February 2011 - Haskell-Cafe

Re: [Haskell-cafe] Byte Histogram
by John Lato 07 Feb '11

07 Feb '11

> > From: Ivan Lazar Miljenovic <ivan.miljenovic(a)gmail.com> > > On 7 February 2011 12:30, wren ng thornton <wren(a)freegeek.org> wrote: > > On 2/6/11 4:53 PM, Ivan Lazar Miljenovic wrote: > >> > >> On 7 February 2011 08:12, Alexey Khudyakov<alexey.skladnoy(a)gmail.com> > >> ?wrote: > >>> > >>> Also there is a container-classes package which provide set of type > class > >>> for containers. > >>> > >>> [1] http://hackage.haskell.org/package/container-classes > >> > >> Don't use that package: it's broken. ?I did start on a re-write that > >> works (and there are similar libraries around that I believe do work), > >> but gave up because it was a) too fiddly, and b) I decided that the > >> use case I had for them wasn't worth it (as it would just make that > >> library more complicated and difficult to use, possibly also less > >> efficient). ?If anyone wants it I can certainly send them what I've > >> got though. > > > > Any chance you could push a 0.0.0.1 version which tells people this, so > that > > they know to avoid it? > > Didn't think about that; I'll try to do so tonight. > Perhaps a better approach would be to ask the hackage maintainer (Ross Patterson, if I'm not mistaken) to deprecate container-classes. John

2 1

Snap 0.4 Released!
by Gregory Collins 06 Feb '11

06 Feb '11

The Snap team is proud to announce the release of Snap 0.4, containing a whole bunch of nifty new features. Here is what we've been up to: New Features ------------ - Heist now uses the brand new xmlhtml HTML5 parser for parsing and rendering templates. This eliminates our dependency on XML and makes it possible to include inline javascript/css in templates. Check out Chris Smith's blog post for more information about xmlhtml. - Along with the change to xmlhtml, we decided to convert Heist to use Text instead of ByteString. This is a backwards-incompatible change which breaks old code, but which we feel is the right thing to do. - Snap now has support for file uploads (!) and the multipart/form-data content type. Snap's file upload support uses iteratees to stream uploaded data and comes with a convenience function to writeuploaded files to a temporary directory. We put significant effort into preventing denial of service attacks and providing policy controls for things like maximum allowable file size, upload timeouts, minimum upload speed, etc. - The web server now uses blaze-builder in the output response body Enumerator. Besides being significantly faster for most workloads than ByteString enumeration, this allowed us to save several copies within the server code, giving us a moderate performance improvement. However, this will break any existing code making direct use of the output enumerator rather than using convenience functions like writeBS. We encourage users who are building up large responses out of lots of little bytestring chunks to consider switching their code to using Builder and writeBuilder to get a speed boost. - The "development mode" of projects built using our snap project starter is now quite a bit smarter. The 0.3 version used hint to interpret web handlers on-the-fly, but it re-interpreted the code on each request, making keeping in-memory state between requests impossible. The development mode now only rebuilds the project when files actually change. State will now be preserved across requests as long as the project files are not changed on disk. - Our file serving code has been substantially improved/rewritten. The new code can automatically generate stylable/themable directory indexes, provides configurable lists of index files, and allows the user to plug in dynamic handlers. These handlers can be used to perform arbitrary transformations based on file type or file content on the fly. The new code also correctly handles trailing slashes for relative path resolution. - It is now possible for user handlers to modify socket timeouts, using the setTimeout function. This (finally) makes it possible to have long-running request handlers. Bugfixes/Improvements --------------------- - Debugging support in snap-core is now turned off by default, as it involves too much of a performance impact. Turning on debug support results in a ~25% performance penalty. To turn debugging output back on, pass the -f debug flag when installing snap-core. - Bugfix: we no longer log spurious "thread killed" messages in the simple backend under HTTP/1.0. - Added catchFinishWith function. - Changed cookie interface to expose cookies in the response as a map for easier manipulation. As always, please let us know if you find any issues with the release. Thanks! -- Gregory Collins <greg(a)gregorycollins.net>

