November 2014 - ghc-devs

Typechecker plugins: request for review and another workflow question
by Iavor Diatchki 18 Nov '14

18 Nov '14

Hello, I just finished merging HEAD into the branch implementing constraint solver plugins (`wip/tc-plugins`), so things should be fully up to date. For ease of review, I squashed everything into a single commit: https://github.com/ghc/ghc/commit/31729d092c813edc4ef5682db2ee18b33aea6911 could interested folks (I know of SimonPJ, Richard, and Adam) have a look and let me know if things look reasonable? On a related note: I know that we are using phabricator for code review, but I don't know how to use it yet, so please let me know if I can do something to make the review easier. -Iavor

7 25

Re: [commit: ghc] master: Fix a bug introduced with allocation counters (2a6f193)
by Joachim Breitner 17 Nov '14

17 Nov '14

Hi Simon, Am Montag, den 17.11.2014, 13:13 +0000 schrieb git(a)git.haskell.org: > commit 2a6f193bb82f88e8dcb919ee7affc13feae56e98 > Author: Simon Marlow <marlowsd(a)gmail.com> > Date: Mon Nov 17 13:03:56 2014 +0000 > > Fix a bug introduced with allocation counters I think you forgot to add a file: =====> ffi023(normal) 3093 of 4195 [0, 0, 0] cd ./ffi/should_run && '/home/travis/build/ghc/ghc/inplace/bin/ghc-stage2' -fforce-recomp -dcore-lint -dcmm-lint -dno-debug-output -no-user-package-db -rtsopts -fno-warn-tabs -fno-ghci-history -o ffi023 ffi023.hs ffi023_c.c >ffi023.comp.stderr 2>&1 Compile failed (status 256) errors were: ffi023_c.c:1:25: fatal error: ffi023_stub.h: No such file or directory compilation terminated. *** unexpected failure for ffi023(normal) Greetings, Joachim -- Joachim “nomeata” Breitner mail(a)joachim-breitner.de • http://www.joachim-breitner.de/ Jabber: nomeata(a)joachim-breitner.de • GPG-Key: 0xF0FBF51F Debian Developer: nomeata(a)debian.org

1 0

Can't compile GHC-7.8.3 from git, fails on haskell98 library
by Dr. ERDI Gergo 17 Nov '14

17 Nov '14

Hi, On a completely clean clone, I've checked out the tag ghc-7.8.3-release, ran sync-all get, boot, and configure, but the build fails on haskell98. Any ideas what I could be doing wrong? Thanks, Gergo "inplace/bin/ghc-cabal" check libraries/haskell98 "inplace/bin/ghc-cabal" configure libraries/haskell98 dist-install "" --with-ghc="/home/cactus/prog/haskell/ghc/ghc-7.8-build/inplace/bin/ghc-stage1" --with-ghc-pkg="/home/cactus/prog/haskell/ghc/ghc-7.8-build/inplace/bin/ghc-pkg" --disable-library-for-ghci --enable-library-vanilla --disable-library-profiling --enable-shared --with-hscolour="/home/cactus/.cabal/bin/HsColour" --configure-option=CFLAGS=" -fno-stack-protector " --configure-option=LDFLAGS=" " --configure-option=CPPFLAGS=" " --gcc-options=" -fno-stack-protector " --with-gcc="/usr/bin/gcc" --with-ld="/usr/bin/ld" --configure-option=--with-cc="/usr/bin/gcc" --with-ar="/usr/bin/ar" --with-ranlib="/usr/bin/ranlib" --with-alex="/home/cactus/.cabal/bin/alex" --with-happy="/home/cactus/.cabal/bin/happy" Configuring haskell98-2.0.0.4... ghc-cabal: At least the following dependencies are missing: base ==4.8.* make[1]: *** [libraries/haskell98/dist-install/package-data.mk] Error 1

4 8

Windows breakage
by Simon Peyton Jones 14 Nov '14

14 Nov '14

This breakage didn't use to happen. Might someone fix it? Thanks. For now I'm going through changing a dozen "Trustworthy" to "Safe". Is that right? Simon librariesWin32SystemWin32Console.hsc:2:14: Warning: 'System.Win32.Console' is marked as Trustworthy but has been inferred as safe! <no location info>: Failing due to -Werror. libraries/Win32/ghc.mk:4: recipe for target 'libraries/Win32/dist-install/build/System/Win32/Console.o' failed

1 0

Re: More flexible literate Haskell extensions (Trac #9789), summary on wiki
by Simon Hengel 14 Nov '14

14 Nov '14

On Fri, Nov 14, 2014 at 03:53:13PM +0800, Simon Hengel wrote: > > Can you explain why this would not solve your usecase? i.e., why would > > README.lhs.md not suffice? > > I haven't tried, but my assumption was that this is not picked up by > GitHub. I just verified, GitHub dose not pick up README.lhs.md files as READMEs, meaning that a README.lhs.md file will not be rendered as a projects README file on GitHub. Cheers, Simon

1 0

Trac down?
by Richard Eisenberg 13 Nov '14

13 Nov '14

Is it me, or is Trac taking the afternoon off? I haven't been able to access it for the last two hours or so. Thanks, Richard

2 2

Travis validation on a GHC fork?
by Richard Eisenberg 13 Nov '14

13 Nov '14

Hi Joachim, I just tried to use Travis for validation on my fork of GHC, to avoid sending out emails associated with a wip/... commit. But, Travis couldn't find the submodules. Here's the tail of my log: > Submodule 'libraries/vector' (git://github.com/goldfirere/packages/vector.git) registered for path 'libraries/vector' > Submodule 'libraries/xhtml' (git://github.com/goldfirere/packages/xhtml.git) registered for path 'libraries/xhtml' > Submodule 'nofib' (git://github.com/goldfirere/nofib.git) registered for path 'nofib' > Submodule 'utils/haddock' (git://github.com/goldfirere/haddock.git) registered for path 'utils/haddock' > Submodule 'utils/hsc2hs' (git://github.com/goldfirere/hsc2hs.git) registered for path 'utils/hsc2hs' > Cloning into 'libffi-tarballs'... > fatal: remote error: > Repository not found. > Clone of 'git://github.com/goldfirere/libffi-tarballs.git' into submodule path 'libffi-tarballs' failed > The command "git submodule update --init --recursive" failed and exited with 1 during . > Your build has been stopped. I could probably figure out the right commands to fix this, but then my local .travis.yml would be different than the proper one, and that can cause various headaches down the road. Any advice? Thanks, Richard

2 2

RFC: Dropping Windows XP support
by Austin Seipp 13 Nov '14

13 Nov '14

Hi all, This is a quick discussion about the current system requirements for Windows builds. Spurred by a recent[1] LLVM discussion, I'd like to raise the question of dropping support for Windows XP, and bumping the minimum required version to Windows Vista or even Windows 7. For one, Microsoft doesn't support XP anymore, so most people are moving off it anyway. 'Soon' even XP Embedded will be obsoleted. But second, Vista and beyond introduced useful new APIs we could use. I was digging through the LLVM thread and two came out to me: 1) We could switch to using slim reader/writer locks, which in some workloads may work out better than critical sections (they'll win on more read-heavy workloads). The downsides is there's no recursive locking but we don't use that anyway (and recursive locks are considered bad by many anyway[2]). 2) We could probably use an actual condition variables API that was introduced with Vista. Currently we use a giant EVENT object to emulate the API, which could be replaced with the real deal. Both of these could be nice wins for simplicity and performance I think. I know there are some corporate users out there who this may impact, and users as well. I'd like to know what people think. Particularly what version we should standardize on. FWIW, I don't plan on changing any of this until the 7.12 release at least. [1] http://article.gmane.org/gmane.comp.compilers.llvm.devel/78419 [2] http://www.zaval.org/resources/library/butenhof1.html -- Regards, Austin Seipp, Haskell Consultant Well-Typed LLP, http://www.well-typed.com/

4 3

Error handling in the renamer
by Jan Stolarek 13 Nov '14

13 Nov '14

I'm improving my patch for injective type families and I have a question about error handling in the renamer. If I write this incorrect definition: type family F a b = r | r -> c I get these errors: T6018rnfail.hs:36:1: Not in scope: type variable ‘c’ T6018rnfail.hs:36:26: Unexpected type variable on the RHS of injectivity condition: ‘c’ All variables should be bound in type family head and appear at most once in exactly the same order as they were bound. I don't want to report two errors here, just the first one. This means I have to first run the renaming using RnTypes.rnTyVar and check if it reports errors. If it does I don't report the extra error. The question is how do I check if this piece of code returns errors: injFrom' <- rnTyVar True injFrom injTo' <- mapM (rnTyVar True) injTo I found some combinators in TcRnMonad (tryTc and friends) but I don't know how to use them. Ideally I'd want `TcRn a -> TcRn (Messages, a)` + isEmptyMessages but the existing combinators return `TcRn a -> TcRn (Messages, Maybe a)`. I'm not at all happy with getting Nothing - even if renaming fails my function has to return a result. Jan

1 0

TIL about arc diff
by Alan & Kim Zimmerman 12 Nov '14

12 Nov '14

I find if I get a timeout on upload at the end, it is time to rebase against master. Alan

1 0