Error: Instances of StrikeFont are not indexable

> Dear Squeakers,
>
> I did the following:
> 1. I opened the latest trunk image Squeak4.2-10779-alpha.image with the Mac OS X VM Squeak 5.8b12.
> 2. Update Squeak.
> 3. Run all tests. After all the tests I get a debugger with "Error: Instances of StrikeFont are not indexable"
>
> --- The full stack ---
> StrikeFont(Object)>>error:
> StrikeFont(Object)>>errorNotIndexable
> StrikeFont(Object)>>size
> StrikeFont(Object)>>basicAt:put:
> StrikeFont(Object)>>instVarAt:put:
> StrikeFont(Object)>>readDataFrom:size:
> ReferenceStream(DataStream)>>readInstance
> ReferenceStream(DataStream)>>next
> ReferenceStream>>next
> ReferenceStream(DataStream)>>readArray
> ReferenceStream(DataStream)>>next
> ReferenceStream>>next
> [] in StrikeFontSet class>>installExternalFontOn:encoding:encodingName:textStyleName:
> [] in [] in MultiByteBinaryOrTextStream(PositionableStream)>>untilEndWithFork:displayingProgress:
> BlockClosure>>ensure:
> [] in MultiByteBinaryOrTextStream(PositionableStream)>>untilEndWithFork:displayingProgress:
> [] in BlockClosure>>newProcess
>
> Is there a way find out where this process is created? Tracing senders of StrikeFontSet class>>installExternalFontOn:encoding:encodingName:textStyleName: leads ultimately to no senders. In a Process Browser I do not see anything unusual.
>
> Cheers,
> Bernhard
>

> Hi Andreas,
>
> Thanks for the tips. Inserting self halt shows that it is called from the preamble of FontJapaneseEnvironment.sar by the SARInstaller. Where that is called from I have yet to figure out. Strangely my image hung after proceeding from the halt. Alt+. does not work.
>
> Am 08.01.2011 um 12:02 schrieb Andreas Raab:
>> This might be the result of a fileIn (possibly one of the LanguageEnvironment tests). You can try two things:
>> 1) Check your recent changes if anything got logged. A fileIn from loading a project file or so should be logged.
>> 2) Insert a "self halt" into the method (before the fork) to see where it comes from.
>> On 1/8/2011 11:47 AM, Bernhard Pieber wrote:
>>> I did the following:
>>> 1. I opened the latest trunk image Squeak4.2-10779-alpha.image with the Mac OS X VM Squeak 5.8b12.
>>> 2. Update Squeak.
>>> 3. Run all tests. After all the tests I get a debugger with "Error: Instances of StrikeFont are not indexable"
>>>
> snip
>>> Is there a way find out where this process is created? Tracing senders of StrikeFontSet class>>installExternalFontOn:encoding:encodingName:textStyleName: leads ultimately to no senders. In a Process Browser I do not see anything unusual.

> It is the LocaleTest. When I run it all the tests are green but the debugger appears. I have a FontJapaneseEnvironment.sar in the folder where my image resides. I have no idea where I got that from. When I remove it and run the LocaleTest the debugger does not appear.
>
> Cheers,
> - Bernhard
>
> Am 08.01.2011 um 15:27 schrieb Bernhard Pieber:
>> Hi Andreas,
>>
>> Thanks for the tips. Inserting self halt shows that it is called from the preamble of FontJapaneseEnvironment.sar by the SARInstaller. Where that is called from I have yet to figure out. Strangely my image hung after proceeding from the halt. Alt+. does not work.
>>
>> Am 08.01.2011 um 12:02 schrieb Andreas Raab:
>>> This might be the result of a fileIn (possibly one of the LanguageEnvironment tests). You can try two things:
>>> 1) Check your recent changes if anything got logged. A fileIn from loading a project file or so should be logged.
>>> 2) Insert a "self halt" into the method (before the fork) to see where it comes from.
>>> On 1/8/2011 11:47 AM, Bernhard Pieber wrote:
>>>> I did the following:
>>>> 1. I opened the latest trunk image Squeak4.2-10779-alpha.image with the Mac OS X VM Squeak 5.8b12.
>>>> 2. Update Squeak.
>>>> 3. Run all tests. After all the tests I get a debugger with "Error: Instances of StrikeFont are not indexable"
>>>>
>> snip
>>>> Is there a way find out where this process is created? Tracing senders of StrikeFontSet class>>installExternalFontOn:encoding:encodingName:textStyleName: leads ultimately to no senders. In a Process Browser I do not see anything unusual.
>
>
>

