[slime-devel] swank-loader
when using asdf to load swank the file swank-loader.lisp is compilied, however this file contains a symbol in the swank package, which is fine when the file is loaded but is an error when the file is compiled before the rest of swank has been loaded, which is what asdf tries to do when loading the swank system. anyway, attached is a new swank.asd which contains all the dependencies in swank-loader and can be loaded from a non-emacs staret lisp image. since i'm going to assume swank.asd will be used by programs and not by users (via emacs) this asdf doesn't load the user's init file. -- Marco Ring the bells that still can ring. Forget the perfect offering. There is a crack in everything. That's how the light gets in. -Leonard Cohen
Marco Baringer <mb@bese.it> writes:
when using asdf to load swank the file swank-loader.lisp is compilied, however this file contains a symbol in the swank package, which is fine when the file is loaded but is an error when the file is compiled before the rest of swank has been loaded, which is what asdf tries to do when loading the swank system.
anyway, attached is a new swank.asd which contains all the dependencies in swank-loader and can be loaded from a non-emacs staret lisp image.
Is it possible to say that asdf shouldn't compile the loader, e.g., with something like (:file "swank-loader.lisp") ? We shouldn't duplicate all the dependencies in the asd file. Helmut.
On Martedì, gen 20, 2004, at 21:14 Europe/Rome, Helmut Eller wrote:
Is it possible to say that asdf shouldn't compile the loader, e.g., with something like (:file "swank-loader.lisp") ? We shouldn't duplicate all the dependencies in the asd file.
i'm not really sure why, but asdf wants to compile before loading even though it's called load and there already is a compile operation. i'll ask the asdf gods and see what the reasoning is behind this decision. in the mean time: yes that is quite possible and is probably easier. patch forthcoming. but, why is the dependency on :sb-bsd-sockets in the asdf file and not in the loader file? is it really required or not? -- Marco Ring the bells that still can ring. Forget the perfect offering. There is a crack in everything. That's how the light gets in. -Leonard Cohen
On Jan 20, 2004, at 3:14 PM, Helmut Eller wrote:
Marco Baringer <mb@bese.it> writes:
when using asdf to load swank the file swank-loader.lisp is compilied, however this file contains a symbol in the swank package, which is fine when the file is loaded but is an error when the file is compiled before the rest of swank has been loaded, which is what asdf tries to do when loading the swank system.
anyway, attached is a new swank.asd which contains all the dependencies in swank-loader and can be loaded from a non-emacs staret lisp image.
Is it possible to say that asdf shouldn't compile the loader, e.g., with something like (:file "swank-loader.lisp") ? We shouldn't duplicate all the dependencies in the asd file.
Try something along the lines of: (defclass uncompiled-cl-source-file (cl-source-file) ()) (defmethod perform ((o compile-op) (f uncompiled-cl-source-file)) t) -- Brian Mastenbrook bmastenb@cs.indiana.edu http://cs.indiana.edu/~bmastenb/
Brian Mastenbrook <bmastenb@cs.indiana.edu> writes:
On Jan 20, 2004, at 3:14 PM, Helmut Eller wrote:
Marco Baringer <mb@bese.it> writes:
when using asdf to load swank the file swank-loader.lisp is compilied, however this file contains a symbol in the swank package, which is fine when the file is loaded but is an error when the file is compiled before the rest of swank has been loaded, which is what asdf tries to do when loading the swank system.
anyway, attached is a new swank.asd which contains all the dependencies in swank-loader and can be loaded from a non-emacs staret lisp image.
Is it possible to say that asdf shouldn't compile the loader, e.g., with something like (:file "swank-loader.lisp") ? We shouldn't duplicate all the dependencies in the asd file.
Try something along the lines of:
(defclass uncompiled-cl-source-file (cl-source-file) ()) (defmethod perform ((o compile-op) (f uncompiled-cl-source-file)) t)
Not sure, but I think you also want (defmethod output-files ((o compile-op) (f uncompiled-cl-source-file)) (list (component-pathname f))) ? Maybe it works without? Pass. Cheers, Christophe -- http://www-jcsu.jesus.cam.ac.uk/~csr21/ +44 1223 510 299/+44 7729 383 757 (set-pprint-dispatch 'number (lambda (s o) (declare (special b)) (format s b))) (defvar b "~&Just another Lisp hacker~%") (pprint #36rJesusCollegeCambridge)
On Jan 20, 2004, at 3:14 PM, Helmut Eller wrote:
Marco Baringer <mb@bese.it> writes:
when using asdf to load swank the file swank-loader.lisp is compilied, however this file contains a symbol in the swank package, which is fine when the file is loaded but is an error when the file is compiled before the rest of swank has been loaded, which is what asdf tries to do when loading the swank system.
anyway, attached is a new swank.asd which contains all the dependencies in swank-loader and can be loaded from a non-emacs staret lisp image.
Is it possible to say that asdf shouldn't compile the loader, e.g., with something like (:file "swank-loader.lisp") ? We shouldn't duplicate all the dependencies in the asd file.
More specifically, the patch attached in this email fixes that. -- Brian Mastenbrook bmastenb@cs.indiana.edu http://cs.indiana.edu/~bmastenb/
On Martedì, gen 20, 2004, at 22:41 Europe/Rome, Brian Mastenbrook wrote:
More specifically, the patch attached in this email fixes that.<swank.patch>
unfortunetly asdf load-op does not, by default, load the source file but loads the result of (input-files 'load-op component) which, when there is a dependency, returns the output-files of the dependency (in this case the result of (compile-file-pathname "swank-loader.lisp"). what is needed is to get rid of the dependencies on compile-op. so you'd think that i'd be enough to return nil from (component-depends-on compile-op file), ha!. since load-op depends on compile-op _for any component_ the system :swank depends on (compile-op :swank), which means that asdf will attempt to (perform compile-op file) even if this specific file does not directly depend on compile-op. we end up needing to tell asdf 2 things: 1) uncompiled-cl-source-files depend on nothing. 2) compiling an uncompiled-cl-source-file is always "done." the attached patch deals with this issue and a few minor openmcl issues, pick which pieces to apply. -- Marco Ring the bells that still can ring. Forget the perfect offering. There is a crack in everything. That's how the light gets in. -Leonard Cohen
On Mercoledì, gen 21, 2004, at 09:07 Europe/Rome, Marco Baringer wrote:
the attached patch deals with this issue and a few minor openmcl issues, pick which pieces to apply.
except that this solution has 2 problems. 1) (fixable) when swank-loader.lisp changes it isn't reloaded. 2) (not fixable) when swank-openmcl.lisp changes but swank-loader.lisp doesn't it (swank-openmcl) isn't reloaded. as far #1 goes i just noticed that asdf does in fact have a load-source-op, which is exactly what we need: (asdf:defsystem :swank :components ((:file "swank-loader" :in-order-to ((compile-op (load-source-op "swank-loader"))))) :depends-on (#+SBCL :sb-bsd-sockets)) however, this doesn't do anything for #2, and i don't really know what could solve #2 without mentioning all the files in the .asd system def. -- Marco Ring the bells that still can ring. Forget the perfect offering. There is a crack in everything. That's how the light gets in. -Leonard Cohen
"This is the patch that never ends It goes on and on my friends Some people started singing it not knowing what it was and they'll continue singing it forever just because! This is the patch that never ends It goes on and on my friends ..." On Mercoledì, gen 21, 2004, at 09:53 Europe/Rome, Marco Baringer wrote:
(asdf:defsystem :swank :components ((:file "swank-loader" :in-order-to ((compile-op (load-source-op "swank-loader"))))) :depends-on (#+SBCL :sb-bsd-sockets))
un fortunetly this has the effect of compiling swank-loader.lisp. the next time (asdf:oos 'asdf:load-op :swank) is run it will attempt to load "swank-loader.dfsl" without first loading the source. All of this is just so that we can do (swank:warn-unimplemented-features). If we change (swank:warn-unimplemented-features) to (funcall (intern (string '#:swank-warn-unimplemented-features) (string '#:swank))) we can go back to the original swank.asd and not worry about this mess anymore. (although this is all just a work around to a bug in asdf). -- Marco Ring the bells that still can ring. Forget the perfect offering. There is a crack in everything. That's how the light gets in. -Leonard Cohen
Marco Baringer <mb@bese.it> writes:
to
(funcall (intern (string '#:swank-warn-unimplemented-features) (string '#:swank)))
we can go back to the original swank.asd and not worry about this mess anymore. (although this is all just a work around to a bug in asdf).
Ok, done. Helmut.
Marco Baringer <mb@bese.it> writes:
On Mercoledì, gen 21, 2004, at 09:53 Europe/Rome, Marco Baringer wrote:
(asdf:defsystem :swank :components ((:file "swank-loader" :in-order-to ((compile-op (load-source-op "swank-loader"))))) :depends-on (#+SBCL :sb-bsd-sockets))
un fortunetly this has the effect of compiling swank-loader.lisp. the next time (asdf:oos 'asdf:load-op :swank) is run it will attempt to load "swank-loader.dfsl" without first loading the source.
Did you try my suggestion, of customizing asdf:output-files? Other people have managed to load source files. (defclass no-compile-source-file (cl-source-file) ()) (defmethod perform ((o compile-op) (f no-compile-source-file)) t) (defmethod output-files ((o compile-op) (f no-compile-source-file)) (list (component-pathname f)))
we can go back to the original swank.asd and not worry about this mess anymore. (although this is all just a work around to a bug in asdf).
Please report bugs in asdf. One of the more encouraging things at the start of slime development were that problems were reported to people rather than "worked around", down which route leads ilisp and maintenance nightmares. Christophe -- http://www-jcsu.jesus.cam.ac.uk/~csr21/ +44 1223 510 299/+44 7729 383 757 (set-pprint-dispatch 'number (lambda (s o) (declare (special b)) (format s b))) (defvar b "~&Just another Lisp hacker~%") (pprint #36rJesusCollegeCambridge)
On Giovedì, gen 22, 2004, at 09:30 Europe/Rome, Christophe Rhodes wrote:
Did you try my suggestion, of customizing asdf:output-files? Other people have managed to load source files.
(defclass no-compile-source-file (cl-source-file) ()) (defmethod perform ((o compile-op) (f no-compile-source-file)) t) (defmethod output-files ((o compile-op) (f no-compile-source-file)) (list (component-pathname f)))
my reasoning was this: the operation load-source-op should "just work" in this case, redefining those methods is one possible work around to the bug in load-source-op's component-depends-on, while the intern trick is another (imho). an bug report will be sent as soon i can find the time. -- Marco Ring the bells that still can ring. Forget the perfect offering. There is a crack in everything. That's how the light gets in. -Leonard Cohen
Marco Baringer <mb@bese.it> writes:
On Giovedì, gen 22, 2004, at 09:30 Europe/Rome, Christophe Rhodes wrote:
Did you try my suggestion, of customizing asdf:output-files? Other people have managed to load source files.
(defclass no-compile-source-file (cl-source-file) ()) (defmethod perform ((o compile-op) (f no-compile-source-file)) t) (defmethod output-files ((o compile-op) (f no-compile-source-file)) (list (component-pathname f)))
my reasoning was this: the operation load-source-op should "just work" in this case, redefining those methods is one possible work around to the bug in load-source-op's component-depends-on, while the intern trick is another (imho). an bug report will be sent as soon i can find the time.
I think you're confused between dependencies and operations. If I, as the programmer, wish to find out whether my system can be loaded as source, rather than as compiled files, I could do (asdf:oos 'asdf:load-source-op :my-system) If I, as the programmer, wish to ensure that a given file is loaded as source, I would override the default dependencies by specializing the file's class. Not perfect, maybe, but the above is the way to define a Lisp source file that should never be compiled. Cheers, Christophe -- http://www-jcsu.jesus.cam.ac.uk/~csr21/ +44 1223 510 299/+44 7729 383 757 (set-pprint-dispatch 'number (lambda (s o) (declare (special b)) (format s b))) (defvar b "~&Just another Lisp hacker~%") (pprint #36rJesusCollegeCambridge)
Where does one send asdf bug reports? -Alan On Jan 22, 2004, at 3:30 AM, Christophe Rhodes wrote:
Please report bugs in asdf. One of the more encouraging things at the start of slime development were that problems were reported to people rather than "worked around", down which route leads ilisp and maintenance nightmares.
Alan Ruttenberg <alanralanr@comcast.net> writes:
Where does one send asdf bug reports?
cclan-list at lists.sourceforge.net. No guarantees on speed of fixes, but at least that way they'll be archived. Cheers, Christophe -- http://www-jcsu.jesus.cam.ac.uk/~csr21/ +44 1223 510 299/+44 7729 383 757 (set-pprint-dispatch 'number (lambda (s o) (declare (special b)) (format s b))) (defvar b "~&Just another Lisp hacker~%") (pprint #36rJesusCollegeCambridge)
Stupid question: why not just load swank-loader.lisp instead of using an ASDF system?
On Mercoledì, gen 21, 2004, at 12:17 Europe/Rome, Luke Gorrie wrote:
Stupid question: why not just load swank-loader.lisp instead of using an ASDF system?
because i'd like to have an asdf system which :depends-on (:swank) -- Marco Ring the bells that still can ring. Forget the perfect offering. There is a crack in everything. That's how the light gets in. -Leonard Cohen
participants (6)
-
Alan Ruttenberg -
Brian Mastenbrook -
Christophe Rhodes -
Helmut Eller -
Luke Gorrie -
Marco Baringer