I'm deleting hpc after building ghc for a vm to save space. Is there an easy way to skip building it in the first place? -- View this message in context: http://haskell.1045720.n5.nabble.com/skip-hpc-during-build-tp5768327.html Sent from the Haskell - Glasgow-haskell-users mailing list archive at Nabble.com.
I've built GHC with GhcWithInterpreter = NO. runghc is built and installed, but errors out with "not built for interactive use". Is runghc supposed to work with such a build? If not, why is it built at all? -- View this message in context: http://haskell.1045720.n5.nabble.com/runghc-and-GhcWithInterpreter-tp5768326.html Sent from the Haskell - Glasgow-haskell-users mailing list archive at Nabble.com.
Hi, The current implementation of showIntAtBase in Numeric is limited to Chars currently. *showIntAtBase* * :: (Integral a, Show a) => a -> (Int -> Char) -> a -> ShowS* The 2 reasons for this constraint is: a) We only accept functions of the form (Int -> Char) b) An implicit concatenation using (:) I'd like to propose a new function showIntAtBaseGeneric that removes the (Int -> Char) function constraint and takes an additional function to replace the implicit (:) operator. *showIntAtBaseGeneric* * :: (Integral a1, Num b, Show a1) =>* * a1 -> (b -> a) -> (a -> s -> s) -> a1 -> s -> s* Now showIntAtBase may be implemented as: *showIntAtBase :: (Integral a, Show a) => a -> (Int -> Char) -> a -> ShowS* *showIntAtBase base toChr n0 r0 = showIntAtBaseGeneric base toChr (:) n0 r0* The API and behavior of showIntAtBase remains unchanged while allowing for generic conversions not limited to Chars alone. *Example: * *λ> showIntAtBaseGeneric 26 id (:) 500  -- convert 500 to base26 and provid
Hello All, Having skimmed the literature, run some tests and benchmarks: The current System.Random is broken: https://github.com/haskell/random/issues/25#issuecomment-87423142. Furthermore, this is recorded in at least two published papers: http://dl.acm.org/citation.cfm?id=2660195 and http://publications.lib.chalmers.se/records/fulltext/183348/local_183348.pdf. The tf-random package does not have this breakage and is based on good theoretical foundations. In my tests tf-random performs better than System.Random. As a result of which, I am very much inclined to suggest we replace the code in System.Random with tf-random. Before doing any more work on this, I’d like to understand what the next steps should be. How much review should be carried out? I have no reason to doubt the implementors have done a great job but should someone (who?) review the code more formally. If so what would the process / tools be? Tests in packages / applications may now fail as the (pseudo) random numbers will be different w
https://ghc.haskell.org/trac/ghc/ticket/10235#ticket Would be really useful to be able to profile code without dying, especially in the context of a long-lived server. Am I missing something that would allow me to do this? cheers mark _______________________________________________ Glasgow-haskell-users mailing list Glasgow-haskell-users< at >haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/glasgow-haskell-users