I have just pushed 3.1.4.5, which contains fixes to UIOP's configuration file finding/XDG functions needed to fix launchpad bug 1437480.
Testing would be very much appreciated, especially by those using the configuration file finding functions.
Robert P. Goldman wrote:
I have just pushed 3.1.4.5, which contains fixes to UIOP's configuration file finding/XDG functions needed to fix launchpad bug 1437480.
Testing would be very much appreciated, especially by those using the configuration file finding functions.
Sorry: typo -- that should have been 3.1.4.6
Cheers, r
Robert P. Goldman wrote:
I have just pushed [3.1.4.6], which contains fixes to UIOP's configuration file finding/XDG functions needed to fix launchpad bug 1437480.
Thanks a lot, Robert!
In backward driver, the (xdg-config-pathname (format nil "common-lisp/~a/" x) direction)) is incorrect. X can be (and usually is) a file pathname, not a directory pathname, and xdg-config-pathname calls resolve-location that will already do the pathname merging magic so you don't need to format nil.
In the launchpad bug at https://bugs.launchpad.net/asdf/+bug/1437480 you also mention:
I believe that we should release this as 3.2 because of the incompatibility in the API with the new functions from UIOP.
While I think we should indeed soon release 3.2, I believe that it is not so urgent that it can't wait for a few more useful changes, especially since we do provide backward compatibility functions for the old API. So I propose we release a 3.1.5 for now, and do a few more changes before we actually cut a 3.2.
He are the few changes I believe could usefully be done *before* rather than *after* we cut a #+asdf3.2 feature:
* Most importantly, this test-system feature I've recently discussed. This change is useless until a new #+ feature is introduced, because people will have to add #+asdf3.2 and/or #-asdf3.2 in their defsystem files to depend on it, until 3.2 becomes ubiquitous (or 3.3, if the feature only makes it to 3.3). * minimakefile. Can we get this in before we cut 3.2? Actually, merging before 3.1.5 would allow to test the release functions before we release an actual 3.2. * maybe some infrastructure to declare old functions obsolete and issue style-warnings, warnings, cerror or even errors when they are used. They are a few ASDF2 compatibility functions that should go, and even a few old ASDF3 misfeatures that could get a headstart in the deprecation area. * Conversely, since it is actually supported and not going to be deprecated (and I've started to take a liking to it), we should probably move the inline-method feature from backward-internals back to parse-defsystem or such.
I think the syntax-control branch can wait until 3.2 is released. Hopefully, it can make it into 3.3 by next year (wow, ASDF moves slowly again)!
—♯ƒ • François-René ÐVB Rideau •Reflection&Cybernethics• http://fare.tunes.org Apparently a government can prevent itself and its successors indefinite from doing bad things, just by writing a note to itself that says "don't do bad things." — Mencius Moldbug on constitutions
Dear Robert,
so I pushed two easy changes among those list I discussed on the list: Move the inline-method support to parse-defsystem Fix in-user-configuration-directory to accept files, not just directories. I also had to fix find-standard-case-symbol again, so I added regression tests.
Now, when I did a make bump, I got the following error message:
Transforming file upgrade.lisp... done. Rebuilding ASDF with bumped version git commit -a -m "Bump version to $(eval a=$(cat version.lisp-expr) ; echo $a)" fatal: ..: '..' is outside repository [master 9120cf7] Bump version to 3.1.4.7 4 files changed, 4 insertions(+), 4 deletions(-)
I checked that it's the command `git commit -a -m '3.1.4.7'` that was complaining indeed. Why, I don't know. I tried to `git submodule deinit .` and/or `git clean -xfd`, to no avail; I see symlinks to ../ but only in subdirectories. I see no .. in my .git/* or .git* files. I hope it's not a symptom of something too bad. Do you have the same symptom?
Finally, is there already a deprecation library for CL somewhere? Otherwise, I ought to write one for UIOP, and start using it for the backward-foo functions.
—♯ƒ • François-René ÐVB Rideau •Reflection&Cybernethics• http://fare.tunes.org The government consists of a gang of men exactly like you and me. They have, taking one with another, no special talent for the business of government; they have only a talent for getting and holding office. Their principal device to that end is to search out groups who pant and pine for something they can't get and to promise to give it to them. Nine times out of ten that promise is worth nothing. The tenth time is made good by looting A to satisfy B. In other words, government is a broker in pillage, and every election is sort of an advance auction sale of stolen goods. — H. L. Mencken
Faré wrote:
Now, when I did a make bump, I got the following error message:
Transforming file upgrade.lisp... done. Rebuilding ASDF with bumped version git commit -a -m "Bump version to $(eval a=$(cat version.lisp-expr) ; echo $a)" fatal: ..: '..' is outside repository [master 9120cf7] Bump version to 3.1.4.7 4 files changed, 4 insertions(+), 4 deletions(-)
I checked that it's the command `git commit -a -m '3.1.4.7'` that was complaining indeed. Why, I don't know. I tried to `git submodule deinit .` and/or `git clean -xfd`, to no avail; I see symlinks to ../ but only in subdirectories. I see no .. in my .git/* or .git* files. I hope it's not a symptom of something too bad. Do you have the same symptom?
I did this immediately before releasing and I didn't get an error message.
The only symlinks I find in my working copy are:
contrib/debug.lisp uiop/version.lisp-expr test/test-multiple-too.asd
and only the first two have .. in their expansion.
How does that compare with what you have?
Best, r
Faré wrote:
In the launchpad bug at https://bugs.launchpad.net/asdf/+bug/1437480 you also mention:
I believe that we should release this as 3.2 because of the incompatibility in the API with the new functions from UIOP.
While I think we should indeed soon release 3.2, I believe that it is not so urgent that it can't wait for a few more useful changes, especially since we do provide backward compatibility functions for the old API. So I propose we release a 3.1.5 for now, and do a few more changes before we actually cut a 3.2.
I wasn't clear: I don't mean that we need to do a 3.2 release at this very moment, just that these changes are not fully compatible, so are worthy of a "greater than patch level" release.
I'm not so sure about the 3.1.5, since that means stuff that's not API compatible comes out as a patch level release.
He are the few changes I believe could usefully be done *before* rather than *after* we cut a #+asdf3.2 feature:
- Most importantly, this test-system feature I've recently discussed.
This change is useless until a new #+ feature is introduced, because people will have to add #+asdf3.2 and/or #-asdf3.2 in their defsystem files to depend on it, until 3.2 becomes ubiquitous (or 3.3, if the feature only makes it to 3.3).
Agreed. I think this is a very important addition, and I'd like to see it go into the release.
Note that the feature would give us a way to do what you want (release 3.1.5), because we could add :asdf3.2 in at that point.
On the other hand, maybe we need to have 3.2.0.1 be the next thing we push, and call it a release candidate. It may be that the release will have to be 3.2.1, but I could live with that.
What do firm believers in semantic versioning do about this? Just always have their release be x.y.z when they want x.y, so that they can have a release candidate? Or do they do something like x.y.rcz? That would require a change to VERSION-SATISFIES...
- minimakefile. Can we get this in before we cut 3.2? Actually,
merging before 3.1.5 would allow to test the release functions before we release an actual 3.2.
The last time I was working with minimakefile it was still at the state where every time I tried a new command, I would get a new error. I got tired of this and gave up. I'll try again, but this one is your cause: I don't care if CL never becomes a scripting language. I'm willing to run with it if it works, but if it gives me grief, I'll give up again.
- maybe some infrastructure to declare old functions obsolete and
issue style-warnings, warnings, cerror or even errors when they are used. They are a few ASDF2 compatibility functions that should go, and even a few old ASDF3 misfeatures that could get a headstart in the deprecation area.
Yes, we discussed this. I have created a ticket for this: https://bugs.launchpad.net/asdf/+bug/1451431
I have added a note to that wrt your suggestion that the deprecation library live in UIOP, and be used in ASDF.
I think the syntax-control branch can wait until 3.2 is released. Hopefully, it can make it into 3.3 by next year (wow, ASDF moves slowly again)!
I think that's a Good Thing: it is a reflection of ASDF mostly just working happily, and a reflection of ASDF's critical place in the CL community's infrastructure.
While I think we should indeed soon release 3.2, I believe that it is not so urgent that it can't wait for a few more useful changes, especially since we do provide backward compatibility functions for the old API. So I propose we release a 3.1.5 for now, and do a few more changes before we actually cut a 3.2.
I wasn't clear: I don't mean that we need to do a 3.2 release at this very moment, just that these changes are not fully compatible, so are worthy of a "greater than patch level" release.
Well, we do provide a backward compatible API; but it's true that the behavior on Windows has slightly changed.
On the other hand, we have accumulated enough bug fixes and features since last October, including support for a new implementation (clasp) to warrant a release soon. Release numbers are not a scarce resource, so if you believe this requires a 3.2 release now, that just means that the further changes I'd like will have to be for a 3.3 release.
On the other hand, maybe we need to have 3.2.0.1 be the next thing we push, and call it a release candidate. It may be that the release will have to be 3.2.1, but I could live with that.
That's how we did the 3.1 release: pre-releases as 3.1.0.x, and release as 3.1.1. It seems to have worked out well — well except for immediately followeing it with a 3.1.2 for a bug fix :-(.
What do firm believers in semantic versioning do about this? Just always have their release be x.y.z when they want x.y, so that they can have a release candidate? Or do they do something like x.y.rcz? That would require a change to VERSION-SATISFIES...
We could specially parse rc as "-1", "beta" as "-2", "alpha" as -3, etc, but that sounds like dubious over-engineering to me.
—♯ƒ • François-René ÐVB Rideau •Reflection&Cybernethics• http://fare.tunes.org Director is a misnomer. You're a hoper. You put all these people together and you hope it all works out. — Frank Oz, director of "Dirty Rotten Scoundrels"
Faré wrote:
While I think we should indeed soon release 3.2, I believe that it is not so urgent that it can't wait for a few more useful changes, especially since we do provide backward compatibility functions for the old API. So I propose we release a 3.1.5 for now, and do a few more changes before we actually cut a 3.2.
I wasn't clear: I don't mean that we need to do a 3.2 release at this very moment, just that these changes are not fully compatible, so are worthy of a "greater than patch level" release.
Well, we do provide a backward compatible API; but it's true that the behavior on Windows has slightly changed.
We provide a backward compatible API, but we don't have a *forward* compatible one, because of the new XDG functions.
On the other hand, we have accumulated enough bug fixes and features since last October, including support for a new implementation (clasp) to warrant a release soon. Release numbers are not a scarce resource, so if you believe this requires a 3.2 release now, that just means that the further changes I'd like will have to be for a 3.3 release.
On the other hand, maybe we need to have 3.2.0.1 be the next thing we push, and call it a release candidate. It may be that the release will have to be 3.2.1, but I could live with that.
That's how we did the 3.1 release: pre-releases as 3.1.0.x, and release as 3.1.1. It seems to have worked out well — well except for immediately followeing it with a 3.1.2 for a bug fix :-(.
What do firm believers in semantic versioning do about this? Just always have their release be x.y.z when they want x.y, so that they can have a release candidate? Or do they do something like x.y.rcz? That would require a change to VERSION-SATISFIES...
We could specially parse rc as "-1", "beta" as "-2", "alpha" as -3, etc, but that sounds like dubious over-engineering to me.
Agreed. OK, the next time I push, I will push 3.2.0.1, because I'd like to have people be able to start checking for version 3.2 for the new XDG functions (and eventually the new test-operation functions).
Should we push just asdf-3.2 or also uiop-3.2 (since the new XDG functions are properly UIOP)?
thanks, r
Should we push just asdf-3.2 or also uiop-3.2 (since the new XDG functions are properly UIOP)?
(I assume you mean *features*) Actually, I don't think there's anything new asdf that warrants a feature, so I'd add a uiop feature only (and uiop has evolved enough since 2.27 that a feature could help, especially considering that at least quicklisp distributes uiop without asdf). I believe uiop/driver.lisp is the correct place for the pushnew.
—♯ƒ • François-René ÐVB Rideau •Reflection&Cybernethics• http://fare.tunes.org Live as if you were living already for the second time and as if you had acted the first time as wrongly as you are about to act now! — Viktor Frankl, "Man's Search for Meaning"
Faré wrote:
Should we push just asdf-3.2 or also uiop-3.2 (since the new XDG functions are properly UIOP)?
(I assume you mean *features*) Actually, I don't think there's anything new asdf that warrants a feature, so I'd add a uiop feature only (and uiop has evolved enough since 2.27 that a feature could help, especially considering that at least quicklisp distributes uiop without asdf). I believe uiop/driver.lisp is the correct place for the pushnew.
OK. Should we at some point define a stable UIOP feature set, and just bump to 3.0 as a new stable point?
cheers, r
Actually, I don't think there's anything new asdf that warrants a feature, so I'd add a uiop feature only (and uiop has evolved enough since 2.27 that a feature could help, especially considering that at least quicklisp distributes uiop without asdf). I believe uiop/driver.lisp is the correct place for the pushnew.
OK. Should we at some point define a stable UIOP feature set, and just bump to 3.0 as a new stable point?
I suppose whenever you release 3.2 (hopefully this year) is the best time to decree that whatever is in UIOP is the new stable point, and then to apply "usual" deprecation policies to any API change.
Of course, it would be nice if deprecation support functions were made part of UIOP before this happens, though not strictly necessary.
—♯ƒ • François-René ÐVB Rideau •Reflection&Cybernethics• http://fare.tunes.org During the Bikini operations, a discussion arose as to what weapons would be used in the next war–atom bombs, germs, rockets. “I don’t know what weapons will be used in the next war,” a young Army lieutenant interrupted, “but in the war after the next one, surer than hell they’ll be using bows and arrows and spears.” — Joe Laitin in Frontpage, 1946
-
Faré -
Robert P. Goldman