[RDY] os: implement VimL libcall with {mch,os}_libcall

[aktau]

The old mch_libcall was removed from neovim. This is a partial
reimplementation on top of libuv. It doesn't catch exceptions (windows) nor
signals (unix) though, so it's quite a bit more prone to crashing if the
loadable library throws an exception or crashes. Still, it should be fine
for well-behaved libraries. Requested by @Shougo.

[aktau]

@justinmk @tarruda this is the PR of the changes I mentioned in issue #795.

[tarruda]

@Shougo would you like to test this branch?

[justinmk]

mch_libcall could be removed I think

[aktau]

mch_libcall could be removed I think

Done, and rebased against master.

[Shougo]

@Shougo would you like to test this branch?

I tested your branch and worked vimproc and vimshell.
Thank you!!

[aktau]

I tested your branch and worked vimproc and vimshell.

Good news!

[tarruda]

👍

[Shougo]

I benchmarked your branch by vimproc's benchmark.vim.

• system() is faster than Vim. Almost 0.310...(Vim) vs 0.207...(neovim)
• vimproc#system()'s(libcall) performance is almost same with Vim.

[aktau]

system() is faster than Vim. Almost 0.310...(Vim) vs 0.207...(neovim)

I suspect that's either libuv's or @tarruda's magic at work, nothing to do with libcall ;).

vimproc#system() performance is almost same with Vim.

I reckoned that, I suspect most of the work is in the loading and unloading of the library. If that's the case and it needs to be faster, we could conceivably keep loaded libraries in a dictionary, but that would increase the complexity and I don't think it's worth it for a feature that's not often used. The same speed sounds good for this one, don't you think?

[Shougo]

The same speed sounds good for this one, don't you think?

Not bad for me.

https://groups.google.com/d/msg/vim_dev/F2z5I9tayKY/UNGZ1-kSvq4J
https://groups.google.com/forum/#!topic/vim_dev/kS8BkiqqwyY

But if neovim supports FFI, it will be good.

[tarruda]

system() is faster than Vim. Almost 0.310...(Vim) vs 0.207...(neovim)

That is because of the new implementation of os_call_shell on top of libuv. I bet that will be even faster once system is refactored to use pipes instead of temporary files as explained in #473

[Shougo]

That is because of the new implementation of os_call_shell on top of libuv. I bet that will be even faster once system is refactored to use pipes instead of temporary files as explained in #473

It is good news for other plugins!

[Hinidu]

There are some uses of FEAT_LIBCALL. I think we should define it in config.h.in or remove entirely that has('libcall') will return true.

[aktau]

There are some uses of FEAT_LIBCALL. I think we should define it in config.h.in or remove entirely that has('libcall') will return true.

I'm not sure if I understand you. With this PR, libcall would be implemented for all platforms, which means that has('libcall') should always return true. (if that's even a thing). I agree that we should remove FEAT_LIBCALL from the source though, as it's no longer necessary to #ifdef.

[Hinidu]

has('libcall') will return false because in definition of f_has in eval.c we have now:

#ifdef FEAT_LIBCALL
    "libcall",
#endif

So we should remove FEAT_LIBCALL here and everywhere or define it in config.h.in.

[aktau]

So we should remove FEAT_LIBCALL here and everywhere or define it in config.h.in.

Ok, I just Ag'ed over the source. I think the best thing is to just remove the FEAT_LIBCALL #ifdef's everywhere and to make libcall like any other non-conditional vim function.

[Hinidu]

👍

[aktau]

@Hinidu done, can you review that?

To all others: I added the EMSG() that used to be in mch_libcall to libcall_common. It seems to me that these things should be in the vim layer, not the os layer.

[Hinidu]

aktau@5934529 is ok 👍

[Hinidu]

@aktau while working on #814 I found that in this PR you delete all occurences of USE_DLOPEN except one:

/* shared library access */
#if defined(HAVE_DLFCN_H) && defined(USE_DLOPEN)
# include <dlfcn.h>
#endif

So I think we can delete that #include in this PR too if you don't mind.

[aktau]

So I think we can delete that #include in this PR too if you don't mind.

I don't mind at all, thanks for noticing. I have removed those lines, rebased for good measure and force-pushed.

[Hinidu]

I don't mind at all, thanks for noticing. I have removed those lines, rebased for good measure and force-pushed.

Thank you, good work 👍

[justinmk]

Merged

[Shougo]

Great!