yoshiki at squeakland.org
Sun Apr 2 02:38:39 UTC 2006
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.
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:
> > 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