asdf-devel April 2014

asdf-devel@common-lisp.net

13 participants
11 discussions

[Asdf-devel] package-system
by Faré 30 Apr '14

30 Apr '14

Dear Lisp hackers, apparently, Xach thinks the name "package-system" is a bad name for the quick-build compatible extension to ASDF that I implemented and is going to be released with ASDF 3.1 — see file package-system.lisp, its use in lisp-interface-library, and the description in the ASDF manual (doc/asdf.texinfo in the master branch). Basic idea: each file starts with a defpackage or define-package, the packages it use's or import-from's or shadowing-import-from's are detected, each package is mapped back to a system, that itself may be mapped to files under a package-system. Before the release is the best time for renaming things. If you have a suggestion for a better name, now is the time to speak, not later. * package-system * quick-build * system-whose-dependencies-are-deduced-from-defined-package-and-whose-pathname-is-deduced-from-its-name * one-package-one-file-one-system * not-quite-faslpath * gangnam-style I suppose the constraints are that it should not be too long, yet somewhat descriptive and not too confusing. Failing that, a brand name. —♯ƒ • François-René ÐVB Rideau •Reflection&Cybernethics• http://fare.tunes.org Where did the water from the Deluge come from, and where did it go?

10 30

[Asdf-devel] Problem with testing on MKCL: more info
by Robert P. Goldman 22 Apr '14

22 Apr '14

CALL-STACK overflow, stack size = 8712192.. upgrade FAILED for mkcl from REQUIRE using method 'load-asdf-lisp'load-asdf-fasl you can retry just that test with: ASDF_UPGRADE_TEST_TAGS="REQUIRE" ASDF_UPGRADE_TEST_METHODS="'load-asdf-lisp'load-asdf-fasl" ./test/\ run-tests.sh -u mkcl or more interactively (and maybe with rlwrap or in emacs), start with: mkcl -norc then copy/paste: (load "test/script-support.lisp") (asdf-test::da) (test-upgrade 'load-asdf-lisp'load-asdf-fasl "REQUIRE")

3 6

[Asdf-devel] Fwd: mkcl crashes during upgrade test
by Jean-Claude Beaudoin 21 Apr '14

21 Apr '14

Forgot to cc the list. ---------- Forwarded message ---------- From: Jean-Claude Beaudoin <jean.claude.beaudoin(a)gmail.com> Date: Mon, Apr 21, 2014 at 9:42 PM Subject: Re: [Asdf-devel] mkcl crashes during upgrade test To: Robert Goldman <rpgoldman(a)sift.info> On Mon, Apr 21, 2014 at 4:33 PM, Robert P. Goldman <rpgoldman(a)sift.info>wrote: > On linux, all the upgrade tests just passed for me with the single > exception of MKCL. I don't know what's going on with the following: > > > > ; Upgraded ASDF from version 3.0.3.0.1 to version 3.1.0.116 > ;; ASDF, version 3.1.0.116 > ;;; Warning: The following packages were referenced in compiled file > (/home/rpg/common-lisp/asdf/bu\ > ild/asdf.lisp) but do not exist yet: (ASDF/PARSE-DEFSYSTEM). > Testing it > Excessive universal-error-handler depth! Probable infinite recursion! > ... > > While loading a fasl file (most probably a version of asdf.fas in this case) a reference to a non-existent package was found. This should be a hard error and not a mere warning. The message mentions the source file the offending file was compiled from, not the real origin of the message, which is somewhat misleading. The mention "Probable infinite recursion!" indicates that the debugger just went into a tail spin and crashed (a fairly common problem in MKCL 1.1.X) so what comes after is most probably a pile of pathological nonsense and should be ignored. BTW, package ASDF/PARSE-DEFSYSTEM does not exists in ASDF 3.0.3. I replaced the code that produced the warning in MKCL to signal an error instead. You'll find it in the MKCL 1.1.X git repository master head. If you could cut-&-paste an exact transcript of what led to the message above it would be quite useful to pinpoint the exact origin of the incident. > When I start up MKCL, and push /home/rpg/common-lisp/asdf/ and > /home/rpg/common-lisp/asdf/uiop/ onto asdf:*central-registry*, then > (asdf:component-pathname (asdf:find-system "asdf")) does the right thing > and (asdf:load-system "asdf") completes, returning T, and afterwards > (ASDF:ASDF-VERSION) returns 3.1.0.116 > > So it seems like this might be a bug with the test infrastructure, > instead of a bug with the actual upgrade. > > It is probably as you say but MKCL 1.1.X could do a better job at not obfuscating the origin of the problem.

1 0

[Asdf-devel] mkcl crashes during upgrade test
by Robert P. Goldman 21 Apr '14

21 Apr '14

