- ghc-devs - Haskell.org

RC Status
by Austin Seipp 20 Jan '14

20 Jan '14

Hello all, I apologize for the lack of updates recently. I'm well aware people are a bit ready to move on, so the good news is we should be able to do so shortly. Simon and I talked last week, and for the RC to go ahead, we've decided to punt a few tickets for the moment. The biggest hurdle is dynamic support on Windows, which we've decided to punt. I have put together a page detailing the current status with some more detail about what's going on: https://ghc.haskell.org/trac/ghc/wiki/Status/GHC-7.8 I spent a lot of time testing my (just merged) branch on several machines. The highlights for interested parties: * OS X looks pretty good across the board, minus a `./validate` bug I need to track down on Mavericks. 10.8 still needs to be tested (this will hopefully happen soon.) Otherwise it seems to be fine. * With the dynamic stuff punted, Windows looks pretty good right now too. There is some minor testsuite fallout I need to investigate. One of Herbert's patches broke the 64bit windows build, and I'm bisecting it. Then I'll test a win64 bootstrap. * Linux, as usual, seems just fine, and I just need to finish the i386 bootstrap. * I need to update some performance numbers. There is one final bug to fix, #7602, which is a performance regression for OS X, but I'm investigating the `./validate` bug on Mavericks first. Once these look green across the board, I speculate I'll begin to make the RC. I expect this to happen ASAP (within the week.) -- Regards, Austin Seipp, Haskell Consultant Well-Typed LLP, http://www.well-typed.com/

6 10

Re: [commit: ghc] master: Re-work the naming story for the GHCi prompt (Trac #8649) (73c08ab)
by Simon Marlow 20 Jan '14

20 Jan '14

On 10/01/14 08:52, git(a)git.haskell.org wrote: > Repository : ssh://git@git.haskell.org/ghc > > On branch : master > Link : http://ghc.haskell.org/trac/ghc/changeset/73c08ab10e4077e18e459a1325996bff1… > >> --------------------------------------------------------------- > > commit 73c08ab10e4077e18e459a1325996bff110360c3 > Author: Simon Peyton Jones <simonpj(a)microsoft.com> > Date: Thu Jan 9 17:58:18 2014 +0000 > > Re-work the naming story for the GHCi prompt (Trac #8649) Thanks for going to the trouble of cleaning this up. I was never happy with how this all worked. The prefix colon in the name (":Interactive") was supposed to avoid the possibility of clashing with a user-defined module, rather like the ":Main" pseudo-module. Could that be a problem with "Ghci1" and so on? What about the "interactive" package? Perhaps these ought to be renamed to something that can't be user-defined? Cheers, Simon

2 1

Re: Pattern synonyms for 7.8?
by Dr. ÉRDI Gergő 20 Jan '14

20 Jan '14

Hi, Wow, so, I thought there would be some back-and-forth, then a decision, then I would go and walk the last mile and then formally submit the patch for review - and now I see that in <2 days all that has passed... Of course I'll make validate pass, I just didn't even know about it. Likewise, I needed the carrot of 7.8 inclusion dangling before me to start writing the user docs. One problem, though, is that I'll be on holiday from tomorrow, so I'll only have time to look into this tonight before next weekend. I'll try my best to fix up validate tonight, and I'll write the docs (which I hope will mostly be an editing job on the wiki) next week. How does that sound? Thanks, Gergo On Jan 8, 2014 3:41 AM, "Austin Seipp" <aseipp(a)pobox.com> wrote: > Hi Gergo, > > Thanks for rebasing your changes. Unfortunately, they do not compile > cleanly with ./validate, which we really need to have working for all > incoming patches. > > In particular, ./validate enables -Werror and a slew of warnings that > you won't normally see during development, which greatly aids in > keeping the code clean. One, for example, is that some of your commits > introduce tabs - we ban tabs and validate errors on them! > > Another: the problem is that in > > https://github.com/gergoerdi/ghc/commit/afefa7ac948b1d7801d622824fbdd75ade2… > , > you added a Monoid instance for UniqSet - but this doesn't work > correctly. The problem is that UniqSet is just an alias for UniqFM > (type UniqSet a = UniqFM a), so the instance is technically seen as an > orphan. Orphan instances cause -Werror failures with ./validate > (unless you disable them for that module, but here we really > shouldn't.) > > The fix is to write the Monoid instance for UniqFM directly in > UniqFM.hs instead. > > Likewise, here's a real bug that -Werror found in your patch in the > renamer (by building with ./validate): > > compiler/rename/RnBinds.lhs:744:1: Warning: > Pattern match(es) are non-exhaustive > In an equation for `renameSig': > Patterns not matched: _ (PatSynSig _ _ _ _ _) > > Indeed, renameSig in RnBinds doesn't check the PatSynSig case! The > missing instance looks straightforward to implement, but this could > have been a nasty bug waiting. > > If you could please take the time to clean up the ./validate failures, > I'd really appreciate it. I imagine it'll take very little time, and > it will make merging much easier for me. An easy way to do it is just > to check out your pattern-synonyms branches, then say: > > $ CPUS=X sh ./validate > > where 'X' is the number of cores, similar to 'make -jX' > > If it fails, you can make a change, and keep going with: > > $ CPUS=X sh ./validate --no-clean > > and rinse and repeat until it's done. > > Note the --no-clean is required, since `./validate` will immediately > run `make distclean` by default if you do not specify it. > > On Tue, Jan 7, 2014 at 5:50 AM, Dr. ERDI Gergo <gergo(a)erdi.hu> wrote: > > On Mon, 6 Jan 2014, Carter Schonwald wrote: > > > >> as long as we clearly communicate that there may be refinements / > breaking > >> changes > >> subsequently, i'm all for it, unless merging it in slows down 7.8 > hitting > >> RC . (its > >> taken long enough for RC to happen... don't want to drag it out further) > > > > > > If that helps, I've updated the version at > https://github.com/gergoerdi/ghc > > (and the two sister repos https://github.com/gergoerdi/ghc-testsuite and > > https://github.com/gergoerdi/ghc-haddock) to be based on top of master > as of > > today. > > > > Bye, > > Gergo > > > > -- > > > > .--= ULLA! =-----------------. > > \ http://gergo.erdi.hu \ > > `---= gergo(a)erdi.hu =-------' > > Elvis is dead and I don't feel so good either. > > _______________________________________________ > > ghc-devs mailing list > > ghc-devs(a)haskell.org > > http://www.haskell.org/mailman/listinfo/ghc-devs > > > > > > -- > Regards, > Austin - PGP: 4096R/0x91384671 >

8 18

unexpected failures expected?
by Mark Lentczner 20 Jan '14

20 Jan '14

Hiho - I just built GHC HEAD on Mac OS X... and make test yields 4 unexpected failures. Is this something I should, er, expect? I'm just trying to calibrate myself for building GHC from source as part of Mac Haskell Platform packaging, and wondering if this (pre-final release) is something to expect, or something I should chase down: OVERALL SUMMARY for test run started at Sun Jan 19 21:02:36 2014 PST 0:33:45 spent to go through 3866 total tests, which gave rise to 16062 test cases, of which 12536 were skipped 26 had missing libraries 3458 expected passes 38 expected failures 0 caused framework failures 0 unexpected passes 4 unexpected failures Unexpected failures: cabal/cabal04 cabal04 [bad exit code] (normal) concurrent/should_run T5611 [bad stderr] (normal) perf/compiler T4801 [stat not good enough] (normal) th TH_spliceE5_prof [bad exit code] (normal) - Mark

2 1

Re: A modest proposal (re the Platform)
by Páli Gábor János 20 Jan '14

20 Jan '14

On Mon, Jan 20, 2014 at 9:29 AM, Andres Löh <andres.loeh(a)gmail.com> wrote: > I can understand the motivation of this proposal, but I'm slightly worried: +1 > (2) Simply because GHC 7.8 is itself so long delayed and so full of > new features, I think it's realistic to assume that quite a few > library glitches will appear even after it's released. Also, GHC bugs > may be found only after formal release (despite all the hammering, the > use of GHC pre release isn't quite comparable with the amount of > testing it gets afterwards; IMHO, there might very well be need for a > GHC 7.8.2). I'm all for trying to get an HP based on GHC 7.8 out as > possible, but how soon would that actually happen, realistically? > Sooner than 6 months from now? I do not think so. Waiting a couple of months after 7.8.1 is released to let the dust settle will not hurt anyway.

1 0

A modest proposal (re the Platform)
by Mark Lentczner 19 Jan '14

19 Jan '14

Looks like GHC 7.8 is pretty near release. And while I know that we really like to have a GHC out for a while, and perhaps see the .1 release, before we incorporate it into the Platform, this GHC, while including many new and anticipated things, seems pretty well hammered on. Combine that with the now two-month late (all my fault) HP release for 2013.4.0.0 isn't slated to really have all that much new in it, in part because it is the same GHC as the last HP release. Now - it would really look foolish, and taken poorly (methinks) if we release a HP this month - only to have GHC 7.8 release early Feb. Folks would really be head scratching, and wondering about the platform. SO - I'm proposing ditching the now late 2013.4.0.0 (I admit, I'm finding it hard to get excited by it!) and instead move right to putting out 2014.2.0.0 - aimed for mid-March to mid-April. This release would have several big changes: - GHC 7.8 - New shake based build for the Platform - Support for validation via package tests - Support for a "server variant" (no OpenGL or other GUI stuff if we had any) - Automated version info w/historical version matrix page - Several significant packages: I'd like to see Aeson at the very least, updated OpenGL stuff I'd also propose changes for the Mac build (though this is obviously independent): - Built from GHC source, not dist. release. (guarantees consistent release) - Only 64bit (I know, controversial...) Thoughts?

3 2

ARM64 cross-compiler and --sysroot GNU C option.
by Karel Gardas 18 Jan '14

18 Jan '14

Folks, just for fun I've built GHC cross-compiler for ARM64 platform using LLVM backend. I've documented it here: https://ghcarm.wordpress.com/2014/01/18/unregisterised-ghc-head-build-for-a… and I'm writing here just to ask if you think adding --with-gcc-sysroot option (or kind of it) to GHC's configure may be a good idea or not (i.e. you consider using shell script wrapper which passes --sysroot option to the GNU C cross compiler perfectly adequate for this job -- like I did in blog post above). See also #7754 which shows the same problem. Thanks! Karel

1 0

RE: [Haskell-cafe] GHC API: runStmt not taking into account reloaded module
by Simon Peyton Jones 17 Jan '14

17 Jan '14

That sounds odd. Can you make a small reproducible test case, open a ticket, and attach the test? Thanks SImon From: Haskell-Cafe [mailto:haskell-cafe-bounces@haskell.org] On Behalf Of JP Moresmau Sent: 14 January 2014 20:14 To: Haskell Cafe Subject: [Haskell-cafe] GHC API: runStmt not taking into account reloaded module It's late here and I'm probably overlooking something stupid, so I'd like if somebody could put my nose on it... I'm using the GHC API to evaluate statements. I use runStmt to get a RunResult, lookupName to get the ID for the bound names, obtainTermFromId to get the term and showTerm to display it. So I can call a function from the loaded module with some parameters and get the result. Good! However, if I reload a module and I change the implementation of the function, runStmt still returns the old value! I know the reload worked because if I added new names, getNamesInScope returns the new names. What do I need to do to make sure the new function definitions are used? I've perused the source code of InteractiveEval and ghci but nothing stood out. I am calling setContext after load. Thanks a million! -- JP Moresmau http://jpmoresmau.blogspot.com/

2 4

[PATCH] platformFromTriple: fix to recognize Solaris triple (i386-pc-solaris2.11)
by Karel Gardas 16 Jan '14

16 Jan '14

--- Cabal/Distribution/System.hs | 2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/Cabal/Distribution/System.hs b/Cabal/Distribution/System.hs index a18e491..4fc76f6 100644 --- a/Cabal/Distribution/System.hs +++ b/Cabal/Distribution/System.hs @@ -89,7 +89,7 @@ osAliases Compat Windows = ["mingw32", "win32"] osAliases _ OSX = ["darwin"] osAliases _ IOS = ["ios"] osAliases Permissive FreeBSD = ["kfreebsdgnu"] -osAliases Permissive Solaris = ["solaris2"] +osAliases _ Solaris = ["solaris2"] osAliases _ _ = [] instance Text OS where -- 1.7.3.2

4 6

Re: [commit: packages/integer-gmp] master: Allocate initial 1-limb mpz_t on the Stack and introduce MPZ# type (7bdcadd)
by Simon Marlow 16 Jan '14

16 Jan '14

On 13/01/14 13:25, git(a)git.haskell.org wrote: > Repository : ssh://git@git.haskell.org/integer-gmp > > On branch : master > Link : http://ghc.haskell.org/trac/ghc/changeset/7bdcadda7e884edffb1427f0685493f3a… > >> --------------------------------------------------------------- > > commit 7bdcadda7e884edffb1427f0685493f3a2e5c5fa > Author: Herbert Valerio Riedel <hvr(a)gnu.org> > Date: Thu Jan 9 00:19:31 2014 +0100 > > Allocate initial 1-limb mpz_t on the Stack and introduce MPZ# type > > We now allocate a 1-limb mpz_t on the stack instead of doing a more > expensive heap-allocation (especially if the heap-allocated copy becomes > garbage right away); this addresses #8647. While this is quite cool (turning some J# back into S#), I don't understand why you've done it this way. Couldn't it be done in the Haskell layer rather than modifying the primops? The ByteArray# has already been allocated by GMP, so you don't lose anything by returning it to Haskell and checking the size there. Then all the DUMMY_BYTEARRAY stuff would go away. Cheers, Simon

3 3