August 2013 - Haskell-Cafe

Ideas on a fast and tidy CSV library
by Justin Paston-Cooper 21 Aug '13

21 Aug '13

Dear All, Recently I have been doing a lot of CSV processing. I initially tried to use the Data.Csv (cassava) library provided on Hackage, but I found this to still be too slow for my needs. In the meantime I have reverted to hacking something together in C, but I have been left wondering whether a tidy solution might be possible to implement in Haskell. I would like to build a library that satisfies the following: 1) Run a function <<f :: a_1 -> ... -> a_n -> m (Maybe (b_1, ..., b_n))>>, with <<m>> some monad and the <<a>>s and <<b>>s being input and output. 2) Be able to specify a maximum record string length and output record string length, so that the string buffers used for reading and outputting lines can be reused, preventing the need for allocating new strings for each record. 3) Allocate only once, the memory where the parsed input values, and output values are put. 4) The library's main function should take some kind of data structure describing the types of the function, the function itself and the filenames of input and output (could also be stdin/stdout). I am not sure yet what would be that best value of <<m>>. I would like to most importantly efficiently, and if possible, purely allow changes in state to a number of variables, such as an aggregation over a certain field in the input. I do not currently have knowledge of the FFI, and how it might be used in this case. I would appreciate any suggestions as to where I should look further. Regards, Justin Paston-Cooper

3 6

PPC binaries for GHC 7.x?
by Rogan Creswick 21 Aug '13

21 Aug '13

Does anyone have PPC binaries for GHC 7.x? I've been trying to help a PPC user compile a large haskell application, and it (and it's dependencies) require a newer ghc; the latest ppc binaries we've found are for 6.10, and we have been unable to compile a never ghc from source (6.12 /almost/ worked, but eventually failed with a linker error that appears to be unsolvable in the near-term). Thanks! Rogan

2 2

GHC and backwards compatibility
by Henning Thielemann 21 Aug '13

21 Aug '13

If you use $ cabal install --constraint="array installed" then cabal-install is forced to use the installed version of array. If a package conflicts with this version, then it will report the conflicting packages.

1 0

ANNOUNCE: haskell-src-exts 1.14.0
by Niklas Broberg 21 Aug '13

21 Aug '13

Fellow Haskelleers, I'm pleased to announce the release of haskell-src-exts-1.14.0! * On hackage: http://hackage.haskell.org/package/haskell-src-exts * Via cabal: cabal install haskell-src-exts * git repo: https://github.com/haskell-suite/haskell-src-exts<http://code.haskell.org/haskell-src-exts> There are two primary reasons for this release, and a number of smaller ones. The first primary reason is technical: haskell-src-exts 1.14 revamps the Extension datatype, among other things to allow turning extensions on and off (similar to what Cabal allows). We also introduce the concept of a Language, separate from a set of extensions. This is the only backwards-incompatible change in this release. The second reason is structural: haskell-src-exts is now part of a larger context -- the Haskell Suite. The package has a new home on github (see above), alongside its new cool friends: haskell-names and haskell-packages. There is also a really nice issue tracker there - please help me fill it, or better yet, empty it! What this release does *not* cover is support for the extensions added to GHC in recent time (with the exceptions of CApiFFI and InterruptibleFFI). Work is in progress on many of these, and there will be another major release not far off in the future. This release owes many thanks to Roman Cheplyaka in particular, as well as Erik Hesselink, Simon Meier and David Fox. Thanks a lot! Complete changelog: 1.13.6 --> 1.14.0 =============== * Modernize the Extension datatype in L.H.E.Extension, following the lead of Cabal, to allow negative and positive extension modifiers (turning features on and off). You need to worry about backwards-incompatible changes if any of the following pertains to you: 1) If you use the Extension datatype programmatically - it has changed significantly (see documentation). 2) The ParseMode record now has one more field (baseLanguage :: Language), which might give you a type error. 3) The behavior of the (extensions :: [Extension]) field has changed, which could bite you if you pass custom extensions in the ParseMode. Previously, the ParseMode defaulted to the list of extensions accepted by Haskell2010, and if you set the list explicitly you would override this. Now, the defaults are { baseLanguage = Haskell2010, extensions = [] }, and explicitly setting a list of extensions will be interpreted on top of Haskell2010. See further the documentation for L.H.E.Extension. * Add support for the 'capi' calling convention. It is enabled with the CApiFFI extension. It's been included since GHC 7.4, and advertised since 7.6. * Add support for the 'interruptible' FFI safety annotation, enabled with the InterruptibleFFI extension. * Give better error message when lexing newline fails. In particular, fix the bug when the parser would crash if the file didn't end with a newline. * Support unboxed tuple expressions and patterns. * Fix bug in lexing of primitive integer literals in hex or octal notation. * Disallow negative primitive word literals (such as W# (-0x8000000000000000##)). * Allow phase control for SPECIALIZE pragma. * Derive Foldable and Traversable instances for all annotated AST types. * Fix bug with pretty-printing WARNING and DEPRECATED pragmas. Cheers, Niklas

