[asdf-devel] Please test before releasing ASDF 3.0.0 - Also, resigning again
Dear Lisp hackers, I'd like to release ASDF 3.0 next week (maybe even later this week). Can you test ASDF before I do? I'll have to produce some document explaining the innovations since ASDF 2.26, 2.000 and/or 1.369, but for now here are just the changes since 2.33. As you can see, it's very minor stuff, and ASDF has been mostly stable these last two months, which is a good sign and the reason why I'm making an official 3.0 release. I'm also inserting a new digit in the version, so releases will have three digits: 3.0.0, 3.0.1, etc. will be minor continuations of 3.0. 3.1.0 will be the next "major" milestone in a series that preserves compatibility, and 4.0 (if ever) will be the next major release that doesn't. But I probably won't be there to see it, because I'm moving away from my Common Lisp job in Cambridge MA to some new as yet undetermined opportunities in NYC that are unlikely to see me do Common Lisp for a living, and I plan to try out different Lisps for a hobby (Racket, Maru, etc.). * Portability: have *uninteresting-conditions* be empty by default. Move stuff to *usual-uninteresting-conditions*, unused by default. Will make the SBCL team happy. Also, fix tests on ABCL. * UIOP: improvements to slurp-input-stream and thus run-program, notably accepting T as alias for *standard-output*, for better backward-compatibility of the deprecated run-shell-command. New macro with-output-file. * POIU support enhanced various tweaks. * Build cleanups. —♯ƒ • François-René ÐVB Rideau •Reflection&Cybernethics• http://fare.tunes.org Of all the things I've lost in life, I miss my mind the most... — Ozzy Ozbourne
Dear Lisp hackers,
I'd like to release ASDF 3.0 next week (maybe even later this week). Can you test ASDF before I do? I get asdf-pathname-test.script failure on SBCL: " These two expressions yield paths that are not pathname-equal
Faré <fahree@gmail.com> writes: the first expression (RESOLVE-LOCATION '("/foo" "bar" "baz")) yields this: #P"/bar/baz" (:HOST #<SB-IMPL::UNIX-HOST {100023F223}> :DEVICE NIL :DIRECTORY (:ABSOLUTE "bar") :NAME "baz" :TYPE :UNSPECIFIC :VERSION NIL) the other expression #P"/foo/bar/baz" yields that: #P"/foo/bar/baz" (:HOST #<SB-IMPL::UNIX-HOST {100023F223}> :DEVICE NIL :DIRECTORY (:ABSOLUTE "foo" "bar") :NAME "baz" :TYPE NIL :VERSION :NEWEST) " -- With best regards, Stas.
Works for me. Weird. Which version of SBCL are you using? —♯ƒ • François-René ÐVB Rideau •Reflection&Cybernethics• http://fare.tunes.org Young man, in mathematics you don't understand things, you just get used to them. — John von Neumann (1903-1957) On Tue, Apr 30, 2013 at 4:25 AM, Stas Boukarev <stassats@gmail.com> wrote:
Faré <fahree@gmail.com> writes:
Dear Lisp hackers,
I'd like to release ASDF 3.0 next week (maybe even later this week). Can you test ASDF before I do? I get asdf-pathname-test.script failure on SBCL: " These two expressions yield paths that are not pathname-equal the first expression (RESOLVE-LOCATION '("/foo" "bar" "baz")) yields this: #P"/bar/baz" (:HOST #<SB-IMPL::UNIX-HOST {100023F223}> :DEVICE NIL :DIRECTORY (:ABSOLUTE "bar") :NAME "baz" :TYPE :UNSPECIFIC :VERSION NIL)
the other expression #P"/foo/bar/baz" yields that: #P"/foo/bar/baz" (:HOST #<SB-IMPL::UNIX-HOST {100023F223}> :DEVICE NIL :DIRECTORY (:ABSOLUTE "foo" "bar") :NAME "baz" :TYPE NIL :VERSION :NEWEST) " -- With best regards, Stas.
On Tue, Apr 30, 2013 at 10:30 AM, Stas Boukarev <stassats@gmail.com> wrote:
I also have a file /foo, if that m
Yes, that probably matters. I don't remember exactly how things go, but I believe that what's going on is that ASDF by default gets truenames at every step, which causes this behaviour. I suppose it should rather error out, expecting a directory pathname, than give this answer. Also, this particular test should probably disable the truename resolution. —♯ƒ • François-René ÐVB Rideau •Reflection&Cybernethics• http://fare.tunes.org Fascists divide in two categories: the fascists and the anti-fascists — Ennio Flaiano
Faré <fahree@gmail.com> writes:
On Tue, Apr 30, 2013 at 10:30 AM, Stas Boukarev <stassats@gmail.com> wrote:
I also have a file /foo, if that m
Yes, that probably matters. I don't remember exactly how things go, but I believe that what's going on is that ASDF by default gets truenames at every step, which causes this behaviour. I suppose it should rather error out, expecting a directory pathname, than give this answer.
Also, this particular test should probably disable the truename resolution. Removing that file results in successful execution of tests.
-- With best regards, Stas.
This is bug worthy. Dunno that I have the courage to fix it before 3.0.0. Maybe a good target for procrastination, though. —♯ƒ • François-René ÐVB Rideau •Reflection&Cybernethics• http://fare.tunes.org You can tell whether a man is clever by his answers. You can tell whether a man is wise by his questions. — Naguib Mahfouz On Tue, Apr 30, 2013 at 10:40 AM, Stas Boukarev <stassats@gmail.com> wrote:
Faré <fahree@gmail.com> writes:
On Tue, Apr 30, 2013 at 10:30 AM, Stas Boukarev <stassats@gmail.com> wrote:
I also have a file /foo, if that m
Yes, that probably matters. I don't remember exactly how things go, but I believe that what's going on is that ASDF by default gets truenames at every step, which causes this behaviour. I suppose it should rather error out, expecting a directory pathname, than give this answer.
Also, this particular test should probably disable the truename resolution. Removing that file results in successful execution of tests.
-- With best regards, Stas.
On ECL 12.12.1 on Mac OSX, test-run-program.script failed for me: ;;; Loading "/Users/rpg/lisp/asdf/test/script-support.lisp" ;;; Loading "/Users/rpg/lisp/asdf/build/fasls/ecl/asdf.fas" Configuring ASDF Enabling debugging Being a bit verbose Comparing directories ASDF-TEST:*TEST-DIRECTORY* and ASDF-TEST::X both evaluate to same path: #P"/Users/rpg/lisp/asdf/test/" Frob packages Internal or unrecoverable error in: illegal stream mode [2: No such file or directory] ;;; ECL C Backtrace ;;; 0 libecl.12.12.dylib 0x000000010e3b68e4 si_dump_c_backtrace + 52 ;;; 1 libecl.12.12.dylib 0x000000010e3a7721 ecl_internal_error + 113 ;;; 2 libecl.12.12.dylib 0x000000010e39abb4 ecl_stream_to_handle + 148 ;;; 3 libecl.12.12.dylib 0x000000010e3dbc50 si_run_program + 1168 ;;; 4 libecl.12.12.dylib 0x000000010e3641b3 si_system + 179 ;;; 5 asdf.fas 0x0000000111514e98 LC359system + 440 ;;; 6 asdf.fas 0x00000001115150db LC360call_system + 523 ;;; 7 asdf.fas 0x000000011151552f LC361uiop_stream__think + 1023 ;;; 8 asdf.fas 0x000000011153bdae L288call_with_temporary_file + 3182 ;;; 9 asdf.fas 0x0000000111515d96 L363run_program + 1334 ;;; 10 asdf.fas 0x00000001114e6356 L849run_shell_command + 758 ;;; 11 libecl.12.12.dylib 0x000000010e373c25 APPLY + 101 ;;; 12 libecl.12.12.dylib 0x000000010e38382c ecl_interpret + 9932 ;;; 13 libecl.12.12.dylib 0x000000010e38b21e eval_form + 350 ;;; 14 libecl.12.12.dylib 0x000000010e38b761 si_eval_with_env + 1281 ;;; 15 libecl.12.12.dylib 0x000000010e3d89e9 si_load_source + 409 ;;; 16 libecl.12.12.dylib 0x000000010e3d91f1 cl_load + 1825 ;;; 17 libecl.12.12.dylib 0x000000010e373c10 APPLY + 80 ;;; 18 libecl.12.12.dylib 0x000000010e38382c ecl_interpret + 9932 ;;; 19 libecl.12.12.dylib 0x000000010e383c5e _ecl_bytecodes_dispatch_vararg + 350 ;;; 20 asdf.fas 0x000000011153e767 L472call_with_asdf_cache + 695 ;;; 21 libecl.12.12.dylib 0x000000010e373c10 APPLY + 80 ;;; 22 libecl.12.12.dylib 0x000000010e38382c ecl_interpret + 9932 ;;; 23 libecl.12.12.dylib 0x000000010e38385a ecl_interpret + 9978 ;;; 24 libecl.12.12.dylib 0x000000010e38b21e eval_form + 350 ;;; 25 libecl.12.12.dylib 0x000000010e386292 compile_toplevel_body + 130 ;;; 26 libecl.12.12.dylib 0x000000010e389f18 compile_form + 600 ;;; 27 libecl.12.12.dylib 0x000000010e38ae15 compile_with_load_time_forms + 53 ;;; 28 libecl.12.12.dylib 0x000000010e38b1b9 eval_form + 249 ;;; 29 libecl.12.12.dylib 0x000000010e38b761 si_eval_with_env + 1281 ;;; 30 libecl.12.12.dylib 0x000000010e380683 cl_eval + 19 ;;; 31 libecl.12.12.dylib 0x000000010e3ab487 dispatch1 + 39 ./run-tests.sh: line 78: 85028 Abort trap: 6 "$@" + echo 'Using ecl, test-run-program.script failed' Using ecl, test-run-program.script failed
I believe this is a bug in ECL. Its can be reproduced this way: (in-package :asdf) (let ((ok1 (format nil "; $ echo ok 1~%ok 1~%"))) (assert-equal (with-output-to-string (s) (let ((*verbose-out* t) (*standard-output* s)) (run-shell-command "echo ok ~D" 1))) ok1)) Or more simply this way: (with-output-to-string (*standard-output*) (uiop:RUN-PROGRAM "echo ok 1" :FORCE-SHELL T :IGNORE-ERROR-STATUS T :OUTPUT T)) I've commented out this test for ECL. Thanks for the bug report! —♯ƒ • François-René ÐVB Rideau •Reflection&Cybernethics• http://fare.tunes.org In a five year period we can get one superb programming language. Only we can't control when the five year period will begin. — Alan Perlis On Mon, Apr 29, 2013 at 6:43 PM, Robert Goldman <rpgoldman@sift.info> wrote:
On ECL 12.12.1 on Mac OSX, test-run-program.script failed for me:
;;; Loading "/Users/rpg/lisp/asdf/test/script-support.lisp" ;;; Loading "/Users/rpg/lisp/asdf/build/fasls/ecl/asdf.fas" Configuring ASDF Enabling debugging Being a bit verbose Comparing directories ASDF-TEST:*TEST-DIRECTORY* and ASDF-TEST::X both evaluate to same path: #P"/Users/rpg/lisp/asdf/test/" Frob packages
Internal or unrecoverable error in: illegal stream mode [2: No such file or directory]
;;; ECL C Backtrace ;;; 0 libecl.12.12.dylib 0x000000010e3b68e4 si_dump_c_backtrace + 52 ;;; 1 libecl.12.12.dylib 0x000000010e3a7721 ecl_internal_error + 113 ;;; 2 libecl.12.12.dylib 0x000000010e39abb4 ecl_stream_to_handle + 148 ;;; 3 libecl.12.12.dylib 0x000000010e3dbc50 si_run_program + 1168 ;;; 4 libecl.12.12.dylib 0x000000010e3641b3 si_system + 179 ;;; 5 asdf.fas 0x0000000111514e98 LC359system + 440 ;;; 6 asdf.fas 0x00000001115150db LC360call_system + 523 ;;; 7 asdf.fas 0x000000011151552f LC361uiop_stream__think + 1023 ;;; 8 asdf.fas 0x000000011153bdae L288call_with_temporary_file + 3182 ;;; 9 asdf.fas 0x0000000111515d96 L363run_program + 1334 ;;; 10 asdf.fas 0x00000001114e6356 L849run_shell_command + 758 ;;; 11 libecl.12.12.dylib 0x000000010e373c25 APPLY + 101 ;;; 12 libecl.12.12.dylib 0x000000010e38382c ecl_interpret + 9932 ;;; 13 libecl.12.12.dylib 0x000000010e38b21e eval_form + 350 ;;; 14 libecl.12.12.dylib 0x000000010e38b761 si_eval_with_env + 1281 ;;; 15 libecl.12.12.dylib 0x000000010e3d89e9 si_load_source + 409 ;;; 16 libecl.12.12.dylib 0x000000010e3d91f1 cl_load + 1825 ;;; 17 libecl.12.12.dylib 0x000000010e373c10 APPLY + 80 ;;; 18 libecl.12.12.dylib 0x000000010e38382c ecl_interpret + 9932 ;;; 19 libecl.12.12.dylib 0x000000010e383c5e _ecl_bytecodes_dispatch_vararg + 350 ;;; 20 asdf.fas 0x000000011153e767 L472call_with_asdf_cache + 695 ;;; 21 libecl.12.12.dylib 0x000000010e373c10 APPLY + 80 ;;; 22 libecl.12.12.dylib 0x000000010e38382c ecl_interpret + 9932 ;;; 23 libecl.12.12.dylib 0x000000010e38385a ecl_interpret + 9978 ;;; 24 libecl.12.12.dylib 0x000000010e38b21e eval_form + 350 ;;; 25 libecl.12.12.dylib 0x000000010e386292 compile_toplevel_body + 130 ;;; 26 libecl.12.12.dylib 0x000000010e389f18 compile_form + 600 ;;; 27 libecl.12.12.dylib 0x000000010e38ae15 compile_with_load_time_forms + 53 ;;; 28 libecl.12.12.dylib 0x000000010e38b1b9 eval_form + 249 ;;; 29 libecl.12.12.dylib 0x000000010e38b761 si_eval_with_env + 1281 ;;; 30 libecl.12.12.dylib 0x000000010e380683 cl_eval + 19 ;;; 31 libecl.12.12.dylib 0x000000010e3ab487 dispatch1 + 39 ./run-tests.sh: line 78: 85028 Abort trap: 6 "$@" + echo 'Using ecl, test-run-program.script failed' Using ecl, test-run-program.script failed
Faré, your code is not valid in ECL because ECL does not support to use run-program with output to text strings. This is not a bug but something that would involve some major redesign of the function we have. On Tue, Apr 30, 2013 at 2:52 AM, Faré <fahree@gmail.com> wrote:
I believe this is a bug in ECL.
Its can be reproduced this way:
(in-package :asdf) (let ((ok1 (format nil "; $ echo ok 1~%ok 1~%"))) (assert-equal (with-output-to-string (s) (let ((*verbose-out* t) (*standard-output* s)) (run-shell-command "echo ok ~D" 1))) ok1))
Or more simply this way: (with-output-to-string (*standard-output*) (uiop:RUN-PROGRAM "echo ok 1" :FORCE-SHELL T :IGNORE-ERROR-STATUS T :OUTPUT T))
I've commented out this test for ECL.
Thanks for the bug report!
—♯ƒ • François-René ÐVB Rideau •Reflection&Cybernethics• http://fare.tunes.org In a five year period we can get one superb programming language. Only we can't control when the five year period will begin. — Alan Perlis
On Mon, Apr 29, 2013 at 6:43 PM, Robert Goldman <rpgoldman@sift.info> wrote:
On ECL 12.12.1 on Mac OSX, test-run-program.script failed for me:
;;; Loading "/Users/rpg/lisp/asdf/test/script-support.lisp" ;;; Loading "/Users/rpg/lisp/asdf/build/fasls/ecl/asdf.fas" Configuring ASDF Enabling debugging Being a bit verbose Comparing directories ASDF-TEST:*TEST-DIRECTORY* and ASDF-TEST::X both evaluate to same path: #P"/Users/rpg/lisp/asdf/test/" Frob packages
Internal or unrecoverable error in: illegal stream mode [2: No such file or directory]
;;; ECL C Backtrace ;;; 0 libecl.12.12.dylib 0x000000010e3b68e4 si_dump_c_backtrace + 52 ;;; 1 libecl.12.12.dylib 0x000000010e3a7721 ecl_internal_error + 113 ;;; 2 libecl.12.12.dylib 0x000000010e39abb4 ecl_stream_to_handle + 148 ;;; 3 libecl.12.12.dylib 0x000000010e3dbc50 si_run_program + 1168 ;;; 4 libecl.12.12.dylib 0x000000010e3641b3 si_system + 179 ;;; 5 asdf.fas 0x0000000111514e98 LC359system + 440 ;;; 6 asdf.fas 0x00000001115150db LC360call_system + 523 ;;; 7 asdf.fas 0x000000011151552f LC361uiop_stream__think + 1023 ;;; 8 asdf.fas 0x000000011153bdae L288call_with_temporary_file + 3182 ;;; 9 asdf.fas 0x0000000111515d96 L363run_program + 1334 ;;; 10 asdf.fas 0x00000001114e6356 L849run_shell_command + 758 ;;; 11 libecl.12.12.dylib 0x000000010e373c25 APPLY + 101 ;;; 12 libecl.12.12.dylib 0x000000010e38382c ecl_interpret + 9932 ;;; 13 libecl.12.12.dylib 0x000000010e38b21e eval_form + 350 ;;; 14 libecl.12.12.dylib 0x000000010e38b761 si_eval_with_env + 1281 ;;; 15 libecl.12.12.dylib 0x000000010e3d89e9 si_load_source + 409 ;;; 16 libecl.12.12.dylib 0x000000010e3d91f1 cl_load + 1825 ;;; 17 libecl.12.12.dylib 0x000000010e373c10 APPLY + 80 ;;; 18 libecl.12.12.dylib 0x000000010e38382c ecl_interpret + 9932 ;;; 19 libecl.12.12.dylib 0x000000010e383c5e _ecl_bytecodes_dispatch_vararg + 350 ;;; 20 asdf.fas 0x000000011153e767 L472call_with_asdf_cache + 695 ;;; 21 libecl.12.12.dylib 0x000000010e373c10 APPLY + 80 ;;; 22 libecl.12.12.dylib 0x000000010e38382c ecl_interpret + 9932 ;;; 23 libecl.12.12.dylib 0x000000010e38385a ecl_interpret + 9978 ;;; 24 libecl.12.12.dylib 0x000000010e38b21e eval_form + 350 ;;; 25 libecl.12.12.dylib 0x000000010e386292 compile_toplevel_body + 130 ;;; 26 libecl.12.12.dylib 0x000000010e389f18 compile_form + 600 ;;; 27 libecl.12.12.dylib 0x000000010e38ae15 compile_with_load_time_forms + 53 ;;; 28 libecl.12.12.dylib 0x000000010e38b1b9 eval_form + 249 ;;; 29 libecl.12.12.dylib 0x000000010e38b761 si_eval_with_env + 1281 ;;; 30 libecl.12.12.dylib 0x000000010e380683 cl_eval + 19 ;;; 31 libecl.12.12.dylib 0x000000010e3ab487 dispatch1 + 39 ./run-tests.sh: line 78: 85028 Abort trap: 6 "$@" + echo 'Using ecl, test-run-program.script failed' Using ecl, test-run-program.script failed
-- Instituto de Física Fundamental, CSIC c/ Serrano, 113b, Madrid 28006 (Spain) http://juanjose.garciaripoll.googlepages.com
I understand there are implementation constraints, but 1- crashing on this error is probably bad; signalling an error, better. 2- if there is a good way to detect this situation, I could revert to running to a stream or file, capturing the stream or file and returning the string. Anyway, if there is a bug tracker, this is probably worth an entry. —♯ƒ • François-René ÐVB Rideau •Reflection&Cybernethics• http://fare.tunes.org If you want to do good, work on the technology, not on getting power. — John McCarthy On Tue, Apr 30, 2013 at 12:02 PM, Juan Jose Garcia-Ripoll <jjgarcia@users.sourceforge.net> wrote:
Faré, your code is not valid in ECL because ECL does not support to use run-program with output to text strings. This is not a bug but something that would involve some major redesign of the function we have.
On Tue, Apr 30, 2013 at 2:52 AM, Faré <fahree@gmail.com> wrote:
I believe this is a bug in ECL.
Its can be reproduced this way:
(in-package :asdf) (let ((ok1 (format nil "; $ echo ok 1~%ok 1~%"))) (assert-equal (with-output-to-string (s) (let ((*verbose-out* t) (*standard-output* s)) (run-shell-command "echo ok ~D" 1))) ok1))
Or more simply this way: (with-output-to-string (*standard-output*) (uiop:RUN-PROGRAM "echo ok 1" :FORCE-SHELL T :IGNORE-ERROR-STATUS T :OUTPUT T))
I've commented out this test for ECL.
Thanks for the bug report!
—♯ƒ • François-René ÐVB Rideau •Reflection&Cybernethics• http://fare.tunes.org In a five year period we can get one superb programming language. Only we can't control when the five year period will begin. — Alan Perlis
On Mon, Apr 29, 2013 at 6:43 PM, Robert Goldman <rpgoldman@sift.info> wrote:
On ECL 12.12.1 on Mac OSX, test-run-program.script failed for me:
;;; Loading "/Users/rpg/lisp/asdf/test/script-support.lisp" ;;; Loading "/Users/rpg/lisp/asdf/build/fasls/ecl/asdf.fas" Configuring ASDF Enabling debugging Being a bit verbose Comparing directories ASDF-TEST:*TEST-DIRECTORY* and ASDF-TEST::X both evaluate to same path: #P"/Users/rpg/lisp/asdf/test/" Frob packages
Internal or unrecoverable error in: illegal stream mode [2: No such file or directory]
;;; ECL C Backtrace ;;; 0 libecl.12.12.dylib 0x000000010e3b68e4 si_dump_c_backtrace + 52 ;;; 1 libecl.12.12.dylib 0x000000010e3a7721 ecl_internal_error + 113 ;;; 2 libecl.12.12.dylib 0x000000010e39abb4 ecl_stream_to_handle + 148 ;;; 3 libecl.12.12.dylib 0x000000010e3dbc50 si_run_program + 1168 ;;; 4 libecl.12.12.dylib 0x000000010e3641b3 si_system + 179 ;;; 5 asdf.fas 0x0000000111514e98 LC359system + 440 ;;; 6 asdf.fas 0x00000001115150db LC360call_system + 523 ;;; 7 asdf.fas 0x000000011151552f LC361uiop_stream__think + 1023 ;;; 8 asdf.fas 0x000000011153bdae L288call_with_temporary_file + 3182 ;;; 9 asdf.fas 0x0000000111515d96 L363run_program + 1334 ;;; 10 asdf.fas 0x00000001114e6356 L849run_shell_command + 758 ;;; 11 libecl.12.12.dylib 0x000000010e373c25 APPLY + 101 ;;; 12 libecl.12.12.dylib 0x000000010e38382c ecl_interpret + 9932 ;;; 13 libecl.12.12.dylib 0x000000010e38b21e eval_form + 350 ;;; 14 libecl.12.12.dylib 0x000000010e38b761 si_eval_with_env + 1281 ;;; 15 libecl.12.12.dylib 0x000000010e3d89e9 si_load_source + 409 ;;; 16 libecl.12.12.dylib 0x000000010e3d91f1 cl_load + 1825 ;;; 17 libecl.12.12.dylib 0x000000010e373c10 APPLY + 80 ;;; 18 libecl.12.12.dylib 0x000000010e38382c ecl_interpret + 9932 ;;; 19 libecl.12.12.dylib 0x000000010e383c5e _ecl_bytecodes_dispatch_vararg + 350 ;;; 20 asdf.fas 0x000000011153e767 L472call_with_asdf_cache + 695 ;;; 21 libecl.12.12.dylib 0x000000010e373c10 APPLY + 80 ;;; 22 libecl.12.12.dylib 0x000000010e38382c ecl_interpret + 9932 ;;; 23 libecl.12.12.dylib 0x000000010e38385a ecl_interpret + 9978 ;;; 24 libecl.12.12.dylib 0x000000010e38b21e eval_form + 350 ;;; 25 libecl.12.12.dylib 0x000000010e386292 compile_toplevel_body + 130 ;;; 26 libecl.12.12.dylib 0x000000010e389f18 compile_form + 600 ;;; 27 libecl.12.12.dylib 0x000000010e38ae15 compile_with_load_time_forms + 53 ;;; 28 libecl.12.12.dylib 0x000000010e38b1b9 eval_form + 249 ;;; 29 libecl.12.12.dylib 0x000000010e38b761 si_eval_with_env + 1281 ;;; 30 libecl.12.12.dylib 0x000000010e380683 cl_eval + 19 ;;; 31 libecl.12.12.dylib 0x000000010e3ab487 dispatch1 + 39 ./run-tests.sh: line 78: 85028 Abort trap: 6 "$@" + echo 'Using ecl, test-run-program.script failed' Using ecl, test-run-program.script failed
-- Instituto de Física Fundamental, CSIC c/ Serrano, 113b, Madrid 28006 (Spain) http://juanjose.garciaripoll.googlepages.com
"Fare" == Far <Far> writes:
Fare> Dear Lisp hackers, Fare> I'd like to release ASDF 3.0 next week (maybe even later this week). Fare> Can you test ASDF before I do? You didn't say what version, so I tested with HEAD and cmucl-snapshot-to-be and all 46 tests pass. Fare> will be the next major release that doesn't. But I probably won't be Fare> there to see it, because I'm moving away from my Common Lisp job in Fare> Cambridge MA to some new as yet undetermined opportunities in NYC that Fare> are unlikely to see me do Common Lisp for a living, and I plan to try Fare> out different Lisps for a hobby (Racket, Maru, etc.). Good luck in your new undetermined opportunities! Ray
participants (5)
-
Faré -
Juan Jose Garcia-Ripoll -
Raymond Toy -
Robert Goldman -
Stas Boukarev