- web-devel - Haskell.org

Question about the composing order of conduit combination operations
by Hiromi ISHII 05 Apr '12

05 Apr '12

Hi, I'm implementing a tiny SMTP server using conduit-0.4.0 and network-conduit-0.4.0. I wrote code like below: > smtpServer src sink = do > LC.sourceList [ renderReply $ SMTPReply 220 (Just "localhost") ["hello"]] $$ sink > src $$ C.sequence (sinkParser smtpCommand) > =$ LC.map (BS.pack . show) > =$ sink Here is the complete (and slightly different) code: https://github.com/konn/haskell-smtp/blob/master/smtp-server/Network/SMTP/S… (You know, this server is not actually an smtp server; just echoing client's input for now.) I ran this program and communicated using telnet. I expected the access log like below (S means server, C means client; new-lines are CRLF) : > S: 220 localhost hello > C: EHLO another.example.com > S: EHLO "another.example.com" > C: MAIL FROM:<Postmaster(a)example.com> > S: MAIL (Path [] (Mailbox {mbLocalPart = "Postmaster", mbDomain = "example.com"})) [] > C: RCPT TO:<foo(a)example.com> > S: RCPT (Path [] (Mailbox {mbLocalPart = "foo", mbDomain = "example.com"})) [] > C: DATA > C: hoge > C: fuga > C: oooo > C: . > S: DATA "hoge\r\nfuga\r\noooo" > C: QUIT > S: QUIT But I got: > S: 220 localhost hello > C: EHLO another.example.com > C: MAIL FROM:<Postmaster(a)example.com> > C: RCPT TO:<foo(a)example.com> > S: EHLO "another.example.com" > C: DATA > S: MAIL (Path [] (Mailbox {mbLocalPart = "Postmaster", mbDomain = "example.com"})) [] > C: hoge > C: fuga > C: oooo > C: . > C: QUIT > S: RCPT (Path [] (Mailbox {mbLocalPart = "foo", mbDomain = "example.com"})) [] It seems that conduit produces a new SMTPCommand after reading another new command, and processes and convert it into SMTPReply much father later. By the way, I rewrote the program above just like below and everythings seems to be good: > smtpServer src sink = do > LC.sourceList [ renderReply $ SMTPReply 220 (Just "localhost") ["hello"]] $$ sink > src $= C.sequence (sinkParser smtpCommand) > $= LC.map (BS.pack . show) > $$ sink If Conduits, Sinks and Sources are the same sings in conduit-0.4, why these two codes above behaves differently? To summarize, my questions are divided into three: 1. Why the first one doesn't work as I expected? 2. Why the second one works well? 3. Is this difference intended? If so, what are the difference of semantics of ($=), (=$), ($$), (=$=) and their composition? -- Hiromi ISHII konn.jinro(a)gmail.com

2 1

Yesod 1.0 Release Candidate
by Michael Snoyman 05 Apr '12

05 Apr '12

