Re: [vim/vim] getjumplist() is not as useful as it should (#4145)
Hi, On Thu, Mar 21, 2019 at 1:35 PM Romain Lafourcade wrote: > > getjumplist() was added in #2609. It purports to allow people to get a > usable representation of the jumplist but it fails to do so. > > First, getjumplist()[0] is inverted compared to :jumps, with jump 0 > being at [-1] and so on. Yes we can reverse() it to get the expected > representation but that shouldn't be necessary. > > Second, the items in getjumplist()[0] don't contain the most important > information: the jump number. Without that information, "getting the > jump list", is debatably useful because we don't get any actual "jump" > in the returned list. > The attached patch adds a jump number to each entry in the list returned by getjumplist(). - Yegappan > Third, the index of those items can't be used to infer actual jump > numbers because jump #0 can be anywhere in the list and have relative > numbers above and below. > > Fourth, getjumplist()[1] is the last position reachable with but > the newest position reachable with is not there. > -- -- 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. jumpnr.diff Description: Binary data
Re: [vim/vim] getjumplist() is not as useful as it should (#4145)
Hi, On Thu, Mar 21, 2019 at 1:35 PM Romain Lafourcade wrote: > > getjumplist() was added in #2609. It purports to allow people to get a > usable representation of the jumplist but it fails to do so. > > First, getjumplist()[0] is inverted compared to :jumps, with jump 0 > being at [-1] and so on. Yes we can reverse() it to get the expected > representation but that shouldn't be necessary. > The getjumplist() function returns the list of entries in the order in which the ":jumps" command lists them. So the first entry in the returned list may be the entry with the highest jump number as displayed by the ":jumps" command. Note that if you use or to traverse the jump list, the jump list number for each entry will change and the last entry may not be the one with the first jump list number. > > Second, the items in getjumplist()[0] don't contain the most important > information: the jump number. Without that information, "getting the > jump list", is debatably useful because we don't get any actual "jump" > in the returned list. > The jump number for each entry can be derived from the second number returned by getjumplist(). The ":jumps" command uses the following to derive the jump number: i > curwin->w_jumplistidx ? i - curwin->w_jumplistidx : curwin->w_jumplistidx - i, where i is the index of the jump list entry. > > Third, the index of those items can't be used to infer actual jump > numbers because jump #0 can be anywhere in the list and have relative > numbers above and below. > > Fourth, getjumplist()[1] is the last position reachable with but > the newest position reachable with is not there. > To find the position reachable with you can add 1 to the number returned by getjumplist() (second item in the list). - Yegappan -- -- 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.1032
Patch 8.1.1032
Problem:Warnings from clang static analyzer. (Yegappan Lakshmanan)
Solution: Fix relevant warnings.
Files: src/arabic.c, src/edit.c, src/eval.c, src/fileio.c, src/normal.c,
src/option.c, src/os_unix.c, src/regexp.c, src/screen.c,
src/channel.c, src/charset.c, src/message.c
*** ../vim-8.1.1031/src/arabic.c2018-09-30 21:43:17.175693433 +0200
--- src/arabic.c2019-03-20 22:22:35.211792256 +0100
***
*** 578,586
/* half-shape current and previous character */
shape_c = half_shape(prev_c);
- /* Save away current character */
- curr_c = c;
-
curr_laa = A_firstc_laa(c, *c1p);
prev_laa = A_firstc_laa(prev_c, prev_c1);
--- 578,583
*** ../vim-8.1.1031/src/edit.c 2019-02-17 17:44:36.199875566 +0100
--- src/edit.c 2019-03-20 22:27:34.349141549 +0100
***
*** 4109,4119
static buf_T *
ins_compl_next_buf(buf_T *buf, int flag)
{
! static win_T *wp;
! if (flag == 'w') /* just windows */
{
! if (buf == curbuf) /* first call for this flag/expansion */
wp = curwin;
while ((wp = (wp->w_next != NULL ? wp->w_next : firstwin)) != curwin
&& wp->w_buffer->b_scanned)
--- 4109,4119
static buf_T *
ins_compl_next_buf(buf_T *buf, int flag)
{
! static win_T *wp = NULL;
! if (flag == 'w') // just windows
{
! if (buf == curbuf || wp == NULL) // first call for this flag/expansion
wp = curwin;
while ((wp = (wp->w_next != NULL ? wp->w_next : firstwin)) != curwin
&& wp->w_buffer->b_scanned)
*** ../vim-8.1.1031/src/eval.c 2019-03-19 23:04:13.762889231 +0100
--- src/eval.c 2019-03-21 21:26:31.371960388 +0100
***
*** 8544,8550
char_u*p;
garray_T ga;
int len;
! int save_did_emsg = did_emsg;
ga_init2(, 1, 80);
--- 8544,8550
char_u*p;
garray_T ga;
int len;
! int save_did_emsg;
ga_init2(, 1, 80);
***
*** 8552,8558
++emsg_skip;
while (*arg != NUL && *arg != '|' && *arg != '\n')
{
- p = arg;
ret = eval1_emsg(, , !eap->skip);
if (ret == FAIL)
break;
--- 8552,8557
*** ../vim-8.1.1031/src/fileio.c2019-02-21 12:16:06.196542536 +0100
--- src/fileio.c2019-03-21 21:27:36.035466453 +0100
***
*** 2322,2331
vim_free(fenc);
#ifdef USE_ICONV
if (iconv_fd != (iconv_t)-1)
- {
iconv_close(iconv_fd);
- iconv_fd = (iconv_t)-1;
- }
#endif
if (!read_buffer && !read_stdin)
--- 2322,2328
*** ../vim-8.1.1031/src/normal.c2019-02-17 17:44:36.215875493 +0100
--- src/normal.c2019-03-21 21:28:19.967132356 +0100
***
*** 214,220
{NL, nv_down,0, FALSE},
{Ctrl_K, nv_error, 0, 0},
{Ctrl_L, nv_clear, 0, 0},
! {Ctrl_M, nv_down,0, TRUE},
{Ctrl_N, nv_down,NV_STS, FALSE},
{Ctrl_O, nv_ctrlo, 0, 0},
{Ctrl_P, nv_up, NV_STS, FALSE},
--- 214,220
{NL, nv_down,0, FALSE},
{Ctrl_K, nv_error, 0, 0},
{Ctrl_L, nv_clear, 0, 0},
! {CAR, nv_down,0, TRUE},
{Ctrl_N, nv_down,NV_STS, FALSE},
{Ctrl_O, nv_ctrlo, 0, 0},
{Ctrl_P, nv_up, NV_STS, FALSE},
***
*** 4263,4269
CLEAR_POS(_pos);
for (;;)
{
- valid = FALSE;
t = searchit(curwin, curbuf, >w_cursor, NULL, FORWARD,
pat, 1L, searchflags, RE_LAST, (linenr_T)0, NULL, NULL);
if (curwin->w_cursor.lnum >= old_pos.lnum)
--- 4263,4268
*** ../vim-8.1.1031/src/option.c2019-02-17 17:44:36.215875493 +0100
--- src/option.c2019-03-21 21:29:31.654589459 +0100
***
*** 4405,4411
key = 0;
if (*arg == '<')
{
- nextchar = 0;
opt_idx = -1;
/* look out for ;> */
if (arg[1] == 't' && arg[2] == '_' && arg[3] && arg[4])
--- 4405,4410
***
*** 7945,7951
&& p[len] == ':'
&& p[len + 1] != NUL)
{
! c1 = c2 = c3 = 0;
s = p + len + 1;
c1 = mb_ptr2char_adv();
if (mb_char2cells(c1) > 1)
--- 7944,7950
&& p[len] == ':'
&& p[len + 1] !=
Patch 8.1.1031
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
*** ../vim-8.1.1030/src/testdir/test_memory_usage.vim 2019-03-20
22:44:58.439933744 +0100
--- src/testdir/test_memory_usage.vim 2019-03-21 21:15:30.477266842 +0100
***
*** 36,50
let proc = {}
let proc.pid = a:pid
let proc.hist = []
- let proc.min = 0
let proc.max = 0
func proc.op() abort
" Check the last 200ms.
let val = s:memory_usage(self.pid)
! if self.min > val
! let self.min = val
! elseif self.max < val
let self.max = val
endif
call add(self.hist, val)
--- 36,47
let proc = {}
let proc.pid = a:pid
let proc.hist = []
let proc.max = 0
func proc.op() abort
" Check the last 200ms.
let val = s:memory_usage(self.pid)
! if self.max < val
let self.max = val
endif
call add(self.hist, val)
***
*** 56,62
endfunc
call WaitFor({-> proc.op()}, 1)
! return {'last': get(proc.hist, -1), 'min': proc.min, 'max': proc.max}
endfunc
let s:term_vim = {}
--- 53,59
endfunc
call WaitFor({-> proc.op()}, 1)
! return {'last': get(proc.hist, -1), 'max': proc.max}
endfunc
let s:term_vim = {}
***
*** 101,108
" Estimate the limit of max usage as 2x initial usage.
call assert_inrange(before, 2 * before, after.max)
! " In this case, garbase collecting is not needed.
! call assert_equal(after.last, after.max)
call vim.stop()
call delete(testfile)
--- 98,108
" Estimate the limit of max usage as 2x initial usage.
call assert_inrange(before, 2 * before, after.max)
! " In this case, garbage collecting is not needed. The value might fluctuate
! " a bit, allow for 3% tolerance.
! let lower = after.last * 97 / 100
! let upper = after.last * 103 / 100
! call assert_inrange(lower, upper, after.max)
call vim.stop()
call delete(testfile)
***
*** 137,145
let last = s:monitor_memory_usage(vim.pid).last
endfor
! " The usage may be a bit less than the last value
let lower = before * 8 / 10
! call assert_inrange(lower, after.max + (after.last - before), last)
call vim.stop()
call delete(testfile)
--- 137,147
let last = s:monitor_memory_usage(vim.pid).last
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()
call delete(testfile)
*** ../vim-8.1.1030/src/version.c 2019-03-21 21:12:46.282715864 +0100
--- src/version.c 2019-03-21 21:14:25.381831859 +0100
***
*** 781,782
--- 781,784
{ /* Add new patch number below this line */
+ /**/
+ 1031,
/**/
--
I AM THANKFUL...
...for the mess to clean after a party because it means I have
been surrounded by friends.
/// 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.1030
Patch 8.1.1030
Problem:Quickfix function arguments are inconsistent.
Solution: Pass a list pointer instead of info and index. (Yegappan
Lakshmanan, closes #4135)
Files: src/quickfix.c
*** ../vim-8.1.1029/src/quickfix.c 2019-03-17 16:39:01.566006172 +0100
--- src/quickfix.c 2019-03-21 21:09:35.184333803 +0100
***
*** 160,169
static efm_T *fmt_start = NULL; // cached across qf_parse_line() calls
static void qf_new_list(qf_info_T *qi, char_u *qf_title);
! static intqf_add_entry(qf_info_T *qi, int qf_idx, char_u *dir, char_u
*fname, char_u *module, int bufnum, char_u *mesg, long lnum, int col, int
vis_col, char_u *pattern, int nr, int type, int valid);
static void qf_free(qf_list_T *qfl);
static char_u *qf_types(int, int);
! static intqf_get_fnum(qf_info_T *qi, int qf_idx, char_u *, char_u *);
static char_u *qf_push_dir(char_u *, struct dir_stack_T **, int
is_file_stack);
static char_u *qf_pop_dir(struct dir_stack_T **);
static char_u *qf_guess_filepath(qf_list_T *qfl, char_u *);
--- 160,169
static efm_T *fmt_start = NULL; // cached across qf_parse_line() calls
static void qf_new_list(qf_info_T *qi, char_u *qf_title);
! static intqf_add_entry(qf_list_T *qfl, char_u *dir, char_u *fname, char_u
*module, int bufnum, char_u *mesg, long lnum, int col, int vis_col, char_u
*pattern, int nr, int type, int valid);
static void qf_free(qf_list_T *qfl);
static char_u *qf_types(int, int);
! static intqf_get_fnum(qf_list_T *qfl, char_u *, char_u *);
static char_u *qf_push_dir(char_u *, struct dir_stack_T **, int
is_file_stack);
static char_u *qf_pop_dir(struct dir_stack_T **);
static char_u *qf_guess_filepath(qf_list_T *qfl, char_u *);
***
*** 1322,1329
*/
static int
qf_parse_multiline_pfx(
- qf_info_T *qi,
- int qf_idx,
int idx,
qf_list_T *qfl,
qffields_T *fields)
--- 1322,1327
***
*** 1361,1367
qfprev->qf_col = fields->col;
qfprev->qf_viscol = fields->use_viscol;
if (!qfprev->qf_fnum)
! qfprev->qf_fnum = qf_get_fnum(qi, qf_idx,
qfl->qf_directory,
*fields->namebuf || qfl->qf_directory != NULL
? fields->namebuf
--- 1359,1365
qfprev->qf_col = fields->col;
qfprev->qf_viscol = fields->use_viscol;
if (!qfprev->qf_fnum)
! qfprev->qf_fnum = qf_get_fnum(qfl,
qfl->qf_directory,
*fields->namebuf || qfl->qf_directory != NULL
? fields->namebuf
***
*** 1381,1388
*/
static int
qf_parse_line(
! qf_info_T *qi,
! int qf_idx,
char_u *linebuf,
int linelen,
efm_T *fmt_first,
--- 1379,1385
*/
static int
qf_parse_line(
! qf_list_T *qfl,
char_u *linebuf,
int linelen,
efm_T *fmt_first,
***
*** 1391,1397
efm_T *fmt_ptr;
int idx = 0;
char_u*tail = NULL;
- qf_list_T *qfl = >qf_lists[qf_idx];
int status;
restofline:
--- 1388,1393
***
*** 1450,1456
}
else if (vim_strchr((char_u *)"CZ", idx) != NULL)
{ // continuation of multi-line msg
! status = qf_parse_multiline_pfx(qi, qf_idx, idx, qfl, fields);
if (status != QF_OK)
return status;
}
--- 1446,1452
}
else if (vim_strchr((char_u *)"CZ", idx) != NULL)
{ // continuation of multi-line msg
! status = qf_parse_multiline_pfx(idx, qfl, fields);
if (status != QF_OK)
return status;
}
***
*** 1485,1495
* Returns TRUE if the specified quickfix/location list is empty.
*/
static int
! qf_list_empty(qf_info_T *qi, int qf_idx)
{
! if (qi == NULL || qf_idx < 0 || qf_idx >= LISTCOUNT)
! return TRUE;
! return qi->qf_lists[qf_idx].qf_count <= 0;
}
/*
--- 1481,1498
* Returns TRUE if the specified quickfix/location list is empty.
*/
static int
! qf_list_empty(qf_list_T *qfl)
! {
! return qfl == NULL || qfl->qf_count <= 0;
! }
!
! /*
! * Return a pointer to a list in the specified quickfix stack
! */
! static qf_list_T *
! qf_get_list(qf_info_T *qi, int idx)
{
! return >qf_lists[idx];
}
/*
***
*** 1631,1641
{
// Adding to existing list, use last entry.
adding = TRUE;
! if (!qf_list_empty(qi, qf_idx))
old_last = qi->qf_lists[qf_idx].qf_last;
}
! qfl = >qf_lists[qf_idx];
// Use the local value of 'errorformat' if
Patch 8.1.1029
Patch 8.1.1029
Problem:DirectWrite doesn't take 'linespace' into account.
Solution: Include 'linespace' in the position. (Ken Takata, closes #4137)
Files: src/gui_dwrite.cpp, src/gui_w32.c
*** ../vim-8.1.1028/src/gui_dwrite.cpp 2019-03-16 15:24:39.333662581 +0100
--- src/gui_dwrite.cpp 2019-03-21 20:47:49.029799122 +0100
***
*** 1031,1037
TextRenderer renderer(this);
TextRendererContext context = { color, FLOAT(cellWidth), 0.0f };
! textLayout->Draw(, , FLOAT(x), FLOAT(y) - 0.5f);
}
SafeRelease();
--- 1031,1037
TextRenderer renderer(this);
TextRendererContext context = { color, FLOAT(cellWidth), 0.0f };
! textLayout->Draw(, , FLOAT(x), FLOAT(y));
}
SafeRelease();
*** ../vim-8.1.1028/src/gui_w32.c 2019-01-28 22:32:54.891909109 +0100
--- src/gui_w32.c 2019-03-21 20:47:49.029799122 +0100
***
*** 6337,6343
{
/* Add one to "cells" for italics. */
DWriteContext_DrawText(s_dwc, unicodebuf, wlen,
! TEXT_X(col), TEXT_Y(row), FILL_X(cells + 1), FILL_Y(1),
gui.char_width, gui.currFgColor,
foptions, pcliprect, unicodepdy);
}
--- 6337,6344
{
/* Add one to "cells" for italics. */
DWriteContext_DrawText(s_dwc, unicodebuf, wlen,
! TEXT_X(col), TEXT_Y(row),
! FILL_X(cells + 1), FILL_Y(1) - p_linespace,
gui.char_width, gui.currFgColor,
foptions, pcliprect, unicodepdy);
}
*** ../vim-8.1.1028/src/version.c 2019-03-21 19:57:57.491816288 +0100
--- src/version.c 2019-03-21 20:49:23.325083994 +0100
***
*** 781,782
--- 781,784
{ /* Add new patch number below this line */
+ /**/
+ 1029,
/**/
--
There's no place like $(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: Patch 8.1.1027
Elimar Riesebieter wrote: > * Bram Moolenaar [2019-03-20 22:45 +0100]: > > > > > Patch 8.1.1027 > > Problem:Memory usage test sometimes fails. > > Solution: Use 80% of before.last as the lower limit. (Christian Brabandt) > > Files: src/testdir/test_memory_usage.vim > > Building 8.1.1027 on linux i686 I get: > >From test_memory_usage.vim: > Found errors in Test_memory_func_capture_lvars(): > function RunTheTest[40]..Test_memory_func_capture_lvars line 31: Expected > range 10115 - 27580, but got 27596 > TEST FAILURE Just a tiny bit over the limit. We can tolerate 1%. -- >From "know your smileys": :-&Eating spaghetti /// 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.1028
Patch 8.1.1028
Problem:MS-Windows: memory leak when creating terminal fails.
Solution: Free the command. (Ken Takata, closes #4138)
Files: src/os_win32.c
*** ../vim-8.1.1027/src/os_win32.c 2019-03-17 14:54:50.453256679 +0100
--- src/os_win32.c 2019-03-21 19:56:14.860462625 +0100
***
*** 4866,4872
--- 4866,4875
argvar[1].v_type = VAR_UNKNOWN;
buf = term_start(argvar, NULL, , TERM_START_SYSTEM);
if (buf == NULL)
+ {
+ vim_free(newcmd);
return 255;
+ }
job = term_getjob(buf->b_term);
++job->jv_refcount;
*** ../vim-8.1.1027/src/version.c 2019-03-20 22:44:58.439933744 +0100
--- src/version.c 2019-03-21 19:57:20.720047863 +0100
***
*** 781,782
--- 781,784
{ /* Add new patch number below this line */
+ /**/
+ 1028,
/**/
--
>From "know your smileys":
:-DBig smile
/// 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
Christian wrote: > On Do, 21 Mär 2019, Bram Moolenaar wrote: > > Ah, that makes sense. Although it makes me wonder if we need this value > > at all. We can just remove "min" and everything works. > > okay, so how about this then: Yeah, that's what I also did. > > When this fails, what are the values? Perhaps this should also use > > assert_inrange()? > > function RunTheTest[40]..Test_memory_func_capture_vargs line 24: > Expected 17548 but got 17832 > > I am not sure why it is actually larger than expected. Also the test > mentions: > > , > | " In this case, garbase collecting is not needed. > | call assert_equal(after.last, after.max) > ` > > So max is larger than last. Does that mean, that garbage collection has > already kicked in and released some memory? It's very well possible that the system cleans up some stuff. It's less than a 2% difference. How about this: " Estimate the limit of max usage as 2x initial usage. call assert_inrange(before, 2 * before, after.max) " In this case, garbage collecting is not needed. The value might fluctuate " a bit, allow for 3% tolerance. call assert_inrange(after.last * 97 / 100, after.last * 103 / 100, after.max) -- >From "know your smileys": +<(:-) The Pope /// 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.1027
On Do, 21 Mär 2019, Elimar Riesebieter wrote: > * Bram Moolenaar [2019-03-20 22:45 +0100]: > > > > > Patch 8.1.1027 > > Problem:Memory usage test sometimes fails. > > Solution: Use 80% of before.last as the lower limit. (Christian Brabandt) > > Files: src/testdir/test_memory_usage.vim > > Building 8.1.1027 on linux i686 I get: > From test_memory_usage.vim: > Found errors in Test_memory_func_capture_lvars(): > function RunTheTest[40]..Test_memory_func_capture_lvars line 31: Expected > range 10115 - 27580, but got 27596 > TEST FAILURE So in your case the upper limit is not correct. Best, Christian -- Das Erlebte weiß jeder zu schätzen, am meisten der Denkende und Nachsinnende im Alter; er fühlt mit Zuversicht und Behaglichkeit, dass ihm das niemand rauben kann. -- Goethe, Maximen und Reflektionen, Nr. 10 -- -- 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.1027
* Elimar Riesebieter [2019-03-21 16:59 +0100]: > * Bram Moolenaar [2019-03-20 22:45 +0100]: > > > > > Patch 8.1.1027 > > Problem:Memory usage test sometimes fails. > > Solution: Use 80% of before.last as the lower limit. (Christian Brabandt) > > Files: src/testdir/test_memory_usage.vim > > Building 8.1.1027 on linux i686 I get: > >From test_memory_usage.vim: > Found errors in Test_memory_func_capture_lvars(): > function RunTheTest[40]..Test_memory_func_capture_lvars line 31: Expected > range 10115 - 27580, but got 27596 > TEST FAILURE ppc32 and amd64 builds fine, though Elimar -- "Talking much about oneself can also be a means to conceal oneself." -Friedrich Nietzsche -- -- 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.1027
* Bram Moolenaar [2019-03-20 22:45 +0100]: > > Patch 8.1.1027 > Problem:Memory usage test sometimes fails. > Solution: Use 80% of before.last as the lower limit. (Christian Brabandt) > Files:src/testdir/test_memory_usage.vim Building 8.1.1027 on linux i686 I get: >From test_memory_usage.vim: Found errors in Test_memory_func_capture_lvars(): function RunTheTest[40]..Test_memory_func_capture_lvars line 31: Expected range 10115 - 27580, but got 27596 TEST FAILURE Elimar -- From The Collaborative International Dictionary of English v.0.48 [gcide]: . arsehole \arse"hole`\ ([aum]rs"h[=o]l`), n. 1. execretory opening at the end of the alimentary canal. -- -- 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 Do, 21 Mär 2019, Bram Moolenaar wrote:
> Ah, that makes sense. Although it makes me wonder if we need this value
> at all. We can just remove "min" and everything works.
okay, so how about this then:
diff --git a/src/testdir/test_memory_usage.vim
b/src/testdir/test_memory_usage.vim
index b70d2d03f..b387edc1a 100644
--- a/src/testdir/test_memory_usage.vim
+++ b/src/testdir/test_memory_usage.vim
@@ -36,15 +36,12 @@ func s:monitor_memory_usage(pid) abort
let proc = {}
let proc.pid = a:pid
let proc.hist = []
- let proc.min = 0
let proc.max = 0
func proc.op() abort
" Check the last 200ms.
let val = s:memory_usage(self.pid)
-if self.min > val
- let self.min = val
-elseif self.max < val
+if self.max < val
let self.max = val
endif
call add(self.hist, val)
@@ -56,7 +53,7 @@ func s:monitor_memory_usage(pid) abort
endfunc
call WaitFor({-> proc.op()}, 1)
- return {'last': get(proc.hist, -1), 'min': proc.min, 'max': proc.max}
+ return {'last': get(proc.hist, -1), 'max': proc.max}
endfunc
let s:term_vim = {}
> When this fails, what are the values? Perhaps this should also use
> assert_inrange()?
function RunTheTest[40]..Test_memory_func_capture_vargs line 24:
Expected 17548 but got 17832
I am not sure why it is actually larger than expected. Also the test
mentions:
,
| " In this case, garbase collecting is not needed.
| call assert_equal(after.last, after.max)
`
So max is larger than last. Does that mean, that garbage collection has
already kicked in and released some memory?
Best,
Christian
--
Stell Dir vor es ist Frühling und kein Baum wird mehr grün.
--
--
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, Bram Moolenaar wrote:
>
> > > 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
> > >
> > > It is kind of strange, that the test fails, because Vim uses less memory
> > > than expected. So I wonder, if this patch would make a difference:
> >
> > When I run it the "min" value is zero, thus that doesn't work well.
>
> Yeah you are right, min can never be larger than zero. I think the test
> is wrong and we need this:
>
> diff --git a/src/testdir/test_memory_usage.vim
> b/src/testdir/test_memory_usage.vim
> index 23dcc62ac..62607a6f9 100644
> --- a/src/testdir/test_memory_usage.vim
> +++ b/src/testdir/test_memory_usage.vim
> @@ -36,7 +36,7 @@ func s:monitor_memory_usage(pid) abort
>let proc = {}
>let proc.pid = a:pid
>let proc.hist = []
> - let proc.min = 0
> + let proc.min =
>let proc.max = 0
Ah, that makes sense. Although it makes me wonder if we need this value
at all. We can just remove "min" and everything works.
> > For me the "last" value is also very close to "before.last".
> > Let's use 80% of the "before.last" value.
>
> It still fails for line 24 of Test_memory_func_capture_vargs()
> which is this one:
>
> ,
> | " In this case, garbase collecting is not needed.
> | call assert_equal(after.last, after.max)
> `
>
> Perhaps this should be skipped for Windows x86? Or at least be set to be
> flaky?
> https://ci.appveyor.com/project/chrisbra/vim-win32-installer/build/job/ph4jsqdjrpvil27t
> (this is the x86 build, not the 64 bit build.)
>
> Can anybody here that builds Vim on Windows reproduce the problem with
> this test on Windows?
When this fails, what are the values? Perhaps this should also use
assert_inrange()?
--
>From "know your smileys":
<>:-) Bishop
/// 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 Mi, 20 Mär 2019, Bram Moolenaar wrote:
>
> > 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
> >
> > It is kind of strange, that the test fails, because Vim uses less memory
> > than expected. So I wonder, if this patch would make a difference:
>
> When I run it the "min" value is zero, thus that doesn't work well.
Yeah you are right, min can never be larger than zero. I think the test
is wrong and we need this:
diff --git a/src/testdir/test_memory_usage.vim
b/src/testdir/test_memory_usage.vim
index 23dcc62ac..62607a6f9 100644
--- a/src/testdir/test_memory_usage.vim
+++ b/src/testdir/test_memory_usage.vim
@@ -36,7 +36,7 @@ func s:monitor_memory_usage(pid) abort
let proc = {}
let proc.pid = a:pid
let proc.hist = []
- let proc.min = 0
+ let proc.min =
let proc.max = 0
> For me the "last" value is also very close to "before.last".
> Let's use 80% of the "before.last" value.
It still fails for line 24 of Test_memory_func_capture_vargs()
which is this one:
,
| " In this case, garbase collecting is not needed.
| call assert_equal(after.last, after.max)
`
Perhaps this should be skipped for Windows x86? Or at least be set to be flaky?
https://ci.appveyor.com/project/chrisbra/vim-win32-installer/build/job/ph4jsqdjrpvil27t
(this is the x86 build, not the 64 bit build.)
Can anybody here that builds Vim on Windows reproduce the problem with this
test on Windows?
Best,
Christian
--
Uneigennützige Freundschaft gibt es nur unter Leuten gleicher
Einkommensklasse.
-- Jean-Paul Getty
--
--
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.
