- Haskell-Cafe - Haskell.org

Looking for a new release manager for cabal
by Johan Tibell 22 Feb '15

22 Feb '15

(bcc: haskell-cafe) Hi, After about 3 years of cabal releases I'm looking for someone else to take over the responsibility as cabal release manager. As a release manager I try to keep on top of pull requests, make releases, and make sure bugs get triaged and bugfixes get release. Anyone interested? -- Johan

1 0

Munich Haskell Meeting, 2015-02-24 @ 19:30
by Christian Neukirchen 21 Feb '15

21 Feb '15

Dear all, Next week, our monthly Munich Haskell Meeting will take place again on Tuesday, February 24 at Cafe Puck at 19h30. For details see here: http://www.haskell-munich.de/dates 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-feb-2015/ Everybody is welcome! cu, -- Christian Neukirchen <chneukirchen(a)gmail.com> http://chneukirchen.org

1 0

FLTK GUI Bindings - Alpha Release
by aditya siram 21 Feb '15

21 Feb '15

I'm pleased to announce the alpha release of Haskell bindings [1] to the FLTK [2] GUI library. On Linux and Mac this package and FLTK 1.3.3 [3] should install pretty smoothly. The library covers about 80+% of API and has 60+ widgets that can be used transparently from Haskell. You can read more about the motivation behind the library, installation instructions and quick start documentation here [4]. The package also comes with 14 demos to show you how to get started. There still isn't any support for Windows because I don't have access to a Windows machine, and don't have any experience with the Windows C/C++ build tools. The code itself should be fully portable. I could use some help here. Please report any issues on the Github page [5]. Hope you enjoy and I'd love any feedback on the install and development process. Thanks! -deech [1] http://hackage.haskell.org/package/fltkhs-0.1.0.0 [2] http://fltk.org [3] http://www.fltk.org/software.php?VERSION=1.3.3&FILE=fltk/1.3.3/fltk-1.3.3-s… [4] http://hackage.haskell.org/package/fltkhs-0.1.0.0/docs/Graphics-UI-FLTK-Low… [5] https://github.com/deech/fltkhs

1 0

Type systems preventing laziness-related memory leaks?
by Eugene Kirpichov 21 Feb '15

21 Feb '15

Hello haskell-cafe, Let me repost here a question I posted to cstheory stackexchange - in hopes that there are more type theory experts here. http://cstheory.stackexchange.com/questions/29518/type-systems-preventing-l… Perhaps the main source of performance problems in Haskell is when a program inadvertently builds up a thunk of unbounded depth - this causes both a memory leak and a potential stack overflow when evaluating. The classic example is defining sum = foldr (+) 0 in Haskell. Are there any type systems which statically enforce lack of such thunks in a program using a lazy language? Seems like this should be on the same order of difficulty as proving other static program properties using type system extensions, e.g. some flavors of thread safety or memory safety.

7 12

Re: [Haskell-cafe] Very large data structures in the heap
by Kim-Ee Yeoh 21 Feb '15

21 Feb '15

On Tue, Feb 17, 2015 at 8:26 PM, Dr. Olaf Klinke < o.klinke(a)dkfz-heidelberg.de> wrote: > On Tue, 17 Feb 2015, Kim-Ee Yeoh wrote: > > >> On Tue, Feb 17, 2015 at 5:05 PM, Dr. Olaf Klinke < >> o.klinke(a)dkfz-heidelberg.de> wrote: >> I'd like to separate serialization (IO) from traversal of the >> stucture (pure), but how can one avoid the entire heap object from being >> built? Can lazyness be exploited? >> >> >> Something I didn't quite understand from your email is whether >> >> 1. the data structure is being constructed and you'd like it >> simultaneously serialized to disk >> >> or >> >> 2. it's already serialized and you'd like to perform pure traversals on >> it. >> >> Problem 1 is one of compute then write, problem 2 is one of read then >> compute. >> >> Lazy I/O, as in unsafeInterleaveIO, excels at 2. >> >> -- Kim-Ee >> >> >> > Both. > > The data structure is a search tree, which is intended to be used multiple > times, so 1. applies. I guess that the only way to circumvent the memory > bottleneck would be to serialize the part of the structure already > constructed and use the already serialized part for constructing the rest, > somehow without de-serializing it again. > To an extent, the virtual memory of a modern operating system solves the memory bottleneck. I'm curious what you were hoping for when thinking of exploiting laziness. If the search tree is truly huge, you'd probably resort to fancy (or fuzzy or both) algorithms to break up the work. > > 2. also applies. Queries to the search tree traverse different paths of > it, but one can not rule out that multiple queries will eventually have > traversed the entire tree. Thus lazily de-serializing it may not be enough > unless the garbage collector disposes of parts of the tree after each > query. Which it won't, if we say something like this: > > search :: FilePath -> IO (Query -> Result) > search treeOnDisk = do > searchtree <- decodeFile treeOnDisk > return (\query -> searchFor query searchtree) > No, gc _will_ reclaim memory if decodeFile uses unsafeInterleaveIO. Take a look at the lazy bytestrings package. p.s. Your search function looks odd. Surely you mean something with the type signature: FilePath -> Query -> IO Result ? -- Kim-Ee

