- Haskell-Cafe - Haskell.org

ByteString.getContents fails for files >2GB on OS X
by Shaun Jackman 21 Jun '12

21 Jun '12

Hi, Data.ByteString.Char8.getContents fails for files >2GB on OS X. Is there a fix for this? $ cat getContents.hs main = getContents $ ./getContents <smallFile $ ./getContents <bigFile getContents: <stdin>: hGetBuf: invalid argument (Invalid argument) $ ghc --version The Glorious Glasgow Haskell Compilation System, version 7.4.1 Mac OS X 10.7.4 64-bit As a workaround, I used ByteString.Lazy instead of the strict ByteString, which worked, but found it was ~4 times slower for my program, so I'd like to get the strict ByteString working with large files. Cheers, Shaun

5 6

Cannot System,Timeout.timeout Network.accept
by Daniel Hlynskyi 21 Jun '12

21 Jun '12

Hello Cafe. I cannot accept socket connection with timeout (Windows, GHC 7.4,1). Consider following code: > import Network > import System.Timeout > main = withSocketsDo $ do > print ":: Starting server ..." > sock <- listenOn (PortNumber 4010) > res <- timeout 1 (accept sock) > print "Timed out" -- Never output! > sClose sock Documentation on http://www.haskell.org/ghc/docs/latest/html/libraries/base/System-Timeout.h… says:"... Standard I/O functions like ... Network.Socket.accept, ... appear to be blocking, but they really don't because the runtime system uses scheduling mechanisms like select(2) to perform asynchronous I/O, so it is possible to interrupt standard socket I/O or file I/O using this combinator." Neither Network.accept, nor Network.Socket.accept can be timed out is example above. Is it bug?

2 2

Re: [Haskell-cafe] [Haskell] JustHub 'Sherkin' Release
by Chris Dornan 21 Jun '12

21 Jun '12

