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

[asdf-devel] [Fwd: Re: Is this a bug? or my error?]
by Louis A. Turk 30 Jun '10

30 Jun '10

-------- Forwarded Message -------- > From: Louis A. Turk <lou(a)dayspringpublisher.com> > Reply-to: lou(a)dayspringpublisher.com > To: Faré <fahree(a)gmail.com> > Subject: Re: [asdf-devel] Is this a bug? or my error? > Date: Thu, 01 Jul 2010 03:58:40 +0800 > > On Wed, 2010-06-30 at 15:11 -0400, Faré wrote: > > Yup. Also, tell us in what directories things are, and whether you > > made > > any changes to ASDF default settings. > > /home/lat/.sbcl/site/iterate-1.4.3/iterate.lisp > /home/lat/clbuild/source/iterate/iterate.lisp > > /home/lat/lisp/collate/collate.lisp > > /home/lat/lisp/il/laturk-unique.asd > /home/lat/lisp/il/laturk-unique.lisp > /home/lat/lisp/il/packages.lisp > > Thanks for looking at this problem! > > Louis >

1 0

[asdf-devel] Proposal for improved support for versions of systems
by Vsevolod Dyomkin 29 Jun '10

29 Jun '10

Hi! Approximately after the release of ASDF 2 I've got interested in creating yet another system distribution management system on top of ASDF, and that made me investigate ASDF internals. Through that investigation, I've understood 2 things: * ASDF has support for much more, than is well known and in ordinary use by most Common Lisp programmers :) * still it's support for versioning (which is essential to distribution management) is lacking due to: - possibility to specify only exact version - somewhere in the depths of code version checking is lost (for example, there's no condition signaled, if in the process of system definitions traversal we load ASD file with different version for some system, that was already loaded, which actually causes errors in some situations, i.e. its a bug) - the syntax is not very friendly So, during last month I was developing ASDF in the direction of more robust version support. I've started with 2.000, but fortunately there's no intersection between my work and recent developments up to version 2.106 (except for new DEFGENERIC*, which is trivial). Attached is the proposed patch to ASDF, that, in my view, solves the aforementioned versioning problems. It does the following: * Unifies internal version representation format in the form of a list of integers: (for example, ASDF 2.106 will have an internal version of '(2 106 0), while ASDF 2.005 — '(2 5 0)). At the same time, the users are given quite a lot of freedom in specifying versions, for example they can do that as before in string form (like "1.2.3"), so it's backwards compatible. This new format is more programming-friendly and several utility functions are added: PROPER-VERSION (to transform to it), V> (version-greater-or-equal), MAJOR-VERSION and MINOR-VERSION,— while VERSION-SATISFIES is much improved in the manner, that is explained below. Also a method for SLOT-UNBOUND is added to VERSION slot on a SYSTEM class, to return version '(0 0 0), which is considered (on par with NIL) to be a wildcard version spec, so to say. * Adds VERSION-P (version-predicate) parameter to different ASDF functions, that need to deal with versions. This specifies in which way to match versions with VERSION-SATISFIES and currently has the following variants: :EXACT (nil also translates to :EXACT), :ABOVE, :MAJOR+, :MINOR+, and also a second version spec, which means that version should be in the interval from the given version to version-p itself. This is the change, that I had had in mind, when I started looking at ASDF * Adds a continuable error of type SYSTEM-VERSION-CONFLICT, when we try to read ASD file with a different version of some system, that is already in memory * Adds new format of version specification in :DEPENDS-ON clause of DEFSYSTEM. Besided (:version <system> <version>), which is retained and extended with version-p, i.e. (:version <system> <version> <version-p>) — example: (:version :hunchentoot "1.2.3" :above) ,— there's now also a simpler (<system> <version> <version-p>) — example: (:hunchentoot "1.2.3" :above) A final note about versioning: I needed to use pre-reading of ASD files in order to know their versions without arising version conflicts. This works, except for the fact, that READ-EVAL is turned off in the process, so such version specifiers as: * :version #.*hunchentoot-version* * :version #.(with-open-file (vers (merge-pathnames "version.lisp-expr" *load-truename*)) (read vers)) do not produce expected results and are treated as empty versions. There will be a need to make a note about that to library developers. Besides, an incompatible change is introduced to FIND-SYSTEM. The ERROR-P optional argument is removed, so plain NIL is unconditionally returned, when system is not found, and VERSION and VERSION-P optional arguments are added instead. I'd like to argue, that this is justified by two things: * there's no substantial use of ERROR-P argument neither in ASDF itself, nor anywhere in dependent code (at least I can tell that after a brief look at google search results) * more importantly, although there's another option to add version/version-p: add VERSION and VERSION-P as keyword arguments and leave ERROR-P also as keyword argument — I don't think, that overall the use of such argument is a proper architectural decision, because it's not an error actually, when system is not found — it's a common situation and should be dealt with in the caller appropriately to the context My last note concerning this patch is about testing. After syncing with the development branch of ASDF, I see the addition of TEST directory. When I'd started my experiments, I had somehow missed it (or it had not been there?). Anyway, I have supplied a number of unit tests to the functions, that I have added. This is done with a very simple unit testing library of my own (a microframework so to say) MUTEST, that can be found at: http://github.com/vseloved/mutest/. The tests are specified right in the code side-by-side with functions definitions, but are protected with #+mutest guards, so effectively can be ignored. They also have the benefit of showing, how each of the functions can be called. There's also a dummy directory structure under TEST, that is used in the tests and should be reproduced in the same directory, where ASDF-VERSION.LISP is located. I have also done functional testing of the changes with the systems, that I have got installed already (around 70 libraries), and have verified, that there are no problems. At the same time I would not claim, that there will not be any problems with some system definitions, that use obscure ASDF features (although, I have acquainted myself with ASDF to the point, that I quite well understand most of the features as well as internals now). So I ask anyone interested in this set of changes to thoroughly test them. At the same time I'd be glad to know more about utilizing the current ASDF test-suite. Finally, the patch can be applied by simply loading ASDF-VERSION.LISP on top of the loaded ASDF 2.106. I hope, this work proves useful and is integrated into ASDF. Anyway I'm willing to answer any questions and/or improve the implementation, if needed. Vsevolod Dyomkin

