- ghc-devs - Haskell.org

example of great getting started guide (possible guide to improve it for ghc)
by Carter Schonwald 20 Nov '13

20 Nov '13

Hey All, I just came across the mozilla firefox "how to get involved in the dev" docs http://codefirefox.com/ and https://news.ycombinator.com/item?id=6753583and https://developer.mozilla.org/en-US/docs/introduction One thing I've been very active on lately is trying to figure out how to talk more people into trying to help out with ghc. And the firefox stuff there seems to lay out a great collection of examples of ways to make it a bit easier / managable to get involved! figured it'd be worth sharing -Carter

4 5

Validate broken on Snow Leopard and Mountain Lion
by Ben Lippmeier 19 Nov '13

19 Nov '13

The Snow Leopard says: ---------------------- Loading package primitive-0.5.1.0 ... linking ... done. Loading package vector-0.10.9.1 ... <command line>: can't load .so/.DLL for: /Users/benl/devel/ghc/ghc-head-validate/libraries/vector/dist-install/build/libHSvector-0.10.9.1-ghc7.7.20131113.dylib (dlopen(/Users/benl/devel/ghc/ghc-head-validate/libraries/vector/dist-install/build/libHSvector-0.10.9.1-ghc7.7.20131113.dylib, 9): Library not loaded: @rpath/primitive-0.5.1.0/libHSprimitive-0.5.1.0-ghc7.7.20131113.dylib Referenced from: /Users/benl/devel/ghc/ghc-head-validate/libraries/vector/dist-install/build/libHSvector-0.10.9.1-ghc7.7.20131113.dylib Reason: image not found) make[1]: *** [libraries/dph/dph-lifted-copy/dist-install/build/Data/Array/Parallel/PArray/PData.o] Error 1 make[1]: *** Waiting for unfinished jobs.... make: *** [all] Error 2 The Mountain Lion says: ----------------------- libraries/primitive/cbits/primitive-memops.c:48:0: warning: dereferencing type-punned pointer will break strict-aliasing rules libraries/primitive/cbits/primitive-memops.c: In function ‘hsprimitive_memset_Float’: libraries/primitive/cbits/primitive-memops.c:49:0: warning: dereferencing type-punned pointer will break strict-aliasing rules libraries/primitive/cbits/primitive-memops.c: In function ‘hsprimitive_memset_Double’: libraries/primitive/cbits/primitive-memops.c:50:0: warning: dereferencing type-punned pointer will break strict-aliasing rules make[1]: *** [libraries/primitive/dist-install/build/cbits/primitive-memops.dyn_o] Error 1 make: *** [all] Error 2 Neither seems pleased. Ben.

6 10

templateHaskellNames
by Richard Eisenberg 19 Nov '13

19 Nov '13

Hi devs, I happened to be looking through the code dealing with known names, and I'm a little confused about templateHaskellNames. In particular, I'm confused why it's included in knownKeyNames only when GHCI is defined. (See lines 196-198 of HscMain.) It's the stage 1 compiler that compiles the TH library, when the known key names are so important. Couldn't this cause very strange behavior if some of the numbers are changed? Or, am I misunderstanding something here? This is certainly a minor problem, but it could give someone down the road a headache if it were to happen. Thanks, Richard

2 1

Re: Building GHC head with clang on Mavericks
by Kazu Yamamoto 19 Nov '13

19 Nov '13

Hi, > btw, is there really no whitespace before the '#' in line 2 ? No space. The line starts with '#'. For testing, I created a valid HS file using CPP and complied it with GHC 7.6.3. A .hscpp file contains: ---- # 1 "a.hs" # 1 "<built-in>" # 1 "<command-line>" # 1 "a.hs" {-# LANGUAGE CPP #-} ---- The line 2 also starts with '#'. Comparing this with the previous one, the difference is '1' in the end of line. ---- # 1 "utils/genprimopcode/dist/build/Lexer.hs" # 1 "<built-in>" 1 # 1 "utils/genprimopcode/dist/build/Lexer.hs" 2 {-# LANGUAGE CPP,MagicHash #-} ---- --Kazu

1 0

tcfail174, T2494 and Simple14 failing
by Joachim Breitner 18 Nov '13

18 Nov '13

