March 2015 - ghc-devs

Bootstrapping 7.8 using 7.10
by Yitzchak Gale 18 Mar '15

18 Mar '15

Moving here from Reddit, as suggested by Herbert. This a continuation of a thread that started with Edward Yang's post here: http://mail.haskell.org/pipermail/glasgow-haskell-users/2014-October/025389… continued here, a few months later: http://mail.haskell.org/pipermail/glasgow-haskell-users/2014-December/02552… and ended here, in the following month: http://mail.haskell.org/pipermail/glasgow-haskell-users/2015-January/025551… Herbert Valerio Riedel wrote on Reddit (http://www.reddit.com/r/haskell/comments/2zc2jg/ghc_7101_rc3_is_out_test_it…) > I think I remember what the problem was with your patch (and why it > wasn't picked up rightaway): you needed tweaks to boot packages such > as transformers would cause the GHC source-tarball to diverge from > the officially released upstream packages. One solution would be to > rather provide an out-of-tree patch a user can apply manually, > rather than making an official GHC 7.8.5 release with unofficial > modifications to upstream packages (which would also require some > administration overhead on the Git level as upstream packages are > automatically mirrored Git submodules). I think Edward's last post (in January, linked above) addressed those concerns. In summary: release upstream point releases for hpc and hoopl that only bump the dependencies of base and time, and provide instance Applicative IO in the GHC sources for 7.8.5 so that no change is needed for transformers. Will that work? Can we go with this? Thanks, Yitz

2 2

HEAD not buildable by 7.10.1 RC3?
by Karel Gardas 18 Mar '15

18 Mar '15

Hi, for a few last days I'm not able to build amd64/solaris11 build of HEAD using 7.10.1. I've been using RC1 for this, then post RC2 and now RC3 and the issue is still the same: ld: fatal: library -lHSghc-7.11.20150318-5E218FiotzLAN97RtaMkIl: not found ld: fatal: file processing errors. No output written to ghc/stage1/build/tmp/ghc-stage1 collect2: ld returned 1 exit status gmake[1]: *** [ghc/stage1/build/tmp/ghc-stage1] Error 1 gmake: *** [all] Error 2 the problem is that the library which is created is named: libHSghc-7.11-5E218FiotzLAN97RtaMkIl.a and so <year><month><day> is missing there, hence linking fails. I assume this may be caused by the patch below, but I'm not sure so if I'm mistaken here I'm sorry for this Edward. Anyway, I would like to raise this concern since we're already in RC3 for 7.10.1 and if something needs to be changed there, it would be better to do that rather sooner IMHO. Although this is issue on Solaris I assume it to be same on Linux, except that we probably don't have user/buildbot building HEAD with not yet release 7.10.1 and so we do not have this reported. Solaris11/amd64 is kind of special here, since the support for this platform is new in 7.10.1 and so I need to use this unreleased compiler. For compilation log please have a look into amd64/solaris11 buildbot output: http://haskell.inf.elte.hu/builders/solaris-amd64-head/232/10.html -- this is still using post-RC2 as a bootstrap compiler, but the issue with RC3 is the same. Thanks! Karel commit 838d8044896b6544d8c80c2ab5de63d97220f06c Author: Edward Z. Yang <ezyang(a)cs.stanford.edu> Date: Wed Mar 11 14:53:17 2015 +0100 Update Cabal submodule to latest 1.22 snapshot This changes the library file name format NOTE: This patch originally updated to Cabal HEAD, but was reduced to update to Cabal 1.22 HEAD by hvr as this is needed in order to update the filepath submodule to version 1.4.0, and subsequently to be cherry-picked into the ghc-7.10 branch Signed-off-by: Edward Z. Yang <ezyang(a)cs.stanford.edu> Reviewed By: austin Differential Revision: https://phabricator.haskell.org/D707

2 1

Minor doc patch for ghc 7.10 + did I submit the patch correctly/follow the process?
by Doug Burke 17 Mar '15

17 Mar '15

I've submitted a small patch for 7.10.1 to the docs, to re-arrange the order of the "important changes", since - as a "casual" user, things like the AMP/BPP seem like they should be mentioned first, before changes labelled as experimental. The change is at https://phabricator.haskell.org/D736 I'm sending this email to a) make sure this change gets seen b) ask if I did this the right way; I'm happy to write this up as an addendum to the newcomers guide/something else on the wiki if it is a sensible path for a doc-only patch I followed a combination of the phabricator intro [1] and newcomers guide [2] but 1) I did not create a ticket; should I have done so? The existing documentation assumes that you are fixing a bug. It's not clearto me if "RFE to the docs" should be treated the same way 2) since the master branch doesn't contain the 7.10 doc file, and the newcomer guide assumes you are working from the master branch, I did # downloading the submodules seems excessive for a doc-only patch % git config --global url."git://github.com/ghc/packages-".insteadOf git:// github.com/ghc/packages/ % git clone --recursive git://github.com/ghc/ghc % cd git % arc install-certificate ... enter in the token as requested % git checkout ghc-7.10 # as I'm on a very slow download link the repository needed to be updated, so % git fetch origin % git pull origin ghc-7.10 # since some of these were in need of updating and 'arc diff' complained % git submodule update ... edit docs/users_guide/7.10.1-notes.xml # just to check I didn't make any obvious snafus % xmllint 7.10.1-notes.xml % git diff % git add 7.10.1-notes.xml % git commit -m '...' # finally get to arc; the first time I tried it complained about a missing "branch" # so I guessed it made sense to use the branch I had started with, rather than the # suggested one (which I think was master) % arc diff ghc-7.10 ... edit the file and guess at what to put in for reviewers (which I just left as blank and fortunately it looks like it defaults to something sensible). Which is a rather heavy weight process when all I wanted to do was re-organize several paragraphs of a text file! Note that I was lazy and didn't try building ghc since it really is a simple doc change and I didn't want to go and spend even more time working out what I needed to build ghc documentation. Doug [1] https://ghc.haskell.org/trac/ghc/wiki/Phabricator [2] https://ghc.haskell.org/trac/ghc/wiki/Newcomers

3 3

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 15 Mar '15

15 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 11 Mar '15

11 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