Am 04.12.2015 um 16:05 schrieb Max Leske <maxleske@gmail.com>:
On 04 Dec 2015, at 14:29, Mariano Martinez Peck <marianopeck@gmail.com <mailto:marianopeck@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âve played around with Process>>signalException: and Context>>handleSignal: (which looked quite promising) but didnât get any results. Iâm out of ideas.
There was no DynamicVariable in pharo when seaside was created. It has been introduced in pharo3?? There are not fully equivalent so it is hard to say better or not. We had a problem that you cannot access a process specific variable because the debugger forks off. But we introduced a fix from Eliot where the effective process is taken into account. A resumable exception should be available as long as you have access to the whole stack up to the closure for that exception. So should be independent of the process you are in. I cannot recall why this makes problems at all. my 2 cents, Norbert
Cheers, Max
On Fri, Dec 4, 2015 at 7:32 AM, Max Leske <maxleske@gmail.com <mailto:maxleske@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 <maxleske@gmail.com <mailto:maxleske@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 <marianopeck@gmail.com <mailto:marianopeck@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/>