October 2014 - ghc-devs

Re: Making GHCi awesomer?
by George Colpitts 22 Oct '14

22 Oct '14

Along the lines of making GHCi better it would be very nice if we could use SDL, OpenGL etc in GHCi. Is there a characterization of the libraries that we can't use in ghci? As you know this has been a problem for years. Is there an open bug about it? I know there was some hope that dynamic linking in 7.8.3 would fix this. What has been your experience? For some reason I get mail to ghc-devs but can't send mail to the mailing list. Thanks George On Sat, Oct 18, 2014 at 12:48 PM, Christopher Done <chrisdone(a)gmail.com> wrote: > Good evening, > > ... > > For years I’ve been using GHCi as a base and it’s been very reliable > for almost every project I’ve done (the only exceptions are things > like SDL and OpenGL, which are well known to be difficult to load in > GHCi, at least on Linux). I think we’ve built up > a good set of functionality > <https://github.com/haskell/haskell-mode/wiki/Haskell-Interactive-Mode> > purely based on asking GHCi things and getting it to do things. > >

3 2

One-shot semantics in GHC event manager
by Ben Gamari 22 Oct '14

22 Oct '14

In ba2555ef and a6f52b19 one-shot semantics were added to event manager in `base`. If my understanding of this code is correct, in this mode the event manager will use only notify the user of the first event on a registered fd after which point the fd will need to be re-registered to get another notification. It appears this was done to optimize the common case of file I/O where only a single event is needed This change lead to a regression[1] in Bas van Dijk's usb library under GHC 7.8. usb's use of the event manager requires that all events on an fd are reported until the fd is registered or else hardware events are lost. I'm a bit perplexed as to why the change was made in the way that it was. Making one-shot a event-manager-wide attribute seems to add a fair bit of complexity to the subsystem while breaking backwards compatibility with library code. Going forward library authors now need to worry about whether the system event manager is one-shot or not. Not only is this platform dependent but it seems that there is no way for a user to determine which semantics the system event handler uses. Is there a reason why one-shot wasn't exported as a per-fd attribute instead of per-manager? Might it be possible to back out this change and instead add a variant of `registerFd` which exposes one-shot semantics? Cheers, - Ben [1] https://github.com/basvandijk/usb/issues/7

7 41

Warning on tabs by default (#9230) for GHC 7.10
by Austin Seipp 21 Oct '14

21 Oct '14

Hi all, Please see here: https://phabricator.haskell.org/D255 and https://ghc.haskell.org/trac/ghc/ticket/9230 Making tabs warn by default has been requested many times before, and now that the compiler is completely detabbed, this should become possible to enable easily, and we can gradually remove warnings from everything else. Unless someone has huge complaints or this becomes a gigantic bikeshed/review (bike-review), please let me know - I would like this to go in for 7.10. -- Regards, Austin Seipp, Haskell Consultant Well-Typed LLP, http://www.well-typed.com/

4 5

GADTs in implementation of Template Haskell
by Richard Eisenberg 21 Oct '14

21 Oct '14

I'm doing a bunch of bug-fixes / improvements to Template Haskell. Two of these are to fix GHC bugs #8100 (add standalone-deriving support) and #9064 (add `default` method type signature support), both of which introduce new constructors for `Dec`. This got me thinking about `Dec` and the fact that different declaration forms are allowable in different contexts. (For example, datatype declarations are allowable only at the top level, and fixity declarations are allowable anywhere except in instance declarations.) How to encode these restrictions? With types, of course! Thus, I redesigned `Dec` to be a GADT. Having done so, I'm not 100% convinced that this is the right thing to do. I would love feedback on my full, concrete proposal available at https://ghc.haskell.org/trac/ghc/wiki/Design/TemplateHaskellGADTs Is this a change for the better or worse? Feel free either to comment on the wiki page or to this email. Thanks! Richard

2 1

GitHub pull requests
by Richard Eisenberg 21 Oct '14

21 Oct '14

I've just finished reading this: http://www.reddit.com/r/haskell/comments/2hes8m/the_ghc_source_code_contain… For better or worse, I don't read reddit often enough to hold a conversation there, so I'll ask my question here: Is there a way we can turn GitHub pull requests into Phab code reviews? I'm thinking of something like this: - GitHub user ghc-newbie submits a pull request to github.com/ghc/ghc about feature X. - GitHub duly sends out notices to the watch list. - Some bot that is watching the repo receives the notification email that a pull request is submitted. - The bot then pulls down the pull request commit and creates a Phab code review from it. In a perfect world, the code review could be made to look like it comes from ghc-newbie, but I don't think this author-redirection is necessary, and ghc-newbie could be cited in an automatically-included comment. - The bot sends ghc-newbie an email with a link to the code review and something like this: Hi ghc-newbie, We've received your pull request on GitHub. Thanks! It's great that you've contributed. GHC, for a variety of well-considered reasons [1], uses a tool called Phabricator [2] -- not GitHub -- to process contributions. We have taken the liberty of posting your pull request to Phab for further review. You can see it here: <...> If you have modifications to make, please use our Phab workflow, documented in full here [3] and in brief here [4]. Thanks again, and we look forward to reviewing and hopefully merging your patch! GHC [1], [2], [3], [4]: <find appropriate destinations> - We GHC devs then carry on like we have been. If the patch is good, we can merge it without further input from ghc-newbie. If it's no good, and ghc-newbie doesn't get onto Phab, that's their loss. To naive me, this all seems possible -- and relatively easy -- to automate. (Naive = I've never done proper tool integration and am deeply grateful to anyone who actually makes things work.) Is this a good idea? Is this possible? Have I missed anything? Thanks for reading! Richard

