asdf-devel

asdf-devel@common-lisp.net

1 participants
1378 discussions

Re: [asdf-devel] Fount inconsistency in RUN-SHELL-COMMAND...
by Faré 13 Oct '11

13 Oct '11

> Question: in order to make this consistent, can I take away the call to > ASDF-MESSAGE and just push the output through without prefixing? > Yes. Though again, consistent would be dropping this pretense of respecting *verbose-out* when most implementations don't and can't; at least not without a serious rewrite. —♯ƒ • François-René ÐVB Rideau •Reflection&Cybernethics• http://fare.tunes.org The Military *did* invent computers: computers sprung forth fully armed from a noncom's aching forehead between two barkings of orders at recruits.

1 0

[asdf-devel] Dependency does not trigger recompilation
by Juan Jose Garcia-Ripoll 12 Oct '11

12 Oct '11

I apologize in advance for the stupid newbie question that follows. I have the two systems below. When I change a file in cl-farm, it recompiles it, but when I demand loading of cl-farm-test again, ASDF does not recompile it, even though its dependency has changed. Why? Is this expected. This all is based on the latest ASDF from git, invoked from Slime (but I do not think this makes a difference) Juanjo (defsystem :cl-farm :serial t :components ((:file "package") (:file "machines"))) (defsystem :cl-farm-test :depends-on (:rt :cl-farm) :serial t :components ((:file "tests/package") (:file "tests/files") (:file "tests/run"))) -- Instituto de Física Fundamental, CSIC c/ Serrano, 113b, Madrid 28006 (Spain) http://juanjose.garciaripoll.googlepages.com

4 7

[asdf-devel] asdf:run-shell-command - fix, delete or don't touch?
by Faré 10 Oct '11

10 Oct '11

Do we want to (a) leave run-shell-command half-broken on various combination of OSes and implementations as soon as any argument needs quoting, do we want to (b) use heavy artillery to solve the problem correctly, or should we not just (c) delete this broken functionality that obviously nobody can or should be relying on for anything serious? My preference goes to (c) delete the damn thing (replacing the function body by an error that suggests a good replacement), but only if it doesn't create a quagmire for users. So I could really use some feedback from the ASDF constituency on that. If we want option (b), I just updated xcvb-driver so its run-program/process-output-stream does all that asdf:run-shell-command does, in addition to its previous functionality that allows actually using the command output. And xcvb-driver supports all the implementations that asdf:run-shell-command does, and more (cormanlisp, though untested). Moreover it works correctly on Windows, including with ClozureCL despite a bug and on Allegro (wanted here). But it's about 300 lines of complex code, as opposed to about 100 of trivial wrappers in the current half-broken implementation. See from requires-escaping-p to run-program/process-output-stream in xcvb/driver.lisp on http://common-lisp.net/gitweb?p=projects/xcvb/xcvb.git Note that unlike XCVB, ASDF itself doesn't use run-shell-command. The obvious suspects cffi-grovel and sb-grovel don't use it either. Actually, I wonder if *anyone* uses asdf:run-shell-command. In my local checkouts, only asdf-install (obsolete) and an experimental file in mcclim (that could be fixed if needed) explicitly call asdf:run-shell-command. Xach - would it be easy for you to test Quicklisp with a version of ASDF without run-shell-command (or fmakunbound'ing it early on) and see if anything breaks? —♯ƒ • François-René ÐVB Rideau •Reflection&Cybernethics• http://fare.tunes.org

5 9

[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

Jump to page:

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

asdf-devel