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

Re: [Pharo-project] Halt

by StÃ©phane Ducasse

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

Aug. 29, 2011

Re: [Pharo-project] Halt

by Damien Cassou

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] Headless image hanging

by Sven Van Caekenberghe

On 23 Aug 2011, at 23:44, Bernat Romagosa wrote: > Any ideas? Many people, including myself, have various images running for many weeks and even months, so it is possible. I am guessing that you are running some Seaside (maybe Pier) with one of the standard HTTP servers ? Those should not leave connections hanging open. Maybe the VNC stuff is the culprit ? I never use VNC, but the Seaside tools (Status | Config | Inspector | Browser | Dispatcher | VersionUploader) to manage and debug running servers. Just make sure you set them up with at least a password. Then you could try to find out what is happening. Sven

Aug. 29, 2011

Re: [Pharo-project] Halt

by Luc Fabresse

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

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 > >> 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] Omnibrowser in 1.4

by Levente Uzonyi

On Sun, 28 Aug 2011, Lukas Renggli wrote: > There are currently no plans to make OB work in upcoming Pharo > versions; Pharo 1.4 is supposed to have its own much better browser > framework. What are the advantages compared to OB? Levente > > On 28 August 2011 11:59, Sean P. DeNigris <sean(a)clipperadams.com> wrote: >> Oh forgot to mention, "(Smalltalk at: #ConfigurationOfOmniBrowser) project >> latestVersion load" from MetacelloRepository seemed maybe old, with >> references to Preferences, and errors after loading. > > References to Preferences were removed from OB a long long time ago (> > 1 year). Use the following script to get the latest code (for Pharo > 1.3 core images): > https://github.com/renggli/builder/blob/master/scripts/omnibrowser.st > > Lukas > >> >> S >> >> -- >> View this message in context: http://forum.world.st/Omnibrowser-in-1-4-tp3774180p3774181.html >> Sent from the Pharo Smalltalk mailing list archive at Nabble.com. >> >> > > > > -- > Lukas Renggli > www.lukas-renggli.ch > >

Aug. 29, 2011

Re: [Pharo-project] Pharo 1.4

by Levente Uzonyi

On Mon, 29 Aug 2011, StÃ©phane Ducasse wrote: > Roel typer does inference using method bodies and I do not think that it takes the receiver. > Now the problem is that we could take the expression (here 100) and evaluate and get its class (and catch error in case you wrote jlkkj > > Now what if the expression should not be evaluated twice. > > So type inferencer > > May be if we had a message: > > expr isLiteral we could guess a bit better. > > So if someone want to experiment please do. ECompletion already does that. See ECContext >> #guessTypeOf:. Levente > > Stef > >>>> >>> Cool! That would make a big difference. Where are they/what are they called? >> >> I know of Roel Wuyts' RoelTyper >> (http://decomp.ulb.ac.be/roelwuyts/smalltalk/roeltyper/) and Lex >> Spoon's Chuck (http://www.lexspoon.org/ti/) > > forget it. It was nice but > you need 80 mb or more of cache > and I'm not sure the code is somewhere and > working > >> Matt Might has also >> written about k-CFA (Control Flow Analysis) for inferring types in a >> dynamic language (Scheme, in particular) - >> http://matt.might.net/articles/implementation-of-kcfa-and-0cfa/ - >> which we might be able to apply to Smalltalk. > > well this is not something you do in 3 months. > >> >> frank >> >>> Sean >>> >>> -- >>> View this message in context: http://forum.world.st/Pharo-1-4-tp3759684p3774973.html >>> Sent from the Pharo Smalltalk mailing list archive at Nabble.com. >>> >>> >> > > >

Aug. 29, 2011

Re: [Pharo-project] Halt

by Damien Cassou

On Mon, Aug 29, 2011 at 9:29 AM, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> 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

Aug. 29, 2011

Re: [Pharo-project] Halt

by StÃ©phane Ducasse

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 <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] Pharo 1.4

by StÃ©phane Ducasse

Roel typer does inference using method bodies and I do not think that it takes the receiver. Now the problem is that we could take the expression (here 100) and evaluate and get its class (and catch error in case you wrote jlkkj Now what if the expression should not be evaluated twice. So type inferencer May be if we had a message: expr isLiteral we could guess a bit better. So if someone want to experiment please do. Stef >>> >> Cool! That would make a big difference. Where are they/what are they called? > > I know of Roel Wuyts' RoelTyper > (http://decomp.ulb.ac.be/roelwuyts/smalltalk/roeltyper/) and Lex > Spoon's Chuck (http://www.lexspoon.org/ti/) forget it. It was nice but you need 80 mb or more of cache and I'm not sure the code is somewhere and working > Matt Might has also > written about k-CFA (Control Flow Analysis) for inferring types in a > dynamic language (Scheme, in particular) - > http://matt.might.net/articles/implementation-of-kcfa-and-0cfa/ - > which we might be able to apply to Smalltalk. well this is not something you do in 3 months. > > frank > >> Sean >> >> -- >> View this message in context: http://forum.world.st/Pharo-1-4-tp3759684p3774973.html >> Sent from the Pharo Smalltalk mailing list archive at Nabble.com. >> >> >

Aug. 29, 2011