Hi Eliot,

The workaround is in the Trunk, so if you think that it may help, then 
please update your image (which creates the .spur versions), and recreate 
the .spur versions starting from at least Collections.spur-tfel.623 (or 
the .mcm which contains it).

Levente

On Tue, 5 May 2015, Levente Uzonyi wrote:

> It seems to me that the tool which creates the .spur versions of the packages 
> is running in an updated non-spur Trunk image, and it somehow added its own 
> version of #isAlphaNumeric to Collections.spur-tfel.623.
>
> The method in Collections.spur-tfel.623 is:
>
> 	isAlphaNumeric
> 		"Answer whether the receiver is a letter or a digit."
>
> 		self asInteger > 255 ifFalse: [ ^((ClassificationTable at: 
> self asInteger + 1) bitAnd: AlphaNumericMask) > 0 ].
> 		^self encodedCharSet isAlphaNumeric: self
>
> While in Collections-tfel.623 it is:
>
> 	isAlphaNumeric
> 		"Answer whether the receiver is a letter or a digit."
>
> 		^self encodedCharSet isAlphaNumeric: self
>
> The version which got patched is from Collections-ul.628 (which merges 
> Collections-ul.625):
>
> 	isAlphaNumeric
> 		"Answer whether the receiver is a letter or a digit."
>
> 		value > 255 ifFalse: [ ^((ClassificationTable at: value + 1) 
> bitAnd: AlphaNumericMask) > 0 ].
> 		^self encodedCharSet isAlphaNumeric: self
>
> If I'm right, then we can work around the problem by updating the current 
> methods in Trunk to check whether the AlphaNumericMask is initialized (along 
> with DigitBit and LetterMask). Then update the image which creates, the .spur 
> versions, and finally recreate the Collections.spur packages starting from 
> tfel-623.
>
> Levente
>
> On Mon, 4 May 2015, Eliot Miranda wrote:
>
>> 
>> 
>> On Mon, May 4, 2015 at 1:55 PM, Levente Uzonyi <leves at elte.hu> wrote:
>>       I tried to update an old Spur image, and somehow Character >> 
>> #isAlphaNumeric from Collections.spur-ul.628 (which should be loaded by
>>       update.spur-ul.311) appeared in the image, while loading 
>> Collections.spur-tfel.623 from update.spur-mt.310.
>>       Assuming that the load order of the packages is untouched, I suspect 
>> that the method got merged in from the non-spur branch of
>>       Collections somehow.
>> 
>> 
>> I think the multiple ancestry that one ends up with in Spur packages, e.g. 
>> that Collections.spur-abc.123 inherits from
>> both Collections.spur-xyz-122 and Collections.abc-123, causes issues for 
>> the update merge.  I wonder whether that could be the cause?