[asdf-devel] ASDF2 cache control?

[Faré]

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 at sift.info> wrote:
> On 4/5/10 Apr 5 -9:53 AM, Tobias C. Rittweiler wrote:
>> Robert Goldman <rpgoldman at 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.
>