haltOnce and haltOnCount

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

haltOnce and haltOnCount

Hernan Wilkinson-3
Hi, 
 when are these messages used? what are the scenarios? 
 I just want to understand why they are there...

--
Hernán Wilkinson
Agile Software Development, Teaching & Coaching
Mobile: +54 - 911 - 4470 - 7207
email: [hidden email]
site: http://www.10Pines.com


_______________________________________________
Pharo-project mailing list
[hidden email]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Reply | Threaded
Open this post in threaded view
|

Re: haltOnce and haltOnCount

Eliot Miranda-2


2010/9/30 Hernan Wilkinson <[hidden email]>
Hi, 
 when are these messages used? what are the scenarios? 
 I just want to understand why they are there...

Let's say you want to debug the debugger.  As soon as you've hit the halt you then want the debugger to stop halting otherwise you can't debug it because it'll halt all the time.  For this you need haltOnce.

HTH
Eliot


--
Hernán Wilkinson
Agile Software Development, Teaching & Coaching
Mobile: +54 - 911 - 4470 - 7207
email: [hidden email]
site: http://www.10Pines.com


_______________________________________________
Pharo-project mailing list
[hidden email]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project


_______________________________________________
Pharo-project mailing list
[hidden email]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Reply | Threaded
Open this post in threaded view
|

Re: haltOnce and haltOnCount

Alexandre Bergel
In reply to this post by Hernan Wilkinson-3
I used haltOnce quite often when I had to debug the rendering facilities in Mondrian.
Putting "self halt" in a drawOn: method can easily freeze your image.

Alexandre

 

On 30 Sep 2010, at 17:18, Hernan Wilkinson wrote:

> Hi,
>  when are these messages used? what are the scenarios?
>  I just want to understand why they are there...
>
> --
> Hernán Wilkinson
> Agile Software Development, Teaching & Coaching
> Mobile: +54 - 911 - 4470 - 7207
> email: [hidden email]
> site: http://www.10Pines.com
>
> _______________________________________________
> Pharo-project mailing list
> [hidden email]
> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

--
_,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:
Alexandre Bergel  http://www.bergel.eu
^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.






_______________________________________________
Pharo-project mailing list
[hidden email]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Reply | Threaded
Open this post in threaded view
|

Re: haltOnce and haltOnCount

Stéphane Ducasse
In reply to this post by Hernan Wilkinson-3
+ 1 really really important

On Sep 30, 2010, at 11:38 PM, Alexandre Bergel wrote:

> I used haltOnce quite often when I had to debug the rendering facilities in Mondrian.
> Putting "self halt" in a drawOn: method can easily freeze your image.
>
> Alexandre
>
>
>
> On 30 Sep 2010, at 17:18, Hernan Wilkinson wrote:
>
>> Hi,
>> when are these messages used? what are the scenarios?
>> I just want to understand why they are there...
>>
>> --
>> Hernán Wilkinson
>> Agile Software Development, Teaching & Coaching
>> Mobile: +54 - 911 - 4470 - 7207
>> email: [hidden email]
>> site: http://www.10Pines.com
>>
>> _______________________________________________
>> Pharo-project mailing list
>> [hidden email]
>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
>
> --
> _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:
> Alexandre Bergel  http://www.bergel.eu
> ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
>
>
>
>
>
>
> _______________________________________________
> Pharo-project mailing list
> [hidden email]
> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project


_______________________________________________
Pharo-project mailing list
[hidden email]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Reply | Threaded
Open this post in threaded view
|

Re: haltOnce and haltOnCount

Hernan Wilkinson-3
ah, ok, I imagine that but what it was a bit of a surprise for me is that it is implemented in Object... I mean, I know that halt is also implemented in Object and it is the natural place to implement those messages, but if we want to build a "modular" system, messages like halt, error, etc should be removed from Object and seeing that Object is growing in its responsibilities with these messages I think that goes against that path... of course, if you decided that the trade off deserves it, fine by me... 
I was thinking that halt for example could be implemented in MethodContext (or ContextPart) so you can write something like "thisContext halt" and not couple Object with Halt (of course we would be coupling MethodContext with Halt, but it is a smaller coupling)... or just remove halt as a message and force everybody to just write "Halt signal" of "Halt signalOnce" etc. I mean, why Object implements halt? I know it is handy to do "self halt" but also as handy as "Halt signal"... the only reason I see to implement halt in Object is the possibility for any subclass to override that message, but I haven't seen that in my years of smalltalker...

Anyway, just a late's Friday thought :-)

PS: A #haltIf: aBlock message would be handy too :-)



On Fri, Oct 1, 2010 at 8:53 AM, Stéphane Ducasse <[hidden email]> wrote:
+ 1 really really important

On Sep 30, 2010, at 11:38 PM, Alexandre Bergel wrote:

> I used haltOnce quite often when I had to debug the rendering facilities in Mondrian.
> Putting "self halt" in a drawOn: method can easily freeze your image.
>
> Alexandre
>
>
>
> On 30 Sep 2010, at 17:18, Hernan Wilkinson wrote:
>
>> Hi,
>> when are these messages used? what are the scenarios?
>> I just want to understand why they are there...
>>
>> --
>> Hernán Wilkinson
>> Agile Software Development, Teaching & Coaching
>> Mobile: +54 - 911 - 4470 - 7207
>> email: [hidden email]
>> site: http://www.10Pines.com
>>
>> _______________________________________________
>> Pharo-project mailing list
>> [hidden email]
>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
>
> --
> _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:
> Alexandre Bergel  http://www.bergel.eu
> ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
>
>
>
>
>
>
> _______________________________________________
> Pharo-project mailing list
> [hidden email]
> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project


