September 2009 - Libraries

Haskell Platform package additions: decision time!
by Duncan Coutts 28 Sep '09

28 Sep '09

All, About a month ago we came up with a recommendation for a procedure for adding new packages to the Haskell Platform. Initial announcement: http://haskell.org/pipermail/libraries/2009-August/012397.html Proposed policy: http://trac.haskell.org/haskell-platform/wiki/AddingPackages If you like the video format then see 7min:15sec into this talk (from the recent Haskell implementers' workshop) http://www.vimeo.com/6572504 We would like to get this wrapped up so that we can move on to discussing more guidelines/requirements on packages and indeed to actually proposing some packages. So far we have had a few people send in comments (thanks particularly to Ian and Simon) but a few more would not go amiss, even if it's just "yes". If you were following the original thread you'll remember that Ian has a few concerns that we've not yet fully resolved. I have suggestions for how to move forward. Feedback and opinions from other people would probably help. I'll set out what the concerns are and what I suggest. Two of the complaints we can deal with fairly easily, the third would be a more radical change from what we're proposing, but we can move a bit closer. First the two simple ones: Concern 1: "The policy document itself is too long and too detailed." Quick poll: should we split the rationale into a separate page or keep it on the same page? Yes or no. * Advantages: policy document looks shorter, less intimidating * Disadvantages: slower to jump back and forth between the policy and the rationale (the two are fully cross-referenced) If we split it, then the main page would look like this: http://trac.haskell.org/haskell-platform/wiki/AddingPackagesCore and the "[rationale-x.y]" links would point to a separate page. It really doesn't matter which we pick, we just need to decide and get on with it! Concern 2: "Documentation written for the proposal will get lost." The concern here is that if people write some new intro tutorial or something for a package proposal that this might never get integrated into the package's documentation. Ian's suggested remedy is to force proposals to link to existing documentation rather than letting proposal authors make something new or make a customised variation on existing docs. The principle that the steering committee seemed to agree on is that the proposal author be given the freedom to present their argument in whatever way they see fit. The alternative that I am proposing is this: in the case that completely new documentation is written for a proposal, there be a presumption that a condition of acceptance is that the new material be republished in the appropriate place and form. For example this might mean the reviewers require that new intro docs be integrated into the haddock docs or perhaps as a separate tutorial or user guide on the package's homepage. The point is that by attaching it as a condition of the package being accepted, that we ensure that it does actually get done rather than nice docs languishing where no users will find them. The policy already has the facility for conditional acceptance so this just adds a presumed condition. Concern 3. The more major and general complaint Ian has is that he believes the criteria for acceptance should be essentially a checklist. Some checklist items would be objective, some subjective, but passing them all would be sufficient for a package to be accepted. With this approach the proposal would also essentially be a checklist, noting that each one is met (with explanation as appropriate). By contrast, the criteria that the steering committee proposes is that a package is accepted if the reviewers reach consensus. That is, ultimately it is up to the judgement of the reviewers. This approach is augmented with a list of minimum package requirements to make it clearer what level package authors have to aim for. In the limit the two approaches are the same. By adding more and more package requirements and guidelines the grey area left up to the judgement of reviewers is reduced. Also, the checklist approach allows some items to be essentially "do the reviewers agree that ...", so it's still a judgement and a consensus but broken up into categories. Related to this issue is the concern that we will find it impossible to agree on any packages before we have agreed a more comprehensive set of package requirements. My argument is that we can make progress on both simultaneously, that is we can start discussing individual package proposals while also discussing general package requirements. Indeed I think the two discussions might inform each other. In the worst case we get blocked discussing a package because we do not agree on the level of some quality requirement, in which case we move to discussing general package requirements and record the decision in the policy. So my suggestion on this complaint is that we go with the policy that the steering committee has proposed and that we move quickly afterwards to discuss more comprehensive package requirements and guidelines. Duncan

8 15

Proposal #3537: Add missing NFData instances to parallel
by Roel van Dijk 24 Sep '09

24 Sep '09

