Smalltalk › Pharo › Pharo Smalltalk Users

Breakpoints in Pharo

_‹ Previous Topic Next Topic _›

Classic

List

Threaded

8 messages Options

Andrei Stebakov

Breakpoints in Pharo

Can I expect that break points in Pharo work in the same way as in Visual Works?

When I set a break point in Pharo (6.1 on Windows), it displays a red dot with an exclamation mark and when I send this message to an object, the debugger doesn't get invoked.

Ben Coman

Re: Breakpoints in Pharo

Hi Andrei,

On 26 December 2017 at 09:51, Andrei Stebakov <[hidden email]> wrote:

Can I expect that break points in Pharo work in the same way as in Visual Works?
When I set a break point in Pharo (6.1 on Windows), it displays a red dot with an exclamation mark and when I send this message to an object, the debugger doesn't get invoked.

Sorry I'm not familiar with VisualWorks.

If I define this method (Pharo 6.1 on Linux)...

Object >> myTest

"Object new myTest"

self halt.

self inform: 'test'.

then evaluate the comment, a debugger is invoked.

If your example is different, could you explain it in more detail?

cheers -ben

jtuchel

Re: Breakpoints in Pharo

Ben,

I don't think you can compare #halt with Breakpoints. Breakpoints have two main advantages over halts:

They do not change source code, so there is no diff between a method version with and without this debugging aid. Helps a lot, especially in times when you urgenztly need to fix a bug in production code. There's no time to read diffs that baiscally have zero meaning saturday nights at 2:00 AM...
They cannot easily be packaged into the production/runtime image, because they are not part of the source code. Thus it cannot be "forgotten" when you deploy.
This is not relevant in Pharo, where there is no packaging step as in VW or VAST, but there it really is. A halt in production code makes for a great monday morning when the new version was just shipped ;-)

So when you work on code to actually ship into users' hands, there are quite some good arguments for Breakpoints. There's more to them, like conditional Breakpoints that make debugging a bug so much easier and Watchpoints, but these would make my message way too long.

Of course all of the above-mentioned things can be achieved using appropriate handlers for #halt and add stuff to them or make #halts just ignored at deployment time, but these are also steps that can be forgotten...

Joachim

Am 27.12.17 um 00:26 schrieb Ben Coman:

Hi Andrei,

On 26 December 2017 at 09:51, Andrei Stebakov <[hidden email]> wrote:

Can I expect that break points in Pharo work in the same way as in Visual Works?
When I set a break point in Pharo (6.1 on Windows), it displays a red dot with an exclamation mark and when I send this message to an object, the debugger doesn't get invoked.

Sorry I'm not familiar with VisualWorks.

If I define this method (Pharo 6.1 on Linux)...

Object >> myTest

"Object new myTest"

self halt.

self inform: 'test'.

then evaluate the comment, a debugger is invoked.

If your example is different, could you explain it in more detail?

cheers -ben

-- 
-----------------------------------------------------------------------
Objektfabrik Joachim Tuchel          [hidden email]
Fliederweg 1                         http://www.objektfabrik.de
D-71640 Ludwigsburg                  http://joachimtuchel.wordpress.com
Telefon: +49 7141 56 10 86 0         Fax: +49 7141 56 10 86 1

kmo

Re: Breakpoints in Pharo

In reply to this post by Andrei Stebakov

Just tried it in Pharo 6.1 on Linux 32 bit. Breakpoints work. So presumably
this is a Pharo on Windows issue.

--
Sent from: http://forum.world.st/Pharo-Smalltalk-Users-f1310670.html

Nicolai Hess-3-2

Re: Breakpoints in Pharo

Works for me too (on windows).

But sometimes, a change and accept of the current method, does not removes the "Breakpoint"-Icon.

So, it looks like there is a breakpoint, but isn't anymore and the code of course does not trigger the debugger.

The icon vanishes, if I unselect and select the current method.

2017-12-27 10:27 GMT+01:00 kmo <[hidden email]>:

Just tried it in Pharo 6.1 on Linux 32 bit. Breakpoints work. So presumably
this is a Pharo on Windows issue.

