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

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