Re: Warning: Computing just-done stamp in plan NIL for action
ASDF keeps inventing good reasons all the time... On Wed, Oct 18, 2017 at 7:43 PM Faré <fahree@gmail.com> wrote:
Oh, is it a case where you're insisting on using a secondary system name that doesn't follow the convention B/A when the primary system is B ? That might explain it. There is also a warning against such a thing, and for good reason.
—♯ƒ • François-René ÐVB Rideau •Reflection&Cybernethics• http://fare.tunes.org Doing well is the result of doing good. That's what capitalism is all about. — Ralph Waldo Emerson (1803–1882)
cat b.asd (defsystem A)
(defsystem B :depends-on (A))
(asdf:load-system 'b) is enough to trigger it.
On Wed, Oct 18, 2017 at 6:51 PM Faré <fahree@gmail.com> wrote:
See section 4 of the ASDF 3.3 paper at ILC 2017 for a quick overview: https://github.com/fare/asdf2017
To support proper phase separation, ASDF has a new operation, define-op, that tracks the dependencies of loading a .asd file (i.e. other systems you operate on, e.g., via load-system or defsystem-depends-on, etc.)
I don't know exactly what is your system A and how you use it, but apparently it's unhappy about depending on the primary system for define-op yet being earlier in the .asd file, so the other system hasn't been defined yet.
Maybe ASDF should refrain from registering a dependency here between sibling systems. Or not. It was quite subtle to debug about a year ago, and it fell out of my working cache.
Is there anything special you do between A and B except a :depends-on ?
—♯ƒ • François-René ÐVB Rideau •Reflection&Cybernethics• http://fare.tunes.org You think war is economically beneficial? Then why share those benefits with dirty foreigners? Let's have a civil war — A war we're sure to win!
On Wed, Oct 18, 2017 at 11:34 AM, Stas Boukarev <stassats@gmail.com> wrote:
It’s a regular depends-on, but why did it work before without
On Wed, Oct 18, 2017 at 12:15 PM, Stas Boukarev <stassats@gmail.com> wrote: problems?
On Wed, 18 Oct 2017 at 18:32 Faré <fahree@gmail.com> wrote:
On Wed, Oct 18, 2017 at 11:25 AM, Stas Boukarev <stassats@gmail.com> wrote:
B is primary, but A has to be loaded before it. It precedes B, and
B
depends on it.
If it's a regular :depends-on, then B should be able to appear before A, and that should actually work better.
If it's a :defsystem-depends-on, it used to be that A must be before B, but the new situation is that they have to be in separate files for define-op to work at all.
—♯ƒ • François-René ÐVB Rideau •Reflection&Cybernethics• http://fare.tunes.org For ultimately, the most visible trait of a just man is to have no desire at all to rule others, and only want to rule himself. This decides everything. In other words, the worst people will rule. — Alain
On Wed, Oct 18, 2017 at 6:23 PM Faré <fahree@gmail.com> wrote: > > On Wed, Oct 18, 2017 at 11:13 AM, Stas Boukarev < stassats@gmail.com> > wrote: > > Looks like this happens because I have two systems in B.asd, A and > > B, > > and B > > depends on A. > Maybe changing the order of the two systems will help. > Which is primary? Which depends on the other? > > —♯ƒ • François-René ÐVB Rideau •Reflection&Cybernethics• > http://fare.tunes.org > All honest people are welcome to come and live here. > All dishonest people are welcome to come and die here. > — Libertarian Open-Borders, Open-Skulls Policy
On Wed, Oct 18, 2017 at 12:58 PM, Stas Boukarev <stassats@gmail.com> wrote:
ASDF keeps inventing good reasons all the time...
Indeed , "inventing" in the original sense of the term: finding a preexisting thing that no one suspected existed, but that was there of all times. See my post about a previous occurrence of the pattern with ASDF 3.0: https://fare.livejournal.com/176185.html — ASDF 3.3 was also fixing a bug, doing it right, and discovering that some things had been wrong all along. —♯ƒ • François-René ÐVB Rideau •Reflection&Cybernethics• http://fare.tunes.org A child of five would understand this. Send someone to fetch a child of five. — Groucho Marx
The systems working on older asdf versions is wrong? On Wed, Oct 18, 2017 at 8:48 PM Faré <fahree@gmail.com> wrote:
On Wed, Oct 18, 2017 at 12:58 PM, Stas Boukarev <stassats@gmail.com> wrote:
ASDF keeps inventing good reasons all the time...
Indeed , "inventing" in the original sense of the term: finding a preexisting thing that no one suspected existed, but that was there of all times. See my post about a previous occurrence of the pattern with ASDF 3.0: https://fare.livejournal.com/176185.html — ASDF 3.3 was also fixing a bug, doing it right, and discovering that some things had been wrong all along.
—♯ƒ • François-René ÐVB Rideau •Reflection&Cybernethics• http://fare.tunes.org A child of five would understand this. Send someone to fetch a child of five. — Groucho Marx
On Wed, Oct 18, 2017 at 2:40 PM, Stas Boukarev <stassats@gmail.com> wrote:
The systems working on older asdf versions is wrong?
Some of them might be. Defining systems with names not based on the .asd filename was never fully supported. In all versions of ASDF, it could lead to the system not being findable by its name, or its aliasing another system, or being aliased by another system, or throwing ASDF in an infinite loop as two systems aliased each other. It's just that ASDF then failed to properly detect the situation and warn the user. Now it tries to do the right thing, in a way that actually works and is supported. Now, I am not saying ASDF 3.3 is without fault. First, this is all out of my cache, so I cannot swear what should or what shouldn't be the expected behavior in this case. What I *can* say is that this case was intended to be somewhat supported on a best effort basis but deprecated. Whether it should work better than that or not, however, it is still *also* a bug in ASDF that the situation wasn't detected with a more helpful error or warning being offered. In summary: your use case was never fully supported and is now explicitly deprecated. ASDF is still at fault for not providing a better error behavior. PS: I don't currently intend to spend too many cycles on this particular issue, but as usual can be convinced otherwise. —♯ƒ • François-René ÐVB Rideau •Reflection&Cybernethics• http://fare.tunes.org Multiple instances of a same hacker with different context in his mental cache count as multiple hackers wrt documentation and testing needs.
On Wed, Oct 18, 2017 at 8:48 PM Faré <fahree@gmail.com> wrote:
On Wed, Oct 18, 2017 at 12:58 PM, Stas Boukarev <stassats@gmail.com> wrote:
ASDF keeps inventing good reasons all the time...
Indeed , "inventing" in the original sense of the term: finding a preexisting thing that no one suspected existed, but that was there of all times. See my post about a previous occurrence of the pattern with ASDF 3.0: https://fare.livejournal.com/176185.html — ASDF 3.3 was also fixing a bug, doing it right, and discovering that some things had been wrong all along.
On Wed, Oct 18, 2017 at 2:40 PM, Stas Boukarev <stassats@gmail.com> wrote:
The systems working on older asdf versions is wrong?
Some of them might be. Defining systems with names not based on the .asd filename was never fully supported. In earlier versions of ASDF, it could lead to the system not being findable by its name, to its aliasing another system, to its being aliased by another system, or before 2.x, to throwing ASDF in an infinite loop as two systems aliased each other. It's just that ASDF then failed to properly detect the situation and warn the user. Now ASDF tries to do the right thing for secondary systems that follow a sensible naming pattern, in a way that actually works and is supported (and backward compatible), and to warn when it sees secondary systems that fail to follow the supported pattern. Now, I am not saying ASDF 3.3 is without fault. First, this is all out of my cache, so I cannot swear what should or what shouldn't be the expected behavior in this case. What I *can* say is that this case was intended to be somewhat supported on a best effort basis but deprecated. Still, whether it should work better than that or not, it is *also* a bug that ASDF failed to detect the situation to then either make it work or at least offer a more helpful error or warning. Mea culpa. In summary: your use case was never fully supported and is now explicitly deprecated, and it is recommend to rename your systems to fit the supported convention. ASDF is still at fault for not behaving better. PS: I don't currently intend to spend too many cycles on this particular issue, but as usual can be convinced otherwise. —♯ƒ • François-René ÐVB Rideau •Reflection&Cybernethics• http://fare.tunes.org Multiple instances of a same hacker with different context in his mental cache count as multiple hackers wrt documentation and testing needs.
On Wed, Oct 18, 2017 at 8:48 PM Faré <fahree@gmail.com> wrote:
On Wed, Oct 18, 2017 at 12:58 PM, Stas Boukarev <stassats@gmail.com> wrote:
ASDF keeps inventing good reasons all the time...
Indeed , "inventing" in the original sense of the term: finding a preexisting thing that no one suspected existed, but that was there of all times. See my post about a previous occurrence of the pattern with ASDF 3.0: https://fare.livejournal.com/176185.html — ASDF 3.3 was also fixing a bug, doing it right, and discovering that some things had been wrong all along.
participants (2)
-
Faré -
Stas Boukarev