tode and breakpoints and debugging.

On Sun, Oct 25, 2015 at 10:42 PM, Jon Paynter <[hidden email]> wrote:

On Sun, Oct 25, 2015 at 6:06 PM, Mariano Martinez Peck <[hidden email]> wrote:

On Sun, Oct 25, 2015 at 9:41 PM, Jon Paynter via Glass <[hidden email]> 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.

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?

Just for the record, do you have native code enabled? Also, which OS? 

Not sure on the native code.  its probably whatever tode defaults to.  Host os is windows 7 -- where pharo runs.   Gemstone/glass is running in an ubuntu 12.04 VM.

You can get it yourself by executing 'GsProcess usingNativeCode'.

 

 

 

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 far as I know, it's not possible to proceed and friends from a stored continuation. 

There was a way of doing this in GemTools, which was opening the web adaptor directly from GemTools (not on a separate gem) and that would prompt a debugger which you were able to restart, proceed, etc.... Of course, GemTools looked like "freeze" while the seaside adaptor was running since it was using same gem. 

That being said, I never used breakpoints (always #halt), so I don;t know.

Well thanks for the reply.  hopefully Dale can shed some light on things on Monday

 

--

Mariano
http://marianopeck.wordpress.com

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
[hidden email]
http://lists.gemtalksystems.com/mailman/listinfo/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 <[hidden email]> 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
[hidden email]
http://lists.gemtalksystems.com/mailman/listinfo/glass

_______________________________________________
Glass mailing list
[hidden email]
http://lists.gemtalksystems.com/mailman/listinfo/glass