asdf-devel

asdf-devel@common-lisp.net

5 participants
1375 discussions

Re: [asdf-devel] Workaround (was: Canonical function to list ordered components for asdf/bundle:monolithic-fasl-op (was: adsf/bundle:monolithic-fasl sometimes puts dependent system first in list))
by Dave Cooper 18 Mar '13

18 Mar '13

> What is the canonical function to see the list which will be > > written out by asdf/bundle:monolithic-fasl-op? I remember you said it's > not > > really component-depends-on -- so what is it again? > > > -- 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

2 1

[asdf-devel] adsf/bundle:monolithic-fasl sometimes puts dependent system first in list
by Dave Cooper 16 Mar '13

16 Mar '13

Try this: 1. git clone git://github.com/genworks/gendl.git 2. put it in your quicklisp/local-projects/ 3. (ql:register-local-projects) 4. (ql:quickload :gendl) 5. (ql:operate 'asdf/bundle:monolithic-fasl-op :gendl) 6. (first (asdf:output-files 'asdf/bundle:monolithic-fasl-op :gendl)) 7. Copy the yielded pathname string to use in next step. 8. [in a fresh Lisp] (load <the --all-systems fasl from step 7>) 9. [back in first Lisp]: (asdf:component-depends-on 'asdf/bundle:monolithic-fasl-op :gendl) 10. Read it and weep. system :gendl comes _first_ in the list. I feel it should come _last_. I tried to look into the asdf code behind this operation but am afraid it is currently far over my head. -- 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] New tests with upgrade
by Robert Goldman 15 Mar '13

15 Mar '13

Works better, thanks! Still running into an error when trying to upgrade allegromodern from 1.85, though. What's odd is that this fails when running inside 'make test-all': Above backtrace due to this condition: #P"/Users/rpg/lisp/asdf/build/fasls/acl-8.2m-macosx-x64/asdf/build/asdf.fasl" does not exist, cannot load Script failed upgrade FAILED for allegromodern from 1.85 using method 'load-asdf-lisp'load-asdf-system But when I run mlisp -q and follow the directions given: mlisp -q then copy/paste: (load"test/script-support.lisp") (asdf-test::da) (test-upgrade 'load-asdf-lisp'load-asdf-system "1.85") everything is fine: ; Upgraded ASDF from version 1.85 to version 2.32.8 ; Registering #<system "asdf"> ;; ASDF, version 2.32.8 Testing it ;;; Installing streamc patch, version 3. ;;; Compiling file /Users/rpg/lisp/asdf/build/asdf.lisp ;;; Writing fasl file ;;; /Users/rpg/.cache/common-lisp/acl-8.2m-macosx-x64/Users/rpg/lisp/asdf/build/asdf-ASDF-TMP.fasl ;;; Fasl write complete Warning: first-feature is defined more than once as `operator' in file /Users/rpg/lisp/asdf/build/asdf.lisp. Warning: implementation-type is defined more than once as `operator' in file /Users/rpg/lisp/asdf/build/asdf.lisp. Warning: *implementation-type* is defined more than once as `variable' in file /Users/rpg/lisp/asdf/build/asdf.lisp. Warning: operating-system is defined more than once as `operator' in file /Users/rpg/lisp/asdf/build/asdf.lisp. Warning: architecture is defined more than once as `operator' in file /Users/rpg/lisp/asdf/build/asdf.lisp. ;;; Compiling file /Users/rpg/lisp/asdf/test/file1.lisp ;;; Writing fasl file ;;; /Users/rpg/.cache/common-lisp/acl-8.2m-macosx-x64/Users/rpg/lisp/asdf/test/file1-ASDF-TMP.fasl ;;; Fasl write complete ;;; Compiling file /Users/rpg/lisp/asdf/test/file2.lisp ;;; Writing fasl file ;;; /Users/rpg/.cache/common-lisp/acl-8.2m-macosx-x64/Users/rpg/lisp/asdf/test/file2-ASDF-TMP.fasl ;;; Fasl write complete ;;; Compiling file /Users/rpg/lisp/asdf/test/file3.lisp ;;; Writing fasl file ;;; /Users/rpg/.cache/common-lisp/acl-8.2m-macosx-x64/Users/rpg/lisp/asdf/test/file3-ASDF-TMP.fasl ;;; Fasl write complete ;;; Compiling file /Users/rpg/lisp/asdf/test/file4.lisp ;;; Writing fasl file ;;; /Users/rpg/.cache/common-lisp/acl-8.2m-macosx-x64/Users/rpg/lisp/asdf/test/file4-ASDF-TMP.fasl ;;; Fasl write complete Script succeeded nil This suggests the problem may be in the testing infrastructure. best, r

2 1

[asdf-devel] Still having errors on ECL upgrade tests
by Robert Goldman 15 Mar '13

15 Mar '13

This time on 2.32: Testing ASDF upgrade from 2.32 using method 'load-asdf-lisp'load-asdf-lisp-clean make[2]: *** No rule to make target `uiop/package.lisp', needed by `build/asdf.lisp'. Stop. ./test/run-tests.sh -c ecl Cheers, r

