Marcin Szamotulski wrote:
> > > > > > > That's a really great feature. I am trying to implemented a gulp
> > > > > > > plugin
> > > > > > > (gulp is a node package used to build web apps) based on channels
> > > > > > > and
> > > > > > > there are two things that I has a problem with:
> > > > > >
> > > > > > Thanks for the feedback. Keep in mind that the feature is still
> > > > > > being
> > > > > > developed. Some things may just be missing. But there can also be
> > > > > > bugs
> > > > > > and things that don't work for you, so feedback is useful anyway.
> > > > >
> > > > > Yes I understand that, the idea is to contribute to the development in
> > > > > some fruitful way.
> > > >
> > > > Note that the type of the channel handle has changed. That mainly
> > > > matters for when checking whether ch_open() worked.
> > > >
> > > > > > > 1) when I use `job_start()` to start a server in the background
> > > > > > > and
> > > > > > > immediately after I call `ch_open()` to open channel to that
> > > > > > > server I am
> > > > > > > always refused: `E896: read from channel: Connection refused`.
> > > > > > >
> > > > > > > However, if I check `job_status` in between (which is what
> > > > > > > I should do anyway), then the following `ch_open` runs fine.
> > > > > > > There is
> > > > > > > no way now to communicate from the job that started that what it
> > > > > > > runs is
> > > > > > > ready to connect to.
> > > > > >
> > > > > > It's normal for a process to have some initialization time before
> > > > > > the
> > > > > > socket is ready for use. This is implemented, it already existed
> > > > > > for
> > > > > > netbeans. Did you add a "waittime" argument? The default is zero.
> > > > >
> > > > > I just tried it:
> > > > > * adding waittime does not help
> > > > > * adding `sleep 1m` before calling `ch_open` solved the problem
> > > > >
> > > > > Which is not what I'd expect.
> > > >
> > > > I assume we need to treat that error as a temporary failure and retry.
> > > > There was a similar problem on Mac, where a 1 msec waittime did work.
> > >
> > > `sleep 100m` is more reliable, with just 1m wait I am getting errors
> > > today,
> >
> > Thus increasing the waittime does not help, but a short sleep between
> > starting the job and ch_open() helps? I think we need to handle a
> > failing connect properly. There is code from Netbeans, but it's waiting
> > too long.
>
> Sorry I wasn't clear enough. The longer wait time does help.
>
> > > When my server crashes, with a `SyntaxError` or a `ReferenceError`
> > > and the socket is not properly closed, I have to kill vim with SIGTERM,
> > > since the cursor gets frozen. This is what `ch_log` reports:
> > >
> > > on 0: Opening channel
> > > on 1: Opening channel
> > > : Connecting to localhost port 3746ERR on 1: channel_select_check():
> > > Cannot read
> > > RECV on 1: '"DETACH"
> > > '
> > > on 1: Closing channelERR on 0: channel_select_check(): Cannot read
> > > RECV on 0: '"DETACH"
> > > '
> > > ERR on 0: channel_select_check(): Cannot read
> >
> > Error handling is tricky. Perhaps Vim hangs in channel_close()?
> > Would be good if you can use a debugger to connect to the hanging Vim
> > and see where it's stuck.
>
> With the most recent version of vim this is gone, sorry I didn't had
> enough time this week to look at it.
Please try the latest version. The waittime didn't actualy work on
Linux, the select() doesn't behave as expected. I made that work,
hopefully it also works for you now.
I also added timestamps to the log, so you can see how long something
takes.
--
FATHER: Who are you?
PRINCE: I'm ... your son ...
FATHER: Not you.
LAUNCELOT: I'm ... er ... Sir Launcelot, sir.
"Monty Python and the Holy Grail" PYTHON (MONTY) PICTURES LTD
/// 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.
