On Mon, 2 Aug 2010, Jonathan Wilkes wrote:
« error: [args hello (world a 42) *] inlet 0 method
loadbang: can't send init-messages, because object has no
[inlet] »
No, it just crashes.
I suppose you can also find other situations in which GF crashes instead
of reporting an error message ?
But my bigger point is that it's really confusing behavior for messages
to be coming out an inlet at loadbang time when nothing is actually
connected to that inlet.
It's confusing while you don't expect it. Once it's expected, it's not any
more confusing than receive-symbols hidden inside IEMGUI properties
dialogues.
Why did you choose to do that?
Because [args] used to have a right outlet to be connected to the top left
[inlet] and it would always go across the whole patch in some ugly way. I
could have made it left outlet instead, but figured out that if I could
save a bit of boilerplate (usually a [t a] and two more wires) in every
abstraction, I'd have that much less in every abstraction, and I wouldn't
have to verify all abstractions to make sure that they support the
init-commas.
Exactly. The clean patching solution for multiple loadbangs is pretty
easy: [loadbang]-[t b b b etc.] . (I actually used that even before
thinking about the problem of [loadbang] order because it just seemed
like a simple, readable way to do it.)
That's not the only well-ordered one : you can do clear-looking partial
ordering of loadbangs by using subpatches (with nesting or not). All
subpatch [loadbang]s are guaranteed to be finished before their immediate
parent's [loadbang]s.
Maybe you could have another object with a different name like [getargs]
that doesn't do the loadbang.
I may as well do search-and-replace on all of GridFlow. I shouldn't care
so much about backwards-compatibility when not only other people don't
contribute abstractions to GF, but also, there's no one even saying
something like « I use [args] ». Then why bother.
But at this point, my idea of it is to make it a comma-option in [args] :
[args foo bar *, noloadbang]
and then think some more before getting into anything not
backwards-compatible.
The word "anything" seems sometimes to be used in opposition to the list
message, to refer to a multi-element message with a selector other than
"list" (or a single-element message with selector other than bang,
symbol, float, or pointer).
bang is not a single-element message : it has no $1.
At other times it seems to mean any message that would be accepted by
the anything-method, which includes list messages as well as the other
pd built-ins. (like [any], [send], [spigot], etc. )
What does that case exclude ?... only "loadbang" and "dsp" ? (but then,
not even necessarily).
And at further other times, it seems like it means "other than x/y/z,
anything", as in, "other than 11 reserved selectors, you can send
anything to [bng] and it will trigger a bang."
this is why method <any> appears last, for a given inlet or outlet.
Do any of these fit your definition of "anything"?
No. The one I mean here is more like : if you put $@ alone in a message
box, you'll get "an anything" in the sense that the possible values of $@
make most any message possible. This includes the case where the value of
$1 is "list", in which case the $1 of the output will be the $2 of the
input. (In effect, this would be a shortcut of [list trim].)
Whereas you get "a list" if you write "list $@" in it because you can only
make list-messages that way.
Why are [args] and [setargs] two separate objects?
Didn't really think about it. Any ideas ?
I suppose that there would be a point soon when I will have a better idea
about what to do, but I only _started_ using [setargs] very recently, so,
I don't know yet.
_ _ __ ___ _____ ________ _____________ _____________________ ...
| 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
