New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[WIP/RFC] Add unit tests for buffer.c and fileio.c #904

Merged
merged 3 commits into from Jul 22, 2014

Conversation

Projects
None yet
8 participants
@war1025
Copy link
Contributor

war1025 commented Jun 30, 2014

No description provided.

@justinmk justinmk added the tests label Jun 30, 2014

@justinmk

This comment has been minimized.

Copy link
Member

justinmk commented Jun 30, 2014

Thanks for getting this started! It will be valuable to get coverage for these core functions.

buffer.moon file segfaults. I do not understand why

Could be that it is accessing an uninitialized global. Looks like p_magic is one. Maybe others. That's why unit-testing these components is difficult at the moment.

Not sure if you are aware, but tests may also be written in plain lua instead of moonscript. In some cases it has helped give better error messages.

@war1025

This comment has been minimized.

Copy link
Contributor

war1025 commented Jul 1, 2014

@justinmk How do I initialize the globals?

@aktau

This comment has been minimized.

Copy link
Member

aktau commented Jul 1, 2014

@war1025 I believe calling some vim initialization routines should do the trick (the real trick is finding the right ones, of course), just like in the main executable. @ZyX-I has more experience with this, though.

@jdavis

This comment has been minimized.

Copy link
Contributor

jdavis commented Jul 2, 2014

Thanks for getting this started! It will be valuable to get coverage for these core functions.

Yeah, I agree. Nice job Wayne 😄

@war1025

This comment has been minimized.

Copy link
Contributor

war1025 commented Jul 6, 2014

If anyone knows how to get the buffer.c tests not to segfault, or could at least point me in the right direction, I would be more than happy to get these tests cleaned up and fleshed out. As it is, I don't understand enough about the build / test system to know where to start, and I don't have the motivation to dig blindly until I get lucky.

@aktau

This comment has been minimized.

Copy link
Member

aktau commented Jul 6, 2014

I think at this moment either @tarruda or @ZyX-I have the best idea of which functions we should call to initialize basic buffer support. If they have time I hope they chime in :).

@aktau

This comment has been minimized.

Copy link
Member

aktau commented Jul 6, 2014

The first problem you're having is basically because buffer.h doesn't include a definition for exarg_T. All these problems would become more apparent if we could get include-what-you-use working, but alas. Simply including the file where exarg_T is defined might not immediately work, as it is the dreaded "include it twice in a specific way" ex_cmds_defs.h... thinking.

@aktau

This comment has been minimized.

Copy link
Member

aktau commented Jul 12, 2014

buflist_new(file: test_file_path.txt, flags: 2)
Process 24851 stopped
* thread #1: tid = 0x25bcd, 0x00000000020f1697 libnvim-test.so`map_uint64_t_ptr_t_put(map=0x0000000000000000, key=1, value=0x0000000002804a00) + 39 at map.c:92, queue = 'com.apple.main-thread', stop reason = EXC_BAD_ACCESS (code=1, address=0x0)
    frame #0: 0x00000000020f1697 libnvim-test.so`map_uint64_t_ptr_t_put(map=0x0000000000000000, key=1, value=0x0000000002804a00) + 39 at map.c:92
   89
   90   MAP_IMPL(cstr_t, ptr_t, DEFAULT_INITIALIZER)
   91   MAP_IMPL(ptr_t, ptr_t, DEFAULT_INITIALIZER)
-> 92   MAP_IMPL(uint64_t, ptr_t, DEFAULT_INITIALIZER)

Well... something is not being properly initialized (the -- probably global -- map), that's for sure. Any ideas @tarruda?

My commandline for debugging:

$ lldb .deps/usr/bin/luajit -- .deps/usr/bin/busted_bootstrap --lpath="./build/?.lua" --pattern=.moon test

EDIT: It's most likely the handle_init() function, that's not being called.

EDIT 2: better call mch_early_init()...

@aktau

This comment has been minimized.

Copy link
Member

aktau commented Jul 12, 2014

Yes, I got it running (buffer.moon). Great success!

●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●
145 successes / 0 failures / 0 pending : 0.55118 seconds
@aktau

This comment has been minimized.

Copy link
Member

aktau commented Jul 12, 2014

@war1025 some small changes to your tests are advisable (and even needed) to make them run, after PR #941 is merged:

buffer.moon (you need to call the new vim_init function):

