We have [ggee/shell], [motex/system], [flatspace/popen], and [moonlib/
popen], so I see little reason to make "yet another" or a
replacement. Instead, the idea that is most interesting to me is to
make an object that allows you to easily run externals processes as if
they were pd objects. That's why STDIN, STDOUT, and STDERR would be
the focus.
.hc
On Jul 8, 2010, at 12:48 PM, IOhannes m zmoelnig wrote:
On 2010-07-08 18:24, Hans-Christoph Steiner wrote:
Your example seems backwards to me. STDIN is definitely a hot
action,STDIN is far from being a hot action "definitely". it's entirely at the process's disposition, whether it will do
something with the stdin or not.anyhow, whether it's backward or not depends on your pov. if you see [process] as an object that interacts with system- processes, then i think my approach is straight-forward. if you think of the object as being a representation of the process,
and thus the process being just another Pd-object, then my approach looks backwards.it seems like I (IOhannes) see this object as an interface to the external world (ihde's "external" tool), whereas you (Hans-Christoph) see the ibject as a way to internalize functionality into Pd (ihde's tool "as an extension")
this basically means, that the question is not solveable :-)
and most likely the inlet that is going to be used the most.
or not. i prefer to not make too many assumptions about what the users are
going to do, but rather try to make the interface consistent, regardless of what they are actually doing.i guess, people are using [shell] to startup an small script. and startup the script again. and again, not worrying to much about the output (mainly due to the fact how stdout/stderr are handled with
[shell]). if [process] is gooing to replace [shell], then people are probably going to use the meta-inlets and -outlets most. so...anyhow, the proposed object is merely an extension to the current [shell]. you could even write an abstraction with the current [shell] and some small wrapper-script that is more or less doing the same as proposed.
it probably would be a good idea to keep compatibility.
I imagine many users would never change the program that is being run. STDOUT will most likely be the main outlet used, i.e the result, so that
really should be the first outlet. The process information is meta/info/ status stuff like in [hid], [comport], etc. so it should be the right outlet like them.i'm thinking more in terms of extensibility. it seems like we all agree on the meta-outlet being a [route]able- message. i think of the stdout and stderr as being messages without a given
selector. putting the stderr and stdout before the meta, makes it hard to add
new backtalk channels (e.g. pipes).its similar to [route] where the reject-outlet moves to the right, whenever you add new selectors. it's one of the behaviours that
annoyed me most. (so that's an argument for both sides)I could see combining the signal and process inlets into one second
meta inlet, but it seems to me that since there are just two messages (run and signal), why not just make each have their own inlet and spare
the patcher from having to build up messages as much.hmm, what's harder to do: create one of those fuzzy messages, or fiddling with the tiny iolets? personally i think the former is simpler to do. in addition, i think that the former is simpler to read as well, as it is an implicit documentation)
anyhow, i'm still convinced that creating and deleting a process (the guts of this object) is "hotter" than sending data to it, which it
might or might not ignore.fgmasdr IOhannes
All information should be free. - the hacker ethic