Mantis - Squeak
Viewing Issue Advanced Details
2271 Morphic minor always 11-28-05 15:08 01-14-06 00:34
closed 3.9  
none 3.9  
0002271: [BUG] [FIX] Changing system font in 3.9
I refile the missing methods, as Paul confirmed what this fix solve the problem
Hi, all,

I noticed that since image 6703 it is not possible to change the default
text font without an error and the disappearance of the TOOLS flap.

Just try it:

standard system fonts
default text font
change to the same as it was (!)
some seconds later there is a walkback.

Any ideas?


Paul Provoost
The Netherlands
has duplicate 0002272closed  [BUG]SyntaxErrorNotification class(Object)>>doesNotUnderstand: #inClass:withCode:doitFlag: 
 SyntaxErrormissingMethods.1.cs [^] (736 bytes) 11-28-05 15:08
 ParserAtInReferenceFix-klc.1.cs.gz [^] (437 bytes) 11-29-05 01:11

11-29-05 00:29   
Good job Edgar, this does indeed appear to fix the problem. It does this by adding 2 simple missing methods. However I wonder if maybe this shouldn't have been fixed by instead changing the reference. Especially if there is only one place referencing this.

In the future please always gzip (compress) your .cs files before uploading them. Unfortunately the .cs extension is also used by C# and on some platforms I fear that the line ending format may be changed if it decides to treat these as ASCII text files.

Note this also resolves 0002272 which is the same issue.
11-29-05 00:52   
OK, I'm not so certain that this is a good fix after I examine it more closely.

First of all the instance method #setClass:code:debugger:doitFlag: added here refers to a non-existence instance variable called #debugger and does not update the definition to add it.

It looks like this has been refactored to use ToolSet to pick the debugger rather than it be specified. This let's it be switched out much more easily.

I'll attach my own suggested fix for this in a few minutes.
11-29-05 01:12   
Please note that ParserAtInReferenceFix-klc.1.cs.gz is my preferred fix over the previous SyntaxErrormissingMethods.1.cs. The problem was a missed ToolSet related update.
12-08-05 19:42   
Harvested to inbox
12-08-05 20:18   
Speaking of process... ;)

I would really like to keep seperate track of when a team accepts a fix and submits it to the release team and then when the fix is actually included in a released public update and/or image. To that goal I think it would be best if this issue had not been closed at this stage but instead marked 'resolved'. Of course that requires someone to come back and mark the issue closed when it is truly and finally harvested.

This may sound like a pain in the ass but I think it's important. Fixes have been accepted in the past and then dropped and not appear in an image.
01-14-06 00:02   
in 6709 :)
script 20

01-14-06 00:34   
Thank you Stef, I really appreciate it.

01-14-06 00:34   
And since this is now in a public update it can be closed.