- Haskell-Cafe - Haskell.org

Looking for (possibly temporary) maintainers
by Julian K. Arni 10 May '17

10 May '17

Hi cafe! I'm going to be away from the internet from late May till early September, so I'm trying to ensure that all my packages have someone who could be responsible for them in the meantime. Minimally, this would involve reviewing new PRs and making releases with them, but you'd be free to take on a more active role too. If you want to continue being a maintainer after that, you'd be very welcome, but I do intend to help. Most of the packages already have other maintainers, but these don't: - bookkeeper (https://github.com/turingjump/bookkeeper) - extensible records library - verdict (https://github.com/jkarni/verdict) - refinement-type-like opaque types - servant-quickcheck (https://github.com/haskell-servant/servant-quickcheck) - quickcheck properties of entire APIs If you're interested, send me an email! Thanks, Julian Arni

1 0

GHC cross compilation survey
by Moritz Angermann 10 May '17

10 May '17

Dear friends, as some of you might have noticed, together with obsidian.systems, I’m trying to make cross compiling GHC a bit easier. To that extend, I’d like to invite you to fill out a short survey[1], so we understand the needs of the community better. Please follow the attached link and fill out the survey! Cheers, Moritz [1]: https://medium.com/@zw3rk/hello-world-a-cross-compilation-survey-890cb95029…

1 1

Announce: Haskell Platform 8.0.2-a builds for Windows 10 Creators Update
by Gershom B 10 May '17

10 May '17

As many people know, the recent Windows 10 Creators Update broke the latest GHC 8.0.2 release. [1] We're happy to announce that there are now new 8.0.2-a builds on the Haskell Platform website that include the patch prepared by GHC HQ, and the hashes have been updated appropriately as well: https://www.haskell.org/platform/windows.html Note that this is not a new HP release in any official sense, nor are these new HP builds. These are the existing installers with the replacement of one file. Accordingly, they have new file names and hashes. However, all else remains the same. Similarly, no builds for other platforms have been updated. If you are not using Windows 10, this doesn't affect you in any way. And if you are, you probably already ran into this. Apologies for about a week of tardiness in getting this out, which is entirely due to my frazzledness. Happy Haskell Hacking all, Gershom [1] https://mail.haskell.org/pipermail/ghc-devs/2017-April/014131.html

1 0

Error using Judy arrays (was: Re: [Biohaskell] hash map/associative structure)
by Ketil Malde 10 May '17

10 May '17

On 2017-05-04 12:14 (+0200), Michał J Gajda <mjgajda(a)gmail.com> wrote: > Interesting. Do You have an error report filed anywhere to peruse? Well, I wrote the below. In the mean time, I've tried replacing "insertWith" with a manual lookup and update. This changed the cases where the segfaults happen, but didn't eliminate them. And I tried using the safe freeze function, to no avail. And I implemented some of the functionality using a Vector, which gives correct results (but without reimplementing a real hashtable, it can only be used for the histogram collection, not k-mer counting, since with large k that requires full 64-bit indexes into the vector) I've also run on several different computers, so I don't think it's a hardware error. -k ---------------------------------------- So: I have a program that indexes k-mers (fixed-size words) as Word64's, storing the different ones along with their counts in a Judy array, and at the end, writing to a file. So an associative map mapping k-word -> count. Then, the second stage re-reads this file, and builds a histogram, tallying how often each count occurs. let's call this count -> frequency For some time, this just seemed to work. But then I implemented an expectation-maximization algorithm to model the frequency distributions, and that failed to terminate in some cases. Going back, I found the following histogram to cause the trouble: ==> SRR901891_1.32.hist <== 865 809 866 775 867 757 868 781 869 725 870 778 871 795 872 774 873 771 48036128 2017612633061982208 Notice that last value? Apparently, there are 2.018e18 different k-mers with a frequency of 48036128. This is clearly not right. Notice also that the latter number is 0x01c000...000. Does this carry any special meaning? One possibility is of course some garbage in the k-mer count index, but I also have a dump command that prints the contents as text. I can find nothing wrong with that, and the highest count k-mers look like this: % sort -nr -k2 *dump* | head tgggggtccagccatggagaagagtttagaca 1670602 gggggtccagccatggagaagagtttagacac 1653146 gtctaaactcttctccatggctggacccccaa 1638158 gaatattatttgggggtccagccatggagaag 1567591 ggaatattatttgggggtccagccatggagaa 1539378 actagtgcttaggaaatctattggaggcagaa 1532596 gcttctgcctccaatagatttcctaagcacta 1531091 aggaatattatttgggggtccagccatggaga 1528806 ctagtgcttaggaaatctattggaggcagaag 1527682 aaaggaatattatttgggggtccagccatgga 1518392 One thing to look into is how the histogram is built. I have wrapped this in a function (mk_judy, code below) that returns a struct of operations, called FreqCount. mk_judy takes as an argument the number of bits to use in the index - but this isn't really used for anything (JudyL is JudyL). Yet, when I changed this parameter from 16 to 32, the last line changed to: 17180896 2017612633061982208 And with 64: 37271776 2017612633061982208 The latter number is always the same, the former ends with 0x8e0, but appears to vary in the most significant bits. Everything else is the same in the histograms, I did a diff on the outputs. -- Code ---------------------------------------- mk_judy :: Int -> IO FreqCount mk_judy l = do j <- J.new :: IO (J.JudyL Int) let ac k = k `seq` J.insertWith (+) k 1 j gc k = k `seq` fromMaybe 0 `fmap` J.lookup k j sc k v = J.insert k v j es = J.unsafeFreeze j >>= J.elems ks = J.unsafeFreeze j >>= J.keys as = J.unsafeFreeze j >>= J.toList return $ FreqCount { key_bits = l , add_count = ac, get_count = gc, set_count = sc , keys = ks, counts = es, assocs = as } -- Code ---------------------------------------- If we're sure there is nothing wrong with the Judy library, the only other thing I can think of is the unsafeFreeze. I'm pretty sure I don't modify the Judy array after accessing it through the "frozen" functions - but could it e.g. be the case that j is frozen with some operations still unevaluated? I tried adding "j `seq`" before unsafeFreeze, and got: 33769696 2017612633061982208 Again, 0x...8e0 and the usual 0x01c0... Anyway, that's where it stands at the moment. I'm not sure what to do, it does worry me that this counting seems to fail on occasion. Note also that the histogram gets truncated (always at the same place, after 873), and it should really go up to 1.5 million. ---------------------------------------- -- If I haven't seen further, it is by standing in the footprints of giants