3 13

[asdf-devel] ASDF 2.003
by Faré 25 Jun '10

25 Jun '10

Can ABCL upgrade its ASDF to 2.003 or whichever is latest in the release branch (if possible NOT the master branch)? That would be great. It should fix several bugs that may have hit ABCL users since then. Xach at least reported that upgrading ASDF on ABCL made his software work. As usual, please test on your specific implementation with a few systems before you commit, and please report any bug. [ François-René ÐVB Rideau | Reflection&Cybernethics | http://fare.tunes.org ] One good Husband is worth two good Wives; for the scarcer things are, the more they're valued. — Benjamin Franklin

2 1

[asdf-devel] 2.003 = 2.105
by Faré 24 Jun '10

24 Jun '10

I just committed 2.105, then blessed it as the new RELEASE 2.003 on the release branch. Nobody complained about the concept of COMPILE-FILE* so I decided it would be OK to include it in the 2.0 branch. [ François-René ÐVB Rideau | Reflection&Cybernethics | http://fare.tunes.org ] Not only is there no contradiction between egoism and altruism, but no altruism is possible without egoism - for what betterment to wish to an other person devoid of selfish desire, to whom any change is indifferent?

1 0

[asdf-devel] documentation patch
by Robert Goldman 24 Jun '10

24 Jun '10

After all the discussion about Stas's bug, I thought it would be handy to provide docstrings to the two configuration variables in question. Just pushed that patch. We might consider expanding on the material in the manual, as well; I am not sure a real novice would understand the implications. If you like, I will do that. cheers, r

1 0

Re: [asdf-devel] [Sbcl-devel] ASDF in SBCL
by Faré 24 Jun '10

24 Jun '10

On 24 June 2010 09:41, Attila Lendvai <attila.lendvai(a)gmail.com> wrote: > is this a bug, or am i doing something wrong? > > if a bug, shall i record it as ASDF bug or SBCL bug? > > > alendvai@ed101:/usr/share/common-lisp/source$ rlwrap > ~/workspace/sbcl/run-sbcl.sh --no-userinit > (running SBCL from: /home/alendvai/workspace/sbcl) > This is SBCL 1.0.39.21, an implementation of ANSI Common Lisp. > More information about SBCL is available at <http://www.sbcl.org/>. > > SBCL is free software, provided as is, with absolutely no warranty. > It is mostly in the public domain; some portions are provided under > BSD-style licenses. See the CREDITS and COPYING files in the > distribution for more information. > * (require :asdf) > > ("ASDF") > * (asdf:load-system :asdf) > > ; registering #<SYSTEM :ASDF> as ASDF > INFO: Control stack guard page unprotected > Control stack guard page temporarily disabled: proceed with caution > > fatal error encountered in SBCL pid 17617(tid 140737353979648): > Control stack exhausted > > Welcome to LDB, a low-level debugger for the Lisp runtime environment. > ldb> > > > > > > the backtrace while the rather slow endless recursion is running: > > > 988: (SB-INT:SIMPLE-EVAL-IN-LEXENV > (ASDF:DEFSYSTEM :ASDF > :PATHNAME > NIL > :DEPENDS-ON > NIL > :COMPONENTS > NIL) > #<NULL-LEXENV>) > 989: ((LAMBDA (#:G[SYSTEM-DEFINITION-PATHNAME]1191)) ASDF::SYSDEF-FIND-ASDF) > 990: (SB-IMPL::%MAP-FOR-EFFECT-ARITY-1 > #<CLOSURE (LAMBDA #) {10031662F9}> > (ASDF::SYSDEF-CENTRAL-REGISTRY-SEARCH ASDF::SYSDEF-SOURCE-REGISTRY-SEARCH > ASDF::SYSDEF-FIND-ASDF)) > 991: (ASDF:SYSTEM-DEFINITION-PATHNAME "asdf") > 992: (ASDF:FIND-SYSTEM "asdf" NIL) > 993: (ASDF:FIND-COMPONENT "asdf" NIL) > 994: (ASDF::PARSE-COMPONENT-FORM > NIL > (:MODULE "asdf" :PATHNAME #P"/usr/share/common-lisp/source/" :PATHNAME > NIL :DEPENDS-ON NIL :COMPONENTS NIL)) > 995: (SB-INT:SIMPLE-EVAL-IN-LEXENV > (ASDF::PARSE-COMPONENT-FORM NIL > (LIST* :MODULE > (ASDF-UTILITIES:COERCE-NAME ':ASDF) > :PATHNAME > #P"/usr/share/common-lisp/source/" > '(:PATHNAME NIL :DEPENDS-ON NIL > :COMPONENTS NIL))) > #<NULL-LEXENV>) > 996: (SB-INT:SIMPLE-EVAL-IN-LEXENV > (ASDF:DEFSYSTEM :ASDF > :PATHNAME > NIL > :DEPENDS-ON > NIL > :COMPONENTS > NIL) > #<NULL-LEXENV>) > > -- > attila > Oops, this is an embarrassing bug in ASDF 2.002 and 2.102. I fixed it in 2.103, that also fixes two other bugs. I wonder whether I should merge 2.103 wholesale as 2.003 in the release branch. Probably. The only controversial feature would be the compile-file* change. If I don't hear any objection to including it in 2.003, I will include it. Otherwise, I'll try to include everything from 2.103 but the compile-file* change. [ François-René ÐVB Rideau | Reflection&Cybernethics | http://fare.tunes.org ] "How many libertarians does it take to change a lightbulb?" A- "None, the market will take care of it." B- "Every one of them and non-libs too, because we all *are* the market." C- "*I*'ll do it, for a dollar."

1 0

[asdf-devel] ASDF from git and lispworks Personal Edition on windows 7/Vista
by Alessandro Piras 19 Jun '10

19 Jun '10

Hi, The latest ASDF doesn't work well on Windows Vista/7 and Lispworks. LispWorks regards pathnames such as #P"C:/a-dir//anotherdir" as illegal because of the double slashes in it. I could fix it but it's a really ugly kludge not worth sharing. Anyway, I could understand where the problem lies: asdf is creating pathnames where (pathname-directory some-path) contains empty strings. This happens for output fasl files, that ASDF is placing in %APPDATA%\common-lisp\<implementation-name>\C\\path\to\source\file - note the double \\ after the drive letter. Hope this helps, __ Alessandro

2 3

[asdf-devel] GIT branching [was Re: [Bug 587889] Re: bad fasls can poison future build]
by Robert Goldman 17 Jun '10

17 Jun '10

On 6/16/10 Jun 16 -11:13 AM, Faré wrote: .... > > Robert: any thoughts re: branching? > I am so far from being a git expert, that I will not venture any suggestions. A while ago I read the following article which proposes a branching policy for use with git. It seemed, to my limited understanding, reasonable. Perhaps we could adopt some variant of this policy? http://www.newartisans.com/2009/10/branch-policies-with-git.html He seems to have many more branches than I would have thought necessary. I don't know that we need a "released," "stable devel," and "bleeding edge" as he does. Perhaps some sort of variant where we have a maint branch --- 2.0 with patches for bug fixes devel branch --- moving towards 2.1 ? I'm inclined to think that we could further minimize/simplify by having the devel branch be master. We could also have topic branches, like the one I built in order to do the first TRAVERSE mods for module dependencies. Does that sound reasonable? Feel free to say "no," since I'm making this up as I go along based on half-remembered blog posts. best, r

2 2

[asdf-devel] a hair in :pathname specifications
by Faré 12 Jun '10

12 Jun '10

Looking at Stelian's recent patches to iolib, I saw that he uses things like: (asdf:defsystem :iolib.syscalls ... :pathname #-asdf2 (merge-pathnames "syscalls/" *load-truename*) #+asdf2 "syscalls/" ...) This shocked me, as I new (for having been hit badly by the issue at ITA and having read the code) that you can't use (merge-pathnames ...) like that in a component and need #. instead, since there is no EVAL in parse-component-form. ITA used to have lots of #.(merge-pathnames ...) before I implemented / parsing in our local ASDF (now merged into ASDF 2). Well, it turns out that the defsystem macro itself treats :pathname specially and lets that argument be evaluated unlike other arguments and unlike :pathname for other forms. This interacts badly with some code I've written recently that cleans up the way we normalize specified pathnames for components, my code assuming we were always provided a valid specifier. So the question is: what to do? 1- Should I do nothing, thus having more uniform semantics but breaking compatibility with ASDF 1 and requiring users of defsystem to use #. in such occasions? 2- Should I issue an ASDF 2.0 minor release that re-allows pathname evaluation just for defsystem forms (excluding other forms), thus providing better backwards compatibility? 3- Should I issue an ASDF 2.0 minor release that does pathname evaluation inside parse-component-form, thus providing better backwards compatibility AND extending the semantics so that it be more uniform? [ François-René ÐVB Rideau | Reflection&Cybernethics | http://fare.tunes.org ] A common man marvels at uncommon things; a wise man marvels at the commonplace. — Confucius

3 3

[asdf-devel] (no subject)
by Stelian Ionescu 12 Jun '10

12 Jun '10

The first patch fixes the parsing of the configuration file that I use: (:source-registry :default-registry (:directory "/usr/share/common-lisp/systems") (:directory "/home/hechee/lisp/systems")) Currently I get "One and only one of :INHERIT-CONFIGURATION or :IGNORE-INHERITED-CONFIGURATION is required", even though none is present.

2 8