[asdf-devel] Workaround (was: adsf/bundle:monolithic-fasl sometimes puts dependent system first in list)

[Dave Cooper]

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 at 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 at 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 at 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 at genworks.com, dave.genworks.com(skype)
USA: 248-327-3253(o), 1-248-330-2979(mobile)
UK: 0191 645 1699
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mailman.common-lisp.net/pipermail/asdf-devel/attachments/20130320/77aa3aff/attachment.html>