- Libraries - Haskell.org

Re: Proposal: System.Timeout module for base (Trac #980)
by Andriy Palamarchuk 10 Mar '07

10 Mar '07

The documentation for the module is excellent. Could you add a few-lines example for an intended usage? Examples greatly shorten in a few ways time needed to start using some API. First, they are complementary explanation to other information. Second, someone can just copy an example to start playing with it. Another thing - in the header comments you mentioned that the module is "non-portable". Could you add an explanation why the module is non-portable? Thanks, Andriy ____________________________________________________________________________________ Yahoo! Music Unlimited Access over 1 million songs. http://music.yahoo.com/unlimited

4 9

Applicative ((,) a)
by Conal Elliott 10 Mar '07

10 Mar '07

What was the motivation for providing the following Applicative instance? instance Monoid a => Applicative ((,) a) where pure x = (mempty, x) (u, f) <*> (v, x) = (u `mappend` v, f x) Is this instance described in "Applicative Programming with Effects<http://www.soi.city.ac.uk/%7Eross/papers/Applicative.html>"? I didn't spot a mention. Thanks, - Conal

2 1

OpenGL and GLUT packages on Windows cause undefeined reference problem if build theirs myself
by shelarcy 09 Mar '07

09 Mar '07

Hello all, I tried to build OpenGL and GLUT packages on Windows by myself. Then runhaskell Setup.hs build cause below problem. $ runhaskell Setup.hs build Reading parameters from c:\home\ghc-6.7.20070305\libraries\GLUT\GLUT.buildinfo Preprocessing library GLUT-2.1... Building GLUT-2.1... (snip) c:\home\ghc-6.7.20070305\ghc-6.7.20070305\bin\ar.exe q dist\build\libHSGLUT-2.1.a dist\build\Graphics\UI\GLUT.o d (snip) dist\build\Graphics\UI\GLUT\Callbacks\Registration_stub.o Warning: resolving _hs_GLUT_getProcAddress@4 by linking to _hs_GLUT_getProcAddress Use --enable-stdcall-fixup to disable these warnings Use --disable-stdcall-fixup to disable these fixups This problem is already noticed by Pepe Gallardo. http://www.haskell.org/pipermail/hopengl/2006-December/000680.html And same problem cause if build GHC head snapshot myself, too. C:\home\ghc-6.7.20070305\libraries\GLUT\examples\OrangeBook\ogl2brick>C:\home\gh c-6.7.20070305\ghc-6.7.20070305\bin\ghc.exe --make Brick.hs [1 of 1] Compiling Main ( Brick.hs, Brick.o ) Linking Brick.exe ... C:/home/ghc-6.7.20070305/ghc-6.7.20070305/libHSGLUT.a(Extensions__3.o)(.text+0x1 4):fake: undefined reference to `hs_GLUT_getProcAddress@4' C:/home/ghc-6.7.20070305/ghc-6.7.20070305/libHSOpenGL.a(Extensions__3.o)(.text+0 x14):fake: undefined reference to `hs_OpenGL_getProcAddress@4' collect2: ld returned 1 exit status This problem doesn't occure Sigbjorn Finne's build snapshot ... http://www.haskell.org/ghc/dist/current/dist/ http://www.haskell.org/pipermail/cvs-ghc/2007-March/034396.html I don't know why .. but I know why reference is unresolved. CALLCONV is defined stdcall on Windows, but hs_**_getProcAddress (and other cbits's c functions) are build with ccall convention. Attached are darcs patch to fix these problem. But ... I don't know this patch doesn't cause any ptoblem Sigbjorn's next binary release. Because I don't know why OpenGL and GLUT can build correctly under his environment. Best Regars, -- shelarcy <shelarcy capella.freemail.ne.jp> http://page.freett.com/shelarcy/

1 0

IO () as Monoid
by Conal Elliott 09 Mar '07

09 Mar '07

Is there a Monoid instance defined for IO () anywhere? I'm using the following, instance Monoid (IO ()) where { mempty = pure mempty; mappend = (*>) } This definition follows a general form mentioned in http://haskell.org/haskellwiki/TypeComposition, instance (Applicative f, Monoid a) => Monoid (f a) where mempty = pure mempty mappend = (*>) without the conflicts (overlapping instances) introduced by this definition. - Conal

1 0

EnumSet and EnumMap
by Chris Kuklewicz 09 Mar '07

09 Mar '07

I could not quickly find anyone else writing this boiler plate, so I have posted this useful wrapper on the Haskell wiki at http://haskell.org/haskellwiki/EnumSet_EnumMap This uses a cheap newtype to wrap IntSet and IntMap so that you can store any Enum in them. It saves either writing many toEnum/fromEnum functions or using the slower and more generic Data.Set and Data.Map. The original motivation was to go from Map Char to IntMap. And as a bonus, the type signature of the newtype is the same kind as Data.Set and Data.Map (which matters when declaring instances...) > newtype EnumSet e = EnumSet {unEnumSet :: S.IntSet} > deriving (Monoid,Eq,Read,Show,Ord) > newtype EnumMap k a = EnumMap {unEnumMap :: M.IntMap a} > deriving (Eq,Read,Show,Ord,Monoid,Foldable,Functor) This has been quickly tested with GHC 6.6 and may contain typographical errors I have not caught yet. -- Chris

3 6

Re: [Haskell-cafe] TVars & throw
by Chris Kuklewicz 08 Mar '07

08 Mar '07

Thomas Conway wrote: > On 3/8/07, Chris Kuklewicz <haskell(a)list.mightyreason.com> wrote: >> http://haskell.org/haskellwiki/New_monads/MonadAdvSTM > > Ah. Yes, I've independently discovered an equivalent technique. I'm > building external btree/hash table code, and need to handle the case > where you go to use a node that hasn't been paged in. My solution was > simply to throw an exception, catch it, do the IO, then rerun the > transaction. Which sounds *almost* equivalent. My onRetry is different in that it lets one create a sequence of actions that are contingent on retrying the whole transaction. If the transaction commits then these actions are not performed; the actions queued by onCommit will be performed instead. What happens in your throw/catch case if I have stm1 = do some_stm_code_that_throws_your_exception stm2 = return Foo and I run "atomically (stm1 `orElse` stm2)" ? Answer: The exception will prevent running stm2. So I think a mixture of the two would be interesting. Perhaps I will add a "forceRetry" command to the MonadAdvSTM code that uses such an exception to prevent any orElse code from running. > Um, is > unsafeIOToSTM $ atomically trans > going to run you into problems? YES! My code does not use "unsafeIOToSTM $ atomically" nor does it use "unsafePerformIO $ atomically". Both of those will kill the runtime system and thus the whole program. That fatal error is why there is the "*IO" functions like "newTVarIO" were added. My code uses "unsafeIOToSTM $ (IO code using MVar)" which is safe. -- Chris

1 0

ANN: IPv6 support for network
by Bryan O'Sullivan 08 Mar '07

08 Mar '07

I've added enough IPv6 support to the network package that I can run the attached test program successfully, in the following manner: $ runghc NetTest.hs fec0::1:215:c5ff:fee2:451a HTTP/1.1 200 OK Date: Thu, 08 Mar 2007 07:56:20 GMT Server: Apache/2.2.3 (Fedora) [...etc...] The changes required were very minor: Network.BSD: New getAddrInfo and getNameInfo functions logically replace getHostByName and getHostByAddr, respectively. Network.Socket: The SockAddr ADT has acquired a new, um, whatever it is that ADTs acquire (a branch? a case?), called SockAddrInet6. Functions that work with SockAddrs are now SockAddrInet6-savvy. Network.Socket: New typeclass, HostAddr, allows definition of inet_ntop over HostAddress and HostAddress6 types. Documentation isn't yet 100% complete, but it should be pretty clear what's going on. I've bumped the library version in the .cabal file, just to make sure people don't confuse it with the regular network library. To fetch: darcs get --partial http://darcs.serpentine.com/network6 Please take a look and let me know if you have any comments. If things look sane, I'll do the remaining doco and formally submit my changes. <b

2 1

Re: Proposal: Add First and Last wrappers around Maybe to Data.Monoid
by Jeffrey Yasskin 08 Mar '07

08 Mar '07

On 3/4/07, David Menendez <zednenem(a)psualum.com> wrote: > Jeffrey Yasskin writes: > > > I've created http://hackage.haskell.org/trac/ghc/ticket/1189 to > > suggest adding two Monoid instances around Maybe that, instead of > > accumulating things like most monoids, just pick the first or last > > piece of data they see. > > Rather than have two wrappers, I say make the a Monoid instance for > Maybe using a left-biased choice (like the MonadPlus instance). > > Then we would get right-biased choice for free with the Dual wrapper. That's a reasonable idea, but I chose against it in the proposal because it arbitrarily picks one of the two sensible monoids for Maybe, which I'm worried will confuse users, especially since Haddock doesn't currently provide documentation for instances. Also, (getDual . foldMap (Dual . f)) is less readable than (getLast . foldMap (Last . f)). On the other hand, maybe the usual case is to just want any result, rather than specifically the left-most or right-most one, in which case providing the instance for Maybe directly saves typing. Thanks for the comment, Jeffrey

5 5

ANN: New release of regex packages
by Chris Kuklewicz 08 Mar '07

08 Mar '07

I would like to announce new versions of the regex-* packages. This announcement covers: Version Package Description 0.83 regex-base -- Type Classes and generic instances 0.90 regex-compat -- Uses regex-posix to provide old API 0.91 regex-dfa -- backend, pure haskell, no submatch capture 0.90 regex-parsec -- backend, pure haskell 0.91 regex-pcre -- backend, links against libpcre 0.91 regex-posix -- backend, links against standard c library 0.92 regex-tdfa -- backend, pure haskell (Posix semantics) 0.91 regex-tre -- backend, links against libtre (currently buggy) These all compile, install, and run a few test correctly. Most notably, I consider regex-tdfa to be of useful quality now. Summary of changes and recommendations: * all packages: ** import Text.Regex.XXX exposes (getVersion_Text_Regex_XXX :: Data.Version) which allows programs to access the current version number of the package ** LICENSE file provided (all are 3 clause BSD except regex-dfa is LGPL) * regex-base: ** BUGFIX: one of the RegexContext instances used tail unsafely ** RegexMaker now has makeRegexM and makeRegexOptsM for better error handling ** Extract has new instances for (Seq Char) and (ByteString.Lazy), as well as the previous [Char] and ByteString instances * all backends: ** Now support [Char], (Seq Char), ByteString, and ByteString.Lazy ** CHANGE: The (=~~) monadic match operators now use makeRegexM and will call 'fail' when a regular expression cannot be parsed. ** CHANGE: (import Text.Regex.BACKEND) now re-exports (module Text.Regex.Base) * regex-dfa: ** BUGFIX: No longer hangs on repeated nullable subpatterns * regex-tdfa: ** New backend in pure haskell that provides true Posix semantics ** Runs with excellent memory usage ** I recommend this backend for Posix extended regular expressions (leftmost longest). * regex-compat: No other changes, still uses regex-posix underneath, not recommended * regex-parsec: No other changes, I recommend regex-tdfa or regex-pcre instead * regex-pcre: No other changes, best provider of Perl's left-biased regular expressions * regex-posix: No other changes, very slow (on OS X the underlying C library is buggy) * regex-tre: No other changes, underlying libtre version 0.7.5 is still buggy Dependencies: All of the above packages have been updated to depend on regex-base>=0.80. I have only tested with GHC 6.6 on Mac OS X 10.4.8 (PPC, 32bit). Porting the backends to other Haskell compilers should be possible, though they may not support the polymorphic type class API that regex-base provides. Porting to GHC 6.4 should work once the support for (Seq Char) and ByteString[.Lazy] has been edited or externally obtained. I think only regex-tdfa actually uses bang patterns at the moment, and those could also be removed when porting. Where to get more information and the packages themselves: There is a slowly developing wiki page at http://haskell.org/haskellwiki/Regular_expressions for holding more documentation relating to these packages. I have uploaded tar.gz sources for each of the packages to hackage: http://hackage.haskell.org/packages/hackage.html They are listed under the "Text" Category: http://hackage.haskell.org/packages/archive/pkg-list.html#cat:Text Development and bug fixes continue in the darcs repositories under http://darcs.haskell.org/packages/regex-unstable/ To checkout one of the above versions with darcs you can use commands like darcs get --partial --tag=0.83 regex-base where the --tag=0.83 may be omitted to get the latest unstable version To install the packages once you have the source: For regex-pcre and regex-tre (and perhaps regex-posix) you might need to edit the end of cabal file to provide Include and Lib directories to the corresponding C library. # Compile Setup.hs for better startup speed ghc --make Setup.hs -o setup # I use my own path and "--user" .I recommend doing this to avoid overwriting # the global regex-* from GHC 6.6 ./setup configure --enable-library-profiling --prefix=YOUR_PATH --user ./setup build ./setup install Producing haddock documentation may not work and may not be up to date, with the important exception of regex-base. Future Plans: * regex-base: add support for generalized indices instead of the current Int * regex-tdfa: Improve DFA algorithm and further limit memory allocation. Try to improve performance of ByteString.Lazy matching. Cheers, Chris Kuklewicz

2 5

Want to poke at the network package a bit
by Bryan O'Sullivan 08 Mar '07

08 Mar '07

As part of a project I'm working on, I have a need to add some IPv6 support to the network library. I'd like to clean up the haddocks (or indeed write some in the first place) as I go. But before I start, I notice that the source has some peculiarities, such as explicit line number pragmas that are all wrong, making the process of finding errors unnecessarily interesting. Is there any reason I shouldn't nuke them as I go? <b

3 3