September 2013 - ghc-devs

RE: GHC 7.8 release status
by Simon Peyton-Jones 05 Sep '13

05 Sep '13

Maybe not, but you'll have to move fast. · Make a branch (Iavor can do that) · Update the wiki page describing the design: http://ghc.haskell.org/trac/ghc/wiki/GhcKinds/KindsWithoutData You can demote any design alternatives that you discarded, putting them in an appendix at the end. · Update documentation in the user manual · Make sure you have tests in the testsuite How fast can you do that? Simon From: Trevor Elliott [mailto:awesomelyawesome@gmail.com] Sent: 04 September 2013 18:30 To: Iavor Diatchki; Simon Peyton-Jones Subject: Re: GHC 7.8 release status Hi Simon, We had talked during your Galois visit about the changes that Iavor and I had made to -XDataKinds, allowing different syntax when introducing a new kind. Have we missed the window to make it into the 7.8 release? Thanks! --trevor On Wed, Sep 4, 2013 at 10:27 AM, Iavor Diatchki <iavor.diatchki(a)gmail.com<mailto:iavor.diatchki@gmail.com>> wrote: ---------- Forwarded message ---------- From: Simon Peyton-Jones <simonpj(a)microsoft.com<mailto:simonpj@microsoft.com>> Date: Wed, Sep 4, 2013 at 6:52 AM Subject: GHC 7.8 release status To: Nicolas Frisby <nicolas.frisby(a)gmail.com<mailto:nicolas.frisby@gmail.com>>, "Pedro Magalhães (dreixel(a)gmail.com<mailto:dreixel@gmail.com>)" <dreixel(a)gmail.com<mailto:dreixel@gmail.com>>, "Richard Eisenberg (eir(a)cis.upenn.edu<mailto:eir@cis.upenn.edu>)" <eir(a)cis.upenn.edu<mailto:eir@cis.upenn.edu>>, "Geoffrey Mainland (mainland(a)cs.drexel.edu<mailto:mainland@cs.drexel.edu>)" <mainland(a)cs.drexel.edu<mailto:mainland@cs.drexel.edu>>, Iavor Diatchki <iavor.diatchki(a)gmail.com<mailto:iavor.diatchki@gmail.com>>, Austin Seipp <aseipp(a)pobox.com<mailto:aseipp@pobox.com>>, Edsko de Vries <edsko(a)well-typed.com<mailto:edsko@well-typed.com>>, "Ryan Newton (rrnewton(a)gmail.com<mailto:rrnewton@gmail.com>)" <rrnewton(a)gmail.com<mailto:rrnewton@gmail.com>>, Luite Stegeman <stegeman(a)gmail.com<mailto:stegeman@gmail.com>>, Thomas Schilling <nominolo(a)googlemail.com<mailto:nominolo@googlemail.com>>, David Luposchainsky <dluposchainsky(a)googlemail.com<mailto:dluposchainsky@googlemail.com>> Cc: "ghc-devs(a)haskell.org<mailto:ghc-devs@haskell.org>" <ghc-devs(a)haskell.org<mailto:ghc-devs@haskell.org>> 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

1 0

Haskeline 0.7.0.4
by Edward Z. Yang 04 Sep '13

04 Sep '13

Hey Judah, We're gearing up for another GHC release, and there a small number of patches which are still in GHC's tree which have not made it into the upstream haskeline repository: commit 495b00b4f125c0b4e7f1e966cd961eae89cffdc0 Author: Herbert Valerio Riedel <hvr(a)gnu.org> Date: Sat Aug 31 10:31:52 2013 +0200 Avoid shadowing `handlers` variable in `catches` commit 40bcd6ac30577d1d240166674d1e328ac52c1fd5 Author: Ian Lynagh <ian(a)well-typed.com> Date: Tue Jul 2 16:46:53 2013 +0100 Fix build on Win64 commit 3a92ddd63d4edc622ad4af044c5b664aa64c3dd4 Author: Ian Lynagh <ian(a)well-typed.com> Date: Sun Feb 17 20:25:10 2013 +0000 Follow unix's version bump Additionally, I have one more patch for the Windows build, attached below: commit 80f2fafe39cbc86205afb2eac8d4f60a1ce2684e Author: Edward Z. Yang <ezyang(a)mit.edu> Date: Wed Sep 4 17:45:37 2013 -0700 Avoid Handler identifier conflict in Windows. Signed-off-by: Edward Z. Yang <ezyang(a)mit.edu> diff --git a/System/Console/Haskeline/Backend/Win32.hsc b/System/Console/Haskeline/Backend/Win32.hsc index d54df2c..4447519 100644 --- a/System/Console/Haskeline/Backend/Win32.hsc +++ b/System/Console/Haskeline/Backend/Win32.hsc @@ -17,7 +17,7 @@ import Data.Maybe(mapMaybe) import Control.Monad import System.Console.Haskeline.Key -import System.Console.Haskeline.Monads +import System.Console.Haskeline.Monads hiding (Handler) import System.Console.Haskeline.LineState import System.Console.Haskeline.Term import System.Console.Haskeline.Backend.WCWidth Thanks, Edward