2 1

[asdf-devel] ECL upgrade failed
by Robert Goldman 13 Mar '13

13 Mar '13

Ran the tests again today, and got this new error: Configuring ASDF Being a bit verbose Frob packages TEST ABORTED: Cannot use #<"UIOP/DRIVER" package> from #<"ASDF-TEST" package>, because UIOP/PATHNAME:PATHNAME-DIRECTORY-PATHNAME and PATHNAME-DIRECTORY-PATHNAME will cause a name conflict. Script failed upgrade FAILED for ecl from 2.21 using method 'load-asdf-lisp-and-test-uiop'load-asdf-fasl This is ECL 12.12.1, Mac OS X Lion. Best, R

2 1

Re: [asdf-devel] testing ASDF with cl-test-grid
by Anton Vodonosov 13 Mar '13

13 Mar '13

Performed tests with ABCL and ACL (express edition, and on Windows, as my linux system turns out to be too old to run ACL 9.0 and the ACL 8.0 Express license has expired). http://common-lisp.net/project/cl-test-grid/asdf/asdf-diff-20.html ACL shows new problem with portableaserve and via it with all genworks-gdl systems. The error: No defined method for ASDF/ACTION:PERFORM oncompiling #<ORIGINAL-ASERVE "aserve" "dummy"> Aside from that all the failures are (upstream) library errors we saw already on other lisps. All the CRASH results are to be ignored. They are caused by heap size limitation of the ACL Express edition. ABCL shows no new problems. All the failures are upstream library errors we saw already on other lisps and com.informatimago.common-lisp TIMEOUT due to http://trac.common-lisp.net/armedbear/ticket/274. Best regards, - Anton

6 23

[asdf-devel] uiop 2.32.4's uiop.asd has nonexistent (:static-file "contrib/debug.lisp")
by Dave Cooper 09 Mar '13

09 Mar '13

As mentioned in subject: uiop 2.32.4's uiop.asd has nonexistent (:static-file "contrib/debug.lisp") This is causing (ql:quickload :uiop) to warn and consequently force a rebuild of it and all dependent systems. I see there is asdf/contrib/debug.lisp but no such file in uiop/ - is something supposed to be moved around? -- 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

2 1

[asdf-devel] unnecessary recompilation of source files
by Yuan Luo 09 Mar '13

09 Mar '13

Hi, I am using asdf 2.25 with Allegro CL 9.0, running on clusters with nfs. I noticed some processes would unnecessarily recompile source files, causing other processes reporting no .fasl files error. Is this a known issue? How can I prevent asdf from such unnecessary recompilation? Thanks, Yuan

2 1

[asdf-devel] ASDF 2.32 released
by Faré 06 Mar '13

06 Mar '13

