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

[asdf-devel] Re: cl-quakeinfo and asdf3
by Faré 08 Apr '15

08 Apr '15

Dear Kevin, as I'm handing out my ASDF duties to my successor Robert Goldman, I gave this a brief look again, and it looks like the issue is (1) your doing everything in cl-user, and (2) your assuming cl-user has allegro extensions such as if* This confuses SBCL, that warns about the suspicious undefined function if*, and other such things. Some dependencies #-allegro :acl-compat and package use #+allegro :excl #-allegro acl-compat.excl could help. —♯ƒ • François-René ÐVB Rideau •Reflection&Cybernethics• http://fare.tunes.org The only way to have a friend is to be one. — Ralph Waldo Emerson On Thu, Feb 21, 2013 at 11:37 AM, Faré <fahree(a)gmail.com> wrote: > Dear Lisp hacker(s), > > ASDF3 now checks deferred warnings by default. > On SBCL, this means that it will treat as an error > any undeclared free variable, including forward references to special variables > as well as any undefined function that isn't defined by the end of the system. > > Using cl-test-grid to compile all the systems in quicklisp, > we found the following failure on a system we believe you maintain. > Can you please fix it? > > cl-quakeinfo > http://cl-test-grid.appspot.com/blob?key=125l61q30b > > http://common-lisp.net/project/cl-test-grid/asdf/sbcl-warning-failures.html > http://common-lisp.net/project/cl-test-grid/asdf/asdf-diff-13.html > > —♯ƒ • François-René ÐVB Rideau •Reflection&Cybernethics• http://fare.tunes.org > Freedom transforms difficulty into opportunity, danger into responsibility. > "Protection" transforms difficulty into oppression, danger into tragedy.

3 7

[asdf-devel] Tests looking good on Mac and Linux
by Robert P. Goldman 08 Apr '15

08 Apr '15

All pass on linux for me, and all but test-bundle on ECL and ABCL on Mac. The latter two seem like they need help from the implementers which is not forthcoming. I'm going to figure out how to turn these tests off and propose to ship the long-postponed 3.0.3 if everyone is in agreement. Seems like the Windows tests have taken many steps forward while I was out of town. Any objections to this plan? Best, r

1 0

[asdf-devel] Installing from tarball
by David A. Cobb 08 Apr '15

08 Apr '15

1 0

[asdf-devel] Re: Some questions re new ASDF structure
by Faré 08 Apr '15

08 Apr '15

