asdf-devel

asdf-devel@common-lisp.net

1 participants
1378 discussions

Max version constraints
by Faré 27 Jan '23

27 Jan '23

Dear Robert & asdf-develers, I was discussing max version constraints and the havoc they wroke on Haskell land, yet the legitimate use they have in toplevel projects integrating many libraries, and figured that maybe the solution could be a difference in treatment between max version constraints found in a toplevel asd file (the one you directly call operate on) vs ones found in subsequently loaded .asd files: a broken constraint at the toplevel would cause an error, whereas a constraint broken outside the toplevel would only issue a warning—a warning that would suggest either removing the constraint (because its value outside the toplevel is dubious or advisory only) or updating it (since the toplevel works without it), or adding it to the toplevel too (because the toplevel doesn't actually work without it). The warning can be hushed the usual way if desired, and both the warning and error would inherit from a common condition. Technically, to implement this, the main methods of load-asd and operate would bind a special variable to the path of the .asd file (or its truename* ?) if the binding is currently NIL, and the constraint checker would behave differently depending on whether the component-path of the current system matches it or not. (This is a rough idea that has not been tested.) Would this solution work for you? It seems to me that it should make everyone happy. —♯ƒ • François-René ÐVB Rideau •Reflection&Cybernethics• http://fare.tunes.org “All problems in computer science can be solved by another level of indirection.” — David Wheeler

1 0

Re: ADG: handling functions defined after a reference
by Faré 31 Dec '22

31 Dec '22

IIRC, at ITA we loaded all the source code of QPX as source code in a first pass before we compiled it, to get all the functions resolved (happily, there weren't any macro-defining macros requiring more than one level of such loading), due to the code having been defined without such a clean build in mind. I don't remember for sure, but I suspect we did that also when we used ADG on that code-base to detect the dependencies. Maybe we even ran ADG twice? In the end, we also generated fine-grained dependency reports so we could later split the files in multiple parts that had a proper dependency order, and even automatically did the file-splitting based on dependencies with toplevel-form granularity. (The output from this project was dropped for political reasons, though, sigh). Sorry, my memories are growing dim, and I don't have access to this codebase anymore. I might know people who have access and might be able to dig it out (or then again might not—the code might have been archived with the old revision control system when ITA was absorbed by Google, and no one is going to get paid to fight bureaucracy to get to ancient code; and it probably was in a branch which will make archaeology harder). —♯ƒ • François-René ÐVB Rideau •Reflection&Cybernethics• http://fare.tunes.org “In reviewing the history of the English Government, its wars and its taxes, a bystander, not blinded by prejudice nor warped by interest, would declare that taxes were not raised to carry on wars, but that wars were raised to carry on taxes.” — Thomas Paine, “Rights of Man” On Sat, Dec 31, 2022 at 12:43 AM Robert Dodier <robert.dodier(a)gmail.com> wrote: > > Hi, thanks for your help so far. > > I have noticed that asdf-dependency-grovel doesn't handle functions > which are defined after a reference. E.g. suppose a file says (defun f > () (g)) and G hasn't been defined yet. Then a file that's loaded > afterwards says (defun g ()). If the loading order of the files were > reversed, ADG would detect the dependency, but as it stands, ADG sees > that there is a new symbol G but doesn't output a dependency for that. > > It seems like the problem might be originating from dependencies being > detected at the time that the reference is detected. It seems like if > the definitions and references were all generated, and then all of the > references matched with definitions after everything is loaded, then > ADG would detect out-of-order references. Just guessing there. > > Do you see an easy way to get ADG to detect out-of-order dependencies? > The reason I ask is that the practical example I am interested in > (Maxima) has a lot of those. > > Thanks for any insights, > > Robert

1 0

asdf-dependency-grovel tests mostly passing now
by Robert Dodier 20 Dec '22

20 Dec '22

I've made still more progress on getting asdf-dependency-grovel running. At this point most of the unit tests are successful; there are only a couple of failed tests, both having to do with DEFTYPE. Here's what I'm getting now. I am working on an ancient Ubuntu (14.04) system. In the interest of clarity I've suppressed the SBCL banner. $ sbcl --no-userinit --script tests/run-tests.lisp This is SBCL 2.1.6, an implementation of ANSI Common Lisp. [...] WARNING: :SB-EVAL is no longer present in *FEATURES* ;;; TESTS failed: ;; u-deftype.satisfies should have: ("p-deftype"), has NIL ;; u-deftype.bar should have: ("p-deftype"), has NIL The warning about :SB-EVAL is coming from loading ASDF. The failed test cases are, respectively, (in-package :asdf-dependency-grovel-test) (deftype uses-satisfies () `(satisfies satisfies-something)) and (in-package :asdf-dependency-grovel-test) (deftype uses-bar () `(or (not bar) (and bar rational))) while the corresponding provider is (in-package :asdf-dependency-grovel-test) (deftype foo () 'string) (deftype bar () 'integer) (defun satisfies-something (#1=#:a) (declare (ignore #1#)) t) I wonder why the appropriate dependency wasn't detected, but I'm not too worried about it. ADG is still useful even if it misses these. Here is the content of tests/run-tests.lisp, which I concocted after tinkering a bit. (load "/home/robert/by-others/asdf-3.1.5/build/asdf.lisp") (push "/home/robert/by-others/asdf-dependency-grovel-master/" asdf:*central-registry*) (push "/home/robert/by-others/asdf-dependency-grovel-master/tests/" asdf:*central-registry*) (load "tests/grovel-tests.lisp") (load "handlers/00-standard-handlers.lisp") (asdf-dependency-grovel-tester:test-result) There are various questionable aspects of that, which I'll point out, although they don't really bother me too much -- I'm not responsible for ADG. (1) I was able to get ADG working only with this particular combination of SBCL (2.1.6) and ASDF (3.1.5). There might be other workable combinations, however, some or all later versions of ASDF trigger errors in ADG. (2) Use of ASDF:*CENTRAL-REGISTRY* is terrible. Okay, well, it works. (3) It appears the handlers file is supposed to be loaded by ASDF, which, I guess, is supposed to scan the handlers directory, but something in that process didn't work, so it's loaded by hand. ADG constructs a new .asd file from the inferred dependencies (and writes it into the ASDF output cache -- maybe that could be mentioned in a readme or something) and I present it here as a kind of trophy. All the best, Robert Dodier PS. groveled-components.lisp: ;;; This file contains -*- lisp -*- expressions. ;;; AUTO-GENERATED file from system definition of system (test-serial-system). Instead of directly editing this file, please edit the system definition and re-generate this file. ( ("test-serial-system" :components ( (:file "package" :encoding :utf-8) (:file "p-defmacro" :depends-on ("package") :encoding :utf-8) (:file "p-define-method-combination" :depends-on ("package") :encoding :utf-8) (:file "p-feature" :depends-on ("package") :encoding :utf-8) (:file "p-defvar" :depends-on ("package") :encoding :utf-8) (:file "p-define-setf-expander" :depends-on ("package") :encoding :utf-8) (:file "p-defsetf" :depends-on ("package") :encoding :utf-8) (:file "p-defclass" :depends-on ("package") :encoding :utf-8) (:file "p-defstruct" :depends-on ("package") :encoding :utf-8) (:file "p-defgeneric" :depends-on ("package") :encoding :utf-8) (:file "p-defmethod" :depends-on ("package") :encoding :utf-8) (:file "p-define-condition" :depends-on ("package") :encoding :utf-8) (:file "p-defpackage" :depends-on ("package") :encoding :utf-8) (:file "p-defun" :depends-on ("package") :encoding :utf-8) (:file "p-define-symbol-macro" :depends-on ("package") :encoding :utf-8) (:file "p-defconstant" :depends-on ("package") :encoding :utf-8) (:file "p-deftype" :depends-on ("package") :encoding :utf-8) (:file "u-defmacro" :depends-on ("p-defmacro" "package") :encoding :utf-8) (:file "u-defmacro.indirect" :depends-on ("p-defmacro" "package") :encoding :utf-8) (:file "u-define-method-combination" :depends-on ("p-define-method-combination" "package") :encoding :utf-8) (:file "u-feature" :depends-on ("p-feature" "package") :encoding :utf-8) (:file "u-defvar" :depends-on ("p-defvar" "package") :encoding :utf-8) (:file "u-defvar.vector" :depends-on ("p-defvar" "package") :encoding :utf-8) (:file "u-defvar.setf" :depends-on ("p-defvar" "package") :encoding :utf-8) (:file "u-defvar.push" :depends-on ("p-defvar" "package") :encoding :utf-8) (:file "u-define-setf-expander" :depends-on ("p-define-setf-expander" "package") :encoding :utf-8) (:file "u-defsetf" :depends-on ("p-defsetf" "package") :encoding :utf-8) (:file "u-defclass.defclass" :depends-on ("p-defclass" "package") :encoding :utf-8) (:file "u-defclass.defmethod" :depends-on ("p-defclass" "package") :encoding :utf-8) (:file "u-defgeneric" :depends-on ("p-defgeneric" "package") :encoding :utf-8) (:file "u-defmethod" :depends-on ("p-defmethod" "package") :encoding :utf-8) (:file "u-define-condition" :depends-on ("p-define-condition" "package") :encoding :utf-8) (:file "u-defstruct" :depends-on ("p-defstruct" "package") :encoding :utf-8) (:file "u-defstruct.type" :depends-on ("p-defstruct" "package") :encoding :utf-8) (:file "u-defstruct.defmethod" :depends-on ("p-defstruct" "package") :encoding :utf-8) (:file "u-defstruct.functions" :depends-on ("p-defstruct" "package") :encoding :utf-8) (:file "u-defstruct.functions.sharpquote" :depends-on ("p-defstruct" "package") :encoding :utf-8) (:file "u-defstruct.include" :depends-on ("p-defstruct" "package") :encoding :utf-8) (:file "u-defpackage" :depends-on ("p-defpackage") :encoding :utf-8) (:file "u-defpackage.1" :depends-on ("p-defpackage") :encoding :utf-8) (:file "u-defpackage.2" :depends-on ("p-defpackage") :encoding :utf-8) (:file "u-defpackage.3" :depends-on ("p-defpackage") :encoding :utf-8) (:file "u-defun" :depends-on ("p-defun" "package") :encoding :utf-8) (:file "u-defun.sharpquote" :depends-on ("p-defun" "package") :encoding :utf-8) (:file "u-define-symbol-macro" :depends-on ("p-define-symbol-macro" "package") :encoding :utf-8) (:file "u-defconstant" :depends-on ("p-defconstant" "package") :encoding :utf-8) (:file "u-deftype.foo" :depends-on ("p-deftype" "package") :encoding :utf-8) (:file "u-deftype.bar" :depends-on ("package") :encoding :utf-8) (:file "u-deftype.satisfies" :depends-on ("package") :encoding :utf-8) (:file "u-deftype.etypecase" :depends-on ("p-deftype" "package") :encoding :utf-8) (:file "u-deftype.typecase" :depends-on ("p-deftype" "package") :encoding :utf-8))) )

2 1

progress on asdf-dependency-grovel
by Robert Dodier 17 Dec '22

17 Dec '22

I've managed to get asdf-dependency-grovel to load. There is a comment in adg/tests/grovel-test.lisp that ASDF 3.1 is required. Okay, I have ASDF 3.1.5 laying around so I loaded that. Now SBCL can load adg. The test script adg/tests/run-tests.sh runs (with modifications) but all of the tests fail -- it appears that no dependencies are identified. I enabled *DEBUG-TRACE* in variables.lisp, and I get some output which suggests something is happening, which is encouraging. Faré, can you say anything about what one should expect to see in the debug output if stuff is working correctly? Can you see anything amiss in the output shown below? best, Robert PS. Here is the output for adg/tests/u-defconstant.lisp. That file contains just (cl:in-package :asdf-dependency-grovel-test) (defvar test-defconstant-user.1 test-defconstant.1) which references TEST-DEFCONSTANT.1, which is defined in p-defconstant.lisp, so that's the dependency that's supposed to be detected. The output for other tests is similar. ----- begin output ----- DEBUG: Perform load-source-op #<ASDF-DEPENDENCY-GROVEL:INSTRUMENTED-CL-SOURCE-FILE "test-serial-system" "u-defconstant"> DEBUG: Operating on (:ASDF ("test-serial-system" "u-defconstant") :ASDF ("test-serial-system") . T) DEBUG: Operating on (:FILE #P"/home/robert/by-others/asdf-dependency-grovel-master/tests/u-defconstant.lisp" :ASDF ("test-serial-system" "u-defconstant") :ASDF ("test-serial-system") . T) DEBUG: Operating on ((:FORM 0 :FILE #P"/home/robert/by-others/asdf-dependency-grovel-master/tests/u-defconstant.lisp" :ASDF ("test-serial-system" "u-defconstant") :ASDF ("test-serial-system") . T) 0 "(IN-PACKAGE :ASDF-DEPENDENCY-GROVEL-TEST)") DEBUG: Done operating on ((:FORM 0 :FILE #P"/home/robert/by-others/asdf-dependency-grovel-master/tests/u-defconstant.lisp" :ASDF ("test-serial-system" "u-defconstant") :ASDF ("test-serial-system") . T) 0 "(IN-PACKAGE :ASDF-DEPENDENCY-GROVEL-TEST)") DEBUG: Operating on ((:FORM 1 :FILE #P"/home/robert/by-others/asdf-dependency-grovel-master/tests/u-defconstant.lisp" :ASDF ("test-serial-system" "u-defconstant") :ASDF ("test-serial-system") . T) 44 "(DEFVAR TEST-DEFCONSTANT-USER.1 ...)") DEBUG: Done operating on ((:FORM 1 :FILE #P"/home/robert/by-others/asdf-dependency-grovel-master/tests/u-defconstant.lisp" :ASDF ("test-serial-system" "u-defconstant") :ASDF ("test-serial-system") . T) 44 "(DEFVAR TEST-DEFCONSTANT-USER.1 ...)") DEBUG: Done operating on (:FILE #P"/home/robert/by-others/asdf-dependency-grovel-master/tests/u-defconstant.lisp" :ASDF ("test-serial-system" "u-defconstant") :ASDF ("test-serial-system") . T) DEBUG: Done operating on (:ASDF ("test-serial-system" "u-defconstant") :ASDF ("test-serial-system") . T) ----- end output -----

2 5

Lisp file and/or ASDF dependency analysis; trying to load asdf-dependency-grovel
by Robert Dodier 15 Dec '22

15 Dec '22

Hi, I'm interested in analyzing dependencies among a collection of Lisp files, or analyzing dependencies stated in a .asd file, or both. (1) Towards the goal of analyzing dependencies among Lisp files, I'm trying to load asdf-dependency-grovel, and I'm not having any luck. I obtained a tar.gz of the current version from Gitlab, from the project https://gitlab.common-lisp.net/xcvb/asdf-dependency-grovel. I found it necessary to patch tests/run-tests.sh to get anywhere (patch below) and I get the following error at this point: ------------------------------------------------ $ sh tests/run-tests.sh This is SBCL 2.1.6, an implementation of ANSI Common Lisp. WARNING: redefining UIOP/UTILITY:PARSE-BODY in DEFUN WARNING: Deprecated recursive use of (ASDF/OPERATE:OPERATE 'ASDF/LISP-ACTION:LOAD-OP '("test-serial-system")) while visiting (ASDF-DEPENDENCY-GROVEL:DEPENDENCY-OP "test-serial" "asdf-dependency-grovel-test/serial") - please use proper dependencies instead debugger invoked on a SIMPLE-ERROR in thread #<THREAD "main thread" RUNNING {988AB081}>: Just performed compiling #<INSTRUMENTED-CL-SOURCE-FILE "test-serial-system" "package"> but failed to mark it done ------------------------------------------------ Can anyone offer any advice about the "failed to mark it done" error? or the bit about "deprecated recursive use"? (2) About looking at dependencies stated in a .asd file, I have a .asd file which ASDF is refusing to load because it has a circular dependency. Is there a way to get ASDF to tell me what that circular dependency is? Failing that, can someone suggest any tools to extract a directed graph from a .asd file? I suppose it wouldn't be too hard to do it myself but no need to reinvent the wheel. I'm thinking I could find a graph analysis library to extract any cycles, if I had a directed graph in hand. I don't suppose someone has already automated looking for cycles in .asd files? Thanks in advance for any advice, I appreciate your help. best, Robert Dodier PS. Here's my patch for asdf-dependency-grovel. $ diff -u tests/run-tests.sh-original tests/run-tests.sh --- tests/run-tests.sh-original 2022-12-13 22:39:50.174826971 -0800 +++ tests/run-tests.sh 2022-12-13 22:43:41.675974917 -0800 @@ -5,7 +5,10 @@ ADG_TEST_DIR="$(dirname $0)" -$LISP --load ${ADG_TEST_DIR}/grovel-tests.lisp --eval '(uiop:quit (asdf-dependency-grovel-tester:test-result))' +$LISP --eval '(require (quote asdf))'\ + --eval '(push "/home/robert/by-others/asdf-dependency-grovel-master/" asdf:*central-registry*)'\ + --eval '(push "/home/robert/by-others/asdf-dependency-grovel-master/tests/" asdf:*central-registry*)'\ + --load ${ADG_TEST_DIR}/grovel-tests.lisp --eval '(uiop:quit (asdf-dependency-grovel-tester:test-result))' STATUS=$? rm -rf asdf-dependency-grovel-tmp-* #$LISP --load ${ADG_TEST_DIR}/grovel-tests.lisp --eval '(asdf-dependency-grovel-tester:check-base-deps)' --eval '(uiop:quit)'

2 3

Fwd: Lisp file and/or ASDF dependency analysis; trying to load asdf-dependency-grovel
by Faré 15 Dec '22

15 Dec '22

---------- Forwarded message --------- From: Faré <fahree(a)gmail.com> Date: Thu, Dec 15, 2022, 04:02 Subject: Re: Lisp file and/or ASDF dependency analysis; trying to load asdf-dependency-grovel To: Robert Dodier <robert.dodier(a)gmail.com> asdf-dependency-grovel predates asdf 2, and probably bitrotted with asdf 3. My guess is that its dependency-op needs a prepare-dependency-op the same way that load-source-op has a prepare-load-source-op. The entire class hierarchy could probably be lifted the same way, except of course for the perform method. Sorry I have no time to dig into the code. Hope this helps. On Thu, Dec 15, 2022, 02:08 Robert Dodier <robert.dodier(a)gmail.com> wrote: > Hi, I'm interested in analyzing dependencies among a collection of > Lisp files, or analyzing dependencies stated in a .asd file, or both. > > (1) Towards the goal of analyzing dependencies among Lisp files, I'm > trying to load asdf-dependency-grovel, and I'm not having any luck. I > obtained a tar.gz of the current version from Gitlab, from the project > https://gitlab.common-lisp.net/xcvb/asdf-dependency-grovel. I found it > necessary to patch tests/run-tests.sh to get anywhere (patch below) > and I get the following error at this point: > > ------------------------------------------------ > $ sh tests/run-tests.sh > This is SBCL 2.1.6, an implementation of ANSI Common Lisp. > > WARNING: redefining UIOP/UTILITY:PARSE-BODY in DEFUN > WARNING: > Deprecated recursive use of (ASDF/OPERATE:OPERATE > 'ASDF/LISP-ACTION:LOAD-OP > '("test-serial-system")) while visiting > (ASDF-DEPENDENCY-GROVEL:DEPENDENCY-OP "test-serial" > "asdf-dependency-grovel-test/serial") > - please use proper dependencies instead > > debugger invoked on a SIMPLE-ERROR in thread > #<THREAD "main thread" RUNNING {988AB081}>: > Just performed compiling #<INSTRUMENTED-CL-SOURCE-FILE > "test-serial-system" "package"> but failed to mark it done > ------------------------------------------------ > > Can anyone offer any advice about the "failed to mark it done" error? > or the bit about "deprecated recursive use"? > > (2) About looking at dependencies stated in a .asd file, I have a .asd > file which ASDF is refusing to load because it has a circular > dependency. Is there a way to get ASDF to tell me what that circular > dependency is? Failing that, can someone suggest any tools to extract > a directed graph from a .asd file? I suppose it wouldn't be too hard > to do it myself but no need to reinvent the wheel. > > I'm thinking I could find a graph analysis library to extract any > cycles, if I had a directed graph in hand. I don't suppose someone has > already automated looking for cycles in .asd files? > > Thanks in advance for any advice, I appreciate your help. > > best, > > Robert Dodier > > PS. Here's my patch for asdf-dependency-grovel. > > $ diff -u tests/run-tests.sh-original tests/run-tests.sh > --- tests/run-tests.sh-original 2022-12-13 22:39:50.174826971 -0800 > +++ tests/run-tests.sh 2022-12-13 22:43:41.675974917 -0800 > @@ -5,7 +5,10 @@ > > ADG_TEST_DIR="$(dirname $0)" > > -$LISP --load ${ADG_TEST_DIR}/grovel-tests.lisp --eval '(uiop:quit > (asdf-dependency-grovel-tester:test-result))' > +$LISP --eval '(require (quote asdf))'\ > + --eval '(push > "/home/robert/by-others/asdf-dependency-grovel-master/" > asdf:*central-registry*)'\ > + --eval '(push > "/home/robert/by-others/asdf-dependency-grovel-master/tests/" > asdf:*central-registry*)'\ > + --load ${ADG_TEST_DIR}/grovel-tests.lisp --eval '(uiop:quit > (asdf-dependency-grovel-tester:test-result))' > STATUS=$? > rm -rf asdf-dependency-grovel-tmp-* > #$LISP --load ${ADG_TEST_DIR}/grovel-tests.lisp --eval > '(asdf-dependency-grovel-tester:check-base-deps)' --eval '(uiop:quit)' > >

1 0

Wrong release version in front page
by Nikolaos Chatzikonstantinou 18 Nov '22

18 Nov '22

Hello, I noticed that the front page in <https://asdf.common-lisp.dev/> claims that the latest version is 3.3.5 but the release tarball <https://common-lisp.net/project/asdf/archives/asdf.tar.gz> unpacks to asdf-3.3.6. Also, do you sign the releases? Regards, Nikolaos Chatzikonstantinou

2 2

Change to allow loading linked asd files
by Nibby Nebbulous 17 Nov '22

17 Nov '22

Hi, I wonder if it possible that you would accept this change which allows finding of a system by a symbolicly linked ".asd" file. I've been running with this patch for about 10 years without issue. I'm sorry for not having test cases and documentation, but it seems time passing won't help that. I know this is probably a pointless change for everyone besides me, being the only user of my software, so I quite understand if you don't want to add it. Anyway, many thanks for your years of work on perhaps the most used CL software ever. diff --git a/find-system.lisp b/find-system.lisp index 0980a2cc..1a226aba 100644 --- a/find-system.lisp +++ b/find-system.lisp @@ -263,11 +263,16 @@ PREVIOUS-PRIMARY when not null is the primary system for the PREVIOUS system." (locate-system name) (assert (eq foundp (and (or found-system pathname previous) t)))) (let ((previous-pathname (system-source-file previous)) - (system (or previous found-system))) + (system (or previous found-system)) + real-name) (when (and found-system (not previous)) (register-system found-system)) (when (and system pathname) (setf (system-source-file system) pathname)) + (when (and pathname + (setf real-name (pathname-name pathname)) + (not (equal real-name name))) + (setf name real-name)) (if-let ((stamp (get-file-stamp pathname))) (let ((up-to-date-p (and previous previous-primary

3 4

Handling of readme and license files
by Russell Sim 21 Oct '22

21 Oct '22

Hey, I'm working with a project that bundles up CL systems, and then copies them to a remote host. To avoid copying unnecessary files, we rely on the components and additional-input-files to find all the files needed to load the system on the remote host. I found some ASD files to load on the remote host. These systems are expecting to read a long-description, usually a readme file. All of these projects are using reader macros to load this data, and none of them declare the file as a :static-file component. It's also often the case that the license of a project requires a copy of the license be shipped with the project. Yet rarely do I see any project declaring a :static-file for one in their asd file. Am I correct in my understanding that using :static-files is this the current recommended way to declare these files? Is there any plan for ASDF to improve the handling of these 2 cases? I see other packaging systems often have a special field for the license file, and having a :read-file form for the long-descripton much like the version field has, would improve handling of these readme's greatly. At the moment asd authors don't have an easy way to test asd evaluation when files like the readme aren't present. Leading to error prone code like this. :long-description #.(uiop:read-file-string (uiop:subpathname *load-pathname* "README.md")) I pulled a sample of 800 packages from quicklisp, 95 of them are using either uiop:read-file-string (65) or a safer, more verbose with-open-file (30) form. Thank you for your work maintaining this essential system. Regards, Russell Sim

4 12

ASDF 3.3.6 is released
by Robert Goldman 07 Aug '22

07 Aug '22

Today we release ASDF 3.3.6, the sixth bugfix release for the 3.3 release series, and -- it is devoutly to be hoped -- the final one. We urge implementations that are currently bundling previous versions of ASDF -- and especially those bundling 3.3.0 through 3.3.5 -- to upgrade to 3.3.6 at their earliest convenience. As maintainer, my primary role continues to be coordination and some limited quality control. The real work for this release has been done by many contributors and bug-reporters, to whom the Common Lisp community owes a tremendous vote of thanks. Their names are listed on the Changelog, appended below. An extra special thanks is due to my co-maintainer, Eric Timmons, who has provided many fixes and also has overhauled and much improved our regression testing. We *hope* that the next release will be 3.4, introducing new functionality but which, as the numbering suggests, will be backward compatible. Best, Robert # Changelog * Fix bug loading ASDF system definitions from jar files on ABCL. See !190 * Fix bug with version numbering after reload. See !194 and #94. Thanks to Eric Timmons. * Fix bug in return value of UPGRADE-ASDF. See !195. Again, thanks to Eric Timmons. * Multiple improvements to documentation and tests. Thanks to Nathan Ringo and Phoebe Goldman. * Add clasp support for uiop/launch program. Thanks to Christian Schafmeister. * Miscellaneous minor bug fixes and tweaks. * Don't let *package* binding leak into ASDF compile operations. Thanks to Phoebe Goldman.

1 0

← Newer
1
2
3
4
5
6
7
...
138
Older →

Jump to page:

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

asdf-devel