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
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.
Cheers, - Andreas
On 1/8/2011 11:47 AM, Bernhard Pieber wrote:
Dear Squeakers,
I did the following:
- I opened the latest trunk image Squeak4.2-10779-alpha.image with the Mac OS X VM Squeak 5.8b12.
- Update Squeak.
- 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.
- Bernhard
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:
- Check your recent changes if anything got logged. A fileIn from loading a project file or so should be logged.
- 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:
- I opened the latest trunk image Squeak4.2-10779-alpha.image with the Mac OS X VM Squeak 5.8b12.
- Update Squeak.
- 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.
Cheers, Bernhard
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:
- Check your recent changes if anything got logged. A fileIn from loading a project file or so should be logged.
- 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:
- I opened the latest trunk image Squeak4.2-10779-alpha.image with the Mac OS X VM Squeak 5.8b12.
- Update Squeak.
- 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.
I have the same issue, and the file has mysteriously appeared in my image directory. Usually you can Shift+Command+e to see references to substrings in the code, but doing that for FontJapaneseEnvironment.sar does not produce any results. Strange indeed..!
On Sat, Jan 8, 2011 at 8:56 AM, Bernhard Pieber bernhard@pieber.com wrote:
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:
- Check your recent changes if anything got logged. A fileIn from loading a project file or so should be logged.
- 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:
- I opened the latest trunk image Squeak4.2-10779-alpha.image with the Mac OS X VM Squeak 5.8b12.
- Update Squeak.
- 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.
Ah, copyright notices. Got it, thx.
On Sat, Jan 8, 2011 at 5:23 PM, Andreas Wacknitz A.Wacknitz@gmx.de wrote:
Am 08.01.11 23:37, schrieb Chris Muller:
I have the same issue, and the file has mysteriously appeared in my image directory. Usually you can Shift+Command+e to see references to
Regarding Shift+Command+e: you should try searching for 2010 with it :D
Regards, Andreas
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.
- Bert -
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.
frank
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
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?
It would be nice not to have the debugger appear in a new 4.2 release from running tests, and also a concern if there would be a problem with the Japanese Locale, of course.
Thanks, Chris
On Mon, Jan 10, 2011 at 8:45 AM, Levente Uzonyi leves@elte.hu wrote:
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....
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....
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
2011/1/31 Levente Uzonyi leves@elte.hu:
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....
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
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 ?
- restore of exact structure (at time of dump) in temporary classes
- mutation to current class sturcture (with ClassBuilder help)
Nicolas
OK, I just browsed it: StrikeFontSet are using ReferenceStream. Didn't SmartRefStream were created for addressing this very problem ?
Nicolas
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.
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
The change was reverted right? What was it, the 20th instVar was put back?
If I were in control of the file, I would redo the file and export it as a SmartRefStream. Alas, I have no idea even where it's being downloaded from; senders lead nowhere. This is some real "magic" going on in LocaleTestCase, kicking off a background load??
On Wed, Feb 2, 2011 at 7:07 PM, Levente Uzonyi leves@elte.hu wrote:
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
On Wed, 2 Feb 2011, Chris Muller wrote:
The change was reverted right? What was it, the 20th instVar was put back?
No, it's not reverted. And yes, the 20th instance variable, charIndex is "missing".
If I were in control of the file, I would redo the file and export it as a SmartRefStream. Alas, I have no idea even where it's being downloaded from; senders lead nowhere. This is some real "magic" going on in LocaleTestCase, kicking off a background load??
It's not magic. LanguageEnvironment >> #fontDownloadUrls contains the url which is http://metatoys.org/pub/ . We can change it to point to http://ftp.squeak.org if it's necessary. Something like http://ftp.squeak.org/4.2/fonts/ or a variant based on SystemVersion is fine IMHO.
Levente
On Wed, Feb 2, 2011 at 7:07 PM, Levente Uzonyi leves@elte.hu wrote:
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
It's not magic. LanguageEnvironment >> #fontDownloadUrls contains the url
Things that subvert the ability to trace the code statically are what I refer to as "magic".
In this case, the problem is completely opaque from the debugger (see original stack-trace from Bernhard at the top of this thread). You just see #installExternalFontOn:encoding:encodingName:textStyleName: at the top (bottom?) of the stack and no one sends it.
Now after three days I finally came across it in the SAR's preamble. But sheesh, I wonder why is it necessary to fork that? We should either not fork or at least tag it as <magic: 'called from from the SAR preamble'>.
- Chris
On Wed, 2 Feb 2011, Chris Muller wrote:
The change was reverted right? What was it, the 20th instVar was put back?
If I were in control of the file, I would redo the file and export it as a SmartRefStream. Alas, I have no idea even where it's being downloaded from; senders lead nowhere. This is some real "magic" going on in LocaleTestCase, kicking off a background load??
We should fix this issue ASAP. IMHO we should do the following: - "freeze" the trunk one more time - push a fix to the trunk which adds the missing instance variable - create a new release candidate from the trunk (the release must be in sync with the trunk) - reopen the trunk - the squeak42 repository's mcm should be replaced with a new version
Levente
On Wed, Feb 2, 2011 at 7:07 PM, Levente Uzonyi leves@elte.hu wrote:
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
squeak-dev@lists.squeakfoundation.org
-
Andreas Raab -
Andreas Wacknitz -
Bernhard Pieber -
Bert Freudenberg -
Chris Muller -
Frank Shearar -
Levente Uzonyi -
Nicolas Cellier