OK, I solved the Halt problem. I did it by adding: WADebugErrorHandler class >> exceptionSelector ^ super exceptionSelector, Halt
And this override: WAErrorHandler >> handleException: anException (Error handles: anException) ifTrue: [ ^ self handleError: anException ]. (Warning handles: anException) ifTrue: [ ^ self handleWarning: anException ]. (Halt handles: anException) ifTrue: [ "Lets debug Halt as an error so that we can take advantage of the #openDebuggerOn: hook" ^ self handleError: anException ]. ^ super handleException: anException Can you try that too? if it gets complicated to test, I can fire a first version of a package and publish it in Shub. On Fri, Dec 4, 2015 at 2:12 PM, Mariano Martinez Peck <marianop...@gmail.com > wrote: > > > On Fri, Dec 4, 2015 at 1:29 PM, Mariano Martinez Peck < > marianop...@gmail.com> wrote: > >> OK. But be aware it is very very little tested and probably still a hack, >> and it still need overrides. Hopefully you will help me to polish it until >> we get a "SeasidePharoDebugging" package with no override :) >> >> All what I mention here is tested in Pharo 4.0 with Seaside 3.1.4.1. >> >> These are the steps: >> >> 1) Create a >> >> ProcessLocalVariable subclass: #WACurrentRequestContextPLV >> instanceVariableNames: '' >> classVariableNames: '' >> category: 'SeasidePharoDebugging' >> >> 2) Override GRPharoPlatform >> openDebuggerOn (see highlighted lines) >> The idea is to simply store the WACurrentRequestContext into a processor >> local variable before we loose it. >> >> openDebuggerOn: anError >> | process currentRequest | >> process := Processor activeProcess. >> currentRequest := WACurrentRequestContext value. >> >> "If we are running in the UI process, we don't want to suspend the active >> process. The >> error was presumably triggered while stepping in the Debugger. If we >> simply immediately >> signal an UnhandledError, the debugger will catch this and display the >> signaling context. >> It isn't perfect or pretty but it works." >> (ProcessBrowser isUIProcess: process) >> ifTrue: [ >> UnhandledError signalForException: anError ] >> ifFalse: [ >> WorldState addDeferredUIMessage: [ >> WACurrentRequestContextPLV value: currentRequest. >> process >> debug: anError signalerContext >> title: anError description >> full: true. >> ]. >> process suspend ] >> >> >> 3) Override WACurrentRequestContext class >> defaultValue >> >> defaultValue >> ^ WACurrentRequestContextPLV value ifNil: [ WARequestContextNotFound >> signal ] >> 4) Set WADebugErrorHandler as the error handler in your seaside app (I am >> not sure if this step is needed). >> >> And that's all. Try to put a "self whateverMethodThatCausesDNU" and then, >> try to evalaute something from the debugger that calls #session or >> #requestContext etc... for example, evaluate "WAComponent new session" and >> that should work: >> >> Besides the overrides I still have doubts: >> >> a) do we need WADebugErrorHandler ? >> > > Yes, we do, because we are hooking in #openDebuggerOn: and that's only > called from WADebugErrorHandler. > > >> b) it seems "Halt halt" does not work but sending a message that causes >> dnu does work. Maybe related to WADebugErrorHandler. >> > > I guess problem is that while MessageNotUnderstood is indeed a subclass of > Error, Halt is not. Anyway, the real problem is that with halt, the hooked > method #openDebuggerOn: is not called... I tried to find out which > method handled Halt but I failed. > > > c) what happens if we have multiple debuggers opened? I am worried about >> the "soleInstance" of ProcessSpecificVariable. >> >> >> Thoughts? Can you tell me if this works for you? >> >> >> >> >> On Fri, Dec 4, 2015 at 1:13 PM, Max Leske <maxle...@gmail.com> wrote: >> >>> >>> On 04 Dec 2015, at 17:11, Mariano Martinez Peck <marianop...@gmail.com> >>> wrote: >>> >>> I found a way!!!! Much cleaner and easier. Awesome! >>> I will clean it, test it a bit more and try to package it for public >>> usage :) >>> >>> >>> Give me a snippet! I want to play with it! :D >>> >>> >>> On Fri, Dec 4, 2015 at 12:31 PM, Mariano Martinez Peck < >>> marianop...@gmail.com> wrote: >>> >>>> >>>> >>>> On Fri, Dec 4, 2015 at 12:05 PM, Max Leske <maxle...@gmail.com> wrote: >>>> >>>>> >>>>> On 04 Dec 2015, at 14:29, Mariano Martinez Peck <marianop...@gmail.com> >>>>> wrote: >>>>> >>>>> Max...Seaside uses WADynamicVariable (NOT DynamicVariable) which >>>>> are completely different. WADynamicVariable uses exception mechanism >>>>> while DynamicVariable uses the ProcessSpecificVariable. >>>>> But thanks anyway! >>>>> >>>>> >>>>> Oh man…. Sorry :) >>>>> >>>>> I wonder, why WADynamicVariable *isn’t* a DynamicVariable. The >>>>> semantics are the same if I’m not mistaken (e.g. only available in the >>>>> current process) and I think access to a dynamic variable may even be >>>>> faster because it *doesn’t* use the exception mechanism (i.e. no need to >>>>> walk down the stack). >>>>> If someone knows the answer, I’d be happy to hear it. >>>>> >>>>> >>>> I bet it's because of portability. For example, i remember in GemStone >>>> the ProcessorLocalVariable did not behave the same as in Pharo. And it was >>>> actually an experiment. I think you cannot expect all this stuff to be ansi >>>> (or easily portable), while exceptions do. >>>> >>>> >>>>> I’ve played around with Process>>signalException: and >>>>> Context>>handleSignal: (which looked quite promising) but didn’t get any >>>>> results. I’m out of ideas. >>>>> >>>>> >>>> I have played all morning with an idea of using local variables. I >>>> arrive to the point where I DO HAVE the request context at hand, but I >>>> don't find an easy way to hook into do-its, print-it etc so that the >>>> closure evaluated gets the request context plugged. In other ways... let's >>>> say I have the context stored somewhere. I am at the SmalltalkEditor >> >>>> evaluateSelectionAndDo: aBlock >>>> >>>> and so..somewhere I need to do something like: >>>> >>>> WACurrentRequestContext use: self storedContextSomewhere during: [ >>>> self theSelectionToBeEvaluated ] >>>> >>>> and that's where I am now :) >>>> >>>> >>>> >>>> >>>>> Cheers, >>>>> Max >>>>> >>>>> >>>>> On Fri, Dec 4, 2015 at 7:32 AM, Max Leske <maxle...@gmail.com> wrote: >>>>> >>>>>> Here’s a snippet to play with: >>>>>> >>>>>> p := Processor activeProcess. >>>>>> x := 2. >>>>>> v := TestDynamicVariable value: x during: [ >>>>>> ((p instVarNamed: 'env') ifNotNil: [ :env| >>>>>> env copyWithout: nil ]) inspect >>>>>> ]. >>>>>> >>>>>> ((p instVarNamed: 'env') ifNotNil: [ :env| >>>>>> env copyWithout: nil ]) inspect >>>>>> >>>>>> Cheers, >>>>>> Max >>>>>> >>>>>> On 04 Dec 2015, at 10:47, Max Leske <maxle...@gmail.com> wrote: >>>>>> >>>>>> I feel you :) >>>>>> >>>>>> Without having thought this through completely: if you look at the >>>>>> implementation of DynamicVariable>>value:during: you’ll see that the way >>>>>> it >>>>>> works is that the variable is bound to the active process. In the >>>>>> debugger >>>>>> you have access to the process that is being debugged and thus you should >>>>>> have access to the variables bound to it. You could try accessing all >>>>>> such >>>>>> variables by iterating over them (which I think will require an extension >>>>>> on Process because you’d need to access at least the PSKeys class >>>>>> variable). >>>>>> >>>>>> Cheers, >>>>>> Max >>>>>> >>>>>> On 04 Dec 2015, at 00:34, Mariano Martinez Peck < >>>>>> marianop...@gmail.com> wrote: >>>>>> >>>>>> Hi guys, >>>>>> >>>>>> This thing I will ask in this email it's in my mind since YEARS. But >>>>>> I have always thought it was like that and that there was nothing we >>>>>> could >>>>>> do. However, I think it's time I ask again :) >>>>>> >>>>>> For those that have used Seaside, and you try to debug, you know that >>>>>> upon request processing seaside uses Exceptions mechanisim to always have >>>>>> access to the request, session, etc. They way that is done is very smart >>>>>> :) >>>>>> >>>>>> WACurrentRequestContext use: self during: aBlock >>>>>> >>>>>> In that case, "self" is the request instance and aBlock the closure >>>>>> that takes care of the request processing. So, inside that closure, >>>>>> everywhere you do "WACurrentRequestContext value" you get the correct >>>>>> request instance. >>>>>> >>>>>> So..that's great for Seaside, but debugging gets complicated. While >>>>>> you can restart, proceed, etc, once inside debugger, you cannot evaluate >>>>>> any piece of code that will use the session or request because you get >>>>>> a WARequestContextNotFound. Of course, because I guess the evaluation you >>>>>> do from cmd+d on a piece of text or via the debugger inspector, creates >>>>>> another closure/context which does not receive the >>>>>> WACurrentRequestContext >>>>>> instance. >>>>>> >>>>>> Now....besides WACurrentRequestContext I have my own class >>>>>> UserContextInformation where I basically have a bunch of stuff associated >>>>>> to the logged user. And I do exactly the same as the >>>>>> WACurrentRequestContext. And I have the same problem. I really want to be >>>>>> able to fix this. >>>>>> >>>>>> Anyone have an idea on how can I do it? I guess I can change the >>>>>> debugger, in the place where I evaluate code so that I wrap that >>>>>> evaluation >>>>>> with my request context instance??? >>>>>> >>>>>> Thoughts? >>>>>> >>>>>> >>>>>> -- >>>>>> Mariano >>>>>> http://marianopeck.wordpress.com >>>>>> >>>>>> >>>>>> >>>>>> >>>>> >>>>> >>>>> -- >>>>> Mariano >>>>> http://marianopeck.wordpress.com >>>>> >>>>> >>>>> >>>> >>>> >>>> -- >>>> Mariano >>>> http://marianopeck.wordpress.com >>>> >>> >>> >>> >>> -- >>> Mariano >>> http://marianopeck.wordpress.com >>> >>> >>> >> >> >> -- >> Mariano >> http://marianopeck.wordpress.com >> > > > > -- > Mariano > http://marianopeck.wordpress.com > -- Mariano http://marianopeck.wordpress.com
