- Glasgow-haskell-users

Chimeric syntax
by Scott Michel 29 Apr '09

29 Apr '09

I've been hacking along on a NetBeans Haskell plugin (*) Looking at Parser.y.pp, because both Eclipse and NetBeans work with antlr, it seems like there are interesting cases in which chimeric constructions parse correctly. Here's an example: class ParsedModule m where let { a = 1; b = 2; } in a + b :: Int :: Int This is mostly accepted by ghc, which complains with an invalid type signature. This got me to thinking that either ghc has issues or I have some fundamental misunderstanding of Haskell syntax. Or, maybe I should use someone else's grammar. -scooter (*) Don't tell me about eclipsefp2: I know already. It's the Monty Python parrot of Haskell IDE support. And the code is about as Teutonic as one can get. :-)

3 3

6.10.3 plans
by Ian Lynagh 27 Apr '09

27 Apr '09

Hi all, Due to some problems with the handling of ^C in ghci, we are planning to do a 6.10.3 release. The idea is that, rather than being a full-blown release process, including all the various fixes that have been made since 6.10.2, we will only do what is necessary to resolve the ^C issue. By keeping the changes to a minimum, we will minimise the amount of testing, release-note writing, etc that is necessary. An exception to this rule is that we will probably also rebundle time in the bindists, as that has little chance of breaking anything else. There are actually two problems with ^C. One is due to the changes in the signal handling in ghci, and we will fix that. The other is that, on some platforms (including x86/Linux), the interaction between editline and GHC means that pressing ^C causes a segfault. Given all the other issues that people have had with editline, we plan to use haskeline in 6.10.3 instead. We already planned to do this for 6.12, but we think that it makes sense to do it sooner rather than later. The plan is: * Add haskeline and deps as boot packages * Move the interactive modules from the ghc package to the ghc-bin package. This means that the ghc package will not depend on the new boot packages, so there will not be any problems with upgrading them. Any comments? Thanks Ian

9 14

Re: Threads and memory management
by Jost Berthold 27 Apr '09

27 Apr '09

> Message: 8 > Date: Fri, 24 Apr 2009 19:20:46 +0200 > From: Johannes Waldmann <waldmann(a)imn.htwk-leipzig.de> > Subject: Threads and memory management > To: "glasgow-haskell-users(a)haskell.org" > <glasgow-haskell-users(a)haskell.org> > Message-ID: <49F1F4EE.8070306(a)imn.htwk-leipzig.de> > Content-Type: text/plain; charset="iso-8859-1" > > Dear all, > > I was wondering what is the current status of the ghc RTS > with respect to threading. Is it true that the allocator > and deallocator (garbage collector) are still single-threaded? > > > I made this example: > ... > Well, then, if the two Haskell threads are (nearly) completely > independent like the above, it would be better to compile and run > two separate executables and have them communicate via the OS (pipe or > port). But that shouldn't be! (the OS being better than Haskell) > > Is there was a way of partitioning the memory (managed by the ghc RTS) > in totally independent parts that each have their stand-alone > memory management. Of course then all communication > had to go via some Control.Concurrent.Chan, > but that should be fine, if there is little of them. > > Well, just some thought. This idea can't be new? > Tell me why it couldn't possibly work ... > > J.W. Hello everybody, Since I did not see any other replies, I thought I might give you some pointers to more information. Other people will perhaps follow up with more details. In all, quite a few things are recently going on about threading in the GHC world, and it is even difficult to keep the oversight. - GHC has undergone a big overhaul with respect to threading support since last September. I have started this work at Microsoft Research last summer, and a lot more has been done by Simon Marlow since. There are forthcoming papers (mainly one submitted to ICFP) about this work. The main focus here was the shared-heap implementation of the Glasgow-parallel Haskell programming model (see http://www.macs.hw.ac.uk/~dsg/gph/ , mainly the paper here: http://www.macs.hw.ac.uk/~dsg/gph/papers/html/Strategies/strategies.html) This programming model is supported in GHC versions since 2004 already, but should now deliver much better performance. That said, the vast majority of the latest GHC optimisations carried out in the GHC HEAD aim at improving thread performance (the explicit basis of the more implicit programming model), and thus relate directly to what you observe. The version you have tested with is GHC-6.10.2, which does not include substantial threading optimisations. - a related question is tool support for parallel performance tuning. Very recently, GHC (HEAD) supports a visual post-mortem analysis, and a graphical tool "ThreadScope" has been developed by Satnam Singh and others. http://raintown.org/?page_id=132 There is a related posting in glasgow-haskell-users (11 March). - GHC has parallel garbage collection since 2007 already. However, recent work showed that this parallel GC sometimes hampers performance, in particular on Linux systems. See this thread for more: http://www.haskell.org/pipermail/glasgow-haskell-users/2009-April/017050.ht… - about your remark that separate OS processes should communicate, rather than having the Haskell RTS manage all threads: yes, there are programming models around which aim at parallel Haskell with distributed heap. Aside from the older GpH cluster implementations, you might have a look at the language Eden: http://www.mathematik.uni-marburg.de/~eden/?content=paper (and personally, I might apologise for the suboptimal web presence...) Using Eden (and its implementation) would be a way to realise the model you propose, communicating processes with separate heaps, but managed by a common parallel runtime system and programmed in one single program. Let me add that Eden also provides a tool with features very similar to what recently became "ThreadScope". Interestingly, a number of recent experiments have shown that Eden has competitive performance to the shared heap GpH implementation when executed on multicores, delegating all communication to the underlying middleware (most commonly PVM). Early papers discussing alike results have been published recently or are in preparation. http://www-fp.cs.st-and.ac.uk/~kh/mainICPP09.pdf I strongly support the idea to collect all this related information systematically! Kickoff is already present here: http://haskell.org/haskellwiki/Performance/Parallel However, the question is where to start... the field is indeed very broad, and the page above will surely focus on GHC rather than general ideas. So I hesitate in dropping all this information into the wiki and rather send a mail for now. Cheers Jost Berthold

