Faré ---
Would you please add some comments to test-multiple? I got a failure on that with MKCL under jenkins on linux, but cannot replicate that failure running it myself.
There's no comment saying what this is supposed to test, other than the name, which suggests that it's about testing where there are ... multiple systems defined (incorrectly) in one .asd file? the same systems defined in multiple .asd files?
The test checks to make sure (I believe) that a variable is not rebound when we ask to reload a system, but not how this pertains to correct ASDF function.
thanks! r
test-multiple works for me with asdf 3.3.1.4, mkcl 1.1.10.19-2dbfa99 on Linux 4.14 x64.
This is all long gone from my mental cache. The test could be better commented, but I suppose the purpose can be extracted by looking at its history then looking at related commits, bugs, bug fix commits, mailing-list messages, etc. A starting point: git log --stat test/test-multiple.*
Apparently, it tests support for what is now considered misnamed secondary systems, but was once a kind-of-supported feature, seen in the wild, with nasty consequences sometimes (e.g. infinite loop with quicklisp until relevant fix).
A variable not being rebound is a test that a file hasn't been reloaded.
I'd rather not add comments, but I'll review them gladly.
—♯ƒ • François-René ÐVB Rideau •Reflection&Cybernethics• http://fare.tunes.org Everyone hates a martyr. It's no wonder martyrs were burnt at a stake. — E.W. Howe, "Country Town Sayings", p.7
On Mon, Feb 19, 2018 at 5:21 PM, Robert Goldman rpgoldman@sift.info wrote:
Faré ---
Would you please add some comments to test-multiple? I got a failure on that with MKCL under jenkins on linux, but cannot replicate that failure running it myself.
There's no comment saying what this is supposed to test, other than the name, which suggests that it's about testing where there are ... multiple systems defined (incorrectly) in one .asd file? the same systems defined in multiple .asd files?
The test checks to make sure (I believe) that a variable is not rebound when we ask to reload a system, but not how this pertains to correct ASDF function.
thanks! r
The failure isn't replicable to me, which bothers me some. I suspect it means that it's having side-effects in the file system that aren't entirely cleaned up. I'm eyeballing the test and it *does* affect the filesystem, and it does not remove the files (really symlinks) it creates. So ... potentially there could be insufficiently controlled side-effects that gave me a transient failure? I don't know. I suppose it's also possible that it does something with the filesystem that Jenkins isn't allowed to do, and that's why I got the Jenkins-only failure. But that explanation doesn't explain why I get failure only with Jenkins *and* MKCL.
On 19 Feb 2018, at 16:43, Faré wrote:
test-multiple works for me with asdf 3.3.1.4, mkcl 1.1.10.19-2dbfa99 on Linux 4.14 x64.
This is all long gone from my mental cache. The test could be better commented, but I suppose the purpose can be extracted by looking at its history then looking at related commits, bugs, bug fix commits, mailing-list messages, etc. A starting point: git log --stat test/test-multiple.*
Apparently, it tests support for what is now considered misnamed secondary systems, but was once a kind-of-supported feature, seen in the wild, with nasty consequences sometimes (e.g. infinite loop with quicklisp until relevant fix).
A variable not being rebound is a test that a file hasn't been reloaded.
I'd rather not add comments, but I'll review them gladly.
—♯ƒ • François-René ÐVB Rideau •Reflection&Cybernethics• http://fare.tunes.org Everyone hates a martyr. It's no wonder martyrs were burnt at a stake. — E.W. Howe, "Country Town Sayings", p.7
On Mon, Feb 19, 2018 at 5:21 PM, Robert Goldman rpgoldman@sift.info wrote:
Faré ---
Would you please add some comments to test-multiple? I got a failure on that with MKCL under jenkins on linux, but cannot replicate that failure running it myself.
There's no comment saying what this is supposed to test, other than the name, which suggests that it's about testing where there are ... multiple systems defined (incorrectly) in one .asd file? the same systems defined in multiple .asd files?
The test checks to make sure (I believe) that a variable is not rebound when we ask to reload a system, but not how this pertains to correct ASDF function.
thanks! r
If you let me know what Jenkins happens to be then I may be able to give a look at the problem. I have been planning an update to the latest ASDF for my upcoming (RSN) release of MKCL 1.1.11, so I may as well squeeze that question in.
Regards,
JCB
On Mon, Feb 19, 2018 at 6:56 PM, Robert Goldman rpgoldman@sift.info wrote:
The failure isn't replicable to me, which bothers me some. I suspect it means that it's having side-effects in the file system that aren't entirely cleaned up. I'm eyeballing the test and it *does* affect the filesystem, and it does not remove the files (really symlinks) it creates. So ... potentially there could be insufficiently controlled side-effects that gave me a transient failure? I don't know. I suppose it's also possible that it does something with the filesystem that Jenkins isn't allowed to do, and that's why I got the Jenkins-only failure. But that explanation doesn't explain why I get failure only with Jenkins *and* MKCL.
On 19 Feb 2018, at 16:43, Faré wrote:
test-multiple works for me with asdf 3.3.1.4, mkcl 1.1.10.19-2dbfa99 on Linux 4.14 x64.
This is all long gone from my mental cache. The test could be better commented, but I suppose the purpose can be extracted by looking at its history then looking at related commits, bugs, bug fix commits, mailing-list messages, etc. A starting point: git log --stat test/test-multiple.*
Apparently, it tests support for what is now considered misnamed secondary systems, but was once a kind-of-supported feature, seen in the wild, with nasty consequences sometimes (e.g. infinite loop with quicklisp until relevant fix).
A variable not being rebound is a test that a file hasn't been reloaded.
I'd rather not add comments, but I'll review them gladly.
—♯ƒ • François-René ÐVB Rideau •Reflection&Cybernethics• http://fare.tunes.org Everyone hates a martyr. It's no wonder martyrs were burnt at a stake. — E.W. Howe, "Country Town Sayings", p.7
On Mon, Feb 19, 2018 at 5:21 PM, Robert Goldman rpgoldman@sift.info wrote:
Faré ---
Would you please add some comments to test-multiple? I got a failure on that with MKCL under jenkins on linux, but cannot replicate that failure running it myself.
There's no comment saying what this is supposed to test, other than the name, which suggests that it's about testing where there are ... multiple systems defined (incorrectly) in one .asd file? the same systems defined in multiple .asd files?
The test checks to make sure (I believe) that a variable is not rebound when we ask to reload a system, but not how this pertains to correct ASDF function.
thanks! r
Here's what I see in the Jenkins log:
``` ;;; Loading "/var/lib/jenkins/workspace/asdf/test/file1.lisp" ;;; Warning: Computing just-done stamp in plan NIL for action (PREPARE-SOURCE-OP "test-multiple-too" "file2"), but dependency (LOAD-SOURCE-OP "test-multiple-too" "file1") wasn't done yet! ;;; Loading "/var/lib/jenkins/workspace/asdf/test/file2.lisp" ;;; Loading "/var/lib/jenkins/workspace/asdf/build/fasls/mkcl-1.1.10.17.head.2-2dbfa99-linux-x64/asdf/test/file3.fas" ;;; Compiling /var/lib/jenkins/workspace/asdf/test/file3.lisp. ;;; Finished compiling /var/lib/jenkins/workspace/asdf/test/file3.lisp. ;;; Loading "/var/lib/jenkins/workspace/asdf/build/fasls/mkcl-1.1.10.17.head.2-2dbfa99-linux-x64/asdf/test/file3.fas" ;;; Compiling /var/lib/jenkins/workspace/asdf/test/file4.lisp. ;;; Finished compiling /var/lib/jenkins/workspace/asdf/test/file4.lisp. ;;; Loading "/var/lib/jenkins/workspace/asdf/build/fasls/mkcl-1.1.10.17.head.2-2dbfa99-linux-x64/asdf/test/file4.fas" ;;; Loading "/var/lib/jenkins/workspace/asdf/build/fasls/mkcl-1.1.10.17.head.2-2dbfa99-linux-x64/asdf/test/file3.fas" ;;; Loading "/var/lib/jenkins/workspace/asdf/build/fasls/mkcl-1.1.10.17.head.2-2dbfa99-linux-x64/asdf/test/file3.fas" ;;; Loading "/var/lib/jenkins/workspace/asdf/build/fasls/mkcl-1.1.10.17.head.2-2dbfa99-linux-x64/asdf/test/file4.fas" TEST ABORTED: These two expressions fail comparison with EQUAL: TEST-PACKAGE::*FILE4* evaluates to T NIL evaluates to NIL ```
IIUC from what Fare said earlier, this would indicate that there's a bug in ASDF behavior on MKCL here, because file4.fas should not be loaded twice.
TBH, I have no idea why this happened for me in Jenkins, but not when I tested myself.
Note the warning -- this is a warning message I'm coming to really hate:
1. it has data that looks almost like a type error. If `NIL` is OK for the `PLAN`, then we should have a conditional in the warning format string that just prunes the plan out of the warning message if it's `NIL`. If `NIL` is *not* ok, then we need to explain that it isn't, and there should probably be a different and earlier warning.
2. It assumes that the user will understand what a `just-done stamp` is, and how it fits into a plan. This really asks too much.
3. It doesn't tell the user what's really wrong. And, I suspect in this case it's sort of ASDF's fault, and it's sort of the fault of the system -- the system has a bad name (it is a sub-system without a "slashy name"), and somehow when we have that, we get these warnings. If that's the case, then we should give the user the information about the root cause and suppress these warnings, which are just noise.
Best, r
On 19 Feb 2018, at 19:07, Jean-Claude Beaudoin wrote:
If you let me know what Jenkins happens to be then I may be able to give a look at the problem. I have been planning an update to the latest ASDF for my upcoming (RSN) release of MKCL 1.1.11, so I may as well squeeze that question in.
Regards,
JCB
On Mon, Feb 19, 2018 at 6:56 PM, Robert Goldman rpgoldman@sift.info wrote:
The failure isn't replicable to me, which bothers me some. I suspect it means that it's having side-effects in the file system that aren't entirely cleaned up. I'm eyeballing the test and it *does* affect the filesystem, and it does not remove the files (really symlinks) it creates. So ... potentially there could be insufficiently controlled side-effects that gave me a transient failure? I don't know. I suppose it's also possible that it does something with the filesystem that Jenkins isn't allowed to do, and that's why I got the Jenkins-only failure. But that explanation doesn't explain why I get failure only with Jenkins *and* MKCL.
On 19 Feb 2018, at 16:43, Faré wrote:
test-multiple works for me with asdf 3.3.1.4, mkcl 1.1.10.19-2dbfa99 on Linux 4.14 x64.
This is all long gone from my mental cache. The test could be better commented, but I suppose the purpose can be extracted by looking at its history then looking at related commits, bugs, bug fix commits, mailing-list messages, etc. A starting point: git log --stat test/test-multiple.*
Apparently, it tests support for what is now considered misnamed secondary systems, but was once a kind-of-supported feature, seen in the wild, with nasty consequences sometimes (e.g. infinite loop with quicklisp until relevant fix).
A variable not being rebound is a test that a file hasn't been reloaded.
I'd rather not add comments, but I'll review them gladly.
—♯ƒ • François-René ÐVB Rideau •Reflection&Cybernethics• http://fare.tunes.org Everyone hates a martyr. It's no wonder martyrs were burnt at a stake. — E.W. Howe, "Country Town Sayings", p.7
On Mon, Feb 19, 2018 at 5:21 PM, Robert Goldman rpgoldman@sift.info wrote:
Faré ---
Would you please add some comments to test-multiple? I got a failure on that with MKCL under jenkins on linux, but cannot replicate that failure running it myself.
There's no comment saying what this is supposed to test, other than the name, which suggests that it's about testing where there are ... multiple systems defined (incorrectly) in one .asd file? the same systems defined in multiple .asd files?
The test checks to make sure (I believe) that a variable is not rebound when we ask to reload a system, but not how this pertains to correct ASDF function.
thanks! r
Robert P. Goldman Research Fellow Smart Information Flow Technologies (d/b/a SIFT, LLC)
319 N. First Ave., Suite 400 Minneapolis, MN 55401
Voice: (612) 326-3934 Email: rpgoldman@SIFT.net
;;; Warning: Computing just-done stamp in plan NIL for action (PREPARE-SOURCE-OP
"test-multiple-too" "file2"), but dependency (LOAD-SOURCE-OP
"test-multiple-too"
"file1") wasn't done yet!
Note the warning -- this is a warning message I'm coming to really hate:
it has data that looks almost like a type error. If NIL is OK for the PLAN, then we should have a conditional in the warning format string that just prunes the plan out of the warning message if it's NIL. If NIL is not ok, then we need to explain that it isn't, and there should probably be a different and earlier warning.
Indeed, the warning message should use ~@[in plan ~A~].
It assumes that the user will understand what a just-done stamp is, and how it fits into a plan. This really asks too much.
This is indeed a very bad error message for users to see. Admittedly, it's usually a symptom of a bug in the build system (or an extension thereof), so users ideally never see them.
It doesn't tell the user what's really wrong. And, I suspect in this case it's sort of ASDF's fault, and it's sort of the fault of the system -- the system has a bad name (it is a sub-system without a "slashy name"), and somehow when we have that, we get these warnings. If that's the case, then we should give the user the information about the root cause and suppress these warnings, which are just noise.
I don't know what the root cause is here, but this looks like the same bug that is supposed to be fixed, and the fix works for me. Does Jenkins use some fancy filesystem setup that confuses the timestamp checking?
—♯ƒ • François-René ÐVB Rideau •Reflection&Cybernethics• http://fare.tunes.org Politics is the only profession that does without learning, probably because those who suffer from mistakes are not the same as those who make them. — Achille Tournier, Pensées d'automne
On 20 Feb 2018, at 10:49, Faré wrote:
I don't know what the root cause is here, but this looks like the same bug that is supposed to be fixed, and the fix works for me. Does Jenkins use some fancy filesystem setup that confuses the timestamp checking?
It might. Jenkins does everything in a workspace, which is similar to a home directory, but isn't one.
What's odd is that I only see this issue with MKCL. So it would have to be something special about the Jenkins workspace that is visible to MKCL, but not to other lisps.
So I'm still puzzled.
R
On 20 Feb 2018, at 13:07, Robert Goldman wrote:
On 20 Feb 2018, at 10:49, Faré wrote:
I don't know what the root cause is here, but this looks like the same bug that is supposed to be fixed, and the fix works for me. Does Jenkins use some fancy filesystem setup that confuses the timestamp checking?
It might. Jenkins does everything in a workspace, which is similar to a home directory, but isn't one.
What's odd is that I only see this issue with MKCL. So it would have to be something special about the Jenkins workspace that is visible to MKCL, but not to other lisps.
So I'm still puzzled.
R
My latest test on Jenkins did *not* fail. I'm not happy about this -- I suspect there's something uncontrolled about the behavior of the test -- but on the other hand, I don't believe that this transient failure is a reason to hold back a release.
R
-
Faré -
Jean-Claude Beaudoin -
Robert Goldman