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

Re: [slime] the inspector doesn't run the swank side in the initiating thread (#12)
by Helmut Eller 08 Apr '15

08 Apr '15

On Sat, Jan 04 2014, João Távora wrote: > Helmut Eller <notifications(a)github.com> writes: > >> On Fri, Jan 03 2014, João Távora wrote: >> >>> In any case we should reopen the issue and mark it low priority. It >>> would make nice a feature, whatever the implementation. >> I consider this bloat and not a valuable feature. > > Helmut, > > I assigned the issue to me and reopened it. At the end of this message I > explain what I intend to do with it, and will not do any rogue commit or > anything. > > I really think we should not close off such feature requests with > statements of personal preference. While stating opinion is of course > OK, closing discussions out of view not only doesn't make the demand go > away, but detracts from one of the advantages of the github ecosystem > which is attracting hackers that might be willing to do Slime "the > sincerest form of code appreciation". OK, as you wish. > Given the conditions we're in (daily hungry SLIME users), as Luís > explained, we are committed to inverting the effective dev stall that > Slime has seen in the past years (lately completely dead). We went to > some lengths to refrain from forking and keep the general project > policies. > > I think it's only fair to list at least approximately my personal goals > for the project: > > * All current slime tests should pass in various combinations (this is > being worked on currently). > > * Slime should be installable via ELPA and el-get > > * Contribs should be completely independent (no need to add their swank > files to *CONTRIBS*) and also installable via ELPA and el-get, which > both manage dependencies nicely. > > * Modern emacs coding conventions should be adhered to. This sounds all good. > I'd also like hear your (and everyone else's) plans for the future of > Slime. My goals are: * keep maintance effort down, i.e. I don't want to spend my time or have endless discussions on features that I don't actually use * make it easier for other people to create and cooperate on contribs or features that they care about but are of limited interest to me or the average SLIME user * continued support for Emacs 23. Using the Emacs version that is in Debian Stable should be as hassle-free as possible. * There are always some cleanups to do, e.g. the CMUCL backend should finally use Gray streams. * for the dedicated output stream it would be reasonable to keep the initial port open to avoid some firewall issues. That would also make it easy to open other sockets, which is much more likely to fly than the idea with multiplexed streams on a single connection. * I would like to compile my Lisp code with makefiles. Maybe SLIME could ship some command line tools to make that easier. This may be outside the scope of SLIME, tho. > Reading through slime.el I agree with you that it is indeed a bit > bloated. I'm also commited to cleaning it up. By offloading tests to > ert.el for example I relieved slime of 250 lines of test framework. If > you look at the diffs you'll see other small refactorings. Yes, that was good work. > So while I think the patch at hand is hardly bloat (because of its small > size), I also agree that Slime's core should grow smaller and offer more > consistent interfaces so features like the one requested by Attila can > be implemented as contribs. Lets keep this issue open as an attempt to > do that, who knows, you might be surprised with less and more > maintainable lines of code instead of more. That would indeed be a surprise. Helmut

1 0

New contrib: slime-trace-dialog
by joaotavora＠gmail.com 08 Apr '15

08 Apr '15

Hello, I submit for review a new contrib I've been working on, an interactive dialog for examining the tree of collected traces. It's inspired by Allegro's trace dialog. Here's a screenshot: http://i.imgur.com/ycIzzOf.png It's probably still a little rough around the edges, but is proving really useful for my work, and integrates well with the rest of slime. The best way to understand how it works is to try it out: * apply the patch attached to any recent slime * point a git slime to the "slime-trace-dialog" branch at http://github.com/capitaomorte/slime slime-trace-dialog is automatically loaded by the slime-fancy contrib: * specs are traced/untraced with C-c M-t, works like C-c C-t * open the dialog with C-c T, or M-x slime-trace-dialog * click on the interactive parts of the dialog, to control trace collection and inspect objects. It needs emacs 24 for its lexical-binding feature. I've tested with sbcl, allegro, and clisp. The swank-side of the contrib, swank-trace-dialog.lisp, uses a new group of interfaces in swank-backend.lisp, WRAP, UNWRAP and WRAPPED-P. There is a default implementation for each one, but the allegro implementation is best, and allows tracing of complex specs using the slime-fancy-trace contrib. sbcl's implementation is second best. I added these interfaces so they can assist in writing future extensions, like maybe a simple interactive profiler. Thanks, João

2 4

Testing subscriber post
by Drew C 08 Apr '15

08 Apr '15

This should simply go through non-moderated. -- drewc

1 0

ChangeLog file
by joaotavora＠gmail.com 08 Apr '15

08 Apr '15

Luís Oliveira <notifications(a)github.com> writes: > FWIW, I find the ChangeLog distracts people from more IMHO more important > efforts such as updating the NEWS file or writing a proper commit message > describing why something has changed rather than what. I don't agree at all: you *should* describe in the ChangeLog or commit messages **why you changed what**. In the NEWS file, you describe the user-visible aspects of your change. The ChangeLog format can hardly be blamed for any lazyness to write proper commit messages, indeed it encourages the opposite. The information in SLIME's ChangeLog has been invaluable to my recent hackings, for example. I refer you to the discussion in emacs-devel, they're getting rid of the ChangeLog file, but not its format. Still, Helmut, I propose that we get rid of the ChangeLog files and use commit messages exclusively. I've noticed that with no such file, pressing C-x 4 a will still create a (dummy) ChangeLog file with the prettily formatted entries. You just don't commit it and it can probably be ignored in .gitignore. Then, a fairly recent Emacs's built-in vc-dir.el will, upon commiting, automatically transpose the text below the date-and-author line is to the commit message buffer. This is extremely convenient and I invite you to try it (in other versions, you have to copy&paste and remove the left indentation manually). Finally, emacs's own "M-x vc-print-log" will give you all the information. The actual diff is only the "=" keybinding away. If Helmut agrees, I see the following steps to enable this in SLIME: * We must find a way to re-implement version checking between SLIME and Swank that is portable across all installation options. slime.el can parse itself on compile/load to look for the ";; Version:" cookie (that MELPA and other automated builders also look for, incidently). swank.lisp would have to do something similar in portable Common Lisp to report its own version in a variable. * Listing the contributors in the manual depends on the ChangeLog, but that can be delegated to some variation of git log | grep Author: | cut -d ' ' -f 1 --complement | sort | uniq except for the authors of patches that were commited by someone else in the CVS days. * The CONTRIBUTING.md file has to be updated. Anyone up to perform these changes? João

3 4

tests for contrib/slime-cl-indent.el are broken
by Robert Brown 08 Apr '15

08 Apr '15

You can verify tests are broken if you M-x load-file slime-cl-indent.el then evaluate the following in *scratch* (progn (setq lisp-indent-function 'common-lisp-indent-function) (common-lisp-run-indentation-tests t)) The root cause is complicated. Setting comment-column to nil in the buffer used for testing fixes things. Bob Index: slime-cl-indent-test.txt =================================================================== RCS file: /project/slime/cvsroot/slime/contrib/slime-cl-indent-test.txt,v retrieving revision 1.22 diff -u -r1.22 slime-cl-indent-test.txt --- slime-cl-indent-test.txt 13 Apr 2012 16:16:11 -0000 1.22 +++ slime-cl-indent-test.txt 22 Nov 2013 23:26:18 -0000 @@ -348,9 +348,6 @@ (bar)) ;;; Test: 32 -;; -;; comment-indent-function: (lambda () nil) -;; comment-column: nil (unknown (;; KLUDGE: comment-indent hackery to get ;; the comment right. Otherwise we get a Index: slime-cl-indent.el =================================================================== RCS file: /project/slime/cvsroot/slime/contrib/slime-cl-indent.el,v retrieving revision 1.68 diff -u -r1.68 slime-cl-indent.el --- slime-cl-indent.el 3 Jan 2013 12:40:52 -0000 1.68 +++ slime-cl-indent.el 22 Nov 2013 23:26:18 -0000 @@ -33,6 +33,8 @@ ;;; Code: +(require 'cl) + (defgroup lisp-indent nil "Indentation in Lisp." :group 'lisp) @@ -1755,6 +1757,11 @@ (defun common-lisp-indent-test (name bindings test) (with-temp-buffer (lisp-mode) + ;; We've installed a comment-indent-function that returns nil, so that + ;; comment-indent always calls indent-according-to-mode. Unfortunately, it + ;; shifts comments to comment-column, if there's text before the comment. + ;; Turn that behavior off by setting comment-column to nil. + (setq comment-column nil) (setq indent-tabs-mode nil) (common-lisp-set-style "common-lisp-indent-test") (dolist (bind bindings)

2 2

Re: [slime] swank-loader could use ASDF (#65)
by joaotavora＠gmail.com 08 Apr '15

08 Apr '15

[CCing slime-devel] François-René Rideau <notifications(a)github.com> writes: > On SBCL, (time (require :asdf)) takes .15s, but total SLIME startup > time is about 3s, so ASDF doesn't seem to be the bottleneck. I didn't say that it was, and yes that matches my times. I am mostly curious as to the proportion of ABCL's 2 seconds to the total current SLIME startup time. > On most implementations, you don't need to compile asdf if you use the > implementation's provided ASDF (assuming it's recent > enough). > > Otherwise, yes, the first time around, you get to compile asdf — but > hopefully, that's only the case on SCL. It's also the case on most Allegros. Even 9.0 doesn't have the newest ASDF, it seems to have 2.23.7. But a one-time wait per lisp implementation is not so bad for me. > Yes, it makes sense to me that each slime extension should get its own > directory, its own .asd file, etc. In case it wasn't clear, the mock tree I gave in the last email were the contents of the ~/.emacs.d/elpa dir after installation. So the slime source repo, the main .asd file can be still be the "all in one" that you propose in pull request #80. Those small .asd files can easily be auto-generated when packaging. Maybe this makes sense so as not to disrupt the current repo organization too much. In the el-get case, the installed software in ~/.emacs.d/el-get *is* the source repo. So non-third-party contribs are loaded slightly differently, while third-party contribs would be just like in the ELPA case. > There's a slight issue of how to communicate the search path between > Emacs and ASDF, however: push things to the central-registry? Is let-binding ASDF:*CENTRAL-REGISTRY* very bad? I sometimes do that and it works ok. We could set it to the same path where we have the .el file. This would have to be tested and as robust as possible of course. > source-registry? Add an Emacs-specific sysdef search function? I'm not familiar with any SOURCE-REGISTRY var. And also would avoid, if possible, replicating in emacs-lisp what might already be in ASDF. João

1 0

Re: slime on github
by Paul Bowyer 08 Apr '15

08 Apr '15

Hello João, If you recall, I mentioned some error messages that occurred in the slime *messages* buffer when I tried to load log4cl: error in process filter: ad-Orig-slime-repl-emit: Text is read-only error in process filter: Text is read-only Well, this afternoon I was trying to track down a problem related to some work I was doing and I went to the *inferior-lisp* buffer and entered (sb-ext:describe-compiler-policy). That produced the following error message in the *messages* buffer: error in process filter: slime-repl-emit: Text is read-only error in process filter: Text is read-only If I enter (sb-ext:describe-compiler-policy) in the repl, I get normal output in the repl. Do I have some configuration issues, or is there some reason I can no longer use the *inferior-lisp* buffer for direct entry of lisp commands? I'm using emacs 23.4.1 and sbcl-1.13 if that's important. Paul Bowyer

2 8

Typos on SLIME tutorial
by Borja Tarraso 08 Apr '15

08 Apr '15

Hi, I was reading the SLIME tutorial and I found two typos. They are in the pdf (at least - did not check the other flavours like HTML that are online): Page 18 (13 from PDF file): just when it is explaining slime-compiler-macroexpand : where it says "Repeatedy expamd" -> should be "Repeatedly expand". Page 19 (14 from PDF file) just when it is explaining slime-inspector-operate-on-point : where it says "inspcetor" -> should be "inspector". Best regards, Borja Tarraso

2 1

Freeze for SLIME 2.5
by Luís Oliveira 08 Apr '15

08 Apr '15

Hello everyone, It's time for another freeze. Please focus on testing and fixing regressions since the last release. I plan to do the release dance either Sunday or Monday. Cheers, -- Luís Oliveira http://kerno.org/~luis/

1 0

slime-repl buffer
by Fabrice Popineau 08 Apr '15

08 Apr '15

Hi, Is there anyway to limit the size of the repl buffer ? Something like 10000 lines max for example. Emacs slows a lot with large buffers. Best regards, -- Fabrice Popineau ----------------------------- SUPELEC Département Informatique 3, rue Joliot Curie 91192 Gif/Yvette Cedex Tel direct : +33 (0) 169851950 Standard : +33 (0) 169851212 ------------------------------

4 7