October 2009 - Pharo-dev - lists.pharo.org

Re: [Pharo-project] Detecting overriding class extensions

by Simon Denier

On 20 oct. 2009, at 14:16, Lukas Renggli wrote: > You can also ask the PackageInfo for #overrideMethods. ahah, interesting but broken, apparently nobody has used it for a long time? First, there is a gross spelling mistake in PackageInfo>>overrideMethods ^ self extensionMethods select: [:ea | self isOvverideMethod: ea] easy enough to correct. Second, isOverrideMethod: aMethodReference ^ aMethodReference category endsWith: '-override' uses a convention to identify override, but apparently Monticello does not follow its own convention anymore. Does anybody have an idea about what happened? > > Lukas > > 2009/10/20 Damien Cassou <damien.cassou(a)gmail.com>: >> On Tue, Oct 20, 2009 at 1:24 PM, Simon Denier >> <Simon.Denier(a)inria.fr> wrote: >>> Does anybody have a tool to detect class extensions which override >>> methods? Because that's so bad it's evil. >> >> You can have a look at the following script which basically warns you >> if you load a package that overrides a method IIRC. >> >> -- >> Damien Cassou >> http://damiencassou.seasidehosting.st >> >> "Lambdas are relegated to relative obscurity until Java makes them >> popular by not having them." James Iry >> >> _______________________________________________ >> Pharo-project mailing list >> Pharo-project(a)lists.gforge.inria.fr >> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >> > > > > -- > Lukas Renggli > http://www.lukas-renggli.ch > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project -- Simon

Oct. 20, 2009

Re: [Pharo-project] Detecting overriding class extensions

by Simon Denier

On 20 oct. 2009, at 13:45, Damien Cassou wrote: > On Tue, Oct 20, 2009 at 1:24 PM, Simon Denier > <Simon.Denier(a)inria.fr> wrote: >> Does anybody have a tool to detect class extensions which override >> methods? Because that's so bad it's evil. > > You can have a look at the following script which basically warns you > if you load a package that overrides a method IIRC. Sorry but I cant see a difference. Can you detail a use case that I can reproduce? (because I know there are still a few overrides in Moose but can not reproduce) > > -- > Damien Cassou > http://damiencassou.seasidehosting.st > > "Lambdas are relegated to relative obscurity until Java makes them > popular by not having them." James Iry > <WarnsAboutOverride-damiencassou. > 1.cs>_______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project -- Simon

Oct. 20, 2009

[Pharo-project] Clean up the #sort: and sortBy: mess.

by Niko Schwarz

Hi list, this is a copy of a proposal that I dumped into the bugtracker as http://code.google.com/p/pharo/issues/detail?id=1346. An OrderedCollection returns a copy on #sortBy:, while an ArrayedCollection returns a changed self on #sort:. ArrayedCollection does understand #sortBy:, while OrderedCollection does not understand #sort:. In VW and Squeak, OrderedCollection understands sort:, and it sorts inline. I'd like to propose two things (1) Add sort: to OrderedCollection, LinkedList and Heap (all of them understand at: put: since this weekend. and then (2) remove sortBy: I understand that point 2 might be controversial. I'd like to argue for it as follows: the naming sort vs. sortBy: is more than misleading, they appear to be synonyms, but they really do different things. The principle of the least surprise tells me that we should not have such behavior in the system. I'd like to argue that we want to erase the possible source of confusion, that is change sortBy: such that it either does the same as sort: or goes away. I'd like to leave #sort: the way it is because at any rate, we need to have an in-place sort, so why not keep the sort that sorts in- place. I'd argue it should go away, such that code that currently calls sortBy: does not call a method with changed semantics, which is difficult to debug. A DNU is easy to debug: you just change it to the now appropriate call. For me the most reasonable options are these: - rename #sortBy: to #copySortedBy: - remove #sortBy: Out of these, I'd vote for removing, since #copySortedBy: is not really shorter than 'copy sort:'. Cheers, Niko

Oct. 20, 2009

Re: [Pharo-project] Detecting overriding class extensions

by Lukas Renggli

You can also ask the PackageInfo for #overrideMethods. Lukas 2009/10/20 Damien Cassou <damien.cassou(a)gmail.com>: > On Tue, Oct 20, 2009 at 1:24 PM, Simon Denier <Simon.Denier(a)inria.fr> wrote: >> Does anybody have a tool to detect class extensions which override >> methods? Because that's so bad it's evil. > > You can have a look at the following script which basically warns you > if you load a package that overrides a method IIRC. > > -- > Damien Cassou > http://damiencassou.seasidehosting.st > > "Lambdas are relegated to relative obscurity until Java makes them > popular by not having them." James Iry > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > -- Lukas Renggli http://www.lukas-renggli.ch

Oct. 20, 2009

Re: [Pharo-project] scriptloader>>loadComanche

by Lukas Renggli

The following snippet loads Seaside 3.0: [ Gofer new squeaksource: 'Seaside30'; addPackage: 'LoadOrderTests'; load ] valueSupplyingAnswers: { {'Load Seaside'. true}. {'SqueakSource User Name'. ''}. {'SqueakSource Password'. ''}. {'Run tests'. false}. } There are more scripts that I use to build images on the Pharo Wiki <http://code.google.com/p/pharo/wiki/ImageBuildScripts>. Lukas 2009/10/20 Johan Brichau <johan.brichau(a)uclouvain.be>: > > On 20 Oct 2009, at 12:00, Torsten Bergmann wrote: > >>> We clearly need a universe like tools so that people can publish and >>> maintain their add-ons. >> >> Yes, but we should be pragmatic for Seaside since it is the "flagship" >> until we have the infrastructur set up. >> >> Maybe we should delete it from the core but we can the loading support >> in the dev images. What do you all think? > > I just loaded metacello and used its seaside configuration to load the > 3.0-alpha5 of seaside. > > It hits the 'reading a number failed' bug in 10487-DEV > > ...argh... > > > > ---------------------------- > Johan Brichau > johan.brichau(a)uclouvain.be > > > > > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > -- Lukas Renggli http://www.lukas-renggli.ch

Oct. 20, 2009

[Pharo-project] [update] #10492 (1.0rc1)

by Adrian Lienhard

10492 (this is the stream of the branch 1.0rc1) ----- - Issue 1320: [squeak trunk] Sort the conflicts. This is required when merging a distant version, like Pharo for example... - Issue 1338: HostWindowTests>>testOne is failing in Windows - Issue 1345: Revert Number class>>readFrom: (was integrated with issue 1258) ___________________ http://www.adrian-lienhard.ch/

Oct. 20, 2009

Re: [Pharo-project] '' asNumber -> 'Reading a number failed'

by Nicolas Cellier