Hi, thanks to Duncan for fixing topHandler03. Three new tests are however failing: =====> T2494(normal) 805 of 3821 [0, 0, 0] Actual stderr output differs from expected: --- ./typecheck/should_compile/T2494.stderr 2013-11-15 19:07:53.298771915 +0000 +++ ./typecheck/should_compile/T2494.comp.stderr 2013-11-15 19:41:46.626713597 +0000 @@ -1,10 +1,10 @@ T2494.hs:15:14: - Couldn't match type ‛a’ with ‛b’ - ‛a’ is a rigid type variable bound by - the RULE "foo/foo" at T2494.hs:13:16 + Couldn't match type ‛b’ with ‛a’ ‛b’ is a rigid type variable bound by the RULE "foo/foo" at T2494.hs:14:16 + ‛a’ is a rigid type variable bound by + the RULE "foo/foo" at T2494.hs:13:16 Expected type: Maybe (m a) -> Maybe (m a) Actual type: Maybe (m b) -> Maybe (m b) Relevant bindings include @@ -17,11 +17,11 @@ In the second argument of ‛foo’, namely ‛(foo g x)’ T2494.hs:15:30: - Couldn't match type ‛a’ with ‛b’ - ‛a’ is a rigid type variable bound by - the RULE "foo/foo" at T2494.hs:13:16 + Couldn't match type ‛b’ with ‛a’ ‛b’ is a rigid type variable bound by the RULE "foo/foo" at T2494.hs:14:16 + ‛a’ is a rigid type variable bound by + the RULE "foo/foo" at T2494.hs:13:16 Expected type: Maybe (m a) -> Maybe (m a) Actual type: Maybe (m b) -> Maybe (m b) Relevant bindings include *** unexpected failure for T2494(normal) =====> tcfail174(normal) 1068 of 3821 [0, 1, 0] Actual stderr output differs from expected: --- ./typecheck/should_fail/tcfail174.stderr 2013-11-15 19:07:53.462762490 +0000 +++ ./typecheck/should_fail/tcfail174.comp.stderr 2013-11-15 19:42:10.823320120 +0000 @@ -6,11 +6,11 @@ In the expression: Base id tcfail174.hs:13:14: - Couldn't match type ‛a’ with ‛a1’ - because type variable ‛a1’ would escape its scope - This (rigid, skolem) type variable is bound by - the type forall a2. a2 -> a2 - at tcfail174.hs:13:14 + Couldn't match type ‛a1’ with ‛a’ + ‛a1’ is a rigid type variable bound by + the type forall a2. a2 -> a2 at tcfail174.hs:13:14 + ‛a’ is a rigid type variable bound by + the inferred type of h1 :: Capture a at tcfail174.hs:13:1 Expected type: Capture (forall x. x -> a) Actual type: Capture (forall a. a -> a) Relevant bindings include *** unexpected failure for tcfail174(normal) =====> Simple14(normal) 3306 of 3821 [0, 2, 0] Actual stderr output differs from expected: --- ./indexed-types/should_compile/Simple14.stderr 2013-11-15 19:07:52.465819783 +0000 +++ ./indexed-types/should_compile/Simple14.comp.stderr 2013-11-15 19:48:37.218070046 +0000 @@ -1,8 +1,7 @@ Simple14.hs:17:19: - Couldn't match type ‛z0’ with ‛n’ - ‛z0’ is untouchable - inside the constraints (Maybe m ~ Maybe n) + Could not deduce (n ~ z0) + from the context (Maybe m ~ Maybe n) bound by a type expected by the context: Maybe m ~ Maybe n => EQ_ z0 z0 at Simple14.hs:17:12-33 *** unexpected failure for Simple14(normal) I guess these have been introduced by SPJ’s most recent changes (https://github.com/nomeata/ghc-complete/commit/a8030acfc591f4069c27c9df86a8…) Greetings, Joachim -- Joachim “nomeata” Breitner mail(a)joachim-breitner.de • http://www.joachim-breitner.de/ Jabber: nomeata(a)joachim-breitner.de • GPG-Key: 0x4743206C Debian Developer: nomeata(a)debian.org

2 2

GHC 7.8 release status
by Simon Peyton-Jones 16 Nov '13

16 Nov '13

Friends The 7.8 release is imminent. This email is to ask abou the status of your contributions. In each case could you update the wiki with the current state of play, and your intentions, including dates. That is, don't put your reply in email: it on the status page below; though by all means send email too! Summary here: http://ghc.haskell.org/trac/ghc/wiki/Status/GHC-7.8 Also : What is missing from the list that should be done? · Patrick Palka: status of ghc -make -j? · Nick: status of your three items? · Pedro/Richard: is all the Typeable stuff, and gcast and friends, finished? · Geoff: what about the new Template Haskell story? · Iavor: when do you think you can merge? · Austin: what about ARMv7? · Edsko/Thomas/Luite: if you want anything for 7.8 it'll have to be jolly soon. At the moment I don't even know the motivation or design, let alone implementation. Could you make a wiki page explaining the proposed design? Is it really important to do this for 7.8? · Dynamic GHCi. I have no idea who is driving this, or how important it is. · Ryan: atomic stuff. All merged? · AMP warnings: David Luposchainsky is driving this. Thanks! Simon Microsoft Research Limited (company number 03369488) is registered in England and Wales Registered office is at 21 Station Road, Cambridge, CB1 2FB

