Test test_paste.com should not be run in Windows cmd.exe
Vim developers-
The tests in test_paste.vim are designed to run in an xterm. I haven't found
any evidence that "bracketed paste mode" and its escape sequences are supported
by cmd.exe. When I run this test using vim.exe in a cmd.exe window, it
sometimes reduces the window height to 2 lines, which cause subsequent tests to
fail, and it always changes the "screen buffer size" height property for the
window.
I suggest the attached patch
-mike
--
--
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 subscribed to the Google Groups
"vim_dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to vim_dev+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
diff --git a/src/testdir/test_paste.vim b/src/testdir/test_paste.vim
index 65f300cef..0c608a231 100644
--- a/src/testdir/test_paste.vim
+++ b/src/testdir/test_paste.vim
@@ -1,7 +1,7 @@
" Tests for bracketed paste and other forms of pasting.
-" Bracketed paste only works with "xterm". Not in GUI.
-if has('gui_running')
+" Bracketed paste only works with "xterm". Not in GUI or Windows cmd.
+if has('gui_running') || == "win32"
finish
endif
set term=xterm
Re: Patch 8.1.1040
On Fri, Mar 22, 2019 at 5:03 PM Bram Moolenaar wrote: > > > Patch 8.1.1040 > Problem:FEAT_TAG_ANYWHITE is not enabled in any build. > Solution: Remove the feature. > Files: src/feature.h, src/tag.c, src/evalfunc.c, src/version.c, > src/Make_vms.mms I suppose it could still be enabled by editing src/feature.h but that was of little use anyhow. The following documentation clean-up changes are related to this: * in runtime/doc/tagsrch.txt, either remove the last sentence and tag at lines 561-562 or replace them by something like for instance: It used to be possible to re-enable it by including *tag-any-white* the |+tag_any_white| featureat compile time but few people if any seemed to use this possibility and it has now been removed (since patchlevel 8.1.1040). * in runtime/doc/various.txt, either remove line 446 (i.e. :help +tag_any_white) entirely, or add a new line to it, maybe Removed since 8.1.1040 * in runtime/doc/eval.txt, probably remove lines 10334-10335. Best regards, Tony. -- -- 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 subscribed to the Google Groups "vim_dev" group. To unsubscribe from this group and stop receiving emails from it, send an email to vim_dev+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Patch 8.1.1040
Patch 8.1.1040
Problem:FEAT_TAG_ANYWHITE is not enabled in any build.
Solution: Remove the feature.
Files: src/feature.h, src/tag.c, src/evalfunc.c, src/version.c,
src/Make_vms.mms
*** ../vim-8.1.1039/src/feature.h 2019-03-22 12:03:26.587533860 +0100
--- src/feature.h 2019-03-22 16:38:39.508875325 +0100
***
*** 313,324
#endif
/*
- * +tag_any_white Allow any white space to separate the fields in a tags
- *file. When not defined, only a TAB is allowed.
- */
- /* #define FEAT_TAG_ANYWHITE */
-
- /*
* +cscopeUnix only: Cscope support.
*/
#if defined(UNIX) && defined(FEAT_BIG) && !defined(FEAT_CSCOPE) &&
!defined(MACOS_X)
--- 313,318
*** ../vim-8.1.1039/src/tag.c 2019-02-15 21:06:05.342289715 +0100
--- src/tag.c 2019-03-22 16:41:08.227934510 +0100
***
*** 1931,1943
{
vim_memset(, 0, sizeof(tagp));
tagp.tagname = lbuf;
- #ifdef FEAT_TAG_ANYWHITE
- tagp.tagname_end = skiptowhite(lbuf);
- if (*tagp.tagname_end == NUL)
- #else
tagp.tagname_end = vim_strchr(lbuf, TAB);
if (tagp.tagname_end == NULL)
- #endif
{
if (vim_strchr(lbuf, NL) == NULL)
{
--- 1931,1938
***
*** 1976,1995
if (*p == ':')
{
if (tagp.fname == NULL)
- # ifdef FEAT_TAG_ANYWHITE
- tagp.fname = skipwhite(tagp.tagname_end);
- # else
tagp.fname = tagp.tagname_end + 1;
! # endif
! if ( fnamencmp(lbuf, tagp.fname, p - lbuf) == 0
! # ifdef FEAT_TAG_ANYWHITE
! && VIM_ISWHITE(tagp.fname[p - lbuf])
! # else
! && tagp.fname[p - lbuf] == TAB
! # endif
! )
{
! /* found one */
tagp.tagname = p + 1;
break;
}
--- 1971,1981
if (*p == ':')
{
if (tagp.fname == NULL)
tagp.fname = tagp.tagname_end + 1;
! if (fnamencmp(lbuf, tagp.fname, p - lbuf) == 0
! && tagp.fname[p - lbuf] == TAB)
{
! // found one
tagp.tagname = p + 1;
break;
}
***
*** 2112,2131
#ifdef FEAT_TAG_OLDSTATIC
if (tagp.fname == NULL)
#endif
- #ifdef FEAT_TAG_ANYWHITE
- tagp.fname = skipwhite(tagp.tagname_end);
- #else
tagp.fname = tagp.tagname_end + 1;
- #endif
- #ifdef FEAT_TAG_ANYWHITE
- tagp.fname_end = skiptowhite(tagp.fname);
- tagp.command = skipwhite(tagp.fname_end);
- if (*tagp.command == NUL)
- #else
tagp.fname_end = vim_strchr(tagp.fname, TAB);
tagp.command = tagp.fname_end + 1;
if (tagp.fname_end == NULL)
- #endif
i = FAIL;
else
i = OK;
--- 2098,2107
***
*** 2843,2883
else /* not an Emacs tag */
{
#endif
! /* Isolate the tagname, from lbuf up to the first white */
tagp->tagname = lbuf;
- #ifdef FEAT_TAG_ANYWHITE
- p = skiptowhite(lbuf);
- #else
p = vim_strchr(lbuf, TAB);
if (p == NULL)
return FAIL;
- #endif
tagp->tagname_end = p;
! /* Isolate file name, from first to second white space */
! #ifdef FEAT_TAG_ANYWHITE
! p = skipwhite(p);
! #else
if (*p != NUL)
++p;
- #endif
tagp->fname = p;
- #ifdef FEAT_TAG_ANYWHITE
- p = skiptowhite(p);
- #else
p = vim_strchr(p, TAB);
if (p == NULL)
return FAIL;
- #endif
tagp->fname_end = p;
! /* find start of search command, after second white space */
! #ifdef FEAT_TAG_ANYWHITE
! p = skipwhite(p);
! #else
if (*p != NUL)
++p;
- #endif
if (*p == NUL)
return FAIL;
tagp->command = p;
--- 2819,2843
else /* not an Emacs tag */
{
#endif
! // Isolate the tagname, from lbuf up to the first white
tagp->tagname = lbuf;
p = vim_strchr(lbuf, TAB);
if (p == NULL)
return FAIL;
tagp->tagname_end = p;
! // Isolate file name, from first to second white space
if (*p != NUL)
++p;
tagp->fname = p;
p = vim_strchr(p, TAB);
if (p == NULL)
return FAIL;
tagp->fname_end = p;
! // find start of search command,
Patch 8.1.1039
Patch 8.1.1039 Problem:MS-Windows build fails. Solution: Remove dependency on arabic.h Files: src/Make_cyg_ming.mak, src/Make_mvc.mak, src/Make_vms.mms *** ../vim-8.1.1038/src/Make_cyg_ming.mak 2019-02-21 13:34:01.801327590 +0100 --- src/Make_cyg_ming.mak 2019-03-22 16:56:09.634270303 +0100 *** *** 1004,1010 $(MAKE) -C tee clean ### ! INCL =vim.h alloc.h arabic.h ascii.h ex_cmds.h feature.h globals.h \ keymap.h macros.h option.h os_dos.h os_win32.h proto.h regexp.h \ spell.h structs.h term.h beval.h $(NBDEBUG_INCL) GUI_INCL = gui.h --- 1004,1010 $(MAKE) -C tee clean ### ! INCL =vim.h alloc.h ascii.h ex_cmds.h feature.h globals.h \ keymap.h macros.h option.h os_dos.h os_win32.h proto.h regexp.h \ spell.h structs.h term.h beval.h $(NBDEBUG_INCL) GUI_INCL = gui.h *** ../vim-8.1.1038/src/Make_mvc.mak2019-03-17 15:47:22.585492095 +0100 --- src/Make_mvc.mak2019-03-22 16:56:14.670238750 +0100 *** *** 693,699 !include Make_all.mak !include testdir\Make_all.mak ! INCL =vim.h alloc.h arabic.h ascii.h ex_cmds.h feature.h globals.h \ keymap.h macros.h option.h os_dos.h os_win32.h proto.h regexp.h \ spell.h structs.h term.h beval.h $(NBDEBUG_INCL) --- 693,699 !include Make_all.mak !include testdir\Make_all.mak ! INCL =vim.h alloc.h ascii.h ex_cmds.h feature.h globals.h \ keymap.h macros.h option.h os_dos.h os_win32.h proto.h regexp.h \ spell.h structs.h term.h beval.h $(NBDEBUG_INCL) *** ../vim-8.1.1038/src/Make_vms.mms2019-02-16 15:09:21.221946179 +0100 --- src/Make_vms.mms2019-03-22 16:56:58.201966027 +0100 *** *** 2,8 # Makefile for Vim on OpenVMS # # Maintainer: Zoltan Arpadffy ! # Last change: 2019 Feb 16 # # This has script been tested on VMS 6.2 to 8.2 on DEC Alpha, VAX and IA64 # with MMS and MMK --- 2,8 # Makefile for Vim on OpenVMS # # Maintainer: Zoltan Arpadffy ! # Last change: 2019 Mar 22 # # This has script been tested on VMS 6.2 to 8.2 on DEC Alpha, VAX and IA64 # with MMS and MMK *** *** 514,791 buffer.obj : buffer.c vim.h [.auto]config.h feature.h os_unix.h \ ascii.h keymap.h term.h macros.h structs.h regexp.h \ gui.h beval.h [.proto]gui_beval.pro option.h ex_cmds.h proto.h \ ! globals.h arabic.h version.h charset.obj : charset.c vim.h [.auto]config.h feature.h os_unix.h \ ascii.h keymap.h term.h macros.h structs.h regexp.h \ gui.h beval.h [.proto]gui_beval.pro option.h ex_cmds.h proto.h \ ! globals.h arabic.h crypt.obj : crypt.c vim.h [.auto]config.h feature.h os_unix.h \ ascii.h keymap.h term.h macros.h option.h structs.h regexp.h gui.h \ beval.h [.proto]gui_beval.pro alloc.h ex_cmds.h spell.h proto.h \ ! globals.h arabic.h crypt_zip.obj : crypt_zip.c vim.h [.auto]config.h feature.h os_unix.h \ ascii.h keymap.h term.h macros.h option.h structs.h \ regexp.h gui.h beval.h [.proto]gui_beval.pro alloc.h ex_cmds.h spell.h \ ! proto.h globals.h arabic.h dict.obj : dict.c vim.h [.auto]config.h feature.h os_unix.h \ ascii.h keymap.h term.h macros.h option.h structs.h regexp.h gui.h \ beval.h [.proto]gui_beval.pro alloc.h ex_cmds.h spell.h proto.h \ ! globals.h arabic.h diff.obj : diff.c vim.h [.auto]config.h feature.h os_unix.h \ ascii.h keymap.h term.h macros.h structs.h regexp.h gui.h beval.h \ [.proto]gui_beval.pro option.h ex_cmds.h proto.h globals.h \ ! arabic.h digraph.obj : digraph.c vim.h [.auto]config.h feature.h os_unix.h \ ascii.h keymap.h term.h macros.h structs.h regexp.h \ gui.h beval.h [.proto]gui_beval.pro option.h ex_cmds.h proto.h \ ! globals.h arabic.h edit.obj : edit.c vim.h [.auto]config.h feature.h os_unix.h \ ascii.h keymap.h term.h macros.h structs.h regexp.h gui.h beval.h \ [.proto]gui_beval.pro option.h ex_cmds.h proto.h globals.h \ ! arabic.h eval.obj : eval.c vim.h [.auto]config.h feature.h os_unix.h \ ascii.h keymap.h term.h macros.h structs.h regexp.h gui.h beval.h \ [.proto]gui_beval.pro option.h ex_cmds.h proto.h globals.h \ ! arabic.h version.h evalfunc.obj : evalfunc.c vim.h [.auto]config.h feature.h os_unix.h \ ascii.h keymap.h term.h macros.h option.h structs.h \ regexp.h gui.h beval.h [.proto]gui_beval.pro alloc.h ex_cmds.h spell.h \ ! proto.h globals.h arabic.h version.h ex_cmds.obj : ex_cmds.c vim.h [.auto]config.h feature.h os_unix.h \ ascii.h keymap.h term.h macros.h structs.h regexp.h \ gui.h beval.h [.proto]gui_beval.pro option.h ex_cmds.h proto.h \ ! globals.h arabic.h version.h ex_cmds2.obj : ex_cmds2.c vim.h [.auto]config.h feature.h os_unix.h \ ascii.h keymap.h term.h macros.h structs.h regexp.h \ gui.h
Patch 8.1.1038
Patch 8.1.1038
Problem:Arabic support excludes Farsi.
Solution: Add Farsi support to the Arabic support. (Ali Gholami Rudi,
Ameretat Reith)
Files: Filelist, src/arabic.c, src/arabic.h, src/globals.h, src/macros.h,
src/mbyte.c, src/proto/arabic.pro, src/proto/mbyte.pro,
src/Makefile, src/testdir/test_arabic.vim
*** ../vim-8.1.1037/Filelist2019-02-16 15:09:21.209946237 +0100
--- Filelist2019-03-22 15:28:28.674998090 +0100
***
*** 12,18
src/README.txt \
src/alloc.h \
src/arabic.c \
- src/arabic.h \
src/ascii.h \
src/autocmd.c \
src/beval.c \
--- 12,17
*** ../vim-8.1.1037/src/arabic.c2019-03-21 21:45:30.871282226 +0100
--- src/arabic.c2019-03-22 16:19:36.840005367 +0100
***
*** 11,551
* arabic.c: functions for Arabic language
*
* Author: Nadim Shaikli & Isam Bayazidi
*/
#include "vim.h"
#if defined(FEAT_ARABIC) || defined(PROTO)
! static int A_firstc_laa(int c1, int c);
! static int A_is_harakat(int c);
! static int A_is_iso(int c);
! static int A_is_formb(int c);
! static int A_is_ok(int c);
! static int A_is_valid(int c);
! static int A_is_special(int c);
!
/*
! * Returns True if c is an ISO-8859-6 shaped ARABIC letter (user entered)
*/
static int
! A_is_a(int cur_c)
{
! switch (cur_c)
{
- case a_HAMZA:
case a_ALEF_MADDA:
case a_ALEF_HAMZA_ABOVE:
! case a_WAW_HAMZA:
case a_ALEF_HAMZA_BELOW:
! case a_YEH_HAMZA:
case a_ALEF:
! case a_BEH:
! case a_TEH_MARBUTA:
! case a_TEH:
! case a_THEH:
! case a_JEEM:
! case a_HAH:
! case a_KHAH:
! case a_DAL:
! case a_THAL:
! case a_REH:
! case a_ZAIN:
! case a_SEEN:
! case a_SHEEN:
! case a_SAD:
! case a_DAD:
! case a_TAH:
! case a_ZAH:
! case a_AIN:
! case a_GHAIN:
! case a_TATWEEL:
! case a_FEH:
! case a_QAF:
! case a_KAF:
! case a_LAM:
! case a_MEEM:
! case a_NOON:
! case a_HEH:
! case a_WAW:
! case a_ALEF_MAKSURA:
! case a_YEH:
! return TRUE;
! }
!
! return FALSE;
! }
!
!
! /*
! * Returns True if c is an Isolated Form-B ARABIC letter
! */
! static int
! A_is_s(int cur_c)
! {
! switch (cur_c)
! {
! case a_s_HAMZA:
! case a_s_ALEF_MADDA:
! case a_s_ALEF_HAMZA_ABOVE:
! case a_s_WAW_HAMZA:
! case a_s_ALEF_HAMZA_BELOW:
! case a_s_YEH_HAMZA:
! case a_s_ALEF:
! case a_s_BEH:
! case a_s_TEH_MARBUTA:
! case a_s_TEH:
! case a_s_THEH:
! case a_s_JEEM:
! case a_s_HAH:
! case a_s_KHAH:
! case a_s_DAL:
! case a_s_THAL:
! case a_s_REH:
! case a_s_ZAIN:
! case a_s_SEEN:
! case a_s_SHEEN:
! case a_s_SAD:
! case a_s_DAD:
! case a_s_TAH:
! case a_s_ZAH:
! case a_s_AIN:
! case a_s_GHAIN:
! case a_s_FEH:
! case a_s_QAF:
! case a_s_KAF:
! case a_s_LAM:
! case a_s_MEEM:
! case a_s_NOON:
! case a_s_HEH:
! case a_s_WAW:
! case a_s_ALEF_MAKSURA:
! case a_s_YEH:
! return TRUE;
}
! return FALSE;
}
-
/*
! * Returns True if c is a Final shape of an ARABIC letter
*/
static int
! A_is_f(int cur_c)
{
! switch (cur_c)
! {
! case a_f_ALEF_MADDA:
! case a_f_ALEF_HAMZA_ABOVE:
! case a_f_WAW_HAMZA:
! case a_f_ALEF_HAMZA_BELOW:
! case a_f_YEH_HAMZA:
! case a_f_ALEF:
! case a_f_BEH:
! case a_f_TEH_MARBUTA:
! case a_f_TEH:
! case a_f_THEH:
! case a_f_JEEM:
! case a_f_HAH:
! case a_f_KHAH:
! case a_f_DAL:
! case a_f_THAL:
! case a_f_REH:
! case a_f_ZAIN:
! case a_f_SEEN:
! case a_f_SHEEN:
! case a_f_SAD:
! case a_f_DAD:
! case a_f_TAH:
! case a_f_ZAH:
! case a_f_AIN:
! case a_f_GHAIN:
! case a_f_FEH:
! case a_f_QAF:
! case a_f_KAF:
! case a_f_LAM:
! case a_f_MEEM:
! case a_f_NOON:
! case a_f_HEH:
! case a_f_WAW:
! case a_f_ALEF_MAKSURA:
! case a_f_YEH:
! case a_f_LAM_ALEF_MADDA_ABOVE:
! case a_f_LAM_ALEF_HAMZA_ABOVE:
! case a_f_LAM_ALEF_HAMZA_BELOW:
! case a_f_LAM_ALEF:
! return TRUE;
! }
! return FALSE;
! }
!
! /*
! * Change shape - from ISO-8859-6/Isolated to Form-B Isolated
! */
! static int
! chg_c_a2s(int cur_c)
! {
! switch (cur_c)
{
! case a_HAMZA: return a_s_HAMZA;
! case a_ALEF_MADDA: return a_s_ALEF_MADDA;
! case a_ALEF_HAMZA_ABOVE: return a_s_ALEF_HAMZA_ABOVE;
! case a_WAW_HAMZA: return a_s_WAW_HAMZA;
!
Re: Patch 8.1.1031
* Bram Moolenaar [2019-03-22 11:33 +0100]: [...] > I added 1% and this goes over the limit by 1.02%. > I guess I'll have to make the tolerance 3%. With 8.1.1034 the build runs just fine on my i686. Thanks Elimar -- We all know Linux is great... it does infinite loops in 5 seconds. -Linus Torvalds -- -- 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 subscribed to the Google Groups "vim_dev" group. To unsubscribe from this group and stop receiving emails from it, send an email to vim_dev+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: Patch 8.1.1031
> > I added 1% and this goes over the limit by 1.02%. > > I guess I'll have to make the tolerance 3%. > > Even with 3% tolerance (per 8.1.1033) I'm still seeing this on i686 [1] > (and armhf [2]): > > From test_memory_usage.vim: > Found errors in Test_memory_func_capture_lvars(): > function RunTheTest[40]..Test_memory_func_capture_lvars line 33: > Expected range 6579 - 22985, but got 23108 > TEST FAILURE > > Is the reported upper range number (in this case 22985) the 100% value, > or the 103% value? It is the 103% value. We could increase it to 105%. > Another build with larger value difference [2]: > > >From test_memory_usage.vim: > Found errors in Test_memory_func_capture_lvars(): > function RunTheTest[40]..Test_memory_func_capture_lvars line 33: > Expected range 12780 - 28292, but got 30896 > TEST FAILURE That is a lot more, about 10%. We could use a tolerance of 20%. I suppose that when the memory use problem would come back it would still be caught. > The build/packaging process in these logs runs several times with > different enabled features/flags. The first run [1] failed while testing > "vim-basic", the second run [3] succeeded where [1] failed but failed > later while testing "vim-gtk", and a third run [4] succeeded where [1] > and [3] failed but failed later still while testing "vim-gtk3". (and a > fourth run failed again testing "vim-basic". [5]) > > The test looks pretty flaky for 32-bit... 64-bit builds (amd64, arm64) > don't have the same problem. I suspect that these machines are quite busy, causing more fluctuation in memory use. -- >From "know your smileys": :-| :-| Deja' vu! /// Bram Moolenaar -- b...@moolenaar.net -- http://www.Moolenaar.net \\\ ///sponsor Vim, vote for features -- http://www.Vim.org/sponsor/ \\\ \\\ an exciting new programming language -- http://www.Zimbu.org/// \\\help me help AIDS victims -- http://ICCF-Holland.org/// -- -- 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 subscribed to the Google Groups "vim_dev" group. To unsubscribe from this group and stop receiving emails from it, send an email to vim_dev+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Patch 8.1.1037
Patch 8.1.1037
Problem:Memory usage test may still fail on some systems.
Solution: Increase tolerance from 3% to 20%.
Files: src/testdir/test_memory_usage.vim
*** ../vim-8.1.1036/src/testdir/test_memory_usage.vim 2019-03-22
11:33:04.445160178 +0100
--- src/testdir/test_memory_usage.vim 2019-03-22 14:36:02.166938817 +0100
***
*** 138,146
endfor
" The usage may be a bit less than the last value, use 80%.
! " Allow for 3% tolerance at the upper limit.
let lower = before * 8 / 10
! let upper = (after.max + (after.last - before)) * 103 / 100
call assert_inrange(lower, upper, last)
call vim.stop()
--- 138,147
endfor
" The usage may be a bit less than the last value, use 80%.
! " Allow for 20% tolerance at the upper limit. That's very permissive, but
! " otherwise the test fails sometimes.
let lower = before * 8 / 10
! let upper = (after.max + (after.last - before)) * 12 / 10
call assert_inrange(lower, upper, last)
call vim.stop()
*** ../vim-8.1.1036/src/version.c 2019-03-22 14:16:02.877160892 +0100
--- src/version.c 2019-03-22 14:36:39.330677890 +0100
***
*** 781,782
--- 781,784
{ /* Add new patch number below this line */
+ /**/
+ 1037,
/**/
--
>From "know your smileys":
:.-( Crying
/// Bram Moolenaar -- b...@moolenaar.net -- http://www.Moolenaar.net \\\
///sponsor Vim, vote for features -- http://www.Vim.org/sponsor/ \\\
\\\ an exciting new programming language -- http://www.Zimbu.org///
\\\help me help AIDS victims -- http://ICCF-Holland.org///
--
--
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 subscribed to the Google Groups
"vim_dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to vim_dev+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
Patch 8.1.1036
Patch 8.1.1036
Problem:Quickfix function arguments are inconsistent.
Solution: Pass a list pointer to more functions. (Yegappan Lakshmanan,
closes #4149)
Files: src/quickfix.c
*** ../vim-8.1.1035/src/quickfix.c 2019-03-21 21:12:46.282715864 +0100
--- src/quickfix.c 2019-03-22 14:14:13.850223057 +0100
***
*** 1629,1645
// make place for a new list
qf_new_list(qi, qf_title);
qf_idx = qi->qf_curlist;
}
else
{
// Adding to existing list, use last entry.
adding = TRUE;
! if (!qf_list_empty(qf_get_list(qi, qf_idx)))
! old_last = qi->qf_lists[qf_idx].qf_last;
}
- qfl = qf_get_list(qi, qf_idx);
-
// Use the local value of 'errorformat' if it's set.
if (errorformat == p_efm && tv == NULL && *buf->b_p_efm != NUL)
efm = buf->b_p_efm;
--- 1629,1645
// make place for a new list
qf_new_list(qi, qf_title);
qf_idx = qi->qf_curlist;
+ qfl = qf_get_list(qi, qf_idx);
}
else
{
// Adding to existing list, use last entry.
adding = TRUE;
! qfl = qf_get_list(qi, qf_idx);
! if (!qf_list_empty(qfl))
! old_last = qfl->qf_last;
}
// Use the local value of 'errorformat' if it's set.
if (errorformat == p_efm && tv == NULL && *buf->b_p_efm != NUL)
efm = buf->b_p_efm;
***
*** 3921,3927
// it if we have errors; otherwise, leave it closed.
if (qf_stack_empty(qi)
|| qfl->qf_nonevalid
! || qf_list_empty(qf_get_curlist(qi)))
{
if (win != NULL)
ex_cclose(eap);
--- 3921,3927
// it if we have errors; otherwise, leave it closed.
if (qf_stack_empty(qi)
|| qfl->qf_nonevalid
! || qf_list_empty(qfl))
{
if (win != NULL)
ex_cclose(eap);
***
*** 5286,5292
*/
static int
vgr_match_buflines(
! qf_info_T *qi,
char_u *fname,
buf_T *buf,
regmmatch_T *regmatch,
--- 5286,5292
*/
static int
vgr_match_buflines(
! qf_list_T *qfl,
char_u *fname,
buf_T *buf,
regmmatch_T *regmatch,
***
*** 5307,5313
// Pass the buffer number so that it gets used even for a
// dummy buffer, unless duplicate_name is set, then the
// buffer will be wiped out below.
! if (qf_add_entry(qf_get_curlist(qi),
NULL, // dir
fname,
NULL,
--- 5307,5313
// Pass the buffer number so that it gets used even for a
// dummy buffer, unless duplicate_name is set, then the
// buffer will be wiped out below.
! if (qf_add_entry(qfl,
NULL, // dir
fname,
NULL,
***
*** 5535,5541
{
// Try for a match in all lines of the buffer.
// For ":1vimgrep" look for first match only.
! found_match = vgr_match_buflines(qi, fname, buf, ,
, duplicate_name, flags);
if (using_dummy)
--- 5535,5542
{
// Try for a match in all lines of the buffer.
// For ":1vimgrep" look for first match only.
! found_match = vgr_match_buflines(qf_get_curlist(qi),
! fname, buf, ,
, duplicate_name, flags);
if (using_dummy)
***
*** 7082,7088
*/
static void
hgr_search_file(
! qf_info_T *qi,
char_u *fname,
vimconv_T *p_vc,
regmatch_T *p_regmatch)
--- 7083,7089
*/
static void
hgr_search_file(
! qf_list_T *qfl,
char_u *fname,
vimconv_T *p_vc,
regmatch_T *p_regmatch)
***
*** 7117,7123
while (l > 0 && line[l - 1] <= ' ')
line[--l] = NUL;
! if (qf_add_entry(qf_get_curlist(qi),
NULL, // dir
fname,
NULL,
--- 7118,7124
while (l > 0 && line[l - 1] <= ' ')
line[--l] = NUL;
! if (qf_add_entry(qfl,
NULL, // dir
fname,
NULL,
***
*** 7153,7159
*/
static void
hgr_search_files_in_dir(
! qf_info_T *qi,
char_u *dirname,
regmatch_T *p_regmatch,
vimconv_T *p_vc
--- 7154,7160
*/
static void
hgr_search_files_in_dir(
! qf_list_T *qfl,
char_u *dirname,
regmatch_T *p_regmatch,
vimconv_T *p_vc
***
*** 7186,7192
continue;
#endif
! hgr_search_file(qi, fnames[fi], p_vc, p_regmatch);
Re: Patch 8.1.1031
On 22/03/2019 10:33, Bram Moolenaar wrote: > > Elimar Riesebieter wrote: > >> * Bram Moolenaar [2019-03-21 21:16 +0100]: >> >>> >>> Patch 8.1.1031 >>> Problem:Memory usage test may still fail. >>> Solution: Drop the unused min value. (Christian Brabandt) >>> Files: src/testdir/test_memory_usage.vim >> >> Still get on i686: >> >> From test_memory_usage.vim: >> Found errors in Test_memory_func_capture_lvars(): >> function RunTheTest[40]..Test_memory_func_capture_lvars line 33: Expected >> range 10051 - 26967, but got 27516 >> TEST FAILURE > > I added 1% and this goes over the limit by 1.02%. > I guess I'll have to make the tolerance 3%. > Even with 3% tolerance (per 8.1.1033) I'm still seeing this on i686 [1] (and armhf [2]): >From test_memory_usage.vim: Found errors in Test_memory_func_capture_lvars(): function RunTheTest[40]..Test_memory_func_capture_lvars line 33: Expected range 6579 - 22985, but got 23108 TEST FAILURE Is the reported upper range number (in this case 22985) the 100% value, or the 103% value? Another build with larger value difference [2]: >From test_memory_usage.vim: Found errors in Test_memory_func_capture_lvars(): function RunTheTest[40]..Test_memory_func_capture_lvars line 33: Expected range 12780 - 28292, but got 30896 TEST FAILURE The build/packaging process in these logs runs several times with different enabled features/flags. The first run [1] failed while testing "vim-basic", the second run [3] succeeded where [1] failed but failed later while testing "vim-gtk", and a third run [4] succeeded where [1] and [3] failed but failed later still while testing "vim-gtk3". (and a fourth run failed again testing "vim-basic". [5]) The test looks pretty flaky for 32-bit... 64-bit builds (amd64, arm64) don't have the same problem. J [1] https://launchpadlibrarian.net/416114150/buildlog_ubuntu-bionic-i386.vim_2%3A8.1.1017+really.v8.1.1034-0york0~ubuntu18.04.1_BUILDING.txt.gz [2] https://launchpadlibrarian.net/416119282/buildlog_ubuntu-bionic-armhf.vim_2%3A8.1.1017+really.v8.1.1034-0york0~ubuntu18.04.1_BUILDING.txt.gz [3] https://launchpadlibrarian.net/416116391/buildlog_ubuntu-bionic-i386.vim_2%3A8.1.1017+really.v8.1.1034-0york0~ubuntu18.04.1_BUILDING.txt.gz [4] https://launchpadlibrarian.net/416118864/buildlog_ubuntu-bionic-i386.vim_2%3A8.1.1017+really.v8.1.1034-0york0~ubuntu18.04.1_BUILDING.txt.gz [5] https://code.launchpad.net/~jonathonf/+archive/ubuntu/vim-daily/+build/16521748/+files/buildlog_ubuntu-bionic-i386.vim_2%3A8.1.1017+really.v8.1.1034-0york0~ubuntu18.04.1_BUILDING.txt.gz (yes, it +really. is 8.1.1034 ;) -- -- 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 subscribed to the Google Groups "vim_dev" group. To unsubscribe from this group and stop receiving emails from it, send an email to vim_dev+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout. signature.asc Description: OpenPGP digital signature
Patch 8.1.1035
Patch 8.1.1035
Problem:prop_remove() second argument is not optional.
Solution: Fix argument count. Use "buf" instead of "curbuf". (closes #4147)
Files: src/evalfunc.c, src/testdir/test_textprop.vim, src/textprop.c
*** ../vim-8.1.1034/src/evalfunc.c 2019-03-22 12:03:26.583533911 +0100
--- src/evalfunc.c 2019-03-22 13:13:27.209011192 +0100
***
*** 788,794
{"prop_add", 3, 3, f_prop_add},
{"prop_clear",1, 3, f_prop_clear},
{"prop_list", 1, 2, f_prop_list},
! {"prop_remove", 2, 3, f_prop_remove},
{"prop_type_add", 2, 2, f_prop_type_add},
{"prop_type_change", 2, 2, f_prop_type_change},
{"prop_type_delete", 1, 2, f_prop_type_delete},
--- 788,794
{"prop_add", 3, 3, f_prop_add},
{"prop_clear",1, 3, f_prop_clear},
{"prop_list", 1, 2, f_prop_list},
! {"prop_remove", 1, 3, f_prop_remove},
{"prop_type_add", 2, 2, f_prop_type_add},
{"prop_type_change", 2, 2, f_prop_type_change},
{"prop_type_delete", 1, 2, f_prop_type_delete},
*** ../vim-8.1.1034/src/testdir/test_textprop.vim 2019-02-22
14:38:46.447452832 +0100
--- src/testdir/test_textprop.vim 2019-03-22 13:19:41.448110561 +0100
***
*** 166,193
new
let bufnr = bufnr('')
call AddPropTypes()
! call setline(1, 'one two three')
wincmd w
! call prop_add(1, 1, {'length': 3, 'id': 11, 'type': 'one', 'bufnr': bufnr})
! call prop_add(1, 5, {'length': 3, 'id': 12, 'type': 'two', 'bufnr': bufnr})
! call prop_add(1, 11, {'length': 3, 'id': 13, 'type': 'three', 'bufnr':
bufnr})
!
let props = [
\ {'col': 1, 'length': 3, 'id': 11, 'type': 'one', 'start': 1, 'end':
1},
\ {'col': 5, 'length': 3, 'id': 12, 'type': 'two', 'start': 1, 'end':
1},
\ {'col': 11, 'length': 3, 'id': 13, 'type': 'three', 'start': 1,
'end': 1},
\]
call assert_equal(props, prop_list(1, {'bufnr': bufnr}))
!
" remove by id
! call prop_remove({'id': 12, 'bufnr': bufnr}, 1)
unlet props[1]
call assert_equal(props, prop_list(1, {'bufnr': bufnr}))
" remove by type
! call prop_remove({'type': 'one', 'bufnr': bufnr}, 1)
unlet props[0]
call assert_equal(props, prop_list(1, {'bufnr': bufnr}))
call DeletePropTypes()
wincmd w
--- 166,229
new
let bufnr = bufnr('')
call AddPropTypes()
! for lnum in range(1, 4)
! call setline(lnum, 'one two three')
! endfor
wincmd w
! for lnum in range(1, 4)
! call prop_add(lnum, 1, {'length': 3, 'id': 11, 'type': 'one', 'bufnr':
bufnr})
! call prop_add(lnum, 5, {'length': 3, 'id': 12, 'type': 'two', 'bufnr':
bufnr})
! call prop_add(lnum, 11, {'length': 3, 'id': 13, 'type': 'three', 'bufnr':
bufnr})
! endfor
!
let props = [
\ {'col': 1, 'length': 3, 'id': 11, 'type': 'one', 'start': 1, 'end':
1},
\ {'col': 5, 'length': 3, 'id': 12, 'type': 'two', 'start': 1, 'end':
1},
\ {'col': 11, 'length': 3, 'id': 13, 'type': 'three', 'start': 1,
'end': 1},
\]
call assert_equal(props, prop_list(1, {'bufnr': bufnr}))
!
" remove by id
! let before_props = deepcopy(props)
unlet props[1]
+
+ call prop_remove({'id': 12, 'bufnr': bufnr}, 1)
+ call assert_equal(props, prop_list(1, {'bufnr': bufnr}))
+ call assert_equal(before_props, prop_list(2, {'bufnr': bufnr}))
+ call assert_equal(before_props, prop_list(3, {'bufnr': bufnr}))
+ call assert_equal(before_props, prop_list(4, {'bufnr': bufnr}))
+
+ call prop_remove({'id': 12, 'bufnr': bufnr}, 3, 4)
call assert_equal(props, prop_list(1, {'bufnr': bufnr}))
+ call assert_equal(before_props, prop_list(2, {'bufnr': bufnr}))
+ call assert_equal(props, prop_list(3, {'bufnr': bufnr}))
+ call assert_equal(props, prop_list(4, {'bufnr': bufnr}))
+
+ call prop_remove({'id': 12, 'bufnr': bufnr})
+ for lnum in range(1, 4)
+ call assert_equal(props, prop_list(lnum, {'bufnr': bufnr}))
+ endfor
" remove by type
! let before_props = deepcopy(props)
unlet props[0]
+
+ call prop_remove({'type': 'one', 'bufnr': bufnr}, 1)
call assert_equal(props, prop_list(1, {'bufnr': bufnr}))
+ call assert_equal(before_props, prop_list(2, {'bufnr': bufnr}))
+ call assert_equal(before_props, prop_list(3, {'bufnr': bufnr}))
+ call assert_equal(before_props, prop_list(4, {'bufnr': bufnr}))
+
+ call prop_remove({'type': 'one', 'bufnr': bufnr}, 3, 4)
+ call assert_equal(props, prop_list(1, {'bufnr': bufnr}))
+ call assert_equal(before_props, prop_list(2, {'bufnr': bufnr}))
+ call assert_equal(props, prop_list(3, {'bufnr': bufnr}))
+ call assert_equal(props, prop_list(4, {'bufnr': bufnr}))
+
+ call prop_remove({'type': 'one', 'bufnr': bufnr})
+ for lnum in range(1, 4)
+ call assert_equal(props, prop_list(lnum, {'bufnr': bufnr}))
+ endfor
call DeletePropTypes()
wincmd w
*** ../vim-8.1.1034/src/textprop.c
Re: vim-win32-installer build on appveyor failed
On Fr, 22 Mär 2019, Bram Moolenaar wrote: > How about with patch 1033 included? This came to late, but the problem test 1033 fixed, did not appear on the appveyor build. And the build with patch 1032 worked perfectly again: https://github.com/vim/vim-win32-installer/releases/tag/v8.1.1032 Best, Christian -- Mein Haß ist gealtert - nun ist er Verachtung. -- Stanislaw Jerzy Lec (eig. S. J. de Tusch-Letz) -- -- 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 subscribed to the Google Groups "vim_dev" group. To unsubscribe from this group and stop receiving emails from it, send an email to vim_dev+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: vim-win32-installer build on appveyor failed
Christian wrote: > On Mi, 20 Mär 2019, Christian Brabandt wrote: > > > Bram, > > the latest build of the vim-win32-installer failed with this error > > message: > > > > https://ci.appveyor.com/project/chrisbra/vim-win32-installer/builds/23206196/job/2i61rw80gx51ubv7#L6622 > > > > function RunTheTest[40]..Test_memory_func_capture_lvars line 29: > > Expected range 23092 - 43324, but got 22800 > > I did re-trigger the build. This time, the x86 build failed with > https://ci.appveyor.com/project/chrisbra/vim-win32-installer/build/job/ii6lq86sb7mycfac#L6600 > > function RunTheTest[40]..Test_memory_func_capture_lvars line 29: Expected > range 18180 - 32420, but got 17752 > Found errors in Test_memory_func_capture_vargs(): > function RunTheTest[40]..Test_memory_func_capture_vargs line 24: Expected > 17484 but got 18188 > > I don't actually understand the test test_memory_usage, but I wonder why > in Test_memory_func_capture_vargs it is expected, that > after.last == after.max > > ,[ Test_memory_func_capture_lvars ]- > | " In this case, garbase collecting is not needed. > | call assert_equal(after.last, after.max) > ` > > Perhaps those tests should be added to the flaky tests? Or may be, we > don't need the assert_equal, since there is the assert_inrange() test > just before that? Not sure. How about with patch 1033 included? -- I AM THANKFUL... ...for the piles of laundry and ironing because it means I have plenty of clothes to wear. /// Bram Moolenaar -- b...@moolenaar.net -- http://www.Moolenaar.net \\\ ///sponsor Vim, vote for features -- http://www.Vim.org/sponsor/ \\\ \\\ an exciting new programming language -- http://www.Zimbu.org/// \\\help me help AIDS victims -- http://ICCF-Holland.org/// -- -- 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 subscribed to the Google Groups "vim_dev" group. To unsubscribe from this group and stop receiving emails from it, send an email to vim_dev+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Patch 8.1.1034
Patch 8.1.1034
Problem:Too many #ifdefs.
Solution: Merge FEAT_MOUSE_SGR into FEAT_MOUSE_XTERM / FEAT_MOUSE_TTY.
Files: src/evalfunc.c, src/misc2.c, src/os_unix.c, src/term.c,
src/version.c, src/feature.h
*** ../vim-8.1.1033/src/evalfunc.c 2019-03-07 11:25:24.455856096 +0100
--- src/evalfunc.c 2019-03-22 11:50:43.386780312 +0100
***
*** 6414,6420
# ifdef FEAT_MOUSE_PTERM
"mouse_pterm",
# endif
! # ifdef FEAT_MOUSE_SGR
"mouse_sgr",
# endif
# ifdef FEAT_SYSMOUSE
--- 6414,6420
# ifdef FEAT_MOUSE_PTERM
"mouse_pterm",
# endif
! # ifdef FEAT_MOUSE_XTERM
"mouse_sgr",
# endif
# ifdef FEAT_SYSMOUSE
*** ../vim-8.1.1033/src/misc2.c 2019-02-17 17:44:36.215875493 +0100
--- src/misc2.c 2019-03-22 11:50:57.118697587 +0100
***
*** 2453,2462
#ifdef FEAT_MOUSE_URXVT
{K_URXVT_MOUSE, (char_u *)"UrxvtMouse"},
#endif
- #ifdef FEAT_MOUSE_SGR
{K_SGR_MOUSE, (char_u *)"SgrMouse"},
{K_SGR_MOUSERELEASE, (char_u *)"SgrMouseRelelase"},
- #endif
{K_LEFTMOUSE, (char_u *)"LeftMouse"},
{K_LEFTMOUSE_NM, (char_u *)"LeftMouseNM"},
{K_LEFTDRAG, (char_u *)"LeftDrag"},
--- 2453,2460
*** ../vim-8.1.1033/src/os_unix.c 2019-03-21 21:45:30.879282125 +0100
--- src/os_unix.c 2019-03-22 11:51:47.062396710 +0100
***
*** 3596,3602
}
# endif
- # ifdef FEAT_MOUSE_SGR
if (ttym_flags == TTYM_SGR)
{
/* SGR mode supports columns above 223 */
--- 3596,3601
***
*** 3606,3612
: IF_EB("\033[?1006l", ESC_STR "[?1006l")));
mouse_ison = on;
}
- # endif
# ifdef FEAT_BEVAL_TERM
if (bevalterm_ison != (p_bevalterm && on))
--- 3605,3610
***
*** 3864,3874
else
del_mouse_termcode(KS_URXVT_MOUSE);
# endif
- # ifdef FEAT_MOUSE_SGR
if (use_xterm_mouse() == 4
! # ifdef FEAT_GUI
&& !gui.in_use
! # endif
)
{
set_mouse_termcode(KS_SGR_MOUSE, (char_u *)(term_is_8bit(T_NAME)
--- 3862,3871
else
del_mouse_termcode(KS_URXVT_MOUSE);
# endif
if (use_xterm_mouse() == 4
! # ifdef FEAT_GUI
&& !gui.in_use
! # endif
)
{
set_mouse_termcode(KS_SGR_MOUSE, (char_u *)(term_is_8bit(T_NAME)
***
*** 3890,3896
del_mouse_termcode(KS_SGR_MOUSE);
del_mouse_termcode(KS_SGR_MOUSE_RELEASE);
}
- # endif
}
#endif
--- 3887,3892
*** ../vim-8.1.1033/src/term.c 2019-02-17 17:44:36.219875473 +0100
--- src/term.c 2019-03-22 11:54:14.909506042 +0100
***
*** 2126,2138
has_mouse_termcode |= HMT_URXVT;
else
# endif
- # ifdef FEAT_MOUSE_SGR
if (n == KS_SGR_MOUSE)
has_mouse_termcode |= HMT_SGR;
else if (n == KS_SGR_MOUSE_RELEASE)
has_mouse_termcode |= HMT_SGR_REL;
else
- # endif
has_mouse_termcode |= HMT_NORMAL;
# endif
}
--- 2126,2136
***
*** 2175,2187
has_mouse_termcode &= ~HMT_URXVT;
else
# endif
- # ifdef FEAT_MOUSE_SGR
if (n == KS_SGR_MOUSE)
has_mouse_termcode &= ~HMT_SGR;
else if (n == KS_SGR_MOUSE_RELEASE)
has_mouse_termcode &= ~HMT_SGR_REL;
else
- # endif
has_mouse_termcode &= ~HMT_NORMAL;
# endif
}
--- 2173,2183
***
*** 4690,4696
if (tp[1 + (tp[0] != CSI)] == '>' && semicols == 2)
{
int need_flush = FALSE;
- # ifdef FEAT_MOUSE_SGR
int is_iterm2 = FALSE;
int is_mintty = FALSE;
--- 4686,4691
***
*** 4698,4704
// (77 is ASCII 'M' for mintty.)
if (STRNCMP(tp + extra - 3, "77;", 3) == 0)
is_mintty = TRUE;
- # endif
/* if xterm version >= 141 try to get termcap codes */
if (version >= 141)
--- 4693,4698
***
*** 4718,4729
* 256, libvterm supports even more. */
if (mch_getenv((char_u *)"COLORS") == NULL)
may_adjust_color_count(256);
- # ifdef FEAT_MOUSE_SGR
/* Libvterm can handle SGR mouse reporting. */
if (!option_was_set((char_u *)"ttym"))
set_option_value((char_u *)"ttym", 0L,
(char_u *)"sgr", 0);
- # endif
}
if (version == 95)
--- 4712,4721
***
*** 4734,4747
is_not_xterm = TRUE;
is_mac_terminal = TRUE;
}
- # ifdef FEAT_MOUSE_SGR
Patch 8.1.1033
Patch 8.1.1033
Problem:Memory usage test may still fail on some systems. (Elimar
Riesebieter)
Solution: Increase tolerance from 1% to 3%.
Files: src/testdir/test_memory_usage.vim
*** ../vim-8.1.1032/src/testdir/test_memory_usage.vim 2019-03-21
21:16:32.988734329 +0100
--- src/testdir/test_memory_usage.vim 2019-03-22 11:30:54.389943874 +0100
***
*** 138,146
endfor
" The usage may be a bit less than the last value, use 80%.
! " Allow for 1% tolerance at the upper limit.
let lower = before * 8 / 10
! let upper = (after.max + (after.last - before)) * 101 / 100
call assert_inrange(lower, upper, last)
call vim.stop()
--- 138,146
endfor
" The usage may be a bit less than the last value, use 80%.
! " Allow for 3% tolerance at the upper limit.
let lower = before * 8 / 10
! let upper = (after.max + (after.last - before)) * 103 / 100
call assert_inrange(lower, upper, last)
call vim.stop()
*** ../vim-8.1.1032/src/version.c 2019-03-21 21:45:30.887282025 +0100
--- src/version.c 2019-03-22 11:31:39.321673113 +0100
***
*** 781,782
--- 781,784
{ /* Add new patch number below this line */
+ /**/
+ 1033,
/**/
--
A fool learns from his mistakes, a wise man from someone else's.
/// Bram Moolenaar -- b...@moolenaar.net -- http://www.Moolenaar.net \\\
///sponsor Vim, vote for features -- http://www.Vim.org/sponsor/ \\\
\\\ an exciting new programming language -- http://www.Zimbu.org///
\\\help me help AIDS victims -- http://ICCF-Holland.org///
--
--
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 subscribed to the Google Groups
"vim_dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to vim_dev+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
Re: Patch 8.1.1031
Elimar Riesebieter wrote: > * Bram Moolenaar [2019-03-21 21:16 +0100]: > > > > > Patch 8.1.1031 > > Problem:Memory usage test may still fail. > > Solution: Drop the unused min value. (Christian Brabandt) > > Files: src/testdir/test_memory_usage.vim > > Still get on i686: > > From test_memory_usage.vim: > Found errors in Test_memory_func_capture_lvars(): > function RunTheTest[40]..Test_memory_func_capture_lvars line 33: Expected > range 10051 - 26967, but got 27516 > TEST FAILURE I added 1% and this goes over the limit by 1.02%. I guess I'll have to make the tolerance 3%. -- I AM THANKFUL... ...for a lawn that needs mowing, windows that need cleaning and gutters that need fixing because it means I have a home. /// Bram Moolenaar -- b...@moolenaar.net -- http://www.Moolenaar.net \\\ ///sponsor Vim, vote for features -- http://www.Vim.org/sponsor/ \\\ \\\ an exciting new programming language -- http://www.Zimbu.org/// \\\help me help AIDS victims -- http://ICCF-Holland.org/// -- -- 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 subscribed to the Google Groups "vim_dev" group. To unsubscribe from this group and stop receiving emails from it, send an email to vim_dev+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: vim-win32-installer build on appveyor failed
On Fr, 22 Mär 2019, Christian Brabandt wrote: > (Let's see if this mail comes through) No, it was still in the moderation queue because Google suspects that I am spamming. Best, Christian -- -- 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 subscribed to the Google Groups "vim_dev" group. To unsubscribe from this group and stop receiving emails from it, send an email to vim_dev+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: vim-win32-installer build on appveyor failed
(Let's see if this mail comes through) > --- You received this message because you are subscribed to the Google For some reason, Google started moderating Brams and my mails to this list and I had to manually confirm that we are allowed to post here. That is a bit ridiculous. I have confirmed that we are trusted members ;) Hopefully it won't happen again. Best, Christian -- KOMMUNIKATIVE BEWEISMETHODE: "Weiß das vielleicht jemand von ihnen?" -- -- 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 subscribed to the Google Groups "vim_dev" group. To unsubscribe from this group and stop receiving emails from it, send an email to vim_dev+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: vim-win32-installer build on appveyor failed
On Mi, 20 Mär 2019, Christian Brabandt wrote: > Bram, > the latest build of the vim-win32-installer failed with this error > message: > > https://ci.appveyor.com/project/chrisbra/vim-win32-installer/builds/23206196/job/2i61rw80gx51ubv7#L6622 > > function RunTheTest[40]..Test_memory_func_capture_lvars line 29: > Expected range 23092 - 43324, but got 22800 I did re-trigger the build. This time, the x86 build failed with https://ci.appveyor.com/project/chrisbra/vim-win32-installer/build/job/ii6lq86sb7mycfac#L6600 function RunTheTest[40]..Test_memory_func_capture_lvars line 29: Expected range 18180 - 32420, but got 17752 Found errors in Test_memory_func_capture_vargs(): function RunTheTest[40]..Test_memory_func_capture_vargs line 24: Expected 17484 but got 18188 I don't actually understand the test test_memory_usage, but I wonder why in Test_memory_func_capture_vargs it is expected, that after.last == after.max ,[ Test_memory_func_capture_lvars ]- | " In this case, garbase collecting is not needed. | call assert_equal(after.last, after.max) ` Perhaps those tests should be added to the flaky tests? Or may be, we don't need the assert_equal, since there is the assert_inrange() test just before that? Not sure. Best, Christian -- Der Mensch erträgt ein neues Übel darum unwilliger als ein größeres altes, weil sie es, aus Mangel an Wiederholung, noch für kein notwendiges halten. -- Jean Paul -- -- 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 subscribed to the Google Groups "vim_dev" group. To unsubscribe from this group and stop receiving emails from it, send an email to vim_dev+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: Patch 8.1.1031
* Bram Moolenaar [2019-03-21 21:16 +0100]: > > Patch 8.1.1031 > Problem:Memory usage test may still fail. > Solution: Drop the unused min value. (Christian Brabandt) > Files:src/testdir/test_memory_usage.vim Still get on i686: >From test_memory_usage.vim: Found errors in Test_memory_func_capture_lvars(): function RunTheTest[40]..Test_memory_func_capture_lvars line 33: Expected range 10051 - 26967, but got 27516 TEST FAILURE Elimar -- Never make anything simple and efficient when a way can be found to make it complex and wonderful ;-) -- -- 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 subscribed to the Google Groups "vim_dev" group. To unsubscribe from this group and stop receiving emails from it, send an email to vim_dev+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
