I have finally fixed an essential "dependency problem" of ASDF by introducing a new operation "parent-load-op" which I'm going to rename "prepare-op". This in turns opens the way for many many improvements to the internals, which will make ASDF easier to explain and extend, so expect some work there — and I'm postponing any 2.27 release until that's stable. However, any and all changes introduces potential backwards-incompatibility, and I'll be searching through packages available in quicklisp for any potential such incompatibility before I go ahead with renaming internals. Some details: In 2.26.14, I introduced an operation called parent-load-op, which ensures the dependencies of the parent are loaded before the child is compiled. This ensures the graph produced by following component-depends-on isn't missing crucial dependencies instead of relying on the specifics of the TRAVERSE algorithm (and at long last I really understand what rpgoldman was telling me while we were writing the ASDF 2 paper). I had to tweak traverse, because parent-load-op trickles upward, not downward, the component hierarchy: you depend-on the parent-load-op of your parents, but not on that of your children (that would create a circular dependency). So I had to add a check in TRAVERSE (now — 2.26.20 — in its nice and short visit-children helper) to not automatically propagate subclasses of parent-op dependencies downward. I started thinking about a theory of parent-op and child-op dependencies and how to rewrite the current hierarchy, and as I was doing it found that actually, parent-load-op is not parent-specific: it's actually a dependency-op or prepare-op, that ensures that the image is prepared to compile or load the component, by having already loaded all the dependencies, and it could do it for the "normal" case, too: instead of having load-op or compile-op depend on the load-op of all the dependencies, they could simply depend on prepare-op. Then, we don't need to have traverse know anything about propagating dependencies either downward or upward, it can all be done with two methods on component-depends-on! [which is one of the many misnomers in ASDF: components don't depend on anything, it's (operation . component) pairs, which I'm calling "actions", like in Kent Pitman's article), that are nodes in the dependency graph]. It was all quite a revelation. And so I'll be working on drastically cutting down ASDF, and making the basic dependency graph cleaner, which will make ASDF much simpler and more reliable to extend. Some change I'd like to make if no one uses these internals (or only use them without relying on the current setup to define methods, in which case I can define an alias]: module ==> make it a subclass of both child-component and parent-component system ==> is a parent but not a child, and thus not a module. component-depends-on ==> rename it to action-depends-on if-component-fails ==> I'd like to remove it altogether, it's a crock that doesn't go well with the reified graph model. I suppose I could preserve it the hard way, but would be ugly. mark-operation-done ==> maybe rename to stamp-action ? Or at least mark-action-done. operation-description ==> action-description component-visited-p ==> action-visited-p component-depends-on ==> component-dependencies - likely not possible for backwards compatibility. component-load-dependencies ==> component-depends-on - same. Then component-sibling-dependencies. circular-dependencies-components ==> circular-dependencies-actions, it's a list of (operation . component) pairs hash-tables of symbol, component ==> hash-tables of operations and component, systematically using make-sub-operation make-sub-operation ==> find-operation, to work like find-component, and ignore the first contextual argument if the second is already an object. Canonicalizes named operations while still allowing explicitly different operations of the same class. module-components ==> component-children module-components-by-name ==> component-children-by-name load-fasl-op ==> load-system-fasl-op load-op ==> split between load-op and load-fasl-op (see below). Alternatively, for backwards compatibility, call the latter load-compiled-op My current temporary names would also be renamed: parent-load-op ==> prepare-op (or dependency-op?) visit-children ==> done away with -- replaced entirely by one component-depends-on method. parent-op ==> upward-operation child-op ==> downward-operation Chasing "horizontal" dependencies to siblings under the same parent would be done entirely by prepare-op, which is a subclass of upward-operation. load-op would remain a downward-operation, but would have a separate strategy for deciding whether to delegate to load-source-op, load-fasl-op or load-system-fasl-op or whatever (e.g. some load-instrumented-op extension), based on a generalization of the force / force-not mechanism that would decide the compilation strategy. These ones would NOT be downward-operations, unlike the main load-op which would be a downward-op and propagate everywhere as appropriate. Since parents vs children vs siblings are no longer a fixture of the TRAVERSE algorithm but something reified in the object graph through the normal use of simple methods, you can easily define arbitrary graphs of your choice, instead of ASDF only being applicable to one particular kind of graph shapes. etc. Then the base object hierarchy becomes robust and stable, and it makes sense and is easy to extend, with a nice well-define dependency graph, that can be reified thanks to POIU's current make-parallel-plan. A lot of that (and previous) work was prompted by the desire to keep POIU working as I refactored ASDF, and then the desire to fix ASDF based on the things understood while adapting POIU. POIU interestingly builds an actual complete graph of dependencies from the object model, or at least did it within each system, because, not being able to fix ASDF, Andreas Fuchs had intercepted perform, not operate or perform-plan (which didn't exist then). One ugly inefficient detail Andreas had in his graph-building function was an additional-dependencies argument he used to copy the parent's dependencies on each and every child. That's really ugly. I wanted to get rid of it, but discovered I couldn't... until I invented parent-load-op, which makes it unnecessary, and also promises to fix compute-action-stamp. In any case, Andreas Fuchs certainly deserves a lot of credit for his POIU hack, of which I didn't fully understand the elaborate until I had to fully reimplement it bit by bit, to make it cleaner and fit the new ASDF, and admire each detail he got just right. And he did it all as an add-on, without changing a single line of ASDF itself (though overriding a few definitions — which I promptly made unnecessary once I became ASDF maintainer). That's impressive. And the language is also impressive for allowing such things, at all. But the result was absolute ugly. Being the unexpected co-maintainer of the two sometimes conflicting pieces of software has led me to make both of them ugly no more. PS: In the spirit of people who credit John McCarthy with having discovered Lisp rather than created it, I like think ASDF was a great *discovery* made by Dan Barlow, rather than some badly unfinished program he created; I'm only just reaching what I believe is the bottom of the matter, and it's much nicer than I thought it was, or than Dan probably understood, either, at the time. PPS: I was going to sent a mail to this list, then it grew very long into what would be a blog post, then two, etc. Scrap it. Back to a notice to the list. Still grew up to be too long. Oh well. I hope at least one of you read that and wasn't bored. —♯ƒ • 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
OK, this is now committed as of ASDF 2.26.21 and POIU 1.29.3. It's slightly smaller, it's much cleaner, and it all works. I hope I have not broken users — please test. Casualties of the cleanup were :feature and :if-component-dep-fails. They were just horrible things. Another, disabled, :feature feature could replace it: it was never working in ASDF 1, but I fixed it some time ago and it's there behind a cerror waiting to be used. On the other hand, there are many new features for those who extend ASDF or inspect its results. ASDF and POIU are now officially equivalent, using the exact same traversal functions, just with different production functions: ASDF drops information and creates a linear list, POIU keeps all the information and builds a graph representation. If you want to examine the graph, you can. component-depends-on is now more powerful: it faithfully describes the graph without any implicit inherited dependency, it allows you to express operations that do not flow down the component hierarchy, but instead go up or sideways or don't flow (like test-op), or skip merrily around whichever way you prefer. It may return component objects as well as designators relative to the argument component's parent, and the resolve-dependency-spec is made available to you for custom operations. component-self-dependencies and the default input-files method were fixed to handle more cases. force is implemented via a simple method on prepare-op, and the mechanism it and force-not use has been factored in a way that it could be reused for other interesting future uses. A whole slew of special cases were done away with. For the first time, ever, I can say that ASDF has a design that makes sense. It's not perfect, it's not ideal, but it does make sense. I may write for Dan Barlow his ASDF apology. —♯ƒ • François-René ÐVB Rideau •Reflection&Cybernethics• http://fare.tunes.org There are two kinds of pacifists: those who try to disarm the criminals, and those who try to disarm the victims. On Fri, Dec 14, 2012 at 2:48 AM, Faré <fahree@gmail.com> wrote:
I have finally fixed an essential "dependency problem" of ASDF by introducing a new operation "parent-load-op" which I'm going to rename "prepare-op". This in turns opens the way for many many improvements to the internals, which will make ASDF easier to explain and extend, so expect some work there — and I'm postponing any 2.27 release until that's stable. However, any and all changes introduces potential backwards-incompatibility, and I'll be searching through packages available in quicklisp for any potential such incompatibility before I go ahead with renaming internals.
Some details:
In 2.26.14, I introduced an operation called parent-load-op, which ensures the dependencies of the parent are loaded before the child is compiled. This ensures the graph produced by following component-depends-on isn't missing crucial dependencies instead of relying on the specifics of the TRAVERSE algorithm (and at long last I really understand what rpgoldman was telling me while we were writing the ASDF 2 paper). I had to tweak traverse, because parent-load-op trickles upward, not downward, the component hierarchy: you depend-on the parent-load-op of your parents, but not on that of your children (that would create a circular dependency). So I had to add a check in TRAVERSE (now — 2.26.20 — in its nice and short visit-children helper) to not automatically propagate subclasses of parent-op dependencies downward. I started thinking about a theory of parent-op and child-op dependencies and how to rewrite the current hierarchy, and as I was doing it found that actually, parent-load-op is not parent-specific: it's actually a dependency-op or prepare-op, that ensures that the image is prepared to compile or load the component, by having already loaded all the dependencies, and it could do it for the "normal" case, too: instead of having load-op or compile-op depend on the load-op of all the dependencies, they could simply depend on prepare-op. Then, we don't need to have traverse know anything about propagating dependencies either downward or upward, it can all be done with two methods on component-depends-on! [which is one of the many misnomers in ASDF: components don't depend on anything, it's (operation . component) pairs, which I'm calling "actions", like in Kent Pitman's article), that are nodes in the dependency graph]. It was all quite a revelation. And so I'll be working on drastically cutting down ASDF, and making the basic dependency graph cleaner, which will make ASDF much simpler and more reliable to extend.
Some change I'd like to make if no one uses these internals (or only use them without relying on the current setup to define methods, in which case I can define an alias]:
module ==> make it a subclass of both child-component and parent-component system ==> is a parent but not a child, and thus not a module. component-depends-on ==> rename it to action-depends-on if-component-fails ==> I'd like to remove it altogether, it's a crock that doesn't go well with the reified graph model. I suppose I could preserve it the hard way, but would be ugly. mark-operation-done ==> maybe rename to stamp-action ? Or at least mark-action-done. operation-description ==> action-description component-visited-p ==> action-visited-p component-depends-on ==> component-dependencies - likely not possible for backwards compatibility. component-load-dependencies ==> component-depends-on - same. Then component-sibling-dependencies. circular-dependencies-components ==> circular-dependencies-actions, it's a list of (operation . component) pairs hash-tables of symbol, component ==> hash-tables of operations and component, systematically using make-sub-operation make-sub-operation ==> find-operation, to work like find-component, and ignore the first contextual argument if the second is already an object. Canonicalizes named operations while still allowing explicitly different operations of the same class. module-components ==> component-children module-components-by-name ==> component-children-by-name load-fasl-op ==> load-system-fasl-op load-op ==> split between load-op and load-fasl-op (see below). Alternatively, for backwards compatibility, call the latter load-compiled-op
My current temporary names would also be renamed: parent-load-op ==> prepare-op (or dependency-op?) visit-children ==> done away with -- replaced entirely by one component-depends-on method. parent-op ==> upward-operation child-op ==> downward-operation
Chasing "horizontal" dependencies to siblings under the same parent would be done entirely by prepare-op, which is a subclass of upward-operation. load-op would remain a downward-operation, but would have a separate strategy for deciding whether to delegate to load-source-op, load-fasl-op or load-system-fasl-op or whatever (e.g. some load-instrumented-op extension), based on a generalization of the force / force-not mechanism that would decide the compilation strategy. These ones would NOT be downward-operations, unlike the main load-op which would be a downward-op and propagate everywhere as appropriate. Since parents vs children vs siblings are no longer a fixture of the TRAVERSE algorithm but something reified in the object graph through the normal use of simple methods, you can easily define arbitrary graphs of your choice, instead of ASDF only being applicable to one particular kind of graph shapes. etc. Then the base object hierarchy becomes robust and stable, and it makes sense and is easy to extend, with a nice well-define dependency graph, that can be reified thanks to POIU's current make-parallel-plan.
A lot of that (and previous) work was prompted by the desire to keep POIU working as I refactored ASDF, and then the desire to fix ASDF based on the things understood while adapting POIU. POIU interestingly builds an actual complete graph of dependencies from the object model, or at least did it within each system, because, not being able to fix ASDF, Andreas Fuchs had intercepted perform, not operate or perform-plan (which didn't exist then). One ugly inefficient detail Andreas had in his graph-building function was an additional-dependencies argument he used to copy the parent's dependencies on each and every child. That's really ugly. I wanted to get rid of it, but discovered I couldn't... until I invented parent-load-op, which makes it unnecessary, and also promises to fix compute-action-stamp. In any case, Andreas Fuchs certainly deserves a lot of credit for his POIU hack, of which I didn't fully understand the elaborate until I had to fully reimplement it bit by bit, to make it cleaner and fit the new ASDF, and admire each detail he got just right. And he did it all as an add-on, without changing a single line of ASDF itself (though overriding a few definitions — which I promptly made unnecessary once I became ASDF maintainer). That's impressive. And the language is also impressive for allowing such things, at all. But the result was absolute ugly. Being the unexpected co-maintainer of the two sometimes conflicting pieces of software has led me to make both of them ugly no more.
PS: In the spirit of people who credit John McCarthy with having discovered Lisp rather than created it, I like think ASDF was a great *discovery* made by Dan Barlow, rather than some badly unfinished program he created; I'm only just reaching what I believe is the bottom of the matter, and it's much nicer than I thought it was, or than Dan probably understood, either, at the time.
PPS: I was going to sent a mail to this list, then it grew very long into what would be a blog post, then two, etc. Scrap it. Back to a notice to the list. Still grew up to be too long. Oh well.
I hope at least one of you read that and wasn't bored.
—♯ƒ • 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
Faré <fahree@gmail.com> writes:
OK, this is now committed as of ASDF 2.26.21 and POIU 1.29.3. It's slightly smaller, it's much cleaner, and it all works. I hope I have not broken users — please test.
Casualties of the cleanup were :feature and :if-component-dep-fails. They were just horrible things.
FYI, the sb-rotate-byte contrib in SBCL uses :if-component-dep-fails. Zach
Casualties of the cleanup were :feature and :if-component-dep-fails. They were just horrible things.
FYI, the sb-rotate-byte contrib in SBCL uses :if-component-dep-fails.
I've contacted the SBCL maintainers. Hopefully they will revert to #+x86-64 and such until a new asdf is universal. But that begs the question: how do we support old versions... and should we try? I can imagine plenty of horribly klugy ways to make it work, but... ouch. —♯ƒ • François-René ÐVB Rideau •Reflection&Cybernethics• http://fare.tunes.org I'd rather write programs that write programs than write programs — Dick Sites
Faré <fahree@gmail.com> writes:
Casualties of the cleanup were :feature and :if-component-dep-fails. They were just horrible things.
FYI, the sb-rotate-byte contrib in SBCL uses :if-component-dep-fails.
I've contacted the SBCL maintainers. Hopefully they will revert to #+x86-64 and such until a new asdf is universal. But that begs the question: how do we support old versions... and should we try? SBCL is already change, but if people want to use newer ASDF, then can also use newer SBCL.
-- With best regards, Stas.
Zach Beane <xach@xach.com> writes:
Faré <fahree@gmail.com> writes:
OK, this is now committed as of ASDF 2.26.21 and POIU 1.29.3. It's slightly smaller, it's much cleaner, and it all works. I hope I have not broken users — please test.
Casualties of the cleanup were :feature and :if-component-dep-fails. They were just horrible things.
FYI, the sb-rotate-byte contrib in SBCL uses :if-component-dep-fails.
What is the correct way now to indicate that a file is part of a system, but should only be compiled if a given feature is present? Thanks, Christophe
On Mon, Dec 17, 2012 at 2:19 PM, Christophe Rhodes <csr21@cantab.net> wrote:
Zach Beane <xach@xach.com> writes:
Faré <fahree@gmail.com> writes:
OK, this is now committed as of ASDF 2.26.21 and POIU 1.29.3. It's slightly smaller, it's much cleaner, and it all works. I hope I have not broken users — please test.
Casualties of the cleanup were :feature and :if-component-dep-fails. They were just horrible things.
FYI, the sb-rotate-byte contrib in SBCL uses :if-component-dep-fails.
What is the correct way now to indicate that a file is part of a system, but should only be compiled if a given feature is present?
It appears that the SBCL contrib SB-ROTATE-BYTE uses :IF-COMPONENT-DEP-FAILS. In the spirit of not breaking everyone's existing SBCL installation, I have implemented *limited* compatibility with :IF-COMPONENT-DEP-FAILS in ASDF 2.26.27, sufficient to cover the usage observed in the wild. The restrictions are as follows: (a) Only the :ignore behavior is implemented. :try-next (which is a misnomer since it tries all) is seen as :ignore. It is not possible to directly reproduce :try-next behavior in ASDF 2.27. If you want to fail when none of some features is present, you should explicitly use somewhere in your system: #-(or foo bar baz) (error "unsupported implementation") (b) I only support :IF-COMPONENT-DEP-FAILS for dependencies on COMPILE-OP, which is what the only known (to me) users use. Please report any occurrence of a different usage pattern in the wild, if possible before release 2.27 (which I target around Christmas). :IF-COMPONENT-DEP-FAILS is still strongly deprecated, though its current pattern of use will still work: (:module "foo" :if-component-dep-fails :ignore :components ((:file "x86-64-vm" :in-order-to (compile-op (feature :x86-64))))) For legacy compatibility, I recommend either using the like of #+(and sbcl x86-64) (:file "x86-64-vm") unless you insist on making the file part of the system object, as per Christophe's legitimate requirement. Going forward, when ASDF 2.27 becomes widespread, I recommend the future use of (:file "x86-64-vm" :if-feature (:and :sbcl :x86-64)) Note only that (a) :if-feature allows for boolean combinations of features with :and :or :not, unlike :if-component-dep-fails; (b) dependencies on a :if-feature component are automatically removed if removes when the component has been disabled by lack of feature; (c) the component still part of the component tree, which will make Christophe happy; (d) :if-feature does not involve multi-level special-case complexity in the traverse algorithm to invalidate the patent meaning of the graph, which makes *me* happy. There will be a feature #+asdf2.27 in case it is useful to detect the availability of the massively refactored ASDF internals. I apologize for the temporary breakage, but I suppose that's what testing before release is all for. Thanks a lot for bearing with me, thanks a lot to Xach for your prompt feedback, and thanks to stassats for quickly fixing SB-ROTATE-BYTE in SBCL HEAD (which retrospectively is not needed anymore - my apologies for the make work). PS: Only semi-relatedly, there is now a new generic function: RESOLVE-DEPENDENCY-COMBINATION (COMPONENT COMBINATION ARGUMENTS) called when (COMBINATION . ARGUMENTS) appears as the specification of a dependency to COMPONENT, so you can extend the dependency language. —♯ƒ • François-René ÐVB Rideau •Reflection&Cybernethics• http://fare.tunes.org Common Lisp makes it easy for you to grow your own language; however, it makes it difficult for that language to be the same as anyone else's.
Faré <fahree@gmail.com> writes:
On Mon, Dec 17, 2012 at 2:19 PM, Christophe Rhodes <csr21@cantab.net> wrote:
Zach Beane <xach@xach.com> writes:
Faré <fahree@gmail.com> writes:
OK, this is now committed as of ASDF 2.26.21 and POIU 1.29.3. It's slightly smaller, it's much cleaner, and it all works. I hope I have not broken users — please test.
Casualties of the cleanup were :feature and :if-component-dep-fails. They were just horrible things.
FYI, the sb-rotate-byte contrib in SBCL uses :if-component-dep-fails.
What is the correct way now to indicate that a file is part of a system, but should only be compiled if a given feature is present?
It appears that the SBCL contrib SB-ROTATE-BYTE uses :IF-COMPONENT-DEP-FAILS. In the spirit of not breaking everyone's existing SBCL installation, I have implemented *limited* compatibility with :IF-COMPONENT-DEP-FAILS in ASDF 2.26.27, sufficient to cover the usage observed in the wild.
I'm trying to build my software with 2.26.28, and I get this: ASDF could not load sb-cover because error opening #P"/usr/local/lib/sbcl/sb-md5/md5-ASDF-TMP.fasl": Permission denied. What should I do? Zach
On Tue, Dec 18, 2012 at 8:46 AM, Zach Beane <xach@xach.com> wrote:
Faré <fahree@gmail.com> writes:
On Mon, Dec 17, 2012 at 2:19 PM, Christophe Rhodes <csr21@cantab.net> wrote:
Zach Beane <xach@xach.com> writes:
Faré <fahree@gmail.com> writes:
OK, this is now committed as of ASDF 2.26.21 and POIU 1.29.3. It's slightly smaller, it's much cleaner, and it all works. I hope I have not broken users — please test.
Casualties of the cleanup were :feature and :if-component-dep-fails. They were just horrible things.
FYI, the sb-rotate-byte contrib in SBCL uses :if-component-dep-fails.
What is the correct way now to indicate that a file is part of a system, but should only be compiled if a given feature is present?
It appears that the SBCL contrib SB-ROTATE-BYTE uses :IF-COMPONENT-DEP-FAILS. In the spirit of not breaking everyone's existing SBCL installation, I have implemented *limited* compatibility with :IF-COMPONENT-DEP-FAILS in ASDF 2.26.27, sufficient to cover the usage observed in the wild.
I'm trying to build my software with 2.26.28, and I get this:
ASDF could not load sb-cover because error opening #P"/usr/local/lib/sbcl/sb-md5/md5-ASDF-TMP.fasl": Permission denied.
What should I do?
It works for me. I suspect you might not have compiled sb-md5 from clean, and due to that bug I fixed in 2.26.9 which required a substantial refactoring, ASDF can now see that file was not up-to-date, when it couldn't see it earlier. Can you recompile this contrib from clean, either in place (by getting proper access rights) or in another directly from which you reinstall afterwards? —♯ƒ • François-René ÐVB Rideau •Reflection&Cybernethics• http://fare.tunes.org Nostalgia isn’t what it used to be.
Faré <fahree@gmail.com> writes:
It works for me. I suspect you might not have compiled sb-md5 from clean, and due to that bug I fixed in 2.26.9 which required a substantial refactoring, ASDF can now see that file was not up-to-date, when it couldn't see it earlier. Can you recompile this contrib from clean, either in place (by getting proper access rights) or in another directly from which you reinstall afterwards?
What does "compile from clean" mean? What's a way to *not* compile from clean? Zach
Zach Beane <xach@xach.com> writes:
Faré <fahree@gmail.com> writes:
It works for me. I suspect you might not have compiled sb-md5 from clean, and due to that bug I fixed in 2.26.9 which required a substantial refactoring, ASDF can now see that file was not up-to-date, when it couldn't see it earlier. Can you recompile this contrib from clean, either in place (by getting proper access rights) or in another directly from which you reinstall afterwards?
What does "compile from clean" mean? What's a way to *not* compile from clean?
FYI, here's a simplified way to reproduce it. From the ASDF source directory, with the latest checkout: sbcl --non-interactive --no-userinit --load asdf.lisp --eval "(require :sb-md5)" This lands in the debugger with the permissions error on three different SBCL installations of mine. Am I doing something wrong? Zach
It works for me. I suspect you might not have compiled sb-md5 from clean, and due to that bug I fixed in 2.26.9 which required a substantial refactoring, ASDF can now see that file was not up-to-date, when it couldn't see it earlier. Can you recompile this contrib from clean, either in place (by getting proper access rights) or in another directly from which you reinstall afterwards?
What does "compile from clean" mean? What's a way to *not* compile from clean?
Good question. When you build SBCL from source, update it then build again, does it remove the fasls in the contrib before to build them, or does it rely on ASDF for only compiling what's needed? In the latter case, this will may produce an "unclean" installation. Then, because sb-md5.asd was recently updated, and ASDF now (since 2.26.21) sees that as requiring .fasls to be updated (in case the dependencies have changed in a crucial way). If you clean.sh then make.sh your SBCL, it should all work. Another explanation would be if the installation process of SBCL does not preserve timestamps, in which case ASDF will be very unhappy about it, which it wouldn't have been before if all fasl's happened to have been written at the same time as their lisp source file or before. I believe the tar and untar'ing by which things are installed preserves the timestamps, though (and was designed precisely for this purpose to be fulfilled portably without relying on GNU install).
FYI, here's a simplified way to reproduce it. From the ASDF source directory, with the latest checkout:
sbcl --non-interactive --no-userinit --load asdf.lisp --eval "(require :sb-md5)"
This lands in the debugger with the permissions error on three different SBCL installations of mine. Am I doing something wrong?
Note that indeed, one of my installations had to be recompiled that way, so whichever explanatino there is, I suppose the problem is pervasive with SBCL. I don't know what to say, except: "if you've been installing SBCL from updated source, you might have to recompile some contrib". —♯ƒ • François-René ÐVB Rideau •Reflection&Cybernethics• http://fare.tunes.org If all values are relative, then cannibalism is a matter of taste. — Leo Strauss
On Tue, Dec 18, 2012 at 11:09 AM, Zach Beane <xach@xach.com> wrote:
Faré <fahree@gmail.com> writes:
I don't know what to say, except: "if you've been installing SBCL from updated source, you might have to recompile some contrib".
I'd prefer something less disruptive, please.
You want me to special case the detection that SBCL contribs built from an updated source may be out of date? That's not going to be very clean. How many people build from updated source, and if they do how hard is it for them to rebuild from source and/or get write permissions to let ASDF update sb-md5.fasl in its installed location? Is that kluge worth it? I'm not even sure how to do it. Do you have a better solution? —♯ƒ • François-René ÐVB Rideau •Reflection&Cybernethics• http://fare.tunes.org The rule is, jam to-morrow and jam yesterday, but never jam today. — Lewis Carroll
Faré <fahree@gmail.com> writes:
On Tue, Dec 18, 2012 at 11:09 AM, Zach Beane <xach@xach.com> wrote:
Faré <fahree@gmail.com> writes:
I don't know what to say, except: "if you've been installing SBCL from updated source, you might have to recompile some contrib".
I'd prefer something less disruptive, please.
You want me to special case the detection that SBCL contribs built from an updated source may be out of date? That's not going to be very clean. How many people build from updated source, and if they do how hard is it for them to rebuild from source and/or get write permissions to let ASDF update sb-md5.fasl in its installed location? Is that kluge worth it? I'm not even sure how to do it. Do you have a better solution?
The only solution I understand so far is to run SBCL as root and rebuild the contribs, or modify the system directory permissions so a user can rebuild the contribs. That seems like a hassle, and I'd prefer not to do it, especially since I have a lot of SBCL installations around. It's also unlike anything else I normally do to fix CL problems. Are there changes to SBCL that could be made to mitigate the problem? "Update SBCL and reinstall" is something I'm quite familiar with doing. Zach
sb-md5 hasn't been modified in years, but it depends on sb-rotate-byte which was just tweaked because of :if-component-dep-fails. ASDF used to not propagate timestamps from system to system, or from .asd file to the system internals, but now it does both, and so the change in sb-rotate-byte.asd now causes sb-md5 to be out of date. stassats tells me SBCL usually does a clean.sh as the first thing in make.sh, so if you built with make.sh instead of slam.sh, and didn't update your source in between make.sh and install.sh, there should be not have been an issue. I suppose my position is: * if the bug is just due to unclean builds of SBCL, I'm not willing to fix, just rebuild SBCL from clean and reinstall. * if the bug is due to some deeper incompatibility that will affect people using binary distributions built from clean, or with the SBCL installation itself having been unclean, I shall write a fix or workaround (but then we should also fix these distributions or SBCL to be cleaner). But is that the case?
The only solution I understand so far is to run SBCL as root and rebuild the contribs, or modify the system directory permissions so a user can rebuild the contribs. That seems like a hassle, and I'd prefer not to do it, especially since I have a lot of SBCL installations around. It's also unlike anything else I normally do to fix CL problems.
Are there changes to SBCL that could be made to mitigate the problem? "Update SBCL and reinstall" is something I'm quite familiar with doing.
Update and reinstall from clean should do it. —♯ƒ • François-René ÐVB Rideau •Reflection&Cybernethics• http://fare.tunes.org If all values are relative, then cannibalism is a matter of taste. — Leo Strauss
Faré <fahree@gmail.com> writes:
sb-md5 hasn't been modified in years, but it depends on sb-rotate-byte which was just tweaked because of :if-component-dep-fails. ASDF used to not propagate timestamps from system to system, or from .asd file to the system internals, but now it does both, and so the change in sb-rotate-byte.asd now causes sb-md5 to be out of date.
stassats tells me SBCL usually does a clean.sh as the first thing in make.sh, so if you built with make.sh instead of slam.sh, and didn't update your source in between make.sh and install.sh, there should be not have been an issue.
Ok, I updated to the latest SBCL sources, did this: sh clean.sh sh make.sh sudo sh install.sh Then I change to the ASDF directory and do this: sbcl --non-interactive --no-userinit --load asdf.lisp --eval "(require :sb-md5)" I still get the permission error. Did I miss a step? Zach
On Tue, Dec 18, 2012 at 12:01 PM, Zach Beane <xach@xach.com> wrote:
Faré <fahree@gmail.com> writes:
sb-md5 hasn't been modified in years, but it depends on sb-rotate-byte which was just tweaked because of :if-component-dep-fails. ASDF used to not propagate timestamps from system to system, or from .asd file to the system internals, but now it does both, and so the change in sb-rotate-byte.asd now causes sb-md5 to be out of date.
stassats tells me SBCL usually does a clean.sh as the first thing in make.sh, so if you built with make.sh instead of slam.sh, and didn't update your source in between make.sh and install.sh, there should be not have been an issue.
Ok, I updated to the latest SBCL sources, did this:
sh clean.sh sh make.sh sudo sh install.sh
Then I change to the ASDF directory and do this:
sbcl --non-interactive --no-userinit --load asdf.lisp --eval "(require :sb-md5)"
I still get the permission error.
Did I miss a step?
No, you're not missing anything. That's weird: I tried, and it worked for me. Can you attach a trace of this? (trace asdf::visit-action asdf::compute-action-stamp asdf::safe-file-write-date) (asdf:traverse (make-instance 'asdf:load-op) (asdf:find-system :sb-md5)) —♯ƒ • François-René ÐVB Rideau •Reflection&Cybernethics• http://fare.tunes.org It should be a grammatical if not legal offense to ascribe thoughts, opinions and decisions to "we" without a signed power of attorney.
On Tue, Dec 18, 2012 at 1:20 PM, Faré <fahree@gmail.com> wrote:
On Tue, Dec 18, 2012 at 12:01 PM, Zach Beane <xach@xach.com> wrote:
Faré <fahree@gmail.com> writes:
sb-md5 hasn't been modified in years, but it depends on sb-rotate-byte which was just tweaked because of :if-component-dep-fails. ASDF used to not propagate timestamps from system to system, or from .asd file to the system internals, but now it does both, and so the change in sb-rotate-byte.asd now causes sb-md5 to be out of date.
stassats tells me SBCL usually does a clean.sh as the first thing in make.sh, so if you built with make.sh instead of slam.sh, and didn't update your source in between make.sh and install.sh, there should be not have been an issue.
Ok, I updated to the latest SBCL sources, did this:
sh clean.sh sh make.sh sudo sh install.sh
Then I change to the ASDF directory and do this:
sbcl --non-interactive --no-userinit --load asdf.lisp --eval "(require :sb-md5)"
I still get the permission error.
Did I miss a step?
No, you're not missing anything. That's weird: I tried, and it worked for me.
Can you attach a trace of this?
(trace asdf::visit-action asdf::compute-action-stamp asdf::safe-file-write-date) (asdf:traverse (make-instance 'asdf:load-op) (asdf:find-system :sb-md5))
Oh: It work for me in SLIME but I can reproduce the issue with your command-line. I'll investigate some more. My apologies for the frustration. —♯ƒ • François-René ÐVB Rideau •Reflection&Cybernethics• http://fare.tunes.org The fear of death follows from the fear of life. A man who lives fully is prepared to die at any time. — Mark Twain
Faré <fahree@gmail.com> writes:
Ok, I updated to the latest SBCL sources, did this:
sh clean.sh sh make.sh sudo sh install.sh
Then I change to the ASDF directory and do this:
sbcl --non-interactive --no-userinit --load asdf.lisp --eval "(require :sb-md5)"
I still get the permission error.
Did I miss a step?
No, you're not missing anything. That's weird: I tried, and it worked for me.
Can you attach a trace of this?
(trace asdf::visit-action asdf::compute-action-stamp asdf::safe-file-write-date) (asdf:traverse (make-instance 'asdf:load-op) (asdf:find-system :sb-md5))
Ok, it's attached. Zach $ sbcl --non-interactive --no-userinit --load asdf.lisp --eval "(trace asdf::visit-action asdf::compute-action-stamp asdf::safe-file-write-date)" --eval "(asdf:traverse (make-instance 'asdf:load-op) (asdf:find-system :sb-md5))" This is SBCL 1.1.2.21-9f53ac7, an implementation of ANSI Common Lisp. More information about SBCL is available at <http://www.sbcl.org/>. SBCL is free software, provided as is, with absolutely no warranty. It is mostly in the public domain; some portions are provided under BSD-style licenses. See the CREDITS and COPYING files in the distribution for more information. 0: (ASDF::SAFE-FILE-WRITE-DATE #P"/usr/local/lib/sbcl/sb-md5/sb-md5.asd") 0: ASDF::SAFE-FILE-WRITE-DATE returned 3555406906 0: (ASDF::SAFE-FILE-WRITE-DATE #P"/usr/local/lib/sbcl/sb-md5/sb-md5.asd") 0: ASDF::SAFE-FILE-WRITE-DATE returned 3555406906 0: (ASDF::SAFE-FILE-WRITE-DATE #P"/usr/local/lib/sbcl/sb-md5/sb-md5.asd") 0: ASDF::SAFE-FILE-WRITE-DATE returned 3555406906 0: (ASDF::SAFE-FILE-WRITE-DATE #P"/usr/local/lib/sbcl/sb-md5/sb-md5.asd") 0: ASDF::SAFE-FILE-WRITE-DATE returned 3555406906 0: (ASDF::SAFE-FILE-WRITE-DATE #P"/usr/local/lib/sbcl/sb-md5/sb-md5.asd") 0: ASDF::SAFE-FILE-WRITE-DATE returned 3555406906 0: (ASDF::SAFE-FILE-WRITE-DATE #P"/usr/local/lib/sbcl/sb-md5/sb-md5.asd") 0: ASDF::SAFE-FILE-WRITE-DATE returned 3555406906 0: (ASDF::SAFE-FILE-WRITE-DATE #P"/usr/local/lib/sbcl/sb-md5/sb-md5.asd") 0: ASDF::SAFE-FILE-WRITE-DATE returned 3555406906 0: (ASDF::SAFE-FILE-WRITE-DATE #P"/usr/local/lib/sbcl/sb-md5/sb-md5.asd") 0: ASDF::SAFE-FILE-WRITE-DATE returned 3555406906 0: (ASDF::SAFE-FILE-WRITE-DATE #P"/usr/local/lib/sbcl/sb-md5/sb-md5.asd") 0: ASDF::SAFE-FILE-WRITE-DATE returned 3555406906 0: (ASDF::SAFE-FILE-WRITE-DATE #P"/usr/local/lib/sbcl/sb-md5/sb-md5.asd") 0: ASDF::SAFE-FILE-WRITE-DATE returned 3555406906 0: (ASDF::SAFE-FILE-WRITE-DATE #P"/usr/local/lib/sbcl/sb-md5/sb-md5.asd") 0: ASDF::SAFE-FILE-WRITE-DATE returned 3555406906 0: (ASDF::SAFE-FILE-WRITE-DATE #P"/usr/local/lib/sbcl/sb-md5/sb-md5.asd") 0: ASDF::SAFE-FILE-WRITE-DATE returned 3555406906 0: (ASDF::SAFE-FILE-WRITE-DATE #P"/usr/local/lib/sbcl/sb-md5/sb-md5.asd") 0: ASDF::SAFE-FILE-WRITE-DATE returned 3555406906 0: (ASDF::VISIT-ACTION #<ASDF:LOAD-OP NIL {1004C292F3}> #<ASDF:SYSTEM "sb-md5"> ASDF:TRAVERSE #<CLOSURE (LAMBDA # :IN ASDF::TRAVERSE-ACTION) {1005654A7B}> #<CLOSURE (LAMBDA # :IN ASDF::TRAVERSE-ACTION) {1005654A9B}>) 1: (ASDF::VISIT-ACTION #<ASDF:PREPARE-OP NIL {100584FED3}> #<ASDF:SYSTEM "sb-md5"> ASDF:TRAVERSE #<CLOSURE (LAMBDA # :IN ASDF::TRAVERSE-ACTION) {10058538AB}> #<CLOSURE (LAMBDA # :IN ASDF::TRAVERSE-ACTION) {10058538CB}>) 2: (ASDF::SAFE-FILE-WRITE-DATE #P"/usr/local/lib/sbcl/sb-rotate-byte/sb-rotate-byte.asd") 2: ASDF::SAFE-FILE-WRITE-DATE returned 3564838427 2: (ASDF::SAFE-FILE-WRITE-DATE #P"/usr/local/lib/sbcl/sb-rotate-byte/sb-rotate-byte.asd") 2: ASDF::SAFE-FILE-WRITE-DATE returned 3564838427 2: (ASDF::SAFE-FILE-WRITE-DATE #P"/usr/local/lib/sbcl/sb-rotate-byte/sb-rotate-byte.asd") 2: ASDF::SAFE-FILE-WRITE-DATE returned 3564838427 2: (ASDF::SAFE-FILE-WRITE-DATE #P"/usr/local/lib/sbcl/sb-rotate-byte/sb-rotate-byte.asd") 2: ASDF::SAFE-FILE-WRITE-DATE returned 3564838427 2: (ASDF::SAFE-FILE-WRITE-DATE #P"/usr/local/lib/sbcl/sb-rotate-byte/sb-rotate-byte.asd") 2: ASDF::SAFE-FILE-WRITE-DATE returned 3564838427 2: (ASDF::SAFE-FILE-WRITE-DATE #P"/usr/local/lib/sbcl/sb-rotate-byte/sb-rotate-byte.asd") 2: ASDF::SAFE-FILE-WRITE-DATE returned 3564838427 2: (ASDF::SAFE-FILE-WRITE-DATE #P"/usr/local/lib/sbcl/sb-rotate-byte/sb-rotate-byte.asd") 2: ASDF::SAFE-FILE-WRITE-DATE returned 3564838427 2: (ASDF::SAFE-FILE-WRITE-DATE #P"/usr/local/lib/sbcl/sb-rotate-byte/sb-rotate-byte.asd") 2: ASDF::SAFE-FILE-WRITE-DATE returned 3564838427 2: (ASDF::VISIT-ACTION #<ASDF:LOAD-OP NIL {1004C292F3}> #<ASDF:SYSTEM "sb-rotate-byte"> ASDF:TRAVERSE #<CLOSURE (LAMBDA # :IN ASDF::TRAVERSE-ACTION) {1005999ACB}> #<CLOSURE (LAMBDA # :IN ASDF::TRAVERSE-ACTION) {1005999AEB}>) 3: (ASDF::VISIT-ACTION #<ASDF:PREPARE-OP NIL {100584FED3}> #<ASDF:SYSTEM "sb-rotate-byte"> ASDF:TRAVERSE #<CLOSURE (LAMBDA # :IN ASDF::TRAVERSE-ACTION) {10059A17DB}> #<CLOSURE (LAMBDA # :IN ASDF::TRAVERSE-ACTION) {10059A17FB}>) 4: (ASDF::COMPUTE-ACTION-STAMP #<ASDF:PREPARE-OP NIL {100584FED3}> #<ASDF:SYSTEM "sb-rotate-byte"> :PLAN ASDF:TRAVERSE) 5: (ASDF::SAFE-FILE-WRITE-DATE #P"/usr/local/lib/sbcl/sb-rotate-byte/sb-rotate-byte.asd") 5: ASDF::SAFE-FILE-WRITE-DATE returned 3564838427 4: ASDF::COMPUTE-ACTION-STAMP returned 3564838427 NIL 3: ASDF::VISIT-ACTION returned 3564838427 3: (ASDF::VISIT-ACTION #<ASDF:LOAD-OP NIL {1004C292F3}> #<ASDF:CL-SOURCE-FILE "sb-rotate-byte" "package"> ASDF:TRAVERSE #<CLOSURE (LAMBDA # :IN ASDF::TRAVERSE-ACTION) {1005AE474B}> #<CLOSURE (LAMBDA # :IN ASDF::TRAVERSE-ACTION) {1005AE476B}>) 4: (ASDF::VISIT-ACTION #<ASDF:COMPILE-OP NIL {1005C809A3}> #<ASDF:CL-SOURCE-FILE "sb-rotate-byte" "package"> ASDF:TRAVERSE #<CLOSURE (LAMBDA # :IN ASDF::TRAVERSE-ACTION) {1005C8356B}> #<CLOSURE (LAMBDA # :IN ASDF::TRAVERSE-ACTION) {1005C8358B}>) 5: (ASDF::VISIT-ACTION #<ASDF:PREPARE-OP NIL {100584FED3}> #<ASDF:CL-SOURCE-FILE "sb-rotate-byte" "package"> ASDF:TRAVERSE #<CLOSURE (LAMBDA # :IN ASDF::TRAVERSE-ACTION) {1005C8A65B}> #<CLOSURE (LAMBDA # :IN ASDF::TRAVERSE-ACTION) {1005C8A67B}>) 6: (ASDF::COMPUTE-ACTION-STAMP #<ASDF:PREPARE-OP NIL {100584FED3}> #<ASDF:CL-SOURCE-FILE "sb-rotate-byte" "package"> :PLAN ASDF:TRAVERSE) 6: ASDF::COMPUTE-ACTION-STAMP returned 3564838427 NIL 5: ASDF::VISIT-ACTION returned 3564838427 5: (ASDF::COMPUTE-ACTION-STAMP #<ASDF:COMPILE-OP NIL {1005C809A3}> #<ASDF:CL-SOURCE-FILE "sb-rotate-byte" "package"> :PLAN ASDF:TRAVERSE) 6: (ASDF::SAFE-FILE-WRITE-DATE #P"/usr/local/lib/sbcl/sb-rotate-byte/package.fasl") 6: ASDF::SAFE-FILE-WRITE-DATE returned 3564838724 6: (ASDF::SAFE-FILE-WRITE-DATE #P"/usr/local/lib/sbcl/sb-rotate-byte/package.lisp") 6: ASDF::SAFE-FILE-WRITE-DATE returned 3555406906 5: ASDF::COMPUTE-ACTION-STAMP returned 3564838724 T 5: (ASDF::COMPUTE-ACTION-STAMP #<ASDF:COMPILE-OP NIL {1005C809A3}> #<ASDF:CL-SOURCE-FILE "sb-rotate-byte" "package"> :JUST-DONE T) 6: (ASDF::SAFE-FILE-WRITE-DATE #P"/usr/local/lib/sbcl/sb-rotate-byte/package.fasl") 6: ASDF::SAFE-FILE-WRITE-DATE returned 3564838724 6: (ASDF::SAFE-FILE-WRITE-DATE #P"/usr/local/lib/sbcl/sb-rotate-byte/package.lisp") 6: ASDF::SAFE-FILE-WRITE-DATE returned 3555406906 5: ASDF::COMPUTE-ACTION-STAMP returned 3564838724 T 4: ASDF::VISIT-ACTION returned 3564838724 4: (ASDF::COMPUTE-ACTION-STAMP #<ASDF:LOAD-OP NIL {1004C292F3}> #<ASDF:CL-SOURCE-FILE "sb-rotate-byte" "package"> :PLAN ASDF:TRAVERSE) 5: (ASDF::SAFE-FILE-WRITE-DATE #P"/usr/local/lib/sbcl/sb-rotate-byte/package.fasl") 5: ASDF::SAFE-FILE-WRITE-DATE returned 3564838724 4: ASDF::COMPUTE-ACTION-STAMP returned 3564838724 NIL 3: ASDF::VISIT-ACTION returned 3564838724 3: (ASDF::VISIT-ACTION #<ASDF:LOAD-OP NIL {1004C292F3}> #<ASDF:CL-SOURCE-FILE "sb-rotate-byte" "compiler"> ASDF:TRAVERSE #<CLOSURE (LAMBDA # :IN ASDF::TRAVERSE-ACTION) {1005F0001B}> #<CLOSURE (LAMBDA # :IN ASDF::TRAVERSE-ACTION) {1005F0003B}>) 4: (ASDF::VISIT-ACTION #<ASDF:COMPILE-OP NIL {1005C809A3}> #<ASDF:CL-SOURCE-FILE "sb-rotate-byte" "compiler"> ASDF:TRAVERSE #<CLOSURE (LAMBDA # :IN ASDF::TRAVERSE-ACTION) {1005F05C4B}> #<CLOSURE (LAMBDA # :IN ASDF::TRAVERSE-ACTION) {1005F05C6B}>) 5: (ASDF::VISIT-ACTION #<ASDF:PREPARE-OP NIL {100584FED3}> #<ASDF:CL-SOURCE-FILE "sb-rotate-byte" "compiler"> ASDF:TRAVERSE #<CLOSURE (LAMBDA # :IN ASDF::TRAVERSE-ACTION) {1005F0B27B}> #<CLOSURE (LAMBDA # :IN ASDF::TRAVERSE-ACTION) {1005F0B29B}>) 6: (ASDF::COMPUTE-ACTION-STAMP #<ASDF:PREPARE-OP NIL {100584FED3}> #<ASDF:CL-SOURCE-FILE "sb-rotate-byte" "compiler"> :PLAN ASDF:TRAVERSE) 6: ASDF::COMPUTE-ACTION-STAMP returned 3564838724 NIL 5: ASDF::VISIT-ACTION returned 3564838724 5: (ASDF::COMPUTE-ACTION-STAMP #<ASDF:COMPILE-OP NIL {1005C809A3}> #<ASDF:CL-SOURCE-FILE "sb-rotate-byte" "compiler"> :PLAN ASDF:TRAVERSE) 6: (ASDF::SAFE-FILE-WRITE-DATE #P"/usr/local/lib/sbcl/sb-rotate-byte/compiler.fasl") 6: ASDF::SAFE-FILE-WRITE-DATE returned 3564838724 6: (ASDF::SAFE-FILE-WRITE-DATE #P"/usr/local/lib/sbcl/sb-rotate-byte/compiler.lisp") 6: ASDF::SAFE-FILE-WRITE-DATE returned 3555406906 5: ASDF::COMPUTE-ACTION-STAMP returned 3564838724 T 5: (ASDF::COMPUTE-ACTION-STAMP #<ASDF:COMPILE-OP NIL {1005C809A3}> #<ASDF:CL-SOURCE-FILE "sb-rotate-byte" "compiler"> :JUST-DONE T) 6: (ASDF::SAFE-FILE-WRITE-DATE #P"/usr/local/lib/sbcl/sb-rotate-byte/compiler.fasl") 6: ASDF::SAFE-FILE-WRITE-DATE returned 3564838724 6: (ASDF::SAFE-FILE-WRITE-DATE #P"/usr/local/lib/sbcl/sb-rotate-byte/compiler.lisp") 6: ASDF::SAFE-FILE-WRITE-DATE returned 3555406906 5: ASDF::COMPUTE-ACTION-STAMP returned 3564838724 T 4: ASDF::VISIT-ACTION returned 3564838724 4: (ASDF::COMPUTE-ACTION-STAMP #<ASDF:LOAD-OP NIL {1004C292F3}> #<ASDF:CL-SOURCE-FILE "sb-rotate-byte" "compiler"> :PLAN ASDF:TRAVERSE) 5: (ASDF::SAFE-FILE-WRITE-DATE #P"/usr/local/lib/sbcl/sb-rotate-byte/compiler.fasl") 5: ASDF::SAFE-FILE-WRITE-DATE returned 3564838724 4: ASDF::COMPUTE-ACTION-STAMP returned 3564838724 NIL 3: ASDF::VISIT-ACTION returned 3564838724 3: (ASDF::VISIT-ACTION #<ASDF:LOAD-OP NIL {1004C292F3}> #<ASDF:MODULE "sb-rotate-byte" "vm"> ASDF:TRAVERSE #<CLOSURE (LAMBDA # :IN ASDF::TRAVERSE-ACTION) {1005F55BEB}> #<CLOSURE (LAMBDA # :IN ASDF::TRAVERSE-ACTION) {1005F55C0B}>) 4: (ASDF::VISIT-ACTION #<ASDF:PREPARE-OP NIL {100584FED3}> #<ASDF:MODULE "sb-rotate-byte" "vm"> ASDF:TRAVERSE #<CLOSURE (LAMBDA # :IN ASDF::TRAVERSE-ACTION) {1005F5D05B}> #<CLOSURE (LAMBDA # :IN ASDF::TRAVERSE-ACTION) {1005F5D07B}>) 5: (ASDF::COMPUTE-ACTION-STAMP #<ASDF:PREPARE-OP NIL {100584FED3}> #<ASDF:MODULE "sb-rotate-byte" "vm"> :PLAN ASDF:TRAVERSE) 5: ASDF::COMPUTE-ACTION-STAMP returned 3564838724 NIL 4: ASDF::VISIT-ACTION returned 3564838724 4: (ASDF::VISIT-ACTION #<ASDF:LOAD-OP NIL {1004C292F3}> #<ASDF:CL-SOURCE-FILE "sb-rotate-byte" "vm" "x86-64-vm"> ASDF:TRAVERSE #<CLOSURE (LAMBDA # :IN ASDF::TRAVERSE-ACTION) {1005F68F9B}> #<CLOSURE (LAMBDA # :IN ASDF::TRAVERSE-ACTION) {1005F68FBB}>) 5: (ASDF::VISIT-ACTION #<ASDF:COMPILE-OP NIL {1005C809A3}> #<ASDF:CL-SOURCE-FILE "sb-rotate-byte" "vm" "x86-64-vm"> ASDF:TRAVERSE #<CLOSURE (LAMBDA # :IN ASDF::TRAVERSE-ACTION) {1005F6E85B}> #<CLOSURE (LAMBDA # :IN ASDF::TRAVERSE-ACTION) {1005F6E87B}>) 6: (ASDF::VISIT-ACTION #<ASDF:PREPARE-OP NIL {100584FED3}> #<ASDF:CL-SOURCE-FILE "sb-rotate-byte" "vm" "x86-64-vm"> ASDF:TRAVERSE #<CLOSURE (LAMBDA # :IN ASDF::TRAVERSE-ACTION) {1005F74AAB}> #<CLOSURE (LAMBDA # :IN ASDF::TRAVERSE-ACTION) {1005F74ACB}>) 7: (ASDF::COMPUTE-ACTION-STAMP #<ASDF:PREPARE-OP NIL {100584FED3}> #<ASDF:CL-SOURCE-FILE "sb-rotate-byte" "vm" "x86-64-vm"> :PLAN ASDF:TRAVERSE) 7: ASDF::COMPUTE-ACTION-STAMP returned 3564838724 NIL 6: ASDF::VISIT-ACTION returned 3564838724 6: (ASDF::COMPUTE-ACTION-STAMP #<ASDF:COMPILE-OP NIL {1005C809A3}> #<ASDF:CL-SOURCE-FILE "sb-rotate-byte" "vm" "x86-64-vm"> :PLAN ASDF:TRAVERSE) 7: (ASDF::SAFE-FILE-WRITE-DATE #P"/usr/local/lib/sbcl/sb-rotate-byte/x86-64-vm.fasl") 7: ASDF::SAFE-FILE-WRITE-DATE returned 3564838724 7: (ASDF::SAFE-FILE-WRITE-DATE #P"/usr/local/lib/sbcl/sb-rotate-byte/x86-64-vm.lisp") 7: ASDF::SAFE-FILE-WRITE-DATE returned 3555406906 6: ASDF::COMPUTE-ACTION-STAMP returned 3564838724 T 6: (ASDF::COMPUTE-ACTION-STAMP #<ASDF:COMPILE-OP NIL {1005C809A3}> #<ASDF:CL-SOURCE-FILE "sb-rotate-byte" "vm" "x86-64-vm"> :JUST-DONE T) 7: (ASDF::SAFE-FILE-WRITE-DATE #P"/usr/local/lib/sbcl/sb-rotate-byte/x86-64-vm.fasl") 7: ASDF::SAFE-FILE-WRITE-DATE returned 3564838724 7: (ASDF::SAFE-FILE-WRITE-DATE #P"/usr/local/lib/sbcl/sb-rotate-byte/x86-64-vm.lisp") 7: ASDF::SAFE-FILE-WRITE-DATE returned 3555406906 6: ASDF::COMPUTE-ACTION-STAMP returned 3564838724 T 5: ASDF::VISIT-ACTION returned 3564838724 5: (ASDF::COMPUTE-ACTION-STAMP #<ASDF:LOAD-OP NIL {1004C292F3}> #<ASDF:CL-SOURCE-FILE "sb-rotate-byte" "vm" "x86-64-vm"> :PLAN ASDF:TRAVERSE) 6: (ASDF::SAFE-FILE-WRITE-DATE #P"/usr/local/lib/sbcl/sb-rotate-byte/x86-64-vm.fasl") 6: ASDF::SAFE-FILE-WRITE-DATE returned 3564838724 5: ASDF::COMPUTE-ACTION-STAMP returned 3564838724 NIL 4: ASDF::VISIT-ACTION returned 3564838724 4: (ASDF::COMPUTE-ACTION-STAMP #<ASDF:LOAD-OP NIL {1004C292F3}> #<ASDF:MODULE "sb-rotate-byte" "vm"> :PLAN ASDF:TRAVERSE) 5: (ASDF::SAFE-FILE-WRITE-DATE #P"/usr/local/lib/sbcl/sb-rotate-byte/") 5: ASDF::SAFE-FILE-WRITE-DATE returned 3564838733 4: ASDF::COMPUTE-ACTION-STAMP returned 3564838733 NIL 3: ASDF::VISIT-ACTION returned 3564838733 3: (ASDF::VISIT-ACTION #<ASDF:LOAD-OP NIL {1004C292F3}> #<ASDF:CL-SOURCE-FILE "sb-rotate-byte" "rotate-byte"> ASDF:TRAVERSE #<CLOSURE (LAMBDA # :IN ASDF::TRAVERSE-ACTION) {1005FC8C2B}> #<CLOSURE (LAMBDA # :IN ASDF::TRAVERSE-ACTION) {1005FC8C4B}>) 4: (ASDF::VISIT-ACTION #<ASDF:COMPILE-OP NIL {1005C809A3}> #<ASDF:CL-SOURCE-FILE "sb-rotate-byte" "rotate-byte"> ASDF:TRAVERSE #<CLOSURE (LAMBDA # :IN ASDF::TRAVERSE-ACTION) {1005FCEDBB}> #<CLOSURE (LAMBDA # :IN ASDF::TRAVERSE-ACTION) {1005FCEDDB}>) 5: (ASDF::VISIT-ACTION #<ASDF:PREPARE-OP NIL {100584FED3}> #<ASDF:CL-SOURCE-FILE "sb-rotate-byte" "rotate-byte"> ASDF:TRAVERSE #<CLOSURE (LAMBDA # :IN ASDF::TRAVERSE-ACTION) {1005FD457B}> #<CLOSURE (LAMBDA # :IN ASDF::TRAVERSE-ACTION) {1005FD459B}>) 6: (ASDF::COMPUTE-ACTION-STAMP #<ASDF:PREPARE-OP NIL {100584FED3}> #<ASDF:CL-SOURCE-FILE "sb-rotate-byte" "rotate-byte"> :PLAN ASDF:TRAVERSE) 6: ASDF::COMPUTE-ACTION-STAMP returned 3564838724 NIL 5: ASDF::VISIT-ACTION returned 3564838724 5: (ASDF::COMPUTE-ACTION-STAMP #<ASDF:COMPILE-OP NIL {1005C809A3}> #<ASDF:CL-SOURCE-FILE "sb-rotate-byte" "rotate-byte"> :PLAN ASDF:TRAVERSE) 6: (ASDF::SAFE-FILE-WRITE-DATE #P"/usr/local/lib/sbcl/sb-rotate-byte/rotate-byte.fasl") 6: ASDF::SAFE-FILE-WRITE-DATE returned 3564838724 6: (ASDF::SAFE-FILE-WRITE-DATE #P"/usr/local/lib/sbcl/sb-rotate-byte/rotate-byte.lisp") 6: ASDF::SAFE-FILE-WRITE-DATE returned 3555406906 5: ASDF::COMPUTE-ACTION-STAMP returned 3564838724 T 5: (ASDF::COMPUTE-ACTION-STAMP #<ASDF:COMPILE-OP NIL {1005C809A3}> #<ASDF:CL-SOURCE-FILE "sb-rotate-byte" "rotate-byte"> :JUST-DONE T) 6: (ASDF::SAFE-FILE-WRITE-DATE #P"/usr/local/lib/sbcl/sb-rotate-byte/rotate-byte.fasl") 6: ASDF::SAFE-FILE-WRITE-DATE returned 3564838724 6: (ASDF::SAFE-FILE-WRITE-DATE #P"/usr/local/lib/sbcl/sb-rotate-byte/rotate-byte.lisp") 6: ASDF::SAFE-FILE-WRITE-DATE returned 3555406906 5: ASDF::COMPUTE-ACTION-STAMP returned 3564838724 T 4: ASDF::VISIT-ACTION returned 3564838724 4: (ASDF::COMPUTE-ACTION-STAMP #<ASDF:LOAD-OP NIL {1004C292F3}> #<ASDF:CL-SOURCE-FILE "sb-rotate-byte" "rotate-byte"> :PLAN ASDF:TRAVERSE) 5: (ASDF::SAFE-FILE-WRITE-DATE #P"/usr/local/lib/sbcl/sb-rotate-byte/rotate-byte.fasl") 5: ASDF::SAFE-FILE-WRITE-DATE returned 3564838724 4: ASDF::COMPUTE-ACTION-STAMP returned 3564838724 NIL 3: ASDF::VISIT-ACTION returned 3564838724 3: (ASDF::COMPUTE-ACTION-STAMP #<ASDF:LOAD-OP NIL {1004C292F3}> #<ASDF:SYSTEM "sb-rotate-byte"> :PLAN ASDF:TRAVERSE) 4: (ASDF::SAFE-FILE-WRITE-DATE #P"/usr/local/lib/sbcl/sb-rotate-byte/sb-rotate-byte.asd") 4: ASDF::SAFE-FILE-WRITE-DATE returned 3564838427 3: ASDF::COMPUTE-ACTION-STAMP returned 3564838733 NIL 2: ASDF::VISIT-ACTION returned 3564838733 2: (ASDF::COMPUTE-ACTION-STAMP #<ASDF:PREPARE-OP NIL {100584FED3}> #<ASDF:SYSTEM "sb-md5"> :PLAN ASDF:TRAVERSE) 3: (ASDF::SAFE-FILE-WRITE-DATE #P"/usr/local/lib/sbcl/sb-rotate-byte/sb-rotate-byte.asd") 3: ASDF::SAFE-FILE-WRITE-DATE returned 3564838427 3: (ASDF::SAFE-FILE-WRITE-DATE #P"/usr/local/lib/sbcl/sb-rotate-byte/sb-rotate-byte.asd") 3: ASDF::SAFE-FILE-WRITE-DATE returned 3564838427 3: (ASDF::SAFE-FILE-WRITE-DATE #P"/usr/local/lib/sbcl/sb-md5/sb-md5.asd") 3: ASDF::SAFE-FILE-WRITE-DATE returned 3555406906 2: ASDF::COMPUTE-ACTION-STAMP returned 3564838733 NIL 1: ASDF::VISIT-ACTION returned 3564838733 1: (ASDF::VISIT-ACTION #<ASDF:LOAD-OP NIL {1004C292F3}> #<ASDF:CL-SOURCE-FILE "sb-md5" "md5"> ASDF:TRAVERSE #<CLOSURE (LAMBDA # :IN ASDF::TRAVERSE-ACTION) {100605590B}> #<CLOSURE (LAMBDA # :IN ASDF::TRAVERSE-ACTION) {100605592B}>) 2: (ASDF::VISIT-ACTION #<ASDF:COMPILE-OP NIL {1005C809A3}> #<ASDF:CL-SOURCE-FILE "sb-md5" "md5"> ASDF:TRAVERSE #<CLOSURE (LAMBDA # :IN ASDF::TRAVERSE-ACTION) {100605AD7B}> #<CLOSURE (LAMBDA # :IN ASDF::TRAVERSE-ACTION) {100605AD9B}>) 3: (ASDF::VISIT-ACTION #<ASDF:PREPARE-OP NIL {100584FED3}> #<ASDF:CL-SOURCE-FILE "sb-md5" "md5"> ASDF:TRAVERSE #<CLOSURE (LAMBDA # :IN ASDF::TRAVERSE-ACTION) {100606085B}> #<CLOSURE (LAMBDA # :IN ASDF::TRAVERSE-ACTION) {100606087B}>) 4: (ASDF::COMPUTE-ACTION-STAMP #<ASDF:PREPARE-OP NIL {100584FED3}> #<ASDF:CL-SOURCE-FILE "sb-md5" "md5"> :PLAN ASDF:TRAVERSE) 4: ASDF::COMPUTE-ACTION-STAMP returned 3564838733 NIL 3: ASDF::VISIT-ACTION returned 3564838733 3: (ASDF::COMPUTE-ACTION-STAMP #<ASDF:COMPILE-OP NIL {1005C809A3}> #<ASDF:CL-SOURCE-FILE "sb-md5" "md5"> :PLAN ASDF:TRAVERSE) 4: (ASDF::SAFE-FILE-WRITE-DATE #P"/usr/local/lib/sbcl/sb-md5/md5.fasl") 4: ASDF::SAFE-FILE-WRITE-DATE returned 3564838725 4: (ASDF::SAFE-FILE-WRITE-DATE #P"/usr/local/lib/sbcl/sb-md5/md5.lisp") 4: ASDF::SAFE-FILE-WRITE-DATE returned 3555406906 3: ASDF::COMPUTE-ACTION-STAMP returned T NIL 2: ASDF::VISIT-ACTION returned T 2: (ASDF::COMPUTE-ACTION-STAMP #<ASDF:LOAD-OP NIL {1004C292F3}> #<ASDF:CL-SOURCE-FILE "sb-md5" "md5"> :PLAN ASDF:TRAVERSE) 3: (ASDF::SAFE-FILE-WRITE-DATE #P"/usr/local/lib/sbcl/sb-md5/md5.fasl") 3: ASDF::SAFE-FILE-WRITE-DATE returned 3564838725 2: ASDF::COMPUTE-ACTION-STAMP returned T NIL 1: ASDF::VISIT-ACTION returned T 1: (ASDF::COMPUTE-ACTION-STAMP #<ASDF:LOAD-OP NIL {1004C292F3}> #<ASDF:SYSTEM "sb-md5"> :PLAN ASDF:TRAVERSE) 2: (ASDF::SAFE-FILE-WRITE-DATE #P"/usr/local/lib/sbcl/sb-md5/sb-md5.asd") 2: ASDF::SAFE-FILE-WRITE-DATE returned 3555406906 1: ASDF::COMPUTE-ACTION-STAMP returned T NIL 0: ASDF::VISIT-ACTION returned T
OK, I understand the bug that Xach found: There was an ancient bug whereby input-files for a module always returned a singleton list containing the module's component-pathname, its directory. That wasn't an issue then due to the even greater deep design flaw of timestamps not being propagated. Since the latter bug was fixed, the former popped its ugly head. Because SB-ROTATE-BYTE has a module (a fake one for the purpose of using :if-component-dep-fails), ASDF wanted to recompile it, which fails. If you have a fast compiler and you don't install, the entire thing can be compiled in under a second, and the timestamps for all the fasls and directory are the same. But after you install, the directory timestamp is older, and you are sure to lose. Anyway, this should be fixed in 2.26.33. My apologies for the breakage. Software is hard. —♯ƒ • François-René ÐVB Rideau •Reflection&Cybernethics• http://fare.tunes.org Truth comes as conqueror only to those who have lost the art of receiving it as friend. — Tagore
On Tue, Dec 18, 2012 at 5:01 PM, Faré <fahree@gmail.com> wrote:
OK, I understand the bug that Xach found:
There was an ancient bug whereby input-files for a module always returned a singleton list containing the module's component-pathname, its directory. That wasn't an issue then due to the even greater deep design flaw of timestamps not being propagated. Since the latter bug was fixed, the former popped its ugly head. Because SB-ROTATE-BYTE has a module (a fake one for the purpose of using :if-component-dep-fails), ASDF wanted to recompile it, which fails. If you have a fast compiler and you don't install, the entire thing can be compiled in under a second, and the timestamps for all the fasls and directory are the same. But after you install, the directory timestamp is older, and you are sure to lose.
Anyway, this should be fixed in 2.26.33.
My apologies for the breakage. Software is hard.
Actually, the reason I wasn't seeing Zach's bug when running in SLIME is because I was running my asdf on top of the require'd asdf; now since input-files is not included in the list of redefined-functions, I was still benefitting from a method from the previous ASDF that explicitly overrode the default method, forcing modules to actually have no input-files. So it was actually my bug to have deleted this method instead of making it a method on parent-component. There. Mea culpa. —♯ƒ • François-René ÐVB Rideau •Reflection&Cybernethics• http://fare.tunes.org It may be better to be a live jackal than a dead lion, but it is better still to be a live lion. And usually easier. — Robert Heinlein, "Time Enough For Love"
participants (4)
-
Christophe Rhodes -
Faré -
Stas Boukarev -
Zach Beane