OK, so should the default be no translation, except for software that is system installed?
I still think that the cache being on by default is ultimately simpler, least surprising, and more useful.
Mario's analogy with make is OK to a point, but ASDF differs very much from make, too. And with multiple implementations, making a "don't map" default can really get in the way. Especially as I'd like to promote some portability and "test with multiple architectures/implementations" style. I do catch more bugs thanks to SBCL, CLISP, ECL, etc.
Can anyone setup a google questionnaire or some other survey?
[ François-René ÐVB Rideau | Reflection&Cybernethics | http://fare.tunes.org ] I walked a mile with Pleasure, / She chattered all the way; But left me none the wiser, / For all she had to say. // I walked a mile with Sorrow / And ne'er a word said she; But, oh, the things I learned from her / When Sorrow walked with me! — Robert Browning Hamilton
On 5 April 2010 16:05, Robert Goldman rpgoldman@sift.info wrote:
On 4/5/10 Apr 5 -9:53 AM, Tobias C. Rittweiler wrote:
Robert Goldman rpgoldman@sift.info writes:
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 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.
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.
Even if they work only with one implementation, why do you think they want their source directories be cluttered with fasls which just plays bad with RCS, grep, tar, and other tools?
With all due respect, I don't care why they want this. I just know that they do. They want ASDF to just build systems for them and get out of their way and not complicate their lives. They want the configuration of ASDF to be handed to them on a platter.
I have weaned many of these people from just using big files full of
(compile-file-if-needed ...) (load ...)
They do not want to learn ASDF any more than I want to learn autoconf just to build a piece of software, and I respect that. I don't fix my car, I just drive it.
cc by default drops .o files right in front of you. People seem to live with that just fine.
I used a symbolics for many years happily without fussing with the location of the binaries.
I think it's great that we have output-translations, and I have gradually spread their use, but I want to make the first spoonful of ASDF go down easily. This, IMO, means that if someone tells you to use ASDF, and gives you an ASDF system definition, you can load it and run. You don't have to learn the whole thing, you just do it, and it acts pretty much like a smarter replacement for COMPILE-FILE, just like make is a smarter replacement (from a user standpoint) for cc.
I also want the first spoonful of ASDF2 go down easily. This, IMO, means that it should behave as much like ASDF 1 as possible, modulo bug fixes, when it's turned on. Fiddling with the buttons and dials should give you all kinds of new goodness, but the /obligation/ to fiddle with buttons and dials should be avoided.
There are far too many FMs out there, and we cannot expect users to R them! If they want a new feature (if they want to install a shiny SBCL next to their copy of an old one, and need to keep the fasls from being confused, or if they like to have all their fasls together somewhere), great, they will read the manual. If they just want to load a system, they shouldn't have to and, in any case, we should not expect them to.