Re: patch for Solaris to correctly set v:progpath

[Danek Duvall]

Bram Moolenaar wrote:

> Danek Duvall wrote:
> 
> > After the recent patch to allow Linux builds to read /proc/self/exe, I
> > figured doing the equivalent on Solaris would be pretty easy.  The patch is
> > attached.
> 
> Thanks.  I'll also add "/proc/curproc/file" for FreeBSD.

Thanks!

Danek

-- 
-- 
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 for Solaris to correctly set v:progpath

[Danek Duvall]

After the recent patch to allow Linux builds to read /proc/self/exe, I
figured doing the equivalent on Solaris would be pretty easy.  The patch is
attached.

Thanks,
Danek

-- 
-- 
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.
diff --git a/src/auto/configure b/src/auto/configure
index 73b9ce7..c0570a4 100755
--- a/src/auto/configure
+++ b/src/auto/configure
@@ -10101,12 +10101,17 @@ fi
 
 
 
-{ $as_echo "$as_me:${as_lineno-$LINENO}: checking for /proc/self/exe" >&5
-$as_echo_n "checking for /proc/self/exe... " >&6; }
+{ $as_echo "$as_me:${as_lineno-$LINENO}: checking for /proc link to 
executable" >&5
+$as_echo_n "checking for /proc link to executable... " >&6; }
 if test -L "/proc/self/exe"; then
 { $as_echo "$as_me:${as_lineno-$LINENO}: result: yes" >&5
 $as_echo "yes" >&6; }
-$as_echo "#define HAVE_PROC_SELF_EXE 1" >>confdefs.h
+$as_echo "#define PROC_EXE_LINK \"/proc/self/exe\"" >>confdefs.h
+
+elif test -L "/proc/self/path/a.out"; then
+{ $as_echo "$as_me:${as_lineno-$LINENO}: result: /proc/self/path/a.out" >&5
+$as_echo "/proc/self/path/a.out" >&6; }
+$as_echo "#define PROC_EXE_LINK \"/proc/self/path/a.out\"" >>confdefs.h
 
 else
 { $as_echo "$as_me:${as_lineno-$LINENO}: result: no" >&5
diff --git a/src/config.h.in b/src/config.h.in
index a9bcf1e..f8a23ed 100644
--- a/src/config.h.in
+++ b/src/config.h.in
@@ -446,8 +446,8 @@
 /* Define if fcntl()'s F_SETFD command knows about FD_CLOEXEC */
 #undef HAVE_FD_CLOEXEC
 
-/* Define if /proc/self/exe can be read */
-#undef HAVE_PROC_SELF_EXE
+/* Define if /proc/self/exe or similar can be read */
+#undef PROC_EXE_LINK
 
 /* Define if you want Cygwin to use the WIN32 clipboard, not compatible with 
X11*/
 #undef FEAT_CYGWIN_WIN32_CLIPBOARD
diff --git a/src/configure.ac b/src/configure.ac
index 4445cf5..23fd88c 100644
--- a/src/configure.ac
+++ b/src/configure.ac
@@ -3020,10 +3020,13 @@ dnl 
---
 dnl end of GUI-checking
 dnl ---
 
-AC_MSG_CHECKING([for /proc/self/exe])
+AC_MSG_CHECKING([for /proc link to executable])
 if test -L "/proc/self/exe"; then
 AC_MSG_RESULT(yes)
-AC_DEFINE(HAVE_PROC_SELF_EXE)
+AC_DEFINE(PROC_EXE_LINK, "/proc/self/exe")
+elif test -L "/proc/self/path/a.out"; then
+AC_MSG_RESULT(/proc/self/path/a.out)
+AC_DEFINE(PROC_EXE_LINK, "/proc/self/path/a.out")
 else
 AC_MSG_RESULT(no)
 fi
diff --git a/src/main.c b/src/main.c
index aa5a1a2..29ab3c6 100644
--- a/src/main.c
+++ b/src/main.c
@@ -3539,11 +3539,11 @@ set_progpath(char_u *argv0)
 {
 char_u *val = argv0;
 
-# ifdef HAVE_PROC_SELF_EXE
+# ifdef PROC_EXE_LINK
 charbuf[PATH_MAX + 1];
 ssize_t len;
 
-len = readlink("/proc/self/exe", buf, PATH_MAX);
+len = readlink(PROC_EXE_LINK, buf, PATH_MAX);
 if (len > 0)
 {
buf[len] = NUL;

Re: Patch 8.0.0436

[Danek Duvall]

On Sat, Mar 11, 2017 at 10:02:13AM +0900, Kazunobu Kuriyama wrote:

> Though I'm not 100% sure whether or not what I'm going to tell you is
> relevant to the issue Danek is talking about, let me do so anyway because I
> think it's a good occasion for me to do that now.
> 
> How to reproduce a resize problem:
> 
> (1) Start X11 with the twm window manager running (Or, using any window
> manager of choice instead is a good idea for comparison, I think).
> 
> (2) Open a terminal and resize it wider than 80 columns.
> 
> (3) cd /.../vim/src && make && make test3
> 
> On my PC, the width of the terminal gets reduced to 80 columns during the
> test.
> 
> It appears the problem is due to line 973 of test3.in:
> 
> :set tw=0 wm=60 columns=80 noai fo=croq
> 
> Though I've noticed that for a quite while, I've also found that whether or
> not the problem occurs depends on the window manager in use. So I had been
> holding back from reporting that.

Indeed; adding "t_WS=" to that line (before columns=80) takes care of the
remainder of the terminal resizing.

Thanks!
Danek

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

[Danek Duvall]

On Fri, Mar 10, 2017 at 09:34:43PM +0100, Bram Moolenaar wrote:

> 
> Danek -
> 
> > On Thu, Mar 09, 2017 at 01:55:24PM +0100, Bram Moolenaar wrote:
> > 
> > > Patch 8.0.0436
> > > Problem:Running the options test sometimes resizes the terminal.
> > > Solution:   Clear out t_WS.
> > > Files:  src/testdir/gen_opt_test.vim
> > 
> > Is this supposed to be the only thing in the test suite that resizes the
> > terminal?  Because that's still happening for me (with patch 442) when
> > running the full suite.
> 
> Is that with the GUI perhaps?  The patch only disables it for the
> terminal, because tests were sometimes failing, apparently because the
> original size was not restored and the height was too small to split the
> window.  I'm assuming that for the GUI there is no problem restoring the
> size.

No, this is in the terminal.  But it must be happening due to a test other
than opt_test.vim.  I can try to track it down, if there's interest.  I'm
glad to have the beeping gone, now it would be nice if my terminal didn't
shrink every time I ran the tests.  :)

Danek

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

[Danek Duvall]

On Thu, Mar 09, 2017 at 01:55:24PM +0100, Bram Moolenaar wrote:

> Patch 8.0.0436
> Problem:Running the options test sometimes resizes the terminal.
> Solution:   Clear out t_WS.
> Files:  src/testdir/gen_opt_test.vim

Is this supposed to be the only thing in the test suite that resizes the
terminal?  Because that's still happening for me (with patch 442) when
running the full suite.

Thanks,
Danek

-- 
-- 
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: core dumps during signal handling

[Danek Duvall]

So I'm still getting this one, or something pretty similar, every time my
ssh session drops:

7ffe71ba798a _ndoprnt_s () + 1a
7ffe71ba7932 _ndoprnt () + 12
7ffe71ba6bdd vsnprintf () + ad
7ffe71ba5df3 vasprintf () + 43
7ffe71ba5f9c asprintf () + 9c
7ffe71c5a58f checkit () + 3f
7ffe71c5a8fe fallback () + 28e
7ffe71c5ade6 locale_fallback () + 126
7ffe71b99608 _real_gettext_u_l () + 538
7ffe71b99789 _real_gettext_u () + 49
7ffe71b9712b gettext () + 6b
00503029 write_viminfo () + 5e9
00709786 getout () + 176
7ffe71c4b936 __sighndlr () + 6
7ffe71c3ceb1 call_user_handler () + 2f1
7ffe71c3d2ce sigacthandler (1, 0, 513fbce0) + de
--- called from signal handler with signal 1 (SIGHUP) ---
7ffe71c5214a __pollsys () + a
7ffe71b85a93 pselect () + 193
7ffe71b8649b select () + 6b
00602348 WaitForChar () + 218
005fe0f3 mch_inchar () + 6e3
006b7bc0 ui_inchar () + d0
0056f581 inchar () + 1c1
0056ef8f vgetorpeek () + 19ef
0056cef0 vgetc () + 60
0056d479 safe_vgetc () + 9
005c7d04 normal_cmd () + 134
007095e1 main_loop () + 821
0070867c vim_main2 () + 85c
00707e02 main () + 362
0049d1c4  ()

Here's a similar one, where gettext() appears to be called directly from
deathtrap(), which is odd:

7ff024ba798a _ndoprnt_s () + 1a
7ff024ba7932 _ndoprnt () + 12
7ff024ba6bdd vsnprintf () + ad
7ff024ba5df3 vasprintf () + 43
7ff024ba5f9c asprintf () + 9c
7ff024c5a58f checkit () + 3f
7ff024c5a8fe fallback () + 28e
7ff024c5ade6 locale_fallback () + 126
7ff024b99608 _real_gettext_u_l () + 538
7ff024b99789 _real_gettext_u () + 49
7ff024b9712b gettext () + 6b
005d367e deathtrap () + ee
7ff024c4b936 __sighndlr () + 6
7ff024c3ceb1 call_user_handler () + 2f1
7ff024c3d2ce sigacthandler (1, 0, 8396566f0) + de
--- called from signal handler with signal 1 (SIGHUP) ---
7ff024c51eea kill () + a
00679054 ui_inchar () + 84
005462ae vgetorpeek () + 17de
00544436 vgetc () + 76
005449a9 safe_vgetc () + 9
005a38f4 normal_cmd () + 134
006ac5e1 main_loop () + 771
006abe59 main () + 2c79
0048b9e4  ()

Perhaps _ should be #defined to something that can test to see whether
we're executing in an unsafe context, and call gettext() only if that's not
the case.

Danek

-- 
-- 
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 to create icon directories before installing

[Danek Duvall]

I've been sitting on this patch for a bit.  If you do "make install" with
DESTDIR set, then it's unlikely that the directories where the icons go
will exist already, so create them in that situation.

--- a/src/Makefile
+++ b/src/Makefile
@@ -2366,6 +2366,10 @@ ICONTHEMEPATH = $(DATADIR)/icons/hicolor
 DESKTOPPATH = $(DESTDIR)$(DATADIR)/applications
 KDEPATH = $(HOME)/.kde/share/icons
 install-icons:
+   if test -n "$(DESTDIR)"; then \
+   $(SHELL) ./mkinstalldirs $(ICON48PATH) $(ICON32PATH) \
+   $(ICON16PATH) $(DESKTOPPATH); \
+   fi
if test -d $(ICON48PATH) -a -w $(ICON48PATH) \
-a ! -f $(ICON48PATH)/gvim.png; then \
   $(INSTALL_DATA) $(SCRIPTSOURCE)/vim48x48.png $(ICON48PATH)/gvim.png; 
\

Thanks,
Danek

-- 
-- 
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: compiler warning w/ Studio & gtk3 GUI

[Danek Duvall]

On Wed, Aug 24, 2016 at 07:09:01PM +0900, Kazunobu Kuriyama wrote:

> > I guess I'm a bit surprised that clang didn't show it; I thought it did
> > a better job of finding bad code.  I guess that's why we try to have a
> > diverse bundle of compilers.  :)
> 
> Indeed.  And I envy you for the compiler :)

It's available for free for production use on Linux, too:


http://www.oracle.com/technetwork/server-storage/developerstudio/downloads/index.html

though AFAIK you don't get any support whatsoever, not even patches.

Danek

-- 
-- 
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: compiler warning w/ Studio & gtk3 GUI

[Danek Duvall]

On Tue, Aug 23, 2016 at 06:01:54PM +0900, Kazunobu Kuriyama wrote:

> Hi Danek,
> 
> I think that mismatch is not our fault, either.

Yeah, that was my thought, but I thought perhaps the Solaris setup was
somehow incorrect.  But it really does look like a bug in glib/gtk.  I'll
see if I can get a bug filed upstream.

> That said, it would take some time to file the issue against them and wait
> for their response to that; it would be better for us to do something about
> that for ourselves.
> 
> So I made a patch for fixing the issue, which is attached to this mail.
> 
> For that, I assumed that the Solaris Studio had the predefined constant
> macro __SUNPRO_C.  Is that assumption OK?

Yup, that seems reasonable.  And the patch works just fine -- no more
warnings, and the result seems to work just fine.

> If that's OK, could you try the patch to check if it works as expected?
> 
> Note that the patch includes some minor fixes on coding style, too.
> 
> 
> > glib is 2.46, gtk3 is 3.18.
> >
> > I don't see this in the travis logs, but I can't tell from there what
> > versions of glib and gtk are in use.
> >
> > Does this look familiar to anyone?
> 
> I didn't see either clang or gcc (generic one, not the one which is a
> symbolic link to clang) giving me any warning on the mismatch.  I didn't
> know about that until I read you report.

Yeah; I wonder if gcc would show that with some more -W flags thrown in
there.  I guess I'm a bit surprised that clang didn't show it; I thought it
did a better job of finding bad code.  I guess that's why we try to have a
diverse bundle of compilers.  :)

Thanks,
Danek

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

compiler warning w/ Studio

[Danek Duvall]

I'm also seeing these warnings:

"globals.h", line 371: warning: initializer will be sign-extended: -1
"globals.h", line 372: warning: initializer will be sign-extended: -1

Hardly surprising since it's taking a negative value and implicitly casting
to unsigned.  But I don't know what the right fix would be, and I'm not
sure why it's not showing up on travis, other than the compilers simply
being different.

Thanks,
Danek

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

compiler warning w/ Studio & gtk3 GUI

[Danek Duvall]

I'm seeing these warnings when building on Solaris with the Studio
compilers.

"gui_gtk_f.c", line 507: warning: argument #6 is incompatible with 
prototype:
prototype: pointer to void : 
"/usr/include/glib-2.0/gobject/gsignal.h", line 431
argument : pointer to function(void) returning void
"gui_gtk_f.c", line 510: warning: argument #6 is incompatible with 
prototype:
prototype: pointer to void : 
"/usr/include/glib-2.0/gobject/gsignal.h", line 431
argument : pointer to function(void) returning void
"gui_gtk_f.c", line 795: warning: argument #6 is incompatible with 
prototype:
prototype: pointer to void : 
"/usr/include/glib-2.0/gobject/gsignal.h", line 431
argument : pointer to function(void) returning void
"gui_gtk_f.c", line 797: warning: argument #6 is incompatible with 
prototype:
prototype: pointer to void : 
"/usr/include/glib-2.0/gobject/gsignal.h", line 431
argument : pointer to function(void) returning void
"gui_beval.c", line 522: warning: argument #6 is incompatible with 
prototype:
prototype: pointer to void : 
"/usr/include/glib-2.0/gobject/gsignal.h", line 431
argument : pointer to function(void) returning void
"gui_beval.c", line 536: warning: argument #6 is incompatible with 
prototype:
prototype: pointer to void : 
"/usr/include/glib-2.0/gobject/gsignal.h", line 431
argument : pointer to function(void) returning void

Frankly, it seems like it's a gtk/glib mismatch, since all the mechanism
comes from those headers: GTK_SIGNAL_FUNC is G_CALLBACK, which just casts
its argument to GCallback, which is the function pointer mentioned above,
while the function prototype for gtk_signal_disconnect_by_func() takes a
gpointer, which is the void *.

glib is 2.46, gtk3 is 3.18.

I don't see this in the travis logs, but I can't tell from there what
versions of glib and gtk are in use.

Does this look familiar to anyone?

Thanks,
Danek

-- 
-- 
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: error in test_startup_utf8

[Danek Duvall]

On Thu, Aug 18, 2016 at 07:39:21PM -0700, Ken Takata wrote:

> > I spent a bit of time debugging.  The problem is that after the iconv()
> > call fails, vim tries to rewind the file and the lseek() fails with ESPIPE.
> > The file created by <() ends up being a character device in /dev/fd (for
> > both bash and zsh), but the seek fails anyway, probably because the
> > underlying mechanism really is a pipe.
> 
> No, it's not the expected behavior.  lseek() should not be called when opening
> <().  It might happen when failing to detect a pipe.

Indeed, that's what's happening.  Like I said, the file that open_buffer()
stats is a character device, not a FIFO, and not a pipe.  So read_fifo
never gets set to TRUE, and readfile() thinks its okay to lseek().

I was focused on readfile() when looking at this yesterday, and completely
ignored its arguments or its caller, which probably would have gotten me to
make the "character device" portion of my message a bit more prominent.

> > As the zsh manpage suggests, this really isn't expected to work:
> > 
> > If =(...) is used instead of <(...), then the file passed as an
> > argument will be the name of a temporary file containing the output of
> > the list process.  This may be used instead of the < form for a program
> > that expects to lseek (see lseek(2)) on the input file.
> > 
> > [ ... ] In both cases [/dev/fd and FIFO implementations of <()], the
> > shell actually supplies the information using a pipe, so that
> > programmes that expect to lseek (see lseek(2)) on the file will not
> > work.
> > 
> > So it seems to me that the test is broken (though I'm not sure how to fix
> > it).
> 
> The test is not broken (at least on Linux and Cygwin.)

