On Wed, Jun 10, 2015 at 5:51 PM, Raymond Toy <toy.raymond@gmail.com> wrote:
"Fare" == Far <Far> writes:
Fare> On Wed, Jun 10, 2015 at 1:55 PM, Raymond Toy <toy.raymond@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.