2 2

Status of Windows validate
by Edward Z. Yang 04 Sep '13

04 Sep '13

A lot of failures: ---- Unexpected results from: TEST="T5313 registry001 cabal01 dynamicToo002 dynHelloWorld T1969 T5030 T3294 T7797 T7850 haddock.Cabal haddock.compiler haddock.base linker_unload derefnull T4850 divbyzero T8172 ghci058 prog002 prog003 ImpSafeOnly08 safePkg01 ImpSafeOnly02 ImpSafeOnly03 ImpSafeOnly01 ImpSafeOnly06 ImpSafeOnly07 ImpSafeOnly04 ImpSafeOnly05 ImpSafeOnly09 ImpSafeOnly10" OVERALL SUMMARY for test run started at now 3724 total tests, which gave rise to 12242 test cases, of which 8869 were skipped 27 had missing libraries 3248 expected passes 61 expected failures 18 caused framework failures 1 unexpected passes 31 unexpected failures Unexpected passes: driver T5313 (normal) Unexpected failures: ../../libraries/Win32/tests registry001 [bad exit code] (normal) cabal/cabal01 cabal01 [bad exit code] (normal) driver dynHelloWorld [bad exit code] (dyn) driver/dynamicToo/dynamicToo002 dynamicToo002 [bad stdout] (normal) ghci/prog002 prog002 [bad exit code] (ghci) ghci/prog003 prog003 [bad exit code] (ghci) ghci/scripts T8172 [bad stdout] (ghci) ghci/scripts ghci058 [bad exit code] (ghci) perf/compiler T1969 [stat not good enough] (normal) perf/compiler T5030 [stat too good] (normal) perf/haddock haddock.Cabal [stat not good enough] (normal) perf/haddock haddock.base [stat not good enough] (normal) perf/haddock haddock.compiler [stat too good] (normal) perf/should_run T7797 [stat too good] (normal) perf/should_run T7850 [stat too good] (normal) rts T4850 [bad stdout] (normal) rts derefnull [bad exit code] (normal) rts divbyzero [bad exit code] (normal) rts linker_unload [bad exit code] (normal) safeHaskell/check/pkg01 ImpSafeOnly01 [exit code non-0] (normal) safeHaskell/check/pkg01 ImpSafeOnly02 [exit code non-0] (normal) safeHaskell/check/pkg01 ImpSafeOnly03 [stderr mismatch] (normal) safeHaskell/check/pkg01 ImpSafeOnly04 [exit code non-0] (normal) safeHaskell/check/pkg01 ImpSafeOnly05 [stderr mismatch] (normal) safeHaskell/check/pkg01 ImpSafeOnly06 [exit code non-0] (normal) safeHaskell/check/pkg01 ImpSafeOnly07 [stderr mismatch] (normal) safeHaskell/check/pkg01 ImpSafeOnly08 [stderr mismatch] (normal) safeHaskell/check/pkg01 ImpSafeOnly09 [stderr mismatch] (normal) safeHaskell/check/pkg01 ImpSafeOnly10 [exit code non-0] (normal) safeHaskell/check/pkg01 safePkg01 [bad exit code] (normal) Cheers, Edward

1 0

Re: RE: More windows woe
by Jost Berthold 04 Sep '13

04 Sep '13

