[Openmcl-devel] Debian packaging for CCL

[Gary Byers]

On Sat, 30 Jun 2012, Faheem Mitha wrote:

>
> Hi Gary,
>
> Thanks for the reply.
>
> On Fri, 29 Jun 2012, Gary Byers wrote:
>
>> I don't know of any more recent attempts to package CCL for Debian.
>> AFAIK, it's in MacPorts for OSX, in the FreeBSD ports system, and
>> (IIRC) in Gentoo's package system. The actual packaging technology
>> in those cases is different from Debian's, but you might find it
>> helpful to look at those efforts.
>
> Thanks for the pointers.
>
>> A year or two ago, someone got fairly far in the process of packaging
>> CCL for Fedora.  Their attempts to get it accepted into the Fedora
>> distribution kept getting rejected by whoever decides these things.
>> CCL - like many other Lisps and like some other programming
>> environments - puts code in memory and executes it; in order for this
>> to work, its heap (and sometimes stack) pages have to be mapped with
>> execute permission, and this set off a red flag for the reviewer.  I
>> think that the person who was trying to do the packaging got
>> frustrated by the process and gave up; the reviewer may have just been
>> going through a checklist and may not have understood the issue(s) too
>> deeply.  I think that other applications that do similar things (for
>> similar reasons) are distributed with Fedora, so this may have just been
>> a case of (bad) luck of the draw.
>
> Do you recall who this person was and/or his/her contact info?

<https://bugzilla.redhat.com/show_bug.cgi?id=562226>  seems to describe some
of the history of that effort.


>
>> I don't want to discourage you if you're interested in doing this; having
>> CCL available in Debian (and likely Ubuntu) is mostly a good thing for
>> CCL (some - possibly large - number of people who might be interested in
>> CCL but aren't aware of it might become aware of it.)  There's a tradeoff;
>> if there are versions available in the package system, they may not always
>> be the most recent versions and it may not be possible or practical for
>> users of those versions to get bug fixes via svn.  The advantages - broader
>> visibility of CCL - likely outweigh these concerns, and if you want to
>> pursue this the results could be good for CCL in general.
>
> I'm currently just poking around a little, trying to understand what is going 
> on.
>
> I'm currently seeing a rebuild failure on trunk from a clean checkout. I've 
> been able to reproduce it a few times. See below. Maybe I'm doing something 
> wrong. If so, clarifications/corrections would be appreciated. However, the 
> same producedure works for me for the 1.8 release.

You may have the environment variable CCL_DEFAULT_DIRECTORY set to some directory
other than the directory you're trying to build in.


>
> It seems the only files that change in this rebuild are lx86cl and 
> lx86cl.image, correct? This is with Debian squeeze, 32 bit.

FASL files (*.lx32fsl), .o files, and a bootstrapping image (x86-boot32) are
also (re-)created.

>
> A second, related question. It seems the lx86cl.image is the heap image, and 
> has everything loaded into it. I was wondering what other files from the 
> installation are needed. It seems something else is. I did the following 
> little experiment. I copied lx86cl and lx86cl.image to /tmp. Now these files 
> have no knowledge about the rest of the installation. Then I ran 'rlwrap 
> ./lx86cl'. I get the following error.
>
> faheem at orwell:/tmp$ rlwrap ./lx86cl
>> Error: Unbound variable: CCL::FASL-VERSION
>> While executing: ASDF::LISP-VERSION-STRING, in process listener(1).
>> Type :GO to continue, :POP to abort, :R for a list of available 
> restarts.
>> If continued: Skip loading init file.
>> Type :? for other options.
> 1 >

You might want to look at your init file (which may be doing (REQUIRE "ASDF"))
as well as whatever's setting CCL_DEFAULT_DIRECTORY (and therefore causing
REQUIRE to look in the wrong CCL directory and find an older, incompatible
version of ASDF.

>
> If I abort and carry on, then I can run quite complicated programs using 
> arrays and strings, and they execute correctly. However, I get an error when 
> trying to load another library. This works under normal usage.
>
> ? (require :cl-rmath)
> ASDF could not load cl-rmath because Unbound variable: CCL::FASL-VERSION.
>> Error: Unbound variable: CCL::FASL-VERSION
>> While executing: ASDF::LISP-VERSION-STRING, in process listener(1).
>> Type :POP to abort, :R for a list of available restarts.
>> Type :? for other options.
> 1 >
>
> With a correct installation, I get
>
> ? (require :cl-rmath)
> :CL-RMATH
> NIL

>
> So my question is, what other files are required for the installation to work 
> correctly, and why? The wrapper script exports CCL_DEFAULT_DIRECTORY, but 
> that does not tell me much.

The manual will hopefully tell you more; reading it is strongly suggested.

>
>                                                          Regards, Faheem