Warning: Computing just-done stamp in plan NIL for action

[Stas Boukarev]

More new warnings from ASDF 3.3, this time I have no idea what it means.

WARNING:
Computing just-done stamp in plan NIL for action
(ASDF/LISP-ACTION:LOAD-OP
"system"), but
dependency (ASDF/FIND-SYSTEM:DEFINE-OP

"system") wasn't done yet!

The .asd file is not public, but it looks perfectly normal without using
any complicated features.

[Faré]

It's hard to tell without seeing the .asd file. The message says that
you completed the load-op of the system, but somehow you never did the
define-op of the system (the new action that tracks the loading of
.asd files so that defsystem-depends-on can be properly staged).

Can you tell us more about the "non-complicated" features that you
use? Do you follow the "best practices" document?
https://github.com/fare/asdf/blob/master/doc/best_practices.md

—♯ƒ • François-René ÐVB Rideau •Reflection&Cybernethics• http://fare.tunes.org
Don't forget your daily prayer to Baah-kup,
the God of data storage and recovery!

Post by Stas Boukarev
More new warnings from ASDF 3.3, this time I have no idea what it means.
Computing just-done stamp in plan NIL for action
(ASDF/LISP-ACTION:LOAD-OP
"system"), but
dependency (ASDF/FIND-SYSTEM:DEFINE-OP
"system") wasn't done yet!
The .asd file is not public, but it looks perfectly normal without using any
complicated features.

[Stas Boukarev]

It's a work file, can't publish it. But it's just a defsystem with
depends-on and components.

Post by Faré
It's hard to tell without seeing the .asd file. The message says that
you completed the load-op of the system, but somehow you never did the
define-op of the system (the new action that tracks the loading of
.asd files so that defsystem-depends-on can be properly staged).
Can you tell us more about the "non-complicated" features that you
use? Do you follow the "best practices" document?
https://github.com/fare/asdf/blob/master/doc/best_practices.md
—♯ƒ • François-René ÐVB Rideau •Reflection&Cybernethics•
http://fare.tunes.org
Don't forget your daily prayer to Baah-kup,
the God of data storage and recovery!

Post by Stas Boukarev
More new warnings from ASDF 3.3, this time I have no idea what it means.
Computing just-done stamp in plan NIL for action
(ASDF/LISP-ACTION:LOAD-OP
"system"), but
dependency (ASDF/FIND-SYSTEM:DEFINE-OP
"system") wasn't done yet!
The .asd file is not public, but it looks perfectly normal without using

any

Post by Stas Boukarev
complicated features.

[Faré]

Can you anonymize it and send it? Or extract a minimal failure case? I
can't reproduce at home, nor imagine what could be happening.

Anton, could you test the syntax-control branch with cl-test-grid, and
grep the results for expansions of the format string "Computing
just-done stamp in plan ~S for action ~S, but dependency ~S wasn't
done yet!" ?

—♯ƒ • François-René ÐVB Rideau •Reflection&Cybernethics• http://fare.tunes.org
Mathematics is as little a science as grammar is a language. — Ernst Mayr

It's a work file, can't publish it. But it's just a defsystem with depends-on and components.

Post by Faré
It's hard to tell without seeing the .asd file. The message says that
you completed the load-op of the system, but somehow you never did the
define-op of the system (the new action that tracks the loading of
.asd files so that defsystem-depends-on can be properly staged).
Can you tell us more about the "non-complicated" features that you
use? Do you follow the "best practices" document?
https://github.com/fare/asdf/blob/master/doc/best_practices.md
—♯ƒ • François-René ÐVB Rideau •Reflection&Cybernethics• http://fare.tunes.org
Don't forget your daily prayer to Baah-kup,
the God of data storage and recovery!

Post by Stas Boukarev
More new warnings from ASDF 3.3, this time I have no idea what it means.
Computing just-done stamp in plan NIL for action
(ASDF/LISP-ACTION:LOAD-OP
"system"), but
dependency (ASDF/FIND-SYSTEM:DEFINE-OP
"system") wasn't done yet!
The .asd file is not public, but it looks perfectly normal without using any
complicated features.

