Re: Tracking Progress of #7353 (New Windows IO Manager)
Hi Travis, The current MR with my WIP is at https://gitlab.haskell.org/ghc/ghc/merge_requests/1224 This should build without a problem (on Windows, haven't sorted the Linux build failures yet). The threaded version passes the testsuite (i.e. -threaded +RTS --io-manager=native) but the non-threaded version has proven tricky to support correctly. That one still has a deadlock that I am debugging (though I have made significant progress since I last updated that MR). I will push the updated code this weekend. Though I'm afraid that based on it not getting any review of the design so far and my current work commitments I won't be able to get this done for GHC 8.10. So I will punt it to GHC 8.12. The MR contains a list of TODOs in case you're wondering what's left on it. Thanks, Tamar On Tue, Sep 24, 2019 at 11:39 PM Travis Whitaker wrote: > Hello Haskell friends, > > Even though I no longer work at a Windows shop, I've been watching > https://gitlab.haskell.org/ghc/ghc/issues/7353 with great interest. Last > I knew Tamar Christina was heroically hacking away on a new IO manager for > Windows. > > Although my low-level Windows knowledge is likely insufficient for me to > contribute significantly, I'd be very interested in testing the new IO > manager and helping with debugging in any way I can. How might one go about > building a GHC with this new Windows IO manager? > > Thanks, as always, for all your hard work, > > Travis Whitaker > ___ > ghc-devs mailing list > ghc-devs@haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs > ___ ghc-devs mailing list ghc-devs@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
Tracking Progress of #7353 (New Windows IO Manager)
Hello Haskell friends, Even though I no longer work at a Windows shop, I've been watching https://gitlab.haskell.org/ghc/ghc/issues/7353 with great interest. Last I knew Tamar Christina was heroically hacking away on a new IO manager for Windows. Although my low-level Windows knowledge is likely insufficient for me to contribute significantly, I'd be very interested in testing the new IO manager and helping with debugging in any way I can. How might one go about building a GHC with this new Windows IO manager? Thanks, as always, for all your hard work, Travis Whitaker ___ ghc-devs mailing list ghc-devs@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
Re: What does a milestone mean?
Matthew Pickering writes: > Hi, > > It seems that basically every new issues gets triaged with the 8.10.1 > milestone, what does this mean? > > It seems like a lot of the issue's won't get fixed for 8.10, or at any > foreseeable point in the future which dilutes the milestoning. > > Therefore I don't think we should assign a certain milestone to a > ticket unless either > > 1. The issue is considered necessary to fix for that milestone (ie, a > regression) > 2. Someone is planning to work on the ticket for that milestone (ie, a > feature/improvement) > I generally set the milestone of new tickets that I think could plausibly be handled before the next merge window to the next major release. I then go through the list and bump tickets to the next milestone prior to forking. This is an extension of our treatment of milestones under Trac, where the field would IIRC default to the next major release and perform mass re-milestonings prior to release, eventually de-milestoning a ticket if it is remilestoned several times with no visible progress. This approach has the nice property that it ensures that each ticket is looked at periodically. On the other hand, it also means that the next release milestone is quite cluttered. I wouldn't be opposed to reconsidering this policy. Cheers, - Ben signature.asc Description: PGP signature ___ ghc-devs mailing list ghc-devs@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
What does a milestone mean?
Hi, It seems that basically every new issues gets triaged with the 8.10.1 milestone, what does this mean? It seems like a lot of the issue's won't get fixed for 8.10, or at any foreseeable point in the future which dilutes the milestoning. Therefore I don't think we should assign a certain milestone to a ticket unless either 1. The issue is considered necessary to fix for that milestone (ie, a regression) 2. Someone is planning to work on the ticket for that milestone (ie, a feature/improvement) Then the milestone actually has some meaning. Cheers, Matt ___ ghc-devs mailing list ghc-devs@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
Filtering GitLab mentions
Hi everyone, During a discussion on procedural matters earlier today it was (yet again) noted that GitLab notification emails are quite chatty and consequently it is easy to lose the signal in the noise. However, during this discussion we also realized that much of the issue can be mitigated with a simple email filter to identify explicit @-mentions. I find that: from:gitlab.haskell.org and @bgamari and header:X-GitLab-Discussion-Id isolates emails arising from @-mentions fairly effetively. If your MUA doesn't support filtering by arbitrary headers you can replace the "header" predicate with simply a mention of the word "commented". If you are active on GitLab I would encourage you to setup such a filter; I was surprised by how many comments I had overlooked. Cheers, - Ben signature.asc Description: PGP signature ___ ghc-devs mailing list ghc-devs@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
