Anonymous | Login | 04-13-2021 19:39 UTC |
Main | My View | View Issues | Change Log | Docs |
Viewing Issue Simple Details [ Jump to Notes ] | [ View Advanced ] [ Issue History ] [ Print ] | ||||||||
ID | Category | Severity | Reproducibility | Date Submitted | Last Update | ||||
0005309 | [Squeak] Multilingual | block | always | 10-27-06 07:44 | 05-26-08 18:38 | ||||
Reporter | wiz | View Status | public | ||||||
Assigned To | andreas | ||||||||
Priority | normal | Resolution | fixed | ||||||
Status | closed | Product Version | 3.9 | ||||||
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-. |
||||||||
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. |
||||||||
Attached Files |
![]() ![]() ![]() ![]() ![]() ![]() |
||||||||
|
![]() |
||||||||||||||||||||||||||
SYSTEM WARNING: Creating default object from empty value SYSTEM WARNING: Creating default object from empty value SYSTEM WARNING: Creating default object from empty value
|
![]() |
|
(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 |
Mantis 1.0.8[^]
Copyright © 2000 - 2007 Mantis Group
188 total queries executed. 91 unique queries executed. |