- ghc-devs - Haskell.org

heres a 32bit OS X 7.8.3 build
by Carter Schonwald 09 Oct '14

09 Oct '14

hey all, I know all of you wish you could run 32bit ghc 7.8.3 on your snazzy mac OS 10.9, so here you are! http://www.wellposed.com.s3.amazonaws.com/opensource/ghc/releasebuild-unoff… $ shasum -a256 ghc-7.8.3-i386-apple-darwin.tar.bz2 1268ce020b46b0b459b8713916466cb92ce0c54992a76b265db203e9ef5fb5e5 ghc-7.8.3-i386-apple-darwin.tar.bz2 is the relevant SHA 256 digest NB: I believe I managed to build it with intree-gmp too! So it wont' need GMP installed in the system (but I could be wrong, in which case brew install gmp will suffice) cheers -Carter

2 4

Re: [GHC] #9628: Add Annotations to the AST to simplify source to source conversions
by Alan & Kim Zimmerman 09 Oct '14

09 Oct '14

Yes, I was thinking last night I need to update the GhcAstAnnotations wiki page. Will do so and clean up. On Thu, Oct 9, 2014 at 5:20 PM, GHC <ghc-devs(a)haskell.org> wrote: > #9628: Add Annotations to the AST to simplify source to source conversions > -------------------------------------+------------------------------------- > Reporter: alanz | Owner: alanz > Type: feature | Status: new > request | Milestone: > Priority: normal | Version: 7.8.3 > Component: Compiler | Keywords: > Resolution: | Architecture: Unknown/Multiple > Operating System: | Difficulty: Unknown > Unknown/Multiple | Blocked By: > Type of failure: | Related Tickets: > None/Unknown | > Test Case: | > Blocking: | > Differential Revisions: D246 | > -------------------------------------+------------------------------------- > > Comment (by simonpj): > > I'm afraid I'm very confused by this thread. > > * There are two different Phab tickets: Phab:D246 is linked to this > ticket, but Phab:D297 (I believe) may supercede it. If so please let's > redirect the "Differential revision" field of this ticket, and explicit > mark the moribund one as moribund. > > * The wiki page GhcAstAnnotations does not appear to reflect any of the > discussion. Indeed it appears to describe only the first bullet from > comment:3 > > * comment:3 identifies two issues, which Alan (in comment:4) agreed were > separate. Yet [http://www.haskell.org/pipermail/ghc- > devs/2014-October/006487.html Neil certainly thinks] that the new > Phab:D297 is exclusively about issue 1. So maybe the new design > encompasses both issue 1 and issue 2? I have no idea. > > * There has been quite a lot of [http://www.haskell.org/pipermail/ghc- > devs/2014-October/006482.html traffic on ghc-devs] that is not captured > anywhere. That's fine: an email list is good for discussion. But my > input bandwidth is low and struggle to make sense of it all. And the > conclusions from the discussion may be useful. > > * Alan has posted a [http://www.haskell.org/pipermail/haskell- > cafe/2014-October/116267.html useful summary] to Haskell Cafe, which isn't > captured on a wiki anywhere. > > * Alan has done some work identifying users for the new features, and > written some email notes about that; again this would be useful to > capture. > > I am too slow to take a big patch and try to reverse-engineer the thought > process that went into it. Would be possible to update the wiki page > (presumably GhcAstAnnotations) to state > * The problem we are trying to solve > * The user-visible (or at least visible-to-client-of-GHC-API) design > * Other notes about the implementation. > > Covering the larger picture about the GHC API improvements you are making > (eg no landmines) would be helpful. Maybe you need more than one page. > > I'm delighted you are doing this. But I don't want to throw a lot of code > into GHC without a clear, shared consensus about what it is we are trying > do to, and how we are doing it. > > Thanks. > > Simon (drowning in review requests) PJ > > -- > Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/9628#comment:12> > GHC <http://www.haskell.org/ghc/> > The Glasgow Haskell Compiler >

1 0

Tentative high-level plans for 7.10.1
by Austin Seipp 09 Oct '14

09 Oct '14

