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

[asdf-devel] asdf loading error error
by Cyrus Harmon 08 Apr '15

08 Apr '15

While trying to load and asdf system that generates an error (that’s another story, presumably an abcl-contrib problem), I get the following error: Error while trying to load definition for system abcl-cdk from pathname /Users/sly/projects/abcl-cdk/abcl-cdk.asd: There is no applicable method for the generic function #<STANDARD-GENERIC-FUNCTION ASDF/SYSTEM:BUILTIN-SYSTEM-P {4DE3AFA9}> when called with arguments ((NIL)). [Condition of type ASDF/FIND-SYSTEM:LOAD-SYSTEM-DEFINITION-ERROR] Restarts: 0: [REINITIALIZE-SOURCE-REGISTRY-AND-RETRY] Retry finding system abcl-cdk after reinitializing the source-registry. 1: [RETRY] Retry SLIME REPL evaluation request. 2: [*ABORT] Return to SLIME's top level. 3: [ABORT] Abort thread. Backtrace: 0: (#<FUNCTION {55860583}> #<ASDF/FIND-SYSTEM:LOAD-SYSTEM-DEFINITION-ERROR {7A5599D4}> #<FUNCTION {55860583}>) 1: (APPLY #<FUNCTION {55860583}> (#<ASDF/FIND-SYSTEM:LOAD-SYSTEM-DEFINITION-ERROR {7A5599D4}> #<FUNCTION {55860583}>)) 2: (SYSTEM::RUN-HOOK SYSTEM::*INVOKE-DEBUGGER-HOOK* #<ASDF/FIND-SYSTEM:LOAD-SYSTEM-DEFINITION-ERROR {7A5599D4}> #<FUNCTION {55860583}>) 3: (INVOKE-DEBUGGER #<ASDF/FIND-SYSTEM:LOAD-SYSTEM-DEFINITION-ERROR {7A5599D4}>) 4: (ERROR ASDF/FIND-SYSTEM:LOAD-SYSTEM-DEFINITION-ERROR :NAME "abcl-cdk" :PATHNAME #P"/Users/sly/projects/abcl-cdk/abcl-cdk.asd" ...) 5: (#<FUNCTION {76BF4B40}> #<SIMPLE-ERROR {9E66C0B}>) 6: (SIGNAL #<SIMPLE-ERROR {9E66C0B}>) 7: (ERROR "There is no applicable method for the generic function ~S ~ when called with arguments ~S." #<STANDARD-GENERIC-FUNCTION {4DE3AFA9}> ((NIL))) 8: (#<FUNCTION {372CC276}> #<STANDARD-GENERIC-FUNCTION {4DE3AFA9}> (NIL)) 9: (APPLY #<FUNCTION {372CC276}> (#<STANDARD-GENERIC-FUNCTION {4DE3AFA9}> (NIL))) 10: (ASDF/SYSTEM:BUILTIN-SYSTEM-P NIL) 11: (#<FUNCTION {8E593A8}> "~S: ~S doesn't follow asdf version numbering convention" UIOP/UTILITY:PARSE-VERSION "1.5.6-SNAPSHOT") 12: (APPLY #<FUNCTION {8E593A8}> ("~S: ~S doesn't follow asdf version numbering convention" UIOP/UTILITY:PARSE-VERSION "1.5.6-SNAPSHOT")) 13: (UIOP/UTILITY:CALL-FUNCTION #<FUNCTION {8E593A8}> "~S: ~S doesn't follow asdf version numbering convention" UIOP/UTILITY:PARSE-VERSION "1.5.6-SNAPSHOT") 14: (UIOP/UTILITY:PARSE-VERSION "1.5.6-SNAPSHOT" #<FUNCTION {8E593A8}>) 15: (ASDF/PARSE-DEFSYSTEM::NORMALIZE-VERSION "1.5.6-SNAPSHOT" :COMPONENT "org.openscience.cdk/cdk" :PARENT #<ASDF/SYSTEM:SYSTEM {43A2DC5E}> ...) 16: (ASDF/PARSE-DEFSYSTEM:PARSE-COMPONENT-FORM #<ASDF/SYSTEM:SYSTEM {43A2DC5E}> (:MVN "org.openscience.cdk/cdk" :VERSION "1.5.6-SNAPSHOT") :PREVIOUS-SERIAL-COMPONENT "org.freehep/freehep-graphicsio-svg") 17: (ASDF/PARSE-DEFSYSTEM:PARSE-COMPONENT-FORM NIL (:MODULE "abcl-cdk" :PATHNAME NIL :NAME "abcl-cdk" ...)) I can understand the first error, but the second error that gets generated along the way seems like a mistake. Let me know if I can offer more information to help track this down. thanks, Cyrus

