On Sat, Dec 5, 2015 at 8:58 AM, Mariano Martinez Peck <marianopeck@gmail.com
wrote:
On Sat, Dec 5, 2015 at 7:33 AM, Max Leske <maxleske@gmail.com> wrote:
Good stuff Mariano! I think a similar approach will work for Seaside 2.8.
Great.
- I think you might want to override #handleException: and inject the process variable there. Then it doesnât matter from where the debugger is being opened and you donât have to mess with the exception handling logic (which inevitably leads to trouble in my experience).
Good idea. The reason I was hooking there is because I was setting in the process local variable once I know I was already at the UI Manager process and no the Zinc Server one that was processing the request. However...let me explain... Whenever you evaluate something from the debugger, inspector, etc...all that is being run with UI Manager process. While the stack you debugging was actually created at another process (the Zinc Server one that was processing the request). If we store in PLC (processor local variables) when we are in the Zinc process, then the debugger does not see the values at all (since it is in UIManager). We may be able to fix this, but we will need to hook in every possible "evaluation" done from debugger: inspect, do it, print it, etc etc etc. The only reason it make sense to store the values in PLC of the Zinc process rather than UIManager (and make all necessary hooks in inspect, print, etc) is because that would allow us to debug multiple exceptions at the same time. Right now, since values are stored in PLC of UIManager, those are shared for all debuggers. Meaning...you allow only ONE debugger. The last debugger will set new values and the older debuggers will now get the "new values". You can verify this yourself by opening 2 debuggers from my test case.
Anyway.... if we are already going to support 1 one debugger at a time (it's more than enough for my needs), it make no sense to use PLC from UIManager. In fact, the values could be stored ANYWHERE. The only condition is to be able to reach them in each WADynamicVariable subclass >> defaultValue.
In my last commit you can see this new approach. For this experiment I store things in Smalltalk globals but next I will:
1) Use a class side variable in WAPharoDebuggererErrorHandler 2) Automatically store all subclasses of WADynamicValue with convetion..say:
I just committed that. -- Mariano http://marianopeck.wordpress.com