[Glass] tode and breakpoints and debugging.

Mon Oct 26 12:28:33 PDT 2015

Jon,

I would not disable native code since that may have a terrible impact in
performance. Instead, I would simply use #halt.

On Mon, Oct 26, 2015 at 4:02 PM, Jon Paynter via Glass <
glass at lists.gemtalksystems.com> wrote:

> 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
>>
>
>
> _______________________________________________
> Glass mailing list
> Glass at lists.gemtalksystems.com
> http://lists.gemtalksystems.com/mailman/listinfo/glass
>
>

-- 
Mariano
http://marianopeck.wordpress.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.gemtalksystems.com/mailman/private/glass/attachments/20151026/7b710c02/attachment-0001.html>