Subject: Re: "telent clx", "portable CLX", and the various Lisps
From: rpw3@rpw3.org (Rob Warnock)
Date: Tue, 20 Dec 2005 23:07:24 -0600
Newsgroups: comp.lang.lisp
Message-ID: <otidnUyLl6CRfjXeRVn-iw@speakeasy.net>
[I have changed "telnet" to "telent" in the Subject, 'cuz it was
bugging me. Apologies to those with non-threaded newsreaders for
whom it will cause a new pseudo-"thread".]

C Y <smustudent1@yahoo.com> wrote:
+---------------
| Rob Warnock wrote:
| > The quick & dirty version: To make (REQUIRE :FOO) work in CMUCL...
| 
| OK, thanks!  I'll try this later.  One potential problem - clx is
| multiple files and has an asd file to load it all - do I just put one
| provide in the asd file?
+---------------

You can do it that way, as Pascal showed you in a parallel reply.
Or since this is CMUCL, you could just concatenate all of the FASLs
together [well, in the right order] to produce one big ".x86f" file.
This is how the "clx-library.x86f" in the "extras" tarball gets built
for the CMUCL distribution. Observe:

   $ tr @ '\012' < clx-library.x86f | grep -a '^FASL'
   FASL FILE output from target:clx/package.lisp.
   FASL FILE output from target:clx/depdefs.lisp.
   FASL FILE output from target:clx/clx.lisp.
   FASL FILE output from target:clx/dependent.lisp.
   FASL FILE output from target:clx/macros.lisp.
   FASL FILE output from target:clx/bufmac.lisp.
   FASL FILE output from target:clx/buffer.lisp.
   FASL FILE output from target:clx/display.lisp.
   FASL FILE output from target:clx/gcontext.lisp.
   FASL FILE output from target:clx/input.lisp.
   FASL FILE output from target:clx/requests.lisp.
   FASL FILE output from target:clx/fonts.lisp.
   FASL FILE output from target:clx/graphics.lisp.
   FASL FILE output from target:clx/text.lisp.
   FASL FILE output from target:clx/attributes.lisp.
   FASL FILE output from target:clx/translate.lisp.
   FASL FILE output from target:clx/keysyms.lisp.
   FASL FILE output from target:clx/manager.lisp.
   FASL FILE output from target:clx/image.lisp.
   FASL FILE output from target:clx/resource.lisp.
   FASL FILE output from target:code/clx-ext.lisp.
   FASL FILE output from target:hemlock/charmacs.lisp.
   FASL FILE output from target:hemlock/key-event.lisp.
   FASL FILE output from target:hemlock/keysym-defs.lisp.
   $ 

But if you want to keep tracking the ASDF-mediated version of
"telent CLX", I'd do it the way Pascal suggested. [Or add ASDF
support to CMUCL's REQUIRE yourself, see below.]

+---------------
| > p.s. If that doesn't work for you [probably because you have
| > CMUCL installed differently], I'll go into a longer explication
| > of the #p"modules:" and #p"library:" "search lists", but it ain't
| > pretty!  :-{  Hint: Type this in and try to grok what it tells you:
| >
| >   (loop for k being each hash-key in lisp::*search-lists*
| > 	      using (hash-value v)
| >     when (lisp::search-list-defined v)
| >       collect (cons k (lisp::search-list-expansions v)))
| 
| Is this a standard feature in other lisps or is (require <whatever>)
| unique to cmucl/sbcl?  (/me hopes it's the former...)
+---------------

Well... uh... this is one of those "standardized non-standard features"
in the ANSI CL spec!!  ;-}  ;-}  That is, REQUIRE/PROVIDE themselves are
standard enough:

    http://www.lispworks.com/documentation/HyperSpec/Body/f_provid.htm

but exactly how (REQUIRE :FOO) [with no optional pathname-list]
translates to a file *isn't*!!

    If the pathname-list is nil, an implementation-dependent mechanism
    will be invoked in an attempt to load the module named module-name...

For CMUCL, the function documentation -- try (DESCRIBE #'REQUIRE) --
is fairly helpful, but for the gory details see the source file
"cmucl/src/code/module.lisp". The function REQUIRE is quite simple;
most of the fussing with pathnames is done in MODULE-DEFAULT-PATHNAME
[try calling DESCRIBE on that one, too].

Other implementations have different ways of interpreting REQUIRE.
Current releases of SBCL, in particular, will also try using ASDF to
load a module requested with REQUIRE. [Looking at the code, it appears
that it would be very easy to add the same to CMUCL -- it's just that
no-one has yet, AFAIK.]


-Rob

-----
Rob Warnock			<rpw3@rpw3.org>
627 26th Avenue			<URL:http://rpw3.org/>
San Mateo, CA 94403		(650)572-2607