- Haskell-Cafe - Haskell.org

Video! Duncan Coutts on Cloud Haskell
by Theo 05 Feb '13

05 Feb '13

Back in October 2012 Well-Typed and Haskell expert Duncan Coutts delivered a talk on 'Cloud Haskell' at the 2K12 edition of the Haskell eXchange. Cloud Haskell takes Erlang's successful approach to distributed concurrency and implements it in Haskell as a library. We will look at what this means and what possibilities it opens up. You should also get a flavour of what distributed programming in Haskell is like. The initial Cloud Haskell idea and a prototype implementation were introduced last year. Since then we have been working on a new from-scratch implementation with a focus on robustness and flexibility Watch the video on the Skills Matter website - http://bit.ly/VB9tcy

1 0

Re: [Haskell-cafe] FFI - Approaches to C/C++
by Casey Basichis 05 Feb '13

05 Feb '13

Hi Ertugrul, I'm not entirely sure what you mean. I'm intending on using Ogre for GUI - for which there is the Hogre bindings, but after emailing the DEV about it, I didn't get the impression from his advice that I should be using it for production code. Here is what he suggested: "It depends, really. Hogre is good for running Ogre from within Haskell, but it has its limitations. The number one thing people have been struggling with is handling input with hogre - there's Hois (Haskell wrapper for OIS) but it's not perfect (it misses input events), and the other option is having to write some C++ glue. Hogre is a solid proof of concept and you can do some demos with it, but if you're e.g. writing a game it might be a bit of a struggle. In the end it's about how much you value being able to write code in Haskell (or how allergic to C++ you are)." I'm on iOS so I imagine those difficulties are compounded. I am using several other C++ libraries for which there are no existing bindings and no Haskell alternative packages that are even remotely close. Are you suggesting it would be better to write all my own FFI bindings for all the needed libraries? Everything I read suggests that Haskells strengths are in transformation and that interaction is not its strong suit. I am interested in your thoughts and I am open to whatever, but you are the first to suggest that the mix is a bad idea. Thanks, Casey >>* I'm working on a project in Haskell and C++ where the former is the*>>* brains and the latter is for UI, interaction etc.* >That's a rather odd choice. Not exactly answering your question, but >questioning your project decisions, why would you do UI and interaction >in C++? You have the necessary Haskell bindings and libraries to write >everything cleanly in Haskell. > > >Greets, >Ertugrul

5 7

haskell build phase is very slow
by Junior White 04 Feb '13

04 Feb '13

Hi Cafe, I came from the C/C++ world, recently I play with a haskell editor named yi-editor, I find haskell build phase is very slow: 1.Compile one .hs file is slow 2. When change a little, it will recompile many many files Compare to c, compile a c source file seems much quick then compile a haskell source file. And if i change a .c file, it only recompile the file i changed, and relink, it's awesome. How can i make my build phase more quick? Thanks!

3 2

<package>-inplace is shadowed by package <package>-<hexstring>
by Alexander Bernauer 04 Feb '13

04 Feb '13

