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

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

Re: [Pharo-project] Collection extensions

by Janko MivÅ¡ek

Hi Stef, StÃ©phane Ducasse wrote: > 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. One of Pharo goals is to become a professional tool for serious development, specially for web apps. This implies that it should be conservative regarding introducing new and specially incompatible extensions. Because web apps are destined to be portable, so Pharo shall behave nice to other Smalltalks and avoid introducing some completely different methods in basic classes. But on the other side I agree with you, Pharo shall not be tied with that requirement too much and shall extend itself. Kind of tagging of methods as portable, pharo only etc. can therefore be a solution. Alexandre's proposal with Lint rules sounds good to me too. I would also suggest to do some promotion of good extensions to other Smalltalks as well. That way slowly Smalltalk as a whole will evolve! Pharo is right now in wonderful position to achieve such a common good for Smalltalk! Best regards Janko -- Janko MivÅ¡ek AIDA/Web Smalltalk Web Application Server http://www.aidaweb.si

Jan. 5, 2009

Re: [Pharo-project] DictionaryTest

by Alexandre Bergel

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 ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.

Jan. 5, 2009