- Glasgow-haskell-users

SpecConstr and GADTs
by Nicolas Frisby 19 Dec '12

19 Dec '12

I suspect I've found a situation where, to a first approximation, I'd like SpecConstr to run more than once. I'm specializing on GADT constructors that contain coercions, so the constructor-specialized functions have RHSs with refined types. In my situation, those refined types enable simplifications/specializations that eventually result in additional calls that would lead to further constructor-specializations if the eventual calls were somehow already manifest. But it seems that the simplification/specialization only happens after the SpecConstr pass, so the resulting usages don't lead to further constructor-specialized functions. Ticket 2642 http://hackage.haskell.org/trac/ghc/ticket/2642 is the only mention I've seen of the SpecConstr pass being repeated. The more I think about my desired behavior of SpecConstr, the more I suspect that a failure to maximally share the constructor-specializations (leading to possible non-termination) might be a concern if the pass were simply repeated in my particular case. Regarding broader impact, I suspect this situation might arise with heavy uses of single types. Is there any known mechanisms to handle this interaction between SpecConstr and GADTs? I'll be able to provide concrete details about my situation in a few weeks, if anyone is interested. Thanks for your time.

2 1

How to start with GHC development?
by Jan Stolarek 19 Dec '12

19 Dec '12

Dear list, I'm reposting my message from Haskell-cafe here since this seems like a more appropriate place to ask this question. I would like to learn about internals of GHC and contribute to its development in the future. I read a couple of papers that give a very general overview of GHC (chapter from AoS, papers about inliner and multicore support) and I'm thinking what direction should I pursue now. I got the GHC sources and started reading commentary on the wiki, but it seems that entry barrier is very high. Aside from the problem of understanding the whole project organization itself, I also don't have background on implementation of functional languages. In fact I have a rather basic knowledge of compilers in general - I only took Stanford's online course on Compilers at Coursera. I was thinking that perhaps I should read SPJs "Implementing Functional Languages: a tutorial" or "The Implementation Of Functional Languages" book to learn more about theory? On the other hand I don't know if getting stuck in theory for next couple of months is a good idea. I would greatly appreciate any advice and help. Janek

10 25

Suggested policy: use declarative names for tests instead of increasing integers
by Johan Tibell 18 Dec '12

18 Dec '12

Hi, I find our tests to be quite hard to navigate, as the majority have names like tc12345.hs or some such. I suggest we instead use descriptive names like GADT.hs or PrimOps.hs instead. What do people think? -- Johan

6 5

Need workaround for lack of fromIntegral/Int->Word rules in 7.4.2
by Johan Tibell 18 Dec '12

18 Dec '12

I'm trying to work around the lack of some fromIntegral/Int->Word rules in 7.4.2. I tried something like: int2Word :: Int -> Word #if defined(__GLASGOW_HASKELL__) int2Word (I# i#) = W# (int2Word# i#) #else int2Word = fromIntegral #endif {-# RULES "fromIntegral/Int->Word" fromIntegral = int2Word #-} but that didn't work as some fromSmallInteger and integerToWord function calls got inserted before my rule had a chance to fire. Can anyone think of a workaround that would work with 7.4.2? P.S. The reason I want this workaround is that some of my users are stuck on 7.4.2 and this regression is affecting them quite badly, making me want to try to fix it in my library. Cheers, Johan

3 5

building GHC for Slackware/Salix
by tim.beech 17 Dec '12

17 Dec '12

I'm making a GHC package for Salix 14 (which is backwards-compatible with Slackware, so this will be a Slackware package, too). The main thing I'd be grateful for advice on is the overall approach I'm taking to the package. Others I've seen (such as the Arch package) just assume GHC is already present. My build script unpacks the binary distribution for "unknown linux" and builds GHC against that. (Both are version 7.4.2.) I have avoided installing anything else (such as the Haskell Platform) so as to keep as close as possible to the ideal of a package as a transparent, reproducible process that only depends on the source. As far as I can tell from the build prerequisites http://hackage.haskell.org/trac/ghc/wiki/Building/Preparation/Tools the only consequence is that documentation is only created as html, not pdf and ps as well. Though everything seems to work ok, the build as it stands fails three tests: Unexpected failures: lib/Time T5430 [bad stdout] (normal) perf/compiler parsing001 [stat not good enough] (normal) simplCore/should_compile spec-inline [stderr mismatch] (optasm) That is after running the fast version of the test suite, which the documentation says should pass 100%. My second question is, do these results suggest anything as to where the problem may lie, and how important it is? When I then installed the new package and built the Haskell Platform against it (using the build script at http://slackbuilds.org) although the installation nonetheless appeared to be succesful, the build script failed at the very end where it tries to do ghc-pkg recache When I did this manually, I discovered root permissions were needed. Is that normal?

