On Jul 2, 2010, at 3:47 AM, Pedro Lopes wrote:

...

#!/bin/bash echo "this goes to stdout" echo "this goes to stderr" 1>&2 (Which should have been obvious from the familiar "pd -stderr 2>&1")

Yep I use a similar trick in UNIX find, like trying to find .pd files:

• find / -name "*.pd*" -type f -print 2>/dev/null

...

I am thinking of the ideal version of this, an object that would

give you an inlet for STDIN then two >outlets for STDOUT and STDERR,
plus a status outlet and an inlet to set what to run. It could be

...

something like this:

...

[process /usr/bin/python]

...

Then you could send python bits to it via the first inlet, and

receive the reply via the outlets. So >something like a cleaner
[shell].

NIce hc. That's an interesting object, sending messages in a simple
way to a shell process running in the background should be fairly
easy. Just didn't get what you mean by status outlet..

Want to implement it? :-D The status outlet would give you info like
the name of the process running, whether its still running, etc.

.hc

Programs should be written for people to read, and only incidentally
for machines to execute.

• from Structure and Interpretation of Computer Programs

I guess there should be a third inlet for the signals? I see
something like this:

STDIN signals process name | | | | | | [process /usr/sbin/httpd] | | | | | | STDOUT STDERR status messages, like PID, current process name,
state, etc.

.hc

On Jul 4, 2010, at 12:04 PM, Pedro Lopes wrote:

Exactly my point. Having a kill inlet or a kill message. I can make some prototypes from the 16th forth, nothing till then...
work comes first!

On Sun, Jul 4, 2010 at 3:56 PM, Mathieu Bouchard
matju@artengine.ca wrote: at. Make sure you add something for the child process ID, and have a
"kill" (or general "signal") feature.

-- Pedro Lopes contacto: jazz@radiozero.pt website: http://web.ist.utl.pt/Pedro.Lopes

I have always wished for my computer to be as easy to use as my
telephone; my wish has come true because I can no longer figure out
how to use my telephone." --Bjarne Stroustrup (creator of C++)

On Jul 8, 2010, at 3:30 AM, IOhannes m zmoelnig wrote:

On 2010-07-08 01:09, Hans-Christoph Steiner wrote:

...

I guess there should be a third inlet for the signals? I see
something like this:

STDIN signals process name | | | | | | [process /usr/sbin/httpd] | | | | | | STDOUT STDERR status messages, like PID, current process name, state, etc.

hmm, iirc "process name" is there mainly to override the process given as the argument.

sending a new "process name" (e.g. "/usr/sbin/apache2") into the last inlet surely won't start the new process, would it? for me starting a new process seems to be a very "hot" action.

then i don't see a reason why we need different inlets for "process name" and "signals", as both are there to control the the current/ future process from "outside".

so i would basically simplify this to the attached interface.

as for sending signals: even though i like signals very much, there is no such concept on w32 (or at least it is not readily available for
the little programmer). personally i would hate to have the 5th object for the same task
that is still highly platform dependent.

Your example seems backwards to me. STDIN is definitely a hot action,
and most likely the inlet that is going to be used the most. 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 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.

.hc

'You people have such restrictive dress for women,’ she said, hobbling
away in three inch heels and panty hose to finish out another pink- collar temp pool day. - “Hijab Scene #2", by Mohja Kahf

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

On Thu, 8 Jul 2010, 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.

It depends what one means by "hot". Miller's Pd Intro doesn't develop the concept of "hotness" sufficiently enough to make some important distinctions, and this is what we are stumbling upon in this case.

I realise now that I have tended to ignore Miller's definition in favour of my own intuitive concepts.

I would call "hot" any message that goes beyond modifying the contents of the object, be it outputting by outlets, writing to a file, etc.

But it still doesn't explain things like whether displaying something on screen can be considered a hot action. Perhaps "hot" vs "cold" is insufficient and we should use 3 or 4 words instead of 2.

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.

That change of perspective is related to what I mean, too.

In the end it depends on which border-crossings constitute the hot concept : if I only do "sed s/foo/bar/" with stdin and stdout, I could call it cold from the perspective of whether inputting causes an immediate outputting, and then I'd say cold. But if I consider the overall use of that object over time, inlet messages eventually cause the outlet messages to be produced (albeit with a different timing), which may be called hot in the context of that patch, or cold in the context of the patch containing that patch (depending on whether those messages reach an [outlet]). And then if I do "sed s/foo/bar/ > /tmp/bar" I'm doing something that can be considered hot or cold for various reasons including who will look at "/tmp/bar", and what it is that we call an "output".

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.

do you have ideas for which words we could introduce in documentation, to replace the ambiguïty and insufficiency of the "hot" concept ? that's a topic I'm getting quite interested in.

going to use the meta-inlets and -outlets most. so...

Excuse me, what's a meta-inlet ?

it seems like we all agree on the meta-outlet being a [route]able-message.

which messages are not "[route]able" ?

i think of the stdout and stderr as being messages without a given selector.

what is "a message without a selector" ? Pd does not know this concept.

And btw, why wouldn't we have this swiss-army [process] thingy work with byte values just like mrpeach's socket thingies would do ?... Do you think it would be natural, that the most flexible shell-tool would be in sync with the most flexible network-tools, for things as similar to each other as sockets and pipes are ?

_ _ __ ___ _____ ________ _____________ _____________________ ... | Mathieu Bouchard, Montréal, Québec. téléphone: +1.514.383.3801

On 2010-07-08 18:27, Pedro Lopes wrote:

The fun side of being open source is also this one. As Ive said before I can try to help with this object from 16th up, but even so I'd never would do it for Windows, simply because I have no interest in it :) But once again, the beauty of open source is that if a thing is readable enough and easily extensible, it then can be altered to fit more operating systems. (beware that the differences between OSs will show at some point... that's something to consider*).

• i.e.: I have no clue on how to run a process on the background of the

shell in Win. Nor how to kill a process, and so forth...

me neither. but i do know that there are no signals in w32 as we know them from un*x. if an object is designed around features not available on a certain platform, chances are low that the object will ever be available on this very platform, regardless of whether there is a team of experts waiting to port it or not.

fmasdr IOhannes