- ghc-devs - Haskell.org

Large tuple strategy
by Reid Barton 05 Jan '17

05 Jan '17

Hi all, https://phabricator.haskell.org/D2899 proposes adding Generic instances for large tuples (up to size 62). Currently GHC only provides Generic instances for tuples of size up to 7. There's been some concern about the effect that all these instances will have on compilation time for anyone who uses Generics, even if they don't actually use the new instances. There was a suggestion to move these new instances to a separate module, but as these instances would then be orphans, I believe GHC would have to read the interface file for that module anyways once Generic comes into scope, which would defeat the purpose of the split. It occurred to me that rather than moving just these instances to a new module, we could move the large tuples themselves to a new module Data.LargeTuple and put the instances there. The Prelude would reexport the large tuples, so there would be no user-visible change. According to my experiments, GHC should never have to read the Data.LargeTuple interface file unless a program actually mentions a large tuple type, which is presumably rare. We could then also extend the existing instances for Eq, Show, etc., which are currently only provided through 15-tuples. A nontrivial aspect of this change is that tuples are wired-in types, and they currently all live in the ghc-prim package. I'm actually not sure why they need to be wired-in rather than ordinary types with a funny-looking name. In any case I need to look into this further, but the difficulties here don't seem to be insurmountable. Does this seem like a reasonable plan? Anything important I have missed? Regards, Reid Barton

3 3

Contributing Examples to the Documentation
by Sunjay Varma 05 Jan '17

05 Jan '17

Hi, I'm considering contributing examples to the documentation. I wanted to start with something like Data.List because it is one of the modules I end up using the most. I think a few examples for each function would help users understand them better. I find myself referring back to books like learn you a haskell because I don't remember exactly what I'm supposed to do with a function. Doing one module seems like a good start and hopefully we can have some other people begin to add their own examples too. Is this a worthwhile contribution? I haven't contributed before and so I think it's prudent to ask before I add something no one wants. Are there any examples of modules with good code examples that I should use as a reference? I want to include both the code and output of the example as if the user was running ghci. Are there any guidelines for contributing documentation? When I say Data.List, I really mean Data.Foldable and Data.Traversable since that is where the functions are actually implemented. I noticed the GitHub repo said that Pull Requests were okay for easy to review documentation changes. Can I open a pull request there or should I follow another process? Please let me know when you can. I don't have an exact timeline for when this will be done, but hopefully I'll have something in the next few weeks. I don't anticipate that it will take long once I sit down to do it. I've always complained about a lack of examples and never done anything about it. Hopefully I can practice what I preach and contribute some in order to make the documentation a little better for everyone. Thanks for helping to make this language so great! Sunjay

6 9

FW: Lightweight Concurrency Branch
by Simon Peyton Jones 04 Jan '17

04 Jan '17

