Well, since SequenceableCollection overwrites #do: breaking its superclass' 
contract, it should also overwrite #size as subclassResponsibility - at least. 
That would break the loop, no ?

The discussion about catching infinite recursion loops is old and comes up 
every couple of weeks. It should be fixed, it can be fixed IMHO, but it is a VM 
thing.

On 16 Sep 2014, at 08:39, Max Leske <[email protected]> wrote:

> So first: as Sven said Sequenceable collection is abstract.
> Still I would consider what you found a bug since it provides the 
> implementations that produce the behavior you reported.
> 
> I can reproduce it in a 40 with vmLatest, and the proble occurs whenever 
> either #do: or #size is sent.
> 
> SequenceableCollection>>do: aBlock
>       "Refer to the comment in Collection|do:.” 
>        1 to: self size do: [:index | aBlock value: (self at: index)]
> 
> 
> Collection>>size
>       size "Answer how many elements the receiver contains.” 
> 
>        | tally | 
>        tally := 0. 
>        self do: [:each | tally := tally + 1]. 
>        ^ tally
> 
> 
> As you can see, calling either method will produce an infinite loop which 
> eventually crashes the VM.
> 
> I couldn’t find an open bug entry so I’ve created one: 
> https://pharo.fogbugz.com/f/cases/14022/Infinite-loop-in-simple-subclasses-of-SequenceableCollection
> 
> Cheers,
> Max
> 
> On 15.09.2014, at 23:12, [email protected] wrote:
> 
>> Hi,
>> 
>> A student of mine has accidentaly found something interesting that may be 
>> already reported, but I do not have time to check.
>> 
>> The thing is simple:
>> 
>> 1) Create a class with accessors for f.
>> 
>> SequenceableCollection subclass: #Foo
>>     instanceVariableNames: 'f'
>>     classVariableNames: ''
>>     category: 'Varios'
>> 
>> 2) Foo class >> new: d 
>>     ^self new f: (Array new: d*d)
>> 
>> 3) Go to Workspace and inspect the following code
>> 
>>        | m |
>>         m := Foo new: 2
>> 
>> And Pharo crashes. Always crashes. I am using "Pharo 3.0 3" on OS X 10.6.8. 
>> I am pretty sure it is not a Smalltalk error since it works ok in Squeak and 
>> VisualWorks.
>> 
>> So, is this a known issue?
>> 
>> Bests,
>> 
>> Jordi
>> 
>> 
> 


Reply via email to