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

Re: [Pharo-project] Symbol>value:

by StÃ©phane Ducasse

My suggestion is the following one: we could add it because there is value: now I would not use it in the core of the system. I hope that one of these days we will be able to bootstrap and identify a kernel and after that we could tag a bit the methods in terms of layers. Stef On Aug 30, 2011, at 9:14 PM, StÃ©phane Ducasse wrote: > Indeed I would prefer just to have perform: and block value: > > Stef > > On Aug 30, 2011, at 8:34 PM, Lukas Renggli wrote: > >> 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 StÃ©phane Ducasse

Indeed I would prefer just to have perform: and block value: Stef On Aug 30, 2011, at 8:34 PM, Lukas Renggli wrote: > 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 StÃ©phane Ducasse

On Aug 30, 2011, at 6:02 PM, Douglas Brebner 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. It was just a stupid idea of mine :) > > Also, some of the examples in this thread seem to be about terseness for terseness sake. >

Aug. 30, 2011

Re: [Pharo-project] Symbol>value:

by Frank Shearar

On 30 August 2011 19:34, Lukas Renggli <renggli(a)gmail.com> wrote: > 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. Like all strong flavours, it's very useful/tasty in small doses. I'm not sure that #inject:into value: #(1 2 3) value: 0 value: #+ is particularly useful. Having said that, I did find it useful playing around with partial continuations to define #compose: on the continuations, symbols and blocks. It made for very readable (IMO at least :) ) code. ZipperControl class >> zipOver: aCollection | f zippers | f := [:a | [:k | Zipper on: a with: (k compose: [:x | x maybe: #yourself default: a])] shift]. ^ [ZipDone on: (aCollection collect: [:each | f value: each])] reset. compared to the original Haskell: make_zipper :: T.Traversable t => t a -> Zipper t a make_zipper t = reset $ T.mapM f t >>= return . ZDone where f a = shift (\k -> return $ Z a (k . maybe a id)) (From http://okmij.org/ftp/continuations/zipper.html#traversable) frank > 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] Polymorph changes

by Tudor Girba

Actually, the only reason why the development of Moose is not on 1.4 is that we did not release the current version yet, due to a couple of issues still open in Moose. As soon as we release it, we move to 1.4. Cheers, Doru On 30 Aug 2011, at 20:38, StÃ©phane Ducasse wrote: > :) you are probably really crazy. > > Moose migration from 1.2 to 1.3 took one afternoon or two. > >> Yes Stef, for 1.4 (bravely using it for our OCR development!) >> Ta >> >> Regards, Gary >> >> ----- Original Message ----- From: "StÃ©phane Ducasse" <stephane.ducasse(a)inria.fr> >> To: <Pharo-project(a)lists.gforge.inria.fr> >> Sent: Tuesday, August 30, 2011 1:42 PM >> Subject: Re: [Pharo-project] Polymorph changes >> >> >> tx gary >> is this for 1.4 (I guess). >> I will integrate them. >> >> Stef >> >> On Aug 30, 2011, at 2:29 PM, Gary Chambers wrote: >> >>> Before I forget... >>> A few changes to Polymorph and fixes for a few other packages attached. >>> >>> AlphaImageMorph supports #scaledAspect layout option (scales the image to fit whilst retaining aspect ratio) >>> also class side accessor to set DefaultImage (I use the Pharo logo, appears in #exampleOtherControls) >>> DialogItemsChooserUI centering rounded to avoid layout anomalies >>> EditorFindReplaceDialogWindow initialized to position within usable area of display so not obscured by docks etc. >>> GeneralScrollPane minWidth/minHeight when shrinkWrapping to target >>> LazyListMorph mouse down row indication fixed >>> PluggableListMorph fix for startDragExtended: mouse focus and wrapItem (when wrapSelector takes 0 args) >>> ScrollPane will ignore mouse wheel iv not vertically scrollable (allows owners to handle) >>> SystemWindow basicActivate no longer passivates old top window if no longer in world >>> UITheme expander color no longer set to white by default >>> nil labels for label groups now allow the associated control to fill whole width >>> >>> >>> Also I've noticed that in latest updates, corner rounding no longer functions (affects scrollbars etc. in Watery 2 theme). >>> >>> Regards, Gary >>> <PolymorphImprovements2.1.cs> >> >> >> > > -- www.tudorgirba.com "No matter how many recipes we know, we still value a chef."

