[armedbear-devel] Embedding ABCL into IntelliJ IDEA and writing plugins
Hello, I created IntelliJ IDEA plugin that embeds ABCL, allows to connect from SLIME and extend IDEA using Common Lisp. I haven't contrived any useful functionality (that is easy to implement), therefore, for the sake of example, the plugin ads to IDEA commands yank and yank-pop, like in Emacs. Source may be found here: http://github.com/avodonosov/abcl-idea/tree/master Binary distro: http://cloud.github.com/downloads/avodonosov/abcl-idea/abcl-idea.zip There is a readme, check it for more details. Some conclusions from my experience: - it is absolutely possible to create IDEA plugins using ABCL. - Jfli interface to java is currently more convenient than native ABCL's - ABCL's performance of slime fuzzy-completion is still unsatisfying (it is the only little unsatisfying thing for me) - ABCL is more suited to be embedded into J editor, than into something else. For example Interpreter.kill method stops ABCL like: if (jlisp) { ... close input output streams } else System.exit(status); I.e. if we call Interpretter.kill() in IDEA plugin, it will exit whose IDEA process This is not a big problem, because with having Interpreter source code we may But having source code we can copy/past desirable kill behavior - closing streams. But it would make sense to reactor it a little to be more embedding friendly. If somebody is interested to write IDEA plugins in Lisp, my plugin may be used as a basis for further extension. Best regards, - Anton
On Wed, Aug 19, 2009 at 11:24 PM, Anton Vodonosov<avodonosov@yandex.ru> wrote:
Hello,
I created IntelliJ IDEA plugin that embeds ABCL, allows to connect from SLIME and extend IDEA using Common Lisp.
I haven't contrived any useful functionality (that is easy to implement), therefore, for the sake of example, the plugin ads to IDEA commands yank and yank-pop, like in Emacs.
Very nice! I happen to have a copy of IDEA available, so I'll do some experiments :)
Source may be found here: http://github.com/avodonosov/abcl-idea/tree/master Binary distro: http://cloud.github.com/downloads/avodonosov/abcl-idea/abcl-idea.zip
There is a readme, check it for more details.
Some conclusions from my experience:
- it is absolutely possible to create IDEA plugins using ABCL. - Jfli interface to java is currently more convenient than native ABCL's
The native ABCL interface to Java is indeed very verbose; I consider it to be a low-level api on which more user-friendly FFIs can be implemented.
- ABCL's performance of slime fuzzy-completion is still unsatisfying (it is the only little unsatisfying thing for me) - ABCL is more suited to be embedded into J editor, than into something else. For example Interpreter.kill method stops ABCL like:
if (jlisp) { ... close input output streams } else System.exit(status);
I.e. if we call Interpretter.kill() in IDEA plugin, it will exit whose IDEA process
Keep in mind that, in general, the ABCL interpreter is a singleton, and "killing" it is not that easy: besides open streams, other data is kept around so reverting the interpreter to a clean state is quite complicated. Why are you trying to kill it in the first place?
This is not a big problem, because with having Interpreter source code we may But having source code we can copy/past desirable kill behavior - closing streams. But it would make sense to reactor it a little to be more embedding friendly.
If somebody is interested to write IDEA plugins in Lisp, my plugin may be used as a basis for further extension.
Best regards, - Anton
_______________________________________________ armedbear-devel mailing list armedbear-devel@common-lisp.net http://common-lisp.net/cgi-bin/mailman/listinfo/armedbear-devel
Hello Alessio, on Thursday, August 20, 2009, 12:45:44 PM Alessio wrote:
- ABCL is more suited to be embedded into J editor, than into something else. For example Interpreter.kill method stops ABCL like:
if (jlisp) { ... close input output streams } else System.exit(status);
I.e. if we call Interpretter.kill() in IDEA plugin, it will exit whose IDEA process
Keep in mind that, in general, the ABCL interpreter is a singleton, and "killing" it is not that easy: besides open streams, other data is kept around so reverting the interpreter to a clean state is quite complicated.
I think if streams are closed, it will stop read-eval-print loop. There is a static method Interpreter.dispose() which assigns the static field "interpreter" to null. Therefore I hope everything will be garbage collected.
Why are you trying to kill it in the first place?
Well, for example I want restart Lisp without closing IDEA. Or just to stop Lisp if I don't need it anymore. It was only example of where ABCL is more suited for J editor than to anything else. Another example is method Interpreter.createJLispInstance. It accepts input/output streams. For non J editor case, there is no factory method with input/output stream parameters. But, as I said, it's a minor problem. Best regards, - Anton
On Sun, Aug 23, 2009 at 2:54 AM, Anton Vodonosov<avodonosov@yandex.ru> wrote:
Hello Alessio,
on Thursday, August 20, 2009, 12:45:44 PM Alessio wrote:
- ABCL is more suited to be embedded into J editor, than into something else. For example Interpreter.kill method stops ABCL like:
if (jlisp) { ... close input output streams } else System.exit(status);
I.e. if we call Interpretter.kill() in IDEA plugin, it will exit whose IDEA process
Keep in mind that, in general, the ABCL interpreter is a singleton, and "killing" it is not that easy: besides open streams, other data is kept around so reverting the interpreter to a clean state is quite complicated.
I think if streams are closed, it will stop read-eval-print loop. There is a static method Interpreter.dispose() which assigns the static field "interpreter" to null. Therefore I hope everything will be garbage collected.
There is data in static fields too, and that won't be garbage collected. If some piece of this data holds reference to a symbol, which in turn references a package, which references other symbols, which can point to top-level variables, functions, CLOS classes, ... a whole lot of state will be kept alive. I'm not saying that the interpreter cannot be killed, just that eliminating all the garbage might not be easy. However such "garbage" might not pose problems in practice, I don't know.
Why are you trying to kill it in the first place?
Well, for example I want restart Lisp without closing IDEA. Or just to stop Lisp if I don't need it anymore.
It was only example of where ABCL is more suited for J editor than to anything else. Another example is method Interpreter.createJLispInstance. It accepts input/output streams.
For non J editor case, there is no factory method with input/output stream parameters.
There's a system function, system::top-level-loop IIRC, which implements the REPL and takes in and out streams as parameters; it might be what you want. (note that afaik closing the streams makes this function throw an exception).
But, as I said, it's a minor problem.
Maybe, but since embedding ABCL in Java applications is an important use case for ABCL, I think that we should make it as easy as possible: feel free to report any problem you have, however minor it is. Cheers, Alessio
It was only example of where ABCL is more suited for J editor than to anything else. Another example is method Interpreter.createJLispInstance. It accepts input/output streams.
For non J editor case, there is no factory method with input/output stream parameters.
This problem plagued me. So I just added another method: public static synchronized Interpreter createLispInstance(InputStream in, OutputStream out, String initialDirectory) http://code.google.com/p/uabcl/source/detail?r=17
participants (3)
-
Alessio Stalla -
Anton Vodonosov -
dmiles＠users.sourceforge.net