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

Trying for 3.1.6 release tomorrow
by Robert Goldman 15 Oct '15

15 Oct '15

I have all new Allegro 10 versions. I'll be installing these on Linux, Windows, and Mac, then re-running all the tests. If the tests pass, I'll try to push out 3.1.6 tomorrow sometime. Cheers, r

1 0

Towards release 3.1.6
by Faré 15 Oct '15

15 Oct '15

With the sbcl/windows regression on uiop:run-program fixed (1), and the lib-op and monolithic-lib-op features reasonably implemented on all implementations beyond ECL & co (though requiring a CFFI patch), I believe we're all set for ASDF 3.1.6. Anton, do you have time to make a test run of cl-test-grid? If some of you believe the C linking features should (or shouldn't) be included in this release (or the next one), now is the time to voice your opinion. It's 300 to 400 more lines of code — or 800 if we splurge and merge in most of lisp-invocation as we go instead of special-casing it. (1) A real fix requires fixing SBCL. https://bugs.launchpad.net/asdf/+bug/1501373 —♯ƒ • François-René ÐVB Rideau •Reflection&Cybernethics• http://fare.tunes.org When you've seen one nuclear war, you've seen them all.

3 11

Relocating asdf fasl cache
by 73budden . 15 Oct '15

15 Oct '15

