On 27/03/14 06:42, Bram Moolenaar wrote:
Since many plugins consist of several files, and we would like to check
the dependencies before downloading all the files, the best place for
these dependencies is to have them in a separate manifest file.
Another advantage is that there would be one
On 26 March 2014, Bram Moolenaar b...@moolenaar.net wrote:
lcd wrote:
[...]
I'm not saying we should change how uniq() works now, but add an
optional parameter that would tell it to switch modes.
There is a case for stable uniques, where the list is left
in the initial order, but
Bram Moolenaar wrote:
I'm thinking of a kind of manifest that specifies these dependencies.
When we standardize that it's still possible to use a choice of plugin
managers.
FWIW, GLVS (getscript) supports plugin dependencies. A number of my
plugins have lines such as
On 26 March 2014, LCD 47 lcd...@gmail.com wrote:
[...]
FWIW, I have a preliminary implementation, and I ran a few
benchmarks. Here are few numbers:
[...]
Patch attached below. The patch adds an optional parameter {mode}
to uniq():
uniq({list} [, {mode} [, {func} [, {dict}]]])
Charles Campbell wrote:
Bram Moolenaar wrote:
I'm thinking of a kind of manifest that specifies these dependencies.
When we standardize that it's still possible to use a choice of plugin
managers.
FWIW, GLVS (getscript) supports plugin dependencies. A number of my
plugins have
lcd wrote:
On 21 March 2014, Cade Forester ahx2...@gmail.com wrote:
How about separating it from sort()? That is, an uniq()
function that would remove duplicates from an already sorted list
(results would be undefined if the input list is not sorted). That
would be consistent
On 25 March 2014, Bram Moolenaar b...@moolenaar.net wrote:
lcd wrote:
On 21 March 2014, Cade Forester ahx2...@gmail.com wrote:
How about separating it from sort()? That is, an uniq()
function that would remove duplicates from an already sorted
list (results would be undefined
On 25 March 2014, LCD 47 lcd...@gmail.com wrote:
On 25 March 2014, Bram Moolenaar b...@moolenaar.net wrote:
lcd wrote:
On 21 March 2014, Cade Forester ahx2...@gmail.com wrote:
How about separating it from sort()? That is, an uniq()
function that would remove duplicates
lcd wrote:
On 21 March 2014, Cade Forester ahx2...@gmail.com wrote:
How about separating it from sort()? That is, an uniq()
function that would remove duplicates from an already sorted
list (results would be undefined if the input list is not
sorted). That would be
On 25 March 2014, Bram Moolenaar b...@moolenaar.net wrote:
lcd wrote:
On 21 March 2014, Cade Forester ahx2...@gmail.com wrote:
How about separating it from sort()? That is, an uniq()
function that would remove duplicates from an already sorted
list (results would be
lcd wrote:
Thanks. Any comment about the red-black trees? The resulting
uniq() function should be about as fast as sort(), but having the tree
operations implemented as macros would make the code a little awkward.
/lcd
I don't think that uniq should use a red-black tree.
It should
LCD 47 wrote:
On 19 March 2014, Cade Forester ahx2...@gmail.com wrote:
Looks like you made a copy of f_sort() and modified it a bit. That's a
lot of duplicate code. Better move the common stuff into a function
that's used by both sort() and sortuniq().
Fixed
How about separating it
On Mar 25, 2014 11:41 PM, Charles E Campbell drc...@campbellfamily.biz
wrote:
LCD 47 wrote:
On 19 March 2014, Cade Forester ahx2...@gmail.com wrote:
Looks like you made a copy of f_sort() and modified it a bit. That's a
lot of duplicate code. Better move the common stuff into a function
On 25 March 2014, Dominique Pellé dominique.pe...@gmail.com wrote:
lcd wrote:
Thanks. Any comment about the red-black trees? The resulting
uniq() function should be about as fast as sort(), but having the
tree operations implemented as macros would make the code a little
awkward.
On 25 March 2014, LCD 47 lcd...@gmail.com wrote:
[...]
I'm attaching bellow my attempt to a fix. I also merged f_sort()
and f_uniq() in a single function, and made some minor optimisations.
[...]
+static int (*item_compare_func_ptr)__ARGS((const void *, const void
*s2));
[...]
Bram said:
Thanks. I'll add it in the todo list. Although we may add uniq() instead.
Consistancy with Unix is useful.
I just wanted to weigh in on the idea of adding uniq() instead of sortuniq().
The modularity of Unix commands is great and all, but when working with big
data sets you
I think some of us would be rather surprised if the result weren't
[1,2,3].
Well, the more experienced among us would know that full (unsorted)
unique would be nice, but expensive. :)
It eluded my mind that vimscript aims at high performance computing. I was
talking about user
On Fr, 21 Mär 2014, LCD 47 wrote:
On 21 March 2014, lith minil...@gmail.com wrote:
In other words, I'd expect this for example:
:echo uniq([1, 2, 3, 3, 2, 2, 1])
[1, 2, 3, 2, 1]
I think some of us would be rather surprised if the result weren't
[1,2,3].
Well, the
Cade Forester wrote:
Looks like you made a copy of f_sort() and modified it a bit. That's a
lot of duplicate code. Better move the common stuff into a function
that's used by both sort() and sortuniq().
Fixed
Thanks. I'll add it in the todo list. Although we may add uniq()
instead.
On 22 March 2014, Michael Reiland michael.reil...@gmail.com wrote:
On 3/22/2014 12:51 PM, LCD 47 wrote:
[...]
Well, there is another function I seem to be reinventing over
and over again, namely any() (returns true if all items in a list or
dict meet a criterion).
[...]
Did you misspeak
How about separating it from sort()? That is, an uniq() function
that would remove duplicates from an already sorted list (results would
be undefined if the input list is not sorted). That would be consistent
with how uniq(1) works on UNIX.
This patch add uniq() function.
LCD 47 lcd...@gmail.com wrote:
On 19 March 2014, Cade Forester ahx2...@gmail.com wrote:
Looks like you made a copy of f_sort() and modified it a bit. That's a
lot of duplicate code. Better move the common stuff into a function
that's used by both sort() and sortuniq().
Fixed
In other words, I'd expect this for example:
:echo uniq([1, 2, 3, 3, 2, 2, 1])
[1, 2, 3, 2, 1]
I think some of us would be rather surprised if the result weren't [1,2,3].
--
--
You received this message from the vim_dev maillist.
Do not top-post! Type your reply below the text you are
On 21 March 2014, Cade Forester ahx2...@gmail.com wrote:
How about separating it from sort()? That is, an uniq()
function that would remove duplicates from an already sorted list
(results would be undefined if the input list is not sorted). That
would be consistent with how uniq(1)
On 19 March 2014, Cade Forester ahx2...@gmail.com wrote:
Looks like you made a copy of f_sort() and modified it a bit. That's a
lot of duplicate code. Better move the common stuff into a function
that's used by both sort() and sortuniq().
Fixed
How about separating it from
Cade Foster wrote:
Function sortuniq() for sort and remove duplicates.
Looks like you made a copy of f_sort() and modified it a bit. That's a
lot of duplicate code. Better move the common stuff into a function
that's used by both sort() and sortuniq().
--
A M00se once bit my sister ...
Looks like you made a copy of f_sort() and modified it a bit. That's a
lot of duplicate code. Better move the common stuff into a function
that's used by both sort() and sortuniq().
Fixed
--
--
You received this message from the vim_dev maillist.
Do not top-post! Type your reply below
Function sortuniq() for sort and remove duplicates.
--
--
You received this message from the vim_dev maillist.
Do not top-post! Type your reply below the text you are replying to.
For more information, visit http://www.vim.org/maillist.php
---
You received this message because you are
28 matches
Mail list logo