8 16

ANNOUNCE: posix-paths, for faster file system operations
by Niklas Hambüchen 20 Aug '13

20 Aug '13

John Lato and I would like to announce our posix-paths package. https://github.com/JohnLato/posix-paths It implements a large portion of System.Posix.FilePath using ByteString based RawFilePaths instead of String based FilePaths, and on top of that provides a Traversal module with a fast replacement for `getDirectoryContents` and a recursive `allDirectoryContents`. `getDirectoryContents` is (unsurprisingly?) really slow. Our replacement is 11 times faster in the recursive use case [1], and only 20% slower than `find`. Benchmarks are at [2], code is at [3]. We hope that these improvements will eventually make it into base some day. Until then, we propose our package as a base for discussion and further improvements. Contributions are welcome: Some FilePath operations are not in it yet (especially the Windows / drive related ones), and our traversals might not work on Windows. We would also appreciate some thorough looks at their low level implementations. If you find our benchmarks against getDirectoryContents unfair or would like to add another one, please send a pull request. We have been running this on Linux production machines for a few months now, and are pleased by the speed-up. [1] For the recursive version of the original `getDirectoryContents`, we used the implementation given in Real World Haskell: http://book.realworldhaskell.org/read/io-case-study-a-library-for-searching… [2] Benchmarks: On a real file system: http://johnlato.github.io/posix-paths/usrLocal.html On tmpfs: http://johnlato.github.io/posix-paths/tmpfs.html (note that here find is slow because of process starting overhead) [3] Code: Github: https://github.com/JohnLato/posix-paths RawFilePath operations: https://github.com/JohnLato/posix-paths/blob/master/src/System/Posix/FilePa… Traversals: https://github.com/JohnLato/posix-paths/blob/master/src/System/Posix/Direct… Benchmarks: https://github.com/JohnLato/posix-paths/blob/master/benchmarks/Bench.hs

1 0

Looking for ICFP roommate
by Conal Elliott 20 Aug '13

20 Aug '13

I'm looking for an ICFP roommate. I plan to attend Sunday through Saturday and stay the nights of Saturday the 21st through Saturday the 28th. I missed the discounted price of $225 (yipes) at the Airport Hilton (sold out). Perhaps someone already has a room reserved with two beds or could switch to one with two beds and would like to reduce their cost by room-sharing for part or all of their stay. If so, please let me know. Thanks, - Conal

1 0

wxHaskell mailinglist
by Nathan Hüsken 20 Aug '13

20 Aug '13

Hey, Anyone knows what the proper channel for reporting bugs and asking questions about wxHaskell is? The github page https://github.com/wxHaskell/wxHaskell/wiki seems to have issues disabled, and when I post to the wxHaskell user mailinglist, it tells me that the list is moderated. But my post did not get accepted for the last 2 days. Regards, Nathan

2 3

Re: [Haskell-cafe] Compiling stringable with GHC 7.0.4
by Ketil Malde 20 Aug '13

20 Aug '13

