- Glasgow-haskell-users

GHC 7.8.3 release
by Austin Seipp 31 May '14

31 May '14

Hello all, After a long week, I've finally gotten a little time to reply to emails, and I mainly have one question I'd like to ask. First, please direct your attention to this: https://ghc.haskell.org/trac/ghc/query?status=closed&status=merge&status=pa… This is the 7.8.3 milestone, but it only considers things that are: - 1) Fixed - 2) Going to be merged - 3) Are a patch to be still merged. That is, it is a solid representation of the difference between 7.8.2 and the 7.8 branch tip. The question is: when should we do the release? There are several bugs there that seem quite problematic for users - #9045, #7097, #9001, #8768 and #9078 in particular. If these bugs are really problematic (and I sort of feel they are) then the release can happen soon. I can do it within a week from now, and we could punt more to a 7.8.4 release. I ask this because my time to dedicate to GHC is a bit thin right now, so you must help me decide what's important! So please let me know - just a general vote in favor of doing it within some X timeframe (even 'real soon' or 'a week would be great') would be nice. PS: I apologize for the lack of status updates and brief email - my time for GHC has been in very short order the past two weeks in particular, and I've finally just returned to a computer (not mine) for right now to ask this. PPS: This might also impact the 7.10 schedule, but last Simon and I talked, we thought perhaps shooting for ICFP this time (and actually hitting it) was a good plan. So I'd estimate on that a 7.8.4 might happen a few months from now, after summer. -- Regards, Austin Seipp, Haskell Consultant Well-Typed LLP, http://www.well-typed.com/

10 10

Haskell Platform Update?
by Caitlin 31 May '14

31 May '14

Hi all. I was just wondering if an updated release for the Haskell Platform was planned in the neat future? The current schedule lists November of last year as being the time for release candidates.. Thanks, ~Caitlin

2 1

RFC: changes to -i flag for finding source files
by Simon Marlow 30 May '14

30 May '14

I want to propose a simple change to the -i flag for finding source files. The problem we often have is that when you're writing code for a library that lives deep in the module hierarchy, you end up needing a deep directory structure, e.g. src/ Graphics/ UI/ Gtk/ Button.hs Label.hs ... where the top few layers are all empty. There have been proposals of elaborate solutions for this in the past (module grafting etc.), but I want to propose something really simple that would avoid this problem with minimal additional complexity: ghc -iGraphics.UI.Gtk=src the meaning of this flag is that when searching for modules, ghc will look for the module Graphics.UI.Gtk.Button in src/Button.hs, rather than src/Graphics/UI/Gtk/Button.hs. The source file itself is unchanged: it still begins with "module Graphics.UI.Gtk.Button ...". The implementation is only a few lines in the Finder (and probably rather more in the manual and testsuite), but I wanted to get a sense of whether people thought this would be a good idea, or if there's a better alternative before I push it. Pros: - simple implementation (but Cabal needs mods, see below) - solves the deep directory problem Cons: - It makes the rules about finding files a bit more complicated. People need to find source files too, not just compilers. - packages that want to be compatible with older compilers can't use it yet. - you can't use '=' in a source directory name (but we could pick a different syntax if necessary) - It won't work for Cabal packages until Cabal is modified to support it (PreProcess and SrcDist and perhaps Haddock are the only places affected, I think) - Hackage will need to reject packages that use this feature without also specifying ghc >= 7.10 and some cabal-version too. - Are there other tools/libraries that will need changes? Leksah? Cheers, Simon

19 37

GHC 7.8.2 bindist for OS X with Xcode 4
by Christiaan Baaij 30 May '14

30 May '14

The Xcode 5 version of GHC 7.8.2, at http://www.haskell.org/ghc/download_ghc_7_8_2#macosx_x86_64, does not work on my machine where I only have Xcode 4 installed. Under the assumption that there are other people out there who also do not (want to) upgrade to Xcode 5, and don't like building GHC from source either, I've created bindists for GHC 7.8.2 that work with Xcode 4: https://www.dropbox.com/s/v6ax3itgjo0imy9/ghc-7.8.2-x86_64-apple-darwin.tar… https://www.dropbox.com/s/d5xpkoiia2tg0e4/ghc-7.8.2-x86_64-apple-darwin.tar… Is there a process through which I could perhaps get them added to: http://www.haskell.org/ghc/download_ghc_7_8_2#macosx_x86_64 ? I see that there are multiple releases for other platforms as well. -- Christiaan