Copying this conversation to asdf-devel, since these are topics of interest to any hacker who would like to take over development of ASDF. On Mon, Jan 6, 2014 at 11:07 AM, Robert Goldman <rpgoldman(a)sift.net> wrote: > I'm dribbing and drabbing these out, I'm afraid.... > > FIND-OPERATION vs. MAKE-OPERATION: I'm a bit confused by this. I see > that operations are all indexed in the *OPERATIONS* hash table, but > although the names suggest that MAKE-OPERATION would make a fresh > OPERATION object, and FIND-OPERATION would require that there be a > previously existing one, it seems like they *both* address the hash > table. Nevertheless, a careful distinction is made between calls, > suggesting that I am missing an important distinction. It looks like > there's a future interest in recovering initargs by using the CONTEXT > argument, but for now that seems to be ignored (i.e., the CONTEXT > argument never provides anything). > > PERFORM: I believe that the ASDF protocol expects that PERFORM will not > return anything of interest, correct? I don't see anyone catching > return values. I figure I should probably document this as part of any > documentation overhaul. > I'm glad you ask. This is another unresolved design issues tracing back to ASDF 1, and one that I wasn't fully aware of until I wrote ASDF 3, at which point I fumbled around and ended up settling for a compromise. The problem at heart is that * on the one hand, ASDF seems to allow operations to be parametrized by user-defined slots * on the other hand, when computing the plan, ASDF drops any such parameters as it walks the graph and discards any action such that an action of same type on same component has already been visited. When rewriting ASDF, I tried to reconcile the two, by memoizing operations created with the same initargs, but eventually failed by fear of breaking backward compatibility: * users can and often do call make-instance 'some-operation, at which point you don't have the unique operation object. * I tried to have a per-traversal cache, by making the initial operation given to traverse be the "parent" of all other operations in a traversal; but this required incompatible changes in the component-operation-time / mark-operation-done protocol (not a big deal, since no one should be looking inside), this most importantly fails to work when one tries to load-system the second time around, and since no operation object is the same that second time, every action looks like it hasn't been done yet, and asdf loads everything the second time around. * I eventually settled for a global cache of *operations*, but got discouraged before to check with every user inside (and outside?!) quicklisp that I could indeed make the incompatible change in component-operation-time. Also, every single function or method that can be called with a user-provided operation object must now "canonicalize" the object before to use it in any of these comparisons (or more likely, the comparison function should be abstracted, and do the canonicalization, and for decent speed, cache the canonicalized operation in a slot of each compared operation object). * Finally, there was the issue of what it meant for two initargs to be equivalent — that totally depends on the operation class, and there's no protocol to help determine when that is or isn't the case. And this is further complicated by the fact that operate historically passes its keyword arguments to the operation, which includes things such as force, which are actually arguments to the plan, and shouldn't affect the operation — except that swank and gbbopen somehow used that slot (though they have both been weened off it recently, so we could leave a compatibility nil method in backward-interface and be done with it). So there, I did an incomplete job here, and I apologize for it. It will be your call to either fully allow operation initargs, or definitely deprecate them. Obviously, no one is relying on the feature right now, since it has never worked (not uncommon a thing for ASDF — :depends-on (:feature featr component), :force (sys1 sys2), and probably more are ASDF 1 features that never worked until I fixed them, that plus the module dependency that you fixed). PERFORM returns nothing of interest indeed — it either succeeds or signals an error. Now, my plans for an ASDF 4 (or at least 3.2) were to move ASDF towards a cross-compilation model, which would make life easier for MOCL, but would also bring to the ASDF world most of the goodies of XCVB: off-image compilation, deterministic build, parallel build, etc. This would mean deprecating PERFORM, instead having a method PERFORM-FORM or such that returns some source code to be run on the target slave (as opposed to the planning master — the slave doesn't run ASDF, only UIOP, and doesn't compute the entire plan, so can be started quickly on N machines or cpus) — and maybe a list of dependencies to be loaded on the target. When no method is defined for PERFORM-FORM, ASDF4 would check for a PERFORM method, in which case it would load ASDF on the target as well as some set of dependencies to be determined (e.g. the defsystem-depends-on of the current system), and then would either import the entire set of system definitions being used or create a fake trivial system with one entry, and then call perform on the chosen operation and component. Depending on how serious you are about it, you may or may not also adopt XCVB's model of :compile-depends-on, :load-depends-on :run-depends-on, with :depends-on foo implying a :compile-depends-on foo.cfasl (assuming you also support cfasls), and :load-depends-on foo.fasl (must be loaded before) and :run-depends-on foo.fasl (can be loaded after with circular dependencies), whereas :defsystem-depends-on foo implies :compile-depends-on foo.fasl and :load-depends-on foo.fasl. Or something more complex; cross-compilation is hard. That's also advanced hacking, and a somewhat incompatible change (modulo that fallback strategy) that requires a lot of social work for a smooth transition. But hopefully, you can convince the MOCL guy to do the social work, since it's in his interest to promote a standardized cross-compilation solution, and good marketing for him (Cc'ed). Regards, —♯ƒ • François-René ÐVB Rideau •Reflection&Cybernethics• http://fare.tunes.org Live as if you were living already for the second time and as if you had acted the first time as wrongly as you are about to act now! — Viktor Frankl, "Man's Search for Meaning"

1 0

[asdf-devel] Pushed update
by Robert Goldman 08 Apr '15

08 Apr '15

This has Vladimir Dyomkin's patch for some of the version-handling code (thanks, Vladimir!). It also has a fix to failures of test.run-program on LispWorks. This is version 3.0.2.6. It is *not* a release yet! I'd like to see some more tests run, and there's one more bug in UIOP that should be fixed, before we release 3.0.3. Best, Robert -- Robert P. Goldman Principal Scientist Smart Information Flow Technologies (d/b/a SIFT, LLC) 211 N. First St., Suite 300 Minneapolis, MN 55401 Voice: (612) 326-3934 Email: rpgoldman(a)SIFT.net

2 1

[asdf-devel] 3.0.3 release plans
by Robert P. Goldman 08 Apr '15

08 Apr '15

I was hoping to release this past week, but was unable to get further testing done. Before releasing, I try to test a number of large systems that we use here at SIFT with the latest ASDF. This provides a real world add-on to the test suite. Unfortunately, I have not had a chance to make this test. I hope to do so in the next couple of days. That should either reveal bugs, or lead to an immediate release of 3.0.3. It would be great if the quicklisp issues could be resolved satisfactorily in time for 3.0.3. Best, r

3 3

[asdf-devel] Fixing asdf-system-connections
by Liam Healy 08 Apr '15

08 Apr '15

I am using asdf-system-connections and notice a glitch in its design. As the original author no longer maintains it, I'm try to fix this myself. This system is designed to allow the loading of a connected system (say "A") automatically when two or more dependent systems (say "B" and "C") are loaded. The problem I'm encountering is that when another system (say "D") is defined to depend on B and C, then A is not loaded until after D is done loading, but D may need the definitions in A. asdf-system-connections defines a function load-connected-systems which does the work of loading the connected system definitions, but this is called from a new #'operate :after method which apparently doesn't get called until A is done loading. I am looking for a place from which to call load-connected-systems that will trigger its call as soon as it's able, i.e., immediately once both "B" and "C" are loaded. I'm not familiar with the internals of ASDF and wonder if someone can guide me to a good place to define this. Thanks, Liam

2 1

[asdf-devel] ASDF 3.0.1
by Faré 08 Apr '15

08 Apr '15

Dear Lisp hackers, ASDF 3.0.0 was decidedly short-lived. Longer live ASDF 3.0.1! An undocumented feature of version-satisfies, since the early days of ASDF 1, was that it would reject a component that didn't exactly match the specified major version as well as otherwise be same or newer as specified version. Of course, this broke quicklisp's check for a newer ASDF when ASDF went from major version 2 to major version 3. Since the feature was undocumented, and that users don't seem to ask for it, whereas many power users are inconvenienced by it, I just removed it. A future maintainer of ASDF may extend the `(:version ,dependency ,minimum-version) pattern for specifying dependencies with a `(:version ,dependency ,minimum-version ,too-large-version) pattern that allows to specify an exclusive upper bound on compatible versions. This would allow finer specification of compatible version ranges than just a match on the major version. But I didn't implement it. I leave it as an exercise for whoever volunteers to replace me, since I'm definitely leaving active maintenance of ASDF and unwilling to implement new features, though I will still fix bugs until a new maintainer rises. PS: this fiasco also suggests that a new maintainer shall include some typical quicklisp usage as part of the automated test suite. —♯ƒ • François-René ÐVB Rideau •Reflection&Cybernethics• http://fare.tunes.org When you are young you are afraid people will steal your ideas; when you are old you are afraid they won't. — David D. Friedman

2 1

[asdf-devel] add-cldir helper script
by Daniel Herring 08 Apr '15

08 Apr '15

Re: [asdf-devel] Alternate default lisp system location On Wed, 12 Mar 2014, Zach Beane wrote: > Is there some easy way, supported by ASDF, to make a system known to > ASDF if you have its pathname? I added the following function to my ~/bashrc shortly after migrating to the new ASDF config mechanism. add-cldir() { cfg="$HOME/.config/common-lisp/source-registry.conf.d/10-$USER.conf" grep $PWD $cfg || echo "(:directory \"$PWD/\")" >> $cfg } This could easily be converted to a standalone shell script and batch file, suitable for all major platforms. - Daniel

2 1

[asdf-devel] is there a built in way to prevent ASDF from trying to upgrade itself?
by Gary King 08 Apr '15

08 Apr '15

thanks, -- Gary Warren King, metabang.com Cell: (413) 559 8738 Fax: (206) 338-4052 gwkkwg on Skype * garethsan on AIM * gwking on twitter

3 2