VM file name character encoding support (pending)
John M McIntosh
johnmci at smalltalkconsulting.com
Mon Dec 1 20:58:41 UTC 2003
On Nov 27, 2003, at 10:51 PM, Yoshiki Ohshima wrote:
> Adding those functions may be ok. I would prefer the IANA encoding
> names over the magic numbers, though.
>> This allows plugins, like the mpeg plugin to accept a file name from
>> the VM and know what to do
>> with it before issuing the file open by asking the VM what the
>> is. It also of course allows
>> a programmer the ability to see and choose an encoding to use within
>> the Image.
> Having different internal encoding wouldn't be a good idea. Such
> plugin shouldn't bother to translate the file names passed.
The mpeg plugin is a good example of the problem here because we pick
the mp3 name via results returned from directory information which then
be in UTF-8. If the primitive doesn't use the sqFilenameFromStringOpen
then the character string will be wrong and require translation.
admit that usage of sqFilenameFromStringOpen and sqFilenameFromString
solve this issue because they are responsible for translation from/to
the desired results
for fopen() and the like. I'll review if this is really an issue.
>> What is unclear, but could be defined is how to deal with existing
>> information, such as the vmpath
>> once you switch encoding. I suppose you could leave that information
>> native platform format and
>> return a converted value based on the currently chosen encoding.
> Is the info like VM path used before the image becomes *live* and
> take the control? Using somewhat native encoding for VM path,
> etc. sounds make sense to me.
This I would guess depends on the implementation, on the mac the vmPath
before the image goes live because it's needed for things like finding
> -- Yoshiki
John M. McIntosh <johnmci at smalltalkconsulting.com> 1-800-477-2659
Corporate Smalltalk Consulting Ltd. http://www.smalltalkconsulting.com
More information about the Squeak-dev