1 0

Asserting that list fusing kicked in
by Joachim Breitner 26 May '14

26 May '14

Hi, for those of you who don’t follow Planet Haskell and haven’t seen my blog post¹ on it: I have created a (very) small library list-fusion-probe with an identity function fuseThis :: [a] -> [a] that will complain loudly (at run-time, for the time being) if the argument is not fused away. Using it might give you more confidence in that your code really fuses as well as you think it does. Greetings from TFP (where the invited talk by Geoffrey Mainland inspired me to write that), Joachim ¹ http://www.joachim-breitner.de/blog/archives/649-Does-list-fusion-work.html -- Joachim “nomeata” Breitner mail(a)joachim-breitner.de • http://www.joachim-breitner.de/ Jabber: nomeata(a)joachim-breitner.de • GPG-Key: 0xF0FBF51F Debian Developer: nomeata(a)debian.org

2 1

Future of DYNAMIC_GHC_PROGRAMS?
by harry 25 May '14

25 May '14

I need to build GHC 7.8 so that Template Haskell will work without shared libraries (due to a shortage of space). I understand that this can be done by turning off DYNAMIC_GHC_PROGRAMS and associated build options. Is this possibility going to be kept going forward, or will it be deprecated once dynamic GHC is fully supported on all platforms? -- View this message in context: http://haskell.1045720.n5.nabble.com/Future-of-DYNAMIC-GHC-PROGRAMS-tp57497… Sent from the Haskell - Glasgow-haskell-users mailing list archive at Nabble.com.

4 5

Caching intermediate powers in GHC.Float
by Bas van Dijk 16 May '14

16 May '14

Does the following make sense: https://ghc.haskell.org/trac/ghc/ticket/9120 Bas

1 0

vector and GeneralizedNewtypeDeriving
by John Lato 15 May '14

15 May '14

Hello, Prior to ghc-7.8, it was possible to do this: > module M where > > import qualified Data.Vector.Generic.Base as G > import qualified Data.Vector.Generic.Mutable as M > import Data.Vector.Unboxed.Base -- provides MVector and Vector > > newtype Foo = Foo Int deriving (Eq, Show, Num, > M.MVector MVector, G.Vector Vector, Unbox) M.MVector is defined as > class MVector v a where > basicLength :: v s a -> Int etc. With ghc-7.8 this no longer compiles due to an unsafe coercion, as MVector s Foo and MVector s Int have different types. The error suggests trying -XStandaloneDeriving to manually specify the context, however I don't see any way that will help in this case. For that matter, I don't see any way to fix this in the vector package either. We might think to define > type role M.MVector nominal representational but that doesn't work as both parameters to M.MVector require a nominal role (and it's probably not what we really want anyway). Furthermore Data.Vector.Unboxed.Base.MVector (which fills in at `v` in the instance) is a data family, so we're stuck at that point also. So given this situation, is there any way to automatically derive Vector instances from newtypes? tl;dr: I would really like to be able to do: > coerce (someVector :: Vector Foo) :: Vector Int am I correct that the current machinery isn't up to handling this? Thanks, John

5 8

Using mutable array after an unsafeFreezeArray, and GC details
by Brandon Simmons 14 May '14

14 May '14

A couple of updates: Edward Yang responded here, confirming the sort of track I was thinking on: http://blog.ezyang.com/2014/05/ghc-and-mutable-arrays-a-dirty-little-secret/ And I can report that: 1) cloning a frozen array doesn't provide the benefits of creating a new array and freezing 2) and anyway, I'm seeing some segfaults when cloning, freezing, reading then writing in my library I'd love to learn if there are any other approaches I might take, e.g. maybe with my own CMM primop variants? Thanks, Brandon

6 7

HSghc-prim-0.3.1.0.o: unknown symbol 'memcpy'
by M Farkas-Dyck 11 May '14

11 May '14

I just built stock ghc 7.8.1 against musl on Linux x86_64. I get this: $ ghci GHCi, version 7.8.1: http://www.haskell.org/ghc/ :? for help Loading package ghc-prim ... linking ... ghc: /lib/ghc-7.8.1/ghc-prim-0.3.1.0/HSghc-prim-0.3.1.0.o: unknown symbol `memcpy' ghc: unable to load package `ghc-prim' $ memcpy is defined in /lib/libc.a; how can I link it in? I tried -lc and -opt-lc options to ghci, in vain.

2 4