I took the liberty of implementing this fix and uploading stringable-0.1.1.1 to HackageDB. I tested it on GHC 7.0.4 (you know, shipped with the cutting-edge Fedora distribution one year ago, but ancient and no longer to be bothered with by Haskell standards :-) and on 7.6.2. -k Ketil Malde <ketil(a)malde.org> writes: > Hi, > > ------------------------------------------------------- > I don't think FlexibleInstances works with this GHC, I get: > > % cabal install --prefix=$G stringable > Resolving dependencies... > Configuring stringable-0.1.1... > Building stringable-0.1.1... > Preprocessing library stringable-0.1.1... > [1 of 1] Compiling Data.Stringable ( Data/Stringable.hs, dist/build/Data/Stringable.o ) > > Data/Stringable.hs:54:10: > Illegal instance declaration for `Stringable String' > (All instance types must be of the form (T t1 ... tn) > where T is not a synonym. > Use -XTypeSynonymInstances if you want to disable this.) > In the instance declaration for `Stringable String' > ------------------------------------------------------- > > I changed the first line of Data/Stringable.hs to: > > {-# LANGUAGE FlexibleInstances, TypeSynonymInstances #-} > > and then it compiled. Is there any reason not to retain the TSI pragma? > > -k -- If I haven't seen further, it is by standing in the footprints of giants

1 0

One-element tuple
by AntC 20 Aug '13

20 Aug '13

There's an annoying inconsistency: (CustId 47, CustName "Fred", Gender Male) -- threeple (CustId 47, CustName "Fred) -- twople -- (CustId 47) -- oneple not! () -- nople (That is, it's annoying if you're trying to make typeclass instances for extensible/contractable tuples. Yes, I know I could use HLists.) I'm not happy with either approach I've tried: data Oneple a = Oneple a -- (or newtype) (Oneple $ CustId 47) -- too verbose type Oneple a = [a] [CustId 47] -- at least looks bracket-y What do you do? AntC

8 12

llvm on macos
by Dominic Steinitz 20 Aug '13

20 Aug '13

I am trying to use llvm but am being told I don't have llvm installed. Dominics-MacBook-Pro:Laplace dom$ ghc src-repa/Main.hs -rtsopts -threaded -eventlog -Odph -fllvm -optlo-O3 -fno-liberate-case -isrc-repa [1 of 3] Compiling SolverStencil ( src-repa/SolverStencil.hs, src-repa/SolverStencil.o ) Loading package ghc-prim ... linking ... done. Loading package integer-gmp ... linking ... done. Loading package base ... linking ... done. Loading package pretty-1.1.1.0 ... linking ... done. Loading package array-0.4.0.1 ... linking ... done. Loading package deepseq-1.3.0.1 ... linking ... done. Loading package containers-0.5.0.0 ... linking ... done. Loading package old-locale-1.0.0.5 ... linking ... done. Loading package time-1.4.0.1 ... linking ... done. Loading package random-1.0.1.1 ... linking ... done. Loading package template-haskell ... linking ... done. Loading package QuickCheck-2.5.1.1 ... linking ... done. Loading package bytestring-0.10.0.2 ... linking ... done. Loading package primitive-0.5.0.1 ... linking ... done. Loading package vector-0.10.0.1 ... linking ... done. Loading package repa-3.2.3.1 ... linking ... done. <no location info>: Warning: Couldn't figure out LLVM version! Make sure you have installed LLVM ghc: could not execute: opt The ghc documentation (http://www.haskell.org/ghc/docs/7.6.1/html/users_guide/code-generators.html) says that llvm and clang are installed by default for 10.6 and later. I am on 10.8.3. Indeed Dominics-MacBook-Pro:Laplace dom$ llvm- llvm-cpp-4.2 llvm-g++ llvm-g++-4.2 llvm-gcc llvm-gcc-4.2 And Dominics-MacBook-Pro:Laplace dom$ clang clang clang++ But ghc-info tells me Dominics-MacBook-Pro:Laplace dom$ ghc --info [("Project name","The Glorious Glasgow Haskell Compilation System") ,("GCC extra via C opts"," -fwrapv") ,("C compiler command","/usr/bin/gcc") ,("C compiler flags"," -m64 -fno-stack-protector -m64") ,("ar command","/usr/bin/ar") ,("ar flags","clqs") ,("ar supports at file","@ArSupportsAtFile@") ,("touch command","touch") ,("dllwrap command","/bin/false") ,("windres command","/bin/false") ,("perl command","/usr/bin/perl") ,("target os","OSDarwin") ,("target arch","ArchX86_64") ,("target word size","8") ,("target has GNU nonexec stack","False") ,("target has .ident directive","True") ,("target has subsections via symbols","True") ,("LLVM llc command","llc") ,("LLVM opt command","opt") ,("Project version","7.6.2") ,("Booter version","7.4.2") ,("Stage","2") ,("Build platform","x86_64-apple-darwin") ,("Host platform","x86_64-apple-darwin") ,("Target platform","x86_64-apple-darwin") ,("Have interpreter","YES") ,("Object splitting supported","YES") ,("Have native code generator","YES") ,("Support SMP","YES") ,("Unregisterised","NO") ,("Tables next to code","YES") ,("RTS ways","l debug thr thr_debug thr_l thr_p dyn debug_dyn thr_dyn thr_debug_dyn") ,("Leading underscore","YES") ,("Debug on","False") ,("LibDir","/usr/local/lib/ghc-7.6.2") ,("Global Package DB","/usr/local/lib/ghc-7.6.2/package.conf.d") ,("Gcc Linker flags","[\"-m64\"]") ,("Ld Linker flags","[\"-arch\",\"x86_64\"]") ] But I don't have either llc or opt Dominics-MacBook-Pro:Laplace dom$ llc -bash: llc: command not found Dominics-MacBook-Pro:Laplace dom$ opt -bash: opt: command not found Dominics-MacBook-Pro:Laplace dom$ What is the solution? Thanks, Dominic Steinitz dominic(a)steinitz.org http://idontgetoutmuch.wordpress.com

5 11