December 2009 - Libraries

darcs patch: fixed 'cabal sdist'
by Sergei Trofimovich 23 Dec '09

23 Dec '09

Tue Dec 15 00:56:45 EET 2009 Sergei Trofimovich <slyfox(a)community.haskell.org> * fixed 'cabal sdist' It actually fixes './configure' regeneration for such distros, like gentoo, wich had to patch configure.ac and regenerate script toolchain.

1 0

containers + cabal-install 0.8.0 issues?
by Michael Snoyman 22 Dec '09

22 Dec '09

When trying to compile containers-0.2.0.1 with cabal-install 0.8.0, I get the following: Data/IntMap.hs:182:7: Could not find module `Data.Data': It is a member of the hidden package `base'. Perhaps you need to add `base' to the build-depends in your .cabal file. Use -v to see a list of the files searched for. This does not occur when I install using the Setup.hs included with containers. Also, if I put a version range on base in containers.cabal (I tried >= 4 && < 5), it also works just fine. Any chance of getting a containers-0.2.0.2 released with a version range on base? Thanks, Michael

1 0

MonadIO in mtl and transformers
by Antoine Latter 21 Dec '09

21 Dec '09

Folks, Would there be support for splitting off the MonadIO class from the mtl, and simple having Control.Monad.Trans re-export it? My proposed packaging of the functionality is here: http://community.haskell.org/~aslatter/code/monad-io Here's my problem which prompted this: I'm converting a library of mine over to the failure[1] package for returning errors, and the type on a lot of my functions is as follows: (MonadFailure MyFailureType m, MonadIO m) => Alpha -> Beta -> m Gamma The MonadFailure constraint is defined separate from its many instances, which would give the consumers of my library the choice between using the mtl or the transformers[2] library. Except that I also need a MonadIO constraint, for which I must pick from which package I choose it. Antoine [1] http://hackage.haskell.org/package/failure

3 6

parList implementation question
by Marcus D. Gabriel 21 Dec '09

21 Dec '09

Hello, In Control.Parallel.Strategies, parList is defined as parList strat [] = () parList strat (x:xs) = strat x `par` (parList strat xs) with parMap strat f xs = map f xs `using` parList strat. I have recently found that if I define forceParMap strat f xs = map f xs `using` forceParList strat where forceParList strat = foldl (\done -> (done>||) . strat) () then to date, forceParList via forceParMap gives faster results than parList via parMap. For example, in one experiment, parMap with parList run at 0.81 the time of the serial solution whereas forceParMap with forceParList run at 0.58 the time of the serial solution. This is to say, forceParList completed in 0.72 the time of parList. So, 1. Why is forceParList faster than parList? 2. Is this generic to the ghc runtime model or a particularity of the ghc implementation? Thanks in advance for the clarification, - Marcus

2 3

Re: parList implementation question
by Marcus D. Gabriel 20 Dec '09

20 Dec '09

Denis Bueno wrote: > On Fri, Dec 18, 2009 at 11:31, Marcus D. Gabriel <marcus(a)gabriel.name> wrote: >> than parList via parMap. For example, in one experiment, parMap >> with parList run at 0.81 the time of the serial solution whereas >> forceParMap with forceParList run at 0.58 the time of the serial >> solution. This is to say, forceParList completed in 0.72 the >> time of parList. So, > > I don't know your application, so it's hard to interpret your numbers. > > Are you sure those measurements are statistically significant? The particular example that I gave was a straightforward searchDepthFirst(1) algorithm. To parallelise it, I choose the initial, simple approach to determine the first list of successor nodes from an initial node and use parMap to apply the serial algorithm searchDepthFirst to this list and then reduce (concat) the list. With some RTS tuning and using a dedicated dual-core system, I was able for the problem above to reproduce the numbers that I cite above consistently to within about plus or minus a factor of 0.01. I have played with variations of this class of problem but not generally compared parList with forceParList across a broader class of problems. I like your question above. It helped me formulate this question: Is what I observed above significant or random? I hope it is not random. I guess the deeper question is how does one determine with confidence that parallised serial algorithm + startegy1 works for problem class1 and parallised serial algorithm + startegy2 works for problem class2 where both are better than the serial case for their respective class of problems across a given range of operating environments, e.g., -N2 to -N8 for 2 to 8 cores. - Marcus (1) "Algorithms, A Functional Programming Approach" by Fethi Rabhi and Guy Laplame. ISBN 0201-59604-0.

