[asdf-devel] ASDF2 cache control?

[Faré]

On 5 April 2010 14:12, Robert Goldman <rpgoldman at sift.info> wrote:
> 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 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.


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