I did two speed tests of sort() with and without my patch
on my Linux box:
original patchedratio
test1 78.81 sec 81.06 sec1.03
test2 5.87 sec6.08 sec1.04
where 'original' is the revision adc4a84f72eb, and
'patched' is with my patch for eval.c.
It seems the overhe
On 2014/07/04, at 5:54, Bram Moolenaar wrote:
> Hmm, we need to fill an array with pointers, might as well add an int
> right after the pointer. Effectively this means sorting this struct:
>
> {
> void *ptr; /* the list element to be sorted */
> int idx; /* original pos
Jun T wrote:
> On 2014/07/03, at 2:06, Bram Moolenaar wrote:
>
> > + static intitem_compare_keep_zero;
>
> This variable is set to FALSE for the sort() function, and only set to
> TRUE for uniq(). Is this intentional?
Yes, uniq() needs the zero to decide elements are equal.
> Even i
On Thursday, July 3, 2014 2:39:30 AM UTC-5, Jun T. wrote:
>
> PS.
>
> What is the best way of referring to a previous post in this mailing list?
Probably, finding it on the Google Groups interface, and grabbing the link.
The drop-down menu next to the "reply" button on every list post has a "li
On 2014/07/03, at 2:06, Bram Moolenaar wrote:
> + static int item_compare_keep_zero;
This variable is set to FALSE for the sort() function, and only set to TRUE for
uniq(). Is this intentional?
Even if I set this variable to TRUE for sort(), the sort is still not stable
and test55 fails on my
Patch 7.4.351
Problem:sort() is not stable.
Solution: When the items are identical, compare the pointers.
Files: src/eval.c, src/testdir/test55.in, src/testdir/test55.ok
*** ../vim-7.4.350/src/eval.c 2014-06-25 17:31:04.942737863 +0200
--- src/eval.c 2014-07-02 18:52:19.102313288
