- Haskell-Cafe - Haskell.org

First call to putStr takes far more time than subsequent calls
by Ben Gunton 11 Jul '15

11 Jul '15

This is a simplified version of an issue I'm running into when timing some functions. In this example, the first putStr inside the replicateM_ takes far longer than subsequent putStrs. If I add in a putStr at the top (the commented line), each iteration takes the same. (Though I presume I just shifted the long execution to the putStr on top). The same thing happens on the first iterations of a function when I need to evaluate some state, or deepseq some value. putStr was just a simpler version that still showed the same issue. Relevant code: http://lpaste.net/136250 What's going on here? Thanks! import Control.Monadimport Data.Time.Clock main :: IO ()main = do -- putStr "" replicateM_ 5 $ do t1 <- getCurrentTime putStr "" t2 <- getCurrentTime print . round $ 1000 * 1000 * diffUTCTime t2 t1 {- Sample output: 49 1 1 1 2 -}

6 10

As reading, what are your favorite Haskell libraries?
by Jeffrey Brown 11 Jul '15

11 Jul '15

A wider question controls also for a library's applicability and (relative) absence of prerequisites, because the funnest reading is not only intrinsically fun, but also extrinsically rewarding and soon feasible (feasible to comprehend or to use). That is, I like simple, beautiful, powerful libraries that do not require me to first learn too many other things. I might value simplicity over power. I'm interested in answers to either question.

2 1

GHC Memory Management wiki page
by Kyle Miller 11 Jul '15

11 Jul '15

I have been studying the garbage collection algorithms used in GHC, and it appears to me that section two of [1] is misleading, since thunks permit controlled mutation of the heap, and so objects in older generations may point to younger objects. In fact, the RTS maintains "remembered sets" to keep track of these relations. A Haskell could in principle be implemented in the way described (and execute in surprising complexity classes), but this does not seem to match reality. [1] https://wiki.haskell.org/GHC/Memory_Management Should the wiki be modified? Regards, Kyle Miller

4 3

Confusion with GeneralizedNewtypeDeriving + MultiParamTypeClasses
by William Yager 10 Jul '15

10 Jul '15

Hello all, I have run into a bit of a strange case where I can't get `GeneralizedNewtypeDeriving` to work as I'd like. In the `vector` package, under `Data.Vector.Generic`, there is a generic vector typeclass of the form `Vector v a`, where `v` is the vector type and `a` is the type of items in the vector. I have a newtype wrapper of the form `newtype Neuron a = Neuron (Vector a)`. (Note that "Vector" here is a type "Vector", not the two-parameter constraint also called "Vector".) I would like to be able to use everything in `Data.Vector.Generic` on `Neuron`s. Using `GeneralizedNewtypeDeriving`, I immediately run up against the issue that the `Vector` typeclass doesn't have the correct form of `* -> Constraint`. According to section 7.5.5.1 of https://downloads.haskell.org/~ghc/7.8.4/docs/html/users_guide/deriving.html , we should be able to derive instances of multi-parameter type classes, provided the newtype is the last parameter of the typeclass. The problem here is that it's the first parameter. Using `ConstraintKinds` to make a constraint synonym (of the form `FlippedVectorClass a v`) so that I can do something like `newtype Neuron a = Neuron (Vector a) deriving (FlippedVectorClass a)` also doesn't seem to work. Does anyone have any advice for how to make this work? It's quite tempting just to make `type Neuron a = Vector a`, but I'd rather do a proper wrapper type. Cheers, Will

2 1

darcs 2.10.1 release
by Guillaume Hoffmann 10 Jul '15

10 Jul '15

Hi all, The darcs team is pleased to announce the release of darcs 2.10.1 ! # Downloading # The easiest way to install darcs 2.10.1 from source is by first installing the Haskell Platform (http://www.haskell.org/platform) If you have installed the Haskell Platform or cabal-install, you can install this release by doing: $ cabal update $ cabal install darcs-2.10.1 Alternatively, you can download the tarball from http://darcs.net/releases/darcs-2.10.1.tar.gz and build it by hand as explained in the README file. The 2.10 branch is also available as a darcs repository from http://darcs.net/releases/branch-2.10 # What's new in 2.10.1 (since 2.10.0) # - generalized doFastZip for darcsden support - support terminfo 0.4, network 2.6, zlib 0.6, quickcheck 2.8 and attoparsec 0.13 - errorDoc now prints a stack trace (if profiling was enabled) (Ben Franksen) - beautified error messages for command line and default files (Ben Franksen) - fixed the following bugs: - issue2449: test harness/shelly: need to handle mis-encoded/binary data (Ganesh Sittampalam) - issue2423: diff only respecting --diff-command when a diff.exe is present (Alain91) - issue2447: get contents of deleted file (Ben Franksen) - issue2307: add information about 'darcs help manpage' and 'darcs help markdown' (Dan Frumin) - issue2461: darcs log --repo=remoterepo creates and populates _darcs (Ben Franksen) - issue2459: cloning remote repo fails to use packs if cache is on a different partition (Ben Franksen) # Feedback # If you have an issue with darcs 2.10.0, you can report it on http://bugs.darcs.net/ . You can also report bugs by email to bugs(a)darcs.net, or come to #darcs on irc.freenode.net. # Known issues # - issue2269: rebase should warn about stolen patches at suspend, not unsuspend - issue2272: darcs rebase unsuspend should automate or semi-automate handling unrecorded changes - issue2276: darcs rebase unsuspend needs UI improvements for "You are not... Amend anyway?" - issue2359: convert --export mishandles Unicode filenames - issue2372: Please remove "HINT: I could not reach..." message - issue2436: rollback --patches takes ages before first prompt - issue2445: internal error if suspended patch is pulled into repository again

1 0

(no subject)
by None 09 Jul '15

09 Jul '15

1 0

[GHC 7.8.4] IO Monad leak space?
by Baojun Wang 09 Jul '15

09 Jul '15

Hi, First of all, I found it interesting that loopM_ f k n s = when (k <= n) (f k >> loopM_ f (s+k) n s) loopM_ seems faster than mapM_ ( mapM_ f [k, k+s..n])) I think mapM_ is used very commonly, why it's performance is even lower than a hand-written loop function? 2nd, even I replace mapM_ with loopM_ from above, when chain IO action, it still can leak space. ( Because IO Monad (>>) need keep ``RealWorld s'' updated so that I/O actions can be done in-order? ) Consider below function: f3 :: UArray Int Int -> IOUArray Int Int64 -> Int -> IO () f3 u r i = let !v = u ! i in go (f31 v) i i where f31 v j = readArray r j >>= \v1 -> writeArray r j (v1 + (fromIntegral i) * (fromIntegral v)) f31 :: Int -> Int -> IO () go g k s = when (k <= maxn) ( g k >> go g (s+k) s ) When call f3: loopM_ (f3 uu res) 1 1 1000000 Which will have blow profiling output: individual inherited COST CENTRE MODULE no. entries %time %alloc %time %alloc ... loopM_ Main 104 4000002 7.4 10.1 100.0 99.3 f3 Main 113 1000000 1.0 2.0 70.2 69.1 f3.go Main 116 14970034 32.7 67.1 68.8 67.1 f3.f31 Main 117 13970034 34.5 0.0 36.1 0.0 f3.f31.\ Main 118 13970034 1.7 0.0 1.7 0.0 f3.f31 Main 114 0 0.3 0.0 0.4 0.0 f3.f31.\ Main 115 0 0.1 0.0 0.1 0.0 ... Why f3.go consumes so much space (67.1%)? The only reason I can think of is IO Monad chain (>>) isn't space free as I thought. Did I get something fundamentally wrong? Thanks baojun

6 14

Problems with type families
by Leza Morais Lutonda 09 Jul '15

09 Jul '15

Hi All! Consider the following definitions: type family TFunIn t e type family TFunOut t e data IdT data ComposeT t1 t2 -- etc... type instance TFunIn (ComposeT t1 t2) e = TFunIn t2 e type instance TFunOut (ComposeT t1 t2) e = TFunOut t1 e -- etc... class SignalT t e where transform :: t -> TFunIn t e -> TFunOut t e instance (SignalT t1 e, SignalT t2 e) => SignalT (ComposeT t1 t2) e where transform _ x = (transform (undefined :: t1) . transform (undefined :: t2)) x Due to the `TFunIn` and `TFunOut` type families instances for [(ComposeT t1 t2) e], the `transform` function for [(ComposeT t1 t2) e] instance of SignalT should be inferred as: transform :: t -> TFunIn (ComposeT t1 t2) e -> TFunOut (ComposeT t1 t2) e <==> :: t -> TFunIn t2 e -> TFunOut t1 e But I cannot figure out why it does not compile. Any ideas? Thanks. -- Leza Morais Lutonda, Lemol-C http://lemol.github.io 50 Aniversario de la Cujae. Inaugurada por Fidel el 2 de diciembre de 1964 http://cujae.edu.cu

2 7

You know, I am tired of it.
by Stefan Reich 09 Jul '15

09 Jul '15

Whatever "community" I go, they all pretend like their old shit is SO important.

9 15

The evil of "mailing list removals" - and Microsoft-sponsored s**t ^^
by Stefan Reich 09 Jul '15

09 Jul '15

3 2