August 2009 - Libraries

Proposal #3456: Add FilePath -> String decoder
by Judah Jacobson 07 Sep '09

07 Sep '09

Currently, FilePaths on POSIX systems are represented as raw bytes in a String. When this last came up on the mailing list, the general consensus was to make FilePath an abstract datatype representing paths as Strings on Windows and raw bytes on POSIX systems. However, such a change is sure to break some existing code. As a small step towards that goal, I propose adding the following two functions to the System.IO module: filePathToString :: FilePath -> IO String getFilePathToStringFunc :: IO (FilePath -> String) I've implemented those functions in a patch attached to the trac ticket. Haddock docs are here: http://code.haskell.org/~judah/new-io-docs/System-IO.html#v%3AfilePathToStr… On POSIX those functions decode according to the current locale, so they ought to be in the IO monad. I think that the latter function will be easier to integrate into existing pure code. On Windows, those functions are just `return` and `return id`, respectively, since GHC already treats FilePaths as Strings on that platform. Discussion deadline: September 9 Ticket: http://hackage.haskell.org/trac/ghc/ticket/3456 Best, -Judah

6 7

darcs patch: Add justIf to Data.Maybe
by Joachim Breitner 03 Sep '09

03 Sep '09

Hi, I propose the attached change, with a discussion timeframe until end of September. The corresponding ticket is http://hackage.haskell.org/trac/ghc/ticket/3446 Thanks, Joachim Fri Aug 21 19:17:12 CEST 2009 Joachim Breitner <mail(a)joachim-breitner.de> * Add justIf to Data.Maybe

8 16

Binding to inline functions
by Maurício CA 01 Sep '09

01 Sep '09

I understand we can't use 'foreign import ccall' to wrap inline C functions. Do you think it could be possible to have an option in cabal to generate such functions in an object file when #included in a C file, in a compiler independent, portable way? Thanks, Maurício

4 8

ioToST
by Samuel Bronson 01 Sep '09

01 Sep '09

Dear libraries@..., Shouldn't Control.Monad.ST export ioToST :: IO a -> ST RealWorld a, as defined in GHC.IO? Hugs for some reason does not have it, but it would seem trivial to write, given their stToIO: stToIO :: ST RealWorld a -> IO a stToIO (ST f) = IO f It doesn't look like anyone else even *has* ST...

4 3

Proposal #3455: Add a setting to change how Unicode encoding errors are handled
by Judah Jacobson 01 Sep '09

01 Sep '09

I proposal that we augment ghc-6.12.1's support for Unicode Handles by adding the following functions to System.IO: hSetOnEncodingError :: Handle -> OnEncodingError -> IO () hGetOnEncodingError :: Handle -> IO OnEncodingError as well as the enumeration `OnEncodingError` with three constructors: - `ThrowEncodingError`: Throw an exception at the first encoding or decoding error. - `SkipEncodingError`: Skip all invalid bytes or characters. - `TranslitEncodingError`: Replace undecodable bytes with u+FFFD, and unencodable characters with '?'. I have implemented this functionality in a patch attached to the ticket. Haddock docs are here: http://code.haskell.org/~judah/new-io-docs/System-IO.html#23 The choice of error handler is orthogonal to the choice of encoder. Additionally, the same setting is used for both read and write modes. For portability, the handlers are written in pure Haskell rather than using GNU iconv's //TRANSLIT feature. Note that the text package, for example, provides more sophisticated error-handling options. However, I think the above choices are useful enough without making the API too complicated. Discussion deadline: September 9 Ticket: http://hackage.haskell.org/trac/ghc/ticket/3455 Best, -Judah

4 4

Fwd: How to change -optc-O2 when compiling C files
by Roel van Dijk 01 Sep '09

01 Sep '09

I sent this message to cabal-devel. After reading the cabal website more carefully I noticed I should sent questions here. Apologies for the noise in cabal-devel. Hello, I have cabal file which specifies some c-sources to compile together with the usual Haskell stuff. I noticed that cabal automatically passes -optc-O2 to GHC when compiling C files. If I specify some additional cc-options in my cabal file they just get prepended to the list of options passed to ghc. How do I get rid of the -optc-O2? With my current cc-options "-D_OPENMP -O3 -funroll-loops" GHC is invoked like this during a "cabal build": /usr/bin/ghc -Ilevmar-2.4 -package base-3.0.3.1 -optc-D_OPENMP -optc-O3 -optc-funroll-loops -optc-O2 -odir dist/build -c levmar-2.4/lm.c I don't know which -optc-O? will be picked by the C compiler. Normally -O2 is ok, but in this case I really want -O3. Thanks in advance, Roel van Dijk

1 0

Hackage rankings : August 2009
by Don Stewart 30 Aug '09

30 Aug '09

Monthly statistics on the most popular Haskell applications and libraries on Hackage. August 2009 edition now up: http://donsbot.wordpress.com/2009/08/29/haskell-popularity-rankings-septemb… -- Don

1 0

darcs patch: Allow for configurable iconv include and library locat...
by Matthias Kilian 27 Aug '09

27 Aug '09

Wed Aug 26 17:44:06 CEST 2009 Matthias Kilian <kili(a)outback.escape.de> * Allow for configurable iconv include and library locations. This should help to fix the build on OpenBSD.

2 1

darcs patch: Allow for configurable iconv include and library locat...
by Matthias Kilian 27 Aug '09

27 Aug '09

Wed Aug 26 17:44:06 CEST 2009 Matthias Kilian <kili(a)outback.escape.de> * Allow for configurable iconv include and library locations. This should help to fix the build on OpenBSD.

1 0

Cabal: literate hscolour
by Sean McLaughlin 25 Aug '09

25 Aug '09

Hello, I can't find a way to pass the -lit flag to hscoulour using neither my cabal configuration file nor a command line option to runhaskell Setup.hs haddock. I'd really like to not have my literate comments be colored according to Haskell lexical conventions. Is there a way to do this? Thanks! Sean

3 8