I was careful with this, but to double check I was being careful I went back read the documentation again, then because I was using a copy on my computer I went to the internet to check that version is the same. I think you are missing something its not inconsistent when you read the full explanation of the methods. May be the method names are confusing but as I said think of it from the java perspective and they read correctly.
Here is the link to the online version I used http://download.oracle.com/javase/6/docs/api/java/lang/Process.html.
My reading gives me:* getInputStream maps to standard output of the command being run and this method returns an InputStream.
* getErrorStream maps to standard error and returns an InputStream. * getOutputStream maps to standard input and returns an OutputStream.I think you are confusing the stream in the method name (eg. getInputStream being InputStream) and what it relates to. It doesn't relate to the command being run and its streams, it relates to the streams as seen by java code.
Michael Whapples On 08/12/10 18:07, qubit wrote:
Mike, as I pointed out, if you look closer, the return type for the input method should be an output stream for the java process, and the return type for the output methods should be input streams. The documentation specifies this inconsistently. It makes standard error of the subprocess go to an input stream (correctly), but the standard input of the subprocess goes to an input stream (wrong), and the standard output goes to an output stream (also bogus). The docs are wrong but also inconsistent, as they handle stderr one way and stdout another. Anyway, I note these are also abstract methods so I need to find class implementations that will handle whatever platform I am using. Honestly, I know how to do the pipe juggling in the process of spawning a child process, as I have done it before a number of times -- but in unix it is easy using fork and exec, but I am not shure what to call for windows, and for that matter, whether this differs between versions of windows. I also thought about the performance issue, so I may in the end go back and finish doing the jni, but I want to investigate this as well because it is cleaner and opens up the possibility of dropping in other spawned processes without much effort. --le ----- Original Message ----- From: "Michael Whapples"<mwhapples@xxxxxxx> To:<brailleblaster@xxxxxxxxxxxxx> Sent: Tuesday, December 07, 2010 7:10 PM Subject: [brailleblaster] Re: more on spawning processes Firstly that is good news for you on the family front and I hope it all goes well. Regarding using itex2mml, using pipes probably will work fine for actually getting the data, however I would imagine it will be much slower than using JNI. Basically be prepared if a bottleneck appears at that point to look at moving to JNI. In short what I am saying, try and make an interface to that part of the code which will be independent of how itex2mml is run (eg. don't have it that the command line flags are passed about more than necessary, may be have a different method for each way itex2mml will be called). There is no inconsistency regarding the streams of java.lang.Process. Reading the full documentation of those methods, getErrorStream relates to the processes STDERR stream, getInputStream relates to the processes STDOUT and getOutputStream relates to the processes STDIN. The methods are named for the perspective of the java application, I pass data out to the process and get data back in from the process. The application inside the process sees it the other way round. Michael Whapples On 07/12/10 23:17, qubit wrote:Wow, I'm just now this afternoon getting to the brailleblaster code. I had something important come up that I had to take care of all morning. Also, hope you don't mind an off topic announcement -- my niece is even now in labor with her first baby. It is a boy they will name Benjamin. He should be arriving sometime tonight or tomorrow. First baby in his generation. It is very exciting -- so hope you'll forgive this diversion. But look at it this way -- you could say my niece is in the "spawning process". (More seriously, happy thoughts and prayers if you say them are welcome.) Anyway, back to java, it appears that java defines a platform independent way of running a filter and feeding it input and collecting its output in buffers. This will make it possible to run the itex2MML command completely independently rather than cutting into the code to make a JNI library. Hopefully it can come in handy for other utilities as well. I did run across something that looks erroneous in the java class documentation online. In particular, there are 3 functions that set up pipes to manage standard in, out and err: abstract InputStream getErrorStream() Gets the error stream of the subprocess. abstract InputStream getInputStream() gets the input stream of the subprocess abstract OutputStream getOutputStream() get output stream of subprocess Note the return types are inconsistent. The first declaration is right, but the second and third should have swapped return types (if I'm interpreting this right). I haven't tried compiling any code yet as I'm still writing it. I hope this is the right approach. I did a fair amount of googling and reading of opensource projects, but for our purposes, I think just using the process classes in java.lang is sufficient. Any objections send to the list. Thanx and happy hacking. --le
