[Openmcl-devel] OpenMCL for Linux x86-64 available for testing
gb at clozure.com
Mon May 8 05:52:19 EDT 2006
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
(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
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 ...
More information about the Openmcl-devel