> That doesn't look right, because there should not be a complete json message.
> If there is, perhaps a call to parse it is missing?
> Perhaps a call to channel_parse_json() is needed.
Yes, maybe there is a channel_parse_json() missing somewhere. But as the flow
log shows it's also a channel_parse_messages()-call missing.
> If the JSON is incomplete we need to receive more text to be able to parse
> it. Thus we might as well block on receiving something.
Thing is, I think that the JSON is actually complete, but since
channel_parse_messages() isn't called it never gets the chance to parse the
JSON content. That's how I read the logs at least.
> So what is in those 64 bytes? If you look in the channel log it should be
> there. You don't quote from a channel log, did you use ch_logfile()?
That was just pseudo-logs handwritten :) I ran it again and this time include
what is actually read from the channel in channel_read().
Since I do get a few signs placed I can see in the log how it looks like when
it works, this is one of the signs that gets placed:
RealWaitForChar() is called with 0 delay
channel_read() is called from RealWaitForChar(), it reads 63 bytes into the
buffer
channel_save() is called from channel_read() with the buffer that starts with:
[0,[34,"call","sign_place",0,"govim","govimerr",1,{"lnum":6}]] (and 0x0a at the
end)
RealWaitForChar() is called with 0 delay
RealWaitForChar() is called with 0 delay
RealWaitForChar() is called with 0 delay
channel_parse_messages() is called from parse_queued_messages()
channel_peek is called (for part 0)
channel_get_json is called
channel_parse_json is called
channel_peek is called (for part 1)
channel_get_json is called
channel_peek is called (for part 0)
channel_get_json is called
channel_parse_json is called
channel_peek is called (for part 1)
channel_get_json is called
channel_get_json is called
channel_parse_json is called
channel_peek is called (for part 2)
channel_get_json is called
And when it doesn't work it never gets to the channel_parse_messages() call:
RealWaitForChar() is called with 0 delay
channel_read() is called from RealWaitForChar(), it reads 64 bytes into the
buffer
channel_save() is called from channel_read() with the buffer that starts with:
[0,[41,"call","sign_place",0,"govim","govimerr",1,{"lnum":12}]] (and 0x0a at
the end)
RealWaitForChar() is called with 0 delay
RealWaitForChar() is called with 0 delay
RealWaitForChar() is called with 0 delay
channel_peek is called (part 0, I don't know from where)
channel_peek is called (part 0, I don't know from where)
RealWaitForChar() is called with -1 (as wait_func)
Ok, so I see what you referred to with:
> In inchar_loop() it should call parse_queued_messages() before blocking,
I did run again and logged the inchar_loop() calls, there are only two in the
entire run and both with -1 as wtime.
So, we end up inside inchar_loop(), before calling wait_func() with a wait_time
value set to -1 (that will block).
And to ensure that parse_queued_messages() are called before sleeping, either
has_pending_job() or channel_any_readahead() must return TRUE, right?
That would explain why the patch to channel_any_readahead() works, since it
will make it return TRUE?
Or should it be another check to ensure that parse_queued_messages() is called
before blocking?
Best regards, Pontus
--
--
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].
To view this discussion on the web visit
https://groups.google.com/d/msgid/vim_dev/39af4c19-2eaf-4cdd-baef-52ed1094f390%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
