Aren't we talking about a trivial few lines of code here:* new list family class boilerplate

• loop through the input atom vector and output each of its atoms in sequence (prefixed by the "list" selector, of course)* output a bang to a second outlet when finished* consider whether it should be able to output in reverse as well?

If that's all [list foreach] is supposed to do I'll go ahead and implement this in Pd-l2ork when I get a spare 10 mins. -Jonathan

 On Wednesday, October 1, 2014 3:43 PM, Joe White <white.joe4@gmail.com> wrote:

+1

On 1 October 2014 14:20, Dan Wilcox danomatika@gmail.com wrote:

+1 On Sep 30, 2014, at 9:39 PM, pd-list-request@lists.iem.at wrote:

The addition of the symbol/list methods made me think, that maybe now could be a time to add these as well, or at least the important "foreach".

Ciao --  Frank Barknecht                                     _ ______footils.org__

--------Dan Wilcox@danomatikadanomatika.comrobotcowboy.com

Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list

Here is one:

1. Don't check the type of the atoms. Just output inside the loop using outlet_list That way you don't have to care if there happen to be other types of atoms (like gpointers, blobs, etc.)

To complete it in 10 mins:

1. git diff filename.pd > whatever.patch
2. submitting patch to tracker == emailing Miller and list (if not then you must have left something out of your general outline of free software dev process)

-Jonathan

On Friday, October 10, 2014 2:00 AM, Chris McCormick chris@mccormick.cx wrote:

On 02/10/14 09:24, Jonathan Wilkes via Pd-list wrote:

If that's all [list foreach] is supposed to do I'll go ahead and implement this in Pd-l2ork when I get a spare 10 mins.

The actual code took me about half an hour to adapt from other list objects. I realise that is slow. What took a bit longer was:

• Updating the help patch.
• Making the correctly formatted patch.
• Submitting the patch to Sourceforge.
• Emailing Miller and the list.

The patch may well come back with comments in which case that time will be longer. My patch lacks some of the features you outlined. Would have taken me longer if I had added those features too. I feel like "spare 10 mins" is lowballing the time required in any case and maybe that is one of the reasons nobody else did it.

Note that if you implemented it with your specification in Pd-l2ork and I implemented it my way and it got accepted into Pd-miller then we would have incompatible binaries. Urgk! I guess that's an advantage of mailing list consensus before action.

Cheers,

Chris.

Unfortunately there's no easy step for the help patch documentation. I'm the documentation guy, and even I left it out of my 10min estimate.

Miller has replied saying he's 100% busy.

As a process, what do you do during the 11 months out of the year that he isn't working on Pd?

So let's recap: you've spent 30mins+ on a patch that he most likely will not accept, for reasons he hasn't stated. Do you see now why this thread is full of "+1" and "it'd be great if" rather than actual development by capable developers?

If we're going to be developing within a whim-based environment, I'd much rather aim my efforts at the version where the busy gatekeeper tends to say "gee thanks".

Still, do work on a "Tidy Up" if you have excess dev energy. It would be great to have anything better in Vanilla. If it's better than what's currently in Pd-l2ork I'll push it there, too.

-Jonathan

On Friday, October 10, 2014 3:53 AM, Chris McCormick chris@mccormick.cx wrote:

On 10/10/14 15:31, Jonathan Wilkes via Pd-list wrote:

Here is one:

1. Don't check the type of the atoms. Just output inside the loop using

outlet_list That way you don't have to care if there happen to be other types of atoms (like gpointers, blobs, etc.)

Good tip, thanks! I took my cue from other Pd objects like "pack" and "spigot" here and I thought this was closest to what Miller might want. I may well be wrong though! I guess I'll find out if my trivial patch is ever looked at.

To complete it in 10 mins:

1. git diff filename.pd > whatever.patch

I use the method suggested on puredata.info which is git format-patch HEAD^ and captures all of the changes I have made, but same thing basically.

Note that a git format-patch also includes git meta information meaning when Miller merges it it goes in as if it was a commit to his branch made by you.

You didn't have the step in here for updating the help patch.

2. submitting patch to tracker == emailing Miller and list (if not then

you must have left something out of your general outline of free software dev process)

This is part of my point. In the past when I have just submitted a patch to the tracker it often doesn't get noticed. Hans gave me a tip that if I email Miller directly with the patch and ask his opinion etc. I am much more likely to get it looked at. This turned out to be true, which is why I include that step separately in what I wrote.

Puredata.info seems to be down right now but once it is back up I will add my preaching points to whatever wiki they best belong in.

Cheers,

Chris.