- Libraries - Haskell.org

Hackage timeout
by Don Stewart 05 Oct '09

05 Oct '09

Hey all, Hackage timed out for me today during an upload. Looks like the index didn't regenerate. I imagine this gets fixed on the next succesful upload. -- Don

2 1

darcs patch: haskell-x11: add and export the list of cursors
by Andres Salomon 02 Oct '09

02 Oct '09

Tue Sep 15 11:57:08 EDT 2009 Andres Salomon <dilinger(a)collabora.co.uk> * haskell-x11: add and export the list of cursors Pulled in from X11/cursorfont.h, export things like xC_X_cursor and xC_left_ptr for things like createFontCursor to use. New patches: [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. ] { addfile ./Graphics/X11/Xlib/Cursor.hsc hunk ./Graphics/X11/Xlib/Cursor.hsc 1 +----------------------------------------------------------------------------- +-- | +-- Module : Graphics.X11.Xlib.Cursor +-- Copyright : (C) Collabora Ltd 2009 +-- License : BSD-style (see the file libraries/base/LICENSE) +-- +-- Maintainer : libraries(a)haskell.org +-- Stability : provisional +-- Portability : portable +-- +-- A collection of cursor types defined by /usr/include/X11/cursorfont.h. +-- +----------------------------------------------------------------------------- + +module Graphics.X11.Xlib.Cursor( + + xC_X_cursor, + xC_arrow, + xC_based_arrow_down, + xC_based_arrow_up, + xC_boat, + xC_bogosity, + xC_bottom_left_corner, + xC_bottom_right_corner, + xC_bottom_side, + xC_bottom_tee, + xC_box_spiral, + xC_center_ptr, + xC_circle, + xC_clock, + xC_coffee_mug, + xC_cross, + xC_cross_reverse, + xC_crosshair, + xC_diamond_cross, + xC_dot, + xC_dotbox, + xC_double_arrow, + xC_draft_large, + xC_draft_small, + xC_draped_box, + xC_exchange, + xC_fleur, + xC_gobbler, + xC_gumby, + xC_hand1, + xC_hand2, + xC_heart, + xC_icon, + xC_iron_cross, + xC_left_ptr, + xC_left_side, + xC_left_tee, + xC_leftbutton, + xC_ll_angle, + xC_lr_angle, + xC_man, + xC_mouse, + xC_pencil, + xC_pirate, + xC_plus, + xC_question_arrow, + xC_right_ptr, + xC_right_side, + xC_right_tee, + xC_rightbutton, + xC_rtl_logo, + xC_sailboat, + xC_sb_down_arrow, + xC_sb_h_double_arrow, + xC_sb_left_arrow, + xC_sb_right_arrow, + xC_sb_up_arrow, + xC_sb_v_double_arrow, + xC_shuttle, + xC_sizing, + xC_spider, + xC_spraycan, + xC_star, + xC_target, + xC_tcross, + xC_top_left_arrow, + xC_top_left_corner, + xC_top_right_corner, + xC_top_side, + xC_top_tee, + xC_trek, + xC_ul_angle, + xC_umbrella, + xC_ur_angle, + xC_watch, + xC_xterm, + + ) where + +import Graphics.X11.Xlib.Font + +---------------------------------------------------------------- +-- Cursors +---------------------------------------------------------------- + +#include "HsXlib.h" + +xC_X_cursor :: Glyph +xC_X_cursor = #const XC_X_cursor + +xC_arrow :: Glyph +xC_arrow = #const XC_arrow + +xC_based_arrow_down :: Glyph +xC_based_arrow_down = #const XC_based_arrow_down + +xC_based_arrow_up :: Glyph +xC_based_arrow_up = #const XC_based_arrow_up + +xC_boat :: Glyph +xC_boat = #const XC_boat + +xC_bogosity :: Glyph +xC_bogosity = #const XC_bogosity + +xC_bottom_left_corner :: Glyph +xC_bottom_left_corner = #const XC_bottom_left_corner + +xC_bottom_right_corner :: Glyph +xC_bottom_right_corner = #const XC_bottom_right_corner + +xC_bottom_side :: Glyph +xC_bottom_side = #const XC_bottom_side + +xC_bottom_tee :: Glyph +xC_bottom_tee = #const XC_bottom_tee + +xC_box_spiral :: Glyph +xC_box_spiral = #const XC_box_spiral + +xC_center_ptr :: Glyph +xC_center_ptr = #const XC_center_ptr + +xC_circle :: Glyph +xC_circle = #const XC_circle + +xC_clock :: Glyph +xC_clock = #const XC_clock + +xC_coffee_mug :: Glyph +xC_coffee_mug = #const XC_coffee_mug + +xC_cross :: Glyph +xC_cross = #const XC_cross + +xC_cross_reverse :: Glyph +xC_cross_reverse = #const XC_cross_reverse + +xC_crosshair :: Glyph +xC_crosshair = #const XC_crosshair + +xC_diamond_cross :: Glyph +xC_diamond_cross = #const XC_diamond_cross + +xC_dot :: Glyph +xC_dot = #const XC_dot + +xC_dotbox :: Glyph +xC_dotbox = #const XC_dotbox + +xC_double_arrow :: Glyph +xC_double_arrow = #const XC_double_arrow + +xC_draft_large :: Glyph +xC_draft_large = #const XC_draft_large + +xC_draft_small :: Glyph +xC_draft_small = #const XC_draft_small + +xC_draped_box :: Glyph +xC_draped_box = #const XC_draped_box + +xC_exchange :: Glyph +xC_exchange = #const XC_exchange + +xC_fleur :: Glyph +xC_fleur = #const XC_fleur + +xC_gobbler :: Glyph +xC_gobbler = #const XC_gobbler + +xC_gumby :: Glyph +xC_gumby = #const XC_gumby + +xC_hand1 :: Glyph +xC_hand1 = #const XC_hand1 + +xC_hand2 :: Glyph +xC_hand2 = #const XC_hand2 + +xC_heart :: Glyph +xC_heart = #const XC_heart + +xC_icon :: Glyph +xC_icon = #const XC_icon + +xC_iron_cross :: Glyph +xC_iron_cross = #const XC_iron_cross + +xC_left_ptr :: Glyph +xC_left_ptr = #const XC_left_ptr + +xC_left_side :: Glyph +xC_left_side = #const XC_left_side + +xC_left_tee :: Glyph +xC_left_tee = #const XC_left_tee + +xC_leftbutton :: Glyph +xC_leftbutton = #const XC_leftbutton + +xC_ll_angle :: Glyph +xC_ll_angle = #const XC_ll_angle + +xC_lr_angle :: Glyph +xC_lr_angle = #const XC_lr_angle + +xC_man :: Glyph +xC_man = #const XC_man + +xC_middlebutton :: Glyph +xC_middlebutton = #const XC_middlebutton + +xC_mouse :: Glyph +xC_mouse = #const XC_mouse + +xC_pencil :: Glyph +xC_pencil = #const XC_pencil + +xC_pirate :: Glyph +xC_pirate = #const XC_pirate + +xC_plus :: Glyph +xC_plus = #const XC_plus + +xC_question_arrow :: Glyph +xC_question_arrow = #const XC_question_arrow + +xC_right_ptr :: Glyph +xC_right_ptr = #const XC_right_ptr + +xC_right_side :: Glyph +xC_right_side = #const XC_right_side + +xC_right_tee :: Glyph +xC_right_tee = #const XC_right_tee + +xC_rightbutton :: Glyph +xC_rightbutton = #const XC_rightbutton + +xC_rtl_logo :: Glyph +xC_rtl_logo = #const XC_rtl_logo + +xC_sailboat :: Glyph +xC_sailboat = #const XC_sailboat + +xC_sb_down_arrow :: Glyph +xC_sb_down_arrow = #const XC_sb_down_arrow + +xC_sb_h_double_arrow :: Glyph +xC_sb_h_double_arrow = #const XC_sb_h_double_arrow + +xC_sb_left_arrow :: Glyph +xC_sb_left_arrow = #const XC_sb_left_arrow + +xC_sb_right_arrow :: Glyph +xC_sb_right_arrow = #const XC_sb_right_arrow + +xC_sb_up_arrow :: Glyph +xC_sb_up_arrow = #const XC_sb_up_arrow + +xC_sb_v_double_arrow :: Glyph +xC_sb_v_double_arrow = #const XC_sb_v_double_arrow + +xC_shuttle :: Glyph +xC_shuttle = #const XC_shuttle + +xC_sizing :: Glyph +xC_sizing = #const XC_sizing + +xC_spider :: Glyph +xC_spider = #const XC_spider + +xC_spraycan :: Glyph +xC_spraycan = #const XC_spraycan + +xC_star :: Glyph +xC_star = #const XC_star + +xC_target :: Glyph +xC_target = #const XC_target + +xC_tcross :: Glyph +xC_tcross = #const XC_tcross + +xC_top_left_arrow :: Glyph +xC_top_left_arrow = #const XC_top_left_arrow + +xC_top_left_corner :: Glyph +xC_top_left_corner = #const XC_top_left_corner + +xC_top_right_corner :: Glyph +xC_top_right_corner = #const XC_top_right_corner + +xC_top_side :: Glyph +xC_top_side = #const XC_top_side + +xC_top_tee :: Glyph +xC_top_tee = #const XC_top_tee + +xC_trek :: Glyph +xC_trek = #const XC_trek + +xC_ul_angle :: Glyph +xC_ul_angle = #const XC_ul_angle + +xC_umbrella :: Glyph +xC_umbrella = #const XC_umbrella + +xC_ur_angle :: Glyph +xC_ur_angle = #const XC_ur_angle + +xC_watch :: Glyph +xC_watch = #const XC_watch + +xC_xterm :: Glyph +xC_xterm = #const XC_xterm + +---------------------------------------------------------------- +-- End +---------------------------------------------------------------- hunk ./Makefile.nhc98 12 Graphics/X11/Xlib/Atom.hsc \ Graphics/X11/Xlib/Color.hs \ Graphics/X11/Xlib/Context.hs \ + Graphics/X11/Xlib/Cursor.hsc \ Graphics/X11/Xlib/Display.hs \ Graphics/X11/Xlib/Event.hsc \ Graphics/X11/Xlib/Font.hsc \ hunk ./X11.cabal 31 Graphics.X11.Xlib.Atom, Graphics.X11.Xlib.Color, Graphics.X11.Xlib.Context, + Graphics.X11.Xlib.Cursor, Graphics.X11.Xlib.Display, Graphics.X11.Xlib.Event, Graphics.X11.Xlib.Font, hunk ./configure.ac 118 if ! test "$have_keysymdef" = yes; then echo "WARNING: Couldn't find <X11/keysymdef.h> for X.org keysyms" fi + + AC_CHECK_HEADERS([X11/cursorfont.h], [have_cursorfont=yes]) + if ! test "$have_cursorfont" = yes; then + AC_MSG_ERROR([X11/cursorfont.h (from libx11) is required]) + fi fi hunk ./include/HsXlib.h 40 #define XK_LATIN1 #include <X11/keysymdef.h> +#include <X11/cursorfont.h> + /* This error handler is used from FFI code. * It generates a slightly better error message than the one * that comes with Xlib. } Context: [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: c2047a1dad296b9bf634a852c71d6e5002226576

3 2

Proposal (Trac ticket #3524): Add mfilter to Control.Monad
by Jon Fairbairn 01 Oct '09

01 Oct '09

Following on from the discussion of #3453, I propose the addition of mfilter to Control.Monad. It's just List.filter for any MonadPlus. I'd rather that we didn't have List.filter, and called this filter, but (a) I can't see that happening and (b) the naming scheme for Control.Monad is quite explicit. Time limit for discussion: 1 October. -- Jón Fairbairn Jon.Fairbairn(a)cl.cam.ac.uk

1 1

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