- slime-devel - mailman3.common-lisp.net

[slime-devel] Daily ChangeLog diff
by Luke Gorrie 11 Jun '04

11 Jun '04

Index: slime/ChangeLog diff -u slime/ChangeLog:1.390 slime/ChangeLog:1.391 --- slime/ChangeLog:1.390 Wed Jun 9 21:40:28 2004 +++ slime/ChangeLog Thu Jun 10 11:08:23 2004 @@ -1,3 +1,48 @@ +2004-06-10 Christophe Rhodes <csr21(a)cam.ac.uk> + + * swank-sbcl.lisp (call-with-syntax-hooks): Add hooks to fix + "SB!"-style package names. + (shebang-readtable): Return a readtable with readermacros needed + to parse SBCL sources. + + * swank.lisp (with-buffer-syntax): New macro. This should be used + for code which needs to READ code from Emacs buffers. *package* + and *readtable* are bound suitable values. + (to-string, format-values-for-echo-area, interactive-eval) + (eval-region, interactive-eval-region, re-evaluate-defvar) + (swank-pprint, pprint-eval, listener-eval) + (compile-string-for-emacs, disassemble-symbol, describe-to-string) + (describe-symbol, describe-function) + (describe-definition-for-emacs) + (documentation-symbol, init-inspector, inspect-nth-part) + (inspector-pop, inspector-next, describe-inspectee) + (inspect-current-condition): Use it. + +2004-06-10 Helmut Eller <e9626484(a)stud3.tuwien.ac.at> + + * swank-loader.lisp: Initialize swank::*readtable-alist* for SBCL. + + * swank-backend.lisp (default-directory, call-with-syntax-hooks): + New functions. + + * swank.lisp (*readtable-alist*): New configurable. The keys are + package name and the values readtables. The readtable will be + used to READ code originating from Emacs buffers in the associated + slime-buffer-package. + (drop-thread): Simplified. + (*buffer-readtable*): New variable. + (parse-package): New function. + (parse-string): Renamed from symbol-from-string. Make it case + insensitive. + (eval-for-emacs): Initialize the *buffer-readtable*. + (symbol-indentation): Don't consider symbols in the CL package. + Emacs already knows how to indent them. + (compile-file-if-needed): Used for REPL shortcut + 'compile-and-load'. + + * slime.el (pwd): Re-add REPL shortcut. + (slime-repl-push-directory, slime-repl-compile-and-load): Simplified. + 2004-06-10 Luke Gorrie <luke(a)bluetail.com> * slime.el (sldb-step): Command is disabled because the function

1 0

[slime-devel] M-x slime-ensure-typeout-frame ?
by Sung-youn Kim 10 Jun '04

10 Jun '04

Hmm.. After M-x slime-ensure-typeout-frame, the command related messages are still directed to minibuffer with typeout frame open and idle. I use cmucl 18e and emacs21 on Debian sarge. -- _________________ Sung-youn Kim Political Science Dept. Stony Brook University (SUNY at Stony Brook) Office : 631-632-7664 Web : http://www.ic.sunysb.edu/stu/sungyoki

1 0

[slime-devel] Re: sbcl sources support
by Helmut Eller 10 Jun '04

10 Jun '04

