Breakpoints in Pharo

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
8 messages Options
Reply | Threaded
Open this post in threaded view
|

Breakpoints in Pharo

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

Reply | Threaded
Open this post in threaded view
|

Re: Breakpoints in Pharo

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
Reply | Threaded
Open this post in threaded view
|

Re: Breakpoints in Pharo

jtuchel
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
Reply | Threaded
Open this post in threaded view
|

Re: Breakpoints in Pharo

kmo
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

Reply | Threaded
Open this post in threaded view
|

Re: Breakpoints in Pharo

Nicolai Hess-3-2
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


Reply | Threaded
Open this post in threaded view
|

Re: Breakpoints in Pharo

Denis Kudriashov

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



Reply | Threaded
Open this post in threaded view
|

Re: Breakpoints in Pharo

Ben Coman
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
Reply | Threaded
Open this post in threaded view
|

Re: Breakpoints in Pharo

Nicolai Hess-3-2
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