- asdf-devel - mailman3.common-lisp.net

[asdf-devel] Cache? Translations? How to get rid of them?
by Juan Jose Garcia-Ripoll 15 Mar '10

15 Mar '10

I must admit that after four hours fighting with this I am right now a bit pissed off, so please forgive the tone of the message. ASDF has introduced a new caching system which alters the names of all output files. This is making me mad because I am trying to implement pre-built ASDF components for ECL and ASDF insists on changing the value of output-files and input-files, looking for those prebuilt files at the location of the cache. What I have added so far is an extension to the system class, with hardcoded locations for prebuilt files (see below), so that I can store a single file $ cat ~/lib/ecl-10.3.1/serve-event.asd (DEFSYSTEM "serve-event" :CLASS ASDF::PREBUILT-SYSTEM :LIB "SYS:serve-event" :COMPONENTS ((:COMPILED-FILE "serve-event"))) Now the problem is that when I try to use these systems ASDF insists on translating the library file pathname "SYS:serve-event" to a cached name which does not exist. I have tried adding a TRUENAME around the output of OUTPUT-FILES, so that the return value reflects the full path, but ASDF insists in changing the name. I have tried hardcoding a system location, like SBCL does, but ASDF insists on appending its own translation > (asdf::output-translations) ((#P"/Users/jjgarcia/lib/ecl-10.3.1/" #P"/Users/jjgarcia/lib/ecl-10.3.1/") (#P"/**/*.*" #P"/Users/jjgarcia/.cache/common-lisp/ecl-10.3.1-darwin-x86/**/*.*")) Is there no rational way to prevent the translation of system directories without breaking the cache system? (defclass prebuilt-system (system) ((static-library :accessor prebuilt-system-static-library :initarg :lib))) (defmethod output-files ((o lib-op) (c prebuilt-system)) (list (compile-file-pathname (prebuilt-system-static-library c) :type :lib))) (defmethod perform ((o lib-op) (c prebuilt-system)) (car (output-files o c))) (defmethod component-depends-on ((o lib-op) (c prebuilt-system)) nil) (defmethod bundle-sub-operations ((o lib-op) (c prebuilt-system)) nil) (defmethod bundle-sub-operations ((o monolithic-lib-op) (c prebuilt-system)) (error "Prebuilt system ~S shipped with ECL can not be used in a monolithic library operation." c)) (defmethod bundle-sub-operations ((o monolithic-bundle-op) (c prebuilt-system)) nil) -- Instituto de Física Fundamental, CSIC c/ Serrano, 113b, Madrid 28006 (Spain) http://juanjose.garciaripoll.googlepages.com

4 21

Re: [asdf-devel] never ending component relative pathnames
by Faré 15 Mar '10

15 Mar '10

On 14 March 2010 21:04, james anderson <james.anderson(a)setf.de> wrote: > > On 2010-03-15, at 01:36 , Faré wrote: > >> Dear James, >> >> is there a tarball I can download with enough stuff to replace those >> tests or yours? > > ? > the tests are all in the one asdf-pathname-test.lisp file. > The amazon host is down. Also, when I last glanced, it looked like you needed some subdirectory with test files. Can you send on the list a tarball with the .lisp, .sh, and any ancillary file or does your script already create the files? > if the pathname reference failed, the entry looks like > > CL-SOURCE-FILE "file" > missing: #P"/ebs/test/asdf-src/system1/module1/ > untyped-file.lisp" > configuration: (#P"ASDFTEST:system1;" > #P"ASDFTEST:system2;module4;" #P"/ebs/test/asdf-src/system1/module1/ > untyped-file") > parent pathnames: (#P"ASDFTEST:system1;" > #P"ASDFTEST:system2;module4;") > Does "missing" means that you tried that pathname in the end, and failed? i.e. in that case, you were expecting a .lisp type, when you're not providing one in an explicit pathname? We explicitly won't merge any type when a pathname object is specified, so that the user can override component-provided types. >> Also, why do you map :unspecific to nil in merge-pathnames* ? What >> issues does that solve? Isn't that against what we want? > > i changed it to pass no argument when no value is intended. > on this topic clhs/make-pathname -> 19.2.1 lets you down. > you need to attend to 19.3.2.1 [1], to which it appears lispworks > pays attention.[2] > Ouch. I had missed this section. What about I change merge-pathnames* to squash :unspecific if and only if the host is a logical host? >> Shouldn't we >> rather have split-name-type return type :unspecific more often? Maybe >> your function should compare namestrings instead of pathnames? > > the test does not explicitly "compare". it create the files, then > uses the component pathnames to try to write to them (or just probe > for directories), and then confirms that it found all the intended > files by checking their modification times. at least, that is what it > is supposed to do. > OK. --#f Nostalgia isn’t what it used to be.

2 2

[asdf-devel] never ending component relative pathnames
by james anderson 15 Mar '10

15 Mar '10

good evening; on the occasion of pushing de.setf.graphics down the wire, when i built it for ccl/sbcl i did an obligatory pull on asdf and observe that something changed in the treatment of modules' component relative pathnames. with the effect that it was no longer possible possible to build clx. the clx-0-7-4 version as (:relative) specification in module pathnames which ran afoul of the asdf changes. i applied the same tactic as i have previously found effective for source file components and was able to build. the diff [1] is posted with the graphics sources. on other semi-related matters, i can report, that i have now an s3 ami (linux-2.6.31+ubuntu++^3) with which i can boot an ec2 instance with all pieces in place to run the target lisp implementations. --- [1] : http://github.com/lisp/de.setf.graphics/blob/master/readmes/ asdf.diff

4 36

[asdf-devel] asdf-version
by Nikodemus Siivola 14 Mar '10

14 Mar '10

What's the update policy? On every commit? (Since we're using Git I think this is pointless.) On release? (If so, I would suggest appending -dev to it outside releases.) Something else? Cheers, -- Nikodemus

3 7

Re: [asdf-devel] ASDF 2 confusion
by Robert Goldman 14 Mar '10

14 Mar '10

The member of *features* that indicates new asdf is :asdf2 This is probably the source of the confusion. Probably need a section of the manual on this. If you (or anyone else) find infelicities in the manual, please post or launchpad bug with location info. I'm very pressed for time right now and need all the help I can get squishing manual bugs. Thanks! "Nikodemus Siivola" <nikodemus(a)random-state.net> wrote: >The manual talks about both ASDF-VERSION and "ASDF 1" vs "ASDF 2", but >doesn't relate the two. > >Is anything post 1.600 "ASDF 2"? Might I suggest to drop the "ASDF 2" >language from the manual in that case -- because it is just confusing. > >Cheers, > > -- Nikodemus > >_______________________________________________ >asdf-devel mailing list >asdf-devel(a)common-lisp.net >http://common-lisp.net/cgi-bin/mailman/listinfo/asdf-devel -- Sent from my Android phone with K-9 Mail. Please excuse my brevity.

2 3

[asdf-devel] ASDF manual lisp installation directions
by Robert Goldman 14 Mar '10

14 Mar '10

Going over the manual to tidy it up, I was quite surprised to read this: The default location for a user to install Common Lisp software is under `~/.local/share/common-lisp/source/'. This seems /very/ odd. Why would I want to install software in a location 'ls' is going to hide from me? For conventional programs, I stick the source in ~/src and I put my executables in ~/bin. It wouldn't even occur to me to stick them somewhere where I couldn't find them without something like 'ls -a'. Furthermore, since I work on my lisp code most of the day, it wouldn't occur to me to hide them four levels deep behind a hidden directory. Do most lisp users stick things in ~/.local ? And if so, why???? Thanks, r

4 8

[asdf-devel] Subsumed README.source-registry into the manual
by Robert Goldman 13 Mar '10

13 Mar '10

I had to do this quite quickly, so the import was a bit rough and ready. BTW, I think the two configuration chapters should be pushed UP in the manual, and the object model should be pushed DOWN below them, since the former is for advanced users, but the latter is for in-depth programmers. The current flow is pretty awkward. But I don't have time for that today. cheers, r

1 0

[asdf-devel] ASDF 2 confusion
by Nikodemus Siivola 13 Mar '10

13 Mar '10

The manual talks about both ASDF-VERSION and "ASDF 1" vs "ASDF 2", but doesn't relate the two. Is anything post 1.600 "ASDF 2"? Might I suggest to drop the "ASDF 2" language from the manual in that case -- because it is just confusing. Cheers, -- Nikodemus

1 0

[asdf-devel] Git merge practice
by Nikodemus Siivola 13 Mar '10

13 Mar '10

Please, when merging branches that will end up in the repo, merge INTO master before pushing, as opposed to merging master to feature branch. Example: commit 4158a412c3ed75c027a47996b52057e812e8b5ed Merge: 50e98da... 9b5eaf9... Author: Francois-Rene Rideau <fare(a)tunes.org> Date: Fri Mar 12 10:51:42 2010 -0500 Merge branch 'master' of http://common-lisp.net/project/asdf/asdf Conflicts: README.asdf-output-translations This is would be more informative if it had instead been Merge branch 'some-feature' of http://common-lisp.net/project/asdf/asdf </end of sermon> Cheers, -- Nikodemus

1 1

[asdf-devel] output-translations documentation
by Robert Goldman 13 Mar '10

13 Mar '10

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

2 8