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

[asdf-devel] asdf and windows vs unix on abcl
by Faré 21 Oct '11

21 Oct '11

ABCL is special in that it can run on either Windows or Unix. The problem is that ASDF 2.017 determines which of Windows or Unix at compile-time, which causes confusion when ABCL's builtin ASDF is compiled on Windows and used on Unix or vice-versa. And I can tell your binary was definitely produced on Windows. (I found this issue while testing cl-launch. I also noticed that you fixed your ext:*command-line-argument-list* albeit in a necessarily incompatible way.) I suppose the solution is that the test of unixness vs windowsness should happen at runtime. Crazy. —♯ƒ • François-René ÐVB Rideau •Reflection&Cybernethics• http://fare.tunes.org

3 3

[asdf-devel] compile-with-nicknames
by Gábor Balázs 20 Oct '11

20 Oct '11

hY, I would like to propose a kind of an enhancement to the ASDF functionalities. So there is a problem with package nicknames that they have to be unique. So using the :nicknames option in a package definition can cause "uncorrectable" collisions. On the other hand, by not doing so, one has to use fully qualified package names (eg. :com.gigamonkeys.macro-utilities) during library development which makes the code completely unreadable (in my opinion at least). So there would be a possibility in asdf to at least partially handle this problem. It would be nice to define temporary nicknames for the compilation time. At the moment, it is possible by the :perform asdf option. So one can place and remove the nicknames by :perform (compile-op :before ...) and :perform (compile-op :after) options. Often it would be desirable, to do so for every asdf compilation unit, but there is no easy way to do so yet. Note: one has to define the nickname operators for every compilation unit in which it is used, otherwise the exclusive recompilation of this unit will produce an error (which would make development difficult). The other problem with this approach is when a compilation fails, the nicknames won't be cleared. However it is not a big problem for a development process, and otherwise it should not happen. Defining the :perform options for each asdf unit, is pretty ugly. So it is nice to have a script at least which walks over all compilation units and sets the perform options. But there would be a nicer way, and this is the proposal. What about a new asdf option (eg :compile-with-nicknames), which could look like something this? (defsystem my-system :depends-on ("package-1" "package-2" "package-3" ...) :compile-with-nicknames (("package-1" "pckg-1") ("package-3" "pckg-3")) :components (...)) I think this approach nicely works in a "clear" environment for non-parallel compilation when there are no insane nickname requests. The "clear" environment assumption can be relaxed to say that the user hasn't defined any nicknames which causes collisions for any necessary compilations. Or if you know a better way to handle this problem, I would be happy to hear about that... Thanks, `bg`

4 26

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