Re: --nest for nested argument files

[Ole Tange]

On Tue, May 3, 2011 at 6:08 PM, Ole Tange <tange@gnu.org> wrote:
> On Tue, May 3, 2011 at 4:25 PM, Hans Schou <chlor@schou.dk> wrote:
>> 2011/5/3 Ole Tange <tange@gnu.org>:
>
>>> Do you have a better idea for the syntax? Should it be default (and
>>> thus the current behaviour would require you to use --xapply)?
>>
>> I thought --nest was default. I suggest that --keeporder is changed to
>> be the one to use if you want to run line by line.
>
> If no one is using the current xapply-like functionality (I think I
> have used it once) then I will change the default to nesting and make
> the current behaviour available using --xapply.

For all you alpha-testers: The git version now can do:

$ parallel echo {1} {2} {3} :::: <(seq 1 3) <(seq 4 5) <(seq 6 7)
Name "main::opt_xapply" used only once: possible typo at src/parallel line 360.
1 4 6
2 4 6
3 4 6
1 5 6
2 5 6
3 5 6
1 4 7
1 5 7
2 4 7
2 5 7
3 4 7
3 5 7

It goes through all the combinations in a funky way because I try to
save memory by only generating the next command line when it is needed
instead of generating all combination before starting the first
command. It will also in the future make it possible to read from
pipes and if one pipe cannot deliver then parallel will try reading
from another pipe. It will therefore not wait for
slow_generating_command in this example:

$ parallel echo {1} {2} {3} :::: <(slow_generating_command)
<(fast_generating_command) <(slow_generating_command)

This part is not implemented, but just to let you know: The funky
combinations is by design.


/Ole