> From: Simon Peyton-Jones <simonpj(a)microsoft.com> > To: "Edward Z. Yang" <ezyang(a)MIT.EDU>, Simon Marlow > <marlowsd(a)gmail.com> > Cc: "ghc-devs(a)haskell.org" <ghc-devs(a)haskell.org> > Subject: RE: More windows woe > Message-ID: > <59543203684B2244980D7E4057D5FBC1485BB7AB(a)DB3EX14MBXC308.europe.corp.microsoft.com> > > Content-Type: text/plain; charset="utf-8" > > Simon Marlow: please help! > At the moment windows builds are hosed, which is a Bad Situation. > > Actually it turns out that what want is > > debugBelch("Checking whether to unload %S\n", oc->fileName)); > > That is, use "%S" rather than "%s" as format specifier for wide chars. > > Sadly, this works on Windows, but not on Linux: > rts/CheckUnload.c:260:13: > error: format ?%S? expects argument of type ?wchar_t *?, but argument 2 has type ?pathchar *? [-Werror=format] > > > So what I need guidance on, please!, is what the approved way to deal with this is. I suppose that I could identify each use of %s on a filepath and say > > #ifdef mingw32_HOST_OS > debugBelch("Checking whether to unload %S\n", oc->fileName)); > #else > debugBelch("Checking whether to unload %s\n", oc->fileName)); > #endif > > But that seems deeply unsatisfactory doesn't it? > > If not that, then what? > > > Simon Similar code is in place to distinguish between 32-bit and 64-bit StgWords: > grep -r -e FMT_Word includes/ includes/stg/Types.h:#define FMT_Word32 "u" includes/stg/Types.h:#define FMT_Word32 "lu" includes/stg/Types.h:#define FMT_Word64 "lu" includes/stg/Types.h:#define FMT_Word64 "llu" includes/stg/Types.h:#define FMT_Word FMT_Word64 includes/stg/Types.h:#define FMT_Word FMT_Word32 and format strings like "blabla " FMT_Word " ..blabla" are used inside rts/. One could do the same for FMT_Path and introduce it where required. Maybe this would be acceptable? / Jost

4 6

More windows woe
by Simon Peyton-Jones 04 Sep '13

04 Sep '13

OK, so now my windows build is getting further, but it now falls over here. This one looks more straightforward! Can anyone help? Simon "inplace/bin/ghc-stage1.exe" -optc-Werror -optc-Wall -optc-Wall -optc-Wextra -optc-Wstrict-prototypes -optc-Wmissing-prototypes -optc-Wmissing-declarations -optc-Winline -optc-Waggregate-return -optc-Wpointer-arith -optc-Wmissing-noreturn -optc-Wnested-externs -optc-Wredundant-decls -optc-Iincludes -optc-Iincludes/dist -optc-Iincludes/dist-derivedconstants/header -optc-Iincludes/dist-ghcconstants/header -optc-Irts -optc-Irts/dist/build -optc-DCOMPILING_RTS -optc-fno-strict-aliasing -optc-fno-common -optc-O2 -optc-fomit-frame-pointer -optc-fno-omit-frame-pointer -optc-g -optc-O0 -optc-DRtsWay=\"rts_debug\" -static -optc-DDEBUG -ticky -DTICKY_TICKY -H32m -O -Werror -Wall -H64m -O0 -Iincludes -Iincludes/dist -Iincludes/dist-derivedconstants/header -Iincludes/dist-ghcconstants/header -Irts -Irts/dist/build -DCOMPILING_RTS -package-name rts -dcmm-lint -i -irts -irts/dist/build -irts/dist/build/autogen -Irts/dist/build -Irts/dist/build/autogen -O2 -O0 -c rts/CheckUnload.c -o rts/dist/build/CheckUnload.debug_o cc1.exe: warnings being treated as errors rts\CheckUnload.c: In function 'checkUnload': rts\CheckUnload.c:257:7: error: format '%s' expects type 'char *', but argument 2 has type 'pathchar *' rts\CheckUnload.c:293:11: error: format '%s' expects type 'char *', but argument 2 has type 'pathchar *' rts\CheckUnload.c:297:11: error: format '%s' expects type 'char *', but argument 2 has type 'pathchar *' bash-3.1$

3 9

cvs-ghc archives
by Simon Peyton-Jones 04 Sep '13

04 Sep '13

