- Haskell-Cafe - Haskell.org

(no subject)
by Marcus D. Gabriel 02 Aug '03

02 Aug '03

-- Marcus D. Gabriel, Ph.D. Email: mdg(a)wanadoo.fr 213 ter, rue de Mulhouse F68300 Saint Louis FRANCE

1 0

Re: a breaking monad (to haskell cafe)
by Iavor Diatchki 01 Aug '03

01 Aug '03

hi, Derek Elkins wrote: > Anyways, most of my uses of the Cont monad have been for my own personal > entertainment, and usually I break the abstraction (using > Control.Monad.Cont) to do the things I want. I don't know if I've ever > written something that's used callCC that I kept. except for entertainment purposes i feel pretty much the same way :-) i think that in probably 95% of the cases that arise there is a simpler monad that does the job (i.e. exceptions, backtracking, etc). of course it could be that we are simply not used to program using the callcc. bye iavor -- ================================================== | Iavor S. Diatchki, Ph.D. student | | Department of Computer Science and Engineering | | School of OGI at OHSU | | http://www.cse.ogi.edu/~diatchki | ==================================================

1 0

FTP, XMLRPC libraries?
by Bryn Keller 01 Aug '03

01 Aug '03

Hi folks, I'm looking for FTP (client) and XMLRPC (client) libraries for Haskell. Does anyone know of any, or do I need to roll my own? Thanks, Bryn

1 0

Exporting GHC functions.
by Thomas L. Bevan 31 Jul '03

31 Jul '03

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Here is a copy of all the files I am using to try to export a Haskell function. This compiles but produces a executable that simply hangs. Tom -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.2 (GNU/Linux) iD8DBQE/KUHbYha8TWXIQwoRAs8RAKCIFcnH9uuqfMpDYXA0gfFjBtMfEwCgjZeD 5dkfLbz/lz4btmsR9G4kL2A= =pCBN -----END PGP SIGNATURE-----

1 1

Linking to exported GHC functions.
by Thomas L. Bevan 31 Jul '03

31 Jul '03

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Could someone give me a command line example of how to link a C programme using functions exported via GHC FFI? I've compile C object files using an FFI function but can't for the life of me work out what arguments to pass to the compiler to make it link correctly. Thanks, Tom -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.2 (GNU/Linux) iD8DBQE/KTyZYha8TWXIQwoRAlAwAKDu/gh3/TVvrVo8Damrr5K8YvbGgACgsz17 2MZqp/GG0K51O+6Gn829I0A= =mIS3 -----END PGP SIGNATURE-----

1 0

RE: Ann: HAllInOne bug fix release
by Hal Daume 31 Jul '03

31 Jul '03

(cafe) This seems like a reasonable hypothesis. Is there a way to get GHC to keep trying, despite the enormity of the input file? Specifically, I expect it to do a better job of (a) inlining and (b) specialization. Is there a way to hint to it to try a bit harder? :) - Hal -- Hal Daume III | hdaume(a)isi.edu "Arrest this man, he talks in maths." | www.isi.edu/~hdaume > -----Original Message----- > From: Koen Claessen [mailto:koen@cs.chalmers.se] > Sent: Thursday, July 31, 2003 1:49 AM > To: Simon Peyton-Jones > Cc: Hal Daume; Wolfgang Jeltsch; The Haskell Mailing List > Subject: RE: Ann: HAllInOne bug fix release > > > Simon Peyton-Jones wrote: > > | I don't know why the all in one version might go > | slower though. > > How about some (artificial) cut-offs during optimization > phases? Optimizing a hugs module could lead to some kind of > combinatorial explosion (which gets cut off by the > optimizer) which does not happen when you have separate > modules? > > Just my 2 öre! > > /Koen > >

1 0

RE: Ann: HAllInOne bug fix release
by Hal Daume 31 Jul '03

31 Jul '03