> On 2011/01/10 11:18, Bert Freudenberg wrote:
>> On 08.01.2011, at 15:56, Bernhard Pieber wrote:
>>
>>> I have a FontJapaneseEnvironment.sar in the folder where my image resides.
>>> I have no idea where I got that from.
>>
>> Fonts are downloaded automatically when you switch to a locale that
>> requires it. You must have tried switching to Japanese at some point.
>
> That would have been part of the tests, yes? Certainly I didn't deliberately
> change locale, and ran into the same problem.

> On Mon, 10 Jan 2011, Frank Shearar wrote:
>
>> On 2011/01/10 11:18, Bert Freudenberg wrote:
>>>
>>> On 08.01.2011, at 15:56, Bernhard Pieber wrote:
>>>
>>>> I have a FontJapaneseEnvironment.sar in the folder where my image
>>>> resides. I have no idea where I got that from.
>>>
>>> Fonts are downloaded automatically when you switch to a locale that
>>> requires it. You must have tried switching to Japanese at some point.
>>
>> That would have been part of the tests, yes? Certainly I didn't
>> deliberately change locale, and ran into the same problem.
>
> I guess LocaleTest does that.
>
>
> Levente
>
>>
>> frank
>>
>>
>
>

> On Sun, 30 Jan 2011, Chris Muller wrote:
>
>> Does anyone know how to fix this?  The suspect we have at this point
>> is LocaleTest>>#testLocaleChanged, which loads a Japanese file from...
>> somewhere which I can't tell, except there seems to be a problem with
>> the ReferenceStream that causes it to try to, when constructing a
>> StrikeFont, try to set beyond its 19th instance-variable..
>>
>> Perhaps the class-structure changed, and/or the 'ja' file needs updating?
>
> StrikeFont changed. Nicolas removed the 20th variable (charIndex), because it
> was unused. See
> http://lists.squeakfoundation.org/pipermail/squeak-dev/2010-December/156220.html
>
>

> On Mon, 31 Jan 2011, Levente Uzonyi wrote:
>
>> On Sun, 30 Jan 2011, Chris Muller wrote:
>>
>>> Does anyone know how to fix this?  The suspect we have at this point
>>> is LocaleTest>>#testLocaleChanged, which loads a Japanese file from...
>>> somewhere which I can't tell, except there seems to be a problem with
>>> the ReferenceStream that causes it to try to, when constructing a
>>> StrikeFont, try to set beyond its 19th instance-variable..
>>>
>>> Perhaps the class-structure changed, and/or the 'ja' file needs updating?
>>
>> StrikeFont changed. Nicolas removed the 20th variable (charIndex), because
>> it was unused. See
>> http://lists.squeakfoundation.org/pipermail/squeak-dev/2010-December/156220.html
>>
>>
>
> I uploaded Tests-ul.114 which fixes LocaleTest >> #testIsFontAvailable.
> Since it was an expected failure it wasn't easy to find out that it got
> totally broken.
> To make the test pass you have to add the charIndex variable back to
> StrikeFont, otherwise the sar file won't load.
> The other option is to fix the sar file...
>
>
> Levente
>
>

>
> I would say take the shortest path for a quick 4.2 release : revert the change.
> Then, we'll have time to think about how to deal with those obsolete
> binary dumps in 4.3.
> Shouldn't a binary dump be restored in two pass ?
> 1) restore of exact structure (at time of dump) in temporary classes
> 2) mutation to current class sturcture (with ClassBuilder help)
>
> Nicolas
>

> On Mon, 31 Jan 2011, Chris Muller wrote:
>
>>> OK, I just browsed it: StrikeFontSet are using ReferenceStream.
>>> Didn't SmartRefStream were created for addressing this very problem ?
>>
>> That's my understanding.  But if the file was originally written as a
>> ReferenceStream, I think it will have to be re-written using a
>> SmartRefStream.
>>
>>
>
> Will the file be updated or the change in the image reverted to solve this
> problem?
>
>
> Levente
>
>