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.
> > > 2) when my server sends data back to vim only the first message is
> > > received. This can be reproduced by the demoserver.py example. Just
> > > double the lines in `ThreadedTCPRequestHandler.handle`:
> > > print("sending {}".format(encoded))
> > > self.request.sendall(encoded.encode('utf-8'))
> > > print("sending {}".format(encoded))
> > > self.request.sendall(encoded.encode('utf-8'))
> > >
> > > And vim will only get the first message. It would be nice if the socket
> > > was reading until explicitly closed by the server. It would be useful
> > > for my case to send updates from the background process spawn by the
> > > server
> > > that I wrote.
> >
> > If you are using raw messages Vim has no clue where a message ends and
> > whether there is more coming. Vim should get the second message, but
> > possibly only in the next read. If it never arrives there can be a bug.
> > I just fixed one where raw messages were dropped when there is no
> > handler.
>
> I am using the default `json` messages. I found that this works fine,
> from the server:
>
> socket.write(JSON.stringify([0, ["ex", "call MyHandler('" + msg + "')"]);
>
> the problem with this approach is to encode msg properly so that it
> does not contain any `'` which would be misinterpreted by vim when
> evaluating the expression.
>
>
> > I just added the ch_logfile() function, that will be useful to find out
> > what is happening.
>
> Great, I will try and check what is going on.
--
hundred-and-one symptoms of being an internet addict:
246. You use up your free 1 Gbyte in two days.
/// 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.
