<div dir="ltr"><div><span style="font-family: arial, sans-serif; font-size: 12.8px;">(sorry for duplicates, realized I couldn't post to the mailing list without registering)</span></div><span style="font-family: arial, sans-serif; font-size: 12.8px;"><div><span style="font-family: arial, sans-serif; font-size: 12.8px;"><br></span></div>Hi Ryan,</span><div style="font-family: arial, sans-serif; font-size: 12.8px;"><br></div><div style="font-family: arial, sans-serif; font-size: 12.8px;">I'm the student working on the CI part Joachim mentioned. It's not quite there yet, but the ground work is done. </div><div style="font-family: arial, sans-serif; font-size: 12.8px;"><br></div><div style="font-family: arial, sans-serif; font-size: 12.8px;">Basically, I'm writing a daemon that will read a config file for a list of git repositories, maintain periodically updated clones for them and execute a benchmark script on new (Repository, Commit) pairs, after which gipeda is (re-)run, so that might be exactly what you are looking for. </div><div style="font-family: arial, sans-serif; font-size: 12.8px;"><br></div><div style="font-family: arial, sans-serif; font-size: 12.8px;">You can find the current code at <a href="https://github.com/sgraf812/feed-gipeda" target="_blank" style="color: rgb(17, 85, 204);">https://github.com/<wbr>sgraf812/feed-gipeda</a>. There are still some rough edges (not on Hackage yet, somewhat laborious setup) and documentation is somewhat incomplete, but you can always leave me a mail if you get stuck while setting it up. Also, documentation etc. should come within the next week.</div><div style="font-family: arial, sans-serif; font-size: 12.8px;"><br></div><div style="font-family: arial, sans-serif; font-size: 12.8px;">I'll CC you in the mail thread where we discuss things, if you don't mind.</div><div style="font-family: arial, sans-serif; font-size: 12.8px;"><br></div><div style="font-family: arial, sans-serif; font-size: 12.8px;">Regards,</div><div style="font-family: arial, sans-serif; font-size: 12.8px;">Sebastian</div><br>On Monday, 4 April 2016 22:35:56 UTC+2, Ryan Newton  wrote:<blockquote class="gmail_quote" style="margin: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div dir="ltr"><div><div class="gmail_quote"><div>Great!  I'm glad to hear folks are interested.  </div><div><br></div><div>It sounds like there is need for a better low-dependencies benchmark suite.  I was just grepping through nofib looking for things that are <i>missing</i> and I realized there are no uses of atomicModifyIORef, for example.</div><div><br></div><div>What we're working on at Indiana right this second is not quite this effort, but is the separate, complementary, effort to gather as much data as possible from a large swath of packages (high dependency-count) .</div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">Note that fibon already has bitrotted, and does not quite work any<br>
more. So there is some low hanging fruit in resurrecting that one.<br></blockquote><div><br></div><div><div>Agreed.  Though I see that nofib already contains some of them.  </div><div><br></div><div>Even though stack + GHC head loses many of stack's benefits, I think that stack and cabal freeze should make it easier to keep things running for the long term than it was with fibon (which bitrotted quickly).</div></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
Another important step in that direction would be to define a common<br>
output for benchmark suites defined in .cabal files, so it is easier to<br>
set up things like <a href="http://perf.haskell.org/ghc" rel="nofollow" target="_blank" onmousedown="this.href='http://www.google.com/url?q\75http%3A%2F%2Fperf.haskell.org%2Fghc\46sa\75D\46sntz\0751\46usg\75AFQjCNGBlmzoK8tU6_wkAr2M8mOctfWo-Q';return true;" onclick="this.href='http://www.google.com/url?q\75http%3A%2F%2Fperf.haskell.org%2Fghc\46sa\75D\46sntz\0751\46usg\75AFQjCNGBlmzoK8tU6_wkAr2M8mOctfWo-Q';return true;">http://perf.haskell.org/<wbr>ghc</a> and <a href="http://perf.haskell" rel="nofollow" target="_blank" onmousedown="this.href='http://www.google.com/url?q\75http%3A%2F%2Fperf.haskell\46sa\75D\46sntz\0751\46usg\75AFQjCNERy_Qs98o8poPnOFiEgABWmEdCUQ';return true;" onclick="this.href='http://www.google.com/url?q\75http%3A%2F%2Fperf.haskell\46sa\75D\46sntz\0751\46usg\75AFQjCNERy_Qs98o8poPnOFiEgABWmEdCUQ';return true;">http://perf.haskell</a>.<br>
org/binary for these projects.<br></blockquote><div><br></div><div>Yes, exitcode-stdio-1.0 is useful for testing but not so much for benchmarking.  To attempt to harvest Stackage benchmarks we were going to just assume things are criterion and catch errors as we go.  Should we go further and aim to standardize a new value for "type:" within benchmark suites?</div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
About the harness: <a href="http://haskell.org" rel="nofollow" target="_blank" onmousedown="this.href='http://www.google.com/url?q\75http%3A%2F%2Fhaskell.org\46sa\75D\46sntz\0751\46usg\75AFQjCNGewfSNYl0LKG3GaO2xGT2ELcQarA';return true;" onclick="this.href='http://www.google.com/url?q\75http%3A%2F%2Fhaskell.org\46sa\75D\46sntz\0751\46usg\75AFQjCNGewfSNYl0LKG3GaO2xGT2ELcQarA';return true;">haskell.org</a> is currently paying a student (CCed) to<br>
setup a travis-like infrastructure based on gipeda (the software behind<br>
<a href="http://perf.haskell.org" rel="nofollow" target="_blank" onmousedown="this.href='http://www.google.com/url?q\75http%3A%2F%2Fperf.haskell.org\46sa\75D\46sntz\0751\46usg\75AFQjCNEt3DUrhCNWKfzGrr9Wzlm7nlVwfg';return true;" onclick="this.href='http://www.google.com/url?q\75http%3A%2F%2Fperf.haskell.org\46sa\75D\46sntz\0751\46usg\75AFQjCNEt3DUrhCNWKfzGrr9Wzlm7nlVwfg';return true;">perf.haskell.org</a>) that would allow library authors to very simply get<br>
continuous benchmark measurements. Let’s see what comes out of that!<br></blockquote><div><br></div><div>What's the infrastructure that currently gathers the data for <a href="http://perf.haskell.org" target="_blank" rel="nofollow" onmousedown="this.href='http://www.google.com/url?q\75http%3A%2F%2Fperf.haskell.org\46sa\75D\46sntz\0751\46usg\75AFQjCNEt3DUrhCNWKfzGrr9Wzlm7nlVwfg';return true;" onclick="this.href='http://www.google.com/url?q\75http%3A%2F%2Fperf.haskell.org\46sa\75D\46sntz\0751\46usg\75AFQjCNEt3DUrhCNWKfzGrr9Wzlm7nlVwfg';return true;">perf.haskell.org</a>?  Is there a repo you can point to?  (Since gipeda itself is just the presentation layer, and something else must be running things & gathering data.)</div><div><br></div><div>Cheers,</div><div> -Ryan</div><div><br></div><div><br></div></div></div></div>
</blockquote></div>