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