- Libraries - Haskell.org

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

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