Control.Parallel.Strategies contains many NFData instances for types defined in base, but not all. I propose adding NFData instances for all types in base where it makes sense. The specific issue I had was with Data.Version. I wanted to 'rnf' some type which contained a Version, but it had no instance for NFData. The only solution is to add an instance in your own code, where it doesn't really belong. Therefor I checked the base package for other other types which also lacked an NFData instance. I would like some feedback on the instances for STRef and IORef. Does it make sense to have them? I used a trick to force their evaluation since their constructors are not exported. Discussion deadline: October 7 Ticket: http://hackage.haskell.org/trac/ghc/ticket/3537 Regards, Roel van Dijk

3 6

Windows Install Issues for erf (and statistics)
by Dominic Steinitz 23 Sep '09

23 Sep '09

The package statistics uses the package erf. Doing cabal install statistics works fine but when I try to use anything I get: > Loading package syb ... linking ... done. > Loading package base-3.0.3.0 ... linking ... done. > Loading package erf-1.0.0.0 ... linking ... <interactive>: > C:\Program Files\Haskell\erf-1.0.0.0\ghc-6.10.1\HSerf-1.0.0.0.o: unknown symbol > `_erfc' > : unable to load package `erf-1.0.0.0' I assume that erf is looking for some C functions which are available on linux but not windows. I'm not sure what the solution is. Should cabal complain? Should there be some documentation on the erf homepage telling windows users what to do? Or at least that it doesn't work on windows? Dominic.

4 8

Re: Windows Install Issues for erf (and statistics)
by Simon Marlow 23 Sep '09

23 Sep '09

