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

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

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?

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.

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

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

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

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

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, 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/

Sounds good to me. I went ahead and updated the working conventions page (after fiddling for a while with the amazingly annoying Trac wiki syntax): http://ghc.haskell.org/trac/ghc/wiki/WorkingConventions/Git#Workingwiththetr... I added 5 notes here that I think everyone will like, if they're not aware of them: - Darcs-style cherry-picking - Darcs-style interactive diff selection - Squashing a branch - Basic rebases. - Using the reflog. Finally I have a small advanced section concerning itself with an interactive rebase, but there is no example. I should perhaps fix that. On Thu, Sep 12, 2013 at 5:49 PM, 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 | | 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.

Woo. I'd never heard of that. Sounds really useful.

Please Git experts, can you document some of these helpful workflows for us ingnoramuses! A series of headings "To do X..." followed by a how-to like the above, with a bit of explanation of when to use it and what is going on. Would be v helpful!

Simon

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

On Fri, Sep 13, 2013 at 9:10 AM, Jan Stolarek wrote:

I suspect that we will be building against newer version of libgmp, but the problem still remains. Would it be possible to ship libgmp with binary distribution of GHC so that users don't have to rely on their distro providing a precise version of that library?

This is what we already do with libffi, where the system may not have a version that we like (or any version), and it seems to work quite well. Taking the same approach with libgmp seems like a good idea.

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/

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

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

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, 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

Hi Joachim, I wouldn't know which place is preferable. Simon? (Your snippet did remind me that I forgot to remove the -fwarn-typeable-instances flag... working on that now.) Thanks, Pedro On Mon, Sep 9, 2013 at 8:25 AM, Joachim Breitner wrote:

Dear Predro,

Am Sonntag, den 08.09.2013, 18:27 -0500 schrieb Austin Seipp:

...

I know Pedro committed the work to make manual Typeable instances an error, which is great.

the Coercible class has a similar property, and I added the check to prevent manual instances to checkValidInstance in TcValidity: https://github.com/nomeata/ghc/commit/5e3f13 while you did it in tcInstDecls1 in TcInstDecls:

http://git.haskell.org/?p=ghc.git;a=commitdiff;h=5335e56953c4bbe18166039c062...

I’m happy to follow suite if you tell me that TcInstDecls is indeed the better spot for such a check.

Greetings, Joachim

-- Joachim “nomeata” Breitner mail@joachim-breitner.de • http://www.joachim-breitner.de/ Jabber: nomeata@joachim-breitner.de • GPG-Key: 0x4743206C Debian Developer: nomeata@debian.org

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

Hi, Am Montag, den 09.09.2013, 15:57 +0000 schrieb Simon Peyton-Jones:

I think I'd prefer all of these checks to be done in checkValidInstHead. It makes sense... it's just the kind of thing that checkValidInstHead is for. It would remove clutter (and filtration) from tcInstDecls1.

The same goes for the SafeHaskell checks in tcInstDecls1.

I'm not sure who is willing to do this? If no one wants to do it now can someone make a ticket? But it might be easier just to cut to the chase and do it :-)

I tried to cut the chase, but the issue is that checkValidInstHead has no idea whether the instance head it is about to check is a standalone instance or a regular one. For Coercible this is fine, but for Typeable it needs to allow standalone instances. So this requires more refactoring than I’m comfortable to do at the moment, hence the requested ticket: http://ghc.haskell.org/trac/ghc/ticket/8264 Greetings, Joachim -- Joachim “nomeata” Breitner mail@joachim-breitner.de • http://www.joachim-breitner.de/ Jabber: nomeata@joachim-breitner.de • GPG-Key: 0x4743206C Debian Developer: nomeata@debian.org

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

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/