Re: Patch 7.4.944

2015-12-01 Fir de Conversatie toothpik
On Sun, Nov 29, 2015 at 10:01:02PM +0100, Bram Moolenaar wrote:

> Christian Brabandt wrote:

> > On So, 29 Nov 2015, Bram Moolenaar wrote:
> > 
> > > 
> > > Nikolay Pavlov wrote:
> > > 
> > > > 2015-11-29 19:36 GMT+03:00 Bram Moolenaar <b...@moolenaar.net>:
> > > > 
> > > > >
> > > > > Patch 7.4.944
> > > > > Problem:Writing tests for Vim script is hard.
> > > > > Solution:   Add assertEqual(), assertFalse() and assertTrue() 
> > > > > functions.
> > > > > Add
> > > > >
> > > > 
> > > > Why `assert{upper case letter}`? I know exactly no functions that use 
> > > > this
> > > > naming convention.
> > > 
> > > Yes, it's different.  There are some other functions with a capital,
> > 
> > There are? Which ones?

> hlID()
> synID()
> synIDattr()

> diff_hlID() is nicely inconsistent..

> > > but many more with an underscore, or just all lower case.
> > > 
> > > But I do think that assertEqual() is easier to read than assertequal()
> > > and it's shorter than assert_equal().  So do we prefer consistency or
> > > nicer names?
> > 
> > +1 for consistency and the underscore.

> Counting votes...

+1 for nicer names, because, my opinion only, they make Bram happy


-- 
-- 
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 7.4.944

2015-11-30 Fir de Conversatie Bram Moolenaar

Ryuichi Hayashida wrote:

> I think assertion message is very important reported when it fails.  Should 
> message be customizable as many assertions in other languages?
> 
>   assertEqual({exp}, {act} [, {msg}])
>   assertFalse({actual} [, {msg}])
>   assertTrue({actual} [, {msg}])
> 
> This is used as below.
> 
>   assertTrue(check_something(label), 'something failed with ' . label)

Yes, I was planning on adding the optional message.  It's just not that
easy to implement, so I left it for later.  I had actually already set
the maximum argument count for that.

I assume that the position would still be prepended to the optional
message.

-- 
hundred-and-one symptoms of being an internet addict:
162. You go outside and look for a brightness knob to turn down the sun.

 /// 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 7.4.944

2015-11-30 Fir de Conversatie Bram Moolenaar

Yasuhiro Matsumoto wrote:

> On Monday, November 30, 2015 at 10:41:21 AM UTC+9, Ryuichi Hayashida wrote:
> > I think assertion message is very important reported when it fails.  Should 
> > message be customizable as many assertions in other languages?
> > 
> >   assertEqual({exp}, {act} [, {msg}])
> >   assertFalse({actual} [, {msg}])
> >   assertTrue({actual} [, {msg}])
> > 
> > This is used as below.
> > 
> >   assertTrue(check_something(label), 'something failed with ' . label)
> 
> Here is a patch.
> 
> https://gist.github.com/mattn/e6405f257bae62ccfe54

Thanks.  I would prefer to get rid of some duplication.  We can assume
there will be more assert functions later.

-- 
hundred-and-one symptoms of being an internet addict:
163. You go outside for the fresh air (at -30 degrees) but open the
 window first to hear new mail arrive.

 /// 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 7.4.944

2015-11-29 Fir de Conversatie Bram Moolenaar

Nikolay Pavlov wrote:

> 2015-11-29 19:36 GMT+03:00 Bram Moolenaar <b...@moolenaar.net>:
> 
> >
> > Patch 7.4.944
> > Problem:Writing tests for Vim script is hard.
> > Solution:   Add assertEqual(), assertFalse() and assertTrue() functions.
> > Add
> >
> 
> Why `assert{upper case letter}`? I know exactly no functions that use this
> naming convention.

Yes, it's different.  There are some other functions with a capital, but
many more with an underscore, or just all lower case.

But I do think that assertEqual() is easier to read than assertequal()
and it's shorter than assert_equal().  So do we prefer consistency or
nicer names?

-- 
hundred-and-one symptoms of being an internet addict:
155. You forget to eat because you're too busy surfing the net.

 /// 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 7.4.944

