February 2012 - Libraries

Template Haskell: dataToExpQ and constructor mis-match
by Conal Elliott 08 Feb '12

08 Feb '12

I'm looking for a reliable way to turn values into Template Haskell expressions. I thought dataToExpQ from Language.Haskell.TH.Quote was the ticket, but it appears to produce constructors different from those produced by [| ... |], including [], (:), (), and (,). Here's an example run for (). I'm using template-haskell-2.5.0.0: GHCi, version 7.0.4: http://www.haskell.org/ghc/ :? for help Prelude> import Data.Data Prelude Data.Data> import Language.Haskell.TH Prelude Data.Data Language.Haskell.TH> :set -XTemplateHaskell Prelude Data.Data Language.Haskell.TH> import Language.Haskell.TH.Quote Prelude Data.Data Language.Haskell.TH Language.Haskell.TH.Quote> u1 <- runQ (dataToExpQ (const Nothing) ()) Prelude Data.Data Language.Haskell.TH Language.Haskell.TH.Quote> u2 <- runQ [| () |] Prelude Data.Data Language.Haskell.TH Language.Haskell.TH.Quote> u1 ConE () Prelude Data.Data Language.Haskell.TH Language.Haskell.TH.Quote> u2 ConE GHC.Unit.() Prelude Data.Data Language.Haskell.TH Language.Haskell.TH.Quote> u1 == u2 False Any suggestions? -- Conal

2 1

Re: [Haskell-cafe] The State of Testing?
by Thomas Tuegel 08 Feb '12

08 Feb '12

On Tue, Feb 7, 2012 at 3:23 PM, Austin Seipp <mad.one(a)gmail.com> wrote: > If you're writing a library, you need to compile the library with > `-fhpc`, i.e. put it in the library stanza, not the testsuite stanza, > and then you can compile the test program using your library - the > resulting 'tix' file will contain the library coverage reports. You > can link a HPC-built library into an executable not compiled with HPC > just fine. > > Normally I only compile the library under HPC mode, link it in a test, > and distribute the results from that. That way your coverage reports > don't include the test module (which may or may not be relevant.) > > I normally add a cabal flag called 'hpc' which optionally enables > coverage reports for my library, e.g. > > flag hpc > default: False > > library > ... > ... > if flag(hpc) > ghc-options: -fhpc > > Then when you want coverage reports, just say 'cabal install -fhpc > --enable-tests' and the resulting properties executable will spit out > the results when run. First, as author of the test suite code, let me apologize for the terrible documentation. This is absolutely NOT how coverage reports are supposed to work. If you configure with '--enable-tests --enable-library-coverage', Cabal will take care of _everything_ else for you, including excluding the test module from the coverage report. You should not have to put any flag gymnastics in your .cabal file. If this doesn't work for you, please let me know, because it's a bug. Thanks! -- Thomas Tuegel

2 1

Proposal: Add getStdGenState and stdGenFromState
by Bas van Dijk 07 Feb '12

07 Feb '12

Dear Ryan, all, To quote the documentation of System.Random: "The Show and Read instances of StdGen provide a primitive way to save the state of a random number generator." Primitive it is indeed. Currently the only way to serialize (using cereal or binary) a StdGen is to convert it to a String and then serialize this String. This takes up many more bytes than are actually needed. I would like to propose a more efficient way of serializing the state of the random number generator by providing the following two functions: getStdGenState :: StdGen -> (Int32, Int32) getStdGenState (StdGen s1 s2) = (s1, s2) stdGenFromState :: (Int32, Int32) -> StdGen stdGenFromState (s1, s2) = StdGen s1 s2 Of course this satisfies: (stdGenFromState . getStdGenState) g == g Alternatively, instead of using (Int32, Int32) we can use an Int64: getStdGenState :: StdGen -> Int64 getStdGenState (StdGen s1 s2) = fromIntegral s1 `unsafeShiftL` 32 .|. fromIntegral s2 #if !MIN_VERSION_base(4,5,0) where unsafeShiftL = shiftL #endif stdGenFromState :: Int64 -> StdGen stdGenFromState s = StdGen (fromIntegral (s `unsafeShiftR` 32)) (fromIntegral s) #if !MIN_VERSION_base(4,5,0) where unsafeShiftR = shiftR #endif I don't really care which one we use but I think the latter is a bit easier to use. Oh, I don't really care about the names either. Regards, Bas

5 7

Re: [Haskell-cafe] The State of Testing?
by Ryan Newton 07 Feb '12

07 Feb '12

