On 26 April 2011 12:36, Zach Beane <xach@xach.com> wrote:
PPS: I just made asdf more verbose in verbose mode. However, verbose mode is the default, so this may or may not be annoying. Please tell me.
Now that I've seen it, I do find it both annoying and confusing.
OK. Should I turn verbose off by default, or should I make verbose less verbose, or introduce several degrees of verbosity?
Before:
* (require 'sb-rotate-byte) ("SB-ROTATE-BYTE" "ASDF")
After:
* (require 'sb-rotate-byte)
; Loading #<CL-SOURCE-FILE "sb-rotate-byte" "package"> ; Loading #<CL-SOURCE-FILE "sb-rotate-byte" "compiler"> ; Loading #<CL-SOURCE-FILE "sb-rotate-byte" "vm" "x86-64-vm"> ; Loading #<MODULE "sb-rotate-byte" "vm"> ; Loading #<CL-SOURCE-FILE "sb-rotate-byte" "rotate-byte"> ; Loading #<SYSTEM "sb-rotate-byte"> ("SB-ROTATE-BYTE")
More than one project has something like this in the .asd:
#+sbcl (require 'some-sbcl-thing)
There isn't a good way to intercede to make these non-verbose, is there?
We could make require explicitly use :verbose nil. Probably should, too. Only reason I didn't do it before was out of conservatism.
I would prefer to see nothing at all in that circumstance, except the return value.
Is T a proper return value?
Also, the display of the object as a "CL-SOURCE-FILE" is confusing. It's actually loading the FASL. (I know why it prints the way it does, but it's still confusing.)
I suppose I could specialize the description for source files and for modules. What about the following when we're verbose: ; Loading FASL for #<CL-SOURCE-FILE "sb-rotate-byte" "package"> ; Loading FASL for #<CL-SOURCE-FILE "sb-rotate-byte" "compiler"> ; Loading FASL for #<CL-SOURCE-FILE "sb-rotate-byte" "vm" "x86-64-vm"> ; Loaded #<MODULE "sb-rotate-byte" "vm"> ; Loading FASL for #<CL-SOURCE-FILE "sb-rotate-byte" "rotate-byte"> ; Loaded #<SYSTEM "sb-rotate-byte"> [ François-René ÐVB Rideau | Reflection&Cybernethics | http://fare.tunes.org ] No woman ever falls in love with a man unless she has a better opinion of him than he deserves. — Edgar Watson Howe
Faré <fahree@gmail.com> writes:
On 26 April 2011 12:36, Zach Beane <xach@xach.com> wrote:
PPS: I just made asdf more verbose in verbose mode. However, verbose mode is the default, so this may or may not be annoying. Please tell me.
Now that I've seen it, I do find it both annoying and confusing.
OK. Should I turn verbose off by default, or should I make verbose less verbose, or introduce several degrees of verbosity?
I would be pretty happy if the old behavior was reinstated, and nothing else was changed. Was there a specific problem that prompted the change in behavior? Zach
OK. Should I turn verbose off by default, or should I make verbose less verbose, or introduce several degrees of verbosity?
I would be pretty happy if the old behavior was reinstated, and nothing else was changed.
OK. Reverted in 2.014.12, with some additional changes.
Was there a specific problem that prompted the change in behavior?
I sometimes want to debug a ASDF build, or find out what file a set of style-warnings come from, etc. At ITA we use ancillary methods that call explain. I wanted to have something similar part of ASDF itself. I guess however, that the fact that ASDF is "verbose" by default, makes that more annoying than helpful. What about making ASDF *not* verbose by default? Does anyone simultaneously care to have ASDF print the little it currently prints yet not the progress report I was printing? [ François-René ÐVB Rideau | Reflection&Cybernethics | http://fare.tunes.org ] Seems like this farmer purchased an old, run-down, abandoned farm with plans to turn it into a thriving enterprise. The fields are grown over with weeds, the farmhouse is falling apart, and the fences are collapsing all around. During his first day of work, the town preacher stops by to bless the man's work, praying, "May you and God work together to make this the farm of your dreams!" A few months later, the preacher stops by again to call on the farmer. Lo and behold, it's like a completely different place — the farm house is completely rebuilt and in excellent condition, there is plenty of cattle and other livestock happily munching on feed in well-fenced pens, and the fields are filled with crops planted in neat rows. "Amazing!" the preacher says. "Look what God and you have accomplished together!" "Yes, reverend," replies the farmer, "but remember what the farm was like when God was working it alone!"
On 4/26/11 Apr 26 -1:06 PM, Faré wrote:
OK. Should I turn verbose off by default, or should I make verbose less verbose, or introduce several degrees of verbosity?
I would be pretty happy if the old behavior was reinstated, and nothing else was changed.
OK. Reverted in 2.014.12, with some additional changes.
Was there a specific problem that prompted the change in behavior?
I sometimes want to debug a ASDF build, or find out what file a set of style-warnings come from, etc. At ITA we use ancillary methods that call explain. I wanted to have something similar part of ASDF itself. I guess however, that the fact that ASDF is "verbose" by default, makes that more annoying than helpful.
What about making ASDF *not* verbose by default? Does anyone simultaneously care to have ASDF print the little it currently prints yet not the progress report I was printing?
I have never found the ASDF message printing burdensome. But then, I don't ever build as many systems at once as Xach does. Is there some way to tell if this is other than a quicklisp-specific problem? If it is quicklisp-specific, could we just support a special configuration for QL that doesn't hide information from people using ASDF in a more limited environment? QL is almost defined as one where you don't expect the user to be able to debug parent systems. I'm a lot more familiar with /needing/ to debug parent systems! Best, r
Robert Goldman <rpgoldman@sift.info> writes:
I have never found the ASDF message printing burdensome. But then, I don't ever build as many systems at once as Xach does.
Is there some way to tell if this is other than a quicklisp-specific problem?
It's nothing Quicklisp-specific. Please see the message regarding (require 'sb-rotate-byte) for an example of the new verbosity introduced a couple commits ago. Zach
On 4/26/11 Apr 26 -4:40 PM, Zach Beane wrote:
Robert Goldman <rpgoldman@sift.info> writes:
I have never found the ASDF message printing burdensome. But then, I don't ever build as many systems at once as Xach does.
Is there some way to tell if this is other than a quicklisp-specific problem?
It's nothing Quicklisp-specific. Please see the message regarding (require 'sb-rotate-byte) for an example of the new verbosity introduced a couple commits ago.
Zach
Got it. So you didn't object to the old level of verbosity? I'm confused because it seemed like the alternatives were new, greater verbosity, versus silence, neither of which seems very appealing to me. I guess the challenge that's specific to ql is that you'd like to be able to throttle verbosity, but the use of invocations of LOAD-SYSTEM inside .asd files (rather than in depends-on) breaks that, right? Is the right answer (horrors! ;->) a dynamically bound verbosity-controller? Best, r
Robert Goldman <rpgoldman@sift.info> writes:
Got it. So you didn't object to the old level of verbosity?
No, which is why I wrote that I'd be happy if the old behavior was restored.
I'm confused because it seemed like the alternatives were new, greater verbosity, versus silence, neither of which seems very appealing to me.
Those are indeed both bad choices.
I guess the challenge that's specific to ql is that you'd like to be able to throttle verbosity, but the use of invocations of LOAD-SYSTEM inside .asd files (rather than in depends-on) breaks that, right? Is the right answer (horrors! ;->) a dynamically bound verbosity-controller?
Any change that I can ignore, and still get the current appearance, behavior, and semantics, is one I don't mind. Zach
No, which is why I wrote that I'd be happy if the old behavior was restored. It has been restored in 2.014.12.
For 2.014.13, I'm considering making asdf not verbose by default. I'm wondering what you think of it. Nevertheless, I think SBCL should be changed to explicitly use :verbose nil when it loads a .asd from another one -- and/or it should be relying on the new :defsystem-depends-on.
I'm confused because it seemed like the alternatives were new, greater verbosity, versus silence, neither of which seems very appealing to me.
Those are indeed both bad choices.
What's wrong with (mostly) silence? What about verbosity levels, with an integer indicating what level of messages to get?
Any change that I can ignore, and still get the current appearance, behavior, and semantics, is one I don't mind.
OK, what do you positively like about the current output, that you want to preserve? Semantics, I think we all agree must be preserved -- though sometimes I make mistake in interpreting it -- and I am ever so grateful to you for your exhaustive testing. [ François-René ÐVB Rideau | Reflection&Cybernethics | http://fare.tunes.org ] Just because your semi-free country government is evil doesn't mean "native" governments have a right to exist and enslave "their" people. — Faré
Faré <fahree@gmail.com> writes:
No, which is why I wrote that I'd be happy if the old behavior was restored. It has been restored in 2.014.12.
For 2.014.13, I'm considering making asdf not verbose by default. I'm wondering what you think of it.
I don't like these kinds of user-visible changes, because if someone liked the old behavior, or was at least accustomed to it, they now have to do research and become involved in ASDF to learn how to get the previous behavior.
Nevertheless, I think SBCL should be changed to explicitly use :verbose nil when it loads a .asd from another one -- and/or it should be relying on the new :defsystem-depends-on.
SBCL doesn't do that, user code does. It would be nice if people took advantage of new features where useful. It would be nice if keeping the status quo didn't require *any* updates or changes to existing user code.
I'm confused because it seemed like the alternatives were new, greater verbosity, versus silence, neither of which seems very appealing to me.
Those are indeed both bad choices.
What's wrong with (mostly) silence?
I object to making changes that require updates to existing code or configuration to maintain previous desired or at least customary appearance and output.
What about verbosity levels, with an integer indicating what level of messages to get?
That sounds fine, as long as the previous behavior is the default.
Any change that I can ignore, and still get the current appearance, behavior, and semantics, is one I don't mind.
OK, what do you positively like about the current output, that you want to preserve?
Using ASDF lately is a little like living in a house with an insomniac interior decorator who putters around rearranging the furniture while I sleep. While I might not have particularly liked the previous behavior, it's been that way for a long time and I'm used to it. To stretch this metaphor way too far, I'd rather wake up and find a note that says "I installed a set of hidden furniture-rearrangement servos in the floor - to see the nice new idea I had, push the tiny little button by the door." Zach
I don't like these kinds of user-visible changes, because if someone liked the old behavior, or was at least accustomed to it, they now have to do research and become involved in ASDF to learn how to get the previous behavior.
i don't really have an opinion on the specific topic, and i don't mean to annoy... but what if someone *didn't* like the behavior? then they would have to do research and become involved in ASDF to learn how to get rid of the current behavior (notice the almost exact same wording of a counter argument). just pointing out that to me it seems like you're simply stating your personal preferences and/or dislike for change. it's a common human behavior and there's nothing wrong with that, especially in your case Zach: as author of quicklisp you obviously try to minimize headaches caused by changes to ASDF. but if this really is the case then we should be aware of that because it often hiders technical discussions and development of software systems (the closest example that comes to my mind is what is happening to Slime. or really, what is *not* happening to it...) the ultimate backwards compatibility is not having had even started the project in question (modulo my english grammar deficiencies). also worth noting that people much-much more often speak up of annoyance than being pleased by a change. </rant> -- attila Notice your eroding (digital) freedom, and do something about it! PGP: 2FA1 A9DC 9C1E BA25 A59C 963F 5D5F 45C7 DFCD 0A39 OTR XMPP: 8647EEAC EA30FEEF E1B55146 573E52EE 21B1FF06 BitCoin: 154uf86Vd9rpjMULd9CXa7nVwikknYZJiB
I can see both sides of this argument. But I think Daniel is right in many ways --- ASDF is way down at the bottom of the dependency stack for the common lisp community and so the expectation of it remaining stable is pretty important. Probably, though, to avoid stagnation, we need to soon begin a branch that will lead us to ASDF 3. We need to find someone who wishes to lead us on that journey, though, since Faré has announced his desire to move on to something different. best, r
On 1 May 2011 14:11, Robert Goldman <rpgoldman@sift.info> wrote:
I can see both sides of this argument. But I think Daniel is right in many ways --- ASDF is way down at the bottom of the dependency stack for the common lisp community and so the expectation of it remaining stable is pretty important.
Yes.
Probably, though, to avoid stagnation, we need to soon begin a branch that will lead us to ASDF 3.
Note: in my mind, ASDF 3 is XCVB. Which is working great, but still requires love before it correctly supports all the maintained platforms that ASDF does and provides better failure modes than dumping a backtrace on syntax errors.
We need to find someone who wishes to lead us on that journey, though, since Faré has announced his desire to move on to something different.
If you think there's long term future in the current ASDF architecture, you'll need someone else than I, indeed. If you want to give a try to XCVB, you know where to find it. [ François-René ÐVB Rideau | Reflection&Cybernethics | http://fare.tunes.org ] Life is like an onion: you peel off layer after layer, then you find there is nothing in it.
Faré wrote:
What's wrong with (mostly) silence?
What about verbosity levels, with an integer indicating what level of messages to get?
These are probably good things, but as Zach mentioned, recently ASDF has started dragging users through internal development. Its a gripe I have about Slime and some other key libraries, so you are in good company, but I cannot follow "the bleeding edge" as a matter of habit. Releases broadly fall into three social categories. Micro releases only fix internal bugs and have no other user visibility. Minor releases modify behavior but should be compatible with previous releases, still requiring no user interaction. Major releases require the user to understand what's changed and modify code or config files. Major releases need to happen slowly to minimize end-user churn, ensure proper vetting, etc. Major releases often come with nice ChangeLog entries summarizing what to expect. I think many recent ASDF changes have been good, but they are falling into the major release category. They can't be going into monthly Quicklisp or SBCL updates or (your favorite distribution channel here). This is where "trunk" and "release/stable branches" work fairly well. Tagging trunk is not equivalent. If a project does not have the resources to maintain a separate release branch, then they should simply tag major releases at a slower rate. People who want the latest can always look directly at trunk. Discussion can still be happening on list. Its just that the end user should have to be involved. Thanks for your work, Daniel
On 27 April 2011 12:57, <dherring@tentpost.com> wrote:
These are probably good things, but as Zach mentioned, recently ASDF has started dragging users through internal development. Its a gripe I have about Slime and some other key libraries, so you are in good company, but I cannot follow "the bleeding edge" as a matter of habit.
Uh - I've been trying my darned best to make "release" versions stable, e.g. 2.010, 2.011, 2.012, 2.013, 2.014. I may not have been as successful at it as I'd like, but so far as I can tell, all the complaints (which are justified and most welcome) had to do with non-release versions, e.g. 2.014.8, etc. That's not to say that I couldn't be doing better, but yes, 1) trying trunk will give you regressions like that. 2) if you're a power user like Zach, you unhappily have to test with trunk to weed out the problems, or the bugs will make it into a release. 3) Recent bugs and feature requests have prompted some refactorings, and along the way I've made changes that didn't make everyone happy. 4) So far as I can tell, we're still on a good path to making the next stable release satisfactory to everyone. If this is not your perception, then maybe we can have a discussion on the details of what went wrong and how to avoid the same in the future.
Releases broadly fall into three social categories. Micro releases only fix internal bugs and have no other user visibility. Minor releases modify behavior but should be compatible with previous releases, still requiring no user interaction. Major releases require the user to understand what's changed and modify code or config files. Major releases need to happen slowly to minimize end-user churn, ensure proper vetting, etc. Major releases often come with nice ChangeLog entries summarizing what to expect.
Agreed.
I think many recent ASDF changes have been good, but they are falling into the major release category. They can't be going into monthly Quicklisp or SBCL updates or (your favorite distribution channel here).
Do you call 2.014 vs 2.011 "major"? Certainly, I haven't been pushing for development versions like 2.014.12 to be put into either Quicklisp or SBCL. That said, bugfixes or features required for Quicklisp may have pushed Xach to upgrade anyway. And he is in the unhappy situation of being my first line tester for many systems.
This is where "trunk" and "release/stable branches" work fairly well. Tagging trunk is not equivalent. If a project does not have the resources to maintain a separate release branch, then they should simply tag major releases at a slower rate.
In my terminology, I count 2.000 as a major release, 2.014 as a minor release, and 2.014.13 as a development version. I've done a major release once, last year. I've had 14 minor releases since, and hundreds of develop versions. I'm tagging minor releases about once a month, and pushing for them to be adopted by various vendors. If any of this is out of synch with your expectations, please be more specific in your criticism.
People who want the latest can always look directly at trunk. Discussion can still be happening on list.
That's also my understanding.
Its just that the end user should have to be involved. I don't understand what THAT means.
[ François-René ÐVB Rideau | Reflection&Cybernethics | http://fare.tunes.org ] You can tell whether a man is clever by his answers. You can tell whether a man is wise by his questions. — Naguib Mahfouz
Faré <fahree@gmail.com> writes:
On 27 April 2011 12:57, <dherring@tentpost.com> wrote:
These are probably good things, but as Zach mentioned, recently ASDF has started dragging users through internal development. Its a gripe I have about Slime and some other key libraries, so you are in good company, but I cannot follow "the bleeding edge" as a matter of habit.
Uh - I've been trying my darned best to make "release" versions stable, e.g. 2.010, 2.011, 2.012, 2.013, 2.014. I may not have been as successful at it as I'd like, but so far as I can tell, all the complaints (which are justified and most welcome) had to do with non-release versions, e.g. 2.014.8, etc.
That's not to say that I couldn't be doing better, but yes, 1) trying trunk will give you regressions like that. 2) if you're a power user like Zach, you unhappily have to test with trunk to weed out the problems, or the bugs will make it into a release. 3) Recent bugs and feature requests have prompted some refactorings, and along the way I've made changes that didn't make everyone happy. 4) So far as I can tell, we're still on a good path to making the next stable release satisfactory to everyone.
That's my impression as well. My primary concern is that, if I don't take the time to try out the minor commits, a change like the verbosity change would just end up in a release. In general, I'd rather see opt-in behavior, which I can ignore until persuaded otherwise, than opt-out. Zach
On 27 April 2011 14:14, Zach Beane <xach@xach.com> wrote:
My primary concern is that, if I don't take the time to try out the minor commits, a change like the verbosity change would just end up in a release. In general, I'd rather see opt-in behavior, which I can ignore until persuaded otherwise, than opt-out.
Well I suspected that the change in verbosity might raise comments, so I raised the question on the list. Most changes you can ignore -- or so I believe when I make them -- but I *have* been wrong in the past. *Someone* has to do the testing. It so happens that that person is currently you. If you want to automate away some of the drudgery, you might help me setup a server so I could do the testing myself before I release; but even then, nothing will fully replace the human eye inspecting the results. In any case, thanks a lot for your hard work and attention. [ François-René ÐVB Rideau | Reflection&Cybernethics | http://fare.tunes.org ] My hobby of not attending meetings about recycling saves more energy than your hobby of recycling. — John McCarthy
On Wed, 27 Apr 2011, Faré wrote:
On 27 April 2011 12:57, <dherring@tentpost.com> wrote:
These are probably good things, but as Zach mentioned, recently ASDF has started dragging users through internal development. Its a gripe I have about Slime and some other key libraries, so you are in good company, but I cannot follow "the bleeding edge" as a matter of habit.
Uh - I've been trying my darned best to make "release" versions stable, e.g. 2.010, 2.011, 2.012, 2.013, 2.014. I may not have been as successful at it as I'd like, but so far as I can tell, all the complaints (which are justified and most welcome) had to do with non-release versions, e.g. 2.014.8, etc.
In a nutshell, things like changes to inputs (enforcing contracts), outputs (changing what's printed) and internal behaviors (e.g. path names vs objects) are very sensitive in ASDF. There are many users of the system, and a good number were tuned to the implementation instead of any specification. ASDF's design leaks all sorts of details. While you are tagging "minor" releases roughly once a month, since there are no separate trunk/release branches, all the changes appear in each month's release. Thus I think you either need to restrict yourself to truly minor changes (not good for development), only make major releases once a year or so, or split development and only backport critical fixes and clean API extensions to the release branch. In short, I wasn't really aware that people were actively seeking enhancements, but I have seen a number of potentially breaking changes, and the current development cycle means people have to catch them every month.
I think many recent ASDF changes have been good, but they are falling into the major release category. They can't be going into monthly Quicklisp or SBCL updates or (your favorite distribution channel here).
Do you call 2.014 vs 2.011 "major"?
By number, no. By content, ...
From a quick scan, here are a few good-looking changes that might count as major.
eb1ed61 Substituted (default-directory) for *default-pathname-defaults* 09b9b8a Binding of *default-pathname-defaults* [special variables in CL have high visibility] 2.012.2: cleanup name of cache directory for clisp (remove trailing dash) [the user should be told to rename or delete the old directory]
Its just that the end user should have to be involved. I don't understand what THAT means.
I think I meant "should not have". In other words, end users should be able to trustingly accept minor and micro versions, generally without even reading a changelog. Their grey matter should only need to kick in on the major release cycles. This also allows other people (e.g. debian or sbcl) to safely make the upgrade choice for them. - Daniel
NB: Meh, shouldn't have gone into this long defense. I somehow took dherring's remarks personally and don't have the guts to not post this reply after writing it. Please ignore.
In a nutshell, things like changes to inputs (enforcing contracts), outputs (changing what's printed) and internal behaviors (e.g. path names vs objects) are very sensitive in ASDF.
I've tried to always support previously documented accepted inputs. Sometimes, it was not sufficient - and I realized the hard way that I had to support and document previous practice, too. As for what's printed - I've added a bit of output, at least in the case of upgrade, and no one's complained. In general, I'm in the opinion that since ASDF's default "verbose" output is not verbose enough to help diagnose any issue, it's as good as useless, and it should be silenced by default, and made much more verbose when in "verbose" mode — but obviously, this doesn't fly with a lot of existing users. Anyway, I understand the concern, and my position is that unless it's consensual (at least amongst concerned users on this list), a compatibility-breaking change in output is not kosher — and so I do make suggestions once in a while, usually with actual code committed, usually to be rebuffed, with the change backed out before the next stable release.
There are many users of the system, and a good number were tuned to the implementation instead of any specification. ASDF's design leaks all sorts of details.
I should know. A huge part of my job in taking ASDF from 1.369 to 2.000 and beyond has been to replace implementation-dependent behavior and underspecified interfaces with well-defined portable semantics.
While you are tagging "minor" releases roughly once a month, since there are no separate trunk/release branches, all the changes appear in each month's release.
I tried to have two branches — it amounted to a lot more work and confusion for no actual benefit whatsoever: *all* the work ended being "backported" to the stable branch anyway. Indeed, there are no new features to speak of, only bug fixes and that prompt refactorings and API tweaks: one corner case of system+implementation+OS leads to having to refactor the code, fix an existing interface and expose the new, fixed, one. These changes all too often introduce bugs that cascade for a few commits before stabilizing. I try to select the time for a stable release for when there is no more pending fix, cascaded or not, and before I do any sizable refactoring. Unhappily, absent wider testing, I often miss some corner case, and sometimes need to issue patches right after a "stable" release. Of course, I make mistakes along the way — but that has nothing to do with being "development" vs "stable". It has to do with any change at all, and it's why I encourage power users to test development versions. As for my actual ideas for new features: they all go into XCVB, which is getting more usable and more portable every week, thank you for asking, but not yet universally good enough to justify casual users migrating from ASDF.
Thus I think you either need to restrict yourself to truly minor changes (not good for development), only make major releases once a year or so, or split development and only backport critical fixes and clean API extensions to the release branch.
"Development" so far has been prompted mainly by one or the other corner cases emerging from having to provide a portable interface supporting 14 underlying implementations on more than 3 OSes. Minor changes, bug fixes and exposing APIs after cleaning them up is *ALL* I'm doing with ASDF. I'm sorry I'm not doing it without occasional breakage, hopefully breakage that remains unreleased (but unhappily, not always, as I do make mistakes). Then again, if you claim you can do a better job at maintainership, I'm most willing to pass on the tiara to the next princess.
In short, I wasn't really aware that people were actively seeking enhancements, but I have seen a number of potentially breaking changes, and the current development cycle means people have to catch them every month.
What do you propose? Less frequent releases? How would that help, given the rate of change? Less frequent changes? Considering that "development" is mostly driven by fixes to reported bugs, with cleanups attempted along the way, that really means, don't fix bugs so fast. Or maybe you're suggesting to try fewer cleanups as I fix bugs. That's possible, but would make the code so disgusting that I would quickly throw up and throw down the towel. — If you think ASDF can be maintained this way, you'll have to do it yourself.
Do you call 2.014 vs 2.011 "major"?
By number, no. By content, ...
From a quick scan, here are a few good-looking changes that might count as major.
eb1ed61 Substituted (default-directory) for *default-pathname-defaults* 09b9b8a Binding of *default-pathname-defaults* [special variables in CL have high visibility]
For instance the first changes you mentionned happened for 2.011.1; they are an improvement to the way we parse our configuration file. There is no negative impact whatsoever to any user, since it only affects people who previously were frustrated in desiring to write location-independent configuration files for their directory hierarchies, or who were using #. in configuration files to work around this or other limitations, and will be able to trust the *default-pathname-defaults* to be bound to an absolute directory pathname.
2.012.2: cleanup name of cache directory for clisp (remove trailing dash) [the user should be told to rename or delete the old directory]
CLISP was returning non-sensical results for a component of implementation-identifier. A user complained. I fixed in 2.012.2. This is slightly incompatible, but not in a way that should ever matter negatively to the end user, except for a slight waste of cache space, if he never cleans it manually. And it's not more incompatible than a wider change I made in 2.142 (~2.009.8) to implementation-identifier to keep strings shorter, which is necessary to make some Windows implementations happy, and another issue reported by a user. If you want a "major" change, consider rather how I am now pre-caching source-registry results, and you have to re-run (asdf:initialize-source-registry) for ASDF to see newly-installed .asd files. Previously, the behavior was left unspecified, and you could install a new .asd file in a previously-configured directory that already had .asd files but not in a new sub-directory or one previously without a .asd file. This semantic change was prompted by a request from Xach to use pre-caching in quicklisp. Now he can do it by simply using the source-registry, or rolling his own alternative with the same simplified interface.
[...] end users should be able to trustingly accept minor and micro versions, generally without even reading a changelog. Their grey matter should only need to kick in on the major release cycles. This also allows other people (e.g. debian or sbcl) to safely make the upgrade choice for them.
I agree. And I believe that this is the case: none of the changes I am making should be *negatively* impacting anyone. Negative impacts come from: 1- bugs. 2- my failure to realize the (usually un(der)specified) API I'm touching is actually being relied upon by clients. Oops. My bad. Please help me test before release. [ François-René ÐVB Rideau | Reflection&Cybernethics | http://fare.tunes.org ] Quality means doing it right when no one is looking. — Henry Ford
Faré wrote:
NB: Meh, shouldn't have gone into this long defense. I somehow took dherring's remarks personally and don't have the guts to not post this reply after writing it. Please ignore.
I apologize for causing any stress. I worry about "looking the gift horse in the mouth" and was hoping to provide only helpful criticism. To summarize my view, - ASDF changes can be tricky, and the success of ASDF causes high visibility - Recent changes have been good for ASDF with a few unintended consequences - Please slow down the rate for pushing updates into SBCL, etc. The new upgrade features make it easier for end users to get what they need. - Please keep up the good work and feel free to weight my feedback based on my level of contribution (i.e. very, very low right now) Thanks for your work, Daniel
On 28 April 2011 11:55, <dherring@tentpost.com> wrote:
- Please slow down the rate for pushing updates into SBCL, etc. The new upgrade features make it easier for end users to get what they need.
Well, as for SBCL in particular, it has been upgraded five times since ASDF 2 (including once by mistake to an experimental version, which was promptly fixed). And it's still at 2.010 from 6 months ago, which is a stable version, but a lot of small improvements have been made since, including one to better cope with a specific SBCL developer's use case: SBCL_HOME being relative (in 2.012.9, 2.012.10). I will certainly request an upgrade to 2.015 when it's released. [ François-René ÐVB Rideau | Reflection&Cybernethics | http://fare.tunes.org ] You worry too much about your job. Stop it. You're not paid enough to worry.
participants (6)
-
Attila Lendvai -
Daniel Herring -
dherring＠tentpost.com
-
Faré -
Robert Goldman -
Zach Beane