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

Re: [Pharo-project] Symbol>value:

by Lukas Renggli

Therefor I suggested to remove Symbol>>#value: the last time this was brought up. If you keep it, besides all the variations of #value:... you also need to consider #cull:, #cull:cull:, #cull:cull:cull:, #valueWithArguments:, valueWithEnoughArguments:, #valuWithPossibleArgs:, #valueWithPossibleArguments:; as well as somebody needs to fix #numArgs (which is highly inconsistent with a block that has the same behavior). Also for many asymmetric selectors the trick does not work (e.g. #join:, #matches:, #includesSubString:, ...) because you need to turn around the arguments. Aside from the above, evaluable selectors hamper readability: Back in 2005 Magritte added #value: and #value:value: as method extensions. You can go and read all the mails of people having troubles reading the code. The benefit of writing a few characters less is really not worth the trouble spent digesting the code. Lukas On 30 August 2011 20:09, Niko Schwarz <niko.schwarz(a)googlemail.com> wrote: > It's a question of consistency. Why support value:, but not value:value:? > > Niko > > On Tue, Aug 30, 2011 at 7:45 PM, Igor Stasenko <siguctua(a)gmail.com> wrote: >> On 30 August 2011 18:02, Douglas Brebner <squeaklists(a)fang.demon.co.uk> wrote: >>> On 30/08/2011 13:30, Tudor Girba wrote: >>> >>> I proposed this some one or two years ago. I got shut down, but I still find >>> it a good idea. >>> >>> And I even have a semantic reason: >>> - A Block represents a piece of functionality that can be evaluated with >>> some input >>> - A Symbol often represents a selector which in turns represents a piece of >>> functionality that can be evaluated with some input. >>> >>> I seem to recall there was discussion some time ago about splitting Selector >>> functionality from Symbol. After all, there's no real reason that a selector >>> has to be a Symbol. >>> >> >> Selector is just a role to identify a method in method's dictionary. >> It can be any object: if you look how VM does a lookup >> there's nothing which limits a selectors to be the instances of Symbol >> (perhaps the only thing is printing a stack trace ;). >> >> What i mean that any object may be a selector: >> >> MyClass methodDict at: 1 put: someMethod. >> >> MyClass new perform: 1 >> >> should work. >> >> So, i don't see what you can gain by splitting functionality of >> Selector from Symbol. Then you should put all selector-related >> protocol to Object class. >> And this even worse idea :) >> >> >>> Also, some of the examples in this thread seem to be about terseness for >>> terseness sake. >>> >> >> Yeah. I have same impression. >> But its cool :) >> >> >> >> -- >> Best regards, >> Igor Stasenko AKA sig. >> >> > > > > -- > http://scg.unibe.ch/staff/Schwarz > twitter.com/nes1983 > Tel: +41786126354 > > -- Lukas Renggli www.lukas-renggli.ch

Aug. 30, 2011

Re: [Pharo-project] Symbol>value:

by Nicolas Cellier

