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

Faré fahree at gmail.com
Mon Jan 6 23:25:51 UTC 2014


> 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.
Is this supposed to add SLIME to your CL source-registry?
Or is Emacs supposed to point CL to the files
that correspond to the current SLIME's installation?
What when one is using a remote SLIME?

>> According to Francois, startup times are seem OK. M-x slime on sbcl
>> takes well more than two seconds for me. But
>>
M-x slime on sbcl takes about three seconds for me,
but ASDF is a small part of that
(I use swank-asdf, so it is part of the slime startup already).

> 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.)

>> 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 would say ELPA packages must be installed and the user "makes" .elc
> files.
>
> Assume we know how to load quicklisp. Let's say the user needs to create
> a config file, ~/.slime/config, that looks like so:
>
> (:load-quicklisp-form (cl-user:load-quicklisp)
>  :load-asdf-form (require :asdf)
>  :slime-contribs (slime-repl slime-foo))
>
> With that we know how to load quicklisp, but that doesn't mean we load
> it all the time.  We would read the config file every time, but load
> quicklisp, and possibly ASDF, only when we need to install/compile our
> stuff.
>
That mostly makes sense. Beware though that it is better to load ASDF
before Quicklisp, and to load an ASDF version no older than the one
required by Quicklisp. While ASDF is designed to be upgraded,
some implementations seem to have issues when an old ASDF is loaded,
then upgraded (CMUCL totally fails upgrade, and
CCL looks like it has odd corner cases at times after upgrade).
That means it's better to manage the loading of ASDF than to let
two independent mechanisms introduce discrepancy and fail.

Frankly, I'm the first hater and doubter of ASDF,
but at the same time, I favor more declarative and more manageable
installation of software, and I believe ASDF helps much more than it costs
(ASDF 1 admittedly wasn't quite there yet,
and I totally understand why SLIME was built without it;
however, ASDF 2.26 is OK, and ASDF 3 is quite decent I believe.)

—♯ƒ • François-René ÐVB Rideau •Reflection&Cybernethics• http://fare.tunes.org
Mathematics is the Queen of Science but she isn't very Pure; she keeps
having babies by handsome young upstarts and various frog princes.
  — Donald Kingsbury (In "psychohistorical crisis", 2001)



More information about the slime-devel mailing list