On 23/09/2009 10:35, Dominic.Steinitz(a)barclayscapital.com wrote: > > >> -----Original Message----- >> From: Simon Marlow [mailto:marlowsd@gmail.com] >> Sent: 22 September 2009 13:44 >> To: Dominic Steinitz >> Cc: Lennart Augustsson; Steinitz, Dominic: Markets (LDN); > cabal-devel(a)haskell.org; libraries(a)haskell.org >> Subject: Re: Windows Install Issues for erf (and statistics) >> >> Are you sure the problem you had isn't just that the C erfc function > is not available on Windows? >> >> Oh, perhaps the problem that Lennart is referring to is that when GHCi > loads up a package it requires that all the symbols in> the package can > be resolved, whereas when you statically link a .a library we only have > to resolve the symbols required by the> library modules that the > program actually refers to. > > That may be it. If I use ghc all works: > > C:\p4wksp\steinitd_fpf_virgin_ws\FPF_Dev.br\src>ghc > -package-conf=..\ThirdParty\ghc\ghc-6.10.1\fpf.package.conf --make > Paths.hs -o Paths.exe > > C:\p4wksp\steinitd_fpf_virgin_ws\FPF_Dev.br\src>Paths.exe > [0.0,-0.3701728565440763,-0.43078071862053197,-1.2205246923473059,-1.294 > 0085383906827] > > But if I use ghci: > > Prelude> :l Paths.hs > [1 of 1] Compiling Main ( Paths.hs, interpreted ) > Ok, modules loaded: Main. > *Main> main > Loading package syb ... linking ... done. > Loading package base-3.0.3.0 ... linking ... done. > Loading package bytestring-0.9.1.4 ... linking ... done. > Loading package Win32-2.2.0.0 ... linking ... done. > Loading package old-locale-1.0.0.1 ... linking ... done. > Loading package time-1.1.2.2 ... linking ... done. > Loading package uvector-0.1.0.4 ... linking ... done. > Loading package erf-1.0.0.0 ... linking ...<interactive>: > C:/p4wksp/steinitd_fpf_virgin_ws/FPF_Dev.br/src/../thirdparty/haskell_pa > ckages\erf-1.0.0.0\ghc-6.10.1\HSerf-1.0.0.0.o: unknown symbol `_erfc' > : unable to load package `erf-1.0.0.0' > > >> So one workaround would be to link in a dummy erfc() function, or > alternatively hack the erf pacakge so that it omits the >> offending parts on Windows. > > I'll probably do the latter for the time being but is there something > that could be done to ghci to stop it complaining in the case of other > similar situations? It would mean doing some kind of lazy linking, and would be pretty tricky I think. In any case, it will only fail again when we start using shared libraries with GHCi, so I don't think it's worth tackling. (or maybe it will work with shared libraries; either way I don't think we should worry about doing anything in GHC's linker :-) Cheers, Simon

1 0

Fwd: Delivery Status Notification (Failure)
by Thomas DuBuisson 20 Sep '09

20 Sep '09

Ross, I'm sending this to you as the last uploader for hsc2hs. The .cabal needs some minor fixes and the maintainer e-mail seems broken. Should this be taken over by libraries(a)h.o? Thomas ---------- Forwarded message ---------- From: Mail Delivery Subsystem <mailer-daemon(a)googlemail.com> Date: Sat, Sep 19, 2009 at 1:32 PM Subject: Delivery Status Notification (Failure) To: thomas.dubuisson(a)gmail.com This is an automatically generated Delivery Status Notification Delivery to the following recipient failed permanently: cvs-fptools(a)haskell.org Technical details of permanent failure: Google tried to deliver your message, but it was rejected by the recipient domain. We recommend contacting the other email provider for further information about the cause of this error. The error that the other server returned was: 550 550 <cvs-fptools(a)haskell.org>: User unknown in local recipient table (state 14). ----- Original message ----- MIME-Version: 1.0 Received: by 10.220.89.158 with SMTP id e30mr3359450vcm.93.1253392364295; Sat, 19 Sep 2009 13:32:44 -0700 (PDT) Date: Sat, 19 Sep 2009 13:32:44 -0700 Message-ID: <4c44d90b0909191332k21fe4b02ic7554038c74acf77(a)mail.gmail.com> Subject: hsc2hs .cabal change needed From: Thomas DuBuisson <thomas.dubuisson(a)gmail.com> To: cvs-fptools(a)haskell.org Content-Type: text/plain; charset=ISO-8859-1 The hsc2hs package on hackage needs updated to include 'process' and 'directory' packages as deps. Thomas ----- End of message -----

2 1

[patch] #562: cabal-install update fails going through a HTTP proxy
by valery.vv＠gmail.com 19 Sep '09

19 Sep '09

Dear Cabal maintainers, A couple of days ago I was unable to cabal-install a library from Hackage -- 00-index.tar.gz was not downloaded completely. And if obtaining one with wget, other .tar.gz files (packages) still could not be fetched in full. This problem has been reported already (see http://hackage.haskell.org/trac/hackage/ticket/562) 06/11/09 09:49:25 changed by duncan: > Why has this started cropping up all of a sudden? Never seen this > before then 3 reports in as many days. Do we suspect HTTP-4000.0.6 -> > 7 perhaps? 06/11/09 13:02:47 changed by michaeldever: > So it's definitely a problem with the HTTP package in my opinion. I'm > not sure if it is a problem with the packages proxy handling, as it > does download some of the package, but not all of it. > > Seeing as both the Zlib library, and tar yield an end of stream error, > its something that I'm reckoning is happening during transport. 06/13/09 09:05:26 changed by michaeldever: > http://trac.haskell.org/http/ticket/8#comment:1 The bug is not in HTTP API, but in the way cabal-install uses it. The type of HTTP response body is polymorphic within `HTTP' library (rspBody :: Response a -> a) but it is specialized to Lazy.ByteString by cabal-install's `getHTTP' function (Distribution/Client/HttpUtils.hs). Once the type of response body is changed to _strict_ ByteString, files get downloaded through proxy completely. The attached module [proxy-POC.hs] makes this quite apparent (you need to be behind a proxy; HTTP >= 4000.0.8): vvv@takeshi:~/src$ time runhaskell proxy-POC.hs Content-Length: 1200593 bytes downloaded: 2408 proxy-POC.hs: user error (sizes differ) real 0m1.210s user 0m0.556s sys 0m0.052s vvv@takeshi:~/src$ time runhaskell -DSTRICT proxy-POC.hs Content-Length: 1200593 bytes downloaded: 1200593 real 0m17.956s user 0m0.620s sys 0m0.028s vvv@takeshi:~/src$ runhaskell proxy-POC.hs # repeatable Content-Length: 1200593 bytes downloaded: 2408 proxy-POC.hs: user error (sizes differ) There are only 4 lines that need to be changed (2 in HttpUtils.hs and 2 in Fetch.hs); see the accompanying patch. ...And could anyone explain me, why don't lazy ByteString cause cropped downloads in proxy-free environment? Thank you. -- vvv

3 2

Proposal: add new function "check" to Control.Monad
by Jon Fairbairn 19 Sep '09

19 Sep '09

Trac ticket #3453. Two week time frame. Add check function to Control.Monad check :: (MonadPlus m) => (a -> Bool) -> a -> m a check p a | p a = return a | otherwise = mzero Rationale: The example that suggested the function to me is this: readMaybe :: Read a => String -> Maybe a readMaybe = join . fmap no_trailing_garbage . listToMaybe . reads where no_trailing_garbage = fmap fst . check (all isSpace . snd) but check is clearly more generally useful than guard. (guard = flip (check . const) ()) Discussion: I also note in the comments to check that we can define List.filter like this filter = (concat .) . map . check Now, concat is just join specialised to lists, and map [is fmap, but...] is liftM, so we would expect a function mfilter = (join .) . liftM . check to be useful. Should that also be added? -- Jón Fairbairn Jon.Fairbairn(a)cl.cam.ac.uk

8 14

Re: [patch] #562: cabal-install update fails going through a HTTP proxy
by Valery V. Vorotyntsev 19 Sep '09

19 Sep '09

On Sat, Sep 19, 2009 at 3:17 AM, Duncan Coutts <duncan(a)haskell.org> wrote: > But that is exactly what makes me think it's a bug in the HTTP library. > The HTTP library provides instances for String, strict ByteString and > lazy ByteString. With one instance provided by the HTTP library your > test program fails and with the other it works. I see... > It not completely implausible that it could be the fault of the way we > use the HTTP library. For example if we were holding onto the lazy > ByteString for a long period without demanding all of it then perhaps > that could upset the network flow by causing timeouts or something, > however I don't think anything like that is going on here. The code > pretty swiftly takes the response and writes the content out to disk. > > As I mentioned in the Cabal ticket, I'd be very interested in hearing > Sigbjorn's diagnosis before considering whether we want to work around > the problem by switching to strict ByteString. If at all possible I > would prefer to stick to lazy ByteString. Okay, let's wait then. Thank you, Duncan. -- vvv

1 0

meaing of Cabal's extra-libraries field
by Ryan Wisnesky 15 Sep '09

15 Sep '09

Hello, I have a probably very dumb question about how to use Cabal - I'm just starting out with it. If this list isn't the right place to post the question, please let me know. It seems like when I add an Extra-libraries field to a cabal source package description: Name: LibraryFoo ... Library Extra-libraries: Bar this has the effect that when loading package LibraryFoo in ghci, ghci will necessarily try to open a corresponding Bar.so/.dll/.dylib file: > ghci -package LibraryFoo Loading package LibraryFoo-0.1 ... <command line>: can't load .so/.DLL for: Bar (dlopen(Bar.dylib, 10): image not found) What I want to do is statically link LibraryFoo against Bar before Cabal installs the package, (so that, for instance, I can run ghci without a bunch of command line linking arguments and don't need to have Bar around anymore), and I have a Bar.o file for just such a purpose. Is there a way to get Cabal to do this? Thanks for your help, Ryan Wisnesky

2 1

darcs patch: haskell-x11: export Cursor in Xlib.hs
by Andres Salomon 15 Sep '09

15 Sep '09

Tue Sep 15 12:23:18 EDT 2009 Andres Salomon <dilinger(a)collabora.co.uk> * haskell-x11: export Cursor in Xlib.hs Whoops, I forgot to export the cursors along w/ the rest of Xlib. New patches: [haskell-x11: export Cursor in Xlib.hs Andres Salomon <dilinger(a)collabora.co.uk>**20090915162318 Ignore-this: 77e1afa7994d1d0a3396dac2f7b37d27 Whoops, I forgot to export the cursors along w/ the rest of Xlib. ] { hunk ./Graphics/X11/Xlib.hs 40 module Graphics.X11.Xlib.Window, module Graphics.X11.Xlib.Context, module Graphics.X11.Xlib.Color, + module Graphics.X11.Xlib.Cursor, module Graphics.X11.Xlib.Font, module Graphics.X11.Xlib.Atom, module Graphics.X11.Xlib.Region, hunk ./Graphics/X11/Xlib.hs 57 import Graphics.X11.Xlib.Window import Graphics.X11.Xlib.Context import Graphics.X11.Xlib.Color +import Graphics.X11.Xlib.Cursor import Graphics.X11.Xlib.Font import Graphics.X11.Xlib.Atom import Graphics.X11.Xlib.Region } Context: [Some extra fields, bump the version. Don Stewart <dons(a)galois.com>**20090915161044] [haskell-x11: add and export the list of cursors Andres Salomon <dilinger(a)collabora.co.uk>**20090915155708 Ignore-this: 995cede8cdd8830a2c0bb6c63b8229b9 Pulled in from X11/cursorfont.h, export things like xC_X_cursor and xC_left_ptr for things like createFontCursor to use. ] [TAG 1.4.5 Spencer Janssen <spencerjanssen(a)gmail.com>**20081203050348 Ignore-this: d8112e4ff25ec56fe5ac2cdc9fa1ead ] [Bump version to 1.4.5 Spencer Janssen <spencerjanssen(a)gmail.com>**20081203050251 Ignore-this: 665f8093d82bef9e6b13bf1e4db74e1d ] [Bump configure.ac to 1.4.4 as well Spencer Janssen <spencerjanssen(a)gmail.com>**20081203050154 Ignore-this: ef3fabf26fc7dbfdb6dfaa92073e3c9e ] [Fix memory leak in getWMHints Spencer Janssen <spencerjanssen(a)gmail.com>**20081125221512 Ignore-this: dacc19acbb60e13d945509cde0551bc8 ] [more precise X11 deps Don Stewart <dons(a)galois.com>**20081011211930] [TAG 1.4.3 Spencer Janssen <spencerjanssen(a)gmail.com>**20080921082528] [Bump version to 1.4.3 Spencer Janssen <spencerjanssen(a)gmail.com>**20080921054954] [getCommand Marco Túlio Gontijo e Silva <marcot(a)riseup.net>**20080712154521] [X implementation dependent keysyms from X.org zythmer(a)gmail.com**20080528004224 Added all of the X keysyms from X.org except the groups XK_MISCELLANY and XK_LATIN1 as well as skipped XK_VoidSymbol since it is not in any group. The above groups and symbol are already in Graphics.X11.Types ] [Make sure both --with-xinerama and --without-xinerama works Lennart Kolmodin <kolmodin(a)gentoo.org>**20080524112224 Use the builtin variable with_xinerama instead of our want_xinerama. This gives us ability to use both --with-xinerama and --without-xinerama. ] [Use -auto-all when profiling Don Stewart <dons(a)galois.com>**20080413112039] [Update configure.ac with new version number Lennart Kolmodin <kolmodin(a)gentoo.org>**20080331184021] [Add setKeyEvent to Graphics.X11.Xlib.Extras Jérémy Bobbio <lunar(a)debian.org>**20080328214753] [TAG 1.4.2 Spencer Janssen <sjanssen(a)cse.unl.edu>**20080327193813] [Bump version number to 1.4.2 Spencer Janssen <sjanssen(a)cse.unl.edu>**20080327193755] [Handle a NULL retrun from XGetWMHints correctly, fixes a segfault bug Spencer Janssen <sjanssen(a)cse.unl.edu>**20080327192702] [update version info Don Stewart <dons(a)galois.com>**20080307190921] [comments Don Stewart <dons(a)galois.com>**20080307190910] [Remove -O2 from ghc-options Spencer Janssen <sjanssen(a)cse.unl.edu>**20071216001612] [TAG 1.4.1 Spencer Janssen <sjanssen(a)cse.unl.edu>**20071211042441] [Bump version to 1.4.1 Spencer Janssen <sjanssen(a)cse.unl.edu>**20071211042430] [Check the return value of XGetWindowProperty, this fixes crash bugs when the requested Window/Property does not exist Spencer Janssen <sjanssen(a)cse.unl.edu>**20071211041940] [Update installation instructions to use newer Cabal's --configure-option Alec Berryman <alec(a)thened.net>**20071120214634] [Remove obsolete INSTALL file; installation instructions are in README Alec Berryman <alec(a)thened.net>**20071120203353] [Remove redundant XIconifyWindow binding Spencer Janssen <sjanssen(a)cse.unl.edu>**20071208084849] [Added haddock docs to setErrorHandler; added XIconifyWindow and XMapRaised bindings hoelz(a)wisc.edu**20071202043806] [use a working header file for XSetErrorHandler Lukas Mai <l.mai(a)web.de>**20071129174529] [Implemented a full binding to XSetErrorHandler hoelz(a)wisc.edu**20071127011847] [TAG 1.4.0 Don Stewart <dons(a)galois.com>**20071125032528] [bump X11 version to 1.4.0 Don Stewart <dons(a)galois.com>**20071125032135] [add copyright info and year for Graphics/X11/Xlib/Extras.hsc Don Stewart <dons(a)galois.com>**20071121024752] [bump to snapshot tag Don Stewart <dons(a)galois.com>**20071111200531] [Fix bug in the type of functions dealing with properties Mats Jansborg <mats(a)jansb.org>**20071101190154 The documentation for XGetWindowProperty and XChangeProperty states that the data must be represented as an array of char, short and long for a format of 8, 16 and 32 respectively. Previously Word8, Word16 and Word32 were used, resulting in bugs on platforms where char is not 8 bits, short 16 bits and long 32 bits wide. ] [home instead of $USER Don Stewart <dons(a)galois.com>**20071101212016] [space in CPPFLAGS will break .buildinfo file Don Stewart <dons(a)galois.com>**20071031172720] [add CPPFLAGS and LDFLAGS to buildinfo file Don Stewart <dons(a)galois.com>**20071031172436] [formatting Don Stewart <dons(a)galois.com>**20071031171257] [license header for Xinerama Don Stewart <dons(a)galois.com>**20071031165900] [untabify Don Stewart <dons(a)galois.com>**20071031165743] [#!-able Setup.lhs Don Stewart <dons(a)galois.com>*-20071030173235] [bump version Don Stewart <dons(a)galois.com>**20071030213949] [Bump version number Ian Lynagh <igloo(a)earth.li>**20071027124814] [#!-able Setup.lhs Don Stewart <dons(a)galois.com>**20071030173235] [TAG X11-1.3.0 Don Stewart <dons(a)galois.com>**20071030172832] [wall police Don Stewart <dons(a)galois.com>**20071030171430] [cabal tweaks Don Stewart <dons(a)galois.com>**20071030171341] [wall police Don Stewart <dons(a)galois.com>**20071029205511] [Bug fix: not storing height in XSizeHints.resize_inc Don Stewart <dons(a)galois.com>**20071029202844] [-Wall police Don Stewart <dons(a)galois.com>**20071029202542] [clean up warnings Don Stewart <dons(a)galois.com>**20071029201214] [wrong header included, hidden by -fasm Don Stewart <dons(a)galois.com>**20071029184208] [no .lhs Setup script Don Stewart <dons(a)galois.com>**20071029183618] [Xutils.h -> Xutil.hs Don Stewart <dons(a)galois.com>**20071029183435] [more info in readme Don Stewart <dons(a)galois.com>**20071029182528] [more typos in the merged .cabal file Don Stewart <dons(a)galois.com>**20071029182349] [duplicate line in .cabal file Don Stewart <dons(a)galois.com>**20071029181942] [Merge in X11-extras package, bump to 1.3.0. Adds Xinerama and X event support. Don Stewart <dons(a)galois.com>**20071029175855] [TAG 1.2.3 Don Stewart <dons(a)galois.com>**20071012181748] Patch bundle hash: c591b42158e6bb75fd901ba0b250c12d49093b88

1 0