* Marco Baringer 87ir17m6mo.fsf@arsenic.bese.it : Wrote on Sat, 02 Feb 2008 21:43:27 +0100:
| It can happen (though i admit it's a rare occurance) that you build an | image with swank, update swank and then try to load swank into the | existing image. hard to debug/understand errors ensue, this simple | patch protects against that. | | Index: swank-loader.lisp [...] | +(eval-when (:compile-toplevel :load-toplevel :execute) | + (when (find-package :swank) | + (delete-package :swank) | + (delete-package :swank-io-package) | + (delete-package :swank-loader) | + (delete-package :swank-backend))) | + | (cl:defpackage :swank-loader | (:use :cl) | (:export :load-swank
This is a bad idea. In general, packages should not be automatically deleted[1], and I would prefer if package deletion was provided in a function called reload-swank-loader or something that the user can call when he knows what is happening
Secondly, this breaks a common[2] strategy to put swank fasl files in a different location: For example in my lisp's init file I may have have
(eval-when (:load-toplevel :execute :compile-toplevel) (unless (find-package :swank-loader) (make-package :swank-loader)))
(defparameter swank-loader::*fasl-directory* "/user11/madhu/build/swank/")
(load "/path/toswank-loader.lisp")
- To override the defvar in swank-loader.lisp
The logic propsed in the patch would break this usage completely by deleting the package the variable belongs to -- Madhu
[1] I hear some implementations may leak objects in deleted packages [2] By common, I mean I use this idiom and have seen others use this to customize defvars.