[slime] swank-loader could use ASDF (#65)

[Faré]

On Tue, Jan 7, 2014 at 3:58 PM, Helmut Eller <eller.helmut at gmail.com> wrote:
> Offloading stuff to ASDF doesn't sound much different from offloading
> stuff to quicklisp.
>
Even less different when quicklisp offloads the system loading work to ASDF.
What quicklisp does that ASDF doesn't is download stuff of the network;
for compiling and loading the downloaded systems, it delegates to ASDF.

> Well, we don't need a default, one option for me, and a third option for
> the exotic cases.  Just put be in the exotic case.
>
I agree that the endgame should be a single way to load the code
that works well for everyone on all platforms.

>> Still, I'm curious as to why you don't you trust ASDF? Any specific
>> problems in mind?
>
> As I said in a another message, I had experiences like this:
>
>  1. (asdf:load-system foo),
>  2. then had some load-time problem,
>  3. cleaned out the cache,
>  4. and magically (asdf:load-system foo) worked.
>
Are these experiences recent? If so, that's a troubling bug indeed,
either in ASDF or in the system foo.
ASDF should not have this kind of behavior anymore,
unless system foo is doing something both funky and buggy.
If you experience this again, please take it to the asdf-devel mailing-list,
it's a matter that we're serious about eliminating.

> Or just a few days ago:
>
>  This is SBCL 1.1.12-1.fc20, an implementation of ANSI Common Lisp.
>  ...
>  * (require :asdf)
>  * (uiop:with-temporary-file (:stream s) s)
>
>  debugger invoked on a SB-INT:SIMPLE-FILE-ERROR in thread
>  #<THREAD "main thread" RUNNING {AC17981}>:
>    Couldn't remove "/tmp/tmp9MFH86" while closing #<SB-SYS:FD-STREAM
>                                                       for "file /tmp/tmp9MFH86"
>                                                     {BAD9B51}>:
>   No such file or directory
>
I did a lot of work recently in with-temporary-file, to make it more
portable than it was, whereby many use cases would only run on some
platforms. I also improved its configurability and defaults, and added
proper tests to the test suite, so it should be and remain robust.
Unhappily, this means that with-temporary-file isn't portably reliable
until the imminent ASDF release 3.1.1. My apologies for the
inconvenience.

> Or the "upgrade" stuff and Faré telling us how it fails in CMUCL and
> CCL.  None of this inspires trust.
>
CMUCL has a bad bug in PCL and no one to fix it. Maybe I should think
harder about a workaround.

Three systems out of almost a thousand in Quicklisp have been found to
trigger a weird CLOS bug on CCL after an ASDF upgrade, unless some
classes are finalized somehow. We're investigating, but I don't think
that's a blocking issue.

Upgrades shouldn't be required in most cases, but when they're needed,
they're sorely needed (e.g. you need a fix to with-temporary-file, and
your implementation doesn't have a recent one). Happily, both CMUCL
and CCL keep their provided version of ASDF fairly up to date, so no
upgrade should be needed on either platform.

> But I recognize that the masses have spoken and ASDF is the de-facto
> standard.
>
ASDF has been a de facto standard for a long time now;
I've tried to make it actually robust and portable;
where I have failed, I'm eager to fix it.

> Because reading .emacs from Common Lisp is difficult.  It's also much
> easier to automatically update a config file that contains only
> "declarative" stuff and no general Lisp code.  And why would you put
> information about quicklisp into your .emacs in the first place?  I
> could understand .sbclrc or .swank.lisp.
>
I agree that Emacs can pass any necessary information to CL
at initialization time based on its configuration, much more easily
than CL can be taught (and maintained!) to read Emacs configuration.

> The requirements of most Emacs packages are quite different.  Few Emacs
> packages ship substantial non-Emacs-Lisp source code around and have to
> initialize half a dozen different interpreters each with different
> command line arguments etc.
>
I maintain lisp-invocation.asd to handle the same issue for XCVB,
but it's not maintainably sharable with Emacs.
(Though it could be, as long as maintained as part of SLIME.)

>> I'm still confused. When don't we load it? BTW I think quicklisp
>> always loads ASDF.
>
> We could load quicklisp during "make install".  That's the time when you
> potentially need to download third party Common Lisp code.  E.g. when a
> contrib depends on cl-pcre.  We could also use it when a user wants to
> add a library to his project, e.g. we could have something like M-x
> slime-quickload.
>
That's probably a good idea.
Something similar for clbuild would be nice, too.
In a production environment, this would be slightly harder,
because you'd want to import things into your project's version control.

—♯ƒ • François-René ÐVB Rideau •Reflection&Cybernethics• http://fare.tunes.org
"Don't worry about people stealing your ideas.  If your ideas are any good,
you'll have to ram them down people's throats."         — Howard Aiken