Reply from KC… see below. Simon From: KC Sivaramakrishnan [mailto:sk826@cam.ac.uk] Sent: 04 January 2017 11:29 To: Simon Peyton Jones <simonpj(a)microsoft.com> Cc: Daniel Bennet <daniel.bennet83(a)gmail.com>; ghc-devs(a)haskell.org; KC (sk826(a)hermes.cam.ac.uk) <sk826(a)hermes.cam.ac.uk> Subject: Re: Lightweight Concurrency Branch Hi Simon, David, Indeed as Simon mentioned it, the work was never finished. The implementation is(was) at a stage where we can run some small non-trivial benchmarks (Section 7 of the JFP paper). The interactions with FFI, MVars, STM, asynchronous exceptions worked well (though we most probably do things a little differently now), until we encountered interaction with blackholes mechanism. The crux of the problem is that the blackholing mechanism interacts with the scheduler and if the scheduler functionality itself is written in Haskell, then we have the potential for a deadlock. Some of the details are presented in Section 6.5, but we never got around to a clean solution that I could get working properly. Hence the reason for not formalizing it completely in the paper, and I am sure there are some edge cases that I hadn't thought about. This is a particularly tricky issue, and the current design unfortunately does not lend itself to a clean solution. Although the asynchronous exception mechanism interaction was not formalized, it works well and passes the tests. Not much effort was put in to make the implementation go particularly fast. While the performance was comparable on average, but varied quite a bit on edge cases; some of the results in the paper show this. If one were to revive the project, I would suggest starting from the design, using the existing code as a prototype, but write code from scratch; pleasantly there isn't much new code in this branch. The project does need substantial amount of work to make it upstream with the newer RTS mechanisms. I am very happy to provide more details and eager to assist with the work, but my time commitments mean that I cannot lead this effort. Kind Regards, KC On Wed, Jan 4, 2017 at 10:38 AM, Simon Peyton Jones <simonpj(a)microsoft.com<mailto:simonpj@microsoft.com>> wrote: David KC never finished work on this stuff. I’m copying him because I’m sure he’d be happy to help. KC: can you summarise where you left it? I think it’s very interesting work, and has the potential to make GHC’s RTS much more malleable, by moving more of it into Haskell libraries instead of deeply-magic C code. But it’s not easy, because we are reluctant to lose performance, and because there are interactions with STM, weak pointers, foreign function calls, etc. I think it’d require a bit of commitment to make a go of it. Simon From: ghc-devs [mailto:ghc-devs-bounces@haskell.org<mailto:ghc-devs-bounces@haskell.org>] On Behalf Of Daniel Bennet Sent: 28 December 2016 17:23 To: ghc-devs(a)haskell.org<mailto:ghc-devs@haskell.org> Subject: Lightweight Concurrency Branch The lightweight concurrency branch is highly interesting and relevant to my interests, however, the ghc-lwc2 branch hasn't been updated in several years even though it's listed as an active branch at https://ghc.haskell.org/trac/ghc/wiki/ActiveBranches The wiki page for the work hasn't been updated in almost two years either, https://ghc.haskell.org/trac/ghc/wiki/LightweightConcurrency Relevant papers: Composable Scheduler Activations for Haskell (2014) https://timharris.uk/papers/2014-composable-tr.pdf<https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Ftimharris.…> Composable Scheduler Activations for Haskell (2016) http://kcsrk.info/papers/schedact_jfp16.pdf<https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fkcsrk.info%…> What remains for integrating this branch into GHC?

2 1

Lightweight Concurrency Branch
by Daniel Bennet 04 Jan '17

04 Jan '17

The lightweight concurrency branch is highly interesting and relevant to my interests, however, the ghc-lwc2 branch hasn't been updated in several years even though it's listed as an active branch at https://ghc.haskell.org/trac/ghc/wiki/ActiveBranches The wiki page for the work hasn't been updated in almost two years either, https://ghc.haskell.org/trac/ghc/wiki/LightweightConcurrency Relevant papers: Composable Scheduler Activations for Haskell (2014) https://timharris.uk/papers/2014-composable-tr.pdf Composable Scheduler Activations for Haskell (2016) http://kcsrk.info/papers/schedact_jfp16.pdf What remains for integrating this branch into GHC?

2 1

[ANNOUNCE] Formation of the initial GHC Steering Committee
by Ben Gamari 04 Jan '17

04 Jan '17

Dear Haskell community, Over the past months we have discussed changes to GHC's process for collecting, discussing, and considering new language extensions, compiler features, and the like. Happily, we are now ready to move forward with our new proposal process. Towards this end, we have formed the GHC Steering Committee which will be responsible for evaluating the proposals that run through the process. The committee consists of the following members (with GitHub user names given parenthetically), * Chris Allen (@bitemyapp) * Joachim Breitner (@nomeata) * Manuel M T Chakravarty (@mchakravarty) * Iavor Diatchki (@yav) * Atze Dijkstra (@atzedijkstra) * Richard Eisenberg (@goldfirere) * Ben Gamari (@bgamari) * Simon Marlow (@simonmar) * Ryan Newton (@rrnewton) * Simon Peyton-Jones (@simonpj) The body will be chaired jointly by Simon Marlow and Simon Peyton-Jones. Since the ghc-proposals repository was created, it has accumulated nearly thirty pull requests describing a variety of compelling changes. We will consider these proposals to be at the beginning of their four-week discussion period. The goal of this discussion is to find and eliminate weaknesses of the proposal. The final proposal should address all valid points raised in the discussion. When you believe the proposal has converged, bring it to the steering committee and summarize the discussion in a pull request comment. If you would like to contribute a new proposal, please refer to the directions given in the ghc-proposals' repository README [1] and proposal submission guidelines [2]. Cheers, - Ben, on behalf of the GHC Steering Committee [1] https://github.com/ghc-proposals/ghc-proposals [2] https://github.com/ghc-proposals/ghc-proposals/blob/master/proposal-submiss…

1 0

