[Pharo-project] return character magic?
Hi all, Just last week, I had a very strange phenomenon in my Pharo image: the return character (^) was changed by an up arrow (see screenshot below). I was not really able to reproduce the 'problem' but now we got a repeatable one: Just load the attached js file in a Seaside WAFilelibrary (WAFilelibrary addFileAt: ' ...'): you will see that the method will also have such a return char. What is going on? :-) I'm on Mac, using Pharo 1.1. cheers, Johan A MIME attachment of type <application/x-javascript> was removed here by a drop-attachments-by-name filter rule on the host <mail2-relais-roc.national.inria.fr>.
A while ago I got the same with _ Stef On Aug 30, 2010, at 8:28 PM, Johan Brichau wrote:
Hi all,
Just last week, I had a very strange phenomenon in my Pharo image: the return character (^) was changed by an up arrow (see screenshot below). I was not really able to reproduce the 'problem' but now we got a repeatable one:
Just load the attached js file in a Seaside WAFilelibrary (WAFilelibrary addFileAt: ' ...'): you will see that the method will also have such a return char.
What is going on? :-)
I'm on Mac, using Pharo 1.1.
cheers, Johan
<Screen shot 2010-07-29 at 17.15.29.png> A MIME attachment of type <application/x-javascript> was removed here by a drop-attachments-by-name filter rule on the host <mail2-relais-roc.national.inria.fr>.
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
so what did you do? I see that the file got removed... I will submit a bug issue for that with the file attached. The *real* problem is that you cannot remove it either! It does _not_ want to go away! On 30 Aug 2010, at 20:31, Stéphane Ducasse wrote:
A while ago I got the same with _
Stef
On Aug 30, 2010, at 8:28 PM, Johan Brichau wrote:
Hi all,
Just last week, I had a very strange phenomenon in my Pharo image: the return character (^) was changed by an up arrow (see screenshot below). I was not really able to reproduce the 'problem' but now we got a repeatable one:
Just load the attached js file in a Seaside WAFilelibrary (WAFilelibrary addFileAt: ' ...'): you will see that the method will also have such a return char.
What is going on? :-)
I'm on Mac, using Pharo 1.1.
cheers, Johan
<Screen shot 2010-07-29 at 17.15.29.png> A MIME attachment of type <application/x-javascript> was removed here by a drop-attachments-by-name filter rule on the host <mail2-relais-roc.national.inria.fr>.
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
On Aug 30, 2010, at 8:33 PM, Johan Brichau wrote:
so what did you do?
I see that the file got removed... I will submit a bug issue for that with the file attached.
The *real* problem is that you cannot remove it either! It does _not_ want to go away!
Oops! A bad spirit in pharo :) For me just resizing the window made it disappeared.
2010/8/30 Stéphane Ducasse <stephane.ducasse@inria.fr>:
On Aug 30, 2010, at 8:33 PM, Johan Brichau wrote:
so what did you do?
I see that the file got removed... Â I will submit a bug issue for that with the file attached.
The *real* problem is that you cannot remove it either! It does _not_ want to go away!
Oops! A bad spirit in pharo :)
Any person able to understand MultiDisplayScanner arcanes wouldn't see any magic in this. But I really wonder whether a single person can manage such complexity... Henrik ? Nicolas
For me just resizing the window made it disappeared.
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
On 30.08.2010 22:05, Nicolas Cellier wrote:
2010/8/30 Stéphane Ducasse<stephane.ducasse@inria.fr>:
On Aug 30, 2010, at 8:33 PM, Johan Brichau wrote:
so what did you do?
I see that the file got removed... I will submit a bug issue for that with the file attached.
The *real* problem is that you cannot remove it either! It does _not_ want to go away! Oops! A bad spirit in pharo :)
Any person able to understand MultiDisplayScanner arcanes wouldn't see any magic in this. But I really wonder whether a single person can manage such complexity... Henrik ?
Nicolas Hurr durr, I hate a challenge, can't really stop... In Pharo, the display primitive fails, and the fallback code does not deal correctly with the characterToGlyphMap used by StrikeFonts to store arrows at the normal ^_ spots, and substitute with characters at slots 128/129. In Squeak, the glyph-by-glyph rendering is encountered, and neither hasGlyphOf: nor glyphInfoInto: takes the map into account Attached is the fixed code for all three methods, should work in both Pharo and Squeak with these. (Issue 2886 on the Pharo tracker)
Cheers, Henry
El mar, 31-08-2010 a las 00:44 +0200, Henrik Sperre Johansen escribió:
On 30.08.2010 22:05, Nicolas Cellier wrote:
2010/8/30 Stéphane Ducasse<stephane.ducasse@inria.fr>:
On Aug 30, 2010, at 8:33 PM, Johan Brichau wrote:
so what did you do?
I see that the file got removed... I will submit a bug issue for that with the file attached.
The *real* problem is that you cannot remove it either! It does _not_ want to go away! Oops! A bad spirit in pharo :)
Any person able to understand MultiDisplayScanner arcanes wouldn't see any magic in this. But I really wonder whether a single person can manage such complexity... Henrik ?
Nicolas Hurr durr, I hate a challenge, can't really stop... In Pharo, the display primitive fails, and the fallback code does not deal correctly with the characterToGlyphMap used by StrikeFonts to store arrows at the normal ^_ spots, and substitute with characters at slots 128/129. In Squeak, the glyph-by-glyph rendering is encountered, and neither hasGlyphOf: nor glyphInfoInto: takes the map into account Attached is the fixed code for all three methods, should work in both Pharo and Squeak with these. (Issue 2886 on the Pharo tracker)
Impressive! :)
Cheers, Henry
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
-- Miguel Cobá http://miguel.leugim.com.mx
Henrik, you must be a kind of sorcerer or maybe a devil! Nicolas 2010/8/31 Henrik Sperre Johansen <henrik.s.johansen@veloxit.no>:
 On 30.08.2010 22:05, Nicolas Cellier wrote:
