- ghc-devs - Haskell.org

[PATCH] Fix typo in User's Guide
by Pedro Rodrigues 21 Nov '13

21 Nov '13

--- docs/users_guide/glasgow_exts.xml | 2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/docs/users_guide/glasgow_exts.xml b/docs/users_guide/glasgow_exts.xml index ce07806..d61ff7a 100644 --- a/docs/users_guide/glasgow_exts.xml +++ b/docs/users_guide/glasgow_exts.xml @@ -8673,7 +8673,7 @@ proc (x,y) -> which is translated to <screen> arr (\ (x,y) -> if f x y then Left x else Right y) >>> - (arr (\x -> x+1) >>> f) ||| (arr (\y -> y+2) >>> g) + (arr (\x -> x+1) >>> g) ||| (arr (\y -> y+2) >>> h) </screen> Since the translation uses <function>|||</function>, the arrow concerned must belong to the <literal>ArrowChoice</literal> class. -- 1.7.4.1

5 6

Re: [commit: testsuite] master: Much better perf on 5030, higher peak on 3064 (53b3199)
by Simon Marlow 21 Nov '13

21 Nov '13

On 12/11/13 15:07, git(a)git.haskell.org wrote: > Repository : ssh://git@git.haskell.org/testsuite > > On branch : master > Link : http://ghc.haskell.org/trac/ghc/changeset/53b3199b03bd2e52c63babffd33d47824… > >> --------------------------------------------------------------- > > commit 53b3199b03bd2e52c63babffd33d478242ae74d5 > Author: Simon Peyton Jones <simonpj(a)microsoft.com> > Date: Tue Nov 12 15:06:56 2013 +0000 > > Much better perf on 5030, higher peak on 3064 > > The peak-megabytes is vulnerable to when GC runs Juat a reminder to everyone: when peak_megabytes or max_bytes_used changes, please run with +RTS -h -i0.01 to get a heap profile and check whether it's a real change or not. You don't need to compile for profiling or anything. Cheers, Simon

2 1

Behaviour of readProcess, and code simplicity (or lack thereof)
by Duncan Coutts 21 Nov '13

21 Nov '13

Hi possibly-interested souls, In this patch to System.Process.readProcess from last year: https://ghc.haskell.org/trac/ghc/changeset/b5ee908863882d18e4110d96b43ccc1b… Bas changed things so that if an async exception is received by the thread calling readProcess (or readProcessWithExitCode) then the external process gets forcibly terminated. I do mean forcibly, it's TerminateProcess() on Windows and SIGKILL (not SIGTERM) on Unix. I was wondering if this is really desirable behaviour. There are certainly programs out there that will leave stale lock files (or worse) if forcibly terminated, that can shut down reasonably cleanly if asked more nicely. I have to say, it does make me a bit nervous. That said, terminating programs cleanly is a tricky business. While there is SIGTERM on Unix, there's no simple way to do it on Windows; there's no softer equivalent of TerminateProcess(). But if we think it *is* the right behaviour then I think we ought to be doing it consistently. There are other System.Process functions that run processes synchronously that should have the same behaviour. And it turns out that cleaning up is rather subtle. Takano recently sent in a patch to fix a deadlock due to the order in which the cleanup happens: https://ghc.haskell.org/trac/ghc/changeset/32223a9ab174c22e939c81e24b6f4822… So if it is desirable behaviour and is so subtle we ought to provide the users with some help to do it (or indeed to do alternatives if we think no one policy fits all). For example, we could provide: -- | A 'bracketOnError'-style resource handler for 'createProcess'. -- -- In normal operation it adds nothing, you are still responsible for -- waiting for (or forcing) process termination and closing any -- 'Handle's. It only does automatic cleanup if there is an exception. -- If there is an exception in the body then it ensures that the process -- gets terminated and any 'CreatePipe' 'Handle's are closed. In -- particular this means that if the Haskell thread is killed (e.g. -- 'killThread'), that the external process is also terminated. -- withCreateProcess :: CreateProcess -> (Maybe Handle -> Maybe Handle -> Maybe Handle -> ProcessHandle -> IO a) -> IO a withCreateProcess c action = bracketOnError (createProcess c) cleanupProcess (\(m_in, m_out, m_err, ph) -> action m_in m_out m_err ph) cleanupProcess :: (Maybe Handle, Maybe Handle, Maybe Handle, ProcessHandle) -> IO ExitCode cleanupProcess (mb_stdin, mb_stdout, mb_stderr, ph) = do -- We rely on the fact that terminateProcess really does terminate it -- and not just ask it nicely. Otherwise we could deadlock if there -- are other threads holding the lock on the stdin/out/err Handles. terminateProcess ph maybe (return ()) hClose mb_stdin maybe (return ()) hClose mb_stdout maybe (return ()) hClose mb_stderr waitForProcess ph As it is, the docs say: 'readProcess' and 'readProcessWithExitCode' are fairly simple wrappers around 'createProcess'. Constructing variants of these functions is quite easy: follow the link to the source code to see how 'readProcess' is implemented. but if you do look at the source you see that while it may originally have been true, it certainly is not anymore! Providing and using a withCreateProcess-style would help quite a bit. Also, the ignoring EPIPE stuff is rather unsatisfactory and non-portable. It's not used consistently and it's impossible for anyone else to implement it themselves without using GHC internals. It's almost possible in a nice way, since you could check if it's ResourceVanished rather than errno = EPIPE, but actually ResourceVanished is not exposed via System.IO.Error either. I think it's worth if at all possible making it true that people can write useful and reliable special cases of createProcess, but we'd need to provide more help.

3 2

clang/wrapper cannot build GHC head with integer-gmp on Mavericks
by Kazu Yamamoto 21 Nov '13

21 Nov '13

Hi, I'm try to make GHC head stably buildable with clang/wrapper on Mavericks because we cannot ask all Mavericks users to install apple-gcc or GCC. The last big item for me is integer-gmp. GHC head cannot be built with clang/wrapper if integer-gmp is used. (integer-simple is OK.) This is because "configure" of libgmp fails. Now I understand why this happens. The source of this problem is "/usr/bin/gcc" which is a wrapper for clang (not gcc actually). This cheats "configure" of libgmp. If we type "CC=clang ./configure", it works. The problem is how to specify "CC=clang" to configure of libgmp when we build GHC head. If we modified "libraries/integer-gmp/gmp/ghc.mk" manually, we can build GHC head. But I don't like this one since "make maintainer-clean" removes "ghc.mk". Any ideas? Ticket is here: https://ghc.haskell.org/trac/ghc/ticket/8497 --Kazu

2 3

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