Re: [Pharo-dev] Hook "WACurrentRequestContext" into debugger?

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
:)

On Fri, Dec 4, 2015 at 12:31 PM, Mariano Martinez Peck <
[email protected]> wrote:

>
>
> On Fri, Dec 4, 2015 at 12:05 PM, Max Leske <[email protected]> wrote:
>
>>
>> On 04 Dec 2015, at 14:29, Mariano Martinez Peck <[email protected]>
>> 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 <[email protected]> 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 <[email protected]> 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 <[email protected]>
>>> 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

_______________________________________________
seaside mailing list
[email protected]
http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside