- Libraries - Haskell.org

Mail System Error - Returned Mail
by ross＠soi.city.ac.uk 06 Oct '04

06 Oct '04

The original message was included as attachment

1 0

Using Cabal for a simple wrapper library
by Einar Karttunen 06 Oct '04

06 Oct '04

Hello I am trying to use Cabal for a small library that essentially just wraps a C library. There seems to be no (documented) way of linking the produced library with an external library. Basically I have libfoo.so and libfoo.a, and would need the cabalized package to link to either of them. I am trying to use Distribution.Simple and my Setup.description looks like: Name: qdbm Version: 0.1 License: LGPL Copyright: (c) Einar Karttunen 2004 Stability: alpha Build-Depends: haskell-src Modules: Database.QDBM.Depot Maintainer: Einar Karttunen <ekarttun(a)cs.helsinki.fi> Extra-Libs: qdbm Extensions: ForeignFunctionInterface -- -fglasgow-exts is needed for data without a constructor -- -#include is a hack -- -cpp needs a better way of saying it -- And how should the library be linked really? Options-ghc: -cpp -fglasgow-exts -O2 -#include <depot.h> - Einar Karttunen

2 1

Re: [Debian-haskell] Bug#275071: ITP: hunit -- Haskell Unit Testing Framework
by Isaac Jones 06 Oct '04

06 Oct '04

(This is a followup to a request to package HUnit for the Debian GNU/Linux system) On Tue, 05 Oct 2004 13:16:03 -0500, John Goerzen <jgoerzen(a)complete.org> wrote: > Package: wnpp > Severity: wishlist > > * Package name : hunit Just a warning: there was talk of adding this to the standard Haskell libraries, which is why it hasn't been packaged yet. That said, people keep asking for it to be packaged, and I haven't checked lately to see if it has actually made it into the haskell standard libraries? BTW, It should be easy to generate the dh_make skeleton from the cabal debianTemplate. I'm ccing libraries(a)haskell.org about this. Malcolm Wallace originally requested that it be added. peace, isaac

3 2

RE: Network.CGI, POST and QUERY_STRING
by Simon Marlow 05 Oct '04

05 Oct '04

On 05 October 2004 13:09, Graham Klyne wrote: > I have the CVS access keys set up, but I've never actually got around > to checking them out, yet. If you're comfortable with this I'll plan > to update the CVS copy next week. Sure, go ahead. > BTW, You've probably noticed that I've also made extensive changes to > HaXml which I've been kind-of expecting Malcolm Wallace to pick up > and comment > upon. Judging by private messages I've received, the goal of the > changes (better entity support, Unicode support, namespace support) > are widely desired. > > Interested for GHC 6.4? This one's up to Malcolm as the maintainer of HaXml. If it turns out that for whatever reason Malcolm doesn't want to incorporate your changes into the base HaXml, then you can create a forked version - using Cabal this will be well supported, without the need to change the module names in your package. 6.4 will have better support for Cabal. Cheers, Simon

1 0

RE: Network.CGI, POST and QUERY_STRING
by Graham Klyne 05 Oct '04

05 Oct '04

At 12:37 05/10/04 +0100, Simon Marlow wrote: >On 04 October 2004 20:39, Graham Klyne wrote: > > > FWIW, Bjorn Bringert has improved and big-fixed Warrick Gray's HTTP in > > several ways, available from: > > > > http://www.dtek.chalmers.se/~d00bring/haskell-xml-rpc/http.html > > > > I've used this with greater success than I had with the original. > > > > Also, I've implemented an updated URI parser/processor, based on the > > new work-in-progress URI specification, which is available at: > > > > http://www.ninebynine.org/Software/Intro.html#HaskellURI > > http://www.ninebynine.org/Software/HaskellUtils/Network/ > > > > (The latter URI also contains a slightly modifed version of Bjorn's > > HTTP, that works with my URI module.) > > > > I am hoping/planning to contribute these to the Haskell common > > libraries, but have been waiting for (a) the new URI spec to be > > ratified, and (b) me having tome to make sure the small interface > > changes in my version of URI handling won't be too problematic for > > others. > >I'd like to get your revised URI library into GHC 6.4, which we plan to >release in roughly a month's time. This is the time to make possibly >breaking changes to library interfaces, which we only do for a new major >release - minor releases never change library APIs. > >So even if the URI spec isn't ratified yet, I think it might be prudent >to make the switch now. Dashing off a quick response before I go travelling for a few days... OK, the new spec is in (or very close to) last call, and any changes now are almost certain to be cosmetic. In any case, I'll commit to tracking any fixes to the spec without changing the interface. I have the CVS access keys set up, but I've never actually got around to checking them out, yet. If you're comfortable with this I'll plan to update the CVS copy next week. Meanwhile, the URI code can be examined at: http://www.ninebynine.org/Software/HaskellUtils/Network/ In particular: http://www.ninebynine.org/Software/HaskellUtils/Network/URI.hs http://www.ninebynine.org/Software/HaskellUtils/Network/URITest.hs (There are some other files there which use RDF to configure and run URI tests, but they're probably over-complicated for general library use.) ... BTW, You've probably noticed that I've also made extensive changes to HaXml which I've been kind-of expecting Malcolm Wallace to pick up and comment upon. Judging by private messages I've received, the goal of the changes (better entity support, Unicode support, namespace support) are widely desired. Interested for GHC 6.4? #g ------------ Graham Klyne For email: http://www.ninebynine.org/#Contact

