Index: slime/ChangeLog diff -u slime/ChangeLog:1.2243 slime/ChangeLog:1.2246 --- slime/ChangeLog:1.2243 Sat Nov 19 08:35:58 2011 +++ slime/ChangeLog Mon Nov 21 11:52:25 2011 @@ -1,3 +1,33 @@ +2011-11-21 Helmut Eller heller@common-lisp.net + + * swank-cmucl.lisp: Trigger compilation of utf8 stuff before first + real use. + +2011-11-21 Helmut Eller heller@common-lisp.net + + * swank.lisp (*sldb-printer-bindings*): Removed. Rather useless + since the change from 2009-02-26. It could at best have some + influence on the way conditions are printed. *sldb-string-length* + and *sldb-bitvector-length* where both nil so + *sldb-pprint-dispatch-table* was also not used by default. In + summary, spending 3 pages for something that's not used by default + was pretty silly. One variable less where we can get the defaults + wrong. + +2011-11-21 Helmut Eller heller@common-lisp.net + + * slime.el (sldb-eval-in-frame): Try to figure the package out. + Ask Lisp if the function for frame was defined in a particular + package and use it to read the form. + (sldb-read-form-for-frame): New helper. + + * swank-backend (frame-package): New. + * swank-cmucl (frame-package): Implement it. + + * swank.lisp (frame-package-name, eval-in-frame-aux): New. + (eval-string-in-frame, pprint-eval-string-in-frame): Use package + argument. + 2011-11-19 Nikodemus Siivola nikodemus@random-state.net
* swank-sbcl.lisp (restart-frame): Make it possible to restart
2011/11/22 Helmut Eller:
+2011-11-21 Helmut Eller heller@common-lisp.net
- * slime.el (sldb-eval-in-frame): Try to figure the package out.
- Ask Lisp if the function for frame was defined in a particular
- package and use it to read the form.
- (sldb-read-form-for-frame): New helper.
- * swank-backend (frame-package): New.
- * swank-cmucl (frame-package): Implement it.
- * swank.lisp (frame-package-name, eval-in-frame-aux): New.
- (eval-string-in-frame, pprint-eval-string-in-frame): Use package
- argument.
Could frame-package's default implementation be (eval-in-frame 'cl:*package* frame-number)?
Paulo Madeira
* Paulo Madeira [2011-11-22 13:46] writes:
Could frame-package's default implementation be (eval-in-frame 'cl:*package* frame-number)?
Hmm... yes, but I'm not sure in what cases that would be better than what we do know. Currently we return nil by default. That way we can at least tell that the backend has no strong opinion on the matter and we simply use the current value of *package* as fallback.
The purpose of frame-package was primarily that we can read the names of local variables without package prefix. That package is actually more a (static) property of the frame's function than a (dynamic) property of the stack frame itself. Basically we are interested in the package that was current when the function was compiled.
In many implementations (eval-in-frame '*package* <N>) is literally the same as (eval '*package*). In Lisps that actually bother to reconstruct the dynamic environment of the time of the call it's also not necessarily the same package as it was when the function was read/compiled.
(eval-in-frame '*package* <N>) seems to be as good/bad as the current default but I haven't actually tried it.
Helmut
2011/11/22 Helmut Eller:
Currently we return nil by default. That way we can at least tell that the backend has no strong opinion on the matter and we simply use the current value of *package* as fallback. (...) Basically we are interested in the package that was current when the function was compiled.
This is quite interesting. Maybe it should be called "definition package" instead of "frame package".
I was thinking along the line that `e' in sldb reads (or used to read) the form in CL-USER (it seems) and evalutes it in the repl's package. For instance:
(defpackage #:foo)
(defun test () (let ((*package* (find-package '#:foo))) (break)))
If you enter "(test)" in the repl while in package CL-USER, press `e' in frame "break" or "test" and enter "(symbol-package 'sym1)", you get the CL package.
If you enter "(cl-user::test)" in the repl while in package FOO and do the rest, you get the FOO package.
In my though, executing `symbol-package' shouldn't even succeed, since package FOO doesn't use CL. `sdlb-eval-in-frame' would read the form and execute it with the `*package*' of the current frame.
Ok, after exposing this, my opinion is kind of split. When debugging, it's mighty handy to just copy-paste a source form and have it be read in the package where the definition was defined. But there might also be cases where one really wants to read and evaluate things in the frame's bound value of `*package*'.
I wasn't considering the chance that an implementation wouldn't have an accessible dynamic environments for each frame. In this case, it may be more intuitive to just use the frame's `*package*' for both reading and evaluating, even if that means always using the most recent frame's `*package*'.
The purpose of frame-package was primarily that we can read the names of local variables without package prefix.
Maybe there should be an SLDB binding just to get a binding's value , e.g. that would try match a variable name no matter its package, unless there were two same named symbols in different packages, where CMUCL could use its magic to Guess What You Mean (TM).
PS: please excuse my spaghetti quoting.
Paulo Madeira
* Paulo Madeira [2011-11-23 00:08] writes:
2011/11/22 Helmut Eller:
Currently we return nil by default. That way we can at least tell that the backend has no strong opinion on the matter and we simply use the current value of *package* as fallback. (...) Basically we are interested in the package that was current when the function was compiled.
This is quite interesting. Maybe it should be called "definition package" instead of "frame package".
I was thinking along the line that `e' in sldb reads (or used to read) the form in CL-USER (it seems) and evalutes it in the repl's package.
The debugger switches to the *buffer-package* if it is bound. That's bound before the evaluation is started (the one that triggers the debugger). Not sure if that is such a great idea, but it's what we currently do.
For instance:
(defpackage #:foo)
(defun test () (let ((*package* (find-package '#:foo))) (break)))
If you enter "(test)" in the repl while in package CL-USER, press `e' in frame "break" or "test" and enter "(symbol-package 'sym1)", you get the CL package.
CL-USER would be ok, but CL package is indeed unexpected.
If you enter "(cl-user::test)" in the repl while in package FOO and do the rest, you get the FOO package.
In my though, executing `symbol-package' shouldn't even succeed, since package FOO doesn't use CL. `sdlb-eval-in-frame' would read the form and execute it with the `*package*' of the current frame.
That's probably because you weren't aware of the *buffer-package* thing.
Ok, after exposing this, my opinion is kind of split. When debugging, it's mighty handy to just copy-paste a source form and have it be read in the package where the definition was defined. But there might also be cases where one really wants to read and evaluate things in the frame's bound value of `*package*'.
I'm not sure that I can follow your reasoning. In the latter case symbols need to be entered with qualifiers to access frame local variables. That's never more desirable than non-qualified symbols. And if we aren't accessing local variables, why are we using eval-in-frame?
I wasn't considering the chance that an implementation wouldn't have an accessible dynamic environments for each frame. In this case, it may be more intuitive to just use the frame's `*package*' for both reading and evaluating, even if that means always using the most recent frame's `*package*'.
I think we should aim at the common case. It seems to me that few frames explicitly bind *package* but that the functions on the stack often belong to different packages.
There is also no need to use the same package for read and eval.
The purpose of frame-package was primarily that we can read the names of local variables without package prefix.
Maybe there should be an SLDB binding just to get a binding's value , e.g. that would try match a variable name no matter its package, unless there were two same named symbols in different packages, where CMUCL could use its magic to Guess What You Mean (TM).
Something like that would amount to implement eval-in-frame directly. And there is still the problem that two local lexical variables can in fact have the same name when one shadows the other. Luckily, sldb-toggle-details solves that problem most of the time.
Helmut
-
Helmut Eller -
Paulo Madeira