[GemStone-Smalltalk] GBS for VA Smalltalk debugging

Wed Jun 10 04:05:43 PDT 2015

The functions in our StsDebugger subclass SaraDebugger:
- "Open in Organizer" on the variables menu.
- "Reconnect to server" on the stack menu (we've had network issues which would terminate server connection every now and then).
- "Inspect this debugger" on the file menu.
- #gbxExecuteOnBehalfOfSelectedProcess: is overridden to handle our own application semaphore in addition to GBS semaphores.
- Modifications to auto-frame-selection (I'm not sure about the details here).
- Handling GbxMethod a few places (sending #gbxSelector instead of #selector).
- Image details in the debugger title.

Thanks for raising the "through" and "to cursor" issues with Instantiations. Hope to see a fix in coming releases. It could really speed up the debugging process.

I've created an example for the differences in the "over" function in VAST and in GemStone debugging. Screen shots and sample code is included in the enclosed Word document. It also shows differences in source code selection, and problems with stack frame context ("over" stepping into Collection>>#do: implementation and "^aValue" returning to client code).

Working with this example, another couple of issues was brought to my mind again:
- When the selected frame is block execution (ex: "[] in GemStoneDebuggingExample1..."), "self" is the block. In the client, self is the instance that the source code in the block refers to, and that makes debugging easier. Often, you'll have another stack frame with the appropriate "self", but it makes debugging less efficient.
- There seems to be a refresh issue with the "self" variable on GemStone. Every now and then, we'll get the wrong "self" when inspecting self in the variables pane. It can be fixed by selecting the stack frame over again, and then inspecting "self" over again.

I'm unable to see any pattern in when we receive the " you cannot set breakpoints in executed code" error message, but it happens occasionally when trying to set breakpoints in normal GemStone methods. I think it's usually solved by opening another GemStone code browser. It happened over and over again yesterday, but not today :-)

Jonas

-----Original Message-----
From: GemStone-Smalltalk [mailto:gemstone-smalltalk-bounces at lists.gemtalksystems.com] On Behalf Of Richard Sargent via GemStone-Smalltalk
Sent: 9. juni 2015 20:26
To: gemstone-smalltalk at lists.gemtalksystems.com
Subject: Re: [GemStone-Smalltalk] GBS for VA Smalltalk debugging

Gemstone/S mailing list wrote
> We use (our own subclass of) StsDebugger. 

I'm curious about why you needed a new subclass. What functions did you add?

> We really love the seamless client/server debugging capabilities 
> (stack frames from the client image and the GemStone server in the 
> same debugger). It's really powerful.
> 
> We are using VAST 8.0.2 and GemStone 64-bit 2.4.3. GemBuilder 5.3.
> 
> Since you're interested in experiences with the GemStone debugging 
> support, here are a few issues that has a great impact on GemStone 
> debugging (note that we're not using the latest versions):
> - The "through" and "to cursor" buttons don't work when debugging 
> GemStone code.

There are some problems with how this was done in the StsDebugger compared to how the superclass does things. I've raised the issue with Instantiations and I hope we'll see a patch before too much longer.

That being said, GBS 5.3 does not include any support for the added functions in the StsDebugger.

> - Sometimes, each "over" step takes a long time (a second or two). But 
> sometimes it's really fast. We haven't seen any pattern in when it's 
> fast and when it's slow.
> - The "over" button always goes into blocks/loops, whereas in client 
> code, the "over" button executes the whole block/loop in one step (and 
> you can use "through" to step into the block).

I haven't noticed this in the 5.4 branch (where I have been working recently to provide support for our upcoming 3.3 server release). I know some blocks are actually optimized. If you can provide an example case, I will look into it.

> - Combined, these glitches make GemStone debugging a lot slower than 
> client debugging.
> (- And it would help if the source code selection of the next 
> statement to be executed was more like the client).

Can you elaborate on the source code selection issue? Again, I didn't see anything wrong while working on 5.4.3.

> - Every now and then, we get an error message when trying to set
> breakpoints: "you cannot set breakpoints in executed code". What does 
> that mean?

Executed code is the code sent to the server to be executed. It is analogous to the client's do-it code, for which you get a similar message.

> Jonas
> 
> -----Original Message-----
> From: GemStone-Smalltalk [mailto:

> gemstone-smalltalk-bounces at .gemtalksystems

> ] On Behalf Of Richard Sargent via GemStone-Smalltalk
> Sent: 8. juni 2015 17:56
> To: 

> gemstone-smalltalk at .gemtalksystems

> Subject: [GemStone-Smalltalk] GBS for VA Smalltalk debugging
> 
> I am looking for information on what debuggers people use in VA 
> Smalltalk and why they use the ones they do. This information will 
> help me plan how GBS (GemBuilder for Smalltalk) will need to change.
> 
> If I understand correctly, there are three debuggers one might use:
> - the basic, original IBM Smalltalk debugger named DbgDebugger
> - Server Smalltalk debugger (SstDebugger?)
> - Instantiations' debugger (StsDebugger)
> 
> I believe that everyone would prefer the StsDebugger over the DbgDebugger.
> I don't know how the SstDebugger fits in anyone's work, and whether 
> anyone using Server Smalltalk would even use a GemStone database at all.
> 
> Thank you for your feedback.
> Richard
> _______________________________________________
> GemStone-Smalltalk mailing list

> GemStone-Smalltalk at .gemtalksystems

> http://lists.gemtalksystems.com/mailman/listinfo/gemstone-smalltalk

--
View this message in context: http://forum.world.st/GBS-for-VA-Smalltalk-debugging-tp4830988p4831272.html
Sent from the Gemstone/S mailing list archive at Nabble.com.
_______________________________________________
GemStone-Smalltalk mailing list
GemStone-Smalltalk at lists.gemtalksystems.com
http://lists.gemtalksystems.com/mailman/listinfo/gemstone-smalltalk
-------------- next part --------------
A non-text attachment was scrubbed...
Name: GemStone debugging vs VAST debugging (GemStoneDebuggingExample1).docx
Type: application/vnd.openxmlformats-officedocument.wordprocessingml.document
Size: 749703 bytes
Desc: GemStone debugging vs VAST debugging (GemStoneDebuggingExample1).docx
URL: <http://lists.gemtalksystems.com/mailman/private/gemstone-smalltalk/attachments/20150610/55c54d93/attachment-0001.docx>