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

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

Spurious failure in SBCL on windows
by Robert Goldman 29 Sep '15

29 Sep '15

When I run test all on Windows, the SBCL tests fail in a spurious way. I get an error that lisp couldn't rename f:\asdf\build\dir1\foo0.asd to f:\asdf\build\dir1\foo1.asd.bak AFAICT this is because CREATE-ASD-FILES in test-configuration.script uses :if-exists :rename-and-delete when it's creating the .asd files. Is this actually necessary? Could we replace this with :supersede, or will something go awry? For now I'm experimenting with that replacement, so please just LMK if this is A Bad Thing. thanks, r

2 1

Understanding UIOP/RUN-PROGRAM
by Mark Evenson 29 Sep '15

29 Sep '15

In a potentially memory constrained environment, I need to portably (across sbcl and ccl at least) process a potentially large (multiple GiB) stream of bytes output from a Linux command. For the curious, "process" here means encrypt with a block cipher and push to the network; whereas the UNIX command is the output of "btrfs send". I wanted to confirm with ASDF developers that as far as I can tell from wrangling with UIOP:RUN-PROGRAM, it isn't going to do what I want because there is no "asynchronous" mode. UIOP:RUN-PROGRAM cannot be "run in the background" like SBCL's SB-EXT:RUN-PROGRAM with :wait nil that allows the output of the sub-process to be gathered and processed in blocks. So, it would always be the case that UIOP/RUN-PROGRAM::SLURP-INPUT-STREAM has "gone through" all the (potentially huge) output of the sub-process before UIOP:RUN-PROGRAM can return. Note that I'm not complaining about UIOP:RUN-PROGAM: it certainly bridges a lot of implementation specific details of the use case for "Execute this command; let me process its output". I'm just trying to affirm my understanding of UIOP and (regrettable) need to move off to do my own CCL/SBCL implementation for my needs. If my understanding is correct, the UIOP maintainers may wish to emphasize the synchronous nature of UIOP:RUN-PROGRAM in its docstring. -- "A screaming comes across the sky. It has happened before, but there is nothing to compare to it now."

3 4

program-op compression
by Florian Margaine 28 Sep '15

28 Sep '15

Hi list, I want to use asdf's program-op to dump an image, using this command: sbcl --eval '(asdf:operate :build-op :my-system)' This works perfectly. An image is correctly dumped, and works fine. However, the image is 70MB. Is it possible to use sb-ext:save-lisp-and-die's :compression option? In the source, I've seen :extra-build-args, but it seems to be a make-build option only. I'm not very familiar with asdf's source though, so I'm surely missing something. Cheers, -- Florian Margaine

2 1

(asdf:operate :build-op :system) creates image in ~/.cache/[...]
by Florian Margaine 28 Sep '15

28 Sep '15

Hi list, I'm trying to use the relatively recent feature to dump an image using asdf's build-op feature, so that I only need this line in my terminal: sbcl --eval "(push \"$PWD/\" asdf:*central-registry*)" --eval '(asdf:operate :build-op :my-system)' Where my-system has the following .asd: (asdf:defsystem #:my-system :description "foo" :serial t :depends-on (:sb-posix) :components ((:file "package") (:file "my-system")) :build-operation "asdf:program-op" :build-pathname "my-system" :entry-point "my-system:main") The binary is built just fine. The issue is that it's created in ~/.cache/common-lisp/sbcl-1.2.15.debian-linux-x64/$PWD/, while I'd just like it to be created in $PWD/. Is this a configuration issue? Where is this setting configured? Regards, -- Florian Margaine

2 3

3.1.6 release candidate test results -- and one patch
by Robert Goldman 26 Sep '15

26 Sep '15

On Linux, I checked: ccl sbcl cmucl allegro allegromodern allegro8 allegromodern8 lispworks clisp ecl ecl_bytecodes mkcl All passed, except ECL and ECL with bytecodes, both of which failed test-xach-update-bug.script But I have only ECL 13.5.1, so this may be wrong. Also note that I checked only with ACL 9. I don't have the ACL 10 release candidate on this machine. But I assume Kevin will have tested that case. On Mac, I checked: ccl clisp sbcl cmucl lispworks allegro_64 allegromodern_64 allegro8_64 allegromodern8_64 allegro_64_s allegromodern_64_s allegro8_64_s allegromodern8_64_s abcl All tests on these lisps pass. On SBCL on the Mac, with version 1.2.15.0.sbcl-1.2.15.0-4bc676e, the tests failed before running, because the ASDF build failed with a deprecation warning. That was because we use SB-DEBUG:BACKTRACE (deprecated) instead of SB-DEBUG:PRINT-BACKTRACE. I made that change and pushed. I'm hoping we don't need to protect this patch with checks to avoid earlier versions of SBCL. For Allegro on the Mac, I checked with both Allegro 9.0 and the Allegro 10.0 pre-release. I'll try Windows next, and if that works, release 3.1.6. Cheers, r

1 1

maintaining non-Lisp systems with ASDF
by Robert Dodier 25 Sep '15

25 Sep '15

Hi, I am exploring the possibility of using ASDF to define systems of non-Lisp code, specifically for Maxima (http://maxima.sourceforge.net) Maxima is written in Lisp but has its own language. I'd like to be able to load programs written in Maxima's language and/or Lisp. It seems like ASDF should be suitable if I can just replace calls to COMPILE-FILE with Maxima's compile_file, and replace LOAD with Maxima's load. After looking over the 3.1.5 source code, it seems like one could clobber COMPILE-FILE* and LOAD* with Maxima-specific versions. That seems suboptimal, since it would be helpful to have the original versions of those functions for loading Lisp files. Can someone give some advice about how to go about adapting ASDF to Maxima? Have there been similar attempts for other applications? The bigger picture is that I'd like to use Quicklisp to download and install Maxima packages, and Quicklisp uses ASDF to compile and load stuff. Thanks in advance for any light you can shed on this problem. Robert Dodier

5 11

3.1.6
by Faré 23 Sep '15

23 Sep '15

I think the code is ready for 3.1.6. I see one regression: logical pathnames on CLISP, that don't play well with the newly used temporary file strategy. I propose we punt on that test and file a bug against CLISP. Maybe some day CLISP will have new maintainers who'll fix it. Anyone who uses logical pathnames DESERVES to lose. —♯ƒ • François-René ÐVB Rideau •Reflection&Cybernethics• http://fare.tunes.org The best place to find a helping hand is at the end of your own arm.

4 7

Release 3.1.6
by Robert Goldman 22 Sep '15

22 Sep '15

Kevin, Does head currently work for you with the new Allegro (and with 9.0) on all three platforms? If so, I'm inclined to suggest we bless this as 3.1.6, since I know of no regressions on other implementations. Out of a sense of tidiness, I'd be happier if you had an x.y.z release version in your released ACL, instead of some transient internal version. But I'm going to be quite busy for the remainder of the month, so if you could let me know ASAP, I will try to squeeze the release around other activities in time that you can incorporate it in ACL. For you, ideally, it should just be a matter of getting a version with a tidier release number. Cheers, Robert

1 0

Standalone application delivery
by Faré 17 Sep '15

17 Sep '15

Dear Lispers, is any of you interested in automating application delivery using ASDF? Now that I fixed ASDF's bundle operations and CFFI, the missing piece is the part where the bundled object files are linked against the runtime to produce a self-contained executable. Is anyone interested in writing it? I have all the pieces (at least for SBCL), but assembling them is not my top priority at the moment. —♯ƒ • François-René ÐVB Rideau •Reflection&Cybernethics• http://fare.tunes.org It's not ignorance that does so much damage; it's knowing so darned much that ain't so. — Josh Billings

2 4

ASDF 3.1.5 test suite issues on ACL (8.2 and 10.0 GM)
by Kevin Layer 17 Sep '15

17 Sep '15

Hi, all. I had an spr with Faré, but I figure it's better to have this discussion on asdf-devel. First, as Faré pointed out, ACL was releasing non-release versions of ASDF. I've rectified that, and I will be using the `release' branch from now on. Second, I can't build 3.1.5 on Windows. See below. Third, I would really love to include the ASDF tests as part of the ACL test suite. It would have prevented so many headaches. To that end, I see these problems: 1. There are reported errors, even on ACL 8.2. I can send the details, but I'm sure someone else can reproduce this. I used ALLEGRO=.../alisp make t u l=allegro in a clone of the asdf repo on the release branch. I used an 8.2 alisp, which was not in my PATH, btw. I don't have any lisps in my PATH (because I want to explicitly choose the version when I run it). 2. The symbolic link issue. The test suite doesn't run at all when the source files are available via a symbolic links. I'll be happy to get some workaround (a file loaded before the tests start so I can set *resolve-symlinks* to nil?). As for the Windows build problem: ;;; Compiling file sys:;contrib;asdf.lisp ;;; (C:\src\scm\acl82.32\src\cl\src\contrib\asdf.lisp) ; While compiling (:top-level-form "asdf.lisp" 321294): Error (from error): Invalid pathname #P"cache": Expected an absolute pathname Once I can build a release version of ASDF, I'll put it out as a patch on 8.2, 9.0 and 10.0. Once the testing issues are resolved, I will immediately add it to the test suite. Thanks. Kevin

6 28

Testing Allegro 10 GM on Windows
by Robert Goldman 16 Sep '15

16 Sep '15

I have just run the tests of HEAD on Windows with the GM. HEAD passes all the tests. Or almost.... I get failures on "allegro" and on "sbcl". I'm pretty sure that these are both bogus, because sbcl wasn't even an element of ASDF_TEST_LISPS! And I did a "make clean" before running the tests. So I suspect something oddball is going on. Don't have time to do any more checking now, though. cheers

1 0

Tests failing on Allegro 10 preview, Mac OS X
by Robert Goldman 11 Sep '15

11 Sep '15

The test-configuration.script and test-logical-pathname.script are failing on the latest Allegro 10 preview on Mac OS X on all the Allegro modern variants, and on the ANSI SMP variants. All tests pass on alisp non-SMP and alisp8 non-SMP. Test configuration: Running test-configuration.script with acl-10.0.pre-final.30s-macosx-x64 ; Loading /Users/rpg/lisp/asdf/test/test-configuration.script subdirectories of dir2/: (#P"/Users/rpg/lisp/asdf/build/dir2/dir3/" #P"/Users/rpg/lisp/asdf/build/dir2/dir4/") subdirectories of dir5/: (#P"/Users/rpg/lisp/asdf/build/dir5/dir6/" #P"/Users/rpg/lisp/asdf/build/dir5/dir7/") Source Registry: #<EQUAL hash-table with 22 entries @ #x1000cb1762> TEST ABORTED: the assertion (FIND-SYSTEM :FOO0 NIL) failed. test-logical-pathname: Test logical pathnames in source-registry, non-recursive TEST ABORTED: Component :TEST-LOGICAL-PATHNAME not found Is this the known no-trailing slash problem? Cheers, r

4 11

Pushed some docstrings
by Robert Goldman 08 Sep '15

08 Sep '15

I pushed documentation strings for some of the bundle operations. Open for comments about their accuracy, helpfulness, etc. At some point I would also like to reopen the issue of how to sync up docstrings and manual. The SBCL manual seems to have a solution to this problem. I'd be willing to use something like Didier's decIt, too. But I need a solution that wouldn't destroy the existing manual. Prefer TeXinfo, also. No Markdown need apply! ;-)

1 0