Links like this one fail to work. Is this permanent? Thanks! http://www.haskell.org/pipermail/cvs-ghc/2007-July/036496.html Microsoft Research Limited (company number 03369488) is registered in England and Wales Registered office is at 21 Station Road, Cambridge, CB1 2FB

4 3

Anyone else failing to validate on 'linker_unload'?
by Ryan Newton 04 Sep '13

04 Sep '13

That test builds an executable named 'linker_unload' which segfaults for me. Valgrind says this: ==42800== Invalid read of size 8 ==42800== at 0x66945F: checkUnload (in /home/beehive/ryan_scratch/validate14/testsuite/tests/rts/linker_unload) ==42800== by 0x657F7A: GarbageCollect (in /home/beehive/ryan_scratch/validate14/testsuite/tests/rts/linker_unload) ==42800== by 0x651790: scheduleDoGC (in /home/beehive/ryan_scratch/validate14/testsuite/tests/rts/linker_unload) ==42800== by 0x6518B4: performGC_ (in /home/beehive/ryan_scratch/validate14/testsuite/tests/rts/linker_unload) ==42800== by 0x403BB1: main (in /home/beehive/ryan_scratch/validate14/testsuite/tests/rts/linker_unload) ==42800== Address 0x5bfdd20 is 80 bytes inside a block of size 120 free'd ==42800== at 0x4C273F0: free (vg_replace_malloc.c:446) ==42800== by 0x66945E: checkUnload (in /home/beehive/ryan_scratch/validate14/testsuite/tests/rts/linker_unload) ==42800== by 0x657F7A: GarbageCollect (in /home/beehive/ryan_scratch/validate14/testsuite/tests/rts/linker_unload) ==42800== by 0x651790: scheduleDoGC (in /home/beehive/ryan_scratch/validate14/testsuite/tests/rts/linker_unload) ==42800== by 0x6518B4: performGC_ (in /home/beehive/ryan_scratch/validate14/testsuite/tests/rts/linker_unload) ==42800== by 0x403BB1: main (in /home/beehive/ryan_scratch/validate14/testsuite/tests/rts/linker_unload) This went the same across a couple different independent checkouts. -Ryan

4 10

Building on Windows with msys
by Simon Peyton-Jones 04 Sep '13

04 Sep '13

Friends My Windows build (new laptop) got stuck again, but this time I managed to work out what is going on. This email is just to record the issue; I'll add something to the wiki. tl;dr: a MSYS build will fail in a deeply strange way if your MSYS bin directory doesn't take priority over the windows/system32 director. Symptom: "sh libtool" hangs indefinitely. The process manager shows an extant "cmd" and "sed", but nothing else. libtool is a shell script that comes from a tarball, and is unpacked into libraries/integer-gmp/gmp/gmpbuild/libtool Cause: libtool invokes the following command line (in the function func_convert_coer_msys_to_w32: cmd /c "echo blah" and pipes the result to sed. But MSYS mangles the command line to turn slashes into backslashes. So the actual command line is more like cmd \c "echo blah" which does something entirely different, and indeed hangs waiting for input on stdin. Solution: So how did this ever work on any MSYS installation? Because * msys/1.0/bin has a little script "cmd" which hands off to the real c:/windows/system32/cmd * MSYS does not mangle the command-line for programs in msys/1.0/bin * On my old laptop, msys/1.0/bin was in my path before c:/windows/system32. So plain "cmd" gets the script, and MSYS does not mangle the command line. The script passes arguments on unchanged to the real cmd. * NB: c:/windows/system32 is in the "system" path, which precedes the "user" path. So no amount of fiddling with the "user" path will fix this. There are two solutions: o Modify the system path o Use a .bashrc file to prepend the stuff you need This is pretty subtle stuff. Simon Microsoft Research Limited (company number 03369488) is registered in England and Wales Registered office is at 21 Station Road, Cambridge, CB1 2FB

2 1

RE: RE: More windows woe
by Kyle Van Berendonck 04 Sep '13

04 Sep '13

A quick search reveals that this is valid ANSI C. Regards, Kyle

1 0

Unicode quotes
by Kazu Yamamoto 04 Sep '13

04 Sep '13

Hello, GHCi of GHC 7.7 use Unicode quote marks instead of ASCII quote marks. Why do you guys decide this behavior change? I'm just curious. --Kazu

3 3