Same question with cull: 2011/8/30 Niko Schwarz <niko.schwarz(a)googlemail.com>: > It's a question of consistency. Why support value:, but not value:value:? > > Niko > > On Tue, Aug 30, 2011 at 7:45 PM, Igor Stasenko <siguctua(a)gmail.com> wrote: >> On 30 August 2011 18:02, Douglas Brebner <squeaklists(a)fang.demon.co.uk> wrote: >>> On 30/08/2011 13:30, Tudor Girba wrote: >>> >>> I proposed this some one or two years ago. I got shut down, but I still find >>> it a good idea. >>> >>> And I even have a semantic reason: >>> - A Block represents a piece of functionality that can be evaluated with >>> some input >>> - A Symbol often represents a selector which in turns represents a piece of >>> functionality that can be evaluated with some input. >>> >>> I seem to recall there was discussion some time ago about splitting Selector >>> functionality from Symbol. After all, there's no real reason that a selector >>> has to be a Symbol. >>> >> >> Selector is just a role to identify a method in method's dictionary. >> It can be any object: if you look how VM does a lookup >> there's nothing which limits a selectors to be the instances of Symbol >> (perhaps the only thing is printing a stack trace ;). >> >> What i mean that any object may be a selector: >> >> MyClass methodDict at: 1 put: someMethod. >> >> MyClass new perform: 1 >> >> should work. >> >> So, i don't see what you can gain by splitting functionality of >> Selector from Symbol. Then you should put all selector-related >> protocol to Object class. >> And this even worse idea :) >> >> >>> Also, some of the examples in this thread seem to be about terseness for >>> terseness sake. >>> >> >> Yeah. I have same impression. >> But its cool :) >> >> >> >> -- >> Best regards, >> Igor Stasenko AKA sig. >> >> > > > > -- > http://scg.unibe.ch/staff/Schwarz > twitter.com/nes1983 > Tel: +41786126354 > >

Aug. 30, 2011

Re: [Pharo-project] Symbol>value:

by Niko Schwarz

It's a question of consistency. Why support value:, but not value:value:? Niko On Tue, Aug 30, 2011 at 7:45 PM, Igor Stasenko <siguctua(a)gmail.com> wrote: > On 30 August 2011 18:02, Douglas Brebner <squeaklists(a)fang.demon.co.uk> wrote: >> On 30/08/2011 13:30, Tudor Girba wrote: >> >> I proposed this some one or two years ago. I got shut down, but I still find >> it a good idea. >> >> And I even have a semantic reason: >> - A Block represents a piece of functionality that can be evaluated with >> some input >> - A Symbol often represents a selector which in turns represents a piece of >> functionality that can be evaluated with some input. >> >> I seem to recall there was discussion some time ago about splitting Selector >> functionality from Symbol. After all, there's no real reason that a selector >> has to be a Symbol. >> > > Selector is just a role to identify a method in method's dictionary. > It can be any object: if you look how VM does a lookup > there's nothing which limits a selectors to be the instances of Symbol > (perhaps the only thing is printing a stack trace ;). > > What i mean that any object may be a selector: > > MyClass methodDict at: 1 put: someMethod. > > MyClass new perform: 1 > > should work. > > So, i don't see what you can gain by splitting functionality of > Selector from Symbol. Then you should put all selector-related > protocol to Object class. > And this even worse idea :) > > >> Also, some of the examples in this thread seem to be about terseness for >> terseness sake. >> > > Yeah. I have same impression. > But its cool :) > > > > -- > Best regards, > Igor Stasenko AKA sig. > > -- http://scg.unibe.ch/staff/Schwarz twitter.com/nes1983 Tel: +41786126354

Aug. 30, 2011

Re: [Pharo-project] Pharo 1.3 release

by Nicolas Cellier

Thanks Igor. We mostly can live with a bug in the image. A bug in a VM would be another thing, so you are right to look it twice. Nicolas 2011/8/30 Igor Stasenko <siguctua(a)gmail.com>: > On 30 August 2011 17:17, Marcus Denker <marcus.denker(a)inria.fr> wrote: >> >> On Aug 30, 2011, at 5:15 PM, Mariano Martinez Peck wrote: >> >>> so what is missing now? just an ANN email? >>> >> >> No, as much as I know we do not have yet a One-Click with current VMs... >> > > yes, i am working on that. > > The delay was because: > > a) some critical fixes to VM were added recently, and i would like > them to be in release > Â - fix with become primitive > Â - fix a command-line interface for Cocoa VMs , which we were able to > do with Esteban @ ESUG > > b) due to squeaksource failures and other mess with > jenkins/hudson/windows slave things get delayed > > please, do not treat me as an asshole, who spoils the fun and delays > and delays.. but i just want to make sure that we're releasing > something more or less stable and usable :) > > I will verify everything in a couple of days, and then will just give > the VMs to Markus to package them in one-click distro.. > > -- > Best regards, > Igor Stasenko AKA sig. > >

