Hi,
I had another look at this and thought of a few improvements I'd like
to include.
I added an rlimit check for open file descriptors. I also added some
clearer error messages and a few more tests.
Thanks,
Bo
From 093c965cbf5458c05c841ce1269499bd08aeff16 Mon Sep 17 00:00:00 2001
From:
On Tue, Apr 1, 2008 at 4:11 AM, Jim Meyering <[EMAIL PROTECTED]> wrote:
> So please see if you can find an option name that does not start with
> --merge, and, ideally, that doesn't influence interpretation of any
> other option abbreviations.
>
How about --batch-size. It doesn't have an initi
"Bo Borgerson" <[EMAIL PROTECTED]> wrote:
> + sort accepts a new option --merge-batch-size=NMERGE, where NMERGE
> + represents the maximum number of inputs that will be merged at once.
> + When more than NMERGE inputs are present temporary files are used.
I've just realized that adding --merge-
"Bo Borgerson" <[EMAIL PROTECTED]> wrote:
> Okay, I've added some tests and documentation as per your contribution
> guidelines.
Thanks!
One real bug: this should be "sizeof *ord":
> + size_t *ord = xnmalloc(nmerge, sizeof ord);
Some nits:
- s/int nmerge/unsigned int nmerge/
- in comments, re
Okay, I've added some tests and documentation as per your contribution
guidelines.
I realize it may be a little premature for a "signoff", but I want to
verify that I'm using the tools correctly.
Thanks,
Bo
From 70b1e98b5bbf119e9b14b63780c4d02769cdb8ea Mon Sep 17 00:00:00 2001
From: Bo Borgerson
Pádraig Brady <[EMAIL PROTECTED]> wrote:
> Also I would mention that to ammend a patch do:
>
> edit your files
> git commit --amend -e -a
> git format-patch --stdout --signoff HEAD~1 > your-branch.diff
Thanks.
I added a few words for that and pushed the new file
with the ungainly long name:
On Mon, Mar 31, 2008 at 11:05 AM, Pádraig Brady <[EMAIL PROTECTED]> wrote:
> Jim Meyering wrote:
> >
> > One more suggestion ;-)
> >
> > Add tests
>
> you beat me to it :)
>
> Also I would mention that to ammend a patch do:
>
> edit your files
> git commit --amend -e -a
> git format
"Bo Borgerson" <[EMAIL PROTECTED]> wrote:
> On Mon, Mar 31, 2008 at 2:29 AM, Paul Eggert <[EMAIL PROTECTED]> wrote:
> > Alas, that patch assumes C99, and we can't assume that quite yet.
> > Also, it mishandles nmerge values that are "too large" (you'll get
> > core dumps or worse on many host
"Bo Borgerson" <[EMAIL PROTECTED]> wrote:
> On Mon, Mar 31, 2008 at 2:29 AM, Paul Eggert <[EMAIL PROTECTED]> wrote:
> > Alas, that patch assumes C99, and we can't assume that quite yet.
> > Also, it mishandles nmerge values that are "too large" (you'll get
> > core dumps or worse on many host
"Bo Borgerson" <[EMAIL PROTECTED]> wrote:
> On Mon, Mar 31, 2008 at 2:29 AM, Paul Eggert <[EMAIL PROTECTED]> wrote:
> > Alas, that patch assumes C99, and we can't assume that quite yet.
> > Also, it mishandles nmerge values that are "too large" (you'll get
> > core dumps or worse on many host
On Mon, Mar 31, 2008 at 2:29 AM, Paul Eggert <[EMAIL PROTECTED]> wrote:
> Alas, that patch assumes C99, and we can't assume that quite yet.
> Also, it mishandles nmerge values that are "too large" (you'll get
> core dumps or worse on many hosts). That being said, it might be
> worth adding
Alas, that patch assumes C99, and we can't assume that quite yet.
Also, it mishandles nmerge values that are "too large" (you'll get
core dumps or worse on many hosts). That being said, it might be
worth adding an option like that (it's a bit specialized, but it's a
big performance win in some cas
12 matches
Mail list logo
