On Fri, Dec 4, 2015 at 1:29 PM, Mariano Martinez Peck <marianopeck@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 <maxleske@gmail.com> wrote:

On 04 Dec 2015, at 17:11, Mariano Martinez Peck <marianopeck@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 <marianopeck@gmail.com> wrote:

On Fri, Dec 4, 2015 at 12:05 PM, Max Leske <maxleske@gmail.com> wrote:

On 04 Dec 2015, at 14:29, Mariano Martinez Peck <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 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 <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> 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> 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