asdf-devel

asdf-devel@common-lisp.net

1 participants
1378 discussions

[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

[asdf-devel] notes on the manual discussion of asdf-output-locations
by Robert Goldman 12 Mar '10

12 Mar '10

1. The manual in several places uses version 1.6 as synonymous with 1.600. But if we are to eat our own dogfood and comply with our own version-satisfies function, 1.6 ~= (1 6) while 1.600 ~= (1 600) and 600 > 6 I have fixed the references I found. 2. In a couple of places the manual suggests making files with names of the form nn-filename. We should explain what is the purpose of these integers. 3. I don't want to repeatedly have to translate stuff out of read me files. I have put all of the information from the README.asdf-output-locations file into the manual, and killed the README so that it doesn't become an attractive nuisance. I have pushed these changes. I'd encourage everyone to please have a peek at the new manual. Question: I have been assuming that everyone on the list is capable of opening this up in emacs and using texinfo mode to format this to their choice of HTML, info, and pdf. If that is not true, please let me know; it should be possible to put a formatted copy on the ASDF web page for people who are interested in screening the documentation. Best, R

2 2

[asdf-devel] revising asdf manual
by Robert Goldman 12 Mar '10

12 Mar '10

The section 8/9 merge was easy. The section 7 (where does asdf write its files?) one is going to be more difficult. It turns out that this stuff is discussed in THREE locations: 1. The "configuring ASDF chapter; 2. Section 7 3. README.asdf-output-translations. Getting those three merged sensibly is going to be a bit more work than I'd hoped. I'm inclined to start by having the configuration chapter just crossref to section 7, and merge all the stuff into section 7. Then we can figure out how to reorganize things. I think we should probably update this to restore some one-paragraph "here's how you turn it on with a minimum of fuss" introduction. Regrettably, I don't see how that's possible with the full, heavyweight new configuration procedure. Cheers, r

2 1

[asdf-devel] texinfo documentation
by Faré 11 Mar '10

11 Mar '10

>> I can't find my way through the texinfo documentation. Too much manual >> section management. Could we be using something nicer? ReST? Exscribe? >> Gary King's CL-Markdown? > > Texinfo is standard and the toolchain is available to everyone. > > CL-Markdown has a big dependency chain, and a brittle one. > > If you use emacs, it will take care of all of the manual section > management: Texinfo > Update every node, Texinfo > Node..., Texinfo > > Create menu.... Similarly, emacs will take care of building for you, to > a number of different formats. > > So far, I'm pretty much the only one editing the manual. I promise to > stop if the format changes. > I understand. If you do the section work or walk me through it on IRC, I can do the filling the blanks for specifying how ASDF computes pathnames from module names, and what is or isn't portable to use. [ François-René ÐVB Rideau | Reflection&Cybernethics | http://fare.tunes.org ] The revolution will be won, not, as the authoritarians would claim, when the last political boss is hanged with the bowels of the last state propagandist, but, as the libertarians know, when the ever-repeated attempts to lure people into subservience are systematically greeted with laughter and drowned in ridicule by free men who are well-armed both physically and intellectually.

2 2

Jump to page:

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

asdf-devel