- ghc-devs - Haskell.org

[ANNOUNCE] GHC 8.2.1 release candidate 1
by Ben Gamari 03 Oct '17

03 Oct '17

Hello everyone, The GHC team is very pleased to announce the first candidate of the 8.2.1 release of the Glasgow Haskell Compiler. Source and binary distributions are available at https://downloads.haskell.org/~ghc/8.2.1-rc1/ This is the first of a few release candidates leading up the final 8.2.1 release. This release will feature, * A new type-indexed Typeable implementation * The long awaited Backpack * Deriving strategies for disambiguating DeriveAnyClass, GeneralizedNewtypeDeriving, and stock mechanisms * Overloaded record fields * Improved compiler performance * Better code generation through more robust tracking of join points * Compact regions for more efficient garbage collection and serialization * Better support for machines with non-uniform memory architectures * More robust support for levity (e.g. RuntimeRep) polymorphism * A simple interface for streaming eventlog data from live processes * Further refinement of DWARF support Unfortunately there are still a few known issues in this release, including a few compiler panics (#13233, #13509) and a memory leak in the simplifier (#13426) which may adversely affect heap sizes and compilation time for some modules. This memory leak unfortunately made it impossible to provide a 32-bit Windows distribution for this candidate; this will be resolved in -rc2. As always, please let us know if you have difficulty. Thanks to everyone who has contributed to this release! Happy testing, - Ben

5 15

GHC Threads affinity
by Michael Baikov 03 Oct '17

03 Oct '17

Greetings Currently GHC supports two kinds of threads - pinned to a specific capability (bound threads) and those it can migrate between any capabilities (unbound threads). For purposes of achieving lower latency in Haskell applications it would be nice to have something in between - threads GHC can migrate but within a certain subset of capabilities only. I'm developing a program that contains several kinds of threads - those that do little work and sensitive to latency and those that can spend more CPU time and less latency sensitive. I looked into several cases of increased latency in those sensitive threads (using GHC eventlog) and in all cases sensitive threads were waiting for non-sensitive threads to finish working. I was able to reduce worst case latency by factor of 10 by pinning all the threads in the program to specific capability but manually distributing threads (60+ of them) between capabilities (several different machines with different numbers of cores available) seems very fragile. World stopping GC is still a problem but at least in my case is much less frequently so. It would be nice to be able to allow GHC runtime to migrate a thread between a subset of capabilities using interface similar to this one: -- creates a thread that is allowed to migrate between capabilities according to following rule: ghc is allowed to run this thread on Nth capability if Nth `mod` size_of_word bit in mask is set. forkOn' :: Int -> IO () -> IO ThreadId forkOn' mask act = undefined This should allow to define up to 64 (32) distinct groups and allow user to break down their threads into bigger number of potentially intersecting groups by specifying things like capability 0 does latency sensitive things, caps 1..5 - less sensitive things, caps 6-7 bulk things. Anything obvious I'm missing? Any recommendations to how to implement this?

6 10

Proposal: Allow passing in linkable files from TH
by Alec Theriault 03 Oct '17

03 Oct '17

Hello, I have a TH feature request and I'd like to hear what people have to say about it. Here is the [Trac ticket][0]. I'm new to this, so if anything here sounds completely wrong, it probably is. TH currently lets you add in arbitrary C (and other languages usually supported by C compilers). That code is compiled for you and then linked in automatically. This is what makes the [`inline-c`][1] package possible. I'm proposing to extend this so that TH lets you pass in something that is already compiled and ready to be linked. The idea is that this would allow TH-level FFI to any language that can produce object files or libraries that have the C ABI. My immediate use-case is to make an `inline-rust` package where one can write Rust code straight into a Haskell quasiquote. In terms of a concrete API change, it would suffice to 1. add a `LangLinkable` constructor to the `ForeignSrcLang` data type 2. add a `qAddForeignFilePath :: ForeignSrcLang -> FilePath -> m ()` method to `Quasi` The code change is pretty small too (60 additions, 30 deletions) since the `addForeignFile` machinery is fully reusable (we just have to skip past the phase of calling the C compiler). # Pros: * Better TH FFI support * Simple to implement # Cons: * The proposed API is suboptimal: it allows for `qAddForeignFile LangLinkable "..."` although that that pretty much never makes sense since the thing being linked is not subject to `String` encoding Any thoughts? Alec [0]: https://ghc.haskell.org/trac/ghc/ticket/14298 [1]: https://hackage.haskell.org/package/inline-c

