May 2018 - ghc-devs - Haskell.org

Question about ArrayArray#
by Michal Terepeta 03 May '18

03 May '18

Hi all, I have a quick question about ArrayArray#. Is it safe to store *both* an ByteArray# and ArrayArray# within the *same* ArrayArray#? For instance: - at index 0 of an ArrayArray# I store a different ArrayArray#, - at index 1 of that same ArrayArray# I store a ByteArray#. It seems to me that this should be safe/supported from the point of view of the runtime system: - both ArrayArray# and ByteArray# have the same kind/runtime representation, - the arrays have a header that tells rts/GC what they are/how to handle them. (But I, as a user, would be responsible for using the right primop with the right index to read them back) Is this correct? Thanks a lot! - Michal

2 2

ghc 8.4.1 and trac 13930
by Evan Laforge 02 May '18

02 May '18

I recently noticed that with -O1, ghc was optimizing some code if Trace.traceShowId "b" $ True then return $ Left $ Serialize.BadMagic (Serialize.magicBytes magic) file_magic else first Serialize.UnserializeError <$> Exception.evaluate (Serialize.decode rest) to always evaluate the 'else' branch. This is fixed in 8.4.2, so I'm pretty sure it's https://ghc.haskell.org/trac/ghc/ticket/13930 I assume there's no point trying to get a minimal reproduction, since it's a known issue and fixed. Still, https://downloads.haskell.org/~ghc/8.4.2/docs/html/users_guide/8.4.2-notes.… says "incorrectly optimised, resulting in space leaks". Maybe it should instead say "incorrectly optimised, resulting in taking the wrong branch in 'if' expressions"? That's a bit more alarming, and is a stronger "upgrade to 8.4.2" signal.

3 7

building ghc once or twice?
by Jens Petersen 02 May '18

02 May '18

I have been packaging ghc for a long time... In older times I think it was recommended to first do a (quick) build of a new version of ghc (with the previous version) and then to do a (perf) rebuild of the new version against itself. In fact I am still building ghc this way for Fedora: though it seems like this is overhead nowadays...? (I think one major reason was to get stable ABI hashes for the core library packages.) These days should I just do a single default or perf build of a new ghc version against a previous stable release, or does it still make sense to continue to build in two steps like I have been doing? Any pros or cons? Jens

2 1

RE: Open up the issues tracker on ghc-proposals
by Simon Peyton Jones 02 May '18

02 May '18

| > Sometimes, a language extension idea could benefit from | some community discussion before it's ready for a formal proposal. | | Can I point out it's not only ghc developers who make proposals. I'd | rather you post this idea more widely. The Right Thing is surely for the main GHC proposals pave https://github.com/ghc-proposals/ghc-proposals to describe how you can up a "pre-proposal". That is, document the entire process in one, easy to find, place. Mind you, I'm unclear about the distinction between a pre-proposal and a proposal. Both are drafts that invite community discussion, prior to submitting to the committee for decision. Simon | -----Original Message----- | From: Glasgow-haskell-users <glasgow-haskell-users- | bounces(a)haskell.org> On Behalf Of Anthony Clayden | Sent: 02 May 2018 02:34 | To: glasgow-haskell-users(a)haskell.org; ghc-devs(a)haskell.org | Subject: Re: Open up the issues tracker on ghc-proposals | | > On May 1, 2018, at 2:24 PM, David Feuer <david.feuer at | gmail.com> wrote: | > | > Sometimes, a language extension idea could benefit from | some community discussion before it's ready for a formal proposal. | | Can I point out it's not only ghc developers who make proposals. I'd | rather you post this idea more widely. | | As a datapoint, I found ghc-users and the café just fine for those | discussions. | Ghc-users seems to have very low traffic/is rather wasted currently. | And I believe a lot of people pre-discuss on reddit. | For ideas that have been on the back burner for a long time, there's | often wiki pages. (For example re Quantified | Constraints.) | | > I'd like to propose that we open up the GitHub issues | tracker for ghc-proposals to serve as a place to discuss pre-proposal | ideas. Once those discussions converge on one or a few specific plans, | someone can write a proper proposal. | | I'm not against that. There gets to be a lot of cruft on some | discussions about proposals, so I'd expect we could archive it all | once a proposal is more formalised. | | AntC | | _______________________________________________ | Glasgow-haskell-users mailing list | Glasgow-haskell-users(a)haskell.org | http://mail.haskell.org/cgi-bin/mailman/listinfo/glasgow-haskell-users

1 0

Poly-kinded type family
by alice 01 May '18

01 May '18

Hello. I’m trying to make a type family with resolving it inside type checking classes, like CmpNat. Its type signature is «type family Cmp (a :: k1) (b :: k2) :: Ordering», so the function is poly kinded. But it seems unclear how to make its TyCon. I’ve tried to follow the CmpNat and CmpSymbol style, and also saw Any TyCon in TysWiredIn. So this is my attempt: typeCmpTyCon :: TyCon typeCmpTyCon = mkFamilyTyCon name (binders ++ (mkTemplateAnonTyConBinders [ input_kind1, input_kind2 ])) orderingKind Nothing (BuiltInSynFamTyCon ops) Nothing NotInjective where name = mkWiredInTyConName UserSyntax gHC_TYPELITS (fsLit "Cmp") typeCmpTyFamNameKey typeCmpTyCon ops = BuiltInSynFamily { sfMatchFam = matchFamCmpType , sfInteractTop = interactTopCmpType , sfInteractInert = \_ _ _ _ -> [] } binders@[kv1, kv2] = mkTemplateKindTyConBinders [ liftedTypeKind, liftedTypeKind ] input_kind1 = mkTyVarTy (binderVar kv1) input_kind2 = mkTyVarTy (binderVar kv2) ghci says this: :kind Cmp Cmp :: forall {k0} {k1}. k0 -> k1 -> Ordering But then I try to apply it to some values and get this exception: :kind! Cmp 4 5 <interactive>:1:15: error: • Expected kind ‘k0’, but ‘4’ has kind ‘Nat’ • In the first argument of ‘Cmp’, namely ‘4’ In the type ‘Cmp 4 5’ <interactive>:1:17: error: • Expected kind ‘k1’, but ‘5’ has kind ‘Nat’ • In the second argument of ‘Cmp’, namely ‘5’ In the type ‘Cmp 4 5’ Does anyone know where I made a mistake? Any help would be appreciated.

