
Hmmm.... I'll take a look, but from what I see - it uses the same code as
ghc-events for decoding and all the streaming done in a short single commit
- it must suffer the same bug then. It is not a single stream of events,
it's several of them per capability mixed due to caching done by RTS so you
need to decode several streams at once and merge the results.
On Oct 1, 2017 20:43, "Boespflug, Mathieu"
You might want to have a look at https://github.com/mboes/ghc-events/tree/streaming. Similar to what you mention, it uses the "streaming" package for the incremental parsing. I ran into an issue with binary that I wasn't able to track down: even medium sized buffers make the parsing slower (significantly so) rather than faster (my suspicion: something somewhere that should be constant time is actually linear). -- Mathieu Boespflug Founder at http://tweag.io.
On 1 October 2017 at 14:34, Michael Baikov
wrote: On Sun, Oct 1, 2017 at 8:09 PM, Boespflug, Mathieu
wrote: Note that the (AFAIK unreleased) version of ghc-events on the master branch of the upstream repo can parse event streams incrementally, if that's what you meant.
It can but it got some problems. For one the only thing incremental parser can do is to print the output - for everything else old parser will be used and output of that incremental is partially out of order due to the way event blocks are stored. Anyway, I already have my own version that does proper incremental parsing, provides interface with a streaming library and collects some info that wasn't available in the original version. How it's more about shuffling stuff around, cleaning and testing.