Right.  Because on Linux,

$ stat -L -c %F <(echo hi)
fifo

while on Solaris,

$ stat -L -c %F <(echo hi)
character special file

> Please check the patch 7.4.2189 if you want to know the purpose of the test.

I can see that.  What's not clear to me is whether the test is broken
because it assumes that the <() construct will create a FIFO, or whether
the code is broken because it doesn't test for a character device.  If I
explicitly create a FIFO with mkfifo and edit that with vim, then the right
thing happens for me.

So here's a change that will allow /dev/fd paths to be read as if they were
FIFOs, and allows the existing tests to pass for me.

diff --git a/src/buffer.c b/src/buffer.c
index 4f68882..ce0bb35 100644
--- a/src/buffer.c
+++ b/src/buffer.c
@@ -220,6 +220,11 @@ open_buffer(
 # ifdef S_ISSOCK
  || S_ISSOCK(perm)
 # endif
+# ifdef S_ISCHR
+ || (S_ISCHR(perm) &&
+!STRNCMP(curbuf->b_ffname, "/dev/fd/", 8) &&
+STRLEN(curbuf->b_ffname) > 8)
+# endif
))
read_fifo = TRUE;
if (read_fifo)

I can try to cons up a test that explicitly uses mkfifo to test fifo input,
but I'm not sure how to explicitly use a /dev/fd device.

Thanks,
Danek

-- 
-- 
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: error in test_startup_utf8

[Danek Duvall]

On Wed, Aug 17, 2016 at 05:24:27PM -0700, Ken Takata wrote:

> Hi,
> 
> 2016/8/18 Thu 5:36:51 UTC+9 Danek Duvall wrote:
> > On Wed, Aug 17, 2016 at 09:52:12PM +0200, Bram Moolenaar wrote:
> > 
> > > Danek Duvall wrote:
> > > 
> > > > I'm seeing this.  It's on Solaris, but I'm not sure whether that 
> > > > matters,
> > > > or if it does, what aspect does.
> > > > 
> > > > From test_startup_utf8.vim:
> > > > Found errors in Test_read_fifo_utf8():
> > > > function RunTheTest[9]..Test_read_fifo_utf8 line 24: Expected 
> > > > ['テスト', '€ÀÈÌÒÙ'] but got []
> > > > 
> > > > When I run the RunVim command standalone:
> > > > 
> > > > ../vim -f -u NONE -U NONE --noplugin --not-a-term --cmd "so b" 
> > > > <(cat Xtestin)
> > > > 
> > > > I do in fact get nothing in the buffer, and a warning in the status line
> > > > 
> > > > "/dev/fd/12" [character special][converted][READ ERRORS] 0 lines, 0 
> > > > characters
> > > > 
> > > > I get the same thing if I remove cp932 from fencs and add ascii, but 
> > > > latin1
> > > > gives me something, at least.  Aren't errors in conversion supposed to 
> > > > be
> > > > ignored and move vim on to the next entry in fencs, or am I
> > > > misunderstanding that whole thing?
> > > 
> > > It is supposed to work.  No idea why it fails in your situation.
> > > Would require debugging (or adding some printf's).
> > 
> > Hm.  Any suggestions on where to start?  Am I right that it should try to
> > convert from cp932, fail, and then try utf8?  Is there anything I can do
> > with the iconv command that could demonstrate that there's something wrong
> > with iconv on the system?
> 
> Does Solaris have S_ISFIFO()?  If not, it might happen.
> Could you try the attached patch?

No, Solaris isn't that backwards.  :)  I tried the patch anyway, just in
case, but no.

I spent a bit of time debugging.  The problem is that after the iconv()
call fails, vim tries to rewind the file and the lseek() fails with ESPIPE.
The file created by <() ends up being a character device in /dev/fd (for
both bash and zsh), but the seek fails anyway, probably because the
underlying mechanism really is a pipe.

As the zsh manpage suggests, this really isn't expected to work:

If =(...) is used instead of <(...), then the file passed as an
argument will be the name of a temporary file containing the output of
the list process.  This may be used instead of the < form for a program
that expects to lseek (see lseek(2)) on the input file.

[ ... ] In both cases [/dev/fd and FIFO implementations of <()], the
shell actually supplies the information using a pipe, so that
programmes that expect to lseek (see lseek(2)) on the file will not
work.

So it seems to me that the test is broken (though I'm not sure how to fix
it).

Danek

-- 
-- 
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: error in test_startup_utf8

[Danek Duvall]

On Wed, Aug 17, 2016 at 09:52:12PM +0200, Bram Moolenaar wrote:

> Danek Duvall wrote:
> 
> > I'm seeing this.  It's on Solaris, but I'm not sure whether that matters,
> > or if it does, what aspect does.
> > 
> > From test_startup_utf8.vim:
> > Found errors in Test_read_fifo_utf8():
> > function RunTheTest[9]..Test_read_fifo_utf8 line 24: Expected ['テスト', 
> > '€ÀÈÌÒÙ'] but got []
> > 
> > When I run the RunVim command standalone:
> > 
> > ../vim -f -u NONE -U NONE --noplugin --not-a-term --cmd "so b" <(cat 
> > Xtestin)
> > 
> > I do in fact get nothing in the buffer, and a warning in the status line
> > 
> > "/dev/fd/12" [character special][converted][READ ERRORS] 0 lines, 0 
> > characters
> > 
> > I get the same thing if I remove cp932 from fencs and add ascii, but latin1
> > gives me something, at least.  Aren't errors in conversion supposed to be
> > ignored and move vim on to the next entry in fencs, or am I
> > misunderstanding that whole thing?
> 
> It is supposed to work.  No idea why it fails in your situation.
> Would require debugging (or adding some printf's).

Hm.  Any suggestions on where to start?  Am I right that it should try to
convert from cp932, fail, and then try utf8?  Is there anything I can do
with the iconv command that could demonstrate that there's something wrong
with iconv on the system?

Thanks,
Danek

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

[Danek Duvall]

On Thu, Jul 21, 2016 at 10:16:22AM +0200, Bram Moolenaar wrote:

> Danek Duvall wrote:
>
> > There seem to be issues when running the test in the C locale.  I'm getting
> > a bunch of lines like the following (copy/pasted, so somewhat corrupted):
> > 
> > function RunTheTest[9]..Test_digraphs line 5: Expected '¿' but got 'â'
> > function RunTheTest[9]..Test_digraphs line 10: Expected 'þ' but got 'þ'
> > 
> > (depending on whether I view test.log in utf8 or latin1, one or the other
> > will be correct).
> > 
> > If I put "set encoding=utf-8" right before the "scriptencoding" line (like
> > many other tests do), it works.
> 
> Thanks for checking that.  I suspect that the switching back and forth
> messes up the stored text.  I have sent out a patch to run this test
> separately.

Works for me; thanks!

> We might want to set 'encoding' to utf-8 always, and only run specific
> tests with a different encoding, instead of leaving it to the system
> default.

Certainly sounds reasonable to me.

Danek

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

[Danek Duvall]

Bram Moolenaar wrote:

> Hisashi Fujinaka wrote:
> 
> > On Wed, 20 Jul 2016, Bram Moolenaar wrote:
> > 
> > >
> > > Patch 7.4.2084
> > > Problem:New digraph test makes testing hang.
> > > Solution:   Don't set "nocp".
> > > Files:  src/testdir/test_digraph.vim
> > 
> > This is breaking things on MacOS. Do you need a log file?
> 
> Well, the test is passing for me.  Better is if you can make it pass.
> Try commenting-out some lines (or nearly all the lines) to see what
> causes the problem.

There seem to be issues when running the test in the C locale.  I'm getting
a bunch of lines like the following (copy/pasted, so somewhat corrupted):

function RunTheTest[9]..Test_digraphs line 5: Expected '¿' but got 'â'
function RunTheTest[9]..Test_digraphs line 10: Expected 'þ' but got 'þ'

(depending on whether I view test.log in utf8 or latin1, one or the other
will be correct).

If I put "set encoding=utf-8" right before the "scriptencoding" line (like
many other tests do), it works.

Thanks,
Danek

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

ACLs disappearing on write on ZFS/Solaris

[Danek Duvall]

ZFS datasets on Solaris (maybe others?) have this nifty little property
called "aclmode", which is set to "discard" by default[1].  That means that
when calling chmod() on a file, any non-trivial ACL gets removed.  In
buf_write(), we almost always call mch_setperm(), causing that to happen.
If a user has backupcopy=no, then the ACL is restored, but if it's set to
yes, then vim skips the restoration.

I'm not sure how targeted the fix should be, but the attached patch seems
reasonable.  We could keep track of whether mch_setperm() had been called
previously, but maybe that's overkill for something (not calling it) that's
very unlikely to happen.

[1] http://docs.oracle.com/cd/E23824_01/html/821-1462/zfs-1m.html

Thanks,
Danek

-- 
-- 
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.
diff --git a/src/fileio.c b/src/fileio.c
index 1ceeaa7..f4fcc98 100644
--- a/src/fileio.c
+++ b/src/fileio.c
@@ -4708,7 +4708,14 @@ restore_backup:
 #ifdef HAVE_ACL
 /* Probably need to set the ACL before changing the user (can't set the
  * ACL on a file the user doesn't own). */
+/* On Solaris, with ZFS and the aclmode property set to "discard" (the
+ * default, chmod() discards all part of a file's ACL that don't represent
+ * the mode of the file.  It's non-trivial for us to discover whether we're
+ * in that situation, so we simply always re-set the ACL.
+ */
+#ifndef HAVE_SOLARIS_ZFS_ACL
 if (!backup_copy)
+#endif
mch_set_acl(wfname, acl);
 #endif
 #ifdef FEAT_CRYPT

Re: core dumps during signal handling

[Danek Duvall]

On Fri, Jun 10, 2016 at 07:49:30PM +0200, Bram Moolenaar wrote:

> Thanks for the stack trace.  I'll make a patch to block autocommands in
> deathtrap(), that should avoid this crash.  Obviously it won't exit
> completely cleanly, but that's very difficult to avoid.

True.  Though in the case of TERM or HUP, things are definitely
recoverable, at least as compared to things like SEGV.  Still, crashing in
the middle of cleanup is probably the worst of all worlds.  :)

> It depends on where the program was when the signal was received.  E.g.,
> if it happens inside free() then any memory allocation can fail.  And
> it's difficult to flush swap files without any memory allocation.
> That's why Vim handles multiple deadly signals.

Right.  And that's why I went down the road of returning from the signal
handler to do all those messy things in the normal execution context, but
then getting out as soon as possible.

Thanks,
Danek

-- 
-- 
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: core dumps during signal handling

[Danek Duvall]

On Thu, Jun 09, 2016 at 10:53:16PM +0200, Bram Moolenaar wrote:

> Danek Duvall wrote:
> 
> > I've been chasing down a bug in vim, where killing vim (usually via SIGHUP
> > or SIGTERM) causes it to get a SIGSEGV and dump core.  I'm doing my work on
> > Solaris, but I can get it to do the same thing on Ubuntu 14.04, so it's not
> > strictly a Solaris thing.
> 
> Hmm, killing Vim is likely to cause damage.  Vim tries to exit cleanly,
> but that is not so easy.
> 
> > Most reproducibly (for me, at least), it seems to be due to the BufWinLeave
> > autocommand that fugitive sets up.  That would make sense to me -- running
> > autocommands in a signal handler seems to me like it would be inherently
> > difficult to get right, and certainly not generically possible.
> 
> Does this work perhaps happen on the signal stack?  It's not unlikely it
> just runs out of stack.

Bingo.  We're running on the alternate stack, but its's just not big
enough.  Here's the stack from a recent core:

000649eb7170 get_func_tv+0x17()
000649eb7210 eval7+0x399()
000649eb72f0 eval6+0x30()
000649eb7440 eval5+0x2d()
000649eb75b0 eval4+0x2b()
000649eb76b0 eval3+0x2b()
000649eb77c0 eval2+0x30()
000649eb7810 eval1+0x24()
000649eb7a40 get_func_tv+0xa5()
000649eb7ae0 eval7+0x399()
000649eb7bc0 eval6+0x30()
000649eb7d10 eval5+0x2d()
000649eb7e80 eval4+0x2b()
000649eb7f80 eval3+0x2b()
000649eb8090 eval2+0x30()
000649eb80e0 eval1+0x24()
000649eb8310 get_func_tv+0xa5()
000649eb83b0 eval7+0x399()
000649eb8490 eval6+0x30()
000649eb85e0 eval5+0x2d()
000649eb8750 eval4+0x2b()
000649eb8850 eval3+0x2b()
000649eb8960 eval2+0x30()
000649eb89b0 eval1+0x24()
000649eb8a30 ex_execute+0x80()
000649eb8ba0 do_one_cmd+0x1b1b()
000649eb9170 do_cmdline+0x9b4()
000649eb9340 apply_autocmds_group+0x82c()
000649eb9360 apply_autocmds+0x1e()
000649eb9380 vim`getout+0xba()
000649eb9390 libc.so.1`__sighndlr+6()
000649eb9430 libc.so.1`call_user_handler+0x2f1()
000649eb9460 libc.so.1`sigacthandler+0xde(f, 0, 649eb9480)
80d396e4ec60 libc.so.1`__pollsys+0xa()
80d396e4ecf0 libc.so.1`pselect+0x193()
80d396e4ed10 libc.so.1`select+0x6b()
80d396e52d80 RealWaitForChar+0x200()

So it's clearly on the alternate stack, but the difference between the base
of that stack and the top is well over the default SIGSTKSZ (8192).  I'm
not sure how to get the information from the core that it died because it
blew the stack, but it seems entirely reasonable.  I set ss_size to 10 *
SIGSTKSZ, and it worked.

It's not the case for all the cores I have, though.  For instance,

000de03ee050 libc.so.1`_ndoprnt_s+0x1a()
000de03ee080 libc.so.1`_ndoprnt+0x12()
000de03ee140 libc.so.1`vsnprintf+0xad()
000de03ee210 libc.so.1`vasprintf+0x43()
000de03ee2f0 libc.so.1`asprintf+0x9c()
000de03ee360 libc.so.1`checkit+0x3f()
000de03ee410 libc.so.1`fallback+0x28e()
000de03ee500 libc.so.1`locale_fallback+0x126()
000de03eeb30 libc.so.1`_real_gettext_u_l+0x538()
000de03eeb90 libc.so.1`_real_gettext_u+0x49()
000de03eebc0 libc.so.1`gettext+0x6b()
000de03eec20 auto_next_pat+0x154()
000de03eed50 apply_autocmds_group+0x5ec()
000de03eeda0 apply_autocmds+0x47()
000de03eedf0 vim`getout+0x12e()
000de03eee10 preserve_exit+0x105()
000de03eee40 vim`deathtrap+0x202()
000de03eee50 libc.so.1`__sighndlr+6()
000de03eeef0 libc.so.1`call_user_handler+0x2f1()
000de03eef20 libc.so.1`sigacthandler+0xde(f, 0, de03eef40)

has a much smaller stack, well within the 8k.  But it's calling unsafe
functions (I think).  I also have a bunch of stacks that have nfa_regmatch
and mch_breakcheck at the top with a <8k stack.  I'm not sure what's going
on there.  And I'm not sure how I got into those situations.

> > The thought I have was to do the classic thing where the signal handler
> > sets a global flag and returns immediately.
> > [ ... ]
> 
> This might work better when actually waiting for a character, but it
> makes Vim completely ignore the signal when it's looping somewhere.
> Which would be the reason to send it a signal in the first place.

True.

> We could set a flag that indicates Vim is waiting for a character, and
> the signal will be handled there.  Still need to find a way to wake up
> that loop.  And the problem would still exist when not waiting for a
> character (which I would assume is the more common situation where you
> want to kill Vim).  Thus it won't help much.
> 
> It's possible to at least ignore autocommands when receiving a deadly
> sig

core dumps during signal handling

[Danek Duvall]

I've been chasing down a bug in vim, where killing vim (usually via SIGHUP
or SIGTERM) causes it to get a SIGSEGV and dump core.  I'm doing my work on
Solaris, but I can get it to do the same thing on Ubuntu 14.04, so it's not
strictly a Solaris thing.

Most reproducibly (for me, at least), it seems to be due to the BufWinLeave
autocommand that fugitive sets up.  That would make sense to me -- running
autocommands in a signal handler seems to me like it would be inherently
difficult to get right, and certainly not generically possible.

It's running the autocommands from the the HUP/TERM handler, doing
something unsafe, and getting a SIGSEGV.  If my understanding of the code
is correct, the design is to handle the SEGV, try cleaning up again (but
skipping the autocommands this time), and if anything goes wrong, rely on
getting another SEGV, and really quitting at that point.  Is my
understanding of that correct?  But (at least on Solaris), that second SEGV
isn't caught; it just gets delivered, and we get the coredump.

One complication seems to be that if I compile with optimization (-xO4 on
the Studio compilers), then it doesn't seem to catch even the first SEGV,
but just dumps core somewhere in the middle of handling the HUP/TERM.  If I
turn off optimization and turn on debugging, then it works as intended,
modulo that the secondary SEGV isn't caught.  I have some more work to do
to figure out why the compilation flags make a difference here.

We could try to make this secondary SEGV handling async-signal-safe, but
that seems to me like it's just trying to polish an inherently broken
design.

The thought I have was to do the classic thing where the signal handler
sets a global flag and returns immediately.  For the majority of the cases
I've seen, the loop in RealWaitForChar is where the signal hits anyway, so
checking for that flag there would be easy, and it could call
preserve_exit() and exit quickly and sanely, even if it can't do a lot of
cleanup.  The simple (and incomplete) attached patch works for my testcase.
Other places would be harder to handle, but maybe they don't happen enough
to be worth it.

Thoughts?

Thanks,
Danek

-- 
-- 
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.
diff --git a/src/os_unix.c b/src/os_unix.c
index b4808b5..0a15073 100644
--- a/src/os_unix.c
+++ b/src/os_unix.c
@@ -1119,6 +1119,8 @@ deathtrap SIGDEFARG(sigarg)
 sprintf((char *)IObuff, "Vim: Caught deadly signal\n");
 #endif
 
+SIGRETURN;
+
 /* Preserve files and exit.  This sets the really_exiting flag to prevent
  * calling free(). */
 preserve_exit();
@@ -5775,6 +5777,8 @@ select_eintr:
 * SIGWINCH. */
if (do_resize)
handle_resize();
+   if (get_vim_var_nr(VV_DYING) >= 1)
+   preserve_exit();
 
/* Interrupted by a signal, need to try again.  We ignore msec
 * here, because we do want to check even after a timeout if

Re: RFE: support POSIX standard and developing RE's

[Danek Duvall]

On Tue, Apr 12, 2016 at 09:15:24PM +0200, Christian Brabandt wrote:

> On Di, 12 Apr 2016, L. A. Walsh wrote:
> 
> > Christian Brabandt wrote:
> > >There is https://github.com/vim/vim/issues/99
> > >You might want to check, if this works for you.
> > 
> >If vim supported posix extended RE's, then, like, say grep,
> > it could also support Perl RE's, from the PCRE library.  Perl supports
> > the "/x" to ignore whitespace for readability.  I.e. the author was saying
> > they wanted to implement some flavor of PCRE's, but really wanted the "/x"
> > feature, which would have been alot easier to do from Vim's current
> > feature set.
> 
> The thing is, Vims RE support atoms, that other RE engines do not 
> support. Think about e.g. \_. \< \%l  \%'m
> 
> That makes adding another RE engine hard.

It sounded to me like the request wasn't for a new RE engine, but a new RE
syntax, and one that would only be turned on explicitly by a flag.

Perhaps this conflicts with existing syntax, I'm not sure, but you could
say something like "//SE", which would search for the ERE "",
because the Syntax flag was set to Extended regular expression.  Similarly,
"//SP".  Those regular expressions would be handed off to the
appropriate engine (if support were available), and if those syntaxes
didn't support all the features of Vim's regular expression language, no
problem, no problem.  The person writing those expressions would know their
limitations, and not use features not available in those languages.

That's vastly different than the recent change to the new engine, where it
needed to support the same features as the old one.  And much more
tractable, I'd think.  More a matter of defining the interface and setting
appropriate expectations with regard to availability and differences from
"normal" vim regexes.

Danek

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

[Danek Duvall]

On Mon, Feb 29, 2016 at 09:38:42PM +0100, Bram Moolenaar wrote:

> 
> Danek Duvall wrote:
> 
> > Problems on Solaris after this patch, too.  At least in the compilation
> > mode I've been using, isinf is not found by autoconf (though isnan is).  So
> > we come into this section of macros.h with HAVE_ISNAN defined, but not
> > HAVE_ISINF.  Since they're both supposed to be macros in math.h, changing
> > 
> > ifndef HAVE_ISINF
> > 
> > to
> > 
> > if !defined(HAVE_ISINF) && !defined(isinf)
> > 
> > causes the compile to succeed for me, and the testsuite passes as well.
> > I've done the same thing for isnan, since it's also supposed to be a macro.
> > I've attached the patch I used.
> > 
> > I'll note that the info page on autoconf talks about isnan and isinf a bit,
> > and has a suggestion for how to deal with them.  I know there's been a
> > bunch of back-and-forth on this here, but I don't think anyone's raised
> > that source specifically.
> 
> Although this workaround would work, I think we need to fix configure.
> It currently checks for isinf and isnan without any header files, while
> the manual page says that math.h is needed and linking with -lm.
> I'll do it that way, please check after that patch if it works on your
> system.

It does, thanks.

Danek

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

[Danek Duvall]

Problems on Solaris after this patch, too.  At least in the compilation
mode I've been using, isinf is not found by autoconf (though isnan is).  So
we come into this section of macros.h with HAVE_ISNAN defined, but not
HAVE_ISINF.  Since they're both supposed to be macros in math.h, changing

ifndef HAVE_ISINF

to

if !defined(HAVE_ISINF) && !defined(isinf)

causes the compile to succeed for me, and the testsuite passes as well.
I've done the same thing for isnan, since it's also supposed to be a macro.
I've attached the patch I used.

I'll note that the info page on autoconf talks about isnan and isinf a bit,
and has a suggestion for how to deal with them.  I know there's been a
bunch of back-and-forth on this here, but I don't think anyone's raised
that source specifically.

Thanks,
Danek

-- 
-- 
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.
diff --git src/macros.h src/macros.h
index b86c479..8d287bd 100644
--- src/macros.h
+++ src/macros.h
@@ -334,10 +334,10 @@
 #define isinf(x) (!_finite(x) && !_isnan(x))
 #   endif
 #  else
-#   ifndef HAVE_ISNAN
+#   if !defined(HAVE_ISNAN) && !defined(isnan)
  static inline int isnan(double x) { return x != x; }
 #   endif
-#   ifndef HAVE_ISINF
+#   if !defined(HAVE_ISINF) && !defined(isinf)
  static inline int isinf(double x) { return !isnan(x) && isnan(x - x); }
 #   endif
 #  endif

perleval bug on 64-bit big-endian architectures

[Danek Duvall]

I ran into a problem with a perl test on sparc.  Looks like the code
pulling keys out of a dict wasn't doing the right thing when it came to
type declarations.

Basically, on a 64-bit big-endian machine like SPARC, size_t will be
64 bits, and I32 will be 32 bits.  If we pass the pointer to the 64-bit
value off to a function that is expecting a 32-bit value, then the function
will write the result (say, 3, as what happens in the test) into the lower
end of the top half of the value:

00 00 00 03 00 00 00 00

Back to the vim code, which interprets that memory again as a 64-bit value,
and sees 12 billion or so, which is definitely greater than strlen(key), so
we get the malformed key error.

On x86, this isn't a problem, since

03 00 00 00 00 00 00 00

is interpreted as 3 regardless of whether the code thinks that's the start
of a 64-bit value or a 32-bit value.  And in a 32-bit process, the
endianness wouldn't matter since size_t would be 32-bits.

Patch is attached.

Thanks,
Danek

-- 
-- 
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.
diff --git a/src/if_perl.xs b/src/if_perl.xs
index 47c9440..9ca5291 100644
--- src/if_perl.xs
+++ src/if_perl.xs
@@ -1097,7 +1097,7 @@ perl_to_vim(SV *sv, typval_T *rettv)
case SVt_PVHV:  /* dictionary */
{
HE *entry;
-   size_t  key_len;
+   I32 key_len;
char *  key;
dictitem_T *item;
SV *item2;
@@ -1121,9 +1121,9 @@ perl_to_vim(SV *sv, typval_T *rettv)
for (entry = hv_iternext((HV *)sv); entry; entry = 
hv_iternext((HV *)sv))
{
key_len = 0;
-   key = hv_iterkey(entry, (I32 *)_len);
+   key = hv_iterkey(entry, _len);
 
-   if (!key || !key_len || strlen(key) < key_len) {
+   if (!key || !key_len || strlen(key) < (size_t)key_len) {
EMSG2("Malformed key Dictionary '%s'", key && *key ? 
key : "(empty)");
break;
}

Re: Solaris needs a tiny waittime, too

[Danek Duvall]

On Fri, Feb 19, 2016 at 02:56:35PM -0800, Danek Duvall wrote:

> On Fri, Feb 19, 2016 at 11:21:46PM +0100, Bram Moolenaar wrote:
> 
> > 
> > Danek Duvall wrote:
> > 
> > > The channel tests, when run on a couple of the Solaris boxes I'm on, fail
> > > fairly consistently on anywhere from two to six tests, each with timeout
> > > errors.  If I make the same concession that we do for MacOS, then they 
> > > work
> > > consistently.
> > > 
> > > I don't like this much, since I feel like there's a race condition lurking
> > > in here somewhere, but I'm really not sure what it is -- whether it's
> > > simply a race between vim's connect() and python's listen() (though an
> > > explicit sleep in the server code immediately after server_thread.start()
> > > doesn't help much), or if there's something internal.
> > > 
> > > At any rate, the following patch works for now.
> > 
> > Thanks.  I suspect it has something to do with making the socket
> > non-blocking.  Perhaps it helps to set it back to blocking before
> > calling select()?
> 
> It doesn't.  I'll ask some of our networking gurus at work, see if anyone
> has the time to identify the issue.

The response I got was that it's working precisely as requested.  There's
no guarantee that by the time the user code gets to the select() that the
connect() will have completed in the kernel, so the fact that a zero
timeout ever works is pretty much dumb luck.

I would suggest that a zero timeout should mean a zero timeout on all
platforms, instead of being silently changed to 1ms -- even if it's not
especially useful on many or most systems -- and that the default timeout
for ch_open() should be 10ms -- long enough for any modern machine to
complete a local connection, and short enough to be invisible to a human
user.  The author of the vimscript using this can always override this to 0
if they know better, but for general cross-platform safety, it probably
should stay at the default for the local case, and probably upped for
remotes.

Danek

-- 
-- 
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: Solaris needs a tiny waittime, too

[Danek Duvall]

On Fri, Feb 19, 2016 at 11:21:46PM +0100, Bram Moolenaar wrote:

> 
> Danek Duvall wrote:
> 
> > The channel tests, when run on a couple of the Solaris boxes I'm on, fail
> > fairly consistently on anywhere from two to six tests, each with timeout
> > errors.  If I make the same concession that we do for MacOS, then they work
> > consistently.
> > 
> > I don't like this much, since I feel like there's a race condition lurking
> > in here somewhere, but I'm really not sure what it is -- whether it's
> > simply a race between vim's connect() and python's listen() (though an
> > explicit sleep in the server code immediately after server_thread.start()
> > doesn't help much), or if there's something internal.
> > 
> > At any rate, the following patch works for now.
> 
> Thanks.  I suspect it has something to do with making the socket
> non-blocking.  Perhaps it helps to set it back to blocking before
> calling select()?

It doesn't.  I'll ask some of our networking gurus at work, see if anyone
has the time to identify the issue.

> I'll use the one msec waittime for all systems for now.

Works for me.

Thanks,
Danek

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

Solaris needs a tiny waittime, too

[Danek Duvall]

The channel tests, when run on a couple of the Solaris boxes I'm on, fail
fairly consistently on anywhere from two to six tests, each with timeout
errors.  If I make the same concession that we do for MacOS, then they work
consistently.

I don't like this much, since I feel like there's a race condition lurking
in here somewhere, but I'm really not sure what it is -- whether it's
simply a race between vim's connect() and python's listen() (though an
explicit sleep in the server code immediately after server_thread.start()
doesn't help much), or if there's something internal.

At any rate, the following patch works for now.

diff --git a/src/channel.c b/src/channel.c
index 49fa8f9..7920389 100644
--- a/src/channel.c
+++ b/src/channel.c
@@ -538,7 +538,7 @@ channel_open(char *hostname, int port_in, int waittime, 
void (*close_cb)(void))
 }
 memcpy((char *)_addr, host->h_addr, host->h_length);
 
-#if defined(__APPLE__) && __APPLE__ == 1
+#if (defined(__APPLE__) && __APPLE__ == 1) || defined(__sun)
 /* On Mac a zero timeout almost never works.  At least wait one
  * millisecond. */
 if (waittime == 0)


Thanks,
Danek

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

[Danek Duvall]

On Fri, Feb 05, 2016 at 03:45:01PM -0800, Ken Takata wrote:

> Hi Bram,
> 
> 2016/2/6 Sat 6:37:07 UTC+9 Bram Moolenaar wrote:
> > Patch 7.4.1263
> > Problem:ch_open() hangs when the server isn't running.
> > Solution:   Add a timeout. Use a dict to pass arguments. (Yasuhiro 
> > Matsumoto)
> > Files:  runtime/doc/eval.txt, runtime/doc/channel.txt, src/channel.c,
> > src/eval.c, src/netbeans.c, src/os_win32.c, 
> > src/proto/channel.pro,
> > src/testdir/test_channel.vim
> 
> I found some typos in the document:
> 
> --- a/runtime/doc/channel.txt
> +++ b/runtime/doc/channel.txt
> @@ -93,7 +93,7 @@ The default is zero, don't wait, which i
>  be running already.  A negative number waits forever.
>  
>  "timeout" is the time to wait for a request when blocking, using
> -ch_sendexpr().  Again in millisecons.  The default si 2000 (2 seconds).
> +ch_sendexpr().  Again in millisecons.  The default is 2000 (2 seconds).

And "millisecons" -> "milliseconds", too.  :)

Danek

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

[Danek Duvall]

On Thu, Feb 04, 2016 at 08:29:10PM +0100, Bram Moolenaar wrote:

> > That's what
> > 
> > let pid = system("./test_channel.py& echo $!")
> > ...
> > call system("kill " . pid)
> > 
> > was all about -- the script would emit the pid of the job running in the
> > shell, the vimscript would capture that, and then pass it to a kill
> > command.  That's about as precise as we can get, I think.
> 
> Unfortunately it doesn't work:
> 
> Caught exception in Test_communicate(): Vim(let):E484: Can't open file /tmp/
> vaLXnoR/0 @ function Test_communicate[1]..3_start_server, line 7
> 
> Somehow the command fails.

Huh.  It worked for me in a simpler testcase.  I can try to track this
down, but probably not until next week.

Danek

-- 
-- 
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] GTK3 GUI

[Danek Duvall]

On Thu, Feb 04, 2016 at 12:06:57PM +0200, Marius Gedminas wrote:

> I've patched vim to log all calls to gui_gtk2_draw_string() and wrote a
> small Python script to visualize the draw calls using ncurses.  Here's a
> screencast: https://asciinema.org/a/35507

Wow, that's really clever.  Thanks for sharing!

Danek

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

[Danek Duvall]

On Wed, Feb 03, 2016 at 10:40:06PM +0100, Bram Moolenaar wrote:

> 
> Danek Duvall wrote:
> 
> > On Wed, Feb 03, 2016 at 09:33:00PM +0100, Bram Moolenaar wrote:
> > > 
> > > Lcd wrote:
> > > 
> > > > On 3 February 2016, Jun T. <takimot...@kba.biglobe.ne.jp> wrote:
> > > > >
> > > > > On 2016/02/03, at 19:04, Jun T. <takimot...@kba.biglobe.ne.jp> wrote:
> > > > >
> > > > > >  call system("killall test_channel.py") this doesn't work either,
> > > > > > because the name of the process is not 'test_channel.py' but
> > > > > > 'python'.
> > > > >
> > > > > I forgot to mention that killall works on Linux. killall on Mac (and
> > > > > maybe on many non-linux systems) is not so clever.
> > > > 
> > > > pkill(1) should work on (recent) Linux, *BSD, OS-X, and Solaris.
> > > 
> > > Thanks for the hint.  "pkill --full test_channel.py" should work.
> > > I'll add a check for "pkill".  I'll assume they all have the --full
> > > argument.
> > 
> > Not on Solaris, which has just -f for that.
> 
> OK, let's use "pkill -f" then.
> 
> > Is there a reason that grabbing the pid and killing that directly wasn't
> > appropriate?  Do not all shells support $!?
> 
> We don't have the PID (yet).

That's what

let pid = system("./test_channel.py& echo $!")
...
call system("kill " . pid)

was all about -- the script would emit the pid of the job running in the
shell, the vimscript would capture that, and then pass it to a kill
command.  That's about as precise as we can get, I think.

Danek

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

[Danek Duvall]

On Wed, Feb 03, 2016 at 09:33:00PM +0100, Bram Moolenaar wrote:

> 
> Lcd wrote:
> 
> > On 3 February 2016, Jun T.  wrote:
> > >
> > > On 2016/02/03, at 19:04, Jun T.  wrote:
> > >
> > > >  call system("killall test_channel.py") this doesn't work either,
> > > > because the name of the process is not 'test_channel.py' but
> > > > 'python'.
> > >
> > > I forgot to mention that killall works on Linux. killall on Mac (and
> > > maybe on many non-linux systems) is not so clever.
> > 
> > pkill(1) should work on (recent) Linux, *BSD, OS-X, and Solaris.
> 
> Thanks for the hint.  "pkill --full test_channel.py" should work.
> I'll add a check for "pkill".  I'll assume they all have the --full
> argument.

Not on Solaris, which has just -f for that.

Is there a reason that grabbing the pid and killing that directly wasn't
appropriate?  Do not all shells support $!?

Danek

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

[Danek Duvall]

On Thu, Feb 04, 2016 at 12:00:00AM +0100, Bram Moolenaar wrote:

> > That's what
> > 
> > let pid = system("./test_channel.py& echo $!")
> > ...
> > call system("kill " . pid)
> > 
> > was all about -- the script would emit the pid of the job running in the
> > shell, the vimscript would capture that, and then pass it to a kill
> > command.  That's about as precise as we can get, I think.
> 
> Nice solution.  Does that $! work with every shell?

Doesn't work with the very old csh on Solaris.  Tcsh supports it, as do
bash, zsh, and ksh (88 & 93).  No idea when it was introduced in each,
though if ksh88 has it, I suspect all the bourne shell derivatives do,
except maybe the original bourne shell itself.

I'm guessing that pretty much everyone using an operating system that has
pkill available will be using a shell with $!, except maybe some csh users.
Csh users can be really, really stubborn.  :)

But that's just a guess.

Danek

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

[Danek Duvall]

On Wed, Feb 03, 2016 at 02:14:14PM +0100, Bram Moolenaar wrote:

> 
> Jun Takimoto wrote:
> 
> > On 2016/02/03, at 7:23, Bram Moolenaar  wrote:
> > 
> > > Patch 7.4.1246
> > > Problem:The channel functionality isn't tested.
> > > Solution:   Add a test using a Python test server.
> > 
> > The Python test server doesn't quit and keeps running after the
> > test (at least on my Mac, OSX 10.8.5, Python2.7).
> > 
> > In test_channel.py, line 76:
> > sys.exit(0)
> > it seems this terminates only the current thread.
> > 
> > # and it may raise the SystemExit exception. If I run
> > # $ make check 2>&1 | tee testlog
> > # then the shell hangs, but this may due to my shell's settings.
> > 
> > Moreover, in test_channel.vim, line 52:
> >   call system("killall test_channel.py")
> > this doesn't work either, because the name of the process is
> > not 'test_channel.py' but 'python'. But of course we don't
> > want to call 'killall python'.
> > 
> > A possible patch for test_channel.py is attached below.
> > On my Mac it seems to work.
> > 
> > I don't know how to fix the killall. Without this, the python
> > process will keep running if something goes wrong and shutdown
> > fails.
> 
> Yes, the killall does not appear to work reliably.  It does work for my
> specific setup.  I wonder if there is a portable way (on Unix) to kill
> the process.  We'll also need it once we add commands to start and stop
> jobs.

LCD mentioned pkill, which at least exists on other OSes.  But if for
whatever reasons (multiple tests running in parallel?) there are other
test_channel.py processes running on the machine, you'll just kill them
all.

I think the most reliable thing to do here is to have a way to know the pid
and kill it directly, but since ! goes through a shell, you don't have any
way of knowing what the pid of test_channel.py is.

I think having a spawn() function (and a kill()) would probably the best
answer for this, but perhaps for now, maybe do something like

let pid = system("./test_channel.py& echo $!")
...
call system("kill " . pid)

Danek

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

[Danek Duvall]

On Fri, Nov 20, 2015 at 03:35:08PM -0800, h_east wrote:

> Appveyor test94 FAILED in this version or later. 
> https://ci.appveyor.com/project/chrisbra/vim
> 
> Test passed on Linux.  Only Appveyor faild.

I'm seeing this failure (I think) on Solaris, but the key is to run the
test with LC_ALL=C.  If I run the test in en_US.UTF-8, it passes just fine.
Here's the diff:

--- test94.ok   Fri Nov 20 14:49:08 2015
+++ test94.failed   Fri Nov 20 15:49:51 2015
@@ -115,7 +115,7 @@
 
 gv in exclusive select mode after operation
 zzz 
-xxx 
+xxxっ 
 ---
 
 gv in exclusive select mode without operation

Thanks,
Danek

-- 
-- 
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: Moving to github

[Danek Duvall]

On Fri, Aug 14, 2015 at 09:48:53AM +0200, Christian Brabandt wrote:

 Hi Bram!
 
 On Do, 13 Aug 2015, Bram Moolenaar wrote:
 
  Then, I want to check in a change to Google code only, that produces an
  error when trying to build that version.  This is because there is no
  way to stop the Mercurial repository from serving, users who simply pull
  there won't notice anything wrong (except not getting any more updates).
  So you would need to halt your update script before that happens, and
  sync from github.  This *should* have the same version history then.
 
 I already sync from github ;)
 
 But if you check in an error to google code, that means, users won't be 
 able to just switch the repository URL, because a commit would be 
 missing? Can't we just keep the Google Code repository alone? It will be 
 closed in January anyhow, so users should notice 4 month later when the 
 urls won't work anymore.

You'd have two heads on the default branch initially -- the error head
that's at tip on google code, and the first real changeset after the switch
on bitbucket -- but you could merge the error head back in to the main
stream in the bitbucket repo so that anyone who pulled the google code
repo, got the error, switched repos, and updated would be back on track.

I think the build error is rather clever.

Danek

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

#define SOLARIS

[Danek Duvall]

The following lives in os_unix.h:

/*
 * Sun defines FILE on SunOS 4.x.x, Solaris has a typedef for FILE
 */
#if defined(sun)  !defined(FILE)
# define SOLARIS
#endif

That may or may not be useful anymore, but SOLARIS is nowhere else to be
found in the source.  We recently noticed that this caused the vim build to
fail when paired with Python, which has

#ifdef SOLARIS
/* Unchecked */
extern int gethostname(char *, int);
#endif

in pyport.h, and that declaration is at odds with the official declaration
in unistd.h.

While the declaration in pyport.h is incorrect and needs to be removed, it
seems that the #define in os_unix.h should be removed, too.

Any objections?

Thanks,
Danek

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

[Danek Duvall]

On Wed, Jul 02, 2014 at 08:01:04PM +0200, Bram Moolenaar wrote:

 
 Patch 7.4.353
 Problem:'breakindent' doesn't work with the 'list' option.
 Solution:   Make it work. (Christian Brabandt)
 Files:runtime/doc/options.txt, src/charset.c, src/screen.c,
   src/testdir/Make_amiga.mak, src/testdir/Make_dos.mak,
   src/testdir/Make_ming.mak, src/testdir/Make_os2.mak,
   src/testdir/Make_vms.mms, src/testdir/Makefile,
   src/testdir/test_listlbr.in, src/testdir/test_listlbr.ok

When the tests are run with LC_ALL=C, this test fails, apparently because
test_listlbr.out ends up having converted the various unicode characters to
something other than utf-8, and so it doesn't match the .ok file.  AFAICT,
this is the only test with that problem (at least, it's the only test that
fails for me).

Running the tests in a utf-8 locale isn't really an option for me, but I'm
not sure what the right answer actually is.  Should the test be modified to
not require fancy unicode characters, or should the test suite be sure to
run this particular test to force utf-8 encoding (assuming the system is
even configured with it)?  Or is there some other option?

Thanks,
Danek

-- 
-- 
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: Compile error in Vim 7.4.324 on Solaris

[Danek Duvall]

Ben Fritz wrote:

 Thanks, that got me further. But the build still fails:
 
 OLD_PO_FILE_INPUT=yes gmsgfmt -v -o pl.mo pl.po
 headerfield `Language-Team' missing in header
 found 1 fatal errors
 *** Error code 1
 make: Fatal error: Command failed for target `pl.mo'

No idea; that doesn't happen for me.  I'm using GNU gettext 0.16.1, FWIW.

Danek

-- 
-- 
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: Compile error in Vim 7.4.324 on Solaris

[Danek Duvall]

On Tue, Jun 17, 2014 at 12:34:25PM -0500, Benjamin Fritz wrote:

 On Tue, Jun 17, 2014 at 10:45 AM, Danek Duvall duv...@comfychair.org wrote:
  Ben Fritz wrote:
 
  Thanks, that got me further. But the build still fails:
 
  OLD_PO_FILE_INPUT=yes gmsgfmt -v -o pl.mo pl.po
  headerfield `Language-Team' missing in header
  found 1 fatal errors
  *** Error code 1
  make: Fatal error: Command failed for target `pl.mo'
 
  No idea; that doesn't happen for me.  I'm using GNU gettext 0.16.1, FWIW.
 
 
 I can't tell what version of gettext I have, in /usr/bin/gettext,
 because it isn't respecting any of -v, --version, -h, or --help.

Right; that's the Solaris version.

 I do have GNU gettext 0.10.35 as ggettext but I don't see a way to
 override gettext like you showed me with msgfmt.

You don't need to, you just need to override msgfmt with gmsgfmt, which you
did.

I'm guessing that 0.10.35 is just too old, in which case you don't have any
good options, with the Solaris version unable to handle the corrupt Chinese
.po file and the GNU version unable to deal with the missing header in the
Polish ones.

You could either get a newer version of GNU gettext, edit the
Polish .po files to add the header (any value ought to do), or edit the
cp936 .po file to remove the bad bytes.

 So what did I cripple by using --disable-nls? Did that just remove
 the translations or something?

That's what it's intended to do, yeah.

Danek

-- 
-- 
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: Compile error in Vim 7.4.324 on Solaris

[Danek Duvall]

On Mon, Jun 16, 2014 at 10:35:37AM -0500, Benjamin Fritz wrote:

 I get this error from both make and make install when building on Solaris:
 
 Processing file zh_CN.cp936.po...
 ERROR: Line 2899 (zh_CN.cp936.po): Invalid character found.
 *** Error code 2
 make: Fatal error: Command failed for target `zh_CN.cp936.mo'

