slime-devel September 2005

slime-devel@common-lisp.net

58 participants
72 discussions

[slime-devel] Daily ChangeLog diff
by lgorrie＠common-lisp.net 07 Sep '05

07 Sep '05

Index: slime/ChangeLog diff -u slime/ChangeLog:1.768 slime/ChangeLog:1.769 --- slime/ChangeLog:1.768 Mon Sep 5 16:00:20 2005 +++ slime/ChangeLog Wed Sep 7 20:44:51 2005 @@ -1,3 +1,18 @@ +2005-09-07 Matthias Koeppe <mkoeppe(a)mail.math.uni-magdeburg.de> + + * present.lisp (menu-choices-for-presentation): The + Inspect/Describe/Copy items are now provided from the Emacs side. + Implement all pathname menu items without having Emacs evaluate a + form. Fix for Lisps where ".lisp" is parsed as :name ".lisp". + + * slime.el (slime-menu-choices-for-presentation): New function, + return a menu with Inspect/Describe/Copy plus the items that come + from the menu protocol. + (slime-presentation-menu): Security improvement for the + presentation menu protocol: Don't eval arbitrary forms coming from + the Lisp. Minor cleanup: Use x-popup-menu in the normal Emacs way, + associating a command with each menu item. + 2005-09-05 Helmut Eller <heller(a)common-lisp.net> * swank-cmucl.lisp (background-message): New function. Forward the

1 0

[slime-devel] presentations and xemacs very slow?
by Todd Sabin 07 Sep '05

07 Sep '05

Hi, I decided to try out slime (been using ilisp), and found what seems to be a bug, or at least a poor default. I checked out the current CVS, and tried it in XEmacs 21.4.15 on an amd64 machine, with a semi-old cmucl snapshot (2005-01-04). Slime connected to cmucl just fine, but I didn't get too much further than that. Running buffer-menu made emacs hang for a second or more. After a little experimentation, I found that it hangs an amount proportional to the number of buffers I have. Once you get over 10 or so, you notice the delay, and when you get up around 50 buffers or more, it's really awful. I tried a bunch of stuff and found that this doesn't affect GNU-Emacs, and setting slime-repl-enable-presentations to nil is an effective workaround. I also tried the FAIRLY-STABLE branch, and it didn't seem to have the problem, but I couldn't get a connection to either cmucl or sbcl, so I'm not sure if that was a valid test. Anyway, does anyone have an idea what causes this, or if there's a better fix than disabling presentations? Thanks, Todd -- Todd Sabin <tsabin(a)optonline.net>

1 0

[slime-devel] Color-Theme vs Slime
by GP lisper 07 Sep '05

07 Sep '05

It appears that slime overwrites some color-theme variable, making the color selection option on the Emacs menu bar (under Tools) pop up this error message: face-attribute: Wrong type argument: symbolp, (slime-repl-inputed-output-face) My default.el has ... (require 'color-theme) ; wild colors ... (require 'slime) This has been occurring for awhile, I guess that color-theme is not that popular. I like using colors to help separate what username is working on what problem. Are there better alternatives? ;;; color-theme.el --- install color themes ;; Version: 6.5.4 ;; Keywords: faces ;; Author: Jonadab the Unsightly One <jonadab(a)bright.net> ;; Maintainer: Xavier Maillard <zedek(a)gnu-rox.org> ;; URL: http://www.emacswiki.org/cgi-bin/wiki.pl?ColorTheme TIA

3 2

[slime-devel] Daily ChangeLog diff
by lgorrie＠common-lisp.net 05 Sep '05

05 Sep '05

