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

Thu Apr 7 12:47:07 PDT 2016

On Thu, Apr 7, 2016 at 3:13 PM, Paul DeBruicker via Glass <
glass at lists.gemtalksystems.com> 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 <
>
> > marianopeck@
>
> > > 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 at .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
> Glass at lists.gemtalksystems.com
> http://lists.gemtalksystems.com/mailman/listinfo/glass
>

-- 
Mariano
http://marianopeck.wordpress.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.gemtalksystems.com/mailman/private/glass/attachments/20160407/11302801/attachment.html>