- Haskell-Cafe - Haskell.org

Haskell developer role with Strats at Standard Chartered London
by Don Stewart 10 Jun '15

10 Jun '15

Hi all, I'm hiring (another) Haskell dev to join our team in London. Details here: https://donsbot.wordpress.com/2015/06/10/haskell-dev-role-in-strats-at-stan…

1 0

[ANN] Lentil - a frugal issue tracker
by Francesco Ariis 10 Jun '15

10 Jun '15

lentil - a frugal issue tracker If you litter your code with TODOs and FIXMEs, lentil [1] can help you make sense of that big mess into something nice and readable like: src/Lentil/File.hs 49 does upMan work windows? [feature:intermediate] src/Lentil/Parse.hs 26 eliminate lookahead? refactor parsing? [lint] [refactor] 54 add test for rotoscope [test] It supports tags, filtering, exporting and much more. Check the user manual [2] for more information. [1] http://hackage.haskell.org/package/lentil [2] http://www.ariis.it/static/articles/lentil-manual/page.html

2 2

[Haddock] Alphabetize record accessors
by aditya siram 09 Jun '15

09 Jun '15

How would people feel about Haddock alphabetizing record accessors by default? For example: data T { b :: ..., c :: ... , a :: ... } displays as: data T { a :: ..., b :: ... , c :: ... } Seems as though projects that have large records like Cabal & Parsec would benefit from this. Thanks! -deech

6 5

And, Or, Not, and [something atomic] data types: What am I doing?
by Jeffrey Brown 09 Jun '15

09 Jun '15

I am considering the problem of representing search results in a graph database. (Define such a database as a collection N of nodes and E of labeled edges, where a labeled edge consists of a triplet (l, n1, n2), where l is some kind of label and n1 and n2 are members of N.) I think a type something like the following would be useful: data Search = Fan { origin :: Node , label :: Label , members :: [Node] } | And Search Search | Or Search Search | Not Search In a Fan with origin o, members would be the set of Nodes p such that (label, o, p) is an edge. A Search is ultimately built out of Fans. I've seen this kind of thing before, and I believe it will lead me to some substantial problems that other people have already solved. What should I study?

1 0

parsec or attoparsec for 40-50MB text files ?
by briand＠aracnet.com 09 Jun '15

09 Jun '15

Hi, My file is pretty straightforward text file with a small amount of somewhat annoying state: comments* config line comments* data line* if there is no config line it's an error. the data lines can have a variable number of values and it matters how many values there are (hey- it's not my file format !). the data lines can also have a comment at the end. My initial thought was to go with parsec but the data files could be as large as 40-50MB and upon further reading it really seemed like attoparsec would be better. Error handling wouldn't be too sophisticated. if a data line has something other than 1 or more floating point values and the optional comment, failing out with "error line X" is fine. parse time is somewhat critical only because i'll have multiple files to parse, so while 5-10 seconds is ok for one file, i have to multiply that by 5-10. I've seen several comments talking about the fact that parsec can be slow, but so far unable to find anything the quantifies "slow". Any opinions on which would be better for my application (although i think i've just talked myself into using attoparsec) ? In particular- am i going to get at least reasonable "error on line X" error handling using attoparsec ? Thanks, Brian

5 5

Re: [Haskell-cafe] zipWith and divide
by Rehno Lindeque 07 Jun '15

07 Jun '15

Hi! > zipWith(\) z1 z2 ........ this fails but works when using * or + or - > ....... I also tried using div and `div` but they failed to. > The divide operator is slash (/) not backslash (\): > zipWith (/) [0.1, 0.2] [0.2, 0.4] [0.5,0.5] Also, div should work as long you're using a Integral type like Int (you may be using Float or Double): > zipWith div [1, 2] [2, 2] [0,1] Cheers

1 0

ANN: nonce package
by Felipe Lessa 07 Jun '15

07 Jun '15

(Please forgive me if you received multiple copies of this e-mail.) Hello, The nonce package [1] contains functions to easily generate cryptographic nonces for many situations. Some places where these generated nonces can be used include: - Password recovery e-mail tokens. - XSRF protection tokens. - Session IDs sent on cookies. - Initialization vectors. It uses an AES CPRNG periodically reseeded from /dev/urandom (or equivalent). It has no frills, no knobs, so it's hard to misuse. It's been available for an year but I just realized I've never properly announced it. Regrettably, I've seen many uses of the random package (System.Random) when generating nonces. It's a bad choice: it is not a cryptographically secure PRNG, contains low entropy (64-bit state), and its default usage is seeded predictably (using a constant seed). Please avoid using the random package for generating nonces at all costs. In its stead, use the nonce package or something similar. Cheers, [1] http://hackage.haskell.org/package/nonce -- Felipe.

3 4

Re: [Haskell-cafe] Attacking Attachment "Cancelled Event" Bayhac 15
by Byron Hale 07 Jun '15

07 Jun '15

Bayhac 15 has not been cancelled. See http://bayhac.org/ @bayhac2015 Do NOT open the attachment to the cancelling email. It is likely a sophisticated attack. The listed "organizer" is not. We may, however, have modifications. For example, we are still seeking donors for food. We are still seeking speakers, maybe even some repeats of last year's speakers. You might just dust off last year's presentation, until we run out of room. Best Regards, Byron Hale byron.hale(a)einfo.com @Hale_ByronL

1 0

ANN: bytestring-lexing 0.5.0
by wren romano 07 Jun '15

07 Jun '15

-------------------------------------------- -- bytestring-lexing 0.5.0 -------------------------------------------- The bytestring-lexing package offers extremely efficient bytestring parsers for some common lexemes: namely integral and fractional numbers. In addition, it provides efficient serializers for (some of) the formats it parses. As of version 0.3.0, bytestring-lexing offers the best-in-show parsers for integral values. (According to the Warp web server's benchmark of parsing the Content-Length field of HTTP headers.) And as of this version (0.5.0) it offers (to my knowledge) the best-in-show parser for fractional/floating numbers. -------------------------------------------- -- Changes since 0.4.3 (2013-03-21) -------------------------------------------- I've completely overhauled the parsers for fractional numbers. The old Data.ByteString.Lex.Double and Data.ByteString.Lex.Lazy.Double modules have been removed, as has their reliance on Alex as a build tool. I know some users were reluctant to use bytestring-lexing because of that dependency, and forked their own version of bytestring-lexing-0.3.0's integral parsers. This is no longer an issue, and those users are requested to switch over to using bytestring-lexing. The old modules are replaced by the new Data.ByteString.Lex.Fractional module. This module provides two variants of the primary parsers. The readDecimal and readExponential functions are very simple and should suffice for most users' needs. The readDecimalLimited and readExponentialLimited are variants which take an argument specifying the desired precision limit (in decimal digits). With care, the limited-precision parsers can perform far more efficiently than the unlimited-precision parsers. Performance aside, they can also be used to intentionally restrict the precision of your program's inputs. -------------------------------------------- -- Benchmarks -------------------------------------------- For the Criterion output of the benchmark discussed below, see <http://community.haskell.org/~wren/bytestring-lexing/bench/html/readExponen…>. The main competitors we compare against are the previous version of bytestring-lexing (which already surpassed text and attoparsec/scientific) and bytestring-read which was the previous best-in-show. The unlimited-precision parsers provide 3.3x to 3.9x speedup over the readDouble function from bytestring-lexing-0.4.3.3, as well as being polymorphic over all Fractional values. For Float/Double: these functions have essentially the same performance as bytestring-read on reasonable inputs (1.07x to 0.89x), but for inputs which have far more precision than Float/Double can handle these functions are much slower than bytestring-read (0.30x 'speedup'). However, for Rational: these functions provide 1.26x to 1.96x speedup compared to bytestring-read. The limited-precision parsers do even better, but require some care to use properly. For types with infinite precision (e.g., Rational) we can pass in an 'infinite' limit by passing the length of the input string plus one. For Rational: doing so provides 1.5x speedup over the unlimited-precision parsers (and 1.9x to 3x speedup over bytestring-read), because we can avoid intermediate renormalizations. Whether other unlimited precision types would see the same benefit remains an open question. For types with inherently limited precision (e.g., Float/Double), we could either pass in an 'infinite' limit or we could pass in the actual inherent limit. For types with inherently limited precision, passing in an 'infinite' limit degrades performance compared to the unlimited-precision parsers (0.51x to 0.8x 'speedup'). Whereas, passing in the actual inherent limit gives 1.3x to 4.5x speedup over the unlimited-precision parsers. They also provide 1.2x to 1.4x speedup over bytestring-read; for a total of 5.1x to 14.4x speedup over bytestring-lexing-0.4.3.3! -------------------------------------------- -- Links -------------------------------------------- Homepage: http://code.haskell.org/~wren/ Hackage: http://hackage.haskell.org/package/bytestring-lexing Darcs: http://community.haskell.org/~wren/bytestring-lexing Haddock (Darcs version): http://community.haskell.org/~wren/bytestring-lexing/dist/doc/html/bytestri… -- Live well, ~wren

1 0

Re: [Haskell-cafe] Proposal: Shorter Import Syntax
by Anthony Cowley 06 Jun '15

06 Jun '15

> On Jun 5, 2015, at 4:14 PM, Marcin Mrotek <marcin.jan.mrotek(a)gmail.com> wrote: > > +1, though something alleviating the burden of importing the same module twice, like: > > import qualified Text as Text > import Text ( {- something -} ) > > would be even better. That is what this does. You will be able to write: import Text ( {- something -} ) as Text Anthony

2 1