I downloaded cusp source code and digged into it a little bit once. The problem is, I couldn't figure out quickly the detail of the swank client they implemented, nor did I figure out quickly the detail of the interface between slime and swank.
I wished there were already a client for swank written in clojure, but I couldn't find one. So, there is swank/slime to learn, and there is eclipse IDE plugin writing to learn. The former can be bypassed by doing something quick and not-so-dirty. The latter can't be bypassed ! So I made the choice to dot it iteratively, and concentrate on eclipse integration first. At the end of the day, I know I may well have finally faced all the problems the slime/swank protocol faced and solved them differently. But sometimes, you have to do the trip yourself to really understand what it is all about ! :-) On Jan 17, 8:03 pm, Matt Revelle <mreve...@gmail.com> wrote: > On Jan 17, 2009, at 1:47 PM, Peter Wolf wrote: > > > > > Sure, good idea. I'm in! > > > As a first cut, I think we need to separate those tools written in JVM > > languages (Clojure/Java) and those written in something else. > > > I certainly think the JVM based projects can, and should, share > > components. BTW the most important JVM project is Clojure itself. > > The > > tools should share as much as possible with the Clojure core sources. > > > Tools such as SLIME and (I think) Gorilla, on the other hand, are not > > written in language that makes sharing easy. > > This is not entirely correct. SLIME works by communicating with the > running Lisp process (in this case, Clojure), essentially all the > integration between Emacs/SLIME and Clojure is written in Clojure. > The component of SLIME that runs in the Lisp process is called SWANK. > > I recall that a Common Lisp plugin for Eclipse, CUSP, used swank so it > may be useful environments other than Emacs/SLIME. > > The main repo for swank-clojure > is:http://github.com/jochu/swank-clojure/tree/master > > > > > However, I would be very much in favor of a common test set. A > > collection of Clojure code that can be used to test tools, and ensure > > common behavior. These would be useful for all tools written in all > > languages. > > > My 2 cents > > P > > > Meikel Brandmeyer wrote: > >> Hi, > > >> Am 17.01.2009 um 16:22 schrieb Peter Wolf: > > >>> I think much of the parser, such as the JFlex lexer is certainly > >>> reusable. The recursive descent parser outputs Intellij objects, > >>> but > >>> with pretty minor changes could be made reuseable. > > >>> Please feel free to take anything you want. > > >>>http://code.google.com/p/clojure-intellij-plugin/source/browse/ > > >> There is lots of such things going at the moment. > > >> - Enclojure > >> - Clojuredev > >> - the IntelliJ Plugin > >> - the swank/SLIME/emacs thingy > >> - my Vim Gorilla > > >> Is there some interest to bundle the efforts? > > >> I'm thinking about a project, which provides such common > >> things, like the Parser mentioned above. Or Chouser's or > >> cgrand's javadoc. Everything in a neutral way, so that the > >> specific frontend projects just provide the interface to the > >> IDE in question and use the same backend functions. > > >> This would allow a faster development for the different > >> platforms, since re-inventing the wheel is not necessary. > > >> I don't know the requirements of the different platforms, > >> let alone how to implement all the features like refactoring > >> and stuff. So I don't even know, whether this is possible > >> or not. > > >> So what do you think? > > >> Sincerely > >> Meikel --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en -~----------~----~----~----~------~----~------~--~---
