OK, so I propose we freeze the current state of ASDF for a release 2.21, hopefully some time next week. Please test 2.20.16.
Changes since 2.20: * New features: * Most importantly, encodings. ASDF now lets you specify an :encoding for a system, module or component, that is used when loading or compiling Lisp files. See the documentation. By default, the only useful value is :utf-8, and we recommend you use UTF-8 everywhere. We intend to make it the default in the future (current default is the legacy behavior of using whichever implicit default your underlying implementation is currently configured to use). An extension asdf-encodings is available that supports more encodings, including autodetection of encoding in the near future. * You can now specify :hostname in your asdf-output-translations, so you can easily share a home directory yet split its fasl cache between several subtly different machines. * Bug Fixes: * lp#982285. since 2.014.4, the default source-registry was skipping anything from /usr or XDG_DATA_DIRS, because of a missing test in getenv-absolute-pathnames. Fixed in .15. * In 2.019.9 aka 2.20, ECL support was broken by using a function in the wrong package (defined in cl-user). Fixed in .1. * logical-pathname support was somewhat broken since 2.017.6, due to the way most implementations fail to read physical namestrings when *default-pathname-defaults* is a logical-pathname. Fixed, together with other logical-pathname issues, and a test case was added to the test suite to ensure no further regression. Works great modulo quirks around implementation bugs on CLISP and Allegro. * Minor tweaks: * Use :unspecific in pathname components on more implementations. * export and/or document more utilities. * add a few missing compatfmt for Genera.
I do not intend to make any further changes to ASDF before the 2.21 release, except for fixes to any bug found, of course. Experiments with encodings and autodetection are redirected to the asdf-encodings system for the time being. Discussion of a possible merge of asdf-encodings into ASDF will happen only after asdf-encodings itself is reasonably stable.
—♯ƒ • François-René ÐVB Rideau •Reflection&Cybernethics• http://fare.tunes.org The mice which helplessly find themselves between the cats teeth acquire no merit from their enforced sacrifice. — Mahatma Gandhi
The :encoding support is a dead end and I suggest it be removed now and not be put forward to the wider community. The documentation encouraging the use of the :encoding option is not constructive. People would be poorly advised to use the :encoding option in preference to an encoding file option.
The latest documentation additions:
"We invite you to embrace UTF-8 as the encoding for non-ASCII characters starting today, even without any explicit specification in your .asd files. Indeed, on some implementations and configurations, UTF-8 is already the :default, and loading your code may cause errors if it is encoded in anything but UTF-8. Therefore, even with the legacy behaviour, non-UTF-8 is guaranteed to break for some users, whereas UTF-8 is pretty much guaranteed not to break anywhere, although it might be read incorrectly on some implementations. In the future, we intend to make @code{:utf-8} the default, to be enforced everywhere, so at least the code is guaranteed to be read correctly everywhere it can be."
People would be poorly advised to use any encoding without regard for the locale. Even UTF-8 is not guaranteed to 'not break anywhere' - just try running SBCL in an ISO-8859-1 locale and loading UTF-8! There is no need to make :utf-8 the default or to enforce it and this is not an appropriate path.
Regards Douglas Crosher
On 04/17/2012 02:29 AM, Faré wrote:
OK, so I propose we freeze the current state of ASDF for a release 2.21, hopefully some time next week. Please test 2.20.16.
Changes since 2.20:
- New features:
- Most importantly, encodings.
ASDF now lets you specify an :encoding for a system, module or component, that is used when loading or compiling Lisp files. See the documentation. By default, the only useful value is :utf-8, and we recommend you use UTF-8 everywhere. We intend to make it the default in the future (current default is the legacy behavior of using whichever implicit default your underlying implementation is currently configured to use). An extension asdf-encodings is available that supports more encodings, including autodetection of encoding in the near future.
- You can now specify :hostname in your asdf-output-translations,
so you can easily share a home directory yet split its fasl cache between several subtly different machines.
- Bug Fixes:
- lp#982285. since 2.014.4, the default source-registry
was skipping anything from /usr or XDG_DATA_DIRS, because of a missing test in getenv-absolute-pathnames. Fixed in .15.
- In 2.019.9 aka 2.20, ECL support was broken by using
a function in the wrong package (defined in cl-user). Fixed in .1.
- logical-pathname support was somewhat broken since 2.017.6,
due to the way most implementations fail to read physical namestrings when *default-pathname-defaults* is a logical-pathname. Fixed, together with other logical-pathname issues, and a test case was added to the test suite to ensure no further regression. Works great modulo quirks around implementation bugs on CLISP and Allegro.
- Minor tweaks:
- Use :unspecific in pathname components on more implementations.
- export and/or document more utilities.
- add a few missing compatfmt for Genera.
I do not intend to make any further changes to ASDF before the 2.21 release, except for fixes to any bug found, of course. Experiments with encodings and autodetection are redirected to the asdf-encodings system for the time being. Discussion of a possible merge of asdf-encodings into ASDF will happen only after asdf-encodings itself is reasonably stable.
—♯ƒ • François-René ÐVB Rideau •Reflection&Cybernethics• http://fare.tunes.org The mice which helplessly find themselves between the cats teeth acquire no merit from their enforced sacrifice. — Mahatma Gandhi
asdf-devel mailing list asdf-devel@common-lisp.net http://lists.common-lisp.net/cgi-bin/mailman/listinfo/asdf-devel
On Tue, Apr 17, 2012 at 10:32, Douglas Crosher dtc-asdf@scieneer.com wrote:
The :encoding support is a dead end and I suggest it be removed now and not be put forward to the wider community. The documentation encouraging the use of the :encoding option is not constructive. People would be poorly advised to use the :encoding option in preference to an encoding file option.
I'm not sure why you say it's a dead-end. It certainly costs very little in terms of lines of code, and guarantees a deterministic behavior without the costs of detection. It's cheaper to put say :encoding :koi8-r in your defsystem than -*- coding: koi8-r -*- in each and every file (assuming each of the contributors' editor is otherwise configured to accept koi8-r for those files).
Until we're ready to merge ~500 lines of code into ASDF itself (which is not a light thing, and supposes the design is stable and widely accepted), I believe this is a good intermediate solution, where the provided extensibility hooks allow everyone to have his way.
The latest documentation additions:
"We invite you to embrace UTF-8 as the encoding for non-ASCII characters starting today, even without any explicit specification in your .asd files. Indeed, on some implementations and configurations, UTF-8 is already the :default, and loading your code may cause errors if it is encoded in anything but UTF-8. Therefore, even with the legacy behaviour, non-UTF-8 is guaranteed to break for some users, whereas UTF-8 is pretty much guaranteed not to break anywhere, although it might be read incorrectly on some implementations. In the future, we intend to make @code{:utf-8} the default, to be enforced everywhere, so at least the code is guaranteed to be read correctly everywhere it can be."
People would be poorly advised to use any encoding without regard for the locale. Even UTF-8 is not guaranteed to 'not break anywhere' - just try running SBCL in an ISO-8859-1 locale and loading UTF-8! There is no need to make :utf-8 the default or to enforce it and this is not an appropriate path.
I disagree, all 8-bit locales will read utf-8 without *breaking*, though displaying funny characters. A utf-8 locale will *break* when reading arbitrary 8-bit files. That's a big difference. As for multibyte CJK locales, yes they may break when fed utf-8 code, but implementations that support them also support unicode, and whoever uses these locales is already having configuration issues that the current asdf proposal will make better, not worse. Therefore, when publishing a library online, your best bet is to use UTF-8. That's not just my personal opinion. That's what the authors of the ~100 libraries that use non-ASCII out of the ~700 in Quicklisp have chosen. If "we" are to formally standardize on anything it should be on this de facto standard.
—♯ƒ • François-René ÐVB Rideau •Reflection&Cybernethics• http://fare.tunes.org A fruitful discussion is a negotiation, out of which emerges meaning. Classic works are standards, and politeness is a protocol, to ease such negotiation. With a reasonably expressive language, neither is strictly needed, but both sure do help, and they are where the general progress happens.
On 4/16/12 9:29 AM, Faré wrote:
OK, so I propose we freeze the current state of ASDF for a release 2.21, hopefully some time next week. Please test 2.20.16.
Where is it? Seems not available in git on c-l.net.
Anyway, FWIW, I ran the most recent version I could find with cmucl 2012-04 on OSX. The test said:
-#--------------------------------------- Using cmulisp -noinit -batch Ran 38 tests: 38 passing and 0 failing all tests apparently successful -#---------------------------------------
I'll try this again once I get 2.20.16 (or later).
Ray
On Tue, Apr 17, 2012 at 22:31, Raymond Toy toy.raymond@gmail.com wrote:
On 4/16/12 9:29 AM, Faré wrote:
OK, so I propose we freeze the current state of ASDF for a release 2.21, hopefully some time next week. Please test 2.20.16.
Where is it? Seems not available in git on c-l.net.
Anyway, FWIW, I ran the most recent version I could find with cmucl 2012-04 on OSX. The test said:
-#--------------------------------------- Using cmulisp -noinit -batch Ran 38 tests: 38 passing and 0 failing all tests apparently successful -#---------------------------------------
I'll try this again once I get 2.20.16 (or later).
Yes it's clearly there (now 2.20.18) on http://common-lisp.net/gitweb?p=projects/asdf/asdf.git Are you using the master branch when checking out from git://common-lisp.net/projects/asdf/asdf.git ?
And I'm getting plenty of low-level failures with cmucl 2011-03. Are you using unicode builds?
—♯ƒ • François-René ÐVB Rideau •Reflection&Cybernethics• http://fare.tunes.org Documentation is worth it just to be able to answer all your mail with 'RTFM'. — Alan Cox
On 4/17/12 10:17 PM, Faré wrote:
Yes it's clearly there (now 2.20.18) on http://common-lisp.net/gitweb?p=projects/asdf/asdf.git Are you using the master branch when checking out from git://common-lisp.net/projects/asdf/asdf.git ?
Yeah, I was on the wrong branch. With the master branch, make lisp fails because when cmucl compiles asdf, there are a few notes which I guess are warnings. If you modify compile-asdf.lisp to ignore the warnings (like it already does for ecl and scl), then the tests can proceed. At the end I get:
-#--------------------------------------- Using cmulisp -noinit -batch Ran 39 tests: 39 passing and 0 failing all tests apparently successful -#---------------------------------------
This is with CMU Common Lisp snapshot-2012-04 (20C Unicode) running on OSX 10.6.8. This is, of course, the "official" build from common-lisp.net.
Where do you get you cmucl binaries from? What OS are you running on?
It's possible something got fixed between 20c and 2012-04, but there haven't really been very many changes.
Ray
On 4/21/12 Apr 21 -10:57 AM, Raymond Toy wrote:
On 4/17/12 10:17 PM, Faré wrote:
Yes it's clearly there (now 2.20.18) on http://common-lisp.net/gitweb?p=projects/asdf/asdf.git Are you using the master branch when checking out from git://common-lisp.net/projects/asdf/asdf.git ?
Yeah, I was on the wrong branch. With the master branch, make lisp fails because when cmucl compiles asdf, there are a few notes which I guess are warnings. If you modify compile-asdf.lisp to ignore the warnings (like it already does for ecl and scl), then the tests can proceed. At the end I get:
-#--------------------------------------- Using cmulisp -noinit -batch Ran 39 tests: 39 passing and 0 failing all tests apparently successful -#---------------------------------------
This is with CMU Common Lisp snapshot-2012-04 (20C Unicode) running on OSX 10.6.8. This is, of course, the "official" build from common-lisp.net.
I thought simple 20c was the official build, since it's all that is mentioned at http://www.cons.org/cmucl/index.html
Please LMK if I should move to using the 2012-04 snapshot and abandon the 20c release.
Where do you get you cmucl binaries from? What OS are you running on?
It's possible something got fixed between 20c and 2012-04, but there haven't really been very many changes.
This isn't what I get on CMU 20c unicode (which I downloaded --- prior to the snapshot).
I get a crash when I try to recompile asdf, done as:
1. start cmucl 2. (require :asdf) 3. push my asdf directory onto asdf:*central-registry* 4. (asdf:load-system :asdf)
The error I get is as follows:
; Compiling Top-Level Form: ; [GC threshold exceeded with 33,192,064 bytes in use. Commencing GC.] ; [GC completed with 25,558,400 bytes retained and 7,633,664 bytes freed.] ; [GC will next occur when at least 37,558,400 bytes are in use.] ; Compiling LAMBDA (.PV-CELL. .NEXT-METHOD-CALL. STRING .REST-ARG.): ; Compiling Top-Level Form: ; Compiling LAMBDA (.PV-CELL. .NEXT-METHOD-CALL. X .REST-ARG.): ; Compiling Top-Level Form: ; Compiling LAMBDA (.PV-CELL. .NEXT-METHOD-CALL. FORM .REST-ARG.): ; Compiling Top-Level Form:
#(11) fell through ETYPECASE expression. Wanted one of (FUNCTION PCL::FAST-INSTANCE-BOUNDP FIXNUM PCL::METHOD-CALL PCL::FAST-METHOD-CALL). [Condition of type CONDITIONS::CASE-FAILURE]
Restarts: 0: [TRY-RECOMPILING] Try recompiling asdf 1: [RETRY ] Retry compiling #<CL-SOURCE-FILE "asdf" "asdf">. 2: [ACCEPT ] Continue, treating compiling #<CL-SOURCE-FILE "asdf" "asdf"> as having been successful. 3: [ABORT ] Return to Top-Level.
Debug (type H for help)
(PCL::INVOKE-EMF #(11) (#<ASDF:LOAD-SOURCE-OP NIL {48935595}> #<ASDF:CL-SOURCE-FILE "asdf" "asdf">)) Source: Error finding source: Error in function DEBUG::GET-FILE-TOP-LEVEL-FORM: Source file no longer exists: target:pcl/boot.lisp.
BACKTRACE:
0] backtrace
0: (PCL::INVOKE-EMF #(11) (#<ASDF:LOAD-SOURCE-OP NIL {48935595}> #<ASDF:CL-SOURCE-FILE "asdf" "asdf">)) 1: ("LAMBDA (G2663 G2664 G2665)" #<unused-arg> #<unused-arg> #<ASDF:LOAD-SOURCE-OP NIL {48935595}> #<ASDF:CL-SOURCE-FILE "asdf" "asdf">) 2: ("LAMBDA (G2726 G2727 G2728)" #<unused-arg> #<unused-arg> #<ASDF:COMPILE-OP NIL {488B52BD}> #<ASDF:CL-SOURCE-FILE "asdf" "asdf">) 3: ((METHOD ASDF::PERFORM-WITH-RESTARTS NIL (ASDF:COMPILE-OP ASDF:CL-SOURCE-FILE)) (#(0) . #(NIL)) #S(PCL::FAST-METHOD-CALL :FUNCTION #<Function # {48202921}> :PV-CELL NIL :NEXT-METHOD-CALL NIL :ARG-INFO (2)) #<ASDF:COMPILE-OP NIL {488B52BD}> #<ASDF:CL-SOURCE-FILE "asdf" "asdf">) 4: ((FLET #:G21)) 5: ((METHOD ASDF::PERFORM-PLAN NIL (LIST)) #<unused-arg> #<unused-arg> ((# . #) (# . #) (# . #) (# . #)) #<unused-arg>) 6: ((METHOD ASDF::PERFORM-PLAN NIL (LIST)) 4 #<unused-arg> #<unused-arg> ((# . #) (# . #) (# . #) (# . #)) ...)[:EXTERNAL] 7: ("DEFMETHOD OPERATE (T T)") 8: (ASDF::CALL-WITH-SYSTEM-DEFINITIONS #<Closure Over Function "DEFMETHOD OPERATE (T T)" {482AB6B1}>) 9: ((METHOD ASDF:OPERATE NIL (T T)) #<unused-arg> #<unused-arg> ASDF:LOAD-OP "asdf" ...) 10: (ASDF:LOAD-SYSTEM "asdf") 11: (INTERACTIVE-EVAL (ASDF:LOAD-SYSTEM "asdf")) 12: (LISP::%TOP-LEVEL) 13: ((LABELS LISP::RESTART-LISP SAVE-LISP))
0]
The only recognizable (to me) lines in the output are:
; Converted DEFGENERIC*. ; Converted DEFUN*.
after that all I see is a lot of lines with
; Compiling LAMBDA (.PV-CELL. .NEXT-METHOD-CALL. X): ; Compiling Top-Level Form:
Should there be a top level form echoed there for me to read? I am not getting it. I don't see any list of top level forms.
Cheers, r
On 4/21/12 12:04 PM, Robert Goldman wrote:
This is with CMU Common Lisp snapshot-2012-04 (20C Unicode) running on OSX 10.6.8. This is, of course, the "official" build from common-lisp.net.
I thought simple 20c was the official build, since it's all that is mentioned at http://www.cons.org/cmucl/index.html
Dang. I thought I had updated those pages but didn't. FWIW, trac.common-lisp.net/cmucl is a bit more up-to-date because it's way easier to edit.
Please LMK if I should move to using the 2012-04 snapshot and abandon the 20c release.
I don't think there were many changes, but let me investigate with 20c. If 20c fails (as you show) and 2012-04 doesn't, then I'd say use 2012-04. :-)
Ray
On 4/21/12 12:04 PM, Robert Goldman wrote:
This isn't what I get on CMU 20c unicode (which I downloaded --- prior to the snapshot).
I get a crash when I try to recompile asdf, done as:
- start cmucl
- (require :asdf)
- push my asdf directory onto asdf:*central-registry*
- (asdf:load-system :asdf)
The error I get is as follows:
Thanks for the recipe. I can reproduce this with 20c. I also get an error with 2012-04, but the error is slightly different. I definitely didn't change pcl between these releases. Something else must be going on, but I don't know what.
Ray
On 4/21/12 1:45 PM, Raymond Toy wrote:
On 4/21/12 12:04 PM, Robert Goldman wrote:
This isn't what I get on CMU 20c unicode (which I downloaded --- prior to the snapshot).
I get a crash when I try to recompile asdf, done as:
- start cmucl
- (require :asdf)
- push my asdf directory onto asdf:*central-registry*
- (asdf:load-system :asdf)
The error I get is as follows:
Thanks for the recipe. I can reproduce this with 20c. I also get an error with 2012-04, but the error is slightly different. I definitely didn't change pcl between these releases. Something else must be going on, but I don't know what.
Oops. I guess I should include the error message. Does this make sense to you?
No matching method for the generic function #<STANDARD-GENERIC-FUNCTION ASDF:OUTPUT-FILES (5) {487748F1}>, when called with arguments (#<ASDF:COMPILE-OP NIL {48677415}> #<ASDF:CL-SOURCE-FILE "asdf" "asdf">). [Condition of type PCL::NO-APPLICABLE-METHOD-ERROR]
Restarts: 0: [CONTINUE] Retry call to :FUNCTION. 1: [RETRY ] Retry compiling #<CL-SOURCE-FILE "asdf" "asdf">. 2: [ACCEPT ] Continue, treating compiling #<CL-SOURCE-FILE "asdf" "asdf"> as having been successful. 3: [ABORT ] Return to Top-Level.
Ray
On 4/21/12 Apr 21 -3:50 PM, Raymond Toy wrote:
On 4/21/12 1:45 PM, Raymond Toy wrote:
On 4/21/12 12:04 PM, Robert Goldman wrote:
This isn't what I get on CMU 20c unicode (which I downloaded --- prior to the snapshot).
I get a crash when I try to recompile asdf, done as:
- start cmucl
- (require :asdf)
- push my asdf directory onto asdf:*central-registry*
- (asdf:load-system :asdf)
The error I get is as follows:
Thanks for the recipe. I can reproduce this with 20c. I also get an error with 2012-04, but the error is slightly different. I definitely didn't change pcl between these releases. Something else must be going on, but I don't know what.
Oops. I guess I should include the error message. Does this make sense to you?
No matching method for the generic function #<STANDARD-GENERIC-FUNCTION ASDF:OUTPUT-FILES (5) {487748F1}>, when called with arguments (#<ASDF:COMPILE-OP NIL {48677415}> #<ASDF:CL-SOURCE-FILE "asdf" "asdf">). [Condition of type PCL::NO-APPLICABLE-METHOD-ERROR]
Restarts: 0: [CONTINUE] Retry call to :FUNCTION. 1: [RETRY ] Retry compiling #<CL-SOURCE-FILE "asdf" "asdf">. 2: [ACCEPT ] Continue, treating compiling #<CL-SOURCE-FILE "asdf" "asdf"> as having been successful. 3: [ABORT ] Return to Top-Level.
I can confirm this: I get the same error. Here's what I find mysterious: when I am in the debugger, I can call the ASDF:OUTPUT-FILES method on COMPILE-OP and the asdf source file, which seems to be what's yielding the error:
0] (asdf:find-component (asdf:find-system "asdf") "asdf")
#<ASDF:CL-SOURCE-FILE "asdf" "asdf"> 0] (defvar *c* *)
*C* 0] (asdf:output-files (make-instance 'asdf:compile-op) *c*)
(#P"/Users/rpg/.cache/common-lisp/cmu-snapshot-2012-04__20c_unicode_-macosx-x86/Users/rpg/lisp/asdf/asdf.sse2f") T 0]
Faré, is there any chance this is an error that happens when ASDF is replacing itself, i.e., upgrade rather than just build?
When I compile asdf from new (using COMPILE-FILE and LOAD), although I get the unreachable code warnings, ASDF compiles and loads, which suggests a possible upgrade issue.
On Sat, Apr 21, 2012 at 18:47, Robert Goldman rpgoldman@sift.info wrote:
Faré, is there any chance this is an error that happens when ASDF is replacing itself, i.e., upgrade rather than just build?
When I compile asdf from new (using COMPILE-FILE and LOAD), although I get the unreachable code warnings, ASDF compiles and loads, which suggests a possible upgrade issue.
It's very possible that the upgrade doesn't work well on CMUCL. I realize that the test-upgrade target in the Makefile doesn't try loading asdf the asdf way. I probably wrote it before I changed asdf.asd to load-source-op asdf.lisp before it will compile and load it. Sigh. More tests needed.
You can try modifying on #+cmu the behavior for redefined-functions from (ensure-fmakunbound p redefined-functions) to (ensure-unintern p redefined-functions) and see if it works better.
In any case, and even if this workaround works, it still sounds like a bug in CMUCL.
—♯ƒ • François-René ÐVB Rideau •Reflection&Cybernethics• http://fare.tunes.org An anarchist is a man who is careful to always use pedestrian crossings, because he utterly detests talking with policemen. — Georges Brassens
Yeah, I was on the wrong branch. With the master branch, make lisp fails because when cmucl compiles asdf, there are a few notes which I guess are warnings. If you modify compile-asdf.lisp to ignore the warnings (like it already does for ecl and scl), then the tests can proceed. At the end I get:
Interesting. In 2.20.15 (last Monday), I had to ignore similar warnings on SCL. There used to not be warnings. No "WARNING" message shows, only compiler notes. Are they the warnings? Isn't it a bug that they should count as warnings rather than say mere style-warnings? In any case, I've just disabled bork-on-warning on CMUCL as well as SCL.
-#--------------------------------------- Using cmulisp -noinit -batch Ran 39 tests: 39 passing and 0 failing all tests apparently successful -#---------------------------------------
This is with CMU Common Lisp snapshot-2012-04 (20C Unicode) running on OSX 10.6.8. This is, of course, the "official" build from common-lisp.net.
I don't see that snapshot on the download page; but browsing the site by editing existing linked URLs, I find http://common-lisp.net/project/cmucl/downloads/snapshots/2012/04/
And yes, it works for me, too, with the 2012-04 snapshot. Yay! But as reported a few days ago, it was borking for me on vanilla 20c.
Can you link the working snapshot from the download page? That beats offering a failing release as first choice.
Where do you get you cmucl binaries from? What OS are you running on?
I for one always use the unicode tarballs on Linux; AFAIK, rpgoldman always uses the unicode tarballs on MacOS X.
An unidentified already fixed bug sure beats one that's identified but unfixed.
—♯ƒ • François-René ÐVB Rideau •Reflection&Cybernethics• http://fare.tunes.org What's funny with equality is how everyone has a different idea of it. —#f
On 4/21/12 1:13 PM, Faré wrote:
Yeah, I was on the wrong branch. With the master branch, make lisp fails because when cmucl compiles asdf, there are a few notes which I guess are warnings. If you modify compile-asdf.lisp to ignore the warnings (like it already does for ecl and scl), then the tests can proceed. At the end I get:
Interesting. In 2.20.15 (last Monday), I had to ignore similar warnings on SCL. There used to not be warnings. No "WARNING" message shows, only compiler notes. Are they the warnings? Isn't it a bug that they should count as warnings rather than say mere style-warnings?
Hard to say. The notes are about code not reached. Depending on what is not reachable, they could be serious errors or just innocuous notes.
In any case, I've just disabled bork-on-warning on CMUCL as well as SCL.
-#--------------------------------------- Using cmulisp -noinit -batch Ran 39 tests: 39 passing and 0 failing all tests apparently successful -#---------------------------------------
This is with CMU Common Lisp snapshot-2012-04 (20C Unicode) running on OSX 10.6.8. This is, of course, the "official" build from common-lisp.net.
I don't see that snapshot on the download page; but browsing the site by editing existing linked URLs, I find http://common-lisp.net/project/cmucl/downloads/snapshots/2012/04/
And yes, it works for me, too, with the 2012-04 snapshot. Yay! But as reported a few days ago, it was borking for me on vanilla 20c.
Can you link the working snapshot from the download page? That beats offering a failing release as first choice.
As I mentioned already to Robert, I have failed to update the pages on www.cmucl.org and www.cons.org/cmucl. The trac.common-lisp.net/cmucl page is more up-to-date.
Ray
On 4/21/12 1:13 PM, Faré wrote:
And yes, it works for me, too, with the 2012-04 snapshot. Yay! But as reported a few days ago, it was borking for me on vanilla 20c.
-#--------------------------------------- Using /Volumes/share2/src/clnet/cmucl/release-20c/darwin-20c/bin/lisp -noinit -batch Ran 39 tests: 39 passing and 0 failing all tests apparently successful -#---------------------------------------
Don't know what to say. This is on OSX 10.6.8. (I didn't examine the output to see the "apparently" is "truly".)
(All of my tests are with unicode builds. I almost never use the 8-bit builds.)
Ray
-
Douglas Crosher -
Faré -
Raymond Toy -
Robert Goldman