[GemStone-Smalltalk] GBS for VA Smalltalk debugging

Wed Jun 10 09:35:50 PDT 2015

Gemstone/S mailing list wrote
> 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).

Please share these with me, if you would.

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

It requires a fix in both VA and in GBS. The VA fix is a prerequisite. I'll
see about back-porting my 5.4.3 changes into 5.3.2. I suggest you open an HR
requesting fixes for the specific items you want. 

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

Thanks!

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

This comes from the server. I suggest you check how the latest 2.4 release
works in this respect. It's 2.4.6 (you said you were on 2.4.3). If it is
still wrong in 2.4.6, I suggest you report it in an HR.
(And I have to ask: What are your plans for moving to 3.x?)

> - 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've seen things like this. I'm not sure I can address them. I *think* the
issue arises from the fact that the VA debugger is designed to be
synchronous, but getting information from the server is not. Scintilla
really highlights this aspect.

> 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 :-)

The message is displayed from GbxToolWindow>>#setBreak. I suspect the
browser's model is not a Method Holder. (And someone decided that all
objects should respond to #selector!) I suggest you add a breakpoint in this
method to find out what the model is when the message would come up.

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

> gemstone-smalltalk-bounces at .gemtalksystems

> ] On Behalf Of Richard Sargent via GemStone-Smalltalk
> Sent: 9. juni 2015 20:26
> To: 

> gemstone-smalltalk at .gemtalksystems

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

> http://lists.gemtalksystems.com/mailman/listinfo/gemstone-smalltalk
> 
> _______________________________________________
> GemStone-Smalltalk mailing list

> GemStone-Smalltalk at .gemtalksystems

> http://lists.gemtalksystems.com/mailman/listinfo/gemstone-smalltalk
> 
> 
> GemStone debugging vs VAST debugging (GemStoneDebuggingExample1).docx
> (1001K)
> <http://forum.world.st/attachment/4831453/0/GemStone%20debugging%20vs%20VAST%20debugging%20%28GemStoneDebuggingExample1%29.docx>

--
View this message in context: http://forum.world.st/GBS-for-VA-Smalltalk-debugging-tp4830988p4831461.html
Sent from the Gemstone/S mailing list archive at Nabble.com.