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

[asdf-devel] What are current plans for RMCL?
by Pascal Costanza 12 Apr '12

12 Apr '12

Hi, I'd like to get an idea what the current plans for RMCL are, if any. Since the switch to OS X 10.7, there is no default support for old PowerPC applications on OS X anymore, so RMCL doesn't work anymore, at least not without a major effort. Are there any plans to find a remedy for this situation? Or will RMCL effectively become deprecated? I'm asking for the following reasons: When ASDF was changed from 1.x to 2.x, this caused some problems for RMCL, which I eventually resolved by using Common Lisp's logical pathnames for the systems I maintain (primarily Closer to MOP and ContextL). However, the current maintainers of ASDF have an unjustified very low regard for logical pathnames, which causes a lot of pain - basically, whenever a new version of a Common Lisp implementation comes bundled with a new ASDF version, I have to deal with bugs in ASDF that in one way or the other break my setup with logical pathnames. Since my time is limited and is better served on things other than producing bug reports for ASDF (which is a tool that should be much more stable than it currently is), I decided now that it is better to drop logical pathnames and go for the Unix-like names that the ASDF maintainers seem to strongly prefer. RMCL would be the only Common Lisp implementation that would cause a problem in this regard. So, what's the verdict? Thanks a lot for any hints! Best, Pascal -- Pascal Costanza The views expressed in this email are my own, and not those of my employer.

3 7

[asdf-devel] Latest commit
by Robert Goldman 12 Apr '12

12 Apr '12

I just ran the noupgrade tests (with CMUCL disabled) on Mac OS X, and all passed. I assume that I don't need to bother with Linux testing.... r

1 0

[asdf-devel] testing new ASDF
by Robert Goldman 11 Apr '12

11 Apr '12

All tests pass on Mac OS X until I get to CMUCL 20c, which still fails for reasons that seem unrelated to ACL. These are test-all-noupgrade. Will test with upgrade later. Note that I am still running 10.6, not the latest 10.7. It would probably be a Good Thing to find someone who will run the tests on 10.7. For the moment, I'm purging CMUCL from my test suite. Cheers, r

1 0

[asdf-devel] LOCALAPPDATA vs APPDATA
by Faré 01 Apr '12

01 Apr '12

On Sun, Apr 1, 2012 at 14:35, Anton Vodonosov <avodonosov(a)yandex.ru> wrote: > 01.04.2012, 22:19, "Faré" <fahree(a)gmail.com>: >>> 15.01.2012, 22:46, "Faré" <fahree(a)gmail.com>: >>>> I'm a bit surprised that LOCALAPPDATA includes Roaming\ instead of >>>> Local\ but then again I don't understand Windows paths very well. >> >>> If you are intrested, I just noticed: CLISP uses Roaming, while SBCL and CCL use Local. >>> (noticed with the ASDF version from the recent Quicklisp) >> >> Wow. Is that on the *same* machine? >> Because on all implementations but LispWorks, >> it's taken from the LOCALAPPDATA environment variable, >> and that shouldn't vary from one program to the other. > > Yes, same machine. > > I suppose you mean APPDATA variable, because it is mentioned in asdf.lisp, > but LOCALAPPDATA isn't. Anyway, the enviroment variable value is equal > in all the 3 lisps > ASDF has favoring LOCALAPPDATA over APPDATA since 2.015.6. But I see quicklisp is still using 2.014.6. Now, considering the ECL bug in 2.20 (aka 2.019.9), I recommend that ECL and/or Quicklisp should upgrade to 2.019.8 (if they upgrade), until 2.21 is ready (which it won't be until we fix those 20 systems that depend on something else than UTF-8). —♯ƒ • François-René ÐVB Rideau •Reflection&Cybernethics• http://fare.tunes.org (map()(lambda(n l)(princ(subseq (format nil "(~{~A~^ ~})~%"(let(r)(do-external-symbols(x :cl)(push x r))(sort r #'string< :key #'string))) n (+ n l)))(finish-output))'(875 949 8 6010 4863 371 11)'(4 3 5 5 3 2 2))

