LIsp Framework for Testing
Common Lisp reader heredoc dispatcher
Hyperobject is a Object Representation package for development. It emphasizes object printing in ASCII text, HTML, and XML formats both with and without field labels and hyperlinks to related objects.Hyperobject is supported on:
A library for manipulating dates and times, based on a paper by Erik Naggum
SLIME is the Superior Lisp Interaction Mode for Emacs. This is an ILISP-like development environment intended for maximum integration with CMUCL (also works with SBCL, OpenMCL and work is ongoing on Lispworks and current CVS version of CLISP and CLISP 2.32 on Linux; there is also support packaged separately for Scheme48, called SLIME48).SLIME is now stable and released. Please download the latest version from its home page. Documentation is included there.
NOTE: slime-2.0 is too old for use with current versions of SBCL. Fetch slime from CVS.Want to try SLIME? Check out the SLIME-HOWTO or read about the SLIME Features. You can also check out some SLIME Tips.Users are invited to post feature suggestions on this page.
Ability to pin certain things (arglist info, debugger, repl) into dedicated frames for nice multi-window operation -- Zach
Make the slime faces inherit from the standard font-lock faces when appropriate (eg making the REPL output face inherit from font-lock-comment-face) -- Brian
Note: Although it is possible to connect to a Lisp on a remote machine, we haven't yet figured out what does and doesn't work without a shared filesystem. Maybe this can be made tramp-aware? -- Rahul Jain Clear *use-dedicated-output-stream* before connecting works for me so far. -- ngps
Autodetection of LINEDIT (or other random REPL wrappers) and calling LINEDIT's UNINSTALL-REPL before running SWANK. I tried to add something in slime-maybe-start-lisp in slime.el to do so, but comint-proc-query was uncooperative and kept hanging. -- James A. Crippen
Some REPL conveniences, such as ILISP's C-z P (set package).
The SLIME equivalent of the latter is
SLIME-REPL-SET-PACKAGE, anything else?
Some way to get a REPL in the current debugger frame, for more serious
playing around I second the motion. It would be very useful to keep a record
of what was evaluated and what printed, sort of like a
... read-eval-print loop! It's amazing that this crucial feature of
Lisp was discarded in the SLIME model; its absence really detracts from
Drew McDermott -- 2005-12-09.
I would also very much like this feature! -Lars Rune NÃ¸stdal
Working symbol-completion when you enter expressions in the mini-buffer
"Getting ILISP working was a nightmare. Getting SLIME working was a breeze, even though I had to check it out of CVS" (Steve Jenson, saladwithsteve.com)
If your connection to ssh forwarded swank server doesnt work, try to (setf swank::*use-dedicated-output-stream* nil)
Maybe: Visit a file "through" the lisp process: slime instructs lisp process to open the file and squirt it across connection back to an emacs buffer. When buffer is saved in emacs, squirt back to lisp process. Potentially very nice for long-lived lisp server processes (provided your slimeswank is a secure channel!), and skirts the whole path-translations thing: the only correct path is the path the lisp process uses i.e. you're not doing C-xC-f emacs-file-path, you're doing C-cC-xC-f (or something saner) CL-file-path. (obviously, you'd provide tab completion for CL-file-path, too ;-) ) See the variable `file-name-handler-alist' for how you might want to do this.
How about unified directory access! I know there are some packages out there, but it would be wonderful to have this come with slime. It would be nice to have it as a part of the development environment. It's hard for me to switch between different implementations of CL otherwise. (for example, (:cd "dir") doesn't work when using SLIME with OpenMCL...) Update: I found directory functionality by typing a comma then entering 'cd' into the minibuffer. SLIME RULES!
It would be nice if I could have fixed Emacs windows for different SLIME buffers. Like, if I evaluate something and the debugger pops up, I never know where it's going to be (I usually have several Emacs frames and windows open). I would like to say "this will be the REPL window, and I want nothing else there" -- another window for the debugger, another for Lisp code etc. - You can kind of do this with the Emacs Code Browser, if you tell it the repl is a compilation window. It provides a fixed and togglable compilation window at the bottom of the first frame.
To add a note about using the standard font-lock faces, the keywords from the appropriate mode should also be used. That is, SLIME should use the lisp-mode-font-lock-keywords-... variables. I have diffrerent ones for Common Lisp, Scheme, and Emacs Lisp, so it would be nice to have this customizable for SLIME. Or better yet, since Emacs's default keywords for Lisp are pretty ELisp-centric maybe SLIME should provide its own set of Common Lisp--centric font-lock keywords, leaving the user to decide whether to copy those for Emacs's Lisp-mode or not. -- James A CrippenSounds a good idea to me. Can you post the code you use somewhere so we can use it as a basis? -- Luke GorrieSome responses..A "Recent Changes" popup: Can you elaborate a bit? The ChangeLog file + the mailing list is supposed to fill this role, but feedback about the effectiveness would be appreciated. -- Luke GorrieIt might be nice to just add a link to the latest ChangeLog in CVS, like so
Latest ChangeLog. Stick that on the project home page. -- James A Crippen Good idea. ChangeLog and mailing lists are now linked.Re: "Recent Changes Popup": Especially with the daily ChangeLog diff on the list, this is a solved problem for me at least. I suspect that people following
the CVS, but not the list deserve to lose (like I did...). OTOH: I can imagine having a busy month, then updating SLIME, and not noticing all the new goodies. ;) So in the bells and whistles department, SLIME offering to show it's own ChangeLog since last update would be kind of neat -- but definitely not a priority.As far as using slime remotely: if you have a shared filesystem but not with identical mountpoints, the patch included in this mail provides you with a M-x slime-replace-prefix function which causes a few uses of filenames to be translated (but only in the emacs->lisp direction).The full cygwin-windows cycle is translated by these hooks, working for any cygwin mountpoint. --ReiniUrbanThere is the beginnings of MP (threading) support in SLIME CVS. See the mailing list for detailsSlime DistributionsInformation, for fetching the source distribution, is available at the Slime homepage.For fetching Slime via cvs, information is available, also, at the Slime homepage.Debian packagesSlime has got an
official Debian package.It is under the non-free section of Debian mostly because of the license of one
file (xref.lisp). So, should it stay on CLiki.net? -- alceste@NOSPAM.muvara.orgMac OS X
A fink package for Mac OS X (10.3) is also available in fink's unstable tree.Slime is available in MacPorts, current port is based on 20110419 CVS snapshot.
Hunchentoot is a HTTP server based on USOCKET and
BORDEAUX-THREADS. It supports HTTP 1.1, serves static files, has a
simple framework for user-defined handlers and can be extended
CL-GTK2 is a Common Lisp GUI library that provides access to the Gtk+ cross-platform GUI library in idiomatic Lisp style.CL-GTK2 should portably work in most modern Lisps that support CFFI and MOP (works at least in SBCL, Clozure CL on Linux and Windows). Current version is 0.1.1 released on 2009.12.30.cl-gtk2 blog contains news on development of CL-GTK2. There is also a common-lisp.net website, with more documentation.CL-GTK2 is ASDF-installable (install the :CL-GTK2-GTK, :CL-GTK2-CAIRO and :CL-GTK2-GTKGLEXT systems).Requirements:
FFI with callbacks (via CFFI)
Threading (via Bordeaux-Threads)
Weak references (weak hash-tables) and finalizers (via Trivial-Garbage)
CLOS Metaobject Protocol (via Closer-MOP)
Provides Gtk+ API in a Lispy way
(Almost) Complete Gtk+ API
Objects and classes are mapped into CLOS objects and classes
Gtk+ objects are garbage collected
Error in objects' signal handlers are restartable
Provides some higher-level abstractions over Gtk+ facilities:
Calling code in GUI thread (call-within-main-loop, call-within-main-loop-and-wait)
Displaying progress-bar for long-running code (with-progress-bar)
Displaying errors (with-gtk-message-error-handler)
(defun run ()
(let ((output *standard-output*))
(let ((window (make-instance 'gtk:gtk-window
:title "Hello world!"
(button (make-instance 'gtk:button :label "Hello, world!"))
(gobject:g-signal-connect button "clicked"
(declare (ignore b))
(format output "Hello, world!~%")
(setf (gtk:button-label button)
"Hello, world! (clicked ~D times)"
(gtk:container-add window button)
(gtk:widget-show window :all t)))))
(defun demo-class-browser ()
(let ((output *standard-output*))
(let* ((window (make-instance 'gtk:gtk-window
:title "Class Browser"
(search-entry (make-instance 'gtk:entry))
(search-button (make-instance 'gtk:button :label "Search"))
(scroll (make-instance 'gtk:scrolled-window
(slots-model (make-instance 'gtk:array-list-store))
(slots-list (make-instance 'gtk:tree-view :model slots-model)))
(let ((v-box (make-instance 'gtk:v-box))
(search-box (make-instance 'gtk:h-box)))
(gtk:container-add window v-box)
(gtk:box-pack-start v-box search-box :expand nil)
(gtk:box-pack-start search-box search-entry)
(gtk:box-pack-start search-box search-button :expand nil)
(gtk:box-pack-start v-box scroll)
(gtk:container-add scroll slots-list))
(gtk:store-add-column slots-model "gchararray"
(format nil "~S" (closer-mop:slot-definition-name slot))))
(let ((col (make-instance 'gtk:tree-view-column :title "Slot name"))
(cr (make-instance 'gtk:cell-renderer-text)))
(gtk:tree-view-column-pack-start col cr)
(gtk:tree-view-column-add-attribute col cr "text" 0)
(gtk:tree-view-append-column slots-list col))
(labels ((display-class-slots (class)
(format output "Displaying ~A~%" class)
repeat (gtk:store-items-count slots-model)
do (gtk:store-remove-item slots-model (gtk:store-item slots-model 0)))
for slot in (closer-mop:class-slots class)
do (gtk:store-add-item slots-model slot)))
(declare (ignore button))
(let* ((class-name (read-from-string (gtk:entry-text search-entry)))
(class (find-class class-name)))
(gobject:g-signal-connect search-button "clicked" #'on-search-clicked))
Gtk GTK binding
Common Lisp Prevalence Package
Climacs is an Emacs-like text editor written in Common Lisp.It is a CLIM application. Its development resources are summarized at
its project page on common-lisp.net. As of July 2006, Climacs is a useful tool for writing Common Lisp code, but it does not have close integration with a REPL, debugger or inspector like SLIME. The CLIM-desktop project provides additional integration with Climacs into other applications (most notably the McCLIM Listener), but does not greatly enhance Climacs' capabilities for editing Common Lisp. Climacs can presently do parameter hinting, code evaluation, symbol completion, displaying of compiler notes and definition-editing.
Clouchdb is an interface to the CouchDb databases.Features include:
A lispy syntax for creating document views (thanks to Parenscript).
It supports CouchDb version 1.1.0 and newer, and it should be portable across Lisp implementations. It has currently been tested with SBCL and Clozure CL on Mac OSX Lion (64bit,Intel).License: BSDHomepage: http://common-lisp.net/project/clouchdb/Author: Peter Eddy
Isolated, reproducible virtual development environments.
Common Lisp bindings for the ncurses terminal library.
evol - entrenched virtues of lisp / love reversed. Multi-purpose build system.
Interface to GTK/Glib via CFFI
HH-Web is a library of Common Lisp code intended to simplify development of modern web applications.Features:
Content templates for consistent site structure (HTML and image)
Site customizations for specific user agents
Regex-based URL routing
Source repository: HH-WEB on Github.comLicense: MIT
Topics: web framework
The Lisa expert system shell
McCLIM is an implementation of the CLIM 2.0 specification.
Exploratory programming tool and documentation
A collection of tools to aid in development with CommonQt.
RESTAS is a Common Lisp web application framework, based
on the Hunchentoot HTTP server. It was developed to simplify development of
web applications following the REST architectural style.
A small Ajax framework for hunchentoot using parenscript
Stefil - Simple Test Framework In Lisp
UncommonWeb : Standard Components
Universal Foreign Function Library for Common Lisp