Re: [Pharo-users] Breakpoints in Pharo

2017-12-27 Thread Nicolai Hess
2017-12-27 10:49 GMT+01:00 Denis Kudriashov :

>
> 2017-12-27 10:37 GMT+01:00 Nicolai Hess :
>
>> 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 :
>>
>>> 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
>>>
>>>
>>
>


Re: [Pharo-users] Breakpoints in Pharo

2017-12-27 Thread Ben Coman
On 27 December 2017 at 07:26, Ben Coman  wrote:

> Hi Andrei,
>
> On 26 December 2017 at 09:51, Andrei Stebakov  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


Re: [Pharo-users] Breakpoints in Pharo

2017-12-27 Thread Denis Kudriashov
2017-12-27 10:37 GMT+01:00 Nicolai Hess :

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


Re: [Pharo-users] Breakpoints in Pharo

2017-12-27 Thread Nicolai Hess
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 :

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


Re: [Pharo-users] Breakpoints in Pharo

2017-12-27 Thread kmo
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



Re: [Pharo-users] Breakpoints in Pharo

2017-12-26 Thread jtuc...@objektfabrik.de

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 > 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:jtuc...@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



Re: [Pharo-users] Breakpoints in Pharo

2017-12-26 Thread Ben Coman
Hi Andrei,

On 26 December 2017 at 09:51, Andrei Stebakov  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


[Pharo-users] Breakpoints in Pharo

2017-12-25 Thread 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.