Hi I am trying to write criterion benchmarks for the pretty library. Unfortunately, building the benchmark executable fails at some point during the development with the following error message: ---8<--- <command line>: cannot satisfy -package-id pretty-1.1.1.1-inplace: pretty-1.1.1.1-inplace is shadowed by package pretty-1.1.1.1-7bd0114e9691fca3d3447fc0133701cf --->8--- I don't understand the cause of the error, let alone what I am supposed to do next. Any help is much appreciated. Here are the steps that lead to the above quoted error. Sorry, if this is not the smallest counter example possible. As I said, I hardly understand what is going on. (the two patch files mentioned are attached to this email, virthualenv is version 0.2.1) ---8<--- git clone https://github.com/haskell/pretty.git cd pretty git apply /tmp/0001-hello-world-setup.patch export PATH=/opt/ghc-7.4.2/install/bin:/opt/haskell-platform-2012.4.0.0/install/bin:$PATH ~/.cabal/bin/virthualenv source .virthualenv/bin/activate cabal configure --user cabal build cabal install cabal install criterion cabal configure --user --enable-benchmarks cabal build git apply /tmp/0002-replaced-example-with-real-benchmark.patch cabal install language-c cabal configure --user --enable-benchmarks cabal build # error --->8--- So the first build of the benchmark executable works, but the second one "suddenly" fails. Executing "cabal build -v" next yields ---8<--- $ cabal build -v creating dist/build creating dist/build/autogen Building pretty-1.1.1.1... Preprocessing library pretty-1.1.1.1... Building library... creating dist/build /opt/ghc-7.4.2/install/bin/ghc --make -package-name pretty-1.1.1.1 -hide-all-packages -fbuilding-cabal-package -package-conf /home/alex/tmp/pretty/.virthualenv/ghc_pkg_db -i -idist/build -isrc -idist/build/autogen -Idist/build/autogen -Idist/build -optP-include -optPdist/build/autogen/cabal_macros.h -odir dist/build -hidir dist/build -stubdir dist/build -package-id base-4.5.1.0-66f22db3dfcd87541c9c7e50e7095d26 -O -Wall -fwarn-tabs -XHaskell98 -XCPP -XBangPatterns Text.PrettyPrint Text.PrettyPrint.HughesPJ Linking... /usr/bin/ar -r dist/build/libHSpretty-1.1.1.1.a dist/build/Text/PrettyPrint.o dist/build/Text/PrettyPrint/HughesPJ.o /usr/bin/ar: creating dist/build/libHSpretty-1.1.1.1.a /usr/bin/ld -x --hash-size=31 --reduce-memory-overheads -r -o dist/build/HSpretty-1.1.1.1.o dist/build/Text/PrettyPrint.o dist/build/Text/PrettyPrint/HughesPJ.o Registering pretty-1.1.1.1... /opt/ghc-7.4.2/install/bin/ghc-pkg update - --global --user --package-conf=/home/alex/tmp/pretty/.virthualenv/ghc_pkg_db --package-conf=dist/package.conf.inplace Preprocessing benchmark 'bench-pretty' for pretty-1.1.1.1... Building benchmark bench-pretty... creating dist/build/bench-pretty creating dist/build/bench-pretty/bench-pretty-tmp /opt/ghc-7.4.2/install/bin/ghc --make -o dist/build/bench-pretty/bench-pretty -hide-all-packages -fbuilding-cabal-package -package-conf /home/alex/tmp/pretty/.virthualenv/ghc_pkg_db -package-conf dist/package.conf.inplace -i -idist/build/bench-pretty/bench-pretty-tmp -ibench -idist/build/autogen -Idist/build/autogen -Idist/build/bench-pretty/bench-pretty-tmp -optP-include -optPdist/build/autogen/cabal_macros.h -odir dist/build/bench-pretty/bench-pretty-tmp -hidir dist/build/bench-pretty/bench-pretty-tmp -stubdir dist/build/bench-pretty/bench-pretty-tmp -package-id base-4.5.1.0-66f22db3dfcd87541c9c7e50e7095d26 -package-id criterion-0.6.2.1-5ae981935ea0c9773e0df464b5922b27 -package-id language-c-0.4.2-fe58279e43af097994ce7b7010785c69 -package-id pretty-1.1.1.1-inplace -O -O -XHaskell98 bench/Bench.hs <command line>: cannot satisfy -package-id pretty-1.1.1.1-inplace: pretty-1.1.1.1-inplace is shadowed by package pretty-1.1.1.1-7bd0114e9691fca3d3447fc0133701cf (use -v for more information) --->8--- What does this mean? What am I doing wrong? How can I fix this? Greetings, Alex

1 0

Text.PrettyPrint.HughesPJ is sloooow (and wl-pprint-text is fast)
by Johannes Waldmann 04 Feb '13

04 Feb '13

I was running into serious performance problems when printing moderately sized Doc and Xml data (HaXml goes via Doc). So I replace Text.PrettyPrint.HughesPJ with Text.PrettyPrint.Leijen.Text, and patched the HaXml printer in the same way. Now it is running much faster. This confirms some of the comments here: http://stackoverflow.com/questions/9761507/which-pretty-print-library If you want to see for yourself, here is a test case. It constructs and prints a document tree with about 10^4 nodes, rendered to an Xml document with 10^6 (nonblank) chars: https://github.com/jwaldmann/haskell-tpdb/blob/master/test/speed.hs Of the 4 output methods (fin the main program), only one takes < 1 second. Rendering via HughesPJ needs extra stack (!) and takes about 20 seconds. Rendering via Text.XML.HaXml.ByteStringPP seems much slower still (!) (ghc-7.6.2, pretty-1.1.1.0, HaXml-1.23.3, wl-pprint-text-1.1.0.0, amd64, fedora 18, kernel 3.7.4)