1 0

[asdf-devel] the same (asdf::implementation-identifier) for byte-compiler and lisp-to-C-compiler of ECL
by Anton Vodonosov 01 Apr '12

01 Apr '12

ECL offers two compiles: byte-compiler and lisp-to-C compiler. They produce incompatible .fasls (asdf::implementation-identifier) does not accounts the difference and returns the same value - ecl-11.1.1-win-x86. As implementation-identifier is used to compute output files location, the same file location is used to store .fasls of both ECL compilers (in my case C:\Users\anton\AppData\Roaming\common-lisp\cache\ecl-11.1.1-win-x86\). In result, if some files are compiled with byte-compiler, and latter user tries the lisp-to-C-compiler, he has errors during .fasl load.

2 5

[asdf-devel] CMUCL error with 20c
by Robert Goldman 31 Mar '12

31 Mar '12

Sorry --- took the wrong bit out of the screen --- the backtrace hid the key stuff. Looks like something is badly wrong with CMUCL for me. Anyone else out there able to test with 20c for Mac OS X? ; Python version 1.1, VM version Intel x86/sse2 on 2012-03-28 12:37:57. ; Compiling: /Users/rpg/lisp/asdf/test/test.lisp 2011-10-21 16:34:09 Type-error in KERNEL::OBJECT-NOT-TYPE-ERROR-HANDLER: -364 is not of type (OR (MOD 536870911) NULL) Break [Condition of type SIMPLE-CONDITION] Restarts: 0: [CONTINUE] Return from BREAK. 1: [RETRY ] Retry compiling #<CL-SOURCE-FILE "test-around-compile" "test">. 2: [ACCEPT ] Continue, treating compiling #<CL-SOURCE-FILE "test-around-compile" "test"> as having been successful. 3: Return NIL from load of "test-around-compile.script". 4: [ABORT ] Skip remaining initializations. De

5 5

[asdf-devel] CMUCL and unicode...
by Robert Goldman 31 Mar '12

31 Mar '12

Looks like there are unicode and non-unicode versions of CMUCL... Should we be checking for this when we set *utf-8-external-format* ? We just set :utf-8 for CMUCL without looking. cheers, r

2 1

[asdf-devel] Test results on Mac OS X
by Robert Goldman 30 Mar '12

30 Mar '12

As before, all these pass: ccl clisp sbcl ecl abcl allegro allegromodern cmucl fails on test-around-compile.script no idea why.... cheers, r

1 0

[asdf-devel] Running the tests: failures: ACL (alisp) and CMUCL
by Robert Goldman 28 Mar '12

28 Mar '12

ACL alisp: ACL on MacOS X (8.2, 64-bit, updated yesterday) failed: ;;; Writing fasl file /Users/rpg/lisp/asdf/tmp/fasls/alisp/asdf-tmp.fasl ;;; Fasl write complete Testsuite failed: ASDF compiled with warnings ; Exiting Compilation FAILED Looking upstream: Warning: Can you please fix ASDF to not emit style-warnings? Got a EXCL:COMPILER-UNREACHABLE-CODE-WARNING: cond clause (T :DEFAULT) is unreachable CMUCL: CMUCL 20c Using /usr/local/bin/cmucl -noinit -batch, wild-module.script passed -#--------------------------------------- Using /usr/local/bin/cmucl -noinit -batch Ran 38 tests: 37 passing and 1 failing failing test(s): test-around-compile.script

2 3

[asdf-devel] Operation inheritance usage
by Dmitriy Ivanov 23 Mar '12

23 Mar '12

Hello folks, I would like to found out whether subclassing operations is really practical. The operation hierarchy built-in within the asdf.lisp source file is actually of two-level depth. Has anybody ever defined an operation subclass and specialize methods on it? -- Sincerely, Dmitriy Ivanov lisp.ystok.ru

3 7