I believe for many this is concealed by having their lisp implementation able to call "compile-file" and load the affected modules in at runtime - the contribs it determines as missing (right or wrong) will compile the elements it percieves as missing - my implementation (commercial) does not allow this; but it then highlights an inconsistency in the implementation.
This may explain it:
I configure slime in my .emacs as so: (slime-setup '(slime-repl slime-fancy slime-banner slime-asdf slime-indentation))
Now, due to my implementation, I want my app to include all of the relevant contribs. To achieve this, I needed to do 2 things.
1: In Swank-loader.lisp, add swank-indentation to defvar *contribs*
2: Address another problem in Swank.lisp. . .
This is where the compile-file was being decided on and triggered. Basically, despite being present, this test was determining that ASDF and Indentation have to be reincluded. ASDF and Indentation were being passed in as as :swank-indentation and :swank-asdf, then looking for them in *modules* via a string search. However, the string for asdf was "ASDF" not "SWANK-ASDF", and nothing for INDENTATION is present at all despite being loaded.
As a temporary hack I make the check avoid reload for either of these modules; but that's obviously not the solution. And I'm not even sure what's populating *modules* - but there is an emission or an inconsistency.
* Matt Lamari [2010-02-13 16:43+0100] writes:
I believe for many this is concealed by having their lisp implementation able to call "compile-file" and load the affected modules in at runtime
- the contribs it determines as missing (right or wrong) will compile
the elements it percieves as missing - my implementation (commercial) does not allow this; but it then highlights an inconsistency in the implementation.
Your implemenation doesn't allow (load (compile-file ...)) ? I've never heard of such an implemenation. How do you compile/load Swank in the first place?
This may explain it:
I configure slime in my .emacs as so: (slime-setup '(slime-repl slime-fancy slime-banner slime-asdf slime-indentation))
Now, due to my implementation, I want my app to include all of the relevant contribs. To achieve this, I needed to do 2 things.
1: In Swank-loader.lisp, add swank-indentation to defvar *contribs*
That will compile it if the the source is newer the the fasl file.
2: Address another problem in Swank.lisp. . .
Swank uses REQUIRE in this case and the filename is determined by calling the hook function swank:*find-module*. You could customize that or perhaps swank:*load-path*.
Whether REQUIRE invokes COMPILE-file before loading the file is beyound our control.
This is where the compile-file was being decided on and triggered. Basically, despite being present, this test was determining that ASDF and Indentation have to be reincluded. ASDF and Indentation were being passed in as as :swank-indentation and :swank-asdf, then looking for them in *modules* via a string search. However, the string for asdf was "ASDF" not "SWANK-ASDF", and nothing for INDENTATION is present at all despite being loaded.
SWANK-ASDF depends on ASDF that would explain it. swank-indentation.lisp is missing the corresponing PROVIDE, that's a bug.
Helmut
Lispworks. It contains compile-file; but the delivered EXEs it produces do not (this is by design). Slime has to connect to a delivered EXE in my situation.
It seems *intended* to compile if the source is newer than the FASL file. But due to the problem I see, it is rebuilding elements that I know have already been compiled in from latest.
The ability to use compile-file at runtime would be sufficient to mask the problem. Indeed, the logic I mentioned could be broken completely (to recompile everything every time) and most users wouldn't notice it.
Helmut Eller wrote:
- Matt Lamari [2010-02-13 16:43+0100] writes:
I believe for many this is concealed by having their lisp implementation able to call "compile-file" and load the affected modules in at runtime
- the contribs it determines as missing (right or wrong) will compile
the elements it percieves as missing - my implementation (commercial) does not allow this; but it then highlights an inconsistency in the implementation.
Your implemenation doesn't allow (load (compile-file ...)) ? I've never heard of such an implemenation. How do you compile/load Swank in the first place?
This may explain it:
I configure slime in my .emacs as so: (slime-setup '(slime-repl slime-fancy slime-banner slime-asdf slime-indentation))
Now, due to my implementation, I want my app to include all of the relevant contribs. To achieve this, I needed to do 2 things.
1: In Swank-loader.lisp, add swank-indentation to defvar *contribs*
That will compile it if the the source is newer the the fasl file.
2: Address another problem in Swank.lisp. . .
Swank uses REQUIRE in this case and the filename is determined by calling the hook function swank:*find-module*. You could customize that or perhaps swank:*load-path*.
Whether REQUIRE invokes COMPILE-file before loading the file is beyound our control.
This is where the compile-file was being decided on and triggered. Basically, despite being present, this test was determining that ASDF and Indentation have to be reincluded. ASDF and Indentation were being passed in as as :swank-indentation and :swank-asdf, then looking for them in *modules* via a string search. However, the string for asdf was "ASDF" not "SWANK-ASDF", and nothing for INDENTATION is present at all despite being loaded.
SWANK-ASDF depends on ASDF that would explain it. swank-indentation.lisp is missing the corresponing PROVIDE, that's a bug.
Helmut
slime-devel site list slime-devel@common-lisp.net http://common-lisp.net/mailman/listinfo/slime-devel
* Matt Lamari [2010-02-13 18:20+0100] writes:
Lispworks. It contains compile-file; but the delivered EXEs it produces do not (this is by design). Slime has to connect to a delivered EXE in my situation.
It seems *intended* to compile if the source is newer than the FASL file. But due to the problem I see, it is rebuilding elements that I know have already been compiled in from latest.
The ability to use compile-file at runtime would be sufficient to mask the problem. Indeed, the logic I mentioned could be broken completely (to recompile everything every time) and most users wouldn't notice it.
The loader (swank-loader.lisp) may call compile-file if the source is newer or the fasl file doesn't exist. I'm pretty sure that that part isn't broken, otherwise SBCL would start noticeably slower.
swank-require doesn't call compile-file. It loads the source if the fasl file doesn't exist. (I think that we can exclude the possibility that cl:require calls compile-file for Lispworks.)
Maybe some file/directory names aren't set correctly for the EXE version, but it's hard to say without a more concrete error description.
Helmut
On the call stack
compile-file swank-require
Undefined function COMPILE-FILE called with arguments (#P"C:/Users/Matthew Lamari/.slime/fasl/2010-02-01/lispworks-6.0.0-mswindows-x86/contrib/swank-indentation-fu" :ONLY-PATH T). [Condition of type UNDEFINED-FUNCTION]
Restarts: 0: [RETRY] Try invoking COMPILE-FILE again. 1: [NIL] Return some values from the call to COMPILE-FILE. 2: [USE-VALUE] Try invoking something other than COMPILE-FILE with the same arguments. 3: [STORE-VALUE] Set the symbol-function of COMPILE-FILE to another function. 4: [ABORT] Return to SLIME's top level. 5: [ABORT] Quit process.
Backtrace: 0: CONDITIONS::CONDITIONS-ERROR (:INVISIBLEP T #<UNDEFINED-FUNCTION 200F059B> NIL) 1: ERROR (#<UNDEFINED-FUNCTION 200F059B> &REST NIL) 2: CONDITIONS::UNDEFINED-FUNCTION-FUNCTION-INTERNAL-COMMON (:INVISIBLEP T COMPILE-FILE (#P"C:/Users/Matthew Lamari/.slime/fasl/2010-02-01/lispworks-6.0.0-mswindows-x86/contrib/swank-indentation-fu" :ONLY.. 3: COMPILE-FILE-PATHNAME (#P"C:/Users/Matthew Lamari/.slime/fasl/2010-02-01/lispworks-6.0.0-mswindows-x86/contrib/swank-indentation-fu" &REST NIL &KEY NIL "<&ALLOW-OTHER-KEYS>") 4: SWANK::MODULE-CANDITATES ("swank-indentation-fu" #P"C:/Users/Matthew Lamari/.slime/fasl/2010-02-01/lispworks-6.0.0-mswindows-x86/contrib/") 5: (SUBFUNCTION 1 SWANK::FIND-MODULE) (#P"C:/Users/Matthew Lamari/.slime/fasl/2010-02-01/lispworks-6.0.0-mswindows-x86/contrib/") 6: SYSTEM::EVERY-OR-SOME (#<Closure 1 subfunction of SWANK::FIND-MODULE 33FEA12> (#P"C:/Users/Matthew Lamari/.slime/fasl/2010-02-01/lispworks-6.0.0-mswindows-x86/contrib/" #P"c:/prog/lisp/libraries/slime.. 7: SOME (#<Closure 1 subfunction of SWANK::FIND-MODULE 33FEA12> (#P"C:/Users/Matthew Lamari/.slime/fasl/2010-02-01/lispworks-6.0.0-mswindows-x86/contrib/" #P"c:/prog/lisp/libraries/slime/contrib/") &REST.. 8: SWANK::FIND-MODULE (:SWANK-INDENTATION-FU) 9: SWANK::MODULE-FILENAME (:SWANK-INDENTATION-FU) 10: SWANK:SWANK-REQUIRE ((:SWANK-INDENTATION-FU :SWANK-ASDF) &OPTIONAL NIL) 11: SYSTEM::%INVOKE NIL 12: SYSTEM::%EVAL ((SWANK:SWANK-REQUIRE (QUOTE (:SWANK-INDENTATION-FU :SWANK-ASDF)))) 13: EVAL ((SWANK:SWANK-REQUIRE (QUOTE (:SWANK-INDENTATION-FU :SWANK-ASDF)))) 14: SWANK::EVAL-FOR-EMACS ((SWANK:SWANK-REQUIRE (QUOTE (:SWANK-INDENTATION-FU :SWANK-ASDF))) "COMMON-LISP-USER" 2) 15: (SUBFUNCTION 1 SWANK::SPAWN-WORKER-THREAD) NIL 16: (SUBFUNCTION 1 (TOP-LEVEL-FORM 44)) (#<Function SWANK:SWANK-DEBUGGER-HOOK 229D98E2> #<Function 1 subfunction of SWANK::SPAWN-WORKER-THREAD 22A4D432>) 17: SWANK::CALL-WITH-BINDINGS (NIL #<Closure 3 subfunction of SWANK::CALL-WITH-CONNECTION 200ACDD2>) 18: SWANK::CALL-WITH-CONNECTION (#<SWANK::CONNECTION 22EA702F> #<Function 1 subfunction of SWANK::SPAWN-WORKER-THREAD 22A4D432>) 19: SWANK::CALL-WITH-BINDINGS (NIL #<Closure 1 subfunction of SWANK::SPAWN-WORKER-THREAD 200AD28A>) 20: MP::PROCESS-SG-FUNCTION (0 NIL NIL) 21: SYSTEM::%%FIRST-CALL-TO-STACK NIL
Helmut Eller wrote:
- Matt Lamari [2010-02-13 18:20+0100] writes:
Lispworks. It contains compile-file; but the delivered EXEs it produces do not (this is by design). Slime has to connect to a delivered EXE in my situation.
It seems *intended* to compile if the source is newer than the FASL file. But due to the problem I see, it is rebuilding elements that I know have already been compiled in from latest.
The ability to use compile-file at runtime would be sufficient to mask the problem. Indeed, the logic I mentioned could be broken completely (to recompile everything every time) and most users wouldn't notice it.
The loader (swank-loader.lisp) may call compile-file if the source is newer or the fasl file doesn't exist. I'm pretty sure that that part isn't broken, otherwise SBCL would start noticeably slower.
swank-require doesn't call compile-file. It loads the source if the fasl file doesn't exist. (I think that we can exclude the possibility that cl:require calls compile-file for Lispworks.)
Maybe some file/directory names aren't set correctly for the EXE version, but it's hard to say without a more concrete error description.
Helmut
slime-devel site list slime-devel@common-lisp.net http://common-lisp.net/mailman/listinfo/slime-devel
* Matt Lamari [2010-02-13 19:32+0100] writes:
On the call stack
compile-file swank-require
Undefined function COMPILE-FILE called with arguments (#P"C:/Users/Matthew Lamari/.slime/fasl/2010-02-01/lispworks-6.0.0-mswindows-x86/contrib/swank-indentation-fu" :ONLY-PATH T). [Condition of type UNDEFINED-FUNCTION]
Restarts: 0: [RETRY] Try invoking COMPILE-FILE again. 1: [NIL] Return some values from the call to COMPILE-FILE. 2: [USE-VALUE] Try invoking something other than COMPILE-FILE with the same arguments. 3: [STORE-VALUE] Set the symbol-function of COMPILE-FILE to another function. 4: [ABORT] Return to SLIME's top level. 5: [ABORT] Quit process.
Backtrace: 0: CONDITIONS::CONDITIONS-ERROR (:INVISIBLEP T #<UNDEFINED-FUNCTION 200F059B> NIL) 1: ERROR (#<UNDEFINED-FUNCTION 200F059B> &REST NIL) 2: CONDITIONS::UNDEFINED-FUNCTION-FUNCTION-INTERNAL-COMMON (:INVISIBLEP T COMPILE-FILE (#P"C:/Users/Matthew Lamari/.slime/fasl/2010-02-01/lispworks-6.0.0-mswindows-x86/contrib/swank-indentation-fu" :ONLY.. 3: COMPILE-FILE-PATHNAME (#P"C:/Users/Matthew Lamari/.slime/fasl/2010-02-01/lispworks-6.0.0-mswindows-x86/contrib/swank-indentation-fu" &REST NIL &KEY NIL "<&ALLOW-OTHER-KEYS>") 4: SWANK::MODULE-CANDITATES ("swank-indentation-fu" #P"C:/Users/Matthew Lamari/.slime/fasl/2010-02-01/lispworks-6.0.0-mswindows-x86/contrib/")
This looks like COMPILE-FILE-PATHNAME is calling (COMPILE-FILE ... :ONLY-PATH t).
I.e. the delivered app not only misses COMPILE-FILE but also that COMPILE-FILE-PATHNAME. I guess the Lispworks people didn't intend that.
You can work around that problem by customizing swank:*find-module*. Set it to a function which doesn't need COMPILE-FILE-PATHNAME.
Helmut
-
Helmut Eller -
Matt Lamari