[This discussion was started on the Haskell mailing list in response to an announcement I made which you can read here http://justhaskell.org/2012/06/13/announce-justhub-sherkin/ At issue is whether the JustHub Haskell distribution for Enterprise Linux and the hub hackage for sandboxing development projects and integrating multiple GHC tool chains is redundant because all of the functionality is covered by the Nix Haskell distribution, allowing as they do multiple Nix Haskell releases to be deployed simultaneously.] (cd = Chris Dornan, al = Andres Löh) cd: > The key feature is the way it integrates the multiple tool chains into cd: > a single virtual tool chain with a sandboxing mechanism provided by cd: > the hub hackage. cd: > I think the Nix distribution might be a natural fit for 'hub' cd: > integration -- I would be happy to work with the Nix people on that cd: > (though it can't be right now). al: If this adds anything in terms of functionality that Nix doesn't already provide, al: then I would be interested to know. From having a quick look at your al: announcements, it's not quite clear though if it does. Hi Adres, >From the original announcement (on the above link): The JustHub distribution is based on the Hub system for sandbox development that allows each work tree to work in its own sandboxed environment with a specific tool chain and a private user-package database. All of the standard Haskell tools inter-operate cleanly and transparently with the sandboxes and operate in the normal way outside of them. Sandboxed environments (hubs) can be shared between work trees as well as being (re)named, annotated, replicated, swapped, archived, locked and removed. Proper package deletion with the option of garbage collecting orphaned code and documentation is also supported. Where is this functionality provided by Nix? These are the 'key features' that I emphasized in the clarification. I have loaded GHC-7.4.1 platform and the GHC-7.0.4 into Nix and it installs all of the ghc drivers into a single bin directory in the user's profile. I am guessing that running `ghc` will generally get you the latest compiler you have installed (7.4.1 in my case); specific releases can be invoked with ghc-7.0.4, etc. This hardly covers all of the above functionality! I think the Nix distribution is excellent and I strongly agree with its functional philosophy -- which I think is the right way to distribute Haskell. Quite related to this (in my mind anyway) are the user-level facilities for managing the package databases that each work tree uses -- the problems that cabal-dev was created to solve. What I have done is to create a system that manages the environment each source work tree uses. If you are in a 2012.2.0.0-based project work tree then the ghc-driver will detect that and invoke the right tools. The 2012.2 platform uses cabal-instal-0.14 and that is what you will get when you invoke cabal in such a work tree. However in work trees based on earlier version of the compiler (e.g., GHC-7.2.2), cabal-install-0.10.2 will be used because cabal-install-0.14.0 doesn't interoperate very well with cabal-0.10 and earlier (see https://github.com/haskell/cabal/issues/932) Also in such a work tree you will get all of the tools that were shipped with the GHC-7.2.2 and all through issuing the usual command 'ghc', 'ghci', 'ghc-pkg', etc). Without some system to help the user invoke the right tools in the right context, having to invoke each version of the compiler explicitly can get awkward to use quite quickly. Think about installing a package into a 7.0.4-based work tree where 'ghc' runs version 7.4.1. Cabal will reach for 7.4.1 unless told otherwise. The only practical way to do this is to build a PATH where the right tools get run on the default commands ('ghc', 'ghc-pkg', etc), or equivalently use intelligent drivers that make sure the right tools get invoked (the method JustHub uses). It is also sometimes helpful to be able to start from the minimal collection of packages that you get with compiler (sans platform packages) and build your collection from there. The JustHub system allows you to do this, even on installations that are working double time as Haskell Platform instantiations. Oftentimes less is more in working out the right package combination! Production Haskell development requires this kind of control over the environment, we have all been doing this for years and it isn't technically difficult. But frankly it sure is tedious, especially when you have worked with something better. And it means that everyone has to hand-build their own developments -- that is wasteful. GHC+cabal do provide an awesome build system but the package management mechanisms aren't as easy to use as they could be. There is no proper mechanism for erasing packages for instance (arguably because it is meaningless -- reinforcing my point) and the mechanisms for managing package databases are inconsistent across the tools (differing between 'cabal' and 'ghc'/ghc-pkg') and not very friendly (requiring the setting up of environment variables and the use of special flags). I have also found it highly useful to be able to name, replicate, archive and share environments between different work trees All of this together (including the missing bits) can make for quite a steep learning curve for those gearing up for writing production Haskell code, and it can get in the way to a surprising degree even for those that have been doing it for a while (or at least that has been my experience). You may dismiss that as pointless or irrelevant but it _is_ a large part of what I am trying get right and it did feature prominently in the announcement. I can see elements of this present in the Nix distribution and cabal-dev and similar tools. But our current standard tools don't make it easy for a developers to unpack a production work tree, ensure the relevant tool chain is installed and just work with it in the precise configuration it needs; each developer has to solve that for themselves. I think the Nix functional approach to distributions is definitely going in the right direction in giving user better control over which packages are installed but, unless I have missed something, I don't think it is so definitive that there isn't room for other developments. Finally a couple of gripes with Nix as a replacement for JustHub. JustHub has a special emphasis on Enterprise Linux (RHEL/CentOS/SL) developers. Because the EL family of O/Ses have such long lifetimes for each O/S release they pose special problems. The GCC tools shipped with RHEL5 are just too long in the tooth for use with recent versions of GHC, which is why JustHub ships with GCC-4.6.1 and binutils-2.21. As we have seen the Nix Linux package doesn't work with CentOS 5 and I have tried to get the Nix distribution loaded onto an up-to-date CentOS 6 system. As far as I could tell that required building the package manager from source but the build failed with an opaque libtool-related message. Because the RPMs are available for Fedora that was much easier to use. Also I could not determine which releases of GHC you are supporting. It looks as the distribution is focused on the Haskell Platform, in which case only those releases of GHC will be available, when they get scheduled for inclusion in the platform. This is a more selective collection than I am aiming to provide with JustHub, but perhaps more importantly, it makes it hard for anyone trying to get hold of an older release of the compiler to find it and load it into Nix. Chris

4 17

The Layout Rule
by Michael D. Adams 21 Jun '12

21 Jun '12

I am looking for background material on how GHC and other Haskell compilers implement the layout rule. Are there any papers, documentation, commentary, etc. that discus the actual implementation of this rule (even if only a paragraph or two)? I've already looked at the parsing code in GHC and UHC. Do any other Haskell compilers have interesting approaches for implementing the layout rule? I am writing a paper about a new formalism for indentation sensitive languages and I want to ensure I've covered the appropriate background material on existing implementations of the layout rule. Michael D. Adams mdmkolbe(a)gmail.com

2 1

Haskell Weekly News: Issue 232
by Daniel Santa Cruz 20 Jun '12

20 Jun '12

Welcome to issue 232 of the HWN, an issue covering crowd-sourced bits of information about Haskell from around the web. This issue covers the week of June 10 to 16, 2012. Quotes of the Week * irene-knapp: ewtoombs: the universe is already an interactive quantum physics simulator * Philipp: "While in Python every problem can be solved with a big enough Hashtable, in Haskell, every problem can be solved with an additional type parameter." * kulin: man, i am loving this existential quantification, i feel like now i will use it incorrectly to solve every problem for sure * mekeor: xmonad is awesome (ignore the ambiguity, please) Top Reddit Stories * Waldo - the Haskell powered codebase behind xkcd’s Umwelt comic Domain: self.haskell, Score: 75, Comments: 16 On Reddit: [1] http://goo.gl/M2fGv Original: [2] http://goo.gl/M2fGv * “ARM is now a fully supported target platform for GHC, complete with GHCi support” Domain: haskell.org, Score: 60, Comments: 17 On Reddit: [3] http://goo.gl/O0XK3 Original: [4] http://goo.gl/0Fajp * 3D Mandelbrot in OpenGL from imperative to functional style. Domain: yannesposito.com, Score: 36, Comments: 8 On Reddit: [5] http://goo.gl/5MKK1 Original: [6] http://goo.gl/nzpvl * ANN: clckwrks - a Haskell blogging and CMS framework Domain: groups.google.com, Score: 35, Comments: 21 On Reddit: [7] http://goo.gl/ROrHt Original: [8] http://goo.gl/WneBw * web server C10k benchmark: snap vs. erlang, go, node.js, java Domain: github.com, Score: 35, Comments: 5 On Reddit: [9] http://goo.gl/r1Q1j Original: [10] http://goo.gl/eFlTm * GADTs Domain: haskellforall.com, Score: 33, Comments: 74 On Reddit: [11] http://goo.gl/B41Ef Original: [12] http://goo.gl/rcL6I * Announcing Elm 0.2: Haskell integration (Yesod, HAppStack, and Snap), better error messages, larger examples, and more. Domain: self.haskell, Score: 30, Comments: 8 On Reddit: [13] http://goo.gl/ENBPH Original: [14] http://goo.gl/ENBPH * command line options using applicative without Template Haskell Domain: github.com, Score: 28, Comments: 13 On Reddit: [15] http://goo.gl/zqKGw Original: [16] http://goo.gl/eVSAb * Haskell and Yesod - Book on writing web applications in Haskell Domain: shop.oreilly.com, Score: 28, Comments: 5 On Reddit: [17] http://goo.gl/0RdvE Original: [18] http://goo.gl/9qCEu Top StackOverflow Questions * Tying the Knot with a State monad votes: 33, answers: 3 Read on SO: [19] http://goo.gl/cMcRf * Lazy evaluation of terms in an infinite list in Haskell votes: 32, answers: 4 Read on SO: [20] http://goo.gl/IyRJ1 * What is going on with the types in this ghci session? votes: 17, answers: 1 Read on SO: [21] http://goo.gl/3RVnN * the seq function and strictness votes: 14, answers: 2 Read on SO: [22] http://goo.gl/f8u9G * Is it possible to “hide” language extensions? votes: 11, answers: 2 Read on SO: [23] http://goo.gl/q4JQx * Rebinding do notation for indexed monads votes: 11, answers: 1 Read on SO: [24] http://goo.gl/Z4lnx * Haskell: “how much” of a type should functions receive? and avoiding complete “reconstruction” votes: 9, answers: 1 Read on SO: [25] http://goo.gl/2FFHu * Intelligent purely functional sets votes: 8, answers: 1 Read on SO: [26] http://goo.gl/I7Tzb * Is there a better way to express the absolute error function in point-free notation? votes: 8, answers: 2 Read on SO: [27] http://goo.gl/FFFek * GADTs vs. MultiParamTypeClasses votes: 7, answers: 2 Read on SO: [28] http://goo.gl/3DYKI Until next time, Daniel Santa Cruz References 1. http://www.reddit.com/r/haskell/comments/uved7/waldo_the_haskell_powered_co… 2. http://www.reddit.com/r/haskell/comments/uved7/waldo_the_haskell_powered_co… 3. http://www.haskell.org/pipermail/haskell-cafe/2012-June/101704.html 4. http://www.reddit.com/r/haskell/comments/uv07c/arm_is_now_a_fully_supported… 5. http://yannesposito.com/Scratch/en/blog/Haskell-OpenGL-Mandelbrot/ 6. http://www.reddit.com/r/haskell/comments/v4pzk/3d_mandelbrot_in_opengl_from… 7. https://groups.google.com/forum/#!msg/clckwrks/58AwDSRRGoI/prrMP6fhtqMJ 8. http://www.reddit.com/r/haskell/comments/uyr0y/ann_clckwrks_a_haskell_blogg… 9. https://github.com/ericmoritz/wsdemo/blob/results-v1/results.md 10. http://www.reddit.com/r/haskell/comments/v595l/web_server_c10k_benchmark_sn… 11. http://www.haskellforall.com/2012/06/gadts.html 12. http://www.reddit.com/r/haskell/comments/v5ewa/gadts/ 13. http://www.reddit.com/r/haskell/comments/uugne/announcing_elm_02_haskell_in… 14. http://www.reddit.com/r/haskell/comments/uugne/announcing_elm_02_haskell_in… 15. https://github.com/pcapriotti/optparse-applicative 16. http://www.reddit.com/r/haskell/comments/uw7eq/command_line_options_using_a… 17. http://shop.oreilly.com/product/0636920023142.do 18. http://www.reddit.com/r/haskell/comments/v64f5/haskell_and_yesod_book_on_wr… 19. http://stackoverflow.com/questions/11060565/tying-the-knot-with-a-state-mon… 20. http://stackoverflow.com/questions/10972429/lazy-evaluation-of-terms-in-an-… 21. http://stackoverflow.com/questions/11003535/what-is-going-on-with-the-types… 22. http://stackoverflow.com/questions/11046590/the-seq-function-and-strictness 23. http://stackoverflow.com/questions/11035676/is-it-possible-to-hide-language… 24. http://stackoverflow.com/questions/11042685/rebinding-do-notation-for-index… 25. http://stackoverflow.com/questions/10967832/haskell-how-much-of-a-type-shou… 26. http://stackoverflow.com/questions/10971237/intelligent-purely-functional-s… 27. http://stackoverflow.com/questions/11006772/is-there-a-better-way-to-expres… 28. http://stackoverflow.com/questions/10994508/gadts-vs-multiparamtypeclasses

1 0

Re: [Haskell-cafe] ANNOUNCE : Leksah 0.12.1.2 (fixes some metadata issues)
by Hilco Wijbenga 20 Jun '12

20 Jun '12

On 20 June 2012 18:22, Oliver Batchelor <saulzar(a)gmail.com> wrote: > Check the error given by cairo. > > cabal install cairo-0.12.3.1 Well, it wasn't cairo that was the problem but ... > You probably need to put the .cabal/bin in your PATH, so that the > tools such as c2hs can run. ... indeed, adding .cabal/bin to my PATH allowed the install to finish successfully. Why doesn't cabal abort when a package fails to install? Why doesn't it die if .cabal/bin isn't on the PATH? (Surely, that's easy to test for?)

1 0

relocation R_X86_64_PC32 against undefined symbol
by Henning Thielemann 20 Jun '12

20 Jun '12

Just for the record: I compiled with GHC and got the linker error: /usr/bin/ld: dist/build/.../Module.dyn_o: relocation R_X86_64_PC32 against undefined symbol `..._xyz1_closure' can not be used when making a shared object; recompile with -fPIC Problem was that I forgot to declare Module in the Cabal description.

1 0

[Word8] -> FilePath using ghc's file system encoding
by Joey Hess 20 Jun '12

20 Jun '12

I found myself writing the code below today, and thought I'd write to see if there's a better way, perhaps one that doesn't use unsafePerformIO. A sample use case for this is a program that reads a FilePath from a Handle, and then operates on that file on disk. GHC uses a special encoding for FilePaths that cleanly roundtrips invalid utf8, but for that to work, the FilePath must be read using that encoding too. Neglecting to do that would result in a program that worked for most filenames, but failed on edge case non-utf8 encoded filenames. Another way to deal with this problem is to first hSetEncoding using GHC.IO.Encoding.getFileSystemEncoding, and then read from the Handle using hGetLine, which applies the encoding to the data it reads. However, in this case I needed to use ByteString to read from the Handle, and so needed a way to convert from a ByteString to a FilePath. (Using RawFilePath would be another approach, but reworking my program to use it isn't practical.) Anyway, it seems there should be a pure way to encode a string with GHC's filesystem encoding. ----- import qualified GHC.Foreign as GHC import qualified GHC.IO.Encoding as Encoding import System.IO.Unsafe import Data.Bits.Utils -- from MissingH {- Converts a [Word8] to a FilePath, encoding using the filesystem encoding. - - w82c produces a String, which may contain Chars that are invalid - unicode. From there, this is really a simple matter of applying the - file system encoding, only complicated by GHC's interface to doing so. -} {-# NOINLINE encodeW8 #-} encodeW8 :: [Word8] -> FilePath encodeW8 w8 = unsafePerformIO $ do enc <- Encoding.getFileSystemEncoding GHC.withCString Encoding.char8 (w82s w8) (GHC.peekCString enc) -- see shy jo

1 0

Problem with plugins
by Timo von Holtz 20 Jun '12

20 Jun '12

Hi, I'm currently working on extending the hascat Server. My problem is, that for whatever odd reason it will only work on GHC < 7.0 or alternatively if I execute it with runghc or in ghci. If I compile it with GHC>=7.0 and execute it, then I get this: $ ~/.cabal/bin/hascat config.xml Installing "Root" at / hascat: /home/tvh/.cabal/lib/plugins-1.5.2.1/ghc-7.4.1/HSplugins-1.5.2.1.o: unknown symbol `ghczm7zi4zi1_ErrUtils_zdsinsertzugo3_info' hascat: unloadObj: can't find `/usr/lib/ghc/binary-0.5.1.0/HSbinary-0.5.1.0.o' to unload user error (unloadObj: failed) Installing "Hascat Server Info" at /ServerInfo/ hascat: /home/tvh/.cabal/lib/hascat-system-0.2/ghc-7.4.1/HShascat-system-0.2.o: unknown symbol `base_DataziMaybe_Nothing_closure' hascat: unloadObj: can't find `/usr/lib/ghc/Cabal-1.14.0/HSCabal-1.14.0.o' to unload user error (unloadObj: failed) Installing "Hascat Application Manager" at /Manager/ hascat: /home/tvh/.cabal/lib/hascat-system-0.2/ghc-7.4.1/HShascat-system-0.2.o: unknown symbol `base_DataziMaybe_Nothing_closure' hascat: unloadObj: can't find `/usr/lib/ghc/Cabal-1.14.0/HSCabal-1.14.0.o' to unload user error (unloadObj: failed) Installing "Hascat Application Deployer" at /Deployer/ hascat: /usr/lib/haskell-packages/ghc/lib/zlib-0.5.3.3/ghc-7.4.1/HSzlib-0.5.3.3.o: unknown symbol `base_GHCziForeignPtr_ForeignPtr_con_info' hascat: unloadObj: can't find `/usr/lib/ghc/Cabal-1.14.0/HSCabal-1.14.0.o' to unload user error (unloadObj: failed) Waiting for connections on port 8012 Is there a way to make this work? Greetings Timo

2 3

Re: [Haskell-cafe] Again, version conflicting problem with cabal-install
by Jason Dagit 19 Jun '12

19 Jun '12

In my experience the diamond of death is typically because: * You install package A that uses C-0.1 * Someone uploads C-0.2 to hackage * Later you 'cabal update', this does not rebuild A to use C-0.2, even though it could. * You install package B that uses C, and cabal builds it with C-0.2 * Now you want to build D that uses A and B, but A requires C-0.1 and B requires C-0.2, even though they could be rebuilt to use the same C. Typically, the constraints on A, B, and D would all accept the same version of C. Except that when they were compiled separately and C changed between building A and B, then the compiled versions become fixed on C-0.1 and C-0.2. It's true that it won't solve it in all cases, but in my experience using cabal-dev made the problem go away. I hope that clarifies. Jason On Fri, Feb 3, 2012 at 7:33 AM, Magicloud Magiclouds <magicloud.magiclouds(a)gmail.com> wrote: > Well, cabal-dev could not resolve the conflict of "the diamond". > Because the conflict is "depending different version at the SAME > time". > > On Fri, Feb 3, 2012 at 9:20 PM, Jason Dagit <dagitj(a)gmail.com> wrote: >> On Thu, Feb 2, 2012 at 9:54 PM, Magicloud Magiclouds >> <magicloud.magiclouds(a)gmail.com> wrote: >>> Hello, >>> As I recalled, ghc works in staticly link mode. So after one library >>> is compiled, all its build dependencies are useless. Lost, changed, >>> wheresoever, it does not matter. >>> Then why the problem of version conflicting exists? >> >> I'm not sure, but for me this problem has gone away by using cabal-dev >> to build everything. >> >> Jason > > > > -- > 竹密岂妨流水过 > 山高哪阻野云飞 > > And for G+, please use magiclouds#gmail.com.

4 9