[ANNOUNCE] GHC 8.0.2 release candidate 2
by Ben Gamari 28 Dec '16

28 Dec '16

Hello everyone, The GHC team is happy to announce the second candiate of 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-rc2/ This is the second and likely final release candidate leading up the 8.0.2 release. This release will fix a number of bugs found in 8.0.1 including, * Interface file build determinism (#4012). * Compatibility with macOS Sierra and GCC compilers which compile position-independent executables by default * Runtime linker fixes on Windows (see #12797) * A compiler bug which resulted in undefined reference errors while compiling some packages (see #12076) * Compatability with systems which use the gold linker * 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. This release candidate fixes a number of issues present in -rc1, * #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. If all goes well we should have a final 8.0.2 release out shortly after the new year. As always, let us know if you encounter trouble. Thanks to everyone who has contributed so far! Happy testing, - Ben [1] https://ghc.haskell.org/trac/ghc/query?status=closed&milestone=8.0.2&col=id…

4 4

Can the definition of alwaysSucceeds be streamlined?
by David Feuer 27 Dec '16

27 Dec '16

Currently, `GHC.Conc` has alwaysSucceeds :: STM a -> STM () alwaysSucceeds i = do ( i >> retry ) `orElse` ( return () ) checkInv i If I understand what's going on here (which I may not), I think this should be equivalent to alwaysSucceeds i = (i >> retry) `orElse` checkInv i David Feuer

1 0

Re: [Haskell-cafe] many haskell's mails are detected as spam on gmail
by Takenobu Tani 25 Dec '16

25 Dec '16

Hi Arian , Thank you for information. At least from about 11th December, detection of the spam have been increasing. I'll report them after I understand it. Regards, Takenobu 2016-12-25 18:34 GMT+09:00 Arian van Putten <aeroboy94(a)gmail.com>: > If I recall correctly it's being worked on. There is a plan to harden the > haskell.org domain during the holidays by introducing DKIM and setting up > DMARC. There is a thread in haskell-cafe titled "[Haskell-cafe] Work on > mail.haskell.org beginning, please report any problems" with more info. > > On Sun, 25 Dec 2016, 09:35 Takenobu Tani, <takenobu.hs(a)gmail.com> wrote: > > Hi, > > I'm using gmail. > Recently, many haskell's mails are detected as spam on gmail. > (ghc-devs, haskell-cafe, ghc-commit, ...) > > Does anyone know why? > Do you know the workaround? > > Regards, > Takenobu > > _______________________________________________ > Haskell-Cafe mailing list > To (un)subscribe, modify options or view archives go to: > http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe > Only members subscribed via the mailman list are allowed to post. > >

1 0

I have Aphronted Phab
by Richard Eisenberg 24 Dec '16

24 Dec '16

Hi Austin, Ben, In trying to write a comment on Phab, I got this: Unhandled Exception ("AphrontCSRFException") You are trying to save some data to Phabricator, but the request your browser made included an incorrect token. Reload the page and try again. You may need to clear your cookies. This was a Web request. This request had an invalid CSRF token. I followed the suggestions, and even tried a different browser (one I never use), to no avail. This still may very well be my fault, but it seems something is awry somewhere. Do you have any help you can offer? Thanks! Richard

3 2

Re: [GHC] #13005: Mac OSX uses MAP_ANON in place of MAP_ANONYMOUS
by Gracjan Polak 24 Dec '16

24 Dec '16

No, `master`. 2016-12-23 23:53 GMT+01:00 GHC <ghc-devs(a)haskell.org>: > #13005: Mac OSX uses MAP_ANON in place of MAP_ANONYMOUS > -------------------------------------+---------------------- > --------------- > Reporter: gracjan | Owner: > Type: bug | Status: merge > Priority: high | Milestone: 8.0.2 > Component: Compiler | Version: 8.0.1 > (Linking) | > Resolution: | Keywords: > Operating System: MacOS X | Architecture: > Type of failure: Building GHC | Unknown/Multiple > failed | Test Case: > Blocked By: | Blocking: > Related Tickets: | Differential Rev(s): Phab:D2881 > Wiki Page: | > -------------------------------------+---------------------- > --------------- > Changes (by bgamari): > > * status: patch => merge > * milestone: => 8.0.2 > > > Comment: > > Did you really observe this on 8.0.1, gracjan? > > -- > Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/13005#comment:5> > GHC <http://www.haskell.org/ghc/> > The Glasgow Haskell Compiler >

1 0