0005309: [Bug][Fix] Under certain conditions returning from a MVC project will hang indefinitely.

(0007910 - 302 - 355 - 355 - 355 - 355 - 355)
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 - 672 - 732 - 732 - 732 - 732 - 732)
wiz
10-28-06 08:59
edited on: 10-30-06 08:25

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 - 14 - 14 - 14 - 119 - 119 - 119)
wiz
11-19-06 07:16

See also 0005451

(0010601 - 80 - 104 - 104 - 104 - 104 - 104)
wiz
04-22-07 22:50
edited on: 09-08-07 03:50

In the child report, Edgar claims he fixed this in as:

7092TTCFontDNUfix.cs

(0010913 - 459 - 613 - 613 - 613 - 613 - 613)
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 - 660 - 730 - 730 - 730 - 730 - 730)
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 - 273 - 303 - 303 - 303 - 303 - 303)
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 - 181 - 211 - 211 - 211 - 211 - 211)
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 - 648 - 830 - 830 - 830 - 830 - 830)
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 - 71 - 77 - 77 - 77 - 77 - 77)
tak
07-23-07 22:22

I understood.
I told Yoshiki about this URL. Perhaps he has a comment.

(0011098 - 119 - 119 - 119 - 119 - 119 - 119)
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 - 336 - 384 - 384 - 384 - 384 - 384)
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 - 925 - 1264 - 1264 - 1264 - 1264 - 1264)
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 - 402 - 462 - 462 - 462 - 462 - 462)
wiz
10-10-07 03:30
edited on: 10-10-07 17:18

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 - 270 - 298 - 474 - 474 - 474 - 474)
korakurider
10-16-07 07:02

About concept of leadingchar, see Yoshiki's paper on squeak m17n:
http://www.is.titech.ac.jp/~ohshima/squeak/m17npaper/index.html [^]

This is a bit outdated, but is still good description about design of squeak m17n. LeadingChar is same as "encoding tag" in that paper.

(0011339 - 377 - 413 - 413 - 413 - 413 - 413)
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 - 277 - 289 - 289 - 289 - 289 - 289)
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 - 163 - 163 - 163 - 163 - 163 - 163)
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 - 76 - 76 - 76 - 76 - 76 - 76)
KenCausey
05-18-08 20:28

I should clarify that update 7164 is fontAvailable-1204yo-wiz.1.cs of 9/8/07

(0012119 - 131 - 137 - 137 - 137 - 137 - 137)
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 - 15 - 15 - 15 - 15 - 15 - 15)
KenCausey
05-26-08 18:38

Fixed in 3.10.1

