March 2006 - Libraries

Capturing facility of OpenAL binding
by Dmitry V'yal 17 Mar '06

17 Mar '06

Hello. I am going to play with sound processing using Haskell. I need to capture sound in my program somehow. According to it's documentation, OpenAL supports sound capturing. So I decided to use Haskell binding to it. http://haskell.org/ghc/docs/latest/html/libraries/ doesn't mention OpenAL. I managed to find API where: http://www.haskell.org/HOpenGL/newAPI/OpenAL/Sound-OpenAL-ALC-Capture.html But it's half complete compared to http://openal.org/openal_webstf/specs/OpenAL1-1Spec_html/AL11Spec6.html Then I looked through ghc-6.4.1 library sources and didn't find ghc-6.4.1/libraries/OpenAL/Sound/OpenAL/ALC/Capture.hs at all. But it must be where according to online docs. So the question is whether OpenAL binding supports capturing or not and is it planned to add it in the latter case? Thanks in advance.

2 1

Re: 6.4.2 release plans
by shelarcy 17 Mar '06

17 Mar '06

On Thu, 16 Mar 2006 01:54:03 +0900, Duncan Coutts <duncan.coutts(a)worc.ox.ac.uk> wrote: > We have 2 patches. One to fix compilation of OpenAL: > http://haskell.org/~gentoo/gentoo-haskell/portage/dev-lang/ghc/files/ghc-6.… > (I know this is fixed in darcs, I've not checked cvs ghc-6.4-branch) OpenAL's configure.ac uses different form that is compared by OpenGL and GLUT, and also darcs repositories ALUT. So now version - both cvs ghc-6.4-branch and darcs - can't build on Mac OS X platform. And cvs ghc-6.4-branch's OpenAL has also some problems, so can't build under Windows platform, either. http://www.haskell.org//pipermail/libraries/2005-September/004399.html I think best solution is: 1. to change darcs repository OpenAL's configure.ac form that is same as ALUT, OpenGL and GLUT. 2. then, to merge darcs repository's OpenAL. -- shelarcy <shelarcy capella.freemail.ne.jp> http://page.freett.com/shelarcy/

1 1

cabal-setup
by Simon Marlow 15 Mar '06

15 Mar '06

Following discussions a while back: http://www.haskell.org//pipermail/libraries/2006-January/004815.html there was some concensus (although not unanimous) that Cabal's user interface should be a wrapper program that runs Setup.hs. I've implemented a first cut at this, see the attached Cabal patch. It addresses this ticket: http://hackage.haskell.org/trac/hackage/ticket/63 I'm sending it here rather than committing directly, because I imagine there will be some discussion about whether this is the right thing. I'm pretty convinced this is the right way to go: it solves the Cabal versioning problem, and it frees the programmer from having to write a boilerplate Setup.hs file. It's a step on the way to supporting building of multiple packages. Look at the patch, tell me what you think. You'll need a completely up-to-date Cabal from darcs to build it. Cheers, Simon

5 4

Network.CGI
by Sebastian Sylvan 15 Mar '06

15 Mar '06

Hello. Sending values (over GET or POST) to a CGI-script does not work in IE if the value contains the character '@'. Sending it a string "hello@world" will return just "hello" in the key-value pair list that you get from the wrapper. Is there a reason for this? It looks like IE isn't encoding the strings (while firefox is), but should we require that it does? Couldn't we just change 'extra' to: extra :: Parser Char extra = sat (`elem` "!*'(),@") -- note the added '@' That would fix it, right? /S -- Sebastian Sylvan +46(0)736-818655 UIN: 44640862

1 0

RFC: Time Library 0.3
by Ashley Yakeley 14 Mar '06

14 Mar '06

Please take a look at my third draft of a replacement for the standard time library. http://semantic.org/TimeLib/ Take a look at the Haddock documentation: http://semantic.org/TimeLib/doc/html/ Download the source: http://semantic.org/TimeLib/TimeLib-0.3.tar.gz Or keep up-to-date: darcs get http://semantic.org/TimeLib/TimeLib/ It needs GHC 6.4.1. (I haven't tested with 6.4 or other compilers.) It consists of two separate Cabal packages, "fixed" and "time", which can be installed in the usual way. See the README file. This release should be close to being ready to become part of the libraries distributed with some future version of GHC. I'm interested in any remaining issues. Major changes since 0.2: * The code has been reorganised into two separate packages, "fixed", containing only Data.Fixed for fixed-point arithmetic, and "time", containing everything else. * The modules in "time" have been reorganised. The three "first level" modules, Data.Time.*, contain functionality that most ordinary users want. The "root" module, Data.Time simply re-exports these three. The "second level" modules, Data.Time.*.*, contain more specialised functionality. http://semantic.org/TimeLib/doc/html/ Some points (largely repeated from the 0.2 RFC): 1. There is no leap second table provided, though there is a type (LeapSecondTable) for such things. Any software compiled with a fixed table would soon become out of date. 2. There is no table of time-zones provided, since these also change. However, if there's a good way of getting this from the TZ database on the machine, I'll add that. It is actually possible to get the local time-zone for any given time, indeed one of the test programs finds your local summertime transitions. The Timezone type includes name, minutes of offset, and a "summertime" flag. 3. The TimeLocale type comes from the already existing System.Locale. 4. The "fixed" package includes Data.Fixed which provides a fixed-point arithmetic type (wrapper around Integer). It allows dealing with seconds as a single thing, rather than as an integer/picoseconds pair. It should probably be merged into base. 5. I don't have any text-parsing functionality for times. This is a fair amount of work, so it would be good to know sensible requirements. 6. Time as measured by the CPU since system startup remains in System.CPUTime, which TimeLib does not intend to replace. -- Ashley Yakeley, Seattle WA

5 8

UArray
by Frederik Eaton 14 Mar '06

14 Mar '06

I was trying to track down the problem with this piece of code: instance (Elt k, IxB a, Eq a, Eq k) => Num (Vector k a) where (+) = vmap2 (+) (-) = vmap2 (-) (*) = vmap2 (*) negate = vmap negate signum = vmap signum abs = vmap abs fromInteger n = vconst $ fromInteger n Vector2.hs:246:0: Could not deduce (Eq (UArray a k)) from the context (Elt k, IxB a, Eq a, Eq k) arising from the superclasses of an instance declaration at Vector2.hs:246:0 Probable fix: add (Eq (UArray a k)) to the instance declaration superclass context or add an instance declaration for (Eq (UArray a k)) In the instance declaration for `Num (Vector k a)' So it appears that here is another barrier to using UArray polymorphically. Am I the first user of this interface? In Data/Array/Base.hs it says: eqUArray :: (IArray UArray e, Ix i, Eq e) => UArray i e -> UArray i e -> Bool eqUArray arr1@(UArray l1 u1 _) arr2@(UArray l2 u2 _) = if rangeSize (l1,u1) == 0 then rangeSize (l2,u2) == 0 else l1 == l2 && u1 == u2 && and [unsafeAt arr1 i == unsafeAt arr2 i | i <- [0 .. rangeSize (l1,u1) - 1]] ... instance Ix ix => Eq (UArray ix Bool) where (==) = eqUArray instance Ix ix => Eq (UArray ix Bool) where (==) = eqUArray instance Ix ix => Eq (UArray ix Char) where (==) = eqUArray instance Ix ix => Eq (UArray ix Int) where (==) = eqUArray instance Ix ix => Eq (UArray ix Word) where (==) = eqUArray ... etc. Why define separate instances when one could just define one equivalent one: instance (Ix ix, Eq e, IArray UArray e) => Eq (UArray ix e) (==) = eqUArray ??? The same question applies to the Ord instances in that file. I can give an answer *why not* do this: it makes UArray even more unusable. UArrays which are polymorphic in their element types cannot be compared. Here is another patch, please apply: --- /home/frederik/ghc-6.4/libraries/base/Data/Array/Unboxed.hs.old 2006-03-12 18:34:14.000000000 +0000 +++ /home/frederik/ghc-6.4/libraries/base/Data/Array/Unboxed.hs 2006-03-12 18:35:32.000000000 +0000 @@ -10,6 +10,9 @@ -- -- Unboxed immutable arrays. -- +-- Beware that these arrays are generally not usable polymorphically +-- because of problems with Eq and Ord instances. +-- ----------------------------------------------------------------------------- module Data.Array.Unboxed ( Confused, Frederik On Sun, Mar 12, 2006 at 02:58:42AM +0000, Frederik Eaton wrote: > I see. The solutions on that thread, i.e.: > > http://www.mail-archive.com/haskell%40haskell.org/msg17085.html > > would seem to require me to at least declare an instance of some > class, for every type that I want to support. So the short answer to > "I'm trying to figure out how to use STUArray. Is it possible to let > it be polymorphic?" appears to be "No". > > Perhaps some sort of warning in the documentation for STUArray is in > order, until Bulat's code can be incorporated? > > By the way, why make the distinction between unboxable types and > "other" types in the first place? E.g., just because I want something > to work quickly on "Int", doesn't mean that I don't want it to work at > all on "String". It seems that there could be a default "IArray UArray > e" instance which just implements a regular Array behind the scenes. > > Frederik > > On Fri, Mar 10, 2006 at 11:49:10PM +0100, Benjamin Franksen wrote: > > On Friday 10 March 2006 23:01, Frederik Eaton wrote: > > > I'm trying to figure out how to use STUArray. Is it possible to let > > > it be polymorphic? > > > > Hi Frederik > > > > I think this thread (and the one it referres to) provide a solution: > > > > http://www.mail-archive.com/haskell%40haskell.org/msg17081.html > > > > Ben > > -- > > There are three kinds of programmers: those who make off by one errors, > > and those who don't. > > _______________________________________________ > > Haskell-Cafe mailing list > > Haskell-Cafe(a)haskell.org > > http://www.haskell.org/mailman/listinfo/haskell-cafe > > > > -- > http://ofb.net/~frederik/ > -- http://ofb.net/~frederik/

4 4

registering packages in ghc using a directory of package files
by Duncan Coutts 13 Mar '06

13 Mar '06

All, Yet again I've got annoyed by the difficulties with the way ghc registers packages. It's hard to get right. This time I had someone testing hdbc-odbc for me on ppc64. He uninstalled ghc and reinstalled it (to pick up a fix I had made) then he found that building hdbc-odbc failed because the hdbc package was not registered. However portage (the Gentoo package management facility) knew that it was installed. Of course what happened is that when ghc was reinstalled all the ghc packages that were already installed were not re-registered. Actually that is my fault because our ghc ebuild is supposed to do this. (Technically to do this correctly we should re-register the packages in dependency order, but we don't and just use --force) The point is that there are several bits that the packaging system has to get right for this to all work. The majority of the code in our ghc-package.eclass is for dealing with this issue. If we could just have ghc use a directory of package files rather than registering via modifying one central file then this would all become much simpler and more robust. One concern is that it would remove a point where the package database can be checked for consistency. I don't think this is necessarily so. The place that this QA check is really important is when users are manually installing packages. If an package management system finds a QA problem at registration time then it's already an unrecoverable bug. So the ghc-pkg could continue to be used in the way it is now, it will do it's carious checks and then install a file into a global package.conf.d directory rather than modifying a global package.conf file. For distro packaging systems we could use "ghc-pkg --check" or something, and then the package system would take responsibility for actually installing the file (and removing it when the package is uninstalled/upgraded). I'm somewhat tempted to patch our current ghc to do this, it might be easier to get that working than to get our current hacks to work properly. Duncan

3 5

Re: New collections package ready (almost)
by Simon Marlow 13 Mar '06

13 Mar '06

Jean-Philippe Bernardy wrote: > I've set up the new collections package, and it compiles under ghc and > hugs. I don't know about nhc, because I've been unable to compile nhc. > (I've got a x86_64 system; I've tryied to compile under a chroot does > not work, and configure program baffles me.) The non-ghc version is > portable though, so it _should_ work under nhc alright. > > So, you can try to make "collections" a default package, so I can > start moving stuff out of "base" into it. Ok, I misunderstood what you were doing here. I thought you were simply packaging AVL trees, but you're actually including the generic collections framework. I'm not completely comfortable with shipping this framework with GHC at the moment, given the small amount of discussion it has received, and the volume of competition in this space. This isn't a criticism of the design at all (indeed, I haven't looked at it in detail). I'd much prefer to see this provided as a separate package for now. Of course if a concensus emerges that this collections framework is the right way to go, then we'll certainly include it - a collections framework is pretty basic functionality. Cheers, Simon

4 3

darcs patch: add Data.Set.notMember and Data.Map.notMember
by John Meacham 13 Mar '06

13 Mar '06

Thu Mar 9 11:18:06 PST 2006 John Meacham <john(a)repetae.net> * add Data.Set.notMember and Data.Map.notMember

10 13

Re: New collections package ready (almost)
by Jean-Philippe Bernardy 12 Mar '06

12 Mar '06

I've checked again and it looks like, with the CVS version of hugs, modules that are transitively used must be exposed. Did I miss some option in the cabal file? Cheers, JP. On 3/12/06, Jean-Philippe Bernardy <jeanphilippe.bernardy(a)gmail.com> wrote: > Hello Einar, > > I did some tests with a (probably bugged) version of cabal which > required the modules to be exposed, and this is a left-over. > > Thanks for the feedback :) > > Cheers, > JP. > > On 3/12/06, Einar Karttunen <ekarttun(a)cs.helsinki.fi> wrote: > > On 12.03 16:03, Jean-Philippe Bernardy wrote: > > > I've set up the new collections package, and it compiles under ghc and > > > hugs. I don't know about nhc, because I've been unable to compile nhc. > > > (I've got a x86_64 system; I've tryied to compile under a chroot does > > > not work, and configure program baffles me.) The non-ghc version is > > > portable though, so it _should_ work under nhc alright. > > > > Looked at the package briefly and it seems promising. Why are > > Data.Tree.AVL.Internals.* in exposed-modules and not hidden ones? > > Should the Data.Tree.AVL.Test.* be added at all to the library > > or just remain there for a Makefile test target? > > > > - Einar Karttunen > > >

1 0