This is the mail archive of the
kawa@sourceware.org
mailing list for the Kawa project.
SLIME backend (was: help needed: Netbeans and/or Eclipse set-up for Kawa?)
- From: Helmut Eller <eller dot helmut at gmail dot com>
- To: kawa at sources dot redhat dot com
- Date: Wed, 28 May 2008 02:02:39 +0200
- Subject: SLIME backend (was: help needed: Netbeans and/or Eclipse set-up for Kawa?)
- References: <483C64C0.4050202@bothner.com>
* Per Bothner [2008-05-27 21:45+0200] writes:
> Note I'm talking about debugging Kawa itself, not Kawa applications.
> The latter would of course be really great! There is some support
> for Eclipse using SchemeWay.
I'll take this opportunity to advertise my SLIME backend for Kawa a bit.
Please skip the rest of this message if you don't use Emacs.
SLIME is an Emacs mode which communicates with an external Lisp process
to implement IDE-like features like symbol-completion, an
object-inspector and a debugger. SLIME's primary target are various
Common Lisps but since the communication runs over a tcp socket it's
possible to use any server that implements the protocol. The Emacs-side
commands are probably only useful for a Lisp-like language, though.
SLIME's homepage is: http://www.common-lisp.net/project/slime
The Kawa server is only available in the CVS version.
At the beginning of the file contrib/swank-kawa.scm are some
installation instructions.
The debugger is implemented via the Java Debug Interface (JDI), but is
supposed to be used in a 'debug-on-error' fashion i.e. the debugger pops
up when an uncaught exception occurs. The 'jump-to-source' and
'show-local-variables' commands work but breakpoint and stepping commands
aren't implemented.
Highlights of the Kawa server:
* M-. command works (almost)
* REPL works (no value history, though)
* Symbol completion (based on current environment)
* Inspector works (problems with long arrays)
* Disassemble command works (for simple cases)
* Interrupting endless loops works (only sometimes)
Lowlights:
* Macro expansion commands are useless
* Incremental compilation (C-c C-c) doesn't interact well with modules
* Attaching the debugger slows the entire JVM down (considerably)
* no support for multiple threads
* swank-kawa.scm is written in a perverse style
* the JVM ain't a Lisp Machine (and never will be)
Helmut.