(haskell-cafe now) Interesting. I've stripped them and they are exactly the same size. diff says they differ though. pre-stripping, the normal nhc (non ai1) is marginally larger (6.8m versus 7.0m). I'll try to measure memory usage if someone tells me how :) - Hal -- Hal Daume III | hdaume(a)isi.edu "Arrest this man, he talks in maths." | www.isi.edu/~hdaume > -----Original Message----- > From: haskell-admin(a)haskell.org > [mailto:haskell-admin@haskell.org] On Behalf Of John Meacham > Sent: Wednesday, July 30, 2003 5:22 PM > To: The Haskell Mailing List > Subject: Re: Ann: HAllInOne bug fix release > > > Another useful thing would be the striped binary sizes of the two > versions. I am curious how much AllInOneing affects the resultant > binary. Memory usage would also be interesting. > John > > On Wed, Jul 30, 2003 at 04:22:58PM -0700, Hal Daume wrote: > > Ah, apparently it is not (at least not the Cygwin version). > > > > I recompiled NHC with GHC -O2, both the separate > compilation version and > > the all-in-over version. Averaged over five runs, we see that the > > separate compilation version is actually *faster* than the > ai1 version: > > > > standard nhc compiled with ghc: > > > > real 0m27.167s > > user 0m9.991s > > sys 0m1.304s > > > > nhc all-in-one: > > > > real 0m31.411s > > user 0m10.007s > > sys 0m1.299s > > > > > > > > i am completely unable to explain this. someone want to > hazard a guess? > > > > - hal, who is a bit disappointed now :( > > > > -- > > Hal Daume III | hdaume(a)isi.edu > > "Arrest this man, he talks in maths." | > www.isi.edu/~hdaume > > > > > > > -----Original Message----- > > > From: haskell-admin(a)haskell.org > > > [mailto:haskell-admin@haskell.org] On Behalf Of Wolfgang Jeltsch > > > Sent: Wednesday, July 30, 2003 2:59 PM > > > To: The Haskell Mailing List > > > Subject: Re: Ann: HAllInOne bug fix release > > > > > > > > > On Wednesday, 2003-07-30, 23:36, CEST, Hal Daume III wrote: > > > > [...] > > > > > > > A few people have asked me for speed-up results from > > > All-In-One-ifying code, > > > > so here's a good one. We take two versions of NHC. One is > > > the original > > > > binary distribution and the other is the All-In-One-ified > > > version, compiled > > > > by GHC. > > > > > > Hi, > > > > > > is the original binary distribution compiled with GHC? If > > > not, the speed-up > > > may also be the result of using a different compiler (i.e., GHC). > > > > > > > [...] > > > > > > Wolfgang > > > > > > _______________________________________________ > > > Haskell mailing list > > > Haskell(a)haskell.org > > > http://www.haskell.org/mailman/listinfo/haskell > > > > > -- > > Haskell mailing list > > Haskell(a)haskell.org > > http://www.haskell.org/mailman/listinfo/haskell > > > > -- > -------------------------------------------------------------- > ------------- > John Meacham - California Institute of Technology, Alum. - > john(a)foo.net > -------------------------------------------------------------- > ------------- > _______________________________________________ > Haskell mailing list > Haskell(a)haskell.org > http://www.haskell.org/mailman/listinfo/haskell >

1 0

RE: Ann: HAllInOne bug fix release
by Hal Daume 31 Jul '03

31 Jul '03

(moved to haskell cafe -- hopefully the other threads will follow) > >I don't know why the all in one version might go slower though > > Virtual memory thrashing? (Hal did say something about > needing lots of RAM.) only to compile. i haven't measured, but the resulting executable shouldn't require any more memory. it only hits about 400mbs max, though, which won't swap on my machine. - hal

1 0

Re: Ann: HAllInOne bug fix release
by Malcolm Wallace 31 Jul '03

31 Jul '03

> Normal: > real 3m14.295s > user 3m9.879s > sys 0m2.143s > > All-In-One: > real 1m11.380s > user 0m10.102s > sys 0m1.711s > Something very odd is going on. GHC does not generate programs than run > 3x faster between GHC versions. This comparison is actually between an nhc98-built program (the first one) and a ghc-built program (the second one), showing that (in this specific case) nhc98 is generating code that is three times slower than that generated by ghc. In my experience, a speed difference of between 2x and 5x of the (unoptimised) generated code between the two compilers is fairly typical. The really odd thing is in the second set of figures. Unless there has been a cut-n-paste mistake, the user+system times do not add up even close to the wall-clock time, suggesting a much greater difference of 18x, which would start to worry me a little if it were true. However, Hal posted an updated set of figures comparing a program separately compiled with ghc to all-in-one compiled with ghc, and these figures seem to have a similar same user+system /= real discrepancy: > separately compiled with ghc: > real 0m27.167s > user 0m9.991s > sys 0m1.304s > all-in-one compiled with ghc: > real 0m31.411s > user 0m10.007s > sys 0m1.299s Is this some kind of known Cygwin timing problem? Do ghc executables fiddle with the internal timers at runtime? :-) Regards, Malcolm

1 0

CSV parser, quotes?
by Shawn P. Garbett 31 Jul '03

31 Jul '03

In attempting to improve the CSV parser based on comments, I have the following code that's attached. I'm having a heck of a time getting the double quotes = an escaped quote thing to work. There is some commented out code which was my last attempt. As it stands the code works, minus the escaped quotes. Remove the comments and it just hangs. module CSV (contents, csv) where import Parsec ---------------------------------------------------------------------- -- CSV Module ---------------------------------------------------------------------- -- Useful common parsers comma :: Parser Char comma = char ',' quote :: Parser Char quote = char '\"' -- How to handle these buggers.... --esc_quote :: Parser Char --esc_quote = do {char '\"'; char '\"';} --text :: Parser String --text = do {esc_quote; t<-text; return ('\"':t)} -- <|> do {c <- noneOf "\""; t<-text; return (c:t) } -- <|> return "" -- A cell can be a quoted value, a number or empty -- Quotes can be embedded by using double quotes "" cell :: Parser String cell = between quote quote (many (noneOf "\"")) -- quoted values --cell = between quote quote text -- quoted values <|> many1 (noneOf "\",\n") -- unquoted values <|> return "" -- give up, Empty cell -- Group of cells with a newline cells :: Parser [String] cells = do c <- sepBy cell comma newline return c -- Comma Separated Values, set of rows followed by eof csv :: Parser [[String]] csv = manyTill cells eof -- Useful For extracting comma delimited values of a cell contents :: Parser [String] contents = sepBy1 (many (noneOf ",")) comma

3 2