asdf-devel

asdf-devel@common-lisp.net

5 participants
1375 discussions

[asdf-devel] Merge or not with upstream ECL's asdf?
by Faré 09 Oct '11

09 Oct '11

Dear Juanjo, I see that your current ECL replaces si:: by ext: on a few symbols in its version of ASDF. Should I merge that into the official ASDF, or should I wait until you make a release of ECL? If I should merge, here is the attached patch that you or I can commit into ASDF. If I should not merge, then considering that differences are easier to track when ECL's ASDF and the upstream ASDF are kept in synch, maybe in the future we should make until ECL is released before we make such changes to even the internal version of ASDF? I suppose in both cases, I want to add that new (defmethod bundle-sub-operations ((o monolithic-lib-op) c) ...) —♯ƒ • François-René ÐVB Rideau •Reflection&Cybernethics• http://fare.tunes.org

2 2

Re: [asdf-devel] Repeat f-ile compilation
by Сергей Катревич 08 Oct '11

08 Oct '11

Thanks, cool refactoring! > 1- It makes ASDF more robust against implementations that for some reason > would allow only one call to (call-next-method). I am don't know about this. But if: > CLHS does say the function has lexical scope and indefinite extent. ... this is problem of implementation, right? > The only previously allowed extension it prevents is > defining :before or :after methods ... The main proplem is that those who use :perform-with-restarts getted not pretty surprise. And therefore need to either warn them of the incompatibility or look the other way. I think you understand me. I do not like only one thing: restart try-reCOMPILING semantically not bind with load-op operation. Although i'am not sure that it is necessary to change ... Чтв 06 Окт 2011 20:21:02 +0400, Far <fahree(a)gmail.com> написал: > 2011/10/6 Сергей Катревич <linkfly1(a)newmail.ru>: > > O please do not rush. Simplify perform-with-restart is good way. But your > > last patch: > > - or makes the new version asdf is not backward compatible > > - or provides an error (implicitly, rarely appears) > > > Can you explain in what situation my patch causes an error? > > If I understand correctly, the only functional difference wrt your version > is that I explicitly call (perform o c) instead of going through (c-n-m). > > As for the incompatible replacement of (call-next-method) > by an explicit (perform o c): > > 1- It makes ASDF more robust against implementations that for some reason > would allow only one call to (call-next-method). It wasn't clear to me > that all implementations behave well when that's not the case; however, > the CLHS does say the function has lexical scope and indefinite extent. > > 2- The only previously allowed extension it prevents is > defining :before or :after methods on superclasses > of load-op and cl-source-file. I can imagine a use for that: logging, > though then you might as well log around perform rather than p-w-r. > This does not otherwise affect inline methods on perform-with-restarts; > not that anyone defines any such method AFAICT. > > In the end, I think your argument wins, and in 2.017.8, > I return to (c-n-m) and simplify things further: > * returned to (call-next-method) in the load-op method, make it a loop. > * moved the main restart from perform-plan to an :around method > of perform-with-restarts > * removed the redundant method for compile-op, since the main :around > method already provides a restart that does the very same. > > NB: my 2.017.8 does pass all the tests, including > test-retry-loading-component-1.script and > test/test-try-recompiling-1.script > that already test this functionality — thanks a lot to gwking! > > NB2: Since there's more coding involved, > I'm pushing release candidacy to next week, and release two weeks from now. > > —♯ƒ • François-René ÐVB Rideau •Reflection&Cybernethics• http://fare.tunes.org

1 0

[asdf-devel] A Weird Problem With ASDF on NFS (and a Workaround)
by Faré 07 Oct '11

07 Oct '11

Dear Andreas, it was fun reading your blog post: http://boinkor.net/archives/2011/10/a-weird-problem-with-asdf-on-nfs.html You're not the first one having experienced problems with clock skew. In 2.011.3, we fixed an indefinite loop that could happen in defsystem in presence of NFS clock skew. Instead of merely a workaround, what about a real fix? Can you tell me how ASDF 2.017.9 works for you? At some point next month it would be nice if Allegro would upgrade to ASDF 2.018... —♯ƒ • François-René ÐVB Rideau •Reflection&Cybernethics• http://fare.tunes.org

1 0

[asdf-devel] Fwd: Re: asdf:run-shell-command - fix, delete or don't touch?
by Robert Goldman 07 Oct '11

07 Oct '11

Here's my response from last night. The mailing list doesn't seem to like my alternative address. cheers, r

1 0

Re: [asdf-devel] Repeat file compilation
by Сергей Катревич 06 Oct '11

06 Oct '11

