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

[Philippe Marschall]

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.

> 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?

>>>  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.

Cheers
Philippe