12 25

Re: GitHub pull requests
by Merijn Verstraaten 21 Oct '14

21 Oct '14

Whoops, accidentally only addressed Ben instead of the list: On 20 Oct 2014, at 12:13 , Ben Gamari <bgamari.foss(a)gmail.com> wrote: > a) Confusion between Github issue numbers, Trac bug numbers, and > Phabricator identifiers It is possible to disable GitHub issues on a repository, would this not at least solve the issue number confusion? I only figured this out today when trying to *enable* issues on my personal fork of another project. Cheers, Merijn

1 0

Help understanding Specialise.lhs
by David Feuer 20 Oct '14

20 Oct '14

I'm trying to figure out how to address #9701, but I'm having an awfully hard time figuring out what's going on in Specialise.lhs. I think I get the vague general idea of what it's supposed to do, based on the notes, but the actual code is a mystery to me. Is there anyone who might be able to help me get enough of a sense of it to let me do what I need? Many thanks in advance. David Feuer

2 5

GHC Weekly News - 2014/10/20
by Austin Seipp 20 Oct '14

20 Oct '14

Hi *, Here's a weekly news update covering the past several weeks, covering some of our discussions we've had - please let me know if I missed out on something important so I can update the post. https://ghc.haskell.org/trac/ghc/blog/edit/weekly20141020 -- Regards, Austin Seipp, Haskell Consultant Well-Typed LLP, http://www.well-typed.com/

3 4

Re: [GHC] #9628: Add Annotations to the AST to simplify source to source conversions
by Alan & Kim Zimmerman 20 Oct '14

20 Oct '14

For the review process I updated the phabricator summary to capture the current implementation, I will move it on to the wiki too. The ExtraCommas have been removed as unworkable, they are an abandoned point in the design space. The lessons learned are being transferred to Alexander Berntsen for his record syntax extension proposal. I did consider bringing comments in directly, as being a natural part of things, but did not want to confuse the issue too much in one go. It should be possible to capture them in a similar process, and it will definitely help with round tripping. At the moment tooling has to access them via `getRichTokenStream` and then work them in to the correct place. In terms of haddock usage, I would have to discuss with them what they do/need, to find out if this will serve as a replacement. On Mon, Oct 20, 2014 at 9:55 AM, GHC <ghc-devs(a)haskell.org> wrote: > #9628: Add Annotations to the AST to simplify source to source conversions > -------------------------------------+------------------------------------- > Reporter: alanz | Owner: alanz > Type: feature | Status: new > request | Milestone: > Priority: normal | Version: 7.9 > Component: Compiler | Keywords: > Resolution: | Architecture: Unknown/Multiple > Operating System: | Difficulty: Unknown > Unknown/Multiple | Blocked By: > Type of failure: | Related Tickets: > None/Unknown | > Test Case: | > Blocking: | > Differential Revisions: D297 | > -------------------------------------+------------------------------------- > > Comment (by simonpj): > > Well done for making progress. Some thoughts > > * If the patch is ready for review, is [wiki:GhcAstAnnotations] also > fully up to date? Could you move any discussion of alternatives to the > end, under "Other possible design alternatives" so that what remains is > actually a description of the feature you propose, and a sketch of its > implementation? I'm unsure about which bits of the wiki page are rejected > ideas and which are the ones you adopted. > > * Floating around is also `ExtraCommas`. I think the two are somewhat > orthogonal, right? > > * Does your design say where comments are? That is, can you really > round-trip source code? > > In particular, an excellent criterion could be: can you do Haddock this > way? Currently Haddock has a lot of Haddock-specific fields in HsSyn. > Could they all be replaced with annotations in your style? If not, what > would take to make that possible? It would be highly cool; after all, > Haddock may be privileged, but the more we can make it possible for others > to do Haddock-like things without changing GHC itself, the better. > > * You outlined a number of "customers" in an earlier post. Would it be > worth adding them to the wiki page? > > Simon > > -- > Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/9628#comment:30> > GHC <http://www.haskell.org/ghc/> > The Glasgow Haskell Compiler >

1 0

A simpler remove HEAP_ALLOCED check
by Edward Z. Yang 20 Oct '14

20 Oct '14

Hey Simon, I was chatting with Sergio Benitez about GHC's HEAP_ALLOCED woes and he suggested an alternate fix which I'm not sure we have considered. The idea is simple: pre-assign some portion of the virtual address space for the dynamic heap, and then have HEAP_ALLOCED check if it's inside this space. Now, *obviously* this doesn't work for 32-bit (and I assume this is why we didn't go this route), but that's fine: the bitmap we use for 32-bit works pretty great and isn't a bottleneck. For 64-bit, we have a lot more address space to play with. Certainly we have to make sure the system linker never puts segments inside our pre-assigned space, but this seems far more manageable. I'm not particularly wedded to the indirections patchset, so if we can make this work for 64-bit, it seems good enough to me. Edward

1 0