This has been the case since 7.4.296.  As of 7.4.322, you can work around
it with GNU msgfmt, by putting MSGFMT=gmsgfmt in the environment when
running configure, assuming you have GNU gettext (text/gnu-gettext on S11
or later) installed.  Or just make sure that the first msgfmt in your
$PATH is GNU.

Danek

-- 
-- 
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: illegal encoding in zh_CN.cp936.po

[Danek Duvall]

Bram Moolenaar wrote:

 Danek Duvall wrote:
 
  I've applied the attached patch to my build, and just set MSGFMT=gmsgfmt in
  the environment when I run configure.  It's yours if you want it, since it
  seems like a decent addition to the configurability of the build.  It's not
  complete, though, since it doesn't handle xgettext and msgmerge, but I
  don't need to run either one as a part of a typical build, and the latter
  at least doesn't have a Solaris native version, so we'd end up using the
  GNU version anyway.
 
 Thanks.  It's not clear to me how this solves the illegal encoding
 problem though.

It doesn't; it just lets me work around it.

 Looks like in po/Makefile you could have just changed msgfmt to
 $(MSGFMT).

I could have, though a) I wasn't sure if various makes would pass it down
to sub-invocations properly, and b) configure was checking for msgfmt, but
never actually using it (as far as I could tell), so I figured that this
was a piece of configuration that someone simply forgot to hook up.

Thanks,
Danek

-- 
-- 
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: illegal encoding in zh_CN.cp936.po

[Danek Duvall]

I've applied the attached patch to my build, and just set MSGFMT=gmsgfmt in
the environment when I run configure.  It's yours if you want it, since it
seems like a decent addition to the configurability of the build.  It's not
complete, though, since it doesn't handle xgettext and msgmerge, but I
don't need to run either one as a part of a typical build, and the latter
at least doesn't have a Solaris native version, so we'd end up using the
GNU version anyway.

Thanks,
Danek

-- 
-- 
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.
--- src/config.mk.in.orig   Thu May 22 12:22:19 2014
+++ src/config.mk.inMon Jun  2 14:00:42 2014
@@ -164,6 +164,8 @@
 ### If the *.po files are to be translated to *.mo files.
 MAKEMO = @MAKEMO@
 
+MSGFMT = @MSGFMT@
+
 # Make sure that make first will run make all once configure has done its
 # work.  This is needed when using the Makefile in the top directory.
 first: all
--- src/po/Makefile.origThu May 22 12:22:19 2014
+++ src/po/Makefile Mon Jun  2 14:02:33 2014
@@ -1,5 +1,7 @@
 # Makefile for the Vim message translations.
 
+include ../auto/config.mk
+
 # TODO make this configurable
 # Note: ja.sjis, *.cp1250 and zh_CN.cp936 are only for MS-Windows, they are
 # not installed on Unix
@@ -133,7 +135,7 @@
 # tools 0.10.37, which use a slightly different .po file format that is not
 # compatible with Solaris (and old gettext implementations) unless these are
 # set.  gettext 0.10.36 will not work!
-MSGFMT = OLD_PO_FILE_INPUT=yes msgfmt -v
+# MSGFMT = OLD_PO_FILE_INPUT=yes msgfmt -v
 XGETTEXT = OLD_PO_FILE_INPUT=yes OLD_PO_FILE_OUTPUT=yes xgettext
 MSGMERGE = OLD_PO_FILE_INPUT=yes OLD_PO_FILE_OUTPUT=yes msgmerge
 
@@ -142,7 +144,7 @@
 .PHONY: all install uninstall prefixcheck converted check clean checkclean 
distclean update-po $(LANGUAGES) $(CONVERTED)
 
 .po.mo:
-   $(MSGFMT) -o $@ $
+   OLD_PO_FILE_INPUT=yes $(MSGFMT) -v -o $@ $
 
 .po.ck:
$(VIM) -u NONE -e -X -S check.vim -c if error == 0 | q | endif -c cq 
$

illegal encoding in zh_CN.cp936.po

[Danek Duvall]

After changeset 4303f7b6f72f, I'm seeing this:

OLD_PO_FILE_INPUT=yes msgfmt -v -o zh_CN.cp936.mo zh_CN.cp936.po
Processing file zh_CN.cp936.po...
GNU PO file found.
Generating the MO file in the GNU MO format.
Processing file zh_CN.cp936.po...
ERROR: Line 2899 (zh_CN.cp936.po): Invalid character found.
make[3]: *** [zh_CN.cp936.mo] Error 2

GNU msgfmt doesn't have any problems with the file, and Solaris iconv
doesn't support cp936, but on Linux, I do see

$ iconv -f cp936 -t utf8 zh_CN.cp936.po| tail  
iconv: illegal input sequence at position 65551
output

and the output abruptly terminates in the middle of the offending line.

Thanks,
Danek

-- 
-- 
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: Page on developing Vim

[Danek Duvall]

Christian Brabandt wrote:

 On Mi, 02 Apr 2014, Danek Duvall wrote:
 
  I'm in the same boat.  I've been using MQ for years and am comfortable with
  it, and haven't had the time to try out obsolescence in any serious way,
  though I'm actually quite excited about it, since I'd love to have the
  history of my patch changes for the duration of the patch.  I tried out
  pbranch several years ago, but it was just too wild, and the merges were
  horrendous.
 
 Can someone explain in little more detail how to use the new recommended 
 way to deal with patches if mq becomes un-supported?

You can start here:

http://mercurial.selenic.com/wiki/ChangesetEvolution

and the materials linked from there.  There's also

http://hg-lab.logilab.org/doc/mutable-history/html/

which includes a MQ-refugee page.

Though the interfaces MQ provides won't be removed for a long time, if
ever; the mercurial guys are very strict about backwards compatibility.

Danek

-- 
-- 
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: Page on developing Vim

[Danek Duvall]

Ben Fritz wrote:

 Does rebase integrate with MQ to set up the queue base changeset and
 such properly? I really, really don't like the idea of messing around
 with MQ changesets in this way, unless I know it works.

Yes, it resets all the MQ-specific tags to what they would have been had
you qpushed onto the new changeset.

 I saw recently on the Mercurial mailing list that MQ is planned for
 deprecation (still supported, but not recommended for new users). One of
 the suggested replacements was changeset evolution combined with
 rebase, histedit, and strip if needed. The idea was to use normal
 changesets with the secret phase on so you could use all the internal
 Mercurial machinery better. But I don't know how mature this approach
 is, and I'm having a little trouble wrapping my mind around it without
 trying it out first. I already know how to work with MQ, on the other
 hand.

I'm in the same boat.  I've been using MQ for years and am comfortable with
it, and haven't had the time to try out obsolescence in any serious way,
though I'm actually quite excited about it, since I'd love to have the
history of my patch changes for the duration of the patch.  I tried out
pbranch several years ago, but it was just too wild, and the merges were
horrendous.

Danek

-- 
-- 
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: Page on developing Vim

[Danek Duvall]

Christian Brabandt wrote:

  Secondly, I disagree that It is dangerous to pull changes from the central
  vim repository, while there are still patches applied. Pulling with patches
  applied always works just fine, the mq patches act just like real Mecurial
  changesets. What you don't want to do, is update after a pull with the
  patches still applied, because then you need to back up to a different
  changeset to unapply the patches. But even update isn't dangerous. What
  would be bad is trying to merge the upstream changes into your mq patches
  using Mercurial merge commands.
 
 Yes, that's what I meant. So, to how about this:
 
 It is dangerous to pull changes from the central vim repository and 
 update your working copy at the same time (-u flag), while there are 
 still patches applied. Instead, make sure to pop all patches, update the 
 repository and push your patches again:

You may be better off enabling the rebase extension and running hg pull
--rebase, since that will enable mercurial's merging mechanics, rather
than the qpop/qpush pair, which will (if there are conflicts) leave patch
reject files lying around, which you then need to merge manually.