7 10

bundle panic
by Simon Peyton-Jones 15 Nov '13

15 Nov '13

Windows build is failing again in a new way. It was fine a couple of days ago. Does this ring any bells? ghc-stage1.exe: panic! (the 'impossible' happened) (GHC version 7.7.20131107 for i386-unknown-mingw32): bundle Simon "inplace/bin/ghc-stage1.exe" -static -H32m -O -Werror -Wall -H64m -O0 -package-name integer-gmp-0.5.1.0 -hide-all-packages -i -ilibraries/integer-gmp/. -ilibraries/integer-gmp/dist-install/build -ilibraries/integer-gmp/dist-install/build/autogen -Ilibraries/integer-gmp/dist-install/build -Ilibraries/integer-gmp/dist-install/build/autogen -Ilibraries/integer-gmp/. -optP-include -optPlibraries/integer-gmp/dist-install/build/autogen/cabal_macros.h -package ghc-prim-0.3.1.0 -Wall -package-name integer-gmp -XHaskell2010 -dcore-lint -no-user-package-db -rtsopts -Ilibraries/integer-gmp/mkGmpDerivedConstants/dist -c libraries/integer-gmp/cbits/gmp-wrappers.cmm -o libraries/integer-gmp/dist-install/build/cbits/gmp-wrappers.o ghc-stage1.exe: panic! (the 'impossible' happened) (GHC version 7.7.20131107 for i386-unknown-mingw32): bundle c8 integer_cmm_importIntegerFromByteArrayzh [(c8, label: block{v c8}_info rep:StackRep [False, True, True, True]), (cg, label: block{v cg}_info rep:StackRep [False, True, True, True])] Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug HEAD (master)$

1 0

Re: Fwd: Any GHC plans to adopt tf-random?
by Michał Pałka 15 Nov '13

15 Nov '13

Hello Ryan and Nicolas, I'm happy to see some interest in the tf-random package. The package has not been extensively tested. I ran it on x86-64 and x86 Linux, and on x86 Windows. It would be good to check if it gives the same results on a big-endian architecture, such as ARM, however I don't have access to such a machine. When it comes to the performance, it is good on x86-64, but significantly slower on x86, and probably on other 32-bit architectures, because the cipher's code is optimised for 64-bit arithmetic. It may be possible to use a 32-bit optimised version for the 32-bit architectures to mitigate that, but that would mean even more C code to review. Another issue is whether to change the RandomGen/Random API, which might be considered at the same time. The current Random instances are slow, suffer from the modulo bias, and work only when the range of numbers returned by the generator is (0, 2147483562). However, I am aware that the disturbance would potentially be much larger if the API is changed, so doing it may need some planning. Ideally, it would be nice if people started using the package and see how it performs in practice before any decisions are made. Best regards, Michał > Begin forwarded message: > > From: Ryan Newton <rrnewton(a)gmail.com> > > Subject: Re: Any GHC plans to adopt tf-random? > > Date: 6 november 2013 22:51:02 CET > > To: Nicolas Frisby <nicolas.frisby(a)gmail.com> > > Cc: "ghc-devs(a)haskell.org" <ghc-devs(a)haskell.org> > > Reply-To: rrnewton(a)gmail.com > > Hi all, > > It looks like since the paper has come out the code has been > > released to Hackage. I personally would love to replace > > System.Random with something like this. > > I think the question of whether it's time comes down to some > > due-diligence issues outside the scope of the paper. This library > > has C code, have people tested it extensively on Mac/Linux/Windows? > > Does it have any performance divots we should know about? (Though > > the performance of the legacy implementation was bad in many > > respects -- it > > is a low bar.) > > -Ryan > > > > > > On Wed, Nov 6, 2013 at 3:12 PM, Nicolas Frisby > > <nicolas.frisby(a)gmail.com> wrote: > > Adding Ryan Newton to the TO field, as the maintainer of > > random. > > > > > > On Wed, Nov 6, 2013 at 2:02 PM, Nicolas Frisby > > <nicolas.frisby(a)gmail.com> wrote: > > Bugs #3575 #3620 have to do with splitting StdGens > > yielding dependent generators. > > > > The Haskell 2013 paper Splittable Pseudorandom > > Number Generators Using Cryptographic Hashing by > > Claessen and Pałka yielded the tf-random package on > > Hackage. > > > > Are there any plans to integrate these corrections > > into System.Random? > > Thanks. > > > > > > _______________________________________________ > > ghc-devs mailing list > > ghc-devs(a)haskell.org > > http://www.haskell.org/mailman/listinfo/ghc-devs > > > >

1 0

topHandler03 failing
by Joachim Breitner 15 Nov '13

15 Nov '13

