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

Re: [Pharo-project] Stack should be reimplemented with Array

by Igor Stasenko

On 19 October 2010 00:25, Levente Uzonyi <leves(a)elte.hu> wrote: > On Mon, 18 Oct 2010, Igor Stasenko wrote: > >> Stephane, i could say more: >> - i don't like how LinkedList implemented. >> >> I don't see why it should mimic things like #at: #at:put: at all.. > > It's not mimicing those methods. A list usually support things like this, > but the user should know the consequences. > The consequences of such approach is much more far-reaching: leads to bad design practices, crappy application performance, and then tons of bugs and workarounds. >> IMO this protocol should be pruned from it, to not provoke uses which >> completely do not fit for given data structure. > > I'm not sure if it's okay to remove features, because users lacking really > basic CS knowledge may use them the wrong way. > Imo, we should prohibit this from the beginning. Standard, core classes should not contain an API, which could lead to careless, abusive programming techniques. IMO, a kernel APIs should serve not only as an implementation of basic system funcionality, it also must serve as guide, how to best use these facilities, so people will learn what is the right way to use it. We should teach users to use right tools for things they need. >> >> Removing/inserting into the middle of list is quite ineffective >> operation (O(n)), > > As long as you don't give away the link objects, it's O(n), otherwise it can > be O(1). giving away link objects... oh, that's the worst thing, which could possibly happen :) > >> while inserting at the begginning/end of list is O(1). >> >> Lists are sequenceable.. but sequenceable ~~ indexable. Period. > > Sequenceable is indexable, but good performance is not guaranteed. > Unless you representing an infinite collection(s). Streams are good example of sequenceable, however non-indexable containers. > > Levente > >> >> -- >> Best regards, >> Igor Stasenko AKA sig. >> >> _______________________________________________ >> 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 > -- Best regards, Igor Stasenko AKA sig.

Oct. 18, 2010

