[Glass] debugging zinc server requests/responses with tode or GemTools

[Dale Henrichs]

Paul,

Option 1 is to run the server in GemTools/tODE ... the client will block,
but when you get an error you should be able to bring up a debugger on the
GemStone stack to see what is going on ... it's awkward to debug the server
running in the client because the client blocks and sometimes it is
difficult to interrupt the process and finally if Zinc doesn't do a good
job of cleaning up open sockets when you terminate the process then the
socket is left open and you have to restart your client to stop the process
form listening on the port ... however, this is really the best way to
debug infrastructure bugs ...

Hmmm, if the client debugger is not coming up then it is likely that Zinc
is catching the error and doing something with the error...

I did do some work with Zinc a month or so ago, but I don't recall all of
the details, other than I was using tODE and I was getting the debugger to
come up so that I could look at the stack ... what I don't remember is
whether or not I had to put `self halt` in strategic places (like in the
error handling code) ... I also recall that I monkeyed with the logger to
do logging to the Transcript/Object log ....

So Option 2 is to use the Object log to trace things ...

If you put Transcript shows into your code, the strings are stashed in the
object log.

If you need more than "simple print statement debugging" then you can
collect references to objects in the object log by inserting code like
(ObjectLogEntry trace: 'label' object: objectOrArrayofObjectsOfInterest)
addToLog ... then you can inspect the object log and see what's going on...

To snap off a continuation you insert code like (DebuggerLogEntry
createContinuationLabeled: 'label) addToLog which will drop a continuation
rooted in that spot into the object log ... GemTools should allow you to
debug these continuations ... with tODE I have to provide a little bit more
glue code (I've rewritten the debugger so that you can `attach` to a
process so I'll need to tinker with things to let you attach to a
continuation)

If the objectlog code is running in a separate vm then you must arrange for
a commit to take place and high up in the infrastructure, this means that
you will have to insert a commit in places where commits are not normally
done ...

There is also code floating around (in the Seaside suport code) that allows
you to dump stacks to the gem log and stash a continuation in the object
log and conditionally commit ... but if you don't ahve seaside loaded,
we'll have to spelunk for that code ...

Dale


On Wed, Jan 22, 2014 at 5:49 PM, Paul DeBruicker <pdebruic at gmail.com> wrote:

> Hi,
>
> I'm porting some working Pharo code to GemStone.  The Zinc server is
> responding with messages like:
>
> a MessageNotUnderstood occurred (error 2010), a UndefinedObject does not
> understand  #'readStream'
>
> If I prevent my code from executing it works fine so I think tis something
> I've done.  What I don't know how to do is get more information than whats
> in the message above.
>
> Since I'm not using the Seaside infrastructure I need to figure out how to
> raise an exception which brings up a debugger.  Or prints something to a
> transcript or dumps a stack into an object log.
>
>
> How can I do that with either tode or GemTools ?  Its GemStone 3.1.0.4, on
> ubuntu 12.04
>
>
> Thanks
>
> Paul
> _______________________________________________
> Glass mailing list
> Glass at lists.gemtalksystems.com
> http://lists.gemtalksystems.com/mailman/listinfo/glass
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.gemtalksystems.com/mailman/private/glass/attachments/20140122/c9027a86/attachment-0001.html>