On Tue, Jan 07 2014, João Távora wrote:
[...]
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.
Yes, it seems like an advantage. Well I understand your point about debugging a familiar swank-loader.lisp, it's not so for others (i.e. co-workers not managing to get a contrib loaded or understanding why swank error'ed out and quit their Allegro suddently). ASDF offers good error messages and restarts, which are already familiar if you're in the quicklisp/asdf ecosystem.
In general, offloading some responsibilities to a software package that specilize in them is a good policy in my opinion.
Offloading stuff to ASDF doesn't sound much different from offloading stuff to quicklisp.
In my view `slime-init-command' should keep "returning a string to initialize lisp", as per its docstrings. But that string, by customizing a variable:
should, be default, be built around applying ASDF:REQUIRE-SYSTEM to :SWANK and/or whatever contribs the user has set up.
could be based on loading swank-loader.lisp from the current directory, which is the current case.
could be based on some custom swank-loading-logic if the user decides so.
Maybe we coulnd move the current swank-loader.lisp to swank-asdfless-loader.lisp and load it as per a `defcustom' that you enable in your config?
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.
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.
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
Or the "upgrade" stuff and Faré telling us how it fails in CMUCL and CCL. None of this inspires trust.
But I recognize that the masses have spoken and ASDF is the de-facto standard.
I would say ELPA packages must be installed and the user "makes" .elc files.
I don't undertand this bit. ELPA packages are uploaded by the developers onto remote repositories and fetched-and-installed via package.el's `package-install' command.
They can/should be built by us using a make target that picks out some files from the source repo, auto-generates others like slime-pkg.el. package-install then autogenerates a slime-autoloads.el file and byte compiles the remaining ones, sets up load paths and all that.
All I'm saying is that M-x package-install is not that different from "make install".
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))
At first sight, this would personally bug me: why not do this in the user's .emacs in elisp? Why this file?
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.
very few EMACS packages have their own config files (I can think of Gnus only) and they are all emacs-lisp, so that they can be perfectly replaced with elisp code in user's init files. I would see no advantage in adding one such file to SLIME.
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.
Also, storing per-project settings in a config file in the projects directory seems natural to me. A single .emacs just doesn't work well for that.
Also, if I understand correctly, this file would make ELPA (and el-get) packaging much more complicated and non-standard.
Not sure why that would be.
To be clear. I'm not adding a ASDF dependency to slime so that we get ASDF in the lisp runtime, although that is a side effect, unless we go to some lengths to delete the packages afterwards.
I'm adding it because it's becoming a standard and is specilized in representing dependencies between systems, which is something we can definitely use to simplify out loading behaviour:
to make addition of third-party contribs easier;
to ease bundling our own existing contribs in separate packages;
to have "one" way of loading swank, less 300 lines to maintain, and one less option-hungry SWANK-LOADER:INIT to worry about.
Once we have a simple enough loading behaviour, it's much easier to add installation behaviours that serve:
- your "make install" use case
- the hacker's clone-my-own case
- ELPA's package-install <some-package-depending-on-slime>
- el-get
we know how to load quicklisp but doesn't mean we load it all the time.
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.
Helmut