[asdf-devel] Cache? Translations? How to get rid of them?

[Faré]

On 14 March 2010 04:21, Juan Jose Garcia-Ripoll
<juanjose.garciaripoll at googlemail.com> wrote:
> No, interchangeability means not chance of using the library as it was used.
> Not having it means that new ways of loading code and linking it into
> executables of libraries should be found. New functions, new operations, new
> steps to configure. In other ways, it imposes and additional burden on the
> user.
>
OK. Makes a lot sense if you want to distribute software in two ways,
either as source or as binary, and want clients to not have to worry
too much which way it was. Maybe even to "binarize" software previously
expected to come as source.

> The proof that the current scheme is good is the fact that ECL already
> delivers some key libraries in this form. For instance CLX. The result is
> that anyone who wants to build a standalone executable including Common
> Lisp, CLX and its own custom code may do so using the distributed binary --
> no need for sources --. Stumpwm is one user of this, resulting in a really
> small executable, 1.5Mb, that just works.
>
OK, OK. I get the point.

> It's your design choice. I believe that distributing together, in the same
> directory, the *.ASD file and the binaries, is just fine.
>
OK. But I don't see what is your problem, then?

I mean, you can either write a new component type for libraries to be loaded
without being compiled (i.e. compile-op is a nop, load-op loads the binary),
or just define a special method that does all the loading.

If you distribute things in the same directory as the .asd file,
then asdf will have no problem locating them, it knows the truename
of the .asd file.

> No option. What you say is something like for every utility they should cook
> up a logical hostname? They would then have to store those logical pathname
> definitions in some other file and match the place where they install the
> files....
>
Well, indeed, you'd need a search facility that sets up the logical hosts.
A pain to write, but a one-time pain that can be invisible to users.

Anyway, your plan of delivering an asd with things in the same directory
should work.

> We just need a way to selectively deactivate those translations from user
> written code.
Why need translations at all? Just don't use OUTPUT-FILES in your target .asd.
When you create a target .asd, use components that refer directly to the
things to be loaded. Your class compiled-file looks great.

Or is your problem that of installing the binaries you compile and the asd
file you create into some target directory?

I would suggest a post-compilation INSTALL-OP phase, that copies the files
from wherever they were created, to wherever you want them. But indeed,
if it were an asdf operation and would declare its OUTPUT-FILES, then
they would be redirected.

So I suppose that what you were asking for all that time,
that I was failing to understand all along, was
the ability for OUTPUT-FILES
to say return a (CONS PATHNAME NIL) meaning
"I want this pathname, untranslated"
and the outer-most :AROUND method would detect that, then pass
the inner PATHNAME untranslated.

That's totally doable. Would adding a case
(cons (pathname (car path)))
to apply-output-translations satisfy you?

> Say, I somebody writes an OUTPUT-FILES she should be able to
> tell ASDF that no translations should be applied to those paths.
> This is also important for platform independent resources,
> as it has been discused in c.l.l.
>
I haven't been following c.l.l. in years. Can you give a link to
whatever discussion you think is relevant? Maybe you mean this?
http://groups.google.com/group/comp.lang.lisp/browse_thread/thread/8b35ee7543c03ff4#

> If you remove this problem somehow, I will stop bothering the mailing list
> :-) Really, if that is removed then the extension we cooked should just work
> for user code as well.
>
How do you like my proposed solution? It is somewhat ugly, but it's all
I can imagine at the time.

Alternatively, I could cook up an API to easily add a mapping to
output-translations on the fly (if not already there).

> Please do not tell me that, given that the tree has to be registered with
> ASDF anyway, then they should also add the path to the list of pathnames
> that do not get translated. That is a very weak link prone to break.
> Furthermore, in the same tree of directories one might want source and
> binary versions of ASDF packages.
>
How are you going to make sure that the correct .asd is loaded, if you
have two versions of foo.asd under the same registered tree?

> However, if you want to forget all this blah, blah, blah, it is also ok.
>
No, I want to make sure you are satisfied. I didn't need to be convinced,
I needed to understand what the issue was, and was too blockheaded for that.

> Just remember that what I said above applies: we need a way to write code in
> ASDF whose pathnames do not get arbitrarily overwritten. This facility is
> seriously needed for ASDF extensibility. Another example. Say, for instance,
> that one ASDF extension decides to code temporary files and wants them
> stored in /var/tmp so that they get regularly cleaned up by the OS. Again,
> either does it push the path in the list of exceptions, or it is fracked.
>
Yup, makes sense.

So what about marking paths as "not to be translated" by returning
(list path) instead of path?

[ François-René ÐVB Rideau | Reflection&Cybernethics | http://fare.tunes.org ]
First they ignore you. Then they laugh at you.
Then they fight you. Then you win.
	— Gandhi