On 5 April 2010 14:12, Robert Goldman rpgoldman@sift.info wrote:
On 4/4/10 Apr 4 -9:50 PM, Faré wrote:
I would in order prefer the following:
- disable output-translations by default.
I think we can't do that, because of things like system-installed source code and users who use both clisp and ecl (that share the .fas suffix) or i386 and x86-64 SBCL (that share the .fasl suffix), etc.
If a novice wants to know where the fasls are, I prefer to give the explanation once than to give plenty of explanations with as many special rules.
Ah. I see. Then is there a "disable output translations for MY files, and do the right thing with system installed code"?
I could add a keyword argument to disable-output-translations for that -- and the question remains, which should be the default?
Note to Mario: I tend to prefer a functional interface where you call a function to initialize the complete state of the output-translation facility, to an interface with plenty of special variables that you must all set or reset, save or restore, to set the state of the facility.
I agree with you about people who use clisp and ecl, multiple SBCLs, ACL
- SBCL, but I'm not convinced that those people are common enough that
we should arrange the world around them. I am, after all, one of these people and I am a user of ASDF-BINARY-LOCATIONS.
I believe that people who don't care don't care and shouldn't care: a user-cache does automagically the right thing for all of them.
However, there are a lot of people out there who use only a single CL. Indeed, I work with them, both in my company and out.
But do they care that the fasls be in current directory rather than a central cache?
The only break cases I can imagine are: * user removes directory, recreates it from an archive with pre-modified source being backdated, asdf reuses fasls from modified source unless the user explicitly clears the cache.
* user keeps installing and deleting new software of software, trying or upgrading CL implementations, moving stuff around, yet has a machine with a small disk. The cache grows big and needs to be explicitly cleared.
I'd tend to think either case would require a user who is enough of an expert to learn to clear the cache, and to be tempted to use multiple implementations at which point the cache is a good default.
- provide a clean disable-output-translations.
Done in 1.665: (asdf:disable-output-translations)
Given your remarks above, is this going to do something bad, by wrecking system-installed code?
Probably. If you do that, you are probably avoiding system-installed code. Or there should be two versions of disable, one that takes precedence and one that doesn't.
Reminds me that the current code uses a stable-sort according to the length of the directory component of the source pattern...
What I would like us to be able to offer is something that will feel like classic ASDF (or, for that matter, COMPILE-FILE) --- if you have foo.lisp, you get foo.fasl (or whatever), by default, next to foo.lisp. If you don't want that, we have something way better to offer you in asdf-output-translations. But if you /do/ want that, how do you get it?
(disable-output-translations) will do that.
I think the main question is which is a better, more newbie-friendly and future-proof default.
I lean the central cache way. But I can be convinced otherwise.
[ François-René ÐVB Rideau | Reflection&Cybernethics | http://fare.tunes.org ] Democracy is a religion too. It's the worship of jackals by jackasses. — H. L. Mencken