- Pharo-dev - lists.pharo.org

Re: [Pharo-project] #traits

by Adrian Lienhard

On Jan 5, 2009, at 13:45 , StÃ©phane Ducasse wrote: > Hi adrian > > I wanted to know if we could not have > traits defined in Behavior and whose behavior would be > > self traitComposition allTraits > sure, seems like a useful shortcut. > BTW will you have some time to look at my improvements? Which ones are you referring to? Adrian

Jan. 5, 2009

Re: [Pharo-project] #traits

by Adrian Lienhard

Damien, thanks for implementing this. I checked your submission, however, the last version, Traits-damiencassou.254, deletes classes like Trait from the system. Something went wrong there. Could you check again? Cheers, Adrian On Jan 5, 2009, at 16:57 , Damien Cassou wrote: > On Mon, Jan 5, 2009 at 1:45 PM, StÃ©phane Ducasse > <stephane.ducasse(a)inria.fr> wrote: >> I wanted to know if we could not have >> traits defined in Behavior and whose behavior would be >> >> self traitComposition allTraits >> >> BTW will you have some time to look at my improvements? > > http://code.google.com/p/pharo/issues/detail?id=433 > > I propose to send #traits instead of #allTraits. #traits returns the > collection of traits used in a behavior whereas #allTraits also > returns the traits that are used by those traits. > > -- > Damien Cassou > http://damiencassou.seasidehosting.st > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

Jan. 5, 2009

Re: [Pharo-project] Fwd: [ANN] Number comparison, hash, NaN, Point, and other partially ordered sets

by StÃ©phane Ducasse

Thanks nicolas I like this kind of discussions because I always learn something. This is cool to have you with us. I will digest that and once marcus is getting better we will certainly start a new harvesting phase. I will probably try to allocate some time soon. We have a deadline for the 15 of January. Argh On Jan 5, 2009, at 7:38 PM, nicolas cellier wrote: > StÃ©phane Ducasse <stephane.ducasse@...> writes: > >> >> Nicolas >> >> could you summarize your solution? >> >> Stef >> >> On Jan 5, 2009, at 12:55 AM, nicolas cellier wrote: >> > > Here is the summary: > > 1) equality relation is not transitive due to inexact asFloat > conversion > > example: > (1/2) = 0.5. "This is exact" > (1/2) + (1/(2 raisedTo: 100)) = 0.5. "This is an inexact conversion" > (1/2) + (1/(2 raisedTo: 100)) ~= (1/2). "If equal where transitive, > they > should be equal" > > Solution: base comparison on inexact->exact conversions rather than > the > contrary... > inexact->exact is called #asTrueFraction (#asExactFraction in GNU > Smalltalk). > > This solution is known from the wise lispers for so long... > http://www.lispworks.com/documentation/lcl50/aug/aug-170.html > This is http://bugs.squeak.org/view.php?id=3374 > > 2) Some numbers are equal, but have different hash codes > > Since some Float can equal some Integer or Fraction, it is necessary > to > change at least 2 out of 3 hash implementations. > > Solution I retained: > - preserve Integer hash > - change Float hash if they have a fractionPart = 0.0 (they are > equal to > anInteger) > - change Fraction hash if they could be equal to a Float (I only test > that denominator is a power of two, which is a necessary but not a > sufficient condition). > > This is http://bugs.squeak.org/view.php?id=6601, and > http://bugs.squeak.org/view.php?id=3360, solution has been posted at > #3374. > > Note: this results in loosing a little speed for small Float hash, and > lot more for large Float hash. > But make it right > make it fast... > > 3) Comparing Float nan to a Float or an Integer does not follow IEEE > 754 > conventions > comparison should always return false since nan cannot be ordered. > > Magnitude assume subInstances form a totally ordered set. > Thus Number is not a well behaved Magnitude. > > Consequently, Number must define not only < but also <= >= and > > Note that only < and <= would be strictly necessary. > The other two could be defined like this: >> b > ^b < self >> = b > ^b <= self > > I choose to change >= implementation in Magnitude, and reimplement > everything in Number subclasses > (though > and >= would not be strictly necessary). > > This is http://bugs.squeak.org/view.php?id=6719 > > But the VM also makes same assumption as Magnitude and must be changed > too - this is http://bugs.squeak.org/view.php?id=7260 > > 4) Comparing a Number and a Point is weird (different result with an > Integer and a Float) > > Float did coerce to a Point, then compare. > Integer did use a false total order assumption through super > Magnitude. > > Two main solutions: > - either coerce Number to a Point (might be implicitely used this > way in > the image... hard to tell). > - or raise an Exception > > Solution: I choosed to raise an Exception. > > This is http://bugs.squeak.org/view.php?id=7259 > > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >

Jan. 5, 2009

Re: [Pharo-project] Collection extensions

by StÃ©phane Ducasse

Interesting to see that you need that kind of check. Could you explain why? a button could return something else that a boolean ? On Jan 5, 2009, at 7:28 PM, Gary Chambers wrote: > In a similar vein, one I have found useful with the Report Builder for > enablement of toolbar buttons/menu options in a multiple selection > case: > > isHomogeneous: aBlock > "Answer whether the result of evaluating the given > block for each element of the receiver has the same > value in each case." > > |val| > self ifEmpty: [^true]. > val := aBlock value: self anyOne. > ^self allSatisfy: [:e | (aBlock value: e) = val] > > Regards, Gary. > > ----- Original Message ----- > From: "Alexandre Bergel" <alexandre(a)bergel.eu> > To: <Pharo-project(a)lists.gforge.inria.fr> > Sent: Monday, January 05, 2009 6:02 PM > Subject: Re: [Pharo-project] Collection extensions > > >> + 1 >> >> On 5 Jan 2009, at 14:53, Gary Chambers wrote: >> >>> Can't remember the number of times I've had to implement these kinds >>> of >>> generally useful methods on various Smalltalk dialects (particularly >>> #groupedBy:, called it #categorizedBy: myself ;-) ). Really should >>> be part >>> of all Smalltalks. I'd push for general adoption/standardisation for >>> every >>> dialect! That's the only way Smalltalk is going to evolve, the "ANSI >>> standard" is years behind! >>> >>> Regards, Gary. >>> >>>> >>>> So why do we do pharo. Really. If everything as to be compatible >>>> with >>>> other >>>> smalltalk. Terrible. >>>> Can't we get smarter? >>>> Why can't we tag the methods with <notAnsi> and build a tool that >>>> check when you >>>> do a fill out. I do not write code to be portable to VisualWorks >>>> so? >>>> >>>>> I would prefer to have such extension methods separate from the >>>>> core. >>>> >>>> Me not. Because then in a lot of places I will have to inline their >>>> body. >>>> >>>> Stef >>>> >>>> >>>> _______________________________________________ >>>> Pharo-project mailing list >>>> Pharo-project(a)lists.gforge.inria.fr >>>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >>> >>> >>> _______________________________________________ >>> Pharo-project mailing list >>> Pharo-project(a)lists.gforge.inria.fr >>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >>> >> >> -- >> _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: >> Alexandre Bergel http://www.bergel.eu >> ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. >> >> >> >> >> >> >> _______________________________________________ >> Pharo-project mailing list >> Pharo-project(a)lists.gforge.inria.fr >> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >

Jan. 5, 2009

[Pharo-project] Pharo Issues

by Brian Brown

Greetings all, I download the latest image from the site (10196 dev), and selected "Software update" from the System Menu. There is an error with update: 10201-Pha-FlapTabViewerObjectPassOneOverScriptSyst While it is in the "Adding Versions" step, we get an exception trying to read a stream on this file: Sixx-stephane_ducasse.2.mcz Here is the traceback: UndefinedObject(Object)>>doesNotUnderstand: #readStream MCScanner class>>scanTokens: MCMczReader>>parseMember: MCMczReader>>loadPackage MCMczReader(MCVersionReader)>>package MCMczReader(MCVersionReader)>>basicVersion MCMczReader(MCVersionReader)>>version [] in MCHttpRepository(MCFileBasedRepository)>>loadVersionFromFileNamed: {[:r | r version]} BlockContext>>valueWithPossibleArgs: MCMczReader(ProtoObject)>>ifNotNil: MCHttpRepository>>versionReaderForFileNamed:do: MCHttpRepository(MCFileBasedRepository)>>loadVersionFromFileNamed: [] in ScriptLoader>>loadTogether:merge: {[:fn | loader addVersion: (self repository loadVersionFromFileNamed: fn)]} [] in OrderedCollection(SequenceableCollection)>>do:displayingProgress: {[:each :i | bar value: i. aBlock value: each]} OrderedCollection(SequenceableCollection)>>withIndexDo: [] in OrderedCollection(SequenceableCollection)>>do:displayingProgress: {[:bar | self withIndexDo: [:each :i | bar value: i. aBlock value: e...]} [] in ProgressInitiationException>>defaultAction {[result := workBlock value: progress]} BlockContext>>ensure: ProgressInitiationException>>defaultAction UndefinedObject>>handleSignal: MethodContext(ContextPart)>>handleSignal: MethodContext(ContextPart)>>handleSignal: ProgressInitiationException(Exception)>>signal ProgressInitiationException>>display:at:from:to:during: ProgressInitiationException class>>display:at:from:to:during: ByteString(String)>>displayProgressAt:from:to:during: OrderedCollection(SequenceableCollection)>>do:displayingProgress: ScriptLoader>>loadTogether:merge: ScriptLoader>>script280 ScriptLoader>>update10201 UndefinedObject>>DoIt Compiler>>evaluate:in:to:notifying:ifFail:logged: Compiler class>>evaluate:for:notifying:logged: Compiler class>>evaluate:for:logged: Compiler class>>evaluate:logged: [] in MultiByteBinaryOrTextStream(PositionableStream)>>fileInAnnouncing: {[val := (self peekFor: $!) ifTrue: [(Compiler evaluate: self nextChunk l...]} BlockContext>>on:do: [] in MultiByteBinaryOrTextStream(PositionableStream)>>fileInAnnouncing: {[:bar | [self atEnd] whileFalse: [bar value: self position. self skipS...]} [] in ProgressInitiationException>>defaultAction {[result := workBlock value: progress]} BlockContext>>ensure: ProgressInitiationException>>defaultAction UndefinedObject>>handleSignal: MethodContext(ContextPart)>>handleSignal: ProgressInitiationException(Exception)>>signal ProgressInitiationException>>display:at:from:to:during: ProgressInitiationException class>>display:at:from:to:during: ByteString(String)>>displayProgressAt:from:to:during: MultiByteBinaryOrTextStream(PositionableStream)>>fileInAnnouncing: [] in ChangeSet class>>newChangesFromStream:named: {[newSet ifNotNil: [(aStream respondsTo: #converter:) ifTrue: [newStrea...]} BlockContext>>ensure: ChangeSet class>>newChangesFromStream:named: [] in Utilities class>>readServer:special:updatesThrough:saveLocally:updateImage: {[:bar | [this := docQueue next. nextDoc := docQueue next. nextDoc = #fail...]} [] in ProgressInitiationException>>defaultAction {[result := workBlock value: progress]} BlockContext>>ensure: ProgressInitiationException>>defaultAction UndefinedObject>>handleSignal: MethodContext(ContextPart)>>handleSignal: ProgressInitiationException(Exception)>>signal ProgressInitiationException>>display:at:from:to:during: ProgressInitiationException class>>display:at:from:to:during: ByteString(String)>>displayProgressAt:from:to:during: [] in Utilities class>>readServer:special:updatesThrough:saveLocally:updateImage: {[urls := self newUpdatesOn: (serverList collect: [:url | url , 'up...]} BlockContext>>ensure: CursorWithMask(Cursor)>>showWhile: Utilities class>>readServer:special:updatesThrough:saveLocally:updateImage: Utilities class>>readServerUpdatesThrough:saveLocally:updateImage: Utilities class>>readServerUpdatesSaveLocally:updateImage: Utilities class>>updateFromServer TheWorldMenu>>doMenuItem:with: [] in ToggleMenuItemMorph(MenuItemMorph)>>invokeWithEvent: {[(selArgCount := selector numArgs) = 0 ifTrue: [target perform: selector] ...]} BlockContext>>ensure: CursorWithMask(Cursor)>>showWhile: ToggleMenuItemMorph(MenuItemMorph)>>invokeWithEvent: ToggleMenuItemMorph(MenuItemMorph)>>mouseUp: ToggleMenuItemMorph(MenuItemMorph)>>handleMouseUp: MouseButtonEvent>>sentTo: ToggleMenuItemMorph(Morph)>>handleEvent: MorphicEventDispatcher>>dispatchDefault:with: MorphicEventDispatcher>>dispatchEvent:with: ToggleMenuItemMorph(Morph)>>processEvent:using: MorphicEventDispatcher>>dispatchDefault:with: MorphicEventDispatcher>>dispatchEvent:with: MenuMorph(Morph)>>processEvent:using: MenuMorph(Morph)>>processEvent: MenuMorph>>handleFocusEvent: [] in HandMorph>>sendFocusEvent:to:clear: {[ActiveHand := self. ActiveEvent := anEvent. result := focusHolder han...]} [] in PasteUpMorph>>becomeActiveDuring: {[aBlock value]} BlockContext>>on:do: PasteUpMorph>>becomeActiveDuring: HandMorph>>sendFocusEvent:to:clear: HandMorph>>sendEvent:focus:clear: HandMorph>>sendMouseEvent: HandMorph>>handleEvent: HandMorph>>processEvents [] in WorldState>>doOneCycleNowFor: {[:h | ActiveHand := h. h processEvents. ActiveHand := nil]} Array(SequenceableCollection)>>do: WorldState>>handsDo: WorldState>>doOneCycleNowFor: WorldState>>doOneCycleFor: PasteUpMorph>>doOneCycle [] in Project class>>spawnNewProcess {[[World doOneCycle. Processor yield. false] whileFalse. nil]} [] in BlockContext>>newProcess {[self value. Processor terminateActive]}

Jan. 5, 2009

Re: [Pharo-project] DictionaryTest

by StÃ©phane Ducasse

Alex are the sorted and changes that were in 136 included in the new ones? Stef On Jan 5, 2009, at 6:27 PM, Alexandre Bergel wrote: > MC behaved strangely. > > I produced a new version: > -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= > Name: CollectionsTests-AlexandreBergel.142 > Author: AlexandreBergel > Time: 5 January 2009, 2:24:21 pm > UUID: 0e32b9b7-708d-4c01-913a-2a07c9319ac7 > Ancestors: CollectionsTests-AlexandreBergel.141 > > More test in DictionaryTest. The class Dictionary is now covered at > 66% > -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= > > I checked, and it is not empty > > Alexandre > > On 5 Jan 2009, at 13:14, StÃ©phane Ducasse wrote: > >> Alex >> >> I do not really understand since 139, 138 are also empty when I >> browse >> them via the squeaksource web ui >> I can move everything to treated and you republish the package. >> I really want to see this code can you send to me a package via >> email? >> >> Stef >> >> On Jan 5, 2009, at 3:58 PM, Lukas Renggli wrote: >> >>>> If I browse the file CollectionsTests-AlexandreBergel.140 within >>>> Squeak stored on PharoInbox, I see the content. If I go on >>>> squeaksource, and look the content of the version that I saved, it >>>> is >>>> empty. I tried to save CollectionTests, but the content is empty. >>>> Any >>>> hint? >>> >>> The Pharo image uses the cache in memory or on your file-system to >>> display mcz files you recently committed. You should ask an >>> administrator of the PharoInbox to delete the defective version from >>> the repository and try to copy your local version to >>> squeaksource.com >>> again. >>> >>> Lukas >>> >>> -- >>> 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 >>> >> >> >> _______________________________________________ >> Pharo-project mailing list >> Pharo-project(a)lists.gforge.inria.fr >> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >> > > -- > _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: > Alexandre Bergel http://www.bergel.eu > ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. > > > > > > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >

Jan. 5, 2009

[Pharo-project] Fwd: [ANN] Number comparison, hash, NaN, Point, and other partially ordered sets

by nicolas cellier

StÃ©phane Ducasse <stephane.ducasse@...> writes: > > Nicolas > > could you summarize your solution? > > Stef > > On Jan 5, 2009, at 12:55 AM, nicolas cellier wrote: > Here is the summary: 1) equality relation is not transitive due to inexact asFloat conversion example: (1/2) = 0.5. "This is exact" (1/2) + (1/(2 raisedTo: 100)) = 0.5. "This is an inexact conversion" (1/2) + (1/(2 raisedTo: 100)) ~= (1/2). "If equal where transitive, they should be equal" Solution: base comparison on inexact->exact conversions rather than the contrary... inexact->exact is called #asTrueFraction (#asExactFraction in GNU Smalltalk). This solution is known from the wise lispers for so long... http://www.lispworks.com/documentation/lcl50/aug/aug-170.html This is http://bugs.squeak.org/view.php?id=3374 2) Some numbers are equal, but have different hash codes Since some Float can equal some Integer or Fraction, it is necessary to change at least 2 out of 3 hash implementations. Solution I retained: - preserve Integer hash - change Float hash if they have a fractionPart = 0.0 (they are equal to anInteger) - change Fraction hash if they could be equal to a Float (I only test that denominator is a power of two, which is a necessary but not a sufficient condition). This is http://bugs.squeak.org/view.php?id=6601, and http://bugs.squeak.org/view.php?id=3360, solution has been posted at #3374. Note: this results in loosing a little speed for small Float hash, and lot more for large Float hash. But make it right > make it fast... 3) Comparing Float nan to a Float or an Integer does not follow IEEE 754 conventions comparison should always return false since nan cannot be ordered. Magnitude assume subInstances form a totally ordered set. Thus Number is not a well behaved Magnitude. Consequently, Number must define not only < but also <= >= and > Note that only < and <= would be strictly necessary. The other two could be defined like this: > b ^b < self >= b ^b <= self I choose to change >= implementation in Magnitude, and reimplement everything in Number subclasses (though > and >= would not be strictly necessary). This is http://bugs.squeak.org/view.php?id=6719 But the VM also makes same assumption as Magnitude and must be changed too - this is http://bugs.squeak.org/view.php?id=7260 4) Comparing a Number and a Point is weird (different result with an Integer and a Float) Float did coerce to a Point, then compare. Integer did use a false total order assumption through super Magnitude. Two main solutions: - either coerce Number to a Point (might be implicitely used this way in the image... hard to tell). - or raise an Exception Solution: I choosed to raise an Exception. This is http://bugs.squeak.org/view.php?id=7259

