- ghc-devs - Haskell.org

Extracting kind variables from LHsTyVarBndr
by Jan Stolarek 19 Mar '15

19 Mar '15

forall hi, is there a function somewhere in the source code that extracts kind variable names from LHsTyVarBndr? I couldn't find anything. Writing one seems a bit scary given the fact that not all fields in HsType constructors are obvious to me. Janek --- Politechnika Łódzka Lodz University of Technology Treść tej wiadomości zawiera informacje przeznaczone tylko dla adresata. Jeżeli nie jesteście Państwo jej adresatem, bądź otrzymaliście ją przez pomyłkę prosimy o powiadomienie o tym nadawcy oraz trwałe jej usunięcie. This email contains information intended solely for the use of the individual to whom it is addressed. If you are not the intended recipient or if you have received this message in error, please notify the sender and delete it from your system.

2 1

RE: [Diffusion] [Committed] rHADDOCK4bb685bd0f57: Track changes in HsSyn for quasi-quotes
by Simon Peyton Jones 19 Mar '15

19 Mar '15

Austin I'm puzzled about this. This relates to something I did ages ago, and I thought was fully committed. I didn't intend to commit anything yesterday. Something mysterious. I hope I have not messed up. Simon | -----Original Message----- | From: noreply(a)phabricator.haskell.org | [mailto:noreply@phabricator.haskell.org] | Sent: 19 March 2015 00:13 | To: Simon Peyton Jones | Subject: [Diffusion] [Committed] rHADDOCK4bb685bd0f57: Track changes in | HsSyn for quasi-quotes | | simonpj committed rHADDOCK4bb685bd0f57: Track changes in HsSyn for | quasi-quotes (authored by simonpj). | | Track changes in HsSyn for quasi-quotes | | | AFFECTED FILES | /haddock-api/src/Haddock/Backends/LaTeX.hs | /haddock-api/src/Haddock/Backends/Xhtml/Decl.hs | /haddock-api/src/Haddock/Interface/Rename.hs | | USERS | simonpj (Author) | | COMMIT | https://phabricator.haskell.org/rHADDOCK4bb685bd0f57 | | REPLY HANDLER ACTIONS | Reply to comment. | | EMAIL PREFERENCES | https://phabricator.haskell.org/settings/panel/emailpreferences/ | | To: simonpj

2 1

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

18 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 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