September 2014 - Haskell-Cafe

Race conditions with threadWait(Read/Write) and closeFdWith
by Leon Smith 03 Sep '14

03 Sep '14

I was very tangentially involved with a use-after-close IO descriptor fault recently, and I came to realize that descriptor indexes are typically allocated by the smallest available index, Previously, I had erroneously believed that the indexes were sequentially allocated by an ever-increasing counter, until wrap-around occurs. Obviously, the smallest available index allocation strategy makes use-after-close faults rather more significant, because in a server application that is constantly closing and allocating descriptors, it makes it rather more likely that an erroneous operation will actually have a tangible effect, and not simply return an EINVAL or similar errno. So in my low-level linux-inotify binding, I felt it wise to add protection against use-after-close faults. The approach I'm currently investigating is the obvious one: to (conceptually) represent the inotify socket by a "MVar (Maybe Fd)" value. However, if there's no file system events to read from the socket, we want to call threadWaitRead, So somewhere there's some code that's essentially this: readMVar inotifyfd >>= maybe (throwIO ...) threadWaitRead So the problem is, what happens when the thread executing this snippet yields in between the readMVar and the threadWaitRead? It would then be possible for another thread (or two) to close the inotify descriptor, and then allocate another descriptor with the same index. The first thread would then end up blocking until the new descriptor becomes readable, after which the thread would re-read the MVar and throw an exception that the descriptor has been closed. This is a _relatively_ benign effect, but still, it does prevent the waiting thread from throwing an exception at the earliest possible moment, and there are several particularly unlucky scenarios I can think of where such a thread could be waiting on the wrong descriptor for a very long time. Not to mention that this is a whole family of race conditions, which I haven't really explored the other possible manifestations of which might not be as benign. Somebody did also point me to the new threadWaitReadSTM primitives, but this doesn't cover this use case although the original proposal (properly implemented, of course) would: http://www.haskell.org/ghc/docs/7.8.3/html/libraries/base-4.7.0.1/Control-C… https://ghc.haskell.org/trac/ghc/ticket/7216 In any case, my linux-inotify binding is available on github; the current main branch is unreleased and also has code to attempt to make reading from a descriptor a thread-safe operation. However I'm not too enthusiastic about this unreleased code at the moment, and am considering throwing it out. However, I'd still very much like to add protection against use-after-close faults, and I'd certainly prefer being able to concurrently call both close and read on the descriptor with complete safety. https://github.com/lpsmith/linux-inotify Best, Leon

5 14

"Lower case" infix type operator variables
by Joseph Abrahamson 03 Sep '14

03 Sep '14

I spent a few moments confused by the fact the TypeOperators was insufficient to allow the following type to be parsed constA :: Arrow (~>) => b -> (a ~> b) My current intuition is that since I *can* write things like newtype (~>) a b = A (a -> b) there is clashing in the type operator space for “upper case” and “lower case” identifiers. Is it possible or advisable to mitigate this clash and provide some syntax for “type operator variables”? Joseph

3 2

ANNOUNCE: hemokit 0.6.3 - Now with OpenVibe compatibility
by Niklas Hambüchen 02 Sep '14

02 Sep '14

Heya, out is Hemokit 0.6.3, which can now be connected to the OpenVibe EEG framework. OpenVibe allows fancy stuff like spelling words with your mind: Video: https://www.youtube.com/watch?v=08GNE6OdNcs Docs: http://openvibe.inria.fr/coadapt-p300-stimulator-tutorial There is a new tutorial on how to set up Hemokit+OpenVibe at: https://github.com/nh2/hemokit/wiki/OpenVibe If you set up something cool with that, don't forget to tell me about it! Grab Hemokit: https://hackage.haskell.org/package/hemokit Stand-alone Linux and Windows binaries are also available: https://github.com/nh2/hemokit/releases

2 1

System.Process.readProcess "yes" [] "" >>= return . take 100
by David Fox 02 Sep '14

02 Sep '14

I would expect the expression above to finish - but it doesn't. Is this a bug?

3 2

Third call for papers, IFL 2014
by publicityifl＠gmail.com 02 Sep '14

02 Sep '14

