Hi, it's me again in my Pd documentation revision.
I have the idea that "flags" are a special kind of creation arguments. Here's how to define them:
They start with "-".
They're always optional
They come before "actual" arguments.
Now, I'm not sure about the last rule. I just tried it in [sigmund~] and I could use the '-hop <float>' flag after the actual creation arguments (such as "env" / "tracks").
Is this a bug in [sigmund~]?
Cheers
Am 27. Februar 2022 02:23:54 MEZ schrieb Alexandre Torres Porres porres@gmail.com:
Is this a bug in [sigmund~]?
What exactly is the buggy behaviour?
mfg.sfg.jfd IOhannes
Em dom., 27 de fev. de 2022 às 05:26, IOhannes m zmölnig zmoelnig@iem.at escreveu:
What exactly is the buggy behaviour?
If in fact flags should always come first, the object shouldn't load it in an incorrect order.
Many objects in Pd are coded in a way to reject creation arguments in the wrong order. The bug would be that it allows it.
On 2/27/22 10:05, Alexandre Torres Porres wrote:
Em dom., 27 de fev. de 2022 às 05:26, IOhannes m zmölnig zmoelnig@iem.at escreveu:
Many objects in Pd are coded in a way to reject creation arguments in the wrong order. The bug would be that it allows it.
that's typically not how it works. see Postel's law.
flags are just a general expression of "named arguments" (where you specify the meaning of a value along with the value; which is useful if you have many and/or non-mandatory arguments),
in general, flags are most useful for cmdline applications. so i think we should check how flags are andled there.
- They start with "-".
in *general* i think it is safe to say that flags start with some common prefix. the actual prefix may vary based on the ecosystem, with *plenty* of exceptions.
- on Windows, cmdline flags often start with "/"
- GNU suggests to use "--" for long-name flags (e.g. "--verbose") and
"-" for short-name (single-character) flags (e.g. "-v")
- single dash is common as well (e.g. "-flags")
Pd has mostly adopted single-dash flags, both for cmdline args and for arguments. that doesn't mean that other suffixes (e.g. '@') are "bugs". they are just uncommon.
- They're always optional
i don't think so. i know programs that have obligatory flags (though they are uncommon; and i can't remember the name of one right now; but i *know* that i know some such programs)
- They come before "actual" arguments.
what do you mean by "actual arguments"? I've never heard of anything like that. i guess you mean arguments that are not "flags" (named arguments), but what is typically called "positional arguments" (as their semantic is encoded in the position: the 1st argument means something else as the 2nd arg).
so to conclude: i think you are overformalizing here, based on some assumptions that do not hold.
in general, a rule for flags could be: is the meaing of an argument-list ambiguous or not. if it allows to specify ambiguous arguments, then there's a bug. if not, then there's none.
fgdy IOhannes
I didn't mean to define things in a broader sense outside the context of Pd. I'm just concerned in defining what is the "official" settings and behaviour of flags in Pd.
Em dom., 27 de fev. de 2022 às 06:33, IOhannes m zmölnig zmoelnig@iem.at escreveu:
that's typically not how it works. see Postel's law.
I see. It's not actually a bug if you allow non-conformant input, as long as the meaning is clear. But the point here is to define what is the correct way, in order to document it as such.
Lots of people use a bogus symbol argument for inlet (such as [inlet hz]) and Pd allows it, even though it is meaningless and non-conformant input, but the point is that it is not documented and it shouldn't be. In the same way you can have [osc~ 440 hz(cycles-per-second)] and [osc~] will not complain that it is meaningless and that's fine.
But this is a bit different, it's something that is meaningful and that will work.
Therefore, my main concern here is to agree on what is the standard way and document it. And I believe the idea is that flags in pd are supposed to come first for optional settings, and I should not say that you can have it come later in [sigmund~], even though it works.
I'm also concerned to conform to this principles in my externals.
Would it be weird or wrong to have an external that NEEDS to load flags AFTER the creation arguments? This has been necessary for parameters that take a non fixed number of elements.
Pd has mostly adopted single-dash flags, both for cmdline args and for arguments.
I think Pd has "only" adopted single-dash flags, right? Unless you mean externals out there have adopted things differently.
that doesn't mean that other suffixes (e.g. '@') are "bugs". they are just uncommon.
cyclone uses "@", but that's because MAX uses it (and calls it "attributes"). They can come later, though.
- They're always optional
i don't think so.
I meant in Pd, but I remember now how [declare] works, and it only takes 'flags', so yeah, not really "optional".
- They come before "actual" arguments.
what do you mean by "actual arguments"?
Arguments that are not flags, in [sigmund~] they'd be "pitch" and "env" for instance.
I've never heard of anything like that. i guess you mean arguments that are not "flags" (named arguments), but what is typically called "positional arguments" (as their semantic is encoded in the position: the 1st argument means something else as the 2nd arg).
yup
IMO there is a convention that "flags" should come before positional arguments - but after "methods", like in [text define -k foo].
[sigmund~] is a curious case because its arguments "pitch", "notes", "env", "peaks" and "tracks" are *not* positional arguments but rather named arguments. [sigmund~] doesn't really distinguish between "arguments" on the one hand and "flags" on the other hand, instead it's just a single big loop. As a side effect, you can freely mix "arguments" and "flags". In fact, these "arguments" could just as well be flags, i.e. "-pitch", "-notes", etc. In the case of [sigmund~], the real difference is that all the "flags" can also be changed dynamically via messages while the "arguments" are fixed at creation time.
The current documentation follows the established practice to put flags before other arguments and I think we should keep it. I'm not sure whether it's necessary or even helpful to mention that the flags can actually come at any position. It might create more confusion than it tries to avoid...
Christof
On 27.02.2022 18:19, Alexandre Torres Porres wrote:
I didn't mean to define things in a broader sense outside the context of Pd. I'm just concerned in defining what is the "official" settings and behaviour of flags in Pd.
Em dom., 27 de fev. de 2022 às 06:33, IOhannes m zmölnig zmoelnig@iem.at escreveu:
that's typically not how it works. see Postel's law.I see. It's not actually a bug if you allow non-conformant input, as long as the meaning is clear. But the point here is to define what is the correct way, in order to document it as such.
Lots of people use a bogus symbol argument for inlet (such as [inlet hz]) and Pd allows it, even though it is meaningless and non-conformant input, but the point is that it is not documented and it shouldn't be. In the same way you can have [osc~ 440 hz(cycles-per-second)] and [osc~] will not complain that it is meaningless and that's fine.
But this is a bit different, it's something that is meaningful and that will work.
Therefore, my main concern here is to agree on what is the standard way and document it. And I believe the idea is that flags in pd are supposed to come first for optional settings, and I should not say that you can have it come later in [sigmund~], even though it works. I'm also concerned to conform to this principles in my externals.
Would it be weird or wrong to have an external that NEEDS to load flags AFTER the creation arguments? This has been necessary for parameters that take a non fixed number of elements.
Pd has mostly adopted single-dash flags, both for cmdline args and for arguments.I think Pd has "only" adopted single-dash flags, right? Unless you mean externals out there have adopted things differently.
that doesn't mean that other suffixes (e.g. '@') are "bugs". they are just uncommon.cyclone uses "@", but that's because MAX uses it (and calls it "attributes"). They can come later, though.
- They're always optional i don't think so.I meant in Pd, but I remember now how [declare] works, and it only takes 'flags', so yeah, not really "optional".
- They come before "actual" arguments. what do you mean by "actual arguments"?Arguments that are not flags, in [sigmund~] they'd be "pitch" and "env" for instance.
I've never heard of anything like that. i guess you mean arguments that are not "flags" (named arguments), but what is typically called "positional arguments" (as their semantic is encoded in the position: the 1st argument means something else as the 2nd arg).yup
Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management ->https://lists.puredata.info/listinfo/pd-list
some thoughts:
i think that sigmund~ is ok with flags that come last, because of the way that sigmund~ parses its arguments. It doesn't impose any order, since the user will create it the way it wants ([sigmund~ env pitch] and [sigmund~ pitch env] are both valid and gets its outlets swapped, and it is ok), so for sigmund~ the point of view is that all arguments needs to be parsed and if you throw a flag in the middle, it will be parsed accordingly, so even if you put a flag in the middle (like [sigmund~ env -npts 512 pitch]) it will also work.
but not all objects works if the flags appear in different order, and this actually confuses me more than sigmund~
for example
[netreceive -u 5000] will listen to port 5000 and will use udp protocol, but [netreceive 5000 -u] will listen to port 5000 and use tcp protocol!! -u is ignored in this case...
(you can check this using pdsend... for the first case "pdsend 5000 localhost udp" will work, but for the second it doesn't... it only works with "pdsend 5000 localhost tcp")
but on the other hand, pd also has the opposite case, where flags comes in the end, they are on the text family objects, specifically the [text sequence] object
[text sequence text-help-seq2 -g], the -g goes after the creation argument with the name of the text... and -w or -t also goes in the end
Em dom., 27 de fev. de 2022 às 14:22, Alexandre Torres Porres < porres@gmail.com> escreveu:
I didn't mean to define things in a broader sense outside the context of Pd. I'm just concerned in defining what is the "official" settings and behaviour of flags in Pd.
Em dom., 27 de fev. de 2022 às 06:33, IOhannes m zmölnig zmoelnig@iem.at escreveu:
that's typically not how it works. see Postel's law.
I see. It's not actually a bug if you allow non-conformant input, as long as the meaning is clear. But the point here is to define what is the correct way, in order to document it as such.
Lots of people use a bogus symbol argument for inlet (such as [inlet hz]) and Pd allows it, even though it is meaningless and non-conformant input, but the point is that it is not documented and it shouldn't be. In the same way you can have [osc~ 440 hz(cycles-per-second)] and [osc~] will not complain that it is meaningless and that's fine.
But this is a bit different, it's something that is meaningful and that will work.
Therefore, my main concern here is to agree on what is the standard way and document it. And I believe the idea is that flags in pd are supposed to come first for optional settings, and I should not say that you can have it come later in [sigmund~], even though it works.
I'm also concerned to conform to this principles in my externals.
Would it be weird or wrong to have an external that NEEDS to load flags AFTER the creation arguments? This has been necessary for parameters that take a non fixed number of elements.
Pd has mostly adopted single-dash flags, both for cmdline args and for arguments.
I think Pd has "only" adopted single-dash flags, right? Unless you mean externals out there have adopted things differently.
that doesn't mean that other suffixes (e.g. '@') are "bugs". they are just uncommon.
cyclone uses "@", but that's because MAX uses it (and calls it "attributes"). They can come later, though.
- They're always optional
i don't think so.
I meant in Pd, but I remember now how [declare] works, and it only takes 'flags', so yeah, not really "optional".
- They come before "actual" arguments.
what do you mean by "actual arguments"?
Arguments that are not flags, in [sigmund~] they'd be "pitch" and "env" for instance.
I've never heard of anything like that. i guess you mean arguments that are not "flags" (named arguments), but what is typically called "positional arguments" (as their semantic is encoded in the position: the 1st argument means something else as the 2nd arg).
yup
Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> https://lists.puredata.info/listinfo/pd-list
On 28.02.2022 00:26, José de Abreu wrote:
but on the other hand, pd also has the opposite case, where flags comes in the end, they are on the text family objects, specifically the [text sequence] object
[text sequence] is really an outlier. Typically, flags come *before* positional arguments, but *after* "methods", see [text define]. Here the flags come *after* the first (and only) positional argument. To add more to the confusion, there is a problem with the flag parsing: https://github.com/pure-data/pure-data/issues/1579
Christof
Em dom., 27 de fev. de 2022 às 20:26, José de Abreu abreubacelar@gmail.com escreveu:
but not all objects works if the flags appear in different order,
I know, that's because they should come first! This is why I think it's confusing that sigmund~ doesn't complain and it just works...
[netreceive -u 5000] will listen to port 5000 and will use udp protocol,
but [netreceive 5000 -u] will listen to port 5000 and use tcp protocol!! -u is ignored in this case...
yup, wrong order, so it gets ignored, but a warning should be given that the order is wrong, so it's ignored!
but on the other hand, pd also has the opposite case, where flags comes in the end, they are on the text family objects, specifically the [text sequence] object
[text sequence text-help-seq2 -g], the -g goes after the creation argument with the name of the text... and -w or -t also goes in the end
I'm almost done writing the reference for all objects, there are 6 to go, and I didn't get to [text] yet, ahahahaha, so I was missing that one in my radar.
Em dom., 27 de fev. de 2022 às 20:58, Christof Ressi info@christofressi.com escreveu:
[text sequence] is really an outlier. Typically, flags come *before* positional arguments, but *after* "methods", see [text define]. Here the flags come *after* the first (and only) positional argument. To add more to the confusion, there is a problem with the flag parsing: https://github.com/pure-data/pure-data/issues/1579
I haven't looked closely but I believe the best thing to do here is to make the code allow these flags coming before the array name and document it as such! It should also work by creating them in the wrong order as in sigmund~ though.
On 2/28/22 17:47, Alexandre Torres Porres wrote:
I know, that's because they should come first! This is why I think it's confusing that sigmund~ doesn't complain and it just works...
i doubt that it is confusing. but: if you do find it confusing, just put the flags at the beginning.
it's not like Pd is *forcing* you to put the sigmund~ flags at the end, and the flags for all other objects at the beginning. (*that* would be an inconsistency, and deserve some attention).
it's not even documented, that you can put the flags at the end. and i agree with christof, that there's no benefit in documenting that you can put them at the end.
so just forget it, and the source for the confusion will be gone.
[netreceive -u 5000] will listen to port 5000 and will use udp protocol,
but [netreceive 5000 -u] will listen to port 5000 and use tcp protocol!! -u is ignored in this case...
yup, wrong order, so it gets ignored, but a warning should be given that the order is wrong, so it's ignored!
i agree that a warning should be given if there are any ignored (and probably also: unknown) arguments (for objects with a complex invocation).
in general i think: it is confusing if things don't work. it isn't confusing if things do work.
fmgdasr IOhannes
Em dom., 27 de fev. de 2022 às 20:58, Christof Ressi info@christofressi.com escreveu:
On 28.02.2022 00:26, José de Abreu wrote:
but on the other hand, pd also has the opposite case, where flags comes in the end, they are on the text family objects, specifically the [text sequence] object
[text sequence] is really an outlier. Typically, flags come *before* positional arguments, but *after* "methods", see [text define]. Here the flags come *after* the first (and only) positional argument. To add more to the confusion, there is a problem with the flag parsing: https://github.com/pure-data/pure-data/issues/1579
Well, made a PR that fixes it and allows flags to come first, but is also permissive of this old and "wrong" way for backwards compatibility...
Christof
Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> https://lists.puredata.info/listinfo/pd-list
-
Alexandre Torres Porres -
Christof Ressi -
IOhannes m zmoelnig -
IOhannes m zmölnig
-
José de Abreu