Hi! I make a "portable file release" of my software. I want that user could just unpack archive to some "my" directory and than have the software completely independent from any other possible CL installations on this computer. I found (too) many words about output translations in asdf manual, but I was unable to find out how I will do what I need. My solution and relevant portions in my .sbclrc (for SBCL) follow: (require :uiop) (setf uiop::*user-cache* #P"c:/clcon/fasl-cache/asdf/") (require 'asdf) ;;; The following lines added by ql:add-to-init-file: #-quicklisp (let ((quicklisp-init "c:/clcon/quicklisp/setup.lisp" )) (when (probe-file quicklisp-init) (load quicklisp-init))) ; swank is handled separatedly (maybe irrelevant to asdf, but relevant ; to task of creating "portable file releases" (load (merge-pathnames "swank-loader.lisp" (ql:where-is-system :swank))) (setq swank-loader::*fasl-directory* "c:/clcon/fasl-cache/swank/") (swank-loader:init) Problem with current docs is that *user-cache* is mentioned in docs, but it is not stated _when_ the default is calculated. This variable have no default value, but it has a function which calculates it. It is not evident when this function is called. So I needed an experiment. I even don't know when value I supplied will be reset back to hard-coded value. If you find it useful, you can consider including it into asdf doc/wiki/FAQ, or address me to the appropriate place. Thank you!

2 2

trouble with :also-exclude
by Attila Lendvai 08 Oct '15

08 Oct '15

i'm not sure what's the expected behavior. what i'm trying to achieve is to exclude some dirs inside my ~/common-lisp/ -------- $ cat ~/.config/common-lisp/source-registry.conf.d/00-excluded-systems.conf (:also-exclude "sbcl" "disabled-systems") $ rlwrap sbcl --no-userinit --no-sysinit This is SBCL 1.2.4.debian, an implementation of ANSI Common Lisp. More information about SBCL is available at <http://www.sbcl.org/>. SBCL is free software, provided as is, with absolutely no warranty. It is mostly in the public domain; some portions are provided under BSD-style licenses. See the CREDITS and COPYING files in the distribution for more information. * (require :asdf) ("ASDF" "asdf" "UIOP" "uiop") ;; force asdf upgrade * (asdf:load-system :asdf) T * (gethash "cl-postgres+local-time" asdf::*source-registry*) #P"/home/alendvai/common-lisp/disabled-systems/local-time.old-darcs/cl-postgres+local-time.asd" T * asdf::*source-registry-exclusions* (".bzr" ".cdv" ".git" ".hg" ".pc" ".svn" "CVS" "RCS" "SCCS" "_darcs" "_sgbak" "autom4te.cache" "cover_db" "_build" "debian") * asdf/upgrade:*asdf-version* "3.1.5.18" ---------- it may or may not be normal that *source-registry-exclusions* doesn't contain "disabled-systems". (trace asdf/source-registry::process-source-registry-directive :print asdf::*source-registry-exclusions*) the output of the above^ trace suggests that it gets processed (and recorded into a dynamically bound variable? which is then thrown away?). any hints? -- • attila lendvai • PGP: 963F 5D5F 45C7 DFCD 0A39 -- “The worst enemy of clear thinking is the propensity to hypostatize, i.e. to ascribe substance or real existence to mental constructs or concepts.” — Ludwig von Mises (1881–1973), 'The Ultimate Foundations of Economic Science' (1962)

2 3

monolithic-lib-op
by Faré 07 Oct '15

07 Oct '15

Difficulties making monolithic-lib-op portable suggest that it (and maybe also lib-op) should output an object file as if by ld -r rather than a static library. Indeed, there is no *portable* way to combine several .a files into a single one on a BSD system (including MacOS X). Or should that be the case only on said systems? In any case, that's ugly, and to make a distinction, we'd have to extend os.lisp to also distinguish bsd-style unix from gnu-style unix. —♯ƒ • François-René ÐVB Rideau •Reflection&Cybernethics• http://fare.tunes.org It is said that pragmatism trumps ideology in a crisis. What actually happens in a crisis, certainly in this one, is that the ruling party gets to rechristen its ideology as pragmatism. — Christopher Caldwell

4 7

Bundle operations
by Robert Goldman 01 Oct '15

01 Oct '15

Are these reasonable across different Lisp implementations? E.g., what would it mean to try to invoke a DLL-OP on ACL, Lispworks, or CCL? It seems like we are advertising a lot of functionality that we do not, in fact, support. I'd like to prune this down in some way, eliminating operations on implementations that don't support them. thanks, r

4 12

Spurious ALLEGRO failure
by Robert Goldman 30 Sep '15

30 Sep '15

I'm getting what look like spurious failures on tests of "allegro" in test-program.script. I *believe* that what's going wrong here is that lisp-invocation is getting confused about how to find the right ACL runtime. If you look at run-tests.sh, you will see that "ALLEGRO" is initially bound using the funky logic at the top of the file, but then is REBOUND on windows to use buildi instead of alisp on that platform.... I *suspect* this is breaking things, because I suspect that the logic for reasoning about the ALLEGRO installation directories is getting run more than once, causing INVOKE-LISP to fail. But INVOKE-LISP doesn't provide any useful information about how it's invoking lisp. I'll investigate somewhat further, but if an explanation jumps out at you, please LMK. I believe that this conjecture is supported by the fact that it is only the "allegro" tests that fail -- not allegro64, none of the modern variants, etc. Cheers, r

3 13

One last test failure: ECL on Linux
by Robert Goldman 30 Sep '15

30 Sep '15

test-xach-update-bug.script fails on both ECL and ECL bytecodes for me on Linux. This is ECL 13.5.1. I *believe* that this is to be expected, and there's an ECL fix for this. Please LMK if that's not true and if I should hold up releasing 3.1.6 for that reason. Otherwise I plan to release today (assuming I can get the necessary time from work).

2 4

uiop:run-program broken on SBCL/Windows.
by Faré 30 Sep '15

30 Sep '15

SANO Masatoshi reports that uiop:run-program broke on SBCL/Windows at some point between 3.1.3 and 3.1.5. Can someone with SBCL and Windows help me debug that? A trace of functions in uiop/run-program and the functions in sb-ext that appear in that file, using ASDF on 3.1.3 and on 3.1.5, on some failed invocation, would help. A fix before 3.1.6 would be wonderful. —♯ƒ • François-René ÐVB Rideau •Reflection&Cybernethics• http://fare.tunes.org The [classical] liberal, of course, does not deny that there are some superior people — he is not an egalitarian — but he denies that anyone has authority to decide who these superior people are. — F. A. Hayek, "Why I Am Not a Conservative"

3 6

test status, impending release, and UIOP/SBCL/Windows bug
by Robert Goldman 30 Sep '15

30 Sep '15

Tests all pass on my Windows VM (thanks to Dave Cooper!). Tests all pass on Mac. Running tests on Linux. After that propose to release 3.1.6. I'd like to get the UIOP fix for SBCL on Windows in place before the release, but still have no bug report, so am not sure how to replicate or fix. Last call for bug report...

1 0