_______________________________________________
Pharo-project mailing list
[hidden email]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project



--
Hernán Wilkinson
Agile Software Development, Teaching & Coaching
Mobile: +54 - 911 - 4470 - 7207
email: [hidden email]
site: http://www.10Pines.com


_______________________________________________
Pharo-project mailing list
[hidden email]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Reply | Threaded
Open this post in threaded view
|

Re: haltOnce and haltOnCount

Guillermo Polito
There is already an issue about removing that responsibility from Object.  I made a little enhancement some months ago (it was the first issue I fixed :P) but it never got integrated because it was not urgent.

http://code.google.com/p/pharo/issues/detail?id=2394&q=halt&colspec=ID%20Type%20Status%20Summary%20Milestone%20Difficulty

Cheers!

2010/10/1 Hernan Wilkinson <[hidden email]>
ah, ok, I imagine that but what it was a bit of a surprise for me is that it is implemented in Object... I mean, I know that halt is also implemented in Object and it is the natural place to implement those messages, but if we want to build a "modular" system, messages like halt, error, etc should be removed from Object and seeing that Object is growing in its responsibilities with these messages I think that goes against that path... of course, if you decided that the trade off deserves it, fine by me... 
I was thinking that halt for example could be implemented in MethodContext (or ContextPart) so you can write something like "thisContext halt" and not couple Object with Halt (of course we would be coupling MethodContext with Halt, but it is a smaller coupling)... or just remove halt as a message and force everybody to just write "Halt signal" of "Halt signalOnce" etc. I mean, why Object implements halt? I know it is handy to do "self halt" but also as handy as "Halt signal"... the only reason I see to implement halt in Object is the possibility for any subclass to override that message, but I haven't seen that in my years of smalltalker...

Anyway, just a late's Friday thought :-)

PS: A #haltIf: aBlock message would be handy too :-)



On Fri, Oct 1, 2010 at 8:53 AM, Stéphane Ducasse <[hidden email]> wrote:
+ 1 really really important

On Sep 30, 2010, at 11:38 PM, Alexandre Bergel wrote:

> I used haltOnce quite often when I had to debug the rendering facilities in Mondrian.
> Putting "self halt" in a drawOn: method can easily freeze your image.
>
> Alexandre
>
>
>
> On 30 Sep 2010, at 17:18, Hernan Wilkinson wrote:
>
>> Hi,
>> when are these messages used? what are the scenarios?
>> I just want to understand why they are there...
>>
>> --
>> Hernán Wilkinson
>> Agile Software Development, Teaching & Coaching
>> Mobile: +54 - 911 - 4470 - 7207
>> email: [hidden email]
>> site: http://www.10Pines.com
>>
>> _______________________________________________
>> Pharo-project mailing list
>> [hidden email]
>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
>
> --
> _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:
> Alexandre Bergel  http://www.bergel.eu
> ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
>
>
>
>
>
>
> _______________________________________________
> Pharo-project mailing list
> [hidden email]
> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project


_______________________________________________
Pharo-project mailing list
[hidden email]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project



--
Hernán Wilkinson
Agile Software Development, Teaching & Coaching
Mobile: +54 - 911 - 4470 - 7207
email: [hidden email]
site: http://www.10Pines.com


_______________________________________________
Pharo-project mailing list
[hidden email]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project


_______________________________________________
Pharo-project mailing list
[hidden email]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Reply | Threaded
Open this post in threaded view
|

Re: haltOnce and haltOnCount

Marcus Denker-4
In reply to this post by Stéphane Ducasse

On Oct 1, 2010, at 8:08 PM, Hernan Wilkinson wrote:

PS: A #haltIf: aBlock message would be handy too :-)

already there:

1 haltIf: [1<2].
1 haltIf: [:rec | rec isInteger].
1 haltIf: (1<2).
1 haltIf: #doIt

especially putting a symbol is very useful. e.g. you can out the selector of the test and then even
put a haltIf: into system methods called all the time. (e.g. collections).

Marcus

--
Marcus Denker  -- http://www.marcusdenker.de
INRIA Lille -- Nord Europe. Team RMoD.


_______________________________________________
Pharo-project mailing list
[hidden email]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Reply | Threaded
Open this post in threaded view
|

Re: haltOnce and haltOnCount

Hernan Wilkinson-3
cool! I didn't see it :-)

2010/10/1 Marcus Denker <[hidden email]>

On Oct 1, 2010, at 8:08 PM, Hernan Wilkinson wrote:

PS: A #haltIf: aBlock message would be handy too :-)

already there:

1 haltIf: [1<2].
1 haltIf: [:rec | rec isInteger].
1 haltIf: (1<2).
1 haltIf: #doIt

especially putting a symbol is very useful. e.g. you can out the selector of the test and then even
put a haltIf: into system methods called all the time. (e.g. collections).

Marcus

--
Marcus Denker  -- http://www.marcusdenker.de
INRIA Lille -- Nord Europe. Team RMoD.


_______________________________________________
Pharo-project mailing list
[hidden email]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project



--
Hernán Wilkinson
Agile Software Development, Teaching & Coaching
Mobile: +54 - 911 - 4470 - 7207
email: [hidden email]
site: http://www.10Pines.com


_______________________________________________
Pharo-project mailing list
[hidden email]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project