2 1

Re: [ANNOUNCE] GHC 8.2.2 release candidate 1
by Ryan Scott 02 Oct '17

02 Oct '17

I did a smoke test of Stackage Nightly's libraries [1] this afternoon using GHC 8.2.2. Only two libraries failed to build: extensible-0.4.5 and protolude-0.2, due to a change where type signatures like `foo :: forall k. forall (a :: k). ...` no longer compile without enabling TypeInType. I only mention this because the migration guide for 8.4 [2] currently gives the impression that this TypeInType change won't land until GHC 8.4. This doesn't appear to be case, though! Ryan S. ----- [1] https://www.stackage.org/nightly-2017-09-29 [2] https://ghc.haskell.org/trac/ghc/wiki/Migration/8.4?version=7#TypeInTypeisp…

3 9

Disabling Travis?
by Joachim Breitner 02 Oct '17

02 Oct '17

Hi, I wasn’t looking for a while I notice that the travis CI build of GHC has not been succeeding for two months, partly because build time exceeded the already much extended limits we have, partly because support for booting with 7.10 was dropped, but the .travis file was not used. A CI system that is not normally succeeding is pretty pointless, and will only confuse people who submit pull requests over GitHub who see failures. So if noone complains now I will soon disable building on Travis. Greetings, Joachim -- Joachim “nomeata” Breitner mail(a)joachim-breitner.de https://www.joachim-breitner.de/

3 14