It's also not at all dangerous to pull -u when there are patches applied;
the only thing that will happen is that mercurial will complain that it
won't update across heads and leave you where you are.  You can then
qpop/qpush or rebase your queue.

Danek

-- 
-- 
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: grep -F fails on Solaris

[Danek Duvall]

On Wed, Feb 26, 2014 at 04:34:15AM +0100, Bram Moolenaar wrote:

 
 Danek Duvall wrote:
 
  Now that I'm building Perl and Ruby support, I'm running into the fact that
  /usr/bin/grep on Solaris doesn't support -F.  Telling configure to find a
  version of grep that supports it, and using $FGREP takes care of the
  problem.
  
  This is a patch to configure.in; when I regenerate auto/configure, the diff
  is huge since I'm not using autoconf 2.65, so I'm not including that
  portion.
 
 Thanks.  However, the indenting messes up the patch, can you attach it
 instead?

Done.

Thanks,
Danek

-- 
-- 
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/groups/opt_out.
--- src/configure.in.orig   Tue Feb 25 13:09:51 2014
+++ src/configure.inTue Feb 25 13:11:03 2014
@@ -14,6 +14,7 @@
 AC_PROG_CC dnl required by almost everything
 AC_PROG_CPPdnl required by header file checks
 AC_PROGRAM_EGREP dnl required by AC_EGREP_CPP
+AC_PROG_FGREP  dnl finds working grep -F
 AC_ISC_POSIX   dnl required by AC_C_CROSS
 AC_PROG_AWKdnl required for make html in ../doc
 
@@ -936,7 +937,7 @@
  PERL_CFLAGS=`echo $perlcppflags | sed -e 's/-pipe //' -e 's/-W[[^ 
]]*//'`
fi
if test X$perlldflags != X; then
- if test X`echo \$LDFLAGS\ | grep -F -e \$perlldflags\` = X; 
then
+ if test X`echo \$LDFLAGS\ | $FGREP -e \$perlldflags\` = X; 
then
LDFLAGS=$perlldflags $LDFLAGS
  fi
fi
@@ -1727,7 +1728,7 @@
  dnl configure, so strip these flags first (if present)
  rubyldflags=`echo $rubyldflags | sed -e 's/-arch\ ppc//' -e 
's/-arch\ i386//' -e 's/-arch\ x86_64//'`
  if test X$rubyldflags != X; then
-   if test X`echo \$LDFLAGS\ | grep -F -e \$rubyldflags\` = X; 
then
+   if test X`echo \$LDFLAGS\ | $FGREP -e \$rubyldflags\` = X; 
then
  LDFLAGS=$rubyldflags $LDFLAGS
fi
  fi

dynamic 64-bit ruby 1.9 linking issues

[Danek Duvall]

I've been trying to get dynamic ruby support working on Solaris, with a
64-bit build of vim 7.4.192 and Ruby 1.9.  I was getting a pair of link
errors about rb_fix2int and rb_num2int, and in the course of poking around
found that the following patch seems to work:

--- src/if_ruby.c.orig  Tue Feb 25 10:14:41 2014
+++ src/if_ruby.c   Tue Feb 25 10:14:45 2014
@@ -88,7 +88,7 @@
 # define rb_int2big rb_int2big_stub
 #endif
 
-#if defined(DYNAMIC_RUBY_VER)  DYNAMIC_RUBY_VER = 20 \
+#if defined(DYNAMIC_RUBY_VER)  DYNAMIC_RUBY_VER = 19 \
 VIM_SIZEOF_INT  VIM_SIZEOF_LONG
 /* Ruby 2.0 defines a number of static functions which use rb_fix2int and
  * rb_num2int if VIM_SIZEOF_INT  VIM_SIZEOF_LONG (64bit) */
@@ -392,7 +392,7 @@
 {
 return dll_rb_int2big(x);
 }
-#  if defined(DYNAMIC_RUBY_VER)  DYNAMIC_RUBY_VER = 20 \
+#  if defined(DYNAMIC_RUBY_VER)  DYNAMIC_RUBY_VER = 19 \
 VIM_SIZEOF_INT  VIM_SIZEOF_LONG
 long rb_fix2int_stub(VALUE x)
 {

I don't know whether that's right or not, though, though our ruby.h
definitely uses rb_fix2int() and rb_num2int() in macros, which is what it
sounds like the comment suggests happened in 2.0.

I do get the following warnings, though:

if_ruby.c, line 206: warning: macro redefined: rb_fix2int
if_ruby.c, line 207: warning: macro redefined: rb_num2int

which isn't surprising, since fist they're #defined to the stub versions,
and here they're #defined to the dll_ versions.

Simple ruby tests work, so it's not all broken, but I don't know enough
Ruby to test these two functions to see if what I've done is completely
busted.

Any help would be appreciated.

Thanks,
Danek

-- 
-- 
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/groups/opt_out.

grep -F fails on Solaris

[Danek Duvall]

Now that I'm building Perl and Ruby support, I'm running into the fact that
/usr/bin/grep on Solaris doesn't support -F.  Telling configure to find a
version of grep that supports it, and using $FGREP takes care of the
problem.

This is a patch to configure.in; when I regenerate auto/configure, the diff
is huge since I'm not using autoconf 2.65, so I'm not including that
portion.

--- src/configure.in.orig   Tue Feb 25 13:09:51 2014
+++ src/configure.inTue Feb 25 13:11:03 2014
@@ -14,6 +14,7 @@
 AC_PROG_CC dnl required by almost everything
 AC_PROG_CPPdnl required by header file checks
 AC_PROGRAM_EGREP dnl required by AC_EGREP_CPP
+AC_PROG_FGREP  dnl finds working grep -F
 AC_ISC_POSIX   dnl required by AC_C_CROSS
 AC_PROG_AWKdnl required for make html in ../doc
 
@@ -936,7 +937,7 @@
  PERL_CFLAGS=`echo $perlcppflags | sed -e 's/-pipe //' -e 
's/-W[[^ ]]*//'`
fi
if test X$perlldflags != X; then
- if test X`echo \$LDFLAGS\ | grep -F -e \$perlldflags\` = 
X; then
+ if test X`echo \$LDFLAGS\ | $FGREP -e \$perlldflags\` = 
X; then
LDFLAGS=$perlldflags $LDFLAGS
  fi
fi
@@ -1727,7 +1728,7 @@
  dnl configure, so strip these flags first (if present)
  rubyldflags=`echo $rubyldflags | sed -e 's/-arch\ ppc//' -e 
