September 2009 - Libraries

Recommendation for the procedure to add platform packages
by Duncan Coutts 14 Sep '09

14 Sep '09

All, The Haskell Platform steering committee have been very busy over the past two weeks drafting, discussing and redrafting. The result is our recommendation to the libraries list for a procedure for adding new packages to the Haskell Platform. Before you all go off and read it, we'd like to say what feedback we are looking for and what the next steps will be. The document we've come up with describes the procedure but only some very basic quality requirements for packages. Our aim is to have the libraries list come to an agreement on the procedure first and then we can discuss codifying a more comprehensive set of package requirements and guidelines. The main document contains: * the procedure itself, which is relatively short * a rationale, cross-linked to the procedure * a procedure to help us make decisions http://trac.haskell.org/haskell-platform/wiki/AddingPackages There is an accompanying "how to" guide to help the people who will actually be making proposals: http://trac.haskell.org/haskell-platform/wiki/AddingPackages/HowTo There is also an example proposal: http://trac.haskell.org/haskell-platform/wiki/Proposals/example So please send in your comments and of course feel free to ask questions and seek clarifications. Our hope is that we'll be able to agree this procedure stuff relatively quickly and then move onto package quality issues and indeed to actually start proposing packages. Let me also say that I've been very pleased with how the steering committee has worked. People have put in a lot of effort. It took 2 weeks, nearly 60 emails and over 100 edits to the draft. We didn't always agree but we talked things through thoroughly and turned our early draft into something much better that we're all satisfied with. Duncan, on behalf of the rest of the steering committee: Iavor Diatchki, Isaac Dupree, Thomas Schilling, Johan Tibell and Adam Wick.

6 15

GHC bus error on Network.BSD.getHostByName
by Sebastiaan Visser 14 Sep '09

14 Sep '09

Hello all, Before I file a bug maybe someone might recognize the following error and knows if I should blame GHC or someone at Apple. When trying to use the Network.BSD.getHostByName function ghci exits with a bus error. The same thing happens with ghc --make and runghc. > > ghci > GHCi, version 6.10.4: http://www.haskell.org/ghc/ :? for help > Loading package ghc-prim ... linking ... done. > Loading package integer ... linking ... done. > Loading package base ... linking ... done. > Prelude> :m Network.BSD > Prelude Network.BSD> getHostByName "www.google.com" > Loading package syb ... linking ... done. > Loading package base-3.0.3.1 ... linking ... done. > Loading package parsec-2.1.0.1 ... linking ... done. > Loading package network-2.2.1.4 ... linking ... done. > zsh: bus error ghci I'm using a Mac running Snow Leopard and GHC 6.10.4 from the MacOSX platform installer together with network-2.2.1.4. Never had any problems with this function before my upgrade to Snow Leopard. All other GHC functionality seems to be ok. Should I file a bug or is this something already known? Thanks, -- Sebastiaan Visser

3 2

[lists@qseep.net: [Haskell-cafe] Unable to install Haskell Platform without readline]
by Don Stewart 12 Sep '09

12 Sep '09

----- Forwarded message from Lyle Kopnicky <lists(a)qseep.net> ----- Date: Fri, 11 Sep 2009 11:46:00 -0700 From: Lyle Kopnicky <lists(a)qseep.net> To: haskell-cafe(a)haskell.org Subject: [Haskell-cafe] Unable to install Haskell Platform without readline Hi folks, I just installed GHC 6.10.4 on Ubuntu 9.04 32-bit, and then tried to install the Haskell Platform from source. It built quite a bit of stuff, with many warnings but no errors, and then finally died with the error below. To install editline, I need cabal, which is of course why I installed the Platform. I read an earlier thread from May that said that editline came with GHC 6.10.2, so the Platform didn't work with 6.10.3, but was soon to be updated. Now the web site for the Platform says it comes with 6.10.4, so I assumed it should work with 6.10.4, but apparently it still has this problem of still missing editline. Am I doing something wrong? checking editline/readline.h usability... no checking editline/readline.h presence... no checking for editline/readline.h... no checking editline/editline.h usability... no checking editline/editline.h presence... no checking for editline/editline.h... no checking readline/readline.h usability... yes checking readline/readline.h presence... yes checking for readline/readline.h... yes checking for sign of read_history result on error... negative checking for rl_completion_matches... no checking for completion_matches... no configure: error: editline not found, so this package cannot be built See `config.log' for more details. Error: Configuring the editline-0.2.1.0 package failed make: *** [build.stamp] Error 2 - Lyle _______________________________________________ Haskell-Cafe mailing list Haskell-Cafe(a)haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe ----- End forwarded message -----

