If I start with a clean slime directory (no fasls) and attempt to (asdf:oos 'asdf:load-op :swank), I get an error message as the swank package isn't loaded when it tries to access some things in the swank::... package. The following patch fixes thing, although there might be a better approach.
Cyrus
* Cyrus Harmon [2007-09-11 08:37+0200] writes:
If I start with a clean slime directory (no fasls) and attempt to (asdf:oos 'asdf:load-op :swank), I get an error message as the swank package isn't loaded when it tries to access some things in the swank::... package. The following patch fixes thing, although there might be a better approach.
Do you get an error if you load the source? Like so:
(asdf:oos 'asdf:load-source-op :swank)
Helmut.
Helmut Eller heller@common-lisp.net writes:
- Cyrus Harmon [2007-09-11 08:37+0200] writes:
If I start with a clean slime directory (no fasls) and attempt to (asdf:oos 'asdf:load-op :swank), I get an error message as the swank package isn't loaded when it tries to access some things in the swank::... package. The following patch fixes thing, although there might be a better approach.
Do you get an error if you load the source? Like so:
(asdf:oos 'asdf:load-source-op :swank)
I'm not sure if you do or not, though I would imagine that that will work fine; I personally would prefer to be able to compile-file (or 'load-op) swank, because of the functionality that it can add to other projects. I suppose either one could adjust the .asd file for swank to make it load source, or apply a patch like the attached.
Because I'm uncertain how much the base-level swank directory is open to commits from dilettantes like me, I'm asking for review or some kind of affirmation on this patch. (In the case where this patch or something with equivalent functionality is completely vetoed, it would probably be sensible to revoke my cvs permissions explicitly, or at least explain the ground rules for using them).
Cheers,
Christophe
* Christophe Rhodes [2007-09-12 16:47+0200] writes:
+(labels ((swank-find-symbol (keyword &optional (package :swank))
(find-symbol (symbol-name keyword) package))
(swank-set (keyword value)
(set (swank-find-symbol keyword) value))
(swank-symbol-value (keyword)
(symbol-value (swank-find-symbol keyword))))
- (swank-set :*swank-wire-protocol-version* (slime-version-string))
- (swank-set :*load-path*
(append (swank-symbol-value :*load-path*)
(list (contrib-src-dir *source-directory*))))
- (funcall (swank-find-symbol :warn-unimplemented-interfaces :swank-backend))
- (load-site-init-file *source-directory*)
- (load-user-init-file)
- (funcall (swank-find-symbol :run-after-init-hook)))
Because I'm uncertain how much the base-level swank directory is open to commits from dilettantes like me, I'm asking for review or some kind of affirmation on this patch.
I think this kind of code is ugly. It does what eval does, just much more verbose. I would very much prefer a patch for swank.asd to make it load the source.
(In the case where this patch or something with equivalent functionality is completely vetoed, it would probably be sensible to revoke my cvs permissions explicitly, or at least explain the ground rules for using them).
As a SBCL maintainer you can mess around with swank-sbcl.lisp as much as you like. Modifications to the core should primarily be simplifications, i.e. the code should get shorter. For contribs, do whatever you like.
Helmut.
Helmut Eller heller@common-lisp.net writes:
- Christophe Rhodes [2007-09-12 16:47+0200] writes:
- (swank-set :*swank-wire-protocol-version* (slime-version-string))
Because I'm uncertain how much the base-level swank directory is open to commits from dilettantes like me, I'm asking for review or some kind of affirmation on this patch.
I think this kind of code is ugly. It does what eval does, just much more verbose. I would very much prefer a patch for swank.asd to make it load the source.
OK, I attach that.
(In the case where this patch or something with equivalent functionality is completely vetoed, it would probably be sensible to revoke my cvs permissions explicitly, or at least explain the ground rules for using them).
As a SBCL maintainer you can mess around with swank-sbcl.lisp as much as you like. Modifications to the core should primarily be simplifications, i.e. the code should get shorter. For contribs, do whatever you like.
Thanks.
Best,
Christophe
* Christophe Rhodes [2007-09-12 20:22+0200] writes:
I think this kind of code is ugly. It does what eval does, just much more verbose. I would very much prefer a patch for swank.asd to make it load the source.
OK, I attach that.
Committed.