Hello, Please, find below the third call for papers for IFL 2014. The submission page is now open. The submission date has been delayed to Sep. 8 2014 anywhere on the world. Please forward these to anyone you think may be interested. Apologies for any duplicates you may receive. best regards, Jurriaan Hage --- CALL FOR PAPERS 26th SYMPOSIUM ON IMPLEMENTATION AND APPLICATION OF FUNCTIONAL LANGUAGES - IFL 2014 NORTHEASTERN UNIVERSITY/BOSTON, USA OCTOBER 1-3, 2014 http://ifl2014.github.io We are pleased to announce that the 26th edition of the IFL series will be held at Northeastern University in Boston, USA. The symposium will be held from 1st to 3rd of October 2014. Scope ----- The goal of the IFL symposia is to bring together researchers actively engaged in the implementation and application of functional and function-based programming languages. IFL 2014 will be a venue for researchers to present and discuss new ideas and concepts, work in progress, and publication-ripe results related to the implementation and application of functional languages and function-based programming. Following the IFL tradition, IFL 2014 will use a post-symposium review process to produce the formal proceedings. All participants of IFL 2014 are invited to submit either a draft paper or an extended abstract describing work to be presented at the symposium. At no time may work submitted to IFL be simultaneously submitted to other venues; submissions must adhere to ACM SIGPLAN's republication policy: http://www.sigplan.org/Resources/Policies/Republication The submissions will be screened by the program committee chair to make sure they are within the scope of IFL, and will appear in the draft proceedings distributed at the symposium. Submissions appearing in the draft proceedings are not peer-reviewed publications. Hence, publications that appear only in the draft proceedings do not count as publication for the ACM SIGPLAN republication policy. After the symposium, authors will be given the opportunity to incorporate the feedback from discussions at the symposium and will be invited to submit a revised full article for the formal review process. From the revised submissions, the program committee will select papers for the formal proceedings considering their correctness, novelty, originality, relevance, significance, and clarity. Submission Details ------------------ Submission deadline draft papers: September 8 Notification of acceptance for presentation: September 10 Early registration deadline: September 11 Late registration deadline: September 17 Submission deadline for pre-symposium proceedings: September 24 26th IFL Symposium: October 1-3 Submission deadline for post-symposium proceedings: December 15 Notification of acceptance for post-symposium proceedings: January 31 2015 Camera-ready version for post-symposium proceedings: March 15 2015 Prospective authors are encouraged to submit papers or extended abstracts to be published in the draft proceedings and to present them at the symposium. All contributions must be written in English. Papers must adhere to the standard ACM two columns conference format. For the pre-symposium proceedings we adopt a 'weak' page limit of 12 pages. For the post-symposium proceedings the page limit of 12 pages is firm. A suitable document template for LaTeX can be found at: http://www.acm.org/sigs/sigplan/authorInformation.htm Papers should be submitted online at https://easychair.org/conferences/?conf=ifl2014 Topics ------ IFL welcomes submissions describing practical and theoretical work as well as submissions describing applications and tools in the context of functional programming. If you are not sure whether your work is appropriate for IFL 2014, please contact the PC chair at samth(a)cs.indiana.edu. Topics of interest include, but are not limited to: • language concepts • type systems, type checking, type inferencing • compilation techniques • staged compilation • run-time function specialization • run-time code generation • partial evaluation • (abstract) interpretation • metaprogramming • generic programming • automatic program generation • array processing • concurrent/parallel programming • concurrent/parallel program execution • embedded systems • web applications • (embedded) domain specific languages • security • novel memory management techniques • run-time profiling performance measurements • debugging and tracing • virtual/abstract machine architectures • validation, verification of functional programs • tools and programming techniques • (industrial) applications Peter Landin Prize ------------------ The Peter Landin Prize is awarded to the best paper presented at the symposium every year. The honoured article is selected by the program committee based on the submissions received for the formal review process. The prize carries a cash award equivalent to 150 Euros. Programme committee ------------------- Sam Tobin-Hochstadt, Indiana University (Chair) Rinus Plasmeijer, Radboud University Nijmegen (Co-Chair) Atze Dijkstra, Utrecht University Colin Runciman, University of York Graham Hutton, University of Nottingham Mary Sheeran, Chalmers University of Technology Patricia Johann, Appalachian State University Matthew Fluet, Rochester Institute of Technology Josef Svenningsson, Chalmers University of Technology Małgorzata Biernacka, University of Wroclaw Peter Achten, Radboud Univerity Nijmegen Laura Castro, University of A Coruña Hai Paul Liu, Intel Labs Kathryn Gray, Cambridge University Lars Bergstrom, Mozilla Research Lindsey Kuper, Indiana University Nicolas Wu, Oxford T. Stephen Strickland, University of Maryland Xavier Clerc, INRIA Venue ----- The 26th IFL will be held in association with the College of Computer and Information Science at Northeastern University. It can be reached quickly and easily by public transport.