On linux, all the upgrade tests just passed for me with the single exception of MKCL. I don't know what's going on with the following: ; Upgraded ASDF from version 3.0.3.0.1 to version 3.1.0.116 ;; ASDF, version 3.1.0.116 ;;; Warning: The following packages were referenced in compiled file (/home/rpg/common-lisp/asdf/bu\ ild/asdf.lisp) but do not exist yet: (ASDF/PARSE-DEFSYSTEM). Testing it Excessive universal-error-handler depth! Probable infinite recursion! Quitting thread: #<thread "Initial" active (17807) 0x2aead6b02a80 0000000002a82000>. Error while trying to load definition for system test-asdf from pathname /home/rpg/common-lisp/asdf\ /test/test-asdf.asd: Error while trying to load definition for system test-asdf from pathname /home\ /rpg/common-lisp/asdf/test/test-asdf.asd: Error while trying to load definition for system test-asd\ f from pathname /home/rpg/common-lisp/asdf/test/test-asdf.asd: Error while trying to load definitio\ n for system test-asdf from pathname /home/rpg/common-lisp/asdf/test/test-asdf.asd: Error while try\ ing to load definition for system test-asdf from pathname /home/rpg/common-lisp/asdf/test/test-asdf\ .asd: Error while trying to load definition for system test-asdf from pathname /home/rpg/common-lis\ p/asdf/test/test-asdf.asd: Error while trying to load definition for system test-asdf from pathname\ /home/rpg/common-lisp/asdf/test/test-asdf.asd: Error while trying to load definition for system te\ st-asdf from pathname /home/rpg/common-lisp/asdf/test/test-asdf.asd: Error while trying to load def\ inition for system test-asdf from pathname /home/rpg/common-lisp/asdf/test/test-asdf.asd: Filesyste\ m error with pathname: #P"/home/rpg/common-lisp/asdf/test/test-asdf.asd". Cannot open file OS Explanation: (errno == 24) Too many open files When I start up MKCL, and push /home/rpg/common-lisp/asdf/ and /home/rpg/common-lisp/asdf/uiop/ onto asdf:*central-registry*, then (asdf:component-pathname (asdf:find-system "asdf")) does the right thing and (asdf:load-system "asdf") completes, returning T, and afterwards (ASDF:ASDF-VERSION) returns 3.1.0.116 So it seems like this might be a bug with the test infrastructure, instead of a bug with the actual upgrade.

1 0

[Asdf-devel] mkcl and asdf
by Faré 20 Apr '14

20 Apr '14

Dear JCB, I managed to compile MKCL from git, but only after I updated its ASDF. Unless you have a good reason, I recommend you only include a bootstrapped version of asdf.lisp in your source tree. You should of course keep generating it from an asdf checkout, and send us any local patch you create (thanks a lot for that!) In 3.1.0.109, I have an attempt at implementing get-optimization-settings on most implementations (allegro is still missing, plus ecl-bytecmp, genera, corman, mcl); my implementation for MKCL does not work and/or proclaim does not work: c::*speed* exists but isn't updated by proclaim. Can you help me fix that? —♯ƒ • François-René ÐVB Rideau •Reflection&Cybernethics• http://fare.tunes.org Compulsory apologies mostly train children to say things they don't mean — that is, to lie. ― Alfie Kohn, 'Unconditional Parenting'

3 11

[Asdf-devel] Please Review! Many updates to the documentation
by Robert P. Goldman 07 Apr '14

07 Apr '14

The version of the manual that's in the docs branch is good enough to release. For those who would like a look, but aren't interested in building it themselves, the current draft is on the web site at: http://common-lisp.net/project/asdf/draft-asdf-manual.pdf or you can navigate to it from the ASDF homepage. PLEASE, PLEASE, PLEASE, if you have a few cycles, I would be very grateful to anyone who would review the manual and send me suggestions or repairs. [If you want to submit patches, use the 'docs' topic branch.] I'm going to set up another test machine and do some hard-core testing this week, but after that we should release. That means testing the latest version of ASDF against your systems -- especially "dark" systems that aren't in Quicklisp or are for local use only -- would be A Great Thing. Best to all...

1 0

[Asdf-devel] :FORCE
by Robert P. Goldman 06 Apr '14

06 Apr '14

In the discussion of CLEAR-SYSTEM, I see the following parenthetical: (It was once conceived that one should provide a list of systems the recompilation of which to force as the @code{:force} keyword argument to @code{load-system}; but this has never worked, and though the feature was fixed in ASDF 2.000, it remains @code{cerror}'ed out as nobody ever used it.) Is that correct? I thought that :FORCE *did* accept these? I'm commenting this out for now.

2 1

[Asdf-devel] TEST-OP
by Robert P. Goldman 06 Apr '14

06 Apr '14

I have just pushed to the docs topic branch a complete rewrite of the recommendations for TEST-OP. I think this rewrite better maintains abstraction, because the testing methods are on the test library, rather than on the library to be tested. I also explained why one should have a separate test library. I have abandoned any attempt at ASDF 2 compatibility, also. It makes the presentation too cumbersome and twisty. I welcome inspection of this changed definition and suggestions for improvement. Best, r

2 1

[Asdf-devel] LOAD-SOURCE-OP
by Robert P. Goldman 06 Apr '14

06 Apr '14

The documentation of LOAD-SOURCE-OP seems contradictory. At first it says that loading source only (and never compiling) is "not workable." But later it describes LOAD-SOURCE-OP as doing just exactly the thing that we say is unworkable. If that is not what LOAD-SOURCE-OP does, what *does* it do? thanks, r

2 1

[Asdf-devel] Chipping away at the manual
by Robert P. Goldman 06 Apr '14

06 Apr '14

If you are interested in the current status, see the 'docs' topic branch. You will see there some work products, particularly a marked up copy of the old manual, with my thoughts about what needs to be done, and a ledger of exported symbols, which should be documented in the manual. Comments and suggestions welcomed. Patches also welcomed, but for that perhaps it's best you contact me. I'd be happy to cede parts of the manual to others. Best, r

2 3

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

asdf-devel April 2014