's/-arch\ i386//' -e 's/-arch\ x86_64//'`
  if test X$rubyldflags != X; then
-   if test X`echo \$LDFLAGS\ | grep -F -e \$rubyldflags\` = 
X; then
+   if test X`echo \$LDFLAGS\ | $FGREP -e \$rubyldflags\` = 
X; then
  LDFLAGS=$rubyldflags $LDFLAGS
fi
  fi

Thanks,
Danek

-- 
-- 
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/groups/opt_out.

Re: Install issues Vim7.4 on Solaris 9

[Danek Duvall]

On Fri, Aug 16, 2013 at 07:06:41AM -0700, Albert Simenon wrote:

 Installed Vim7.3 without any problems on Solaris 9.
 
 However when i try to install Vim7.4 on Solaris 9 i run into issues. With 
 default configure options i get an error on 
 
 checking for sys/acl.h... (cached) yes
 [ ... ]
 checking --disable-acl argument... no
 checking for acl_get_file in -lposix1e... (cached) no
 checking for acl_get_file in -lacl... (cached) no
 checking for POSIX ACL support... no
 checking for acl_get in -lsec... (cached) yes
 checking for AIX ACL support... no
 [ ... ]
 os_unix.c: In function 'mch_get_acl':
 os_unix.c:2805:5: error: 'acl_t' undeclared (first use in this function)
 os_unix.c:2805:5: note: each undeclared identifier is reported only once for 
 each function it appears in
 os_unix.c:2805:12: error: 'aclent' undeclared (first use in this function)
 os_unix.c: In function 'mch_set_acl':
 os_unix.c:2875:29: error: 'acl_t' undeclared (first use in this function)
 os_unix.c:2875:36: error: expected expression before ')' token
 os_unix.c: In function 'mch_free_acl':
 os_unix.c:2899:15: error: 'acl_t' undeclared (first use in this function)
 os_unix.c:2899:22: error: expected expression before ')' token
 *** Error code 1
 make: Fatal error: Command failed for target `objects/os_unix.o'
 Current working directory /home/inhuur1/vim/vim74/src
 *** Error code 1
 make: Fatal error: Command failed for target `first'

This was introduced in 7.3.432.  The test does a very simple test for
whether the ACL functions are in libsec, but doesn't try compiling a more
thorough test that would also check that the types are defined.

What I don't understand, though, is why the link succeeds.  The function
acl_get() shouldn't be found in Solaris 9, as far as I can tell.  Perhaps
you built this workspace on S10 or S11 before, and that's why the value is
cached?  If that test properly fails, then it should revert to the older
UFS ACL functions on Solaris, which is probably fine, since that S9 box
won't have any ZFS or NFSv4 filesystems.

Danek

-- 
-- 
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/groups/opt_out.

Re: Python items in the todo list

[Danek Duvall]

On Wed, May 15, 2013 at 06:58:53PM +0200, Bram Moolenaar wrote:

 Patch to dynamically load Python on Solaris. (Danek Duvall, 2009 Feb 16)
 Needs more work.

I don't know that it's worth following up on this.  The current python/dyn
interface works just fine on Solaris, and while it's probably possible to
squeeze some performance out with some linker tricks, I doubt it's worth
the code complexity.

I still think it'd be great to be able to load whatever version of python
you had on your system, rather than just the one vim was built against, but
that was never part of my patch, anyway.

Oh, and I'm still seeing problems with test86 due to patch 924, which I
reported on May 7.

Thanks,
Danek

-- 
-- 
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/groups/opt_out.

Re: Python items in the todo list

[Danek Duvall]

Bram Moolenaar wrote:

 Danek Duvall wrote:
 
  On Wed, May 15, 2013 at 06:58:53PM +0200, Bram Moolenaar wrote:
  
   Patch to dynamically load Python on Solaris. (Danek Duvall, 2009 Feb 16)
   Needs more work.
  
  I don't know that it's worth following up on this.  The current python/dyn
  interface works just fine on Solaris, and while it's probably possible to
  squeeze some performance out with some linker tricks, I doubt it's worth
  the code complexity.
 
 I believe the note was about more work for the patch, not more work for
 a working interface.  If there are more improvements those are welcome,
 of course.

Sure.  I was just suggesting that it's not worth keeping that item on your
list, as I think that patch is a dead-end given the work that's been done
since on dynamic loading of other language platforms.

  Oh, and I'm still seeing problems with test86 due to patch 924, which I
  reported on May 7.
 
 There is not much I can do about that..

Okay.  I guess it's up to ZyX to provide that fix; I would, but I don't
know what the right fix is.  I suspect that changing iminsert to
tabstop would be the right start, but I don't know how to change the
expected output properly.  I'd like to see this fixed before 7.4, so that I
can deliver 7.4 with all tests passing, even if it's the test that's
broken.

Thanks,
Danek

-- 
-- 
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/groups/opt_out.

Re: Patch 7.3.924

[Danek Duvall]

I get an error in test86 with this patch.  The error diffs are:

--- test86.ok   Tue May  7 10:29:47 2013
+++ test86.failed   Tue May  7 10:35:16 2013
@@ -242,15 +242,15 @@
   wopts1! KeyError
   wopts2! KeyError
   wopts3! KeyError
-  p/bopts1: 2
+  p/bopts1: 0
   G: 1
-  W: 1:2 2:1 3:0 4:2
-  B: 1:2 2:1 3:0 4:2
+  W: 1:0 2:1 3:0 4:0
+  B: 1:0 2:1 3:0 4:0
   del wopts3! KeyError
   del bopts3! ValueError
   G: 1
-  W: 1:2 2:1 3:0 4:2
-  B: 1:2 2:1 3:0 4:2
+  W: 1:0 2:1 3:0 4:0
+  B: 1:0 2:1 3:0 4:0
  omnifunc
   p/gopts1! KeyError
   inv: 1! KeyError

but I'm not sure what to make of them.

This is with Python 2.6.8 on Solaris.

Thanks,
Danek

-- 
-- 
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/groups/opt_out.

Re: Patch 7.3.677

[Danek Duvall]

On Wed, Oct 03, 2012 at 06:25:17PM +0200, Bram Moolenaar wrote:

 
 Patch 7.3.677
 Problem:buf_spname() is used inconsistently.
 Solution:   Make the return type a char_u pointer.  Check the size of the
   returned string.
 Files:src/buffer.c, src/proto/buffer.pro, src/ex_cmds2.c,
   src/ex_docmd.c, src/memline.c, src/screen.c

This breaks for me, building on Solaris 11 with the Studio compilers, with
the following error:

edit.c, line 4196: operands have incompatible types:
 pointer to unsigned char : pointer to char


Here's a fix, though I'm not positive I tested it properly:

diff --git a/src/edit.c b/src/edit.c
--- a/src/edit.c
+++ b/src/edit.c
@@ -4194,8 +4194,8 @@ ins_compl_get_exp(ini)
ins_buf-b_fname == NULL
? buf_spname(ins_buf)
: ins_buf-b_sfname == NULL
-   ? (char *)ins_buf-b_fname
-   : (char *)ins_buf-b_sfname);
+   ? (char_u *)ins_buf-b_fname
+   : (char_u *)ins_buf-b_sfname);
(void)msg_trunc_attr(IObuff, TRUE, hl_attr(HLF_R));
}
else if (*e_cpt == NUL)

Thanks,
Danek

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

Re: vim crashes when creating a file inside a long directory

[Danek Duvall]

On Thu, Sep 20, 2012 at 09:54:05AM -0400, Charles Campbell wrote:

 Danek Duvall wrote:
 snip
 In os_unix.c, the path we trace through mch_FullName() grabs the cwd into 
 buf
 (an input parameter) with mch_dirname(), which succeeds, since it's just 
 short
 enough to fit into the 1024-byte buffer (with the trailing NUL).  We then get
 the strlen() of buf, returning 1023, as the truss output shows on line 72731.
 We then compare that value to the input parameter len, which is the size of
 buf, and since 1023 is not= 1024, we assume we can add a slash to the end,
 overwriting the end of the buffer.
 snip
 
 Shouldn't the buffer size (1024 mentioned above) be set, at least
 under unix, to a value at least as large as indicated by pathconf()?

Yeah, that's a decent idea, but non-trivial.  Looks like (at least for this
codepath) it's allocated in FullName_save() in misc1.c.  Dunno about other
possibilities, but you'd have to track them all down, as well as pass
around a buffer length, or call pathconf() again every time you need to
know the length.

It's also possible for getcwd() to return a buffer larger than MAXPATHLEN,
but handling that, particularly across different implementations, also
seemed trickier than I particularly felt like handling.

Danek

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

vim crashes when creating a file inside a long directory

[Danek Duvall]

On Solaris, at least:

$ pwd

/var/tmp/maxpath/0123456789012345678901234567890123456789012345678901234567890123456789012345678901234567890123456789012345678901234567890123456789012345678901234567890123456789012345678901234567890123456789012345678901234567890123456789012345678901234567890/0123456789012345678901234567890123456789012345678901234567890123456789012345678901234567890123456789012345678901234567890123456789012345678901234567890123456789012345678901234567890123456789012345678901234567890123456789012345678901234567890/0123456789012345678901234567890123456789012345678901234567890123456789012345678901234567890123456789012345678901234567890123456789012345678901234567890123456789012345678901234567890123456789012345678901234567890123456789012345678901234567890/0123456789012345678901234567890123456789012345678901234567890123456789012345678901234567890123456789012345678901234567890123456789012345678901234567890123456789012345678901234567890123456789012345678901234567890123456789012345678901234567890/012345678901234567890123456789/0123456
$ pwd | wc -c
1024
$ vi a
Vim: Caught deadly signal SEGV
Vim: Finished.
Segmentation Fault (core dumped)
$ vi
Segmentation Fault (core dumped)

Using truss and libumem, the problem becomes reasonably apparent.  Using

LD_PRELOAD=libumem.so.1 UMEM_DEBUG=default,verbose truss -u a.out -u libc: 
-o /tmp/vi.out vi a

I get this output:

72705 /1@1: - alist_add(0x8285804, 0x82cb428, 0x2)
72706 /1@1:   - buflist_add(0x82cb428, 0x3)
72707 /1@1: - buflist_new(0x82cb428, 0x0, 0x0, 0x3)
72708 /1@1:   - fname_expand(0x82f8e08, 0x8046ec8, 0x8046ecc)
72709 /1@1: - fix_fname(0x82cb428, 0x0)
72710 /1@1:   - FullName_save(0x82cb428, 0x1)
72711 /1@1: - alloc(0x400, 0x0)
72712 /1@1: - alloc() = 0x82d3188
72713 /1@1: - vim_FullName(0x82cb428, 0x82d3188, 0x400, 0x1)
72714 /1@1:   - path_with_url(0x82cb428, 0x0)
72715 /1@1: - libc:strncmp(0x82cb429, 0x82544b0, 0x3)
72716 /1@1: - libc:strncmp() = -1
72717 /1@1: - libc:strncmp(0x82cb429, 0x82544b4, 0x3)
72718 /1@1: - libc:strncmp() = -1
72719 /1@1:   - path_with_url() = 0
72720 /1@1:   - mch_FullName(0x82cb428, 0x82d3188, 0x400, 0x1)
72721 /1@1: - vim_strrchr(0x82cb428, 0x2f)
72722 /1@1:   - utfc_ptr2len(0x82cb428, 0x0)
72723 /1@1:   - utfc_ptr2len() = 1
72724 /1@1: - vim_strrchr() = 0
72725 /1@1: - mch_dirname(0x82d3188, 0x400)
72726 /1@1:   - libc:getcwd(0x82d3188, 0x400)
72727 /1: 
getcwd(/var/tmp/maxpath/012345678901234567890123456789012345678901234567890123456789012345678
  
901234567890123456789012345678901234567890123456789012345678901234567890123456789012345678901234567890
  
1234567890123456789012345678901234567890123456789012345678901234567890/0123456789012345678901234567890
  
123456789012345678901234567890123456789012345678901234567890123456789012345678901234567890123456789012
  
345678901234567890123456789012345678901234567890123456789012345678901234567890123456789012345678901234
  
567890/01234567890123456789012345678901234567890123456789012345678901234567890123456789012345678901234
  
567890123456789012345678901234567890123456789012345678901234567890123456789012345678901234567890123456
  
78901234567890123456789012345678901234567890/012345678901234567890123456789012345678901234567890123456
  
789012345678901234567890123456789012345678901234567890123456789012345678901234567890123456789012345678
  
9012345678901234567890123456789012345678901234567890123456789012345678901234567890/0123456789012345678
  90123456789/0123456, 1024) = 0
72728 /1@1:   - libc:getcwd() = 0x82d3188
72729 /1@1: - mch_dirname() = 1
72730 /1@1: - libc:strlen(0x82d3188, 0x0)
72731 /1@1: - libc:strlen() = 1023
72732 /1@1: - libc:strcmp(0x82cb428, 0x824d790)
72733 /1@1: - libc:strcmp() = 51
72734 /1@1: - libc:strcat(0x82d3188, 0x824d7b0)
72735 /1@1: - libc:strcat() = 0x82d3188
72736 /1@1: - libc:strlen(0x82d3188, 0x0)
72737 /1@1: - libc:strlen() = 1024
72738 /1@1: - libc:strlen(0x82cb428, 0x0)
72739 /1@1: - libc:strlen() = 1
72740 /1@1:   - mch_FullName() = 0
72741 /1@1:   - vim_strncpy(0x82d3188, 0x82cb428, 0x3ff)
72742 /1@1: - libc:strncpy(0x82d3188, 0x82cb428, 0x3ff)
72743 /1@1: - libc:strncpy() = 0x82d3188
72744 /1@1:   - vim_strncpy() = 0
72745 /1@1: - vim_FullName() = 0
72746 /1@1:

Re: vim crashes when creating a file inside a long directory

[Danek Duvall]

On Wed, Sep 19, 2012 at 11:35:59AM -0700, Ben Fritz wrote:

 What version of Vim are you using? There was a long filenames crash fixed
 recently (7.3.648), but for systems other than just Unix:

I saw that fix, but since it didn't touch the same area as my patch, I
assumed it solved a different problem.  (We first saw the problem reported
on 7.2.308, but the problem continued to reproduce into 7.3; I've been
applying the patch cleanly since 7.3.515.)

And 7.3.648 doesn't fix this problem, anyway (just rebuilt without my patch
and checked).

Thanks,
Danek

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

Re: Patch 7.3.569

[Danek Duvall]

On Sat, Jun 30, 2012 at 01:01:16PM +0200, Bram Moolenaar wrote:

  In addition to the PyCapsule problems, it appears that
  _PyObject_NextNotImplemented is not present in Python 2.6, and so when I
  try to run a python command after today's series of patches, I get
  
  E448: Could not load library function _PyObject_NextNotImplemented
  E263: Sorry, this command is disabled, the Python library could not be 
  loaded.
 
 It appears they are only used indirectly.  Thus putting them in #ifdefs
 for Python 2.7 and later should work?  Try this patch:

I pulled 7.3.583 (584 doesn't seem to be in the repo yet), and it compiles
and works just fine for me on Solaris.

Thanks!
Danek

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

Re: Patch 7.3.569

[Danek Duvall]

On Fri, Jun 29, 2012 at 12:55:10PM +0200, Bram Moolenaar wrote:

 Patch 7.3.569
 Problem:Evaluating Vim expression in Python is insufficient.
 Solution:   Add vim.bindeval().  Also add pyeval() and py3eval(). (ZyX)
 Files:runtime/doc/eval.txt, runtime/doc/if_pyth.txt, src/eval.c,
   src/if_lua.c, src/if_py_both.h, src/if_python.c, src/if_python3.c,
   src/proto/eval.pro, src/proto/if_python.pro,
   src/proto/if_python3.pro, src/testdir/Make_amiga.mak,
   src/testdir/Make_dos.mak, src/testdir/Make_ming.mak,
   src/testdir/Make_os2.mak, src/testdir/Makefile,
   src/testdir/test86.in, src/testdir/test86.ok,
   src/testdir/test87.in, src/testdir/test87.ok
 
 [ ... ]
 
 *** ../vim-7.3.568/src/if_python.c2011-08-28 16:00:14.0 +0200
 --- src/if_python.c   2012-06-29 12:47:48.0 +0200
 ***
 *** 179,186 
 --- 209,218 
   # define Py_Finalize dll_Py_Finalize
   # define Py_IsInitialized dll_Py_IsInitialized
   # define _PyObject_New dll__PyObject_New
 + # define _PyObject_NextNotImplemented (*dll__PyObject_NextNotImplemented)
   # define _Py_NoneStruct (*dll__Py_NoneStruct)
   # define PyObject_Init dll__PyObject_Init
 + # define PyObject_GetIter dll_PyObject_GetIter
   # if defined(PY_VERSION_HEX)  PY_VERSION_HEX = 0x0202
   #  define PyType_IsSubtype dll_PyType_IsSubtype
   # endif

In addition to the PyCapsule problems, it appears that
_PyObject_NextNotImplemented is not present in Python 2.6, and so when I
try to run a python command after today's series of patches, I get

E448: Could not load library function _PyObject_NextNotImplemented
E263: Sorry, this command is disabled, the Python library could not be 
loaded.

Danek

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

Re: Vim 7.3.556 dumps core when freeing memory in open_line()

[Danek Duvall]

On Tue, Jun 19, 2012 at 06:23:29PM -0700, Gary Johnson wrote:

 I don't have all the details on this at the moment, but I ran out of
 time to investigate further today.  In summary, opening a new line
 in a C comment causes Vim to dump core with various messages about
 improper freeing of memory.

I can reproduce this on Solaris 11 with 7.3.555, but not 7.3.515.  I
specifically have to use libumem (an alternate malloc implementation that's
got a bunch of debugging goodies in it), but the resulting core appears to
have the same stack.  FWIW, I only have to hit Enter once, and in fact,
simply o will do the trick.  Plus, the file need only contain // at the
beginning of the first line -- no tabs, no comment content, no second
comment line.

The umem debugging utils say it's a write past end of buffer.  Why that
would be happening on a vim_free() call, I don't know.  But umem confirms
that the buffer involved is the same one allocated on line 1058 --
leader.

Danek

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

patch: support for ZFS/NFSv4 ACLs on Solaris

[Danek Duvall]

ACLs are supported (in the sense that a non-trivial ACL on a file gets
preserved when the file is written) on UFS on Solaris, as well as on AIX,
or systems which support POSIX ACLs, but this code doesn't work on either
ZFS or NFSv4 on Solaris, which use a different ACL API.

The attached patch fixes this.  When built on a Solaris system prior to
ZFS, it uses the old interface, but on a newer system sets the ACLs
properly on ZFS, UFS, and NFS.

I don't know what the ZFS or NFSv4 ACL APIs are like on other operating
systems with those filesystems, so the names I used are Solaris specific,
but it may not take much massaging to get it to work there, too.  Perhaps
it just works there with the POSIX ACL API?

Danek

-- 
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
--- src/configure.inTue Jan 10 16:13:35 2012
+++ src/configure.inFri Jan 13 14:10:21 2012
@@ -3106,6 +3106,7 @@
 
 dnl Link with -lposix1e for ACL stuff; if not found, try -lacl for SGI
 dnl when -lacl works, also try to use -lattr (required for Debian).
+dnl On Solaris, use the acl_get/set functions in libsec, if present.
 AC_MSG_CHECKING(--disable-acl argument)
 AC_ARG_ENABLE(acl,
[  --disable-acl   Don't check for ACL support.],
@@ -3128,7 +3129,8 @@
AC_MSG_RESULT(yes); AC_DEFINE(HAVE_POSIX_ACL),
AC_MSG_RESULT(no))
 
-AC_MSG_CHECKING(for Solaris ACL support)
+AC_CHECK_LIB(sec, acl_get, [LIBS=$LIBS -lsec; 
AC_DEFINE(HAVE_SOLARIS_ZFS_ACL)],
+AC_MSG_CHECKING(for Solaris ACL support)
 AC_TRY_LINK([
 #ifdef HAVE_SYS_ACL_H
 # include sys/acl.h
@@ -3135,7 +3137,7 @@
 #endif], [acl(foo, GETACLCNT, 0, NULL);
],
AC_MSG_RESULT(yes); AC_DEFINE(HAVE_SOLARIS_ACL),
-   AC_MSG_RESULT(no))
+   AC_MSG_RESULT(no)))
 
 AC_MSG_CHECKING(for AIX ACL support)
 AC_TRY_LINK([
--- src/config.h.in Fri Jan 13 13:29:05 2012
+++ src/config.h.in Fri Jan 13 13:29:13 2012
@@ -363,6 +363,7 @@
 
 /* Define if you want to add support for ACL */
 #undef HAVE_POSIX_ACL
+#undef HAVE_SOLARIS_ZFS_ACL
 #undef HAVE_SOLARIS_ACL
 #undef HAVE_AIX_ACL
 
--- src/os_unix.c   Tue Jan 10 16:13:35 2012
+++ src/os_unix.c   Fri Jan 13 15:57:08 2012
@@ -2746,6 +2746,13 @@
 #ifdef HAVE_POSIX_ACL
 ret = (vim_acl_T)acl_get_file((char *)fname, ACL_TYPE_ACCESS);
 #else
+#ifdef HAVE_SOLARIS_ZFS_ACL
+acl_t *aclent;
+
+if (acl_get((char *)fname, 0, aclent)  0)
+   return NULL;
+ret = (vim_acl_T)aclent;
+#else
 #ifdef HAVE_SOLARIS_ACL
 vim_acl_solaris_T   *aclent;
 
@@ -2791,6 +2798,7 @@
 ret = (vim_acl_T)aclent;
 #endif /* HAVE_AIX_ACL */
 #endif /* HAVE_SOLARIS_ACL */
+#endif /* HAVE_SOLARIS_ZFS_ACL */
 #endif /* HAVE_POSIX_ACL */
 return ret;
 }
@@ -2808,6 +2816,9 @@
 #ifdef HAVE_POSIX_ACL
 acl_set_file((char *)fname, ACL_TYPE_ACCESS, (acl_t)aclent);
 #else
+#ifdef HAVE_SOLARIS_ZFS_ACL
+acl_set((char *)fname, (acl_t *)aclent);
+#else
 #ifdef HAVE_SOLARIS_ACL
 acl((char *)fname, SETACL, ((vim_acl_solaris_T *)aclent)-acl_cnt,
((vim_acl_solaris_T *)aclent)-acl_entry);
@@ -2816,6 +2827,7 @@
 chacl((char *)fname, aclent, ((struct acl *)aclent)-acl_len);
 #endif /* HAVE_AIX_ACL */
 #endif /* HAVE_SOLARIS_ACL */
+#endif /* HAVE_SOLARIS_ZFS_ACL */
 #endif /* HAVE_POSIX_ACL */
 }
 
@@ -2828,6 +2840,9 @@
 #ifdef HAVE_POSIX_ACL
 acl_free((acl_t)aclent);
 #else
+#ifdef HAVE_SOLARIS_ZFS_ACL
+acl_free((acl_t *)aclent);
+#else
 #ifdef HAVE_SOLARIS_ACL
 free(((vim_acl_solaris_T *)aclent)-acl_entry);
 free(aclent);
@@ -2836,6 +2851,7 @@
 free(aclent);
 #endif /* HAVE_AIX_ACL */
 #endif /* HAVE_SOLARIS_ACL */
+#endif /* HAVE_SOLARIS_ZFS_ACL */
 #endif /* HAVE_POSIX_ACL */
 }
 #endif

Re: missing cpoptions settings in some syntax files

[Danek Duvall]

Thilo Six wrote:

 attached is full list of affected files. Those files below /doc can be 
 ignored i
 assume. I would like to see the rest fixed, too. Can we join forces?

Well, I sent out a missive to the maintainers of the syntax files (some of
whom also own some of the other runtime files), since Bram wants to be able
to pull the fixes from upstream.  I've gotten a few responses (and a couple
bounces) so far, but it'll take some time to filter through.  What's left
over without a response after a few weeks I'll submit to Bram directly.

 $ recgrep -l '^[\t ]*\\' .

I used

comm -13 =(grep -l set cpo **/*.vim) =(grep -l ^[[:space:]]* 
**/*.vim)

to generate mine (with some zsh-isms).  That gives 73 files to check out
once you ignore the keymap files.

autoload/ada.vim
autoload/adacomplete.vim
autoload/decada.vim
autoload/gnat.vim
autoload/htmlcomplete.vim
autoload/javascriptcomplete.vim
autoload/netrw.vim
autoload/phpcomplete.vim
autoload/sqlcomplete.vim
autoload/syntaxcomplete.vim
autoload/xml/html32.vim
autoload/xml/html401f.vim
autoload/xml/html401s.vim
autoload/xml/html401t.vim
autoload/xml/html40f.vim
autoload/xml/html40s.vim
autoload/xml/html40t.vim
autoload/xml/xhtml10f.vim
autoload/xml/xhtml10s.vim
autoload/xml/xhtml10t.vim
autoload/xml/xhtml11.vim
autoload/xml/xsd.vim
autoload/xml/xsl.vim
compiler/cs.vim
compiler/decada.vim
compiler/g95.vim
compiler/gfortran.vim
compiler/gnat.vim
compiler/hp_acc.vim
compiler/ifort.vim
compiler/intel.vim
compiler/irix5_c.vim
compiler/irix5_cpp.vim
compiler/mips_c.vim
compiler/mipspro_c89.vim
compiler/mipspro_cpp.vim
ftplugin/art.vim
ftplugin/cs.vim
ftplugin/occam.vim
ftplugin/pyrex.vim
ftplugin/python.vim
ftplugin/spec.vim
indent/cmake.vim
indent/css.vim
indent/eiffel.vim
indent/idlang.vim
indent/java.vim
indent/mp.vim
indent/occam.vim
indent/python.vim
indent/sqlanywhere.vim
indent/vim.vim
indent/xinetd.vim
lang/menu_ja_jp.euc-jp.vim
lang/menu_ja_jp.utf-8.vim
lang/menu_japanese_japan.932.vim

If you want, we can split them up, but the trick will be to weed out
maintainers that already got the message by way of the syntax file missive
I sent out and to make sure we don't duplicate each other.  I think it's
probably less work for one person to do it.  I'll send you the email I sent
out, if you want to do it.

Danek

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

missing cpoptions settings in some syntax files

[Danek Duvall]

There are a handful of syntax files that use backslash continuation
characters without ensuring that cpoptions is missing C, so when running
vim in vi compatibility mode (such as when there's no .vimrc), you'll get
errors like

Error detected while processing /usr/share/vim/vim73/syntax/po.vim:
line   37:
E10: \ should be followed by /, ? or 
line   39:
E10: \ should be followed by /, ? or 

when editing a .po file and running syn on.  Most syntax scripts (at
least those that use continuation characters) execute set cpovim and
reset cpo at the end of the script, but these don't:

autoit.vim
cmake.vim
cucumber.vim
datascript.vim
fvwm.vim
lsl.vim
mrxvtrc.vim
objc.vim
perl6.vim
php.vim
po.vim
sgmldecl.vim
taskdata.vim
taskedit.vim
tex.vim
valgrind.vim

I'm happy to submit a patch that fixes these, but there are many scripts
outside the syntax directory that would have the same problem, and I don't
know whether these should be fixed in the vim distro or further upstream
first, so I'm looking for guidance.

Thanks,
Danek

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

Re: Patch 7.3.296

[Danek Duvall]

This doesn't compile.

 Patch 7.3.296
 Problem:When writing to an external command a zombie process may be left
   behind.
 Solution:   Wait on the process. (James Vega)
 Files:src/os_unix.c
 
 
 *** ../vim-7.3.295/src/os_unix.c  2011-09-07 14:06:38.0 +0200
 --- src/os_unix.c 2011-09-07 14:54:11.0 +0200
 ***
 *** 154,159 
 --- 154,166 
   
   static void may_core_dump __ARGS((void));
   
 + #ifdef HAVE_UNION_WAIT
 + typedef union wait waitstatus;
 + #else
 + typedef int waitstatus;
 + #endif
 + static int  wait4pid __ARGS((pid_t, waitstatus *));

wait4pid is declared as returning int here, but ...

   static int  WaitForChar __ARGS((long));
   #if defined(__BEOS__)
   int  RealWaitForChar __ARGS((int, long, int *));
 ***
 *** 3660,3665 
 --- 3667,3713 
   /* Nothing to do. */
   }
   
 + /*
 +  * Wait for process child to end.
 +  * Return child if it exited properly, = 0 on error.
 +  */
 + static pid_t
 + wait4pid(child, status)
 + pid_t   child;
 + waitstatus  *status;

... defined as returning pid_t here.  At least with Sun Studio, this is a
redeclaration error.

Changing the declaration to return pid_t lets it compile.

Thanks,
Danek

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

Re: remote API without X

[Danek Duvall]

On Wed, Jun 08, 2011 at 06:38:14AM +0200, Bram Moolenaar wrote:

 Yasuhiro Matsumoto wrote:
 
   On Unix it uses sockets?  How does it protect from other users
   sending commands to my Vim?
  
  Yes, it use unix domain socket. this control in
  /tmp/vim-cmdsrv-UID-SERVERID on unix.  And it is set permission 0600.
  For windows, it use named pipe. This is provided for the user.  i.e.
  serverlist() is listing the files /tmp/vim-cmd- 
 
 This it's sure that only the user himself can access the Vim instance,
 right?

I know on Solaris, and I believe on Linux, at least at one point in the
past, the permissions on the socket itself don't actually prevent anyone
from reading or writing.  The only protection comes from putting the socket
inside a directory that's inaccessible to anyone but the intended user(s).

Solaris has a getpeerucred() function which allows a program to get the
credential information about a socket's peer, but I don't know if other
OSes have any equivalents.

Danek

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

Re: Patch 7.3.202

[Danek Duvall]

Tony Mechelynck wrote:

 On 28/05/11 19:59, Danek Duvall wrote:

 Or perhaps there's a smooth, generic patch-flow I'm not seeing where this
 problem isn't actually a problem.
 
 See http://vim.wikia.com/wiki/Getting_the_Vim_source_with_Mercurial

Yes, I can do that, but our build infrastructure is currently designed with
tarballs and patches in mind, not SCMs.  That said, using an SCM URL in
place of a tarball URL is something I've wanted for a while, so perhaps I
should spend some time designing that into the tools if vim's tarball/patch
model is broken.

Thanks,
Danek

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

Re: Patch 7.3.202

[Danek Duvall]

On Sat, May 28, 2011 at 07:11:22PM +0800, H Xu wrote:

 On 05/28/2011 03:49 AM, Danek Duvall wrote:
 I'm getting an error applying this, after having applied all previous
 patches to the 7.3 tarball:
 [...]
 Normally this is just fine.  In fact, patches 191 and 196 were the only
 other patches that reported even needing an offset.
 
 Hello Danek Duvall,
 
 I see that you failed to patch a doc file, which is not only updated
 in the patch way. Usually doc files are also updated in the vim
 mercurial repository, which is probably the culprit of the patch
 failure, so you can ignore this patch failure and obtain the latest
 doc files at the mercurial repository.

I usually apply all the patches from the patches directory and then create
a runtime patch that applies on top of those to bring the runtime up to
the latest patchlevel.  Then I can check the runtime patch into my
workspace, but have the canonical patches downloaded.  Unfortunately,
there's no reasonable way to automate interleaving runtime patches with
code.

I'd prefer not to ignore errors, because that usually means something went
wrong, and I'd like the build to fail if something went wrong.  I could
also try editing the patch on the fly before applying it, or try to apply
the patch only to the non-runtime files, but the build architecture is
making it a touch difficult to figure out how to do that.

I'll find a way to work around it if necessary, but I was wondering whether
this was simply a mistake, and if so, if the patch file on the ftp site
could simply be regenerated to not include the changes to eval.txt, and let
folks who want to patch that do so the usual way (or if the changes are
truly integral, deliver them as changes that apply against 7.3).

Or perhaps there's a smooth, generic patch-flow I'm not seeing where this
problem isn't actually a problem.

Thanks,
Danek

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

Re: Patch 7.3.202

[Danek Duvall]

I'm getting an error applying this, after having applied all previous
patches to the 7.3 tarball:

patching file runtime/doc/indent.txt
Hunk #12 succeeded at 273 with fuzz 1.
Hunk #13 succeeded at 289 (offset -1 lines).
Hunk #14 succeeded at 301 (offset -1 lines).
Hunk #15 succeeded at 310 (offset -1 lines).
Hunk #16 succeeded at 334 (offset -1 lines).
Hunk #17 succeeded at 342 (offset -1 lines).
Hunk #18 FAILED at 356.
Hunk #19 succeeded at 364 (offset -4 lines).
Hunk #20 succeeded at 374 (offset -4 lines).
Hunk #21 succeeded at 385 (offset -4 lines).
Hunk #22 succeeded at 408 (offset -4 lines).
Hunk #23 succeeded at 416 (offset -4 lines).
Hunk #24 succeeded at 428 (offset -4 lines).
Hunk #25 succeeded at 441 (offset -4 lines).
Hunk #26 succeeded at 456 (offset -4 lines).
Hunk #27 succeeded at 471 (offset -4 lines).
Hunk #28 succeeded at 481 (offset -4 lines).
Hunk #29 succeeded at 492 (offset -4 lines).
Hunk #30 FAILED at 510.
Hunk #31 succeeded at 528 (offset -6 lines).
2 out of 31 hunks FAILED -- saving rejects to file 
runtime/doc/indent.txt.rej
patching file src/misc1.c
patching file src/testdir/test3.in
patching file src/testdir/test3.ok
patching file src/version.c

Normally this is just fine.  In fact, patches 191 and 196 were the only
other patches that reported even needing an offset.

Any ideas?

Thanks,
Danek

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

Re: Patch 7.3.050

[Danek Duvall]

On Wed, Nov 03, 2010 at 10:32:40PM +0100, Bram Moolenaar wrote:

 
 Patch 7.3.050
 Problem:The link script is clumsy.
 Solution:   Use the --as-needed linker option if available. (Kirill A.
   Shutemov)
 Files:src/Makefile, src/auto/configure, src/config.mk.in,
   src/configure.in, src/link.sh

Hm.  Using the Solaris linker, -z ignore does exactly the same thing.
Doesn't look like the GNU folks have caught up with its CLI, or the Solaris
linker folks with the GNU CLI.  Any chance you can fold that in quickly, or
should I try to cook up a patch?

Thanks,
Danek

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

Re: Patch 7.2.167

[Danek Duvall]

On Thu, May 14, 2009 at 09:46:46PM +0200, Bram Moolenaar wrote:

 It appears one needs to install the whole package to get this lint.

:(  Yeah, that's possible.  I know the Solaris packages (the SVr4 ones, at
any rate) are reasonably finer grained, so you don't have to get the
fortran and all the truly miscellaneous stuff, but the linux package may
not be like that.

 How good is it?  Compared to the warnings that gcc can produce.

It comes up with a different set of warnings, honestly.  The Solaris kernel
is compiled with both, and while Studio lint finds more problem in general,
there are times when gcc finds things it doesn't.  Note, though, that lint
will do a better job of finding cross-module problems than gcc will, since
gcc operates on one source file at a time.

Danek

--~--~-~--~~~---~--~~
You received this message from the vim_dev maillist.
For more information, visit http://www.vim.org/maillist.php
-~--~~~~--~~--~--~---

Re: Patch 7.2.167

[Danek Duvall]

On Wed, May 13, 2009 at 08:40:06PM +0200, Bram Moolenaar wrote:

 Does someone know a better lint than splint?  Unfortunately the lint I
 was using on FreeBSD doesn't appear to be available for Linux.  It
 wasn't great but I least I could use it for some basic sanity checking.

The Sun Studio compilers are available for Linux, come with a reasonably
good lint, and don't cost anything except any annoyance you might find in
registering.  I've never installed them on Linux, though, so I don't know
how well all that works there.

Danek

--~--~-~--~~~---~--~~
You received this message from the vim_dev maillist.
For more information, visit http://www.vim.org/maillist.php
-~--~~~~--~~--~--~---

Re: PATCH: dynamically load Python on Solaris

[Danek Duvall]

On Sun, Feb 22, 2009 at 07:04:08PM +0100, bj�rn wrote:

 Well, this is turning out to be quite complicated.  After quite a bit
 of searching I found that passing
 
 -dynamic -undefined suppress -flat_namespace
 
 when linking if_python.so gets rid of all those error messages.  So
 the relevant lines inside Makefile should say something like:

Hm.  Try perhaps -dynamiclib instead of -dynamic?  You could also see how
the Python dynamic modules are compiled, since they're likely loaded by the
Python interpreter the same way we're loading this module in vim.

Danek

--~--~-~--~~~---~--~~
You received this message from the vim_dev maillist.
For more information, visit http://www.vim.org/maillist.php
-~--~~~~--~~--~--~---

Re: PATCH: dynamically load Python on Solaris

[Danek Duvall]

björn wrote:

 2009/2/15 Danek Duvall:
 
  And further down that road would be to experiment with whether multiple
  versions of Python can be loaded into memory at the same time.  If that's
  the case, then you could have different scripts running with different
  versions in the same vim session.  I don't know how useful that would be in
  practice, though.
 
 This would be very useful for the Mac OS X port of Vim (MacVim) since
 10.4 comes with Python 2.3 and 10.5 ships with Python 2.5.  At the
 moment I link MacVim against 2.3 so that it works on both 10.4 and
 10.5 but several users have requested 2.5.

So that speaks for having multiple versions available, but not necessarily
for having them all co-resident.

 I actually implemented dynamic loading of Python for OS X but since there
 are Python API changes between 2.3 and 2.5 you get a warning when trying
 to run on 2.3 if the binary was built using 2.5 (even though the library
 itself is successfullly loaded dynamically).

Yup, I saw that as well when playing around.

 By the way, how exactly do you propose to do this?  Looking at your
 latest patch I assume you'd build one if_python module for each version
 and then decide which one to load when python is first used?

That's the idea.  I'm just not sure how that decision should be made.  I
guess I'm looking for some guidance from Bram, though not being terribly
familiar with the vim development model, I don't know if I should be
looking elsewhere for that guidance.

At any rate, if I were to hack something together right now, I'd probably
introduce a new variable that would let you set the order:

set pythonversions=2.3,2.4,2.5

with tags of oldest and newest available as well.  The first module
matching an element in the series that loaded properly would be the one
used, defaulting to either oldest or newest if the variable isn't set (or
if none of them match?).  The modules would need to be named consistently
-- if_pythonver.so -- and in a collatable order, though I suppose I could
always try to query the module for the definitive version if the collation
proves too difficult.

But there might be some pitfalls behind that.  Suggestions and guidance are
welcomed.

Thanks,
Danek

--~--~-~--~~~---~--~~
You received this message from the vim_dev maillist.
For more information, visit http://www.vim.org/maillist.php
-~--~~~~--~~--~--~---

Re: PATCH: dynamically load Python on Solaris

[Danek Duvall]

On Tue, Feb 17, 2009 at 07:32:35PM +0100, björn wrote:

 Yes that is all I am after -- I can't see any particular use for
 having two or more co-resident.  (?)

The use case would be if you had a script that could only run with 2.3 and
another that could only run with 2.6, and you wanted to use both in the
same vim process.  I agree that it's all that worth worrying about, though.

 I think this is overkill.  Why not just see which modules are
 installed and try loading from newest to oldest?

Works for me.  I can always change it later to be fancier if people find
the simple method to not be enough.

 Well, maybe it isn't that simple since loading will probably work as long
 as the module is present even if the matching python version is not
 installed.

That'll probably depend on the features of the dynamic linker.  On Solaris,
at least, the module will fail to load if a dependency it has isn't there.

I may not get to it before this weekend, but I'll post another patch as
soon as I have it.  In the meantime, if you have a chance to try my latest
patch out on OS X, I'd be curious to know if it works there.

Thanks,
Danek

--~--~-~--~~~---~--~~
You received this message from the vim_dev maillist.
For more information, visit http://www.vim.org/maillist.php
-~--~~~~--~~--~--~---

Re: PATCH: dynamically load Python on Solaris

[Danek Duvall]

So here's a re-work that should allow for dynamic loading on platforms
other than Solaris.  The autoconf bits are tuned for Solaris, but change
-Kpic to -fpic, -G to -shared, and SunOS to Linux, and I think it might
work, or at least come close.

The difference here is that if_python.c itself is converted into a shared
object which can be loaded by vim.  That way, if_python.so can link simply
against python and not have to worry about the mess of dlsym calls, lazy
loading, etc, that you needed in the main program in my first attempt.
Then vim either loads or fails to load if_python.so.

New patch is attached.

Thanks,
Danek

--~--~-~--~~~---~--~~
You received this message from the vim_dev maillist.
For more information, visit http://www.vim.org/maillist.php
-~--~~~~--~~--~--~---

--- Makefile.orig   Sat Aug  9 07:50:04 2008
+++ MakefileMon Feb 16 01:07:36 2009
@@ -966,6 +966,8 @@
 PRINTSUBLOC= $(VIMRTLOC)$(PRINTSUBDIR)
 SCRIPTLOC  = $(VIMRTLOC)
 
+VIMSOLOC   = $(LIBDIR)$(VIMRTDIR)
+
 ### Only set VIMRUNTIMEDIR when VIMRTLOC is set to a different location and
 ### the runtime directory is not below it.
 #VIMRUNTIMEDIR = $(VIMRTLOC)
@@ -1334,6 +1336,7 @@
 DEST_SCRIPT = $(DESTDIR)$(SCRIPTLOC)
 DEST_PRINT = $(DESTDIR)$(PRINTSUBLOC)
 DEST_MAN_TOP = $(DESTDIR)$(MANDIR)
+DEST_SO = $(DESTDIR)$(VIMSOLOC)
 
 # We assume that the .../man/xx/man1/ directory is for latin1 manual pages.
 # Some systems use UTF-8, but these should find the .../man/xx.UTF-8/man1/
@@ -1555,7 +1558,7 @@
os_mswin.pro os_beos.pro os_vms.pro os_riscos.pro $(PERL_PRO)
 
 # Default target is making the executable and tools
-all: $(VIMTARGET) $(TOOLS) languages $(GUI_BUNDLE)
+all: $(VIMTARGET) $(PYTHON_SO) $(TOOLS) languages $(GUI_BUNDLE)
 
 tools: $(TOOLS)
 
@@ -1761,7 +1764,7 @@
 
 install_gui_extra: installgtutorbin
 
-installvim: installvimbin installtutorbin \
+installvim: installvimbin installvimso installtutorbin \
installruntime installlinks installmanlinks
 
 #
@@ -1784,6 +1787,11 @@
 # may create a link to the new executable from /usr/bin/vi
-$(LINKIT)
 
+installvimso: $(PYTHON_SO) $(DESTDIR)$(libdir) $(DEST_SO)
+   -$(INSTALL_PROG) $(PYTHON_SO) $(DEST_SO)
+   -$(STRIP) $(DEST_SO)/$(PYTHON_SO)
+   -chmod $(BINMOD) $(DEST_SO)/$(PYTHON_SO)
+
 # Long list of arguments for the shell script that installs the manual pages
 # for one language.
 INSTALLMANARGS = $(VIMLOC) $(SCRIPTLOC) $(VIMRCLOC) $(HELPSOURCE) $(MANMOD) \
@@ -2020,7 +2028,7 @@
@echo You need to unpack the runtime archive before running make 
install.
test -f error
 
-$(DESTDIR)$(exec_prefix) $(DEST_BIN) \
+$(DESTDIR)$(exec_prefix) $(DEST_BIN) $(DEST_SO) \
$(DEST_VIM) $(DEST_RT) $(DEST_HELP) \
$(DEST_PRINT) $(DEST_COL) $(DEST_SYN) $(DEST_IND) $(DEST_FTP) \
$(DEST_LANG) $(DEST_KMAP) $(DEST_COMP) \
@@ -2184,6 +2192,7 @@
 # We support common typing mistakes for Juergen! :-)
 clean celan: testclean
-rm -f *.o objects/* core $(VIMTARGET).core $(VIMTARGET) vim xxd/*.o
+   -rm -f $(PYTHON_SO)
-rm -f $(TOOLS) auto/osdef.h auto/pathdef.c auto/if_perl.c
-rm -f conftest* *~ auto/link.sed
-rm -rf $(APPDIR)
@@ -2429,9 +2438,15 @@
 objects/if_perlsfio.o: if_perlsfio.c
$(CCC) -o $@ if_perlsfio.c
 
+objects/if_python_stub.o: if_python_stub.c
+   $(CCC) -o $@ if_python_stub.c
+
 objects/if_python.o: if_python.c
-   $(CCC) -o $@ if_python.c
+   $(CCC) $(PYTHON_SO_CFLAGS) -o $@ if_python.c
 
+$(PYTHON_SO): $(PYTHON_SO_OBJ)
+   $(CClink) $(PYTHON_SO_LIBS) -o $@ $(PYTHON_SO_OBJ)
+
 objects/if_ruby.o: if_ruby.c
$(CCC) -o $@ if_ruby.c
 
@@ -2503,7 +2518,7 @@
 
 objects/py_config.o: $(PYTHON_CONFDIR)/config.c
$(CCC) -o $@ $(PYTHON_CONFDIR)/config.c \
-   -I$(PYTHON_CONFDIR) -DHAVE_CONFIG_H -DNO_MAIN
+   $(PYTHON_INC) -I$(PYTHON_CONFDIR) -DHAVE_CONFIG_H -DNO_MAIN
 
 objects/py_getpath.o: $(PYTHON_CONFDIR)/getpath.c
$(CCC) -o $@ $(PYTHON_CONFDIR)/getpath.c \
--- config.mk.in.orig   Sat Jun 21 08:56:41 2008
+++ config.mk.inMon Feb 16 00:54:57 2009
@@ -55,6 +55,11 @@
 PYTHON_OBJ = @PYTHON_OBJ@
 PYTHON_CFLAGS  = @PYTHON_CFLAGS@
 PYTHON_LIBS= @PYTHON_LIBS@
+PYTHON_INC = @PYTHON_INC@
+PYTHON_SO  = @PYTHON_SO@
+PYTHON_SO_OBJ  = @PYTHON_SO_OBJ@
+PYTHON_SO_CFLAGS   = @PYTHON_SO_CFLAGS@
+PYTHON_SO_LIBS = @PYTHON_SO_LIBS@
 PYTHON_CONFDIR = @PYTHON_CONFDIR@
 PYTHON_GETPATH_CFLAGS = @PYTHON_GETPATH_CFLAGS@
 
@@ -112,6 +117,9 @@
 ### For autoconf 2.60 and later (avoid a warning)
 datarootdir= @datarootdir@
 
+### Prefix for location of native-code plugins
+LIBDIR = @libdir@
+
 ### Prefix for location of data files
 DATADIR= @datadir@
 
--- configure.in.orig   Sat Feb 14 13:53:40 2009
+++ configure.inMon Feb 16 00:58:47 2009
@@ -608,10 +608,10 @@
 
 

Re: PATCH: dynamically load Python on Solaris

[Danek Duvall]

On Sun, Feb 15, 2009 at 02:57:35PM +0100, Bram Moolenaar wrote:

 I haven't looked at the patch yet, but I would like to encourage others
 to help make this work for as many systems as possible.  It's so much
 nicer when Vim can be build with Python and the binary distributed to
 systems where Python is not available.  Less versions, more flexibility.
 
 I assume that for building the Python headers and tools are still
 required, thus it only helps for when distributing a Vim binary.

Correct.

One question I have is how flexible it should be.  I did this the way I did
because I could easily hang off the work that had been done for Windows,
but if I were to make a dynamic module -- consisting of if_python.o and
py_config.o -- then I could make one for each version of Python available
on the system at build time, and then try loading them in turn until one
was successful.  So you could build on a system that had 2.4, 2.5, and 2.6,
and work on a system that had any of the three.

Of course, fully fleshing that idea out means giving some control to the
user of which version they want to use, or a preference ordering of the
versions.

And further down that road would be to experiment with whether multiple
versions of Python can be loaded into memory at the same time.  If that's
the case, then you could have different scripts running with different
versions in the same vim session.  I don't know how useful that would be in
practice, though.

Danek

--~--~-~--~~~---~--~~
You received this message from the vim_dev maillist.
For more information, visit http://www.vim.org/maillist.php
-~--~~~~--~~--~--~---

Re: Re: PATCH: dynamically load Python on Solaris

[Danek Duvall]

On Sun, Feb 15, 2009 at 09:02:15PM +1100, Doug Kearns wrote:

 On 2/15/09, Danek Duvall duv...@comfychair.org wrote:
 
   If there are any Python script torture tests I should run, let me
   know; I'm not sure what the best python scripts are to play with.
 
 You could play with the distributed Python omni completion:
 autoload/pythoncomplete.vim

Ah, thanks.  Seems to work.

Danek

--~--~-~--~~~---~--~~
You received this message from the vim_dev maillist.
For more information, visit http://www.vim.org/maillist.php
-~--~~~~--~~--~--~---

Re: PATCH: dynamically load Python on Solaris

[Danek Duvall]

Okay, I've hacked configure.in to make it possible to do this from
configure.  The patch is attached.  It applies only on top of my previous
patch, as it passes the python library name in as a define.  This is gross,
but it gets the job done for now.

Thanks,
Danek

--~--~-~--~~~---~--~~
You received this message from the vim_dev maillist.
For more information, visit http://www.vim.org/maillist.php
-~--~~~~--~~--~--~---

--- configure.in.orig   Sat Feb 14 13:53:40 2009
+++ configure.inSun Feb 15 21:24:19 2009
@@ -608,10 +608,10 @@
 
 AC_MSG_CHECKING(--enable-pythoninterp argument)
 AC_ARG_ENABLE(pythoninterp,
-   [  --enable-pythoninterp   Include Python interpreter.], ,
+   [  --enable-pythoninterp[=OPTS] Include Python interpreter. 
[OPTS=yes/no/dynamic]], ,
[enable_pythoninterp=no])
 AC_MSG_RESULT($enable_pythoninterp)
-if test $enable_pythoninterp = yes; then
+if test $enable_pythoninterp = yes -o $enable_pythoninterp = dynamic; 
then
   dnl -- find the python executable
   AC_PATH_PROG(vi_cv_path_python, python)
   if test X$vi_cv_path_python != X; then
@@ -668,6 +668,12 @@
done
   ])
 
+  if test ${enable_pythoninterp} = dynamic; then
+   if test `(uname) 2/dev/null` != SunOS; then
+ AC_MSG_RESULT([dynamically loaded Python interpreter not supported!])
+   fi
+  fi
+
   PYTHON_CONFDIR=${vi_cv_path_python_conf}
 
   if test X$PYTHON_CONFDIR = X; then
@@ -686,6 +692,7 @@
@echo python_LIBS='$(LIBS)'
@echo python_SYSLIBS='$(SYSLIBS)'
@echo python_LINKFORSHARED='$(LINKFORSHARED)'
+   @echo python_INSTSONAME='$(INSTSONAME)'
 eof
dnl -- delete the lines from make about Entering/Leaving directory
eval `cd ${PYTHON_CONFDIR}  make -f ${tmp_mkf} __ | sed '/ 
directory /d'`
@@ -697,7 +704,17 @@
  if test ${vi_cv_var_python_version} = 1.4; then
  vi_cv_path_python_plibs=${PYTHON_CONFDIR}/libModules.a 