2 3

Open up the issues tracker on ghc-proposals
by David Feuer 01 May '18

01 May '18

Sometimes, a language extension idea could benefit from some community discussion before it's ready for a formal proposal. I'd like to propose that we open up the GitHub issues tracker for ghc-proposals to serve as a place to discuss pre-proposal ideas. Once those discussions converge on one or a few specific plans, someone can write a proper proposal.

4 5

Testsuite wobbles
by Simon Peyton Jones 01 May '18

01 May '18

Friends I'm seeing test-suite wobbles like these: Unexpected failures: /tmp/ghctest-9ez8i8lx/test spaces/./ghci.debugger/scripts/break006.run break006 [bad stdout] (ghci) /tmp/ghctest-9ez8i8lx/test spaces/./ghci.debugger/scripts/hist001.run hist001 [bad stdout] (ghci) /tmp/ghctest-9ez8i8lx/test spaces/./ghci.debugger/scripts/hist002.run hist002 [bad stdout] (ghci) /tmp/ghctest-9ez8i8lx/test spaces/./profiling/should_run/scc001.run scc001 [bad profile] (profasm) It turns out that they are all variations in the order of output, e.g. --- ./scripts/break006.run/break006.stdout.normalised 2018-05-01 13:20:13.297808002 +0100 +++ ./scripts/break006.run/break006.run.stdout.normalised 2018-05-01 13:20:13.297808002 +0100 @@ -4,14 +4,14 @@ x :: Integer = 1 xs :: [Integer] = [2,3] xs :: [Integer] = [2,3] -f :: Integer -> a = _ x :: Integer = 1 +f :: Integer -> a = _ _result :: [a] = _ y = (_t1::a) y = 2 xs :: [Integer] = [2,3] -f :: Integer -> Integer = _ x :: Integer = 1 +f :: Integer -> Integer = _ _result :: [Integer] = _ y :: Integer = 2 _t1 :: Integer = 2 *** unexpected failure for break006(ghci) I've seen this go to and fro recently. It looks as if the output is not deterministic somehow. (The order in which the bindings are printed is immaterial.) Does this happen for others? Does the master CI build show this problem? I don't know whether to commit these changes, because I don't know if it affects anyone else. And it's certainly tiresome for me. Any ideas? Simon

1 0

[ANNOUNCE] GHC 8.4.2 released
by Ben Gamari 01 May '18

01 May '18

Hello everyone, The GHC team is pleased to announce the availability of GHC 8.4.2. The source distribution, binary distributions, and documentation for this release are available at https://downloads.haskell.org/~ghc/8.4.2 This release is a bug-fix release, fixing numerous regressions and bugs present in GHC 8.4.1. These include: * A regression resulting in some uses of `Control.Exception.evaluate` to be inappropriately optimised away (see #13930) * A regression resulting in segmentation faults of programs compiled with profiling (#14705) * A bug causing runtime system panics while running programs with retainer profiling (#14947) * The configure scripts now accepts a `--disable-dtrace` option, again allowing GHC to be bootstrapped on FreeBSD (#15040) * The version number of the `base` package has been bumped to 4.11.1.0 to reflect the addition of the `GHC.IO.FixIOException` type. This interface was added in 8.4.1 but the version bump was missed due to an oversight. * Support for DWARF debug information has been significantly improved (#14894, #14779) A more thorough list of the changes in this release can be found in the release notes, https://downloads.haskell.org/~ghc/8.4.2/docs/html/users_guide/8.4.2-notes.… Thanks to everyone who has contributed to developing, documenting, and testing this release! As always, let us know if you encounter trouble. How to get it ~~~~~~~~~~~~~ The easy way is to go to the web page, which should be self-explanatory: http://www.haskell.org/ghc/ We supply binary builds in the native package format for many platforms, and the source distribution is available from the same place. Packages will appear as they are built - if the package for your system isn't available yet, please try again later. Background ~~~~~~~~~~ Haskell is a standard lazy functional programming language. 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. A wide variety of Haskell related resources (tutorials, libraries, specifications, documentation, compilers, interpreters, references, contact information, links to research groups) are available from the Haskell home page (see below). On-line GHC-related resources ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Relevant URLs on the World-Wide Web: GHC home page http://www.haskell.org/ghc/ GHC developers' home page http://ghc.haskell.org/trac/ghc/ Haskell home page http://www.haskell.org/ Supported Platforms ~~~~~~~~~~~~~~~~~~~ The list of platforms we support, and the people responsible for them, is here: http://ghc.haskell.org/trac/ghc/wiki/Contributors 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 accessing our source code repository, and getting started with hacking on GHC, are available from the GHC's developer's site run by Trac: http://ghc.haskell.org/trac/ghc/ Mailing lists ~~~~~~~~~~~~~ We run mailing lists for GHC users and bug reports; 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-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 #haskell on IRC, 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

5 5