[slime-devel] Daily ChangeLog diff
Index: slime/ChangeLog diff -u slime/ChangeLog:1.2036 slime/ChangeLog:1.2042 --- slime/ChangeLog:1.2036 Tue Mar 16 12:20:07 2010 +++ slime/ChangeLog Thu Mar 18 14:24:25 2010 @@ -1,3 +1,84 @@ +2010-03-18 Tobias C. Rittweiler <tcr@freebits.de> + + Remove attach-gdb restart. Instead add SLDB shortcut `A'. + + * slime.el (slime-dispatch-event): Remove :gdb-attach. + (slime-attach-gdb): Changed API. Takes connection not pid now and + lightweight &optional arg. If not lightweight, get the default gdb + config from the inferior Lisp. + (sldb-break-with-system-debugger): New command, bound to `A' in + sldb. Called this way to mimick + `sldb-break-with-default-debugger', and because it may make sense + to go beyond gdb in future, e.g. to invoke the Java Debugger for + ABCL. + + * swank.lisp (call-with-gdb-restart, with-gdb-restart): Removed. + (with-top-level-restart): Remove use of with-gdb-restart. + (make-connection, start-server, create-server, setup-server): + Remove inferior-lisp flag again. Not needed anymore. + +2010-03-18 Tobias C. Rittweiler <tcr@freebits.de> + + Add M-x slime-attach-gdb as an interactive function. + + The ATTACH-GDB restart is nice because it's convenient and the + backends can specify customized gdb configuration. + + Sometimes, if the Lisp is too screwed up, going over a restart + involving the SWANK middle layer may not be possible. For that, a + manual M-x slime-attach-gdb may come in handy. + + * slime.el (slime-read-connection): New helper. + (slime-attach-gdb): Use it. Make it an interactive function. + +2010-03-18 Tobias C. Rittweiler <tcr@freebits.de> + + * swank.lisp (call-with-gdb-restart): Forgot to remove trailing T. + +2010-03-18 Tobias C. Rittweiler <tcr@freebits.de> + + * swank.lisp (open-dedicated-output-stream): Forgot to rename + accept-authenticated-connection to accept-authenticated-client + here. + +2010-03-18 Tobias C. Rittweiler <tcr@freebits.de> + + Add an ATTACH-GDB restart to SLDB. + + * swank.lisp (call-with-gdb-restart): New. Sends the new :gdb-attach event to Emacs. + (with-gdb-restart): Sugar. + (with-top-level-restart): Also expand to with-gdb-restart. + (dispatch-event): Add :gdb-attach event. + + * swank-backend.lisp (gdb-initial-commands): New interface + function so backends can customize how gdb needs to be configured + for their implementation. + + * swank-ecl.lisp (gdb-initial-commands): Implement. + + * slime.el (slime-dispatch-event): Add clause for :gdb-attach. + (slime-attach-gdb): New. + +2010-03-18 Tobias C. Rittweiler <tcr@freebits.de> + + * swank.lisp (connection): Add socket slot, make socket-io slot + not be required to be filled in during object creation. Add + inferior-lisp slot so we can know whether a connection belongs to + a superior Emacs process. Need for that will come in following + commit. + (make-connection): Our constructor. + (create-connection): Removed; not needed anymore. + (finish-connection-setup): Function to fill socket-io slot. + (start-server): Results in inferior-lisp slot being T. + (create-server): Results in inferior-lisp slot being NIL. + (setup-server): Adapted accordingly. Construct connection early so + we do not have to pass down all the meta information explicitly. + (serve-connection): Adapted accordingly. + (accept-authenticated-client): Renamed from + accept-authenticated-connection. + (dispatch-event): Get rid of unused :%apply and :end-of-stream + events. + 2010-03-16 Tobias C. Rittweiler <tcr@freebits.de> * swank-ecl.lisp (source-location): Also return EXT::FOO as
Index: slime/ChangeLog diff -u slime/ChangeLog:1.2036 slime/ChangeLog:1.2042 --- slime/ChangeLog:1.2036 Tue Mar 16 12:20:07 2010 +++ slime/ChangeLog Thu Mar 18 14:24:25 2010
...
+ +2010-03-18 Tobias C. Rittweiler <tcr@freebits.de> + + Add an ATTACH-GDB restart to SLDB. +
...
+ + * slime.el (slime-dispatch-event): Add clause for :gdb-attach. + (slime-attach-gdb): New. +
The new function `slime-attach-gdb' references the function `gud-gdb' and the variable `gud-comint-buffer', which are defined in Emacs's gud.el, but does not include (require 'gud) Was this omission intentional?
Mark Harig <idirectscm@aim.com> writes:
Index: slime/ChangeLog diff -u slime/ChangeLog:1.2036 slime/ChangeLog:1.2042 --- slime/ChangeLog:1.2036 Tue Mar 16 12:20:07 2010 +++ slime/ChangeLog Thu Mar 18 14:24:25 2010
...
+ +2010-03-18 Tobias C. Rittweiler <tcr@freebits.de> + + Add an ATTACH-GDB restart to SLDB. +
...
+ + * slime.el (slime-dispatch-event): Add clause for :gdb-attach. + (slime-attach-gdb): New. +
The new function `slime-attach-gdb' references the function `gud-gdb' and the variable `gud-comint-buffer', which are defined in Emacs's gud.el, but does not include
(require 'gud)
Was this omission intentional?
Under what circumstances is it necessary to explicitly require packages? Won't the autoload magic do that automatically? -T.
+ * slime.el (slime-dispatch-event): Add clause for :gdb-attach. + (slime-attach-gdb): New. +
The new function `slime-attach-gdb' references the function
`gud-gdb' and the variable `gud-comint-buffer', which are defined in Emacs's gud.el, but does not include
(require 'gud)
Was this omission intentional?
Under what circumstances is it necessary to explicitly require packages?
Here is the first sentence from the "Autoload" section of the Emacs Lisp manual: "The 'autoload' facility allows you to make a function or macro known in Lisp, but put off loading the file that defines it." So, as long as code is referencing only functions or macros that have been marked as autoloaded, it is not be necessary to require explicitly the packages that define them. The change to add the new function `slime-attach-gdb' does not reference only functions or macros. It also references a variable. Because `slime-attach-gdb' references an autoloaded function, this reference to the variable does not cause a problem -- its definition is loaded when the autoload for the function takes place. However, the compilation of slime.el will cause the variable to be flagged as undefined because the autoloading (by definition) takes place at run-time. So, everyone who compiles slime.el will, if they are being careful, need to check the code to confirm that it is calling an autoloaded function (searching for `gud-gdb', in this case) and looking it up in the defining file (gud.el). In this instance in slime.el, the autoloaded function is called quite near in the code to the reference to the variable, but that will not always be the case.
Won't the autoload magic do that automatically?
In this instance, yes. It is more a stylistic consideration. The code is written once, but (at least potentially) compiled and read by many people, who would then need to investigate to confirm that the definition of `gud-comint-buffer' will be loaded when `gud-gdb' is autoloaded. The stylistic rule I am proposing is that if the code references any non-autoloaded symbols (only functions and macros are autoloaded), then it should include a '(require ...)', regardless of whether the code also includes some autoloaded symbols. This should also help with robustness because if some future change were to remove the autoloaded symbols, then the non-autoloaded symbols would no longer have their definitions loaded.
* Mark Harig [2010-03-20 16:44+0100] writes:
The stylistic rule I am proposing is that if the code references any non-autoloaded symbols (only functions and macros are autoloaded), then it should include a '(require ...)', regardless of whether the code also includes some autoloaded symbols.
Those requires should be added to the existing (eval-when (compile) ...) section; a plain require would defeat the purpose of autoloading. Helmut
participants (3)
-
Helmut Eller -
Mark Harig -
Tobias C. Rittweiler