patch 7.0.190
Patch 7.0.190
Problem:syntax spell default results in an error message.
Solution: Change 4 to 7 for STRNICMP(). (Raul Nunez de Arenas Coronado)
Files: src/syntax.c
*** ../vim-7.0.189/src/syntax.c Wed Nov 1 12:43:07 2006
--- src/syntax.cSun Jan 21 13:12:19 2007
***
*** 3206,3212
curbuf-b_syn_spell = SYNSPL_TOP;
else if (STRNICMP(arg, notoplevel, 10) == 0 next - arg == 10)
curbuf-b_syn_spell = SYNSPL_NOTOP;
! else if (STRNICMP(arg, default, 4) == 0 next - arg == 4)
curbuf-b_syn_spell = SYNSPL_DEFAULT;
else
EMSG2(_(E390: Illegal argument: %s), arg);
--- 3206,3212
curbuf-b_syn_spell = SYNSPL_TOP;
else if (STRNICMP(arg, notoplevel, 10) == 0 next - arg == 10)
curbuf-b_syn_spell = SYNSPL_NOTOP;
! else if (STRNICMP(arg, default, 7) == 0 next - arg == 7)
curbuf-b_syn_spell = SYNSPL_DEFAULT;
else
EMSG2(_(E390: Illegal argument: %s), arg);
*** ../vim-7.0.189/src/version.cSun Feb 4 02:37:40 2007
--- src/version.c Sun Feb 4 02:40:23 2007
***
*** 668,669
--- 668,671
{ /* Add new patch number below this line */
+ /**/
+ 190,
/**/
--
From know your smileys:
:-)-O Smiling doctor with stethoscope
/// Bram Moolenaar -- [EMAIL PROTECTED] -- http://www.Moolenaar.net \\\
///sponsor Vim, vote for features -- http://www.Vim.org/sponsor/ \\\
\\\download, build and distribute -- http://www.A-A-P.org///
\\\help me help AIDS victims -- http://ICCF-Holland.org///
patch 7.0.191
Patch 7.0.191
Problem:The items used by getqflist() and setqflist() don't match.
Solution: Support the bufnum item for setqflist(). (Yegappan Lakshmanan)
Files: runtime/doc/eval.txt, src/quickfix.c
*** ../vim-7.0.190/runtime/doc/eval.txt Wed Nov 1 15:31:02 2006
--- runtime/doc/eval.txtSun Feb 4 01:54:35 2007
***
*** 2897,2908
vcolnon-zero: col is visual column
zero: col is byte index
nr error number
textdescription of the error
typetype of the error, 'E', '1', etc.
valid non-zero: recognized error message
When there is no error list or it's empty an empty list is
! returned.
Useful application: Find pattern matches in multiple files and
do something with them:
--- 2912,2925
vcolnon-zero: col is visual column
zero: col is byte index
nr error number
+ pattern search pattern used to locate the error
textdescription of the error
typetype of the error, 'E', '1', etc.
valid non-zero: recognized error message
When there is no error list or it's empty an empty list is
! returned. Quickfix list entries with non-existing buffer
! number are returned with bufnr set to zero.
Useful application: Find pattern matches in multiple files and
do something with them:
***
*** 4371,4377
Non-dictionary items in {list} are ignored. Each dictionary
item can contain the following entries:
! filenamename of a file
lnumline number in the file
pattern search pattern used to locate the error
col column number
--- 4401,4410
Non-dictionary items in {list} are ignored. Each dictionary
item can contain the following entries:
! bufnr buffer number; must be the number of a valid
! buffer
! filenamename of a file; only used when bufnr is not
! present or it is invalid.
lnumline number in the file
pattern search pattern used to locate the error
col column number
***
*** 4384,4394
The col, vcol, nr, type and text entries are
optional. Either lnum or pattern entry can be used to
locate a matching error line.
! If the filename entry is not present or neither the lnum
! or pattern entries are present, then the item will not be
! handled as an error line.
If both pattern and lnum are present then pattern will
be used.
If {action} is set to 'a', then the items from {list} are
added to the existing quickfix list. If there is no existing
--- 4417,4429
The col, vcol, nr, type and text entries are
optional. Either lnum or pattern entry can be used to
locate a matching error line.
! If the filename and bufnr entries are not present or
! neither the lnum or pattern entries are present, then the
! item will not be handled as an error line.
If both pattern and lnum are present then pattern will
be used.
+ Note that the list is not exactly the same as what
+ |getqflist()| returns.
If {action} is set to 'a', then the items from {list} are
added to the existing quickfix list. If there is no existing
*** ../vim-7.0.190/src/quickfix.c Fri Oct 20 20:15:05 2006
--- src/quickfix.c Sun Feb 4 01:50:17 2007
***
*** 106,112
static intqf_init_ext __ARGS((qf_info_T *qi, char_u *efile, buf_T *buf,
typval_T *tv, char_u *errorformat, int newlist, linenr_T lnumfirst, linenr_T
lnumlast));
static void qf_new_list __ARGS((qf_info_T *qi));
! static intqf_add_entry __ARGS((qf_info_T *qi, qfline_T **prevp, char_u
*dir, char_u *fname, char_u *mesg, long lnum, int col, int vis_col, char_u
*pattern, int nr, int type, int valid));
static void qf_msg __ARGS((qf_info_T *qi));
static void qf_free __ARGS((qf_info_T *qi, int idx));
static char_u *qf_types __ARGS((int, int));
--- 106,112
static intqf_init_ext __ARGS((qf_info_T *qi, char_u *efile, buf_T *buf,
typval_T *tv, char_u *errorformat, int newlist, linenr_T lnumfirst,
Re: Vim 7 performance notes
On 2/4/07, Bram Moolenaar [EMAIL PROTECTED] wrote:
Alexei Alexandrov wrote:
I'm doing some performance investigations of Vim code trying to
understand whether there are any possibilities to improve it.
Currently I've made the following observations (all investigations are
done on Windows):
Redundant work is done during regexp operations in syntax
highlighting. On some files it is very noticable. The stack of the
hotspot is ... syn_current_attr syn_regexec vim_regexec_multi
vim_regexec_both regtry regmatch ga_grow alloc_clear memset.
So alloc_clear spends quite a few clockticks in lalloc() and memset().
The reason for this is pessimistically big grow size for regset
growing array:
ga_init2(regstack, 1, 1);
This is not very good: many regexp operations don't go deep -
non-match is detected very quickly. But even one element on the stack
will lead to allocating at least 1 bytes (which should be fast
with good CRT memory allocator) and (worse) initializing these 1
bytes with zeros (won't be that fast).
One possible solution would be to keep regstack alive across calls to
vim_regexec_both, but I'm not sure if it's can be done safely. What I
did was replacing the grow size with smaller number and making the
grow size for growing arrays dynamic with increase of 25%:
--- regexp.c (revision 136)
+++ regexp.c (working copy)
@@ -3350,7 +3350,7 @@
/* Init the regstack empty. Use an item size of 1 byte, since we push
* different things onto it. Use a large grow size to avoid reallocating
* it too often. */
-ga_init2(regstack, 1, 1);
+ga_init2(regstack, 1, 64);
/* Init the backpos table empty. */
ga_init2(backpos, sizeof(backpos_T), 10);
--- misc2.c (revision 136)
+++ misc2.c (working copy)
@@ -1905,6 +1905,7 @@
{
if (n gap-ga_growsize)
n = gap-ga_growsize;
+gap-ga_growsize += (gap-ga_growsize 2);
len = gap-ga_itemsize * (gap-ga_len + n);
pp = alloc_clear((unsigned)len);
if (pp == NULL)
With this change I can see serious performance improvements, but I'm
not sure if they are safe.
Bram, does it look making any sense?
This is a tradeoff between allocating too much and allocating too often.
What works best completely depends on the implementation of malloc() and
free(). I know that there are many implementations where they are quite
slow. Then allocating larger chunks less often is better. On some
systems they are fast and the chunks can be smaller.
Gnu malloc (glibc) is exceptionally fast, iirc. It is possible
to benchmark the malloc speed during the ./configure time.
And auto-select the initital size depending on the results.
The procmail this similar technique in configure: It automatically
benchmarks it's own builtin strstr() vs system's strstr() and selects
the one which is faster.
Yakov
Compilation error with -D EXITFREE
Hi All! Do I understand it correct that EXITFREE define in Vim source code can be used to make sure all resources are cleaned up on exit (and those which are not should be treated as leaks)? To be able to use it on Windows I had to do the following changes: Index: misc2.c === --- misc2.c (revision 205) +++ misc2.c (working copy) @@ -1075,7 +1075,7 @@ ResetRedobuff(); ResetRedobuff(); -#ifdef FEAT_CLIENTSERVER +#if defined(FEAT_CLIENTSERVER) defined(FEAT_X11) vim_free(serverDelayedStartName); #endif Index: os_mswin.c === --- os_mswin.c (revision 205) +++ os_mswin.c (working copy) @@ -239,6 +239,11 @@ if (gui.in_use) gui_exit(r); + +#ifdef EXITFREE +free_all_mem(); +#endif + exit(r); } -- Alexei Alexandrov
Re: Vim 7 performance notes
Alexei Alexandrov wrote: The idea to gradually increase the chunk size makes sense, but not everywhere. For the syntax stack it's probably better to start with a stack that is mostly needed, then growing quite quickly (say double the chunk size every time). That's because when recursive things are involved we need much more space. And copying the stack to another place is more expensive than clearing with zeroes. Perhaps you can do some investigation about what the size mostly ends up to be. Then use that with a special version of ga_grow() that increases the chunk size every time. I've also tried the approach with persisting the regstack and backpos allocation across calls to vim_regexec_both. It seems to work even better than increasing the grow size in my particular test cases. And I can't think up any situation when it can slow things down. Could you please take a look at the patch attached and provide your opinion? Speed should be OK this way, but it does keep up to 32 Kbyte allocated. That may not seem much, but if we do this in many places it quickly adds up. Can you show the benchmarks you used to see the performance and the stack space that is being used? Otherwise we keep guessing the best numbers. Coding detail: please don't use if (!number), use if (number == 0), that is so much easier to read. Checking if ga_data is NULL would be simpler. -- From know your smileys: :q vi user saying, How do I get out of this damn emacs editor? /// Bram Moolenaar -- [EMAIL PROTECTED] -- http://www.Moolenaar.net \\\ ///sponsor Vim, vote for features -- http://www.Vim.org/sponsor/ \\\ \\\download, build and distribute -- http://www.A-A-P.org/// \\\help me help AIDS victims -- http://ICCF-Holland.org///
Re: Compilation error with -D EXITFREE
Alexei Alexandrov wrote: Do I understand it correct that EXITFREE define in Vim source code can be used to make sure all resources are cleaned up on exit (and those which are not should be treated as leaks)? To be able to use it on Windows I had to do the following changes: Thanks for the patch. I never tried EXITFREE on Win32. What memory checker to you use with it? Aren't there Win32-specific things that need to be freed? -- From know your smileys: (:-# Said something he shouldn't have /// Bram Moolenaar -- [EMAIL PROTECTED] -- http://www.Moolenaar.net \\\ ///sponsor Vim, vote for features -- http://www.Vim.org/sponsor/ \\\ \\\download, build and distribute -- http://www.A-A-P.org/// \\\help me help AIDS victims -- http://ICCF-Holland.org///
Re: Inconsistent return from exists()
Bram Moolenaar wrote: Tony Mechelynck wrote: In VIM - Vi IMproved 7.0 (2006 May 7, compiled Feb 4 2007 03:42:30) Included patches: 1-191 Compiled by [EMAIL PROTECTED] Huge version with GTK2-GNOME GUI. Features included (+) or not (-): [...] exists(:simalt) or exists(:tearoff) return 2; however trying to use them results in E319: Sorry, the command is not available in this version Shouldn't the call to exists() have returned 0 (zero)? The command exists but it doesn't work. That is more something for has() to figure out. But it doesn't handle Ex commands specifically, you can only find out by check for certain features. I can add this to the todo list, but don't expect it soon. OK, well, I guess it's a case of better late than never or if you (Tony) want it real bad, then program it yourself ;-/ Best regards, Tony.
