test-bundle

[Robert Goldman]

I still see these "dependency not done" warnings in test-bundle on SBCL 
and other implementations (I haven't checked them all, but at least my 
big three: SBCL, Allegro, and CCL).


```
Running test-bundle.script with sbcl-1.4.3-macosx-x64
; loading #P"/Users/rpg/lisp/asdf/test/test-bundle.script"
; Registering system test-asdf
;; loading #P"/Users/rpg/lisp/asdf/test/test-asdf.asd"
TEST-BUNDLE
  ASDF-TEST::*BUNDLE-1* => 
#P"/Users/rpg/lisp/asdf/build/fasls/sbcl-1.4.3-macosx-x64/asdf/test/test-asdf/bundle-1--system.fasl"
  ASDF-TEST::*BUNDLE-2* => 
#P"/Users/rpg/lisp/asdf/build/fasls/sbcl-1.4.3-macosx-x64/asdf/test/test-asdf/bundle-2--system.fasl"
;; loading 
#P"/Users/rpg/lisp/asdf/build/fasls/sbcl-1.4.3-macosx-x64/asdf/test/test-asdf/bundle-1--system.fasl"

WARNING:
   Computing just-done stamp  for action (LOAD-OP
  "test-asdf/bundle-1"), but 
dependency (LOAD-OP

 
"test-asdf/bundle-1"
 "file1") 
wasn't done yet!

WARNING:
   Computing just-done stamp  for action (LOAD-OP
  "test-asdf/bundle-1"), but 
dependency (LOAD-OP

 
"test-asdf/bundle-1"
 "file3") 
wasn't done yet!

WARNING:
   Computing just-done stamp  for action (LOAD-OP
  "test-asdf/bundle-1"), but 
dependency (COMPILE-OP
 "test-asdf/bundle-1") 
wasn't done yet!
;; loading 
#P"/Users/rpg/lisp/asdf/build/fasls/sbcl-1.4.3-macosx-x64/asdf/test/file1.fasl"
;; loading 
#P"/Users/rpg/lisp/asdf/build/fasls/sbcl-1.4.3-macosx-x64/asdf/test/file3.fasl"
;; loading 
#P"/Users/rpg/lisp/asdf/build/fasls/sbcl-1.4.3-macosx-x64/asdf/test/test-asdf/bundle-2--system.fasl"

WARNING:
   Computing just-done stamp  for action (LOAD-OP
  "test-asdf/bundle-2"), but 
dependency (LOAD-OP

 
"test-asdf/bundle-2"
 "file2") 
wasn't done yet!

WARNING:
   Computing just-done stamp  for action (LOAD-OP
  "test-asdf/bundle-2"), but 
dependency (COMPILE-OP
 "test-asdf/bundle-2") 
wasn't done yet!

```

This seems like a bug somewhere, right? And it must be an ASDF bug, 
probably in the definition of LOAD-OP for bundles.


So, even after the last email, I'm inclined to hold up a release until 
I understand this bug and kill it.

Releasing 3.3.2

[Robert Goldman]

I think we are ready to release 3.3.1.5 as 3.3.2

I am quite busy this week, so it will probably take me a while to get 
through the necessary drudgery to actually make the release, but there 
is a good population of fixes to send out, so I'll make it happen.


Best,
r

Re: Issues with package location information on SBCL

[Robert Goldman]

This does seem to illustrate an issue with the current "export 
everything that's in UIOP" strategy.


Should we consider changing this policy?

Or, if we have "internal" functions that we don't want to be visible 
through `UIOP/DRIVER`, should we simply not export them from the 
sub-packages and use `:import-from` to move them among the sub-packages?


Best,
r


On 19 Feb 2018, at 18:22, Faré wrote:

On Mon, Feb 19, 2018 at 7:03 PM, Eric Timmons  
wrote:
Glad to help! I've also opened the following bug on SBCL to let them 
know

about it: https://bugs.launchpad.net/sbcl/+bug/1750466.


Thanks!

Also, I checked that nothing else in ASDF uses 
`parse-define-package-form`,
but I somehow missed until just now that it's actually exported from 
uiop
=/. Is there any concern about another library using it? If so, I can 
try to
fix it in such a way that the output of `parse-define-package-form` 
is

unchanged.

I wouldn't worry about that: grepping through quicklisp systems 
reveals no user.


—♯ƒ • François-René ÐVB Rideau •Reflection• 
http://fare.tunes.org
It costs the nation millions to keep Gandhi living in poverty — 
Sarojini Naidu

Re: Test-multiple

[Robert Goldman]

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

Re: Test-multiple

[Faré]

> ;;; 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• 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

Re: Test-multiple

[Robert Goldman]

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  
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•

http://fare.tunes.org
Everyone hates a martyr. It's no wonder martyrs were burnt at a 
stake.

— E.W. Howe,