- Libraries - Haskell.org

(no subject)
by Bjorn Bringert 22 May '06

22 May '06

I'm moving this thread over to the libraries list. For those new to the thread, it is about replacing the current Network.CGI module with the NewCGI library. On May 22, 2006, at 8:06 AM, Lemmih wrote: > On 5/22/06, Simon Marlow <simonmar(a)gmail.com> wrote: >> On 5/22/06, Lemmih <lemmih(a)gmail.com> wrote: >> >> > NewCGI already supports POST data. >> > http://www.cs.chalmers.se/~bringert/darcs/haskell-cgi/doc/ >> >> Slightly off-topic, but maybe NewCGI should take over as Network.CGI? >> The current implementation isn't maintained, AFAIK. > > I volunteer to do the actual bone work if consensus is reached. I'd also be happy to do whatever work is needed for this. I'm still actively maintaining NewCGI. Here is a list of current features: - Access to CGI parameters (e.g. form input) from both GET and POST requests. - Access to CGI environment variables. - Ability to set arbitrary response headers. - Support for HTTP cookies. - An efficient implementation of multipart/form-data using Data.ByteString. This allows for efficient handling of file uploads. - Wrapper functions for compatibility with the existing Network.CGI module. - A CGI monad transformer. - Basic exception handling and logging (these should be improved) - Low-level run functions that allow using NewCGI programs with protocols other than CGI, for example FastCGI (http:// www.cs.chalmers.se/~bringert/darcs/haskell-fastcgi/doc/) /Björn

1 1

Announce: HGAL 1.2
by Jean-Philippe Bernardy 21 May '06

21 May '06

Hello folks, This is an announcement for HGAL 1.2. http://users.skynet.be/jyp/HGAL/ HGAL (Haskell Graph Automorphism Library) is a haskell implementation of Brendan McKay's algorithm for graph canonic labeling and automorphism group. (aka Nauty) Here are the main improvements over the previous release: * The algorithm is now more completely implemented and therefore a lot faster; * The library is now a cabal package. I'm also proud to proclaim that zero bug has been reported in the 3 years of existence of the library. (That either being due to a high quality of the library or a low number of users -- I'm not sure :) Cheers, JP.

1 0

Types vs. Classes
by Ashley Yakeley 20 May '06

20 May '06

Occasionally in library proposals one comes across classes of this form: class Thingy a where foo :: a -> this bar :: a -> that spong :: a -> theotherthing Such classes can be replaced by data-types, which turn out to also be more general: data Thingy = MkThingy { foo :: this, bar :: that, spong :: theotherthing } My question: is there a reason not to use types? I'm particularly interested in two cases that I've come across, references and streams. Here's the class version: class (Monad m) => Ref m r | r -> m, m -> r where newRef :: a -> m (r a) readRef :: r a -> m a writeRef :: r a -> a -> m () class (Monad m) => Stream m h where vPutStrLn :: h -> String -> m () vGetContents :: h -> m String vIsEOF :: h -> m Bool vClose :: h -> m () -- etc. And here's the type version: data Ref m a = MkRef { readRef :: m a, writeRef :: a -> m () } class (Monad m) => HasRefs m where newRef :: a -> m (Ref m a) data Stream m = MkStream { vPutStrLn :: String -> m (), vGetContents :: m String, vIsEOF :: m Bool, vClose :: m (), -- etc. } Is there any reason not to prefer using types? -- Ashley Yakeley, Seattle WA WWEWDD? http://www.cs.utexas.edu/users/EWD/

3 2

Data.ByteString: copyCStringLen not in the IO monad
by Tomasz Zielonka 18 May '06

18 May '06

Hello! Why copyCStringLen :: CStringLen -> ByteString? It seems pretty dangerous, because at the time of forcing (copyCStringLen csLen), csLen may no longer be valid. I think it would be better if this and other similar functions returned their results in the IO monad. Best regards Tomasz

2 1

Revised Numeric Prelude
by Ashley Yakeley 16 May '06

16 May '06

Aaron Denney wrote (on the Haskell' list): > Meh. I'd really like a revised numeric prelude to be able to use MPTCs > with FDs. Do you have some ideas for this? There's no reason why such an effort shouldn't start right now; I daresay even if we used FDs while Haskell eventually goes with ATs it might still be useful. I know there's the Basic Algebra proposal, but there's probably been some other work done here. -- Ashley Yakeley, Seattle WA WWEWDD? http://www.cs.utexas.edu/users/EWD/

2 1

make Text.Printf extensible, more flexible
by John Meacham 16 May '06

16 May '06

I was wondering if we could make Text.Printf extensible to user defined types. as far as I can tell, all that is needed is to export PrintfArg so that users can define new instances. it would also be nice if UPrintf could be switched from the current union type to a higher order function, since the only thing UPrintf is used for is formating strings. I am thinking something like newtype UPrintf = UPrintf (UFmt -> ShowS) data Adjustment = LeftAdjust | ZeroPad data UFmt = UFmt { fmtAdjust :: Maybe Adjustment, fmtFieldWidth :: Maybe Int, fmtPrecision :: Maybe Int, fmtCharacter :: Char } so, a UPrintf is just a function that takes a parsed formating string and prints the appropriate string. John -- John Meacham - ⑆repetae.net⑆john⑈

2 1

ByteStrings and the ram barrier
by dons＠cse.unsw.edu.au 16 May '06

16 May '06

Hey libraries@, Data.ByteStrings are strict, unboxed arrays of Word8s. They're great for fast processing of strings that fit in memory but no good for lazy processing, or dealing with data larger than your ram (i.e. they're infeasible above 1G on a 2G ram box). Last week Duncan Coutts had the bright idea to write Data.ByteString.Lazy, a newtyped [ByteString], which would allow constant space processing of chunks of strict ByteString arrays. The theory is that we'd be able to efficiently process large data, where both ByteString and [Char] fails, and open a new range of applications that could be handled successfully with Haskell. By using list operations over the spine of the structure, and fast ByteString operations over the leaves, we should be able to get some of the benefits of both lazy lists and strict bytestrings. For example, to map over a lazy bytestring you do a list map along the spine of the list, and a bytestring map over the nodes: lazy bytestring map = L.map (B.map f) xs So we hacked away at it for a few days, and here are some preliminary results: Simple task, filter the letter 'e' from a file. ------------------------------------------------------------------------ 4G file, 1G ram, Linux/x86, 3.20GHz P4, GHC 6.4.1 Data.ByteString.Lazy (128k chunks) constant heap, total time 2m 20s, 25% cpu Data.List constant heap, total time 8 minutes (quite good!), 98% cpu sed 's/e//g' constant heap, I gave up after 10 minutes ------------------------------------------------------------------------ 10G file, 1G ram, OpenBSD/x86, 2.4GHz P4, GHC 6.4.1 Data.ByteString.Lazy (5M chunks) constant heap, total time 11.44 minutes, 34% cpu Data.List constant heap, total time 18.21 minutes, 90% cpu ------------------------------------------------------------------------ A nice improvement for Haskell on mutli-gigabyte files, I think! Data.ByteString.Lazy is in fps head, here: http://www.cse.unsw.edu.au/~dons/code/fps/Data/ByteString/Lazy.hs Cheers, Don

3 5

Library Tests Location?
by Ashley Yakeley 16 May '06

16 May '06

I wrote a bunch of unit tests for my time library. What should I do with the unit tests I wrote? Should I convert them to all.T etc. format and put them in the testsuite repo? Or should I leave them in the time repo? -- Ashley Yakeley, Seattle WA WWEWDD? http://www.cs.utexas.edu/users/EWD/

2 1

xml in fptools?
by Lemmih 15 May '06

15 May '06

On 5/15/06, Isaac Jones <ijones(a)syntaxpolice.org> wrote: > Lemmih <lemmih(a)gmail.com> writes: > > > On 5/15/06, Isaac Jones <ijones(a)syntaxpolice.org> wrote: > >> Greetings, > >> > >> I'm wondering if we've ever discussed putting an XML parser into > >> fptools. I'm asking because cabal-install would like to use xml-rpc, > >> but it drags in a bunch of dependencies that aren't in fptools. > >> > >> What do other languages do: > >> * Python seems to have XML and XML-RPC as standard libraries > >> * Same with ruby > >> * Not java (shocking): http://java.sun.com/j2se/1.3/docs/api/ > >> > >> I guess that HaXml probably can't get into fptools because of license > >> incompatibilities, but hxml and HXmlToolbox both have MIT licenses, > >> and so could probably be put into fptools: > >> > >> http://www.flightlab.com/~joe/hxml/ > >> http://www.fh-wedel.de/~si/HXmlToolbox/ > >> > >> What do others think? > > > > XML and xml-rpc are the wrong tools for cabal-install, IMO. Picking a > > tool that isn't suited for the task will not result in anything good, > > no matter how common and popular that tool happens to be. I only chose > > xml-rpc because it was easily available, and it resulted in several > > dirty hacks. Please, lets avoid enterprise, XML and managers in suits; > > The /right/ tools are out there. > > End of way too emotional rant. > > Care to elaborate with some facts or details that can help the rest of > us make a decision? Well, XML/xml-rpc isn't very well suited for transferring binary data and that's pretty much the only thing cabal-install is interested in. Using bencoding would be more efficient and not drag in any dependencies. BEncoding is used by bittorrent and, hence, is implemented in almost every language. -- Friendly, Lemmih

1 0

ByteStrings and the Terabyte barrier
by dons＠cse.unsw.edu.au 15 May '06

15 May '06

Just for fun, I was able to filter a 1 Terabyte stream through a Haskell program, using Data.ByteString.Lazy, with a constant 2M heapsize, in $ time ( repeat 100 ; cat /home/dons/data/10G | ./lazy > /dev/null ) 12752.37s user 4069.35s system 58% cpu 8:03:11.42 total 8 hours. Just so we can say it is possible :) -- Don

1 0