- asdf-devel - mailman3.common-lisp.net

Re: [asdf-devel] compile-with-nicknames (a possible compromise?)
by Juan Jose Garcia-Ripoll 18 Oct '11

18 Oct '11

2011/10/17 Gábor Balázs <gabalz(a)gmail.com> > > Hm, I like the idea of having multiple classes for cl-source-file objects. > But I wouldn't do it through CLOS. I tend to agree on this, for CLOS is not declarative. It would become very hard to automatically deciphering defsystem files, and what they do. I also believe that the wrap-around functionality does not have to be that general. In particular this is specifically required only for _compiling_, not for loading. I would not want an :around semantics to exist at all for loading, because that would completely eliminate any possible and future goal of making ASDF ship pre-compiled libraries. Out of the tasks listed here: locally renaming packages binding *readtables* and other syntax-controlling variables handling warnings and other conditions proclaiming optimization settings saving code coverage information maintaining meta-data about compilation timings resetting gensym counters, PRNG seeds, etc., for determinism cheating the source-location and/or timestamping systems checking that some cleanup function was properly called etc. I see nothing that could not exist in :eval-when forms. The problem is thus not that these operations may live in the compiled files, but the fact that we need them to be executed every time the files in the system are compiled. In a sense, it is a _reversed_ dependency. Normally we have that file2 depends on file1 and thus file2 is loaded _after_ file1 is loaded. Couldn't we just add another component to defsystem which is loaded when _any_ file is to be changed? It would be like a prerequisite module or file. Juanjo -- Instituto de Física Fundamental, CSIC c/ Serrano, 113b, Madrid 28006 (Spain) http://juanjose.garciaripoll.googlepages.com

3 3

[asdf-devel] ASDF system def inspectors
by Gary King 17 Oct '11

17 Oct '11

Hi all, Are there any tools extant that provide a good summary of all of the inter-relations between systems. I use the attached to make a DOT file but wonder if there are others. thanks, -- Gary Warren King, metabang.com Cell: (413) 559 8738 Fax: (206) 338-4052 gwkkwg on Skype * garethsan on AIM * gwking on twitter

2 1

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