[armedbear-devel] Several ABCL/Java questions
Hello, I'm trying to port Clon[1] to ABCL, or at least figure out whether it makes sense at all. My Java programming experience boils down to a Hello World program 10 years ago or so, so some questions belong to the Java side of ABCL for sure :-). I would be grateful if somebody can help me answer these. 1/ Is it possible to create standalone ABCL executables and how ? 2/ ABCL doesn't seem to provide a [set|put]env function. From what I can gather from the internet, that would be because there's no such thing in Java. I've seen some nasty tricks around consisting in modifying the (application-local) initial memory mapping of the environment, but that's all. Is this correct ? 3/ It seems that ABCL does not have a complete MOP. In particular, I couldn't find a validate-superclass function. Is this correct ? Does this mean that classes/superclasses are implicitely "validated" ? 4/ There is a place where I need to access low-level information about a stream in order to figure out whether it's connected to a tty, and in that case, what's the tty line-width. In other implementations, I have native support (or cffi support in the case of CLISP) for calling ioctl with the TIOCGWINSZ argument. It either gets me the tty line width or throws me an ENOTTY error in the face which is fine. How can I do something similar in ABCL ? Thank you very much ! Footnotes: [1] http://www.lrde.epita.fr/~didier/software/lisp/clon.php -- Resistance is futile. You will be jazzimilated. Scientific site: http://www.lrde.epita.fr/~didier Music (Jazz) site: http://www.didierverna.com
On Tue, Jan 4, 2011 at 10:28 AM, Didier Verna <didier@lrde.epita.fr> wrote:
Hello,
I'm trying to port Clon[1] to ABCL, or at least figure out whether it makes sense at all. My Java programming experience boils down to a Hello World program 10 years ago or so, so some questions belong to the Java side of ABCL for sure :-). I would be grateful if somebody can help me answer these.
1/ Is it possible to create standalone ABCL executables and how ?
I'd say no, but it really depends on what you mean. You can't create standalone executables in Java, the equivalent is a bunch of Jar files (for console or GUI applications). It is possible to package ABCL + your software as a bunch of Jar files, but ABCL doesn't provide facilities of its own for that, though it's not hard to do (you can look at ABCL's own build script to get an idea). ABCL has no facilities for dumping a memory image, either (memory being controlled by the JVM makes this hard).
2/ ABCL doesn't seem to provide a [set|put]env function. From what I can gather from the internet, that would be because there's no such thing in Java. I've seen some nasty tricks around consisting in modifying the (application-local) initial memory mapping of the environment, but that's all. Is this correct ?
I'd say yes, it's correct. But what are you trying to achieve? If you want to provide an environment for a subprocess, the ProcessBuilder class supports it. If you want to modify your own environment, you can't (without resorting to FFI, as far as I know), but why do you want to do that?
3/ It seems that ABCL does not have a complete MOP. In particular, I couldn't find a validate-superclass function. Is this correct ? Does this mean that classes/superclasses are implicitely "validated" ?
It doesn't have a complete MOP. I think that validation is performed on an ad-hoc basis (e.g. you can't extend structure classes), so every other case is implicitly validated.
4/ There is a place where I need to access low-level information about a stream in order to figure out whether it's connected to a tty, and in that case, what's the tty line-width. In other implementations, I have native support (or cffi support in the case of CLISP) for calling ioctl with the TIOCGWINSZ argument. It either gets me the tty line width or throws me an ENOTTY error in the face which is fine.
How can I do something similar in ABCL ?
I don't know. ABCL streams wrap java.io streams and readers/writers and I don't think there's a mean of accessing their low-level implementation. Perhaps with a dedicated library that uses JNI/JNA and provides custom streams, but I don't know any. Terminal handling is not common in Java (as most OS-specific stuff). hth, Alessio
On 1/4/11 11:25 , Alessio Stalla wrote:
On Tue, Jan 4, 2011 at 10:28 AM, Didier Verna<didier@lrde.epita.fr> wrote:
2/ ABCL doesn't seem to provide a [set|put]env function. From what I can gather from the internet, that would be because there's no such thing in Java. I've seen some nasty tricks around consisting in modifying the (application-local) initial memory mapping of the environment, but that's all. Is this correct ?
I'd say yes, it's correct. But what are you trying to achieve?
Access to reading environment variables to the JVM process is available by the function on the EXT:GETENV symbol. When spawning sub-process, one can use the ProcessBuilder interface Alessio described. Low level stuff for which you know the local system analogs via ANSI C linkage would be well served by using CFFI to wrap calls to [abcl-cffi-jna][]. We have a [putative patch to run JNA with the callbacks made possible via constructing the necessary Java interfaces on-the-fly made possible on abcl-0.24-dev][1] that we welcome feedback on esp. wrt. improving the ABCL system interfaces. [abcl-cffi-jna]: http://trac.common-lisp.net/armedbear/wiki/asdf/cffi [1]: http://slack.net/~evenson/abcl/cffi-abcl-20101231a.diff -- "A screaming comes across the sky. It has happened before, but there is nothing to compare to it now."
On 4 January 2011 13:05, Mark Evenson <evenson@panix.com> wrote:
Low level stuff for which you know the local system analogs via ANSI C linkage would be well served by using CFFI to wrap calls to [abcl-cffi-jna][]. We have a [putative patch to run JNA with the callbacks made possible via constructing the necessary Java interfaces on-the-fly made possible on abcl-0.24-dev][1] that we welcome feedback on esp. wrt. improving the ABCL system interfaces.
It would surely be neat to have an example of cffi/jna.
Hi Alessio, thanks for your reply. Alessio Stalla <alessiostalla@gmail.com> wrote:
1/ Is it possible to create standalone ABCL executables and how ?
I'd say no, but it really depends on what you mean. You can't create standalone executables in Java, the equivalent is a bunch of Jar files (for console or GUI applications). It is possible to package ABCL + your software as a bunch of Jar files, but ABCL doesn't provide facilities of its own for that, though it's not hard to do (you can look at ABCL's own build script to get an idea). ABCL has no facilities for dumping a memory image, either (memory being controlled by the JVM makes this hard).
OK, so here's where I am right now: Clon is a command-line option parser library so it's essentially targetted at standalone executables. However, I see that you can do something like that: java -jar myapp.jar --myapp-opt-1 --myapp-other-opt ... and get the command-line arguments from *command-line-argument-list* so it probably still makes sense to port Clon to ABCL. The next question is: how do I hook an initial "main" function into myapp.jar. I seem to remember that you need a Main class in Java, but I'm not sure about the Lisp level.
2/ ABCL doesn't seem to provide a [set|put]env function.
I'd say yes, it's correct. But what are you trying to achieve? If you want to provide an environment for a subprocess, the ProcessBuilder class supports it. If you want to modify your own environment, you can't (without resorting to FFI, as far as I know), but why do you want to do that?
In Clon, command-line options may be associated with environment variables providing implicit values. In case such a variable contains a typo (for instance DEBUG=ys instead of DEBUG=yes), Clon provides a restart for fixing that interactively, which can benefit to the current process but also subsequent ones launched from the same terminal. I guess I can just disable this restart in the ABCL version.
3/ It seems that ABCL does not have a complete MOP.
It doesn't have a complete MOP. I think that validation is performed on an ad-hoc basis (e.g. you can't extend structure classes), so every other case is implicitly validated.
OK.
4/ There is a place where I need to access low-level information about a stream
I don't know. ABCL streams wrap java.io streams and readers/writers and I don't think there's a mean of accessing their low-level implementation. Perhaps with a dedicated library that uses JNI/JNA and provides custom streams, but I don't know any. Terminal handling is not common in Java (as most OS-specific stuff).
OK :-/ Thanks again. -- Resistance is futile. You will be jazzimilated. Scientific site: http://www.lrde.epita.fr/~didier Music (Jazz) site: http://www.didierverna.com
On Tue, Jan 4, 2011 at 12:20 PM, Didier Verna <didier@lrde.epita.fr> wrote:
Hi Alessio, thanks for your reply.
Alessio Stalla <alessiostalla@gmail.com> wrote:
1/ Is it possible to create standalone ABCL executables and how ?
I'd say no, but it really depends on what you mean. You can't create standalone executables in Java, the equivalent is a bunch of Jar files (for console or GUI applications). It is possible to package ABCL + your software as a bunch of Jar files, but ABCL doesn't provide facilities of its own for that, though it's not hard to do (you can look at ABCL's own build script to get an idea). ABCL has no facilities for dumping a memory image, either (memory being controlled by the JVM makes this hard).
OK, so here's where I am right now: Clon is a command-line option parser library so it's essentially targetted at standalone executables. However, I see that you can do something like that:
java -jar myapp.jar --myapp-opt-1 --myapp-other-opt ...
and get the command-line arguments from *command-line-argument-list* so it probably still makes sense to port Clon to ABCL. The next question is: how do I hook an initial "main" function into myapp.jar. I seem to remember that you need a Main class in Java, but I'm not sure about the Lisp level.
You do need one. You can either use ABCL's one - in that case you have to pass something like --eval "(your-main-function)", perhaps with a shell script - or write a custom one in Java that will call the right Lisp function.
2/ ABCL doesn't seem to provide a [set|put]env function.
I'd say yes, it's correct. But what are you trying to achieve? If you want to provide an environment for a subprocess, the ProcessBuilder class supports it. If you want to modify your own environment, you can't (without resorting to FFI, as far as I know), but why do you want to do that?
In Clon, command-line options may be associated with environment variables providing implicit values. In case such a variable contains a typo (for instance DEBUG=ys instead of DEBUG=yes), Clon provides a restart for fixing that interactively, which can benefit to the current process but also subsequent ones launched from the same terminal. I guess I can just disable this restart in the ABCL version.
Ok, yes you can disable it, or implement it by calling an external command to set the variable (that will only be seen by subsequent processes, though).
4/ There is a place where I need to access low-level information about a stream
I don't know. ABCL streams wrap java.io streams and readers/writers and I don't think there's a mean of accessing their low-level implementation. Perhaps with a dedicated library that uses JNI/JNA and provides custom streams, but I don't know any. Terminal handling is not common in Java (as most OS-specific stuff).
OK :-/
In fact, I think a lot of criticism Lisp receives for not being integrated enough with the OS, etc. would apply twice as much for Java, yet nobody seems to notice :P
Alessio Stalla <alessiostalla@gmail.com> wrote:
You do need one. You can either use ABCL's one - in that case you have to pass something like --eval "(your-main-function)", perhaps with a shell script - or write a custom one in Java that will call the right Lisp function.
Where can I find the exact list of understood command-line arguments ? -- Resistance is futile. You will be jazzimilated. Scientific site: http://www.lrde.epita.fr/~didier Music (Jazz) site: http://www.didierverna.com
On 4 January 2011 15:12, Didier Verna <didier@lrde.epita.fr> wrote:
Where can I find the exact list of understood command-line arguments ?
http://trac.common-lisp.net/armedbear/wiki/CommandLineArguments
Alessio Stalla <alessiostalla@gmail.com> wrote:
You do need one. You can either use ABCL's one - in that case you have to pass something like --eval "(your-main-function)", perhaps with a shell script - or write a custom one in Java that will call the right Lisp function.
Here's the closest thing I have to "standalone" ABCL executables so far. Comments welcome (remember: I don't know Java). Main.java: | import org.armedbear.lisp.*; | | public class Main | { | public static void main (String[] argv) | { | try | { | LispObject cmdline = Lisp.NIL; | for (String arg : argv) | cmdline = new Cons (arg, cmdline); | cmdline.nreverse (); | Lisp._COMMAND_LINE_ARGUMENT_LIST_.setSymbolValue (cmdline); | | Interpreter interpreter = Interpreter.createInstance (); | // load a lisp file like main.lisp or so. | } | catch (Throwable t) | { | t.printStackTrace (); | } | } | } javac -cp /usr/local/pkg/common-lisp/abcl/\* Main.java java -cp /usr/local/pkg/common-lisp/abcl/\*:. Main [options...] And now from that interpreter (in fact, its #'main function), *command-line-argument-list* contains the list of [options...], with the notable effect that none of them are processed by, or affect ABCL itself. Two remarks: - I can also provide my own jar file, only it seems painful to do because I would have to uncompress abcl.jar to get all its contents and then create my own by adding Main.class to it. I've seen threads dating back to 2007 about adding jar files to jar files directly but it seems that it still doesn't work the way I want it to (accessing the sub-jar's contents). Correct? - A cleaner way to do the above would have been to extend the Interpreter class by adding a new method, e.g. createStandaloneInstance, as a mixture of createDefaultInstance and createInstance. Unfortunately, this is not possible because this class is final. -- Resistance is futile. You will be jazzimilated. Scientific site: http://www.lrde.epita.fr/~didier Music (Jazz) site: http://www.didierverna.com
participants (4)
-
Alessio Stalla -
Didier Verna -
Mark Evenson -
Ville Voutilainen