2 1

Re: Newby question re quicksort
by leledumbo 27 Apr '09

27 Apr '09

I think you miss something important here: quickslop :: (Ord a) => [a] ->[a] quickslop [] = [] quickslop (x:xs) = quickslop [a | a <- xs, a <= x] ++ [x] ++ quickslop [b | b <- xs, b > x] -- View this message in context: http://www.nabble.com/Newby-question-re-quicksort-tp23250159p23250345.html Sent from the Haskell - Glasgow-haskell-users mailing list archive at Nabble.com.

1 0

Some suggestion for "mutually recursive modules" problem.
by Andy Stewart 26 Apr '09

26 Apr '09

Dear GHC developers: First thanks for your work with GHC! And i have suggestion for "mutually recursive modules" problem: Now GHC use .hs-boot fix "mutually recursive modules" problem, yes it can work, but it not pretty. So GHC can fix this problem automatically at next release version? And programmer not need write .hs-boot file, then programmer's life will be more easier. Thanks! -- Andy

2 1

Static library to redefine entrypoint
by Philip K.F. Hölzenspies 25 Apr '09

25 Apr '09

Dear GHCers, I am trying to write a wrapper library for lab work to give to students. My problem is, that the libraries I use require initialization that I really want to hide from our students. The wrapper I'm writing is compiled to a static library and installed with cabal, so students can just "ghc --make" or "ghci" their sources. Here comes the problem: I want to define main and let students just define labMain as an entry point to their program. How can I have my library use "labMain" without a definition? Keep in mind that I want to give them a cabalized library that they can just link to, so I can't give them a template file that they fill and compile together with my code. Is it at all possible to have "external" functions and letting the linker sort stuff out? Regards, Philip

3 3

writeFile/readFile on multiple threads leads to error
by Neil Mitchell 24 Apr '09

24 Apr '09

Hi, I've got a multi-threaded application which occasionally generates failures in openFile. I haven't been able to reproduce the errors reliably, the code is way too large to send over, and any small attempts at invoking the same problem don't seem to work. Despite the uselessness of the bug report, I thought I'd share what I've seen and how I fixed it. I have many threads, which read and write files. Every so often one thread will write a file, then another thread will read the same file - but fail during the open call. There are locks to ensure that the write call finishes before the read call begins. I modified the code to give: do print ("READ START",x) ; res <- readFile x ; print ("READ STOP",x) ; return res do print ("WRITE START",x); writeFile x src ; print ("WRITE STOP",x) I then get on the console: WRITE START foo WRITE STOP foo READ START foo openFile doesn't have permission to open foo. The writeFile/readFile are happening in different threads, and they usually succeed - but not always. The bug seems to go away when I add performGC just after writeFile. My guess is that something in the openFile/hClose pair isn't really closed until a garbage collection happens. All this is using GHC 6.10.2 on XP through Cygwin. I'm happy to supply more details if you can think of anything that will help, Thanks Neil

6 11

Re: [Haskell-cafe] HPong-0.1.2 fails to compile in Debian ghc 6.10.1
by John Goerzen 24 Apr '09

24 Apr '09

Ahn, Ki Yung wrote: > I don't know the exact reason but this should not fail since I have > Debian packaged ghc 6.10.1 and OpenGL-2.2.1.1 on my system. > > I think this is because the filename of the OpenGL shared library is > /usr/lib/libGL.so.1 rather than libGL.so. This is why we have two No. Do not manually create the symlink. It sounds like you don't have the -dev packages for OpenGL installed. You should install them and then you should be OK.

3 2

No "last core parallel slowdown" on OS X
by Dave Bayer 22 Apr '09

22 Apr '09

I'm a huge fan of the recent paper http://ghcmutterings.wordpress.com/2009/03/03/new-paper-runtime-support-for… which put me over the top to get started writing parallel code in Haskell. Parallel code is now integral to my and my Ph.D. students' research. For example, we recently checked an assertion for the roughly 69 billion atomic lattices on six atoms, in a day rather than a week, using perhaps 6 lines of parallel code in otherwise sequential code. When you're anxiously waiting for the answer, a day is a lot better than a week. (The enumeration itself is down to two hours on 7 cores, which astounds me. I see no reason to ever use another language.) In that paper, they routinely benchmark N-1 cores on an N core Linux box, because of a noticeable falloff using the last core, which can do more harm than good. I had confirmed this on my four core Linux box, but was puzzled that my two core MacBook showed no such falloff. Hey, two cores isn't representative of many cores, cache issues yada yada, so I waited. I just got an EFi-X "boot processor" (efi-x.com) working on a nearly identical quad core box that I built, and I tested the same computations with OS X. For my test case, there's a mild cost to moving to parallel at all, but... Compared to 2 cores, using 3, 4 cores on a four core Linux box gives speedups of 1.37x, 1.38x Compared to 2 cores, using 3, 4 cores on an equivalent four core box running OS X gives speedups of 1.45x, 1.9x Here 1.5x, 2.0x is ideal, so I'm thrilled. If we can't shame Linux into fixing this, I'm never looking back. How true is this for other parallel languages? Haskell alone is perhaps too fringe to cause a Linux scandal over this, even if it should... The EFi-X boot processor itself is rather expensive ($240 now), and there's sticking to a specific hardware compatibility list, and I needed to update my motherboard BIOS and the EFi-X firmware, but no other fiddling for me. These boxes are just compute servers for me, I would have been ok returning to Linux, but not if it means giving up a core. People worry about compatibility, "I sensed a softness in the surround sound in game X...", but for me the above numbers put all this in perspective. Another way to put this, especially for those who don't have a strong preference for building their own machines, and can't wait for Linux to get its act together: If you're serious about parallel Haskell, buy a Mac Pro.

7 14

Using FFI for .NET
by Guilherme Oliveira 22 Apr '09

22 Apr '09

Hi guys, I'm new to haskell and I'm trying to make some calls to static methods of the Microsoft .NET framework with GHC 6.10.2 but I'm getting the follwoing error: GHC error in desugarer lookup in main:Main: > Failed to load interface for `GHC.Dotnet': > There are files missing in the `base' package, > try running 'ghc-pkg check'. > Use -v to see a list of the files searched for. > ghc: panic! (the 'impossible' happened) > (GHC version 6.10.2 for i386-unknown-mingw32): > initDs IOEnv failure > My haskell code is this: {-# LANGUAGE ForeignFunctionInterface #-} module Main where import Prelude import Foreign foreign import dotnet "static foo" foo :: Int -> Int main = do print (foo 5) To build the code above I'm doing like this: ghc -fvia-C Main.hs Am I forgeting something? Does this version of GHC supports FFI for .NET? Regards, Guilherme Oliveira MSc Student, UFPE - Brazil

2 1