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? > > >> 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
