asdf-devel

asdf-devel@common-lisp.net

5 participants
1375 discussions

[asdf-devel] Small testing convenience pushed
by Robert P. Goldman 08 Apr '15

08 Apr '15

If you test on ACL with the many variations that Dave set up (thanks, Dave!), there is a new problem: you end up testing upgrade over and over and over and over, and it takes forever. This recent commit adds the ability to set ASDF_TEST_UPGRADE_LISPS, typically as a subset of ASDF_TEST_LISPS. If the variable is unset, it should not affect you (but this is not tested). Best, r

1 0

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

08 Apr '15

Dear Lisp hackers, I'm considering recording a walk through the ASDF sources. I'd like to have an interactive session over Google Hangout with one or a few people, explaining the current code in asdf/defsystem (i.e. not going into uiop, except to minimally explain what asdf uses). That should take about 2 hours. To enjoy the walkthrough, you need to be somewhat fluent in Common Lisp, and somewhat familiar with how to use ASDF, though not necessarily with either extending it or hacking its internals. If at least one person is familiar with ASDF 2 and has questions, that could be interesting, or that could be a separate session. Please respond me to this email (privately or publicly) if you're interested. —♯ƒ • François-René ÐVB Rideau •Reflection&Cybernethics• http://fare.tunes.org We are always in anarchy. But we pay a hefty price maintaining the illusion that we aren't, and another one being misled by the illusion.

2 2

[asdf-devel] Patch for UIOP/UTILITY:ENSURE-FUNCTION
by Mark Evenson 08 Apr '15

08 Apr '15

Without the attached patch, I believe the use of a function for output translations is hosed from post asdf-3.0.2 onwards. I think ABCL is the only implementation actively using the ability to specify an output translation as a function, as indeed Faré expressly introduced this for us. ABCL uses a specialized output translation to translate the location of FASLs for ASDF systems stored in jar files (like ABCL’s contribs) which can’t otherwise be expressed in the translation DSL. I have [committed an asdf-3.0.3.0.1 including this patch][r14583] to ABCL trunk, which I will sync in the near future to ASDF master if this is indeed the correct way to patch the problem. [r14583]: http://abcl.org/trac/changeset/14583 -- "A screaming comes across the sky. It has happened before but there is nothing to compare to it now."

1 0

[asdf-devel] New ASDF test failures
by Robert P. Goldman 08 Apr '15

08 Apr '15

CCL: package-system-test.script clisp: asdf-pathname-test.script package-system-test.script test-sysdef-asdf.script sbcl: package-system-test ecl: package-system-test.script test-bundle.script (expected) test-sysdef-asdf.script cmucl: package-system-test lispworks: package-system-test I'm stopping for now -- it seems like package-system-test is now portably broken, at least on Mac OSX. Happy New Year, r

2 5

[asdf-devel] Version 3.0.2.9 available
by Robert Goldman 08 Apr '15

08 Apr '15

Minor test tweak only. But one item off my todo list! ;-)

1 0

[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

Jump to page:

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

asdf-devel