Halt
Locked
12
12
 
Administrator
|
The halt code is a mess. There are several open issues and should be several more. Here's what I found today...
1. Object>>setHaltOnce and friends are misleading See http://code.google.com/p/pharo/issues/detail?id=2621 All the accessors for the global HaltOnce are on the instance side of Object, making it unclear whether haltOnce and especially haltOnCount: are per-object or global. I suggest they be moved to some object representing the system (like SmalltalkImage or a delegate - I know we're trying to clean SmalltalkImage). #haltOnce Smalltalk haltOnceEnabled "used to be self haltOnceEnabled" ifTrue: [Smalltalk clearHaltOnce. "used to be self clearHaltOnce" ^ self halt]. makes it obvious that this is a global property, not per-instance. The first requires a comment (as indicated by the pending issue), the second is documented by the code. 2. Using Object to halt causes bloat, and doesn't buy much (except that's how we've always done it). See http://code.google.com/p/pharo/issues/detail?id=2394 for a proposal to change from "self haltOnce" to Halt once. 3. Is anyone using the versions that take a string message (e.g. #haltOnce:). A halt brings you into a debugger, so is the extra info worth the added complexity? p.s. right now, the versions are cut-and-pastes of each other I've already started to clean all this up and write tests, but wanted to be clear what the right direction is. Cheers, Sean
Cheers,
Sean |
|
|
On Aug 28, 2011, at 7:24 PM, Sean P. DeNigris wrote: > > 2. Using Object to halt causes bloat, and doesn't buy much (except that's > how we've always done it). Back in the days, we were virtually crucified for introducing the Beeper class along the same reasoning... The Beeper actually got very depressed due to having his very existance being questioned. "I am just the result of a random refactoring" he was complaining "maybe I should just just delete myself and everyone will be happy". (you know, reflection *is* dangerous! There has been a lot of talk to make reflection more secure... for a reason!). To cheer him up, I gave him the lead role in a real, peer reviewed Paper: http://scg.unibe.ch/archive/papers/Denk08bMetaContextLNBIP.pdf The Beeper thus was the first Class to be really "Meta" in the history of Objects. What a thrill. In an interview, the Beeper said: "You know, being meta is hard to decribe... Classes claim to be Meta all the time. But I doubt they ever really are Meta. Being Meta is special. The whole System looks different when meta!" ;-) -- Marcus Denker -- http://marcusdenker.de |
|
|
We have a class Halt and the class-side is empty. This seems to be the
right place to hold all the code in the protocols #debugging and #debuggin-haltonce of Object. With a few renames we could get a really nice DSL: Halt now. Halt if: a = 2. Halt once. Lukas On 28 August 2011 19:47, Marcus Denker <[hidden email]> wrote: > > On Aug 28, 2011, at 7:24 PM, Sean P. DeNigris wrote: > >> >> 2. Using Object to halt causes bloat, and doesn't buy much (except that's >> how we've always done it). > > > Back in the days, we were virtually crucified for introducing the Beeper class along the > same reasoning... > > The Beeper actually got very depressed due to having his very existance being > questioned. > > "I am just the result of a random refactoring" he was complaining "maybe I should just > just delete myself and everyone will be happy". > > (you know, reflection *is* dangerous! There has been a lot of talk to make reflection more > secure... for a reason!). > > To cheer him up, I gave him the lead role in a real, peer reviewed Paper: > > http://scg.unibe.ch/archive/papers/Denk08bMetaContextLNBIP.pdf > > The Beeper thus was the first Class to be really "Meta" in the history of > Objects. What a thrill. In an interview, the Beeper said: "You know, being meta is hard > to decribe... Classes claim to be Meta all the time. But I doubt they ever really are Meta. Being > Meta is special. The whole System looks different when meta!" > > ;-) > > -- > Marcus Denker -- http://marcusdenker.de > > > -- Lukas Renggli www.lukas-renggli.ch |
|
|
In reply to this post by Marcus Denker-4
On Aug 28, 2011, at 8:10 PM, Lukas Renggli wrote: > We have a class Halt and the class-side is empty. This seems to be the > right place to hold all the code in the protocols #debugging and > #debuggin-haltonce of Object. With a few renames we could get a really > nice DSL: > > Halt now. > Halt if: a = 2. > Halt once. > Nice! I want that. This would even allow for making the #haltIf: less overloaded and provide a explicit control flow based halt with something like this: Halt selector: #DoIt. or maybe better: Halt ifCalledFrom: #testMyWonderfulBuggyTest Marcus -- Marcus Denker -- http://marcusdenker.de |
|
|
In reply to this post by Marcus Denker-4
On Sun, Aug 28, 2011 at 7:47 PM, Marcus Denker <[hidden email]> wrote:
> Back in the days, we were virtually crucified for introducing the Beeper class along the > same reasoning... > > The Beeper actually got very depressed due to having his very existance being > questioned. > > "I am just the result of a random refactoring" he was complaining "maybe I should just > just delete myself and everyone will be happy". > > (you know, reflection *is* dangerous! There has been a lot of talk to make reflection more > secure... for a reason!). > > To cheer him up, I gave him the lead role in a real, peer reviewed Paper: > > http://scg.unibe.ch/archive/papers/Denk08bMetaContextLNBIP.pdf > > The Beeper thus was the first Class to be really "Meta" in the history of > Objects. What a thrill. In an interview, the Beeper said: "You know, being meta is hard > to decribe... Classes claim to be Meta all the time. But I doubt they ever really are Meta. Being > Meta is special. The whole System looks different when meta!" Thank you Marcus, it is very funny :-) -- Damien Cassou http://damiencassou.seasidehosting.st "Lambdas are relegated to relative obscurity until Java makes them popular by not having them." James Iry |
|
|
In reply to this post by Lukas Renggli
and we could keep all the Object method in a extension of the halt packages and just some of them as forward to Halt.
I know that there was an attempt on the inbox to do that. But I was worried that people will complain. Now cleaning Object would be nice. Stef On Aug 28, 2011, at 8:10 PM, Lukas Renggli wrote: > We have a class Halt and the class-side is empty. This seems to be the > right place to hold all the code in the protocols #debugging and > #debuggin-haltonce of Object. With a few renames we could get a really > nice DSL: > > Halt now. > Halt if: a = 2. why not Halt ifTrue: [a = 2]. ? two questions in my questions :) [] and True: > Halt once. > > Lukas > > > On 28 August 2011 19:47, Marcus Denker <[hidden email]> wrote: >> >> On Aug 28, 2011, at 7:24 PM, Sean P. DeNigris wrote: >> >>> >>> 2. Using Object to halt causes bloat, and doesn't buy much (except that's >>> how we've always done it). >> >> >> Back in the days, we were virtually crucified for introducing the Beeper class along the >> same reasoning... >> >> The Beeper actually got very depressed due to having his very existance being >> questioned. >> >> "I am just the result of a random refactoring" he was complaining "maybe I should just >> just delete myself and everyone will be happy". >> >> (you know, reflection *is* dangerous! There has been a lot of talk to make reflection more >> secure... for a reason!). >> >> To cheer him up, I gave him the lead role in a real, peer reviewed Paper: >> >> http://scg.unibe.ch/archive/papers/Denk08bMetaContextLNBIP.pdf >> >> The Beeper thus was the first Class to be really "Meta" in the history of >> Objects. What a thrill. In an interview, the Beeper said: "You know, being meta is hard >> to decribe... Classes claim to be Meta all the time. But I doubt they ever really are Meta. Being >> Meta is special. The whole System looks different when meta!" >> >> ;-) >> >> -- >> Marcus Denker -- http://marcusdenker.de >> >> >> > > > > -- > Lukas Renggli > www.lukas-renggli.ch > |
|
|
On Mon, Aug 29, 2011 at 9:29 AM, Stéphane Ducasse
<[hidden email]> wrote: > Halt ifTrue: [a = 2]. > > two questions in my questions :) > [] and True: why would you need a block here? The expression is going to be evaluated once and only once: if the expression is true than a debugger pops up otherwise nothing happens. #if is shorted than #ifTrue and closer to English: "please halt if the variable a equals 2" -- Damien Cassou http://damiencassou.seasidehosting.st "Lambdas are relegated to relative obscurity until Java makes them popular by not having them." James Iry |
|
|
In reply to this post by Stéphane Ducasse
On Mon, 29 Aug 2011, Stéphane Ducasse wrote:
> and we could keep all the Object method in a extension of the halt packages and just some of them as forward to Halt. > > I know that there was an attempt on the inbox to do that. But I was worried that people will complain. > Now cleaning Object would be nice. > > Stef > > On Aug 28, 2011, at 8:10 PM, Lukas Renggli wrote: > >> We have a class Halt and the class-side is empty. This seems to be the >> right place to hold all the code in the protocols #debugging and >> #debuggin-haltonce of Object. With a few renames we could get a really >> nice DSL: >> >> Halt now. >> Halt if: a = 2. > > why not > Halt ifTrue: [a = 2]. > > ? > > two questions in my questions :) > [] and True: that, then you have to: - remove the optimization which will result in worse performance and will break code that assumes this method is atomic - or you have to change the compiler to generate extra bytecodes which will perform the real message send when the receiver is not a boolean and change the VM to not send the message in specialObjectsArray (currently #mustBeBoolean), but execute those extra bytecodes - or you have to change the handling of NonBooleanReceiver, use the decompiler to find out what has to be sent to who, etc. Btw Halt if: a = 2 is much more readable IMHO. Levente > >> Halt once. >> >> Lukas >> >> >> On 28 August 2011 19:47, Marcus Denker <[hidden email]> wrote: >>> >>> On Aug 28, 2011, at 7:24 PM, Sean P. DeNigris wrote: >>> >>>> >>>> 2. Using Object to halt causes bloat, and doesn't buy much (except that's >>>> how we've always done it). >>> >>> >>> Back in the days, we were virtually crucified for introducing the Beeper class along the >>> same reasoning... >>> >>> The Beeper actually got very depressed due to having his very existance being >>> questioned. >>> >>> "I am just the result of a random refactoring" he was complaining "maybe I should just >>> just delete myself and everyone will be happy". >>> >>> (you know, reflection *is* dangerous! There has been a lot of talk to make reflection more >>> secure... for a reason!). >>> >>> To cheer him up, I gave him the lead role in a real, peer reviewed Paper: >>> >>> http://scg.unibe.ch/archive/papers/Denk08bMetaContextLNBIP.pdf >>> >>> The Beeper thus was the first Class to be really "Meta" in the history of >>> Objects. What a thrill. In an interview, the Beeper said: "You know, being meta is hard >>> to decribe... Classes claim to be Meta all the time. But I doubt they ever really are Meta. Being >>> Meta is special. The whole System looks different when meta!" >>> >>> ;-) >>> >>> -- >>> Marcus Denker -- http://marcusdenker.de >>> >>> >>> >> >> >> >> -- >> Lukas Renggli >> www.lukas-renggli.ch >> > > > |
|
|
2011/8/29 Levente Uzonyi <[hidden email]>
Hi Levente,
I did not get this interesting point. I know that ifTrue: ... messages are optimized with special bytecodes. But, implementing Halt class>>ifTrue: would work. What am I missing? Thanks, Luc If you want to enable that, then you have to:
|
|
|
In reply to this post by Levente Uzonyi-2
2011/8/29 Levente Uzonyi <[hidden email]>:
> Currently you can't send #ifTrue: to any object. Looks like it works on Pharo 1.3. I created a class with an #ifTrue: method and I can call it without problem -- Damien Cassou http://damiencassou.seasidehosting.st "Lambdas are relegated to relative obscurity until Java makes them popular by not having them." James Iry |
|
|
In reply to this post by Levente Uzonyi-2
>
>> and we could keep all the Object method in a extension of the halt packages and just some of them as forward to Halt. >> >> I know that there was an attempt on the inbox to do that. But I was worried that people will complain. >> Now cleaning Object would be nice. >> >> Stef >> >> On Aug 28, 2011, at 8:10 PM, Lukas Renggli wrote: >> >>> We have a class Halt and the class-side is empty. This seems to be the >>> right place to hold all the code in the protocols #debugging and >>> #debuggin-haltonce of Object. With a few renames we could get a really >>> nice DSL: >>> >>> Halt now. >>> Halt if: a = 2. >> >> why not >> Halt ifTrue: [a = 2]. >> >> ? >> >> two questions in my questions :) >> [] and True: > > Currently you can't send #ifTrue: to any object. If you want to enable that, then you have to: > - remove the optimization which will result in worse performance and will break code that assumes this method is atomic > - or you have to change the compiler to generate extra bytecodes which will perform the real message send when the receiver is not a boolean and change the VM to not send the message in specialObjectsArray (currently #mustBeBoolean), but execute those extra bytecodes > - or you have to change the handling of NonBooleanReceiver, use the decompiler to find out what has to be sent to who, etc. > > Btw Halt if: a = 2 is much more readable IMHO. I agree I was curious and waking up. |
|
|
In reply to this post by Luc Fabresse
> Currently you can't send #ifTrue: to any object.
> > I did not get this interesting point. > I know that ifTrue: ... messages are optimized with special bytecodes. > But, implementing Halt class>>ifTrue: would work. > What am I missing? > > Thanks, Luc indeed ifTrue: is handled specially by the compiler. The problem is that it would have to get changed if we wanted to have something else. BTW I found strange that the following does not refer to 'plop' in a way or another. foo self ifTrue: ['plop'] 13 <70> self 14 <87> pop 15 <78> returnSelf |
|
|
In reply to this post by Damien Cassou
How?
because I get Foo new ifTrue: ['sss'] mustBeABoolean On Aug 29, 2011, at 10:50 AM, Damien Cassou wrote: > 2011/8/29 Levente Uzonyi <[hidden email]>: >> Currently you can't send #ifTrue: to any object. > > Looks like it works on Pharo 1.3. I created a class with an #ifTrue: > method and I can call it without problem > > -- > Damien Cassou > http://damiencassou.seasidehosting.st > > "Lambdas are relegated to relative obscurity until Java makes them > popular by not having them." James Iry > |
|
|
In reply to this post by Levente Uzonyi-2
2011/8/29 Levente Uzonyi <[hidden email]>:
> On Mon, 29 Aug 2011, Stéphane Ducasse wrote: > >> and we could keep all the Object method in a extension of the halt >> packages and just some of them as forward to Halt. >> >> I know that there was an attempt on the inbox to do that. But I was >> worried that people will complain. >> Now cleaning Object would be nice. >> >> Stef >> >> On Aug 28, 2011, at 8:10 PM, Lukas Renggli wrote: >> >>> We have a class Halt and the class-side is empty. This seems to be the >>> right place to hold all the code in the protocols #debugging and >>> #debuggin-haltonce of Object. With a few renames we could get a really >>> nice DSL: >>> >>> Halt now. >>> Halt if: a = 2. >> >> why not >> Halt ifTrue: [a = 2]. >> >> ? >> >> two questions in my questions :) >> [] and True: > > Currently you can't send #ifTrue: to any object. If you want to enable that, > then you have to: > - remove the optimization which will result in worse performance and will > break code that assumes this method is atomic > - or you have to change the compiler to generate extra bytecodes which will > perform the real message send when the receiver is not a boolean and change > the VM to not send the message in specialObjectsArray (currently > #mustBeBoolean), but execute those extra bytecodes > - or you have to change the handling of NonBooleanReceiver, use the > decompiler to find out what has to be sent to who, etc. > > Btw Halt if: a = 2 is much more readable IMHO. > > > Levente > More exactly, you can't send #ifTrue: with a block argument. If you use anything else but a block, the compiler will use a normal message send (at least in Squeak, can't remember if it was ported to Pharo). For example: (Halt ifTrue: [a = 2] yourself) would be possible (but block is useless in this case as already said) Nicolas >> >>> Halt once. >>> >>> Lukas >>> >>> >>> On 28 August 2011 19:47, Marcus Denker <[hidden email]> wrote: >>>> >>>> On Aug 28, 2011, at 7:24 PM, Sean P. DeNigris wrote: >>>> >>>>> >>>>> 2. Using Object to halt causes bloat, and doesn't buy much (except >>>>> that's >>>>> how we've always done it). >>>> >>>> >>>> Back in the days, we were virtually crucified for introducing the Beeper >>>> class along the >>>> same reasoning... >>>> >>>> The Beeper actually got very depressed due to having his very existance >>>> being >>>> questioned. >>>> >>>> "I am just the result of a random refactoring" he was complaining "maybe >>>> I should just >>>> just delete myself and everyone will be happy". >>>> >>>> (you know, reflection *is* dangerous! There has been a lot of talk to >>>> make reflection more >>>> secure... for a reason!). >>>> >>>> To cheer him up, I gave him the lead role in a real, peer reviewed >>>> Paper: >>>> >>>> http://scg.unibe.ch/archive/papers/Denk08bMetaContextLNBIP.pdf >>>> >>>> The Beeper thus was the first Class to be really "Meta" in the history >>>> of >>>> Objects. What a thrill. In an interview, the Beeper said: "You know, >>>> being meta is hard >>>> to decribe... Classes claim to be Meta all the time. But I doubt they >>>> ever really are Meta. Being >>>> Meta is special. The whole System looks different when meta!" >>>> >>>> ;-) >>>> >>>> -- >>>> Marcus Denker -- http://marcusdenker.de >>>> >>>> >>>> >>> >>> >>> >>> -- >>> Lukas Renggli >>> www.lukas-renggli.ch >>> >> >> > |
|
|
In reply to this post by Luc Fabresse
Anyway, (Halt ifTrue: a = 2) does not make it. We all expect the
ifTrue: condition to lie left of the message... So Halt if: a = 2, or Halt when: a = 2 are far better selectors IMO. Nicolas 2011/8/29 Luc Fabresse <[hidden email]>: > > 2011/8/29 Levente Uzonyi <[hidden email]> >> >> On Mon, 29 Aug 2011, Stéphane Ducasse wrote: >> >>> and we could keep all the Object method in a extension of the halt >>> packages and just some of them as forward to Halt. >>> >>> I know that there was an attempt on the inbox to do that. But I was >>> worried that people will complain. >>> Now cleaning Object would be nice. >>> >>> Stef >>> >>> On Aug 28, 2011, at 8:10 PM, Lukas Renggli wrote: >>> >>>> We have a class Halt and the class-side is empty. This seems to be the >>>> right place to hold all the code in the protocols #debugging and >>>> #debuggin-haltonce of Object. With a few renames we could get a really >>>> nice DSL: >>>> >>>> Halt now. >>>> Halt if: a = 2. >>> >>> why not >>> Halt ifTrue: [a = 2]. >>> >>> ? >>> >>> two questions in my questions :) >>> [] and True: > > > Hi Levente, > >> >> Currently you can't send #ifTrue: to any object. > > I did not get this interesting point. > I know that ifTrue: ... messages are optimized with special bytecodes. > But, implementing Halt class>>ifTrue: would work. > What am I missing? > > Thanks, > > Luc > >> >> If you want to enable that, then you have to: >> - remove the optimization which will result in worse performance and will >> break code that assumes this method is atomic >> - or you have to change the compiler to generate extra bytecodes which >> will perform the real message send when the receiver is not a boolean and >> change the VM to not send the message in specialObjectsArray (currently >> #mustBeBoolean), but execute those extra bytecodes >> - or you have to change the handling of NonBooleanReceiver, use the >> decompiler to find out what has to be sent to who, etc. > > > > > > >> >> Btw Halt if: a = 2 is much more readable IMHO. >> >> >> Levente >> >>> >>>> Halt once. >>>> >>>> Lukas >>>> >>>> >>>> On 28 August 2011 19:47, Marcus Denker <[hidden email]> wrote: >>>>> >>>>> On Aug 28, 2011, at 7:24 PM, Sean P. DeNigris wrote: >>>>> >>>>>> >>>>>> 2. Using Object to halt causes bloat, and doesn't buy much (except >>>>>> that's >>>>>> how we've always done it). >>>>> >>>>> >>>>> Back in the days, we were virtually crucified for introducing the >>>>> Beeper class along the >>>>> same reasoning... >>>>> >>>>> The Beeper actually got very depressed due to having his very existance >>>>> being >>>>> questioned. >>>>> >>>>> "I am just the result of a random refactoring" he was complaining >>>>> "maybe I should just >>>>> just delete myself and everyone will be happy". >>>>> >>>>> (you know, reflection *is* dangerous! There has been a lot of talk to >>>>> make reflection more >>>>> secure... for a reason!). >>>>> >>>>> To cheer him up, I gave him the lead role in a real, peer reviewed >>>>> Paper: >>>>> >>>>> http://scg.unibe.ch/archive/papers/Denk08bMetaContextLNBIP.pdf >>>>> >>>>> The Beeper thus was the first Class to be really "Meta" in the history >>>>> of >>>>> Objects. What a thrill. In an interview, the Beeper said: "You know, >>>>> being meta is hard >>>>> to decribe... Classes claim to be Meta all the time. But I doubt they >>>>> ever really are Meta. Being >>>>> Meta is special. The whole System looks different when meta!" >>>>> >>>>> ;-) >>>>> >>>>> -- >>>>> Marcus Denker -- http://marcusdenker.de >>>>> >>>>> >>>>> >>>> >>>> >>>> >>>> -- >>>> Lukas Renggli >>>> www.lukas-renggli.ch >>>> >>> >>> > > |
|
Administrator
|
In reply to this post by Sean P. DeNigris
What about the versions that take a string message? Can we remove them since we have the call stack open in a debugger anyway? Sean
Cheers,
Sean |
|
|
In reply to this post by Sean P. DeNigris
On Aug 29, 2011, at 11:48 AM, Sean P. DeNigris wrote: > > Sean P. DeNigris wrote: >> >> 3. Is anyone using the versions that take a string message (e.g. >> #haltOnce:). A halt brings you into a debugger, so is the extra info worth >> the added complexity? p.s. right now, the versions are cut-and-pastes of >> each other >> > > What about the versions that take a string message? Can we remove them since > we have the call stack open in a debugger anyway? > Yes, I would say remove. -- Marcus Denker -- http://marcusdenker.de |
|
|
In reply to this post by Nicolas Cellier
2011/8/29 Nicolas Cellier <[hidden email]>
ok, the complier applies the optimisation only is the argument is a Block. Because I tried: Foo ifTrue: a=2 " and it works perfectly" Foo ifTrue: [a=2] "but this one not. mustBeBoolean receiver" Thanks Nicolas, Luc
|
|
Administrator
|
In reply to this post by Marcus Denker-4
I've never removed a core method. What is the latest deprecation policy? Or just remove? Sean
Cheers,
Sean |
|
|
self deprecate:in:on: or something like that.
On Aug 29, 2011, at 11:56 AM, Sean P. DeNigris wrote: > > marcus.denker wrote: >> >> Yes, I would say remove. >> > > I've never removed a core method. What is the latest deprecation policy? Or > just remove? > > Sean > > -- > View this message in context: http://forum.world.st/Halt-tp3774723p3775839.html > Sent from the Pharo Smalltalk mailing list archive at Nabble.com. > |
«
Return to Pharo Smalltalk Developers
|
1 view|%1 views
| Free forum by Nabble | Edit this page |