Hi everyone, I'd like to announce the availability of the Yesod 1.0 release candidate. The code is available on Hackage now, so you should be able to install with a simple `cabal update && cabal install yesod` to get up-and-running. If you've been installing from Github or Yackage, you'll probably have the smoothest ride by wiping out your ~/.ghc and ~/.cabal/packages/cabal-src folders, and disabling Yackage as a remote repo in ~/.cabal/config. We're setting a release date of next Monday, April 9. That's when we'll be posting an official release announcement and releasing a new version of yesod-platform. At this point, the code is well tested and usable (in fact, it *is* in production use on multiple sites), but we wanted to give everyone one last chance to hammer away at the code. One of the goals with this release is to try to start pushing Haskell and Yesod to the masses (i.e., we're going to fail to avoid success at all costs). We're going to be trying to demonstrate the advantages Haskell provides over other solutions out there. I think this is the kind of effort that we can all work on together as a community. If anyone's interested in helping out with promoting, please be in touch. Michael

1 0

wai and conduit 0.4 for proxy
by Kazu Yamamoto 03 Apr '12

03 Apr '12

Hello, I'm trying to catch up conduit 0.4. To pass requestBody of Request to ResponseSource of Response, we need to convert types as follows: Source (ResourceT IO) ByteString -> Source (ResourceT IO) (Flush Builder) The way which I could find is: src $= CL.map (Chunk . byteStringToBuilder) Is this a right way? Or, is there another proper way? Cheers, --Kazu

2 2

ANN: acme-http
by Jeremy Shaw 01 Apr '12

01 Apr '12

Hello, As we all know, the true measure of performance for a web server is the classic PONG test. And, so the Happstack team is pleased to announce the release of the new acme-http server! hackage: http://hackage.haskell.org/package/acme-http source: http://patch-tag.com/r/stepcut/acme-http When testing on my laptop with +RTS -N4 using the classic PONG test: $ httperf --hog -v --server 127.0.0.1 --port 8000 --uri / --num-conns=1000 --num-calls=1000 --burst-length=20 --rate=1000 acme-http delivered 221,693.0 req/s, making it the fastest Haskell web server on the planet. By comparison, warp delivered 51,346.6 req/s on this machine. The secret to acme-http's success is that it large avoids doing anything not required to win the PONG benchmark. It does not support timeouts, it does not check quotas, it assumes the client is HTTP 1.1, it does not catch exceptions, and it responds to every single request with PONG. The goal of acme-http is two fold: 1. determine the upper-bound on Haskell web-server performance 2. push that upper bound even higher In regards to #1, we have now established the current upper limit at 221,693.0 req/s. In regards to #2, I believe acme-http will be useful as a place to investigate performance bottlenecks. It is very small, only 250 lines of code or so. And many of those lines deal with pretty-printing, and other non-performance related tasks. Additionally, it works in the plain IO monad. It does not use conduits, enumerators, pipes, or even lazy IO. As, a result, it should be very easy to understand, profile, and benchmark. In providing such a simple environment and avoiding as much extra work as possible we should be able to more easily answer questions like "Why is so much RAM required?", "What is limiting the number of connections per second", etc. As we address these issues in acme-http, we can hopefully bring solutions back to practical frameworks, or to the underlying GHC implementation itself. If performance tuning is your thing, I invite you to check out acme-http and see if you can raise the limit even higher! - jeremy

2 2

ANN: Happstack 7
by Jeremy Shaw 30 Mar '12

30 Mar '12

We are pleased to announce the release of Happstack 7! Happstack is a fast, modern, web application framework written in Haskell. Please check out the brand new happstack.com website to read about what is new in Happstack 7, and what we are planning for Happstack 8, and what makes Happstack great! http://www.happstack.com/ - jeremy

3 3

Re: [web-devel] [Haskell-cafe] Fail-back monad
by Alberto G. Corona 28 Mar '12

28 Mar '12

Hi Stephen: It could be: It performs a rollback indeed. I guess that this monad can be used in something similar to nonblocking (multilevel) transactions. if "GoBack" is changed to "Goback String", and a trace string is added to each NoBack step, then each NoBack step could sum the traces of all the previous steps. The when GoBack condition is reached, it can transport back the entire trace of the failed execution. to the BackPoint 2012/3/28 Stephen Tetley <stephen.tetley(a)gmail.com>: > Maybe this is a version of William Harrison's DebugT monad with > rollback, listed in his periodic table of effects? > > http://www.cs.missouri.edu/~harrisonwl/Presentations/UIUCFM05.ppt > > I've never seen a definition of the monad itself... > http://www.haskell.org/pipermail/beginners/2010-January/003371.html

1 0

GSoC project idea: haskell-type-exts
by Niklas Broberg 28 Mar '12

28 Mar '12

See ticket here: http://hackage.haskell.org/trac/summer-of-code/ticket/1620 == What? == The haskell-src-exts library (HSE) is very popular for manipulating Haskell source code in a wide range of scenarios, such as (syntactic) preprocessors (e.g. hsx), syntax highlighting, refactoring and code inspection (e.g. hlint), etc. A commonly sought feature, that would enable a multitude of new and improved scenarios, is the ability to type-check the code, and annotate the AST with type information. Type-driven refactoring, type-aware code inspection, type-based preprocessing, ... Lots of pure awesomeness lies in that direction. Sadly, HSE has no type-checking abilities. For those who seek such, we are forced to point in the direction of the dark cave that is the GHC API. While GHC is an utterly awesome compiler, there are several reasons why this is not an ideal situation. First, GHC was designed and built for optimization, which means that even the early stages of the compilation pipeline contain features that cater to later optimization, but that are (at best) unnecessary for a front-end tool. Second, the API into GHC internals is defined as an afterthought. Some good work has been done to make it somewhat palatable, but it remains a fact that GHC's primary purpose is not to be a library for integration in tools, and this shows. Overall, depending on GHC when all you want is front-end capabilities like parsing and typechecking, is really like using the proverbial sledge hammer. Also, at the meta level, GHC deserves "competition". Right now GHC is de facto the only implementation of Haskell, and as such it more or less defines the progress of Haskell. Too often this leads to overly pragmatic choices, which lead to inconsistencies and headaches for tool programmers. Having a separate, stand-alone front end library would help set higher standards. So - what we need is a type checker that works on the HSE AST: haskell-type-exts! == How? == I now hear you think: "This is too much, an enormous project, surely it can't be done as a GSoC project?" Sure it can! By walking in the footsteps of giants, and following GHC's approach. This can be achieved by closely observing the documentation provided by [1] and [2], with a bit of [3] thrown into the mix. I already have a basic library that provides most of the core framework necessary to cover extensions, but at this time it's mostly just scaffolding. It needs a lot of love, to provide cover for all the various available extensions, but I'm confident it can be done satisfactorily as a GSoC project. Still, it would be reasonable to modularize the task. Certain features are more crucial than others to support, simply because they have a more profound impact on the overall type-checking. Higher-rank types, GADTs and type families (and fundeps) are likely the most important ones to get right. There are also some design issues to get right (e.g. using pure substitution vs efficient mutable variables). I (Niklas Broberg) am more than willing to mentor this project. == Further reading: == [1] S. Peyton Jones, D. Vytiniotis, S. Weirich, and M. Shields. Practical type inference for arbitrary-rank types. [2] D. Vytiniotis, S. Peyton Jones, T. Schrijvers, M. Sulzmann. OutsideIn(X) – Modular type inference with local assumptions [3] M. P. Jones. Typing Haskell in Haskell

1 0

Fail-back monad
by Alberto G. Corona 28 Mar '12

28 Mar '12

Hi Haskellers. In my package MFlow [1] I program an entire web navigation in a single procedure. That happened in the good-old WASH web application framework. The problem is the back button in the Browser. To go back in the code to the previous interactions when the data input does not match the expected because the user pressed the back button one or more times, i came across this Monad specimen,: that solves the problem. data FailBack a = BackPoint a -- will go back to this point | NoBack a . -- Normal outcome | GoBack -- "exception":: must go to the last backPoint newtype BackT m a = BackT { runBackT :: m (FailBack a ) } -- this monad nas a loop instance Monad m => Monad (BackT m) where fail _ = BackT $ return GoBack return x = BackT . return $ NoBack x x >>= f = BackT $ loop where loop = do v <- runBackT x case v of NoBack y -> runBackT (f y) -- business as usual BackPoint y -> do z <- runBackT (f y) case z of GoBack -> loop -- if x was a backpoint, then redirects the flow to this backpoint other -> return other GoBack -> return GoBack --propagate the signal back This monad does not perform exploration of alternatives as is the case of MonadPlus instances. It does not perform the kind of backtracking of "nondeterministic" three navigations in the Prolog style. It just go back to the last point where the computation can restart again in a sequence of actions. In this example: liftBackPoint f= BackT $ f >>= \x -> return $ BackPoint x test= runBackT $ do lift $ print "will not return back here" liftBackPoint $ print "will return here" n2 <- lift $ getLine lift $ print "second input" n3 <- lift $ getLine if n3 == "back" then fail "" else lift $ print $ n2++n3 Whenever the second input is "back" The procedure will go back to where liftBackPoint is. Otherwise, it will return the concatenation of the two inputs. If the underlying monad is an instance of MonadState, it can transport the state that caused the failure to the backpoint. Are there something similar? May it be functionally equivalent to something simpler or with more grounds? I looked at some exception monads out there, but they did not seems to share the same idea [1] http://haskell-web.blogspot.com.es/2012/02/web-application-server-with-stat…

1 1

GSoC project ideas for web technology
by Jeremy Shaw 25 Mar '12

25 Mar '12

Hello, If you are looking for some ideas for a GSoC project, I have written down some web technology related projects I would like to see. So far I mostly have ideas for improvements to HSX (a templating solution) and acid-state (a pure, haskell persistent datastore). Both these technologies can be used with any Haskell web framework (though they are embraced most fully by Happstack). http://code.google.com/p/happstack/wiki/GoogleSummerOfCode I am an officially registered Haskell GSoC mentor. I am happy to help expand any of these ideas into a genuine GSoC proposal and to act as a mentor on the project. If you have other ideas you wish to pitch, I am happy to hear those as well. - jeremy

1 0

ANN: sendfile 0.7.6
by Jeremy Shaw 21 Mar '12

21 Mar '12

Hello, I just uploaded sendfile 0.7.6 to hackage. This should fix issues with the build failing on 32-bit Linux with GHC 7.4.1. (Such as the hackage build bot). Let me know if you still experience any build failures. - jeremy

2 1