Danek Duvall wrote:
> > Jun Takimoto wrote:
> >
> > > On 2016/02/03, at 7:23, Bram Moolenaar <[email protected]> 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)
There are some vague plans for job control. The idea is that you should
be able to run a job for your plugin. Either one job per Vim, or one
job shared with multiple Vims. And possibly it keeps running when Vim
exits, or it gets killed automatically.
Something like:
let job = job_start('command', {options})
call job_stop(job)
Would also be useful to start a job if we can't open a channel:
let job = job_maystart('command', {address}, {options})
We could also start a job and use stdin/stdout for communication.
That would would be in the options of job_start().
There was an incomplete patch for this more than a year ago.
--
hundred-and-one symptoms of being an internet addict:
121. You ask for e-mail adresses instead of telephone numbers.
/// Bram Moolenaar -- [email protected] -- 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 [email protected].
For more options, visit https://groups.google.com/d/optout.