Dear Lisp hackers, ASDF 2.32 was released in time for inclusion in the upcoming CCL 1.9. Once again, we invite all implementation vendors and distributors to upgrade the version of ASDF included in their releases. Yes, I know, that's a lot of releases in a bit more than a month. But it was also a lot of development, and a lot of adjustment to reality after that development was first released. We will keep fixing bugs and improve ASDF based on our growing internal test suite and results from Anton Vodonosov's cl-test-grid. This is still a pre-release for ASDF3. Here are the changes, since previous release 2.31, and since previous public announcement for 2.30. >From 2.31 to 2.32: * deferred-warning checks are now disabled by default, to enhance backward compatibility with ASDF 2.26 and earlier. In the future, we will enable them by default, but not until we implement a smoother transition plan. Also, CCL-specific fixes to deferred-warning support. * UIOP is the new official name for ASDF-DRIVER. "Utilities for Implementation- and OS- Portability". Old names remain as package and system nicknames: ASDF/DRIVER ASDF-DRIVER ASDF-UTILS * require-system so systems may depend on implementation-provided modules. * auto-upgrade attempt in operate *before* the implicit find-system. * class specification for components can now be a string to be read as a symbol. * feature conditional dependencies are now debugged and tested: :depends-on ("some-system" (:feature :foo "other-system)) we only recommend them for dependencies between systems; within systems, we recommend you use feature-conditional components with :if-feature :foo and we only provide limited support for the deprecated legacy way of using feature-conditionals with a module having :if-component-dep-fails :ignore while its components specify things like: :in-order-to ((compile-op (feature :foo))) * read-from-file for :version specification is made more useful by using the ASDF-USER package rather than CL (into which interning is forbidden) to read the files. Changes from 2.30 to 2.31: * *default-encoding* is now UTF-8. As tested with cl-test-grid, This is a boon for most programs, that will compile in a more predictable way in a wider range of settings. A handful of unmaintained outliers still need to be fixed. * Downgrade is now explicitly avoided. ASDF will issue a warning if your system is misconfigured in a way that specifies downgrade, but will then ignore the specified ASDF downgrade. * version specifications, when invalid, will lead only to a warning for now; a future ASDF3 may restore the behavior of ASDF 2.27, that raises an errors when there is a bad :version specification, but for now, backward compatibility prevails. * ECL support received several bug fixes. * precompiled-system support was notably fixed, enabling single-fasl deployment of SBCL contribs. —♯ƒ • François-René ÐVB Rideau •Reflection&Cybernethics• http://fare.tunes.org If normative judgments cannot be rational, then science is actually useless. — François Guillaumat

1 0

Re: [asdf-devel] Still having problems on upgrade tests
by Robert Goldman 04 Mar '13

04 Mar '13

On 3/3/13 Mar 3 -8:56 PM, Dave Cooper wrote: > > > Hi Robert, > > If you can outline for me the steps to do it, I can try this on ACL 8.2 > and 9.0 on Windows and Linux, if you like... I am just doing the following: setting ASDF_TEST_LISPS to a list of the lisps I have installed (this would be at least "allegro allegromodern" for you, and perhaps some others. Then I can do make test-all and the scripts will run both static and upgrade tests for all the lisps in ASDF_TEST_LISPS. I also have 8.2 and 9.0. Unfortunately, the make scripts right now aren't that friendly to testing both -- what I do is test each one separately by pushing its install directory onto the shell PATH. > > By the way, out of curiosity, why is it necessary to upgrade asdf for > Allegro? Do you have an image with asdf built in? Franz ships > code/asdf.fasl then updates with code/asdf.xyz - right now (for 9.0 at > least) they are on asdf.002 which just came down last week and is 2.31.1 > I believe. So normally the Allegro will just load the latest asdf fasl > on demand. One nuisance I have noticed is that they have updated the fasls in 8.2 without updating src/asdf.lisp, which means that the asdf you have loaded has drifted from the one for which you have source.... Probably what we most care about is upgrading from the current bundled version to the head and released versions in git. > > Is the test just to make sure that an upgrade works properly for people > who might have saved images and want to update their asdf in that same > image? I will leave these to Faré to answer... cheers, r > > Regards, > > Dave > > > > > On Sun, Mar 3, 2013 at 8:46 PM, Robert Goldman <rpgoldman(a)sift.info > <mailto:rpgoldman@sift.info>> wrote: > > On 3/3/13 Mar 3 -5:38 PM, Faré wrote: > > On Sun, Mar 3, 2013 at 5:41 PM, Robert Goldman > <rpgoldman(a)sift.info <mailto:rpgoldman@sift.info>> wrote: > >> The upgrade test for ACL from 1.85 fails reliably with this error: > >> > >> Warning: COMPILE-FILE warned while performing #<compile-op > on > >> #<cl-source-file "asdf" "build" "asdf">. > >> Warning: COMPILE-FILE failed while performing #<compile-op > on > >> #<cl-source-file "asdf" "build" "asdf">. > >> TEST ABORTED: > >> > #P"/Users/rpg/lisp/asdf/build/fasls/acl-8.2m-macosx-x64/asdf/build/asdf.fasl" > >> does not exist, cannot load > > [...] > >> Script failed > >> upgrade FAILED for allegromodern from 1.85 using method > >> 'load-asdf-lisp'load-asdf-system > >> > >> Interestingly, when I paste the replication string into bash: > >> > >> ASDF_UPGRADE_TEST_TAGS="1.85" > >> ASDF_UPGRADE_TEST_METHODS="'load-asdf-lisp'load-asdf-system" > >> ./test/run-tests.sh -u allegromodern > >> > >> this works fine. > >> > >> So this only fails for me when running in the context of make.... > >> > > Works for me, at least with Allegro 9.0: > > > > make u l=allegro ASDF_UPGRADE_TEST_TAGS=1.85 > > make u l=allegromodern ASDF_UPGRADE_TEST_TAGS=1.85 > > I'm stumped. It fails for me on Allegro 9.0 just as with 8.2 > > Note that this happens for me in the context of 'make test-all' > > > make u l=allegromodern ASDF_UPGRADE_TEST_TAGS=1.85 > > also fails... > > Somehow the build is not working: > > rpg% ls > /Users/rpg/lisp/asdf/build/fasls/acl-9.0m-macosx-x64/asdf/build/asdf.fasl > ls: cannot access > /Users/rpg/lisp/asdf/build/fasls/acl-9.0m-macosx-x64/asdf/build/asdf.fasl: > No such file or directory > > For some reason, I have no asdf.fasl there, but I *do* have an > asdf.lisp... > > I see this, which indicates that the fasl is being written in the wrong > location: > > ; Registering #<system "asdf"> > ;;; Writing fasl file /Users/rpg/lisp/asdf/build/asdf.fasl > ;;; Fasl write complete > Warning: COMPILE-FILE warned while performing #<compile-op > on > #<cl-source-file "asdf" "build" "asdf">. > Warning: COMPILE-FILE failed while performing #<compile-op > on > #<cl-source-file "asdf" "build" "asdf">. > > And that's the file, alright: > > pg% head build/asdf.fasl > ?z??#<<AcL>> /Users/rpg/lisp/asdf/build/asdf.lisp by rpg on > rpgoldman-3.local at 2013-03-03T19:40:46+06\ > using 9.0 [64-bit Mac OS X (Intel)] (Feb 26, 2013 9:53)\ > fasl version = 63\ > runtime version = 33\ > for non-smp lisps; #+8-bit-specific code; #+16-bit-specific code\ > Optimization settings at wfasl time:\ > ((safety 3) (space 1) (speed 2) (compilation-speed 1) (debug 2))\ > > So is there something going awry in the build process? > > Best, > r > > > > > > I can't try allegro 8.2, because my license has expired, and Franz > > only offers one until January 31st 2013, and I don't feel like > > cheating on the system date: > > http://www.franz.com/products/express/ > > > > Is it a case of confusion whereby we changed the way the > > implementation identifier is computed, and asdf creates the fasl in > > one directory but somehow looks for it in another? > > > > What is the command that makes it fail, already? > > > > —♯ƒ • François-René ÐVB Rideau •Reflection&Cybernethics• > http://fare.tunes.org > > The kingly office is entitled to no respect. It was originally > procured by the > > highwayman's methods; it remains a perpetuated crime, can never be > anything but > > the symbol of a crime. It is no more entitled to respect than is > the flag of > > a pirate. — Mark Twain > > > > > _______________________________________________ > asdf-devel mailing list > asdf-devel(a)common-lisp.net <mailto:asdf-devel@common-lisp.net> > http://lists.common-lisp.net/cgi-bin/mailman/listinfo/asdf-devel > > > > > -- > My Best, > > Dave Cooper, Genworks Support > david.cooper(a)genworks.com <mailto:david.cooper@genworks.com>, > dave.genworks.com <http://dave.genworks.com>(skype) > USA: 248-327-3253(o), 1-248-330-2979(mobile) > UK: 0191 645 1699

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