- Haskell-Cafe - Haskell.org

Munich Haskell Meeting, 2019-03-27 @ 19:30
by Leah Neukirchen 25 Mar '19

25 Mar '19

Dear all, Next week, our monthly Munich Haskell Meeting will take place again on Wednesday, March 27 at Rumpler at 19h30. For details see here: http://muenchen.haskell.bayern/dates.html If you plan to join, please add yourself to this dudle so we can reserve enough seats! It is OK to add yourself to the dudle anonymously or pseudonymously. https://dudle.inf.tu-dresden.de/haskell-munich-mar-2019/ Everybody is welcome! cu & see you perhaps tomorrow at Munich Lambda meetup, -- Leah Neukirchen <leah(a)vuxu.org> http://leahneukirchen.org/

3 2

sublime-haskell and hsdev
by Dennis Raddle 22 Mar '19

22 Mar '19

I'm just now learning Sublime Text 3 and trying to install sublime-haskell. It requires me to build hsdev, which I did with "cabal install hsdev". However the latter operation installs version > 3 of hsdev, while sublime-haskell requires < 3. So first question, how do I build and install an earlier version of hsdev? Also, I'm not clear if sublime-haskell is integrated with stack. I use stack for everything and I've been using Intero up til now in Emacs. The docs mention stack but seem to be clearer about cabal. D

2 1

RedMonk ranks Haskell among top 20 most popular programming languages
by Jeffrey Brown 22 Mar '19

22 Mar '19

based on GitHub and StackOverflow. https://redmonk.com/sogrady/2019/03/20/language-rankings-1-19/ -- Jeff Brown | Jeffrey Benjamin Brown Website <https://msu.edu/~brown202/> | Facebook <https://www.facebook.com/mejeff.younotjeff> | LinkedIn <https://www.linkedin.com/in/jeffreybenjaminbrown>(spammy, so I often miss messages here) | Github <https://github.com/jeffreybenjaminbrown>

1 0

More graph algorithms for Alga & Streaming JSON/YAML parser
by Shiv 22 Mar '19

22 Mar '19

Dear mentors, I am Shiv Pratap Singh from IIIT-Allahabad, India. I am currently in 4th year and Computer Science Undergraduate. After lot of brainstorming and carefully choosing the project idea based on my skills/expertise/experience, I am highly interested in project idea mentioned in Subject of the mail. As the proposal submission date is very close, I am keen to discuss the idea in depth so that various subtasks can be finalized .If any prior contribution/patch is requirement for applying, please let me know. Please mention some resources links in order to gain insights on project. Hoping to work together! Thank you, Shiv

2 2

[ANN] libarchive
by Vanessa McHale 21 Mar '19

21 Mar '19