1 0

Concurrency best practices?
by wren ng thornton 06 Feb '11

06 Feb '11

So I'm working on a project that uses STM to run a lot of things in parallel without the headaches of locks. So far it's working beautifully, STM rocks. But there's one snag... Sometimes I need those threads to do some IO like printing logging info. I'd like to make these IO chunks atomic with respect to one another so that the logging output isn't garbage. Since I'm using STM everywhere else, I'd love to use it for this too (instead of mixing STM and non-STM concurrency) except you can't embed IO in STM. I could just use STM vars as locks to force the atomicity, but locks are ugly and bug-prone. So what's the current best practice for doing this kind of thing? -- Live well, ~wren

8 8

ANN: monad-control-0.1
by Bas van Dijk 06 Feb '11

06 Feb '11

Dear all, Several attempts have been made to lift control operations (functions that use monadic actions as input instead of just output) through monad transformers: MonadCatchIO-transformers[1] provided a type class that allowed to overload some often used control operations (catch, block and unblock). Unfortunately that library was limited to those operations. It was not possible to use, say, alloca in a monad transformer. More importantly however, the library was broken as was explained[2] by Michael Snoyman. In response Michael created the MonadInvertIO type class which solved the problems. Then Anders Kaseorg created the monad-peel library which provided an even nicer implementation. monad-control is a rewrite of monad-peel that uses CPS style operations and exploits the RankNTypes language extension to simplify and speedup most functions. A very preliminary and not yet fully representative, benchmark shows that monad-control is on average about 2.6 times faster than monad-peel: bracket: 2.4 x faster bracket_: 3.1 x faster catch: 1.8 x faster try: 4.0 x faster mask: 2.0 x faster Note that, although the package comes with a test suite that passes, I still consider it highly experimental. API DOCS: http://hackage.haskell.org/package/monad-control INSTALLING: $ cabal update $ cabal install monad-control TESTING: The package contains a copy of the monad-peel test suite written by Anders. You can perform the tests using: $ cabal unpack monad-control $ cd monad-control $ cabal configure -ftest $ cabal test BENCHMARKING: $ darcs get http://bifunctor.homelinux.net/~bas/bench-monad-peel-control/ $ cd bench-monad-peel-control $ cabal configure $ cabal build $ dist/build/bench-monad-peel-control/bench-monad-peel-control DEVELOPING: The darcs repository will be hosted on code.haskell.org ones that server is back online. For the time being you can get the repository from: $ darcs get http://bifunctor.homelinux.net/~bas/monad-control/ TUTORIAL: This short unpolished tutorial will explain how to lift control operations through monad transformers. Our goal is to lift a control operation like: foo ∷ M a → M a where M is some monad, into a transformed monad like 'StateT M': foo' ∷ StateT M a → StateT M a The first thing we need to do is write an instance for the MonadTransControl type class: class MonadTrans t ⇒ MonadTransControl t where liftControl ∷ (Monad m, Monad n, Monad o) ⇒ (Run t n o → m a) → t m a If you ignore the Run argument for now, you'll see that liftControl is identical to the 'lift' method of the MonadTrans type class: class MonadTrans t where lift ∷ Monad m ⇒ m a → t m a So the instance for MonadTransControl will probably look very much like the instance for MonadTrans. Let's see: instance MonadTransControl (StateT s) where liftControl f = StateT $ \s → liftM (\x → (x, s)) (f run) So what is this run function? Let's look at its type: type Run t n o = ∀ b. t n b → n (t o b) The run function executes a transformed monadic action 't n b' in the non-transformed monad 'n'. In our case the 't' will be a StateT computation. The only way to run a StateT computation is to give it some state and the only state we have lying around is the one from the outer computation: 's'. So let's run it on 's': instance MonadTransControl (StateT s) where liftControl f = StateT $ \s → let run t = ... runStateT t s ... in liftM (\x → (x, s)) (f run) Now that we are able to run a transformed monadic action, we're almost done. Look at the type of Run again. The function should leave the result 't o b' in the monad 'n'. This 't o b' computation should contain the final state after running the supplied 't n b' computation. In case of our StateT it should contain the final state s': instance MonadTransControl (StateT s) where liftControl f = StateT $ \s → let run t = liftM (\(x, s') → StateT $ \_ → return (x, s')) (runStateT t s) in liftM (\x → (x, s)) (f run) This final computation, "StateT $ \_ → return (x, s')", can later be used to restore the final state. Now that we have our MonadTransControl instance we can start using it. Recall that our goal was to lift "foo ∷ M a → M a" into our StateT transformer yielding the function "foo' ∷ StateT M a → StateT M a". To define foo', the first thing we need to do is call liftControl: foo' t = liftControl $ \run → ... This captures the current state of the StateT computation and provides us with the run function that allows us to run a StateT computation on this captured state. Now recall the type of liftControl ∷ (Run t n o → m a) → t m a. You can see that in place of the ... we must fill in a value of type 'm a'. In our case this will be a value of type 'M a'. We can construct such a value by calling foo. However, foo expects an argument of type 'M a'. Fortunately we can provide one if we convert the supplied 't' computation of type 'StateT M a' to 'M a' using our run function of type ∀ b. StateT M b → M (StateT o b): foo' t = ... liftControl $ \run → foo $ run t However, note that the run function returns the final StateT computation inside M. So the type of the right hand side is now 'StateT M (StateT o b)'. We would like to restore this final state. We can do that using join: foo' t = join $ liftControl $ \run → foo $ run t That's it! Note that because it's so common to join after a liftControl I provide an abstraction for it: control = join ∘ liftControl Allowing you to simplify foo' to: foo' t = control $ \run → foo $ run t Probably the most common control operations that you want to lift through your transformers are IO operations. Think about: bracket, alloca, mask, etc.. For this reason I provide the MonadControlIO type class: class MonadIO m ⇒ MonadControlIO m where liftControlIO ∷ (RunInBase m IO → IO a) → m a Again, if you ignore the RunInBase argument, you will see that liftControlIO is identical to the liftIO method of the MonadIO type class: class Monad m ⇒ MonadIO m where liftIO ∷ IO a → m a Just like Run, RunInBase allows you to run your monadic computation inside your base monad, which in case of liftControlIO is IO: type RunInBase m base = ∀ b. m b → base (m b) The instance for the base monad is trivial: instance MonadControlIO IO where liftControlIO = idLiftControl idLiftControl directly executes f and passes it a run function which executes the given action and lifts the result r into the trivial 'return r' action: idLiftControl ∷ Monad m ⇒ ((∀ b. m b → m (m b)) → m a) → m a idLiftControl f = f $ liftM $ \r -> return r The instances for the transformers are all identical. Let's look at StateT and ReaderT: instance MonadControlIO m ⇒ MonadControlIO (StateT s m) where liftControlIO = liftLiftControlBase liftControlIO instance MonadControlIO m ⇒ MonadControlIO (ReaderT r m) where liftControlIO = liftLiftControlBase liftControlIO The magic function is liftLiftControlBase. This function is used to compose two liftControl operations, the outer provided by a MonadTransControl instance and the inner provided as the argument: liftLiftControlBase ∷ (MonadTransControl t, Monad base, Monad m, Monad (t m)) ⇒ ((RunInBase m base → base a) → m a) → ((RunInBase (t m) base → base a) → t m a) liftLiftControlBase lftCtrlBase = \f → liftControl $ \run → lftCtrlBase $ \runInBase → f $ liftM (join ∘ lift) ∘ runInBase ∘ run Basically it captures the state of the outer monad transformer using liftControl. Then it captures the state of the inner monad using the supplied lftCtrlBase function. If you recall the identical definitions of the liftControlIO methods: 'liftLiftControlBase liftControlIO' you will see that this lftCtrlBase function is the recursive step of liftLiftControlBase. If you use 'liftLiftControlBase liftControlIO' in a stack of monad transformers a chain of liftControl operations is created: liftControl $ \run1 -> liftControl $ \run2 -> liftControl $ \run3 -> ... This will recurse until we hit the base monad. Then liftLiftControlBase will finally run f in the base monad supplying it with a run function that is able to run a 't m a' computation in the base monad. It does this by composing the run and runInBase functions. Note that runInBase is basically the composition: '... ∘ run3 ∘ run2'. However, just composing the run and runInBase functions is not enough. Namely: runInBase ∘ run ∷ ∀ b. t m b → base (m (t m b)) while we need to have ∀ b. t m b → base (t m b). So we need to lift the 'm (t m b)' computation inside t yielding: 't m (t m b)' and then join that to get 't m b'. Now that we have our MonadControlIO instances we can start using them. Let's look at how to lift 'bracket' into a monad supporting MonadControlIO. Before we do that I define a little convenience function similar to 'control': controlIO = join ∘ liftControlIO Bracket just calls controlIO which captures the state of m and provides us with a runInIO function which allows us to run an m computation in IO: bracket ∷ MonadControlIO m ⇒ m a → (a → m b) → (a → m c) → m c bracket before after thing = controlIO $ \runInIO → E.bracket (runInIO before) (\m → runInIO $ m >>= after) (\m → runInIO $ m >>= thing) I welcome any comments, questions or patches. Regards, Bas [1] http://hackage.haskell.org/package/MonadCatchIO-transformers [2] http://docs.yesodweb.com/blog/invertible-monads-exceptions-allocations/ [3] http://hackage.haskell.org/package/monad-peel

