Well, its a feature freeze, not a release, so I imagine bugs can still be fixed as they come up.
Alan On Fri, Dec 4, 2015 at 4:04 PM, Luite Stegeman <stege...@gmail.com> wrote: > Oh I don't want to block anything from being merged, if anything I'd like to > see it get added and actually use the new intrastructure. Unfortunately it > looks like I already need some hook changes to make GHCJSi work reasonably > well, without having to copy/paste huge loads of GHC code into GHCJS, but > it'd feel a bit silly to add hooks for something where a proper solution is > already in place. So I would like to try to update GHCJS to use this, if > there's a good chance that this gets merged. > > I just hope that I have enough time to do all of this and verify that things > work before the freeze. It's a bit unfortunate that I can only be really > sure when I actually have things running, and there's always a lot of work > involved in updating GHCJS and its dependencies to work with GHC HEAD, with > many big changes always landing right before the freeze. > > cheers, > > Luite > > On Thu, Dec 3, 2015 at 5:50 PM Simon Marlow <marlo...@gmail.com> wrote: >> >> On 03/12/2015 13:50, Ben Gamari wrote: >> > Luite Stegeman <stege...@gmail.com> writes: >> > >> >> Is Simon's remote GHCi patch planned to go in before the fork? I'm >> >> still >> >> working on upgrading GHCJS to work with the master branch, but I >> >> haven't >> >> quite finished yet. This change would clearly require some >> >> restructuring of >> >> GHCJSi and Template Haskell in GHCJS, and I'm not sure if a week is >> >> enough >> >> to test the changes. Also the recent removal of boot file merging >> >> reintroduces a problem with that I'm not sure can be fixed without >> >> adding a >> >> new hook. >> >> >> > Simon, what do you think about this? >> > >> > I'm a bit worried that this patch is quite late and breaks users like >> > Luite. Nevertheless, I am willing to hear arguments for merging. >> >> It doesn't have to go in, but I think it would be nice. I'd like to >> have it out for at least one major release in a disabled-by-default >> state so that we can experiment with it. But as far as my particular >> goals for this feature are concerned, I'll backport the patch to 7.10 >> and use it in our local GHC build at Facebook regardless. >> >> Luite - the hooks you use are still intact, so I don't think you have to >> do any major restructuring in GHCJS until you're ready. What I've >> implemented will almost certainly need work to be usable or shareable >> with GHCJS, and it's not clear to me exactly what the changes will look >> like, but for the time being I thought the changes should not impact >> GHCJS's implementation of TH & GHCi. I could be wrong though, if so >> please let me know how it breaks you. >> >> Cheers, >> Simon >> >> >> What's the policy on adding hooks or GHC API tweaks after the freeze? >> >> >> > We'll need to work that out when we get to that point. It largely >> > depends upon how confined and "safe" a change appears to be. That being >> > said, given how much other churn has happened for this release, I don't >> > think we want to be sloppy with merge discipline this time around. >> > >> > Austin, what do you think? >> > >> > Cheers, >> > >> > - Ben >> > > > > _______________________________________________ > 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
