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