Hi all, I just released libarchive (http://hackage.haskell.org/package/libarchive) which can be used to create and unpack tar archives as well as several other formats. It has a reasonably complete high-level API and full bindings to the C library. Cheers, Vanessa McHale

1 0

Yet another binary reader (10x faster than Hackage's binary; )
by Станислав Черничкин 20 Mar '19

20 Mar '19

I was investigating Haskell’s binary serialization libraries and has found that lot of them (binary, cereal and protocol-buffers) has pretty similar design. They capable to consume lazy bytestrings and either produce result, report error or produce partial result, indicating that more input data required. Such design leads to quite complex readers, and often ends up with producing closures in runtime. If you take a close look at binary’s microbenches (binary in general bit faster than cereal, so I focused on binary) you will discover, that it triggers GC even during simple tasks, such as reading a bunch of Word64 and summing results. And it relatively slow. Binary’s performance limited to hundreds of megabytes per second even in simple scenarios, but actual memory bandwidth should allow us process gigabytes per second. So, I decided to try a different approach. My approach is based on two assumptions so if it does not suit your case it obliviously will not work for you. First – when dealing with binary data we always know exactly how many bytes we want to read. This happens because we either read a fixed size primitive type or length-prefixed variable size data (possibly not “prefixed”, but you always know expected message length from somewhere). Second – chunks of data are continuous. I.e. we working with strict bytestrings more often. Even when you processing chunked stream of data with unknown number of messages (such as Mesos RecordIO Format) you should always be able to allocate continuous memory buffer for a single entity you want to deserialize. If it’s ok for you lets go on. First thing I’ve created was so called static reader. Static – because reader knows how mush bytes it wants to consume at compile time. Such readers suitable for reading combinations of primitive values. Here the implementation https://github.com/PROTEINE-INSAIDERS/lev-tolstoy/blob/master/src/Lev/Reade… Static reader is somewhat monadic (you can use do-syntax with RebindableSyntax extension like here https://github.com/PROTEINE-INSAIDERS/lev-tolstoy/blob/master/bench/Bench/L… ) but it actually indexed monad and it unfortunately incompatible with traditional monads. Offsets and sizes are calculates at type level during the compile time and according to microbences static reader does not introduced any overhead compared to hand-written reader using the low-level indexInt64OffAddr# function ( https://github.com/PROTEINE-INSAIDERS/lev-tolstoy/blob/master/bench/Bench/H… ) Next thing was a dynamic reader. Dynamic readers are composed from static readers, they are fully monadic and allow you to read length-prefixed data structures (you read length with wrapped static reader and then perform normal monadic binding to supply a reader which reads a value). Here the implementation https://github.com/PROTEINE-INSAIDERS/lev-tolstoy/blob/master/src/Lev/Reade… I’ve discovered, that typeclasses are surprisingly fast. So, it’s completely ok to have something like “(Cursor c) => … Reader” where cursor contains functions for overflow checking and memory buffer progression. I was not able to achieve same performance when I passed buffer callbacks explicitly, possibly because of inlining of specialization magic. So, I've created ByteStringCursor ( https://github.com/PROTEINE-INSAIDERS/lev-tolstoy/blob/master/src/Lev/Reade… ) which allows to read strict bytestrings. I suppose that cursors introduce flexibility: you may read strict bytestring or you may define custom cursor for reading custom memory buffers. Finally, I’ve written some microbenches for my cases and also ported one microbench from binary. And my implementation was able to run 10x-15x faster than binary on strict bytestring. Moreover, it does not trigger GC during the run at all! You may find the project and all the benches here https://github.com/PROTEINE-INSAIDERS/lev-tolstoy So, what's the purpose of my message? It’s quite unlikely that I’ll release my code on the Hackage. This is because I’m a hobbyist Haskell developer and doing it all in my free time. But before mr. Putin will close Internet in Russia I’d like to demonstrate that it’s possible to write very fast binary deserializer taking in account several assumptions which seems quite reasonably for me. So, feel free to borrow the ideas, or share the ideas, if you know how it could be implemented better. -- Sincerely, Stanislav Chernichkin.

4 4

Re: [Haskell-cafe] Yet another binary reader (10x faster than Hackage's binary)
by Olaf Klinke 20 Mar '19

20 Mar '19

My (admittedly limited) experience with parsers, of which deserializers are a special case, is that with complicated data structures the majority of computing time is spent transforming the raw data (i.e. chunks of bytes) into meaningful information such as Doubles, Timestamps, tree structures and so on. Of course you could argue that such conversions are not the scope of the deserializer and that these operations must be performed regardless which library one chooses. Nevertheless it somewhat relativizes the importance of the choice of serializing library. Your benchmarks do not go beyond adding integers as far as I can see, which is a relatively cheap operation. I'd be interested in a benchmark where e.g. a huge Set or an array of custom records are used. You seem to work in bioinformatics. There are plenty of examples from this field, e.g. genomic annotations. Cheers, Olaf

1 0

Re： Yet another binary reader (10x faster thanHackage's binary; )
by Dr.Koster 20 Mar '19

20 Mar '19

These two assumptions are basically the most challenging issues stop people from getting more performance, e.g. If somehow you want to support incremental parsing, a primitive like `ensureN` probably need to do something like ``` ensureN n = Parser $ \ buf ... k -> if n < length buf then k buf ... else partial buf ... k ``` The k appear twice inside `ensureN` 's both branch, which will stop parsers from getting inline sooner or later since inlining k into both branch will produce exponential amount of code, so instead GHC will allocate k and make a jump, the best we can get is probably to try make it a joint point, so no allocation is needed, but that's the best you can get from argument passing buffers. Regards Han Dong ------------------ 原始邮件 ------------------ 发件人: "Joachim Durchholz"<jo(a)durchholz.org>; 发送时间: 2019年3月20日(星期三) 中午1:28 收件人: "haskell-cafe"<haskell-cafe(a)haskell.org>; 主题: Re: [Haskell-cafe] Yet another binary reader (10x faster thanHackage's binary; ) Am 19.03.19 um 22:58 schrieb Станислав Черничкин: > possibly because of inlining of > specialization magic. I have seen people validate this kind of assumption, by looking at the various intermediate representations of code. If you're after performance, you may want to do that. You may find that things work differently than expected, with the potential for becoming a bottleneck when stuff is scaled up (more varied datatypes in the input stream, or more complex target datatypes, stuff hidden behind "oh I don't need GC yet", that kind of finding). Regards, Jo _______________________________________________ Haskell-Cafe mailing list To (un)subscribe, modify options or view archives go to: http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe Only members subscribed via the mailman list are allowed to post.

2 1

Data.Functor.Compose Combinator
by Ben Kolera 20 Mar '19

20 Mar '19

Hi, I was wondering if this function exists somewhere (i'm not attached to the name): (<<$>>) :: (Functor f) => (a -> g b) -> f a -> Compose f g b (<<$>>) mkG = Compose . fmap mkG It's handy if you're working with an applicative (e.g Reflex.Dynamic) and want to layer on top a validation type function that returns a different applicative that need composing. So I figure that it must exist somewhere! :) E.g. data Person = Person Text Email nameTextDyn :: Dynamic t Text emailTextDyn :: Dynamic t Text validEmail :: Text -> Validation (NonEmpty Text) Email validPersonDyn :: Dynamic t (Validation (NonEmpty Text) Person = getCompose $ Person <$> (pure <<$>> name) <*> (validEmail <<$>> emailTextDyn) Cheers, Ben

1 0

Fwd: [Fwd: linux version compatible with GHC 4.3 ?]
by Damien Mattei 19 Mar '19

19 Mar '19

---------- Forwarded message --------- From: Damien Mattei <damien.mattei(a)univ-cotedazur.fr> Date: Mon, Mar 18, 2019 at 11:46 AM Subject: [Fwd: linux version compatible with GHC 4.3 ?] To: <damien.mattei(a)gmail.com> ---------- Forwarded message ---------- From: Damien Mattei <damien.mattei(a)univ-cotedazur.fr> To: Haskell Cafe <haskell-cafe(a)haskell.org> Cc: Bcc: Date: Mon, 18 Mar 2019 11:39:25 +0100 Subject: linux version compatible with GHC 4.3 ? Hi, does anyone know a linux distrib where haskell platform installs out of the box? it fails on fedora core 28 (32bits) : [root@localhost Downloads]# ghci /usr/local/haskell/ghc-8.4.3-i386/lib/ghc-8.4.3/bin/ghc: error while loading shared libraries: libtinfo.so.5: cannot open shared object file: No such file or directory but works on older system such as CentOS Linux release 7.2.1511 (Core) 64bits: [mattei@moita ~]$ cat /etc/redhat-release CentOS Linux release 7.2.1511 (Core) [mattei@moita ~]$ ghci GHCi, version 8.4.3: http://www.haskell.org/ghc/ :? for help Prelude> does it works on Ubuntu? Damien

4 3