[Seaside-dev] Debugging in Seaside 3.0 (issue 340)

[Philippe Marschall]

2009/9/18, Michael Lucas-Smith <mlucas-smith at cincom.com>:
> Hi All,
>
> I'd like to kick off a (hopefully) short discussion on the direction of
> walkbacks and debugging with Seaside 3.0.
>
> There is an open issue for debugging and walkbacks, issue 340 (
> http://code.google.com/p/seaside/issues/detail?id=340 ) which points out
> that the new way exception handling works and continuations work
> basically means showing a walkback, let alone debugging, is pretty much
> impossible in the way it was done in Seaside 2.8.
>
> You cannot render during an action, so any walkback during an action
> cannot be reported to the user without great difficulty. You can render
> during the render phase, but this often leads to a mess.
>
> Julian and I had a chat at ESUG about a potential solution to debugging
> and walkbacks in Seaside 3.0. Specifically the debugging - instead of
> trying to provide a debugging solution in the web browser, we let the
> development environment handle it as per normal. This means you'll get a
> debugger pop up in the GUI. It means that in production, instead of a
> walkback, users get an Internal Server Error of some kind.
>
> So how do we debug then? We have a separate Seaside request showing a
> list of debuggable processes, which you can refresh (and probably should
> refresh itself either via comet or polling) which you can click on to
> see a walkback, terminate, debug, etc.
>
> The question was posed: could this be done and could it be portable?
>
> Tamara Kogan has twisted the WebVelocity web debugger about until it is
> demonstrable, so here is the video:
> http://dl.getdropbox.com/u/20291/Cincom%20Smalltalk/Seaside-20090918-Debugging.mov
>
> The bad news: Every Smalltalk I looked at handles how the debugger is
> opened and how you debug a process completely differently. So while the
> technique is something that can be shared around the smalltalks, the
> code itself pretty much can't be.
>
> Recommendations:
>     1) An official "technique" could be published somewhere, on the
> seaside wiki perhaps, on how to implement debugging in Seaside for each
> implementation.
>     2) The WAExceptionHandler* classes can be removed to dissuade people
> from expecting a way to do this reasonably.
>
> What do people think about this?

I'm not particularly found of it. I don't like clever process tricks.
Additionally where do you store the processes and how do you reap
them? Moreover not all platforms have a comet server. I'd rather just
open a debugger in the image, which is what your eventually going to
do anyway.

Cheers
Philippe