Hi, I don’t trust the travis setup enough to automatically relay failures, so I do it manually. Since these patches: Changes to ghc: commit 12cdd6d Author: Duncan Coutts <duncan(a)well-typed.com> Date: Thu Nov 14 16:02:03 2013 +0000 Don translate UserInterrupt into ExitFailure 1, let it propagate It is important that if a program recieved ^C from the user, and the program terminates as a result, that it exit with SIGINT so that the parent process knows that was the case. For example cabal calling ghc will then be able to tell the difference between it failing and the user interrupting with ^C and report (or not) appropriately. So we should just let the UserInterrupt exception propagate to the top level error handler which will do the right thing. See http://www.cons.org/cracauer/sigint.html commit a987b80 Author: Duncan Coutts <duncan(a)well-typed.com> Date: Thu Nov 14 15:54:13 2013 +0000 Improve the shutdownHaskellAndSignal and add fast exit This is the RTS part of a patch to base's topHandler to handle exiting by a signal. The intended behaviour is that on Unix, throwing ExitFailure (-sig) results in the process terminating with that signal. Previously shutdownHaskellAndSignal was only used for exiting with SIGINT due to the UserInterrupt exception. Improve shutdownHaskellAndSignal to do the signal part more carefully. In particular, it (should) now reliably terminates the process one way or another. Previusly if the signal was blocked, ignored or handled then shutdownHaskellAndSignal would actually return! Also, the topHandler code has two paths a careful shutdown and a "fast exit" where it does not give finalisers a chance to run. We want to support that mode also when we want to exit by signal. So rather than the base code directly calling stg_exit as it did before, we have a fastExit bool paramater for both shutdownHaskellAnd{Exit,Signal}. Changes to base: commit dd00004 Author: Duncan Coutts <duncan(a)well-typed.com> Date: Thu Nov 14 15:16:30 2013 +0000 Add tests for the top level exception handler The top level exception handler is wrapped around main, and FFI exports. It handles exceptions that are not otherwise caught in user code. For most exception is just prints them, but handles a few specially, including ExitCode and UserInterrupt. On Unix it installs a signal handler for SIGINT to translate it into a UserInterrupt async exception. So we test that: 1. receiving SIGINT does trigger a UserInterrupt async exception 2. an unhandled UserInterrupt makes us kill ourselves with SIGINT 3. an unhandled ExitFailure (-sig) makes us kill ourselves with sig commit 6b22a6e Author: Duncan Coutts <duncan(a)well-typed.com> Date: Thu Nov 14 15:15:31 2013 +0000 Handle ExitFailure (-sig) by killing process with signal On Unix we now use negative exit codes in ExitFailure to indicate that a process exited due to a signal. This patch implements the case for when a ExitFailure exception propagates out of the top of main (and is handled by the topHandler). For a negative ExitFailure code, we try to kill the process using that signal (the details of that are handled by shutdownHaskellAndSignal from the RTS). For an exit code outside the valid ranges, we use 0xff. Changes to process: commit 3ebbe13 Author: Duncan Coutts <duncan(a)well-typed.com> Date: Thu Nov 14 13:59:57 2013 +0000 Change the unix ExitCode encoding again! Now simply -signum So rather than a bitfield encoding, covering normal exit codes, signals and core dumps, we now simply use negative numbers for signal exit codes. We thus do not report core dumps by this mechanism. This encoding is a lot simpler to explain and use. It also happens to be the same encoding as Python's subprocess package uses. Anyone who cares about core dumps can still use the unix package. I get this failure on travis: =====> topHandler03(normal) 3622 of 3821 [0, 0, 0] Actual stderr output differs from expected: --- /dev/null 2013-11-14 17:46:34.724312327 +0000 +++ ../../libraries/base/tests/topHandler03.run.stderr 2013-11-14 18:24:52.367542630 +0000 @@ -0,0 +1 @@ +Terminated *** unexpected failure for topHandler03(normal) (Full log at https://s3.amazonaws.com/archive.travis-ci.org/jobs/13982142/log.txt) Does anyone feel responsible? Greetings, Joachim -- Joachim “nomeata” Breitner mail(a)joachim-breitner.de • http://www.joachim-breitner.de/ Jabber: nomeata(a)joachim-breitner.de • GPG-Key: 0x4743206C Debian Developer: nomeata(a)debian.org

2 1

Trac formatting
by Simon Peyton-Jones 15 Nov '13

15 Nov '13

When Trac formats commit messages it is doing a terrible job. See for example: https://ghc.haskell.org/trac/ghc/ticket/5996 The commit message is nigh illegible until typeset without makup (see comment 10). Could this be done automatically? Simon Microsoft Research Limited (company number 03369488) is registered in England and Wales Registered office is at 21 Station Road, Cambridge, CB1 2FB

4 7