2 1

TFPIE - Trends in Functional Programming in Education 2017 - Deadline extended to 17 May
by Simon Thompson 10 May '17

10 May '17

After a number of requests, we have extended the deadline for TFPIE 2017 to 17 May. Please consider submitting if you’re interested in hearing about how to get the functional message shared more widely. A particular topic of this year's TFPIE will be MOOCs and other online learning and, as well as a session on this, we're delighted to announce that Heather Miller of EFPL and Northeastern University will be giving a keynote on this topic. Heather works on and around the Scala programming language and is Executive Director of the Scala Center. We'll also have Yann Regis-Gianas and Benjamin Canou from the OCaml MOOC team, Jeremy Singer (Haskell), and Simon Thompson (Erlang). TFPIE 2017 - DEADLINE EXTENDED TO 17 MAY Trends in Functional Programming in Education, 2017 https://www.cs.kent.ac.uk/people/staff/sjt/TFPIE2017/ The sixth workshop on Trends in Functional Programming in Education, 2017, which is to be held on the Canterbury campus of the University of Kent on Thursday, 22 June, following the 2017 TFP meeting on 19–21 June. TFPIE workshops have previously been held in St Andrews, Scotland (2012), Provo Utah, USA (2013), Soesterberg, The Netherlands (2014), and Sophia-Antipolis, France (2015), College Park, USA (2016). The goal of TFPIE is to gather researchers, teachers and professionals that use, or are interested in the use of, functional programming in education. TFPIE aims to be a venue where novel ideas, classroom-tested ideas and work-in-progress on the use of functional programming in education are discussed. The one-day workshop will foster a spirit of open discussion by having a review process for publication after the workshop. The program chair of TFPIE 2017 will screen submissions to ensure that all presentations are within scope and are of interest to participants. After the workshop, presenters will be invited to submit revised versions of their articles for publication in the journal Electronic Proceedings in Theoretical Computer Science (EPTCS). Final call for papers TFPIE 2017 welcomes submissions describing techniques used in the classroom, tools used in and/or developed for the classroom and any creative use of functional programming (FP) to aid education in or outside Computer Science. Topics of interest include, but are not limited to: - FP and beginning CS students - FP and Computational Thinking - FP and Artificial Intelligence - FP in Robotics - FP and Music - Advanced FP for undergraduates - FP in graduate education - Engaging students in research using FP - FP in Programming Languages - FP in the high school curriculum - FP as a stepping stone to other CS topics - FP and Philosophy - The pedagogy of teaching FP - FP and e-learning: MOOCs, automated assessment etc. - Best Lectures – more details below In addition to papers, we are requesting best lecture presentations. What’s your best lecture topic in an FP related course? Do you have a fun way to present FP concepts to novices or perhaps an especially interesting presentation of a difficult topic? In either case, please consider sharing it. Best lecture topics will be selected for presentation based on a short abstract describing the lecture and its interest to TFPIE attendees. Submission Potential presenters are invited to submit an extended abstract (4-6 pages) or a draft paper (up to 16 pages) in EPTCS style. The authors of accepted presentations will have their preprints and their slides made available on the workshop's website. Papers and abstracts can be submitted via easychair at the following link: https://easychair.org/conferences/?conf=tfpie2017 After the workshop, presenters will be invited to submit (a revised version of) their article for review. The PC will select the best articles for publication in the journal Electronic Proceedings in Theoretical Computer Science (EPTCS). Articles rejected for presentation and extended abstracts will not be formally reviewed by the PC. Programme committee Dr Laura Castro, University of A Coruña Prof Ralf Lämmel, University of Koblenz-Landau Dr Elena Machkasova, University of Minnesota, Morris Prof Michel Mauny, Inria, Paris Dr Jeremy Singer, University of Glasgow Prof Simon Thompson, University of Kent (chair) Important dates Submissions of draft papers: 17 May, 2017 Notification: 22 May, 2017 Registration: 11 June, 2017 Workshop: 22 June 2017 Submission for formal review: 18 August, 2017 Notification of acceptance: 6 October, 2017 Camera ready paper: 3 November, 2017 Simon Thompson | Professor of Logic and Computation School of Computing | University of Kent | Canterbury, CT2 7NF, UK s.j.thompson(a)kent.ac.uk | M +44 7986 085754 | W www.cs.kent.ac.uk/~sjt