2015-11-29 Fir de Conversatie Bram Moolenaar

Christian Brabandt wrote:

> On So, 29 Nov 2015, Bram Moolenaar wrote:
> 
> > 
> > Nikolay Pavlov wrote:
> > 
> > > 2015-11-29 19:36 GMT+03:00 Bram Moolenaar <b...@moolenaar.net>:
> > > 
> > > >
> > > > Patch 7.4.944
> > > > Problem:Writing tests for Vim script is hard.
> > > > Solution:   Add assertEqual(), assertFalse() and assertTrue() functions.
> > > > Add
> > > >
> > > 
> > > Why `assert{upper case letter}`? I know exactly no functions that use this
> > > naming convention.
> > 
> > Yes, it's different.  There are some other functions with a capital,
> 
> There are? Which ones?

hlID()
synID()
synIDattr()

diff_hlID() is nicely inconsistent..

> > but many more with an underscore, or just all lower case.
> > 
> > But I do think that assertEqual() is easier to read than assertequal()
> > and it's shorter than assert_equal().  So do we prefer consistency or
> > nicer names?
> 
> +1 for consistency and the underscore.

Counting votes...

-- 
hundred-and-one symptoms of being an internet addict:
160. You get in the elevator and double-click the button for the floor
 you want.

 /// 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 7.4.944

2015-11-29 Fir de Conversatie Nikolay Pavlov
2015-11-29 19:36 GMT+03:00 Bram Moolenaar <b...@moolenaar.net>:

>
> Patch 7.4.944
> Problem:Writing tests for Vim script is hard.
> Solution:   Add assertEqual(), assertFalse() and assertTrue() functions.
> Add
>

​Why `assert{upper case letter}`? I know exactly no functions that use this
naming convention.​



