Yes of course, there's a lot of "wheels" out there, no need to reinvent it. Just combine a bit with the possibility of sending signals, STDIN, STDOUT, status and STDERR and we get ourselves a new "car". <br>
<br><div class="gmail_quote">On Thu, Jul 8, 2010 at 6:03 PM, Hans-Christoph Steiner <span dir="ltr"><<a href="mailto:hans@at.or.at">hans@at.or.at</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
<br>
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.<br>
<br>
.hc<div><div></div><div class="h5"><br>
<br>
On Jul 8, 2010, at 12:48 PM, IOhannes m zmoelnig wrote:<br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
On 2010-07-08 18:24, Hans-Christoph Steiner wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
Your example seems backwards to me. STDIN is definitely a hot action,<br>
</blockquote>
<br>
STDIN is far from being a hot action "definitely".<br>
it's entirely at the process's disposition, whether it will do something<br>
with the stdin or not.<br>
<br>
anyhow, whether it's backward or not depends on your pov.<br>
if you see [process] as an object that interacts with system-processes,<br>
then i think my approach is straight-forward.<br>
if you think of the object as being a representation of the process, and<br>
thus the process being just another Pd-object, then my approach looks<br>
backwards.<br>
<br>
it seems like I (IOhannes) see this object as an interface to the<br>
external world (ihde's "external" tool), whereas you (Hans-Christoph)<br>
see the ibject as a way to internalize functionality into Pd (ihde's<br>
tool "as an extension")<br>
<br>
this basically means, that the question is not solveable :-)<br>
<br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
and most likely the inlet that is going to be used the most.<br>
</blockquote>
<br>
or not.<br>
i prefer to not make too many assumptions about what the users are going<br>
to do, but rather try to make the interface consistent, regardless of<br>
what they are actually doing.<br>
<br>
i guess, people are using [shell] to startup an small script. and<br>
startup the script again. and again, not worrying to much about the<br>
output (mainly due to the fact how stdout/stderr are handled with [shell]).<br>
if [process] is gooing to replace [shell], then people are probably<br>
going to use the meta-inlets and -outlets most. so...<br>
<br>
anyhow, the proposed object is merely an extension to the current<br>
[shell]. you could even write an abstraction with the current [shell]<br>
and some small wrapper-script that is more or less doing the same as<br>
proposed.<br>
<br>
it probably would be a good idea to keep compatibility.<br>
<br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
I imagine<br>
many users would never change the program that is being run. STDOUT<br>
will most likely be the main outlet used, i.e the result, so that really<br>
should be the first outlet. The process information is meta/info/status<br>
stuff like in [hid], [comport], etc. so it should be the right outlet<br>
like them.<br>
</blockquote>
<br>
i'm thinking more in terms of extensibility.<br>
it seems like we all agree on the meta-outlet being a [route]able-message.<br>
i think of the stdout and stderr as being messages without a given selector.<br>
putting the stderr and stdout before the meta, makes it hard to add new<br>
backtalk channels (e.g. pipes).<br>
<br>
its similar to [route] where the reject-outlet moves to the right,<br>
whenever you add new selectors. it's one of the behaviours that annoyed<br>
me most.<br>
(so that's an argument for both sides)<br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
I could see combining the signal and process inlets into one second meta<br>
inlet, but it seems to me that since there are just two messages (run<br>
and signal), why not just make each have their own inlet and spare the<br>
patcher from having to build up messages as much.<br>
<br>
</blockquote>
<br>
hmm, what's harder to do: create one of those fuzzy messages, or<br>
fiddling with the tiny iolets?<br>
personally i think the former is simpler to do.<br>
in addition, i think that the former is simpler to read as well, as it<br>
is an implicit documentation)<br>
<br>
anyhow, i'm still convinced that creating and deleting a process (the<br>
guts of this object) is "hotter" than sending data to it, which it might<br>
or might not ignore.<br>
<br>
fgmasdr<br>
IOhannes<br>
<br>
<br>
</blockquote>
<br>
<br>
<br></div></div>
----------------------------------------------------------------------------<br>
<br>
All information should be free. - the hacker ethic<div><div></div><div class="h5"><br>
<br>
<br>
<br>
<br>
<br>
_______________________________________________<br>
<a href="mailto:Pd-list@iem.at" target="_blank">Pd-list@iem.at</a> mailing list<br>
UNSUBSCRIBE and account-management -> <a href="http://lists.puredata.info/listinfo/pd-list" target="_blank">http://lists.puredata.info/listinfo/pd-list</a><br>
</div></div></blockquote></div><br><br clear="all"><br>-- <br>Pedro Lopes<br>contacto: <a href="mailto:jazz@radiozero.pt">jazz@radiozero.pt</a><br>website: <a href="http://web.ist.utl.pt/Pedro.Lopes">http://web.ist.utl.pt/Pedro.Lopes</a> <br>