On 21:09 Sun 14 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, > > 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. Best regards, Marcin -- -- 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
