7.8 Release Update

older
RE: Question about correct GHC-API...

Austin Seipp

8 Sep 2013 8 Sep '13

7:27 p.m.

Friends, After talking with SPJ, we've decided that the cutoff date for the 7.8 feature window will essentially start on Monday, the 16th. This is the beginning of the week before ICFP. This is a week from tomorrow. Afterwords, I suspect we will cut the 7.8 branch in early October (my notes tentatively say Oct. 9th.) This will give us a few weeks of straight bugfixing. Don't let this scare you too much. We're doing this at the beginning of the week so we have time to sort things out. Bug fixes will of course continuously be welcome until the 7.8 branch. However, for pending features, I'd like a status update. Everyone mentioned below, please reply to clarify anything: * Iavor Diatchki and SPJ are working together on the type-nats-simple branch. I believe this will hopefully land in time. Iavor, SPJ - can you comment here? * Trevor and Iavor are also working on kinds without data. Any word here? * Geoffrey is currently moving, but he says the SIMD work and new template-haskell work will land by the end of this week, which is great. * Patrick Palka has a few loose ends to tie off for the parallel compilation driver. I talked to him today, and after Andreas committed his bugfix to base, I believe everything is now working, with the deadlocks sorted out. Patrick, can you confirm? We can get this merged ASAP if so. * Pedro and Richard - what's the story on propositional equality, etc? This is mentioned on the status page[1] but I'm not sure what else needs to be done. I know Pedro committed the work to make manual Typeable instances an error, which is great. * Luite and Edsko will be talking about some final changes to the hooks patch, and afterwords it can hopefully be integrated. I'll keep up with them this week. * I am currently working on integrating the Applicative-Monad warning, but this requires some upstream patches for the build to work. However, we still need to sync several upstream libraries, and this will be happening over the next few weeks. Therefore, I may commit it, and incrementally fix validation errors as time goes on and me and Herbert sync upstreams. IMO, most of these look to be in good shape, I think. If you *do not think you'll make it by the 16th*, please let me know. We can possibly still land it the week of the 16th, provided I know ASAP. But we really really need to know, because many people will be gone the following week. In the following few days, I'm hoping going to finish off everything I can in the patch queue, and fix my remaining bugs, and investigate Dynamic GHCi in particular. Again, if you don't think you can make it on the 16th, but still within the week, we can of discuss it. -- Regards, Austin - PGP: 4096R/0x91384671

Show replies by date

Kazu Yamamoto

8 Sep 8 Sep

10:16 p.m.

Hi Austin, I would like to ask about profiling and dynamic linking. If I understand correctly, GHC 7.8 with cabal-install 1.18.x.x uses dynamic linking by default (except on FreeBSD). But GHC 7.8 provides a profile library only for static linking. An example is the base library: libHSbase-4.7.0.0.a libHSbase-4.7.0.0-ghc7.7.20130907.so* libHSbase-4.7.0.0_p.a Profile libraries for dynamic linking are not provided. So, I got troubles when I tried to take profile of my programs. I need to specify "--disable-shared" explicitly to cabal-install. (This sometime fails if Build-Type: is Custom.) Is this intentional? Are there any technical reasons to not provide dynamic profile libraries? --Kazu

...

Friends,

After talking with SPJ, we've decided that the cutoff date for the 7.8 feature window will essentially start on Monday, the 16th. This is the beginning of the week before ICFP. This is a week from tomorrow.

Afterwords, I suspect we will cut the 7.8 branch in early October (my notes tentatively say Oct. 9th.) This will give us a few weeks of straight bugfixing.

Don't let this scare you too much. We're doing this at the beginning of the week so we have time to sort things out. Bug fixes will of course continuously be welcome until the 7.8 branch.

However, for pending features, I'd like a status update. Everyone mentioned below, please reply to clarify anything:

* Iavor Diatchki and SPJ are working together on the type-nats-simple branch. I believe this will hopefully land in time. Iavor, SPJ - can you comment here?

* Trevor and Iavor are also working on kinds without data. Any word here?

* Geoffrey is currently moving, but he says the SIMD work and new template-haskell work will land by the end of this week, which is great.

* Patrick Palka has a few loose ends to tie off for the parallel compilation driver. I talked to him today, and after Andreas committed his bugfix to base, I believe everything is now working, with the deadlocks sorted out. Patrick, can you confirm? We can get this merged ASAP if so.

* Pedro and Richard - what's the story on propositional equality, etc? This is mentioned on the status page[1] but I'm not sure what else needs to be done. I know Pedro committed the work to make manual Typeable instances an error, which is great.

* Luite and Edsko will be talking about some final changes to the hooks patch, and afterwords it can hopefully be integrated. I'll keep up with them this week.

* I am currently working on integrating the Applicative-Monad warning, but this requires some upstream patches for the build to work. However, we still need to sync several upstream libraries, and this will be happening over the next few weeks. Therefore, I may commit it, and incrementally fix validation errors as time goes on and me and Herbert sync upstreams.

IMO, most of these look to be in good shape, I think.

If you *do not think you'll make it by the 16th*, please let me know. We can possibly still land it the week of the 16th, provided I know ASAP. But we really really need to know, because many people will be gone the following week.

In the following few days, I'm hoping going to finish off everything I can in the patch queue, and fix my remaining bugs, and investigate Dynamic GHCi in particular.

Again, if you don't think you can make it on the 16th, but still within the week, we can of discuss it.

-- Regards, Austin - PGP: 4096R/0x91384671

_______________________________________________ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs

Austin Seipp

10:25 p.m.

Kazu, Dynamic should be available with anything, including profiling. This is probably more an artifact of your mk/build.mk setup. When you look in there, check carefully which BuildFlavour you have set. The relevant variable is GhcLibWays. For example, BuildFlavour=perf will add 'p' which is profiling, and also 'dyn' if the platform supports shared libraries. BuildFlavour=quick however, would not set this. If you have a build tree, you can do: $ make show VALUE=GhcLibWays which should print out a string containing the enabled Ways. On Sun, Sep 8, 2013 at 9:16 PM, Kazu Yamamoto wrote:

...

Hi Austin,

I would like to ask about profiling and dynamic linking.

If I understand correctly, GHC 7.8 with cabal-install 1.18.x.x uses dynamic linking by default (except on FreeBSD). But GHC 7.8 provides a profile library only for static linking. An example is the base library:

libHSbase-4.7.0.0.a libHSbase-4.7.0.0-ghc7.7.20130907.so* libHSbase-4.7.0.0_p.a

Profile libraries for dynamic linking are not provided. So, I got troubles when I tried to take profile of my programs. I need to specify "--disable-shared" explicitly to cabal-install. (This sometime fails if Build-Type: is Custom.)

Is this intentional? Are there any technical reasons to not provide dynamic profile libraries?

--Kazu

...
Friends,

After talking with SPJ, we've decided that the cutoff date for the 7.8 feature window will essentially start on Monday, the 16th. This is the beginning of the week before ICFP. This is a week from tomorrow.

Afterwords, I suspect we will cut the 7.8 branch in early October (my notes tentatively say Oct. 9th.) This will give us a few weeks of straight bugfixing.

Don't let this scare you too much. We're doing this at the beginning of the week so we have time to sort things out. Bug fixes will of course continuously be welcome until the 7.8 branch.

However, for pending features, I'd like a status update. Everyone mentioned below, please reply to clarify anything:

* Iavor Diatchki and SPJ are working together on the type-nats-simple branch. I believe this will hopefully land in time. Iavor, SPJ - can you comment here?

* Trevor and Iavor are also working on kinds without data. Any word here?

* Geoffrey is currently moving, but he says the SIMD work and new template-haskell work will land by the end of this week, which is great.

* Patrick Palka has a few loose ends to tie off for the parallel compilation driver. I talked to him today, and after Andreas committed his bugfix to base, I believe everything is now working, with the deadlocks sorted out. Patrick, can you confirm? We can get this merged ASAP if so.

* Pedro and Richard - what's the story on propositional equality, etc? This is mentioned on the status page[1] but I'm not sure what else needs to be done. I know Pedro committed the work to make manual Typeable instances an error, which is great.

* Luite and Edsko will be talking about some final changes to the hooks patch, and afterwords it can hopefully be integrated. I'll keep up with them this week.

* I am currently working on integrating the Applicative-Monad warning, but this requires some upstream patches for the build to work. However, we still need to sync several upstream libraries, and this will be happening over the next few weeks. Therefore, I may commit it, and incrementally fix validation errors as time goes on and me and Herbert sync upstreams.

IMO, most of these look to be in good shape, I think.

If you *do not think you'll make it by the 16th*, please let me know. We can possibly still land it the week of the 16th, provided I know ASAP. But we really really need to know, because many people will be gone the following week.

In the following few days, I'm hoping going to finish off everything I can in the patch queue, and fix my remaining bugs, and investigate Dynamic GHCi in particular.

Again, if you don't think you can make it on the 16th, but still within the week, we can of discuss it.

-- Regards, Austin - PGP: 4096R/0x91384671

_______________________________________________ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs

-- Regards, Austin - PGP: 4096R/0x91384671

Kazu Yamamoto

10:36 p.m.

Austin,

...

Dynamic should be available with anything, including profiling. This is probably more an artifact of your mk/build.mk setup.

My mk/build.mk contains just one line: InstallExtraPackages = YES

...

If you have a build tree, you can do:

$ make show VALUE=GhcLibWays

which should print out a string containing the enabled Ways.

It printed: ---- % make show VALUE=GhcLibWays make -r --no-print-directory -f ghc.mk show GhcLibWays="v p dyn" ---- This does not install dynamic libraries for profiling in my environment. What's are missing? And why aren't they set by default? --Kazu