Index: slime/ChangeLog diff -u slime/ChangeLog:1.767 slime/ChangeLog:1.768 --- slime/ChangeLog:1.767 Sun Sep 4 20:33:07 2005 +++ slime/ChangeLog Mon Sep 5 16:00:20 2005 @@ -1,3 +1,35 @@ +2005-09-05 Helmut Eller <heller(a)common-lisp.net> + + * swank-cmucl.lisp (background-message): New function. Forward the + call to the front end. + (pre-gc-hook, post-gc-hook): Use it. + (swank-sym, sending-safe-p): Deleted. + + * swank.lisp (y-or-n-p-in-emacs): Simplify arglist. + (evaluate-in-emacs, dispatch-event, send-to-socket-io): Remove + evaluate-in-emacs stuff. + (to-string): Undo last change. to-string is not to supposed to + ignore errors. Bind *print-readably* instead. + (background-message): New function. + (symbol-external-p): Simplify it a little. + + * slime.el (slime-setup-command-hooks): Add after-change-functions + only if presentations are enabled. + (slime-dispatch-event, slime-enable-evaluate-in-emacs) + (evaluate-in-emacs): Remove evaluate-in-emacs stuff. It was not + used and redundant. + (slime-save-some-lisp-buffers): Renamed from + save-some-lisp-buffers. + (slime-choose-overlay-region): Ignore :source-form locations. + (slime-choose-overlay-for-sexp): Ignore errors when stepping over + forms. + (slime-search-method-location, slime-goto-location-position): Move + all this regexpery to it's own function. + (slime-recenter-if-needed, slime-repl-return): Factor some + duplicated code into its own function. + (slime-presentation-bounds, slime-presentation-around-point) + (slime-presentation-around-or-before-point): Minor cleanups. + 2005-09-04 Matthias Koeppe <mkoeppe(a)mail.math.uni-magdeburg.de> * slime.el (slime-ensure-presentation-overlay): New.

1 0

Re: [slime-devel] "Unbalanced parentheses"
by Jeff Cunningham 05 Sep '05

05 Sep '05

--Jeff I don't know if this is related, but I've been running into a matching problem on large projects exclusively, but it isn't parenthesis, its double-quotes. Specifically, if I type a long text string after a function declaration like this: (defun somefunction () "some text some text some text some text some text some text some text some text some text some text some text some text some text some text some text some text some text some text some text" (format t "some long format string with vars" var1 var2 var3)) What will happen is that everything after the description text is colored the same as if it were all commented out, and indenting works the same. It doesn't compile right either. When it happens, the only fix I've been able to find is to shorton the descriptive text to a single line, then everything straightens out and flies right. It has never happened in a short file and only occasionally in a long one. I'm running CMUCL 19a and if I could remember how to get the slime version, I'd give you that too. :\ --Jeff cunningham

2 2

[slime-devel] Daily ChangeLog diff
by lgorrie＠common-lisp.net 04 Sep '05

04 Sep '05

Index: slime/ChangeLog diff -u slime/ChangeLog:1.766 slime/ChangeLog:1.767 --- slime/ChangeLog:1.766 Wed Aug 31 13:28:08 2005 +++ slime/ChangeLog Sun Sep 4 20:33:07 2005 @@ -1,3 +1,16 @@ +2005-09-04 Matthias Koeppe <mkoeppe(a)mail.math.uni-magdeburg.de> + + * slime.el (slime-ensure-presentation-overlay): New. + (slime-add-presentation-properties): Don't add face, mouse-face, + keymap text properties. Call slime-ensure-presentation-overlay to + implement them via overlays. + (slime-remove-presentation-properties): Don't remove these text + properties. Delete the right overlay. + (slime-after-change-function): Add overlays for presentations if + necessary. + (slime-copy-presentation-at-point): Don't add face text property. + (slime-repl-grab-old-output): Likewise. + 2005-08-31 Marco Baringer <mb(a)bese.it> * swank.lisp (to-string): Handle errors during printing of objects.

1 0

[slime-devel] presentations
by Helmut Eller 04 Sep '05

04 Sep '05

I've some questions about the presentation stuff: 1. now that we have explicit messages for presentations in the protocol, can we remove the bridge thing? Yes, I know that presentations will then not work with the dedicated output stream, but that's a efficiency hack and layerying the bridge kludge on top of the efficiency hack is so ugly, it makes me cry. I'll remove it, if there are no objections. 2. is there another way to handle presentations than with after-change-functions? Our after-change-functions are totally broken in Emacs20. Could we use overlays instead of text properties for presentations? 3. is *can-print-presentation* still needed? It seems to me that slime-stream-p serves about the same purpose, but it is much cleaner. It's also ugly the we need to bind *can-print-presentation* in a lot of unrelated/random places.

3 4

Re: [slime-devel] presentations
by Matthias Koeppe 04 Sep '05

04 Sep '05

