I managed to build one on top of attoparsec's lazy parser that "seems
to work" -- but I'd like ghc to flush a bit more regularly so I could
test it better.
-- Don
On Sun, May 1, 2011 at 7:59 PM, Bryan O'Sullivan wrote:
> On Thu, Apr 28, 2011 at 3:00 PM, Don Stewart wrote:
>>
>> So we'd need a l
On Thu, Apr 28, 2011 at 3:00 PM, Don Stewart wrote:
> So we'd need a lazy (or incremental) parser, that'll return a list of
> successful event parses, then block. I suspect this mode would be
> supported.
>
A while ago, I hacked something together on top of the current eventlog
parser that would
I've got a proof of concept event-log monitoring server and
incremental parser for event streams:
* http://code.haskell.org/~dons/code/ghc-events-stream/
* http://code.haskell.org/~dons/code/ghc-monitor/
Little screen shot of the snap server running, watching a Haskell
process' eventlog fifo:
On Thu, 2011-04-28 at 23:31 +0200, Johan Tibell wrote:
> The RTS would invoke listeners every time a new event is written. This
> design has many benefits:
>
> - We don't need to introduce the serialization, deserialization, and
> I/O overhead of first writing the eventlog to file and then parsin
I've put a library for incremental parsing of the event log here:
http://code.haskell.org/~dons/code/ghc-events-stream/
The goal is to implement something like:
http://www.erlang.org/doc/man/heart.html
On Sun, May 1, 2011 at 1:44 AM, Johan Tibell wrote:
> On Fri, Apr 29, 2011 at 12:00
On Fri, Apr 29, 2011 at 12:00 AM, Don Stewart wrote:
> I'm very interested in what the best way to get incremental event data
> from a running GHC process would be.
>
> Looking at the code, we flush the event buffer fairly regularly, but
> the event parser is currently strict.
>
> So we'd need a l
On Thu, Apr 28, 2011 at 11:53 PM, Donnie Jones wrote:
> Anyway, from your description, I don't understand how a listener would
> consume the eventlog incrementally?
I simply meant that I want to be able to register listeners for events
instead of having to parse the eventlog file after the fact.
I'm very interested in what the best way to get incremental event data
from a running GHC process would be.
Looking at the code, we flush the event buffer fairly regularly, but
the event parser is currently strict.
So we'd need a lazy (or incremental) parser, that'll return a list of
successful e
Hello Johan,
I did the initial implementation of GHC.Eventlog. Sadly, I haven't
had time to work on it since starting a full-time job after
university. That being said, I am still interested in GHC and the
improvement of GHC.Eventlog. Hopefully soon, I will have the time to
do more development