2010/8/30 Stéphane Ducasse<stephane.ducasse@inria.fr>:
On Aug 30, 2010, at 8:33 PM, Johan Brichau wrote:
so what did you do?
I see that the file got removed... Â I will submit a bug issue for that with the file attached.
The *real* problem is that you cannot remove it either! It does _not_ want to go away!
Oops! A bad spirit in pharo :)
Any person able to understand MultiDisplayScanner arcanes wouldn't see any magic in this. But I really wonder whether a single person can manage such complexity... Henrik ?
Nicolas
Hurr durr, I hate a challenge, can't really stop... In Pharo, the display primitive fails, and the fallback code does not deal correctly with the characterToGlyphMap used by StrikeFonts to store arrows at the normal ^_ spots, and substitute with characters at slots 128/129. In Squeak, the glyph-by-glyph rendering is encountered, and neither hasGlyphOf: nor glyphInfoInto: takes the map into account Attached is the fixed code for all three methods, should work in both Pharo and Squeak with these. (Issue 2886 on the Pharo tracker)
Cheers, Henry
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
alchemist! Stef On Aug 31, 2010, at 1:20 AM, Nicolas Cellier wrote:
Henrik, you must be a kind of sorcerer or maybe a devil!
Nicolas
2010/8/31 Henrik Sperre Johansen <henrik.s.johansen@veloxit.no>:
On 30.08.2010 22:05, Nicolas Cellier wrote:
2010/8/30 Stéphane Ducasse<stephane.ducasse@inria.fr>:
On Aug 30, 2010, at 8:33 PM, Johan Brichau wrote:
so what did you do?
I see that the file got removed... I will submit a bug issue for that with the file attached.
The *real* problem is that you cannot remove it either! It does _not_ want to go away!
Oops! A bad spirit in pharo :)
Any person able to understand MultiDisplayScanner arcanes wouldn't see any magic in this. But I really wonder whether a single person can manage such complexity... Henrik ?
Nicolas
Hurr durr, I hate a challenge, can't really stop... In Pharo, the display primitive fails, and the fallback code does not deal correctly with the characterToGlyphMap used by StrikeFonts to store arrows at the normal ^_ spots, and substitute with characters at slots 128/129. In Squeak, the glyph-by-glyph rendering is encountered, and neither hasGlyphOf: nor glyphInfoInto: takes the map into account Attached is the fixed code for all three methods, should work in both Pharo and Squeak with these. (Issue 2886 on the Pharo tracker)
Cheers, Henry
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Hi Henrik, twice you write a slip that the compiler should not allow: (map := characterToGlyphMap) ifNotNil: [:map | code := map at: code + 1]. code := (map := characterToGlyphMap) ifNil: [aCharacter charCode] ifNotNil: [:map | map at: aCharacter charCode + 1] these should read characterToGlyphMap ifNotNil: [:map | code := map at: code + 1]. code := characterToGlyphMap ifNil: [aCharacter charCode] ifNotNil: [:map | map at: aCharacter charCode + 1] HTH, Eliot also in BitBlt>>#primDisplayString:from:to:map:xTable:kern: you write ascii := glyphMap at: (aString at: charIndex) asciiValue + 1. whereas the current Squeak code reads ascii := (aString at: charIndex) asciiValue. glyphMap ifNotNil:[ascii := glyphMap at: ascii+1]. Should Squeak keep its original code (which seems equivalent) or is there a specific reason to eliminate the ifNotNil: test? TIA Eliot 2010/8/30 Henrik Sperre Johansen <henrik.s.johansen@veloxit.no>
On 30.08.2010 22:05, Nicolas Cellier wrote:
2010/8/30 Stéphane Ducasse<stephane.ducasse@inria.fr>:
On Aug 30, 2010, at 8:33 PM, Johan Brichau wrote:
so what did you do?
I see that the file got removed... I will submit a bug issue for that with the file attached.
The *real* problem is that you cannot remove it either! It does _not_ want to go away!
Oops! A bad spirit in pharo :)
Any person able to understand MultiDisplayScanner arcanes wouldn't see any magic in this. But I really wonder whether a single person can manage such complexity... Henrik ?
Nicolas
Hurr durr, I hate a challenge, can't really stop... In Pharo, the display primitive fails, and the fallback code does not deal correctly with the characterToGlyphMap used by StrikeFonts to store arrows at the normal ^_ spots, and substitute with characters at slots 128/129. In Squeak, the glyph-by-glyph rendering is encountered, and neither hasGlyphOf: nor glyphInfoInto: takes the map into account Attached is the fixed code for all three methods, should work in both Pharo and Squeak with these. (Issue 2886 on the Pharo tracker)
Cheers, Henry
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
On 31.08.2010 01:32, Eliot Miranda wrote:
Hi Henrik,
twice you write a slip that the compiler should not allow:
(map := characterToGlyphMap) ifNotNil: [:map | code := map at: code + 1].
code := (map := characterToGlyphMap) ifNil: [aCharacter charCode] ifNotNil: [:map | map at: aCharacter charCode + 1]
these should read
characterToGlyphMap ifNotNil: [:map | code := map at: code + 1].
code := characterToGlyphMap ifNil: [aCharacter charCode] ifNotNil: [:map | map at: aCharacter charCode + 1]
HTH, Eliot Hum, unless I posted a previous version, the code in the changeset was: characterToGlyphMap ifNotNil: [:map | code := map at: code +1]. and code := characterToGlyphMap ifNotNil: [:map | map at: aCharacter charCode +1] ifNil: [aCharacter charCode].
Seem to me they got decompiled somehow?
also in BitBlt>>#primDisplayString:from:to:map:xTable:kern: you write
ascii := glyphMap at: (aString at: charIndex) asciiValue + 1.
whereas the current Squeak code reads
ascii := (aString at: charIndex) asciiValue. glyphMap ifNotNil:[ascii := glyphMap at: ascii+1].
Should Squeak keep its original code (which seems equivalent) or is there a specific reason to eliminate the ifNotNil: test?
TIA Eliot
Yes, it should keep it. Getting late, I made that change in that method first to have Pharo display correctly, and didn't yet think of that glyphMap may be nil :) For Squeak, the two methods in StrikeFont should be sufficient. Cheers, Henry
2010/8/30 Henrik Sperre Johansen <henrik.s.johansen@veloxit.no>
On 31.08.2010 01:32, Eliot Miranda wrote:
Hi Henrik,
twice you write a slip that the compiler should not allow:
(map := characterToGlyphMap) ifNotNil: [:map | code := map at: code + 1].
code := (map := characterToGlyphMap) ifNil: [aCharacter charCode] ifNotNil: [:map | map at: aCharacter charCode + 1]
these should read
characterToGlyphMap ifNotNil: [:map | code := map at: code + 1].
code := characterToGlyphMap ifNil: [aCharacter charCode] ifNotNil: [:map | map at: aCharacter charCode + 1]
HTH, Eliot
Hum, unless I posted a previous version, the code in the changeset was:
characterToGlyphMap ifNotNil: [:map | code := map at: code +1]. and code := characterToGlyphMap ifNotNil: [:map | map at: aCharacter charCode +1] ifNil: [aCharacter charCode].
Seem to me they got decompiled somehow?
Oops, quite right! I think I did pretty diffs and this is what I got. Bad pretty diffs, bad :)
also in BitBlt>>#primDisplayString:from:to:map:xTable:kern: you write
ascii := glyphMap at: (aString at: charIndex) asciiValue + 1.
whereas the current Squeak code reads
ascii := (aString at: charIndex) asciiValue. glyphMap ifNotNil:[ascii := glyphMap at: ascii+1].
Should Squeak keep its original code (which seems equivalent) or is there a specific reason to eliminate the ifNotNil: test?
TIA Eliot
Yes, it should keep it. Getting late, I made that change in that method first to have Pharo display correctly, and didn't yet think of that glyphMap may be nil :) For Squeak, the two methods in StrikeFont should be sufficient.
Cool, thanks! Eliot
Cheers, Henry
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
It happens with WideStrings, you get the normal display with ByteString instances. To reproduce just print an expression like "Character value: 1024" if you can't type non-ascii characters on your keyboard. Now, why the display changes I don't know either ... Lukas On 30 August 2010 20:31, Stéphane Ducasse <stephane.ducasse@inria.fr> wrote:
A while ago I got the same with _
Stef
On Aug 30, 2010, at 8:28 PM, Johan Brichau wrote:
Hi all,
Just last week, I had a very strange phenomenon in my Pharo image: the return character (^) was changed by an up arrow (see screenshot below). I was not really able to reproduce the 'problem' but now we got a repeatable one:
Just load the attached js file in a Seaside WAFilelibrary (WAFilelibrary addFileAt: ' ...'): you will see that the method will also have such a return char.
What is going on? :-)
I'm on Mac, using Pharo 1.1.
cheers, Johan
<Screen shot 2010-07-29 at 17.15.29.png> A MIME attachment of type <application/x-javascript> was removed here by a drop-attachments-by-name filter rule on the host <mail2-relais-roc.national.inria.fr>.
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
-- Lukas Renggli www.lukas-renggli.ch
participants (7)
-
Eliot Miranda -
Henrik Sperre Johansen -
Johan Brichau -
Lukas Renggli -
Miguel Enrique Cobá MartÃnez -
Nicolas Cellier -
Stéphane Ducasse