[GemStone-Smalltalk] GBS for VA Smalltalk debugging

Richard Sargent via GemStone-Smalltalk gemstone-smalltalk at lists.gemtalksystems.com
Tue Jun 9 11:26:17 PDT 2015

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

> - 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.

More information about the GemStone-Smalltalk mailing list