asdf-devel

asdf-devel@common-lisp.net

5 participants
1375 discussions

[asdf-devel] 3.1.0.75 pushed: more checking of system names
by Robert P. Goldman 08 Apr '15

08 Apr '15

This is a repair of last night's commit. I added a test for the new system name checks, which had some fan-out -- I needed to fix DEF-TEST-SYSTEM to permit systems named with strings instead of symbols. Also, I check to make sure that all the system names, when being registered, are case-flattened down, and issue a continuable error if not. cheers, r

2 3

[asdf-devel] How should ASDF return cached system definition information
by Robert P. Goldman 08 Apr '15

08 Apr '15

The latest version of ASDF contains three functions: SYSTEM-DEFSYSTEM-DEPENDS-ON SYSTEM-DEPENDS-ON and SYSTEM-WEAKLY-DEPENDS-ON that return information about defined systems. The intention is to support introspection about sets of systems (I believe Quicklisp does this today). Currently, ASDF does *not* put the return values into canonical form. So, equivalent forms like :depends-on (foo) and :depends-on ("foo") will yield different return values. Similarly, :version specifications will not be resolved. This seems wrong to me. I feel that the return values should be canonicalized. So all system names should be resolved down to lower-cased strings. Does that sound like the right approach? It would support performing inference on the systems relatively straightforwardly. I can't imagine why people would want the exact, literal slot initforms, but I could be wrong. R

2 6

[asdf-devel] New release candidate?
by Faré 08 Apr '15

08 Apr '15

3.1.0.70 it is. Passes all tests for me, on Linux x64 on ccl clisp sbcl cmucl allegro allegromodern lispworks ecl_bytecodes ecl abcl xcl gcl Before some patches I just committed for xcl and gcl (!) 3.1.0.68 worked on Mac for Robert Goldman. (Any volunteer to test on Genera? Corman? MCL? Windows?) —♯ƒ • François-René ÐVB Rideau •Reflection&Cybernethics• http://fare.tunes.org Capital is past work. Undermining the rights of past and future workers in favor of present workers is sure to backfire on them tomorrow when their today's work is past and their tomorrow's work has been robbed already.

3 10

[asdf-devel] Reader conditionals in :depends-on considered harmful?
by Dave Cooper 08 Apr '15

08 Apr '15

Hi, Is stuff like the following advised/recommended? ;;;;; (asdf:defsystem #:robot :description "The Gendl™ Simplified Android Robot example " ... :depends-on (#-gendl :gendl) ... ) ;;;;;; The scenario is that we ship a pre-built Gendl image which has no asdf or Quicklisp in it (but does, of course, have :gendl included in *features). Downstream user is then free to load Quicklisp and start pulling in libraries. But if they pull a library (or application, like :robot), which normally should depend-on :gendl, then we don't want it trying to reload the whole gendl system, since it's already built in. I know this was discussed here briefly around the launch of 3.0.3 but I'm still not completely clear on how it should work. If we don't include ASDF and Quicklisp at all in our pre-built image, then I don't see any way for us to tamper with e.g. asdf's registry search functions. I guess the only way to do that would be to provide a custom function for installing Quicklisp and ASDF -- but we have no guarantee that the user will actually follow our function and not simply try to install Quicklisp according to the instructions at quicklisp.org. -- My Best, Dave Cooper, Genworks Support david.cooper(a)genworks.com, dave.genworks.com(skype)

3 2

[asdf-devel] Volunteer for LispWorks testing?
by Robert Goldman 08 Apr '15

08 Apr '15

Does anyone have a paid license to LispWorks that they would be willing to use to test our periodic ASDF updates? Alternatively, does anyone have a contact at LispWorks who might be willing to let me have an ASDF-only test version? What I would need is a copy of LW that would start up from the command-line, so that I could run our test scripts. I would be willing to sign a contract promising not to use it for other purposes. Such a copy would have to run on MacOS X and/or linux (I don't have access to Windows, nor am I interested in mastering it again). Thanks! Robert

2 1

trying some ASDF tests on Windows (was: Re: [asdf-devel] Volunteer for LispWorks testing?)
by Dave Cooper 08 Apr '15

08 Apr '15

Hi Robert, [also cc'ing this to asdf-devel in case anyone else has feedback] Ok, shifting gears a little bit here first... I'm trying a few test runs of the ASDF test suite on Windows. Platforms on Windows which I have available to test right now are: Allegro CL (several variations), and CCL. To prepare to run the tests on Windows, I installed cygwin and cygwin's make. Then to run the tests, I do (for lack of having this more automated so far): 1. set ASDF_TEST_LISPS appropriately. 2. Edit run-tests.sh to point to appropriate Lisp executables. 3 Invoke "make test-all-no-upgrade" from the cygwin command shell. Let's try CCL first. Here are the outputs: https://www.dropbox.com/sh/jc2cqwpkp06dupm/-vvd5gFwTk/cl/tests/asdf/output/… Summary: 42 out of 47 pass (5 failures). I can try to dive into these further, but I thought I would post the results here first in case anything is obvious to anyone. Incidentally, I have been running ASDF in production with Allegro CL for some time now (including asdf:monolithic-fasl-op) and it has been working well. There are some startup glitches for running ASDF tests on Windows/Allegro right now. After the CCL issue is resolved I will return to trying to get the tests to run for Allegro on Windows. Regards, Dave P.S. I can see the Launchpad link you sent earlier. On Tue, Sep 3, 2013 at 8:41 PM, Robert P. Goldman <rpgoldman(a)sift.info>wrote: > Dave Cooper wrote: > > In the meantime do you think it's worth me diving into what is > > apparently this one test failure on LWM? > > That would be great, thanks! > > If there is anything I can do to help you get acclimated and figure it > out, let me know. I haven't had a chance to look into it yet. I've > been on vacation and now I'm in the thick of things at work. > > I will try to put some notes in the ASDF ticket on launchpad. Can you > see that? If not, please let me know. > > Best, > Robert > > > > -- 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

3 2

[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

Jump to page:

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

asdf-devel