Debugger doesn’t apply dynamic variable values from debugged context to evaluations

[Rinzwind]

Using Pharo 13 build 193, on the following screenshot, I put a halt in a snippet that sets a value for TestDynamicVariable, then in the debugger I try to inspect the send of #value to that variable:

The result is nil. It would be nice if the debugger applied the dynamic variable values from the debugged context to the evaluation, so that the result would be 42.

For a more concrete example, load Seaside and put a breakpoint at the send of #rootClass in #createRoot on WAInitialRenderLoopContinuation, then open a web browser on http://localhost:8080/ and try inspecting the send of #rootClass in the debugger that is opened, you’ll get a second debugger rather than an inspector as a WARequestContextNotFound is signaled due to the dynamic variable WACurrentRequestContext’s value being nil.

[StevenCostiou]

The unfortunate reason is that value calls the following code, in which the dynamic variable tries to extract the value from the active process. However, the active process is the one running the debugger, and the process in which the dynamic variable has the correct value is the interrupted process from the debug session (I tested it, it is correct).

I am looking at adding the correct value in the inspector, it might be easy.
However when evaluating the code it ends up in the compiler.
Neither the compiler and the debugger know each other, and then it is impossible to know anything about the interrupted process.
I am looking at that now, but for it to work properly we have to specialize the doit/printit/debug it commands for dynamic variables.

[MarcusDenker]

Maybe the same idea that we use to read "thisContext" correctly could be used... but one problem is that Dynamic Variables are not Variables... hmm... maybe that would be a nice experiment to try... (but more an experiment, not a solution in the short term)

[StevenCostiou]

a simple way to go would be to override the command in the debugger, so that it does not end up really executing the value in the active process but in one controlled by the debugger

[StevenCostiou]

Ok actually I think it is a bug in the debugger where the api of process is wrongly used.
activeProcess can return the process debugged by the debugger.

I'm experimenting a bit to check that...

[StevenCostiou]

It is pretty obvious we should use that:

evaluate: aBlock onBehalfOf: aProcess
	"Evaluate aBlock setting effectiveProcess to aProcess.  Used
	 in the execution simulation machinery to ensure that
	 Processor activeProcess evaluates correctly when debugging."
	| oldEffectiveProcess |
	oldEffectiveProcess := effectiveProcess.
	effectiveProcess := aProcess.
	^aBlock ensure: [effectiveProcess := oldEffectiveProcess]

But spec won't let me easily call that instead of its command. I am looking at a nice way of doing that.

[StevenCostiou]

It works!
Now need to do tests and a PR.

[StevenCostiou]

fixed by pharo-spec/NewTools#854
@MarcusDenker

[Rinzwind]

Thanks a lot! I already tried the changes of the pull request using the Seaside example I gave above and that works as expected now.

[StevenCostiou]

Cool! :)
I had a problem on the tests but it seems to pass now, it should be integrated I guess.
It would be worth porting it back to P12.

[Rinzwind]

Ah yes, a backport to Pharo 12 would definitely be nice.

[Rinzwind]

This seems to no longer work in the latest Pharo 13 build, so build 313. I checked earlier builds as well: it works in build 299, but not in build 300.

[StevenCostiou]

I do not have an access to a dev computer right now, but if tests are passing that means my tests are not covering enough scenarios :/

How can I see the changes between 299 and 300 specifically?

[Rinzwind]

For the NewTools repository, you can use the link for comparing the reference commits that I gave in issue #17316 which is also due to changes between builds 299 and 300.

[StevenCostiou]

Tests pass everything is ok, just that the method that does the work is not called anymore so it obviously can't work.
In addition, the menu in the code presenter does not have the doit print it commands etc. (build 313).
So it seems the commands calling this code are not here anymore...
Investigating...

[StevenCostiou]

It's a big regression:

• <= v299 the commands (shortcuts and context menu actions) in the debugger code pane go through the SpCodeSelectionCommand
• v300 and abovre the commands are gone (still in the system but not used or available in the code presenter anymore), and instead the morphic code is used and bypass completely the mechanism

It is wrong, however it shows a lack of test coverage.

In holidays right now, I can hardly help until after next week.

[Rinzwind]

It’s fine if this can’t be fixed immediately, we’re not actively using Pharo 13, that will have to wait until it’s released. I have opened a separate issue about the menu items that disappeared: issue #17320.