[Glass] tode and breakpoints and debugging.

[Jon Paynter via Glass]

Thanks for the detailed reply!

so if I understand correctly, the first task is to disable native code.
which conf files do I update?  running 'find' shows several of them:
./server/stones/seaside/extents/system.conf
./server/stones/seaside/gem.conf
./server/stones/seaside/maint.conf
./sys/default/server/gemstone/templates/gem.conf
./sys/default/server/gemstone/templates/maint.conf
./sys/default/server/gemstone/templates/system.conf

Do I update all 6? or only the first set? or some subset?


On Mon, Oct 26, 2015 at 11:15 AM, Dale Henrichs via Glass <
glass at lists.gemtalksystems.com> wrote:

> Okay I've read the follow on messages, but I'll reply here...
>
> On 10/25/2015 05:41 PM, Jon Paynter via Glass wrote:
>
>>
>> Im trying to debug some seaside code - when I try to set a break point in
>> my method, and run the method from a browser -- nothing seems to happen.  I
>> dont get a message in the browser and I cant see anything related in the
>> object log.
>>
> As Mariano points out breakpoints and native code are related ... the
> exact behavior is also a function of which version of GemStone you are
> using as bugs have been fixed along the way, but in the recent versions of
> GemStone (3.2.x) you should be able to set a breakpoint in a gem that is
> running with native code, but the breakpoint will not take effect until a
> new GsProcess instance has been created (basically when a breakpoint has
> been set in native code mode, all new GsProcess instances are run in
> interpretted mode and breakpoints will be honored) .... Mariano may
> remember some of the bugs that have been hit along the way...
>
> Now in your specific case, I am curious about how you are setting your
> breakpoints and where you are running your seaside gem.
>
> If you are running your seaside gem in your interactive tODE environment,
> then the break point should be honored (it's how I have debugged web-based
> apps in the past).
>
> If you are setting your breakpoint in you tODE gem and running Seaside in
> a separate gem, then the breakpoints are not shared automatically --- I
> assume that this is your case....
>
> You may be thinking of remote breakpoints[3], but they have to be enabled
> (see `man break remote). I did some work at the beginning of the year on
> remote breakpoints and zinc[2] ... it's when I added the `break remote`
> command to tODE, but I haven't done a lot with them since then ---- you
> have to use GemSTone 3.2.4 or later for remote breakpoints, since in
> earlier versions the "automatic resume" of a breakpoint didn't quite work
> ...
>
> If you give remote breakpoints, let me know if you have an issue or two ..
> I am giving a talk at Smalltalks in Buenos Aires in 2.5 weeks, so I am not
> going to have a lot of time to delve into detailed problems while I work on
> getting tODE, GsDevKit_home and my talk into shape:)
>
> [2] https://github.com/GsDevKit/zinc/pull/66
> [3]
> https://gemstonesoup.wordpress.com/2011/12/02/glass-101-remote-breakpoints-for-seaside-3-0/
>
>
>> to set the method breakpoint, I navigate to the method in the hierarchy
>> browser, right click & pick 'set breakpoint'.
>> Are method breakpoints working in tode?
>>
> Yes, but as noted above, they only set a breakpoint in your current gem.
>
>>
>>
>> Next I tried the old school "self halt" in my code.  That gave a message
>> in the browser, and I was able to see the continuation in the object log,
>> and start a debugger.  However I found all the debug related options (step
>> over, step into, continue, restart) -- were greyed out.   I tried modifying
>> the method i want to debug (sometimes that will get things going), but that
>> didnt work either.
>>
> As Mariano points out, debugging a continuation is pretty much only read
> only ... If you need to do interactive debugging then your best bet is to
> start the gemServer in tODE.
>
> For best results you should turn off auto commit (limit autoCommit false)
> and use manual transaction mode (eval `System transactionMode:
> #manualBegin`) so that you duplicate the environment in your seaside web
> server gem - Seaside not work quite correctly otherwise ... if you switch
> transaction modes and/or turn off autoCommit you want to remember that
> you've done so, since you'll need to remember to do a manual
> beginTransaction and/or commits and you will probably lose work a couple of
> times before remembering --- so I recommed running two separate tODE
> sessions ... one where you set breakpoints and debug the problem and the
> other where you make changes to your code (and live safely with autoCommit
> and automatic transaction mode)
>
> I've got example scripts[4] and a little document[5] on debugging
> GemServers  that will at least give you an introduction to the basic
> principles ...
>
> Dale
>
> [4] https://github.com/GsDevKit/gsApplicationTools/tree/master/tode
> [5]
> https://github.com/GsDevKit/gsApplicationTools/blob/master/docs/gettingStarted.md#gem-server-debugging
>
>
> _______________________________________________
> 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/20151026/bc6f2808/attachment.html>