- Glasgow-haskell-users

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

13 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 08 Nov '13

08 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 04 Nov '13

04 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

Re: GHC API: modInfoIsExportedName, String -> Name?
by Daniel Trstenjak 20 Oct '13

20 Oct '13

Hi Ranjit, > I should have added that you should call them after compiling the > particular target (or with the environment obtained after compiling > from a particular target) did you do that? I don't compile anything in my context, but I'm just reading the information of already compiled modules/packages. So if I'm using 'lookupRdrNameInModule' instead of 'tcRnLookupRdrName', than I'm getting the desired information, perhaps that's the difference between your and my use case. But now I'm seeing, that my previous profiling was a bit halfhearted and I missed the real hot spot. After adding several cost centres by hand, I'm seeing that getModuleInfo takes up the most time. Does anyone know why that's the case, why getModuleInfo is so costly and if there's an other way to get the exports of a module? Most allocations seem to be done by getModuleInfo, so getModuleInfo seems to create the data structures holding the complete module information. So there's presumably little hope to get this information faster, right? Greetings, Daniel

1 0

GHC API: modInfoIsExportedName, String -> Name?
by Daniel Trstenjak 20 Oct '13

20 Oct '13

Hi, I wanted to use the GHC API to find if a symbol is exported from a module. The function 'modInfoIsExportedName :: ModuleInfo -> Name -> Bool' seems to do what I want, but how do I convert a symbol string into a 'Name'? Thanks for any hints! Greetings, Daniel

3 4

Why cannot inferred type signatures restrict (potentially) ambiguous type variables?
by adam vogt 14 Oct '13

14 Oct '13

Hello, I have code: {-# LANGUAGE FlexibleInstances, MultiParamTypeClasses, ScopedTypeVariables, TypeFamilies #-} class C a b where c :: a -> b instance (int ~ Integer) => C Integer int where c = (+1) c2 :: forall a b c. (C a b, C b c) => a -> c c2 x = c (c x :: b) c2 x = c ((c :: a -> b) x) Why are the type signatures needed? If I leave all of them off, I get: Could not deduce (C a1 a0) arising from the ambiguity check for ‛c2’ from the context (C a b, C a1 a) bound by the inferred type for ‛c2’: (C a b, C a1 a) => a1 -> b from the line: c2 x = c (c x) >From my perspective, it seems that the type signature ghc infers should be able to restrict the ambiguous types as the hand-written signature does. These concerns apply to HEAD (using -XAllowAmbiguousTypes) and ghc-7.6 too. Regards, Adam

3 2