Get command-line parameter in the new world of processing-java

Programming Questions

howthebod..

Get command-line parameter in the new world of processing-java

in Programming Questions • 2 months ago

In the " external editor" thread - - i learned that we now use the "processing-java" application to launch processing.

Now, at the bottom of the " command line parameter" thread, there are examples how how to use PApplet.args to access command line arguments.

Now, how do I put these together? Let's say I want to dynamically pass a display width to an applet called my_sketch that I invoke from the command-line: Well, that's no problem:

processing-java --sketch=$PWD/my_sketch --output=$PWD/output --force --present

However, there is no obvious way to pass arguments to it

processing-java --sketch=$PWD/my_sketch --output=$PWD/output --force --present width=800

does not work. processing-java complains

I don't know anything about width=80.

there is no clear way to pass the arguments in.

Has anyone worked out how to do this yet?

Cheers,

Dan

Replies(10)

howthebod..

Re: Get command-line parameter in the new world of processing-java

2 months ago

Hmm, I just noticed that there is a way of doing this in OS X at least.

Export the sketch as an application
use the OS X open command

e.g.

open my_sketch/application.macosx/my_sketch.app --args width=800

dimkir

Re: Get command-line parameter in the new world of processing-java

2 months ago

wouldn't it work with:
processing-java --sketch=$PWD/my_sketch --output=$PWD/output --force --present my_sketch width=800

howthebod..

Re: Re: Get command-line parameter in the new world of processing-java

2 months ago

No,

processing-java --sketch=$PWD/my_sketch --output=$PWD/output --force --present my_sketch width=800

does not work. processing-java complains

I don't know anything about my_sketch

Good guess though.

howthebod..

Re: Get command-line parameter in the new world of processing-java

2 months ago

In fact my platform is OS X at the moment, so this is almost a solution for me. Except the problem with the open command is that, AFAIK, there is no way to find the PID of the launched process - and in fact, the whole reason I want to do this from the shell is to I can mange the app - killing it and restarting it as necessary.

So, more cross-platform solutions are welcome on general principle, but even on OS X I would appreciate tips on getting the Process ID of the launched app.

rbrauer

Re: Get command-line parameter in the new world of processing-java

2 months ago

You can build the sketch with "processing-java" and then run it with command line arg via Java. I tested it with the following sketch on Windows.

void setup() {
  size(int(args[0]),int(args[1]));
  println(args);
}

void draw() {
}

void mouseClicked() {
  exit();
}

The two commands should be about the same on Mac. First build:
processing-java --sketch=$PWD/my_sketch --output=$PWD/output --build --force
Then run via Java:
java -Djava.ext.dirs=<path to processing/core/library> -cp $PWD/output <name of sketch> <args>

You should be able to put those on the same terminal input line if you want. Use the command separator between them. I think its ; on Mac.

howthebod..

Re: Re: Get command-line parameter in the new world of processing-java

2 months ago

Ah! so build using processing-java then run using vanilla java. gotcha. That does indeed seem to be cross-platform too. Nice one.

Thanks, rbrauer.

howthebod..

Re: Get command-line parameter in the new world of processing-java

1 month ago

Not for other fellow travellers: as interesting as all this was, it still did not tell me the PID of the launched processing app.

For that I had to use this hack, which is not guaranteed to provide the PID, but happens to work on most (all?) JVMs.

m.peres

Re: Get command-line parameter in the new world of processing-java

1 month ago

That is really strange,

I have used the open command many times and I am not sure about what you mean by "no way to find PID". How about trying the following command in terminal:

ps -ax | grep -m1 YourSketch.app | awk '{print $1}'

howthebod..

Re: Get command-line parameter in the new world of processing-java

1 month ago

m.peres, thanks for the suggestion.

sure, yes, there is not "no way to find the PID of a named process at all" , but there is no way to get the PID directly from the "open" command of the application just launched, and I'm not convinced that parsing shell command output is substantially better than the java solution I linked to above.

If we give up the idea of open reporting the PID but rather grep the process list, sure we can do it, but it's not the one-liner it would seem.

For one thing, if you aren't sure that the process has launched, or that it has launched yet, then you can't just "grep -m1" - since you need to know that you haven't just grepped your own grep command's process in lieu of a viable running application, so some error trapping is needed, and parsing the string output of the shell command beyond awk. And in fact, if you run open asynchronously (as I am), since spawning the GUI app takes a while, the parent process is not guaranteed to detect such a PID if it checks instantly, so there is more time-out book-keeping to do even if the process was successfully launched. (Has it not launched yet, or launched and crashed?)

For another, this method doesn't work if you launched the app from within the processing IDE instead of the command line, (because then the YourAppName.app string isn't present) so you need to special case development and deployment environments, which is tedious and error-prone.

Finally, it has even less guarantees of being cross-platform, ps being unix-ish etc.

However, if you are launching apps synchronously and don't have to worry about them crashing, this could indeed be a good option especially should a JVM appear which doesn't respect the convention of naming the RuntimeMXBean by PID.

m.peres

Re: Get command-line parameter in the new world of processing-java

1 month ago

Yes I am aware of these issues. In my case what I did, and this is not in any way a cross platform solution, was to write down the process PID once the application is fully loaded by calling Runtime exec. Apart from the PID, I also ended up writing down the current framerate of the app, among a few other things as I wanted to make sure it was not going bellow a minimum expected. This was written to an external text file and continually updated in a separate thread. The file was read by an external script (kept alive by launchd) responsible for killing the app, reseting, etc., according to a set of rules I specified. It ended up working really well because I could also easily detect when the application froze without crashing.

Top Reply