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.
Hi Andrei, On 26 December 2017 at 09:51, Andrei Stebakov <lispercat@gmail.com> 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
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 <lispercat@gmail.com <mailto:lispercat@gmail.com>> 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 mailto:jtuchel@objektfabrik.de 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
On 27 December 2017 at 07:26, Ben Coman <btc@openinworld.com> wrote:
Hi Andrei,
On 26 December 2017 at 09:51, Andrei Stebakov <lispercat@gmail.com> 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
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
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 <voxkmp@gmail.com>:
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
2017-12-27 10:37 GMT+01:00 Nicolai Hess <nicolaihess@gmail.com>:
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 <voxkmp@gmail.com>:
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
2017-12-27 10:49 GMT+01:00 Denis Kudriashov <dionisiydk@gmail.com>:
2017-12-27 10:37 GMT+01:00 Nicolai Hess <nicolaihess@gmail.com>:
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 <voxkmp@gmail.com>:
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
participants (6)
-
Andrei Stebakov -
Ben Coman -
Denis Kudriashov -
jtuchel＠objektfabrik.de -
kmo -
Nicolai Hess