August 2008 - Haskell-Cafe

the "process" package ...
by Galchin, Vasili 22 Aug '08

22 Aug '08

Hello, The "process" package Internal.hs references HsProcessConfig.h but this include file is not in the package "include" directory. Is this C include supposed to be generated? ?? KInd regards, Vasili

2 6

parser combinators need how many values to report errors?
by Jason Dusek 21 Aug '08

21 Aug '08

I'm looking for a copy of: Predictive Parser Combinators Need four Values to Report Errors. I've poked around on the JFP's web site at Cambridge and they don't seem to have Volume 6 anymore. -- _jsn

1 0

CouchDB module in Yhc source tree: clarification, and small problems with other packages
by Dimitry Golubovsky 21 Aug '08

21 Aug '08

Hi, Don asked: > Are we likely to see the couchdb bindings released as a standalone > library for the wider community? Let me explain a little bit why the CouchDB module appears in the Yhc repo. As the next stage of the Yhc/Javascript project, I am trying to set up a web service where people might upload some Haskell code (or reference to such code, these details haven't been clarified yet), and get it compiled by background Yhc/ycr2js batch job, returning a HTML page with Javascript in response. CouchDB was picked* as intermediate storage for this project. Therefore an interface module was needed, so I wrote one. This module, `Database.CouchDB' is not 100% finished; it was coded up to satisfy the needs of the first utility I wrote, `cdbup' which is currently capable of uploading a text (utf-8 expected) or a binary file as a document attachment to CouchDB. So some functionality hasn't been coded yet, although it will definitely be, as the project develops. Regarding packaging, I hope I will eventually put it on Hackage, but there are some problems with another packages which I'll try to explain here, so maybe those packages' developers suggest something. 1. Text.JSON. This module was picked from Jun Mukai's haskellnet package (http://darcs.haskell.org/SoC/haskellnet/) One problem with this package, it needs too many dependencies (while JSON module relies only on Packrat parser). I had to extract the JSON module into Yhc tree; can the haskellnet package be split somehow into orthogonal sub-packages, and maybe one toplevel package which would pull all parts together if used? 2. Text.JSON again. I had to change the pNumber function (parser for numeric nodes) replacing the '1'..'9' digits range with '0' .. '9'. Otherwise it did not handle JSON-encoded numbers equal to zero. I am not sure I was 100% right, so perhaps some JSON experts here might correct me. 3. Packrat parser does not seem to be packaged anywhere else, does it? 4. The dataenc package (http://code.haskell.org/dataenc/devo/) from which I pulled the Codec.Binary.Base64 module. The package may need some adjustment to GHC 6.8.x packages structure as only "base" listed in build-depends does not seem to be enough: when building it, Cabal complains for hidden packages such as collections (which I had to add manually to the cabal file), etc. Is it some problem with my GHC setup, or does just the dataenc.cabal need to be updated? So, in order to get things done quicker, I pulled the said pieces from their packages into Yhc tree. For packaging the CouchDB interface, definitely these duplicates need to be removed. Other packages that CouchDB relies upon, are**: base, network, HTTP, filepath, base64-string, utf8-string Thanks for the interest in CouchDB interface, and feel free to ask any questions. --- * before support form IBM/Apache was announced, but this recent development definitely increases interest to CouchDB ** Just from the -package options I used to compile it; I may have something omitted here. -- Dimitry Golubovsky Anywhere on the Web

5 5

poll: how can we help you contribute to darcs?
by Eric Kow 21 Aug '08

21 Aug '08

Dear Haskellers, I would like to take an informal poll for the purposes of darcs recruitment. Could you please complete this sentence for me? "I would contribute to darcs if only..." The answers I am most interested in hearing go beyond "... I had more time". For instance, if you are contributing to other Haskell/volunteer projects, why are you contributing more to them, rather than darcs? The context: Lately, darcs has suffered a setback: the GHC team has decided that it is now time to switch to a different system, like git or Mercurial. This is probably a good thing for GHC and for us. By the way, good luck to them, and thanks for everything! (better GHC == better darcs) But where is darcs going? For now, we are going to have to focus on what we do best, providing precision merging and a consistent user interface for small-to-medium sized projects. I want more, though! I want to see darcs 2.1 come out next year, performance enhanced out the wazoo, and running great on Windows. And I want to see Future Darcs, the universal revision control system, seamlessly integrating with everybody else. We need to learn to do better so that darcs can achieve this kind of wild success. For example, whereas darcs suffers from the "day job" problem, xmonad has had to turn developers away! As Don mentions, this is partly thanks to their extreme accessibility (better self-documentation). But does anyone have more specific ideas about things we need to change so that you can contribute to darcs? How do we hit critical hacker mass? I have jotted down some other thoughts here regarding recruitment here: http://wiki.darcs.net/index.html/Recruitment In the meantime, if you have been discouraged from hacking on darcs, we want to know why, and how we can change things! Thanks,

27 45

cabal build command and package versions
by Nicolas Frisby 21 Aug '08

21 Aug '08

I have a question about cabal's behavior for the build command. When using the build command on a cabalized project, any version changes for installed packages go unnoticed - the necessary modules in the project are not re-compiled. If however, you run the configure command (though the .cabal file for the project has not changed) and then the build command, the appropriate modules (and only the appropriate modules) are re-compiled. Not knowing that the configure command is necessary to detect changes in package that the current project depends on and proceeding only with the build command has led to BusErrors and GHC incurring the impossible in my exploration. Is there a reason that the build command does not check the packages for version changes? It seems fair to expect package-sensitivity of the process that determines if modules need to be re-compiled. This process, I think, is part of the build command and not the configure command. Here's an example scenario: - Imagine package Q depends on package P. - We "runhaskell Setup.hs clean/configure/build/install" them both, from scratch, at version 0. - Then we change package P (by, say, introducing new fields to a constructor that Q cases over), bump its version to 1, and "runhaskell Setup.hs clean/configure/build/install" on it. - If we now "runhaskell build" on package Q, nothing is re-compiled, though a package dependency has changed. "runhaskell Setup.hs build" does not notice this. - However, if we "runhaskell configure/build" on package Q, then the (necessary) modules are re-compiled. Thanks for your time.

3 3

Haskell Xcode Plugin
by Dennis Buchmann 21 Aug '08

21 Aug '08

Hello, during my search for an acceptable development environment under Mac OS X I found this Plugin for Xcode: http://hoovy.org/HaskellXcodePlugin/ Unfortunately, I'm not able to get it to run in Xcode v3.0 and the developer seems to be not contactable at the moment. So, has anyone installed this plugin successfully (with problems in the beginning)? With best regards Dennis Buchmann

3 2

unknown flags scramble
by Evan Laforge 21 Aug '08

21 Aug '08

I've been getting a mysterious error for a while now. It's come and gone, but seems to be showing up slightly more consistently now. Before I was on ghc 6.8.2 and now I'm on ghc 6.8.3, OS X 10.4 and now 10.5, i386 arch. The problem is that randomly while compiling I get an error like this: unknown flags in {-# OPTIONS #-} pragma: -XDeriveDataTypeabl<Data/Array/IArray.hs" #<e Ui.Font ( TextStyle(..), Font(..), FontFace(..) ) where import qualified Data.Generics as <Data/Array/IArray.lhs.L<array-0.1.0.0ali<Color as Color import Foreign import qualified Ui.Util as Util {-# LINE 14 "Ui/Font.hsc" It looks like somehow pragma parsing gets a bunch of random junk scrambled in. In the past this would happen consistently until I did a make clean and rebuild, but more recently all I have to do is try again and it doesn't happen the second time. I haven't gotten it while compiling for a while, but since I'm using hint which uses the ghc api to interpret haskell, I'm getting this quite frequently inside a GhcException when hint wants to interpret some code. I've also gotten this from ghci occasionally, and the usual fix is just to do a reload, and the second time it works. Does this sound familiar to anyone? It's not fatal since a retry clears things up, but it's a little worrying and would not look very good in released software. I cast about a bit on the ghc trac and didn't find any open bugs like this.

2 2

a recent Haskell contribution?
by Galchin, Vasili 21 Aug '08

21 Aug '08

Hello, Recently someone made a post about a message-passing IPC that they contributed (within one month?). I have been searching the Haskell cafe archive to no avail. Can the contributor (or any one else) tell where the code is and any papers? Thank you, Vasili

3 2

lines of code metrics
by Greg Fitzgerald 20 Aug '08

20 Aug '08

Does anyone know of a good case study comparing a project written in C versus one written in Haskell? I'm mostly looking for a comparison of lines of code, but any other metric, such as time to market and code quality metrics could also be

8 10

"build depends:" in a .cabal file
by Galchin, Vasili 20 Aug '08

20 Aug '08

Hello, It seems to me that the "build depends" attribute/field is only informational, i.e. it doesn't cause "faulting in" dependencies if not present? If true, this seems to be a deficiency in cabal. ?? Kind regards, Vasili PS It seems to me that for HaskellDB the "build depends" is incomplete in that it should contain "old time" and "TextPrettyPrint.HughesPJ"??

8 13