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

[Michael Lucas-Smith]

Philippe Marschall wrote:
> 2009/9/20, Michael Lucas-Smith <mlucas-smith at cincom.com>:
>   
>> Lukas Renggli wrote:
>>     
>>>>> 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.
>>>>
>>>>         
>> Clever process tricks is what used to happen in Seaside 2.8. Now it's
>> not doing anything clever at all.
>> In VisualWorks, when an exception is unhandled, a DebuggerService is
>> created for the process and a DebuggerClient opens up on it. The
>> DebuggerService provides all the controls to manipulate the process.
>>     
>
> We don't have those fancy classes in Pharo.
>   
Exactly the problem - there are different classes in GST, VA, Dolphin. 
This area of Smalltalk is anything but standard.
>   
>> The two options are: let the GUI show the debugger, which is fine for
>> most cases. Capture the service in a collection and let a web page show
>> the debugger - which is the technique I described above.
>>     
>>>> Additionally where do you store the processes and how do you reap
>>>> them?
>>>>         
>> They go in to a collection, you either reap them when you're done
>> debugging (resume or terminate) or you can terminate them before you
>> debug. That's the same as the GUI is right now, which pops up a debug
>> dialog asking you what you want to do with it.
>>     
>
> Where is that collection? How do you remove stuff from this
> collection, do you have to debug every exception? How do you keep this
> collection from filling up and preventing stuff from being released?
>   
The collection is on our WebDebuggerService right now. No you don't have 
to debug every exception. It's the same as having the dialog box pop up 
later, except in a list. Given that it's our list, we could even drop 
"old" services if people cared. Run away masses of exceptions are a mess 
in the GUI anyway.
>>>>  Moreover not all platforms have a comet server.
>>>>         
>> Right, as I said before, the debugging code is platform specific anyway,
>> there's basically nothing reusable - except for the technique itself.
>> Polling is just as acceptable, but there's no reasonable spot in the
>> regular seaside to start polling or cometing for debug exceptions. My
>> preference would be for seaside to not attempt to be a debugger at all -
>> but for us to merely say "and this is how you can implement web
>> debugging if you want to"
>>     
>>>>  I'd rather just
>>>> open a debugger in the image, which is what your eventually going to
>>>> do anyway.
>>>>
>>>>         
>> Except if you don't have a GUI.
>>     
>
> But we do.
>   
VisualWorks, ObjectStudio, Pharo, Squeak, VisualAge, Dolphin all do - 
WebVelocity doesn't.
Is WV unique in this or are other projects interested in ui-less 
development too?

Anyway - we're saying the same thing. There is a technique to do web 
debugging with Seaside that isn't intrusive and isn't required.

I believe all we need to do for issue 340 is to remove the debugger 
handlers? Julian?

Michael