2 1

Pattern match checking for GADTs
by Simon Peyton Jones 20 Feb '15

20 Feb '15

Friends George Karachalas, Tom Schrijvers, Dimitrios Vytiniotis, and I are working on finally cracking the problem of accurately reporting pattern-match overlap and redundancy warnings, in the presence of GADTs. You know the problem; consider vzip :: Vect n a -> Vect n b -> Vect n (a,b) vzip VN VN = VN vzip (VC x xs) (VC y ys) = VC (x,y) (vzip xs ys) data Vect :: Nat -> * -> * where VN :: Vect Zero a VC :: a -> Vect n a -> Vect (Succ n) a Are there any missing equations in vzip? No! But GHC complains anyway. We have lots of Trac tickets about this; e.g. https://ghc.haskell.org/trac/ghc/ticket/3927. We now have a draft paper (wait a week) and a prototype implementation, that fixes the problem. But we need your help. We'd like to try our prototype on real code, not just toy examples. So, could you send George a pointer to any packages you have, or know of, that * use GADTS (or other fancy type features) and * would benefit from accurate pattern-match overlap/redundancy warnings? Specifically: * Where you have had to add a catch-all f _ _ = error "impossible" to silence GHC from saying "missing patterns" * Or where you have added {-# OPTIONS_GHC -fno-warn-missing-patterns #-} to silence the warnings. * Or something else like that. George's email is in cc. Time is short - the ICFP deadline is on 27 Feb. So sooner is better than later for us. But later is better than never. Thank you! Simon

6 6

build troubles with ghc binary
by briand＠aracnet.com 20 Feb '15

20 Feb '15

(i hope this is not a repost - sent it to haskell-cafe-bounces the first time) new thread because i have the details i should have provided in the first place. development system is centos 6.6 but i suspect something's broken because... i built and installed gmp-4.3.2 only to find that it's being build as a 32-bit library and will only build as 32-bits. which is really weird, because 64-bit system: 2.6.32-504.3.3.el6.x86_64 #1 SMP Wed Dec 17 01:55:02 UTC 2014 x86_64 x86_64 x86_64 GNU/Linux however- no problem- i'll simply download the 32-bit version of the ghc binary, which was built on centos no less, and install that instead of the 64-bit version. so i do that, point configure at my gmp thusly ./configure --prefix=/home/denheyer/local --with-gmp-includes=/home/denheyer/local/include --with-gmp-libraries=/home/denheyer/local/lib and get this checking for path to top of build tree... utils/ghc-pwd/dist-install/build/tmp/ghc-pwd: error while loading shared libraries: libgmp.so.3: cannot open shared object file: No such file or directory configure: error: cannot determine current directory ok- i haven't seen it do that before, but it's probably because i'm pointing it away from it's internal libgmp. that's fine, i'll set LD_LIBRARY_PATH. I do that and make install starts to work. yay! and then i get THIS ghc-cabal: Bad interface file: dist-install/build/GHC/CString.hi magic number mismatch: old/corrupt interface file? (wanted 33214052, got 129742) somebody really hates me. so originally i had downloaded the xz file, and even though i figure it's pretty much impossible that the archive was actually corrupted, i decide to download the bzip version just in case. yeah- not surprisingly, the build still breaks. any ideas ?? Thanks, Brian