${PYTHON_CONFDIR}/libPython.a ${PYTHON_CONFDIR}/libObjects.a 
${PYTHON_CONFDIR}/libParser.a
  else
+   if test ${enable_pythoninterp} = dynamic; then
+ vi_cv_lazyon=-zlazyload
+ vi_cv_lazyoff=-znolazyload
+ if test $GCC = yes; then
+   vi_cv_lazyon=-Wl,${vi_cv_lazyon}
+   vi_cv_lazyoff=-Wl,${vi_cv_lazyoff}
+ fi
+ vi_cv_path_python_plibs=-L${PYTHON_CONFDIR} ${vi_cv_lazyon} 
-lpython${vi_cv_var_python_version} ${vi_cv_lazyoff}
+   else
  vi_cv_path_python_plibs=-L${PYTHON_CONFDIR} 
-lpython${vi_cv_var_python_version}
+   fi
  fi
  vi_cv_path_python_plibs=${vi_cv_path_python_plibs} 
${python_MODLIBS} ${python_LIBS} ${python_SYSLIBS} ${python_LINKFORSHARED}
  dnl remove -ltermcap, it can conflict with an earlier -lncurses
@@ -711,6 +728,9 @@
else
  
PYTHON_CFLAGS=-I${vi_cv_path_python_pfx}/include/python${vi_cv_var_python_version}
 -I${vi_cv_path_python_epfx}/include/python${vi_cv_var_python_version}
