Hello everyone, I was wondering if there is a way in pure-vanilla Pd to retrieve the list of arguments of an abstraction. I use zexy's [dollarg] for this, but I'm making an effort to see if I can use Pd vanilla only for some abstractions. Is there a way to do this in Pd vanilla?
Thanks,
Alexandre Quessy http://alexandre.quessy.net/
Sorry -- there's no way to do that!
Miller
On Mon, Mar 07, 2011 at 11:50:16AM -0500, Alexandre Quessy wrote:
Hello everyone, I was wondering if there is a way in pure-vanilla Pd to retrieve the list of arguments of an abstraction. I use zexy's [dollarg] for this, but I'm making an effort to see if I can use Pd vanilla only for some abstractions. Is there a way to do this in Pd vanilla?
Thanks,
Alexandre Quessy http://alexandre.quessy.net/
Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Can't you simply do [f $<arg_num] or [symbol $<arg_num] inside the patch for each of the arguments and send them out with a loadbang? Granted this won't generate a list buy you could easily pack it below.
Ico
-----Original Message----- From: pd-list-bounces@iem.at [mailto:pd-list-bounces@iem.at] On Behalf Of Miller Puckette Sent: Monday, March 07, 2011 12:16 PM To: Alexandre Quessy Cc: pd-list@iem.at Subject: Re: [PD] Get list of a the arguments of a patch without using any external?
Sorry -- there's no way to do that!
Miller
On Mon, Mar 07, 2011 at 11:50:16AM -0500, Alexandre Quessy wrote:
Hello everyone, I was wondering if there is a way in pure-vanilla Pd to retrieve the list of arguments of an abstraction. I use zexy's [dollarg] for this, but I'm making an effort to see if I can use Pd vanilla only for some abstractions. Is there a way to do this in Pd vanilla?
Thanks,
Alexandre Quessy http://alexandre.quessy.net/
Pd-list@iem.at mailing list UNSUBSCRIBE and account-management ->
http://lists.puredata.info/listinfo/pd-list
Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
On Mon, 7 Mar 2011, Miller Puckette wrote:
Sorry -- there's no way to do that!
Yes there is a way to do it, but it takes 5 hours to find out how to do it in pd, while it takes 5 minutes to edit the C code so that people can do it in pd in 5 seconds. But most of all it takes 0.5 second to write "sorry".
| Mathieu Bouchard ---- tél: +1.514.383.3801 ---- Villeray, Montréal, QC
--- On Mon, 3/7/11, Mathieu Bouchard matju@artengine.ca wrote:
From: Mathieu Bouchard matju@artengine.ca Subject: Re: [PD] Get list of a the arguments of a patch without using any external? To: "Miller Puckette" msp@ucsd.edu Cc: pd-list@iem.at Date: Monday, March 7, 2011, 9:07 PM On Mon, 7 Mar 2011, Miller Puckette wrote:
Sorry -- there's no way to do that!
Yes there is a way to do it, but it takes 5 hours to find out how to do it in pd, while it takes 5 minutes to edit the C code so that people can do it in pd in 5 seconds. But most of all it takes 0.5 second to write "sorry".
matju, How long would it take you to implement the "$@" thingy that you commented on in the patch tracker? That would be a big step forward and would surely get included in pd-ext and pd-l2ork.
(I would try my hand at it, but I move at turtle speed in c.)
-Jonathan
| Mathieu Bouchard ---- tél: +1.514.383.3801 ---- Villeray, Montréal, QC
-----Inline Attachment Follows-----
Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
On Mon, 7 Mar 2011, Jonathan Wilkes wrote:
matju, How long would it take you to implement the "$@" thingy that you commented on in the patch tracker? That would be a big step forward and would surely get included in pd-ext and pd-l2ork. (I would try my hand at it, but I move at turtle speed in c.)
Jonathan,
When in jan 2007, I talked about "$@" in the patch tracker, it had already been implemented by Iohannes and submitted in aug 2006. http://sourceforge.net/tracker/index.php?func=detail&aid=1543850&gro...
PS: the [delwrite~] clear method http://sourceforge.net/tracker/?func=detail&aid=3170987&group_id=557... is still assigned to "nobody", because it's waiting for any of the five project admins to click on a button... It also didn't appear on pd-dev@iem.at either : http://lists.puredata.info/pipermail/pd-dev/2011-02/thread.html
| Mathieu Bouchard ---- tél: +1.514.383.3801 ---- Villeray, Montréal, QC
--- On Mon, 3/7/11, Mathieu Bouchard matju@artengine.ca wrote:
From: Mathieu Bouchard matju@artengine.ca Subject: Re: [PD] Get list of a the arguments of a patch without using any external? To: "Jonathan Wilkes" jancsika@yahoo.com Cc: "Miller Puckette" msp@ucsd.edu, pd-list@iem.at Date: Monday, March 7, 2011, 10:40 PM On Mon, 7 Mar 2011, Jonathan Wilkes wrote:
matju, How long would it take you to
implement the "$@" thingy that you commented on in the patch tracker? That would be a big step forward and would surely get included in pd-ext and pd-l2ork.
(I would try my hand at it, but I move at turtle speed
in c.)
Jonathan,
When in jan 2007, I talked about "$@" in the patch tracker, it had already been implemented by Iohannes and submitted in aug 2006. http://sourceforge.net/tracker/index.php?func=detail&aid=1543850&gro...
I know, but I think your suggestion is cleaner-- you can get then number of args by [$@(--[list length] so $# isn't needed, and as you point out, having a way of saying "put args from $n and up in this object box" is very useful. (Without that, one either has to make the number of args static, or use dynamic patching-- i.e., either be less flexible or complicated.)
PS: the [delwrite~] clear method http://sourceforge.net/tracker/?func=detail&aid=3170987&group_id=557... is still assigned to "nobody", because it's waiting for any of the five project admins to click on a button... It also didn't appear on pd-dev@iem.at either : http://lists.puredata.info/pipermail/pd-dev/2011-02/thread.html
If one of the admins (finally) takes care of that, would you consider submitting a patch for $@ with the functionality you wrote in the comment?
-Jonathan
| Mathieu Bouchard ---- tél: +1.514.383.3801 ---- Villeray, Montréal, QC
On Mon, 7 Mar 2011, Jonathan Wilkes wrote:
I know, but I think your suggestion is cleaner-- you can get then number of args by [$@(--[list length] so $# isn't needed, and as you point out, having a way of saying "put args from $n and up in this object box" is very useful.
But what would be the syntax for it ?
(Without that, one either has to make the number of args static, or use dynamic patching-- i.e., either be less flexible or complicated.)
But dynamic patching does deserve to become easier too, and more high-level. Imagine something like what [#in] or [#out] does for loading plugins, except it would be available for general use for any purpose whatsoever. Then imagine other things.
PS: the [delwrite~] clear method http://sourceforge.net/tracker/?func=detail&aid=3170987&group_id=557... is still assigned to "nobody", because it's waiting for any of the five project admins to click on a button... It also didn't appear on pd-dev@iem.at either : http://lists.puredata.info/pipermail/pd-dev/2011-02/thread.html
If one of the admins (finally) takes care of that, would you consider submitting a patch for $@ with the functionality you wrote in the comment?
It was just a reminder, not a condition.
| Mathieu Bouchard ---- tél: +1.514.383.3801 ---- Villeray, Montréal, QC
PS: the [delwrite~] clear method
http://sourceforge.net/tracker/?func=detail&aid=3170987&group_id=557 36&atid=478072
is still assigned to "nobody", because it's waiting for any of the five project admins to click on a button... It also didn't appear on pd-dev@iem.at either : http://lists.puredata.info/pipermail/pd-dev/2011-
02/thread.html
If one of the admins (finally) takes care of that, would you consider submitting a patch for $@ with the functionality you wrote in the comment?
It was just a reminder, not a condition.
Having merged this feature (with changes) to pd-l2ork, I can attest that the patch in its current condition will not work because memory allocation has changed dramatically since the patch was submitted, rendering it incomplete (e.g. code won't even compile). If interested, feel free to dig around pd-l2ork code to find the updated implementation (sans $# which is superfluous with the introduction of [list length], as Jonathan pointed out).
Best,
ico
--- On Thu, 3/31/11, Mathieu Bouchard matju@artengine.ca wrote:
From: Mathieu Bouchard matju@artengine.ca Subject: Re: [PD] Get list of a the arguments of a patch without using any external? To: "Jonathan Wilkes" jancsika@yahoo.com Cc: pd-list@iem.at Date: Thursday, March 31, 2011, 3:40 AM On Mon, 7 Mar 2011, Jonathan Wilkes wrote:
I know, but I think your suggestion is cleaner-- you
can get then number of args by [$@(--[list length] so $# isn't needed, and as you point out, having a way of saying "put args from $n and up in this object box" is very useful.
But what would be the syntax for it ?
I don't know. $@-3 = from $3 onward? Or $@3?
(Without that, one either has to make the number of
args static, or use dynamic patching-- i.e., either be less flexible or complicated.)
But dynamic patching does deserve to become easier too, and more high-level.
Absolutely. It's just that $@ was sitting there ready, along with your comment, and both are concrete ideas that have concrete benefits so I thought it was worth getting it implemented.
Imagine something like what [#in] or [#out] does for loading plugins, except it would be available for general use for any purpose whatsoever.
You'll have to walk me through this a bit-- I haven't used those before.
Then imagine other things.
PS: the [delwrite~] clear method http://sourceforge.net/tracker/?func=detail&aid=3170987&group_id=557... is still assigned to "nobody", because it's
waiting for any
of the five project admins to click on a button...
It also
didn't appear on pd-dev@iem.at either : http://lists.puredata.info/pipermail/pd-dev/2011-02/thread.html
If one of the admins (finally) takes care of that,
would you consider submitting a patch for $@ with the functionality you wrote in the comment?
It was just a reminder, not a condition.
| Mathieu Bouchard ---- tél: +1.514.383.3801 ---- Villeray, Montréal, QC
On Mon, Mar 07, 2011 at 03:07:08PM -0500, Mathieu Bouchard wrote:
On Mon, 7 Mar 2011, Miller Puckette wrote:
Sorry -- there's no way to do that!
Yes there is a way to do it, but it takes 5 hours to find out how to do it in pd, while it takes 5 minutes to edit the C code so that people can do it in pd in 5 seconds. But most of all it takes 0.5 second to write
"sorry".
On Mon, Mar 07, 2011 at 04:40:39PM -0500, Mathieu Bouchard wrote:
PS: the [delwrite~] clear method
http://sourceforge.net/tracker/?func=detail&aid=3170987&group_id=557... is still assigned to "nobody", because it's waiting for any of the five
project admins to click on a button... It also didn't appear on
pd-dev@iem.at either :
http://lists.puredata.info/pipermail/pd-dev/2011-02/thread.html
Do you think that what you have written above is likely to increase or decrease your chances of getting those patches accepted more quickly? I ask this question sincerely.
Cheers,
Chris.
--- On Tue, 3/8/11, Chris McCormick chris@mccormick.cx wrote:
From: Chris McCormick chris@mccormick.cx Subject: Re: [PD] Get list of a the arguments of a patch without using any external? To: pd-list@iem.at Date: Tuesday, March 8, 2011, 5:56 AM On Mon, Mar 07, 2011 at 03:07:08PM -0500, Mathieu Bouchard wrote:
On Mon, 7 Mar 2011, Miller Puckette wrote:
Sorry -- there's no way to do that!
Yes there is a way to do it, but it takes 5 hours to
find out how to do
it in pd, while it takes 5 minutes to edit the C code
so that people can
do it in pd in 5 seconds. But most of all it takes 0.5
second to write
"sorry".
On Mon, Mar 07, 2011 at 04:40:39PM -0500, Mathieu Bouchard wrote:
PS: the [delwrite~] clear method http://sourceforge.net/tracker/?func=detail&aid=3170987&group_id=557...
is still assigned to "nobody", because it's waiting
for any of the five
project admins to click on a button... It also didn't
appear on
pd-dev@iem.at
either :
http://lists.puredata.info/pipermail/pd-dev/2011-02/thread.html
Do you think that what you have written above is likely to increase or decrease your chances of getting those patches accepted more quickly? I ask this question sincerely.
I think a better question would be put to Miller or Hans, or the other
admins-- can someone please explain how the patch review process works?
Not only is the patch in question is now over a month old with no signs
of the review having begun, but it was submitted to the tracker in direct
response to a user's request for the feature. If there's a problem
with it there should at least be a relevant comment by this point.
-Jonathan
Cheers,
Chris.
Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On 2011-03-08 06:34, Jonathan Wilkes wrote:
I think a better question would be put to Miller or Hans, or the other admins-- can someone please explain how the patch review process works?
it's very simple: each patch is assigned to a person (well, let's assume it is). whenever the assignee feels like it, they would browse to sf.net and have a look at the patches that are assigned to them (and probably at patches that are not assigned to them, though it seems that they should) if they have a good they, they eventually apply a given patch (considering they like how it is done), fix a given bug (considering they find a way to do it) or just close an invalid report.
there is an agreement, that only miller manages the core Pd. (hence there are a lot of patches in the tracker submitted by hans or me or other "admins")
Not only is the patch in question is now over a month old with no signs of the review having begun, but it was submitted to the tracker in direct response to a user's request for the feature. If there's a problem with it there should at least be a relevant comment by this point.
indeed.
here comes the usual rant (you can safely skip it, if not in the mood): feel free to employ one (or several) of the people responsible for fixing your problems. then you can define the review process (e.g. that people have to react on an issue within a minimum time). you could even press them into accepting a given patch (or to come up with an alternative solution) since you are interested in getting a feature into core Pd, i suggest to hire miller. in the meantime you might have to accept that people have dynamic priorities which might not overlap with yours. end of the usual rant.
mfgasdr IOhannes
--- On Tue, 3/8/11, IOhannes m zmoelnig zmoelnig@iem.at wrote:
From: IOhannes m zmoelnig zmoelnig@iem.at Subject: Re: [PD] Get list of a the arguments of a patch without using any external? To: pd-list@iem.at Date: Tuesday, March 8, 2011, 9:51 AM -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On 2011-03-08 06:34, Jonathan Wilkes wrote:
I think a better question would be put to Miller or
Hans, or the other
admins-- can someone please explain how the patch
review process works?
it's very simple: each patch is assigned to a person (well, let's assume it is).
Ok, then the problem is equally simple: the patch in question is not currently assigned to anyone. Could someone choose the "millerpuckette" option on the tracker for patch id #3170987, please?
whenever the assignee feels like it, they would browse to sf.net and have a look at the patches that are assigned to them (and probably at patches that are not assigned to them, though it seems that they should) if they have a good they, they eventually apply a given patch (considering they like how it is done), fix a given bug (considering they find a way to do it) or just close an invalid report.
there is an agreement, that only miller manages the core Pd. (hence there are a lot of patches in the tracker submitted by hans or me or other "admins")
Not only is the patch in question is now over a month
old with no signs
of the review having begun, but it was submitted to
the tracker in direct
response to a user's request for the feature. If
there's a problem
with it there should at least be a relevant comment by
this point.
indeed.
here comes the usual rant (you can safely skip it, if not in the mood): feel free to employ one (or several) of the people responsible for fixing your problems. then you can define the review process (e.g. that people have to react on an issue within a minimum time). you could even press them into accepting a given patch (or to come up with an alternative solution) since you are interested in getting a feature into core Pd, i suggest to hire miller. in the meantime you might have to accept that people have dynamic priorities which might not overlap with yours. end of the usual rant.
mfgasdr IOhannes -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
iEYEARECAAYFAk117h4ACgkQkX2Xpv6ydvTWkwCfVLcnqV/EGjPTwBB/1axkjWqO mbcAoJRpq/abzebKGhZ5gJKPNz1EDRG1 =7Tww -----END PGP SIGNATURE-----
-----Inline Attachment Follows-----
Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
On Tue, 8 Mar 2011, IOhannes m zmoelnig wrote:
it's very simple: each patch is assigned to a person (well, let's assume it is).
Why can we assume that each patch has been assigned to a person ? (What has to happen before that step ?)
whenever the assignee feels like it, they would browse to sf.net and have a look at the patches that are assigned to them if they have a good they, they eventually apply a given patch (considering they like how it
Can you write us what you meant to write instead of "have a good they,".
| Mathieu Bouchard ---- tél: +1.514.383.3801 ---- Villeray, Montréal, QC
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On 2011-03-08 20:08, Mathieu Bouchard wrote:
On Tue, 8 Mar 2011, IOhannes m zmoelnig wrote:
it's very simple: each patch is assigned to a person (well, let's assume it is).
Why can we assume that each patch has been assigned to a person ? (What has to happen before that step ?)
it has to get assigned to a person. this can either be done at commit time or later.
Can you write us what you meant to write instead of "have a good they,".
i meant to write "have a good day", meaing "if they feel like it" (but trying to avoid phrase duplication), really meaning that looking (and reacting) on the bug-tracker is a good-will action of the assignee.
fgasdr IOhannes
On Wed, 9 Mar 2011, IOhannes m zmoelnig wrote:
On 2011-03-08 20:08, Mathieu Bouchard wrote:
Why can we assume that each patch has been assigned to a person ? (What has to happen before that step ?)
it has to get assigned to a person. this can either be done at commit time or later.
Excuse me ? I thought that the process of assignation was just so that each ticket is handled by the person most competent for the topic of the bug report or patch (and sometimes to ensure that no person gets overloaded with tickets).
If not, then what is the purpose of assigning tickets ?
« At commit time or later » instead sounds like the time for closing the ticket.
| Mathieu Bouchard ---- tél: +1.514.383.3801 ---- Villeray, Montréal, QC
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On 2011-03-09 15:25, Mathieu Bouchard wrote:
it has to get assigned to a person. this can either be done at commit time or later.
Excuse me ? I thought that the process of assignation was just so that each ticket is handled by the person most competent for the topic of the bug report or patch (and sometimes to ensure that no person gets overloaded with tickets).
If not, then what is the purpose of assigning tickets ?
so who is the most competent person for a certain ticket? and can we expect a submitter to know? (e.g. if they haven't read the book of rules in pd-dev)
for example, people tend to assign all sorts of tickets to hans, just because they are using pd-extended and hans is somewhat prominently responsible for this. it doesn't mean that he is the most competent person for fixing a problem with, e.g. mrpeach/net
« At commit time or later » instead sounds like the time for closing the ticket.
so the "or later" was meant as a backdoor in my argumentation to allow re-assignment of ill-assigned topics or assignment of non-assigned topics. "commit time" referred to the time where the ticket was initially opened (which might not have been clear either)
fgmadr IOhannes
On Wed, 9 Mar 2011, IOhannes m zmoelnig wrote:
so who is the most competent person for a certain ticket? and can we expect a submitter to know?
There is no book.
I don't know what you mean. I don't recall ever allowed to assign anything to anyone, in the 6 years or so that I had been on SF.net/projects/pure-data. I assume that it stayed the same ever after I cancelled my SF.net account.
So, I assumed that one of the admins' first task was to filter through the new tickets to weed out spam, mistakes, and dispatch according to how members want to get the tasks split. I took "assigned to" as being a sign that the admins are approving the issue for further consideration.
So why do you say that if non-admins aren't allowed to select "assigned to" ? And then obviously, if I'm talking about getting someone to set the "assigned to" status, does it look like I'm talking about submitters setting their own "assigned to" ? I'm talking about why don't admins do any kind of dispatch.
(e.g. if they haven't read the book of rules in pd-dev)
There is no such book.
"commit time" referred to the time where the ticket was initially opened (which might not have been clear either)
Ah ok. I never see the word "commit" used for that.
| Mathieu Bouchard ---- tél: +1.514.383.3801 ---- Villeray, Montréal, QC
On Mon, Mar 07, 2011 at 09:34:52PM -0800, Jonathan Wilkes wrote:
--- On Tue, 3/8/11, Chris McCormick chris@mccormick.cx wrote:
Do you think that what you have written above is likely to increase or decrease your chances of getting those patches accepted more quickly? I ask this question sincerely.
I think a better question would be put to Miller or Hans, or the other admins-- can someone please explain how the patch review process works?
Good question. I was happy to read IOhanne's reply.
Not only is the patch in question is now over a month old with no signs of the review having begun, but it was submitted to the tracker in direct response to a user's request for the feature. If there's a problem with it there should at least be a relevant comment by this point.
This is not realistic. If you look at any large FLOSS project, patches lie dormant, are ignored, are rejected for the wrong reasons all of the time. Submit a patch to the Linux kernel and see what happens. Most likely it will be silently dropped.
In my experience, the best way to get a patch accepted in most projects is to invest time in engaging socially. The reality is that often the onus is on the submitter to advocate for their patch. In this case a sensible place to do that would be pd-dev list. Demanding that your patch is more important than the other things a volunteer-maintainer might need to do with their time (like real life engagements), and is more important than other patches in the queue seems like an unlikely way to get patches accepted.
Likewise if you somehow imply that the maintainer owes you something and that they are not doing some kind of job properly. The people on the other end have given up thousands of hours of their time as volunteers and released all of that work for free, and they are often busy with other things in their lives. Is it really so much to ask of eachother a little patience and respect?
Seriously, I find it weird that I even have to write this.
I speak only for myself and my own observations. I have no idea what any of the other people involved think about this (except IOhannes who replied more succinctly than me, and with whom I agree).
Cheers,
Chris.
On Tue, 8 Mar 2011, Chris McCormick wrote:
This is not realistic. If you look at any large FLOSS project, patches lie dormant, are ignored, are rejected for the wrong reasons all of the time. Submit a patch to the Linux kernel and see what happens. Most likely it will be silently dropped.
Do you mean we have to adopt and accept the same problems that are sure signs of a project's overwhelming success ? Would that bring us overwhelming success too ?
In my experience, the best way to get a patch accepted in most projects is to invest time in engaging socially. The reality is that often the onus is on the submitter to advocate for their patch.
Don't you think a lot more patches would go through if the users wanting the features weren't sitting around saying things like "the onus is on the submitter" or just being quiet, and instead promoted the patches ?
In a large project, people have the luxury to say things like "the onus is on the submitter", because if that scares away 1000 developers, there's another 1000 developers working on the project anyway.
In this case a sensible place to do that would be pd-dev list.
I don't see the connection between babbling on pd-dev and getting a patch approved by someone who rarely writes on pd-dev.
Demanding that your patch is more important than the other things a volunteer-maintainer might need to do with their time
I thought you were trying to be realistic about the situation. We need not invent additional problems.
Likewise if you somehow imply that the maintainer owes you something
Likewise if you somehow imply that a patch-submitter is bound by some kind of onus, so that he does your promotion job for you, for inclusion in a branch he doesn't need, for a patch he doesn't need either...
Seriously, I find it weird that I even have to write this.
You don't "have" to.
I speak only for myself and my own observations.
| Mathieu Bouchard ---- tél: +1.514.383.3801 ---- Villeray, Montréal, QC
On Tue, Mar 08, 2011 at 12:31:43PM -0500, Mathieu Bouchard wrote:
On Tue, 8 Mar 2011, Chris McCormick wrote:
This is not realistic. If you look at any large FLOSS project, patches
lie dormant, are ignored, are rejected for the wrong reasons all of the time. Submit a patch to the Linux kernel and see what happens. Most
likely it will be silently dropped.Do you mean we have to adopt and accept the same problems that are sure
signs of a project's overwhelming success ? Would that bring us
overwhelming success too ?
No, that is not my point. I'm sorry I was unclear. I meant to show a causal chain that does exist in most FLOSS projects, including Pd. I did not mean to advocate a particular style of software management, or the adoption and acceptance of any problems.
The causal chain works like this:
- You desire to contribute a patch to the project.
- You post the patch and advocate it.
- In advocating you avoid antagonising those who will do the applying.
- Eventually the patch might be applied.
In my experience, the best way to get a patch accepted in most projects is to invest time in engaging socially. The reality is that often the
onus is on the submitter to advocate for their patch.Don't you think a lot more patches would go through if the users wanting the features weren't sitting around saying things like "the onus is on the submitter" or just being quiet, and instead promoted the patches ?
Yes, that is almost certainly true. At last I have found a new years resolution, thank you.
So now we have two ways to help patches go through:
- Promote patches that you want to be applied.
- Don't be a jerk.
In a large project, people have the luxury to say things like "the onus
is on the submitter", because if that scares away 1000 developers, there's another 1000 developers working on the project anyway.
I hope I have not scared away any developers. That is the opposite of my intention.
In this case a sensible place to do that would be pd-dev list.
I don't see the connection between babbling on pd-dev and getting a patch approved by someone who rarely writes on pd-dev.
Consider this mechanism:
- You convince yourself to write in a less hostile way.
- You promote your patches on pd-dev (sure, "babbling").
- Hans applies your patch to his version.
- Miller pulls the change from Hans' version.
- Everybody wins.
Realistic? To me it seems more likely to get a patch applied than active hostility.
Demanding that your patch is more important than the other things a
volunteer-maintainer might need to do with their timeI thought you were trying to be realistic about the situation. We need not invent additional problems.
I was referring to this statement:
"PS: the [delwrite~] clear method is still assigned to 'nobody', because it's waiting for any of the five project admins to click on a button..."
http://en.wikipedia.org/wiki/Ellipsis http://en.wikipedia.org/wiki/Aposiopesis
It implies that the application of the [delwrite~] clear method patch has been too slow for your liking, which implies that the five project admins should have found the application of the [delwrite~] clear method more important than whatever it is they have been doing which isn't clicking that button.
"Demanding" is too strong a word. I'm sorry that I used that word. Probably I should have written "implying".
Likewise if you somehow imply that the maintainer owes you something
Likewise if you somehow imply that a patch-submitter is bound by some kind of onus, so that he does your promotion job for you, for inclusion in a branch he doesn't need, for a patch he doesn't need either...
I'm sorry, this was badly phrased. I meant to say that given the condition that the patch submitter wants their patch to be merged, then the onus is on the patch submitter to advocate for acceptance of the patch.
Because you submitted the patch to the patch tracker, and then complained that nobody had clicked the button, I assumed that you wanted the patch applied. Your statement "for a patch he doesn't need either..." indicates that you actually aren't interested in the patch being applied. If this is indeed the case, please feel free to resume your normal trend of thinly veiled insolence.
You are correct that anyone who wants the patch applied should also do the job of promoting the patch. I am convinced by that argument.
Seriously, I find it weird that I even have to write this.
You don't "have" to.
You are correct, that was badly phrased.
Cheers,
Chris.
On Wed, 9 Mar 2011, Chris McCormick wrote:
"PS: the [delwrite~] clear method is still assigned to 'nobody', because it's waiting for any of the five project admins to click on a button..." It implies that the application of the [delwrite~] clear method patch has been too slow for your liking, which implies that the five project admins should have found the application of the [delwrite~] clear method more important than whatever it is they have been doing which isn't clicking that button.
Ok, you are all too determined to see something wrong in whatever I say about the admins. I'm really sorry I spent lots of time trying to answer this last mail in detail. I just deleted a dozen paragraphs that I spent plenty of time on, being puzzled, thinking about, and thinking that it might matter at all. I'm not gonna say how long I spent on it or your other mails because it's embarrassingly too much.
| Mathieu Bouchard ---- tél: +1.514.383.3801 ---- Villeray, Montréal, QC
On Thu, Mar 10, 2011 at 12:43:01PM -0500, Mathieu Bouchard wrote:
On Wed, 9 Mar 2011, Chris McCormick wrote:
"PS: the [delwrite~] clear method is still assigned to 'nobody', because it's waiting for any of the five project admins to click on a button..." It implies that the application of the [delwrite~] clear method patch has been too slow for your liking, which implies that the five project admins should have found the application of the [delwrite~] clear method more important than whatever it is they have been doing which isn't clicking that button.
Ok, you are all too determined to see something wrong in whatever I say
about the admins. I'm really sorry I spent lots of time trying to answer
this last mail in detail. I just deleted a dozen paragraphs that I spent
plenty of time on, being puzzled, thinking about, and thinking that it
might matter at all. I'm not gonna say how long I spent on it or your
other mails because it's embarrassingly too much.
Ok, I apologise, I'll hand back my badge and banana. I'm quitting the Just Be Nice Police.
Chris.
On Tue, 8 Mar 2011, Chris McCormick wrote:
Do you think that what you have written above is likely to increase or decrease your chances of getting those patches accepted more quickly?
If I hadn't written it, I wouldn't have been reminded of the existence of the delwrite patch in a manner that would have caused me to ask about it on pd-list, and I guess that no-one else would have done it anytime soon.
Apparently, the auto-forward to pd-dev@iem.at automatically ignores mail written without a sourceforget account, and I'm the first person to notice it, and everybody else relies on pd-dev for notifications about all new patches, because they assume that it works 100 % of the time, and that's what I'd assume too.
| Mathieu Bouchard ---- tél: +1.514.383.3801 ---- Villeray, Montréal, QC
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On 2011-03-08 08:02, Mathieu Bouchard wrote:
On Tue, 8 Mar 2011, Chris McCormick wrote:
Do you think that what you have written above is likely to increase or decrease your chances of getting those patches accepted more quickly?
If I hadn't written it, I wouldn't have been reminded of the existence of the delwrite patch in a manner that would have caused me to ask about it on pd-list, and I guess that no-one else would have done it anytime soon.
iirc, this was discussed on the pd-dev list prior to enabling the "feature".
gamdr IOhannes
On Tue, 8 Mar 2011, IOhannes m zmoelnig wrote:
iirc, this was discussed on the pd-dev list prior to enabling the "feature".
Is reading pd-dev a requirement for people who submit to the patchtracker ?
| Mathieu Bouchard ---- tél: +1.514.383.3801 ---- Villeray, Montréal, QC
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On 2011-03-08 09:47, Mathieu Bouchard wrote:
On Tue, 8 Mar 2011, IOhannes m zmoelnig wrote:
iirc, this was discussed on the pd-dev list prior to enabling the "feature".
Is reading pd-dev a requirement for people who submit to the patchtracker ?
i don't think so.
however, if people complain that there posts are not processed in the way they imagine that they should, they might want to familiarize themselves with the way others imagine it.
fgmasdr IOhannes
On Tue, 8 Mar 2011, IOhannes m zmoelnig wrote:
On 2011-03-08 09:47, Mathieu Bouchard wrote:
On Tue, 8 Mar 2011, IOhannes m zmoelnig wrote:
iirc, this was discussed on the pd-dev list prior to enabling the "feature".
Is reading pd-dev a requirement for people who submit to the patchtracker ?
i don't think so. however, if people complain that there posts are not processed in the way they imagine that they should, they might want to familiarize themselves with the way others imagine it.
How does that not mean "I think so" ?
How would anyone find out about the rule, other than reading a few years of pd-dev until stumbling upon that thread ; or writing a mail that will be interpreted as being a "complaint" simply because "report" and "inquiry" aren't in the vocabulary ?
| Mathieu Bouchard ---- tél: +1.514.383.3801 ---- Villeray, Montréal, QC
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On 2011-03-08 20:16, Mathieu Bouchard wrote:
On Tue, 8 Mar 2011, IOhannes m zmoelnig wrote:
On 2011-03-08 09:47, Mathieu Bouchard wrote:
On Tue, 8 Mar 2011, IOhannes m zmoelnig wrote:
iirc, this was discussed on the pd-dev list prior to enabling the "feature".
Is reading pd-dev a requirement for people who submit to the patchtracker ?
i don't think so. however, if people complain that there posts are not processed in the way they imagine that they should, they might want to familiarize themselves with the way others imagine it.
How does that not mean "I think so" ?
you don't have to know that issues in the tracker are forwarded to pd-dev, in order to submit issues.
if you are using the tracker to send emails to pd-dev without having to be subscribed, then you are obviously trying to tweak rules of pd-dev. if you try to tweak the rules, then you should probably know them.
How would anyone find out about the rule, other than reading a few years of pd-dev until stumbling upon that thread ; or writing a mail that will be interpreted as being a "complaint" simply because "report" and "inquiry" aren't in the vocabulary ?
why do you insist in having explicit knowledge about the rules?
i keep submitting bugs and patches to other projects at sourceforge, and i couldn't care less whether these tickets are automatically forwarded to some email address or not. i don't know the tracker rules of these projects. but i see that there _is_ a tracker, and hope that someone will eventually read it (when they find time). that's it.
(i find that trackers that contain 5 or less items are usually worthless (except for very young projects), as they seem to be not used at all but have been created automatically and nobody turned them off; with projects that have many issues, and many of them closed, i usually assume that the tracker is in active use and eventually somebody responsible will have a look at my issue)
fmgasdr IOhannes
On Wed, 9 Mar 2011, IOhannes m zmoelnig wrote:
you don't have to know that issues in the tracker are forwarded to pd-dev, in order to submit issues.
Right, but how do i figure out whether my issue has been seen by anyone at all ? I'm trying to find out the way I can.
if you are using the tracker to send emails to pd-dev without having to be subscribed, then you are obviously trying to tweak rules of pd-dev. if you try to tweak the rules, then you should probably know them. [...] why do you insist in having explicit knowledge about the rules?
Because I believe that the tracker and pd-dev are run by people who value openness of information and enjoy contributions from outsiders.
If the rules aren't written down in a list of rules, there are no rules.
i keep submitting bugs and patches to other projects at sourceforge, and i couldn't care less whether these tickets are automatically forwarded to some email address or not. i don't know the tracker rules of these projects. but i see that there _is_ a tracker, and hope that someone will eventually read it (when they find time). that's it.
Do you mean that other submitters ought to follow your example of not caring about where your efforts are going ?
| Mathieu Bouchard ---- tél: +1.514.383.3801 ---- Villeray, Montréal, QC
On 03/12/2011 05:34 PM, Mathieu Bouchard wrote:
If the rules aren't written down in a list of rules, there are no rules.
indeed there are none.
afair, it was you who brought up the term "rules".
i am trying to explain the process how tracker items are currently handled. i'm not saying that this how it should be, nor that it is the "best" way (neither do i say the opposite)
mfadsr IOhannes
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On 2011-03-07 17:50, Alexandre Quessy wrote:
Hello everyone, I was wondering if there is a way in pure-vanilla Pd to retrieve the list of arguments of an abstraction. I use zexy's [dollarg] for this,
most likely not, as there is no such object in zexy (there is one in iemlib though, which you probably mean; iemguts comes with it's own version of the object)
but I'm making an effort to see if I can use Pd vanilla only for some abstractions. Is there a way to do this in Pd vanilla?
well, it seems like this is something that can be done via externals, but hardly via abstractions, hence the existence of [dollarg] and the like.
otoh, you can test whether a certain named argument is present and use this. see: http://lists.puredata.info/pipermail/pd-list/2008-10/065465.html http://lists.puredata.info/pipermail/pd-list/2008-11/066293.html
fgmasdr IOhannes
Hello Alexandre,
I just try to write an abstraction. I don't know if it could help you, it is just a try. ++
Jack
Le lundi 07 mars 2011 à 11:50 -0500, Alexandre Quessy a écrit :
Hello everyone, I was wondering if there is a way in pure-vanilla Pd to retrieve the list of arguments of an abstraction. I use zexy's [dollarg] for this, but I'm making an effort to see if I can use Pd vanilla only for some abstractions. Is there a way to do this in Pd vanilla?
Thanks,
Alexandre Quessy http://alexandre.quessy.net/
Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
On Mon, 7 Mar 2011, Jack wrote:
I just try to write an abstraction. I don't know if it could help you, it is just a try.
Doesn't work with arguments that contain $0 or $1 or such.
| Mathieu Bouchard ---- tél: +1.514.383.3801 ---- Villeray, Montréal, QC
-
Alexandre Quessy -
Chris McCormick -
IOhannes m zmoelnig -
IOhannes zmölnig
-
Ivica Ico Bukvic -
Jack -
Jonathan Wilkes -
Mathieu Bouchard -
Miller Puckette