1 0

FLTK bindings near completion. Need community assistance ...
by aditya siram 20 Feb '15

20 Feb '15

Hi all, I've been working on bindings [1] to the FLTK GUI toolkit [2] and I've come to the point where it's mostly complete but I could use some help from the community before I put it up on Hackage. My hope is to eventually fill the need in the Haskell ecosystem for a native GUI library that: - runs on all platforms - is easily installable - is small and fast - has a minimum of dependencies. Currently this library uses only base, stm, bytestring and c2hs. - is conservative with extensions. Currently the most recent extension required is GADTs. If any of this sounds good to you, I could use some help with: - testing the build on Linux and OSX. This should be as simple as installing FLTK, cloning the repo [1] and running `cabal build`. Better instructions are in included README. - getting it to build on Windows. I unfortunately don't have access to a Windows machine. - getting it to build on older GHC's. I used 7.8.3 because that is what I have, but it should work back to the first version of GHC that introduced GADTs. Unfortunately the included `Setup.hs` is non-trivial and I been having trouble getting it work with versions of Cabal older than 1.20 due to breaking API changes across versions. - building a single library. Currently the C/C++ wrappers and Haskell bindings are two separate statically linked libraries. They are copied to the same location so applications built with this package don't have to know that, but it would be ideal if it was all-in-one. - building a shared library on Mac OSX. Any other feedback you have is totally welcome. Thanks! -deech [1] https://github.com/deech/fltkhs [2] http://www.fltk.org/index.php

4 3

Let's teach GHC idiom brackets!
by Oliver Charles 20 Feb '15

20 Feb '15

Hi friends, Last night I was having a good natter with Chris Done, and the topic of idiom brackets came up. Specifically, Chris' hindent and structured-haskell-mode tools have both recently become aware of the quasiquoter in applicative-quoters <http://hackage.haskell.org/package/applicative-quoters> - allowing one to write ordinary Haskell code but have it formatted/edited as if it wasn't even inside a quasiquoter. However, it's a shame that Chris has to now be aware of this specific quasiquoter just to get his tools to work properly. Furthermore, it's a shame that *everyone* has to do the same whenever they want to manipulate Haskell code. That said, idiom brackets - at least to me - appears to be a very desirable syntax extension. A recent desire for this came to me while working with reactive-banana. As almost everything "interesting" is even an Event or a Behavior, there tends to be a lot of assembling programs with applicative syntax. Another obvious example is when using parser combinators. Therefore, I'd like to propose that we teach GHC about this desugaring, properly. Now, how we do that, and in fact, what I'm even proposing... that's all up for discussion! I spoke briefly with David Christiansen and a few others in the Idris IRC channel last night about their particular variation of idiom brackets, and it seems people are generally happy with that. Copying that almost verbatim is probably the first proposal I'd put forward. This is the first time I've proposed an extension to GHC, so I'll need some guidance to make this happen - both in terms of guiding the discussion through to a proposal, but ultimately implementing it. Perhaps the proposal will be ready for ZuriHac, and some GHC devs could help me work on it there. Anyway, that's enough rambling from me. I would love to hear your thoughts - do you think idiom brackets are a good idea? Do you have a particular tricky case that you think they need to support? I'm all ears. -- Ollie

10 16

Very large data structures in the heap
by Dr. Olaf Klinke 19 Feb '15

19 Feb '15

I have a function that builds a (cyclic) data structure for searching text. The resulting object can be serialized and re-built. Real-world problems would, however, result in a tree with about 10^9 nodes. I take it that standard data type declarations are not very memory-efficient, so my (fully evaluated) search tree would not fit into memory as a heap object. Its serialised form should be of tractable size, e.g. by storing an array of labels and the tree structure as a bit array of parentheses. I'd like to separate serialization (IO) from traversal of the stucture (pure), but how can one avoid the entire heap object from being built? Can lazyness be exploited? Olaf

4 3