From alan.zimm at gmail.com Tue Nov 1 20:36:25 2016 From: alan.zimm at gmail.com (Alan & Kim Zimmerman) Date: Tue, 1 Nov 2016 22:36:25 +0200 Subject: Compilation optimisation performance example - HaRe Message-ID: At the moment HaRe has -O0 set for the library. Here are some timing differences on my machine with optimisation on and off With normal optimisation, we get $ rm -fr dist-newstyle/ $ cabal new-configure --enable-test $ time cabal new-build real 6m54.778s user 7m3.156s sys 0m4.504s With -O0, the timing for the same commands is real 0m36.427s user 0m41.448s sys 0m2.544s So optimisation slows it down from 36 seconds to 7 minutes. Alan -------------- next part -------------- An HTML attachment was scrubbed... URL: From takenobu.hs at gmail.com Thu Nov 3 02:57:40 2016 From: takenobu.hs at gmail.com (Takenobu Tani) Date: Thu, 3 Nov 2016 11:57:40 +0900 Subject: simple pictures about GHC development flow In-Reply-To: References: <1477660775.1146.5.camel@joachim-breitner.de> <87r3702zxs.fsf@ben-laptop.smart-cactus.org> <1477763970.1364.3.camel@joachim-breitner.de> Message-ID: Hi devs, 2016-10-31 20:02 GMT+09:00 Takenobu Tani : > > Also it might be good to add something about the process of fixing doc > "bugs" and improving the doc. > > > > I think these are areas where less experienced Haskell developers can > add value and contribute to the > > ghc community. > > Indeed. It's good :) > Update of documents is easy to contribute by new contributors. > I'll understand the document process, then I'll try to draw the diagram. > I updated the following: * page 11: add a link for test case * page 12-15: add document flow Here is Rev.2016-Nov-03: GHC development flow http://takenobu-hs.github.io/downloads/ghc_development_flow.pdf https://github.com/takenobu-hs/ghc-development-flow Please teach me if I have misunderstood, especially page 12-15. Thank you, Takenobu -------------- next part -------------- An HTML attachment was scrubbed... URL: From ben at smart-cactus.org Thu Nov 3 12:20:40 2016 From: ben at smart-cactus.org (Ben Gamari) Date: Thu, 03 Nov 2016 08:20:40 -0400 Subject: simple pictures about GHC development flow In-Reply-To: References: <1477660775.1146.5.camel@joachim-breitner.de> <87r3702zxs.fsf@ben-laptop.smart-cactus.org> <1477763970.1364.3.camel@joachim-breitner.de> Message-ID: <87h97on49z.fsf@ben-laptop.smart-cactus.org> Takenobu Tani writes: > Hi devs, > > 2016-10-31 20:02 GMT+09:00 Takenobu Tani : > >> > Also it might be good to add something about the process of fixing doc >> "bugs" and improving the doc. >> > >> > I think these are areas where less experienced Haskell developers can >> add value and contribute to the >> > ghc community. >> >> Indeed. It's good :) >> Update of documents is easy to contribute by new contributors. >> I'll understand the document process, then I'll try to draw the diagram. >> > > > I updated the following: > * page 11: add a link for test case > * page 12-15: add document flow > > Here is Rev.2016-Nov-03: > GHC development flow > http://takenobu-hs.github.io/downloads/ghc_development_flow.pdf > https://github.com/takenobu-hs/ghc-development-flow > > Please teach me if I have misunderstood, especially page 12-15. > Thanks, this looks great Takenobu! Cheers, - Ben -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 454 bytes Desc: not available URL: From takenobu.hs at gmail.com Thu Nov 3 22:36:36 2016 From: takenobu.hs at gmail.com (Takenobu Tani) Date: Fri, 4 Nov 2016 07:36:36 +0900 Subject: simple pictures about GHC development flow In-Reply-To: <87h97on49z.fsf@ben-laptop.smart-cactus.org> References: <1477660775.1146.5.camel@joachim-breitner.de> <87r3702zxs.fsf@ben-laptop.smart-cactus.org> <1477763970.1364.3.camel@joachim-breitner.de> <87h97on49z.fsf@ben-laptop.smart-cactus.org> Message-ID: Hi Ben, Thank you so much :) After I remove "DRAFT" watermark, I'll introduce this PDF to cafe. Regards, Takenobu 2016-11-03 21:20 GMT+09:00 Ben Gamari : > Takenobu Tani writes: > > > Hi devs, > > > > 2016-10-31 20:02 GMT+09:00 Takenobu Tani : > > > >> > Also it might be good to add something about the process of fixing doc > >> "bugs" and improving the doc. > >> > > >> > I think these are areas where less experienced Haskell developers can > >> add value and contribute to the > >> > ghc community. > >> > >> Indeed. It's good :) > >> Update of documents is easy to contribute by new contributors. > >> I'll understand the document process, then I'll try to draw the diagram. > >> > > > > > > I updated the following: > > * page 11: add a link for test case > > * page 12-15: add document flow > > > > Here is Rev.2016-Nov-03: > > GHC development flow > > http://takenobu-hs.github.io/downloads/ghc_development_flow.pdf > > https://github.com/takenobu-hs/ghc-development-flow > > > > Please teach me if I have misunderstood, especially page 12-15. > > > Thanks, this looks great Takenobu! > > Cheers, > > - Ben > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From takenobu.hs at gmail.com Fri Nov 4 04:37:55 2016 From: takenobu.hs at gmail.com (Takenobu Tani) Date: Fri, 4 Nov 2016 13:37:55 +0900 Subject: simple diagrams about GHC development flow Message-ID: Hi cafe, For myself and new contributors, I drew overview diagrams about GHC development flow. GHC development flow http://takenobu-hs.github.io/downloads/ghc_development_flow.pdf https://github.com/takenobu-hs/ghc-development-flow Let's enjoy :) Regards, Takenobu -------------- next part -------------- An HTML attachment was scrubbed... URL: From alan.zimm at gmail.com Fri Nov 4 07:10:24 2016 From: alan.zimm at gmail.com (Alan & Kim Zimmerman) Date: Fri, 4 Nov 2016 09:10:24 +0200 Subject: Building with recent binutils require --no-pie Message-ID: Hi all For anyone building on Debian testing or similar and getting linker failures, there is currently a workaround in progress by Ben Gamari that can be used. It is based on first applying D2672, D2673, and D2674 and then configuring with ./configure \ CONF_CC_OPTS_STAGE2=-fno-PIE \ CONF_GCC_LINKER_OPTS_STAGE2=-no-pie \ CONF_LD_LINKER_OPTS_STAGE2=-no-pie \ CONF_CC_OPTS_STAGE0=-no-pie \ CONF_GCC_LINKER_OPTS_STAGE0=-no-pie \ CONF_LD_LINKER_OPTS_STAGE0=-no-pie \ CONF_HC_OPTS_STAGE0=-optl=-no-pie See https://gist.github.com/alanz/570eb6f1c0ae7e989f493f1b69904c28 for a more legible version. Regards Alan -------------- next part -------------- An HTML attachment was scrubbed... URL: From mle+hs at mega-nerd.com Fri Nov 4 08:22:51 2016 From: mle+hs at mega-nerd.com (Erik de Castro Lopo) Date: Fri, 4 Nov 2016 19:22:51 +1100 Subject: Building with recent binutils require --no-pie In-Reply-To: References: Message-ID: <20161104192251.9cdc2d4cdebb4494fb4890d5@mega-nerd.com> Alan & Kim Zimmerman wrote: > For anyone building on Debian testing or similar and getting linker > failures, there is currently a workaround in progress by Ben Gamari that > can be used. > > It is based on first applying D2672, D2673, and D2674 and then configuring > with > > ./configure \ > CONF_CC_OPTS_STAGE2=-fno-PIE \ > CONF_GCC_LINKER_OPTS_STAGE2=-no-pie \ > CONF_LD_LINKER_OPTS_STAGE2=-no-pie \ > CONF_CC_OPTS_STAGE0=-no-pie \ > CONF_GCC_LINKER_OPTS_STAGE0=-no-pie \ > CONF_LD_LINKER_OPTS_STAGE0=-no-pie \ > CONF_HC_OPTS_STAGE0=-optl=-no-pie Unfortunately, that is not sufficient. With the three patchs you listed and the configure options above, the resulting GHC still fails to build the 'magic' due to something going wrong with hsc2hs: Configuring magic-1.1... Building magic-1.1... Preprocessing library magic-1.1... /usr/bin/ld: dist/build/Magic/Data_hsc_make.o: relocation R_X86_64_32 against `.rodata' can not be used when making a shared object; recompile with -fPIC /usr/bin/ld: final link failed: Nonrepresentable section on output collect2: error: ld returned 1 exit status linking dist/build/Magic/Data_hsc_make.o failed (exit code 1) command was: /usr/bin/gcc dist/build/Magic/Data_hsc_make.o dist/build/Magic/Data_hsc_utils.o -o dist/build/Magic/Data_hsc_make -fno-PIE -fno-stack-protector -lmagic -L/usr/lib/ghc-8.0/lib/base-4.9.0.0 -Wl,-R,/usr/lib/ghc-8.0/lib/base-4.9.0.0 -L/usr/lib/ghc-8.0/lib/integer-gmp-1.0.0.1 -Wl,-R,/usr/lib/ghc-8.0/lib/integer-gmp-1.0.0.1 -lgmp -L/usr/lib/ghc-8.0/lib/ghc-prim-0.5.0.0 -Wl,-R,/usr/lib/ghc-8.0/lib/ghc-prim-0.5.0.0 -L/usr/lib/ghc-8.0/lib/rts -Wl,-R,/usr/lib/ghc-8.0/lib/rts -lm -lrt -ldl -lffi Erik -- ---------------------------------------------------------------------- Erik de Castro Lopo http://www.mega-nerd.com/ From mle+hs at mega-nerd.com Fri Nov 4 08:45:30 2016 From: mle+hs at mega-nerd.com (Erik de Castro Lopo) Date: Fri, 4 Nov 2016 19:45:30 +1100 Subject: Building with recent binutils require --no-pie In-Reply-To: <20161104192251.9cdc2d4cdebb4494fb4890d5@mega-nerd.com> References: <20161104192251.9cdc2d4cdebb4494fb4890d5@mega-nerd.com> Message-ID: <20161104194530.e3ba3fc92d87eb653c3655c1@mega-nerd.com> Erik de Castro Lopo wrote: > Unfortunately, that is not sufficient. With the three patchs you listed > and the configure options above, the resulting GHC still fails to build > the 'magic' due to something going wrong with hsc2hs: Just to be clear, this is patching the 8.0.1 release. It seems that the final piece of the puzzle is the cabal 1.24.1.0 release which is due RealSoonNow! https://github.com/haskell/cabal/issues/4080 Erik -- ---------------------------------------------------------------------- Erik de Castro Lopo http://www.mega-nerd.com/ From mle+hs at mega-nerd.com Fri Nov 4 09:57:26 2016 From: mle+hs at mega-nerd.com (Erik de Castro Lopo) Date: Fri, 4 Nov 2016 20:57:26 +1100 Subject: Submitting a patch for hsc2hs Message-ID: <20161104205726.c14b935a6bc81cd4eea82b01@mega-nerd.com> HI all, How would I go about submitting a patch to hsc2hs? Patch below. Erik >From 446e43994e39c763e2fcc3a3accea3e61c3ce767 Mon Sep 17 00:00:00 2001 From: Erik de Castro Lopo Date: Fri, 4 Nov 2016 20:08:06 +1100 Subject: [PATCH] Fix type signature of main test function During C compiler feature testing, the `main` function was defined with a parameter list of `(int argc, char *argv [])` but these parameters were not used. This results in compiler warnings when the generated file is compiled with the `-Wextra` warning flag added to the `cc-options` of the cabal file. --- DirectCodegen.hs | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/DirectCodegen.hs b/DirectCodegen.hs index 37564ee..2a88784 100644 --- a/DirectCodegen.hs +++ b/DirectCodegen.hs @@ -63,7 +63,7 @@ outputDirect config outName outDir outBase name toks = do outTemplateHeaderCProg (cTemplate config)++ concatMap outFlagHeaderCProg flags++ concatMap outHeaderCProg specials++ - "\nint main (int argc, char *argv [])\n{\n"++ + "\nint main (void)\n{\n"++ outHeaderHs flags (if needsH then Just outHName else Nothing) specials++ outHsLine (SourcePos name 0)++ concatMap outTokenHs toks++ -- 2.10.1 -- ---------------------------------------------------------------------- Erik de Castro Lopo http://www.mega-nerd.com/ From ryan.gl.scott at gmail.com Fri Nov 4 13:02:25 2016 From: ryan.gl.scott at gmail.com (Ryan Scott) Date: Fri, 4 Nov 2016 09:02:25 -0400 Subject: Submitting a patch for hsc2hs Message-ID: Hi Erik, I'm not sure if the hsc2hs repo [1] has "official" Phabricator integration, but what I did when I submitted a patch to hsc2hs was: 1. Commit your changes 2. Because the hsc2hs repo doesn't have an .arcconfig file, you have to manually point arcanist to the right URL by running: arc diff --conduit-uri=https://phabricator.haskell.org Ryan S. ----- [1] http://git.haskell.org/hsc2hs.git From mle+hs at mega-nerd.com Fri Nov 4 20:07:00 2016 From: mle+hs at mega-nerd.com (Erik de Castro Lopo) Date: Sat, 5 Nov 2016 07:07:00 +1100 Subject: Submitting a patch for hsc2hs In-Reply-To: References: Message-ID: <20161105070700.e5308d9ca7e12d8558e30ca6@mega-nerd.com> Ryan Scott wrote: > Hi Erik, > > I'm not sure if the hsc2hs repo [1] has "official" Phabricator > integration, but what I did when I submitted a patch to hsc2hs was: > > 1. Commit your changes > 2. Because the hsc2hs repo doesn't have an .arcconfig file, you have > to manually point arcanist to the right URL by running: > > arc diff --conduit-uri=https://phabricator.haskell.org How long ago was it that it worked, because it doesn't now. I get: Exception ERR-CONDUIT-CORE: Validation errors: - Creation of this diff was rejected by Herald rule H51. Rule: Reject diffs with no repository set Reason: You must specify an existing repository to attach the diff to. (Run with `--trace` for a full exception trace.) Erik -- ---------------------------------------------------------------------- Erik de Castro Lopo http://www.mega-nerd.com/ From mle+hs at mega-nerd.com Fri Nov 4 21:11:26 2016 From: mle+hs at mega-nerd.com (Erik de Castro Lopo) Date: Sat, 5 Nov 2016 08:11:26 +1100 Subject: Submitting a patch for hsc2hs In-Reply-To: <20161105070700.e5308d9ca7e12d8558e30ca6@mega-nerd.com> References: <20161105070700.e5308d9ca7e12d8558e30ca6@mega-nerd.com> Message-ID: <20161105081126.412d89a517fa2fb56ca0426a@mega-nerd.com> Erik de Castro Lopo wrote: > How long ago was it that it worked, because it doesn't now. With a little help from mpickering I got this up on Phab: https://phabricator.haskell.org/D2677 Thanks Matt! Erik -- ---------------------------------------------------------------------- Erik de Castro Lopo http://www.mega-nerd.com/ From matthewtpickering at gmail.com Fri Nov 4 22:24:43 2016 From: matthewtpickering at gmail.com (Matthew Pickering) Date: Fri, 4 Nov 2016 22:24:43 +0000 Subject: Submitting a patch for hsc2hs In-Reply-To: <20161105081126.412d89a517fa2fb56ca0426a@mega-nerd.com> References: <20161105070700.e5308d9ca7e12d8558e30ca6@mega-nerd.com> <20161105081126.412d89a517fa2fb56ca0426a@mega-nerd.com> Message-ID: To close up this thread, once D2676 is merged to hsc2hs then you will be able to submit patches using the same workflow as for GHC. On Friday, 4 November 2016, Erik de Castro Lopo wrote: > Erik de Castro Lopo wrote: > > > How long ago was it that it worked, because it doesn't now. > > With a little help from mpickering I got this up on Phab: > > https://phabricator.haskell.org/D2677 > > Thanks Matt! > > Erik > -- > ---------------------------------------------------------------------- > Erik de Castro Lopo > http://www.mega-nerd.com/ > _______________________________________________ > ghc-devs mailing list > ghc-devs at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs > -------------- next part -------------- An HTML attachment was scrubbed... URL: From tjakway at nyu.edu Sun Nov 6 13:43:14 2016 From: tjakway at nyu.edu (Thomas Jakway) Date: Sun, 6 Nov 2016 08:43:14 -0500 Subject: D2638: Reviewers Needed Message-ID: <93286d3c-2871-9df3-380c-dab1b5b98e01@nyu.edu> My first patch to GHC is on Phab and Matthew Pickering suggested I get someone knowledgeable about the register allocator to review it. I checked the Code Owners page but it's very out of date and doesn't mention the NCG specifically. If anyone here familiar with the backend would care to take a look I would very much appreciate it. Thanks, Thomas Jakway -------------- next part -------------- An HTML attachment was scrubbed... URL: From marlowsd at gmail.com Wed Nov 9 13:02:58 2016 From: marlowsd at gmail.com (Simon Marlow) Date: Wed, 9 Nov 2016 13:02:58 +0000 Subject: T12041 failing? Message-ID: I just saw the error below in a validate with -DDEBUG. Anyone know about this? --- /tmp/ghctest-uhJ8rt/test spaces/./indexed-types/should_fail/T12041.run/T12041.stderr.normalised 2016-11-09 12:13:38.206501840 +0000 +++ /tmp/ghctest-uhJ8rt/test spaces/./indexed-types/should_fail/T12041.run/T12041.comp.stderr.normalised 2016-11-09 12:13:38.206501840 +0000 @@ -1,7 +1,17 @@ +ghc: panic! (the 'impossible' happened) + (GHC version 8.1.20161109 for x86_64-unknown-linux): + ASSERT failed! + i_axb + Call stack: + CallStack (from HasCallStack): + prettyCurrentCallStack, called at compiler/utils/Outputable.hs:: in :Outputable + callStackDoc, called at compiler/utils/Outputable.hs:: in :Outputable + assertPprPanic, called at compiler/typecheck/TcType.hs:: in :TcType + Call stack: + CallStack (from HasCallStack): + prettyCurrentCallStack, called at compiler/utils/Outputable.hs:: in :Outputable + callStackDoc, called at compiler/utils/Outputable.hs:: in :Outputable + pprPanic, called at compiler/utils/Outputable.hs:: in :Outputable + assertPprPanic, called at compiler/typecheck/TcType.hs:: in :TcType -T12041.hs:12:15: - Expected kind ‘i -> Constraint’, - but ‘(~) Int’ has kind ‘* -> Constraint’ - In the type ‘(~) Int’ - In the type instance declaration for ‘Ob’ - In the instance declaration for ‘Category I’ +Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug *** unexpected failure for T12041(normal) -------------- next part -------------- An HTML attachment was scrubbed... URL: From alan.zimm at gmail.com Thu Nov 10 07:01:22 2016 From: alan.zimm at gmail.com (Alan & Kim Zimmerman) Date: Thu, 10 Nov 2016 09:01:22 +0200 Subject: ppr of HsDo Message-ID: The pretty printer turns foo = do let x = 1 Just 5 into foo = do { let x = 1; Just 5 } which does not parse, complaining about "parse error on input ‘Just’" Is this a parser error or a ppr problem? I am keen to fix the ppr to output foo = do let x = 1 Just 5 but I am not sure if there is a parser bug too. Alan -------------- next part -------------- An HTML attachment was scrubbed... URL: From simonpj at microsoft.com Thu Nov 10 08:24:32 2016 From: simonpj at microsoft.com (Simon Peyton Jones) Date: Thu, 10 Nov 2016 08:24:32 +0000 Subject: ppr of HsDo In-Reply-To: References: Message-ID: I think it’s because the “;” is treated as part of the let not part of the do. After all, how does the implicit layout of the let know that the let-bindings are finished? This should work foo = do { let { x = 1 }; Just 5 } Now the let bindings are clearly brought to an end. Or this foo = do { let x = 1 ; Just 5 } Now the “’;” is to the left of the x=1 and so brings the let’s implicit layout to an end. But not this! foo = do { let x = 1; Just 5 } So it’s a bug in the pretty-printer, not the parser SImon From: ghc-devs [mailto:ghc-devs-bounces at haskell.org] On Behalf Of Alan & Kim Zimmerman Sent: 10 November 2016 07:01 To: ghc-devs at haskell.org Subject: ppr of HsDo The pretty printer turns foo = do let x = 1 Just 5 into foo = do { let x = 1; Just 5 } which does not parse, complaining about "parse error on input ‘Just’" Is this a parser error or a ppr problem? I am keen to fix the ppr to output foo = do let x = 1 Just 5 but I am not sure if there is a parser bug too. Alan -------------- next part -------------- An HTML attachment was scrubbed... URL: From alan.zimm at gmail.com Thu Nov 10 08:31:00 2016 From: alan.zimm at gmail.com (Alan & Kim Zimmerman) Date: Thu, 10 Nov 2016 10:31:00 +0200 Subject: ppr of HsDo In-Reply-To: References: Message-ID: Thanks. And any thoughts on my proposal to do away with the braces/semi completely? I suspect GHC is the only significant body of code that uses that style still. Alan On Thu, Nov 10, 2016 at 10:24 AM, Simon Peyton Jones wrote: > I think it’s because the “;” is treated as part of the let not part of > the do. After all, how does the implicit layout of the let know that the > let-bindings are finished? > > > > This should work > > > > foo > = do { let { x = 1 }; > Just 5 } > > > > Now the let bindings are clearly brought to an end. Or this > > > > foo > = do { let x = 1 > > ; Just 5 } > > > > Now the “’;” is to the left of the x=1 and so brings the let’s implicit > layout to an end. > > > > But not this! > > > > foo > = do { let x = 1; Just 5 } > > > > So it’s a bug in the pretty-printer, not the parser > > > > SImon > > > > > > *From:* ghc-devs [mailto:ghc-devs-bounces at haskell.org] *On Behalf Of *Alan > & Kim Zimmerman > *Sent:* 10 November 2016 07:01 > *To:* ghc-devs at haskell.org > *Subject:* ppr of HsDo > > > > The pretty printer turns > > foo = do > let x = 1 > Just 5 > > into > > foo > = do { let x = 1; > Just 5 } > > which does not parse, complaining about "parse error on input ‘Just’" > > Is this a parser error or a ppr problem? I am keen to fix the ppr to > output > > > foo > = do let x = 1 > Just 5 > > but I am not sure if there is a parser bug too. > > Alan > -------------- next part -------------- An HTML attachment was scrubbed... URL: From simonpj at microsoft.com Thu Nov 10 10:02:31 2016 From: simonpj at microsoft.com (Simon Peyton Jones) Date: Thu, 10 Nov 2016 10:02:31 +0000 Subject: ppr of HsDo In-Reply-To: References: Message-ID: It’s not about GHC’s programming style, is it? It’s about what the pretty-printer does. If it were me I’d use braces and semicolons everywhere, so that I could guarantee to parse it easily. But that’s not a strong opinion and I would willingly yield to others! Simon From: Alan & Kim Zimmerman [mailto:alan.zimm at gmail.com] Sent: 10 November 2016 08:31 To: Simon Peyton Jones Cc: ghc-devs at haskell.org Subject: Re: ppr of HsDo Thanks. And any thoughts on my proposal to do away with the braces/semi completely? I suspect GHC is the only significant body of code that uses that style still. Alan On Thu, Nov 10, 2016 at 10:24 AM, Simon Peyton Jones > wrote: I think it’s because the “;” is treated as part of the let not part of the do. After all, how does the implicit layout of the let know that the let-bindings are finished? This should work foo = do { let { x = 1 }; Just 5 } Now the let bindings are clearly brought to an end. Or this foo = do { let x = 1 ; Just 5 } Now the “’;” is to the left of the x=1 and so brings the let’s implicit layout to an end. But not this! foo = do { let x = 1; Just 5 } So it’s a bug in the pretty-printer, not the parser SImon From: ghc-devs [mailto:ghc-devs-bounces at haskell.org] On Behalf Of Alan & Kim Zimmerman Sent: 10 November 2016 07:01 To: ghc-devs at haskell.org Subject: ppr of HsDo The pretty printer turns foo = do let x = 1 Just 5 into foo = do { let x = 1; Just 5 } which does not parse, complaining about "parse error on input ‘Just’" Is this a parser error or a ppr problem? I am keen to fix the ppr to output foo = do let x = 1 Just 5 but I am not sure if there is a parser bug too. Alan -------------- next part -------------- An HTML attachment was scrubbed... URL: From alan.zimm at gmail.com Thu Nov 10 10:06:36 2016 From: alan.zimm at gmail.com (Alan & Kim Zimmerman) Date: Thu, 10 Nov 2016 12:06:36 +0200 Subject: ppr of HsDo In-Reply-To: References: Message-ID: For context, I am putting in a test suite similar to the one for ghc-exactprint to ensure that the pretty printer always generates code that can be round tripped back to the original AST. This means that fears of some uncaught case requiring us do it the guaranteed safe way should be allayed. In the process I am updating the pretty printer. So the question really is, given the existence of that test suite, what style of code should we have in our messages, and in pretty printed code? Alan On Thu, Nov 10, 2016 at 12:02 PM, Simon Peyton Jones wrote: > > > It’s not about GHC’s programming style, is it? It’s about what the > pretty-printer does. If it were me I’d use braces and semicolons > everywhere, so that I could guarantee to parse it easily. > > > > But that’s not a strong opinion and I would willingly yield to others! > > > > Simon > > > > *From:* Alan & Kim Zimmerman [mailto:alan.zimm at gmail.com] > *Sent:* 10 November 2016 08:31 > *To:* Simon Peyton Jones > *Cc:* ghc-devs at haskell.org > *Subject:* Re: ppr of HsDo > > > > Thanks. > > And any thoughts on my proposal to do away with the braces/semi > completely? I suspect GHC is the only significant body of code that uses > that style still. > > Alan > > > > On Thu, Nov 10, 2016 at 10:24 AM, Simon Peyton Jones < > simonpj at microsoft.com> wrote: > > I think it’s because the “;” is treated as part of the let not part of > the do. After all, how does the implicit layout of the let know that the > let-bindings are finished? > > > > This should work > > > > foo > = do { let { x = 1 }; > Just 5 } > > > > Now the let bindings are clearly brought to an end. Or this > > > > foo > = do { let x = 1 > > ; Just 5 } > > > > Now the “’;” is to the left of the x=1 and so brings the let’s implicit > layout to an end. > > > > But not this! > > > > foo > = do { let x = 1; Just 5 } > > > > So it’s a bug in the pretty-printer, not the parser > > > > SImon > > > > > > *From:* ghc-devs [mailto:ghc-devs-bounces at haskell.org] *On Behalf Of *Alan > & Kim Zimmerman > *Sent:* 10 November 2016 07:01 > *To:* ghc-devs at haskell.org > *Subject:* ppr of HsDo > > > > The pretty printer turns > > foo = do > let x = 1 > Just 5 > > into > > foo > = do { let x = 1; > Just 5 } > > which does not parse, complaining about "parse error on input ‘Just’" > > Is this a parser error or a ppr problem? I am keen to fix the ppr to > output > > > foo > = do let x = 1 > Just 5 > > but I am not sure if there is a parser bug too. > > Alan > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From alan.zimm at gmail.com Thu Nov 10 12:46:57 2016 From: alan.zimm at gmail.com (Alan & Kim Zimmerman) Date: Thu, 10 Nov 2016 14:46:57 +0200 Subject: ppr of HsDo In-Reply-To: References: Message-ID: As a follow up, I will be continuing with the least-invasive change, which is to keep the existing braces/semis, and make sure that they are all produced correctly. Alan On Thu, Nov 10, 2016 at 12:06 PM, Alan & Kim Zimmerman wrote: > For context, I am putting in a test suite similar to the one for > ghc-exactprint to ensure that the pretty printer always generates code that > can be round tripped back to the original AST. > > This means that fears of some uncaught case requiring us do it the > guaranteed safe way should be allayed. > > In the process I am updating the pretty printer. > > So the question really is, given the existence of that test suite, what > style of code should we have in our messages, and in pretty printed code? > > Alan > > > On Thu, Nov 10, 2016 at 12:02 PM, Simon Peyton Jones < > simonpj at microsoft.com> wrote: > >> >> >> It’s not about GHC’s programming style, is it? It’s about what the >> pretty-printer does. If it were me I’d use braces and semicolons >> everywhere, so that I could guarantee to parse it easily. >> >> >> >> But that’s not a strong opinion and I would willingly yield to others! >> >> >> >> Simon >> >> >> >> *From:* Alan & Kim Zimmerman [mailto:alan.zimm at gmail.com] >> *Sent:* 10 November 2016 08:31 >> *To:* Simon Peyton Jones >> *Cc:* ghc-devs at haskell.org >> *Subject:* Re: ppr of HsDo >> >> >> >> Thanks. >> >> And any thoughts on my proposal to do away with the braces/semi >> completely? I suspect GHC is the only significant body of code that uses >> that style still. >> >> Alan >> >> >> >> On Thu, Nov 10, 2016 at 10:24 AM, Simon Peyton Jones < >> simonpj at microsoft.com> wrote: >> >> I think it’s because the “;” is treated as part of the let not part of >> the do. After all, how does the implicit layout of the let know that the >> let-bindings are finished? >> >> >> >> This should work >> >> >> >> foo >> = do { let { x = 1 }; >> Just 5 } >> >> >> >> Now the let bindings are clearly brought to an end. Or this >> >> >> >> foo >> = do { let x = 1 >> >> ; Just 5 } >> >> >> >> Now the “’;” is to the left of the x=1 and so brings the let’s implicit >> layout to an end. >> >> >> >> But not this! >> >> >> >> foo >> = do { let x = 1; Just 5 } >> >> >> >> So it’s a bug in the pretty-printer, not the parser >> >> >> >> SImon >> >> >> >> >> >> *From:* ghc-devs [mailto:ghc-devs-bounces at haskell.org] *On Behalf Of *Alan >> & Kim Zimmerman >> *Sent:* 10 November 2016 07:01 >> *To:* ghc-devs at haskell.org >> *Subject:* ppr of HsDo >> >> >> >> The pretty printer turns >> >> foo = do >> let x = 1 >> Just 5 >> >> into >> >> foo >> = do { let x = 1; >> Just 5 } >> >> which does not parse, complaining about "parse error on input ‘Just’" >> >> Is this a parser error or a ppr problem? I am keen to fix the ppr to >> output >> >> >> foo >> = do let x = 1 >> Just 5 >> >> but I am not sure if there is a parser bug too. >> >> Alan >> >> >> > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From pierre.crumeyrolle at c-s.fr Thu Nov 10 12:56:04 2016 From: pierre.crumeyrolle at c-s.fr (CRUMEYROLLE Pierre) Date: Thu, 10 Nov 2016 13:56:04 +0100 Subject: install pandoc with cabal update Message-ID: <20161110135604.Horde.L0Nu9ydSoDhGsmvjuyL-Cw3@messagerie.si.c-s.fr> hello y try to install pandoc in mode offline but the standard installation from source preconise to execute cabal update . it seems that cabal update try to connect and download package from hackage.haskell.org. do you known how to execute offline installation ? ghc 7.10.3 cabal 1.24.0.0 best regards From ben at smart-cactus.org Thu Nov 10 19:44:54 2016 From: ben at smart-cactus.org (Ben Gamari) Date: Thu, 10 Nov 2016 14:44:54 -0500 Subject: Breakage due to CallStack refactoring Message-ID: <87wpgbjf0p.fsf@ben-laptop.smart-cactus.org> Hi Simon, In 317236db308d you performed some refactoring of CallStack defaulting and noted that there was no change in visisble behavior. However, it isn't seem that this is true. The following two tests [1] now fail as callstacks are no longer produced in their output, TEST="assert T10845" Presumably this isn't expected. Cheers, - Ben [1] https://phabricator.haskell.org/harbormaster/build/14964/?l=100 -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 454 bytes Desc: not available URL: From omeragacan at gmail.com Fri Nov 11 04:12:22 2016 From: omeragacan at gmail.com (=?UTF-8?Q?=C3=96mer_Sinan_A=C4=9Facan?=) Date: Thu, 10 Nov 2016 23:12:22 -0500 Subject: 177 unexpected test failures on a new system -- is this yet another linker issue? Message-ID: I'm trying to validate on a new system (not sure if related, but it has gcc 6.2.1 and ld 2.27.0), and I'm having 177 unexpected failures, most (maybe even all) of them are similar to this one: =====> T5976(ext-interp) 1 of 1 [0, 0, 0] cd "./th/T5976.run" && "/home/omer/haskell/ghc/inplace/test spaces/ghc-stage2" -c T5976.hs -dcore-dno-debug-output -XTemplateHaskell -package template-haskell -fexternal-interpreter -v0 Actual stderr output differs from expected: --- ./th/T5976.run/T5976.stderr.normalised 2016-11-10 23:01:39.351997560 -0500 +++ ./th/T5976.run/T5976.comp.stderr.normalised 2016-11-10 23:01:39.351997560 -0500 @@ -1,7 +1,4 @@ - -T5976.hs:1:1: - Exception when trying to run compile-time code: - bar -CallStack (from HasCallStack): - error, called at T5976.hs:: in :Main - Code: error ((++) "foo " error "bar") +ghc-iserv.bin: internal loadArchive: GNU-variant filename offset not found while reading filename f + (GHC version 8.1.20161107 for x86_64_unknown_linux) + Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug +ghc: ghc-iserv terminated (-6) *** unexpected failure for T5976(ext-interp) Does anyone know what is this about? -------------- next part -------------- An HTML attachment was scrubbed... URL: From ben at smart-cactus.org Fri Nov 11 05:09:04 2016 From: ben at smart-cactus.org (Ben Gamari) Date: Fri, 11 Nov 2016 00:09:04 -0500 Subject: 177 unexpected test failures on a new system -- is this yet another linker issue? In-Reply-To: References: Message-ID: <87h97ek3gv.fsf@ben-laptop.smart-cactus.org> Ömer Sinan Ağacan writes: > I'm trying to validate on a new system (not sure if related, but it has gcc > 6.2.1 and ld 2.27.0), and I'm having 177 unexpected failures, most (maybe > even > all) of them are similar to this one: Hmm, I have a rather similar setup and yet I haven't seen this locally. I'm not sure what's going on here but the filename cited in the error message looks quite odd. I wonder if this is due to normalization by the testsuite driver or some other issue. Cheers, - Ben -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 454 bytes Desc: not available URL: From rwbarton at gmail.com Fri Nov 11 05:52:00 2016 From: rwbarton at gmail.com (Reid Barton) Date: Fri, 11 Nov 2016 00:52:00 -0500 Subject: 177 unexpected test failures on a new system -- is this yet another linker issue? In-Reply-To: References: Message-ID: On Thu, Nov 10, 2016 at 11:12 PM, Ömer Sinan Ağacan wrote: > I'm trying to validate on a new system (not sure if related, but it has gcc > 6.2.1 and ld 2.27.0), and I'm having 177 unexpected failures, most (maybe > even > all) of them are similar to this one: > > =====> T5976(ext-interp) 1 of 1 [0, 0, 0] > cd "./th/T5976.run" && "/home/omer/haskell/ghc/inplace/test > spaces/ghc-stage2" -c T5976.hs -dcore-dno-debug-output -XTemplateHaskell > -package template-haskell -fexternal-interpreter -v0 > Actual stderr output differs from expected: > --- ./th/T5976.run/T5976.stderr.normalised 2016-11-10 > 23:01:39.351997560 -0500 > +++ ./th/T5976.run/T5976.comp.stderr.normalised 2016-11-10 > 23:01:39.351997560 -0500 > @@ -1,7 +1,4 @@ > - > -T5976.hs:1:1: > - Exception when trying to run compile-time code: > - bar > -CallStack (from HasCallStack): > - error, called at T5976.hs:: in :Main > - Code: error ((++) "foo " error "bar") > +ghc-iserv.bin: internal loadArchive: GNU-variant filename offset not > found while reading filename f Did this line get truncated? It might help to have the rest of it. Regards, Reid Barton From simonpj at microsoft.com Fri Nov 11 15:35:25 2016 From: simonpj at microsoft.com (Simon Peyton Jones) Date: Fri, 11 Nov 2016 15:35:25 +0000 Subject: Breakage due to CallStack refactoring In-Reply-To: <87wpgbjf0p.fsf@ben-laptop.smart-cactus.org> References: <87wpgbjf0p.fsf@ben-laptop.smart-cactus.org> Message-ID: Darn. validate --fast doesn’t run that test. And, sure enough, I made a mistake. So I'm reverting and will solve my original problem another way. sorry about this. Simon | -----Original Message----- | From: Ben Gamari [mailto:ben at smart-cactus.org] | Sent: 10 November 2016 19:45 | To: Simon Peyton Jones | Cc: ghc-devs at haskell.org | Subject: Breakage due to CallStack refactoring | | Hi Simon, | | In 317236db308d you performed some refactoring of CallStack defaulting | and noted that there was no change in visisble behavior. However, it | isn't seem that this is true. The following two tests [1] now fail as | callstacks are no longer produced in their output, | | TEST="assert T10845" | | Presumably this isn't expected. | | Cheers, | | - Ben | | | [1] https://phabricator.haskell.org/harbormaster/build/14964/?l=100 From omeragacan at gmail.com Fri Nov 11 15:49:33 2016 From: omeragacan at gmail.com (=?UTF-8?Q?=C3=96mer_Sinan_A=C4=9Facan?=) Date: Fri, 11 Nov 2016 10:49:33 -0500 Subject: 177 unexpected test failures on a new system -- is this yet another linker issue? In-Reply-To: References: Message-ID: Ah, sorry, that line was truncated. I posted the output here: https://gist.githubusercontent.com/osa1/ea72655b8369099e84a67e0949adca7e/raw/9e72cbfb859cb839f1898af39a46ff0896237d15/gistfile1.txt That line should be +ghc-iserv.bin: internal loadArchive: GNU-variant filename offset not found while reading filename from `/home/omer/haskell/ghc/libraries/ghc-prim/dist-install/build/libHSghc-prim-0.5.0.0.a' + (GHC version 8.1.20161107 for x86_64_unknown_linux) + Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug 2016-11-11 0:52 GMT-05:00 Reid Barton : > On Thu, Nov 10, 2016 at 11:12 PM, Ömer Sinan Ağacan > wrote: > > I'm trying to validate on a new system (not sure if related, but it has > gcc > > 6.2.1 and ld 2.27.0), and I'm having 177 unexpected failures, most (maybe > > even > > all) of them are similar to this one: > > > > =====> T5976(ext-interp) 1 of 1 [0, 0, 0] > > cd "./th/T5976.run" && "/home/omer/haskell/ghc/inplace/test > > spaces/ghc-stage2" -c T5976.hs -dcore-dno-debug-output -XTemplateHaskell > > -package template-haskell -fexternal-interpreter -v0 > > Actual stderr output differs from expected: > > --- ./th/T5976.run/T5976.stderr.normalised 2016-11-10 > > 23:01:39.351997560 -0500 > > +++ ./th/T5976.run/T5976.comp.stderr.normalised 2016-11-10 > > 23:01:39.351997560 -0500 > > @@ -1,7 +1,4 @@ > > - > > -T5976.hs:1:1: > > - Exception when trying to run compile-time code: > > - bar > > -CallStack (from HasCallStack): > > - error, called at T5976.hs:: in :Main > > - Code: error ((++) "foo " error "bar") > > +ghc-iserv.bin: internal loadArchive: GNU-variant filename offset not > > found while reading filename f > > Did this line get truncated? It might help to have the rest of it. > > Regards, > Reid Barton > -------------- next part -------------- An HTML attachment was scrubbed... URL: From sylvain at haskus.fr Fri Nov 11 16:18:43 2016 From: sylvain at haskus.fr (Sylvain Henry) Date: Fri, 11 Nov 2016 17:18:43 +0100 Subject: 177 unexpected test failures on a new system -- is this yet another linker issue? In-Reply-To: References: Message-ID: It seems like we don't bypass the special filename "/" (symbol lookup table) in rts/Linker.c https://en.wikipedia.org/wiki/Ar_(Unix)#System_V_.28or_GNU.29_variant On 11/11/2016 16:49, Ömer Sinan Ağacan wrote: > Ah, sorry, that line was truncated. I posted the output here: > https://gist.githubusercontent.com/osa1/ea72655b8369099e84a67e0949adca7e/raw/9e72cbfb859cb839f1898af39a46ff0896237d15/gistfile1.txt > > > That line should be > +ghc-iserv.bin: internal loadArchive: GNU-variant filename offset not found while reading filename from `/home/omer/haskell/ghc/libraries/ghc-prim/dist-install/build/libHSghc-prim-0.5.0.0.a' > + (GHC version 8.1.20161107 for x86_64_unknown_linux) > + Please report this as a GHC bug:http://www.haskell.org/ghc/reportabug > > 2016-11-11 0:52 GMT-05:00 Reid Barton >: > > On Thu, Nov 10, 2016 at 11:12 PM, Ömer Sinan Ağacan > > wrote: > > I'm trying to validate on a new system (not sure if related, but > it has gcc > > 6.2.1 and ld 2.27.0), and I'm having 177 unexpected failures, > most (maybe > > even > > all) of them are similar to this one: > > > > =====> T5976(ext-interp) 1 of 1 [0, 0, 0] > > cd "./th/T5976.run" && "/home/omer/haskell/ghc/inplace/test > > spaces/ghc-stage2" -c T5976.hs -dcore-dno-debug-output > -XTemplateHaskell > > -package template-haskell -fexternal-interpreter -v0 > > Actual stderr output differs from expected: > > --- ./th/T5976.run/T5976.stderr.normalised 2016-11-10 > > 23:01:39.351997560 -0500 > > +++ ./th/T5976.run/T5976.comp.stderr.normalised 2016-11-10 > > 23:01:39.351997560 -0500 > > @@ -1,7 +1,4 @@ > > - > > -T5976.hs:1:1: > > - Exception when trying to run compile-time code: > > - bar > > -CallStack (from HasCallStack): > > - error, called at T5976.hs:: in > :Main > > - Code: error ((++) "foo " error "bar") > > +ghc-iserv.bin: internal loadArchive: GNU-variant filename > offset not > > found while reading filename f > > Did this line get truncated? It might help to have the rest of it. > > Regards, > Reid Barton > > > > > _______________________________________________ > ghc-devs mailing list > ghc-devs at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs -------------- next part -------------- An HTML attachment was scrubbed... URL: From sylvain at haskus.fr Fri Nov 11 16:55:58 2016 From: sylvain at haskus.fr (Sylvain Henry) Date: Fri, 11 Nov 2016 17:55:58 +0100 Subject: 177 unexpected test failures on a new system -- is this yet another linker issue? In-Reply-To: References: Message-ID: <666e2499-dca7-fdec-4ab9-5f7fe826b927@haskus.fr> My bad, in fact we do. Could you try with the attached patch? It shows the failing filename in the archive. On 11/11/2016 17:18, Sylvain Henry wrote: > > It seems like we don't bypass the special filename "/" (symbol lookup > table) in rts/Linker.c > > https://en.wikipedia.org/wiki/Ar_(Unix)#System_V_.28or_GNU.29_variant > > > On 11/11/2016 16:49, Ömer Sinan Ağacan wrote: >> Ah, sorry, that line was truncated. I posted the output here: >> https://gist.githubusercontent.com/osa1/ea72655b8369099e84a67e0949adca7e/raw/9e72cbfb859cb839f1898af39a46ff0896237d15/gistfile1.txt >> >> >> That line should be >> +ghc-iserv.bin: internal loadArchive: GNU-variant filename offset not found while reading filename from `/home/omer/haskell/ghc/libraries/ghc-prim/dist-install/build/libHSghc-prim-0.5.0.0.a' >> + (GHC version 8.1.20161107 for x86_64_unknown_linux) >> + Please report this as a GHC bug:http://www.haskell.org/ghc/reportabug >> >> 2016-11-11 0:52 GMT-05:00 Reid Barton > >: >> >> On Thu, Nov 10, 2016 at 11:12 PM, Ömer Sinan Ağacan >> > wrote: >> > I'm trying to validate on a new system (not sure if related, >> but it has gcc >> > 6.2.1 and ld 2.27.0), and I'm having 177 unexpected failures, >> most (maybe >> > even >> > all) of them are similar to this one: >> > >> > =====> T5976(ext-interp) 1 of 1 [0, 0, 0] >> > cd "./th/T5976.run" && "/home/omer/haskell/ghc/inplace/test >> > spaces/ghc-stage2" -c T5976.hs -dcore-dno-debug-output >> -XTemplateHaskell >> > -package template-haskell -fexternal-interpreter -v0 >> > Actual stderr output differs from expected: >> > --- ./th/T5976.run/T5976.stderr.normalised 2016-11-10 >> > 23:01:39.351997560 -0500 >> > +++ ./th/T5976.run/T5976.comp.stderr.normalised 2016-11-10 >> > 23:01:39.351997560 -0500 >> > @@ -1,7 +1,4 @@ >> > - >> > -T5976.hs:1:1: >> > - Exception when trying to run compile-time code: >> > - bar >> > -CallStack (from HasCallStack): >> > - error, called at T5976.hs:: in >> :Main >> > - Code: error ((++) "foo " error "bar") >> > +ghc-iserv.bin: internal loadArchive: GNU-variant filename >> offset not >> > found while reading filename f >> >> Did this line get truncated? It might help to have the rest of it. >> >> Regards, >> Reid Barton >> >> >> >> >> _______________________________________________ >> ghc-devs mailing list >> ghc-devs at haskell.org >> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs > > > > _______________________________________________ > ghc-devs mailing list > ghc-devs at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: 0001-Show-failing-filename.patch Type: text/x-patch Size: 958 bytes Desc: not available URL: From omeragacan at gmail.com Fri Nov 11 17:02:30 2016 From: omeragacan at gmail.com (=?UTF-8?Q?=C3=96mer_Sinan_A=C4=9Facan?=) Date: Fri, 11 Nov 2016 12:02:30 -0500 Subject: 177 unexpected test failures on a new system -- is this yet another linker issue? In-Reply-To: <666e2499-dca7-fdec-4ab9-5f7fe826b927@haskus.fr> References: <666e2499-dca7-fdec-4ab9-5f7fe826b927@haskus.fr> Message-ID: So I just tried validating on another system: > ghc git:(master) $ uname -a Linux linux-enrr.suse 4.1.34-33-default #1 SMP PREEMPT Thu Oct 20 08:03:29 UTC 2016 (fe18aba) x86_64 x86_64 x86_64 GNU/Linux > ghc git:(master) $ gcc --version gcc (SUSE Linux) 4.8.5 Copyright (C) 2015 Free Software Foundation, Inc. This is free software; see the source for copying conditions. There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. > ghc git:(master) $ ld --version GNU ld (GNU Binutils; openSUSE Leap 42.1) 2.26.1 Copyright (C) 2015 Free Software Foundation, Inc. This program is free software; you may redistribute it under the terms of the GNU General Public License version 3 or (at your option) a later version. This program has absolutely no warranty. It validated without any errors. So I can't reproduce it right now. I'll try the patch sometime later today when I have the other laptop with me. Sylvain, do you have any ideas on what difference may be causing this? I'm pasting gcc and ld versions but I'm not sure if they're relevant at all. 2016-11-11 11:55 GMT-05:00 Sylvain Henry : > My bad, in fact we do. > > Could you try with the attached patch? It shows the failing filename in the > archive. > > > On 11/11/2016 17:18, Sylvain Henry wrote: > > It seems like we don't bypass the special filename "/" (symbol lookup table) > in rts/Linker.c > > https://en.wikipedia.org/wiki/Ar_(Unix)#System_V_.28or_GNU.29_variant > > > On 11/11/2016 16:49, Ömer Sinan Ağacan wrote: > > Ah, sorry, that line was truncated. I posted the output here: > https://gist.githubusercontent.com/osa1/ea72655b8369099e84a67e0949adca7e/raw/9e72cbfb859cb839f1898af39a46ff0896237d15/gistfile1.txt > > That line should be > > +ghc-iserv.bin: internal loadArchive: GNU-variant filename offset not found > while reading filename from > `/home/omer/haskell/ghc/libraries/ghc-prim/dist-install/build/libHSghc-prim-0.5.0.0.a' > + (GHC version 8.1.20161107 for x86_64_unknown_linux) > + Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug > > > 2016-11-11 0:52 GMT-05:00 Reid Barton : >> >> On Thu, Nov 10, 2016 at 11:12 PM, Ömer Sinan Ağacan >> wrote: >> > I'm trying to validate on a new system (not sure if related, but it has >> > gcc >> > 6.2.1 and ld 2.27.0), and I'm having 177 unexpected failures, most >> > (maybe >> > even >> > all) of them are similar to this one: >> > >> > =====> T5976(ext-interp) 1 of 1 [0, 0, 0] >> > cd "./th/T5976.run" && "/home/omer/haskell/ghc/inplace/test >> > spaces/ghc-stage2" -c T5976.hs -dcore-dno-debug-output -XTemplateHaskell >> > -package template-haskell -fexternal-interpreter -v0 >> > Actual stderr output differs from expected: >> > --- ./th/T5976.run/T5976.stderr.normalised 2016-11-10 >> > 23:01:39.351997560 -0500 >> > +++ ./th/T5976.run/T5976.comp.stderr.normalised 2016-11-10 >> > 23:01:39.351997560 -0500 >> > @@ -1,7 +1,4 @@ >> > - >> > -T5976.hs:1:1: >> > - Exception when trying to run compile-time code: >> > - bar >> > -CallStack (from HasCallStack): >> > - error, called at T5976.hs:: in :Main >> > - Code: error ((++) "foo " error "bar") >> > +ghc-iserv.bin: internal loadArchive: GNU-variant filename offset >> > not >> > found while reading filename f >> >> Did this line get truncated? It might help to have the rest of it. >> >> Regards, >> Reid Barton > > > > > _______________________________________________ > ghc-devs mailing list > ghc-devs at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs > > > > > _______________________________________________ > ghc-devs mailing list > ghc-devs at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs > > > > _______________________________________________ > ghc-devs mailing list > ghc-devs at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs > From simonpj at microsoft.com Fri Nov 11 17:39:34 2016 From: simonpj at microsoft.com (Simon Peyton Jones) Date: Fri, 11 Nov 2016 17:39:34 +0000 Subject: T12041 failing? In-Reply-To: References: Message-ID: Hmm. Yes, this is an (actually harmless) assertion failure if your build has -DDEBUG on. I think it’s just a fluke that it’s only just started failing. I’ll make a ticket for it; I don’t think it’s super-urgent. Simon From: ghc-devs [mailto:ghc-devs-bounces at haskell.org] On Behalf Of Simon Marlow Sent: 09 November 2016 13:03 To: ghc-devs at haskell.org Subject: T12041 failing? I just saw the error below in a validate with -DDEBUG. Anyone know about this? --- /tmp/ghctest-uhJ8rt/test spaces/./indexed-types/should_fail/T12041.run/T12041.stderr.normalised 2016-11-09 12:13:38.206501840 +0000 +++ /tmp/ghctest-uhJ8rt/test spaces/./indexed-types/should_fail/T12041.run/T12041.comp.stderr.normalised 2016-11-09 12:13:38.206501840 +0000 @@ -1,7 +1,17 @@ +ghc: panic! (the 'impossible' happened) + (GHC version 8.1.20161109 for x86_64-unknown-linux): + ASSERT failed! + i_axb + Call stack: + CallStack (from HasCallStack): + prettyCurrentCallStack, called at compiler/utils/Outputable.hs:: in :Outputable + callStackDoc, called at compiler/utils/Outputable.hs:: in :Outputable + assertPprPanic, called at compiler/typecheck/TcType.hs:: in :TcType + Call stack: + CallStack (from HasCallStack): + prettyCurrentCallStack, called at compiler/utils/Outputable.hs:: in :Outputable + callStackDoc, called at compiler/utils/Outputable.hs:: in :Outputable + pprPanic, called at compiler/utils/Outputable.hs:: in :Outputable + assertPprPanic, called at compiler/typecheck/TcType.hs:: in :TcType -T12041.hs:12:15: - Expected kind ‘i -> Constraint’, - but ‘(~) Int’ has kind ‘* -> Constraint’ - In the type ‘(~) Int’ - In the type instance declaration for ‘Ob’ - In the instance declaration for ‘Category I’ +Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug *** unexpected failure for T12041(normal) -------------- next part -------------- An HTML attachment was scrubbed... URL: From mail at joachim-breitner.de Fri Nov 11 18:57:14 2016 From: mail at joachim-breitner.de (Joachim Breitner) Date: Fri, 11 Nov 2016 13:57:14 -0500 Subject: New home for the perf.haskell.org builder wanted In-Reply-To: <1477351512.14842.9.camel@joachim-breitner.de> References: <1477351512.14842.9.camel@joachim-breitner.de> Message-ID: <1478890634.8366.1.camel@joachim-breitner.de> Hi all, let me bump this request. http://perf.haskell.org/ghc has now stopped producing new results. It does not have to be a fancy server or anything like that; an unused office machine in some corner would do as well, it has done that so far. (I wonder if I should reactivate my T400s for that. Maybe a slow machine yields more precise measurements. But it is in Germany right now, so I won’t be able to do that before Christmas.) Greetings, Joachim Am Montag, den 24.10.2016, 19:25 -0400 schrieb Joachim Breitner: > although I have moved away from Karlsruhe three months ago, so far it > is still my office PC driving > https://perf.haskell.org/ghc/ > > But a new person is now using my desk and wants to use this machine, so > I should really really move this away from there now. > > Sebastian Graf has been working on turning gipeda, the Frontend > perf.haskell.org, into a more general service open to open source > Haskell projects, and this is close, but not close enough to simply > stop running the performance tests until he is good to go. > > He currently has a machine given from haskell.org to run this on, but > it is a virtual machine and the measurements are too flaky for real > use. > > So basically, I need a decent non-virtualized (or virtualized, but > exclusive) machine to move my performance build runner to, as quickly > as possible. The current specs are >  * 8 core Intel(R) Core(TM) i7-3770 CPU @ 3.40GHz  >  * 16 GB RAM > but it does not matter too much, a slightly weaker machine would be > able to keep up as well. I also do not necessarily need root access > (but it would be beyond the point if the machine would do other stuff > that incurs a heavy load). > > The same machine could then be used by Sebastian for his more general > setup, once that is ready to go. > > Does anyone have something handy? > > Greetings, > Joachim > > > _______________________________________________ > ghc-devs mailing list > ghc-devs at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs -- Joachim “nomeata” Breitner   mail at joachim-breitner.de • https://www.joachim-breitner.de/   XMPP: nomeata at joachim-breitner.de • OpenPGP-Key: 0xF0FBF51F   Debian Developer: nomeata at debian.org -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 833 bytes Desc: This is a digitally signed message part URL: From ryan.trinkle at gmail.com Fri Nov 11 19:06:46 2016 From: ryan.trinkle at gmail.com (Ryan Trinkle) Date: Fri, 11 Nov 2016 14:06:46 -0500 Subject: New home for the perf.haskell.org builder wanted In-Reply-To: <1478890634.8366.1.camel@joachim-breitner.de> References: <1477351512.14842.9.camel@joachim-breitner.de> <1478890634.8366.1.camel@joachim-breitner.de> Message-ID: Joachim, Did you see my response earlier? I've pasted it below. Ryan Hi Joachim and Sebastian, I think it would make sense to get a machine like that with Haskell.org funds. My company (Obsidian) would be happy to host it physically and cover internet/power/etc., although our facilities aren't too fancy (no redundant connections or anything like that). Best, Ryan On Fri, Nov 11, 2016 at 1:57 PM, Joachim Breitner wrote: > Hi all, > > let me bump this request. http://perf.haskell.org/ghc has now stopped > producing new results. > > It does not have to be a fancy server or anything like that; an unused > office machine in some corner would do as well, it has done that so > far. (I wonder if I should reactivate my T400s for that. Maybe a slow > machine yields more precise measurements. But it is in Germany right > now, so I won’t be able to do that before Christmas.) > > Greetings, > Joachim > > > Am Montag, den 24.10.2016, 19:25 -0400 schrieb Joachim Breitner: > > although I have moved away from Karlsruhe three months ago, so far it > > is still my office PC driving > > https://perf.haskell.org/ghc/ > > > > But a new person is now using my desk and wants to use this machine, so > > I should really really move this away from there now. > > > > Sebastian Graf has been working on turning gipeda, the Frontend > > perf.haskell.org, into a more general service open to open source > > Haskell projects, and this is close, but not close enough to simply > > stop running the performance tests until he is good to go. > > > > He currently has a machine given from haskell.org to run this on, but > > it is a virtual machine and the measurements are too flaky for real > > use. > > > > So basically, I need a decent non-virtualized (or virtualized, but > > exclusive) machine to move my performance build runner to, as quickly > > as possible. The current specs are > > * 8 core Intel(R) Core(TM) i7-3770 CPU @ 3.40GHz > > * 16 GB RAM > > but it does not matter too much, a slightly weaker machine would be > > able to keep up as well. I also do not necessarily need root access > > (but it would be beyond the point if the machine would do other stuff > > that incurs a heavy load). > > > > The same machine could then be used by Sebastian for his more general > > setup, once that is ready to go. > > > > Does anyone have something handy? > > > > Greetings, > > Joachim > > > > > > _______________________________________________ > > ghc-devs mailing list > > ghc-devs at haskell.org > > http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs > -- > Joachim “nomeata” Breitner > mail at joachim-breitner.de • https://www.joachim-breitner.de/ > XMPP: nomeata at joachim-breitner.de • OpenPGP-Key: 0xF0FBF51F > Debian Developer: nomeata at debian.org > -------------- next part -------------- An HTML attachment was scrubbed... URL: From rae at cs.brynmawr.edu Fri Nov 11 19:15:00 2016 From: rae at cs.brynmawr.edu (Richard Eisenberg) Date: Fri, 11 Nov 2016 14:15:00 -0500 Subject: New home for the perf.haskell.org builder wanted In-Reply-To: <1478890634.8366.1.camel@joachim-breitner.de> References: <1477351512.14842.9.camel@joachim-breitner.de> <1478890634.8366.1.camel@joachim-breitner.de> Message-ID: <7332ACC3-AD10-4012-BD1D-BA896ACCBDDE@cs.brynmawr.edu> I have an unused machine in my department. It currently has 6GB of memory on it, but memory is cheap enough these days, so this could be expanded if necessary. (Is this necessary?) We would slap a basic Linux on it, give it a hostname (xxx.cs.brynmawr.edu), and then make an account for you, Joachim, to ssh into. Are there other setup requirements? It's Friday afternoon, so I'm unsure if we could get it done in the next 24 hours, but I would imagine by early next week. Richard > On Nov 11, 2016, at 1:57 PM, Joachim Breitner wrote: > > Hi all, > > let me bump this request. http://perf.haskell.org/ghc has now stopped > producing new results. > > It does not have to be a fancy server or anything like that; an unused > office machine in some corner would do as well, it has done that so > far. (I wonder if I should reactivate my T400s for that. Maybe a slow > machine yields more precise measurements. But it is in Germany right > now, so I won’t be able to do that before Christmas.) > > Greetings, > Joachim > > > Am Montag, den 24.10.2016, 19:25 -0400 schrieb Joachim Breitner: >> although I have moved away from Karlsruhe three months ago, so far it >> is still my office PC driving >> https://perf.haskell.org/ghc/ >> >> But a new person is now using my desk and wants to use this machine, so >> I should really really move this away from there now. >> >> Sebastian Graf has been working on turning gipeda, the Frontend >> perf.haskell.org, into a more general service open to open source >> Haskell projects, and this is close, but not close enough to simply >> stop running the performance tests until he is good to go. >> >> He currently has a machine given from haskell.org to run this on, but >> it is a virtual machine and the measurements are too flaky for real >> use. >> >> So basically, I need a decent non-virtualized (or virtualized, but >> exclusive) machine to move my performance build runner to, as quickly >> as possible. The current specs are >> * 8 core Intel(R) Core(TM) i7-3770 CPU @ 3.40GHz >> * 16 GB RAM >> but it does not matter too much, a slightly weaker machine would be >> able to keep up as well. I also do not necessarily need root access >> (but it would be beyond the point if the machine would do other stuff >> that incurs a heavy load). >> >> The same machine could then be used by Sebastian for his more general >> setup, once that is ready to go. >> >> Does anyone have something handy? >> >> Greetings, >> Joachim >> >> >> _______________________________________________ >> ghc-devs mailing list >> ghc-devs at haskell.org >> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs > -- > Joachim “nomeata” Breitner > mail at joachim-breitner.de • https://www.joachim-breitner.de/ > XMPP: nomeata at joachim-breitner.de • OpenPGP-Key: 0xF0FBF51F > Debian Developer: nomeata at debian.org_______________________________________________ > ghc-devs mailing list > ghc-devs at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs From mail at joachim-breitner.de Fri Nov 11 19:28:13 2016 From: mail at joachim-breitner.de (Joachim Breitner) Date: Fri, 11 Nov 2016 14:28:13 -0500 Subject: New home for the perf.haskell.org builder wanted In-Reply-To: <7332ACC3-AD10-4012-BD1D-BA896ACCBDDE@cs.brynmawr.edu> References: <1477351512.14842.9.camel@joachim-breitner.de> <1478890634.8366.1.camel@joachim-breitner.de> <7332ACC3-AD10-4012-BD1D-BA896ACCBDDE@cs.brynmawr.edu> Message-ID: <1478892493.8366.5.camel@joachim-breitner.de> Hi, Ryan, I saw your hosting offer, thanks a lot! I must have skipped the past suggesting haskell.org funds for a machine and only saw the hosting offer. But an existing unused machine is just fine. Richard, sounds great!. I should not work on in before Monday anyways. No other requirements necessary. Greetings, Joachim Am Freitag, den 11.11.2016, 14:15 -0500 schrieb Richard Eisenberg: > I have an unused machine in my department. It currently has 6GB of > memory on it, but memory is cheap enough these days, so this could be > expanded if necessary. (Is this necessary?) We would slap a basic > Linux on it, give it a hostname (xxx.cs.brynmawr.edu), and then make > an account for you, Joachim, to ssh into. Are there other setup > requirements? > > It's Friday afternoon, so I'm unsure if we could get it done in the > next 24 hours, but I would imagine by early next week. > > Richard > > > On Nov 11, 2016, at 1:57 PM, Joachim Breitner > r.de> wrote: > > > > Hi all, > > > > let me bump this request. http://perf.haskell.org/ghc has now > > stopped > > producing new results. > > > > It does not have to be a fancy server or anything like that; an > > unused > > office machine in some corner would do as well, it has done that so > > far. (I wonder if I should reactivate my T400s for that. Maybe a > > slow > > machine yields more precise measurements. But it is in Germany > > right > > now, so I won’t be able to do that before Christmas.) > > > > Greetings, > > Joachim > > > > > > Am Montag, den 24.10.2016, 19:25 -0400 schrieb Joachim Breitner: > > > although I have moved away from Karlsruhe three months ago, so > > > far it > > > is still my office PC driving > > > https://perf.haskell.org/ghc/ > > > > > > But a new person is now using my desk and wants to use this > > > machine, so > > > I should really really move this away from there now. > > > > > > Sebastian Graf has been working on turning gipeda, the Frontend > > > perf.haskell.org, into a more general service open to open source > > > Haskell projects, and this is close, but not close enough to > > > simply > > > stop running the performance tests until he is good to go. > > > > > > He currently has a machine given from haskell.org to run this on, > > > but > > > it is a virtual machine and the measurements are too flaky for > > > real > > > use. > > > > > > So basically, I need a decent non-virtualized (or virtualized, > > > but > > > exclusive) machine to move my performance build runner to, as > > > quickly > > > as possible. The current specs are > > >  * 8 core Intel(R) Core(TM) i7-3770 CPU @ 3.40GHz  > > >  * 16 GB RAM > > > but it does not matter too much, a slightly weaker machine would > > > be > > > able to keep up as well. I also do not necessarily need root > > > access > > > (but it would be beyond the point if the machine would do other > > > stuff > > > that incurs a heavy load). > > > > > > The same machine could then be used by Sebastian for his more > > > general > > > setup, once that is ready to go. > > > > > > Does anyone have something handy? > > > > > > Greetings, > > > Joachim > > > > > > > > > _______________________________________________ > > > ghc-devs mailing list > > > ghc-devs at haskell.org > > > http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs > > > > --  > > Joachim “nomeata” Breitner > >   mail at joachim-breitner.de • https://www.joachim-breitner.de/ > >   XMPP: nomeata at joachim-breitner.de • OpenPGP-Key: 0xF0FBF51F > >   Debian Developer: nomeata at debian.org_____________________________ > > __________________ > > ghc-devs mailing list > > ghc-devs at haskell.org > > http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs > > -- Joachim Breitner mail at joachim-breitner.de http://www.joachim-breitner.de/ -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 833 bytes Desc: This is a digitally signed message part URL: From omeragacan at gmail.com Fri Nov 11 21:26:18 2016 From: omeragacan at gmail.com (=?UTF-8?Q?=C3=96mer_Sinan_A=C4=9Facan?=) Date: Fri, 11 Nov 2016 16:26:18 -0500 Subject: 177 unexpected test failures on a new system -- is this yet another linker issue? In-Reply-To: References: <666e2499-dca7-fdec-4ab9-5f7fe826b927@haskus.fr> Message-ID: Sylvain, I tried your patch, here's the output: cd "./th/T5976.run" && "/home/omer/haskell/ghc/inplace/test spaces/ghc-stage2" -c T5976.hs -dcore-lint -dcmm-lint -no-user-package-db -rtsopts -fno-warn-missed-specialisations -fshow-warning-groups -dno-debug-output -XTemplateHaskell -package template-haskell -fexternal-interpreter -v0 Actual stderr output differs from expected: --- ./th/T5976.run/T5976.stderr.normalised 2016-11-11 16:22:02.247761214 -0500 +++ ./th/T5976.run/T5976.comp.stderr.normalised 2016-11-11 16:22:02.247761214 -0500 @@ -1,7 +1,4 @@ - -T5976.hs:1:1: - Exception when trying to run compile-time code: - bar -CallStack (from HasCallStack): - error, called at T5976.hs:: in :Main - Code: error ((++) "foo " error "bar") +ghc-iserv.bin: internal loadArchive: invalid GNU-variant filename `/SYM64/ ' found while reading `/home/omer/haskell/ghc/libraries/ghc-prim/dist-install/build/libHSghc-prim-0.5.0.0.a' + (GHC version 8.1.20161107 for x86_64_unknown_linux) + Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug +ghc: ghc-iserv terminated (-6) *** unexpected failure for T5976(ext-interp) Unexpected results from: TEST="T5976" 2016-11-11 12:02 GMT-05:00 Ömer Sinan Ağacan : > So I just tried validating on another system: > > > ghc git:(master) $ uname -a > Linux linux-enrr.suse 4.1.34-33-default #1 SMP PREEMPT Thu Oct 20 08:03:29 > UTC 2016 (fe18aba) x86_64 x86_64 x86_64 GNU/Linux > > > ghc git:(master) $ gcc --version > gcc (SUSE Linux) 4.8.5 > Copyright (C) 2015 Free Software Foundation, Inc. > This is free software; see the source for copying conditions. There is NO > warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. > > > ghc git:(master) $ ld --version > GNU ld (GNU Binutils; openSUSE Leap 42.1) 2.26.1 > Copyright (C) 2015 Free Software Foundation, Inc. > This program is free software; you may redistribute it under the terms of > the GNU General Public License version 3 or (at your option) a later > version. > This program has absolutely no warranty. > > It validated without any errors. So I can't reproduce it right now. I'll try > the patch sometime later today when I have the other laptop with me. > > Sylvain, do you have any ideas on what difference may be causing this? I'm > pasting gcc and ld versions but I'm not sure if they're relevant at all. > > 2016-11-11 11:55 GMT-05:00 Sylvain Henry : >> My bad, in fact we do. >> >> Could you try with the attached patch? It shows the failing filename in the >> archive. >> >> >> On 11/11/2016 17:18, Sylvain Henry wrote: >> >> It seems like we don't bypass the special filename "/" (symbol lookup table) >> in rts/Linker.c >> >> https://en.wikipedia.org/wiki/Ar_(Unix)#System_V_.28or_GNU.29_variant >> >> >> On 11/11/2016 16:49, Ömer Sinan Ağacan wrote: >> >> Ah, sorry, that line was truncated. I posted the output here: >> https://gist.githubusercontent.com/osa1/ea72655b8369099e84a67e0949adca7e/raw/9e72cbfb859cb839f1898af39a46ff0896237d15/gistfile1.txt >> >> That line should be >> >> +ghc-iserv.bin: internal loadArchive: GNU-variant filename offset not found >> while reading filename from >> `/home/omer/haskell/ghc/libraries/ghc-prim/dist-install/build/libHSghc-prim-0.5.0.0.a' >> + (GHC version 8.1.20161107 for x86_64_unknown_linux) >> + Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug >> >> >> 2016-11-11 0:52 GMT-05:00 Reid Barton : >>> >>> On Thu, Nov 10, 2016 at 11:12 PM, Ömer Sinan Ağacan >>> wrote: >>> > I'm trying to validate on a new system (not sure if related, but it has >>> > gcc >>> > 6.2.1 and ld 2.27.0), and I'm having 177 unexpected failures, most >>> > (maybe >>> > even >>> > all) of them are similar to this one: >>> > >>> > =====> T5976(ext-interp) 1 of 1 [0, 0, 0] >>> > cd "./th/T5976.run" && "/home/omer/haskell/ghc/inplace/test >>> > spaces/ghc-stage2" -c T5976.hs -dcore-dno-debug-output -XTemplateHaskell >>> > -package template-haskell -fexternal-interpreter -v0 >>> > Actual stderr output differs from expected: >>> > --- ./th/T5976.run/T5976.stderr.normalised 2016-11-10 >>> > 23:01:39.351997560 -0500 >>> > +++ ./th/T5976.run/T5976.comp.stderr.normalised 2016-11-10 >>> > 23:01:39.351997560 -0500 >>> > @@ -1,7 +1,4 @@ >>> > - >>> > -T5976.hs:1:1: >>> > - Exception when trying to run compile-time code: >>> > - bar >>> > -CallStack (from HasCallStack): >>> > - error, called at T5976.hs:: in :Main >>> > - Code: error ((++) "foo " error "bar") >>> > +ghc-iserv.bin: internal loadArchive: GNU-variant filename offset >>> > not >>> > found while reading filename f >>> >>> Did this line get truncated? It might help to have the rest of it. >>> >>> Regards, >>> Reid Barton >> >> >> >> >> _______________________________________________ >> ghc-devs mailing list >> ghc-devs at haskell.org >> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs >> >> >> >> >> _______________________________________________ >> ghc-devs mailing list >> ghc-devs at haskell.org >> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs >> >> >> >> _______________________________________________ >> ghc-devs mailing list >> ghc-devs at haskell.org >> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs >> From sylvain at haskus.fr Sat Nov 12 00:06:45 2016 From: sylvain at haskus.fr (Sylvain Henry) Date: Sat, 12 Nov 2016 01:06:45 +0100 Subject: 177 unexpected test failures on a new system -- is this yet another linker issue? In-Reply-To: References: <666e2499-dca7-fdec-4ab9-5f7fe826b927@haskus.fr> Message-ID: <3c9a2f53-013c-ef27-68bb-2a9f4f304455@haskus.fr> Ok so it seems to be a 64-bit symbol table (according to https://docs.oracle.com/cd/E53394_01/html/E54772/ar-3head.html): > A 64-bit archive symbol table sets ar_name to the string “/SYM64/”, padded with 9 blank characters to the right." We should skip it. I will make a patch. Thanks for the report! Sylvain On 11/11/2016 22:26, Ömer Sinan Ağacan wrote: > Sylvain, I tried your patch, here's the output: > > > cd "./th/T5976.run" && "/home/omer/haskell/ghc/inplace/test > spaces/ghc-stage2" -c T5976.hs -dcore-lint -dcmm-lint > -no-user-package-db -rtsopts -fno-warn-missed-specialisations > -fshow-warning-groups -dno-debug-output -XTemplateHaskell -package > template-haskell -fexternal-interpreter -v0 > Actual stderr output differs from expected: > --- ./th/T5976.run/T5976.stderr.normalised 2016-11-11 > 16:22:02.247761214 -0500 > +++ ./th/T5976.run/T5976.comp.stderr.normalised 2016-11-11 > 16:22:02.247761214 -0500 > @@ -1,7 +1,4 @@ > - > -T5976.hs:1:1: > - Exception when trying to run compile-time code: > - bar > -CallStack (from HasCallStack): > - error, called at T5976.hs:: in :Main > - Code: error ((++) "foo " error "bar") > +ghc-iserv.bin: internal loadArchive: invalid GNU-variant filename > `/SYM64/ ' found while reading > `/home/omer/haskell/ghc/libraries/ghc-prim/dist-install/build/libHSghc-prim-0.5.0.0.a' > + (GHC version 8.1.20161107 for x86_64_unknown_linux) > + Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug > +ghc: ghc-iserv terminated (-6) > *** unexpected failure for T5976(ext-interp) > > Unexpected results from: > TEST="T5976" > > 2016-11-11 12:02 GMT-05:00 Ömer Sinan Ağacan : >> So I just tried validating on another system: >> >> > ghc git:(master) $ uname -a >> Linux linux-enrr.suse 4.1.34-33-default #1 SMP PREEMPT Thu Oct 20 08:03:29 >> UTC 2016 (fe18aba) x86_64 x86_64 x86_64 GNU/Linux >> >> > ghc git:(master) $ gcc --version >> gcc (SUSE Linux) 4.8.5 >> Copyright (C) 2015 Free Software Foundation, Inc. >> This is free software; see the source for copying conditions. There is NO >> warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. >> >> > ghc git:(master) $ ld --version >> GNU ld (GNU Binutils; openSUSE Leap 42.1) 2.26.1 >> Copyright (C) 2015 Free Software Foundation, Inc. >> This program is free software; you may redistribute it under the terms of >> the GNU General Public License version 3 or (at your option) a later >> version. >> This program has absolutely no warranty. >> >> It validated without any errors. So I can't reproduce it right now. I'll try >> the patch sometime later today when I have the other laptop with me. >> >> Sylvain, do you have any ideas on what difference may be causing this? I'm >> pasting gcc and ld versions but I'm not sure if they're relevant at all. >> >> 2016-11-11 11:55 GMT-05:00 Sylvain Henry : >>> My bad, in fact we do. >>> >>> Could you try with the attached patch? It shows the failing filename in the >>> archive. >>> >>> >>> On 11/11/2016 17:18, Sylvain Henry wrote: >>> >>> It seems like we don't bypass the special filename "/" (symbol lookup table) >>> in rts/Linker.c >>> >>> https://en.wikipedia.org/wiki/Ar_(Unix)#System_V_.28or_GNU.29_variant >>> >>> >>> On 11/11/2016 16:49, Ömer Sinan Ağacan wrote: >>> >>> Ah, sorry, that line was truncated. I posted the output here: >>> https://gist.githubusercontent.com/osa1/ea72655b8369099e84a67e0949adca7e/raw/9e72cbfb859cb839f1898af39a46ff0896237d15/gistfile1.txt >>> >>> That line should be >>> >>> +ghc-iserv.bin: internal loadArchive: GNU-variant filename offset not found >>> while reading filename from >>> `/home/omer/haskell/ghc/libraries/ghc-prim/dist-install/build/libHSghc-prim-0.5.0.0.a' >>> + (GHC version 8.1.20161107 for x86_64_unknown_linux) >>> + Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug >>> >>> >>> 2016-11-11 0:52 GMT-05:00 Reid Barton : >>>> On Thu, Nov 10, 2016 at 11:12 PM, Ömer Sinan Ağacan >>>> wrote: >>>>> I'm trying to validate on a new system (not sure if related, but it has >>>>> gcc >>>>> 6.2.1 and ld 2.27.0), and I'm having 177 unexpected failures, most >>>>> (maybe >>>>> even >>>>> all) of them are similar to this one: >>>>> >>>>> =====> T5976(ext-interp) 1 of 1 [0, 0, 0] >>>>> cd "./th/T5976.run" && "/home/omer/haskell/ghc/inplace/test >>>>> spaces/ghc-stage2" -c T5976.hs -dcore-dno-debug-output -XTemplateHaskell >>>>> -package template-haskell -fexternal-interpreter -v0 >>>>> Actual stderr output differs from expected: >>>>> --- ./th/T5976.run/T5976.stderr.normalised 2016-11-10 >>>>> 23:01:39.351997560 -0500 >>>>> +++ ./th/T5976.run/T5976.comp.stderr.normalised 2016-11-10 >>>>> 23:01:39.351997560 -0500 >>>>> @@ -1,7 +1,4 @@ >>>>> - >>>>> -T5976.hs:1:1: >>>>> - Exception when trying to run compile-time code: >>>>> - bar >>>>> -CallStack (from HasCallStack): >>>>> - error, called at T5976.hs:: in :Main >>>>> - Code: error ((++) "foo " error "bar") >>>>> +ghc-iserv.bin: internal loadArchive: GNU-variant filename offset >>>>> not >>>>> found while reading filename f >>>> Did this line get truncated? It might help to have the rest of it. >>>> >>>> Regards, >>>> Reid Barton >>> >>> >>> >>> _______________________________________________ >>> ghc-devs mailing list >>> ghc-devs at haskell.org >>> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs >>> >>> >>> >>> >>> _______________________________________________ >>> ghc-devs mailing list >>> ghc-devs at haskell.org >>> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs >>> >>> >>> >>> _______________________________________________ >>> ghc-devs mailing list >>> ghc-devs at haskell.org >>> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs >>> From ryan.trinkle at gmail.com Sat Nov 12 00:14:01 2016 From: ryan.trinkle at gmail.com (Ryan Trinkle) Date: Fri, 11 Nov 2016 19:14:01 -0500 Subject: New home for the perf.haskell.org builder wanted In-Reply-To: <1478892493.8366.5.camel@joachim-breitner.de> References: <1477351512.14842.9.camel@joachim-breitner.de> <1478890634.8366.1.camel@joachim-breitner.de> <7332ACC3-AD10-4012-BD1D-BA896ACCBDDE@cs.brynmawr.edu> <1478892493.8366.5.camel@joachim-breitner.de> Message-ID: OK, great! Definitely happy to help in some other way if makes sense. On Fri, Nov 11, 2016 at 2:28 PM, Joachim Breitner wrote: > Hi, > > Ryan, I saw your hosting offer, thanks a lot! I must have skipped the > past suggesting haskell.org funds for a machine and only saw the > hosting offer. But an existing unused machine is just fine. > > Richard, sounds great!. I should not work on in before Monday anyways. > No other requirements necessary. > > Greetings, > Joachim > > Am Freitag, den 11.11.2016, 14:15 -0500 schrieb Richard Eisenberg: > > I have an unused machine in my department. It currently has 6GB of > > memory on it, but memory is cheap enough these days, so this could be > > expanded if necessary. (Is this necessary?) We would slap a basic > > Linux on it, give it a hostname (xxx.cs.brynmawr.edu), and then make > > an account for you, Joachim, to ssh into. Are there other setup > > requirements? > > > > It's Friday afternoon, so I'm unsure if we could get it done in the > > next 24 hours, but I would imagine by early next week. > > > > Richard > > > > > On Nov 11, 2016, at 1:57 PM, Joachim Breitner > > r.de> wrote: > > > > > > Hi all, > > > > > > let me bump this request. http://perf.haskell.org/ghc has now > > > stopped > > > producing new results. > > > > > > It does not have to be a fancy server or anything like that; an > > > unused > > > office machine in some corner would do as well, it has done that so > > > far. (I wonder if I should reactivate my T400s for that. Maybe a > > > slow > > > machine yields more precise measurements. But it is in Germany > > > right > > > now, so I won’t be able to do that before Christmas.) > > > > > > Greetings, > > > Joachim > > > > > > > > > Am Montag, den 24.10.2016, 19:25 -0400 schrieb Joachim Breitner: > > > > although I have moved away from Karlsruhe three months ago, so > > > > far it > > > > is still my office PC driving > > > > https://perf.haskell.org/ghc/ > > > > > > > > But a new person is now using my desk and wants to use this > > > > machine, so > > > > I should really really move this away from there now. > > > > > > > > Sebastian Graf has been working on turning gipeda, the Frontend > > > > perf.haskell.org, into a more general service open to open source > > > > Haskell projects, and this is close, but not close enough to > > > > simply > > > > stop running the performance tests until he is good to go. > > > > > > > > He currently has a machine given from haskell.org to run this on, > > > > but > > > > it is a virtual machine and the measurements are too flaky for > > > > real > > > > use. > > > > > > > > So basically, I need a decent non-virtualized (or virtualized, > > > > but > > > > exclusive) machine to move my performance build runner to, as > > > > quickly > > > > as possible. The current specs are > > > > * 8 core Intel(R) Core(TM) i7-3770 CPU @ 3.40GHz > > > > * 16 GB RAM > > > > but it does not matter too much, a slightly weaker machine would > > > > be > > > > able to keep up as well. I also do not necessarily need root > > > > access > > > > (but it would be beyond the point if the machine would do other > > > > stuff > > > > that incurs a heavy load). > > > > > > > > The same machine could then be used by Sebastian for his more > > > > general > > > > setup, once that is ready to go. > > > > > > > > Does anyone have something handy? > > > > > > > > Greetings, > > > > Joachim > > > > > > > > > > > > _______________________________________________ > > > > ghc-devs mailing list > > > > ghc-devs at haskell.org > > > > http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs > > > > > > -- > > > Joachim “nomeata” Breitner > > > mail at joachim-breitner.de • https://www.joachim-breitner.de/ > > > XMPP: nomeata at joachim-breitner.de • OpenPGP-Key: 0xF0FBF51F > > > Debian Developer: nomeata at debian.org_____________________________ > > > __________________ > > > ghc-devs mailing list > > > ghc-devs at haskell.org > > > http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs > > > > > -- > Joachim Breitner > mail at joachim-breitner.de > http://www.joachim-breitner.de/ > -------------- next part -------------- An HTML attachment was scrubbed... URL: From alan.zimm at gmail.com Sat Nov 12 10:12:03 2016 From: alan.zimm at gmail.com (Alan & Kim Zimmerman) Date: Sat, 12 Nov 2016 12:12:03 +0200 Subject: GHC pretty printer philosophy Message-ID: I am currently working on #3384, with the intent of ensuring that parse (ppr (parse source)) == parse source I have hit the issue where foo :: (Int) has the parens reflected in the original parsed AST, but the types pretty printer goes to a lot of trouble to remove any parens not required to interpret the meaning of the type. So the question is, should the default ppr faithfully reproduce the source that was parsed to generate the given AST, or simplify it? >From a round-tripping perspective I prefer the former, but there are other use cases where the current behaviour is preferred. If the original is preferred, it can perhaps be enabled via a flag to the pretty printer, but before doing that I want to see if it actually matters. Alan -------------- next part -------------- An HTML attachment was scrubbed... URL: From rae at cs.brynmawr.edu Sat Nov 12 22:44:52 2016 From: rae at cs.brynmawr.edu (Richard Eisenberg) Date: Sat, 12 Nov 2016 17:44:52 -0500 Subject: GHC pretty printer philosophy In-Reply-To: References: Message-ID: <888D721E-4DE2-4474-8C6D-757272343138@cs.brynmawr.edu> I'm afraid I've lost track of where this discussion took place (does someone else remember seeing it?), but I've advocated for faithful reproduction in the past. In particular, the pretty-printers for HsSyn should, in my opinion, never add or remove parentheses. There is a problem here, though: sometimes HsSyn is produced within GHC (for example, in the implementation of `deriving`, or in splicing TH, among a few other spots). This HsSyn can get away with missing parentheses, because it's built as an unambiguous AST. But if the pretty-printer is always faithful, then pretty-printing such an AST will produce an unparsable string. Perhaps the answer is that the generated code should be generous with parentheses -- essentially moving the paren-adding code from today's pretty-printer to the generation sites. Bottom line here: I fully support this direction of travel, but it's not without bumps in the road. Richard > On Nov 12, 2016, at 5:12 AM, Alan & Kim Zimmerman wrote: > > I am currently working on #3384, with the intent of ensuring that > > parse (ppr (parse source)) == parse source > > I have hit the issue where > > foo :: (Int) > > has the parens reflected in the original parsed AST, but the types pretty printer goes to a lot of trouble to remove any parens not required to interpret the meaning of the type. > > So the question is, should the default ppr faithfully reproduce the source that was parsed to generate the given AST, or simplify it? > > From a round-tripping perspective I prefer the former, but there are other use cases where the current behaviour is preferred. > > If the original is preferred, it can perhaps be enabled via a flag to the pretty printer, but before doing that I want to see if it actually matters. > > Alan > > > _______________________________________________ > ghc-devs mailing list > ghc-devs at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs From leo at halfaya.org Sat Nov 12 22:48:04 2016 From: leo at halfaya.org (John Leo) Date: Sat, 12 Nov 2016 14:48:04 -0800 Subject: build fail with latest 8.1 sources Message-ID: Hi everyone, I'm trying to build the latest 8.1 sources on a Mac running El Capitan. I'm getting an error I'd never seen before and wonder if anyone has any pointers of how I might fix things. I blew away my GHC, re-cloned from github, reconfigured and I still get the same error. The following are the relevant output lines; the problem is that the template-haskell version doesn't seem to match. I'm not sure whether this is coming from the template-haskell in 8.1 or in 8.0.1 (which I'm using to build 8.1), but checking the latter I have version 2.11.0.0 which I assume should be sufficient. John -------------------- Configuring ghc-pkg-6.9... Configuring ghc-8.1... ghc-cabal: Encountered missing dependencies: template-haskell ==2.11.* && ==2.12.0.0 make[1]: *** [compiler/stage1/package-data.mk] Error 1 make[1]: *** Waiting for unfinished jobs.... make: *** [all] Error 2 ---------------- internal-229:~/haskell/ghc> cabal update (git)-[master] Downloading the latest package list from hackage.haskell.org Skipping download: local and remote files match. internal-229:~/haskell/ghc> cabal install template-haskell (git)-[master] Resolving dependencies... All the requested packages are already installed: template-haskell-2.11.0.0 Use --reinstall if you want to reinstall anyway. -------------- next part -------------- An HTML attachment was scrubbed... URL: From leo at halfaya.org Sat Nov 12 23:06:30 2016 From: leo at halfaya.org (John Leo) Date: Sat, 12 Nov 2016 15:06:30 -0800 Subject: build fail with latest 8.1 sources In-Reply-To: References: Message-ID: Looking more closely at the log output it appears there were some errors or at least warnings earlier in the output, including for template haskell, so I've attached the full output. I'll continue to investigate on my machine, but again if anyone has pointers I'd appreciate it. I've build 8.1 many times and never seen this problem before. John On Sat, Nov 12, 2016 at 2:48 PM, John Leo wrote: > Hi everyone, > > I'm trying to build the latest 8.1 sources on a Mac running El Capitan. > I'm getting an error I'd never seen before and wonder if anyone has any > pointers of how I might fix things. I blew away my GHC, re-cloned from > github, reconfigured and I still get the same error. > > The following are the relevant output lines; the problem is that the > template-haskell version doesn't seem to match. I'm not sure whether this > is coming from the template-haskell in 8.1 or in 8.0.1 (which I'm using to > build 8.1), but checking the latter I have version 2.11.0.0 which I assume > should be sufficient. > > John > > -------------------- > > Configuring ghc-pkg-6.9... > Configuring ghc-8.1... > ghc-cabal: Encountered missing dependencies: > template-haskell ==2.11.* && ==2.12.0.0 > make[1]: *** [compiler/stage1/package-data.mk] Error 1 > make[1]: *** Waiting for unfinished jobs.... > make: *** [all] Error 2 > > ---------------- > > internal-229:~/haskell/ghc> cabal update > > (git)-[master] > Downloading the latest package list from hackage.haskell.org > Skipping download: local and remote files match. > internal-229:~/haskell/ghc> cabal install template-haskell > > (git)-[master] > Resolving dependencies... > All the requested packages are already installed: > template-haskell-2.11.0.0 > Use --reinstall if you want to reinstall anyway. > -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: buildFailure20161112 Type: application/octet-stream Size: 85225 bytes Desc: not available URL: From simonpj at microsoft.com Sat Nov 12 23:16:57 2016 From: simonpj at microsoft.com (Simon Peyton Jones) Date: Sat, 12 Nov 2016 23:16:57 +0000 Subject: build fail with latest 8.1 sources In-Reply-To: References: Message-ID: I’ve seen a very recent commit that mentioned bumping a TH bound. Maybe pull, make clean and try again? Simon From: ghc-devs [mailto:ghc-devs-bounces at haskell.org] On Behalf Of John Leo Sent: 12 November 2016 22:48 To: ghc-devs Subject: build fail with latest 8.1 sources Hi everyone, I'm trying to build the latest 8.1 sources on a Mac running El Capitan. I'm getting an error I'd never seen before and wonder if anyone has any pointers of how I might fix things. I blew away my GHC, re-cloned from github, reconfigured and I still get the same error. The following are the relevant output lines; the problem is that the template-haskell version doesn't seem to match. I'm not sure whether this is coming from the template-haskell in 8.1 or in 8.0.1 (which I'm using to build 8.1), but checking the latter I have version 2.11.0.0 which I assume should be sufficient. John -------------------- Configuring ghc-pkg-6.9... Configuring ghc-8.1... ghc-cabal: Encountered missing dependencies: template-haskell ==2.11.* && ==2.12.0.0 make[1]: *** [compiler/stage1/package-data.mk] Error 1 make[1]: *** Waiting for unfinished jobs.... make: *** [all] Error 2 ---------------- internal-229:~/haskell/ghc> cabal update (git)-[master] Downloading the latest package list from hackage.haskell.org Skipping download: local and remote files match. internal-229:~/haskell/ghc> cabal install template-haskell (git)-[master] Resolving dependencies... All the requested packages are already installed: template-haskell-2.11.0.0 Use --reinstall if you want to reinstall anyway. -------------- next part -------------- An HTML attachment was scrubbed... URL: From simonpj at microsoft.com Sat Nov 12 23:17:45 2016 From: simonpj at microsoft.com (Simon Peyton Jones) Date: Sat, 12 Nov 2016 23:17:45 +0000 Subject: Windows build broken -- again Message-ID: Sigh. The Simon PJ Windows Buildbot reports "inplace/bin/ghc-stage1.exe" -optc-fno-stack-protector -optc-Wall -optc-Werror -optc-Wall -optc-Wextra -optc-Wstrict-prototypes -optc-Wmissing-prototypes -optc-Wmissing-declarations -optc-Winline -optc-Waggregate-return -optc-Wpointer-arith -optc-Wmissing-noreturn -optc-Wnested-externs -optc-Wredundant-decls -optc-Iincludes -optc-Iincludes/dist -optc-Iincludes/dist-derivedconstants/header -optc-Iincludes/dist-ghcconstants/header -optc-Irts -optc-Irts/dist/build -optc-DCOMPILING_RTS -optc-fno-strict-aliasing -optc-fno-common -optc-Irts/dist/build/./autogen -optc-Wno-error=inline -optc-O2 -optc-fomit-frame-pointer -optc-g -optc-DRtsWay=\"rts_v\" -optc-DWINVER=0x06000100 -static -O0 -H64m -Wall -fllvm-fill-undef-with-garbage -Werror -Iincludes -Iincludes/dist -Iincludes/dist-derivedconstants/header -Iincludes/dist-ghcconstants/header -Irts -Irts/dist/build -DCOMPILING_RTS -this-unit-id rts -dcmm-lint -i -irts -irts/dist/build -Irts/dist/build -irts/dist/build/./autogen -Irts/dist/build/./autogen -O2 -Wnoncanonical-monad-instances -c rts/CheckUnload.c -o rts/dist/build/CheckUnload.o In file included from rts\CheckUnload.c:16:0: error: rts\LinkerInternals.h:284:15: error: error: unknown type name 'UChar' STATIC_INLINE UChar * ^ rts\LinkerInternals.h: In function 'myindex': rts\LinkerInternals.h:288:11: error: error: 'UChar' undeclared (first use in this function) ((UChar*)base) + scale * index; ^ rts\LinkerInternals.h:288:11: error: note: each undeclared identifier is reported only once for each function it appears in rts\LinkerInternals.h:288:17: error: error: expected expression before ')' token ((UChar*)base) + scale * index; ^ rts\LinkerInternals.h:285:28: error: error: unused parameter 'base' [-Werror=unused-parameter] myindex ( int scale, void* base, int index ) ^ rts\LinkerInternals.h: At top level: rts\LinkerInternals.h:292:5: error: error: unknown type name 'UChar' UChar* name, ^ rts\LinkerInternals.h:293:5: error: error: unknown type name 'UChar' UChar* strtab); ^ cc1.exe: all warnings being treated as errors `gcc.exe' failed in phase `C Compiler'. (Exit code: 1) make[1]: *** [rts/ghc.mk:255: rts/dist/build/CheckUnload.o] Error 1 make[1]: *** Waiting for unfinished jobs.... make: *** [Makefile:127: all] Error 2 /c/code/HEAD-1$ -------------- next part -------------- An HTML attachment was scrubbed... URL: From leo at halfaya.org Sat Nov 12 23:19:10 2016 From: leo at halfaya.org (John Leo) Date: Sat, 12 Nov 2016 15:19:10 -0800 Subject: build fail with latest 8.1 sources In-Reply-To: References: Message-ID: That's exactly what I did--in fact clone a fresh GHC and try again, but no luck. I attached the full logs in my second message, which have the details--let me know if the attachment is not readable. Thanks very much for your help. John On Sat, Nov 12, 2016 at 3:16 PM, Simon Peyton Jones wrote: > I’ve seen a very recent commit that mentioned bumping a TH bound. Maybe > pull, make clean and try again? > > > > Simon > > > > *From:* ghc-devs [mailto:ghc-devs-bounces at haskell.org] *On Behalf Of *John > Leo > *Sent:* 12 November 2016 22:48 > *To:* ghc-devs > *Subject:* build fail with latest 8.1 sources > > > > Hi everyone, > > > > I'm trying to build the latest 8.1 sources on a Mac running El Capitan. > I'm getting an error I'd never seen before and wonder if anyone has any > pointers of how I might fix things. I blew away my GHC, re-cloned from > github, reconfigured and I still get the same error. > > > > The following are the relevant output lines; the problem is that the > template-haskell version doesn't seem to match. I'm not sure whether this > is coming from the template-haskell in 8.1 or in 8.0.1 (which I'm using to > build 8.1), but checking the latter I have version 2.11.0.0 which I assume > should be sufficient. > > > > John > > > > -------------------- > > > > Configuring ghc-pkg-6.9... > > Configuring ghc-8.1... > > ghc-cabal: Encountered missing dependencies: > > template-haskell ==2.11.* && ==2.12.0.0 > > make[1]: *** [compiler/stage1/package-data.mk > ] > Error 1 > > make[1]: *** Waiting for unfinished jobs.... > > make: *** [all] Error 2 > > > > ---------------- > > > > internal-229:~/haskell/ghc> cabal update > > (git)-[master] > > Downloading the latest package list from hackage.haskell.org > > > Skipping download: local and remote files match. > > internal-229:~/haskell/ghc> cabal install template-haskell > > (git)-[master] > > Resolving dependencies... > > All the requested packages are already installed: > > template-haskell-2.11.0.0 > > Use --reinstall if you want to reinstall anyway. > -------------- next part -------------- An HTML attachment was scrubbed... URL: From mle+hs at mega-nerd.com Sat Nov 12 23:36:00 2016 From: mle+hs at mega-nerd.com (Erik de Castro Lopo) Date: Sun, 13 Nov 2016 10:36:00 +1100 Subject: Windows build broken -- again In-Reply-To: References: Message-ID: <20161113103600.1072fa4498ba33fdc8905383@mega-nerd.com> Simon Peyton Jones via ghc-devs wrote: > In file included from rts\CheckUnload.c:16:0: error: > > > > rts\LinkerInternals.h:284:15: error: > > error: unknown type name 'UChar' > > STATIC_INLINE UChar * There's a patch up on Phab that should fix that: https://phabricator.haskell.org/D2700 Erik -- ---------------------------------------------------------------------- Erik de Castro Lopo http://www.mega-nerd.com/ From leo at halfaya.org Sun Nov 13 01:21:06 2016 From: leo at halfaya.org (John Leo) Date: Sat, 12 Nov 2016 17:21:06 -0800 Subject: build fail with latest 8.1 sources In-Reply-To: References: Message-ID: I just pulled again and picked up a more recent patch by Ben Gamari: https://github.com/ghc/ghc/commit/ca1b986074757efff755c33c7f9a62c7eae43c7f This seems to have fixed the problem. The commit says 8 hours ago but for some reason I didn't pick it up 2 or 3 hours ago when I last pulled. John On Sat, Nov 12, 2016 at 3:19 PM, John Leo wrote: > That's exactly what I did--in fact clone a fresh GHC and try again, but no > luck. I attached the full logs in my second message, which have the > details--let me know if the attachment is not readable. Thanks very much > for your help. > > John > > On Sat, Nov 12, 2016 at 3:16 PM, Simon Peyton Jones > wrote: > >> I’ve seen a very recent commit that mentioned bumping a TH bound. Maybe >> pull, make clean and try again? >> >> >> >> Simon >> >> >> >> *From:* ghc-devs [mailto:ghc-devs-bounces at haskell.org] *On Behalf Of *John >> Leo >> *Sent:* 12 November 2016 22:48 >> *To:* ghc-devs >> *Subject:* build fail with latest 8.1 sources >> >> >> >> Hi everyone, >> >> >> >> I'm trying to build the latest 8.1 sources on a Mac running El Capitan. >> I'm getting an error I'd never seen before and wonder if anyone has any >> pointers of how I might fix things. I blew away my GHC, re-cloned from >> github, reconfigured and I still get the same error. >> >> >> >> The following are the relevant output lines; the problem is that the >> template-haskell version doesn't seem to match. I'm not sure whether this >> is coming from the template-haskell in 8.1 or in 8.0.1 (which I'm using to >> build 8.1), but checking the latter I have version 2.11.0.0 which I assume >> should be sufficient. >> >> >> >> John >> >> >> >> -------------------- >> >> >> >> Configuring ghc-pkg-6.9... >> >> Configuring ghc-8.1... >> >> ghc-cabal: Encountered missing dependencies: >> >> template-haskell ==2.11.* && ==2.12.0.0 >> >> make[1]: *** [compiler/stage1/package-data.mk >> ] >> Error 1 >> >> make[1]: *** Waiting for unfinished jobs.... >> >> make: *** [all] Error 2 >> >> >> >> ---------------- >> >> >> >> internal-229:~/haskell/ghc> cabal update >> >> (git)-[master] >> >> Downloading the latest package list from hackage.haskell.org >> >> >> Skipping download: local and remote files match. >> >> internal-229:~/haskell/ghc> cabal install template-haskell >> >> (git)-[master] >> >> Resolving dependencies... >> >> All the requested packages are already installed: >> >> template-haskell-2.11.0.0 >> >> Use --reinstall if you want to reinstall anyway. >> > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From harendra.kumar at gmail.com Sun Nov 13 10:40:05 2016 From: harendra.kumar at gmail.com (Harendra Kumar) Date: Sun, 13 Nov 2016 16:10:05 +0530 Subject: data families syntax Message-ID: I am curious about why the data families syntax was chosen to be the way it is. For example a list can be defined as follows: data family List a data instance List Char = Empty | Cons Char (List Char) data instance List () = Count Int Instead why not define it as: data List :: * -> * data List Char = Empty | Cons Char (List Char) data List () = Count Int The latter form looks more intuitive and easy to remember to me since it is very similar to the way value level functions are defined (signature & pattern matching defs). Here we are just defining a type level function instead. -harendra -------------- next part -------------- An HTML attachment was scrubbed... URL: From harendra.kumar at gmail.com Sun Nov 13 12:01:34 2016 From: harendra.kumar at gmail.com (Harendra Kumar) Date: Sun, 13 Nov 2016 17:31:34 +0530 Subject: data families syntax In-Reply-To: References: Message-ID: Answering my own question, which means I did not do enough research before asking. I found two points that I missed earlier: 1) data families are open in contrast to value level functions i.e. you can add more instances later on hence the family and instance keywords make sense. 2) the syntax 'data family List :: * -> *' is actually already supported as an alternative. -harendra On 13 November 2016 at 16:10, Harendra Kumar wrote: > I am curious about why the data families syntax was chosen to be the way > it is. For example a list can be defined as follows: > > data family List a > > data instance List Char = Empty | Cons Char (List Char) > > data instance List () = Count Int > > > Instead why not define it as: > > data List :: * -> * > > data List Char = Empty | Cons Char (List Char) > > data List () = Count Int > > > The latter form looks more intuitive and easy to remember to me since it > is very similar to the way value level functions are defined (signature & > pattern matching defs). Here we are just defining a type level function > instead. > > -harendra > -------------- next part -------------- An HTML attachment was scrubbed... URL: From alan.zimm at gmail.com Sun Nov 13 14:53:06 2016 From: alan.zimm at gmail.com (Alan & Kim Zimmerman) Date: Sun, 13 Nov 2016 16:53:06 +0200 Subject: GHC pretty printer philosophy In-Reply-To: <888D721E-4DE2-4474-8C6D-757272343138@cs.brynmawr.edu> References: <888D721E-4DE2-4474-8C6D-757272343138@cs.brynmawr.edu> Message-ID: Richard Thanks for the support. The major change in HsSyn since the pretty printer was first written is that the parser now preserves parens in the original source, which it did not used to, so this approach is now feasible. And I am starting to bump into tests failing which require updating the generic deriving code to add parens. Alan -------------- next part -------------- An HTML attachment was scrubbed... URL: From ben at smart-cactus.org Sun Nov 13 15:38:45 2016 From: ben at smart-cactus.org (Ben Gamari) Date: Sun, 13 Nov 2016 10:38:45 -0500 Subject: Windows build broken -- again In-Reply-To: References: Message-ID: <87bmxjs83e.fsf@ben-laptop.smart-cactus.org> Simon Peyton Jones via ghc-devs writes: > Sigh. The Simon PJ Windows Buildbot reports > Yes, my apologies for this one. I'm currently in the process of getting this one fixed in D2700. Unfortunately my own Windows machine is having hardware issues so I progress has been a bit slow. I hope to have a functional fix by the end of the day. Cheers, - Ben -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 454 bytes Desc: not available URL: From sylvain at haskus.fr Sun Nov 13 15:59:07 2016 From: sylvain at haskus.fr (Sylvain Henry) Date: Sun, 13 Nov 2016 16:59:07 +0100 Subject: OpenSearch with GHC manual Message-ID: Hi, Search engines often reference old versions of the GHC user guide. For instance with Google and the request "ghc unboxed tuples" I get the manual for 7.0.3, 5.04.1 and 6.8.2 as first results. With DuckDuckGo I get 6.12.3 and then "latest" versions of the manual. So I have made a custom search engine for the latest manual (using OpenSearch spec). You can install it from the following page: http://haskus.fr/ghc/index.html like any other search engine. Sphinx supports automatic generation of OpenSearch spec: http://www.sphinx-doc.org/en/1.4.8/config.html#confval-html_use_opensearch Maybe we should use this to make the search engine easier to find and use. As a side note, would it be possible to have a nicer URI for the latest doc? Currently it is: https://downloads.haskell.org/~ghc/latest/docs/html/users_guide/index.html Something like https://haskell.org/ghc/doc/index.html would be better IMO. Sylvain From ben at smart-cactus.org Sun Nov 13 17:09:07 2016 From: ben at smart-cactus.org (Ben Gamari) Date: Sun, 13 Nov 2016 12:09:07 -0500 Subject: build fail with latest 8.1 sources In-Reply-To: References: Message-ID: <8760nrs3ws.fsf@ben-laptop.smart-cactus.org> John Leo writes: > I just pulled again and picked up a more recent patch by Ben Gamari: > https://github.com/ghc/ghc/commit/ca1b986074757efff755c33c7f9a62c7eae43c7f > > This seems to have fixed the problem. The commit says 8 hours ago but for > some reason I didn't pick it up 2 or 3 hours ago when I last pulled. > Right, sorry John, that was my fault. I bumped the template-haskell version without bumping the bounds of the pacakges that depend upon it. Yet another reason why no change is too small for CI :) Cheers, - Ben > John > > On Sat, Nov 12, 2016 at 3:19 PM, John Leo wrote: > >> That's exactly what I did--in fact clone a fresh GHC and try again, but no >> luck. I attached the full logs in my second message, which have the >> details--let me know if the attachment is not readable. Thanks very much >> for your help. >> >> John >> >> On Sat, Nov 12, 2016 at 3:16 PM, Simon Peyton Jones > > wrote: >> >>> I’ve seen a very recent commit that mentioned bumping a TH bound. Maybe >>> pull, make clean and try again? >>> >>> >>> >>> Simon >>> >>> >>> >>> *From:* ghc-devs [mailto:ghc-devs-bounces at haskell.org] *On Behalf Of *John >>> Leo >>> *Sent:* 12 November 2016 22:48 >>> *To:* ghc-devs >>> *Subject:* build fail with latest 8.1 sources >>> >>> >>> >>> Hi everyone, >>> >>> >>> >>> I'm trying to build the latest 8.1 sources on a Mac running El Capitan. >>> I'm getting an error I'd never seen before and wonder if anyone has any >>> pointers of how I might fix things. I blew away my GHC, re-cloned from >>> github, reconfigured and I still get the same error. >>> >>> >>> >>> The following are the relevant output lines; the problem is that the >>> template-haskell version doesn't seem to match. I'm not sure whether this >>> is coming from the template-haskell in 8.1 or in 8.0.1 (which I'm using to >>> build 8.1), but checking the latter I have version 2.11.0.0 which I assume >>> should be sufficient. >>> >>> >>> >>> John >>> >>> >>> >>> -------------------- >>> >>> >>> >>> Configuring ghc-pkg-6.9... >>> >>> Configuring ghc-8.1... >>> >>> ghc-cabal: Encountered missing dependencies: >>> >>> template-haskell ==2.11.* && ==2.12.0.0 >>> >>> make[1]: *** [compiler/stage1/package-data.mk >>> ] >>> Error 1 >>> >>> make[1]: *** Waiting for unfinished jobs.... >>> >>> make: *** [all] Error 2 >>> >>> >>> >>> ---------------- >>> >>> >>> >>> internal-229:~/haskell/ghc> cabal update >>> >>> (git)-[master] >>> >>> Downloading the latest package list from hackage.haskell.org >>> >>> >>> Skipping download: local and remote files match. >>> >>> internal-229:~/haskell/ghc> cabal install template-haskell >>> >>> (git)-[master] >>> >>> Resolving dependencies... >>> >>> All the requested packages are already installed: >>> >>> template-haskell-2.11.0.0 >>> >>> Use --reinstall if you want to reinstall anyway. >>> >> >> > _______________________________________________ > ghc-devs mailing list > ghc-devs at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 454 bytes Desc: not available URL: From gale at sefer.org Mon Nov 14 09:58:58 2016 From: gale at sefer.org (Yitzchak Gale) Date: Mon, 14 Nov 2016 11:58:58 +0200 Subject: GHC 8.0.2 status In-Reply-To: <87insg5xza.fsf@ben-laptop.smart-cactus.org> References: <87twck8duc.fsf@ben-laptop.smart-cactus.org> <87insg5xza.fsf@ben-laptop.smart-cactus.org> Message-ID: Ben, I see #12757 is now fixed and closed. Great! What's the prognosis now for a release? Thanks, Yitz On Tue, Oct 25, 2016 at 5:01 PM, Ben Gamari wrote: > George Colpitts writes: > >> Hi >> >> Where are we on this? 12479 was last updated 5 days ago and it is not clear >> who has the next action. >> > Unfortunately The merge of #12479 took longer than expected and soon > thereafter yet another terrible bug has reared its ugly head. See > #12757. I'm trying to work out what to do about this today. > > Cheers, > > - Ben > > _______________________________________________ > ghc-devs mailing list > ghc-devs at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs > From ben at well-typed.com Mon Nov 14 13:26:10 2016 From: ben at well-typed.com (Ben Gamari) Date: Mon, 14 Nov 2016 08:26:10 -0500 Subject: GHC 8.0.2 status In-Reply-To: References: <87twck8duc.fsf@ben-laptop.smart-cactus.org> <87insg5xza.fsf@ben-laptop.smart-cactus.org> Message-ID: <87d1hyb3bh.fsf@ben-laptop.smart-cactus.org> Yitzchak Gale writes: > Ben, I see #12757 is now fixed and closed. Great! > > What's the prognosis now for a release? > I'm just waiting for a release of filepath and then one more round of tests and then I should have a source release ready. This release has been a bit of a perpetual trainwreck unfortunately; one blocking bug after another. Cheers, - Ben -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 454 bytes Desc: not available URL: From marlowsd at gmail.com Mon Nov 14 14:42:46 2016 From: marlowsd at gmail.com (Simon Marlow) Date: Mon, 14 Nov 2016 14:42:46 +0000 Subject: T12041 failing? In-Reply-To: References: Message-ID: Ok, so I think we should mark the test as expect_broken, because the Travis builds use -DDEBUG and this is causing them to fail currently (see e.g. https://travis-ci.org/simonmar/ghc/builds/174768018) Cheers Simon On 11 November 2016 at 17:39, Simon Peyton Jones wrote: > Hmm. Yes, this is an (actually harmless) assertion failure if your build > has -DDEBUG on. I think it’s just a fluke that it’s only just started > failing. > > > > I’ll make a ticket for it; I don’t think it’s super-urgent. > > > > Simon > > > > *From:* ghc-devs [mailto:ghc-devs-bounces at haskell.org] *On Behalf Of *Simon > Marlow > *Sent:* 09 November 2016 13:03 > *To:* ghc-devs at haskell.org > *Subject:* T12041 failing? > > > > I just saw the error below in a validate with -DDEBUG. Anyone know about this? > > --- /tmp/ghctest-uhJ8rt/test spaces/./indexed-types/should_fail/T12041.run/T12041.stderr.normalised 2016-11-09 12:13:38.206501840 +0000 > > +++ /tmp/ghctest-uhJ8rt/test spaces/./indexed-types/should_fail/T12041.run/T12041.comp.stderr.normalised 2016-11-09 12:13:38.206501840 +0000 > > @@ -1,7 +1,17 @@ > > +ghc: panic! (the 'impossible' happened) > > + (GHC version 8.1.20161109 for x86_64-unknown-linux): > > + ASSERT failed! > > + i_axb > > + Call stack: > > + CallStack (from HasCallStack): > > + prettyCurrentCallStack, called at compiler/utils/Outputable.hs:: in :Outputable > > + callStackDoc, called at compiler/utils/Outputable.hs:: in :Outputable > > + assertPprPanic, called at compiler/typecheck/TcType.hs:: in :TcType > > + Call stack: > > + CallStack (from HasCallStack): > > + prettyCurrentCallStack, called at compiler/utils/Outputable.hs:: in :Outputable > > + callStackDoc, called at compiler/utils/Outputable.hs:: in :Outputable > > + pprPanic, called at compiler/utils/Outputable.hs:: in :Outputable > > + assertPprPanic, called at compiler/typecheck/TcType.hs:: in :TcType > > -T12041.hs:12:15: > > - Expected kind ‘i -> Constraint’, > > - but ‘(~) Int’ has kind ‘* -> Constraint’ > > - In the type ‘(~) Int’ > > - In the type instance declaration for ‘Ob’ > > - In the instance declaration for ‘Category I’ > > +Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug > > *** unexpected failure for T12041(normal) > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From ggreif at gmail.com Mon Nov 14 15:57:04 2016 From: ggreif at gmail.com (Gabor Greif) Date: Mon, 14 Nov 2016 16:57:04 +0100 Subject: Non-working "-no-pie" test? Message-ID: Hi all, The test for checking "-no-pie" support of GCC doesn't seem to work. See below: $ gcc --version gcc (GCC) 4.4.7 20120313 (Red Hat 4.4.7-4) Copyright (C) 2010 Free Software Foundation, Inc. This is free software; see the source for copying conditions. There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. $ echo 'int main() { return 0; }' > conftest.c $ if gcc -o conftest -no-pie conftest.c > /dev/null 2>&1 ; then echo YEP ; else echo NOPE ; fi YEP $ if gcc -o conftest -no-pie conftest.c ; then echo YEP ; else echo NOPE ; fi gcc: unrecognized option '-no-pie' YEP $ if gcc -o conftest -no-pie conftest.c > /dev/null ; then echo YEP ; else echo NOPE ; fi gcc: unrecognized option '-no-pie' YEP Is the test supposed to check that there is nothing output into stdout? If so, it seems to fail. It leads to lots of failures when "make test", because gcc gets chatty. Cheers, Gabor PS: I have bash 4.1. From ben at smart-cactus.org Mon Nov 14 17:16:26 2016 From: ben at smart-cactus.org (Ben Gamari) Date: Mon, 14 Nov 2016 12:16:26 -0500 Subject: Non-working "-no-pie" test? In-Reply-To: References: Message-ID: <87bmxiyob9.fsf@ben-laptop.smart-cactus.org> Gabor Greif writes: > Hi all, > > The test for checking "-no-pie" support of GCC doesn't seem to work. See below: > > $ gcc --version > gcc (GCC) 4.4.7 20120313 (Red Hat 4.4.7-4) > Copyright (C) 2010 Free Software Foundation, Inc. > This is free software; see the source for copying conditions. There is NO > warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. > > $ echo 'int main() { return 0; }' > conftest.c > > $ if gcc -o conftest -no-pie conftest.c > /dev/null 2>&1 ; then echo > YEP ; else echo NOPE ; fi > YEP > $ if gcc -o conftest -no-pie conftest.c ; then echo YEP ; else echo NOPE ; fi > gcc: unrecognized option '-no-pie' > YEP > $ if gcc -o conftest -no-pie conftest.c > /dev/null ; then echo YEP ; > else echo NOPE ; fi > gcc: unrecognized option '-no-pie' > YEP > > > Is the test supposed to check that there is nothing output into stdout? > Oh dear; it seems that GCC prior to 4.8 doesn't exit with a non-zero exit code when faced with an unrecognized flag. Could you verify that https://phabricator.haskell.org/D2707 fixes this? Cheers, - Ben -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 454 bytes Desc: not available URL: From m at tweag.io Mon Nov 14 20:50:45 2016 From: m at tweag.io (Boespflug, Mathieu) Date: Mon, 14 Nov 2016 21:50:45 +0100 Subject: GHC 8.0.2 status In-Reply-To: <87d1hyb3bh.fsf@ben-laptop.smart-cactus.org> References: <87twck8duc.fsf@ben-laptop.smart-cactus.org> <87insg5xza.fsf@ben-laptop.smart-cactus.org> <87d1hyb3bh.fsf@ben-laptop.smart-cactus.org> Message-ID: Hi Ben, still a few tickets, most of them with patches, slated for the 8.0.2 milestone: https://ghc.haskell.org/trac/ghc/wiki/Status/GHC-8.0.2. Is the plan still to merge those in? https://ghc.haskell.org/trac/ghc/ticket/12777 is particularly important for inline-java. Many thanks, -- Mathieu Boespflug Founder at http://tweag.io. On 14 November 2016 at 14:26, Ben Gamari wrote: > Yitzchak Gale writes: > > > Ben, I see #12757 is now fixed and closed. Great! > > > > What's the prognosis now for a release? > > > I'm just waiting for a release of filepath and then one more round of > tests and then I should have a source release ready. This release has > been a bit of a perpetual trainwreck unfortunately; one blocking bug > after another. > > Cheers, > > - Ben > > > _______________________________________________ > ghc-devs mailing list > ghc-devs at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From matthewtpickering at gmail.com Mon Nov 14 21:00:53 2016 From: matthewtpickering at gmail.com (Matthew Pickering) Date: Mon, 14 Nov 2016 21:00:53 +0000 Subject: OSX build failing Message-ID: Hi all, The OSX build is broken due to 55d535da10dd63bbaf03fb176ced7179087cd0d4 Should I revert the patch or is there a fix coming? Matt ===== commit 55d535da10dd63bbaf03fb176ced7179087cd0d4 Author: Simon Marlow Date: Wed Nov 9 09:20:02 2016 +0000 Remove CONSTR_STATIC Summary: We currently have two info tables for a constructor * XXX_con_info: the info table for a heap-resident instance of the constructor, It has type CONSTR, or one of the specialised types like CONSTR_1_0 * XXX_static_info: the info table for a static instance of this constructor, which has type CONSTR_STATIC or CONSTR_STATIC_NOCAF. I'm getting rid of the latter, and using the `con_info` info table for both static and dynamic constructors. For rationale and more details see Note [static constructors] in SMRep.hs. I also removed these macros: `isSTATIC()`, `ip_STATIC()`, `closure_STATIC()`, since they relied on the CONSTR/CONSTR_STATIC distinction, and anyway HEAP_ALLOCED() does the same job. Test Plan: validate Reviewers: bgamari, simonpj, austin, gcampax, hvr, niteria, erikd Subscribers: thomie Differential Revision: https://phabricator.haskell.org/D2690 https://phabricator.haskell.org/rGHC From matthewtpickering at gmail.com Mon Nov 14 21:01:30 2016 From: matthewtpickering at gmail.com (Matthew Pickering) Date: Mon, 14 Nov 2016 21:01:30 +0000 Subject: OSX build failing In-Reply-To: References: Message-ID: I now see D2705, sorry for the noise. Matt On Mon, Nov 14, 2016 at 9:00 PM, Matthew Pickering wrote: > Hi all, > > The OSX build is broken due to 55d535da10dd63bbaf03fb176ced7179087cd0d4 > > Should I revert the patch or is there a fix coming? > > Matt > > ===== > > commit 55d535da10dd63bbaf03fb176ced7179087cd0d4 > Author: Simon Marlow > Date: Wed Nov 9 09:20:02 2016 +0000 > > Remove CONSTR_STATIC > > Summary: > We currently have two info tables for a constructor > > * XXX_con_info: the info table for a heap-resident instance of the > constructor, It has type CONSTR, or one of the specialised types like > CONSTR_1_0 > > * XXX_static_info: the info table for a static instance of this > constructor, which has type CONSTR_STATIC or CONSTR_STATIC_NOCAF. > > I'm getting rid of the latter, and using the `con_info` info table for > both static and dynamic constructors. For rationale and more details > see Note [static constructors] in SMRep.hs. > > I also removed these macros: `isSTATIC()`, `ip_STATIC()`, > `closure_STATIC()`, since they relied on the CONSTR/CONSTR_STATIC > distinction, and anyway HEAP_ALLOCED() does the same job. > > Test Plan: validate > > Reviewers: bgamari, simonpj, austin, gcampax, hvr, niteria, erikd > > Subscribers: thomie > > Differential Revision: https://phabricator.haskell.org/D2690 > > > > https://phabricator.haskell.org/rGHC From ben at well-typed.com Mon Nov 14 22:28:49 2016 From: ben at well-typed.com (Ben Gamari) Date: Mon, 14 Nov 2016 17:28:49 -0500 Subject: GHC 8.0.2 status In-Reply-To: References: <87twck8duc.fsf@ben-laptop.smart-cactus.org> <87insg5xza.fsf@ben-laptop.smart-cactus.org> <87d1hyb3bh.fsf@ben-laptop.smart-cactus.org> Message-ID: <87zil1y9um.fsf@ben-laptop.smart-cactus.org> "Boespflug, Mathieu" writes: > Hi Ben, > > still a few tickets, most of them with patches, slated for the 8.0.2 > milestone: https://ghc.haskell.org/trac/ghc/wiki/Status/GHC-8.0.2. Is the > plan still to merge those in? > There was one patch that was mistakenly in patch state which I cleared up. The 64-bit symbol table issue I have merged. The rest I was planning on punting on but if you say that #12777 I will merge it (although we first need to get it merged to master; Simon has been in paper-writing mode up until today (or rather, I think tomorrow), so you may want to try pinging him tomorrow to get a quick review. Cheers, - Ben -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 454 bytes Desc: not available URL: From m at tweag.io Mon Nov 14 22:35:21 2016 From: m at tweag.io (Boespflug, Mathieu) Date: Mon, 14 Nov 2016 23:35:21 +0100 Subject: GHC 8.0.2 status In-Reply-To: <87zil1y9um.fsf@ben-laptop.smart-cactus.org> References: <87twck8duc.fsf@ben-laptop.smart-cactus.org> <87insg5xza.fsf@ben-laptop.smart-cactus.org> <87d1hyb3bh.fsf@ben-laptop.smart-cactus.org> <87zil1y9um.fsf@ben-laptop.smart-cactus.org> Message-ID: Ok many thanks for the heads up Ben. I'll let Facundo coordinate from here, regarding #12777. -- Mathieu Boespflug Founder at http://tweag.io. On 14 November 2016 at 23:28, Ben Gamari wrote: > "Boespflug, Mathieu" writes: > > > Hi Ben, > > > > still a few tickets, most of them with patches, slated for the 8.0.2 > > milestone: https://ghc.haskell.org/trac/ghc/wiki/Status/GHC-8.0.2. Is > the > > plan still to merge those in? > > > There was one patch that was mistakenly in patch state which I cleared > up. The 64-bit symbol table issue I have merged. The rest I was planning > on punting on but if you say that #12777 I will merge it (although we > first need to get it merged to master; Simon has been in paper-writing > mode up until today (or rather, I think tomorrow), so you may want to > try pinging him tomorrow to get a quick review. > > Cheers, > > - Ben > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From bernard.delapaz at yandex.ru Tue Nov 15 15:41:22 2016 From: bernard.delapaz at yandex.ru (Bernard de la Paz) Date: Tue, 15 Nov 2016 18:41:22 +0300 Subject: Linux -> Windows cross-compiling failed Message-ID: <224521479224482@web9o.yandex.ru> An HTML attachment was scrubbed... URL: From ben at well-typed.com Tue Nov 15 16:05:32 2016 From: ben at well-typed.com (Ben Gamari) Date: Tue, 15 Nov 2016 11:05:32 -0500 Subject: Linux -> Windows cross-compiling failed In-Reply-To: <224521479224482@web9o.yandex.ru> References: <224521479224482@web9o.yandex.ru> Message-ID: <87twb8ybhv.fsf@ben-laptop.smart-cactus.org> Bernard de la Paz writes: > I try to cross-compile GHC 8.0.1 with x86_64-mingw toolchain (gcc 6.2.1) and native GHC 8.0.1. Sources are from http://downloads.haskell.org/~ghc/8.0.1/ghc-8.0.1-src.tar.xz > > cp mk/build.mk.example mk/build.mk > > sed -i '1iBuildFlavour = perf' mk/build.mk > sed -i '1iStage1Only = YES' mk/build.mk > sed -i '1iHADDOCK_DOCS = NO' mk/build.mk > ./configure --prefix=~/x86_64-mingw \ > --target=x86_64-unknown-mingw32 \ > --with-gcc=/usr/bin/x86_64-w64-mingw32-gcc \ > --with-ld=/usr/bin/x86_64-w64-mingw32-ld \ > --with-nm=/usr/bin/x86_64-w64-mingw32-nm \ > --with-ar=/usr/bin/x86_64-w64-mingw32-ar \ > --with-ranlib=/usr/bin/x86_64-w64-mingw32-ranlib > make -j8 install > > First encountered error is in Types.hsc: > > Types.hsc: In function ‘_hsc2hs_test44’: > Types.hsc:219:20: error: storage size of ‘test_array’ isn’t constant > In general it is helpful if you include a bit more context on where in the build these errors ocurred. Is this during the stage1 build or stage2? Just a few lines of the surrounding build output would be helpful. > There are testing scripts in utils/hsc2hs/CrossCodegen.hs that create such code: > > void _hsc2hs_test44() { > static int test_array[value]; > ... > > where 'value' is const int, that is forbidden by C standard. GCC older then 4.4 reject this code, but Clang doesn't (does with -pedantic-errors). But with-gcc=/usr/bin/x86_64-w64-mingw32-clang fails sooner, so it cannot help. > So I compiled Types.hsc (and three others) with clang and go further. Hmm, presumably it fails since the array in question is static? On looking into this I realized that apparently VLAs have been made optional in C11, so perhaps we should be more conservative in using them, especially in hsc2hs. > Second error: > > rts/posix/GetTime.c:25:2: error: #error No implementation for getProcessCPUTime() available. > #error No implementation for getProcessCPUTime() available. > > In file there are such strings: > > #if ! ((defined(HAVE_GETRUSAGE) && !irix_HOST_OS) || defined(HAVE_TIMES)) > #error No implementation for getProcessCPUTime() available. > #endif > > Linux definitely hasn't such function, it's a part of Windows API. getProcessCPUTime is a function provided by GHC's runtime system. I believe the issue here is that the build system (rts/ghc.mk) chooses which implementation to use based upon the host operating system. This seems wrong. Then again, if this is wrong I don't see how cross-compilation ever actually worked. Surely I'm missing something here. Cheers, - Ben -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 454 bytes Desc: not available URL: From mle+hs at mega-nerd.com Tue Nov 15 19:50:51 2016 From: mle+hs at mega-nerd.com (Erik de Castro Lopo) Date: Wed, 16 Nov 2016 06:50:51 +1100 Subject: Linux -> Windows cross-compiling failed In-Reply-To: <224521479224482@web9o.yandex.ru> References: <224521479224482@web9o.yandex.ru> Message-ID: <20161116065051.6609f1ffa7abf44459a1d8a2@mega-nerd.com> Bernard de la Paz wrote: > I try to cross-compile GHC 8.0.1 with x86_64-mingw toolchain (gcc 6.2.1) and native GHC 8.0.1. Sources are from http://downloads.haskell.org/~ghc/8.0.1/ghc-8.0.1-src.tar.xz > cp mk/build.mk.example mk/build.mk > sed -i '1iBuildFlavour = perf' mk/build.mk I'm pretty sure you will have better results with build flavour 'quick-cross' or 'perf-cross'. > sed -i '1iStage1Only = YES' mk/build.mk > sed -i '1iHADDOCK_DOCS = NO' mk/build.mk > ./configure --prefix=~/x86_64-mingw \ > --target=x86_64-unknown-mingw32 \ >      --with-gcc=/usr/bin/x86_64-w64-mingw32-gcc \ >     --with-ld=/usr/bin/x86_64-w64-mingw32-ld \ >     --with-nm=/usr/bin/x86_64-w64-mingw32-nm \ >     --with-ar=/usr/bin/x86_64-w64-mingw32-ar \ >     --with-ranlib=/usr/bin/x86_64-w64-mingw32-ranlib It should be sufficient to just do: ./configure --target=x86_64-w64-mingw32 Erik -- ---------------------------------------------------------------------- Erik de Castro Lopo http://www.mega-nerd.com/ From adam at well-typed.com Wed Nov 16 08:29:27 2016 From: adam at well-typed.com (Adam Gundry) Date: Wed, 16 Nov 2016 08:29:27 +0000 Subject: OverloadedRecordFields request for review Message-ID: <286a007e-3f8b-a660-27c7-8c659350b5bf@well-typed.com> Hi devs, I just wanted to draw your attention to the OverloadedRecordFields proposal [1], which I've just updated and now has a corresponding implementation ready for review on Phab [2]. I'd very much appreciate any feedback on either the design or implementation. Thanks, Adam [1] https://github.com/ghc-proposals/ghc-proposals/pull/6 [2] https://phabricator.haskell.org/D2708 -- Adam Gundry, Haskell Consultant Well-Typed LLP, http://www.well-typed.com/ From bernard.delapaz at yandex.ru Wed Nov 16 11:40:22 2016 From: bernard.delapaz at yandex.ru (Bernard de la Paz) Date: Wed, 16 Nov 2016 14:40:22 +0300 Subject: Linux -> Windows cross-compiling failed In-Reply-To: <87twb8ybhv.fsf@ben-laptop.smart-cactus.org> References: <224521479224482@web9o.yandex.ru> <87twb8ybhv.fsf@ben-laptop.smart-cactus.org> Message-ID: <2787531479296422@web27j.yandex.ru> An HTML attachment was scrubbed... URL: From ifigueroap at gmail.com Thu Nov 17 20:08:24 2016 From: ifigueroap at gmail.com (Ismael Figueroa) Date: Thu, 17 Nov 2016 17:08:24 -0300 Subject: GHC archeology and git commit hashes Message-ID: Dear ghc devs, I'm doing some archeology of the GHC codebase, and I need to map every release to a given git tag/commit/hash. So far, based on the official webpage and Github mirror, I have done it for releases from 7.2.1 until 8.0.1. However, it is not clear to me: - whether there is a corresponding point in history for releases before 7.2.1 - what are the corresponding commits, if any >From what I can get at a glance, at this point in time the source code was managed in a DARCS repository, right? Would you please be so kind to point me in the right direction, in order to correctly perform this mapping? Thanks in advance! -- Ismael -------------- next part -------------- An HTML attachment was scrubbed... URL: From simonpj at microsoft.com Thu Nov 17 21:40:53 2016 From: simonpj at microsoft.com (Simon Peyton Jones) Date: Thu, 17 Nov 2016 21:40:53 +0000 Subject: windows build In-Reply-To: <87y40iw2np.fsf@ben-laptop.smart-cactus.org> References: <8737iqyeoc.fsf@ben-laptop.smart-cactus.org> <87y40iw2np.fsf@ben-laptop.smart-cactus.org> Message-ID: Whizzo! Window builds are up again. Thank you! Here are the errors I get, which seem more manageable. Simon Unexpected passes: rts/T7037.run T7037 [unexpected] (normal) Unexpected failures: ghci/prog003/prog003.run prog003 [bad exit code] (ghci) plugins/plugins07.run plugins07 [bad exit code] (normal) Unexpected stat failures: perf/haddock/haddock.compiler.run haddock.compiler [stat not good enough] (normal) perf/should_run/T876.run T876 [stat too good] (normal) Framework failures: plugins/plugins07.run plugins07 [normal] (pre_cmd failed: 2) | -----Original Message----- | From: Ben Gamari [mailto:ben at well-typed.com] | Sent: 17 November 2016 15:24 | To: Simon Peyton Jones | Subject: RE: windows build | | Simon Peyton Jones writes: | | > OK thank you. | > | > Meanwhile, what about the RTS error? | | A fix has been merged for the RTS issue | (b76958671cda1df9f6f0e1d54d681144d09cb06e). Tamar is still looking at the | testsuite driver issue (#12554) and has a suspicion that the issue is | file handle inheritance. He's going to try to put together a fix tonight. | | Cheers, | | - Ben From ben at well-typed.com Fri Nov 18 00:15:30 2016 From: ben at well-typed.com (Ben Gamari) Date: Thu, 17 Nov 2016 19:15:30 -0500 Subject: GHC archeology and git commit hashes In-Reply-To: References: Message-ID: <87poltwsm5.fsf@ben-laptop.smart-cactus.org> Ismael Figueroa writes: > Dear ghc devs, > > I'm doing some archeology of the GHC codebase, and I need to map every > release to a given git tag/commit/hash. So far, based on the official > webpage and Github mirror, I have done it for releases from 7.2.1 until > 8.0.1. However, it is not clear to me: > > - whether there is a corresponding point in history for releases before > 7.2.1 > - what are the corresponding commits, if any > > From what I can get at a glance, at this point in time the source code was > managed in a DARCS repository, right? > > Would you please be so kind to point me in the right direction, in order to > correctly perform this mapping? > I'm afraid this is well before my time. However, I'm CCing Ian who may have something to offer here. However, I'm afraid it's possible that this information is lost to time, especially if you need the corresponding core library commits as well. Regardless, good luck! Cheers, - Ben -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 454 bytes Desc: not available URL: From ben at well-typed.com Fri Nov 18 04:42:36 2016 From: ben at well-typed.com (Ben Gamari) Date: Thu, 17 Nov 2016 23:42:36 -0500 Subject: GHC 8.0.2 status In-Reply-To: <87twck8duc.fsf@ben-laptop.smart-cactus.org> References: <87twck8duc.fsf@ben-laptop.smart-cactus.org> Message-ID: <87oa1dwg8z.fsf@ben-laptop.smart-cactus.org> Ben Gamari writes: > Hello GHCers, > > Thanks to the work of darchon the last blocker for the 8.0.2 release > (#12479) has nearly been resolved. After the fix has been merged I'll be > doing some further testing of the ghc-8.0 branch and cut a source > tarball for 8.0.2-rc1 later this week. > > If you intend on offering a binary release for 8.0.2 it would be great > if you could plan on testing the tarball promptly so we can cut 8.0.2 > and move on to planning for 8.2.1. > > Thanks for your help and patience! > Hello everyone! Well, here we are, another month and another handful of bugs later but at long last I have good news to report: I just finished a set of builds on our tier 1 platforms and it seems that things are finally in reasonably good shape. I put the finishing touches on the tree today and will try to cut a source tarball for 8.0.2-rc1 tomorrow. Here's to hoping that things go more smoothly from here on out. As usual, I'd like to plan on a seven-day window between the source release and final release announcement. However, let me know if this will be too onerous and we can discuss other options. Cheers, - Ben -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 454 bytes Desc: not available URL: From mle+hs at mega-nerd.com Fri Nov 18 08:18:12 2016 From: mle+hs at mega-nerd.com (Erik de Castro Lopo) Date: Fri, 18 Nov 2016 19:18:12 +1100 Subject: Heads up: Git HEAD now requres LLVM 3.9 Message-ID: <20161118191812.59e348a9e2b2f143186ec5f4@mega-nerd.com> Hi all, With the landing of https://phabricator.haskell.org/D2719 GHC git HEAD now requires LLVM 3.9. Erik -- ---------------------------------------------------------------------- Erik de Castro Lopo http://www.mega-nerd.com/ From shea at shealevy.com Mon Nov 21 12:50:44 2016 From: shea at shealevy.com (Shea Levy) Date: Mon, 21 Nov 2016 07:50:44 -0500 Subject: Making (useful subsets of) bytecode portable between targets Message-ID: <87h971t2sb.fsf@shlevy-laptop.i-did-not-set--mail-host-address--so-tickle-me> Hi all, I'm interested in implementing a general solution for TH during cross-compilation, which if my naive lack-of-understanding is correct will broadly involve the following three tasks: 1. Make the generation of byte code, or at least the subset needed for useful TH use, target-independent 2. Teach the external-interpreter to launch a build-native iserv when cross-compiling 3. Teach cabal to compile dependencies and modules for the build and target when cross-compiling and TH is used Of course, due to the generality of TH there will be code you can write that would be different in this approach from what you would get with a fully native compilation (e.g. due to GHC conditional compilation in the TH functions or FFI that does runtime host introspection), but since requiring a target device at build time is in many cases impractical (do you want to hook up an iPhone to your build farm?) and in some cases probably impossible (for targets without the resources to run a full GHC even if they can run GHC-compiled code) I think this is a reasonable restriction to require. My questions to the list are: * Is 1 above a pipe dream, keeping in mind that we are assuming the availability of build-native versions of all dependencies and already-compiled modules? * Any pointers for getting started with 1? * Anything I'm missing? Thanks, Shea -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 800 bytes Desc: not available URL: From alan.zimm at gmail.com Mon Nov 21 19:49:40 2016 From: alan.zimm at gmail.com (Alan & Kim Zimmerman) Date: Mon, 21 Nov 2016 21:49:40 +0200 Subject: Paren removal in renamer Message-ID: Hi all I have been wrestling with something silly most of today. T12530 has the following splice in it, which has parens around the "(Maybe Int)". $([d| -- Test the Template Haskell pretty-printing for TypeApplications f = id @(Maybe Int) |]) the parsed source has these parens, but they are removed for the renamed source. I am modifying the pretty printer to be faithful to the original source, so when the renamed source is printed it has no parens, causing T12530 to fail. I have looked all over the source, and cannot see where the HsParTy is removed. Can anyone give me a pointer? See details here [1] My current work branch is here [2], but I am pretty sure there are no changes affecting this there. [1] http://lpaste.net/1624164315596587008 [2] https://github.com/alanz/ghc/tree/wip/T3384 Regards Alan -------------- next part -------------- An HTML attachment was scrubbed... URL: From ben at smart-cactus.org Mon Nov 21 21:06:14 2016 From: ben at smart-cactus.org (Ben Gamari) Date: Mon, 21 Nov 2016 16:06:14 -0500 Subject: Making (useful subsets of) bytecode portable between targets In-Reply-To: <87h971t2sb.fsf@shlevy-laptop.i-did-not-set--mail-host-address--so-tickle-me> References: <87h971t2sb.fsf@shlevy-laptop.i-did-not-set--mail-host-address--so-tickle-me> Message-ID: <87r364v8zd.fsf@ben-laptop.smart-cactus.org> CCing Luite who has done this sort of thing in the context of GHCJS. Shea Levy writes: > Hi all, > > I'm interested in implementing a general solution for TH during > cross-compilation, which if my naive lack-of-understanding is correct > will broadly involve the following three tasks: > > 1. Make the generation of byte code, or at least the subset needed for > useful TH use, target-independent The bytecode machine itself (defined by ByteCodeInstr) is reasonably target-independent. However, I suspect primops will be problematic since they can appear in BCOs and are quite target dependent (namely due to word size). I honestly don't know how much of a problem this will be in practice; I tried loading a few example programs into ghci -ddump-bcos and didn't see any PUSH_PRIMOP instructions, so perhaps this won't be as problematic as I expect; it is worrisome though. In general it's hard to identify "the subset needed for useful TH use" but the fact that I can load the gitrev package (a fairly non-trivial use of TH) into GHCi with no apparently platform dependent BCOs being produced is promising. > 2. Teach the external-interpreter to launch a build-native iserv when > cross-compiling For this you'll want to have a careful look through the Binary instances for the things that are sent over the wire to iserv. You'll find these occur in libraries/ghci/*.hs. The first thing to look for is places where the system word-size may leak into the serialized representation (e.g. instances where Ints and Words are being used). Many of these can probably just be narrowed into 32-bit representations (e.g. in ResolvedBCO, where I think it's fair to assume that four-billion bytecode instructions is an unreasonable BCO size). Don't forget to consider the platform dependence of the "primitive" encodings like the Binary instance for ByteString [1]; you'll need to take care to replace these with platform-independent encodings. [1] https://hackage.haskell.org/package/binary-0.8.4.1/docs/src/Data.Binary.Class.html#line-611 > 3. Teach cabal to compile dependencies and modules for the build and > target when cross-compiling and TH is used You'll need to speak with the Cabal folks about this. However, it's probably safe to ignore this for now; there's a lot of work to done before you'll be in a position to start thinking about this. > Of course, due to the generality of TH there will be code you can write > that would be different in this approach from what you would get with a > fully native compilation (e.g. due to GHC conditional compilation in the > TH functions or FFI that does runtime host introspection), but since > requiring a target device at build time is in many cases impractical (do > you want to hook up an iPhone to your build farm?) and in some cases > probably impossible (for targets without the resources to run a full GHC > even if they can run GHC-compiled code) I think this is a reasonable > restriction to require. > > My questions to the list are: > > * Is 1 above a pipe dream, keeping in mind that we are assuming the > availability of build-native versions of all dependencies and > already-compiled modules? This sounds quite feasible to me. > * Any pointers for getting started with 1? See above. The first thing to do is to rid the Binary instances of platform dependent encodings. This will be a bit of a game of whack-a-mole, but it shouldn't be that hard. Don't hesitate to ask if you get stuck! Cheers, - Ben -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 454 bytes Desc: not available URL: From ben at smart-cactus.org Tue Nov 22 06:18:55 2016 From: ben at smart-cactus.org (Ben Gamari) Date: Tue, 22 Nov 2016 01:18:55 -0500 Subject: DWARF patches for 8.2 Message-ID: <87k2bwuje8.fsf@ben-laptop.smart-cactus.org> Hello fellow DWARF enthusiasts, Tonight I finally made something of a breakthrough on the DWARF front; after finding a small logic error in one of my patches I was able to get a full stack trace into and out of Haskell using the runtime system's native stack unwinder. This is quite exciting! Recall that up until now there have been a few issues which can lead to problems with unwinding, * #11353: Unsafe foreign calls can require the NCG to make stack pointer adjustments to accomodate native calling conventions. These adjustments need to be taken into account when we generate unwinding information. * #11337: Stack fixups produced by CmmStackLayout aren't reflected in unwinding information. Essentially this was a result of the fact that our current unwinding implementation assumes that stack layout is fixed over the course of a block. * #11338: The region surrounding safe foreign calls doesn't get proper unwinding information. I've solved all three of these in my branch, which I've rebased, split up, and posted to Phabricator. The result is quite a stack of differentials, * D2740: OrdList: Add Foldable, Traversable instances Some throat-clearing. * D2735: Use newBlockId instead of newLabelC Just some refactoring. * D2737: NCGMonad: Add MonadUnique NatM instance This will come in handy later. * D2736: AsmCodeGen: Refactor worker in cmmNativeGens More refactoring I did while trying to understand the dataflow in the NCG. * D2739: CmmCommonBlockElim: Ignore CmmUnwind nodes This is a fix to what I believe is a bug which I noticed while reading through the implementation. * D2741: Generalize CmmUnwind and pass unwind information through NCG This is the bulk of the change. Here we refactor the treatment of unwinding information to provide the flexibility we will need to address the issues described above and fix #11353. Review is badly needed here. * D2742: CmmLayoutStack: Add unwind information on stack fixups Here we use the infrastructure provided in D2741 to fix #11337. * D2743: StgCmmForeign: Emit debug information for safe foreign calls Here we fix #11338 by adding unwind information to the safe foreign call prologue/epilogue code. * D2738: Cmm: Add support for undefined unwinding statements Fix unwinding information for stg_stack_underflow_frames, which we have no means of unwinding out of. For this we need to add support for unwinding declarations which tell the underwinder to "forget" about the value of a register. Reviews would be greatly appreciated. Cheers, - Ben -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 454 bytes Desc: not available URL: From matthewtpickering at gmail.com Tue Nov 22 10:42:53 2016 From: matthewtpickering at gmail.com (Matthew Pickering) Date: Tue, 22 Nov 2016 10:42:53 +0000 Subject: Exhaustiveness checking for pattern synonyms Message-ID: Hello devs, I have implemented exhaustiveness checking for pattern synonyms. The idea is very simple, you specify a set of pattern synonyms (or data constructors) which are regarded as a complete match. The pattern match checker then uses this information in order to check whether a function covers all possibilities. Specification: https://ghc.haskell.org/trac/ghc/wiki/PatternSynonyms/CompleteSigs https://phabricator.haskell.org/D2669 https://phabricator.haskell.org/D2725 Matt From jan.bracker at googlemail.com Wed Nov 23 09:34:29 2016 From: jan.bracker at googlemail.com (Jan Bracker) Date: Wed, 23 Nov 2016 09:34:29 +0000 Subject: Restrictions of proc-notation with RebindableSyntax Message-ID: Hello, I want to use the proc-notation together with RebindableSyntax. So far what I am trying to do is working fine, but I would like to know what the exact restrictions on the supplied functions are. I am introducing additional indices and constraints on the operations. The documentation [1] says the details are in flux and that I should ask directly. Best, Jan [1] https://downloads.haskell.org/~ghc/latest/docs/html/users_guide/glasgow_exts.html#rebindable-syntax-and-the-implicit-prelude-import -------------- next part -------------- An HTML attachment was scrubbed... URL: From marlowsd at gmail.com Wed Nov 23 11:50:15 2016 From: marlowsd at gmail.com (Simon Marlow) Date: Wed, 23 Nov 2016 11:50:15 +0000 Subject: Making (useful subsets of) bytecode portable between targets In-Reply-To: <87h971t2sb.fsf@shlevy-laptop.i-did-not-set--mail-host-address--so-tickle-me> References: <87h971t2sb.fsf@shlevy-laptop.i-did-not-set--mail-host-address--so-tickle-me> Message-ID: On 21 November 2016 at 12:50, Shea Levy wrote: > Hi all, > > I'm interested in implementing a general solution for TH during > cross-compilation, which if my naive lack-of-understanding is correct > will broadly involve the following three tasks: > > 1. Make the generation of byte code, or at least the subset needed for > useful TH use, target-independent > 2. Teach the external-interpreter to launch a build-native iserv when > cross-compiling > 3. Teach cabal to compile dependencies and modules for the build and > target when cross-compiling and TH is used > The external interpreter was aimed at being able to run target code at compile time. I think what you have in mind is running *host* code at compile-time instead. There are a number of tricky things here. - You have to build everything for the host as well as the target. All the libraries that GHC builds will need to be built in two flavours, and the external build tools Cabal/Stack (as you mentioned) need to know about this. - GHC itself will need to be able to generate code for multiple platforms. We've done some work in this direction, but I don't think it's complete. Maybe it's not all that far off, but there are still some platform #ifdefs in the code. - As you point out, the code we compile for the host platform will not necessarily be the same as the target code, due to #ifdefs and other platform differences. - There is a point where the two platforms meet, when we're compiling a module for the target platform that uses TH. Every assumption that we made about the target platform (from reading .hi files) must also be true of the host platform, because we're about to run that code. So the .hi files for the host and target must be exactly the same. One way this could easily go wrong is if you use some API that's only available on the target platform in some TH code. GHC won't know that anything is wrong, but we'll get a link error (or worse, a crash) when trying to run the TH code. What this comes down to is that GHC doesn't have a clean separation between compile-time execution and runtime execution, it assumes that they're the same. For a (slightly opinionated) perspective on this, see http://blog.ezyang.com/2016/07/what-template-haskell-gets-wrong-and-racket-gets-right/ . So what I'm saying is: you could probably make this work, for some slightly flaky and brittle value of "work". Doing it properly is also pretty hard in the context of GHC, though, because it's a fairly fundamental upheaval. My question would be: are you *sure* you can't run target code at compile time? Not even with an iphone simulator? Cheers Simon Of course, due to the generality of TH there will be code you can write > that would be different in this approach from what you would get with a > fully native compilation (e.g. due to GHC conditional compilation in the > TH functions or FFI that does runtime host introspection), but since > requiring a target device at build time is in many cases impractical (do > you want to hook up an iPhone to your build farm?) and in some cases > probably impossible (for targets without the resources to run a full GHC > even if they can run GHC-compiled code) I think this is a reasonable > restriction to require. > > My questions to the list are: > > * Is 1 above a pipe dream, keeping in mind that we are assuming the > availability of build-native versions of all dependencies and > already-compiled modules? > * Any pointers for getting started with 1? > * Anything I'm missing? > > Thanks, > Shea > -------------- next part -------------- An HTML attachment was scrubbed... URL: From trupill at gmail.com Wed Nov 23 13:57:52 2016 From: trupill at gmail.com (Alejandro Serrano Mena) Date: Wed, 23 Nov 2016 14:57:52 +0100 Subject: Reading source annotations during type checking Message-ID: Dear GHC devs, Is there a way to retrieve "source annotations" (as defined by https://downloads.haskell.org/~ghc/latest/docs/html/users_guide/extending_ghc.html#source-annotations) during type checking. In particular, I am interested in reading them in TcExpr and TcCanonical. Regards, Alejandro -------------- next part -------------- An HTML attachment was scrubbed... URL: From marlowsd at gmail.com Wed Nov 23 14:17:46 2016 From: marlowsd at gmail.com (Simon Marlow) Date: Wed, 23 Nov 2016 14:17:46 +0000 Subject: DWARF patches for 8.2 In-Reply-To: <87k2bwuje8.fsf@ben-laptop.smart-cactus.org> References: <87k2bwuje8.fsf@ben-laptop.smart-cactus.org> Message-ID: Awesome stuff Ben. I'll try to find some time to review these. On 22 November 2016 at 06:18, Ben Gamari wrote: > Hello fellow DWARF enthusiasts, > > Tonight I finally made something of a breakthrough on the DWARF front; > after finding a small logic error in one of my patches I was able to get > a full stack trace into and out of Haskell using the runtime system's > native stack unwinder. This is quite exciting! > > Recall that up until now there have been a few issues which can lead to > problems with unwinding, > > * #11353: Unsafe foreign calls can require the NCG to make stack > pointer adjustments to accomodate native calling conventions. These > adjustments need to be taken into account when we generate unwinding > information. > > * #11337: Stack fixups produced by CmmStackLayout aren't reflected in > unwinding information. Essentially this was a result of the fact that > our current unwinding implementation assumes that stack layout is > fixed over the course of a block. > > * #11338: The region surrounding safe foreign calls doesn't get proper > unwinding information. > > I've solved all three of these in my branch, which I've rebased, split > up, and posted to Phabricator. The result is quite a stack of > differentials, > > * D2740: OrdList: Add Foldable, Traversable instances > > Some throat-clearing. > > * D2735: Use newBlockId instead of newLabelC > > Just some refactoring. > > * D2737: NCGMonad: Add MonadUnique NatM instance > > This will come in handy later. > > * D2736: AsmCodeGen: Refactor worker in cmmNativeGens > > More refactoring I did while trying to understand the dataflow in the > NCG. > > * D2739: CmmCommonBlockElim: Ignore CmmUnwind nodes > > This is a fix to what I believe is a bug which I noticed while > reading through the implementation. > > * D2741: Generalize CmmUnwind and pass unwind information through NCG > > This is the bulk of the change. Here we refactor the treatment of > unwinding information to provide the flexibility we will need to > address the issues described above and fix #11353. Review is badly > needed here. > > * D2742: CmmLayoutStack: Add unwind information on stack fixups > > Here we use the infrastructure provided in D2741 to fix #11337. > > * D2743: StgCmmForeign: Emit debug information for safe foreign calls > > Here we fix #11338 by adding unwind information to the safe foreign > call prologue/epilogue code. > > * D2738: Cmm: Add support for undefined unwinding statements > > Fix unwinding information for stg_stack_underflow_frames, which we > have no means of unwinding out of. For this we need to add support > for unwinding declarations which tell the underwinder to "forget" > about the value of a register. > > Reviews would be greatly appreciated. > > Cheers, > > - Ben > -------------- next part -------------- An HTML attachment was scrubbed... URL: From moritz at lichtzwerge.de Thu Nov 24 02:05:33 2016 From: moritz at lichtzwerge.de (Moritz Angermann) Date: Thu, 24 Nov 2016 10:05:33 +0800 Subject: Making (useful subsets of) bytecode portable between targets In-Reply-To: References: <87h971t2sb.fsf@shlevy-laptop.i-did-not-set--mail-host-address--so-tickle-me> Message-ID: > On Nov 23, 2016, at 7:50 PM, Simon Marlow wrote: > > […] > > My question would be: are you *sure* you can't run target code at compile time? Not even with an iphone simulator? This should be possible. However for proper development one would need to run on the device (iPhone, iPad, …) for armv7 or arm64, as the Simulator is i386 or x86_64. There is a bit of additional engineering required here to get the shipping of code from ghc to the runner on the target required (e.g. via network). As executing and controlling applications on the actual hardware is limited, I guess a custom ghc-runner application would have to be manually started on the device, which could trivially be discovered using bonjour/zeroconf (or just giving ghc the host:port information). In general though, the runner does not have to obey all the restrictions apple puts onto app-store distributed apps, as I expect that everyone could build and install the runner themselves when intending to do iOS development with ghc. cheers, moritz From chak at justtesting.org Thu Nov 24 04:42:23 2016 From: chak at justtesting.org (Manuel M T Chakravarty) Date: Thu, 24 Nov 2016 15:42:23 +1100 Subject: Making (useful subsets of) bytecode portable between targets In-Reply-To: References: <87h971t2sb.fsf@shlevy-laptop.i-did-not-set--mail-host-address--so-tickle-me> Message-ID: Sorry, but I don’t think running on the device is practical. How do you want to do CI, for example? Manuel > Moritz Angermann : > > >> On Nov 23, 2016, at 7:50 PM, Simon Marlow wrote: >> >> […] >> >> My question would be: are you *sure* you can't run target code at compile time? Not even with an iphone simulator? > > This should be possible. However for proper development one would need to run on the > device (iPhone, iPad, …) for armv7 or arm64, as the Simulator is i386 or x86_64. > > There is a bit of additional engineering required here to get the shipping of > code from ghc to the runner on the target required (e.g. via network). As executing > and controlling applications on the actual hardware is limited, I guess a custom > ghc-runner application would have to be manually started on the device, which could > trivially be discovered using bonjour/zeroconf (or just giving ghc the host:port information). > > In general though, the runner does not have to obey all the restrictions apple puts > onto app-store distributed apps, as I expect that everyone could build and install > the runner themselves when intending to do iOS development with ghc. > > cheers, > moritz > _______________________________________________ > ghc-devs mailing list > ghc-devs at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs From moritz at lichtzwerge.de Thu Nov 24 04:51:13 2016 From: moritz at lichtzwerge.de (Moritz Angermann) Date: Thu, 24 Nov 2016 12:51:13 +0800 Subject: Making (useful subsets of) bytecode portable between targets In-Reply-To: References: <87h971t2sb.fsf@shlevy-laptop.i-did-not-set--mail-host-address--so-tickle-me> Message-ID: It's certainly far from ideal, but for CI, what obstacles are there besides needing a runner accessible from cross compiling machine? E.g. Start the runner app on an iPhone plugged in into a USB power source and leave it there? Sent from my iPhone > On 24 Nov 2016, at 12:42 PM, Manuel M T Chakravarty wrote: > > Sorry, but I don’t think running on the device is practical. How do you want to do CI, for example? > > Manuel > >> Moritz Angermann : >> >> >>> On Nov 23, 2016, at 7:50 PM, Simon Marlow wrote: >>> >>> […] >>> >>> My question would be: are you *sure* you can't run target code at compile time? Not even with an iphone simulator? >> >> This should be possible. However for proper development one would need to run on the >> device (iPhone, iPad, …) for armv7 or arm64, as the Simulator is i386 or x86_64. >> >> There is a bit of additional engineering required here to get the shipping of >> code from ghc to the runner on the target required (e.g. via network). As executing >> and controlling applications on the actual hardware is limited, I guess a custom >> ghc-runner application would have to be manually started on the device, which could >> trivially be discovered using bonjour/zeroconf (or just giving ghc the host:port information). >> >> In general though, the runner does not have to obey all the restrictions apple puts >> onto app-store distributed apps, as I expect that everyone could build and install >> the runner themselves when intending to do iOS development with ghc. >> >> cheers, >> moritz >> _______________________________________________ >> ghc-devs mailing list >> ghc-devs at haskell.org >> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs > From moritz at lichtzwerge.de Thu Nov 24 04:55:53 2016 From: moritz at lichtzwerge.de (Moritz Angermann) Date: Thu, 24 Nov 2016 12:55:53 +0800 Subject: Making (useful subsets of) bytecode portable between targets In-Reply-To: References: <87h971t2sb.fsf@shlevy-laptop.i-did-not-set--mail-host-address--so-tickle-me> Message-ID: Hi, just to also note: that this completely ignores any host / target IO actions that TH might want to run. cheers, moritz > On Nov 24, 2016, at 12:51 PM, Moritz Angermann wrote: > > It's certainly far from ideal, but for CI, what obstacles are there besides needing a runner accessible from cross compiling machine? > > E.g. Start the runner app on an iPhone plugged in into a USB power source and leave it there? > > Sent from my iPhone > >> On 24 Nov 2016, at 12:42 PM, Manuel M T Chakravarty wrote: >> >> Sorry, but I don’t think running on the device is practical. How do you want to do CI, for example? >> >> Manuel >> >>> Moritz Angermann : >>> >>> >>>> On Nov 23, 2016, at 7:50 PM, Simon Marlow wrote: >>>> >>>> […] >>>> >>>> My question would be: are you *sure* you can't run target code at compile time? Not even with an iphone simulator? >>> >>> This should be possible. However for proper development one would need to run on the >>> device (iPhone, iPad, …) for armv7 or arm64, as the Simulator is i386 or x86_64. >>> >>> There is a bit of additional engineering required here to get the shipping of >>> code from ghc to the runner on the target required (e.g. via network). As executing >>> and controlling applications on the actual hardware is limited, I guess a custom >>> ghc-runner application would have to be manually started on the device, which could >>> trivially be discovered using bonjour/zeroconf (or just giving ghc the host:port information). >>> >>> In general though, the runner does not have to obey all the restrictions apple puts >>> onto app-store distributed apps, as I expect that everyone could build and install >>> the runner themselves when intending to do iOS development with ghc. >>> >>> cheers, >>> moritz >>> _______________________________________________ >>> ghc-devs mailing list >>> ghc-devs at haskell.org >>> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs >> > > _______________________________________________ > ghc-devs mailing list > ghc-devs at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs From chak at justtesting.org Thu Nov 24 05:38:34 2016 From: chak at justtesting.org (Manuel M T Chakravarty) Date: Thu, 24 Nov 2016 16:38:34 +1100 Subject: Making (useful subsets of) bytecode portable between targets In-Reply-To: References: <87h971t2sb.fsf@shlevy-laptop.i-did-not-set--mail-host-address--so-tickle-me> Message-ID: <943355CC-884B-4F46-BA8A-B14B5AB78202@justtesting.org> If you use Travis CI or such, do you really want to have a runner accessible from an arbitrary host on the Internet? > Moritz Angermann : > > It's certainly far from ideal, but for CI, what obstacles are there besides needing a runner accessible from cross compiling machine? > > E.g. Start the runner app on an iPhone plugged in into a USB power source and leave it there? > > Sent from my iPhone > >> On 24 Nov 2016, at 12:42 PM, Manuel M T Chakravarty wrote: >> >> Sorry, but I don’t think running on the device is practical. How do you want to do CI, for example? >> >> Manuel >> >>> Moritz Angermann : >>> >>> >>>> On Nov 23, 2016, at 7:50 PM, Simon Marlow wrote: >>>> >>>> […] >>>> >>>> My question would be: are you *sure* you can't run target code at compile time? Not even with an iphone simulator? >>> >>> This should be possible. However for proper development one would need to run on the >>> device (iPhone, iPad, …) for armv7 or arm64, as the Simulator is i386 or x86_64. >>> >>> There is a bit of additional engineering required here to get the shipping of >>> code from ghc to the runner on the target required (e.g. via network). As executing >>> and controlling applications on the actual hardware is limited, I guess a custom >>> ghc-runner application would have to be manually started on the device, which could >>> trivially be discovered using bonjour/zeroconf (or just giving ghc the host:port information). >>> >>> In general though, the runner does not have to obey all the restrictions apple puts >>> onto app-store distributed apps, as I expect that everyone could build and install >>> the runner themselves when intending to do iOS development with ghc. >>> >>> cheers, >>> moritz >>> _______________________________________________ >>> ghc-devs mailing list >>> ghc-devs at haskell.org >>> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs >> > From simonpj at microsoft.com Thu Nov 24 09:30:08 2016 From: simonpj at microsoft.com (Simon Peyton Jones) Date: Thu, 24 Nov 2016 09:30:08 +0000 Subject: Constraint solver again Message-ID: Richard, I’ve taken another run at the constraint solver. It’s on wip/spj-tc-branch3 (you’ll need a forced update). I think I can safely commit it to HEAD in the light of your earlier comments, so I’ll do that soon, but I thought I’d just give you (and other ghc-devs) a heads-up. The two main commits are below. The former is small; the latter is the main event. Simon commit 570c3181342386b5cee1862f85a8ebed7d98d712 Author: Simon Peyton Jones Date: Wed Nov 23 16:00:00 2016 +0000 Allow TyVars in TcTypes Up to now we've had a rule that a TyVar can't apppear in a type seen by the type checker; they should all be TcTyVars. But: a) With -XTypeInType it becomes much harder to exclude them; see Note [TcTyVars in the typechecker] in TcType. b) It's unnecessary to exculde them; instead we can just treat a TyVar just like vanillaSkolemTv. This is what was causing an ASSERT error in indexed-types/should_fail/T12041, reported in Trac #12826. That patch allows a TyVar in a TcType. The most significant change is to make Var.tcTyVarDetails return vanillaSkolemTv. In fact it already did, but (a) it was not documented, and (b) we never exploited it. Now we rely on it. commit 6e6d93b8b713339dc5f74e8f93e35d0d94014d63 Author: Simon Peyton Jones Date: Tue Oct 25 17:41:45 2016 +0100 Another major constraint-solver refactoring This patch takes further my refactoring of the constraint solver, which I've been doing over the last couple of months in consultation with Richard. It fixes a number of tricky bugs that made the constraint solver actually go into a loop, including Trac #12526 Trac #12444 Trac #12538 The main changes are these * Flatten unification variables (fmvs/fuvs) appear on the LHS of a tvar/tyvar equality; thus fmv ~ alpha and not alpha ~ fmv See Note [Put flatten unification variables on the left] in TcUnify. This is implemented by TcUnify.swapOverTyVars. * Don't reduce a "loopy" CFunEqCan where the fsk appears on the LHS: F t1 .. tn ~ fsk where 'fsk' is free in t1..tn. See Note [FunEq occurs-check principle] in TcInteract This neatly stops some infinite loops that people reported; and it allows us to delete some crufty code in reduce_top_fun_eq. And it appears to be no loss whatsoever. As well as fixing loops, ContextStack2 and T5837 both terminate when they didn't before. * Previously we generated "derived shadow" constraints from Wanteds, but we could (and sometimes did; Trac #xxxx) repeatedly generate a derived shadow from the same Wanted. A big change in this patch is to have two kinds of Wanteds: [WD] behaves like a pair of a Wanted and a Derived [W] behaves like a Wanted only See CtFlavour and ShadowInfo in TcRnTypes, and the ctev_nosh field of a Wanted. This turned out to be a lot simpler. A [WD] gets split into a [W] and a [D] in TcSMonad.maybeEmitShaodow. See TcSMonad Note [The improvement story and derived shadows] * Rather than have a separate inert_model in the InertCans, I've put the derived equalities back into inert_eqs. We weren't gaining anything from a separate field. * Previously we had a mode for the constraint solver in which it would more aggressively solve Derived constraints; it was used for simplifying the context of a 'deriving' clause, or a 'default' delcaration, for example. But the complexity wasn't worth it; now I just make proper Wanted constraints. See TcMType.cloneWC * Don't generate injectivity improvement for Givens; see Note [No FunEq improvement for Givens] in TcInteract * solveSimpleWanteds leaves the insolubles in-place rather than returning them. Simpler. I also did lots of work on comments. -------------- next part -------------- An HTML attachment was scrubbed... URL: From ezyang at mit.edu Fri Nov 25 03:59:58 2016 From: ezyang at mit.edu (Edward Z. Yang) Date: Thu, 24 Nov 2016 22:59:58 -0500 Subject: Making (useful subsets of) bytecode portable between targets In-Reply-To: <87r364v8zd.fsf@ben-laptop.smart-cactus.org> References: <87h971t2sb.fsf@shlevy-laptop.i-did-not-set--mail-host-address--so-tickle-me> <87r364v8zd.fsf@ben-laptop.smart-cactus.org> Message-ID: <1480046166-sup-295@sabre> Excerpts from Ben Gamari's message of 2016-11-21 16:06:14 -0500: > > 3. Teach cabal to compile dependencies and modules for the build and > > target when cross-compiling and TH is used > > You'll need to speak with the Cabal folks about this. However, it's > probably safe to ignore this for now; there's a lot of work to done > before you'll be in a position to start thinking about this. Some related work that has been done for just compiling Setup scripts with the host system: https://github.com/haskell/cabal/issues/1493 and https://github.com/haskell/cabal/issues/4047 is where we have been going with it. John Ericson is in charge of the effort, I've CC'ed him to this list. Edward From ezyang at mit.edu Fri Nov 25 04:01:19 2016 From: ezyang at mit.edu (Edward Z. Yang) Date: Thu, 24 Nov 2016 23:01:19 -0500 Subject: Making (useful subsets of) bytecode portable between targets In-Reply-To: <943355CC-884B-4F46-BA8A-B14B5AB78202@justtesting.org> References: <87h971t2sb.fsf@shlevy-laptop.i-did-not-set--mail-host-address--so-tickle-me> <943355CC-884B-4F46-BA8A-B14B5AB78202@justtesting.org> Message-ID: <1480046427-sup-3746@sabre> At least for Travis, you can generate a private key that only Travis has access to, and use this to authenticate access to the runner. See https://docs.travis-ci.com/user/encryption-keys/ Edward Excerpts from Manuel M T Chakravarty's message of 2016-11-24 16:38:34 +1100: > If you use Travis CI or such, do you really want to have a runner accessible from an arbitrary host on the Internet? > > > Moritz Angermann : > > > > It's certainly far from ideal, but for CI, what obstacles are there besides needing a runner accessible from cross compiling machine? > > > > E.g. Start the runner app on an iPhone plugged in into a USB power source and leave it there? > > > > Sent from my iPhone > > > >> On 24 Nov 2016, at 12:42 PM, Manuel M T Chakravarty wrote: > >> > >> Sorry, but I don’t think running on the device is practical. How do you want to do CI, for example? > >> > >> Manuel > >> > >>> Moritz Angermann : > >>> > >>> > >>>> On Nov 23, 2016, at 7:50 PM, Simon Marlow wrote: > >>>> > >>>> […] > >>>> > >>>> My question would be: are you *sure* you can't run target code at compile time? Not even with an iphone simulator? > >>> > >>> This should be possible. However for proper development one would need to run on the > >>> device (iPhone, iPad, …) for armv7 or arm64, as the Simulator is i386 or x86_64. > >>> > >>> There is a bit of additional engineering required here to get the shipping of > >>> code from ghc to the runner on the target required (e.g. via network). As executing > >>> and controlling applications on the actual hardware is limited, I guess a custom > >>> ghc-runner application would have to be manually started on the device, which could > >>> trivially be discovered using bonjour/zeroconf (or just giving ghc the host:port information). > >>> > >>> In general though, the runner does not have to obey all the restrictions apple puts > >>> onto app-store distributed apps, as I expect that everyone could build and install > >>> the runner themselves when intending to do iOS development with ghc. > >>> > >>> cheers, > >>> moritz > >>> _______________________________________________ > >>> ghc-devs mailing list > >>> ghc-devs at haskell.org > >>> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs > >> > > > From chak at justtesting.org Fri Nov 25 06:38:20 2016 From: chak at justtesting.org (Manuel M T Chakravarty) Date: Fri, 25 Nov 2016 17:38:20 +1100 Subject: Making (useful subsets of) bytecode portable between targets In-Reply-To: <1480046427-sup-3746@sabre> References: <87h971t2sb.fsf@shlevy-laptop.i-did-not-set--mail-host-address--so-tickle-me> <943355CC-884B-4F46-BA8A-B14B5AB78202@justtesting.org> <1480046427-sup-3746@sabre> Message-ID: Ok, I am not saying that it is technical impossible. I am saying that it is *impractical*. Imagine Travis CI needing to run stuff on my phone that is attached to my Mac (if we are lucky), which is behind NAT somewhere in Australia. Running stuff in the simulator during a build would be pretty awkward, but running it on the device is not practical. Manuel PS: BTW, shipping binary code to the device means it has to be code signed using a distribution profile of a registered developer. That is one thing if Xcode does all the magic behind the scenes, but do you really want to make that part of the GHC build process? > Edward Z. Yang : > > At least for Travis, you can generate a private key that only Travis > has access to, and use this to authenticate access to the runner. > See https://docs.travis-ci.com/user/encryption-keys/ > > Edward > > Excerpts from Manuel M T Chakravarty's message of 2016-11-24 16:38:34 +1100: >> If you use Travis CI or such, do you really want to have a runner accessible from an arbitrary host on the Internet? >> >>> Moritz Angermann : >>> >>> It's certainly far from ideal, but for CI, what obstacles are there besides needing a runner accessible from cross compiling machine? >>> >>> E.g. Start the runner app on an iPhone plugged in into a USB power source and leave it there? >>> >>> Sent from my iPhone >>> >>>> On 24 Nov 2016, at 12:42 PM, Manuel M T Chakravarty wrote: >>>> >>>> Sorry, but I don’t think running on the device is practical. How do you want to do CI, for example? >>>> >>>> Manuel >>>> >>>>> Moritz Angermann : >>>>> >>>>> >>>>>> On Nov 23, 2016, at 7:50 PM, Simon Marlow wrote: >>>>>> >>>>>> […] >>>>>> >>>>>> My question would be: are you *sure* you can't run target code at compile time? Not even with an iphone simulator? >>>>> >>>>> This should be possible. However for proper development one would need to run on the >>>>> device (iPhone, iPad, …) for armv7 or arm64, as the Simulator is i386 or x86_64. >>>>> >>>>> There is a bit of additional engineering required here to get the shipping of >>>>> code from ghc to the runner on the target required (e.g. via network). As executing >>>>> and controlling applications on the actual hardware is limited, I guess a custom >>>>> ghc-runner application would have to be manually started on the device, which could >>>>> trivially be discovered using bonjour/zeroconf (or just giving ghc the host:port information). >>>>> >>>>> In general though, the runner does not have to obey all the restrictions apple puts >>>>> onto app-store distributed apps, as I expect that everyone could build and install >>>>> the runner themselves when intending to do iOS development with ghc. >>>>> >>>>> cheers, >>>>> moritz >>>>> _______________________________________________ >>>>> ghc-devs mailing list >>>>> ghc-devs at haskell.org >>>>> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs >>>> >>> >> > _______________________________________________ > ghc-devs mailing list > ghc-devs at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs From moritz at lichtzwerge.de Fri Nov 25 07:23:17 2016 From: moritz at lichtzwerge.de (Moritz Angermann) Date: Fri, 25 Nov 2016 15:23:17 +0800 Subject: Making (useful subsets of) bytecode portable between targets In-Reply-To: References: <87h971t2sb.fsf@shlevy-laptop.i-did-not-set--mail-host-address--so-tickle-me> <943355CC-884B-4F46-BA8A-B14B5AB78202@justtesting.org> <1480046427-sup-3746@sabre> Message-ID: <82BE62B1-2416-48BD-9A8E-B071785209DD@lichtzwerge.de> Aren’t we taking this a bit too far off topic? I feared as much when I wrote my initial reply. Please excuse. I agree that ghc + runner is not an optimal, and maybe even for some tasks (iOS) a pretty convoluted solution. This is only if we follow the proven solution to TH that luite in ghcjs pioneered, and which later found it’s way into ghc through iserv. If someone proposes a solution to TH that does not require a runner and allows the TH to be fully evaluated on the host with no need to evaluate on the target for cross compilation, that would be great! If the runner would just require the same architecture, maybe qemu would be a solution that would not require a device running? Then again I’m not sure how that would work with TH that directly or indirectly accesses libraries only available on iOS for example. Please don’t get me wrong. IMO ghc without TH is quite crippled, and therefore so is a cross compiling ghc. From the solutions I saw to this problem (zeroth, evil-splicer, and the ghcjs runner approach), the ghcjs runner approach, seems to me at least as the most promising, that would work for the largest subset of TH. To get this back on topic, if we have a architecture independent interpretable bytecode, for ghc, could we sidestep the runner solution altogether and have TH for the target be evaluated on the host? Is this what Shea initially wanted to go after? cheers, moritz > On Nov 25, 2016, at 2:38 PM, Manuel M T Chakravarty wrote: > > Ok, I am not saying that it is technical impossible. I am saying that it is *impractical*. > > Imagine Travis CI needing to run stuff on my phone that is attached to my Mac (if we are lucky), which is behind NAT somewhere in Australia. > > Running stuff in the simulator during a build would be pretty awkward, but running it on the device is not practical. > > Manuel > > PS: BTW, shipping binary code to the device means it has to be code signed using a distribution profile of a registered developer. That is one thing if Xcode does all the magic behind the scenes, but do you really want to make that part of the GHC build process? > >> Edward Z. Yang : >> >> At least for Travis, you can generate a private key that only Travis >> has access to, and use this to authenticate access to the runner. >> See https://docs.travis-ci.com/user/encryption-keys/ >> >> Edward >> >> Excerpts from Manuel M T Chakravarty's message of 2016-11-24 16:38:34 +1100: >>> If you use Travis CI or such, do you really want to have a runner accessible from an arbitrary host on the Internet? >>> >>>> Moritz Angermann : >>>> >>>> It's certainly far from ideal, but for CI, what obstacles are there besides needing a runner accessible from cross compiling machine? >>>> >>>> E.g. Start the runner app on an iPhone plugged in into a USB power source and leave it there? >>>> >>>> Sent from my iPhone >>>> >>>>> On 24 Nov 2016, at 12:42 PM, Manuel M T Chakravarty wrote: >>>>> >>>>> Sorry, but I don’t think running on the device is practical. How do you want to do CI, for example? >>>>> >>>>> Manuel >>>>> >>>>>> Moritz Angermann : >>>>>> >>>>>> >>>>>>> On Nov 23, 2016, at 7:50 PM, Simon Marlow wrote: >>>>>>> >>>>>>> […] >>>>>>> >>>>>>> My question would be: are you *sure* you can't run target code at compile time? Not even with an iphone simulator? >>>>>> >>>>>> This should be possible. However for proper development one would need to run on the >>>>>> device (iPhone, iPad, …) for armv7 or arm64, as the Simulator is i386 or x86_64. >>>>>> >>>>>> There is a bit of additional engineering required here to get the shipping of >>>>>> code from ghc to the runner on the target required (e.g. via network). As executing >>>>>> and controlling applications on the actual hardware is limited, I guess a custom >>>>>> ghc-runner application would have to be manually started on the device, which could >>>>>> trivially be discovered using bonjour/zeroconf (or just giving ghc the host:port information). >>>>>> >>>>>> In general though, the runner does not have to obey all the restrictions apple puts >>>>>> onto app-store distributed apps, as I expect that everyone could build and install >>>>>> the runner themselves when intending to do iOS development with ghc. >>>>>> >>>>>> cheers, >>>>>> moritz >>>>>> _______________________________________________ >>>>>> ghc-devs mailing list >>>>>> ghc-devs at haskell.org >>>>>> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs >>>>> >>>> >>> >> _______________________________________________ >> ghc-devs mailing list >> ghc-devs at haskell.org >> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs > > _______________________________________________ > ghc-devs mailing list > ghc-devs at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs From chak at justtesting.org Fri Nov 25 09:49:36 2016 From: chak at justtesting.org (Manuel M T Chakravarty) Date: Fri, 25 Nov 2016 20:49:36 +1100 Subject: Making (useful subsets of) bytecode portable between targets In-Reply-To: <82BE62B1-2416-48BD-9A8E-B071785209DD@lichtzwerge.de> References: <87h971t2sb.fsf@shlevy-laptop.i-did-not-set--mail-host-address--so-tickle-me> <943355CC-884B-4F46-BA8A-B14B5AB78202@justtesting.org> <1480046427-sup-3746@sabre> <82BE62B1-2416-48BD-9A8E-B071785209DD@lichtzwerge.de> Message-ID: I totally agree that GHC with TH is crippled and that this is a major restriction off the cross-compilation story. All I am saying is that I see a device runner (and to a degree a simulator runner) not as a solution to this *important* problem. Architecture independent interpretable byte code seems a much more attractive avenue for me. (Sorry if I didn’t make this clear.) Manuel > Moritz Angermann : > > Aren’t we taking this a bit too far off topic? I feared as much when I wrote my > initial reply. Please excuse. > > I agree that ghc + runner is not an optimal, and maybe even for some tasks (iOS) > a pretty convoluted solution. > > This is only if we follow the proven solution to TH that luite in ghcjs pioneered, > and which later found it’s way into ghc through iserv. If someone proposes a > solution to TH that does not require a runner and allows the TH to be fully > evaluated on the host with no need to evaluate on the target for cross compilation, > that would be great! > > If the runner would just require the same architecture, maybe qemu would be a solution > that would not require a device running? Then again I’m not sure how that would > work with TH that directly or indirectly accesses libraries only available on iOS for > example. > > Please don’t get me wrong. IMO ghc without TH is quite crippled, and therefore so is a > cross compiling ghc. From the solutions I saw to this problem (zeroth, evil-splicer, and > the ghcjs runner approach), the ghcjs runner approach, seems to me at least as the most > promising, that would work for the largest subset of TH. > > To get this back on topic, if we have a architecture independent interpretable bytecode, > for ghc, could we sidestep the runner solution altogether and have TH for the target > be evaluated on the host? Is this what Shea initially wanted to go after? > > cheers, > moritz > >> On Nov 25, 2016, at 2:38 PM, Manuel M T Chakravarty wrote: >> >> Ok, I am not saying that it is technical impossible. I am saying that it is *impractical*. >> >> Imagine Travis CI needing to run stuff on my phone that is attached to my Mac (if we are lucky), which is behind NAT somewhere in Australia. >> >> Running stuff in the simulator during a build would be pretty awkward, but running it on the device is not practical. >> >> Manuel >> >> PS: BTW, shipping binary code to the device means it has to be code signed using a distribution profile of a registered developer. That is one thing if Xcode does all the magic behind the scenes, but do you really want to make that part of the GHC build process? >> >>> Edward Z. Yang : >>> >>> At least for Travis, you can generate a private key that only Travis >>> has access to, and use this to authenticate access to the runner. >>> See https://docs.travis-ci.com/user/encryption-keys/ >>> >>> Edward >>> >>> Excerpts from Manuel M T Chakravarty's message of 2016-11-24 16:38:34 +1100: >>>> If you use Travis CI or such, do you really want to have a runner accessible from an arbitrary host on the Internet? >>>> >>>>> Moritz Angermann : >>>>> >>>>> It's certainly far from ideal, but for CI, what obstacles are there besides needing a runner accessible from cross compiling machine? >>>>> >>>>> E.g. Start the runner app on an iPhone plugged in into a USB power source and leave it there? >>>>> >>>>> Sent from my iPhone >>>>> >>>>>> On 24 Nov 2016, at 12:42 PM, Manuel M T Chakravarty wrote: >>>>>> >>>>>> Sorry, but I don’t think running on the device is practical. How do you want to do CI, for example? >>>>>> >>>>>> Manuel >>>>>> >>>>>>> Moritz Angermann : >>>>>>> >>>>>>> >>>>>>>> On Nov 23, 2016, at 7:50 PM, Simon Marlow wrote: >>>>>>>> >>>>>>>> […] >>>>>>>> >>>>>>>> My question would be: are you *sure* you can't run target code at compile time? Not even with an iphone simulator? >>>>>>> >>>>>>> This should be possible. However for proper development one would need to run on the >>>>>>> device (iPhone, iPad, …) for armv7 or arm64, as the Simulator is i386 or x86_64. >>>>>>> >>>>>>> There is a bit of additional engineering required here to get the shipping of >>>>>>> code from ghc to the runner on the target required (e.g. via network). As executing >>>>>>> and controlling applications on the actual hardware is limited, I guess a custom >>>>>>> ghc-runner application would have to be manually started on the device, which could >>>>>>> trivially be discovered using bonjour/zeroconf (or just giving ghc the host:port information). >>>>>>> >>>>>>> In general though, the runner does not have to obey all the restrictions apple puts >>>>>>> onto app-store distributed apps, as I expect that everyone could build and install >>>>>>> the runner themselves when intending to do iOS development with ghc. >>>>>>> >>>>>>> cheers, >>>>>>> moritz >>>>>>> _______________________________________________ >>>>>>> ghc-devs mailing list >>>>>>> ghc-devs at haskell.org >>>>>>> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs >>>>>> >>>>> >>>> >>> _______________________________________________ >>> ghc-devs mailing list >>> ghc-devs at haskell.org >>> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs >> >> _______________________________________________ >> ghc-devs mailing list >> ghc-devs at haskell.org >> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs From marlowsd at gmail.com Fri Nov 25 11:11:25 2016 From: marlowsd at gmail.com (Simon Marlow) Date: Fri, 25 Nov 2016 11:11:25 +0000 Subject: Making (useful subsets of) bytecode portable between targets In-Reply-To: <82BE62B1-2416-48BD-9A8E-B071785209DD@lichtzwerge.de> References: <87h971t2sb.fsf@shlevy-laptop.i-did-not-set--mail-host-address--so-tickle-me> <943355CC-884B-4F46-BA8A-B14B5AB78202@justtesting.org> <1480046427-sup-3746@sabre> <82BE62B1-2416-48BD-9A8E-B071785209DD@lichtzwerge.de> Message-ID: On 25 November 2016 at 07:23, Moritz Angermann wrote: [snip] > To get this back on topic, if we have a architecture independent > interpretable bytecode, > for ghc, could we sidestep the runner solution altogether and have TH for > the target > be evaluated on the host? Is this what Shea initially wanted to go after? > Yes, but architecture-independent bytecode is the least of the problems. Doing this properly is a really big change. We basically have two worlds: first, the compile-time world. In this world, we need all the packages and modules of the current package built for the host platform. Secondly, we need the runtime world, with all the packages and modules of the current package cross-compiled for the target platform. When compiling a module that uses TH, we need to - compile it as if we were compiling for the host platform, reading .hi files from the host world - run the TH code in the host world - restart the compilation, using the .hi files from the target world, and the results of running the splices But even this isn't going to be enough. What if your code imports some modules that are only available on the runtime platform? iOS APIs, for example. The right thing is to have a clean separation between runtime imports and compile-time imports. Perhaps we just annotate some imports to say they aren't needed at compile-time for running the TH code. but then we also need compile-time vs. runtime build-depends in our .cabal files, and so on. This is just off the top of my head, I'm sure there are more complexities I haven't thought about. Its a big project, but ultimately we do have to tackle it, because it's the right thing to do. Anyone interested in working on this? Maybe start a new proposal to flesh out the details. Cheers Simon > cheers, > moritz > > > On Nov 25, 2016, at 2:38 PM, Manuel M T Chakravarty < > chak at justtesting.org> wrote: > > > > Ok, I am not saying that it is technical impossible. I am saying that it > is *impractical*. > > > > Imagine Travis CI needing to run stuff on my phone that is attached to > my Mac (if we are lucky), which is behind NAT somewhere in Australia. > > > > Running stuff in the simulator during a build would be pretty awkward, > but running it on the device is not practical. > > > > Manuel > > > > PS: BTW, shipping binary code to the device means it has to be code > signed using a distribution profile of a registered developer. That is one > thing if Xcode does all the magic behind the scenes, but do you really want > to make that part of the GHC build process? > > > >> Edward Z. Yang : > >> > >> At least for Travis, you can generate a private key that only Travis > >> has access to, and use this to authenticate access to the runner. > >> See https://docs.travis-ci.com/user/encryption-keys/ > >> > >> Edward > >> > >> Excerpts from Manuel M T Chakravarty's message of 2016-11-24 16:38:34 > +1100: > >>> If you use Travis CI or such, do you really want to have a runner > accessible from an arbitrary host on the Internet? > >>> > >>>> Moritz Angermann : > >>>> > >>>> It's certainly far from ideal, but for CI, what obstacles are there > besides needing a runner accessible from cross compiling machine? > >>>> > >>>> E.g. Start the runner app on an iPhone plugged in into a USB power > source and leave it there? > >>>> > >>>> Sent from my iPhone > >>>> > >>>>> On 24 Nov 2016, at 12:42 PM, Manuel M T Chakravarty < > chak at justtesting.org> wrote: > >>>>> > >>>>> Sorry, but I don’t think running on the device is practical. How do > you want to do CI, for example? > >>>>> > >>>>> Manuel > >>>>> > >>>>>> Moritz Angermann : > >>>>>> > >>>>>> > >>>>>>> On Nov 23, 2016, at 7:50 PM, Simon Marlow > wrote: > >>>>>>> > >>>>>>> […] > >>>>>>> > >>>>>>> My question would be: are you *sure* you can't run target code at > compile time? Not even with an iphone simulator? > >>>>>> > >>>>>> This should be possible. However for proper development one would > need to run on the > >>>>>> device (iPhone, iPad, …) for armv7 or arm64, as the Simulator is > i386 or x86_64. > >>>>>> > >>>>>> There is a bit of additional engineering required here to get the > shipping of > >>>>>> code from ghc to the runner on the target required (e.g. via > network). As executing > >>>>>> and controlling applications on the actual hardware is limited, I > guess a custom > >>>>>> ghc-runner application would have to be manually started on the > device, which could > >>>>>> trivially be discovered using bonjour/zeroconf (or just giving ghc > the host:port information). > >>>>>> > >>>>>> In general though, the runner does not have to obey all the > restrictions apple puts > >>>>>> onto app-store distributed apps, as I expect that everyone could > build and install > >>>>>> the runner themselves when intending to do iOS development with ghc. > >>>>>> > >>>>>> cheers, > >>>>>> moritz > >>>>>> _______________________________________________ > >>>>>> ghc-devs mailing list > >>>>>> ghc-devs at haskell.org > >>>>>> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs > >>>>> > >>>> > >>> > >> _______________________________________________ > >> ghc-devs mailing list > >> ghc-devs at haskell.org > >> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs > > > > _______________________________________________ > > ghc-devs mailing list > > ghc-devs at haskell.org > > http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs > -------------- next part -------------- An HTML attachment was scrubbed... URL: From m at tweag.io Fri Nov 25 12:59:40 2016 From: m at tweag.io (Boespflug, Mathieu) Date: Fri, 25 Nov 2016 13:59:40 +0100 Subject: IRC: Logging #ghc with ircbrowse.net In-Reply-To: <87oa273yf6.fsf@ben-laptop.smart-cactus.org> References: <87poobpltf.fsf@ben-laptop.smart-cactus.org> <87oa273yf6.fsf@ben-laptop.smart-cactus.org> Message-ID: > > Note that currently there are no logs for any time prior to the last few > days. However, I have ZNC logs which Chris said he may be able to import > which cover the last several years of #ghc activity. If there is no > objection I would like to have him import these so we have a more > permanent archive of the channel. > That would be great! Best, Mathieu -------------- next part -------------- An HTML attachment was scrubbed... URL: From shea at shealevy.com Fri Nov 25 15:30:25 2016 From: shea at shealevy.com (Shea Levy) Date: Fri, 25 Nov 2016 10:30:25 -0500 Subject: Making (useful subsets of) bytecode portable between targets In-Reply-To: References: <87h971t2sb.fsf@shlevy-laptop.i-did-not-set--mail-host-address--so-tickle-me> <943355CC-884B-4F46-BA8A-B14B5AB78202@justtesting.org> <1480046427-sup-3746@sabre> <82BE62B1-2416-48BD-9A8E-B071785209DD@lichtzwerge.de> Message-ID: <87twavmvam.fsf@shlevy-laptop.netgear.com> Simon Marlow writes: > The right thing is to have a clean separation between runtime > imports and compile-time imports. Perhaps we just annotate some imports to > say they aren't needed at compile-time for running the TH code. but then > we also need compile-time vs. runtime build-depends in our .cabal files, > and so on. Yes, I was just looking into this yesterday. We already have something similar for plugins, though of course the TH story is much more involved (in part because GHC has to compile haskell code, not just load and run a pre-existing object file). > Its a big project, but ultimately we do have to tackle it, because it's the > right thing to do. Anyone interested in working on this? Maybe start a > new proposal to flesh out the details. Yeah, I'm going to at least try. Don't know where formal proposals go, but what I've got so far (definitely subject to change!): 1. Add a separate package database like we have for plugins for TH imports, defaulting to the normal package database when empty 2. Use the TH package db for code to be *run*, but resolve all reifications etc. against the normal target scope. 3. Add {-# TH #-}-annotated imports to specify modules to import compile-time code from (if a module *also* has definitions to be reified, it needs to be imported twice) 3a. If a module has any {-# TH #-} imports, enforce that *all* compile-time executed code is pulled in via {-# TH #-} imports. 3b. Optionally add a warning for TH-using code that doesn't use {-# TH #-}, as the first start of a migration path to enforcing compiletime/runtime separation across the ecosystem. 3c. Not sure what the specific difficulties are that require the staging restrictions, but possibly annotating same-module definitions with {-# TH -} might make this easier? 4. Teach cabal how to add packages to the TH database 4a. Not sure how all this works, but probably this is the place to e.g. request the non-profiled version of a package if ghc is non-profiled and the target code is profiled 5. Modify the build process of the cross-compiler to build a stage-2 compiler that builds code for the target *and* host (at least, enough of the host to build BCOs), and runs that host-targeted code in the interpreter. 5a. This will require some way to distinguish stage-2-as-target-native-compiler VS stage-2-as-hybrid-compiler. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 800 bytes Desc: not available URL: From moritz at lichtzwerge.de Fri Nov 25 15:35:03 2016 From: moritz at lichtzwerge.de (Moritz Angermann) Date: Fri, 25 Nov 2016 23:35:03 +0800 Subject: Making (useful subsets of) bytecode portable between targets In-Reply-To: <87twavmvam.fsf@shlevy-laptop.netgear.com> References: <87h971t2sb.fsf@shlevy-laptop.i-did-not-set--mail-host-address--so-tickle-me> <943355CC-884B-4F46-BA8A-B14B5AB78202@justtesting.org> <1480046427-sup-3746@sabre> <82BE62B1-2416-48BD-9A8E-B071785209DD@lichtzwerge.de> <87twavmvam.fsf@shlevy-laptop.netgear.com> Message-ID: <97B4AA2B-0C44-43A4-B2AC-B790261C5223@lichtzwerge.de> There is https://github.com/ghc-proposals/ghc-proposals Sent from my iPhone > On 25 Nov 2016, at 11:30 PM, Shea Levy wrote: > > Simon Marlow writes: > >> The right thing is to have a clean separation between runtime >> imports and compile-time imports. Perhaps we just annotate some imports to >> say they aren't needed at compile-time for running the TH code. but then >> we also need compile-time vs. runtime build-depends in our .cabal files, >> and so on. > > Yes, I was just looking into this yesterday. We already have something > similar for plugins, though of course the TH story is much more > involved (in part because GHC has to compile haskell code, not just load > and run a pre-existing object file). > >> Its a big project, but ultimately we do have to tackle it, because it's the >> right thing to do. Anyone interested in working on this? Maybe start a >> new proposal to flesh out the details. > > Yeah, I'm going to at least try. Don't know where formal proposals go, > but what I've got so far (definitely subject to change!): > > 1. Add a separate package database like we have for plugins for TH > imports, defaulting to the normal package database when empty > 2. Use the TH package db for code to be *run*, but resolve all > reifications etc. against the normal target scope. > 3. Add {-# TH #-}-annotated imports to specify modules to import > compile-time code from (if a module *also* has definitions to be > reified, it needs to be imported twice) > 3a. If a module has any {-# TH #-} imports, enforce that *all* > compile-time executed code is pulled in via {-# TH #-} imports. > 3b. Optionally add a warning for TH-using code that doesn't use > {-# TH #-}, as the first start of a migration path to enforcing > compiletime/runtime separation across the ecosystem. > 3c. Not sure what the specific difficulties are that require the > staging restrictions, but possibly annotating same-module > definitions with {-# TH -} might make this easier? > 4. Teach cabal how to add packages to the TH database > 4a. Not sure how all this works, but probably this is the place to > e.g. request the non-profiled version of a package if ghc is > non-profiled and the target code is profiled > 5. Modify the build process of the cross-compiler to build a stage-2 > compiler that builds code for the target *and* host (at least, enough > of the host to build BCOs), and runs that host-targeted code in the > interpreter. > 5a. This will require some way to distinguish > stage-2-as-target-native-compiler VS stage-2-as-hybrid-compiler. -------------- next part -------------- An HTML attachment was scrubbed... URL: From ezyang at mit.edu Fri Nov 25 15:45:52 2016 From: ezyang at mit.edu (Edward Z. Yang) Date: Fri, 25 Nov 2016 10:45:52 -0500 Subject: Making (useful subsets of) bytecode portable between targets In-Reply-To: <87twavmvam.fsf@shlevy-laptop.netgear.com> References: <87h971t2sb.fsf@shlevy-laptop.i-did-not-set--mail-host-address--so-tickle-me> <943355CC-884B-4F46-BA8A-B14B5AB78202@justtesting.org> <1480046427-sup-3746@sabre> <82BE62B1-2416-48BD-9A8E-B071785209DD@lichtzwerge.de> <87twavmvam.fsf@shlevy-laptop.netgear.com> Message-ID: <1480088424-sup-9778@sabre> Excerpts from Shea Levy's message of 2016-11-25 10:30:25 -0500: > > The right thing is to have a clean separation between runtime > > imports and compile-time imports. Perhaps we just annotate some imports to > > say they aren't needed at compile-time for running the TH code. but then > > we also need compile-time vs. runtime build-depends in our .cabal files, > > and so on. > > Yes, I was just looking into this yesterday. We already have something > similar for plugins, though of course the TH story is much more > involved (in part because GHC has to compile haskell code, not just load > and run a pre-existing object file). Actually, we don't really have this for plugins either. It is true that you can load a plugin independently of the imports of the module it is compiling, and that you can setup an independent package database for plugins, but the interfaces of the plugin are still all dumped in the same interface database that GHC uses for compile-time interfaces as well. It's delicate and has caused bugs before (https://ghc.haskell.org/trac/ghc/ticket/10420) Edward From monkleyon at googlemail.com Fri Nov 25 18:04:13 2016 From: monkleyon at googlemail.com (MarLinn) Date: Fri, 25 Nov 2016 19:04:13 +0100 Subject: Making (useful subsets of) bytecode portable between targets In-Reply-To: References: <87h971t2sb.fsf@shlevy-laptop.i-did-not-set--mail-host-address--so-tickle-me> <943355CC-884B-4F46-BA8A-B14B5AB78202@justtesting.org> <1480046427-sup-3746@sabre> <82BE62B1-2416-48BD-9A8E-B071785209DD@lichtzwerge.de> Message-ID: <78965331-2441-65ce-5fc8-327ea18d4fba@gmail.com> On 2016-11-25 12:11, Simon Marlow wrote: > We basically have two worlds: first, the compile-time world. In this > world, we need all the packages and modules of the current package > built for the host platform. Secondly, we need the runtime world, with > all the packages and modules of the current package cross-compiled for > the target platform. Maybe this separation and the preceding discussion of the two possible solutions suggests a usable approach to the architecture of this future system? First, let me reframe the "runner" idea. In a real-world environment, this seems like a viable solution either with two separate machines or with a VM nested in the main build machine. In both cases, we would need two parts of the compiler, communicating over customized channels. The cross-compiler approach is more or less just a variation on this with far less overhead. So why not build an architecture that supports both solutions? I practice, this would mean we need a tightly defined, but flexible API between at least two "architecture plugins" and one controller that could run on either side. To me, this sounds more like a build system than a mere compiler. And I'm okay with that, but I don't think GHC+Cabal alone can and should shoulder the complexity. There are nice, working build-systems out there that could take over the role of the controller, so all GHC and Cabal would have to offer are parsing, modularized steps, and nice hooks. In other words, /a //kind of meta-language to describe compiler deployments/ – and Haskell is great for describing languages. Here's yet another idea I'd like to add, although it is rather silly. The idea of a meta-language that describes a conversion structure seems very close to what Pandoc is doing for documents. And while Pandoc's architecture and history make it a bit static, GHC can still learn from it. Maybe, someday, there could even be a bigger, even more over-arching build language that describes the program, the documentation, and the deployment processes of the whole system? Cheers, MarLinn -------------- next part -------------- An HTML attachment was scrubbed... URL: From ben at well-typed.com Fri Nov 25 22:38:17 2016 From: ben at well-typed.com (Ben Gamari) Date: Fri, 25 Nov 2016 17:38:17 -0500 Subject: [ANNOUNCE] GHC 8.0.2 release candidate 1 Message-ID: <8737ifuqw6.fsf@ben-laptop.smart-cactus.org> Hello everyone, The GHC team is happy to (finally!) announce the first candiate of the 8.0.2 release of the Glasgow Haskell Compiler. Source and binary distributions are available at http://downloads.haskell.org/~ghc/8.0.2-rc1/ This is the first of what will hopefully be only two release candidates leading up the final 8.0.2 release. This release will fix a number bugs found in 8.0.1 including, * Interface file build determinism (#4012). * Compatibility with macOS Sierra and GCC compilers which compile position-independent executables by default * Runtime linker fixes on Windows (see #12797) * A compiler bug which resulted in undefined reference errors while compiling some packages (see #12076) * Compatability with systems which use the gold linker * A number of memory consistency bugs in the runtime system * A number of efficiency issues in the threaded runtime which manifest on larger core counts and large numbers of bound threads. * A typechecker bug which caused some programs using -XDefaultSignatures to be incorrectly accepted. * More than two-hundred other bugs. See Trac [1] for a complete listing. Unfortunately there is one known bug (#12757) which can result in runtime crashes which is still lurking in -rc1. This will be fixed in -rc2, which will be released in about a week. As always, let us know if you encounter trouble. Thanks to everyone who has contributed so far! Happy testing, - Ben [1] https://ghc.haskell.org/trac/ghc/query?status=closed&milestone=8.0.2&col=id&col=summary&col=status&col=type&col=priority&col=milestone&col=component&order=priority -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 454 bytes Desc: not available URL: From george.colpitts at gmail.com Sat Nov 26 00:15:25 2016 From: george.colpitts at gmail.com (George Colpitts) Date: Sat, 26 Nov 2016 00:15:25 +0000 Subject: [ANNOUNCE] GHC 8.0.2 release candidate 1 In-Reply-To: <8737ifuqw6.fsf@ben-laptop.smart-cactus.org> References: <8737ifuqw6.fsf@ben-laptop.smart-cactus.org> Message-ID: Thanks Ben, this is great! Installing the binary on the Mac results in the following minor problem: /usr/bin/install -c -m 644 docs/users_guide/build-man/ghc.1 "/usr/local/share/man/man1" install: /usr/local/share/man/man1/ghc.1: No such file or directory make[1]: *** [install_man] Error 71 make: *** [install] Error 2 The error message is a bit confusing as the file does exist. It is easily resolved by rm /usr/local/share/man/man1/ghc.1 I believe I encountered the same problem on ghc 8.0.1 rc1 Thanks George On Fri, Nov 25, 2016 at 6:39 PM Ben Gamari wrote: > > Hello everyone, > > The GHC team is happy to (finally!) announce the first candiate of the > 8.0.2 release of the Glasgow Haskell Compiler. Source and binary > distributions are available at > > http://downloads.haskell.org/~ghc/8.0.2-rc1/ > > This is the first of what will hopefully be only two release candidates > leading up the final 8.0.2 release. This release will fix a number bugs > found in 8.0.1 including, > > * Interface file build determinism (#4012). > > * Compatibility with macOS Sierra and GCC compilers which compile > position-independent executables by default > > * Runtime linker fixes on Windows (see #12797) > > * A compiler bug which resulted in undefined reference errors while > compiling some packages (see #12076) > > * Compatability with systems which use the gold linker > > * A number of memory consistency bugs in the runtime system > > * A number of efficiency issues in the threaded runtime which manifest > on larger core counts and large numbers of bound threads. > > * A typechecker bug which caused some programs using > -XDefaultSignatures to be incorrectly accepted. > > * More than two-hundred other bugs. See Trac [1] for a complete > listing. > > Unfortunately there is one known bug (#12757) which can result in > runtime crashes which is still lurking in -rc1. This will be fixed in > -rc2, which will be released in about a week. > > As always, let us know if you encounter trouble. Thanks to everyone who > has contributed so far! > > Happy testing, > > - Ben > > > [1] > https://ghc.haskell.org/trac/ghc/query?status=closed&milestone=8.0.2&col=id&col=summary&col=status&col=type&col=priority&col=milestone&col=component&order=priority > _______________________________________________ > ghc-devs mailing list > ghc-devs at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs > -------------- next part -------------- An HTML attachment was scrubbed... URL: From ben at well-typed.com Sat Nov 26 13:46:36 2016 From: ben at well-typed.com (Ben Gamari) Date: Sat, 26 Nov 2016 08:46:36 -0500 Subject: [ANNOUNCE] GHC 8.0.2 release candidate 1 In-Reply-To: References: <8737ifuqw6.fsf@ben-laptop.smart-cactus.org> Message-ID: <87zikmtkub.fsf@ben-laptop.smart-cactus.org> George Colpitts writes: > Thanks Ben, this is great! > > Installing the binary on the Mac results in the following minor problem: > > /usr/bin/install -c -m 644 docs/users_guide/build-man/ghc.1 > "/usr/local/share/man/man1" > install: /usr/local/share/man/man1/ghc.1: No such file or directory > make[1]: *** [install_man] Error 71 > make: *** [install] Error 2 > Thanks for the report, George! That is quite odd indeed. It sounds like /usr/local/share/man/man1/ghc.1 may have been a symlink to a directory which does not exist (possibly?). What does `ls -l /usr/local/share/man/man1/ghc.1` say now? Cheers, - Ben -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 454 bytes Desc: not available URL: From george.colpitts at gmail.com Sat Nov 26 16:46:36 2016 From: george.colpitts at gmail.com (George Colpitts) Date: Sat, 26 Nov 2016 16:46:36 +0000 Subject: [ANNOUNCE] GHC 8.0.2 release candidate 1 In-Reply-To: <87zikmtkub.fsf@ben-laptop.smart-cactus.org> References: <8737ifuqw6.fsf@ben-laptop.smart-cactus.org> <87zikmtkub.fsf@ben-laptop.smart-cactus.org> Message-ID: I think I am very atypical as I had the Haskell Platform installed and did an uninstall-hs before installing this release candidate. This is on the latest Mac OS and Xcode. At the time I got the error the file was a symbolic link, I believe to an existing file: install: /usr/local/share/man/man1/ghc.1: No such file or directory make[1]: *** [install_man] Error 71 make: *** [install] Error 2 bash-3.2$ ls -l /usr/local/share/man/man1/ghc.1 lrwxr-xr-x 1 gcolpitts admin 80 Jun 23 19:44 /usr/local/share/man/man1/ghc.1 -> /Library/Frameworks/GHC.framework/Versions/8.0.1-x86_64/usr/share/man/man1/ghc.1 bash-3.2$ rm /usr/local/share/man/man1/ghc.1 Now after a successful install of the binary and a successful compile from source I have: ls -l /usr/local/share/man/man1/ghc.1 -rw-r--r-- 1 root admin 58932 Nov 26 09:16 /usr/local/share/man/man1/ghc.1 bash-3.2$ ls -l /Library/Frameworks/GHC.framework/Versions/8.0.1-x86_64/usr/share/man/man1/ghc.1 ls -l /Library/Frameworks/GHC.framework/Versions/8.0.1-x86_64/usr/share/man/man1/ghc.1 -rw-r--r-- 1 root wheel 58214 May 21 2016 /Library/Frameworks/GHC.framework/Versions/8.0.1-x86_64/usr/share/man/man1/ghc.1 After the binary install I did a cabal install of threadscope, hlint and criterion and some minimal runtime testing. Everything looks fine. Thanks George On Sat, Nov 26, 2016 at 9:47 AM Ben Gamari wrote: > George Colpitts writes: > > > Thanks Ben, this is great! > > > > Installing the binary on the Mac results in the following minor problem: > > > > /usr/bin/install -c -m 644 docs/users_guide/build-man/ghc.1 > > "/usr/local/share/man/man1" > > install: /usr/local/share/man/man1/ghc.1: No such file or directory > > make[1]: *** [install_man] Error 71 > > make: *** [install] Error 2 > > > Thanks for the report, George! That is quite odd indeed. It sounds like > /usr/local/share/man/man1/ghc.1 may have been a symlink to a directory > which does not exist (possibly?). What does `ls -l > /usr/local/share/man/man1/ghc.1` say now? > > Cheers, > > - Ben > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From michal.terepeta at gmail.com Sat Nov 26 19:14:20 2016 From: michal.terepeta at gmail.com (Michal Terepeta) Date: Sat, 26 Nov 2016 19:14:20 +0000 Subject: Status of "Improved LLVM backend" Message-ID: Hi all, I was wondering what’s the current status of the “Improved LLVM backend” project ( https://ghc.haskell.org/trac/ghc/wiki/ImprovedLLVMBackend ). The page mentions a few main problems, but some seem to be already fixed: 1) Using/supporting only one version of LLVM. This has been done AFAIK. 2) Prebuilt binaries to be shipped together with GHC. I can't find anything about this. Is there a ticket? Has there been any progress on this? 3) Adding support for split-objs I found a ticket about it: https://ghc.haskell.org/trac/ghc/ticket/8300 which was closed as WONTFIX in favor of split-sections. So I guess this can also be considered as done. 4) Figuring out what LLVM optimizations are useful. Again, I can seem to find anything here. Has anyone looked at this? I only found an issue about this: https://ghc.haskell.org/trac/ghc/ticket/11295 The page also mentions that the generated IR could be improved in many cases, but it doesn't link to any tickets or discussions. Is there something I could read to better understand what are the main problems? The only thing I can recall is that proc point splitting is likely to cause issues for LLVM's ability to optimize the code. (but I only found a couple of email threads about this but couldn't find any follow-ups) Thanks, Michal -------------- next part -------------- An HTML attachment was scrubbed... URL: From tuncer.ayaz at gmail.com Sun Nov 27 00:37:41 2016 From: tuncer.ayaz at gmail.com (Tuncer Ayaz) Date: Sun, 27 Nov 2016 01:37:41 +0100 Subject: [ANNOUNCE] GHC 8.0.2 release candidate 1 In-Reply-To: <8737ifuqw6.fsf@ben-laptop.smart-cactus.org> References: <8737ifuqw6.fsf@ben-laptop.smart-cactus.org> Message-ID: On 25 November 2016 at 23:38, Ben Gamari wrote: > > As always, let us know if you encounter trouble. Thanks to everyone > who has contributed so far! No trouble building and running rc1, but some code in xmonad-contrib that builds fine with 8.0.1 doesn't with 8.0.2-rc1. Not sure if it's broken code or a ghc regression. https://github.com/xmonad/xmonad-contrib/issues/123 From moritz at lichtzwerge.de Sun Nov 27 03:29:25 2016 From: moritz at lichtzwerge.de (Moritz Angermann) Date: Sun, 27 Nov 2016 11:29:25 +0800 Subject: Status of "Improved LLVM backend" In-Reply-To: References: Message-ID: Hi, I’m trying to implement a bitcode producing llvm backend[1], which would potentially allow to use a range of llvm versions with ghc. However, this is only tangentially relevant to the improved llvm backend, as Austin correctly pointed out[2], as there are other complications besides the fragility of the textual representation. So this is mostly only relevant to the improved ir you mentioned. The bitcode code gen plugin right now follows mostly the textual ir generation, but tries to prevent the ubiquitous symbol to i8* casting. The llvm gen turns cmm into ir, at this point however at that point, the wordsize has been embedded already, which means that the current textual llvm gen as well as the bitcode llvm gen try to figure out if relative access is in multiple wordsizes to use llvms getElementPointer. I don’t know if generating llvm from stg instead of cmm would be a better approach, which is what ghcjs and eta do as far as I know. Cheers, moritz — [1]: https://github.com/ghc-proposals/ghc-proposals/pull/25 [2]: https://github.com/ghc-proposals/ghc-proposals/pull/25#issuecomment-261697189 > On Nov 27, 2016, at 3:14 AM, Michal Terepeta wrote: > > Hi all, > > I was wondering what’s the current status of the “Improved LLVM backend” project > ( https://ghc.haskell.org/trac/ghc/wiki/ImprovedLLVMBackend ). The page mentions a > few main problems, but some seem to be already fixed: > 1) Using/supporting only one version of LLVM. > This has been done AFAIK. > 2) Prebuilt binaries to be shipped together with GHC. > I can't find anything about this. Is there a ticket? Has there been any > progress on this? > 3) Adding support for split-objs > I found a ticket about it: https://ghc.haskell.org/trac/ghc/ticket/8300 > which was closed as WONTFIX in favor of split-sections. So I guess this can > also be considered as done. > 4) Figuring out what LLVM optimizations are useful. > Again, I can seem to find anything here. Has anyone looked at this? > I only found an issue about this: > https://ghc.haskell.org/trac/ghc/ticket/11295 > > The page also mentions that the generated IR could be improved in many cases, > but it doesn't link to any tickets or discussions. Is there something I could > read to better understand what are the main problems? > The only thing I can recall is that proc point splitting is likely to cause > issues for LLVM's ability to optimize the code. (but I only found a couple of email > threads about this but couldn't find any follow-ups) > > Thanks, > Michal > > _______________________________________________ > ghc-devs mailing list > ghc-devs at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs From tuncer.ayaz at gmail.com Sun Nov 27 13:30:40 2016 From: tuncer.ayaz at gmail.com (Tuncer Ayaz) Date: Sun, 27 Nov 2016 14:30:40 +0100 Subject: [ANNOUNCE] GHC 8.0.2 release candidate 1 In-Reply-To: References: <8737ifuqw6.fsf@ben-laptop.smart-cactus.org> Message-ID: On 27 November 2016 at 01:37, Tuncer Ayaz wrote: > On 25 November 2016 at 23:38, Ben Gamari wrote: > > > > As always, let us know if you encounter trouble. Thanks to everyone > > who has contributed so far! > > No trouble building and running rc1, but some code in xmonad-contrib > that builds fine with 8.0.1 doesn't with 8.0.2-rc1. Not sure if it's > broken code or a ghc regression. > > https://github.com/xmonad/xmonad-contrib/issues/123 It's a leftover use of ImpredicativeTypes and getting fixed[2] However, what's changed from 8.0.1 to 8.0.2 to trigger this? I mean, is a point release supposed to do this? I would expect 8.0 to 8.1 to break, but find it surprising x.0.1 to x.0.2 would as well. IIRC ImpredicativeTypes has been obsoleted a long time ago, and maybe 8.0.2 has fixes which catches code that slipped through before. That's an explanation that would make sense. In that case, it seems ok. [2] https://github.com/xmonad/xmonad-contrib/pull/124 From michal.terepeta at gmail.com Sun Nov 27 14:17:22 2016 From: michal.terepeta at gmail.com (Michal Terepeta) Date: Sun, 27 Nov 2016 14:17:22 +0000 Subject: Status of "Improved LLVM backend" In-Reply-To: References: Message-ID: > Hi, > > I’m trying to implement a bitcode producing llvm backend[1], which would potentially > allow to use a range of llvm versions with ghc. However, this is only tangentially > relevant to the improved llvm backend, as Austin correctly pointed out[2], as there are > other complications besides the fragility of the textual representation. > > So this is mostly only relevant to the improved ir you mentioned. The bitcode code gen > plugin right now follows mostly the textual ir generation, but tries to prevent the > ubiquitous symbol to i8* casting. The llvm gen turns cmm into ir, at this point however > at that point, the wordsize has been embedded already, which means that the current > textual llvm gen as well as the bitcode llvm gen try to figure out if relative access is > in multiple wordsizes to use llvms getElementPointer. That sounds interesting, do you know where could I find out more about this? (both when it comes to the current LLVM codegen and yours) > I don’t know if generating llvm from stg instead of cmm would be a better > approach, which is what ghcjs and eta do as far as I know. Wouldn't a step from STG to LLVM be much harder (LLVM IR is a pretty low-level representation compared to STG)? There are also a few passes on the Cmm level that seem necessary, e.g., `cmmLayoutStack`. Cheers, Michal -------------- next part -------------- An HTML attachment was scrubbed... URL: From allbery.b at gmail.com Sun Nov 27 17:37:20 2016 From: allbery.b at gmail.com (Brandon Allbery) Date: Sun, 27 Nov 2016 12:37:20 -0500 Subject: [ANNOUNCE] GHC 8.0.2 release candidate 1 In-Reply-To: References: <8737ifuqw6.fsf@ben-laptop.smart-cactus.org> Message-ID: On Sun, Nov 27, 2016 at 8:30 AM, Tuncer Ayaz wrote: > However, what's changed from 8.0.1 to 8.0.2 to trigger this? I mean, > is a point release supposed to do this? I would expect 8.0 to 8.1 to > break, but find it surprising x.0.1 to x.0.2 would as well. > ImpredicativeTypes has *always* been broken, just in different ways in every release. Worse, it never had a real specification, therefore no tests. I think it's just going to be ripped out finally in the next major release, since VisibleTypeApplication should handle most of the use cases. -- brandon s allbery kf8nh sine nomine associates allbery.b at gmail.com ballbery at sinenomine.net unix, openafs, kerberos, infrastructure, xmonad http://sinenomine.net -------------- next part -------------- An HTML attachment was scrubbed... URL: From judah.jacobson at gmail.com Sun Nov 27 20:18:52 2016 From: judah.jacobson at gmail.com (Judah Jacobson) Date: Sun, 27 Nov 2016 12:18:52 -0800 Subject: [ANNOUNCE] GHC 8.0.2 release candidate 1 In-Reply-To: <8737ifuqw6.fsf@ben-laptop.smart-cactus.org> References: <8737ifuqw6.fsf@ben-laptop.smart-cactus.org> Message-ID: Thanks Ben! When testing, I found that a type checker regression from 7.10 to 8.0 that I thought/hoped was resolved is in fact still present in this release candidate. I filed a new bug: https://ghc.haskell.org/trac/ghc/ticket/12885 It originally seemed the same as #12175. But unfortunately, although that problem is resolved in 8.0.2-rc1, this one is still around (though they may still be related). Thanks, -Judah On Fri, Nov 25, 2016 at 2:38 PM, Ben Gamari wrote: > > Hello everyone, > > The GHC team is happy to (finally!) announce the first candiate of the > 8.0.2 release of the Glasgow Haskell Compiler. Source and binary > distributions are available at > > http://downloads.haskell.org/~ghc/8.0.2-rc1/ > > This is the first of what will hopefully be only two release candidates > leading up the final 8.0.2 release. This release will fix a number bugs > found in 8.0.1 including, > > * Interface file build determinism (#4012). > > * Compatibility with macOS Sierra and GCC compilers which compile > position-independent executables by default > > * Runtime linker fixes on Windows (see #12797) > > * A compiler bug which resulted in undefined reference errors while > compiling some packages (see #12076) > > * Compatability with systems which use the gold linker > > * A number of memory consistency bugs in the runtime system > > * A number of efficiency issues in the threaded runtime which manifest > on larger core counts and large numbers of bound threads. > > * A typechecker bug which caused some programs using > -XDefaultSignatures to be incorrectly accepted. > > * More than two-hundred other bugs. See Trac [1] for a complete > listing. > > Unfortunately there is one known bug (#12757) which can result in > runtime crashes which is still lurking in -rc1. This will be fixed in > -rc2, which will be released in about a week. > > As always, let us know if you encounter trouble. Thanks to everyone who > has contributed so far! > > Happy testing, > > - Ben > > > [1] https://ghc.haskell.org/trac/ghc/query?status=closed& > milestone=8.0.2&col=id&col=summary&col=status&col=type& > col=priority&col=milestone&col=component&order=priority > > _______________________________________________ > ghc-devs mailing list > ghc-devs at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From moritz at lichtzwerge.de Mon Nov 28 01:43:04 2016 From: moritz at lichtzwerge.de (Moritz Angermann) Date: Mon, 28 Nov 2016 09:43:04 +0800 Subject: Status of "Improved LLVM backend" In-Reply-To: References: Message-ID: > On Nov 27, 2016, at 10:17 PM, Michal Terepeta wrote: > > > Hi, > > > > I’m trying to implement a bitcode producing llvm backend[1], which would potentially > > allow to use a range of llvm versions with ghc. However, this is only tangentially > > relevant to the improved llvm backend, as Austin correctly pointed out[2], as there are > > other complications besides the fragility of the textual representation. > > > > So this is mostly only relevant to the improved ir you mentioned. The bitcode code gen > > plugin right now follows mostly the textual ir generation, but tries to prevent the > > ubiquitous symbol to i8* casting. The llvm gen turns cmm into ir, at this point however > > at that point, the wordsize has been embedded already, which means that the current > > textual llvm gen as well as the bitcode llvm gen try to figure out if relative access is > > in multiple wordsizes to use llvms getElementPointer. > > That sounds interesting, do you know where could I find out more about this? > (both when it comes to the current LLVM codegen and yours) For the llvm code gen in ghc it’s usually the `_fast` suffix functions. See [1] and the `genStore_fast` 30 lines further down. My bitcode llvm gen follows that file [1], almost identically, as can be seen in [2]. However the `_fast` path is currently disabled. An example of the generated ir for the current llvm backend, and the bitcode backend, (textual ir, via llvm-dis) can be found in [3] and [4] respectively. > > > I don’t know if generating llvm from stg instead of cmm would be a better > > approach, which is what ghcjs and eta do as far as I know. > > Wouldn't a step from STG to LLVM be much harder (LLVM IR is a pretty low-level > representation compared to STG)? There are also a few passes on the Cmm level > that seem necessary, e.g., `cmmLayoutStack`. There is certainly a tradeoff between retaining more high-level information and having to lower them oneself. If I remember luite correctly, he said he had a similar intermediate format to cmm, just not cmm but something richer, which allows to better target javascript. The question basically boils down to asking if cmm is too low-level for llvm already; the embedding of wordsizes is an example where I think cmm might be to low-level for llvm. — [1]: https://github.com/ghc/ghc/blob/master/compiler/llvmGen/LlvmCodeGen/CodeGen.hs#L824 [2]: https://github.com/angerman/data-bitcode-plugin/blob/master/src/Data/BitCode/LLVM/Gen.hs [3]: https://gist.github.com/angerman/32ce9395e73cfea3348fcc7da108cd0a [4]: https://gist.github.com/angerman/d87db1657aac4e06a0886801aaf44329 From juhpetersen at gmail.com Mon Nov 28 07:37:09 2016 From: juhpetersen at gmail.com (Jens Petersen) Date: Mon, 28 Nov 2016 16:37:09 +0900 Subject: [ANNOUNCE] GHC 8.0.2 release candidate 1 In-Reply-To: <87zikmtkub.fsf@ben-laptop.smart-cactus.org> References: <8737ifuqw6.fsf@ben-laptop.smart-cactus.org> <87zikmtkub.fsf@ben-laptop.smart-cactus.org> Message-ID: On 26 November 2016 at 22:46, Ben Gamari wrote: > > /usr/bin/install -c -m 644 docs/users_guide/build-man/ghc.1 > > "/usr/local/share/man/man1" > > install: /usr/local/share/man/man1/ghc.1: No such file or directory > > make[1]: *** [install_man] Error 71 > > make: *** [install] Error 2 > I already mentioned this in a private mail to Ben. > Thanks for the report, George! That is quite odd indeed. It sounds like > /usr/local/share/man/man1/ghc.1 may have been a symlink to a directory > which does not exist (possibly?). > I don't think so. If you look at ghc-8.0.1.20161117-x86_64-centos67-linux.tar.xz for example you will it does not contain ghc.1 either: I think it is not being generated. Looks like a buildsystem regression to me wrt to 8.0.1: I guess we should file a bug... Here https://copr-be.cloud.fedoraproject.org/results/petersen/ghc-8.0.2/fedora-rawhide-i386/00479814-ghc/build.log.gz is a complete buildlog and https://github.com/fedora-haskell/ghc/commit/97b08fb4732a548db8e2bf7c8011b4419ac70d29 is my packaging workaround. Jens -------------- next part -------------- An HTML attachment was scrubbed... URL: From juhpetersen at gmail.com Mon Nov 28 07:44:22 2016 From: juhpetersen at gmail.com (Jens Petersen) Date: Mon, 28 Nov 2016 16:44:22 +0900 Subject: [ANNOUNCE] GHC 8.0.2 release candidate 1 In-Reply-To: References: <8737ifuqw6.fsf@ben-laptop.smart-cactus.org> <87zikmtkub.fsf@ben-laptop.smart-cactus.org> Message-ID: On 28 November 2016 at 16:37, Jens Petersen wrote: > I think it is not being generated. > Well it might be generated, but it is not getting installed properly by default anyway. Looks like a buildsystem regression to me wrt to 8.0.1: I guess we should > file a bug... > -------------- next part -------------- An HTML attachment was scrubbed... URL: From juhpetersen at gmail.com Mon Nov 28 07:55:57 2016 From: juhpetersen at gmail.com (Jens Petersen) Date: Mon, 28 Nov 2016 16:55:57 +0900 Subject: [ANNOUNCE] GHC 8.0.2 release candidate 1 In-Reply-To: <8737ifuqw6.fsf@ben-laptop.smart-cactus.org> References: <8737ifuqw6.fsf@ben-laptop.smart-cactus.org> Message-ID: On 26 November 2016 at 07:38, Ben Gamari wrote: > http://downloads.haskell.org/~ghc/8.0.2-rc1/ > Thank you, I built it for Fedora 25 (just released last week) and Rawhide: https://copr.fedorainfracloud.org/coprs/petersen/ghc-8.0.2 Hopefully there will be a build for F24 soon too. Jens -------------- next part -------------- An HTML attachment was scrubbed... URL: From rae at cs.brynmawr.edu Mon Nov 28 22:30:03 2016 From: rae at cs.brynmawr.edu (Richard Eisenberg) Date: Mon, 28 Nov 2016 17:30:03 -0500 Subject: Help needed: Restrictions of proc-notation with RebindableSyntax In-Reply-To: References: Message-ID: <84B44086-45A5-41D8-AAC9-DCB848C1CD39@cs.brynmawr.edu> Jan’s question is a good one, but I don’t know enough about procs to be able to answer. I do know that the answer can be found by looking for uses of `tcSyntaxOp` in the TcArrows module.... but I just can’t translate it all to source Haskell, having roughly 0 understanding of this end of the language. Can anyone else help Jan here? Richard > On Nov 23, 2016, at 4:34 AM, Jan Bracker via ghc-devs wrote: > > Hello, > > I want to use the proc-notation together with RebindableSyntax. So far what I am trying to do is working fine, but I would like to know what the exact restrictions on the supplied functions are. I am introducing additional indices and constraints on the operations. The documentation [1] says the details are in flux and that I should ask directly. > > Best, > Jan > > [1] https://downloads.haskell.org/~ghc/latest/docs/html/users_guide/glasgow_exts.html#rebindable-syntax-and-the-implicit-prelude-import _______________________________________________ > ghc-devs mailing list > ghc-devs at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs -------------- next part -------------- An HTML attachment was scrubbed... URL: From simonpj at microsoft.com Tue Nov 29 12:41:53 2016 From: simonpj at microsoft.com (Simon Peyton Jones) Date: Tue, 29 Nov 2016 12:41:53 +0000 Subject: Help needed: Restrictions of proc-notation with RebindableSyntax In-Reply-To: <84B44086-45A5-41D8-AAC9-DCB848C1CD39@cs.brynmawr.edu> References: <84B44086-45A5-41D8-AAC9-DCB848C1CD39@cs.brynmawr.edu> Message-ID: Jan, Type checking and desugaring for arrow syntax has received Absolutely No Love for several years. I do not understand how it works very well, and I would not be at all surprised if it is broken in corner cases. It really needs someone to look at it carefully, document it better, and perhaps refactor it – esp by using a different data type rather than piggy-backing on HsExpr. In the light of that understanding, I think rebindable syntax will be easier. I don’t know if you are up for that, but it’s a rather un-tended part of GHC. Thanks Simon From: ghc-devs [mailto:ghc-devs-bounces at haskell.org] On Behalf Of Richard Eisenberg Sent: 28 November 2016 22:30 To: Jan Bracker Cc: ghc-devs at haskell.org Subject: Help needed: Restrictions of proc-notation with RebindableSyntax Jan’s question is a good one, but I don’t know enough about procs to be able to answer. I do know that the answer can be found by looking for uses of `tcSyntaxOp` in the TcArrows module.... but I just can’t translate it all to source Haskell, having roughly 0 understanding of this end of the language. Can anyone else help Jan here? Richard On Nov 23, 2016, at 4:34 AM, Jan Bracker via ghc-devs > wrote: Hello, I want to use the proc-notation together with RebindableSyntax. So far what I am trying to do is working fine, but I would like to know what the exact restrictions on the supplied functions are. I am introducing additional indices and constraints on the operations. The documentation [1] says the details are in flux and that I should ask directly. Best, Jan [1] https://downloads.haskell.org/~ghc/latest/docs/html/users_guide/glasgow_exts.html#rebindable-syntax-and-the-implicit-prelude-import _______________________________________________ ghc-devs mailing list ghc-devs at haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs -------------- next part -------------- An HTML attachment was scrubbed... URL: From mail at joachim-breitner.de Tue Nov 29 16:20:19 2016 From: mail at joachim-breitner.de (Joachim Breitner) Date: Tue, 29 Nov 2016 11:20:19 -0500 Subject: Separating typechecking and type error reporting in two passes? Message-ID: <1480436419.27881.15.camel@joachim-breitner.de> Hi, the following is a rough idea that I came up with while pondering #12864, which is about better (and fewer!) error messages when the user forgot an argument to a function, or swapped their order. The current scheme of type checking and error reporting is the following (please correct me if I am wrong, I have actually done little in this area so far): The typechecker traverses the syntax tree from top to bottom. Along the way, it keeps track of the current context in terms of SDoc fragments of the form “In the second argument of…”. It generates constraints (e.g. the argument type of a function is the type of the actual argument), which it either solves, or propagate outwards as “wanted constraints”, which refer to their context, and refer to a “hole” in the program where, if this constraint gets solved later, some form of evidence gets filled in. At the end, if there are any wanted constraints left, they are reported as type errors, together with the context they are mentioned. But with -fdefer-type-errors, they are not reported, but the evidence holes are filled in with essentially calls to `error` that print the error message at runtime. The problem I see with this approach is that the type checker has to remember interesting bits about context that might possibly eventually be relevant when reporting the error. In particular, it makes it harder to report multiple related error messages at once. So I am wondering if this approach would be better: The type checker does *not* bother keeping track of context: It traverses the syntax tree, creates constraints, and unsolvable constraints get filled with “error evidence”. Basically as if -fdefer-type-errors is one. Then a second pass is done over the syntax tree. This pass does keep track of the context. Whenever it finds some error evidence, it reports it. I see the following advantages: * The type checker code gets a bit simpler and tidier. * As most compiled programs are type correct [citation needed], the  type checker, but not the error reporting, is compiler-performance- critical. This might make type checking a (possibly insignificant) tad faster. * The error reporting pass can “look around” more. For example, before recursing into a pair `(e1,e2)`, it could check for the special case of `(e1 ▷ TyError Int Bool, e1 ▷ TyError Bool Int)` and report this as one error “Tuple with swapped arguments” instead of two errors. The #12864 is a more elaborate application of this. * There could even be an intermediate pass over the syntax tree between typechecking and error reporting that “transform” or “optimizes” the AST by moving type errors around, by coalescing error or other things, all with the aim of giving easier to understand error messages. * (This is getting into the area of wild dreams:) Library authors could somehow express custom error messages for certain patterns of the form If the AST now contains an application of `Library.foo` where the first argument is a type error `TyError Int Bool`, then give this particular domain-specific error message. I don’t see any disadvantages now, but there probably are some, and I would be grateful about feedback from those who actually have worked with this part of GHC before. Thanks, Joachim -- Joachim “nomeata” Breitner   mail at joachim-breitner.de • https://www.joachim-breitner.de/   XMPP: nomeata at joachim-breitner.de • OpenPGP-Key: 0xF0FBF51F   Debian Developer: nomeata at debian.org -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 833 bytes Desc: This is a digitally signed message part URL: From simonpj at microsoft.com Tue Nov 29 16:27:20 2016 From: simonpj at microsoft.com (Simon Peyton Jones) Date: Tue, 29 Nov 2016 16:27:20 +0000 Subject: Levity polymorphism Message-ID: Richard. I’ve made a status page for levity polymorphism. Everyone: tag levity-polymorphic tickets with “LevityPolymorphism” keyword. We really need a GHC proposal too… Simon https://ghc.haskell.org/trac/ghc/wiki/LevityPolymorphism -------------- next part -------------- An HTML attachment was scrubbed... URL: From rpglover64 at gmail.com Tue Nov 29 16:48:28 2016 From: rpglover64 at gmail.com (Alex Rozenshteyn) Date: Tue, 29 Nov 2016 16:48:28 +0000 Subject: Separating typechecking and type error reporting in two passes? In-Reply-To: <1480436419.27881.15.camel@joachim-breitner.de> References: <1480436419.27881.15.camel@joachim-breitner.de> Message-ID: One concern I have is with the claim that "most compiled programs are type correct". This has emphatically not been my experience while developing Haskell. Often, I edit and recompile to find the next type error to fix, or the new type of the hole; this is especially easy (and automatic) in emacs with flycheck. It's also the case that compiling correct programs is (or at least appears to me to be) much slower than compiling incorrect ones (with GHC 8.0.1, at least). I worry that this proposal might slow down type errors significantly. Of course, someone with more (basically any) knowledge of GHC internals can correct me and allay my fear. On Tue, Nov 29, 2016 at 8:20 AM Joachim Breitner wrote: > Hi, > > the following is a rough idea that I came up with while pondering > #12864, which is about better (and fewer!) error messages when the user > forgot an argument to a function, or swapped their order. > > > The current scheme of type checking and error reporting is the > following (please correct me if I am wrong, I have actually done little > in this area so far): > > The typechecker traverses the syntax tree from top to bottom. Along > the way, it keeps track of the current context in terms of SDoc > fragments of the form “In the second argument of…”. It generates > constraints (e.g. the argument type of a function is the type of the > actual argument), which it either solves, or propagate outwards as > “wanted constraints”, which refer to their context, and refer to a > “hole” in the program where, if this constraint gets solved later, > some form of evidence gets filled in. > At the end, if there are any wanted constraints left, they are > reported as type errors, together with the context they are > mentioned. > But with -fdefer-type-errors, they are not reported, but the > evidence holes are filled in with essentially calls to `error` that > print the error message at runtime. > > The problem I see with this approach is that the type checker has to > remember interesting bits about context that might possibly eventually > be relevant when reporting the error. In particular, it makes it harder > to report multiple related error messages at once. > > > So I am wondering if this approach would be better: > > The type checker does *not* bother keeping track of context: It > traverses the syntax tree, creates constraints, and unsolvable > constraints get filled with “error evidence”. Basically as if > -fdefer-type-errors is one. > > Then a second pass is done over the syntax tree. This pass does keep > track of the context. Whenever it finds some error evidence, it > reports it. > > > I see the following advantages: > > * The type checker code gets a bit simpler and tidier. > * As most compiled programs are type correct [citation needed], the > type checker, but not the error reporting, is compiler-performance- > critical. This might make type checking a (possibly insignificant) > tad faster. > * The error reporting pass can “look around” more. For example, before > recursing into a pair `(e1,e2)`, it could check for the special case > of `(e1 ▷ TyError Int Bool, e1 ▷ TyError Bool Int)` and report this > as one error “Tuple with swapped arguments” instead of two errors. > The #12864 is a more elaborate application of this. > * There could even be an intermediate pass over the syntax tree > between typechecking and error reporting that “transform” or > “optimizes” the AST by moving type errors around, by coalescing > error or other things, all with the aim of giving easier to > understand error messages. > * (This is getting into the area of wild dreams:) > Library authors could somehow express custom error messages > for certain patterns of the form > If the AST now contains an application of `Library.foo` where > the first argument is a type error `TyError Int Bool`, then > give this particular domain-specific error message. > > I don’t see any disadvantages now, but there probably are some, and I > would be grateful about feedback from those who actually have worked > with this part of GHC before. > > Thanks, > Joachim > > -- > Joachim “nomeata” Breitner > mail at joachim-breitner.de • https://www.joachim-breitner.de/ > XMPP: nomeata at joachim-breitner.de • OpenPGP-Key: 0xF0FBF51F > Debian Developer: nomeata at debian.org > _______________________________________________ > ghc-devs mailing list > ghc-devs at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs > -------------- next part -------------- An HTML attachment was scrubbed... URL: From mail at joachim-breitner.de Tue Nov 29 16:52:31 2016 From: mail at joachim-breitner.de (Joachim Breitner) Date: Tue, 29 Nov 2016 11:52:31 -0500 Subject: Separating typechecking and type error reporting in two passes? In-Reply-To: References: <1480436419.27881.15.camel@joachim-breitner.de> Message-ID: <1480438351.27881.17.camel@joachim-breitner.de> Hi, I guess the claim is still true: Think about just the amount of code you compile when you install your dependencies. But you are right that when the programmer sits there and waits for a result, that’s when snappyness is important. I don’t expect this change to be human-noticable in terms of performance, and the prospect of getting more useful error messages (which are easier to grasp and fix) will certainly outweigh that. Anyways, performance aspects are just a side-effect of this. Greetings, Joachim Am Dienstag, den 29.11.2016, 16:48 +0000 schrieb Alex Rozenshteyn: > One concern I have is with the claim that "most compiled programs are > type correct". This has emphatically not been my experience while > developing Haskell. Often, I edit and recompile to find the next type > error to fix, or the new type of the hole; this is especially easy > (and automatic) in emacs with flycheck. > > It's also the case that compiling correct programs is (or at least > appears to me to be) much slower than compiling incorrect ones (with > GHC 8.0.1, at least). I worry that this proposal might slow down type > errors significantly. Of course, someone with more (basically any) > knowledge of GHC internals can correct me and allay my fear. > > On Tue, Nov 29, 2016 at 8:20 AM Joachim Breitner er.de> wrote: > > Hi, > > > > the following is a rough idea that I came up with while pondering > > #12864, which is about better (and fewer!) error messages when the > > user > > forgot an argument to a function, or swapped their order. > > > > > > The current scheme of type checking and error reporting is the > > following (please correct me if I am wrong, I have actually done > > little > > in this area so far): > > > >     The typechecker traverses the syntax tree from top to bottom. > > Along > >     the way, it keeps track of the current context in terms of SDoc > >     fragments of the form “In the second argument of…”. It > > generates > >     constraints (e.g. the argument type of a function is the type > > of the > >     actual argument), which it either solves, or propagate outwards > > as > >     “wanted constraints”, which refer to their context, and refer > > to a > >     “hole” in the program where, if this constraint gets solved > > later, > >     some form of evidence gets filled in. > >     At the end, if there are any wanted constraints left, they are > >     reported as type errors, together with the context they are > >     mentioned. > >     But with -fdefer-type-errors, they are not reported, but the > >     evidence holes are filled in with essentially calls to `error` > > that > >     print the error message at runtime. > > > > The problem I see with this approach is that the type checker has > > to > > remember interesting bits about context that might possibly > > eventually > > be relevant when reporting the error. In particular, it makes it > > harder > >  to report multiple related error messages at once. > > > > > > So I am wondering if this approach would be better: > > > >     The type checker does *not* bother keeping track of context: It > >     traverses the syntax tree, creates constraints, and unsolvable > >     constraints get filled with “error evidence”. Basically as if > >     -fdefer-type-errors is one. > > > >     Then a second pass is done over the syntax tree. This pass does > > keep > >     track of the context. Whenever it finds some error evidence, it > >     reports it. > > > > > > I see the following advantages: > > > >  * The type checker code gets a bit simpler and tidier. > >  * As most compiled programs are type correct [citation needed], > > the  > >    type checker, but not the error reporting, is compiler- > > performance- > >    critical. This might make type checking a (possibly > > insignificant) > >    tad faster. > >  * The error reporting pass can “look around” more. For example, > > before > >    recursing into a pair `(e1,e2)`, it could check for the special > > case > >    of `(e1 ▷ TyError Int Bool, e1 ▷ TyError Bool Int)` and report > > this > >    as one error “Tuple with swapped arguments” instead of two > > errors. > >    The #12864 is a more elaborate application of this. > >  * There could even be an intermediate pass over the syntax tree > >    between typechecking and error reporting that “transform” or > >    “optimizes” the AST by moving type errors around, by coalescing > >    error or other things, all with the aim of giving easier to > >    understand error messages. > >  * (This is getting into the area of wild dreams:) > >    Library authors could somehow express custom error messages > >    for certain patterns of the form > >    If the AST now contains an application of `Library.foo` where > >    the first argument is a type error `TyError Int Bool`, then > >    give this particular domain-specific error message. > > > > I don’t see any disadvantages now, but there probably are some, and > > I > > would be grateful about feedback from those who actually have > > worked > > with this part of GHC before. > > > > Thanks, > > Joachim > > > > -- > > Joachim “nomeata” Breitner > >   mail at joachim-breitner.de • https://www.joachim-breitner.de/ > >   XMPP: nomeata at joachim-breitner.de • OpenPGP-Key: 0xF0FBF51F > >   Debian Developer: nomeata at debian.org_____________________________ > > __________________ > > ghc-devs mailing list > > ghc-devs at haskell.org > > http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs > > > > _______________________________________________ > ghc-devs mailing list > ghc-devs at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs -- Joachim Breitner mail at joachim-breitner.de http://www.joachim-breitner.de/ -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 833 bytes Desc: This is a digitally signed message part URL: From ben at well-typed.com Tue Nov 29 18:01:52 2016 From: ben at well-typed.com (Ben Gamari) Date: Tue, 29 Nov 2016 13:01:52 -0500 Subject: [ANNOUNCE] GHC 8.0.2 release candidate 1 In-Reply-To: References: <8737ifuqw6.fsf@ben-laptop.smart-cactus.org> Message-ID: <87eg1utban.fsf@ben-laptop.smart-cactus.org> Jens Petersen writes: > On 26 November 2016 at 07:38, Ben Gamari wrote: > >> http://downloads.haskell.org/~ghc/8.0.2-rc1/ >> > > Thank you, I built it for Fedora 25 (just released last week) and Rawhide: > > https://copr.fedorainfracloud.org/coprs/petersen/ghc-8.0.2 > > Hopefully there will be a build for F24 soon too. > Thanks Jens! Cheers, - Ben -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 454 bytes Desc: not available URL: From michal.terepeta at gmail.com Tue Nov 29 19:09:58 2016 From: michal.terepeta at gmail.com (Michal Terepeta) Date: Tue, 29 Nov 2016 19:09:58 +0000 Subject: Status of "Improved LLVM backend" In-Reply-To: References: Message-ID: On Mon, Nov 28, 2016 at 2:43 AM Moritz Angermann wrote: [...] > For the llvm code gen in ghc it’s usually the `_fast` suffix functions. See [1] and > the `genStore_fast` 30 lines further down. My bitcode llvm gen follows that file [1], > almost identically, as can be seen in [2]. However the `_fast` path is currently > disabled. > > An example of the generated ir for the current llvm backend, and the bitcode backend, > (textual ir, via llvm-dis) can be found in [3] and [4] respectively. Cool, thanks a lot for the links! > > > I don’t know if generating llvm from stg instead of cmm would be a better > > > approach, which is what ghcjs and eta do as far as I know. > > > > Wouldn't a step from STG to LLVM be much harder (LLVM IR is a pretty low-level > > representation compared to STG)? There are also a few passes on the Cmm level > > that seem necessary, e.g., `cmmLayoutStack`. > There is certainly a tradeoff between retaining more high-level information and > having to lower them oneself. If I remember luite correctly, he said he had a similar > intermediate format to cmm, just not cmm but something richer, which allows > to better target javascript. The question basically boils down to asking if cmm is > too low-level for llvm already; the embedding of wordsizes is an example where I think > cmm might be to low-level for llvm. Ok, I see. This is quite interesting - I'm wondering if it makes sense to collect thought/ideas like that somewhere (e.g., a wiki page with all the issues of using current Cmm for LLVM backend, or just adding some comments in the code). Thanks, Michal -------------- next part -------------- An HTML attachment was scrubbed... URL: From moritz at lichtzwerge.de Wed Nov 30 06:33:17 2016 From: moritz at lichtzwerge.de (Moritz Angermann) Date: Wed, 30 Nov 2016 14:33:17 +0800 Subject: Status of "Improved LLVM backend" In-Reply-To: References: Message-ID: <808E98F2-EAB7-44C1-8097-990E5B544B8A@lichtzwerge.de> > > > > I don’t know if generating llvm from stg instead of cmm would be a better > > > > approach, which is what ghcjs and eta do as far as I know. > > > > > > Wouldn't a step from STG to LLVM be much harder (LLVM IR is a pretty low-level > > > representation compared to STG)? There are also a few passes on the Cmm level > > > that seem necessary, e.g., `cmmLayoutStack`. > > > There is certainly a tradeoff between retaining more high-level information and > > having to lower them oneself. If I remember luite correctly, he said he had a similar > > intermediate format to cmm, just not cmm but something richer, which allows > > to better target javascript. The question basically boils down to asking if cmm is > > too low-level for llvm already; the embedding of wordsizes is an example where I think > > cmm might be to low-level for llvm. > > Ok, I see. This is quite interesting - I'm wondering if it makes sense to > collect thought/ideas like that somewhere (e.g., a wiki page with all the issues > of using current Cmm for LLVM backend, or just adding some comments in the > code). That indeed is an interesting question, to which I don’t have a satisfying answer yet. I’m trying to note these kinds of lookup down in code as I’m trying to go along porting over the textual ir gen to the bitcode ir gen. I would consider this to be a second iteration though. First trying to get the bitcode pipeline to work nicely (this includes having an option to have ghc emit bitcode instead of the assembled object code), and see where that takes us, and then trying to incrementally improve on that. cheers, moritz From nicola.gigante at gmail.com Wed Nov 30 08:37:38 2016 From: nicola.gigante at gmail.com (Nicola Gigante) Date: Wed, 30 Nov 2016 09:37:38 +0100 Subject: Separating typechecking and type error reporting in two passes? In-Reply-To: <1480438351.27881.17.camel@joachim-breitner.de> References: <1480436419.27881.15.camel@joachim-breitner.de> <1480438351.27881.17.camel@joachim-breitner.de> Message-ID: > Il giorno 29 nov 2016, alle ore 17:52, Joachim Breitner ha scritto: > > Hi, > > I guess the claim is still true: Think about just the amount of code > you compile when you install your dependencies. > > But you are right that when the programmer sits there and waits for a > result, that’s when snappyness is important. I don’t expect this change > to be human-noticable in terms of performance, and the prospect of > getting more useful error messages (which are easier to grasp and fix) > will certainly outweigh that. > > Anyways, performance aspects are just a side-effect of this. > Hi all, the following is a comment from an interested outsider. I’ve never hacked on GHC, but I have some little experience with clang internals. Compiling C++ code is a very heavy task, especially when a lot of templates are involved, and the design of the whole compiler is particularly performance-driven. As you may know, they nevertheless put a lot of effort on the understandability of compilation errors. As a coding guideline, they treat the compilation of correct code as the “fast path”, and the error reporting as the slow path. This doesn’t mean the compiler is slow at reporting errors: as much as you can go around the AST to collect information, you won’t ever be able to slow it so much as to outweigh the time to codegen the code if it were correct. So at the end, the programmer experiences a fast iteration anyway. All of this to say that my humble experience with clang suggests that an improvement in error messages is worth a little slow down in the incorrect code compilation path, and it is a very important goal to pursue even if it had to slow down some micro benchmark. Greetings, Nicola From lonetiger at gmail.com Wed Nov 30 09:01:00 2016 From: lonetiger at gmail.com (lonetiger at gmail.com) Date: Wed, 30 Nov 2016 09:01:00 +0000 Subject: Windows toolchain update Message-ID: <583e954c.e626c20a.f98d5.62cb@mx.google.com> Hi Windows devs, The Windows GCC has been updated to 6.2.0 and binutils to 2.27. At some point please rebuild using these binaries. Do throw away your old toolchain cache before getting the new one: rm -rf ghc-tarballs && ./configure --enable-tarballs-autodownload The plan is to ship these versions with GHC 8.2, though binutils will likely Get another minor bump. Thanks, Tamar -------------- next part -------------- An HTML attachment was scrubbed... URL: From simonpj at microsoft.com Wed Nov 30 10:51:34 2016 From: simonpj at microsoft.com (Simon Peyton Jones) Date: Wed, 30 Nov 2016 10:51:34 +0000 Subject: Separating typechecking and type error reporting in two passes? In-Reply-To: <1480436419.27881.15.camel@joachim-breitner.de> References: <1480436419.27881.15.camel@joachim-breitner.de> Message-ID: | Then a second pass is done over the syntax tree. This pass does | keep | track of the context. Whenever it finds some error evidence, it | reports it. The syntax tree is a big type. A second pass would be a fairly big deal. But doable. You'd need to be able to look at the nature of the error; SDocs won't do. Maybe errors become a data type. That might be a good idea but it would be another big deal. I very much doubt that you'll be able to discard the context information from the type checker. Maybe some of it. I can't say exactly why, it's a gut feel for now. There is a rich literature on type errors, worth digging into. Alejandro Serrano and his adviser Juraiaan Hage are thinking about this at the moment. SherLoc was interesting too; worked for Haskell. Lennart gave a nice talk at the Haskell Implementors meeting last year about error provenance. Maybe available online? Simon | -----Original Message----- | From: ghc-devs [mailto:ghc-devs-bounces at haskell.org] On Behalf Of | Joachim Breitner | Sent: 29 November 2016 16:20 | To: ghc-devs at haskell.org | Subject: Separating typechecking and type error reporting in two | passes? | | Hi, | | the following is a rough idea that I came up with while pondering | #12864, which is about better (and fewer!) error messages when the | user forgot an argument to a function, or swapped their order. | | | The current scheme of type checking and error reporting is the | following (please correct me if I am wrong, I have actually done | little in this area so far): | | The typechecker traverses the syntax tree from top to bottom. | Along | the way, it keeps track of the current context in terms of SDoc | fragments of the form “In the second argument of…”. It generates | constraints (e.g. the argument type of a function is the type of | the | actual argument), which it either solves, or propagate outwards as | “wanted constraints”, which refer to their context, and refer to a | “hole” in the program where, if this constraint gets solved later, | some form of evidence gets filled in. | At the end, if there are any wanted constraints left, they are | reported as type errors, together with the context they are | mentioned. | But with -fdefer-type-errors, they are not reported, but the | evidence holes are filled in with essentially calls to `error` | that | print the error message at runtime. | | The problem I see with this approach is that the type checker has to | remember interesting bits about context that might possibly eventually | be relevant when reporting the error. In particular, it makes it | harder to report multiple related error messages at once. | | | So I am wondering if this approach would be better: | | The type checker does *not* bother keeping track of context: It | traverses the syntax tree, creates constraints, and unsolvable | constraints get filled with “error evidence”. Basically as if | -fdefer-type-errors is one. | | Then a second pass is done over the syntax tree. This pass does | keep | track of the context. Whenever it finds some error evidence, it | reports it. | | | I see the following advantages: | | * The type checker code gets a bit simpler and tidier. | * As most compiled programs are type correct [citation needed], the | type checker, but not the error reporting, is compiler-performance- | critical. This might make type checking a (possibly insignificant) | tad faster. | * The error reporting pass can “look around” more. For example, | before | recursing into a pair `(e1,e2)`, it could check for the special | case | of `(e1 ▷ TyError Int Bool, e1 ▷ TyError Bool Int)` and report this | as one error “Tuple with swapped arguments” instead of two errors. | The #12864 is a more elaborate application of this. | * There could even be an intermediate pass over the syntax tree | between typechecking and error reporting that “transform” or | “optimizes” the AST by moving type errors around, by coalescing | error or other things, all with the aim of giving easier to | understand error messages. | * (This is getting into the area of wild dreams:) | Library authors could somehow express custom error messages | for certain patterns of the form | If the AST now contains an application of `Library.foo` where | the first argument is a type error `TyError Int Bool`, then | give this particular domain-specific error message. | | I don’t see any disadvantages now, but there probably are some, and I | would be grateful about feedback from those who actually have worked | with this part of GHC before. | | Thanks, | Joachim | | -- | Joachim “nomeata” Breitner |   mail at joachim-breitner.de • | https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.j | oachim- | breitner.de%2F&data=02%7C01%7Csimonpj%40microsoft.com%7C41dcebe5f26043 | 94f94108d41873a1f0%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636160 | 332322948063&sdata=hoylWVvBSQjqGmm0ICnr3nDFz80waxDStDOjWDPQb5A%3D&rese | rved=0 |   XMPP: nomeata at joachim-breitner.de • OpenPGP-Key: 0xF0FBF51F |   Debian Developer: nomeata at debian.org From monkleyon at googlemail.com Wed Nov 30 11:59:25 2016 From: monkleyon at googlemail.com (MarLinn) Date: Wed, 30 Nov 2016 12:59:25 +0100 Subject: Separating typechecking and type error reporting in two passes? In-Reply-To: <1480438351.27881.17.camel@joachim-breitner.de> References: <1480436419.27881.15.camel@joachim-breitner.de> <1480438351.27881.17.camel@joachim-breitner.de> Message-ID: <13bbd92a-612c-83b6-af8f-c421203c116a@gmail.com> > But you are right that when the programmer sits there and waits for a > result, that’s when snappyness is important. I had a random idea based on this observation: (With a certain flag set) the compiler could follow the existing strategy until it has hit the first n errors, possibly with n=1. Then it could switch off the context overhead and all subsequent errors could be deferred or not fleshed out. Or, alternatively, the proposed new strategy is used, but the second pass only looks at the first n errors. Benefit: Correct code is on the fast path, but error reporting doesn't add too much of an overhead. My experience when using the compiler to have a conversation about errors was that I was correcting one or two errors at a time, then re-compiling. I discarded all the extra information about the other errors anyway, at least most of the time. I don't know if that is a usual pattern, but if it is we might as well exploit it. This idea could already benefit from a separation, but we can go further. What if, in interactive sessions, you would only get the result of the first pass at first. No details, but only a list of error positions. In some cases, that is all you need to find a dumb typo. It also doesn't clutter the screen with loads of fluff while still giving you a basic idea of how much is wrong. Now what if you could then instruct the system to do the second pass at places you choose, interactively? In other words the conversation would be even more conversational. Of course the benefits are debatable and this is not something that's going to be happening soon anyway. But for me the idea alone is an argument for the proposed new separation, because it would give us the flexibility to think of features like this. Cheers, MarLinn From mail at joachim-breitner.de Wed Nov 30 14:02:12 2016 From: mail at joachim-breitner.de (Joachim Breitner) Date: Wed, 30 Nov 2016 09:02:12 -0500 Subject: Separating typechecking and type error reporting in two passes? In-Reply-To: <13bbd92a-612c-83b6-af8f-c421203c116a@gmail.com> References: <1480436419.27881.15.camel@joachim-breitner.de> <1480438351.27881.17.camel@joachim-breitner.de> <13bbd92a-612c-83b6-af8f-c421203c116a@gmail.com> Message-ID: <1480514532.12505.1.camel@joachim-breitner.de> Hi, Am Mittwoch, den 30.11.2016, 12:59 +0100 schrieb MarLinn via ghc-devs: > > But you are right that when the programmer sits there and waits for a > > result, that’s when snappyness is important. > > I had a random idea based on this observation: please allow me to re-iterate that my proposal is *not* about performance, but about being able to detect and report typical error patterns such as confusing the order of arguments to a function, or to leave out one argument. (Wouldn’t that be great?) I regret pointing out hypothetical and likely insignificant performance effects; it derails the discussion. Your ideas (printing less errors, or less details, at first until asked) can be pursued already now. There is precedent, e.g. https://ghc.haskell.org/trac/ghc/ticket/10848 which added the -freverse-errors option. Options in similar vain (-fone-line-errors, -fnum-errors=1) are worth considering and can be implemented today, so if you feel like it, do explain your ideas in greater detail. Greetings, Joachim -- Joachim “nomeata” Breitner   mail at joachim-breitner.de • https://www.joachim-breitner.de/   XMPP: nomeata at joachim-breitner.de • OpenPGP-Key: 0xF0FBF51F   Debian Developer: nomeata at debian.org -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 833 bytes Desc: This is a digitally signed message part URL: From ben at well-typed.com Wed Nov 30 19:46:37 2016 From: ben at well-typed.com (Ben Gamari) Date: Wed, 30 Nov 2016 14:46:37 -0500 Subject: Testsuite and Python 3 Message-ID: <87y400sqci.fsf@ben-laptop.smart-cactus.org> Hello everyone, Note that yesterday I flipped the switch in the build system to use the Python 3 interpreter by default when invoking the testsuite driver. The motivation for this is the fact that Python 2.7 is quite buggy on Windows, which resulted in spurious testsuite failures (see #12554). The question remains, however, of how much we care to preserve compatibility with Python 2. From what little I've seen so far I think it would be easier for everyone involved if we just let Python 2 pass into the sunset. Afterall, Python 3 is no less available than 2 at this point. Thoughts? Cheers, - Ben -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 454 bytes Desc: not available URL: From eacameron at gmail.com Wed Nov 30 20:06:22 2016 From: eacameron at gmail.com (Elliot Cameron) Date: Wed, 30 Nov 2016 15:06:22 -0500 Subject: Testsuite and Python 3 In-Reply-To: <87y400sqci.fsf@ben-laptop.smart-cactus.org> References: <87y400sqci.fsf@ben-laptop.smart-cactus.org> Message-ID: The Python community is heavily pushing to get Python 2 out of normal use, so the only reason I can imagine of trying to maintain Python 2 compatibility is if people have written scripts atop GHC's test suites. I sort of doubt that's common. ᐧ On Wed, Nov 30, 2016 at 2:46 PM, Ben Gamari wrote: > Hello everyone, > > Note that yesterday I flipped the switch in the build system to use the > Python 3 interpreter by default when invoking the testsuite driver. The > motivation for this is the fact that Python 2.7 is quite buggy on > Windows, which resulted in spurious testsuite failures (see #12554). > > The question remains, however, of how much we care to preserve > compatibility with Python 2. From what little I've seen so far I think > it would be easier for everyone involved if we just let Python 2 pass > into the sunset. Afterall, Python 3 is no less available than 2 at this > point. Thoughts? > > Cheers, > > - Ben > > _______________________________________________ > ghc-devs mailing list > ghc-devs at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From simonpj at microsoft.com Wed Nov 30 22:50:50 2016 From: simonpj at microsoft.com (Simon Peyton Jones) Date: Wed, 30 Nov 2016 22:50:50 +0000 Subject: Windows build Message-ID: Thanks for all the work you've been doing on the Windows build. As requested by Tamar I removed ghc-tarballs, and reconfigured. Then I built from scratch. I get the following testsuite failures Simon Unexpected failures: ghci/prog003/prog003.run prog003 [bad exit code] (ghci) plugins/plugins05.run plugins05 [exit code non-0] (normal) plugins/plugins01.run plugins01 [bad exit code] (normal) plugins/plugins07.run plugins07 [bad exit code] (normal) plugins/T10420.run T10420 [bad exit code] (normal) plugins/T10294a.run T10294a [bad exit code] (normal) plugins/T11244.run T11244 [bad stderr] (normal) plugins/T12567a.run T12567a [bad exit code] (normal) rts/testmblockalloc.run testmblockalloc [bad exit code] (normal) simplCore/should_compile/T7702.run T7702 [exit code non-0] (normal) Unexpected stat failures: perf/haddock/haddock.compiler.run haddock.compiler [stat not good enough] (normal) Framework failures: ghci/scripts/ghci062.run ghci062 [ghci-ext] ([Errno 17] File exists: '/c/Users/simonpj/AppData/Local/Temp/ghctest-anc5s5mh/test spaces/./ghci/scripts/ghci062.run') plugins/plugins07.run plugins07 [normal] (pre_cmd failed: 2) plugins/T10420.run T10420 [normal] (pre_cmd failed: 2) plugins/T10294a.run T10294a [normal] (pre_cmd failed: 2) plugins/T11244.run T11244 [normal] (pre_cmd failed: 2) th/TH_repPrim.run TH_repPrim [ext-interp] ([Errno 17] File exists: '/c/Users/simonpj/AppData/Local/Temp/ghctest-anc5s5mh/test spaces/./th/TH_repPrim.run') th/TH_repPatSig.run TH_repPatSig [ext-interp] ([Errno 17] File exists: '/c/Users/simonpj/AppData/Local/Temp/ghctest-anc5s5mh/test spaces/./th/TH_repPatSig.run') -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- An embedded message was scrubbed... From: "lonetiger at gmail.com" Subject: Windows toolchain update Date: Wed, 30 Nov 2016 09:01:00 +0000 Size: 11305 URL: From mail at joachim-breitner.de Wed Nov 30 22:56:06 2016 From: mail at joachim-breitner.de (Joachim Breitner) Date: Wed, 30 Nov 2016 17:56:06 -0500 Subject: Separating typechecking and type error reporting in two passes? In-Reply-To: References: <1480436419.27881.15.camel@joachim-breitner.de> Message-ID: <1480546566.12505.13.camel@joachim-breitner.de> Hi, Am Mittwoch, den 30.11.2016, 10:51 +0000 schrieb Simon Peyton Jones via ghc-devs: > I very much doubt that you'll be able to discard the context > information from the type checker. Maybe some of it.   I can't say > exactly why, it's a gut feel for now. the gut feeling is warranted: There are quite a few errors that are raised directly by the type checker, and not expressed as a WantedConstraint that can be deferred. Kind errors inside types, for example. It might be an interesting exercise to try to make all errors deferrable somehow. With some additions to the relevant types (HsType etc.) this might work. But until then, a second pass would have to *duplicate* all the context-handling machinery, and that is surely not the way to go. Punting this for now, for want of a better idea. Greetings, Joachim -- Joachim “nomeata” Breitner   mail at joachim-breitner.de • https://www.joachim-breitner.de/   XMPP: nomeata at joachim-breitner.de • OpenPGP-Key: 0xF0FBF51F   Debian Developer: nomeata at debian.org -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 833 bytes Desc: This is a digitally signed message part URL: From lonetiger at gmail.com Wed Nov 30 23:07:56 2016 From: lonetiger at gmail.com (lonetiger at gmail.com) Date: Wed, 30 Nov 2016 23:07:56 +0000 Subject: Windows build In-Reply-To: References: Message-ID: <583f5bcc.0f341c0a.dc613.bffb@mx.google.com> Hi Simon, For the tests what Ben’s email forgot to say was that the build system doesn’t pick up on changes to Timeout. So you’d need to nuke it to get the fixes for timing related things: rm -rf testsuite/timeout/dist && rm -rf testsuite/timeout/install-inplace And rerun the tests should fix a few including prog003. For the plugin ones we reverted the commit that caused the failures. I’m currently working on fixing the hsc2hs ones you might see pop up every now and again. The haddock one is new as well, Don’t know what caused it. If you can nuke timeout and rebase to head you should only have the haddock one left. Also we’ve nuked support for python 2. If you’re up to date with master then we only accept python 3 so that should be alright. If you still have these failures (particularly the framework failures ones) could you possibly send me the errors printed on stderr? The errors are hard to reproduce on all machines so logs help a lot. Thanks, Tamar From: Simon Peyton Jones via ghc-devs Sent: Wednesday, November 30, 2016 22:50 To: ghc-devs at haskell.org Subject: Windows build Thanks for all the work you’ve been doing on the Windows build. As requested by Tamar I removed ghc-tarballs, and reconfigured. Then I built from scratch. I get the following testsuite failures Simon Unexpected failures:    ghci/prog003/prog003.run            prog003 [bad exit code] (ghci)    plugins/plugins05.run               plugins05 [exit code non-0] (normal)    plugins/plugins01.run               plugins01 [bad exit code] (normal)    plugins/plugins07.run               plugins07 [bad exit code] (normal)    plugins/T10420.run                  T10420 [bad exit code] (normal)    plugins/T10294a.run                 T10294a [bad exit code] (normal)    plugins/T11244.run                  T11244 [bad stderr] (normal)    plugins/T12567a.run                 T12567a [bad exit code] (normal)    rts/testmblockalloc.run             testmblockalloc [bad exit code] (normal)   simplCore/should_compile/T7702.run  T7702 [exit code non-0] (normal) Unexpected stat failures:    perf/haddock/haddock.compiler.run  haddock.compiler [stat not good enough] (normal) Framework failures:    ghci/scripts/ghci062.run  ghci062 [ghci-ext] ([Errno 17] File exists: '/c/Users/simonpj/AppData/Local/Temp/ghctest-anc5s5mh/test   spaces/./ghci/scripts/ghci062.run')    plugins/plugins07.run     plugins07 [normal] (pre_cmd failed: 2)    plugins/T10420.run        T10420 [normal] (pre_cmd failed: 2)    plugins/T10294a.run       T10294a [normal] (pre_cmd failed: 2)    plugins/T11244.run        T11244 [normal] (pre_cmd failed: 2)    th/TH_repPrim.run         TH_repPrim [ext-interp] ([Errno 17] File exists: '/c/Users/simonpj/AppData/Local/Temp/ghctest-anc5s5mh/test   spaces/./th/TH_repPrim.run')    th/TH_repPatSig.run       TH_repPatSig [ext-interp] ([Errno 17] File exists: '/c/Users/simonpj/AppData/Local/Temp/ghctest-anc5s5mh/test   spaces/./th/TH_repPatSig.run') -------------- next part -------------- An HTML attachment was scrubbed... URL: