- Haskell-Cafe - Haskell.org

Proposed change to mime-mail
by Erik Hesselink 28 Nov '11

28 Nov '11

Hi all, I've found and solved a problem with mime-mail, and Michael Snoyman asked me to send a request for feedback to -cafe, so here goes. In short, the issue is with address headers containing 'special' (non-ascii) characters. In mime-mail, these are automatically encoded according to RFC 2047. However, the email address part of an address header is not allowed to be encoded. My patch adds 'from', 'to', 'cc' and 'bcc' fields to the Mail data type, and creates correct headers from these fields. This does make the Mail type a bit larger, so I've also added a smart constructor with initializes these fields with empty lists (only 'from' is required). For more details, see my initial bug report [1] and my patches in the pull request [2]. If you have any comments on this change, please let me know. Regards, Erik [1] https://github.com/snoyberg/mime-mail/issues/5 [2] https://github.com/snoyberg/mime-mail/pull/6

3 2

Reminder Haskell Munich
by Heinrich Hördegen 28 Nov '11

28 Nov '11

Dear all, just a reminder for our monthly Haskell get-together in Munich, Cafe Puck, tomorrow (Tuesday, 29th, 19h30). If you will join and didn't already click the button, you can do it here: http://www.haskell-munich.de/dates Have a nice day, Heinrich -- -- hoerdegen(a)funktional.info www.funktional.info --

1 0

Haskellers.com polls (specifically, the mascot question)
by Michael Snoyman 28 Nov '11

28 Nov '11

Hi all, I've just added the polls feature to Haskellers.com, and created an initial poll about mascots[1]. Let me know if there are any issues. Michael PS: I've also added Google+ profile link support, just go to your edit profile page and paste in the link. [1] http://www.haskellers.com/poll/1

4 6

Mascot Poll Results
by heathmatlock 28 Nov '11

28 Nov '11

Haskellers.com poll: Yes 52 votes (50%), 22 verified votes (53%) No 51 votes (49%), 19 verified votes (46%) Email: Yes 14 (64%) No 8 (36%) Seems a bit divided. -- Heath Matlock +1 256 274 4225

5 7

Current Haskell report URL
by Tom Murphy 28 Nov '11

28 Nov '11

Is there a reason that the Haskell 2010 report is in a subdirectory of haskell.org/onlinereport (which currently points to the Haskell98 standard)? http://www.haskell.org/onlinereport/ -- Haskell98 http://www.haskell.org/onlinereport/haskell2010/ -- Haskell2010 If it's for historical reasons - because books etc. use this URL for the 98 standard, then I'd highly recommend making a new directory called "currentreport" or something (if there isn't one already). The current impression that we give is that Haskell98 is the current standard, and Haskell2010 isn't compiler-supported. amindfv / Tom

4 3

ANNOUNCE: clientsession-0.7.3.4 (performance enhancement)
by Michael Snoyman 28 Nov '11

28 Nov '11

Hi all, tl;dr: randomIV is now much faster, API is the same, upgrade ASAP to avoid painful slowdowns. Version 0.7 of clientsession brought with it a much enhanced encryption and hashing algorithm, courtesy of Felipe Lessa. Beginning with this version, you now need to provide an Initialization Vector (IV) for encrypting cookies, and these IVs need to be randomly generated. To start off with, we simply used the getIVIO[1] function to generate these values. Recently, some Yesod users reported that version 0.9 of Yesod no longer lived up to previous benchmarks. After some research, I determined that the slowdown came from the call to randomIV in clientsession. The initial fix was simply to disable this call when it wasn't used, but it was still a significant slowdown for most users of Yesod. Over the past few days, Felipe and I put together a significantly more efficient version of randomIV. getIVIO simply opens up /dev/urandom on each request, which involves I/O. As a result, the average run time of the function in our testing was 1.686ms. Instead, our new code initializes with a call to /dev/urandom for the base randomness. It then uses AES encryption to work as a cryptographic random number generator for generating successive IVs. Additionally, every 1000 calls (we'll probably change that number over time), it spawns a new thread to reseed the generator from /dev/urandom again. The result is a function that takes 7.144764 us, aka 236 times faster. Thanks for the initial reporters who commented on the slowdown in Yesod. If you install the newest clientsession and rerun the benchmarks, you should see *significantly* better results. Michael [1] http://hackage.haskell.org/packages/archive/crypto-api/0.8/doc/html/Crypto-…