I integrated your patch in the CVS version. It does basically the same as your patch, but the functionality is a bit better separated between front-end and backend. As a side-effect, *readtable-alist* can now be used to associate readtables with packages. Helmut. Christophe Rhodes <csr21(a)cam.ac.uk> writes: > Helmut Eller <e9626484(a)stud3.tuwien.ac.at> writes: > >> I think it's rather unlikely, that someone works on SBCL and another >> project with conflicting reader macros. > > Relatively unlikely, I grant you -- but not beyond the bounds of > possibility. (A number of projects I work on have their own > readtables, and it would be awkward if a minor bugfix to sbcl in the > interim caused odd things to happen). > >> What do you think about a command like: >> >> (defun set-sbcl-syntax () >> (setf *readtable* (sb-introspect:sbcl-readtable)) >> (sb-introspect:advice-find-package)) > > What I would like to happen is that, when a user does e.g. M-. to find > the source of an sbcl function, that the normal slime commands work as > expected without user intervention. The precise mechanism to achieve > this doesn't worry me so much (though I think global advising of > find-package, and global setting of *readtable*, is a lot uglier than > advice in the dynamic contour of slime evaluation -- this is in fact a > defect of my patch, which handles slightly too many > BOOTSTRAP-PACKAGE-NOT-FOUND conditions: during evaluation as well as > compilation.) > > The problem from my point of view with the requirement of an explicit > command is that it only marginally lowers the barrier of entry. If > you want a typical use case, I can imagine someone wishing to find the > location of the error emitted from defconstant when a constant is > being redefined, and redefine the checking function; notwithstanding > the fact that there may be better ways of achieving the ultimate aim, > I think this kind of interaction should be supported. I don't think > that this ability to treat the system as incrementally modifiable is > assisted very much (over the current situation) by having to run an > explicit command... > > Cheers, > > Christophe > > (Lest my tone be too negative: for the record I really appreciate the > work you, Luke and others have done. The fact that I'm even > contemplating incremental modification of sbcl via slime should be > testimony to that! :-)

1 0

[slime-devel] abcl
by Andras Simon 10 Jun '04

10 Jun '04