Edward Z. Yang

9 Sep 9 Sep

3:14 a.m.

Excerpts from Kazu Yamamoto (山本和彦)'s message of Sun Sep 08 19:36:19 -0700 2013:

...

---- % make show VALUE=GhcLibWays make -r --no-print-directory -f ghc.mk show GhcLibWays="v p dyn" ----

Yes, it looks like you are missing p_dyn from this list. I think this is a bug in the build system. When I look at ghc.mk it only verifies that the p way is present, not p_dyn; and I don't see any knobs which turn on p_dyn. However, I must admit to being a little confused; didn't we abandon dynamic by default and switch to only using dynamic for GHCi (in which case the profiling libraries ought not to matter)? Edward

Simon Marlow

4:11 p.m.

On 09/09/13 08:14, Edward Z. Yang wrote:

...

Excerpts from Kazu Yamamoto (山本和彦)'s message of Sun Sep 08 19:36:19 -0700 2013:

...
---- % make show VALUE=GhcLibWays make -r --no-print-directory -f ghc.mk show GhcLibWays="v p dyn" ----

Yes, it looks like you are missing p_dyn from this list. I think this is a bug in the build system. When I look at ghc.mk it only verifies that the p way is present, not p_dyn; and I don't see any knobs which turn on p_dyn.

However, I must admit to being a little confused; didn't we abandon dynamic by default and switch to only using dynamic for GHCi (in which case the profiling libraries ought not to matter)?

I think Kazu is saying that when he builds something with profiling using cabal-install, it fails because cabal-install tries to build a dynamic version too. We don't want dyanmic/profiled libraries (there's no point, you can't load them into GHCi). Perhaps this is something that needs fixing in cabal-install? Cheers, Simon

Edward Z. Yang

4:14 p.m.

...

I think Kazu is saying that when he builds something with profiling using cabal-install, it fails because cabal-install tries to build a dynamic version too. We don't want dyanmic/profiled libraries (there's no point, you can't load them into GHCi). Perhaps this is something that needs fixing in cabal-install?

Agreed, sounds like a Cabal install bug. Edward

Johan Tibell

5 p.m.

On Mon, Sep 9, 2013 at 1:14 PM, Edward Z. Yang wrote:

...

...
I think Kazu is saying that when he builds something with profiling using cabal-install, it fails because cabal-install tries to build a dynamic version too. We don't want dyanmic/profiled libraries (there's no point, you can't load them into GHCi). Perhaps this is something that needs fixing in cabal-install?

Agreed, sounds like a Cabal install bug.

I don't know what the right fix is. Can someone who understands the issue submit a pull request to cabal-install?

Mikhail Glushenkov

5:15 p.m.

Hi, On Mon, Sep 9, 2013 at 10:11 PM, Simon Marlow wrote:

...

I think Kazu is saying that when he builds something with profiling using cabal-install, it fails because cabal-install tries to build a dynamic version too. We don't want dyanmic/profiled libraries (there's no point, you can't load them into GHCi). Perhaps this is something that needs fixing in cabal-install?

Aren't they needed when compiling libraries that are using Template Haskell for profiling? The issue sounds like it could be TH-related. -- () ascii ribbon campaign - against html e-mail /\ www.asciiribbon.org - against proprietary attachments

Edward Z. Yang

5:21 p.m.