--
Sent from: http://forum.world.st/Pharo-Smalltalk-Users-f1310670.html

Denis Kudriashov

Re: Breakpoints in Pharo

2017-12-27 10:37 GMT+01:00 Nicolai Hess <[hidden email]>:

Works for me too (on windows).
But sometimes, a change and accept of the current method, does not removes the "Breakpoint"-Icon.
So, it looks like there is a breakpoint, but isn't anymore and the code of course does not trigger the debugger.
The icon vanishes, if I unselect and select the current method.

I think it is fixed in Calypso

2017-12-27 10:27 GMT+01:00 kmo <[hidden email]>:
Just tried it in Pharo 6.1 on Linux 32 bit. Breakpoints work. So presumably
this is a Pharo on Windows issue.

--
Sent from: http://forum.world.st/Pharo-Smalltalk-Users-f1310670.html

Ben Coman

Re: Breakpoints in Pharo

In reply to this post by Ben Coman

On 27 December 2017 at 07:26, Ben Coman <[hidden email]> wrote:

Hi Andrei,

On 26 December 2017 at 09:51, Andrei Stebakov <[hidden email]> wrote:
Can I expect that break points in Pharo work in the same way as in Visual Works?
When I set a break point in Pharo (6.1 on Windows), it displays a red dot with an exclamation mark and when I send this message to an object, the debugger doesn't get invoked.

Sorry I'm not familiar with VisualWorks.
If I define this method (Pharo 6.1 on Linux)...
Object >> myTest
"Object new myTest"
self halt.
self inform: 'test'.

then evaluate the comment, a debugger is invoked.

If your example is different, could you explain it in more detail?

cheers -ben

By strange co-incidence, I've just experienced a similar problem, that I've never seen before.

Slightly rearranging my previous example...

Object >> myTest

"Object new myTest"

self inform: 'test'.

self halt.

evaluating the comment pops up 'test' but doesn't open a debugger at the "self halt".

It was working earlier today, but since then I had an episode which opened a large number of debug windows.

I guess it could somehow be related.

Actually its worse, Spotter doesn't show any contents,

and "1 inspect" from Playground does nothing, although that does work from the old Workspace.

All a bit strange. I'll move to fresh Image.

I can upload this Image if someone cared to give it a once over.

btw, version info...

Latest update: #60520 (64bit)

Unix built on Aug 27 2017 20:00:40 Compiler: 4.6.3

VMMaker versionString VM: 201708271955

cheers -ben

Nicolai Hess-3-2

Re: Breakpoints in Pharo

In reply to this post by Denis Kudriashov

2017-12-27 10:49 GMT+01:00 Denis Kudriashov <[hidden email]>:

2017-12-27 10:37 GMT+01:00 Nicolai Hess <[hidden email]>:
Works for me too (on windows).
But sometimes, a change and accept of the current method, does not removes the "Breakpoint"-Icon.
So, it looks like there is a breakpoint, but isn't anymore and the code of course does not trigger the debugger.
The icon vanishes, if I unselect and select the current method.

I think it is fixed in Calypso

In Nautilus, I traced this bug back to

NautilusUI>>methodModified: anAnnouncement
...

(selectedMethod = oldMethod )
                ifTrue: [
                    self sourceTextModel hasUnacceptedEdits
                        ifTrue: [
                            self forceSelectedMethod: method.
                            self updateCategoryAndMethodList.
                            self highlightCategory: method]
                        ifFalse: [

                            self selectedMethod: method.
                            self updateCategoryAndMethodList ]]
                ifFalse: [self updateCategoryAndMethodList ]                    "<<< If compiled method changed, we do not call forceSelectMethod, which would reset the icon styler"

2017-12-27 10:27 GMT+01:00 kmo <[hidden email]>:
Just tried it in Pharo 6.1 on Linux 32 bit. Breakpoints work. So presumably
this is a Pharo on Windows issue.

--
Sent from: http://forum.world.st/Pharo-Smalltalk-Users-f1310670.html