- ghc-devs - Haskell.org

T13156
by Ben Gamari 20 Jan '17

20 Jan '17

Hi Simon, I'm seeing some rather peculiar validation issues with your most recent patch. Namely, =====> T13156(normal) 1 of 1 [0, 0, 0] cd "./simplCore/should_compile/T13156.run" && $MAKE -s --no-print-directory T13156 Actual stdout output differs from expected: diff -uw "./simplCore/should_compile/T13156.run/T13156.stdout.normalised" "./simplCore/should_compile/T13156.run/T13156.run.stdout.normalised" --- ./simplCore/should_compile/T13156.run/T13156.stdout.normalised 2017-01-20 13:00:46.620654541 -0500 +++ ./simplCore/should_compile/T13156.run/T13156.run.stdout.normalised 2017-01-20 13:00:46.620654541 -0500 @@ -1,5 +1,2 @@ case GHC.List.reverse @ a x of sat { __DEFAULT -> - case \ (@ a) -> - case g x of { - case r @ GHC.Types.Any of { __DEFAULT -> - case r @ GHC.Types.Any of { __DEFAULT -> GHC.Types.True } + case case g x of { Oddly enough Harbormaster isn't reproducing this, but it seems to be quite reproducible locally. Do you have any idea what might be going on here? Cheers, - Ben

1 1

Arc doesn't work
by Simon Peyton Jones 20 Jan '17

20 Jan '17

