[asdf-devel] Workaround (was: adsf/bundle:monolithic-fasl sometimes puts dependent system first in list)
As you probably are aware, an apparent workaround for this apparent bug is to make a toplevel "container" system, whose only contents is a :depends-on which contains the actual desired system (or list of systems). It seems that if the toplevel system has no actual file components, then it will not appear in the (asdf:component-depends-on 'asdf/bundle:monllithic-fasl-op ...) at all, and subsequently the systems appear in the correct order --- so the generated monofasl will be usable. In fact that's why I didn't see the bug initially, because gendl.asd normally is just such a container system and has no source components (last night I purposely "broke" it for testing by inclusion of a "source/try.lisp" at the toplevel -- if you clone the repository now, that source directory will not be there, and the monofasl for :gendl will work). I hope this is useful information. On Fri, Mar 15, 2013 at 7:06 PM, Dave Cooper <david.cooper@genworks.com>wrote:
Try this:
1. git clone git://github.com/genworks/gendl.git
2. put it in your quicklisp/local-projects/
3. (ql:register-local-projects)
4. (ql:quickload :gendl)
5. (ql:operate 'asdf/bundle:monolithic-fasl-op :gendl)
6. (first (asdf:output-files 'asdf/bundle:monolithic-fasl-op :gendl))
7. Copy the yielded pathname string to use in next step.
8. [in a fresh Lisp] (load <the --all-systems fasl from step 7>)
9. [back in first Lisp]:
(asdf:component-depends-on 'asdf/bundle:monolithic-fasl-op :gendl)
10. Read it and weep. system :gendl comes _first_ in the list. I feel it should come _last_.
I tried to look into the asdf code behind this operation but am afraid it is currently far over my head.
-- My Best,
Dave Cooper, Genworks Support david.cooper@genworks.com, dave.genworks.com(skype) USA: 248-327-3253(o), 1-248-330-2979(mobile) UK: 0191 645 1699
-- My Best, Dave Cooper, Genworks Support david.cooper@genworks.com, dave.genworks.com(skype) USA: 248-327-3253(o), 1-248-330-2979(mobile) UK: 0191 645 1699
Dear Dave, I fixed in 2.32.13 the bug you found with monolithic-fasl-op. It was a subtle bug in dependency propagation, that was ultimately rooted in the incorrect decision of having the monolithic bundle operations inherit from the non-monolithic ones. This imposed contradictory constraints on the code, which prevented it from doing the right thing in all cases, with the current code kind of working in the common case, but not quite in other not-so-uncommon cases, as you discovered. Thanks for your bug report, and my apologies for taking a few days before I sorted it all out. As a bonus, 2.32.12 included a few utilities like delete-empty-directory and delete-directory-tree that should help you get rid of cl-fad. —♯ƒ • François-René ÐVB Rideau •Reflection&Cybernethics• http://fare.tunes.org A competent and self-confident person is incapable of jealousy in anything. Jealousy is invariably a symptom of neurotic insecurity. — Robert Heinlein, "Time Enough For Love"
Dear Faré, * *Looks like there is a strange regression, at least on acl-9.0-linux-x86 and acl-9.0m-linux-x86: The --all-systems file is not being written at all! I get this: http://paste.lisp.org/display/136095 The (asdf:component-depends-on ...) does look like it gives the correct order, though. (What is the canonical function to see the list which will be written out by asdf/bundle:monolithic-fasl-op? I remember you said it's not really component-depends-on -- so what is it again? By the way, I just made a branch of github.com/genworks/gendl.git called asdf-monofasl-broken which has that extra source/try.lisp file and the :component for it in the gendl.asd file, for github.com/genworks/gendl.git. I tried this on acl-9.0-linux-x86, acl-9.0m-linux-x86, and ccl-1.9-f96-macosx-x64. Thanks for the work on this so far, please let me know if there is anything else I can do. Regards, Dave P.S. Thanks for the uiop/filesystem:delete-directory-tree, I will use it with caution. P.P.S. Is there a recursive copy-directory? I didn't see one at first glance. On Sun, Mar 17, 2013 at 11:40 AM, Faré <fahree@gmail.com> wrote:
Dear Dave,
I fixed in 2.32.13 the bug you found with monolithic-fasl-op. It was a subtle bug in dependency propagation, that was ultimately rooted in the incorrect decision of having the monolithic bundle operations inherit from the non-monolithic ones. This imposed contradictory constraints on the code, which prevented it from doing the right thing in all cases, with the current code kind of working in the common case, but not quite in other not-so-uncommon cases, as you discovered.
Thanks for your bug report, and my apologies for taking a few days before I sorted it all out.
As a bonus, 2.32.12 included a few utilities like delete-empty-directory and delete-directory-tree that should help you get rid of cl-fad.
—♯ƒ • François-René ÐVB Rideau •Reflection&Cybernethics• http://fare.tunes.org A competent and self-confident person is incapable of jealousy in anything. Jealousy is invariably a symptom of neurotic insecurity. — Robert Heinlein, "Time Enough For Love"
-- My Best, Dave Cooper, Genworks Support david.cooper@genworks.com, dave.genworks.com(skype) USA: 248-327-3253(o), 1-248-330-2979(mobile) UK: 0191 645 1699
[I don't know what happened with the formatting in my last note, here is the same note word-wrapped with emacs M-q:] Dear Faré, Looks like there is a strange regression, at least on acl-9.0-linux-x86 and acl-9.0m-linux-x86: The --all-systems file is not being written at all! I get this: http://paste.lisp.org/display/136095 The (asdf:component-depends-on ...) does look like it gives the correct order, though. (What is the canonical function to see the list which will be written out by asdf/bundle:monolithic-fasl-op? I remember you said it's not really component-depends-on -- so what is it again? By the way, I just made a branch of github.com/genworks/gendl.git called asdf-monofasl-broken which has that extra source/try.lisp file and the :component for it in the gendl.asd file, for github.com/genworks/gendl.git. I tried this on acl-9.0-linux-x86, acl-9.0m-linux-x86, and ccl-1.9-f96-macosx-x64. Thanks for the work on this so far, please let me know if there is anything else I can do. Regards, Dave P.S. Thanks for the uiop/filesystem:delete-directory-tree, I will use it with caution. P.P.S. Is there a recursive copy-directory? I didn't see one at first glance. On Mon, Mar 18, 2013 at 12:45 AM, Dave Cooper <david.cooper@genworks.com>wrote:
Dear Faré,
* *Looks like there is a strange regression, at least on acl-9.0-linux-x86 and acl-9.0m-linux-x86:
The --all-systems file is not being written at all! I get this:
http://paste.lisp.org/display/136095
The (asdf:component-depends-on ...) does look like it gives the correct order, though. (What is the canonical function to see the list which will be written out by asdf/bundle:monolithic-fasl-op? I remember you said it's not really component-depends-on -- so what is it again?
By the way, I just made a branch of github.com/genworks/gendl.git called asdf-monofasl-broken which has that extra source/try.lisp file and the :component for it in the gendl.asd file, for github.com/genworks/gendl.git .
I tried this on acl-9.0-linux-x86, acl-9.0m-linux-x86, and ccl-1.9-f96-macosx-x64.
Thanks for the work on this so far, please let me know if there is anything else I can do.
Regards,
Dave
P.S. Thanks for the uiop/filesystem:delete-directory-tree, I will use it with caution.
P.P.S. Is there a recursive copy-directory? I didn't see one at first glance.
On Sun, Mar 17, 2013 at 11:40 AM, Faré <fahree@gmail.com> wrote:
Dear Dave,
I fixed in 2.32.13 the bug you found with monolithic-fasl-op. It was a subtle bug in dependency propagation, that was ultimately rooted in the incorrect decision of having the monolithic bundle operations inherit from the non-monolithic ones. This imposed contradictory constraints on the code, which prevented it from doing the right thing in all cases, with the current code kind of working in the common case, but not quite in other not-so-uncommon cases, as you discovered.
Thanks for your bug report, and my apologies for taking a few days before I sorted it all out.
As a bonus, 2.32.12 included a few utilities like delete-empty-directory and delete-directory-tree that should help you get rid of cl-fad.
—♯ƒ • François-René ÐVB Rideau •Reflection&Cybernethics• http://fare.tunes.org A competent and self-confident person is incapable of jealousy in anything. Jealousy is invariably a symptom of neurotic insecurity. — Robert Heinlein, "Time Enough For Love"
-- My Best,
Dave Cooper, Genworks Support david.cooper@genworks.com, dave.genworks.com(skype) USA: 248-327-3253(o), 1-248-330-2979(mobile) UK: 0191 645 1699
-- My Best, Dave Cooper, Genworks Support david.cooper@genworks.com, dave.genworks.com(skype) USA: 248-327-3253(o), 1-248-330-2979(mobile) UK: 0191 645 1699
Dear Dave, when I fixed the dependencies for monolithic-fasl-op in 2.32.13, I failed to make an according change to the perform method. I fixed the issue *and* I added a test case in the test suite. My apologies for the breakage. PS: there is no copy-directory for now. On Unix, I use run-program to invoke cp or rsync, that come with lots of options that are hard to reproduce. On Windows, I suppose you could try xcopy. A full-fledged cp or rsync replacement and/or wrapper is out of the scope of uiop, but would make a nice Lisp library. —♯ƒ • François-René ÐVB Rideau •Reflection&Cybernethics• http://fare.tunes.org Free Will: decisions are determined by processes located in individual brains and unpredictable by either same or other individuals. God-given souls, pixie dust, (quantum) non-determinism, mystic animal spirits and other magic sources of "free will" need not apply. On Mon, Mar 18, 2013 at 12:45 AM, Dave Cooper <david.cooper@genworks.com> wrote:
Dear Faré,
Looks like there is a strange regression, at least on acl-9.0-linux-x86 and acl-9.0m-linux-x86:
The --all-systems file is not being written at all! I get this:
http://paste.lisp.org/display/136095
The (asdf:component-depends-on ...) does look like it gives the correct order, though. (What is the canonical function to see the list which will be written out by asdf/bundle:monolithic-fasl-op? I remember you said it's not really component-depends-on -- so what is it again?
By the way, I just made a branch of github.com/genworks/gendl.git called asdf-monofasl-broken which has that extra source/try.lisp file and the :component for it in the gendl.asd file, for github.com/genworks/gendl.git.
I tried this on acl-9.0-linux-x86, acl-9.0m-linux-x86, and ccl-1.9-f96-macosx-x64.
Thanks for the work on this so far, please let me know if there is anything else I can do.
Regards,
Dave
P.S. Thanks for the uiop/filesystem:delete-directory-tree, I will use it with caution.
P.P.S. Is there a recursive copy-directory? I didn't see one at first glance.
On Sun, Mar 17, 2013 at 11:40 AM, Faré <fahree@gmail.com> wrote:
Dear Dave,
I fixed in 2.32.13 the bug you found with monolithic-fasl-op. It was a subtle bug in dependency propagation, that was ultimately rooted in the incorrect decision of having the monolithic bundle operations inherit from the non-monolithic ones. This imposed contradictory constraints on the code, which prevented it from doing the right thing in all cases, with the current code kind of working in the common case, but not quite in other not-so-uncommon cases, as you discovered.
Thanks for your bug report, and my apologies for taking a few days before I sorted it all out.
As a bonus, 2.32.12 included a few utilities like delete-empty-directory and delete-directory-tree that should help you get rid of cl-fad.
Dear Faré, Thank you for 2.32.17, the monofasl ordering now seems to be correct. Regards Dave On Mon, Mar 18, 2013 at 8:20 AM, Faré <fahree@gmail.com> wrote:
Dear Dave,
when I fixed the dependencies for monolithic-fasl-op in 2.32.13, I failed to make an according change to the perform method. I fixed the issue *and* I added a test case in the test suite.
My apologies for the breakage.
PS: there is no copy-directory for now. On Unix, I use run-program to invoke cp or rsync, that come with lots of options that are hard to reproduce. On Windows, I suppose you could try xcopy. A full-fledged cp or rsync replacement and/or wrapper is out of the scope of uiop, but would make a nice Lisp library.
—♯ƒ • François-René ÐVB Rideau •Reflection&Cybernethics• http://fare.tunes.org Free Will: decisions are determined by processes located in individual brains and unpredictable by either same or other individuals. God-given souls, pixie dust, (quantum) non-determinism, mystic animal spirits and other magic sources of "free will" need not apply.
On Mon, Mar 18, 2013 at 12:45 AM, Dave Cooper <david.cooper@genworks.com> wrote:
Dear Faré,
Looks like there is a strange regression, at least on acl-9.0-linux-x86
and
acl-9.0m-linux-x86:
The --all-systems file is not being written at all! I get this:
http://paste.lisp.org/display/136095
The (asdf:component-depends-on ...) does look like it gives the correct order, though. (What is the canonical function to see the list which will be written out by asdf/bundle:monolithic-fasl-op? I remember you said it's not really component-depends-on -- so what is it again?
By the way, I just made a branch of github.com/genworks/gendl.gitcalled asdf-monofasl-broken which has that extra source/try.lisp file and the :component for it in the gendl.asd file, for github.com/genworks/gendl.git.
I tried this on acl-9.0-linux-x86, acl-9.0m-linux-x86, and ccl-1.9-f96-macosx-x64.
Thanks for the work on this so far, please let me know if there is anything else I can do.
Regards,
Dave
P.S. Thanks for the uiop/filesystem:delete-directory-tree, I will use it with caution.
P.P.S. Is there a recursive copy-directory? I didn't see one at first glance.
On Sun, Mar 17, 2013 at 11:40 AM, Faré <fahree@gmail.com> wrote:
Dear Dave,
I fixed in 2.32.13 the bug you found with monolithic-fasl-op. It was a subtle bug in dependency propagation, that was ultimately rooted in the incorrect decision of having the monolithic bundle operations inherit from the non-monolithic ones. This imposed contradictory constraints on the code, which prevented it from doing the right thing in all cases, with the current code kind of working in the common case, but not quite in other not-so-uncommon cases, as you discovered.
Thanks for your bug report, and my apologies for taking a few days before I sorted it all out.
As a bonus, 2.32.12 included a few utilities like delete-empty-directory and delete-directory-tree that should help you get rid of cl-fad.
-- My Best, Dave Cooper, Genworks Support david.cooper@genworks.com, dave.genworks.com(skype) USA: 248-327-3253(o), 1-248-330-2979(mobile) UK: 0191 645 1699
participants (2)
-
Dave Cooper -
Faré