- Libraries - Haskell.org

Conditional compilation of Setup.hs
by Bayley, Alistair 31 Jul '07

31 Jul '07

I'd like to add a #ifdef to Takusen's Setup.hs, so that we can have a single source file that will compile with ghc-6.6 and ghc-6.6.1. With ghc-6.6 and Cabal-1.1.6.1 we use splitFileName and joinPaths from Distribution.Compat.FilePath. With ghc-6.6.1 (which includes Cabal-1.1.6.2) these have been moved to System.FilePath. I'd like to do something like the following: #ifdef __CABAL_VERSION__ > 117 import System.FilePath (splitFileName, combine) joinPaths = combine #else import Distribution.Compat.FilePath (splitFileName, joinPaths) #endif Is something like this possible with Cabal? It's either that, or make Takusen's install depend on filepath. I'm not sure which is the least desirable, but I'm open to suggestions. To be fair, we already require our ghc-6.6 users to upgrade Cabal from 1.1.6 to 1.1.6.1, so making them install filepath instead perhaps isn't so bad, and is no more effort. Alistair ***************************************************************** Confidentiality Note: The information contained in this message, and any attachments, may contain confidential and/or privileged material. It is intended solely for the person(s) or entity to which it is addressed. Any review, retransmission, dissemination, or taking of any action in reliance upon this information by persons or entities other than the intended recipient(s) is prohibited. If you received this in error, please contact the sender and delete the material from any computer. *****************************************************************

3 3

Proposal: Move System.Posix.Signals to the unix package
by Ian Lynagh 29 Jul '07

29 Jul '07

Hi all, Proposal: http://hackage.haskell.org/trac/ghc/ticket/1568 As suggested in http://hackage.haskell.org/trac/ghc/ticket/1190 I propose that the System.Posix.Signals module is moved to the UNIX package. Currently, on Windows, it is an empty module. Suggested deadline: 12 August 2007. Thanks Ian

1 0

Proposal: Move the throwErrnoPath* functions from unix:System.Posix.Error to base:Foreign.C.Error
by Ian Lynagh 29 Jul '07

29 Jul '07

Proposal: http://hackage.haskell.org/trac/ghc/ticket/1566 Currently, unix:System.Posix.Error has a number of throwErrnoPath* functions which are entirely portable, but they are not available on Windows due to being in the unix package. In the thread beginning http://www.haskell.org/pipermail/libraries/2007-July/007793.html Simon Marlow writes: When I needed to add some error-related functionality for the POSIX library, I didn't want to add extra stuff to Foreign.C.Error beyond what was specified in the FFI spec, so I added System.Posix.Error instead. This was just conservative; we could probably add throwErrnoPath and friends to Foreign.C.Error (with the usual proposal process). I propose that these functions are moved to base:Foreign.C.Error. They would still be re-exported by unix:System.Posix.Error to minimise breakage. Suggested deadline: Sun 12 August 2007. Thanks Ian

2 1

documentation in GHC.Conc, Control.Parallel.Strategies; querying number of CPUs
by Frederik Eaton 29 Jul '07

29 Jul '07

Hello, I am interested in implementing some multi-threaded algorithms in Haskell. I have run into some documentation dead-ends. The documentation in GHC.Conc is what I get when I search for "ghc pseq" on google, but it doesn't document pseq and some other functions: pseq par forkOnIO childHandler ensureIOManagerIsRunning In particular, I wonder: How is pseq different from seq? Under what circumstances is it used? I have looked at the source code so I see that it is implemented in terms of 'seq' and 'lazy': > -- "pseq" is defined a bit weirdly (see below) > -- > -- The reason for the strange "lazy" call is that > -- it fools the compiler into thinking that pseq and par are non-strict in > -- their second argument (even if it inlines pseq at the call site). > -- If it thinks pseq is strict in "y", then it often evaluates > -- "y" before "x", which is totally wrong. > > pseq :: a -> b -> b > pseq x y = x `seq` lazy y - does this mean pseq should be used instead of 'seq' when I want the first argument to be evaluated first? And I am also curious about the others, although par seems to be documented in Control.Parallel. Also, the following functions in Control.Parallel.Strategies are not documented, at least in Haddock: (>|) :: Done -> Done -> Done (>||) :: Done -> Done -> Done using :: a -> Strategy a -> a demanding :: a -> Done -> a sparking :: a -> Done -> a sPar :: a -> Strategy b sSeq :: a -> Strategy b r0 :: Strategy a rwhnf :: Strategy a rnf :: Strategy a ($|) :: (a -> b) -> Strategy a -> a -> b ($||) :: (a -> b) -> Strategy a -> a -> b (.|) :: (b -> c) -> Strategy b -> (a -> b) -> a -> c (.||) :: (b -> c) -> Strategy b -> (a -> b) -> a -> c (-|) :: (a -> b) -> Strategy b -> (b -> c) -> a -> c (-||) :: (a -> b) -> Strategy b -> (b -> c) -> a -> c seqPair :: Strategy a -> Strategy b -> Strategy (a, b) parPair :: Strategy a -> Strategy b -> Strategy (a, b) seqTriple :: Strategy a -> Strategy b -> Strategy c -> Strategy (a, b, c) parTriple :: Strategy a -> Strategy b -> Strategy c -> Strategy (a, b, c) fstPairFstList :: NFData a => Strategy [(a, b)] force :: NFData a => a -> a sforce :: NFData a => a -> b -> b The types Done and Strategy or the class NFData and related classes in this module are also not documented in Haddock. If there is a paper which defines all of these then it would be nice to have a link to the paper in the module's documentation, for people to use until the module's documentation itself can be updated. As an aside, if you've read this far then you may know the answer to a related question: is there a way to query how many processors the current machine has? I am implementing a parallel sort, and in cases such as sorting where one can decompose an algorithm into an arbitrarily large number of threads, I am wondering how to tell what the maximum useful number of threads is (usually this will be some increasing function of the number of CPUs) to avoid the overhead of spawning a thread when it is not needed. (I'm about to read "Lightweight concurrency primitives for GHC" by Li et al, if that's the right place to look) Thanks, Frederik -- http://ofb.net/~frederik/

7 9

ANNOUNCE: Gtk2Hs version 0.9.12 released
by Duncan Coutts 27 Jul '07

27 Jul '07

Gtk2Hs - A GUI Library for Haskell based on Gtk+ Version 0.9.12 is now available from: http://haskell.org/gtk2hs/download/ The source tarball and an installer for Windows are available. Packages for various platforms should become available soon, hopefully including Debian, Fedora, Gentoo, FreeBSD and Darwin. Changes since 0.9.11: * ps, pdf and svg cairo backends are now supported * drag & drop support added * can run mainGUI in GHCi after :reload * Graphics.SOE.Gtk now works with threaded rts and GHCi * Windows build now includes OpenGL and SourceView packages * c2hs no longer chokes on some system headers (eg glibc-2.4) * various bug fixes and minor code cleanups * major overhaul of the code generator (will help binding Gtk+ 2.10) Gtk2Hs feature highlights: * automatic memory management * Unicode support * nearly full coverage of Gtk+ 2.8 API * support for several additional Gtk+/Gnome modules: * Glade visual GUI builder * cairo vector graphics library * SVG rendering for cairo * OpenGL extension (works with HOpenGL) * GConf, Gnome's system for storing app preferences * SourceView, code editor widget with syntax highlighting * the Mozilla browser rendering engine in a widget * an implementation of the Graphics.SOE API * extensive haddock API reference documentation * multi-platform support with native look * LGPL licence Platforms and requirements: * builds from source on Linux, Windows, MacOS X, FreeBSD and Solaris * builds with GHC 6.2 - 6.6.1 * works with Gtk+ version 2.0 through to 2.10 * SVG support requires librsvg version 2.16 or later Please report all problems to gtk2hs-devel(a)sourceforge.net Contributions and feedback are also most welcome. Windows release notes: The installer expects GHC 6.6.1. As always if you need a build for a different version of GHC then that's possible by building from source. The windows build now includes the gtkglext and sourceview packages, but not svgcairo as that has pretty heavy dependencies. This makes the download a bit bigger, but on the other hand currently it includes support for only one GHC version, so overall the installer is rather smaller than in the last release. Duncan (on behalf of the Gtk2Hs team)

1 0

Why is System.Posix.Error in unix?
by Ian Lynagh 24 Jul '07

24 Jul '07

