[cl-debian] Re: clc, asdf-install, slime, fasl paths, etc.
Bonjour Faré, Faré wrote:
I'm trying to find a lean way to compile lisp packages over my network-shared home directory with many implementations on many machines, and I yearn for a way that would unify what slime, c-l-c and asdf-install each do.
I immediately see the cause for a problem here: homedirectory. clc was meant to be machine-local, as to avoid mixing fasl's from different architectures.
Slime finds a nice way to create a (unique-directory-name) such as sbcl-0.9.3.26-linux-x86_64 and stores its fasl in ~/.slime/fasl/$UNIQUENAME/ This works great but only for slime and with manual cleaning.
If they clean up the copyright notices I might enhance the debian slime package to clean the local caches when a new implementation gets installed. Is this something you would like to have? I could also build in a hook into clc to allow moving the cache directory. Slime could then instruct clc to use the same directory.
c-l-c only uses things like /var/cache/common-lisp-controller/$USER/$IMPL/$PACKAGE (except trying to infer user name from directory name instead of
You mean from user-homedir-pathname? We just use that as a method to make $USER unique. There are no further requirements then the one that it is unique, which it should be as described by the specs. If the local administrator uses a scheme like /home/science/physics/solid-state/students/p/pv/pva/pvaneynd it would still work.
asdf-install will try to install in either ...
asdf is only well-described for sbcl, that is one of reasons I make clc. I did not place the fasls in $HOME because I wanted to make life easier for administrators, and /var/cache normally is on the backup exclusion list already :-)
which in the latter case is wrong when the machine is shared between several SBCL implementations.
And it has no method of removing old fasls. At least the sbcl people increase the fasl-version when it is required, unlike for example cmucl :-(.
Maybe we can think of something that would unify what happens for user installations for slime, c-l-c and asdf-install?
Well. I fear we have a fundamental difference in option: I do not think having fasls in (or beneath) the homedirectory is a good idea. I am happy to include hooks so that you can cause yourself problems to no end, but I prefer to not have to solve them. :-)
I understand that if there are risks of bad side-effects between packaging systems and little benefit to integration, then having widely different installation directories is actually a feature. On the other hand, having a semi-standard way of allowing installation of lisp stuff, including stuff that is currently under development and not (yet) system packaged would be a nice plus.
In theory there is clc-register-user-package and friends, but I agree they are not all what I imagined they would or could be. Groetjes, Peter -- signature -at- pvaneynd.mailworks.org http://www.livejournal.com/users/pvaneynd/ "God, root, what is difference?" Pitr | "God is more forgiving." Dave Aronson|
Hello, CL-debian'ers. I'm a new subscriber here. I understand there are many concerns with having a fasl cache under $HOME. However, there are times when this is not an option, and it would be nice to have some semi-standard packaging system for CL that supported but did not require system administrator access and/or that could be shared between many machines with same architecture. * It is evil to have lots of differently named cache directories under $HOME, that clutter backups (and/or prevent them from nicely fitting in your favorite media). Having everything under ~/.cache/lisp-fasl/ or ~/.lisp/cache/fasl/ should help. This would be the equivalent of the current /var/cache/common-lisp-controller/$USERNAME/ * Since a same implementation (sbcl, ecl, clisp, etc.) can have many variants (architectures, fasl or source versions), a proper cache subdirectory should distinguish between them. c-l-c could (optionally) rm -rf the global (and user?) cache directories when an implementation package is removed. * It would be nice to semi-standardize a string to name the fasl format -- and encourage implementations to provide a simple interface to such a string, falling back to some gross hack such as the one used by SLIME to generate its unique-directory-name. Be careful to make this interface user-overridable, so that the user may differentiate things that look the same but are not. For instance have it be a variable impl-ext:*fasl-format-name* that the user could set in an initialization file or command-line argument.
I could also build in a hook into clc to allow moving the cache directory. Slime could then instruct clc to use the same directory. That would be nice.
You mean from user-homedir-pathname? We just use that as a method to make $USER unique. Several users may have the same $HOME -- it's a user variable that can be set to anything, and the administrator might share paths in /etc/passwd, too. It would be better to use usernames from getpwuid(getuid()) -- maybe let the shell script wrapper do that if it's too hard to obtain from within all the various lisp implementations.
asdf is only well-described for sbcl, that is one of reasons I make clc. I did not place the fasls in $HOME because I wanted to make life easier for administrators, and /var/cache normally is on the backup exclusion list already :-)
Maybe we can think of something that would unify what happens for user installations for slime, c-l-c and asdf-install?
Well. I fear we have a fundamental difference in option: I do not think having fasls in (or beneath) the homedirectory is a good idea.
I think it's better to have a system cache, too. Sometimes this isn't an option. Or sometimes, you want to share that cache between machines. In any case, configurability would be nice, here. [ François-René ÐVB Rideau | Reflection&Cybernethics | http://fare.tunes.org ] Wir Mathematiker sind alle ein bisschen meschugge. (We mathematicans are all a bit crazy). -- Lev Landau
participants (2)
-
Faré -
Peter Van Eynde