1 0

Bug in random shuffle algorithm
by David Turner 09 May '17

09 May '17

https://wiki.haskell.org/Random_shuffle says: Here's a variation using the MonadRandom package: import Control.Monad import Control.Monad.ST import Control.Monad.Random import System.Random import Data.Array.ST import GHC.Arr shuffle :: RandomGen g => [a] -> Rand g [a] shuffle xs = do let l = length xs rands <- take l `fmap` getRandomRs (0, l-1) let ar = runSTArray $ do ar <- thawSTArray $ listArray (0, l-1) xs forM_ (zip [0..(l-1)] rands) $ \(i, j) -> do vi <- readSTArray ar i vj <- readSTArray ar j writeSTArray ar j vi writeSTArray ar i vj return ar return (elems ar) But this doesn't yield a uniformly-chosen random permutation of its input, because at the i'th step the first `i` elements are not fixed as they are in the other algorithms on that page. Cheers, David

3 2

Re: [Haskell-cafe] [perl #129843] [LTA] Indexing on a Str throws generic “out of range” message which is less than awesome (“hello”[2])
by Joachim Durchholz 09 May '17

09 May '17

Am 08.05.2017 um 23:00 schrieb Brandon Allbery: > > On Mon, May 8, 2017 at 4:49 PM, Joachim Durchholz <jo(a)durchholz.org > <mailto:jo@durchholz.org>> wrote: > > If the mental model for Perl6 strings is "array of characters" though > > Perl has never had that mental model, is my point. Right, I should have written "is supposed to evolve to" instead of "is". Array of characters may be a useful abstraction to have in Perl6, or not (see below). > It's generally > imported by folks who come from languages where strings *are* "arrays of > characters" --- and where that model has a strong tendency to cause > problems. (See Python 3's struggles with Unicode as an example. And > C/C++, well, don't even get me started. Some of these struggles originate from equating bytes with characters. Since Perl6 is more or less a clean slate, it can avoid these. Other struggles originate from the structure of Unicode: it defines multiple levels of sequences, each useful for different tasks: - code points - graphemes - characters (various normalizations exist) - word parts (for line breaking) - words - sentences - paragraphs and possible a few more. Ideally, developers will be able to use the same API structure at each level, maybe with the exception of the grapeme level where Perl6 has its native representation (the better the API, the less of such implementation details is visible and relevant to the programmer). > Bytes stopped being the basis of > characters even *before* Unicode. C and C++ are still struggling to > understand that. I think you're being unfair to them. The issues are actually well-understood in the C++ arena, as demonstrated by the ICU library. It's just that language evolution is constrained by legacy, plus possibly short-sighed decisions by compiler makers. Also, C++ (by necessity) evolves slower than Unicode. Under these conditions, Unicode support in a library is actually preferrable to anything inside the language, it's enough if the language can interoperate with the library.

1 0

[ANN] gonimo web-based baby monitor has launched!
by Robert Klotzner 09 May '17

09 May '17

Hi to all Haskell-er parents out there! Always hated that your baby monitor is the only thing left in your household not coded in Haskell? Well, don't worry no more! Gonimo is here! Visit gonimo.com <https://gonimo.com> and have a baby monitor coded in Haskell! All you need is a recent web-browser (Chrome works best) on any non iOS platform! :-) Source code on github <https://github.com/gonimo/gonimo>! Hope you like it! Feedback, very welcome! Uh and we have a facebook page too! facebook.com/mygonimo ! If you like our baby monitor consider a like or even share - it is pretty hard with no money to reach potential users, so this would really be awesome! Best regards, Robert

2 1

Parse stream using an external template for rules?
by Brian Jones 09 May '17

09 May '17

I'm not completely sure what I am looking for so I figured I'd ask the community. I have a project which reads data from a telnet stream (I wrote a pipes-network[1] library to handle this), however, rather than hard code the parsing rules with something like attoparsec (as I have done in my example) I'd like to define a template language which reads in a file with the template definitions that describes what to parse instead and use that inside the parser step. What tools and approaches would you recommend in this case? Or alternatively, a better solution? Thanks, Brian [1] https://github.com/alasconnect/pipes-telnet

1 0

Language extension proposal: aspects
by MarLinn 09 May '17

09 May '17

4 10