3 4

How do we best make sure {Int,Word,Float,Double} to {Int,Word,Float,Double} conversions stay efficient
by Johan Tibell 17 Dec '12

17 Dec '12

Hi, I've been tracking down a few (unrelated) performance bugs related to conversions between primitive types. What these issues had in common is that some rule failed to fire and the conversion went via Integer, killing performance. How do we best write a test that make sure that fromIntegral conversions between these types don't regress? Is it possible to test the output of the simplifier or do we have to do something less direct, like writing a loop that does such conversions and make sure that the allocation stay low? -- Johan

7 8

Haskell Dynamic Loading with -fllvm
by Nathaniel Neitzke 13 Dec '12

13 Dec '12

Essentially I have a use case that, if worked, would save countless hours in development time. I am writing a scientific computing web service utilizing the Repa and Snap libraries. The Snap framework has a dynamic loader that will load modules on the fly when the source files change. This works excellent! The problem is that the modules must be compiled with full optimizations (including -fllvm) or web service operations take minutes instead of < second to execute at run time. I do not mind the penalty paid for optimized compilation. It is still much faster than recompiling and linking the entire exe from scratch and restarting the server. The problem is when the code is compiled with -fllvm dynamically, it crashes. I believe this is a known issue as listed in this trac - http://hackage.haskell.org/trac/ghc/ticket/4210 NOTE: it says "The LLVM backend doesn't support dynamic libraries at the moment." My question is could anyone point me in the right direction as to what might need to be implemented support for this? Is anyone currently working on it? It would be a huge win for the work I am currently doing, to the point where if I can't find a way to get this working (even if it means diving in and attacking it myself), I may have to switch to another language/platform. Thanks, Nathan

4 3

Hoopl vs LLVM?
by Greg Fitzgerald 13 Dec '12

13 Dec '12

I don't know my way around the GHC source tree. How can I get the list of optimizations implemented with Hoopl? Is there overlap with LLVM's optimization passes? If so, has anyone compared the implementations at all? Should one group be stealing ideas from the other? Or apples and oranges? Thanks, Greg

8 14

Mailing list reorganisation
by Ian Lynagh 12 Dec '12

12 Dec '12

Hi all, Following a recent discussion, we propose to reorganise the GHC-related mailing lists so that we end up with: glasgow-haskell-users For user discussions ghc-devs For developer discussions ghc-commits For automated commit messages from the git repositories ghc-builds For automated nightly build reports ghc-tickets For automated messages from trac We would remove cvs-ghc cvs-libraries cvs-other glasgow-haskell-bugs but leave the archives in place, and for now forwarding messages to cvs-* to ghc-devs, and glasgow-haskell-bugs to ghc-tickets. (cvs-libraries and cvs-other are included in this list, because we think they are mainly used by libraries that GHC HQ maintains, or by GHC's lagging repos of libraries that other people maintain). The initial subscriber lists for ghc-devs, ghc-commits and ghc-builds would be the union of the subscribers of cvs-ghc, cvs-libraries and cvs-other. For ghc-tickets it would be the subscriber list for glasgow-haskell-bugs. Does that sound reasonable? Does anyone have any further questions or comments? Thanks Ian

5 4

ghc-7.6.2 breaks haddock interface...
by Joachim Breitner 12 Dec '12

12 Dec '12

Hi, I built GHC 7.6.2-rc1 for Debian. Unfortunately, we have this: Control files of package ghc-haddock: lines which differ (wdiff format) ----------------------------------------------------------------------- Depends: ghc (= [-7.6.1-3),-] {+7.6.1.20121207-1),+} libc6 (>= 2.11), libffi5 (>= 3.0.4), libgmp10 Installed-Size: [-32917-] {+33044+} Provides: haddock, [-haddock-interface-21-] {+haddock-interface-22+} Version: [-7.6.1-3-] {+7.6.1.20121207-1+} i.e. upstream has bumped the haddock interface number. I really was not expecting this from a minor release. @GHC devs: Is that intentional? I.e., is there really a change to the on-disk format of the .haddock files? Can we expect this to be stable until 7.6.2 final? In general, please only bump the interface number if really required, makes live much easier for us (and probably also for some of your other users). @Debian: If the answer is yes, what should we do? I think I have automated rebuilding everything (at least everything in Darcs) enough to make that not as painful as it used to be, but it would still take some time. On the other hand, it would break Haskell in experimental for some time (maybe a week, optimistically). But then, it is already partly broken. Thanks, Joachim -- Joachim "nomeata" Breitner Debian Developer nomeata(a)debian.org | ICQ# 74513189 | GPG-Keyid: 4743206C JID: nomeata(a)joachim-breitner.de | http://people.debian.org/~nomeata

3 5