Frame-restartable-p is not defined in openmcl-swank.lisp and thus always returns NIL. This seems like an omission given that return- from-frame and restart-frame recently were added:
+2009-05-17 Helmut Eller heller@common-lisp.net + * swank-openmcl.lisp + (return-from-frame, restart-frame)
-- Terje Norderhaug
* Terje Norderhaug [2009-07-17 02:17+0200] writes:
Frame-restartable-p is not defined in openmcl-swank.lisp and thus always returns NIL. This seems like an omission given that return- from-frame and restart-frame recently were added:
Even though Swank has an implementation it doesn't mean that it actually works. The problem is: %apply-in-frame doesn't work for x8632 yet.
Helmut
On Jul 17, 2009, at 9:35 AM, Helmut Eller wrote:
- Terje Norderhaug [2009-07-17 02:17+0200] writes:
Frame-restartable-p is not defined in openmcl-swank.lisp and thus always returns NIL. This seems like an omission given that return- from-frame and restart-frame recently were added:
Even though Swank has an implementation it doesn't mean that it actually works. The problem is: %apply-in-frame doesn't work for x8632 yet.
Could perhaps frame-restartable-p be defined for #+powerpc in openmcl- swank? I am eager to use this functionality with Clozure even if it does not yet work on all hardware platforms.
-- Terje Norderhaug
Terje Norderhaug terje@in-progress.com writes:
Could perhaps frame-restartable-p be defined for #+powerpc in openmcl- swank? I am eager to use this functionality with Clozure even if it does not yet work on all hardware platforms.
Notice that FRAME-RESTARTABLE-P has _no_ consequences on the ability to restart from frames.
All it does is to make frames that are known to be restartable be fontified specially in the SLDB buffer.
-T.
PS. If you want to change the colors, you can use
M-x customize-face RET sldb-restartable-frame-line M-x customize-face RET sldb-non-restartable-frame-line
On Jul 17, 2009, at 11:13 AM, Tobias C. Rittweiler wrote:
Terje Norderhaug terje@in-progress.com writes:
Could perhaps frame-restartable-p be defined for #+powerpc in openmcl- swank? I am eager to use this functionality with Clozure even if it does not yet work on all hardware platforms.
Notice that FRAME-RESTARTABLE-P has _no_ consequences on the ability to restart from frames. All it does is to make frames that are known to be restartable be fontified specially in the SLDB buffer.
I am aware of that (having implemented support for frame restarts in my swank client). Providing FRAME-RESTARTABLE-P for Clozure has the practical consequence of making remote frame restarting "officially" and visibly available at least for PowerPC, with the QA benefit of the functionality being more used.
-- Terje
* Terje Norderhaug [2009-07-17 19:40+0200] writes:
Could perhaps frame-restartable-p be defined for #+powerpc in openmcl- swank? I am eager to use this functionality with Clozure even if it does not yet work on all hardware platforms.
Well, that would be no problem. OTOH, the flag would be the same for each frame. What do you want to do with it?
On Jul 17, 2009, at 11:35 AM, Helmut Eller wrote:
- Terje Norderhaug [2009-07-17 19:40+0200] writes:
Could perhaps frame-restartable-p be defined for #+powerpc in openmcl- swank? I am eager to use this functionality with Clozure even if it does not yet work on all hardware platforms.
Well, that would be no problem. OTOH, the flag would be the same for each frame. What do you want to do with it?
I use it on the client to check a priori whether a frame can be restarted.
-- Terje Norderhaug
Terje Norderhaug terje@in-progress.com writes:
I use it on the client to check a priori whether a frame can be restarted.
I did not intend FRAME-RESTARTABLE-P to necessarily work reliably. Perhaps an implementation has a short, and a long path to find it out, and because the long path would be too time-consuming, it implements FRAME-RESTARTABLE-P only going through the short path.
Furthermore, I think FRAME-RESTARTABLE-P should become a FRAME-ATTRIBUTES function with :RESTARTABLE, and :NON-RESTARTABLE being the currently specified values.
-T.
I just stumbled upon a problem with fuzzy completion. This was investigated using a freshly updated slime from CVS and SBCL 1.0.28 on an intel mac.
If one adds
(setq *read-default-float-format* 'double-float)
to .sbclrc, deletes ~/.slime and then restart the slime session, completion stops working. One gets an error such as this (in emacs):
Debugger entered--Lisp error: (error "Format specifier doesn't match argument type") format(" %s %-8.2f" "-f--t---" "42.67858333333333d0") (insert (format " %s %-8.2f" classification-string score))
Apparently, due to float type differences that I can not quite understand, the scores reported from the cl side now includes the "d0" specifier for a single float which emacs then interprets as a symbol rather than a number.
The problem does not occur when swank is compiled under the normal default float format, even if the the default is then changed afterwards again. This means that there is a workaround (just make sure swank always is compiled with normal float defaults) and changing the default float format is probably not the most common thing to do and it needs to coincide with a slime update to trigger the problem.
None the less I guess it hints at a fragility in the moving of floats between CL and emacs, though I know too little about the slime internals to say if this is in the generic parts (in which case it probably ought to be handled) or just in the particulars of the fuzzy completion contrib.
For reference here is a slightly larger emacs stack trace:
Debugger entered--Lisp error: (error "Format specifier doesn't match argument type") format(" %s %-8.2f" "-f--t---" "42.67858333333333d0") (insert (format " %s %-8.2f" classification-string score)) (let ((start ...) (end)) (insert symbol-name) (setq end (point)) (dolist (chunk chunks) (put-text-property ... ... ... ...)) (put-text-property start (point) (quote mouse-face) (quote highlight)) (dotimes (i ...) (insert " ")) (insert (format " %s %-8.2f" classification-string score)) (insert "\n") (put-text-property start (point) (quote completion) completion)) (let* ((--cl-rest-- completion) (symbol-name ...) (score ...) (chunks ...) (classification-string ...)) (let (... ...) (insert symbol-name) (setq end ...) (dolist ... ...) (put-text-property start ... ... ...) (dotimes ... ...) (insert ...) (insert "\n") (put-text-property start ... ... completion))) (progn (let* (... ... ... ... ...) (let ... ... ... ... ... ... ... ... ...))) (destructuring-bind (symbol-name score chunks classification-string) completion (let (... ...) (insert symbol-name) (setq end ...) (dolist ... ...) (put-text-property start ... ... ...) (dotimes ... ...) (insert ...) (insert "\n") (put-text-property start ... ... completion))) slime-fuzzy-insert-completion-choice(("member" 42.67858333333333d0 ((0 "memb")) "-f--t---") 32)
------------------------+----------------------------------------------------- Christian Lynbech | christian #@ defun #. dk ------------------------+----------------------------------------------------- Hit the philistines three times over the head with the Elisp reference manual. - petonic@hal.com (Michael A. Petonic)
Christian Lynbech christian@defun.dk writes:
I just stumbled upon a problem with fuzzy completion. This was investigated using a freshly updated slime from CVS and SBCL 1.0.28 on an intel mac.
If one adds
(setq *read-default-float-format* 'double-float)to .sbclrc, deletes ~/.slime and then restart the slime session, completion stops working. One gets an error such as this (in emacs):
Debugger entered--Lisp error: (error "Format specifier doesn't match argument type") format(" %s %-8.2f" "-f--t---" "42.67858333333333d0") (insert (format " %s %-8.2f" classification-string score))Apparently, due to float type differences that I can not quite understand, the scores reported from the cl side now includes the "d0" specifier for a single float which emacs then interprets as a symbol rather than a number.
This is because threads do not inherit bindings, so in all threads started by slime *read-default-float-format* is bound to SINGLE-FLOAT, while in the parent thread it is DOUBLE-FLOAT.
Christian Lynbech christian@defun.dk writes:
I just stumbled upon a problem with fuzzy completion. This was investigated using a freshly updated slime from CVS and SBCL 1.0.28 on an intel mac.
If one adds
(setq *read-default-float-format* 'double-float)to .sbclrc, deletes ~/.slime and then restart the slime session, completion stops working. One gets an error such as this (in emacs):
Debugger entered--Lisp error: (error "Format specifier doesn't match argument type") format(" %s %-8.2f" "-f--t---" "42.67858333333333d0") (insert (format " %s %-8.2f" classification-string score))
I fixed the issue with fuzzy completion, but the fact that *read-default-float-format* woud be different in other threads, including repl, remains.
"Stas" == Stas Boukarev stassats@gmail.com writes:
Stas> Christian Lynbech christian@defun.dk writes:
Stas> I fixed the issue with fuzzy completion, but the fact that Stas> *read-default-float-format* woud be different in other threads, Stas> including repl, remains.
Thanks.
-- Christian
Stas Boukarev stassats@gmail.com writes:
I fixed the issue with fuzzy completion, but the fact that *read-default-float-format* woud be different in other threads, including repl, remains.
But Christian changes *READ-DEFAULT-FLOAT-FORMAT* in his .sbclrc, i.e. he changes the global binding. :-)
-T.
"Tobias C. Rittweiler" tcr@freebits.de writes:
Stas Boukarev stassats@gmail.com writes:
I fixed the issue with fuzzy completion, but the fact that *read-default-float-format* woud be different in other threads, including repl, remains.
But Christian changes *READ-DEFAULT-FLOAT-FORMAT* in his .sbclrc, i.e. he changes the global binding. :-)
Didn't know that about .sbclrc. Then float mismatch is somewhere else.
* Christian Lynbech [2009-07-18 07:49+0200] writes:
None the less I guess it hints at a fragility in the moving of floats between CL and emacs, though I know too little about the slime internals to say if this is in the generic parts (in which case it probably ought to be handled) or just in the particulars of the fuzzy completion contrib.
Yep. Sending floats across the wire is problematic and should be avoided. It would be better to send it as string. We could probably enforce that but I doubt that it's worth doing so. We could also forbid bignums and symbols with bars etc. There are many small differences between Emacs's and CL's syntax, but it's just too convenient not to exploit the similarities.
Helmut.
-
Christian Lynbech -
Helmut Eller -
Stas Boukarev -
Terje Norderhaug -
Tobias C. Rittweiler