I can't use arc. At the end of 'arc diff' it says Exception Some linters failed: - CommandException: Command failed with error #1! COMMAND python3 .arc-linters/check-cpp.py 'compiler/basicTypes/Id.hs' STDOUT (empty) STDERR File ".arc-linters/check-cpp.py", line 28 r = re.compile(rb'ASSERT\s+\(') ^ SyntaxError: invalid syntax (Run with `--trace` for a full exception trace.) simonpj@cam-05-unx:~/code/HEAD-3$ python3 --version python3 --version Python 3.2.3 Alas. Simon

2 3

RE: Arc doesn't work
by Simon Peyton Jones 20 Jan '17

20 Jan '17

Have you tried to 'arc upgrade'? Yes, I did that. It did upgrade successfully, but had no effect on this. S From: Simon Peyton Jones Sent: 20 January 2017 17:11 To: 'Alan & Kim Zimmerman' <alan.zimm(a)gmail.com> Subject: RE: Arc doesn't work Have you tried to 'arc upgrade'? Yes, I did that. It did upgrade successfully, but had no effect on this. S From: Alan & Kim Zimmerman [mailto:alan.zimm@gmail.com] Sent: 20 January 2017 16:18 To: Simon Peyton Jones <simonpj(a)microsoft.com<mailto:simonpj@microsoft.com>> Subject: Re: Arc doesn't work Have you tried to 'arc upgrade'? On 20 January 2017 at 17:50, Simon Peyton Jones via ghc-devs <ghc-devs(a)haskell.org<mailto:ghc-devs@haskell.org>> wrote: I can’t use arc. At the end of ‘arc diff’ it says Exception Some linters failed: - CommandException: Command failed with error #1! COMMAND python3 .arc-linters/check-cpp.py 'compiler/basicTypes/Id.hs' STDOUT (empty) STDERR File ".arc-linters/check-cpp.py", line 28 r = re.compile(rb'ASSERT\s+\(') ^ SyntaxError: invalid syntax (Run with `--trace` for a full exception trace.) simonpj@cam-05-unx:~/code/HEAD-3$ python3 --version python3 --version Python 3.2.3 Alas. Simon _______________________________________________ ghc-devs mailing list ghc-devs(a)haskell.org<mailto:ghc-devs@haskell.org> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs<https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fmail.haskel…>

1 0

Magical function to support reflection
by David Feuer 20 Jan '17

20 Jan '17

The following proposal (with fancier formatting and some improved wording) can be viewed at https://ghc.haskell.org/trac/ghc/wiki/MagicalReflectionSupport Using the Data.Reflection has some runtime costs. Notably, there can be no inlining or unboxing of reified values. I think it would be nice to add a GHC special to support it. I'll get right to the point of what I want, and then give a bit of background about why. === What I want I propose the following absurdly over-general lie: reify# :: (forall s . c s a => t s r) -> a -> r `c` is assumed to be a single-method class with no superclasses whose dictionary representation is exactly the same as the representation of `a`, and `t s r` is assumed to be a newtype wrapper around `r`. In desugaring, reify# f would be compiled to f@S, where S is a fresh type. I believe it's necessary to use a fresh type to prevent specialization from mixing up different reified values. === Background Let me set up a few pieces. These pieces are slightly modified from what the package actually does to make things cleaner under the hood, but the differences are fairly shallow. newtype Tagged s a = Tagged { unTagged :: a } unproxy :: (Proxy s -> a) -> Tagged s a unproxy f = Tagged (f Proxy) class Reifies s a | s -> a where reflect' :: Tagged s a -- For convenience reflect :: forall s a proxy . Reifies s a => proxy s -> a reflect _ = unTagged (reflect' :: Tagged s a) -- The key function--see below regarding implementation reify' :: (forall s . Reifies s a => Tagged s r) -> a -> r -- For convenience reify :: a -> (forall s . Reifies s a => Proxy s -> r) -> r reify a f = reify' (unproxy f) a The key idea of reify' is that something of type forall s . Reifies s a => Tagged s r is represented in memory exactly the same as a function of type a -> r So we can currently use unsafeCoerce to interpret one as the other. Following the general approach of the library, we can do this as such: newtype Magic a r = Magic (forall s . Reifies s a => Tagged s r) reify' :: (forall s . Reifies s a => Tagged s r) -> a -> r reify' f = unsafeCoerce (Magic f) This certainly works. The trouble is that any knowledge about what is reflected is totally lost. For instance, if I write reify 12 $ \p -> reflect p + 3 then GHC will not see, at compile time, that the result is 15. If I write reify (+1) $ \p -> reflect p x then GHC will never inline the application of (+1). Etc. I'd like to replace reify' with reify# to avoid this problem. Thanks, David Feuer

6 16

Type family bug?
by Simon Peyton Jones 19 Jan '17

19 Jan '17

Richard This works type family F (a :: k) type instance F Maybe = Char But this does not. Surely it should? type family F (a :: k) where -- = r | r -> a where F Maybe = Char The latter is rejected with Foo.hs:6:5: error: * Expecting one more argument to `Maybe' Expected kind `k', but `Maybe' has kind `* -> *' * In the first argument of `F', namely `Maybe' In the type family declaration for `F' If you agree I'll open a ticket. Simon

2 1

Building RUNPATH into ghc binaries for 3rd-party libraries
by Albert Chin 19 Jan '17

19 Jan '17

Hi. I am building ghc-8.0.2 on RHEL 6 and trying to get the runtime path for 3rd-party libraries outside of the system search path embedded into the ghc binaries. Specifically, this is for libffi and libgmp. I am using the attached patch for this and it seems to work for the most part. It does not work for ghc-iserv through: $ cd /usr/local/ghc80/lib/ghc-8.0.2/bin $ ldd ghc-iserv linux-vdso.so.1 => (0x00007fffba3ff000) librt.so.1 => /lib64/librt.so.1 (0x00000033e0e00000) libutil.so.1 => /lib64/libutil.so.1 (0x00000033f0200000) libdl.so.2 => /lib64/libdl.so.2 (0x00000033e0600000) libgmp.so.10 => not found libm.so.6 => /lib64/libm.so.6 (0x00000033e0200000) libffi.so.6 => not found libpthread.so.0 => /lib64/libpthread.so.0 (0x00000033e0a00000) libc.so.6 => /lib64/libc.so.6 (0x00000033dfe00000) /lib64/ld-linux-x86-64.so.2 (0x00000033dfa00000) I presume I need to add something like the following to iserv/ghc.mk somewhere? -optl-Wl,-rpath,$(FFILibDir) \ -optl-Wl,-rpath,$(GMP_LIB_DIRS) \ -- albert chin (china(a)thewrittenword.com)

1 0

[ANNOUNCE] Glasgow Haskell Compiler 8.0.2 is available!
by Ben Gamari 19 Jan '17

19 Jan '17

=============================================== The Glasgow Haskell Compiler -- version 8.0.2 =============================================== The GHC team is happy to at last announce the 8.0.2 release of the Glasgow Haskell Compiler. Source and binary distributions are available at http://downloads.haskell.org/~ghc/8.0.2/ This is the second release of the 8.0 series and fixes nearly two-hundred bugs. These include, * Interface file build determinism (#4012). * Compatibility with macOS Sierra and GCC compilers which compile position-independent executables by default * Compatibility with systems which use the gold linker * Runtime linker fixes on Windows (see #12797) * A compiler bug which resulted in undefined reference errors while compiling some packages (see #12076) * A number of memory consistency bugs in the runtime system * A number of efficiency issues in the threaded runtime which manifest on larger core counts and large numbers of bound threads. * A typechecker bug which caused some programs using -XDefaultSignatures to be incorrectly accepted. * More than two-hundred other bugs. See Trac [1] for a complete listing. * #12757, which lead to broken runtime behavior and even crashes in the presence of primitive strings. * #12844, a type inference issue affecting partial type signatures. * A bump of the `directory` library, fixing buggy path canonicalization behavior (#12894). Unfortunately this required a major version bump in `directory` and minor bumps in several other libraries. * #12912, where use of the `select` system call would lead to runtime system failures with large numbers of open file handles. * #10635, wherein -Wredundant-constraints was included in the -Wall warning set A more detailed list of the changes included in this release can be found in the release notes, https://downloads.haskell.org/~ghc/8.0.2/docs/html/users_guide/8.0.2-notes.… Please note that this release breaks with our usual tendency to avoid major version bumps of core libraries in minor GHC releases by including an upgrade of the `directory` library to 1.3.0.0. Also note that, due to a rather serious bug (#13100) affecting Windows noticed late in the release cycle, the Windows binary distributions were produced using a slightly patched [2] source tree. Users compiling from source for Windows should be certain to include this patch in their build. This release is the result of six months of effort by the GHC development community. We'd like to thank everyone who has contributed code, bug reports, and feedback to this release. It's only due to their efforts that GHC remains a vibrant and exciting project. [1] https://ghc.haskell.org/trac/ghc/query?status=closed&milestone=8.0.2&col=id… [2] http://downloads.haskell.org/~ghc/8.0.2/0001-SysTools-Revert-linker-flags-c… How to get it ~~~~~~~~~~~~~ Both the source tarball and binary distributions for a wide variety of platforms are available at, http://www.haskell.org/ghc/ Background ~~~~~~~~~~ Haskell is a standardized lazy functional programming language. The Glasgow Haskell Compiler (GHC) is a state-of-the-art programming suite for Haskell. Included is an optimising compiler generating efficient code for a variety of platforms, together with an interactive system for convenient, quick development. The distribution includes space and time profiling facilities, a large collection of libraries, and support for various language extensions, including concurrency, exceptions, and foreign language interfaces. GHC is distributed under a BSD-style open source license. Supported Platforms ~~~~~~~~~~~~~~~~~~~ The list of platforms we support, and the people responsible for them, can be found on the GHC wiki http://ghc.haskell.org/trac/ghc/wiki/Platforms Ports to other platforms are possible with varying degrees of difficulty. The Building Guide describes how to go about porting to a new platform: http://ghc.haskell.org/trac/ghc/wiki/Building Developers ~~~~~~~~~~ We welcome new contributors. Instructions on getting started with hacking on GHC are available from GHC's developer site, http://ghc.haskell.org/trac/ghc/ Community Resources ~~~~~~~~~~~~~~~~~~~ There are mailing lists for GHC users, develpoers, and monitoring bug tracker activity; to subscribe, use the web interfaces at http://mail.haskell.org/cgi-bin/mailman/listinfo/glasgow-haskell-users http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-tickets There are several other Haskell and GHC-related mailing lists on www.haskell.org; for the full list, see https://mail.haskell.org/cgi-bin/mailman/listinfo Some GHC developers hang out on the #ghc and #haskell of the Freenode IRC network, too: http://www.haskell.org/haskellwiki/IRC_channel Please report bugs using our bug tracking system. Instructions on reporting bugs can be found here: http://www.haskell.org/ghc/reportabug

3 3

Join points
by Luke Maurer 17 Jan '17

17 Jan '17

Hello all! For your consideration, I present patch D2853: Join points. https://phabricator.haskell.org/D2853 It validates* and it's ready for wider reviewing, so please help me get it to land before the freeze! It's ... sizable. There's not really any way to split it, since there are many interdependencies. I've put up a "tour" as part of the SequentCore page on the wiki: https://ghc.haskell.org/trac/ghc/wiki/SequentCore This should help with where to start. Also included on the wiki are benchmarks and lots of general information. *Modulo a few long URLs and a known bug (D2964). - Luke Maurer University of Oregon maurerl(a)cs.uoregon.edu

2 1

Windows build
by Simon Peyton Jones 17 Jan '17

17 Jan '17

Hi Tamar The current state of a clean Windows build has improved - but still has multiple failures. See below Thanks for your work on this. I can send more details if that'd be helpful Simon Unexpected failures: plugins/plugins07.run plugins07 [bad exit code] (normal) plugins/T10420.run T10420 [bad exit code] (normal) plugins/T10294a.run T10294a [bad exit code] (normal) plugins/T11244.run T11244 [bad stderr] (normal) Framework failures: backpack/cabal/bkpcabal03/bkpcabal03.run bkpcabal03 [runTest] (Unhandled exception: [Errno 90] Directory not empty: 'autogen') plugins/plugins07.run plugins07 [normal] (pre_cmd failed: 2) plugins/T10420.run T10420 [normal] (pre_cmd failed: 2) plugins/T10294a.run T10294a [normal] (pre_cmd failed: 2) plugins/plugins07.run plugins07 [runTest] (Unhandled exception: [Errno 90] Directory not empty: 'rule-defining-plugin-0.1') plugins/T11244.run T11244 [normal] (pre_cmd failed: 2) safeHaskell/check/pkg01/ImpSafeOnly03.run ImpSafeOnly03 [runTest] (Unhandled exception: [Errno 90] Directory not empty: 'safePkg01-1.0-COK8JB4prM8EuKYKd3XaX3')

2 1

recomp001 failing on OSX for Phab:D2853
by Luke Maurer 17 Jan '17

17 Jan '17

Getting an odd test failure from Phab: @@ -1,2 +0,0 @@ - -C.hs:3:11: Module ‘B’ does not export ‘foo’ Actual stderr output differs from expected: *** unexpected failure for recomp001(normal) https://phabricator.haskell.org/harbormaster/build/18499/?l=0 I can't explain how my changes would break module exports *at all,* much less only on OSX. Found a Mac (running Mavericks and GHC 8.0.1) but couldn't reproduce it there. Thoughts? I'd love to nail this as soon as possible so I can get join points in before the feature freeze ... - Luke Maurer University of Oregon maurerl(a)cs.uoregon.edu

2 2