InterpreterProxy>>ioFilename:fromString:ofLength:resolveAliases:?
John M McIntosh
johnmci at smalltalkconsulting.com
Thu Mar 30 05:35:47 UTC 2006
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 smalltalkconsulting.com> 1-800-477-2659
Corporate Smalltalk Consulting Ltd. http://www.smalltalkconsulting.com
========================================================================
===
More information about the Vm-dev
mailing list