[ANN] SeasideDynamicVariablesDebugger [WAS] Re: [ANN]: WADynamicVariablesErrorHandler (let me know if I should integrate this)

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
3 messages Options
Reply | Threaded
Open this post in threaded view
|

[ANN] SeasideDynamicVariablesDebugger [WAS] Re: [ANN]: WADynamicVariablesErrorHandler (let me know if I should integrate this)

GLASS mailing list
Dear all,

This is a quick email to let you know that I pushed the code into it's ow repository with all the needed documentation:


Cheers,



On Mon, Dec 7, 2015 at 3:36 PM, Mariano Martinez Peck <[hidden email]> wrote:
Dear all,

For those that have used Seaside, and you try to debug with the Debugger, you know that upon request processing seaside uses Exceptions mechanism to always have access to the current request, error handler, etc. The way that this is done is via subclasses of WADynamicVariable:

 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.

Once inside the debugger, things get complicated. While you can restart, proceed, etc (because the process you are debugging is inside the scope of the dynamic variables),  you  cannot evaluate any piece of code that at the end use the session  or request because you get a WARequestContextNotFound kind of error. The reason is obvious: The evaluation, do-it, print-it, etc etc  you on a piece of text or via the debugger inspector, creates another closure/context which is not in the scope of the dynamic variables.

For a client, we also have custom subclasses of WADynamicVariable, for example UserContextInformation. And that means that almost every time  in the debugger I really need access to that object. 

To solve that issue, I create a project which is actually a proof of concept: Check package SeasidePharoDebugging from http://smalltalkhub.com/#!/~marianopeck/MarianoPublic
It does work for me, and if you think this could be useful for Seaside itself, I can commit it there.

The idea is very simple. I have a WADynamicVariablesErrorHandler subclass of WADebugErrorHandler. We reimplements there #handleException: in order to simply iterate all values of all dynamic variables (all WADynamicVaraible subclasses) and store those into a dictionary in a class variable of WADynamicVariablesErrorHandler. 

Then, I simply override (this is the part that must be cleared if we integrate this in Seaside) WADynamicVarible >> #defaultAction  to be something like this:

WADynamicVarible >> #defaultAction 
^ (WADynamicVariablesErrorHandler storedDynamicVariable: self class)
ifNil: [ self class defaultValue ]

That way... when we handle an exception, we save out all values into a class side. And then, in the debugger, whenever we evaluate, inspect, print etc anything that would do a #value over a WADynamicVariable subclass, it ends up calling #defaultAction (because there will be no handler in the stack) and there, we first check if the have the value for that dynamic variable. If we do, we answer that, if not, the defaultValue :)

There are tests too. There is WACurrentRequestDebuggingTest which you can try from /tests/seasidepharodebugging

For the user, there is almost nothing to do. All WADynamicVariable subclasses are managed automatically. All you need is to register the exception handler:

app filter configuration at: #exceptionHandler put: WADynamicVariablesErrorHandler.

The only drawback here is that this doesn't work with multiple debuggers as the last debugger will override the class variable values and hence the OLD already opened debuggers will be getting a wrong (the latest) value for the dynamic variables.

What do you think? I think that while it might not be the best solution and it has limits, it is every is extremely simple and does the job. 
Maybe you see problems I am not seeing? 

Let me know if do you want this integrated or not. In the meanwhile, I am loading it from my repo for my apps and keeping the override (I would like to get rid of it!!!).

Best,

--



--

_______________________________________________
Glass mailing list
[hidden email]
http://lists.gemtalksystems.com/mailman/listinfo/glass
Reply | Threaded
Open this post in threaded view
|

Re: [ANN] SeasideDynamicVariablesDebugger [WAS] Re: [ANN]: WADynamicVariablesErrorHandler (let me know if I should integrate this)

Paul DeBruicker
thanks Mariano for making and sharing this.  Have you tried it with GemStone?  I'm getting an error in some of my callback processing code and It'd be nice to be able to step through the execution on tODE.  

GLASS mailing list wrote
Dear all,

This is a quick email to let you know that I pushed the code into it's ow
repository with all the needed documentation:

https://github.com/marianopeck/SeasideDynamicVariablesDebugger

Cheers,



On Mon, Dec 7, 2015 at 3:36 PM, Mariano Martinez Peck <[hidden email]
> wrote:

> Dear all,
>
> For those that have used Seaside, and you try to debug with the Debugger,
> you know that upon request processing seaside uses Exceptions mechanism to
> always have access to the current request, error handler, etc. The way that
> this is done is via subclasses of WADynamicVariable:
>
>  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.
>
> Once inside the debugger, things get complicated. While you can restart,
> proceed, etc (because the process you are debugging is inside the scope of
> the dynamic variables),  you  cannot evaluate any piece of code that at the
> end use the session  or request because you get a WARequestContextNotFound
> kind of error. The reason is obvious: The evaluation, do-it, print-it, etc
> etc  you on a piece of text or via the debugger inspector, creates another
> closure/context which is not in the scope of the dynamic variables.
>
> For a client, we also have custom subclasses of WADynamicVariable, for
> example UserContextInformation. And that means that almost every time  in
> the debugger I really need access to that object.
>
> To solve that issue, I create a project which is actually a proof of
> concept: Check package SeasidePharoDebugging from
> http://smalltalkhub.com/#!/~marianopeck/MarianoPublic
> It does work for me, and if you think this could be useful for Seaside
> itself, I can commit it there.
>
> The idea is very simple. I have a WADynamicVariablesErrorHandler subclass
> of WADebugErrorHandler. We reimplements there #handleException: in order to
> simply iterate all values of all dynamic variables (all WADynamicVaraible
> subclasses) and store those into a dictionary in a class variable of
> WADynamicVariablesErrorHandler.
>
> Then, I simply override (this is the part that must be cleared if we
> integrate this in Seaside) WADynamicVarible >> #defaultAction  to be
> something like this:
>
> WADynamicVarible >> #defaultAction
> ^ (WADynamicVariablesErrorHandler storedDynamicVariable: self class)
> ifNil: [ self class defaultValue ]
>
> That way... when we handle an exception, we save out all values into a
> class side. And then, in the debugger, whenever we evaluate, inspect, print
> etc anything that would do a #value over a WADynamicVariable subclass, it
> ends up calling #defaultAction (because there will be no handler in the
> stack) and there, we first check if the have the value for that dynamic
> variable. If we do, we answer that, if not, the defaultValue :)
>
> There are tests too. There is WACurrentRequestDebuggingTest which you can
> try from /tests/seasidepharodebugging
>
> For the user, there is almost nothing to do. All WADynamicVariable
> subclasses are managed automatically. All you need is to register the
> exception handler:
>
> app filter configuration at: #exceptionHandler put:
> WADynamicVariablesErrorHandler.
>
> The only drawback here is that this doesn't work with multiple debuggers
> as the last debugger will override the class variable values and hence the
> OLD already opened debuggers will be getting a wrong (the latest) value for
> the dynamic variables.
>
> What do you think? I think that while it might not be the best solution
> and it has limits, it is every is extremely simple and does the job.
> Maybe you see problems I am not seeing?
>
> Let me know if do you want this integrated or not. In the meanwhile, I am
> loading it from my repo for my apps and keeping the override (I would like
> to get rid of it!!!).
>
> Best,
>
> --
> Mariano
> http://marianopeck.wordpress.com
>



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

_______________________________________________
Glass mailing list
[hidden email]
http://lists.gemtalksystems.com/mailman/listinfo/glass
Reply | Threaded
Open this post in threaded view
|

Re: [ANN] SeasideDynamicVariablesDebugger [WAS] Re: [ANN]: WADynamicVariablesErrorHandler (let me know if I should integrate this)

GLASS mailing list


On Thu, Apr 7, 2016 at 3:13 PM, Paul DeBruicker via Glass <[hidden email]> wrote:
thanks Mariano for making and sharing this. 

Hi Paul, you are welcome. 
 
Have you tried it with GemStone?

No. This is because normally I develop on Pharo. And the walkbacks I debug on GemStone are not from an interactive tODE session but they are already dead (stored in the object log) and hence they cannot even "proceed". 
But it would be cool if you make it work for GemStone. I suspect all you need is a variation of WADynamicVariablesErrorHandler which subclass from one of the GemStone error handler classes, for example, WAGemStoneWalkbackErrorHandler.

I am a bit busy right now to try myself, but let me know if I can help you somehow to make it work. 
 
I'm getting an error in some of my callback processing code and It'd be nice
to be able to step through the execution on tODE.


Of course, that's the idea :)
 

GLASS mailing list wrote
> Dear all,
>
> This is a quick email to let you know that I pushed the code into it's ow
> repository with all the needed documentation:
>
> https://github.com/marianopeck/SeasideDynamicVariablesDebugger
>
> Cheers,
>
>
>
> On Mon, Dec 7, 2015 at 3:36 PM, Mariano Martinez Peck &lt;

