January 2012 - Haskell-Cafe

TCP Server
by Alexander V Vershilov 31 Jan '12

31 Jan '12

Hello, café. Recently I asked about tcp server libraries [1] and there was only one answer haskell-scallable-server [2], but in that package there was some dependencies and server logic that are not good for my task. So I decided to make a library with skeletons for different types of tcp servers and a basic library to make server [3]. Now there is only warp based (simplified) tcp server. Main logic is: * handle new connection and start iteratee green thread * enumerator (library side) reads socket and send data into enumeratee (application side) * enumeratee consumes input and produces server command (now simply output) and push it into iteratee (server side) * iteratee server side reads command and performs action (now simply output command) It gives application possibility to store state in enumerator. My questions to community: 1). can you help to make code better ;) maybe there are some stupid mistakes 2). is there any ideas what thing can be add to the server to make it reusable And another thing that I want to add other types of server e.g. single threaded, with workers pool, or other types. And I want to ask what types of servers will be effective in haskell. [1] http://www.haskell.org/pipermail/haskell-cafe/2012-January/098594.html [2] https://github.com/jamwt/haskell-scalable-server [3] https://github.com/qnikst/TcpServers -- Alexander V Vershilov.

7 12

[ANNOUNCE] biostockholm 0.2
by Felipe Almeida Lessa 31 Jan '12

31 Jan '12

Hello! I'm pleased to announce the second major release of the biostockholm library! This library allows you to parse and render files in the Stockholm 1.0 format, which is used by Pfam, Rfam, Infernal and others for holding information about families of proteins or non-coding RNAs. http://hackage.haskell.org/package/biostockholm Despite this low increase in number from 0.1 to 0.2, this is actually a big rewrite of the library. Now we have: - An streaming interface similar to what SAX parsers provide. This allows you to consume Stockholm files using constant memory (80k in a simple case). - More test cases. It's able to consume its own pretty printed version of Rfam through the document interface, and is also capable of reading the full Rfam stockholm file (which has some huge families) through the streaming interface. - QuickCheck properties. Now we have three different QuickCheck properties covering almost everything. These have helped uncover some tricky bugs that were never found before. However, two of these three properties still don't pass, but I consider the failing examples that I've investigated just corner cases. Unfortunately, Stockholm lacks a formal specification. - Conduit interface. Besides a lazy I/O version, now there's a conduit interface. - Code much easier to read and reason about. - Fast enough: the streaming interface achieves 12 MiB/s for parsing, which is pretty nice considering that there are some known overheads on its implementation. For the tasks that biostockholm 0.1 already handled, biostockholm 0.2 tends to be slightly slower. However, biostockholm 0.2 is able to handle some previously impossible cases where an streaming solution is required. Cheers! -- Felipe.

1 1

strict version of Haskell - does it exist?
by Marc Weber 31 Jan '12

31 Jan '12

A lot of work has been gone into GHC and its libraries. However for some use cases C is still preferred, for obvious speed reasons - because optimizing an Haskell application can take much time. Is there any document describing why there is no ghc --strict flag making all code strict by default? Wouldn't this make it easier to apply Haskell to some additional fields such as video processing etc? Wouldn't such a '--strict' flag turn Haskell/GHC into a better C/gcc compiler? Projects like this: https://github.com/thoughtpolice/strict-ghc-plugin show that the idea is not new. Eg some time ago I had to do some logfile analysis. I ended doing it in PHP because optimizing the Haskell code took too much time. Marc Weber

12 18

[Haskell Cafe] strict version of Haskell - does it exist?
by Doug McIlroy 31 Jan '12

31 Jan '12

> Is there any document describing why there is no ghc --strict flag > making all code strict by default? > Wouldn't such a '--strict' flag turn Haskell/GHC into a better C/gcc > compiler? I agree that a strict flag would turn Haskell into C--but that's a perversion of Haskell. Almost all Haskell code I write depends critically on laziness. Sure, there are little bits here and there that would run faster if I carefully decorated them with strict flags. But the genius of Haskell is architectural clarity, achieved in no small part by relegating nasty issues of sequencing to the implementation. If you even have to think once about what needs to be strict or non-strict, then non-strict is the only viable default. I can't imagine writing any interesting Haskell code that will successfully run all strict. Doug McIlroy

4 3

Invitation to connect on LinkedIn
by Sunny Basi 31 Jan '12

31 Jan '12

LinkedIn ------------ I'd like to add you to my professional network on LinkedIn. - Sunny Sunny Basi Software Development Engineer Intern at Amazon.com Greater Seattle Area Confirm that you know Sunny Basi: https://www.linkedin.com/e/uc6lxc-gy2lv1bv-z/isd/5727371010/HFPCz0eC/?hs=fa… -- You are receiving Invitation to Connect emails. Click to unsubscribe: http://www.linkedin.com/e/uc6lxc-gy2lv1bv-z/XvIdBwmueHfd6vFMPXXdLaqreCbl5oO… (c) 2012 LinkedIn Corporation. 2029 Stierlin Ct, Mountain View, CA 94043, USA.

1 0

Speculative Parallelism
by Burak Ekici 30 Jan '12

30 Jan '12

Dear List, my question is in which cases, I could understand the speculative parallelism in parallel Haskell? Does the case in which all and the same number of created sparks are converted by both original and second generation strategies, speak of the speculative parallelism effect? If it does not, how can I prove the argument that indicating speculative parallelism could be exploited in second generation strategies while it is not possible to exploit when usages of original ones are in question? Kind regards, Burak.

1 0

space leak when repeatedly calling Control.Monad.State.Strict.modify
by Joey Hess 30 Jan '12

30 Jan '12

The attached test case quickly chews up hundreds of MB of memory. If modified to call work' instead, it runs in constant space. Somehow the value repeatedly read in from the file and stored in the state is leaking. Can anyone help me understand why? (ghc 7.0.4) -- see shy jo

3 4

Re: [Haskell-cafe] Some thoughts on Type-Directed Name
by Anthony Clayden 30 Jan '12

30 Jan '12