fi
+   if test ${enable_pythoninterp} = dynamic; then
+ PYTHON_CFLAGS=${PYTHON_CFLAGS} -DDYNAMIC_PYTHON 
-DPYTHONSONAME='\${python_INSTSONAME}\'
+   fi
PYTHON_SRC=if_python.c
dnl For Mac OSX 10.2 config.o is included in the Python library.
if test x$MACOSX = xyes; then
--- if_python.c.orig.2  Sun Feb 15 21:29:10 2009
+++ if_python.c Sun Feb 15 21:29:26 2009
@@ -442,7 +442,7 @@
 int
 python_enabled(int verbose)
 {
-return python_runtime_link_init(libpython2.4.so.1.0, verbose) == OK;
+return python_runtime_link_init(PYTHONSONAME, verbose) == OK;
 }
 #endif /* SOLARIS */
 #endif /* DYNAMIC_PYTHON */

PATCH: dynamically load Python on Solaris

[Danek Duvall]

I've been wanting to code this up for a while, and almost had it a while
back, but couldn't quite get it working, and put it aside until today.

It's not ready for integration, since it's not at all tied into the
autoconf setup, and requires that you modify src/auto/config.mk to add
-DDYNAMIC_PYTHON to PYTHON_CFLAGS and wrap -lpython2.4 in PYTHON_LIBS with
-zlazyload / -znolazyload, but otherwise it seems to work: python isn't
loaded until the first python command is executed, and (as far as I've been
able to tell) executes python code just fine after that, has(python) is
true, etc.

Comments on the patch itself are appreciated.  Suggestions on how it might
be made to work on Linux are also appreciated, though I don't really have
any means of testing it at the moment.  And help with getting it tied in
with autoconf would be great; I'm not sure how to move forward on that.  If
there are any Python script torture tests I should run, let me know; I'm
not sure what the best python scripts are to play with.

I haven't looked at doing the other interpreters yet, though I'd like to do
that, as well as see if it's possible to dynamically load the GUI.

Thanks for any thoughts,
Danek

--~--~-~--~~~---~--~~
You received this message from the vim_dev maillist.
For more information, visit http://www.vim.org/maillist.php
-~--~~~~--~~--~--~---

--- if_python.c.origSat Feb 14 13:53:41 2009
+++ if_python.c Sat Feb 14 19:21:41 2009
@@ -86,9 +86,11 @@
 #endif
 
 #if defined(DYNAMIC_PYTHON) || defined(PROTO)
+#ifdef MSWIN
 # ifndef DYNAMIC_PYTHON
 #  define HINSTANCE long_u /* for generating prototypes */
 # endif
+#endif
 
 /* This makes if_python.c compile without warnings against Python 2.5
  * on Win32 and Win64. */
@@ -215,7 +217,9 @@
 static void (*dll_PyObject_Free)(void*);
 # endif
 
+#ifdef MSWIN
 static HINSTANCE hinstPython = 0; /* Instance of python.dll */
+#endif
 
 /* Imported exception objects */
 static PyObject *imp_PyExc_AttributeError;
@@ -233,11 +237,17 @@
 /*
  * Table of name to function pointer of python.
  */
+#ifdef MSWIN
 # define PYTHON_PROC FARPROC
+# define PYTHON_PROC_STRUCT FARPROC
+#else
+# define PYTHON_PROC void
+# define PYTHON_PROC_STRUCT void *
+#endif
 static struct
 {
 char *name;
-PYTHON_PROC *ptr;
+PYTHON_PROC_STRUCT *ptr;
 } python_funcname_table[] =
 {
 {PyArg_Parse, (PYTHON_PROC*)dll_PyArg_Parse},
@@ -301,6 +311,7 @@
 {, NULL},
 };
 
+#ifdef MSWIN
 /*
  * Free python.dll
  */
@@ -358,6 +369,7 @@
 {
 return python_runtime_link_init(DYNAMIC_PYTHON_DLL, verbose) == OK;
 }
+#endif /* MSWIN */
 
 /* Load the standard Python exceptions - don't import the symbols from the
  * DLL, as this can cause errors (importing data symbols is not reliable).
@@ -381,6 +393,58 @@
 Py_XINCREF(imp_PyExc_ValueError);
 Py_XDECREF(exmod);
 }
+
+#ifdef SOLARIS
+#include dlfcn.h
+
+static void *python_dlhandle = NULL;
+
+static void
+end_dynamic_python(void)
+{
+if (python_dlhandle) {
+   dlclose(python_dlhandle);
+   python_dlhandle = NULL;
+}
+}
+
+static int
+python_runtime_link_init(char *libname, int verbose)
+{
+int i;
+
+if (python_dlhandle)
+   return OK;
+python_dlhandle = dlopen(libname, RTLD_GLOBAL|RTLD_LAZY);
+if (!python_dlhandle)
+{
+   if (verbose)
+   EMSG2(_(e_loadlib), libname);
+   return FAIL;
+}
+
+for (i = 0; python_funcname_table[i].ptr; ++i)
+{
+   if ((*python_funcname_table[i].ptr = dlsym(python_dlhandle,
+   python_funcname_table[i].name)) == NULL)
+   {
+   dlclose(python_dlhandle);
+   python_dlhandle = NULL;
+   if (verbose)
+   EMSG2(_(e_loadfunc), python_funcname_table[i].name);
+   return FAIL;
+   }
+}
+
+return OK;
+}
+
+int
+python_enabled(int verbose)
+{
+return python_runtime_link_init(libpython2.4.so.1.0, verbose) == OK;
+}
+#endif /* SOLARIS */
 #endif /* DYNAMIC_PYTHON */
 
 /**
@@ -483,7 +547,13 @@
 ++recurse;
 
 #ifdef DYNAMIC_PYTHON
-if (hinstPython  Py_IsInitialized())
+if (
+#ifdef MSWIN
+   hinstPython
+#elif defined(SOLARIS)
+   python_dlhandle
+#endif
+Py_IsInitialized())
 {
Python_RestoreThread(); /* enter python */
Py_Finalize();

Re: Feature request: Better way to handle SCM blame/annotate syntax highlighting

[Danek Duvall]

On Tue, Jan 27, 2009 at 06:12:39AM -0800, Ben Fritz wrote:

 On Jan 26, 9:30 am, Ted Pavlic t...@tedpavlic.com wrote:
 
  That is, an output of git blame myfile.c | vim - would get highlighted
  so that the left side of the blame output was highlighted matching
  git blame rules, and the right side of the blame output would use
  standard highlighting rules for c.
 
 While it is possible in some cases to highlight certain areas of a
 file using rules for a different filetype (http://vim.wikia.com/wiki/
 Different_syntax_highlighting_within_regions_of_a_file) what you are
 asking is currently not possible in Vim. 

 [ ... ]
 
 All this being said, you could probably make some sort of plugin to
 get functionality similar to what you want. After reading in the
 blame output, you could fairly easily split the file into a left and
 right window, with the left window containing only the blame output
 and the right containing only the un-annotated file.

Ideally, wouldn't annotate look very much like the 'number' option in terms
of how it's put on the screen?  They're both per-line metadata, after all.

Danek

--~--~-~--~~~---~--~~
You received this message from the vim_dev maillist.
For more information, visit http://www.vim.org/maillist.php
-~--~~~~--~~--~--~---

Re: automatic setting of encoding failure: bug in mbyte.c?

[Danek Duvall]

On Wed, Nov 19, 2008 at 10:01:23PM +0100, Bram Moolenaar wrote:

 Indeed.  It's very strange that this code got here...
 I'll make a patch out of this.

Thanks!

Danek

--~--~-~--~~~---~--~~
You received this message from the vim_dev maillist.
For more information, visit http://www.vim.org/maillist.php
-~--~~~~--~~--~--~---

automatic setting of encoding failure: bug in mbyte.c?

[Danek Duvall]

In enc_locale(), there's a for loop that looks like this:

for (i = 0; s[i] != NUL  s + i  buf + sizeof(buf) - 1; ++i)

but I can't figure out what the purpose is for that second test.  If I'm
reading it correctly, it's testing that the address of the character we're
copying from the source is less than the address of the final character in
the destination buffer, but that doesn't make much sense to me.  I could
understand if we were checking the source against the beginning of the
destination -- a check for overlap, but it's not doing that.

I ran into this because of a bug filed against the x86 build of vim for
Solaris, where 'encoding' always gets set to 'latin1', regardless of your
locale settings (unless, of course, you've set 'encoding' explicitly).
Oddly, it works just fine on SPARC, but it appears that it's just due to
the way the compiler's laid out memory on the two platforms.

The problem is fixed if I simply remove the test.  Is there any reason not
to do that in the base?

Thanks,
Danek

--~--~-~--~~~---~--~~
You received this message from the vim_dev maillist.
For more information, visit http://www.vim.org/maillist.php
-~--~~~~--~~--~--~---

Re: automatic setting of encoding failure: bug in mbyte.c?

[Danek Duvall]

On Tue, Nov 18, 2008 at 10:55:56PM +0100, Dominique Pelle wrote:

   for (i = 0; s[i] != NUL  i  sizeof(buf) - 1; ++i)
 
 The test (i  sizeof(buf) - 1) prevents overflow in buf[...],
 I would not remove it.

Of course; I was too focused on figuring out what the original code was (or
wasn't) doing.

I'm happy to add the patch into the stream for the Solaris build, would
would much rather simply pull an official patch.  Is there anything I can
do to streamline that process?

Thanks,
Danek

--~--~-~--~~~---~--~~
You received this message from the vim_dev maillist.
For more information, visit http://www.vim.org/maillist.php
-~--~~~~--~~--~--~---