[cmucl-imp] Snapshot 2015-06

[Faré]

On Wed, Jun 10, 2015 at 5:51 PM, Raymond Toy <toy.raymond at gmail.com> wrote:
>>>>>> "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.
>
ext:*environment-list* is O(n); it sucks and is totally clunky, and
not case-preserving. Kill it with fire.

>     >> 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.
>
It doesn't make sense for the normal tarball to contain asdf but not
some module required for asdf.

Maybe add a canary test for your tarballs, that makes sure you can run
some trivial asdf program?

>     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.
>
Yup, probably not worth stirring the ancient cesspool and risking to
awaken a great old one.

Thanks for your support!

—♯ƒ • François-René ÐVB Rideau •Reflection&Cybernethics• http://fare.tunes.org
Reason wins in the long run, because irrational memes fight each other,
whereas rational memes add up.