- Haskell-Cafe - Haskell.org

GHC exceeding command line length limit with split-objs - and a possible fix
by Eugene Kirpichov 12 Jan '12

12 Jan '12

Hi, I'm building gtk2hs on a mac with -fsplit-objs, and during compilation of the largest file, which produces about 7000 split objects, the linking phase fails. I'm assuming that's because the command line length has been exceeded, because other files compile fine, without -fsplit-objs it compiles fine too, and it compiles fine *with* -fsplit-objs on other OS - so perhaps the reason is in mac's tempfile name generation (they're longer than on other platforms) or something. Anyway. I think a nice fix would be to employ gcc's ability to read options from a file - gcc @file - and write overly long option strings into temp files. It'd be fun for me to implement this as my first contribution to ghc; is this a good idea in general? -- Eugene Kirpichov Principal Engineer, Mirantis Inc. http://www.mirantis.com/ Editor, http://fprog.ru/

2 4

Re: [Haskell-cafe] GHC exceeding command line length limit with split-objs - and a possible fix
by John Lato 11 Jan '12

11 Jan '12

I used https://github.com/kennethreitz/osx-gcc-installer/downloads to get a real gcc on Lion. Biggish download, but it worked. I've also seen reports of success by self-compiling gcc, or by installing XCode 4 on top of an existing XCode 3 installation. John L. > From: Eugene Kirpichov <ekirpichov(a)gmail.com> > > Oh well... looks like building ghc won't be easy, as it doesn't build with > llvm-gcc and it's not easy to get a "real" gcc on Lion. But I don't stop > trying :)

4 3

Where is the pairing-with-monoid monad instance?
by Conal Elliott 11 Jan '12

11 Jan '12

Is the standard pair-with-monoid monad instance in some standard place? I see the Applicative instance in Control.Applicative, and the pair-with-monoid Functor instance in Control.Monad.Instances, and the (->) e and Either e monad instances also in Control.Monad.Instances. I'm looking for something like instance Monoid o => Monad ((,) o) where return a = (mempty,a) (o,a) >>= f = (o `mappend` o', b) where (o',b) = f a Where is it hiding from me? Thanks, - Conal

2 1

debugging snap app
by Eric Wong 11 Jan '12

11 Jan '12

Hi, I'm trying to get the debugging messages in snap-server in order to find the socket leaking in my snap app. I find the doc on snapframework.com says that setting an environment variable DEBUG=1 will enable the app to output the messages in stderr. But I don't get any. I installed the snap-server package using -fopenssl flag but without -fnodebug, so I think it's normal. Any idea on this? Eric

1 0

When will constraint kinds roll out?
by Nicholas Tung 11 Jan '12

11 Jan '12

Just a quick, logistical question: I see constraint kinds didn't make it to GHC 7.2.2; does anyone have guesses when the extension will roll out in an official release? Our research team is interested in using Haskell for an EDSL, and having both constraint kinds and access to all of the libraries on Hackage would be optimal. (I've been writing an EDSL with monad transformers and the rmonad package myself, but think it is too difficult and cumbersome if we are to use Haskell EDSL approaches more broadly). Thanks in advance, Nicholas — https://ntung.com — 4432-nstung

2 1

ANNOUNCE: sloth-0.0.1
by Jan Christiansen 11 Jan '12

11 Jan '12

Hi, I have just released a prototype implementation of a tool (http://hackage.haskell.org/package/sloth) for checking whether a function is unnecessarily strict. It is inspired by Olaf Chitils StrictCheck tool (http://www.cs.kent.ac.uk/people/staff/oc/) but does not propose improvements that lead to non-sequential function definitions. For more details there is a short explanation with some examples at http://www.informatik.uni-kiel.de/fileadmin/arbeitsgruppen/ca_prog_develop/…. If you discover a bug or have any questions please use the human bug tracking system at jan_christiansen[at]gmx[dot]de. Cheers, Jan

1 0

Simple type-class experiment turns out not so simple...
by Steve Horne 11 Jan '12

11 Jan '12

I was messing around with type-classes (familiarization exercises) when I hit a probably newbie problem. Reducing it to the simplest case... module BinTree ( WalkableBinTree, BT (Branch, Empty) ) where -- n : node type -- d : data item type wrapped in each node class WalkableBinTree n where wbtChildren :: n -> Maybe (n, n) wbtData :: n -> Maybe d -- Simple tree type, mostly for testing data BT x = Branch x (BT x) (BT x) | Empty instance WalkableBinTree (BT x) where wbtChildren (Branch d l r) = Just (l, r) wbtChildren Empty = Nothing wbtData (Branch d l r) = Just d wbtData Empty = Nothing Loading this code into GHCi, I get... Prelude> :load BinTree [1 of 1] Compiling BinTree ( BinTree.hs, interpreted ) BinTree.hs:16:39: Couldn't match type `x' with `d' `x' is a rigid type variable bound by the instance declaration at BinTree.hs:12:32 `d' is a rigid type variable bound by the type signature for wbtData :: BT x -> Maybe d at BinTree.hs:16:5 In the first argument of `Just', namely `d' In the expression: Just d In an equation for `wbtData': wbtData (Branch d l r) = Just d Failed, modules loaded: none. Prelude> I've tried varying a number of details. Adding another parameter to the type-class (for the item-data type) requires an extension, and even then the instance is rejected because (I think) the tree-node and item-data types aren't independent. In any case, I can't understand why those types can't match.

7 10

How to "show" a utf8 string?
by Magicloud Magiclouds 10 Jan '12

10 Jan '12

Hi, I am using LDAP hackage to do some ldap searching. I am not sure if this is its problem. All Chinese chars returned like "\29579". How to convert it to the actual Chinese char? I thought it was my terminal's fault, so tried to use System.IO.UTF8 to put the result into a file and viewed by firefox, no luck. -- 竹密岂妨流水过山高哪阻野云飞

3 3

Re: [Haskell-cafe] typeclass and functional dependency problem
by John Lato 10 Jan '12

10 Jan '12

> From: Martin DeMello <martindemello(a)gmail.com> > Subject: [Haskell-cafe] typeclass and functional dependency problem > > I'm writing a Gtk2hs app, and I have several custom widgets that are > composite objects represented by records, one field of which is a > container widget. I am trying to write a replacement for gtk2hs's > boxPackStart > > boxPackStart :: (BoxClass self, WidgetClass child) => self -> child -> > Packing -> Int -> IO () > > that will accept either a gtk widget or one of my custom widgets to > place in the box, and do the right thing. Here's my attempt at it; > what I want to know is why the commented out bit didn't work and I had > to individually add instances of widgets instead: > > --------------------------------------------- > -- packable objects > class WidgetClass w => Packable a w | a -> w where > widgetOf :: a -> w > > --instance WidgetClass w => Packable w w where > -- widgetOf = id > > instance Packable Button Button where > widgetOf = id > > instance Packable Entry Entry where > widgetOf = id > > instance Packable Label Label where > widgetOf = id > > instance Packable Notebook Notebook where > widgetOf = id > > instance Packable HBox HBox where > widgetOf = id > > -- add widget to box > boxPackS :: (BoxClass b, WidgetClass w, Packable a w) => b -> a -> > Packing -> Int -> IO () > boxPackS box child p i = boxPackStart box (widgetOf child) p i > > --------------------------------------------- > > If I try to use > > instance WidgetClass w => Packable w w where > widgetOf = id > > instead, I get the compilation error > > Editor.hs:23:10: > Functional dependencies conflict between instance declarations: > instance Packable PairBox VBox -- Defined at Editor.hs:23:10-30 > instance WidgetClass w => Packable w w > -- Defined at GuiUtils.hs:13:10-38 > > even though PairBox does not belong to WidgetClass. This is a very common problem. The line > instance WidgetClass w => Packable w w where means "Every type is an instance of Packable by this declaration", not "Every type that has a WidgetClass instance is a Packable by this declaration", which is what you wanted. So you end up with two Packable instances for PairBox, "Packable PairBox PairBox" and "Packable PairBox Container" (or whatever type you used), which causes this conflict. This is a consequence of Haskell type classes being open. Even if you don't have a WidgetClass instance for a type (PairBox) in scope where you define this instance, one could be defined elsewhere and be in scope at a call site. Unfortunately Haskell doesn't provide a way to write what you want. I can think of a few solutions, none of which are ideal: 1. Create separate instances for each type. Writing some generating code to do this is probably the best available option. 2. Convert everything to a Container. 3. Make boxPackS a TH splice, and use a naming convention to differentiate your objects from the built-in widgets. I don't like 3) because it's fragile. Pretty much everything else is a variant of either 1 (lots of instance decls) or 2 (another function call/separate functions). John L.

1 0

SMP parallelism increasing GC time dramatically
by Tom Thorne 10 Jan '12

10 Jan '12

I am having some strange performance issues when using SMP parallelism, that I think may be something to do with GC. Apologies for the large readouts below but I'm not familiar enough to know what is and isn't relevant! I have a pure function that is mapped over a list of around 10 values, and this happens several times for each iteration of my program. It does some fairly intensive calculations using hmatrix, generating intermediate matrices along the way. The computation is significantly more complex for some values, so the work done by each call is not spread equally. I did some profiling and it seems like the program is spending about 50% of its time in that function. First of all, without any attempts at parallelism, I see this from ./Main +RTS -s 67,142,126,336 bytes allocated in the heap 147,759,264 bytes copied during GC 109,384 bytes maximum residency (58 sample(s)) 354,408 bytes maximum slop 3 MB total memory in use (0 MB lost due to fragmentation) Generation 0: 104551 collections, 0 parallel, 1.13s, 1.11s elapsed Generation 1: 58 collections, 0 parallel, 0.01s, 0.01s elapsed Parallel GC work balance: -nan (0 / 0, ideal 1) MUT time (elapsed) GC time (elapsed) Task 0 (worker) : 0.00s ( 67.06s) 0.00s ( 0.00s) Task 1 (worker) : 0.00s ( 67.09s) 0.00s ( 0.00s) Task 2 (bound) : 66.95s ( 67.09s) 1.14s ( 1.12s) SPARKS: 0 (0 converted, 0 pruned) INIT time 0.00s ( 0.00s elapsed) MUT time 66.95s ( 67.09s elapsed) GC time 1.14s ( 1.12s elapsed) EXIT time 0.00s ( 0.00s elapsed) Total time 68.09s ( 68.21s elapsed) %GC time 1.7% (1.6% elapsed) Alloc rate 1,002,835,517 bytes per MUT second Productivity 98.3% of total user, 98.2% of total elapsed gc_alloc_block_sync: 0 whitehole_spin: 0 gen[0].sync_large_objects: 0 gen[1].sync_large_objects: 0 This looks ok to me... Then if I try to use Control.Parallel to parallelise my code, simpy replacing a map with parMap (rdeepseq), on a 12 core machine using +RTS -N12 -s I get this: 66,065,148,144 bytes allocated in the heap 197,202,056 bytes copied during GC 181,312 bytes maximum residency (251 sample(s)) 387,240 bytes maximum slop 12 MB total memory in use (3 MB lost due to fragmentation) Generation 0: 37592 collections, 37591 parallel, 245.32s, 26.67s elapsed Generation 1: 251 collections, 251 parallel, 3.12s, 0.33s elapsed Parallel GC work balance: 2.41 (24219609 / 10058220, ideal 12) MUT time (elapsed) GC time (elapsed) Task 0 (worker) : 0.00s ( 0.00s) 0.00s ( 0.00s) Task 1 (worker) : 0.00s ( 0.00s) 0.00s ( 0.00s) Task 2 (worker) : 0.00s ( 17.97s) 0.00s ( 0.00s) Task 3 (worker) : 0.00s ( 19.35s) 0.00s ( 0.00s) Task 4 (worker) : 0.00s ( 40.28s) 0.00s ( 0.00s) Task 5 (worker) : 0.00s ( 45.08s) 0.00s ( 0.00s) Task 6 (worker) : 0.00s ( 47.06s) 0.00s ( 0.00s) Task 7 (worker) : 18.30s ( 49.73s) 16.24s ( 1.71s) Task 8 (worker) : 0.00s ( 51.22s) 0.00s ( 0.00s) Task 9 (worker) : 0.00s ( 53.75s) 0.00s ( 0.00s) Task 10 (worker) : 0.00s ( 54.17s) 0.00s ( 0.00s) Task 11 (worker) : 5.65s ( 54.30s) 0.70s ( 0.08s) Task 12 (worker) : 0.00s ( 54.41s) 0.41s ( 0.04s) Task 13 (worker) : 4.34s ( 54.58s) 4.50s ( 0.48s) Task 14 (worker) : 5.82s ( 54.76s) 5.91s ( 0.64s) Task 15 (worker) : 6.50s ( 55.01s) 3.37s ( 0.38s) Task 16 (worker) : 7.60s ( 55.21s) 8.56s ( 0.94s) Task 17 (worker) : 11.05s ( 55.21s) 9.04s ( 0.96s) Task 18 (worker) : 11.75s ( 55.21s) 12.94s ( 1.43s) Task 19 (worker) : 16.02s ( 55.21s) 13.32s ( 1.43s) Task 20 (worker) : 26.98s ( 55.23s) 7.43s ( 0.77s) Task 21 (worker) : 7.36s ( 55.23s) 7.47s ( 0.83s) Task 22 (worker) : 16.08s ( 55.23s) 10.25s ( 1.12s) Task 23 (worker) : 7.04s ( 55.23s) 4.99s ( 0.57s) Task 24 (worker) : 28.47s ( 55.23s) 8.78s ( 0.94s) Task 25 (worker) : 7.43s ( 55.23s) 1.62s ( 0.18s) Task 26 (worker) : 6.33s ( 55.23s) 11.42s ( 1.23s) Task 27 (worker) : 9.80s ( 55.23s) 8.72s ( 0.95s) Task 28 (worker) : 4.88s ( 55.26s) 8.92s ( 0.99s) Task 29 (worker) : 0.00s ( 55.26s) 0.00s ( 0.00s) Task 30 (bound) : 5.59s ( 55.26s) 0.59s ( 0.06s) Task 31 (worker) : 41.16s ( 55.26s) 3.48s ( 0.38s) Task 32 (worker) : 17.03s ( 55.26s) 3.90s ( 0.42s) Task 33 (worker) : 14.89s ( 55.26s) 5.29s ( 0.58s) Task 34 (worker) : 6.30s ( 55.26s) 1.99s ( 0.21s) Task 35 (worker) : 16.13s ( 55.26s) 13.95s ( 1.50s) Task 36 (worker) : 16.70s ( 55.26s) 13.02s ( 1.41s) Task 37 (worker) : 11.68s ( 55.26s) 15.45s ( 1.68s) Task 38 (worker) : 7.65s ( 55.26s) 13.61s ( 1.50s) Task 39 (worker) : 14.18s ( 55.26s) 12.48s ( 1.35s) Task 40 (worker) : 5.51s ( 55.26s) 11.92s ( 1.31s) Task 41 (worker) : 3.10s ( 55.26s) 8.17s ( 0.93s) SPARKS: 42525 (37707 converted, 519 pruned) INIT time 0.00s ( 0.00s elapsed) MUT time 365.55s ( 55.26s elapsed) GC time 248.45s ( 27.00s elapsed) EXIT time 0.00s ( 0.00s elapsed) Total time 614.01s ( 82.26s elapsed) %GC time 40.5% (32.8% elapsed) Alloc rate 180,724,403 bytes per MUT second Productivity 59.5% of total user, 444.4% of total elapsed gc_alloc_block_sync: 1339708 whitehole_spin: 36 gen[0].sync_large_objects: 197621 gen[1].sync_large_objects: 6396 It seems like suddenly GC is taking a lot longer. I also tried using Control.Monad.Par, with runPar $ do parMap, and using +RTS -N12 -s I get this: 71,480,561,920 bytes allocated in the heap 275,752,912 bytes copied during GC 198,704 bytes maximum residency (343 sample(s)) 394,232 bytes maximum slop 12 MB total memory in use (3 MB lost due to fragmentation) Generation 0: 37575 collections, 37574 parallel, 169.08s, 16.67s elapsed Generation 1: 343 collections, 343 parallel, 6.24s, 0.61s elapsed Parallel GC work balance: 2.56 (33928871 / 13275450, ideal 12) MUT time (elapsed) GC time (elapsed) Task 0 (worker) : 0.70s ( 46.46s) 0.00s ( 0.00s) Task 1 (worker) : 2.94s ( 46.46s) 0.00s ( 0.00s) Task 2 (worker) : 0.10s ( 46.46s) 0.00s ( 0.00s) Task 3 (worker) : 0.06s ( 46.47s) 0.00s ( 0.00s) Task 4 (worker) : 1.70s ( 46.47s) 0.00s ( 0.00s) Task 5 (worker) : 0.07s ( 46.47s) 0.00s ( 0.00s) Task 6 (worker) : 2.75s ( 46.47s) 0.00s ( 0.00s) Task 7 (worker) : 1.21s ( 46.47s) 0.00s ( 0.00s) Task 8 (worker) : 0.43s ( 46.47s) 0.00s ( 0.00s) Task 9 (worker) : 10.44s ( 46.47s) 0.00s ( 0.00s) Task 10 (worker) : 0.06s ( 46.47s) 0.00s ( 0.00s) Task 11 (worker) : 1.36s ( 46.47s) 0.00s ( 0.00s) Task 12 (worker) : 0.00s ( 46.50s) 46.69s ( 4.63s) Task 13 (worker) : 0.00s ( 46.50s) 0.00s ( 0.00s) Task 14 (bound) : 0.05s ( 46.50s) 0.56s ( 0.06s) Task 15 (worker) : 24.84s ( 46.50s) 2.24s ( 0.21s) Task 16 (worker) : 28.00s ( 46.50s) 1.95s ( 0.19s) Task 17 (worker) : 35.30s ( 46.50s) 2.79s ( 0.27s) Task 18 (worker) : 29.03s ( 46.50s) 4.06s ( 0.39s) Task 19 (worker) : 32.71s ( 46.50s) 7.04s ( 0.69s) Task 20 (worker) : 32.74s ( 46.50s) 11.47s ( 1.09s) Task 21 (worker) : 23.35s ( 46.50s) 15.16s ( 1.49s) Task 22 (worker) : 36.00s ( 46.50s) 7.94s ( 0.76s) Task 23 (worker) : 0.00s ( 46.50s) 35.84s ( 3.63s) Task 24 (worker) : 24.70s ( 46.50s) 21.26s ( 2.06s) Task 25 (worker) : 23.07s ( 46.50s) 18.33s ( 1.82s) SPARKS: 0 (0 converted, 0 pruned) INIT time 0.00s ( 0.00s elapsed) MUT time 307.74s ( 46.50s elapsed) GC time 175.32s ( 17.29s elapsed) EXIT time 0.00s ( 0.00s elapsed) Total time 483.06s ( 63.79s elapsed) %GC time 36.3% (27.1% elapsed) Alloc rate 232,274,501 bytes per MUT second Productivity 63.7% of total user, 482.4% of total elapsed gc_alloc_block_sync: 1619540 whitehole_spin: 258 gen[0].sync_large_objects: 232661 gen[1].sync_large_objects: 6378 This seems slightly better, but the GC time is still much bigger than I would expect it to be. I don't think it is solely because of parallel GC, since running the parallel code with +RTS -N1 gives results similar to the non-parallel version. Am I simply misunderstanding the way the GC time is represented in this output, or is there something amiss? (I also noticed that there seem to be a lot more than 12 threads running if I look at top while the program is running, but I assume this is something to do with the runtime spawning more threads for GC etc)

14 23