Hi all, I get the feeling I must be missing something, but why is System.Posix.Error in the unix package? It looks to me like it just calls things in the base package, and it works on Windows as far as I can see: $ ghci System/Posix/Error.hs [...] Loading package base ... linking ... done. [1 of 1] Compiling System.Posix.Error ( System/Posix/Error.hs, interpreted ) Ok, modules loaded: System.Posix.Error. *System.Posix.Error> throwErrnoPath "foo" "bar" *** Exception: bar: foo: failed (No error) *System.Posix.Error> Is there a reason not to move this, perhaps renaming it in the process, to the base package (or possibly elsewhere in the future, but in the short term I might want to use it in base)? Thanks Ian

4 5

Overflow in Ratio
by David Benbennick 22 Jul '07

22 Jul '07

The Ratio data type suffers from numeric overflow. For example, consider the Ord declaration in the Haskell 98 Report (I'm looking at page 153, section 12.1 of http://haskell.org/definition/haskell98-report.pdf) (x:%y) <= (x':%y') = x * y' <= x' * y It is easy to see that Ratio Int is not well-ordered under this definition, because of overflow. This is a self-contradiction in the Report, since page 84 (section 6.3.2) says that "The Ord class is used for totally ordered datatypes". I think the best way to resolve this contradiction is to avoid overflow. For example, the following definition works: (x:%y) <= (x':%y') = (toInteger x) * (toInteger y') <= (toInteger x') * (toInteger y) I submitted a complete patch at http://hackage.haskell.org/trac/ghc/ticket/1517, but that was apparently the wrong place, since the bug was closed as wontfix. Is there a chance of getting this contradiction resolved? I'll be happy to provide unit tests for the change if that will help get it applied.

3 4

Typeable<n> classes
by Matthew Pocock 21 Jul '07

21 Jul '07

Hi, I've been trying to use `deriving (Typeable, Data)' on some datatypes with arity 8 and 15, but GHC has been complaining. There aren't any Typeable<n> classes defined in Data.Typeable that go beyond 7. Is there a reason for this particular limit? If not, could it be extended further e.g. to 15? Is this likely to let GHC derive Typeable instances for my data types? Thanks, Matthew

2 1

Re: Data.Map.updateAt problem
by Andriy Palamarchuk 21 Jul '07

21 Jul '07

Bertram, Christian, thank you for help. Can somebody apply the patch posted by Bertram in the previous message? Please let me know if it is better to submit a ticket for it. Here are the relevant changes: [fix Data.Map.updateAt Bertram Felgenhauer <int-e(a)gmx.de>**20070718150340 See http://haskell.org/pipermail/libraries/2007-July/007785.html for a piece of code triggering the bug. updateAt threw away parts of the tree making up the map. ] { hunk ./Data/Map.hs 526 - LT -> updateAt f i l - GT -> updateAt f (i-sizeL-1) r + LT -> balance kx x (updateAt f i l) r + GT -> balance kx x l (updateAt f (i-sizeL-1) r) } Andriy ____________________________________________________________________________________ Park yourself in front of a world of choices in alternative vehicles. Visit the Yahoo! Auto Green Center. http://autos.yahoo.com/green_center/

2 1

Proposal: expose the drive functions in the filepath package
by Ian Lynagh 19 Jul '07

19 Jul '07

Hi all, This is proposal 1535: http://hackage.haskell.org/trac/ghc/ticket/1535 This comes out of http://hackage.haskell.org/trac/ghc/ticket/1490 where, in createDirectoryIfMissing, we use stat to determine if a directory exists. (I don't think catching an exception is a possibility in this case, as mkdir returns EEXIST if "pathname already exists (not necessarily as a directory)", so we can't distinguish between the directory already existing and a file existing with the name that we want. Short of doing something ugly like trying to make (path ++ "/.") and seeing if we get ENOTDIR, anyway). The problem is that mingw's stat succeeds for C:\ and C:\foo but fails for C: and C:\foo\. The current code strips a trailing \ before calling stat, and thus fails if asked to create C:\ (which we always do if "make parents" is true, and of course this path could be given explicitly by a user). What we want is something like if isDrive x then addTrailingPathSeparator x else dropTrailingPathSeparator x except filepath currently doesn't export isDrive, for reasons I'm not entirely clear on. Thus I propose exposing the *Drive functions from the filepath package. The patch, attached to the bug, is rather trivial as the code is already written, tested etc, just not exposed. Let's try until 21 July for a discussion period. Please try to accompany any objections with a (clean) alternative solution to the original problem. Thanks Ian

4 8