[asdf-devel] ASDF2 cache control?

[Robert Goldman]

On 4/5/10 Apr 5 -11:58 AM, Faré wrote:
> 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.

I'd go with "ultimately simpler" and "more useful," but not "least
surprising," at least not for an ASDF Classic user!

I would feel more confident shipping with the translation on by default
if it didn't seem like it was complicated to turn it off.  If I
understand you correctly, one cannot simply turn it off, one must
somehow grok how it handles system installed s/w to understand how to
disable it correctly.  If I'm wrong, please correct me.

Based on that (possibly erroneous) premise, it sounds like turning it on
from off is an easier operation than turning it off from on, which
reinforces my desire to see it off by default.

However, if there's a very simple single function, with no arguments (no
need to understand, or even copy anything out of the DSL for A-O-T) that
gives asdf classsic behavior, that would dissolve a lot of my objections.

I see four families of users I'd like to see supported with
minimal-effort configurations:

1.  ASDF classic users who want ASDF classic + bugfixes (at least
initially);

2.  ASDF-BINARY-LOCATIONS users ditto, with no centralized binaries

3.  As 2, but with centralized binaries.

4.  People who want the latest and greatest, with sensible default
output relocations.

I would prefer that all of these be able to configure minimally, and in
CL only, so that people who are currently using their CL init files as
configurations will be on solid ground.  Note that I'm not saying that
the new configuration arrangement is bad, just that people should be
able to work their way up to it with baby steps.

Is this reasonably achievable without crippling people who want all the
good new stuff?

> 
> 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?

I'm reluctant to do this, because it seems to me that the people least
likely to answer are the ones most relevant to the survey.

Best,
r

> 
> [ 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.
>>