Re: Dynamic python bindings and "undefined symbol" error
On Wed, Apr 06, 2016 at 09:07:32AM -0700, 'Anatol Pomazau' via vim_dev wrote:
> Here is a followup for this discussion at Arch Linux forum
> https://bbs.archlinux.org/viewtopic.php?id=210968
>
> Arch recently switched to dynamic language bindings to support both
> python2 and python3 by the same package. It works great except a few
> use-cases. It turned out that some python packages (like python-dbus)
> do not link their packages to python shared library:
>
> $ ldd /usr/lib/python2.7/site-packages/_dbus_bindings.so | grep python
> # compare it to yaml library:
> $ ldd /usr/lib/python2.7/site-packages/_yaml.so | grep python
> libpython2.7.so.1.0 => /usr/lib/libpython2.7.so.1.0 (0x7ffa53d88000)
>
> I am not a python guru and not sure why it is done. Does anybody know why it
> is not linked to libpython2.7.so?
This thread on Python's distutils-sig@ may be relevant:
https://mail.python.org/pipermail/distutils-sig/2016-February/028275.html
> But this enough for vim to crash when this package is loading:
>
> :py import dbus
> Traceback (most recent call last):
> File "", line 1, in
> File "/usr/lib/python2.7/site-packages/dbus/__init__.py", line 77, in
>
> import dbus.types as types
> File "/usr/lib/python2.7/site-packages/dbus/types.py", line 6, in
> from _dbus_bindings import (
> ImportError: /usr/lib/python2.7/site-packages/_dbus_bindings.so: undefined
> symbol: PyExc_KeyboardInterrupt
Ouch.
> This behavior is different from static language bindings where (it
> seems) python libraries are loaded into namespace by vim itself.
>
> What is the right way to resolve it? Should vim preload python
> libraries when the language binding is used? Or all python libraries
> should be linked to libpython2.7.so?
Perhaps if vim used RTLD_GLOBAL when dlopen'ing libpython that would
make things work? Apparently that's the workaround that mod_wsgi uses
to fix this exact situation, if I correctly understood
https://mail.python.org/pipermail/distutils-sig/2016-February/028286.html
:h if_pyth.txt describes what to do to try that (undefine
PY_NO_RTLD_GLOBAL in auto/config.h after running ./configure), and what
the downsides are ("may crash Vim", if you attempt to use both :py and
:py3 in the same vim seession).
Marius Gedminas
--
Every nonempty totally-disconnected perfect compact metric space is
homeomorphic to the Cantor set.
--
--
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: Vim 7.5 or Vim 8?
On Tuesday, April 5, 2016 at 2:28:34 AM UTC-5, Dominique Pelle wrote: > Bram Moolenaar wrote: > > > I have been wondering if the next release should be called 7.5 or 8. > > We have quite a few new features, but not that many as with the Vim 7 > > release. Well, that was a big release. I think the most important > > addition since then is persistent undo in 7.3. Now we have more new > > features than in 7.3 or 7.4. 7.1 and 7.2 were mostly bug fixes. > > 8.0 or 7.5 is a bit arbitrary without conventions such as: > - major version number increased when breaking backward >compatibility (which should be rare) > - middle version number increased when adding new features > - minor version increased for bug fixes > I actually think 8.0 makes sense, due entirely to expected plugins that will require the new features. Considering any plugins that start to require the new packages feature, IO/jobs/channels features, etc. may not work AT ALL in older Vims (instead of just degraded performance) I think it makes sense to let them say "requires Vim 8.0 and up". Although Vim kept backwards compatibility, it introduced a bunch of features that will be hard to embrace fully in plugins and yet remain backwards compatible with older Vims. -- -- 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.
setf make for Makefile.inc
good day, (this is my first ever attempt at sending a patch for vim) please find attached a very simple patch to set the filetype make for Makefile.inc files. these files are fairly common in make based projects and are routinely used in OpenBSD's ports tree (package building framework). -f -- this message printed on 100% recycled electrons. -- -- 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. --- runtime/filetype.vim.orig Wed Apr 6 22:56:21 2016 +++ runtime/filetype.vimWed Apr 6 22:57:18 2016 @@ -1138,7 +1138,7 @@ au BufNewFile,BufRead */etc/mail/aliases,*/etc/aliases au BufNewFile,BufRead .mailcap,mailcap setf mailcap " Makefile -au BufNewFile,BufRead *[mM]akefile,*.mk,*.mak,*.dsp setf make +au BufNewFile,BufRead *[mM]akefile,*.mk,*.mak,*.dsp,Makefile.inc setf make " MakeIndex au BufNewFile,BufRead *.ist,*.mst setf ist
BSD specific cType's for syntax highlighting
good day,
please find attached a simple patch to add some C types
used on some BSD systems to the C syntax highlighting file.
-f
--
nothing is fool-proof to a sufficiently talented fool.
--
--
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.
--- runtime/syntax/c.vim.orig Thu Apr 9 21:08:22 2015
+++ runtime/syntax/c.vimThu Apr 9 23:41:51 2015
@@ -248,6 +248,7 @@ if !exists("c_no_c99") " ISO C99
syn keyword cType _Bool bool _Complex complex _Imaginary imaginary
syn keyword cType int8_t int16_t int32_t int64_t
syn keyword cType uint8_t uint16_t uint32_t uint64_t
+ syn keyword cType u_int8_t u_int16_t u_int32_t u_int64_t
syn keyword cType int_least8_t int_least16_t int_least32_t
int_least64_t
syn keyword cType uint_least8_t uint_least16_t uint_least32_t
uint_least64_t
syn keyword cType int_fast8_t int_fast16_t int_fast32_t
int_fast64_t
Re: [vim/vim] Provide a way to get list of buffers in diff mode / (re)set diff mode (#736)
2016-04-07 3:24 GMT+03:00 Daniel Hahler :
> I am seeing the following error from time to time, although only two diff
> windows are visible:
>
> E101: More than two buffers in diff mode, don't know which one to use
>
> This might happen when closing a window which had diff mode enabled, and
> there
> appears no way to reset it easily?!
>
> I've seen usage of getbufvar in that context, but the following returns
> all buffers when in a window with diff set, and is empty otherwise
> (although another window is in diff mode):
>
> :echo filter(range(1, bufnr('$')), "getbufvar(v:val, '&diff')")
>
> Is there a way to see for which buffers diff is set?
>
&diff is window-local option. Your question has no sense, it may not be
set for any buffer. You may get a list of windows in which this option is
set and transform this into a list of buffers displayed in those windows.
`getbufvar()` is evaluated in the current window context, with different
buffer context. So, of course, your code does not work; but VimL is rather
permissive so it does not work, but as well does not throw any errors. If
you wrote
:python for buf in vim.buffers: print(buf.number, buf.options['diff'])
you would get KeyError because my python bindings are not that permissive:
you cannot use `options` attribute of `vim.Buffer` instance to get option
that is not buffer-local or buffer-local/global.
> It could certainly be displayed with the E101 error (since it can only be
> 4 (E96)).
>
> It seems like diffoff! could provide a way to turn it off, but that
> appears
> to handle windows (and their buffers) only:
>
> :diffo[ff]! Switch off diff mode for the current window and in all windows
> in the current tab page where 'diff' is set. Resetting
> related options only happens in a window that has 'diff' set,
> if the current window does not have 'diff' set then no options
> in it are changed.
>
> —
> You are receiving this because you are subscribed to this thread.
> Reply to this email directly or view it on GitHub
>
>
> --
> --
> 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.
Patch 7.4.1716
Patch 7.4.1716
Problem:'autochdir' doesn't work for the first file. (Rob Hoelz)
Solution: Call DO_AUTOCHDIR after startup. (Christian Brabandt, closes #704)
Files: src/main.c
*** ../vim-7.4.1715/src/main.c 2016-03-26 20:59:48.107431656 +0100
--- src/main.c 2016-04-06 23:03:32.600191578 +0200
***
*** 959,964
--- 959,967
no_wait_return = FALSE;
starting = 0;
+ /* 'autochdir' has been postponed */
+ DO_AUTOCHDIR
+
#ifdef FEAT_TERMRESPONSE
/* Requesting the termresponse is postponed until here, so that a "-c q"
* argument doesn't make it appear in the shell Vim was started from. */
*** ../vim-7.4.1715/src/version.c 2016-04-06 22:59:33.503226978 +0200
--- src/version.c 2016-04-06 23:02:08.169269889 +0200
***
*** 750,751
--- 750,753
{ /* Add new patch number below this line */
+ /**/
+ 1716,
/**/
--
hundred-and-one symptoms of being an internet addict:
239. You think "surfing" is something you do on dry land.
/// 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.1715
Patch 7.4.1715
Problem:Double free when a partial is in a cycle with a list or dict.
(Nikolai Pavlov)
Solution: Do not free a nested list or dict.
Files: src/eval.c, src/testdir/test_partial.vim
*** ../vim-7.4.1714/src/eval.c 2016-04-03 22:44:32.403625720 +0200
--- src/eval.c 2016-04-06 22:48:53.971029556 +0200
***
*** 5929,5934
--- 5929,5985
return OK;
}
+ static void
+ partial_free(partial_T *pt, int recursive)
+ {
+ int i;
+
+ for (i = 0; i < pt->pt_argc; ++i)
+ {
+ typval_T *tv = &pt->pt_argv[i];
+
+ if (recursive || (tv->v_type != VAR_DICT && tv->v_type != VAR_LIST))
+ clear_tv(tv);
+ }
+ vim_free(pt->pt_argv);
+ if (recursive)
+ dict_unref(pt->pt_dict);
+ func_unref(pt->pt_name);
+ vim_free(pt->pt_name);
+ vim_free(pt);
+ }
+
+ /*
+ * Unreference a closure: decrement the reference count and free it when it
+ * becomes zero.
+ */
+ void
+ partial_unref(partial_T *pt)
+ {
+ if (pt != NULL && --pt->pt_refcount <= 0)
+ partial_free(pt, TRUE);
+ }
+
+ /*
+ * Like clear_tv(), but do not free lists or dictionaries.
+ * This is when called via free_unref_items().
+ */
+ static void
+ clear_tv_no_recurse(typval_T *tv)
+ {
+ if (tv->v_type == VAR_PARTIAL)
+ {
+ partial_T *pt = tv->vval.v_partial;
+
+ /* We unref the partial but not the dict or any list it
+* refers to. */
+ if (pt != NULL && --pt->pt_refcount == 0)
+ partial_free(pt, FALSE);
+ }
+ else if (tv->v_type != VAR_LIST && tv->v_type != VAR_DICT)
+ clear_tv(tv);
+ }
+
/*
* Allocate a variable for a List and fill it from "*arg".
* Return OK or FAIL.
***
*** 6070,6078
{
/* Remove the item before deleting it. */
l->lv_first = item->li_next;
! if (recurse || (item->li_tv.v_type != VAR_LIST
! && item->li_tv.v_type != VAR_DICT))
clear_tv(&item->li_tv);
vim_free(item);
}
vim_free(l);
--- 6121,6130
{
/* Remove the item before deleting it. */
l->lv_first = item->li_next;
! if (recurse)
clear_tv(&item->li_tv);
+ else
+ clear_tv_no_recurse(&item->li_tv);
vim_free(item);
}
vim_free(l);
***
*** 7185,7190
--- 7237,7252
}
}
}
+ if (tv->v_type == VAR_PARTIAL)
+ {
+ partial_T *pt = tv->vval.v_partial;
+ int i;
+
+ if (pt != NULL)
+ for (i = 0; i < pt->pt_argc; ++i)
+ set_ref_in_item(&pt->pt_argv[i], copyID,
+ ht_stack, list_stack);
+ }
}
else if (tv->v_type == VAR_LIST)
{
***
*** 7215,7246
return abort;
}
- static void
- partial_free(partial_T *pt, int free_dict)
- {
- int i;
-
- for (i = 0; i < pt->pt_argc; ++i)
- clear_tv(&pt->pt_argv[i]);
- vim_free(pt->pt_argv);
- if (free_dict)
- dict_unref(pt->pt_dict);
- func_unref(pt->pt_name);
- vim_free(pt->pt_name);
- vim_free(pt);
- }
-
- /*
- * Unreference a closure: decrement the reference count and free it when it
- * becomes zero.
- */
- void
- partial_unref(partial_T *pt)
- {
- if (pt != NULL && --pt->pt_refcount <= 0)
- partial_free(pt, TRUE);
- }
-
/*
* Allocate an empty header for a dictionary.
*/
--- 7277,7282
***
*** 7331,7350
* something recursive causing trouble. */
di = HI2DI(hi);
hash_remove(&d->dv_hashtab, hi);
! if (recurse || (di->di_tv.v_type != VAR_LIST
!&& di->di_tv.v_type != VAR_DICT))
! {
! if (!recurse && di->di_tv.v_type == VAR_PARTIAL)
! {
! partial_T *pt = di->di_tv.vval.v_partial;
!
! /* We unref the partial but not the dict it refers to. */
! if (pt != NULL && --pt->pt_refcount == 0)
! partial_free(pt, FALSE);
! }
! else
! clear_tv(&di->di_tv);
! }
vim_free(di);
--todo;
}
--- 7367,7376
* something recursive causing trouble. */
di = HI2DI(hi);
hash_remove(&d->dv_hashtab, hi);
! if (recurse)
! clear_tv(&di->di_tv);
! else
! clear_tv_no_recurse(&di->di_tv);
vim_free(di);
--todo;
}
*** ../vim-7.4.1714/src/testdir/test_partial.vim2016-03-24
21:58:06.940204253 +0100
--- src/testdir/test_partial.vim2016-04-06 22:28:06.495210598 +0200
***
*** 220,222
--- 220,240
endtry
endif
endfunc
+
+ " Thi
Re: [bug] netrw remote delete
Carlos Pita wrote: > Hi all, > > I'm getting this error message when trying to delete (pressing D) a file on a > remote directory: > > Error detected while processing function > 28_NetrwRemoteRm[32]..28_NetrwRemoteRmFile: > line 60: > E488: Trailing characters: else if ret != 0 > > Doing the same operation on a local directory works fine. Also, a remote > rename works. > Hello: Please try v156e of netrw, which you can get from my website: http://www.drchip.org/astronaut/vim/index.html#NETRW . Regards, Chip Campbell -- -- 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.
[bug] netrw remote delete
Hi all, I'm getting this error message when trying to delete (pressing D) a file on a remote directory: Error detected while processing function 28_NetrwRemoteRm[32]..28_NetrwRemoteRmFile: line 60: E488: Trailing characters: else if ret != 0 Doing the same operation on a local directory works fine. Also, a remote rename works. Cheers -- Carlos -- -- 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.
[bug] netrw not redrawing
Hi all, try doing a remote editing (I'm using scp) of some file, then executing :Lexplore, and pressing Enter to open a different file. The new file is shown in a new window as expected, but the netrw window won't be redrawn. The problem seems to be the commented out redraw! at line 2856 (version 155, Feb 16, 2016). Uncommenting it fixed the problem, at least for my use case. Cheers -- Carlos -- -- 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.
Dynamic python bindings and "undefined symbol" error
Here is a followup for this discussion at Arch Linux forum https://bbs.archlinux.org/viewtopic.php?id=210968 Arch recently switched to dynamic language bindings to support both python2 and python3 by the same package. It works great except a few use-cases. It turned out that some python packages (like python-dbus) do not link their packages to python shared library: $ ldd /usr/lib/python2.7/site-packages/_dbus_bindings.so | grep python # compare it to yaml library: $ ldd /usr/lib/python2.7/site-packages/_yaml.so | grep python libpython2.7.so.1.0 => /usr/lib/libpython2.7.so.1.0 (0x7ffa53d88000) I am not a python guru and not sure why it is done. Does anybody know why it is not linked to libpython2.7.so? But this enough for vim to crash when this package is loading: :py import dbus Traceback (most recent call last): File "", line 1, in File "/usr/lib/python2.7/site-packages/dbus/__init__.py", line 77, in import dbus.types as types File "/usr/lib/python2.7/site-packages/dbus/types.py", line 6, in from _dbus_bindings import ( ImportError: /usr/lib/python2.7/site-packages/_dbus_bindings.so: undefined symbol: PyExc_KeyboardInterrupt This behavior is different from static language bindings where (it seems) python libraries are loaded into namespace by vim itself. What is the right way to resolve it? Should vim preload python libraries when the language binding is used? Or all python libraries should be linked to libpython2.7.so? -- -- 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.