Jan. 5, 2009

Re: [Pharo-project] Collection extensions

by Gary Chambers

In a similar vein, one I have found useful with the Report Builder for enablement of toolbar buttons/menu options in a multiple selection case: isHomogeneous: aBlock "Answer whether the result of evaluating the given block for each element of the receiver has the same value in each case." |val| self ifEmpty: [^true]. val := aBlock value: self anyOne. ^self allSatisfy: [:e | (aBlock value: e) = val] Regards, Gary. ----- Original Message ----- From: "Alexandre Bergel" <alexandre(a)bergel.eu> To: <Pharo-project(a)lists.gforge.inria.fr> Sent: Monday, January 05, 2009 6:02 PM Subject: Re: [Pharo-project] Collection extensions >+ 1 > > On 5 Jan 2009, at 14:53, Gary Chambers wrote: > >> Can't remember the number of times I've had to implement these kinds >> of >> generally useful methods on various Smalltalk dialects (particularly >> #groupedBy:, called it #categorizedBy: myself ;-) ). Really should >> be part >> of all Smalltalks. I'd push for general adoption/standardisation for >> every >> dialect! That's the only way Smalltalk is going to evolve, the "ANSI >> standard" is years behind! >> >> Regards, Gary. >> >>> >>> So why do we do pharo. Really. If everything as to be compatible with >>> other >>> smalltalk. Terrible. >>> Can't we get smarter? >>> Why can't we tag the methods with <notAnsi> and build a tool that >>> check when you >>> do a fill out. I do not write code to be portable to VisualWorks so? >>> >>>> I would prefer to have such extension methods separate from the >>>> core. >>> >>> Me not. Because then in a lot of places I will have to inline their >>> body. >>> >>> Stef >>> >>> >>> _______________________________________________ >>> Pharo-project mailing list >>> Pharo-project(a)lists.gforge.inria.fr >>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >> >> >> _______________________________________________ >> Pharo-project mailing list >> Pharo-project(a)lists.gforge.inria.fr >> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >> > > -- > _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: > Alexandre Bergel http://www.bergel.eu > ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. > > > > > > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

Jan. 5, 2009

Re: [Pharo-project] Collection extensions

by Alexandre Bergel

+ 1 On 5 Jan 2009, at 14:53, Gary Chambers wrote: > Can't remember the number of times I've had to implement these kinds > of > generally useful methods on various Smalltalk dialects (particularly > #groupedBy:, called it #categorizedBy: myself ;-) ). Really should > be part > of all Smalltalks. I'd push for general adoption/standardisation for > every > dialect! That's the only way Smalltalk is going to evolve, the "ANSI > standard" is years behind! > > Regards, Gary. > >> >> So why do we do pharo. Really. If everything as to be compatible with >> other >> smalltalk. Terrible. >> Can't we get smarter? >> Why can't we tag the methods with <notAnsi> and build a tool that >> check when you >> do a fill out. I do not write code to be portable to VisualWorks so? >> >>> I would prefer to have such extension methods separate from the >>> core. >> >> Me not. Because then in a lot of places I will have to inline their >> body. >> >> Stef >> >> >> _______________________________________________ >> Pharo-project mailing list >> Pharo-project(a)lists.gforge.inria.fr >> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.

Jan. 5, 2009

Re: [Pharo-project] Collection extensions

by Gary Chambers

Can't remember the number of times I've had to implement these kinds of generally useful methods on various Smalltalk dialects (particularly #groupedBy:, called it #categorizedBy: myself ;-) ). Really should be part of all Smalltalks. I'd push for general adoption/standardisation for every dialect! That's the only way Smalltalk is going to evolve, the "ANSI standard" is years behind! Regards, Gary. > > So why do we do pharo. Really. If everything as to be compatible with > other > smalltalk. Terrible. > Can't we get smarter? > Why can't we tag the methods with <notAnsi> and build a tool that > check when you > do a fill out. I do not write code to be portable to VisualWorks so? > >> I would prefer to have such extension methods separate from the core. > > Me not. Because then in a lot of places I will have to inline their > body. > > Stef > > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

Jan. 5, 2009