Re: [PATCH 0/2] Merge Leslie Polzer's SOC 2007 changes for better ARG_MAX support

2009-04-21 Thread Leslie P. Polzer
> On Sun, Apr 12, 2009 at 1:21 PM, James Youngman wrote: >> This patch applies part of Leslie P. Polzer's project for the Google >> Summer of Code 2007. Very nice, I hope it'll be useful for people. Leslie -- LinkedIn Profile: http://www.linkedin.com/in/polzer Xing Profile: https://www.xing

Re: [PATCH 0/2] Merge Leslie Polzer's SOC 2007 changes for better ARG_MAX support

2009-04-20 Thread James Youngman
#x27;s SOC 2007 changes for better ARG_MAX support > >  ChangeLog      |   46 +++ >  NEWS           |   21 +++- >  find/defs.h    |    2 +- >  find/pred.c    |    2 +- >  lib/buildcmd.c |  160 +--- >  lib/buil

[PATCH 0/2] Merge Leslie Polzer's SOC 2007 changes for better ARG_MAX support

2009-04-12 Thread James Youngman
This patch applies part of Leslie P. Polzer's project for the Google Summer of Code 2007. James Youngman (1): Avoid mixing declarations and statements. Leslie P. Polzer (1): Merge Leslie Polzer's SOC 2007 changes for better ARG_MAX support ChangeLog | 46 +++

[PATCH 1/2] Merge Leslie Polzer's SOC 2007 changes for better ARG_MAX support

2009-04-12 Thread James Youngman
From: Leslie P. Polzer 2008-03-23 Leslie Polzer Merge Leslie Polzer's ARG_MAX enhancements to xargs which were produced as part of the Google Summer of Code 2007. These changes fix Savannah bug #22708. * find/pred.c (launch): The struct buildcmd_co

Current version of ARG_MAX flexibility patch

2008-05-05 Thread James Youngman
This patch is my current merge of Leslie's 2007 SOC changes which made findutils more resilient to the fact that sometimes the system that findutils is running on has an actual arg max which is smaller than the compile-time ARG_MAX, or is computed sufficiently difficulty to defeat the pre

Re: ARG_MAX

2007-04-26 Thread James Youngman
On 4/26/07, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote: It looks slick, but I'm not sure whether that isn't too much overhead for the whole thing... after all the different strategies really only differ in one algorithm that has the same input and output. The overhead lies in the function poin

Re: ARG_MAX

2007-04-26 Thread leslie . polzer
On Thu, Apr 26, 2007 at 10:23:33AM +0100, James Youngman wrote: > I like your idea of separating the strategy (making decisions about > whether to exec now and start again, or add this argument to the > list) from the nuts and bolts of the implementation. Perhaps we couls > separate the buildcmd.c

Re: ARG_MAX

2007-04-26 Thread James Youngman
Obviously the runtime of that implementation of lin_suggest_argv_split is linear in the size of the input and that's unfortunate. But the constant factor would be small and I think we can fix the problem (moving to O(1)) just by changing the interface slightly later. I don't think it's a big dea

Re: ARG_MAX

2007-04-26 Thread James Youngman
On 4/26/07, Leslie P. Polzer <[EMAIL PROTECTED]> wrote: If there's sufficient time, the linear approach can be substituted by a binary one then (while still doing it only on-demand, of course). I like your idea of separating the strategy (making decisions about whether to exec now and start a

Re: ARG_MAX

2007-04-26 Thread James Youngman
On 4/26/07, Leslie P. Polzer <[EMAIL PROTECTED]> wrote: It would be even more efficient to store the last known value that worked somewhere. Perhaps /var/cache would be a good idea? It certainly could be more efficient that way, but I have an instinctive aversion to find modifying the filesyst

Re: ARG_MAX

2007-04-25 Thread Leslie P. Polzer
> Thanks. I've copied the bug-findutils@gnu.org mailing list, since > we're discussing design changes. I hope you don't mind. I never do :) > My main concern is the overhead of figuring out the ARG_MAX value. > [...] > To be honest, it mostly comes down

Re: ARG_MAX

2007-04-25 Thread James Youngman
r the benefit of list members: there are operating systems - including commercial Unix systems - on which the compile-time value of ARG_MAX is not a reliable guide as to how long a command line we can use. In the absence of a well-defined answer at compile time, we will have to behave appropriately in

[bug #16738] find does not subtract environment size from ARG_MAX

2006-08-05 Thread James Youngman
Update of bug #16738 (project findutils): Open/Closed:Open => Closed Fixed Release:None => 4.2.28 ___ Reply to this item at:

[bug #16738] find does not subtract environment size from ARG_MAX

2006-08-05 Thread James Youngman
Update of bug #16738 (project findutils): Status: In Progress => Fixed ___ Follow-up Comment #2: Fixed in the development code. The bug will be fixed in releases 4.2.28 (stable branch) and

[bug #16738] find does not subtract environment size from ARG_MAX

2006-07-24 Thread James Youngman
Additional Item Attachment, bug #16738 (project findutils): File name: sv-bug-16738.shSize:5 KB Updated updated script ___ Reply to this item at:

[bug #16738] find does not subtract environment size from ARG_MAX

2006-07-22 Thread James Youngman
Additional Item Attachment, bug #16738 (project findutils): File name: sv-bug-16738.shSize:5 KB Updated test script ___ Reply to this item at:

[bug #16738] find does not subtract environment size from ARG_MAX

2006-07-22 Thread James Youngman
Update of bug #16738 (project findutils): Severity: 3 - Normal => 4 - Important Status:None => In Progress Assigned to:None => jay ___

[bug #16738] find does not subtract environment size from ARG_MAX

2006-06-02 Thread Geoff Clare
URL: <http://savannah.gnu.org/bugs/?func=detailitem&item_id=16738> Summary: find does not subtract environment size from ARG_MAX Project: findutils Submitted by: geoffclare Submitted on: Friday 06/02/200

Re: cygwin xargs limitation: ARG_MAX depends on command

2005-09-21 Thread Bob Proulx
Eric Blake wrote: > Chris Faylor (one of the cygwin maintainers) proposed a benchmark that > times the entire operation, not just the xargs invocation: > http://sources.redhat.com/ml/cygwin-patches/2005-q3/msg00107.html > > His numbers, with a modified xargs that ignored the _SC_ARG_MAX limit, > s

Re: cygwin xargs limitation: ARG_MAX depends on command

2005-09-21 Thread Eric Blake
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 According to Bob Proulx on 9/5/2005 3:33 PM: > If it is not too much trouble could you do post some simple benchmarks > showing that larger buffer sizes are significantly better than the 32k > buffer sizes? If so then it would help to promote your cas

Re: cygwin xargs limitation: ARG_MAX depends on command

2005-09-06 Thread James Youngman
mand line is passed using cygwin internal memory, and can easily be > several megabytes. But in the typical situation, the command lives on a > normal Windows mount, where the command line goes through the Windows API > CreateProcess which has a 32k limit. I believe that Cygwin should t

Re: cygwin xargs limitation: ARG_MAX depends on command

2005-09-05 Thread Eric Blake
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 According to Bob Proulx on 9/5/2005 3:33 PM: > > (export TIMEFORMAT='real %3lR user %3lU sys %3lS' > for i in 1024 2048 4096 8192 16384 20480; do > printf "timing $i: " > yes | head --bytes=10m | bash -c "time xargs -s$i /bin/echo > /dev

Re: cygwin xargs limitation: ARG_MAX depends on command

2005-09-05 Thread Bob Proulx
Eric Blake wrote: > But even if cygwin 1.5.19 were to define ARG_MAX and changes > sysconf(_SC_ARG_MAX) to 32k instead of 1 meg, this would unfairly > penalize cygexec mounts, which can handle much bigger command lines. I know this sounds like it would unfairly limit all uses because

cygwin xargs limitation: ARG_MAX depends on command

2005-09-05 Thread Eric Blake
X requires that ARG_MAX, if defined, be a constant, and that sysconf(_SC_ARG_MAX) be constant for the life of a process, as well as being no less than ARG_MAX if it was defined. Cygwin 1.5.18 does not define ARG_MAX, and sysconf(_SC_ARG_MAX) returns 1 meg, meaning that xargs violates the 32k li