Hey guys,
Marc and I have started work on adding support for Gambit to SLIME (http://common-lisp.net/project/slime/). We basically need to implement a fully functioning server (called a "swank" server) in Gambit to support all of the SLIME protocol.
Marc wrote the initial draft and I have fleshed it out. Basic support for a SLIME repl and debugging is available. You can get the project here:
http://github.com/jlongster/swank-gambit
I think it'd be great if everyone worked on this together. There are many more commands that need to be implemented (completions, better debugging, etc.) and if we could get this fully implemented, it would be a huge benefit for Gambit. SLIME is really an incredible development environment and I think a lot more people would choose Gambit with SLIME support.
To use it, fire it up in a terminal like so:
$ gsi -:dar swank-gambit.scm
The "-:dar" option just makes sure that you see any errors that happen in any threads.
Now connect to it in Emacs:
M-x slime-connect <ENT> <ENT> <ENT>
And you should see a SLIME REPL if you activated the slime-repl library when you set it up. You should have done something like this when installing SLIME:
(slime-setup 'slime-repl)
SLDB is SLIME's debugger, and it will pop up if an error occurs, but many of the debugging commands haven't been implemented yet.
You can embed the server wherever you like. I'm debugging my Gambit Scheme iPhone games using SLIME, which is neat.
*** QUESTION FOR SLIME USERS ***
I'm currently wrestling with what to do with program output from any thread. How do most SLIME backends handle it? I've sketched out an implementation which sends all output to the SLIME REPL. It's a little rough, but it seems to work. What would be the SLIME philosophy?
Please let me know if you want to start hacking on this with us!
- James
Afficher les réponses par date
On Jan 16, 2010, at 1:54 PM, James Long wrote:
Marc and I have started work on adding support for Gambit to SLIME (http://common-lisp.net/project/slime/). We basically need to implement a fully functioning server (called a "swank" server) in Gambit to support all of the SLIME protocol. [...] SLIME is really an incredible development environment and I think a lot more people would choose Gambit with SLIME support.
Very cool!
I adapted the MCLIDE swank client <mclide.in-progress.com> to connect to the Gambit swank server. Enclosed is a screen shot of the MCLIDE listener in action with Gambit as the target lisp. Consider it a preview of what's to come...
-- Terje Norderhaug terje@in-progress.com
On Jan 16, 2010, at 1:54 PM, James Long wrote:
Marc and I have started work on adding support for Gambit to SLIME (http://common-lisp.net/project/slime/). We basically need to implement a fully functioning server (called a "swank" server) in Gambit to support all of the SLIME protocol.
Marc wrote the initial draft and I have fleshed it out. Basic support for a SLIME repl and debugging is available. You can get the project here:
http://github.com/jlongster/swank-gambit
I think it'd be great if everyone worked on this together. There are many more commands that need to be implemented (completions, better debugging, etc.) and if we could get this fully implemented, it would be a huge benefit for Gambit. SLIME is really an incredible development environment and I think a lot more people would choose Gambit with SLIME support.
Please let me know if you want to start hacking on this with us!
I am implementing a Gambit counterpart to the swank-rpc module that I recently added to the Common Lisp swank server of the SLIME project. This module provides a symmetric RPC layer to pass remote calls and responses between lisp systems, implementing the foundation for the swank protocol.
One of my main reasons for advocating the addition of a swank-rpc module in Slime/Swank was to facilitate alternative swank servers such as swank-gambit. The module includes a validating reader that defines the syntax of the swank RPC protocol.
PS: I am using the swank-gambit server itself when implementing the swank-rpc.scm module, hooked up with MCLIDE as swank client / development environment!
-- Terje Norderhaug terje@in-progress.com
On Sun, Jan 17, 2010 at 10:54 AM, James Long longster@gmail.com wrote:
*** QUESTION FOR SLIME USERS ***
I'm currently wrestling with what to do with program output from any thread. How do most SLIME backends handle it? I've sketched out an implementation which sends all output to the SLIME REPL. It's a little rough, but it seems to work. What would be the SLIME philosophy?
I'm not a SLIME user but I just happened upon this, it sounds relevant.
http://common-lisp.net/project/slime/doc/html/Global-IO-Redirection.html#Glo...
Terje - I will take a look at your work, sounds cool. It sounds like you know a lot about the swank protocol, so you'll definitely be good for swank-gambit. I'll check out your RPC layer to see what you're doing!
On Thu, Feb 11, 2010 at 5:41 AM, Julian Scheid julians37@googlemail.comwrote:
I'm not a SLIME user but I just happened upon this, it sounds relevant.
http://common-lisp.net/project/slime/doc/html/Global-IO-Redirection.html#Glo...
Thanks Julian. I've been doing a good bit of Clojure work under SLIME and have found `M-x slime-redirect-inferior-output` which actually switches all inferior output to the REPl. I'm not sure why those docs don't say that.
On Sun, Jan 17, 2010 at 10:54 AM, James Long longster@gmail.com wrote:
I think it'd be great if everyone worked on this together. There are many more commands that need to be implemented (completions, better debugging, etc.) and if we could get this fully implemented, it would be a huge benefit for Gambit. SLIME is really an incredible development environment and I think a lot more people would choose Gambit with SLIME support.
Just a heads up, I've started implementing swank:simple-completions (for tab completion) and swank:frame-locals-and-catch-tags (for being able to use the t key in the backtrace to display frame local data).
I'll publish my work-in-progress when you've added the license.
Julian
On Feb 11, 2010, at 11:28 PM, Julian Scheid wrote:
On Sun, Jan 17, 2010 at 10:54 AM, James Long longster@gmail.com wrote:
I think it'd be great if everyone worked on this together. There are many more commands that need to be implemented (completions, better debugging, etc.) and if we could get this fully implemented, it would be a huge benefit for Gambit. SLIME is really an incredible development environment and I think a lot more people would choose Gambit with SLIME support.
Just a heads up, I've started implementing swank:simple-completions (for tab completion) and swank:frame-locals-and-catch-tags (for being able to use the t key in the backtrace to display frame local data).
I'll publish my work-in-progress when you've added the license.
This is good news. Checking out the value of local bindings is essential during debugging.
-- Terje Norderhaug terje@in-progress.com
On Mon, Feb 15, 2010 at 9:12 PM, Terje Norderhaug terje@in-progress.com wrote:
This is good news. Checking out the value of local bindings is essential during debugging.
I've also got the following, though some of it is still a bit rough-hewn:
inspector presentations support for debugging other threads pprint-eval-string-in-frame sldb-return-from-frame sldb-disassemble (without instruction pointer) and a few minor improvements and bugfixes.
I'm currently polishing the thread debugging and I plan to look into restarts and stepping after that.
Your RPC stuff is in the transport layer and not affected by any of this, right?
On Feb 15, 2010, at 1:29 AM, Julian Scheid wrote:
On Mon, Feb 15, 2010 at 9:12 PM, Terje Norderhaug <terje@in- progress.com> wrote:
This is good news. Checking out the value of local bindings is essential during debugging.
I've also got the following, though some of it is still a bit rough- hewn:
inspector presentations support for debugging other threads pprint-eval-string-in-frame sldb-return-from-frame sldb-disassemble (without instruction pointer) and a few minor improvements and bugfixes.
I'm currently polishing the thread debugging and I plan to look into restarts and stepping after that.
Your RPC stuff is in the transport layer and not affected by any of this, right?
Yes, all of this is on swank event level and only uses the rpc transport layer.
-- Terje Norderhaug terje@in-progress.com
On Mon, Feb 15, 2010 at 4:29 AM, Julian Scheid julians37@googlemail.com wrote:
On Mon, Feb 15, 2010 at 9:12 PM, Terje Norderhaug terje@in-progress.com wrote:
This is good news. Checking out the value of local bindings is essential during debugging.
I've also got the following, though some of it is still a bit rough-hewn:
Julian, this is wonderful. Do you plan to push these up to github soon now that the licenses are there? I may get motivated to help out with more work on this. I'd love to try out your improvements!
- James
-
James Long -
Julian Scheid -
Terje Norderhaug