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".
On Thu, Jul 8, 2010 at 6:03 PM, Hans-Christoph Steiner <h...@at.or.at>wrote: > > 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 > > > > > > > _______________________________________________ > Pd-list@iem.at mailing list > UNSUBSCRIBE and account-management -> > http://lists.puredata.info/listinfo/pd-list > -- Pedro Lopes contacto: j...@radiozero.pt website: http://web.ist.utl.pt/Pedro.Lopes
_______________________________________________ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list