- Pharo-dev - lists.pharo.org

Re: [Pharo-project] Symbol>value:

by Mariano Martinez Peck

I arrive late to the discussion, but from my point of view, the correct solution is to create a subclass from Symbol, called Selector ;) and move all those methods there. There are lots of methods in Symbol which in fact only make sense when they are selectors. I know this change will never be done, but that's where those methods like #value: should be placed. I would love to see a clear division between Symbol and Selector. cheers On Tue, Aug 30, 2011 at 9:20 PM, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr > wrote: > 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 > >> > > > > > > > -- Mariano http://marianopeck.wordpress.com

Aug. 31, 2011

Re: [Pharo-project] Gofer/Metacello problem in 1.4 [WAS] Re: DBXTalk and Pharo 1.4

by Mariano Martinez Peck

On Tue, Aug 30, 2011 at 11:26 PM, Dale Henrichs <dhenrich(a)vmware.com> wrote: > Mariano, > > I think that addVersion: is very old gofer/metacello code ... not fancy new > code. It sounds like an old version of Metacello is being > loaded/bootstrapped. #addVersion: isn't sent from the current code base ... > At a minimum, you should have these packages loaded: > > 'Metacello-Base-DaleHenrichs.19' > 'Metacello-Core-DaleHenrichs.455' > 'Metacello-MC-DaleHenrichs.505' > > Wow. This is weird. The versions that are being loaded are: Metacello-Core-dkh.302 Metacello-MC-dkh.258 ... So...terribly old. Of course, the problem was that out #ensureMetacello was very old. But how we didn't discovered before doing the release? of course, because we used Pharo images that already come with Metacello hahahha. I have just commited the fix. I took the latest #ensureMetacello from here: http://code.google.com/p/metacello/wiki/EnsureMetacello I hope this is correct. Thanks Dale for the help and thanks Laszlo for the report! > if the bootstrapping process is working. > > Keep in mind that pharo1.4.x has not yet been defined in Metacello (see > Issue 4613[1]), so there will be other Metacello issues in 1.4 for the > moment ... the proposed bugfix in 4613 would mean that a new version of > Metacello would no longer be needed to define the platform specific > attributes ... > > Dale > > [1] http://code.google.com/p/pharo/issues/detail?id=4613 > > ----- Original Message ----- > | From: "Mariano Martinez Peck" <marianopeck(a)gmail.com> > | To: dbxtalk(a)googlegroups.com, "Pharo Development" < > pharo-project(a)lists.gforge.inria.fr> > | Sent: Tuesday, August 30, 2011 2:00:26 PM > | Subject: [Pharo-project] Gofer/Metacello problem in 1.4 [WAS] Re: DBXTalk > and Pharo 1.4 > | > | > | > | > | On Tue, Aug 30, 2011 at 9:14 PM, Laszlo Zsolt Kiss < > | lzskiss(a)gmail.com > wrote: > | > | > | > | > | hi. > | first i load the ConfigurationOfOpenDBX and the 1.4 version is > | missing from the spec.: > | > | > | > | stable: spec > | <symbolicVersion: #stable> > | > | spec for: #'pharo1.2.x' version: '1.0'. > | spec for: #'pharo1.3.x' version: '1.0'. > | > | > | then i added the next line to the spec: > | > | > | spec for: #'pharo1.4.x' version: '1.0'. > | > | > | then i probally do it this: > | > | > | (((Smalltalk globals at: #ConfigurationOfOpenDBXDriver) perform: > | #project) perform: #version: with: #stable) load. > | > | > | i gived back a warring: > | > | > | > | "The method Gofer addVersion: has been deprecated. > | Instead of #addVersion: simply use #version: > | > | Hi. Yes, I can reproduce this problem :( > | > | > | > | > | > | > | > | > | Select Proceed to continue, or close this window to cancel the > | operation." > | > | > | I proceed this warrning. > | > | > | Then gived back an error message, I think this error came from the > | Metacello. > | > | I attached the PharoDebug file. > | > | > | > | > | The error is in the method #updateProject where it does: > | > | (GoferPackageReference name: mgr packageName repository: mgr > | repositoryGroup) versionReference. > | > | GoferPackageReference dnu #name:repository: instead, it is > | implemented in GoferResolvedReference > | > | > | Dale any idea? > | > | Versions: Gofer-Core-StephaneDucasse.135. > | Metacello version is ...... ConfigurationOfMetacello project > | currentVersion raises dnu #setName > | > | So...I guess Pharo 1.4 is using a very new version of Gofer, which > | brings lot of changes that break Metacello ? > | > | Thanks! > | > | > | > | > | > | > | > | > | Byte > | Laszlo Zsolt > | > | > | Ps: the image is clean #14112 and the CogVM is the last.. > | > | > | inez Peck < marianopeck(a)gmail.com > > | > | > | > | > | > | > | > | > | > | On Tue, Aug 30, 2011 at 9:53 AM, Laszlo Zsolt Kiss < > | lzskiss(a)gmail.com > wrote: > | > | > | Hi Developers! > | > | > | Can I use any way this combination: DBXTalk with Pharo 1.4? > | > | Hi. Yes, sure. Did you try it? You shouldn't have any problem. > | Please let us know if you do have. > | > | > | -- > | Mariano > | http://marianopeck.wordpress.com > | > | > | > | > | > | -- > | Mariano > | http://marianopeck.wordpress.com > | > | > > -- Mariano http://marianopeck.wordpress.com