Alan Ruttenberg <alanr(a)pluto.mumble.net> writes: > On Sep 4, 2005, at 6:17 AM, Matthias Koeppe wrote: >> >>> 3. is *can-print-presentation* still needed? It seems to me that >>> slime-stream-p serves about the same purpose, but it is much >>> cleaner. It's also ugly the we need to bind >>> *can-print-presentation* in a lot of unrelated/random places. >> >> I would think it is not needed any more. > > Is that true even for the bridge code version? I think so, thanks to your slime-stream-p function. -- Matthias Köppe -- http://www.math.uni-magdeburg.de/~mkoeppe

1 0

Re: [slime-devel] presentations
by Alan Ruttenberg 04 Sep '05

04 Sep '05

My opinions: On Sep 2, 2005, at 6:46 PM, Helmut Eller wrote: > I've some questions about the presentation stuff: > > 1. now that we have explicit messages for presentations in the > protocol, can we remove the bridge thing? Yes, I know that > presentations will then not work with the dedicated output stream, > but that's a efficiency hack and layerying the bridge kludge on top > of the efficiency hack is so ugly, it makes me cry. I'll remove > it, if there are no objections. > Please don't. I tried not using the bridge version today and it was *much* slower. Annoyingly so. Unless you have some other idea about how to make the thing run faster. For that matter I've been poking around trying to understand how to make the bridge version run even faster. Maybe there is a way to structure the code differently so that it isn't so, um, stimulating. It could very well be time to refactor. BTW, Note that there is some bug in the bridge stuff that I keep running into. I am trying to debug it currently. > 2. is there another way to handle presentations than with > after-change-functions? Our after-change-functions are totally > broken in Emacs20. Could we use overlays instead of text > properties for presentations? Don't know this stuff well enough to know. My first versions used a different mechanism that wasn't as elegant, but might have been more backwards compatible. > 3. is *can-print-presentation* still needed? It seems to me that > slime-stream-p serves about the same purpose, but it is much > cleaner. It's also ugly the we need to bind > *can-print-presentation* in a lot of unrelated/random places. > The intent of *can-print-presentations* was to avoid the use of presentations in places that couldn't handle them like the inspector and sldb. I had thought that at some future time I would think about whether they had any use there and possibly make them work if so. I haven't caught up with all of Matthias' changes yet, so I'm not sure if it is necessary any more. --- FYI, I have a few features that I've been thinking of adding. 1) Style - Bold, color, tooltips. 2) Updateable presentations. I have some cases where I want to leave a marker for something that will take some time to compute and later update the presentation with the computed result. 3) Separate stream/process to handle presentation events so that they can be active even when the repl is busy. -Alan

2 1

[slime-devel] Daily ChangeLog diff
by lgorrie＠common-lisp.net 03 Sep '05

03 Sep '05

Index: slime/ChangeLog diff -u slime/ChangeLog:1.756 slime/ChangeLog:1.759 --- slime/ChangeLog:1.756 Sat Aug 27 18:37:56 2005 +++ slime/ChangeLog Sun Aug 28 17:09:46 2005 @@ -1,3 +1,27 @@ +2005-08-28 Matthias Koeppe <mkoeppe(a)mail.math.uni-magdeburg.de> + + * slime.el (slime-repl-kill-input): New command. + (slime-repl-mode-map): Bind it to C-c C-u, like in comint. + (slime-repl-easy-menu): Include it in the REPL menu. + + * swank-backend.lisp (make-weak-key-hash-table) + (make-weak-value-hash-table): New interfaces. + * swank-cmucl.lisp (make-weak-key-hash-table): Implement it. + * swank-sbcl.lisp (make-weak-key-hash-table): Implement it. + * swank-openmcl.lisp (make-weak-key-hash-table) + (make-weak-value-hash-table): Implement it. + + * swank.lisp (*object-to-presentation-id*) + (*presentation-id-to-object*): Use new functions + make-weak-key-hash-table, make-weak-value-hash-table. + + * slime.el (slime-enable-evaluate-in-emacs): New variable. + (evaluate-in-emacs): Security improvement: If + slime-enable-evaluate-in-emacs is nil (the default), don't + evaluate forms sent by the Lisp. + + * swank.lisp (send-to-socket-io): Handle :evaluate-in-emacs. + 2005-08-27 Matthias Koeppe <mkoeppe(a)mail.math.uni-magdeburg.de> * slime.el (slime-presentation-menu): When an object is no longer

5 10

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

slime-devel September 2005