Unifying verbosity flags (ticket #12822)
by Sergey Bykov 02 Oct '17

02 Oct '17

Hi, I'm working with the #12822 task, which is a refactoring for the verbosity flag. It should be reimplemented in a way, similar to the 'optimization' flag. After studying the codebase, specifically *optLevelFlags*, I'm stuck with the following questions: 1. Should I add a new data 'VerbosityFlag' similar to GeneralFlag, DumpFlag, etc or should I extend any of existing data types? 2. How to determine a set of verbosity options to implement? Is grepping through all the codebase and adding corresponding options a good approach? Thanks! -- Best regards, Sergey Bykov

2 2

RTS changes affect runtime when they shouldn’t
by Joachim Breitner 30 Sep '17

30 Sep '17

Hi, while keeping an eye on the performance numbers, I notice a pattern where basically any change to the rts makes some benchmarks go up or down by a significant percentage. Recent example: https://git.haskell.org/ghc.git/commitdiff/0aba999f60babe6878a1fd2cc8410139… which exposed an additional secure modular power function in integer (and should really not affect any of our test cases) causes these changes: Benchmark name prev change now nofib/time/FS 0.434 - 4.61% 0.414 seco nds nofib/time/VS 0.369 + 15.45% 0.426 seco nds nofib/time/scs 0.411 - 4.62% 0.392 sec onds https://perf.haskell.org/ghc/#revision/0aba999f60babe6878a1fd2cc8410139 358cad16 The new effBench benchmarks (FS, VS) are particularly often affected, but also old friends like scs, lambda, integer… In a case like this I can see that the effect is spurious, but it really limits our ability to properly evaluate changes to the compiler – in some cases it makes us cheer about improvements that are not really there, in other cases it makes us hunt for ghosts. Does anyone have a solid idea what is causing these differences? Are they specific to the builder for perf.haskell.org, or do you observe them as well? And what can we do here? For the measurements in my thesis I switched to measuring instruction counts (using valgrind) instead. These are much more stable, requires only a single NoFibRun, and the machine does not have to be otherwise quiet. Should I start using these on perf.haskell.org? Or would we lose too much by not tracking actual running times any more? Greetings, Joachim -- Joachim Breitner mail(a)joachim-breitner.de http://www.joachim-breitner.de/

5 13

Underscore in binary literals
by Takenobu Tani 30 Sep '17

30 Sep '17

Dear devs, GHC's BinaryLiterals extension is useful. (For example, x = 0b110111000101) Is it difficult to include underscore(_) in the format like Verilog-HDL[1] ? (For example, x = 0b1101_1100_0101) [1]: https://inst.eecs.berkeley.edu/~cs150/fa06/Labs/verilog-ieee.pdf#page=20 Regards, Takenobu

6 8

Updating Phabricator
by Ben Gamari 29 Sep '17

29 Sep '17

Hello everyone, It seems that Harbormaster is acting up so I'm going to take this opportunity to upgrade Phabricator while fixing it. I expect this will take about 30 minutes. I'll wait an hour begin beginning to allow people to finish their work, however. Let me know if this would cause a great inconvenience. Cheers, - Ben

1 1

Re: cvs-ghc archives
by Gershom B 28 Sep '17

28 Sep '17

You can also get cvs-ghc specific mail at: https://www.mail-archive.com/cvs-ghc=40haskell.org/ Note: We still have the old list archives. It looks like the list itself = was deleted on mailman when the old cvs- lists were decomissioned so as t= o prevent confusion. I think they=E2=80=99ve been inaccessable for years = so it doesn=E2=80=99t seem like its a pressing concern=3F That said, we c= an look into hosting the archives with a redirect on archives.haskell.org= . Cheers, Gershom On September 28, 2017 at 8:32:26 AM, ghc-devs-request=40haskell.org (ghc-= devs-request=40haskell.org) wrote: > Send ghc-devs mailing list submissions to > ghc-devs=40haskell.org > =20 > To subscribe or unsubscribe via the World Wide Web, visit > http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs > or, via email, send a message with subject or body 'help' to > ghc-devs-request=40haskell.org > =20 > You can reach the person managing the list at > ghc-devs-owner=40haskell.org > =20 > When replying, please edit your Subject line so it is more specific > than =22Re: Contents of ghc-devs digest...=22 > =20 > =20 > Today's Topics: > =20 > 1. Re: cvs-ghc archives (Bartosz Nitka) > =20 > =20 > ---------------------------------------------------------------------- > =20 > Message: 1 > Date: Thu, 28 Sep 2017 11:07:43 +0100 > =46rom: Bartosz Nitka =20 > To: ghc-devs Devs =20 > Subject: Re: cvs-ghc archives > Message-ID: > =20 > Content-Type: text/plain; charset=3D=22UT=46-8=22 > =20 > I think someone has archived the data for us here > https://www.mail-archive.com/cvs-all=40haskell.org/. > I don't have a good way to map the old links to new ones, though. > =20 > 2017-09-28 11:01 GMT+01:00 Bartosz Nitka : > > Hello, > > > > I was reading a comment that pointed to > > http://www.haskell.org/pipermail/cvs-ghc/2007-September/038458.html. > > It's a dead link and I couldn't find any place where cvs-ghc is archi= ved. > > I've tried webarchive. > > > > Looks like Simon had a simliar problem 4 years ago: > > http://ghc-devs.haskell.narkive.com/3dIDGsHy/cvs-ghc-archives > > > > Is the data forever lost=3F > > > > There aren't actually that many references in the source tree: > > ./libraries/base/configure.ac:=23 See > > http://www.haskell.org/pipermail/cvs-ghc/2011-September/065980.html > > ./libraries/base/configure:=23 See > > http://www.haskell.org/pipermail/cvs-ghc/2011-September/065980.html > > ./libraries/base/autom4te.cache/output.0:=23 See > > http://www.haskell.org/pipermail/cvs-ghc/2011-September/065980.html > > ./rts/linker/Elf.c: * See thread > > http://www.haskell.org/pipermail/cvs-ghc/2007-September/038458.html > > ./rts/Linker.c: // see > > http://www.haskell.org/pipermail/cvs-ghc/2007-September/038570.html > > ./testsuite/tests/typecheck/should=5Ffail/tcfail201.hs:-- > > http://www.haskell.org/pipermail/cvs-ghc/2008-June/043173.html > > > > I'm happy to remove them if that's what we want to do. > > > > Coincidentally cvs-ghc=40haskell.org appears 58 times in the GHC sour= ce > > tree. Do we want to keep using it=3F > > > > Thanks, > > Bartosz > =20 > =20 > ------------------------------ > =20 > Subject: Digest =46ooter > =20 > =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F= =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F > ghc-devs mailing list > ghc-devs=40haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs > =20 > =20 > ------------------------------ > =20 > End of ghc-devs Digest, Vol 169, Issue 60 > ***************************************** > =20

1 0