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 <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/>

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’ve played around with Process>>signalException: and Context>>handleSignal: (which looked quite promising) but didn’t get any results. I’m out of ideas. 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/>

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

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 ? b) it seems "Halt halt" does not work but sending a message that causes dnu does work. Maybe related to WADebugErrorHandler. 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

OK, I solved the Halt problem. I did it by adding: WADebugErrorHandler class >> exceptionSelector ^ super exceptionSelector, Halt And this override: WAErrorHandler >> handleException: anException (Error handles: anException) ifTrue: [ ^ self handleError: anException ]. (Warning handles: anException) ifTrue: [ ^ self handleWarning: anException ]. (Halt handles: anException) ifTrue: [ "Lets debug Halt as an error so that we can take advantage of the #openDebuggerOn: hook" ^ self handleError: anException ]. ^ super handleException: anException Can you try that too? if it gets complicated to test, I can fire a first version of a package and publish it in Shub. On Fri, Dec 4, 2015 at 2:12 PM, Mariano Martinez Peck <marianopeck@gmail.com

wrote:

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

-- Mariano http://marianopeck.wordpress.com

OK, I tested it and it works. I added only one test but I plan to add more. On Fri, Dec 4, 2015 at 4:59 PM, Mariano Martinez Peck <marianopeck@gmail.com

wrote:

OK, I started publishing here: http://smalltalkhub.com/mc/marianopeck/MarianoPublic/main package called SeasidePharoDebugging I did not even have the time to try it..just committed. I must leave now.

byw

On Fri, Dec 4, 2015 at 2:43 PM, Mariano Martinez Peck < marianopeck@gmail.com> wrote:

...

OK, I solved the Halt problem. I did it by adding:

WADebugErrorHandler class >> exceptionSelector ^ super exceptionSelector, Halt

And this override:

WAErrorHandler >> handleException: anException (Error handles: anException) ifTrue: [ ^ self handleError: anException ]. (Warning handles: anException) ifTrue: [ ^ self handleWarning: anException ]. (Halt handles: anException) ifTrue: [ "Lets debug Halt as an error so that we can take advantage of the #openDebuggerOn: hook" ^ self handleError: anException ]. ^ super handleException: anException

Can you try that too?

if it gets complicated to test, I can fire a first version of a package and publish it in Shub.

On Fri, Dec 4, 2015 at 2:12 PM, Mariano Martinez Peck < marianopeck@gmail.com> wrote:

...

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

-- Mariano http://marianopeck.wordpress.com

-- Mariano http://marianopeck.wordpress.com

-- Mariano http://marianopeck.wordpress.com

Good stuff Mariano! I think a similar approach will work for Seaside 2.8. - I think you might want to override #handleException: and inject the process variable there. Then it doesn’t matter from where the debugger is being opened and you don’t have to mess with the exception handling logic (which inevitably leads to trouble in my experience). - There’s an “er” too many in WAPharoDebuggererErrorHandler :) - Your current solution doesn’t work for the UI process. Snippet: [ WACurrentRequestContext use: 'foo' during: [ WAPharoDebuggererErrorHandler new handleExceptionsDuring: [ self halt. ] ] ] fork. Without the #fork the process will be the UI process and the request will not be saved into the process variable. That’s not a deal breaker but nice for testing. Incidentally, you could reuse WACurrentRequestContext (instead of the new process variable) in #openDebuggerOn: like so: WACurrentRequestContext use: currentRequest during: [ process debug: anError signalerContext title: anError description full: true. ] ]. That would make it much easier for users not familiar with the process variable trick. Cheers, Max

On 05 Dec 2015, at 00:11, Mariano Martinez Peck <marianopeck@gmail.com> wrote:

I added more tests to WACurrentRequestDebuggingTest. If you see, all tests work except #callbackAndHalt.

At a later point we will likely need to do this for the rest of the WADynamicVariable subclasses (they are 3 in total).