1 0

community server & hasktags learned recursing into directories
by Marc Weber 06 Feb '11

06 Feb '11

hasktags learned about how to recurse into subdirectories itself. This is especially useful for windows because writing scripts can be done but is less well known (http://stackoverflow.com/questions/4865391/answer/submit) Now I'd like to push the latest changes to the community server which was hosting the repo in the past but my account does no longer work? Also there are some dead links now. Eg http://www.haskell.org/haskellwiki/Haskell.org_domain still references http://community.haskell.org/admin/ (404) Do you know what happened and where I should host the repo now? (uploading it to github would take seconds only) Moreover I fonud that I was no longer subscribed to haskell-cafe. I can't remember having unsubscribed ? Let's hope this mail get's through now after having resubscribed. Marc Weber

5 6

Storing passwords securely
by Peter Scott 06 Feb '11

06 Feb '11

The usual advice on how to store passwords securely is "use bcrypt", but since there seem to be no Haskell bindings for bcrypt, the other good option is to iterate a salted hash function at least 1000 times. In order for people to get this right, there should be a library with a really simple API that makes it Just Work. I think I have such an API, but I'd like to hear if anybody else has suggestions before I go releasing it onto Hackage. The code is here: https://github.com/PeterScott/pwstore The part of the API that people have to care about is two functions. makePassword creates a hashed, salted password that you can store in a database. verifyPassword takes this hashed, salted password and a user's password input, and tells you if it matches. Like this: >>> makePassword (B.pack "hunter2") 12 "sha256|12|lMzlNz0XK9eiPIYPY96QCQ==|1ZJ/R3qLEF0oCBVNtvNKLwZLpXPM7bLEy/Nc6QBxWro=" >>> verifyPassword (B.pack "wrong guess") passwordHash False >>> verifyPassword (B.pack "hunter2") passwordHash True There's also a function for increasing the number of hash iterations on stored password hashes, to compensate for Moore's law. Does this sound reasonable? Also, I have a pure-Haskell version and a version which depends on some C code, for speed (about 25x difference). Does anybody care about the pure Haskell version, or should I just drop it and require the faster C/Haskell mixed version? Thanks, -Peter

2 2

Re: [Haskell-cafe] combined parsing & pretty-printing
by Ozgur Akgun 05 Feb '11

05 Feb '11

Great! That was pretty fast :) Are you going to update invertible-syntax to use partial-isomorphisms-0.2? 2011/2/5 Tillmann Rendel <tillmann(a)rendel.net> > Hi Ozgur, > > Ozgur Akgun wrote: > >> I've already implemented a toy example and it worked great. Now I am >> trying >> to use your library in a more serious piece of code, and I've realised >> that >> defineIsomorphisms doesn't support record constructors. To be precise, you >> handle the case for NormalC in the code, however you do not handle RecC. I >> don't think this will be a difficult thing to add. Is there any reason for >> you not to support RecC? >> > > No reason at all. I just generalized the Template Haskell macros. They now > support: > > * newtypes > * infix constructors > * record constructors > > Infix constructors are only support by constructorIso, though, not by > defineIsomorphisms, because I can't think of a good automatic naming scheme. > Suggestions welcome. > > The code is on hackage. > > There are still some constructors which are not supported: constructors of > GADTs as well as data or newtype instances, and constructors with > existentials. I would need to think about typing issues before supporting > these. > > Tillmann > -- Ozgur Akgun