Aug. 31, 2011

Re: [Pharo-project] The Keys to the Kingdom

by Johannes Rasche

exactly !! before Pharo Squeak was a nightmare for me and I'm grateful to the Pharo contributors Am 31.08.2011 um 11:14 schrieb Sean P. DeNigris: > This incredible piece of feedback was hiding at > http://code.google.com/p/pharo/wiki/HowToContribute . We should all have > this pinned to the wall behind our computer: > > Sometimes I make some "exercise" on Smalltalk/Squeak for the fun, sometimes > I try to build tools in Squeak to solve some practical problem or personal > need. I'm not a programmer, just a curious guy, completely ignorant about > programming, who, some years ago, found Smalltalk/Squeak to be the only > human programming language I could cope with. But every time I try to do > something with Squeak I stumble on this inevitable conclusion: it is one of > the most entropic things I ever met in my life. The reason for this may lay > partly on structural reasons - I wouldn't know, because I'm an ignorant, as > I stated before. But there is a second reason I know for sure: the owners' > and contributors' inability to step out of the developer's perspective, to > put a distance towards themselves (and towards the result of their work). As > a result, Squeak is probably the worst documented language in the world. > Documentation and comments on the code are completely entropic, > self-centered, tautological; it is experts talking to all-knowing experts - > like those stupid old-fashioned dictionaries where every word definition > tends to be built with the defined word. Until now I had a look to Pharo > system browser only for a few minutes, but that was enough for me to get the > impression that you are trying to get over this dreadful limitation, to jump > over the limits of an strictly enclosed community, rehearsing new tentative > styles to comment code and classes. If I got it right and this is true, > congratulations and thank you very much for your effort. > > -- > View this message in context: http://forum.world.st/The-Keys-to-the-Kingdom-tp3780556p3780556.html > Sent from the Pharo Smalltalk mailing list archive at Nabble.com. >

Aug. 31, 2011

[Pharo-project] The Keys to the Kingdom

by Sean P. DeNigris

This incredible piece of feedback was hiding at http://code.google.com/p/pharo/wiki/HowToContribute . We should all have this pinned to the wall behind our computer: Sometimes I make some "exercise" on Smalltalk/Squeak for the fun, sometimes I try to build tools in Squeak to solve some practical problem or personal need. I'm not a programmer, just a curious guy, completely ignorant about programming, who, some years ago, found Smalltalk/Squeak to be the only human programming language I could cope with. But every time I try to do something with Squeak I stumble on this inevitable conclusion: it is one of the most entropic things I ever met in my life. The reason for this may lay partly on structural reasons - I wouldn't know, because I'm an ignorant, as I stated before. But there is a second reason I know for sure: the owners' and contributors' inability to step out of the developer's perspective, to put a distance towards themselves (and towards the result of their work). As a result, Squeak is probably the worst documented language in the world. Documentation and comments on the code are completely entropic, self-centered, tautological; it is experts talking to all-knowing experts - like those stupid old-fashioned dictionaries where every word definition tends to be built with the defined word. Until now I had a look to Pharo system browser only for a few minutes, but that was enough for me to get the impression that you are trying to get over this dreadful limitation, to jump over the limits of an strictly enclosed community, rehearsing new tentative styles to comment code and classes. If I got it right and this is true, congratulations and thank you very much for your effort. -- View this message in context: http://forum.world.st/The-Keys-to-the-Kingdom-tp3780556p3780556.html Sent from the Pharo Smalltalk mailing list archive at Nabble.com.