{:cimport, :internalize, :eq, :neq, :ffi, :lib, :cstr, :to_cstr, :vim_init} = require 'test.unit.helpers'

-- initialize some global variables, buflist_new() segfaults without it,
-- among others
vim_init!

buffer = cimport "./src/nvim/buffer.h"

fileio.moon (with PR #941, you can now just import fileio.h regularly):

fileio = cimport "./src/nvim/fileio.h"

Hinidu referenced this pull request in aktau/neovim Jul 13, 2014

test/helpers: add 'vim_init' helper
Initializes some global variables. Will be useful for the buffer tests in PR

aktau added a commit to aktau/neovim that referenced this pull request Jul 14, 2014

test/helpers: add 'vim_init' helper
- Initializes some global variables.
- Necessary for the buffer tests in PR neovim#904.

aktau added a commit to aktau/neovim that referenced this pull request Jul 16, 2014

test/helpers: add 'vim_init' helper
- Initializes some global variables.
- Necessary for the buffer tests in PR neovim#904.
@aktau

This comment has been minimized.

Copy link
Member

aktau commented Jul 16, 2014

@war1025 the necessary changes have been merged into mainline. Can you rebase and change the test files as I've indicated above please?

@war1025

This comment has been minimized.

Copy link
Contributor

war1025 commented Jul 19, 2014

Will do. Was on vacation.

@war1025

This comment has been minimized.

Copy link
Contributor

war1025 commented Jul 19, 2014

@aktau Thank you for your work cleaning things up and figuring out how to make them work. I have made the changes you suggested and will try to find time to flesh out the tests in the next few days.

if(p_cpo != NULL) {
reg_cpo_lit = vim_strchr(p_cpo, CPO_LITERAL) != NULL;
reg_cpo_bsl = vim_strchr(p_cpo, CPO_BACKSL) != NULL;
}

This comment has been minimized.

@war1025

war1025 Jul 19, 2014

Contributor

I ran into an issue because p_cpo wasn't set during my tests. I saw somewhere else checked p_cpo != NULL so I added that here. If that is inappropriate, I need to figure out how to initialize p_cpo properly.

@war1025

This comment has been minimized.

Copy link
Contributor

war1025 commented Jul 19, 2014

Is there a style guide?

eq([[^foo^bar$]], file_pat_to_reg_pat('foo^bar'))
end)

