Re: [Haskell-cafe] When the gauge depends on what it measures
On 14 February 2013 20:56, Gregory Collins wrote: > While you're benchmarking, rename the library under test and/or its modules. > Criterion won't conflict with "new-pretty". Alternatively, don't ever actually install your new pretty and just do "cabal configure --enable-benchmarks && cabal build && cabal bench" (assuming the benchmark is within the pretty package itself)? > > G > > > On Thu, Feb 14, 2013 at 10:11 AM, Alexander Bernauer > wrote: >> >> Hi, >> >> I am currently working on benchmarking the pretty library. >> >> Pretty itself has no non-trivial dependencies. But criterion and >> language-c, which I use to perform the benchmarks, directly and/or >> indirectly depend on pretty. Everything is configured in one Cabal file via >> library and benchmark sections. >> >> Now, whenever I modify pretty and want to rebuild the bench executable, >> things become messy. Either I rebuild criterion et al. as well, or the bench >> executable ends up with two different pretty version built in - if this is >> even possible. >> >> Until now I could not find a robust workflow for this scenario. At some >> point pretty "shadows" itself and the build fails (c.f. my previous caffee >> post). >> >> What is the right way to handle this scenario? >> >> Confused greetings, >> >> Alex >> >> >> ___ >> Haskell-Cafe mailing list >> Haskell-Cafe@haskell.org >> http://www.haskell.org/mailman/listinfo/haskell-cafe >> > > > > -- > Gregory Collins > > ___ > Haskell-Cafe mailing list > Haskell-Cafe@haskell.org > http://www.haskell.org/mailman/listinfo/haskell-cafe > -- Ivan Lazar Miljenovic ivan.miljeno...@gmail.com http://IvanMiljenovic.wordpress.com ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] When the gauge depends on what it measures
On 14 February 2013 13:11, Alexander Bernauer wrote: > Hi, > > I am currently working on benchmarking the pretty library. > > ... skip ... > > What is the right way to handle this scenario? > I simply create symlink to source tree and build benchmark with ghc --make ... ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] When the gauge depends on what it measures
While you're benchmarking, rename the library under test and/or its modules. Criterion won't conflict with "new-pretty". G On Thu, Feb 14, 2013 at 10:11 AM, Alexander Bernauer wrote: > Hi, > > I am currently working on benchmarking the pretty library. > > Pretty itself has no non-trivial dependencies. But criterion and > language-c, which I use to perform the benchmarks, directly and/or > indirectly depend on pretty. Everything is configured in one Cabal file via > library and benchmark sections. > > Now, whenever I modify pretty and want to rebuild the bench executable, > things become messy. Either I rebuild criterion et al. as well, or the > bench executable ends up with two different pretty version built in - if > this is even possible. > > Until now I could not find a robust workflow for this scenario. At some > point pretty "shadows" itself and the build fails (c.f. my previous caffee > post). > > What is the right way to handle this scenario? > > Confused greetings, > > Alex > > ___ > Haskell-Cafe mailing list > Haskell-Cafe@haskell.org > http://www.haskell.org/mailman/listinfo/haskell-cafe > > -- Gregory Collins ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] When the gauge depends on what it measures
Hi, I am currently working on benchmarking the pretty library. Pretty itself has no non-trivial dependencies. But criterion and language-c, which I use to perform the benchmarks, directly and/or indirectly depend on pretty. Everything is configured in one Cabal file via library and benchmark sections. Now, whenever I modify pretty and want to rebuild the bench executable, things become messy. Either I rebuild criterion et al. as well, or the bench executable ends up with two different pretty version built in - if this is even possible. Until now I could not find a robust workflow for this scenario. At some point pretty "shadows" itself and the build fails (c.f. my previous caffee post). What is the right way to handle this scenario? Confused greetings, Alex ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
