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é wrote:
>>
>> rpg:>> Given that Quicklisp and SBCL already refuse to update their
>> bundled ASDF versions, because
I'm curious about the Bazel namespace problem. Can you elaborate a bit ...
On Mon, Feb 26, 2024 at 4:57 PM Faré 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
[Oops — just noticed that I had sent this only to Faré, not the list.]
Oh wow, that was even more of an earful than I was expecting :-)
... I've now read your syntax-control document. Before I found it, I tried
to think of solutions, and came up with something very much like your
Proposal 2.
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
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
> 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
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
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,
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
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é
Le 22/02/2024 à 05:14, sc...@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
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;
12 matches
Mail list logo
