- ghc-devs - Haskell.org

Getting error about unused instances during "sh validate"
by Alfredo Di Napoli 13 Jun '14

13 Jun '14

Hello guys, am I the only one to get the following when I run "sh validate"? libraries/base/Data/Maybe.hs:139:1: Warning: Defined but not used: ‘mapMaybeFB’ <no location info>: Failing due to -Werror. make[1]: *** [libraries/base/dist-install/doc/html/base/base.haddock] Error 1 make[1]: *** Waiting for unfinished jobs.... make: *** [all] Error 2 I'm working on this ticket, but I can't see how that can be related: https://ghc.haskell.org/trac/ghc/ticket/8226 Thanks! Alfredo

2 3

HEADS-UP: diagrams does not compile with HEAD (regressions)
by Gabor Greif 12 Jun '14

12 Jun '14

Devs, as of recently GHC HEAD stopped building the diagrams library. Several prerequisite libs also fail to compile. A specific error message appears in an attoparsec issue <https://github.com/bos/attoparsec/issues/67>, for which I have submitted a workaround. But as Herbert cautiously points out, this could be a recent GHC bug surfacing. The symptoms of the bug seem to be that GHC complains about the usage of (~) type equality operation, but there is no reference to that type operator in the source code. To work around the problem it suffices to add -XGADTs or -XTypeFamilies. Does this ring any bells? Can automatized tests catch such things in the future? Cheers, Gabor

4 7

Re: GHC/cabal release procedures, and Stackage
by Joachim Breitner 11 Jun '14

11 Jun '14

Hi Michael, Am Samstag, den 07.06.2014, 21:06 +0300 schrieb Michael Snoyman: > If there was a daily snapshot build, I would be happy to set up some > kind of regular process to download that snapshot and do a Stackage > run on it. I'm currently blocked on this kind of activity, since I > can't get a successful GHC 7.8 build due to my system using the Gold > linker. That would be great, both for GHC and for people who want to have their packages work on GHC HEAD without manually monitoring it. There is http://deb.haskell.org/ which should produce daily debian packages for Debian wheezy. I guess if you are building on that platform, such packages are easiest to use (as you need no particular tooling to update and install). http://deb.haskell.org/dailies/latest/ is currently lagging due to temporary full disk, but I hope that by tomorrow, we have a new build. There used to be daily snapshot builds at http://darcs.haskell.org/ghcBuilder/uploads/ but that is defuct (Can someone remove the link from http://www.haskell.org/ghc/download) I wonder if the “new” builder infrastructure at http://haskell.inf.elte.hu/builders/ assembles the snapshots somewhere, then you can use them. Or you can build GHC yourself as part of the stackage run. 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

3 2

Re: Windows breakage (+patch)
by Sergei Trofimovich 11 Jun '14

11 Jun '14

On Wed, 11 Jun 2014 21:35:57 +0300 Sergei Trofimovich <slyfox(a)gentoo.org> wrote: > On Wed, 11 Jun 2014 08:18:30 +0000 > Simon Peyton Jones <simonpj(a)microsoft.com> wrote: > > > Stefan, Guys > > This commit breaks the Windows build (ie my laptop) > > > > commit 9fd507e5758f4141ac2619f0db57136bcab035c6 > > > > Author: Sergei Trofimovich <slyfox(a)gentoo.org> > > > > Date: Fri May 23 23:58:06 2014 +0300 > > > > > > > > Raise exceptions when blocked in bad FDs (fixes Trac #4934) > > The breakage is this: > > > > C:/code/HEAD/rts/dist/build/libHSrts.a(RtsStartup.o):RtsStartup.c:(.text+0x2aa): undefined reference to `base_GHCziEventziThread_blockedOnBadFD_closure' > > The reason is, I think that that this line in RtsStartup.c should be inside the guard #ifndef mingw32_HOST_OS > > > > getStablePtr((StgPtr)blockedOnBadFD_closure); > > I'd do that myself but I am not confident that the fix is correct; and I would like to add a comment to explain why the getStablePtr is non-windows-only. > > Can someone do this, please? > > Oh, I've missed the fact GHC.Event.Thread in a non-windows thing. > The whole patch was for posix-only platform, but i tried to export > that exception for all platforms. > > CCed Simon M. > > There is 2 routes: > a) move an exception a common module to all platforms. > For example to Foreign.C.Error (I've started to prepare a patch) To avoid import loops and make things clear I've moved it to GHC.Exception.RTS (other from-rts exceptions can be pushded there as well) Patch is in attach. Please review. Thank you! -- Sergei

1 0

Re: [commit: ghc] master: Update mod73 test output (1178fa4)
by Richard Eisenberg 11 Jun '14

11 Jun '14

This test case is failing on my machine, too. Is it perhaps possible to sort the output to avoid these wibbles? I looked at the code and it's not immediately obvious to me the best place to do this... Thanks, Richard On Jun 6, 2014, at 10:09 AM, git(a)ghc.haskell.org wrote: > Repository : ssh://git@git.haskell.org/ghc > > On branch : master > Link : http://ghc.haskell.org/trac/ghc/changeset/1178fa4ada1ac054976f3abb2e303ad42… > >> --------------------------------------------------------------- > > commit 1178fa4ada1ac054976f3abb2e303ad42653e303 > Author: Joachim Breitner <mail(a)joachim-breitner.de> > Date: Fri Jun 6 15:03:36 2014 +0200 > > Update mod73 test output > > to what I observe on travis and on my validate machine, even though my > local tree produces the previous output. > > >> --------------------------------------------------------------- > > 1178fa4ada1ac054976f3abb2e303ad42653e303 > testsuite/tests/module/mod73.stderr | 4 ++-- > 1 file changed, 2 insertions(+), 2 deletions(-) > > diff --git a/testsuite/tests/module/mod73.stderr b/testsuite/tests/module/mod73.stderr > index d19a032..576b0e3 100644 > --- a/testsuite/tests/module/mod73.stderr > +++ b/testsuite/tests/module/mod73.stderr > @@ -2,6 +2,6 @@ > mod73.hs:3:7: > Not in scope: ‘Prelude.g’ > Perhaps you meant one of these: > - data constructor ‘Prelude.GT’ (imported from Prelude), > + data constructor ‘Prelude.LT’ (imported from Prelude), > data constructor ‘Prelude.EQ’ (imported from Prelude), > - data constructor ‘Prelude.LT’ (imported from Prelude) > + data constructor ‘Prelude.GT’ (imported from Prelude) > > _______________________________________________ > ghc-commits mailing list > ghc-commits(a)haskell.org > http://www.haskell.org/mailman/listinfo/ghc-commits >

1 0

Hashes for download files
by Yitzchak Gale 11 Jun '14

11 Jun '14

Perhaps it would be a good idea to post hashes on the download site for each downloadable file, to make it easier to verify that you have the genuine article. Thanks, Yitz

1 0

(drop)CommonPrefix: ccs call implementation
by Maarten Faddegon 11 Jun '14

11 Jun '14

Dear list, I am reading up on cost centre stacks. Simon Marlow's "solving an old problem"-slides is the more recent resource I could find. On slide 43 he describes a call function implemented as: > call Sapp Slam = foldr push Spre Slam’ > where (Spre, Sapp’, Slam’) = commonPrefix Sapp Slam However in rts/profiling.c the following is written: > Set CCCS when entering a function. > > The algorithm is as follows. > > ccs ++> ccsfn = ccs ++ dropCommonPrefix ccs ccsfn > > where > > dropCommonPrefix A B > -- returns the suffix of B after removing any prefix common > -- to both A and B. > > e.g. > > <a,b,c> ++> <> = <a,b,c> > <a,b,c> ++> <d> = <a,b,c,d> > <a,b,c> ++> <a,b> = <a,b,c> > <a,b> ++> <a,b,c> = <a,b,c> > <a,b,c> ++> <a,b,d> = <a,b,c,d> For the given examples Simon's proposal would result in different stacks: <>, <d>, <a,b>, <a,b,c> and <a,b,d>. Has the implementation changed since Simon Marlow gave his talk? If so, is there something I can read on the motivation behind this change? Or do I maybe misinterpret the slides? Thank you, Maarten Faddegon

3 3

Windows breakage
by Simon Peyton Jones 11 Jun '14

11 Jun '14

Stefan, Guys This commit breaks the Windows build (ie my laptop) commit 9fd507e5758f4141ac2619f0db57136bcab035c6 Author: Sergei Trofimovich <slyfox(a)gentoo.org> Date: Fri May 23 23:58:06 2014 +0300 Raise exceptions when blocked in bad FDs (fixes Trac #4934) The breakage is this: C:/code/HEAD/rts/dist/build/libHSrts.a(RtsStartup.o):RtsStartup.c:(.text+0x2aa): undefined reference to `base_GHCziEventziThread_blockedOnBadFD_closure' The reason is, I think that that this line in RtsStartup.c should be inside the guard #ifndef mingw32_HOST_OS getStablePtr((StgPtr)blockedOnBadFD_closure); I'd do that myself but I am not confident that the fix is correct; and I would like to add a comment to explain why the getStablePtr is non-windows-only. Can someone do this, please? Thanks Simon

1 0

Re: GHC/cabal release procedures, and Stackage
by Joachim Breitner 10 Jun '14

10 Jun '14

Hi, Am Sonntag, den 08.06.2014, 21:25 +0300 schrieb Michael Snoyman: > That's great news, thanks! I'll try to get a test going with that. Another benefit of this would be that it is more likely that $ cabal install criterion --with-compiler=.../ghc/inplace/bin/ghc-stage2 works, which would be very handy when developing on GHC head (currently it fails to compile attoparsec, as reported by Gabor). 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

SV: GHC MinGW distribution
by Niklas Larsson 10 Jun '14

10 Jun '14

I think this is a great idea, I was thinking of creating a ticket for it after 7.8.3 was out of the way. In my case the reason is C++11 support, LLVM has 4.7 as the minimum version now. Just having a script in git and downloading the tarballs sounds very sensible. Speaking of LLVM, how about making it (optionally?) download an llvm tarball too? Niklas ----- Ursprungligt meddelande ----- Från: "Robin KAY" <komadori(a)gekkou.co.uk> Skickat: ‎2014-‎06-‎10 01:46 Till: "ghc-devs(a)haskell.org" <ghc-devs(a)haskell.org> Ämne: GHC MinGW distribution Dear All, I wanted to enquire about the prospects for updating the version of MinGW which ships with the Windows binary distribution of GHC. The version included as of 7.8.2 is now several years old and in some cases I've found that it's incompatible with the libraries produced by newer versions of MinGW (as to be expected, per my understanding). Specifically, my HsQML binding for Qt can't be used with the libraries from the official Windows binary distribution of Qt 5 because the resulting executables crash on start-up with runtime incompatibilities. I'm in the process of trying to build out-of-the-box compatible Qt binaries against GHC's MinGW, but Qt's stated minimum requirements on the tool-chain version aren't encouraging. The only way I currently have of making this work is for users to edit their GHC settings file to point GHC at a version of gcc.exe from a newer MinGW (such as the one which ships with Qt). The fact that this seems to work is encouraging, but it's still a bit of a difficult process to put people through. I know that Windows developers are in short supply, so I would like to offer what assistance I can in making this happen. There appear to be copies of MinGW stored in the GHC repository at http://git.haskell.org/ghc-tarballs.git/tree . Does the build system use these automatically or are they just there for reference? Thanks, -- Robin KAY _______________________________________________ ghc-devs mailing list ghc-devs(a)haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs

1 0