April 2011 - Libraries

Re: Hackage broken -- no building/haddock being done
by Ross Paterson 23 Apr '11

23 Apr '11

On Fri, Apr 22, 2011 at 06:40:41PM -0400, Darius Jahandarie wrote: > Hackage seems to have stopped building packages since April 16th. > Consequently, no haddocks have been created for all packages uploaded > since then. I'm afraid I don't have access to the build machine until Tuesday 26th. Hopefully it will be back on the job then.

1 0

Proposal: Add CUSeconds, CSUSeconds to Foreign.C.Types, and fix definition of CTimeval
by Ian Lynagh 22 Apr '11

22 Apr '11

Hi all, This is a proposal to add CUSeconds, CSUSeconds to Foreign.C.Types (which are Haskell versions of the C useconds_t and suseconds_t types), and fix the definition of CTimeval to use CTime and CSUSeconds rather than CLong. The C types are specified here: http://pubs.opengroup.org/onlinepubs/009695399/basedefs/sys/time.h.html This will fix a bug in getCPUTime on OS X. Patches, from William Knop, to implement this are here: http://hackage.haskell.org/trac/ghc/attachment/ticket/4970/0001-Add-Haskell… http://hackage.haskell.org/trac/ghc/attachment/ticket/4970/0002-Whitespace-… http://hackage.haskell.org/trac/ghc/attachment/ticket/4970/0003-Use-CSUSeco… http://hackage.haskell.org/trac/ghc/attachment/ticket/4970/0001-Use-CSUSeco… Discussion deadline: 7 May 2011 Thanks Ian

4 4

[PATCH 1/2] add calloc and callocBytes to Foreign.Marshal.Alloc
by Jason Dagit 22 Apr '11

22 Apr '11

