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
_______________________________________________
Pd-list@iem.at mailing list
UNSUBSCRIBE and account-management ->
http://lists.puredata.info/listinfo/pd-list
