7.8 Release Update

[Austin Seipp]

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
<iavor.diatchki at gmail.com> 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 <austin at well-typed.com> 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
>> <simonpj at microsoft.com> wrote:
>> > Is this something that could be clarified in GHC's documentation?
>> > Patch?
>> >
>> > Simon
>> >
>> > |  -----Original Message-----
>> > |  From: ghc-devs [mailto:ghc-devs-bounces at haskell.org] On Behalf Of
>> > Kazu
>> > |  Yamamoto
>> > |  Sent: 12 September 2013 04:43
>> > |  To: glasgow-haskell-users at haskell.org; ghc-devs at 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 at haskell.org
>> > |  http://www.haskell.org/mailman/listinfo/ghc-devs
>> > _______________________________________________
>> > Glasgow-haskell-users mailing list
>> > Glasgow-haskell-users at 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 at haskell.org
>> http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
>
>



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