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