Aug. 31, 2011

[Pharo-project] Please comment: Issue 4725: extend the string protocol

by Torsten Bergmann

Stef wrote >hence I would like to introduce some extensions: > >- chomp (ruby like) #chomp is not a very intention revealing name. What about #withoutTerminatingNewline Bye T. -- NEU: FreePhone - 0ct/min Handyspartarif mit Geld-zurÃ¼ck-Garantie! Jetzt informieren: http://www.gmx.net/de/go/freephone

Aug. 31, 2011

[Pharo-project] Please comment: Issue 4725: extend the string protocol

by StÃ©phane Ducasse

http://code.google.com/p/pharo/issues/detail?id=4725 I always feel a bit lost when using string manipulation in pharo... hence I would like to introduce some extensions: - chomp (ruby like) - #padLeft: #padRight: (as a replacement for the broken padded:to:with:) - #copyFrom:to: extensions with several specialized methods (the classical way would be to support negative indices, but this will most likely break existing tools) camillo could you illustrate your request. Some tests would be the ideal way to describe them.

Aug. 31, 2011

Re: [Pharo-project] Redirect CI link

by Marcus Denker

On Aug 30, 2011, at 8:45 PM, Torsten Bergmann wrote: > 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/ > Oh, yes, we will change that (might take a bit as Adrian is on Holidays) > > Would also be nice if "bugs.pharo-project.org" would > point to the issue tracker as well (similar to "issues.pharo-project.org") > ok. > Thanks > T. > -- > Empfehlen Sie GMX DSL Ihren Freunden und Bekannten und wir > belohnen Sie mit bis zu 50,- Euro! https://freundschaftswerbung.gmx.de > -- Marcus Denker -- http://marcusdenker.de

Aug. 31, 2011

Re: [Pharo-project] Website RSS feed broken?

by Max Leske

I'll check if this might be a cmsbox bug. Since Adrian's Blog is also affected, this might well be the case. I'll keep you posted. Max On 31.08.2011, at 07:41, Damien Cassou wrote: > On Tue, Aug 30, 2011 at 10:46 PM, Mariano Martinez Peck > <marianopeck(a)gmail.com> wrote: >> Hi Stefan, I've noticed the same problem :( > > I confirm, and this also happens with Adrian's blog: > http://www.adrian-lienhard.ch/blog > > -- > Damien Cassou > http://damiencassou.seasidehosting.st > > "Lambdas are relegated to relative obscurity until Java makes them > popular by not having them." James Iry >

Aug. 31, 2011

Re: [Pharo-project] Website RSS feed broken?

by Damien Cassou

On Tue, Aug 30, 2011 at 10:46 PM, Mariano Martinez Peck <marianopeck(a)gmail.com> wrote: > Hi Stefan, I've noticed the same problem :( I confirm, and this also happens with Adrian's blog: http://www.adrian-lienhard.ch/blog -- Damien Cassou http://damiencassou.seasidehosting.st "Lambdas are relegated to relative obscurity until Java makes them popular by not having them." James Iry

Aug. 31, 2011

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

by Alexander LazareviÄ

2011/8/30 Tobias Pape <Das.Linux(a)gmx.de> > What do you mean by project page? > Just a simple page that has some Whys, Whos, Hows, Whats and Whats nots! Maybe something like this [1]. Alex [1] http://swagger.wordnik.com/

Aug. 31, 2011