[Openmcl-devel] OpenMCL for Linux x86-64 available for testing

[Gary Byers]

On Sun, 7 May 2006, Gary Byers wrote:

>
>
> On Sun, 7 May 2006, Eric Marsden wrote:
>
>>>>>>> "gb" == Gary Byers <gb at clozure.com> writes:
>>
>>  gb> Fixed in CVS
>>
>>  thanks, cl-pdf seems to work fine in some light testing, as does
>>  cl-bench. I got certain simple CLX demos to run (using telent-clx),
>>  but others cause a SEGV and break to the low-level debugger.
>
> I'll look at it; thanks.
>

A function in clx/demo/clx-demos (DEMOS::FULL-WINDOW-STATE) does something
like:

(let* ((l (list* x y)))
   (declare (dynamic-extent l))
   ...)

and aparently had the dubious honor of being the first thing that does
that (stack-consed LIST*) that anyone's tried yet on the new port.  That's
now fixed in CVS, and all of the CLX demos that I've tried so far seem
to work.

I did run into another problem that Eric may not have: since I was
ssh'ed into the amd64 box, clx tried to read my .Xauthority file and
had to call the version of XLIB::HOST-ADDRESS that's defined in
clx/dep-openmcl.lisp while parsing the contents.  XLIB::HOST-ADDRESS calls
an internal CCL package function (CCL::HOST-AS-INET-HOST) which
returns a 32-bit IPv4 address in network byte order, then returns 4
octets as if that address was in host byte order (so "localhost" gets
mapped to (:internet 1 0 0 127) instead of (:internet 127 0 0 1)).
That version of XLIB::HOST-ADDRESS should probably call
OPENMCL-SOCKET:LOOKUP-HOSTNAME instead of CCL::HOST-AS-INET-HOST, and
this may not be the last byte-ordering bug that anyone runs into ...