4 6

[asdf-devel] cmucl upgrade of asdf works (somewhat)
by Faré 08 Apr '15

08 Apr '15

An innocuous-looking change suggested by rpgoldman, of not providing a default initform for the selfward-operation slot, led after testing to fixing a few innocuous bugs in asdf, but also to a better understanding of the issues with CMUCL and upgrade. After the innocuous change, tests failed on CMUCL that didn't; some of it was bugs in ASDF that had been papered over by that initform: things that shouldn't have been selfward-operation were, and now had no initform — that was easily fixed. Then, there was a CMUCL bug, whereby sometimes, for reasons not understood yet deterministic and easy but not simple to trigger, some operations would be created without an initialized selfward-operation slot. This was worked around by noticing that selfward-operation was meant to be an :allocation :class slot, but that option wasn't inherited by slot specializations, and needed to be explicitly specified every time the slot was specialized (no doubt because trying to inherit the option would require a non-trivial decision procedure in case of conflict between multiple super-slots); fixing ASDF to do the right thing papered over that CMUCL bug. (to reproduce, checkout 3.1.0.37 and make t l=cmucl t=test-encodings.script) While we were experimenting with CLOS and CMUCL, we tried to remove the #+cmu declaim optimize (not sure why it was ever there), and/or add a #+cmu (setf c::top-level-lambda-max 0). That didn't help (yet I removed the declaim at rtoy's suggestion), but along the way, we noticed that upgrade works from 3.0.1, 3.0.2, 3.0.3, and fails from 2.32 and earlier. The issue is that defclass component has a renamed a slot, and its subclass system is invalidated, but CMUCL somehow fails to finalize it again before it's next used. The good news is that not only have we identified two CMUCL bugs, we have established to upgrade works from 3.0.1 to 3.0.3, which is all that matters, really, since CMUCL updates its ASDF frequently. And we know what to do to avoid more upgrade woes on CMUCL: avoid incompatible slot definitions in classes and/or superclasses. I changed our tests to upgrade versions in reverse chronological order, which is more relevant, and disabled older versions when using CMUCL. I also bumped *oldest-forward-compatible-asdf-version* to 2.33, since we don't have a method on update-instance-for-redefined-class to account for the renamed slot. That leaves the upgrade issue found by cl-grid-test on CCL with cl-l10n and some other systems. wow. such procrastination. much bugfix. very robustified. wow. All because rpgoldman read the source and wanted a tiny cleanup. In other news, still no date set for the walkthrough of ASDF sources on Google hangout; since rpgoldman is the primary audience, we're waiting for his schedule to open up. —♯ƒ • François-René ÐVB Rideau •Reflection&Cybernethics• http://fare.tunes.org "I believe that sex is one of the most beautiful, natural, wholesome things that money can buy." — Steve Martin

3 6

[asdf-devel] BUILD-OP
by Robert P. Goldman 08 Apr '15

08 Apr '15

I'm a little concerned about making BUILD-OP be the default operation. It seems to me that "BUILD" is not a good synonym for "LOAD," which is how BUILD-OP is currently interpreted. I think the conventional interpretation of the word "build" would suggest to the user that (build "foo-system") would compile and NOT load "foo-system," instead of performing LOAD-OP as now. To me "build" does not connote "load." Is this just me? What's the sense of the community? Should we use a different term? I realize that LOAD is taken, and shadowing CL:LOAD would be a big PITA. Is there a synonym we can use? Best, r

5 25

[asdf-devel] Will you please test the latest ASDF with CMUCL
by Robert Goldman 08 Apr '15

08 Apr '15

On Mac OS X for me, it fails upgrade from 2.32 to the latest (3.0.2.2) using method require. Faré's testing instructions are: /usr/local/bin/cmucl -noinit then copy/paste: (load"test/script-support.lisp") (asdf-test::da) (test-upgrade 'load-asdf-lisp'load-asdf-lisp-clean "REQUIRE") I get an error as follows: Error in function KERNEL:CLASS-TYPEP: Class is currently invalid: #<KERNEL::STANDARD-CLASS ASDF/SYSTEM:SYSTEM {48589A35}> Please let me know any findings. I'd like to get this fixed (or disconfirmed) before we release 3.0.3. Best, r

2 2

Re: [asdf-devel] ASDF 3.0.2.1 released
by Faré 08 Apr '15

08 Apr '15

Dear Robert, here are some code review comments on ASDF 3.0.2.1. * Putting :asdf/find-system after :asdf in the recycle looks like it's defeating the purpose; you might as well remove it. * Maybe refactor duplicate-names so it doesn't inherit from system-definition-error ? Or have a function of the same name be called that is defined later to throw the error? * Since we don't work on antique cmucl, maybe we could check whether the :report print-object hack is still needed? * I kind of wanted to prevent the multiplication of .asd files and the eating away of the namespace by using test-asdf/foo systems for new systems; but it's your baby, so your call. Also, an error might not be compatible with putting it in test-asdf.asd. On the other hand, that's a case where define-test-system and/or eval can be used so you don't need a .asd file at all. * the nodes in the grammar could be renamed to be less confusing and not require a comment. —♯ƒ • François-René ÐVB Rideau •Reflection&Cybernethics• http://fare.tunes.org The politicians have a most touching faith in technology — that it can make up for any dumb thing the politicians decide to do. — John McCarthy

3 3

[asdf-devel] :depends-on to load-system or require-system?
by John Morrison 08 Apr '15

08 Apr '15

Hi All; tl:dr - AFAICT post-version-2.26-ish versions of ASDF systems listed in :depends-on are unconditionally loaded rather than required - ditto for asdf:load-system. If this is correct (both in intent and my understanding), then how to create a GUI for quicklisp in McCLIM which can quickload any system which :depends-on McCLIM? Apologies in advance in the likely event this is Pilot Error. Am trying to write a gui<https://bitbucket.org/symbolicsimulation/com.symsim.oss.ql-gui>for quicklisp. Testing on various platforms (Raspberry Pi, linux/SBCL, linux/CCL) with various vintages of ASDF produces differing behavior. In particular, quickloading a system which depends upon McCLIM from the McCLIM-based gui screws up (I haven't tracked down the exact problem, but I could understand why unconditionally reloading McCLIM while it's running could get weird). After some digging (and rebuilding various versions of SBCL up to 1.1.9), I got as far as seeing asdf:load-system behavior diverging from 2.26 (SBCL 1.0.9) to both 2.32 (CCL 1.9) and 3.0.2 (both SBCL and CCL). AFAICT 2.26 load-system does not unconditionally load an already-loaded system (behaving like and perhaps redundant to asdf:require-system). 2.32 and 3.0.2 load-system unconditionally load systems, and require-system does not. I think I understand why the newer vintages do this. The issue for me is loading systems that :depend-on McCLIM from inside a McCLIM frame command. In my naivety, I would think that the :depends-on systems should be required rather than loaded (if you've patched them, say, you wouldn't want the patch hammered). For my own stuff, I guess I could require prerequisite systems within the asd file rather than :depending-on them, but this seems wrong (breaks introspection?) - so wrong I feel I may be going about this entirely the wrong way. Would anybody please be so kind as to throw some advice my way? -jm

4 9

[asdf-devel] Releasing asdf 3.1.1 ?
by Faré 08 Apr '15

08 Apr '15

Dear Robert, do you think we can release this year? All tests pass for me on Linux, and I believe all tests were passing for Dave Cooper on Windows. There has been very light development this past month, with no intent for further development ahead, but notable new features and bug fixes since the last release in October. —♯ƒ • François-René ÐVB Rideau •Reflection&Cybernethics• http://fare.tunes.org A student who changes the course of history is probably taking an exam.

5 21

[asdf-devel] One failure on ASDF 3.1.0.70 on Allegro/Windows
by Dave Cooper 08 Apr '15

08 Apr '15

Sorry to be late to the party again with Windows testing... So far I'm seeing a consistent failure for every Allegro variant on Windows for test-sysdef-asdf. Here is the error: These two expressions fail comparison with equal: (asdf-test::system-lisp-files :uiop) evaluates to ("uiop\\package.lisp" "uiop\\common-lisp.lisp" "uiop\\utility.lisp" "uiop\\os.lisp" "uiop\\pathname.lisp" "uiop\\filesystem.lisp" "uiop\\stream.lisp" "uiop\\image.lisp" "uiop\\run-program.lisp" "uiop\\lisp-build.lisp" "uiop\\configuration.lisp" "uiop\\backward-driver.lisp" "uiop\\driver.lisp") (asdf-test::makefile-lisp-files "driver-files") evaluates to ("uiop/package.lisp" "uiop/common-lisp.lisp" "uiop/utility.lisp" "uiop/os.lisp" "uiop/pathname.lisp" "uiop/filesystem.lisp" "uiop/stream.lisp" "uiop/image.lisp" "uiop/run-program.lisp" "uiop/lisp-build.lisp" "uiop/configuration.lisp" "uiop/backward-driver.lisp" "uiop/driver.lisp") Script failed -- My Best, Dave Cooper, Genworks Support david.cooper(a)genworks.com, dave.genworks.com(skype) USA: 248-327-3253(o), 1-248-330-2979(mobile) UK: 0191 645 1699

7 27

[asdf-devel] The issue at hand
by Robert P. Goldman 08 Apr '15

08 Apr '15

James Anderson has asked for a "concise statement of the issue at hand." Faré has had to change the semantics of the OPERATION class. Previously, the OPERATION class would automatically trigger dependencies downward (notably, if you did an OPERATION on a system, then you had to do that OPERATION as well on that OPERATION's children), "leftward," and onto itself ("selfward"). The implementation of this left holes, and also caused problems for extensions (e.g., for TEST-OP, one typically had to define a default PERFORM that did nothing, since testing a system necessarily tested all of the files). To fix this, Faré had to add new mixin classes, DOWNWARD-OPERATION, UPWARD-OPERATION, SIDEWAY-OPERATION, and SELFWARD-OPERATION. In order to preserve the integrity of the code, OPERATION remained as the superclass of all operation objects. But its semantics has changed. This is not a problem for anyone with a "vanilla" ASDF system. The only programmers who are vulnerable to this change are those who have defined their own subclasses of OPERATION (or those who use libraries whose programmers have defined subclasses of OPERATION). For those cases, I have pushed a change that checks to make sure that all operations that are instantiated are subclasses of either DOWNWARD-OPERATION, UPWARD-OPERATION, SIDEWAY-OPERATION, SELFWARD-OPERATION, or a new NON-PROPAGATING-OPERATION. If this run-time test fails, an error will be signaled and the programmer will have to fix the offending OPERATION subclass's definition.

8 28

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

08 Apr '15

Tweaked the bundle op so that writing DLLs on Mac generates files with "dylib" as extension instead of "so". To do so, I added os-macosx-p to UIOP. Cheers, r -- 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

1 0