[Chream iz]

Hi, I am also getting this error when trying to run (asdf:test-system ....). It is also not finding the test-files but that might be an but in the prove package?

Summary:
All 0 files passed.
WARNING:
Computing just-done stamp in plan NIL for action (ASDF/LISP-ACTION:TEST-OP
"iparse"), but dependency (ASDF/LISP-ACTION:TEST-OP
"iparse-test") wasn't done yet!


system asd:

#|
This file is a part of iparse project.
Copyright (c) 2017 Christopher Eames (chream) (***@gmx.com)
|#

#|
Author: Christopher Eames (chream) (***@gmx.com)
|#

(in-package :cl-user)
(defpackage iparse-asd
(:use :cl :asdf))
(in-package :iparse-asd)

(defsystem iparse
:version "0.1.1"
:class :package-inferred-system
:author "Christopher Eames (chream)"
:license "MIT"
:depends-on ("iparse/src/iparse")
:description "A small parsing and data structure library."
:long-description
#.(with-open-file (stream (merge-pathnames
#p"README.markdown"
(or *load-pathname* *compile-file-pathname*))
:if-does-not-exist nil
:direction :input)
(when stream
(let ((seq (make-array (file-length stream)
:element-type 'character
:fill-pointer t)))
(setf (fill-pointer seq) (read-sequence seq stream))
seq)))
:in-order-to ((test-op (test-op iparse-test))))