Cheers,

On Fri, Dec 4, 2015 at 7:17 PM, Mariano Martinez Peck <marianopeck@gmail.com <mailto:marianopeck@gmail.com>> wrote: OK, I tested it and it works. I added only one test but I plan to add more.

On Fri, Dec 4, 2015 at 4:59 PM, Mariano Martinez Peck <marianopeck@gmail.com <mailto:marianopeck@gmail.com>> wrote: OK, I started publishing here: http://smalltalkhub.com/mc/marianopeck/MarianoPublic/main <http://smalltalkhub.com/mc/marianopeck/MarianoPublic/main> package called SeasidePharoDebugging I did not even have the time to try it..just committed. I must leave now.

byw

On Fri, Dec 4, 2015 at 2:43 PM, Mariano Martinez Peck <marianopeck@gmail.com <mailto:marianopeck@gmail.com>> wrote: OK, I solved the Halt problem. I did it by adding:

WADebugErrorHandler class >> exceptionSelector ^ super exceptionSelector, Halt

And this override:

WAErrorHandler >> handleException: anException (Error handles: anException) ifTrue: [ ^ self handleError: anException ]. (Warning handles: anException) ifTrue: [ ^ self handleWarning: anException ]. (Halt handles: anException) ifTrue: [ "Lets debug Halt as an error so that we can take advantage of the #openDebuggerOn: hook" ^ self handleError: anException ]. ^ super handleException: anException

Can you try that too?

if it gets complicated to test, I can fire a first version of a package and publish it in Shub.

On Fri, Dec 4, 2015 at 2:12 PM, Mariano Martinez Peck <marianopeck@gmail.com <mailto:marianopeck@gmail.com>> wrote:

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

...

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

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

...

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 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 <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/>

-- 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/>

-- 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/>

...

Incidentally, you could reuse WACurrentRequestContext (instead of the new process variable) in #openDebuggerOn: like so:

WACurrentRequestContext use: currentRequest during: [ process debug: anError signalerContext title: anError description full: true. ] ].

That would make it much easier for users not familiar with the process variable trick.

mmmmm are you sure this works? (in any case, we will not go that path anymore but I am curious if that did work for you)

by "works" I mean if you tested with WACurrentRequestDebuggingTest and followed the steps in its comments (the identityHash comparison to transcript).

Thanks!

...

Cheers, Max

On 05 Dec 2015, at 00:11, Mariano Martinez Peck <marianopeck@gmail.com> wrote:

I added more tests to WACurrentRequestDebuggingTest. If you see, all tests work except #callbackAndHalt.

At a later point we will likely need to do this for the rest of the WADynamicVariable subclasses (they are 3 in total).

Cheers,

On Fri, Dec 4, 2015 at 7:17 PM, Mariano Martinez Peck < marianopeck@gmail.com> wrote:

...

OK, I tested it and it works. I added only one test but I plan to add more.

On Fri, Dec 4, 2015 at 4:59 PM, Mariano Martinez Peck < marianopeck@gmail.com> wrote:

...

OK, I started publishing here: http://smalltalkhub.com/mc/marianopeck/MarianoPublic/main package called SeasidePharoDebugging I did not even have the time to try it..just committed. I must leave now.

byw

On Fri, Dec 4, 2015 at 2:43 PM, Mariano Martinez Peck < marianopeck@gmail.com> wrote:

...

OK, I solved the Halt problem. I did it by adding:

WADebugErrorHandler class >> exceptionSelector ^ super exceptionSelector, Halt

And this override:

WAErrorHandler >> handleException: anException (Error handles: anException) ifTrue: [ ^ self handleError: anException ]. (Warning handles: anException) ifTrue: [ ^ self handleWarning: anException ]. (Halt handles: anException) ifTrue: [ "Lets debug Halt as an error so that we can take advantage of the #openDebuggerOn: hook" ^ self handleError: anException ]. ^ super handleException: anException

