[nightly] 10-Mar-2010 build of HEAD on x86_64-unknown-linux (cam-04-unx.europe.corp.microsoft.com)

2010-03-10 Thread GHC Build Reports
Build description = HEAD on x86_64-unknown-linux (cam-04-unx.europe.corp.microsoft.com) Build location= /64playpen/simonmar/nightly/HEAD-cam-04-unx Build config file = /home/simonmar/nightly/site/msrc/conf-HEAD-cam-04-unx Nightly build started on cam-04-unx at Wed Mar 10 19:00:01 GMT 2010. **

[nightly] 10-Mar-2010 build of STABLE on x86_64-unknown-linux (cam-04-unx.europe.corp.microsoft.com)

2010-03-10 Thread GHC Build Reports
Build description = STABLE on x86_64-unknown-linux (cam-04-unx.europe.corp.microsoft.com) Build location= /64playpen/simonmar/nightly/STABLE-cam-04-unx Build config file = /home/simonmar/nightly/site/msrc/conf-STABLE-cam-04-unx Nightly build started on cam-04-unx at Wed Mar 10 19:10:01 GMT 20

Re: Fast Haskell Parser

2010-03-10 Thread John D. Earle
Hi, Ben! Thanks for the input. I went to the Parsec and Attoparsec parser links. Attoparsec was new to me. From the Parsec link: Combinator parsers are written and used within the same programming language as the rest of the program. The parsers are first-class citizens of the language, unlike

GHC support has landed in LLVM!

2010-03-10 Thread David Terei
> r98212 | lattner | 2010-03-11 11:22:57 +1100 (Thu, 11 Mar 2010) > add support, testcases, and dox for the new GHC calling > convention. Patch by David Terei! The new calling convention in LLVM needed by GHC has just been committed! Unfortunately it missed the 2.7 window by about 2 days but

Re: Fast Haskell Parser

2010-03-10 Thread Ben Lippmeier
Hi John, Doing a Google search for "haskell parser" returns the following link as its first result. That's the parser that GHC uses. http://www.haskell.org/happy/ You could also check out the following: http://www.haskell.org/haskellwiki/Parsec http://hackage.haskell.org/package/attoparsec

Fast Haskell Parser

2010-03-10 Thread John D. Earle
I was thinking of ways to create an efficient Haskell parser. My initial thinking was to write a top down parser in Haskell, but if you want speed a table driven approach may make greater sense. Due to the existence of build bots there is a certain degree of compliancy concerning build times.

simonmar-win32-head, build 3

2010-03-10 Thread Builder
simonmar-win32-head, build 3 Build failed Details: http://darcs.haskell.org/ghcBuilder/builders/simonmar-win32-head/3.html darcs checkout | Success create mk/build.mk | Success get subrepos | Failure: 258 Build failed Details: http://darcs.haskell.org/ghcBuilder/builders/simonmar-win32