|
Mantis - Squeak
|
|
Viewing Issue Advanced Details |
|
|
ID:
|
Category:
|
Severity:
|
Reproducibility:
|
Date Submitted:
|
Last Update:
|
|
5309 |
Multilingual |
block |
always |
10-27-06 07:44 |
05-26-08 18:38 |
|
|
Reporter:
|
wiz |
Platform:
|
|
|
|
Assigned To:
|
andreas |
OS:
|
|
|
|
Priority:
|
normal |
OS Version:
|
|
|
|
Status:
|
closed |
Product Version:
|
3.9 |
|
|
Product Build:
|
|
Resolution:
|
fixed |
|
|
Projection:
|
none |
|
|
|
|
ETA:
|
none |
Fixed in Version:
|
3.10 |
|
|
|
Summary:
|
0005309: [Bug][Fix] Under certain conditions returning from a MVC project will hang indefinitely. |
|
Description:
|
The symptom is reported here:
http://lists.squeakfoundation.org/pipermail/beginners/2006-October/001291.html [^]
"...If you go to the
preference browser, and set the general >> tinyDisplay setting to
enabled, and after that if you create a new MVC project, enter it and
leave it to go back to the main project, the result is that the VM will
freeze."
This can be interupted by Cmd-.
|
|
Steps To Reproduce:
|
|
|
Additional Information:
|
The problem is word confusion in a text method.
TextStyle defaultFont fontArray gets a DNU
TextStyle default fontArray is what is needed.
Fix and a TestClass Uploaded.
There is probably a secondry problem in the error handling. Reporting the error is dependant on finding a font which is dependant on this error not being there in the first place. |
| Relationships | SYSTEM WARNING: Creating default object from empty value
SYSTEM WARNING: Creating default object from empty value
SYSTEM WARNING: Creating default object from empty value
| parent of | 0005451 | closed | | MessageNotUnderstood error on entering Morphic Project | | related to | 0006444 | new | | Browser hangs when accepting a new class | | related to | 0007044 | assigned | MAD | MNU StrikeFont>>fontArray when exiting Morphic project with Accujen as default font | | related to | 0007035 | closed | edgardec | Fix system version for 3.10.1 | | child of | 0006570 | assigned | tim | A Mother for font and font test problems |
|
|
Attached Files:
|
 LanguageEnviro...ntAvailable.st [^] (326 bytes) 10-27-06 07:45