Can you try that too?

if it gets complicated to test, I can fire a first version of a package and publish it in Shub.

On Fri, Dec 4, 2015 at 2:12 PM, Mariano Martinez Peck < marianopeck@gmail.com> wrote:

...

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

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

On 05 Dec 2015, at 14:07, Mariano Martinez Peck <marianopeck@gmail.com> wrote:

On Sat, Dec 5, 2015 at 8:58 AM, Mariano Martinez Peck <marianopeck@gmail.com <mailto:marianopeck@gmail.com>> wrote:

On Sat, Dec 5, 2015 at 7:33 AM, Max Leske <maxleske@gmail.com <mailto:maxleske@gmail.com>> wrote: Good stuff Mariano! I think a similar approach will work for Seaside 2.8.

Great.

- I think you might want to override #handleException: and inject the process variable there. Then it doesn’t matter from where the debugger is being opened and you don’t have to mess with the exception handling logic (which inevitably leads to trouble in my experience).

Good idea. The reason I was hooking there is because I was setting in the process local variable once I know I was already at the UI Manager process and no the Zinc Server one that was processing the request. However...let me explain... Whenever you evaluate something from the debugger, inspector, etc...all that is being run with UI Manager process. While the stack you debugging was actually created at another process (the Zinc Server one that was processing the request). If we store in PLC (processor local variables) when we are in the Zinc process, then the debugger does not see the values at all (since it is in UIManager). We may be able to fix this, but we will need to hook in every possible "evaluation" done from debugger: inspect, do it, print it, etc etc etc. The only reason it make sense to store the values in PLC of the Zinc process rather than UIManager (and make all necessary hooks in inspect, print, etc) is because that would allow us to debug multiple exceptions at the same time. Right now, since values are stored in PLC of UIManager, those are shared for all debuggers. Meaning...you allow only ONE debugger. The last debugger will set new values and the older debuggers will now get the "new values". You can verify this yourself by opening 2 debuggers from my test case.

Anyway.... if we are already going to support 1 one debugger at a time (it's more than enough for my needs), it make no sense to use PLC from UIManager. In fact, the values could be stored ANYWHERE. The only condition is to be able to reach them in each WADynamicVariable subclass >> defaultValue.

In my last commit you can see this new approach. For this experiment I store things in Smalltalk globals but next I will:

1) Use a class side variable in WAPharoDebuggererErrorHandler 2) Automatically store all subclasses of WADynamicValue with convetion..say:

That might be the better approach. More transparent too.

I just committed that.

-- Mariano http://marianopeck.wordpress.com <http://marianopeck.wordpress.com/>

...

mmmmm are you sure this works? (in any case, we will not go that path anymore but I am curious if that did work for you)

by "works" I mean if you tested with WACurrentRequestDebuggingTest and followed the steps in its comments (the identityHash comparison to transcript).

Actually, I did test it before I replied to your e-mail. But now it seems I must have evaluated the wrong piece of code or something. If you think about it of course it makes sense: any #DoIt has a separate stack, so the exception handling mechanism will not find those handlers.

OK Max. In the last version you can find the "likely" final version. It's extremely simple, easy to use, and very very little code. Only one override. All WADynamicVariables subclasses handled automatically. All you need to do is to register the handler: app filter configuration at: #exceptionHandler put: WAPharoDebuggererErrorHandler. It works for exceptions and both Halt too. The only limit is only the "last opened debugger" will be correct and all previous will be wrong since they will be using another values for dynamic variables. I will see if people want to integrate this directly into Seaside. On Sat, Dec 5, 2015 at 11:36 AM, Max Leske <maxleske@gmail.com> wrote:

On 05 Dec 2015, at 12:58, Mariano Martinez Peck <marianopeck@gmail.com> wrote:

Can you try with the latest version that does not use LPC if it works?