2 1

Problems with code blocks in the description field in a .cabal file
by Josef Svenningsson 04 Feb '13

04 Feb '13

Hi, I'm putting together a cabal package and I'd like to have some code examples in my description file. In particular I would like to have a code block containing markdown containing a code block of Haskell, like this: > ~~~{ .haskell } > module Main where > > main = putStrLn "Hello World!" > ~~~ When I put the above code in my .cabal file and do `cabal haddock --executables` I get the following error: haddock: failed to parse haddock prologue from file: dist/doc/html/codeExtract/codeExtract/haddock-prolog31969.txt In general I can provoke the parse error from haddock whenever I have something inside curly braces. So the error seems to stem from haddock. I've tried to track down what happens inside haddock but I've run out steam. I'd like to know if there is anything I can do to be able to write something like the above as part of the description in my .cabal file. Thanks, Josef

3 6

Yet another Conduit question
by Simon Marechal 04 Feb '13

04 Feb '13

I am working with bulk sources and sinks, that is with a type like: Source m [a] Sink [a] m () The problem is that I would like to work on individual values in my conduit. I can have this: concat :: (Monad m) => Conduit [a] m a concat = awaitForever (mapM_ yield) But how can I do it the other way around ? I suppose it involves pattern matching on the different states my conduit might me in. But is that even possible to do it in a "non blocking" way, that is catenate data while there is something to read (up to a certain threshold), and send it as soon as there is nothing left to read ? Or doesn't that make any sense in the context of Conduits (in the sense that this conduit will be recheck for input before the upstream conduits will have a chance to operate) ? Another approach would be to have a map equivalent: conduitMap :: Conduit i m o -> Conduit [i] m [o] But I am not sure how to do this either ...

4 10

Re: [Haskell-cafe] Monadic parser vs. combinator parser
by Jan Stolarek 04 Feb '13

04 Feb '13

> Of course that is fine. But keep in mind that all parser combinator based > libraries are based on a top-down parsing strategy which in most places, > BUT NOT ALL, fits Haskell's syntax. Try to use the chaining combinators > where-ever possible. In case of doubt you can always spy on how things are > done in the UHC. Luckily I'm not building a parser for Haskell, but for a very small set of instructions given to a program from the command line. In case of emergency I will be looking at the source code of uulib and uu-parsinglib (which, by the way, could use some line wrapping to fit in 80 columns). Janek

1 0

Call for Nominations: Haskell Prime language committee
by Malcolm Wallace 04 Feb '13

04 Feb '13

Dear Haskell lovers, The Haskell Prime process for standardisation of new versions of the Haskell language is at something of an impasse. Since the Haskell 2010 Report was issued (at the end of 2009), there has been very little momentum to formalise existing extensions and generalisations, nor appetite to decide on whether any such extensions should be adopted as part of the core language standard. We therefore seek nominations for new members of the Haskell Prime language committee; people who have the enthusiasm to take this forward, as well as some relevant experience. If you think you would like to contribute, please nominate yourself by sending a email to haskell-2011-committee(a)haskell.org describing who you are, and what you think the committee might hope to achieve. The address above is populated by the existing committee members, but is now (temporarily) open to all during the nomination period. Nominations close in 3 weeks time, i.e. to be received by end of Sunday 24th February 2013. The process for deciding a new language committee is described at http://hackage.haskell.org/trac/haskell-prime/wiki/Committee Regards, Malcolm

1 0

Parsec Vs. src exts
by Sean Cormican 03 Feb '13

03 Feb '13

Hi, I've been spending a bit of time looking into using Parsec as a parser for a subset of the syntax of the Haskell language, a high level description of what I'm looking to create is a parser which confirms whether a given Haskell code file is valid or in the case that it isn't returns some helpful error messages to the user. (Please bear with me, I know this is a strange implementation) My question is that while I have a modest understanding of Parsec from tutorials, the haskell-src package has also been recommended of which I can find very limited documentation in comparison. However, the issue arises from both my limited understanding of haskell and lack of information on the usage of haskell-src. Can anybody provide me with some guidance on whether to try and create the parser using Parsec or if haskell-src is a better option. In the case that haskell-src is a better option, are there any tutorials or documents that I would benefit from reading? Thanks in advance, Seán

4 4