Re: Compilation warning: gdk_pixbuf_new_from_inline is deprecated (@ gui_gtk.c line 152)
On Mon, Nov 30, 2015 at 8:02 AM, Marius Gedminas wrote: > On Mon, Nov 30, 2015 at 12:01:07AM +0100, Tony Mechelynck wrote: >> When compiling 7.4.944, huge, with GTK2/Gnome2 GUI (i don't know >> exactly at which changeset it appeared): >> >> gcc -c -I. [...] -o objects/gui_gtk.o gui_gtk.c >> gui_gtk.c: In function ‘add_stock_icon’: >> gui_gtk.c:152:5: warning: ‘gdk_pixbuf_new_from_inline’ is deprecated >> (declared at /usr/include/gdk-pixbuf-2.0/gdk-pixbuf/gdk-pixbuf-core.h:314) >> [-Wdeprecated-declarations] >> pixbuf = gdk_pixbuf_new_from_inline(data_length, inline_data, FALSE, >> NULL); >> ^ >> >> I don't know if we can do something about it now; but as everyone >> knows, "deprecated in one release may mean removed in the next >> release" and if and when that happens we'll be in trouble. > > GTK+ 2.x is no longer being maintained; it's unlikely that someone will > create a new release and remove deprecated functions. > > Is anyone working on porting Vim to GTK+ 3? > > Marius Gedminas Not AFAIK; but now that there is a GTK+3, GTK+2 is bound to end where GTK+1 already is — down the drain. 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.
Re: Compilation warning: gdk_pixbuf_new_from_inline is deprecated (@ gui_gtk.c line 152)
On Mon, Nov 30, 2015 at 12:01:07AM +0100, Tony Mechelynck wrote: > When compiling 7.4.944, huge, with GTK2/Gnome2 GUI (i don't know > exactly at which changeset it appeared): > > gcc -c -I. [...] -o objects/gui_gtk.o gui_gtk.c > gui_gtk.c: In function ‘add_stock_icon’: > gui_gtk.c:152:5: warning: ‘gdk_pixbuf_new_from_inline’ is deprecated > (declared at /usr/include/gdk-pixbuf-2.0/gdk-pixbuf/gdk-pixbuf-core.h:314) > [-Wdeprecated-declarations] > pixbuf = gdk_pixbuf_new_from_inline(data_length, inline_data, FALSE, > NULL); > ^ > > I don't know if we can do something about it now; but as everyone > knows, "deprecated in one release may mean removed in the next > release" and if and when that happens we'll be in trouble. GTK+ 2.x is no longer being maintained; it's unlikely that someone will create a new release and remove deprecated functions. Is anyone working on porting Vim to GTK+ 3? Marius Gedminas -- We did it for smallpox, we'll also win over on ISO 8859-1 ... ;-) -- Markus Kuhn after eradicating one more ISO 8859-1 file from his disk -- -- 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: Digital signature
Re: Patch 7.4.944
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
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.
Cannot build 32-bit Vim using 64-bit capable mingw
Vim developers, I am trying to build 32-bit Vim using a mingw compiler that generates 64-bit output files by default. I specify ARCH=i686 on the make command line. Compilation fails with the first file because -m64 is the compiler default. This problem would not occur if the makefile src/Make_cyg_ming.mak included the -m32 compiler option but, as of patch 942, it does not. Assuming this change is made, the next problem occurs when Windows resource files are created. Now I don't claim to understand such things very well but apparently there are 64-bit versions and 32-bit versions and they are specified through the --target option: "--target=pe-x86-64" for 64-bit builds and "--target=pe-i386" for 32-bit builds (this took some investigation). A review of the makefile suggests that this parameter should be defined in the WINDRES_FLAGS make variable. Setting this parameter as indicated solves the remaining build problem. So, here are the makefiles that I had to modify: src/Make_ming.mak src/Make_cyg_ming.mak GvimExt/Make_ming.mak xxd/Make_ming.mak The lines below show my diffs relative to patch 942. I purposely organized the changes so that they affect mingw builds exclusively. Mike - diff --git a/src/Make_ming.mak b/src/Make_ming.mak index 9ed1a70..a760302 100644 --- a/src/Make_ming.mak +++ b/src/Make_ming.mak @@ -43,6 +43,21 @@ # uncomment 'RUBY' if you want a Ruby-enabled version #RUBY=c:/ruby +# To build 32-bit Vim using a mingw that generates 64-bit code by default, +# some extra flags need to be set. I've defined these flags using the new +# make variables "CFLAGS_EXTRA" and "WINDRES_FLAGS_EXTRA" and added references +# to them in the file "make_cyg_ming.mak". In this way, only the mingw +# build is affected. +# +# Similar changes also must be made to Make_ming.mak in GvimExt and xxd. +# +ifeq ($(ARCH),x86-64) +CFLAGS_EXTRA = -m64 +WINDRES_FLAGS_EXTRA = --target=pe-x86-64 +else +CFLAGS_EXTRA = -m32 +WINDRES_FLAGS_EXTRA = --target=pe-i386 +endif # Do not change this. UNDER_CYGWIN = no diff --git a/src/Make_cyg_ming.mak b/src/Make_cyg_ming.mak index d10817a..646ac22 100644 --- a/src/Make_cyg_ming.mak +++ b/src/Make_cyg_ming.mak @@ -723,6 +723,13 @@ LIB += -lstdc++ endif endif +# The following two statements allow the caller to override any of the above +# defaults even though they are in the "do not modify" section of this +# Makefile. +# +CFLAGS += $(CFLAGS_EXTRA) +WINDRES_FLAGS += $(WINDRES_FLAGS_EXTRA) + all: $(TARGET) vimrun.exe xxd/xxd.exe install.exe uninstal.exe GvimExt/gvimext.dll vimrun.exe: vimrun.c diff --git a/src/GvimExt/Make_ming.mak b/src/GvimExt/Make_ming.mak index d1d060b..8ce5943 100644 --- a/src/GvimExt/Make_ming.mak +++ b/src/GvimExt/Make_ming.mak @@ -47,6 +47,18 @@ CXX := $(CROSS_COMPILE)g++ WINDRES := $(CROSS_COMPILE)windres WINDRES_CXX = $(CXX) WINDRES_FLAGS = --preprocessor="$(WINDRES_CXX) -E -xc" -DRC_INVOKED + +# Set flags to support either 32-bit or 64-bit build as appropriate. +# +CXXFLAGS := $(CXXFLAGS) -march=$(ARCH) +ifeq ($(ARCH),x86-64) +CXXFLAGS := $(CXXFLAGS) -m64 +WINDRES_FLAGS += --target=pe-x86-64 +else +CXXFLAGS := $(CXXFLAGS) -m32 +WINDRES_FLAGS += --target=pe-i386 +endif + LIBS := -luuid -lgdi32 RES := gvimext.res DEFFILE = gvimext_ming.def diff --git a/src/xxd/Make_ming.mak b/src/xxd/Make_ming.mak index 5147e89..442a9ea 100644 --- a/src/xxd/Make_ming.mak +++ b/src/xxd/Make_ming.mak @@ -15,6 +15,12 @@ endif CC = gcc CFLAGS = -O2 -Wall -DWIN32 $(DEFINES) +ifeq ($(ARCH),x86-64) +CFLAGS += -march=$(ARCH) -m64 +else +CFLAGS += -march=$(ARCH) -m32 +endif + ifneq (sh.exe, $(SHELL)) DEL = rm else -- -- 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
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: Compilation warning: gdk_pixbuf_new_from_inline is deprecated (@ gui_gtk.c line 152)
On Monday, November 30, 2015 at 10:26:09 AM UTC+9, Ken Takata wrote: > Hi, > > 2015/11/30 Mon 8:01:10 UTC+9 Tony Mechelynck wrote: > > When compiling 7.4.944, huge, with GTK2/Gnome2 GUI (i don't know > > exactly at which changeset it appeared): > > > > gcc -c -I. [...] -o objects/gui_gtk.o gui_gtk.c > > gui_gtk.c: In function ‘add_stock_icon’: > > gui_gtk.c:152:5: warning: ‘gdk_pixbuf_new_from_inline’ is deprecated > > (declared at /usr/include/gdk-pixbuf-2.0/gdk-pixbuf/gdk-pixbuf-core.h:314) > > [-Wdeprecated-declarations] > > pixbuf = gdk_pixbuf_new_from_inline(data_length, inline_data, FALSE, > > NULL); > > ^ > > > > I don't know if we can do something about it now; but as everyone > > knows, "deprecated in one release may mean removed in the next > > release" and if and when that happens we'll be in trouble. > > The gdk-pixbuf's manual says: > https://developer.gnome.org/gdk-pixbuf/2.31/gdk-pixbuf-Image-Data-in-Memory.html#gdk-pixbuf-new-from-inline > > > gdk_pixbuf_new_from_inline has been deprecated since version 2.32 and > > should not be used in newly-written code. > > Use GResource instead. > > But I don't know how to use GResource... > > Regards, > Ken Takata You can use gdk_pixbuf_loader instead, I think. https://github.com/mattn/gtktweeter/blob/master/gtktweeter.c#L979-L994 -- -- 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: Compilation warning: gdk_pixbuf_new_from_inline is deprecated (@ gui_gtk.c line 152)
Hi, 2015/11/30 Mon 8:01:10 UTC+9 Tony Mechelynck wrote: > When compiling 7.4.944, huge, with GTK2/Gnome2 GUI (i don't know > exactly at which changeset it appeared): > > gcc -c -I. [...] -o objects/gui_gtk.o gui_gtk.c > gui_gtk.c: In function ‘add_stock_icon’: > gui_gtk.c:152:5: warning: ‘gdk_pixbuf_new_from_inline’ is deprecated > (declared at /usr/include/gdk-pixbuf-2.0/gdk-pixbuf/gdk-pixbuf-core.h:314) > [-Wdeprecated-declarations] > pixbuf = gdk_pixbuf_new_from_inline(data_length, inline_data, FALSE, > NULL); > ^ > > I don't know if we can do something about it now; but as everyone > knows, "deprecated in one release may mean removed in the next > release" and if and when that happens we'll be in trouble. The gdk-pixbuf's manual says: https://developer.gnome.org/gdk-pixbuf/2.31/gdk-pixbuf-Image-Data-in-Memory.html#gdk-pixbuf-new-from-inline > gdk_pixbuf_new_from_inline has been deprecated since version 2.32 and > should not be used in newly-written code. > Use GResource instead. But I don't know how to use GResource... Regards, Ken Takata -- -- 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 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
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 :
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
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.
Compilation warning: gdk_pixbuf_new_from_inline is deprecated (@ gui_gtk.c line 152)
When compiling 7.4.944, huge, with GTK2/Gnome2 GUI (i don't know exactly at which changeset it appeared): gcc -c -I. [...] -o objects/gui_gtk.o gui_gtk.c gui_gtk.c: In function ‘add_stock_icon’: gui_gtk.c:152:5: warning: ‘gdk_pixbuf_new_from_inline’ is deprecated (declared at /usr/include/gdk-pixbuf-2.0/gdk-pixbuf/gdk-pixbuf-core.h:314) [-Wdeprecated-declarations] pixbuf = gdk_pixbuf_new_from_inline(data_length, inline_data, FALSE, NULL); ^ I don't know if we can do something about it now; but as everyone knows, "deprecated in one release may mean removed in the next release" and if and when that happens we'll be in trouble. 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.
Re: Build test "listchars" fails in Windows
On 11/29/2015 3:26 PM, Christian Brabandt wrote: On So, 29 Nov 2015, Bram Moolenaar wrote: Michael Soyka wrote: As of patch 942, the build-test "listchars" fails under Windows when using the mingw compiler. Specifically, the command "diff test.out test_listchars.ok" fails because test.out file is in unix format and test_listchars.ok" is in DOS format. As I see it, there are two ways to fix this: 1. Modify src/testdir/Make_ming.mak to convert test_listchars.ok from DOS to unix format (fixff target in makefile) or So does this fixes it? diff --git a/src/testdir/Make_ming.mak b/src/testdir/Make_ming.mak --- a/src/testdir/Make_ming.mak +++ b/src/testdir/Make_ming.mak @@ -120,7 +120,7 @@ win32: fixff $(SCRIPTS16) $(SCRIPTS) $(S fixff: -$(VIMPROG) -u dos.vim --noplugin "+argdo set ff=dos|upd" +q *.in *.ok -$(VIMPROG) -u dos.vim --noplugin "+argdo set ff=unix|upd" +q \ - dotest.in test60.ok test71.ok test74.ok + dotest.in test60.ok test71.ok test74.ok test_listchars.ok clean: -$(DEL) *.out 2. change the "set ff" statement in test_listchars.in" to specify "dos" instead of unix". Of these, changing the makefile will affect only mingw build environments and so I prefer number one. This test changed in patch 7.4.733. Christian, setting 'fileformat' to unix has problems, is there another solution for the problem this patch was fixing? Perhaps fileformat can be reset before writing to test.out? Yes that was done, because of a failure in the Windows test: https://ci.appveyor.com/project/k-takata/vim-ci/build/288#L1693 That patch fixed the error for the other windows built, but apparently broke it for mingw. So I would go with the patch above, if it can be confirmed to work correctly. Best, Christian I tried it, it solves the problem. 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.
Re: Patch 7.4.944
2015-11-30 0:01 GMT+03:00 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 :
> > > >
> > > > >
> > > > > 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: Support for new way of testing
Christian Brabandt wrote:
> On So, 29 Nov 2015, Bram Moolenaar wrote:
>
> >
> > Testing Vim functionality has always been difficult. The tests in
> > src/testdir are hard to write and even harder to read back.
> >
> > I have just sent out patch 7.4.944 which should make testing easier.
> > This is what simple test looks like:
> >
> > func Test_assertFalse()
> > call assertFalse(0)
> > endfunc
> >
> > func Test_assertTrue()
> > call assertTrue(1)
> > call assertTrue(123)
> > endfunc
> >
> > func Test_assertEqual()
> > let s = 'foo'
> > call assertEqual('foo', s)
> > let n = 4
> > call assertEqual(4, n)
> > let l = [1, 2, 3]
> > call assertEqual([1, 2, 3], l)
> > endfunc
> >
> > The asserts are done where the value is available. No need to dig
> > through an .ok file or diff the .ok file with an .out file and then
> > guess where in the test something went wrong.
> >
> > The test script finds all the Test_ functions and executes them,
> > collecting any error messages from the asserts.
> >
> > An important limitation is that this only works with the +eval feature.
> > Testing a small or tiny Vim build still requires the old kind of
> > testing.
> >
> > What do you think?
> >
> > Obviously we can add more assert functions and improve their error
> > messages.
>
> I appreciate it to make testing easier. Writing and debugging the old
> tests are a huge PITA (sorry).
>
> However, as of now, I don't know how this is supposed to be better. Most
> of the tests I have written in the last time, were trying to test some
> visual feature, so I don't know how the assert functions are going to
> help with this.
>
> I have to see how this works out, before I can make a final assessment.
You will still have to manipulate text and yank or have some other way
to grab the result. But instead of putting the resulting text at the end
of the buffer, and later writing it to test.out, you can use
assertEqual() or assert_equal(). Thus there is no .ok file to update
and when a test fails you can see where it happens, intead of looking at
the diff and guessing where the change came from.
Another hint: put :finish before example text that you want to mess
with.
func Test_that()
...
endfunc
finish
Here: test some stuff on this text.
--
hundred-and-one symptoms of being an internet addict:
161. You get up before the sun rises to check your e-mail, and you
find yourself in the very same chair long after the sun has set.
/// 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
Christian Brabandt wrote:
> On So, 29 Nov 2015, Bram Moolenaar wrote:
>
> >
> > Nikolay Pavlov wrote:
> >
> > > 2015-11-29 19:36 GMT+03:00 Bram Moolenaar :
> > >
> > > >
> > > > 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
Hi Bram!
On So, 29 Nov 2015, Bram Moolenaar wrote:
>
> Nikolay Pavlov wrote:
>
> > 2015-11-29 19:36 GMT+03:00 Bram Moolenaar :
> >
> > >
> > > 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.
Re: Support for new way of testing
Hi Bram!
On So, 29 Nov 2015, Bram Moolenaar wrote:
>
> Testing Vim functionality has always been difficult. The tests in
> src/testdir are hard to write and even harder to read back.
>
> I have just sent out patch 7.4.944 which should make testing easier.
> This is what simple test looks like:
>
> func Test_assertFalse()
> call assertFalse(0)
> endfunc
>
> func Test_assertTrue()
> call assertTrue(1)
> call assertTrue(123)
> endfunc
>
> func Test_assertEqual()
> let s = 'foo'
> call assertEqual('foo', s)
> let n = 4
> call assertEqual(4, n)
> let l = [1, 2, 3]
> call assertEqual([1, 2, 3], l)
> endfunc
>
> The asserts are done where the value is available. No need to dig
> through an .ok file or diff the .ok file with an .out file and then
> guess where in the test something went wrong.
>
> The test script finds all the Test_ functions and executes them,
> collecting any error messages from the asserts.
>
> An important limitation is that this only works with the +eval feature.
> Testing a small or tiny Vim build still requires the old kind of
> testing.
>
> What do you think?
>
> Obviously we can add more assert functions and improve their error
> messages.
I appreciate it to make testing easier. Writing and debugging the old
tests are a huge PITA (sorry).
However, as of now, I don't know how this is supposed to be better. Most
of the tests I have written in the last time, were trying to test some
visual feature, so I don't know how the assert functions are going to
help with this.
I have to see how this works out, before I can make a final assessment.
Best,
Christian
--
Ideen sind ja nur das einzig wahrhaft Bleibende im Leben.
-- Wilhelm von Humboldt
--
--
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: Build test "listchars" fails in Windows
On So, 29 Nov 2015, Bram Moolenaar wrote: > Michael Soyka wrote: > > > As of patch 942, the build-test "listchars" fails under Windows when > > using the mingw compiler. Specifically, the command "diff test.out > > test_listchars.ok" fails because test.out file is in unix format and > > test_listchars.ok" is in DOS format. > > > > As I see it, there are two ways to fix this: > > > > 1. Modify src/testdir/Make_ming.mak to convert test_listchars.ok from > > DOS to unix format (fixff target in makefile) or So does this fixes it? diff --git a/src/testdir/Make_ming.mak b/src/testdir/Make_ming.mak --- a/src/testdir/Make_ming.mak +++ b/src/testdir/Make_ming.mak @@ -120,7 +120,7 @@ win32: fixff $(SCRIPTS16) $(SCRIPTS) $(S fixff: -$(VIMPROG) -u dos.vim --noplugin "+argdo set ff=dos|upd" +q *.in *.ok -$(VIMPROG) -u dos.vim --noplugin "+argdo set ff=unix|upd" +q \ - dotest.in test60.ok test71.ok test74.ok + dotest.in test60.ok test71.ok test74.ok test_listchars.ok clean: -$(DEL) *.out > > 2. change the "set ff" statement in test_listchars.in" to specify "dos" > > instead of unix". > > > > Of these, changing the makefile will affect only mingw build > > environments and so I prefer number one. > > This test changed in patch 7.4.733. Christian, setting 'fileformat' to > unix has problems, is there another solution for the problem this patch > was fixing? Perhaps fileformat can be reset before writing to test.out? Yes that was done, because of a failure in the Windows test: https://ci.appveyor.com/project/k-takata/vim-ci/build/288#L1693 That patch fixed the error for the other windows built, but apparently broke it for mingw. So I would go with the patch above, if it can be confirmed to work correctly. Best, Christian -- Weg mit der Schwerkraft! Es lebe der Leichtsinn! -- -- 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
Nikolay Pavlov wrote:
> 2015-11-29 19:36 GMT+03:00 Bram Moolenaar :
>
> >
> > 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: Build test "listchars" fails in Windows
Michael Soyka wrote: > As of patch 942, the build-test "listchars" fails under Windows when > using the mingw compiler. Specifically, the command "diff test.out > test_listchars.ok" fails because test.out file is in unix format and > test_listchars.ok" is in DOS format. > > As I see it, there are two ways to fix this: > > 1. Modify src/testdir/Make_ming.mak to convert test_listchars.ok from > DOS to unix format (fixff target in makefile) or > 2. change the "set ff" statement in test_listchars.in" to specify "dos" > instead of unix". > > Of these, changing the makefile will affect only mingw build > environments and so I prefer number one. This test changed in patch 7.4.733. Christian, setting 'fileformat' to unix has problems, is there another solution for the problem this patch was fixing? Perhaps fileformat can be reset before writing to test.out? -- hundred-and-one symptoms of being an internet addict: 151. You find yourself engaged to someone you've never actually met, except through e-mail. /// 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: Windows 64bit build in 32bit command prompt
On 29/11/2015 17:04, Mike Williams wrote:
Hi Ken (and Taro),
On 29/11/2015 15:13, Ken Takata wrote:
Hi Mike,
2015/11/29 Sun 20:06:42 UTC+9 Mike Williams wrote:
Hi,
Just done my first build of VIM on an old Windows 7 32bit machine
upgraded to Windows 10 using VC. The link stage was failing due to
mixed machine targets being used in the make file - 32 and 64 bit! I
tracked this down to some fun with the PROCESSOR_ARCHITECTURE in a 32bit
prompt on a 64bit machine, see -
http://blogs.msdn.com/b/david.wang/archive/2006/03/26/howto-detect-process-bitness.aspx
I guess no one has ever tried to do this until now. It seems reasonable
to default to the host processor architecture and not the architecture
of the process being used to run the build. The following diff solves
the build issue for me:
diff --git a/src/Make_mvc.mak b/src/Make_mvc.mak
--- a/src/Make_mvc.mak
+++ b/src/Make_mvc.mak
@@ -217,7 +217,11 @@ ASSEMBLY_ARCHITECTURE=$(CPU)
ASSEMBLY_ARCHITECTURE = x86
! endif
! else
+! ifdef PROCESSOR_ARCHITEW6432
+CPU = $(PROCESSOR_ARCHITEW6432)
+! else
CPU = $(PROCESSOR_ARCHITECTURE)
+! endif
ASSEMBLY_ARCHITECTURE = $(PROCESSOR_ARCHITECTURE)
! if ("$(CPU)" == "x86") || ("$(CPU)" == "X86")
CPU = i386
HTH - TTFN
Mike
--
Accept that some days you're the pigeon, and some days you're the statue.
I currently build 32-bit and 64-bit Vim on 64-bit Win10 without changing the
Makefile. I use 32-bit compiler for 32-bit target and 64-bit compiler for
64-bit target, but you seem to use 32-bit cross compiler targeting 64-bit.
The current makefile assume that the bitness of nmake.exe is the same as the
target, and it doesn't support cross compiling.
We need another approach to support cross compiling.
I agree that my patch is the wrong solution. As Taro points out using
the Platform environment var should take into account the cross
compilation target. However it does not seem to be set for every
architecture passed to vcvarsall.bat. I'll try a few things and see
where they leads.
My bad, too many command prompts with too many environments - Taro is on
the right track.
Mike
--
Accept that some days you're the pigeon, and some days you're the statue.
--
--
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: Windows 64bit build in 32bit command prompt
On 29/11/2015 16:57, Taro MURAOKA wrote: I wrote: We may be able to use "Platform" environment variable for this purpose. It get one of values: "x64", "X64", "X86" or "ARM" as cross compiling target, in all of VS10, 11, 12, 14 environments. Hi Mike and Ken. I have wrote a patch to use PLATFORM for this purpose. Please try https://gist.github.com/koron/c51efe584d0b4e5686a4 There is still a problem when building 32bit when PROCESSOR_ARCHITECTURE is amd64. I think that if PLATFORM is not defined it should default CPU to i386 and not use PROCESSOR_ARCHITECTURE. Mike -- Accept that some days you're the pigeon, and some days you're the statue. -- -- 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: Windows 64bit build in 32bit command prompt
Hi Ken (and Taro),
On 29/11/2015 15:13, Ken Takata wrote:
Hi Mike,
2015/11/29 Sun 20:06:42 UTC+9 Mike Williams wrote:
Hi,
Just done my first build of VIM on an old Windows 7 32bit machine
upgraded to Windows 10 using VC. The link stage was failing due to
mixed machine targets being used in the make file - 32 and 64 bit! I
tracked this down to some fun with the PROCESSOR_ARCHITECTURE in a 32bit
prompt on a 64bit machine, see -
http://blogs.msdn.com/b/david.wang/archive/2006/03/26/howto-detect-process-bitness.aspx
I guess no one has ever tried to do this until now. It seems reasonable
to default to the host processor architecture and not the architecture
of the process being used to run the build. The following diff solves
the build issue for me:
diff --git a/src/Make_mvc.mak b/src/Make_mvc.mak
--- a/src/Make_mvc.mak
+++ b/src/Make_mvc.mak
@@ -217,7 +217,11 @@ ASSEMBLY_ARCHITECTURE=$(CPU)
ASSEMBLY_ARCHITECTURE = x86
! endif
! else
+! ifdef PROCESSOR_ARCHITEW6432
+CPU = $(PROCESSOR_ARCHITEW6432)
+! else
CPU = $(PROCESSOR_ARCHITECTURE)
+! endif
ASSEMBLY_ARCHITECTURE = $(PROCESSOR_ARCHITECTURE)
! if ("$(CPU)" == "x86") || ("$(CPU)" == "X86")
CPU = i386
HTH - TTFN
Mike
--
Accept that some days you're the pigeon, and some days you're the statue.
I currently build 32-bit and 64-bit Vim on 64-bit Win10 without changing the
Makefile. I use 32-bit compiler for 32-bit target and 64-bit compiler for
64-bit target, but you seem to use 32-bit cross compiler targeting 64-bit.
The current makefile assume that the bitness of nmake.exe is the same as the
target, and it doesn't support cross compiling.
We need another approach to support cross compiling.
I agree that my patch is the wrong solution. As Taro points out using
the Platform environment var should take into account the cross
compilation target. However it does not seem to be set for every
architecture passed to vcvarsall.bat. I'll try a few things and see
where they leads.
TTFN
Mike
--
Accept that some days you're the pigeon, and some days you're the statue.
--
--
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: Windows 64bit build in 32bit command prompt
I wrote: > We may be able to use "Platform" environment variable for this purpose. > It get one of values: "x64", "X64", "X86" or "ARM" as cross compiling target, > in all of VS10, 11, 12, 14 environments. Hi Mike and Ken. I have wrote a patch to use PLATFORM for this purpose. Please try https://gist.github.com/koron/c51efe584d0b4e5686a4 Best. -- -- 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: Support for new way of testing
2015-11-29 19:53 GMT+03:00 Nikolay Pavlov :
>
>
> 2015-11-29 19:46 GMT+03:00 Bram Moolenaar :
>
>>
>> Testing Vim functionality has always been difficult. The tests in
>> src/testdir are hard to write and even harder to read back.
>>
>> I have just sent out patch 7.4.944 which should make testing easier.
>> This is what simple test looks like:
>>
>> func Test_assertFalse()
>> call assertFalse(0)
>> endfunc
>>
>> func Test_assertTrue()
>> call assertTrue(1)
>> call assertTrue(123)
>> endfunc
>>
>> func Test_assertEqual()
>> let s = 'foo'
>> call assertEqual('foo', s)
>> let n = 4
>> call assertEqual(4, n)
>> let l = [1, 2, 3]
>> call assertEqual([1, 2, 3], l)
>> endfunc
>>
>> The asserts are done where the value is available. No need to dig
>> through an .ok file or diff the .ok file with an .out file and then
>> guess where in the test something went wrong.
>>
>> The test script finds all the Test_ functions and executes them,
>> collecting any error messages from the asserts.
>>
>> An important limitation is that this only works with the +eval feature.
>> Testing a small or tiny Vim build still requires the old kind of
>> testing.
>>
>> What do you think?
>>
>
> As I commented on the patch I think that functions need to have different
> name. There was never a function that had upper case letter, using current
> conventions I would expect `asserttrue`, `assertfalse` and `assertequal`.
> Or `assert_true`, `assert_false` and `assert_equal`: though this is
> uncommon, there are examples (`remote_*` and `complete_*`) of function
> families using this convention.
>
Underscore variants are more readable.
>
>
>
>>
>> Obviously we can add more assert functions and improve their error
>> messages.
>>
>> --
>> hundred-and-one symptoms of being an internet addict:
>> 150. You find yourself counting emoticons to get to sleep.
>>
>> /// 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: Support for new way of testing
2015-11-29 19:46 GMT+03:00 Bram Moolenaar :
>
> Testing Vim functionality has always been difficult. The tests in
> src/testdir are hard to write and even harder to read back.
>
> I have just sent out patch 7.4.944 which should make testing easier.
> This is what simple test looks like:
>
> func Test_assertFalse()
> call assertFalse(0)
> endfunc
>
> func Test_assertTrue()
> call assertTrue(1)
> call assertTrue(123)
> endfunc
>
> func Test_assertEqual()
> let s = 'foo'
> call assertEqual('foo', s)
> let n = 4
> call assertEqual(4, n)
> let l = [1, 2, 3]
> call assertEqual([1, 2, 3], l)
> endfunc
>
> The asserts are done where the value is available. No need to dig
> through an .ok file or diff the .ok file with an .out file and then
> guess where in the test something went wrong.
>
> The test script finds all the Test_ functions and executes them,
> collecting any error messages from the asserts.
>
> An important limitation is that this only works with the +eval feature.
> Testing a small or tiny Vim build still requires the old kind of
> testing.
>
> What do you think?
>
As I commented on the patch I think that functions need to have different
name. There was never a function that had upper case letter, using current
conventions I would expect `asserttrue`, `assertfalse` and `assertequal`.
Or `assert_true`, `assert_false` and `assert_equal`: though this is
uncommon, there are examples (`remote_*` and `complete_*`) of function
families using this convention.
>
> Obviously we can add more assert functions and improve their error
> messages.
>
> --
> hundred-and-one symptoms of being an internet addict:
> 150. You find yourself counting emoticons to get to sleep.
>
> /// 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 19:36 GMT+03:00 Bram Moolenaar :
>
> 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(&ARGLIST[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 = &vimvars[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(&argvars[0], &argvars[1], FALSE, FALSE))
> + {
> + prepareForAssertError(&ga);
> + ga_concat(&ga, (char_u *)": Expected ");
> + ga_concat(&ga, tv2string(&argvars[0], &tofree, numbuf, 0));
> + vim_free(tofree);
> + ga_concat(&ga, (char_u *)" but got ");
> + ga_concat(&ga, tv2string(&argvars[1], &tofree, numbuf, 0));
> + vim_free(tofree);
> + assertError(&ga);
> + ga_clear(&ga);
> + }
> + }
> +
> + 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(&argvars[0], &error) == 0) == isTrue
> + || error)
> + {
> + prepareForAssertError(&ga);
> + ga_concat(&ga, (char_u *)": Expected ");
> + if (isTrue)
> + ga_concat(&ga, (char_u *)"True ");
> + else
> + ga_concat(&ga, (char_u *)"False ");
> + ga_concat(&ga, (char_u *)"but got ");
> + ga_concat(&ga, tv2string(&argvars[0], &tofree, numbuf, 0));
> + vim_free(tofree);
> + assertError(&ga);
> + ga_clear(&ga);
> + }
> + }
> +
> + /*
> + * "assertFalse(actual[, msg])" function
> + */
> + static void
> + f_assertFalse(argvars, rettv)
> + typval_T *argvars;
> + typval_T *rettv UNUSED;
> +
Support for new way of testing
Testing Vim functionality has always been difficult. The tests in
src/testdir are hard to write and even harder to read back.
I have just sent out patch 7.4.944 which should make testing easier.
This is what simple test looks like:
func Test_assertFalse()
call assertFalse(0)
endfunc
func Test_assertTrue()
call assertTrue(1)
call assertTrue(123)
endfunc
func Test_assertEqual()
let s = 'foo'
call assertEqual('foo', s)
let n = 4
call assertEqual(4, n)
let l = [1, 2, 3]
call assertEqual([1, 2, 3], l)
endfunc
The asserts are done where the value is available. No need to dig
through an .ok file or diff the .ok file with an .out file and then
guess where in the test something went wrong.
The test script finds all the Test_ functions and executes them,
collecting any error messages from the asserts.
An important limitation is that this only works with the +eval feature.
Testing a small or tiny Vim build still requires the old kind of
testing.
What do you think?
Obviously we can add more assert functions and improve their error
messages.
--
hundred-and-one symptoms of being an internet addict:
150. You find yourself counting emoticons to get to sleep.
/// 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 7.4.944
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(&ARGLIST[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 = &vimvars[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(&argvars[0], &argvars[1], FALSE, FALSE))
+ {
+ prepareForAssertError(&ga);
+ ga_concat(&ga, (char_u *)": Expected ");
+ ga_concat(&ga, tv2string(&argvars[0], &tofree, numbuf, 0));
+ vim_free(tofree);
+ ga_concat(&ga, (char_u *)" but got ");
+ ga_concat(&ga, tv2string(&argvars[1], &tofree, numbuf, 0));
+ vim_free(tofree);
+ assertError(&ga);
+ ga_clear(&ga);
+ }
+ }
+
+ 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(&argvars[0], &error) == 0) == isTrue
+ || error)
+ {
+ prepareForAssertError(&ga);
+ ga_concat(&ga, (char_u *)": Expected ");
+ if (isTrue)
+ ga_concat(&ga, (char_u *)"True ");
+ else
+ ga_concat(&ga, (char_u *)"False ");
+ ga_concat(&ga, (char_u *)"but got ");
+ ga_concat(&ga, tv2string(&argvars[0], &tofree, numbuf, 0));
+ vim_free(tofree);
+ assertError(&ga);
+ ga_clear(&ga);
+ }
+ }
+
+ /*
+ * "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/src/vim.h2015-07-17 17:38:00.567399623 +0200
--- src/vim.h 2015-11-29 14:53:31.936054759 +0100
***
Re: Windows 64bit build in 32bit command prompt
I wrote: > So we should try/find another way. We may be able to use "Platform" environment variable for this purpose. It get one of values: "x64", "X64", "X86" or "ARM" as cross compiling target, in all of VS10, 11, 12, 14 environments. You can see these variables at VC\bin\**\vcvars*.bat in each VS. -- -- 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: Windows 64bit build in 32bit command prompt
Hi Mike,
2015/11/29 Sun 20:06:42 UTC+9 Mike Williams wrote:
> Hi,
>
> Just done my first build of VIM on an old Windows 7 32bit machine
> upgraded to Windows 10 using VC. The link stage was failing due to
> mixed machine targets being used in the make file - 32 and 64 bit! I
> tracked this down to some fun with the PROCESSOR_ARCHITECTURE in a 32bit
> prompt on a 64bit machine, see -
>
> http://blogs.msdn.com/b/david.wang/archive/2006/03/26/howto-detect-process-bitness.aspx
>
> I guess no one has ever tried to do this until now. It seems reasonable
> to default to the host processor architecture and not the architecture
> of the process being used to run the build. The following diff solves
> the build issue for me:
>
> diff --git a/src/Make_mvc.mak b/src/Make_mvc.mak
> --- a/src/Make_mvc.mak
> +++ b/src/Make_mvc.mak
> @@ -217,7 +217,11 @@ ASSEMBLY_ARCHITECTURE=$(CPU)
> ASSEMBLY_ARCHITECTURE = x86
> ! endif
> ! else
> +! ifdef PROCESSOR_ARCHITEW6432
> +CPU = $(PROCESSOR_ARCHITEW6432)
> +! else
> CPU = $(PROCESSOR_ARCHITECTURE)
> +! endif
> ASSEMBLY_ARCHITECTURE = $(PROCESSOR_ARCHITECTURE)
> ! if ("$(CPU)" == "x86") || ("$(CPU)" == "X86")
> CPU = i386
>
>
> HTH - TTFN
>
> Mike
> --
> Accept that some days you're the pigeon, and some days you're the statue.
I currently build 32-bit and 64-bit Vim on 64-bit Win10 without changing the
Makefile. I use 32-bit compiler for 32-bit target and 64-bit compiler for
64-bit target, but you seem to use 32-bit cross compiler targeting 64-bit.
The current makefile assume that the bitness of nmake.exe is the same as the
target, and it doesn't support cross compiling.
We need another approach to support cross compiling.
Regards,
Ken Takata
--
--
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: Windows 64bit build in 32bit command prompt
Mike Williams wrote > Hi, > > Just done my first build of VIM on an old Windows 7 32bit machine > upgraded to Windows 10 using VC. The link stage was failing due to > mixed machine targets being used in the make file - 32 and 64 bit! I > tracked this down to some fun with the PROCESSOR_ARCHITECTURE in a 32bit > prompt on a 64bit machine, see - Sorry but I disapprove this. Because PROCESSOR_ARCHITEW6432 is set "AMD64" on 64bit OS when using 32bit compiler. Therefore, we never be able to build 32bit binary on 64bit OS, if this patch would be applied. So we should try/find another way. -- -- 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: if_python build on mingw32/mingw64(msys2)
okay, updated. https://gist.githubusercontent.com/mattn/4f17789cdc0ec1ad17e9/raw/20391843cdb1beb784fcb9c235bb35d9d6967474/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.
Windows 64bit build in 32bit command prompt
Hi,
Just done my first build of VIM on an old Windows 7 32bit machine
upgraded to Windows 10 using VC. The link stage was failing due to
mixed machine targets being used in the make file - 32 and 64 bit! I
tracked this down to some fun with the PROCESSOR_ARCHITECTURE in a 32bit
prompt on a 64bit machine, see -
http://blogs.msdn.com/b/david.wang/archive/2006/03/26/howto-detect-process-bitness.aspx
I guess no one has ever tried to do this until now. It seems reasonable
to default to the host processor architecture and not the architecture
of the process being used to run the build. The following diff solves
the build issue for me:
diff --git a/src/Make_mvc.mak b/src/Make_mvc.mak
--- a/src/Make_mvc.mak
+++ b/src/Make_mvc.mak
@@ -217,7 +217,11 @@ ASSEMBLY_ARCHITECTURE=$(CPU)
ASSEMBLY_ARCHITECTURE = x86
! endif
! else
+! ifdef PROCESSOR_ARCHITEW6432
+CPU = $(PROCESSOR_ARCHITEW6432)
+! else
CPU = $(PROCESSOR_ARCHITECTURE)
+! endif
ASSEMBLY_ARCHITECTURE = $(PROCESSOR_ARCHITECTURE)
! if ("$(CPU)" == "x86") || ("$(CPU)" == "X86")
CPU = i386
HTH - TTFN
Mike
--
Accept that some days you're the pigeon, and some days you're the statue.
--
--
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.
