[Openmcl-devel] wx86cl on international systems

Gary Byers gb at clozure.com
Thu May 14 21:21:55 PDT 2009


It'd be interesting to know whether or not passing the heap image name
explicitly makes things better, e.g.:

cmd prompt> cd C:\ccl&#12609
cmd prompt> wx86cl wx86cl.image

If that isn't provided, then the heap image name is something derived
from the kernel name in argv[0], which is likely a full pathname
encoded in some 8-bit Windows encoding.  open() can presumably handle
that encoding, but we wind up putting that 8-bit encoded string
somewhere where the code that initializes *HEAP-IMAGE-NAME* would find
it (and probably treat it as an ISO-8859-1-encoded C string.)  We wind
up using the TRUENAME of *HEAP-IMAGE-NAME* to initialize the CCL
logical host's translations, and that's where we seem to be dying.
If the heap image name is passed on the command line as a relative pathname,
TRUENAME winds up prepending the current directory to that, and that happens
to use Unicode-aware primitives and should therefore do the right thing.

I think you (Matt) are right that we have to at least ensure that the
strings that come from the command-line and are passed to the lisp
(and used to intialize *HEAP-IMAGE-NAME* and
*COMMAND-LINE-ARGUMENT-LIST*) are encoded in some way that we can
consistently decode without loss of information.  An incompatible
change would be to always decode them into native-endian UTF-32 in the
kernel and let the lisp side of things deal with that one case.



On Thu, 14 May 2009, R. Matthew Emerson wrote:

>
> On May 12, 2009, at 8:32 AM, dherring at tentpost.com wrote:
>
>> FWIW, clozure is very unhappy if installed in a path containing non-
>> ascii
>> characters.
>>
>> In cmd.exe, I cd to c:\cclㅁ (c:\cclM where M is the square
>> Korean
>> character; any Korean characters in the path have this effect) and run
>> C:\cclㅁ>wx86cl.exe > log.txt
>>
>> The head of log.txt follows, with a very large number of recursive-
>> lock
>> errors elided.
>
> I believe this is because the lisp kernel (a C program) is responsible
> for figuring out the path to the CCL directory.  The lisp deals well
> with the UTF-16 encoded pathnames that Windows uses, but the lisp
> kernel, well, not so much.
>
> It looks like we'd need to use GetCommandLineW and CommandLineToArgvW
> to convert the command line arguments to unicode-style strings, and
> then change the argument processing and image path name derivation
> code to use wchar_t functions.
>
> I'll open a ticket for this.
>
>
>>
>>
>>> Error: value NIL is not of the expected type (OR STRING PATHNAME
>>> STREAM).
>>> While executing: PATHNAME-DIRECTORY, in process Initial(0).
>>> Type :GO to continue, :POP to abort, :R for a list of available
>>> restarts.
>>> If continued: Skip (possibly crucial) startup function
>> CCL::INIT-LOGICAL-DIRECTORIES.
>>> Type :? for other options.
>>> Error: value NIL is not of the expected type CCL::RECURSIVE-LOCK.
>>> While executing: CCL::RECURSIVE-LOCK-PTR, in process Initial(0).
>>> Type :POP to abort, :R for a list of available restarts.
>>> Error: value NIL is not of the expected type CCL::RECURSIVE-LOCK.
>>> While executing: CCL::RECURSIVE-LOCK-PTR, in process Initial(0).
>>> Type :POP to abort, :R for a list of available restarts.
>> ...
>>
>> This is the 1.3 release tarball running on a Korean Windows XP system.
>>
>> Later,
>> Daniel
>>
>> _______________________________________________
>> Openmcl-devel mailing list
>> Openmcl-devel at clozure.com
>> http://clozure.com/mailman/listinfo/openmcl-devel
>
> _______________________________________________
> Openmcl-devel mailing list
> Openmcl-devel at clozure.com
> http://clozure.com/mailman/listinfo/openmcl-devel
>
>



More information about the Openmcl-devel mailing list