I have not been using the output-translations (because my colleagues are still using "classic" asdf), and so I'm not familiar with the configurations. I have gone over the readme, but I was left with (at least) a few questions:
1. There's no description of what happens if you have left the environment variable unset and you don't have any of the magical files. What would happen if you were to do
(asdf:initialize-output-translations)
? What would you get?
[The README says "Indeed, few people use and customize these packages; these people are experts who can trivially adapt to the new configuration." but I don't think that this division of the world into "ASDF by itself" and "Wizards" is accurate. All my colleagues, and several people we have worked with are people who DO use but DO NOT customize ASDF-BINARY-LOCATIONS. That is, they are not Wizards, but they do use A-B-L. So I'm very much interested in what happens to such people.]
2. Related to the above, can you provide a recipe for getting the same behavior as ASDF-BINARY-LOCATIONS? A-B-L was quite easy to use --- if you just turned it on, it would split your fasls by implementation type. Is there a simple set of commands --- that can be put entirely into one's lisp init file --- that would replicate this behavior?
3. In the readme I see:
(ensure-output-translations) checks whether output translations have been initialized. If not, initialize them. This function will be called before any attempt to operate on a system. If your application wants to override the provided defaults, it will have to use the below function process-output-translations.
but there is no mention of process-output-translations anywhere else in the file.
What I'd like to do:
In general, I'd like to beef up the discussion of "all lisp" configurations of output-translations.
I ask because although a long-term unix user, I'm not a big fan of the way linux has led to a multiplication of configuration files in different locations. I like to have all my lisp configuration either in my init file (clinit.cl or .sbclrc) or in a file explicitly loaded therefrom. I have a lot of trouble managing the complexity of interacting configuration files, so I simply avoid them. This stands me in good stead with my colleagues --- we stick a file in a project repository, near the root, that configures everything (including the ASDF *central-registry*), using local information (including *load-truename*) and we are happier with that than having to wrangle scattered configurations.
Indeed, I typically have a set of functions, one for each project, that will configure my lisp appropriately. I will usually start a lisp session then, before anything else, execute one of these functions, which will populate ASDF:*central-registry* and set any necessary contextual variables, etc.
The ability to do this is particularly important for my firm because we are a contract research house (a "soft money lab"), and so are often concurrently working on several large systems. We must be able to switch contexts (including sometimes multiple, inconsistent versions of a single library), and having multiple different configuration files scattered around makes project context switches very difficult.
For similar reasons, to the maximum extent possible, I try not to configure with environment variables, because it's difficult to control their flow. E.g., it's difficult to switch from project to project while in a long-running emacs session if unseen environment variables affect the system. Similarly, I find it hard to predict what will happen if I change them in one terminal window --- did that get propagated to that emacs process or not?
So I'd like to make sure I capture into the manual --- not to the exclusion of all else, of course! --- a set of instructions that will be useful for people like me, who will want to configure everything in their lisp and only the absolute minimum externally.
cheers, r
On 12 March 2010 00:05, Robert Goldman rpgoldman@sift.info wrote:
I have not been using the output-translations (because my colleagues are still using "classic" asdf), and so I'm not familiar with the configurations. I have gone over the readme, but I was left with (at least) a few questions:
- There's no description of what happens if you have left the
environment variable unset and you don't have any of the magical files. What would happen if you were to do
(asdf:initialize-output-translations)
? What would you get?
I think I hadn't made my mind up when I originally wrote that document. But in my update to the asdf manual, I did specify the current behaviour: all output will be redirected to the user cache in *user-cache*, i.e. '(:home ".cache" "common-lisp" :implementation) i.e. ~/.cache/common-lisp/sbcl-1.0.35.10-linux-x86-64/
[The README says "Indeed, few people use and customize these packages; these people are experts who can trivially adapt to the new configuration." but I don't think that this division of the world into "ASDF by itself" and "Wizards" is accurate. All my colleagues, and several people we have worked with are people who DO use but DO NOT customize ASDF-BINARY-LOCATIONS. That is, they are not Wizards, but they do use A-B-L. So I'm very much interested in what happens to such people.]
Most people will let the default, i.e. this user-cache, or (when using common-lisp-controller) the system cache in '(:root "var" "cache" "common-lisp-controller" :uid :implementation-type) i.e. /var/cache/common-lisp-controller/1000/sbcl/
People who for whatever reason want to disable the cache on a directory can add an entry ("/dont/use/aot/on/this/path/") in their ~/.config/common-lisp/asdf-output-translations.conf.d/10-disable-some-path.conf or disable AOT completely with (:root) in ~/.config/common-lisp/asdf-output-translations.conf.d/00-disable-aot.conf
- Related to the above, can you provide a recipe for getting the same
behavior as ASDF-BINARY-LOCATIONS? A-B-L was quite easy to use --- if you just turned it on, it would split your fasls by implementation type. Is there a simple set of commands --- that can be put entirely into one's lisp init file --- that would replicate this behavior?
AOT is turned on by defaults. To turn it off completely, use (:root) in ~/.config/common-lisp/asdf-output-translations.conf.d/00-disable-aot.conf What other former ABL behaviour do you want me to give examples for?
In a Lisp init file, that would be: (asdf:initialize-output-transations '(:asdf-output-translations (:root) (:ignore-inherited-configuration))) or on Unix, simply: (asdf:initialize-output-transations "/")
- In the readme I see:
(ensure-output-translations) checks whether output translations have been initialized. If not, initialize them. This function will be called before any attempt to operate on a system. If your application wants to override the provided defaults, it will have to use the below function process-output-translations.
but there is no mention of process-output-translations anywhere else in the file.
Oops, some bitrot happened along a refactoring. Fixed.
What I'd like to do:
In general, I'd like to beef up the discussion of "all lisp" configurations of output-translations.
Makes sense.
I ask because although a long-term unix user, I'm not a big fan of the way linux has led to a multiplication of configuration files in different locations. I like to have all my lisp configuration either in my init file (clinit.cl or .sbclrc) or in a file explicitly loaded therefrom. I have a lot of trouble managing the complexity of interacting configuration files, so I simply avoid them. This stands me in good stead with my colleagues --- we stick a file in a project repository, near the root, that configures everything (including the ASDF *central-registry*), using local information (including *load-truename*) and we are happier with that than having to wrangle scattered configurations.
That is sensible. Whatever floats your boat. AtITA, the Makefile for the project I build overrides any user configuration with its own, using suitable environment variables. I could have done it from Lisp instead.
Indeed, I typically have a set of functions, one for each project, that will configure my lisp appropriately. I will usually start a lisp session then, before anything else, execute one of these functions, which will populate ASDF:*central-registry* and set any necessary contextual variables, etc.
The ability to do this is particularly important for my firm because we are a contract research house (a "soft money lab"), and so are often concurrently working on several large systems. We must be able to switch contexts (including sometimes multiple, inconsistent versions of a single library), and having multiple different configuration files scattered around makes project context switches very difficult.
Completely agreed. Once again, these things are actively supported by the current code, and I'm eager to fix any bug. The main problem here is the lack of documentation and examples.
For similar reasons, to the maximum extent possible, I try not to configure with environment variables, because it's difficult to control their flow. E.g., it's difficult to switch from project to project while in a long-running emacs session if unseen environment variables affect the system. Similarly, I find it hard to predict what will happen if I change them in one terminal window --- did that get propagated to that emacs process or not?
I set the environment variables at compile-time from the Makefile through a configuration script, and at run-time from a wrapper script that does the Right Thing (including invoking Lisp for SLIME). So that's 100% controlled. YMMV obviously.
So I'd like to make sure I capture into the manual --- not to the exclusion of all else, of course! --- a set of instructions that will be useful for people like me, who will want to configure everything in their lisp and only the absolute minimum externally.
Totally agreed. Needs to be written totally, though.
[ François-René ÐVB Rideau | Reflection&Cybernethics | http://fare.tunes.org ] A pretty face is not a passport; it's a visa and it runs out fast.
On 3/11/10 Mar 11 -11:55 PM, Faré wrote:
On 12 March 2010 00:05, Robert Goldman rpgoldman@sift.info wrote:
What other former ABL behaviour do you want me to give examples for?
A behavior that, like ABL, creates a subdirectory for each different lisp implementation.
Would that be
(asdf:initialize-output-translations '(:asdf-output-translations (:root) (:current-directory :implementation-type))
?
thanks, r
On 12 March 2010 08:46, Robert Goldman rpgoldman@sift.info wrote:
On 3/11/10 Mar 11 -11:55 PM, Faré wrote:
On 12 March 2010 00:05, Robert Goldman rpgoldman@sift.info wrote:
What other former ABL behaviour do you want me to give examples for?
A behavior that, like ABL, creates a subdirectory for each different lisp implementation.
Would that be
(asdf:initialize-output-translations '(:asdf-output-translations (:root) (:current-directory :implementation-type))
?
More like
(asdf:initialize-output-translations `(:asdf-output-translations (:root (,(truename *default-pathname-defaults*) :implementation-type))))
or if you want to only redirect output for what's in the current self-contained directory, and want it to be inside a predictable subdirectory thereof, you can use:
(let ((cwd (truename *default-pathname-defaults*))) (asdf:initialize-output-translations `(:asdf-output-translations (,cwd (,cwd "asdf-output" :implementation-type)))))
[ François-René ÐVB Rideau | Reflection&Cybernethics | http://fare.tunes.org ] Demand Truly Free Health Care: where doctors need neither pay, food, sleep nor training, and hospitals grow on trees!
On 3/12/10 Mar 12 -9:46 AM, Faré wrote:
On 12 March 2010 08:46, Robert Goldman rpgoldman@sift.info wrote:
On 3/11/10 Mar 11 -11:55 PM, Faré wrote:
On 12 March 2010 00:05, Robert Goldman rpgoldman@sift.info wrote:
What other former ABL behaviour do you want me to give examples for?
A behavior that, like ABL, creates a subdirectory for each different lisp implementation.
Would that be
(asdf:initialize-output-translations '(:asdf-output-translations (:root) (:current-directory :implementation-type))
?
More like
(asdf:initialize-output-translations `(:asdf-output-translations (:root (,(truename *default-pathname-defaults*) :implementation-type))))
What happens to this as the value of *default-pathname-defaults* changes over time?
I guess I don't understand the role of the (truename *default-pathname-defaults*) here.
Does this mean that A-O-T by default always does the equivalent of *centralize-binaries* in A-B-L?
or if you want to only redirect output for what's in the current self-contained directory, and want it to be inside a predictable subdirectory thereof, you can use:
(let ((cwd (truename *default-pathname-defaults*))) (asdf:initialize-output-translations `(:asdf-output-translations (,cwd (,cwd "asdf-output" :implementation-type)))))
Question: for people who have been using ASDF-BINARY-LOCATIONS for a while without a deep understanding (e.g., colleagues of mine who just did what I told them to), would it be possible to provide
(ASDF:ABL-COMPATIBILITY-MODE)
as an alias for the former?
That would allow an easy
#+ASDF2 (ASDF:ABL-COMPATIBILITY-MODE) #-ASDF2 (ASDF:OOS 'ASDF:LOAD-OP :ASDF-BINARY-LOCATIONS)
in lisp init files.
(asdf:initialize-output-translations `(:asdf-output-translations (:root (,(truename *default-pathname-defaults*) :implementation-type))))
What happens to this as the value of *default-pathname-defaults* changes over time?
Well, Lisp is call-by-value, so this clearly takes the current directory at the time this initialization takes place. I think it is crazy to try to offer a :current-directory directive the semantics of which you'd have to specify.
I guess I don't understand the role of the (truename *default-pathname-defaults*) here.
It locates the cwd at the time of execution of this form. On some implementations, indeed (like CMUCL), *default-pathname-defaults* is #p"" by default, and you better resolve that, or have surprises.
Does this mean that A-O-T by default always does the equivalent of *centralize-binaries* in A-B-L?
Yes. That is the default configuration indeed. It should be documented prominently.
If you think it's wrong, it's still time to revert this default before ASDF 2 is released.
Question: for people who have been using ASDF-BINARY-LOCATIONS for a while without a deep understanding (e.g., colleagues of mine who just did what I told them to), would it be possible to provide
(ASDF:ABL-COMPATIBILITY-MODE)
as an alias for the former?
That would allow an easy
#+ASDF2 (ASDF:ABL-COMPATIBILITY-MODE) #-ASDF2 (ASDF:OOS 'ASDF:LOAD-OP :ASDF-BINARY-LOCATIONS)
in lisp init files.
That's a great idea. function ASDF:ASDF-BINARY-LOCATION-COMPATIBILITY-MODE would take keyword arguments :centralize-binaries, etc., with proper defaults.
We probably also want a simple function to disable A-O-T.
[ François-René ÐVB Rideau | Reflection&Cybernethics | http://fare.tunes.org ] Those who hammer their guns into plows will plow for those who do not. — Thomas Jefferson
On 3/12/10 Mar 12 -10:43 AM, Faré wrote:
(asdf:initialize-output-translations `(:asdf-output-translations (:root (,(truename *default-pathname-defaults*) :implementation-type))))
What happens to this as the value of *default-pathname-defaults* changes over time?
Well, Lisp is call-by-value, so this clearly takes the current directory at the time this initialization takes place. I think it is crazy to try to offer a :current-directory directive the semantics of which you'd have to specify.
I guess I don't understand the role of the (truename *default-pathname-defaults*) here.
It locates the cwd at the time of execution of this form. On some implementations, indeed (like CMUCL), *default-pathname-defaults* is #p"" by default, and you better resolve that, or have surprises.
OK, this isn't going to do what A-B-L did then, because A-B-L was pervasive, and this will only work on the current value of *default-pathname-defaults*.
So my original, without this, didn't work?
What's the way to make ALL the systems so that a file foo.lisp gets its fasl into <foo.lisp directory>/<implementation>/foo.fasl ?
Does this mean that A-O-T by default always does the equivalent of *centralize-binaries* in A-B-L?
Yes. That is the default configuration indeed. It should be documented prominently.
If you think it's wrong, it's still time to revert this default before ASDF 2 is released.
I don't think that this is what anyone expects; I would think that making centralization not be the default would be more appropriate, but if the community feels differently, that's fine, too.
Question: for people who have been using ASDF-BINARY-LOCATIONS for a while without a deep understanding (e.g., colleagues of mine who just did what I told them to), would it be possible to provide
(ASDF:ABL-COMPATIBILITY-MODE)
as an alias for the former?
That would allow an easy
#+ASDF2 (ASDF:ABL-COMPATIBILITY-MODE) #-ASDF2 (ASDF:OOS 'ASDF:LOAD-OP :ASDF-BINARY-LOCATIONS)
in lisp init files.
That's a great idea. function ASDF:ASDF-BINARY-LOCATION-COMPATIBILITY-MODE would take keyword arguments :centralize-binaries, etc., with proper defaults.
We probably also want a simple function to disable A-O-T.
OK, thanks. I'll work on this. But note that I still don't know how to replicate A-B-L with *centralize-binaries* NIL.
On 12 March 2010 11:53, Robert Goldman rpgoldman@sift.info wrote:
What's the way to make ALL the systems so that a file foo.lisp gets its fasl into <foo.lisp directory>/<implementation>/foo.fasl ?
This isn't possible with the current A-O-T, since A-O-T tries to resolve the mappings statically. I could modify A-O-T to make it possible to do what you say.
It strikes me as a bad idea, but if there's popular demand, I don't see why not let people have what they want, as long as it's not the default.
Does this mean that A-O-T by default always does the equivalent of *centralize-binaries* in A-B-L?
Yes. That is the default configuration indeed. It should be documented prominently.
If you think it's wrong, it's still time to revert this default before ASDF 2 is released.
I don't think that this is what anyone expects; I would think that making centralization not be the default would be more appropriate, but if the community feels differently, that's fine, too.
CLC and CL-Launch use centralization, and no one seems to complain (maybe because no one use CL-Launch; but CLC seems to be somewhat used). Centralization is just *required* when source comes in shared locations where users don't have write access. So it's a better universal default.
I'd rather have no translation by default than this decentralized mess. At least, it would make it clear that you need to configure things. But Centralized FASLs strike me as something that will work everywhere.
That's a great idea. function ASDF:ASDF-BINARY-LOCATION-COMPATIBILITY-MODE would take keyword arguments :centralize-binaries, etc., with proper defaults.
We probably also want a simple function to disable A-O-T.
OK, thanks. I'll work on this. But note that I still don't know how to replicate A-B-L with *centralize-binaries* NIL.
I'll make that happen next week.
[ François-René ÐVB Rideau | Reflection&Cybernethics | http://fare.tunes.org ] Free Market is not the end of every large-scale economical problem; but it's the beginning to any long-term solution to anyone of them.
Free Software is not the end of every large-scale software problem; but it's the beginning to any long-term solution to anyone of them.
Freedom is not the end of every large-scale problem; but it's the beginning to any long-term solution to anyone of them. — Faré
OK, thanks. I'll work on this. But note that I still don't know how to replicate A-B-L with *centralize-binaries* NIL.
I'll make that happen next week.
Actually, I think that (at least on Unix) this mapping may work:
(#p"/**/*.*" (#p"/**/" :implementation #p"*.*"))
Yay for translate-pathnames: I don't have to change anything to asdf.lisp!
[ François-René ÐVB Rideau | Reflection&Cybernethics | http://fare.tunes.org ] A cuddle a day keeps the shrink away