August 2011 - Pharo-dev - lists.pharo.org

Re: [Pharo-project] Halt

by StÃ©phane Ducasse

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

Aug. 29, 2011

[Pharo-project] MorphLayout

by Camillo Bruni

Hi, I am looking for a sort of FlowLayout which works the same way usually text is handled: All submorphs are put on a single line and wrapped when the border is hit. Is there already a layout which does this?

Aug. 29, 2011

Re: [Pharo-project] Halt

by Sean P. DeNigris

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.

Aug. 29, 2011

Re: [Pharo-project] Halt

by Luc Fabresse

2011/8/29 Nicolas Cellier <nicolas.cellier.aka.nice(a)gmail.com> > 2011/8/29 Levente Uzonyi <leves(a)elte.hu>: > > 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). > 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 > 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 <marcus.denker(a)inria.fr> 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 > >>> > >> > >> > > > >

Aug. 29, 2011

Re: [Pharo-project] Halt

by Marcus Denker

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

Aug. 29, 2011

Re: [Pharo-project] Halt

by Sean P. DeNigris

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? Sean -- View this message in context: http://forum.world.st/Halt-tp3774723p3775828.html Sent from the Pharo Smalltalk mailing list archive at Nabble.com.

Aug. 29, 2011

Re: [Pharo-project] Halt

by Nicolas Cellier

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 <luc.fabresse(a)gmail.com>: > > 2011/8/29 Levente Uzonyi <leves(a)elte.hu> >> >> 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 <marcus.denker(a)inria.fr> 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 >>>> >>> >>> > >

Aug. 29, 2011

Re: [Pharo-project] Halt

by Nicolas Cellier

2011/8/29 Levente Uzonyi <leves(a)elte.hu>: > 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 <marcus.denker(a)inria.fr> 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 >>> >> >> >

Aug. 29, 2011

Re: [Pharo-project] Halt

by StÃ©phane Ducasse

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 <leves(a)elte.hu>: >> 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 >

Aug. 29, 2011

Re: [Pharo-project] Halt

by StÃ©phane Ducasse

> 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

Aug. 29, 2011