October 2013 - ghc-devs

old-time.git/tests/time004.hs is DST-sensitive :-/
by Herbert Valerio Riedel 26 Oct '14

26 Oct '14

Hi *, if anyone wonders, why TEST=time004 suddenly fails: it's sensitive to DST (and depends on your system's TZ-config): http://git.haskell.org/packages/old-time.git/blob/HEAD:/tests/time004.hs For me, the comparison this unit-test checks now suddenly fails, because the DST-switch occurs on different days in 2012 and 2013 in my TZ, i.e. length "Sun Oct 27 10:56:42 CET 2013" /= length "Sat Oct 27 11:56:42 CEST 2012" Does anyone happen to know what the rationale behind this 'time004' unit test was? Cheers, hvr

1 1

More GND + role inference woes
by Edward Kmett 31 Dec '13

31 Dec '13

Ben Gamari was trying to update my linear package to work with GHC HEAD. Along the way he noted an example of the new GND+role inference machinery failing rather spectacularly. http://hackage.haskell.org/package/linear-1.3/docs/src/Linear-Affine.html#P… Note the number of classes that the current proposal would force us to hand implement. =( -Edward

5 20

Simple script to make existing GHC or HP installation work with Xcode 5
by Mark Lentczner 05 Dec '13

05 Dec '13

Friends - I've developed a simple shell script that should enable your existing GHC 7. or HP installation work with Xcode 5. https://gist.github.com/mzero/7245290 Place that script somewhere, make it executable, and run it. *Then follow the instructions it tells you!* You will end up having to run it more than once: First time it will tell you where to install a copy of the script Second time it will patch your GHC settings file(s) The script is safe to install and setup before you upgrade to Xcode 5, as it reverts to "getting out of the way" if it detects Xcode 4 based installation. It has been tested on two machines: - OS X 10.8 and Xcode 4 - OS X 10.9 and Xcode 5 If a few more intrepid souls test it and it works, I'll post instructions in more prominent places! I'll be testing OS X 10.9 and Xcode 4, tomorrow, and expect it should work fine on OS X10.8 with Xcode 5. But looking for reports that it all works. - Mark "Mac Packager" Lentczner

2 1

GHC 7.8 release status
by Simon Peyton-Jones 15 Nov '13

15 Nov '13

Friends The 7.8 release is imminent. This email is to ask abou the status of your contributions. In each case could you update the wiki with the current state of play, and your intentions, including dates. That is, don't put your reply in email: it on the status page below; though by all means send email too! Summary here: http://ghc.haskell.org/trac/ghc/wiki/Status/GHC-7.8 Also : What is missing from the list that should be done? · Patrick Palka: status of ghc -make -j? · Nick: status of your three items? · Pedro/Richard: is all the Typeable stuff, and gcast and friends, finished? · Geoff: what about the new Template Haskell story? · Iavor: when do you think you can merge? · Austin: what about ARMv7? · Edsko/Thomas/Luite: if you want anything for 7.8 it'll have to be jolly soon. At the moment I don't even know the motivation or design, let alone implementation. Could you make a wiki page explaining the proposed design? Is it really important to do this for 7.8? · Dynamic GHCi. I have no idea who is driving this, or how important it is. · Ryan: atomic stuff. All merged? · AMP warnings: David Luposchainsky is driving this. Thanks! Simon Microsoft Research Limited (company number 03369488) is registered in England and Wales Registered office is at 21 Station Road, Cambridge, CB1 2FB

7 10

Restrictions on polytypes with type families
by Richard Eisenberg 12 Nov '13

12 Nov '13

Hi all, GHC doesn't allow type families to be used with polytypes: 1) The right-hand side of a type family instance cannot have a "forall". 2) A type family cannot be applied to a type containing a "forall". 3) A pattern in a type family instance is (oddly) allowed to contain "forall", but this is silly because of (2). Do these restrictions have known reasons for their existence? Or, are there any that are restricted because someone needs to think hard before lifting it, and no one has yet done that thinking? I know, for example, that the unify function in types/Unify.lhs will have to be completed to work with foralls, but this doesn't seem hard. I've run into two separate cases where I've hit this restriction, so this isn't just idle thought. Thanks, Richard

8 15

simd branch ready for review/merge
by Geoffrey Mainland 07 Nov '13

07 Nov '13