> the v:errors variable.  Add the runtest script. Add a first new
> style test script.
> Files:  src/eval.c, src/vim.h, src/misc2.c, src/testdir/Makefile,
> src/testdir/runtest.vim, src/testdir/test_assert.vim,
> runtime/doc/eval.txt
>
>
> *** ../vim-7.4.943/src/eval.c   2015-09-29 16:53:18.200480733 +0200
> --- src/eval.c  2015-11-29 16:45:12.155720718 +0100
> ***
> *** 368,373 
> --- 368,374 
>   {VV_NAME("option_new", VAR_STRING), VV_RO},
>   {VV_NAME("option_old", VAR_STRING), VV_RO},
>   {VV_NAME("option_type",VAR_STRING), VV_RO},
> + {VV_NAME("errors", VAR_LIST), 0},
>   };
>
>   /* shorthand */
> ***
> *** 472,477 
> --- 473,481 
>   static void f_argidx __ARGS((typval_T *argvars, typval_T *rettv));
>   static void f_arglistid __ARGS((typval_T *argvars, typval_T *rettv));
>   static void f_argv __ARGS((typval_T *argvars, typval_T *rettv));
> + static void f_assertEqual __ARGS((typval_T *argvars, typval_T *rettv));
> + static void f_assertFalse __ARGS((typval_T *argvars, typval_T *rettv));
> + static void f_assertTrue __ARGS((typval_T *argvars, typval_T *rettv));
>   #ifdef FEAT_FLOAT
>   static void f_asin __ARGS((typval_T *argvars, typval_T *rettv));
>   static void f_atan __ARGS((typval_T *argvars, typval_T *rettv));
> ***
> *** 8068,8073 
> --- 8072,8080 
>   {"argidx",0, 0, f_argidx},
>   {"arglistid", 0, 2, f_arglistid},
>   {"argv",  0, 1, f_argv},
> + {"assertEqual",   2, 3, f_assertEqual},
> + {"assertFalse",   1, 2, f_assertFalse},
> + {"assertTrue",1, 2, f_assertTrue},
>   #ifdef FEAT_FLOAT
>   {"asin",  1, 1, f_asin},  /* WJMc */
>   {"atan",  1, 1, f_atan},
> ***
> *** 9124,9129 
> --- 9131,9243 
>alist_name([idx]),
> -1);
>   }
>
> + static void assertError __ARGS((garray_T *gap));
> + static void prepareForAssertError __ARGS((garray_T*gap));
> + static void assertBool __ARGS((typval_T *argvars, int isTrue));
> +
> + /*
> +  * Add an assert error to v:errors.
> +  */
> + static void
> + assertError(gap)
> + garray_T  *gap;
> + {
> + struct vimvar   *vp = [VV_ERRORS];
> +
> + if (vp->vv_type != VAR_LIST || vimvars[VV_ERRORS].vv_list == NULL)
> +   /* Make sure v:errors is a list. */
> +   set_vim_var_list(VV_ERRORS, list_alloc());
> + list_append_string(vimvars[VV_ERRORS].vv_list, gap->ga_data,
> gap->ga_len);
> + }
> +
> + static void
> + prepareForAssertError(gap)
> + garray_T  *gap;
> + {
> + char buf[NUMBUFLEN];
> +
> + ga_init2(gap, 1, 100);
> + ga_concat(gap, sourcing_name);
> + sprintf(buf, " line %ld", (long)sourcing_lnum);
> + ga_concat(gap, (char_u *)buf);
> + }
> +
> + /*
> +  * "assertEqual(expected, actual[, msg])" function
> +  */
> + static void
> + f_assertEqual(argvars, rettv)
> + typval_T  *argvars;
> + typval_T  *rettv UNUSED;
> + {
> + garray_T  ga;
> + char_u*tofree;
> + char_unumbuf[NUMBUFLEN];
> +
> + if (!tv_equal([0], [1], FALSE, FALSE))
> + {
> +   prepareForAssertError();
> +   ga_concat(, (char_u *)": Expected ");
> +   ga_concat(, tv2string([0], , numbuf, 0));
> +   vim_free(tofree);
> +   ga_concat(, (char_u *)" but got ");
> +   ga_concat(, tv2string([1], , numbuf, 0));
> +   vim_free(tofree);
> +   assertError();
> +   ga_clear();
> + }
> + }
> +
> + static void
> + assertBool(argvars, isTrue)
> + typval_T  *argvars;
> + int   isTrue;
> + {
> + int   error = FALSE;
> + garray_T  ga;
> + char_u*tofree;
> + char_unumbuf[NUMBUFLEN];
> +
> + if (argvars[0].v_type != VAR_NUMBER
> +   || (get_tv_number_chk([0], ) == 0) == isTrue
> +   || error)
> + {
> +   prepareForAssertError();
> +   ga_concat(, (char_u *)": Expected ");
> +   if (isTrue)

Re: Patch 7.4.944

2015-11-29 Fir de Conversatie Nikolay Pavlov
2015-11-30 0:01 GMT+03:00 Bram Moolenaar <b...@moolenaar.net>:

>
> Christian Brabandt wrote:
>
> > On So, 29 Nov 2015, Bram Moolenaar wrote:
> >
> > >
> > > Nikolay Pavlov wrote:
> > >
> > > > 2015-11-29 19:36 GMT+03:00 Bram Moolenaar <b...@moolenaar.net>:
> > > >
> > > > >
> > > > > Patch 7.4.944
> > > > > Problem:Writing tests for Vim script is hard.
> > > > > Solution:   Add assertEqual(), assertFalse() and assertTrue()
> functions.
> > > > > Add
> > > > >
> > > >
> > > > Why `assert{upper case letter}`? I know exactly no functions that
> use this
> > > > naming convention.
> > >
> > > Yes, it's different.  There are some other functions with a capital,
> >
> > There are? Which ones?
>
> hlID()
> synID()
> synIDattr()
>
> diff_hlID() is nicely inconsistent..
>

​Forgot about *ID* and thus incorrectly constructed the regex for search
(only searched for functions which have exactly one capital letter). Though
I still prefer `assert_equal`.​

Also I would not say that `assertEqual` is easier to read: due to its
inconsistency it actually reads as “strange function name, *have a closer
look and **double-check** this*”. Attention like this does not make any
good; I saw other examples (e.g. Python: logging.Logger.addHandler which is
against PEP8 that suggests add_handler) and (unless encountered many times
recently) they always make me ask myself whether code is written right
(when reading) or fail the expectations and make me go use the
completion/documentation/code examples/… (when writing).



>
> > > but many more with an underscore, or just all lower case.
> > >
> > > But I do think that assertEqual() is easier to read than assertequal()
> > > and it's shorter than assert_equal().  So do we prefer consistency or
> > > nicer names?
> >
> > +1 for consistency and the underscore.
>
> Counting votes...
>
> --
> hundred-and-one symptoms of being an internet addict:
> 160. You get in the elevator and double-click the button for the floor
>  you want.
>
>  /// 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.
>

-- 
-- 
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 7.4.944

2015-11-29 Fir de Conversatie Tony Mechelynck
I'm not going to take sides here, just compare with some other
project: In Mozilla code (Firefox, Thunderbird, SeaMonkey),
preferences (which are user-visible, at least for technical-minded
users who dare use the about:config interface) are named with
camelCase in some parts of the code and with underscore_divided_names
in other parts: even if we don't enforce strict consistency we won't
be alone.

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 7.4.944

2015-11-29 Fir de Conversatie Bram Moolenaar

Patch 7.4.944
Problem:Writing tests for Vim script is hard.
Solution:   Add assertEqual(), assertFalse() and assertTrue() functions.  Add
the v:errors variable.  Add the runtest script. Add a first new
style test script.
Files:  src/eval.c, src/vim.h, src/misc2.c, src/testdir/Makefile,
src/testdir/runtest.vim, src/testdir/test_assert.vim,
runtime/doc/eval.txt


*** ../vim-7.4.943/src/eval.c   2015-09-29 16:53:18.200480733 +0200
--- src/eval.c  2015-11-29 16:45:12.155720718 +0100
***
*** 368,373 
--- 368,374 
  {VV_NAME("option_new", VAR_STRING), VV_RO},
  {VV_NAME("option_old", VAR_STRING), VV_RO},
  {VV_NAME("option_type",VAR_STRING), VV_RO},
+ {VV_NAME("errors", VAR_LIST), 0},
  };
  
  /* shorthand */
***
*** 472,477 
--- 473,481 
  static void f_argidx __ARGS((typval_T *argvars, typval_T *rettv));
  static void f_arglistid __ARGS((typval_T *argvars, typval_T *rettv));
  static void f_argv __ARGS((typval_T *argvars, typval_T *rettv));
+ static void f_assertEqual __ARGS((typval_T *argvars, typval_T *rettv));
+ static void f_assertFalse __ARGS((typval_T *argvars, typval_T *rettv));
+ static void f_assertTrue __ARGS((typval_T *argvars, typval_T *rettv));
  #ifdef FEAT_FLOAT
  static void f_asin __ARGS((typval_T *argvars, typval_T *rettv));
  static void f_atan __ARGS((typval_T *argvars, typval_T *rettv));
***
*** 8068,8073 
--- 8072,8080 
  {"argidx",0, 0, f_argidx},
  {"arglistid", 0, 2, f_arglistid},
  {"argv",  0, 1, f_argv},
+ {"assertEqual",   2, 3, f_assertEqual},
+ {"assertFalse",   1, 2, f_assertFalse},
+ {"assertTrue",1, 2, f_assertTrue},
  #ifdef FEAT_FLOAT
  {"asin",  1, 1, f_asin},  /* WJMc */
  {"atan",  1, 1, f_atan},
***
*** 9124,9129 
--- 9131,9243 
   alist_name([idx]), -1);
  }
  
