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

[asdf-devel] android ECL port cache directory problem
by Daniel Kochmański 20 Oct '15

20 Oct '15

Hello, I'm currently working on ECL port for the android. I've managed to make it more or less usable, but I've encountered some problem with the cache directory translation in ASDF. Not sure how to solve it. Everything from the application has to be put in it's directory (in this case its /data/data/org.lisp.ecl/) under directories app_resources/, cache/ etc. To achieve it I set necessary directories from the initializatio script with: sprintf(tmp, "(setq *default-pathname-defaults* #p\"%s/\")", home); si_safe_eval(3, c_string_to_object(tmp), Cnil, OBJNULL); si_select_package(ecl_make_simple_base_string("CL-USER", 7)); si_safe_eval(3, c_string_to_object("(load \"init\")"), Cnil, OBJNULL); Where home points to /data/data/org.lisp.ecl/app_resources/ Also related part of the init.lisp file: -- CUT HERE -- (format t "Setting environment variables~%") (setq *default-directory* *default-pathname-defaults*) (defvar *ecl-home* *default-directory*) (ext:setenv "HOME" (namestring *ecl-home*)) (ext:setenv "USER-CACHE" (namestring (merge-pathnames #P"../cache/" *ecl-home*))) (setf asdf:*user-cache* (merge-pathnames #P"../cache/" *default-pathname-defaults*)) (format t "Loading the modules~%") (require :ASDF) (require :SOCKETS) (require :SERVE-EVENT) (pushnew (namestring *default-pathname-defaults*) asdf:*central-registry*) ;; (asdf::ensure-output-translations) (format t "XXX: DIAG:~% (asdf:compute-output-translations) ~A~% (ext:getenv \"HOME\" ~A~% asdf:*user-cache* ~A~% (truename \"SYS:\") ~A~% *default-pathname-defaults* ~A~%~%" (asdf::compute-output-translations) (ext:getenv "HOME") asdf:*user-cache* (truename "SYS:") *default-pathname-defaults*) (format t "Preparing swank~%") (handler-case (asdf:oos 'asdf:load-op :swank :verbose t) (condition (c) (format t "condition ~A happened~%" c) (format t "filepath SYS:SLIME-2.14;SWANK.ASD.NEWEST: ~A~%" (truename #P"SYS:SLIME-2.14;SWANK.ASD.NEWEST")) (force-output) (error c))) -- CUT HERE -- But this fails with filesystem error for pathname #P"/SLIME-2.14/SWANK-LOADER-tmpWIW7CRE5.FASC" Related part of the logcat output: -- CUT HERE -- I/stdout (19157): Setting environment variables I/stdout (19157): Loading the modules I/stdout (19157): XXX: DIAG: I/stdout (19157): (asdf:compute-output-translations) ((SYS:**;*.*.* T) I/stdout (19157): (/data/data/org.lisp.ecl/cache/**/*.* I/stdout (19157): T) I/stdout (19157): (T I/stdout (19157): /data/data/org.lisp.ecl/cache/**/*.*)) I/stdout (19157): (ext:getenv "HOME" /data/data/org.lisp.ecl/app_resources/ I/stdout (19157): asdf:*user-cache* /data/data/org.lisp.ecl/app_resources/../cache/ I/stdout (19157): (truename "SYS:") /data/data/org.lisp.ecl/app_resources/ I/stdout (19157): *default-pathname-defaults* /data/data/org.lisp.ecl/app_resources/ I/stdout (19157): Preparing swank I/stdout (19157): condition Filesystem error with pathname #P"/SLIME-2.14/SWANK-LOADER-tmpWIW7CRE5.FASC". I/stdout (19157): Either I/stdout (19157): 1) the file does not exist, or I/stdout (19157): 2) we are not allowed to access the file, or I/stdout (19157): 3) the pathname points to a broken symbolic link. happened I/stdout (19157): filepath SYS:SLIME-2.14;SWANK.ASD.NEWEST: /data/data/org.lisp.ecl/app_resources/slime-2.14/swank.asd I/native-activity(19157): EXIT TOP LEVEL -- CUT HERE-- As you can see caches seem to be set up properly. But ECL tries to load the FASC file from the root directory. Note, that if slime files are put directly in app_resources, not in slime-2.14 directory everything loads fine. I would be greatful for any hints. Thanks, Daniel -- Daniel Kochmański | Poznań, Poland ;; aka jackdaniel "Be the change that you wish to see in the world." - Mahatma Gandhi

2 4

License field
by Faré 20 Oct '15

20 Oct '15

I propose we document that the license field should if possible contain an identifier from http://spdx.org/licenses/ http://esr.ibiblio.org/?p=6867 —♯ƒ • François-René ÐVB Rideau •Reflection&Cybernethics• http://fare.tunes.org You think you know when you can learn, are more sure when you can write, even more when you can teach, but certain when you can program. — Alan Perlis

3 6

ASDF 3.1.6 has been released
by Robert P. Goldman 18 Oct '15

18 Oct '15

We would like to announce the release of ASDF 3.1.6, the latest bug fix release for ASDF. As usual many thanks are due to Faré for many bug fixes, clean ups, explanations, etc. Thanks are also owed to Dave Cooper, for testing on the Windows platform, enabling the maintainers to test on Windows, and identifying uncaught bugs. Thanks to Anton Vodonosov for testing the release candidate against Quicklisp on cl-test-grid. Finally, thanks to all who found bugs, provided patches, and used prerelease candidates. We urge implementations that are currently bundling previous versions of ASDF to adopt 3.1.6. 3.1.6 does not introduce any API incompatibilities that we know of, and contains significant bug fixes on multiple platforms and implementations. See the Changelog (below) for a list of the major bug fixes. Details on minor bugfixes can be found at launchpad.net/asdf We had hoped that 3.1.5 would be the last 3.1.x bug fix release, paving the way for us to move to developing ASDF 3.2, which we expect will add new features. Maybe this time! Here is the changelog entry for 3.1.6: Bug fix and portability release: * Fix backtrace on SBCL. * Fix RUN-PROGRAM of string (shell command) on Windows SBCL (ticket #1501373). * Fix a number of issues with bundle operations (especially on non-C-compiler-based implementations). * Fix component-finding in package-inferred-system. * Fix race condition between multiple concurrent lisp processes doing ASDF builds (ticket #1483948). * Fix misplaced fasl cache on Windows. * Miscellaneous bug fixes. * Documentation improvements. -- Robert P. Goldman <rpgoldman(a)sift.net> Sat, 17 Oct 2015 15:01:34 -0500

1 0

ASDF 3.1.6 is released
by Robert Goldman 18 Oct '15

18 Oct '15

We would like to announce the release of ASDF 3.1.6, the latest bug fix release for ASDF. As usual many thanks are due to Faré for many bug fixes, clean ups, explanations, etc. Thanks are also owed to Dave Cooper, for testing on the Windows platform, enabling the maintainers to test on Windows, and identifying uncaught bugs. Thanks to Anton Vodonosov for testing the release candidate against Quicklisp on cl-test-grid. Finally, thanks to all who found bugs, provided patches, and used prerelease candidates. We urge implementations that are currently bundling previous versions of ASDF to adopt 3.1.6. 3.1.6 does not introduce any API incompatibilities that we know of, and contains significant bug fixes on multiple platforms and implementations. See the Changelog (below) for a list of the major bug fixes. Details on minor bugfixes can be found at launchpad.net/asdf We had hoped that 3.1.5 would be the last 3.1.x bug fix release, paving the way for us to move to developing ASDF 3.2, which we expect will add new features. Maybe this time! Here is the changelog entry for 3.1.6: Bug fix and portability release: * Fix backtrace on SBCL. * Fix RUN-PROGRAM of string (shell command) on Windows SBCL (ticket #1501373). * Fix a number of issues with bundle operations (especially on non-C-compiler-based implementations). * Fix component-finding in package-inferred-system. * Fix race condition between multiple concurrent lisp processes doing ASDF builds (ticket #1483948). * Fix misplaced fasl cache on Windows. * Miscellaneous bug fixes. * Documentation improvements. -- Robert P. Goldman <rpgoldman(a)sift.net> Sat, 17 Oct 2015 15:01:34 -0500

1 0

Draft release email for 3.1.6
by Robert Goldman 17 Oct '15

17 Oct '15

Hope to have this out this evening. Here's the announcement. Comments and corrections welcome (for a few hours!).

1 0

3.1.6 progress report
by Robert Goldman 16 Oct '15

16 Oct '15

I have just completed the upgrade tests on the following lisps: ccl sbcl cmucl allegro_64 allegromodern_64 lispworks clisp ecl ecl_bytecodes mkcl and they all passed. So I believe that ASDF 3.1.6 is ready for release. I hope to get this done tomorrow, but worst case it would slip to Monday.

1 0

3.1.6 progress report
by Robert Goldman 16 Oct '15

16 Oct '15

Tests pass for me on all the implementations I have on Mac OS X (Yosemite), linux, and Windows. Now running the upgrade tests on linux on CCL, SBCL, CMUCL, Allegro, lispworks, ECL, ECL bytecodes, and MKCL. If those pass, I will bless the current head as 3.1.6. The upgrade tests are very time consuming, so I'll check in on them tomorrow morning.

3 3

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