On Fri, Dec 11, 2015 at 12:25 PM, Max Leske <maxle...@gmail.com> wrote:
> > On 10 Dec 2015, at 21:21, Mariano Martinez Peck <marianop...@gmail.com> > wrote: > > > > On Thu, Dec 10, 2015 at 4:12 PM, Mariano Martinez Peck < > marianop...@gmail.com> wrote: > >> >> >> On Thu, Dec 10, 2015 at 7:27 AM, Max Leske <maxle...@gmail.com> wrote: >> >>> >>> On 07 Dec 2015, at 17:17, Mariano Martinez Peck <marianop...@gmail.com> >>> wrote: >>> >>> OK Max. In the last version you can find the "likely" final version. >>> It's extremely simple, easy to use, and very very little code. Only one >>> override. All WADynamicVariables subclasses handled automatically. All you >>> need to do is to register the handler: >>> >>> app filter configuration at: #exceptionHandler put: >>> WAPharoDebuggererErrorHandler. >>> >>> It works for exceptions and both Halt too. The only limit is only the >>> "last opened debugger" will be correct and all previous will be wrong since >>> they will be using another values for dynamic variables. >>> >>> I will see if people want to integrate this directly into Seaside. >>> >>> >>> Very nice! And since you provide a separate error handler it’s easy to >>> integrate into seaside too by simply adding it to the handler chain. >>> >>> >> Exactly. The only issue to fix is the override in WADynamicVariable >> >> defaultAction. >> And that's not easy. Why? Because at that level, we know nothing about >> the current seaside app or anything. We don't know which seaside app those >> signal came from. Of course, I can still do the check to the handler to see >> if that has that variable stored. But... What if now you have set another >> error handler? Or what about OTHER possible registered apps which use a >> different error handler. >> Thoughts? I have some HACKS in mind, but they are hacks and none solves >> all problems. And only for Pharo. >> Any idea to solve this would be nice. >> >> > Assuming you are using GTDebugger (should be very easy to adapt for normal > debugger), we can do this: > > defaultAction > " This is an override from SeasidePharoDebugging because before raising a > signal we > first check if we have the value stored. That way, everywhere > we evaluate code in a debugger that end ups doing 'WACurrentRequestContext > value' will simply > get up to this place. Since in WAPharoDebuggererErrorHandler >> #open: we > stored the dynamic variables, we should have the value " > | openedSeasideErrorDebuggers | > *openedSeasideErrorDebuggers := ((UIManager default currentWorld submorphs > select: [ :each | each model isKindOf: GTGenericStackDebugger ]) * > * collect: [ :each | each model ]) * > * select: [ :each2 | (each2 session interruptedProcess suspendedContext > method selector = #openDebuggerOn:)* > * and: (each2 session interruptedProcess suspendedContext sender receiver > class = WADynamicVariablesErrorHandler) ].* > ^ openedSeasideErrorDebuggers > ifEmpty: [ self class defaultValue ] > ifNotEmpty: [ > (WADynamicVariablesErrorHandler storedDynamicVariable: self class) > ifNil: [ self class defaultValue ] > ] > > But that..the only thing it solves is that we would not be getting the > value of dynamic variables from previous errors if there is none debugger > opened from a seaside continuation. If you let a debugger opened debugging > a seaside error, then there is no magic we can do I think. > Imagine you were in a debugger and you evaluated: "WAComponent new > session". The signal raised from there knows NOTHING about the debugger > where that was evaluated... so at #defaultAction level you know nothing > about what triggered that. > > The only thing to solve this would be to hook into the do-it, print it, > inspect etc...too complicated. > > > Thoughts? > > > I think you’re solution is already pretty good. I wouldn’t really care if > multiple debuggers are a problem. Evaluating a piece of code in context of > the dynamic variables is already a lot of help. Although, if you don’t know > that you’re seeing a different session / request, that’s bad... > > I do have one idea but it might be a bit more complicated and is not > Seaside specific: if we could attach the context of the evaluation to the > suspended context, the handler search should automatically yield the > correct handlers for the dynamic variables (although I don’t know exactly > how the VM resolves the handlers). Alternatively, instead of attaching the > whole stack, it would suffice to copy the handler contexts and attach them > to the evaluation context. Both approaches would also solve the problem of > multiple debuggers. > Yes, I have thought about doing something similar. In GemStone for example, there is another possibility since it allows global static handler for exceptions. So for example you can say install a block to be executed when nobody handled exception XXX. And that closure execution is BEFORE the #defaultAction. So for example in this case I would be able to do that without the override in WADynamicVariable >> defaultAction. mmmmm I am not 100% sure about what I said about GemStone hahahaha. > For this to work the debugger would need highjack the evaluation of code > e.g. by using a custom code editor. > Exactly. We would need to hook on everything: print it, do it, debug it, inspect etc. Maybe at the first level is not that hard (say at debugger level). But imagine you do a "self session inspect". But then, once inside the inspector, you can inspect other objects and open other inspectors, evaluate another piece of code etc... and so the scope would end up in the first level. With current approach we simply propagate the values to everybody , everywhere. But it's also nice to be able to inspect, explore etc from anywhere and you know you will be dealing with the context of the last debugger :) I mean, you can do anything in the image and you will be dealing with the last debug error context :) So I think that even both approaches have advantages and disadvantages, right? > The cool thing about this would be that every evaluation would run in the > same exception handling contexts as the original process. > The bad thing is of course that in some situations you actually don’t care > (or want to care) about those handlers (e.g. when you want to trigger an > exception explicitly during evaluation and don’t want it to be swallowed by > the exception handlers). > > I’ve CC’ed Andrei because he knows more about UI <-> Debugger interaction. > Maybe he has an idea how to do this. > > OK, Thanks. > > > > >> >> >>> Two tiny things: >>> - you’re not using the #reset method you wrote but instead manually >>> assign nil to the variable >>> >> >> yes, thanks. >> >> >>> - I guess the dictionary in the handler could be a SmallDictionary. >>> There won’t be many entries. >>> >>> >> Well..since there will be likely.. less than 10 entries I don't care >> which Dictionary to use. However, I would prefer to keep Dictionary. Or if >> not GRSmallDictionary. >> >> >>> Thanks a lot for this. I’ll probably port this back to Seaside 2.8 so I >>> can use it too :) >>> >> >> No problem. Thanks for reviewing and give feedback. >> >> >> >>> >>> On Sat, Dec 5, 2015 at 11:36 AM, Max Leske <maxle...@gmail.com> wrote: >>> >>>> >>>> On 05 Dec 2015, at 12:58, Mariano Martinez Peck <marianop...@gmail.com> >>>> wrote: >>>> >>>> Can you try with the latest version that does not use LPC if it works? >>>> >>>> >>>> Works perfectly! >>>> >>> >>> >>> >>> -- >>> Mariano >>> http://marianopeck.wordpress.com >>> >>> >>> >> >> >> -- >> Mariano >> http://marianopeck.wordpress.com >> > > > > -- > Mariano > http://marianopeck.wordpress.com > > > -- Mariano http://marianopeck.wordpress.com
