- Pharo-dev - lists.pharo.org

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

Re: [Pharo-project] [ANN] glamorous inspector

by StÃ©phane Ducasse

getting really sexy. On Aug 29, 2011, at 12:06 AM, Tudor Girba wrote: > Hi, > > There are a couple of improvements related to the GT Inspector: > > - A morph has a dedicated submorphs tab with which we can inspect the tree of morphs (see attached picture) > - A parse tree has a dedicated view that provides a tree of RB nodes and previews the information as a selection on the method source code (see the attached picture) > - On the top right there is a refresh button to update the inspector (it does not happen automatically) > - Damien Cassou fixed the "do it" support in the evaluator so now you can use the default keys as in the workspace > - Some more relevant menu items for manipulation > > Cheers, > Doru > > > <gti13.png> > <gti14.png> > > > On 24 Aug 2011, at 11:12, Tudor Girba wrote: > >> The GT Inspector is now available by default in the Moose image (CMD+Shift+i). >> >> It seems to work quite well. >> >> Cheers, >> Doru >> >> >> On 22 Aug 2011, at 22:59, StÃ©phane Ducasse wrote: >> >>> Thanks doru :) >>> >>> Stef >>> >>> On Aug 22, 2011, at 7:59 PM, Tudor Girba wrote: >>> >>>> Hi, >>>> >>>> I am happy to announce the first release of the Glamorous Inspector, a new browser for inspecting objects based on Glamour. >>>> >>>> More information, including a demo and screenshots, can be found here: >>>> http://www.humane-assessment.com/blog/glamorous-inspector-for-smalltalk >>>> >>>> To download it follow the instructions from: >>>> http://www.moosetechnology.org/tools/glamoroustoolkit >>>> >>>> You can use it by: >>>> 1. "GTInspector openOn: someObject", or >>>> 2. "GTInspector registerToolsOn: Smalltalk tools" and then use CMD+I (explore) >>>> >>>> Please let your opinion be heard :) >>>> >>>> Cheers, >>>> Doru >>>> >>>> p.s. Have fun at ESUG :) >>>> >>>> -- >>>> www.tudorgirba.com >>>> >>>> "Every successful trip needs a suitable vehicle." >>>> >>>> >>> >> >> -- >> www.tudorgirba.com >> >> "In a world where everything is moving ever faster, >> one might have better chances to win by moving slower." >> >> >> > > -- > www.tudorgirba.com > > "Some battles are better lost than fought." > > >

Aug. 29, 2011

Re: [Pharo-project] Squeaksource.com (was: [squeak-dev] Re: Addition to "About Pharo" dialog)

by Alexander LazareviÄ

2011/8/27 Bert Freudenberg <bert(a)freudenbergs.de> > The Chile mirror is up. > Just learned about that one. Thanks! While it seems more stable indeed, it also gets much less traffic. I'n not > sure it would handle the load of squeaksource.com as well. > Ok, but spreading the workload on to more than one SqueakSource server by moving selected projects from squeaksource.com as an interims solution could ease the pain, no? > So far we have not opened up source.squeak.org for personal projects. > Hah. Typical Plan B characteristics! ;) That would be a good idea IMHO - you might ask what the other VM developers think of the idea on the vm-dev list. I will forward it to the vm-dev list. I think the broken SqueakSource is hurting us more than we know! We discussed this at ESUG and so far the most promising plan is to migrate squeaksource.com to a SqueakSource3 instance running on Gemstone. Tobias should be able to tell us more. Is there a project page besides the actual beta repo installation? Alex

Aug. 29, 2011

Re: [Pharo-project] Halt

by Damien Cassou

On Sun, Aug 28, 2011 at 7:47 PM, Marcus Denker <marcus.denker(a)inria.fr> 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

Aug. 29, 2011