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