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

[Helmut Eller]

On Tue, Jan 07 2014, Faré wrote:

>> My use case is more like:
>>
>>   git clone .../slime.git
>>   make install
>>
> How would that affect (or not) your .emacs?
> How is emacs supposed to find the correct slime?
> One still has to add it to the load-path, I presume.

make could ask if it should write or update ~/.slime/config.  It could
ask if it should update .emacs and add the directory to load-path or
perhaps install some ELPA style package with autoloads.

> Is this supposed to add SLIME to your CL source-registry?

It could add SWANK.  But that doesn't seem necessary.

> Or is Emacs supposed to point CL to the files
> that correspond to the current SLIME's installation?

Shouldn't matter if Lisp and Emacs read the same ~/.slime/config.

> What when one is using a remote SLIME?

swank-loader would read the remote ~/.slime/config.

>> I'm not worried about the one time cost of compiling lisp files.  I'm
>> talking about the cost of loading additional fasl files every time.
>>
> Incidentally, because I use swank-asdf (and seemingly, it's part of
> the default contribs on sbcl and ccl), I'm paying the price for it anyway,
> at which point I may as well enjoy some benefits from it, so it's no
> "additional fasl" to me. Admittedly, it is a small additional fasl for
> people who were not previously using that contrib, and/or
> who explicitly disabled it on sbcl or ccl. (.2s extra load time on CCL.)

Well:

Welcome to Clozure Common Lisp Version 1.9-dev-r15611M-trunk (LinuxX8664)!
? (time (require :asdf))
(REQUIRE :ASDF)
took 3,118,425 microseconds (3.118425 seconds) to run.


>>> I think with well crafted ASDF systems (and who better than François)
>>> this file could well dissapear.
>>
>> So you say that's a clear advantage?  Well, I still clear out ASDF's
>> fasl cache regularly because I don't trust ASDF.  And I rather debug the
>> code in swank-loader.lisp than in asdf.lisp.
>>
> Well, there would still be a top-level file, but
> swank-loader could be reduced to
> (require :asdf) (asdf:load-system :swank) (swank:init) or some such,
> with a more elaborate fallback for implementations that don't provide asdf.
>
> Have you had bad experiences with ASDF's fasl cache since ASDF 2.000?
> I agree that before then, the situation was quite bad, but since then,
> apart from slightly rough transitions when CCL made its fasl numbering
> per-target, or when Allegro introduced smp vs non-smp fasls,
> which I believe swank must have experienced, too,
> ASDF's fasl cache has always been just as good as swank's
> (from which it is proudly derived, after all — with many thanks).
>
> I see a few small advantages to ASDF's fasl cache:
> * it is configurable in a way that is important for production code;
>  IIRC, at ITA, we trick $HOME as being under the build tree
>  so that swank would store its fasls in a controlled place.
>  One configuration is better than two.
> * it matches source by path location, which means more sharing when
>  you upgrade SLIME (recompiling as needed, no more no less)
>  yet no accidental sharing when two subtly different
>  versions at different locations have a same version tag.
>
> That said if you've had issues, I'm curious to know what they were,
> and to make sure they have been addressed in the current (or else next)
> release of ASDF.

I don't track ASDF versions.  All I know is that a couple of times, I
did essentially:

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.

Helmut