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

[asdf-devel] source file encoding
by Anton Vodonosov 16 Apr '12

16 Apr '12

Hello. How to specify source files encoding in ASD2? I.e. what value to pass to the :external-format argument of the compile-file? In the old ASDF I did it by (let ((asdf:*compile-file-external-format* #+:clisp charset:cp1251 #+:sbcl :cp1251)) (asdf:operate 'asdf:load-op :mysystem)) But today the variable asdf:*compile-file-external-format* does not exist. Also, it of course would be better to specify the encoding in the .asd file (the system author knows the files encoding, and should care about this, but not the system user). Could you advise me how to do it? Best regards, - Anton

13 61

[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

[asdf-devel] Quick note on the tests after addition of external format patch...
by Robert Goldman 22 Mar '12

22 Mar '12

The tests failed for me on ECL on Mac OSX. Out of memory error crash in test-retry-loading-component-1.script ;;; ** Unknown or unsupported external format: UTF-8 Sorry, I'm having a heck of a busy week; don't have as much time to focus on this as I would like. best, R

1 0

[asdf-devel] always load/compile from sources.
by Pascal J. Bourguignon 16 Mar '12

16 Mar '12

Hi! I have a file swank-stuff.lisp that uses swank if available, with forms such as: #+swank (in-package :swank) #+swank … It contains also definitions that are alway available. If I define it as: (:file "swank-stuff" :depends-on ("other-stuff")) and compile it when I have swank, it produces a .fasl that contains a toplevel (in-pacakge :swank). Therefore when I load the system in an image without swank, it produces this error: ; Loading "com.informatimago.lse.unix-cli" . > Error: There is no package named "SWANK" . > While executing: ccl::set-package, in process listener(1). I tried to define it as: (:file "swank-stuff" :depends-on ("other-stuff") :in-order-to ((asdf:load-op (asdf:compile-op "swank-stuff")))) but it still doesn't work. Is there a way to make it so that swank-stuff is always loaded/compiled from source, instead of from the .fasl file? -- __Pascal Bourguignon__ http://www.informatimago.com/ A bad day in () is better than a good day in {}.

3 5

[asdf-devel] Local package renaming at compile time
by Faré 05 Mar '12

05 Mar '12

It's possible to build CL software with local package renamings using ASDF 2.018 or later, and I have proof: http://common-lisp.net/gitweb?p=users/frideau/package-renaming.git However it (at least currently) requires quite some groundwork if you want to do more than add a non-clashing nickname to an existing package. Below my sigblock is the current relevant section of the README. —♯ƒ • François-René ÐVB Rideau •Reflection&Cybernethics• http://fare.tunes.org The naturalistic fallacy: "if it's natural, it's good." The anti-naturalistic fallacy: "if it's natural, it's bad." The a-naturalistic fallacy: "nature has no relationship to good and bad." with-effective-package-renamings and call-with-effective-package-renamings are pretty low-level primitives that let you do what you need, but require you to do a lot of the groundwork. First, an important constraint to understand about building CL software. By intentional design, ASDF only has an :around-compile hook, but no :around-load hook around load, or :around-build hook around both compile and load; indeed, some implementations that rely on linking, such as ECL or GCL, might not even allow any kind of useful hook around loading, and some things one might want to do with fasls (such as linking or concatenating them together into a big fasl) might preclude any such hook. Therefore, whatever renamings you do at compile-time will NOT be done available at load-time. When the fasl is loaded, only the non-renamed names are available, and symbols, stored with the principal name of their package at compile-time, will be resolved against the set of packages at load-time. This imposes this important constraint on renamings that are admissible in ASDF's :around-compile hook: THE (PRINCIPAL) NAME OF A PACKAGE AS RENAMED AT COMPILE-TIME *MUST* BE ONE OF THE NAMES OF THAT PACKAGE AT LOAD-TIME. For instance, if your target package is COM.FOO.BLAH and has nicknames CFBLAH and BLAH, then during your rename, the main name of the package must be one of COM.FOO.BLAH, CFBLAH or BLAH, or the symbols will fail to resolve properly at load-time. You can add as many new local nicknames as you want, and use them locally in your files, you cannot delete all the original names, and you must use the original names in any operation that will happen at runtime or load-time, such as defpackage or find-symbol. Now, if you want to use package-renaming to locally override a package A with another B, it is still possible; but you have to use further tricks. The trick is to somehow ADD a new unique non-clashing nickname to each of the packages that are involved in a clash, at some point after they are defined and before they are used by your code. For instance, give A the nickname A.at.runtime and B the nickname B.at.runtime. Then, you can make B.at.runtime the principal name of whatever renaming you make that targets B, even with local nickname A, whereas A is previously renamed away to A.at.runtime. With this constraint in mind, a typical way to use package-renaming would be to use the following in your my-system.asd file: (defsystem my-system :depends-on (:my-system-meta) :around-compile "my-system-meta::call-with-renamings" ...) And in B-renaming.asd: (defsystem my-system-meta :depends-on (:package-renaming) :components ((:file "renamings"))) And in renamings.lisp: (defpackage :my-system-meta (:use :cl :package-renaming)) (effect-package-renaming '((:A (:A :A.regular.nick :A.at.runtime)) (:B (:B :B.regular.nick :B.at.runtime)))) (defun with-renamings (thunk) (call-with-package-renamings '((:A :A.at.runtime) (:B :B.at.runtime :A :B.other.nick)) thunk)) That's not all that simple, but at least it's possible. If you implement an easier all-in-one solution based on this, I'll happily merge it into this package-renaming.

1 0