Aug. 30, 2011

[Pharo-project] Why MC when you copying a package doing too much things?

by Igor Stasenko

If you look how MC copies package from remote repository to package-cache dir, you will find out , that it: - reads and parses all definitions from source package - and then writes all these definitions into a new file while instead it could just simply copy the contents of existing file to the directory and that's it. This actually explains why uploading VMMaker to squeaksource takes ages (and most of the times time outs), simply because on server we have this unnecessary load of read-deserialize-serialize-write cycle while it could be just read-write (copying). I think we could make it faster by copying and then parsing only the necessary parts of package, like commit log and ancestry information, but not parsing the whole package contents. Another approach is of course to split bloated VMMaker package into parts.. but the problem is that for building VMs there's already too many stuff there.. for example look at the configuration of cog: package: 'FFI-Pools' with: 'FFI-Pools-eem.3'; package: 'SharedPool-Speech' with: 'SharedPool-Speech-dtl.2'; package: 'Balloon-Engine-Pools' with: 'Balloon-Engine-Pools-JB.2'; package: 'Alien-Core' with: 'Alien-Core-IgorStasenko.68'; package: 'Sound' with: 'Sound-StephaneDucasse.62'; package: 'VMConstruction-Plugins-OSProcessPlugin' with: 'VMConstruction-Plugins-OSProcessPlugin.oscog-eem.31'; package: 'Freetype-Plugin' with: 'Freetype-Plugin-IgorStasenko.61'; package: 'ObjectiveC-Plugin' with: 'ObjectiveC-Plugin-John M McIntosh.20'; package: 'Cog' with: 'Cog-eem.45'; package: 'VMMaker-oscog' with: 'VMMaker-oscog-IgorStasenko.122'; package: 'Qwaq-VMProfiling-Plugins' with: 'Qwaq-VMProfiling-Plugins-JB.5'; package: 'Applescript-Core' with: 'Applescript-Core-SeanDeNigris.2'; package: 'CMakeVMMaker' with: 'CMakeVMMaker-IgorStasenko.136' ]. but i think we can deal with it nicely. Anyways, i think we should consider splitting VMMaker, because it goes nowhere. For Cog VMMaker , i think we could remove an Interpreter class, which can make a package like 20% smaller, without any need of refactoring and dependency rewiring. -- Best regards, Igor Stasenko AKA sig.

Aug. 30, 2011

Re: [Pharo-project] Symbol>value:

by Igor Stasenko

On 30 August 2011 18:02, Douglas Brebner <squeaklists(a)fang.demon.co.uk> wrote: > On 30/08/2011 13:30, Tudor Girba wrote: > > I proposed this some one or two years ago. I got shut down, but I still find > it a good idea. > > And I even have a semantic reason: > - A Block represents a piece of functionality that can be evaluated with > some input > - A Symbol often represents a selector which in turns represents a piece of > functionality that can be evaluated with some input. > > I seem to recall there was discussion some time ago about splitting Selector > functionality from Symbol. After all, there's no real reason that a selector > has to be a Symbol. > Selector is just a role to identify a method in method's dictionary. It can be any object: if you look how VM does a lookup there's nothing which limits a selectors to be the instances of Symbol (perhaps the only thing is printing a stack trace ;). What i mean that any object may be a selector: MyClass methodDict at: 1 put: someMethod. MyClass new perform: 1 should work. So, i don't see what you can gain by splitting functionality of Selector from Symbol. Then you should put all selector-related protocol to Object class. And this even worse idea :) > Also, some of the examples in this thread seem to be about terseness for > terseness sake. > Yeah. I have same impression. But its cool :) -- Best regards, Igor Stasenko AKA sig.

Aug. 30, 2011

Re: [Pharo-project] Pharo 1.3 release

by Sven Van Caekenberghe

