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.
On Sun, Jan 15, 2012 at 03:54, Anton Vodonosov avodonosov@yandex.ru wrote:
ECL offers two compiles: byte-compiler and lisp-to-C compiler.
They produce incompatible .fasls
At least in a recent ECL (I tested with a git checkout from November 2011), they also should be using different extensions, .fas for the usual compiler, and .fasc for the bytecode compiler. Is there somehow a clash on windows because these share the same first three characters?
(asdf::implementation-identifier) does not accounts the difference and returns the same value - ecl-11.1.1-win-x86.
I could include a bytecode indicator in there, but you'd have to explicitly asdf::clear-output-translations when you switch compiler.
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).
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 think that's wrong, please suggest a better heuristic for choosing a path to the cache.
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.
Shouldn't the different pathname type prevent such an issue? Are there more subtle issues due to e.g. different API in generated FFI .so files?
I'll withhold the releasing of ASDF 2.20 until this issue is resolved.
Regards,
—♯ƒ • François-René ÐVB Rideau •Reflection&Cybernethics• http://fare.tunes.org Judge and party — the ultimate nature of a monopoly government.
15.01.2012, 22:46, "Faré" fahree@gmail.com:
On Sun, Jan 15, 2012 at 03:54, Anton Vodonosov avodonosov@yandex.ru wrote:
ECL offers two compiles: byte-compiler and lisp-to-C compiler.
They produce incompatible .fasls
At least in a recent ECL (I tested with a git checkout from November 2011), they also should be using different extensions, .fas for the usual compiler, and .fasc for the bytecode compiler. Is there somehow a clash on windows because these share the same first three characters?
It' my mistake. I just misinterpreted other failure, and when noticed the implementation-identifier is the same decided (mistakenly) it is the cause.
Sorry for disturbing you.
(in my case C:\Users\anton\AppData\Roaming\common-lisp\cache\ecl-11.1.1-win-x86).
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 think that's wrong, please suggest a better heuristic for choosing a path to the cache.
For me Roaming is OK.
Best regards, - Anton
15.01.2012, 22:46, "Faré" fahree@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)
15.01.2012, 22:46, "Faré" fahree@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.
On Sun, Apr 1, 2012 at 13:46, Anton Vodonosov avodonosov@yandex.ru wrote:
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.
—♯ƒ • François-René ÐVB Rideau •Reflection&Cybernethics• http://fare.tunes.org "When buying and selling are controlled by legislation, the first things to be bought and sold are legislators." — P.J. O'Rourke
01.04.2012, 22:19, "Faré" fahree@gmail.com:
15.01.2012, 22:46, "Faré" fahree@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.
On Sun, Apr 1, 2012 at 13:46, Anton Vodonosov avodonosov@yandex.ru wrote:
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 --------------------------- clisp: [1]> (asdf:getenv "APPDATA") "C:\Users\anton\AppData\Roaming" [2]> (asdf::implementation-identifier) "clisp-2.49-win"
------------------ Welcome to Clozure Common Lisp Version 1.7-r14925M (WindowsX8664)! ? (asdf:getenv "APPDATA") "C:\Users\anton\AppData\Roaming" ? (asdf::implementation-identifier) "ccl-1.7-f95-win-x64"
----------------- This is SBCL 1.0.54.84.mswinmt.1137-215bdc8, an implementation of ... * (asdf:getenv "APPDATA")
"C:\Users\anton\AppData\Roaming" * (asdf::implementation-identifier)
"sbcl-1.0.54.84.mswinmt.1137-215bdc8-win-x64"