1 1

First order formula parsers in Haskell (logic-TPTP and the one in Equinox)
by Ahn, Ki Yung 18 Dec '09

18 Dec '09

Dear Daniel Schüssler and Koen Classen, I've tried using both logic-TPTP and the parser in the Equinox theroem prover. I wanted to list issues I had when I tried using the parsers. logic-TPTP http://hackage.haskell.org/package/logic-TPTP is implemented with alex and happy, and it is very close to the specification to the TPTP syntax when you look at the happy source file. So, I think it works very nice for the people who wants to work on source to source transformation from TPTP syntax. It also comes with pretty printer and exporting to plain text TPTP syntax. It seems to be tested against the TPTP problem set and also random testing with formulae generated from One problem I had with logic-TPTP parser is about dealing with comments. The TPTP syntax specification states that comments can come in between any tokens. Howerver, logic-TPTP assumes that it is only at the top level, and not in between the formlua. As a result, it fails to parse such formulae, for example, the following one: fof(equality_reflexive, axiom, ! [X] # for all X : X=X # X is equal to itself ). This is valid according to the TPTP syntax specification, and all the theorem provers I know (at least the ones in the TPTP world) accepts such formulae. I believe that there is a reason Daniel's logic-TPTP keeps the comment since TPTP syntax specification also states that comment is not to be processed same as whitespace in case theorem prover implementation may use the content of the comment as extra information. However, it is just not correct to reject valid formulae which contains comments inside. For a quick fix, I would suggest either (1) provide another set of parsing functions parse' and parseFile' that ignores all comment (2) export the lexer so that the user can build such versions of parsing functions themselves which ignores all comment tokens. (Maybe, in the long run, the happy syntax definition should allow comments between tokens?) In contrast, the parser in Equinox http://www.cs.chalmers.se/~koen/folkung/ can parse the formulae above. It just seem to ignore all comments since Equinox internally does not make use of any comments. However, the problem for me about the current parser implementation in Equinox is that it transforms the syntax tree into some normalized form. For example the formula ! [X,Y] : ... seem to be parsed as ! [X] : ! [Y] : ... So, when one wants to maintain the original form during the transformation the parser in Equinox would not be desirable for him. -- Ahn, Ki Yung

1 0

[network] `setSocketOption' fails with `Linger' option
by Valery V. Vorotyntsev 14 Dec '09

14 Dec '09

See http://is.gd/57Ptu (Network.Socket.setSocketOption). `setSocketOption' uses FFI binding to setsockopt(2), named `c_setsockopt'. > foreign import CALLCONV unsafe "setsockopt" > c_setsockopt :: CInt -> CInt -> CInt -> Ptr CInt -> CInt -> IO CInt The binding treats OPTVAL (4th argument) as a pointer to `int'. This is mostly fine but not when `SO_LINGER' option is being set. In the latter case OPTVAL must be a pointer to `struct linger'. [1] [1] http://www.gnu.org/s/libc/manual/html_node/Socket_002dLevel-Options.html Haskell programs trying to set SO_LINGER socket option will successfully compile but fail in runtime. $ runhaskell socket-linger.hs || echo X $ runhaskell -DLINGER socket-linger.hs || echo X socket-linger.hs: setSocketOption: invalid argument (Invalid argument) X $ gcc -g -Wall -W -o /tmp/1 socket-linger.c && /tmp/1 || echo X $ gcc -g -DLINGER_AS_INT -Wall -W -o /tmp/1 socket-linger.c && /tmp/1 || echo X setsockopt: Invalid argument X (See attached files `socket-linger.c', `socket-linger.hs'.) The necessity of `SO_LINGER' option is controversial (see [2]). I think it is better to comment the `Linger' constructor out of Network/Socket.hsc. [2] http://www.developerweb.net/forum/archive/index.php/t-2982.html Cheers. -- vvv

