[armedbear-devel] Lisp / Java interface utilities and examples
Greetings, Enclosed are the completed Lisp and Java utilities designed to make Lisp / Java interaction easier. It also includes an example / tutorial program. If it is appropriate, I'd like to have these added as one of the ABCL examples in the distribution. Also, if it is advantageous, perhaps we can move the Lisp and Java utilities to be part of ABCL. Thanks. Blake McBride
Hi Blake, On Sat, Jan 30, 2010 at 10:30 PM, Blake McBride <blake@mcbride.name> wrote:
Greetings,
Enclosed are the completed Lisp and Java utilities designed to make Lisp / Java interaction easier. It also includes an example / tutorial program. If it is appropriate, I'd like to have these added as one of the ABCL examples in the distribution. Also, if it is advantageous, perhaps we can move the Lisp and Java utilities to be part of ABCL.
Just writing to let you know this item is on my list of items to be followed up. However, I'm trying to finish up some other stuff before I'll be able to look at it. Thanks for your contribution! Bye, Erik.
2010/1/30 Blake McBride <blake@mcbride.name>:
Greetings, Enclosed are the completed Lisp and Java utilities designed to make Lisp / Java interaction easier. It also includes an example / tutorial program. If it is appropriate, I'd like to have these added as one of the ABCL examples in the distribution. Also, if it is advantageous, perhaps we can move the Lisp and Java utilities to be part of ABCL.
Looks good. I think the ABCL java class could benefit from a setter for the interpreter, and a getter, so that you could use it as a decorator. Wherever an instance of Interpreter is created, I think it's better to allow people to use that instance for other things Interpreter is capable of. I'd add the possibility to have per-ABCL-instance Interpreters, as well as the option of having a class instance. The utils.lisp stuff looks like it could well be added to our java.lisp, probably slightly tweaking the function names to follow the normal java.lisp conventions. Would you like to do such tweaks, or should I? :) Alessio, this is your familiar playground, any comments on these utils?
2010/2/2 Ville Voutilainen <ville.voutilainen@gmail.com>:
Looks good. I think the ABCL java class could benefit from a setter for the interpreter, and a getter, so that you could use it as a decorator. Wherever
We should obviously consider just adding the functionality into Interpreter.
On Tue, Feb 2, 2010 at 11:53 AM, Ville Voutilainen < ville.voutilainen@gmail.com> wrote:
Looks good. I think the ABCL java class could benefit from a setter for
2010/2/2 Ville Voutilainen <ville.voutilainen@gmail.com>: the
interpreter, and a getter, so that you could use it as a decorator. Wherever
We should obviously consider just adding the functionality into Interpreter.
I agree. I just didn't attempt it because a) I am unfamiliar with the code, and b) I thought that it might be a bit presumptuous in my part. Thanks. Blake
See comments in-line. On Tue, Feb 2, 2010 at 11:14 AM, Ville Voutilainen < ville.voutilainen@gmail.com> wrote:
2010/1/30 Blake McBride <blake@mcbride.name>:
Greetings, Enclosed are the completed Lisp and Java utilities designed to make Lisp / Java interaction easier. It also includes an example / tutorial program. If it is appropriate, I'd like to have these added as one of the ABCL examples in the distribution. Also, if it is advantageous, perhaps we can move the Lisp and Java utilities to be part of ABCL.
Looks good. I think the ABCL java class could benefit from a setter for the interpreter, and a getter, so that you could use it as a decorator. Wherever an instance of Interpreter is created, I think it's better to allow people to use that instance for other things Interpreter is capable of.
Agreed.
I'd add the possibility to have per-ABCL-instance Interpreters, as well as the option of having a class instance.
I was under the impression that, while you can have multiple ABCL threads, you can't have multiple instances of ABCL running. If this is true, however, I could use an instance version instead to support the future possibilities.
The utils.lisp stuff looks like it could well be added to our java.lisp, probably slightly tweaking the function names to follow the normal java.lisp conventions.
Agreed. I am now working on a Lisp function in which you pass the name of a Java class and it automatically creates the Lisp proxy functions for the entire class through Java reflection. I'll probably have that working today.
Would you like to do such tweaks, or should I? :)
Alessio, this is your familiar playground, any comments on these utils?
At any rate, lets hold off on integrating anything I sent so far since I am planning significant enhancements in the coming days. I do need to know about the multiple ABCL instance question though. Thanks. Blake On Tue, Feb 2, 2010 at 11:53 AM, Blake McBride <blake@mcbride.name> wrote:
See comments in-line.
On Tue, Feb 2, 2010 at 11:14 AM, Ville Voutilainen < ville.voutilainen@gmail.com> wrote:
Greetings, Enclosed are the completed Lisp and Java utilities designed to make Lisp / Java interaction easier. It also includes an example / tutorial
2010/1/30 Blake McBride <blake@mcbride.name>: program.
If it is appropriate, I'd like to have these added as one of the ABCL examples in the distribution. Also, if it is advantageous, perhaps we can move the Lisp and Java utilities to be part of ABCL.
Looks good. I think the ABCL java class could benefit from a setter for the interpreter, and a getter, so that you could use it as a decorator. Wherever an instance of Interpreter is created, I think it's better to allow people to use that instance for other things Interpreter is capable of.
Agreed.
I'd add the possibility to have per-ABCL-instance Interpreters, as well as the option of having a class instance.
I was under the impression that, while you can have multiple ABCL threads, you can't have multiple instances of ABCL running. If this is true, however, I could use an instance version instead to support the future possibilities.
The utils.lisp stuff looks like it could well be added to our java.lisp, probably slightly tweaking the function names to follow the normal java.lisp conventions.
Agreed. I am now working on a Lisp function in which you pass the name of a Java class and it automatically creates the Lisp proxy functions for the entire class through Java reflection. I'll probably have that working today.
Would you like to do such tweaks, or should I? :)
Alessio, this is your familiar playground, any comments on these utils?
2010/2/2 Blake McBride <blake@mcbride.name>:
At any rate, lets hold off on integrating anything I sent so far since I am planning significant enhancements in the coming days. I do need to know
Ok, cool.
about the multiple ABCL instance question though.
Ah, right.. Interpreter has the createInstance function, which is probably the only way to create an Interpreter. Thus it's not possible to have multiple interpreters I think.
On Tue, Feb 2, 2010 at 12:22 PM, Ville Voutilainen < ville.voutilainen@gmail.com> wrote:
2010/2/2 Blake McBride <blake@mcbride.name>:
At any rate, lets hold off on integrating anything I sent so far since I am planning significant enhancements in the coming days. I do need to know
Ok, cool.
about the multiple ABCL instance question though.
Ah, right.. Interpreter has the createInstance function, which is probably the only way to create an Interpreter. Thus it's not possible to have multiple interpreters I think.
And the small advantage of using a class variable (and the reason I did it that way) is that the user doesn't have to carry around a reference to the instance.
2010/2/2 Blake McBride <blake@mcbride.name>:
And the small advantage of using a class variable (and the reason I did it that way) is that the user doesn't have to carry around a reference to the instance.
Yeah, I was thinking of cases where the user creates the instance separately, but in that case Intepreter.createInstance() will return that same instance for the ABCL class. And if the ABCL class creates it first, createInstance will again return the same instance for the user. So it's not significant. Probably not even worth changing at all, now that I think about it. I do think we can just add the functionality of ABCL to Interpreter.
On Tue, Feb 2, 2010 at 6:14 PM, Ville Voutilainen <ville.voutilainen@gmail.com> wrote:
2010/1/30 Blake McBride <blake@mcbride.name>:
Greetings, Enclosed are the completed Lisp and Java utilities designed to make Lisp / Java interaction easier. It also includes an example / tutorial program. If it is appropriate, I'd like to have these added as one of the ABCL examples in the distribution. Also, if it is advantageous, perhaps we can move the Lisp and Java utilities to be part of ABCL.
Looks good. I think the ABCL java class could benefit from a setter for the interpreter, and a getter, so that you could use it as a decorator. Wherever an instance of Interpreter is created, I think it's better to allow people to use that instance for other things Interpreter is capable of. I'd add the possibility to have per-ABCL-instance Interpreters, as well as the option of having a class instance.
The utils.lisp stuff looks like it could well be added to our java.lisp, probably slightly tweaking the function names to follow the normal java.lisp conventions.
Would you like to do such tweaks, or should I? :)
Alessio, this is your familiar playground, any comments on these utils?
The Java utils for what I can see are a subset of what is already there in AbclScriptEngine, with the difference that - iirc - the script engine automatically calls javaInstance() on the returned objects, so you don't have the possibility to access "raw" Lisp objects (e.g. calling a function that returns a Fixnum will return an Integer instead). The lisp utils could be handy, but I'd prefer to call jmethod, jclass and similar during macroexpansion and including the results in the expanded code; this way no method/class reflective lookup will be done at runtime. For maximum safety, it would be even better to fall back to calling jmethod in the expansion, and warn, if method resolution fails at compile time. Wrt. multiple Interpreter instances, it's not entirely true that you can only have one; you can use two different, unrelated classloaders to load two copies of ABCL. It's true that, in that case, interacting with them with code from yet another classloader (say, a manager thread), will be harder and slower, as you can only use reflection; but if you just want two or more independent ABCLs, that can be the way to go. hth, Alessio
participants (4)
-
Alessio Stalla -
Blake McBride -
Erik Huelsmann -
Ville Voutilainen