1 0

New Functional Programming Job Opportunities
by Functional Jobs 01 Sep '14

01 Sep '14

Here are some functional programming job opportunities that were posted recently: Senior Software Engineer (Functional) at McGraw-Hill Education http://functionaljobs.com/jobs/8737-senior-software-engineer-functional-at-… Cheers, Sean Murphy FunctionalJobs.com

1 0

projects.haskell.org Pipermail not Google-indexed?
by Niklas Hambüchen 01 Sep '14

01 Sep '14

Hi, I noticed that I couldn't find this http://projects.haskell.org/pipermail/quickcheck/2014-July/000158.html on Google. Is the quickcheck list archive, or any of the other sites of projects.haskell.org actually reachable from via any path from some top level web site (like Haskell.org)?

1 0

LFM for Haskell bittorrent effort
by Mateusz Kowalczyk 01 Sep '14

01 Sep '14

Hi, For this or another reason, no bittorrent libraries/clients available today seem to suit my needs: they are either too slow, too memory inefficient, bundled with a client which often can't run in a headless environment or broken in some other way or don't implement all the common BEPs. I came to the conclusion that I'll probably have to write one. Happily, whenever I mentioned the topic in #haskell, there was quite a bit of interest each time so I'm looking to recruit people to join me in this effort. First a brief overlook of what's already available in the Haskell environment: * Combinatorrent[1] – a rather old client, no longer maintained with the last Hackage upload in 2010. Only supports few BEPs and was not able to load in the .torrent file provided by Ubuntu. I have spoken to jlouis who wrote this, you can read the conversation at [2]. He himself says that nowadays you can do better performance wise with available libraries. Additionally, this comes with a client on top rather than just being a library. * conjure – not touched since 2008 * bittorrent – seems to be the closest to what I'd like but it is still incomplete and the library is in limbo. There is a lot of stuff that does not work or is commented out and for various reasons the maintainer is unavailable to help out. I have spoken to the maintainer and he himself would like to redesign the library. That's about it. There seem to be a few related tools for bencoding &c but nothing huge. I think the best way to go about this is to learn from Combinatorrent and bittorrent and start something fresh. I'll outline the goals I personally am looking for even though they might be obvious: * efficient, scalable – the library needs to be able to handle tens of thousands of active (announcing, not necessarily downloading) torrents at once. For reference, libtorrent-rakshasa + rtorrent is able to run about ~10k torrents in about 1GB of memory with low CPU usage. The downside is that the library crashes like no tomorrow and the client itself sucks. A slow library is useless to me but so is a fast but unstable one. * implements all the common BEPs – no use for a library if it doesn't work for a lot of cases. It needs to implement everything from [3] maybe except BEP 8. * sane interface – in the end we need to be able to build clients on top. Fortunately we can leverage Haskell's types to do this whereas the existing C/C++ bittorrent libraries seems to suffer badly here. * resilient – if I wanted a fast library which crashes every ten minutes I'd stick with libtorrent Basically, I'm looking to build a fully usable bittorrent library. Notably, I'm not looking for people to help to write a client (yet!). I plan to start as soon as time allows but it'd be great if there was more than just myself on board. Let me know one way another if you're interested in contributing. If you're just interested in the final product then that's fine too, I could always use more motivation! [1]: https://github.com/jlouis/combinatorrent [2]: http://ircbrowse.net/browse/haskell?id=18701612&timestamp=1406738464#t14067… [3]: http://www.bittorrent.org/beps/bep_0000.html -- Mateusz K.

1 1

Set (Set a) like container - but more efficient?
by Marc Weber 01 Sep '14

01 Sep '14

Does a Set (Set a) like container exist already but which is represented as tree internally, eg A ` - B - C ` - D ` - X - Y which would represent ABC ABD and AXY ? If it does not what would be a nice name to create such container? Marc Weber

3 3

Diony Rosa
by Diony Rosa 01 Sep '14

01 Sep '14

http://www.sarah-aloisi.com/ftpkk/lbqwswuvjc.ocrjttewxqiidnzuutwvyhq

1 0