(register-system-packages
"closer-mop"
'(:c2mop :closer-common-lisp :c2cl :closer-common-lisp-user :c2cl-user))
(register-system-packages
"lil"
'(:lil/core :interface :pure :smltateful :classy :posh :lil/test))

(register-system-packages "iparse/src/all" '(:iparse.dev))
(register-system-packages "iparse/src/formats" '(:iparse.formats))
(register-system-packages "iparse/src/utils" '(:iparse.utils))
(register-system-packages "iparse/src/iparse" '(:iparse))
(register-system-packages "iparse/src/types" '(:iparse.types))



Test system asd:

#|
This file is a part of iparse project.
Copyright (c) 2017 Christopher Eames (chream) (***@gmx.com)
|#

(in-package :cl-user)
(defpackage iparse-test-asd
(:use :cl :asdf))
(in-package :iparse-test-asd)

(defsystem iparse-test
:author "Christopher Eames (chream)"
:license ""
:depends-on (:iparse
:prove)
:components ((:module "t"
:serial t
:components
((:file "utils")
(:test-file "utils-test")
(:test-file "read-single-test-byte")
(:test-file "read-single-test-sequence")
(:test-file "read-single-test-composite")
(:test-file "read-single-test-class")
(:test-file "byte")
(:test-file "macro")
(:module "new"
:serial t
:components
((:test-file "basic-tests"))))))
:description "Test system for iparse"

:defsystem-depends-on (:prove-asdf)
:perform (test-op :after (op c)
(funcall (intern #.(string :run-test-system) :prove-asdf) c)
(asdf:clear-system c)))


Christopher

Post by Faré
Can you anonymize it and send it? Or extract a minimal failure case? I
can't reproduce at home, nor imagine what could be happening.
Anton, could you test the syntax-control branch with cl-test-grid, and
grep the results for expansions of the format string "Computing
just-done stamp in plan ~S for action ~S, but dependency ~S wasn't
done yet!" ?
—♯ƒ • François-René ÐVB Rideau •Reflection&Cybernethics• http://fare.tunes.org
Mathematics is as little a science as grammar is a language. — Ernst Mayr

It's a work file, can't publish it. But it's just a defsystem with depends-on and components.

Post by Faré
It's hard to tell without seeing the .asd file. The message says that
you completed the load-op of the system, but somehow you never did the
define-op of the system (the new action that tracks the loading of
.asd files so that defsystem-depends-on can be properly staged).
Can you tell us more about the "non-complicated" features that you
use? Do you follow the "best practices" document?
https://github.com/fare/asdf/blob/master/doc/best_practices.md
—♯ƒ • François-René ÐVB Rideau •Reflection&Cybernethics• http://fare.tunes.org
Don't forget your daily prayer to Baah-kup,
the God of data storage and recovery!

Post by Stas Boukarev
More new warnings from ASDF 3.3, this time I have no idea what it means.
Computing just-done stamp in plan NIL for action
(ASDF/LISP-ACTION:LOAD-OP
"system"), but
dependency (ASDF/FIND-SYSTEM:DEFINE-OP
"system") wasn't done yet!
The .asd file is not public, but it looks perfectly normal without using any
complicated features.

[Robert Goldman]

Is this system somewhere available (e.g., GitHub) so we could try to
replicate?

For that matter, could we break on signals and get a backtrace?

thanks,
r

Post by Chream iz
Hi, I am also getting this error when trying to run (asdf:test-system
....). It is also not finding the test-files but that might be an but
in the prove package?
All 0 files passed.
Computing just-done stamp in plan NIL for action
(ASDF/LISP-ACTION:TEST-OP
"iparse"), but
dependency (ASDF/LISP-ACTION:TEST-OP
"iparse-test")
wasn't done yet!
#|
This file is a part of iparse project.
|#
#|
|#
(in-package :cl-user)
(defpackage iparse-asd
(:use :cl :asdf))
(in-package :iparse-asd)
(defsystem iparse
:version "0.1.1"
:class :package-inferred-system
:author "Christopher Eames (chream)"
:license "MIT"
:depends-on ("iparse/src/iparse")
:description "A small parsing and data structure library."
:long-description
#.(with-open-file (stream (merge-pathnames
#p"README.markdown"
(or *load-pathname*
*compile-file-pathname*))
:if-does-not-exist nil
:direction :input)
(when stream
(let ((seq (make-array (file-length stream)
:element-type 'character
:fill-pointer t)))
(setf (fill-pointer seq) (read-sequence seq stream))
seq)))
:in-order-to ((test-op (test-op iparse-test))))
(register-system-packages
"closer-mop"
'(:c2mop :closer-common-lisp :c2cl :closer-common-lisp-user
:c2cl-user))
(register-system-packages
"lil"
'(:lil/core :interface :pure :smltateful :classy :posh :lil/test))
(register-system-packages "iparse/src/all" '(:iparse.dev))
(register-system-packages "iparse/src/formats" '(:iparse.formats))
(register-system-packages "iparse/src/utils" '(:iparse.utils))
(register-system-packages "iparse/src/iparse" '(:iparse))
(register-system-packages "iparse/src/types" '(:iparse.types))
#|
This file is a part of iparse project.
|#
(in-package :cl-user)
(defpackage iparse-test-asd
(:use :cl :asdf))
(in-package :iparse-test-asd)
(defsystem iparse-test
:author "Christopher Eames (chream)"
:license ""
:depends-on (:iparse
:prove)
:components ((:module "t"
:serial t
:components
((:file "utils")
(:test-file "utils-test")
(:test-file "read-single-test-byte")
(:test-file "read-single-test-sequence")
(:test-file "read-single-test-composite")
(:test-file "read-single-test-class")
(:test-file "byte")
(:test-file "macro")
(:module "new"
:serial t
:components
((:test-file "basic-tests"))))))
:description "Test system for iparse"
:defsystem-depends-on (:prove-asdf)
:perform (test-op :after (op c)
(funcall (intern #.(string :run-test-system) :prove-asdf) c)
(asdf:clear-system c)))
Christopher

Post by Faré
Can you anonymize it and send it? Or extract a minimal failure case? I
can't reproduce at home, nor imagine what could be happening.
Anton, could you test the syntax-control branch with cl-test-grid, and
grep the results for expansions of the format string "Computing
just-done stamp in plan ~S for action ~S, but dependency ~S wasn't
done yet!" ?
—♯ƒ • François-René ÐVB Rideau
•Reflection&Cybernethics• http://fare.tunes.org
Mathematics is as little a science as grammar is a language. — Ernst Mayr

Post by Stas Boukarev
It's a work file, can't publish it. But it's just a defsystem with
depends-on and components.

Post by Faré
It's hard to tell without seeing the .asd file. The message says that
you completed the load-op of the system, but somehow you never did the
define-op of the system (the new action that tracks the loading of
.asd files so that defsystem-depends-on can be properly staged).
Can you tell us more about the "non-complicated" features that you
use? Do you follow the "best practices" document?
https://github.com/fare/asdf/blob/master/doc/best_practices.md
—♯ƒ • François-René ÐVB Rideau
•Reflection&Cybernethics• http://fare.tunes.org
Don't forget your daily prayer to Baah-kup,
the God of data storage and recovery!

Post by Stas Boukarev
More new warnings from ASDF 3.3, this time I have no idea what it means.
Computing just-done stamp in plan NIL for action
(ASDF/LISP-ACTION:LOAD-OP
"system"), but
dependency (ASDF/FIND-SYSTEM:DEFINE-OP
"system") wasn't done yet!
The .asd file is not public, but it looks perfectly normal without using any
complicated features.

[Faré]

Post by Chream iz
Hi, I am also getting this error when trying to run (asdf:test-system ....).
It is also not finding the test-files but that might be an but in the prove
package?
:defsystem-depends-on (:prove-asdf)
:perform (test-op :after (op c)
(funcall (intern #.(string :run-test-system) :prove-asdf) c)
(asdf:clear-system c)))

There is your culprit: clear-system should NEVER be called within
perform. It's removing the rug under ASDF as it's running -- very BAD,
especially if there are many build phases. Unhappily, prove and other
prove-based system skeletons (e.g. from caveman) have made this
pattern popular. I sent patches to prove & al. at least six months
ago, and wrote about this anti-pattern in my "best_practices"
document, but I suppose the message didn't go around yet. Maybe I
should make it an error for clear-system to be called from within an
active asdf-session?

Stas, if you also use clear-system this way, you also lose for that reason.

—♯ƒ • François-René ÐVB Rideau •Reflection&Cybernethics• http://fare.tunes.org
Young man, in mathematics you don't understand things,
you just get used to them. — John von Neumann (1903-1957)

[Robert Goldman]

So is this done so that prove can damage its internal state while
testing? So that you need to force the tests to reload if you want to
rerun?

If so, can't the same objective be achieved more cleanly by adding a
special method for OPERATION-DONE-P on PROVE's TEST-FILE class?

Post by Faré

Post by Chream iz
Hi, I am also getting this error when trying to run (asdf:test-system ....).
It is also not finding the test-files but that might be an but in the prove
package?
:defsystem-depends-on (:prove-asdf)
:perform (test-op :after (op c)
(funcall (intern #.(string :run-test-system) :prove-asdf) c)
(asdf:clear-system c)))

There is your culprit: clear-system should NEVER be called within
perform. It's removing the rug under ASDF as it's running -- very BAD,
especially if there are many build phases. Unhappily, prove and other
prove-based system skeletons (e.g. from caveman) have made this
pattern popular. I sent patches to prove & al. at least six months
ago, and wrote about this anti-pattern in my "best_practices"
document, but I suppose the message didn't go around yet. Maybe I
should make it an error for clear-system to be called from within an
active asdf-session?
Stas, if you also use clear-system this way, you also lose for that reason.
—♯ƒ • François-René ÐVB Rideau •Reflection&Cybernethics•
http://fare.tunes.org
Young man, in mathematics you don't understand things,
you just get used to them. — John von Neumann (1903-1957)

[Faré]

So is this done so that prove can damage its internal state while testing?
So that you need to force the tests to reload if you want to rerun?
If so, can't the same objective be achieved more cleanly by adding a special
method for OPERATION-DONE-P on PROVE's TEST-FILE class?

Yes and yes.

—♯ƒ • François-René ÐVB Rideau •Reflection&Cybernethics• http://fare.tunes.org
One man alone can be pretty dumb sometimes, but for real bona fide stupidity,
there ain't nothing can beat teamwork. — Edward Abbey

[Faré]

Post by Faré
There is your culprit: clear-system should NEVER be called within
perform. It's removing the rug under ASDF as it's running -- very BAD,
especially if there are many build phases. Unhappily, prove and other
prove-based system skeletons (e.g. from caveman) have made this
pattern popular. I sent patches to prove & al. at least six months
ago, and wrote about this anti-pattern in my "best_practices"
document, but I suppose the message didn't go around yet. Maybe I
should make it an error for clear-system to be called from within an
active asdf-session?

I see 97 mentions of clear-system in .asd files in quicklisp, so
obviously I wasn't thorough in chasing these mentions 6 months ago,
and I shouldn't make that an error until all these mentions are fixed.
But maybe it's possible to issue a warning? Oh well.

—♯ƒ • François-René ÐVB Rideau •Reflection&Cybernethics• http://fare.tunes.org
"Never ascribe to malice that which is caused by greed and ignorance."
— Cal Keegan

[Robert Goldman]

Can we issue a STYLE-WARNING, with an explanation for the likely
explanation (inappropriate use of CLEAR-SYSTEM, possibly related to
PROVE)? I figure we are more likely to get compliance if people
understand what's wrong.

Post by Faré

Post by Faré
There is your culprit: clear-system should NEVER be called within
perform. It's removing the rug under ASDF as it's running -- very BAD,
especially if there are many build phases. Unhappily, prove and other
prove-based system skeletons (e.g. from caveman) have made this
pattern popular. I sent patches to prove & al. at least six months
ago, and wrote about this anti-pattern in my "best_practices"
document, but I suppose the message didn't go around yet. Maybe I
should make it an error for clear-system to be called from within an
active asdf-session?

I see 97 mentions of clear-system in .asd files in quicklisp, so
obviously I wasn't thorough in chasing these mentions 6 months ago,
and I shouldn't make that an error until all these mentions are fixed.
But maybe it's possible to issue a warning? Oh well.
—♯ƒ • François-René ÐVB Rideau •Reflection&Cybernethics•
http://fare.tunes.org
"Never ascribe to malice that which is caused by greed and ignorance."
— Cal Keegan

[Stas Boukarev]

No clear-system in sight, everything is declarative.

Post by Chream iz

Post by Chream iz
Hi, I am also getting this error when trying to run (asdf:test-system

....).

Post by Chream iz
It is also not finding the test-files but that might be an but in the

prove

Post by Chream iz
package?
:defsystem-depends-on (:prove-asdf)
:perform (test-op :after (op c)
(funcall (intern #.(string :run-test-system) :prove-asdf) c)
(asdf:clear-system c)))

There is your culprit: clear-system should NEVER be called within
perform. It's removing the rug under ASDF as it's running -- very BAD,
especially if there are many build phases. Unhappily, prove and other
prove-based system skeletons (e.g. from caveman) have made this
pattern popular. I sent patches to prove & al. at least six months
ago, and wrote about this anti-pattern in my "best_practices"
document, but I suppose the message didn't go around yet. Maybe I
should make it an error for clear-system to be called from within an
active asdf-session?
Stas, if you also use clear-system this way, you also lose for that reason.
—♯ƒ • François-René ÐVB Rideau •Reflection&Cybernethics•
http://fare.tunes.org
Young man, in mathematics you don't understand things,
you just get used to them. — John von Neumann (1903-1957)

[Faré]

Post by Stas Boukarev
No clear-system in sight, everything is declarative.

Do you depend on another system that uses clear-system?
Can you tell us anything about what you or some of your dependnecies
might be doing?

—♯ƒ • François-René ÐVB Rideau •Reflection&Cybernethics• http://fare.tunes.org
In the long run, John Maynard Keynes is dead. — John Perich

[Stas Boukarev]

ASDF keeps inventing good reasons all the time...

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.

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!

It’s a regular depends-on, but why did it work before without

problems?

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 11:13 AM, Stas Boukarev <

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

[Faré]

Post by Stas Boukarev
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

[Stas Boukarev]

The systems working on older asdf versions is wrong?

Post by Faré

Post by Stas Boukarev
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

[Faré]

This post might be inappropriate. Click to display it.

[Faré]

This post might be inappropriate. Click to display it.