On 30 Aug 2011, at 19:04, Igor Stasenko wrote: > please, do not treat me as an asshole, who spoils the fun and delays > and delays.. but i just want to make sure that we're releasing > something more or less stable and usable :) > > I will verify everything in a couple of days, and then will just give > the VMs to Markus to package them in one-click distro.. Yes, thanks a lot! This one Pharo VM to rule them all is really important. Sven

Aug. 30, 2011

Re: [Pharo-project] Pharo 1.3 release

by Tudor Girba

Thanks a lot, Igor! Doru On 30 Aug 2011, at 19:04, Igor Stasenko wrote: > On 30 August 2011 17:17, Marcus Denker <marcus.denker(a)inria.fr> wrote: >> >> On Aug 30, 2011, at 5:15 PM, Mariano Martinez Peck wrote: >> >>> so what is missing now? just an ANN email? >>> >> >> No, as much as I know we do not have yet a One-Click with current VMs... >> > > yes, i am working on that. > > The delay was because: > > a) some critical fixes to VM were added recently, and i would like > them to be in release > - fix with become primitive > - fix a command-line interface for Cocoa VMs , which we were able to > do with Esteban @ ESUG > > b) due to squeaksource failures and other mess with > jenkins/hudson/windows slave things get delayed > > please, do not treat me as an asshole, who spoils the fun and delays > and delays.. but i just want to make sure that we're releasing > something more or less stable and usable :) > > I will verify everything in a couple of days, and then will just give > the VMs to Markus to package them in one-click distro.. > > -- > Best regards, > Igor Stasenko AKA sig. > -- www.tudorgirba.com "Problem solving efficiency grows with the abstractness level of problem understanding."

Aug. 30, 2011

Re: [Pharo-project] Pharo 1.3 release

by Igor Stasenko

On 30 August 2011 17:17, Marcus Denker <marcus.denker(a)inria.fr> wrote: > > On Aug 30, 2011, at 5:15 PM, Mariano Martinez Peck wrote: > >> so what is missing now? just an ANN email? >> > > No, as much as I know we do not have yet a One-Click with current VMs... > yes, i am working on that. The delay was because: a) some critical fixes to VM were added recently, and i would like them to be in release - fix with become primitive - fix a command-line interface for Cocoa VMs , which we were able to do with Esteban @ ESUG b) due to squeaksource failures and other mess with jenkins/hudson/windows slave things get delayed please, do not treat me as an asshole, who spoils the fun and delays and delays.. but i just want to make sure that we're releasing something more or less stable and usable :) I will verify everything in a couple of days, and then will just give the VMs to Markus to package them in one-click distro.. -- Best regards, Igor Stasenko AKA sig.

Aug. 30, 2011

Re: [Pharo-project] Symbol>value:

by niko.schwarz＠googlemail.com

You just inspired me to a block post on point-free programming :) http://smalltalkthoughts.blogspot.com/2011/08/point-free-programming-in-sma… Niko On 30.08.2011, at 16:57, HwaJong Oh wrote: > I have similar definitions from symbol to block for SortedCollection like; > > #('3' '20' '100') asSortedCollection: #size ascendingSortBlock. "#('3' '20' > '100')" > > #size ascendingSortBlock evaluates to be [:a :b| (a perform: #size) <= (b > perform:#size) ] > > #('3' '20' '100') asSortedCollection: #size descendingSortBlock. "#('100' > '20' '3')" > > > Similarly, following can be done > > #('3' '20' '100') asSortedCollection: #first ascendingSortBlock. > #('3' '20' '100') asSortedCollection: #first descendingSortBlock. > > -- > View this message in context: http://forum.world.st/Symbol-value-tp3778525p3778943.html > Sent from the Pharo Smalltalk mailing list archive at Nabble.com. > -- http://scg.unibe.ch/staff/Schwarz twitter.com/nes1983 Tel: +41786126354

Aug. 30, 2011