Hi all! I just ran into something surprising. This is with ASDF 3.2.1, packaged with Quicklisp. I am using Named-Readtables. I had '*readtable*' set to a nonstandard readtable, then did quickload of a system unrelated to the one that defines and uses that readtable. The compilation failed; after I did '(in-readtable :common-lisp)' and tried again, it succeeded.
A quick glance at the ASDF source code shows that it binds '*readtable*' to a standard readtable in some cases, such as to read a '.asd' file, but not in 'uiop/lisp-build/compile-file*', nor in 'asdf/lisp-action:perform-lisp-compilation'. Wouldn't it make sense to do that?
-- Scott
Le 22/02/2024 à 05:14, Scott@sympoiesis.com a écrit :
Hi all! I just ran into something surprising. This is with ASDF 3.2.1, packaged with Quicklisp. I am using Named-Readtables. I had '*readtable*' set to a nonstandard readtable, then did quickload of a system unrelated to the one that defines and uses that readtable. The compilation failed; after I did '(in-readtable :common-lisp)' and tried again, it succeeded.
A quick glance at the ASDF source code shows that it binds '*readtable*' to a standard readtable in some cases, such as to read a '.asd' file, but not in 'uiop/lisp-build/compile-file*', nor in 'asdf/lisp-action:perform-lisp-compilation'. Wouldn't it make sense to do that?
-- Scott
IMO it would indeed make sense to do so.
And for other readtables than the default standard readtable, perhaps having a :readtable argument in defsystem or in the :file or :components clauses?
The thing is that some implementations have a non-standard default readtable, (eg. ccl has #/ #_ etc for FFI), and implementation-dependent sources may depend on those readtables without explicitely setting them in each file.
Just using (copy-readtable NIL) to get a standard readtable would break those files. (IMO rightly so, but let's be nice).
I think this is still true, but... we cannot be discussing ASDF 3.2.1 here. It was released almost 7 years ago, and for whatever reason Zach refuses to update. The current version is 3.3.7
Please get a more recent ASDF and try again. I *believe* that this behavior is still in place: Faré proposed the "syntax control" patch to fix this, but we decided we had no easy path to introducing it, because it would break other code (admittedly not of good style) that relies on the old behavior of having the readtable setting leak out of one file into another. See https://gitlab.common-lisp.net/asdf/asdf/-/merge_requests/86
Any non-backwards compatible modification to ASDF -- even to the extent of raising a deprecation warning -- has led to temper-tantrums in the CL community...
On 21 Feb 2024, at 22:14, Scott@sympoiesis.com wrote:
Hi all! I just ran into something surprising. This is with ASDF 3.2.1, packaged with Quicklisp. I am using Named-Readtables. I had '*readtable*' set to a nonstandard readtable, then did quickload of a system unrelated to the one that defines and uses that readtable. The compilation failed; after I did '(in-readtable :common-lisp)' and tried again, it succeeded.
A quick glance at the ASDF source code shows that it binds '*readtable*' to a standard readtable in some cases, such as to read a '.asd' file, but not in 'uiop/lisp-build/compile-file*', nor in 'asdf/lisp-action:perform-lisp-compilation'. Wouldn't it make sense to do that?
-- Scott
In the past, to introduce changes a fraction as compatibility-breaking (e.g. making utf-8 the default, or changing the internals of OPERATION), I would write up an explanation why the change is desired that anyone can read, discuss on the mailing list, write the code but keep it unmerged or disabled, make an announcement for the intended future breaking change, go over all of Quicklisp with Anton Vodonosov's cl-test-grid, locate all the offenders there, and send patches to each and everyone, wait a year if the old behavior used to be officially documented and supported, only a few weeks if it was a forbidden internals dependency, run the test again, give a last warning to those who didn't merge the patches, sometimes fork the systems left unmaintained to a new home, then finally make the change and announce it. And be ready to handle all the angry authors of proprietary code not in Quicklisp that you failed to previously contact.
For syntax-control (see my branch, that needs much love merging with 3.3.7), we never reached that point, if only because we were never satisfied with the complexity of the code (speaking for myself at least, I suspect for RPG also to a point, but he can opine otherwise if needed). There are many special variables beside *readtable* that control syntax (e.g. some systems try to make double-float the default—with "interesting" side effects to other systems compiled later, more subtle than the big obvious breakage when the readtable is wrong or corrupted). And users define more such variables as they extend the language. So now you want to maintain a dynamic list of symbols, some in packages not yet defined, that you want to track, save and restore. Next your users will want to bind the values of some of these variables around some systems, modules or components. The code is big and messy, and it isn't even obviously "the right thing" overall, though a lot of elements of it are, and every piece is needed somehow.
There's also the question of whether the default readtable should be THE "standard" readtable (immutable on some implementations, not on others), or some shared mutable readtable copied from it (will break many CCL extensions), or from the magic initial readtable that is not standard and that some will mutate (the most backward compatible option, so probably the one ASDF should pick, though it's ugly, unless you want to wrestle some more with the community).
Should we merge the whole messy thing that solves the entire problem? Only the small and clean part that is obviously right but clearly insufficient? Each time we make such a change, we have to pay a lot to overcome a big incompatibility hurdle. If the solution isn't fully satisfactory, then we are setting ourselves up for yet another round (or several) of such costly change(s).
I'm out of the Common Lisp community (moved to Gerbil Scheme), but whoever wants to tackle this challenge for good better makes sure they (and the community!) are ready to pay the price for the transition, and multiple times so if they don't get it right on the first try. Oh, and once you take on the job, you'll be hated by some part of the community whether you subsequently make the change or don't.
Good luck!
On Thu, Feb 22, 2024, 10:15 Robert Goldman rpgoldman@sift.info wrote:
I think this is still true, but... we cannot be discussing ASDF 3.2.1 here. It was released almost 7 years ago, and for whatever reason Zach refuses to update. The current version is 3.3.7
Please get a more recent ASDF and try again. I *believe* that this behavior is still in place: Faré proposed the "syntax control" patch to fix this, but we decided we had no easy path to introducing it, because it would break other code (admittedly not of good style) that relies on the old behavior of having the readtable setting leak out of one file into another. See https://gitlab.common-lisp.net/asdf/asdf/-/merge_requests/86
Any non-backwards compatible modification to ASDF -- even to the extent of raising a deprecation warning -- has led to temper-tantrums in the CL community...
On 21 Feb 2024, at 22:14, Scott@sympoiesis.com wrote:
Hi all! I just ran into something surprising. This is with ASDF 3.2.1, packaged with Quicklisp. I am using Named-Readtables. I had '*readtable*' set to a nonstandard readtable, then did quickload of a system unrelated to the one that defines and uses that readtable. The compilation failed; after I did '(in-readtable :common-lisp)' and tried again, it succeeded.
A quick glance at the ASDF source code shows that it binds '*readtable*' to a standard readtable in some cases, such as to read a '.asd' file, but not in 'uiop/lisp-build/compile-file*', nor in 'asdf/lisp-action:perform-lisp-compilation'. Wouldn't it make sense to do that?
-- Scott
Oh, and as for binding variables around files, this has subtly different meanings when compiling a file, loading its fasl or loading its source. And if done wrong it can easily break fasl concatenation or linking on ecl and mkcl, where you just can't bind around the loading of individual fasls, whereas with source loading you can't not bind, so now the user is responsible to make sure his code works both ways and the binding only really matters at compile-time—which kind of is already a development constraint, just unarticulated, unenforced, and undetected until a subtle bug hits someone.
In the end you can only protect the developer from himself so much, when you can't change the semantics of CL itself across twenty implementations many unmaintained.
On Thu, Feb 22, 2024, 11:16 Faré fahree@gmail.com wrote:
In the past, to introduce changes a fraction as compatibility-breaking (e.g. making utf-8 the default, or changing the internals of OPERATION), I would write up an explanation why the change is desired that anyone can read, discuss on the mailing list, write the code but keep it unmerged or disabled, make an announcement for the intended future breaking change, go over all of Quicklisp with Anton Vodonosov's cl-test-grid, locate all the offenders there, and send patches to each and everyone, wait a year if the old behavior used to be officially documented and supported, only a few weeks if it was a forbidden internals dependency, run the test again, give a last warning to those who didn't merge the patches, sometimes fork the systems left unmaintained to a new home, then finally make the change and announce it. And be ready to handle all the angry authors of proprietary code not in Quicklisp that you failed to previously contact.
For syntax-control (see my branch, that needs much love merging with 3.3.7), we never reached that point, if only because we were never satisfied with the complexity of the code (speaking for myself at least, I suspect for RPG also to a point, but he can opine otherwise if needed). There are many special variables beside *readtable* that control syntax (e.g. some systems try to make double-float the default—with "interesting" side effects to other systems compiled later, more subtle than the big obvious breakage when the readtable is wrong or corrupted). And users define more such variables as they extend the language. So now you want to maintain a dynamic list of symbols, some in packages not yet defined, that you want to track, save and restore. Next your users will want to bind the values of some of these variables around some systems, modules or components. The code is big and messy, and it isn't even obviously "the right thing" overall, though a lot of elements of it are, and every piece is needed somehow.
There's also the question of whether the default readtable should be THE "standard" readtable (immutable on some implementations, not on others), or some shared mutable readtable copied from it (will break many CCL extensions), or from the magic initial readtable that is not standard and that some will mutate (the most backward compatible option, so probably the one ASDF should pick, though it's ugly, unless you want to wrestle some more with the community).
Should we merge the whole messy thing that solves the entire problem? Only the small and clean part that is obviously right but clearly insufficient? Each time we make such a change, we have to pay a lot to overcome a big incompatibility hurdle. If the solution isn't fully satisfactory, then we are setting ourselves up for yet another round (or several) of such costly change(s).
I'm out of the Common Lisp community (moved to Gerbil Scheme), but whoever wants to tackle this challenge for good better makes sure they (and the community!) are ready to pay the price for the transition, and multiple times so if they don't get it right on the first try. Oh, and once you take on the job, you'll be hated by some part of the community whether you subsequently make the change or don't.
Good luck!
On Thu, Feb 22, 2024, 10:15 Robert Goldman rpgoldman@sift.info wrote:
I think this is still true, but... we cannot be discussing ASDF 3.2.1 here. It was released almost 7 years ago, and for whatever reason Zach refuses to update. The current version is 3.3.7
Please get a more recent ASDF and try again. I *believe* that this behavior is still in place: Faré proposed the "syntax control" patch to fix this, but we decided we had no easy path to introducing it, because it would break other code (admittedly not of good style) that relies on the old behavior of having the readtable setting leak out of one file into another. See https://gitlab.common-lisp.net/asdf/asdf/-/merge_requests/86
Any non-backwards compatible modification to ASDF -- even to the extent of raising a deprecation warning -- has led to temper-tantrums in the CL community...
On 21 Feb 2024, at 22:14, Scott@sympoiesis.com wrote:
Hi all! I just ran into something surprising. This is with ASDF 3.2.1, packaged with Quicklisp. I am using Named-Readtables. I had '*readtable*' set to a nonstandard readtable, then did quickload of a system unrelated to the one that defines and uses that readtable. The compilation failed; after I did '(in-readtable :common-lisp)' and tried again, it succeeded.
A quick glance at the ASDF source code shows that it binds '*readtable*' to a standard readtable in some cases, such as to read a '.asd' file, but not in 'uiop/lisp-build/compile-file*', nor in 'asdf/lisp-action:perform-lisp-compilation'. Wouldn't it make sense to do that?
-- Scott
Yes, Faré reminds me that CCL's default readtable is *not* the standard readtable, but a customized one. That means that defaulting to standard readtable would cause breakage in CCL programs. This is the problem that he alludes to below.
Given that Quicklisp and SBCL *already* refuse to update their bundled ASDF versions, because of warnings about deprecated behavior, I'm reluctant to donate any of my unpaid time to fixing this: it's a strong disincentive to making any improvements to ASDF, as opposed to just fixing bugs around the edges.
On 22 Feb 2024, at 10:16, Faré wrote:
In the past, to introduce changes a fraction as compatibility-breaking (e.g. making utf-8 the default, or changing the internals of OPERATION), I would write up an explanation why the change is desired that anyone can read, discuss on the mailing list, write the code but keep it unmerged or disabled, make an announcement for the intended future breaking change, go over all of Quicklisp with Anton Vodonosov's cl-test-grid, locate all the offenders there, and send patches to each and everyone, wait a year if the old behavior used to be officially documented and supported, only a few weeks if it was a forbidden internals dependency, run the test again, give a last warning to those who didn't merge the patches, sometimes fork the systems left unmaintained to a new home, then finally make the change and announce it. And be ready to handle all the angry authors of proprietary code not in Quicklisp that you failed to previously contact.
For syntax-control (see my branch, that needs much love merging with 3.3.7), we never reached that point, if only because we were never satisfied with the complexity of the code (speaking for myself at least, I suspect for RPG also to a point, but he can opine otherwise if needed). There are many special variables beside *readtable* that control syntax (e.g. some systems try to make double-float the default—with "interesting" side effects to other systems compiled later, more subtle than the big obvious breakage when the readtable is wrong or corrupted). And users define more such variables as they extend the language. So now you want to maintain a dynamic list of symbols, some in packages not yet defined, that you want to track, save and restore. Next your users will want to bind the values of some of these variables around some systems, modules or components. The code is big and messy, and it isn't even obviously "the right thing" overall, though a lot of elements of it are, and every piece is needed somehow.
There's also the question of whether the default readtable should be THE "standard" readtable (immutable on some implementations, not on others), or some shared mutable readtable copied from it (will break many CCL extensions), or from the magic initial readtable that is not standard and that some will mutate (the most backward compatible option, so probably the one ASDF should pick, though it's ugly, unless you want to wrestle some more with the community).
Should we merge the whole messy thing that solves the entire problem? Only the small and clean part that is obviously right but clearly insufficient? Each time we make such a change, we have to pay a lot to overcome a big incompatibility hurdle. If the solution isn't fully satisfactory, then we are setting ourselves up for yet another round (or several) of such costly change(s).
I'm out of the Common Lisp community (moved to Gerbil Scheme), but whoever wants to tackle this challenge for good better makes sure they (and the community!) are ready to pay the price for the transition, and multiple times so if they don't get it right on the first try. Oh, and once you take on the job, you'll be hated by some part of the community whether you subsequently make the change or don't.
Good luck!
On Thu, Feb 22, 2024, 10:15 Robert Goldman rpgoldman@sift.info wrote:
I think this is still true, but... we cannot be discussing ASDF 3.2.1 here. It was released almost 7 years ago, and for whatever reason Zach refuses to update. The current version is 3.3.7
Please get a more recent ASDF and try again. I *believe* that this behavior is still in place: Faré proposed the "syntax control" patch to fix this, but we decided we had no easy path to introducing it, because it would break other code (admittedly not of good style) that relies on the old behavior of having the readtable setting leak out of one file into another. See https://gitlab.common-lisp.net/asdf/asdf/-/merge_requests/86
Any non-backwards compatible modification to ASDF -- even to the extent of raising a deprecation warning -- has led to temper-tantrums in the CL community...
On 21 Feb 2024, at 22:14, Scott@sympoiesis.com wrote:
Hi all! I just ran into something surprising. This is with ASDF 3.2.1, packaged with Quicklisp. I am using Named-Readtables. I had '*readtable*' set to a nonstandard readtable, then did quickload of a system unrelated to the one that defines and uses that readtable. The compilation failed; after I did '(in-readtable :common-lisp)' and tried again, it succeeded.
A quick glance at the ASDF source code shows that it binds '*readtable*' to a standard readtable in some cases, such as to read a '.asd' file, but not in 'uiop/lisp-build/compile-file*', nor in 'asdf/lisp-action:perform-lisp-compilation'. Wouldn't it make sense to do that?
-- Scott
Yes, Faré reminds me that CCL's default readtable is *not* the standard readtable, but a customized one. That means that defaulting to standard readtable would cause breakage in CCL programs. This is the problem that he alludes to below.
Defaulting to the standard readtable *might* cause breakage, but it would be good for portability.
Given that Quicklisp and SBCL *already* refuse to update their bundled ASDF versions, because of warnings about deprecated behavior, I'm reluctant to donate any of my unpaid time to fixing this: it's a strong disincentive to making any improvements to ASDF, as opposed to just fixing bugs around the edges.
Is it time for ASDF 4 ? There's tons of stuff I'd like to delete or change.
On 22 Feb 2024, at 10:16, Faré wrote:
In the past, to introduce changes a fraction as compatibility-breaking (e.g. making utf-8 the default, or changing the internals of OPERATION), I would write up an explanation why the change is desired that anyone can read, discuss on the mailing list, write the code but keep it unmerged or disabled, make an announcement for the intended future breaking change, go over all of Quicklisp with Anton Vodonosov's cl-test-grid, locate all the offenders there, and send patches to each and everyone, wait a year if the old behavior used to be officially documented and supported, only a few weeks if it was a forbidden internals dependency, run the test again, give a last warning to those who didn't merge the patches, sometimes fork the systems left unmaintained to a new home, then finally make the change and announce it. And be ready to handle all the angry authors of proprietary code not in Quicklisp that you failed to previously contact.
For syntax-control (see my branch, that needs much love merging with 3.3.7), we never reached that point, if only because we were never satisfied with the complexity of the code (speaking for myself at least, I suspect for RPG also to a point, but he can opine otherwise if needed). There are many special variables beside *readtable* that control syntax (e.g. some systems try to make double-float the default—with "interesting" side effects to other systems compiled later, more subtle than the big obvious breakage when the readtable is wrong or corrupted). And users define more such variables as they extend the language. So now you want to maintain a dynamic list of symbols, some in packages not yet defined, that you want to track, save and restore. Next your users will want to bind the values of some of these variables around some systems, modules or components. The code is big and messy, and it isn't even obviously "the right thing" overall, though a lot of elements of it are, and every piece is needed somehow.
There's also the question of whether the default readtable should be THE "standard" readtable (immutable on some implementations, not on others), or some shared mutable readtable copied from it (will break many CCL extensions), or from the magic initial readtable that is not standard and that some will mutate (the most backward compatible option, so probably the one ASDF should pick, though it's ugly, unless you want to wrestle some more with the community).
Should we merge the whole messy thing that solves the entire problem? Only the small and clean part that is obviously right but clearly insufficient? Each time we make such a change, we have to pay a lot to overcome a big incompatibility hurdle. If the solution isn't fully satisfactory, then we are setting ourselves up for yet another round (or several) of such costly change(s).
I'm out of the Common Lisp community (moved to Gerbil Scheme), but whoever wants to tackle this challenge for good better makes sure they (and the community!) are ready to pay the price for the transition, and multiple times so if they don't get it right on the first try. Oh, and once you take on the job, you'll be hated by some part of the community whether you subsequently make the change or don't.
Good luck!
On Thu, Feb 22, 2024, 10:15 Robert Goldman rpgoldman@sift.info wrote:
I think this is still true, but... we cannot be discussing ASDF 3.2.1 here. It was released almost 7 years ago, and for whatever reason Zach refuses to update. The current version is 3.3.7
Please get a more recent ASDF and try again. I *believe* that this behavior is still in place: Faré proposed the "syntax control" patch to fix this, but we decided we had no easy path to introducing it, because it would break other code (admittedly not of good style) that relies on the old behavior of having the readtable setting leak out of one file into another. See https://gitlab.common-lisp.net/asdf/asdf/-/merge_requests/86
Any non-backwards compatible modification to ASDF -- even to the extent of raising a deprecation warning -- has led to temper-tantrums in the CL community...
On 21 Feb 2024, at 22:14, Scott@sympoiesis.com wrote:
Hi all! I just ran into something surprising. This is with ASDF 3.2.1, packaged with Quicklisp. I am using Named-Readtables. I had '*readtable*' set to a nonstandard readtable, then did quickload of a system unrelated to the one that defines and uses that readtable. The compilation failed; after I did '(in-readtable :common-lisp)' and tried again, it succeeded.
A quick glance at the ASDF source code shows that it binds '*readtable*' to a standard readtable in some cases, such as to read a '.asd' file, but not in 'uiop/lisp-build/compile-file*', nor in 'asdf/lisp-action:perform-lisp-compilation'. Wouldn't it make sense to do that?
-- Scott
-- Stelian Ionescu
For now, I have been hoping for/focused on ASDF 3.4 which would be backwards-compatible, but add new capabilities, so would not be forwards-compatible.
Wondering if it will just languish unused is a strong disincentive to invest my unpaid hours in ASDF. There are other things I can work on that are more fun.
Cheers, R
On 24 Feb 2024, at 9:57, Stelian Ionescu wrote:
Yes, Faré reminds me that CCL's default readtable is *not* the standard readtable, but a customized one. That means that defaulting to standard readtable would cause breakage in CCL programs. This is the problem that he alludes to below.
Defaulting to the standard readtable *might* cause breakage, but it would be good for portability.
Given that Quicklisp and SBCL *already* refuse to update their bundled ASDF versions, because of warnings about deprecated behavior, I'm reluctant to donate any of my unpaid time to fixing this: it's a strong disincentive to making any improvements to ASDF, as opposed to just fixing bugs around the edges.
Is it time for ASDF 4 ? There's tons of stuff I'd like to delete or change.
On 22 Feb 2024, at 10:16, Faré wrote:
In the past, to introduce changes a fraction as compatibility-breaking (e.g. making utf-8 the default, or changing the internals of OPERATION), I would write up an explanation why the change is desired that anyone can read, discuss on the mailing list, write the code but keep it unmerged or disabled, make an announcement for the intended future breaking change, go over all of Quicklisp with Anton Vodonosov's cl-test-grid, locate all the offenders there, and send patches to each and everyone, wait a year if the old behavior used to be officially documented and supported, only a few weeks if it was a forbidden internals dependency, run the test again, give a last warning to those who didn't merge the patches, sometimes fork the systems left unmaintained to a new home, then finally make the change and announce it. And be ready to handle all the angry authors of proprietary code not in Quicklisp that you failed to previously contact.
For syntax-control (see my branch, that needs much love merging with 3.3.7), we never reached that point, if only because we were never satisfied with the complexity of the code (speaking for myself at least, I suspect for RPG also to a point, but he can opine otherwise if needed). There are many special variables beside *readtable* that control syntax (e.g. some systems try to make double-float the default—with "interesting" side effects to other systems compiled later, more subtle than the big obvious breakage when the readtable is wrong or corrupted). And users define more such variables as they extend the language. So now you want to maintain a dynamic list of symbols, some in packages not yet defined, that you want to track, save and restore. Next your users will want to bind the values of some of these variables around some systems, modules or components. The code is big and messy, and it isn't even obviously "the right thing" overall, though a lot of elements of it are, and every piece is needed somehow.
There's also the question of whether the default readtable should be THE "standard" readtable (immutable on some implementations, not on others), or some shared mutable readtable copied from it (will break many CCL extensions), or from the magic initial readtable that is not standard and that some will mutate (the most backward compatible option, so probably the one ASDF should pick, though it's ugly, unless you want to wrestle some more with the community).
Should we merge the whole messy thing that solves the entire problem? Only the small and clean part that is obviously right but clearly insufficient? Each time we make such a change, we have to pay a lot to overcome a big incompatibility hurdle. If the solution isn't fully satisfactory, then we are setting ourselves up for yet another round (or several) of such costly change(s).
I'm out of the Common Lisp community (moved to Gerbil Scheme), but whoever wants to tackle this challenge for good better makes sure they (and the community!) are ready to pay the price for the transition, and multiple times so if they don't get it right on the first try. Oh, and once you take on the job, you'll be hated by some part of the community whether you subsequently make the change or don't.
Good luck!
On Thu, Feb 22, 2024, 10:15 Robert Goldman rpgoldman@sift.info wrote:
I think this is still true, but... we cannot be discussing ASDF 3.2.1 here. It was released almost 7 years ago, and for whatever reason Zach refuses to update. The current version is 3.3.7
Please get a more recent ASDF and try again. I *believe* that this behavior is still in place: Faré proposed the "syntax control" patch to fix this, but we decided we had no easy path to introducing it, because it would break other code (admittedly not of good style) that relies on the old behavior of having the readtable setting leak out of one file into another. See https://gitlab.common-lisp.net/asdf/asdf/-/merge_requests/86
Any non-backwards compatible modification to ASDF -- even to the extent of raising a deprecation warning -- has led to temper-tantrums in the CL community...
On 21 Feb 2024, at 22:14, Scott@sympoiesis.com wrote:
Hi all! I just ran into something surprising. This is with ASDF 3.2.1, packaged with Quicklisp. I am using Named-Readtables. I had '*readtable*' set to a nonstandard readtable, then did quickload of a system unrelated to the one that defines and uses that readtable. The compilation failed; after I did '(in-readtable :common-lisp)' and tried again, it succeeded.
A quick glance at the ASDF source code shows that it binds '*readtable*' to a standard readtable in some cases, such as to read a '.asd' file, but not in 'uiop/lisp-build/compile-file*', nor in 'asdf/lisp-action:perform-lisp-compilation'. Wouldn't it make sense to do that?
-- Scott
-- Stelian Ionescu
rpg:>> Given that Quicklisp and SBCL already refuse to update their bundled ASDF versions, because of warnings about deprecated behavior, I'm reluctant to donate any of my unpaid time to fixing this: it's a strong disincentive to making any improvements to ASDF, as opposed to just fixing bugs around the edges. On the other hand, the whole point of ASDF 2 and later was that by making ASDF upgradable (and with ASDF 3, it's now automatically self-upgradable), users shouldn't have to care as much which version of ASDF their implementation and package distribution system do or don't provide: "just" install the latest ASDF in e.g. ~/common-lisp/asdf/ and things will "just work". If the new ASDF is so much better, eventually the implementors and distributors should follow.
si:> Is it time for ASDF 4 ? There's tons of stuff I'd like to delete or change. It's always time for ASDF 4, and never time for ASDF 4. The main question is: is someone crazy enough to sink in the time to do it, the emotional energy to fight half the community, etc.
If only Bazel didn't fuck up their namespace system, the solution could have been "just use Bazelisp".
If and when someone volunteers to do ASDF 4 (if ever), there are plenty of suggestions in the asdf/TODO file, in addition to the issues on gitlab and the old launchpad. Good luck!
—♯ƒ • François-René Rideau • Chief Scientist, MuKn.com “With freedom, no more One True Scale to rank people. Everyone pick his own. Why vie for a society of equals, when everyone can be superior?”
I'm curious about the Bazel namespace problem. Can you elaborate a bit ...
On Mon, Feb 26, 2024 at 4:57 PM Faré fahree@gmail.com wrote:
rpg:>> Given that Quicklisp and SBCL already refuse to update their bundled ASDF versions, because of warnings about deprecated behavior, I'm reluctant to donate any of my unpaid time to fixing this: it's a strong disincentive to making any improvements to ASDF, as opposed to just fixing bugs around the edges. On the other hand, the whole point of ASDF 2 and later was that by making ASDF upgradable (and with ASDF 3, it's now automatically self-upgradable), users shouldn't have to care as much which version of ASDF their implementation and package distribution system do or don't provide: "just" install the latest ASDF in e.g. ~/common-lisp/asdf/ and things will "just work". If the new ASDF is so much better, eventually the implementors and distributors should follow.
si:> Is it time for ASDF 4 ? There's tons of stuff I'd like to delete or change. It's always time for ASDF 4, and never time for ASDF 4. The main question is: is someone crazy enough to sink in the time to do it, the emotional energy to fight half the community, etc.
If only Bazel didn't fuck up their namespace system, the solution could have been "just use Bazelisp".
If and when someone volunteers to do ASDF 4 (if ever), there are plenty of suggestions in the asdf/TODO file, in addition to the issues on gitlab and the old launchpad. Good luck!
—♯ƒ • François-René Rideau • Chief Scientist, MuKn.com “With freedom, no more One True Scale to rank people. Everyone pick his own. Why vie for a society of equals, when everyone can be superior?”
I'm also very curious because I might have a use for it soon.
I'm curious about the Bazel namespace problem. Can you elaborate a bit ...
On Mon, Feb 26, 2024 at 4:57 PM Faré fahree@gmail.com wrote:
rpg:>> Given that Quicklisp and SBCL already refuse to update their bundled ASDF versions, because of warnings about deprecated behavior, I'm reluctant to donate any of my unpaid time to fixing this: it's a strong disincentive to making any improvements to ASDF, as opposed to just fixing bugs around the edges. On the other hand, the whole point of ASDF 2 and later was that by making ASDF upgradable (and with ASDF 3, it's now automatically self-upgradable), users shouldn't have to care as much which version of ASDF their implementation and package distribution system do or don't provide: "just" install the latest ASDF in e.g. ~/common-lisp/asdf/ and things will "just work". If the new ASDF is so much better, eventually the implementors and distributors should follow.
si:> Is it time for ASDF 4 ? There's tons of stuff I'd like to delete or change. It's always time for ASDF 4, and never time for ASDF 4. The main question is: is someone crazy enough to sink in the time to do it, the emotional energy to fight half the community, etc.
If only Bazel didn't fuck up their namespace system, the solution could have been "just use Bazelisp".
If and when someone volunteers to do ASDF 4 (if ever), there are plenty of suggestions in the asdf/TODO file, in addition to the issues on gitlab and the old launchpad. Good luck!
—♯ƒ • François-René Rideau • Chief Scientist, MuKn.com “With freedom, no more One True Scale to rank people. Everyone pick his own. Why vie for a society of equals, when everyone can be superior?”
-
Faré -
Pascal Bourguignon -
Robert Brown -
Robert Goldman -
Scott＠sympoiesis.com -
Stelian Ionescu