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

[Michael Lucas-Smith]

Julian Fitzell wrote:
> Hi Michael,
>
> I'm in Belgium this weekend and using internet on a computer with a
> wonky keyboard and no working quicktime. So... I'll get back to you on
> this on Monday unless I find WIFI somewhere. :)
>
> To clarify, though, I was hoping we could still have a debugger open
> up in the browser, just in another tab or window (one using comet or
> polling to notice it needed to).
Yes. In WV I'd like to have the WV environment poll/comet to see if an 
exception has occurred and pop it up in a dialog box. I think that'd be 
great. Another thing we can do is have the window/tab know if it has 
focus or not. If not, make it do a ticker on the window title so that a 
developer can see there is activity thar requires attention on another 
window/tab.

But these are UI specifics that aren't required to demonstrate that the 
technique is feasible as a solution.
>  And why do you think we should get
> rid of the exception handlers (or do you mean the debugging exception
> handlers specifically?)
>   
The debugging ones specifically, but the other handlers don't add 
anything. A walkback catcher versus a debug catcher tends to be 
something you can configure in your image when you develop or deploy - 
they're different on each platform too. I don't know if there's much 
benefit to the code that exists in Seaside right now, but that's debatable.

My basic premise is this: if you're in development, a debugger is more 
useful. If you're in production, you'll probably want to log the 
exception somewhere for later debugging anyway instead of showing the 
user a bunch of gibberish. Gemstone saves the stack in their db so you 
can actually debug it later - and with the debugging technique described 
below, you can do the same without having to save it (so long as you 
don't mind the memory cost of keeping the session and objects around).. 
or you could make it email you, or you could write the stack out to 
disk, etc. I think the least useful of all these options is to show the 
stack to the user.

Cheers,
Michael
> Julian
>
> On 9/18/09, Michael Lucas-Smith <mlucas-smith at cincom.com> wrote:
>   
>> 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?
>>
>> Cheers,
>> Michael
>> _______________________________________________
>> seaside-dev mailing list
>> seaside-dev at lists.squeakfoundation.org
>> http://lists.squeakfoundation.org/mailman/listinfo/seaside-dev
>>
>>     
> _______________________________________________
> seaside-dev mailing list
> seaside-dev at lists.squeakfoundation.org
> http://lists.squeakfoundation.org/mailman/listinfo/seaside-dev
>
>