December 2012 - Glasgow-haskell-users

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

Re: [Haskell-cafe] GHCi + FFI + global C variables
by Brandon Allbery 11 Dec '12

11 Dec '12

On Tue, Dec 11, 2012 at 5:57 AM, Francisco Vieira de Souza < vieira.ufpi(a)gmail.com> wrote: > Hi Simon! Is it not necessary to show the type of igraph_bool_t > igraphhaskell_initialized like > > "int igraph_bool_t igraphhaskell_initialized = 0"? > "igraph_bool_t" uses the _t suffix convention for typedefs in C; in other words, it *is* the type. (And if it weren't, that would be a compile time error, not link time.) -- brandon s allbery kf8nh sine nomine associates allbery.b(a)gmail.com ballbery(a)sinenomine.net unix, openafs, kerberos, infrastructure, xmonad http://sinenomine.net

1 0

GHCi + FFI + global C variables
by Nils 11 Dec '12

11 Dec '12

I'm currently working with a C library that needs to use/modify global C variables, for example: igraph_bool_t igraphhaskell_initialized = 0; int igraphhaskell_initialize() { if (igraphhaskell_initialized != 0) { printf("C: Not initializing. igraphhaskell_initialized = %i\n", igraphhaskell_initialized); return 1; } // initialization } If I compile an example programm using this library everything works fine, but if I try to run the same program in GHCi it dies with the message C: Not initializing. igraphhaskell_initialized = -907777 The value (and apparently the adress of the global variable) is completly off, and I have no idea what is causing this or how to solve this issue and make the library GHCi-friendly. Is it possible to run this code in GHCi at all? Also, since it's a foreign library I obviously cannot just change the C code to simply not use any global variables at all. - Nils

2 1