the problem now is that
allInstancesDo: aBlock
"Evaluate the argument, aBlock, for each of the current instances of
the
receiver.
Because aBlock might change the class of inst (for example, using
become:),
it is essential to compute next before aBlock value: inst."
| inst next |
self == UndefinedObject ifTrue: [^ aBlock value: nil].
inst := self someInstance.
[inst == nil]
whileFalse:
[
next := inst nextInstance.
aBlock value: inst.
inst := next]
is looping too.
Stef
On Aug 5, 2009, at 7:01 PM, Marcus Denker wrote:
>
> On 05.08.2009, at 12:42, Marcus Denker wrote:
>>>>
>>> Hmm, if that so, then we would expect to see an interpreter speed
>>> degradation. But its not. :)
>>
>> Yes, see the other mail. The reason is that the allocation of
>> contexts
>> in case of blocks happens now at #value, whereas it used to be just
>> done
>> at the definiton point (#blockCopy).
>>
>> So nothing to worry about.
>
>
> Eliot says:
>
> | So you can either
> | - wait for the stack VM or
> | - inline allInstancesDo: into allInstances or
> | - implement allInstacesDo: specially in ContextPart or
> | - implement a pair of primitives to answer allInstances and
> allObject atomically.
> |
> | This latter approach allows much more flexibility in implementing
> the garbage collector subsequently; for
> | example segmenting the heap and adding and freeing segments as
> required, which complicates the simple object
> | ordering provided by the single heap but has much better memory
> usage.
>
>
> I vote for inling for now... this fixes the problem.
>
> allInstances
> "Answer a collection of all current instances of the receiver."
>
> | all inst next |
> all := OrderedCollection new.
> inst := self someInstance.
> [inst == nil]
> whileFalse: [
> next := inst nextInstance.
> inst == all ifFalse: [all add: inst].
> inst := next].
> ^ all asArray
>
>
> Marcus
>
>
> --
> Marcus Denker - http://marcusdenker.de
> PLEIAD Lab - Computer Science Department (DCC) - University of Chile
>
>
> _______________________________________________
> Pharo-project mailing list
> [email protected]
> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________
Pharo-project mailing list
[email protected]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
