January 2012 - Haskell-Cafe

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 10 Jan '12

10 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 10 Jan '12

10 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 10 Jan '12

10 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

typeclass and functional dependency problem
by Martin DeMello 10 Jan '12

10 Jan '12

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. martin

1 0

PhD studentship in Nottingham
by Graham Hutton 09 Jan '12

09 Jan '12

Dear all, I am currently advertising a PhD Studentship in Functional Programming at the University of Nottingham in the UK: http://www.nottingham.ac.uk/jobs/currentvacancies/ref/SCI1088 If you are interested in applying yourself, please drop me a note by email. If you know of any good candidates who may be interested in applying, or there is a local mailing list for advertising such things, I'd be much obliged if you could pass on the above link. Many thanks, Graham Hutton -- Prof Graham Hutton Functional Programming Lab School of Computer Science University of Nottingham, UK http://www.cs.nott.ac.uk/~gmh This message and any attachment are intended solely for the addressee and may contain confidential information. If you have received this message in error, please send it back to me, and immediately delete it. Please do not use, copy or disclose the information contained in this message or in any attachment. Any views or opinions expressed by the author of this email do not necessarily reflect the views of the University of Nottingham. This message has been checked for viruses but the contents of an attachment may still contain software viruses which could damage your computer system: you are advised to perform your own checks. Email communications with the University of Nottingham may be monitored as permitted by UK legislation.

1 0

Re: [Haskell-cafe] Experiments in Haskell Packaging
by Chris Dornan 09 Jan '12

09 Jan '12

> > I don’t have any problem with installing the tools into user-land – > > this will be true of all of the components in the justhub distro – > > provided you start with the source code. > > Long ago the Fedora Haskell project's rpm packages were relocatable for this reason. So it may still be possible and not that hard to do. I have looked into it -- unless we can unpack a bindist as part of the post-install step, it doesn't look practical. I have yet to be convinced that the RPM route make sense for the restrictive situation that Sanket outlines and I am trying to keep an open mind. I don't want to distribute sources either -- I think the solution will involve bindists. What a piece of work is a GHC bindist! Chris -----Original Message----- From: juhpetersen(a)gmail.com [mailto:juhpetersen@gmail.com] On Behalf Of Jens Petersen Sent: 08 January 2012 08:03 To: Chris Dornan Subject: Re: [Haskell-cafe] Experiments in Haskell Packaging > I don’t have any problem with installing the tools into user-land – > this will be true of all of the components in the justhub distro – > provided you start with the source code. Long ago the Fedora Haskell project's rpm packages were relocatable for this reason. So it may still be possible and not that hard to do. Jens

1 0