- ghc-devs - Haskell.org

Testsuite broken on windows
by Simon Peyton Jones 17 Mar '15

17 Mar '15

Thomas AAAARGH! Windows build is broken again. Could you please fix? Soon! I got going again by reverting the last four commits to testsuite/, but there's some complication with the hpc submodule so I couldn't do it mechanically. Better to fix it properly Thanks Simon python ../driver/runtests.py -e ghc_compiler_always_flags="'-fforce-recomp -dcore-lint -dcmm-lint -dno-debug-output -no-user-package-db -rtsopts -fno-warn-tabs'" -e ghc_debugged=False -e ghc_with_native_codegen=1 -e ghc_with_vanilla=1 -e ghc_with_dynamic=0 -e ghc_with_profiling=0 -e ghc_with_threaded_rts=1 -e ghc_with_dynamic_rts=0 -e ghc_with_interpreter=1 -e ghc_unregisterised=0 -e ghc_dynamic_by_default=False -e ghc_dynamic=False -e ghc_with_smp=1 -e ghc_with_llvm=0 -e windows=True -e darwin=False -e in_tree_compiler=True --threads=5 --verbose=3 -e clean_only=False --rootdir=. --config=../config/ghc -e 'config.confdir="../config"' -e 'config.platform="i386-unknown-mingw32"' -e 'config.os="mingw32"' -e 'config.arch="i386"' -e 'config.wordsize="32"' -e 'default_testopts.cleanup="1"' -e 'config.timeout=int() or config.timeout' -e 'config.exeext=".exe"' -e 'config.top="C:/code/HEAD/testsuite"' -e 'config.compiler="\"C:/code/HEAD/inplace/bin/ghc-stage2.exe\""' -e 'config.ghc_pkg="\"C:/code/HEAD/inplace/bin/ghc-pkg.exe\""' -e 'config.hp2ps="\"C:/code/HEAD/inplace/bin/hp2ps.exe\""' -e 'config.hpc="\"C:/code/HEAD/inplace/bin/hpc.exe\""' -e 'config.gs="\"gs\""' -e 'config.timeout_prog="\"../timeout/install-inplace/bin/timeout.exe\""' --output-summary "../../testsuite_summary.txt" --rootdir=../../libraries/Win32/tests --rootdir=../../libraries/array/tests --rootdir=../../libraries/base/tests --rootdir=../../libraries/binary/tests --rootdir=../../libraries/bytestring/tests --rootdir=../../libraries/containers/tests --rootdir=../../libraries/deepseq/tests --rootdir=../../libraries/directory/tests --rootdir=../../libraries/filepath/tests --rootdir=../../libraries/ghc-prim/tests --rootdir=../../libraries/haskeline/tests --rootdir=../../libraries/hpc/tests --rootdir=../../libraries/parallel/tests --rootdir=../../libraries/pretty/tests --rootdir=../../libraries/process/tests --rootdir=../../libraries/stm/tests --rootdir=../../libraries/template-haskell/tests --rootdir=../../libraries/containers/tests-ghc \ \ \ \ \ \ -e config.fast=1 \ Warning: Ignoring request to use threads as running on Windows Traceback (most recent call last): File "../driver/runtests.py", line 205, in <module> pkginfo = getStdout([config.ghc_pkg, 'dump']) File "C:\code\HEAD\testsuite\driver\testlib.py", line 2277, in getStdout p = subprocess.Popen(strip_quotes(cmd), File "C:\code\HEAD\testsuite\driver\testutil.py", line 20, in strip_quotes return s.strip('\'"') AttributeError: 'list' object has no attribute 'strip' ../mk/test.mk:261: recipe for target 'test' failed make[2]: *** [test] Error 1 make[2]: Leaving directory '/cygdrive/c/code/HEAD/testsuite/tests' ../mk/test.mk:276: recipe for target 'fast' failed make[1]: *** [fast] Error 2 make[1]: Leaving directory '/cygdrive/c/code/HEAD/testsuite/tests' Makefile:117: recipe for target 'fasttest' failed make: *** [fasttest] Error 2

2 2

MAC builds of 7.8.4 and 7.10.1 RC2
by Mark Lentczner 16 Mar '15

16 Mar '15

I have built "in the official manner" both GHC 7.8.4 and GHC 7.10.1 rc2 from sources. You can find them here: http://www.ozonehouse.com/mark/platform/ They need some "doesn't crash out of the box" testing on a few OS X systems before I think we should declare them good and put them on the download page. Can you help out? Basic instructions to install a bindist in a local, isolated area (so you don't clobber your system GHC installation): mkdir test-ghc cd test-ghc tar xf $binddist_tar_file cd ghc* configure --prefix=`cd ..; pwd` make install cd .. Let me know if that works - and what version of OS X you used. - Mark

7 8

More at-use-site extension pragmas please
by David Feuer 16 Mar '15

16 Mar '15

For people working on libraries intended to be portable but using/offering GHC specials when compiled with GHC, it's nice to be able to verify quickly that nothing relies on a GHC extension that shouldn't. For example, I just submitted a pull request to add an IsString instance to Data.Sequence: instance IsString (Seq Char) where fromString = fromList This instance requires FlexibleInstances to compile. Since that option is global, GHC will no longer complain about non-standard instance heads *anywhere* in the (large) module. The obvious long-term solution, I believe, is to add {-# FlexibleInstance #-} (and {-# FlexibleContext #-}) pragmas. Well, that or get some sort of termination checker into Haskell 2015! David

1 0

GHC 7.8.4 for Windows 32bit
by Neil Mitchell 13 Mar '15

13 Mar '15

Hi, GHC 7.8.4 was released a little while ago, but there still isn't a Windows 32bit version available. With my "MinGHC maintainer" hat on we're getting quite a lot of requests for a 32bit 7.8.4 version. With my "using Haskell commercially" hat on the lack of a 32bit build is causing delays to infrastructure upgrades. Any timeline for a 32bit Windows build? Anything you're stuck on? Going forward, it seems the 32bit Windows version remains popular, so if all releases and release candidates came with such a version it would be great. I note there wasn't (and still might not be) a 7.10 RC, and as a result I've only tested my packages on Linux. Thanks, Neil

4 3

Testsuite broken on builders.
by Karel Gardas 13 Mar '15

13 Mar '15

Hello, we do have builders[1] broken for about 2-3 days now due to an issue in testsuite[2]. It shows as: Traceback (most recent call last): File "../driver/runtests.py", line 200, in <module> "gs" -dNODISPLAY -dBATCH -dQUIET -dNOPAUSE ../config/good.ps from testlib import * File "/buildbot/gabor-ghc-head-builder/builder/tempbuild/build/testsuite/driver/testlib.py", line 2058, in <module> resultGood = runCmdExitCode(genGSCmd(config.confdir + '/good.ps')); File "/buildbot/gabor-ghc-head-builder/builder/tempbuild/build/testsuite/driver/testlib.py", line 1870, in runCmdExitCode return (runCmd(cmd) >> 8); File "/buildbot/gabor-ghc-head-builder/builder/tempbuild/build/testsuite/driver/testlib.py", line 1838, in runCmd r = rawSystemWithTimeout([config.timeout_prog, str(config.timeout), cmd]) File "/buildbot/gabor-ghc-head-builder/builder/tempbuild/build/testsuite/driver/testlib.py", line 1813, in rawSystemWithTimeout r = rawSystem(cmd_and_args) File "/buildbot/gabor-ghc-head-builder/builder/tempbuild/build/testsuite/driver/testlib.py", line 1790, in rawSystem return subprocess.call([strip_quotes(cmd)] + cmd_and_args[1:]) NameError: global name 'strip_quotes' is not defined gmake[1]: *** [test] Error 1 gmake[1]: Leaving directory `/buildbot/gabor-ghc-head-builder/builder/tempbuild/build/testsuite/tests' gmake: *** [test] Error 2 Following git log you were two developers dealing with testsuite recently. Perhaps you've broken the thing? Do you think you find some time to fix that? Thanks a lot! Karel [1]: http://haskell.inf.elte.hu/builders/ [2]: http://haskell.inf.elte.hu/builders/solaris-x86-head/342/21.html

2 2

GHC 7.10 Regression(?) regarding Unicode subscript characters in identifiers
by Herbert Valerio Riedel 12 Mar '15

12 Mar '15

Hello *, The comment https://ghc.haskell.org/trac/ghc/ticket/5108#comment:16 made me aware the Unicode7 update in GHC 7.10 had the side effect of breaking code making use of subscript symbols that did compile with GHC 7.8.4, but won't anymore with GHC 7.10.1: For instance, GHCi 7.8.4 accepts let xᵦ = 1 let xᵤ = 1 let xᵩ = 1 let xᵢ = 1 let xᵪ = 1 let xᵣ = 1 let xₙ = 1 whereas GHC 7.10.1RC fails parsing those with a lexical error. (NB: GHC 7.8 does not accept *all* latin subscript letters either). I wanted to raise attention to this, as this IMO deserves (at the very least) some release-note entry, or alternatively (if this is considered a regression) some workaround in the lexer to restore backward compatibility... Cheers, hvr

1 0

tyConHash -- quick fix?
by Simon Peyton Jones 12 Mar '15

12 Mar '15

data TyCon = TyCon { tyConHash :: {-# UNPACK #-} !Fingerprint, -- ^ @since 4.8.0.0 tyConPackage :: String, -- ^ @since 4.5.0.0 tyConModule :: String, -- ^ @since 4.5.0.0 tyConName :: String -- ^ @since 4.5.0.0 } Friends, Is tyConHash a good name here? Wouldn't tyConFingerprint be better? * Hash functions usually yield a Int. * tyConFingerprint :: TyCon -> Fingerprint makes the name match the type. * If we had fingerprintHash:: Fingerprint -> Int, then we might want tyConHash :: TyCon -> Int tyConHash = fingerprintHash . tyConFingerpring This is new in 7.10, so we could fix it now with no trouble. Simon

4 4

Porting to Haiku
by Jessica Hamilton 11 Mar '15

11 Mar '15

Hi, I (and one other) am working on porting GHC to Haiku; we've successfully got a working GHC cross-compiler running on Haiku, and now are able to also build GHC on Haiku from the cross-compiler when using the "quickest" profile in the mk/build.mk file. However, using the default build profile, we're running into a couple of issues. 1. A random segfault in ghc-stage1 (is probably an issue in Haiku, not entirely sure yet), with the following call stack: runCFinalizers + 0x3a runAllCFinalizers + 0x37 hs_exit_ +0x99 shutdownHaskellAndExit + 0x2f hs_main + 0xb1 .../ghc-7.8.3/inplace/lib/bin/ghc-stage1 + 0xc7b374 _start + 0x4b runtime_loader + 0x130 I can't really see anything obvious in the source code myself (although our debugger fails to enumerate the semaphores, and also needs to be killed). Restarting the build is sufficient to get past the issue, however. 2. A more pressing issue is with ghc-cabal. It fails with the error "resource exhausted" when running the following command: inplace/bin/ghc-cabal copy compiler stage2 This error is reproducible every time. I've tried setting up a profile build in the mk/build.mk file in order to get a stack trace from ghc-cabal; however, after rebuilding GHC from scratch, running ghc-cabal +RTS -xc, it still complains that the flag -xc requires the program to be built with -prof. Some advice would be handy before diving into another couple hours of rebuilding GHC to try and get a profiled build of ghc-cabal out of the build system ;-) Cheers, Jessica

2 1

RE: [commit: ghc] ghc-7.10: fixup T10019 output yet again (9f19723)
by Simon Peyton Jones 10 Mar '15

10 Mar '15

This test keeps wobbling because a unique id shows up in the pretty-printed Template Haskell output. Maybe it's a poorly designed test; or maybe there should be a way of suppressing these uniques. I'm not sure. It'd be great if someone wanted to take a look Simon | -----Original Message----- | From: ghc-commits [mailto:ghc-commits-bounces@haskell.org] On Behalf Of | git(a)git.haskell.org | Sent: 10 March 2015 14:28 | To: ghc-commits(a)haskell.org | Subject: [commit: ghc] ghc-7.10: fixup T10019 output yet again (9f19723) | | Repository : ssh://git@git.haskell.org/ghc | | On branch : ghc-7.10 | Link : | http://ghc.haskell.org/trac/ghc/changeset/9f19723668b5ef012841012406d1ea4 | 2b618fb69/ghc | | >--------------------------------------------------------------- | | commit 9f19723668b5ef012841012406d1ea42b618fb69 | Author: Herbert Valerio Riedel <hvr(a)gnu.org> | Date: Tue Mar 10 15:25:59 2015 +0100 | | fixup T10019 output yet again | | | >--------------------------------------------------------------- | | 9f19723668b5ef012841012406d1ea42b618fb69 | testsuite/tests/th/T10019.stdout | 2 +- | 1 file changed, 1 insertion(+), 1 deletion(-) | | diff --git a/testsuite/tests/th/T10019.stdout | b/testsuite/tests/th/T10019.stdout | index 350338c..6345930 100644 | --- a/testsuite/tests/th/T10019.stdout | +++ b/testsuite/tests/th/T10019.stdout | @@ -1 +1 @@ | -"DataConI Ghci1.Some (ForallT [KindedTV a_1627391549 StarT] [] (AppT | (AppT ArrowT (VarT a_1627391549)) (AppT (ConT Ghci1.Option) (VarT | a_1627391549)))) Ghci1.Option (Fixity 9 InfixL)" | +"DataConI Ghci1.Some (ForallT [KindedTV a_1627391544 StarT] [] (AppT | (AppT ArrowT (VarT a_1627391544)) (AppT (ConT Ghci1.Option) (VarT | a_1627391544)))) Ghci1.Option (Fixity 9 InfixL)" | | _______________________________________________ | ghc-commits mailing list | ghc-commits(a)haskell.org | http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-commits

1 0

RE: [Diffusion] [Build Failed] rGHCb833bc2767d7: User manual section to document the principles of kind inference
by Simon Peyton Jones 10 Mar '15

10 Mar '15

Guys I'm seeing this validate failures on TH_Roles2 -Dependent packages: [array-0.5.0.1, base-4.8.0.0, deepseq-1.4.0.0, +Dependent packages: [array-0.5.0.1, base-4.8.0.0, deepseq-1.4.1.0, And similarly safePkg01 -package dependencies: array-0.5.0.1 base-4.8.0.0 bytestring-0.10.5.0* deepseq-1.4.0.0 ghc-prim-0.3.1.0 integer-gmp-0.5.1.0 +package dependencies: array-0.5.0.1 base-4.8.0.0 bytestring-0.10.6.0* deepseq-1.4.1.0 ghc-prim-0.3.1.0 integer-gmp-1.0. Could someone fix? Do we want tests that depend on version numbers in this fragile way. They are almost bound to fail repeatedly over time. Simon | -----Original Message----- | From: noreply(a)phabricator.haskell.org | [mailto:noreply@phabricator.haskell.org] | Sent: 05 March 2015 23:03 | To: Simon Peyton Jones | Subject: [Diffusion] [Build Failed] rGHCb833bc2767d7: User manual section | to document the principles of kind inference | | Harbormaster failed to build B3285: rGHCb833bc2767d7: User manual section | to document the principles of kind inference! | | USERS | simonpj (Author) | GHC - Documentation (Auditor) | | COMMIT | https://phabricator.haskell.org/rGHCb833bc2767d7 | | REPLY HANDLER ACTIONS | Reply to comment. | | EMAIL PREFERENCES | https://phabricator.haskell.org/settings/panel/emailpreferences/ | | To: simonpj, GHC - Documentation

3 2