Luite Stegeman 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.

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

My 2c, I would love to see the remote GHCi patch land for 8.0. It is a big change though. Alan On Thu, Dec 3, 2015 at 4:31 PM, Austin Seipp wrote:

On Thu, Dec 3, 2015 at 7:50 AM, Ben Gamari wrote:

...

Luite Stegeman 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.

I think this is one we're best off leaving in HEAD. It's a very large change, and I'm a bit scared of bringing it in right at the finish line, so to speak. I think it might be best to just get it in sometime after the branch IMO...

...

...

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

Hrm. If possible I would like to avoid any breaking changes past the first RC, which has normally been my policy... Generally it's just easier for everyone this way and people typically don't like too many mid-flight changes, once things are in RC-mode.

That said, if it's something game-breaking for, say, GHCJS, I'd be open to it. But we should try to fix it ASAP, not in the middle of February. So it would be best if we could find out what hooks or tweaks we needed Very Soon.

-- Regards,

Austin Seipp, Haskell Consultant Well-Typed LLP, http://www.well-typed.com/ _______________________________________________ ghc-devs mailing list ghc-devs@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

Based on my cursory look at the patch, I think it's unlikely to break existing functionality in subtle ways. So I'm OK with trying to ship it in 8.0 Edward Excerpts from Simon Marlow's message of 2015-12-03 09:50:37 -0800:

On 03/12/2015 13:50, Ben Gamari wrote:

...

Luite Stegeman 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

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 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 wrote:

...

On 03/12/2015 13:50, Ben Gamari wrote:

...

Luite Stegeman 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