+ static void assertError __ARGS((garray_T *gap));
+ static void prepareForAssertError __ARGS((garray_T*gap));
+ static void assertBool __ARGS((typval_T *argvars, int isTrue));
+ 
+ /*
+  * Add an assert error to v:errors.
+  */
+ static void
+ assertError(gap)
+ garray_T  *gap;
+ {
+ struct vimvar   *vp = [VV_ERRORS];
+ 
+ if (vp->vv_type != VAR_LIST || vimvars[VV_ERRORS].vv_list == NULL)
+   /* Make sure v:errors is a list. */
+   set_vim_var_list(VV_ERRORS, list_alloc());
+ list_append_string(vimvars[VV_ERRORS].vv_list, gap->ga_data, gap->ga_len);
+ }
+ 
+ static void
+ prepareForAssertError(gap)
+ garray_T  *gap;
+ {
+ char buf[NUMBUFLEN];
+ 
+ ga_init2(gap, 1, 100);
+ ga_concat(gap, sourcing_name);
+ sprintf(buf, " line %ld", (long)sourcing_lnum);
+ ga_concat(gap, (char_u *)buf);
+ }
+ 
+ /*
+  * "assertEqual(expected, actual[, msg])" function
+  */
+ static void
+ f_assertEqual(argvars, rettv)
+ typval_T  *argvars;
+ typval_T  *rettv UNUSED;
+ {
+ garray_T  ga;
+ char_u*tofree;
+ char_unumbuf[NUMBUFLEN];
+ 
+ if (!tv_equal([0], [1], FALSE, FALSE))
+ {
+   prepareForAssertError();
+   ga_concat(, (char_u *)": Expected ");
+   ga_concat(, tv2string([0], , numbuf, 0));
+   vim_free(tofree);
+   ga_concat(, (char_u *)" but got ");
+   ga_concat(, tv2string([1], , numbuf, 0));
+   vim_free(tofree);
+   assertError();
+   ga_clear();
+ }
+ }
+ 
+ static void
+ assertBool(argvars, isTrue)
+ typval_T  *argvars;
+ int   isTrue;
+ {
+ int   error = FALSE;
+ garray_T  ga;
+ char_u*tofree;
+ char_unumbuf[NUMBUFLEN];
+ 
+ if (argvars[0].v_type != VAR_NUMBER
+   || (get_tv_number_chk([0], ) == 0) == isTrue
+   || error)
+ {
+   prepareForAssertError();
+   ga_concat(, (char_u *)": Expected ");
+   if (isTrue)
+   ga_concat(, (char_u *)"True ");
+   else
+   ga_concat(, (char_u *)"False ");
+   ga_concat(, (char_u *)"but got ");
+   ga_concat(, tv2string([0], , numbuf, 0));
+   vim_free(tofree);
+   assertError();
+   ga_clear();
+ }
+ }
+ 
+ /*
+  * "assertFalse(actual[, msg])" function
+  */
+ static void
+ f_assertFalse(argvars, rettv)
+ typval_T  *argvars;
+ typval_T  *rettv UNUSED;
+ {
+ assertBool(argvars, FALSE);
+ }
+ 
+ /*
+  * "assertTrue(actual[, msg])" function
+  */
+ static void
+ f_assertTrue(argvars, rettv)
+ typval_T  *argvars;
+ typval_T  *rettv UNUSED;
+ {
+ assertBool(argvars, TRUE);
+ }
+ 
  #ifdef FEAT_FLOAT
  /*
   * "asin()" function
*** ../vim-7.4.943/

Re: Patch 7.4.944

2015-11-29 Fir de Conversatie Ryuichi Hayashida
I think assertion message is very important reported when it fails.  Should 
message be customizable as many assertions in other languages?

  assertEqual({exp}, {act} [, {msg}])
  assertFalse({actual} [, {msg}])
  assertTrue({actual} [, {msg}])

This is used as below.

  assertTrue(check_something(label), 'something failed with ' . label)

-- 
-- 
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 7.4.944

2015-11-29 Fir de Conversatie mattn
On Monday, November 30, 2015 at 10:41:21 AM UTC+9, Ryuichi Hayashida wrote:
> I think assertion message is very important reported when it fails.  Should 
> message be customizable as many assertions in other languages?
> 
>   assertEqual({exp}, {act} [, {msg}])
>   assertFalse({actual} [, {msg}])
>   assertTrue({actual} [, {msg}])
> 
> This is used as below.
> 
>   assertTrue(check_something(label), 'something failed with ' . label)

Here is a patch.

https://gist.github.com/mattn/e6405f257bae62ccfe54

-- 
-- 
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 7.4.944

2015-11-29 Fir de Conversatie Mike Williams

On 29/11/2015 21:01, Bram Moolenaar wrote:


Christian Brabandt wrote:


On So, 29 Nov 2015, Bram Moolenaar wrote:



Nikolay Pavlov wrote:


2015-11-29 19:36 GMT+03:00 Bram Moolenaar <b...@moolenaar.net>:



Patch 7.4.944
Problem:Writing tests for Vim script is hard.
Solution:   Add assertEqual(), assertFalse() and assertTrue() functions.
Add



Why `assert{upper case letter}`? I know exactly no functions that use this
naming convention.


Yes, it's different.  There are some other functions with a capital,


There are? Which ones?


hlID()
synID()
synIDattr()

diff_hlID() is nicely inconsistent..


but many more with an underscore, or just all lower case.

But I do think that assertEqual() is easier to read than assertequal()
and it's shorter than assert_equal().  So do we prefer consistency or
nicer names?


+1 for consistency and the underscore.


Counting votes...


+1 for consistency/predictability over inconsistency.  You may not like 
it but life is easier in the long run.


https://en.wikipedia.org/wiki/Principle_of_least_astonishment

Perhaps there also is a case for adding hl_id(), syn_id(), etc.  Or is 
the move to rename all existing functions in camelCase?  Or just new 
ones?  Or special ones, and if so how are special ones recognised?


Mike
--
Virtue is insufficient temptation.

--
--
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 7.4.944

2015-11-29 Fir de Conversatie mattn
On Monday, November 30, 2015 at 11:23:23 AM UTC+9, mattn wrote:
> On Monday, November 30, 2015 at 10:41:21 AM UTC+9, Ryuichi Hayashida wrote:
> > I think assertion message is very important reported when it fails.  Should 
> > message be customizable as many assertions in other languages?
> > 
> >   assertEqual({exp}, {act} [, {msg}])
> >   assertFalse({actual} [, {msg}])
> >   assertTrue({actual} [, {msg}])
> > 
> > This is used as below.
> > 
> >   assertTrue(check_something(label), 'something failed with ' . label)
> 
> Here is a patch.
> 
> https://gist.github.com/mattn/e6405f257bae62ccfe54

and doc.

https://gist.githubusercontent.com/mattn/69e527d8e45791d98e49/raw/3e7c9cf9030c7d89375c5166a1a1ca2fde9f46e8/gistfile1.diff

-- 
-- 
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 7.4.944

2015-11-29 Fir de Conversatie Nikolay Pavlov
2015-11-30 2:10 GMT+03:00 Tony Mechelynck :

> I'm not going to take sides here, just compare with some other
> project: In Mozilla code (Firefox, Thunderbird, SeaMonkey),
> preferences (which are user-visible, at least for technical-minded
> users who dare use the about:config interface) are named with
> camelCase in some parts of the code and with underscore_divided_names
> in other parts: even if we don't enforce strict consistency we won't
> be alone.
>

*​Strict* consistency in a large project is often an exception rather then
a rule (e.g. see my example with Python). But I do not know a project where
authors are intentionally missing chances to be consistent; also
inconsistency in large projects often means legacy, imported or compatible
(with other software: e.g. unit tests with jUnit interface in non-Java
languages) code. These functions have no such excuses AFAIK:

1. they are definitely not legacy
2. neither it is an external work imported by Bram
3. interface and intended usage is different from other unit test systems
(also because most of them use OO interface).


>
> 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.
>

-- 
-- 
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 7.4.944

2015-11-29 Fir de Conversatie Christian Brabandt
Hi Bram!

On So, 29 Nov 2015, Bram Moolenaar wrote:

> 
> Nikolay Pavlov wrote:
> 
> > 2015-11-29 19:36 GMT+03:00 Bram Moolenaar <b...@moolenaar.net>:
> > 
> > >
> > > Patch 7.4.944
> > > Problem:Writing tests for Vim script is hard.
> > > Solution:   Add assertEqual(), assertFalse() and assertTrue() functions.
> > > Add
> > >
> > 
> > Why `assert{upper case letter}`? I know exactly no functions that use this
> > naming convention.
> 
> Yes, it's different.  There are some other functions with a capital,

There are? Which ones?

> but many more with an underscore, or just all lower case.
> 
> But I do think that assertEqual() is easier to read than assertequal()
> and it's shorter than assert_equal().  So do we prefer consistency or
> nicer names?

+1 for consistency and the underscore.

Best,
Christian
-- 
Sich selbst darf man nicht für so göttlich halten, daß man seine
eigenen Werke nicht gelegentlich verbessern könnte.
-- Ludwig van Beethoven

-- 
-- 
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.