--- Foreign/Marshal/Alloc.hs | 29 +++++++++++++++++++++++++++++ 1 files changed, 29 insertions(+), 0 deletions(-) diff --git a/Foreign/Marshal/Alloc.hs b/Foreign/Marshal/Alloc.hs index 612d2c7..148190b 100644 --- a/Foreign/Marshal/Alloc.hs +++ b/Foreign/Marshal/Alloc.hs @@ -53,6 +53,9 @@ module Foreign.Marshal.Alloc ( malloc, -- :: Storable a => IO (Ptr a) mallocBytes, -- :: Int -> IO (Ptr a) + calloc, -- :: Storable a => IO (Ptr a) + callocBytes, -- :: Int -> IO (Ptr a) + realloc, -- :: Storable b => Ptr a -> IO (Ptr b) reallocBytes, -- :: Ptr a -> Int -> IO (Ptr a) @@ -168,6 +171,32 @@ allocaBytesAligned :: Int -> Int -> (Ptr a -> IO b) -> IO b allocaBytesAligned size align = allocaBytes size -- wrong #endif +-- | Allocate a block of memory that is sufficient to hold values of type +-- @a@. The size of the area allocated is determined by the 'sizeOf' +-- method from the instance of 'Storable' for the appropriate type. +-- The memory is initalized to 0. +-- +-- The memory may be deallocated using 'free' or 'finalizerFree' when +-- no longer required. +-- +{-# INLINE calloc #-} +calloc :: Storable a => IO (Ptr a) +calloc = doCalloc undefined + where + doCalloc :: Storable b => b -> IO (Ptr b) + doCalloc dummy = callocBytes (sizeOf dummy) + +-- | Allocate a block of memory of the given number of bytes. +-- The block of memory is sufficiently aligned for any of the basic +-- foreign tyes that fit into a memory block of the allocated size. +-- The memory is initialized to 0. +-- +-- The memory may be deallocated using 'free' or 'finalizerFree' when +-- no longer required. +-- +callocBytes :: Int -> IO (Ptr a) +callocBytes size = failWhenNULL "calloc" (_calloc (fromIntegral size) 1) + -- |Resize a memory area that was allocated with 'malloc' or 'mallocBytes' -- to the size needed to store values of type @b@. The returned pointer -- may refer to an entirely different memory area, but will be suitably -- 1.7.4.1

5 11

Stop using "Int" for microsecond delays in "base"
by Paul Johnson 21 Apr '11

21 Apr '11

The "base" library has the "threadDelay" primitive, which takes an Int argument in microseconds. Unfortunately this means that the longest delay you can get on a 32 bit machine with GHC is just under 36 minutes (2^31 uSec), and a hypothetical compiler that only used 30 bit integers (as per the standard) would get under 10 minutes. It is a bit tricky to write general-purpose libraries with this. I think that there should be a type Delay = Int64 declaration, and that threadDelay and related functions should take that as an argument type. Paul.

17 31

ANNOUNCE: cereal-0.3.1.0
by Trevor Elliott 19 Apr '11

19 Apr '11

Hi Everyone, I'm proud to announce version 0.3.1.0 of the cereal binary-(de)serialization library [1]! This version includes some new functionality contributed by Lemmih, that adds support for partial parses in the Get monad. The changes don't modify the API presented in 0.3.0.0, instead adding a new runPartialGet function for the Get monad when partial parses are desired. [1] http://hackage.haskell.org/package/cereal-0.3.1.0

1 0

A paper relating to Data.Set and Data.Map
by Kazu Yamamoto 19 Apr '11

19 Apr '11

Hello libraries and cafe, We (Hirai and I) would like to tell you our paper relating to Data.Set and Data.Map. "Balancing Weight-Balanced Trees" is now accepted and will appear in Journal of Functional Programming. The camera-ready version of the paper is available from: http://www.mew.org/~kazu/proj/weight-balanced-tree/ Please recall that Taylor Campbell reported a bug of Data.Map in last Summer. In some cases, the balance of Data.Map is broken after delete operations. This triggered our research. http://article.gmane.org/gmane.comp.lang.haskell.libraries/13444 Though Data.Set/Data.Map are based of a variant Weight-Balanced tree by Adams, we target the original Weight-Balanced tree by Nievergelt and Reingold. They are parameterized algorithms and the difference of two algorithms is quite small. But the original has smaller conditions which are gentle for proof. We identified the valid area of two parameters of the original Weight-Balanced tree and showed <3,2> is only one integer solution. Soundness is proved in Coq and completeness is verified with four algorithms to generate counterexamples for the outside of the valid area. "wttree.scm" of MIT/GNU Scheme and slib have already incorporated our fixes. When I offered our fixes to MIT/GNU Scheme, Taylor Campbell appeared again. I understand that he is an MIT/GNU Scheme guy and found the bug of Data.Map when re-implementing "wttree.scm" consulting Data.Map. :-) We think it's Haskell community turn now. Data.Set/Data.Map are still based on the variant whose soundness is not proved yet. If interested, let's discuss whether or not we should replace the variant with the original in Data.Set/Data.Map. We guess that Milan Straka, a big contributer of the container package, has his opinion. We welcome opinions from other people, two. Regards, --Kazu

2 1

Re: How to contact OpenGL package maintainer (where is Sven?)
by Jason Dagit 19 Apr '11

19 Apr '11

On Mon, Apr 18, 2011 at 6:21 PM, Jens Petersen <juhp(a)community.haskell.org>wrote: > On 7 April 2011 06:51, Don Stewart <dons00(a)gmail.com> wrote: > > Moving those modules under OpenGL.*.*.StateVar etc would remove the > > problems with upgrading to the HP. > > Perhaps it would be a good time now to revisit again whether > we really need to include OpenGL support inside HP or not. > > I grant that it may be convenient for users who might find it > hard to build OpenGL and GLUT with cabal-install; on the other hand > not that many haskell packages actually need those libraries AFAICT > so I am still not convinced that they really belong in HP. > Let's look at some numbers: http://www.galois.com/~dons/hackage/march-2011/mar-10-to-feb-11.txt <http://www.galois.com/~dons/hackage/march-2011/mar-10-to-feb-11.txt>Search for opengl and you'll see that it's in the top 25, meaning it's used by a relatively high number of packages. That means we're discussing a library that provides a unique capability (opengl support) that is in the top 25 of the Haskell libraries. Not making it easy to get seems like a bit of a strategic error to me. The reverse package index shows what depends on it: http://bifunctor.homelinux.net/~roel/cgi-bin/hackage-scripts/revdeps/OpenGL… And some things depend on the raw bindings instead: http://bifunctor.homelinux.net/~roel/cgi-bin/hackage-scripts/revdeps/OpenGL… Additionally, I've had 1 person contact me off list saying that they wouldn't even be a Haskell programmer if the opengl bindings were not in the HP. If there had been any barrier to getting good opengl support when they started learning Haskell that would have been a show stopper for them. Jason

1 1

Re: How to contact OpenGL package maintainer (where is Sven?)
by Don Stewart 19 Apr '11

19 Apr '11

There's a ticket to track discussion around removal here: * http://trac.haskell.org/haskell-platform/ticket/57 Removing large C library dependencies is generally a good thing; however, removing functionality is bad. And we don't have a good track record for adding functionality yet. On Mon, Apr 18, 2011 at 6:21 PM, Jens Petersen <juhp(a)community.haskell.org> wrote: > On 7 April 2011 06:51, Don Stewart <dons00(a)gmail.com> wrote: >> Moving those modules under OpenGL.*.*.StateVar etc would remove the >> problems with upgrading to the HP. > > Perhaps it would be a good time now to revisit again whether > we really need to include OpenGL support inside HP or not. > > I grant that it may be convenient for users who might find it > hard to build OpenGL and GLUT with cabal-install; on the other hand > not that many haskell packages actually need those libraries AFAICT > so I am still not convinced that they really belong in HP. > > Maybe if hopengl provided upstream binaries for current Windows and Mac HP > that might lessen the burden on the HP binary maintainers too? > > Jens >

1 0

How to contact OpenGL package maintainer (where is Sven?)
by Jason Dagit 18 Apr '11

18 Apr '11

I sent the message below to Haskell-Cafe about a week ago. I got one response saying that Sven has disappeared in the past but reappeared when updates were necessary. I still haven't heard from Sven. Now I'm widening my search. My original email to Sven was on March 11th. It looks like the OpenGL packages on hackage[1,2,3,4] have not been updated in some time. No updates later than Oct 2009. I tried to email Sven directly using the email address listed on hackage but after over two weeks I still haven't heard from him. I sent some patches to the opengl list about a week ago but I noticed that Sven hasn't posted on that list since Oct 2009 when he released the current version of OpenGLRaw. None of the public darcs repos have patches newer than Oct 2009. Also, the homepage url listed in the packages is a 404: http://www.haskell.org/HOpenGL/ My concern is that Sven has disappeared for some reason. I hope he's well. He has always done top notch work in the past maintaining these libraries. Perhaps he's simply busy or lost interest? Does anyone know if he was looking for a new maintainer? Perhaps you've heard from him more recently than Oct 2009? If a new maintainer is needed, I would consider nominating myself :) Thanks, Jason [1] http://hackage.haskell.org/package/OpenGLRaw [2] http://hackage.haskell.org/package/OpenGL [3] http://hackage.haskell.org/package/GLURaw [4] http://hackage.haskell.org/package/GLUT

6 15

MTL Upgrade Problem
by Dominic Steinitz 17 Apr '11

17 Apr '11

Hi, I have > dom1@fourier:~/asn1_0> ghc-pkg list --user > /home/dom1/.ghc/i386-linux-6.12.1/package.conf.d > mtl-1.1.0.2 > mtl-2.0.1.0 > But I get the following error: > [4 of 6] Compiling LatticeMod ( LatticeMod.hs, interpreted ) > [5 of 6] Compiling ConstraintGeneration ( ConstraintGeneration.lhs, > interpreted ) > > ConstraintGeneration.lhs:781:6: > Overlapping instances for Monad (Either String) > arising from a use of `return' > at ConstraintGeneration.lhs:(781,6)-(782,69) > Matching instances: > instance (Error e) => Monad (Either e) > -- Defined in Control.Monad.Trans.Error > instance (mtl-1.1.0.2:Control.Monad.Error.Class.Error e) => > Monad (Either e) > -- Defined in mtl-1.1.0.2:Control.Monad.Error > In the expression: > return > (ExtensibleConstraint > (ResStringConstraint v top) (ResStringConstraint top top) b) > In the definition of `pvPermittedAlphabetElements': > pvPermittedAlphabetElements (S (SV v)) b > = return > (ExtensibleConstraint > (ResStringConstraint v top) > (ResStringConstraint top top) > b) > Failed, modules loaded: ASNTYPE, LatticeMod, > Language.ASN1.PER.Integer, Language.ASN1.PER.IntegerAux. If I do > dom1@fourier:~/asn1_0> ghc-pkg hide mtl-2.0.1.0 Then the error goes away. But if I do > ghc-pkg hide mtl-1.1.0.2 Then I still get the error. Is there a wiki page that tells me what to do to upgrade from mtl-1 to mtl-2? Or perhaps someone can tell me what to do? Many thanks, Dominic.

2 2