2 3

Re: [network] getAddrInfo: invalid haddock (+ patch)
by Valery V. Vorotyntsev 13 Dec '09

13 Dec '09

Johan Tibell <johan.tibell(a)gmail.com> wrote: > Sorry for the long delay. The trac instance should be fixed now. It > would be great if you could try to add a new ticket. Done. http://trac.haskell.org/network/ticket/22 I could not attach the patch though: OSError: [Errno 13] Permission denied: '/srv/trac/network/attachments/ticket' Do you think it would be secure enough if we enable attaching files to tickets (for registered Trac accounts)? -----BEGIN BACKTRACE----- Traceback (most recent call last): File "/var/lib/python-support/python2.4/trac/web/main.py", line 387, in dispatch_request dispatcher.dispatch(req) File "/var/lib/python-support/python2.4/trac/web/main.py", line 237, in dispatch resp = chosen_handler.process_request(req) File "/var/lib/python-support/python2.4/trac/attachment.py", line 361, in process_request self._do_save(req, attachment) File "/var/lib/python-support/python2.4/trac/attachment.py", line 494, in _do_save attachment.insert(filename, upload.file, size) File "/var/lib/python-support/python2.4/trac/attachment.py", line 180, in insert os.makedirs(self.path) File "os.py", line 156, in makedirs makedirs(head, mode) File "os.py", line 159, in makedirs mkdir(name, mode) OSError: [Errno 13] Permission denied: '/srv/trac/network/attachments/ticket' -----END BACKTRACE----- Cheers. -- vvv

1 0

Advance warning to package authors of breakage with Cabal-1.8
by Duncan Coutts 11 Dec '09

11 Dec '09

package authors, I'm preparing to release a new version of Cabal. This is the one that will come with ghc-6.12. A few packages with custom Setup.hs scripts will require some changes to compile with Cabal version 1.8. In most cases it is possible to have them continue to work with version 1.6 too. When you test your changes, please test against the darcs version of Cabal-1.8 rather than the one included in 6.12 RC2. The reason is that I've added in a couple API backwards compat fixes, so there's actually less to fix than you would find with the RC2 (and for at least one of those if you fix it to work with the Cabal pre-release version included in 6.12 RC2 it'll be impossible to make it work with Cabal-1.6 too). darcs get --partial http://darcs.haskell.org/cabal-branches/cabal-1.8 These minor changes will of course be rolled into the final version that comes with ghc 6.12.1. * HDBC-postgresql, MissingPy, Omega, HDBC-mysql These use the function requireProgram in their Setup.hs. This function drops one parameter in Cabal-1.8. To make the Setup.hs continue to work with Cabal-1.6 too, I suggest changing code like this: (pgconfigProg, _) <- requireProgram verbosity pgconfigProgram AnyVersion (withPrograms lbi) let pgconfig = rawSystemProgramStdout verbosity pgconfigProg into just: let pgconfig = rawSystemProgramStdoutConf verbosity pgconfigProgram (withPrograms lbi) * haskeline This uses GHC.build in its Setup.hs which no longer exists. It got split into GHC.buildLib and buildExe. Duncan

1 1

Cabal, list of include files or directories
by Maurício CA 10 Dec '09

10 Dec '09

Hi, I would like to check for a few include files, and read them, in my Setup file. However, the only structure where I can find info about include files seems to be BuildInfo, and this could only come from HookedBuildInfo in preConf and confHook. Both, however, give empty HookedBuildInfos. Thanks, Maurício

1 0