It seems that any system Y associated with a name X must have its name be of the form X/Y. For example, when you build "cl-ppcre", you get this warning:
Please only define "cl-ppcre" and secondary systems with a name starting with "cl-ppcre/" (e.g. "cl-ppcre/test") in that file.
I've seen this complaint for quite a few systems already. What's the need for this, and is it really worth nagging users of all these systems that have existed in many cases for years and have worked perfectly well without following the new convention? What great functionality are we getting for this?
Thanks, -Mark
What great functionality are we getting for this?
you can find and load a system without pre-processing every .asd file available.
and have worked perfectly well without following the new convention?
was it, though?
it took multiple seconds to read and process every .asd on my system before this change.
-- • attila lendvai • PGP: 963F 5D5F 45C7 DFCD 0A39 -- “In a democracy, mass opinion creates power. Power diverts funds to the manufacturers of opinion, who manufacture more, etc. […] This feedback loop generates a playing field on which the most competitive ideas are not those which best correspond to reality, but those which produce the strongest feedback.” — Mencius Moldbug
On Tue, Dec 11, 2018 at 2:09 PM Mark H. David mhd@yv.org wrote:
It seems that any system Y associated with a name X must have its name be of the form X/Y. For example, when you build "cl-ppcre", you get this warning:
Please only define "cl-ppcre" and secondary systems with a name starting with "cl-ppcre/" (e.g. "cl-ppcre/test") in that file.
I've seen this complaint for quite a few systems already. What's the need for this, and is it really worth nagging users of all these systems that have existed in many cases for years and have worked perfectly well without following the new convention? What great functionality are we getting for this?
"Worked perfectly well", except that 1- if you wanted to find a system not properly named, you had to make sure to have read the relevant .asd file beforehand. 2- if someone defined two systems with the same name in two different files, then ASDF 2.014 could loop infinitely, and even 2.016 or later might survive but behave in unstable way depending on how changes may cause one system to be loaded instead of the other, then reloaded, etc.
With ASDF 2.27 (ASDF 3 pre-release), a solution was offered to define multiple systems in one .asd file in a safe way, and the old way was deprecated ever since, though a warning has only been issued since ASDF 3.2.0.
ASDF is still backward-compatible. You can hush the warning if you want—though it importantly tells you which systems could use a new maintainer.
—♯ƒ • François-René ÐVB Rideau •Reflection&Cybernethics• http://fare.tunes.org A true intellectual is a man who, after reading a book and being convinced by its arguments, will shoot someone or, more likely, order someone shot. — John McCarthy
1- if you wanted to find a system not properly named, you had to make sure to have read the relevant .asd file beforehand.
For subsystems that's a perfectly reasonable case.
2- if someone defined two systems with the same name in two different files, then ASDF 2.014 could loop infinitely, and even 2.016 or later might survive but behave in unstable way depending on how changes may cause one system to be loaded instead of the other, then reloaded, etc.
If that were bugs which were fixable, then bringing up old ASDF releases doesn't make a compelling argument for prohibiting behavior.
ASDF is still backward-compatible. You can hush the warning if you want—though it importantly tells you which systems could use a new maintainer.
That is a very unfair statement. I'm not even sure how to comment it. I'll only note that not willing to change a code without a good reason (because issueing this warning is a fad) is conservative in a good sense of this word.
-- Daniel
I specifically don't update cl-ppcre.asd, so that these messages annoy as many people as possible and they complain to ASDF. cl-ppcre/test works perfectly fine, nobody calls find-system on it, it's only ever used via (asdf:test-system :cl-ppcre), which still works.
ASDF is an entrenched monopoly, there's no competition and you can't just choose some other system to use. So it can change its behavior with every release and all the users can do is just to suck it up.
On Tue, Dec 11, 2018 at 10:09 PM Mark H. David mhd@yv.org wrote:
It seems that any system Y associated with a name X must have its name be of the form X/Y. For example, when you build "cl-ppcre", you get this warning:
Please only define "cl-ppcre" and secondary systems with a name starting with "cl-ppcre/" (e.g. "cl-ppcre/test") in that file.
I've seen this complaint for quite a few systems already. What's the need for this, and is it really worth nagging users of all these systems that have existed in many cases for years and have worked perfectly well without following the new convention? What great functionality are we getting for this?
Thanks, -Mark
sorry Stas, but i just had to dishonestly (?) cut your mail... :) with the hope that it will incite some reflection:
I specifically don't update cl-ppcre.asd [...]
[...] and all the users can do is just to suck it up.
FTR, there's an open PR with discussion: https://github.com/edicl/cl-ppcre/pull/30
i understand that "it was him who made the first change!", and "everything would still be fine if he doesn't make a change!"... but i'm not sure it's reasonable to expect this kind of conservatism in a collaborative space. old ASDF was a piece of software that wasn't designed for the tasks it is used for today (as in its API, let alone its implementation), and that was causing a lot of headache to "the users" you seem to be defending above.
i don't have a strong opinion about this specific warning. to be honest, if i was the ASDF maintainer, it would be fine for me if the warning was off by default, and i would only turn it on in my own CI to send out the PR's and/or warnings to the relevant maintainers, and then let old and/or conservative libs continue to misbehave as they did with the old ASDF.
but it's quite disheartening to see all the trash-talk against the refactored ASDF. i may be just one user, but the cleanup of ASDF helped me tremendously! maybe i was using more deps than usual (~100), and had to deal with live systems and whatnot that most CL users don't do...? but prior to the ASDF cleanup i had wasted countless hours hunting build-related bugs only to realize that there wasn't any bug (in my code), and by getting used to mindlessly rebuilding from scratch *any time* something strange happened.
conservatism, and the general hostility, has always troubled me in the CL community, but i don't have a dog in this fight currently, or maybe even anymore, so i better cut the talk...
good luck resolving whatever needs to be resolved for a better tomorrow!
On Wed, Dec 12, 2018 at 2:05 AM Attila Lendvai attila@lendvai.name wrote:
sorry Stas, but i just had to dishonestly (?) cut your mail... :) with the hope that it will incite some reflection:
I specifically don't update cl-ppcre.asd [...]
[...] and all the users can do is just to suck it up.
FTR, there's an open PR with discussion: https://github.com/edicl/cl-ppcre/pull/30
i understand that "it was him who made the first change!", and "everything would still be fine if he doesn't make a change!"... but i'm not sure it's reasonable to expect this kind of conservatism in a collaborative space. old ASDF was a piece of software that wasn't designed for the tasks it is used for today (as in its API, let alone its implementation), and that was causing a lot of headache to "the users" you seem to be defending above.
i don't have a strong opinion about this specific warning. to be honest, if i was the ASDF maintainer, it would be fine for me if the warning was off by default, and i would only turn it on in my own CI to send out the PR's and/or warnings to the relevant maintainers, and then let old and/or conservative libs continue to misbehave as they did with the old ASDF.
but it's quite disheartening to see all the trash-talk against the refactored ASDF. i may be just one user, but the cleanup of ASDF helped me tremendously! maybe i was using more deps than usual (~100), and had to deal with live systems and whatnot that most CL users don't do...? but prior to the ASDF cleanup i had wasted countless hours hunting build-related bugs only to realize that there wasn't any bug (in my code), and by getting used to mindlessly rebuilding from scratch *any time* something strange happened.
conservatism, and the general hostility, has always troubled me in the CL community, but i don't have a dog in this fight currently, or maybe even anymore, so i better cut the talk...
There's not even any conservatism here. Nothing in the behavior has changed for better or worse (at least in the scope of cl-ppcre.asd), the only adverse effect is the warning. I apply that PR, and asdf:test-system still works exactly the same, as far as I can tell. I'm not against the cl-ppcre/test thingy, just the warning for cl-ppcre-test. What happens when I update cl-ppcre.asd and other libraries? Now I get five and not ten things warning me about a non-issue. So my only course of action to get to zero warnings is to actually have as many warnings as possible so that other people start complaining, and not to barge in to working for years projects and demand for new maintainers "cause I did a thing".
oh, Stas, something important that i forgot to include:
i highly appreciate your contributions to the CL ecosystem! please, don't take whatever i wrote as anything personal. e.g. i still read some of your SBCL commits out of sheer curiosity, even though i rarely fire up a CL nowadays...
peace,
Thanks, Attila. I must say that as the remaining maintainer, this kind of complaining doesn't make me excited about doing my ASDF chores.
This warning won't go away on my watch. Fare's change to support "slashy" systems is an elegant way to handle subsystems.
I'm sorry that some people used hyphens for subsystems, and some for just word separation, but sometimes in the interests of clarity someone loses.
Eventually I will just hack in a restart that muffles this warning specifically for cl-ppcre, and then we will all have to find something else to be pissed off about....
But right now I'm mostly working in Python, where no one's being an ingrate, so I have better things to do with my time.
Sent from my iPad
On Dec 11, 2018, at 13:04, Attila Lendvai attila@lendvai.name wrote:
sorry Stas, but i just had to dishonestly (?) cut your mail... :) with the hope that it will incite some reflection:
I specifically don't update cl-ppcre.asd [...]
[...] and all the users can do is just to suck it up.
FTR, there's an open PR with discussion: https://github.com/edicl/cl-ppcre/pull/30
i understand that "it was him who made the first change!", and "everything would still be fine if he doesn't make a change!"... but i'm not sure it's reasonable to expect this kind of conservatism in a collaborative space. old ASDF was a piece of software that wasn't designed for the tasks it is used for today (as in its API, let alone its implementation), and that was causing a lot of headache to "the users" you seem to be defending above.
i don't have a strong opinion about this specific warning. to be honest, if i was the ASDF maintainer, it would be fine for me if the warning was off by default, and i would only turn it on in my own CI to send out the PR's and/or warnings to the relevant maintainers, and then let old and/or conservative libs continue to misbehave as they did with the old ASDF.
but it's quite disheartening to see all the trash-talk against the refactored ASDF. i may be just one user, but the cleanup of ASDF helped me tremendously! maybe i was using more deps than usual (~100), and had to deal with live systems and whatnot that most CL users don't do...? but prior to the ASDF cleanup i had wasted countless hours hunting build-related bugs only to realize that there wasn't any bug (in my code), and by getting used to mindlessly rebuilding from scratch *any time* something strange happened.
conservatism, and the general hostility, has always troubled me in the CL community, but i don't have a dog in this fight currently, or maybe even anymore, so i better cut the talk...
good luck resolving whatever needs to be resolved for a better tomorrow!
-- • attila lendvai • PGP: 963F 5D5F 45C7 DFCD 0A39 -- “The more artificial taboos and restrictions there are in the world, the more the people are impoverished…. The more that laws and regulations are given prominence, the more thieves and robbers there will be.” — Lao Tzu (sixth century BC)
I have just created a merge request https://gitlab.common-lisp.net/asdf/asdf/merge_requests/116 that *specifically* quashes `BAD-SYSTEM-WARNING` from CL-PPCRE.
I'm sick and tired of Stas stoking anger about this issue, so I'm taking the social engineering handle away from him.
I welcome comments on this before I merge it to master.
After this I will just moderate all questions about `BAD-SYSTEM-WARNING` into the bit bucket. I don't have time left in my life expectancy for this crap.
R
:Attila old ASDF was a piece of software that wasn't designed for the tasks it is used for today (as in its API, let alone its implementation), and that was causing a lot of headache to "the users" you seem to be defending above.
Indeed, there has been a lot of mission creep in ASDF from ASDF 1 to ASDF 3.3, some of it is explained in my 2013 article http://fare.tunes.org/files/asdf3/asdf3-2014.html (search "Mission Creep" in the article; obviously not covering improvements since, but 3.1 stabilized many ASDF3 APIs and introduced package-inferred-system, while 3.2 had significant internal cleanups and enhancements including for bundles plus major documentation update, and 3.3 introduces proper support for staged builds).
i don't have a strong opinion about this specific warning. to be honest, if i was the ASDF maintainer, it would be fine for me if the warning was off by default, and i would only turn it on in my own CI to send out the PR's and/or warnings to the relevant maintainers, and then let old and/or conservative libs continue to misbehave as they did with the old ASDF.
Actually, I believe the warning is here for a good reason and should be there *by default*—to warn developers about their using a misfeature that was never officially supported nor documented, caused a lot of grief in the past, and has been deprecated for a long time with a better, simpler replacement (typically, replace a dash by a slash) that just works. I am glad that Robert agrees.
I also wouldn't be against introducing multiple levels of verbosity to ASDF (though I'm not willing to do the job for free anymore). Ideally, there would even be a way to get different verbosity levels for systems depending on whether they are mere dependencies (where you'd like to be able to disable all warnings after you pass QA) or software you're developing. But doing this kind of things right would introduce yet another backward-incompatible feature with an "interesting" migration path, which would open its own can of worms and a lot of time to be sunk in engineering, with no reward whatsoever to be expected from the community.
I've done my share of sending patches to unresponsive or ungrateful maintainers, warning people years ahead of an incompatible breakage, etc. I've also done my share of breaking things, even when I did run all the software through cl-test-grid. Mea culpa. [And, sure, we don't have automated enough cross-platform CI. That would be a great feature to add for a new maintainer.]
Anyway, I too am reminded why I chose to spend less time in the CL "community". The Racket, Gerbil Scheme, OCaml and Nix communities are far from perfect, but they are overall less dysfunctional, with less counterproductive passive aggression— oriented towards building new cool things that never existed before, rather than religiously preserving as is the perfect code of our ancestors (that never actually worked far beyond their obsolete use cases). At this point my opinions on ASDF are for historical value only, supposing a future maintainer wonders why the code is what it is rather than worships it as perfect godly gift never to be changed.
—♯ƒ • François-René ÐVB Rideau •Reflection&Cybernethics• http://fare.tunes.org "I'm not a procrastinator, I'm temporally challenged"
On Tue, Dec 11, 2018 at 3:56 PM Stas Boukarev stassats@gmail.com wrote:
I specifically don't update cl-ppcre.asd, so that these messages annoy as many people as possible and they complain to ASDF. cl-ppcre/test works perfectly fine, nobody calls find-system on it, it's only ever used via (asdf:test-system :cl-ppcre), which still works.
ASDF is an entrenched monopoly, there's no competition and you can't just choose some other system to use. So it can change its behavior with every release and all the users can do is just to suck it up.
Oh, so SBCL and other projects you work on never introduce new warnings, never deprecate old (mis)behavior? Good to know.
And, well, you can submit patches to ASDF, fork it, etc. If you showed goodwill, you might even have been coopted as maintainer. Or maybe you can convince the next "official" maintainer: whoever it is who is willing to put in the hard work to keep the thing running coherently on 17 different implementations and a wide range of inputs, with few thanks but many complaints from members of the community whatever they do or fail to do—or sometimes insults years later when no objection was made at the time the disputed behavior was initially discussed or introduced.
—♯ƒ • François-René ÐVB Rideau •Reflection&Cybernethics• http://fare.tunes.org Taxation with representation ain't so hot either. – Gerald Barzan
I have decided I'm tired of having my chain pulled.
I have dropped Stas from asdf-devel.common-lisp.net and will reject all messages from him in the future.
Also I will be ignoring direct mails from him in the future.
I'm done.
-
Attila Lendvai -
Daniel Kochmański -
Faré -
Mark H. David -
Robert Goldman -
Robert P. Goldman -
Stas Boukarev