2 1

XML modification
by Andrew Coppin 25 Nov '11

25 Nov '11

Hi guys. I've got a folder with about 80 XML files in it. I want to take each file and make specific modifications to it. (Mostly just finding specific attributes and changing their values to make then all consistent.) Now I guess it wouldn't take me /that/ long to code something from scratch. But does anybody have a better suggestion for tools or libraries that might be useful?

2 4

blaze-textual-native and aeson-native are being deprecated
by Michael Snoyman 25 Nov '11

25 Nov '11

Hi all, In the last Yesod release, we created two new packages: blaze-textual-native and aeson-native. These were direct forks of their source packages, with just two changes: blaze-textual-native did not include a double-conversion dependency, and aeson-native depended on blaze-textual-native instead of blaze-textual. The reason for all this is that there is a GHC bug which prevents C++ code from working correctly with GHCi and Template Haskell[1]. Bryan recently released a new version of blaze-textual which no longer uses double-conversion by default (it's still available with compile-time flags if you want the extra speed and don't need TH/GHCi), and as a result, we are very happy to be deprecating the native siblings. Fortunately, there are not that many packages on Hackage using these libraries; in fact, the only packages for which I'm not a maintainer are dingo-core, dingo-widgets and hledger-web. However, since these are Yesod dependencies, I'm guessing many Yesod users reference aeson-native in their site cabal files. Technically speaking, switching from aeson-native to aeson in a library should constitute a major version bump. However, in this case, I think we want these deprecated packages to die as quickly as possible. So my plan is to switch all of my packages from using aeson-native to aeson some time next week. The result will likely be broken builds for some people; all you'll need to do is edit your cabal file and replace aeson-native with aeson (likewise for blaze-textual). Are there any objections to this course of action, or better ideas on how to handle the situation? Michael [1] Please don't ask me for details, I don't know them. And for all I know, the bug has already be fixed in newer GHCs.

1 0

FGL custom node identification (Label -> Node lookup)
by Thomas DuBuisson 25 Nov '11

25 Nov '11

All, The containers library has a somewhat primitive but certainly useful Data.Graph library. Building a graph with this library simultaneously results in the lookup functions: m1 :: Vertex -> (node, key, [key]) m2 :: key -> Maybe Vertex (where 'key' is like FGL's 'label' but is assumed to be unique) This is exactly what I wanted when building and analyzing a call graph in FGL. To that end, I started making a graph type that tracked label to Node mappings, wrapping Data.Graph.Inductive.Gr, and assuming the labels are all unique. The classes for such a graph actually aren't possible. The ability to build a mapping from a node's 'label' to the 'Node' requires extra context (ex: Hashable, Ord, or at least Eq), but such context can not be provided due to the typeclass construction. Is there any chance we can change the Graph and DiaGraph classes to expose the type variables 'a' and 'b'? class Graph gr a b where ... class (Graph gr) => DynGraph gr a b where ... This would allow instances to provide the needed context: instance (Hashable a, Hashable b) => Graph UniqueLabel a b where ... buildGraph = ... some use of containers libraries that require context ... ... lookupNode :: Hashable a => UniqueLabel a b -> a -> Node -- etc Cheers, Thomas P.S. Please do educate me if I simply missed or misunderstood some feature of FGL.

2 4

ANN: OpenCL 1.0.2.2 package
by Luis Cabellos 24 Nov '11

24 Nov '11

Hello, all. I update the OpenCL package with a better error handle using Control.Exception. Thanks all comments in the previous version, and issues in github. # Where to get it * Hackage page (http://hackage.haskell.org/package/OpenCL) * Repository (https://github.com/zhensydow/opencl) * Bugs (https://github.com/zhensydow/opencl/issues) # Changes: * Changed LICENSE to BSD3 * Changed error from 'IO (Either CLError a)' to IO a + CLError exceptions * Added creation of programs using precompiled binaries (added example program) * Better documentation. Thanks, Luis Cabellos

1 1