Plan of Attack for Parallel Builds

[Max Bolingbroke]

On 30 March 2011 09:37, Simon Meier <iridcode at gmail.com> wrote:
> Probably some more filtering of this sequence is required to cater for
> repeated calls to GHC. I guess that, as long as progress never goes from
> 100% to something below, the user will be happy about the progress estimate.
> Moreover, the chance that such a pattern occurs where it doesn't indicate
> some interesting progress is reasonably low.

An coworker of mine back in the day had a great hack for reporting the
progress of loading up a GUI application written in his framework.
Basically, he watched what logging calls were made by the app. He also
kept a record of the strings that got logged *last* time the app
started up, as well, and maintained a pointer into it during app
startup. If he saw a match (to within some edit distance) between a
newly-logged message and previously-logged one occurring **after the
pointer** then he moved the pointer forward to that previously-logged
entry. He could then get a % estimate of how started the program was
by looking at how far the pointer had gone along the log from last
time.

The really cute thing about this is that as the user of his GUI
framework you didn't have to worry about progress reporting at all -
just write a few logging calls as you would normally and it just
magically worked :-)

Unfortunately I can't see a way to apply this to Cabal without a lot
of engineering (e.g. Hackage could record the build output
stderr/stdout for a package and then transmit it down to a new client
building a package). Probably not worth it!

Cheers,
Max