Issue History
Date Modified	Username	Field	Change
10-27-06 07:44	wiz	New Issue
10-27-06 07:45	wiz	File Added: LanguageEnviro...ntAvailable.st
10-27-06 07:48	wiz	File Added: LangEnvBugs.st
10-27-06 07:54	wiz	Issue Monitored: tak
10-27-06 07:54	wiz	Note Added: 0007910
10-28-06 08:50	wiz	File Added: LangEnvBugs-wiz.2.st
10-28-06 08:59	wiz	Note Added: 0007923
10-30-06 08:25	wiz	Note Edited: 0007923
11-19-06 07:16	wiz	Note Added: 0008326
04-03-07 05:45	wiz	Relationship added	parent of 0005451
04-22-07 22:50	wiz	Note Added: 0010601
04-22-07 22:50	wiz	Status	new => resolved
04-22-07 22:50	wiz	Resolution	open => fixed
04-22-07 22:50	wiz	Fixed in Version	=> 3.10
07-22-07 21:51	andreas	Status	resolved => new
07-22-07 21:51	andreas	Resolution	fixed => open
07-22-07 21:51	andreas	Assigned To	=> andreas
07-22-07 21:51	andreas	Note Added: 0010913
07-22-07 22:08	andreas	Status	new => assigned
07-22-07 22:08	andreas	Resolution	open => reopened
07-23-07 02:35	wiz	Relationship added	child of 0006570
07-23-07 20:08	wiz	File Added: LanguageEnv...ntAvailable-ar.st
07-23-07 20:16	wiz	Note Added: 0010921
07-23-07 20:44	wiz	File Added: 1204fontAvailable-yo.1.cs
07-23-07 20:50	wiz	Note Added: 0010923
07-23-07 21:31	tak	Note Added: 0010925
07-23-07 21:55	andreas	Note Added: 0010926
07-23-07 22:02	tak	Issue End Monitor: tak
07-23-07 22:02	tak	Issue Monitored: tak
07-23-07 22:22	tak	Note Added: 0010927
09-08-07 03:50	wiz	Note Edited: 0010601
09-08-07 03:51	wiz	Note Added: 0011098
09-08-07 04:27	wiz	File Added: fontAvailable-1204yo-wiz.1.cs
09-08-07 04:31	wiz	Note Added: 0011099
10-08-07 14:42	RalphJohnson	Note Added: 0011257
10-08-07 14:43	RalphJohnson	Note Deleted: 0011257
10-08-07 14:57	RalphJohnson	Note Added: 0011258
10-09-07 02:25	matthewf	Relationship added	related to 0006444
10-10-07 03:30	wiz	Note Added: 0011280
10-10-07 17:18	wiz	Note Edited: 0011280
10-16-07 07:02	korakurider	Note Added: 0011333
10-16-07 21:37	wiz	Note Added: 0011339
11-23-07 19:22	wiz	Issue Monitored: edgardec
11-23-07 19:22	wiz	Note Added: 0011452
05-15-08 05:11	wiz	Relationship added	related to 0007044
05-18-08 19:42	KenCausey	Status	assigned => resolved
05-18-08 19:42	KenCausey	Resolution	reopened => fixed
05-18-08 19:42	KenCausey	Note Added: 0012113
05-18-08 20:28	KenCausey	Note Added: 0012118
05-18-08 20:59	edgardec	Note Added: 0012119
05-20-08 22:47	KenCausey	Relationship added	related to 0007035
05-26-08 18:38	KenCausey	Status	resolved => closed
05-26-08 18:38	KenCausey	Note Added: 0012179

Notes
(0007910 - 302 - 355 - 355 - 355 - 355 - 355) 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 - 672 - 732 - 732 - 732 - 732 - 732) wiz 10-28-06 08:59 edited on: 10-30-06 08:25	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 - 14 - 14 - 14 - 119 - 119 - 119) wiz 11-19-06 07:16	See also 0005451

(0010601 - 80 - 104 - 104 - 104 - 104 - 104) wiz 04-22-07 22:50 edited on: 09-08-07 03:50	In the child report, Edgar claims he fixed this in as: 7092TTCFontDNUfix.cs

(0010913 - 459 - 613 - 613 - 613 - 613 - 613) 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 - 660 - 730 - 730 - 730 - 730 - 730) 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 - 273 - 303 - 303 - 303 - 303 - 303) 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 - 181 - 211 - 211 - 211 - 211 - 211) 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 - 648 - 830 - 830 - 830 - 830 - 830) 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 - 71 - 77 - 77 - 77 - 77 - 77) tak 07-23-07 22:22	I understood. I told Yoshiki about this URL. Perhaps he has a comment.

(0011098 - 119 - 119 - 119 - 119 - 119 - 119) 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 - 336 - 384 - 384 - 384 - 384 - 384) 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 - 925 - 1264 - 1264 - 1264 - 1264 - 1264) 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 - 402 - 462 - 462 - 462 - 462 - 462) wiz 10-10-07 03:30 edited on: 10-10-07 17:18	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 - 270 - 298 - 474 - 474 - 474 - 474) korakurider 10-16-07 07:02	About concept of leadingchar, see Yoshiki's paper on squeak m17n: http://www.is.titech.ac.jp/~ohshima/squeak/m17npaper/index.html [^] This is a bit outdated, but is still good description about design of squeak m17n. LeadingChar is same as "encoding tag" in that paper.

(0011339 - 377 - 413 - 413 - 413 - 413 - 413) 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 - 277 - 289 - 289 - 289 - 289 - 289) 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 - 163 - 163 - 163 - 163 - 163 - 163) 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 - 76 - 76 - 76 - 76 - 76 - 76) KenCausey 05-18-08 20:28	I should clarify that update 7164 is fontAvailable-1204yo-wiz.1.cs of 9/8/07

(0012119 - 131 - 137 - 137 - 137 - 137 - 137) 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 - 15 - 15 - 15 - 15 - 15 - 15) KenCausey 05-26-08 18:38	Fixed in 3.10.1