> marianopeck@

> &gt; wrote:
>
>> Dear all,
>>
>> For those that have used Seaside, and you try to debug with the Debugger,
>> you know that upon request processing seaside uses Exceptions mechanism
>> to
>> always have access to the current request, error handler, etc. The way
>> that
>> this is done is via subclasses of WADynamicVariable:
>>
>>  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.
>>
>> Once inside the debugger, things get complicated. While you can restart,
>> proceed, etc (because the process you are debugging is inside the scope
>> of
>> the dynamic variables),  you  cannot evaluate any piece of code that at
>> the
>> end use the session  or request because you get a
>> WARequestContextNotFound
>> kind of error. The reason is obvious: The evaluation, do-it, print-it,
>> etc
>> etc  you on a piece of text or via the debugger inspector, creates
>> another
>> closure/context which is not in the scope of the dynamic variables.
>>
>> For a client, we also have custom subclasses of WADynamicVariable, for
>> example UserContextInformation. And that means that almost every time  in
>> the debugger I really need access to that object.
>>
>> To solve that issue, I create a project which is actually a proof of
>> concept: Check package SeasidePharoDebugging from
>> http://smalltalkhub.com/#!/~marianopeck/MarianoPublic
>> It does work for me, and if you think this could be useful for Seaside
>> itself, I can commit it there.
>>
>> The idea is very simple. I have a WADynamicVariablesErrorHandler subclass
>> of WADebugErrorHandler. We reimplements there #handleException: in order
>> to
>> simply iterate all values of all dynamic variables (all WADynamicVaraible
>> subclasses) and store those into a dictionary in a class variable of
>> WADynamicVariablesErrorHandler.
>>
>> Then, I simply override (this is the part that must be cleared if we
>> integrate this in Seaside) WADynamicVarible >> #defaultAction  to be
>> something like this:
>>
>> WADynamicVarible >> #defaultAction
>> ^ (WADynamicVariablesErrorHandler storedDynamicVariable: self class)
>> ifNil: [ self class defaultValue ]
>>
>> That way... when we handle an exception, we save out all values into a
>> class side. And then, in the debugger, whenever we evaluate, inspect,
>> print
>> etc anything that would do a #value over a WADynamicVariable subclass, it
>> ends up calling #defaultAction (because there will be no handler in the
>> stack) and there, we first check if the have the value for that dynamic
>> variable. If we do, we answer that, if not, the defaultValue :)
>>
>> There are tests too. There is WACurrentRequestDebuggingTest which you can
>> try from /tests/seasidepharodebugging
>>
>> For the user, there is almost nothing to do. All WADynamicVariable
>> subclasses are managed automatically. All you need is to register the
>> exception handler:
>>
>> app filter configuration at: #exceptionHandler put:
>> WADynamicVariablesErrorHandler.
>>
>> The only drawback here is that this doesn't work with multiple debuggers
>> as the last debugger will override the class variable values and hence
>> the
>> OLD already opened debuggers will be getting a wrong (the latest) value
>> for
>> the dynamic variables.
>>
>> What do you think? I think that while it might not be the best solution
>> and it has limits, it is every is extremely simple and does the job.
>> Maybe you see problems I am not seeing?
>>
>> Let me know if do you want this integrated or not. In the meanwhile, I am
>> loading it from my repo for my apps and keeping the override (I would
>> like
>> to get rid of it!!!).
>>
>> Best,
>>
>> --
>> Mariano
>> http://marianopeck.wordpress.com
>>
>
>
>
> --
> Mariano
> http://marianopeck.wordpress.com
>
> _______________________________________________
> Glass mailing list

> Glass@.gemtalksystems

> http://lists.gemtalksystems.com/mailman/listinfo/glass





--
View this message in context: http://forum.world.st/ANN-SeasideDynamicVariablesDebugger-WAS-Re-ANN-WADynamicVariablesErrorHandler-let-me-know-if-I-shoul-tp4881484p4888902.html
Sent from the GLASS mailing list archive at Nabble.com.
_______________________________________________
Glass mailing list
[hidden email]
http://lists.gemtalksystems.com/mailman/listinfo/glass



--

_______________________________________________
Glass mailing list
[hidden email]
http://lists.gemtalksystems.com/mailman/listinfo/glass