Hi *, Today, Mikolaj and I discussed and plotted out a quick, high-level roadmap for the 7.10.1 release, based on our earlier plans. Consider this the 10,000 foot view (the last one was like a view from space). **The TL;DR** - We think the freeze and branching for major things will happen in _5 to 6 weeks from now_, in early/mid November. The release will happen in Feburary. Developers, please read some code (see below), and get your stuff in! The initial bug list will come next week for you to look at. --------------------------- The not-quite-TL;DR version: We'll get about 4 months of fixes into STABLE. This stability period will come at a typically low-point during the year, when many people will be preoccupied with Holidays. So, we're trying to aim far ahead, and try to give STABLE a long, official 'cooking period'. Feature inclusions after the freeze _are_ negotiable, but not large changes. Expect us to say "No" more often this time around. The STABLE branch will only be touchable by me and Herbert. We do not believe we will ship a 7.8.4 at all, contrary to what you may have seen on Trac - we never decided definitively, but there is likely not enough time. Over the next few days, I will remove the defunct 7.8.4 milestone, and re-triage the assigned tickets. We don't have any expected time for an RC just yet. I will spend the next few days culling the 7.10.1 milestone to contain appropriate tickets. Expect a list of these tickets early next week, with more info. Developers: if you have time, **please** review some code, and get your stuff in too! Petition people to review things of yours. Review things other people wrote, and learn new stuff. High five each other afterwords. Here are the major patches on Phabricator still needing review, that I think we'd like to see for 7.10.1: - D168: Partial type signatures - D72: New rebindable syntax for arrows. - D155: LLVM 3.5 compatibility - D169: Source code note infrastructure - D202: Injective type families - Edward Yang's HEAP_ALLOCED saga, D270 through D293 - D130: Implementation of hsig (module signatures) It is possible not all of these will make it. But I think they're solid priorities to try and land soon. Please let me know if you disagree with this. After I publish the bug list, please also take a look, and use your judgement to include or remove things you think are sensible for 7.10.1 (I trust your judgement, and we can always talk it out later). I think that's all. Here's a full roadmap below from our notes: ----------------------------------- - Expected ETA for 7.10.1: - Roughly Feburary 2015. - Expected code freeze ~5wks - Entails making the stable branch - Tentatively create branch on Nov. 7th. - ~3-4mo's of freeze time for STABLE. - Empirically a low-point in development due to Holidays, but gives us a lot of time. - Cull and probably remove the 7.8.4 milestone. - Simply not enough time to address almost any of the tickets in any reasonable timeframe before 7.10.1, while also shipping them. - Only one, probably workarouadble, not game-changing bug (#9303) marked for 7.8.4. - No particular pressure on any outstanding bugs to release immediately. - ANY release would be extremely unlikely, but if so, only backed by the most critical of bugs. - We will move everything in 7.8.4 milestone to 7.10.1 milestone. - To accurately catalogue what was fixed. - To eliminate confusion. - Cull the 7.10.1 milestone - Currently ~700 tickets. - 31 high tickets. - 1 highest priority ticket. - Bulk of them will need moved out to 7.12.1. - Ask developers/users to move things back in. - Demote any old tickets out of highest according to bug tracker policy. - Alert people these are our priorities. - Go through ONLY high/highest priority tickets for 7.10.1. - Email ghc-devs with plans. - Major tentative patches for 7.10 - D168: Partial type signatures - D72: New rebindable syntax for arrows. - D155: LLVM 3.5 compatibility (not big, but important for users!) - D169: Source code note infrastructure (partially reviewed, Austin to review) - D202: Injective type families - Edward Yang's HEAP_ALLOCED saga, D270 through D293 - D130: Implementation of hsig (module signatures) -- Regards, Austin Seipp, Haskell Consultant Well-Typed LLP, http://www.well-typed.com/

18 35

Warning when deriving Foldable/Traversable using -Wall
by Alan & Kim Zimmerman 08 Oct '14

08 Oct '14

I am not sure how to report bugs against the current development version of GHC. Should this go into Trac? The current HEAD gives a spurious unused declaration when deriving Typable/Traversable Details Compiling against current HEAD (0ed9a2779a2adf0347088134fdb9f60ae9f2735b) Adding test('T9069w', extra_clean(['T9069.o', 'T9069.hi']), multimod_compile, ['T9069', '-Wall']) to testsuite/tests/deriving/should_compile/all.T results in +[1 of 1] Compiling T9069 ( T9069.hs, T9069.o ) + +T9069.hs:5:1: Warning: + The import of ‘Data.Foldable’ is redundant + except perhaps to import instances from ‘Data.Foldable’ + To import instances alone, use: import Data.Foldable() + +T9069.hs:6:1: Warning: + The import of ‘Data.Traversable’ is redundant + except perhaps to import instances from ‘Data.Traversable’ + To import instances alone, use: import Data.Traversable() *** unexpected failure for T9069w(optasm) The file being compiled is -------------------------------------------- {-# LANGUAGE DeriveTraversable #-} module T9069 where import Data.Foldable import Data.Traversable data Trivial a = Trivial a deriving (Functor,Foldable,Traversable) ---------------------------------------------

4 4

Re: [commit: ghc] master: Make Data.List.takeWhile fuse: fix #9132 (d14d3f9)
by Joachim Breitner 08 Oct '14

08 Oct '14

Hi, Am Mittwoch, den 08.10.2014, 06:53 +0000 schrieb git(a)git.haskell.org: > commit d14d3f92d55a352db7faf62939127060716c4694 > Author: Joachim Breitner <mail(a)joachim-breitner.de> > Date: Wed Oct 8 08:53:26 2014 +0200 > > Make Data.List.takeWhile fuse: fix #9132 > > Summary: > Rewrites takeWhile to a build/foldr form; fuses repeated > applications of takeWhile. > > Reviewers: nomeata, austin > > Reviewed By: nomeata > > Subscribers: thomie, carter, ezyang, simonmar > > Projects: #ghc > > Differential Revision: https://phabricator.haskell.org/D322 > > GHC Trac Issues: #9132 nofib’s fft2’s allocs -23%, nice! (otherwise no differences worth mentioning). Greetings, Joachim -- 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

1 0

Windows build broken (again)
by Simon Peyton Jones 08 Oct '14

08 Oct '14

Sigh. The testsuite fails utterly on Windows, with thousands of identical errors =====> tc012(normal) 3039 of 4088 [1, 2677, 88] cd .\typecheck\should_compile && 'C:/code/HEAD/inplace/bin/ghc-stage2.exe' -fforce-recomp -dcore-lint -dcmm-lint -dno-debug-output -no-user-package-db -rtsopts -fno-ghci-history -c tc012.hs -fno-warn-incomplete-patterns >tc012.comp.stderr 2>&1 sh: line 0: cd: .typecheckshould_compile: No such file or directory Compile failed (status 256) errors were: *** unexpected failure for tc012(normal) Presumably this is some kind of Windows escape-character problem. But it has worked fine for years, so what is going on? It's very tiresome dealing with Windows breakage so frequently. A few regression test failures, maybe, but outright breakage is very bad. Simon

6 7

FFI: c/c++ struct on stack as an argument or return value
by Yuras Shumovich 07 Oct '14

07 Oct '14

Hi, Right now ghc's FFI doesn't support c/c++ structures. Whenever we have foreign function that accepts or returns struct by value, we have to create wrapper that accepts or returns pointer to struct. It is inconvenient, but actually not a big deal. But there is no easy workaround when you want to export haskell function to use it with c/c++ API that requires structures to be passed by value (Usually it is a callback in c/c++ API. You can't change it's signature, and if it doesn't provide some kind of "void* userdata", then you are stuck.) I'm interested in fixing that. I'm going to start with 'foreign import "wrapper" ...' stuff. Calling conventions for passing c/c++ structures by value are pretty tricky and platform/compiler specific. So initially I'll use libffi for that (it will work when USE_LIBFFI_FOR_ADJUSTORS is defined, see rts/Adjustor.c). It will allow me to explore design space without bothering about low level implementation details. Later it could be implemented for native (non-libffi) adjustors. Is anybody interested it that? I appreciate any comments/ideas. Right now I don't have clear design. It would be nice to support plain haskell data types that are 1) not recursive, 2) has one constructor and 3) contains only c/c++ types. But it doesn't work with c/c++ unions. Any ideas are welcome. An example how to use libffi with structures: http://www.atmark-techno.com/~yashi/libffi.html#Structures Thanks, Yuras

7 19

oneShot (was Re: FoldrW/buildW issues)
by David Feuer 07 Oct '14

07 Oct '14

Just for the heck of it, I tried out an implementation of scanl using Joachim Breitner's magical oneShot primitive. Using the test scanlA :: (b -> a -> b) -> b -> [a] -> [b] scanlA f a bs = build $ \c n -> a `c` foldr (\b g x -> let b' = f x b in (b' `c` g b')) (const n) bs a scanlB :: (b -> a -> b) -> b -> [a] -> [b] scanlB f a bs = build $ \c n -> a `c` foldr (\b g -> oneShot (\x -> let b' = f x b in (b' `c` g b'))) (const n) bs a f :: Int -> Bool f 0 = True f 1 = False {-# NOINLINE f #-} barA = scanlA (+) 0 . filter f barB = foldlB (+) 0 . filter f with -O2 (NOT disabling Call Arity) the Core from barB is really, really beautiful: it's small, there are no lets or local lambdas, and everything is completely unboxed. This is much better than the result of barA, which has a local let, and which doesn't seem to manage to unbox anything. It looks to me like this could be a pretty good tool to have around. It certainly has its limits—it doesn't do anything nice with reverse . reverse or reverse . scanl f b . reverse, but it doesn't need to be perfect to be useful. More evaluation, of course, is necessary.to make sure it doesn't go wrong when used sanely. David

3 3

Stepping through ghc
by Omar Mefire 07 Oct '14

07 Oct '14

Hi, I'm new to ghc codebase and I'm interested in stepping through the code in order to gain a better idea of how it all works. - Is there a way to load ghc into ghci ? and debug through it ? - What are the ways experienced ghc devs step through the code ? - Any techniques you guys recommend ? - What would your advices be for a newbie to the source code ? Thanks, Omar Mefire,

4 3

Framework failures
by Simon Peyton Jones 07 Oct '14

07 Oct '14

I'm getting three "framework failures" in the testsuite, as below, on Linux. Does anyone have any idea why that might happen? Simon =====> haddock.compiler(normal) 1891 of 4114 [0, 0, 2] *** framework failure for haddock.compiler(normal) do_test exception Traceback (most recent call last): File "/home/simonpj/code/HEAD-3/testsuite/driver/testlib.py", line 764, in do_test result = apply(func, [name,way] + args) File "/home/simonpj/code/HEAD-3/testsuite/driver/testlib.py", line 1035, in stats return checkStats(name, way, stats_file, opts.stats_range_fields) File "/home/simonpj/code/HEAD-3/testsuite/driver/testlib.py", line 1045, in checkStats f = open(in_testdir(stats_file)) IOError: [Errno 2] No such file or directory: './perf/haddock/../../../../compiler/stage2/doc/html/ghc/ghc.haddock.t'

1 0