Hi, Am Sonntag, den 08.01.2017, 13:45 -0500 schrieb Ben Gamari:

...

We could also create a cabal and stack files for `nofib-analyse` (making it possible to use some libraries for it).

This would be great. This would allow me to drop a submodule from my own performance monitoring tool.

Exists since last April: http://hackage.haskell.org/package/nofib-analyse Only the binary so far, though, but good enough for "cabal install nofib-analyse". Greetings, Joachim -- Joachim “nomeata” Breitner   mail@joachim-breitner.de • https://www.joachim-breitner.de/   XMPP: nomeata@joachim-breitner.de • OpenPGP-Key: 0xF0FBF51F   Debian Developer: nomeata@debian.org

Hi, Am Montag, den 09.01.2017, 19:48 +0000 schrieb Michal Terepeta:

On Sun, Jan 8, 2017 at 10:56 PM Joachim Breitner wrote:

...

Hi,

Am Sonntag, den 08.01.2017, 13:45 -0500 schrieb Ben Gamari:

...

...

We could also create a cabal and stack files for `nofib-analyse` (making it possible to use some libraries for it).

This would be great. This would allow me to drop a submodule from my own performance monitoring tool.

Exists since last April: http://hackage.haskell.org/package/nofib-analyse

Only the binary so far, though, but good enough for "cabal install nofib-analyse".

Oh, interesting! But now I'm a bit confused - what's the relationship

...

between https://github.com/nomeata/nofib-analyse and https://git.haskell.org/nofib.git, e.g., is the github repo the upstream for nofib-anaylse and the haskell.org one for the other parts of nofib? Or is the github one just a mirror and all patches should go to haskell.org repo?

my repo occasionally pulls in the nofib-analyse directory from the haskell.org nofib repo; see for example this commit (especially its message): https://github.com/nomeata/nofib-analyse/commit/8225e0dd84c3c31cd156d10df75e... So yes, patches go to the haskell.org nofib repo (or Phab or whatever). Greetings, Joachim -- Joachim “nomeata” Breitner   mail@joachim-breitner.de • https://www.joachim-breitner.de/   XMPP: nomeata@joachim-breitner.de • OpenPGP-Key: 0xF0FBF51F   Debian Developer: nomeata@debian.org

My time for this ticket run out and for the foreseeable future I won't be able to do much. We can discuss ideas if you have some. The part of nofib that is called fibno should be replaced with latest version of packages and permanently connected to the test suite. Or removed. This is the only sure conclusion I came to. Everything else is up for debate. W dniu wt., 10.01.2017 o 20:43 Michal Terepeta napisał(a):

On Tue, Jan 10, 2017 at 11:35 AM Gracjan Polak wrote:

...

I was looking nearby recently and you might want to take into account my discoveries described in https://ghc.haskell.org/trac/ghc/ticket/11501

Thanks a lot for mentioning it! (I didn't see this ticket/discussion)

I don't want to get in your way - did you already start working on something? Do you have some concrete plans wrt. nofib?

From my side, I was recently mostly interested in using nofib to measure the performance of GHC itself. Nofib already tries to do that, but it's super flaky (it only compiles things once and most modules are small). So I was thinking of improving this, but when I started to look into it a bit closer, I decided that it might be better to start with the build system ;) And then add options to compile things more than once, add some compile-time only benchmarks, etc.

Thanks, Michal