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

[Dale Henrichs]

GemStone has both ui-less and ui-full modes for debugging, although the primary mode is ui-less ... a continuation is snapped off and the stack is stashed in the db (in the object log to be precise) as Michael mentioned before ... While I haven't implemented this yet, I've always imagined that there would be a process running that would clean out old entries in the Object log to keep it from growing without bounds ... 

When dealing with problems in the Seaside framework itself I resort to the standard technique of bringing up a a debugger in the ui...

I'm riffing now, but presumably all platforms are able to suspend a process and I assume that all platforms have a way of bringing up a debugger on a suspended process ... so at a minimum I would think that a generic handler could be written that suspends the offensive process on an error, stashes the process in a platform-specific collection (via SeasidePlatform) and arranges for an error response to be returned .... the process could go into a queue, that is being polled or could cause a debugger to be opened, or could be logged into a log file and dropped on the floor ... 

Dale
----- "Michael Lucas-Smith" <mlucas-smith at cincom.com> wrote:

| 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
| _______________________________________________
| seaside-dev mailing list
| seaside-dev at lists.squeakfoundation.org
| http://lists.squeakfoundation.org/mailman/listinfo/seaside-dev