> There is an effort underway to make Haskell's Records > better. The discussion is ongoing on the ghc-users mail > list, ... > in the direction of making the most minimal changes > possible to achieve some simple record name-spacing. > > Thanks, > Greg Weber Thank you Greg, Yes I know, and I have been trying to follow along (intermittently). Thank you for your attempts to marshall the discussion. What would really, really help me is for someone to have a look at the 'solution' I posted to the difficulties SPJ saw with the SORF approach. (I ref'd it in my reply to Steve.) It seemed from my testing to address the needs. Since I got it working in GHC 7.2.1, there's a good chance it will need only "minimal changes" to implement (I'm thinking mostly syntactic sugar) -- providing of course that it is workable and generalisable enough. It could possibly benefit from some of the new Kind-level stuff in 7.4.1 (that SPJ used, but wasn't available to me at the time). I keep trying to make the time to write up the full proposal on the Wiki. I see it as a 'tweak' to SORF. Given that I'm supposed to have a day job, I'm reluctant to make time until/unless someone else double-checks whether I'm barking up the wrong tree. Anthony

2 1

Need advice: Haskell in Web Client
by dokondr 30 Jan '12

30 Jan '12

**Bardur Arantsson wrote: >On 01/26/2012 11:16 AM, dokondr wrote: >> Ideally, I would be happy to be able to write in Haskell a complete >> front-end / GUI, so it could be compiled to different back-ends: Javascript >> to run in the Browser and also a standalone app. >> In Python world this is already done with Pyjamas (http://pyjs.org/) - "a >> Rich Internet Application (RIA) Development Platform for both Web and >> Desktop." >> Also from Pyjamas site: >> Pyjamas "... contains a Python-to-Javascript compiler, an AJAX framework >> and a Widget Set API. >> Pyjamas Desktop is the Desktop version of Pyjamas >> Pyjamas Desktop allows the exact same python web application source code to >> be executed as a standalone desktop application (running under Python) >> instead of being stuck in a Web browser." >> >> Architecture diagram >> http://pyjs.org/wiki/pyjamasandpyjamasdesktop/ >> >> I wonder if somebody works on similar Haskell "Rich Internet Application >> (RIA) Development Platform" ? >> Any ideas, comments on implementation of such system in Haskell? What >> existing Haskell GUI libraries can be used for a desktop GUI, etc.? >> > >Well, it's basically just proof-of-concept at the moment, and it's not >really usable for real applications at the moment, but there is > > http://hackage.haskell.org/package/dingo-core-0.1.0 > http://hackage.haskell.org/package/dingo-widgets-0.1.0 > http://hackage.haskell.org/package/dingo-example-0.1.0 > >The basic client<->server communication, server-side state handling, >etc. is there, but it's missing a couple of things before it could be >used for real apps: There's no real security, and there are *very* few >widgets. The few widgets that exist at the moment are also probably >lacking a few operations. On the plus side, it's should be pretty easy >to create new widgets. > >You can get a feel for how the thing looks from an application >programmer's perspective by looking at the source for the example. Looks neat, thanks! If I got this write, in dingo all web page content is created by running Haskell on the server side in run-time and then sending generated html + js to the client (browser). I am looking for the opposite - when client does more work running Javascript generated by Haskell in advance, the approach that Pyjamas use ( http://pyjs.org/) with Python to Javascript compilation.

1 0

ANN: bytestring-lexing 0.3.0
by wren ng thornton 29 Jan '12

29 Jan '12

-------------------------------------------- -- bytestring-lexing 0.3.0 -------------------------------------------- The bytestring-lexing package offers efficient reading and packing of common types like Double and Integral types. -------------------------------------------- -- Administrative Changes (since 0.2.1) -------------------------------------------- * Change of maintainer. Don Stewart handed maintainership of the package over to myself when I voiced interest. * Change of repo type. The old repo for the package used Darcs-1 style patches. I've converted the repository to Darcs-2 hashed. This means that the new repository cannot exchange patches with the old Darcs-1 repo (or any other Darcs-2 conversions that may be floating around out there). So anyone who's interested in contributing should scrap their local copies and get the new repo. -------------------------------------------- -- Code Changes (since 0.2.1) -------------------------------------------- * Added Data.ByteString.Lex.Integral which provides efficient implementations for reading and packing/showing integral types in ASCII-compatible formats including decimal, hexadecimal, and octal. * The readDecimal function in particular has been highly optimized. The new version is wicked fast[1] and perfectly suitable for hot code locations like parsing headers for HTTP servers like Warp. In addition, attention has been paid to ensuring that parsing is efficient for larger than native types like Int64 on 32-bit systems (including 64-bit OS X), as well as Integer. The optimization of this function was done in collaboration with Erik de Castro Lopo, Vincent Hanquez, and Christoph Breitkopf following a blog post by Erik[2] and ensuing discussion on Reddit[3] [1] A Criterion report is available for 64-bit Intel OS X running 32-bit GHC 6.12.1: http://code.haskell.org/~wren/bytestring-lexing/test/bench/readDecimal.html The benchmark is included in the repo and has also been run on 64-bit GHC 7 systems, which differ primarily in not showing slowdown for Int64 vs Int (naturally). If you're curious about the different implementations: * readIntBS / readIntegerBS --- are the readInt and readInteger functions in Data.ByteString * readDecimalOrig (correct) --- was my original implementation, prior to collaboration with Erik, Vincent, and Christoph. * readIntegralMH (buggy) --- or rather a non-buggy version very much like it, is the implementation currently used in Warp. * readDecimal (current) --- is the current implementation used in this package. [2] http://www.mega-nerd.com/erikd/Blog/CodeHacking/Haskell/read_int.html [3] http://www.reddit.com/r/haskell/comments/otwxe/benchmarking_and_quickchecki… -------------------------------------------- -- 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

2 3