LangEnvBugs.st [^] (491 bytes) 10-27-06 07:48
LangEnvBugs-wiz.2.st [^] (675 bytes) 10-28-06 08:50
LanguageEnv...ntAvailable-ar.st [^] (410 bytes) 07-23-07 20:08
1204fontAvailable-yo.1.cs [^] (895 bytes) 07-23-07 20:44
fontAvailable-1204yo-wiz.1.cs [^] (1,068 bytes) 09-08-07 04:27 |
|
Notes |
|
|
(0007910)
|
|
wiz
|
|
10-27-06 07:54
|
|
|
Reminder sent to: tak
Hi tak.
Your intials were on the method with the bug.
Could you please look at this and verify it is the right fix for the bug? I'm not an expert on the font stuff and I just did the first thing that looked like it should work.
Also I suspect this effects squeakland's 3.8 as well as 3.9.
|
|
|
|
(0007923)
|
|
wiz
|
|
10-28-06 08:59
|
|
Ah the dangers of a hasty report.
The first bug fix did not set up the #tinyDisplay preference. So in the absence of the patch it would fail it #tinyDisplay had been set but it would pass in a fresh image.
The second attempt LangEnvBugs-wiz.2.st adds the preference setting to the bug test. So it will properly fail in a fresh image unless the patch is installed.
[OT] and worthy of its own report. The second bug test, simple as it is takes 3.5 to 4.5 seconds to run. I find this very very odd.
Subsequent investigation has shown that toggling the tinyDisplay preference is responsible for 1.5-2.5 sec in each direction. It sets off a flurry of activity.
|
|
|
|
(0008326)
|
|
wiz
|
|
11-19-06 07:16
|
|
|
|
|
(0010601)
|
|
wiz
|
|
04-22-07 22:50
|
|
In the child report, Edgar claims he fixed this in as:
7092TTCFontDNUfix.cs
|
|
|
|
(0010913)
|
|
andreas
|
|
07-22-07 21:51
|
|
Reopened; the fix is just plain wrong. The problem isn't "word confusion" the problem is that #isFontAvailable expects a StrikeFontSet (which indeed has a fontArray) and therefore the correct way to fix it is via, e.g.,
isFontAvailable
| encoding font |
encoding := self leadingChar + 1.
font := TextStyle defaultFont.
(font isKindOf: StrikeFontSet)
ifTrue:[font fontArray at: encoding ifAbsent: [^ false]]
ifFalse:[^false].
^ true |
|
|
|
(0010921)
|
|
wiz
|
|
07-23-07 20:16
|
|
LanguageEnv...ntAvailable-ar.st which is the goodie Andreas suggested in the previous note.
I went back and looked at the tak code that I attempted to fix. It was just as incorrect (actually more so because it did not pass the test).
So the question is with that kind of misunderstanding in heavily touched code, will Andreas's "correct" code work with everything that was written to work around the old broken code?
And how do we find out.
Someone with more sway than me (note tak never answered the reminder sent to him) should ask the other parties to add their thoughts and comments to this.
Yours in curiosity and service, --Jerome Peace |
|
|
|
(0010923)
|
|
wiz
|
|
07-23-07 20:50
|
|
Uploaded 1204fontAvailable-yo.1.cs which is a fileout from a fresh current OPLC image.
This addresses the exact same problem.
I have not tested it or tried it yet in the 3.10 image. Looking at it, it resembles andreas's solution.
Now how do we decide on a solution? |
|
|
|
(0010925)
|
|
tak
|
|
07-23-07 21:31
|
|
I'm sorry to miss your reminder.
1204fontAvailable-yo.1.cs covers all of cases.
At least it is working six months in OLPC image. FontSet mechanism is
too complected for me... |
|
|
|
(0010926)
|
|
andreas
|
|
07-23-07 21:55
|
|
Hm ... looking at 1204 it seems that this fix has similar issues to the one before. Its first part is fine but the latter part isn't:
encoding = 1 ifTrue: [^ true].
f fallbackFont fontArray
at: encoding
ifAbsent: [^ false].
^ true
Again, there is the same implicit assumption that "f fallbackFont" must be a font set which is not generally true. As a matter of fact it isn't even true for the *default* fallback font (a FixedFaceFont) so it would explode right away with any newly installed font. So it needs a guard along the lines of:
f fallbackFont isFontSet ifFalse:[^false].
before testing for the encoding. |
|
|
|
(0010927)
|
|
tak
|
|
07-23-07 22:22
|
|
I understood.
I told Yoshiki about this URL. Perhaps he has a comment. |
|
|
|
(0011098)
|
|
wiz
|
|
09-08-07 03:51
|
|
|
Note there is now a problem with saving and then reading in a text morph if the text starts out as BitStream Vera sans. |
|
|
|
(0011099)
|
|
wiz
|
|
09-08-07 04:31
|
|
fontAvailable-1204yo-wiz.1.cs uploaded.
This is the previous cs with Andreas's guard added.
It should pass the current tests and it passed (manually) my save textmorph as morph read it back in test.
I am still aiming to make an sunit for that last manual part, but not tonite.
Yours in service and curiosity, --Jerome Peace |
|
|
|
(0011258)
|
|
RalphJohnson
|
|
10-08-07 14:57
|
|
What is a "leadingChar"? There are dozens of methods with this name, and none of them have comments. There is no particular reason to think they all mean the same thing, so perhaps what I really should say is "what is leadingChar in a LanguageEnvironment"?
In class Character, there is a class method
leadingChar: leadChar code: code
code >= 16r400000 ifTrue: [
self error: 'code is out of range'.
].
leadChar >= 256 ifTrue: [
self error: 'lead is out of range'.
].
^self value: (leadChar bitShift: 22) + code.
This indictates that leadingChar is something like a high-order byte of the unicode value. This value must be 30 bits, and the leadingChar is the high order 8 bits.
This has nothing to do with the fontArray stored in a font. I thought that was just different sizes of a font. Why should it make sense to index the fontArray with an "encoding", which is just the leadingChar + 1? |
|
|
|
(0011280)
|
|
wiz
|
|
10-10-07 03:30
|
|
Hi Ralph,
I have no idea what 'leadingChar' is but it is being used consistently to access a font or glyph index in ttc fonts.
The author of all the methods that it is defined in is Yoshiki Ohshima.
The plus one means it is a zero based index being translated to squeak one based indexing.
You ought to lean on Yoshiki to provide a bit of documentation and a glossary for ttc font stuff.
|
|
|
|
(0011333)
|
|
korakurider
|
|
10-16-07 07:02
|
|
|
|
|
(0011339)
|
|
wiz
|
|
10-16-07 21:37
|
|
Ha,
Thank you korakurider, very useful documentation.
So leading character is the first 8 bits of the value of a multichar (after the sign) which represent the encoding tag for various language sets. Some sets have dual interpretations for backward compatibility. The english/latin-1 ISO-8859-1 set has a tag of 0 for backward compatibility with character value.
Cool |
|
|
|
(0011452)
|
|
wiz
|
|
11-23-07 19:22
|
|
|
Reminder sent to: edgardec
Hi Edgar sq 7154 is failing the isFontAvailableTest because isFontAvailable in sq7154 is broken. (I broke it.) The last patch here is a good a one as I know, based on yo's work and andreas's advice. So try that one and see how it fares.
Yours in curiosity and service, --Jer |
|
|
|
(0012113)
|
|
KenCausey
|
|
05-18-08 19:42
|
|
|
Uhm. This one is rather confusing but I'm going to be proactive and assume that we can consider this resolved as of update 7164. Please correct me if I am wrong. |
|
|
|
(0012118)
|
|
KenCausey
|
|
05-18-08 20:28
|
|
|
I should clarify that update 7164 is fontAvailable-1204yo-wiz.1.cs of 9/8/07 |
|
|
|
(0012119)
|
|
edgardec
|
|
05-18-08 20:59
|
|
|
Reminder sent to: wiz
I suppose no , as going back to .cs policy any could have all the info with ChangeSorter in the image.
I wish hear Jerome feedback |
|
|
|
(0012179)
|
|
KenCausey
|
|
05-26-08 18:38
|
|
|