John M McIntosh
johnmci at smalltalkconsulting.com
Sun Apr 2 07:17:40 UTC 2006
Well the VM is given a info.plist entry or cmd line that defines what
encoding to use. This information needs to be gotten from
the VM in order to set the proper filenameConverter. My understanding
was that the default for the mac carbon vm was
MacRoman, but the fileNameConverter used in 3.8? is latin-1. If I
choose latin-1 there are characters in the utf-8 character set
os-x that can't be translated to latin-1 so latin-1 technically is
not a viable choice. I understand UTF-8 is viable, but somehow the
image should configure that from the Vm without manual intervention.
On 1-Apr-06, at 6:38 PM, Yoshiki Ohshima wrote:
> 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,
>> 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:
>>>> 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/
>>>> abstraction inside the image but the way it's right now we're
>>>> 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:
>>> with FilePath...
>>> -- Yoshiki
>> John M. McIntosh <johnmci at smalltalkconsulting.com> 1-800-477-2659
>> Corporate Smalltalk Consulting Ltd. http://
John M. McIntosh <johnmci at smalltalkconsulting.com> 1-800-477-2659
Corporate Smalltalk Consulting Ltd. http://www.smalltalkconsulting.com
More information about the Vm-dev