Hello Mikhail, It is a known issue that Template Haskell does not work with profiling (because GHCi and profiling do not work together, and TH uses GHCi's linker). [1] Actually, with the new linker patches that are landing soon we are not too far off from having this work. Edward [1] http://ghc.haskell.org/trac/ghc/ticket/4837 Excerpts from Mikhail Glushenkov's message of Mon Sep 09 14:15:54 -0700 2013:

...

Hi,

On Mon, Sep 9, 2013 at 10:11 PM, Simon Marlow wrote:

...
I think Kazu is saying that when he builds something with profiling using cabal-install, it fails because cabal-install tries to build a dynamic version too. We don't want dyanmic/profiled libraries (there's no point, you can't load them into GHCi). Perhaps this is something that needs fixing in cabal-install?

Aren't they needed when compiling libraries that are using Template Haskell for profiling? The issue sounds like it could be TH-related.

Mikhail Glushenkov

5:36 p.m.

Hi, On Mon, Sep 9, 2013 at 11:21 PM, Edward Z. Yang wrote:

...

Hello Mikhail,

It is a known issue that Template Haskell does not work with profiling (because GHCi and profiling do not work together, and TH uses GHCi's linker). [1] Actually, with the new linker patches that are landing soon we are not too far off from having this work.

Thanks, that clears things up a bit. Kazu (or someone else), can you please file a ticket on the Cabal bug tracker [1] if you think that this a Cabal bug? [1] https://github.com/haskell/cabal/issues/ -- () ascii ribbon campaign - against html e-mail /\ www.asciiribbon.org - against proprietary attachments

Kazu Yamamoto

6:37 p.m.

Hi,

...

Kazu (or someone else), can you please file a ticket on the Cabal bug tracker [1] if you think that this a Cabal bug?

I'm not completely sure yet. GHCi 7.8 uses dynamic linking. This is true. So, what is a consensus for GHC 7.8 and cabal-install 1.18? Are they supposed to use dynamic linking? Or, static linking? If dynamic linking is used, GHC should provide dynamic libraries for profiling. If static linking is used, cabal-install should stop using dynamic libraries for profiling. And of course, I can make a ticket when I'm convinced. P.S. Since "doctest" uses GHCi internally, I might misunderstand GHC 7.8 uses dynamic linking. Anyway, I don't understand what is right yet. --Kazu

Edward Z. Yang

7:06 p.m.

If I am building some Haskell executable using 'cabal build', the result should be *statically linked* by default. However, subtly, if I am building a Haskell library, I would like to be able to load the compiled version into GHCi. So it seems to me cabal should produce v, dyn (libs only, not final executable) and p ways by default (but not dyn_p). Edward Excerpts from Kazu Yamamoto (山本和彦)'s message of Mon Sep 09 15:37:10 -0700 2013:

...

Hi,

...
Kazu (or someone else), can you please file a ticket on the Cabal bug tracker [1] if you think that this a Cabal bug?

I'm not completely sure yet.

GHCi 7.8 uses dynamic linking. This is true.

So, what is a consensus for GHC 7.8 and cabal-install 1.18? Are they supposed to use dynamic linking? Or, static linking?

If dynamic linking is used, GHC should provide dynamic libraries for profiling.

If static linking is used, cabal-install should stop using dynamic libraries for profiling.

And of course, I can make a ticket when I'm convinced.

P.S.

Since "doctest" uses GHCi internally, I might misunderstand GHC 7.8 uses dynamic linking. Anyway, I don't understand what is right yet.

--Kazu

Johan Tibell

7:15 p.m.

That sounds terrible expensive to do on every `cabal build` and its a cost most users won't understand (what was broken before?). On Mon, Sep 9, 2013 at 4:06 PM, Edward Z. Yang wrote:

...

If I am building some Haskell executable using 'cabal build', the result should be *statically linked* by default.

However, subtly, if I am building a Haskell library, I would like to be able to load the compiled version into GHCi.

So it seems to me cabal should produce v, dyn (libs only, not final executable) and p ways by default (but not dyn_p).

Edward

Excerpts from Kazu Yamamoto (山本和彦)'s message of Mon Sep 09 15:37:10 -0700 2013:

...
Hi,

...
Kazu (or someone else), can you please file a ticket on the Cabal bug tracker [1] if you think that this a Cabal bug?

I'm not completely sure yet.

GHCi 7.8 uses dynamic linking. This is true.

So, what is a consensus for GHC 7.8 and cabal-install 1.18? Are they supposed to use dynamic linking? Or, static linking?

If dynamic linking is used, GHC should provide dynamic libraries for profiling.

If static linking is used, cabal-install should stop using dynamic libraries for profiling.

And of course, I can make a ticket when I'm convinced.

P.S.

Since "doctest" uses GHCi internally, I might misunderstand GHC 7.8 uses dynamic linking. Anyway, I don't understand what is right yet.

--Kazu

_______________________________________________ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs

Edward Z. Yang

7:29 p.m.

Erm, I forgot to mention that profiling would only be enabled if the user asked for it. Yes, we will be producing two sets of objects by default. This is what the -dynamic-too flag is for, no? I suppose you could try to compile your static executables using -fPIC, but that would negate the performance considerations why we haven't just switched to dynamic for everything. Edward Excerpts from Johan Tibell's message of Mon Sep 09 16:15:45 -0700 2013:

...

That sounds terrible expensive to do on every `cabal build` and its a cost most users won't understand (what was broken before?).

On Mon, Sep 9, 2013 at 4:06 PM, Edward Z. Yang wrote:

...
If I am building some Haskell executable using 'cabal build', the result should be *statically linked* by default.

However, subtly, if I am building a Haskell library, I would like to be able to load the compiled version into GHCi.

So it seems to me cabal should produce v, dyn (libs only, not final executable) and p ways by default (but not dyn_p).

Edward

Excerpts from Kazu Yamamoto (山本和彦)'s message of Mon Sep 09 15:37:10 -0700 2013:

...
Hi,

...
Kazu (or someone else), can you please file a ticket on the Cabal bug tracker [1] if you think that this a Cabal bug?

I'm not completely sure yet.

GHCi 7.8 uses dynamic linking. This is true.

So, what is a consensus for GHC 7.8 and cabal-install 1.18? Are they supposed to use dynamic linking? Or, static linking?

If dynamic linking is used, GHC should provide dynamic libraries for profiling.

If static linking is used, cabal-install should stop using dynamic libraries for profiling.

And of course, I can make a ticket when I'm convinced.

P.S.

Since "doctest" uses GHCi internally, I might misunderstand GHC 7.8 uses dynamic linking. Anyway, I don't understand what is right yet.

--Kazu

_______________________________________________ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs

Edward Z. Yang

14 Sep 14 Sep

5:01 a.m.

Actually, the situation is pretty bad on Windows, where dynamic-too does not work. Edward Excerpts from Edward Z. Yang's message of Mon Sep 09 16:29:38 -0700 2013:

...

Erm, I forgot to mention that profiling would only be enabled if the user asked for it.

Yes, we will be producing two sets of objects by default. This is what the -dynamic-too flag is for, no? I suppose you could try to compile your static executables using -fPIC, but that would negate the performance considerations why we haven't just switched to dynamic for everything.

Edward

Excerpts from Johan Tibell's message of Mon Sep 09 16:15:45 -0700 2013:

...
That sounds terrible expensive to do on every `cabal build` and its a cost most users won't understand (what was broken before?).

On Mon, Sep 9, 2013 at 4:06 PM, Edward Z. Yang wrote:

...
If I am building some Haskell executable using 'cabal build', the result should be *statically linked* by default.

However, subtly, if I am building a Haskell library, I would like to be able to load the compiled version into GHCi.

So it seems to me cabal should produce v, dyn (libs only, not final executable) and p ways by default (but not dyn_p).

Edward

Excerpts from Kazu Yamamoto (山本和彦)'s message of Mon Sep 09 15:37:10 -0700 2013:

...
Hi,

...
Kazu (or someone else), can you please file a ticket on the Cabal bug tracker [1] if you think that this a Cabal bug?

I'm not completely sure yet.

GHCi 7.8 uses dynamic linking. This is true.

So, what is a consensus for GHC 7.8 and cabal-install 1.18? Are they supposed to use dynamic linking? Or, static linking?

If dynamic linking is used, GHC should provide dynamic libraries for profiling.

If static linking is used, cabal-install should stop using dynamic libraries for profiling.

And of course, I can make a ticket when I'm convinced.

P.S.

Since "doctest" uses GHCi internally, I might misunderstand GHC 7.8 uses dynamic linking. Anyway, I don't understand what is right yet.

--Kazu

_______________________________________________ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs

Simon Marlow

10 Sep 10 Sep

1:50 a.m.

Template Haskell *does* work with profiling, you just have to compile the code without profiling first (Cabal knows how to do this and does it automatically). The big obstacles to loading profiled code into ghci are (a) lack of support in the byte code compiler and interpreter and (b) ghci itself would need to be a profiled executable. On 9 Sep 2013 22:21, "Edward Z. Yang" wrote:

...

Hello Mikhail,

It is a known issue that Template Haskell does not work with profiling (because GHCi and profiling do not work together, and TH uses GHCi's linker). [1] Actually, with the new linker patches that are landing soon we are not too far off from having this work.

Edward

[1] http://ghc.haskell.org/trac/ghc/ticket/4837

...
Hi,

On Mon, Sep 9, 2013 at 10:11 PM, Simon Marlow wrote:

...
I think Kazu is saying that when he builds something with profiling

using

...
cabal-install, it fails because cabal-install tries to build a dynamic version too. We don't want dyanmic/profiled libraries (there's no

Excerpts from Mikhail Glushenkov's message of Mon Sep 09 14:15:54 -0700 2013: point,

...
...
you can't load them into GHCi). Perhaps this is something that needs fixing in cabal-install?

Aren't they needed when compiling libraries that are using Template Haskell for profiling? The issue sounds like it could be TH-related.

Kazu Yamamoto

11 Sep 11 Sep

11:43 p.m.

Hi, Now I understand what is right and why I misunderstood. - GHC 7.8 provides three kinds of libraries: - static libraries - dynamic libraries - static libraries for profiling - GHCi uses dynamic libraries. - Programs complied with GHC 7.8 use static libraries. - When a library package is complied, both static one and dynamic one are created. - When "-p" or "--enabling-executable-profiling" are specified to cabal, static libraries for profiling are also created and used. So, we don't have to specify "--enable-shared"/"--disable-shared" to cabal in normal situation. There is no bug. Just I misunderstood. * Why did I misunderstand that programs are linked dynamically? I tried to support GHC 7.8 for doctest. Doctest uses GHCi internally. At the beginning, doctest cannot pass many tests if "--enable-shared" is not specified. This was fixed: https://github.com/sol/doctest-haskell/issues/58 Now, "--enable-shared" is not necessary even for doctest. * Why did I misunderstand that compiling programs for profiling fails? I specified --ghc-options="-prof -fprof-auto". "-prof" lets GHC 7.8 to produce both static and dynamic libraries for profiling. This resulted in build failure. Right procedure for profiling are: % cabal install -p --enable-executable-profiling --ghc-options="-fprof-auto" -j3 or % cabal install -p --ghc-options="-fprof-auto" --only-dependencies -j3 % cabal configure --enable-executable-profiling % cabal build --Kazu

...

On 09/09/13 08:14, Edward Z. Yang wrote:

...
Excerpts from Kazu Yamamoto (山本和彦)'s message of Sun Sep 08 19:36:19 -0700 2013:

...
---- % make show VALUE=GhcLibWays make -r --no-print-directory -f ghc.mk show GhcLibWays="v p dyn" ----

Yes, it looks like you are missing p_dyn from this list. I think this is a bug in the build system. When I look at ghc.mk it only verifies that the p way is present, not p_dyn; and I don't see any knobs which turn on p_dyn.

However, I must admit to being a little confused; didn't we abandon dynamic by default and switch to only using dynamic for GHCi (in which case the profiling libraries ought not to matter)?

I think Kazu is saying that when he builds something with profiling using cabal-install, it fails because cabal-install tries to build a dynamic version too. We don't want dyanmic/profiled libraries (there's no point, you can't load them into GHCi). Perhaps this is something that needs fixing in cabal-install?

Cheers, Simon

Simon Peyton-Jones

12 Sep 12 Sep

2:35 p.m.

Is this something that could be clarified in GHC's documentation? Patch? Simon | -----Original Message----- | From: ghc-devs [mailto:ghc-devs-bounces@haskell.org] On Behalf Of Kazu | Yamamoto | Sent: 12 September 2013 04:43 | To: glasgow-haskell-users@haskell.org; ghc-devs@haskell.org | Subject: Re: 7.8 Release Update | | Hi, | | Now I understand what is right and why I misunderstood. | | - GHC 7.8 provides three kinds of libraries: | - static libraries | - dynamic libraries | - static libraries for profiling | - GHCi uses dynamic libraries. | - Programs complied with GHC 7.8 use static libraries. | - When a library package is complied, both static one and dynamic | one are created. | - When "-p" or "--enabling-executable-profiling" are specified to | cabal, static libraries for profiling are also created and used. | | So, we don't have to specify "--enable-shared"/"--disable-shared" to | cabal in normal situation. | | There is no bug. Just I misunderstood. | | * Why did I misunderstand that programs are linked dynamically? | | I tried to support GHC 7.8 for doctest. Doctest uses GHCi internally. | At the beginning, doctest cannot pass many tests if "--enable-shared" | is not specified. This was fixed: | | https://github.com/sol/doctest-haskell/issues/58 | | Now, "--enable-shared" is not necessary even for doctest. | | * Why did I misunderstand that compiling programs for profiling fails? | | I specified --ghc-options="-prof -fprof-auto". "-prof" lets GHC 7.8 | to produce both static and dynamic libraries for profiling. This | resulted in build failure. | | Right procedure for profiling are: | | % cabal install -p --enable-executable-profiling --ghc-options="-fprof-auto" -j3 | | or | | % cabal install -p --ghc-options="-fprof-auto" --only-dependencies -j3 | % cabal configure --enable-executable-profiling | % cabal build | | --Kazu | | > On 09/09/13 08:14, Edward Z. Yang wrote: | >> Excerpts from Kazu Yamamoto (山本和彦)'s message of Sun Sep 08 | >> 19:36:19 -0700 2013: | >>> ---- | >>> % make show VALUE=GhcLibWays | >>> make -r --no-print-directory -f ghc.mk show | >>> GhcLibWays="v p dyn" | >>> ---- | >> | >> Yes, it looks like you are missing p_dyn from this list. I think | >> this is a bug in the build system. When I look at ghc.mk | >> it only verifies that the p way is present, not p_dyn; and I don't | >> see any knobs which turn on p_dyn. | >> | >> However, I must admit to being a little confused; didn't we abandon | >> dynamic by default and switch to only using dynamic for GHCi (in which | >> case the profiling libraries ought not to matter)? | > | > I think Kazu is saying that when he builds something with profiling | > using cabal-install, it fails because cabal-install tries to build a | > dynamic version too. We don't want dyanmic/profiled libraries | > (there's no point, you can't load them into GHCi). Perhaps this is | > something that needs fixing in cabal-install? | > | > Cheers, | > Simon | > | _______________________________________________ | ghc-devs mailing list | ghc-devs@haskell.org | http://www.haskell.org/mailman/listinfo/ghc-devs

Austin Seipp

4:18 p.m.

I think this can definitely be clarified. I'll update the docs a little later today when I get a chance. On Thu, Sep 12, 2013 at 1:35 PM, Simon Peyton-Jones wrote:

...

Is this something that could be clarified in GHC's documentation? Patch?

Simon

| -----Original Message----- | From: ghc-devs [mailto:ghc-devs-bounces@haskell.org] On Behalf Of Kazu | Yamamoto | Sent: 12 September 2013 04:43 | To: glasgow-haskell-users@haskell.org; ghc-devs@haskell.org | Subject: Re: 7.8 Release Update | | Hi, | | Now I understand what is right and why I misunderstood. | | - GHC 7.8 provides three kinds of libraries: | - static libraries | - dynamic libraries | - static libraries for profiling | - GHCi uses dynamic libraries. | - Programs complied with GHC 7.8 use static libraries. | - When a library package is complied, both static one and dynamic | one are created. | - When "-p" or "--enabling-executable-profiling" are specified to | cabal, static libraries for profiling are also created and used. | | So, we don't have to specify "--enable-shared"/"--disable-shared" to | cabal in normal situation. | | There is no bug. Just I misunderstood. | | * Why did I misunderstand that programs are linked dynamically? | | I tried to support GHC 7.8 for doctest. Doctest uses GHCi internally. | At the beginning, doctest cannot pass many tests if "--enable-shared" | is not specified. This was fixed: | | https://github.com/sol/doctest-haskell/issues/58 | | Now, "--enable-shared" is not necessary even for doctest. | | * Why did I misunderstand that compiling programs for profiling fails? | | I specified --ghc-options="-prof -fprof-auto". "-prof" lets GHC 7.8 | to produce both static and dynamic libraries for profiling. This | resulted in build failure. | | Right procedure for profiling are: | | % cabal install -p --enable-executable-profiling --ghc-options="-fprof-auto" -j3 | | or | | % cabal install -p --ghc-options="-fprof-auto" --only-dependencies -j3 | % cabal configure --enable-executable-profiling | % cabal build | | --Kazu | | > On 09/09/13 08:14, Edward Z. Yang wrote: | >> Excerpts from Kazu Yamamoto (山本和彦)'s message of Sun Sep 08 | >> 19:36:19 -0700 2013: | >>> ---- | >>> % make show VALUE=GhcLibWays | >>> make -r --no-print-directory -f ghc.mk show | >>> GhcLibWays="v p dyn" | >>> ---- | >> | >> Yes, it looks like you are missing p_dyn from this list. I think | >> this is a bug in the build system. When I look at ghc.mk | >> it only verifies that the p way is present, not p_dyn; and I don't | >> see any knobs which turn on p_dyn. | >> | >> However, I must admit to being a little confused; didn't we abandon | >> dynamic by default and switch to only using dynamic for GHCi (in which | >> case the profiling libraries ought not to matter)? | > | > I think Kazu is saying that when he builds something with profiling | > using cabal-install, it fails because cabal-install tries to build a | > dynamic version too. We don't want dyanmic/profiled libraries | > (there's no point, you can't load them into GHCi). Perhaps this is | > something that needs fixing in cabal-install? | > | > Cheers, | > Simon | > | _______________________________________________ | ghc-devs mailing list | ghc-devs@haskell.org | http://www.haskell.org/mailman/listinfo/ghc-devs _______________________________________________ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users

-- Austin Seipp, Haskell Consultant Well-Typed LLP, http://www.well-typed.com/

Iavor Diatchki

4:39 p.m.

Hello, I think that the simple type nats solver (branch type-nats-simple) is pretty much ready for merging with HEAD. Should I go ahead and merge it in? -Iavor On Thu, Sep 12, 2013 at 1:18 PM, Austin Seipp wrote:

...

I think this can definitely be clarified. I'll update the docs a little later today when I get a chance.

On Thu, Sep 12, 2013 at 1:35 PM, Simon Peyton-Jones wrote:

...
Is this something that could be clarified in GHC's documentation? Patch?

Simon

| -----Original Message----- | From: ghc-devs [mailto:ghc-devs-bounces@haskell.org] On Behalf Of Kazu | Yamamoto | Sent: 12 September 2013 04:43 | To: glasgow-haskell-users@haskell.org; ghc-devs@haskell.org | Subject: Re: 7.8 Release Update | | Hi, | | Now I understand what is right and why I misunderstood. | | - GHC 7.8 provides three kinds of libraries: | - static libraries | - dynamic libraries | - static libraries for profiling | - GHCi uses dynamic libraries. | - Programs complied with GHC 7.8 use static libraries. | - When a library package is complied, both static one and dynamic | one are created. | - When "-p" or "--enabling-executable-profiling" are specified to | cabal, static libraries for profiling are also created and used. | | So, we don't have to specify "--enable-shared"/"--disable-shared" to | cabal in normal situation. | | There is no bug. Just I misunderstood. | | * Why did I misunderstand that programs are linked dynamically? | | I tried to support GHC 7.8 for doctest. Doctest uses GHCi internally. | At the beginning, doctest cannot pass many tests if "--enable-shared" | is not specified. This was fixed: | | https://github.com/sol/doctest-haskell/issues/58 | | Now, "--enable-shared" is not necessary even for doctest. | | * Why did I misunderstand that compiling programs for profiling fails? | | I specified --ghc-options="-prof -fprof-auto". "-prof" lets GHC 7.8 | to produce both static and dynamic libraries for profiling. This | resulted in build failure. | | Right procedure for profiling are: | | % cabal install -p --enable-executable-profiling --ghc-options="-fprof-auto" -j3 | | or | | % cabal install -p --ghc-options="-fprof-auto" --only-dependencies -j3 | % cabal configure --enable-executable-profiling | % cabal build | | --Kazu | | > On 09/09/13 08:14, Edward Z. Yang wrote: | >> Excerpts from Kazu Yamamoto (山本和彦)'s message of Sun Sep 08 | >> 19:36:19 -0700 2013: | >>> ---- | >>> % make show VALUE=GhcLibWays | >>> make -r --no-print-directory -f ghc.mk show | >>> GhcLibWays="v p dyn" | >>> ---- | >> | >> Yes, it looks like you are missing p_dyn from this list. I think | >> this is a bug in the build system. When I look at ghc.mk | >> it only verifies that the p way is present, not p_dyn; and I don't | >> see any knobs which turn on p_dyn. | >> | >> However, I must admit to being a little confused; didn't we abandon | >> dynamic by default and switch to only using dynamic for GHCi (in which | >> case the profiling libraries ought not to matter)? | > | > I think Kazu is saying that when he builds something with profiling | > using cabal-install, it fails because cabal-install tries to build a | > dynamic version too. We don't want dyanmic/profiled libraries | > (there's no point, you can't load them into GHCi). Perhaps this is | > something that needs fixing in cabal-install? | > | > Cheers, | > Simon | > | _______________________________________________ | ghc-devs mailing list | ghc-devs@haskell.org | http://www.haskell.org/mailman/listinfo/ghc-devs _______________________________________________ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users

-- Austin Seipp, Haskell Consultant Well-Typed LLP, http://www.well-typed.com/ _______________________________________________ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users

Austin Seipp

4:46 p.m.

Iavor, yes! Please do so. If there's fallout we can look at it as it comes. If you don't mind, please squash the commits in your branch together into one and 'drop it' on the master branch. This is normally the way most of us drop features, and I think it makes it easier to notice and look at when other people (.e.g myself) see the commit messages. It also helps keep the history clean. An easy way to do this is: $ git checkout master $ git merge --squash type-nats-simple Then the changes will be on your branch, uncommitted, and a simple 'git commit ...' should let you make a big commit and write up some explanation. On Thu, Sep 12, 2013 at 3:39 PM, Iavor Diatchki wrote:

...

Hello,

I think that the simple type nats solver (branch type-nats-simple) is pretty much ready for merging with HEAD. Should I go ahead and merge it in?

-Iavor

On Thu, Sep 12, 2013 at 1:18 PM, Austin Seipp wrote:

...
I think this can definitely be clarified. I'll update the docs a little later today when I get a chance.

On Thu, Sep 12, 2013 at 1:35 PM, Simon Peyton-Jones wrote:

...
Is this something that could be clarified in GHC's documentation? Patch?

Simon

| -----Original Message----- | From: ghc-devs [mailto:ghc-devs-bounces@haskell.org] On Behalf Of Kazu | Yamamoto | Sent: 12 September 2013 04:43 | To: glasgow-haskell-users@haskell.org; ghc-devs@haskell.org | Subject: Re: 7.8 Release Update | | Hi, | | Now I understand what is right and why I misunderstood. | | - GHC 7.8 provides three kinds of libraries: | - static libraries | - dynamic libraries | - static libraries for profiling | - GHCi uses dynamic libraries. | - Programs complied with GHC 7.8 use static libraries. | - When a library package is complied, both static one and dynamic | one are created. | - When "-p" or "--enabling-executable-profiling" are specified to | cabal, static libraries for profiling are also created and used. | | So, we don't have to specify "--enable-shared"/"--disable-shared" to | cabal in normal situation. | | There is no bug. Just I misunderstood. | | * Why did I misunderstand that programs are linked dynamically? | | I tried to support GHC 7.8 for doctest. Doctest uses GHCi internally. | At the beginning, doctest cannot pass many tests if "--enable-shared" | is not specified. This was fixed: | | https://github.com/sol/doctest-haskell/issues/58 | | Now, "--enable-shared" is not necessary even for doctest. | | * Why did I misunderstand that compiling programs for profiling fails? | | I specified --ghc-options="-prof -fprof-auto". "-prof" lets GHC 7.8 | to produce both static and dynamic libraries for profiling. This | resulted in build failure. | | Right procedure for profiling are: | | % cabal install -p --enable-executable-profiling --ghc-options="-fprof-auto" -j3 | | or | | % cabal install -p --ghc-options="-fprof-auto" --only-dependencies -j3 | % cabal configure --enable-executable-profiling | % cabal build | | --Kazu | | > On 09/09/13 08:14, Edward Z. Yang wrote: | >> Excerpts from Kazu Yamamoto (山本和彦)'s message of Sun Sep 08 | >> 19:36:19 -0700 2013: | >>> ---- | >>> % make show VALUE=GhcLibWays | >>> make -r --no-print-directory -f ghc.mk show | >>> GhcLibWays="v p dyn" | >>> ---- | >> | >> Yes, it looks like you are missing p_dyn from this list. I think | >> this is a bug in the build system. When I look at ghc.mk | >> it only verifies that the p way is present, not p_dyn; and I don't | >> see any knobs which turn on p_dyn. | >> | >> However, I must admit to being a little confused; didn't we abandon | >> dynamic by default and switch to only using dynamic for GHCi (in which | >> case the profiling libraries ought not to matter)? | > | > I think Kazu is saying that when he builds something with profiling | > using cabal-install, it fails because cabal-install tries to build a | > dynamic version too. We don't want dyanmic/profiled libraries | > (there's no point, you can't load them into GHCi). Perhaps this is | > something that needs fixing in cabal-install? | > | > Cheers, | > Simon | > | _______________________________________________ | ghc-devs mailing list | ghc-devs@haskell.org | http://www.haskell.org/mailman/listinfo/ghc-devs _______________________________________________ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users

-- Austin Seipp, Haskell Consultant Well-Typed LLP, http://www.well-typed.com/ _______________________________________________ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users

-- Austin Seipp, Haskell Consultant Well-Typed LLP, http://www.well-typed.com/

Simon Peyton-Jones

13 Sep 13 Sep

12:36 p.m.

| also helps keep the history clean. An easy way to do this is: | | $ git checkout master | $ git merge --squash type-nats-simple Does that make One Patch with a single coherent message, abandoning all the intermediate commit messages on type-nats-simple? I hope so. Simon

Austin Seipp

12:57 p.m.

Yep. It will basically add all of your changes into the current branch like you did a real merge, but it just does not commit the result. If you 'git merge --squash', and then 'git status', you can see the changed files are ready to be committed, and you can commit them with one Big Commit. The relevant part of the git manual: "This allows you to create a single commit on top of the current branch whose effect is the same as merging another branch." which is perfect for us! On Fri, Sep 13, 2013 at 11:36 AM, Simon Peyton-Jones wrote:

...

| also helps keep the history clean. An easy way to do this is: | | $ git checkout master | $ git merge --squash type-nats-simple

Does that make One Patch with a single coherent message, abandoning all the intermediate commit messages on type-nats-simple? I hope so.

Simon

-- Austin Seipp, Haskell Consultant Well-Typed LLP, http://www.well-typed.com/

Trevor Elliott

9 Sep 9 Sep

12:08 a.m.

Hi Austin, Iavor and I have got the data kinds syntax changes up to date with master, on the data-kind-syntax branch. The -XDataKinds section of the manual has been updated to describe the new syntax. During a validate run, there were some problems building haddock, so I'm going to look into that tonight. There are tests for the data kind syntax in the test suite, currently on the data-kind-syntax branch. Other than the haddock fix, I think that we're ready to go. Thanks! --trevor On Sun 08 Sep 2013 04:27:33 PM PDT, Austin Seipp wrote:

...

Friends,

After talking with SPJ, we've decided that the cutoff date for the 7.8 feature window will essentially start on Monday, the 16th. This is the beginning of the week before ICFP. This is a week from tomorrow.

Afterwords, I suspect we will cut the 7.8 branch in early October (my notes tentatively say Oct. 9th.) This will give us a few weeks of straight bugfixing.

Don't let this scare you too much. We're doing this at the beginning of the week so we have time to sort things out. Bug fixes will of course continuously be welcome until the 7.8 branch.

However, for pending features, I'd like a status update. Everyone mentioned below, please reply to clarify anything:

* Iavor Diatchki and SPJ are working together on the type-nats-simple branch. I believe this will hopefully land in time. Iavor, SPJ - can you comment here?

* Trevor and Iavor are also working on kinds without data. Any word here?

* Geoffrey is currently moving, but he says the SIMD work and new template-haskell work will land by the end of this week, which is great.

* Patrick Palka has a few loose ends to tie off for the parallel compilation driver. I talked to him today, and after Andreas committed his bugfix to base, I believe everything is now working, with the deadlocks sorted out. Patrick, can you confirm? We can get this merged ASAP if so.

* Pedro and Richard - what's the story on propositional equality, etc? This is mentioned on the status page[1] but I'm not sure what else needs to be done. I know Pedro committed the work to make manual Typeable instances an error, which is great.

* Luite and Edsko will be talking about some final changes to the hooks patch, and afterwords it can hopefully be integrated. I'll keep up with them this week.

* I am currently working on integrating the Applicative-Monad warning, but this requires some upstream patches for the build to work. However, we still need to sync several upstream libraries, and this will be happening over the next few weeks. Therefore, I may commit it, and incrementally fix validation errors as time goes on and me and Herbert sync upstreams.

IMO, most of these look to be in good shape, I think.

If you *do not think you'll make it by the 16th*, please let me know. We can possibly still land it the week of the 16th, provided I know ASAP. But we really really need to know, because many people will be gone the following week.

In the following few days, I'm hoping going to finish off everything I can in the patch queue, and fix my remaining bugs, and investigate Dynamic GHCi in particular.

Again, if you don't think you can make it on the 16th, but still within the week, we can of discuss it.

Austin Seipp

11:25 a.m.

Excellent. Simon, are you privvy to this work at all? We lightly talked about it last week, but I'm not sure if you've reviewed it. Or perhaps Pedro or someone else could if we have time (I seem to remember he drew up the initial design points.) On Sun, Sep 8, 2013 at 11:08 PM, Trevor Elliott wrote:

...

Hi Austin,

Iavor and I have got the data kinds syntax changes up to date with master, on the data-kind-syntax branch. The -XDataKinds section of the manual has been updated to describe the new syntax. During a validate run, there were some problems building haddock, so I'm going to look into that tonight.

There are tests for the data kind syntax in the test suite, currently on the data-kind-syntax branch.

Other than the haddock fix, I think that we're ready to go.

Thanks!

--trevor

On Sun 08 Sep 2013 04:27:33 PM PDT, Austin Seipp wrote:

...
Friends,

After talking with SPJ, we've decided that the cutoff date for the 7.8 feature window will essentially start on Monday, the 16th. This is the beginning of the week before ICFP. This is a week from tomorrow.

Afterwords, I suspect we will cut the 7.8 branch in early October (my notes tentatively say Oct. 9th.) This will give us a few weeks of straight bugfixing.

Don't let this scare you too much. We're doing this at the beginning of the week so we have time to sort things out. Bug fixes will of course continuously be welcome until the 7.8 branch.

However, for pending features, I'd like a status update. Everyone mentioned below, please reply to clarify anything:

* Iavor Diatchki and SPJ are working together on the type-nats-simple branch. I believe this will hopefully land in time. Iavor, SPJ - can you comment here?

* Trevor and Iavor are also working on kinds without data. Any word here?

* Geoffrey is currently moving, but he says the SIMD work and new template-haskell work will land by the end of this week, which is great.

* Patrick Palka has a few loose ends to tie off for the parallel compilation driver. I talked to him today, and after Andreas committed his bugfix to base, I believe everything is now working, with the deadlocks sorted out. Patrick, can you confirm? We can get this merged ASAP if so.

* Pedro and Richard - what's the story on propositional equality, etc? This is mentioned on the status page[1] but I'm not sure what else needs to be done. I know Pedro committed the work to make manual Typeable instances an error, which is great.

* Luite and Edsko will be talking about some final changes to the hooks patch, and afterwords it can hopefully be integrated. I'll keep up with them this week.

* I am currently working on integrating the Applicative-Monad warning, but this requires some upstream patches for the build to work. However, we still need to sync several upstream libraries, and this will be happening over the next few weeks. Therefore, I may commit it, and incrementally fix validation errors as time goes on and me and Herbert sync upstreams.

IMO, most of these look to be in good shape, I think.

If you *do not think you'll make it by the 16th*, please let me know. We can possibly still land it the week of the 16th, provided I know ASAP. But we really really need to know, because many people will be gone the following week.

In the following few days, I'm hoping going to finish off everything I can in the patch queue, and fix my remaining bugs, and investigate Dynamic GHCi in particular.

Again, if you don't think you can make it on the 16th, but still within the week, we can of discuss it.

-- Regards, Austin - PGP: 4096R/0x91384671

Simon Peyton-Jones

11:44 a.m.

Yes I will try to review it this week. (This is the first time I've had access to the code.) Simon | -----Original Message----- | From: Austin Seipp [mailto:aseipp@pobox.com] | Sent: 09 September 2013 16:25 | To: Trevor Elliott | Cc: Austin Seipp; ghc-devs@haskell.org; glasgow-haskell- | users@haskell.org; Simon Peyton-Jones | Subject: Re: 7.8 Release Update | | Excellent. Simon, are you privvy to this work at all? We lightly | talked about it last week, but I'm not sure if you've reviewed it. Or | perhaps Pedro or someone else could if we have time (I seem to | remember he drew up the initial design points.) | | On Sun, Sep 8, 2013 at 11:08 PM, Trevor Elliott | wrote: | > Hi Austin, | > | > Iavor and I have got the data kinds syntax changes up to date with | master, | > on the data-kind-syntax branch. The -XDataKinds section of the manual | has | > been updated to describe the new syntax. During a validate run, there | were | > some problems building haddock, so I'm going to look into that | tonight. | > | > There are tests for the data kind syntax in the test suite, currently | on the | > data-kind-syntax branch. | > | > Other than the haddock fix, I think that we're ready to go. | > | > Thanks! | > | > --trevor | > | > | > On Sun 08 Sep 2013 04:27:33 PM PDT, Austin Seipp wrote: | >> | >> Friends, | >> | >> After talking with SPJ, we've decided that the cutoff date for the | 7.8 | >> feature window will essentially start on Monday, the 16th. This is | the | >> beginning of the week before ICFP. This is a week from tomorrow. | >> | >> Afterwords, I suspect we will cut the 7.8 branch in early October (my | >> notes tentatively say Oct. 9th.) This will give us a few weeks of | >> straight bugfixing. | >> | >> Don't let this scare you too much. We're doing this at the beginning | >> of the week so we have time to sort things out. Bug fixes will of | >> course continuously be welcome until the 7.8 branch. | >> | >> However, for pending features, I'd like a status update. Everyone | >> mentioned below, please reply to clarify anything: | >> | >> * Iavor Diatchki and SPJ are working together on the type-nats- | simple | >> branch. I believe this will hopefully land in time. Iavor, SPJ - can | >> you comment here? | >> | >> * Trevor and Iavor are also working on kinds without data. Any word | >> here? | >> | >> * Geoffrey is currently moving, but he says the SIMD work and new | >> template-haskell work will land by the end of this week, which is | >> great. | >> | >> * Patrick Palka has a few loose ends to tie off for the parallel | >> compilation driver. I talked to him today, and after Andreas | committed | >> his bugfix to base, I believe everything is now working, with the | >> deadlocks sorted out. Patrick, can you confirm? We can get this | merged | >> ASAP if so. | >> | >> * Pedro and Richard - what's the story on propositional equality, | >> etc? This is mentioned on the status page[1] but I'm not sure what | >> else needs to be done. I know Pedro committed the work to make manual | >> Typeable instances an error, which is great. | >> | >> * Luite and Edsko will be talking about some final changes to the | >> hooks patch, and afterwords it can hopefully be integrated. I'll keep | >> up with them this week. | >> | >> * I am currently working on integrating the Applicative-Monad | >> warning, but this requires some upstream patches for the build to | >> work. However, we still need to sync several upstream libraries, and | >> this will be happening over the next few weeks. Therefore, I may | >> commit it, and incrementally fix validation errors as time goes on | and | >> me and Herbert sync upstreams. | >> | >> IMO, most of these look to be in good shape, I think. | >> | >> If you *do not think you'll make it by the 16th*, please let me know. | >> We can possibly still land it the week of the 16th, provided I know | >> ASAP. But we really really need to know, because many people will be | >> gone the following week. | >> | >> In the following few days, I'm hoping going to finish off everything | I | >> can in the patch queue, and fix my remaining bugs, and investigate | >> Dynamic GHCi in particular. | >> | >> Again, if you don't think you can make it on the 16th, but still | >> within the week, we can of discuss it. | >> | > | | | | -- | Regards, | Austin - PGP: 4096R/0x91384671

Johan Tibell

12:39 p.m.

Is it OK if I release Cabal-1.18.0.1 on Monday if we want it to ship with GHC 7.8? 1.18.0.1 is a tiny bugfix release on top of 1.18.0. On Mon, Sep 9, 2013 at 8:44 AM, Simon Peyton-Jones wrote:

...

Yes I will try to review it this week. (This is the first time I've had access to the code.)

Simon

| -----Original Message----- | From: Austin Seipp [mailto:aseipp@pobox.com] | Sent: 09 September 2013 16:25 | To: Trevor Elliott | Cc: Austin Seipp; ghc-devs@haskell.org; glasgow-haskell- | users@haskell.org; Simon Peyton-Jones | Subject: Re: 7.8 Release Update | | Excellent. Simon, are you privvy to this work at all? We lightly | talked about it last week, but I'm not sure if you've reviewed it. Or | perhaps Pedro or someone else could if we have time (I seem to | remember he drew up the initial design points.) | | On Sun, Sep 8, 2013 at 11:08 PM, Trevor Elliott | wrote: | > Hi Austin, | > | > Iavor and I have got the data kinds syntax changes up to date with | master, | > on the data-kind-syntax branch. The -XDataKinds section of the manual | has | > been updated to describe the new syntax. During a validate run, there | were | > some problems building haddock, so I'm going to look into that | tonight. | > | > There are tests for the data kind syntax in the test suite, currently | on the | > data-kind-syntax branch. | > | > Other than the haddock fix, I think that we're ready to go. | > | > Thanks! | > | > --trevor | > | > | > On Sun 08 Sep 2013 04:27:33 PM PDT, Austin Seipp wrote: | >> | >> Friends, | >> | >> After talking with SPJ, we've decided that the cutoff date for the | 7.8 | >> feature window will essentially start on Monday, the 16th. This is | the | >> beginning of the week before ICFP. This is a week from tomorrow. | >> | >> Afterwords, I suspect we will cut the 7.8 branch in early October (my | >> notes tentatively say Oct. 9th.) This will give us a few weeks of | >> straight bugfixing. | >> | >> Don't let this scare you too much. We're doing this at the beginning | >> of the week so we have time to sort things out. Bug fixes will of | >> course continuously be welcome until the 7.8 branch. | >> | >> However, for pending features, I'd like a status update. Everyone | >> mentioned below, please reply to clarify anything: | >> | >> * Iavor Diatchki and SPJ are working together on the type-nats- | simple | >> branch. I believe this will hopefully land in time. Iavor, SPJ - can | >> you comment here? | >> | >> * Trevor and Iavor are also working on kinds without data. Any word | >> here? | >> | >> * Geoffrey is currently moving, but he says the SIMD work and new | >> template-haskell work will land by the end of this week, which is | >> great. | >> | >> * Patrick Palka has a few loose ends to tie off for the parallel | >> compilation driver. I talked to him today, and after Andreas | committed | >> his bugfix to base, I believe everything is now working, with the | >> deadlocks sorted out. Patrick, can you confirm? We can get this | merged | >> ASAP if so. | >> | >> * Pedro and Richard - what's the story on propositional equality, | >> etc? This is mentioned on the status page[1] but I'm not sure what | >> else needs to be done. I know Pedro committed the work to make manual | >> Typeable instances an error, which is great. | >> | >> * Luite and Edsko will be talking about some final changes to the | >> hooks patch, and afterwords it can hopefully be integrated. I'll keep | >> up with them this week. | >> | >> * I am currently working on integrating the Applicative-Monad | >> warning, but this requires some upstream patches for the build to | >> work. However, we still need to sync several upstream libraries, and | >> this will be happening over the next few weeks. Therefore, I may | >> commit it, and incrementally fix validation errors as time goes on | and | >> me and Herbert sync upstreams. | >> | >> IMO, most of these look to be in good shape, I think. | >> | >> If you *do not think you'll make it by the 16th*, please let me know. | >> We can possibly still land it the week of the 16th, provided I know | >> ASAP. But we really really need to know, because many people will be | >> gone the following week. | >> | >> In the following few days, I'm hoping going to finish off everything | I | >> can in the patch queue, and fix my remaining bugs, and investigate | >> Dynamic GHCi in particular. | >> | >> Again, if you don't think you can make it on the 16th, but still | >> within the week, we can of discuss it. | >> | > | | | | -- | Regards, | Austin - PGP: 4096R/0x91384671 _______________________________________________ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs

Simon Peyton-Jones

12:45 p.m.

I'm in the "to" field alone. Are you asking me? I have no opinion! But Monday 16 sounds fine to me. S | -----Original Message----- | From: Johan Tibell [mailto:johan.tibell@gmail.com] | Sent: 09 September 2013 17:40 | To: Simon Peyton-Jones | Cc: Austin Seipp; Trevor Elliott; glasgow-haskell-users@haskell.org; | ghc-devs@haskell.org | Subject: Re: 7.8 Release Update | | Is it OK if I release Cabal-1.18.0.1 on Monday if we want it to ship | with GHC 7.8? 1.18.0.1 is a tiny bugfix release on top of 1.18.0. | | On Mon, Sep 9, 2013 at 8:44 AM, Simon Peyton-Jones | wrote: | > Yes I will try to review it this week. (This is the first time I've | had access to the code.) | > | > Simon | > | > | -----Original Message----- | > | From: Austin Seipp [mailto:aseipp@pobox.com] | > | Sent: 09 September 2013 16:25 | > | To: Trevor Elliott | > | Cc: Austin Seipp; ghc-devs@haskell.org; glasgow-haskell- | > | users@haskell.org; Simon Peyton-Jones | > | Subject: Re: 7.8 Release Update | > | | > | Excellent. Simon, are you privvy to this work at all? We lightly | > | talked about it last week, but I'm not sure if you've reviewed it. | Or | > | perhaps Pedro or someone else could if we have time (I seem to | > | remember he drew up the initial design points.) | > | | > | On Sun, Sep 8, 2013 at 11:08 PM, Trevor Elliott | > | wrote: | > | > Hi Austin, | > | > | > | > Iavor and I have got the data kinds syntax changes up to date with | > | master, | > | > on the data-kind-syntax branch. The -XDataKinds section of the | manual | > | has | > | > been updated to describe the new syntax. During a validate run, | there | > | were | > | > some problems building haddock, so I'm going to look into that | > | tonight. | > | > | > | > There are tests for the data kind syntax in the test suite, | currently | > | on the | > | > data-kind-syntax branch. | > | > | > | > Other than the haddock fix, I think that we're ready to go. | > | > | > | > Thanks! | > | > | > | > --trevor | > | > | > | > | > | > On Sun 08 Sep 2013 04:27:33 PM PDT, Austin Seipp wrote: | > | >> | > | >> Friends, | > | >> | > | >> After talking with SPJ, we've decided that the cutoff date for | the | > | 7.8 | > | >> feature window will essentially start on Monday, the 16th. This | is | > | the | > | >> beginning of the week before ICFP. This is a week from tomorrow. | > | >> | > | >> Afterwords, I suspect we will cut the 7.8 branch in early October | (my | > | >> notes tentatively say Oct. 9th.) This will give us a few weeks of | > | >> straight bugfixing. | > | >> | > | >> Don't let this scare you too much. We're doing this at the | beginning | > | >> of the week so we have time to sort things out. Bug fixes will of | > | >> course continuously be welcome until the 7.8 branch. | > | >> | > | >> However, for pending features, I'd like a status update. Everyone | > | >> mentioned below, please reply to clarify anything: | > | >> | > | >> * Iavor Diatchki and SPJ are working together on the type-nats- | > | simple | > | >> branch. I believe this will hopefully land in time. Iavor, SPJ - | can | > | >> you comment here? | > | >> | > | >> * Trevor and Iavor are also working on kinds without data. Any | word | > | >> here? | > | >> | > | >> * Geoffrey is currently moving, but he says the SIMD work and | new | > | >> template-haskell work will land by the end of this week, which is | > | >> great. | > | >> | > | >> * Patrick Palka has a few loose ends to tie off for the | parallel | > | >> compilation driver. I talked to him today, and after Andreas | > | committed | > | >> his bugfix to base, I believe everything is now working, with the | > | >> deadlocks sorted out. Patrick, can you confirm? We can get this | > | merged | > | >> ASAP if so. | > | >> | > | >> * Pedro and Richard - what's the story on propositional | equality, | > | >> etc? This is mentioned on the status page[1] but I'm not sure | what | > | >> else needs to be done. I know Pedro committed the work to make | manual | > | >> Typeable instances an error, which is great. | > | >> | > | >> * Luite and Edsko will be talking about some final changes to | the | > | >> hooks patch, and afterwords it can hopefully be integrated. I'll | keep | > | >> up with them this week. | > | >> | > | >> * I am currently working on integrating the Applicative-Monad | > | >> warning, but this requires some upstream patches for the build to | > | >> work. However, we still need to sync several upstream libraries, | and | > | >> this will be happening over the next few weeks. Therefore, I may | > | >> commit it, and incrementally fix validation errors as time goes | on | > | and | > | >> me and Herbert sync upstreams. | > | >> | > | >> IMO, most of these look to be in good shape, I think. | > | >> | > | >> If you *do not think you'll make it by the 16th*, please let me | know. | > | >> We can possibly still land it the week of the 16th, provided I | know | > | >> ASAP. But we really really need to know, because many people will | be | > | >> gone the following week. | > | >> | > | >> In the following few days, I'm hoping going to finish off | everything | > | I | > | >> can in the patch queue, and fix my remaining bugs, and | investigate | > | >> Dynamic GHCi in particular. | > | >> | > | >> Again, if you don't think you can make it on the 16th, but still | > | >> within the week, we can of discuss it. | > | >> | > | > | > | | > | | > | | > | -- | > | Regards, | > | Austin - PGP: 4096R/0x91384671 | > _______________________________________________ | > ghc-devs mailing list | > ghc-devs@haskell.org | > http://www.haskell.org/mailman/listinfo/ghc-devs

Austin Seipp

12:48 p.m.

Herbert brought this question to my attention earlier - what's the cutoff date for boot libraries? IMO, I think boot library updates can happen until the actual branch in Oct. I'm planning on pushing the Applicative-Monad patch today, which will require some upstream coordination as well, including a patch to Cabal I believe. Short answer: yes, that'll be fine. On Mon, Sep 9, 2013 at 11:39 AM, Johan Tibell wrote:

...

Is it OK if I release Cabal-1.18.0.1 on Monday if we want it to ship with GHC 7.8? 1.18.0.1 is a tiny bugfix release on top of 1.18.0.

On Mon, Sep 9, 2013 at 8:44 AM, Simon Peyton-Jones wrote:

...
Yes I will try to review it this week. (This is the first time I've had access to the code.)

Simon

| -----Original Message----- | From: Austin Seipp [mailto:aseipp@pobox.com] | Sent: 09 September 2013 16:25 | To: Trevor Elliott | Cc: Austin Seipp; ghc-devs@haskell.org; glasgow-haskell- | users@haskell.org; Simon Peyton-Jones | Subject: Re: 7.8 Release Update | | Excellent. Simon, are you privvy to this work at all? We lightly | talked about it last week, but I'm not sure if you've reviewed it. Or | perhaps Pedro or someone else could if we have time (I seem to | remember he drew up the initial design points.) | | On Sun, Sep 8, 2013 at 11:08 PM, Trevor Elliott | wrote: | > Hi Austin, | > | > Iavor and I have got the data kinds syntax changes up to date with | master, | > on the data-kind-syntax branch. The -XDataKinds section of the manual | has | > been updated to describe the new syntax. During a validate run, there | were | > some problems building haddock, so I'm going to look into that | tonight. | > | > There are tests for the data kind syntax in the test suite, currently | on the | > data-kind-syntax branch. | > | > Other than the haddock fix, I think that we're ready to go. | > | > Thanks! | > | > --trevor | > | > | > On Sun 08 Sep 2013 04:27:33 PM PDT, Austin Seipp wrote: | >> | >> Friends, | >> | >> After talking with SPJ, we've decided that the cutoff date for the | 7.8 | >> feature window will essentially start on Monday, the 16th. This is | the | >> beginning of the week before ICFP. This is a week from tomorrow. | >> | >> Afterwords, I suspect we will cut the 7.8 branch in early October (my | >> notes tentatively say Oct. 9th.) This will give us a few weeks of | >> straight bugfixing. | >> | >> Don't let this scare you too much. We're doing this at the beginning | >> of the week so we have time to sort things out. Bug fixes will of | >> course continuously be welcome until the 7.8 branch. | >> | >> However, for pending features, I'd like a status update. Everyone | >> mentioned below, please reply to clarify anything: | >> | >> * Iavor Diatchki and SPJ are working together on the type-nats- | simple | >> branch. I believe this will hopefully land in time. Iavor, SPJ - can | >> you comment here? | >> | >> * Trevor and Iavor are also working on kinds without data. Any word | >> here? | >> | >> * Geoffrey is currently moving, but he says the SIMD work and new | >> template-haskell work will land by the end of this week, which is | >> great. | >> | >> * Patrick Palka has a few loose ends to tie off for the parallel | >> compilation driver. I talked to him today, and after Andreas | committed | >> his bugfix to base, I believe everything is now working, with the | >> deadlocks sorted out. Patrick, can you confirm? We can get this | merged | >> ASAP if so. | >> | >> * Pedro and Richard - what's the story on propositional equality, | >> etc? This is mentioned on the status page[1] but I'm not sure what | >> else needs to be done. I know Pedro committed the work to make manual | >> Typeable instances an error, which is great. | >> | >> * Luite and Edsko will be talking about some final changes to the | >> hooks patch, and afterwords it can hopefully be integrated. I'll keep | >> up with them this week. | >> | >> * I am currently working on integrating the Applicative-Monad | >> warning, but this requires some upstream patches for the build to | >> work. However, we still need to sync several upstream libraries, and | >> this will be happening over the next few weeks. Therefore, I may | >> commit it, and incrementally fix validation errors as time goes on | and | >> me and Herbert sync upstreams. | >> | >> IMO, most of these look to be in good shape, I think. | >> | >> If you *do not think you'll make it by the 16th*, please let me know. | >> We can possibly still land it the week of the 16th, provided I know | >> ASAP. But we really really need to know, because many people will be | >> gone the following week. | >> | >> In the following few days, I'm hoping going to finish off everything | I | >> can in the patch queue, and fix my remaining bugs, and investigate | >> Dynamic GHCi in particular. | >> | >> Again, if you don't think you can make it on the 16th, but still | >> within the week, we can of discuss it. | >> | > | | | | -- | Regards, | Austin - PGP: 4096R/0x91384671 _______________________________________________ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs

-- Regards, Austin - PGP: 4096R/0x91384671

Iavor Diatchki

2:40 a.m.

Hello Austin, On Sun, Sep 8, 2013 at 4:27 PM, Austin Seipp wrote:

...

* Iavor Diatchki and SPJ are working together on the type-nats-simple branch. I believe this will hopefully land in time. Iavor, SPJ - can you comment here?

I think we are on track to get this done on time. The type-nats-simple branch should be working (at least when I build it with no dynamic libraries) and up to date with HEAD, and there are some tests in a branched version of the testuite. One question: when I try to validate things, my build fails with this error: Reachable modules from DynFlags out of date Please fix compiler/ghc.mk, or building DLLs on Windows may break (#7780) Extra modules: BinIface BuildTyCl CoreLint FamInst Finder IOEnv IfaceEnv LoadIface PrelInfo TcIface TcMType TcRnMonad TcRnTypes TcTypeNats Any advice on what might be going wrong? -Iavor

Austin Seipp

11:29 a.m.

Iavor, I think we'll need to update the list of DynFlags-imported modules for the windows DLL split for this to work. Check compiler/ghc.mk, and look at the variable 'compiler_stage2_dll0_modules' flag. This essentially contains a list of the modules reachable from DynFlags. Try updating this list with the offending modules that dll-split reported, and see if things go OK. If not, let me know and I'll check out your branch and take a look. On Mon, Sep 9, 2013 at 1:40 AM, Iavor Diatchki wrote:

...

Hello Austin,

On Sun, Sep 8, 2013 at 4:27 PM, Austin Seipp wrote:

...
* Iavor Diatchki and SPJ are working together on the type-nats-simple branch. I believe this will hopefully land in time. Iavor, SPJ - can you comment here?

I think we are on track to get this done on time. The type-nats-simple branch should be working (at least when I build it with no dynamic libraries) and up to date with HEAD, and there are some tests in a branched version of the testuite.

One question: when I try to validate things, my build fails with this error:

Reachable modules from DynFlags out of date Please fix compiler/ghc.mk, or building DLLs on Windows may break (#7780) Extra modules: BinIface BuildTyCl CoreLint FamInst Finder IOEnv IfaceEnv LoadIface PrelInfo TcIface TcMType TcRnMonad TcRnTypes TcTypeNats

Any advice on what might be going wrong?

-Iavor

-- Regards, Austin - PGP: 4096R/0x91384671

Richard Eisenberg

8:40 a.m.

On Sep 8, 2013, at 7:27 PM, Austin Seipp wrote:

...

* Pedro and Richard - what's the story on propositional equality, etc? This is mentioned on the status page[1] but I'm not sure what else needs to be done. I know Pedro committed the work to make manual Typeable instances an error, which is great.

This work is complete and has been pushed for some time -- just haven't gotten around to updating the release notes. I'll get to it today. Thanks, Richard

Austin Seipp

11:23 a.m.

Thanks Richard! On Mon, Sep 9, 2013 at 7:40 AM, Richard Eisenberg wrote:

...

On Sep 8, 2013, at 7:27 PM, Austin Seipp wrote:

...
* Pedro and Richard - what's the story on propositional equality, etc? This is mentioned on the status page[1] but I'm not sure what else needs to be done. I know Pedro committed the work to make manual Typeable instances an error, which is great.

This work is complete and has been pushed for some time -- just haven't gotten around to updating the release notes. I'll get to it today.

Thanks, Richard

-- Regards, Austin - PGP: 4096R/0x91384671

Austin Seipp

16 Sep 16 Sep

noon

Friends, The time is here! We'll be closing off new features this week. There are some exceptions that have been made already: * Geoffrey will get SIMD/Template Haskell in this week, as he's been a little busy. But it's very close. * I believe Trevor and Iavor would still like to get Kinds without Data in the release, but Simon is currently on leave for the next few days, so we'll see once he gets back to look into it. There are some other lingering potential features that might make it (of various sizes,) but it's not clear they will be done in time. We'll be going on a case-by-case basis as I said. Do you have a feature you'd like to see make it in? Did you write a patch for some super cool feature? Please email me (either on list, or off-list) and we can discuss it. Again, today isn't a hard-line requirement, but at this point, I *have* to be aware of what you're doing, for you to have any chance of making the merge window. Several people have already done this, and we're discussing it. If you have a patch, but you're in doubt if it is too big, just email me. Or get ahold of me on IRC (thoughtpolice.) You can't really waste my time on this note. And of course, please continue to liberally report bugs (or patches!) - it's much better if we find them as early as possible. On Sun, Sep 8, 2013 at 6:27 PM, Austin Seipp wrote:

...

Friends,

After talking with SPJ, we've decided that the cutoff date for the 7.8 feature window will essentially start on Monday, the 16th. This is the beginning of the week before ICFP. This is a week from tomorrow.

Afterwords, I suspect we will cut the 7.8 branch in early October (my notes tentatively say Oct. 9th.) This will give us a few weeks of straight bugfixing.

Don't let this scare you too much. We're doing this at the beginning of the week so we have time to sort things out. Bug fixes will of course continuously be welcome until the 7.8 branch.

However, for pending features, I'd like a status update. Everyone mentioned below, please reply to clarify anything:

* Iavor Diatchki and SPJ are working together on the type-nats-simple branch. I believe this will hopefully land in time. Iavor, SPJ - can you comment here?

* Trevor and Iavor are also working on kinds without data. Any word here?

* Geoffrey is currently moving, but he says the SIMD work and new template-haskell work will land by the end of this week, which is great.

* Patrick Palka has a few loose ends to tie off for the parallel compilation driver. I talked to him today, and after Andreas committed his bugfix to base, I believe everything is now working, with the deadlocks sorted out. Patrick, can you confirm? We can get this merged ASAP if so.

* Pedro and Richard - what's the story on propositional equality, etc? This is mentioned on the status page[1] but I'm not sure what else needs to be done. I know Pedro committed the work to make manual Typeable instances an error, which is great.

* Luite and Edsko will be talking about some final changes to the hooks patch, and afterwords it can hopefully be integrated. I'll keep up with them this week.

* I am currently working on integrating the Applicative-Monad warning, but this requires some upstream patches for the build to work. However, we still need to sync several upstream libraries, and this will be happening over the next few weeks. Therefore, I may commit it, and incrementally fix validation errors as time goes on and me and Herbert sync upstreams.

IMO, most of these look to be in good shape, I think.

If you *do not think you'll make it by the 16th*, please let me know. We can possibly still land it the week of the 16th, provided I know ASAP. But we really really need to know, because many people will be gone the following week.

In the following few days, I'm hoping going to finish off everything I can in the patch queue, and fix my remaining bugs, and investigate Dynamic GHCi in particular.

Again, if you don't think you can make it on the 16th, but still within the week, we can of discuss it.

-- Regards, Austin - PGP: 4096R/0x91384671

-- Austin Seipp, Haskell Consultant Well-Typed LLP, http://www.well-typed.com/

Austin Seipp

12:02 p.m.

Oh, and of course, Edsko and Luite have made the final changes to their hooks patch, and as far as I can tell, all our potential users are quite happy! I've already given them an exception as well. I expect I will merge it in the next day or two, after another code review. On Mon, Sep 16, 2013 at 11:00 AM, Austin Seipp wrote:

...

Friends,

The time is here! We'll be closing off new features this week. There are some exceptions that have been made already:

* Geoffrey will get SIMD/Template Haskell in this week, as he's been a little busy. But it's very close. * I believe Trevor and Iavor would still like to get Kinds without Data in the release, but Simon is currently on leave for the next few days, so we'll see once he gets back to look into it.

There are some other lingering potential features that might make it (of various sizes,) but it's not clear they will be done in time. We'll be going on a case-by-case basis as I said. Do you have a feature you'd like to see make it in? Did you write a patch for some super cool feature? Please email me (either on list, or off-list) and we can discuss it.

Again, today isn't a hard-line requirement, but at this point, I *have* to be aware of what you're doing, for you to have any chance of making the merge window. Several people have already done this, and we're discussing it.

If you have a patch, but you're in doubt if it is too big, just email me. Or get ahold of me on IRC (thoughtpolice.) You can't really waste my time on this note.

And of course, please continue to liberally report bugs (or patches!) - it's much better if we find them as early as possible.

On Sun, Sep 8, 2013 at 6:27 PM, Austin Seipp wrote:

...
Friends,

After talking with SPJ, we've decided that the cutoff date for the 7.8 feature window will essentially start on Monday, the 16th. This is the beginning of the week before ICFP. This is a week from tomorrow.

Afterwords, I suspect we will cut the 7.8 branch in early October (my notes tentatively say Oct. 9th.) This will give us a few weeks of straight bugfixing.

Don't let this scare you too much. We're doing this at the beginning of the week so we have time to sort things out. Bug fixes will of course continuously be welcome until the 7.8 branch.

However, for pending features, I'd like a status update. Everyone mentioned below, please reply to clarify anything:

* Iavor Diatchki and SPJ are working together on the type-nats-simple branch. I believe this will hopefully land in time. Iavor, SPJ - can you comment here?

* Trevor and Iavor are also working on kinds without data. Any word here?

* Geoffrey is currently moving, but he says the SIMD work and new template-haskell work will land by the end of this week, which is great.

* Patrick Palka has a few loose ends to tie off for the parallel compilation driver. I talked to him today, and after Andreas committed his bugfix to base, I believe everything is now working, with the deadlocks sorted out. Patrick, can you confirm? We can get this merged ASAP if so.

* Pedro and Richard - what's the story on propositional equality, etc? This is mentioned on the status page[1] but I'm not sure what else needs to be done. I know Pedro committed the work to make manual Typeable instances an error, which is great.

* Luite and Edsko will be talking about some final changes to the hooks patch, and afterwords it can hopefully be integrated. I'll keep up with them this week.

* I am currently working on integrating the Applicative-Monad warning, but this requires some upstream patches for the build to work. However, we still need to sync several upstream libraries, and this will be happening over the next few weeks. Therefore, I may commit it, and incrementally fix validation errors as time goes on and me and Herbert sync upstreams.

IMO, most of these look to be in good shape, I think.

If you *do not think you'll make it by the 16th*, please let me know. We can possibly still land it the week of the 16th, provided I know ASAP. But we really really need to know, because many people will be gone the following week.

In the following few days, I'm hoping going to finish off everything I can in the patch queue, and fix my remaining bugs, and investigate Dynamic GHCi in particular.

Again, if you don't think you can make it on the 16th, but still within the week, we can of discuss it.

-- Regards, Austin - PGP: 4096R/0x91384671

-- Austin Seipp, Haskell Consultant Well-Typed LLP, http://www.well-typed.com/

-- Austin Seipp, Haskell Consultant Well-Typed LLP, http://www.well-typed.com/

4264

Age (days ago)

4272

Last active (days ago)

List overview

Download

35 comments

11 participants

participants (11)

Austin Seipp
Austin Seipp
Edward Z. Yang
Iavor Diatchki
Johan Tibell
Kazu Yamamoto
Mikhail Glushenkov
Richard Eisenberg
Simon Marlow
Simon Peyton-Jones
Trevor Elliott