1 0

RE: Network.CGI, POST and QUERY_STRING
by Simon Marlow 05 Oct '04

05 Oct '04

On 04 October 2004 20:39, Graham Klyne wrote: > FWIW, Bjorn Bringert has improved and big-fixed Warrick Gray's HTTP in > several ways, available from: > > http://www.dtek.chalmers.se/~d00bring/haskell-xml-rpc/http.html > > I've used this with greater success than I had with the original. > > Also, I've implemented an updated URI parser/processor, based on the > new work-in-progress URI specification, which is available at: > > http://www.ninebynine.org/Software/Intro.html#HaskellURI > http://www.ninebynine.org/Software/HaskellUtils/Network/ > > (The latter URI also contains a slightly modifed version of Bjorn's > HTTP, that works with my URI module.) > > I am hoping/planning to contribute these to the Haskell common > libraries, but have been waiting for (a) the new URI spec to be > ratified, and (b) me having tome to make sure the small interface > changes in my version of URI handling won't be too problematic for > others. I'd like to get your revised URI library into GHC 6.4, which we plan to release in roughly a month's time. This is the time to make possibly breaking changes to library interfaces, which we only do for a new major release - minor releases never change library APIs. So even if the URI spec isn't ratified yet, I think it might be prudent to make the switch now. Cheers, Simon

1 0

Network.CGI, POST and QUERY_STRING
by Philippa Cowderoy 04 Oct '04

04 Oct '04

Would it be possible to expose urlDecode from Network.CGI, or to automatically parse the query string in response to a POST rather than just parsing the data on stdin? -- flippa(a)flippac.org

3 5

RE: Data.HashTable and duplicate keys
by Simon Marlow 28 Sep '04

28 Sep '04

On 28 September 2004 12:49, George Russell wrote: > Einar wrote (snipped): > > I recently noticed that Data.HashTable silently > > accepts duplicate keys and keeps all the values. > > This is very counterintuitive from the interface > > and makes updating a hashtable quite tedious > > (lookup + delete + insert). > > Gosh, I'm glad *someone* told me of this bizarre behaviour. > Why on earth hash tables should mimic association lists of > all things is a mystery to me. (Should GHC also insert > delay loops to simulate their poor performance?) > > Sigh, off I go to fix my code. Just as well I only use > hash tables in one place. Making insert do delete+insert is pretty inefficient if you know that the key isn't in the table. Providing update (==delete+insert) seems a reasonable solution, no? Cheers, Simon

4 3

RE: Data.HashTable and duplicate keys
by Simon Marlow 28 Sep '04

28 Sep '04

On 28 September 2004 13:37, Marcin 'Qrczak' Kowalczyk wrote: > "Simon Marlow" <simonmar(a)microsoft.com> writes: > >> Making insert do delete+insert is pretty inefficient if you know that >> the key isn't in the table. Providing update (==delete+insert) >> seems a reasonable solution, no? > > This depends whether the implementation uses buckets for elements with > the same hash modulo size (like in OCaml), or stores elements directly > in the array, with some conflict resolution strategy (like in Python). > > I don't know which scheme is more efficient in general. Buckets are > easier to implement if deletion is to be supported, but a flat array > may have a faster optimistic case. Their memory overhead is similar > because a flat array can't be as dense as an array of buckets. The implementation uses buckets. I think buckets are also easier if the hash tables are variable in size (which ours are). I've now added update :: HashTable key val -> key -> val -> IO Bool to the interface, and improved the documentation. Cheers, Simon

1 0

Re: Data.HashTable and duplicate keys
by George Russell 28 Sep '04

28 Sep '04

Einar wrote (snipped): > I recently noticed that Data.HashTable silently > accepts duplicate keys and keeps all the values. > This is very counterintuitive from the interface > and makes updating a hashtable quite tedious > (lookup + delete + insert). Gosh, I'm glad *someone* told me of this bizarre behaviour. Why on earth hash tables should mimic association lists of all things is a mystery to me. (Should GHC also insert delay loops to simulate their poor performance?) Sigh, off I go to fix my code. Just as well I only use hash tables in one place.

1 0