Works perfectly!

-- Mariano http://marianopeck.wordpress.com

On 07 Dec 2015, at 17:17, Mariano Martinez Peck <marianopeck@gmail.com> wrote:

OK Max. In the last version you can find the "likely" final version. It's extremely simple, easy to use, and very very little code. Only one override. All WADynamicVariables subclasses handled automatically. All you need to do is to register the handler:

app filter configuration at: #exceptionHandler put: WAPharoDebuggererErrorHandler.

It works for exceptions and both Halt too. The only limit is only the "last opened debugger" will be correct and all previous will be wrong since they will be using another values for dynamic variables.

I will see if people want to integrate this directly into Seaside.

Very nice! And since you provide a separate error handler it’s easy to integrate into seaside too by simply adding it to the handler chain. Two tiny things: - you’re not using the #reset method you wrote but instead manually assign nil to the variable - I guess the dictionary in the handler could be a SmallDictionary. There won’t be many entries. Thanks a lot for this. I’ll probably port this back to Seaside 2.8 so I can use it too :) Cheers, Max

On Sat, Dec 5, 2015 at 11:36 AM, Max Leske <maxleske@gmail.com <mailto:maxleske@gmail.com>> wrote:

...

On 05 Dec 2015, at 12:58, Mariano Martinez Peck <marianopeck@gmail.com <mailto:marianopeck@gmail.com>> wrote:

Can you try with the latest version that does not use LPC if it works?

Works perfectly!

-- Mariano http://marianopeck.wordpress.com <http://marianopeck.wordpress.com/>

On Thu, Dec 10, 2015 at 4:12 PM, Mariano Martinez Peck < marianopeck@gmail.com> wrote:

On Thu, Dec 10, 2015 at 7:27 AM, Max Leske <maxleske@gmail.com> wrote:

...

On 07 Dec 2015, at 17:17, Mariano Martinez Peck <marianopeck@gmail.com> wrote:

OK Max. In the last version you can find the "likely" final version. It's extremely simple, easy to use, and very very little code. Only one override. All WADynamicVariables subclasses handled automatically. All you need to do is to register the handler:

app filter configuration at: #exceptionHandler put: WAPharoDebuggererErrorHandler.

It works for exceptions and both Halt too. The only limit is only the "last opened debugger" will be correct and all previous will be wrong since they will be using another values for dynamic variables.

I will see if people want to integrate this directly into Seaside.

Very nice! And since you provide a separate error handler it’s easy to integrate into seaside too by simply adding it to the handler chain.

Exactly. The only issue to fix is the override in WADynamicVariable >> defaultAction. And that's not easy. Why? Because at that level, we know nothing about the current seaside app or anything. We don't know which seaside app those signal came from. Of course, I can still do the check to the handler to see if that has that variable stored. But... What if now you have set another error handler? Or what about OTHER possible registered apps which use a different error handler. Thoughts? I have some HACKS in mind, but they are hacks and none solves all problems. And only for Pharo. Any idea to solve this would be nice.

