[cmucl-imp] Snapshot 2015-06

Raymond Toy toy.raymond at gmail.com
Wed Jun 10 21:51:17 UTC 2015


>>>>> "Fare" == Far  <Far> writes:

    Fare> On Wed, Jun 10, 2015 at 1:55 PM, Raymond Toy <toy.raymond at gmail.com> wrote:
    >>>>>>> "Fare" == Far  <Far> writes:
    >> 
    >> >> The other changes to cmucl include:
    >> >>
    >> >> o The UNIX package has been changed; it now only contains just enough
    >> >> to compile all of cmucl.  If you want the rest of old UNIX package,
    >> >> use (require :unix) to get that.
    >> >>
    Fare> 1- This breaks ASDF, which assumed it could use unix-getenv and some such.
    >> 
    >> I looked at the asdf distributed with cmucl, which is version
    >> 3.1.4. asdf does have getenv, but not via unix-getenv. Instead it
    >> accesses ext:*environment-list*.
    >> 
    Fare> The latest 3.1.4.15 uses unix-getenv. I can revert that, if you wish.

What would you prefer? I'm open to adding back unix-getenv.  Since
cmucl tracks asdf fairly closely, it seems either would be ok.

    >> A quick grep through asdf.lisp only shows unix:unix-current-directory,
    >> unix:unix-chdir, unix:unix-stat, and unix:unix-rmdir, which are all
    >> available without doing (require :unix).
    >> 
    >> Is there some way for me to test asdf? (I confess I haven't run the
    >> asdf test suite with this new snapshot. I should have.)
    >> 
    Fare> cd asdf ; make t l=cmucl

    >> However, I do see that I've broken slime which wants to use
    >> unix:unix-execve, and perhaps others.  This is fixed by adding
    >> (require :unix) in my .cmucl-init.lisp script, but that's not really
    >> the solution I want.
    >> 

    Fare> BTW, I retried running cmucl after I rm rf lib/cmucl and tar jxf the
    Fare> 2015-06 tarball, and I can 100% reproduce the failure to (require

Ah, you also need the 2015-06 extra tarball since that contains the
contrib stuff.  Since this is a compatibility issue, it's probably
best if the normal tarball contained these files.  I'll make that
happen for the next snapshot.

    Fare> (LISP::INTERNAL-LOAD #P"modules:load-unix" NIL :ERROR NIL ...)
    Fare> Source: Error finding source:
    Fare> Error in function DEBUG::GET-FILE-TOP-LEVEL-FORM:  Source file no longer exists:
    Fare> target:code/load.lisp.
    Fare> 0] #p"modules:"

    Fare> #P"modules:"
    Fare> 0] (describe #p"modules:")

    Fare> #P"modules:" is a structure of type PATHNAME.
    Fare> HOST: #<LISP::UNIX-HOST>.
    Fare> DEVICE: NIL.
    Fare> DIRECTORY: (:ABSOLUTE #<SEARCH-LIST modules>).
    Fare> NAME:  NIL.
    Fare> TYPE: NIL.
    Fare> VERSION: NIL.

    Fare> What kind of pathname horror is THAT?????
    Fare> As if pathnames weren't horrible enough already, CMUCL invents
    Fare> additional pathname horrors!

You clearly have not been using cmucl for very long. :-)  That
search-list pathname stuff predates my involvement with cmucl.  Could
possibly predate support for logical pathnames.

It certainly would be better if the host were something like
#<lisp::search-list-host "modules"> and the :directory component could be more
like a regular list of directory components.  I did try to make that
happen briefly once but failed to succeed.  And decided that it wasn't
worth it to me.

--
Ray



More information about the cmucl-imp mailing list