O please do not rush. Simplify perform-with-restart is good way. But your last patch: - or makes the new version asdf is not backward compatible - or provides an error (implicitly, rarely appears) perform-with-restart is generic function with methods that may defining with system definition in *.asd files (by :perform-with-restart keyword). This feature provided code: (defparameter +asdf-methods+ '(perform-with-restarts perform ...) (defun* %remove-component-inline-methods (component) (dolist (name +asdf-methods+) ...)) (defun* fine-component-inline-methods (ret rest) ;; !!! rest may be contain keyword :perform-with-restart (it defining "inline method") (dolist (name +asdf-methods+) ...)) calls: parse-component-form -> %refresh-component-inline-methods -> %remove-component-inline-methods -> fine-component-inline-methods This means that: we need in the (call-next-method) Please review my definition perform-with-restarts for compile-op and make analogue (if good code) for load-op: (defmethod perform-with-restarts ((o compile-op) (c cl-source-file)) (loop :with state :until (eq state :success) :do (restart-case (progn (call-next-method) (setf state :success)) (try-recompiling () :report (lambda (s) (format s (compatfmt "~@<Try recompiling ~a.~@:>") (component-name c))) )))) P.S. I run it and checked - the code solves the problem Чтв 06 Окт 2011 05:12:39 +0400, Far <fahree(a)gmail.com> написал: > I rewrote the perform-with-restarts methods based on what I understand > they *should* be doing, > and without any of the state machine complication that I never quite > got the hang of. > > Can you tell me if ASDF works better for you with the attached patch? > I passes all self-tests for me (on SBCL), but I admit I haven't tried > hard to trigger the case. > If it works for you, I'll commit it. > > I don't suppose anyone wants to write a test case for that. Sigh. > So I may have to myself write a file that includes a state machine > for compile-time and/or load-time failure. > Yay defvar and eval-when... > > —♯ƒ • François-René ÐVB Rideau •Reflection&Cybernethics• http://fare.tunes.org > >

1 0

[asdf-devel] Repeat file compilation
by Сергей Катревич 06 Oct '11

06 Oct '11

Hi Lispers! I research sources ASDF Library. I am not understand: Why repeat the compilation of a file (below code and details)? (defmethod perform-with-restarts ((o compile-op) (c cl-source-file)) (loop :with state = :initial :until (or (eq state :success) (eq state :failure)) :do (case state (:recompiled (setf state :failure) (call-next-method) (setf state :success)) (:failed-compile (setf state :recompiled) (perform-with-restarts o c)) (t (with-simple-restart (try-recompiling "Try recompiling ~a" (component-name c)) (setf state :failed-compile) (call-next-method) (setf state :success)))))) This is bad for me: my code evaluated twice (eval-when (:compile-toplevel) ...) in a file that i am recompiled throghout select try-recompiling restart. Details. 1. (setf state :failed-compiled) 2. error compilation. 3. select try-recompiling restart. 4. next iteration. 5. (setf state :recompiled) 6. recursive call: (perform-with-restarts o c) (in recusive-call) 6.1 (setf state :failed-compile) 6.2 (call-next-method) = success compile 6.3 (setf state :success) 6.4 next iteration and exit call. 7. next iteration 8. (setf state :failure) 9. (call-next-method) - second compilation! ??? I understand that (call-next-method) conceptual feature. But the file should not compile twice! Suggestions?

2 2

[asdf-devel] Please test ASDF 2.017.6
by Faré 03 Oct '11

03 Oct '11

I applied Juanjo's patch for testing with ecl-bytecmp. Only affect test files. Considering that there's been no action on the source code since last week, I propose that current version 2.017.6 is a pre-release for 2.018. Or maybe I'll call it 2.18 and loose the 0 which isn't very meaningful anymore? Please test thoroughly. I intend to make a release after one more week or two of inaction. So far, since 2.017: fix a component reuse bug noticed by Xach, and minor portability improvements with ECL, and minor testing improvements for ECL and SCL; everything relatively minor means we're slowly converging to something stable. —♯ƒ • François-René ÐVB Rideau •Reflection&Cybernethics• http://fare.tunes.org

2 5

[asdf-devel] Suggested patches for ASDF
by Juan Jose Garcia-Ripoll 20 Sep '11

20 Sep '11

Apart from some documentation and copyright notices, two major changes: - ECL will support two compilers. ASDF needs to be aware of that. - The plug-in for REQUIRE allows ECL users to supply another default operator. LOAD-FASL-OP is recommended because it builds each library into a single shared library, saving resources. Juanjo -- Instituto de Física Fundamental, CSIC c/ Serrano, 113b, Madrid 28006 (Spain) http://juanjose.garciaripoll.googlepages.com

4 25

[asdf-devel] Troubles with ASDF:RUN-SHELL-COMMAND
by Robert Goldman 19 Sep '11

19 Sep '11

As a side-effect of trying to export ASDF:*VERBOSE-OUTPUT*, to catch the output from RUN-SHELL-COMMAND, I created a test to verify that it was behaving properly. Boy, was that a mistake! I found that, in fact, ASDF:RUN-SHELL-COMMAND was not working on (at least) ACL, when faced with a command that had embedded double-quotes. See launchpad bug: https://bugs.launchpad.net/bugs/853566 I have fixed this and pushed the fix and the tests to the branch named 'run-shell-command' on cl.net. I would be VERY grateful if others would run the test on other lisps and other platforms. I would be especially grateful if people would run the tests on windows, since I don't really have a good understanding of how RUN-SHELL-COMMAND should work on that platform. I think it's bad that RUN-SHELL-COMMAND doesn't work properly, but I don't want to push these mods as a new version of ASDF until they run everywhere. Best, Robert

1 0

[asdf-devel] Export asdf::*verbose-out*?
by Robert Goldman 15 Sep '11

15 Sep '11

The user needs to bind asdf::*verbose-out* to something in order to see what happens when executing a command through asdf:run-shell-command. Given that the user is to do this, shouldn't this symbol be exported from the ASDF package? best, r

1 0

Jump to page:

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

asdf-devel