Assuming you are using GTDebugger (should be very easy to adapt for normal debugger), we can do this: defaultAction " This is an override from SeasidePharoDebugging because before raising a signal we first check if we have the value stored. That way, everywhere we evaluate code in a debugger that end ups doing 'WACurrentRequestContext value' will simply get up to this place. Since in WAPharoDebuggererErrorHandler >> #open: we stored the dynamic variables, we should have the value " | openedSeasideErrorDebuggers | *openedSeasideErrorDebuggers := ((UIManager default currentWorld submorphs select: [ :each | each model isKindOf: GTGenericStackDebugger ]) * * collect: [ :each | each model ]) * * select: [ :each2 | (each2 session interruptedProcess suspendedContext method selector = #openDebuggerOn:)* * and: (each2 session interruptedProcess suspendedContext sender receiver class = WADynamicVariablesErrorHandler) ].* ^ openedSeasideErrorDebuggers ifEmpty: [ self class defaultValue ] ifNotEmpty: [ (WADynamicVariablesErrorHandler storedDynamicVariable: self class) ifNil: [ self class defaultValue ] ] But that..the only thing it solves is that we would not be getting the value of dynamic variables from previous errors if there is none debugger opened from a seaside continuation. If you let a debugger opened debugging a seaside error, then there is no magic we can do I think. Imagine you were in a debugger and you evaluated: "WAComponent new session". The signal raised from there knows NOTHING about the debugger where that was evaluated... so at #defaultAction level you know nothing about what triggered that. The only thing to solve this would be to hook into the do-it, print it, inspect etc...too complicated. Thoughts?

...

Two tiny things: - you’re not using the #reset method you wrote but instead manually assign nil to the variable

yes, thanks.

...

- I guess the dictionary in the handler could be a SmallDictionary. There won’t be many entries.

Well..since there will be likely.. less than 10 entries I don't care which Dictionary to use. However, I would prefer to keep Dictionary. Or if not GRSmallDictionary.

...

Thanks a lot for this. I’ll probably port this back to Seaside 2.8 so I can use it too :)

No problem. Thanks for reviewing and give feedback.

...

On Sat, Dec 5, 2015 at 11:36 AM, Max Leske <maxleske@gmail.com> wrote:

...

On 05 Dec 2015, at 12:58, Mariano Martinez Peck <marianopeck@gmail.com> wrote:

Can you try with the latest version that does not use LPC if it works?

Works perfectly!

-- Mariano http://marianopeck.wordpress.com

-- Mariano http://marianopeck.wordpress.com

-- Mariano http://marianopeck.wordpress.com

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

On 10 Dec 2015, at 21:21, Mariano Martinez Peck <marianopeck@gmail.com> wrote:

On Thu, Dec 10, 2015 at 4:12 PM, Mariano Martinez Peck < marianopeck@gmail.com> wrote:

...

On Thu, Dec 10, 2015 at 7:27 AM, Max Leske <maxleske@gmail.com> wrote:

...

On 07 Dec 2015, at 17:17, Mariano Martinez Peck <marianopeck@gmail.com> wrote:

OK Max. In the last version you can find the "likely" final version. It's extremely simple, easy to use, and very very little code. Only one override. All WADynamicVariables subclasses handled automatically. All you need to do is to register the handler:

app filter configuration at: #exceptionHandler put: WAPharoDebuggererErrorHandler.

It works for exceptions and both Halt too. The only limit is only the "last opened debugger" will be correct and all previous will be wrong since they will be using another values for dynamic variables.

I will see if people want to integrate this directly into Seaside.

Very nice! And since you provide a separate error handler it’s easy to integrate into seaside too by simply adding it to the handler chain.

Exactly. The only issue to fix is the override in WADynamicVariable >> defaultAction. And that's not easy. Why? Because at that level, we know nothing about the current seaside app or anything. We don't know which seaside app those signal came from. Of course, I can still do the check to the handler to see if that has that variable stored. But... What if now you have set another error handler? Or what about OTHER possible registered apps which use a different error handler. Thoughts? I have some HACKS in mind, but they are hacks and none solves all problems. And only for Pharo. Any idea to solve this would be nice.

Assuming you are using GTDebugger (should be very easy to adapt for normal debugger), we can do this:

defaultAction " This is an override from SeasidePharoDebugging because before raising a signal we first check if we have the value stored. That way, everywhere we evaluate code in a debugger that end ups doing 'WACurrentRequestContext value' will simply get up to this place. Since in WAPharoDebuggererErrorHandler >> #open: we stored the dynamic variables, we should have the value " | openedSeasideErrorDebuggers | *openedSeasideErrorDebuggers := ((UIManager default currentWorld submorphs select: [ :each | each model isKindOf: GTGenericStackDebugger ]) * * collect: [ :each | each model ]) * * select: [ :each2 | (each2 session interruptedProcess suspendedContext method selector = #openDebuggerOn:)* * and: (each2 session interruptedProcess suspendedContext sender receiver class = WADynamicVariablesErrorHandler) ].* ^ openedSeasideErrorDebuggers ifEmpty: [ self class defaultValue ] ifNotEmpty: [ (WADynamicVariablesErrorHandler storedDynamicVariable: self class) ifNil: [ self class defaultValue ] ]

But that..the only thing it solves is that we would not be getting the value of dynamic variables from previous errors if there is none debugger opened from a seaside continuation. If you let a debugger opened debugging a seaside error, then there is no magic we can do I think. Imagine you were in a debugger and you evaluated: "WAComponent new session". The signal raised from there knows NOTHING about the debugger where that was evaluated... so at #defaultAction level you know nothing about what triggered that.

The only thing to solve this would be to hook into the do-it, print it, inspect etc...too complicated.

Thoughts?

I think you’re solution is already pretty good. I wouldn’t really care if multiple debuggers are a problem. Evaluating a piece of code in context of the dynamic variables is already a lot of help. Although, if you don’t know that you’re seeing a different session / request, that’s bad...

I do have one idea but it might be a bit more complicated and is not Seaside specific: if we could attach the context of the evaluation to the suspended context, the handler search should automatically yield the correct handlers for the dynamic variables (although I don’t know exactly how the VM resolves the handlers). Alternatively, instead of attaching the whole stack, it would suffice to copy the handler contexts and attach them to the evaluation context. Both approaches would also solve the problem of multiple debuggers.

Yes, I have thought about doing something similar. In GemStone for example, there is another possibility since it allows global static handler for exceptions. So for example you can say install a block to be executed when nobody handled exception XXX. And that closure execution is BEFORE the #defaultAction. So for example in this case I would be able to do that without the override in WADynamicVariable >> defaultAction. mmmmm I am not 100% sure about what I said about GemStone hahahaha.

For this to work the debugger would need highjack the evaluation of code e.g. by using a custom code editor.

Exactly. We would need to hook on everything: print it, do it, debug it, inspect etc. Maybe at the first level is not that hard (say at debugger level). But imagine you do a "self session inspect". But then, once inside the inspector, you can inspect other objects and open other inspectors, evaluate another piece of code etc... and so the scope would end up in the first level. With current approach we simply propagate the values to everybody , everywhere. But it's also nice to be able to inspect, explore etc from anywhere and you know you will be dealing with the context of the last debugger :) I mean, you can do anything in the image and you will be dealing with the last debug error context :) So I think that even both approaches have advantages and disadvantages, right?

The cool thing about this would be that every evaluation would run in the same exception handling contexts as the original process. The bad thing is of course that in some situations you actually don’t care (or want to care) about those handlers (e.g. when you want to trigger an exception explicitly during evaluation and don’t want it to be swallowed by the exception handlers).

I’ve CC’ed Andrei because he knows more about UI <-> Debugger interaction. Maybe he has an idea how to do this.

OK, Thanks.

...

...

Two tiny things: - you’re not using the #reset method you wrote but instead manually assign nil to the variable

yes, thanks.

...

- I guess the dictionary in the handler could be a SmallDictionary. There won’t be many entries.

Well..since there will be likely.. less than 10 entries I don't care which Dictionary to use. However, I would prefer to keep Dictionary. Or if not GRSmallDictionary.

...

Thanks a lot for this. I’ll probably port this back to Seaside 2.8 so I can use it too :)

No problem. Thanks for reviewing and give feedback.

...

On Sat, Dec 5, 2015 at 11:36 AM, Max Leske <maxleske@gmail.com> wrote:

...

On 05 Dec 2015, at 12:58, Mariano Martinez Peck <marianopeck@gmail.com> wrote:

Can you try with the latest version that does not use LPC if it works?

Works perfectly!

-- Mariano http://marianopeck.wordpress.com

-- Mariano http://marianopeck.wordpress.com

-- Mariano http://marianopeck.wordpress.com

-- Mariano http://marianopeck.wordpress.com

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

On 11 Dec 2015, at 16:39, Mariano Martinez Peck <marianopeck@gmail.com> wrote:

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

...

On 10 Dec 2015, at 21:21, Mariano Martinez Peck <marianopeck@gmail.com> wrote:

On Thu, Dec 10, 2015 at 4:12 PM, Mariano Martinez Peck < marianopeck@gmail.com> wrote:

...

On Thu, Dec 10, 2015 at 7:27 AM, Max Leske <maxleske@gmail.com> wrote:

...

On 07 Dec 2015, at 17:17, Mariano Martinez Peck <marianopeck@gmail.com> wrote:

OK Max. In the last version you can find the "likely" final version. It's extremely simple, easy to use, and very very little code. Only one override. All WADynamicVariables subclasses handled automatically. All you need to do is to register the handler:

app filter configuration at: #exceptionHandler put: WAPharoDebuggererErrorHandler.

It works for exceptions and both Halt too. The only limit is only the "last opened debugger" will be correct and all previous will be wrong since they will be using another values for dynamic variables.

I will see if people want to integrate this directly into Seaside.

Very nice! And since you provide a separate error handler it’s easy to integrate into seaside too by simply adding it to the handler chain.

Exactly. The only issue to fix is the override in WADynamicVariable >> defaultAction. And that's not easy. Why? Because at that level, we know nothing about the current seaside app or anything. We don't know which seaside app those signal came from. Of course, I can still do the check to the handler to see if that has that variable stored. But... What if now you have set another error handler? Or what about OTHER possible registered apps which use a different error handler. Thoughts? I have some HACKS in mind, but they are hacks and none solves all problems. And only for Pharo. Any idea to solve this would be nice.

Assuming you are using GTDebugger (should be very easy to adapt for normal debugger), we can do this:

defaultAction " This is an override from SeasidePharoDebugging because before raising a signal we first check if we have the value stored. That way, everywhere we evaluate code in a debugger that end ups doing 'WACurrentRequestContext value' will simply get up to this place. Since in WAPharoDebuggererErrorHandler >> #open: we stored the dynamic variables, we should have the value " | openedSeasideErrorDebuggers | *openedSeasideErrorDebuggers := ((UIManager default currentWorld submorphs select: [ :each | each model isKindOf: GTGenericStackDebugger ]) * * collect: [ :each | each model ]) * * select: [ :each2 | (each2 session interruptedProcess suspendedContext method selector = #openDebuggerOn:)* * and: (each2 session interruptedProcess suspendedContext sender receiver class = WADynamicVariablesErrorHandler) ].* ^ openedSeasideErrorDebuggers ifEmpty: [ self class defaultValue ] ifNotEmpty: [ (WADynamicVariablesErrorHandler storedDynamicVariable: self class) ifNil: [ self class defaultValue ] ]

But that..the only thing it solves is that we would not be getting the value of dynamic variables from previous errors if there is none debugger opened from a seaside continuation. If you let a debugger opened debugging a seaside error, then there is no magic we can do I think. Imagine you were in a debugger and you evaluated: "WAComponent new session". The signal raised from there knows NOTHING about the debugger where that was evaluated... so at #defaultAction level you know nothing about what triggered that.

The only thing to solve this would be to hook into the do-it, print it, inspect etc...too complicated.

Thoughts?

I think you’re solution is already pretty good. I wouldn’t really care if multiple debuggers are a problem. Evaluating a piece of code in context of the dynamic variables is already a lot of help. Although, if you don’t know that you’re seeing a different session / request, that’s bad...

I do have one idea but it might be a bit more complicated and is not Seaside specific: if we could attach the context of the evaluation to the suspended context, the handler search should automatically yield the correct handlers for the dynamic variables (although I don’t know exactly how the VM resolves the handlers). Alternatively, instead of attaching the whole stack, it would suffice to copy the handler contexts and attach them to the evaluation context. Both approaches would also solve the problem of multiple debuggers.

Yes, I have thought about doing something similar. In GemStone for example, there is another possibility since it allows global static handler for exceptions. So for example you can say install a block to be executed when nobody handled exception XXX. And that closure execution is BEFORE the #defaultAction. So for example in this case I would be able to do that without the override in WADynamicVariable >> defaultAction. mmmmm I am not 100% sure about what I said about GemStone hahahaha.

Intersting. But wouldn’t you have the same problem with multiple debuggers? They’d all use the same global handler, wouldn’t they?

Yes. But I would solve the override :)

...

For this to work the debugger would need highjack the evaluation of code e.g. by using a custom code editor.

Exactly. We would need to hook on everything: print it, do it, debug it, inspect etc. Maybe at the first level is not that hard (say at debugger level). But imagine you do a "self session inspect". But then, once inside the inspector, you can inspect other objects and open other inspectors, evaluate another piece of code etc... and so the scope would end up in the first level.

Yes, right. That’s a problem, although what I usually do is inspect the session and then use the session in a new handler context to run my code:

WASession use: self during: [ … ]

Indeed, that works. But again, works only inside that closure. So if you want to open a new inspector, or given the same inspector navigate other objects, then execute or or then type something in a playground etc, you are out of context. Each code evaluation will have it's own new context. So you would need to type above code every time you need that. But at least we agree in the pros and cons of each solution :)

Thus I don’t care too much about what happens outside of the debugger. Of course, not everyone understands the session handling mechanism, so it’s probably not the solution for everyone. Still, having access to dynamic variables *at least* in the debugger, is already a big improvement in itself. We don’t need to rethink everything.

Well...I think I personally prefer to have it accessible everywhere (even outside the debugger) with the known limitations (that we have discussed many times). But tastes are tastes :) If you prefer only at debugger level, allow multiple debugger, etc... and if you use GT Debugger it looked not so hard to hook into code execution. But make sure you are able to first make the "backend" support (copy exception handlers from suspended process to the new process result of evaluation).

With current approach we simply propagate the values to everybody , everywhere. But it's also nice to be able to inspect, explore etc from anywhere and you know you will be dealing with the context of the last debugger :) I mean, you can do anything in the image and you will be dealing with the last debug error context :) So I think that even both approaches have advantages and disadvantages, right?

...

The cool thing about this would be that every evaluation would run in the same exception handling contexts as the original process. The bad thing is of course that in some situations you actually don’t care (or want to care) about those handlers (e.g. when you want to trigger an exception explicitly during evaluation and don’t want it to be swallowed by the exception handlers).

I’ve CC’ed Andrei because he knows more about UI <-> Debugger interaction. Maybe he has an idea how to do this.

OK, Thanks.

...

...

...

Two tiny things: - you’re not using the #reset method you wrote but instead manually assign nil to the variable

yes, thanks.

...

- I guess the dictionary in the handler could be a SmallDictionary. There won’t be many entries.

Well..since there will be likely.. less than 10 entries I don't care which Dictionary to use. However, I would prefer to keep Dictionary. Or if not GRSmallDictionary.

...

Thanks a lot for this. I’ll probably port this back to Seaside 2.8 so I can use it too :)

No problem. Thanks for reviewing and give feedback.

...

On Sat, Dec 5, 2015 at 11:36 AM, Max Leske <maxleske@gmail.com> wrote:

...

On 05 Dec 2015, at 12:58, Mariano Martinez Peck <marianopeck@gmail.com> wrote:

Can you try with the latest version that does not use LPC if it works?

Works perfectly!

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