This weekend, thanks to Dave Cooper, there was much bug fixing on windows, particularly (but not only) related to run-program (and, unhappily, also unearthing implementation bugs in at least in Allegro and SBCL). PJB also found a bug in with-temporary-file, that was fixed. Because I was remote-debugging and failed to think about sharing a topic branch, this led to many increments in patch number. The test system was made more robust as a result.
I also found a bug in test-module-pathnames (failure to specify *test-directory* to merge-pathnames*) that may or may not explain the test failures that Robert was seeing on LispWorks/Mac, and Dave on sbcl/win -- Robert, does your pathname under LispWorks have a non-nil host and/or device? That would explain it.
SBCL/win also has massive failures in asdf-pathname-test, which I don't fully understand (I don't understand this janderson-contributed test in general), but every other file write test is a failure.
Robert: can I commit this asdf-package-system branch now, before the 3.0.3 release? It's only additive features, modulo a rename of file asdf/defsystem to asdf/parse-defsystem (with a nickname for the old package name) and system asdf/header to asdf/prelude. Maintaining that topic branch is slightly costly, I've been using it for a week and removed a lot of kinks and relative inefficiencies. The new features are the support for the package-system "one package per file" style of quick-build, and some useful :use-reexport and :mix-reexport options of uiop:define-package. I believe it's not affecting anything negatively and is robust, and I'd really like to be able to encourage people to "just use it" without waiting for a few more months until the next release. [I'm using it for lisp-interface-library, but it's more awkward if people have to use the asdf extension asdf-package-system.]
—♯ƒ • François-René ÐVB Rideau •Reflection&Cybernethics• http://fare.tunes.org Panties: not best thing on earth, but next to it.
Faré wrote:
Robert: can I commit this asdf-package-system branch now, before the 3.0.3 release? It's only additive features, modulo a rename of file asdf/defsystem to asdf/parse-defsystem (with a nickname for the old package name) and system asdf/header to asdf/prelude. Maintaining that topic branch is slightly costly, I've been using it for a week and removed a lot of kinks and relative inefficiencies. The new features are the support for the package-system "one package per file" style of quick-build, and some useful :use-reexport and :mix-reexport options of uiop:define-package. I believe it's not affecting anything negatively and is robust, and I'd really like to be able to encourage people to "just use it" without waiting for a few more months until the next release. [I'm using it for lisp-interface-library, but it's more awkward if people have to use the asdf extension asdf-package-system.]
I would sort of prefer not to, because I would like people to require ASDF 3.1 when using asdf package systems.
I don't like instituting new API features without a reliable way to detect whether or not your version of ASDF supports them. If I let this slip out in ASDF 3.0, then if people start using the feature in the wild, they CANNOT conditionalize it on ASDF version being greater than 3.1. Hence my preference to keep it out of 3.0.3.
However, I sympathize with your desire to kill the topic branch. So how about this:
I will run the tests again today on head, on Mac and Linux. If the tests all pass for me, I will release 3.0.3, and we will move to 3.1.0.
I was holding off, hoping for a judgment about 3.0.3 compatibility with Quicklisp, but don't want to continue to push the branch maintenance cost onto you.
Best, R
On Mon, Oct 14, 2013 at 11:57 AM, Robert Goldman rpgoldman@sift.net wrote:
Faré wrote:
Robert: can I commit this asdf-package-system branch now, before the 3.0.3 release? It's only additive features [...]
I would sort of prefer not to, because I would like people to require ASDF 3.1 when using asdf package systems.
I both agree on the goal and disagree on the means:
1- Yes, it would be nice to have an #+asdf3.1 feature and encourage people to conditionalize on it their use of recent features not present in 3.0.0.
2- On the other hand, the only way to really iron out the kinks is to get the feature out early, and get more people to try it. If we wait for all bugs to be fixed to release, we'll never release, and we'll never get them fixed. This weekend debugging session on Windows found plenty of bugs (that prove that there are no CL hackers using run-program much on Windows, and not just uiop's wrapper, but the underlying thing). There were also bugs in some use cases of with-temporary-file, of for various open file utilities on LispWorks (I just discovered that you better use lw:simple-char rather than character if you specify :external-format :utf-8).
3- After a week of using it, I found many small kinks in that branch, that I resolved. More eyes could have found them earlier, and could have found the kinks that I still haven't seen. If there are such bugs lurking around, I really would like them fixed before we declare "yes, you can really trust this feature to be there and solid if the asdf3.1 feature is present."
I don't like instituting new API features without a reliable way to detect whether or not your version of ASDF supports them. If I let this slip out in ASDF 3.0, then if people start using the feature in the wild, they CANNOT conditionalize it on ASDF version being greater than 3.1. Hence my preference to keep it out of 3.0.3.
When I introduced the :around-compile, :compile-check, :force-not, a working :force (sys1 sys2), classes cl-source-file.cl & cl-source-file.lsp, quicklisp compatibility, a *working* :defsystem-depends-on or :encoding, I didn't add a new feature (ok, for :encoding, there's :asdf-unicode when it's actually useful). Rather, users could either :depends-on ((:version :asdf "2.23")) or #.(if (fboundp 'asdf::some-function) ...) Eventually, but not initially, I could just start using #+asdf3 for my uses of these features.
I propose that the same be true for the asdf-package-system. For now, people can #.(if (find-class 'asdf::package-system nil) ...) and in a few weeks or months, they can instead #+asdf3.1
However, I sympathize with your desire to kill the topic branch. So how about this:
I will run the tests again today on head, on Mac and Linux. If the tests all pass for me, I will release 3.0.3, and we will move to 3.1.0.
I was holding off, hoping for a judgment about 3.0.3 compatibility with Quicklisp, but don't want to continue to push the branch maintenance cost onto you.
Works for me, too.
—♯ƒ • François-René ÐVB Rideau •Reflection&Cybernethics• http://fare.tunes.org Every program has at least one bug and can be shortened by at least one instruction — from which, by induction, one can deduce that every program can be reduced to one instruction which doesn't work.
Faré wrote:
On Mon, Oct 14, 2013 at 11:57 AM, Robert Goldman rpgoldman@sift.net wrote:
Faré wrote:
Robert: can I commit this asdf-package-system branch now, before the 3.0.3 release? It's only additive features [...]
I would sort of prefer not to, because I would like people to require ASDF 3.1 when using asdf package systems.
I both agree on the goal and disagree on the means:
1- Yes, it would be nice to have an #+asdf3.1 feature and encourage people to conditionalize on it their use of recent features not present in 3.0.0.
2- On the other hand, the only way to really iron out the kinks is to get the feature out early, and get more people to try it. If we wait for all bugs to be fixed to release, we'll never release, and we'll never get them fixed. This weekend debugging session on Windows found plenty of bugs (that prove that there are no CL hackers using run-program much on Windows, and not just uiop's wrapper, but the underlying thing). There were also bugs in some use cases of with-temporary-file, of for various open file utilities on LispWorks (I just discovered that you better use lw:simple-char rather than character if you specify :external-format :utf-8).
3- After a week of using it, I found many small kinks in that branch, that I resolved. More eyes could have found them earlier, and could have found the kinks that I still haven't seen. If there are such bugs lurking around, I really would like them fixed before we declare "yes, you can really trust this feature to be there and solid if the asdf3.1 feature is present."
I don't like instituting new API features without a reliable way to detect whether or not your version of ASDF supports them. If I let this slip out in ASDF 3.0, then if people start using the feature in the wild, they CANNOT conditionalize it on ASDF version being greater than 3.1. Hence my preference to keep it out of 3.0.3.
When I introduced the :around-compile, :compile-check, :force-not, a working :force (sys1 sys2), classes cl-source-file.cl & cl-source-file.lsp, quicklisp compatibility, a *working* :defsystem-depends-on or :encoding, I didn't add a new feature (ok, for :encoding, there's :asdf-unicode when it's actually useful). Rather, users could either :depends-on ((:version :asdf "2.23")) or #.(if (fboundp 'asdf::some-function) ...) Eventually, but not initially, I could just start using #+asdf3 for my uses of these features.
I propose that the same be true for the asdf-package-system. For now, people can #.(if (find-class 'asdf::package-system nil) ...) and in a few weeks or months, they can instead #+asdf3.1
No, I don't want us to get into that position of users having to go back and change their system definitions later.
I think it's just simpler to push out 3.0.3 today, absent the feature, and then our users can :depends-on (:version :asdf "3.1") or #+asdf3.1 right away.
It should only be a matter of hours before we can start 3.1.0.1 and kill this pesky branch.
Best, Robert
I propose that the same be true for the asdf-package-system. For now, people can #.(if (find-class 'asdf::package-system nil) ...) and in a few weeks or months, they can instead #+asdf3.1
No, I don't want us to get into that position of users having to go back and change their system definitions later.
They kind of already have to, and/or the current fine-grained tests will remain compatible once a coarse-grained test becomes available. But that's your call.
I think it's just simpler to push out 3.0.3 today, absent the feature, and then our users can :depends-on (:version :asdf "3.1") or #+asdf3.1 right away.
Sure.
It should only be a matter of hours before we can start 3.1.0.1 and kill this pesky branch.
Do you mean 3.0.3.1, etc., so you can release 3.1.0, or 3.1.0.1, etc., so you'll release 3.1.1? (It's up to you to determine the numbering scheme, of course.)
—♯ƒ • François-René ÐVB Rideau •Reflection&Cybernethics• http://fare.tunes.org Cubans bemoan the three failures of the revolution: breakfast, lunch and dinner
Faré wrote:
It should only be a matter of hours before we can start 3.1.0.1 and kill this pesky branch.
Do you mean 3.0.3.1, etc., so you can release 3.1.0, or 3.1.0.1, etc., so you'll release 3.1.1? (It's up to you to determine the numbering scheme, of course.)
Yes, I was mumbling to myself about that. I want the prerelease candidates to be 3.1.<something>, so I think we are condemned to have 3.1.0.x all be prereleases, and the first release will have to be 3.1.1.
Somehow offends the small numerical tidiness side of my personality, but not really a big deal.
So the first prerelease version with the ASDF-PACKAGE system should be 3.1.0.1
Cheers, r
Could you please distinguish between stable and unstable releases. It's fine to ask the CL community to help with finding and fixing bugs, but there are situations where this can be a real showstopper, especially when working against deadlines. You have been very aggressive in the past at pushing out buggy versions of ASDF into compilers and quicklisp, and this can create real headaches. I think these versions should only get stable releases, and people interested in bleeding edge features can then ask for the unstable releases explicitly.
Please!!!
Pascal
Sent from my iPad
On 14 Oct 2013, at 19:17, Faré fahree@gmail.com wrote:
On Mon, Oct 14, 2013 at 11:57 AM, Robert Goldman rpgoldman@sift.net wrote: Faré wrote:
Robert: can I commit this asdf-package-system branch now, before the 3.0.3 release? It's only additive features [...]
I would sort of prefer not to, because I would like people to require ASDF 3.1 when using asdf package systems.
I both agree on the goal and disagree on the means:
1- Yes, it would be nice to have an #+asdf3.1 feature and encourage people to conditionalize on it their use of recent features not present in 3.0.0.
2- On the other hand, the only way to really iron out the kinks is to get the feature out early, and get more people to try it. If we wait for all bugs to be fixed to release, we'll never release, and we'll never get them fixed. This weekend debugging session on Windows found plenty of bugs (that prove that there are no CL hackers using run-program much on Windows, and not just uiop's wrapper, but the underlying thing). There were also bugs in some use cases of with-temporary-file, of for various open file utilities on LispWorks (I just discovered that you better use lw:simple-char rather than character if you specify :external-format :utf-8).
3- After a week of using it, I found many small kinks in that branch, that I resolved. More eyes could have found them earlier, and could have found the kinks that I still haven't seen. If there are such bugs lurking around, I really would like them fixed before we declare "yes, you can really trust this feature to be there and solid if the asdf3.1 feature is present."
I don't like instituting new API features without a reliable way to detect whether or not your version of ASDF supports them. If I let this slip out in ASDF 3.0, then if people start using the feature in the wild, they CANNOT conditionalize it on ASDF version being greater than 3.1. Hence my preference to keep it out of 3.0.3.
When I introduced the :around-compile, :compile-check, :force-not, a working :force (sys1 sys2), classes cl-source-file.cl & cl-source-file.lsp, quicklisp compatibility, a *working* :defsystem-depends-on or :encoding, I didn't add a new feature (ok, for :encoding, there's :asdf-unicode when it's actually useful). Rather, users could either :depends-on ((:version :asdf "2.23")) or #.(if (fboundp 'asdf::some-function) ...) Eventually, but not initially, I could just start using #+asdf3 for my uses of these features.
I propose that the same be true for the asdf-package-system. For now, people can #.(if (find-class 'asdf::package-system nil) ...) and in a few weeks or months, they can instead #+asdf3.1
However, I sympathize with your desire to kill the topic branch. So how about this:
I will run the tests again today on head, on Mac and Linux. If the tests all pass for me, I will release 3.0.3, and we will move to 3.1.0.
I was holding off, hoping for a judgment about 3.0.3 compatibility with Quicklisp, but don't want to continue to push the branch maintenance cost onto you.
Works for me, too.
—♯ƒ • François-René ÐVB Rideau •Reflection&Cybernethics• http://fare.tunes.org Every program has at least one bug and can be shortened by at least one instruction — from which, by induction, one can deduce that every program can be reduced to one instruction which doesn't work.
Dear Pascal,
all releases are considered stable, and they are recognizable because their version has only three numbers MAJOR.MINOR.RELEASE. (Back in ASDF 2 days, it was just two numbers 2.RELEASE.) If you see a version with four numbers MAJOR.MINOR.RELEASE.PATCH then it's not a release, and not considered "stable". (Back in ASDF 2 days, that would have been three numbers 2.RELEASE.PATCH.)
Certainly, even in "stable" code, some new features may not be perfect yet. That's called a bug, we've had plenty in the past, and we take bug reports seriously. But at least, before we make a release, we run our regression test suite on a wide variety of different implementations and operating systems, and we're pretty confident that nothing obvious was broken that used to work.
So, if you want stability, get what your implementation (or quicklisp) provides, and only upgrade from a release tarball or a git checkout of the release branch. If you need the latest feature or bug fix, at the price of higher risk of breakage, use git checkout of the master branch, and please report bugs.
ASDF is not different from a lot of other software in this regard, and certainly gets more release effort, with a more formal process and extensive test suite than about every single the Common Lisp library I've looked at.
PS: before a 3.1 release, we ought to do check results of cl-test-grid.
—♯ƒ • François-René ÐVB Rideau •Reflection&Cybernethics• http://fare.tunes.org It's just a pissing contest, but unfortunately the contestants never seem to run out of piss. — John McCarthy
On Mon, Oct 14, 2013 at 1:26 PM, Pascal Costanza pc@p-cos.net wrote:
Could you please distinguish between stable and unstable releases. It's fine to ask the CL community to help with finding and fixing bugs, but there are situations where this can be a real showstopper, especially when working against deadlines. You have been very aggressive in the past at pushing out buggy versions of ASDF into compilers and quicklisp, and this can create real headaches. I think these versions should only get stable releases, and people interested in bleeding edge features can then ask for the unstable releases explicitly.
I think somehow a message is being missed here. No version with four components, w.x.y.z to its version number is a "release," and such versions should not be considered stable.
I try much harder to make the patch level releases stable. Those are w.x.y versions, and should be considered as candidates for pushing into compilers and quick lisp.
Note that even the w.x.y versions are only as good as their testing. Right now, I regularly test on Mac and Linux. That is, I run the test suite. Previously unfounded bugs will not be encountered this way, only regressions.
So we do encourage all of you who can to run the w.x.y.z versions against your real, in the wild, systems, and report bugs to launchpad.net/asdf.
Thank you all, R
On Oct 14, 2013, at 12:26, Pascal Costanza pc@p-cos.net wrote:
Could you please distinguish between stable and unstable releases. It's fine to ask the CL community to help with finding and fixing bugs, but there are situations where this can be a real showstopper, especially when working against deadlines. You have been very aggressive in the past at pushing out buggy versions of ASDF into compilers and quicklisp, and this can create real headaches. I think these versions should only get stable releases, and people interested in bleeding edge features can then ask for the unstable releases explicitly.
Please!!!
Pascal
Sent from my iPad
On 14 Oct 2013, at 19:17, Faré fahree@gmail.com wrote:
On Mon, Oct 14, 2013 at 11:57 AM, Robert Goldman rpgoldman@sift.net wrote: Faré wrote: Robert: can I commit this asdf-package-system branch now, before the 3.0.3 release? It's only additive features [...]
I would sort of prefer not to, because I would like people to require ASDF 3.1 when using asdf package systems.
I both agree on the goal and disagree on the means:
1- Yes, it would be nice to have an #+asdf3.1 feature and encourage people to conditionalize on it their use of recent features not present in 3.0.0.
2- On the other hand, the only way to really iron out the kinks is to get the feature out early, and get more people to try it. If we wait for all bugs to be fixed to release, we'll never release, and we'll never get them fixed. This weekend debugging session on Windows found plenty of bugs (that prove that there are no CL hackers using run-program much on Windows, and not just uiop's wrapper, but the underlying thing). There were also bugs in some use cases of with-temporary-file, of for various open file utilities on LispWorks (I just discovered that you better use lw:simple-char rather than character if you specify :external-format :utf-8).
3- After a week of using it, I found many small kinks in that branch, that I resolved. More eyes could have found them earlier, and could have found the kinks that I still haven't seen. If there are such bugs lurking around, I really would like them fixed before we declare "yes, you can really trust this feature to be there and solid if the asdf3.1 feature is present."
I don't like instituting new API features without a reliable way to detect whether or not your version of ASDF supports them. If I let this slip out in ASDF 3.0, then if people start using the feature in the wild, they CANNOT conditionalize it on ASDF version being greater than 3.1. Hence my preference to keep it out of 3.0.3.
When I introduced the :around-compile, :compile-check, :force-not, a working :force (sys1 sys2), classes cl-source-file.cl & cl-source-file.lsp, quicklisp compatibility, a *working* :defsystem-depends-on or :encoding, I didn't add a new feature (ok, for :encoding, there's :asdf-unicode when it's actually useful). Rather, users could either :depends-on ((:version :asdf "2.23")) or #.(if (fboundp 'asdf::some-function) ...) Eventually, but not initially, I could just start using #+asdf3 for my uses of these features.
I propose that the same be true for the asdf-package-system. For now, people can #.(if (find-class 'asdf::package-system nil) ...) and in a few weeks or months, they can instead #+asdf3.1
However, I sympathize with your desire to kill the topic branch. So how about this:
I will run the tests again today on head, on Mac and Linux. If the tests all pass for me, I will release 3.0.3, and we will move to 3.1.0.
I was holding off, hoping for a judgment about 3.0.3 compatibility with Quicklisp, but don't want to continue to push the branch maintenance cost onto you.
Works for me, too.
—♯ƒ • François-René ÐVB Rideau •Reflection&Cybernethics• http://fare.tunes.org Every program has at least one bug and can be shortened by at least one instruction — from which, by induction, one can deduce that every program can be reduced to one instruction which doesn't work.
-
Faré -
Pascal Costanza -
Robert Goldman -
Robert P. Goldman