While the list was sleeping, I adapted Helmut's allegro backend for abcl. It is not quite ready for prime time, but is somewhat usable. Actually, it's already at version 2 (or should I say 0.02): originally, I had to patch swank.lisp, but thanks to Peter Graves, who tracked down pretty printing bugs in abcl, this is no longer necessary. Nevertheless, it's probably too early to include it in the official slime sources, but I thought I'd let you know about it anyway. It's temporarily available here: http://www.math.bme.hu/~asimon/slime-abcl.tgz The tar file includes swank-loader.lisp (so back up yours if you untar it in the slime directory) and swank-abcl.lisp. It doesn't work with the latest abcl release, only with the cvs version. (In fact, it's probably better to wait a few hours until anon cvs at sourceforge picks up the latest sources.) Andras

2 5

[slime-devel] slime-maybe-start-lisp patch
by Robert Lehr 10 Jun '04

10 Jun '04

I have applied this patch to my local installation of SLIME. It enables me to point to the 'swank-loader' lisp in any location. It enables the user to bypass the original concatenation of SLIME-PATH and SLIME-BACKEND depending on whether SLIME-BACKEND is an absolute pathname or not. In other words, if SLIME-BACKEND is an absolute pathname then the original procedure is bypassed, avoiding the concatenation of SLIME-PATH and SLIME-BACKEND. Otherwise, they are concatenated. Whether you accept this specific logic or not, you should be aware that some installations do not want to put the emacs code and the lisp code in the same location. Hence, my conflict with the 'swank-loader' that I resolved with this patch. -- Robert Lehr (concatenate 'string "bozzio" "@" "the-lehrs" ".com" )

1 1

[slime-devel] Anonymous CVS back (again)
by Luke Gorrie 10 Jun '04

10 Jun '04

Ahoy, Anonymous CVS should be working again now.

1 0

[slime-devel] Daily ChangeLog diff
by Luke Gorrie 10 Jun '04

10 Jun '04

Index: slime/ChangeLog diff -u slime/ChangeLog:1.387 slime/ChangeLog:1.390 --- slime/ChangeLog:1.387 Tue Jun 8 16:58:32 2004 +++ slime/ChangeLog Wed Jun 9 21:40:28 2004 @@ -1,3 +1,48 @@ +2004-06-10 Luke Gorrie <luke(a)bluetail.com> + + * slime.el (sldb-step): Command is disabled because the function + `swank:sldb-step' that it calls doesn't exist. I don't see any + stepping code in our backends. + +2004-06-09 Helmut Eller <e9626484(a)stud3.tuwien.ac.at> + + * slime.el (slime-goto-location-position) [:function-name]: The + function name can also occur after a ?(, not only after + whitespace. + + * (slime-init-output-buffer): Initialize the package stack. + Reported by Rui Patrocínio. + + * (slime-completions): Make it consistent with + slime-simple-completions. The second argument was never supplied. + Reported by Rui Patrocínio. + +2004-06-09 Eric Blood <eblood(a)winkywooster.org> + + * slime.el (slime-indent-and-complete-symbol): Renamed from + slime-repl-indent-and-complete-symbol. + + (slime-typeout-frame-properties): Add more default options for the + typeout frame--specifically it now has a default width, and moves + the typeout frame to the upper right. + +2004-06-09 Andras Simon <andras(a)renyi.hu> + + * swank-abcl.lisp: New backend for Armed Bear Common Lisp. + + * swank-loader.lisp: Add ABCL support. + +2004-06-09 Martin Simmons <martin(a)xanalys.com> + + * swank-lispworks.lisp (dspec-stream-position): New function to + make source location work for anything complicated e.g. methods. + (with-swank-compilation-unit): Refactoring. + (who-macroexpands): Implemented. + (list-callers): Implemented. + + * swank-backend.lisp (network-error): Inherit from simple-error to + get correct initargs. + 2004-06-09 Luke Gorrie <luke(a)bluetail.com> * slime.el (sldb-insert-references): Added support for hyperlinked

1 0

[slime-devel] Welcome back!
by Luke Gorrie 09 Jun '04

09 Jun '04

Greetings, The mailing list is now operational again! At least I presume it is, if this test message gets through :-)

5 6

[slime-devel] sbcl sources support
by Christophe Rhodes 09 Jun '04

09 Jun '04

Hi, Attached is a (probably corrupt, sorry) patch which partly implements DWIM when slime commands are executed on sbcl sources. The background: for those who do not know the detail, suffice it to say that, out of the box, sbcl sources are unreadable (in the READ sense) to a running sbcl. The unreadability comes in two forms: firstly, all of the package names are different (this enables sbcl to build cleanly even from itself); secondly, the #! reader macro (reserved to the user) is used extensively by the sources to implement reader conditionals against the *features* that will be active under the to-be-built lisp. This patch uses knowledge of sbcl internals (some of which should probably be in sb-introspect; they'll get moved there once we establish exactly what we need) to, firstly, modify the behaviour of FIND-PACKAGE to treat SB!FOO as a nickname for SB-FOO; and secondly, to temporarily replace the current readtable with one which includes a #! reader macro. This, I think, is good enough for a DWIM system; it gets about 99% of sbcl sources right. My implementation of it is, of course, sucky. I don't really have a handle on the package discipline, nor where a feature like this logically belongs in slime -- it seems to cross-cut several layers. On top of this, I'm fairly sure I haven't found all the places where this is necessary: essentially all places that could do READ need to be wrapped. [ The implementation of the #! reader macro logically belongs in sb-introspect, I think, but it isn't there yet. ] I hope this patch gives enough of a flavour for what is necessary, and enough information to either desuckify it for me, or to tell me what I should do to make it suck less. Cheers, Christophe -- http://www-jcsu.jesus.cam.ac.uk/~csr21/ +44 1223 510 299/+44 7729 383 757 (set-pprint-dispatch 'number (lambda (s o) (declare (special b)) (format s b))) (defvar b "~&Just another Lisp hacker~%") (pprint #36rJesusCollegeCambridge)

2 2

[slime-devel] some problems
by Rui Patrocínio 09 Jun '04

09 Jun '04

Hello, I'm currently working on some extensions to slime (I hope to release the source at end of the month) and I've found some minor problems. Currently the 'slime-repl-stack-package' is not initialized with M-x slime (only with slime-start-and-load, AFAIK), none the less the repl starts with the CL-USER package. Shouldn't the stack be initialized with that package? The other problem is only a matter of consistency. The slime-simple-completions doesn't have the same interface of slime-completions. I think there are some problems with the handling of CL symbols and packages, but I'll comment on that later. Continue with the great job. :) Rui Patrocínio

2 1