November 2013 - Glasgow-haskell-users

ghc src snapshots
by Jens Petersen 24 Dec '13

24 Dec '13

Are recent source tarball snapshots available somewhere? (I mean more recent than http://darcs.haskell.org/ghcBuilder/uploads/ :) Anyway since I haven't seen any recently, I finally rolled one today and uploaded ghc-7.7.20131005-src.tar.bz2 (11MB) to: http://petersen.fedorapeople.org/ghc/ It seems to build ok for me. :) (I didn't go to the trouble of generating a testsuite tarball too.) Thanks, Jens

1 2

love for hpc?
by Evan Laforge 13 Nov '13

13 Nov '13

Is anyone out there using HPC? It seems like it was gotten into a more or less working if not ideal state, and then abandoned. Things I've noticed lately: The GHC runtime just quits on the spot if there's already a tix file. This bit me when I was parallelizing tests. It's also completely unsafe when run concurrently, mostly it just overwrites the file, sometimes it quits. Sure to cause headaches for someone trying to parallelize tests. You can't change the name of the output tix file, so I worked around by hardlinking the binary to a bunch of new ones, and then doing 'hpc sum' on the results. The hpc command is super slow. It might have to do with it doing its parsing with Prelude's 'read', and it certainly doesn't help the error msgs. And the whole thing is generally minimally documented. I can already predict the answer will be "yes, HPC could use some love, roll up your sleeves and welcome!" It does look like it could be improved a lot with just a bit of effort, but that would be a yak too far for me, at the moment. I'm presently just curious if anyone else out there is using it, and if they feel like it could do with a bit of polishing.

6 6

Adding new library dependencies to GHC
by Alex Ford 12 Nov '13

12 Nov '13

Hi, I've made some changes to the LLVM backend of GHC to make it use llvm-general to output bitcode rather than pretty printing human readable LLVM assembly. However, I've been having trouble linking the required libraries (llvm-general and its transitive dependencies). The steps I've taken so far are to put the required libraries in the build tree under libraries, and added them to the packages file, to PACKAGES_STAGE0 and PACKAGES_STAGE1 in ghc.mk, and to the build depends section in compiler/ ghc.cabal.in. The build fails in phase 1 when trying to link utf8-string (a dependency of llvm-general) during the build of llvm-general, with: Loading package utf8-string-0.3.7 ... <command line>: can't load .so/.DLL for: libHSutf8-string-0.3.7.so (libHSutf8-string-0.3.7.so: cannot open shared object file: No such file or directory) The problem seems to be that with pre-existing library dependencies, the system-wide libraries at /usr/lib/ghc-7.6.3/<libname>/ are pulled in, whereas with the new dependencies, versions within the build tree (e.g. at libraries/utf8-string/dist-install/build/) are tried instead, despite these new libraries being installed globally within the same parent directory and being listed by ghc-pkg (no errors upon ghc-pkg check either). For example, in compiler/stage1/package-data.mk, compiler_stage1_DEP_LIB_DIRS_SEARCHPATH specifies /usr/lib/ghc-7.6.3/bytestring-0.10.0.2, and bytestring links successfully, but for utf8-string specifies <ghc-base-dir>/libraries/utf8-string/dist-boot/build. I've read through the documentation on libraries for GHC but can't figure out how to make this work. Could anyone suggest how I could go about fixing this? As a slightly related question, llvm-general depends on template-haskell. Will this cause problems when building GHC normally, since the stage 1 compiler does not support TH? If so is there any way to compile stage 2 directly using the stage 0 compiler? Many thanks, Alex

2 1

Giving function a larger arity
by Akio Takano 12 Nov '13

12 Nov '13

Hi, I've been trying to get a certain type of programs compiled into efficient code, but I haven't been able to find a good way to do it, so I'm asking for help. Specifically, it involves a library that defines a newtype whose representation is a function. Attached Lib.hs is an example of such a library. It defines a newtype (Builder), and functions (fromInt, mappend) that deal with it. In user code I want to write a (often-recursive) function that produces a value of the newtype (the 'upto' function in arity.hs is an example). The problem is that I know that the resulting value will be used only once, and I'd like GHC to take advantage of it. In other words, I want the 'upto' function to get compiled into something that takes 4 arguments (Int#, Int#, Addr# and State#), rather than a binary function that returns a lambda. I understand that GHC does not do this by default for a good reason. It avoids potentially calling 'slightlyExpensive' more than once. However I need some way to get the larger arity, because the performance difference can be rather large (for example, this problem can add a lot of boxing to an otherwise allocation-free loop). One of my attempts was to have the library expose a function with which the user can tell GHC that re-computation is okay. Lib.rebuild is such a function, and the 'upto_rebuild' function demonstrates how to use it. Unfortunately this approach only worked when the full-laziness optimization was explicitly disabled. This problem happened many times to me. In particular Reader and State monads often triggered it. I'm using GHC 7.6.3. Any advice? Thank you, Takano Akio

5 8

blocking parallel program
by Facundo Domínguez 11 Nov '13

11 Nov '13

Hello, Below is a program that seems to block indefinitely with ghc in a multicore machine. This program has a loop that does not produce allocations, and I understand that this may grab one of the cores. The question is, why can't the other cores take the blocked thread? The program was compiled with: $ ghc --make -O -threaded test.hs and it is run with: $ ./test Program text follows. Thanks, Facundo -------- import Control.Concurrent import Control.Monad import System.Environment main :: IO () main = do y <- getArgs mv0 <- newEmptyMVar mv1 <- newEmptyMVar forkIO $ do takeMVar mv0 putMVar mv1 () loop (y == ["yield"]) putMVar mv0 () takeMVar mv1 loop :: Bool -> IO () loop cooperative = go where go = when cooperative yield >> go

2 5

Annotations
by Simon Peyton-Jones 08 Nov '13

08 Nov '13

I've just noticed that there is no GHC language extension for annotations http://www.haskell.org/ghc/docs/latest/html/users_guide/extending-ghc.html#… That feels like an oversight. Yes, they are in a pragma, but you may get an error message if you compile with a stage-1 compiler, for example. Plus, the language extensions should truthfully report what extra stuff you are using. I'm inclined to add a language extension "Annotations". * Without it {-# ANN ... #-} pragmas are ignored as comments * With it, they are treated as annotations Do you agree? I don't know whether this can (or even should) land in 7.8.1. Do you care either way? Guidance welcome Simon Microsoft Research Limited (company number 03369488) is registered in England and Wales Registered office is at 21 Station Road, Cambridge, CB1 2FB

5 6

GHC error message on type mismatch
by Daniel Trstenjak 08 Nov '13

08 Nov '13

Hello, I don't know if I'm the only one struggeling with this GHC error message on type mismatches or it's because I'm not a full time Haskeller, or because I'm not a native english speaker. Couldn't match type `A' with `B´ Expected type: B Actual type: A My problem is with 'Expected' and 'Actual', that I'm often unsure if the compiler is "expecting" something or if I'm the expecting one and the same goes for "actual". I know that the compiler is the expecting one and that I'm given the actual thing, but it's quite often that I'm looking at this error and have to repeat this reasoning. It's strange, because normaly I can memorize such things quite good, but this one bothers me. Perhaps it would be easier for myself if 'Actual type' would be called e.g. 'Given type', I don't know, that just one of the two has a less generic meaning. Greetings, Daniel

8 9

match_co: needs more cases
by Evan Laforge 07 Nov '13

07 Nov '13

I made some strictifying changes and started getting this msg from ghc: match_co: needs more cases vector-0.10.0.1:Data.Vector.Generic.Mutable.MVector{tc r46} (Sym <(vector-0.10.0.1:Data.Vector.TFCo:R:MutableVector{tc r45})>) <main:Util.TimeVectorStorable.Sample{tc r4e} y{tv a4lK} [tv]> It's not just TimeVectorStorable.Sample (which is indeed stored in Data.Vectors), we also have some mysterious compiler-generated symbols: match_co: needs more cases vector-0.10.0.1:Data.Vector.Generic.Mutable.MVector{tc rQA} (Sym <(vector-0.10.0.1:Data.Vector.TFCo:R:MutableVector{tc rQz})>) <a{tv a6IH} [tv]> I assume this is harmless, but I didn't see any other references to this error on the web or on the ghc trac so maybe it's new?

4 5

7.8.1 RC
by Austin Seipp 03 Nov '13

03 Nov '13

Hello all, First and foremost, I realize that I said an RC was coming on Friday along with a branch, but I've unfortunately been a bit behind the gun this week, and several things more things have come to my attention recently. For the delay, I am very sorry. Here's an update on the most pertinent tickets and what needs to happen. One thing is that Herbert and I would like to upload many of the bootstrap libraries to hackage to coincide with the release, but this requires a server upgrade that should happen quite soon (thanks to Duncan/Herbert.) Herber and I also went over #8305, which should (in our opinion) certainly be part of the RC so issues can be filed, and clearly documented. Herbert has a patch for this, and I'll review it today. Second, the new OS X release, Mavericks (and, by association, XCode 5) seem to be a little confusing at the moment, and I don't have access to these machines quite yet. Only a Lion machine. One reason this is a delay is because I don't quite understand e.g. #8497 and #8493 in particular. There has also historically been some issues with different OS X builds not working on different platforms due to XCode and/or strange ABI issues, so I need to make my own to double check. Preprocessing seems to becoming a hot issue* on the note of #8493, and this also certainly needs attention once I get my hands on a machine. There's been a lot of pain around making all this 'work correctly', and working by proxy is simply becoming difficult I think, so I just need to dig into it a bit once I have my hands on something. Also relevant to this is that I'll be signing the announcement, and giving out tarballs with checksums(!), so some of these issues must be fixed for distribution (like #5987, which I am still investigating.) Finally, I have some incoming patches to fix a few of the critical priority bugs (related to Windows, mostly,) but they need to be polished and I need to investigate some other things related to them (e.g. due to lack of time, I only have a 'very slow path' fix for #8228, which is a bit annoying. And also this new msys2 thing.) * Richard Smith, if you're out there, I should have listened to you on the LLVM list. I'll learn from this one. -- Regards, Austin Seipp, Haskell Consultant Well-Typed LLP, http://www.well-typed.com/

1 0