2009/10/20 <csrabak(a)bol.com.br>: > I don't see where are we willing to arrive at. > > '' asNumber gives zero in several other Smalltalks (Dolphin and VW, > for example) and used to work as Mariano mentions in earlier versions > of Pharo (which makes me surmise is the way Squeak worked as well). > > So attempting addressing Nicolas point: the context where '' can be > expected is when reading text from some other source (mainly text from > a file) into you Pharo application. > > A library API has to have a reasonable balance between an excruciating > "conceptual right" set of calls and the "principle of minimum > surprise" for the corner cases in general. > > From this discussion, are we saying that for now on in order to have > strings converted into numbers if we want to have the behaviour '' > returning zero we shall change from '' asNumber to '' asNumberOrZero > and this method will call a more general method like this? > > Number>>asNumberOrZero > ^self asNumberOr: 0 > > And > > Number>>asNumberOr: aNumber > ^Number readFrom: self ifFail: [^aNumber] > > Just my .0199999.... > > If this is an identified inter-dialect feature, then some applications will rely on it, and then yes we SHOULD maintain the feature. But we can in no way keep all the silly other cases. However, did you try these in other dialects ' ' asNumber. 'a' asNumber. 'b2' asNumber. etc... I guess VW & Dolphin should fail in all these cases... Squeak did not and would answer 0 in most cases, and that's what I don't want to see anymore... Another question is should we authorize non blank trailing characters ? I think no. '2r' asNumber. '2 + 3' asNumber. etc.. If the feature is OK, I would say: asNumber | strm num | self isEmpty: [^0]. strm := self readStream. strm skipSeparators. num := Number readFrom: strm. "<- if it fails, this message will signal an Error..." strm skipSeparators atEnd ifFalse: [self error: 'I do not represent a valid number']. ^num Nicolas > > > Em 20/10/2009 05:26, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> escreveu: >> Â I like asNumberOrZero we could Â have asNumberOr: aNumber so that we >> are not bound Â to Zero and I would include it. Â Now what the others >> think? Â Stef >> Â On Oct 20, 2009, at 4:31 AM, Nicolas Cellier wrote: >> >> > 2009/10/20 Mariano Martinez Peck : >> >> >> >> On Mon, Oct 19, 2009 at 10:33 PM, Nicolas Cellier wrote: >> >>> Yes, I understand the paradigm, nil is nothing is zero, empty is >> >>> nothing is zero... Â But frankly, do you think Â '' forms a valid >> >>> Number ? In Â every context ? Â So yes, this Â is expected, and can >> >>> break compatibility, but sometimes this is necessary. >> >>> If you want to keep this Â behaviour, you have to use an explicit >> >>> rule like: asNumberOrZero ^Number readFrom: self ifFail: [^0] >> >>> >> >> Thanks Nicolas. Now, the question Â is, do you think we can create >> >> this method in Â String as part of Pharo core? or Â I should add it >> >> to my application? >> >> cheers >> >> mariano >> >> >> > Depends if Â the pattern Â was used by Â many packages or Â not... Â It >> > would be stupid to create 10x Â the same extension to work around a >> > pharo Â change. Â Would Â it Â be Â a Â temporary Â helper Â subject Â to >> > deprecation, or a definitive feature Â ? Â I can't tell, and i don't >> > decide, i only suggest. >> > Nicolas >> > >> >>> Hope this helps... >> >>> Nicolas >> >>> 2009/10/20 Mariano Martinez Peck : >> >>>> Hi folks: In older images, like Â 10418, '' asNumber gave me a 0 >> >>>> (zero). Â But now, I get a 'Reading a number failed'. >> >>>> Is this expected? >> >>>> Perhaps it is due to the fix to this bug: >> >>>> >> >>>> http://code.google.com/p/pharo/issues/detail?can=1&q=1258&colspec=ID%20Type… >> >>>> any toughs? >> >>>> best >> >>>> Mariano > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

Oct. 20, 2009

[Pharo-project] New Pharo and pharo-web based on core 10491

by Damien Cassou

RC1: http://pharo-project.org/pharo-download -- Damien Cassou http://damiencassou.seasidehosting.st "Lambdas are relegated to relative obscurity until Java makes them popular by not having them." James Iry

Oct. 20, 2009

[Pharo-project] String lines/linesDo: cr/crlf/?

by stephan＠stack.nl

What behaviour should I expect from String:linesDo:? The linesDo: in String expects a cr as lineSeparator. lines in *magritte-model-accessing is more flexible, it also accepts crlf. There is no test for this behaviour. In a cross-platform environment (development on OS-X and windows, deployment on linux) I prefer the lines behaviour when reading and writing files. Stephan

Oct. 20, 2009

Re: [Pharo-project] Detecting overriding class extensions

by Damien Cassou

On Tue, Oct 20, 2009 at 1:24 PM, Simon Denier <Simon.Denier(a)inria.fr> wrote: > Does anybody have a tool to detect class extensions which override > methods? Because that's so bad it's evil. You can have a look at the following script which basically warns you if you load a package that overrides a method IIRC. -- Damien Cassou http://damiencassou.seasidehosting.st "Lambdas are relegated to relative obscurity until Java makes them popular by not having them." James Iry

Oct. 20, 2009