Aug. 30, 2011

Re: [Pharo-project] Symbol>value:

by StÃ©phane Ducasse

makes sense. http://code.google.com/p/pharo/issues/detail?id=4726 Stef On Aug 30, 2011, at 2:12 PM, niko.schwarz(a)googlemail.com wrote: > Hi, > > Symbol responds to #value:, but not to #value:value:. > > At some point, Symbol and Block were decided to have the invocation protocol in common. I find this great. Therefore, I think, Symbol should also respond to #value:value:, as follows: > > value: anObject value: anotherObject > ^ anObject perform: self with: anotherObject > > Of course, it should also respond to #value:value:value: and #value:value:value:value: > > Niko > > -- > http://scg.unibe.ch/staff/Schwarz > twitter.com/nes1983 > Tel: +41786126354 > >

Aug. 30, 2011

[Pharo-project] Redirect CI link

by Torsten Bergmann

Anyone able to redirect "http://ci.pharo-project.org" from old hudson https://pharo-ic.lille.inria.fr/hudson/ to new Jenkins https://ci.lille.inria.fr/pharo/ Would also be nice if "bugs.pharo-project.org" would point to the issue tracker as well (similar to "issues.pharo-project.org") Thanks T. -- Empfehlen Sie GMX DSL Ihren Freunden und Bekannten und wir belohnen Sie mit bis zu 50,- Euro! https://freundschaftswerbung.gmx.de

Aug. 30, 2011

Re: [Pharo-project] Pharo 1.3 release

by StÃ©phane Ducasse

In a couple of weeks (but not before :)) igor will start to work on tests and VM branding. Stef On Aug 30, 2011, at 8:03 PM, Nicolas Cellier wrote: > 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

Re: [Pharo-project] Polymorph changes

by StÃ©phane Ducasse

:) you are probably really crazy. Moose migration from 1.2 to 1.3 took one afternoon or two. > Yes Stef, for 1.4 (bravely using it for our OCR development!) > Ta > > Regards, Gary > > ----- Original Message ----- From: "StÃ©phane Ducasse" <stephane.ducasse(a)inria.fr> > To: <Pharo-project(a)lists.gforge.inria.fr> > Sent: Tuesday, August 30, 2011 1:42 PM > Subject: Re: [Pharo-project] Polymorph changes > > > tx gary > is this for 1.4 (I guess). > I will integrate them. > > Stef > > On Aug 30, 2011, at 2:29 PM, Gary Chambers wrote: > >> Before I forget... >> A few changes to Polymorph and fixes for a few other packages attached. >> >> AlphaImageMorph supports #scaledAspect layout option (scales the image to fit whilst retaining aspect ratio) >> also class side accessor to set DefaultImage (I use the Pharo logo, appears in #exampleOtherControls) >> DialogItemsChooserUI centering rounded to avoid layout anomalies >> EditorFindReplaceDialogWindow initialized to position within usable area of display so not obscured by docks etc. >> GeneralScrollPane minWidth/minHeight when shrinkWrapping to target >> LazyListMorph mouse down row indication fixed >> PluggableListMorph fix for startDragExtended: mouse focus and wrapItem (when wrapSelector takes 0 args) >> ScrollPane will ignore mouse wheel iv not vertically scrollable (allows owners to handle) >> SystemWindow basicActivate no longer passivates old top window if no longer in world >> UITheme expander color no longer set to white by default >> nil labels for label groups now allow the associated control to fill whole width >> >> >> Also I've noticed that in latest updates, corner rounding no longer functions (affects scrollbars etc. in Watery 2 theme). >> >> Regards, Gary >> <PolymorphImprovements2.1.cs> > > >

Aug. 30, 2011

[Pharo-project] Pharo 1.3 and 1.4 status update

by laurent laffont

Here's a Pharo status update: http://www.pharo-project.org/news Please review. Laurent Laffont - @lolgzs <http://twitter.com/#!/lolgzs> Pharo Smalltalk Screencasts: http://www.pharocasts.com/ Blog: http://magaloma.blogspot.com/ Developer group: http://cara74.seasidehosting.st

Aug. 30, 2011