Re: [Pharo-project] [squeak-dev] SharedQueue does scale (was: Re: SharedQueue doesn't scale)

by Levente Uzonyi

On Mon, 18 Oct 2010, Igor Stasenko wrote: snip > Thanks, Levente for giving a feedback. Please, feel free to shape my classes in more complete from (such as proper naming), to make them ready for inclusion in both Squeak's and Pharo cores. I propose the following names: AtomicQueue (base class) -> AtomicCollection FIFOQueue -> AtomicQueue LIFOQueue -> AtomicStack If you, or anyone else having better suggestions, speak now :) I think these should be the names: FIFOQueue -> SharedQueue LIFOQueue -> SharedStack I don't know a really good name for AtomicQueue, maybe SharedList, SharedCollection or SharedListStub. Levente In any case, i'm am open to discuss further details and possible caveats of using new classes to anyone interested in using them. P.S. As a side note, i now can explain (to myself at first place), why i intuitively choosed to used atomic swap instead of CAS. Because it fits better fits with smalltalk language semantics: A swap operation in smalltalk implemented as two assignments: x := y. y := z. An assignments is basic operation, which have nothing to do with late-bound nature of language. Unless we going to introduce a meta-object protocol(s), which could turn a simple assignment into some message sends under the hood, it will remain a basic, early-bound operation. And even if we do, it is highly unlikely, that even then we will throw away the old, simple assignment, which identifies an assignment source & target at compile time. In contrast, a CAS operation , if written in smalltalk looks like: (a == b ) ifTrue: [ a := c ] so, it having two message sends (#== , #ifTrue:), and from strict, pure language perspective, this using a late-bound semantics (a message sends), and as any message send, the message result and behavior cannot be predicted at compile time and therefore its wrong to assume that such statement could be an atomic operation. Unless, of course, we introduce a new language syntax which will denote a CAS operation explicitly. > > Levente > > > snip > -- Best regards, Igor Stasenko AKA sig. _______________________________________________ Pharo-project mailing list Pharo-project(a)lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

Oct. 18, 2010

[Pharo-project] SqueakSource are down

by Igor Stasenko

Hello, :( Guys, are there a reason , why we can't address this problem once and for all? -- Best regards, Igor Stasenko AKA sig.

Oct. 18, 2010

Re: [Pharo-project] Speeding up Pharo 1.1

by Igor Stasenko

2010/10/19 Levente Uzonyi <leves(a)elte.hu>: > On Tue, 19 Oct 2010, Igor Stasenko wrote: > >> On 19 October 2010 00:30, Henrik Sperre Johansen > > <henrik.s.johansen(a)veloxit.no> wrote: >> >> Â On 18.10.2010 23:21, Igor Stasenko wrote: >>> >>> 2010/10/19 Levente Uzonyi<leves(a)elte.hu>: >>>> >>>> On Mon, 18 Oct 2010, Nicolas Cellier wrote: >>>> >>>>> 2010/10/18 Igor Stasenko<siguctua(a)gmail.com>: >>>>>> >>>>>> On 18 October 2010 23:18, Nicolas Cellier >>>>>> <nicolas.cellier.aka.nice(a)gmail.com> Â wrote: >>>>>>> >>>>>>> 2010/10/17 Levente Uzonyi<leves(a)elte.hu>: >>>>>>>> >>>>>>>> On Sat, 16 Oct 2010, Bart Veenstra wrote: >>>>>>>> >>>>>>>>> Hi list, >>>>>>>>> >>>>>>>>> I have been working with Pharo for almost a month now, and I >>>>>>>>> suspect >>>>>>>>> that the performance is degrading fast. UI tasks takes several >>>>>>>>> seconds >>>>>>>>> to react to my keyboard. >>>>>>>> >>>>>>>> That kind of sluggishness is probably related to finalization/gc. >>>>>>>> Please >>>>>>>> send us the result of the following expression: >>>>>>>> >>>>>>>> (WeakArray classPool at: #FinalizationDependents) >>>>>>>> Â Â Â Â select: [ :each | each notNil ] >>>>>>>> Â Â Â Â thenCollect: [ :each | each class -> Â each size ] >>>>>>>> >>>>>>> While updating pharo 1.2, after an EndOfCentralDirectory error, I got >>>>>>> a very unresponsive image... >>>>>>> >>>>>>> ((WeakArray classPool at: #FinalizationDependents) as: Array) >>>>>>> Â Â Â select: [ :each | each notNil ] >>>>>>> Â Â Â thenCollect: [ :each | each class -> Â each size] >>>>>>> -> >>>>>>> {(WeakIdentityKeyDictionary->22370). >>>>>> >>>>>> This is an MC cache. And major reason of image slowdown. >>>>>> >>>>> Levente did this simplification in trunk: >>>>> >>>>> cachedDefinitions >>>>> Â Â Â Â ^definitions ifNil: [ definitions := WeakIdentityKeyDictionary >>>>> new >>>>> ] >>>>> >>>>> It would be worth a try in Pharo. >>>> >>>> IIRC Pharo's WeakKeyDictionary (and subclasses) don't work properly if >>>> they're not registered to the finalization process. So this won't work >>>> as >>>> long as that's not fixed. >>>> >>> Huh? Can you provide a code to show it? Test case please? >>> >> Just add lots of objects which will be GC'd to an unregistered >> WeakKeyDictionary. >> After X objects are gc'd, you'd still have X nil-keyed associations in the >> dictionary. >> Add Y objects, gc those, and you have X+Y nil-keys in the dict. >> (If dict grown/rehashed, all nicely placed index 1 onwards) >> > > it doesn't sounds like incorrect behavior (i.e. pruning a nil-ed keys > before #finalizeValues could visit them). > > > It's incorrect, because WeakKeyDictionaries are not designed to be accessed > concurrently, but this can happen if the dictionary is registered to the > finalization process. True. Another reason to not register them like MC in Pharo currently does. > It's inefficient, because someone has to send #finalizeValues, even when > there's no finalization action. > That's why in my patch, i placed #finalizeValues on finishing package load/unload actions. > > Levente > > >> Cheers, >> Henry >> >> _______________________________________________ >> Pharo-project mailing list >> Pharo-project(a)lists.gforge.inria.fr >> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >> > > > > -- > Best regards, > Igor Stasenko AKA sig. > > _______________________________________________ > 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 > -- Best regards, Igor Stasenko AKA sig.

Oct. 18, 2010

Re: [Pharo-project] Speeding up Pharo 1.1

by Levente Uzonyi

On Tue, 19 Oct 2010, Igor Stasenko wrote: > On 19 October 2010 00:30, Henrik Sperre Johansen <henrik.s.johansen(a)veloxit.no> wrote: > Â On 18.10.2010 23:21, Igor Stasenko wrote: >> >> 2010/10/19 Levente Uzonyi<leves(a)elte.hu>: >>> >>> On Mon, 18 Oct 2010, Nicolas Cellier wrote: >>> >>>> 2010/10/18 Igor Stasenko<siguctua(a)gmail.com>: >>>>> >>>>> On 18 October 2010 23:18, Nicolas Cellier >>>>> <nicolas.cellier.aka.nice(a)gmail.com> Â wrote: >>>>>> >>>>>> 2010/10/17 Levente Uzonyi<leves(a)elte.hu>: >>>>>>> >>>>>>> On Sat, 16 Oct 2010, Bart Veenstra wrote: >>>>>>> >>>>>>>> Hi list, >>>>>>>> >>>>>>>> I have been working with Pharo for almost a month now, and I suspect >>>>>>>> that the performance is degrading fast. UI tasks takes several >>>>>>>> seconds >>>>>>>> to react to my keyboard. >>>>>>> >>>>>>> That kind of sluggishness is probably related to finalization/gc. >>>>>>> Please >>>>>>> send us the result of the following expression: >>>>>>> >>>>>>> (WeakArray classPool at: #FinalizationDependents) >>>>>>> Â Â Â Â select: [ :each | each notNil ] >>>>>>> Â Â Â Â thenCollect: [ :each | each class -> Â each size ] >>>>>>> >>>>>> While updating pharo 1.2, after an EndOfCentralDirectory error, I got >>>>>> a very unresponsive image... >>>>>> >>>>>> ((WeakArray classPool at: #FinalizationDependents) as: Array) >>>>>> Â Â Â select: [ :each | each notNil ] >>>>>> Â Â Â thenCollect: [ :each | each class -> Â each size] >>>>>> -> >>>>>> {(WeakIdentityKeyDictionary->22370). >>>>> >>>>> This is an MC cache. And major reason of image slowdown. >>>>> >>>> Levente did this simplification in trunk: >>>> >>>> cachedDefinitions >>>> Â Â Â Â ^definitions ifNil: [ definitions := WeakIdentityKeyDictionary >>>> new >>>> ] >>>> >>>> It would be worth a try in Pharo. >>> >>> IIRC Pharo's WeakKeyDictionary (and subclasses) don't work properly if >>> they're not registered to the finalization process. So this won't work as >>> long as that's not fixed. >>> >> Huh? Can you provide a code to show it? Test case please? >> > Just add lots of objects which will be GC'd to an unregistered > WeakKeyDictionary. > After X objects are gc'd, you'd still have X nil-keyed associations in the > dictionary. > Add Y objects, gc those, and you have X+Y nil-keys in the dict. > (If dict grown/rehashed, all nicely placed index 1 onwards) > it doesn't sounds like incorrect behavior (i.e. pruning a nil-ed keys before #finalizeValues could visit them). It's incorrect, because WeakKeyDictionaries are not designed to be accessed concurrently, but this can happen if the dictionary is registered to the finalization process. It's inefficient, because someone has to send #finalizeValues, even when there's no finalization action. Levente > Cheers, > Henry > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > -- Best regards, Igor Stasenko AKA sig. _______________________________________________ Pharo-project mailing list Pharo-project(a)lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

Oct. 18, 2010

Re: [Pharo-project] Speeding up Pharo 1.1

by Henrik Sperre Johansen

On 18.10.2010 23:43, Igor Stasenko wrote: > On 19 October 2010 00:30, Henrik Sperre Johansen > <henrik.s.johansen(a)veloxit.no> wrote: >> On 18.10.2010 23:21, Igor Stasenko wrote: >>> 2010/10/19 Levente Uzonyi<leves(a)elte.hu>: >>>> On Mon, 18 Oct 2010, Nicolas Cellier wrote: >>>> >>>>> 2010/10/18 Igor Stasenko<siguctua(a)gmail.com>: >>>>>> On 18 October 2010 23:18, Nicolas Cellier >>>>>> <nicolas.cellier.aka.nice(a)gmail.com> wrote: >>>>>>> 2010/10/17 Levente Uzonyi<leves(a)elte.hu>: >>>>>>>> On Sat, 16 Oct 2010, Bart Veenstra wrote: >>>>>>>> >>>>>>>>> Hi list, >>>>>>>>> >>>>>>>>> I have been working with Pharo for almost a month now, and I suspect >>>>>>>>> that the performance is degrading fast. UI tasks takes several >>>>>>>>> seconds >>>>>>>>> to react to my keyboard. >>>>>>>> That kind of sluggishness is probably related to finalization/gc. >>>>>>>> Please >>>>>>>> send us the result of the following expression: >>>>>>>> >>>>>>>> (WeakArray classPool at: #FinalizationDependents) >>>>>>>> select: [ :each | each notNil ] >>>>>>>> thenCollect: [ :each | each class -> each size ] >>>>>>>> >>>>>>> While updating pharo 1.2, after an EndOfCentralDirectory error, I got >>>>>>> a very unresponsive image... >>>>>>> >>>>>>> ((WeakArray classPool at: #FinalizationDependents) as: Array) >>>>>>> select: [ :each | each notNil ] >>>>>>> thenCollect: [ :each | each class -> each size] >>>>>>> -> >>>>>>> {(WeakIdentityKeyDictionary->22370). >>>>>> This is an MC cache. And major reason of image slowdown. >>>>>> >>>>> Levente did this simplification in trunk: >>>>> >>>>> cachedDefinitions >>>>> ^definitions ifNil: [ definitions := WeakIdentityKeyDictionary >>>>> new >>>>> ] >>>>> >>>>> It would be worth a try in Pharo. >>>> IIRC Pharo's WeakKeyDictionary (and subclasses) don't work properly if >>>> they're not registered to the finalization process. So this won't work as >>>> long as that's not fixed. >>>> >>> Huh? Can you provide a code to show it? Test case please? >>> >> Just add lots of objects which will be GC'd to an unregistered >> WeakKeyDictionary. >> After X objects are gc'd, you'd still have X nil-keyed associations in the >> dictionary. >> Add Y objects, gc those, and you have X+Y nil-keys in the dict. >> (If dict grown/rehashed, all nicely placed index 1 onwards) >> > it doesn't sounds like incorrect behavior (i.e. pruning a nil-ed keys > before #finalizeValues could visit them). > Except, you know, if they're not registered for finalization at all, they're probably not meant to be finalized. Cheers, Henry

Oct. 18, 2010

Re: [Pharo-project] Speeding up Pharo 1.1

by Igor Stasenko

On 19 October 2010 00:30, Henrik Sperre Johansen <henrik.s.johansen(a)veloxit.no> wrote: > Â On 18.10.2010 23:21, Igor Stasenko wrote: >> >> 2010/10/19 Levente Uzonyi<leves(a)elte.hu>: >>> >>> On Mon, 18 Oct 2010, Nicolas Cellier wrote: >>> >>>> 2010/10/18 Igor Stasenko<siguctua(a)gmail.com>: >>>>> >>>>> On 18 October 2010 23:18, Nicolas Cellier >>>>> <nicolas.cellier.aka.nice(a)gmail.com> Â wrote: >>>>>> >>>>>> 2010/10/17 Levente Uzonyi<leves(a)elte.hu>: >>>>>>> >>>>>>> On Sat, 16 Oct 2010, Bart Veenstra wrote: >>>>>>> >>>>>>>> Hi list, >>>>>>>> >>>>>>>> I have been working with Pharo for almost a month now, and I suspect >>>>>>>> that the performance is degrading fast. UI tasks takes several >>>>>>>> seconds >>>>>>>> to react to my keyboard. >>>>>>> >>>>>>> That kind of sluggishness is probably related to finalization/gc. >>>>>>> Please >>>>>>> send us the result of the following expression: >>>>>>> >>>>>>> (WeakArray classPool at: #FinalizationDependents) >>>>>>> Â Â Â Â select: [ :each | each notNil ] >>>>>>> Â Â Â Â thenCollect: [ :each | each class -> Â each size ] >>>>>>> >>>>>> While updating pharo 1.2, after an EndOfCentralDirectory error, I got >>>>>> a very unresponsive image... >>>>>> >>>>>> ((WeakArray classPool at: #FinalizationDependents) as: Array) >>>>>> Â Â Â select: [ :each | each notNil ] >>>>>> Â Â Â thenCollect: [ :each | each class -> Â each size] >>>>>> -> >>>>>> {(WeakIdentityKeyDictionary->22370). >>>>> >>>>> This is an MC cache. And major reason of image slowdown. >>>>> >>>> Levente did this simplification in trunk: >>>> >>>> cachedDefinitions >>>> Â Â Â Â ^definitions ifNil: [ definitions := WeakIdentityKeyDictionary >>>> new >>>> ] >>>> >>>> It would be worth a try in Pharo. >>> >>> IIRC Pharo's WeakKeyDictionary (and subclasses) don't work properly if >>> they're not registered to the finalization process. So this won't work as >>> long as that's not fixed. >>> >> Huh? Can you provide a code to show it? Test case please? >> > Just add lots of objects which will be GC'd to an unregistered > WeakKeyDictionary. > After X objects are gc'd, you'd still have X nil-keyed associations in the > dictionary. > Add Y objects, gc those, and you have X+Y nil-keys in the dict. > (If dict grown/rehashed, all nicely placed index 1 onwards) > it doesn't sounds like incorrect behavior (i.e. pruning a nil-ed keys before #finalizeValues could visit them). > Cheers, > Henry > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > -- Best regards, Igor Stasenko AKA sig.

Oct. 18, 2010

Re: [Pharo-project] Speeding up Pharo 1.1

by Henrik Sperre Johansen

On 18.10.2010 23:21, Igor Stasenko wrote: > 2010/10/19 Levente Uzonyi<leves(a)elte.hu>: >> On Mon, 18 Oct 2010, Nicolas Cellier wrote: >> >>> 2010/10/18 Igor Stasenko<siguctua(a)gmail.com>: >>>> On 18 October 2010 23:18, Nicolas Cellier >>>> <nicolas.cellier.aka.nice(a)gmail.com> wrote: >>>>> 2010/10/17 Levente Uzonyi<leves(a)elte.hu>: >>>>>> On Sat, 16 Oct 2010, Bart Veenstra wrote: >>>>>> >>>>>>> Hi list, >>>>>>> >>>>>>> I have been working with Pharo for almost a month now, and I suspect >>>>>>> that the performance is degrading fast. UI tasks takes several seconds >>>>>>> to react to my keyboard. >>>>>> That kind of sluggishness is probably related to finalization/gc. >>>>>> Please >>>>>> send us the result of the following expression: >>>>>> >>>>>> (WeakArray classPool at: #FinalizationDependents) >>>>>> select: [ :each | each notNil ] >>>>>> thenCollect: [ :each | each class -> each size ] >>>>>> >>>>> While updating pharo 1.2, after an EndOfCentralDirectory error, I got >>>>> a very unresponsive image... >>>>> >>>>> ((WeakArray classPool at: #FinalizationDependents) as: Array) >>>>> select: [ :each | each notNil ] >>>>> thenCollect: [ :each | each class -> each size] >>>>> -> >>>>> {(WeakIdentityKeyDictionary->22370). >>>> This is an MC cache. And major reason of image slowdown. >>>> >>> Levente did this simplification in trunk: >>> >>> cachedDefinitions >>> ^definitions ifNil: [ definitions := WeakIdentityKeyDictionary new >>> ] >>> >>> It would be worth a try in Pharo. >> IIRC Pharo's WeakKeyDictionary (and subclasses) don't work properly if >> they're not registered to the finalization process. So this won't work as >> long as that's not fixed. >> > Huh? Can you provide a code to show it? Test case please? > Just add lots of objects which will be GC'd to an unregistered WeakKeyDictionary. After X objects are gc'd, you'd still have X nil-keyed associations in the dictionary. Add Y objects, gc those, and you have X+Y nil-keys in the dict. (If dict grown/rehashed, all nicely placed index 1 onwards) Cheers, Henry

Oct. 18, 2010

Re: [Pharo-project] Stack should be reimplemented with Array

by Levente Uzonyi

On Mon, 18 Oct 2010, Igor Stasenko wrote: > Stephane, i could say more: > - i don't like how LinkedList implemented. > > I don't see why it should mimic things like #at: #at:put: at all.. It's not mimicing those methods. A list usually support things like this, but the user should know the consequences. > IMO this protocol should be pruned from it, to not provoke uses which > completely do not fit for given data structure. I'm not sure if it's okay to remove features, because users lacking really basic CS knowledge may use them the wrong way. > > Removing/inserting into the middle of list is quite ineffective > operation (O(n)), As long as you don't give away the link objects, it's O(n), otherwise it can be O(1). > while inserting at the begginning/end of list is O(1). > > Lists are sequenceable.. but sequenceable ~~ indexable. Period. Sequenceable is indexable, but good performance is not guaranteed. Levente > > -- > Best regards, > Igor Stasenko AKA sig. > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >

Oct. 18, 2010

Re: [Pharo-project] Speeding up Pharo 1.1

by Igor Stasenko

2010/10/19 Levente Uzonyi <leves(a)elte.hu>: > On Mon, 18 Oct 2010, Nicolas Cellier wrote: > >> 2010/10/18 Igor Stasenko <siguctua(a)gmail.com>: >>> >>> On 18 October 2010 23:18, Nicolas Cellier >>> <nicolas.cellier.aka.nice(a)gmail.com> wrote: >>>> >>>> 2010/10/17 Levente Uzonyi <leves(a)elte.hu>: >>>>> >>>>> On Sat, 16 Oct 2010, Bart Veenstra wrote: >>>>> >>>>>> Hi list, >>>>>> >>>>>> I have been working with Pharo for almost a month now, and I suspect >>>>>> that the performance is degrading fast. UI tasks takes several seconds >>>>>> to react to my keyboard. >>>>> >>>>> That kind of sluggishness is probably related to finalization/gc. >>>>> Please >>>>> send us the result of the following expression: >>>>> >>>>> (WeakArray classPool at: #FinalizationDependents) >>>>> Â Â Â Â select: [ :each | each notNil ] >>>>> Â Â Â Â thenCollect: [ :each | each class -> each size ] >>>>> >>>> >>>> While updating pharo 1.2, after an EndOfCentralDirectory error, I got >>>> a very unresponsive image... >>>> >>>> ((WeakArray classPool at: #FinalizationDependents) as: Array) >>>> Â Â Â select: [ :each | each notNil ] >>>> Â Â Â thenCollect: [ :each | each class -> each size] >>>> -> >>>> {(WeakIdentityKeyDictionary->22370). >>> >>> This is an MC cache. And major reason of image slowdown. >>> >> >> Levente did this simplification in trunk: >> >> cachedDefinitions >> Â Â Â Â ^definitions ifNil: [ definitions := WeakIdentityKeyDictionary new >> ] >> >> It would be worth a try in Pharo. > > IIRC Pharo's WeakKeyDictionary (and subclasses) don't work properly if > they're not registered to the finalization process. So this won't work as > long as that's not fixed. > Huh? Can you provide a code to show it? Test case please? > > Levente > >> >> Nicolas >> >>>> (WeakRegistry->0). >>>> (WeakRegistry->0). (WeakRegistry->0). (WeakRegistry->2)} >>>> >>>> I tried to inspect it 5 minutes ago, but hey, answer in another email... >>>> Ah, OK, cmd+shift+. just worked. I had to interrupt >>>> #finalizationProcess itself finally... >>>> Oh inspect is sorting the keys... unusable. >>>> So what's in the array ? Things like >>>> >>>> (ScriptLoader>>#update12125 "a CompiledMethod(0)")->a >>>> MCMethodDefinition(ScriptLoader>>update12125) >>>> (PragmaCollector>>#release "a CompiledMethod(964689920)")->a >>>> MCMethodDefinition(PragmaCollector>>release) >>>> (Float>>#arcSin "a CompiledMethod(358088704)")->a >>>> MCMethodDefinition(Float>>arcSin) >>>> >>>> I don't understand yet, but I begin to gather clues why updating pharo >>>> goes so badly... >>>> >>>> Nicolas >>>> >>>> _______________________________________________ >>>> Pharo-project mailing list >>>> Pharo-project(a)lists.gforge.inria.fr >>>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >>>> >>> >>> >>> >>> -- >>> Best regards, >>> Igor Stasenko AKA sig. >>> >>> _______________________________________________ >>> 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 > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > -- Best regards, Igor Stasenko AKA sig.

Oct. 18, 2010