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 <rpgold...@sift.info> wrote: > On 4/5/10 Apr 5 -9:53 AM, Tobias C. Rittweiler wrote: >> Robert Goldman <rpgold...@sift.info> >> writes: >> >>> On 4/4/10 Apr 4 -9:50 PM, Faré wrote: >>>>> I would in order prefer the following: >>>>> >>>>> 1. 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. > _______________________________________________ asdf-devel mailing list asdf-devel@common-lisp.net http://common-lisp.net/cgi-bin/mailman/listinfo/asdf-devel