By the way, has anyone else had trouble with "cabal test" diverging? I've been running into this issue with cabal 0.10.2, but ONLY in conjunction with GHC 6.12.3. It's hard to make a small reproducer for (and therefore I haven't filed a bug yet), but you can see the below Jenkins run stalled for 2.5 days, whereas it should take minutes: http://tester-lin.soic.indiana.edu:8080/job/monad-par_github_master/JENKINS… Note that it *doesn't* burn CPU -- it deadlocks rather than spins. I replaced "cabal test" with a direct call to the test executable and I haven't seen this problem since. -Ryan On Tue, Feb 7, 2012 at 4:23 PM, Austin Seipp <mad.one(a)gmail.com> wrote: > If you're writing a library, you need to compile the library with > `-fhpc`, i.e. put it in the library stanza, not the testsuite stanza, > and then you can compile the test program using your library - the > resulting 'tix' file will contain the library coverage reports. You > can link a HPC-built library into an executable not compiled with HPC > just fine. > > Normally I only compile the library under HPC mode, link it in a test, > and distribute the results from that. That way your coverage reports > don't include the test module (which may or may not be relevant.) > > I normally add a cabal flag called 'hpc' which optionally enables > coverage reports for my library, e.g. > > flag hpc > default: False > > library > ... > ... > if flag(hpc) > ghc-options: -fhpc > > Then when you want coverage reports, just say 'cabal install -fhpc > --enable-tests' and the resulting properties executable will spit out > the results when run. > > On Tue, Feb 7, 2012 at 3:16 PM, Michael Craig <mkscrg(a)gmail.com> wrote: > > Thanks for the advice, all. I've got test-framework, quickcheck, and > cabal's > > test-suite all working together nicely. > > > > Cabal seems to support using hpc to check test coverage. If I add -fhpc > to > > the ghc-options under the test-suite, I get output like "Test coverage > > report written to dist/hpc/html/tests/hpc_index.html" and "Package > coverage > > report written to dist/hpc/html/test-0.0.0/hpc_index.html", but those > html > > files are just empty tables. How does this work? > > > > Mike Craig > > > > > > > > > > On Thu, Feb 2, 2012 at 8:45 PM, Ivan Lazar Miljenovic > > <ivan.miljenovic(a)gmail.com> wrote: > >> > >> On 03/02/2012 12:22 PM, "Johan Tibell" <johan.tibell(a)gmail.com> wrote: > >> > > >> > On Thu, Feb 2, 2012 at 4:46 PM, Conrad Parker <conrad(a)metadecks.org> > >> > wrote: > >> >> > >> >> On 3 February 2012 08:30, Johan Tibell <johan.tibell(a)gmail.com> > wrote: > >> >> > On Thu, Feb 2, 2012 at 4:19 PM, Conrad Parker < > conrad(a)metadecks.org> > >> >> > wrote: > >> >> >> > >> >> >> I've followed what Johan Tibbell did in the hashable package: > >> >> > > >> >> > > >> >> > If I had known how much confusion my childhood friends would > unleash > >> >> > on the > >> >> > Internet when they, at age 7, gave me a nickname that's spelled > >> >> > slightly > >> >> > differently from my last name, I would have asked them to pick > >> >> > another one. > >> >> > ;) > >> >> > >> >> lol, sorry, I actually double-checked the number of l's before > writing > >> >> that but didn't consider the b's. For future reference I've produced > a > >> >> handy chart: > >> >> > >> >> > >> >> > >> >> Letter | Real-name count | Nickname count > >> >> -------+-----------------+--------------- > >> >> b | 1 | 2 > >> >> l | 2 | 0 > >> >> -------+-----------------+--------------- > >> >> SUM | 3 | 2 > >> >> > >> > > >> > Excellent. I will tattoo it on my forehead. > >> > >> There is, of course, a simpler (but not necessarily easier :p) solution: > >> change your name to match your nickname! > >> > >> > > >> > > >> > _______________________________________________ > >> > Haskell-Cafe mailing list > >> > Haskell-Cafe(a)haskell.org > >> > http://www.haskell.org/mailman/listinfo/haskell-cafe > >> > > >> > >> > >> _______________________________________________ > >> Haskell-Cafe mailing list > >> Haskell-Cafe(a)haskell.org > >> http://www.haskell.org/mailman/listinfo/haskell-cafe > >> > > > > > > _______________________________________________ > > Haskell-Cafe mailing list > > Haskell-Cafe(a)haskell.org > > http://www.haskell.org/mailman/listinfo/haskell-cafe > > > > > > -- > Regards, > Austin > > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe(a)haskell.org > http://www.haskell.org/mailman/listinfo/haskell-cafe >

2 1

Re: [Haskell-cafe] The State of Testing?
by Michael Craig 07 Feb '12

07 Feb '12

Thanks for the advice, all. I've got test-framework, quickcheck, and cabal's test-suite all working together nicely. Cabal seems to support using hpc to check test coverage. If I add -fhpc to the ghc-options under the test-suite, I get output like "Test coverage report written to dist/hpc/html/tests/hpc_index.html" and "Package coverage report written to dist/hpc/html/test-0.0.0/hpc_index.html", but those html files are just empty tables. How does this work? Mike Craig On Thu, Feb 2, 2012 at 8:45 PM, Ivan Lazar Miljenovic < ivan.miljenovic(a)gmail.com> wrote: > On 03/02/2012 12:22 PM, "Johan Tibell" <johan.tibell(a)gmail.com> wrote: > > > > On Thu, Feb 2, 2012 at 4:46 PM, Conrad Parker <conrad(a)metadecks.org> > wrote: > >> > >> On 3 February 2012 08:30, Johan Tibell <johan.tibell(a)gmail.com> wrote: > >> > On Thu, Feb 2, 2012 at 4:19 PM, Conrad Parker <conrad(a)metadecks.org> > wrote: > >> >> > >> >> I've followed what Johan Tibbell did in the hashable package: > >> > > >> > > >> > If I had known how much confusion my childhood friends would unleash > on the > >> > Internet when they, at age 7, gave me a nickname that's spelled > slightly > >> > differently from my last name, I would have asked them to pick > another one. > >> > ;) > >> > >> lol, sorry, I actually double-checked the number of l's before writing > >> that but didn't consider the b's. For future reference I've produced a > >> handy chart: > >> > >> > >> > >> Letter | Real-name count | Nickname count > >> -------+-----------------+--------------- > >> b | 1 | 2 > >> l | 2 | 0 > >> -------+-----------------+--------------- > >> SUM | 3 | 2 > >> > > > > Excellent. I will tattoo it on my forehead. > > There is, of course, a simpler (but not necessarily easier :p) solution: > change your name to match your nickname! > > > > > > > _______________________________________________ > > Haskell-Cafe mailing list > > Haskell-Cafe(a)haskell.org > > http://www.haskell.org/mailman/listinfo/haskell-cafe > > > > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe(a)haskell.org > http://www.haskell.org/mailman/listinfo/haskell-cafe > >

