Re: callback is not called when job exit immediately.
On Friday, September 9, 2016 at 9:52:09 AM UTC+9, mattn wrote: > okay, will look into it soon. I tried this but I cound't reproduce this. hmm, seems to be fixed already? -- -- 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: callback is not called when job exit immediately.
okay, will look into it soon. -- -- 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: callback is not called when job exit immediately.
I wrote: > Yasuhiro Matsumoto wrote: > > > behavior is I expected. but tests are failing with my patch. > > > > From test_channel.vim: > > Found errors in Test_out_close_cb(): > > function RunTheTest[9]..Test_out_close_cb line 26: Expected 2 but got 0 > > Found errors in Test_pipe_to_buffer_name(): > > function > > RunTheTest[9]..Test_pipe_to_buffer_name[1]..Run_test_pipe_to_buffer line > > 35: Expected 'yes' but got 'no' > > Found errors in Test_pipe_to_buffer_name_nomod(): > > Caught exception in Test_pipe_to_buffer_name_nomod(): Vim(sleep):E117: > > Unknown function: CloseHandler @ function > > RunTheTest[9]..Test_pipe_to_buffer_name_nomod[1]..Run_test_pipe_to_buffer[28]..WaitFor, > > line 20 > > Found errors in Test_read_in_close_cb(): > > function RunTheTest[9]..Test_read_in_close_cb line 15: Expected 'quit' but > > got '' > > Maybe PeekNamedPipe() is not the right function to use? > How about doing a non-blocking read? Any progress on this? I really want to make the Vim 8 release. -- $ echo pizza > /dev/oven /// Bram Moolenaar -- b...@moolenaar.net -- http://www.Moolenaar.net \\\ ///sponsor Vim, vote for features -- http://www.Vim.org/sponsor/ \\\ \\\ an exciting new programming language -- http://www.Zimbu.org/// \\\help me help AIDS victims -- http://ICCF-Holland.org/// -- -- You received this message from the "vim_dev" maillist. Do not top-post! Type your reply below the text you are replying to. For more information, visit http://www.vim.org/maillist.php --- You received this message because you are subscribed to the Google Groups "vim_dev" group. To unsubscribe from this group and stop receiving emails from it, send an email to vim_dev+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: callback is not called when job exit immediately.
Yasuhiro Matsumoto wrote: > behavior is I expected. but tests are failing with my patch. > > From test_channel.vim: > Found errors in Test_out_close_cb(): > function RunTheTest[9]..Test_out_close_cb line 26: Expected 2 but got 0 > Found errors in Test_pipe_to_buffer_name(): > function RunTheTest[9]..Test_pipe_to_buffer_name[1]..Run_test_pipe_to_buffer > line 35: Expected 'yes' but got 'no' > Found errors in Test_pipe_to_buffer_name_nomod(): > Caught exception in Test_pipe_to_buffer_name_nomod(): Vim(sleep):E117: > Unknown function: CloseHandler @ function > RunTheTest[9]..Test_pipe_to_buffer_name_nomod[1]..Run_test_pipe_to_buffer[28]..WaitFor, > line 20 > Found errors in Test_read_in_close_cb(): > function RunTheTest[9]..Test_read_in_close_cb line 15: Expected 'quit' but > got '' Maybe PeekNamedPipe() is not the right function to use? How about doing a non-blocking read? -- In Joseph Heller's novel "Catch-22", the main character tries to get out of a war by proving he is crazy. But the mere fact he wants to get out of the war only shows he isn't crazy -- creating the original "Catch-22". /// Bram Moolenaar -- b...@moolenaar.net -- http://www.Moolenaar.net \\\ ///sponsor Vim, vote for features -- http://www.Vim.org/sponsor/ \\\ \\\ an exciting new programming language -- http://www.Zimbu.org/// \\\help me help AIDS victims -- http://ICCF-Holland.org/// -- -- You received this message from the "vim_dev" maillist. Do not top-post! Type your reply below the text you are replying to. For more information, visit http://www.vim.org/maillist.php --- You received this message because you are subscribed to the Google Groups "vim_dev" group. To unsubscribe from this group and stop receiving emails from it, send an email to vim_dev+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: callback is not called when job exit immediately.
Yasuhiro Matsumoto wrote:
> On Monday, September 5, 2016 at 11:30:42 AM UTC+9, mattn wrote:
> > > Isn't the best solution then to have channel_wait() not return an error?
> > > Or is there some way to detect the situation, perhaps by using
> > > LastError(). At least it should only affect Windows, since on Unix we
> > > don't want to make this exception.
> >
> > I say again, This is posssible to be reproduced on Linux.
>
> While the process alive, stdout is not filled in the buffer. But when
> the process exited, buffer should be flushed. So if we change this
> like below to debug output,
>
> ---
> diff --git a/src/channel.c b/src/channel.c
> index 10ed42e..15a3f72 100644
> --- a/src/channel.c
> +++ b/src/channel.c
> @@ -59,6 +59,12 @@ static void channel_read(channel_T *channel, int part,
> char *func);
> /* Whether a redraw is needed for appending a line to a buffer. */
> static int channel_need_redraw = FALSE;
>
> +static void debuglog(char* buf) {
> + FILE *fp = fopen("debug.log", "a");
> + fprintf(fp, "%s\n", buf);
> + fclose(fp);
> +}
> +
> /* Whether we are inside channel_parse_messages() or another situation where
> it
> * is safe to invoke callbacks. */
> static int safe_to_invoke_callback = 0;
> @@ -2894,11 +2900,14 @@ channel_wait(channel_T *channel, sock_T fd, int
> timeout)
> while (TRUE)
> {
> int r = PeekNamedPipe((HANDLE)fd, NULL, 0, NULL, , NULL);
> + char buff[256];
> + sprintf(buff, "polling %ld, %d, %ld", nread, r, GetLastError());
> + debuglog(buff);
>
> - if (r && nread > 0)
> - return CW_READY;
> if (r == 0)
> return CW_ERROR;
> + if (nread > 0)
> + return CW_READY;
>
> /* perhaps write some buffer lines */
> channel_write_any_lines();
> @@ -3003,6 +3012,7 @@ channel_close_on_error(channel_T *channel, char *func)
> * died. Don't close the channel right away, it may be the wrong moment
> * to invoke callbacks. */
> channel->ch_to_be_closed = TRUE;
> +debuglog("close");
>
> #ifdef FEAT_GUI
> /* Stop listening to GUI events right away. */
> @@ -3033,9 +3043,6 @@ channel_read(channel_T *channel, int part, char *func)
> sock_T fd;
> int use_socket = FALSE;
>
> -/* If we detected a read error don't try reading again. */
> -if (channel->ch_to_be_closed)
> - return;
>
> fd = channel->ch_part[part].ch_fd;
> if (fd == INVALID_FD)
> @@ -3045,6 +3052,14 @@ channel_read(channel_T *channel, int part, char *func)
> }
> use_socket = fd == channel->CH_SOCK_FD;
>
> +{
> + DWORD nread;
> + int r = PeekNamedPipe((HANDLE)fd, NULL, 0, NULL, , NULL);
> + char buff[256];
> + sprintf(buff, "let's read %ld, %d", nread, r);
> + debuglog(buff);
> +}
> +
> /* Allocate a buffer to read into. */
> if (buf == NULL)
> {
> ---
>
> The output become:
>
> polling 0, 1, 0
> polling 0, 1, 0
> polling 0, 1, 0
> polling 0, 1, 0
> polling 0, 0, 109
> close
> polling 18, 1, 0
> let's read 18, 1
> polling 18, 1, 0
>
> Then, I check GetLastError() to ignore ERROR_BROKEN_BUFFER that occur
> when process exited.
Surprising to see that first it returns an error and then later shows
bytes are available to readl. So ignoring code 109 (I believe that's
ERROR_BROKEN_PIPE) seems appropriate.
--
hundred-and-one symptoms of being an internet addict:
170. You introduce your wife as "my_l...@home.wife" and refer to your
children as "forked processes."
/// Bram Moolenaar -- b...@moolenaar.net -- http://www.Moolenaar.net \\\
///sponsor Vim, vote for features -- http://www.Vim.org/sponsor/ \\\
\\\ an exciting new programming language -- http://www.Zimbu.org///
\\\help me help AIDS victims -- http://ICCF-Holland.org///
--
--
You received this message from the "vim_dev" maillist.
Do not top-post! Type your reply below the text you are replying to.
For more information, visit http://www.vim.org/maillist.php
---
You received this message because you are subscribed to the Google Groups
"vim_dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to vim_dev+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
Re: callback is not called when job exit immediately.
Yasuhiro Matsumoto wrote: > > Isn't the best solution then to have channel_wait() not return an error? > > Or is there some way to detect the situation, perhaps by using > > LastError(). At least it should only affect Windows, since on Unix we > > don't want to make this exception. > > I say again, This is posssible to be reproduced on Linux. How? Perhaps by inserting a delay somewhere? We could do something like "read once after the pipe was closed" but without being able to reproduce it I won't know if it actually works. -- hundred-and-one symptoms of being an internet addict: 169. You hire a housekeeper for your home page. /// Bram Moolenaar -- b...@moolenaar.net -- http://www.Moolenaar.net \\\ ///sponsor Vim, vote for features -- http://www.Vim.org/sponsor/ \\\ \\\ an exciting new programming language -- http://www.Zimbu.org/// \\\help me help AIDS victims -- http://ICCF-Holland.org/// -- -- You received this message from the "vim_dev" maillist. Do not top-post! Type your reply below the text you are replying to. For more information, visit http://www.vim.org/maillist.php --- You received this message because you are subscribed to the Google Groups "vim_dev" group. To unsubscribe from this group and stop receiving emails from it, send an email to vim_dev+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: callback is not called when job exit immediately.
On Tuesday, September 6, 2016 at 12:01:35 AM UTC+9, mattn wrote: > Below's change fixes this issue, and not break tests. > > https://gist.github.com/214b61186e2fe091fa65e2b6fbaa8069 > > Thanks. Ah, sorry noisy. Still wrong... -- -- 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: callback is not called when job exit immediately.
Below's change fixes this issue, and not break tests. https://gist.github.com/214b61186e2fe091fa65e2b6fbaa8069 Thanks. -- -- 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: callback is not called when job exit immediately.
behavior is I expected. but tests are failing with my patch. >From test_channel.vim: Found errors in Test_out_close_cb(): function RunTheTest[9]..Test_out_close_cb line 26: Expected 2 but got 0 Found errors in Test_pipe_to_buffer_name(): function RunTheTest[9]..Test_pipe_to_buffer_name[1]..Run_test_pipe_to_buffer line 35: Expected 'yes' but got 'no' Found errors in Test_pipe_to_buffer_name_nomod(): Caught exception in Test_pipe_to_buffer_name_nomod(): Vim(sleep):E117: Unknown function: CloseHandler @ function RunTheTest[9]..Test_pipe_to_buffer_name_nomod[1]..Run_test_pipe_to_buffer[28]..WaitFor, line 20 Found errors in Test_read_in_close_cb(): function RunTheTest[9]..Test_read_in_close_cb line 15: Expected 'quit' but got '' -- -- 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: callback is not called when job exit immediately.
On Monday, September 5, 2016 at 11:30:42 AM UTC+9, mattn wrote:
> > Isn't the best solution then to have channel_wait() not return an error?
> > Or is there some way to detect the situation, perhaps by using
> > LastError(). At least it should only affect Windows, since on Unix we
> > don't want to make this exception.
>
> I say again, This is posssible to be reproduced on Linux.
While the process alive, stdout is not filled in the buffer. But when the
process exited, buffer should be flushed. So if we change this like below to
debug output,
---
diff --git a/src/channel.c b/src/channel.c
index 10ed42e..15a3f72 100644
--- a/src/channel.c
+++ b/src/channel.c
@@ -59,6 +59,12 @@ static void channel_read(channel_T *channel, int part, char
*func);
/* Whether a redraw is needed for appending a line to a buffer. */
static int channel_need_redraw = FALSE;
+static void debuglog(char* buf) {
+ FILE *fp = fopen("debug.log", "a");
+ fprintf(fp, "%s\n", buf);
+ fclose(fp);
+}
+
/* Whether we are inside channel_parse_messages() or another situation where it
* is safe to invoke callbacks. */
static int safe_to_invoke_callback = 0;
@@ -2894,11 +2900,14 @@ channel_wait(channel_T *channel, sock_T fd, int timeout)
while (TRUE)
{
int r = PeekNamedPipe((HANDLE)fd, NULL, 0, NULL, , NULL);
+ char buff[256];
+ sprintf(buff, "polling %ld, %d, %ld", nread, r, GetLastError());
+ debuglog(buff);
- if (r && nread > 0)
- return CW_READY;
if (r == 0)
return CW_ERROR;
+ if (nread > 0)
+ return CW_READY;
/* perhaps write some buffer lines */
channel_write_any_lines();
@@ -3003,6 +3012,7 @@ channel_close_on_error(channel_T *channel, char *func)
* died. Don't close the channel right away, it may be the wrong moment
* to invoke callbacks. */
channel->ch_to_be_closed = TRUE;
+debuglog("close");
#ifdef FEAT_GUI
/* Stop listening to GUI events right away. */
@@ -3033,9 +3043,6 @@ channel_read(channel_T *channel, int part, char *func)
sock_T fd;
intuse_socket = FALSE;
-/* If we detected a read error don't try reading again. */
-if (channel->ch_to_be_closed)
- return;
fd = channel->ch_part[part].ch_fd;
if (fd == INVALID_FD)
@@ -3045,6 +3052,14 @@ channel_read(channel_T *channel, int part, char *func)
}
use_socket = fd == channel->CH_SOCK_FD;
+{
+ DWORD nread;
+ int r = PeekNamedPipe((HANDLE)fd, NULL, 0, NULL, , NULL);
+ char buff[256];
+ sprintf(buff, "let's read %ld, %d", nread, r);
+ debuglog(buff);
+}
+
/* Allocate a buffer to read into. */
if (buf == NULL)
{
---
The output become:
polling 0, 1, 0
polling 0, 1, 0
polling 0, 1, 0
polling 0, 1, 0
polling 0, 0, 109
close
polling 18, 1, 0
let's read 18, 1
polling 18, 1, 0
Then, I check GetLastError() to ignore ERROR_BROKEN_BUFFER that occur when
process exited.
diff --git a/src/channel.c b/src/channel.c
index 10ed42e..c465be7 100644
--- a/src/channel.c
+++ b/src/channel.c
@@ -2888,17 +2888,18 @@ channel_wait(channel_T *channel, sock_T fd, int timeout)
DWORD nread;
int sleep_time;
DWORD deadline = GetTickCount() + timeout;
- int delay = 1;
+ int r, delay = 1;
/* reading from a pipe, not a socket */
while (TRUE)
{
- int r = PeekNamedPipe((HANDLE)fd, NULL, 0, NULL, , NULL);
+ nread = 0;
+ r = PeekNamedPipe((HANDLE)fd, NULL, 0, NULL, , NULL);
- if (r && nread > 0)
- return CW_READY;
- if (r == 0)
+ if (r == 0 && GetLastError() != ERROR_BROKEN_PIPE)
return CW_ERROR;
+ if (nread > 0)
+ return CW_READY;
/* perhaps write some buffer lines */
channel_write_any_lines();
diff --git a/src/testdir/shared.vim b/src/testdir/shared.vim
index 24b05be..cdf4c53 100644
--- a/src/testdir/shared.vim
+++ b/src/testdir/shared.vim
@@ -121,10 +121,10 @@ func WaitFor(expr)
for i in range(100)
try
if eval(a:expr)
- if has('reltime')
- return float2nr(reltimefloat(reltime(start)) * 1000)
- endif
- return slept
+if has('reltime')
+ return float2nr(reltimefloat(reltime(start)) * 1000)
+endif
+return slept
endif
catch
endtry
https://gist.github.com/80bbdb9d27b62e0f37c86f8f2e112b34
--
--
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
Re: callback is not called when job exit immediately.
> Isn't the best solution then to have channel_wait() not return an error? > Or is there some way to detect the situation, perhaps by using > LastError(). At least it should only affect Windows, since on Unix we > don't want to make this exception. I say again, This is posssible to be reproduced on Linux. -- -- 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: callback is not called when job exit immediately.
Yasuhiro Matsumoto wrote:
> On Sunday, September 4, 2016 at 11:19:35 PM UTC+9, Bram Moolenaar wrote:
> > Yasuhiro Matsumoto wrote:
> >
> > > When the job exit immediately, channel->ch_to_be_closed will be TRUE
> > > before channel_read even though the output buffer is filled enough to
> > > read. For example, following command doesn't output result of the job.
> > >
> > > -
> > > function! Disp(ch, msg)
> > > echom a:msg
> > > endfunction
> > >
> > > function! PerlCheck()
> > > let s:job = job_start("perl -cw ".expand("%"), { "callback" :
> > > function("Disp") })
> > > endfunction
> > > -
> >
> > I cannot reproduce the problem. Does this only happen on MS-Windows
> > perhaps?
> >
> > > Below is a patch to fix this. This change doesn't break any tests.
> > >
> > > https://gist.github.com/130f41a825ec72ccddb55b189d11558f
> >
> > It looks like the change in channel_wait() is a no-op.
> > So the essential thing is to ignore ch_to_be_closed in channel_read().
> > Can you explain how we would get there with ch_to_be_closed set while
> > there is still something to read? It should only happen after reading
> > failed.
> >
> > Hmm, is it because PeekNamedPipe() returns zero but there is still
> > something to read?
>
> Yes, Right. stdout/stdin/stderr is buffer(s). So can't ignore output
> even though the jo was exited.
Isn't the best solution then to have channel_wait() not return an error?
Or is there some way to detect the situation, perhaps by using
LastError(). At least it should only affect Windows, since on Unix we
don't want to make this exception.
--
hundred-and-one symptoms of being an internet addict:
164. You got out to buy software, instead of going out for a beer.
/// Bram Moolenaar -- b...@moolenaar.net -- http://www.Moolenaar.net \\\
///sponsor Vim, vote for features -- http://www.Vim.org/sponsor/ \\\
\\\ an exciting new programming language -- http://www.Zimbu.org///
\\\help me help AIDS victims -- http://ICCF-Holland.org///
--
--
You received this message from the "vim_dev" maillist.
Do not top-post! Type your reply below the text you are replying to.
For more information, visit http://www.vim.org/maillist.php
---
You received this message because you are subscribed to the Google Groups
"vim_dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to vim_dev+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
Re: callback is not called when job exit immediately.
Additional, I could reproduce this on Linux. http://go-gyazo.appspot.com/d1ac2f988bba9549.png -- -- 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: callback is not called when job exit immediately.
On Sunday, September 4, 2016 at 11:19:35 PM UTC+9, Bram Moolenaar wrote:
> Yasuhiro Matsumoto wrote:
>
> > When the job exit immediately, channel->ch_to_be_closed will be TRUE
> > before channel_read even though the output buffer is filled enough to
> > read. For example, following command doesn't output result of the job.
> >
> > -
> > function! Disp(ch, msg)
> > echom a:msg
> > endfunction
> >
> > function! PerlCheck()
> > let s:job = job_start("perl -cw ".expand("%"), { "callback" :
> > function("Disp") })
> > endfunction
> > -
>
> I cannot reproduce the problem. Does this only happen on MS-Windows
> perhaps?
>
> > Below is a patch to fix this. This change doesn't break any tests.
> >
> > https://gist.github.com/130f41a825ec72ccddb55b189d11558f
>
> It looks like the change in channel_wait() is a no-op.
> So the essential thing is to ignore ch_to_be_closed in channel_read().
> Can you explain how we would get there with ch_to_be_closed set while
> there is still something to read? It should only happen after reading
> failed.
>
> Hmm, is it because PeekNamedPipe() returns zero but there is still
> something to read?
Yes, Right. stdout/stdin/stderr is buffer(s). So can't ignore output even
though the jo was exited.
--
--
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: callback is not called when job exit immediately.
Yasuhiro Matsumoto wrote:
> When the job exit immediately, channel->ch_to_be_closed will be TRUE
> before channel_read even though the output buffer is filled enough to
> read. For example, following command doesn't output result of the job.
>
> -
> function! Disp(ch, msg)
> echom a:msg
> endfunction
>
> function! PerlCheck()
> let s:job = job_start("perl -cw ".expand("%"), { "callback" :
> function("Disp") })
> endfunction
> -
I cannot reproduce the problem. Does this only happen on MS-Windows
perhaps?
> Below is a patch to fix this. This change doesn't break any tests.
>
> https://gist.github.com/130f41a825ec72ccddb55b189d11558f
It looks like the change in channel_wait() is a no-op.
So the essential thing is to ignore ch_to_be_closed in channel_read().
Can you explain how we would get there with ch_to_be_closed set while
there is still something to read? It should only happen after reading
failed.
Hmm, is it because PeekNamedPipe() returns zero but there is still
something to read?
--
hundred-and-one symptoms of being an internet addict:
163. You go outside for the fresh air (at -30 degrees) but open the
window first to hear new mail arrive.
/// Bram Moolenaar -- b...@moolenaar.net -- http://www.Moolenaar.net \\\
///sponsor Vim, vote for features -- http://www.Vim.org/sponsor/ \\\
\\\ an exciting new programming language -- http://www.Zimbu.org///
\\\help me help AIDS victims -- http://ICCF-Holland.org///
--
--
You received this message from the "vim_dev" maillist.
Do not top-post! Type your reply below the text you are replying to.
For more information, visit http://www.vim.org/maillist.php
---
You received this message because you are subscribed to the Google Groups
"vim_dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to vim_dev+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
callback is not called when job exit immediately.
Hi.
When the job exit immediately, channel->ch_to_be_closed will be TRUE before
channel_read even though the output buffer is filled enough to read. For
example, following command doesn't output result of the job.
-
function! Disp(ch, msg)
echom a:msg
endfunction
function! PerlCheck()
let s:job = job_start("perl -cw ".expand("%"), { "callback" :
function("Disp") })
endfunction
-
Below is a patch to fix this. This change doesn't break any tests.
https://gist.github.com/130f41a825ec72ccddb55b189d11558f
Thanks.
- mattn
--
--
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.
