> 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 > <mailto:marianop...@gmail.com>> wrote: > > > On Fri, Dec 4, 2015 at 12:05 PM, Max Leske <maxle...@gmail.com > <mailto:maxle...@gmail.com>> wrote: > >> On 04 Dec 2015, at 14:29, Mariano Martinez Peck <marianop...@gmail.com >> <mailto: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 >> <mailto: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 >>> <mailto: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 >>>> <mailto: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 <http://marianopeck.wordpress.com/> >>> >> >> >> >> >> -- >> Mariano >> http://marianopeck.wordpress.com <http://marianopeck.wordpress.com/> > > > > > -- > Mariano > http://marianopeck.wordpress.com <http://marianopeck.wordpress.com/> > > > > -- > Mariano > http://marianopeck.wordpress.com <http://marianopeck.wordpress.com/>