it('Does not escape $', function()

This comment has been minimized.

@war1025

war1025 Jul 19, 2014

Contributor

This seems like a bug to me, but the purpose of this pull is to document current behavior.

This comment has been minimized.

@justinmk

justinmk Jul 20, 2014

Member

can you create a ticket for this? Need to check if this is a regression or ask vim_dev mailing list.

@war1025

This comment has been minimized.

Copy link
Contributor

war1025 commented Jul 19, 2014

@aktau Also that lldb command in your comment is super useful. Someone should add that to the wiki or README or something.

@Hinidu

This comment has been minimized.

Copy link
Contributor

Hinidu commented Jul 19, 2014

@aktau

This comment has been minimized.

Copy link
Member

aktau commented Jul 19, 2014

I ran into an issue because p_cpo wasn't set during my tests. I saw somewhere else checked p_cpo != NULL so I added that here. If that is inappropriate, I need to figure out how to initialize p_cpo properly.

Since this isn't a problem during normal neovim runs, we probably shouldn't change the C code for that, but (try to) intialize it proporly from the Lua side.

I believe the ffi is capable of assigning global variables. Though it would be even better to find the corresponding init function and just call it from Lua.

@aktau Also that lldb command in your comment is super useful. Someone should add that to the wiki or README or something.

I actually found it in @justinmk's notes :).

@@ -1483,7 +1483,7 @@ static void init_startuptime(mparm_T *paramp)
* Allocate space for the generic buffers (needed for set_init_1() and
* EMSG2()).
*/
static void allocate_generic_buffers(void)
void allocate_generic_buffers(void)

This comment has been minimized.

@war1025

war1025 Jul 19, 2014

Contributor

I couldn't figure out any way to initialize NameBuff besides exposing this function. Please let me know if there is a better way

This comment has been minimized.

@aktau

aktau Jul 19, 2014

Member

Is there actually a good reason why NameBuff isn't statically allocated like IOBuff and msg_buf? Their definitions:

EXTERN char_u   IObuff[IOSIZE];         /* sprintf's are done in this buffer,
                                           size is IOSIZE */
EXTERN char_u   *NameBuff;              /* file names are expanded in this
                                         * buffer, size is MAXPATHL */
EXTERN char_u msg_buf[MSG_BUF_LEN];     /* small buffer for messages */

@justinmk @tarruda @philix @ZyX-I Any of you guys know what's going on in (neo)vim's belly?

This comment has been minimized.

@aktau

aktau Jul 19, 2014

Member

...suprisingly, in vanilla vim IObuff is also dynamically allocated (but not msg_buf). Who changed it? The plot thickens...

EDIT: Git blame to the rescue:

tree c084cde4dbad56ce29ab07a3ffd247aea86cfbf9
parent 08059114349d689d2a45bbeb983fe78217ba5f1c
author Thiago de Arruda <tpadilha84@gmail.com> Tue Apr 8 07:01:44 2014 -0300
committer Thiago de Arruda <tpadilha84@gmail.com> Tue Apr 8 13:49:45 2014 -0300

Fix/add more files with to clint-files.txt

Not that I'm blaming you @tarruda, I support this change, and I think that we should try it for NameBuff too. But something in my mind wonders why it wasn't done like this in the first place.

This comment has been minimized.

@war1025

war1025 Jul 20, 2014

Contributor

I'm guessing NameBuff was not converted along with the others because it caused tests to fail.
I have updated the code so that it passes the tests. If there is a better way to fix things please let me know.

#define GETF_SETMARK 0x01 /* set pcmark before jumping */
#define GETF_ALT 0x02 /* jumping to alternate file (not buf num) */
#define GETF_SWITCH 0x04 /* respect 'switchbuf' settings when jumping */
static const int GETF_SETMARK = 0x01; /* set pcmark before jumping */

This comment has been minimized.

@war1025

war1025 Jul 19, 2014

Contributor

I switched these away from #define so they can be referenced in tests. Is that kosher?

This comment has been minimized.

@justinmk

justinmk Jul 20, 2014

Member

There's a good discussion here, with some conflicting opinions: http://stackoverflow.com/a/1674459/152142 . But see also c faq.

The way we are currently accessing #define values is to provide them to the lua preprocessor like this: https://github.com/neovim/neovim/blob/master/test/includes/pre/sys/fcntl.h

This comment has been minimized.

@justinmk

justinmk Jul 20, 2014

Member

Just to be clear, I think we should stick to #defines. Use the preprocessor trick mentioned above to make these available to the tests.

This comment has been minimized.

@war1025

war1025 Jul 22, 2014

Contributor

Done Switched to enums since the pre-processor stuff got messy

@@ -5156,7 +5156,8 @@ void fix_help_buffer(void)
/* Find all "doc/ *.txt" files in this directory. */
add_pathsep(NameBuff);
STRCAT(NameBuff, "doc/*.??[tx]");
if (gen_expand_wildcards(1, &NameBuff, &fcount,
char_u *buff_list[1] = {(char_u*) NameBuff};
if (gen_expand_wildcards(1, buff_list, &fcount,

This comment has been minimized.

@war1025

war1025 Jul 20, 2014

Contributor

With static allocation of NameBuff, taking the address &NameBuff seems to make things upset. Work around by manually creating an array containing NameBuff. The cast avoids a compiler warning.

This comment has been minimized.

@aktau

aktau Jul 20, 2014

Member

Actually, just casting to (char_u **) works fine.

gen_expand_wildcards(1, (char_u **) &NameBuff, &fcount, ...);

In my opinion that's a bit cleaner.

This comment has been minimized.

@aktau

aktau Jul 20, 2014

Member

EDIT: ignore me for a bit, I just tried that and it makes vim crash on exit. Perhaps gen_expand_wildcards is re-assigning NameBuff, although that would be way weird.

EDIT 2: still doesn't make a lot of sense to me though. Not seeing why the cast approach would be any different:

   966  static int has_special_wildchar(char_u *p)
   967  {
-> 968    for (; *p; mb_ptr_adv(p)) {
   969      if (*p == '\\' && p[1] != NUL)
   970        ++p;
   971      else if (vim_strchr((char_u *)SPECIAL_WILDCHAR, *p) != NULL)
(lldb) bt
* thread #1: tid = 0x252960, 0x000000010016a770 nvim`has_special_wildchar(p=0x6c6f662f7261762f) + 16 at path.c:968, queue = 'com.apple.main-thread', stop reason = EXC_BAD_ACCESS (code=EXC_I386_GPFLT)
  * frame #0: 0x000000010016a770 nvim`has_special_wildchar(p=0x6c6f662f7261762f) + 16 at path.c:968
    frame #1: 0x000000010016a336 nvim`gen_expand_wildcards(num_pat=1, pat=0x0000000100291710, num_file=0x00007fff5fbfeb24, file=0x00007fff5fbfeb28, flags=35) + 118 at path.c:1026
    frame #2: 0x0000000100215917 nvim`vim_deltempdir + 119 at tempfile.c:63
    frame #3: 0x00000001001090f4 nvim`ml_close_all(del_file=1) + 180 at memline.c:593
    frame #4: 0x0000000100166ccf nvim`mch_exit(r=0) + 175 at os_unix.c:585
    frame #5: 0x00000001000f4e16 nvim`getout(exitval=0) + 806 at main.c:829
    frame #6: 0x0000000100093cbb nvim`ex_quit(eap=0x00007fff5fbfee40) + 475 at ex_docmd.c:5160
    frame #7: 0x00000001000884aa nvim`do_one_cmd(cmdlinep=0x00007fff5fbff5b0, sourcing=0, cstack=0x00007fff5fbff0f8, fgetline=0x00000001000a8880, cookie=0x0000000000000000) + 11066 at ex_docmd.c:1937
    frame #8: 0x00000001000846c3 nvim`do_cmdline(cmdline=0x0000000000000000, fgetline=0x00000001000a8880, cookie=0x0000000000000000, flags=0) + 2659 at ex_docmd.c:646
    frame #9: 0x000000010013b70d nvim`nv_colon(cap=0x00007fff5fbff748) + 285 at normal.c:4078
    frame #10: 0x0000000100131549 nvim`normal_cmd(oap=0x00007fff5fbff7f8, toplevel=1) + 6105 at normal.c:911
    frame #11: 0x00000001000f4adc nvim`main_loop(cmdwin=0, noexmode=0) + 1932 at main.c:742
    frame #12: 0x00000001000f18e7 nvim`main(argc=1, argv=0x00007fff5fbffa10) + 1799 at main.c:525

This comment has been minimized.

@aktau

aktau Jul 20, 2014

Member

It seems that taking the address of a statically sized array has different semantics:

(lldb) expr (void)printf("%p %p\n", NameBuff, &NameBuff);
0x100291710 0x100291710

So *& would not be idempotent, which is why it crashes. This is also why your approach works.

This comment has been minimized.

@war1025

war1025 Jul 20, 2014

Contributor

Yea, that's the process I went through to get the code where its at. Fun stuff.

This comment has been minimized.

@justinmk

justinmk Jul 20, 2014

Member

I guess I'm fine with that if we feel confident that option (3) is correct.

I see absolutely no reason to not have it as a static array because that's what it is.

Well, we are then turning around and telling gen_expand_wildcards that it isn't :)

This comment has been minimized.

@aktau

aktau Jul 20, 2014

Member

Well, we are then turning around and telling gen_expand_wildcards that it isn't :).

Hehe, I see what you mean. But gen_expand_wildcards expects an array of strings, and, well, in fact @war1025's solution is more or less the right one. I think I would've gone for something like:

char_u *ptr = NameBuff;  // perhaps a cast is necessary here
gen_expand_wildcards(1, &ptr, &fcount, ...);

It looks a bit less alien (though I'm not sure if it works). But the downside is that it's less obvious that something tricky is going on.

This comment has been minimized.

@war1025

war1025 Jul 21, 2014

Contributor

@aktau I like the way I have it since the function asks for a list of char_u* which is what I'm making. I will switch it to your way if you want. I'm not hard up on it. Either way it would probably be good to add in a comment about why it is needed.

This comment has been minimized.

@aktau

aktau Jul 21, 2014

Member

I don't feel too strongly about it to request a change. But a comment would definitely feel refreshing, yes (even if it was just a reference to these comments, but preferably something inline).

This comment has been minimized.

@war1025

war1025 Jul 22, 2014

Contributor

Done Added a comment. Let me know if it works for you.

}

This comment has been minimized.

@aktau

aktau Jul 20, 2014

Member

The Stack Overflow link referenced by @justinmk says most of it really (refreshing to read). As long as they're (supposed to be) ints, enums seems better because they're true constants. Then we can also keep the switch, which looks cleaner. Otherwise, the extra lua header is better until I can update the Lua-C parser to handle simple #define's properly.

This comment has been minimized.

@war1025

war1025 Jul 20, 2014

Contributor

Will switch this back once I get the test contant things working correctly.

This comment has been minimized.

@war1025

war1025 Jul 22, 2014

Contributor

Done

@@ -822,7 +822,7 @@ EXTERN int swap_exists_did_quit INIT(= FALSE);

EXTERN char_u IObuff[IOSIZE]; /* sprintf's are done in this buffer,
size is IOSIZE */
EXTERN char_u *NameBuff; /* file names are expanded in this
EXTERN char_u NameBuff[MAXPATHL]; /* file names are expanded in this
* buffer, size is MAXPATHL */

This comment has been minimized.

@justinmk

justinmk Jul 20, 2014

Member

Now we don't need the "size is MAXPATHL" comment nor the "size is IOSIZE" fragment 2 lines above. Try to make this comment fit on line 825.

This comment has been minimized.

@war1025

war1025 Jul 20, 2014

Contributor

Done

local buf2 = buflist_new(path2, buffer.BLN_LISTED)
local buf3 = buflist_new(path3, buffer.BLN_LISTED)

eq(buf1.b_fnum, buflist_findpat("test"))

This comment has been minimized.

@justinmk

justinmk Jul 22, 2014

Member

But this could also be dependent on the order of the buffers (buf1 happens to be the first buffer). Probably need another test for that or re-order the buffers in this test and repeat the assert.

This comment has been minimized.

@war1025

war1025 Jul 22, 2014

Contributor

Done Ran the test for all 3 buffers.

close_buffer(NULL, buf3, buffer.DOBUF_DEL, 0)

-- Then: It should not find the buffer when searching only listed buffers
eq(-1, buflist_findpat("_test_"))

This comment has been minimized.

@justinmk

justinmk Jul 22, 2014

Member

Better to explicitly send 0 here than coalesce it in the helper function above.

This comment has been minimized.

@war1025

war1025 Jul 22, 2014

Contributor

Done Switched and added constants to make it clearer what the value means

close_buffer(NULL, buf3, buffer.DOBUF_WIPE, 0)

-- Then: It should not find the buffer at all
eq(-1, buflist_findpat("_test_"))

This comment has been minimized.

@justinmk

justinmk Jul 22, 2014

Member

Here too.

This comment has been minimized.

@war1025

war1025 Jul 22, 2014

Contributor

Done

local buf2 = buflist_new(path2, buffer.BLN_LISTED)

-- Then: The first buffer is preferred when both are listed
eq(buf1.b_fnum, buflist_findpat("test"))

This comment has been minimized.

@justinmk

justinmk Jul 22, 2014

Member

The first buffer is preferred when both are listed

But in a test above, this buffer is preferred because test_ is at the start of the buffer name. So this comment would make more sense if both buffer names started with test_ in this test, showing that order was the tie-breaker here.

This comment has been minimized.

@war1025

war1025 Jul 22, 2014

Contributor

I think the current flow works.

What I am trying to demonstrate in the test is that while buf1 is preferred when both are listed (as you stated), once buf1 becomes unlisted, buf2 is preferred.

This comment has been minimized.

@war1025

war1025 Jul 22, 2014

Contributor

I updated the test comments to clarify

--}

close_buffer(NULL, buf1, buffer.DOBUF_WIPE, 0)
close_buffer(NULL, buf2, buffer.DOBUF_WIPE, 0)

This comment has been minimized.

@justinmk

justinmk Jul 22, 2014

Member

these can probably go in a after_each, even if some buffers aren't used for some tests.

This comment has been minimized.

@war1025

war1025 Jul 22, 2014

Contributor

I debated and ended up leaving it like this because some of the tests depend on us not having all 3 buffers open and the thing we have to pass to close_buffer is a locally allocated variable.

eq( '^path$', file_pat_to_reg_pat('path'))
end)

it('does not include ^ when there is a starting glob (*)', function()

This comment has been minimized.

@justinmk

justinmk Jul 22, 2014

Member

does not prepend ^ if input path begins with * glob

return ffi.string(res)
end

it('converts a plaintext path to a regex with ^ and $', function()

This comment has been minimized.

@justinmk

justinmk Jul 22, 2014

Member

returns ^path$ regex for literal path input

eq('path', file_pat_to_reg_pat('*path*'))
end)

it('replaces the bash any character (?) with the regex any character (.)', function()

This comment has been minimized.

@justinmk

justinmk Jul 22, 2014

Member

It's not really bash-specific, it's just a glob syntax.

eq('^foo.bar$', file_pat_to_reg_pat('foo?bar'))
end)

it('replaces a glob (*) in the middle of a path with regex multiple any character (.*)',

This comment has been minimized.

@justinmk

justinmk Jul 22, 2014

Member

converts pa*th glob to ^pa.*th$ regex

This comment has been minimized.

@war1025

war1025 Jul 22, 2014

Contributor

I think the current text is better because it explains the context of what is happening rather than just echoing what the assert in the test is showing already.

@justinmk

This comment has been minimized.

Copy link
Member

justinmk commented Jul 22, 2014

LGTM. @war1025 would you mind signing the CLA?

@war1025

This comment has been minimized.

Copy link
Contributor

war1025 commented Jul 22, 2014

Signed the CLA.

@aktau

This comment has been minimized.

Copy link
Member

aktau commented Jul 22, 2014

Can't comment inline on some code comments, so doing it here for all: 👍 starting to look really good @war1025. Thanks for the effort!

-- that is initialized in main() and main() is not called for unit tests.
-- But it is not a big problem: all tests can work with or without it.
-- tempfile.vim_deltempdir()
tempfile.vim_deltempdir()

This comment has been minimized.

@war1025

war1025 Jul 22, 2014

Contributor

Made this change. The comment suggesting it was on a commit that got clobbered so I don't remember who requested it.

This comment has been minimized.

@Hinidu

Hinidu Jul 22, 2014

Contributor

It was me, thank you!

@aktau

This comment has been minimized.

Copy link
Member

aktau commented Jul 22, 2014

Alright, I've been trying to create tests for #978 and now I'm blocked on a change in this PR: the NameBuff initial allocation we've been talking about.

@justinmk

This comment has been minimized.

Copy link
Member

justinmk commented Jul 22, 2014

@war1025 is this RDY for merge?

@aktau

This comment has been minimized.

Copy link
Member

aktau commented Jul 22, 2014

Just gave it another combover (it's smaller than the 113 (!) comment discussion would make you think), and it looks very nice to me.

aktau added a commit to aktau/neovim that referenced this pull request Jul 22, 2014

TOCHANGE/os/shell: add tests
- The call to allocate_...() needs to go (and the ones to initialize logging
  hopefully as well). Blocked on neovim#904.

justinmk added a commit that referenced this pull request Jul 22, 2014

Merge pull request #904 from war1025/dev/buffer_tests
Add unit tests for buffer.c and fileio.c

@justinmk justinmk merged commit ba04a1c into neovim:master Jul 22, 2014

1 check passed

continuous-integration/travis-ci The Travis CI build passed
Details
@aktau

This comment has been minimized.

Copy link
Member

aktau commented Jul 22, 2014

@justinmk thanks for merging! I just tried make && make unittest here and all tests pass. But it does print out some stuff:

E94: No matching buffer for _test_
E94: No matching buffer for _test_
E94: No matching buffer for _test●○
E94: No matching buffer for tes

EDIT: apparently this also happens on Linux, seeing as its also in the travis logs

@justinmk

This comment has been minimized.

Copy link
Member

justinmk commented Jul 22, 2014

@aktau That looks like EMSG from buflist_findpat(). Is there a way to silence EMSG? Do we want to?

@aktau

This comment has been minimized.

Copy link
Member

aktau commented Jul 22, 2014

@aktau That looks like EMSG from buflist_findpat(). Is there a way to silence EMSG? Do we want to?

Not sure. It's not actively harmful either. Just a bit unclean. In the long run we should disable it for the library.

I'm actually dealing with a very similar problem now: the *LOG functions. They can easily be omitted from a shared library build I think, and it would solve some of my headaches.

fwalch added a commit to fwalch/neovim that referenced this pull request Jul 22, 2014

test/helpers: add 'vim_init' helper
- Initializes some global variables.
- Necessary for the buffer tests in PR neovim#904.

@war1025 war1025 deleted the war1025:dev/buffer_tests branch Jul 23, 2014

fmoralesc added a commit to fmoralesc/neovim that referenced this pull request Aug 19, 2014

test/helpers: add 'vim_init' helper
- Initializes some global variables.
- Necessary for the buffer tests in PR neovim#904.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment