- ghc-devs - Haskell.org

build fail with latest 8.1 sources
by John Leo 13 Nov '16

13 Nov '16

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.

3 5

Windows build broken -- again
by Simon Peyton Jones 13 Nov '16

13 Nov '16

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$

3 2

GHC pretty printer philosophy
by Alan & Kim Zimmerman 13 Nov '16

13 Nov '16

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

2 2

data families syntax
by Harendra Kumar 13 Nov '16

13 Nov '16

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

1 1

New home for the perf.haskell.org builder wanted
by Joachim Breitner 12 Nov '16

12 Nov '16

Hi, 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 -- Joachim “nomeata” Breitner mail(a)joachim-breitner.de • https://www.joachim-breitner.de/ XMPP: nomeata(a)joachim-breitner.de • OpenPGP-Key: 0xF0FBF51F Debian Developer: nomeata(a)debian.org

3 5

177 unexpected test failures on a new system -- is this yet another linker issue?
by Ömer Sinan Ağacan 12 Nov '16

12 Nov '16

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:<line>:<column> in <package-id>: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?

4 8

Breakage due to CallStack refactoring
by Ben Gamari 11 Nov '16

11 Nov '16

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

2 1

install pandoc with cabal update
by CRUMEYROLLE Pierre 10 Nov '16

10 Nov '16

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

1 0

ppr of HsDo
by Alan & Kim Zimmerman 10 Nov '16

10 Nov '16

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

2 5

D2638: Reviewers Needed
by Thomas Jakway 06 Nov '16

06 Nov '16

My first patch to GHC <https://phabricator.haskell.org/D2638> is on Phab and Matthew Pickering suggested I get someone knowledgeable about the register allocator to review it. I checked the Code Owners page <https://ghc.haskell.org/trac/ghc/wiki/CodeOwners> 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

1 0