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.
> > > > > 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.
>
> `ch_logfile` is very helpful. I could see that when I attach a handler
> with `ch_sendexpr` it is invoked only once on a message that has the
> correct ID. I was sending from the server `[requestID, data]` and if
> `requestID` is greater than 0 the callback is invoked only once and this
> seems the intended behaviour of `may_invoke_callback` function in
> channel.c. Reading the source I found that I should rather register the
> callback as a channel callback using `ch_open`.
Correct.
> I think that the user expects that the callback will be called on every
> message with that given `requestID`. The problem might be when to
> un-register the callback. One could for example to check for the
> returned value, if is is false or true and remove it when is it is true.
> I guess this is all about freeing the memory and leaving this up to
> a plugin author might not be a safe option, is that the reason for one
> time callbacks?
The IDs are used to match the response to the request. There must not
be more than one response to the same request. They are considered
duplicates and dropped.
I don't know what you are doing, but if you have multiple responses than
you should probably use the channel callback, not the request callback.
> The current implementation give the same expressive power, since I can
> change some state variable in which is then used by the channel level
> callback that will be invoked. One just has to be careful to send non
> zero requestID to vim only once.
Correct.
> If you want to keep the current behaviour, I think the docs should
> explain this in some detail. I can write a patch for that.
I already made changes to channel.txt. I will add a remark now. Please
re-read the help later when the changes have settled down.
> 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.
--
hundred-and-one symptoms of being an internet addict:
252. You vote for foreign officials.
/// 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.
