Bert Freudenberg bert at
Sun Apr 2 07:57:31 UTC 2006

The image defaults to Latin1Environment on Mac, but John's VM did not  
support Latin1 until very recently. It does support UTF-8, however,  
there is no UTF8Environment that could be set as default.

A hack that I used was to manually set the filename converter class  
to  UTF-8 after startup, but that's cumbersome.

- Bert -

Am 02.04.2006 um 04:38 schrieb Yoshiki Ohshima:

>   John,
>   It may be done poorly.  But the idea is to switch the encoding in
> the image by providing the right fileNameConverter.
>   I'm not sure what you mean by "in image encoding assumes latin-1".
> If the file browser doesn't show the right file name, the right fix is
> to change the fileNameConverter, not changing the VM.
> -- Yoshiki
> At Wed, 29 Mar 2006 21:35:47 -0800,
> John M McIntosh wrote:
>> Ah, poorly.
>>  From what I've seen the in image encoding assumes latin-1. It gets
>> macroman from the VM and mangles, demangles that ok, however
>> displays the characters then wrong in the file browser.  If you
>> switch the VM to use latin-1 then characters are displayed correctly,
>> however
>> it is possible to create file names that contains characters that
>> UTF-8 allows but has not latin-1 mapping, thus the internal VM
>> mapping from that character to latin-1 fails.
>> Keeping the VM in UTF-8 seems to work, of course FilePath mangles
>> that as latin-1 and the names are not displayed correctly.
>> On 29-Mar-06, at 6:42 PM, Yoshiki Ohshima wrote:
>>>   Hello,
>>>> Well, my point is that if we expose that primitive to the image,
>>>> we will
>>>> never have the need to do it from a plugin because you can always
>>>> pass a
>>>> valid file name into it. It's really strange to me that the VM does
>>>> translation for stuff which is (supposedly) handled in the image
>>>> already. I could understand this if we would shoot for a file/
>>>> directory
>>>> abstraction inside the image but the way it's right now we're  
>>>> hiding
>>>> stuff from the image that the image supposedly is responsible for
>>>> (platform file name handling) and that's Just Wrong (tm).
>>>   Since Squeak3.8, FilePath class is supposed to do the  
>>> conversion.  I
>>> wonder if how ioFilename:fromString:ofLength:resolveAliases:  
>>> interacts
>>> with FilePath...
>>> -- Yoshiki
>> --
>> ===================================================================== 
>> ===
>> ===
>> John M. McIntosh <johnmci at> 1-800-477-2659
>> Corporate Smalltalk Consulting Ltd.  http:// 
>> ===================================================================== 
>> ===
>> ===

More information about the Vm-dev mailing list