GBS for VA Smalltalk debugging

Gemstone/S mailing list wrote

We use (our own subclass of) StsDebugger.

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.

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

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

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

Jonas

-----Original Message-----
From: GemStone-Smalltalk [mailto:[hidden email]] On Behalf Of Richard Sargent via GemStone-Smalltalk
Sent: 8. juni 2015 17:56
To: [hidden email]
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
[hidden email]
http://lists.gemtalksystems.com/mailman/listinfo/gemstone-smalltalk

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

- 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:[hidden email]] On Behalf Of Richard Sargent via GemStone-Smalltalk
Sent: 9. juni 2015 20:26
To: [hidden email]
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@.gemtalksystems

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

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

_______________________________________________
GemStone-Smalltalk mailing list
[hidden email]
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>

Gemstone/S mailing list wrote

I'll send the code for our debugger subclass to you in a separate email.

We are currently looking into upgrading to GemStone 3.2.6 and VAST 8.6.1 with GemBuilder 5.4. It will be subject to priorities, but I'm optimistic, and hope we'll upgrade within 2015.

The model object in #setBreak turned out to be a GbxMethodListBrowser at the time of the "you cannot set breakpoints in executed code" error message. I think it usually happens if you try to set breakpoints in a GemStone code browser dialog which has been open for some time (but I'm unable to reproduce consistently).

Looking forward to hearing from you about any progress on GemStone debugger fixes/enhancements.

Jonas

-----Original Message-----
From: GemStone-Smalltalk [mailto:[hidden email]] On Behalf Of Richard Sargent via GemStone-Smalltalk
Sent: 10. juni 2015 18:36
To: [hidden email]
Subject: Re: [GemStone-Smalltalk] GBS for VA Smalltalk debugging

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

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

> gemstone-smalltalk@.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@.gemtalksystems
>
>> ] On Behalf Of Richard Sargent via GemStone-Smalltalk
>> Sent: 8. juni 2015 17:56
>> To:
>
>> gemstone-smalltalk@.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@.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@.gemtalksystems

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

> GemStone-Smalltalk@.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%20
> vs%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.
_______________________________________________
GemStone-Smalltalk mailing list
[hidden email]
http://lists.gemtalksystems.com/mailman/listinfo/gemstone-smalltalk
_______________________________________________
GemStone-Smalltalk mailing list
[hidden email]
http://lists.gemtalksystems.com/mailman/listinfo/gemstone-smalltalk