The SIMD branch, available as wip/simd, is ready for review/merge. It could use some review---Simon and Simon, I'd be especially grateful if you both had a quick look. Some major points: 1) I have added support for AVX 512, although this is necessarily untested. AVX and AVX2 are also both supported. 2) After the recent churn regarding patching LLVM's GHC calling convention, by default only 128-bit wide SIMD vectors are passed in registers, and then only on X86_64. There is a "hidden" flag, -fllvm-pass-vectors-in-regs, that causes GHC to generate LLVM code that assumes all vectors are passed in registers by LLVM. This can be used with a suitably patched version of LLVM, and if we get LLVM 3.4 patched, we can consider turning it on by default for LLVM 3.4+. This would mean that we couldn't mix LLVM <3.3-compiled object files with LLVM >3.4-compiled object files, but I don't see that as much of a problem. 3) utils/genprimcode has been hacked up to allow us to write vector operations once and have them instantiated at multiple vector types. I'm not thrilled with this solution, but after discussing with Simon PJ, what I've implemented seems to be the minimal reasonable solution to the problem of exploding primop boilerplate. The changes are documented in compiler/prelude/primops.txt.pp. 4) Error handling is sub-optimal. My patch checks to make sure that vector primops can be compiled efficiently based on the current set of dynamic flags. For example, if -mavx is not specified and the user tries to use a primop that adds together two 256-bit wide vectors of double-precision elements, the user will see an error message like: ghc-stage2: sorry! (unimplemented feature or known bug) (GHC version 7.7.20130916 for x86_64-unknown-linux): 256-bit wide floating point SIMD vector instructions require at least -mavx. This is because the only good place to check for this kind of error is during STG->Cmm translation (in compiler/codeGen/StgCmmPrim.hs), and we don't have much of an error handling infrastructure there in contrast to when we're working in the typechecking/renaming monad. If there is a better way/place to do this, please let me know. Thanks, Geoff

4 8

Possible bug related to stm and exceptions
by Andreas Voellmy 07 Nov '13

07 Nov '13

Hi all, I have a program that uses STM heavily and also performs lots of foreign calls. I've noticed that sometimes the program uses 100% CPU indefinitely and uses lots of memory - I see it go up to about 5GB before I kill it. I've grabbed some preliminary samples of stack traces and see lots stm related stuff (e.g. lots of stg_atomically_frame_info and stmCommitTransaction entries). I can pretty reliably get the behavior to happen now by closing a socket that my Haskell program is trying to recv from. When this causes an exception to be raised (something like "recv: resource vanished (Connection reset by peer)") , then this behavior gets triggered. I haven't pinned down the bug yet, but I'm suspecting it is STM related - somehow the exception causes some STM transaction to go wrong. Are there any known bugs that sound similar to this? BTW, this is with GHC 7.6.3 from a recent HP release on OS X. -Andi

4 6

Dynamically loading and unloading (C) object files
by Edsko de Vries 05 Nov '13

05 Nov '13

Hi guys, We started experimenting with dynamically loading and unloading C object files (using the GHC API). I have a simple example with an object file exporting a single symbol "f"; I have two versions of the object file; in the first one, f is defined int f() { return 1234; } The second one uses the value "4321" instead. I can dynamically load and unload these object files (using "linkObj" and "unlinkObj" from "ObjLink"). I can load the first, dynamically compile some Haskell code that imports this symbol, then upload this object file and load the second, and as long as I make sure that the Haskell code gets recompiled (perhaps a relink step suffices, haven't experimented an awful lot yet) it can then interact with the second object file. All this is good news -- in fact, it is more than we had hoped for, because ghci does not allow dynamically unloading or loading any object files at all. Object files specified on the command line are handled in initDynLinker and the ghci top-level function doesn't even get to see them, and we cannot load object files from inside a ghci session. So that leads me to wonder: are there limitations that we should be aware of? Have I simply been lucky so far? Any points or suggestions for things to try would be appreciated, Edsko

4 4

Why do we put GMP allocations on GHC heaps?
by Gergely Risko 04 Nov '13

04 Nov '13

Dear GHC gurus, I've been looking into how GHC uses GMP (with the hidden agenda of taking the work of replacing it with something that is BSD license compatible and so can be linked in and shipped statically by default). I think I more or less understand how GMP memory is managed and how the GC works together with it. Actually understanding the "how" was not that hard, everything is quite clearly commented. What I couldn't find any reference for is the "why". Why does GHC do this? Would it be possible to just not do this and let GMP malloc and free for itself (obviously we would have to call mpz_free here and there, but that seems doable). I have multiple ideas, but don't know which one (if any) is correct: - performance reasons, - memory defragmentation reasons, - GHC GC moves around stuff and that would somehow break, - the previous one + threads + race conditions. Second question: let's assume for a moment that we don't have any licensing issues with a GMP like library, can be linked statically into GHC, but we decide to go with the same allocation methodology as with GMP. Am I right when I think that linking statically solves the technical issues too. More concretely: openssl BN uses the openssl_malloc function can only be overridden openssl wide. But if we link statically, than this override won't affect external openssl library bindings, because the openssl symbols in our object files won't even be exported, right? Third question: is replacing with openssl bn an acceptable path to you guys? I saw that 6 years ago there were work on getting integer-simple performance wise good enough to be the default and then adding other bignum libraries externally, but none of this happened. I see how sexy project it is computer science wise to write a bignum library in Haskell, but will we really do it? Thanks, Gergely (errge)

9 21

TemplateHaskell usage of Annotations
by Gergely Risko 30 Oct '13

30 Oct '13

Hi, In the recent weeks I've been working on making it possilbe to use Annotations (both generate and reify) from TemplateHaskell. We've hit some gray area where design decisions were needed during the reviews. SPJ asked me to write up a wikipage on my use-case and the approach that is taken in the current patches, so we can discuss alternative ideas, problems and questions openly. http://ghc.haskell.org/trac/ghc/wiki/TemplateHaskell/Annotations Therefore, if you're interested please use this thread, the bug tracker or the wiki to comment on these issues! Thanks, Gergely Risko

3 4