1 0

combined parsing & pretty-printing
by Ozgur Akgun 05 Feb '11

05 Feb '11

Dear Café, I working on a DSL represented by a algebraic data type with many constructors. I can write (separately) a parser and a pretty-printer for it, and I am doing so at the moment. However, this way it feels like repeating the same information twice. Is there any work to combine the two? Best, Ozgur

7 8

Problem with xhtml 1.5.1.1: html tags are split
by Gwern Branwen 05 Feb '11

05 Feb '11

On Thu, May 13, 2010 at 11:38 AM, Gwern Branwen <gwern0(a)gmail.com> wrote: > On Tue, May 11, 2010 at 3:00 AM, Bjorn Bringert <bjorn(a)bringert.net> wrote: >> I support finding a new maintainer. > > Alright; as the old maintainer, I guess it falls on you to advertise > on -cafe and libraries. Has a request gone out yet? I didn't notice anything (maybe it got lost in all the recent haskell.org downtime), and the current Hackage page of xhtml is still listing Bjorn. Anyway, John MacFarlane has found a workaround which he's implemented in HEAD Pandoc (http://code.google.com/p/pandoc/issues/detail?id=134) from http://groups.google.com/group/pandoc-discuss/browse_frm/thread/915586b5c5e… : > Many people have wanted pandoc to produce "more normal" HTML output, > without nesting, but with line breaks between block elements (where > they aren't semantically significant). Something like this: > > <ul> > <li>a <a href="/foo">link</a></li> > <li>another list item</li> > </ul> > > I've found that I can get this kind of output, even using Text.XHtml's > renderer, by modifying the writer to insert raw newlines after block > elements, and using 'showHtmlFragment' rather than 'prettyHtmlFragment'. This may be useful for other people to know. (There are quite a few users of xhtml: http://bifunctor.homelinux.net/~roel/cgi-bin/hackage-scripts/revdeps/xhtml-… ) -- gwern http://www.gwern.net

1 0

Re: [Haskell-cafe] Byte Histogram
by Janis Voigtländer 05 Feb '11

05 Feb '11

On 2/5/11 4:26 AM, Claus Reinke wrote: >> Lately I've been trying to go the other direction: make a large >> section of formerly strict code lazy. > > There used to be a couple of tools trying to make suggestions when a > function could be made less strict (Olaf Chitil's StrictCheck and > another that escapes memory at the moment). Probably Sloth: http://korsika.informatik.uni-kiel.de/~jac/wordpress/ http://korsika.informatik.uni-kiel.de/~jac/wordpress/wp-content/uploads/PAD… Best, Janis. -- Jun.-Prof. Dr. Janis Voigtländer http://www.iai.uni-bonn.de/~jv/ mailto:jv@iai.uni-bonn.de

1 0