1 0

Data.IntMap: intersection function not sufficiently polymorphic
by Axel Simon 11 Sep '09

11 Sep '09

Hi, the function intersectionWith :: (a -> b -> a) -> IntMap a -> IntMap b -> IntMap a in Data.IntMap creates a map of elements that occur in both maps. This function can and should return a map of an arbitrary third type: intersectionWith :: (a -> b -> c) -> IntMap a -> IntMap b -> IntMap c This also applies to Data.IntMap.intersectionWithKey. Oddly enough, this is already fixed in Data.Map. Discussion period one week?! Cheers, Axel.

2 1

Potential Network SIG
by Thomas DuBuisson 11 Sep '09

11 Sep '09

Hello All, If you are CCed it's because you are listed as a maintainer of a network-* package that I consider related to the Haskell network library. I'm hoping to roll much of the functionality of network-{bytestring, multicast, fancy} etc into a single package that the community will agree on (namely, "network"). Johan suggested starting a SIG to hammer out a design for a new Network API seeing as the current API, a straight-forward Berkeley binding, doesn't seem to please anyone in a Haskell context. If you want to partake then this e-mail if your heads up. If there is some formal method of setting up a Haskell SIG then please let me know. My thoughts on some important parts are below - I'm sure not everyone will agree as these thoughts directly contradict some designs found in current libraries. 1) Separate low level functions / bindings from high level / productive code by placing each in different modules. The low level bindings should remain available for those cases we fail to have the needed functionality in our high level packages. That said, I'm hoping to cover more than the 80% of users with any new design. 2) Maintain type safety by using type classes for most things. Unlike Network.Fancy and Network.Socket (which have IPv4 and IPv6 as constructors of the same data type), I think we should allow for the possibility that some users of the library will be limited to just one IP version without resorting to partial functions. I suggest type classes to cover this aspect (class Address, class Port, etc). 3) Use Bytestrings (and have corrosponding .Lazy modules) for efficiency. As in network-bytestring, any new API should be performance concious enough to avoid String. 4) Support more features Features such as Multicast, Header inclusion (IP_HDRINCL), address binding, etc. IOW, most the IP_ and SO_ options of socket (7) and ip (7) man pages. It would be rather nice if we were able to expose these in a friendly way - but with our cross platform concerns that might not be a good idea (e.g. I'm not familiar with windows). 5) Separate IO-less data declarations from IO and any platform dependent code in different packages. I've already got some work in this area via network-data. Not claiming its current design will stand the test of time, its just an example of keeping the data structures separate from any IO operations that will need platform specific work. 6) Integrate with the rest of hackage. This means instance of PrettyClass, Parsec, and Binary. I noticed a number of parsing utilities for IP addresses - lots of duplicated effort here. I'm currently looking at how the network library is being used - particularly when Network.Socket is invoked. So I guess I'll go sort through some of the source code for scurry, happstack, and adhoc-network. Thomas

10 31

darcs patch: Fix unportable use of sleep(1)
by Matthias Kilian 08 Sep '09

08 Sep '09

Sat Aug 29 11:37:20 CEST 2009 Matthias Kilian <kili(a)outback.escape.de> * Fix unportable use of sleep(1) `sleep 1s' is probably a GNUism; `sleep 1' should do the same in a portable way.

2 1

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

06 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

Request to add isBinDigit to Data.Char
by John Lien 03 Sep '09

03 Sep '09

Add isBinDigit that returns true is char = 0 or char =1 so that binary digit chars are covered like hex,octal,decimal chars are.

1 0

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