On 23:58 Sat 13 Feb , Bram Moolenaar wrote: > > 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,
>
> > > > 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`.
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 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.
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.
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
Best regards,
Marcin
>
> --
> hundred-and-one symptoms of being an internet addict:
> 246. You use up your free 1 Gbyte in two days.
>
> /// 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.
signature.asc
Description: Digital signature