1 0

Improve System.Environment haddocks
by Gwern Branwen 07 Feb '12

07 Feb '12

17:52:34 < goodgrue> Is there a way to change the environment variables associated with Xmonad.Prompt.Shell at runtime? e.g. I'd like to be able to modify $http_proxy and have that affect subsequently launched processes. 17:55:31 < gwern> goodgrue: that'd be kind of hard. you could prepend a mpodification of $HTTP_PROXY to each command 17:56:10 < gwern> ideally you'd modify xmonad's own environment 17:56:33 < goodgrue> gwern: yeah, the latter is what I was thinking of. is that possible? 17:57:08 < gwern> shell uses `getEnv` from System.Environment but there's no setEnv! 17:57:21 < gwern> if there were, you could probably bind it to a key and use a prompt 17:58:44 < goodgrue> Hm...sounds like this may be a nice piece of missing functionality. is there any reason you can think of that i wouldn't be able to implement setEnv myself? 17:59:04 < gwern> http://hackage.haskell.org/trac/ghc/ticket/3587 17:59:14 < gwern> looks like 'putEnv' may be the real name -- gwern http://www.gwern.net

2 3

Proposal: Derive Typeable instance for StdGen
by Bas van Dijk 06 Feb '12

06 Feb '12

Dear all, I would like to propose deriving a Typeable instance for System.Random.StdGen. Discussion deadline: 2 weeks from now: Monday, 20 February. Regards, Bas

3 3

"missing" Eq instance for ErrorCall
by Simon Hengel 06 Feb '12

06 Feb '12

Is there a good reason for not having an Eq instance for Control.Exception.ErrorCall? Somewhat related, what are the Ord instances (e.g. for ArithException) meant for? Cheers, Simon

1 0

Oddity with 'cabal install' in GHC 7.4.1
by Conal Elliott 05 Feb '12

05 Feb '12

Since upgrading to 7.4.1, if I 'cabal install' successfully and then 'cabal install' a second time without first doing a 'ghc-pkg unregister <package-name>', I get the following complaint: cabal: The install plan contains reinstalls which can break your GHC > installation. You can try --solver=modular for the new modular solver that > chooses such reinstalls less often and also offers the --avoid-reinstalls > option. You can also ghc-pkg unregister the affected packages and run > ghc-pkg > check to see the effect on reverse dependencies. If you know what you are > doing you can use the --force-reinstalls option to override this reinstall > check. > The only path I've found so far that's willing to rebuild or even say nothing needs rebuilding (when nothing does) is to 'ghc-pkg unregister' and then 'cabal install' again. I'm getting the same behavior on Red Hat 5 and Mac OS 10.6.8, both compiled from sources. Does anyone know what's going on here? -- Conal

4 9

Cabal-install bug
by wren ng thornton 05 Feb '12

05 Feb '12

Hello all, The cabal/cabal-install bug tracker seems to be down, so I'm not sure if this is a known issue or not... When playing around with JHC earlier I ran into the following errors: $> cabal --version cabal-install version 0.10.2 using version 1.10.2.0 of the Cabal library $> cabal install --dry-run --jhc --verbose base Reading available packages... Resolving dependencies... cabal: internal error: impossible $> cabal install --dry-run --ghc --verbose base Reading available packages... Resolving dependencies... cabal: Distribution/Client/Dependency/TopDown.hs:171:37-73: Non-exhaustive patterns in lambda $> cabal install --dry-run --verbose base Reading available packages... Resolving dependencies... cabal: Distribution/Client/Dependency/TopDown.hs:171:37-73: Non-exhaustive patterns in lambda I've seen that problem before, though I can't recall where off-hand. Anyone know if this (a) has been reported, (b) has been fixed? -- Live well, ~wren

2 2