From carter.schonwald at gmail.com  Sat Mar  1 00:26:22 2014
From: carter.schonwald at gmail.com (Carter Schonwald)
Date: Fri, 28 Feb 2014 19:26:22 -0500
Subject: Ready for Cabal release now?
In-Reply-To: <CAHYVw0zoMTkgSJW_e4_gLau5RUXArkC1Ctw9s-6U5cebADnoCw@mail.gmail.com>
References: <CAK-tuPY7wpLQyz0wGS7JqbbXKe-S7giyQ5iToz-p-Y+-YArPCQ@mail.gmail.com>
 <CAEs96n0jonf2Ssk_G_Jn2CZFhLdTgOt4YBmgfgn_1c_otaKNRQ@mail.gmail.com>
 <CAHYVw0zoMTkgSJW_e4_gLau5RUXArkC1Ctw9s-6U5cebADnoCw@mail.gmail.com>
Message-ID: <CAHYVw0x=YZa2bU=sy82TtOnF0gyRRnBdoWrG4L41ENDNMMVQqw@mail.gmail.com>

johan, any chance this can get cherry picked for cabal-install 1.18?
https://github.com/haskell/cabal/pull/1707 :)


On Fri, Feb 28, 2014 at 6:19 PM, Carter Schonwald <
carter.schonwald at gmail.com> wrote:

> are we going to try to make cabal-install binaries available for tier 1
> platforms?
>
>
> On Fri, Feb 28, 2014 at 6:02 PM, Austin Seipp <austin at well-typed.com>wrote:
>
>> That sounds good to me. I'm setting up the RC2 builds now, so we can
>> update our Cabal copy to the latest release after that, for the final
>> release. Right now we're at e97aa58f68519db54de1c62339459ebb88aed069,
>> which is just ahead of 1.18.1.3.
>>
>> As Duncan noted to me, we'll also have to do a cabal-install release,
>> to make sure that it can build with the adjusted version bounds
>> present in 7.8.
>>
>> Herbert, Duncan - any other input?
>>
>> Thanks Johan!
>>
>>
>> On Fri, Feb 28, 2014 at 4:48 PM, Johan Tibell <johan.tibell at gmail.com>
>> wrote:
>> > Hi,
>> >
>> > I know we're waiting until the last minute before the Cabal release that
>> > need to go into 7.8. Should I make that release now?
>> >
>> > -- Johan
>> >
>> >
>> > _______________________________________________
>> > ghc-devs mailing list
>> > ghc-devs at haskell.org
>> > http://www.haskell.org/mailman/listinfo/ghc-devs
>> >
>>
>>
>>
>> --
>> Regards,
>>
>> Austin Seipp, Haskell Consultant
>> Well-Typed LLP, http://www.well-typed.com/
>> _______________________________________________
>> ghc-devs mailing list
>> ghc-devs at haskell.org
>> http://www.haskell.org/mailman/listinfo/ghc-devs
>>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/ghc-devs/attachments/20140228/b597c005/attachment.html>

From carter.schonwald at gmail.com  Sat Mar  1 00:26:51 2014
From: carter.schonwald at gmail.com (Carter Schonwald)
Date: Fri, 28 Feb 2014 19:26:51 -0500
Subject: Ready for Cabal release now?
In-Reply-To: <CAHYVw0x=YZa2bU=sy82TtOnF0gyRRnBdoWrG4L41ENDNMMVQqw@mail.gmail.com>
References: <CAK-tuPY7wpLQyz0wGS7JqbbXKe-S7giyQ5iToz-p-Y+-YArPCQ@mail.gmail.com>
 <CAEs96n0jonf2Ssk_G_Jn2CZFhLdTgOt4YBmgfgn_1c_otaKNRQ@mail.gmail.com>
 <CAHYVw0zoMTkgSJW_e4_gLau5RUXArkC1Ctw9s-6U5cebADnoCw@mail.gmail.com>
 <CAHYVw0x=YZa2bU=sy82TtOnF0gyRRnBdoWrG4L41ENDNMMVQqw@mail.gmail.com>
Message-ID: <CAHYVw0w+jCHq99neDUBCwZaLuiUtsu2Zj2mDtN4s8rJWNedtEg@mail.gmail.com>

oh, ignore that last one, i guess its landing in 1.20 :)


On Fri, Feb 28, 2014 at 7:26 PM, Carter Schonwald <
carter.schonwald at gmail.com> wrote:

> johan, any chance this can get cherry picked for cabal-install 1.18?
> https://github.com/haskell/cabal/pull/1707 :)
>
>
> On Fri, Feb 28, 2014 at 6:19 PM, Carter Schonwald <
> carter.schonwald at gmail.com> wrote:
>
>> are we going to try to make cabal-install binaries available for tier 1
>> platforms?
>>
>>
>> On Fri, Feb 28, 2014 at 6:02 PM, Austin Seipp <austin at well-typed.com>wrote:
>>
>>> That sounds good to me. I'm setting up the RC2 builds now, so we can
>>> update our Cabal copy to the latest release after that, for the final
>>> release. Right now we're at e97aa58f68519db54de1c62339459ebb88aed069,
>>> which is just ahead of 1.18.1.3.
>>>
>>> As Duncan noted to me, we'll also have to do a cabal-install release,
>>> to make sure that it can build with the adjusted version bounds
>>> present in 7.8.
>>>
>>> Herbert, Duncan - any other input?
>>>
>>> Thanks Johan!
>>>
>>>
>>> On Fri, Feb 28, 2014 at 4:48 PM, Johan Tibell <johan.tibell at gmail.com>
>>> wrote:
>>> > Hi,
>>> >
>>> > I know we're waiting until the last minute before the Cabal release
>>> that
>>> > need to go into 7.8. Should I make that release now?
>>> >
>>> > -- Johan
>>> >
>>> >
>>> > _______________________________________________
>>> > ghc-devs mailing list
>>> > ghc-devs at haskell.org
>>> > http://www.haskell.org/mailman/listinfo/ghc-devs
>>> >
>>>
>>>
>>>
>>> --
>>> Regards,
>>>
>>> Austin Seipp, Haskell Consultant
>>> Well-Typed LLP, http://www.well-typed.com/
>>> _______________________________________________
>>> ghc-devs mailing list
>>> ghc-devs at haskell.org
>>> http://www.haskell.org/mailman/listinfo/ghc-devs
>>>
>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/ghc-devs/attachments/20140228/d39b1f82/attachment.html>

From johan.tibell at gmail.com  Sat Mar  1 07:23:31 2014
From: johan.tibell at gmail.com (Johan Tibell)
Date: Sat, 1 Mar 2014 08:23:31 +0100
Subject: Ready for Cabal release now?
In-Reply-To: <CAEs96n0jonf2Ssk_G_Jn2CZFhLdTgOt4YBmgfgn_1c_otaKNRQ@mail.gmail.com>
References: <CAK-tuPY7wpLQyz0wGS7JqbbXKe-S7giyQ5iToz-p-Y+-YArPCQ@mail.gmail.com>
 <CAEs96n0jonf2Ssk_G_Jn2CZFhLdTgOt4YBmgfgn_1c_otaKNRQ@mail.gmail.com>
Message-ID: <CAK-tuPbBzaK9ZkOkVmBmn=d7qS7J6g6ys=FAeJxBFZT8CUwqeQ@mail.gmail.com>

On Sat, Mar 1, 2014 at 12:02 AM, Austin Seipp <austin at well-typed.com> wrote:

> That sounds good to me. I'm setting up the RC2 builds now, so we can
> update our Cabal copy to the latest release after that, for the final
> release. Right now we're at e97aa58f68519db54de1c62339459ebb88aed069,
> which is just ahead of 1.18.1.3.
>

(Note that 1.18.1.3 is not a released version, just a version bump in the
repo in preparation for the release.)

The 1.18 branch is currently at 0d5ffeb91075739246627da17bda945aedc6a427
and I'm worried that ee6d1cf5cefe18f6d74ed379af21d92f8b0ae92d hasn't seen
enough testing. Duncan suggested (
https://github.com/haskell/cabal/issues/1660) that this change should be
included in a GHC RC, but since that's a bit annoying I'll try a Cabal RC
instead.


> As Duncan noted to me, we'll also have to do a cabal-install release,
> to make sure that it can build with the adjusted version bounds
> present in 7.8.
>

Will do that when I do the Cabal release.

-- Johan
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/ghc-devs/attachments/20140301/aa551f55/attachment-0001.html>

From johan.tibell at gmail.com  Sat Mar  1 07:24:42 2014
From: johan.tibell at gmail.com (Johan Tibell)
Date: Sat, 1 Mar 2014 08:24:42 +0100
Subject: Ready for Cabal release now?
In-Reply-To: <CAHYVw0zoMTkgSJW_e4_gLau5RUXArkC1Ctw9s-6U5cebADnoCw@mail.gmail.com>
References: <CAK-tuPY7wpLQyz0wGS7JqbbXKe-S7giyQ5iToz-p-Y+-YArPCQ@mail.gmail.com>
 <CAEs96n0jonf2Ssk_G_Jn2CZFhLdTgOt4YBmgfgn_1c_otaKNRQ@mail.gmail.com>
 <CAHYVw0zoMTkgSJW_e4_gLau5RUXArkC1Ctw9s-6U5cebADnoCw@mail.gmail.com>
Message-ID: <CAK-tuPYCEfAD=36iOm7Ee3kH=+qA960hcoq_c9nC1oDuiZKezQ@mail.gmail.com>

On Sat, Mar 1, 2014 at 12:19 AM, Carter Schonwald <
carter.schonwald at gmail.com> wrote:

> are we going to try to make cabal-install binaries available for tier 1
> platforms?
>

"Are we" is a magic phrase meaning "perhaps I should". :) In other words,
if people provide me with binaries, I will put them on the website.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/ghc-devs/attachments/20140301/cc97f5b1/attachment.html>

From johan.tibell at gmail.com  Sat Mar  1 07:55:03 2014
From: johan.tibell at gmail.com (Johan Tibell)
Date: Sat, 1 Mar 2014 08:55:03 +0100
Subject: Cabal-1.18.1.3 and cabal-install-1.18.0.3 RCs
Message-ID: <CAK-tuPZNhij2gKVR0AhKUsMbAt713cbU+AXi1=XCnP4qT7NFEg@mail.gmail.com>

Hi all,

I've uploaded release candidates for Cabal-1.18.1.3 (to be shipped with GHC
7.8) and cabal-install-1.18.0.3.

You can install the RCs like so:

cabal install http://johantibell.com/files/Cabal-1.18.1.3-rc.tar.gz
http://johantibell.com/files/cabal-install-1.18.0.3-rc.tar.gz

It's especially important that Cabal-1.18.1.3 gets some testing on OS X
using GHC 7.8, as there's a change in how linking is done (see
https://github.com/haskell/cabal/issues/1660).

These RCs correspond to commit d310d87c2c445f52987169a2ce4da03c14070918 on
the 1.18 branch in the cabal repo [1]. Note that both Cabal and
cabal-install are released from the same repo. If you want to check which
commits are new since last release run:

git log Cabal-v1.18.1.2.. -- Cabal/
git log cabal-install-v1.18.0.2 -- cabal-install/

-- Johan

1. https://github.com/haskell/cabal
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/ghc-devs/attachments/20140301/37b8b25b/attachment.html>

From johan.tibell at gmail.com  Sat Mar  1 07:58:30 2014
From: johan.tibell at gmail.com (Johan Tibell)
Date: Sat, 1 Mar 2014 08:58:30 +0100
Subject: Ready for Cabal release now?
In-Reply-To: <CAK-tuPbBzaK9ZkOkVmBmn=d7qS7J6g6ys=FAeJxBFZT8CUwqeQ@mail.gmail.com>
References: <CAK-tuPY7wpLQyz0wGS7JqbbXKe-S7giyQ5iToz-p-Y+-YArPCQ@mail.gmail.com>
 <CAEs96n0jonf2Ssk_G_Jn2CZFhLdTgOt4YBmgfgn_1c_otaKNRQ@mail.gmail.com>
 <CAK-tuPbBzaK9ZkOkVmBmn=d7qS7J6g6ys=FAeJxBFZT8CUwqeQ@mail.gmail.com>
Message-ID: <CAK-tuPYCdoTA4A_E+T+5n3Ap9Yrr=mkojjk2R4seQw1grauLVg@mail.gmail.com>

On Sat, Mar 1, 2014 at 8:23 AM, Johan Tibell <johan.tibell at gmail.com> wrote:

> On Sat, Mar 1, 2014 at 12:02 AM, Austin Seipp <austin at well-typed.com>wrote:
>
>> That sounds good to me. I'm setting up the RC2 builds now, so we can
>> update our Cabal copy to the latest release after that, for the final
>> release. Right now we're at e97aa58f68519db54de1c62339459ebb88aed069,
>> which is just ahead of 1.18.1.3.
>>
>
> (Note that 1.18.1.3 is not a released version, just a version bump in the
> repo in preparation for the release.)
>
> The 1.18 branch is currently at 0d5ffeb91075739246627da17bda945aedc6a427
> and I'm worried that ee6d1cf5cefe18f6d74ed379af21d92f8b0ae92d hasn't seen
> enough testing. Duncan suggested (
> https://github.com/haskell/cabal/issues/1660) that this change should be
> included in a GHC RC, but since that's a bit annoying I'll try a Cabal RC
> instead.
>

I just announce a RC1 for Cabal/cabal-install. In case you do any more GHC
RCs, please update the GHC repo to the latest cabal 1.18 HEAD.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/ghc-devs/attachments/20140301/b58b6691/attachment.html>

From pali.gabor at gmail.com  Sat Mar  1 08:29:33 2014
From: pali.gabor at gmail.com (=?ISO-8859-1?Q?P=E1li_G=E1bor_J=E1nos?=)
Date: Sat, 1 Mar 2014 09:29:33 +0100
Subject: RC2 release imminent
In-Reply-To: <CAEs96n0CTG7EqMGDNu0P3V1Od-AskB8zAdU8XdnfDMnCPiEqSQ@mail.gmail.com>
References: <CAEs96n2j0oyvTeYecrgdfHsJgzCRexz=LTf8smta9UQSONbd5w@mail.gmail.com>
 <CAHnG2CwkfT2+16+W0Z=C8xabtRXW6vmpf7n_X7N9+Zt6vbL8yw@mail.gmail.com>
 <CAK-hX0=N-sDjQPy8VY+qwgndvR5B+qMVJZja1=mVT=YcWyhqpg@mail.gmail.com>
 <CAHnG2CyPf4bsMtY1Bm5sRjgbaCC4wYeBj6TBQqBjdkB_HkOo_g@mail.gmail.com>
 <CAEs96n3X1NUY0OmpsjGgM+t2HYxx1VOkDb9X0vED2zwDeu7qpA@mail.gmail.com>
 <CAEDGBqLRsXbARK=o1D-MYfxkiaQ_sjipNimQYHpXSNcHZkwbow@mail.gmail.com>
 <CAEs96n0CTG7EqMGDNu0P3V1Od-AskB8zAdU8XdnfDMnCPiEqSQ@mail.gmail.com>
Message-ID: <CAHnG2CzfrqTxNL=jrxVfjpSSvE+_5=G47V3NQ2QqFCk51dQHbA@mail.gmail.com>

2014-03-01 0:46 GMT+01:00 Austin Seipp <austin at well-typed.com>:
> New source distributions are available here:
>
> http://www.haskell.org/ghc/dist/7.8.1-rc2/
>
> Feel free to build when you get a chance at attach the hashes for the
> binary dists.

The corresponding FreeBSD build are available here:

http://haskell.inf.elte.hu/ghc/ghc-7.8.0.20140228-i386-portbld-freebsd.tar.bz2
http://haskell.inf.elte.hu/ghc/ghc-7.8.0.20140228-x86_64-portbld-freebsd.tar.bz2

Hashes:

http://haskell.inf.elte.hu/ghc/SHA256SUMS

Updated installation instructions:

http://haskell.inf.elte.hu/ghc/README.html

From lukexipd at gmail.com  Sat Mar  1 16:27:43 2014
From: lukexipd at gmail.com (Luke Iannini)
Date: Sat, 1 Mar 2014 08:27:43 -0800
Subject: RC2 release imminent
In-Reply-To: <CAHnG2CzfrqTxNL=jrxVfjpSSvE+_5=G47V3NQ2QqFCk51dQHbA@mail.gmail.com>
References: <CAEs96n2j0oyvTeYecrgdfHsJgzCRexz=LTf8smta9UQSONbd5w@mail.gmail.com>
 <CAHnG2CwkfT2+16+W0Z=C8xabtRXW6vmpf7n_X7N9+Zt6vbL8yw@mail.gmail.com>
 <CAK-hX0=N-sDjQPy8VY+qwgndvR5B+qMVJZja1=mVT=YcWyhqpg@mail.gmail.com>
 <CAHnG2CyPf4bsMtY1Bm5sRjgbaCC4wYeBj6TBQqBjdkB_HkOo_g@mail.gmail.com>
 <CAEs96n3X1NUY0OmpsjGgM+t2HYxx1VOkDb9X0vED2zwDeu7qpA@mail.gmail.com>
 <CAEDGBqLRsXbARK=o1D-MYfxkiaQ_sjipNimQYHpXSNcHZkwbow@mail.gmail.com>
 <CAEs96n0CTG7EqMGDNu0P3V1Od-AskB8zAdU8XdnfDMnCPiEqSQ@mail.gmail.com>
 <CAHnG2CzfrqTxNL=jrxVfjpSSvE+_5=G47V3NQ2QqFCk51dQHbA@mail.gmail.com>
Message-ID: <CAGo83ChTJobOczFdBbpeL9EhUn2cte20cDbpdXnphbauwGBn8A@mail.gmail.com>

Quad linkage:
https://github.com/ghc-ios/ghc-ios-scripts/releases/download/7.8-rc2-device/ghc-7.8.0.20140228-arm-apple-ios.tar.bz2
https://github.com/ghc-ios/ghc-ios-scripts/releases/download/7.8-rc2-device/ghc-7.8.0.20140228-arm-apple-ios.tar.bz2.sha1

https://github.com/ghc-ios/ghc-ios-scripts/releases/download/7.8-rc2-simulator/ghc-7.8.0.20140228-i386-apple-ios.tar.bz2
https://github.com/ghc-ios/ghc-ios-scripts/releases/download/7.8-rc2-simulator/ghc-7.8.0.20140228-i386-apple-ios.tar.bz2.sha1

+ readme
https://github.com/ghc-ios/ghc-ios-scripts/blob/master/README.md

Cheers
Luke


On Sat, Mar 1, 2014 at 12:29 AM, P?li G?bor J?nos <pali.gabor at gmail.com>wrote:

> 2014-03-01 0:46 GMT+01:00 Austin Seipp <austin at well-typed.com>:
> > New source distributions are available here:
> >
> > http://www.haskell.org/ghc/dist/7.8.1-rc2/
> >
> > Feel free to build when you get a chance at attach the hashes for the
> > binary dists.
>
> The corresponding FreeBSD build are available here:
>
>
> http://haskell.inf.elte.hu/ghc/ghc-7.8.0.20140228-i386-portbld-freebsd.tar.bz2
>
> http://haskell.inf.elte.hu/ghc/ghc-7.8.0.20140228-x86_64-portbld-freebsd.tar.bz2
>
> Hashes:
>
> http://haskell.inf.elte.hu/ghc/SHA256SUMS
>
> Updated installation instructions:
>
> http://haskell.inf.elte.hu/ghc/README.html
> _______________________________________________
> ghc-devs mailing list
> ghc-devs at haskell.org
> http://www.haskell.org/mailman/listinfo/ghc-devs
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/ghc-devs/attachments/20140301/e2210e58/attachment.html>

From karel.gardas at centrum.cz  Sat Mar  1 18:12:18 2014
From: karel.gardas at centrum.cz (Karel Gardas)
Date: Sat, 01 Mar 2014 19:12:18 +0100
Subject: When iselExpr64 (CmmLit (CmmInt i _)) is used?
Message-ID: <53122302.6000603@centrum.cz>


Hello,

I'm trying to resurrect SPARC NCG. I've switched it on and basically 
provided functions on which NCG has panic during the build, basically 
just 2 were missing so far (cut from git diff):

+genCCall (PrimTarget MO_Touch) _ _
+ = return $ nilOL
+


+iselExpr64 (CmmLit (CmmInt i _)) = do
+  (rlo, rhi) <- getNewRegPairNat II32
+  let
+      half0 = fromIntegral (fromIntegral i :: Word32)
+      half1 = fromIntegral (fromIntegral (i `shiftR` 32) :: Word32)
+      code = toOL [
+              SETHI (HI $ ImmInt half0) rlo,
+              OR False rlo (RIImm (LO $ ImmInt half0)) rlo,
+              SETHI (HI $ ImmInt half1) rhi,
+              OR False rhi (RIImm (LO $ ImmInt half1)) rhi
+             ]
+  return (ChildCode64 code rlo)


Now, my ghc-stage2 badly fails and testsuite run with stage=1 reveals 
1390 unexpected failures. Perhaps this is unrelated, but still I'd like 
to test that my iselExpr64 implementation above is correct. Is there any 
simple haskell code which makes this function in NCG run? I'm trying this:

import GHC.Prim
import GHC.Exts

main = do
         let x = 18446744073709551615#
         --- 2^64-1 = 18446744073709551615
         putStrLn (show $ I# x)
         return()


I've had a hope that unboxed long int constant is what causes iselExpr64 
being called, but generated assembly looks suspicious -- like it's not 
called so my idea was wrong here probably. Do you have any idea how to 
test this function and see its generated assembly?

BTW: I hope I got the function semantics correct as a loading of 64bit 
constant/integer into a pair of 32bits registers...

Thanks a lot!
Karel


From austin at well-typed.com  Sat Mar  1 20:26:35 2014
From: austin at well-typed.com (Austin Seipp)
Date: Sat, 1 Mar 2014 14:26:35 -0600
Subject: When iselExpr64 (CmmLit (CmmInt i _)) is used?
In-Reply-To: <53122302.6000603@centrum.cz>
References: <53122302.6000603@centrum.cz>
Message-ID: <CAEs96n3cyEJU99aTodcMxKsvT2eMO559Vd1hntdonmmSB3sL5g@mail.gmail.com>

Hi Karel,

Although I haven't looked extremely closely, may I suggest perhaps
writing your test case in C-- instead of Haskell? It looks like you
can trigger this simply with a CmmAssign or CmmStore node with a 64bit
type, which will call assign(Reg|Mem)_I64Code, in turn calling
iselExpr64 - see nativeGen/SPARC/CodeGen.hs:stmtToInstrs (line 121).
If you trace through from CmmParse.y to find emitAssign in
StgCmmMonad, it'll create an assignment node for you.

Do that with -S and check out the assembly files (-ddump-asm should
also do the trick).

This should make it easy to trigger and examine. Then you can link it
into a Haskell program as a foreign primop and test it extensively
with a working executable.



On Sat, Mar 1, 2014 at 12:12 PM, Karel Gardas <karel.gardas at centrum.cz> wrote:
>
> Hello,
>
> I'm trying to resurrect SPARC NCG. I've switched it on and basically
> provided functions on which NCG has panic during the build, basically just 2
> were missing so far (cut from git diff):
>
> +genCCall (PrimTarget MO_Touch) _ _
> + = return $ nilOL
> +
>
>
> +iselExpr64 (CmmLit (CmmInt i _)) = do
> +  (rlo, rhi) <- getNewRegPairNat II32
> +  let
> +      half0 = fromIntegral (fromIntegral i :: Word32)
> +      half1 = fromIntegral (fromIntegral (i `shiftR` 32) :: Word32)
> +      code = toOL [
> +              SETHI (HI $ ImmInt half0) rlo,
> +              OR False rlo (RIImm (LO $ ImmInt half0)) rlo,
> +              SETHI (HI $ ImmInt half1) rhi,
> +              OR False rhi (RIImm (LO $ ImmInt half1)) rhi
> +             ]
> +  return (ChildCode64 code rlo)
>
>
> Now, my ghc-stage2 badly fails and testsuite run with stage=1 reveals 1390
> unexpected failures. Perhaps this is unrelated, but still I'd like to test
> that my iselExpr64 implementation above is correct. Is there any simple
> haskell code which makes this function in NCG run? I'm trying this:
>
> import GHC.Prim
> import GHC.Exts
>
> main = do
>         let x = 18446744073709551615#
>         --- 2^64-1 = 18446744073709551615
>         putStrLn (show $ I# x)
>         return()
>
>
> I've had a hope that unboxed long int constant is what causes iselExpr64
> being called, but generated assembly looks suspicious -- like it's not
> called so my idea was wrong here probably. Do you have any idea how to test
> this function and see its generated assembly?
>
> BTW: I hope I got the function semantics correct as a loading of 64bit
> constant/integer into a pair of 32bits registers...
>
> Thanks a lot!
> Karel
>
> _______________________________________________
> ghc-devs mailing list
> ghc-devs at haskell.org
> http://www.haskell.org/mailman/listinfo/ghc-devs
>



-- 
Regards,

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

From simonpj at microsoft.com  Sat Mar  1 21:17:18 2014
From: simonpj at microsoft.com (Simon Peyton Jones)
Date: Sat, 1 Mar 2014 21:17:18 +0000
Subject: [commit: packages/base] ghc-7.8: Workaround failed
 constant-folding for zeroBits (591142f)
In-Reply-To: <20140301135323.7B8C42406B@ghc.haskell.org>
References: <20140301135323.7B8C42406B@ghc.haskell.org>
Message-ID: <59543203684B2244980D7E4057D5FBC1487D090F@DB3EX14MBXC306.europe.corp.microsoft.com>

Herbert would you like to open a ticket, saying what's wrong and how to reproduce it?

Simon

| -----Original Message-----
| From: ghc-commits [mailto:ghc-commits-bounces at haskell.org] On Behalf Of
| git at git.haskell.org
| Sent: 01 March 2014 13:53
| To: ghc-commits at haskell.org
| Subject: [commit: packages/base] ghc-7.8: Workaround failed constant-
| folding for zeroBits (591142f)
| 
| Repository : ssh://git at git.haskell.org/base
| 
| On branch  : ghc-7.8
| Link       :
| http://ghc.haskell.org/trac/ghc/changeset/591142f8aead4c28bdaa5656d79e6
| dc38273e685/base
| 
| >---------------------------------------------------------------
| 
| commit 591142f8aead4c28bdaa5656d79e6dc38273e685
| Author: Herbert Valerio Riedel <hvr at gnu.org>
| Date:   Sat Mar 1 14:45:48 2014 +0100
| 
|     Workaround failed constant-folding for zeroBits
| 
|     For some reason GHC fails to constant fold `zeroBits :: Int` and
|     `zeroBits :: Integer`; `ghc -show-iface` shows
| 
|       $fBitsInt_$czeroBits :: GHC.Types.Int
|          {- Strictness: m,
|             Unfolding: (GHC.Types.I# (GHC.Prim.andI# 1 (GHC.Prim.notI#
| 1))) -}
| 
|     Otoh, constant-folding works as expected, reducing `zeroBits` to 0
| constant
|     for the other integer-types (= {Word,Int}{8,16,32,64}` and `Word`).
| So this
|     quickfix is actually just treating the symptom rather than the
| cause.
| 
|     Signed-off-by: Herbert Valerio Riedel <hvr at gnu.org>
|     (cherry picked from commit
| 2dbfcd70e53845d9119389cecc88411b47b70644)
| 
| 
| >---------------------------------------------------------------
| 
| 591142f8aead4c28bdaa5656d79e6dc38273e685
|  Data/Bits.hs |    3 +++
|  1 file changed, 3 insertions(+)
| 
| diff --git a/Data/Bits.hs b/Data/Bits.hs
| index e771624..28cd024 100644
| --- a/Data/Bits.hs
| +++ b/Data/Bits.hs
| @@ -363,6 +363,8 @@ instance Bits Int where
|      {-# INLINE bit #-}
|      {-# INLINE testBit #-}
| 
| +    zeroBits = 0
| +
|      bit     = bitDefault
| 
|      testBit = testBitDefault
| @@ -437,6 +439,7 @@ instance Bits Integer where
|                       | otherwise = shiftRInteger x (negateInt# i#)
|     testBit x (I# i) = testBitInteger x i
| 
| +   zeroBits   = 0
|     bit        = bitDefault
|     popCount   = popCountDefault
| 
| 
| _______________________________________________
| ghc-commits mailing list
| ghc-commits at haskell.org
| http://www.haskell.org/mailman/listinfo/ghc-commits

From hvriedel at gmail.com  Sat Mar  1 22:03:09 2014
From: hvriedel at gmail.com (Herbert Valerio Riedel)
Date: Sat, 01 Mar 2014 23:03:09 +0100
Subject: [commit: packages/base] ghc-7.8: Workaround failed
 constant-folding for zeroBits (591142f)
In-Reply-To: <59543203684B2244980D7E4057D5FBC1487D090F@DB3EX14MBXC306.europe.corp.microsoft.com>
 (Simon Peyton Jones's message of "Sat, 1 Mar 2014 21:17:18 +0000")
References: <20140301135323.7B8C42406B@ghc.haskell.org>
 <59543203684B2244980D7E4057D5FBC1487D090F@DB3EX14MBXC306.europe.corp.microsoft.com>
Message-ID: <87d2i54lwi.fsf@gmail.com>

On 2014-03-01 at 22:17:18 +0100, Simon Peyton Jones wrote:
> Herbert would you like to open a ticket, saying what's wrong and how
> to reproduce it?

Sure: https://ghc.haskell.org/trac/ghc/ticket/8832 :-)

Cheers,
  hvr

From juhpetersen at gmail.com  Sun Mar  2 13:23:11 2014
From: juhpetersen at gmail.com (Jens Petersen)
Date: Sun, 2 Mar 2014 22:23:11 +0900
Subject: RC2 release imminent
In-Reply-To: <CAEs96n0CTG7EqMGDNu0P3V1Od-AskB8zAdU8XdnfDMnCPiEqSQ@mail.gmail.com>
References: <CAEs96n2j0oyvTeYecrgdfHsJgzCRexz=LTf8smta9UQSONbd5w@mail.gmail.com>
 <CAHnG2CwkfT2+16+W0Z=C8xabtRXW6vmpf7n_X7N9+Zt6vbL8yw@mail.gmail.com>
 <CAK-hX0=N-sDjQPy8VY+qwgndvR5B+qMVJZja1=mVT=YcWyhqpg@mail.gmail.com>
 <CAHnG2CyPf4bsMtY1Bm5sRjgbaCC4wYeBj6TBQqBjdkB_HkOo_g@mail.gmail.com>
 <CAEs96n3X1NUY0OmpsjGgM+t2HYxx1VOkDb9X0vED2zwDeu7qpA@mail.gmail.com>
 <CAEDGBqLRsXbARK=o1D-MYfxkiaQ_sjipNimQYHpXSNcHZkwbow@mail.gmail.com>
 <CAEs96n0CTG7EqMGDNu0P3V1Od-AskB8zAdU8XdnfDMnCPiEqSQ@mail.gmail.com>
Message-ID: <CAEDGBqKmPEjQqEPnat4=iUzLzavOr5nYe0_wotDHbde=K5V0OA@mail.gmail.com>

>
> New source distributions are available here:
> http://www.haskell.org/ghc/dist/7.8.1-rc2/


Thanks!  (I would have just called it RC3:)

I have done a couple of testbuilds:

http://koji.fedoraproject.org/koji/taskinfo?taskID=6586630 (built against
ghc-7.6.3)

and a build in my Fedora Copr ghc-7.8 repo for Fedora 20
http://copr.fedoraproject.org/coprs/petersen/ghc-7.8/ (against the original
RC2)
which gave the following testsuite results:

* x86_64 Linux

 0:17:38 spent to go through
    3898 total tests, which gave rise to
   12789 test cases, of which
    9232 were skipped
      48 had missing libraries
    3448 expected passes
      58 expected failures
       0 caused framework failures
       0 unexpected passes
       3 unexpected failures
Unexpected failures:
   codeGen/should_run  T8256 [exit code non-0] (normal)
   perf/compiler       T4801 [stat not good enough] (normal)
   rts                 T8124 [exit code non-0] (normal)

* i686 Linux

 0:17:03 spent to go through
    3898 total tests, which gave rise to
   12789 test cases, of which
    9236 were skipped
      48 had missing libraries
    3439 expected passes
      57 expected failures
       3 caused framework failures
       0 unexpected passes
       9 unexpected failures
Unexpected failures:
   ../../libraries/base/tests  T8766 [stat too good] (normal)
   codeGen/should_run          T8256 [exit code non-0] (normal)
   perf/compiler               T1969 [stat not good enough] (normal)
   perf/compiler               T3064 [stat not good enough] (normal)
   perf/compiler               T6048 [stat not good enough] (optasm)
   perf/haddock                haddock.Cabal [stat not good enough] (normal)
   perf/haddock                haddock.base [stat not good enough] (normal)
   perf/haddock                haddock.compiler [stat not good enough] (normal)
   rts                         T8124 [exit code non-0] (normal)

Since there were some "unexpected failures" I thought I would post then here.

I started a full production build on there now too, which might finish in 45min.

Jens
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/ghc-devs/attachments/20140302/65c17113/attachment.html>

From nathan.d.howell at gmail.com  Sun Mar  2 19:20:27 2014
From: nathan.d.howell at gmail.com (Nathan Howell)
Date: Sun, 2 Mar 2014 11:20:27 -0800
Subject: What does the DWARF information generated by your GHC branch look
 like?
In-Reply-To: <CAK-tuPbGDWa47ZX8LxLqNXyQGMyq6XQsu3+7xQE3a8_5wBTskw@mail.gmail.com>
References: <CAK-tuPZK0XbZPYPji6j92xShBYaTaUMyXtsa_SGLYEJ3ZKVXeg@mail.gmail.com>
 <1393523035.15054.49.camel@cslin101.csunix.comp.leeds.ac.uk>
 <CAK-tuPaVvRJyKORtt2+AY-C3-rDbWKJv5VYeYjhrp4de7X1deA@mail.gmail.com>
 <1393596952.3893.14.camel@cslin101.csunix.comp.leeds.ac.uk>
 <CAK-tuPbGDWa47ZX8LxLqNXyQGMyq6XQsu3+7xQE3a8_5wBTskw@mail.gmail.com>
Message-ID: <CAD84eiH_JzZoQuRwE0SDDHb7oRLV=xqngmzo+DRX6F0CRCWamg@mail.gmail.com>

I did get a language ID assigned a couple years ago, it should be in DWARF
5.

Accepted:  DW_LANG_Haskell assigned value 0x18. -- April 18.2012

http://dwarfstd.org/ShowIssue.php?issue=120218.1



On Fri, Feb 28, 2014 at 7:34 AM, Johan Tibell <johan.tibell at gmail.com>wrote:

> On Fri, Feb 28, 2014 at 3:15 PM, Peter Wortmann <scpmw at leeds.ac.uk> wrote:
>
>> Johan Tibell wrote:> Lets try to get our name standardized and pushed
>> into GDB. It's
>> > hopefully as simple as sending an email to the GDB devs.
>>
>> Strictly speaking standardization is the job of the DWARF format
>> committee, which seem to currently be in the process of specifying
>> DWARF5[1]. Not quite sure we have a strong enough case, but if we wanted
>> our own language ID these would probably be the right people to ask.
>>
>
> I just emailed the DWARF discussion mailing list to sort this out.
>
> -- Johan
>
>
> _______________________________________________
> ghc-devs mailing list
> ghc-devs at haskell.org
> http://www.haskell.org/mailman/listinfo/ghc-devs
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/ghc-devs/attachments/20140302/5ec10f56/attachment.html>

From ralph.benzinger at sap.com  Mon Mar  3 07:39:02 2014
From: ralph.benzinger at sap.com (Benzinger, Ralph)
Date: Mon, 3 Mar 2014 07:39:02 +0000
Subject: Runtime error using LLVM bitcode execution
In-Reply-To: <53105A0F.8020407@gmail.com>
References: <06032AAF9E11164BB3D2827F725F47985C5C5AB8@DEWDFEMB12B.global.corp.sap>
 <530DA1A1.7040600@gmail.com>
 <06032AAF9E11164BB3D2827F725F47985C5C6718@DEWDFEMB12B.global.corp.sap>
 <53105A0F.8020407@gmail.com>
Message-ID: <06032AAF9E11164BB3D2827F725F47986D672533@DEWDFEMB12A.global.corp.sap>

Hallo Simon,

Oh, I see ...  Well, that's unfortunate, as we're working with the .ll files rather than the .s files.

I guess I'll try to create my own mangler that will work on the .ll files instead, if that's feasible ...

Regards
Ralph

 
-----Original Message-----
From: Simon Marlow [mailto:marlowsd at gmail.com] 
Sent: Freitag, 28. Februar 2014 10:43
To: Benzinger, Ralph; ghc-devs at haskell.org
Subject: Re: Runtime error using LLVM bitcode execution

You need to run it against the assembly file (.s) that LLVM generates, 
not the .ll file.

Cheers,
Simon

On 28/02/2014 08:48, Benzinger, Ralph wrote:
> Hello Simon,
>
> Thanks for your suggestion!  I ran the LLVM mangler against the hfun.ll file, but it didn't make any changes to the code at all.  (My understanding is that I can leave the hfun_stub alone.)
>
> Am I missing something?
>
> Regards
> Ralph
>
>
> -----Original Message-----
> From: Simon Marlow [mailto:marlowsd at gmail.com]
> Sent: Mittwoch, 26. Februar 2014 09:11
> To: Benzinger, Ralph; ghc-devs at haskell.org
> Subject: Re: Runtime error using LLVM bitcode execution
>
> My guess is that this isn't working because GHC needs to post-process
> the assembly generated by LLVM to support tables-next-to-code.  You
> could extract this phase from GHC (it's just one module, in
> compiler/llvmGen/LlvmMangler.hs) and run it as a standalone program.
>
> Cheers,
> Simon
>
> On 21/02/2014 16:02, Benzinger, Ralph wrote:
>> Hello,
>>
>> My apologies in advance if this mailing list is not the appropriate
>> address for posting my problem with the GHC runtime, but it seemed
>> like the best option on the GHC home page.
>>
>> I'm trying to execute standalone Haskell functions exported via FFI
>> and compiled as LLVM bitcode.  Unfortunately, all my efforts yield the
>> following runtime error:
>>
>> lu003107:~/hs-bitcode> ./bce_so hsallinone.bc
>> hs_init complete
>> hs_add_root complete
>> hsallinone: internal error: stg_ap_p_ret
>>       (GHC version 7.6.3 for x86_64_unknown_linux)
>>       Please report this as a GHC bug:  http://www.haskell.org/ghc/reportabug
>> 0  bce_so               0x0000000000d6b310
>> 1  bce_so               0x0000000000d6b53b
>> 2  bce_so               0x0000000000d6ba1c
>> 3  libpthread.so.0      0x00007f7683298800
>> 4  libc.so.6            0x00007f7682592b35 gsignal + 53
>> 5  libc.so.6            0x00007f7682594111 abort + 385
>> 6  libHSrts-ghc7.6.3.so 0x00007f7683f6ca21 rtsFatalInternalErrorFn + 177
>> 7  libHSrts-ghc7.6.3.so 0x00007f7683f6cce1 barf + 145
>> 8  libHSrts-ghc7.6.3.so 0x00007f7683f8a24a stg_ap_p_info + 130
>> Stack dump:
>> 0.      Program arguments: ./bce_so hsallinone.bc
>> Aborted
>>
>> This is what I do:
>>
>> I have a function hfun.hs that exports a function
>>
>>       foreign export ccall hfun :: CInt -> CInt
>>
>> and a wrapper cmain.c that calls this function:
>>
>>       #include <HsFFI.h>
>>       #include "hfun_stub.h"
>>       extern void __stginit_HFun(void);
>>       #include <stdio.h>
>>
>>       int main(int argc, char *argv[])
>>       {
>> 	hs_init(&argc, &argv);
>> 	printf("hs_init complete\n");
>>
>> 	hs_add_root(__stginit_HFun);
>>       	printf("hs_add_root complete\n");
>>
>>       	int i = hfun(42);
>>       	printf("hfun(42) = %d\n", i);
>>
>>       	hs_exit();
>>       	return 0;
>>       }
>>
>> To generate a callable bitcode file I use these commands:
>>
>>       $ ghc -S -keep-llvm-files -keep-tmp-files hfun.hs
>>       $ llvm-as hfun.ll
>>       $ cp /tmp/... hfun_stub.c
>>       $ clang -c -emit-llvm -I /opt/ghc/lib/ghc-7.6.3/include hfun_stub.c
>>       $ clang -c -emit-llvm -I /opt/ghc/lib/ghc-7.6.3/include cmain.c
>>       $ llvm-link cmain.bc hfun_stub.bc hfun.bc -o hsallinone.bc
>>
>> My main program "bce_so" loads the linked bitcode and feeds it to the
>> LLVM execution engine.  All required Haskell runtime libraries are
>> linked dynamically against bce_so.
>>
>> Could you kindly provide some insight on whether this runtime error is
>> due to a bug with GHC (unlikely) or rather some negligence in my
>> setup?  Or does the issue highlight some principal limitation in my
>> (admittedly somewhat naive) approach of using LLVM -- threading
>> support, maybe?
>>
>> Note that compiling hfun.hs/cmain.c into a .so and executing
>> everything natively using ldload() works flawlessly.
>>
>> Regards
>> Ralph
>>

From nathan.d.howell at gmail.com  Mon Mar  3 07:58:24 2014
From: nathan.d.howell at gmail.com (Nathan Howell)
Date: Sun, 2 Mar 2014 23:58:24 -0800
Subject: Runtime error using LLVM bitcode execution
In-Reply-To: <06032AAF9E11164BB3D2827F725F47986D672533@DEWDFEMB12A.global.corp.sap>
References: <06032AAF9E11164BB3D2827F725F47985C5C5AB8@DEWDFEMB12B.global.corp.sap>
 <530DA1A1.7040600@gmail.com>
 <06032AAF9E11164BB3D2827F725F47985C5C6718@DEWDFEMB12B.global.corp.sap>
 <53105A0F.8020407@gmail.com>
 <06032AAF9E11164BB3D2827F725F47986D672533@DEWDFEMB12A.global.corp.sap>
Message-ID: <CAD84eiHU1oQS5PjLpuCrG6iv=i11D4oNwf4Z9pV=MYyyj5r_WQ@mail.gmail.com>

Slightly related... is it possible to implement the evil mangler as an LLVM
MC optimization instead of a standalone post-processor? Seems like it could
be faster.


On Sun, Mar 2, 2014 at 11:39 PM, Benzinger, Ralph
<ralph.benzinger at sap.com>wrote:

> Hallo Simon,
>
> Oh, I see ...  Well, that's unfortunate, as we're working with the .ll
> files rather than the .s files.
>
> I guess I'll try to create my own mangler that will work on the .ll files
> instead, if that's feasible ...
>
> Regards
> Ralph
>
>
> -----Original Message-----
> From: Simon Marlow [mailto:marlowsd at gmail.com]
> Sent: Freitag, 28. Februar 2014 10:43
> To: Benzinger, Ralph; ghc-devs at haskell.org
> Subject: Re: Runtime error using LLVM bitcode execution
>
> You need to run it against the assembly file (.s) that LLVM generates,
> not the .ll file.
>
> Cheers,
> Simon
>
> On 28/02/2014 08:48, Benzinger, Ralph wrote:
> > Hello Simon,
> >
> > Thanks for your suggestion!  I ran the LLVM mangler against the hfun.ll
> file, but it didn't make any changes to the code at all.  (My understanding
> is that I can leave the hfun_stub alone.)
> >
> > Am I missing something?
> >
> > Regards
> > Ralph
> >
> >
> > -----Original Message-----
> > From: Simon Marlow [mailto:marlowsd at gmail.com]
> > Sent: Mittwoch, 26. Februar 2014 09:11
> > To: Benzinger, Ralph; ghc-devs at haskell.org
> > Subject: Re: Runtime error using LLVM bitcode execution
> >
> > My guess is that this isn't working because GHC needs to post-process
> > the assembly generated by LLVM to support tables-next-to-code.  You
> > could extract this phase from GHC (it's just one module, in
> > compiler/llvmGen/LlvmMangler.hs) and run it as a standalone program.
> >
> > Cheers,
> > Simon
> >
> > On 21/02/2014 16:02, Benzinger, Ralph wrote:
> >> Hello,
> >>
> >> My apologies in advance if this mailing list is not the appropriate
> >> address for posting my problem with the GHC runtime, but it seemed
> >> like the best option on the GHC home page.
> >>
> >> I'm trying to execute standalone Haskell functions exported via FFI
> >> and compiled as LLVM bitcode.  Unfortunately, all my efforts yield the
> >> following runtime error:
> >>
> >> lu003107:~/hs-bitcode> ./bce_so hsallinone.bc
> >> hs_init complete
> >> hs_add_root complete
> >> hsallinone: internal error: stg_ap_p_ret
> >>       (GHC version 7.6.3 for x86_64_unknown_linux)
> >>       Please report this as a GHC bug:
> http://www.haskell.org/ghc/reportabug
> >> 0  bce_so               0x0000000000d6b310
> >> 1  bce_so               0x0000000000d6b53b
> >> 2  bce_so               0x0000000000d6ba1c
> >> 3  libpthread.so.0      0x00007f7683298800
> >> 4  libc.so.6            0x00007f7682592b35 gsignal + 53
> >> 5  libc.so.6            0x00007f7682594111 abort + 385
> >> 6  libHSrts-ghc7.6.3.so 0x00007f7683f6ca21 rtsFatalInternalErrorFn +
> 177
> >> 7  libHSrts-ghc7.6.3.so 0x00007f7683f6cce1 barf + 145
> >> 8  libHSrts-ghc7.6.3.so 0x00007f7683f8a24a stg_ap_p_info + 130
> >> Stack dump:
> >> 0.      Program arguments: ./bce_so hsallinone.bc
> >> Aborted
> >>
> >> This is what I do:
> >>
> >> I have a function hfun.hs that exports a function
> >>
> >>       foreign export ccall hfun :: CInt -> CInt
> >>
> >> and a wrapper cmain.c that calls this function:
> >>
> >>       #include <HsFFI.h>
> >>       #include "hfun_stub.h"
> >>       extern void __stginit_HFun(void);
> >>       #include <stdio.h>
> >>
> >>       int main(int argc, char *argv[])
> >>       {
> >>      hs_init(&argc, &argv);
> >>      printf("hs_init complete\n");
> >>
> >>      hs_add_root(__stginit_HFun);
> >>              printf("hs_add_root complete\n");
> >>
> >>              int i = hfun(42);
> >>              printf("hfun(42) = %d\n", i);
> >>
> >>              hs_exit();
> >>              return 0;
> >>       }
> >>
> >> To generate a callable bitcode file I use these commands:
> >>
> >>       $ ghc -S -keep-llvm-files -keep-tmp-files hfun.hs
> >>       $ llvm-as hfun.ll
> >>       $ cp /tmp/... hfun_stub.c
> >>       $ clang -c -emit-llvm -I /opt/ghc/lib/ghc-7.6.3/include
> hfun_stub.c
> >>       $ clang -c -emit-llvm -I /opt/ghc/lib/ghc-7.6.3/include cmain.c
> >>       $ llvm-link cmain.bc hfun_stub.bc hfun.bc -o hsallinone.bc
> >>
> >> My main program "bce_so" loads the linked bitcode and feeds it to the
> >> LLVM execution engine.  All required Haskell runtime libraries are
> >> linked dynamically against bce_so.
> >>
> >> Could you kindly provide some insight on whether this runtime error is
> >> due to a bug with GHC (unlikely) or rather some negligence in my
> >> setup?  Or does the issue highlight some principal limitation in my
> >> (admittedly somewhat naive) approach of using LLVM -- threading
> >> support, maybe?
> >>
> >> Note that compiling hfun.hs/cmain.c into a .so and executing
> >> everything natively using ldload() works flawlessly.
> >>
> >> Regards
> >> Ralph
> >>
> _______________________________________________
> ghc-devs mailing list
> ghc-devs at haskell.org
> http://www.haskell.org/mailman/listinfo/ghc-devs
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/ghc-devs/attachments/20140302/6df45231/attachment-0001.html>

From marlowsd at gmail.com  Mon Mar  3 08:39:56 2014
From: marlowsd at gmail.com (Simon Marlow)
Date: Mon, 03 Mar 2014 08:39:56 +0000
Subject: Runtime error using LLVM bitcode execution
In-Reply-To: <CAD84eiHU1oQS5PjLpuCrG6iv=i11D4oNwf4Z9pV=MYyyj5r_WQ@mail.gmail.com>
References: <06032AAF9E11164BB3D2827F725F47985C5C5AB8@DEWDFEMB12B.global.corp.sap>	<530DA1A1.7040600@gmail.com>	<06032AAF9E11164BB3D2827F725F47985C5C6718@DEWDFEMB12B.global.corp.sap>	<53105A0F.8020407@gmail.com>	<06032AAF9E11164BB3D2827F725F47986D672533@DEWDFEMB12A.global.corp.sap>
 <CAD84eiHU1oQS5PjLpuCrG6iv=i11D4oNwf4Z9pV=MYyyj5r_WQ@mail.gmail.com>
Message-ID: <53143FDC.5060407@gmail.com>

I believe the problem is that we can't represent the output of the 
mangler in LLVM's intermediate language as it stands.  Although I think 
it may now be possible to do this with LLVM 3.4:

http://www.haskell.org/pipermail/ghc-devs/2013-September/002565.html

GHC's code generator needs to be updated to take advantage of this.  Is 
anyone interested in looking into it?

Cheers,
Simon

On 03/03/14 07:58, Nathan Howell wrote:
> Slightly related... is it possible to implement the evil mangler as an
> LLVM MC optimization instead of a standalone post-processor? Seems like
> it could be faster.
>
>
> On Sun, Mar 2, 2014 at 11:39 PM, Benzinger, Ralph
> <ralph.benzinger at sap.com <mailto:ralph.benzinger at sap.com>> wrote:
>
>     Hallo Simon,
>
>     Oh, I see ...  Well, that's unfortunate, as we're working with the
>     .ll files rather than the .s files.
>
>     I guess I'll try to create my own mangler that will work on the .ll
>     files instead, if that's feasible ...
>
>     Regards
>     Ralph
>
>
>     -----Original Message-----
>     From: Simon Marlow [mailto:marlowsd at gmail.com
>     <mailto:marlowsd at gmail.com>]
>     Sent: Freitag, 28. Februar 2014 10:43
>     To: Benzinger, Ralph; ghc-devs at haskell.org <mailto:ghc-devs at haskell.org>
>     Subject: Re: Runtime error using LLVM bitcode execution
>
>     You need to run it against the assembly file (.s) that LLVM generates,
>     not the .ll file.
>
>     Cheers,
>     Simon
>
>     On 28/02/2014 08:48, Benzinger, Ralph wrote:
>      > Hello Simon,
>      >
>      > Thanks for your suggestion!  I ran the LLVM mangler against the
>     hfun.ll file, but it didn't make any changes to the code at all.
>       (My understanding is that I can leave the hfun_stub alone.)
>      >
>      > Am I missing something?
>      >
>      > Regards
>      > Ralph
>      >
>      >
>      > -----Original Message-----
>      > From: Simon Marlow [mailto:marlowsd at gmail.com
>     <mailto:marlowsd at gmail.com>]
>      > Sent: Mittwoch, 26. Februar 2014 09:11
>      > To: Benzinger, Ralph; ghc-devs at haskell.org
>     <mailto:ghc-devs at haskell.org>
>      > Subject: Re: Runtime error using LLVM bitcode execution
>      >
>      > My guess is that this isn't working because GHC needs to post-process
>      > the assembly generated by LLVM to support tables-next-to-code.  You
>      > could extract this phase from GHC (it's just one module, in
>      > compiler/llvmGen/LlvmMangler.hs) and run it as a standalone program.
>      >
>      > Cheers,
>      > Simon
>      >
>      > On 21/02/2014 16:02, Benzinger, Ralph wrote:
>      >> Hello,
>      >>
>      >> My apologies in advance if this mailing list is not the appropriate
>      >> address for posting my problem with the GHC runtime, but it seemed
>      >> like the best option on the GHC home page.
>      >>
>      >> I'm trying to execute standalone Haskell functions exported via FFI
>      >> and compiled as LLVM bitcode.  Unfortunately, all my efforts
>     yield the
>      >> following runtime error:
>      >>
>      >> lu003107:~/hs-bitcode> ./bce_so hsallinone.bc
>      >> hs_init complete
>      >> hs_add_root complete
>      >> hsallinone: internal error: stg_ap_p_ret
>      >>       (GHC version 7.6.3 for x86_64_unknown_linux)
>      >>       Please report this as a GHC bug:
>     http://www.haskell.org/ghc/reportabug
>      >> 0  bce_so               0x0000000000d6b310
>      >> 1  bce_so               0x0000000000d6b53b
>      >> 2  bce_so               0x0000000000d6ba1c
>      >> 3  libpthread.so.0      0x00007f7683298800
>      >> 4  libc.so.6            0x00007f7682592b35 gsignal + 53
>      >> 5  libc.so.6            0x00007f7682594111 abort + 385
>      >> 6 libHSrts-ghc7.6.3.so <http://libHSrts-ghc7.6.3.so>
>     0x00007f7683f6ca21 rtsFatalInternalErrorFn + 177
>      >> 7 libHSrts-ghc7.6.3.so <http://libHSrts-ghc7.6.3.so>
>     0x00007f7683f6cce1 barf + 145
>      >> 8 libHSrts-ghc7.6.3.so <http://libHSrts-ghc7.6.3.so>
>     0x00007f7683f8a24a stg_ap_p_info + 130
>      >> Stack dump:
>      >> 0.      Program arguments: ./bce_so hsallinone.bc
>      >> Aborted
>      >>
>      >> This is what I do:
>      >>
>      >> I have a function hfun.hs that exports a function
>      >>
>      >>       foreign export ccall hfun :: CInt -> CInt
>      >>
>      >> and a wrapper cmain.c that calls this function:
>      >>
>      >>       #include <HsFFI.h>
>      >>       #include "hfun_stub.h"
>      >>       extern void __stginit_HFun(void);
>      >>       #include <stdio.h>
>      >>
>      >>       int main(int argc, char *argv[])
>      >>       {
>      >>      hs_init(&argc, &argv);
>      >>      printf("hs_init complete\n");
>      >>
>      >>      hs_add_root(__stginit_HFun);
>      >>              printf("hs_add_root complete\n");
>      >>
>      >>              int i = hfun(42);
>      >>              printf("hfun(42) = %d\n", i);
>      >>
>      >>              hs_exit();
>      >>              return 0;
>      >>       }
>      >>
>      >> To generate a callable bitcode file I use these commands:
>      >>
>      >>       $ ghc -S -keep-llvm-files -keep-tmp-files hfun.hs
>      >>       $ llvm-as hfun.ll
>      >>       $ cp /tmp/... hfun_stub.c
>      >>       $ clang -c -emit-llvm -I /opt/ghc/lib/ghc-7.6.3/include
>     hfun_stub.c
>      >>       $ clang -c -emit-llvm -I /opt/ghc/lib/ghc-7.6.3/include
>     cmain.c
>      >>       $ llvm-link cmain.bc hfun_stub.bc hfun.bc -o hsallinone.bc
>      >>
>      >> My main program "bce_so" loads the linked bitcode and feeds it
>     to the
>      >> LLVM execution engine.  All required Haskell runtime libraries are
>      >> linked dynamically against bce_so.
>      >>
>      >> Could you kindly provide some insight on whether this runtime
>     error is
>      >> due to a bug with GHC (unlikely) or rather some negligence in my
>      >> setup?  Or does the issue highlight some principal limitation in my
>      >> (admittedly somewhat naive) approach of using LLVM -- threading
>      >> support, maybe?
>      >>
>      >> Note that compiling hfun.hs/cmain.c into a .so and executing
>      >> everything natively using ldload() works flawlessly.
>      >>
>      >> Regards
>      >> Ralph
>      >>
>     _______________________________________________
>     ghc-devs mailing list
>     ghc-devs at haskell.org <mailto:ghc-devs at haskell.org>
>     http://www.haskell.org/mailman/listinfo/ghc-devs
>
>


From the.dead.shall.rise at gmail.com  Mon Mar  3 12:30:06 2014
From: the.dead.shall.rise at gmail.com (Mikhail Glushenkov)
Date: Mon, 3 Mar 2014 13:30:06 +0100
Subject: Runtime error using LLVM bitcode execution
In-Reply-To: <53143FDC.5060407@gmail.com>
References: <06032AAF9E11164BB3D2827F725F47985C5C5AB8@DEWDFEMB12B.global.corp.sap>
 <530DA1A1.7040600@gmail.com>
 <06032AAF9E11164BB3D2827F725F47985C5C6718@DEWDFEMB12B.global.corp.sap>
 <53105A0F.8020407@gmail.com>
 <06032AAF9E11164BB3D2827F725F47986D672533@DEWDFEMB12A.global.corp.sap>
 <CAD84eiHU1oQS5PjLpuCrG6iv=i11D4oNwf4Z9pV=MYyyj5r_WQ@mail.gmail.com>
 <53143FDC.5060407@gmail.com>
Message-ID: <CA+tcxkBziw=7Fdicx2Hik=JN0D0ZnG_JvtjdWRMDir==ue=dZg@mail.gmail.com>

Hello Simon,

On 3 March 2014 09:39, Simon Marlow <marlowsd at gmail.com> wrote:
> I believe the problem is that we can't represent the output of the mangler
> in LLVM's intermediate language as it stands.  Although I think it may now
> be possible to do this with LLVM 3.4:
>
> http://www.haskell.org/pipermail/ghc-devs/2013-September/002565.html
>
> GHC's code generator needs to be updated to take advantage of this.  Is
> anyone interested in looking into it?

IIUC, GHC can't take advantage of this yet, because global symbol
offsets [1] are not yet implemented. LLVM currently doesn't allow
arbitrary function prefix data, but requires prefix data to "begin
with a sequence of bytes which decode to a sequence of machine
instructions, [...] which transfer control to the point immediately
succeeding the prefix data" [2].

[1] http://lists.cs.uiuc.edu/pipermail/llvmdev/2013-April/061511.html
[2] http://llvm.org/docs/LangRef.html#prefix-data

From scpmw at leeds.ac.uk  Mon Mar  3 13:54:03 2014
From: scpmw at leeds.ac.uk (Peter Wortmann)
Date: Mon, 03 Mar 2014 13:54:03 +0000
Subject: What does the DWARF information generated by your GHC branch
 look like?
In-Reply-To: <CAD84eiH_JzZoQuRwE0SDDHb7oRLV=xqngmzo+DRX6F0CRCWamg@mail.gmail.com>
References: <CAK-tuPZK0XbZPYPji6j92xShBYaTaUMyXtsa_SGLYEJ3ZKVXeg@mail.gmail.com>
 <1393523035.15054.49.camel@cslin101.csunix.comp.leeds.ac.uk>
 <CAK-tuPaVvRJyKORtt2+AY-C3-rDbWKJv5VYeYjhrp4de7X1deA@mail.gmail.com>
 <1393596952.3893.14.camel@cslin101.csunix.comp.leeds.ac.uk>
 <CAK-tuPbGDWa47ZX8LxLqNXyQGMyq6XQsu3+7xQE3a8_5wBTskw@mail.gmail.com>
 <CAD84eiH_JzZoQuRwE0SDDHb7oRLV=xqngmzo+DRX6F0CRCWamg@mail.gmail.com>
Message-ID: <1393854843.4721.27.camel@cslin101.csunix.comp.leeds.ac.uk>


Nathan Howell wrote:
> I did get a language ID assigned a couple years ago, it should be in DWARF
> 5.
> 
> Accepted:  DW_LANG_Haskell assigned value 0x18. -- April 18.2012

Nice work. We'll start using that one then :)

Greetings,
  Peter Wortmann




From johan.tibell at gmail.com  Mon Mar  3 14:22:54 2014
From: johan.tibell at gmail.com (Johan Tibell)
Date: Mon, 3 Mar 2014 15:22:54 +0100
Subject: What does the DWARF information generated by your GHC branch look
 like?
In-Reply-To: <1393854843.4721.27.camel@cslin101.csunix.comp.leeds.ac.uk>
References: <CAK-tuPZK0XbZPYPji6j92xShBYaTaUMyXtsa_SGLYEJ3ZKVXeg@mail.gmail.com>
 <1393523035.15054.49.camel@cslin101.csunix.comp.leeds.ac.uk>
 <CAK-tuPaVvRJyKORtt2+AY-C3-rDbWKJv5VYeYjhrp4de7X1deA@mail.gmail.com>
 <1393596952.3893.14.camel@cslin101.csunix.comp.leeds.ac.uk>
 <CAK-tuPbGDWa47ZX8LxLqNXyQGMyq6XQsu3+7xQE3a8_5wBTskw@mail.gmail.com>
 <CAD84eiH_JzZoQuRwE0SDDHb7oRLV=xqngmzo+DRX6F0CRCWamg@mail.gmail.com>
 <1393854843.4721.27.camel@cslin101.csunix.comp.leeds.ac.uk>
Message-ID: <CAK-tuPZCnL9DK0qMtWsnw5R235qjdbX6hevQvnd4GEJs+Z-Ktw@mail.gmail.com>

On Mon, Mar 3, 2014 at 2:54 PM, Peter Wortmann <scpmw at leeds.ac.uk> wrote:
>
> Nathan Howell wrote:
>> I did get a language ID assigned a couple years ago, it should be in DWARF
>> 5.
>>
>> Accepted:  DW_LANG_Haskell assigned value 0x18. -- April 18.2012
>
> Nice work. We'll start using that one then :)

Great!

-- Johan

From austin at well-typed.com  Mon Mar  3 18:23:25 2014
From: austin at well-typed.com (Austin Seipp)
Date: Mon, 3 Mar 2014 12:23:25 -0600
Subject: ANNOUNCE: GHC 7.8.1 Release Candidate 2
Message-ID: <CAEs96n328fs8Xj+oD0R4=rkPVkswZk3RQB6OpxxMv4o+bQ=qQA@mail.gmail.com>

We are pleased to announce the second release candidate for GHC 7.8.1:

    http://www.haskell.org/ghc/dist/7.8.1-rc2/
    http://www.haskell.org/ghc/docs/7.8.1-rc2/html/

This includes the source tarball and binary distributions for Windows,
Linux, OS X, FreeBSD, and Solaris, on x86 and x86_64, and more. There
are now two binary builds for Linux users: one for glibc 2.12 and GMP
4, primarily intended for RHEL users, and one built for glibc 2.13 and
GMP 5 - intended for Debian and more recent machines.

In addition, there is also an iOS cross compiler build (both in the
native ARM configuration and i386 simulator configurations), separate
Solaris 10 and Solaris 11 builds - the latter supporting dynamic
linking - and a new Linux/PPC64 build using glibc 2.18/GMP 5. There is
a signed copy of the SHA256 hashes available (attached) using my GPG
key (keyid 0x3B58D86F).

We're also now offering .tar.xz files, which roughly cut the size of
the binary distributions in half compared to bzip2.

We've closed approximately 45 tickets that people filed for RC1 in
this release. Thank you for all the reports!

We plan to make the final 7.8.1 release soon, and hope RC2 will be the
last RC. So *please* test as much as possible; bugs are much cheaper
if we find them before the release!

-- 
Regards,

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

From kazu at iij.ad.jp  Tue Mar  4 01:31:29 2014
From: kazu at iij.ad.jp (Kazu Yamamoto (=?iso-2022-jp?B?GyRCOzNLXE9CSScbKEI=?=))
Date: Tue, 04 Mar 2014 10:31:29 +0900 (JST)
Subject: ANNOUNCE: GHC 7.8.1 Release Candidate 2
In-Reply-To: <CAEs96n328fs8Xj+oD0R4=rkPVkswZk3RQB6OpxxMv4o+bQ=qQA@mail.gmail.com>
References: <CAEs96n328fs8Xj+oD0R4=rkPVkswZk3RQB6OpxxMv4o+bQ=qQA@mail.gmail.com>
Message-ID: <20140304.103129.2116935662663486630.kazu@iij.ad.jp>

Hi Austin,

> We've closed approximately 45 tickets that people filed for RC1 in
> this release. Thank you for all the reports!

Good work!

> We plan to make the final 7.8.1 release soon, and hope RC2 will be the
> last RC. So *please* test as much as possible; bugs are much cheaper
> if we find them before the release!

Unfortunately, ghc-7.8.0.20140228-src does not have:
	https://github.com/haskell/cabal/commit/ee6d1cf5cefe18f6d74ed379af21d92f8b0ae92d

So, ghc-7.8.0.20140228-x86_64-apple-darwin-mavericks does not use @rpath:

	% otool -L libHSmtl-2.1.2-ghc7.8.0.20140228.dylib 
	libHSmtl-2.1.2-ghc7.8.0.20140228.dylib:
		/Users/kazu/work/cab/.cabal-sandbox/lib/x86_64-osx-ghc-7.8.0.20140228/mtl-2.1.2/libHSmtl-2.1.2-ghc7.8.0.20140228.dylib (compatibility version 0.0.0, current version 0.0.0)

--Kazu

From austin at well-typed.com  Tue Mar  4 01:51:15 2014
From: austin at well-typed.com (Austin Seipp)
Date: Mon, 3 Mar 2014 19:51:15 -0600
Subject: ANNOUNCE: GHC 7.8.1 Release Candidate 2
In-Reply-To: <20140304.103129.2116935662663486630.kazu@iij.ad.jp>
References: <CAEs96n328fs8Xj+oD0R4=rkPVkswZk3RQB6OpxxMv4o+bQ=qQA@mail.gmail.com>
 <20140304.103129.2116935662663486630.kazu@iij.ad.jp>
Message-ID: <CAEs96n3j+aoWDjNL_4seues1PM5WS27SkN9vo=r7HdAxjVBypg@mail.gmail.com>

Hi Kazu,

It turns out this was an error on my part - thank you for pointing it
out. I've confirmed this exists with the current RC2 bindist. My
apologies.

We'll be syncing the Cabal submodule with the newest Cabal release
once Johan pushes it out, so this shouldn't happen again. Thanks!

On Mon, Mar 3, 2014 at 7:31 PM, Kazu Yamamoto <kazu at iij.ad.jp> wrote:
> Hi Austin,
>
>> We've closed approximately 45 tickets that people filed for RC1 in
>> this release. Thank you for all the reports!
>
> Good work!
>
>> We plan to make the final 7.8.1 release soon, and hope RC2 will be the
>> last RC. So *please* test as much as possible; bugs are much cheaper
>> if we find them before the release!
>
> Unfortunately, ghc-7.8.0.20140228-src does not have:
>         https://github.com/haskell/cabal/commit/ee6d1cf5cefe18f6d74ed379af21d92f8b0ae92d
>
> So, ghc-7.8.0.20140228-x86_64-apple-darwin-mavericks does not use @rpath:
>
>         % otool -L libHSmtl-2.1.2-ghc7.8.0.20140228.dylib
>         libHSmtl-2.1.2-ghc7.8.0.20140228.dylib:
>                 /Users/kazu/work/cab/.cabal-sandbox/lib/x86_64-osx-ghc-7.8.0.20140228/mtl-2.1.2/libHSmtl-2.1.2-ghc7.8.0.20140228.dylib (compatibility version 0.0.0, current version 0.0.0)
>
> --Kazu
> _______________________________________________
> ghc-devs mailing list
> ghc-devs at haskell.org
> http://www.haskell.org/mailman/listinfo/ghc-devs
>



-- 
Regards,

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

From jpm at cs.uu.nl  Tue Mar  4 08:17:02 2014
From: jpm at cs.uu.nl (=?ISO-8859-1?Q?Jos=E9_Pedro_Magalh=E3es?=)
Date: Tue, 4 Mar 2014 08:17:02 +0000
Subject: ANNOUNCE: GHC 7.8.1 Release Candidate 2
In-Reply-To: <CAEs96n328fs8Xj+oD0R4=rkPVkswZk3RQB6OpxxMv4o+bQ=qQA@mail.gmail.com>
References: <CAEs96n328fs8Xj+oD0R4=rkPVkswZk3RQB6OpxxMv4o+bQ=qQA@mail.gmail.com>
Message-ID: <CA+ZFbn_UsENrgU3hEw+mNDuvtwUZhGRWt=bmaciNLWD3LVscdw@mail.gmail.com>

Hello,

This GHC crashes whenever I try installing any package. (I guess this might
be due to cabal-install, though.)

Details:
  Using the RC2 at
http://www.haskell.org/ghc/dist/7.8.1-rc2/ghc-7.8.0.20140228-i386-unknown-mingw32.tar.xz
  OS: Win7 64bit
  cabal-install version 0.14.0
  using version 1.14.0 of the Cabal library
  cabal install --nats -v3 gives this output <http://lpaste.net/100678>,
and brings up a standard windows application crash window before the
"returned ExitFailure (-1073741819)" line with the following information:

Problem signature:
>   Problem Event Name: APPCRASH
>   Application Name: ghc.exe
>   Application Version: 0.0.0.0
>   Application Timestamp: 5312f1e1
>   Fault Module Name: ghc.exe
>   Fault Module Version: 0.0.0.0
>   Fault Module Timestamp: 5312f1e1
>   Exception Code: c0000005
>   Exception Offset: 01adb323
>   OS Version: 6.1.7601.2.1.0.768.3
>   Locale ID: 2057
>   Additional Information 1: 1548
>   Additional Information 2: 1548a4345bd8ec1f0510cd3884fa5889
>   Additional Information 3: daab
>   Additional Information 4: daabc1a5d9d41fd73825c2e9d33e1385


I have later updated cabal-install (to version 1.18.0.2 using version
1.18.1.2 of the Cabal library), but that
didn't change this problem. The same happened with RC1, btw.

Thanks,
Pedro



On Mon, Mar 3, 2014 at 6:23 PM, Austin Seipp <austin at well-typed.com> wrote:

> We are pleased to announce the second release candidate for GHC 7.8.1:
>
>     http://www.haskell.org/ghc/dist/7.8.1-rc2/
>     http://www.haskell.org/ghc/docs/7.8.1-rc2/html/
>
> This includes the source tarball and binary distributions for Windows,
> Linux, OS X, FreeBSD, and Solaris, on x86 and x86_64, and more. There
> are now two binary builds for Linux users: one for glibc 2.12 and GMP
> 4, primarily intended for RHEL users, and one built for glibc 2.13 and
> GMP 5 - intended for Debian and more recent machines.
>
> In addition, there is also an iOS cross compiler build (both in the
> native ARM configuration and i386 simulator configurations), separate
> Solaris 10 and Solaris 11 builds - the latter supporting dynamic
> linking - and a new Linux/PPC64 build using glibc 2.18/GMP 5. There is
> a signed copy of the SHA256 hashes available (attached) using my GPG
> key (keyid 0x3B58D86F).
>
> We're also now offering .tar.xz files, which roughly cut the size of
> the binary distributions in half compared to bzip2.
>
> We've closed approximately 45 tickets that people filed for RC1 in
> this release. Thank you for all the reports!
>
> We plan to make the final 7.8.1 release soon, and hope RC2 will be the
> last RC. So *please* test as much as possible; bugs are much cheaper
> if we find them before the release!
>
> --
> Regards,
>
> Austin Seipp, Haskell Consultant
> Well-Typed LLP, http://www.well-typed.com/
> _______________________________________________
> ghc-devs mailing list
> ghc-devs at haskell.org
> http://www.haskell.org/mailman/listinfo/ghc-devs
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/ghc-devs/attachments/20140304/52b18574/attachment.html>

From the.dead.shall.rise at gmail.com  Tue Mar  4 09:44:07 2014
From: the.dead.shall.rise at gmail.com (Mikhail Glushenkov)
Date: Tue, 4 Mar 2014 10:44:07 +0100
Subject: ANNOUNCE: GHC 7.8.1 Release Candidate 2
In-Reply-To: <CA+ZFbn_UsENrgU3hEw+mNDuvtwUZhGRWt=bmaciNLWD3LVscdw@mail.gmail.com>
References: <CAEs96n328fs8Xj+oD0R4=rkPVkswZk3RQB6OpxxMv4o+bQ=qQA@mail.gmail.com>
 <CA+ZFbn_UsENrgU3hEw+mNDuvtwUZhGRWt=bmaciNLWD3LVscdw@mail.gmail.com>
Message-ID: <CA+tcxkA-70Bk3fyUpzJLDUbW3zJOG17tqi2jydF2jUEOXH-SCA@mail.gmail.com>

Hello,

On 4 March 2014 09:17, Jos? Pedro Magalh?es <jpm at cs.uu.nl> wrote:
> Hello,
>
> This GHC crashes whenever I try installing any package. (I guess this might
> be due to cabal-install, though.)

No, looks like a GHC issue.

From simonpj at microsoft.com  Tue Mar  4 11:57:11 2014
From: simonpj at microsoft.com (Simon Peyton Jones)
Date: Tue, 4 Mar 2014 11:57:11 +0000
Subject: git.haskell.org misbehaving?
Message-ID: <59543203684B2244980D7E4057D5FBC1487D6085@DB3EX14MBXC306.europe.corp.microsoft.com>

I'm getting
fatal: read error: Connection reset by peer

when I try git pull from
            git://git.haskell.org/ghc.git

Works ok if I try
            http://git.haskell.org/ghc.git
This happens from both Windows and Linux.
Anyone know what is going on?
Simon
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/ghc-devs/attachments/20140304/d456d018/attachment.html>

From hvriedel at gmail.com  Tue Mar  4 12:28:42 2014
From: hvriedel at gmail.com (Herbert Valerio Riedel)
Date: Tue, 04 Mar 2014 13:28:42 +0100
Subject: git.haskell.org misbehaving?
In-Reply-To: <59543203684B2244980D7E4057D5FBC1487D6085@DB3EX14MBXC306.europe.corp.microsoft.com>
 (Simon Peyton Jones's message of "Tue, 4 Mar 2014 11:57:11 +0000")
References: <59543203684B2244980D7E4057D5FBC1487D6085@DB3EX14MBXC306.europe.corp.microsoft.com>
Message-ID: <871tyiw3k5.fsf@gmail.com>

On 2014-03-04 at 12:57:11 +0100, Simon Peyton Jones wrote:
> I'm getting
> fatal: read error: Connection reset by peer
>
> when I try git pull from
>             git://git.haskell.org/ghc.git
>
> Works ok if I try
>             http://git.haskell.org/ghc.git
> This happens from both Windows and Linux.
> Anyone know what is going on?

Fixed! 

It was a problem on ghc.haskell.org with git-daemon processes getting
stuck for some yet unknown reason (which I still need to investigate --
I've seen reports from other sites experiencing the same issue)

Austin, do we have monitoring for the git:// TCP port in place?

Cheers,
  hvr

From simonpj at microsoft.com  Tue Mar  4 12:33:35 2014
From: simonpj at microsoft.com (Simon Peyton Jones)
Date: Tue, 4 Mar 2014 12:33:35 +0000
Subject: git.haskell.org misbehaving?
In-Reply-To: <871tyiw3k5.fsf@gmail.com>
References: <59543203684B2244980D7E4057D5FBC1487D6085@DB3EX14MBXC306.europe.corp.microsoft.com>
 <871tyiw3k5.fsf@gmail.com>
Message-ID: <59543203684B2244980D7E4057D5FBC1487D6556@DB3EX14MBXC306.europe.corp.microsoft.com>

Thank you!

| -----Original Message-----
| From: Herbert Valerio Riedel [mailto:hvriedel at gmail.com]
| Sent: 04 March 2014 12:29
| To: Simon Peyton Jones
| Cc: ghc-devs at haskell.org; Austin Seipp
| Subject: Re: git.haskell.org misbehaving?
| 
| On 2014-03-04 at 12:57:11 +0100, Simon Peyton Jones wrote:
| > I'm getting
| > fatal: read error: Connection reset by peer
| >
| > when I try git pull from
| >             git://git.haskell.org/ghc.git
| >
| > Works ok if I try
| >             http://git.haskell.org/ghc.git This happens from both
| > Windows and Linux.
| > Anyone know what is going on?
| 
| Fixed!
| 
| It was a problem on ghc.haskell.org with git-daemon processes getting
| stuck for some yet unknown reason (which I still need to investigate --
| I've seen reports from other sites experiencing the same issue)
| 
| Austin, do we have monitoring for the git:// TCP port in place?
| 
| Cheers,
|   hvr

From mark.lentczner at gmail.com  Tue Mar  4 14:57:27 2014
From: mark.lentczner at gmail.com (Mark Lentczner)
Date: Tue, 4 Mar 2014 06:57:27 -0800
Subject: ANNOUNCE: GHC 7.8.1 Release Candidate 2
In-Reply-To: <CA+tcxkA-70Bk3fyUpzJLDUbW3zJOG17tqi2jydF2jUEOXH-SCA@mail.gmail.com>
References: <CAEs96n328fs8Xj+oD0R4=rkPVkswZk3RQB6OpxxMv4o+bQ=qQA@mail.gmail.com>
 <CA+ZFbn_UsENrgU3hEw+mNDuvtwUZhGRWt=bmaciNLWD3LVscdw@mail.gmail.com>
 <CA+tcxkA-70Bk3fyUpzJLDUbW3zJOG17tqi2jydF2jUEOXH-SCA@mail.gmail.com>
Message-ID: <CAAOoiFYzuty=juXEK6jABHb78ysRKqwAouiQS937gg4OyoyMXw@mail.gmail.com>

It looks like the Mac builds are specific to the version of Mac OS X they
were compiled on. This is very unfortunate, as now we'll have to produce at
least four variants of HP for each.

The only thing holding back a build on either Maverricks or Mountain Lion
(10.9 and 10.8) from working on 10.7 ~ 10.9 is the set of flags passed to
the c compiler. On a machine with only clang, these need three extra flags.

I had thought that there was a patch that allowed GCC to dynamically
determine if it was working with clang, and if so, pass the extra flags. It
didn't look like that patch made it in. I seem to have lost track of who
did this patch and it's status. Carter: do you remember?

For the platform, I might be able to patch around this with a variant of my
ghc-clang-wrapper script - beefing it up to remove those flags if not clang.

- Mark
?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/ghc-devs/attachments/20140304/6c107749/attachment.html>

From carter.schonwald at gmail.com  Tue Mar  4 17:32:00 2014
From: carter.schonwald at gmail.com (Carter Schonwald)
Date: Tue, 4 Mar 2014 12:32:00 -0500
Subject: ANNOUNCE: GHC 7.8.1 Release Candidate 2
In-Reply-To: <CAAOoiFYzuty=juXEK6jABHb78ysRKqwAouiQS937gg4OyoyMXw@mail.gmail.com>
References: <CAEs96n328fs8Xj+oD0R4=rkPVkswZk3RQB6OpxxMv4o+bQ=qQA@mail.gmail.com>
 <CA+ZFbn_UsENrgU3hEw+mNDuvtwUZhGRWt=bmaciNLWD3LVscdw@mail.gmail.com>
 <CA+tcxkA-70Bk3fyUpzJLDUbW3zJOG17tqi2jydF2jUEOXH-SCA@mail.gmail.com>
 <CAAOoiFYzuty=juXEK6jABHb78ysRKqwAouiQS937gg4OyoyMXw@mail.gmail.com>
Message-ID: <CAHYVw0z_D5pvx1M74eDZyVW3HyRB4jPZ9fvwEL6wP+Emegotpg@mail.gmail.com>

@mark, theres no runtime detection logic patch, theres just a config time
hack currently.

I've a work in progress partial patch to expose the CPP program choice +
flags into the ghc settings file,
https://ghc.haskell.org/trac/ghc/ticket/8683 , but lifes got me a bit
overloaded these past few weeks so we need someone to "own" finishing it up
(and i'm uncertain if i can hard allocate that time this week or next... i
have some personal obligations that need take priority).  That said, I may
find up finding some time to whack on it more

point being, agreed, the wrapper hack aint ok :)


On Tue, Mar 4, 2014 at 9:57 AM, Mark Lentczner <mark.lentczner at gmail.com>wrote:

> It looks like the Mac builds are specific to the version of Mac OS X they
> were compiled on. This is very unfortunate, as now we'll have to produce at
> least four variants of HP for each.
>
> The only thing holding back a build on either Maverricks or Mountain Lion
> (10.9 and 10.8) from working on 10.7 ~ 10.9 is the set of flags passed to
> the c compiler. On a machine with only clang, these need three extra flags.
>
> I had thought that there was a patch that allowed GCC to dynamically
> determine if it was working with clang, and if so, pass the extra flags. It
> didn't look like that patch made it in. I seem to have lost track of who
> did this patch and it's status. Carter: do you remember?
>
> For the platform, I might be able to patch around this with a variant of
> my ghc-clang-wrapper script - beefing it up to remove those flags if not
> clang.
>
> - Mark
> ?
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/ghc-devs/attachments/20140304/ccc5dc42/attachment.html>

From johan.tibell at gmail.com  Tue Mar  4 21:28:06 2014
From: johan.tibell at gmail.com (Johan Tibell)
Date: Tue, 4 Mar 2014 22:28:06 +0100
Subject: Cabal-1.18.1.3 and cabal-install-1.18.0.3 releases made
Message-ID: <CAK-tuPbBYoBFBprfsr3t96CLa3W_PEhEVPjxSLepDMjHM9tOGg@mail.gmail.com>

Hi,

I've just made a release of Cabal/cabal-install, for the benefit of GHC 7.8.

People have in the past expressed a desire for having prebuilt
binaries of cabal-install. I'm happy to upload such binaries if people
send them to me. Please specify for which arch/OS the binary is built.

-- Johan

From ltclifton at gmail.com  Wed Mar  5 05:18:01 2014
From: ltclifton at gmail.com (Luke Clifton)
Date: Wed, 5 Mar 2014 13:18:01 +0800
Subject: GHC 7.8 RC2: ARM cross compiler (LLVM Error)
Message-ID: <CAEvi2wE2EJTkqWZPv=Rfy3DYWAf=1E8SvkgWxbgmd=Q=jN=gUQ@mail.gmail.com>

Hi,

I successfully compiled a native GHC 7.8 RC2 from the source distribution.

I now want to create an GHC cross compiler targeting ARM. So I do a

 ./configure --target=arm-linux-gnueabi --with-gcc=arm-linux-gnueabi-gcc

(I don't know why I have to explicitly supply the GCC, documentation seems
to suggest that it would pick that up based on target, which it seems to do
for ld.)

I then make a copy of the mk/build.mk.sample and place it at mk/build.mk and
uncomment the BuildFlavour = quick-cross line.

At this point I run make and it goes along happily until...

 "inplace/bin/ghc-stage1" -hisuf hi -osuf  o -hcsuf hc -static  -H64m -O0
 -package-name haskeline-0.7.1.2 -hide-all-packages -i
-ilibraries/haskeline/. -ilibraries/haskeline/dist-install/build
-ilibraries/haskeline/dist-install/build/autogen
-Ilibraries/haskeline/dist-install/build
-Ilibraries/haskeline/dist-install/build/autogen
-Ilibraries/haskeline/includes   -optP-DUSE_GHC_ENCODINGS -optP-DTERMINFO
-optP-include
-optPlibraries/haskeline/dist-install/build/autogen/cabal_macros.h -package
base-4.7.0.0 -package bytestring-0.10.4.0 -package containers-0.5.4.0
-package directory-1.2.0.2 -package filepath-1.3.0.2 -package
terminfo-0.4.0.0 -package transformers-0.3.0.0 -package unix-2.7.0.1 -Wall
-XHaskell98 -XForeignFunctionInterface -XRank2Types -XFlexibleInstances
-XTypeSynonymInstances -XFlexibleContexts -XExistentialQuantification
-XScopedTypeVariables -XGeneralizedNewtypeDeriving -XMultiParamTypeClasses
-XOverlappingInstances -XUndecidableInstances -XCPP -XDeriveDataTypeable
-XPatternGuards -O -fllvm  -no-user-package-db -rtsopts      -odir
libraries/haskeline/dist-install/build -hidir
libraries/haskeline/dist-install/build -stubdir
libraries/haskeline/dist-install/build   -c
libraries/haskeline/./System/Console/Haskeline/Command/History.hs -o
libraries/haskeline/dist-install/build/System/Console/Haskeline/Command/History.o
 LLVM ERROR: .Lbase_GHCziChar_chr2_info$alias: Target doesn't support
aliases to declarations
 libraries/haskeline/ghc.mk:4: recipe for target
'libraries/haskeline/dist-install/build/System/Console/Haskeline/Command/History.o'
failed
 make[1]: ***
[libraries/haskeline/dist-install/build/System/Console/Haskeline/Command/History.o]
Error 1
 Makefile:64: recipe for target 'all' failed
 make: *** [all] Error 2


Here is my setup.

 - The Glorious Glasgow Haskell Compilation System, version 7.8.0.20140228
 - arm-linux-gnueabi-gcc (GCC) 4.7.3
 - LLVM 3.4

Is this me being silly, or is it a real problem? If it is a real problem
then I can file a ticket.

If there is anything I can do to help try and get GHC cross compiling for
ARM I would gladly do what I can.

Regards,

Luke
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/ghc-devs/attachments/20140305/37b1dbaf/attachment-0001.html>

From slyich at gmail.com  Wed Mar  5 20:28:55 2014
From: slyich at gmail.com (Sergei Trofimovich)
Date: Wed, 5 Mar 2014 23:28:55 +0300
Subject: Standalone Deriving, GND and roles in 7.8.1-rc2
Message-ID: <20140305232855.23ba61b8@sf>

Hello!

Trying to build random packages with fresh ghc-7.8.1-rc2
I've come up with a strange bit:

https://github.com/trofi/Idris-dev/commit/9f93122ba1aa075c2fa1555fea68a6c403697e04

Is it an intended behaviour that
    deriving instance Parsing IdrisInnerParser
capable of doing more, than
    newtype IdrisInnerParser a = IdrisInnerParser { runInnerParser :: Parser a } deriving (Parsing)
?

Thanks!

-- 

  Sergei
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: not available
URL: <http://www.haskell.org/pipermail/ghc-devs/attachments/20140305/2726307f/attachment.sig>

From eir at cis.upenn.edu  Wed Mar  5 20:40:27 2014
From: eir at cis.upenn.edu (Richard Eisenberg)
Date: Wed, 5 Mar 2014 15:40:27 -0500
Subject: Standalone Deriving, GND and roles in 7.8.1-rc2
In-Reply-To: <20140305232855.23ba61b8@sf>
References: <20140305232855.23ba61b8@sf>
Message-ID: <0242C246-F118-4ED9-96D9-ED7224BB3559@cis.upenn.edu>

I think those should be the same and that you've discovered a bug. What's the definition of the Parsing class?

Thanks!
Richard

On Mar 5, 2014, at 3:28 PM, Sergei Trofimovich wrote:

> Hello!
> 
> Trying to build random packages with fresh ghc-7.8.1-rc2
> I've come up with a strange bit:
> 
> https://github.com/trofi/Idris-dev/commit/9f93122ba1aa075c2fa1555fea68a6c403697e04
> 
> Is it an intended behaviour that
>    deriving instance Parsing IdrisInnerParser
> capable of doing more, than
>    newtype IdrisInnerParser a = IdrisInnerParser { runInnerParser :: Parser a } deriving (Parsing)
> ?
> 
> Thanks!
> 
> -- 
> 
>  Sergei
> _______________________________________________
> ghc-devs mailing list
> ghc-devs at haskell.org
> http://www.haskell.org/mailman/listinfo/ghc-devs


From slyich at gmail.com  Wed Mar  5 20:57:58 2014
From: slyich at gmail.com (Sergei Trofimovich)
Date: Wed, 5 Mar 2014 23:57:58 +0300
Subject: Standalone Deriving, GND and roles in 7.8.1-rc2
In-Reply-To: <0242C246-F118-4ED9-96D9-ED7224BB3559@cis.upenn.edu>
References: <20140305232855.23ba61b8@sf>
 <0242C246-F118-4ED9-96D9-ED7224BB3559@cis.upenn.edu>
Message-ID: <20140305235758.05fff3b2@sf>

On Wed, 5 Mar 2014 15:40:27 -0500
Richard Eisenberg <eir at cis.upenn.edu> wrote:

> I think those should be the same and that you've discovered a bug. What's the definition of the Parsing class?

Here it goes [1]:

class Alternative m => Parsing m where
    ....
    notFollowedBy :: (Monad m, Show a) => m a -> m ()
    notFollowedBy p = try ((try p >>= unexpected . show) <|> pure ())
    {-# INLINE notFollowedBy #-}

[1]: https://github.com/ekmett/parsers/blob/master/src/Text/Parser/Combinators.hs#L230

-- 

  Sergei
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: not available
URL: <http://www.haskell.org/pipermail/ghc-devs/attachments/20140305/44c9c19a/attachment.sig>

From ekmett at gmail.com  Wed Mar  5 21:34:42 2014
From: ekmett at gmail.com (Edward Kmett)
Date: Wed, 5 Mar 2014 16:34:42 -0500
Subject: Standalone Deriving, GND and roles in 7.8.1-rc2
In-Reply-To: <20140305235758.05fff3b2@sf>
References: <20140305232855.23ba61b8@sf>
 <0242C246-F118-4ED9-96D9-ED7224BB3559@cis.upenn.edu>
 <20140305235758.05fff3b2@sf>
Message-ID: <CAJumaK_AysL294u1coOp0rD6_3dxOo43K7Ht5ZUSGSX6Z=aADA@mail.gmail.com>

As usual I'm the source of more headaches for Richard. ;)

-Edward


On Wed, Mar 5, 2014 at 3:57 PM, Sergei Trofimovich <slyich at gmail.com> wrote:

> On Wed, 5 Mar 2014 15:40:27 -0500
> Richard Eisenberg <eir at cis.upenn.edu> wrote:
>
> > I think those should be the same and that you've discovered a bug.
> What's the definition of the Parsing class?
>
> Here it goes [1]:
>
> class Alternative m => Parsing m where
>     ....
>     notFollowedBy :: (Monad m, Show a) => m a -> m ()
>     notFollowedBy p = try ((try p >>= unexpected . show) <|> pure ())
>     {-# INLINE notFollowedBy #-}
>
> [1]:
> https://github.com/ekmett/parsers/blob/master/src/Text/Parser/Combinators.hs#L230
>
> --
>
>   Sergei
>
> _______________________________________________
> ghc-devs mailing list
> ghc-devs at haskell.org
> http://www.haskell.org/mailman/listinfo/ghc-devs
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/ghc-devs/attachments/20140305/b16311bc/attachment.html>

From johan.tibell at gmail.com  Thu Mar  6 09:50:09 2014
From: johan.tibell at gmail.com (Johan Tibell)
Date: Thu, 6 Mar 2014 10:50:09 +0100
Subject: Building GHC for performance testing
Message-ID: <CAK-tuPb5mQJ39q3C69YnGKe5zt5CqnxwdiH4gLfue7gyg7gjYA@mail.gmail.com>

Hi,

I'd like to set up a performance build bot for GHC, but before I can do
that I need a script that reliably builds GHC and runs nofib. Do we have
such a script? Here's a strawman proposal for one:

    cabal install happy alex
    git clone git://git.haskell.org/ghc.git
    cd ghc
    ./sync-all --nofib get
    perl boot
    ./configure
    make
    cd nofib
    make clean
    make boot
    make -k mode=slow

Questions:

 * Does this look sensible?
 * Is there a way to only build and run a subset of the benchmarks?
 * Are there any tweaks to mk/build.mk we can do to make the build faster
without compromising the results?
 * Is there a way to do this in a cheap throwaway VM like travis-ci does?
Could such a VM already provide GHC and the required libs to make the whole
thing hermetic?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/ghc-devs/attachments/20140306/ad8fbb56/attachment.html>

From fuuzetsu at fuuzetsu.co.uk  Thu Mar  6 10:01:36 2014
From: fuuzetsu at fuuzetsu.co.uk (Mateusz Kowalczyk)
Date: Thu, 06 Mar 2014 10:01:36 +0000
Subject: Building GHC for performance testing
In-Reply-To: <CAK-tuPb5mQJ39q3C69YnGKe5zt5CqnxwdiH4gLfue7gyg7gjYA@mail.gmail.com>
References: <CAK-tuPb5mQJ39q3C69YnGKe5zt5CqnxwdiH4gLfue7gyg7gjYA@mail.gmail.com>
Message-ID: <53184780.2090901@fuuzetsu.co.uk>

On 06/03/14 09:50, Johan Tibell wrote:
> Hi,
> 
> I'd like to set up a performance build bot for GHC, but before I can do
> that I need a script that reliably builds GHC and runs nofib. Do we have
> such a script? Here's a strawman proposal for one:
> 
>     cabal install happy alex
>     git clone git://git.haskell.org/ghc.git
>     cd ghc
>     ./sync-all --nofib get
>     perl boot
>     ./configure
>     make
>     cd nofib
>     make clean
>     make boot
>     make -k mode=slow
> 
> Questions:
> 
>  * Does this look sensible?
>  * Is there a way to only build and run a subset of the benchmarks?
>  * Are there any tweaks to mk/build.mk we can do to make the build faster
> without compromising the results?
>  * Is there a way to do this in a cheap throwaway VM like travis-ci does?
> Could such a VM already provide GHC and the required libs to make the whole
> thing hermetic?
> 
> 
> 
> _______________________________________________
> ghc-devs mailing list
> ghc-devs at haskell.org
> http://www.haskell.org/mailman/listinfo/ghc-devs
> 

I think this ties in with the whole issue of not having nightlies/test
bots running. I think if the infrastructure for that was in place then
this would simply be a part of the functionality.

re: subset of benchmarks, I believe they are just regular tests, in
which case you can explicitly pass in which test cases should be ran.
Correct me if I'm wrong.

-- 
Mateusz K.

From hvriedel at gmail.com  Thu Mar  6 10:01:36 2014
From: hvriedel at gmail.com (Herbert Valerio Riedel)
Date: Thu, 06 Mar 2014 11:01:36 +0100
Subject: Building GHC for performance testing
In-Reply-To: <CAK-tuPb5mQJ39q3C69YnGKe5zt5CqnxwdiH4gLfue7gyg7gjYA@mail.gmail.com>
 (Johan Tibell's message of "Thu, 6 Mar 2014 10:50:09 +0100")
References: <CAK-tuPb5mQJ39q3C69YnGKe5zt5CqnxwdiH4gLfue7gyg7gjYA@mail.gmail.com>
Message-ID: <87y50nzlvj.fsf@gmail.com>

On 2014-03-06 at 10:50:09 +0100, Johan Tibell wrote:
> I'd like to set up a performance build bot for GHC, but before I can do
> that I need a script that reliably builds GHC and runs nofib. Do we have
> such a script? Here's a strawman proposal for one:
>
>     cabal install happy alex
>     git clone git://git.haskell.org/ghc.git
>     cd ghc
>     ./sync-all --nofib get
>     perl boot
>     ./configure
>     make
>     cd nofib
>     make clean
>     make boot
>     make -k mode=slow
>
> Questions:
>
>  * Does this look sensible?

If the script is supposed to start in an empty environment, then it
looks good to me

>  * Is there a way to only build and run a subset of the benchmarks?
>  * Are there any tweaks to mk/build.mk we can do to make the build faster
> without compromising the results?

You should disable LaTeX generation, and maybe also haddock generation;
and possibly remove the libraries/dph folder (unless that's becomes part
of the benchmarks)

how often would you run the benchmarks? once a day?
 
>  * Is there a way to do this in a cheap throwaway VM like travis-ci does?
> Could such a VM already provide GHC and the required libs to make the whole
> thing hermetic?

Btw, does benchmarking inside a VM provide good enough measurements?
E.g. I'd be worried from noise due to vSMP scheduling (as GHC's GC is
rather sensible to proper SMP scheduling) and maybe from noise coming
from other VMs trashing the caches.

From simonpj at microsoft.com  Thu Mar  6 12:06:12 2014
From: simonpj at microsoft.com (Simon Peyton Jones)
Date: Thu, 6 Mar 2014 12:06:12 +0000
Subject: Strange file
Message-ID: <59543203684B2244980D7E4057D5FBC1487DA09C@DB3EX14MBXC306.europe.corp.microsoft.com>

What is this file?
nofib/real/HMMS/lib/haskell/Builtin.hi
It's a mystery!  Can we delete it?
Simon
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/ghc-devs/attachments/20140306/add5dc54/attachment.html>

From ggreif at gmail.com  Thu Mar  6 12:29:04 2014
From: ggreif at gmail.com (Gabor Greif)
Date: Thu, 6 Mar 2014 13:29:04 +0100
Subject: [PATCH] time library fix for PowerPC
Message-ID: <CAK-hX0mKiY_MJMsGj_o9k5YbXZOOOp-Q8Qyb7=rdt22ehjrV-A@mail.gmail.com>

Please consider this as a pull request.

<https://github.com/ggreif/packages-time/commit/83f08b8896b950707a910fed4e30bddb7ee7f52f>

It fixes an ugly code size blowup that trips the PowerPC assembler (NCG mode).

Cheers,

    Gabor

From johan.tibell at gmail.com  Thu Mar  6 12:41:47 2014
From: johan.tibell at gmail.com (Johan Tibell)
Date: Thu, 6 Mar 2014 13:41:47 +0100
Subject: Strange file
In-Reply-To: <59543203684B2244980D7E4057D5FBC1487DA09C@DB3EX14MBXC306.europe.corp.microsoft.com>
References: <59543203684B2244980D7E4057D5FBC1487DA09C@DB3EX14MBXC306.europe.corp.microsoft.com>
Message-ID: <CAK-tuPYVn_Qwe5PYuiZMDOXMixCHLANg73zBsXDp73EqLnG1Ng@mail.gmail.com>

On Thu, Mar 6, 2014 at 1:06 PM, Simon Peyton Jones <simonpj at microsoft.com>wrote:

>  What is this file?
>
> nofib/real/HMMS/lib/haskell/Builtin.hi
>
> It's a mystery!  Can we delete it?
>

I think it's safe to assume that it was added by mistake. David even tried
to remove it once:

tmp/ghc/nofib$ git log real/HMMS/lib/haskell/Builtin.hi
commit af36a39eed2e598c1f4c49dd726d3732b53b0f46
Author: David Terei <davidterei at gmail.com>
Date:   Thu Jan 19 12:29:04 2012 -0800

    Revert "Move benchmarks into benchmark/ subdir."

    This reverts commit 0449cb065437fc8014b6669e5f1c2c8f4a926d16.

    Conflicts:

        .gitignore

commit 0449cb065437fc8014b6669e5f1c2c8f4a926d16
Author: David Terei <davidterei at gmail.com>
Date:   Tue Jan 17 10:53:12 2012 -0800

    Move benchmarks into benchmark/ subdir.

commit 0bd88c95b14252969c9dd0a5eaa9da219af5f85f
Author: partain <unknown>
Date:   Mon Jan 8 20:13:28 1996 +0000

    [project @ 1996-01-08 20:13:28 by partain]
    Initial revision
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/ghc-devs/attachments/20140306/ed684454/attachment.html>

From carter.schonwald at gmail.com  Thu Mar  6 14:38:39 2014
From: carter.schonwald at gmail.com (Carter Schonwald)
Date: Thu, 6 Mar 2014 09:38:39 -0500
Subject: Building GHC for performance testing
In-Reply-To: <87y50nzlvj.fsf@gmail.com>
References: <CAK-tuPb5mQJ39q3C69YnGKe5zt5CqnxwdiH4gLfue7gyg7gjYA@mail.gmail.com>
 <87y50nzlvj.fsf@gmail.com>
Message-ID: <CAHYVw0ze16KFJx9bb=+76Gm8S9Tq4H_A+7r76xOOC94ZiMcHHw@mail.gmail.com>

There's also the issue that certain vms disable some simd instructions(I
think), and while we don't have many libs that are simd heavy as yet this
could be an issue in certain future benchmarks? (I could be completely
wrong though. )

On Thursday, March 6, 2014, Herbert Valerio Riedel <hvriedel at gmail.com>
wrote:

> On 2014-03-06 at 10:50:09 +0100, Johan Tibell wrote:
> > I'd like to set up a performance build bot for GHC, but before I can do
> > that I need a script that reliably builds GHC and runs nofib. Do we have
> > such a script? Here's a strawman proposal for one:
> >
> >     cabal install happy alex
> >     git clone git://git.haskell.org/ghc.git
> >     cd ghc
> >     ./sync-all --nofib get
> >     perl boot
> >     ./configure
> >     make
> >     cd nofib
> >     make clean
> >     make boot
> >     make -k mode=slow
> >
> > Questions:
> >
> >  * Does this look sensible?
>
> If the script is supposed to start in an empty environment, then it
> looks good to me
>
> >  * Is there a way to only build and run a subset of the benchmarks?
> >  * Are there any tweaks to mk/build.mk we can do to make the build
> faster
> > without compromising the results?
>
> You should disable LaTeX generation, and maybe also haddock generation;
> and possibly remove the libraries/dph folder (unless that's becomes part
> of the benchmarks)
>
> how often would you run the benchmarks? once a day?
>
> >  * Is there a way to do this in a cheap throwaway VM like travis-ci does?
> > Could such a VM already provide GHC and the required libs to make the
> whole
> > thing hermetic?
>
> Btw, does benchmarking inside a VM provide good enough measurements?
> E.g. I'd be worried from noise due to vSMP scheduling (as GHC's GC is
> rather sensible to proper SMP scheduling) and maybe from noise coming
> from other VMs trashing the caches.
> _______________________________________________
> ghc-devs mailing list
> ghc-devs at haskell.org <javascript:;>
> http://www.haskell.org/mailman/listinfo/ghc-devs
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/ghc-devs/attachments/20140306/c89c6186/attachment.html>

From eir at cis.upenn.edu  Thu Mar  6 14:44:44 2014
From: eir at cis.upenn.edu (Richard Eisenberg)
Date: Thu, 6 Mar 2014 09:44:44 -0500
Subject: Standalone Deriving, GND and roles in 7.8.1-rc2
In-Reply-To: <CAJumaK_AysL294u1coOp0rD6_3dxOo43K7Ht5ZUSGSX6Z=aADA@mail.gmail.com>
References: <20140305232855.23ba61b8@sf>
 <0242C246-F118-4ED9-96D9-ED7224BB3559@cis.upenn.edu>
 <20140305235758.05fff3b2@sf>
 <CAJumaK_AysL294u1coOp0rD6_3dxOo43K7Ht5ZUSGSX6Z=aADA@mail.gmail.com>
Message-ID: <193CEDC4-CEC8-44EF-843E-996FAD1FF697@cis.upenn.edu>

This has now been entered as bug #8851. Track progress there if you're interested.

Thanks for bringing this up!
Richard

On Mar 5, 2014, at 4:34 PM, Edward Kmett <ekmett at gmail.com> wrote:

> As usual I'm the source of more headaches for Richard. ;)
> 
> -Edward
> 
> 
> On Wed, Mar 5, 2014 at 3:57 PM, Sergei Trofimovich <slyich at gmail.com> wrote:
> On Wed, 5 Mar 2014 15:40:27 -0500
> Richard Eisenberg <eir at cis.upenn.edu> wrote:
> 
> > I think those should be the same and that you've discovered a bug. What's the definition of the Parsing class?
> 
> Here it goes [1]:
> 
> class Alternative m => Parsing m where
>     ....
>     notFollowedBy :: (Monad m, Show a) => m a -> m ()
>     notFollowedBy p = try ((try p >>= unexpected . show) <|> pure ())
>     {-# INLINE notFollowedBy #-}
> 
> [1]: https://github.com/ekmett/parsers/blob/master/src/Text/Parser/Combinators.hs#L230
> 
> --
> 
>   Sergei
> 
> _______________________________________________
> ghc-devs mailing list
> ghc-devs at haskell.org
> http://www.haskell.org/mailman/listinfo/ghc-devs
> 
> 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/ghc-devs/attachments/20140306/e897bc59/attachment.html>

From ashley at semantic.org  Thu Mar  6 19:40:59 2014
From: ashley at semantic.org (Ashley Yakeley)
Date: Thu, 06 Mar 2014 11:40:59 -0800
Subject: [PATCH] time library fix for PowerPC
In-Reply-To: <CAK-hX0mKiY_MJMsGj_o9k5YbXZOOOp-Q8Qyb7=rdt22ehjrV-A@mail.gmail.com>
References: <CAK-hX0mKiY_MJMsGj_o9k5YbXZOOOp-Q8Qyb7=rdt22ehjrV-A@mail.gmail.com>
Message-ID: <5318CF4B.4030105@semantic.org>

Rejected. The time library git repo only takes converted patches from 
its darcs upstream, see 
<https://ghc.haskell.org/trac/ghc/wiki/Repositories/Upstream>.

However, I can see about making the equivalent change in 
<http://code.haskell.org/time/>, or you can send me a darcs patch.

-- Ashley

On 2014-03-06 04:29, Gabor Greif wrote:
> Please consider this as a pull request.
>
> <https://github.com/ggreif/packages-time/commit/83f08b8896b950707a910fed4e30bddb7ee7f52f>
>
> It fixes an ugly code size blowup that trips the PowerPC assembler (NCG mode).
>
> Cheers,
>
>      Gabor
>
>


From johan.tibell at gmail.com  Thu Mar  6 20:20:59 2014
From: johan.tibell at gmail.com (Johan Tibell)
Date: Thu, 6 Mar 2014 21:20:59 +0100
Subject: Where's the implementation of newArray#
Message-ID: <CAK-tuPZ41Fff-hZeEFRVrX6XrosCNjZ7x8rwUxeQY3CYdLj1Ag@mail.gmail.com>

Is the below code it (from rts/PrimOps.cmm)? Does it being in PrimOps.cmm
mean that it's always out-of-line?

stg_newArrayzh ( W_ n /* words */, gcptr init )
{
    W_ words, size;
    gcptr p, arr;

    again: MAYBE_GC(again);

    // the mark area contains one byte for each 2^MUT_ARR_PTRS_CARD_BITS
words
    // in the array, making sure we round up, and then rounding up to a
whole
    // number of words.
    size = n + mutArrPtrsCardWords(n);
    words = BYTES_TO_WDS(SIZEOF_StgMutArrPtrs) + size;
    ("ptr" arr) = ccall allocate(MyCapability() "ptr",words);
    TICK_ALLOC_PRIM(SIZEOF_StgMutArrPtrs, WDS(n), 0);

    SET_HDR(arr, stg_MUT_ARR_PTRS_DIRTY_info, CCCS);
    StgMutArrPtrs_ptrs(arr) = n;
    StgMutArrPtrs_size(arr) = size;

    // Initialise all elements of the the array with the value in R2
    p = arr + SIZEOF_StgMutArrPtrs;
  for:
    if (p < arr + WDS(words)) {
        W_[p] = init;
        p = p + WDS(1);
        goto for;
    }
    // Initialise the mark bits with 0
  for2:
    if (p < arr + WDS(size)) {
        W_[p] = 0;
        p = p + WDS(1);
        goto for2;
    }

    return (arr);
}
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/ghc-devs/attachments/20140306/03b3d5be/attachment-0001.html>

From simonpj at microsoft.com  Thu Mar  6 22:10:54 2014
From: simonpj at microsoft.com (Simon Peyton Jones)
Date: Thu, 6 Mar 2014 22:10:54 +0000
Subject: new Windows build problem
Message-ID: <59543203684B2244980D7E4057D5FBC1487DB763@DB3EX14MBXC306.europe.corp.microsoft.com>

Sigh.  Totally new problem with building GHC (HEAD) on Windows..

"inplace/bin/ghc-stage2.exe" -hisuf hi -osuf  o -hcsuf hc -static  -H32m -O -Werror -Wall -H64m -O0    -package-name haskell98-2.0.0.3 -hide-all-packages -i -ilibraries/haskell98/. -ilibraries/haskell98/dist-install/build -ilibraries/haskell98/dist-install/build/autogen -Ilibraries/haskell98/dist-install/build -Ilibraries/haskell98/dist-install/build/autogen -Ilibraries/haskell98/.    -optP-include -optPlibraries/haskell98/dist-install/build/autogen/cabal_macros.h -package array-0.5.0.0 -package base-4.7.0.0 -package directory-1.2.0.2 -package old-locale-1.0.0.6 -package old-time-1.1.0.2 -package process-1.2.0.0 -package time-1.4.2 -Wall -XHaskell98 -O2 -O -dcore-lint -fno-warn-amp  -fno-warn-deprecated-flags -dcore-lint  -no-user-package-db -rtsopts      -odir libraries/haskell98/dist-install/build -hidir libraries/haskell98/dist-install/build -stubdir libraries/haskell98/dist-install/build   -c libraries/haskell98/./Directory.hs -o libraries/haskell98/dist-install/build/Directory.o

bash: [6536: 1 (255)] tcsetattr: Inappropriate ioctl for device

HEAD $
What on earth is this ioctl stuff?
The above is repeatable; same command line, same result.

But I'm also getting random seg-faults when building libraries with the stage2 compiler

libraries/random/ghc.mk:5: recipe for target 'libraries/random/dist-install/build/System/Random.o' failed

make[1]: *** [libraries/random/dist-install/build/System/Random.o] Segmentation fault
This is NOT repeatable.  Saying 'make' again gets further.
Any ideas?
Simon
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/ghc-devs/attachments/20140306/f8c78691/attachment.html>

From ezyang at mit.edu  Thu Mar  6 09:59:27 2014
From: ezyang at mit.edu (Edward Z. Yang)
Date: Thu, 06 Mar 2014 01:59:27 -0800
Subject: Building GHC for performance testing
In-Reply-To: <CAK-tuPb5mQJ39q3C69YnGKe5zt5CqnxwdiH4gLfue7gyg7gjYA@mail.gmail.com>
References: <CAK-tuPb5mQJ39q3C69YnGKe5zt5CqnxwdiH4gLfue7gyg7gjYA@mail.gmail.com>
Message-ID: <1394099626-sup-2072@sabre>

Hello Johan,

Off the top of my head:

Technically speaking, the compiler does not have to be optimized to do
build tests; just the libraries.  So you could probably make the builds
run a bit faster this way.

Your command for nofib will only run the "standard" benchmarks;
to run, for example, the GC benchmarks, you will have to cd into
the gc directory and run make there.  You may also need to vary
the tests parameters in other ways, such as threaded and un-threaded.

Cheers,
Edward

Excerpts from Johan Tibell's message of 2014-03-06 01:50:09 -0800:
> Hi,
> 
> I'd like to set up a performance build bot for GHC, but before I can do
> that I need a script that reliably builds GHC and runs nofib. Do we have
> such a script? Here's a strawman proposal for one:
> 
>     cabal install happy alex
>     git clone git://git.haskell.org/ghc.git
>     cd ghc
>     ./sync-all --nofib get
>     perl boot
>     ./configure
>     make
>     cd nofib
>     make clean
>     make boot
>     make -k mode=slow
> 
> Questions:
> 
>  * Does this look sensible?
>  * Is there a way to only build and run a subset of the benchmarks?
>  * Are there any tweaks to mk/build.mk we can do to make the build faster
> without compromising the results?
>  * Is there a way to do this in a cheap throwaway VM like travis-ci does?
> Could such a VM already provide GHC and the required libs to make the whole
> thing hermetic?

From simonpj at microsoft.com  Thu Mar  6 23:42:25 2014
From: simonpj at microsoft.com (Simon Peyton Jones)
Date: Thu, 6 Mar 2014 23:42:25 +0000
Subject: new Windows build problem
Message-ID: <59543203684B2244980D7E4057D5FBC1487DBAA3@DB3EX14MBXC306.europe.corp.microsoft.com>

Actually, the two problems seem to be the same.  A fresh build from scratch yields

libraries/random/ghc.mk:5: recipe for target 'libraries/random/dist-install/build/System/Random.o' failed

make[1]: *** [libraries/random/dist-install/build/System/Random.o] Segmentation fault
Then sniping the command line that tried to build Random.o yields


"inplace/bin/ghc-stage2.exe" -hisuf hi -osuf  o -hcsuf hc -static  -H32m -O -Werror -Wall -H64m -O0    -package-name random-1.0.1.1 -hide-all-packages -i -ilibraries/random/. -ilibraries/random/dist-install/build -ilibraries/random/dist-install/build/autogen -Ilibraries/random/dist-install/build -Ilibraries/random/dist-install/build/autogen -Ilibraries/random/.    -optP-include -optPlibraries/random/dist-install/build/autogen/cabal_macros.h -package base-4.7.0.0 -package time-1.4.2 -O2 -XHaskell98 -XCPP -O2 -O -dcore-lint -fno-warn-amp  -fno-warn-deprecated-flags -dcore-lint  -no-user-package-db -rtsopts      -odir libraries/random/dist-install/build -hidir libraries/random/dist-install/build -stubdir libraries/random/dist-install/build   -c libraries/random/./System/Random.hs -o libraries/random/dist-install/build/System/Random.o



bash: [6536: 1 (255)] tcsetattr: Inappropriate ioctl for device
io
So this ioctl thing seems to be reported as a seg fault by the make system.
Running the same command from a 'cmd' window does give a seg-fault pop-up window.  Alas.
Running with -dshow-passes shows that it happens during code generation,

*** CorePrep:

Result size of CorePrep = {terms: 1,214, types: 912, coercions: 52}

*** Core Linted result of CorePrep:

*** Stg2Stg:

*** CodeOutput:

*** New CodeGen:

*** CPSZ:

*** CPSZ:
I am totally stuck.
Simon
From: Simon Peyton Jones
Sent: 06 March 2014 22:11
To: ghc-devs at haskell.org
Subject: new Windows build problem

Sigh.  Totally new problem with building GHC (HEAD) on Windows..

"inplace/bin/ghc-stage2.exe" -hisuf hi -osuf  o -hcsuf hc -static  -H32m -O -Werror -Wall -H64m -O0    -package-name haskell98-2.0.0.3 -hide-all-packages -i -ilibraries/haskell98/. -ilibraries/haskell98/dist-install/build -ilibraries/haskell98/dist-install/build/autogen -Ilibraries/haskell98/dist-install/build -Ilibraries/haskell98/dist-install/build/autogen -Ilibraries/haskell98/.    -optP-include -optPlibraries/haskell98/dist-install/build/autogen/cabal_macros.h -package array-0.5.0.0 -package base-4.7.0.0 -package directory-1.2.0.2 -package old-locale-1.0.0.6 -package old-time-1.1.0.2 -package process-1.2.0.0 -package time-1.4.2 -Wall -XHaskell98 -O2 -O -dcore-lint -fno-warn-amp  -fno-warn-deprecated-flags -dcore-lint  -no-user-package-db -rtsopts      -odir libraries/haskell98/dist-install/build -hidir libraries/haskell98/dist-install/build -stubdir libraries/haskell98/dist-install/build   -c libraries/haskell98/./Directory.hs -o libraries/haskell98/dist-install/build/Directory.o

bash: [6536: 1 (255)] tcsetattr: Inappropriate ioctl for device

HEAD $
What on earth is this ioctl stuff?
The above is repeatable; same command line, same result.

But I'm also getting random seg-faults when building libraries with the stage2 compiler

libraries/random/ghc.mk:5: recipe for target 'libraries/random/dist-install/build/System/Random.o' failed

make[1]: *** [libraries/random/dist-install/build/System/Random.o] Segmentation fault
This is NOT repeatable.  Saying 'make' again gets further.
Any ideas?
Simon
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/ghc-devs/attachments/20140306/e0e15606/attachment-0001.html>

From johan.tibell at gmail.com  Fri Mar  7 07:24:55 2014
From: johan.tibell at gmail.com (Johan Tibell)
Date: Fri, 7 Mar 2014 08:24:55 +0100
Subject: Emitting calls to functions defined in PrimOps.cmm from the code gen
Message-ID: <CAK-tuPa3s7A87V6ybUrZ5cye3THwh9P0W8tSN_cC37tET29brw@mail.gmail.com>

Hi,

I'm trying to make allocation of arrays of small, statically-known size
inline. For large or unknown size I just want to call the existing
stg_newArrayzh function. In code:

doNewArrayOp :: DynFlags -> CmmFormal -> CmmExpr -> FCode ()
doNewArrayOp dflags res_r (CmmLit (CmmInt n _)) | n <= inlineAllocLimit = do
    -- Do everything inline.
doNewArrayOp dflags res_r n = do
    emitCallTo "stg_newArrayzh" res_r n  -- HERE

The question is: how do I emit a call to stg_newArrayzh, which is defined
in PrimOps.cmm?

-- Johan
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/ghc-devs/attachments/20140307/8d4aa01a/attachment.html>

From marlowsd at gmail.com  Fri Mar  7 09:33:24 2014
From: marlowsd at gmail.com (Simon Marlow)
Date: Fri, 07 Mar 2014 09:33:24 +0000
Subject: Where's the implementation of newArray#
In-Reply-To: <CAK-tuPZ41Fff-hZeEFRVrX6XrosCNjZ7x8rwUxeQY3CYdLj1Ag@mail.gmail.com>
References: <CAK-tuPZ41Fff-hZeEFRVrX6XrosCNjZ7x8rwUxeQY3CYdLj1Ag@mail.gmail.com>
Message-ID: <53199264.50808@gmail.com>

Yes, it's always out-of-line.

Cheers,
Simon

On 06/03/2014 20:20, Johan Tibell wrote:
> Is the below code it (from rts/PrimOps.cmm)? Does it being in
> PrimOps.cmm mean that it's always out-of-line?
>
> stg_newArrayzh ( W_ n /* words */, gcptr init )
> {
>      W_ words, size;
>      gcptr p, arr;
>
>      again: MAYBE_GC(again);
>
>      // the mark area contains one byte for each
> 2^MUT_ARR_PTRS_CARD_BITS words
>      // in the array, making sure we round up, and then rounding up to a
> whole
>      // number of words.
>      size = n + mutArrPtrsCardWords(n);
>      words = BYTES_TO_WDS(SIZEOF_StgMutArrPtrs) + size;
>      ("ptr" arr) = ccall allocate(MyCapability() "ptr",words);
>      TICK_ALLOC_PRIM(SIZEOF_StgMutArrPtrs, WDS(n), 0);
>
>      SET_HDR(arr, stg_MUT_ARR_PTRS_DIRTY_info, CCCS);
>      StgMutArrPtrs_ptrs(arr) = n;
>      StgMutArrPtrs_size(arr) = size;
>
>      // Initialise all elements of the the array with the value in R2
>      p = arr + SIZEOF_StgMutArrPtrs;
>    for:
>      if (p < arr + WDS(words)) {
>          W_[p] = init;
>          p = p + WDS(1);
>          goto for;
>      }
>      // Initialise the mark bits with 0
>    for2:
>      if (p < arr + WDS(size)) {
>          W_[p] = 0;
>          p = p + WDS(1);
>          goto for2;
>      }
>
>      return (arr);
> }

From jpm at cs.uu.nl  Fri Mar  7 10:16:26 2014
From: jpm at cs.uu.nl (=?ISO-8859-1?Q?Jos=E9_Pedro_Magalh=E3es?=)
Date: Fri, 7 Mar 2014 10:16:26 +0000
Subject: ANNOUNCE: GHC 7.8.1 Release Candidate 2
In-Reply-To: <CA+ZFbn_UsENrgU3hEw+mNDuvtwUZhGRWt=bmaciNLWD3LVscdw@mail.gmail.com>
References: <CAEs96n328fs8Xj+oD0R4=rkPVkswZk3RQB6OpxxMv4o+bQ=qQA@mail.gmail.com>
 <CA+ZFbn_UsENrgU3hEw+mNDuvtwUZhGRWt=bmaciNLWD3LVscdw@mail.gmail.com>
Message-ID: <CA+ZFbn86ZX1rrFV1y6vUpA21zihJoFW3yxLfU3wLYvHsTjGKvw@mail.gmail.com>

Should I file a bug report for this? If it's indeed a GHC bug, it's a
blocker.
Can anyone else confirm it?...


Thanks,
Pedro

On Tue, Mar 4, 2014 at 8:17 AM, Jos? Pedro Magalh?es <jpm at cs.uu.nl> wrote:

> Hello,
>
> This GHC crashes whenever I try installing any package. (I guess this
> might be due to cabal-install, though.)
>
> Details:
>   Using the RC2 at
> http://www.haskell.org/ghc/dist/7.8.1-rc2/ghc-7.8.0.20140228-i386-unknown-mingw32.tar.xz
>   OS: Win7 64bit
>   cabal-install version 0.14.0
>   using version 1.14.0 of the Cabal library
>   cabal install --nats -v3 gives this output <http://lpaste.net/100678>,
> and brings up a standard windows application crash window before the
> "returned ExitFailure (-1073741819)" line with the following information:
>
> Problem signature:
>>   Problem Event Name: APPCRASH
>>   Application Name: ghc.exe
>>   Application Version: 0.0.0.0
>>   Application Timestamp: 5312f1e1
>>   Fault Module Name: ghc.exe
>>   Fault Module Version: 0.0.0.0
>>   Fault Module Timestamp: 5312f1e1
>>   Exception Code: c0000005
>>   Exception Offset: 01adb323
>>   OS Version: 6.1.7601.2.1.0.768.3
>>   Locale ID: 2057
>>   Additional Information 1: 1548
>>   Additional Information 2: 1548a4345bd8ec1f0510cd3884fa5889
>>   Additional Information 3: daab
>>   Additional Information 4: daabc1a5d9d41fd73825c2e9d33e1385
>
>
> I have later updated cabal-install (to version 1.18.0.2 using version
> 1.18.1.2 of the Cabal library), but that
> didn't change this problem. The same happened with RC1, btw.
>
> Thanks,
> Pedro
>
>
>
> On Mon, Mar 3, 2014 at 6:23 PM, Austin Seipp <austin at well-typed.com>wrote:
>
>> We are pleased to announce the second release candidate for GHC 7.8.1:
>>
>>     http://www.haskell.org/ghc/dist/7.8.1-rc2/
>>     http://www.haskell.org/ghc/docs/7.8.1-rc2/html/
>>
>> This includes the source tarball and binary distributions for Windows,
>> Linux, OS X, FreeBSD, and Solaris, on x86 and x86_64, and more. There
>> are now two binary builds for Linux users: one for glibc 2.12 and GMP
>> 4, primarily intended for RHEL users, and one built for glibc 2.13 and
>> GMP 5 - intended for Debian and more recent machines.
>>
>> In addition, there is also an iOS cross compiler build (both in the
>> native ARM configuration and i386 simulator configurations), separate
>> Solaris 10 and Solaris 11 builds - the latter supporting dynamic
>> linking - and a new Linux/PPC64 build using glibc 2.18/GMP 5. There is
>> a signed copy of the SHA256 hashes available (attached) using my GPG
>> key (keyid 0x3B58D86F).
>>
>> We're also now offering .tar.xz files, which roughly cut the size of
>> the binary distributions in half compared to bzip2.
>>
>> We've closed approximately 45 tickets that people filed for RC1 in
>> this release. Thank you for all the reports!
>>
>> We plan to make the final 7.8.1 release soon, and hope RC2 will be the
>> last RC. So *please* test as much as possible; bugs are much cheaper
>> if we find them before the release!
>>
>> --
>> Regards,
>>
>> Austin Seipp, Haskell Consultant
>> Well-Typed LLP, http://www.well-typed.com/
>> _______________________________________________
>> ghc-devs mailing list
>> ghc-devs at haskell.org
>> http://www.haskell.org/mailman/listinfo/ghc-devs
>>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/ghc-devs/attachments/20140307/68de02e3/attachment.html>

From carter.schonwald at gmail.com  Fri Mar  7 14:15:02 2014
From: carter.schonwald at gmail.com (Carter Schonwald)
Date: Fri, 7 Mar 2014 09:15:02 -0500
Subject: ANNOUNCE: GHC 7.8.1 Release Candidate 2
In-Reply-To: <CA+ZFbn86ZX1rrFV1y6vUpA21zihJoFW3yxLfU3wLYvHsTjGKvw@mail.gmail.com>
References: <CAEs96n328fs8Xj+oD0R4=rkPVkswZk3RQB6OpxxMv4o+bQ=qQA@mail.gmail.com>
 <CA+ZFbn_UsENrgU3hEw+mNDuvtwUZhGRWt=bmaciNLWD3LVscdw@mail.gmail.com>
 <CA+ZFbn86ZX1rrFV1y6vUpA21zihJoFW3yxLfU3wLYvHsTjGKvw@mail.gmail.com>
Message-ID: <CAHYVw0xjMamfX+x0ZOM85Jso91nusHSJ-RHsWzF3uE3VoNRBkg@mail.gmail.com>

Ghc 7.8 supports only cabal 1.18
Could you try using the boot strap script for getting new cabal install on
your system?
If not, Austin probably has a cabal-install binary lying around for his
windows testing



On Friday, March 7, 2014, Jos? Pedro Magalh?es <jpm at cs.uu.nl> wrote:

> Should I file a bug report for this? If it's indeed a GHC bug, it's a
> blocker.
> Can anyone else confirm it?...
>
>
> Thanks,
> Pedro
>
> On Tue, Mar 4, 2014 at 8:17 AM, Jos? Pedro Magalh?es <jpm at cs.uu.nl> wrote:
>
> Hello,
>
> This GHC crashes whenever I try installing any package. (I guess this
> might be due to cabal-install, though.)
>
> Details:
>   Using the RC2 at
> http://www.haskell.org/ghc/dist/7.8.1-rc2/ghc-7.8.0.20140228-i386-unknown-mingw32.tar.xz
>   OS: Win7 64bit
>   cabal-install version 0.14.0
>   using version 1.14.0 of the Cabal library
>   cabal install --nats -v3 gives this output <http://lpaste.net/100678>,
> and brings up a standard windows application crash window before the
> "returned ExitFailure (-1073741819)" line with the following information:
>
> Problem signature:
>   Problem Event Name: APPCRASH
>   Application Name: ghc.exe
>   Application Version: 0.0.0.0
>   Application Timestamp: 5312f1e1
>   Fault Module Name: ghc.exe
>   Fault Module Version: 0.0.0.0
>   Fault Module Timestamp: 5312f1e1
>   Exception Code: c0000005
>   Exception Offset: 01adb323
>   OS Version: 6.1.7601.2.1.0.768.3
>   Locale ID: 2057
>   Additional Information 1: 1548
>   Additional Information 2: 1548a4345bd8ec1f0510cd3884fa5889
>   Additional Information 3: daab
>   Additional Information 4: daabc1a5d9d41fd73825c2e9d33e1385
>
>
> I have later updated cabal-install (to version 1.18.0.2 using version
> 1.18.1.2 of the Cabal library), but that
> didn't change this problem. The same happened with RC1, btw.
>
> Thanks,
> Pedro
>
>
>
> On Mon, Mar 3, 2014 at 6:23 PM, Austin Seipp <austin at well-typed.com>wrote:
>
> We are pleased to announce the second release candidate for GHC 7.8.1:
>
>     http://www.haskell.org/ghc/dist/7.8.1-rc2/
>     http://www.haskell.org/ghc/docs/7.8.1-rc2/html/
>
> This includes the source tarball and binary distributions for Windows,
> Linux, OS X, FreeBSD, and Solaris, on x86 and x86_64, and more. There
> are now two binary builds for Linux users: one for glibc 2.12 and GMP
> 4, primarily intended for RHEL users, and one built for glibc 2.13 and
> GMP 5 - intended for Debian and more recent machines.
>
> In addition, there is also an iOS cross compiler build (both in the
> native ARM configuration and i386 simulator configurations), separate
> Solaris 10 and Solaris 11 builds - the latter supporting dynamic
> linking - and a new Linux/PPC64 build using glibc 2.18/GMP 5. There is
> a signed copy of the SHA256 hashes available (attached) using my GPG
> key (keyid 0x3B58D86F).
>
> We're also now offering .tar.xz files, which roughly cut the size of
> the binary distributions in half compared to bzip2.
>
> We've closed approximately 45 tickets that people filed for RC1 in
> this release. Thank you for all the reports!
>
> We plan to make the final 7.8.1 release soon, and hope RC2 will be the
> last RC. So *please* test as much as possible; bugs are much cheaper
> if we find them before the release!
>
> --
> Regards,
>
> Austin Seipp, Haskell Consultant
> Well-Typed LLP, http://www.well-typed.com/
> _______________________________________________
> g
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/ghc-devs/attachments/20140307/9f3cdcfe/attachment.html>

From carter.schonwald at gmail.com  Fri Mar  7 14:19:13 2014
From: carter.schonwald at gmail.com (Carter Schonwald)
Date: Fri, 7 Mar 2014 09:19:13 -0500
Subject: Emitting calls to functions defined in PrimOps.cmm from the code
 gen
In-Reply-To: <CAK-tuPa3s7A87V6ybUrZ5cye3THwh9P0W8tSN_cC37tET29brw@mail.gmail.com>
References: <CAK-tuPa3s7A87V6ybUrZ5cye3THwh9P0W8tSN_cC37tET29brw@mail.gmail.com>
Message-ID: <CAHYVw0w9mLwVQYkxKLNpFJZpxctuKnhFnHR6BysSBuAbm5p+kQ@mail.gmail.com>

Have you looked at some of the lowering code for other primops? What info
are you missing?

On Friday, March 7, 2014, Johan Tibell <johan.tibell at gmail.com> wrote:

> Hi,
>
> I'm trying to make allocation of arrays of small, statically-known size
> inline. For large or unknown size I just want to call the existing
> stg_newArrayzh function. In code:
>
> doNewArrayOp :: DynFlags -> CmmFormal -> CmmExpr -> FCode ()
> doNewArrayOp dflags res_r (CmmLit (CmmInt n _)) | n <= inlineAllocLimit =
> do
>     -- Do everything inline.
> doNewArrayOp dflags res_r n = do
>     emitCallTo "stg_newArrayzh" res_r n  -- HERE
>
> The question is: how do I emit a call to stg_newArrayzh, which is defined
> in PrimOps.cmm?
>
> -- Johan
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/ghc-devs/attachments/20140307/1385d232/attachment.html>

From jpm at cs.uu.nl  Fri Mar  7 14:41:30 2014
From: jpm at cs.uu.nl (=?ISO-8859-1?Q?Jos=E9_Pedro_Magalh=E3es?=)
Date: Fri, 7 Mar 2014 14:41:30 +0000
Subject: ANNOUNCE: GHC 7.8.1 Release Candidate 2
In-Reply-To: <CAHYVw0xjMamfX+x0ZOM85Jso91nusHSJ-RHsWzF3uE3VoNRBkg@mail.gmail.com>
References: <CAEs96n328fs8Xj+oD0R4=rkPVkswZk3RQB6OpxxMv4o+bQ=qQA@mail.gmail.com>
 <CA+ZFbn_UsENrgU3hEw+mNDuvtwUZhGRWt=bmaciNLWD3LVscdw@mail.gmail.com>
 <CA+ZFbn86ZX1rrFV1y6vUpA21zihJoFW3yxLfU3wLYvHsTjGKvw@mail.gmail.com>
 <CAHYVw0xjMamfX+x0ZOM85Jso91nusHSJ-RHsWzF3uE3VoNRBkg@mail.gmail.com>
Message-ID: <CA+ZFbn_pQqAi6_Vhqq34cucZ2md+t=Dk40WyFVi37c-r8A_wHw@mail.gmail.com>

On Fri, Mar 7, 2014 at 2:15 PM, Carter Schonwald <carter.schonwald at gmail.com
> wrote:

> Ghc 7.8 supports only cabal 1.18


"I have later updated cabal-install (to version 1.18.0.2 using version
1.18.1.2 of the Cabal library), but that didn't change this problem."

Or do you mean I need something even more recent than this?


Pedro


> Could you try using the boot strap script for getting new cabal install on
> your system?
> If not, Austin probably has a cabal-install binary lying around for his
> windows testing
>
>
>
> On Friday, March 7, 2014, Jos? Pedro Magalh?es <jpm at cs.uu.nl> wrote:
>
>> Should I file a bug report for this? If it's indeed a GHC bug, it's a
>> blocker.
>> Can anyone else confirm it?...
>>
>>
>> Thanks,
>> Pedro
>>
>> On Tue, Mar 4, 2014 at 8:17 AM, Jos? Pedro Magalh?es <jpm at cs.uu.nl>wrote:
>>
>> Hello,
>>
>> This GHC crashes whenever I try installing any package. (I guess this
>> might be due to cabal-install, though.)
>>
>> Details:
>>   Using the RC2 at
>> http://www.haskell.org/ghc/dist/7.8.1-rc2/ghc-7.8.0.20140228-i386-unknown-mingw32.tar.xz
>>   OS: Win7 64bit
>>   cabal-install version 0.14.0
>>   using version 1.14.0 of the Cabal library
>>   cabal install --nats -v3 gives this output <http://lpaste.net/100678>,
>> and brings up a standard windows application crash window before the
>> "returned ExitFailure (-1073741819)" line with the following information:
>>
>> Problem signature:
>>   Problem Event Name: APPCRASH
>>   Application Name: ghc.exe
>>   Application Version: 0.0.0.0
>>   Application Timestamp: 5312f1e1
>>   Fault Module Name: ghc.exe
>>   Fault Module Version: 0.0.0.0
>>   Fault Module Timestamp: 5312f1e1
>>   Exception Code: c0000005
>>   Exception Offset: 01adb323
>>   OS Version: 6.1.7601.2.1.0.768.3
>>   Locale ID: 2057
>>   Additional Information 1: 1548
>>   Additional Information 2: 1548a4345bd8ec1f0510cd3884fa5889
>>   Additional Information 3: daab
>>   Additional Information 4: daabc1a5d9d41fd73825c2e9d33e1385
>>
>>
>> I have later updated cabal-install (to version 1.18.0.2 using version
>> 1.18.1.2 of the Cabal library), but that
>> didn't change this problem. The same happened with RC1, btw.
>>
>> Thanks,
>> Pedro
>>
>>
>>
>> On Mon, Mar 3, 2014 at 6:23 PM, Austin Seipp <austin at well-typed.com>wrote:
>>
>> We are pleased to announce the second release candidate for GHC 7.8.1:
>>
>>     http://www.haskell.org/ghc/dist/7.8.1-rc2/
>>     http://www.haskell.org/ghc/docs/7.8.1-rc2/html/
>>
>> This includes the source tarball and binary distributions for Windows,
>> Linux, OS X, FreeBSD, and Solaris, on x86 and x86_64, and more. There
>> are now two binary builds for Linux users: one for glibc 2.12 and GMP
>> 4, primarily intended for RHEL users, and one built for glibc 2.13 and
>> GMP 5 - intended for Debian and more recent machines.
>>
>> In addition, there is also an iOS cross compiler build (both in the
>> native ARM configuration and i386 simulator configurations), separate
>> Solaris 10 and Solaris 11 builds - the latter supporting dynamic
>> linking - and a new Linux/PPC64 build using glibc 2.18/GMP 5. There is
>> a signed copy of the SHA256 hashes available (attached) using my GPG
>> key (keyid 0x3B58D86F).
>>
>> We're also now offering .tar.xz files, which roughly cut the size of
>> the binary distributions in half compared to bzip2.
>>
>> We've closed approximately 45 tickets that people filed for RC1 in
>> this release. Thank you for all the reports!
>>
>> We plan to make the final 7.8.1 release soon, and hope RC2 will be the
>> last RC. So *please* test as much as possible; bugs are much cheaper
>> if we find them before the release!
>>
>> --
>> Regards,
>>
>> Austin Seipp, Haskell Consultant
>> Well-Typed LLP, http://www.well-typed.com/
>> _______________________________________________
>> g
>>
>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/ghc-devs/attachments/20140307/1aa63940/attachment-0001.html>

From carter.schonwald at gmail.com  Fri Mar  7 14:52:55 2014
From: carter.schonwald at gmail.com (Carter Schonwald)
Date: Fri, 7 Mar 2014 09:52:55 -0500
Subject: ANNOUNCE: GHC 7.8.1 Release Candidate 2
In-Reply-To: <CA+ZFbn_pQqAi6_Vhqq34cucZ2md+t=Dk40WyFVi37c-r8A_wHw@mail.gmail.com>
References: <CAEs96n328fs8Xj+oD0R4=rkPVkswZk3RQB6OpxxMv4o+bQ=qQA@mail.gmail.com>
 <CA+ZFbn_UsENrgU3hEw+mNDuvtwUZhGRWt=bmaciNLWD3LVscdw@mail.gmail.com>
 <CA+ZFbn86ZX1rrFV1y6vUpA21zihJoFW3yxLfU3wLYvHsTjGKvw@mail.gmail.com>
 <CAHYVw0xjMamfX+x0ZOM85Jso91nusHSJ-RHsWzF3uE3VoNRBkg@mail.gmail.com>
 <CA+ZFbn_pQqAi6_Vhqq34cucZ2md+t=Dk40WyFVi37c-r8A_wHw@mail.gmail.com>
Message-ID: <CAHYVw0xXt_kfFd19aGv7+D4C5qe_-pc1qU_NswMxYqcJrFXmrw@mail.gmail.com>

Woooops.  I misread the earlier email.

Did you wipe your .ghc dir and cabal/config files after updating to
cabal-install 1.18? It could be a stale cabal config that has shared set to
false or something?


On Friday, March 7, 2014, Jos? Pedro Magalh?es <jpm at cs.uu.nl> wrote:

>
>
>
> On Fri, Mar 7, 2014 at 2:15 PM, Carter Schonwald <
> carter.schonwald at gmail.com<javascript:_e(%7B%7D,'cvml','carter.schonwald at gmail.com');>
> > wrote:
>
>> Ghc 7.8 supports only cabal 1.18
>
>
> "I have later updated cabal-install (to version 1.18.0.2 using version
> 1.18.1.2 of the Cabal library), but that didn't change this problem."
>
> Or do you mean I need something even more recent than this?
>
>
> Pedro
>
>
> Could you try using the boot strap script for getting new cabal install on
> your system?
> If not, Austin probably has a cabal-install binary lying around for his
> windows testing
>
>
>
> On Friday, March 7, 2014, Jos? Pedro Magalh?es <jpm at cs.uu.nl> wrote:
>
> Should I file a bug report for this? If it's indeed a GHC bug, it's a
> blocker.
> Can anyone else confirm it?...
>
>
> Thanks,
> Pedro
>
> On Tue, Mar 4, 2014 at 8:17 AM, Jos? Pedro Magalh?es <jpm at cs.uu.nl> wrote:
>
> Hello,
>
> This GHC crashes whenever I try installing any package. (I guess this
> might be due to cabal-install, though.)
>
> Details:
>   Using the RC2 at
> http://www.haskell.org/ghc/dist/7.8.1-rc2/ghc-7.8.0.20140228-i386-unknown-mingw32.tar.xz
>   OS: Win7 64bit
>   cabal-install version 0.14.0
>   using version 1.14.0 of the Cabal library
>   cabal install --nats -v3 gives this output <http://lpaste.net/100678>,
> and brings up a standard windows application crash window before the
> "returned ExitFailure (-1073741819)" line with the following information:
>
> Problem signature:
>   Problem Event Name: APPCRASH
>   Application Name: ghc.exe
>   Application Version: 0.0.0.0
>   Application Timestamp: 5312f1e1
>   Fault Module Name: ghc.exe
>   Fault Module Version: 0.0.0.0
>   Fault Module Timestamp: 5312f1e1
>   Exception Code: c0000005
>   Exception Offset: 01adb323
>   OS Version: 6.1.7601.2.1.0.768.3
>   Locale ID: 2057
>   Additional Information 1: 1548
>   Additional Information 2: 1548a4345bd8ec1f0510cd3884fa5889
>   Additional Information 3: daab
>   Additional Information 4: daabc1a5d9d41fd73825c2e9d33e1385
>
>
> I have later updated cabal-install (to version 1.18.0.2 using version
> 1.18.1.2 of the Cabal library), but that
> didn't change this problem. The same happened with RC1, btw.
>
> Thanks,
> Pedro
>
>
>
> On Mon, Mar 3, 2014 at 6:23 PM, Austin Seipp <austin at well-typed.com>wrote:
>
> We are pleased to announce the second release candidate for GHC 7.8.1:
>
>     http://www.haskell.org/ghc/dist/7.8.1-rc2/
>     http://www.haskell.org/ghc/docs/7.8.1-rc2/html/
>
> This includes the source tarball and binary distributions for Windows,
> Linux, OS X, FreeBSD, and Solaris, on x86 and x86_64, and more. There
> are now two binary builds for Linux users: one for glibc 2.12 and GMP
> 4, primarily intended for RHEL users, and one built for glibc 2.13 and
> GMP 5 - intended for Debian and more recent machines.
>
> In addition, there is also an iOS cross compiler build (both in the
> native ARM configuration and i386 simulator configurations), separate
> Solaris 10 and So
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/ghc-devs/attachments/20140307/41eeed8b/attachment.html>

From jpm at cs.uu.nl  Fri Mar  7 15:07:45 2014
From: jpm at cs.uu.nl (=?ISO-8859-1?Q?Jos=E9_Pedro_Magalh=E3es?=)
Date: Fri, 7 Mar 2014 15:07:45 +0000
Subject: ANNOUNCE: GHC 7.8.1 Release Candidate 2
In-Reply-To: <CAHYVw0xXt_kfFd19aGv7+D4C5qe_-pc1qU_NswMxYqcJrFXmrw@mail.gmail.com>
References: <CAEs96n328fs8Xj+oD0R4=rkPVkswZk3RQB6OpxxMv4o+bQ=qQA@mail.gmail.com>
 <CA+ZFbn_UsENrgU3hEw+mNDuvtwUZhGRWt=bmaciNLWD3LVscdw@mail.gmail.com>
 <CA+ZFbn86ZX1rrFV1y6vUpA21zihJoFW3yxLfU3wLYvHsTjGKvw@mail.gmail.com>
 <CAHYVw0xjMamfX+x0ZOM85Jso91nusHSJ-RHsWzF3uE3VoNRBkg@mail.gmail.com>
 <CA+ZFbn_pQqAi6_Vhqq34cucZ2md+t=Dk40WyFVi37c-r8A_wHw@mail.gmail.com>
 <CAHYVw0xXt_kfFd19aGv7+D4C5qe_-pc1qU_NswMxYqcJrFXmrw@mail.gmail.com>
Message-ID: <CA+ZFbn9-M-RJcvZMxavQuR1mqNrwGCvt6dz-GGT6C2Y69guFcA@mail.gmail.com>

On Fri, Mar 7, 2014 at 2:52 PM, Carter Schonwald <carter.schonwald at gmail.com
> wrote:

> Woooops.  I misread the earlier email.
>
> Did you wipe your .ghc dir


I don't know where to find this in Windows.


> and cabal/config files


My cabal config file doesn't set "shared".


Cheers,
Pedro


> after updating to cabal-install 1.18? It could be a stale cabal config
> that has shared set to false or something?
>
>
>
> On Friday, March 7, 2014, Jos? Pedro Magalh?es <jpm at cs.uu.nl> wrote:
>
>>
>>
>>
>> On Fri, Mar 7, 2014 at 2:15 PM, Carter Schonwald <
>> carter.schonwald at gmail.com> wrote:
>>
>>> Ghc 7.8 supports only cabal 1.18
>>
>>
>> "I have later updated cabal-install (to version 1.18.0.2 using version
>> 1.18.1.2 of the Cabal library), but that didn't change this problem."
>>
>> Or do you mean I need something even more recent than this?
>>
>>
>> Pedro
>>
>>
>> Could you try using the boot strap script for getting new cabal install
>> on your system?
>> If not, Austin probably has a cabal-install binary lying around for his
>> windows testing
>>
>>
>>
>> On Friday, March 7, 2014, Jos? Pedro Magalh?es <jpm at cs.uu.nl> wrote:
>>
>> Should I file a bug report for this? If it's indeed a GHC bug, it's a
>> blocker.
>> Can anyone else confirm it?...
>>
>>
>> Thanks,
>> Pedro
>>
>> On Tue, Mar 4, 2014 at 8:17 AM, Jos? Pedro Magalh?es <jpm at cs.uu.nl>wrote:
>>
>> Hello,
>>
>> This GHC crashes whenever I try installing any package. (I guess this
>> might be due to cabal-install, though.)
>>
>> Details:
>>   Using the RC2 at
>> http://www.haskell.org/ghc/dist/7.8.1-rc2/ghc-7.8.0.20140228-i386-unknown-mingw32.tar.xz
>>   OS: Win7 64bit
>>   cabal-install version 0.14.0
>>   using version 1.14.0 of the Cabal library
>>   cabal install --nats -v3 gives this output <http://lpaste.net/100678>,
>> and brings up a standard windows application crash window before the
>> "returned ExitFailure (-1073741819)" line with the following information:
>>
>> Problem signature:
>>   Problem Event Name: APPCRASH
>>   Application Name: ghc.exe
>>   Application Version: 0.0.0.0
>>   Application Timestamp: 5312f1e1
>>   Fault Module Name: ghc.exe
>>   Fault Module Version: 0.0.0.0
>>   Fault Module Timestamp: 5312f1e1
>>   Exception Code: c0000005
>>   Exception Offset: 01adb323
>>   OS Version: 6.1.7601.2.1.0.768.3
>>   Locale ID: 2057
>>   Additional Information 1: 1548
>>   Additional Information 2: 1548a4345bd8ec1f0510cd3884fa5889
>>   Additional Information 3: daab
>>   Additional Information 4: daabc1a5d9d41fd73825c2e9d33e1385
>>
>>
>> I have later updated cabal-install (to version 1.18.0.2 using version
>> 1.18.1.2 of the Cabal library), but that
>> didn't change this problem. The same happened with RC1, btw.
>>
>> Thanks,
>> Pedro
>>
>>
>>
>> On Mon, Mar 3, 2014 at 6:23 PM, Austin Seipp <austin at well-typed.com>wrote:
>>
>> We are pleased to announce the second release candidate for GHC 7.8.1:
>>
>>     http://www.haskell.org/ghc/dist/7.8.1-rc2/
>>     http://www.haskell.org/ghc/docs/7.8.1-rc2/html/
>>
>> This includes the source tarball and binary distributions for Windows,
>> Linux, OS X, FreeBSD, and Solaris, on x86 and x86_64, and more. There
>> are now two binary builds for Linux users: one for glibc 2.12 and GMP
>> 4, primarily intended for RHEL users, and one built for glibc 2.13 and
>> GMP 5 - intended for Debian and more recent machines.
>>
>> In addition, there is also an iOS cross compiler build (both in the
>> native ARM configuration and i386 simulator configurations), separate
>> Solaris 10 and So
>>
>>
>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/ghc-devs/attachments/20140307/f454d5bc/attachment.html>

From johan.tibell at gmail.com  Fri Mar  7 15:23:20 2014
From: johan.tibell at gmail.com (Johan Tibell)
Date: Fri, 7 Mar 2014 16:23:20 +0100
Subject: Emitting calls to functions defined in PrimOps.cmm from the code
 gen
In-Reply-To: <CAHYVw0w9mLwVQYkxKLNpFJZpxctuKnhFnHR6BysSBuAbm5p+kQ@mail.gmail.com>
References: <CAK-tuPa3s7A87V6ybUrZ5cye3THwh9P0W8tSN_cC37tET29brw@mail.gmail.com>
 <CAHYVw0w9mLwVQYkxKLNpFJZpxctuKnhFnHR6BysSBuAbm5p+kQ@mail.gmail.com>
Message-ID: <CAK-tuPbaJ7bP+1zEnrRCNx5ivtydzDZJufYfONEg+xfk8WMorg@mail.gmail.com>

With Simon's help I figured it out. I'm now refactoring StgCmmPrimOp so
it's easier to have primops that have both inline and out-of-line
implementations in the future.


On Fri, Mar 7, 2014 at 3:19 PM, Carter Schonwald <carter.schonwald at gmail.com
> wrote:

> Have you looked at some of the lowering code for other primops? What info
> are you missing?
>
>
> On Friday, March 7, 2014, Johan Tibell <johan.tibell at gmail.com> wrote:
>
>> Hi,
>>
>> I'm trying to make allocation of arrays of small, statically-known size
>> inline. For large or unknown size I just want to call the existing
>> stg_newArrayzh function. In code:
>>
>> doNewArrayOp :: DynFlags -> CmmFormal -> CmmExpr -> FCode ()
>> doNewArrayOp dflags res_r (CmmLit (CmmInt n _)) | n <= inlineAllocLimit =
>> do
>>     -- Do everything inline.
>> doNewArrayOp dflags res_r n = do
>>     emitCallTo "stg_newArrayzh" res_r n  -- HERE
>>
>> The question is: how do I emit a call to stg_newArrayzh, which is defined
>> in PrimOps.cmm?
>>
>> -- Johan
>>
>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/ghc-devs/attachments/20140307/e61eabd5/attachment-0001.html>

From johan.tibell at gmail.com  Fri Mar  7 15:24:36 2014
From: johan.tibell at gmail.com (Johan Tibell)
Date: Fri, 7 Mar 2014 16:24:36 +0100
Subject: ANNOUNCE: GHC 7.8.1 Release Candidate 2
In-Reply-To: <CA+ZFbn_pQqAi6_Vhqq34cucZ2md+t=Dk40WyFVi37c-r8A_wHw@mail.gmail.com>
References: <CAEs96n328fs8Xj+oD0R4=rkPVkswZk3RQB6OpxxMv4o+bQ=qQA@mail.gmail.com>
 <CA+ZFbn_UsENrgU3hEw+mNDuvtwUZhGRWt=bmaciNLWD3LVscdw@mail.gmail.com>
 <CA+ZFbn86ZX1rrFV1y6vUpA21zihJoFW3yxLfU3wLYvHsTjGKvw@mail.gmail.com>
 <CAHYVw0xjMamfX+x0ZOM85Jso91nusHSJ-RHsWzF3uE3VoNRBkg@mail.gmail.com>
 <CA+ZFbn_pQqAi6_Vhqq34cucZ2md+t=Dk40WyFVi37c-r8A_wHw@mail.gmail.com>
Message-ID: <CAK-tuPZmXLB5m0_h_ebZtw-n=5QdATb9L-GrKSKfZKsGpMH0aw@mail.gmail.com>

Cabal-1.18.1.3 and cabal-install-1.18.0.3, released a couple of days ago,
have some GHC 7.8 specific fixes. I don't know if those will help your
issue though.


On Fri, Mar 7, 2014 at 3:41 PM, Jos? Pedro Magalh?es <jpm at cs.uu.nl> wrote:

>
>
>
> On Fri, Mar 7, 2014 at 2:15 PM, Carter Schonwald <
> carter.schonwald at gmail.com> wrote:
>
>> Ghc 7.8 supports only cabal 1.18
>
>
> "I have later updated cabal-install (to version 1.18.0.2 using version
> 1.18.1.2 of the Cabal library), but that didn't change this problem."
>
> Or do you mean I need something even more recent than this?
>
>
> Pedro
>
>
>> Could you try using the boot strap script for getting new cabal install
>> on your system?
>> If not, Austin probably has a cabal-install binary lying around for his
>> windows testing
>>
>>
>>
>> On Friday, March 7, 2014, Jos? Pedro Magalh?es <jpm at cs.uu.nl> wrote:
>>
>>> Should I file a bug report for this? If it's indeed a GHC bug, it's a
>>> blocker.
>>> Can anyone else confirm it?...
>>>
>>>
>>> Thanks,
>>> Pedro
>>>
>>> On Tue, Mar 4, 2014 at 8:17 AM, Jos? Pedro Magalh?es <jpm at cs.uu.nl>wrote:
>>>
>>> Hello,
>>>
>>> This GHC crashes whenever I try installing any package. (I guess this
>>> might be due to cabal-install, though.)
>>>
>>> Details:
>>>   Using the RC2 at
>>> http://www.haskell.org/ghc/dist/7.8.1-rc2/ghc-7.8.0.20140228-i386-unknown-mingw32.tar.xz
>>>   OS: Win7 64bit
>>>   cabal-install version 0.14.0
>>>   using version 1.14.0 of the Cabal library
>>>   cabal install --nats -v3 gives this output <http://lpaste.net/100678>,
>>> and brings up a standard windows application crash window before the
>>> "returned ExitFailure (-1073741819)" line with the following information:
>>>
>>> Problem signature:
>>>   Problem Event Name: APPCRASH
>>>   Application Name: ghc.exe
>>>   Application Version: 0.0.0.0
>>>   Application Timestamp: 5312f1e1
>>>   Fault Module Name: ghc.exe
>>>   Fault Module Version: 0.0.0.0
>>>   Fault Module Timestamp: 5312f1e1
>>>   Exception Code: c0000005
>>>   Exception Offset: 01adb323
>>>   OS Version: 6.1.7601.2.1.0.768.3
>>>   Locale ID: 2057
>>>   Additional Information 1: 1548
>>>   Additional Information 2: 1548a4345bd8ec1f0510cd3884fa5889
>>>   Additional Information 3: daab
>>>   Additional Information 4: daabc1a5d9d41fd73825c2e9d33e1385
>>>
>>>
>>> I have later updated cabal-install (to version 1.18.0.2 using version
>>> 1.18.1.2 of the Cabal library), but that
>>> didn't change this problem. The same happened with RC1, btw.
>>>
>>> Thanks,
>>> Pedro
>>>
>>>
>>>
>>> On Mon, Mar 3, 2014 at 6:23 PM, Austin Seipp <austin at well-typed.com>wrote:
>>>
>>> We are pleased to announce the second release candidate for GHC 7.8.1:
>>>
>>>     http://www.haskell.org/ghc/dist/7.8.1-rc2/
>>>     http://www.haskell.org/ghc/docs/7.8.1-rc2/html/
>>>
>>> This includes the source tarball and binary distributions for Windows,
>>> Linux, OS X, FreeBSD, and Solaris, on x86 and x86_64, and more. There
>>> are now two binary builds for Linux users: one for glibc 2.12 and GMP
>>> 4, primarily intended for RHEL users, and one built for glibc 2.13 and
>>> GMP 5 - intended for Debian and more recent machines.
>>>
>>> In addition, there is also an iOS cross compiler build (both in the
>>> native ARM configuration and i386 simulator configurations), separate
>>> Solaris 10 and Solaris 11 builds - the latter supporting dynamic
>>> linking - and a new Linux/PPC64 build using glibc 2.18/GMP 5. There is
>>> a signed copy of the SHA256 hashes available (attached) using my GPG
>>> key (keyid 0x3B58D86F).
>>>
>>> We're also now offering .tar.xz files, which roughly cut the size of
>>> the binary distributions in half compared to bzip2.
>>>
>>> We've closed approximately 45 tickets that people filed for RC1 in
>>> this release. Thank you for all the reports!
>>>
>>> We plan to make the final 7.8.1 release soon, and hope RC2 will be the
>>> last RC. So *please* test as much as possible; bugs are much cheaper
>>> if we find them before the release!
>>>
>>> --
>>> Regards,
>>>
>>> Austin Seipp, Haskell Consultant
>>> Well-Typed LLP, http://www.well-typed.com/
>>> _______________________________________________
>>> g
>>>
>>>
>
> _______________________________________________
> ghc-devs mailing list
> ghc-devs at haskell.org
> http://www.haskell.org/mailman/listinfo/ghc-devs
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/ghc-devs/attachments/20140307/35b983d7/attachment.html>

From carter.schonwald at gmail.com  Fri Mar  7 15:27:18 2014
From: carter.schonwald at gmail.com (Carter Schonwald)
Date: Fri, 7 Mar 2014 10:27:18 -0500
Subject: Emitting calls to functions defined in PrimOps.cmm from the code
 gen
In-Reply-To: <CAK-tuPbaJ7bP+1zEnrRCNx5ivtydzDZJufYfONEg+xfk8WMorg@mail.gmail.com>
References: <CAK-tuPa3s7A87V6ybUrZ5cye3THwh9P0W8tSN_cC37tET29brw@mail.gmail.com>
 <CAHYVw0w9mLwVQYkxKLNpFJZpxctuKnhFnHR6BysSBuAbm5p+kQ@mail.gmail.com>
 <CAK-tuPbaJ7bP+1zEnrRCNx5ivtydzDZJufYfONEg+xfk8WMorg@mail.gmail.com>
Message-ID: <CAHYVw0zu-Q94rC-RgWsakm=MZp=A+vPQYFnFZOKKHkTtjAJ-BA@mail.gmail.com>

Awesome! Please post a link to the new version on devs when it lands! (I'm
not quite at the point where I can keep up with the full commits firehose
yet).  This is very relevant for me.

On Friday, March 7, 2014, Johan Tibell <johan.tibell at gmail.com> wrote:

> With Simon's help I figured it out. I'm now refactoring StgCmmPrimOp so
> it's easier to have primops that have both inline and out-of-line
> implementations in the future.
>
>
> On Fri, Mar 7, 2014 at 3:19 PM, Carter Schonwald <
> carter.schonwald at gmail.com<javascript:_e(%7B%7D,'cvml','carter.schonwald at gmail.com');>
> > wrote:
>
>> Have you looked at some of the lowering code for other primops? What info
>> are you missing?
>>
>>
>> On Friday, March 7, 2014, Johan Tibell <johan.tibell at gmail.com<javascript:_e(%7B%7D,'cvml','johan.tibell at gmail.com');>>
>> wrote:
>>
>>> Hi,
>>>
>>> I'm trying to make allocation of arrays of small, statically-known size
>>> inline. For large or unknown size I just want to call the existing
>>> stg_newArrayzh function. In code:
>>>
>>> doNewArrayOp :: DynFlags -> CmmFormal -> CmmExpr -> FCode ()
>>> doNewArrayOp dflags res_r (CmmLit (CmmInt n _)) | n <= inlineAllocLimit
>>> = do
>>>     -- Do everything inline.
>>> doNewArrayOp dflags res_r n = do
>>>     emitCallTo "stg_newArrayzh" res_r n  -- HERE
>>>
>>> The question is: how do I emit a call to stg_newArrayzh, which is
>>> defined in PrimOps.cmm?
>>>
>>> -- Johan
>>>
>>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/ghc-devs/attachments/20140307/c0e0b9be/attachment.html>

From ggreif at gmail.com  Fri Mar  7 19:07:45 2014
From: ggreif at gmail.com (Gabor Greif)
Date: Fri, 7 Mar 2014 20:07:45 +0100
Subject: [commit: ghc] master: Make -XDeriveFunctor more generous about
 non-last arguments (Trac #8678) (cdac487)
In-Reply-To: <20140307165249.B619D2406B@ghc.haskell.org>
References: <20140307165249.B619D2406B@ghc.haskell.org>
Message-ID: <CAK-hX0ne527zh=ZV0KFkr3D=NeBbLJARSnyh7VBo1Er1hAPv3w@mail.gmail.com>

Thanks for fixing this, Simon!

I can add tests if you haven't already...

Cheers,

    Gabor

On 3/7/14, git at git.haskell.org <git at git.haskell.org> wrote:
> Repository : ssh://git at git.haskell.org/ghc
>
> On branch  : master
> Link       :
> http://ghc.haskell.org/trac/ghc/changeset/cdac487bcd9928d77738f6e79ead7b9bb4bc00fd/ghc
>
>>---------------------------------------------------------------
>
> commit cdac487bcd9928d77738f6e79ead7b9bb4bc00fd
> Author: Simon Peyton Jones <simonpj at microsoft.com>
> Date:   Fri Mar 7 16:45:55 2014 +0000
>
>     Make -XDeriveFunctor more generous about non-last arguments (Trac
> #8678)
>
>     When deriving Functor, Foldable, Traversable, we need only look at the
>     way that the last type argument is treated.  It's fine for there to
>     be existentials etc, provided they don't affect the last type argument.
>
>     See Note [Check that the type variable is truly universal] in TcDeriv.
>
>
>>---------------------------------------------------------------
>
> cdac487bcd9928d77738f6e79ead7b9bb4bc00fd
>  compiler/typecheck/TcDeriv.lhs                     |   88
> +++++++++++++++-----
>  compiler/typecheck/TcGenDeriv.lhs                  |    8 +-
>  docs/users_guide/glasgow_exts.xml                  |    7 ++
>  testsuite/tests/deriving/should_compile/T8678.hs   |   12 +++
>  testsuite/tests/deriving/should_compile/all.T      |    1 +
>  testsuite/tests/deriving/should_fail/T3101.stderr  |    2 +-
>  testsuite/tests/generics/GenCannotDoRep0_0.stderr  |    3 +-
>  testsuite/tests/generics/GenCannotDoRep1_0.stderr  |    3 +-
>  .../tests/typecheck/should_fail/tcfail086.stderr   |    2 +-
>  9 files changed, 96 insertions(+), 30 deletions(-)
>
> Diff suppressed because of size. To see it, use:
>
>     git diff-tree --root --patch-with-stat --no-color --find-copies-harder
> --ignore-space-at-eol --cc cdac487bcd9928d77738f6e79ead7b9bb4bc00fd
> _______________________________________________
> ghc-commits mailing list
> ghc-commits at haskell.org
> http://www.haskell.org/mailman/listinfo/ghc-commits
>

From simonpj at microsoft.com  Fri Mar  7 22:33:18 2014
From: simonpj at microsoft.com (Simon Peyton Jones)
Date: Fri, 7 Mar 2014 22:33:18 +0000
Subject: new Windows build problem
In-Reply-To: <59543203684B2244980D7E4057D5FBC1487DBAA3@DB3EX14MBXC306.europe.corp.microsoft.com>
References: <59543203684B2244980D7E4057D5FBC1487DBAA3@DB3EX14MBXC306.europe.corp.microsoft.com>
Message-ID: <59543203684B2244980D7E4057D5FBC1487DD764@DB3EX14MBXC306.europe.corp.microsoft.com>

Is anyone able to help me here?  I have no idea how to hunt down a seg-fault in ghc-stage1.exe on Windows.
I thought of using git bisect to try to find the offending commit (though each bisection takes a couple of hours since it has to be a clean build).  But I was defeated by the fact that haddock is a separate repo, and the task of finding the haddock commit that matches the ghc commit defeated me.  There are probably other repos too, but they probably change less often.
In short, I'm stuck.  I can use Linux at work, but when I'm on the move I just have my Windows laptop.  What is frustrating is that GHC used to build on Windows just fine.
Does anyone feel more competent than me feel able to bisect their way to the offending commit?
Thanks
Simon

From: ghc-devs [mailto:ghc-devs-bounces at haskell.org] On Behalf Of Simon Peyton Jones
Sent: 06 March 2014 23:42
To: ghc-devs at haskell.org
Subject: RE: new Windows build problem

Actually, the two problems seem to be the same.  A fresh build from scratch yields

libraries/random/ghc.mk:5: recipe for target 'libraries/random/dist-install/build/System/Random.o' failed

make[1]: *** [libraries/random/dist-install/build/System/Random.o] Segmentation fault
Then sniping the command line that tried to build Random.o yields


"inplace/bin/ghc-stage2.exe" -hisuf hi -osuf  o -hcsuf hc -static  -H32m -O -Werror -Wall -H64m -O0    -package-name random-1.0.1.1 -hide-all-packages -i -ilibraries/random/. -ilibraries/random/dist-install/build -ilibraries/random/dist-install/build/autogen -Ilibraries/random/dist-install/build -Ilibraries/random/dist-install/build/autogen -Ilibraries/random/.    -optP-include -optPlibraries/random/dist-install/build/autogen/cabal_macros.h -package base-4.7.0.0 -package time-1.4.2 -O2 -XHaskell98 -XCPP -O2 -O -dcore-lint -fno-warn-amp  -fno-warn-deprecated-flags -dcore-lint  -no-user-package-db -rtsopts      -odir libraries/random/dist-install/build -hidir libraries/random/dist-install/build -stubdir libraries/random/dist-install/build   -c libraries/random/./System/Random.hs -o libraries/random/dist-install/build/System/Random.o



bash: [6536: 1 (255)] tcsetattr: Inappropriate ioctl for device
io
So this ioctl thing seems to be reported as a seg fault by the make system.
Running the same command from a 'cmd' window does give a seg-fault pop-up window.  Alas.
Running with -dshow-passes shows that it happens during code generation,

*** CorePrep:

Result size of CorePrep = {terms: 1,214, types: 912, coercions: 52}

*** Core Linted result of CorePrep:

*** Stg2Stg:

*** CodeOutput:

*** New CodeGen:

*** CPSZ:

*** CPSZ:
I am totally stuck.
Simon
From: Simon Peyton Jones
Sent: 06 March 2014 22:11
To: ghc-devs at haskell.org<mailto:ghc-devs at haskell.org>
Subject: new Windows build problem

Sigh.  Totally new problem with building GHC (HEAD) on Windows..

"inplace/bin/ghc-stage2.exe" -hisuf hi -osuf  o -hcsuf hc -static  -H32m -O -Werror -Wall -H64m -O0    -package-name haskell98-2.0.0.3 -hide-all-packages -i -ilibraries/haskell98/. -ilibraries/haskell98/dist-install/build -ilibraries/haskell98/dist-install/build/autogen -Ilibraries/haskell98/dist-install/build -Ilibraries/haskell98/dist-install/build/autogen -Ilibraries/haskell98/.    -optP-include -optPlibraries/haskell98/dist-install/build/autogen/cabal_macros.h -package array-0.5.0.0 -package base-4.7.0.0 -package directory-1.2.0.2 -package old-locale-1.0.0.6 -package old-time-1.1.0.2 -package process-1.2.0.0 -package time-1.4.2 -Wall -XHaskell98 -O2 -O -dcore-lint -fno-warn-amp  -fno-warn-deprecated-flags -dcore-lint  -no-user-package-db -rtsopts      -odir libraries/haskell98/dist-install/build -hidir libraries/haskell98/dist-install/build -stubdir libraries/haskell98/dist-install/build   -c libraries/haskell98/./Directory.hs -o libraries/haskell98/dist-install/build/Directory.o

bash: [6536: 1 (255)] tcsetattr: Inappropriate ioctl for device

HEAD $
What on earth is this ioctl stuff?
The above is repeatable; same command line, same result.

But I'm also getting random seg-faults when building libraries with the stage2 compiler

libraries/random/ghc.mk:5: recipe for target 'libraries/random/dist-install/build/System/Random.o' failed

make[1]: *** [libraries/random/dist-install/build/System/Random.o] Segmentation fault
This is NOT repeatable.  Saying 'make' again gets further.
Any ideas?
Simon
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/ghc-devs/attachments/20140307/17401ddd/attachment-0001.html>

From howard_b_golden at yahoo.com  Fri Mar  7 23:00:26 2014
From: howard_b_golden at yahoo.com (Howard B. Golden)
Date: Fri, 7 Mar 2014 15:00:26 -0800 (PST)
Subject: new Windows build problem
In-Reply-To: <59543203684B2244980D7E4057D5FBC1487DD764@DB3EX14MBXC306.europe.corp.microsoft.com>
References: <59543203684B2244980D7E4057D5FBC1487DBAA3@DB3EX14MBXC306.europe.corp.microsoft.com>
 <59543203684B2244980D7E4057D5FBC1487DD764@DB3EX14MBXC306.europe.corp.microsoft.com>
Message-ID: <1394233226.65312.YahooMailNeo@web164004.mail.gq1.yahoo.com>

Hi Simon,

I have a hunch that the tcsetattr:... message is coming _after_ the segfault. On Windows (not in a command window) you are probably trying to pop-up a window, but what is running isn't a terminal, so the tcsetattr fails.

In other words, look for the cause of the segfault first.

Howard


________________________________
 From: Simon Peyton Jones <simonpj at microsoft.com>
To: Simon Peyton Jones <simonpj at microsoft.com>; "ghc-devs at haskell.org" <ghc-devs at haskell.org> 
Sent: Friday, March 7, 2014 2:33 PM
Subject: RE: new Windows build problem
 


Is anyone able to help me here?? I have no idea how to hunt down a seg-fault in ghc-stage1.exe on Windows.
I thought of using git bisect to try to find the offending commit (though each bisection takes a couple of hours since it has to be a clean build).? But I was defeated by the fact that haddock is a separate repo, and the task of finding the haddock commit that matches the ghc commit defeated me.? There are probably other repos too, but they probably change less often.
In short, I?m stuck.? I can use Linux at work, but when I?m on the move I just have my Windows laptop.? What is frustrating is that GHC used to build on Windows just fine.? 
Does anyone feel more competent than me feel able to bisect their way to the offending commit?
Thanks
Simon
?
From:ghc-devs [mailto:ghc-devs-bounces at haskell.org] On Behalf Of Simon Peyton Jones
Sent: 06 March 2014 23:42
To: ghc-devs at haskell.org
Subject: RE: new Windows build problem
?
Actually, the two problems seem to be the same.? A fresh build from scratch yields
libraries/random/ghc.mk:5: recipe for target 'libraries/random/dist-install/build/System/Random.o' failed
make[1]: *** [libraries/random/dist-install/build/System/Random.o] Segmentation fault
Then sniping the command line that tried to build Random.o yields
?
"inplace/bin/ghc-stage2.exe" -hisuf hi -osuf? o -hcsuf hc -static? -H32m -O -Werror -Wall -H64m -O0??? -package-name random-1.0.1.1 -hide-all-packages -i -ilibraries/random/. -ilibraries/random/dist-install/build -ilibraries/random/dist-install/build/autogen -Ilibraries/random/dist-install/build -Ilibraries/random/dist-install/build/autogen -Ilibraries/random/.??? -optP-include -optPlibraries/random/dist-install/build/autogen/cabal_macros.h -package base-4.7.0.0 -package time-1.4.2 -O2 -XHaskell98 -XCPP -O2 -O -dcore-lint -fno-warn-amp? -fno-warn-deprecated-flags -dcore-lint? -no-user-package-db -rtsopts????? -odir libraries/random/dist-install/build -hidir libraries/random/dist-install/build -stubdir libraries/random/dist-install/build?? -c libraries/random/./System/Random.hs -o libraries/random/dist-install/build/System/Random.o
?
bash: [6536: 1 (255)] tcsetattr: Inappropriate ioctl for device
io
So this ioctl thing seems to be reported as a seg fault by the make system.
Running the same command from a ?cmd? window does give a seg-fault pop-up window.? Alas.
Running with ?dshow-passes shows that it happens during code generation,
*** CorePrep:
Result size of CorePrep = {terms: 1,214, types: 912, coercions: 52}
*** Core Linted result of CorePrep:
*** Stg2Stg:
*** CodeOutput:
*** New CodeGen:
*** CPSZ:
*** CPSZ:
I am totally stuck.
Simon
From:Simon Peyton Jones 
Sent: 06 March 2014 22:11
To: ghc-devs at haskell.org
Subject: new Windows build problem
?
Sigh.? Totally new problem with building GHC (HEAD) on Windows..? 
"inplace/bin/ghc-stage2.exe" -hisuf hi -osuf? o -hcsuf hc -static? -H32m -O -Werror -Wall -H64m -O0??? -package-name haskell98-2.0.0.3 -hide-all-packages -i -ilibraries/haskell98/. -ilibraries/haskell98/dist-install/build -ilibraries/haskell98/dist-install/build/autogen -Ilibraries/haskell98/dist-install/build -Ilibraries/haskell98/dist-install/build/autogen -Ilibraries/haskell98/.??? -optP-include -optPlibraries/haskell98/dist-install/build/autogen/cabal_macros.h -package array-0.5.0.0 -package base-4.7.0.0 -package directory-1.2.0.2 -package old-locale-1.0.0.6 -package old-time-1.1.0.2 -package process-1.2.0.0 -package time-1.4.2 -Wall -XHaskell98 -O2 -O -dcore-lint -fno-warn-amp? -fno-warn-deprecated-flags -dcore-lint? -no-user-package-db -rtsopts????? -odir libraries/haskell98/dist-install/build -hidir libraries/haskell98/dist-install/build -stubdir libraries/haskell98/dist-install/build?? -c libraries/haskell98/./Directory.hs -o
 libraries/haskell98/dist-install/build/Directory.o 
bash: [6536: 1 (255)] tcsetattr: Inappropriate ioctl for device
HEAD $
What on earth is this ioctl stuff?
The above is repeatable; same command line, same result.
?
But I?m also getting random seg-faults when building libraries with the stage2 compiler 
libraries/random/ghc.mk:5: recipe for target 'libraries/random/dist-install/build/System/Random.o' failed
make[1]: *** [libraries/random/dist-install/build/System/Random.o] Segmentation fault
This is NOT repeatable.? Saying ?make? again gets further.
Any ideas?
Simon

_______________________________________________
ghc-devs mailing list
ghc-devs at haskell.org
http://www.haskell.org/mailman/listinfo/ghc-devs
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/ghc-devs/attachments/20140307/81a535c7/attachment.html>

From fuuzetsu at fuuzetsu.co.uk  Sat Mar  8 05:49:24 2014
From: fuuzetsu at fuuzetsu.co.uk (Mateusz Kowalczyk)
Date: Sat, 08 Mar 2014 05:49:24 +0000
Subject: libraries/integer-gmp/cbits/gmp-wrappers.cmm:30:26: fatal error:
 HsIntegerGmp.h: No such file or directory
Message-ID: <531AAF64.90506@fuuzetsu.co.uk>

Hi,

I'm trying to build HEAD but I'm getting

libraries/integer-gmp/cbits/gmp-wrappers.cmm:30:26: fatal error:
HsIntegerGmp.h: No such file or directory
 #include "HsIntegerGmp.h"
                          ^
compilation terminated.
make[1]: ***
[libraries/integer-gmp/dist-install/build/.depend-v-dyn.c_asm] Error 1
make: *** [all] Error 2

This in on 32-bit Gentoo Linux, using 7.6.3 to build. I've been able to
build fine before. My last few versions are

?
drwxr-xr-x    5 shana shana       4096 Feb 19 04:45 ghc-20140218
drwxr-xr-x    5 shana shana       4096 Feb 22 22:04 ghc-20140220
drwxr-xr-x    5 shana shana       4096 Feb 25 08:44 ghc-20140225

which means that the problem must have been introduced some time after
that point.

Does anyone have any ideas?

-- 
Mateusz K.

From marlowsd at gmail.com  Sat Mar  8 07:18:20 2014
From: marlowsd at gmail.com (Simon Marlow)
Date: Sat, 08 Mar 2014 07:18:20 +0000
Subject: Building GHC for performance testing
In-Reply-To: <CAK-tuPb5mQJ39q3C69YnGKe5zt5CqnxwdiH4gLfue7gyg7gjYA@mail.gmail.com>
References: <CAK-tuPb5mQJ39q3C69YnGKe5zt5CqnxwdiH4gLfue7gyg7gjYA@mail.gmail.com>
Message-ID: <531AC43C.2010003@gmail.com>

On 06/03/14 09:50, Johan Tibell wrote:
> Hi,
>
> I'd like to set up a performance build bot for GHC, but before I can do
> that I need a script that reliably builds GHC and runs nofib. Do we have
> such a script? Here's a strawman proposal for one:
>
>      cabal install happy alex
>      git clone git://git.haskell.org/ghc.git
> <http://git.haskell.org/ghc.git>
>      cd ghc
>      ./sync-all --nofib get
>      perl boot

./boot

>      ./configure
>      make
>      cd nofib
>      make clean
>      make boot
>      make -k mode=slow
>
> Questions:
>
>   * Does this look sensible?
>   * Is there a way to only build and run a subset of the benchmarks?
>   * Are there any tweaks to mk/build.mk <http://build.mk> we can do to
> make the build faster without compromising the results?

Turn down the stage2 optimisation, and turn off the docs:

GhcStage2HcOpts = -O
HADDOCK_DOCS       = NO
BUILD_DOCBOOK_HTML = NO
BUILD_DOCBOOK_PS   = NO
BUILD_DOCBOOK_PDF  = NO

>   * Is there a way to do this in a cheap throwaway VM like travis-ci
> does? Could such a VM already provide GHC and the required libs to make
> the whole thing hermetic?

Sure.  I occasionally use EC2 for GHC hacking and I had a VM set up with 
all the tools ready to work on GHC.  (but I assume you mean a local VM; 
EC2 is not good for perf measurements)

Cheers,
Simon


From mle+hs at mega-nerd.com  Sat Mar  8 07:19:11 2014
From: mle+hs at mega-nerd.com (Erik de Castro Lopo)
Date: Sat, 8 Mar 2014 18:19:11 +1100
Subject: libraries/integer-gmp/cbits/gmp-wrappers.cmm:30:26: fatal
 error: HsIntegerGmp.h: No such file or directory
In-Reply-To: <531AAF64.90506@fuuzetsu.co.uk>
References: <531AAF64.90506@fuuzetsu.co.uk>
Message-ID: <20140308181911.230a1d7c6f1ca4ff6b307bdb@mega-nerd.com>

Mateusz Kowalczyk wrote:

> I'm trying to build HEAD but I'm getting
> 
> libraries/integer-gmp/cbits/gmp-wrappers.cmm:30:26: fatal error:
> HsIntegerGmp.h: No such file or directory
>  #include "HsIntegerGmp.h"
>                           ^
> compilation terminated.
> make[1]: ***
> [libraries/integer-gmp/dist-install/build/.depend-v-dyn.c_asm] Error 1
> make: *** [all] Error 2
> 
> This in on 32-bit Gentoo Linux, using 7.6.3 to build. I've been able to
> build fine before. My last few versions are
> 
> ?
> drwxr-xr-x    5 shana shana       4096 Feb 19 04:45 ghc-20140218
> drwxr-xr-x    5 shana shana       4096 Feb 22 22:04 ghc-20140220
> drwxr-xr-x    5 shana shana       4096 Feb 25 08:44 ghc-20140225
> 
> which means that the problem must have been introduced some time after
> that point.
> 
> Does anyone have any ideas?

What did you do that led up to this point?

Erik
-- 
----------------------------------------------------------------------
Erik de Castro Lopo
http://www.mega-nerd.com/

From johan.tibell at gmail.com  Sat Mar  8 07:45:25 2014
From: johan.tibell at gmail.com (Johan Tibell)
Date: Sat, 8 Mar 2014 08:45:25 +0100
Subject: "quick" vs "perf" builds
Message-ID: <CAK-tuPbo=McKZxADAt=kAYXKqYsyvU7hVncEhnDmuQvEt70LnQ@mail.gmail.com>

Hi,

In my mind the "quick" build should be like the "perf" build, except
building the stage2 compiler should be much faster. However, the perf build
uses

GhcLibHcOpts = -O2

while the quick build uses

GhcLibHcOpts = -O -fasm

This means that if you're working on optimizing the generated code and are
running benchmarks to verify your results, the quick build doesn't do the
right thing.

Since the purpose of the quick build is to work on the stage2 compiler,
would it make sense having it build the libraries in the same way as the
perf build?

-- Johan
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/ghc-devs/attachments/20140308/b802a683/attachment.html>

From hvriedel at gmail.com  Sat Mar  8 07:54:36 2014
From: hvriedel at gmail.com (Herbert Valerio Riedel)
Date: Sat, 08 Mar 2014 08:54:36 +0100
Subject: Building GHC for performance testing
In-Reply-To: <531AC43C.2010003@gmail.com> (Simon Marlow's message of "Sat, 08
 Mar 2014 07:18:20 +0000")
References: <CAK-tuPb5mQJ39q3C69YnGKe5zt5CqnxwdiH4gLfue7gyg7gjYA@mail.gmail.com>
 <531AC43C.2010003@gmail.com>
Message-ID: <87lhwlm8g3.fsf@gmail.com>

Hi Simon,

On 2014-03-08 at 08:18:20 +0100, Simon Marlow wrote:
> On 06/03/14 09:50, Johan Tibell wrote:

[...]

>>   * Are there any tweaks to mk/build.mk <http://build.mk> we can do to
>> make the build faster without compromising the results?
>
> Turn down the stage2 optimisation, and turn off the docs:
>
> GhcStage2HcOpts = -O

...but doesn't that compromise the compile-time metrics collected by
nofib about GHC's performance?

cheers,
  hvr

From fuuzetsu at fuuzetsu.co.uk  Sat Mar  8 08:11:09 2014
From: fuuzetsu at fuuzetsu.co.uk (Mateusz Kowalczyk)
Date: Sat, 08 Mar 2014 08:11:09 +0000
Subject: libraries/integer-gmp/cbits/gmp-wrappers.cmm:30:26: fatal error:
 HsIntegerGmp.h: No such file or directory
In-Reply-To: <20140308181911.230a1d7c6f1ca4ff6b307bdb@mega-nerd.com>
References: <531AAF64.90506@fuuzetsu.co.uk>
 <20140308181911.230a1d7c6f1ca4ff6b307bdb@mega-nerd.com>
Message-ID: <531AD09D.3030906@fuuzetsu.co.uk>

On 08/03/14 07:19, Erik de Castro Lopo wrote:
> Mateusz Kowalczyk wrote:
> 
>> I'm trying to build HEAD but I'm getting
>>
>> libraries/integer-gmp/cbits/gmp-wrappers.cmm:30:26: fatal error:
>> HsIntegerGmp.h: No such file or directory
>>  #include "HsIntegerGmp.h"
>>                           ^
>> compilation terminated.
>> make[1]: ***
>> [libraries/integer-gmp/dist-install/build/.depend-v-dyn.c_asm] Error 1
>> make: *** [all] Error 2
>>
>> This in on 32-bit Gentoo Linux, using 7.6.3 to build. I've been able to
>> build fine before. My last few versions are
>>
>> ?
>> drwxr-xr-x    5 shana shana       4096 Feb 19 04:45 ghc-20140218
>> drwxr-xr-x    5 shana shana       4096 Feb 22 22:04 ghc-20140220
>> drwxr-xr-x    5 shana shana       4096 Feb 25 08:44 ghc-20140225
>>
>> which means that the problem must have been introduced some time after
>> that point.
>>
>> Does anyone have any ideas?
> 
> What did you do that led up to this point?
> 
> Erik
> 

./sync-all get && sync-all pull
./configure --prefix=/home/shana/ghc-20140308 && make

I also ran ?./sync-all reset --hard?

I now ran ?make clean && ./configure --prefix=/home/shana/ghc-20140308
&& make? and saved the results. You can find the log at
http://fuuzetsu.co.uk/misc/ghc-20140308-gmp-log (~1.8MB).

-- 
Mateusz K.

From fuuzetsu at fuuzetsu.co.uk  Sat Mar  8 08:12:00 2014
From: fuuzetsu at fuuzetsu.co.uk (Mateusz Kowalczyk)
Date: Sat, 08 Mar 2014 08:12:00 +0000
Subject: libraries/integer-gmp/cbits/gmp-wrappers.cmm:30:26: fatal error:
 HsIntegerGmp.h: No such file or directory
In-Reply-To: <531AD09D.3030906@fuuzetsu.co.uk>
References: <531AAF64.90506@fuuzetsu.co.uk>
 <20140308181911.230a1d7c6f1ca4ff6b307bdb@mega-nerd.com>
 <531AD09D.3030906@fuuzetsu.co.uk>
Message-ID: <531AD0D0.2010900@fuuzetsu.co.uk>

On 08/03/14 08:11, Mateusz Kowalczyk wrote:
> On 08/03/14 07:19, Erik de Castro Lopo wrote:
>> Mateusz Kowalczyk wrote:
>>
>>> I'm trying to build HEAD but I'm getting
>>>
>>> libraries/integer-gmp/cbits/gmp-wrappers.cmm:30:26: fatal error:
>>> HsIntegerGmp.h: No such file or directory
>>>  #include "HsIntegerGmp.h"
>>>                           ^
>>> compilation terminated.
>>> make[1]: ***
>>> [libraries/integer-gmp/dist-install/build/.depend-v-dyn.c_asm] Error 1
>>> make: *** [all] Error 2
>>>
>>> This in on 32-bit Gentoo Linux, using 7.6.3 to build. I've been able to
>>> build fine before. My last few versions are
>>>
>>> ?
>>> drwxr-xr-x    5 shana shana       4096 Feb 19 04:45 ghc-20140218
>>> drwxr-xr-x    5 shana shana       4096 Feb 22 22:04 ghc-20140220
>>> drwxr-xr-x    5 shana shana       4096 Feb 25 08:44 ghc-20140225
>>>
>>> which means that the problem must have been introduced some time after
>>> that point.
>>>
>>> Does anyone have any ideas?
>>
>> What did you do that led up to this point?
>>
>> Erik
>>
> 
> ./sync-all get && sync-all pull
> ./configure --prefix=/home/shana/ghc-20140308 && make
> 
> I also ran ?./sync-all reset --hard?
> 
> I now ran ?make clean && ./configure --prefix=/home/shana/ghc-20140308
> && make? and saved the results. You can find the log at
> http://fuuzetsu.co.uk/misc/ghc-20140308-gmp-log (~1.8MB).
> 

I was told in #ghc that I need to re-run ?perl boot? as well. I'll try
it and post back if it still fails.

-- 
Mateusz K.

From johan.tibell at gmail.com  Sat Mar  8 08:21:31 2014
From: johan.tibell at gmail.com (Johan Tibell)
Date: Sat, 8 Mar 2014 09:21:31 +0100
Subject: Optimized Cmm containing useless blocks
Message-ID: <CAK-tuPa9c6=ay32NMeaCGfZDqpbGJH0-naLRA8cOiokxtBz2vA@mail.gmail.com>

While looking at some generated Cmm I saw things like this

c1Cm:
    goto c1Cq;
c1Cq:

i.e. useless basic blocks that haven't been optimized away. Is this to be
expected?

-- Johan
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/ghc-devs/attachments/20140308/5994a3fa/attachment.html>

From johan.tibell at gmail.com  Sat Mar  8 08:23:26 2014
From: johan.tibell at gmail.com (Johan Tibell)
Date: Sat, 8 Mar 2014 09:23:26 +0100
Subject: Optimized Cmm containing useless blocks
In-Reply-To: <CAK-tuPa9c6=ay32NMeaCGfZDqpbGJH0-naLRA8cOiokxtBz2vA@mail.gmail.com>
References: <CAK-tuPa9c6=ay32NMeaCGfZDqpbGJH0-naLRA8cOiokxtBz2vA@mail.gmail.com>
Message-ID: <CAK-tuPbBM9RBD5hpVb_+_y6p75LuUmv2=qoFfDTsznLDn+L+kw@mail.gmail.com>

On a related note, doesn't Cmm support fall-through branches? Heap checks
use two branches instead of one branch and one fall-through case:

      c1Cq:
          Hp = Hp + 152;
          if (Hp > I64[BaseReg + 856]) goto c1Cs; else goto c1Cr;
      c1Cs:
          I64[BaseReg + 904] = 152;
          goto c1Cp;
      c1Cp:
          R1 = PicBaseReg + a_r1za_closure;
          call (I64[BaseReg - 8])(R1) args: 8, res: 0, upd: 8;
      c1Cr:



On Sat, Mar 8, 2014 at 9:21 AM, Johan Tibell <johan.tibell at gmail.com> wrote:

> While looking at some generated Cmm I saw things like this
>
> c1Cm:
>     goto c1Cq;
> c1Cq:
>
> i.e. useless basic blocks that haven't been optimized away. Is this to be
> expected?
>
> -- Johan
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/ghc-devs/attachments/20140308/6355cd7b/attachment.html>

From mle+hs at mega-nerd.com  Sat Mar  8 08:39:40 2014
From: mle+hs at mega-nerd.com (Erik de Castro Lopo)
Date: Sat, 8 Mar 2014 19:39:40 +1100
Subject: libraries/integer-gmp/cbits/gmp-wrappers.cmm:30:26: fatal
 error: HsIntegerGmp.h: No such file or directory
In-Reply-To: <531AD0D0.2010900@fuuzetsu.co.uk>
References: <531AAF64.90506@fuuzetsu.co.uk>
 <20140308181911.230a1d7c6f1ca4ff6b307bdb@mega-nerd.com>
 <531AD09D.3030906@fuuzetsu.co.uk> <531AD0D0.2010900@fuuzetsu.co.uk>
Message-ID: <20140308193940.8b3e298d12baf7a27770b41e@mega-nerd.com>

Mateusz Kowalczyk wrote:

> I was told in #ghc that I need to re-run ?perl boot? as well. I'll try
> it and post back if it still fails.

My guess is that the missing 'perl boot' step is what's causing this.
When working from the GHC git tree I run 'perl boot' every time I
run configure.

Erik
-- 
----------------------------------------------------------------------
Erik de Castro Lopo
http://www.mega-nerd.com/

From marlowsd at gmail.com  Sat Mar  8 10:20:16 2014
From: marlowsd at gmail.com (Simon Marlow)
Date: Sat, 08 Mar 2014 10:20:16 +0000
Subject: Building GHC for performance testing
In-Reply-To: <87lhwlm8g3.fsf@gmail.com>
References: <CAK-tuPb5mQJ39q3C69YnGKe5zt5CqnxwdiH4gLfue7gyg7gjYA@mail.gmail.com>	<531AC43C.2010003@gmail.com>
 <87lhwlm8g3.fsf@gmail.com>
Message-ID: <531AEEE0.2010302@gmail.com>

On 08/03/14 07:54, Herbert Valerio Riedel wrote:
> Hi Simon,
>
> On 2014-03-08 at 08:18:20 +0100, Simon Marlow wrote:
>> On 06/03/14 09:50, Johan Tibell wrote:
>
> [...]
>
>>>    * Are there any tweaks to mk/build.mk <http://build.mk> we can do to
>>> make the build faster without compromising the results?
>>
>> Turn down the stage2 optimisation, and turn off the docs:
>>
>> GhcStage2HcOpts = -O
>
> ...but doesn't that compromise the compile-time metrics collected by
> nofib about GHC's performance?

I think Johan is interested primarily in runtime performance, but yes if 
you care about compile time then it's better to leave GhcStage2HcOpts at 
the default.

Cheers,
Simon


From carter.schonwald at gmail.com  Sat Mar  8 17:46:19 2014
From: carter.schonwald at gmail.com (Carter Schonwald)
Date: Sat, 8 Mar 2014 12:46:19 -0500
Subject: Building GHC for performance testing
In-Reply-To: <531AEEE0.2010302@gmail.com>
References: <CAK-tuPb5mQJ39q3C69YnGKe5zt5CqnxwdiH4gLfue7gyg7gjYA@mail.gmail.com>
 <531AC43C.2010003@gmail.com> <87lhwlm8g3.fsf@gmail.com>
 <531AEEE0.2010302@gmail.com>
Message-ID: <CAHYVw0w7Y2VxXeQ9ifxckjumGoNBWB0xmxB=MBoj_xSyM-b01w@mail.gmail.com>

one idea that I think Ben Gamari (or was it Reid?) pointed out is that
another (potentially valuable) metric is "how long does it take for ghc to
build itself"


On Sat, Mar 8, 2014 at 5:20 AM, Simon Marlow <marlowsd at gmail.com> wrote:

> On 08/03/14 07:54, Herbert Valerio Riedel wrote:
>
>> Hi Simon,
>>
>> On 2014-03-08 at 08:18:20 +0100, Simon Marlow wrote:
>>
>>> On 06/03/14 09:50, Johan Tibell wrote:
>>>
>>
>> [...]
>>
>>     * Are there any tweaks to mk/build.mk <http://build.mk> we can do to
>>>> make the build faster without compromising the results?
>>>>
>>>
>>> Turn down the stage2 optimisation, and turn off the docs:
>>>
>>> GhcStage2HcOpts = -O
>>>
>>
>> ...but doesn't that compromise the compile-time metrics collected by
>> nofib about GHC's performance?
>>
>
> I think Johan is interested primarily in runtime performance, but yes if
> you care about compile time then it's better to leave GhcStage2HcOpts at
> the default.
>
> Cheers,
> Simon
>
>
> _______________________________________________
> ghc-devs mailing list
> ghc-devs at haskell.org
> http://www.haskell.org/mailman/listinfo/ghc-devs
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/ghc-devs/attachments/20140308/14952c04/attachment.html>

From alexander.kjeldaas at gmail.com  Sat Mar  8 18:26:04 2014
From: alexander.kjeldaas at gmail.com (Alexander Kjeldaas)
Date: Sat, 8 Mar 2014 19:26:04 +0100
Subject: Optimized Cmm containing useless blocks
In-Reply-To: <CAK-tuPbBM9RBD5hpVb_+_y6p75LuUmv2=qoFfDTsznLDn+L+kw@mail.gmail.com>
References: <CAK-tuPa9c6=ay32NMeaCGfZDqpbGJH0-naLRA8cOiokxtBz2vA@mail.gmail.com>
 <CAK-tuPbBM9RBD5hpVb_+_y6p75LuUmv2=qoFfDTsznLDn+L+kw@mail.gmail.com>
Message-ID: <CAHVSqQeg_M=6rzqqQnFQu2n=cR-McRC6HG3_7VUPtuuZ60hNvw@mail.gmail.com>

Seems like something that should be delegated to a peep hole optimizer.
What you describe make it possible to reorder the basic blocks at a later
stage.

Alexander
On Mar 8, 2014 9:24 AM, "Johan Tibell" <johan.tibell at gmail.com> wrote:

> On a related note, doesn't Cmm support fall-through branches? Heap checks
> use two branches instead of one branch and one fall-through case:
>
>       c1Cq:
>           Hp = Hp + 152;
>           if (Hp > I64[BaseReg + 856]) goto c1Cs; else goto c1Cr;
>       c1Cs:
>           I64[BaseReg + 904] = 152;
>           goto c1Cp;
>       c1Cp:
>           R1 = PicBaseReg + a_r1za_closure;
>           call (I64[BaseReg - 8])(R1) args: 8, res: 0, upd: 8;
>       c1Cr:
>
>
>
> On Sat, Mar 8, 2014 at 9:21 AM, Johan Tibell <johan.tibell at gmail.com>wrote:
>
>> While looking at some generated Cmm I saw things like this
>>
>> c1Cm:
>>     goto c1Cq;
>> c1Cq:
>>
>> i.e. useless basic blocks that haven't been optimized away. Is this to be
>> expected?
>>
>> -- Johan
>>
>>
>
> _______________________________________________
> ghc-devs mailing list
> ghc-devs at haskell.org
> http://www.haskell.org/mailman/listinfo/ghc-devs
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/ghc-devs/attachments/20140308/307f8f5c/attachment.html>

From marlowsd at gmail.com  Sat Mar  8 19:50:42 2014
From: marlowsd at gmail.com (Simon Marlow)
Date: Sat, 08 Mar 2014 19:50:42 +0000
Subject: Building GHC for performance testing
In-Reply-To: <CAHYVw0w7Y2VxXeQ9ifxckjumGoNBWB0xmxB=MBoj_xSyM-b01w@mail.gmail.com>
References: <CAK-tuPb5mQJ39q3C69YnGKe5zt5CqnxwdiH4gLfue7gyg7gjYA@mail.gmail.com>
 <531AC43C.2010003@gmail.com> <87lhwlm8g3.fsf@gmail.com>
 <531AEEE0.2010302@gmail.com>
 <CAHYVw0w7Y2VxXeQ9ifxckjumGoNBWB0xmxB=MBoj_xSyM-b01w@mail.gmail.com>
Message-ID: <531B7492.3020607@gmail.com>

On 08/03/14 17:46, Carter Schonwald wrote:
> one idea that I think Ben Gamari (or was it Reid?) pointed out is that
> another (potentially valuable) metric is "how long does it take for ghc
> to build itself"

The trouble is, that figure is affected by three main factors: the 
performance of the code generated by GHC, the performance of GHC itself, 
and the size of GHC's source code.  You want to measure all these 
independently.

Cheers,
Simon

>
> On Sat, Mar 8, 2014 at 5:20 AM, Simon Marlow <marlowsd at gmail.com
> <mailto:marlowsd at gmail.com>> wrote:
>
>     On 08/03/14 07:54, Herbert Valerio Riedel wrote:
>
>         Hi Simon,
>
>         On 2014-03-08 at 08:18:20 +0100, Simon Marlow wrote:
>
>             On 06/03/14 09:50, Johan Tibell wrote:
>
>
>         [...]
>
>                     * Are there any tweaks to mk/build.mk
>                 <http://build.mk> <http://build.mk> we can do to
>                 make the build faster without compromising the results?
>
>
>             Turn down the stage2 optimisation, and turn off the docs:
>
>             GhcStage2HcOpts = -O
>
>
>         ...but doesn't that compromise the compile-time metrics collected by
>         nofib about GHC's performance?
>
>
>     I think Johan is interested primarily in runtime performance, but
>     yes if you care about compile time then it's better to leave
>     GhcStage2HcOpts at the default.
>
>     Cheers,
>     Simon
>
>
>     _________________________________________________
>     ghc-devs mailing list
>     ghc-devs at haskell.org <mailto:ghc-devs at haskell.org>
>     http://www.haskell.org/__mailman/listinfo/ghc-devs
>     <http://www.haskell.org/mailman/listinfo/ghc-devs>
>
>


From jan.stolarek at p.lodz.pl  Sun Mar  9 21:22:20 2014
From: jan.stolarek at p.lodz.pl (Jan Stolarek)
Date: Sun, 9 Mar 2014 22:22:20 +0100
Subject: Optimized Cmm containing useless blocks
In-Reply-To: <CAK-tuPa9c6=ay32NMeaCGfZDqpbGJH0-naLRA8cOiokxtBz2vA@mail.gmail.com>
References: <CAK-tuPa9c6=ay32NMeaCGfZDqpbGJH0-naLRA8cOiokxtBz2vA@mail.gmail.com>
Message-ID: <201403092222.20849.jan.stolarek@p.lodz.pl>

> useless basic blocks that haven't been optimized away. Is this to be
> expected?
I believe this should not happen but it's hard to say without looking at a complete dump. Could 
you post full Cmm dump + a minimial working example that generates that? 

> On a related note, doesn't Cmm support fall-through branches? 
Cmm program is represented as a graph with each node (a block of code) having explicit list of 
successors. Having fall-throughs in Cmm would require storing blocks linearily with a guarantee 
that their order will not change. Note that fall-throughs are present in the generated assembly. 

Janek

From karel.gardas at centrum.cz  Sun Mar  9 21:39:43 2014
From: karel.gardas at centrum.cz (Karel Gardas)
Date: Sun, 09 Mar 2014 22:39:43 +0100
Subject: Optimized Cmm containing useless blocks
In-Reply-To: <CAK-tuPa9c6=ay32NMeaCGfZDqpbGJH0-naLRA8cOiokxtBz2vA@mail.gmail.com>
References: <CAK-tuPa9c6=ay32NMeaCGfZDqpbGJH0-naLRA8cOiokxtBz2vA@mail.gmail.com>
Message-ID: <531CDF9F.8060606@centrum.cz>


If I may add to this, then I'm curious why there is something like:

  I64[BaseReg + 784] = I64[BaseReg + 784];

presented in Cmm optimized code. Since I don't know Cmm enough I've 
verified if the semantics is really C like by looking into generated asm 
and indeed it looks so. This costs 5 isns of sparc asm btw.

If someone is interested to duplicate this, then use sparc or ppc 32 bit 
registerised target and Haskell code:

module Main where

import Data.Int

main = print ( ( 2 ^ 6 ) :: Int64 )

Karel

On 03/ 8/14 09:21 AM, Johan Tibell wrote:
> While looking at some generated Cmm I saw things like this
>
> c1Cm:
>      goto c1Cq;
> c1Cq:
>
> i.e. useless basic blocks that haven't been optimized away. Is this to
> be expected?
>
> -- Johan
>
>
>
> _______________________________________________
> ghc-devs mailing list
> ghc-devs at haskell.org
> http://www.haskell.org/mailman/listinfo/ghc-devs


From johan.tibell at gmail.com  Mon Mar 10 08:13:20 2014
From: johan.tibell at gmail.com (Johan Tibell)
Date: Mon, 10 Mar 2014 09:13:20 +0100
Subject: Optimized Cmm containing useless blocks
In-Reply-To: <201403092222.20849.jan.stolarek@p.lodz.pl>
References: <CAK-tuPa9c6=ay32NMeaCGfZDqpbGJH0-naLRA8cOiokxtBz2vA@mail.gmail.com>
 <201403092222.20849.jan.stolarek@p.lodz.pl>
Message-ID: <CAK-tuPbefY4SA+4Q0skM0nFeF2i=ZMav2pc_S-i+7HpsuVkh6w@mail.gmail.com>

On Sun, Mar 9, 2014 at 10:22 PM, Jan Stolarek <jan.stolarek at p.lodz.pl>wrote:

> > useless basic blocks that haven't been optimized away. Is this to be
> > expected?
> I believe this should not happen but it's hard to say without looking at a
> complete dump. Could
> you post full Cmm dump + a minimial working example that generates that?
>
> > On a related note, doesn't Cmm support fall-through branches?
> Cmm program is represented as a graph with each node (a block of code)
> having explicit list of
> successors. Having fall-throughs in Cmm would require storing blocks
> linearily with a guarantee
> that their order will not change. Note that fall-throughs are present in
> the generated assembly.
>

This was me being stupid. GHC happily prints optimized Cmm even if no
optimization was done due to a missing flag (cause GHC defaults to -O0).
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/ghc-devs/attachments/20140310/ece3d60f/attachment.html>

From johan.tibell at gmail.com  Mon Mar 10 08:22:00 2014
From: johan.tibell at gmail.com (Johan Tibell)
Date: Mon, 10 Mar 2014 09:22:00 +0100
Subject: Card marking for newly allocated arrays
Message-ID: <CAK-tuPb8QEAuYDmdxVV4DSM1kMPco1ck70CdUZWVYrsoefxJcQ@mail.gmail.com>

Hi,

For MutableArray#s, a card is supposed to be marked if the array is
pointing to an object in a younger generation than itself resides in. Since
the array always points to elements in the same or an older generation when
it gets allocated, we should be fine with marking the array as clean upon
allocation and setting all the cards to zero. Right now it's marked as
*dirty* and all cards are (modulo a bug) marked as zero.

I think we should mark these arrays as clean to avoid some GC costs later.
We could avoid writing the card table on allocation as well, as it's always
safe to default to dirty. However, this will incur extra GC costs later
(after the first write to the array) as the whole array will appear as
dirty (due to garbage values in the card table as it wasn't initialized)
even if only a single element was written.

I'm leaning towards 1) marking arrays as clean and 2) zeroing out the card
table when the array is created. Thoughts?

-- Johan
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/ghc-devs/attachments/20140310/3d809421/attachment.html>

From simonpj at microsoft.com  Mon Mar 10 08:30:43 2014
From: simonpj at microsoft.com (Simon Peyton Jones)
Date: Mon, 10 Mar 2014 08:30:43 +0000
Subject: Optimized Cmm containing useless blocks
In-Reply-To: <531CDF9F.8060606@centrum.cz>
References: <CAK-tuPa9c6=ay32NMeaCGfZDqpbGJH0-naLRA8cOiokxtBz2vA@mail.gmail.com>
 <531CDF9F.8060606@centrum.cz>
Message-ID: <59543203684B2244980D7E4057D5FBC1487DFE74@DB3EX14MBXC306.europe.corp.microsoft.com>

That doesn't look right.  Are you using -O?

If so, perhaps open a ticket explaining how to reproduce, and including the results of -ddump-cmm.

(Don't use module Main, because it's irrelevant to this question, and generate a certain amount of auxiliary goop.)

Thanks

SImon

| -----Original Message-----
| From: ghc-devs [mailto:ghc-devs-bounces at haskell.org] On Behalf Of Karel
| Gardas
| Sent: 09 March 2014 21:40
| To: Johan Tibell
| Cc: ghc-devs at haskell.org
| Subject: Re: Optimized Cmm containing useless blocks
| 
| 
| If I may add to this, then I'm curious why there is something like:
| 
|   I64[BaseReg + 784] = I64[BaseReg + 784];
| 
| presented in Cmm optimized code. Since I don't know Cmm enough I've
| verified if the semantics is really C like by looking into generated asm
| and indeed it looks so. This costs 5 isns of sparc asm btw.
| 
| If someone is interested to duplicate this, then use sparc or ppc 32 bit
| registerised target and Haskell code:
| 
| module Main where
| 
| import Data.Int
| 
| main = print ( ( 2 ^ 6 ) :: Int64 )
| 
| Karel
| 
| On 03/ 8/14 09:21 AM, Johan Tibell wrote:
| > While looking at some generated Cmm I saw things like this
| >
| > c1Cm:
| >      goto c1Cq;
| > c1Cq:
| >
| > i.e. useless basic blocks that haven't been optimized away. Is this to
| > be expected?
| >
| > -- Johan
| >
| >
| >
| > _______________________________________________
| > ghc-devs mailing list
| > ghc-devs at haskell.org
| > http://www.haskell.org/mailman/listinfo/ghc-devs
| 
| _______________________________________________
| ghc-devs mailing list
| ghc-devs at haskell.org
| http://www.haskell.org/mailman/listinfo/ghc-devs

From johan.tibell at gmail.com  Mon Mar 10 09:08:47 2014
From: johan.tibell at gmail.com (Johan Tibell)
Date: Mon, 10 Mar 2014 10:08:47 +0100
Subject: Optimized Cmm containing useless blocks
In-Reply-To: <59543203684B2244980D7E4057D5FBC1487DFE74@DB3EX14MBXC306.europe.corp.microsoft.com>
References: <CAK-tuPa9c6=ay32NMeaCGfZDqpbGJH0-naLRA8cOiokxtBz2vA@mail.gmail.com>
 <531CDF9F.8060606@centrum.cz>
 <59543203684B2244980D7E4057D5FBC1487DFE74@DB3EX14MBXC306.europe.corp.microsoft.com>
Message-ID: <CAK-tuPZYG9SPPBTiuzbQ2zFfYiumRxCEaAWJ9dDa=KyVG3=ngw@mail.gmail.com>

This was my mess-up (see previous email). Sorry for the noise.


On Mon, Mar 10, 2014 at 9:30 AM, Simon Peyton Jones
<simonpj at microsoft.com>wrote:

> That doesn't look right.  Are you using -O?
>
> If so, perhaps open a ticket explaining how to reproduce, and including
> the results of -ddump-cmm.
>
> (Don't use module Main, because it's irrelevant to this question, and
> generate a certain amount of auxiliary goop.)
>
> Thanks
>
> SImon
>
> | -----Original Message-----
> | From: ghc-devs [mailto:ghc-devs-bounces at haskell.org] On Behalf Of Karel
> | Gardas
> | Sent: 09 March 2014 21:40
> | To: Johan Tibell
> | Cc: ghc-devs at haskell.org
> | Subject: Re: Optimized Cmm containing useless blocks
> |
> |
> | If I may add to this, then I'm curious why there is something like:
> |
> |   I64[BaseReg + 784] = I64[BaseReg + 784];
> |
> | presented in Cmm optimized code. Since I don't know Cmm enough I've
> | verified if the semantics is really C like by looking into generated asm
> | and indeed it looks so. This costs 5 isns of sparc asm btw.
> |
> | If someone is interested to duplicate this, then use sparc or ppc 32 bit
> | registerised target and Haskell code:
> |
> | module Main where
> |
> | import Data.Int
> |
> | main = print ( ( 2 ^ 6 ) :: Int64 )
> |
> | Karel
> |
> | On 03/ 8/14 09:21 AM, Johan Tibell wrote:
> | > While looking at some generated Cmm I saw things like this
> | >
> | > c1Cm:
> | >      goto c1Cq;
> | > c1Cq:
> | >
> | > i.e. useless basic blocks that haven't been optimized away. Is this to
> | > be expected?
> | >
> | > -- Johan
> | >
> | >
> | >
> | > _______________________________________________
> | > ghc-devs mailing list
> | > ghc-devs at haskell.org
> | > http://www.haskell.org/mailman/listinfo/ghc-devs
> |
> | _______________________________________________
> | ghc-devs mailing list
> | ghc-devs at haskell.org
> | http://www.haskell.org/mailman/listinfo/ghc-devs
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/ghc-devs/attachments/20140310/75fe9ee9/attachment.html>

From marlowsd at gmail.com  Mon Mar 10 12:45:34 2014
From: marlowsd at gmail.com (Simon Marlow)
Date: Mon, 10 Mar 2014 12:45:34 +0000
Subject: Card marking for newly allocated arrays
In-Reply-To: <CAK-tuPb8QEAuYDmdxVV4DSM1kMPco1ck70CdUZWVYrsoefxJcQ@mail.gmail.com>
References: <CAK-tuPb8QEAuYDmdxVV4DSM1kMPco1ck70CdUZWVYrsoefxJcQ@mail.gmail.com>
Message-ID: <531DB3EE.4010904@gmail.com>

Johan and I talked about this on IRC.  The card table is actually 
irrelevant for newly allocated arrays, so in fact we can just not 
initialise it at all.

Cheers,
Simon

On 10/03/2014 08:22, Johan Tibell wrote:
> Hi,
>
> For MutableArray#s, a card is supposed to be marked if the array is
> pointing to an object in a younger generation than itself resides in.
> Since the array always points to elements in the same or an older
> generation when it gets allocated, we should be fine with marking the
> array as clean upon allocation and setting all the cards to zero. Right
> now it's marked as *dirty* and all cards are (modulo a bug) marked as zero.
>
> I think we should mark these arrays as clean to avoid some GC costs
> later. We could avoid writing the card table on allocation as well, as
> it's always safe to default to dirty. However, this will incur extra GC
> costs later (after the first write to the array) as the whole array will
> appear as dirty (due to garbage values in the card table as it wasn't
> initialized) even if only a single element was written.
>
> I'm leaning towards 1) marking arrays as clean and 2) zeroing out the
> card table when the array is created. Thoughts?
>
> -- Johan
>

From marlowsd at gmail.com  Mon Mar 10 15:54:27 2014
From: marlowsd at gmail.com (Simon Marlow)
Date: Mon, 10 Mar 2014 15:54:27 +0000
Subject: "quick" vs "perf" builds
In-Reply-To: <CAK-tuPbo=McKZxADAt=kAYXKqYsyvU7hVncEhnDmuQvEt70LnQ@mail.gmail.com>
References: <CAK-tuPbo=McKZxADAt=kAYXKqYsyvU7hVncEhnDmuQvEt70LnQ@mail.gmail.com>
Message-ID: <531DE033.90300@gmail.com>

Add another build type for your use case.  The "quick" build means 
"build everything as quickly as possible", which is useful for general 
development, but not benchmarking.

Cheers,
Simon

On 08/03/2014 07:45, Johan Tibell wrote:
> Hi,
>
> In my mind the "quick" build should be like the "perf" build, except
> building the stage2 compiler should be much faster. However, the perf
> build uses
>
> GhcLibHcOpts = -O2
>
> while the quick build uses
>
> GhcLibHcOpts = -O -fasm
>
> This means that if you're working on optimizing the generated code and
> are running benchmarks to verify your results, the quick build doesn't
> do the right thing.
>
> Since the purpose of the quick build is to work on the stage2 compiler,
> would it make sense having it build the libraries in the same way as the
> perf build?
>
> -- Johan
>
>
>
> _______________________________________________
> ghc-devs mailing list
> ghc-devs at haskell.org
> http://www.haskell.org/mailman/listinfo/ghc-devs
>

From austin at well-typed.com  Mon Mar 10 16:15:00 2014
From: austin at well-typed.com (Austin Seipp)
Date: Mon, 10 Mar 2014 11:15:00 -0500
Subject: "quick" vs "perf" builds
In-Reply-To: <531DE033.90300@gmail.com>
References: <CAK-tuPbo=McKZxADAt=kAYXKqYsyvU7hVncEhnDmuQvEt70LnQ@mail.gmail.com>
 <531DE033.90300@gmail.com>
Message-ID: <CAEs96n2X-d4ibO34pvRObfOmuScJDmtU+nc84M0UdtpBQSdWNw@mail.gmail.com>

I sometimes wonder if we should have a './performance' script or
something in the root dir that does what ./validate does for the test
suite: it always builds everything highly optimized (except perhaps
GHC itself), and then immediately runs nofib (including parallel SMP
tests, all that jazz) and sticks all that in a report you can keep
around, and use with nofib-analyze later.

But anyway, I agree with Simon that adding a 'bench' build type to
mk/build.mk.sample is the way to go. For completeness, it's probably
also worth adding a 'bench-llvm' type for the people who want to
benchmark with the LLVM backend.*

* We should actually refactor build.mk to not require duplication of
every build type for these two ways, but I digress enough already.

On Mon, Mar 10, 2014 at 10:54 AM, Simon Marlow <marlowsd at gmail.com> wrote:
> Add another build type for your use case.  The "quick" build means "build
> everything as quickly as possible", which is useful for general development,
> but not benchmarking.
>
> Cheers,
> Simon
>
>
> On 08/03/2014 07:45, Johan Tibell wrote:
>>
>> Hi,
>>
>> In my mind the "quick" build should be like the "perf" build, except
>> building the stage2 compiler should be much faster. However, the perf
>> build uses
>>
>> GhcLibHcOpts = -O2
>>
>> while the quick build uses
>>
>> GhcLibHcOpts = -O -fasm
>>
>> This means that if you're working on optimizing the generated code and
>> are running benchmarks to verify your results, the quick build doesn't
>> do the right thing.
>>
>> Since the purpose of the quick build is to work on the stage2 compiler,
>> would it make sense having it build the libraries in the same way as the
>> perf build?
>>
>> -- Johan
>>
>>
>>
>> _______________________________________________
>> ghc-devs mailing list
>> ghc-devs at haskell.org
>> http://www.haskell.org/mailman/listinfo/ghc-devs
>>
> _______________________________________________
> ghc-devs mailing list
> ghc-devs at haskell.org
> http://www.haskell.org/mailman/listinfo/ghc-devs
>



-- 
Regards,

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

From johan.tibell at gmail.com  Mon Mar 10 17:59:38 2014
From: johan.tibell at gmail.com (Johan Tibell)
Date: Mon, 10 Mar 2014 18:59:38 +0100
Subject: "quick" vs "perf" builds
In-Reply-To: <CAEs96n2X-d4ibO34pvRObfOmuScJDmtU+nc84M0UdtpBQSdWNw@mail.gmail.com>
References: <CAK-tuPbo=McKZxADAt=kAYXKqYsyvU7hVncEhnDmuQvEt70LnQ@mail.gmail.com>
 <531DE033.90300@gmail.com>
 <CAEs96n2X-d4ibO34pvRObfOmuScJDmtU+nc84M0UdtpBQSdWNw@mail.gmail.com>
Message-ID: <CAK-tuPY2h9unyvwpe77EGex_TnohqN_WrpAgR_pAMZCscFSGYQ@mail.gmail.com>

Added:
https://github.com/ghc/ghc/commit/ddf79ebf69fe4a6e69d69d451a6040a53b1ea12c


On Mon, Mar 10, 2014 at 5:15 PM, Austin Seipp <austin at well-typed.com> wrote:

> I sometimes wonder if we should have a './performance' script or
> something in the root dir that does what ./validate does for the test
> suite: it always builds everything highly optimized (except perhaps
> GHC itself), and then immediately runs nofib (including parallel SMP
> tests, all that jazz) and sticks all that in a report you can keep
> around, and use with nofib-analyze later.
>
> But anyway, I agree with Simon that adding a 'bench' build type to
> mk/build.mk.sample is the way to go. For completeness, it's probably
> also worth adding a 'bench-llvm' type for the people who want to
> benchmark with the LLVM backend.*
>
> * We should actually refactor build.mk to not require duplication of
> every build type for these two ways, but I digress enough already.
>
> On Mon, Mar 10, 2014 at 10:54 AM, Simon Marlow <marlowsd at gmail.com> wrote:
> > Add another build type for your use case.  The "quick" build means "build
> > everything as quickly as possible", which is useful for general
> development,
> > but not benchmarking.
> >
> > Cheers,
> > Simon
> >
> >
> > On 08/03/2014 07:45, Johan Tibell wrote:
> >>
> >> Hi,
> >>
> >> In my mind the "quick" build should be like the "perf" build, except
> >> building the stage2 compiler should be much faster. However, the perf
> >> build uses
> >>
> >> GhcLibHcOpts = -O2
> >>
> >> while the quick build uses
> >>
> >> GhcLibHcOpts = -O -fasm
> >>
> >> This means that if you're working on optimizing the generated code and
> >> are running benchmarks to verify your results, the quick build doesn't
> >> do the right thing.
> >>
> >> Since the purpose of the quick build is to work on the stage2 compiler,
> >> would it make sense having it build the libraries in the same way as the
> >> perf build?
> >>
> >> -- Johan
> >>
> >>
> >>
> >> _______________________________________________
> >> ghc-devs mailing list
> >> ghc-devs at haskell.org
> >> http://www.haskell.org/mailman/listinfo/ghc-devs
> >>
> > _______________________________________________
> > ghc-devs mailing list
> > ghc-devs at haskell.org
> > http://www.haskell.org/mailman/listinfo/ghc-devs
> >
>
>
>
> --
> Regards,
>
> Austin Seipp, Haskell Consultant
> Well-Typed LLP, http://www.well-typed.com/
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/ghc-devs/attachments/20140310/4dd3f250/attachment.html>

From slyich at gmail.com  Mon Mar 10 19:58:57 2014
From: slyich at gmail.com (Sergei Trofimovich)
Date: Mon, 10 Mar 2014 22:58:57 +0300
Subject: "quick" vs "perf" builds
In-Reply-To: <CAK-tuPY2h9unyvwpe77EGex_TnohqN_WrpAgR_pAMZCscFSGYQ@mail.gmail.com>
References: <CAK-tuPbo=McKZxADAt=kAYXKqYsyvU7hVncEhnDmuQvEt70LnQ@mail.gmail.com>
 <531DE033.90300@gmail.com>
 <CAEs96n2X-d4ibO34pvRObfOmuScJDmtU+nc84M0UdtpBQSdWNw@mail.gmail.com>
 <CAK-tuPY2h9unyvwpe77EGex_TnohqN_WrpAgR_pAMZCscFSGYQ@mail.gmail.com>
Message-ID: <20140310225857.141b5a8f@sf>

On Mon, 10 Mar 2014 18:59:38 +0100
Johan Tibell <johan.tibell at gmail.com> wrote:

> Added:
> https://github.com/ghc/ghc/commit/ddf79ebf69fe4a6e69d69d451a6040a53b1ea12c

While at it:
> SRC_HC_OPTS        = ... -H64m

Just wondering: that '-H64m' is from some old times (pre 2007?).
GHC seems to eat way more RAM nowadays. Is this bit relevant at all?

-- 

  Sergei
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: not available
URL: <http://www.haskell.org/pipermail/ghc-devs/attachments/20140310/be535d57/attachment.sig>

From kazu at iij.ad.jp  Tue Mar 11 03:32:54 2014
From: kazu at iij.ad.jp (Kazu Yamamoto (=?iso-2022-jp?B?GyRCOzNLXE9CSScbKEI=?=))
Date: Tue, 11 Mar 2014 12:32:54 +0900 (JST)
Subject: Template Haskell of GHC 7.8
Message-ID: <20140311.123254.2213572104099588879.kazu@iij.ad.jp>

Hi,

The tests for doctest are not passed again with GHC 7.8:

----
17) Property.runProperty reports the values for which a property that takes multiple arguments fails
expected: ["False","0","\"\""]
 but got: ["<interactive>:24:66:","    \8216doctest_prop\8217 is not in the type environment at a reify","    In the splice: $(polyQuickCheck 'doctest_prop)"]
----

This comes from:

----src/Property.hs
  where
    quickCheck term vars =
      "let doctest_prop " ++ unwords vars ++ " = " ++ term ++
      " in $(polyQuickCheck 'doctest_prop)"
----

It seems to me that the behavior of GHC 7.8's Template Haskell
changed. Would you tell me how to fix this?

--Kazu

From kazu at iij.ad.jp  Tue Mar 11 06:27:33 2014
From: kazu at iij.ad.jp (Kazu Yamamoto (=?iso-2022-jp?B?GyRCOzNLXE9CSScbKEI=?=))
Date: Tue, 11 Mar 2014 15:27:33 +0900 (JST)
Subject: Template Haskell of GHC 7.8
In-Reply-To: <20140311.123254.2213572104099588879.kazu@iij.ad.jp>
References: <20140311.123254.2213572104099588879.kazu@iij.ad.jp>
Message-ID: <20140311.152733.746526205896169198.kazu@iij.ad.jp>

Hi,

Adam told a solution which uses mkName:

	https://github.com/sol/doctest-haskell/issues/76

Unfortunately, I hit upon another issue of Template Haskell.
I will ask a question in another mail.

--Kazu

> Hi,
> 
> The tests for doctest are not passed again with GHC 7.8:
> 
> ----
> 17) Property.runProperty reports the values for which a property that takes multiple arguments fails
> expected: ["False","0","\"\""]
>  but got: ["<interactive>:24:66:","    \8216doctest_prop\8217 is not in the type environment at a reify","    In the splice: $(polyQuickCheck 'doctest_prop)"]
> ----
> 
> This comes from:
> 
> ----src/Property.hs
>   where
>     quickCheck term vars =
>       "let doctest_prop " ++ unwords vars ++ " = " ++ term ++
>       " in $(polyQuickCheck 'doctest_prop)"
> ----
> 
> It seems to me that the behavior of GHC 7.8's Template Haskell
> changed. Would you tell me how to fix this?
> 
> --Kazu
> _______________________________________________
> ghc-devs mailing list
> ghc-devs at haskell.org
> http://www.haskell.org/mailman/listinfo/ghc-devs

From kazu at iij.ad.jp  Tue Mar 11 06:31:34 2014
From: kazu at iij.ad.jp (Kazu Yamamoto (=?iso-2022-jp?B?GyRCOzNLXE9CSScbKEI=?=))
Date: Tue, 11 Mar 2014 15:31:34 +0900 (JST)
Subject: Template Haskell of GHC 7.8 (again)
Message-ID: <20140311.153134.1259677754934308655.kazu@iij.ad.jp>

Hi,

With the attached file, say Printf.hs, GHCi 7.6.3 works
as follows:

	% ghci Printf.hs 
	[1 of 1] Compiling Printf           ( Printf.hs, interpreted )
	Ok, modules loaded: Printf.
	> :set -XTemplateHaskell
	> putStrLn ( $(pr "Hello") )
	Hello

"Hello" is printed. Good. However, with GHC 7.8, the following error
occurs:

	% ghci Printf.hs 
	[1 of 1] Compiling Printf           ( Printf.hs, interpreted )
	Ok, modules loaded: Printf.
	> :set -XTemplateHaskell
	> putStrLn ( $(pr "Hello") )
	unknown package: main

Is this a bug of Template Haskell of GHC 7.8?

--Kazu
-------------- next part --------------
{-# LANGUAGE TemplateHaskell #-}
--
-- derived from: http://www.haskell.org/ghc/docs/latest/html/users_guide/template-haskell.html#th-example
--
module Printf (pr) where

import Language.Haskell.TH

data Format = D | S | L String

parse :: String -> [Format]
parse s   = [ L s ]

gen :: [Format] -> Q Exp
gen [D]   = [| \n -> show n |]
gen [S]   = [| \s -> s |]
gen [L s] = stringE s

-- |
--
-- >>> :set -XTemplateHaskell
-- >>> putStrLn ( $(pr "Hello") )
-- Hello
pr :: String -> Q Exp
pr s = gen (parse s)

From simonpj at microsoft.com  Tue Mar 11 11:04:33 2014
From: simonpj at microsoft.com (Simon Peyton Jones)
Date: Tue, 11 Mar 2014 11:04:33 +0000
Subject: Template Haskell of GHC 7.8 (again)
In-Reply-To: <20140311.153134.1259677754934308655.kazu@iij.ad.jp>
References: <20140311.153134.1259677754934308655.kazu@iij.ad.jp>
Message-ID: <59543203684B2244980D7E4057D5FBC1487E264C@DB3EX14MBXC306.europe.corp.microsoft.com>

Yes: https://ghc.haskell.org/trac/ghc/ticket/8833
Austin is looking at this for the 7.8 release

Simon

| -----Original Message-----
| From: ghc-devs [mailto:ghc-devs-bounces at haskell.org] On Behalf Of Kazu
| Yamamoto
| Sent: 11 March 2014 06:32
| To: ghc-devs at haskell.org
| Subject: Template Haskell of GHC 7.8 (again)
| 
| Hi,
| 
| With the attached file, say Printf.hs, GHCi 7.6.3 works
| as follows:
| 
| 	% ghci Printf.hs
| 	[1 of 1] Compiling Printf           ( Printf.hs, interpreted )
| 	Ok, modules loaded: Printf.
| 	> :set -XTemplateHaskell
| 	> putStrLn ( $(pr "Hello") )
| 	Hello
| 
| "Hello" is printed. Good. However, with GHC 7.8, the following error
| occurs:
| 
| 	% ghci Printf.hs
| 	[1 of 1] Compiling Printf           ( Printf.hs, interpreted )
| 	Ok, modules loaded: Printf.
| 	> :set -XTemplateHaskell
| 	> putStrLn ( $(pr "Hello") )
| 	unknown package: main
| 
| Is this a bug of Template Haskell of GHC 7.8?
| 
| --Kazu

From kazu at iij.ad.jp  Tue Mar 11 11:58:14 2014
From: kazu at iij.ad.jp (Kazu Yamamoto (=?iso-2022-jp?B?GyRCOzNLXE9CSScbKEI=?=))
Date: Tue, 11 Mar 2014 20:58:14 +0900 (JST)
Subject: Template Haskell of GHC 7.8 (again)
In-Reply-To: <59543203684B2244980D7E4057D5FBC1487E264C@DB3EX14MBXC306.europe.corp.microsoft.com>
References: <20140311.153134.1259677754934308655.kazu@iij.ad.jp>
 <59543203684B2244980D7E4057D5FBC1487E264C@DB3EX14MBXC306.europe.corp.microsoft.com>
Message-ID: <20140311.205814.20249842905382017.kazu@iij.ad.jp>

Hi,

> Yes: https://ghc.haskell.org/trac/ghc/ticket/8833
> Austin is looking at this for the 7.8 release

Thanks. I guess you meant:
	https://ghc.haskell.org/trac/ghc/ticket/8831

--Kazu


From simonpj at microsoft.com  Tue Mar 11 12:59:14 2014
From: simonpj at microsoft.com (Simon Peyton Jones)
Date: Tue, 11 Mar 2014 12:59:14 +0000
Subject: Template Haskell of GHC 7.8 (again)
In-Reply-To: <20140311.205814.20249842905382017.kazu@iij.ad.jp>
References: <20140311.153134.1259677754934308655.kazu@iij.ad.jp>
 <59543203684B2244980D7E4057D5FBC1487E264C@DB3EX14MBXC306.europe.corp.microsoft.com>
 <20140311.205814.20249842905382017.kazu@iij.ad.jp>
Message-ID: <59543203684B2244980D7E4057D5FBC1487E2AFD@DB3EX14MBXC306.europe.corp.microsoft.com>

Bother. Yes, correct.

| -----Original Message-----
| From: Kazu Yamamoto [mailto:kazu at iij.ad.jp]
| Sent: 11 March 2014 11:58
| To: Simon Peyton Jones
| Cc: ghc-devs at haskell.org
| Subject: Re: Template Haskell of GHC 7.8 (again)
| 
| Hi,
| 
| > Yes: https://ghc.haskell.org/trac/ghc/ticket/8833
| > Austin is looking at this for the 7.8 release
| 
| Thanks. I guess you meant:
| 	https://ghc.haskell.org/trac/ghc/ticket/8831
| 
| --Kazu


From simonpj at microsoft.com  Tue Mar 11 15:56:16 2014
From: simonpj at microsoft.com (Simon Peyton Jones)
Date: Tue, 11 Mar 2014 15:56:16 +0000
Subject: Safe Haskell
Message-ID: <59543203684B2244980D7E4057D5FBC1487E329D@DB3EX14MBXC306.europe.corp.microsoft.com>

David
Any views about https://ghc.haskell.org/trac/ghc/ticket/8827?
We propose to remove the recursive check (see the ticket for what that means).
Simon
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/ghc-devs/attachments/20140311/461b6c8b/attachment.html>

From johan.tibell at gmail.com  Tue Mar 11 21:15:16 2014
From: johan.tibell at gmail.com (Johan Tibell)
Date: Tue, 11 Mar 2014 22:15:16 +0100
Subject: Getting warnings when pushing to git.haskell.org
Message-ID: <CAK-tuPYUoiDnBpfazAEsQv14N7tPO6C+TOg55RdGbxR5nL5fTQ@mail.gmail.com>

Hi,

I get the following warning every time I push to git.haskell.org. Anyone
have an idea what the correct fix is?

$ git push origin master
perl: warning: Setting locale failed.
perl: warning: Please check that your locale settings:
LANGUAGE = (unset),
LC_ALL = (unset),
 LC_CTYPE = "UTF-8",
LANG = (unset)
    are supported and installed on your system.
perl: warning: Falling back to the standard locale ("C").
Counting objects: 13, done.
Delta compression using up to 8 threads.
Compressing objects: 100% (7/7), done.
Writing objects: 100% (7/7), 652 bytes | 0 bytes/s, done.
Total 7 (delta 6), reused 0 (delta 0)
remote: performing tab-check...
remote: perl: warning: Setting locale failed.
remote: perl: warning: Please check that your locale settings:
remote: LANGUAGE = (unset),
remote: LC_ALL = (unset),
remote: LC_CTYPE = "UTF-8",
remote: LANG = (unset)
remote:     are supported and installed on your system.
remote: perl: warning: Falling back to the standard locale ("C").
remote: mirroring ssh://git at git.haskell.org/ghc to ssh://
git at github.com/ghc/ghc ...
remote: To ssh://git at github.com/ghc/ghc
remote:    22e4bba..d8b3826  master -> master
remote: running notifier
To ssh://git at git.haskell.org/ghc.git
   22e4bba..d8b3826  master -> master
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/ghc-devs/attachments/20140311/269c0932/attachment.html>

From roma at ro-che.info  Tue Mar 11 21:35:21 2014
From: roma at ro-che.info (Roman Cheplyaka)
Date: Tue, 11 Mar 2014 23:35:21 +0200
Subject: Getting warnings when pushing to git.haskell.org
In-Reply-To: <CAK-tuPYUoiDnBpfazAEsQv14N7tPO6C+TOg55RdGbxR5nL5fTQ@mail.gmail.com>
References: <CAK-tuPYUoiDnBpfazAEsQv14N7tPO6C+TOg55RdGbxR5nL5fTQ@mail.gmail.com>
Message-ID: <20140311213521.GA31237@sniper>

Try setting your locale to something like en_US.UTF-8:

  export LANG=en_US.UTF-8
  unset LC_CTYPE

* Johan Tibell <johan.tibell at gmail.com> [2014-03-11 22:15:16+0100]
> Hi,
> 
> I get the following warning every time I push to git.haskell.org. Anyone
> have an idea what the correct fix is?
> 
> $ git push origin master
> perl: warning: Setting locale failed.
> perl: warning: Please check that your locale settings:
> LANGUAGE = (unset),
> LC_ALL = (unset),
>  LC_CTYPE = "UTF-8",
> LANG = (unset)
>     are supported and installed on your system.
> perl: warning: Falling back to the standard locale ("C").
> Counting objects: 13, done.
> Delta compression using up to 8 threads.
> Compressing objects: 100% (7/7), done.
> Writing objects: 100% (7/7), 652 bytes | 0 bytes/s, done.
> Total 7 (delta 6), reused 0 (delta 0)
> remote: performing tab-check...
> remote: perl: warning: Setting locale failed.
> remote: perl: warning: Please check that your locale settings:
> remote: LANGUAGE = (unset),
> remote: LC_ALL = (unset),
> remote: LC_CTYPE = "UTF-8",
> remote: LANG = (unset)
> remote:     are supported and installed on your system.
> remote: perl: warning: Falling back to the standard locale ("C").
> remote: mirroring ssh://git at git.haskell.org/ghc to ssh://
> git at github.com/ghc/ghc ...
> remote: To ssh://git at github.com/ghc/ghc
> remote:    22e4bba..d8b3826  master -> master
> remote: running notifier
> To ssh://git at git.haskell.org/ghc.git
>    22e4bba..d8b3826  master -> master

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

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: Digital signature
URL: <http://www.haskell.org/pipermail/ghc-devs/attachments/20140311/abd0dff2/attachment.sig>

From p.k.f.holzenspies at utwente.nl  Wed Mar 12 09:35:09 2014
From: p.k.f.holzenspies at utwente.nl (p.k.f.holzenspies at utwente.nl)
Date: Wed, 12 Mar 2014 09:35:09 +0000
Subject: Request: export runTcInteractive from TcRnDriver
In-Reply-To: <59543203684B2244980D7E4057D5FBC148761BD9@DB3EX14MBXC312.europe.corp.microsoft.com>
References: <E7F535B24A47D747A07D46C0AA82D43D1C7AA643@EXMBX21.ad.utwente.nl>
 <59543203684B2244980D7E4057D5FBC148761BD9@DB3EX14MBXC312.europe.corp.microsoft.com>
Message-ID: <E7F535B24A47D747A07D46C0AA82D43D1C7C5618@EXMBX21.ad.utwente.nl>

Dear Simon,

Finally got round to doing this. It's registered as ticket #8878 and the patch is attached. For your consideration.

Regards,
Philip

From: Simon Peyton Jones [mailto:simonpj at microsoft.com]
Sent: dinsdag 4 februari 2014 9:05
To: Holzenspies, P.K.F. (EWI); ghc-devs at haskell.org
Subject: RE: Request: export runTcInteractive from TcRnDriver

No, there's no reason it's not exported, excepting only that it's not currently called outside TcRnDriver.

Go ahead and create a ticket and patch.  It should be exported from GHC.hs (ie the official GHC API), not merely from TcRnDriver.  And I suggest you add a comment with the export from GHC.hs to explain why it's exported.  Otherwise someone might delete it again!

Thx

Simon

From: ghc-devs [mailto:ghc-devs-bounces at haskell.org] On Behalf Of p.k.f.holzenspies at utwente.nl<mailto:p.k.f.holzenspies at utwente.nl>
Sent: 29 January 2014 09:55
To: ghc-devs at haskell.org<mailto:ghc-devs at haskell.org>
Subject: Request: export runTcInteractive from TcRnDriver

Dear GHC-devs,

Is there a reason why, in HEAD, TcRnDriver does *not* export runTcInteractive? If not, can it please be added? (I considered sending a patch with this email, but it's so trivial a change that the check of the patch is more work than manually adding runTcInteractive to the export list.)

I'm developing against the GHC API of 7.6.3 and it would have saved me hours of work to have precisely that function. Seeing it's in HEAD, but not being exported seems a shame ;)

Regards,
Philip

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/ghc-devs/attachments/20140312/c7c9afdb/attachment-0001.html>

From thomas.winant at cs.kuleuven.be  Wed Mar 12 13:35:39 2014
From: thomas.winant at cs.kuleuven.be (Thomas Winant)
Date: Wed, 12 Mar 2014 14:35:39 +0100
Subject: Proposal: Partial Type Signatures
Message-ID: <532062AB.50108@cs.kuleuven.be>

Dear GHC developers,

Together with Tom Schrijvers, Frank Piessens and Dominique Devriese, I
have been working on a proposal for adding *Partial Type Signatures* to
GHC. In a partial type signature, annotated types can be mixed with
inferred types. A type signature is written like before, but can now
contain wildcards, written as underscores. The types of these wildcards
or unknown types will be inferred by the type checker, e.g.

     foo :: _ -> Bool
     foo x = not x
     -- Inferred: Bool -> Boo

The proposal also includes a form of generalisation which aligns with
the existing generalisation that GHC does. We have written down a
motivation (when and how might you use this) and details about the
design and implementation on the following wiki page:

https://ghc.haskell.org/trac/ghc/wiki/PartialTypeSignatures

We have a (work in progress) implementation [1] of the feature based on
GHC. It currently implements most of what we propose, but there are some
remaining important bugs mostly concerning the generalisation. We also
described our design and presented a formalisation based on the
OutsideIn(X) formalism in a paper [2] presented at PADL'14.

What we are hoping to get from the people on this list is any of the
below:
* Read the design, play with the implementation and tell us any comments
   you may have about the feature, its design and implementation.
* Opinions on whether this feature might be acceptable in GHC upstream
   at some point (if not, we do not think it's worth developing the
   implementation much further).
* Perhaps a code review or a discussion with someone more knowledgeable
   about the internals of GHC's type checker about how we might fix the
   remaining problems in our implementation (specifically, we could use
   some help with implementing the generalisation of partial type
   signatures).
* Feedback on the `Questions and issues' section on the wiki page.


Kind regards,
Thomas Winant

[1]: https://github.com/mrBliss/ghc-head/
[2]: https://lirias.kuleuven.be/bitstream/123456789/423475/3/paper.pdf


Disclaimer: http://www.kuleuven.be/cwis/email_disclaimer.htm

From simonpj at microsoft.com  Wed Mar 12 13:40:01 2014
From: simonpj at microsoft.com (Simon Peyton Jones)
Date: Wed, 12 Mar 2014 13:40:01 +0000
Subject: [commit: ghc] master: Call Arity: Resurrect fakeBoringCalls
 (7f919de)
In-Reply-To: <20140312122307.1A8252406B@ghc.haskell.org>
References: <20140312122307.1A8252406B@ghc.haskell.org>
Message-ID: <59543203684B2244980D7E4057D5FBC1487E46A0@DB3EX14MBXC306.europe.corp.microsoft.com>

Could we please have a Note to explain what is going on here?  It clearly isn't obvious, or it would have been right the first time!  

Everyone: practically *whenever* you fix a bug, please add a Note.  By definition something subtle is happening.

Thanks

Simon

| -----Original Message-----
| From: ghc-commits [mailto:ghc-commits-bounces at haskell.org] On Behalf Of
| git at git.haskell.org
| Sent: 12 March 2014 12:23
| To: ghc-commits at haskell.org
| Subject: [commit: ghc] master: Call Arity: Resurrect fakeBoringCalls
| (7f919de)
| 
| Repository : ssh://git at git.haskell.org/ghc
| 
| On branch  : master
| Link       :
| http://ghc.haskell.org/trac/ghc/changeset/7f919dec1579641bbcd02978a0038c8
| a3723d8b7/ghc
| 
| >---------------------------------------------------------------
| 
| commit 7f919dec1579641bbcd02978a0038c8a3723d8b7
| Author: Joachim Breitner <mail at joachim-breitner.de>
| Date:   Wed Mar 12 11:15:16 2014 +0100
| 
|     Call Arity: Resurrect fakeBoringCalls
| 
|     (Otherwise the analysis was wrong, as covered by the new test case.)
| 
| 
| >---------------------------------------------------------------
| 
| 7f919dec1579641bbcd02978a0038c8a3723d8b7
|  compiler/simplCore/CallArity.hs                      |   16
| ++++++++++++++--
|  testsuite/tests/callarity/unittest/CallArity1.hs     |    4 ++++
|  testsuite/tests/callarity/unittest/CallArity1.stderr |    3 +++
|  testsuite/tests/perf/compiler/all.T                  |    3 ++-
|  4 files changed, 23 insertions(+), 3 deletions(-)
| 
| diff --git a/compiler/simplCore/CallArity.hs
| b/compiler/simplCore/CallArity.hs
| index 6334d8d..db0406d 100644
| --- a/compiler/simplCore/CallArity.hs
| +++ b/compiler/simplCore/CallArity.hs
| @@ -348,7 +348,8 @@ callArityTopLvl exported int1 (b:bs)
|      exported' = filter isExportedId int2 ++ exported
|      int' = int1 `addInterestingBinds` b
|      (ae1, bs') = callArityTopLvl exported' int' bs
| -    (ae2, b')  = callArityBind ae1 int1 b
| +    ae1' = fakeBoringCalls int' b ae1
| +    (ae2, b')  = callArityBind ae1' int1 b
| 
| 
|  callArityRHS :: CoreExpr -> CoreExpr
| @@ -434,7 +435,8 @@ callArityAnal arity int (Let bind e)
|    where
|      int_body = int `addInterestingBinds` bind
|      (ae_body, e') = callArityAnal arity int_body e
| -    (final_ae, bind') = callArityBind ae_body int bind
| +    ae_body' = fakeBoringCalls int_body bind ae_body
| +    (final_ae, bind') = callArityBind ae_body' int bind
| 
|  -- This is a variant of callArityAnal that is additionally told whether
|  -- the expression is called once or multiple times, and treats thunks
| appropriately.
| @@ -468,6 +470,16 @@ addInterestingBinds int bind
|      = int `delVarSetList`    bindersOf bind -- Possible shadowing
|            `extendVarSetList` interestingBinds bind
| 
| +-- For every boring variable in the binder, this amends the CallArityRes
| to
| +-- report safe information about them (co-called with everything else,
| arity 0).
| +fakeBoringCalls :: VarSet -> CoreBind -> CallArityRes -> CallArityRes
| +fakeBoringCalls int bind res
| +    = addCrossCoCalls (domRes boring) (domRes res) $ (boring `lubRes`
| res)
| +  where
| +    boring = ( emptyUnVarGraph
| +             ,  mkVarEnv [ (v, 0) | v <- bindersOf bind, not (v
| `elemVarSet` int)])
| +
| +
|  -- Used for both local and top-level binds
|  -- First argument is the demand from the body
|  callArityBind :: CallArityRes -> VarSet -> CoreBind -> (CallArityRes,
| CoreBind)
| diff --git a/testsuite/tests/callarity/unittest/CallArity1.hs
| b/testsuite/tests/callarity/unittest/CallArity1.hs
| index 8a142d5..6dd6182 100644
| --- a/testsuite/tests/callarity/unittest/CallArity1.hs
| +++ b/testsuite/tests/callarity/unittest/CallArity1.hs
| @@ -163,6 +163,10 @@ exprs =
|               , (n, Var go `mkApps` [d `mkLApps` [1]])
|               , (go, mkLams [x] $ mkACase (Var n) (Var go `mkApps` [Var n
| `mkVarApps` [x]]) ) ]) $
|          Var go `mkApps` [mkLit 0, go `mkLApps` [0,1]]
| +  , ("a thunk (non-function-type) co-calls with the body (d 1 would be
| bad)",) $
| +    mkLet d (f `mkLApps` [0]) $
| +        mkLet x (d `mkLApps` [1]) $
| +            Var d `mkVarApps` [x]
|    ]
| 
|  main = do
| diff --git a/testsuite/tests/callarity/unittest/CallArity1.stderr
| b/testsuite/tests/callarity/unittest/CallArity1.stderr
| index d5d7d91..c331a64 100644
| --- a/testsuite/tests/callarity/unittest/CallArity1.stderr
| +++ b/testsuite/tests/callarity/unittest/CallArity1.stderr
| @@ -78,3 +78,6 @@ a thunk (function type), in mutual recursion, still
| calls once, d part of mutual
|      go 1
|      d 1
|      n 0
| +a thunk (non-function-type) co-calls with the body (d 1 would be bad):
| +    x 0
| +    d 0
| diff --git a/testsuite/tests/perf/compiler/all.T
| b/testsuite/tests/perf/compiler/all.T
| index fc0abc9..b03a48f 100644
| --- a/testsuite/tests/perf/compiler/all.T
| +++ b/testsuite/tests/perf/compiler/all.T
| @@ -133,7 +133,7 @@ test('T3294',
|             # 2012-10-08:  1373514844 (x86/Linux)
|             # 2013-11-13: 1478325844  (x86/Windows, 64bit machine)
|             # 2014-01-12: 1565185140  (x86/Linux)
| -           (wordsize(64), 2897630040, 5)]),
| +           (wordsize(64), 2705289664, 5)]),
|              # old:        1357587088 (amd64/Linux)
|              # 29/08/2012: 2961778696 (amd64/Linux)
|              # (^ increase due to new codegen, see #7198)
| @@ -141,6 +141,7 @@ test('T3294',
|              # 08/06/2013: 2901451552 (amd64/Linux) (reason unknown)
|              # 12/12/2013: 3083825616 (amd64/Linux) (reason unknown)
|              # 18/02/2014: 2897630040 (amd64/Linux) (call arity
| improvements)
| +            # 12/03/2014: 2705289664 (amd64/Linux) (more call arity
| improvements)
|        conf_3294
|        ],
|       compile,
| 
| _______________________________________________
| ghc-commits mailing list
| ghc-commits at haskell.org
| http://www.haskell.org/mailman/listinfo/ghc-commits

From simonpj at microsoft.com  Wed Mar 12 15:04:05 2014
From: simonpj at microsoft.com (Simon Peyton Jones)
Date: Wed, 12 Mar 2014 15:04:05 +0000
Subject: GHC 7.8 release
Message-ID: <59543203684B2244980D7E4057D5FBC1487E4EFE@DB3EX14MBXC306.europe.corp.microsoft.com>

Friends
The status of the GHC 7.8 release is here https://ghc.haskell.org/trac/ghc/wiki/Status/GHC-7.8/RC2.
Alas we are currently stalled on #8870, #8834: we are getting seg-faults on Windows.  (For example, on my laptop, the stage2 compiler seg-faults when compiling some (but not all) files.  Although few people develop GHC on Windows, many people *use* GHC on Windows, so we can't really release in this state.
We need help!  Austin is trying, but it's all working on his Windows build.   He's trying to get more machines to see if he can reproduce the failure there.
Does anyone feel able to help?  Even git-bisecting to find the offending commit would be a huge help.  In principle I can do that (at two hours per bisection) but I was defeated by an out-of-sync Haddock.  I need to know how to remove Haddock from the build altogether.  But others are far more skilled than me.
On #8834 Simon M speculates that we may have the callee-saves register wrong on Win64.  Does anyone feel up to looking into that?
Until we find what's going on, 7.8 is stalled.
Thanks!
Simon

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/ghc-devs/attachments/20140312/a37e2f79/attachment.html>

From ekmett at gmail.com  Wed Mar 12 15:09:18 2014
From: ekmett at gmail.com (Edward Kmett)
Date: Wed, 12 Mar 2014 11:09:18 -0400
Subject: Proposal: Partial Type Signatures
In-Reply-To: <532062AB.50108@cs.kuleuven.be>
References: <532062AB.50108@cs.kuleuven.be>
Message-ID: <CAJumaK8P8hvWOnjFcid4HeucsrXiCjAG7RYfLw-H9=rQVyTGug@mail.gmail.com>

Clearly given that term-level holes are called TypeHoles, the extension to
enable these should be called KindHoles. =)

Er.. I'll show myself out.

-Edward


On Wed, Mar 12, 2014 at 9:35 AM, Thomas Winant <thomas.winant at cs.kuleuven.be
> wrote:

> Dear GHC developers,
>
> Together with Tom Schrijvers, Frank Piessens and Dominique Devriese, I
> have been working on a proposal for adding *Partial Type Signatures* to
> GHC. In a partial type signature, annotated types can be mixed with
> inferred types. A type signature is written like before, but can now
> contain wildcards, written as underscores. The types of these wildcards
> or unknown types will be inferred by the type checker, e.g.
>
>     foo :: _ -> Bool
>     foo x = not x
>     -- Inferred: Bool -> Boo
>
> The proposal also includes a form of generalisation which aligns with
> the existing generalisation that GHC does. We have written down a
> motivation (when and how might you use this) and details about the
> design and implementation on the following wiki page:
>
> https://ghc.haskell.org/trac/ghc/wiki/PartialTypeSignatures
>
> We have a (work in progress) implementation [1] of the feature based on
> GHC. It currently implements most of what we propose, but there are some
> remaining important bugs mostly concerning the generalisation. We also
> described our design and presented a formalisation based on the
> OutsideIn(X) formalism in a paper [2] presented at PADL'14.
>
> What we are hoping to get from the people on this list is any of the
> below:
> * Read the design, play with the implementation and tell us any comments
>   you may have about the feature, its design and implementation.
> * Opinions on whether this feature might be acceptable in GHC upstream
>   at some point (if not, we do not think it's worth developing the
>   implementation much further).
> * Perhaps a code review or a discussion with someone more knowledgeable
>   about the internals of GHC's type checker about how we might fix the
>   remaining problems in our implementation (specifically, we could use
>   some help with implementing the generalisation of partial type
>   signatures).
> * Feedback on the `Questions and issues' section on the wiki page.
>
>
> Kind regards,
> Thomas Winant
>
> [1]: https://github.com/mrBliss/ghc-head/
> [2]: https://lirias.kuleuven.be/bitstream/123456789/423475/3/paper.pdf
>
>
> Disclaimer: http://www.kuleuven.be/cwis/email_disclaimer.htm
> _______________________________________________
> ghc-devs mailing list
> ghc-devs at haskell.org
> http://www.haskell.org/mailman/listinfo/ghc-devs
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/ghc-devs/attachments/20140312/959d4b96/attachment-0001.html>

From jan.stolarek at p.lodz.pl  Wed Mar 12 15:29:02 2014
From: jan.stolarek at p.lodz.pl (Jan Stolarek)
Date: Wed, 12 Mar 2014 16:29:02 +0100
Subject: GHC 7.8 release
In-Reply-To: <59543203684B2244980D7E4057D5FBC1487E4EFE@DB3EX14MBXC306.europe.corp.microsoft.com>
References: <59543203684B2244980D7E4057D5FBC1487E4EFE@DB3EX14MBXC306.europe.corp.microsoft.com>
Message-ID: <201403121629.02814.jan.stolarek@p.lodz.pl>

I can provide help on #8834 because I know what was done in the commit that introduced the bug. 
But I don't have Windows so I'm afraid we still need someone to do the actual work.

Janek

Dnia ?roda, 12 marca 2014, Simon Peyton Jones napisa?:
> Friends
> The status of the GHC 7.8 release is here
> https://ghc.haskell.org/trac/ghc/wiki/Status/GHC-7.8/RC2. Alas we are
> currently stalled on #8870, #8834: we are getting seg-faults on Windows. 
> (For example, on my laptop, the stage2 compiler seg-faults when compiling
> some (but not all) files.  Although few people develop GHC on Windows, many
> people *use* GHC on Windows, so we can't really release in this state. We
> need help!  Austin is trying, but it's all working on his Windows build.  
> He's trying to get more machines to see if he can reproduce the failure
> there. Does anyone feel able to help?  Even git-bisecting to find the
> offending commit would be a huge help.  In principle I can do that (at two
> hours per bisection) but I was defeated by an out-of-sync Haddock.  I need
> to know how to remove Haddock from the build altogether.  But others are
> far more skilled than me. On #8834 Simon M speculates that we may have the
> callee-saves register wrong on Win64.  Does anyone feel up to looking into
> that? Until we find what's going on, 7.8 is stalled.
> Thanks!
> Simon



From kyrab at mail.ru  Wed Mar 12 15:35:57 2014
From: kyrab at mail.ru (Kyra)
Date: Wed, 12 Mar 2014 19:35:57 +0400
Subject: GHC 7.8 release
In-Reply-To: <59543203684B2244980D7E4057D5FBC1487E4EFE@DB3EX14MBXC306.europe.corp.microsoft.com>
References: <59543203684B2244980D7E4057D5FBC1487E4EFE@DB3EX14MBXC306.europe.corp.microsoft.com>
Message-ID: <53207EDD.6030000@mail.ru>

On 12.03.2014 19:04, Simon Peyton Jones wrote:
> Alas we are currently stalled on #8870, #8834: we are getting 
> seg-faults on Windows. (For example, on my laptop, the stage2 compiler 
> seg-faults when compiling some (but not all) files. Although few 
> people develop GHC on Windows, many people **use** GHC on Windows, so 
> we can?t really release in this state.
>
> We need help! Austin is trying, but it?s all working on his Windows 
> build. He?s trying to get more machines to see if he can reproduce the 
> failure there.
>
> Does anyone feel able to help? Even git-bisecting to find the 
> offending commit would be a huge help.
>
As I've already wrote in comments to #8834 I can't reproduce #8870 using 
32-bit GHC on 64-bit Windows OS. Both of my machines have only 64-bit 
Windows installed. So no help here, sorry.
>
> On #8834 Simon M speculates that we may have the callee-saves register 
> wrong on Win64. Does anyone feel up to looking into that?
>
After reading Simon M comment I've looked into win64 documentation and 
`includes/stg/MachRegs.h` file. Perhaps, I've missed something, but I've 
seen nothing wrong there, `includes/stg/MachRegs.h` is even a bit too 
conservative regarding windows. I probably could help, but this would 
require a lot of learning of Cmm-related things (I've made reverting 
patch completely mechanically), so I'd want to know that nobody else 
would work on this.

Sorry for strange empty messages from me. Something wrong happened with 
my Thunderbird.

Regards,
Kyra

From metaniklas at gmail.com  Wed Mar 12 15:46:34 2014
From: metaniklas at gmail.com (Niklas Larsson)
Date: Wed, 12 Mar 2014 16:46:34 +0100
Subject: SV: GHC 7.8 release
Message-ID: <5320815f.a83d700a.2576.ffffbfe1@mx.google.com>

I'll try to reproduce it and see if I can pin it down..

Niklas

----- Ursprungligt meddelande -----
Fr?n: "Simon Peyton Jones" <simonpj at microsoft.com>
Skickat: ?2014-?03-?12 16:05
Till: "ghc-devs at haskell.org" <ghc-devs at haskell.org>
?mne: GHC 7.8 release

Friends
The status of the GHC 7.8 release is here https://ghc.haskell.org/trac/ghc/wiki/Status/GHC-7.8/RC2.
Alas we are currently stalled on #8870, #8834: we are getting seg-faults on Windows.  (For example, on my laptop, the stage2 compiler seg-faults when compiling some (but not all) files.  Although few people develop GHC on Windows, many people *use* GHC on Windows, so we can?t really release in this state.
We need help!  Austin is trying, but it?s all working on his Windows build.   He?s trying to get more machines to see if he can reproduce the failure there.
Does anyone feel able to help?  Even git-bisecting to find the offending commit would be a huge help.  In principle I can do that (at two hours per bisection) but I was defeated by an out-of-sync Haddock.  I need to know how to remove Haddock from the build altogether.  But others are far more skilled than me.
On #8834 Simon M speculates that we may have the callee-saves register wrong on Win64.  Does anyone feel up to looking into that?
Until we find what?s going on, 7.8 is stalled.
Thanks!
Simon
 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/ghc-devs/attachments/20140312/01e951d7/attachment.html>

From malcolm.wallace at me.com  Wed Mar 12 18:18:30 2014
From: malcolm.wallace at me.com (Malcolm Wallace)
Date: Wed, 12 Mar 2014 18:18:30 +0000
Subject: Proposal: Partial Type Signatures
In-Reply-To: <CAJumaK8P8hvWOnjFcid4HeucsrXiCjAG7RYfLw-H9=rQVyTGug@mail.gmail.com>
References: <532062AB.50108@cs.kuleuven.be>
 <CAJumaK8P8hvWOnjFcid4HeucsrXiCjAG7RYfLw-H9=rQVyTGug@mail.gmail.com>
Message-ID: <A2DD78C8-8E2A-4F09-8BC2-CEB087BD5DBE@me.com>

Since I never used them, I have honestly been under the impression that the TypeHoles language extension named exactly this partial type signatures thing.  I have loved the idea of underspecifying the type signature, ever since it was first mooted many years ago.  So what does TypeHoles do, if not this?

Regards,
    Malcolm

On 12 Mar 2014, at 15:09, Edward Kmett wrote:

> Clearly given that term-level holes are called TypeHoles, the extension to enable these should be called KindHoles. =)
> 
> Er.. I'll show myself out.
> 
> -Edward
> 
> 
> On Wed, Mar 12, 2014 at 9:35 AM, Thomas Winant <thomas.winant at cs.kuleuven.be> wrote:
> Dear GHC developers,
> 
> Together with Tom Schrijvers, Frank Piessens and Dominique Devriese, I
> have been working on a proposal for adding *Partial Type Signatures* to
> GHC. In a partial type signature, annotated types can be mixed with
> inferred types. A type signature is written like before, but can now
> contain wildcards, written as underscores. The types of these wildcards
> or unknown types will be inferred by the type checker, e.g.
> 
>     foo :: _ -> Bool
>     foo x = not x
>     -- Inferred: Bool -> Boo
> 
> The proposal also includes a form of generalisation which aligns with
> the existing generalisation that GHC does. We have written down a
> motivation (when and how might you use this) and details about the
> design and implementation on the following wiki page:
> 
> https://ghc.haskell.org/trac/ghc/wiki/PartialTypeSignatures
> 
> We have a (work in progress) implementation [1] of the feature based on
> GHC. It currently implements most of what we propose, but there are some
> remaining important bugs mostly concerning the generalisation. We also
> described our design and presented a formalisation based on the
> OutsideIn(X) formalism in a paper [2] presented at PADL'14.
> 
> What we are hoping to get from the people on this list is any of the
> below:
> * Read the design, play with the implementation and tell us any comments
>   you may have about the feature, its design and implementation.
> * Opinions on whether this feature might be acceptable in GHC upstream
>   at some point (if not, we do not think it's worth developing the
>   implementation much further).
> * Perhaps a code review or a discussion with someone more knowledgeable
>   about the internals of GHC's type checker about how we might fix the
>   remaining problems in our implementation (specifically, we could use
>   some help with implementing the generalisation of partial type
>   signatures).
> * Feedback on the `Questions and issues' section on the wiki page.
> 
> 
> Kind regards,
> Thomas Winant
> 
> [1]: https://github.com/mrBliss/ghc-head/
> [2]: https://lirias.kuleuven.be/bitstream/123456789/423475/3/paper.pdf
> 
> 
> Disclaimer: http://www.kuleuven.be/cwis/email_disclaimer.htm
> _______________________________________________
> ghc-devs mailing list
> ghc-devs at haskell.org
> http://www.haskell.org/mailman/listinfo/ghc-devs
> 
> _______________________________________________
> ghc-devs mailing list
> ghc-devs at haskell.org
> http://www.haskell.org/mailman/listinfo/ghc-devs


From simonpj at microsoft.com  Wed Mar 12 18:26:40 2014
From: simonpj at microsoft.com (Simon Peyton Jones)
Date: Wed, 12 Mar 2014 18:26:40 +0000
Subject: FW: [GHC] #4385: Type-level natural numbers
In-Reply-To: <CAGK9nuovCVy9coPiX7RguduqNauxBaHnFmX2=LkFpAR-9MiyWw@mail.gmail.com>
References: <047.cc0a64c6c51b4985aaaaf093ec247386@haskell.org>
 <062.1e25a9d7be9158a4f637bc88aba8d691@haskell.org>
 <59543203684B2244980D7E4057D5FBC1487E365A@DB3EX14MBXC306.europe.corp.microsoft.com>
 <CAGK9nuovCVy9coPiX7RguduqNauxBaHnFmX2=LkFpAR-9MiyWw@mail.gmail.com>
Message-ID: <59543203684B2244980D7E4057D5FBC1487E5401@DB3EX14MBXC306.europe.corp.microsoft.com>

I think a new section on ?Type-level naturals? would make more sense.   That way it?s easier to find, and makes it easier to tell a coherent story

Do it on HEAD; Austin can merge as reqd.

Simon

From: Iavor Diatchki [mailto:iavor.diatchki at gmail.com]
Sent: 12 March 2014 16:26
To: Simon Peyton Jones
Subject: Re: FW: [GHC] #4385: Type-level natural numbers

Hello,

There are some docs under `Promoted Literals`.  I can add a few more paragraphs to capture the current state.  Two questions:

  - Should I add the new stuff in the same place, or should I move everything under a new Section (e.g., `Type-Level Naturals` or something)
  - Is there a special branch for the release candidate, or should I only do it on the `master` branch?

-Iavor


On Tue, Mar 11, 2014 at 1:33 PM, Simon Peyton Jones <simonpj at microsoft.com<mailto:simonpj at microsoft.com>> wrote:
Iavor?

-----Original Message-----
From: ghc-tickets [mailto:ghc-tickets-bounces at haskell.org<mailto:ghc-tickets-bounces at haskell.org>] On Behalf Of GHC
Sent: 11 March 2014 20:12
Cc: ghc-tickets at haskell.org<mailto:ghc-tickets at haskell.org>
Subject: Re: [GHC] #4385: Type-level natural numbers

#4385: Type-level natural numbers
--------------------------------------------+------------------------------
        Reporter:  diatchki                 |            Owner:  diatchki
            Type:  feature request          |           Status:  new
        Priority:  normal                   |        Milestone:  7.6.2
       Component:  Compiler (Type checker)  |          Version:
      Resolution:                           |         Keywords:
Operating System:  Unknown/Multiple         |     Architecture:
 Type of failure:  None/Unknown             |  Unknown/Multiple
       Test Case:                           |       Difficulty:  Unknown
        Blocking:                           |       Blocked By:
                                            |  Related Tickets:
--------------------------------------------+------------------------------

Comment (by Lemming):

 Type-level natural numbers are advertised everywhere for GHC-7.8, but I
 cannot find documentation in
   http://www.haskell.org/ghc/docs/7.8.1-rc2/html/users_guide/

--
Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/4385#comment:66>
GHC <http://www.haskell.org/ghc/>
The Glasgow Haskell Compiler
_______________________________________________
ghc-tickets mailing list
ghc-tickets at haskell.org<mailto:ghc-tickets at haskell.org>
http://www.haskell.org/mailman/listinfo/ghc-tickets

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/ghc-devs/attachments/20140312/746b0791/attachment-0001.html>

From simonpj at microsoft.com  Wed Mar 12 18:34:36 2014
From: simonpj at microsoft.com (Simon Peyton Jones)
Date: Wed, 12 Mar 2014 18:34:36 +0000
Subject: Proposal: Partial Type Signatures
In-Reply-To: <A2DD78C8-8E2A-4F09-8BC2-CEB087BD5DBE@me.com>
References: <532062AB.50108@cs.kuleuven.be>
 <CAJumaK8P8hvWOnjFcid4HeucsrXiCjAG7RYfLw-H9=rQVyTGug@mail.gmail.com>
 <A2DD78C8-8E2A-4F09-8BC2-CEB087BD5DBE@me.com>
Message-ID: <59543203684B2244980D7E4057D5FBC1487E5513@DB3EX14MBXC306.europe.corp.microsoft.com>

http://www.haskell.org/haskellwiki/GHC/TypeHoles

| -----Original Message-----
| From: ghc-devs [mailto:ghc-devs-bounces at haskell.org] On Behalf Of Malcolm
| Wallace
| Sent: 12 March 2014 18:19
| To: ghc-devs
| Subject: Re: Proposal: Partial Type Signatures
| 
| Since I never used them, I have honestly been under the impression that
| the TypeHoles language extension named exactly this partial type
| signatures thing.  I have loved the idea of underspecifying the type
| signature, ever since it was first mooted many years ago.  So what does
| TypeHoles do, if not this?
| 
| Regards,
|     Malcolm
| 
| On 12 Mar 2014, at 15:09, Edward Kmett wrote:
| 
| > Clearly given that term-level holes are called TypeHoles, the extension
| to enable these should be called KindHoles. =)
| >
| > Er.. I'll show myself out.
| >
| > -Edward
| >
| >
| > On Wed, Mar 12, 2014 at 9:35 AM, Thomas Winant
| <thomas.winant at cs.kuleuven.be> wrote:
| > Dear GHC developers,
| >
| > Together with Tom Schrijvers, Frank Piessens and Dominique Devriese, I
| > have been working on a proposal for adding *Partial Type Signatures* to
| > GHC. In a partial type signature, annotated types can be mixed with
| > inferred types. A type signature is written like before, but can now
| > contain wildcards, written as underscores. The types of these wildcards
| > or unknown types will be inferred by the type checker, e.g.
| >
| >     foo :: _ -> Bool
| >     foo x = not x
| >     -- Inferred: Bool -> Boo
| >
| > The proposal also includes a form of generalisation which aligns with
| > the existing generalisation that GHC does. We have written down a
| > motivation (when and how might you use this) and details about the
| > design and implementation on the following wiki page:
| >
| > https://ghc.haskell.org/trac/ghc/wiki/PartialTypeSignatures
| >
| > We have a (work in progress) implementation [1] of the feature based on
| > GHC. It currently implements most of what we propose, but there are
| some
| > remaining important bugs mostly concerning the generalisation. We also
| > described our design and presented a formalisation based on the
| > OutsideIn(X) formalism in a paper [2] presented at PADL'14.
| >
| > What we are hoping to get from the people on this list is any of the
| > below:
| > * Read the design, play with the implementation and tell us any
| comments
| >   you may have about the feature, its design and implementation.
| > * Opinions on whether this feature might be acceptable in GHC upstream
| >   at some point (if not, we do not think it's worth developing the
| >   implementation much further).
| > * Perhaps a code review or a discussion with someone more knowledgeable
| >   about the internals of GHC's type checker about how we might fix the
| >   remaining problems in our implementation (specifically, we could use
| >   some help with implementing the generalisation of partial type
| >   signatures).
| > * Feedback on the `Questions and issues' section on the wiki page.
| >
| >
| > Kind regards,
| > Thomas Winant
| >
| > [1]: https://github.com/mrBliss/ghc-head/
| > [2]: https://lirias.kuleuven.be/bitstream/123456789/423475/3/paper.pdf
| >
| >
| > Disclaimer: http://www.kuleuven.be/cwis/email_disclaimer.htm
| > _______________________________________________
| > ghc-devs mailing list
| > ghc-devs at haskell.org
| > http://www.haskell.org/mailman/listinfo/ghc-devs
| >
| > _______________________________________________
| > ghc-devs mailing list
| > ghc-devs at haskell.org
| > http://www.haskell.org/mailman/listinfo/ghc-devs
| 
| _______________________________________________
| ghc-devs mailing list
| ghc-devs at haskell.org
| http://www.haskell.org/mailman/listinfo/ghc-devs

From mail at joachim-breitner.de  Wed Mar 12 18:36:16 2014
From: mail at joachim-breitner.de (Joachim Breitner)
Date: Wed, 12 Mar 2014 19:36:16 +0100
Subject: Extending fold/build fusion
In-Reply-To: <CAOGQyFt1RnFX_pv8a=SX9FTQvXqRLGF2-tN38m-3kDt=r++c-Q@mail.gmail.com>
References: <CAOGQyFsnEsvS47+PaMSZvWkPOPsjYfmbuC6Bfm02r-VX6t6-Dw@mail.gmail.com>
 <1390932396.2641.46.camel@kirk>
 <CAOGQyFup3pZ_H_9f148WK5-LucpfSCe0XPg=PgYxDdR4Q0aOLw@mail.gmail.com>
 <1391159897.3184.10.camel@kirk>
 <CAOGQyFsFxRQY--KVpZBJOgY3ZHxwb3Oxgk5T=03Ofj8FPBi4wg@mail.gmail.com>
 <1392029440.7172.2.camel@kirk>
 <CAOGQyFt1RnFX_pv8a=SX9FTQvXqRLGF2-tN38m-3kDt=r++c-Q@mail.gmail.com>
Message-ID: <1394649376.12060.12.camel@kirk>

Dear Akio,

Am Dienstag, den 11.02.2014, 08:04 +0900 schrieb Akio Takano:
> I modified the base library to use foldrW/buildW, with no changes to
> foldl yet. nofib showed a very big regression in cryptarithm2, so I'm
> looking into it.

any news on this front? Did you find out what happened in cryptarithm2?
Do you need help with that?

I?m currently writing a paper on the Call Arity analysis and tried to
summarize your suggestion in the ?Related Work? section. Is there any
citable document describing your variant of fusion, besides the github
page?

Greetings,
Joachim

-- 
Joachim ?nomeata? Breitner
  mail at joachim-breitner.de ? http://www.joachim-breitner.de/
  Jabber: nomeata at joachim-breitner.de  ? GPG-Key: 0x4743206C
  Debian Developer: nomeata at debian.org
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 181 bytes
Desc: This is a digitally signed message part
URL: <http://www.haskell.org/pipermail/ghc-devs/attachments/20140312/143ae2d8/attachment.sig>

From ggreif at gmail.com  Wed Mar 12 18:51:24 2014
From: ggreif at gmail.com (Gabor Greif)
Date: Wed, 12 Mar 2014 19:51:24 +0100
Subject: Proposal: Partial Type Signatures
In-Reply-To: <532062AB.50108@cs.kuleuven.be>
References: <532062AB.50108@cs.kuleuven.be>
Message-ID: <CAK-hX0n+fnAs8PpbGruYiCqcPDWhyAVTDSemm2qQPutR0ZA+xQ@mail.gmail.com>

Hi all,

this proposal looks very interesting. When writing functions that
consume/produce values of proper GADT type, signatures are mandatory.
So just spelling out the GADTs and leaving the rest to type inference
looks like a clear win.

I can only second the in-development-no-signatures argument. Many
types are in flux, but the fundamentals can be stated with partial
signatures. This also reduces the embarrassment when one goes with a
fixed signature just to discover later that there would have been a
much more general form of it, simply inferrable.

Cheers,

    Gabor

From simonpj at microsoft.com  Wed Mar 12 18:52:09 2014
From: simonpj at microsoft.com (Simon Peyton Jones)
Date: Wed, 12 Mar 2014 18:52:09 +0000
Subject: GHC 7.8 release
In-Reply-To: <53207EDD.6030000@mail.ru>
References: <59543203684B2244980D7E4057D5FBC1487E4EFE@DB3EX14MBXC306.europe.corp.microsoft.com>
 <53207EDD.6030000@mail.ru>
Message-ID: <59543203684B2244980D7E4057D5FBC1487E56C0@DB3EX14MBXC306.europe.corp.microsoft.com>


| conservative regarding windows. I probably could help, but this would
| require a lot of learning of Cmm-related things (I've made reverting
| patch completely mechanically), so I'd want to know that nobody else
| would work on this.

Just trying to reproduce the crash, and then git-bisecting to the fault, would be a huge step forward.  I don't think you'd need to know Cmm necessarily

Simon

| -----Original Message-----
| From: ghc-devs [mailto:ghc-devs-bounces at haskell.org] On Behalf Of Kyra
| Sent: 12 March 2014 15:36
| To: ghc-devs at haskell.org
| Subject: Re: GHC 7.8 release
| 
| On 12.03.2014 19:04, Simon Peyton Jones wrote:
| > Alas we are currently stalled on #8870, #8834: we are getting
| > seg-faults on Windows. (For example, on my laptop, the stage2 compiler
| > seg-faults when compiling some (but not all) files. Although few
| > people develop GHC on Windows, many people **use** GHC on Windows, so
| > we can't really release in this state.
| >
| > We need help! Austin is trying, but it's all working on his Windows
| > build. He's trying to get more machines to see if he can reproduce the
| > failure there.
| >
| > Does anyone feel able to help? Even git-bisecting to find the
| > offending commit would be a huge help.
| >
| As I've already wrote in comments to #8834 I can't reproduce #8870 using
| 32-bit GHC on 64-bit Windows OS. Both of my machines have only 64-bit
| Windows installed. So no help here, sorry.
| >
| > On #8834 Simon M speculates that we may have the callee-saves register
| > wrong on Win64. Does anyone feel up to looking into that?
| >
| After reading Simon M comment I've looked into win64 documentation and
| `includes/stg/MachRegs.h` file. Perhaps, I've missed something, but I've
| seen nothing wrong there, `includes/stg/MachRegs.h` is even a bit too
| conservative regarding windows. I probably could help, but this would
| require a lot of learning of Cmm-related things (I've made reverting
| patch completely mechanically), so I'd want to know that nobody else
| would work on this.
| 
| Sorry for strange empty messages from me. Something wrong happened with
| my Thunderbird.
| 
| Regards,
| Kyra
| _______________________________________________
| ghc-devs mailing list
| ghc-devs at haskell.org
| http://www.haskell.org/mailman/listinfo/ghc-devs

From ggreif at gmail.com  Wed Mar 12 18:55:00 2014
From: ggreif at gmail.com (Gabor Greif)
Date: Wed, 12 Mar 2014 19:55:00 +0100
Subject: Proposal: Partial Type Signatures
In-Reply-To: <59543203684B2244980D7E4057D5FBC1487E5513@DB3EX14MBXC306.europe.corp.microsoft.com>
References: <532062AB.50108@cs.kuleuven.be>
 <CAJumaK8P8hvWOnjFcid4HeucsrXiCjAG7RYfLw-H9=rQVyTGug@mail.gmail.com>
 <A2DD78C8-8E2A-4F09-8BC2-CEB087BD5DBE@me.com>
 <59543203684B2244980D7E4057D5FBC1487E5513@DB3EX14MBXC306.europe.corp.microsoft.com>
Message-ID: <CAK-hX0keV-CeO2kSx158Z0s+23_p3eL6oK1dw3+7vBe0GbJ3AA@mail.gmail.com>

Just a reminder that the new jargon is TypedHoles, so maybe the page
should be renamed to reflect that (an possibly combed for the old
spelling).

Cheers,

    Gabor

On 3/12/14, Simon Peyton Jones <simonpj at microsoft.com> wrote:
> http://www.haskell.org/haskellwiki/GHC/TypeHoles
>
> | -----Original Message-----
> | From: ghc-devs [mailto:ghc-devs-bounces at haskell.org] On Behalf Of Malcolm
> | Wallace
> | Sent: 12 March 2014 18:19
> | To: ghc-devs
> | Subject: Re: Proposal: Partial Type Signatures
> |
> | Since I never used them, I have honestly been under the impression that
> | the TypeHoles language extension named exactly this partial type
> | signatures thing.  I have loved the idea of underspecifying the type
> | signature, ever since it was first mooted many years ago.  So what does
> | TypeHoles do, if not this?
> |
> | Regards,
> |     Malcolm
> |
> | On 12 Mar 2014, at 15:09, Edward Kmett wrote:
> |
> | > Clearly given that term-level holes are called TypeHoles, the extension
> | to enable these should be called KindHoles. =)
> | >
> | > Er.. I'll show myself out.
> | >
> | > -Edward
> | >
> | >
> | > On Wed, Mar 12, 2014 at 9:35 AM, Thomas Winant
> | <thomas.winant at cs.kuleuven.be> wrote:
> | > Dear GHC developers,
> | >
> | > Together with Tom Schrijvers, Frank Piessens and Dominique Devriese, I
> | > have been working on a proposal for adding *Partial Type Signatures* to
> | > GHC. In a partial type signature, annotated types can be mixed with
> | > inferred types. A type signature is written like before, but can now
> | > contain wildcards, written as underscores. The types of these wildcards
> | > or unknown types will be inferred by the type checker, e.g.
> | >
> | >     foo :: _ -> Bool
> | >     foo x = not x
> | >     -- Inferred: Bool -> Boo
> | >
> | > The proposal also includes a form of generalisation which aligns with
> | > the existing generalisation that GHC does. We have written down a
> | > motivation (when and how might you use this) and details about the
> | > design and implementation on the following wiki page:
> | >
> | > https://ghc.haskell.org/trac/ghc/wiki/PartialTypeSignatures
> | >
> | > We have a (work in progress) implementation [1] of the feature based on
> | > GHC. It currently implements most of what we propose, but there are
> | some
> | > remaining important bugs mostly concerning the generalisation. We also
> | > described our design and presented a formalisation based on the
> | > OutsideIn(X) formalism in a paper [2] presented at PADL'14.
> | >
> | > What we are hoping to get from the people on this list is any of the
> | > below:
> | > * Read the design, play with the implementation and tell us any
> | comments
> | >   you may have about the feature, its design and implementation.
> | > * Opinions on whether this feature might be acceptable in GHC upstream
> | >   at some point (if not, we do not think it's worth developing the
> | >   implementation much further).
> | > * Perhaps a code review or a discussion with someone more knowledgeable
> | >   about the internals of GHC's type checker about how we might fix the
> | >   remaining problems in our implementation (specifically, we could use
> | >   some help with implementing the generalisation of partial type
> | >   signatures).
> | > * Feedback on the `Questions and issues' section on the wiki page.
> | >
> | >
> | > Kind regards,
> | > Thomas Winant
> | >
> | > [1]: https://github.com/mrBliss/ghc-head/
> | > [2]: https://lirias.kuleuven.be/bitstream/123456789/423475/3/paper.pdf
> | >
> | >
> | > Disclaimer: http://www.kuleuven.be/cwis/email_disclaimer.htm
> | > _______________________________________________
> | > ghc-devs mailing list
> | > ghc-devs at haskell.org
> | > http://www.haskell.org/mailman/listinfo/ghc-devs
> | >
> | > _______________________________________________
> | > ghc-devs mailing list
> | > ghc-devs at haskell.org
> | > http://www.haskell.org/mailman/listinfo/ghc-devs
> |
> | _______________________________________________
> | ghc-devs mailing list
> | ghc-devs at haskell.org
> | http://www.haskell.org/mailman/listinfo/ghc-devs
> _______________________________________________
> ghc-devs mailing list
> ghc-devs at haskell.org
> http://www.haskell.org/mailman/listinfo/ghc-devs
>

From austin at well-typed.com  Wed Mar 12 19:09:13 2014
From: austin at well-typed.com (Austin Seipp)
Date: Wed, 12 Mar 2014 14:09:13 -0500
Subject: Proposal: Partial Type Signatures
In-Reply-To: <CAK-hX0keV-CeO2kSx158Z0s+23_p3eL6oK1dw3+7vBe0GbJ3AA@mail.gmail.com>
References: <532062AB.50108@cs.kuleuven.be>
 <CAJumaK8P8hvWOnjFcid4HeucsrXiCjAG7RYfLw-H9=rQVyTGug@mail.gmail.com>
 <A2DD78C8-8E2A-4F09-8BC2-CEB087BD5DBE@me.com>
 <59543203684B2244980D7E4057D5FBC1487E5513@DB3EX14MBXC306.europe.corp.microsoft.com>
 <CAK-hX0keV-CeO2kSx158Z0s+23_p3eL6oK1dw3+7vBe0GbJ3AA@mail.gmail.com>
Message-ID: <CAEs96n2FyvRLQ0TcXb_wDbc7bmAnz3mNNo8O1oDDkmsTGjCj3w@mail.gmail.com>

That page should be reworked a bit - for one, typed holes are actually
no longer an extension. They are a warning which is on by default,
controlled by -f[no-]warn-typed-holes[1][2][3]. This IMO does improve
their utility after using it a bit, because they never allow a program
to typecheck - they only change the results of the errors you get.

In any case, I believe the original formulation of Holes by Thijs
actually somewhat overlapped with the idea presented here. In
particular, it would have allowed us to say[4]:

f :: Bool -> _ ()
f = ...

where _ is a 'hole' in the signature, and the type-checker would try
to report some kind of type constructors that might fit based on the
definition. But this was never implemented, and the design was more in
the style of Agda-goals: they were meant to help you write out the
types, not avoid them through inference.

In any case - I too am receptive to the idea of partial type
signatures, so I'd like to see this. (And if we could make it
optionally work with the ideas proposed by Thijs, that would be great,
so we can actually have 'holes' at the type level, like at the term
level. But Simon has some good points in [4] worth reading on that
note.)

[1] http://www.haskell.org/ghc/docs/7.8.1-rc2/html/users_guide/typed-holes.html
[2] http://www.haskell.org/pipermail/ghc-devs/2014-January/003758.html
[3] https://github.com/ghc/ghc/commit/235fd88a9a35a6ca1aed70ff71291d7b433e45e4
[4] https://ghc.haskell.org/trac/ghc/wiki/Holes

On Wed, Mar 12, 2014 at 1:55 PM, Gabor Greif <ggreif at gmail.com> wrote:
> Just a reminder that the new jargon is TypedHoles, so maybe the page
> should be renamed to reflect that (an possibly combed for the old
> spelling).
>
> Cheers,
>
>     Gabor
>
> On 3/12/14, Simon Peyton Jones <simonpj at microsoft.com> wrote:
>> http://www.haskell.org/haskellwiki/GHC/TypeHoles
>>
>> | -----Original Message-----
>> | From: ghc-devs [mailto:ghc-devs-bounces at haskell.org] On Behalf Of Malcolm
>> | Wallace
>> | Sent: 12 March 2014 18:19
>> | To: ghc-devs
>> | Subject: Re: Proposal: Partial Type Signatures
>> |
>> | Since I never used them, I have honestly been under the impression that
>> | the TypeHoles language extension named exactly this partial type
>> | signatures thing.  I have loved the idea of underspecifying the type
>> | signature, ever since it was first mooted many years ago.  So what does
>> | TypeHoles do, if not this?
>> |
>> | Regards,
>> |     Malcolm
>> |
>> | On 12 Mar 2014, at 15:09, Edward Kmett wrote:
>> |
>> | > Clearly given that term-level holes are called TypeHoles, the extension
>> | to enable these should be called KindHoles. =)
>> | >
>> | > Er.. I'll show myself out.
>> | >
>> | > -Edward
>> | >
>> | >
>> | > On Wed, Mar 12, 2014 at 9:35 AM, Thomas Winant
>> | <thomas.winant at cs.kuleuven.be> wrote:
>> | > Dear GHC developers,
>> | >
>> | > Together with Tom Schrijvers, Frank Piessens and Dominique Devriese, I
>> | > have been working on a proposal for adding *Partial Type Signatures* to
>> | > GHC. In a partial type signature, annotated types can be mixed with
>> | > inferred types. A type signature is written like before, but can now
>> | > contain wildcards, written as underscores. The types of these wildcards
>> | > or unknown types will be inferred by the type checker, e.g.
>> | >
>> | >     foo :: _ -> Bool
>> | >     foo x = not x
>> | >     -- Inferred: Bool -> Boo
>> | >
>> | > The proposal also includes a form of generalisation which aligns with
>> | > the existing generalisation that GHC does. We have written down a
>> | > motivation (when and how might you use this) and details about the
>> | > design and implementation on the following wiki page:
>> | >
>> | > https://ghc.haskell.org/trac/ghc/wiki/PartialTypeSignatures
>> | >
>> | > We have a (work in progress) implementation [1] of the feature based on
>> | > GHC. It currently implements most of what we propose, but there are
>> | some
>> | > remaining important bugs mostly concerning the generalisation. We also
>> | > described our design and presented a formalisation based on the
>> | > OutsideIn(X) formalism in a paper [2] presented at PADL'14.
>> | >
>> | > What we are hoping to get from the people on this list is any of the
>> | > below:
>> | > * Read the design, play with the implementation and tell us any
>> | comments
>> | >   you may have about the feature, its design and implementation.
>> | > * Opinions on whether this feature might be acceptable in GHC upstream
>> | >   at some point (if not, we do not think it's worth developing the
>> | >   implementation much further).
>> | > * Perhaps a code review or a discussion with someone more knowledgeable
>> | >   about the internals of GHC's type checker about how we might fix the
>> | >   remaining problems in our implementation (specifically, we could use
>> | >   some help with implementing the generalisation of partial type
>> | >   signatures).
>> | > * Feedback on the `Questions and issues' section on the wiki page.
>> | >
>> | >
>> | > Kind regards,
>> | > Thomas Winant
>> | >
>> | > [1]: https://github.com/mrBliss/ghc-head/
>> | > [2]: https://lirias.kuleuven.be/bitstream/123456789/423475/3/paper.pdf
>> | >
>> | >
>> | > Disclaimer: http://www.kuleuven.be/cwis/email_disclaimer.htm
>> | > _______________________________________________
>> | > ghc-devs mailing list
>> | > ghc-devs at haskell.org
>> | > http://www.haskell.org/mailman/listinfo/ghc-devs
>> | >
>> | > _______________________________________________
>> | > ghc-devs mailing list
>> | > ghc-devs at haskell.org
>> | > http://www.haskell.org/mailman/listinfo/ghc-devs
>> |
>> | _______________________________________________
>> | ghc-devs mailing list
>> | ghc-devs at haskell.org
>> | http://www.haskell.org/mailman/listinfo/ghc-devs
>> _______________________________________________
>> ghc-devs mailing list
>> ghc-devs at haskell.org
>> http://www.haskell.org/mailman/listinfo/ghc-devs
>>
> _______________________________________________
> ghc-devs mailing list
> ghc-devs at haskell.org
> http://www.haskell.org/mailman/listinfo/ghc-devs
>



-- 
Regards,

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

From simonpj at microsoft.com  Wed Mar 12 19:18:51 2014
From: simonpj at microsoft.com (Simon Peyton Jones)
Date: Wed, 12 Mar 2014 19:18:51 +0000
Subject: Proposal: Partial Type Signatures
In-Reply-To: <CAK-hX0keV-CeO2kSx158Z0s+23_p3eL6oK1dw3+7vBe0GbJ3AA@mail.gmail.com>
References: <532062AB.50108@cs.kuleuven.be>
 <CAJumaK8P8hvWOnjFcid4HeucsrXiCjAG7RYfLw-H9=rQVyTGug@mail.gmail.com>
 <A2DD78C8-8E2A-4F09-8BC2-CEB087BD5DBE@me.com>
 <59543203684B2244980D7E4057D5FBC1487E5513@DB3EX14MBXC306.europe.corp.microsoft.com>
 <CAK-hX0keV-CeO2kSx158Z0s+23_p3eL6oK1dw3+7vBe0GbJ3AA@mail.gmail.com>
Message-ID: <59543203684B2244980D7E4057D5FBC1487E5784@DB3EX14MBXC306.europe.corp.microsoft.com>

Indeed, you are right.  It's a wiki, so do go ahead.

Simon

| -----Original Message-----
| From: Gabor Greif [mailto:ggreif at gmail.com]
| Sent: 12 March 2014 18:55
| To: Simon Peyton Jones
| Cc: Malcolm Wallace; ghc-devs
| Subject: Re: Proposal: Partial Type Signatures
| 
| Just a reminder that the new jargon is TypedHoles, so maybe the page
| should be renamed to reflect that (an possibly combed for the old
| spelling).
| 
| Cheers,
| 
|     Gabor
| 
| On 3/12/14, Simon Peyton Jones <simonpj at microsoft.com> wrote:
| > http://www.haskell.org/haskellwiki/GHC/TypeHoles
| >
| > | -----Original Message-----
| > | From: ghc-devs [mailto:ghc-devs-bounces at haskell.org] On Behalf Of
| Malcolm
| > | Wallace
| > | Sent: 12 March 2014 18:19
| > | To: ghc-devs
| > | Subject: Re: Proposal: Partial Type Signatures
| > |
| > | Since I never used them, I have honestly been under the impression
| that
| > | the TypeHoles language extension named exactly this partial type
| > | signatures thing.  I have loved the idea of underspecifying the type
| > | signature, ever since it was first mooted many years ago.  So what
| does
| > | TypeHoles do, if not this?
| > |
| > | Regards,
| > |     Malcolm
| > |
| > | On 12 Mar 2014, at 15:09, Edward Kmett wrote:
| > |
| > | > Clearly given that term-level holes are called TypeHoles, the
| extension
| > | to enable these should be called KindHoles. =)
| > | >
| > | > Er.. I'll show myself out.
| > | >
| > | > -Edward
| > | >
| > | >
| > | > On Wed, Mar 12, 2014 at 9:35 AM, Thomas Winant
| > | <thomas.winant at cs.kuleuven.be> wrote:
| > | > Dear GHC developers,
| > | >
| > | > Together with Tom Schrijvers, Frank Piessens and Dominique
| Devriese, I
| > | > have been working on a proposal for adding *Partial Type
| Signatures* to
| > | > GHC. In a partial type signature, annotated types can be mixed with
| > | > inferred types. A type signature is written like before, but can
| now
| > | > contain wildcards, written as underscores. The types of these
| wildcards
| > | > or unknown types will be inferred by the type checker, e.g.
| > | >
| > | >     foo :: _ -> Bool
| > | >     foo x = not x
| > | >     -- Inferred: Bool -> Boo
| > | >
| > | > The proposal also includes a form of generalisation which aligns
| with
| > | > the existing generalisation that GHC does. We have written down a
| > | > motivation (when and how might you use this) and details about the
| > | > design and implementation on the following wiki page:
| > | >
| > | > https://ghc.haskell.org/trac/ghc/wiki/PartialTypeSignatures
| > | >
| > | > We have a (work in progress) implementation [1] of the feature
| based on
| > | > GHC. It currently implements most of what we propose, but there are
| > | some
| > | > remaining important bugs mostly concerning the generalisation. We
| also
| > | > described our design and presented a formalisation based on the
| > | > OutsideIn(X) formalism in a paper [2] presented at PADL'14.
| > | >
| > | > What we are hoping to get from the people on this list is any of
| the
| > | > below:
| > | > * Read the design, play with the implementation and tell us any
| > | comments
| > | >   you may have about the feature, its design and implementation.
| > | > * Opinions on whether this feature might be acceptable in GHC
| upstream
| > | >   at some point (if not, we do not think it's worth developing the
| > | >   implementation much further).
| > | > * Perhaps a code review or a discussion with someone more
| knowledgeable
| > | >   about the internals of GHC's type checker about how we might fix
| the
| > | >   remaining problems in our implementation (specifically, we could
| use
| > | >   some help with implementing the generalisation of partial type
| > | >   signatures).
| > | > * Feedback on the `Questions and issues' section on the wiki page.
| > | >
| > | >
| > | > Kind regards,
| > | > Thomas Winant
| > | >
| > | > [1]: https://github.com/mrBliss/ghc-head/
| > | > [2]:
| https://lirias.kuleuven.be/bitstream/123456789/423475/3/paper.pdf
| > | >
| > | >
| > | > Disclaimer: http://www.kuleuven.be/cwis/email_disclaimer.htm
| > | > _______________________________________________
| > | > ghc-devs mailing list
| > | > ghc-devs at haskell.org
| > | > http://www.haskell.org/mailman/listinfo/ghc-devs
| > | >
| > | > _______________________________________________
| > | > ghc-devs mailing list
| > | > ghc-devs at haskell.org
| > | > http://www.haskell.org/mailman/listinfo/ghc-devs
| > |
| > | _______________________________________________
| > | ghc-devs mailing list
| > | ghc-devs at haskell.org
| > | http://www.haskell.org/mailman/listinfo/ghc-devs
| > _______________________________________________
| > ghc-devs mailing list
| > ghc-devs at haskell.org
| > http://www.haskell.org/mailman/listinfo/ghc-devs
| >

From novadenizen at gmail.com  Wed Mar 12 19:21:35 2014
From: novadenizen at gmail.com (Ken Bateman)
Date: Wed, 12 Mar 2014 15:21:35 -0400
Subject: GHC Trac registration failed
Message-ID: <CACsFjbxsnpwaLcB44e+6k9aGf5h2xnD-KvVZnzkuNwy4KOev3A@mail.gmail.com>

I tried to register at https://ghc.haskell.org/trac/ghc/register but I
never received a verification email.  I've checked my spam folder.

Could somebody help me out?  The account name is novadenizen, and it's
attached to this gmail address.

-Ken
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/ghc-devs/attachments/20140312/82105efd/attachment.html>

From difrumin at gmail.com  Wed Mar 12 20:35:47 2014
From: difrumin at gmail.com (Dan Frumin)
Date: Thu, 13 Mar 2014 00:35:47 +0400
Subject: Proposal: Partial Type Signatures
In-Reply-To: <A2DD78C8-8E2A-4F09-8BC2-CEB087BD5DBE@me.com>
References: <532062AB.50108@cs.kuleuven.be>
 <CAJumaK8P8hvWOnjFcid4HeucsrXiCjAG7RYfLw-H9=rQVyTGug@mail.gmail.com>
 <A2DD78C8-8E2A-4F09-8BC2-CEB087BD5DBE@me.com>
 <A2DD78C8-8E2A-4F09-8BC2-CEB087BD5DBE@me.com>
Message-ID: <etPan.5320c523.327b23c6.171bf@aquabox.local>

Aha!, that is exactly why TypeHoles were renamed to TypedHoles :)

In the TypedHoles extension underscores are used on the term level.




On March 12, 2014 at 10:18:40 PM, Malcolm Wallace (malcolm.wallace at me.com) wrote:

Since I never used them, I have honestly been under the impression that the TypeHoles language extension named exactly this partial type signatures thing. I have loved the idea of underspecifying the type signature, ever since it was first mooted many years ago. So what does TypeHoles do, if not this? 

Regards, 
Malcolm 

On 12 Mar 2014, at 15:09, Edward Kmett wrote: 

> Clearly given that term-level holes are called TypeHoles, the extension to enable these should be called KindHoles. =) 
> 
> Er.. I'll show myself out. 
> 
> -Edward 
> 
> 
> On Wed, Mar 12, 2014 at 9:35 AM, Thomas Winant <thomas.winant at cs.kuleuven.be> wrote: 
> Dear GHC developers, 
> 
> Together with Tom Schrijvers, Frank Piessens and Dominique Devriese, I 
> have been working on a proposal for adding *Partial Type Signatures* to 
> GHC. In a partial type signature, annotated types can be mixed with 
> inferred types. A type signature is written like before, but can now 
> contain wildcards, written as underscores. The types of these wildcards 
> or unknown types will be inferred by the type checker, e.g. 
> 
> foo :: _ -> Bool 
> foo x = not x 
> -- Inferred: Bool -> Boo 
> 
> The proposal also includes a form of generalisation which aligns with 
> the existing generalisation that GHC does. We have written down a 
> motivation (when and how might you use this) and details about the 
> design and implementation on the following wiki page: 
> 
> https://ghc.haskell.org/trac/ghc/wiki/PartialTypeSignatures 
> 
> We have a (work in progress) implementation [1] of the feature based on 
> GHC. It currently implements most of what we propose, but there are some 
> remaining important bugs mostly concerning the generalisation. We also 
> described our design and presented a formalisation based on the 
> OutsideIn(X) formalism in a paper [2] presented at PADL'14. 
> 
> What we are hoping to get from the people on this list is any of the 
> below: 
> * Read the design, play with the implementation and tell us any comments 
> you may have about the feature, its design and implementation. 
> * Opinions on whether this feature might be acceptable in GHC upstream 
> at some point (if not, we do not think it's worth developing the 
> implementation much further). 
> * Perhaps a code review or a discussion with someone more knowledgeable 
> about the internals of GHC's type checker about how we might fix the 
> remaining problems in our implementation (specifically, we could use 
> some help with implementing the generalisation of partial type 
> signatures). 
> * Feedback on the `Questions and issues' section on the wiki page. 
> 
> 
> Kind regards, 
> Thomas Winant 
> 
> [1]: https://github.com/mrBliss/ghc-head/ 
> [2]: https://lirias.kuleuven.be/bitstream/123456789/423475/3/paper.pdf 
> 
> 
> Disclaimer: http://www.kuleuven.be/cwis/email_disclaimer.htm 
> _______________________________________________ 
> ghc-devs mailing list 
> ghc-devs at haskell.org 
> http://www.haskell.org/mailman/listinfo/ghc-devs 
> 
> _______________________________________________ 
> ghc-devs mailing list 
> ghc-devs at haskell.org 
> http://www.haskell.org/mailman/listinfo/ghc-devs 

_______________________________________________ 
ghc-devs mailing list 
ghc-devs at haskell.org 
http://www.haskell.org/mailman/listinfo/ghc-devs 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/ghc-devs/attachments/20140313/0cb34498/attachment.html>

From ggreif at gmail.com  Wed Mar 12 21:14:06 2014
From: ggreif at gmail.com (Gabor Greif)
Date: Wed, 12 Mar 2014 22:14:06 +0100
Subject: Proposal: Partial Type Signatures
In-Reply-To: <59543203684B2244980D7E4057D5FBC1487E5784@DB3EX14MBXC306.europe.corp.microsoft.com>
References: <532062AB.50108@cs.kuleuven.be>
 <CAJumaK8P8hvWOnjFcid4HeucsrXiCjAG7RYfLw-H9=rQVyTGug@mail.gmail.com>
 <A2DD78C8-8E2A-4F09-8BC2-CEB087BD5DBE@me.com>
 <59543203684B2244980D7E4057D5FBC1487E5513@DB3EX14MBXC306.europe.corp.microsoft.com>
 <CAK-hX0keV-CeO2kSx158Z0s+23_p3eL6oK1dw3+7vBe0GbJ3AA@mail.gmail.com>
 <59543203684B2244980D7E4057D5FBC1487E5784@DB3EX14MBXC306.europe.corp.microsoft.com>
Message-ID: <CAK-hX0mFz_Co+M0HzV94zNGXNU4YcLwhFpEEUfD-RNwFThE81Q@mail.gmail.com>

Yeah, done.

Cheers,

    Gabor

On 3/12/14, Simon Peyton Jones <simonpj at microsoft.com> wrote:
> Indeed, you are right.  It's a wiki, so do go ahead.
>
> Simon
>
> | -----Original Message-----
> | From: Gabor Greif [mailto:ggreif at gmail.com]
> | Sent: 12 March 2014 18:55
> | To: Simon Peyton Jones
> | Cc: Malcolm Wallace; ghc-devs
> | Subject: Re: Proposal: Partial Type Signatures
> |
> | Just a reminder that the new jargon is TypedHoles, so maybe the page
> | should be renamed to reflect that (an possibly combed for the old
> | spelling).
> |
> | Cheers,
> |
> |     Gabor
> |
> | On 3/12/14, Simon Peyton Jones <simonpj at microsoft.com> wrote:
> | > http://www.haskell.org/haskellwiki/GHC/TypeHoles
> | >
> | > | -----Original Message-----
> | > | From: ghc-devs [mailto:ghc-devs-bounces at haskell.org] On Behalf Of
> | Malcolm
> | > | Wallace
> | > | Sent: 12 March 2014 18:19
> | > | To: ghc-devs
> | > | Subject: Re: Proposal: Partial Type Signatures
> | > |
> | > | Since I never used them, I have honestly been under the impression
> | that
> | > | the TypeHoles language extension named exactly this partial type
> | > | signatures thing.  I have loved the idea of underspecifying the type
> | > | signature, ever since it was first mooted many years ago.  So what
> | does
> | > | TypeHoles do, if not this?
> | > |
> | > | Regards,
> | > |     Malcolm
> | > |
> | > | On 12 Mar 2014, at 15:09, Edward Kmett wrote:
> | > |
> | > | > Clearly given that term-level holes are called TypeHoles, the
> | extension
> | > | to enable these should be called KindHoles. =)
> | > | >
> | > | > Er.. I'll show myself out.
> | > | >
> | > | > -Edward
> | > | >
> | > | >
> | > | > On Wed, Mar 12, 2014 at 9:35 AM, Thomas Winant
> | > | <thomas.winant at cs.kuleuven.be> wrote:
> | > | > Dear GHC developers,
> | > | >
> | > | > Together with Tom Schrijvers, Frank Piessens and Dominique
> | Devriese, I
> | > | > have been working on a proposal for adding *Partial Type
> | Signatures* to
> | > | > GHC. In a partial type signature, annotated types can be mixed with
> | > | > inferred types. A type signature is written like before, but can
> | now
> | > | > contain wildcards, written as underscores. The types of these
> | wildcards
> | > | > or unknown types will be inferred by the type checker, e.g.
> | > | >
> | > | >     foo :: _ -> Bool
> | > | >     foo x = not x
> | > | >     -- Inferred: Bool -> Boo
> | > | >
> | > | > The proposal also includes a form of generalisation which aligns
> | with
> | > | > the existing generalisation that GHC does. We have written down a
> | > | > motivation (when and how might you use this) and details about the
> | > | > design and implementation on the following wiki page:
> | > | >
> | > | > https://ghc.haskell.org/trac/ghc/wiki/PartialTypeSignatures
> | > | >
> | > | > We have a (work in progress) implementation [1] of the feature
> | based on
> | > | > GHC. It currently implements most of what we propose, but there are
> | > | some
> | > | > remaining important bugs mostly concerning the generalisation. We
> | also
> | > | > described our design and presented a formalisation based on the
> | > | > OutsideIn(X) formalism in a paper [2] presented at PADL'14.
> | > | >
> | > | > What we are hoping to get from the people on this list is any of
> | the
> | > | > below:
> | > | > * Read the design, play with the implementation and tell us any
> | > | comments
> | > | >   you may have about the feature, its design and implementation.
> | > | > * Opinions on whether this feature might be acceptable in GHC
> | upstream
> | > | >   at some point (if not, we do not think it's worth developing the
> | > | >   implementation much further).
> | > | > * Perhaps a code review or a discussion with someone more
> | knowledgeable
> | > | >   about the internals of GHC's type checker about how we might fix
> | the
> | > | >   remaining problems in our implementation (specifically, we could
> | use
> | > | >   some help with implementing the generalisation of partial type
> | > | >   signatures).
> | > | > * Feedback on the `Questions and issues' section on the wiki page.
> | > | >
> | > | >
> | > | > Kind regards,
> | > | > Thomas Winant
> | > | >
> | > | > [1]: https://github.com/mrBliss/ghc-head/
> | > | > [2]:
> | https://lirias.kuleuven.be/bitstream/123456789/423475/3/paper.pdf
> | > | >
> | > | >
> | > | > Disclaimer: http://www.kuleuven.be/cwis/email_disclaimer.htm
> | > | > _______________________________________________
> | > | > ghc-devs mailing list
> | > | > ghc-devs at haskell.org
> | > | > http://www.haskell.org/mailman/listinfo/ghc-devs
> | > | >
> | > | > _______________________________________________
> | > | > ghc-devs mailing list
> | > | > ghc-devs at haskell.org
> | > | > http://www.haskell.org/mailman/listinfo/ghc-devs
> | > |
> | > | _______________________________________________
> | > | ghc-devs mailing list
> | > | ghc-devs at haskell.org
> | > | http://www.haskell.org/mailman/listinfo/ghc-devs
> | > _______________________________________________
> | > ghc-devs mailing list
> | > ghc-devs at haskell.org
> | > http://www.haskell.org/mailman/listinfo/ghc-devs
> | >
>

From tkn.akio at gmail.com  Wed Mar 12 23:56:59 2014
From: tkn.akio at gmail.com (Akio Takano)
Date: Thu, 13 Mar 2014 08:56:59 +0900
Subject: Extending fold/build fusion
In-Reply-To: <1394649376.12060.12.camel@kirk>
References: <CAOGQyFsnEsvS47+PaMSZvWkPOPsjYfmbuC6Bfm02r-VX6t6-Dw@mail.gmail.com>
 <1390932396.2641.46.camel@kirk>
 <CAOGQyFup3pZ_H_9f148WK5-LucpfSCe0XPg=PgYxDdR4Q0aOLw@mail.gmail.com>
 <1391159897.3184.10.camel@kirk>
 <CAOGQyFsFxRQY--KVpZBJOgY3ZHxwb3Oxgk5T=03Ofj8FPBi4wg@mail.gmail.com>
 <1392029440.7172.2.camel@kirk>
 <CAOGQyFt1RnFX_pv8a=SX9FTQvXqRLGF2-tN38m-3kDt=r++c-Q@mail.gmail.com>
 <1394649376.12060.12.camel@kirk>
Message-ID: <CAOGQyFtOQd2XrgdhnbrU-xFXS1u5MVnRvDPtHObnLjNsGJCBeQ@mail.gmail.com>

On Thu, Mar 13, 2014 at 3:36 AM, Joachim Breitner
<mail at joachim-breitner.de> wrote:
> Dear Akio,
>
> Am Dienstag, den 11.02.2014, 08:04 +0900 schrieb Akio Takano:
>> I modified the base library to use foldrW/buildW, with no changes to
>> foldl yet. nofib showed a very big regression in cryptarithm2, so I'm
>> looking into it.
>
> any news on this front? Did you find out what happened in cryptarithm2?
> Do you need help with that?

I haven't found what happened in cryptarithm2. Maybe I'll look at it
in this weekend.

>
> I'm currently writing a paper on the Call Arity analysis and tried to
> summarize your suggestion in the "Related Work" section. Is there any
> citable document describing your variant of fusion, besides the github
> page?

No, unfortunately not.

-- Akio

>
> Greetings,
> Joachim
>
> --
> Joachim "nomeata" Breitner
>   mail at joachim-breitner.de * http://www.joachim-breitner.de/
>   Jabber: nomeata at joachim-breitner.de  * GPG-Key: 0x4743206C
>   Debian Developer: nomeata at debian.org

From fuuzetsu at fuuzetsu.co.uk  Thu Mar 13 02:29:04 2014
From: fuuzetsu at fuuzetsu.co.uk (Mateusz Kowalczyk)
Date: Thu, 13 Mar 2014 02:29:04 +0000
Subject: GHC 7.8 release
In-Reply-To: <59543203684B2244980D7E4057D5FBC1487E4EFE@DB3EX14MBXC306.europe.corp.microsoft.com>
References: <59543203684B2244980D7E4057D5FBC1487E4EFE@DB3EX14MBXC306.europe.corp.microsoft.com>
Message-ID: <532117F0.8090909@fuuzetsu.co.uk>

On 12/03/14 15:04, Simon Peyton Jones wrote:
> Friends
> The status of the GHC 7.8 release is here https://ghc.haskell.org/trac/ghc/wiki/Status/GHC-7.8/RC2.
> Alas we are currently stalled on #8870, #8834: we are getting seg-faults on Windows.  (For example, on my laptop, the stage2 compiler seg-faults when compiling some (but not all) files.  Although few people develop GHC on Windows, many people *use* GHC on Windows, so we can't really release in this state.
> We need help!  Austin is trying, but it's all working on his Windows build.   He's trying to get more machines to see if he can reproduce the failure there.
> Does anyone feel able to help?  Even git-bisecting to find the offending commit would be a huge help.  In principle I can do that (at two hours per bisection) but I was defeated by an out-of-sync Haddock.  I need to know how to remove Haddock from the build altogether.  But others are far more skilled than me.

Assuming Haddock is not the thing causing the problems here, I think it
wouldn't be unreasonable to simply replace all contents of the Haddock
directory with some dummy Main file, ask GHC to not build with docs and
to not run any of the Haddock tests.

This will only work if GHC doesn't use any of the exposed Haddock API of
course.

I believe I heard someone in #ghc say that Haddock is not a proper
submodule of the repository (why isn't it?) so that's probably why it's
going out of sync. We even have a long outstanding bug on Haddock Trac
because we have no idea how to sanely bisect Haddock and GHC together to
find the change!

> On #8834 Simon M speculates that we may have the callee-saves register wrong on Win64.  Does anyone feel up to looking into that?
> Until we find what's going on, 7.8 is stalled.
> Thanks!
> Simon
> 
> 
> 
> 
> _______________________________________________
> ghc-devs mailing list
> ghc-devs at haskell.org
> http://www.haskell.org/mailman/listinfo/ghc-devs
> 


-- 
Mateusz K.

From johan.tibell at gmail.com  Thu Mar 13 09:03:55 2014
From: johan.tibell at gmail.com (Johan Tibell)
Date: Thu, 13 Mar 2014 10:03:55 +0100
Subject: Can't build HEAD on OS X
Message-ID: <CAK-tuPbgFFqXpiXfjfUOtV5O6r0xG9-_EJXxy=jNQ6j17v5F8g@mail.gmail.com>

Checking out a clean tree today (commit: ) I can no longer build HEAD.
Here's what I did:

git clone git://git.haskell.org/ghc.git
cd ghc
./sync-all --no-dph get
cp mk/build.mk.sample mk/build.mk
# Uncomment devel2 in mk/build.mk
./boot && ./configure --with-gcc=/usr/local/bin/gcc-4.9
make

Here's the result:

gcc -E  -m64 -DPROFILING -DTHREADED_RTS -DDEBUG -Irts/dist/build  -m64
-fno-stack-protector  -Wall -Wextra -Wstrict-prototypes
 -Wmissing-prototypes  -Wmissing-declarations -Winline -Waggregate-return
-Wpointer-arith -Wmissing-noreturn -Wnested-externs -Wredundant-decls
 -Iincludes -Iincludes/dist -Iincludes/dist-derivedconstants/header
-Iincludes/dist-ghcconstants/header -Irts -Irts/dist/build -DCOMPILING_RTS
-fno-strict-aliasing -fno-common -DDTRACE        -O2 -fomit-frame-pointer
-DRtsWay=\"rts_v\" -Wno-strict-prototypes    -Wno-inline
-finline-limit=2500 -MM -x c rts/sm/Compact.c -MF
rts/dist/build/.depend-v-dyn-l-debug-thr-thr_debug-thr_l-debug_dyn-thr_dyn-thr_debug_dyn-l_dyn-thr_l_dyn.c_asm.bit
clang: error: unknown argument: '-finline-limit=2500'
[-Wunused-command-line-argument-hard-error-in-future]
clang: note: this will be a hard error (cannot be downgraded to a warning)
in the future
make[1]: ***
[rts/dist/build/.depend-v-dyn-l-debug-thr-thr_debug-thr_l-debug_dyn-thr_dyn-thr_debug_dyn-l_dyn-thr_l_dyn.c_asm]
Error 1

More context:
sed -e 's|\\|/|g' -e 's| /$| \\|' -e "1s|\.o|\.o|" -e "1s|^|rts/sm/|" -e
"1s|rts/|rts/dist/build/|" -e "1s|dist/build/dist/build|dist/build|g" -e
"s|/Users/tibbe/src/ghc/||g"
rts/dist/build/.depend-v-dyn-l-debug-thr-thr_debug-thr_l-debug_dyn-thr_dyn-thr_debug_dyn-l_dyn-thr_l_dyn.c_asm.bit
>>
rts/dist/build/.depend-v-dyn-l-debug-thr-thr_debug-thr_l-debug_dyn-thr_dyn-thr_debug_dyn-l_dyn-thr_l_dyn.c_asm.tmp
&& sed -e 's|\\|/|g' -e 's| /$| \\|' -e "1s|\.o|\.dyn_o|" -e
"1s|^|rts/sm/|" -e "1s|rts/|rts/dist/build/|" -e
"1s|dist/build/dist/build|dist/build|g" -e "s|/Users/tibbe/src/ghc/||g"
rts/dist/build/.depend-v-dyn-l-debug-thr-thr_debug-thr_l-debug_dyn-thr_dyn-thr_debug_dyn-l_dyn-thr_l_dyn.c_asm.bit
>>
rts/dist/build/.depend-v-dyn-l-debug-thr-thr_debug-thr_l-debug_dyn-thr_dyn-thr_debug_dyn-l_dyn-thr_l_dyn.c_asm.tmp
&& sed -e 's|\\|/|g' -e 's| /$| \\|' -e "1s|\.o|\.l_o|" -e "1s|^|rts/sm/|"
-e "1s|rts/|rts/dist/build/|" -e "1s|dist/build/dist/build|dist/build|g" -e
"s|/Users/tibbe/src/ghc/||g"
rts/dist/build/.depend-v-dyn-l-debug-thr-thr_debug-thr_l-debug_dyn-thr_dyn-thr_debug_dyn-l_dyn-thr_l_dyn.c_asm.bit
>>
rts/dist/build/.depend-v-dyn-l-debug-thr-thr_debug-thr_l-debug_dyn-thr_dyn-thr_debug_dyn-l_dyn-thr_l_dyn.c_asm.tmp
&& sed -e 's|\\|/|g' -e 's| /$| \\|' -e "1s|\.o|\.debug_o|" -e
"1s|^|rts/sm/|" -e "1s|rts/|rts/dist/build/|" -e
"1s|dist/build/dist/build|dist/build|g" -e "s|/Users/tibbe/src/ghc/||g"
rts/dist/build/.depend-v-dyn-l-debug-thr-thr_debug-thr_l-debug_dyn-thr_dyn-thr_debug_dyn-l_dyn-thr_l_dyn.c_asm.bit
>>
rts/dist/build/.depend-v-dyn-l-debug-thr-thr_debug-thr_l-debug_dyn-thr_dyn-thr_debug_dyn-l_dyn-thr_l_dyn.c_asm.tmp
&& sed -e 's|\\|/|g' -e 's| /$| \\|' -e "1s|\.o|\.thr_o|" -e
"1s|^|rts/sm/|" -e "1s|rts/|rts/dist/build/|" -e
"1s|dist/build/dist/build|dist/build|g" -e "s|/Users/tibbe/src/ghc/||g"
rts/dist/build/.depend-v-dyn-l-debug-thr-thr_debug-thr_l-debug_dyn-thr_dyn-thr_debug_dyn-l_dyn-thr_l_dyn.c_asm.bit
>>
rts/dist/build/.depend-v-dyn-l-debug-thr-thr_debug-thr_l-debug_dyn-thr_dyn-thr_debug_dyn-l_dyn-thr_l_dyn.c_asm.tmp
&& sed -e 's|\\|/|g' -e 's| /$| \\|' -e "1s|\.o|\.thr_debug_o|" -e
"1s|^|rts/sm/|" -e "1s|rts/|rts/dist/build/|" -e
"1s|dist/build/dist/build|dist/build|g" -e "s|/Users/tibbe/src/ghc/||g"
rts/dist/build/.depend-v-dyn-l-debug-thr-thr_debug-thr_l-debug_dyn-thr_dyn-thr_debug_dyn-l_dyn-thr_l_dyn.c_asm.bit
>>
rts/dist/build/.depend-v-dyn-l-debug-thr-thr_debug-thr_l-debug_dyn-thr_dyn-thr_debug_dyn-l_dyn-thr_l_dyn.c_asm.tmp
&& sed -e 's|\\|/|g' -e 's| /$| \\|' -e "1s|\.o|\.thr_l_o|" -e
"1s|^|rts/sm/|" -e "1s|rts/|rts/dist/build/|" -e
"1s|dist/build/dist/build|dist/build|g" -e "s|/Users/tibbe/src/ghc/||g"
rts/dist/build/.depend-v-dyn-l-debug-thr-thr_debug-thr_l-debug_dyn-thr_dyn-thr_debug_dyn-l_dyn-thr_l_dyn.c_asm.bit
>>
rts/dist/build/.depend-v-dyn-l-debug-thr-thr_debug-thr_l-debug_dyn-thr_dyn-thr_debug_dyn-l_dyn-thr_l_dyn.c_asm.tmp
&& sed -e 's|\\|/|g' -e 's| /$| \\|' -e "1s|\.o|\.debug_dyn_o|" -e
"1s|^|rts/sm/|" -e "1s|rts/|rts/dist/build/|" -e
"1s|dist/build/dist/build|dist/build|g" -e "s|/Users/tibbe/src/ghc/||g"
rts/dist/build/.depend-v-dyn-l-debug-thr-thr_debug-thr_l-debug_dyn-thr_dyn-thr_debug_dyn-l_dyn-thr_l_dyn.c_asm.bit
>>
rts/dist/build/.depend-v-dyn-l-debug-thr-thr_debug-thr_l-debug_dyn-thr_dyn-thr_debug_dyn-l_dyn-thr_l_dyn.c_asm.tmp
&& sed -e 's|\\|/|g' -e 's| /$| \\|' -e "1s|\.o|\.thr_dyn_o|" -e
"1s|^|rts/sm/|" -e "1s|rts/|rts/dist/build/|" -e
"1s|dist/build/dist/build|dist/build|g" -e "s|/Users/tibbe/src/ghc/||g"
rts/dist/build/.depend-v-dyn-l-debug-thr-thr_debug-thr_l-debug_dyn-thr_dyn-thr_debug_dyn-l_dyn-thr_l_dyn.c_asm.bit
>>
rts/dist/build/.depend-v-dyn-l-debug-thr-thr_debug-thr_l-debug_dyn-thr_dyn-thr_debug_dyn-l_dyn-thr_l_dyn.c_asm.tmp
&& sed -e 's|\\|/|g' -e 's| /$| \\|' -e "1s|\.o|\.thr_debug_dyn_o|" -e
"1s|^|rts/sm/|" -e "1s|rts/|rts/dist/build/|" -e
"1s|dist/build/dist/build|dist/build|g" -e "s|/Users/tibbe/src/ghc/||g"
rts/dist/build/.depend-v-dyn-l-debug-thr-thr_debug-thr_l-debug_dyn-thr_dyn-thr_debug_dyn-l_dyn-thr_l_dyn.c_asm.bit
>>
rts/dist/build/.depend-v-dyn-l-debug-thr-thr_debug-thr_l-debug_dyn-thr_dyn-thr_debug_dyn-l_dyn-thr_l_dyn.c_asm.tmp
&& sed -e 's|\\|/|g' -e 's| /$| \\|' -e "1s|\.o|\.l_dyn_o|" -e
"1s|^|rts/sm/|" -e "1s|rts/|rts/dist/build/|" -e
"1s|dist/build/dist/build|dist/build|g" -e "s|/Users/tibbe/src/ghc/||g"
rts/dist/build/.depend-v-dyn-l-debug-thr-thr_debug-thr_l-debug_dyn-thr_dyn-thr_debug_dyn-l_dyn-thr_l_dyn.c_asm.bit
>>
rts/dist/build/.depend-v-dyn-l-debug-thr-thr_debug-thr_l-debug_dyn-thr_dyn-thr_debug_dyn-l_dyn-thr_l_dyn.c_asm.tmp
&& sed -e 's|\\|/|g' -e 's| /$| \\|' -e "1s|\.o|\.thr_l_dyn_o|" -e
"1s|^|rts/sm/|" -e "1s|rts/|rts/dist/build/|" -e
"1s|dist/build/dist/build|dist/build|g" -e "s|/Users/tibbe/src/ghc/||g"
rts/dist/build/.depend-v-dyn-l-debug-thr-thr_debug-thr_l-debug_dyn-thr_dyn-thr_debug_dyn-l_dyn-thr_l_dyn.c_asm.bit
>>
rts/dist/build/.depend-v-dyn-l-debug-thr-thr_debug-thr_l-debug_dyn-thr_dyn-thr_debug_dyn-l_dyn-thr_l_dyn.c_asm.tmp
&& true
gcc -E  -m64 -DPROFILING -DTHREADED_RTS -DDEBUG -Irts/dist/build  -m64
-fno-stack-protector  -Wall -Wextra -Wstrict-prototypes
 -Wmissing-prototypes  -Wmissing-declarations -Winline -Waggregate-return
-Wpointer-arith -Wmissing-noreturn -Wnested-externs -Wredundant-decls
 -Iincludes -Iincludes/dist -Iincludes/dist-derivedconstants/header
-Iincludes/dist-ghcconstants/header -Irts -Irts/dist/build -DCOMPILING_RTS
-fno-strict-aliasing -fno-common -DDTRACE        -O2 -fomit-frame-pointer
-DRtsWay=\"rts_v\" -Wno-strict-prototypes    -Wno-inline
-finline-limit=2500 -MM -x c rts/sm/Compact.c -MF
rts/dist/build/.depend-v-dyn-l-debug-thr-thr_debug-thr_l-debug_dyn-thr_dyn-thr_debug_dyn-l_dyn-thr_l_dyn.c_asm.bit
clang: error: unknown argument: '-finline-limit=2500'
[-Wunused-command-line-argument-hard-error-in-future]
clang: note: this will be a hard error (cannot be downgraded to a warning)
in the future
make[1]: ***
[rts/dist/build/.depend-v-dyn-l-debug-thr-thr_debug-thr_l-debug_dyn-thr_dyn-thr_debug_dyn-l_dyn-thr_l_dyn.c_asm]
Error 1
make: *** [all] Error 2

-- Johan
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/ghc-devs/attachments/20140313/4668be8e/attachment.html>

From jan.stolarek at p.lodz.pl  Thu Mar 13 09:18:48 2014
From: jan.stolarek at p.lodz.pl (Jan Stolarek)
Date: Thu, 13 Mar 2014 10:18:48 +0100
Subject: Building GHC on Windows
Message-ID: <201403131018.48375.jan.stolarek@p.lodz.pl>

I'm trying to build GHC on 64-bit Windows 7. I installed Cygwin, GHC and cloned the main repo but 
when I run configure I get this error:

configure: Building in-tree ghc-pwd
checking for path to top of build tree... cygwin warning:
  MS-DOS style path detected: C:/cygwin64/home/tewi/head
  Preferred POSIX equivalent is: /home/tewi/head
  CYGWIN environment variable option "nodosfilewarning" turns off this warning.
  Consult the user's guide for more details about POSIX paths:
    http://cygwin.com/cygwin-ug-net/using.html#using-pathnames
C:/cygwin64/home/tewi/head
checking for gcc... C:/cygwin64/home/tewi/head/inplace/mingw/bin/gcc.exe
checking whether the C compiler works... no
configure: error: in `/home/tewi/head':
configure: error: C compiler cannot create executables
See `config.log' for more details

I have gcc installed under Cygwin, but for some reason ./configure is looking for an in-tree 
compiler. I tried passing --with-gcc=/usr/bin/gcc to configure but with no result. Help?

Janek


From fw at deneb.enyo.de  Thu Mar 13 09:32:04 2014
From: fw at deneb.enyo.de (Florian Weimer)
Date: Thu, 13 Mar 2014 10:32:04 +0100
Subject: [PATCH] sync-all: Skip END actions on exceptions
Message-ID: <87pplq8mwb.fsf@mid.deneb.enyo.de>

The instructions at <https://ghc.haskell.org/trac/ghc/wiki/Newcomers>
were slightly outdated, and result in a rather confusing error
messsage:

$ ./sync-all --testsuite get
Unrecognised flag: --testsuite at ./sync-all line 872.
== Checking for old haddock repo
== Checking for old binary repo
== Checking for old mtl repo
== Checking for old Cabal repo
== Checking for old time from tarball
============================
ATTENTION!

You have an old time package in your GHC tree!

Please remove it (e.g. "rm -r libraries/time"), and then run
"./sync-all get" to get the new repository.
============================
== Checking for obsolete Git repo URL
$

The patch corrects the error message.  I've removed the --testsuite
flag from the wiki page as well.

-------------- next part --------------
A non-text attachment was scrubbed...
Name: 0001-sync-all-Skip-END-actions-on-exceptions.patch
Type: text/x-diff
Size: 1180 bytes
Desc: not available
URL: <http://www.haskell.org/pipermail/ghc-devs/attachments/20140313/289a8f8e/attachment-0001.patch>

From johan.tibell at gmail.com  Thu Mar 13 09:45:16 2014
From: johan.tibell at gmail.com (Johan Tibell)
Date: Thu, 13 Mar 2014 10:45:16 +0100
Subject: Can't build HEAD on OS X
In-Reply-To: <CAK-tuPbgFFqXpiXfjfUOtV5O6r0xG9-_EJXxy=jNQ6j17v5F8g@mail.gmail.com>
References: <CAK-tuPbgFFqXpiXfjfUOtV5O6r0xG9-_EJXxy=jNQ6j17v5F8g@mail.gmail.com>
Message-ID: <CAK-tuPb37QmM_JKccbNx6wqoDEtCZKJ=Ffu+RyMPmwGiknvGDQ@mail.gmail.com>

I've unblocked myself with this change:

diff --git a/rts/ghc.mk b/rts/ghc.mk
index 3929adb..b96df3d 100644
--- a/rts/ghc.mk
+++ b/rts/ghc.mk
@@ -427,7 +427,7 @@ rts/win32/ThrIOManager_CC_OPTS += -w

 # Without this, thread_obj will not be inlined (at least on x86 with GCC
4.1.0)
 ifneq "$(CC_CLANG_BACKEND)" "1"
-rts/sm/Compact_CC_OPTS += -finline-limit=2500
+# rts/sm/Compact_CC_OPTS += -finline-limit=2500
 endif

 # -O3 helps unroll some loops (especially in copy() with a constant
argument).

That #ifneq check doesn't work because 1) gcc is not clang (I used
/usr/local/bin/gcc-4.9) but 2) the cpp that actually gets called during the
build is 'gcc -E', which is clang.


On Thu, Mar 13, 2014 at 10:03 AM, Johan Tibell <johan.tibell at gmail.com>wrote:

> Checking out a clean tree today (commit: ) I can no longer build HEAD.
> Here's what I did:
>
> git clone git://git.haskell.org/ghc.git
> cd ghc
> ./sync-all --no-dph get
> cp mk/build.mk.sample mk/build.mk
> # Uncomment devel2 in mk/build.mk
> ./boot && ./configure --with-gcc=/usr/local/bin/gcc-4.9
> make
>
> Here's the result:
>
> gcc -E  -m64 -DPROFILING -DTHREADED_RTS -DDEBUG -Irts/dist/build  -m64
> -fno-stack-protector  -Wall -Wextra -Wstrict-prototypes
>  -Wmissing-prototypes  -Wmissing-declarations -Winline -Waggregate-return
> -Wpointer-arith -Wmissing-noreturn -Wnested-externs -Wredundant-decls
>  -Iincludes -Iincludes/dist -Iincludes/dist-derivedconstants/header
> -Iincludes/dist-ghcconstants/header -Irts -Irts/dist/build -DCOMPILING_RTS
> -fno-strict-aliasing -fno-common -DDTRACE        -O2 -fomit-frame-pointer
> -DRtsWay=\"rts_v\" -Wno-strict-prototypes    -Wno-inline
> -finline-limit=2500 -MM -x c rts/sm/Compact.c -MF
> rts/dist/build/.depend-v-dyn-l-debug-thr-thr_debug-thr_l-debug_dyn-thr_dyn-thr_debug_dyn-l_dyn-thr_l_dyn.c_asm.bit
> clang: error: unknown argument: '-finline-limit=2500'
> [-Wunused-command-line-argument-hard-error-in-future]
> clang: note: this will be a hard error (cannot be downgraded to a warning)
> in the future
> make[1]: ***
> [rts/dist/build/.depend-v-dyn-l-debug-thr-thr_debug-thr_l-debug_dyn-thr_dyn-thr_debug_dyn-l_dyn-thr_l_dyn.c_asm]
> Error 1
>
> More context:
> sed -e 's|\\|/|g' -e 's| /$| \\|' -e "1s|\.o|\.o|" -e "1s|^|rts/sm/|" -e
> "1s|rts/|rts/dist/build/|" -e "1s|dist/build/dist/build|dist/build|g" -e
> "s|/Users/tibbe/src/ghc/||g"
> rts/dist/build/.depend-v-dyn-l-debug-thr-thr_debug-thr_l-debug_dyn-thr_dyn-thr_debug_dyn-l_dyn-thr_l_dyn.c_asm.bit
> >>
> rts/dist/build/.depend-v-dyn-l-debug-thr-thr_debug-thr_l-debug_dyn-thr_dyn-thr_debug_dyn-l_dyn-thr_l_dyn.c_asm.tmp
> && sed -e 's|\\|/|g' -e 's| /$| \\|' -e "1s|\.o|\.dyn_o|" -e
> "1s|^|rts/sm/|" -e "1s|rts/|rts/dist/build/|" -e
> "1s|dist/build/dist/build|dist/build|g" -e "s|/Users/tibbe/src/ghc/||g"
> rts/dist/build/.depend-v-dyn-l-debug-thr-thr_debug-thr_l-debug_dyn-thr_dyn-thr_debug_dyn-l_dyn-thr_l_dyn.c_asm.bit
> >>
> rts/dist/build/.depend-v-dyn-l-debug-thr-thr_debug-thr_l-debug_dyn-thr_dyn-thr_debug_dyn-l_dyn-thr_l_dyn.c_asm.tmp
> && sed -e 's|\\|/|g' -e 's| /$| \\|' -e "1s|\.o|\.l_o|" -e "1s|^|rts/sm/|"
> -e "1s|rts/|rts/dist/build/|" -e "1s|dist/build/dist/build|dist/build|g" -e
> "s|/Users/tibbe/src/ghc/||g"
> rts/dist/build/.depend-v-dyn-l-debug-thr-thr_debug-thr_l-debug_dyn-thr_dyn-thr_debug_dyn-l_dyn-thr_l_dyn.c_asm.bit
> >>
> rts/dist/build/.depend-v-dyn-l-debug-thr-thr_debug-thr_l-debug_dyn-thr_dyn-thr_debug_dyn-l_dyn-thr_l_dyn.c_asm.tmp
> && sed -e 's|\\|/|g' -e 's| /$| \\|' -e "1s|\.o|\.debug_o|" -e
> "1s|^|rts/sm/|" -e "1s|rts/|rts/dist/build/|" -e
> "1s|dist/build/dist/build|dist/build|g" -e "s|/Users/tibbe/src/ghc/||g"
> rts/dist/build/.depend-v-dyn-l-debug-thr-thr_debug-thr_l-debug_dyn-thr_dyn-thr_debug_dyn-l_dyn-thr_l_dyn.c_asm.bit
> >>
> rts/dist/build/.depend-v-dyn-l-debug-thr-thr_debug-thr_l-debug_dyn-thr_dyn-thr_debug_dyn-l_dyn-thr_l_dyn.c_asm.tmp
> && sed -e 's|\\|/|g' -e 's| /$| \\|' -e "1s|\.o|\.thr_o|" -e
> "1s|^|rts/sm/|" -e "1s|rts/|rts/dist/build/|" -e
> "1s|dist/build/dist/build|dist/build|g" -e "s|/Users/tibbe/src/ghc/||g"
> rts/dist/build/.depend-v-dyn-l-debug-thr-thr_debug-thr_l-debug_dyn-thr_dyn-thr_debug_dyn-l_dyn-thr_l_dyn.c_asm.bit
> >>
> rts/dist/build/.depend-v-dyn-l-debug-thr-thr_debug-thr_l-debug_dyn-thr_dyn-thr_debug_dyn-l_dyn-thr_l_dyn.c_asm.tmp
> && sed -e 's|\\|/|g' -e 's| /$| \\|' -e "1s|\.o|\.thr_debug_o|" -e
> "1s|^|rts/sm/|" -e "1s|rts/|rts/dist/build/|" -e
> "1s|dist/build/dist/build|dist/build|g" -e "s|/Users/tibbe/src/ghc/||g"
> rts/dist/build/.depend-v-dyn-l-debug-thr-thr_debug-thr_l-debug_dyn-thr_dyn-thr_debug_dyn-l_dyn-thr_l_dyn.c_asm.bit
> >>
> rts/dist/build/.depend-v-dyn-l-debug-thr-thr_debug-thr_l-debug_dyn-thr_dyn-thr_debug_dyn-l_dyn-thr_l_dyn.c_asm.tmp
> && sed -e 's|\\|/|g' -e 's| /$| \\|' -e "1s|\.o|\.thr_l_o|" -e
> "1s|^|rts/sm/|" -e "1s|rts/|rts/dist/build/|" -e
> "1s|dist/build/dist/build|dist/build|g" -e "s|/Users/tibbe/src/ghc/||g"
> rts/dist/build/.depend-v-dyn-l-debug-thr-thr_debug-thr_l-debug_dyn-thr_dyn-thr_debug_dyn-l_dyn-thr_l_dyn.c_asm.bit
> >>
> rts/dist/build/.depend-v-dyn-l-debug-thr-thr_debug-thr_l-debug_dyn-thr_dyn-thr_debug_dyn-l_dyn-thr_l_dyn.c_asm.tmp
> && sed -e 's|\\|/|g' -e 's| /$| \\|' -e "1s|\.o|\.debug_dyn_o|" -e
> "1s|^|rts/sm/|" -e "1s|rts/|rts/dist/build/|" -e
> "1s|dist/build/dist/build|dist/build|g" -e "s|/Users/tibbe/src/ghc/||g"
> rts/dist/build/.depend-v-dyn-l-debug-thr-thr_debug-thr_l-debug_dyn-thr_dyn-thr_debug_dyn-l_dyn-thr_l_dyn.c_asm.bit
> >>
> rts/dist/build/.depend-v-dyn-l-debug-thr-thr_debug-thr_l-debug_dyn-thr_dyn-thr_debug_dyn-l_dyn-thr_l_dyn.c_asm.tmp
> && sed -e 's|\\|/|g' -e 's| /$| \\|' -e "1s|\.o|\.thr_dyn_o|" -e
> "1s|^|rts/sm/|" -e "1s|rts/|rts/dist/build/|" -e
> "1s|dist/build/dist/build|dist/build|g" -e "s|/Users/tibbe/src/ghc/||g"
> rts/dist/build/.depend-v-dyn-l-debug-thr-thr_debug-thr_l-debug_dyn-thr_dyn-thr_debug_dyn-l_dyn-thr_l_dyn.c_asm.bit
> >>
> rts/dist/build/.depend-v-dyn-l-debug-thr-thr_debug-thr_l-debug_dyn-thr_dyn-thr_debug_dyn-l_dyn-thr_l_dyn.c_asm.tmp
> && sed -e 's|\\|/|g' -e 's| /$| \\|' -e "1s|\.o|\.thr_debug_dyn_o|" -e
> "1s|^|rts/sm/|" -e "1s|rts/|rts/dist/build/|" -e
> "1s|dist/build/dist/build|dist/build|g" -e "s|/Users/tibbe/src/ghc/||g"
> rts/dist/build/.depend-v-dyn-l-debug-thr-thr_debug-thr_l-debug_dyn-thr_dyn-thr_debug_dyn-l_dyn-thr_l_dyn.c_asm.bit
> >>
> rts/dist/build/.depend-v-dyn-l-debug-thr-thr_debug-thr_l-debug_dyn-thr_dyn-thr_debug_dyn-l_dyn-thr_l_dyn.c_asm.tmp
> && sed -e 's|\\|/|g' -e 's| /$| \\|' -e "1s|\.o|\.l_dyn_o|" -e
> "1s|^|rts/sm/|" -e "1s|rts/|rts/dist/build/|" -e
> "1s|dist/build/dist/build|dist/build|g" -e "s|/Users/tibbe/src/ghc/||g"
> rts/dist/build/.depend-v-dyn-l-debug-thr-thr_debug-thr_l-debug_dyn-thr_dyn-thr_debug_dyn-l_dyn-thr_l_dyn.c_asm.bit
> >>
> rts/dist/build/.depend-v-dyn-l-debug-thr-thr_debug-thr_l-debug_dyn-thr_dyn-thr_debug_dyn-l_dyn-thr_l_dyn.c_asm.tmp
> && sed -e 's|\\|/|g' -e 's| /$| \\|' -e "1s|\.o|\.thr_l_dyn_o|" -e
> "1s|^|rts/sm/|" -e "1s|rts/|rts/dist/build/|" -e
> "1s|dist/build/dist/build|dist/build|g" -e "s|/Users/tibbe/src/ghc/||g"
> rts/dist/build/.depend-v-dyn-l-debug-thr-thr_debug-thr_l-debug_dyn-thr_dyn-thr_debug_dyn-l_dyn-thr_l_dyn.c_asm.bit
> >>
> rts/dist/build/.depend-v-dyn-l-debug-thr-thr_debug-thr_l-debug_dyn-thr_dyn-thr_debug_dyn-l_dyn-thr_l_dyn.c_asm.tmp
> && true
> gcc -E  -m64 -DPROFILING -DTHREADED_RTS -DDEBUG -Irts/dist/build  -m64
> -fno-stack-protector  -Wall -Wextra -Wstrict-prototypes
>  -Wmissing-prototypes  -Wmissing-declarations -Winline -Waggregate-return
> -Wpointer-arith -Wmissing-noreturn -Wnested-externs -Wredundant-decls
>  -Iincludes -Iincludes/dist -Iincludes/dist-derivedconstants/header
> -Iincludes/dist-ghcconstants/header -Irts -Irts/dist/build -DCOMPILING_RTS
> -fno-strict-aliasing -fno-common -DDTRACE        -O2 -fomit-frame-pointer
> -DRtsWay=\"rts_v\" -Wno-strict-prototypes    -Wno-inline
> -finline-limit=2500 -MM -x c rts/sm/Compact.c -MF
> rts/dist/build/.depend-v-dyn-l-debug-thr-thr_debug-thr_l-debug_dyn-thr_dyn-thr_debug_dyn-l_dyn-thr_l_dyn.c_asm.bit
> clang: error: unknown argument: '-finline-limit=2500'
> [-Wunused-command-line-argument-hard-error-in-future]
> clang: note: this will be a hard error (cannot be downgraded to a warning)
> in the future
> make[1]: ***
> [rts/dist/build/.depend-v-dyn-l-debug-thr-thr_debug-thr_l-debug_dyn-thr_dyn-thr_debug_dyn-l_dyn-thr_l_dyn.c_asm]
> Error 1
> make: *** [all] Error 2
>
> -- Johan
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/ghc-devs/attachments/20140313/370f9318/attachment.html>

From simonpj at microsoft.com  Thu Mar 13 09:46:16 2014
From: simonpj at microsoft.com (Simon Peyton Jones)
Date: Thu, 13 Mar 2014 09:46:16 +0000
Subject: Proposal: Partial Type Signatures
In-Reply-To: <532062AB.50108@cs.kuleuven.be>
References: <532062AB.50108@cs.kuleuven.be>
Message-ID: <59543203684B2244980D7E4057D5FBC1487E771D@DB3EX14MBXC306.europe.corp.microsoft.com>

| Together with Tom Schrijvers, Frank Piessens and Dominique Devriese, I
| have been working on a proposal for adding *Partial Type Signatures* to
| GHC. 
	
I'm all for this.  Yes, if the design and implementation are solid, I'd be happy to add it to the main branch.

Do focus on something with excellent power-to-weight ratio: that is, gives a lot of benefit for a small cost, rather than something that gives 10% more benefit for 200% more cost.

I've annotated the wiki page with some "SLPJ" comments, which you may want to look at.

I'd be happy to have a Skype conversation about the details in due course.

Simon

| -----Original Message-----
| From: ghc-devs [mailto:ghc-devs-bounces at haskell.org] On Behalf Of Thomas
| Winant
| Sent: 12 March 2014 13:36
| To: ghc-devs at haskell.org
| Cc: Tom Schrijvers; Frank Piessens
| Subject: Proposal: Partial Type Signatures
| 
| Dear GHC developers,
| 
| Together with Tom Schrijvers, Frank Piessens and Dominique Devriese, I
| have been working on a proposal for adding *Partial Type Signatures* to
| GHC. In a partial type signature, annotated types can be mixed with
| inferred types. A type signature is written like before, but can now
| contain wildcards, written as underscores. The types of these wildcards
| or unknown types will be inferred by the type checker, e.g.
| 
|      foo :: _ -> Bool
|      foo x = not x
|      -- Inferred: Bool -> Boo
| 
| The proposal also includes a form of generalisation which aligns with
| the existing generalisation that GHC does. We have written down a
| motivation (when and how might you use this) and details about the
| design and implementation on the following wiki page:
| 
| https://ghc.haskell.org/trac/ghc/wiki/PartialTypeSignatures
| 
| We have a (work in progress) implementation [1] of the feature based on
| GHC. It currently implements most of what we propose, but there are some
| remaining important bugs mostly concerning the generalisation. We also
| described our design and presented a formalisation based on the
| OutsideIn(X) formalism in a paper [2] presented at PADL'14.
| 
| What we are hoping to get from the people on this list is any of the
| below:
| * Read the design, play with the implementation and tell us any comments
|    you may have about the feature, its design and implementation.
| * Opinions on whether this feature might be acceptable in GHC upstream
|    at some point (if not, we do not think it's worth developing the
|    implementation much further).
| * Perhaps a code review or a discussion with someone more knowledgeable
|    about the internals of GHC's type checker about how we might fix the
|    remaining problems in our implementation (specifically, we could use
|    some help with implementing the generalisation of partial type
|    signatures).
| * Feedback on the `Questions and issues' section on the wiki page.
| 
| 
| Kind regards,
| Thomas Winant
| 
| [1]: https://github.com/mrBliss/ghc-head/
| [2]: https://lirias.kuleuven.be/bitstream/123456789/423475/3/paper.pdf
| 
| 
| Disclaimer: http://www.kuleuven.be/cwis/email_disclaimer.htm
| _______________________________________________
| ghc-devs mailing list
| ghc-devs at haskell.org
| http://www.haskell.org/mailman/listinfo/ghc-devs

From kyrab at mail.ru  Thu Mar 13 10:16:34 2014
From: kyrab at mail.ru (kyra)
Date: Thu, 13 Mar 2014 14:16:34 +0400
Subject: Building GHC on Windows
In-Reply-To: <201403131018.48375.jan.stolarek@p.lodz.pl>
References: <201403131018.48375.jan.stolarek@p.lodz.pl>
Message-ID: <53218582.1080802@mail.ru>

On 3/13/2014 13:18, Jan Stolarek wrote:
> I'm trying to build GHC on 64-bit Windows 7. I installed Cygwin, GHC and cloned the main repo but
> when I run configure I get this error:
>
> configure: Building in-tree ghc-pwd
> checking for path to top of build tree... cygwin warning:
>    MS-DOS style path detected: C:/cygwin64/home/tewi/head
>    Preferred POSIX equivalent is: /home/tewi/head
>    CYGWIN environment variable option "nodosfilewarning" turns off this warning.
>    Consult the user's guide for more details about POSIX paths:
>      http://cygwin.com/cygwin-ug-net/using.html#using-pathnames
> C:/cygwin64/home/tewi/head
> checking for gcc... C:/cygwin64/home/tewi/head/inplace/mingw/bin/gcc.exe
> checking whether the C compiler works... no
> configure: error: in `/home/tewi/head':
> configure: error: C compiler cannot create executables
> See `config.log' for more details
>
> I have gcc installed under Cygwin, but for some reason ./configure is looking for an in-tree
> compiler. I tried passing --with-gcc=/usr/bin/gcc to configure but with no result. Help?
>
> Janek
>
> _______________________________________________
> ghc-devs mailing list
> ghc-devs at haskell.org
> http://www.haskell.org/mailman/listinfo/ghc-devs
>
Windows GHC *shall* use in-tree compiler. Windows GHC does *not* use 
cygwin runtime at all!

Now the best way to build GHC on Windows is to use MSYS2: 
https://ghc.haskell.org/trac/ghc/wiki/Building/Preparation/Windows/MSYS2.

I'd also add that most recent versions are

http://sourceforge.net/projects/msys2/files/Base/i686/msys2-base-i686-20140216.tar.xz/download
for 32-bit windows,

and

http://sourceforge.net/projects/msys2/files/Base/x86_64/msys2-base-x86_64-20140216.tar.xz/download
for 64-bit windows.

Please, take into account this is *build environment* and in no way is 
related to gcc compiler and runtime used by GHC on Windows.

Cheers,
Kyra


From jan.stolarek at p.lodz.pl  Thu Mar 13 11:48:14 2014
From: jan.stolarek at p.lodz.pl (Jan Stolarek)
Date: Thu, 13 Mar 2014 12:48:14 +0100
Subject: Building GHC on Windows
In-Reply-To: <53218582.1080802@mail.ru>
References: <201403131018.48375.jan.stolarek@p.lodz.pl>
 <53218582.1080802@mail.ru>
Message-ID: <201403131248.14324.jan.stolarek@p.lodz.pl>

Thanks. I installed msys but again I faced the same problem. I solved it by copying mingw 
directory from ghc-7.6.3 distribution to inplace/mingw subdirectory in the source tree. That's 
silly but it works. 

Now I have problems with installing alex and happy. I followed steps on wiki page, ie. downloaded 
cabal.exe and added it to path. I can run 'cabal update' and 'cabal install alex happy' but it 
looks like packages are not installed in my home directory (home under msys shell that is). Any 
idea where are they installed so that I can add them to path?

Janek

Dnia czwartek, 13 marca 2014, kyra napisa?:
> On 3/13/2014 13:18, Jan Stolarek wrote:
> > I'm trying to build GHC on 64-bit Windows 7. I installed Cygwin, GHC and
> > cloned the main repo but when I run configure I get this error:
> >
> > configure: Building in-tree ghc-pwd
> > checking for path to top of build tree... cygwin warning:
> >    MS-DOS style path detected: C:/cygwin64/home/tewi/head
> >    Preferred POSIX equivalent is: /home/tewi/head
> >    CYGWIN environment variable option "nodosfilewarning" turns off this
> > warning. Consult the user's guide for more details about POSIX paths:
> >      http://cygwin.com/cygwin-ug-net/using.html#using-pathnames
> > C:/cygwin64/home/tewi/head
> > checking for gcc... C:/cygwin64/home/tewi/head/inplace/mingw/bin/gcc.exe
> > checking whether the C compiler works... no
> > configure: error: in `/home/tewi/head':
> > configure: error: C compiler cannot create executables
> > See `config.log' for more details
> >
> > I have gcc installed under Cygwin, but for some reason ./configure is
> > looking for an in-tree compiler. I tried passing --with-gcc=/usr/bin/gcc
> > to configure but with no result. Help?
> >
> > Janek
> >
> > _______________________________________________
> > ghc-devs mailing list
> > ghc-devs at haskell.org
> > http://www.haskell.org/mailman/listinfo/ghc-devs
>
> Windows GHC *shall* use in-tree compiler. Windows GHC does *not* use
> cygwin runtime at all!
>
> Now the best way to build GHC on Windows is to use MSYS2:
> https://ghc.haskell.org/trac/ghc/wiki/Building/Preparation/Windows/MSYS2.
>
> I'd also add that most recent versions are
>
> http://sourceforge.net/projects/msys2/files/Base/i686/msys2-base-i686-20140
>216.tar.xz/download for 32-bit windows,
>
> and
>
> http://sourceforge.net/projects/msys2/files/Base/x86_64/msys2-base-x86_64-2
>0140216.tar.xz/download for 64-bit windows.
>
> Please, take into account this is *build environment* and in no way is
> related to gcc compiler and runtime used by GHC on Windows.
>
> Cheers,
> Kyra
>
> _______________________________________________
> ghc-devs mailing list
> ghc-devs at haskell.org
> http://www.haskell.org/mailman/listinfo/ghc-devs



From austin at well-typed.com  Thu Mar 13 12:03:05 2014
From: austin at well-typed.com (Austin Seipp)
Date: Thu, 13 Mar 2014 07:03:05 -0500
Subject: Building GHC on Windows
In-Reply-To: <201403131248.14324.jan.stolarek@p.lodz.pl>
References: <201403131018.48375.jan.stolarek@p.lodz.pl>
 <53218582.1080802@mail.ru>
 <201403131248.14324.jan.stolarek@p.lodz.pl>
Message-ID: <CAEs96n1uWmqa7QJrOk4iPxsW-9+YQw+KtuZYTGXoxLJrCbZa-w@mail.gmail.com>

Follow the instructions on the wiki that Kyra linked *exactly*. You
need to properly set your $PATH to contain:

/c/Users/$USER/AppData/Roaming/cabal/bin

If you delete all that stuff and follow those instructions, you should
be able to get running in about 5 minutes. You can copy and paste
every command without problem:

https://ghc.haskell.org/trac/ghc/wiki/Building/Preparation/Windows/MSYS2

On Thu, Mar 13, 2014 at 6:48 AM, Jan Stolarek <jan.stolarek at p.lodz.pl> wrote:
> Thanks. I installed msys but again I faced the same problem. I solved it by copying mingw
> directory from ghc-7.6.3 distribution to inplace/mingw subdirectory in the source tree. That's
> silly but it works.
>
> Now I have problems with installing alex and happy. I followed steps on wiki page, ie. downloaded
> cabal.exe and added it to path. I can run 'cabal update' and 'cabal install alex happy' but it
> looks like packages are not installed in my home directory (home under msys shell that is). Any
> idea where are they installed so that I can add them to path?
>
> Janek
>
> Dnia czwartek, 13 marca 2014, kyra napisa?:
>> On 3/13/2014 13:18, Jan Stolarek wrote:
>> > I'm trying to build GHC on 64-bit Windows 7. I installed Cygwin, GHC and
>> > cloned the main repo but when I run configure I get this error:
>> >
>> > configure: Building in-tree ghc-pwd
>> > checking for path to top of build tree... cygwin warning:
>> >    MS-DOS style path detected: C:/cygwin64/home/tewi/head
>> >    Preferred POSIX equivalent is: /home/tewi/head
>> >    CYGWIN environment variable option "nodosfilewarning" turns off this
>> > warning. Consult the user's guide for more details about POSIX paths:
>> >      http://cygwin.com/cygwin-ug-net/using.html#using-pathnames
>> > C:/cygwin64/home/tewi/head
>> > checking for gcc... C:/cygwin64/home/tewi/head/inplace/mingw/bin/gcc.exe
>> > checking whether the C compiler works... no
>> > configure: error: in `/home/tewi/head':
>> > configure: error: C compiler cannot create executables
>> > See `config.log' for more details
>> >
>> > I have gcc installed under Cygwin, but for some reason ./configure is
>> > looking for an in-tree compiler. I tried passing --with-gcc=/usr/bin/gcc
>> > to configure but with no result. Help?
>> >
>> > Janek
>> >
>> > _______________________________________________
>> > ghc-devs mailing list
>> > ghc-devs at haskell.org
>> > http://www.haskell.org/mailman/listinfo/ghc-devs
>>
>> Windows GHC *shall* use in-tree compiler. Windows GHC does *not* use
>> cygwin runtime at all!
>>
>> Now the best way to build GHC on Windows is to use MSYS2:
>> https://ghc.haskell.org/trac/ghc/wiki/Building/Preparation/Windows/MSYS2.
>>
>> I'd also add that most recent versions are
>>
>> http://sourceforge.net/projects/msys2/files/Base/i686/msys2-base-i686-20140
>>216.tar.xz/download for 32-bit windows,
>>
>> and
>>
>> http://sourceforge.net/projects/msys2/files/Base/x86_64/msys2-base-x86_64-2
>>0140216.tar.xz/download for 64-bit windows.
>>
>> Please, take into account this is *build environment* and in no way is
>> related to gcc compiler and runtime used by GHC on Windows.
>>
>> Cheers,
>> Kyra
>>
>> _______________________________________________
>> ghc-devs mailing list
>> ghc-devs at haskell.org
>> http://www.haskell.org/mailman/listinfo/ghc-devs
>
>
> _______________________________________________
> ghc-devs mailing list
> ghc-devs at haskell.org
> http://www.haskell.org/mailman/listinfo/ghc-devs



-- 
Regards,

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

From kyrab at mail.ru  Thu Mar 13 12:04:11 2014
From: kyrab at mail.ru (kyra)
Date: Thu, 13 Mar 2014 16:04:11 +0400
Subject: Building GHC on Windows
In-Reply-To: <201403131248.14324.jan.stolarek@p.lodz.pl>
References: <201403131018.48375.jan.stolarek@p.lodz.pl>
 <53218582.1080802@mail.ru> <201403131248.14324.jan.stolarek@p.lodz.pl>
Message-ID: <53219EBB.9090103@mail.ru>

On 3/13/2014 15:48, Jan Stolarek wrote:
> Thanks. I installed msys but again I faced the same problem. I solved it by copying mingw
> directory from ghc-7.6.3 distribution to inplace/mingw subdirectory in the source tree. That's
> silly but it works.
I suspect this is because you've cloned repo under system other than 
windows and thus didn't clone ghc-tarballs repo.
> Now I have problems with installing alex and happy. I followed steps on wiki page, ie. downloaded
> cabal.exe and added it to path. I can run 'cabal update' and 'cabal install alex happy' but it
> looks like packages are not installed in my home directory (home under msys shell that is). Any
> idea where are they installed so that I can add them to path?
AFAIUI, default prefix is 
C:\Users\<username>\AppData\Roaming\cabal\<arch>-windows-ghc-<version>.

But I'd recommend to install things to predefined location, using 
--prefix option of cabal, e.g. thus:
cabal install --global --prefix=<location> --datadir=<location>
to avoid potential problems with national chars in username. This 
problem existed in the past, not sure it exists now, though.

Kyra

From thomas.winant at cs.kuleuven.be  Thu Mar 13 12:18:19 2014
From: thomas.winant at cs.kuleuven.be (Thomas Winant)
Date: Thu, 13 Mar 2014 13:18:19 +0100
Subject: Proposal: Partial Type Signatures
In-Reply-To: <CAEs96n2FyvRLQ0TcXb_wDbc7bmAnz3mNNo8O1oDDkmsTGjCj3w@mail.gmail.com>
References: <532062AB.50108@cs.kuleuven.be>
 <CAJumaK8P8hvWOnjFcid4HeucsrXiCjAG7RYfLw-H9=rQVyTGug@mail.gmail.com>
 <A2DD78C8-8E2A-4F09-8BC2-CEB087BD5DBE@me.com>
 <59543203684B2244980D7E4057D5FBC1487E5513@DB3EX14MBXC306.europe.corp.microsoft.com>
 <CAK-hX0keV-CeO2kSx158Z0s+23_p3eL6oK1dw3+7vBe0GbJ3AA@mail.gmail.com>
 <CAEs96n2FyvRLQ0TcXb_wDbc7bmAnz3mNNo8O1oDDkmsTGjCj3w@mail.gmail.com>
Message-ID: <5321A20B.40504@cs.kuleuven.be>


On 03/12/2014 08:09 PM, Austin Seipp wrote:
> In any case, I believe the  original formulation of Holes by Thijs
 > actually somewhat overlapped with the idea presented here. In
 > particular, it would have allowed us to say[4]:
 >
 > f :: Bool -> _ ()
 > f = ...
 >
 > where _ is a 'hole' in the signature, and the type-checker would try
 > to report some kind of type constructors that might fit based on the
 > definition. But this was never implemented, and the design was more in
 > the style of Agda-goals: they were meant to help you write out the
 > types, not avoid them through inference.
 >
 > In any case - I too am receptive to the idea of partial type
 > signatures, so I'd like to see this. (And if we could make it
 > optionally work with the ideas proposed by Thijs, that would be great,
 > so we can actually have 'holes' at the type level, like at the term
 > level. But Simon has some good points in [4] worth reading on that
 > note.)

We have also thought about letting the compiler notify the user of the
type each wildcard or 'type hole' was instantiated to during type
inference. We would certainly like to work further on this front, i.e.
reporting the instantiations and/or extending the GHC API to allow
Agda-like goal solving.

However, we have the impression that no Hole should remain unfilled,
whereas using a partial type signature doesn't necessarily mean the
program is incomplete. A partial type signature can still be a
(stylistic) choice.

Cheers,
Thomas

Disclaimer: http://www.kuleuven.be/cwis/email_disclaimer.htm

From dluposchainsky at googlemail.com  Thu Mar 13 13:11:32 2014
From: dluposchainsky at googlemail.com (David Luposchainsky)
Date: Thu, 13 Mar 2014 14:11:32 +0100
Subject: Proposal: Partial Type Signatures
In-Reply-To: <532062AB.50108@cs.kuleuven.be>
References: <532062AB.50108@cs.kuleuven.be>
Message-ID: <5321AE84.2090700@gmail.com>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

One useful thing to have would be a new flag that, similar to
- -fwarn-missing-signatures, warns if there is a top-level definition
with an incomplete type.

However, this clashes a bit with the "Readability" section of the wiki
entry, so it's up to debate whether this should be included in -W,
- -Wall, or none of the "packaged" warning flags at all.

Greetings,
David/Quchen
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.14 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iQEcBAEBAgAGBQJTIa6EAAoJELrQsaT5WQUsQOEIAKoId2sWlWN2slJEK0RGjwmt
LTOlqiQ0qRsxA8kxFqMqVXWoXEKN9Qv0QmxqT1pSbQHDyTq+0DSZ6POUmKFNOPK5
U0YbnOxx9tz2Tb6lZqlbpRbqXEGzZ4KZF8qlDwUB2NZcoLvxtsJ46wE2gBgDW26y
rnHXDrRqF7PNAbzTxIrIyAiWAAExhnYymIy6B+tEXRG8eckwyxMb3ETTJ1abIsKT
tnzS2JFttfxHug0RFYRN9v5J7vC+7PpofoeHJkj39aLSHTncK/RS1aCsE2Jq9XI2
EHR1YF3ZK08wxZ8eEnKwY5tOT3dsuJoziZeIbO2Hp+DhxnJUWj7UsvcZVN/Q0/c=
=Mpan
-----END PGP SIGNATURE-----

From jan.stolarek at p.lodz.pl  Thu Mar 13 13:17:05 2014
From: jan.stolarek at p.lodz.pl (Jan Stolarek)
Date: Thu, 13 Mar 2014 14:17:05 +0100
Subject: Building GHC on Windows
In-Reply-To: <53219EBB.9090103@mail.ru>
References: <201403131018.48375.jan.stolarek@p.lodz.pl>
 <201403131248.14324.jan.stolarek@p.lodz.pl> <53219EBB.9090103@mail.ru>
Message-ID: <201403131417.05360.jan.stolarek@p.lodz.pl>

> Follow the instructions on the wiki that Kyra linked *exactly*. You
> need to properly set your $PATH to contain:
>
> /c/Users/$USER/AppData/Roaming/cabal/bin
Duh, I missed that one. My bad.

> I suspect this is because you've cloned repo under system other than
> windows and thus didn't clone ghc-tarballs repo.
It was cloned under cygwin.

It looks thta everything is in good shape now - I'm building HEAD at the moment.

Janek

From carter.schonwald at gmail.com  Thu Mar 13 14:11:22 2014
From: carter.schonwald at gmail.com (Carter Schonwald)
Date: Thu, 13 Mar 2014 10:11:22 -0400
Subject: [PATCH] sync-all: Skip END actions on exceptions
In-Reply-To: <87pplq8mwb.fsf@mid.deneb.enyo.de>
References: <87pplq8mwb.fsf@mid.deneb.enyo.de>
Message-ID: <CAHYVw0w1sivFOQ60=k462tf5ZAnWnWhtOLbpxkyd8zWOLr4oKg@mail.gmail.com>

Could you please creat a ticket on trac with the patch?

On Thursday, March 13, 2014, Florian Weimer <fw at deneb.enyo.de> wrote:

> The instructions at <https://ghc.haskell.org/trac/ghc/wiki/Newcomers>
> were slightly outdated, and result in a rather confusing error
> messsage:
>
> $ ./sync-all --testsuite get
> Unrecognised flag: --testsuite at ./sync-all line 872.
> == Checking for old haddock repo
> == Checking for old binary repo
> == Checking for old mtl repo
> == Checking for old Cabal repo
> == Checking for old time from tarball
> ============================
> ATTENTION!
>
> You have an old time package in your GHC tree!
>
> Please remove it (e.g. "rm -r libraries/time"), and then run
> "./sync-all get" to get the new repository.
> ============================
> == Checking for obsolete Git repo URL
> $
>
> The patch corrects the error message.  I've removed the --testsuite
> flag from the wiki page as well.
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/ghc-devs/attachments/20140313/bc8b5a8d/attachment.html>

From karel.gardas at centrum.cz  Thu Mar 13 18:49:57 2014
From: karel.gardas at centrum.cz (Karel Gardas)
Date: Thu, 13 Mar 2014 19:49:57 +0100
Subject: Where to find GHC.Types.D#_con_info
Message-ID: <5321FDD5.7080104@centrum.cz>

Hello,

I'm trying to debug few issues in SPARC NCG, now dealing with double 
floats issue. Always get 0.0 and while hunting this I've stepped over 
GHC.Types.D#_con_info which I'm not able to find in GHC sources but I 
guess it should be somewhere... Any idea where to look to see its code 
for reference?

Thanks!
Karel

From jpm at cs.uu.nl  Thu Mar 13 19:15:06 2014
From: jpm at cs.uu.nl (=?ISO-8859-1?Q?Jos=E9_Pedro_Magalh=E3es?=)
Date: Thu, 13 Mar 2014 19:15:06 +0000
Subject: Where to find GHC.Types.D#_con_info
In-Reply-To: <5321FDD5.7080104@centrum.cz>
References: <5321FDD5.7080104@centrum.cz>
Message-ID: <CA+ZFbn_juuxKZ3Zk16xtuDrWudpMAb6AL9pXvsb5zv4-FDPi2g@mail.gmail.com>

This might be GHC.Generics generated stuff. Do you have some more context?


Thanks,
Pedro


On Thu, Mar 13, 2014 at 6:49 PM, Karel Gardas <karel.gardas at centrum.cz>wrote:

> Hello,
>
> I'm trying to debug few issues in SPARC NCG, now dealing with double
> floats issue. Always get 0.0 and while hunting this I've stepped over
> GHC.Types.D#_con_info which I'm not able to find in GHC sources but I guess
> it should be somewhere... Any idea where to look to see its code for
> reference?
>
> Thanks!
> Karel
> _______________________________________________
> ghc-devs mailing list
> ghc-devs at haskell.org
> http://www.haskell.org/mailman/listinfo/ghc-devs
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/ghc-devs/attachments/20140313/6db0f5c2/attachment-0001.html>

From thomas.winant at cs.kuleuven.be  Thu Mar 13 19:38:05 2014
From: thomas.winant at cs.kuleuven.be (Thomas Winant)
Date: Thu, 13 Mar 2014 20:38:05 +0100
Subject: Proposal: Partial Type Signatures
In-Reply-To: <59543203684B2244980D7E4057D5FBC1487E771D@DB3EX14MBXC306.europe.corp.microsoft.com>
References: <532062AB.50108@cs.kuleuven.be>
 <59543203684B2244980D7E4057D5FBC1487E771D@DB3EX14MBXC306.europe.corp.microsoft.com>
Message-ID: <5322091D.6040109@cs.kuleuven.be>

On 13-03-14 10:46, Simon Peyton Jones wrote:
> | Together with Tom Schrijvers, Frank Piessens and Dominique Devriese, I
> | have been working on a proposal for adding *Partial Type Signatures* to
> | GHC.
>
> I'm all for this.  Yes, if the design and implementation are solid, I'd be happy to add it to the main branch.
>
> Do focus on something with excellent power-to-weight ratio: that is, gives a lot of benefit for a small cost, rather than something that gives 10% more benefit for 200% more cost.
>
> I've annotated the wiki page with some "SLPJ" comments, which you may want to look at.
>
> I'd be happy to have a Skype conversation about the details in due course.

Excellent, I added responses ("thomasw") to your comments on the wiki
page.

Cheers,
Thomas


> | -----Original Message-----
> | From: ghc-devs [mailto:ghc-devs-bounces at haskell.org] On Behalf Of Thomas
> | Winant
> | Sent: 12 March 2014 13:36
> | To: ghc-devs at haskell.org
> | Cc: Tom Schrijvers; Frank Piessens
> | Subject: Proposal: Partial Type Signatures
> |
> | Dear GHC developers,
> |
> | Together with Tom Schrijvers, Frank Piessens and Dominique Devriese, I
> | have been working on a proposal for adding *Partial Type Signatures* to
> | GHC. In a partial type signature, annotated types can be mixed with
> | inferred types. A type signature is written like before, but can now
> | contain wildcards, written as underscores. The types of these wildcards
> | or unknown types will be inferred by the type checker, e.g.
> |
> |      foo :: _ -> Bool
> |      foo x = not x
> |      -- Inferred: Bool -> Boo
> |
> | The proposal also includes a form of generalisation which aligns with
> | the existing generalisation that GHC does. We have written down a
> | motivation (when and how might you use this) and details about the
> | design and implementation on the following wiki page:
> |
> | https://ghc.haskell.org/trac/ghc/wiki/PartialTypeSignatures
> |
> | We have a (work in progress) implementation [1] of the feature based on
> | GHC. It currently implements most of what we propose, but there are some
> | remaining important bugs mostly concerning the generalisation. We also
> | described our design and presented a formalisation based on the
> | OutsideIn(X) formalism in a paper [2] presented at PADL'14.
> |
> | What we are hoping to get from the people on this list is any of the
> | below:
> | * Read the design, play with the implementation and tell us any comments
> |    you may have about the feature, its design and implementation.
> | * Opinions on whether this feature might be acceptable in GHC upstream
> |    at some point (if not, we do not think it's worth developing the
> |    implementation much further).
> | * Perhaps a code review or a discussion with someone more knowledgeable
> |    about the internals of GHC's type checker about how we might fix the
> |    remaining problems in our implementation (specifically, we could use
> |    some help with implementing the generalisation of partial type
> |    signatures).
> | * Feedback on the `Questions and issues' section on the wiki page.
> |
> |
> | Kind regards,
> | Thomas Winant
> |
> | [1]: https://github.com/mrBliss/ghc-head/
> | [2]: https://lirias.kuleuven.be/bitstream/123456789/423475/3/paper.pdf
> |
> |
> | Disclaimer: http://www.kuleuven.be/cwis/email_disclaimer.htm
> | _______________________________________________
> | ghc-devs mailing list
> | ghc-devs at haskell.org
> | http://www.haskell.org/mailman/listinfo/ghc-devs
>

Disclaimer: http://www.kuleuven.be/cwis/email_disclaimer.htm

From johan.tibell at gmail.com  Thu Mar 13 20:13:06 2014
From: johan.tibell at gmail.com (Johan Tibell)
Date: Thu, 13 Mar 2014 21:13:06 +0100
Subject: New validate failures
Message-ID: <CAK-tuPbn5y7KDSZuct2TwSnHwJWZ=dSzoPmS4BsQdLA--Q9M4Q@mail.gmail.com>

Hi,

Did something change in pretty-printing recently? I saw these new validate
failures today:

Unexpected failures:
   ghci.debugger/scripts  break008 [bad stdout] (ghci)
   ghci.debugger/scripts  break012 [bad stdout] (ghci)
   ghci.debugger/scripts  break026 [bad stdout] (ghci)
   ghci.debugger/scripts  hist001 [bad stdout] (ghci)
   ghci/scripts           T5545 [bad stdout] (ghci)
   ghci/scripts           ghci008 [bad stdout] (ghci)
   ghci/scripts           ghci012 [bad stdout] (ghci)
   ghci/scripts           ghci023 [bad stdout] (ghci)
   ghci/scripts           ghci025 [bad stdout] (ghci)
   ghci/scripts           ghci026 [bad stdout] (ghci)
   ghci/scripts           ghci055 [bad stdout] (ghci)

Two example stdout changes:

--- ./T5545.stdout 2014-03-13 09:48:23.000000000 +0100
+++ ./T5545.run.stdout 2014-03-13 21:11:32.000000000 +0100
@@ -1,2 +1,2 @@
-($!) :: (a -> b) -> a -> b -- Defined in 'Prelude'
+$! :: forall a b. (a -> b) -> a -> b -- Defined in 'Prelude'
 infixr 0 $!
*** unexpected failure for T5545(ghci)

--- ./ghci008.stdout 2014-03-13 09:48:23.000000000 +0100
+++ ./ghci008.run.stdout 2014-03-13 21:12:20.000000000 +0100
@@ -32,5 +32,5 @@
    -- Defined in 'GHC.Float'
 instance RealFloat Float -- Defined in 'GHC.Float'
 instance RealFloat Double -- Defined in 'GHC.Float'
-Data.List.isPrefixOf :: Eq a => [a] -> [a] -> Bool
+isPrefixOf :: forall a. Eq a -> [a] -> [a] -> Bool
    -- Defined in 'Data.List'
*** unexpected failure for ghci008(ghci)
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/ghc-devs/attachments/20140313/24cb586b/attachment.html>

From johan.tibell at gmail.com  Thu Mar 13 20:15:27 2014
From: johan.tibell at gmail.com (Johan Tibell)
Date: Thu, 13 Mar 2014 21:15:27 +0100
Subject: [commit: ghc] master: Pretty-print the following TyThings via
 their IfaceDecl counterpart: * AnId * ACoAxiom * AConLike (065c35a)
In-Reply-To: <20140313132145.1D9472406B@ghc.haskell.org>
References: <20140313132145.1D9472406B@ghc.haskell.org>
Message-ID: <CAK-tuPZSNQE9EV0tWTZ-oFWnnLwYPwXH8Db1A45PNjboa7cBMQ@mail.gmail.com>

Could these changes be related to the validate failures I just posted about
on the mailing list?


On Thu, Mar 13, 2014 at 2:21 PM, <git at git.haskell.org> wrote:

> Repository : ssh://git at git.haskell.org/ghc
>
> On branch  : master
> Link       :
> http://ghc.haskell.org/trac/ghc/changeset/065c35a9d6d48060c8fac8d755833349ce58b35b/ghc
>
> >---------------------------------------------------------------
>
> commit 065c35a9d6d48060c8fac8d755833349ce58b35b
> Author: Dr. ERDI Gergo <gergo at erdi.hu>
> Date:   Thu Mar 13 21:18:39 2014 +0800
>
>     Pretty-print the following TyThings via their IfaceDecl counterpart:
>      * AnId
>      * ACoAxiom
>      * AConLike
>
>
> >---------------------------------------------------------------
>
> 065c35a9d6d48060c8fac8d755833349ce58b35b
>  compiler/iface/IfaceSyn.lhs |    2 +-
>  compiler/iface/MkIface.lhs  |   10 +++++++-
>  compiler/main/PprTyThing.hs |   59
> ++++++++++---------------------------------
>  3 files changed, 23 insertions(+), 48 deletions(-)
>
> diff --git a/compiler/iface/IfaceSyn.lhs b/compiler/iface/IfaceSyn.lhs
> index 8ca8582..7484b37 100644
> --- a/compiler/iface/IfaceSyn.lhs
> +++ b/compiler/iface/IfaceSyn.lhs
> @@ -1100,7 +1100,7 @@ pprIfaceDecl (IfaceClass {ifCtxt = context, ifName =
> clas, ifTyVars = tyvars,
>                  sep (map ppr sigs)])
>
>  pprIfaceDecl (IfaceAxiom {ifName = name, ifTyCon = tycon, ifAxBranches =
> branches })
> -  = hang (ptext (sLit "axiom") <+> ppr name <> colon)
> +  = hang (ptext (sLit "axiom") <+> ppr name <> dcolon)
>         2 (vcat $ map (pprAxBranch $ Just tycon) branches)
>
>  pprIfaceDecl (IfacePatSyn { ifName = name, ifPatHasWrapper = has_wrap,
> diff --git a/compiler/iface/MkIface.lhs b/compiler/iface/MkIface.lhs
> index 0af9af6..51df08c 100644
> --- a/compiler/iface/MkIface.lhs
> +++ b/compiler/iface/MkIface.lhs
> @@ -1461,7 +1461,7 @@ tyThingToIfaceDecl (AnId id)      = idToIfaceDecl id
>  tyThingToIfaceDecl (ATyCon tycon) = tyConToIfaceDecl emptyTidyEnv tycon
>  tyThingToIfaceDecl (ACoAxiom ax)  = coAxiomToIfaceDecl ax
>  tyThingToIfaceDecl (AConLike cl)  = case cl of
> -    RealDataCon dc -> pprPanic "toIfaceDecl" (ppr dc) -- Should be
> trimmed out earlier
> +    RealDataCon dc -> dataConToIfaceDecl dc -- for ppr purposes only
>      PatSynCon ps   -> patSynToIfaceDecl ps
>
>  --------------------------
> @@ -1477,6 +1477,14 @@ idToIfaceDecl id
>                ifIdInfo    = toIfaceIdInfo (idInfo id) }
>
>  --------------------------
> +dataConToIfaceDecl :: DataCon -> IfaceDecl
> +dataConToIfaceDecl dataCon
> +  = IfaceId { ifName      = getOccName dataCon,
> +              ifType      = toIfaceType (dataConUserType dataCon),
> +              ifIdDetails = IfVanillaId,
> +              ifIdInfo    = NoInfo }
> +
> +--------------------------
>  patSynToIfaceDecl :: PatSyn -> IfaceDecl
>  patSynToIfaceDecl ps
>    = IfacePatSyn { ifName          = getOccName . getName $ ps
> diff --git a/compiler/main/PprTyThing.hs b/compiler/main/PprTyThing.hs
> index 27e7390..fb92b5a 100644
> --- a/compiler/main/PprTyThing.hs
> +++ b/compiler/main/PprTyThing.hs
> @@ -23,20 +23,18 @@ module PprTyThing (
>    ) where
>
>  import TypeRep ( TyThing(..) )
> -import ConLike
>  import DataCon
> -import PatSyn
>  import Id
>  import TyCon
>  import Class
> -import Coercion( pprCoAxiom, pprCoAxBranch )
> +import Coercion( pprCoAxBranch )
>  import CoAxiom( CoAxiom(..), brListMap )
>  import HscTypes( tyThingParent_maybe )
> -import HsBinds( pprPatSynSig )
>  import Type( tidyTopType, tidyOpenType, splitForAllTys, funResultTy )
>  import Kind( synTyConResKind )
>  import TypeRep( pprTvBndrs, pprForAll, suppressKinds )
>  import TysPrim( alphaTyVars )
> +import MkIface ( tyThingToIfaceDecl )
>  import TcType
>  import Name
>  import VarEnv( emptyTidyEnv )
> @@ -44,7 +42,6 @@ import StaticFlags( opt_PprStyle_Debug )
>  import DynFlags
>  import Outputable
>  import FastString
> -import Data.Maybe
>
>  --
> -----------------------------------------------------------------------------
>  -- Pretty-printing entities that we get from the GHC API
> @@ -76,7 +73,7 @@ pprTyThingLoc tyThing
>
>  -- | Pretty-prints a 'TyThing'.
>  pprTyThing :: TyThing -> SDoc
> -pprTyThing thing = ppr_ty_thing showAll thing
> +pprTyThing thing = ppr_ty_thing (Just showAll) thing
>
>  -- | Pretty-prints a 'TyThing' in context: that is, if the entity
>  -- is a data constructor, record selector, or class method, then
> @@ -88,7 +85,7 @@ pprTyThingInContext thing
>    where
>      go ss thing = case tyThingParent_maybe thing of
>                      Just parent -> go (getName thing : ss) parent
> -                    Nothing     -> ppr_ty_thing ss thing
> +                    Nothing     -> ppr_ty_thing (Just ss) thing
>
>  -- | Like 'pprTyThingInContext', but adds the defining location.
>  pprTyThingInContextLoc :: TyThing -> SDoc
> @@ -100,21 +97,17 @@ pprTyThingInContextLoc tyThing
>  -- the function is equivalent to 'pprTyThing' but for type constructors
>  -- and classes it prints only the header part of the declaration.
>  pprTyThingHdr :: TyThing -> SDoc
> -pprTyThingHdr (AnId id)          = pprId         id
> -pprTyThingHdr (AConLike conLike) = case conLike of
> -    RealDataCon dataCon -> pprDataConSig dataCon
> -    PatSynCon patSyn    -> pprPatSyn     patSyn
> -pprTyThingHdr (ATyCon tyCon)     = pprTyConHdr   tyCon
> -pprTyThingHdr (ACoAxiom ax)      = pprCoAxiom ax
> +pprTyThingHdr = ppr_ty_thing Nothing
>
>  ------------------------
> -ppr_ty_thing :: ShowSub -> TyThing -> SDoc
> -ppr_ty_thing _  (AnId id)          = pprId         id
> -ppr_ty_thing _  (AConLike conLike) = case conLike of
> -    RealDataCon dataCon -> pprDataConSig dataCon
> -    PatSynCon patSyn    -> pprPatSyn     patSyn
> -ppr_ty_thing ss (ATyCon tyCon)     = pprTyCon      ss tyCon
> -ppr_ty_thing _  (ACoAxiom ax)      = pprCoAxiom    ax
> +-- NOTE: We pretty-print 'TyThing' via 'IfaceDecl' so that we can reuse
> the
> +-- 'TyCon' tidying happening in 'tyThingToIfaceDecl'. See #8776 for
> details.
> +ppr_ty_thing :: Maybe ShowSub -> TyThing -> SDoc
> +ppr_ty_thing mss tyThing = case tyThing of
> +    ATyCon tyCon -> case mss of
> +        Nothing -> pprTyConHdr tyCon
> +        Just ss -> pprTyCon ss tyCon
> +    _ -> ppr $ tyThingToIfaceDecl tyThing
>
>  pprTyConHdr :: TyCon -> SDoc
>  pprTyConHdr tyCon
> @@ -143,10 +136,6 @@ pprTyConHdr tyCon
>         | isAlgTyCon tyCon = pprThetaArrowTy (tyConStupidTheta tyCon)
>         | otherwise        = empty      -- Returns 'empty' if null theta
>
> -pprDataConSig :: DataCon -> SDoc
> -pprDataConSig dataCon
> -  = ppr_bndr dataCon <+> dcolon <+> pprTypeForUser (dataConUserType
> dataCon)
> -
>  pprClassHdr :: Class -> SDoc
>  pprClassHdr cls
>    = sdocWithDynFlags $ \dflags ->
> @@ -158,28 +147,6 @@ pprClassHdr cls
>    where
>       (tvs, funDeps) = classTvsFds cls
>
> -pprId :: Var -> SDoc
> -pprId ident
> -  = hang (ppr_bndr ident <+> dcolon)
> -        2 (pprTypeForUser (idType ident))
> -
> -pprPatSyn :: PatSyn -> SDoc
> -pprPatSyn patSyn
> -  = pprPatSynSig ident is_bidir args (pprTypeForUser rhs_ty) prov req
> -  where
> -    ident = patSynId patSyn
> -    is_bidir = isJust $ patSynWrapper patSyn
> -
> -    args = fmap pprParendType (patSynTyDetails patSyn)
> -    prov = pprThetaOpt prov_theta
> -    req = pprThetaOpt req_theta
> -
> -    pprThetaOpt [] = Nothing
> -    pprThetaOpt theta = Just $ pprTheta theta
> -
> -    (_univ_tvs, _ex_tvs, (prov_theta, req_theta)) = patSynSig patSyn
> -    rhs_ty = patSynType patSyn
> -
>  pprTypeForUser :: Type -> SDoc
>  -- We do two things here.
>  -- a) We tidy the type, regardless
>
> _______________________________________________
> ghc-commits mailing list
> ghc-commits at haskell.org
> http://www.haskell.org/mailman/listinfo/ghc-commits
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/ghc-devs/attachments/20140313/d192b1e1/attachment-0001.html>

From fuuzetsu at fuuzetsu.co.uk  Thu Mar 13 20:17:01 2014
From: fuuzetsu at fuuzetsu.co.uk (Mateusz Kowalczyk)
Date: Thu, 13 Mar 2014 20:17:01 +0000
Subject: New validate failures
In-Reply-To: <CAK-tuPbn5y7KDSZuct2TwSnHwJWZ=dSzoPmS4BsQdLA--Q9M4Q@mail.gmail.com>
References: <CAK-tuPbn5y7KDSZuct2TwSnHwJWZ=dSzoPmS4BsQdLA--Q9M4Q@mail.gmail.com>
Message-ID: <5322123D.9050508@fuuzetsu.co.uk>

On 13/03/14 20:13, Johan Tibell wrote:
> Hi,
> 
> Did something change in pretty-printing recently? I saw these new validate
> failures today:
> 
> Unexpected failures:
>    ghci.debugger/scripts  break008 [bad stdout] (ghci)
>    ghci.debugger/scripts  break012 [bad stdout] (ghci)
>    ghci.debugger/scripts  break026 [bad stdout] (ghci)
>    ghci.debugger/scripts  hist001 [bad stdout] (ghci)
>    ghci/scripts           T5545 [bad stdout] (ghci)
>    ghci/scripts           ghci008 [bad stdout] (ghci)
>    ghci/scripts           ghci012 [bad stdout] (ghci)
>    ghci/scripts           ghci023 [bad stdout] (ghci)
>    ghci/scripts           ghci025 [bad stdout] (ghci)
>    ghci/scripts           ghci026 [bad stdout] (ghci)
>    ghci/scripts           ghci055 [bad stdout] (ghci)
> 
> Two example stdout changes:
> 
> --- ./T5545.stdout 2014-03-13 09:48:23.000000000 +0100
> +++ ./T5545.run.stdout 2014-03-13 21:11:32.000000000 +0100
> @@ -1,2 +1,2 @@
> -($!) :: (a -> b) -> a -> b -- Defined in 'Prelude'
> +$! :: forall a b. (a -> b) -> a -> b -- Defined in 'Prelude'
>  infixr 0 $!
> *** unexpected failure for T5545(ghci)
> 
> --- ./ghci008.stdout 2014-03-13 09:48:23.000000000 +0100
> +++ ./ghci008.run.stdout 2014-03-13 21:12:20.000000000 +0100
> @@ -32,5 +32,5 @@
>     -- Defined in 'GHC.Float'
>  instance RealFloat Float -- Defined in 'GHC.Float'
>  instance RealFloat Double -- Defined in 'GHC.Float'
> -Data.List.isPrefixOf :: Eq a => [a] -> [a] -> Bool
> +isPrefixOf :: forall a. Eq a -> [a] -> [a] -> Bool
>     -- Defined in 'Data.List'
> *** unexpected failure for ghci008(ghci)
> 
> 
> 
> _______________________________________________
> ghc-devs mailing list
> ghc-devs at haskell.org
> http://www.haskell.org/mailman/listinfo/ghc-devs
> 

Perhaps
https://ghc.haskell.org/trac/ghc/changeset/24eea38c70eae90d166de26d71a178fb0c1ffc30/ghc
has something to do with it. AFAIK it's part of
https://ghc.haskell.org/trac/ghc/ticket/8776

-- 
Mateusz K.

From austin at well-typed.com  Thu Mar 13 20:22:43 2014
From: austin at well-typed.com (Austin Seipp)
Date: Thu, 13 Mar 2014 15:22:43 -0500
Subject: Proposal: Partial Type Signatures
In-Reply-To: <5321A20B.40504@cs.kuleuven.be>
References: <532062AB.50108@cs.kuleuven.be>
 <CAJumaK8P8hvWOnjFcid4HeucsrXiCjAG7RYfLw-H9=rQVyTGug@mail.gmail.com>
 <A2DD78C8-8E2A-4F09-8BC2-CEB087BD5DBE@me.com>
 <59543203684B2244980D7E4057D5FBC1487E5513@DB3EX14MBXC306.europe.corp.microsoft.com>
 <CAK-hX0keV-CeO2kSx158Z0s+23_p3eL6oK1dw3+7vBe0GbJ3AA@mail.gmail.com>
 <CAEs96n2FyvRLQ0TcXb_wDbc7bmAnz3mNNo8O1oDDkmsTGjCj3w@mail.gmail.com>
 <5321A20B.40504@cs.kuleuven.be>
Message-ID: <CAEs96n3RUBc2s6UBM7pSS2xa1qkN7QkfyDYRodJjZ26aKTeS9Q@mail.gmail.com>

On Thu, Mar 13, 2014 at 7:18 AM, Thomas Winant
<thomas.winant at cs.kuleuven.be> wrote:
> However, we have the impression that no Hole should remain unfilled,
> whereas using a partial type signature doesn't necessarily mean the
> program is incomplete. A partial type signature can still be a
> (stylistic) choice.

Yes, this is the main hold up I was thinking of. Thinking about it a
little more, one way to resolve it perhaps would be to do something
similar to we did to typed holes at the term level: make 'holes' at
the type level an error by default, which when encountered spit out
the error containing the type each hole was instantiated to, and what
the partial type signatures would be inferred as. Then, if you enable
-XPartialTypeSignatures, these would cease to be errors providing the
compiler can infer the types sensibly (and it wouldn't alert you in
that case).

That might be a half baked idea (I just sat here for about 5 minutes),
but either way I say again I do support -XPartialTypeSignatures
anyway, and it sounds like a step in the right direction. :)

-- 
Regards,

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

From johan.tibell at gmail.com  Thu Mar 13 20:39:00 2014
From: johan.tibell at gmail.com (Johan Tibell)
Date: Thu, 13 Mar 2014 21:39:00 +0100
Subject: Should we always inline newByteArray#?
Message-ID: <CAK-tuPao+6nm2swJtitC-XcZrx+narpoHmAdX_3CAPxNwWugjg@mail.gmail.com>

Hi all,

After some refactoring of the StgCmmPrim, it's now possible to have both an
inline and an out-of-line (in PrimOps.cmm) version of the same primop. Very
soon (#8876) we'll have both an inline and an out-of-line version of
newByteArray#. The inline version is used when the array size is statically
known and commons up the allocation with the normal heap check.

The reason to have both versions is that we don't want to increase code
size to much (by inlining a primop which implementation is large) unless we
know that there's a benefit in doing so. However, the newByteArray#
implementation is one function call (to allocate) followed by three stores
(to the closure header). Perhaps, that's small enough to always inline? It
would save one function call for each call to newByteArray#.

Anyone have any thoughts on whether always inlining would be a good idea?

-- Johan
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/ghc-devs/attachments/20140313/41962f37/attachment.html>

From eir at cis.upenn.edu  Thu Mar 13 20:56:06 2014
From: eir at cis.upenn.edu (Richard Eisenberg)
Date: Thu, 13 Mar 2014 16:56:06 -0400
Subject: Proposal: Partial Type Signatures
In-Reply-To: <CAEs96n3RUBc2s6UBM7pSS2xa1qkN7QkfyDYRodJjZ26aKTeS9Q@mail.gmail.com>
References: <532062AB.50108@cs.kuleuven.be>
 <CAJumaK8P8hvWOnjFcid4HeucsrXiCjAG7RYfLw-H9=rQVyTGug@mail.gmail.com>
 <A2DD78C8-8E2A-4F09-8BC2-CEB087BD5DBE@me.com>
 <59543203684B2244980D7E4057D5FBC1487E5513@DB3EX14MBXC306.europe.corp.microsoft.com>
 <CAK-hX0keV-CeO2kSx158Z0s+23_p3eL6oK1dw3+7vBe0GbJ3AA@mail.gmail.com>
 <CAEs96n2FyvRLQ0TcXb_wDbc7bmAnz3mNNo8O1oDDkmsTGjCj3w@mail.gmail.com>
 <5321A20B.40504@cs.kuleuven.be>
 <CAEs96n3RUBc2s6UBM7pSS2xa1qkN7QkfyDYRodJjZ26aKTeS9Q@mail.gmail.com>
Message-ID: <F390775B-C13C-4EBF-B3A2-AD68D2E9B411@cis.upenn.edu>

First of all: Yay! I've been wanting this for some time. I'm sorry I missed your presentation at PADL about this.

I, personally, rather like the design. There may be fine points of discussion as it all becomes reality, but I think this is a great approach -- much like what I've envisioned whenever thinking about the problem.

I would allow _ only as a constraint extension and _a in a constraint only when it also appears in the mono-type. I think, contrary to the wiki page, that the scope of named wildcards should mirror the behavior of normal type variables. Yes, it's weird that scoped type variables don't work by default, but I think it's weirder still if some scoped type-variable-like things work and others don't. I don't imagine that this fine control is hard to implement.

I think Austin's suggestion below is equally great. Just has 7.8 will now report informative errors when _ is used in an expression position, the implementation for partial type signatures can easily spit out informative errors when _ is used in a type. This would not be an extension, because it does not change the set of programs that compile nor the behavior of compiled programs. However, if a user specifies -XPartialTypeSignatures, then the errors are not reported -- the inferred type is simply used.

Thanks so much for doing this!

Richard

On Mar 13, 2014, at 4:22 PM, Austin Seipp wrote:

> On Thu, Mar 13, 2014 at 7:18 AM, Thomas Winant
> <thomas.winant at cs.kuleuven.be> wrote:
>> However, we have the impression that no Hole should remain unfilled,
>> whereas using a partial type signature doesn't necessarily mean the
>> program is incomplete. A partial type signature can still be a
>> (stylistic) choice.
> 
> Yes, this is the main hold up I was thinking of. Thinking about it a
> little more, one way to resolve it perhaps would be to do something
> similar to we did to typed holes at the term level: make 'holes' at
> the type level an error by default, which when encountered spit out
> the error containing the type each hole was instantiated to, and what
> the partial type signatures would be inferred as. Then, if you enable
> -XPartialTypeSignatures, these would cease to be errors providing the
> compiler can infer the types sensibly (and it wouldn't alert you in
> that case).
> 
> That might be a half baked idea (I just sat here for about 5 minutes),
> but either way I say again I do support -XPartialTypeSignatures
> anyway, and it sounds like a step in the right direction. :)
> 
> -- 
> Regards,
> 
> Austin Seipp, Haskell Consultant
> Well-Typed LLP, http://www.well-typed.com/
> _______________________________________________
> ghc-devs mailing list
> ghc-devs at haskell.org
> http://www.haskell.org/mailman/listinfo/ghc-devs


From marlowsd at gmail.com  Thu Mar 13 21:24:39 2014
From: marlowsd at gmail.com (Simon Marlow)
Date: Thu, 13 Mar 2014 21:24:39 +0000
Subject: Should we always inline newByteArray#?
In-Reply-To: <CAK-tuPao+6nm2swJtitC-XcZrx+narpoHmAdX_3CAPxNwWugjg@mail.gmail.com>
References: <CAK-tuPao+6nm2swJtitC-XcZrx+narpoHmAdX_3CAPxNwWugjg@mail.gmail.com>
Message-ID: <53222217.5020103@gmail.com>

On 13/03/14 20:39, Johan Tibell wrote:
> Hi all,
>
> After some refactoring of the StgCmmPrim, it's now possible to have both
> an inline and an out-of-line (in PrimOps.cmm) version of the same
> primop. Very soon (#8876) we'll have both an inline and an out-of-line
> version of newByteArray#. The inline version is used when the array size
> is statically known and commons up the allocation with the normal heap
> check.
>
> The reason to have both versions is that we don't want to increase code
> size to much (by inlining a primop which implementation is large) unless
> we know that there's a benefit in doing so. However, the newByteArray#
> implementation is one function call (to allocate) followed by three
> stores (to the closure header). Perhaps, that's small enough to always
> inline? It would save one function call for each call to newByteArray#.
>
> Anyone have any thoughts on whether always inlining would be a good idea?

It's a bad idea for large arrays (>= 3k), because when allocated via 
allocate() these arrays get a blocked marked with BF_LARGE that doesn't 
get copied during GC.

It might be a good idea for arrays less than this size (including the 
header).  It's a bad idea if the size isn't statically known, though.

Cheers,
Simon



From ekmett at gmail.com  Thu Mar 13 21:34:08 2014
From: ekmett at gmail.com (Edward Kmett)
Date: Thu, 13 Mar 2014 17:34:08 -0400
Subject: Proposal: Partial Type Signatures
In-Reply-To: <F390775B-C13C-4EBF-B3A2-AD68D2E9B411@cis.upenn.edu>
References: <532062AB.50108@cs.kuleuven.be>
 <CAJumaK8P8hvWOnjFcid4HeucsrXiCjAG7RYfLw-H9=rQVyTGug@mail.gmail.com>
 <A2DD78C8-8E2A-4F09-8BC2-CEB087BD5DBE@me.com>
 <59543203684B2244980D7E4057D5FBC1487E5513@DB3EX14MBXC306.europe.corp.microsoft.com>
 <CAK-hX0keV-CeO2kSx158Z0s+23_p3eL6oK1dw3+7vBe0GbJ3AA@mail.gmail.com>
 <CAEs96n2FyvRLQ0TcXb_wDbc7bmAnz3mNNo8O1oDDkmsTGjCj3w@mail.gmail.com>
 <5321A20B.40504@cs.kuleuven.be>
 <CAEs96n3RUBc2s6UBM7pSS2xa1qkN7QkfyDYRodJjZ26aKTeS9Q@mail.gmail.com>
 <F390775B-C13C-4EBF-B3A2-AD68D2E9B411@cis.upenn.edu>
Message-ID: <CAJumaK-+JcTK81dYP9qexCXdNiY+xrGHNLiqdqvnd9EtFnDeJg@mail.gmail.com>

I'd just like to echo that I really like Austin's suggestion as well, as it
very nicely unifies the two usecases, while simultaneously *not *dramatically
increasing scope.

-Edward


On Thu, Mar 13, 2014 at 4:56 PM, Richard Eisenberg <eir at cis.upenn.edu>wrote:

> First of all: Yay! I've been wanting this for some time. I'm sorry I
> missed your presentation at PADL about this.
>
> I, personally, rather like the design. There may be fine points of
> discussion as it all becomes reality, but I think this is a great approach
> -- much like what I've envisioned whenever thinking about the problem.
>
> I would allow _ only as a constraint extension and _a in a constraint only
> when it also appears in the mono-type. I think, contrary to the wiki page,
> that the scope of named wildcards should mirror the behavior of normal type
> variables. Yes, it's weird that scoped type variables don't work by
> default, but I think it's weirder still if some scoped type-variable-like
> things work and others don't. I don't imagine that this fine control is
> hard to implement.
>
> I think Austin's suggestion below is equally great. Just has 7.8 will now
> report informative errors when _ is used in an expression position, the
> implementation for partial type signatures can easily spit out informative
> errors when _ is used in a type. This would not be an extension, because it
> does not change the set of programs that compile nor the behavior of
> compiled programs. However, if a user specifies -XPartialTypeSignatures,
> then the errors are not reported -- the inferred type is simply used.
>
> Thanks so much for doing this!
>
> Richard
>
> On Mar 13, 2014, at 4:22 PM, Austin Seipp wrote:
>
> > On Thu, Mar 13, 2014 at 7:18 AM, Thomas Winant
> > <thomas.winant at cs.kuleuven.be> wrote:
> >> However, we have the impression that no Hole should remain unfilled,
> >> whereas using a partial type signature doesn't necessarily mean the
> >> program is incomplete. A partial type signature can still be a
> >> (stylistic) choice.
> >
> > Yes, this is the main hold up I was thinking of. Thinking about it a
> > little more, one way to resolve it perhaps would be to do something
> > similar to we did to typed holes at the term level: make 'holes' at
> > the type level an error by default, which when encountered spit out
> > the error containing the type each hole was instantiated to, and what
> > the partial type signatures would be inferred as. Then, if you enable
> > -XPartialTypeSignatures, these would cease to be errors providing the
> > compiler can infer the types sensibly (and it wouldn't alert you in
> > that case).
> >
> > That might be a half baked idea (I just sat here for about 5 minutes),
> > but either way I say again I do support -XPartialTypeSignatures
> > anyway, and it sounds like a step in the right direction. :)
> >
> > --
> > Regards,
> >
> > Austin Seipp, Haskell Consultant
> > Well-Typed LLP, http://www.well-typed.com/
> > _______________________________________________
> > ghc-devs mailing list
> > ghc-devs at haskell.org
> > http://www.haskell.org/mailman/listinfo/ghc-devs
>
> _______________________________________________
> ghc-devs mailing list
> ghc-devs at haskell.org
> http://www.haskell.org/mailman/listinfo/ghc-devs
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/ghc-devs/attachments/20140313/3f0602cf/attachment-0001.html>

From johan.tibell at gmail.com  Thu Mar 13 21:36:09 2014
From: johan.tibell at gmail.com (Johan Tibell)
Date: Thu, 13 Mar 2014 22:36:09 +0100
Subject: Should we always inline newByteArray#?
In-Reply-To: <53222217.5020103@gmail.com>
References: <CAK-tuPao+6nm2swJtitC-XcZrx+narpoHmAdX_3CAPxNwWugjg@mail.gmail.com>
 <53222217.5020103@gmail.com>
Message-ID: <CAK-tuPYrHxtRmtJTGrm+=Skz26OKvC4Ti9B7OoS32PU4hN_KrQ@mail.gmail.com>

On Thu, Mar 13, 2014 at 10:24 PM, Simon Marlow <marlowsd at gmail.com> wrote:
>
> It's a bad idea for large arrays (>= 3k), because when allocated via
> allocate() these arrays get a blocked marked with BF_LARGE that doesn't get
> copied during GC.
>
> It might be a good idea for arrays less than this size (including the
> header).  It's a bad idea if the size isn't statically known, though.
>

Sorry for not being clear. We will only do the inline *allocation* if the
size <= 128 bytes. I'm talking about always inlining the *code* (whether it
contains a call to allocate or not). In one case we will inline a
definition reusing the heap check. In the other case we will inline a
definition that calls allocate.

-- Johan
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/ghc-devs/attachments/20140313/518147ab/attachment.html>

From nicolas.frisby at gmail.com  Thu Mar 13 21:36:54 2014
From: nicolas.frisby at gmail.com (Nicolas Frisby)
Date: Thu, 13 Mar 2014 16:36:54 -0500
Subject: Arrow notation vs RebindableSyntax
Message-ID: <CADfHYo6iTr+GWqpz2nKGQ6vO4ZkZ7f09_Ln+LQ+9CAkVmoPzXw@mail.gmail.com>

The 7.8-rc2 User Guide for rebindable syntax includes:

Arrow notation (see Section 7.16, "Arrow notation ") uses whatever arr,
> (>>>), first, app, (|||) and loop functions are in scope. But unlike the
> other constructs, the types of these functions must match the Prelude types
> very closely. Details are in flux; if you want to use this, ask!


I want to use this: my types for the functions apparently do not match the
Prelude types closely enough.

Whom should I ask about this?

Thanks very much.

-Nick

----- Further Context

If I do something similar with Monad and RebindableSyntax, it type-checks.

I'm doing some experimentation for work. I'd like to index my arrows as
follows.

(Disclaimer: I have not yet considered any of the laws; I do not currently
intend to support `app' and |||.)

infixr 1 >>>, <<<

type family (:*:) (i :: Maybe *) (j :: Maybe *) :: Maybe *
type instance Nothing :*: j = j
type instance i :*: Nothing = i
type instance Just i :*: Just j = Just (i,j)

returnA :: IArrow arr => arr Nothing a a
 returnA = arr id

-- second, ***, and &&& can have the standard default definitions

class IArrow (arr :: Maybe * -> * -> * -> *) where
    arr :: (b -> c) -> arr Nothing b c
    (>>>) :: arr i a b -> arr j b c -> arr (i :*: j) a c
    first :: arr i b c -> arr i (b,d) (c,d)

Unfortunately, the following does not type-check with -XArrows and
-XRebindableSyntax.

diagram :: IArrow arr => arr f x fx -> arr g x gx -> arr (f :*: g) x gx
diagram f g = proc x -> do
  fx <- f -< x
  gx <- g -< x
  returnA -< gx

The error messages indicate that the type-checker is attempting to unify
the types of f, g, returnA, and the entire proc block.

However, the copy-and-pasted desugaring of that code *does* type-check (mutatis
mutandi).

This S data type is an example of an IArrow.

data S i a b where
  SN ::      ( a    ->  b   ) -> S Nothing  a b
  SJ :: s -> ((a,s) -> (b,s)) -> S (Just s) a b

In terms of the S type, the objective of IArrow is to allow each "box in
the diagram" to have its own state.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/ghc-devs/attachments/20140313/69b04496/attachment.html>

From marlowsd at gmail.com  Thu Mar 13 21:42:03 2014
From: marlowsd at gmail.com (Simon Marlow)
Date: Thu, 13 Mar 2014 21:42:03 +0000
Subject: Should we always inline newByteArray#?
In-Reply-To: <CAK-tuPYrHxtRmtJTGrm+=Skz26OKvC4Ti9B7OoS32PU4hN_KrQ@mail.gmail.com>
References: <CAK-tuPao+6nm2swJtitC-XcZrx+narpoHmAdX_3CAPxNwWugjg@mail.gmail.com>
 <53222217.5020103@gmail.com>
 <CAK-tuPYrHxtRmtJTGrm+=Skz26OKvC4Ti9B7OoS32PU4hN_KrQ@mail.gmail.com>
Message-ID: <5322262B.102@gmail.com>

On 13/03/14 21:36, Johan Tibell wrote:
> On Thu, Mar 13, 2014 at 10:24 PM, Simon Marlow <marlowsd at gmail.com
> <mailto:marlowsd at gmail.com>> wrote:
>
>     It's a bad idea for large arrays (>= 3k), because when allocated via
>     allocate() these arrays get a blocked marked with BF_LARGE that
>     doesn't get copied during GC.
>
>     It might be a good idea for arrays less than this size (including
>     the header).  It's a bad idea if the size isn't statically known,
>     though.
>
>
> Sorry for not being clear. We will only do the inline *allocation* if
> the size <= 128 bytes. I'm talking about always inlining the *code*
> (whether it contains a call to allocate or not). In one case we will
> inline a definition reusing the heap check. In the other case we will
> inline a definition that calls allocate.

Oh I see, sorry for misunderstanding.  In that case it's a 
straightforward code size / speed tradeoff.  When a similar case came up 
recently (PAP optimisations) I turned it on for -O2 only.  Someday I'd 
really like to have a -Os that would allow us a bit more control over 
decisions like this.

Cheers,
Simon


From johan.tibell at gmail.com  Thu Mar 13 21:46:59 2014
From: johan.tibell at gmail.com (Johan Tibell)
Date: Thu, 13 Mar 2014 22:46:59 +0100
Subject: Should we always inline newByteArray#?
In-Reply-To: <5322262B.102@gmail.com>
References: <CAK-tuPao+6nm2swJtitC-XcZrx+narpoHmAdX_3CAPxNwWugjg@mail.gmail.com>
 <53222217.5020103@gmail.com>
 <CAK-tuPYrHxtRmtJTGrm+=Skz26OKvC4Ti9B7OoS32PU4hN_KrQ@mail.gmail.com>
 <5322262B.102@gmail.com>
Message-ID: <CAK-tuPbNebO-pFci3FwdwWKW8RdkA4vFKj46GgONGA8gK32uag@mail.gmail.com>

On Thu, Mar 13, 2014 at 10:42 PM, Simon Marlow <marlowsd at gmail.com> wrote:
>
> Oh I see, sorry for misunderstanding.  In that case it's a straightforward
> code size / speed tradeoff.  When a similar case came up recently (PAP
> optimisations) I turned it on for -O2 only.  Someday I'd really like to
> have a -Os that would allow us a bit more control over decisions like this.
>

I will do the same and inline with -O2 only.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/ghc-devs/attachments/20140313/0408f282/attachment.html>

From carter.schonwald at gmail.com  Thu Mar 13 21:47:19 2014
From: carter.schonwald at gmail.com (Carter Schonwald)
Date: Thu, 13 Mar 2014 17:47:19 -0400
Subject: Proposal: Partial Type Signatures
In-Reply-To: <CAJumaK-+JcTK81dYP9qexCXdNiY+xrGHNLiqdqvnd9EtFnDeJg@mail.gmail.com>
References: <532062AB.50108@cs.kuleuven.be>
 <CAJumaK8P8hvWOnjFcid4HeucsrXiCjAG7RYfLw-H9=rQVyTGug@mail.gmail.com>
 <A2DD78C8-8E2A-4F09-8BC2-CEB087BD5DBE@me.com>
 <59543203684B2244980D7E4057D5FBC1487E5513@DB3EX14MBXC306.europe.corp.microsoft.com>
 <CAK-hX0keV-CeO2kSx158Z0s+23_p3eL6oK1dw3+7vBe0GbJ3AA@mail.gmail.com>
 <CAEs96n2FyvRLQ0TcXb_wDbc7bmAnz3mNNo8O1oDDkmsTGjCj3w@mail.gmail.com>
 <5321A20B.40504@cs.kuleuven.be>
 <CAEs96n3RUBc2s6UBM7pSS2xa1qkN7QkfyDYRodJjZ26aKTeS9Q@mail.gmail.com>
 <F390775B-C13C-4EBF-B3A2-AD68D2E9B411@cis.upenn.edu>
 <CAJumaK-+JcTK81dYP9qexCXdNiY+xrGHNLiqdqvnd9EtFnDeJg@mail.gmail.com>
Message-ID: <CAHYVw0ybc6LYB-mWtN9b8Xmae=dsurbMzM0KHvO0ePfG42o+VA@mail.gmail.com>

i'd like to echo the echo  of agreement :)


On Thu, Mar 13, 2014 at 5:34 PM, Edward Kmett <ekmett at gmail.com> wrote:

> I'd just like to echo that I really like Austin's suggestion as well, as
> it very nicely unifies the two usecases, while simultaneously *not *dramatically
> increasing scope.
>
> -Edward
>
>
> On Thu, Mar 13, 2014 at 4:56 PM, Richard Eisenberg <eir at cis.upenn.edu>wrote:
>
>> First of all: Yay! I've been wanting this for some time. I'm sorry I
>> missed your presentation at PADL about this.
>>
>> I, personally, rather like the design. There may be fine points of
>> discussion as it all becomes reality, but I think this is a great approach
>> -- much like what I've envisioned whenever thinking about the problem.
>>
>> I would allow _ only as a constraint extension and _a in a constraint
>> only when it also appears in the mono-type. I think, contrary to the wiki
>> page, that the scope of named wildcards should mirror the behavior of
>> normal type variables. Yes, it's weird that scoped type variables don't
>> work by default, but I think it's weirder still if some scoped
>> type-variable-like things work and others don't. I don't imagine that this
>> fine control is hard to implement.
>>
>> I think Austin's suggestion below is equally great. Just has 7.8 will now
>> report informative errors when _ is used in an expression position, the
>> implementation for partial type signatures can easily spit out informative
>> errors when _ is used in a type. This would not be an extension, because it
>> does not change the set of programs that compile nor the behavior of
>> compiled programs. However, if a user specifies -XPartialTypeSignatures,
>> then the errors are not reported -- the inferred type is simply used.
>>
>> Thanks so much for doing this!
>>
>> Richard
>>
>> On Mar 13, 2014, at 4:22 PM, Austin Seipp wrote:
>>
>> > On Thu, Mar 13, 2014 at 7:18 AM, Thomas Winant
>> > <thomas.winant at cs.kuleuven.be> wrote:
>> >> However, we have the impression that no Hole should remain unfilled,
>> >> whereas using a partial type signature doesn't necessarily mean the
>> >> program is incomplete. A partial type signature can still be a
>> >> (stylistic) choice.
>> >
>> > Yes, this is the main hold up I was thinking of. Thinking about it a
>> > little more, one way to resolve it perhaps would be to do something
>> > similar to we did to typed holes at the term level: make 'holes' at
>> > the type level an error by default, which when encountered spit out
>> > the error containing the type each hole was instantiated to, and what
>> > the partial type signatures would be inferred as. Then, if you enable
>> > -XPartialTypeSignatures, these would cease to be errors providing the
>> > compiler can infer the types sensibly (and it wouldn't alert you in
>> > that case).
>> >
>> > That might be a half baked idea (I just sat here for about 5 minutes),
>> > but either way I say again I do support -XPartialTypeSignatures
>> > anyway, and it sounds like a step in the right direction. :)
>> >
>> > --
>> > Regards,
>> >
>> > Austin Seipp, Haskell Consultant
>> > Well-Typed LLP, http://www.well-typed.com/
>> > _______________________________________________
>> > ghc-devs mailing list
>> > ghc-devs at haskell.org
>> > http://www.haskell.org/mailman/listinfo/ghc-devs
>>
>> _______________________________________________
>> ghc-devs mailing list
>> ghc-devs at haskell.org
>> http://www.haskell.org/mailman/listinfo/ghc-devs
>>
>
>
> _______________________________________________
> ghc-devs mailing list
> ghc-devs at haskell.org
> http://www.haskell.org/mailman/listinfo/ghc-devs
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/ghc-devs/attachments/20140313/ae3d097c/attachment-0001.html>

From gergo at erdi.hu  Thu Mar 13 22:52:32 2014
From: gergo at erdi.hu (=?UTF-8?B?RHIuIMOJUkRJIEdlcmfFkQ==?=)
Date: Fri, 14 Mar 2014 06:52:32 +0800
Subject: [commit: ghc] master: Pretty-print the following TyThings via
 their IfaceDecl counterpart: * AnId * ACoAxiom * AConLike (065c35a)
In-Reply-To: <CAK-tuPZSNQE9EV0tWTZ-oFWnnLwYPwXH8Db1A45PNjboa7cBMQ@mail.gmail.com>
References: <20140313132145.1D9472406B@ghc.haskell.org>
 <CAK-tuPZSNQE9EV0tWTZ-oFWnnLwYPwXH8Db1A45PNjboa7cBMQ@mail.gmail.com>
Message-ID: <CAO7EwMqmsGvMjmPoweWFVqD7Rh14NGpAyZn8A4UOEg2Sd7nTzw@mail.gmail.com>

Yes:-(

I'll unbreak them later today.
On Mar 14, 2014 4:16 AM, "Johan Tibell" <johan.tibell at gmail.com> wrote:

> Could these changes be related to the validate failures I just posted
> about on the mailing list?
>
>
> On Thu, Mar 13, 2014 at 2:21 PM, <git at git.haskell.org> wrote:
>
>> Repository : ssh://git at git.haskell.org/ghc
>>
>> On branch  : master
>> Link       :
>> http://ghc.haskell.org/trac/ghc/changeset/065c35a9d6d48060c8fac8d755833349ce58b35b/ghc
>>
>> >---------------------------------------------------------------
>>
>> commit 065c35a9d6d48060c8fac8d755833349ce58b35b
>> Author: Dr. ERDI Gergo <gergo at erdi.hu>
>> Date:   Thu Mar 13 21:18:39 2014 +0800
>>
>>     Pretty-print the following TyThings via their IfaceDecl counterpart:
>>      * AnId
>>      * ACoAxiom
>>      * AConLike
>>
>>
>> >---------------------------------------------------------------
>>
>> 065c35a9d6d48060c8fac8d755833349ce58b35b
>>  compiler/iface/IfaceSyn.lhs |    2 +-
>>  compiler/iface/MkIface.lhs  |   10 +++++++-
>>  compiler/main/PprTyThing.hs |   59
>> ++++++++++---------------------------------
>>  3 files changed, 23 insertions(+), 48 deletions(-)
>>
>> diff --git a/compiler/iface/IfaceSyn.lhs b/compiler/iface/IfaceSyn.lhs
>> index 8ca8582..7484b37 100644
>> --- a/compiler/iface/IfaceSyn.lhs
>> +++ b/compiler/iface/IfaceSyn.lhs
>> @@ -1100,7 +1100,7 @@ pprIfaceDecl (IfaceClass {ifCtxt = context, ifName
>> = clas, ifTyVars = tyvars,
>>                  sep (map ppr sigs)])
>>
>>  pprIfaceDecl (IfaceAxiom {ifName = name, ifTyCon = tycon, ifAxBranches =
>> branches })
>> -  = hang (ptext (sLit "axiom") <+> ppr name <> colon)
>> +  = hang (ptext (sLit "axiom") <+> ppr name <> dcolon)
>>         2 (vcat $ map (pprAxBranch $ Just tycon) branches)
>>
>>  pprIfaceDecl (IfacePatSyn { ifName = name, ifPatHasWrapper = has_wrap,
>> diff --git a/compiler/iface/MkIface.lhs b/compiler/iface/MkIface.lhs
>> index 0af9af6..51df08c 100644
>> --- a/compiler/iface/MkIface.lhs
>> +++ b/compiler/iface/MkIface.lhs
>> @@ -1461,7 +1461,7 @@ tyThingToIfaceDecl (AnId id)      = idToIfaceDecl id
>>  tyThingToIfaceDecl (ATyCon tycon) = tyConToIfaceDecl emptyTidyEnv tycon
>>  tyThingToIfaceDecl (ACoAxiom ax)  = coAxiomToIfaceDecl ax
>>  tyThingToIfaceDecl (AConLike cl)  = case cl of
>> -    RealDataCon dc -> pprPanic "toIfaceDecl" (ppr dc) -- Should be
>> trimmed out earlier
>> +    RealDataCon dc -> dataConToIfaceDecl dc -- for ppr purposes only
>>      PatSynCon ps   -> patSynToIfaceDecl ps
>>
>>  --------------------------
>> @@ -1477,6 +1477,14 @@ idToIfaceDecl id
>>                ifIdInfo    = toIfaceIdInfo (idInfo id) }
>>
>>  --------------------------
>> +dataConToIfaceDecl :: DataCon -> IfaceDecl
>> +dataConToIfaceDecl dataCon
>> +  = IfaceId { ifName      = getOccName dataCon,
>> +              ifType      = toIfaceType (dataConUserType dataCon),
>> +              ifIdDetails = IfVanillaId,
>> +              ifIdInfo    = NoInfo }
>> +
>> +--------------------------
>>  patSynToIfaceDecl :: PatSyn -> IfaceDecl
>>  patSynToIfaceDecl ps
>>    = IfacePatSyn { ifName          = getOccName . getName $ ps
>> diff --git a/compiler/main/PprTyThing.hs b/compiler/main/PprTyThing.hs
>> index 27e7390..fb92b5a 100644
>> --- a/compiler/main/PprTyThing.hs
>> +++ b/compiler/main/PprTyThing.hs
>> @@ -23,20 +23,18 @@ module PprTyThing (
>>    ) where
>>
>>  import TypeRep ( TyThing(..) )
>> -import ConLike
>>  import DataCon
>> -import PatSyn
>>  import Id
>>  import TyCon
>>  import Class
>> -import Coercion( pprCoAxiom, pprCoAxBranch )
>> +import Coercion( pprCoAxBranch )
>>  import CoAxiom( CoAxiom(..), brListMap )
>>  import HscTypes( tyThingParent_maybe )
>> -import HsBinds( pprPatSynSig )
>>  import Type( tidyTopType, tidyOpenType, splitForAllTys, funResultTy )
>>  import Kind( synTyConResKind )
>>  import TypeRep( pprTvBndrs, pprForAll, suppressKinds )
>>  import TysPrim( alphaTyVars )
>> +import MkIface ( tyThingToIfaceDecl )
>>  import TcType
>>  import Name
>>  import VarEnv( emptyTidyEnv )
>> @@ -44,7 +42,6 @@ import StaticFlags( opt_PprStyle_Debug )
>>  import DynFlags
>>  import Outputable
>>  import FastString
>> -import Data.Maybe
>>
>>  --
>> -----------------------------------------------------------------------------
>>  -- Pretty-printing entities that we get from the GHC API
>> @@ -76,7 +73,7 @@ pprTyThingLoc tyThing
>>
>>  -- | Pretty-prints a 'TyThing'.
>>  pprTyThing :: TyThing -> SDoc
>> -pprTyThing thing = ppr_ty_thing showAll thing
>> +pprTyThing thing = ppr_ty_thing (Just showAll) thing
>>
>>  -- | Pretty-prints a 'TyThing' in context: that is, if the entity
>>  -- is a data constructor, record selector, or class method, then
>> @@ -88,7 +85,7 @@ pprTyThingInContext thing
>>    where
>>      go ss thing = case tyThingParent_maybe thing of
>>                      Just parent -> go (getName thing : ss) parent
>> -                    Nothing     -> ppr_ty_thing ss thing
>> +                    Nothing     -> ppr_ty_thing (Just ss) thing
>>
>>  -- | Like 'pprTyThingInContext', but adds the defining location.
>>  pprTyThingInContextLoc :: TyThing -> SDoc
>> @@ -100,21 +97,17 @@ pprTyThingInContextLoc tyThing
>>  -- the function is equivalent to 'pprTyThing' but for type constructors
>>  -- and classes it prints only the header part of the declaration.
>>  pprTyThingHdr :: TyThing -> SDoc
>> -pprTyThingHdr (AnId id)          = pprId         id
>> -pprTyThingHdr (AConLike conLike) = case conLike of
>> -    RealDataCon dataCon -> pprDataConSig dataCon
>> -    PatSynCon patSyn    -> pprPatSyn     patSyn
>> -pprTyThingHdr (ATyCon tyCon)     = pprTyConHdr   tyCon
>> -pprTyThingHdr (ACoAxiom ax)      = pprCoAxiom ax
>> +pprTyThingHdr = ppr_ty_thing Nothing
>>
>>  ------------------------
>> -ppr_ty_thing :: ShowSub -> TyThing -> SDoc
>> -ppr_ty_thing _  (AnId id)          = pprId         id
>> -ppr_ty_thing _  (AConLike conLike) = case conLike of
>> -    RealDataCon dataCon -> pprDataConSig dataCon
>> -    PatSynCon patSyn    -> pprPatSyn     patSyn
>> -ppr_ty_thing ss (ATyCon tyCon)     = pprTyCon      ss tyCon
>> -ppr_ty_thing _  (ACoAxiom ax)      = pprCoAxiom    ax
>> +-- NOTE: We pretty-print 'TyThing' via 'IfaceDecl' so that we can reuse
>> the
>> +-- 'TyCon' tidying happening in 'tyThingToIfaceDecl'. See #8776 for
>> details.
>> +ppr_ty_thing :: Maybe ShowSub -> TyThing -> SDoc
>> +ppr_ty_thing mss tyThing = case tyThing of
>> +    ATyCon tyCon -> case mss of
>> +        Nothing -> pprTyConHdr tyCon
>> +        Just ss -> pprTyCon ss tyCon
>> +    _ -> ppr $ tyThingToIfaceDecl tyThing
>>
>>  pprTyConHdr :: TyCon -> SDoc
>>  pprTyConHdr tyCon
>> @@ -143,10 +136,6 @@ pprTyConHdr tyCon
>>         | isAlgTyCon tyCon = pprThetaArrowTy (tyConStupidTheta tyCon)
>>         | otherwise        = empty      -- Returns 'empty' if null theta
>>
>> -pprDataConSig :: DataCon -> SDoc
>> -pprDataConSig dataCon
>> -  = ppr_bndr dataCon <+> dcolon <+> pprTypeForUser (dataConUserType
>> dataCon)
>> -
>>  pprClassHdr :: Class -> SDoc
>>  pprClassHdr cls
>>    = sdocWithDynFlags $ \dflags ->
>> @@ -158,28 +147,6 @@ pprClassHdr cls
>>    where
>>       (tvs, funDeps) = classTvsFds cls
>>
>> -pprId :: Var -> SDoc
>> -pprId ident
>> -  = hang (ppr_bndr ident <+> dcolon)
>> -        2 (pprTypeForUser (idType ident))
>> -
>> -pprPatSyn :: PatSyn -> SDoc
>> -pprPatSyn patSyn
>> -  = pprPatSynSig ident is_bidir args (pprTypeForUser rhs_ty) prov req
>> -  where
>> -    ident = patSynId patSyn
>> -    is_bidir = isJust $ patSynWrapper patSyn
>> -
>> -    args = fmap pprParendType (patSynTyDetails patSyn)
>> -    prov = pprThetaOpt prov_theta
>> -    req = pprThetaOpt req_theta
>> -
>> -    pprThetaOpt [] = Nothing
>> -    pprThetaOpt theta = Just $ pprTheta theta
>> -
>> -    (_univ_tvs, _ex_tvs, (prov_theta, req_theta)) = patSynSig patSyn
>> -    rhs_ty = patSynType patSyn
>> -
>>  pprTypeForUser :: Type -> SDoc
>>  -- We do two things here.
>>  -- a) We tidy the type, regardless
>>
>> _______________________________________________
>> ghc-commits mailing list
>> ghc-commits at haskell.org
>> http://www.haskell.org/mailman/listinfo/ghc-commits
>>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/ghc-devs/attachments/20140314/d25bd3f1/attachment.html>

From mail at joachim-breitner.de  Fri Mar 14 08:34:45 2014
From: mail at joachim-breitner.de (Joachim Breitner)
Date: Fri, 14 Mar 2014 09:34:45 +0100
Subject: New validate failures
In-Reply-To: <CAK-tuPbn5y7KDSZuct2TwSnHwJWZ=dSzoPmS4BsQdLA--Q9M4Q@mail.gmail.com>
References: <CAK-tuPbn5y7KDSZuct2TwSnHwJWZ=dSzoPmS4BsQdLA--Q9M4Q@mail.gmail.com>
Message-ID: <1394786085.3576.1.camel@kirk>

Hi,

Am Donnerstag, den 13.03.2014, 21:13 +0100 schrieb Johan Tibell:

> Did something change in pretty-printing recently? I saw these new
> validate failures today:
> 
> 
> Unexpected failures:
>    ghci.debugger/scripts  break008 [bad stdout] (ghci)
>    ghci.debugger/scripts  break012 [bad stdout] (ghci)
>    ghci.debugger/scripts  break026 [bad stdout] (ghci)
>    ghci.debugger/scripts  hist001 [bad stdout] (ghci)
>    ghci/scripts           T5545 [bad stdout] (ghci)
>    ghci/scripts           ghci008 [bad stdout] (ghci)
>    ghci/scripts           ghci012 [bad stdout] (ghci)
>    ghci/scripts           ghci023 [bad stdout] (ghci)
>    ghci/scripts           ghci025 [bad stdout] (ghci)
>    ghci/scripts           ghci026 [bad stdout] (ghci)
>    ghci/scripts           ghci055 [bad stdout] (ghci)


confirmed by travis, according to
https://travis-ci.org/nomeata/ghc-complete/builds
the breaking change was one of

        commit 065c35a9d6d48060c8fac8d755833349ce58b35b
        Author: Dr. ERDI Gergo <gergo at erdi.hu>
        Date: Thu Mar 13 21:18:39 2014 +0800
        
        Pretty-print the following TyThings via their IfaceDecl
        counterpart:
        * AnId
        * ACoAxiom
        * AConLike
        
        commit 24eea38c70eae90d166de26d71a178fb0c1ffc30
        Author: Dr. ERDI Gergo <gergo at erdi.hu>
        Date: Wed Mar 12 20:38:54 2014 +0800
        
        pprIfaceDecl for IfacePatSyn: use pprPatSynSig
        
        commit 23c0f1ec2cf06c0178c2ae7414fe57ea648689e7
        Author: Dr. ERDI Gergo <gergo at erdi.hu>
        Date: Wed Mar 12 20:38:26 2014 +0800
        
        pprIfaceContextArr: print a context including the "=>" arrow
        
        commit 4d1b7b4a9b986e87755784478b4ea4883a5e203e
        Author: Dr. ERDI Gergo <gergo at erdi.hu>
        Date: Wed Mar 12 20:37:22 2014 +0800
        
        Add OutputableBndr instance for OccName


Gergo, can you have a look and fix that?

Thanks,
Joachim


-- 
Joachim ?nomeata? Breitner
  mail at joachim-breitner.de ? http://www.joachim-breitner.de/
  Jabber: nomeata at joachim-breitner.de  ? GPG-Key: 0x4743206C
  Debian Developer: nomeata at debian.org
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 181 bytes
Desc: This is a digitally signed message part
URL: <http://www.haskell.org/pipermail/ghc-devs/attachments/20140314/022f86ae/attachment.sig>

From mf at zerobuzz.net  Fri Mar 14 09:01:48 2014
From: mf at zerobuzz.net (Matthias Fischmann)
Date: Fri, 14 Mar 2014 10:01:48 +0100
Subject: haddock issue building ghc-7.8 from git
Message-ID: <20140314090148.GG13278@lig>


Hi,

When building from git (branch ghc-7.8 as of today), I run into a
haddock issue because __GLASGOW_HASKELL__ appearently is not 709 on my
system.  Not sure whether this is a bug, and if it should go to
trac/haddock or trac/ghc, so I decided to post it here.

My "fix" is easy enough (even though I ran into other problems later,
so I don't really know how well it works):

| ~/src/ghc/utils/haddock/src/Haddock$ git diff
| diff --git a/src/Haddock/InterfaceFile.hs b/src/Haddock/InterfaceFile.hs
| index 924829d..19a742f 100644
| --- a/src/Haddock/InterfaceFile.hs
| +++ b/src/Haddock/InterfaceFile.hs
| @@ -76,14 +76,14 @@ binaryInterfaceMagic = 0xD0Cface
|  -- (2) set `binaryInterfaceVersionCompatibility` to [binaryInterfaceVersion]
|  --
|  binaryInterfaceVersion :: Word16
| -#if __GLASGOW_HASKELL__ == 709
| +-- #if __GLASGOW_HASKELL__ == 709
|  binaryInterfaceVersion = 25
|
|  binaryInterfaceVersionCompatibility :: [Word16]
|  binaryInterfaceVersionCompatibility = [binaryInterfaceVersion]
| -#else
| -#error Unsupported GHC version
| -#endif
| +-- #else
| +-- #error Unsupported GHC version
| +-- #endif
|
|
|  initBinMemSize :: Int

thanks,
matthias

From fuuzetsu at fuuzetsu.co.uk  Fri Mar 14 09:29:46 2014
From: fuuzetsu at fuuzetsu.co.uk (Mateusz Kowalczyk)
Date: Fri, 14 Mar 2014 09:29:46 +0000
Subject: haddock issue building ghc-7.8 from git
In-Reply-To: <20140314090148.GG13278@lig>
References: <20140314090148.GG13278@lig>
Message-ID: <5322CC0A.3030707@fuuzetsu.co.uk>

On 14/03/14 09:01, Matthias Fischmann wrote:
> 
> Hi,
> 
> When building from git (branch ghc-7.8 as of today), I run into a
> haddock issue because __GLASGOW_HASKELL__ appearently is not 709 on my
> system.  Not sure whether this is a bug, and if it should go to
> trac/haddock or trac/ghc, so I decided to post it here.
> 
> My "fix" is easy enough (even though I ran into other problems later,
> so I don't really know how well it works):
> 
> | ~/src/ghc/utils/haddock/src/Haddock$ git diff
> | diff --git a/src/Haddock/InterfaceFile.hs b/src/Haddock/InterfaceFile.hs
> | index 924829d..19a742f 100644
> | --- a/src/Haddock/InterfaceFile.hs
> | +++ b/src/Haddock/InterfaceFile.hs
> | @@ -76,14 +76,14 @@ binaryInterfaceMagic = 0xD0Cface
> |  -- (2) set `binaryInterfaceVersionCompatibility` to [binaryInterfaceVersion]
> |  --
> |  binaryInterfaceVersion :: Word16
> | -#if __GLASGOW_HASKELL__ == 709
> | +-- #if __GLASGOW_HASKELL__ == 709
> |  binaryInterfaceVersion = 25
> |
> |  binaryInterfaceVersionCompatibility :: [Word16]
> |  binaryInterfaceVersionCompatibility = [binaryInterfaceVersion]
> | -#else
> | -#error Unsupported GHC version
> | -#endif
> | +-- #else
> | +-- #error Unsupported GHC version
> | +-- #endif
> |
> |
> |  initBinMemSize :: Int
> 
> thanks,
> matthias
> _______________________________________________
> ghc-devs mailing list
> ghc-devs at haskell.org
> http://www.haskell.org/mailman/listinfo/ghc-devs
> 

The master branch of Haddock has that test for a reason: anyone working
on Haddock will be doing so using GHC HEAD which is at 7.9. Haddock has
a separate branch (named ghc-7.8) which is the candidate that will go
into 7.8.

If you're building GHC 7.8, you should be on that branch for Haddock and
all the other libraries. IIRC you can pass some arguments to the
sync-all script which will do all the switching for you but I forgot
what it was. I'm sure someone else can chime in.

-- 
Mateusz K.

From simonpj at microsoft.com  Fri Mar 14 09:44:10 2014
From: simonpj at microsoft.com (Simon Peyton Jones)
Date: Fri, 14 Mar 2014 09:44:10 +0000
Subject: Proposal: Partial Type Signatures
In-Reply-To: <5322091D.6040109@cs.kuleuven.be>
References: <532062AB.50108@cs.kuleuven.be>
 <59543203684B2244980D7E4057D5FBC1487E771D@DB3EX14MBXC306.europe.corp.microsoft.com>
 <5322091D.6040109@cs.kuleuven.be>
Message-ID: <59543203684B2244980D7E4057D5FBC1487ED499@DB3EX14MBXC306.europe.corp.microsoft.com>

| Excellent, I added responses ("thomasw") to your comments on the wiki
| page.

OK, good. Better still, improve your wording so that no one could make the same mistake as I did, and delete both comments.

Simon

| -----Original Message-----
| From: Thomas Winant [mailto:thomas.winant at cs.kuleuven.be]
| Sent: 13 March 2014 19:38
| To: Simon Peyton Jones; ghc-devs at haskell.org
| Cc: Tom Schrijvers; Frank Piessens
| Subject: Re: Proposal: Partial Type Signatures
| 
| On 13-03-14 10:46, Simon Peyton Jones wrote:
| > | Together with Tom Schrijvers, Frank Piessens and Dominique Devriese,
| > | I have been working on a proposal for adding *Partial Type
| > | Signatures* to GHC.
| >
| > I'm all for this.  Yes, if the design and implementation are solid,
| I'd be happy to add it to the main branch.
| >
| > Do focus on something with excellent power-to-weight ratio: that is,
| gives a lot of benefit for a small cost, rather than something that
| gives 10% more benefit for 200% more cost.
| >
| > I've annotated the wiki page with some "SLPJ" comments, which you may
| want to look at.
| >
| > I'd be happy to have a Skype conversation about the details in due
| course.
| 
| Excellent, I added responses ("thomasw") to your comments on the wiki
| page.
| 
| Cheers,
| Thomas
| 
| 
| > | -----Original Message-----
| > | From: ghc-devs [mailto:ghc-devs-bounces at haskell.org] On Behalf Of
| > | Thomas Winant
| > | Sent: 12 March 2014 13:36
| > | To: ghc-devs at haskell.org
| > | Cc: Tom Schrijvers; Frank Piessens
| > | Subject: Proposal: Partial Type Signatures
| > |
| > | Dear GHC developers,
| > |
| > | Together with Tom Schrijvers, Frank Piessens and Dominique Devriese,
| > | I have been working on a proposal for adding *Partial Type
| > | Signatures* to GHC. In a partial type signature, annotated types can
| > | be mixed with inferred types. A type signature is written like
| > | before, but can now contain wildcards, written as underscores. The
| > | types of these wildcards or unknown types will be inferred by the
| type checker, e.g.
| > |
| > |      foo :: _ -> Bool
| > |      foo x = not x
| > |      -- Inferred: Bool -> Boo
| > |
| > | The proposal also includes a form of generalisation which aligns
| > | with the existing generalisation that GHC does. We have written down
| > | a motivation (when and how might you use this) and details about the
| > | design and implementation on the following wiki page:
| > |
| > | https://ghc.haskell.org/trac/ghc/wiki/PartialTypeSignatures
| > |
| > | We have a (work in progress) implementation [1] of the feature based
| > | on GHC. It currently implements most of what we propose, but there
| > | are some remaining important bugs mostly concerning the
| > | generalisation. We also described our design and presented a
| > | formalisation based on the
| > | OutsideIn(X) formalism in a paper [2] presented at PADL'14.
| > |
| > | What we are hoping to get from the people on this list is any of the
| > | below:
| > | * Read the design, play with the implementation and tell us any
| comments
| > |    you may have about the feature, its design and implementation.
| > | * Opinions on whether this feature might be acceptable in GHC
| upstream
| > |    at some point (if not, we do not think it's worth developing the
| > |    implementation much further).
| > | * Perhaps a code review or a discussion with someone more
| knowledgeable
| > |    about the internals of GHC's type checker about how we might fix
| the
| > |    remaining problems in our implementation (specifically, we could
| use
| > |    some help with implementing the generalisation of partial type
| > |    signatures).
| > | * Feedback on the `Questions and issues' section on the wiki page.
| > |
| > |
| > | Kind regards,
| > | Thomas Winant
| > |
| > | [1]: https://github.com/mrBliss/ghc-head/
| > | [2]:
| > | https://lirias.kuleuven.be/bitstream/123456789/423475/3/paper.pdf
| > |
| > |
| > | Disclaimer: http://www.kuleuven.be/cwis/email_disclaimer.htm
| > | _______________________________________________
| > | ghc-devs mailing list
| > | ghc-devs at haskell.org
| > | http://www.haskell.org/mailman/listinfo/ghc-devs
| >
| 
| Disclaimer: http://www.kuleuven.be/cwis/email_disclaimer.htm

From austin at well-typed.com  Fri Mar 14 09:45:12 2014
From: austin at well-typed.com (Austin Seipp)
Date: Fri, 14 Mar 2014 04:45:12 -0500
Subject: haddock issue building ghc-7.8 from git
In-Reply-To: <5322CC0A.3030707@fuuzetsu.co.uk>
References: <20140314090148.GG13278@lig>
	<5322CC0A.3030707@fuuzetsu.co.uk>
Message-ID: <CAEs96n375hc1C_z+SpfNTUQHHscgQYPmK=4=HXUm=PTW6k1HJw@mail.gmail.com>

You need to say:

$ git clone -b ghc-7.8 https://git.haskell.org/ghc ghc-7.8
$ cd ghc-7.8
$ ./sync-all -b ghc-7.8

That should do the trick and get you a clean, working repository
(sync-all is fiddly with checkout at the moment, if I remember
correctly).

On Fri, Mar 14, 2014 at 4:29 AM, Mateusz Kowalczyk
<fuuzetsu at fuuzetsu.co.uk> wrote:
> On 14/03/14 09:01, Matthias Fischmann wrote:
>>
>> Hi,
>>
>> When building from git (branch ghc-7.8 as of today), I run into a
>> haddock issue because __GLASGOW_HASKELL__ appearently is not 709 on my
>> system.  Not sure whether this is a bug, and if it should go to
>> trac/haddock or trac/ghc, so I decided to post it here.
>>
>> My "fix" is easy enough (even though I ran into other problems later,
>> so I don't really know how well it works):
>>
>> | ~/src/ghc/utils/haddock/src/Haddock$ git diff
>> | diff --git a/src/Haddock/InterfaceFile.hs b/src/Haddock/InterfaceFile.hs
>> | index 924829d..19a742f 100644
>> | --- a/src/Haddock/InterfaceFile.hs
>> | +++ b/src/Haddock/InterfaceFile.hs
>> | @@ -76,14 +76,14 @@ binaryInterfaceMagic = 0xD0Cface
>> |  -- (2) set `binaryInterfaceVersionCompatibility` to [binaryInterfaceVersion]
>> |  --
>> |  binaryInterfaceVersion :: Word16
>> | -#if __GLASGOW_HASKELL__ == 709
>> | +-- #if __GLASGOW_HASKELL__ == 709
>> |  binaryInterfaceVersion = 25
>> |
>> |  binaryInterfaceVersionCompatibility :: [Word16]
>> |  binaryInterfaceVersionCompatibility = [binaryInterfaceVersion]
>> | -#else
>> | -#error Unsupported GHC version
>> | -#endif
>> | +-- #else
>> | +-- #error Unsupported GHC version
>> | +-- #endif
>> |
>> |
>> |  initBinMemSize :: Int
>>
>> thanks,
>> matthias
>> _______________________________________________
>> ghc-devs mailing list
>> ghc-devs at haskell.org
>> http://www.haskell.org/mailman/listinfo/ghc-devs
>>
>
> The master branch of Haddock has that test for a reason: anyone working
> on Haddock will be doing so using GHC HEAD which is at 7.9. Haddock has
> a separate branch (named ghc-7.8) which is the candidate that will go
> into 7.8.
>
> If you're building GHC 7.8, you should be on that branch for Haddock and
> all the other libraries. IIRC you can pass some arguments to the
> sync-all script which will do all the switching for you but I forgot
> what it was. I'm sure someone else can chime in.
>
> --
> Mateusz K.
> _______________________________________________
> ghc-devs mailing list
> ghc-devs at haskell.org
> http://www.haskell.org/mailman/listinfo/ghc-devs
>



-- 
Regards,

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

From austin at well-typed.com  Fri Mar 14 09:45:58 2014
From: austin at well-typed.com (Austin Seipp)
Date: Fri, 14 Mar 2014 04:45:58 -0500
Subject: haddock issue building ghc-7.8 from git
In-Reply-To: <CAEs96n375hc1C_z+SpfNTUQHHscgQYPmK=4=HXUm=PTW6k1HJw@mail.gmail.com>
References: <20140314090148.GG13278@lig> <5322CC0A.3030707@fuuzetsu.co.uk>
 <CAEs96n375hc1C_z+SpfNTUQHHscgQYPmK=4=HXUm=PTW6k1HJw@mail.gmail.com>
Message-ID: <CAEs96n1voiGsWpBp0Y0-RbsVEXhjvGPMuHir+jZBOohcaaEwLw@mail.gmail.com>

Oh bother:

> $ ./sync-all -b ghc-7.8

Should be:

./sync-all -b ghc-7.8 get

of course.

On Fri, Mar 14, 2014 at 4:45 AM, Austin Seipp <austin at well-typed.com> wrote:
> You need to say:
>
> $ git clone -b ghc-7.8 https://git.haskell.org/ghc ghc-7.8
> $ cd ghc-7.8
> $ ./sync-all -b ghc-7.8
>
> That should do the trick and get you a clean, working repository
> (sync-all is fiddly with checkout at the moment, if I remember
> correctly).
>
> On Fri, Mar 14, 2014 at 4:29 AM, Mateusz Kowalczyk
> <fuuzetsu at fuuzetsu.co.uk> wrote:
>> On 14/03/14 09:01, Matthias Fischmann wrote:
>>>
>>> Hi,
>>>
>>> When building from git (branch ghc-7.8 as of today), I run into a
>>> haddock issue because __GLASGOW_HASKELL__ appearently is not 709 on my
>>> system.  Not sure whether this is a bug, and if it should go to
>>> trac/haddock or trac/ghc, so I decided to post it here.
>>>
>>> My "fix" is easy enough (even though I ran into other problems later,
>>> so I don't really know how well it works):
>>>
>>> | ~/src/ghc/utils/haddock/src/Haddock$ git diff
>>> | diff --git a/src/Haddock/InterfaceFile.hs b/src/Haddock/InterfaceFile.hs
>>> | index 924829d..19a742f 100644
>>> | --- a/src/Haddock/InterfaceFile.hs
>>> | +++ b/src/Haddock/InterfaceFile.hs
>>> | @@ -76,14 +76,14 @@ binaryInterfaceMagic = 0xD0Cface
>>> |  -- (2) set `binaryInterfaceVersionCompatibility` to [binaryInterfaceVersion]
>>> |  --
>>> |  binaryInterfaceVersion :: Word16
>>> | -#if __GLASGOW_HASKELL__ == 709
>>> | +-- #if __GLASGOW_HASKELL__ == 709
>>> |  binaryInterfaceVersion = 25
>>> |
>>> |  binaryInterfaceVersionCompatibility :: [Word16]
>>> |  binaryInterfaceVersionCompatibility = [binaryInterfaceVersion]
>>> | -#else
>>> | -#error Unsupported GHC version
>>> | -#endif
>>> | +-- #else
>>> | +-- #error Unsupported GHC version
>>> | +-- #endif
>>> |
>>> |
>>> |  initBinMemSize :: Int
>>>
>>> thanks,
>>> matthias
>>> _______________________________________________
>>> ghc-devs mailing list
>>> ghc-devs at haskell.org
>>> http://www.haskell.org/mailman/listinfo/ghc-devs
>>>
>>
>> The master branch of Haddock has that test for a reason: anyone working
>> on Haddock will be doing so using GHC HEAD which is at 7.9. Haddock has
>> a separate branch (named ghc-7.8) which is the candidate that will go
>> into 7.8.
>>
>> If you're building GHC 7.8, you should be on that branch for Haddock and
>> all the other libraries. IIRC you can pass some arguments to the
>> sync-all script which will do all the switching for you but I forgot
>> what it was. I'm sure someone else can chime in.
>>
>> --
>> Mateusz K.
>> _______________________________________________
>> ghc-devs mailing list
>> ghc-devs at haskell.org
>> http://www.haskell.org/mailman/listinfo/ghc-devs
>>
>
>
>
> --
> Regards,
>
> Austin Seipp, Haskell Consultant
> Well-Typed LLP, http://www.well-typed.com/



-- 
Regards,

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

From simonpj at microsoft.com  Fri Mar 14 09:46:17 2014
From: simonpj at microsoft.com (Simon Peyton Jones)
Date: Fri, 14 Mar 2014 09:46:17 +0000
Subject: Where to find GHC.Types.D#_con_info
In-Reply-To: <5321FDD5.7080104@centrum.cz>
References: <5321FDD5.7080104@centrum.cz>
Message-ID: <59543203684B2244980D7E4057D5FBC1487ED4EC@DB3EX14MBXC306.europe.corp.microsoft.com>

For every data constructor GHC generates an "info table", and its label is "C_con_info" I think.  The first word of the data constructor heap object points to the info table.

The info table has data that describes the object layout (for the GC), and a little piece of code that says simply "return", used if someone enters that object.

More details about info tables in many GHC papers

Simon

| -----Original Message-----
| From: ghc-devs [mailto:ghc-devs-bounces at haskell.org] On Behalf Of Karel
| Gardas
| Sent: 13 March 2014 18:50
| To: ghc-devs
| Subject: Where to find GHC.Types.D#_con_info
| 
| Hello,
| 
| I'm trying to debug few issues in SPARC NCG, now dealing with double
| floats issue. Always get 0.0 and while hunting this I've stepped over
| GHC.Types.D#_con_info which I'm not able to find in GHC sources but I
| guess it should be somewhere... Any idea where to look to see its code
| for reference?
| 
| Thanks!
| Karel
| _______________________________________________
| ghc-devs mailing list
| ghc-devs at haskell.org
| http://www.haskell.org/mailman/listinfo/ghc-devs

From mf at zerobuzz.net  Fri Mar 14 10:03:42 2014
From: mf at zerobuzz.net (Matthias Fischmann)
Date: Fri, 14 Mar 2014 11:03:42 +0100
Subject: haddock issue building ghc-7.8 from git
In-Reply-To: <CAEs96n1voiGsWpBp0Y0-RbsVEXhjvGPMuHir+jZBOohcaaEwLw@mail.gmail.com>
References: <20140314090148.GG13278@lig> <5322CC0A.3030707@fuuzetsu.co.uk>
 <CAEs96n375hc1C_z+SpfNTUQHHscgQYPmK=4=HXUm=PTW6k1HJw@mail.gmail.com>
 <CAEs96n1voiGsWpBp0Y0-RbsVEXhjvGPMuHir+jZBOohcaaEwLw@mail.gmail.com>
Message-ID: <20140314100342.GH13278@lig>


On Fri, Mar 14, 2014 at 04:45:58AM -0500, Austin Seipp wrote:
> Date: Fri, 14 Mar 2014 04:45:58 -0500
> From: Austin Seipp <austin at well-typed.com>
> To: "ghc-devs at haskell.org" <ghc-devs at haskell.org>
> Subject: Re: haddock issue building ghc-7.8 from git
>
> Oh bother:
>
> > $ ./sync-all -b ghc-7.8
>
> Should be:
>
> ./sync-all -b ghc-7.8 get
>
> of course.

ok, that makes a lot of sense.  (i was wondering about demanding version 709... :-)

now i get this:

[...]
~/src/ghc-7.8$ ./sync-all -b ghc-7.8 get
Unrecognised flag: -b at ./sync-all line 850.
== Checking for old haddock repo
== Checking for old binary repo
== Checking for old mtl repo
== Checking for old Cabal repo
== Checking for old time from tarball
============================
ATTENTION!

You have an old time package in your GHC tree!

Please remove it (e.g. "rm -r libraries/time"), and then run
"./sync-all get" to get the new repository.
============================
== Checking for obsolete Git repo URL
~/src/ghc-7.8$ rm -rf libraries/time/
~/src/ghc-7.8$ ./sync-all -b ghc-7.8 get
Unrecognised flag: -b at ./sync-all line 850.
== Checking for old haddock repo
== Checking for old binary repo
== Checking for old mtl repo
== Checking for old Cabal repo
== Checking for old time from tarball
== Checking for obsolete Git repo URL
~/src/ghc-7.8$ perl boot
Error: libffi-tarballs/LICENSE doesn't exist.
[...]

i also tried to pull with -b ghc-7.8, but sync-all doesn't do anything
in either case.

./sync-all get pull master (which i don't want, appearently).

'./sync-all checkout ghc-7.8' cannot find branch 7.8 on several repos.

(how easy would it be to implement exact version pinning in sync-all?
could i do it in a day or two?  would there be any drawbacks from
doing this?)

cheers,
matthias



> On Fri, Mar 14, 2014 at 4:45 AM, Austin Seipp <austin at well-typed.com> wrote:
> > You need to say:
> >
> > $ git clone -b ghc-7.8 https://git.haskell.org/ghc ghc-7.8
> > $ cd ghc-7.8
> > $ ./sync-all -b ghc-7.8
> >
> > That should do the trick and get you a clean, working repository
> > (sync-all is fiddly with checkout at the moment, if I remember
> > correctly).
> >
> > On Fri, Mar 14, 2014 at 4:29 AM, Mateusz Kowalczyk
> > <fuuzetsu at fuuzetsu.co.uk> wrote:
> >> On 14/03/14 09:01, Matthias Fischmann wrote:
> >>>
> >>> Hi,
> >>>
> >>> When building from git (branch ghc-7.8 as of today), I run into a
> >>> haddock issue because __GLASGOW_HASKELL__ appearently is not 709 on my
> >>> system.  Not sure whether this is a bug, and if it should go to
> >>> trac/haddock or trac/ghc, so I decided to post it here.
> >>>
> >>> My "fix" is easy enough (even though I ran into other problems later,
> >>> so I don't really know how well it works):
> >>>
> >>> | ~/src/ghc/utils/haddock/src/Haddock$ git diff
> >>> | diff --git a/src/Haddock/InterfaceFile.hs b/src/Haddock/InterfaceFile.hs
> >>> | index 924829d..19a742f 100644
> >>> | --- a/src/Haddock/InterfaceFile.hs
> >>> | +++ b/src/Haddock/InterfaceFile.hs
> >>> | @@ -76,14 +76,14 @@ binaryInterfaceMagic = 0xD0Cface
> >>> |  -- (2) set `binaryInterfaceVersionCompatibility` to [binaryInterfaceVersion]
> >>> |  --
> >>> |  binaryInterfaceVersion :: Word16
> >>> | -#if __GLASGOW_HASKELL__ == 709
> >>> | +-- #if __GLASGOW_HASKELL__ == 709
> >>> |  binaryInterfaceVersion = 25
> >>> |
> >>> |  binaryInterfaceVersionCompatibility :: [Word16]
> >>> |  binaryInterfaceVersionCompatibility = [binaryInterfaceVersion]
> >>> | -#else
> >>> | -#error Unsupported GHC version
> >>> | -#endif
> >>> | +-- #else
> >>> | +-- #error Unsupported GHC version
> >>> | +-- #endif
> >>> |
> >>> |
> >>> |  initBinMemSize :: Int
> >>>
> >>> thanks,
> >>> matthias
> >>> _______________________________________________
> >>> ghc-devs mailing list
> >>> ghc-devs at haskell.org
> >>> http://www.haskell.org/mailman/listinfo/ghc-devs
> >>>
> >>
> >> The master branch of Haddock has that test for a reason: anyone working
> >> on Haddock will be doing so using GHC HEAD which is at 7.9. Haddock has
> >> a separate branch (named ghc-7.8) which is the candidate that will go
> >> into 7.8.
> >>
> >> If you're building GHC 7.8, you should be on that branch for Haddock and
> >> all the other libraries. IIRC you can pass some arguments to the
> >> sync-all script which will do all the switching for you but I forgot
> >> what it was. I'm sure someone else can chime in.
> >>
> >> --
> >> Mateusz K.
> >> _______________________________________________
> >> ghc-devs mailing list
> >> ghc-devs at haskell.org
> >> http://www.haskell.org/mailman/listinfo/ghc-devs
> >>
> >
> >
> >
> > --
> > Regards,
> >
> > Austin Seipp, Haskell Consultant
> > Well-Typed LLP, http://www.well-typed.com/
>
>
>
> --
> Regards,
>
> Austin Seipp, Haskell Consultant
> Well-Typed LLP, http://www.well-typed.com/
> _______________________________________________
> ghc-devs mailing list
> ghc-devs at haskell.org
> http://www.haskell.org/mailman/listinfo/ghc-devs

From austin at well-typed.com  Fri Mar 14 10:08:35 2014
From: austin at well-typed.com (Austin Seipp)
Date: Fri, 14 Mar 2014 05:08:35 -0500
Subject: haddock issue building ghc-7.8 from git
In-Reply-To: <20140314100342.GH13278@lig>
References: <20140314090148.GG13278@lig> <5322CC0A.3030707@fuuzetsu.co.uk>
 <CAEs96n375hc1C_z+SpfNTUQHHscgQYPmK=4=HXUm=PTW6k1HJw@mail.gmail.com>
 <CAEs96n1voiGsWpBp0Y0-RbsVEXhjvGPMuHir+jZBOohcaaEwLw@mail.gmail.com>
 <20140314100342.GH13278@lig>
Message-ID: <CAEs96n3BW_OSpe51nj=5N2_XE7dpegpFkMOLYR+91zkSnwj92w@mail.gmail.com>

My goodness am I clumsy sometimes :(

It's actually:

$ git clone -b ghc-7.8 https://git.haskell.org/ghc ghc-7.8
$ cd ghc-7.8
$ ./sync-all get -b ghc-7.8

I messed up the -b argument. Again. :(

As a rule, sync-all for 'get' will take 'git' arguments, so the 'get
-b' translates to 'git clone -b ghc-7.8 ...'

Also, yes, there are already fingerprints. See the source code here:
https://github.com/nomeata/ghc-complete/tree/ghc-7.8 - Note
specifically it is on the 7.8 branch. Also see:

https://ghc.haskell.org/trac/ghc/wiki/Building/GettingTheSources#Trackingthefullrepositorystate

to use the fingerprint utility.

Urgh. Sorry again!

On Fri, Mar 14, 2014 at 5:03 AM, Matthias Fischmann <mf at zerobuzz.net> wrote:
>
> On Fri, Mar 14, 2014 at 04:45:58AM -0500, Austin Seipp wrote:
>> Date: Fri, 14 Mar 2014 04:45:58 -0500
>> From: Austin Seipp <austin at well-typed.com>
>> To: "ghc-devs at haskell.org" <ghc-devs at haskell.org>
>> Subject: Re: haddock issue building ghc-7.8 from git
>>
>> Oh bother:
>>
>> > $ ./sync-all -b ghc-7.8
>>
>> Should be:
>>
>> ./sync-all -b ghc-7.8 get
>>
>> of course.
>
> ok, that makes a lot of sense.  (i was wondering about demanding version 709... :-)
>
> now i get this:
>
> [...]
> ~/src/ghc-7.8$ ./sync-all -b ghc-7.8 get
> Unrecognised flag: -b at ./sync-all line 850.
> == Checking for old haddock repo
> == Checking for old binary repo
> == Checking for old mtl repo
> == Checking for old Cabal repo
> == Checking for old time from tarball
> ============================
> ATTENTION!
>
> You have an old time package in your GHC tree!
>
> Please remove it (e.g. "rm -r libraries/time"), and then run
> "./sync-all get" to get the new repository.
> ============================
> == Checking for obsolete Git repo URL
> ~/src/ghc-7.8$ rm -rf libraries/time/
> ~/src/ghc-7.8$ ./sync-all -b ghc-7.8 get
> Unrecognised flag: -b at ./sync-all line 850.
> == Checking for old haddock repo
> == Checking for old binary repo
> == Checking for old mtl repo
> == Checking for old Cabal repo
> == Checking for old time from tarball
> == Checking for obsolete Git repo URL
> ~/src/ghc-7.8$ perl boot
> Error: libffi-tarballs/LICENSE doesn't exist.
> [...]
>
> i also tried to pull with -b ghc-7.8, but sync-all doesn't do anything
> in either case.
>
> ./sync-all get pull master (which i don't want, appearently).
>
> './sync-all checkout ghc-7.8' cannot find branch 7.8 on several repos.
>
> (how easy would it be to implement exact version pinning in sync-all?
> could i do it in a day or two?  would there be any drawbacks from
> doing this?)
>
> cheers,
> matthias
>
>
>
>> On Fri, Mar 14, 2014 at 4:45 AM, Austin Seipp <austin at well-typed.com> wrote:
>> > You need to say:
>> >
>> > $ git clone -b ghc-7.8 https://git.haskell.org/ghc ghc-7.8
>> > $ cd ghc-7.8
>> > $ ./sync-all -b ghc-7.8
>> >
>> > That should do the trick and get you a clean, working repository
>> > (sync-all is fiddly with checkout at the moment, if I remember
>> > correctly).
>> >
>> > On Fri, Mar 14, 2014 at 4:29 AM, Mateusz Kowalczyk
>> > <fuuzetsu at fuuzetsu.co.uk> wrote:
>> >> On 14/03/14 09:01, Matthias Fischmann wrote:
>> >>>
>> >>> Hi,
>> >>>
>> >>> When building from git (branch ghc-7.8 as of today), I run into a
>> >>> haddock issue because __GLASGOW_HASKELL__ appearently is not 709 on my
>> >>> system.  Not sure whether this is a bug, and if it should go to
>> >>> trac/haddock or trac/ghc, so I decided to post it here.
>> >>>
>> >>> My "fix" is easy enough (even though I ran into other problems later,
>> >>> so I don't really know how well it works):
>> >>>
>> >>> | ~/src/ghc/utils/haddock/src/Haddock$ git diff
>> >>> | diff --git a/src/Haddock/InterfaceFile.hs b/src/Haddock/InterfaceFile.hs
>> >>> | index 924829d..19a742f 100644
>> >>> | --- a/src/Haddock/InterfaceFile.hs
>> >>> | +++ b/src/Haddock/InterfaceFile.hs
>> >>> | @@ -76,14 +76,14 @@ binaryInterfaceMagic = 0xD0Cface
>> >>> |  -- (2) set `binaryInterfaceVersionCompatibility` to [binaryInterfaceVersion]
>> >>> |  --
>> >>> |  binaryInterfaceVersion :: Word16
>> >>> | -#if __GLASGOW_HASKELL__ == 709
>> >>> | +-- #if __GLASGOW_HASKELL__ == 709
>> >>> |  binaryInterfaceVersion = 25
>> >>> |
>> >>> |  binaryInterfaceVersionCompatibility :: [Word16]
>> >>> |  binaryInterfaceVersionCompatibility = [binaryInterfaceVersion]
>> >>> | -#else
>> >>> | -#error Unsupported GHC version
>> >>> | -#endif
>> >>> | +-- #else
>> >>> | +-- #error Unsupported GHC version
>> >>> | +-- #endif
>> >>> |
>> >>> |
>> >>> |  initBinMemSize :: Int
>> >>>
>> >>> thanks,
>> >>> matthias
>> >>> _______________________________________________
>> >>> ghc-devs mailing list
>> >>> ghc-devs at haskell.org
>> >>> http://www.haskell.org/mailman/listinfo/ghc-devs
>> >>>
>> >>
>> >> The master branch of Haddock has that test for a reason: anyone working
>> >> on Haddock will be doing so using GHC HEAD which is at 7.9. Haddock has
>> >> a separate branch (named ghc-7.8) which is the candidate that will go
>> >> into 7.8.
>> >>
>> >> If you're building GHC 7.8, you should be on that branch for Haddock and
>> >> all the other libraries. IIRC you can pass some arguments to the
>> >> sync-all script which will do all the switching for you but I forgot
>> >> what it was. I'm sure someone else can chime in.
>> >>
>> >> --
>> >> Mateusz K.
>> >> _______________________________________________
>> >> ghc-devs mailing list
>> >> ghc-devs at haskell.org
>> >> http://www.haskell.org/mailman/listinfo/ghc-devs
>> >>
>> >
>> >
>> >
>> > --
>> > Regards,
>> >
>> > Austin Seipp, Haskell Consultant
>> > Well-Typed LLP, http://www.well-typed.com/
>>
>>
>>
>> --
>> Regards,
>>
>> Austin Seipp, Haskell Consultant
>> Well-Typed LLP, http://www.well-typed.com/
>> _______________________________________________
>> ghc-devs mailing list
>> ghc-devs at haskell.org
>> http://www.haskell.org/mailman/listinfo/ghc-devs
>



-- 
Regards,

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

From mf at zerobuzz.net  Fri Mar 14 10:25:01 2014
From: mf at zerobuzz.net (Matthias Fischmann)
Date: Fri, 14 Mar 2014 11:25:01 +0100
Subject: testing ghc-7.8 rc2: linker issues
Message-ID: <20140314102501.GJ13278@lig>


hi,

this time i am running 7.8 rc2 (binary for x64 on debian testing).
after a successful '/usr/bin/cabal install cabal-install', i am
running into different instances of this:

| [...]
| [25 of 25] Compiling Text.ParserCombinators.Parsec.Perm ( Text/ParserCombinators/Parsec/Perm.hs, dist/build/Text/ParserCombinators/Parsec/Perm.o )
| /usr/bin/ld: cannot find -lHSmtl-2.1.2-ghc7.8.0.20140228
| collect2: error: ld returned 1 exit status
| Failed to install parsec-3.1.5
| cabal: Error: some packages failed to install:
| network-2.4.2.2 depends on parsec-3.1.5 which failed to install.
| parsec-3.1.5 failed during the building phase. The exception was:
| ExitFailure 1

what makes me suspect this could be relevant to this list is that the
symptoms are weirdly sporadic.  my story:

1. cabal install string-conversions fails because -lHStext-1.1.0.1
   cannot be found.

2. ghc-pkg unregister <a few packages>

3. cabal install network (which pulls text) => fails (see above)

4. cabal install string-conversions => works!

i will read up on dynamic linking in ghc now.


cheers,
matthias

From mf at zerobuzz.net  Fri Mar 14 10:42:25 2014
From: mf at zerobuzz.net (Matthias Fischmann)
Date: Fri, 14 Mar 2014 11:42:25 +0100
Subject: haddock issue building ghc-7.8 from git
In-Reply-To: <CAEs96n3BW_OSpe51nj=5N2_XE7dpegpFkMOLYR+91zkSnwj92w@mail.gmail.com>
References: <20140314090148.GG13278@lig> <5322CC0A.3030707@fuuzetsu.co.uk>
 <CAEs96n375hc1C_z+SpfNTUQHHscgQYPmK=4=HXUm=PTW6k1HJw@mail.gmail.com>
 <CAEs96n1voiGsWpBp0Y0-RbsVEXhjvGPMuHir+jZBOohcaaEwLw@mail.gmail.com>
 <20140314100342.GH13278@lig>
 <CAEs96n3BW_OSpe51nj=5N2_XE7dpegpFkMOLYR+91zkSnwj92w@mail.gmail.com>
Message-ID: <20140314104225.GK13278@lig>


On Fri, Mar 14, 2014 at 05:08:35AM -0500, Austin Seipp wrote:
> Date: Fri, 14 Mar 2014 05:08:35 -0500
> From: Austin Seipp <austin at well-typed.com>
> To: Matthias Fischmann <mf at zerobuzz.net>
> Cc: Austin Seipp <austin at well-typed.com>, "ghc-devs at haskell.org"
>  <ghc-devs at haskell.org>
> Subject: Re: haddock issue building ghc-7.8 from git
>
> My goodness am I clumsy sometimes :(

i bet you i'm clumsier :)


> It's actually:
>
> $ git clone -b ghc-7.8 https://git.haskell.org/ghc ghc-7.8
> $ cd ghc-7.8
> $ ./sync-all get -b ghc-7.8

ok, that works.  i had to ^C and re-try a number of times due to
connect timeouts (i think there is a thread about this on this list a
few days back), but now it's compiling smoothly, and the sub-repos are
all on branch 7.8.

also thanks for the fingerprint hint.

cheers,
matthias

From shumovichy at gmail.com  Fri Mar 14 11:50:39 2014
From: shumovichy at gmail.com (Yuras Shumovich)
Date: Fri, 14 Mar 2014 14:50:39 +0300
Subject: FFI: c/c++ struct on stack as an argument or return value
Message-ID: <1394797839.4664.35.camel@shum-lt>


Hi,

Right now ghc's FFI doesn't support c/c++ structures.

Whenever we have foreign function that accepts or returns struct by
value, we have to create wrapper that accepts or returns pointer to
struct. It is inconvenient, but actually not a big deal.

But there is no easy workaround when you want to export haskell function
to use it with c/c++ API that requires structures to be passed by value
(Usually it is a callback in c/c++ API. You can't change it's signature,
and if it doesn't provide some kind of "void* userdata", then you are
stuck.)

I'm interested in fixing that. I'm going to start with 'foreign import
"wrapper" ...' stuff.

Calling conventions for passing c/c++ structures by value are pretty
tricky and platform/compiler specific. So initially I'll use libffi for
that (it will work when USE_LIBFFI_FOR_ADJUSTORS is defined, see
rts/Adjustor.c). It will allow me to explore design space without
bothering about low level implementation details. Later it could be
implemented for native (non-libffi) adjustors.

Is anybody interested it that? I appreciate any comments/ideas.

Right now I don't have clear design. It would be nice to support plain
haskell data types that are 1) not recursive, 2) has one constructor and
3) contains only c/c++ types. But it doesn't work with c/c++ unions. Any
ideas are welcome.

An example how to use libffi with structures:
http://www.atmark-techno.com/~yashi/libffi.html#Structures

Thanks,
Yuras



From carter.schonwald at gmail.com  Fri Mar 14 12:35:21 2014
From: carter.schonwald at gmail.com (Carter Schonwald)
Date: Fri, 14 Mar 2014 08:35:21 -0400
Subject: testing ghc-7.8 rc2: linker issues
In-Reply-To: <20140314102501.GJ13278@lig>
References: <20140314102501.GJ13278@lig>
Message-ID: <CAHYVw0ykra7VwmsHyRi5oOwJAFaHb07BRdZQmaDX1rES_m3tAg@mail.gmail.com>

Make sure you are building the dynamic / shared lib versions and using
cabal install 1.18

On Friday, March 14, 2014, Matthias Fischmann <mf at zerobuzz.net> wrote:

>
> hi,
>
> this time i am running 7.8 rc2 (binary for x64 on debian testing).
> after a successful '/usr/bin/cabal install cabal-install', i am
> running into different instances of this:
>
> | [...]
> | [25 of 25] Compiling Text.ParserCombinators.Parsec.Perm (
> Text/ParserCombinators/Parsec/Perm.hs,
> dist/build/Text/ParserCombinators/Parsec/Perm.o )
> | /usr/bin/ld: cannot find -lHSmtl-2.1.2-ghc7.8.0.20140228
> | collect2: error: ld returned 1 exit status
> | Failed to install parsec-3.1.5
> | cabal: Error: some packages failed to install:
> | network-2.4.2.2 depends on parsec-3.1.5 which failed to install.
> | parsec-3.1.5 failed during the building phase. The exception was:
> | ExitFailure 1
>
> what makes me suspect this could be relevant to this list is that the
> symptoms are weirdly sporadic.  my story:
>
> 1. cabal install string-conversions fails because -lHStext-1.1.0.1
>    cannot be found.
>
> 2. ghc-pkg unregister <a few packages>
>
> 3. cabal install network (which pulls text) => fails (see above)
>
> 4. cabal install string-conversions => works!
>
> i will read up on dynamic linking in ghc now.
>
>
> cheers,
> matthias
> _______________________________________________
> ghc-devs mailing list
> ghc-devs at haskell.org <javascript:;>
> http://www.haskell.org/mailman/listinfo/ghc-devs
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/ghc-devs/attachments/20140314/1983e66c/attachment.html>

From ekmett at gmail.com  Fri Mar 14 13:08:41 2014
From: ekmett at gmail.com (Edward Kmett)
Date: Fri, 14 Mar 2014 09:08:41 -0400
Subject: FFI: c/c++ struct on stack as an argument or return value
In-Reply-To: <1394797839.4664.35.camel@shum-lt>
References: <1394797839.4664.35.camel@shum-lt>
Message-ID: <CAJumaK-CiOesyRYDYJe0SVES=2Pba-eUvM3sQ93jjUJwZU22Jw@mail.gmail.com>

I spent some time hacking around on this from a library perspective when I
had to interoperate with a bunch of Objective C on a 64-bit mac as many of
the core library functions you need to FFI out to pass around pairs of Int32s
as a struct small enough by the x64 ABI to get shoehorned into one
register, and as I was programmatically cloning Objective C APIs via
template haskell I couldn't use the usual clunky C shims.

What I was doing was just using libffi with a lot of work to cache the
results of ffi_prep_cif for each signature.

It worked reasonably well for my purposes, but my need for it vanished and
I abandoned the code in the middle of refactoring it for grander things.

So if nothing else, you can at least take this as a vote of confidence that
your idea isn't crazy. =)

I'd also be happy to answer questions if you get stuck or need help.

-Edward


On Fri, Mar 14, 2014 at 7:50 AM, Yuras Shumovich <shumovichy at gmail.com>wrote:

>
> Hi,
>
> Right now ghc's FFI doesn't support c/c++ structures.
>
> Whenever we have foreign function that accepts or returns struct by
> value, we have to create wrapper that accepts or returns pointer to
> struct. It is inconvenient, but actually not a big deal.
>
> But there is no easy workaround when you want to export haskell function
> to use it with c/c++ API that requires structures to be passed by value
> (Usually it is a callback in c/c++ API. You can't change it's signature,
> and if it doesn't provide some kind of "void* userdata", then you are
> stuck.)
>
> I'm interested in fixing that. I'm going to start with 'foreign import
> "wrapper" ...' stuff.
>
> Calling conventions for passing c/c++ structures by value are pretty
> tricky and platform/compiler specific. So initially I'll use libffi for
> that (it will work when USE_LIBFFI_FOR_ADJUSTORS is defined, see
> rts/Adjustor.c). It will allow me to explore design space without
> bothering about low level implementation details. Later it could be
> implemented for native (non-libffi) adjustors.
>
> Is anybody interested it that? I appreciate any comments/ideas.
>
> Right now I don't have clear design. It would be nice to support plain
> haskell data types that are 1) not recursive, 2) has one constructor and
> 3) contains only c/c++ types. But it doesn't work with c/c++ unions. Any
> ideas are welcome.
>
> An example how to use libffi with structures:
> http://www.atmark-techno.com/~yashi/libffi.html#Structures
>
> Thanks,
> Yuras
>
>
> _______________________________________________
> ghc-devs mailing list
> ghc-devs at haskell.org
> http://www.haskell.org/mailman/listinfo/ghc-devs
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/ghc-devs/attachments/20140314/ae3924aa/attachment.html>

From petersen at fedoraproject.org  Fri Mar 14 14:07:15 2014
From: petersen at fedoraproject.org (Jens Petersen)
Date: Fri, 14 Mar 2014 23:07:15 +0900
Subject: RC2 release imminent
In-Reply-To: <CAEDGBqKmPEjQqEPnat4=iUzLzavOr5nYe0_wotDHbde=K5V0OA@mail.gmail.com>
References: <CAEs96n2j0oyvTeYecrgdfHsJgzCRexz=LTf8smta9UQSONbd5w@mail.gmail.com>
 <CAHnG2CwkfT2+16+W0Z=C8xabtRXW6vmpf7n_X7N9+Zt6vbL8yw@mail.gmail.com>
 <CAK-hX0=N-sDjQPy8VY+qwgndvR5B+qMVJZja1=mVT=YcWyhqpg@mail.gmail.com>
 <CAHnG2CyPf4bsMtY1Bm5sRjgbaCC4wYeBj6TBQqBjdkB_HkOo_g@mail.gmail.com>
 <CAEs96n3X1NUY0OmpsjGgM+t2HYxx1VOkDb9X0vED2zwDeu7qpA@mail.gmail.com>
 <CAEDGBqLRsXbARK=o1D-MYfxkiaQ_sjipNimQYHpXSNcHZkwbow@mail.gmail.com>
 <CAEs96n0CTG7EqMGDNu0P3V1Od-AskB8zAdU8XdnfDMnCPiEqSQ@mail.gmail.com>
 <CAEDGBqKmPEjQqEPnat4=iUzLzavOr5nYe0_wotDHbde=K5V0OA@mail.gmail.com>
Message-ID: <CAEDGBqJekHsA7XDgsxt_qFCkmk6NEh_T=pBdfZaQrH_h98ESFQ@mail.gmail.com>

On 2 March 2014 22:23, Jens Petersen <juhpetersen at gmail.com> wrote:

> New source distributions are available here:
>> http://www.haskell.org/ghc/dist/7.8.1-rc2/
>
>  :

> I have done a couple of testbuilds:
> http://koji.fedoraproject.org/koji/taskinfo?taskID=6586630 (built against
> ghc-7.6.3)
> and a build in my Fedora Copr ghc-7.8 repo for Fedora 20
> http://copr.fedoraproject.org/coprs/petersen/ghc-7.8/ (against the
> original RC2)
>

I did a test build on Fedora Rawhide s390/s390x too:

http://s390.koji.fedoraproject.org/koji/taskinfo?taskID=1364690

A test build on ppc completed but then the dyn executable sanity check
failed (not yet sure why):
http://ppc.koji.fedoraproject.org/koji/taskinfo?taskID=1707922
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/ghc-devs/attachments/20140314/2abba7bc/attachment.html>

From thomas.winant at cs.kuleuven.be  Fri Mar 14 15:11:43 2014
From: thomas.winant at cs.kuleuven.be (Thomas Winant)
Date: Fri, 14 Mar 2014 16:11:43 +0100
Subject: Proposal: Partial Type Signatures
In-Reply-To: <F390775B-C13C-4EBF-B3A2-AD68D2E9B411@cis.upenn.edu>
References: <532062AB.50108@cs.kuleuven.be>
 <CAJumaK8P8hvWOnjFcid4HeucsrXiCjAG7RYfLw-H9=rQVyTGug@mail.gmail.com>
 <A2DD78C8-8E2A-4F09-8BC2-CEB087BD5DBE@me.com>
 <59543203684B2244980D7E4057D5FBC1487E5513@DB3EX14MBXC306.europe.corp.microsoft.com>
 <CAK-hX0keV-CeO2kSx158Z0s+23_p3eL6oK1dw3+7vBe0GbJ3AA@mail.gmail.com>
 <CAEs96n2FyvRLQ0TcXb_wDbc7bmAnz3mNNo8O1oDDkmsTGjCj3w@mail.gmail.com>
 <5321A20B.40504@cs.kuleuven.be>
 <CAEs96n3RUBc2s6UBM7pSS2xa1qkN7QkfyDYRodJjZ26aKTeS9Q@mail.gmail.com>
 <F390775B-C13C-4EBF-B3A2-AD68D2E9B411@cis.upenn.edu>
Message-ID: <53231C2F.4010707@cs.kuleuven.be>


On 03/13/2014 09:56 PM, Richard Eisenberg wrote:

> First of all: Yay! I've been  wanting this for some time. I'm sorry I
 >  missed your presentation at PADL about this.
 >
 > I, personally, rather like the design. There may be fine points of
 > discussion as it all becomes reality, but I think this is a great
 > approach -- much like what I've envisioned whenever thinking about the
 > problem.
 >
 > Thanks so much for doing this!

You're welcome! Thank you too for the work you have done. I very much
liked your presentation at POPL on closed type families :)

> I would allow _ only as a  constraint extension and _a in a constraint
 > only when it also appears in the mono-type.

Right, we are now convinced (thanks to SPJ's comment on the wiki page)
that the small benefits constraint wildcards bring are not worth the
trouble and confusion. This makes things easier for us too :)

> I think, contrary to the wiki  page, that the scope of named wildcards
 > should mirror the behavior of normal type variables. Yes, it's weird
 > that scoped type variables don't work by default, but I think it's
 > weirder still if some scoped type-variable-like things work and others
 > don't. I don't imagine that this fine control is hard to implement.

If more people feel like this, we have no problem with mirroring the
scoped type variables behaviour. The change will be simple.

> I think Austin's suggestion  below is equally great. Just has 7.8 will
 > now report informative errors when _ is used in an expression
 > position, the implementation for partial type signatures can easily
 > spit out informative errors when _ is used in a type. This would not
 > be an extension, because it does not change the set of programs that
 > compile nor the behavior of compiled programs. However, if a user
 > specifies -XPartialTypeSignatures, then the errors are not reported --
 > the inferred type is simply used.

We also like Austin's idea :) I updated the wiki page with a section
about borrowing ideas from the Holes proposal:

https://ghc.haskell.org/trac/ghc/wiki/PartialTypeSignatures#holes

What we plan on doing next:
1. We will update the code to disallow constraint wildcards. Only named
    wildcards also occurring in the monotype and the extra-constraints
    wildcard will be allowed.
2. We will try to implement what we proposed in the Holes section on the
    wiki page.

Comments and feedback are still welcome. There are still some unanswered
design questions on the wiki page, e.g. what about generalisation and
the extra-constraints wildcard in local partial type signatures?


Cheers,
Thomas



> On Mar 13, 2014, at 4:22 PM,  Austin Seipp wrote:
 >
 >> On Thu, Mar 13, 2014 at 7:18 AM, Thomas Winant
 >> <thomas.winant at cs.kuleuven.be> wrote:
 >>> However, we have the impression that no Hole should remain unfilled,
 >>> whereas using a partial type signature doesn't necessarily mean the
 >>> program is incomplete. A partial type signature can still be a
 >>> (stylistic) choice.
 >>
 >> Yes, this is the main hold up I was thinking of. Thinking about it a
 >> little more, one way to resolve it perhaps would be to do something
 >> similar to we did to typed holes at the term level: make 'holes' at
 >> the type level an error by default, which when encountered spit out
 >> the error containing the type each hole was instantiated to, and what
 >> the partial type signatures would be inferred as. Then, if you enable
 >> -XPartialTypeSignatures, these would cease to be errors providing the
 >> compiler can infer the types sensibly (and it wouldn't alert you in
 >> that case).
 >>
 >> That might be a half baked idea (I just sat here for about 5 minutes),
 >> but either way I say again I do support -XPartialTypeSignatures
 >> anyway, and it sounds like a step in the right direction. :)
 >>
 >> --
 >> Regards,
 >>
 >> Austin Seipp, Haskell Consultant
 >> Well-Typed LLP, http://www.well-typed.com/
 >> _______________________________________________
 >> ghc-devs mailing list
 >> ghc-devs at haskell.org
 >> http://www.haskell.org/mailman/listinfo/ghc-devs
 >


Disclaimer: http://www.kuleuven.be/cwis/email_disclaimer.htm
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/ghc-devs/attachments/20140314/5619023d/attachment-0001.html>

From shumovichy at gmail.com  Fri Mar 14 18:00:09 2014
From: shumovichy at gmail.com (Yuras Shumovich)
Date: Fri, 14 Mar 2014 21:00:09 +0300
Subject: FFI: c/c++ struct on stack as an argument or return value
In-Reply-To: <CAJumaK-CiOesyRYDYJe0SVES=2Pba-eUvM3sQ93jjUJwZU22Jw@mail.gmail.com>
References: <1394797839.4664.35.camel@shum-lt>
 <CAJumaK-CiOesyRYDYJe0SVES=2Pba-eUvM3sQ93jjUJwZU22Jw@mail.gmail.com>
Message-ID: <1394820009.4664.64.camel@shum-lt>

On Fri, 2014-03-14 at 09:08 -0400, Edward Kmett wrote:
> I spent some time hacking around on this from a library perspective when I
> had to interoperate with a bunch of Objective C on a 64-bit mac as many of
> the core library functions you need to FFI out to pass around pairs of Int32s
> as a struct small enough by the x64 ABI to get shoehorned into one
> register, and as I was programmatically cloning Objective C APIs via
> template haskell I couldn't use the usual clunky C shims.

Was it related to language-c-inline package?

> So if nothing else, you can at least take this as a vote of confidence that
> your idea isn't crazy. =)
> 
> I'd also be happy to answer questions if you get stuck or need help.

Thank you, Edward

Since there is at least one person how is interested in, I'll start
asking questions. Please let me know when I become too noisy :)

For now I'm focused on desugaring phase. Right now

type Fn = CInt -> CInt -> IO ()
foreign import ccall "wrapper" f :: Fn -> IO (FunPtr Fn)

is desugared into

f :: Fn -> IO (FunPtr Fn)
f hsFunc = do
  sPtr <- newStablePtr hsFunc
  createAdjustor sPtr staticWrapper ...

Here staticWrapper -- address of C function. It will dereference the
sPtr, cast to StgClosure* and call with appropriate arguments. All the
arguments are primitive C types (int, char, pointer, etc), so it is easy
to convert them to corresponding haskell types via rts_mkInt, rts_mkChar
etc.

But I want to allow argument to be C structs.

data CStruct {
  i :: CInt,
  j :: CInt
}
type Fn = CStruct -> IO ()
foreign import ccall "wrapper" f :: Fn -> IO (FunPtr Fn)

Looks like it is impossible to instantiate CStruct from C function. Is
it true? Is it easy to add such functionality?

The only solution I see is to flatten CStruct before creating StablePtr:

f :: Fn -> IO (FunPtr Fn)
f hsFunc = do
  sPtr <- newStablePtr $ \i j -> hsFunc (CStruct i j)
  createAdjustor sPtr staticWrapper ...

Does it make sense? It will add performance overhead because of
additional indirection. Better ideas are welcome.

Thanks,
Yuras

> 
> -Edward
> 
> 
> On Fri, Mar 14, 2014 at 7:50 AM, Yuras Shumovich <shumovichy at gmail.com>wrote:
> 
> >
> > Hi,
> >
> > Right now ghc's FFI doesn't support c/c++ structures.
> >
> > Whenever we have foreign function that accepts or returns struct by
> > value, we have to create wrapper that accepts or returns pointer to
> > struct. It is inconvenient, but actually not a big deal.
> >
> > But there is no easy workaround when you want to export haskell function
> > to use it with c/c++ API that requires structures to be passed by value
> > (Usually it is a callback in c/c++ API. You can't change it's signature,
> > and if it doesn't provide some kind of "void* userdata", then you are
> > stuck.)
> >
> > I'm interested in fixing that. I'm going to start with 'foreign import
> > "wrapper" ...' stuff.
> >
> > Calling conventions for passing c/c++ structures by value are pretty
> > tricky and platform/compiler specific. So initially I'll use libffi for
> > that (it will work when USE_LIBFFI_FOR_ADJUSTORS is defined, see
> > rts/Adjustor.c). It will allow me to explore design space without
> > bothering about low level implementation details. Later it could be
> > implemented for native (non-libffi) adjustors.
> >
> > Is anybody interested it that? I appreciate any comments/ideas.
> >
> > Right now I don't have clear design. It would be nice to support plain
> > haskell data types that are 1) not recursive, 2) has one constructor and
> > 3) contains only c/c++ types. But it doesn't work with c/c++ unions. Any
> > ideas are welcome.
> >
> > An example how to use libffi with structures:
> > http://www.atmark-techno.com/~yashi/libffi.html#Structures
> >
> > Thanks,
> > Yuras
> >
> >
> > _______________________________________________
> > ghc-devs mailing list
> > ghc-devs at haskell.org
> > http://www.haskell.org/mailman/listinfo/ghc-devs
> >



From ekmett at gmail.com  Fri Mar 14 19:01:52 2014
From: ekmett at gmail.com (Edward Kmett)
Date: Fri, 14 Mar 2014 15:01:52 -0400
Subject: FFI: c/c++ struct on stack as an argument or return value
In-Reply-To: <1394820009.4664.64.camel@shum-lt>
References: <1394797839.4664.35.camel@shum-lt>
 <CAJumaK-CiOesyRYDYJe0SVES=2Pba-eUvM3sQ93jjUJwZU22Jw@mail.gmail.com>
 <1394820009.4664.64.camel@shum-lt>
Message-ID: <CAJumaK9rhvmZC+C6_z2nzrMbmz818u7Ds-UkyPaOz1Xf30xN6Q@mail.gmail.com>

On Fri, Mar 14, 2014 at 2:00 PM, Yuras Shumovich <shumovichy at gmail.com>wrote:

> On Fri, 2014-03-14 at 09:08 -0400, Edward Kmett wrote:
> > I spent some time hacking around on this from a library perspective when
> I
> > had to interoperate with a bunch of Objective C on a 64-bit mac as many
> of
> > the core library functions you need to FFI out to pass around pairs of
> Int32s
> > as a struct small enough by the x64 ABI to get shoehorned into one
> > register, and as I was programmatically cloning Objective C APIs via
> > template haskell I couldn't use the usual clunky C shims.
>
> Was it related to language-c-inline package?


It was an exercise in serial yak shaving brought about by writing a
realtime GPU-based Metropolis light transport raytracer... er.. nevermind.
=)

> So if nothing else, you can at least take this as a vote of confidence
> that
> > your idea isn't crazy. =)
> >
> > I'd also be happy to answer questions if you get stuck or need help.
>
> Thank you, Edward
>
> Since there is at least one person how is interested in, I'll start
> asking questions. Please let me know when I become too noisy :)
>
> For now I'm focused on desugaring phase. Right now
>
> type Fn = CInt -> CInt -> IO ()
> foreign import ccall "wrapper" f :: Fn -> IO (FunPtr Fn)
>
> is desugared into
>
> f :: Fn -> IO (FunPtr Fn)
> f hsFunc = do
>   sPtr <- newStablePtr hsFunc
>   createAdjustor sPtr staticWrapper ...
>
> Here staticWrapper -- address of C function. It will dereference the
> sPtr, cast to StgClosure* and call with appropriate arguments. All the
> arguments are primitive C types (int, char, pointer, etc), so it is easy
> to convert them to corresponding haskell types via rts_mkInt, rts_mkChar
> etc.
>
> But I want to allow argument to be C structs.
>
> data CStruct {
>   i :: CInt,
>   j :: CInt
> }
> type Fn = CStruct -> IO ()
> foreign import ccall "wrapper" f :: Fn -> IO (FunPtr Fn)
>
> Looks like it is impossible to instantiate CStruct from C function. Is
> it true? Is it easy to add such functionality?
>
> The only solution I see is to flatten CStruct before creating StablePtr:
>
> f :: Fn -> IO (FunPtr Fn)
> f hsFunc = do
>   sPtr <- newStablePtr $ \i j -> hsFunc (CStruct i j)
>   createAdjustor sPtr staticWrapper ...
>
> Does it make sense? It will add performance overhead because of
> additional indirection. Better ideas are welcome.
>

Not sure. This is a much lower level (and more correct .. and likely
faster) approach than I was taking.

I'd just built all my functions in a way that would cache the resulting
ffi_prep_cif for each signature using typeclass magic. I had to do some
allocations on each ffi_call though as well for struct avalues though, so
I'm guessing you'd have to do at least that much.





> Thanks,
> Yuras
>
> >
> > -Edward
> >
> >
> > On Fri, Mar 14, 2014 at 7:50 AM, Yuras Shumovich <shumovichy at gmail.com
> >wrote:
> >
> > >
> > > Hi,
> > >
> > > Right now ghc's FFI doesn't support c/c++ structures.
> > >
> > > Whenever we have foreign function that accepts or returns struct by
> > > value, we have to create wrapper that accepts or returns pointer to
> > > struct. It is inconvenient, but actually not a big deal.
> > >
> > > But there is no easy workaround when you want to export haskell
> function
> > > to use it with c/c++ API that requires structures to be passed by value
> > > (Usually it is a callback in c/c++ API. You can't change it's
> signature,
> > > and if it doesn't provide some kind of "void* userdata", then you are
> > > stuck.)
> > >
> > > I'm interested in fixing that. I'm going to start with 'foreign import
> > > "wrapper" ...' stuff.
> > >
> > > Calling conventions for passing c/c++ structures by value are pretty
> > > tricky and platform/compiler specific. So initially I'll use libffi for
> > > that (it will work when USE_LIBFFI_FOR_ADJUSTORS is defined, see
> > > rts/Adjustor.c). It will allow me to explore design space without
> > > bothering about low level implementation details. Later it could be
> > > implemented for native (non-libffi) adjustors.
> > >
> > > Is anybody interested it that? I appreciate any comments/ideas.
> > >
> > > Right now I don't have clear design. It would be nice to support plain
> > > haskell data types that are 1) not recursive, 2) has one constructor
> and
> > > 3) contains only c/c++ types. But it doesn't work with c/c++ unions.
> Any
> > > ideas are welcome.
> > >
> > > An example how to use libffi with structures:
> > > http://www.atmark-techno.com/~yashi/libffi.html#Structures
> > >
> > > Thanks,
> > > Yuras
> > >
> > >
> > > _______________________________________________
> > > ghc-devs mailing list
> > > ghc-devs at haskell.org
> > > http://www.haskell.org/mailman/listinfo/ghc-devs
> > >
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/ghc-devs/attachments/20140314/866509ae/attachment.html>

From chak at cse.unsw.edu.au  Sat Mar 15 04:00:20 2014
From: chak at cse.unsw.edu.au (Manuel M T Chakravarty)
Date: Sat, 15 Mar 2014 15:00:20 +1100
Subject: FFI: c/c++ struct on stack as an argument or return value
In-Reply-To: <1394797839.4664.35.camel@shum-lt>
References: <1394797839.4664.35.camel@shum-lt>
Message-ID: <5F969E34-BCF1-40CB-86DF-20F84245BEDB@cse.unsw.edu.au>

Yuras,

I?m not convinced that the compiler is the right place for this kind of functionality. In fact, when we designed the Haskell FFI, we explicit decided against what you propose. There are a few reasons for this.

Firstly, compilers are complex beasts, and secondly, it takes a long time until a change in the compiler goes into production. Hence, as a general rule, it is advisable to move complexity from the compiler into libraries as this reduces compiler complexity. Libraries are less complex and changes can be rolled out much more quickly (it?s essentially a Hackage upload versus waiting for the next GHC and Haskell Platform release).

Thirdly, we have got the Haskell standard for a reason and modifying the compiler implies a language extension.

The design goal for the Haskell FFI was to provide the absolute minimum as part of the language and compiler, and to layer additional conveniences on top of that in the form of libraries and tools.

Have you considered the library or tool route?

Manuel

Yuras Shumovich <shumovichy at gmail.com>:
> Hi,
> 
> Right now ghc's FFI doesn't support c/c++ structures.
> 
> Whenever we have foreign function that accepts or returns struct by
> value, we have to create wrapper that accepts or returns pointer to
> struct. It is inconvenient, but actually not a big deal.
> 
> But there is no easy workaround when you want to export haskell function
> to use it with c/c++ API that requires structures to be passed by value
> (Usually it is a callback in c/c++ API. You can't change it's signature,
> and if it doesn't provide some kind of "void* userdata", then you are
> stuck.)
> 
> I'm interested in fixing that. I'm going to start with 'foreign import
> "wrapper" ...' stuff.
> 
> Calling conventions for passing c/c++ structures by value are pretty
> tricky and platform/compiler specific. So initially I'll use libffi for
> that (it will work when USE_LIBFFI_FOR_ADJUSTORS is defined, see
> rts/Adjustor.c). It will allow me to explore design space without
> bothering about low level implementation details. Later it could be
> implemented for native (non-libffi) adjustors.
> 
> Is anybody interested it that? I appreciate any comments/ideas.
> 
> Right now I don't have clear design. It would be nice to support plain
> haskell data types that are 1) not recursive, 2) has one constructor and
> 3) contains only c/c++ types. But it doesn't work with c/c++ unions. Any
> ideas are welcome.
> 
> An example how to use libffi with structures:
> http://www.atmark-techno.com/~yashi/libffi.html#Structures
> 
> Thanks,
> Yuras
> 
> 
> _______________________________________________
> ghc-devs mailing list
> ghc-devs at haskell.org
> http://www.haskell.org/mailman/listinfo/ghc-devs


From carter.schonwald at gmail.com  Sat Mar 15 04:17:59 2014
From: carter.schonwald at gmail.com (Carter Schonwald)
Date: Sat, 15 Mar 2014 00:17:59 -0400
Subject: FFI: c/c++ struct on stack as an argument or return value
In-Reply-To: <5F969E34-BCF1-40CB-86DF-20F84245BEDB@cse.unsw.edu.au>
References: <1394797839.4664.35.camel@shum-lt>
 <5F969E34-BCF1-40CB-86DF-20F84245BEDB@cse.unsw.edu.au>
Message-ID: <CAHYVw0xugANXO43pxA5yPH3xpZ4CxKOBA6UetwNAPa6XfLD0Ew@mail.gmail.com>

indeed, its very very easy to do storable instances that correspond to the
struct type you want,

the ``with`` function in
http://hackage.haskell.org/package/base-4.6.0.1/docs/Foreign-Marshal-Utils.htmlforeigh.marshal.utils
actually gets you most of the way there!




On Sat, Mar 15, 2014 at 12:00 AM, Manuel M T Chakravarty <
chak at cse.unsw.edu.au> wrote:

> Yuras,
>
> I?m not convinced that the compiler is the right place for this kind of
> functionality. In fact, when we designed the Haskell FFI, we explicit
> decided against what you propose. There are a few reasons for this.
>
> Firstly, compilers are complex beasts, and secondly, it takes a long time
> until a change in the compiler goes into production. Hence, as a general
> rule, it is advisable to move complexity from the compiler into libraries
> as this reduces compiler complexity. Libraries are less complex and changes
> can be rolled out much more quickly (it?s essentially a Hackage upload
> versus waiting for the next GHC and Haskell Platform release).
>
> Thirdly, we have got the Haskell standard for a reason and modifying the
> compiler implies a language extension.
>
> The design goal for the Haskell FFI was to provide the absolute minimum as
> part of the language and compiler, and to layer additional conveniences on
> top of that in the form of libraries and tools.
>
> Have you considered the library or tool route?
>
> Manuel
>
> Yuras Shumovich <shumovichy at gmail.com>:
> > Hi,
> >
> > Right now ghc's FFI doesn't support c/c++ structures.
> >
> > Whenever we have foreign function that accepts or returns struct by
> > value, we have to create wrapper that accepts or returns pointer to
> > struct. It is inconvenient, but actually not a big deal.
> >
> > But there is no easy workaround when you want to export haskell function
> > to use it with c/c++ API that requires structures to be passed by value
> > (Usually it is a callback in c/c++ API. You can't change it's signature,
> > and if it doesn't provide some kind of "void* userdata", then you are
> > stuck.)
> >
> > I'm interested in fixing that. I'm going to start with 'foreign import
> > "wrapper" ...' stuff.
> >
> > Calling conventions for passing c/c++ structures by value are pretty
> > tricky and platform/compiler specific. So initially I'll use libffi for
> > that (it will work when USE_LIBFFI_FOR_ADJUSTORS is defined, see
> > rts/Adjustor.c). It will allow me to explore design space without
> > bothering about low level implementation details. Later it could be
> > implemented for native (non-libffi) adjustors.
> >
> > Is anybody interested it that? I appreciate any comments/ideas.
> >
> > Right now I don't have clear design. It would be nice to support plain
> > haskell data types that are 1) not recursive, 2) has one constructor and
> > 3) contains only c/c++ types. But it doesn't work with c/c++ unions. Any
> > ideas are welcome.
> >
> > An example how to use libffi with structures:
> > http://www.atmark-techno.com/~yashi/libffi.html#Structures
> >
> > Thanks,
> > Yuras
> >
> >
> > _______________________________________________
> > ghc-devs mailing list
> > ghc-devs at haskell.org
> > http://www.haskell.org/mailman/listinfo/ghc-devs
>
> _______________________________________________
> ghc-devs mailing list
> ghc-devs at haskell.org
> http://www.haskell.org/mailman/listinfo/ghc-devs
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/ghc-devs/attachments/20140315/fa7cd0ac/attachment-0001.html>

From ekmett at gmail.com  Sat Mar 15 04:33:29 2014
From: ekmett at gmail.com (Edward Kmett)
Date: Sat, 15 Mar 2014 00:33:29 -0400
Subject: FFI: c/c++ struct on stack as an argument or return value
In-Reply-To: <CAHYVw0xugANXO43pxA5yPH3xpZ4CxKOBA6UetwNAPa6XfLD0Ew@mail.gmail.com>
References: <1394797839.4664.35.camel@shum-lt>
 <5F969E34-BCF1-40CB-86DF-20F84245BEDB@cse.unsw.edu.au>
 <CAHYVw0xugANXO43pxA5yPH3xpZ4CxKOBA6UetwNAPa6XfLD0Ew@mail.gmail.com>
Message-ID: <CAJumaK-KakS9=9ksGnOj9p6qYq3KmfoZwyCGju7d1kyytwcg8Q@mail.gmail.com>

I don't care enough to fight and try to win the battle, but I just want to
point out that Storable structs are far more brittle and platform dependent
than borrowing the already correct platform logic for struct passing from
libffi.

I do think the existing FFI extension made the right call under the 32 bit
ABIs that were in use at the time it was defined. That said, with 64-bit
ABIs saying that 2 32-bit ints should be passed in a single 64 bit
register, you wind up with large chunks of third party APIs we just can't
call out to directly any more, requiring many one-off manual C shims.

-Edward




On Sat, Mar 15, 2014 at 12:17 AM, Carter Schonwald <
carter.schonwald at gmail.com> wrote:

> indeed, its very very easy to do storable instances that correspond to the
> struct type you want,
>
> the ``with`` function in
> http://hackage.haskell.org/package/base-4.6.0.1/docs/Foreign-Marshal-Utils.htmlforeigh.marshal.utils actually gets you most of the way there!
>
>
>
>
> On Sat, Mar 15, 2014 at 12:00 AM, Manuel M T Chakravarty <
> chak at cse.unsw.edu.au> wrote:
>
>> Yuras,
>>
>> I?m not convinced that the compiler is the right place for this kind of
>> functionality. In fact, when we designed the Haskell FFI, we explicit
>> decided against what you propose. There are a few reasons for this.
>>
>> Firstly, compilers are complex beasts, and secondly, it takes a long time
>> until a change in the compiler goes into production. Hence, as a general
>> rule, it is advisable to move complexity from the compiler into libraries
>> as this reduces compiler complexity. Libraries are less complex and changes
>> can be rolled out much more quickly (it?s essentially a Hackage upload
>> versus waiting for the next GHC and Haskell Platform release).
>>
>> Thirdly, we have got the Haskell standard for a reason and modifying the
>> compiler implies a language extension.
>>
>> The design goal for the Haskell FFI was to provide the absolute minimum
>> as part of the language and compiler, and to layer additional conveniences
>> on top of that in the form of libraries and tools.
>>
>> Have you considered the library or tool route?
>>
>> Manuel
>>
>> Yuras Shumovich <shumovichy at gmail.com>:
>> > Hi,
>> >
>> > Right now ghc's FFI doesn't support c/c++ structures.
>> >
>> > Whenever we have foreign function that accepts or returns struct by
>> > value, we have to create wrapper that accepts or returns pointer to
>> > struct. It is inconvenient, but actually not a big deal.
>> >
>> > But there is no easy workaround when you want to export haskell function
>> > to use it with c/c++ API that requires structures to be passed by value
>> > (Usually it is a callback in c/c++ API. You can't change it's signature,
>> > and if it doesn't provide some kind of "void* userdata", then you are
>> > stuck.)
>> >
>> > I'm interested in fixing that. I'm going to start with 'foreign import
>> > "wrapper" ...' stuff.
>> >
>> > Calling conventions for passing c/c++ structures by value are pretty
>> > tricky and platform/compiler specific. So initially I'll use libffi for
>> > that (it will work when USE_LIBFFI_FOR_ADJUSTORS is defined, see
>> > rts/Adjustor.c). It will allow me to explore design space without
>> > bothering about low level implementation details. Later it could be
>> > implemented for native (non-libffi) adjustors.
>> >
>> > Is anybody interested it that? I appreciate any comments/ideas.
>> >
>> > Right now I don't have clear design. It would be nice to support plain
>> > haskell data types that are 1) not recursive, 2) has one constructor and
>> > 3) contains only c/c++ types. But it doesn't work with c/c++ unions. Any
>> > ideas are welcome.
>> >
>> > An example how to use libffi with structures:
>> > http://www.atmark-techno.com/~yashi/libffi.html#Structures
>> >
>> > Thanks,
>> > Yuras
>> >
>> >
>> > _______________________________________________
>> > ghc-devs mailing list
>> > ghc-devs at haskell.org
>> > http://www.haskell.org/mailman/listinfo/ghc-devs
>>
>> _______________________________________________
>> ghc-devs mailing list
>> ghc-devs at haskell.org
>> http://www.haskell.org/mailman/listinfo/ghc-devs
>>
>
>
> _______________________________________________
> ghc-devs mailing list
> ghc-devs at haskell.org
> http://www.haskell.org/mailman/listinfo/ghc-devs
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/ghc-devs/attachments/20140315/4e855161/attachment.html>

From carter.schonwald at gmail.com  Sat Mar 15 04:37:02 2014
From: carter.schonwald at gmail.com (Carter Schonwald)
Date: Sat, 15 Mar 2014 00:37:02 -0400
Subject: FFI: c/c++ struct on stack as an argument or return value
In-Reply-To: <CAJumaK-KakS9=9ksGnOj9p6qYq3KmfoZwyCGju7d1kyytwcg8Q@mail.gmail.com>
References: <1394797839.4664.35.camel@shum-lt>
 <5F969E34-BCF1-40CB-86DF-20F84245BEDB@cse.unsw.edu.au>
 <CAHYVw0xugANXO43pxA5yPH3xpZ4CxKOBA6UetwNAPa6XfLD0Ew@mail.gmail.com>
 <CAJumaK-KakS9=9ksGnOj9p6qYq3KmfoZwyCGju7d1kyytwcg8Q@mail.gmail.com>
Message-ID: <CAHYVw0wje9Ju_rUfCQUeN=qRtbBs_aJ8TSY+75P3bH89vAJEHA@mail.gmail.com>

I'm not opposing that, in fact, theres a GHC ticket discussing some stuff
related to this (related to complex numbers).

i think the crux of Manuel's point is mainly that any good proposal has to
at least give a roadmap to support on all the various platforms etc etc


On Sat, Mar 15, 2014 at 12:33 AM, Edward Kmett <ekmett at gmail.com> wrote:

> I don't care enough to fight and try to win the battle, but I just want to
> point out that Storable structs are far more brittle and platform dependent
> than borrowing the already correct platform logic for struct passing from
> libffi.
>
> I do think the existing FFI extension made the right call under the 32 bit
> ABIs that were in use at the time it was defined. That said, with 64-bit
> ABIs saying that 2 32-bit ints should be passed in a single 64 bit
> register, you wind up with large chunks of third party APIs we just can't
> call out to directly any more, requiring many one-off manual C shims.
>
> -Edward
>
>
>
>
> On Sat, Mar 15, 2014 at 12:17 AM, Carter Schonwald <
> carter.schonwald at gmail.com> wrote:
>
>> indeed, its very very easy to do storable instances that correspond to
>> the struct type you want,
>>
>> the ``with`` function in
>> http://hackage.haskell.org/package/base-4.6.0.1/docs/Foreign-Marshal-Utils.htmlforeigh.marshal.utils actually gets you most of the way there!
>>
>>
>>
>>
>> On Sat, Mar 15, 2014 at 12:00 AM, Manuel M T Chakravarty <
>> chak at cse.unsw.edu.au> wrote:
>>
>>> Yuras,
>>>
>>> I?m not convinced that the compiler is the right place for this kind of
>>> functionality. In fact, when we designed the Haskell FFI, we explicit
>>> decided against what you propose. There are a few reasons for this.
>>>
>>> Firstly, compilers are complex beasts, and secondly, it takes a long
>>> time until a change in the compiler goes into production. Hence, as a
>>> general rule, it is advisable to move complexity from the compiler into
>>> libraries as this reduces compiler complexity. Libraries are less complex
>>> and changes can be rolled out much more quickly (it?s essentially a Hackage
>>> upload versus waiting for the next GHC and Haskell Platform release).
>>>
>>> Thirdly, we have got the Haskell standard for a reason and modifying the
>>> compiler implies a language extension.
>>>
>>> The design goal for the Haskell FFI was to provide the absolute minimum
>>> as part of the language and compiler, and to layer additional conveniences
>>> on top of that in the form of libraries and tools.
>>>
>>> Have you considered the library or tool route?
>>>
>>> Manuel
>>>
>>> Yuras Shumovich <shumovichy at gmail.com>:
>>> > Hi,
>>> >
>>> > Right now ghc's FFI doesn't support c/c++ structures.
>>> >
>>> > Whenever we have foreign function that accepts or returns struct by
>>> > value, we have to create wrapper that accepts or returns pointer to
>>> > struct. It is inconvenient, but actually not a big deal.
>>> >
>>> > But there is no easy workaround when you want to export haskell
>>> function
>>> > to use it with c/c++ API that requires structures to be passed by value
>>> > (Usually it is a callback in c/c++ API. You can't change it's
>>> signature,
>>> > and if it doesn't provide some kind of "void* userdata", then you are
>>> > stuck.)
>>> >
>>> > I'm interested in fixing that. I'm going to start with 'foreign import
>>> > "wrapper" ...' stuff.
>>> >
>>> > Calling conventions for passing c/c++ structures by value are pretty
>>> > tricky and platform/compiler specific. So initially I'll use libffi for
>>> > that (it will work when USE_LIBFFI_FOR_ADJUSTORS is defined, see
>>> > rts/Adjustor.c). It will allow me to explore design space without
>>> > bothering about low level implementation details. Later it could be
>>> > implemented for native (non-libffi) adjustors.
>>> >
>>> > Is anybody interested it that? I appreciate any comments/ideas.
>>> >
>>> > Right now I don't have clear design. It would be nice to support plain
>>> > haskell data types that are 1) not recursive, 2) has one constructor
>>> and
>>> > 3) contains only c/c++ types. But it doesn't work with c/c++ unions.
>>> Any
>>> > ideas are welcome.
>>> >
>>> > An example how to use libffi with structures:
>>> > http://www.atmark-techno.com/~yashi/libffi.html#Structures
>>> >
>>> > Thanks,
>>> > Yuras
>>> >
>>> >
>>> > _______________________________________________
>>> > ghc-devs mailing list
>>> > ghc-devs at haskell.org
>>> > http://www.haskell.org/mailman/listinfo/ghc-devs
>>>
>>> _______________________________________________
>>> ghc-devs mailing list
>>> ghc-devs at haskell.org
>>> http://www.haskell.org/mailman/listinfo/ghc-devs
>>>
>>
>>
>> _______________________________________________
>> ghc-devs mailing list
>> ghc-devs at haskell.org
>> http://www.haskell.org/mailman/listinfo/ghc-devs
>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/ghc-devs/attachments/20140315/80a92487/attachment.html>

From mail at joachim-breitner.de  Sat Mar 15 10:15:37 2014
From: mail at joachim-breitner.de (Joachim Breitner)
Date: Sat, 15 Mar 2014 11:15:37 +0100
Subject: [commit: ghc] master: Pretty-print the following TyThings via
 their IfaceDecl counterpart: * AnId * ACoAxiom * AConLike (065c35a)
In-Reply-To: <CAO7EwMqmsGvMjmPoweWFVqD7Rh14NGpAyZn8A4UOEg2Sd7nTzw@mail.gmail.com>
References: <20140313132145.1D9472406B@ghc.haskell.org>
 <CAK-tuPZSNQE9EV0tWTZ-oFWnnLwYPwXH8Db1A45PNjboa7cBMQ@mail.gmail.com>
 <CAO7EwMqmsGvMjmPoweWFVqD7Rh14NGpAyZn8A4UOEg2Sd7nTzw@mail.gmail.com>
Message-ID: <1394878537.2413.2.camel@kirk>

Hi Gerg?,


I saw some patches from you yesterday, but there are still validate
failures:

Unexpected failures:
   indexed-types/should_compile  T3017 [stderr mismatch] (normal)
   roles/should_compile          Roles1 [stderr mismatch] (normal)
   roles/should_compile          Roles2 [stderr mismatch] (normal)
   simplCore/should_compile      T4306 [bad exit code] (normal)
   th                            T8884 [stderr mismatch] (normal)
   typecheck/should_compile      tc231 [stderr mismatch] (normal)
https://s3.amazonaws.com/archive.travis-ci.org/jobs/20819762/log.txt

Are these related to your changes, and are pending fixing? (If not it
might take too long until we notice, and it will be more difficult to
find the cause.)

Greetings,
Joachim

-- 
Joachim ?nomeata? Breitner
  mail at joachim-breitner.de ? http://www.joachim-breitner.de/
  Jabber: nomeata at joachim-breitner.de  ? GPG-Key: 0x4743206C
  Debian Developer: nomeata at debian.org
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 181 bytes
Desc: This is a digitally signed message part
URL: <http://www.haskell.org/pipermail/ghc-devs/attachments/20140315/010943a9/attachment-0001.sig>

From R.Paterson at city.ac.uk  Sat Mar 15 11:36:34 2014
From: R.Paterson at city.ac.uk (Ross Paterson)
Date: Sat, 15 Mar 2014 11:36:34 +0000
Subject: Arrow notation vs RebindableSyntax
In-Reply-To: <CADfHYo6iTr+GWqpz2nKGQ6vO4ZkZ7f09_Ln+LQ+9CAkVmoPzXw@mail.gmail.com>
References: <CADfHYo6iTr+GWqpz2nKGQ6vO4ZkZ7f09_Ln+LQ+9CAkVmoPzXw@mail.gmail.com>
Message-ID: <20140315113634.GA4572@city.ac.uk>

On Thu, Mar 13, 2014 at 04:36:54PM -0500, Nicolas Frisby wrote:
> The 7.8-rc2 User Guide for rebindable syntax includes:
> 
>     Arrow notation (see Section 7.16, "Arrow notation") uses whatever
>     arr, (>>>), first, app, (|||) and loop functions are in scope.
>     But unlike the other constructs, the types of these functions
>     must match the Prelude types very closely.  Details are in flux;
>     if you want to use this, ask!
> 
> I want to use this: my types for the functions apparently do not match the
> Prelude types closely enough.
> 
> Whom should I ask about this?

Daniel Winograd-Cort was looking at this, but I haven't heard anything
for a while.  My own view is that rebinding should be done at the control
operator level rather than the level of arrow combinators.  But what are
the types of your functions?

From shumovichy at gmail.com  Sat Mar 15 12:51:02 2014
From: shumovichy at gmail.com (Yuras Shumovich)
Date: Sat, 15 Mar 2014 15:51:02 +0300
Subject: FFI: c/c++ struct on stack as an argument or return value
In-Reply-To: <CAHYVw0wje9Ju_rUfCQUeN=qRtbBs_aJ8TSY+75P3bH89vAJEHA@mail.gmail.com>
References: <1394797839.4664.35.camel@shum-lt>
 <5F969E34-BCF1-40CB-86DF-20F84245BEDB@cse.unsw.edu.au>
 <CAHYVw0xugANXO43pxA5yPH3xpZ4CxKOBA6UetwNAPa6XfLD0Ew@mail.gmail.com>
 <CAJumaK-KakS9=9ksGnOj9p6qYq3KmfoZwyCGju7d1kyytwcg8Q@mail.gmail.com>
 <CAHYVw0wje9Ju_rUfCQUeN=qRtbBs_aJ8TSY+75P3bH89vAJEHA@mail.gmail.com>
Message-ID: <1394887862.4722.31.camel@shum-lt>

Manuel,

I think the compiler is the right place. It is impossible to have
efficient implementation in a library.

For dynamic wrapper (foreign import "wrapper" stuff) ghc generates piece
of executable code at runtime. There are native implementations for a
number of platforms, and libffi is used as a fall back for other
platforms (see rts/Adjustor.c). AFAIK it is done that way because libffi
is slower then native implementation.

Library implementation can't generate native dynamic wrapper, it has to
use slow libffi.


> On Sat, 2014-03-15 at 00:17 -0400, Carter Schonwald wrote: 
> > indeed, its very very easy to do storable instances that correspond to the
> > struct type you want,
> > 
> > the ``with`` function in
> > http://hackage.haskell.org/package/base-4.6.0.1/docs/Foreign-Marshal-Utils.htmlforeigh.marshal.utils
> > actually gets you most of the way there!

Not sure I understand. `with` can be used to provide C function with pointer to C structure.
How can it help when C function requires C structure to be passed by value?


> i think the crux of Manuel's point is mainly that any good proposal
> has to
> at least give a roadmap to support on all the various platforms etc
> etc

I don't think you are expecting detailed schedule from me. Passing
structure by value is possible on all platforms ghc supports, and it can
be implemented for any particular platform if somebody is interested.

>From my point of view, at this point it is more important to agree on
the next question: do we want such functionality in ghc at all? I don't
want to waste time on it if nobody wants to see it merged.

Thanks,
Yuras

On Sat, 2014-03-15 at 00:37 -0400, Carter Schonwald wrote:
> I'm not opposing that, in fact, theres a GHC ticket discussing some stuff
> related to this (related to complex numbers).
> 
> i think the crux of Manuel's point is mainly that any good proposal has to
> at least give a roadmap to support on all the various platforms etc etc
> 
> 
> On Sat, Mar 15, 2014 at 12:33 AM, Edward Kmett <ekmett at gmail.com> wrote:
> 
> > I don't care enough to fight and try to win the battle, but I just want to
> > point out that Storable structs are far more brittle and platform dependent
> > than borrowing the already correct platform logic for struct passing from
> > libffi.
> >
> > I do think the existing FFI extension made the right call under the 32 bit
> > ABIs that were in use at the time it was defined. That said, with 64-bit
> > ABIs saying that 2 32-bit ints should be passed in a single 64 bit
> > register, you wind up with large chunks of third party APIs we just can't
> > call out to directly any more, requiring many one-off manual C shims.
> >
> > -Edward
> >
> >
> >
> >
> > On Sat, Mar 15, 2014 at 12:17 AM, Carter Schonwald <
> > carter.schonwald at gmail.com> wrote:
> >
> >> indeed, its very very easy to do storable instances that correspond to
> >> the struct type you want,
> >>
> >> the ``with`` function in
> >> http://hackage.haskell.org/package/base-4.6.0.1/docs/Foreign-Marshal-Utils.htmlforeigh.marshal.utils actually gets you most of the way there!
> >>
> >>
> >>
> >>
> >> On Sat, Mar 15, 2014 at 12:00 AM, Manuel M T Chakravarty <
> >> chak at cse.unsw.edu.au> wrote:
> >>
> >>> Yuras,
> >>>
> >>> I?m not convinced that the compiler is the right place for this kind of
> >>> functionality. In fact, when we designed the Haskell FFI, we explicit
> >>> decided against what you propose. There are a few reasons for this.
> >>>
> >>> Firstly, compilers are complex beasts, and secondly, it takes a long
> >>> time until a change in the compiler goes into production. Hence, as a
> >>> general rule, it is advisable to move complexity from the compiler into
> >>> libraries as this reduces compiler complexity. Libraries are less complex
> >>> and changes can be rolled out much more quickly (it?s essentially a Hackage
> >>> upload versus waiting for the next GHC and Haskell Platform release).
> >>>
> >>> Thirdly, we have got the Haskell standard for a reason and modifying the
> >>> compiler implies a language extension.
> >>>
> >>> The design goal for the Haskell FFI was to provide the absolute minimum
> >>> as part of the language and compiler, and to layer additional conveniences
> >>> on top of that in the form of libraries and tools.
> >>>
> >>> Have you considered the library or tool route?
> >>>
> >>> Manuel
> >>>
> >>> Yuras Shumovich <shumovichy at gmail.com>:
> >>> > Hi,
> >>> >
> >>> > Right now ghc's FFI doesn't support c/c++ structures.
> >>> >
> >>> > Whenever we have foreign function that accepts or returns struct by
> >>> > value, we have to create wrapper that accepts or returns pointer to
> >>> > struct. It is inconvenient, but actually not a big deal.
> >>> >
> >>> > But there is no easy workaround when you want to export haskell
> >>> function
> >>> > to use it with c/c++ API that requires structures to be passed by value
> >>> > (Usually it is a callback in c/c++ API. You can't change it's
> >>> signature,
> >>> > and if it doesn't provide some kind of "void* userdata", then you are
> >>> > stuck.)
> >>> >
> >>> > I'm interested in fixing that. I'm going to start with 'foreign import
> >>> > "wrapper" ...' stuff.
> >>> >
> >>> > Calling conventions for passing c/c++ structures by value are pretty
> >>> > tricky and platform/compiler specific. So initially I'll use libffi for
> >>> > that (it will work when USE_LIBFFI_FOR_ADJUSTORS is defined, see
> >>> > rts/Adjustor.c). It will allow me to explore design space without
> >>> > bothering about low level implementation details. Later it could be
> >>> > implemented for native (non-libffi) adjustors.
> >>> >
> >>> > Is anybody interested it that? I appreciate any comments/ideas.
> >>> >
> >>> > Right now I don't have clear design. It would be nice to support plain
> >>> > haskell data types that are 1) not recursive, 2) has one constructor
> >>> and
> >>> > 3) contains only c/c++ types. But it doesn't work with c/c++ unions.
> >>> Any
> >>> > ideas are welcome.
> >>> >
> >>> > An example how to use libffi with structures:
> >>> > http://www.atmark-techno.com/~yashi/libffi.html#Structures
> >>> >
> >>> > Thanks,
> >>> > Yuras
> >>> >
> >>> >
> >>> > _______________________________________________
> >>> > ghc-devs mailing list
> >>> > ghc-devs at haskell.org
> >>> > http://www.haskell.org/mailman/listinfo/ghc-devs
> >>>
> >>> _______________________________________________
> >>> ghc-devs mailing list
> >>> ghc-devs at haskell.org
> >>> http://www.haskell.org/mailman/listinfo/ghc-devs
> >>>
> >>
> >>
> >> _______________________________________________
> >> ghc-devs mailing list
> >> ghc-devs at haskell.org
> >> http://www.haskell.org/mailman/listinfo/ghc-devs
> >>
> >>
> >
> _______________________________________________
> ghc-devs mailing list
> ghc-devs at haskell.org
> http://www.haskell.org/mailman/listinfo/ghc-devs



From gergo at erdi.hu  Sat Mar 15 16:50:19 2014
From: gergo at erdi.hu (Dr. ERDI Gergo)
Date: Sun, 16 Mar 2014 00:50:19 +0800 (SGT)
Subject: [commit: ghc] master: Pretty-print the following TyThings via
 their IfaceDecl counterpart: * AnId * ACoAxiom * AConLike (065c35a)
In-Reply-To: <1394878537.2413.2.camel@kirk>
References: <20140313132145.1D9472406B@ghc.haskell.org>
 <CAK-tuPZSNQE9EV0tWTZ-oFWnnLwYPwXH8Db1A45PNjboa7cBMQ@mail.gmail.com>
 <CAO7EwMqmsGvMjmPoweWFVqD7Rh14NGpAyZn8A4UOEg2Sd7nTzw@mail.gmail.com>
 <1394878537.2413.2.camel@kirk>
Message-ID: <alpine.DEB.2.10.1403160024340.4118@galaxy>

On Sat, 15 Mar 2014, Joachim Breitner wrote:

>
> Unexpected failures:
>   indexed-types/should_compile  T3017 [stderr mismatch] (normal)
>   roles/should_compile          Roles1 [stderr mismatch] (normal)
>   roles/should_compile          Roles2 [stderr mismatch] (normal)
>   simplCore/should_compile      T4306 [bad exit code] (normal)
>   th                            T8884 [stderr mismatch] (normal)
>   typecheck/should_compile      tc231 [stderr mismatch] (normal)
> https://s3.amazonaws.com/archive.travis-ci.org/jobs/20819762/log.txt

> Are these related to your changes, and are pending fixing? (If not it
> might take too long until we notice, and it will be more difficult to
> find the cause.)

Hi,

Yes, these are related. However, they all point to just a change in the 
output format of -ddump-types so that by default, foralls are not printed. 
The old output format can be restored by passing in an extra 
-fprint-explicit-foralls flag. I think this is actually an improvement, 
and thus my suggestion is to simply update the expected output of these 
tests.

The one interesting case is T4306 which fails because the generated name 
$wupd is regarded as an infix name, and thus with my new code is rendered 
as

   ($wupd) :: GHC.Prim.Double# -> GHC.Prim.Double#

instead of the old

   $wupd :: GHC.Prim.Double# -> GHC.Prim.Double#

I think this is actually a bug in isSymOcc, since I don't think the 
intention behind the generated name $wupd is to be regarded as an infix 
name. So we could change isLexVarSym so that if the first character is $, 
the rest is still checked for symbol-ness.

If there's agreement on this, I'm happy to implement both changes.

Bye,
 	Gergo

From gergo at erdi.hu  Mon Mar 17 12:22:04 2014
From: gergo at erdi.hu (Dr. ERDI Gergo)
Date: Mon, 17 Mar 2014 20:22:04 +0800 (SGT)
Subject: -ddump-types vs -fprint-explicit-foralls, and symbol-ness of
 worker/wrapper names [Re: [commit: ghc] master: Pretty-print the following
 TyThings via their IfaceDecl counterpart: * AnId * ACoAxiom * AConLike
 (065c35a) (fwd)]
Message-ID: <alpine.DEB.2.10.1403172019570.4118@galaxy>

I've just realized the original subject of this mail probably didn't 
properly highlight that this unearthed two issues that I'd like to hear 
opinions on, before going on to fix them. So here's my original mail:

---------- Forwarded message ----------
Date: Sun, 16 Mar 2014 00:50:19 +0800 (SGT)
From: Dr. ERDI Gergo <gergo at erdi.hu>
To: Joachim Breitner <mail at joachim-breitner.de>
Cc: GHC Devs <ghc-devs at haskell.org>
Subject: Re: [commit: ghc] master: Pretty-print the following TyThings via their
      IfaceDecl counterpart: * AnId * ACoAxiom * AConLike (065c35a)

On Sat, 15 Mar 2014, Joachim Breitner wrote:

> 
> Unexpected failures:
>   indexed-types/should_compile  T3017 [stderr mismatch] (normal)
>   roles/should_compile          Roles1 [stderr mismatch] (normal)
>   roles/should_compile          Roles2 [stderr mismatch] (normal)
>   simplCore/should_compile      T4306 [bad exit code] (normal)
>   th                            T8884 [stderr mismatch] (normal)
>   typecheck/should_compile      tc231 [stderr mismatch] (normal)
> https://s3.amazonaws.com/archive.travis-ci.org/jobs/20819762/log.txt

> Are these related to your changes, and are pending fixing? (If not it
> might take too long until we notice, and it will be more difficult to
> find the cause.)

Hi,

Yes, these are related. However, they all point to just a change in the output 
format of -ddump-types so that by default, foralls are not printed. The old 
output format can be restored by passing in an extra -fprint-explicit-foralls 
flag. I think this is actually an improvement, and thus my suggestion is to 
simply update the expected output of these tests.

The one interesting case is T4306 which fails because the generated name $wupd 
is regarded as an infix name, and thus with my new code is rendered as

   ($wupd) :: GHC.Prim.Double# -> GHC.Prim.Double#

instead of the old

   $wupd :: GHC.Prim.Double# -> GHC.Prim.Double#

I think this is actually a bug in isSymOcc, since I don't think the intention 
behind the generated name $wupd is to be regarded as an infix name. So we could 
change isLexVarSym so that if the first character is $, the rest is still 
checked for symbol-ness.

If there's agreement on this, I'm happy to implement both changes.

Bye,
 	Gergo

From simonpj at microsoft.com  Mon Mar 17 13:45:33 2014
From: simonpj at microsoft.com (Simon Peyton Jones)
Date: Mon, 17 Mar 2014 13:45:33 +0000
Subject: -ddump-types vs -fprint-explicit-foralls, and symbol-ness of
 worker/wrapper names [Re: [commit: ghc] master: Pretty-print the following
 TyThings via their IfaceDecl counterpart: * AnId * ACoAxiom * AConLike
 (065c35a) (fwd)]
In-Reply-To: <alpine.DEB.2.10.1403172019570.4118@galaxy>
References: <alpine.DEB.2.10.1403172019570.4118@galaxy>
Message-ID: <59543203684B2244980D7E4057D5FBC14880333B@DB3EX14MBXC308.europe.corp.microsoft.com>

| Yes, these are related. However, they all point to just a change in the
| output format of -ddump-types so that by default, foralls are not
| printed. The old output format can be restored by passing in an extra -
| fprint-explicit-foralls flag. I think this is actually an improvement,
| and thus my suggestion is to simply update the expected output of these
| tests.

Yes I agree.  Go ahead.

| The one interesting case is T4306 which fails because the generated name
| $wupd is regarded as an infix name, and thus with my new code is
| rendered as
| 
|    ($wupd) :: GHC.Prim.Double# -> GHC.Prim.Double#
| 
| instead of the old
| 
|    $wupd :: GHC.Prim.Double# -> GHC.Prim.Double#

I think it'd also be ok just to accept this output too. These "$wxx" names are generated by GHC and won't show up in user output.  It doesn't much matter displaying them in parens.  

But changing isLexVarSym is probably equally fine too.  I think (worth a check) that it's only called for display purposes, and not in any performance-critical parts.

Whichever you choose, add a Note with isLexVarSym to explain the issue and the choice.

| If there's agreement on this, I'm happy to implement both changes.

Thanks. It would be good to nail this today; currently there are a bunch of consequential validate failures.

Simon


| 
| I think this is actually a bug in isSymOcc, since I don't think the
| intention behind the generated name $wupd is to be regarded as an infix
| name. So we could change isLexVarSym so that if the first character is
| $, the rest is still checked for symbol-ness.
| 
| 
| Bye,
|  	Gergo
| _______________________________________________
| ghc-devs mailing list
| ghc-devs at haskell.org
| http://www.haskell.org/mailman/listinfo/ghc-devs

From johan.tibell at gmail.com  Mon Mar 17 14:00:04 2014
From: johan.tibell at gmail.com (Johan Tibell)
Date: Mon, 17 Mar 2014 15:00:04 +0100
Subject: -ddump-types vs -fprint-explicit-foralls, and symbol-ness of
 worker/wrapper names [Re: [commit: ghc] master: Pretty-print the following
 TyThings via their IfaceDecl counterpart: * AnId * ACoAxiom * AConLike
 (065c35a) (fwd)]
In-Reply-To: <59543203684B2244980D7E4057D5FBC14880333B@DB3EX14MBXC308.europe.corp.microsoft.com>
References: <alpine.DEB.2.10.1403172019570.4118@galaxy>
 <59543203684B2244980D7E4057D5FBC14880333B@DB3EX14MBXC308.europe.corp.microsoft.com>
Message-ID: <CAK-tuPa-9Zwn4tCuCP9vTjDnKkm6kQL3B4LcYhZR3LmgNy=e=g@mail.gmail.com>

On Mon, Mar 17, 2014 at 2:45 PM, Simon Peyton Jones
<simonpj at microsoft.com>wrote:

> | The one interesting case is T4306 which fails because the generated name
> | $wupd is regarded as an infix name, and thus with my new code is
> | rendered as
> |
> |    ($wupd) :: GHC.Prim.Double# -> GHC.Prim.Double#
> |
> | instead of the old
> |
> |    $wupd :: GHC.Prim.Double# -> GHC.Prim.Double#
>
> I think it'd also be ok just to accept this output too. These "$wxx" names
> are generated by GHC and won't show up in user output.  It doesn't much
> matter displaying them in parens.
>

Do they show up in -ddump-simpl? It would be nice to keep that output as
readable as possible, as there are quite a few of us that read it on a
regular basis.


> But changing isLexVarSym is probably equally fine too.  I think (worth a
> check) that it's only called for display purposes, and not in any
> performance-critical parts.
>
> Whichever you choose, add a Note with isLexVarSym to explain the issue and
> the choice.


Does that mean that any operator that starts with $ will now not be
considered infix for printing purposes?

-- Johan
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/ghc-devs/attachments/20140317/8ccfd508/attachment.html>

From simonpj at microsoft.com  Mon Mar 17 14:08:57 2014
From: simonpj at microsoft.com (Simon Peyton Jones)
Date: Mon, 17 Mar 2014 14:08:57 +0000
Subject: -ddump-types vs -fprint-explicit-foralls, and symbol-ness of
 worker/wrapper names [Re: [commit: ghc] master: Pretty-print the following
 TyThings via their IfaceDecl counterpart: * AnId * ACoAxiom * AConLike
 (065c35a) (fwd)]
In-Reply-To: <CAK-tuPa-9Zwn4tCuCP9vTjDnKkm6kQL3B4LcYhZR3LmgNy=e=g@mail.gmail.com>
References: <alpine.DEB.2.10.1403172019570.4118@galaxy>
 <59543203684B2244980D7E4057D5FBC14880333B@DB3EX14MBXC308.europe.corp.microsoft.com>
 <CAK-tuPa-9Zwn4tCuCP9vTjDnKkm6kQL3B4LcYhZR3LmgNy=e=g@mail.gmail.com>
Message-ID: <59543203684B2244980D7E4057D5FBC14880364D@DB3EX14MBXC308.europe.corp.microsoft.com>

Do they show up in -ddump-simpl? It would be nice to keep that output as readable as possible, as there are quite a few of us that read it on a regular basis.

I don't think so (because -ddump-simpl doesn't print *any* operators in parens) but I could be wrong, and I agree that would be bad.

Does that mean that any operator that starts with $ will now not be considered infix for printing purposes?

No, I believe that Gergo's suggestion is that a function be considered infix operator (for display purposes) only if all its characters are operator chars, rather than just the first one.

Simon

From: Johan Tibell [mailto:johan.tibell at gmail.com]
Sent: 17 March 2014 14:00
To: Simon Peyton Jones
Cc: Dr. ERDI Gergo; GHC Devs
Subject: Re: -ddump-types vs -fprint-explicit-foralls, and symbol-ness of worker/wrapper names [Re: [commit: ghc] master: Pretty-print the following TyThings via their IfaceDecl counterpart: * AnId * ACoAxiom * AConLike (065c35a) (fwd)]

On Mon, Mar 17, 2014 at 2:45 PM, Simon Peyton Jones <simonpj at microsoft.com<mailto:simonpj at microsoft.com>> wrote:
| The one interesting case is T4306 which fails because the generated name
| $wupd is regarded as an infix name, and thus with my new code is
| rendered as
|
|    ($wupd) :: GHC.Prim.Double# -> GHC.Prim.Double#
|
| instead of the old
|
|    $wupd :: GHC.Prim.Double# -> GHC.Prim.Double#
I think it'd also be ok just to accept this output too. These "$wxx" names are generated by GHC and won't show up in user output.  It doesn't much matter displaying them in parens.

Do they show up in -ddump-simpl? It would be nice to keep that output as readable as possible, as there are quite a few of us that read it on a regular basis.

But changing isLexVarSym is probably equally fine too.  I think (worth a check) that it's only called for display purposes, and not in any performance-critical parts.

Whichever you choose, add a Note with isLexVarSym to explain the issue and the choice.

Does that mean that any operator that starts with $ will now not be considered infix for printing purposes?

-- Johan

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/ghc-devs/attachments/20140317/4cb1e926/attachment-0001.html>

From gergo at erdi.hu  Mon Mar 17 14:23:44 2014
From: gergo at erdi.hu (=?UTF-8?B?RHIuIMOJUkRJIEdlcmfFkQ==?=)
Date: Mon, 17 Mar 2014 22:23:44 +0800
Subject: -ddump-types vs -fprint-explicit-foralls, and symbol-ness of
 worker/wrapper names [Re: [commit: ghc] master: Pretty-print the following
 TyThings via their IfaceDecl counterpart: * AnId * ACoAxiom * AConLike
 (065c35a) (fwd)]
In-Reply-To: <59543203684B2244980D7E4057D5FBC14880364D@DB3EX14MBXC308.europe.corp.microsoft.com>
References: <alpine.DEB.2.10.1403172019570.4118@galaxy>
 <59543203684B2244980D7E4057D5FBC14880333B@DB3EX14MBXC308.europe.corp.microsoft.com>
 <CAK-tuPa-9Zwn4tCuCP9vTjDnKkm6kQL3B4LcYhZR3LmgNy=e=g@mail.gmail.com>
 <59543203684B2244980D7E4057D5FBC14880364D@DB3EX14MBXC308.europe.corp.microsoft.com>
Message-ID: <CAO7EwMqHwSkUQg6PeKJbYXubCV5pNFRMfEjvRsghm1wKDBZmDg@mail.gmail.com>

Exactly, the problem is precisely that $foo is regarded as an infix
operator in that code path, so with my change, it would be classified as
prefix.
On Mar 17, 2014 10:10 PM, "Simon Peyton Jones" <simonpj at microsoft.com>
wrote:

>   Do they show up in -ddump-simpl? It would be nice to keep that output
> as readable as possible, as there are quite a few of us that read it on a
> regular basis.
>
>
>
> I don't think so (because -ddump-simpl doesn't print **any** operators in
> parens) but I could be wrong, and I agree that would be bad.
>
>
>
> Does that mean that any operator that starts with $ will now not be
> considered infix for printing purposes?
>
>
>
> No, I believe that Gergo's suggestion is that a function be considered
> infix operator (for display purposes) only if all its characters are
> operator chars, rather than just the first one.
>
>
>
> Simon
>
>
>
> *From:* Johan Tibell [mailto:johan.tibell at gmail.com]
> *Sent:* 17 March 2014 14:00
> *To:* Simon Peyton Jones
> *Cc:* Dr. ERDI Gergo; GHC Devs
> *Subject:* Re: -ddump-types vs -fprint-explicit-foralls, and symbol-ness
> of worker/wrapper names [Re: [commit: ghc] master: Pretty-print the
> following TyThings via their IfaceDecl counterpart: * AnId * ACoAxiom *
> AConLike (065c35a) (fwd)]
>
>
>
> On Mon, Mar 17, 2014 at 2:45 PM, Simon Peyton Jones <simonpj at microsoft.com>
> wrote:
>
>  | The one interesting case is T4306 which fails because the generated
> name
>
> | $wupd is regarded as an infix name, and thus with my new code is
> | rendered as
> |
> |    ($wupd) :: GHC.Prim.Double# -> GHC.Prim.Double#
> |
> | instead of the old
> |
> |    $wupd :: GHC.Prim.Double# -> GHC.Prim.Double#
>
> I think it'd also be ok just to accept this output too. These "$wxx" names
> are generated by GHC and won't show up in user output.  It doesn't much
> matter displaying them in parens.
>
>
>
> Do they show up in -ddump-simpl? It would be nice to keep that output as
> readable as possible, as there are quite a few of us that read it on a
> regular basis.
>
>
>
>  But changing isLexVarSym is probably equally fine too.  I think (worth a
> check) that it's only called for display purposes, and not in any
> performance-critical parts.
>
> Whichever you choose, add a Note with isLexVarSym to explain the issue and
> the choice.
>
>
>
> Does that mean that any operator that starts with $ will now not be
> considered infix for printing purposes?
>
>
>
> -- Johan
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/ghc-devs/attachments/20140317/84126cf9/attachment.html>

From johan.tibell at gmail.com  Mon Mar 17 15:25:55 2014
From: johan.tibell at gmail.com (Johan Tibell)
Date: Mon, 17 Mar 2014 16:25:55 +0100
Subject: -ddump-types vs -fprint-explicit-foralls, and symbol-ness of
 worker/wrapper names [Re: [commit: ghc] master: Pretty-print the following
 TyThings via their IfaceDecl counterpart: * AnId * ACoAxiom * AConLike
 (065c35a) (fwd)]
In-Reply-To: <CAO7EwMqHwSkUQg6PeKJbYXubCV5pNFRMfEjvRsghm1wKDBZmDg@mail.gmail.com>
References: <alpine.DEB.2.10.1403172019570.4118@galaxy>
 <59543203684B2244980D7E4057D5FBC14880333B@DB3EX14MBXC308.europe.corp.microsoft.com>
 <CAK-tuPa-9Zwn4tCuCP9vTjDnKkm6kQL3B4LcYhZR3LmgNy=e=g@mail.gmail.com>
 <59543203684B2244980D7E4057D5FBC14880364D@DB3EX14MBXC308.europe.corp.microsoft.com>
 <CAO7EwMqHwSkUQg6PeKJbYXubCV5pNFRMfEjvRsghm1wKDBZmDg@mail.gmail.com>
Message-ID: <CAK-tuPby+UtTZ4rrdbLN95Or4y89hrFNzWhNYezSsk5SM+QT3A@mail.gmail.com>

Sounds good to me.


On Mon, Mar 17, 2014 at 3:23 PM, Dr. ?RDI Gerg? <gergo at erdi.hu> wrote:

> Exactly, the problem is precisely that $foo is regarded as an infix
> operator in that code path, so with my change, it would be classified as
> prefix.
>  On Mar 17, 2014 10:10 PM, "Simon Peyton Jones" <simonpj at microsoft.com>
> wrote:
>
>>   Do they show up in ?ddump-simpl? It would be nice to keep that output
>> as readable as possible, as there are quite a few of us that read it on a
>> regular basis.
>>
>>
>>
>> I don?t think so (because ?ddump-simpl doesn?t print **any** operators
>> in parens) but I could be wrong, and I agree that would be bad.
>>
>>
>>
>> Does that mean that any operator that starts with $ will now not be
>> considered infix for printing purposes?
>>
>>
>>
>> No, I believe that Gergo?s suggestion is that a function be considered
>> infix operator (for display purposes) only if all its characters are
>> operator chars, rather than just the first one.
>>
>>
>>
>> Simon
>>
>>
>>
>> *From:* Johan Tibell [mailto:johan.tibell at gmail.com]
>> *Sent:* 17 March 2014 14:00
>> *To:* Simon Peyton Jones
>> *Cc:* Dr. ERDI Gergo; GHC Devs
>> *Subject:* Re: -ddump-types vs -fprint-explicit-foralls, and symbol-ness
>> of worker/wrapper names [Re: [commit: ghc] master: Pretty-print the
>> following TyThings via their IfaceDecl counterpart: * AnId * ACoAxiom *
>> AConLike (065c35a) (fwd)]
>>
>>
>>
>> On Mon, Mar 17, 2014 at 2:45 PM, Simon Peyton Jones <
>> simonpj at microsoft.com> wrote:
>>
>>  | The one interesting case is T4306 which fails because the generated
>> name
>>
>> | $wupd is regarded as an infix name, and thus with my new code is
>> | rendered as
>> |
>> |    ($wupd) :: GHC.Prim.Double# -> GHC.Prim.Double#
>> |
>> | instead of the old
>> |
>> |    $wupd :: GHC.Prim.Double# -> GHC.Prim.Double#
>>
>> I think it'd also be ok just to accept this output too. These "$wxx"
>> names are generated by GHC and won't show up in user output.  It doesn't
>> much matter displaying them in parens.
>>
>>
>>
>> Do they show up in -ddump-simpl? It would be nice to keep that output as
>> readable as possible, as there are quite a few of us that read it on a
>> regular basis.
>>
>>
>>
>>  But changing isLexVarSym is probably equally fine too.  I think (worth a
>> check) that it's only called for display purposes, and not in any
>> performance-critical parts.
>>
>> Whichever you choose, add a Note with isLexVarSym to explain the issue
>> and the choice.
>>
>>
>>
>> Does that mean that any operator that starts with $ will now not be
>> considered infix for printing purposes?
>>
>>
>>
>> -- Johan
>>
>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/ghc-devs/attachments/20140317/65462174/attachment.html>

From johan.tibell at gmail.com  Mon Mar 17 17:11:51 2014
From: johan.tibell at gmail.com (Johan Tibell)
Date: Mon, 17 Mar 2014 18:11:51 +0100
Subject: [commit: ghc] ghc-parmake-gsoc: Implement the parallel upsweep
 (#910) (8d9edfe)
In-Reply-To: <E1VEJzg-0007dy-KP@ghc.haskell.org>
References: <E1VEJzg-0007dy-KP@ghc.haskell.org>
Message-ID: <CAK-tuPZHbo=+2dmmoKbFf8Sp6AzgFX5_uPS21MwThRPo=-Swbg@mail.gmail.com>

I just had reason to have a look at this code. I just want to say thanks
for writing such nice, readable code. I wish all code in GHC had nicely
written Haddock like these. Would make GHC hacking a bit more approachable.


On Tue, Aug 27, 2013 at 4:11 PM, <git at git.haskell.org> wrote:

> Repository : ssh://git at git.haskell.org/ghc
>
> On branch  : ghc-parmake-gsoc
> Link       :
> http://ghc.haskell.org/trac/ghc/changeset/8d9edfed74e8fd03933d4e3540f6372c269de538/ghc
>
> >---------------------------------------------------------------
>
> commit 8d9edfed74e8fd03933d4e3540f6372c269de538
> Author: Patrick Palka <patrick at parcs.ath.cx>
> Date:   Wed Aug 21 16:55:52 2013 -0400
>
>     Implement the parallel upsweep (#910)
>
>     The parallel upsweep is the parallel counterpart to the default
>     sequential upsweep. It attempts to compile modules in parallel by
>     subdividing the work of the upsweep into parts that can be executed
>     concurrently by multiple Haskell threads.
>
>     In order to enable the parallel upsweep, the user has to pass the -jN
>     flag to GHC, where N is an optional number denoting the number of jobs,
>     or modules, to compile in parallel, like with GNU make. In GHC this
> just
>     sets the number of capabilities to N.
>
>
> >---------------------------------------------------------------
>
> 8d9edfed74e8fd03933d4e3540f6372c269de538
>  compiler/main/DynFlags.hs |    8 +
>  compiler/main/GhcMake.hs  |  354
> ++++++++++++++++++++++++++++++++++++++++++++-
>  2 files changed, 359 insertions(+), 3 deletions(-)
>
> Diff suppressed because of size. To see it, use:
>
>     git diff-tree --root --patch-with-stat --no-color --find-copies-harder
> --ignore-space-at-eol --cc 8d9edfed74e8fd03933d4e3540f6372c269de538
>
> _______________________________________________
> ghc-commits mailing list
> ghc-commits at haskell.org
> http://www.haskell.org/mailman/listinfo/ghc-commits
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/ghc-devs/attachments/20140317/7171be9c/attachment-0001.html>

From chak at cse.unsw.edu.au  Tue Mar 18 01:37:27 2014
From: chak at cse.unsw.edu.au (Manuel M T Chakravarty)
Date: Tue, 18 Mar 2014 12:37:27 +1100
Subject: FFI: c/c++ struct on stack as an argument or return value
In-Reply-To: <1394887862.4722.31.camel@shum-lt>
References: <1394797839.4664.35.camel@shum-lt>
 <5F969E34-BCF1-40CB-86DF-20F84245BEDB@cse.unsw.edu.au>
 <CAHYVw0xugANXO43pxA5yPH3xpZ4CxKOBA6UetwNAPa6XfLD0Ew@mail.gmail.com>
 <CAJumaK-KakS9=9ksGnOj9p6qYq3KmfoZwyCGju7d1kyytwcg8Q@mail.gmail.com>
 <CAHYVw0wje9Ju_rUfCQUeN=qRtbBs_aJ8TSY+75P3bH89vAJEHA@mail.gmail.com>
 <1394887862.4722.31.camel@shum-lt>
Message-ID: <C86323E1-F09A-4FDA-88BD-6D28A1D28F83@cse.unsw.edu.au>

Yuras Shumovich <shumovichy at gmail.com>:
> I think the compiler is the right place. It is impossible to have
> efficient implementation in a library.
> 
> For dynamic wrapper (foreign import "wrapper" stuff) ghc generates piece
> of executable code at runtime. There are native implementations for a
> number of platforms, and libffi is used as a fall back for other
> platforms (see rts/Adjustor.c). AFAIK it is done that way because libffi
> is slower then native implementation.
> 
> Library implementation can't generate native dynamic wrapper, it has to
> use slow libffi.

When we first implemented the FFI, there was no libffi. Maintaining the adjustor code for all platforms is a PITA; hence, using libffi was a welcome way to improve portability.

Making the adjustor code more complicated by adding more functionality doesn?t sound like a good plan to me.

Besides, there are other overheads in addition to the actual marshalling in FFI calls and most of the time we are calling out to library functions for which the FFI call overhead is only a small portion of the runtime.

>> i think the crux of Manuel's point is mainly that any good proposal
>> has to
>> at least give a roadmap to support on all the various platforms etc
>> etc
> 
> I don't think you are expecting detailed schedule from me. Passing
> structure by value is possible on all platforms ghc supports, and it can
> be implemented for any particular platform if somebody is interested.
> 
> From my point of view, at this point it is more important to agree on
> the next question: do we want such functionality in ghc at all? I don't
> want to waste time on it if nobody wants to see it merged.

I still don?t see the benefit in further complicating an already murky corner of the compiler. Moreover, for this to make sense, it would need to work on all supported platforms. Unless you are volunteering to implement it on multiple platforms, this would mean, we?d use libffi for most platforms anyway. This brings me to my original point, a library or tool is the better place for this.

Manuel

PS: I?d happily accept language-c-inline patches for marshalling structs.

> On Sat, 2014-03-15 at 00:37 -0400, Carter Schonwald wrote:
>> I'm not opposing that, in fact, theres a GHC ticket discussing some stuff
>> related to this (related to complex numbers).
>> 
>> i think the crux of Manuel's point is mainly that any good proposal has to
>> at least give a roadmap to support on all the various platforms etc etc
>> 
>> 
>> On Sat, Mar 15, 2014 at 12:33 AM, Edward Kmett <ekmett at gmail.com> wrote:
>> 
>>> I don't care enough to fight and try to win the battle, but I just want to
>>> point out that Storable structs are far more brittle and platform dependent
>>> than borrowing the already correct platform logic for struct passing from
>>> libffi.
>>> 
>>> I do think the existing FFI extension made the right call under the 32 bit
>>> ABIs that were in use at the time it was defined. That said, with 64-bit
>>> ABIs saying that 2 32-bit ints should be passed in a single 64 bit
>>> register, you wind up with large chunks of third party APIs we just can't
>>> call out to directly any more, requiring many one-off manual C shims.
>>> 
>>> -Edward
>>> 
>>> 
>>> 
>>> 
>>> On Sat, Mar 15, 2014 at 12:17 AM, Carter Schonwald <
>>> carter.schonwald at gmail.com> wrote:
>>> 
>>>> indeed, its very very easy to do storable instances that correspond to
>>>> the struct type you want,
>>>> 
>>>> the ``with`` function in
>>>> http://hackage.haskell.org/package/base-4.6.0.1/docs/Foreign-Marshal-Utils.htmlforeigh.marshal.utils actually gets you most of the way there!
>>>> 
>>>> 
>>>> 
>>>> 
>>>> On Sat, Mar 15, 2014 at 12:00 AM, Manuel M T Chakravarty <
>>>> chak at cse.unsw.edu.au> wrote:
>>>> 
>>>>> Yuras,
>>>>> 
>>>>> I?m not convinced that the compiler is the right place for this kind of
>>>>> functionality. In fact, when we designed the Haskell FFI, we explicit
>>>>> decided against what you propose. There are a few reasons for this.
>>>>> 
>>>>> Firstly, compilers are complex beasts, and secondly, it takes a long
>>>>> time until a change in the compiler goes into production. Hence, as a
>>>>> general rule, it is advisable to move complexity from the compiler into
>>>>> libraries as this reduces compiler complexity. Libraries are less complex
>>>>> and changes can be rolled out much more quickly (it?s essentially a Hackage
>>>>> upload versus waiting for the next GHC and Haskell Platform release).
>>>>> 
>>>>> Thirdly, we have got the Haskell standard for a reason and modifying the
>>>>> compiler implies a language extension.
>>>>> 
>>>>> The design goal for the Haskell FFI was to provide the absolute minimum
>>>>> as part of the language and compiler, and to layer additional conveniences
>>>>> on top of that in the form of libraries and tools.
>>>>> 
>>>>> Have you considered the library or tool route?
>>>>> 
>>>>> Manuel
>>>>> 
>>>>> Yuras Shumovich <shumovichy at gmail.com>:
>>>>>> Hi,
>>>>>> 
>>>>>> Right now ghc's FFI doesn't support c/c++ structures.
>>>>>> 
>>>>>> Whenever we have foreign function that accepts or returns struct by
>>>>>> value, we have to create wrapper that accepts or returns pointer to
>>>>>> struct. It is inconvenient, but actually not a big deal.
>>>>>> 
>>>>>> But there is no easy workaround when you want to export haskell
>>>>> function
>>>>>> to use it with c/c++ API that requires structures to be passed by value
>>>>>> (Usually it is a callback in c/c++ API. You can't change it's
>>>>> signature,
>>>>>> and if it doesn't provide some kind of "void* userdata", then you are
>>>>>> stuck.)
>>>>>> 
>>>>>> I'm interested in fixing that. I'm going to start with 'foreign import
>>>>>> "wrapper" ...' stuff.
>>>>>> 
>>>>>> Calling conventions for passing c/c++ structures by value are pretty
>>>>>> tricky and platform/compiler specific. So initially I'll use libffi for
>>>>>> that (it will work when USE_LIBFFI_FOR_ADJUSTORS is defined, see
>>>>>> rts/Adjustor.c). It will allow me to explore design space without
>>>>>> bothering about low level implementation details. Later it could be
>>>>>> implemented for native (non-libffi) adjustors.
>>>>>> 
>>>>>> Is anybody interested it that? I appreciate any comments/ideas.
>>>>>> 
>>>>>> Right now I don't have clear design. It would be nice to support plain
>>>>>> haskell data types that are 1) not recursive, 2) has one constructor
>>>>> and
>>>>>> 3) contains only c/c++ types. But it doesn't work with c/c++ unions.
>>>>> Any
>>>>>> ideas are welcome.
>>>>>> 
>>>>>> An example how to use libffi with structures:
>>>>>> http://www.atmark-techno.com/~yashi/libffi.html#Structures
>>>>>> 
>>>>>> Thanks,
>>>>>> Yuras
>>>>>> 
>>>>>> 
>>>>>> _______________________________________________
>>>>>> ghc-devs mailing list
>>>>>> ghc-devs at haskell.org
>>>>>> http://www.haskell.org/mailman/listinfo/ghc-devs
>>>>> 
>>>>> _______________________________________________
>>>>> ghc-devs mailing list
>>>>> ghc-devs at haskell.org
>>>>> http://www.haskell.org/mailman/listinfo/ghc-devs
>>>>> 
>>>> 
>>>> 
>>>> _______________________________________________
>>>> ghc-devs mailing list
>>>> ghc-devs at haskell.org
>>>> http://www.haskell.org/mailman/listinfo/ghc-devs
>>>> 
>>>> 
>>> 
>> _______________________________________________
>> ghc-devs mailing list
>> ghc-devs at haskell.org
>> http://www.haskell.org/mailman/listinfo/ghc-devs
> 
> 
> _______________________________________________
> ghc-devs mailing list
> ghc-devs at haskell.org
> http://www.haskell.org/mailman/listinfo/ghc-devs


From petersen at fedoraproject.org  Tue Mar 18 10:02:24 2014
From: petersen at fedoraproject.org (Jens Petersen)
Date: Tue, 18 Mar 2014 19:02:24 +0900
Subject: ghc-7.8.1 RC2 ppc dyn linked executable segfaults
Message-ID: <CAEDGBqKnddMLTX3ZqYpyx=UaZxNS+WH2w93M+hfuw+MYHgUh7A@mail.gmail.com>

>
> http://www.haskell.org/ghc/dist/7.8.1-rc2/
>>
>>

> A test build on ppc completed but then the dyn executable sanity check
> failed (not yet sure why):
> http://ppc.koji.fedoraproject.org/koji/taskinfo?taskID=1707922
>

The ppc64 build looks okay, but ppc seems to have a problem with
executables dyn linked to Haskell libs segfaulting.

Is anyone able to reproduce this on Linux/ppc (32bit)?  Debian?

I don't have access yet to a ppc box to investigate further but I see the
segfault for "ghc -dynamic Hello.hs; ./Hello" on ppc in the fedora buildsys.

http://ppc.koji.fedoraproject.org/kojifiles/work/tasks/1459/1711459/build.log&offset=-4000("ghc
-v -dynamic Foo.hs") [1]

I guess I should file a bug anyway.  I sent a heads-up mail to Gustavo too.

Jens

[1] full log is
http://ppc.koji.fedoraproject.org/kojifiles/work/tasks/1459/1711459/build.log[4.9MB]
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/ghc-devs/attachments/20140318/2386789b/attachment.html>

From hvr at gnu.org  Tue Mar 18 10:58:36 2014
From: hvr at gnu.org (Herbert Valerio Riedel)
Date: Tue, 18 Mar 2014 11:58:36 +0100
Subject: HEADS-UP: new server-side validation git hook for submodule updates &
 call-for-help
Message-ID: <87pplj7oyr.fsf@gmail.com>

Hello *,

I've put in place a new server-side validation hook a few days ago, and
since nobody seemed to have complained yet, I assume it didn't have any
adverse effects so far :-)

It will only be triggered when Git submodule references are touched by a
commit; you can find some preliminary (but incomplete) documentation and
a sample session triggering validation-failure on purpose at

  https://ghc.haskell.org/trac/ghc/ticket/8251#comment:4

(this will be turned into a proper wiki-page once #8251 is completed;
there's some minor details wrt some corner cases that still need to be
looked at)

So, this mostly addresses the server-side requirements for migrating to
a proper git-submodule set-up for ghc.git;

The next steps, however, include taking care of the client-side work-flow
for working with a fully "submoduled" ghc.git setup. Personally, I'm
quite comfortable using direct git commands to manage such a construct,
but I'm well aware not everyone is (as previous discussions here have
shown). Also, as my time is rather limited, I'd like to ask interested
parties to join in and help formulate the future client-side work-flow[1]
and/or update (or rewrite) the 'sync-all' to provide a seamless or at
least smooth transition for those GHC devs who want to keep using
"sync-all" instead of using direct Git commands.


 [1]: There's some difference in how tracked upstream packages and
      GHC-HQ owned sub-repos are to be handled workflow-wise, to avoid
      ending up with a noisy ghc.git history. 

      For instance, having ghc.git with submodules is not the same as
      having a huge monolithic ghc.git repository with all subrepos
      embedded. specifically, it might not be sensible to propagate
      *every* single subrepo-commit as a separate ghc.git submod-ref
      update, but rather in logical batches (N.B.: using submodules
      gives the additional ability to git bisect within subrepos instead
      of having to bisect always only at top-level). This is one example
      of things to discuss/consider when designing the new work-flow.

Cheers,
  hvr

From shumovichy at gmail.com  Tue Mar 18 11:42:29 2014
From: shumovichy at gmail.com (Yuras Shumovich)
Date: Tue, 18 Mar 2014 14:42:29 +0300
Subject: FFI: c/c++ struct on stack as an argument or return value
In-Reply-To: <C86323E1-F09A-4FDA-88BD-6D28A1D28F83@cse.unsw.edu.au>
References: <1394797839.4664.35.camel@shum-lt>
 <5F969E34-BCF1-40CB-86DF-20F84245BEDB@cse.unsw.edu.au>
 <CAHYVw0xugANXO43pxA5yPH3xpZ4CxKOBA6UetwNAPa6XfLD0Ew@mail.gmail.com>
 <CAJumaK-KakS9=9ksGnOj9p6qYq3KmfoZwyCGju7d1kyytwcg8Q@mail.gmail.com>
 <CAHYVw0wje9Ju_rUfCQUeN=qRtbBs_aJ8TSY+75P3bH89vAJEHA@mail.gmail.com>
 <1394887862.4722.31.camel@shum-lt>
 <C86323E1-F09A-4FDA-88BD-6D28A1D28F83@cse.unsw.edu.au>
Message-ID: <1395142949.4601.18.camel@shum-lt>

On Tue, 2014-03-18 at 12:37 +1100, Manuel M T Chakravarty wrote:
> > 
> > Library implementation can't generate native dynamic wrapper, it has to
> > use slow libffi.
> 
> When we first implemented the FFI, there was no libffi. Maintaining the adjustor code for all platforms is a PITA; hence, using libffi was a welcome way to improve portability.

Do you think we can remove native adjustors? I can prepare a patch.

It requires minor changes to cache ffi_cif structure. On desugar phase
for each wrapper we can generate fresh global variable to store cif
pointer and pass it to createAdjustor.

> 
> > 
> > From my point of view, at this point it is more important to agree on
> > the next question: do we want such functionality in ghc at all? I don't
> > want to waste time on it if nobody wants to see it merged.
> 
> I still don?t see the benefit in further complicating an already murky corner of the compiler. Moreover, for this to make sense, it would need to work on all supported platforms. Unless you are volunteering to implement it on multiple platforms, this would mean, we?d use libffi for most platforms anyway. This brings me to my original point, a library or tool is the better place for this.

OK, I don't buy it, but I see your point.

> 
> Manuel
> 
> PS: I?d happily accept language-c-inline patches for marshalling structs.
> 



From marlowsd at gmail.com  Tue Mar 18 12:19:00 2014
From: marlowsd at gmail.com (Simon Marlow)
Date: Tue, 18 Mar 2014 12:19:00 +0000
Subject: FFI: c/c++ struct on stack as an argument or return value
In-Reply-To: <C86323E1-F09A-4FDA-88BD-6D28A1D28F83@cse.unsw.edu.au>
References: <1394797839.4664.35.camel@shum-lt>
 <5F969E34-BCF1-40CB-86DF-20F84245BEDB@cse.unsw.edu.au>
 <CAHYVw0xugANXO43pxA5yPH3xpZ4CxKOBA6UetwNAPa6XfLD0Ew@mail.gmail.com>
 <CAJumaK-KakS9=9ksGnOj9p6qYq3KmfoZwyCGju7d1kyytwcg8Q@mail.gmail.com>
 <CAHYVw0wje9Ju_rUfCQUeN=qRtbBs_aJ8TSY+75P3bH89vAJEHA@mail.gmail.com>
 <1394887862.4722.31.camel@shum-lt>
 <C86323E1-F09A-4FDA-88BD-6D28A1D28F83@cse.unsw.edu.au>
Message-ID: <532839B4.7040609@gmail.com>

On 18/03/2014 01:37, Manuel M T Chakravarty wrote:
> Yuras Shumovich <shumovichy at gmail.com>:
>> I think the compiler is the right place. It is impossible to have
>> efficient implementation in a library.
>>
>> For dynamic wrapper (foreign import "wrapper" stuff) ghc generates piece
>> of executable code at runtime. There are native implementations for a
>> number of platforms, and libffi is used as a fall back for other
>> platforms (see rts/Adjustor.c). AFAIK it is done that way because libffi
>> is slower then native implementation.
>>
>> Library implementation can't generate native dynamic wrapper, it has to
>> use slow libffi.
>
> When we first implemented the FFI, there was no libffi. Maintaining the adjustor code for all platforms is a PITA; hence, using libffi was a welcome way to improve portability.
>
> Making the adjustor code more complicated by adding more functionality doesn?t sound like a good plan to me.
>
> Besides, there are other overheads in addition to the actual marshalling in FFI calls and most of the time we are calling out to library functions for which the FFI call overhead is only a small portion of the runtime.
 >
>>> i think the crux of Manuel's point is mainly that any good proposal
>>> has to
>>> at least give a roadmap to support on all the various platforms etc
>>> etc
>>
>> I don't think you are expecting detailed schedule from me. Passing
>> structure by value is possible on all platforms ghc supports, and it can
>> be implemented for any particular platform if somebody is interested.
>>
>>  From my point of view, at this point it is more important to agree on
>> the next question: do we want such functionality in ghc at all? I don't
>> want to waste time on it if nobody wants to see it merged.

I'm really keen to have support for returning structs in particular. 
Passing structs less so, because working around the lack of struct 
passing isn't nearly as onerous as working around the lack of struct 
returns.  Returning multiple values from a C function is a real pain 
without struct returns: you have to either allocate some memory in 
Haskell or in C, and both methods are needlessly complex and slow. 
(though allocating in Haskell is usually better.) C++ code does this all 
the time, so if you're wrapping C++ code for calling from Haskell, the 
lack of multiple returns bites a lot.

In fact implementing this is on my todo list, I'm really glad to see 
someone else is planning to do it :-)

The vague plan I had in my head was to allow the return value of a 
foreign import to be a tuple containing marshallable types, which would 
map to the appropriate return convention for a struct on the current 
platform.  Perhaps allowing it to be an arbitrary single-constructor 
type is better, because it allows us to use a type that has a Storable 
instance.

Cheers,
Simon


> I still don?t see the benefit in further complicating an already murky corner of the compiler. Moreover, for this to make sense, it would need to work on all supported platforms. Unless you are volunteering to implement it on multiple platforms, this would mean, we?d use libffi for most platforms anyway. This brings me to my original point, a library or tool is the better place for this.
>
> Manuel
>
> PS: I?d happily accept language-c-inline patches for marshalling structs.
>
>> On Sat, 2014-03-15 at 00:37 -0400, Carter Schonwald wrote:
>>> I'm not opposing that, in fact, theres a GHC ticket discussing some stuff
>>> related to this (related to complex numbers).
>>>
>>> i think the crux of Manuel's point is mainly that any good proposal has to
>>> at least give a roadmap to support on all the various platforms etc etc
>>>
>>>
>>> On Sat, Mar 15, 2014 at 12:33 AM, Edward Kmett <ekmett at gmail.com> wrote:
>>>
>>>> I don't care enough to fight and try to win the battle, but I just want to
>>>> point out that Storable structs are far more brittle and platform dependent
>>>> than borrowing the already correct platform logic for struct passing from
>>>> libffi.
>>>>
>>>> I do think the existing FFI extension made the right call under the 32 bit
>>>> ABIs that were in use at the time it was defined. That said, with 64-bit
>>>> ABIs saying that 2 32-bit ints should be passed in a single 64 bit
>>>> register, you wind up with large chunks of third party APIs we just can't
>>>> call out to directly any more, requiring many one-off manual C shims.
>>>>
>>>> -Edward
>>>>
>>>>
>>>>
>>>>
>>>> On Sat, Mar 15, 2014 at 12:17 AM, Carter Schonwald <
>>>> carter.schonwald at gmail.com> wrote:
>>>>
>>>>> indeed, its very very easy to do storable instances that correspond to
>>>>> the struct type you want,
>>>>>
>>>>> the ``with`` function in
>>>>> http://hackage.haskell.org/package/base-4.6.0.1/docs/Foreign-Marshal-Utils.htmlforeigh.marshal.utils actually gets you most of the way there!
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> On Sat, Mar 15, 2014 at 12:00 AM, Manuel M T Chakravarty <
>>>>> chak at cse.unsw.edu.au> wrote:
>>>>>
>>>>>> Yuras,
>>>>>>
>>>>>> I?m not convinced that the compiler is the right place for this kind of
>>>>>> functionality. In fact, when we designed the Haskell FFI, we explicit
>>>>>> decided against what you propose. There are a few reasons for this.
>>>>>>
>>>>>> Firstly, compilers are complex beasts, and secondly, it takes a long
>>>>>> time until a change in the compiler goes into production. Hence, as a
>>>>>> general rule, it is advisable to move complexity from the compiler into
>>>>>> libraries as this reduces compiler complexity. Libraries are less complex
>>>>>> and changes can be rolled out much more quickly (it?s essentially a Hackage
>>>>>> upload versus waiting for the next GHC and Haskell Platform release).
>>>>>>
>>>>>> Thirdly, we have got the Haskell standard for a reason and modifying the
>>>>>> compiler implies a language extension.
>>>>>>
>>>>>> The design goal for the Haskell FFI was to provide the absolute minimum
>>>>>> as part of the language and compiler, and to layer additional conveniences
>>>>>> on top of that in the form of libraries and tools.
>>>>>>
>>>>>> Have you considered the library or tool route?
>>>>>>
>>>>>> Manuel
>>>>>>
>>>>>> Yuras Shumovich <shumovichy at gmail.com>:
>>>>>>> Hi,
>>>>>>>
>>>>>>> Right now ghc's FFI doesn't support c/c++ structures.
>>>>>>>
>>>>>>> Whenever we have foreign function that accepts or returns struct by
>>>>>>> value, we have to create wrapper that accepts or returns pointer to
>>>>>>> struct. It is inconvenient, but actually not a big deal.
>>>>>>>
>>>>>>> But there is no easy workaround when you want to export haskell
>>>>>> function
>>>>>>> to use it with c/c++ API that requires structures to be passed by value
>>>>>>> (Usually it is a callback in c/c++ API. You can't change it's
>>>>>> signature,
>>>>>>> and if it doesn't provide some kind of "void* userdata", then you are
>>>>>>> stuck.)
>>>>>>>
>>>>>>> I'm interested in fixing that. I'm going to start with 'foreign import
>>>>>>> "wrapper" ...' stuff.
>>>>>>>
>>>>>>> Calling conventions for passing c/c++ structures by value are pretty
>>>>>>> tricky and platform/compiler specific. So initially I'll use libffi for
>>>>>>> that (it will work when USE_LIBFFI_FOR_ADJUSTORS is defined, see
>>>>>>> rts/Adjustor.c). It will allow me to explore design space without
>>>>>>> bothering about low level implementation details. Later it could be
>>>>>>> implemented for native (non-libffi) adjustors.
>>>>>>>
>>>>>>> Is anybody interested it that? I appreciate any comments/ideas.
>>>>>>>
>>>>>>> Right now I don't have clear design. It would be nice to support plain
>>>>>>> haskell data types that are 1) not recursive, 2) has one constructor
>>>>>> and
>>>>>>> 3) contains only c/c++ types. But it doesn't work with c/c++ unions.
>>>>>> Any
>>>>>>> ideas are welcome.
>>>>>>>
>>>>>>> An example how to use libffi with structures:
>>>>>>> http://www.atmark-techno.com/~yashi/libffi.html#Structures
>>>>>>>
>>>>>>> Thanks,
>>>>>>> Yuras
>>>>>>>
>>>>>>>
>>>>>>> _______________________________________________
>>>>>>> ghc-devs mailing list
>>>>>>> ghc-devs at haskell.org
>>>>>>> http://www.haskell.org/mailman/listinfo/ghc-devs
>>>>>>
>>>>>> _______________________________________________
>>>>>> ghc-devs mailing list
>>>>>> ghc-devs at haskell.org
>>>>>> http://www.haskell.org/mailman/listinfo/ghc-devs
>>>>>>
>>>>>
>>>>>
>>>>> _______________________________________________
>>>>> ghc-devs mailing list
>>>>> ghc-devs at haskell.org
>>>>> http://www.haskell.org/mailman/listinfo/ghc-devs
>>>>>
>>>>>
>>>>
>>> _______________________________________________
>>> ghc-devs mailing list
>>> ghc-devs at haskell.org
>>> http://www.haskell.org/mailman/listinfo/ghc-devs
>>
>>
>> _______________________________________________
>> ghc-devs mailing list
>> ghc-devs at haskell.org
>> http://www.haskell.org/mailman/listinfo/ghc-devs
>
> _______________________________________________
> ghc-devs mailing list
> ghc-devs at haskell.org
> http://www.haskell.org/mailman/listinfo/ghc-devs
>

From simonpj at microsoft.com  Tue Mar 18 12:25:00 2014
From: simonpj at microsoft.com (Simon Peyton Jones)
Date: Tue, 18 Mar 2014 12:25:00 +0000
Subject: HEADS-UP: new server-side validation git hook for submodule
 updates & call-for-help
In-Reply-To: <87pplj7oyr.fsf@gmail.com>
References: <87pplj7oyr.fsf@gmail.com>
Message-ID: <59543203684B2244980D7E4057D5FBC148806764@DB3EX14MBXC308.europe.corp.microsoft.com>

Herbert 

I really appreciate the work you are doing here -- thank you.

As a client, though, I'm very ignorant about submodules, so I do need education about the work-flows that I should follow.  If there are things I must or must not do, I need telling about them.

Much is taken care of by sync-all, which is great.  If that continues to be the case, I'm happy!

Simon

| -----Original Message-----
| From: ghc-devs [mailto:ghc-devs-bounces at haskell.org] On Behalf Of
| Herbert Valerio Riedel
| Sent: 18 March 2014 10:59
| To: ghc-devs
| Subject: HEADS-UP: new server-side validation git hook for submodule
| updates & call-for-help
| 
| Hello *,
| 
| I've put in place a new server-side validation hook a few days ago, and
| since nobody seemed to have complained yet, I assume it didn't have any
| adverse effects so far :-)
| 
| It will only be triggered when Git submodule references are touched by a
| commit; you can find some preliminary (but incomplete) documentation and
| a sample session triggering validation-failure on purpose at
| 
|   https://ghc.haskell.org/trac/ghc/ticket/8251#comment:4
| 
| (this will be turned into a proper wiki-page once #8251 is completed;
| there's some minor details wrt some corner cases that still need to be
| looked at)
| 
| So, this mostly addresses the server-side requirements for migrating to
| a proper git-submodule set-up for ghc.git;
| 
| The next steps, however, include taking care of the client-side work-
| flow for working with a fully "submoduled" ghc.git setup. Personally,
| I'm quite comfortable using direct git commands to manage such a
| construct, but I'm well aware not everyone is (as previous discussions
| here have shown). Also, as my time is rather limited, I'd like to ask
| interested parties to join in and help formulate the future client-side
| work-flow[1] and/or update (or rewrite) the 'sync-all' to provide a
| seamless or at least smooth transition for those GHC devs who want to
| keep using "sync-all" instead of using direct Git commands.
| 
| 
|  [1]: There's some difference in how tracked upstream packages and
|       GHC-HQ owned sub-repos are to be handled workflow-wise, to avoid
|       ending up with a noisy ghc.git history.
| 
|       For instance, having ghc.git with submodules is not the same as
|       having a huge monolithic ghc.git repository with all subrepos
|       embedded. specifically, it might not be sensible to propagate
|       *every* single subrepo-commit as a separate ghc.git submod-ref
|       update, but rather in logical batches (N.B.: using submodules
|       gives the additional ability to git bisect within subrepos instead
|       of having to bisect always only at top-level). This is one example
|       of things to discuss/consider when designing the new work-flow.
| 
| Cheers,
|   hvr
| _______________________________________________
| ghc-devs mailing list
| ghc-devs at haskell.org
| http://www.haskell.org/mailman/listinfo/ghc-devs

From shumovichy at gmail.com  Tue Mar 18 17:31:19 2014
From: shumovichy at gmail.com (Yuras Shumovich)
Date: Tue, 18 Mar 2014 20:31:19 +0300
Subject: FFI: c/c++ struct on stack as an argument or return value
In-Reply-To: <532839B4.7040609@gmail.com>
References: <1394797839.4664.35.camel@shum-lt>
 <5F969E34-BCF1-40CB-86DF-20F84245BEDB@cse.unsw.edu.au>
 <CAHYVw0xugANXO43pxA5yPH3xpZ4CxKOBA6UetwNAPa6XfLD0Ew@mail.gmail.com>
 <CAJumaK-KakS9=9ksGnOj9p6qYq3KmfoZwyCGju7d1kyytwcg8Q@mail.gmail.com>
 <CAHYVw0wje9Ju_rUfCQUeN=qRtbBs_aJ8TSY+75P3bH89vAJEHA@mail.gmail.com>
 <1394887862.4722.31.camel@shum-lt>
 <C86323E1-F09A-4FDA-88BD-6D28A1D28F83@cse.unsw.edu.au>
 <532839B4.7040609@gmail.com>
Message-ID: <1395163879.4601.35.camel@shum-lt>

Hi,

I thought I have lost the battle :)
Thank you for the support, Simon!

I'm interested in full featured solution: arguments, return value,
foreign import, foreign export, etc. But it is too much for me to do it
all at once. So I started with dynamic wrapper.

The plan is to support structs as arguments and return value for dynamic
wrapper using libffi;
then implement native adjustors at least for x86_64 linux;
then make final design decision (tuple or data? language pragma? union
support? etc);
and only then start working on foreign import. 

But I'm open for suggestions. Just let me know if you think it is better
to start with return value support for foreign import. 

Thanks,
Yuras

On Tue, 2014-03-18 at 12:19 +0000, Simon Marlow wrote:
> I'm really keen to have support for returning structs in particular. 
> Passing structs less so, because working around the lack of struct 
> passing isn't nearly as onerous as working around the lack of struct 
> returns.  Returning multiple values from a C function is a real pain 
> without struct returns: you have to either allocate some memory in 
> Haskell or in C, and both methods are needlessly complex and slow. 
> (though allocating in Haskell is usually better.) C++ code does this all 
> the time, so if you're wrapping C++ code for calling from Haskell, the 
> lack of multiple returns bites a lot.
> 
> In fact implementing this is on my todo list, I'm really glad to see 
> someone else is planning to do it :-)
> 
> The vague plan I had in my head was to allow the return value of a 
> foreign import to be a tuple containing marshallable types, which would 
> map to the appropriate return convention for a struct on the current 
> platform.  Perhaps allowing it to be an arbitrary single-constructor 
> type is better, because it allows us to use a type that has a Storable 
> instance.
> 
> Cheers,
> Simon
> 



From simonpj at microsoft.com  Tue Mar 18 17:20:06 2014
From: simonpj at microsoft.com (Simon Peyton Jones)
Date: Tue, 18 Mar 2014 17:20:06 +0000
Subject: Pretty printing
Message-ID: <59543203684B2244980D7E4057D5FBC14880743A@DB3EX14MBXC308.europe.corp.microsoft.com>

Gergo
I'm a bit out of date... did you update those test results etc to get to clean validate?
S
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/ghc-devs/attachments/20140318/03d4b396/attachment-0001.html>

From johan.tibell at gmail.com  Tue Mar 18 18:17:55 2014
From: johan.tibell at gmail.com (Johan Tibell)
Date: Tue, 18 Mar 2014 19:17:55 +0100
Subject: HEADS-UP: new server-side validation git hook for submodule
 updates & call-for-help
In-Reply-To: <87pplj7oyr.fsf@gmail.com>
References: <87pplj7oyr.fsf@gmail.com>
Message-ID: <CAK-tuPZHKJQp2-psKRpPe1iSD_OR+TZAzrgKKHZgOhxQFd3wzA@mail.gmail.com>

Lets give some example workflows for working with submodules. Here's what I
think a raw (i.e. no sync-all) update to base will look like. Please
correct me if I'm wrong.

# Step 1:
cd ~/src/ghc/libraries/base
# edit some_file
git add some_file
git commit -m "Commit to base repo"
git push  # push update to base to git.haskell.org

# Step 2
cd ~/src/ghc
git add libraries/base
git commit -m "Have GHC use the new base version"
git push  # push update to ghc to git.haskell.org

Failure modes include:

 * Forgetting step 2: the ghc repo will point to a slightly older base next
time someone checks it out. Fixing things when in this state: just perform
step 2.
 * Forgetting `git push` in step 1. the ghc repo will point to a base
commit that doesn't exist (except on some developers machine).  Fixing
things when in this state: the developer who forgot to `git push` in step 1
needs to do that.

How could sync-all help us:

 * sync-all push could push all repos, preventing failure case 2 above.

The second interesting workflow involving pulling new changes. This is what
the raw (i.e. no sync-all) workflow will look like:

cd ~/src/ghc
git pull
git submodule update

Failure modes include:

 * Forgetting the `submodule update` and then doing e.g. `git commit -am
"some compile commit"`, reverting the pointer to e.g. base to whatever
older version the developer was using. No commits are lost (nothing changes
in the base repo), but the ghc repo will point to an older commit.

How could sync-all help us:

 * sync-all pull could always run `submodule update`.

The server-side check that Herbert added will make sure that the failure
mode cannot happen, as you explicitly have to say in the commit message
that you updated a submodule.

I think if base was folded into ghc.git very few people would have to deal
with submodules.

On Tue, Mar 18, 2014 at 11:58 AM, Herbert Valerio Riedel <hvr at gnu.org>wrote:

> Hello *,
>
> I've put in place a new server-side validation hook a few days ago, and
> since nobody seemed to have complained yet, I assume it didn't have any
> adverse effects so far :-)
>
> It will only be triggered when Git submodule references are touched by a
> commit; you can find some preliminary (but incomplete) documentation and
> a sample session triggering validation-failure on purpose at
>
>   https://ghc.haskell.org/trac/ghc/ticket/8251#comment:4
>
> (this will be turned into a proper wiki-page once #8251 is completed;
> there's some minor details wrt some corner cases that still need to be
> looked at)
>
> So, this mostly addresses the server-side requirements for migrating to
> a proper git-submodule set-up for ghc.git;
>
> The next steps, however, include taking care of the client-side work-flow
> for working with a fully "submoduled" ghc.git setup. Personally, I'm
> quite comfortable using direct git commands to manage such a construct,
> but I'm well aware not everyone is (as previous discussions here have
> shown). Also, as my time is rather limited, I'd like to ask interested
> parties to join in and help formulate the future client-side work-flow[1]
> and/or update (or rewrite) the 'sync-all' to provide a seamless or at
> least smooth transition for those GHC devs who want to keep using
> "sync-all" instead of using direct Git commands.
>
>
>  [1]: There's some difference in how tracked upstream packages and
>       GHC-HQ owned sub-repos are to be handled workflow-wise, to avoid
>       ending up with a noisy ghc.git history.
>
>       For instance, having ghc.git with submodules is not the same as
>       having a huge monolithic ghc.git repository with all subrepos
>       embedded. specifically, it might not be sensible to propagate
>       *every* single subrepo-commit as a separate ghc.git submod-ref
>       update, but rather in logical batches (N.B.: using submodules
>       gives the additional ability to git bisect within subrepos instead
>       of having to bisect always only at top-level). This is one example
>       of things to discuss/consider when designing the new work-flow.
>
> Cheers,
>   hvr
> _______________________________________________
> ghc-devs mailing list
> ghc-devs at haskell.org
> http://www.haskell.org/mailman/listinfo/ghc-devs
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/ghc-devs/attachments/20140318/a00544e8/attachment.html>

From fuuzetsu at fuuzetsu.co.uk  Tue Mar 18 18:20:20 2014
From: fuuzetsu at fuuzetsu.co.uk (Mateusz Kowalczyk)
Date: Tue, 18 Mar 2014 18:20:20 +0000
Subject: Haddock strings in .hi files
Message-ID: <53288E64.8060704@fuuzetsu.co.uk>

Hi all,

I saw https://ghc.haskell.org/trac/ghc/ticket/5467 pop up in my inbox
and it reminded me of something I've been wondering for a while: why do
we not store Haddock docstrings in the interface file?

I think that if we did, we could do some great things:

1. Show docs in GHCi (I vaguely recall someone working on this ~1 year
ago, does anyone have any info?)

2. Allow Haddock to work a lot faster: the big majority of time spent
when creating documentation is actually spent by Haddock calling various
GHC functions, such as type-checking the modules. Only a small amount of
time is actually spent by Haddock on other tasks such as parsing or
outputting the documentation. If we could simply get everything we need
from the .hi files, we save ourselves a lot of time.

3. Allow Haddock to create partial documentation: a complaint I
sometimes hear is if anything at all in the project doesn't type check,
we don't get any documentation at all. I think that it'd be viable to
generate only the documentation for the modules/functions that do
type-check and perhaps skip type signatures for everything else.

Points 1. and 2. are of clear benefit. Point 3. is a simple afterthought
and thinking about it some more, I think that maybe it'd be possible to
do this with what we have right now: is type-checking separate parts of
the module supported? Can we retrieve documentation for the parts that
don't type-check?

I am asking for input on what people think. I am not familiar at all
with what goes into the .hi file (and I can't find anything concrete! Am
I missing some wiki page?) at all and why. At the very least, 1. should
be easy to implement.

It was suggested that I submit a proposal for this as part of GSoC,
namely implementing 1. and 2.. I admit that having much faster
documentation builds would be amazing and Edward K. and Carter S. seem
to think that this is very do-able in the 3 month period that GSoC runs
over.

While I say all this, I have already submitted my proposal on a
different topic. I am considering writing this up and submitting this as
well but I am looking for some insight into the problem first.

If there are any students around still looking for ideas, please do
speak up if you want to snatch this. If there are people that are eager
to mentor something like this then I suppose they should speak up too.

Thanks!

-- 
Mateusz K.

From marlowsd at gmail.com  Tue Mar 18 21:30:17 2014
From: marlowsd at gmail.com (Simon Marlow)
Date: Tue, 18 Mar 2014 21:30:17 +0000
Subject: FFI: c/c++ struct on stack as an argument or return value
In-Reply-To: <1395163879.4601.35.camel@shum-lt>
References: <1394797839.4664.35.camel@shum-lt>	
 <5F969E34-BCF1-40CB-86DF-20F84245BEDB@cse.unsw.edu.au>	
 <CAHYVw0xugANXO43pxA5yPH3xpZ4CxKOBA6UetwNAPa6XfLD0Ew@mail.gmail.com>	
 <CAJumaK-KakS9=9ksGnOj9p6qYq3KmfoZwyCGju7d1kyytwcg8Q@mail.gmail.com>	
 <CAHYVw0wje9Ju_rUfCQUeN=qRtbBs_aJ8TSY+75P3bH89vAJEHA@mail.gmail.com>	
 <1394887862.4722.31.camel@shum-lt>	
 <C86323E1-F09A-4FDA-88BD-6D28A1D28F83@cse.unsw.edu.au>	
 <532839B4.7040609@gmail.com> <1395163879.4601.35.camel@shum-lt>
Message-ID: <5328BAE9.6080805@gmail.com>

So the hard parts are:

  - the native code generators
  - native adjustor support (rts/Adjustor.c)

Everything else is relatively striaghtforward: we use libffi for 
adjustors on some platforms and for GHCi, and the LLVM backend should be 
quite easy too.

I would at least take a look at the hard bits and see whether you think 
it's going to be possible to extend these to handle struct args/returns. 
  Because if not, then the idea is a dead end.  Or maybe we will need to 
limit the scope to make things easier (e.g. only integer and pointer 
fields).

Cheers,
Simon

On 18/03/2014 17:31, Yuras Shumovich wrote:
> Hi,
>
> I thought I have lost the battle :)
> Thank you for the support, Simon!
>
> I'm interested in full featured solution: arguments, return value,
> foreign import, foreign export, etc. But it is too much for me to do it
> all at once. So I started with dynamic wrapper.
>
> The plan is to support structs as arguments and return value for dynamic
> wrapper using libffi;
> then implement native adjustors at least for x86_64 linux;
> then make final design decision (tuple or data? language pragma? union
> support? etc);
> and only then start working on foreign import.
>
> But I'm open for suggestions. Just let me know if you think it is better
> to start with return value support for foreign import.
>
> Thanks,
> Yuras
>
> On Tue, 2014-03-18 at 12:19 +0000, Simon Marlow wrote:
>> I'm really keen to have support for returning structs in particular.
>> Passing structs less so, because working around the lack of struct
>> passing isn't nearly as onerous as working around the lack of struct
>> returns.  Returning multiple values from a C function is a real pain
>> without struct returns: you have to either allocate some memory in
>> Haskell or in C, and both methods are needlessly complex and slow.
>> (though allocating in Haskell is usually better.) C++ code does this all
>> the time, so if you're wrapping C++ code for calling from Haskell, the
>> lack of multiple returns bites a lot.
>>
>> In fact implementing this is on my todo list, I'm really glad to see
>> someone else is planning to do it :-)
>>
>> The vague plan I had in my head was to allow the return value of a
>> foreign import to be a tuple containing marshallable types, which would
>> map to the appropriate return convention for a struct on the current
>> platform.  Perhaps allowing it to be an arbitrary single-constructor
>> type is better, because it allows us to use a type that has a Storable
>> instance.
>>
>> Cheers,
>> Simon
>>
>
>

From hvr at gnu.org  Tue Mar 18 21:32:05 2014
From: hvr at gnu.org (Herbert Valerio Riedel)
Date: Tue, 18 Mar 2014 22:32:05 +0100
Subject: HEADS-UP: new server-side validation git hook for submodule
 updates & call-for-help
In-Reply-To: <CAK-tuPZHKJQp2-psKRpPe1iSD_OR+TZAzrgKKHZgOhxQFd3wzA@mail.gmail.com>
 (Johan Tibell's message of "Tue, 18 Mar 2014 19:17:55 +0100")
References: <87pplj7oyr.fsf@gmail.com>
 <CAK-tuPZHKJQp2-psKRpPe1iSD_OR+TZAzrgKKHZgOhxQFd3wzA@mail.gmail.com>
Message-ID: <87d2hj6vmy.fsf@gmail.com>

Hello Johan, 

On 2014-03-18 at 19:17:55 +0100, Johan Tibell wrote:
> Lets give some example workflows for working with submodules. Here's what I
> think a raw (i.e. no sync-all) update to base will look like. Please
> correct me if I'm wrong.
>
> # Step 1:
> cd ~/src/ghc/libraries/base
> # edit some_file
> git add some_file
> git commit -m "Commit to base repo"
> git push  # push update to base to git.haskell.org

'git push' w/o a refspec will only work, if the HEAD isn't detached

you'd rather have to invoke something like 'git push origin
HEAD:ghc-head'[1]  (or have a tracked branch checked out)

> # Step 2
> cd ~/src/ghc
> git add libraries/base
> git commit -m "Have GHC use the new base version"
> git push  # push update to ghc to git.haskell.org
>
> Failure modes include:
>
>  * Forgetting step 2: the ghc repo will point to a slightly older base next
> time someone checks it out. Fixing things when in this state: just perform
> step 2.

that's brings up an interesting question (that was also mentioned on
#ghc already):

Are there cases when it is desirable to point to an older commit on
purpose? 

(one use-case may be, if you want to rollback ghc.git to some older
commit to unbreak the build w/o touching the submodule repo itself)

(somewhat related feature: "git submodule update --remote")

>  * Forgetting `git push` in step 1. the ghc repo will point to a base
> commit that doesn't exist (except on some developers machine).  Fixing
> things when in this state: the developer who forgot to `git push` in step 1
> needs to do that.

Actually, the new server-side hook will reject (for non-wip/ branches at
least) a ghc.git commit which would result in a submod-ref pointing to a
non-existing commit, so this one's covered already.

> How could sync-all help us:
>
>  * sync-all push could push all repos, preventing failure case 2
>  above.

(as I wrote, this can't happen thanks to the new hook script)

However, see man-page for "git push --recurse-submodules"

> The second interesting workflow involving pulling new changes. This is what
> the raw (i.e. no sync-all) workflow will look like:
>
> cd ~/src/ghc
> git pull
> git submodule update

> Failure modes include:
>
>  * Forgetting the `submodule update` and then doing e.g. `git commit -am
> "some compile commit"`, reverting the pointer to e.g. base to whatever
> older version the developer was using. No commits are lost (nothing changes
> in the base repo), but the ghc repo will point to an older commit.
>
> How could sync-all help us:
>
>  * sync-all pull could always run `submodule update`.
>
> The server-side check that Herbert added will make sure that the failure
> mode cannot happen, as you explicitly have to say in the commit message
> that you updated a submodule.
>
> I think if base was folded into ghc.git very few people would have to deal
> with submodules.

if 'base' remains tightly coupled to ghc internals, that might be indeed
be the easiest solution; I'm just not sure how the big base-split will
be affected by folded-into-ghc base. Also, supporting a sensible 'cabal
get -s base' will require a bit more work (or we'd have to remove the
ability for that again -- not that it is of much use anyway)

PS: I'm wondering if the next-gen 'sync-all' couldn't be simply realised
by defining a set of git aliases[2]; e.g. it's rather commond to have a
'git pullall' alias defined for combining the effect of 'git pull' and
'git submodule update' into one alias[3]


Cheers,
  hvr

 [1]: occurences of 'ghc-head' will most likely be renamed to 'master'
      as that's more consistent with GHC HEAD being 'master' in ghc.git
      as well

 [2]: https://git.wiki.kernel.org/index.php/Aliases

 [3]: git config alias.pullall '!git pull && git submodule update --init --recursive'


From gergo at erdi.hu  Tue Mar 18 23:01:43 2014
From: gergo at erdi.hu (=?UTF-8?B?RHIuIMOJUkRJIEdlcmfFkQ==?=)
Date: Wed, 19 Mar 2014 07:01:43 +0800
Subject: Pretty printing
In-Reply-To: <59543203684B2244980D7E4057D5FBC14880743A@DB3EX14MBXC308.europe.corp.microsoft.com>
References: <59543203684B2244980D7E4057D5FBC14880743A@DB3EX14MBXC308.europe.corp.microsoft.com>
Message-ID: <CAO7EwMqefFw-FzAzz=GQaT5xYn5yVyFTpvdGLxjwtyV1tU3qGQ@mail.gmail.com>

Hi,

I'm getting it done later today.

Bye,
Gergo
On Mar 19, 2014 1:36 AM, "Simon Peyton Jones" <simonpj at microsoft.com> wrote:

>  Gergo
>
> I'm a bit out of date... did you update those test results etc to get to
> clean validate?
>
> S
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/ghc-devs/attachments/20140319/96678b42/attachment-0001.html>

From d at davidterei.com  Wed Mar 19 00:44:35 2014
From: d at davidterei.com (David Terei)
Date: Tue, 18 Mar 2014 17:44:35 -0700
Subject: We need to add role annotations for 7.8
In-Reply-To: <87eh1zkoso.wl@ta.scs.stanford.edu>
References: <78518EC7-BC18-4732-90B6-1AB37048D2A3@cis.upenn.edu>
 <CAK-tuPY0G0ceKK=mNp1N2H-h8S1sN47rahd2OmAXU3RrP-zukQ@mail.gmail.com>
 <CALjd_v5pCBQv4qXAm3E4_qSp8NRLjq1BKV1dJejymsUhruDReQ@mail.gmail.com>
 <CALjd_v6Ar4BVyWyYjpYDy-2UO78tVC3uOcdVyVSSpvi8M-oE9Q@mail.gmail.com>
 <CAEs96n1Xxp9qmXLBf6XqKbLH3kEE3bVLcpLAuFHoVip0N+1D=w@mail.gmail.com>
 <CAEs96n1dVs8SC6an_5eCsx1aCPwbNjbahhNrKAeaSCv1=Qe3gw@mail.gmail.com>
 <CAEs96n0SCjD6_C7VkeL0NUCY+v-fZseeL=iRFZG9fL9b74AjwQ@mail.gmail.com>
 <CAEs96n1WnrVtyjk2f3jOgUZg2M4EwPSA-9bnN6+9dL1p+=Ea0w@mail.gmail.com>
 <CAK-tuPahbPSd4fxjRCMKHYPcsPuzsM3CnBFMBvkoYbAZkVmmjw@mail.gmail.com>
 <CAKFCL4Um+o8fdv-U04grZhMDCJsUrge3Qmg+gNiAM50quzZwXA@mail.gmail.com>
 <CAK-tuPZoA=hqJT4GXfJnRG6NEhpqFjSNM0YDMS=OA-dfU+7MxA@mail.gmail.com>
 <CAKFCL4X3wy8sM4R-mZWaP4uSO0fChnCu3tB1YGuHSsRsvMNASQ@mail.gmail.com>
 <80F4D480-C520-4AD5-B9CD-C7061199C7AB@cis.upenn.edu>
 <CA+tcxkBT0QqyjSiB3u-Ce0OorHMA2ywqFhq7e2wMK=Hi+9Um2w@mail.gmail.com>
 <937ECF37-CA68-468D-9569-5874100B62C0@cis.upenn.edu>
 <CA+tcxkDs98i+g_-CRgg_qAFS1P2JYS-FZ-O_SMVT1ZzFvckzzQ@mail.gmail.com>
 <87eh1zkoso.wl@ta.scs.stanford.edu>
Message-ID: <CACHt1w_yRMRQt=AzOtm8pKW9YkMS=8_X9eh6gXE+73aRD9B1AQ@mail.gmail.com>

Adding in GHC-DEV. Yes, sorry for no contact, my GHC email filter was
misconfigured so only got alerted when SPJ emailed me directly a few
days back.


On 18 March 2014 17:36, David Mazieres expires 2014-06-16 PDT
<mazieres-i58umkudjfnfpfdx6jbbn3ymzi at temporary-address.scs.stanford.edu>
wrote:
> At Fri, 14 Mar 2014 18:45:16 +0100,
> Mikhail Glushenkov wrote:
>>
>> Hi Richard,
>>
>> > The real trouble with making this decision is that we have no real
>> > guidance. We've tried contacting David Terei (the originator of
>> > Safe Haskell) several times to no avail. If you are an actual
>> > consumer of Safe Haskell and would like to share your opinion on
>> > this front, I do encourage you to make a ticket, essentially
>> > requesting a resurrection of the extra Safe checks.
>>
>> Yes, it would be nice if David Terei or David Mazi?res (CC:ed) could comment.
>
> Sadly, it appears some mail may not have made it through to David
> Terei's mailbox.
>
> At any rate, David and I just discussed the new Coerce typeclass.
> Based on David's understanding of its behavior, it sounds pretty
> dangerous for Safe Haskell.  At a minimum, the programmer is going to
> need to understand a lot more than Haskell 2010 to write secure code.
>
> Based on my possibly limited understanding of the new
> feature--automatically generating instances of the Coerce type seems
> very un-Haskell-like.  By analogy, we could automatically generate
> instance of Read and Show (or add equivalent DebugRead/DebugShow
> classes) wherever possible, but this would similarly break abstraction
> by providing effective access to non-exported constructors.
>
> I understand why there is a need for something better than
> GeneralizedNewtypeDeriving.  However, implementing Coerce as a
> typeclass has the very serious disadvantage that there is no Haskell
> mechanism for controlling instance exports.  And if we are going to
> add a new mechanism (roles) to control such exports, exporting an
> instance that is never requested and that undermines modularity and
> abstraction is an unfortunate default.
>
> It may be too late for this, but a cleaner solution more in keeping
> with other extensions would be to have a -XDeriveCoerce extension that
> allows Coerce to be explicitly derived when safe.  This could be
> combined with leaving the previous behavior of
> GeneralizedNewtypeDeriving and just deprecating the language feature.
>
> Though controlling instance exports does not have a precedent, another
> option might be to special-case the Coerce class and only export
> instances of Coerce when all constructors of a type are also exported.
> This would prevent anyone from using Coerce to do things they couldn't
> already do manually.
>
> David
>

From hsjunn at gmail.com  Wed Mar 19 03:06:52 2014
From: hsjunn at gmail.com (Horsng Junn)
Date: Wed, 19 Mar 2014 12:06:52 +0900
Subject: Possible refactoring for __stg_gc_fun in HeapStackCheck.cmm
Message-ID: <2821BC33-E271-4789-9A16-81391E1C6C96@gmail.com>

Hi list!
This is my first mail to the list; please correct me if I made any mistakes.

I?ve been studying GHC source code for studying?s sake, and think I?ve found a few problems in this function.

Below comes the function in its current form:
????????????????????
__stg_gc_fun /* explicit stack */
{
    W_ size;
    W_ info;
    W_ type;

    info = %GET_FUN_INFO(UNTAG(R1));

    // cache the size
    type = TO_W_(StgFunInfoExtra_fun_type(info));
    if (type == ARG_GEN) {
	size = BITMAP_SIZE(StgFunInfoExtra_bitmap(info));
    } else { 
	if (type == ARG_GEN_BIG) {
#ifdef TABLES_NEXT_TO_CODE
            // bitmap field holds an offset
            size = StgLargeBitmap_size( StgFunInfoExtra_bitmap(info)
                                        + %GET_ENTRY(UNTAG(R1)) /* ### */ );
#else
	    size = StgLargeBitmap_size( StgFunInfoExtra_bitmap(info) );
#endif
	} else {
	    size = BITMAP_SIZE(W_[stg_arg_bitmaps + WDS(type)]);
	}
    }
    
#ifdef NO_ARG_REGS
    // we don't have to save any registers away
    Sp_adj(-3);
    Sp(2) = R1;
    Sp(1) = size;
    Sp(0) = stg_gc_fun_info;
    jump stg_gc_noregs [];
#else
    W_ type;
    type = TO_W_(StgFunInfoExtra_fun_type(info));
    // cache the size
    if (type == ARG_GEN || type == ARG_GEN_BIG) {
        // regs already saved by the heap check code
        Sp_adj(-3);
        Sp(2) = R1;
        Sp(1) = size;
        Sp(0) = stg_gc_fun_info;
        // DEBUG_ONLY(foreign "C" debugBelch("stg_fun_gc_gen(ARG_GEN)"););
        jump stg_gc_noregs [];
    } else { 
        jump W_[stg_stack_save_entries + WDS(type)] [*]; // all regs live
	    // jumps to stg_gc_noregs after saving stuff
    }
#endif /* !NO_ARG_REGS */
}

The problems I see:
1. ?type? variable is declared and its value calculated twice,
2. if (type == ARG_GEN ? check is needlessly done twice,
3. ?size" value is calculated and then discarded in !NO_ARG_REGS, for types other than ARG_GEN or ARG_GEN_BIG, and
4. (this is a minor one) Sp_adj(-3) ~ jmup_stg_gc_noregs code is duplicated. I know they?re in separate #if branch but still...

And my proposed fixes are:
????????????????????
__stg_gc_fun /* explicit stack */
{
    W_ size;
    W_ info;
    W_ type;

    info = %GET_FUN_INFO(UNTAG(R1));

    // cache the size
    type = TO_W_(StgFunInfoExtra_fun_type(info));
    if (type == ARG_GEN) {
        // regs already saved by the heap check code
	size = BITMAP_SIZE(StgFunInfoExtra_bitmap(info));
    } else { 
	if (type == ARG_GEN_BIG) {
	    // regs already saved by the heap check code
#ifdef TABLES_NEXT_TO_CODE
            // bitmap field holds an offset
            size = StgLargeBitmap_size( StgFunInfoExtra_bitmap(info)
                                        + %GET_ENTRY(UNTAG(R1)) /* ### */ );
#else
	    size = StgLargeBitmap_size( StgFunInfoExtra_bitmap(info) );
#endif
	} else {
#ifdef NO_ARG_REGS
	    // we don't have to save any registers away
	    size = BITMAP_SIZE(W_[stg_arg_bitmaps + WDS(type)]);
#else
	    jump W_[stg_stack_save_entries + WDS(type)] [*]; // all regs live
	    // jumps to stg_gc_noregs after saving stuff
#endif
	}
    }

    Sp_adj(-3);
    Sp(2) = R1;
    Sp(1) = size;
    Sp(0) = stg_gc_fun_info;
    jump stg_gc_noregs [];
}

What do you guys think?

Thanks,
Horsng Junn


From petersen at fedoraproject.org  Wed Mar 19 05:34:53 2014
From: petersen at fedoraproject.org (Jens Petersen)
Date: Wed, 19 Mar 2014 14:34:53 +0900
Subject: ghc-7.8.1 RC2 ppc dyn linked executable segfaults
In-Reply-To: <CAEDGBqKnddMLTX3ZqYpyx=UaZxNS+WH2w93M+hfuw+MYHgUh7A@mail.gmail.com>
References: <CAEDGBqKnddMLTX3ZqYpyx=UaZxNS+WH2w93M+hfuw+MYHgUh7A@mail.gmail.com>
Message-ID: <CAEDGBqLiBTsaakZnCLUQVoHp5=dPL=16TpP4eydwyK0TJF+CYg@mail.gmail.com>

On 18 March 2014 19:02, Jens Petersen <petersen at fedoraproject.org> wrote:
>
> The ppc64 build looks okay, but ppc seems to have a problem with
> executables dyn linked to Haskell libs segfaulting.
> :
>
I don't have access yet to a ppc box to investigate further but I see the
> segfault for "ghc -dynamic Hello.hs; ./Hello" on ppc in the fedora buildsys.
>
>
> http://ppc.koji.fedoraproject.org/kojifiles/work/tasks/1459/1711459/build.log&offset=-4000
>

Sorry correct link is:
http://ppc.koji.fedoraproject.org/koji/getfile?taskID=1711459&name=build.log&offset=-4000


I filed https://ghc.haskell.org/trac/ghc/ticket/8909 for this issue.

Jens
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/ghc-devs/attachments/20140319/5421d7bf/attachment.html>

From slyich at gmail.com  Wed Mar 19 07:45:36 2014
From: slyich at gmail.com (Sergei Trofimovich)
Date: Wed, 19 Mar 2014 10:45:36 +0300
Subject: FFI: c/c++ struct on stack as an argument or return value
In-Reply-To: <1395163879.4601.35.camel@shum-lt>
References: <1394797839.4664.35.camel@shum-lt>
 <5F969E34-BCF1-40CB-86DF-20F84245BEDB@cse.unsw.edu.au>
 <CAHYVw0xugANXO43pxA5yPH3xpZ4CxKOBA6UetwNAPa6XfLD0Ew@mail.gmail.com>
 <CAJumaK-KakS9=9ksGnOj9p6qYq3KmfoZwyCGju7d1kyytwcg8Q@mail.gmail.com>
 <CAHYVw0wje9Ju_rUfCQUeN=qRtbBs_aJ8TSY+75P3bH89vAJEHA@mail.gmail.com>
 <1394887862.4722.31.camel@shum-lt>
 <C86323E1-F09A-4FDA-88BD-6D28A1D28F83@cse.unsw.edu.au>
 <532839B4.7040609@gmail.com> <1395163879.4601.35.camel@shum-lt>
Message-ID: <20140319104536.741e39e7@sf>

On Tue, 18 Mar 2014 20:31:19 +0300
Yuras Shumovich <shumovichy at gmail.com> wrote:

> Hi,
> 
> I thought I have lost the battle :)
> Thank you for the support, Simon!
> 
> I'm interested in full featured solution: arguments, return value,
> foreign import, foreign export, etc. But it is too much for me to do it
> all at once. So I started with dynamic wrapper.
> 
> The plan is to support structs as arguments and return value for dynamic
> wrapper using libffi;
> then implement native adjustors at least for x86_64 linux;

On a positive side there is only 2 arches supporting native adjustors
that actually work these days:

ArchHasAdjustorSupport = $(if $(findstring $(TargetArch_CPP),i386 x86_64),YES,NO)

> then make final design decision (tuple or data? language pragma? union
> support? etc);
> and only then start working on foreign import. 
> 
> But I'm open for suggestions. Just let me know if you think it is better
> to start with return value support for foreign import. 
> 
> Thanks,
> Yuras

-- 

  Sergei
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: not available
URL: <http://www.haskell.org/pipermail/ghc-devs/attachments/20140319/b9e09bd5/attachment.sig>

From marlowsd at gmail.com  Wed Mar 19 11:16:15 2014
From: marlowsd at gmail.com (Simon Marlow)
Date: Wed, 19 Mar 2014 11:16:15 +0000
Subject: HEADS-UP: new server-side validation git hook for submodule
 updates & call-for-help
In-Reply-To: <CAK-tuPZHKJQp2-psKRpPe1iSD_OR+TZAzrgKKHZgOhxQFd3wzA@mail.gmail.com>
References: <87pplj7oyr.fsf@gmail.com>
 <CAK-tuPZHKJQp2-psKRpPe1iSD_OR+TZAzrgKKHZgOhxQFd3wzA@mail.gmail.com>
Message-ID: <53297C7F.2070403@gmail.com>

On 18/03/2014 18:17, Johan Tibell wrote:
> Lets give some example workflows for working with submodules. Here's
> what I think a raw (i.e. no sync-all) update to base will look like.
> Please correct me if I'm wrong.
>
> # Step 1:
> cd ~/src/ghc/libraries/base
> # edit some_file
> git add some_file
> git commit -m "Commit to base repo"
> git push  # push update to base to git.haskell.org <http://git.haskell.org>

I believe this doesn't work, because the normal state for a submodule is 
"detached HEAD", so you can't commit to it because it isn't on a branch. 
  You have to first "get checkout master", or "git checkout -b mybranch 
master".

> # Step 2
> cd ~/src/ghc
> git add libraries/base
> git commit -m "Have GHC use the new base version"
> git push  # push update to ghc to git.haskell.org <http://git.haskell.org>
>
> Failure modes include:
>
>   * Forgetting step 2: the ghc repo will point to a slightly older base
> next time someone checks it out. Fixing things when in this state: just
> perform step 2.
>   * Forgetting `git push` in step 1. the ghc repo will point to a base
> commit that doesn't exist (except on some developers machine).  Fixing
> things when in this state: the developer who forgot to `git push` in
> step 1 needs to do that.
>
> How could sync-all help us:
>
>   * sync-all push could push all repos, preventing failure case 2 above.
>
> The second interesting workflow involving pulling new changes. This is
> what the raw (i.e. no sync-all) workflow will look like:
>
> cd ~/src/ghc
> git pull
> git submodule update
>
> Failure modes include:
>
>   * Forgetting the `submodule update` and then doing e.g. `git commit
> -am "some compile commit"`, reverting the pointer to e.g. base to
> whatever older version the developer was using. No commits are lost
> (nothing changes in the base repo), but the ghc repo will point to an
> older commit.

The other failure mode is that the submodule contains local changes, 
that just got overwritten by the "git submodule update".  Perhaps git is 
better about telling you when this is about to happen and/or failing in 
submodule update now?  What about when the submodule is on a branch?

Cheers,
Simon


> How could sync-all help us:
>
>   * sync-all pull could always run `submodule update`.
>
> The server-side check that Herbert added will make sure that the failure
> mode cannot happen, as you explicitly have to say in the commit message
> that you updated a submodule.
>
> I think if base was folded into ghc.git very few people would have to
> deal with submodules.
>
> On Tue, Mar 18, 2014 at 11:58 AM, Herbert Valerio Riedel <hvr at gnu.org
> <mailto:hvr at gnu.org>> wrote:
>
>     Hello *,
>
>     I've put in place a new server-side validation hook a few days ago, and
>     since nobody seemed to have complained yet, I assume it didn't have any
>     adverse effects so far :-)
>
>     It will only be triggered when Git submodule references are touched by a
>     commit; you can find some preliminary (but incomplete) documentation and
>     a sample session triggering validation-failure on purpose at
>
>     https://ghc.haskell.org/trac/ghc/ticket/8251#comment:4
>
>     (this will be turned into a proper wiki-page once #8251 is completed;
>     there's some minor details wrt some corner cases that still need to be
>     looked at)
>
>     So, this mostly addresses the server-side requirements for migrating to
>     a proper git-submodule set-up for ghc.git;
>
>     The next steps, however, include taking care of the client-side
>     work-flow
>     for working with a fully "submoduled" ghc.git setup. Personally, I'm
>     quite comfortable using direct git commands to manage such a construct,
>     but I'm well aware not everyone is (as previous discussions here have
>     shown). Also, as my time is rather limited, I'd like to ask interested
>     parties to join in and help formulate the future client-side
>     work-flow[1]
>     and/or update (or rewrite) the 'sync-all' to provide a seamless or at
>     least smooth transition for those GHC devs who want to keep using
>     "sync-all" instead of using direct Git commands.
>
>
>       [1]: There's some difference in how tracked upstream packages and
>            GHC-HQ owned sub-repos are to be handled workflow-wise, to avoid
>            ending up with a noisy ghc.git history.
>
>            For instance, having ghc.git with submodules is not the same as
>            having a huge monolithic ghc.git repository with all subrepos
>            embedded. specifically, it might not be sensible to propagate
>            *every* single subrepo-commit as a separate ghc.git submod-ref
>            update, but rather in logical batches (N.B.: using submodules
>            gives the additional ability to git bisect within subrepos
>     instead
>            of having to bisect always only at top-level). This is one
>     example
>            of things to discuss/consider when designing the new work-flow.
>
>     Cheers,
>        hvr
>     _______________________________________________
>     ghc-devs mailing list
>     ghc-devs at haskell.org <mailto:ghc-devs at haskell.org>
>     http://www.haskell.org/mailman/listinfo/ghc-devs
>
>
>
>
> _______________________________________________
> ghc-devs mailing list
> ghc-devs at haskell.org
> http://www.haskell.org/mailman/listinfo/ghc-devs
>

From marlowsd at gmail.com  Wed Mar 19 11:39:44 2014
From: marlowsd at gmail.com (Simon Marlow)
Date: Wed, 19 Mar 2014 11:39:44 +0000
Subject: Haddock strings in .hi files
In-Reply-To: <53288E64.8060704@fuuzetsu.co.uk>
References: <53288E64.8060704@fuuzetsu.co.uk>
Message-ID: <53298200.4000509@gmail.com>

On 18/03/2014 18:20, Mateusz Kowalczyk wrote:
> Hi all,
>
> I saw https://ghc.haskell.org/trac/ghc/ticket/5467 pop up in my inbox
> and it reminded me of something I've been wondering for a while: why do
> we not store Haddock docstrings in the interface file?
>
> I think that if we did, we could do some great things:
>
> 1. Show docs in GHCi (I vaguely recall someone working on this ~1 year
> ago, does anyone have any info?)
>
> 2. Allow Haddock to work a lot faster: the big majority of time spent
> when creating documentation is actually spent by Haddock calling various
> GHC functions, such as type-checking the modules. Only a small amount of
> time is actually spent by Haddock on other tasks such as parsing or
> outputting the documentation. If we could simply get everything we need
> from the .hi files, we save ourselves a lot of time.

Don't you still have to run the renamer at least?  And in GHC, renaming 
is tied up with typechecking, so it's hard to do one without the other. 
  Furthermore, if there is a missing type signature it's useful to be 
able to put the inferred type in the documentation.  I think I'm missing 
the point somewhere - how does putting docs in the .hi file let you 
avoid typechecking?

I'm not really sure I see the benefit.  If Haddock provided a library 
that we can call from GHCi to get documentation, then we could show 
documentation in GHCi.

The current design is intended to separate Haddock from GHC as much as 
possible, but putting documentation in .hi files would be going in the 
opposite direction.  There would have to be a compelling reason to do 
that, something that we couldn't do another way.

Cheers,
Simon


> 3. Allow Haddock to create partial documentation: a complaint I
> sometimes hear is if anything at all in the project doesn't type check,
> we don't get any documentation at all. I think that it'd be viable to
> generate only the documentation for the modules/functions that do
> type-check and perhaps skip type signatures for everything else.
>
> Points 1. and 2. are of clear benefit. Point 3. is a simple afterthought
> and thinking about it some more, I think that maybe it'd be possible to
> do this with what we have right now: is type-checking separate parts of
> the module supported? Can we retrieve documentation for the parts that
> don't type-check?
>
> I am asking for input on what people think. I am not familiar at all
> with what goes into the .hi file (and I can't find anything concrete! Am
> I missing some wiki page?) at all and why. At the very least, 1. should
> be easy to implement.
>
> It was suggested that I submit a proposal for this as part of GSoC,
> namely implementing 1. and 2.. I admit that having much faster
> documentation builds would be amazing and Edward K. and Carter S. seem
> to think that this is very do-able in the 3 month period that GSoC runs
> over.
>
> While I say all this, I have already submitted my proposal on a
> different topic. I am considering writing this up and submitting this as
> well but I am looking for some insight into the problem first.
>
> If there are any students around still looking for ideas, please do
> speak up if you want to snatch this. If there are people that are eager
> to mentor something like this then I suppose they should speak up too.
>
> Thanks!
>

From marlowsd at gmail.com  Wed Mar 19 11:54:41 2014
From: marlowsd at gmail.com (Simon Marlow)
Date: Wed, 19 Mar 2014 11:54:41 +0000
Subject: Possible refactoring for __stg_gc_fun in HeapStackCheck.cmm
In-Reply-To: <2821BC33-E271-4789-9A16-81391E1C6C96@gmail.com>
References: <2821BC33-E271-4789-9A16-81391E1C6C96@gmail.com>
Message-ID: <53298581.9020200@gmail.com>

On 19/03/2014 03:06, Horsng Junn wrote:
> Hi list!
> This is my first mail to the list; please correct me if I made any mistakes.

Welcome :-)

> I?ve been studying GHC source code for studying?s sake, and think I?ve found a few problems in this function.
>
> Below comes the function in its current form:
> ????????????????????
> __stg_gc_fun /* explicit stack */
> {
>      W_ size;
>      W_ info;
>      W_ type;
>
>      info = %GET_FUN_INFO(UNTAG(R1));
>
>      // cache the size
>      type = TO_W_(StgFunInfoExtra_fun_type(info));
>      if (type == ARG_GEN) {
> 	size = BITMAP_SIZE(StgFunInfoExtra_bitmap(info));
>      } else {
> 	if (type == ARG_GEN_BIG) {
> #ifdef TABLES_NEXT_TO_CODE
>              // bitmap field holds an offset
>              size = StgLargeBitmap_size( StgFunInfoExtra_bitmap(info)
>                                          + %GET_ENTRY(UNTAG(R1)) /* ### */ );
> #else
> 	    size = StgLargeBitmap_size( StgFunInfoExtra_bitmap(info) );
> #endif
> 	} else {
> 	    size = BITMAP_SIZE(W_[stg_arg_bitmaps + WDS(type)]);
> 	}
>      }
>
> #ifdef NO_ARG_REGS
>      // we don't have to save any registers away
>      Sp_adj(-3);
>      Sp(2) = R1;
>      Sp(1) = size;
>      Sp(0) = stg_gc_fun_info;
>      jump stg_gc_noregs [];
> #else
>      W_ type;
>      type = TO_W_(StgFunInfoExtra_fun_type(info));
>      // cache the size
>      if (type == ARG_GEN || type == ARG_GEN_BIG) {
>          // regs already saved by the heap check code
>          Sp_adj(-3);
>          Sp(2) = R1;
>          Sp(1) = size;
>          Sp(0) = stg_gc_fun_info;
>          // DEBUG_ONLY(foreign "C" debugBelch("stg_fun_gc_gen(ARG_GEN)"););
>          jump stg_gc_noregs [];
>      } else {
>          jump W_[stg_stack_save_entries + WDS(type)] [*]; // all regs live
> 	    // jumps to stg_gc_noregs after saving stuff
>      }
> #endif /* !NO_ARG_REGS */
> }
>
> The problems I see:
> 1. ?type? variable is declared and its value calculated twice,

Yes.

> 2. if (type == ARG_GEN ? check is needlessly done twice,
> 3. ?size" value is calculated and then discarded in !NO_ARG_REGS, for types other than ARG_GEN or ARG_GEN_BIG, and

Yes, but this isn't a performance-critical bit of code, and a good 
backend will be able to optimise it anyway.  Clarity is more important.

> 4. (this is a minor one) Sp_adj(-3) ~ jmup_stg_gc_noregs code is duplicated. I know they?re in separate #if branch but still...
> And my proposed fixes are:

I think your version has more complex control-flow: whether we drop out 
of the if expression to the code that follows depends on an #ifdef. 
I'd rather have something like this:

if (MAX_REAL_VANILLA_REG < 2 || type == ARG_GEN || type == ARG_GEN_BIG) {
   Sp_adj(-3);
   ...
} else {
   jump W_[stg_stack_save_entries + WDS(type)] [*];
}

That way the tail-calls are all at the end of the control flow.

If you validate a patch and attach it to a ticket, I'll take a look.

Cheers,
	Simon



> ????????????????????
> __stg_gc_fun /* explicit stack */
> {
>      W_ size;
>      W_ info;
>      W_ type;
>
>      info = %GET_FUN_INFO(UNTAG(R1));
>
>      // cache the size
>      type = TO_W_(StgFunInfoExtra_fun_type(info));
>      if (type == ARG_GEN) {
>          // regs already saved by the heap check code
> 	size = BITMAP_SIZE(StgFunInfoExtra_bitmap(info));
>      } else {
> 	if (type == ARG_GEN_BIG) {
> 	    // regs already saved by the heap check code
> #ifdef TABLES_NEXT_TO_CODE
>              // bitmap field holds an offset
>              size = StgLargeBitmap_size( StgFunInfoExtra_bitmap(info)
>                                          + %GET_ENTRY(UNTAG(R1)) /* ### */ );
> #else
> 	    size = StgLargeBitmap_size( StgFunInfoExtra_bitmap(info) );
> #endif
> 	} else {
> #ifdef NO_ARG_REGS
> 	    // we don't have to save any registers away
> 	    size = BITMAP_SIZE(W_[stg_arg_bitmaps + WDS(type)]);
> #else
> 	    jump W_[stg_stack_save_entries + WDS(type)] [*]; // all regs live
> 	    // jumps to stg_gc_noregs after saving stuff
> #endif
> 	}
>      }
>
>      Sp_adj(-3);
>      Sp(2) = R1;
>      Sp(1) = size;
>      Sp(0) = stg_gc_fun_info;
>      jump stg_gc_noregs [];
> }
>
> What do you guys think?
>
> Thanks,
> Horsng Junn
>
> _______________________________________________
> ghc-devs mailing list
> ghc-devs at haskell.org
> http://www.haskell.org/mailman/listinfo/ghc-devs
>

From marlowsd at gmail.com  Wed Mar 19 12:12:05 2014
From: marlowsd at gmail.com (Simon Marlow)
Date: Wed, 19 Mar 2014 12:12:05 +0000
Subject: FFI: c/c++ struct on stack as an argument or return value
In-Reply-To: <1395142949.4601.18.camel@shum-lt>
References: <1394797839.4664.35.camel@shum-lt>
 <5F969E34-BCF1-40CB-86DF-20F84245BEDB@cse.unsw.edu.au>
 <CAHYVw0xugANXO43pxA5yPH3xpZ4CxKOBA6UetwNAPa6XfLD0Ew@mail.gmail.com>
 <CAJumaK-KakS9=9ksGnOj9p6qYq3KmfoZwyCGju7d1kyytwcg8Q@mail.gmail.com>
 <CAHYVw0wje9Ju_rUfCQUeN=qRtbBs_aJ8TSY+75P3bH89vAJEHA@mail.gmail.com>
 <1394887862.4722.31.camel@shum-lt>
 <C86323E1-F09A-4FDA-88BD-6D28A1D28F83@cse.unsw.edu.au>
 <1395142949.4601.18.camel@shum-lt>
Message-ID: <53298995.7040708@gmail.com>

On 18/03/2014 11:42, Yuras Shumovich wrote:
> On Tue, 2014-03-18 at 12:37 +1100, Manuel M T Chakravarty wrote:
>>>
>>> Library implementation can't generate native dynamic wrapper, it has to
>>> use slow libffi.
>>
>> When we first implemented the FFI, there was no libffi. Maintaining the adjustor code for all platforms is a PITA; hence, using libffi was a welcome way to improve portability.
>
> Do you think we can remove native adjustors? I can prepare a patch.

I believe native adjustors are sufficiently faster than libffi to want 
to keep them; at least that was what I found the last time I checked. 
It might be the case that either libffi is now faster, or we could 
optimise our libffi support enough that it isn't worth keeping native 
adjustors.  I'd love it if that happened.

The benchmark I think I used is in nofib/smp/callback002.

Cheers,
Simon


> It requires minor changes to cache ffi_cif structure. On desugar phase
> for each wrapper we can generate fresh global variable to store cif
> pointer and pass it to createAdjustor.
>
>>
>>>
>>>  From my point of view, at this point it is more important to agree on
>>> the next question: do we want such functionality in ghc at all? I don't
>>> want to waste time on it if nobody wants to see it merged.
>>
>> I still don?t see the benefit in further complicating an already murky corner of the compiler. Moreover, for this to make sense, it would need to work on all supported platforms. Unless you are volunteering to implement it on multiple platforms, this would mean, we?d use libffi for most platforms anyway. This brings me to my original point, a library or tool is the better place for this.
>
> OK, I don't buy it, but I see your point.
>
>>
>> Manuel
>>
>> PS: I?d happily accept language-c-inline patches for marshalling structs.
>>
>
>
> _______________________________________________
> ghc-devs mailing list
> ghc-devs at haskell.org
> http://www.haskell.org/mailman/listinfo/ghc-devs
>

From marlowsd at gmail.com  Wed Mar 19 12:13:31 2014
From: marlowsd at gmail.com (Simon Marlow)
Date: Wed, 19 Mar 2014 12:13:31 +0000
Subject: "quick" vs "perf" builds
In-Reply-To: <20140310225857.141b5a8f@sf>
References: <CAK-tuPbo=McKZxADAt=kAYXKqYsyvU7hVncEhnDmuQvEt70LnQ@mail.gmail.com>
 <531DE033.90300@gmail.com>
 <CAEs96n2X-d4ibO34pvRObfOmuScJDmtU+nc84M0UdtpBQSdWNw@mail.gmail.com>
 <CAK-tuPY2h9unyvwpe77EGex_TnohqN_WrpAgR_pAMZCscFSGYQ@mail.gmail.com>
 <20140310225857.141b5a8f@sf>
Message-ID: <532989EB.6020703@gmail.com>

On 10/03/2014 19:58, Sergei Trofimovich wrote:
> On Mon, 10 Mar 2014 18:59:38 +0100
> Johan Tibell <johan.tibell at gmail.com> wrote:
>
>> Added:
>> https://github.com/ghc/ghc/commit/ddf79ebf69fe4a6e69d69d451a6040a53b1ea12c
>
> While at it:
>> SRC_HC_OPTS        = ... -H64m
>
> Just wondering: that '-H64m' is from some old times (pre 2007?).
> GHC seems to eat way more RAM nowadays. Is this bit relevant at all?

It still speeds up compilation a bit, but a larger -H value might be 
more appropriate for today's machines.

Cheers,
Simon

From fuuzetsu at fuuzetsu.co.uk  Wed Mar 19 12:30:06 2014
From: fuuzetsu at fuuzetsu.co.uk (Mateusz Kowalczyk)
Date: Wed, 19 Mar 2014 12:30:06 +0000
Subject: Haddock strings in .hi files
In-Reply-To: <53298200.4000509@gmail.com>
References: <53288E64.8060704@fuuzetsu.co.uk> <53298200.4000509@gmail.com>
Message-ID: <53298DCE.2090009@fuuzetsu.co.uk>

On 19/03/14 11:39, Simon Marlow wrote:
> On 18/03/2014 18:20, Mateusz Kowalczyk wrote:
>> Hi all,
>>
>> I saw https://ghc.haskell.org/trac/ghc/ticket/5467 pop up in my inbox
>> and it reminded me of something I've been wondering for a while: why do
>> we not store Haddock docstrings in the interface file?
>>
>> I think that if we did, we could do some great things:
>>
>> 1. Show docs in GHCi (I vaguely recall someone working on this ~1 year
>> ago, does anyone have any info?)
>>
>> 2. Allow Haddock to work a lot faster: the big majority of time spent
>> when creating documentation is actually spent by Haddock calling various
>> GHC functions, such as type-checking the modules. Only a small amount of
>> time is actually spent by Haddock on other tasks such as parsing or
>> outputting the documentation. If we could simply get everything we need
>> from the .hi files, we save ourselves a lot of time.
> 
> Don't you still have to run the renamer at least?  And in GHC, renaming 
> is tied up with typechecking, so it's hard to do one without the other. 
>   Furthermore, if there is a missing type signature it's useful to be 
> able to put the inferred type in the documentation.  I think I'm missing 
> the point somewhere - how does putting docs in the .hi file let you 
> avoid typechecking?

This is a very good point and precisely why I have e-mailed ghc-devs
first. I think you're correct. I suppose that idea is out of the window!

> I'm not really sure I see the benefit.  If Haddock provided a library 
> that we can call from GHCi to get documentation, then we could show 
> documentation in GHCi.

Considering that (as you point out), we can't really get rid of the time
spent in GHC on renaming/type-checking, this does seem like the best way
to go now. I think there's an old ticket somewhere about providing such
a library that would let you work with Haddock interface files. I'll
investigate that approach in some spare time.

> The current design is intended to separate Haddock from GHC as much as 
> possible, but putting documentation in .hi files would be going in the 
> opposite direction.  There would have to be a compelling reason to do 
> that, something that we couldn't do another way.

I agree. Without being able to rip the major benefit of the idea (fast
docs), it is not worth doing it now.

> Cheers,
> Simon
> 
> 

Thanks!

-- 
Mateusz K.

From gergo at erdi.hu  Wed Mar 19 14:36:42 2014
From: gergo at erdi.hu (Dr. ERDI Gergo)
Date: Wed, 19 Mar 2014 22:36:42 +0800 (SGT)
Subject: Pretty printing
In-Reply-To: <59543203684B2244980D7E4057D5FBC14880743A@DB3EX14MBXC308.europe.corp.microsoft.com>
References: <59543203684B2244980D7E4057D5FBC14880743A@DB3EX14MBXC308.europe.corp.microsoft.com>
Message-ID: <alpine.DEB.2.10.1403192235560.4118@galaxy>

On Tue, 18 Mar 2014, Simon Peyton Jones wrote:

> Gergo
> 
> I?m a bit out of date? did you update those test results etc to get to 
> clean validate?

I've just pushed a fix to master for the validation failures, except for 
the following two which I have no idea what they mean:

Unexpected failures:
    perf/compiler  T3294 [stat too good] (normal)
    perf/compiler  T6048 [stat too good] (optasm)

From hsjunn at gmail.com  Thu Mar 20 05:41:41 2014
From: hsjunn at gmail.com (Horsng Junn)
Date: Thu, 20 Mar 2014 14:41:41 +0900
Subject: Possible refactoring for __stg_gc_fun in HeapStackCheck.cmm
In-Reply-To: <53298581.9020200@gmail.com>
References: <2821BC33-E271-4789-9A16-81391E1C6C96@gmail.com>
 <53298581.9020200@gmail.com>
Message-ID: <677609F9-EC84-4D45-A265-8097266800AE@gmail.com>

Thanks for the reply, but I don?t think I?m ready to submit a patch yet.
Hopefully someday :)

Thanks,
Horsng Junn

On 2014-03-19, at 8:54 PM, Simon Marlow <marlowsd at gmail.com> wrote:

> On 19/03/2014 03:06, Horsng Junn wrote:
>> Hi list!
>> This is my first mail to the list; please correct me if I made any mistakes.
> 
> Welcome :-)
> 
>> I?ve been studying GHC source code for studying?s sake, and think I?ve found a few problems in this function.
>> 
>> Below comes the function in its current form:
>> ????????????????????
>> __stg_gc_fun /* explicit stack */
>> {
>>     W_ size;
>>     W_ info;
>>     W_ type;
>> 
>>     info = %GET_FUN_INFO(UNTAG(R1));
>> 
>>     // cache the size
>>     type = TO_W_(StgFunInfoExtra_fun_type(info));
>>     if (type == ARG_GEN) {
>> 	size = BITMAP_SIZE(StgFunInfoExtra_bitmap(info));
>>     } else {
>> 	if (type == ARG_GEN_BIG) {
>> #ifdef TABLES_NEXT_TO_CODE
>>             // bitmap field holds an offset
>>             size = StgLargeBitmap_size( StgFunInfoExtra_bitmap(info)
>>                                         + %GET_ENTRY(UNTAG(R1)) /* ### */ );
>> #else
>> 	    size = StgLargeBitmap_size( StgFunInfoExtra_bitmap(info) );
>> #endif
>> 	} else {
>> 	    size = BITMAP_SIZE(W_[stg_arg_bitmaps + WDS(type)]);
>> 	}
>>     }
>> 
>> #ifdef NO_ARG_REGS
>>     // we don't have to save any registers away
>>     Sp_adj(-3);
>>     Sp(2) = R1;
>>     Sp(1) = size;
>>     Sp(0) = stg_gc_fun_info;
>>     jump stg_gc_noregs [];
>> #else
>>     W_ type;
>>     type = TO_W_(StgFunInfoExtra_fun_type(info));
>>     // cache the size
>>     if (type == ARG_GEN || type == ARG_GEN_BIG) {
>>         // regs already saved by the heap check code
>>         Sp_adj(-3);
>>         Sp(2) = R1;
>>         Sp(1) = size;
>>         Sp(0) = stg_gc_fun_info;
>>         // DEBUG_ONLY(foreign "C" debugBelch("stg_fun_gc_gen(ARG_GEN)"););
>>         jump stg_gc_noregs [];
>>     } else {
>>         jump W_[stg_stack_save_entries + WDS(type)] [*]; // all regs live
>> 	    // jumps to stg_gc_noregs after saving stuff
>>     }
>> #endif /* !NO_ARG_REGS */
>> }
>> 
>> The problems I see:
>> 1. ?type? variable is declared and its value calculated twice,
> 
> Yes.
> 
>> 2. if (type == ARG_GEN ? check is needlessly done twice,
>> 3. ?size" value is calculated and then discarded in !NO_ARG_REGS, for types other than ARG_GEN or ARG_GEN_BIG, and
> 
> Yes, but this isn't a performance-critical bit of code, and a good backend will be able to optimise it anyway.  Clarity is more important.
> 
>> 4. (this is a minor one) Sp_adj(-3) ~ jmup_stg_gc_noregs code is duplicated. I know they?re in separate #if branch but still...
>> And my proposed fixes are:
> 
> I think your version has more complex control-flow: whether we drop out of the if expression to the code that follows depends on an #ifdef. I'd rather have something like this:
> 
> if (MAX_REAL_VANILLA_REG < 2 || type == ARG_GEN || type == ARG_GEN_BIG) {
>  Sp_adj(-3);
>  ...
> } else {
>  jump W_[stg_stack_save_entries + WDS(type)] [*];
> }
> 
> That way the tail-calls are all at the end of the control flow.
> 
> If you validate a patch and attach it to a ticket, I'll take a look.
> 
> Cheers,
> 	Simon
> 
> 
> 
>> ????????????????????
>> __stg_gc_fun /* explicit stack */
>> {
>>     W_ size;
>>     W_ info;
>>     W_ type;
>> 
>>     info = %GET_FUN_INFO(UNTAG(R1));
>> 
>>     // cache the size
>>     type = TO_W_(StgFunInfoExtra_fun_type(info));
>>     if (type == ARG_GEN) {
>>         // regs already saved by the heap check code
>> 	size = BITMAP_SIZE(StgFunInfoExtra_bitmap(info));
>>     } else {
>> 	if (type == ARG_GEN_BIG) {
>> 	    // regs already saved by the heap check code
>> #ifdef TABLES_NEXT_TO_CODE
>>             // bitmap field holds an offset
>>             size = StgLargeBitmap_size( StgFunInfoExtra_bitmap(info)
>>                                         + %GET_ENTRY(UNTAG(R1)) /* ### */ );
>> #else
>> 	    size = StgLargeBitmap_size( StgFunInfoExtra_bitmap(info) );
>> #endif
>> 	} else {
>> #ifdef NO_ARG_REGS
>> 	    // we don't have to save any registers away
>> 	    size = BITMAP_SIZE(W_[stg_arg_bitmaps + WDS(type)]);
>> #else
>> 	    jump W_[stg_stack_save_entries + WDS(type)] [*]; // all regs live
>> 	    // jumps to stg_gc_noregs after saving stuff
>> #endif
>> 	}
>>     }
>> 
>>     Sp_adj(-3);
>>     Sp(2) = R1;
>>     Sp(1) = size;
>>     Sp(0) = stg_gc_fun_info;
>>     jump stg_gc_noregs [];
>> }
>> 
>> What do you guys think?
>> 
>> Thanks,
>> Horsng Junn
>> 
>> _______________________________________________
>> ghc-devs mailing list
>> ghc-devs at haskell.org
>> http://www.haskell.org/mailman/listinfo/ghc-devs

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/ghc-devs/attachments/20140320/1a4a195c/attachment-0001.html>

From simonpj at microsoft.com  Thu Mar 20 08:08:45 2014
From: simonpj at microsoft.com (Simon Peyton Jones)
Date: Thu, 20 Mar 2014 08:08:45 +0000
Subject: Haddock strings in .hi files
In-Reply-To: <53298200.4000509@gmail.com>
References: <53288E64.8060704@fuuzetsu.co.uk> <53298200.4000509@gmail.com>
Message-ID: <59543203684B2244980D7E4057D5FBC14880AF25@DB3EX14MBXC308.europe.corp.microsoft.com>

| The current design is intended to separate Haddock from GHC as much as
| possible, but putting documentation in .hi files would be going in the
| opposite direction.  There would have to be a compelling reason to do
| that, something that we couldn't do another way.

Actually it would in many ways be easier to put Haddock stuff in .hi files.  But since GHC writes the .hi file, that would essentially mean merging GHC and Haddock into a single compile-and-documentation-generator.   That would be cool in a way -- for example, GHCi would natively have access to the Haddock docs for a function.

As Simon M says, the big reason not to do that is because it couples together two large projects, making each harder to develop independently.  And that's a pretty big reason.

Simon

| -----Original Message-----
| From: ghc-devs [mailto:ghc-devs-bounces at haskell.org] On Behalf Of Simon
| Marlow
| Sent: 19 March 2014 11:40
| To: Mateusz Kowalczyk; ghc-devs at haskell.org
| Subject: Re: Haddock strings in .hi files
| 
| On 18/03/2014 18:20, Mateusz Kowalczyk wrote:
| > Hi all,
| >
| > I saw https://ghc.haskell.org/trac/ghc/ticket/5467 pop up in my inbox
| > and it reminded me of something I've been wondering for a while: why
| > do we not store Haddock docstrings in the interface file?
| >
| > I think that if we did, we could do some great things:
| >
| > 1. Show docs in GHCi (I vaguely recall someone working on this ~1 year
| > ago, does anyone have any info?)
| >
| > 2. Allow Haddock to work a lot faster: the big majority of time spent
| > when creating documentation is actually spent by Haddock calling
| > various GHC functions, such as type-checking the modules. Only a small
| > amount of time is actually spent by Haddock on other tasks such as
| > parsing or outputting the documentation. If we could simply get
| > everything we need from the .hi files, we save ourselves a lot of
| time.
| 
| Don't you still have to run the renamer at least?  And in GHC, renaming
| is tied up with typechecking, so it's hard to do one without the other.
|   Furthermore, if there is a missing type signature it's useful to be
| able to put the inferred type in the documentation.  I think I'm missing
| the point somewhere - how does putting docs in the .hi file let you
| avoid typechecking?
| 
| I'm not really sure I see the benefit.  If Haddock provided a library
| that we can call from GHCi to get documentation, then we could show
| documentation in GHCi.
| 
| The current design is intended to separate Haddock from GHC as much as
| possible, but putting documentation in .hi files would be going in the
| opposite direction.  There would have to be a compelling reason to do
| that, something that we couldn't do another way.
| 
| Cheers,
| Simon
| 
| 
| > 3. Allow Haddock to create partial documentation: a complaint I
| > sometimes hear is if anything at all in the project doesn't type
| > check, we don't get any documentation at all. I think that it'd be
| > viable to generate only the documentation for the modules/functions
| > that do type-check and perhaps skip type signatures for everything
| else.
| >
| > Points 1. and 2. are of clear benefit. Point 3. is a simple
| > afterthought and thinking about it some more, I think that maybe it'd
| > be possible to do this with what we have right now: is type-checking
| > separate parts of the module supported? Can we retrieve documentation
| > for the parts that don't type-check?
| >
| > I am asking for input on what people think. I am not familiar at all
| > with what goes into the .hi file (and I can't find anything concrete!
| > Am I missing some wiki page?) at all and why. At the very least, 1.
| > should be easy to implement.
| >
| > It was suggested that I submit a proposal for this as part of GSoC,
| > namely implementing 1. and 2.. I admit that having much faster
| > documentation builds would be amazing and Edward K. and Carter S. seem
| > to think that this is very do-able in the 3 month period that GSoC
| > runs over.
| >
| > While I say all this, I have already submitted my proposal on a
| > different topic. I am considering writing this up and submitting this
| > as well but I am looking for some insight into the problem first.
| >
| > If there are any students around still looking for ideas, please do
| > speak up if you want to snatch this. If there are people that are
| > eager to mentor something like this then I suppose they should speak
| up too.
| >
| > Thanks!
| >
| _______________________________________________
| ghc-devs mailing list
| ghc-devs at haskell.org
| http://www.haskell.org/mailman/listinfo/ghc-devs

From hvriedel at gmail.com  Thu Mar 20 08:53:32 2014
From: hvriedel at gmail.com (Herbert Valerio Riedel)
Date: Thu, 20 Mar 2014 09:53:32 +0100
Subject: HEADS-UP: haddock.git to be turned into submodule soon (was:
 HEADS-UP: new server-side validation git hook for submodule updates &
 call-for-help)
In-Reply-To: <87pplj7oyr.fsf@gmail.com> (Herbert Valerio Riedel's message of
 "Tue, 18 Mar 2014 11:58:36 +0100")
References: <87pplj7oyr.fsf@gmail.com>
Message-ID: <87txatdzeb.fsf@gmail.com>

Hello *

On 2014-03-18 at 11:58:36 +0100, Herbert Valerio Riedel wrote:

[...]

> The next steps, however, include taking care of the client-side work-flow
> for working with a fully "submoduled" ghc.git setup. 

[...]

After having discussed this with the current Haddock maintainers
(i.e. Simon and Mateusz) who are volunteering to help ironing out the
Git workflow with submodules by having haddock.git turned into one, I
plan to convert utils/haddock into a proper submodule by the end of this
weekend (i.e. 2014-03-22/23).

This will allow us to gain experience with submodules for a single
submodule while only very few developers are actively affected (as only
few developers currently push directly to haddock.git these days) and
write up Git-workflow-with-submodules documentation somewhere at

  https://ghc.haskell.org/trac/ghc/wiki/WorkingConventions/Git

Details will follow when the conversion of haddock.git is actually
implemented.

Cheers,
  hvr

From fuuzetsu at fuuzetsu.co.uk  Thu Mar 20 10:39:47 2014
From: fuuzetsu at fuuzetsu.co.uk (Mateusz Kowalczyk)
Date: Thu, 20 Mar 2014 10:39:47 +0000
Subject: Haddock strings in .hi files
In-Reply-To: <59543203684B2244980D7E4057D5FBC14880AF25@DB3EX14MBXC308.europe.corp.microsoft.com>
References: <53288E64.8060704@fuuzetsu.co.uk> <53298200.4000509@gmail.com>
 <59543203684B2244980D7E4057D5FBC14880AF25@DB3EX14MBXC308.europe.corp.microsoft.com>
Message-ID: <532AC573.8020205@fuuzetsu.co.uk>

On 20/03/14 08:08, Simon Peyton Jones wrote:
> | The current design is intended to separate Haddock from GHC as much as
> | possible, but putting documentation in .hi files would be going in the
> | opposite direction.  There would have to be a compelling reason to do
> | that, something that we couldn't do another way.
> 
> Actually it would in many ways be easier to put Haddock stuff in .hi files.  But since GHC writes the .hi file, that would essentially mean merging GHC and Haddock into a single compile-and-documentation-generator.   That would be cool in a way -- for example, GHCi would natively have access to the Haddock docs for a function.
> 
> As Simon M says, the big reason not to do that is because it couples together two large projects, making each harder to develop independently.  And that's a pretty big reason.
> 
> Simon
> 
> [snip]
	
Wasn't this the case years ago? I was under the impression (from commit
messages and various bits in source comments and on the web) that
Haddock used to sit directly in GHC and then got ripped out by Simon M
and David W. Putting it back into GHC seems like a step back, especially
because as Simon M mentions, the functionality to grab documentation for
something can be provided by Haddock and GHCi then can use that. I think
an extra benefit of this is that we get to decide in Haddock how we
present such documentation: we can have different pretty printers if we
so desire. If the strings are in .hi files themselves, the only choice
is to show them verbatim which can be sub-par.

So if having documentation in GHCi is the sole goal, I think it's not
worth putting the strings in the .hi file. If it were to speed up
Haddock dramatically then I would be much less reluctant but as Simon M
points out, that idea doesn't really work. I think if we are to speed up
Haddock, something clever does need to happen in GHC and Haddock but now
I don't think that putting the strings in .hi files is the way to
achieve that. I also can see quite a few people upset about further
coupling of Haddock and GHC and bloating up the .hi files with extra data.

What do you think?
-- 
Mateusz K.

From hvriedel at gmail.com  Thu Mar 20 10:45:36 2014
From: hvriedel at gmail.com (Herbert Valerio Riedel)
Date: Thu, 20 Mar 2014 11:45:36 +0100
Subject: Haddock strings in .hi files
In-Reply-To: <532AC573.8020205@fuuzetsu.co.uk> (Mateusz Kowalczyk's message of
 "Thu, 20 Mar 2014 10:39:47 +0000")
References: <53288E64.8060704@fuuzetsu.co.uk> <53298200.4000509@gmail.com>
 <59543203684B2244980D7E4057D5FBC14880AF25@DB3EX14MBXC308.europe.corp.microsoft.com>
 <532AC573.8020205@fuuzetsu.co.uk>
Message-ID: <87pplhdu7j.fsf@gmail.com>

On 2014-03-20 at 11:39:47 +0100, Mateusz Kowalczyk wrote:
> [...] the functionality to grab documentation for something can be
> provided by Haddock and GHCi then can use that. I think an extra
> benefit of this is that we get to decide in Haddock how we present
> such documentation: we can have different pretty printers if we so
> desire. If the strings are in .hi files themselves, the only choice is
> to show them verbatim which can be sub-par.
>
> So if having documentation in GHCi is the sole goal, I think it's not
> worth putting the strings in the .hi file.

Just wondering: how would GHCi have to handle the case of e.g. ':reload'
(in "-fobject-code" as well as "-fbyte-code" mode), in order to have
access to up-to-date Haddock strings?

From fuuzetsu at fuuzetsu.co.uk  Thu Mar 20 10:55:33 2014
From: fuuzetsu at fuuzetsu.co.uk (Mateusz Kowalczyk)
Date: Thu, 20 Mar 2014 10:55:33 +0000
Subject: Haddock strings in .hi files
In-Reply-To: <87pplhdu7j.fsf@gmail.com>
References: <53288E64.8060704@fuuzetsu.co.uk>
 <53298200.4000509@gmail.com>	<59543203684B2244980D7E4057D5FBC14880AF25@DB3EX14MBXC308.europe.corp.microsoft.com>	<532AC573.8020205@fuuzetsu.co.uk>
 <87pplhdu7j.fsf@gmail.com>
Message-ID: <532AC925.4030205@fuuzetsu.co.uk>

On 20/03/14 10:45, Herbert Valerio Riedel wrote:
> On 2014-03-20 at 11:39:47 +0100, Mateusz Kowalczyk wrote:
>> [...] the functionality to grab documentation for something can be
>> provided by Haddock and GHCi then can use that. I think an extra
>> benefit of this is that we get to decide in Haddock how we present
>> such documentation: we can have different pretty printers if we so
>> desire. If the strings are in .hi files themselves, the only choice is
>> to show them verbatim which can be sub-par.
>>
>> So if having documentation in GHCi is the sole goal, I think it's not
>> worth putting the strings in the .hi file.
> 
> Just wondering: how would GHCi have to handle the case of e.g. ':reload'
> (in "-fobject-code" as well as "-fbyte-code" mode), in order to have
> access to up-to-date Haddock strings?
> 
	
I imagine it can't if I'm guessing what you mean properly. If we are to
use Haddock, you'd have to generate up-to-date .haddock files. I don't
think that's a big problem because you wouldn't be asking for docs of
things that you're changing: you can just look in the source for that if
you really need to. I think the main utility of such feature is being
able to ask about docs of the libraries which we use (which we don't
change on the fly and have the docs for).

Well, it can, using its own API (just like we use it in Haddock) but I
don't imagine that would be fast enough for the user. I don't know, I'd
have to experiment.

-- 
Mateusz K.

From ptrommler at me.com  Thu Mar 20 11:27:37 2014
From: ptrommler at me.com (Peter Trommler)
Date: Thu, 20 Mar 2014 12:27:37 +0100
Subject: ghc-7.8.1 RC2 ppc dyn linked executable segfaults
In-Reply-To: <CAEDGBqLiBTsaakZnCLUQVoHp5=dPL=16TpP4eydwyK0TJF+CYg@mail.gmail.com>
References: <CAEDGBqKnddMLTX3ZqYpyx=UaZxNS+WH2w93M+hfuw+MYHgUh7A@mail.gmail.com>
 <CAEDGBqLiBTsaakZnCLUQVoHp5=dPL=16TpP4eydwyK0TJF+CYg@mail.gmail.com>
Message-ID: <17EA2E34-FB3E-4F75-A84F-2B9C17451D29@me.com>

Hi Jens,

It took me a while to set up my build on openSUSE.

I see the same issue on ppc: All dyn programs segfault.
In addition: Dynamic does not seem to compile (assembler errors)
with binutils 2.23.

My builds are here:
https://build.opensuse.org/package/show/home:ptrommler/ghc
and testsuite results:
https://build.opensuse.org/package/show/home:ptrommler/ghc-testsuite

Speaking of ppc64: Do you see ticket #8849 too?

Peter

On 19.03.2014, at 06:34, Jens Petersen <petersen at fedoraproject.org> wrote:

> On 18 March 2014 19:02, Jens Petersen <petersen at fedoraproject.org> wrote: 
> The ppc64 build looks okay, but ppc seems to have a problem with executables dyn linked to Haskell libs segfaulting.
> : 
> I don't have access yet to a ppc box to investigate further but I see the segfault for "ghc -dynamic Hello.hs; ./Hello" on ppc in the fedora buildsys.
> 
> http://ppc.koji.fedoraproject.org/kojifiles/work/tasks/1459/1711459/build.log&offset=-4000
> 
> Sorry correct link is: http://ppc.koji.fedoraproject.org/koji/getfile?taskID=1711459&name=build.log&offset=-4000 
> 
> I filed https://ghc.haskell.org/trac/ghc/ticket/8909 for this issue.
> 
> Jens
> 
> _______________________________________________
> ghc-devs mailing list
> ghc-devs at haskell.org
> http://www.haskell.org/mailman/listinfo/ghc-devs


From shumovichy at gmail.com  Thu Mar 20 14:38:10 2014
From: shumovichy at gmail.com (Yuras Shumovich)
Date: Thu, 20 Mar 2014 17:38:10 +0300
Subject: FFI: c/c++ struct on stack as an argument or return value
In-Reply-To: <53298995.7040708@gmail.com>
References: <1394797839.4664.35.camel@shum-lt>
 <5F969E34-BCF1-40CB-86DF-20F84245BEDB@cse.unsw.edu.au>
 <CAHYVw0xugANXO43pxA5yPH3xpZ4CxKOBA6UetwNAPa6XfLD0Ew@mail.gmail.com>
 <CAJumaK-KakS9=9ksGnOj9p6qYq3KmfoZwyCGju7d1kyytwcg8Q@mail.gmail.com>
 <CAHYVw0wje9Ju_rUfCQUeN=qRtbBs_aJ8TSY+75P3bH89vAJEHA@mail.gmail.com>
 <1394887862.4722.31.camel@shum-lt>
 <C86323E1-F09A-4FDA-88BD-6D28A1D28F83@cse.unsw.edu.au>
 <1395142949.4601.18.camel@shum-lt> <53298995.7040708@gmail.com>
Message-ID: <1395326290.4643.9.camel@shum-lt>

On Wed, 2014-03-19 at 12:12 +0000, Simon Marlow wrote:
> On 18/03/2014 11:42, Yuras Shumovich wrote:
> > On Tue, 2014-03-18 at 12:37 +1100, Manuel M T Chakravarty wrote:
> >>>
> >>> Library implementation can't generate native dynamic wrapper, it has to
> >>> use slow libffi.
> >>
> >> When we first implemented the FFI, there was no libffi. Maintaining the adjustor code for all platforms is a PITA; hence, using libffi was a welcome way to improve portability.
> >
> > Do you think we can remove native adjustors? I can prepare a patch.
> 
> I believe native adjustors are sufficiently faster than libffi to want 
> to keep them; at least that was what I found the last time I checked. 
> It might be the case that either libffi is now faster, or we could 
> optimise our libffi support enough that it isn't worth keeping native 
> adjustors.  I'd love it if that happened.
> 
> The benchmark I think I used is in nofib/smp/callback002.

callback002 is 10-15% faster with native adjustors then with libffi
(x86_64 linux, BuildFlavour = perf, mode=slow). Not a huge difference,
but it is noticeable.

Native adjustors:

6.53user 0.15system 0:06.69elapsed 99%CPU (0avgtext+0avgdata 2436maxresident)k
0inputs+8outputs (0major+894minor)pagefaults 0swaps
<<ghc: 32640054728 bytes, 58594 GCs (58592 + 2), 0/0 avg/max bytes residency (0 samples), 61418720 bytes GC work, 1M in use, 0.00 INIT (0.00 elapsed), 5.56 MUT (5.56 elapsed), 1.13 GC (1.13 elapsed), 1.13 GC(0) (1.13 elapsed), 0.00 GC(1) (0.00 elapsed), 1 balance :ghc>>


With "UseLibFFIForAdjustors=YES" in mk/build.mk:

7.18user 0.10system 0:07.29elapsed 99%CPU (0avgtext+0avgdata 2440maxresident)k
0inputs+8outputs (0major+893minor)pagefaults 0swaps
<<ghc: 32640054728 bytes, 58594 GCs (58592 + 2), 0/0 avg/max bytes residency (0 samples), 61418720 bytes GC work, 1M in use, 0.00 INIT (0.00 elapsed), 6.21 MUT (6.21 elapsed), 1.08 GC (1.08 elapsed), 1.08 GC(0) (1.08 elapsed), 0.00 GC(1) (0.00 elapsed), 1 balance :ghc>>


However, as Sergei Trofimovich mentioned, we use native adjustors only
on i386 and x86_64. So rts/AdjustorAsm.S and half of rts/Adjustor.c
seems to be a dead code. Unless someone has "UseLibFFIForAdjustors=NO"
in his mk/build.mk.

Thanks,
Yuras

> 
> Cheers,
> Simon
> 
> 
> > It requires minor changes to cache ffi_cif structure. On desugar phase
> > for each wrapper we can generate fresh global variable to store cif
> > pointer and pass it to createAdjustor.
> >
> >>
> >>>
> >>>  From my point of view, at this point it is more important to agree on
> >>> the next question: do we want such functionality in ghc at all? I don't
> >>> want to waste time on it if nobody wants to see it merged.
> >>
> >> I still don?t see the benefit in further complicating an already murky corner of the compiler. Moreover, for this to make sense, it would need to work on all supported platforms. Unless you are volunteering to implement it on multiple platforms, this would mean, we?d use libffi for most platforms anyway. This brings me to my original point, a library or tool is the better place for this.
> >
> > OK, I don't buy it, but I see your point.
> >
> >>
> >> Manuel
> >>
> >> PS: I?d happily accept language-c-inline patches for marshalling structs.
> >>
> >
> >
> > _______________________________________________
> > ghc-devs mailing list
> > ghc-devs at haskell.org
> > http://www.haskell.org/mailman/listinfo/ghc-devs
> >



From ekmett at gmail.com  Thu Mar 20 16:08:24 2014
From: ekmett at gmail.com (Edward Kmett)
Date: Thu, 20 Mar 2014 12:08:24 -0400
Subject: Haddock strings in .hi files
In-Reply-To: <59543203684B2244980D7E4057D5FBC14880AF25@DB3EX14MBXC308.europe.corp.microsoft.com>
References: <53288E64.8060704@fuuzetsu.co.uk> <53298200.4000509@gmail.com>
 <59543203684B2244980D7E4057D5FBC14880AF25@DB3EX14MBXC308.europe.corp.microsoft.com>
Message-ID: <CAJumaK9NnROpnV=kWYUY_ePj6W=gXBC1kYh-D-UqURBD0=2sSw@mail.gmail.com>

One strong reason for considering at least including the haddocks in the
.hi files is build times.

Currently if you have cabal configured to build and document every package
running hackage requires you to recompile your entire source tree a second
time to get information that we just dropped on the floor before spitting
out the .hi file.

For most of the users of GHC this is a 50% difference in compile times if
they have cabal configured to generate haddocks.

GHC doesn't have to understand the haddocks any more than it does now to
support it, just include the content.

Haddock could then just go through and load the .hi files rather than
starting from scratch with parsing and typechecking the entire module,
running template-haskell, just to get at the documentation.

Any pythonesque :doc command support to me would be gravy.

The reason I care at all is the build times. I regularly lose minutes out
of each build just to regenerate docs and wind up skipping building them as
much as I can get away with to avoid he pain.

-Edward


On Thu, Mar 20, 2014 at 4:08 AM, Simon Peyton Jones
<simonpj at microsoft.com>wrote:

> | The current design is intended to separate Haddock from GHC as much as
> | possible, but putting documentation in .hi files would be going in the
> | opposite direction.  There would have to be a compelling reason to do
> | that, something that we couldn't do another way.
>
> Actually it would in many ways be easier to put Haddock stuff in .hi
> files.  But since GHC writes the .hi file, that would essentially mean
> merging GHC and Haddock into a single compile-and-documentation-generator.
>   That would be cool in a way -- for example, GHCi would natively have
> access to the Haddock docs for a function.
>
> As Simon M says, the big reason not to do that is because it couples
> together two large projects, making each harder to develop independently.
>  And that's a pretty big reason.
>
> Simon
>
> | -----Original Message-----
> | From: ghc-devs [mailto:ghc-devs-bounces at haskell.org] On Behalf Of Simon
> | Marlow
> | Sent: 19 March 2014 11:40
> | To: Mateusz Kowalczyk; ghc-devs at haskell.org
> | Subject: Re: Haddock strings in .hi files
> |
> | On 18/03/2014 18:20, Mateusz Kowalczyk wrote:
> | > Hi all,
> | >
> | > I saw https://ghc.haskell.org/trac/ghc/ticket/5467 pop up in my inbox
> | > and it reminded me of something I've been wondering for a while: why
> | > do we not store Haddock docstrings in the interface file?
> | >
> | > I think that if we did, we could do some great things:
> | >
> | > 1. Show docs in GHCi (I vaguely recall someone working on this ~1 year
> | > ago, does anyone have any info?)
> | >
> | > 2. Allow Haddock to work a lot faster: the big majority of time spent
> | > when creating documentation is actually spent by Haddock calling
> | > various GHC functions, such as type-checking the modules. Only a small
> | > amount of time is actually spent by Haddock on other tasks such as
> | > parsing or outputting the documentation. If we could simply get
> | > everything we need from the .hi files, we save ourselves a lot of
> | time.
> |
> | Don't you still have to run the renamer at least?  And in GHC, renaming
> | is tied up with typechecking, so it's hard to do one without the other.
> |   Furthermore, if there is a missing type signature it's useful to be
> | able to put the inferred type in the documentation.  I think I'm missing
> | the point somewhere - how does putting docs in the .hi file let you
> | avoid typechecking?
> |
> | I'm not really sure I see the benefit.  If Haddock provided a library
> | that we can call from GHCi to get documentation, then we could show
> | documentation in GHCi.
> |
> | The current design is intended to separate Haddock from GHC as much as
> | possible, but putting documentation in .hi files would be going in the
> | opposite direction.  There would have to be a compelling reason to do
> | that, something that we couldn't do another way.
> |
> | Cheers,
> | Simon
> |
> |
> | > 3. Allow Haddock to create partial documentation: a complaint I
> | > sometimes hear is if anything at all in the project doesn't type
> | > check, we don't get any documentation at all. I think that it'd be
> | > viable to generate only the documentation for the modules/functions
> | > that do type-check and perhaps skip type signatures for everything
> | else.
> | >
> | > Points 1. and 2. are of clear benefit. Point 3. is a simple
> | > afterthought and thinking about it some more, I think that maybe it'd
> | > be possible to do this with what we have right now: is type-checking
> | > separate parts of the module supported? Can we retrieve documentation
> | > for the parts that don't type-check?
> | >
> | > I am asking for input on what people think. I am not familiar at all
> | > with what goes into the .hi file (and I can't find anything concrete!
> | > Am I missing some wiki page?) at all and why. At the very least, 1.
> | > should be easy to implement.
> | >
> | > It was suggested that I submit a proposal for this as part of GSoC,
> | > namely implementing 1. and 2.. I admit that having much faster
> | > documentation builds would be amazing and Edward K. and Carter S. seem
> | > to think that this is very do-able in the 3 month period that GSoC
> | > runs over.
> | >
> | > While I say all this, I have already submitted my proposal on a
> | > different topic. I am considering writing this up and submitting this
> | > as well but I am looking for some insight into the problem first.
> | >
> | > If there are any students around still looking for ideas, please do
> | > speak up if you want to snatch this. If there are people that are
> | > eager to mentor something like this then I suppose they should speak
> | up too.
> | >
> | > Thanks!
> | >
> | _______________________________________________
> | ghc-devs mailing list
> | ghc-devs at haskell.org
> | http://www.haskell.org/mailman/listinfo/ghc-devs
> _______________________________________________
> ghc-devs mailing list
> ghc-devs at haskell.org
> http://www.haskell.org/mailman/listinfo/ghc-devs
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/ghc-devs/attachments/20140320/9f44744c/attachment.html>

From fuuzetsu at fuuzetsu.co.uk  Thu Mar 20 16:18:13 2014
From: fuuzetsu at fuuzetsu.co.uk (Mateusz Kowalczyk)
Date: Thu, 20 Mar 2014 16:18:13 +0000
Subject: Haddock strings in .hi files
In-Reply-To: <CAJumaK9NnROpnV=kWYUY_ePj6W=gXBC1kYh-D-UqURBD0=2sSw@mail.gmail.com>
References: <53288E64.8060704@fuuzetsu.co.uk>	<53298200.4000509@gmail.com>	<59543203684B2244980D7E4057D5FBC14880AF25@DB3EX14MBXC308.europe.corp.microsoft.com>
 <CAJumaK9NnROpnV=kWYUY_ePj6W=gXBC1kYh-D-UqURBD0=2sSw@mail.gmail.com>
Message-ID: <532B14C5.4040203@fuuzetsu.co.uk>

On 20/03/14 16:08, Edward Kmett wrote:
> One strong reason for considering at least including the haddocks in the
> .hi files is build times.
> 
> Currently if you have cabal configured to build and document every package
> running hackage requires you to recompile your entire source tree a second
> time to get information that we just dropped on the floor before spitting
> out the .hi file.
> 
> For most of the users of GHC this is a 50% difference in compile times if
> they have cabal configured to generate haddocks.
> 
> GHC doesn't have to understand the haddocks any more than it does now to
> support it, just include the content.
> 
> Haddock could then just go through and load the .hi files rather than
> starting from scratch with parsing and typechecking the entire module,
> running template-haskell, just to get at the documentation.
> 
> Any pythonesque :doc command support to me would be gravy.
> 
> The reason I care at all is the build times. I regularly lose minutes out
> of each build just to regenerate docs and wind up skipping building them as
> much as I can get away with to avoid he pain.
> 
> -Edward
> 
> 

As Simon M points out, we still have to run the renamer which seems to
be tightly bound with the type-checker. Where do you suggest the
sizeable performance increase would be coming from in this case? For all
the existing packages, we already read the docs from .haddock files so
there's no difference there. For new packages we have to type-check and
generate .haddock anyway so there's no difference there either.

It's not really about GHC having to know more about Haddock, it's about
Haddock having to use GHC anyway, whether the strinsg are embedded or not.

-- 
Mateusz K.

From ekmett at gmail.com  Thu Mar 20 16:41:47 2014
From: ekmett at gmail.com (Edward Kmett)
Date: Thu, 20 Mar 2014 12:41:47 -0400
Subject: Haddock strings in .hi files
In-Reply-To: <532B14C5.4040203@fuuzetsu.co.uk>
References: <53288E64.8060704@fuuzetsu.co.uk> <53298200.4000509@gmail.com>
 <59543203684B2244980D7E4057D5FBC14880AF25@DB3EX14MBXC308.europe.corp.microsoft.com>
 <CAJumaK9NnROpnV=kWYUY_ePj6W=gXBC1kYh-D-UqURBD0=2sSw@mail.gmail.com>
 <532B14C5.4040203@fuuzetsu.co.uk>
Message-ID: <CAJumaK_Mo0hHPsLrASjY903u55UVkKoAYBRAK1YY=mnqsw=yxg@mail.gmail.com>

My knowledge of precisely how haddock works is somewhat fuzzy in that it
arises from a series of discussions a couple of years back.

My observation was mostly that I run 'cabal install' it goes through all
the modules building my .hi files, etc. Then I run cabal haddock and it
spends all that time redoing the same work, just to go through and get at
some information that we had right up until the moment we finished building.

I'm not wedded to bolting the information into the .hi files being the
solution, but the idea that we could avoid redoing that work is
tantalizing. I'm mostly trying to avoid redoing all the same work twice in
the build cycle of the average user.

If there is an alternative strategy, such as, oh, I don't know, making
haddock able to hook in plugin-style late as we're generating the .hi file
to spit out what it needs to something else and interrogate/rename/whatever
it needs the rest of the GHC API I'd be totally open that as well.

-Edward


On Thu, Mar 20, 2014 at 12:18 PM, Mateusz Kowalczyk <fuuzetsu at fuuzetsu.co.uk
> wrote:

> On 20/03/14 16:08, Edward Kmett wrote:
> > One strong reason for considering at least including the haddocks in the
> > .hi files is build times.
> >
> > Currently if you have cabal configured to build and document every
> package
> > running hackage requires you to recompile your entire source tree a
> second
> > time to get information that we just dropped on the floor before spitting
> > out the .hi file.
> >
> > For most of the users of GHC this is a 50% difference in compile times if
> > they have cabal configured to generate haddocks.
> >
> > GHC doesn't have to understand the haddocks any more than it does now to
> > support it, just include the content.
> >
> > Haddock could then just go through and load the .hi files rather than
> > starting from scratch with parsing and typechecking the entire module,
> > running template-haskell, just to get at the documentation.
> >
> > Any pythonesque :doc command support to me would be gravy.
> >
> > The reason I care at all is the build times. I regularly lose minutes out
> > of each build just to regenerate docs and wind up skipping building them
> as
> > much as I can get away with to avoid he pain.
> >
> > -Edward
> >
> >
>
> As Simon M points out, we still have to run the renamer which seems to
> be tightly bound with the type-checker. Where do you suggest the
> sizeable performance increase would be coming from in this case? For all
> the existing packages, we already read the docs from .haddock files so
> there's no difference there. For new packages we have to type-check and
> generate .haddock anyway so there's no difference there either.
>
> It's not really about GHC having to know more about Haddock, it's about
> Haddock having to use GHC anyway, whether the strinsg are embedded or not.
>
> --
> Mateusz K.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/ghc-devs/attachments/20140320/169dc9b1/attachment-0001.html>

From malcolm.wallace at me.com  Thu Mar 20 20:30:20 2014
From: malcolm.wallace at me.com (Malcolm Wallace)
Date: Thu, 20 Mar 2014 20:30:20 +0000
Subject: Haddock strings in .hi files
In-Reply-To: <CAJumaK_Mo0hHPsLrASjY903u55UVkKoAYBRAK1YY=mnqsw=yxg@mail.gmail.com>
References: <53288E64.8060704@fuuzetsu.co.uk> <53298200.4000509@gmail.com>
 <59543203684B2244980D7E4057D5FBC14880AF25@DB3EX14MBXC308.europe.corp.microsoft.com>
 <CAJumaK9NnROpnV=kWYUY_ePj6W=gXBC1kYh-D-UqURBD0=2sSw@mail.gmail.com>
 <532B14C5.4040203@fuuzetsu.co.uk>
 <CAJumaK_Mo0hHPsLrASjY903u55UVkKoAYBRAK1YY=mnqsw=yxg@mail.gmail.com>
Message-ID: <37252D68-0EEC-41E1-8D9A-80B1F4671A5E@me.com>


On 20 Mar 2014, at 16:41, Edward Kmett wrote:

> My observation was mostly that I run 'cabal install' it goes through all the modules building my .hi files, etc. Then I run cabal haddock and it spends all that time redoing the same work, just to go through and get at some information that we had right up until the moment we finished building.
> 
> I'm not wedded to bolting the information into the .hi files being the solution, but the idea that we could avoid redoing that work is tantalizing.

One obvious solution could be for Haddock to learn how to read the existing .hi files, solely to read out the type signature of any exported entity that does not have an explicit signature in the source file.

Regards,
    Malcolm

From marlowsd at gmail.com  Fri Mar 21 11:38:33 2014
From: marlowsd at gmail.com (Simon Marlow)
Date: Fri, 21 Mar 2014 11:38:33 +0000
Subject: Haddock strings in .hi files
In-Reply-To: <CAJumaK_Mo0hHPsLrASjY903u55UVkKoAYBRAK1YY=mnqsw=yxg@mail.gmail.com>
References: <53288E64.8060704@fuuzetsu.co.uk>	<53298200.4000509@gmail.com>	<59543203684B2244980D7E4057D5FBC14880AF25@DB3EX14MBXC308.europe.corp.microsoft.com>	<CAJumaK9NnROpnV=kWYUY_ePj6W=gXBC1kYh-D-UqURBD0=2sSw@mail.gmail.com>	<532B14C5.4040203@fuuzetsu.co.uk>
 <CAJumaK_Mo0hHPsLrASjY903u55UVkKoAYBRAK1YY=mnqsw=yxg@mail.gmail.com>
Message-ID: <532C24B9.9010401@gmail.com>

Ok, I buy the argument that if we're already compiling everything, we 
shouldn't have to re-typecheck it all in Haddock. Of course if you're 
*not* already compiling everything, then the argument doesn't apply: 
Haddock does support generating documentation from source files without 
precompiling them, but I think if you ask the GHC API to load modules 
with -fno-code it should do the right thing: load up the .hi files if 
they're up to date, or typecheck the modules otherwise.

So I think having GHC spit out the docs as a side-effect of compilation 
is fine, so long as we don't have to do all the Haddock processing 
inside GHC itself, and provided this eliminates Haddock's own interface 
files (which are a pain).  If the docs go in the .hi file, then they 
must go in a separate section that is lazy parsed - we already do this 
for various other sections in the .hi file.

I don't think this is easy, but it's probably doable.  The code that 
attached docs to declarations is currently part of Haddock itself, so 
perhaps this has to move into GHC.

Cheers,
Simon

On 20/03/2014 16:41, Edward Kmett wrote:
> My knowledge of precisely how haddock works is somewhat fuzzy in that it
> arises from a series of discussions a couple of years back.
>
> My observation was mostly that I run 'cabal install' it goes through all
> the modules building my .hi files, etc. Then I run cabal haddock and it
> spends all that time redoing the same work, just to go through and get
> at some information that we had right up until the moment we finished
> building.
>
> I'm not wedded to bolting the information into the .hi files being the
> solution, but the idea that we could avoid redoing that work is
> tantalizing. I'm mostly trying to avoid redoing all the same work twice
> in the build cycle of the average user.
>
> If there is an alternative strategy, such as, oh, I don't know, making
> haddock able to hook in plugin-style late as we're generating the .hi
> file to spit out what it needs to something else and
> interrogate/rename/whatever it needs the rest of the GHC API I'd be
> totally open that as well.
>
> -Edward
>
>
> On Thu, Mar 20, 2014 at 12:18 PM, Mateusz Kowalczyk
> <fuuzetsu at fuuzetsu.co.uk <mailto:fuuzetsu at fuuzetsu.co.uk>> wrote:
>
>     On 20/03/14 16:08, Edward Kmett wrote:
>      > One strong reason for considering at least including the haddocks
>     in the
>      > .hi files is build times.
>      >
>      > Currently if you have cabal configured to build and document
>     every package
>      > running hackage requires you to recompile your entire source tree
>     a second
>      > time to get information that we just dropped on the floor before
>     spitting
>      > out the .hi file.
>      >
>      > For most of the users of GHC this is a 50% difference in compile
>     times if
>      > they have cabal configured to generate haddocks.
>      >
>      > GHC doesn't have to understand the haddocks any more than it does
>     now to
>      > support it, just include the content.
>      >
>      > Haddock could then just go through and load the .hi files rather than
>      > starting from scratch with parsing and typechecking the entire
>     module,
>      > running template-haskell, just to get at the documentation.
>      >
>      > Any pythonesque :doc command support to me would be gravy.
>      >
>      > The reason I care at all is the build times. I regularly lose
>     minutes out
>      > of each build just to regenerate docs and wind up skipping
>     building them as
>      > much as I can get away with to avoid he pain.
>      >
>      > -Edward
>      >
>      >
>
>     As Simon M points out, we still have to run the renamer which seems to
>     be tightly bound with the type-checker. Where do you suggest the
>     sizeable performance increase would be coming from in this case? For all
>     the existing packages, we already read the docs from .haddock files so
>     there's no difference there. For new packages we have to type-check and
>     generate .haddock anyway so there's no difference there either.
>
>     It's not really about GHC having to know more about Haddock, it's about
>     Haddock having to use GHC anyway, whether the strinsg are embedded
>     or not.
>
>     --
>     Mateusz K.
>
>

From ekmett at gmail.com  Fri Mar 21 13:37:21 2014
From: ekmett at gmail.com (Edward Kmett)
Date: Fri, 21 Mar 2014 09:37:21 -0400
Subject: Haddock strings in .hi files
In-Reply-To: <532C24B9.9010401@gmail.com>
References: <53288E64.8060704@fuuzetsu.co.uk> <53298200.4000509@gmail.com>
 <59543203684B2244980D7E4057D5FBC14880AF25@DB3EX14MBXC308.europe.corp.microsoft.com>
 <CAJumaK9NnROpnV=kWYUY_ePj6W=gXBC1kYh-D-UqURBD0=2sSw@mail.gmail.com>
 <532B14C5.4040203@fuuzetsu.co.uk>
 <CAJumaK_Mo0hHPsLrASjY903u55UVkKoAYBRAK1YY=mnqsw=yxg@mail.gmail.com>
 <532C24B9.9010401@gmail.com>
Message-ID: <CAJumaK-DByfmfioe8nwTgk6sUUJoc5McOCLydLrNMuqjxt9fMg@mail.gmail.com>

On Fri, Mar 21, 2014 at 7:38 AM, Simon Marlow <marlowsd at gmail.com> wrote:

> Ok, I buy the argument that if we're already compiling everything, we
> shouldn't have to re-typecheck it all in Haddock. Of course if you're *not*
> already compiling everything, then the argument doesn't apply: Haddock does
> support generating documentation from source files without precompiling
> them, but I think if you ask the GHC API to load modules with -fno-code it
> should do the right thing: load up the .hi files if they're up to date, or
> typecheck the modules otherwise.
>

Definitely. That said, cabal installing a package with documentation is by
far the most common scenario, and that is the thing that could be sped up
the most here.

So I think having GHC spit out the docs as a side-effect of compilation is
> fine, so long as we don't have to do all the Haddock processing inside GHC
> itself, and provided this eliminates Haddock's own interface files (which
> are a pain).  If the docs go in the .hi file, then they must go in a
> separate section that is lazy parsed - we already do this for various other
> sections in the .hi file.
>

Exactly.


> I don't think this is easy, but it's probably doable.  The code that
> attached docs to declarations is currently part of Haddock itself, so
> perhaps this has to move into GHC.
>

This was originally scoped to be around the level of work of a GSoC
project, and folks were worried that it came in a bit light, so it taking
some effort isn't unreasonable. I don't think we have an application for it
yet this year, so we probably have some time to chew it over unless someone
applies to do this in the next few hours. (We had one student, but she
backed out at the last second due to other constraints.)

-Edward
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/ghc-devs/attachments/20140321/2a49aa79/attachment.html>

From alfredo.dinapoli at gmail.com  Fri Mar 21 21:27:55 2014
From: alfredo.dinapoli at gmail.com (Alfredo Di Napoli)
Date: Fri, 21 Mar 2014 21:27:55 +0000
Subject: Was GHC 7.8 RC2 profiled-compiled?
Message-ID: <CAFqA6+WXKD27q8=VaB9K6DKBUb-Jv1yjYRo1+h5K6b_P6qyA6g@mail.gmail.com>

Evening guys,

was GHC 7.8 RC2 released with profiling enabled? Trying to use TH yields:

You can't use Template Haskell with a profiled compiler

This message is spit out from ghc mod.

Do you guys know if the plan was releasing the RC2 profile compiled or is
just a flag forgotten to be disabled?

Furthermore, do you know if is available a non-profiled version available
for Mavericks ?

Sorry if I'm just being stupid!

Alfredo
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/ghc-devs/attachments/20140321/a5d44b25/attachment.html>

From alfredo.dinapoli at gmail.com  Fri Mar 21 21:32:07 2014
From: alfredo.dinapoli at gmail.com (Alfredo Di Napoli)
Date: Fri, 21 Mar 2014 21:32:07 +0000
Subject: Was GHC 7.8 RC2 profiled-compiled?
In-Reply-To: <CAFqA6+WXKD27q8=VaB9K6DKBUb-Jv1yjYRo1+h5K6b_P6qyA6g@mail.gmail.com>
References: <CAFqA6+WXKD27q8=VaB9K6DKBUb-Jv1yjYRo1+h5K6b_P6qyA6g@mail.gmail.com>
Message-ID: <CAFqA6+Vq=MzsPntOKa6jnsy-Gk293A3h9ZSy-cDt0i-T69V49w@mail.gmail.com>

Interesting, enabling TemplateHaskell in cabal as "default extension" made
the error go away.


On 21 March 2014 21:27, Alfredo Di Napoli <alfredo.dinapoli at gmail.com>wrote:

> Evening guys,
>
> was GHC 7.8 RC2 released with profiling enabled? Trying to use TH yields:
>
> You can't use Template Haskell with a profiled compiler
>
> This message is spit out from ghc mod.
>
> Do you guys know if the plan was releasing the RC2 profile compiled or is
> just a flag forgotten to be disabled?
>
> Furthermore, do you know if is available a non-profiled version available
> for Mavericks ?
>
> Sorry if I'm just being stupid!
>
> Alfredo
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/ghc-devs/attachments/20140321/fec2a8b0/attachment.html>

From slyich at gmail.com  Sat Mar 22 19:21:42 2014
From: slyich at gmail.com (Sergei Trofimovich)
Date: Sat, 22 Mar 2014 22:21:42 +0300
Subject: ghc-7.8-rc2 in -O2 mode eats all stack and RAM on pandoc-citeproc /
 highlighting-kate
Message-ID: <20140322222142.798abe7e@sf>

Hello!

I have noticed the problem in ghc-7.6.3 first
when tried to build all haskell userland with -O2 opt level.

It led to amazing bugs!

Here is one of those (highlighting-kate hackage package):
> [281 of 452] Compiling Text.Highlighting.Kate.Syntax.Asp ( highlighting-kate-0.5.6.1/Text/Highlighting/Kate/Syntax/Asp.hs, highlighting-kate-0.5.6.1/Text/Highlighting/Kate/Syntax/Asp.o )
> stack overflow: use +RTS -K<size> to increase it

How to reproduce it:
1. Download a bundled file (6.6MB):
    http://code.haskell.org/~slyfox/selfcontained-eater-ghc-7.8-rc2.tar.gz
2. Unpack and run there:
  ./mk.sh

The script is designed to plug any built ghc version w/o external depends.

Command will fail as:
    $ ./mk.sh
    ...
    [281 of 452] Compiling Text.Highlighting.Kate.Syntax.Asp ( highlighting-kate-0.5.6.1/Text/Highlighting/Kate/Syntax/Asp.hs, highlighting-kate-0.5.6.1/Text/Highlighting/Kate/Syntax/Asp.o )
    stack overflow: use +RTS -K<size> to increase it

On ghc-7.6.3 it will progress a bit more: down to 452 file and will crash there
similar way.

I've 'cabal unpack'-ed all sources and configured/de-.hsc-ed them
manually/added needed -DWhatever / added {-# LANGUAGE CPP #-}
around. Nothing else.

It's very hard to shrink such large thing manually down to 2-3 files.
Would be cool if ghc (and cabal) would be able to spit something
self-sufficient (like 'gcc -i' does) for devs to reproduce.

Adding '-v' shows such log:
    ...
    *** Simplifier:
    Result size of Simplifier iteration=1
      = {terms: 21,973, types: 21,838, coercions: 1,842}
    Result size of Simplifier iteration=2
      = {terms: 21,952, types: 21,819, coercions: 1,842}
    Result size of Simplifier
      = {terms: 21,950, types: 21,817, coercions: 1,842}
    *** SpecConstr:
    Result size of SpecConstr***<CRASH>

Thanks!

-- 

  Sergei
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: not available
URL: <http://www.haskell.org/pipermail/ghc-devs/attachments/20140322/7d4ba9d9/attachment.sig>

From johan.tibell at gmail.com  Sat Mar 22 20:37:15 2014
From: johan.tibell at gmail.com (Johan Tibell)
Date: Sat, 22 Mar 2014 21:37:15 +0100
Subject: [commit: packages/template-haskell] master: Make Pred a type
 synonym of Type (issue #7021) (57b662c)
In-Reply-To: <20140210013952.DA0432406B@ghc.haskell.org>
References: <20140210013952.DA0432406B@ghc.haskell.org>
Message-ID: <CAK-tuPZC2PmRsH352=rMaw6qqHArz=D=Xp-t4wjDKf0WswZ6Ow@mail.gmail.com>

What's the right way to fix libraries (e.g. aeson) that break because
classP was removed?


On Mon, Feb 10, 2014 at 2:39 AM, <git at git.haskell.org> wrote:

> Repository : ssh://git at git.haskell.org/template-haskell
>
> On branch  : master
> Link       :
> http://git.haskell.org/packages/template-haskell.git/commitdiff/57b662c3efd8579595c8642fce2d4cd60ba4ec0b
>
> >---------------------------------------------------------------
>
> commit 57b662c3efd8579595c8642fce2d4cd60ba4ec0b
> Author: YoEight <yo.eight at gmail.com>
> Date:   Fri Jan 10 21:42:01 2014 +0100
>
>     Make Pred a type synonym of Type (issue #7021)
>
>     In order to make any type as a Predicate in Template Haskell, as
> allowed by ConstraintKinds
>
>     Signed-off-by: Richard Eisenberg <eir at cis.upenn.edu>
>
>
> >---------------------------------------------------------------
>
> 57b662c3efd8579595c8642fce2d4cd60ba4ec0b
>  Language/Haskell/TH.hs        |    7 +++----
>  Language/Haskell/TH/Lib.hs    |   21 ++++++++-------------
>  Language/Haskell/TH/Ppr.hs    |    8 ++------
>  Language/Haskell/TH/Syntax.hs |    6 ++----
>  4 files changed, 15 insertions(+), 27 deletions(-)
>
> diff --git a/Language/Haskell/TH.hs b/Language/Haskell/TH.hs
> index 2ab19bd..e9765a9 100644
> --- a/Language/Haskell/TH.hs
> +++ b/Language/Haskell/TH.hs
> @@ -68,7 +68,7 @@ module Language.Haskell.TH(
>      -- ** Patterns
>          Pat(..), FieldExp, FieldPat,
>      -- ** Types
> -        Type(..), TyVarBndr(..), TyLit(..), Kind, Cxt, Pred(..),
> Syntax.Role(..),
> +        Type(..), TyVarBndr(..), TyLit(..), Kind, Cxt, Pred,
> Syntax.Role(..),
>
>      -- * Library functions
>      -- ** Abbreviations
> @@ -105,14 +105,14 @@ module Language.Haskell.TH(
>      bindS, letS, noBindS, parS,
>
>      -- *** Types
> -       forallT, varT, conT, appT, arrowT, listT, tupleT, sigT, litT,
> +       forallT, varT, conT, appT, arrowT, equalityT, listT, tupleT, sigT,
> litT,
>      promotedT, promotedTupleT, promotedNilT, promotedConsT,
>      -- **** Type literals
>      numTyLit, strTyLit,
>      -- **** Strictness
>         isStrict, notStrict, strictType, varStrictType,
>      -- **** Class Contexts
> -    cxt, classP, equalP, normalC, recC, infixC, forallC,
> +    cxt, normalC, recC, infixC, forallC,
>
>      -- *** Kinds
>    varK, conK, tupleK, arrowK, listK, appK, starK, constraintK,
> @@ -146,4 +146,3 @@ module Language.Haskell.TH(
>  import Language.Haskell.TH.Syntax as Syntax
>  import Language.Haskell.TH.Lib
>  import Language.Haskell.TH.Ppr
> -
> diff --git a/Language/Haskell/TH/Lib.hs b/Language/Haskell/TH/Lib.hs
> index b7a88d6..17e794b 100644
> --- a/Language/Haskell/TH/Lib.hs
> +++ b/Language/Haskell/TH/Lib.hs
> @@ -466,19 +466,6 @@ tySynEqn lhs rhs =
>  cxt :: [PredQ] -> CxtQ
>  cxt = sequence
>
> -classP :: Name -> [TypeQ] -> PredQ
> -classP cla tys
> -  = do
> -      tys1 <- sequence tys
> -      return (ClassP cla tys1)
> -
> -equalP :: TypeQ -> TypeQ -> PredQ
> -equalP tleft tright
> -  = do
> -      tleft1  <- tleft
> -      tright1 <- tright
> -      return (EqualP tleft1 tright1)
> -
>  normalC :: Name -> [StrictTypeQ] -> ConQ
>  normalC con strtys = liftM (NormalC con) $ sequence strtys
>
> @@ -536,6 +523,14 @@ sigT t k
>        t' <- t
>        return $ SigT t' k
>
> +equalityT :: TypeQ -> TypeQ -> TypeQ
> +equalityT tleft tright
> +  = do
> +      tleft1  <- tleft
> +      tright1 <- tright
> +      let typ = AppT (AppT EqualityT tleft1) tright1
> +      return typ
> +
>  promotedT :: Name -> TypeQ
>  promotedT = return . PromotedT
>
> diff --git a/Language/Haskell/TH/Ppr.hs b/Language/Haskell/TH/Ppr.hs
> index 2023f3a..e237066 100644
> --- a/Language/Haskell/TH/Ppr.hs
> +++ b/Language/Haskell/TH/Ppr.hs
> @@ -496,6 +496,8 @@ instance Ppr Type where
>
>  pprTyApp :: (Type, [Type]) -> Doc
>  pprTyApp (ArrowT, [arg1,arg2]) = sep [pprFunArgType arg1 <+> text "->",
> ppr arg2]
> +pprTyApp (EqualityT, [arg1, arg2]) =
> +    sep [pprFunArgType arg1 <+> text "~", ppr arg2]
>  pprTyApp (ListT, [arg]) = brackets (ppr arg)
>  pprTyApp (TupleT n, args)
>   | length args == n = parens (sep (punctuate comma (map ppr args)))
> @@ -540,11 +542,6 @@ pprCxt [t] = ppr t <+> text "=>"
>  pprCxt ts = parens (sep $ punctuate comma $ map ppr ts) <+> text "=>"
>
>  ------------------------------
> -instance Ppr Pred where
> -  ppr (ClassP cla tys) = ppr cla <+> sep (map pprParendType tys)
> -  ppr (EqualP ty1 ty2) = pprFunArgType ty1 <+> char '~' <+> pprFunArgType
> ty2
> -
> -------------------------------
>  instance Ppr Range where
>      ppr = brackets . pprRange
>          where pprRange :: Range -> Doc
> @@ -569,4 +566,3 @@ hashParens d = text "(# " <> d <> text " #)"
>
>  quoteParens :: Doc -> Doc
>  quoteParens d = text "'(" <> d <> text ")"
> -
> diff --git a/Language/Haskell/TH/Syntax.hs b/Language/Haskell/TH/Syntax.hs
> index 3606f9d..17bb065 100644
> --- a/Language/Haskell/TH/Syntax.hs
> +++ b/Language/Haskell/TH/Syntax.hs
> @@ -1346,9 +1346,7 @@ data AnnTarget = ModuleAnnotation
>
>  type Cxt = [Pred]                 -- ^ @(Eq a, Ord b)@
>
> -data Pred = ClassP Name [Type]    -- ^ @Eq (Int, a)@
> -          | EqualP Type Type      -- ^ @F a ~ Bool@
> -          deriving( Show, Eq, Data, Typeable )
> +type Pred = Type
>
>  data Strict = IsStrict | NotStrict | Unpacked
>           deriving( Show, Eq, Data, Typeable )
> @@ -1373,6 +1371,7 @@ data Type = ForallT [TyVarBndr] Cxt Type  -- ^
> @forall \<vars\>. \<ctxt\> -> \<t
>            | TupleT Int                    -- ^ @(,), (,,), etc.@
>            | UnboxedTupleT Int             -- ^ @(#,#), (#,,#), etc.@
>            | ArrowT                        -- ^ @->@
> +          | EqualityT                     -- ^ @~@
>            | ListT                         -- ^ @[]@
>            | PromotedTupleT Int            -- ^ @'(), '(,), '(,,), etc.@
>            | PromotedNilT                  -- ^ @'[]@
> @@ -1453,4 +1452,3 @@ cmpEq _  = False
>  thenCmp :: Ordering -> Ordering -> Ordering
>  thenCmp EQ o2 = o2
>  thenCmp o1 _  = o1
> -
>
> _______________________________________________
> ghc-commits mailing list
> ghc-commits at haskell.org
> http://www.haskell.org/mailman/listinfo/ghc-commits
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/ghc-devs/attachments/20140322/d82018ae/attachment.html>

From fuuzetsu at fuuzetsu.co.uk  Sat Mar 22 20:53:28 2014
From: fuuzetsu at fuuzetsu.co.uk (Mateusz Kowalczyk)
Date: Sat, 22 Mar 2014 20:53:28 +0000
Subject: [commit: packages/template-haskell] master: Make Pred a type
 synonym of Type (issue #7021) (57b662c)
In-Reply-To: <CAK-tuPZC2PmRsH352=rMaw6qqHArz=D=Xp-t4wjDKf0WswZ6Ow@mail.gmail.com>
References: <20140210013952.DA0432406B@ghc.haskell.org>
 <CAK-tuPZC2PmRsH352=rMaw6qqHArz=D=Xp-t4wjDKf0WswZ6Ow@mail.gmail.com>
Message-ID: <532DF848.7020308@fuuzetsu.co.uk>

On 22/03/14 20:37, Johan Tibell wrote:
> What's the right way to fix libraries (e.g. aeson) that break because
> classP was removed?
> 

I have already patched lens, aeson, free, derive and binarydefer. You
can look for commits with my e-mail in those projects for how it was done.

All you need to do now to get aeson to compile on 7.9 is to get Bryan to
upload a new version with the relevant commit on Hackage.


-- 
Mateusz K.

From eir at cis.upenn.edu  Sun Mar 23 00:45:19 2014
From: eir at cis.upenn.edu (Richard Eisenberg)
Date: Sat, 22 Mar 2014 20:45:19 -0400
Subject: [commit: packages/template-haskell] master: Make Pred a type
 synonym of Type (issue #7021) (57b662c)
In-Reply-To: <532DF848.7020308@fuuzetsu.co.uk>
References: <20140210013952.DA0432406B@ghc.haskell.org>
 <CAK-tuPZC2PmRsH352=rMaw6qqHArz=D=Xp-t4wjDKf0WswZ6Ow@mail.gmail.com>
 <532DF848.7020308@fuuzetsu.co.uk>
Message-ID: <2B3EB4E1-C0C5-4765-81D1-11ECCDEA8C45@cis.upenn.edu>

Note that the removal of `classP` is only for HEAD -- it will *not* be merged in for 7.8, which would be way too big a change at this point.

Richard

On Mar 22, 2014, at 4:53 PM, Mateusz Kowalczyk wrote:

> On 22/03/14 20:37, Johan Tibell wrote:
>> What's the right way to fix libraries (e.g. aeson) that break because
>> classP was removed?
>> 
> 
> I have already patched lens, aeson, free, derive and binarydefer. You
> can look for commits with my e-mail in those projects for how it was done.
> 
> All you need to do now to get aeson to compile on 7.9 is to get Bryan to
> upload a new version with the relevant commit on Hackage.
> 
> 
> -- 
> Mateusz K.
> _______________________________________________
> ghc-devs mailing list
> ghc-devs at haskell.org
> http://www.haskell.org/mailman/listinfo/ghc-devs


From fuuzetsu at fuuzetsu.co.uk  Sun Mar 23 01:05:28 2014
From: fuuzetsu at fuuzetsu.co.uk (Mateusz Kowalczyk)
Date: Sun, 23 Mar 2014 01:05:28 +0000
Subject: [commit: packages/template-haskell] master: Make Pred a type
 synonym of Type (issue #7021) (57b662c)
In-Reply-To: <2B3EB4E1-C0C5-4765-81D1-11ECCDEA8C45@cis.upenn.edu>
References: <20140210013952.DA0432406B@ghc.haskell.org>
 <CAK-tuPZC2PmRsH352=rMaw6qqHArz=D=Xp-t4wjDKf0WswZ6Ow@mail.gmail.com>
 <532DF848.7020308@fuuzetsu.co.uk>
 <2B3EB4E1-C0C5-4765-81D1-11ECCDEA8C45@cis.upenn.edu>
Message-ID: <532E3358.3030504@fuuzetsu.co.uk>

On 23/03/14 00:45, Richard Eisenberg wrote:
> Note that the removal of `classP` is only for HEAD -- it will *not* be merged in for 7.8, which would be way too big a change at this point.
> 
> Richard
> 
> On Mar 22, 2014, at 4:53 PM, Mateusz Kowalczyk wrote:
> 
>> On 22/03/14 20:37, Johan Tibell wrote:
>>> What's the right way to fix libraries (e.g. aeson) that break because
>>> classP was removed?
>>>
>>
>> I have already patched lens, aeson, free, derive and binarydefer. You
>> can look for commits with my e-mail in those projects for how it was done.
>>
>> All you need to do now to get aeson to compile on 7.9 is to get Bryan to
>> upload a new version with the relevant commit on Hackage.
>>
>>
>> -- 
>> Mateusz K.
>> _______________________________________________
>> ghc-devs mailing list
>> ghc-devs at haskell.org
>> http://www.haskell.org/mailman/listinfo/ghc-devs
> 

Right. I've been using __GLASGOW_HASKELL__ CPP tokens to bound this off
so far. Is there a reason why the Template Haskell version wasn't bumped
after this change? This makes it impossible to instead use tokens that
work based on TH version rather than GHC version. As far as I can tell,
what's shipping with 7.8 is TH 2.9.0.0 and the breaking change that's
currently in 7.9 is also TH 2.9.0.0.

-- 
Mateusz K.

From eir at cis.upenn.edu  Sun Mar 23 03:40:14 2014
From: eir at cis.upenn.edu (Richard Eisenberg)
Date: Sat, 22 Mar 2014 23:40:14 -0400
Subject: [commit: packages/template-haskell] master: Make Pred a type
 synonym of Type (issue #7021) (57b662c)
In-Reply-To: <532E3358.3030504@fuuzetsu.co.uk>
References: <20140210013952.DA0432406B@ghc.haskell.org>
 <CAK-tuPZC2PmRsH352=rMaw6qqHArz=D=Xp-t4wjDKf0WswZ6Ow@mail.gmail.com>
 <532DF848.7020308@fuuzetsu.co.uk>
 <2B3EB4E1-C0C5-4765-81D1-11ECCDEA8C45@cis.upenn.edu>
 <532E3358.3030504@fuuzetsu.co.uk>
Message-ID: <5DFF74CB-12EA-4A33-AD07-5D928C93E6BC@cis.upenn.edu>


On Mar 22, 2014, at 9:05 PM, Mateusz Kowalczyk wrote:
>  Is there a reason why the Template Haskell version wasn't bumped
> after this change?

No -- I just didn't think of it. I won't have time in the next few days to do this (and validate, etc.), but I'll make this change soon.

Thanks,
Richard

From hvriedel at gmail.com  Sun Mar 23 09:37:31 2014
From: hvriedel at gmail.com (Herbert Valerio Riedel)
Date: Sun, 23 Mar 2014 10:37:31 +0100
Subject: [commit: packages/template-haskell] master: Make Pred a type
 synonym of Type (issue #7021) (57b662c)
In-Reply-To: <5DFF74CB-12EA-4A33-AD07-5D928C93E6BC@cis.upenn.edu> (Richard
 Eisenberg's message of "Sat, 22 Mar 2014 23:40:14 -0400")
References: <20140210013952.DA0432406B@ghc.haskell.org>
 <CAK-tuPZC2PmRsH352=rMaw6qqHArz=D=Xp-t4wjDKf0WswZ6Ow@mail.gmail.com>
 <532DF848.7020308@fuuzetsu.co.uk>
 <2B3EB4E1-C0C5-4765-81D1-11ECCDEA8C45@cis.upenn.edu>
 <532E3358.3030504@fuuzetsu.co.uk>
 <5DFF74CB-12EA-4A33-AD07-5D928C93E6BC@cis.upenn.edu>
Message-ID: <87eh1tb6hw.fsf@gmail.com>

On 2014-03-23 at 04:40:14 +0100, Richard Eisenberg wrote:
> On Mar 22, 2014, at 9:05 PM, Mateusz Kowalczyk wrote:
>>  Is there a reason why the Template Haskell version wasn't bumped
>> after this change?
>
> No -- I just didn't think of it. I won't have time in the next few
> days to do this (and validate, etc.), but I'll make this change soon.

Fyi, I went ahead and bumped to template-haskell to 2.10.0.0, fixed up
libraries/dph, and since ./validate still passed, I pushed the version
bump.

From ekmett at gmail.com  Sun Mar 23 10:15:39 2014
From: ekmett at gmail.com (Edward Kmett)
Date: Sun, 23 Mar 2014 06:15:39 -0400
Subject: [commit: packages/template-haskell] master: Make Pred a type
 synonym of Type (issue #7021) (57b662c)
In-Reply-To: <87eh1tb6hw.fsf@gmail.com>
References: <20140210013952.DA0432406B@ghc.haskell.org>
 <CAK-tuPZC2PmRsH352=rMaw6qqHArz=D=Xp-t4wjDKf0WswZ6Ow@mail.gmail.com>
 <532DF848.7020308@fuuzetsu.co.uk>
 <2B3EB4E1-C0C5-4765-81D1-11ECCDEA8C45@cis.upenn.edu>
 <532E3358.3030504@fuuzetsu.co.uk>
 <5DFF74CB-12EA-4A33-AD07-5D928C93E6BC@cis.upenn.edu>
 <87eh1tb6hw.fsf@gmail.com>
Message-ID: <CAJumaK-c6nepR7bS0vEbAsYdrKJiOH62hoq1sehCfSEWwoaX=A@mail.gmail.com>

Thanks. That'll let me make it clearer in my patches to work around the
this on my side that the source of the workarounds is the changes to the
template-haskell package.

-Edward


On Sun, Mar 23, 2014 at 5:37 AM, Herbert Valerio Riedel
<hvriedel at gmail.com>wrote:

> On 2014-03-23 at 04:40:14 +0100, Richard Eisenberg wrote:
> > On Mar 22, 2014, at 9:05 PM, Mateusz Kowalczyk wrote:
> >>  Is there a reason why the Template Haskell version wasn't bumped
> >> after this change?
> >
> > No -- I just didn't think of it. I won't have time in the next few
> > days to do this (and validate, etc.), but I'll make this change soon.
>
> Fyi, I went ahead and bumped to template-haskell to 2.10.0.0, fixed up
> libraries/dph, and since ./validate still passed, I pushed the version
> bump.
> _______________________________________________
> ghc-devs mailing list
> ghc-devs at haskell.org
> http://www.haskell.org/mailman/listinfo/ghc-devs
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/ghc-devs/attachments/20140323/af18eaff/attachment.html>

From petersen at fedoraproject.org  Sun Mar 23 10:44:24 2014
From: petersen at fedoraproject.org (Jens Petersen)
Date: Sun, 23 Mar 2014 19:44:24 +0900
Subject: ghc-7.8.1 RC2 ppc dyn linked executable segfaults
In-Reply-To: <17EA2E34-FB3E-4F75-A84F-2B9C17451D29@me.com>
References: <CAEDGBqKnddMLTX3ZqYpyx=UaZxNS+WH2w93M+hfuw+MYHgUh7A@mail.gmail.com>
 <CAEDGBqLiBTsaakZnCLUQVoHp5=dPL=16TpP4eydwyK0TJF+CYg@mail.gmail.com>
 <17EA2E34-FB3E-4F75-A84F-2B9C17451D29@me.com>
Message-ID: <CAEDGBqKSA=Pai1d=VoxsnJh6_wiauDYpO5LEarCjRtqU92Vzog@mail.gmail.com>

On 20 March 2014 20:27, Peter Trommler <ptrommler at me.com> wrote:

> I see the same issue on ppc: All dyn programs segfault.
> In addition: Dynamic does not seem to compile (assembler errors)
> with binutils 2.23.
>

Thanks for reproducing.

Fedora 21 devel has binutils-2.24.


> Speaking of ppc64: Do you see ticket #8849 too?


I see: I don't have access to ppc hardware currently
but I can try to reproduce later.

Does it show up in the testsuite results too?
I can generate those easily with another rebuild.

Thanks, Jens

 > I filed https://ghc.haskell.org/trac/ghc/ticket/8909 for this issue.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/ghc-devs/attachments/20140323/fdc341ad/attachment.html>

From hvriedel at gmail.com  Sun Mar 23 10:53:01 2014
From: hvriedel at gmail.com (Herbert Valerio Riedel)
Date: Sun, 23 Mar 2014 11:53:01 +0100
Subject: HEADS-UP: haddock.git to be turned into submodule soon
In-Reply-To: <87txatdzeb.fsf@gmail.com> (Herbert Valerio Riedel's message of
 "Thu, 20 Mar 2014 09:53:32 +0100")
References: <87pplj7oyr.fsf@gmail.com> <87txatdzeb.fsf@gmail.com>
Message-ID: <8761n5b302.fsf@gmail.com>

On 2014-03-20 at 09:53:32 +0100, Herbert Valerio Riedel wrote:

[...]

> Details will follow when the conversion of haddock.git is actually
> implemented.

The conversion has been implemented as of 

  http://git.haskell.org/ghc.git/commitdiff/34b072177b687c8fcc24f87293beae0752e82d32

I've started writing up a bit on

  https://ghc.haskell.org/trac/ghc/wiki/WorkingConventions/Git/Submodules

on how to cope with Git submodules (using mostly `git` commands for now;
once we have sorted out which `git` command sequences to use, we can
start thinking about a next-gen `sync-all` replacement)

Feel free to improve/extend the Wiki page!

Cheers,
  hvr

From ptrommler at me.com  Sun Mar 23 12:42:20 2014
From: ptrommler at me.com (Peter Trommler)
Date: Sun, 23 Mar 2014 13:42:20 +0100
Subject: ghc-7.8.1 RC2 ppc dyn linked executable segfaults
In-Reply-To: <CAEDGBqKSA=Pai1d=VoxsnJh6_wiauDYpO5LEarCjRtqU92Vzog@mail.gmail.com>
References: <CAEDGBqKnddMLTX3ZqYpyx=UaZxNS+WH2w93M+hfuw+MYHgUh7A@mail.gmail.com>
 <CAEDGBqLiBTsaakZnCLUQVoHp5=dPL=16TpP4eydwyK0TJF+CYg@mail.gmail.com>
 <17EA2E34-FB3E-4F75-A84F-2B9C17451D29@me.com>
 <CAEDGBqKSA=Pai1d=VoxsnJh6_wiauDYpO5LEarCjRtqU92Vzog@mail.gmail.com>
Message-ID: <432C0AE5-9498-40BD-A0EB-D638899FB2B4@me.com>


On 23.03.2014, at 11:44, Jens Petersen <petersen at fedoraproject.org> wrote:

>   
> Speaking of ppc64: Do you see ticket #8849 too?
> 
> I see: I don't have access to ppc hardware currently
Likewise, I get my results from the OBS service.
> but I can try to reproduce later.
> 
> Does it show up in the testsuite results too?
> I can generate those easily with another rebuild.
Yes, in fact I noticed the error in test arith005 and extracted the small test case
for #8849.

In #8819 I reported test failures in an unregisterised compiler produced on
my x86_64 machine using an unregisterised ghc. Almost all arith tests including arith005
fail and I suspect it might be a data layout issue. I wonder if you can reproduce
#8819 on ppc64. #8849 makes me think yes.

I?ll see if I can fix my ppc64 build on OBS and report back.

Peter

From berthold at Mathematik.Uni-Marburg.de  Sun Mar 23 16:51:57 2014
From: berthold at Mathematik.Uni-Marburg.de (Jost Berthold)
Date: Sun, 23 Mar 2014 17:51:57 +0100
Subject: [commit: ghc] ghc-7.8: change deriveConstants to use nm in a
 POSIX way (fixes #8781) (e7563ec)
In-Reply-To: <mailman.4289.1395560771.1937.ghc-commits@haskell.org>
References: <mailman.4289.1395560771.1937.ghc-commits@haskell.org>
Message-ID: <532F112D.9000102@mathematik.uni-marburg.de>

Hello,

With the patch to deriveConstants, a build on an older Windows (32bit 
Vista, MinGW32 installation, which used to work) now fails with error

	Can't find "STD_HDR_SIZE"

I ran the nm command manually on the generated o file 
(includes/dist-derivedconstants/header/tmp.o) and saw that the output 
follows pattern

_derivedConstantBlaBlah_Blah C 000001b

so it does not match the four-word pattern in the patch.

Is this a problem with my setup, or does it fail for other people on 
Windows as well?

Thanks,
Jost

On 03/23/2014 08:46 AM, ghc-commits-request at haskell.org wrote:
> Message: 6
> Date: Sun, 23 Mar 2014 02:01:50 +0000 (UTC)
> From: git at git.haskell.org
> To: ghc-commits at haskell.org
> Subject: [commit: ghc] ghc-7.8: change deriveConstants to use nm in a
> 	POSIX way (fixes #8781) (e7563ec)
> Message-ID: <20140323020150.1DCE82406B at ghc.haskell.org>
> Content-Type: text/plain; charset=utf-8
>
> Repository : ssh://git at git.haskell.org/ghc
>
> On branch  : ghc-7.8
> Link       : http://ghc.haskell.org/trac/ghc/changeset/e7563ec2e03740074903036bf129fc972b623c23/ghc
>
>> ---------------------------------------------------------------
>
> commit e7563ec2e03740074903036bf129fc972b623c23
> Author: Karel Gardas <karel.gardas at centrum.cz>
> Date:   Sat Mar 22 22:33:05 2014 +0100
>
>      change deriveConstants to use nm in a POSIX way (fixes #8781)
>
>      The patch provided by Christian Maeder <Christian.Maeder at dfki.de>
>
>      Signed-off-by: Karel Gardas <karel.gardas at centrum.cz>
>      Signed-off-by: Austin Seipp <austin at well-typed.com>
>      (cherry picked from commit 045b28033a33a48d31951240a8cb35f2b78345dc)
>
>
>> ---------------------------------------------------------------
>
> e7563ec2e03740074903036bf129fc972b623c23
>   utils/deriveConstants/DeriveConstants.hs |   30 ++++++++++--------------------
>   1 file changed, 10 insertions(+), 20 deletions(-)
>
> diff --git a/utils/deriveConstants/DeriveConstants.hs b/utils/deriveConstants/DeriveConstants.hs
> index 10df61c..54ee6a1 100644
> --- a/utils/deriveConstants/DeriveConstants.hs
> +++ b/utils/deriveConstants/DeriveConstants.hs
> @@ -638,7 +638,7 @@ getWanted verbose tmpdir gccProgram gccFlags nmProgram
>                oFile = tmpdir </> "tmp.o"
>            writeFile cFile cStuff
>            execute verbose gccProgram (gccFlags ++ ["-c", cFile, "-o", oFile])
> -         xs <- readProcess nmProgram [oFile] ""
> +         xs <- readProcess nmProgram ["-P", oFile] ""
>            let ls = lines xs
>                ms = map parseNmLine ls
>                m = Map.fromList $ catMaybes ms
> @@ -707,27 +707,17 @@ getWanted verbose tmpdir gccProgram gccFlags nmProgram
>             doWanted (ClosurePayloadMacro {}) = []
>             doWanted (FieldTypeGcptrMacro {}) = []
>
> -          -- parseNmLine parses nm output that looks like
> -          -- "0000000b C derivedConstantMAX_Vanilla_REG"
> +          -- parseNmLine parses "nm -P" output that looks like
> +          -- "_derivedConstantMAX_Vanilla_REG C b 0" Mac OS X
> +          -- "derivedConstantMAX_Vanilla_REG C 0000000b 0000000b" GNU
> +          -- "derivedConstantMAX_Vanilla_REG D        1        b" Solaris
>             -- and returns ("MAX_Vanilla_REG", 11)
> -          parseNmLine xs0 = case break (' ' ==) xs0 of
> -                            (x1, ' ' : xs1) ->
> -                                case break (' ' ==) xs1 of
> -                                (x2, ' ' : x3) ->
> -                                    case readHex x1 of
> -                                    [(size, "")] ->
> -                                        case x2 of
> -                                        "C" ->
> -                                            let x3' = case x3 of
> -                                                      '_' : rest -> rest
> -                                                      _          -> x3
> -                                            in case stripPrefix prefix x3' of
> -                                               Just name ->
> -                                                   Just (name, size)
> -                                               _ -> Nothing
> -                                        _ -> Nothing
> -                                    _ -> Nothing
> +          parseNmLine xs0 = case words xs0 of
> +                            [x0, x1, x2, x3] -> case stripPrefix prefix $ dropWhile (== '_') x0 of
> +                              Just name -> case readHex $ if x1 == "C" then x2 else x3 of
> +                                [(size, "")] -> Just (name, size)
>                                   _ -> Nothing
> +                              _ -> Nothing
>                               _ -> Nothing
>
>             -- If an Int value is larger than 2^28 or smaller



From karel.gardas at centrum.cz  Sun Mar 23 17:32:51 2014
From: karel.gardas at centrum.cz (Karel Gardas)
Date: Sun, 23 Mar 2014 18:32:51 +0100
Subject: [commit: ghc] ghc-7.8: change deriveConstants to use nm in a
 POSIX way (fixes #8781) (e7563ec)
In-Reply-To: <532F112D.9000102@mathematik.uni-marburg.de>
References: <mailman.4289.1395560771.1937.ghc-commits@haskell.org>
 <532F112D.9000102@mathematik.uni-marburg.de>
Message-ID: <532F1AC3.1030008@centrum.cz>


Jost,

this is not good indeed, could you be so kind and let us know your nm 
--version? I guess mingw is using GNU binutils so I'm curious what old 
nm it is when it fails to implement POSIX output...

Thanks!
Karel

On 03/23/14 05:51 PM, Jost Berthold wrote:
> Hello,
>
> With the patch to deriveConstants, a build on an older Windows (32bit
> Vista, MinGW32 installation, which used to work) now fails with error
>
> Can't find "STD_HDR_SIZE"
>
> I ran the nm command manually on the generated o file
> (includes/dist-derivedconstants/header/tmp.o) and saw that the output
> follows pattern
>
> _derivedConstantBlaBlah_Blah C 000001b
>
> so it does not match the four-word pattern in the patch.
>
> Is this a problem with my setup, or does it fail for other people on
> Windows as well?
>
> Thanks,
> Jost
>
> On 03/23/2014 08:46 AM, ghc-commits-request at haskell.org wrote:
>> Message: 6
>> Date: Sun, 23 Mar 2014 02:01:50 +0000 (UTC)
>> From: git at git.haskell.org
>> To: ghc-commits at haskell.org
>> Subject: [commit: ghc] ghc-7.8: change deriveConstants to use nm in a
>> POSIX way (fixes #8781) (e7563ec)
>> Message-ID: <20140323020150.1DCE82406B at ghc.haskell.org>
>> Content-Type: text/plain; charset=utf-8
>>
>> Repository : ssh://git at git.haskell.org/ghc
>>
>> On branch : ghc-7.8
>> Link :
>> http://ghc.haskell.org/trac/ghc/changeset/e7563ec2e03740074903036bf129fc972b623c23/ghc
>>
>>
>>> ---------------------------------------------------------------
>>
>> commit e7563ec2e03740074903036bf129fc972b623c23
>> Author: Karel Gardas <karel.gardas at centrum.cz>
>> Date: Sat Mar 22 22:33:05 2014 +0100
>>
>> change deriveConstants to use nm in a POSIX way (fixes #8781)
>>
>> The patch provided by Christian Maeder <Christian.Maeder at dfki.de>
>>
>> Signed-off-by: Karel Gardas <karel.gardas at centrum.cz>
>> Signed-off-by: Austin Seipp <austin at well-typed.com>
>> (cherry picked from commit 045b28033a33a48d31951240a8cb35f2b78345dc)
>>
>>
>>> ---------------------------------------------------------------
>>
>> e7563ec2e03740074903036bf129fc972b623c23
>> utils/deriveConstants/DeriveConstants.hs | 30
>> ++++++++++--------------------
>> 1 file changed, 10 insertions(+), 20 deletions(-)
>>
>> diff --git a/utils/deriveConstants/DeriveConstants.hs
>> b/utils/deriveConstants/DeriveConstants.hs
>> index 10df61c..54ee6a1 100644
>> --- a/utils/deriveConstants/DeriveConstants.hs
>> +++ b/utils/deriveConstants/DeriveConstants.hs
>> @@ -638,7 +638,7 @@ getWanted verbose tmpdir gccProgram gccFlags
>> nmProgram
>> oFile = tmpdir </> "tmp.o"
>> writeFile cFile cStuff
>> execute verbose gccProgram (gccFlags ++ ["-c", cFile, "-o", oFile])
>> - xs <- readProcess nmProgram [oFile] ""
>> + xs <- readProcess nmProgram ["-P", oFile] ""
>> let ls = lines xs
>> ms = map parseNmLine ls
>> m = Map.fromList $ catMaybes ms
>> @@ -707,27 +707,17 @@ getWanted verbose tmpdir gccProgram gccFlags
>> nmProgram
>> doWanted (ClosurePayloadMacro {}) = []
>> doWanted (FieldTypeGcptrMacro {}) = []
>>
>> - -- parseNmLine parses nm output that looks like
>> - -- "0000000b C derivedConstantMAX_Vanilla_REG"
>> + -- parseNmLine parses "nm -P" output that looks like
>> + -- "_derivedConstantMAX_Vanilla_REG C b 0" Mac OS X
>> + -- "derivedConstantMAX_Vanilla_REG C 0000000b 0000000b" GNU
>> + -- "derivedConstantMAX_Vanilla_REG D 1 b" Solaris
>> -- and returns ("MAX_Vanilla_REG", 11)
>> - parseNmLine xs0 = case break (' ' ==) xs0 of
>> - (x1, ' ' : xs1) ->
>> - case break (' ' ==) xs1 of
>> - (x2, ' ' : x3) ->
>> - case readHex x1 of
>> - [(size, "")] ->
>> - case x2 of
>> - "C" ->
>> - let x3' = case x3 of
>> - '_' : rest -> rest
>> - _ -> x3
>> - in case stripPrefix prefix x3' of
>> - Just name ->
>> - Just (name, size)
>> - _ -> Nothing
>> - _ -> Nothing
>> - _ -> Nothing
>> + parseNmLine xs0 = case words xs0 of
>> + [x0, x1, x2, x3] -> case stripPrefix prefix $ dropWhile (== '_') x0 of
>> + Just name -> case readHex $ if x1 == "C" then x2 else x3 of
>> + [(size, "")] -> Just (name, size)
>> _ -> Nothing
>> + _ -> Nothing
>> _ -> Nothing
>>
>> -- If an Int value is larger than 2^28 or smaller
>
>
> _______________________________________________
> ghc-devs mailing list
> ghc-devs at haskell.org
> http://www.haskell.org/mailman/listinfo/ghc-devs
>


From eir at cis.upenn.edu  Sun Mar 23 18:32:12 2014
From: eir at cis.upenn.edu (Richard Eisenberg)
Date: Sun, 23 Mar 2014 14:32:12 -0400
Subject: [commit: packages/template-haskell] master: Make Pred a type
 synonym of Type (issue #7021) (57b662c)
In-Reply-To: <87eh1tb6hw.fsf@gmail.com>
References: <20140210013952.DA0432406B@ghc.haskell.org>
 <CAK-tuPZC2PmRsH352=rMaw6qqHArz=D=Xp-t4wjDKf0WswZ6Ow@mail.gmail.com>
 <532DF848.7020308@fuuzetsu.co.uk>
 <2B3EB4E1-C0C5-4765-81D1-11ECCDEA8C45@cis.upenn.edu>
 <532E3358.3030504@fuuzetsu.co.uk>
 <5DFF74CB-12EA-4A33-AD07-5D928C93E6BC@cis.upenn.edu>
 <87eh1tb6hw.fsf@gmail.com>
Message-ID: <8DCBCF2C-EFCE-4A1F-863F-17F196B0342B@cis.upenn.edu>

Thanks, Herbert. I'll cross this off my to-do list.

Richard

On Mar 23, 2014, at 5:37 AM, Herbert Valerio Riedel <hvriedel at gmail.com> wrote:

> On 2014-03-23 at 04:40:14 +0100, Richard Eisenberg wrote:
>> On Mar 22, 2014, at 9:05 PM, Mateusz Kowalczyk wrote:
>>> Is there a reason why the Template Haskell version wasn't bumped
>>> after this change?
>> 
>> No -- I just didn't think of it. I won't have time in the next few
>> days to do this (and validate, etc.), but I'll make this change soon.
> 
> Fyi, I went ahead and bumped to template-haskell to 2.10.0.0, fixed up
> libraries/dph, and since ./validate still passed, I pushed the version
> bump.


From simonpj at microsoft.com  Sun Mar 23 18:53:55 2014
From: simonpj at microsoft.com (Simon Peyton Jones)
Date: Sun, 23 Mar 2014 18:53:55 +0000
Subject: [commit: ghc] master: Convert haddock into a proper submodule
 (re #8545) (34b0721)
In-Reply-To: <20140323094934.5E7D52406B@ghc.haskell.org>
References: <20140323094934.5E7D52406B@ghc.haskell.org>
Message-ID: <59543203684B2244980D7E4057D5FBC1488B8AF9@DB3EX14MBXC308.europe.corp.microsoft.com>

Do us na?ve users need to change our workflow with these submodule changes?

Thanks

Simon

| -----Original Message-----
| From: ghc-commits [mailto:ghc-commits-bounces at haskell.org] On Behalf Of
| git at git.haskell.org
| Sent: 23 March 2014 09:50
| To: ghc-commits at haskell.org
| Subject: [commit: ghc] master: Convert haddock into a proper submodule
| (re #8545) (34b0721)
| 
| Repository : ssh://git at git.haskell.org/ghc
| 
| On branch  : master
| Link       :
| http://ghc.haskell.org/trac/ghc/changeset/34b072177b687c8fcc24f87293beae0
| 752e82d32/ghc
| 
| >---------------------------------------------------------------
| 
| commit 34b072177b687c8fcc24f87293beae0752e82d32
| Author: Herbert Valerio Riedel <hvr at gnu.org>
| Date:   Thu Mar 20 09:20:06 2014 +0100
| 
|     Convert haddock into a proper submodule (re #8545)
| 
|     This should help contribute content to
| 
| 
| https://ghc.haskell.org/trac/ghc/wiki/WorkingConventions/Git/Submodules
| 
|     Signed-off-by: Herbert Valerio Riedel <hvr at gnu.org>
| 
| 
| >---------------------------------------------------------------
| 
| 34b072177b687c8fcc24f87293beae0752e82d32
|  .gitignore    |    1 -
|  .gitmodules   |    3 +++
|  packages      |    2 +-
|  utils/haddock |    1 +
|  4 files changed, 5 insertions(+), 2 deletions(-)
| 
| diff --git a/.gitignore b/.gitignore
| index 93feea3..e60382b 100644
| --- a/.gitignore
| +++ b/.gitignore
| @@ -71,7 +71,6 @@ _darcs/
|  /libraries/unix/
|  /libraries/utf8-string/
|  /nofib/
| -/utils/haddock/
|  /utils/hsc2hs/
| 
|  # ----------------------------------------------------------------------
| -------
| diff --git a/.gitmodules b/.gitmodules
| index d83bfd0..99893a4 100644
| --- a/.gitmodules
| +++ b/.gitmodules
| @@ -54,3 +54,6 @@
|  	path = libraries/random
|  	url = ../packages/random.git
|  	ignore = untracked
| +[submodule "utils/haddock"]
| +	path = utils/haddock
| +	url = ../haddock.git
| diff --git a/packages b/packages
| index 616dfc1..2683c99 100644
| --- a/packages
| +++ b/packages
| @@ -47,7 +47,7 @@
|  ghc-tarballs                 windows     ghc-tarballs.git
| -
|  libffi-tarballs              -           libffi-tarballs.git
| -
|  utils/hsc2hs                 -           hsc2hs.git
| -
| -utils/haddock                -           haddock.git
| -
| +utils/haddock                -           -
| -
|  libraries/array              -           packages/array.git
| -
|  libraries/base               -           packages/base.git
| -
|  libraries/binary             -           -
| https://github.com/kolmodin/binary.git
| diff --git a/utils/haddock b/utils/haddock
| new file mode 160000
| index 0000000..725faca
| --- /dev/null
| +++ b/utils/haddock
| @@ -0,0 +1 @@
| +Subproject commit 725faca5ee670f80359321adc112408880e9c073
| 
| _______________________________________________
| ghc-commits mailing list
| ghc-commits at haskell.org
| http://www.haskell.org/mailman/listinfo/ghc-commits

From berthold at Mathematik.Uni-Marburg.de  Sun Mar 23 20:17:18 2014
From: berthold at Mathematik.Uni-Marburg.de (Jost Berthold)
Date: Sun, 23 Mar 2014 21:17:18 +0100
Subject: [commit: ghc] ghc-7.8: change deriveConstants to use nm in a
 POSIX way (fixes #8781) (e7563ec)
In-Reply-To: <532F1AC3.1030008@centrum.cz>
References: <mailman.4289.1395560771.1937.ghc-commits@haskell.org>
 <532F112D.9000102@mathematik.uni-marburg.de> <532F1AC3.1030008@centrum.cz>
Message-ID: <532F414E.5070805@mathematik.uni-marburg.de>

On 03/23/2014 06:32 PM, Karel Gardas wrote:
>
> Jost,
>
> this is not good indeed, could you be so kind and let us know your nm
> --version? I guess mingw is using GNU binutils so I'm curious what old
> nm it is when it fails to implement POSIX output...

I can see that the failing nm is one that came with ghc-7.6.3 (I 
installed a binary tarball from http://www.haskell.org/ghc/dist/7.6.3/) 
which is copied into the build tree.

jost at ibm-jost ~/ghc
$ C:/MinGW/msys/1.0/home/jost/ghc/inplace/mingw/bin/nm.exe --version
GNU nm (GNU Binutils) 2.20.51.20100613

The nm version that came with MinGW itself is this:

jost at ibm-jost ~/ghc
$ which nm; nm --version
/c/MinGW/bin/nm.exe
GNU nm (GNU Binutils) 2.23.2

But it produces the same output

jost at ibm-jost ~/ghc
$ nm -P includes/dist-derivedconstants/header/tmp.o | head
.bss b 00000000
.data d 00000000
.drectve i 00000000
.rdata$zzz r 00000000
.text t 00000000
_derivedConstantAP_STACK_SPLIM C 00000401
_derivedConstantBITMAP_BITS_SHIFT C 00000006
_derivedConstantBLOCK_SIZE C 00001001
_derivedConstantBLOCKS_PER_MBLOCK C 000000ff
_derivedConstantCINT_SIZE C 00000005


This installation is not very old (last December, mostly following
   https://ghc.haskell.org/trac/ghc/wiki/Building/Preparation/Windows
but taking some shortcuts ). The MSYS2 solution described on a sub-page 
did not work on the 32-bit Vista (pacman did not work)

jost at ibm-jost ~/ghc
$ uname -a
MINGW32_NT-6.0 IBM-JOST 1.0.18(0.48/3/2) 2012-11-21 22:34 i686 Msys

I am not sure whether anything would actually break if 
deriveConstants.hs accepted and parsed this nm output as a fallback if 
it sees it. Will give it a try.

/ Jost



> Thanks!
> Karel
>
> On 03/23/14 05:51 PM, Jost Berthold wrote:
>> Hello,
>>
>> With the patch to deriveConstants, a build on an older Windows (32bit
>> Vista, MinGW32 installation, which used to work) now fails with error
>>
>> Can't find "STD_HDR_SIZE"
>>
>> I ran the nm command manually on the generated o file
>> (includes/dist-derivedconstants/header/tmp.o) and saw that the output
>> follows pattern
>>
>> _derivedConstantBlaBlah_Blah C 000001b
>>
>> so it does not match the four-word pattern in the patch.
>>
>> Is this a problem with my setup, or does it fail for other people on
>> Windows as well?
>>
>> Thanks,
>> Jost
>>
>> On 03/23/2014 08:46 AM, ghc-commits-request at haskell.org wrote:
>>> Message: 6
>>> Date: Sun, 23 Mar 2014 02:01:50 +0000 (UTC)
>>> From: git at git.haskell.org
>>> To: ghc-commits at haskell.org
>>> Subject: [commit: ghc] ghc-7.8: change deriveConstants to use nm in a
>>> POSIX way (fixes #8781) (e7563ec)
>>> Message-ID: <20140323020150.1DCE82406B at ghc.haskell.org>
>>> Content-Type: text/plain; charset=utf-8
>>>
>>> Repository : ssh://git at git.haskell.org/ghc
>>>
>>> On branch : ghc-7.8
>>> Link :
>>> http://ghc.haskell.org/trac/ghc/changeset/e7563ec2e03740074903036bf129fc972b623c23/ghc
>>>
>>>
>>>
>>>> ---------------------------------------------------------------
>>>
>>> commit e7563ec2e03740074903036bf129fc972b623c23
>>> Author: Karel Gardas <karel.gardas at centrum.cz>
>>> Date: Sat Mar 22 22:33:05 2014 +0100
>>>
>>> change deriveConstants to use nm in a POSIX way (fixes #8781)
>>>
>>> The patch provided by Christian Maeder <Christian.Maeder at dfki.de>
>>>
>>> Signed-off-by: Karel Gardas <karel.gardas at centrum.cz>
>>> Signed-off-by: Austin Seipp <austin at well-typed.com>
>>> (cherry picked from commit 045b28033a33a48d31951240a8cb35f2b78345dc)
>>>
>>>
>>>> ---------------------------------------------------------------
>>>
>>> e7563ec2e03740074903036bf129fc972b623c23
>>> utils/deriveConstants/DeriveConstants.hs | 30
>>> ++++++++++--------------------
>>> 1 file changed, 10 insertions(+), 20 deletions(-)
>>>
>>> diff --git a/utils/deriveConstants/DeriveConstants.hs
>>> b/utils/deriveConstants/DeriveConstants.hs
>>> index 10df61c..54ee6a1 100644
>>> --- a/utils/deriveConstants/DeriveConstants.hs
>>> +++ b/utils/deriveConstants/DeriveConstants.hs
>>> @@ -638,7 +638,7 @@ getWanted verbose tmpdir gccProgram gccFlags
>>> nmProgram
>>> oFile = tmpdir </> "tmp.o"
>>> writeFile cFile cStuff
>>> execute verbose gccProgram (gccFlags ++ ["-c", cFile, "-o", oFile])
>>> - xs <- readProcess nmProgram [oFile] ""
>>> + xs <- readProcess nmProgram ["-P", oFile] ""
>>> let ls = lines xs
>>> ms = map parseNmLine ls
>>> m = Map.fromList $ catMaybes ms
>>> @@ -707,27 +707,17 @@ getWanted verbose tmpdir gccProgram gccFlags
>>> nmProgram
>>> doWanted (ClosurePayloadMacro {}) = []
>>> doWanted (FieldTypeGcptrMacro {}) = []
>>>
>>> - -- parseNmLine parses nm output that looks like
>>> - -- "0000000b C derivedConstantMAX_Vanilla_REG"
>>> + -- parseNmLine parses "nm -P" output that looks like
>>> + -- "_derivedConstantMAX_Vanilla_REG C b 0" Mac OS X
>>> + -- "derivedConstantMAX_Vanilla_REG C 0000000b 0000000b" GNU
>>> + -- "derivedConstantMAX_Vanilla_REG D 1 b" Solaris
>>> -- and returns ("MAX_Vanilla_REG", 11)
>>> - parseNmLine xs0 = case break (' ' ==) xs0 of
>>> - (x1, ' ' : xs1) ->
>>> - case break (' ' ==) xs1 of
>>> - (x2, ' ' : x3) ->
>>> - case readHex x1 of
>>> - [(size, "")] ->
>>> - case x2 of
>>> - "C" ->
>>> - let x3' = case x3 of
>>> - '_' : rest -> rest
>>> - _ -> x3
>>> - in case stripPrefix prefix x3' of
>>> - Just name ->
>>> - Just (name, size)
>>> - _ -> Nothing
>>> - _ -> Nothing
>>> - _ -> Nothing
>>> + parseNmLine xs0 = case words xs0 of
>>> + [x0, x1, x2, x3] -> case stripPrefix prefix $ dropWhile (== '_') x0 of
>>> + Just name -> case readHex $ if x1 == "C" then x2 else x3 of
>>> + [(size, "")] -> Just (name, size)
>>> _ -> Nothing
>>> + _ -> Nothing
>>> _ -> Nothing
>>>
>>> -- If an Int value is larger than 2^28 or smaller
>>
>>
>> _______________________________________________
>> ghc-devs mailing list
>> ghc-devs at haskell.org
>> http://www.haskell.org/mailman/listinfo/ghc-devs
>>


From carter.schonwald at gmail.com  Sun Mar 23 20:33:54 2014
From: carter.schonwald at gmail.com (Carter Schonwald)
Date: Sun, 23 Mar 2014 16:33:54 -0400
Subject: help understanding the validate_build_xhtml failure of ./validate for
 my CPP patch
Message-ID: <CAHYVw0xX_pmNi_w=41tpho1W8x6wHpJOP6U8ymBeYH4W-+ZfUw@mail.gmail.com>

Hey all, I'm trying to get my CPP_Setttings patch to validate,
and i'm trying to understand why my validate is failing. At this point im
stumped and I really could  use some help!

I'd appreciate some assistance digging into this,
the ticket in question is
https://ghc.haskell.org/trac/ghc/ticket/8683#comment:50

my current set of patches is
https://github.com/cartazio/ghc/compare/ghc:ghc-7.8...rb_cpp_settings(rebased
on top of current 7.8 branch)

and the confusing  error in question is


== Start post-install package check
Timestamp 2014-03-23 17:32:46 UTC for
/Users/carter/Desktop/repoScratcher/ghc/bindisttest/install
dir/lib/ghc-7.8.0.20140323/package.conf.d/package.cache
Timestamp 2014-03-23 17:32:46 UTC for
/Users/carter/Desktop/repoScratcher/ghc/bindisttest/install
dir/lib/ghc-7.8.0.20140323/package.conf.d (same as cache)
using cache: /Users/carter/Desktop/repoScratcher/ghc/bindisttest/install
  dir/lib/ghc-7.8.0.20140323/package.conf.d/package.cache
== End post-install package check
===--- building phase 0
/Applications/Xcode.app/Contents/Developer/usr/bin/make -r
--no-print-directory -f ghc.mk phase=0 phase_0_builds
make[1]: Nothing to be done for `phase_0_builds'.
===--- building phase 1
/Applications/Xcode.app/Contents/Developer/usr/bin/make -r
--no-print-directory -f ghc.mk phase=1 phase_1_builds
make[1]: Nothing to be done for `phase_1_builds'.
===--- building final phase
/Applications/Xcode.app/Contents/Developer/usr/bin/make -r
--no-print-directory -f ghc.mk phase=final validate_build_xhtml
cd libraries/xhtml &&
"/Users/carter/Desktop/repoScratcher/ghc/bindisttest/install
dir/bin/ghc" --make Setup
[1 of 1] Compiling Main             ( Setup.hs, Setup.o )
Linking Setup ...
cd libraries/xhtml && ./Setup configure
--with-ghc="/Users/carter/Desktop/repoScratcher/ghc/bindisttest/install
  dir/bin/ghc" --with-haddock="/Users/carter/Desktop/repoScratcher/ghc/bindisttest/install
  dir/bin/haddock" --enable-shared --disable-library-vanilla
--disable-library-prof --global --builddir=dist-bindist
--prefix="/Users/carter/Desktop/repoScratcher/ghc/bindisttest/install
 dir"
Configuring xhtml-3000.2.1...
cd libraries/xhtml && ./Setup build   --builddir=dist-bindist
Building xhtml-3000.2.1...
Preprocessing library xhtml-3000.2.1...
ghc: could not execute:
make[1]: *** [validate_build_xhtml] Error 1
make: *** [validate_build_xhtml] Error 2


If someone could help me get to the bottom of this, I'd really really
appreciate it.

-Carter
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/ghc-devs/attachments/20140323/830765be/attachment.html>

From karel.gardas at centrum.cz  Sun Mar 23 20:43:56 2014
From: karel.gardas at centrum.cz (Karel Gardas)
Date: Sun, 23 Mar 2014 21:43:56 +0100
Subject: When iselExpr64 (CmmLit (CmmInt i _)) is used?
In-Reply-To: <CAEs96n3cyEJU99aTodcMxKsvT2eMO559Vd1hntdonmmSB3sL5g@mail.gmail.com>
References: <53122302.6000603@centrum.cz>
 <CAEs96n3cyEJU99aTodcMxKsvT2eMO559Vd1hntdonmmSB3sL5g@mail.gmail.com>
Message-ID: <532F478C.90704@centrum.cz>


Hi Austin,

thanks for your suggestion. Unfortunately this completely go over my 
head now. :-) I'm not able to write single line of C-- test yet. Anyway, 
I've tackled this from different side: added debugging message to the 
function and then see where it's emitted while building GHC, it looks 
like GHC.Word.hs from base library is my friend here. I've also have a 
look into generated asm and it looks reasonable so I think my 
implementation of iselExpr64 is correct.

Thanks!
Karel

On 03/ 1/14 09:26 PM, Austin Seipp wrote:
> Hi Karel,
>
> Although I haven't looked extremely closely, may I suggest perhaps
> writing your test case in C-- instead of Haskell? It looks like you
> can trigger this simply with a CmmAssign or CmmStore node with a 64bit
> type, which will call assign(Reg|Mem)_I64Code, in turn calling
> iselExpr64 - see nativeGen/SPARC/CodeGen.hs:stmtToInstrs (line 121).
> If you trace through from CmmParse.y to find emitAssign in
> StgCmmMonad, it'll create an assignment node for you.
>
> Do that with -S and check out the assembly files (-ddump-asm should
> also do the trick).
>
> This should make it easy to trigger and examine. Then you can link it
> into a Haskell program as a foreign primop and test it extensively
> with a working executable.
>
>
>
> On Sat, Mar 1, 2014 at 12:12 PM, Karel Gardas<karel.gardas at centrum.cz>  wrote:
>>
>> Hello,
>>
>> I'm trying to resurrect SPARC NCG. I've switched it on and basically
>> provided functions on which NCG has panic during the build, basically just 2
>> were missing so far (cut from git diff):
>>
>> +genCCall (PrimTarget MO_Touch) _ _
>> + = return $ nilOL
>> +
>>
>>
>> +iselExpr64 (CmmLit (CmmInt i _)) = do
>> +  (rlo, rhi)<- getNewRegPairNat II32
>> +  let
>> +      half0 = fromIntegral (fromIntegral i :: Word32)
>> +      half1 = fromIntegral (fromIntegral (i `shiftR` 32) :: Word32)
>> +      code = toOL [
>> +              SETHI (HI $ ImmInt half0) rlo,
>> +              OR False rlo (RIImm (LO $ ImmInt half0)) rlo,
>> +              SETHI (HI $ ImmInt half1) rhi,
>> +              OR False rhi (RIImm (LO $ ImmInt half1)) rhi
>> +             ]
>> +  return (ChildCode64 code rlo)
>>
>>
>> Now, my ghc-stage2 badly fails and testsuite run with stage=1 reveals 1390
>> unexpected failures. Perhaps this is unrelated, but still I'd like to test
>> that my iselExpr64 implementation above is correct. Is there any simple
>> haskell code which makes this function in NCG run? I'm trying this:
>>
>> import GHC.Prim
>> import GHC.Exts
>>
>> main = do
>>          let x = 18446744073709551615#
>>          --- 2^64-1 = 18446744073709551615
>>          putStrLn (show $ I# x)
>>          return()
>>
>>
>> I've had a hope that unboxed long int constant is what causes iselExpr64
>> being called, but generated assembly looks suspicious -- like it's not
>> called so my idea was wrong here probably. Do you have any idea how to test
>> this function and see its generated assembly?
>>
>> BTW: I hope I got the function semantics correct as a loading of 64bit
>> constant/integer into a pair of 32bits registers...
>>
>> Thanks a lot!
>> Karel
>>
>> _______________________________________________
>> ghc-devs mailing list
>> ghc-devs at haskell.org
>> http://www.haskell.org/mailman/listinfo/ghc-devs
>>
>
>
>


From hvriedel at gmail.com  Sun Mar 23 21:03:04 2014
From: hvriedel at gmail.com (Herbert Valerio Riedel)
Date: Sun, 23 Mar 2014 22:03:04 +0100
Subject: [commit: ghc] master: Convert haddock into a proper submodule (re
 #8545) (34b0721)
In-Reply-To: <59543203684B2244980D7E4057D5FBC1488B8AF9@DB3EX14MBXC308.europe.corp.microsoft.com>
 (Simon Peyton Jones's message of "Sun, 23 Mar 2014 18:53:55 +0000")
References: <20140323094934.5E7D52406B@ghc.haskell.org>
 <59543203684B2244980D7E4057D5FBC1488B8AF9@DB3EX14MBXC308.europe.corp.microsoft.com>
Message-ID: <871txsbpbr.fsf@gmail.com>

On 2014-03-23 at 19:53:55 +0100, Simon Peyton Jones wrote:
> Do us na?ve users need to change our workflow with these submodule
> changes?

Probably yes... to some extent at least; that's why only haddock.git has
been converted for now[1]: to find out empirically what's involved
before continuing with the submodule-conversion.

I've tried to describe one possible workflow (for if you need to publish
a modification to haddock.git) at

  https://ghc.haskell.org/trac/ghc/wiki/WorkingConventions/Git/Submodules#MakingchangestoGHCsubmodules

I hope it makes a bit of sense :-)

IMO, it's quite useful to familiarize oneself with the 'git submodule'
family of commands, and especially 'git submodule' and 'git submodule
summary', as those two introspection commands allow one to get a better
picture in which state the currently cloned GHC working tree's
submodules are.

 [1]: OTOH, haddock.git is not the first/only proper Git submodule we
      have so far; so, in some way this isn't much of a change...

From ggreif at gmail.com  Sun Mar 23 22:30:34 2014
From: ggreif at gmail.com (Gabor Greif)
Date: Sun, 23 Mar 2014 23:30:34 +0100
Subject: [commit: ghc] ghc-7.8: add --with-ar and --with-ranlib configure
 parameters (05e160e)
In-Reply-To: <532F4BF2.2040008@centrum.cz>
References: <20140323020152.AD5A32406B@ghc.haskell.org>
 <CAK-hX0n5jhdycirTsF8e+BebFBLjKhQ_OXN_2dd2-KKxeiAj8g@mail.gmail.com>
 <532F4BF2.2040008@centrum.cz>
Message-ID: <CAK-hX0nZf2=fzpok6_5=QOLTJDDDTHdwx3-xFoff=WMbytz4Ow@mail.gmail.com>

Committed as 61654e5

Cheers,

    Gabor

On 3/23/14, Karel Gardas <karel.gardas at centrum.cz> wrote:
>
> Hi Gabor,
>
> indeed! I can just follow my intention to follow general logic of:
>
> --with-<cmd> -> @<cmd>Cmd@
>
> but you are right RANLIB logic is a little bit more comlex in aclocal.m4
> so it uses different variables (REAL_RANLIB_CMD/RANLIB_CMD) than "usual"
> RanlibCmd.
>
> So if you care about one useless AC_SUBST(RanlibCmd), please send the
> patch or if you do have commit access just fix that. As I said,
> intention was to follow usual logic although in this case
> non-functional....
>
> Thanks,
> Karel
>
> On 03/23/14 09:35 PM, Gabor Greif wrote:
>> Hi Karel,
>>
>> I am missing a use of @RanlibCmd@, is this intentional?
>>
>> Cheers,
>>
>>      Gabor
>>
>> On 3/23/14, git at git.haskell.org<git at git.haskell.org>  wrote:
>>> Repository : ssh://git at git.haskell.org/ghc
>>>
>>> On branch  : ghc-7.8
>>> Link       :
>>> http://ghc.haskell.org/trac/ghc/changeset/05e160e36527f6f36f997d7aa56f0cbe4cbb50a3/ghc
>>>
>>>> ---------------------------------------------------------------
>>>
>>> commit 05e160e36527f6f36f997d7aa56f0cbe4cbb50a3
>>> Author: Karel Gardas<karel.gardas at centrum.cz>
>>> Date:   Sun Feb 9 21:58:05 2014 +0100
>>>
>>>      add --with-ar and --with-ranlib configure parameters
>>>
>>>      Both --with-ar and --with-ranlib are usable on non-GNU/Linux
>>> systems
>>>      where GNU tools are usually installed (or possible to install), but
>>>      not into standard location nor with standard name. Tested on
>>> Solaris
>>> 10.
>>>
>>>      Signed-off-by: Austin Seipp<austin at well-typed.com>
>>>      (cherry picked from commit
>>> ac24bf45258af701cdd67423d6107357f27bbedf)
>>>
>>>
>>>> ---------------------------------------------------------------
>>>
>>> 05e160e36527f6f36f997d7aa56f0cbe4cbb50a3
>>>   configure.ac    |   15 +++++++++++++++
>>>   mk/config.mk.in |    1 +
>>>   2 files changed, 16 insertions(+)
>>>
>>> diff --git a/configure.ac b/configure.ac
>>> index 1c58da0..d32fd20 100644
>>> --- a/configure.ac
>>> +++ b/configure.ac
>>> @@ -486,6 +486,21 @@ FP_ARG_WITH_PATH_GNU_PROG([NM], [nm], [nm])
>>>   NmCmd="$NM"
>>>   AC_SUBST([NmCmd])
>>>
>>> +dnl ** Which ar to use?
>>> +dnl --------------------------------------------------------------
>>> +FP_ARG_WITH_PATH_GNU_PROG([AR], [ar], [ar])
>>> +ArCmd="$AR"
>>> +fp_prog_ar="$AR"
>>> +AC_SUBST([ArCmd])
>>> +
>>> +dnl ** Which ranlib to use?
>>> +dnl --------------------------------------------------------------
>>> +FP_ARG_WITH_PATH_GNU_PROG([RANLIB], [ranlib], [ranlib])
>>> +RanlibCmd="$RANLIB"
>>> +RANLIB="$RanlibCmd"
>>> +AC_SUBST([RanlibCmd])
>>> +
>>> +
>>>   # Note: we may not have objdump on OS X, and we only need it on
>>> Windows
>>> (for DLL checks)
>>>   case $HostOS_CPP in
>>>   cygwin32|mingw32)
>>> diff --git a/mk/config.mk.in b/mk/config.mk.in
>>> index fef1fb8..7cc7aec 100644
>>> --- a/mk/config.mk.in
>>> +++ b/mk/config.mk.in
>>> @@ -661,6 +661,7 @@ DTRACE			= @DtraceCmd@
>>>
>>>   LD = @LdCmd@
>>>   NM = @NmCmd@
>>> +AR = @ArCmd@
>>>   OBJDUMP = @ObjdumpCmd@
>>>
>>>   LLC = @LlcCmd@
>>>
>>> _______________________________________________
>>> ghc-commits mailing list
>>> ghc-commits at haskell.org
>>> http://www.haskell.org/mailman/listinfo/ghc-commits
>>>
>>
>
>

From kyrab at mail.ru  Mon Mar 24 06:49:50 2014
From: kyrab at mail.ru (kyra)
Date: Mon, 24 Mar 2014 10:49:50 +0400
Subject: [commit: ghc] ghc-7.8: change deriveConstants to use nm in a
 POSIX way (fixes #8781) (e7563ec)
In-Reply-To: <532F112D.9000102@mathematik.uni-marburg.de>
References: <mailman.4289.1395560771.1937.ghc-commits@haskell.org>
 <532F112D.9000102@mathematik.uni-marburg.de>
Message-ID: <532FD58E.3090908@mail.ru>

On 3/23/2014 20:51, Jost Berthold wrote:
> Hello,
>
> With the patch to deriveConstants, a build on an older Windows (32bit 
> Vista, MinGW32 installation, which used to work) now fails with error
>
>     Can't find "STD_HDR_SIZE"
Same here: Windows 64-bit, MSYS2, nm being called is from binutils 2.24.

Kyra

From karel.gardas at centrum.cz  Mon Mar 24 07:39:49 2014
From: karel.gardas at centrum.cz (Karel Gardas)
Date: Mon, 24 Mar 2014 08:39:49 +0100
Subject: [commit: ghc] ghc-7.8: change deriveConstants to use nm in a
 POSIX way (fixes #8781) (e7563ec)
In-Reply-To: <532FD58E.3090908@mail.ru>
References: <mailman.4289.1395560771.1937.ghc-commits@haskell.org>
 <532F112D.9000102@mathematik.uni-marburg.de> <532FD58E.3090908@mail.ru>
Message-ID: <532FE145.3050800@centrum.cz>


Guys,

could you be so kind and test attached patch?

Thanks!
Karel

On 03/24/14 07:49 AM, kyra wrote:
> On 3/23/2014 20:51, Jost Berthold wrote:
>> Hello,
>>
>> With the patch to deriveConstants, a build on an older Windows (32bit
>> Vista, MinGW32 installation, which used to work) now fails with error
>>
>> Can't find "STD_HDR_SIZE"
> Same here: Windows 64-bit, MSYS2, nm being called is from binutils 2.24.
>
> Kyra
> _______________________________________________
> ghc-devs mailing list
> ghc-devs at haskell.org
> http://www.haskell.org/mailman/listinfo/ghc-devs
>

-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: deriveConstants_fix_win_nm.diff
URL: <http://www.haskell.org/pipermail/ghc-devs/attachments/20140324/734e83ab/attachment.ksh>

From simonpj at microsoft.com  Mon Mar 24 08:37:32 2014
From: simonpj at microsoft.com (Simon Peyton Jones)
Date: Mon, 24 Mar 2014 08:37:32 +0000
Subject: [commit: ghc] master: Convert haddock into a proper submodule
 (re #8545) (34b0721)
In-Reply-To: <871txsbpbr.fsf@gmail.com>
References: <20140323094934.5E7D52406B@ghc.haskell.org>
 <59543203684B2244980D7E4057D5FBC1488B8AF9@DB3EX14MBXC308.europe.corp.microsoft.com>
 <871txsbpbr.fsf@gmail.com>
Message-ID: <59543203684B2244980D7E4057D5FBC1488B92DF@DB3EX14MBXC308.europe.corp.microsoft.com>

OK.  Some questions.



?         Where is a good place to get a conceptual understanding of submodules?



Concerning https://ghc.haskell.org/trac/ghc/wiki/WorkingConventions/Git/Submodules



?         Under "Updating an existing source tree clone" you say we have to do "git submodule update --init".  What happens if we forget?  Couldn't sync-all do that?  (Indeed it now emits a message to that effect



bash$ ./sync-all pull --rebase

...

From http://git.haskell.org/packages/dph

   aeef7aa..2984641  master     -> origin/master

   962c999..556e09c  ghc-7.8    -> origin/ghc-7.8

First, rewinding head to replay your work on top of it...

Fast-forwarded master to 2984641ae0c4739b168ee1fb956fd54f741f30e7.

== running git pull --rebase

remote: Counting objects: 581, done.

remote: Compressing objects: 100% (276/276), done.

remote: Total 420 (delta 327), reused 189 (delta 142)

Receiving objects: 100% (420/420), 74.21 KiB, done.

Resolving deltas: 100% (327/327), completed with 108 local objects.

From http://git.haskell.org/ghc

   df409de..15b1eb7  master     -> origin/master

   abb86ad..a617888  ghc-7.8    -> origin/ghc-7.8

* [new branch]      wip/T8545-ghc-7.8 -> origin/wip/T8545-ghc-7.8

* [new branch]      wip/recurs-compat -> origin/wip/recurs-compat

First, rewinding head to replay your work on top of it...

Applying: Add missing kind-check for tcEqType on forall-types

Applying: Don't export isTcReflCo_maybe (unused)

Applying: Comments only

Applying: For equalities with incompatible kinds, new IrredCan goes in the inert set, not work list

Applying: Debug tracing only

Applying: Flattener preserves synonyms, rewriteEvidence can drop buggy "optimisation"

Applying: Implicit parameters should not be allowed in class and instance declarations

Applying: Comments only

== running git submodule update

== Checking for old haddock repo

== Checking for old binary repo



?         Under ?Overriding pushurl?, same question. Couldn?t that long ?git submodule foreach? command be done by sync-all?



?         Under ?Making changes?, this looks hard to me.  Is ?base? a submodule?  Does that mean we have to remember to do some incantations before we modify base?  What if you forget and make the modifications first?  Again, could some of this be automated, at least for the common workflow of pull/push?



Thanks for working on this



Simon



?

| -----Original Message-----

| From: Herbert Valerio Riedel [mailto:hvriedel at gmail.com]

| Sent: 23 March 2014 21:03

| To: Simon Peyton Jones

| Cc: ghc-devs at haskell.org

| Subject: Re: [commit: ghc] master: Convert haddock into a proper

| submodule (re #8545) (34b0721)

|

| On 2014-03-23 at 19:53:55 +0100, Simon Peyton Jones wrote:

| > Do us na?ve users need to change our workflow with these submodule

| > changes?

|

| Probably yes... to some extent at least; that's why only haddock.git has

| been converted for now[1]: to find out empirically what's involved

| before continuing with the submodule-conversion.

|

| I've tried to describe one possible workflow (for if you need to publish

| a modification to haddock.git) at

|

|

| https://ghc.haskell.org/trac/ghc/wiki/WorkingConventions/Git/Submodules#<https://ghc.haskell.org/trac/ghc/wiki/WorkingConventions/Git/Submodules#MakingchangestoGHCsubmodules>

| MakingchangestoGHCsubmodules<https://ghc.haskell.org/trac/ghc/wiki/WorkingConventions/Git/Submodules#MakingchangestoGHCsubmodules>

|

| I hope it makes a bit of sense :-)

|

| IMO, it's quite useful to familiarize oneself with the 'git submodule'

| family of commands, and especially 'git submodule' and 'git submodule

| summary', as those two introspection commands allow one to get a better

| picture in which state the currently cloned GHC working tree's

| submodules are.

|

|  [1]: OTOH, haddock.git is not the first/only proper Git submodule we

|       have so far; so, in some way this isn't much of a change...
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/ghc-devs/attachments/20140324/8f988f51/attachment-0001.html>

From berthold at Mathematik.Uni-Marburg.de  Mon Mar 24 08:54:07 2014
From: berthold at Mathematik.Uni-Marburg.de (Jost Berthold)
Date: Mon, 24 Mar 2014 09:54:07 +0100
Subject: [commit: ghc] ghc-7.8: change deriveConstants to use nm in a
 POSIX way (fixes #8781) (e7563ec)
In-Reply-To: <532FE145.3050800@centrum.cz>
References: <mailman.4289.1395560771.1937.ghc-commits@haskell.org>
 <532F112D.9000102@mathematik.uni-marburg.de> <532FD58E.3090908@mail.ru>
 <532FE145.3050800@centrum.cz>
Message-ID: <532FF2AF.9010101@mathematik.uni-marburg.de>

On 03/24/2014 08:39 AM, Karel Gardas wrote:
>
> Guys,
>
> could you be so kind and test attached patch?

The 32-bit Windows machine is at home; I will try your patch at night.

Fairly certain that it works, though. A very similar patch (which I was 
just going to propose here) worked for me yesterday night:
                                  _ -> Nothing
                                _ -> Nothing
+                            [('_':x0), "C", x1] ->
+                                 do name <- stripPrefix prefix x0
+                                    case readHex x1 of
+                                     [(size, "")] -> return (name,size)
+                                     _            -> fail "not a size"
                              _ -> Nothing
(using do-notation for Maybe, assuming exactly one "_")

/ Jost

> Thanks!
> Karel
>
> On 03/24/14 07:49 AM, kyra wrote:
>> On 3/23/2014 20:51, Jost Berthold wrote:
>>> Hello,
>>>
>>> With the patch to deriveConstants, a build on an older Windows (32bit
>>> Vista, MinGW32 installation, which used to work) now fails with error
>>>
>>> Can't find "STD_HDR_SIZE"
>> Same here: Windows 64-bit, MSYS2, nm being called is from binutils 2.24.
>>
>> Kyra
>> _______________________________________________
>> ghc-devs mailing list
>> ghc-devs at haskell.org
>> http://www.haskell.org/mailman/listinfo/ghc-devs
>>
>


From petersen at fedoraproject.org  Mon Mar 24 09:05:57 2014
From: petersen at fedoraproject.org (Jens Petersen)
Date: Mon, 24 Mar 2014 18:05:57 +0900
Subject: 7.8.1 RC testsuite failures for 64bit unregisterised builds
Message-ID: <CAEDGBqLpci_O65u03Rve_8zzbmoDJh6N83=Zp2N-isDEjZ35xg@mail.gmail.com>

(changing Subject to "fork" this to a separate thread)

On 23 March 2014 21:42, Peter Trommler <ptrommler at me.com> wrote:

> On 23.03.2014, at 11:44, Jens Petersen <petersen at fedoraproject.org> wrote:
> >> Speaking of ppc64: Do you see ticket #8849 too?
> > Does it show up in the testsuite results too?
>
> Yes, in fact I noticed the error in test arith005 and extracted the small
> test case
> for #8849.
>

Okay I did a ppc64 build with the testsuite:
http://ppc.koji.fedoraproject.org/koji/taskinfo?taskID=1731757
and reproduced #8849 and (probably) #8819 too.

I say "probably" since my ppc64 testsuite results are littered with
"Actual stderr output differs from expected:" warnings caused by:

"""
+
+In file included from /usr/include/math.h:26:0:
+    0,
+                     from
/builddir/build/BUILD/ghc-7.8.0.20140228/includes/Stg.h:65,
+                     from /tmp/ghc25682_0/ghc25682_3.hc:3:
+
+/usr/include/features.h:148:3:
+     warning: #warning "_BSD_SOURCE and _SVID_SOURCE are deprecated, use
_DEFAULT_SOURCE" [-Wcpp]
+     # warning "_BSD_SOURCE and _SVID_SOURCE are deprecated, use
_DEFAULT_SOURCE"
+       ^
"""

I only see those on ppc64 so far.
Perhaps there is some way to ignore those?

In #8819 I reported test failures in an unregisterised compiler produced on
> my x86_64 machine using an unregisterised ghc. Almost all arith tests
> including arith005
> fail and I suspect it might be a data layout issue. I wonder if you can
> reproduce
> #8819 on ppc64. #8849 makes me think yes.


I reproduced also on s390x:
http://s390.koji.fedoraproject.org/koji/taskinfo?taskID=1369051
including #8819 unfortunately !!

So seems this happens on ppc64, s390x and x86_64 for unregisterised.

I know "unregisterised" may be considered less supported these days
but this seems quite serious and I hope it could still be fixed for 7.8.1.

Jens
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/ghc-devs/attachments/20140324/26734e9a/attachment.html>

From karel.gardas at centrum.cz  Mon Mar 24 09:08:48 2014
From: karel.gardas at centrum.cz (Karel Gardas)
Date: Mon, 24 Mar 2014 10:08:48 +0100
Subject: [commit: ghc] ghc-7.8: change deriveConstants to use nm in a
 POSIX way (fixes #8781) (e7563ec)
In-Reply-To: <532FF2AF.9010101@mathematik.uni-marburg.de>
References: <mailman.4289.1395560771.1937.ghc-commits@haskell.org>
 <532F112D.9000102@mathematik.uni-marburg.de> <532FD58E.3090908@mail.ru>
 <532FE145.3050800@centrum.cz> <532FF2AF.9010101@mathematik.uni-marburg.de>
Message-ID: <532FF620.8030502@centrum.cz>

On 03/24/14 09:54 AM, Jost Berthold wrote:
> On 03/24/2014 08:39 AM, Karel Gardas wrote:
>>
>> Guys,
>>
>> could you be so kind and test attached patch?
>
> The 32-bit Windows machine is at home; I will try your patch at night.
>
> Fairly certain that it works, though.

Indeed, it's working on your testing line you have provided. I just 
would like to know if it works on bootstrap too as I don't have win/ghc 
machine here.

Thanks for testing!
Karel

From hvriedel at gmail.com  Mon Mar 24 09:14:44 2014
From: hvriedel at gmail.com (Herbert Valerio Riedel)
Date: Mon, 24 Mar 2014 10:14:44 +0100
Subject: [commit: ghc] master: Convert haddock into a proper submodule (re
 #8545) (34b0721)
In-Reply-To: <59543203684B2244980D7E4057D5FBC1488B92DF@DB3EX14MBXC308.europe.corp.microsoft.com>
 (Simon Peyton Jones's message of "Mon, 24 Mar 2014 08:37:32 +0000")
References: <20140323094934.5E7D52406B@ghc.haskell.org>
 <59543203684B2244980D7E4057D5FBC1488B8AF9@DB3EX14MBXC308.europe.corp.microsoft.com>
 <871txsbpbr.fsf@gmail.com>
 <59543203684B2244980D7E4057D5FBC1488B92DF@DB3EX14MBXC308.europe.corp.microsoft.com>
Message-ID: <8761n4nekb.fsf@gmail.com>

Hello Simon,

On 2014-03-24 at 09:37:32 +0100, Simon Peyton Jones wrote:
> OK. Some questions.
>
> ? Where is a good place to get a conceptual understanding of
> submodules?

There were three links at the top of the Wiki page; I assume you want
something better than that?

> Concerning
> https://ghc.haskell.org/trac/ghc/wiki/WorkingConventions/Git/Submodules
>
> ? Under "Updating an existing source tree clone" you say we have to do
> "git submodule update --init". What happens if we forget? Couldn't
> sync-all do that? (Indeed it now emits a message to that effect

sync-all can do that of course; at this point, I'm just collecting all
direct `git` commands one would have to enter if there wasn't a sync-all
script -- once everything is in place, a new radically stripped down
`sync-all` can be constructed for the common day-to-day invocations.

The page also aims to make the underlying Git commands more transparent,
with the hope that by explaining what happens under the hood, it may
become less confusing when `sync-all` fails.

> bash$ ./sync-all pull --rebase

Yes, sync-all does already call `git submodule update` in some occasions
already, but its current implementation is far more confusing than it
needs to be IMHO :-)


> ? Under ?Overriding pushurl?, same question. Couldn?t that long ?git
> submodule foreach? command be done by sync-all?

yes, it will

(even though that specific invocation will be taken core by sync-all in
the future, that snippet serves as an example for the versatile 'git
submodule foreach' tool everyone working with submodules should at least
know about -- it's not that far-fetched that one might want to do
something non-standard sync-all doesn't handle)

> ? Under ?Making changes?, this looks hard to me. Is ?base? a
> submodule? 
> Does that mean we have to remember to do some incantations before we
> modify base? 

Actually, we're strongly considering to fold the non-upgradable
GHC-specific packages tied to GHC, namely

 - base
 - ghc-prim
 - integer-{gmp,simple}
 - template-haskell

into ghc.git (as was done with testsuite/) as those wouldn't benefit
much from remaining an independent (submodule) repo anyway;

> What if you forget and make the modifications first?  Again, could
> some of this be automated, at least for the common workflow of
> pull/push?

for one, if you forget to associate a Git branch before committing on a
detached-HEAD, you can simply 'git push origin HEAD:master'

If you meant about forgetting to update ghc.git to point to the new
commit, then that's actually a feature to avoid *having* to track each
single push/commit to master of a submodule to ghc.git's master branch
as well; For instance, utils/haddock 'master' is currently one rather
unimportant commit[1] ahead of what 'ghc.git' references as its
haddock.git commit right now.

 [1]: http://git.haskell.org/haddock.git/commitdiff/f3c7cd34d066cd40cb4983893165de038974fd95

From marlowsd at gmail.com  Mon Mar 24 10:06:04 2014
From: marlowsd at gmail.com (Simon Marlow)
Date: Mon, 24 Mar 2014 10:06:04 +0000
Subject: [commit: ghc] ghc-7.8: change deriveConstants to use nm in a
 POSIX way (fixes #8781) (e7563ec)
In-Reply-To: <532FD58E.3090908@mail.ru>
References: <mailman.4289.1395560771.1937.ghc-commits@haskell.org>
 <532F112D.9000102@mathematik.uni-marburg.de> <532FD58E.3090908@mail.ru>
Message-ID: <5330038C.2000902@gmail.com>

On 24/03/2014 06:49, kyra wrote:
> On 3/23/2014 20:51, Jost Berthold wrote:
>> Hello,
>>
>> With the patch to deriveConstants, a build on an older Windows (32bit
>> Vista, MinGW32 installation, which used to work) now fails with error
>>
>>     Can't find "STD_HDR_SIZE"
> Same here: Windows 64-bit, MSYS2, nm being called is from binutils 2.24.

I also ran into this when I tried to do a Windows build today, so I've 
reverted the patch in my local tree.

Karel: will you look into this?

Note that on Windows, nm is part of the mingw tools that we provide in 
ghc-tarballs/, so if that needs upgrading we'll need to commit new 
versions of the tools (for both 32 and 64-bit mingw).

Cheers,
Simon

From Christian.Maeder at dfki.de  Mon Mar 24 10:25:31 2014
From: Christian.Maeder at dfki.de (Christian Maeder)
Date: Mon, 24 Mar 2014 11:25:31 +0100
Subject: [commit: ghc] ghc-7.8: change deriveConstants to use nm in a
 POSIX way (fixes #8781) (e7563ec)
In-Reply-To: <532F112D.9000102@mathematik.uni-marburg.de>
References: <mailman.4289.1395560771.1937.ghc-commits@haskell.org>
 <532F112D.9000102@mathematik.uni-marburg.de>
Message-ID: <5330081B.6060600@dfki.de>

Hi,

sorry, I've missed this thread.

Did you just run "nm" or "nm -P" on 
includes/dist-derivedconstants/header/tmp.o?

The comment should say how the output looks like. For GNU nm (without 
option -P) is was:

"0000000b C derivedConstantMAX_Vanilla_REG"

if it is now:

"_derivedConstantBlaBlah_Blah C 000001b"

for "nm -P" on Windows the patch could (and should) be adjusted, easily.
(The 4th word only needs to be present and taken if the second word is 
not a "C", which is only the case under Solaris.)

HTH Christian

Am 23.03.2014 17:51, schrieb Jost Berthold:
> Hello,
>
> With the patch to deriveConstants, a build on an older Windows (32bit
> Vista, MinGW32 installation, which used to work) now fails with error
>
>      Can't find "STD_HDR_SIZE"
>
> I ran the nm command manually on the generated o file
> (includes/dist-derivedconstants/header/tmp.o) and saw that the output
> follows pattern
>
> _derivedConstantBlaBlah_Blah C 000001b
>
> so it does not match the four-word pattern in the patch.
>
> Is this a problem with my setup, or does it fail for other people on
> Windows as well?
>
> Thanks,
> Jost
>
> On 03/23/2014 08:46 AM, ghc-commits-request at haskell.org wrote:
>> Message: 6
>> Date: Sun, 23 Mar 2014 02:01:50 +0000 (UTC)
>> From: git at git.haskell.org
>> To: ghc-commits at haskell.org
>> Subject: [commit: ghc] ghc-7.8: change deriveConstants to use nm in a
>>     POSIX way (fixes #8781) (e7563ec)
>> Message-ID: <20140323020150.1DCE82406B at ghc.haskell.org>
>> Content-Type: text/plain; charset=utf-8
>>
>> Repository : ssh://git at git.haskell.org/ghc
>>
>> On branch  : ghc-7.8
>> Link       :
>> http://ghc.haskell.org/trac/ghc/changeset/e7563ec2e03740074903036bf129fc972b623c23/ghc
>>
>>
>>> ---------------------------------------------------------------
>>
>> commit e7563ec2e03740074903036bf129fc972b623c23
>> Author: Karel Gardas <karel.gardas at centrum.cz>
>> Date:   Sat Mar 22 22:33:05 2014 +0100
>>
>>      change deriveConstants to use nm in a POSIX way (fixes #8781)
>>
>>      The patch provided by Christian Maeder <Christian.Maeder at dfki.de>
>>
>>      Signed-off-by: Karel Gardas <karel.gardas at centrum.cz>
>>      Signed-off-by: Austin Seipp <austin at well-typed.com>
>>      (cherry picked from commit 045b28033a33a48d31951240a8cb35f2b78345dc)
>>
>>
>>> ---------------------------------------------------------------
>>
>> e7563ec2e03740074903036bf129fc972b623c23
>>   utils/deriveConstants/DeriveConstants.hs |   30
>> ++++++++++--------------------
>>   1 file changed, 10 insertions(+), 20 deletions(-)
>>
>> diff --git a/utils/deriveConstants/DeriveConstants.hs
>> b/utils/deriveConstants/DeriveConstants.hs
>> index 10df61c..54ee6a1 100644
>> --- a/utils/deriveConstants/DeriveConstants.hs
>> +++ b/utils/deriveConstants/DeriveConstants.hs
>> @@ -638,7 +638,7 @@ getWanted verbose tmpdir gccProgram gccFlags
>> nmProgram
>>                oFile = tmpdir </> "tmp.o"
>>            writeFile cFile cStuff
>>            execute verbose gccProgram (gccFlags ++ ["-c", cFile, "-o",
>> oFile])
>> -         xs <- readProcess nmProgram [oFile] ""
>> +         xs <- readProcess nmProgram ["-P", oFile] ""
>>            let ls = lines xs
>>                ms = map parseNmLine ls
>>                m = Map.fromList $ catMaybes ms
>> @@ -707,27 +707,17 @@ getWanted verbose tmpdir gccProgram gccFlags
>> nmProgram
>>             doWanted (ClosurePayloadMacro {}) = []
>>             doWanted (FieldTypeGcptrMacro {}) = []
>>
>> -          -- parseNmLine parses nm output that looks like
>> -          -- "0000000b C derivedConstantMAX_Vanilla_REG"
>> +          -- parseNmLine parses "nm -P" output that looks like
>> +          -- "_derivedConstantMAX_Vanilla_REG C b 0" Mac OS X
>> +          -- "derivedConstantMAX_Vanilla_REG C 0000000b 0000000b" GNU
>> +          -- "derivedConstantMAX_Vanilla_REG D        1        b"
>> Solaris
>>             -- and returns ("MAX_Vanilla_REG", 11)
>> -          parseNmLine xs0 = case break (' ' ==) xs0 of
>> -                            (x1, ' ' : xs1) ->
>> -                                case break (' ' ==) xs1 of
>> -                                (x2, ' ' : x3) ->
>> -                                    case readHex x1 of
>> -                                    [(size, "")] ->
>> -                                        case x2 of
>> -                                        "C" ->
>> -                                            let x3' = case x3 of
>> -                                                      '_' : rest -> rest
>> -                                                      _          -> x3
>> -                                            in case stripPrefix
>> prefix x3' of
>> -                                               Just name ->
>> -                                                   Just (name, size)
>> -                                               _ -> Nothing
>> -                                        _ -> Nothing
>> -                                    _ -> Nothing
>> +          parseNmLine xs0 = case words xs0 of
>> +                            [x0, x1, x2, x3] -> case stripPrefix
>> prefix $ dropWhile (== '_') x0 of
>> +                              Just name -> case readHex $ if x1 ==
>> "C" then x2 else x3 of
>> +                                [(size, "")] -> Just (name, size)
>>                                   _ -> Nothing
>> +                              _ -> Nothing
>>                               _ -> Nothing
>>
>>             -- If an Int value is larger than 2^28 or smaller
>
>
> _______________________________________________
> ghc-devs mailing list
> ghc-devs at haskell.org
> http://www.haskell.org/mailman/listinfo/ghc-devs
>


From simonpj at microsoft.com  Mon Mar 24 10:30:33 2014
From: simonpj at microsoft.com (Simon Peyton Jones)
Date: Mon, 24 Mar 2014 10:30:33 +0000
Subject: FW: [commit: ghc] master: Add missing kind-check for tcEqType on
 forall-types (74894e0)
In-Reply-To: <20140324102652.4EBE92406B@ghc.haskell.org>
References: <20140324102652.4EBE92406B@ghc.haskell.org>
Message-ID: <59543203684B2244980D7E4057D5FBC1488B9E9C@DB3EX14MBXC308.europe.corp.microsoft.com>

Austin, this one looks like a bug waiting to happen, so let's merge if time.

Simon

-----Original Message-----
From: ghc-commits [mailto:ghc-commits-bounces at haskell.org] On Behalf Of git at git.haskell.org
Sent: 24 March 2014 10:27
To: ghc-commits at haskell.org
Subject: [commit: ghc] master: Add missing kind-check for tcEqType on forall-types (74894e0)

Repository : ssh://git at git.haskell.org/ghc

On branch  : master
Link       : http://ghc.haskell.org/trac/ghc/changeset/74894e0bc405247092e865b9541f5f18d26aa015/ghc

>---------------------------------------------------------------

commit 74894e0bc405247092e865b9541f5f18d26aa015
Author: Simon Peyton Jones <simonpj at microsoft.com>
Date:   Fri Mar 21 15:24:49 2014 +0000

    Add missing kind-check for tcEqType on forall-types
    
    This wasn't showing up as a bug, but it was definitely wrong.


>---------------------------------------------------------------

74894e0bc405247092e865b9541f5f18d26aa015
 compiler/typecheck/TcType.lhs |    7 ++++---
 1 file changed, 4 insertions(+), 3 deletions(-)

diff --git a/compiler/typecheck/TcType.lhs b/compiler/typecheck/TcType.lhs index 9b58b4c..08c7a62 100644
--- a/compiler/typecheck/TcType.lhs
+++ b/compiler/typecheck/TcType.lhs
@@ -245,7 +245,6 @@ checking.  It's attached to mutable type variables only.
 It's knot-tied back to Var.lhs.  There is no reason in principle  why Var.lhs shouldn't actually have the definition, but it "belongs" here.
 
-
 Note [Signature skolems]
 ~~~~~~~~~~~~~~~~~~~~~~~~
 Consider this
@@ -1008,7 +1007,8 @@ tcEqType ty1 ty2
                  | Just t2' <- tcView t2 = go env t1 t2'
     go env (TyVarTy tv1)       (TyVarTy tv2)     = rnOccL env tv1 == rnOccR env tv2
     go _   (LitTy lit1)        (LitTy lit2)      = lit1 == lit2
-    go env (ForAllTy tv1 t1)   (ForAllTy tv2 t2) = go (rnBndr2 env tv1 tv2) t1 t2
+    go env (ForAllTy tv1 t1)   (ForAllTy tv2 t2) = go env (tyVarKind tv1) (tyVarKind tv2)
+                                                && go (rnBndr2 env tv1 
+ tv2) t1 t2
     go env (AppTy s1 t1)       (AppTy s2 t2)     = go env s1 s2 && go env t1 t2
     go env (FunTy s1 t1)       (FunTy s2 t2)     = go env s1 s2 && go env t1 t2
     go env (TyConApp tc1 ts1) (TyConApp tc2 ts2) = (tc1 == tc2) && gos env ts1 ts2 @@ -1027,7 +1027,8 @@ pickyEqType ty1 ty2
     init_env = mkRnEnv2 (mkInScopeSet (tyVarsOfType ty1 `unionVarSet` tyVarsOfType ty2))
     go env (TyVarTy tv1)       (TyVarTy tv2)     = rnOccL env tv1 == rnOccR env tv2
     go _   (LitTy lit1)        (LitTy lit2)      = lit1 == lit2
-    go env (ForAllTy tv1 t1)   (ForAllTy tv2 t2) = go (rnBndr2 env tv1 tv2) t1 t2
+    go env (ForAllTy tv1 t1)   (ForAllTy tv2 t2) = go env (tyVarKind tv1) (tyVarKind tv2)
+                                                && go (rnBndr2 env tv1 
+ tv2) t1 t2
     go env (AppTy s1 t1)       (AppTy s2 t2)     = go env s1 s2 && go env t1 t2
     go env (FunTy s1 t1)       (FunTy s2 t2)     = go env s1 s2 && go env t1 t2
     go env (TyConApp tc1 ts1) (TyConApp tc2 ts2) = (tc1 == tc2) && gos env ts1 ts2

_______________________________________________
ghc-commits mailing list
ghc-commits at haskell.org
http://www.haskell.org/mailman/listinfo/ghc-commits

From berthold at Mathematik.Uni-Marburg.de  Mon Mar 24 10:35:01 2014
From: berthold at Mathematik.Uni-Marburg.de (Jost Berthold)
Date: Mon, 24 Mar 2014 11:35:01 +0100
Subject: [commit: ghc] ghc-7.8: change deriveConstants to use nm in a
 POSIX way (fixes #8781) (e7563ec)
In-Reply-To: <5330081B.6060600@dfki.de>
References: <mailman.4289.1395560771.1937.ghc-commits@haskell.org>
 <532F112D.9000102@mathematik.uni-marburg.de> <5330081B.6060600@dfki.de>
Message-ID: <53300A55.20002@mathematik.uni-marburg.de>

On 03/24/2014 11:25 AM, Christian Maeder wrote:
> Hi,
>
> sorry, I've missed this thread.
>
> Did you just run "nm" or "nm -P" on
> includes/dist-derivedconstants/header/tmp.o?

I ran "nm -P".

> The comment should say how the output looks like. For GNU nm (without
> option -P) is was:
>
> "0000000b C derivedConstantMAX_Vanilla_REG"
>
> if it is now:
>
> "_derivedConstantBlaBlah_Blah C 000001b"
>
> for "nm -P" on Windows the patch could (and should) be adjusted, easily.
> (The 4th word only needs to be present and taken if the second word is
> not a "C", which is only the case under Solaris.)

The output (with option "-P") was

"_derivedConstantBlaBlah_Blah C 000001b"

I agree the code of the previous patch is easy to adjust.
While several ways are possible, my own suggestion was to add a new 
specialised case rather than trying to integrate into the existing code.

/ Jost


From malcolm.wallace at me.com  Mon Mar 24 10:39:25 2014
From: malcolm.wallace at me.com (Malcolm Wallace)
Date: Mon, 24 Mar 2014 10:39:25 +0000
Subject: help understanding the validate_build_xhtml failure of ./validate
 for my CPP patch
In-Reply-To: <CAHYVw0xX_pmNi_w=41tpho1W8x6wHpJOP6U8ymBeYH4W-+ZfUw@mail.gmail.com>
References: <CAHYVw0xX_pmNi_w=41tpho1W8x6wHpJOP6U8ymBeYH4W-+ZfUw@mail.gmail.com>
Message-ID: <56794DAB-D6C8-4338-864A-1331F9736AF6@me.com>


On 23 Mar 2014, at 20:33, Carter Schonwald wrote:

> Hey all, I'm trying to get my CPP_Setttings patch to validate,
> and i'm trying to understand why my validate is failing. At this point im stumped and I really could  use some help!


This looks like the key information:

> Building xhtml-3000.2.1...
> Preprocessing library xhtml-3000.2.1...
> ghc: could not execute: 

Ghc is reporting that it could not execute "".  This suggests the commandline for external preprocessing is incorrectly formed.

Regards,
    Malcolm

From karel.gardas at centrum.cz  Mon Mar 24 13:25:19 2014
From: karel.gardas at centrum.cz (Karel Gardas)
Date: Mon, 24 Mar 2014 14:25:19 +0100
Subject: [commit: ghc] ghc-7.8: change deriveConstants to use nm in a
 POSIX way (fixes #8781) (e7563ec)
In-Reply-To: <5330038C.2000902@gmail.com>
References: <mailman.4289.1395560771.1937.ghc-commits@haskell.org>
 <532F112D.9000102@mathematik.uni-marburg.de> <532FD58E.3090908@mail.ru>
 <5330038C.2000902@gmail.com>
Message-ID: <5330323F.8060906@centrum.cz>

On 03/24/14 11:06 AM, Simon Marlow wrote:
> On 24/03/2014 06:49, kyra wrote:
>> On 3/23/2014 20:51, Jost Berthold wrote:
>>> Hello,
>>>
>>> With the patch to deriveConstants, a build on an older Windows (32bit
>>> Vista, MinGW32 installation, which used to work) now fails with error
>>>
>>> Can't find "STD_HDR_SIZE"
>> Same here: Windows 64-bit, MSYS2, nm being called is from binutils 2.24.
>
> I also ran into this when I tried to do a Windows build today, so I've
> reverted the patch in my local tree.
>
> Karel: will you look into this?

I already provided a fix for testing on this mailing list. Jost 
(original reporter) promised to do that during the night on his home 
machine. If it's working, I'll prepare complete git patch immediately 
and attach to the #8781 for Austin.

Perhaps you can test it too?

Thanks!
Karel

From simonpj at microsoft.com  Mon Mar 24 14:46:22 2014
From: simonpj at microsoft.com (Simon Peyton Jones)
Date: Mon, 24 Mar 2014 14:46:22 +0000
Subject: We need to add role annotations for 7.8
In-Reply-To: <CAKFCL4Xz_W9of6SyXBsFfk+6Kp4E=T7pjPt4ZhqjqqY9wsixkw@mail.gmail.com>
References: <78518EC7-BC18-4732-90B6-1AB37048D2A3@cis.upenn.edu>
 <CAK-tuPY0G0ceKK=mNp1N2H-h8S1sN47rahd2OmAXU3RrP-zukQ@mail.gmail.com>
 <CALjd_v5pCBQv4qXAm3E4_qSp8NRLjq1BKV1dJejymsUhruDReQ@mail.gmail.com>
 <CALjd_v6Ar4BVyWyYjpYDy-2UO78tVC3uOcdVyVSSpvi8M-oE9Q@mail.gmail.com>
 <CAEs96n1Xxp9qmXLBf6XqKbLH3kEE3bVLcpLAuFHoVip0N+1D=w@mail.gmail.com>
 <CAEs96n1dVs8SC6an_5eCsx1aCPwbNjbahhNrKAeaSCv1=Qe3gw@mail.gmail.com>
 <CAEs96n0SCjD6_C7VkeL0NUCY+v-fZseeL=iRFZG9fL9b74AjwQ@mail.gmail.com>
 <CAEs96n1WnrVtyjk2f3jOgUZg2M4EwPSA-9bnN6+9dL1p+=Ea0w@mail.gmail.com>
 <CAK-tuPahbPSd4fxjRCMKHYPcsPuzsM3CnBFMBvkoYbAZkVmmjw@mail.gmail.com>
 <CAAOoiFZKYXzqdfS1PVfG4W_H9ig8iw3MrcTFWu5GrP4C6sgEoA@mail.gmail.com>
 <CAKFCL4Xz_W9of6SyXBsFfk+6Kp4E=T7pjPt4ZhqjqqY9wsixkw@mail.gmail.com>
Message-ID: <59543203684B2244980D7E4057D5FBC1488BA55B@DB3EX14MBXC308.europe.corp.microsoft.com>

When Brandon says ?potential bugs/unsafety and all? he means GeneralisedNewtypeDeriving (GND).  That already exists, and already allows you to do bad things (Trac #1496 among others).

See the thread on https://ghc.haskell.org/trac/ghc/ticket/8827, starting especially at comment 17 for more discussion and some insightful comments.  As Edward (on the ticket) and Brandon (here) point out, going to ?nominal by default? will be very safe but it?ll break many Haskell packages which use GND.

This is really a library/user question, not a GHC one.  We can implement whatever default you want.  But GHC 7.8 is about to be released and this debate has been going on for some weeks, at high intensity on ghc-devs, plus Richard specifically advertised it to the libraries list back in November<http://www.haskell.org/pipermail/libraries/2013-November/021707.html>, and again a couple of weeks ago<http://www.haskell.org/pipermail/libraries/2014-March/022321.html>.

I think the status quo is not unreasonable.  One question you might want to debate is whether, as Brandon suggests, you want to move to ?nominal by default? in due course.

Simon

From: Libraries [mailto:libraries-bounces at haskell.org] On Behalf Of Brandon Allbery
Sent: 24 March 2014 14:28
To: Mark Lentczner
Cc: GHC Development Mailing List; libraries at haskell.org Libraries
Subject: Re: We need to add role annotations for 7.8

On Mon, Mar 24, 2014 at 10:14 AM, Mark Lentczner <mark.lentczner at gmail.com<mailto:mark.lentczner at gmail.com>> wrote:
On Fri, Mar 14, 2014 at 2:36 AM, Johan Tibell <johan.tibell at gmail.com<mailto:johan.tibell at gmail.com>> wrote:
I'm quite worried about this change though. I thought the default role for data type was nominal, as that's the safe default. If the default is representational, every package author will need to be aware of this feature and update their packages. That's quite a high cost.

On Fri, Mar 14, 2014 at 6:00 AM, Brandon Allbery <allbery.b at gmail.com<mailto:allbery.b at gmail.com>> wrote:

Nominal default breaks everything that uses newtype deriving and doesn't have role annotations, doesn't it? Representational default means things behave in 7.8 as they did in earlier GHCs.

Am I reading these pair of statements correctly? It seems to imply to me that every parameterized type that uses a type constraint on a parameter must be reviewed and possibly annotated to work correctly, one way or the other!

No; if the default is representational, everything works as it did in earlier versions, potential bugs/unsafety and all. If the default is immediately switched to nominal, *then* every affected type must be reviewed immediately. My counter-proposal was to have 7.8 default to representational to give library maintainers a release cycle to add the necessary annotations, then switch the default to nominal in 7.10 to get the additional safety.

--
brandon s allbery kf8nh                               sine nomine associates
allbery.b at gmail.com<mailto:allbery.b at gmail.com>                                  ballbery at sinenomine.net<mailto:ballbery at sinenomine.net>
unix, openafs, kerberos, infrastructure, xmonad        http://sinenomine.net
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/ghc-devs/attachments/20140324/9653b74b/attachment.html>

From mark.lentczner at gmail.com  Mon Mar 24 15:26:14 2014
From: mark.lentczner at gmail.com (Mark Lentczner)
Date: Mon, 24 Mar 2014 08:26:14 -0700
Subject: We need to add role annotations for 7.8
In-Reply-To: <59543203684B2244980D7E4057D5FBC1488BA55B@DB3EX14MBXC308.europe.corp.microsoft.com>
References: <78518EC7-BC18-4732-90B6-1AB37048D2A3@cis.upenn.edu>
 <CAK-tuPY0G0ceKK=mNp1N2H-h8S1sN47rahd2OmAXU3RrP-zukQ@mail.gmail.com>
 <CALjd_v5pCBQv4qXAm3E4_qSp8NRLjq1BKV1dJejymsUhruDReQ@mail.gmail.com>
 <CALjd_v6Ar4BVyWyYjpYDy-2UO78tVC3uOcdVyVSSpvi8M-oE9Q@mail.gmail.com>
 <CAEs96n1Xxp9qmXLBf6XqKbLH3kEE3bVLcpLAuFHoVip0N+1D=w@mail.gmail.com>
 <CAEs96n1dVs8SC6an_5eCsx1aCPwbNjbahhNrKAeaSCv1=Qe3gw@mail.gmail.com>
 <CAEs96n0SCjD6_C7VkeL0NUCY+v-fZseeL=iRFZG9fL9b74AjwQ@mail.gmail.com>
 <CAEs96n1WnrVtyjk2f3jOgUZg2M4EwPSA-9bnN6+9dL1p+=Ea0w@mail.gmail.com>
 <CAK-tuPahbPSd4fxjRCMKHYPcsPuzsM3CnBFMBvkoYbAZkVmmjw@mail.gmail.com>
 <CAAOoiFZKYXzqdfS1PVfG4W_H9ig8iw3MrcTFWu5GrP4C6sgEoA@mail.gmail.com>
 <CAKFCL4Xz_W9of6SyXBsFfk+6Kp4E=T7pjPt4ZhqjqqY9wsixkw@mail.gmail.com>
 <59543203684B2244980D7E4057D5FBC1488BA55B@DB3EX14MBXC308.europe.corp.microsoft.com>
Message-ID: <CAAOoiFaof89nQBRStVD38hmHQbBeNNQOU1+YEdaq_iwieKgGJA@mail.gmail.com>

Thanks for the pointers, Simon. I appologize for coming to this quite so
late... I didn't realize the global impact of this feature.

>From a "meaning" perspective, I'm agnostic on the default.
>From a "engineering" perspective, I want a default that "does a good
enough, reasonably safe thing" if programmers ignore the feature.

The later is subtle as there are different vantage points for different
developers. In the Platform, we have many libraries that we are encouraging
both end-programmers, and other library authors to make use of and depend
on extensively. This means those libraries have to work for both
programmers that are ignoring the feature, and those that use it. In that
later case, there is the even more subtle distinction of those that use the
feature for their own code, and those that use it in libraries they make
available.

The later case is issue: It seems a real mess if a library author who
wanted to use the new feature, had to circumvent a HP library because it
didn't annotate. Similar thought experiment: What would be the downside if
containers didn't annotate? Would that just make the feature unusable
because everything uses containers?

To put it more directly: with the satus-quo default of representations,
what is the down side if a library, a widely used library, doesn't bother
to annotate? What would be the loss if containers didn't annotate? (I know
it did, this is the thought experiment... because I've got 30+ libraries in
HP that are in this boat.)
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/ghc-devs/attachments/20140324/f6425041/attachment-0001.html>

From mark.lentczner at gmail.com  Mon Mar 24 15:36:35 2014
From: mark.lentczner at gmail.com (Mark Lentczner)
Date: Mon, 24 Mar 2014 08:36:35 -0700
Subject: We need to add role annotations for 7.8
In-Reply-To: <CAAOoiFaof89nQBRStVD38hmHQbBeNNQOU1+YEdaq_iwieKgGJA@mail.gmail.com>
References: <78518EC7-BC18-4732-90B6-1AB37048D2A3@cis.upenn.edu>
 <CAK-tuPY0G0ceKK=mNp1N2H-h8S1sN47rahd2OmAXU3RrP-zukQ@mail.gmail.com>
 <CALjd_v5pCBQv4qXAm3E4_qSp8NRLjq1BKV1dJejymsUhruDReQ@mail.gmail.com>
 <CALjd_v6Ar4BVyWyYjpYDy-2UO78tVC3uOcdVyVSSpvi8M-oE9Q@mail.gmail.com>
 <CAEs96n1Xxp9qmXLBf6XqKbLH3kEE3bVLcpLAuFHoVip0N+1D=w@mail.gmail.com>
 <CAEs96n1dVs8SC6an_5eCsx1aCPwbNjbahhNrKAeaSCv1=Qe3gw@mail.gmail.com>
 <CAEs96n0SCjD6_C7VkeL0NUCY+v-fZseeL=iRFZG9fL9b74AjwQ@mail.gmail.com>
 <CAEs96n1WnrVtyjk2f3jOgUZg2M4EwPSA-9bnN6+9dL1p+=Ea0w@mail.gmail.com>
 <CAK-tuPahbPSd4fxjRCMKHYPcsPuzsM3CnBFMBvkoYbAZkVmmjw@mail.gmail.com>
 <CAAOoiFZKYXzqdfS1PVfG4W_H9ig8iw3MrcTFWu5GrP4C6sgEoA@mail.gmail.com>
 <CAKFCL4Xz_W9of6SyXBsFfk+6Kp4E=T7pjPt4ZhqjqqY9wsixkw@mail.gmail.com>
 <59543203684B2244980D7E4057D5FBC1488BA55B@DB3EX14MBXC308.europe.corp.microsoft.com>
 <CAAOoiFaof89nQBRStVD38hmHQbBeNNQOU1+YEdaq_iwieKgGJA@mail.gmail.com>
Message-ID: <CAAOoiFag0mf7uUJoFzw2-zOWN+J=KStRfnCevSxRiZy0Pg=Uvg@mail.gmail.com>

Again, sorry for the 11:59 meddling....

The syntax of role annotations is very heavy weight, and requires lots of
CPP where there wasn't need before.  Two thoughts:

1) Couldn't we do something like use "cue" type constraints? For example,
assuming the default is representational, and that phantom can just be
inferred, all we need is a way to indicate nominal:

data (Nominal k) => Map k v = ...


This could then probably be easily made to compile in other compilers with
some null library implementation of Nominal

2) An alternative to the above. We generally frown on constraints in a data
/ newtype declaration, but perhaps this is exactly the case for them,
whereby we can now do away with the type role syntax: We can infer nominal
if there are *any* constraints on a type parameter, *representational* if
there are none, and *phantom *if there are no mentions in the right hand
side:

data (Eq k) => Map k v = ...


This seems even nicer and just works with all compilers... but perhaps I'm
missing something. (Yes, I imagine there are type constraints that
shouldn't force nominal, but perhaps not worth worrying about?)


Mind you, this all just about syntax... the issue of what is the
implication for libraries of the default being representational is still at
hand.
?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/ghc-devs/attachments/20140324/cac40505/attachment.html>

From fuuzetsu at fuuzetsu.co.uk  Mon Mar 24 17:54:25 2014
From: fuuzetsu at fuuzetsu.co.uk (Mateusz Kowalczyk)
Date: Mon, 24 Mar 2014 17:54:25 +0000
Subject: module =?windows-1252?Q?=91free-4=2E6=2E1=3AMain=92_is_defin?=
 =?windows-1252?Q?ed_in_multiple_files?=
Message-ID: <53307151.9010800@fuuzetsu.co.uk>

Greetings,

First of all to people reading this at ghc-devs, I don't expect this to
be a direct problem caused by GHC but who knows, so I'm CC'ing it anyway.

As you might know, GHC 7.8.1 is scheduled to release Very Soon?  (later
today?). We got a report at Haddock Trac few weeks ago about a strange
error, see http://trac.haskell.org/haddock/ticket/284.

I have asked about this on cabal-devel before and Mikhail said that
maybe it's https://github.com/haskell/cabal/pull/1374 but it's unlikely
because the changes aren't ran by default.

Today I got new reports of this problem and so far everyone on OSX seems
to be affected! This suddenly became a big problem. To replicate:

1. Find OSX machine
2. Get GHC 7.8 rc2 package (which includes Haddock at that stage)
3. git clone git at github.com:ekmett/free.git && cd free
4. cabal install --only-dependencies --enable-documentation && cabal
configure && cabal haddock

The reason I'm barking up cabal-devel and ghc-devs is because I honestly
can not think of anything that has changed since Haddock 2.13.2.1 that
could possibly cause this.

Does anyone have any idea at all? I think it would be very bad to
release now and have everyone on OSX unable to build docs.

FYI I get build docs on 32-bit Linux. No idea about Windows.

Thanks, I hope to hear back soon.

PS: How does one go about downgrading Cabal and cabal-install? If we
wanted to check whether cabal is the problem, how?

-- 
Mateusz K.

From iavor.diatchki at gmail.com  Mon Mar 24 17:58:34 2014
From: iavor.diatchki at gmail.com (Iavor Diatchki)
Date: Mon, 24 Mar 2014 10:58:34 -0700
Subject: Merge CmpNat and CmpSymbol in 7.8
Message-ID: <CAGK9nupKeMOHe-fEAn_QBti5SkE-UMFkq8eSWdRN0321YCBnEA@mail.gmail.com>

Hi,

based on requests from a couple of people I added a couple of type-level
functions for type nats and type symbols.  Could we get these merged in
7.8?  The relevant commits are:

In GHC:
5e4bdb5fc5e741522cbb787731422da3f12aa398
Implement ordering comparisons for type-level naturals and symbols.


In base:
5edb063688e73ec00fd1f61ac0e8317dd122f44a
Comments only.

c1d3546420ee482bbbd9f15d45a6e8a26304d419
Add functions for comparing type-level Nats and Symbols.

Thanks!
-Iavor
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/ghc-devs/attachments/20140324/7e89b9d7/attachment.html>

From ekmett at gmail.com  Mon Mar 24 19:10:47 2014
From: ekmett at gmail.com (Edward Kmett)
Date: Mon, 24 Mar 2014 15:10:47 -0400
Subject: We need to add role annotations for 7.8
In-Reply-To: <CAAOoiFaof89nQBRStVD38hmHQbBeNNQOU1+YEdaq_iwieKgGJA@mail.gmail.com>
References: <78518EC7-BC18-4732-90B6-1AB37048D2A3@cis.upenn.edu>
 <CAK-tuPY0G0ceKK=mNp1N2H-h8S1sN47rahd2OmAXU3RrP-zukQ@mail.gmail.com>
 <CALjd_v5pCBQv4qXAm3E4_qSp8NRLjq1BKV1dJejymsUhruDReQ@mail.gmail.com>
 <CALjd_v6Ar4BVyWyYjpYDy-2UO78tVC3uOcdVyVSSpvi8M-oE9Q@mail.gmail.com>
 <CAEs96n1Xxp9qmXLBf6XqKbLH3kEE3bVLcpLAuFHoVip0N+1D=w@mail.gmail.com>
 <CAEs96n1dVs8SC6an_5eCsx1aCPwbNjbahhNrKAeaSCv1=Qe3gw@mail.gmail.com>
 <CAEs96n0SCjD6_C7VkeL0NUCY+v-fZseeL=iRFZG9fL9b74AjwQ@mail.gmail.com>
 <CAEs96n1WnrVtyjk2f3jOgUZg2M4EwPSA-9bnN6+9dL1p+=Ea0w@mail.gmail.com>
 <CAK-tuPahbPSd4fxjRCMKHYPcsPuzsM3CnBFMBvkoYbAZkVmmjw@mail.gmail.com>
 <CAAOoiFZKYXzqdfS1PVfG4W_H9ig8iw3MrcTFWu5GrP4C6sgEoA@mail.gmail.com>
 <CAKFCL4Xz_W9of6SyXBsFfk+6Kp4E=T7pjPt4ZhqjqqY9wsixkw@mail.gmail.com>
 <59543203684B2244980D7E4057D5FBC1488BA55B@DB3EX14MBXC308.europe.corp.microsoft.com>
 <CAAOoiFaof89nQBRStVD38hmHQbBeNNQOU1+YEdaq_iwieKgGJA@mail.gmail.com>
Message-ID: <CAJumaK_-dxYW=raqvCyfp1h-9XFwj2eKq_smWHng=DuUChfZ4w@mail.gmail.com>

Mark,

We're currently planning to retain the existing behavior of
GeneralizedNewtypeDeriving with regards to Safe Haskell. That is, Safe
Haskell and GND still won't mix in 7.8 due to these same security concerns.

I think a key observation with regards to GeneralizedNewtypeDeriving is
with representational roles as default the new roles machinery with the
representational default lets you write nothing you couldn't write before.
No new security vulnerabilities are introduced. They were there all along!

We're also disabling the Safe flag on Data.Coerce. In that light, `coerce`
then can be viewed as a more friendly but still evil version of
unsafeCoerce. It lets you write nothing you couldn't write before with
`unsafeCoerce`. I view it as merely an occasional situational improvement
over the existing unsafeCoerce in that it at least enforces
representational equality.

Making the default role annotation nominal comes at a very very real cost.
Namely, *all* of generalized newtype deriving anywhere breaks, and everyone
forever will have to put annotations in to fix it.

The 'backwards' representational default puts the burden on a small
minority of library authors.

I'm not a huge fan of the representational machinery, in that it hoists us
upon this dilemma, but given the choice between everyone paying in
perpetuity and a small minority of skilled library authors adding a handful
of annotations that for the most part have already been added, and which
expose them to no more risk than they'd had before if they forget, I'm
definitely in favor of the current solution.

-Edward

On Mon, Mar 24, 2014 at 11:26 AM, Mark Lentczner
<mark.lentczner at gmail.com>wrote:

> Thanks for the pointers, Simon. I appologize for coming to this quite so
> late... I didn't realize the global impact of this feature.
>
> From a "meaning" perspective, I'm agnostic on the default.
> From a "engineering" perspective, I want a default that "does a good
> enough, reasonably safe thing" if programmers ignore the feature.
>
> The later is subtle as there are different vantage points for different
> developers. In the Platform, we have many libraries that we are encouraging
> both end-programmers, and other library authors to make use of and depend
> on extensively. This means those libraries have to work for both
> programmers that are ignoring the feature, and those that use it. In that
> later case, there is the even more subtle distinction of those that use the
> feature for their own code, and those that use it in libraries they make
> available.
>
> The later case is issue: It seems a real mess if a library author who
> wanted to use the new feature, had to circumvent a HP library because it
> didn't annotate. Similar thought experiment: What would be the downside if
> containers didn't annotate? Would that just make the feature unusable
> because everything uses containers?
>
> To put it more directly: with the satus-quo default of representations,
> what is the down side if a library, a widely used library, doesn't bother
> to annotate? What would be the loss if containers didn't annotate? (I know
> it did, this is the thought experiment... because I've got 30+ libraries in
> HP that are in this boat.)
>
>
> _______________________________________________
> Libraries mailing list
> Libraries at haskell.org
> http://www.haskell.org/mailman/listinfo/libraries
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/ghc-devs/attachments/20140324/c4230c12/attachment.html>

From ekmett at gmail.com  Mon Mar 24 19:21:05 2014
From: ekmett at gmail.com (Edward Kmett)
Date: Mon, 24 Mar 2014 15:21:05 -0400
Subject: We need to add role annotations for 7.8
In-Reply-To: <CAAOoiFag0mf7uUJoFzw2-zOWN+J=KStRfnCevSxRiZy0Pg=Uvg@mail.gmail.com>
References: <78518EC7-BC18-4732-90B6-1AB37048D2A3@cis.upenn.edu>
 <CAK-tuPY0G0ceKK=mNp1N2H-h8S1sN47rahd2OmAXU3RrP-zukQ@mail.gmail.com>
 <CALjd_v5pCBQv4qXAm3E4_qSp8NRLjq1BKV1dJejymsUhruDReQ@mail.gmail.com>
 <CALjd_v6Ar4BVyWyYjpYDy-2UO78tVC3uOcdVyVSSpvi8M-oE9Q@mail.gmail.com>
 <CAEs96n1Xxp9qmXLBf6XqKbLH3kEE3bVLcpLAuFHoVip0N+1D=w@mail.gmail.com>
 <CAEs96n1dVs8SC6an_5eCsx1aCPwbNjbahhNrKAeaSCv1=Qe3gw@mail.gmail.com>
 <CAEs96n0SCjD6_C7VkeL0NUCY+v-fZseeL=iRFZG9fL9b74AjwQ@mail.gmail.com>
 <CAEs96n1WnrVtyjk2f3jOgUZg2M4EwPSA-9bnN6+9dL1p+=Ea0w@mail.gmail.com>
 <CAK-tuPahbPSd4fxjRCMKHYPcsPuzsM3CnBFMBvkoYbAZkVmmjw@mail.gmail.com>
 <CAAOoiFZKYXzqdfS1PVfG4W_H9ig8iw3MrcTFWu5GrP4C6sgEoA@mail.gmail.com>
 <CAKFCL4Xz_W9of6SyXBsFfk+6Kp4E=T7pjPt4ZhqjqqY9wsixkw@mail.gmail.com>
 <59543203684B2244980D7E4057D5FBC1488BA55B@DB3EX14MBXC308.europe.corp.microsoft.com>
 <CAAOoiFaof89nQBRStVD38hmHQbBeNNQOU1+YEdaq_iwieKgGJA@mail.gmail.com>
 <CAAOoiFag0mf7uUJoFzw2-zOWN+J=KStRfnCevSxRiZy0Pg=Uvg@mail.gmail.com>
Message-ID: <CAJumaK9ubCMRBcx3_1knJY=GRR_EN9gZOkrMEnL+HVeW0X1AsQ@mail.gmail.com>

This puts the constraint on the wrong thing.

I did argue for a pragma-like syntax for the annotations when they were
first proposed, as the need for library authors to hide these behind CPP
pragmas bothers me a great deal, but I think for better or worse that
syntax decision is largely behind us.



A type-class driven approach does have some promise, but that said, it
can't look like what you've written.

What you've written:

data Nominal k => Map k a

is saying something about the argument k, not about if you can turn
Map kinto Map
k', which is actually about Map, k is just along for the ride.

Really what we're talking about is that the next argument is
representational as applied. Also, the right 'open world' version would be
to talk about it as classes would be:

class Representational t where
  rep :: Coercion a b -> Coercion (t a) (t b)

class Representational t => Phantom t where
  phantom :: Coercion (t a) (t b)

With "Nominal" simply being the absence of either of those instances.

data Map k a

would need

instance Representational (Map k)

since the 'a' can be coerced as it has a representational role.

instance Representational (->)
instance Representational ((->) a)

But there are actually still open issues I don't know how to solve, even
with this approach.

-Edward


On Mon, Mar 24, 2014 at 11:36 AM, Mark Lentczner
<mark.lentczner at gmail.com>wrote:

> Again, sorry for the 11:59 meddling....
>
> The syntax of role annotations is very heavy weight, and requires lots of
> CPP where there wasn't need before.  Two thoughts:
>
> 1) Couldn't we do something like use "cue" type constraints? For example,
> assuming the default is representational, and that phantom can just be
> inferred, all we need is a way to indicate nominal:
>
> data (Nominal k) => Map k v = ...
>
>
> This could then probably be easily made to compile in other compilers with
> some null library implementation of Nominal
>
> 2) An alternative to the above. We generally frown on constraints in a
> data / newtype declaration, but perhaps this is exactly the case for them,
> whereby we can now do away with the type role syntax: We can infer nominal
> if there are *any* constraints on a type parameter, *representational* if
> there are none, and *phantom *if there are no mentions in the right hand
> side:
>
> data (Eq k) => Map k v = ...
>
>
> This seems even nicer and just works with all compilers... but perhaps I'm
> missing something. (Yes, I imagine there are type constraints that
> shouldn't force nominal, but perhaps not worth worrying about?)
>
>
> Mind you, this all just about syntax... the issue of what is the
> implication for libraries of the default being representational is still at
> hand.
> ?
>
> _______________________________________________
> ghc-devs mailing list
> ghc-devs at haskell.org
> http://www.haskell.org/mailman/listinfo/ghc-devs
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/ghc-devs/attachments/20140324/c8c84f93/attachment-0001.html>

From the.dead.shall.rise at gmail.com  Mon Mar 24 21:26:42 2014
From: the.dead.shall.rise at gmail.com (Mikhail Glushenkov)
Date: Mon, 24 Mar 2014 22:26:42 +0100
Subject: module 'free-4.6.1:Main' is defined in multiple files
In-Reply-To: <53307151.9010800@fuuzetsu.co.uk>
References: <53307151.9010800@fuuzetsu.co.uk>
Message-ID: <CA+tcxkDApQ7FNt5UbVnfj9LK2Q=42aNiLDa_rzJmUVn0OA1Mfw@mail.gmail.com>

Hi,

On 24 March 2014 18:54, Mateusz Kowalczyk <fuuzetsu at fuuzetsu.co.uk> wrote:
>
> PS: How does one go about downgrading Cabal and cabal-install? If we
> wanted to check whether cabal is the problem, how?

You can force the Cabal lib version to use (in case you have multiple
versions installed) with 'install --cabal-lib-version'. To downgrade
cabal-install itself to some older version you need to compile and
install that version.

From austin at well-typed.com  Mon Mar 24 21:36:10 2014
From: austin at well-typed.com (Austin Seipp)
Date: Mon, 24 Mar 2014 16:36:10 -0500
Subject: 7.8.1 plan
Message-ID: <CAEs96n3RWy6=xZo6Ogd=pqQ1FQbOK9JEKMzUvO5FAqxJQ7rX-g@mail.gmail.com>

Hello all,

As I'm sure you're all aware, it's the final countdown. The (final)
source distribution will be up within a few hours, and then we'll
continue on from there. Yay! I will post an update when that is, so
Gabor/Luke/Karel can make binaries from the sources as I do so.

Second, there are just two things I want to note:

  - For people following the Windows debacle in #8834, there has been
a bug fixed, but one may still remain. The TL;DR of this is that we
currently have a committed workaround in place we'll keep using, but
Simon has made some good steps towards finding the bug.

  - Lots of people, I'm sure, are wondering what's going on with Safe
Haskell and the GND story. The TL;DR of this one is that "everything
will be the same as in 7.6" - GND is considered an Unsafe feature, and
Data.Coerce is behind Unsafe bars. From a safety point of view,
nothing should change for library authors I cherry picked these
changes into 7.8 last night.

In the mean time, the 7.8 branch is effectively closed. If you have
something to commit, and I *really* mean something, you can let me
know. But your deadline is hours, not days! I'm doing a final review
of all the trees before pushing the library tags, and after that I'll
begin rolling the sdist.

Anyway, the time is finally here, so let's get it over with!

-- 
Regards,

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

From simonpj at microsoft.com  Mon Mar 24 22:57:03 2014
From: simonpj at microsoft.com (Simon Peyton Jones)
Date: Mon, 24 Mar 2014 22:57:03 +0000
Subject: We need to add role annotations for 7.8
In-Reply-To: <CAJumaK_-dxYW=raqvCyfp1h-9XFwj2eKq_smWHng=DuUChfZ4w@mail.gmail.com>
References: <78518EC7-BC18-4732-90B6-1AB37048D2A3@cis.upenn.edu>
 <CAK-tuPY0G0ceKK=mNp1N2H-h8S1sN47rahd2OmAXU3RrP-zukQ@mail.gmail.com>
 <CALjd_v5pCBQv4qXAm3E4_qSp8NRLjq1BKV1dJejymsUhruDReQ@mail.gmail.com>
 <CALjd_v6Ar4BVyWyYjpYDy-2UO78tVC3uOcdVyVSSpvi8M-oE9Q@mail.gmail.com>
 <CAEs96n1Xxp9qmXLBf6XqKbLH3kEE3bVLcpLAuFHoVip0N+1D=w@mail.gmail.com>
 <CAEs96n1dVs8SC6an_5eCsx1aCPwbNjbahhNrKAeaSCv1=Qe3gw@mail.gmail.com>
 <CAEs96n0SCjD6_C7VkeL0NUCY+v-fZseeL=iRFZG9fL9b74AjwQ@mail.gmail.com>
 <CAEs96n1WnrVtyjk2f3jOgUZg2M4EwPSA-9bnN6+9dL1p+=Ea0w@mail.gmail.com>
 <CAK-tuPahbPSd4fxjRCMKHYPcsPuzsM3CnBFMBvkoYbAZkVmmjw@mail.gmail.com>
 <CAAOoiFZKYXzqdfS1PVfG4W_H9ig8iw3MrcTFWu5GrP4C6sgEoA@mail.gmail.com>
 <CAKFCL4Xz_W9of6SyXBsFfk+6Kp4E=T7pjPt4ZhqjqqY9wsixkw@mail.gmail.com>
 <59543203684B2244980D7E4057D5FBC1488BA55B@DB3EX14MBXC308.europe.corp.microsoft.com>
 <CAAOoiFaof89nQBRStVD38hmHQbBeNNQOU1+YEdaq_iwieKgGJA@mail.gmail.com>
 <CAJumaK_-dxYW=raqvCyfp1h-9XFwj2eKq_smWHng=DuUChfZ4w@mail.gmail.com>
Message-ID: <59543203684B2244980D7E4057D5FBC1488BB740@DB3EX14MBXC308.europe.corp.microsoft.com>

In that light, `coerce` then can be viewed as a more friendly but still evil version of unsafeCoerce

Coerce embodies one rather compelling improvement: it is type-sound.  unsafeCoerce can cause arbitrary seg-faults etc.  ?coerce? cannot.  Call me an old-fashioned ?well-typed programs don?t go wrong? man, but I think that?s a big plus.  Much more than ?an occasional situation improvement?.

Granted, ?type-sound? doesn?t guarantee ?correct?, but then it never did.

The role machinery doesn?t exactly hoist us on a dilemma ? it merely exposes the dilemma that was there all the time.

Simon

From: Edward Kmett [mailto:ekmett at gmail.com]
Sent: 24 March 2014 19:11
To: Mark Lentczner
Cc: Simon Peyton Jones; libraries at haskell.org Libraries; ghc-devs at haskell.org
Subject: Re: We need to add role annotations for 7.8

Mark,

We're currently planning to retain the existing behavior of GeneralizedNewtypeDeriving with regards to Safe Haskell. That is, Safe Haskell and GND still won't mix in 7.8 due to these same security concerns.

I think a key observation with regards to GeneralizedNewtypeDeriving is with representational roles as default the new roles machinery with the representational default lets you write nothing you couldn't write before. No new security vulnerabilities are introduced. They were there all along!

We're also disabling the Safe flag on Data.Coerce. In that light, `coerce` then can be viewed as a more friendly but still evil version of unsafeCoerce. It lets you write nothing you couldn't write before with `unsafeCoerce`. I view it as merely an occasional situational improvement over the existing unsafeCoerce in that it at least enforces representational equality.

Making the default role annotation nominal comes at a very very real cost. Namely, all of generalized newtype deriving anywhere breaks, and everyone forever will have to put annotations in to fix it.

The 'backwards' representational default puts the burden on a small minority of library authors.

I'm not a huge fan of the representational machinery, in that it hoists us upon this dilemma, but given the choice between everyone paying in perpetuity and a small minority of skilled library authors adding a handful of annotations that for the most part have already been added, and which expose them to no more risk than they'd had before if they forget, I'm definitely in favor of the current solution.

-Edward

On Mon, Mar 24, 2014 at 11:26 AM, Mark Lentczner <mark.lentczner at gmail.com<mailto:mark.lentczner at gmail.com>> wrote:
Thanks for the pointers, Simon. I appologize for coming to this quite so late... I didn't realize the global impact of this feature.

From a "meaning" perspective, I'm agnostic on the default.
From a "engineering" perspective, I want a default that "does a good enough, reasonably safe thing" if programmers ignore the feature.

The later is subtle as there are different vantage points for different developers. In the Platform, we have many libraries that we are encouraging both end-programmers, and other library authors to make use of and depend on extensively. This means those libraries have to work for both programmers that are ignoring the feature, and those that use it. In that later case, there is the even more subtle distinction of those that use the feature for their own code, and those that use it in libraries they make available.

The later case is issue: It seems a real mess if a library author who wanted to use the new feature, had to circumvent a HP library because it didn't annotate. Similar thought experiment: What would be the downside if containers didn't annotate? Would that just make the feature unusable because everything uses containers?

To put it more directly: with the satus-quo default of representations, what is the down side if a library, a widely used library, doesn't bother to annotate? What would be the loss if containers didn't annotate? (I know it did, this is the thought experiment... because I've got 30+ libraries in HP that are in this boat.)


_______________________________________________
Libraries mailing list
Libraries at haskell.org<mailto:Libraries at haskell.org>
http://www.haskell.org/mailman/listinfo/libraries

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/ghc-devs/attachments/20140324/ff07f8a3/attachment-0001.html>

From chak at cse.unsw.edu.au  Tue Mar 25 00:13:33 2014
From: chak at cse.unsw.edu.au (Manuel M T Chakravarty)
Date: Tue, 25 Mar 2014 11:13:33 +1100
Subject: 7.8.1 plan
In-Reply-To: <CAEs96n3RWy6=xZo6Ogd=pqQ1FQbOK9JEKMzUvO5FAqxJQ7rX-g@mail.gmail.com>
References: <CAEs96n3RWy6=xZo6Ogd=pqQ1FQbOK9JEKMzUvO5FAqxJQ7rX-g@mail.gmail.com>
Message-ID: <C0D01305-3C1C-4FC2-9BFE-DE51035C7414@cse.unsw.edu.au>

Awesome! Thanks for all the hard work!!

Manuel

Austin Seipp <austin at well-typed.com>:
> Hello all,
> 
> As I'm sure you're all aware, it's the final countdown. The (final)
> source distribution will be up within a few hours, and then we'll
> continue on from there. Yay! I will post an update when that is, so
> Gabor/Luke/Karel can make binaries from the sources as I do so.
> 
> Second, there are just two things I want to note:
> 
>  - For people following the Windows debacle in #8834, there has been
> a bug fixed, but one may still remain. The TL;DR of this is that we
> currently have a committed workaround in place we'll keep using, but
> Simon has made some good steps towards finding the bug.
> 
>  - Lots of people, I'm sure, are wondering what's going on with Safe
> Haskell and the GND story. The TL;DR of this one is that "everything
> will be the same as in 7.6" - GND is considered an Unsafe feature, and
> Data.Coerce is behind Unsafe bars. From a safety point of view,
> nothing should change for library authors I cherry picked these
> changes into 7.8 last night.
> 
> In the mean time, the 7.8 branch is effectively closed. If you have
> something to commit, and I *really* mean something, you can let me
> know. But your deadline is hours, not days! I'm doing a final review
> of all the trees before pushing the library tags, and after that I'll
> begin rolling the sdist.
> 
> Anyway, the time is finally here, so let's get it over with!
> 
> -- 
> Regards,
> 
> Austin Seipp, Haskell Consultant
> Well-Typed LLP, http://www.well-typed.com/
> _______________________________________________
> ghc-devs mailing list
> ghc-devs at haskell.org
> http://www.haskell.org/mailman/listinfo/ghc-devs


From carter.schonwald at gmail.com  Tue Mar 25 01:02:32 2014
From: carter.schonwald at gmail.com (Carter Schonwald)
Date: Mon, 24 Mar 2014 21:02:32 -0400
Subject: 7.8.1 plan
In-Reply-To: <C0D01305-3C1C-4FC2-9BFE-DE51035C7414@cse.unsw.edu.au>
References: <CAEs96n3RWy6=xZo6Ogd=pqQ1FQbOK9JEKMzUvO5FAqxJQ7rX-g@mail.gmail.com>
 <C0D01305-3C1C-4FC2-9BFE-DE51035C7414@cse.unsw.edu.au>
Message-ID: <CAHYVw0zYS2JZ7WZKQRRn4x_+9mg3bWu0JnJp8n1VQsBSG7-XaQ@mail.gmail.com>

i second that


On Mon, Mar 24, 2014 at 8:13 PM, Manuel M T Chakravarty <
chak at cse.unsw.edu.au> wrote:

> Awesome! Thanks for all the hard work!!
>
> Manuel
>
> Austin Seipp <austin at well-typed.com>:
> > Hello all,
> >
> > As I'm sure you're all aware, it's the final countdown. The (final)
> > source distribution will be up within a few hours, and then we'll
> > continue on from there. Yay! I will post an update when that is, so
> > Gabor/Luke/Karel can make binaries from the sources as I do so.
> >
> > Second, there are just two things I want to note:
> >
> >  - For people following the Windows debacle in #8834, there has been
> > a bug fixed, but one may still remain. The TL;DR of this is that we
> > currently have a committed workaround in place we'll keep using, but
> > Simon has made some good steps towards finding the bug.
> >
> >  - Lots of people, I'm sure, are wondering what's going on with Safe
> > Haskell and the GND story. The TL;DR of this one is that "everything
> > will be the same as in 7.6" - GND is considered an Unsafe feature, and
> > Data.Coerce is behind Unsafe bars. From a safety point of view,
> > nothing should change for library authors I cherry picked these
> > changes into 7.8 last night.
> >
> > In the mean time, the 7.8 branch is effectively closed. If you have
> > something to commit, and I *really* mean something, you can let me
> > know. But your deadline is hours, not days! I'm doing a final review
> > of all the trees before pushing the library tags, and after that I'll
> > begin rolling the sdist.
> >
> > Anyway, the time is finally here, so let's get it over with!
> >
> > --
> > Regards,
> >
> > Austin Seipp, Haskell Consultant
> > Well-Typed LLP, http://www.well-typed.com/
> > _______________________________________________
> > ghc-devs mailing list
> > ghc-devs at haskell.org
> > http://www.haskell.org/mailman/listinfo/ghc-devs
>
> _______________________________________________
> ghc-devs mailing list
> ghc-devs at haskell.org
> http://www.haskell.org/mailman/listinfo/ghc-devs
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/ghc-devs/attachments/20140324/81034c72/attachment.html>

From ekmett at gmail.com  Tue Mar 25 01:32:59 2014
From: ekmett at gmail.com (Edward A Kmett)
Date: Mon, 24 Mar 2014 21:32:59 -0400
Subject: We need to add role annotations for 7.8
In-Reply-To: <59543203684B2244980D7E4057D5FBC1488BB740@DB3EX14MBXC308.europe.corp.microsoft.com>
References: <78518EC7-BC18-4732-90B6-1AB37048D2A3@cis.upenn.edu>
 <CAK-tuPY0G0ceKK=mNp1N2H-h8S1sN47rahd2OmAXU3RrP-zukQ@mail.gmail.com>
 <CALjd_v5pCBQv4qXAm3E4_qSp8NRLjq1BKV1dJejymsUhruDReQ@mail.gmail.com>
 <CALjd_v6Ar4BVyWyYjpYDy-2UO78tVC3uOcdVyVSSpvi8M-oE9Q@mail.gmail.com>
 <CAEs96n1Xxp9qmXLBf6XqKbLH3kEE3bVLcpLAuFHoVip0N+1D=w@mail.gmail.com>
 <CAEs96n1dVs8SC6an_5eCsx1aCPwbNjbahhNrKAeaSCv1=Qe3gw@mail.gmail.com>
 <CAEs96n0SCjD6_C7VkeL0NUCY+v-fZseeL=iRFZG9fL9b74AjwQ@mail.gmail.com>
 <CAEs96n1WnrVtyjk2f3jOgUZg2M4EwPSA-9bnN6+9dL1p+=Ea0w@mail.gmail.com>
 <CAK-tuPahbPSd4fxjRCMKHYPcsPuzsM3CnBFMBvkoYbAZkVmmjw@mail.gmail.com>
 <CAAOoiFZKYXzqdfS1PVfG4W_H9ig8iw3MrcTFWu5GrP4C6sgEoA@mail.gmail.com>
 <CAKFCL4Xz_W9of6SyXBsFfk+6Kp4E=T7pjPt4ZhqjqqY9wsixkw@mail.gmail.com>
 <59543203684B2244980D7E4057D5FBC1488BA55B@DB3EX14MBXC308.europe.corp.microsoft.com>
 <CAAOoiFaof89nQBRStVD38hmHQbBeNNQOU1+YEdaq_iwieKgGJA@mail.gmail.com>
 <CAJumaK_-dxYW=raqvCyfp1h-9XFwj2eKq_smWHng=DuUChfZ4w@mail.gmail.com>
 <59543203684B2244980D7E4057D5FBC1488BB740@DB3EX14MBXC308.europe.corp.microsoft.com>
Message-ID: <2F1D91F2-0AD6-4E98-81E3-9A95E6024BA3@gmail.com>

Fair enough. I did try to convey that in the following sentence about how it at least enforces representational equality, but I can see how my statement might be taken as understating the importance of that property.

Sent from my iPhone

> On Mar 24, 2014, at 6:57 PM, Simon Peyton Jones <simonpj at microsoft.com> wrote:
> 
> In that light, `coerce` then can be viewed as a more friendly but still evil version of unsafeCoerce
>  
> Coerce embodies one rather compelling improvement: it is type-sound.  unsafeCoerce can cause arbitrary seg-faults etc.  ?coerce? cannot.  Call me an old-fashioned ?well-typed programs don?t go wrong? man, but I think that?s a big plus.  Much more than ?an occasional situation improvement?.
>  
> Granted, ?type-sound? doesn?t guarantee ?correct?, but then it never did.
>  
> The role machinery doesn?t exactly hoist us on a dilemma ? it merely exposes the dilemma that was there all the time.
>  
> Simon
>  
> From: Edward Kmett [mailto:ekmett at gmail.com] 
> Sent: 24 March 2014 19:11
> To: Mark Lentczner
> Cc: Simon Peyton Jones; libraries at haskell.org Libraries; ghc-devs at haskell.org
> Subject: Re: We need to add role annotations for 7.8
>  
> Mark,
> 
>  
> 
> We're currently planning to retain the existing behavior of GeneralizedNewtypeDeriving with regards to Safe Haskell. That is, Safe Haskell and GND still won't mix in 7.8 due to these same security concerns.
> 
>  
> 
> I think a key observation with regards to GeneralizedNewtypeDeriving is with representational roles as default the new roles machinery with the representational default lets you write nothing you couldn't write before. No new security vulnerabilities are introduced. They were there all along!
> 
>  
> 
> We're also disabling the Safe flag on Data.Coerce. In that light, `coerce` then can be viewed as a more friendly but still evil version of unsafeCoerce. It lets you write nothing you couldn't write before with `unsafeCoerce`. I view it as merely an occasional situational improvement over the existing unsafeCoerce in that it at least enforces representational equality.
> 
>  
> 
> Making the default role annotation nominal comes at a very very real cost. Namely, all of generalized newtype deriving anywhere breaks, and everyone forever will have to put annotations in to fix it.
> 
>  
> 
> The 'backwards' representational default puts the burden on a small minority of library authors.
> 
>  
> 
> I'm not a huge fan of the representational machinery, in that it hoists us upon this dilemma, but given the choice between everyone paying in perpetuity and a small minority of skilled library authors adding a handful of annotations that for the most part have already been added, and which expose them to no more risk than they'd had before if they forget, I'm definitely in favor of the current solution.
> 
>  
> 
> -Edward
> 
>  
> 
> On Mon, Mar 24, 2014 at 11:26 AM, Mark Lentczner <mark.lentczner at gmail.com> wrote:
> 
> Thanks for the pointers, Simon. I appologize for coming to this quite so late... I didn't realize the global impact of this feature.
> 
>  
> 
> From a "meaning" perspective, I'm agnostic on the default.
> 
> From a "engineering" perspective, I want a default that "does a good enough, reasonably safe thing" if programmers ignore the feature.
> 
>  
> 
> The later is subtle as there are different vantage points for different developers. In the Platform, we have many libraries that we are encouraging both end-programmers, and other library authors to make use of and depend on extensively. This means those libraries have to work for both programmers that are ignoring the feature, and those that use it. In that later case, there is the even more subtle distinction of those that use the feature for their own code, and those that use it in libraries they make available.
> 
>  
> 
> The later case is issue: It seems a real mess if a library author who wanted to use the new feature, had to circumvent a HP library because it didn't annotate. Similar thought experiment: What would be the downside if containers didn't annotate? Would that just make the feature unusable because everything uses containers? 
> 
>  
> 
> To put it more directly: with the satus-quo default of representations, what is the down side if a library, a widely used library, doesn't bother to annotate? What would be the loss if containers didn't annotate? (I know it did, this is the thought experiment... because I've got 30+ libraries in HP that are in this boat.)
> 
>  
> 
> 
> _______________________________________________
> Libraries mailing list
> Libraries at haskell.org
> http://www.haskell.org/mailman/listinfo/libraries
> 
>  
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/ghc-devs/attachments/20140324/d725062a/attachment-0001.html>

From eir at cis.upenn.edu  Tue Mar 25 03:26:36 2014
From: eir at cis.upenn.edu (Richard Eisenberg)
Date: Mon, 24 Mar 2014 23:26:36 -0400
Subject: We need to add role annotations for 7.8
In-Reply-To: <2F1D91F2-0AD6-4E98-81E3-9A95E6024BA3@gmail.com>
References: <78518EC7-BC18-4732-90B6-1AB37048D2A3@cis.upenn.edu>
 <CAK-tuPY0G0ceKK=mNp1N2H-h8S1sN47rahd2OmAXU3RrP-zukQ@mail.gmail.com>
 <CALjd_v5pCBQv4qXAm3E4_qSp8NRLjq1BKV1dJejymsUhruDReQ@mail.gmail.com>
 <CALjd_v6Ar4BVyWyYjpYDy-2UO78tVC3uOcdVyVSSpvi8M-oE9Q@mail.gmail.com>
 <CAEs96n1Xxp9qmXLBf6XqKbLH3kEE3bVLcpLAuFHoVip0N+1D=w@mail.gmail.com>
 <CAEs96n1dVs8SC6an_5eCsx1aCPwbNjbahhNrKAeaSCv1=Qe3gw@mail.gmail.com>
 <CAEs96n0SCjD6_C7VkeL0NUCY+v-fZseeL=iRFZG9fL9b74AjwQ@mail.gmail.com>
 <CAEs96n1WnrVtyjk2f3jOgUZg2M4EwPSA-9bnN6+9dL1p+=Ea0w@mail.gmail.com>
 <CAK-tuPahbPSd4fxjRCMKHYPcsPuzsM3CnBFMBvkoYbAZkVmmjw@mail.gmail.com>
 <CAAOoiFZKYXzqdfS1PVfG4W_H9ig8iw3MrcTFWu5GrP4C6sgEoA@mail.gmail.com>
 <CAKFCL4Xz_W9of6SyXBsFfk+6Kp4E=T7pjPt4ZhqjqqY9wsixkw@mail.gmail.com>
 <59543203684B2244980D7E4057D5FBC1488BA55B@DB3EX14MBXC308.europe.corp.microsoft.com>
 <CAAOoiFaof89nQBRStVD38hmHQbBeNNQOU1+YEdaq_iwieKgGJA@mail.gmail.com>
 <CAJumaK_-dxYW=raqvCyfp1h-9XFwj2eKq_smWHng=DuUChfZ4w@mail.gmail.com>
 <59543203684!
 B2244980D7E4057D5FBC1488BB740@DB3EX14MBXC308.europe.corp.microsoft.com>
 <2F1D91F2-0AD6-4E98-81E3-9A95E6024BA3@gmail.com>
Message-ID: <8FD54493-CC52-4B90-9DD2-E7C91024FC30@cis.upenn.edu>

I have a few responses to various themes in this thread, but nothing terribly unexpected:

- The introduction of roles is the end of the story that began with the discovery of bug #1496. The alternative would be to do away with GND. `coerce` is just a convenient application of roles, not the reason they were introduced.

- The concrete syntax for role ascriptions was debated in public, in bug #8185. There is further discussion of the design choice in the appendix of the extended version of our recent draft paper on the subject: www.cis.upenn.edu/~eir/papers/2014/coercible/coercible-ext.pdf  I'm afraid it's too late now to make changes. I don't love what we ended up with, but I believe it's the best syntax that was proposed.

- I agree with Simon that `coerce` is quite a bit safer than `unsafeCoerce`. Under the assumption that all libraries are written correctly (that is, with proper role annotations), `coerce` is in fact fully safe.

- I surely recognize why and how this causes a Major Pain for Mark, and for other library maintainers. I wish there were an easier solution. However, I will perhaps repeat others in saying that a library that doesn't add role annotations is no more wrong in 7.8 than it was since GND was introduced. The only difference with 7.8 is that, now, there is a way to be right.

Richard

On Mar 24, 2014, at 9:32 PM, Edward A Kmett wrote:

> Fair enough. I did try to convey that in the following sentence about how it at least enforces representational equality, but I can see how my statement might be taken as understating the importance of that property.
> 
> Sent from my iPhone
> 
> On Mar 24, 2014, at 6:57 PM, Simon Peyton Jones <simonpj at microsoft.com> wrote:
> 
>> In that light, `coerce` then can be viewed as a more friendly but still evil version of unsafeCoerce
>>  
>> Coerce embodies one rather compelling improvement: it is type-sound.  unsafeCoerce can cause arbitrary seg-faults etc.  ?coerce? cannot.  Call me an old-fashioned ?well-typed programs don?t go wrong? man, but I think that?s a big plus.  Much more than ?an occasional situation improvement?.
>>  
>> Granted, ?type-sound? doesn?t guarantee ?correct?, but then it never did.
>>  
>> The role machinery doesn?t exactly hoist us on a dilemma ? it merely exposes the dilemma that was there all the time.
>>  
>> Simon
>>  
>> From: Edward Kmett [mailto:ekmett at gmail.com] 
>> Sent: 24 March 2014 19:11
>> To: Mark Lentczner
>> Cc: Simon Peyton Jones; libraries at haskell.org Libraries; ghc-devs at haskell.org
>> Subject: Re: We need to add role annotations for 7.8
>>  
>> Mark,
>> 
>>  
>> 
>> We're currently planning to retain the existing behavior of GeneralizedNewtypeDeriving with regards to Safe Haskell. That is, Safe Haskell and GND still won't mix in 7.8 due to these same security concerns.
>> 
>>  
>> 
>> I think a key observation with regards to GeneralizedNewtypeDeriving is with representational roles as default the new roles machinery with the representational default lets you write nothing you couldn't write before. No new security vulnerabilities are introduced. They were there all along!
>> 
>>  
>> 
>> We're also disabling the Safe flag on Data.Coerce. In that light, `coerce` then can be viewed as a more friendly but still evil version of unsafeCoerce. It lets you write nothing you couldn't write before with `unsafeCoerce`. I view it as merely an occasional situational improvement over the existing unsafeCoerce in that it at least enforces representational equality.
>> 
>>  
>> 
>> Making the default role annotation nominal comes at a very very real cost. Namely, all of generalized newtype deriving anywhere breaks, and everyone forever will have to put annotations in to fix it.
>> 
>>  
>> 
>> The 'backwards' representational default puts the burden on a small minority of library authors.
>> 
>>  
>> 
>> I'm not a huge fan of the representational machinery, in that it hoists us upon this dilemma, but given the choice between everyone paying in perpetuity and a small minority of skilled library authors adding a handful of annotations that for the most part have already been added, and which expose them to no more risk than they'd had before if they forget, I'm definitely in favor of the current solution.
>> 
>>  
>> 
>> -Edward
>> 
>>  
>> 
>> On Mon, Mar 24, 2014 at 11:26 AM, Mark Lentczner <mark.lentczner at gmail.com> wrote:
>> 
>> Thanks for the pointers, Simon. I appologize for coming to this quite so late... I didn't realize the global impact of this feature.
>> 
>>  
>> 
>> From a "meaning" perspective, I'm agnostic on the default.
>> 
>> From a "engineering" perspective, I want a default that "does a good enough, reasonably safe thing" if programmers ignore the feature.
>> 
>>  
>> 
>> The later is subtle as there are different vantage points for different developers. In the Platform, we have many libraries that we are encouraging both end-programmers, and other library authors to make use of and depend on extensively. This means those libraries  have to work for both programmers that are ignoring the feature, and those that use it. In that later case, there is the even more subtle distinction of those that use the feature for their own code, and those that use it in libraries they make available.
>> 
>>  
>> 
>> The later case is issue: It seems a real mess if a library author who wanted to use the new feature, had to circumvent a HP library because it didn't annotate. Similar thought experiment: What would be the downside if containers didn't annotate? Would that just make the feature unusable because everything uses containers? 
>> 
>>  
>> 
>> To put it more directly: with the satus-quo default of representations, what is the down side if a library, a widely used library, doesn't bother to annotate? What would be the loss if containers didn't annotate? (I know it did, this is the thought experiment... because I've got 30+ libraries in HP that are in this boat.)
>> 
>>  
>> 
>> 
>> _______________________________________________
>> Libraries mailing list
>> Libraries at haskell.org
>> http://www.haskell.org/mailman/listinfo/libraries
>> 
>>  
>> 
> _______________________________________________
> Libraries mailing list
> Libraries at haskell.org
> http://www.haskell.org/mailman/listinfo/libraries

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/ghc-devs/attachments/20140324/3d44ab43/attachment.html>

From kyrab at mail.ru  Tue Mar 25 06:01:56 2014
From: kyrab at mail.ru (kyra)
Date: Tue, 25 Mar 2014 10:01:56 +0400
Subject: 7.8.1 plan
In-Reply-To: <CAEs96n3RWy6=xZo6Ogd=pqQ1FQbOK9JEKMzUvO5FAqxJQ7rX-g@mail.gmail.com>
References: <CAEs96n3RWy6=xZo6Ogd=pqQ1FQbOK9JEKMzUvO5FAqxJQ7rX-g@mail.gmail.com>
Message-ID: <53311BD4.3030008@mail.ru>

Will it include the latest commit to haddock? It solves this: 
http://trac.haskell.org/haddock/ticket/292. This can greatly improve 
performance of haddock in some situations (when a project is built with 
--split-obj flag).

Cheers,
Kyra

On 3/25/2014 01:36, Austin Seipp wrote:
> Hello all,
>
> As I'm sure you're all aware, it's the final countdown. The (final)
> source distribution will be up within a few hours, and then we'll
> continue on from there. Yay! I will post an update when that is, so
> Gabor/Luke/Karel can make binaries from the sources as I do so.
>
> Second, there are just two things I want to note:
>
>    - For people following the Windows debacle in #8834, there has been
> a bug fixed, but one may still remain. The TL;DR of this is that we
> currently have a committed workaround in place we'll keep using, but
> Simon has made some good steps towards finding the bug.
>
>    - Lots of people, I'm sure, are wondering what's going on with Safe
> Haskell and the GND story. The TL;DR of this one is that "everything
> will be the same as in 7.6" - GND is considered an Unsafe feature, and
> Data.Coerce is behind Unsafe bars. From a safety point of view,
> nothing should change for library authors I cherry picked these
> changes into 7.8 last night.
>
> In the mean time, the 7.8 branch is effectively closed. If you have
> something to commit, and I *really* mean something, you can let me
> know. But your deadline is hours, not days! I'm doing a final review
> of all the trees before pushing the library tags, and after that I'll
> begin rolling the sdist.
>
> Anyway, the time is finally here, so let's get it over with!
>


From hvr at gnu.org  Tue Mar 25 09:56:00 2014
From: hvr at gnu.org (Herbert Valerio Riedel)
Date: Tue, 25 Mar 2014 10:56:00 +0100
Subject: We need to add role annotations for 7.8
In-Reply-To: <53313E49.1040405@ifi.lmu.de> (Andreas Abel's message of "Tue, 25
 Mar 2014 09:28:57 +0100")
References: <78518EC7-BC18-4732-90B6-1AB37048D2A3@cis.upenn.edu>
 <CAEs96n1Xxp9qmXLBf6XqKbLH3kEE3bVLcpLAuFHoVip0N+1D=w@mail.gmail.com>
 <CAEs96n1dVs8SC6an_5eCsx1aCPwbNjbahhNrKAeaSCv1=Qe3gw@mail.gmail.com>
 <CAEs96n0SCjD6_C7VkeL0NUCY+v-fZseeL=iRFZG9fL9b74AjwQ@mail.gmail.com>
 <CAEs96n1WnrVtyjk2f3jOgUZg2M4EwPSA-9bnN6+9dL1p+=Ea0w@mail.gmail.com>
 <CAK-tuPahbPSd4fxjRCMKHYPcsPuzsM3CnBFMBvkoYbAZkVmmjw@mail.gmail.com>
 <CAAOoiFZKYXzqdfS1PVfG4W_H9ig8iw3MrcTFWu5GrP4C6sgEoA@mail.gmail.com>
 <CAKFCL4Xz_W9of6SyXBsFfk+6Kp4E=T7pjPt4ZhqjqqY9wsixkw@mail.gmail.com>
 <59543203684B2244980D7E4057D5FBC1488BA55B@DB3EX14MBXC308.europe.corp.microsoft.com>
 <CAAOoiFaof89nQBRStVD38hmHQbBeNNQOU1+YEdaq_iwieKgGJA@mail.gmail.com>
 <CAJumaK_-dxYW=raqvCyfp1h-9XFwj2eKq_smWHng=DuUChfZ4w@mail.gmail.com>
 <2F1D91F2-0AD6-4E98-81E3-9A95E6024BA3@gmail.com>
 <8FD54493-CC52-4B90-9DD2-E7C91024FC30@cis.upenn.edu>
 <53313E49.1040405@ifi.lmu.de>
Message-ID: <8761n2ob4f.fsf@gnu.org>

On 2014-03-25 at 09:28:57 +0100, Andreas Abel wrote:

[...]

> You might wanna pull the break before the release.

Fwiw, reverting the new syntax at this point also has an effect on
already officially released libraries such as
http://hackage.haskell.org/package/containers-0.5.5.1 which started
using the new non-pragma annotation[1]; so this would require new
hackage uploads (and maybe hackage-deprecations)... just saying...

 [1]: http://hdiff.luite.com/cgit/containers/commit?id=0.5.5.0

From mark.lentczner at gmail.com  Tue Mar 25 15:09:57 2014
From: mark.lentczner at gmail.com (Mark Lentczner)
Date: Tue, 25 Mar 2014 08:09:57 -0700
Subject: We need to add role annotations for 7.8
In-Reply-To: <533165DF.5030206@ifi.lmu.de>
References: <78518EC7-BC18-4732-90B6-1AB37048D2A3@cis.upenn.edu>
 <CAEs96n1Xxp9qmXLBf6XqKbLH3kEE3bVLcpLAuFHoVip0N+1D=w@mail.gmail.com>
 <CAEs96n1dVs8SC6an_5eCsx1aCPwbNjbahhNrKAeaSCv1=Qe3gw@mail.gmail.com>
 <CAEs96n0SCjD6_C7VkeL0NUCY+v-fZseeL=iRFZG9fL9b74AjwQ@mail.gmail.com>
 <CAEs96n1WnrVtyjk2f3jOgUZg2M4EwPSA-9bnN6+9dL1p+=Ea0w@mail.gmail.com>
 <CAK-tuPahbPSd4fxjRCMKHYPcsPuzsM3CnBFMBvkoYbAZkVmmjw@mail.gmail.com>
 <CAAOoiFZKYXzqdfS1PVfG4W_H9ig8iw3MrcTFWu5GrP4C6sgEoA@mail.gmail.com>
 <CAKFCL4Xz_W9of6SyXBsFfk+6Kp4E=T7pjPt4ZhqjqqY9wsixkw@mail.gmail.com>
 <59543203684B2244980D7E4057D5FBC1488BA55B@DB3EX14MBXC308.europe.corp.microsoft.com>
 <CAAOoiFaof89nQBRStVD38hmHQbBeNNQOU1+YEdaq_iwieKgGJA@mail.gmail.com>
 <CAJumaK_-dxYW=raqvCyfp1h-9XFwj2eKq_smWHng=DuUChfZ4w@mail.gmail.com>
 <2F1D91F2-0AD6-4E98-81E3-9A95E6024BA3@gmail.com>
 <8FD54493-CC52-4B90-9DD2-E7C91024FC30@cis.upenn.edu>
 <53313E49.1040405@ifi.lmu.de> <8761n2ob4f.fsf@gnu.org>
 <533165DF.5030206@ifi.lmu.de>
Message-ID: <CAAOoiFYJiGmpxPDYTbcHO107XxZMNRWpvMVZA5=waBv35oYR0g@mail.gmail.com>

Thank you to everyone who has been helping me understand this issue in
greater depth.

*tl;dr: As long as we don't expect any libraries beyond to core to
annotate, I'm cool. This presumes that the extra safety isn't, in practice,
dependent on transitive adoption by libraries. It also implies that
representational is the only possible default, and that there can be no
migration from it.*

My approach to thinking about this is guided by thinking about supporting
an eco-system with 1000s of libraries (hackage), a few dozen of which are
heavily promoted (the platform), and a small set that are closely tied to
the compiler (the core). The availability, speed of release, motivation,
and even skill of the the developers varies widely over that range.

I also think about the various "stances" of different developers:

   - *End developer*: makes use of libraries, but just builds apps
   - *Internal developer*: makes libraries for internal use in a project
   - *Casual library writer*: makes libraries, primarily for their own
   needs, but distributed on hackage
   - *Popular library writer:* actively maintains libraries which are
   widely used
   - *Core library writer: *maintainer of a core package that stays in lock
   step with the compiler

Then, I think about, for each of these, what is the effect on a new feature
on them, their existing code, and future code? Does it affect them only if
they are using the feature? If they aren't using the feature? For library
writers, how does the feature affect clients? If a client wants to use a
feature, under what conditions does the library need to do something? This
last issue of the "transitivity" the feature is often the biggest concern.

*Given that... onto type roles:*

The default of *representational* is the only option, because a default of
*nominal* would require far too many developers to have to update their
code. I don't believe that we can ever migrate to *nominal* as default.

The feature implies that any abstract data type that uses a type parameter
in certain ways needs annotate to get the full safety afforded now
afforded. However, without annotation, the data type is still no worse off
than it was before (there is added safety, but not perhaps relevant to the
stand point of the library writer). Further, this (pre-existing) non-safety
isn't likely a huge concern. Making sure the docs take the tone that most
developers need to nothing, and when developers need to be concerned seems
like an important way to ensure the right outcome.

A key question here is transitivity: Is it possible for module A to not
annotate a type, and then have module B by a different author use the type
in A in another abstract type, that *is* annotated, and get the benefit.
Seems the answer is "partially". If the answer were "no", then use of the
feature would be dependent on transitive adoption, and that is where the
big burden on developers comes from.

The degree to which we believe this "partially" is important: If we are
willing to believe that the only library writers we care about doing this
are those in the core, then fine. In this case we shouldn't feel compelled
to suggest to library writers that they annotate, ever. I'm good with this.
If the team here thinks otherwise, that we need to start a campaign to get
every library writer to eventually annotate, then I have deep objections.

I read the paper, and understand how the authors felt the syntax options
were all less than perfect, and choose what they did. But that choice,
perhaps unwittingly, the implication that it forces -XCPP on all libraries
except perhaps some of the core. This is because they all need to support
previous compilers. So, a one line annotation has turned into an ugly
beast, and perhaps added -XCPP where there was none, which is really
unfortunate. (I, like many, consider it a defeat when one has to resort to
-XCPP.)

It seems to me that the paper didn't really consider less-perfect,
heuristic solutions. It might have had significantly less impact on library
writers were some heuristic (no constructors exported? has any type
constraint on the parameter? etc..) might have allowed most data types to
go without annotation at the cost of a few (where *nominal* was incorrectly
inferred) requiring immediate action. In this situation, a non-language
feature (pragma or other device) might have been more palatable.

Finally, on the choice of terms, *nominal*, *representational*, and
*phantom* all seem like clear, self-explanatory choices to me.

- Mark
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/ghc-devs/attachments/20140325/c8c6e57c/attachment.html>

From fuuzetsu at fuuzetsu.co.uk  Tue Mar 25 15:11:26 2014
From: fuuzetsu at fuuzetsu.co.uk (Mateusz Kowalczyk)
Date: Tue, 25 Mar 2014 15:11:26 +0000
Subject: 7.8.1 plan
In-Reply-To: <53311BD4.3030008@mail.ru>
References: <CAEs96n3RWy6=xZo6Ogd=pqQ1FQbOK9JEKMzUvO5FAqxJQ7rX-g@mail.gmail.com>
 <53311BD4.3030008@mail.ru>
Message-ID: <53319C9E.9040000@fuuzetsu.co.uk>

On 25/03/14 06:01, kyra wrote:
> Will it include the latest commit to haddock? It solves this: 
> http://trac.haskell.org/haddock/ticket/292. This can greatly improve 
> performance of haddock in some situations (when a project is built with 
> --split-obj flag).
> 
> Cheers,
> Kyra
> 
> On 3/25/2014 01:36, Austin Seipp wrote:
>> Hello all,
>>
>> As I'm sure you're all aware, it's the final countdown. The (final)
>> source distribution will be up within a few hours, and then we'll
>> continue on from there. Yay! I will post an update when that is, so
>> Gabor/Luke/Karel can make binaries from the sources as I do so.
>>
>> Second, there are just two things I want to note:
>>
>>    - For people following the Windows debacle in #8834, there has been
>> a bug fixed, but one may still remain. The TL;DR of this is that we
>> currently have a committed workaround in place we'll keep using, but
>> Simon has made some good steps towards finding the bug.
>>
>>    - Lots of people, I'm sure, are wondering what's going on with Safe
>> Haskell and the GND story. The TL;DR of this one is that "everything
>> will be the same as in 7.6" - GND is considered an Unsafe feature, and
>> Data.Coerce is behind Unsafe bars. From a safety point of view,
>> nothing should change for library authors I cherry picked these
>> changes into 7.8 last night.
>>
>> In the mean time, the 7.8 branch is effectively closed. If you have
>> something to commit, and I *really* mean something, you can let me
>> know. But your deadline is hours, not days! I'm doing a final review
>> of all the trees before pushing the library tags, and after that I'll
>> begin rolling the sdist.
>>
>> Anyway, the time is finally here, so let's get it over with!
>>
> 
> _______________________________________________
> ghc-devs mailing list
> ghc-devs at haskell.org
> http://www.haskell.org/mailman/listinfo/ghc-devs
> 

Hi,

That commit is not in 2.14.1. Do you have any benchmarks to show the
speedup? If the commit does some significant speedup, I'm not against
backporting it into Haddock released with 7.8.2 (and there is at least 1
other fix I want to get into 7.8.2) but we pretty much closed the
2.14.1, it's up on Hackage and everything and that's what's planned to
ship with 7.8.1.

-- 
Mateusz K.

From simonpj at microsoft.com  Tue Mar 25 15:47:29 2014
From: simonpj at microsoft.com (Simon Peyton Jones)
Date: Tue, 25 Mar 2014 15:47:29 +0000
Subject: We need to add role annotations for 7.8
In-Reply-To: <CAAOoiFYJiGmpxPDYTbcHO107XxZMNRWpvMVZA5=waBv35oYR0g@mail.gmail.com>
References: <78518EC7-BC18-4732-90B6-1AB37048D2A3@cis.upenn.edu>
 <CAEs96n1Xxp9qmXLBf6XqKbLH3kEE3bVLcpLAuFHoVip0N+1D=w@mail.gmail.com>
 <CAEs96n1dVs8SC6an_5eCsx1aCPwbNjbahhNrKAeaSCv1=Qe3gw@mail.gmail.com>
 <CAEs96n0SCjD6_C7VkeL0NUCY+v-fZseeL=iRFZG9fL9b74AjwQ@mail.gmail.com>
 <CAEs96n1WnrVtyjk2f3jOgUZg2M4EwPSA-9bnN6+9dL1p+=Ea0w@mail.gmail.com>
 <CAK-tuPahbPSd4fxjRCMKHYPcsPuzsM3CnBFMBvkoYbAZkVmmjw@mail.gmail.com>
 <CAAOoiFZKYXzqdfS1PVfG4W_H9ig8iw3MrcTFWu5GrP4C6sgEoA@mail.gmail.com>
 <CAKFCL4Xz_W9of6SyXBsFfk+6Kp4E=T7pjPt4ZhqjqqY9wsixkw@mail.gmail.com>
 <59543203684B2244980D7E4057D5FBC1488BA55B@DB3EX14MBXC308.europe.corp.microsoft.com>
 <CAAOoiFaof89nQBRStVD38hmHQbBeNNQOU1+YEdaq_iwieKgGJA@mail.gmail.com>
 <CAJumaK_-dxYW=raqvCyfp1h-9XFwj2eKq_smWHng=DuUChfZ4w@mail.gmail.com>
 <2F1D91F2-0AD6-4E98-81E3-9A95E6024BA3@gmail.com>
 <8FD54493-CC52-4B90-9DD2-E7C91024FC30@cis.upenn.edu>
 <53313E49.1040405@ifi.lmu.de> <8761n2ob4f.fsf@gnu.org>
 <533165DF.5030206@ifi.lmu.de>
 <CAAOoiFYJiGmpxPDYTbcHO107XxZMNRWpvMVZA5=waBv35oYR0g@mail.gmail.com>
Message-ID: <59543203684B2244980D7E4057D5FBC1488BD709@DB3EX14MBXC308.europe.corp.microsoft.com>

The degree to which we believe this "partially" is important: If we are willing to believe that the only library writers we care about doing this are those in the core, then fine. In this case we shouldn't feel compelled to suggest to library writers that they annotate, ever. I'm good with this. If the team here thinks otherwise, that we need to start a campaign to get every library writer to eventually annotate, then I have deep objections.

The situation today is that

?         A client of a library can use GND to do bad things to the library (e.g. change the ?key? type of (Map key value)).

?         Role annotations allow the library author to prevent that happening.

Would you say that means that we are ?compelled to suggest to library writers that they annotate??

I would have thought that it would indeed be good to suggest to them that a new opportunity exists for them to make their library more robust to clients.  They are free to do nothing, or to take advantage of the suggestion.

It?s an upside-only situation.

Looking further ahead, when you say that ?there can be no migration from representational-by-default?, do you have data to support that?  Notably, any client not using GND could not observe a change. So simply seeing how many library modules use GND would be an upper bound on how many libraries would fail to compile you were to ask us to change the default.  Is that 1% of Hackage modules?  10%?  0.1%?  I don?t know.

The awkward bit is that if a client is using GND, which fails after a change to nominal-by-default, the fix is to change the library, not the client, and I can see that is awkward.

Simon

From: Libraries [mailto:libraries-bounces at haskell.org] On Behalf Of Mark Lentczner
Sent: 25 March 2014 15:10
To: libraries at haskell.org Libraries; ghc-devs at haskell.org
Subject: Re: We need to add role annotations for 7.8

Thank you to everyone who has been helping me understand this issue in greater depth.

tl;dr: As long as we don't expect any libraries beyond to core to annotate, I'm cool. This presumes that the extra safety isn't, in practice, dependent on transitive adoption by libraries. It also implies that representational is the only possible default, and that there can be no migration from it.

My approach to thinking about this is guided by thinking about supporting an eco-system with 1000s of libraries (hackage), a few dozen of which are heavily promoted (the platform), and a small set that are closely tied to the compiler (the core). The availability, speed of release, motivation, and even skill of the the developers varies widely over that range.

I also think about the various "stances" of different developers:

  *   End developer: makes use of libraries, but just builds apps
  *   Internal developer: makes libraries for internal use in a project
  *   Casual library writer: makes libraries, primarily for their own needs, but distributed on hackage
  *   Popular library writer: actively maintains libraries which are widely used
  *   Core library writer: maintainer of a core package that stays in lock step with the compiler
Then, I think about, for each of these, what is the effect on a new feature on them, their existing code, and future code? Does it affect them only if they are using the feature? If they aren't using the feature? For library writers, how does the feature affect clients? If a client wants to use a feature, under what conditions does the library need to do something? This last issue of the "transitivity" the feature is often the biggest concern.

Given that... onto type roles:

The default of representational is the only option, because a default of nominal would require far too many developers to have to update their code. I don't believe that we can ever migrate to nominal as default.

The feature implies that any abstract data type that uses a type parameter in certain ways needs annotate to get the full safety afforded now afforded. However, without annotation, the data type is still no worse off than it was before (there is added safety, but not perhaps relevant to the stand point of the library writer). Further, this (pre-existing) non-safety isn't likely a huge concern. Making sure the docs take the tone that most developers need to nothing, and when developers need to be concerned seems like an important way to ensure the right outcome.

A key question here is transitivity: Is it possible for module A to not annotate a type, and then have module B by a different author use the type in A in another abstract type, that is annotated, and get the benefit. Seems the answer is "partially". If the answer were "no", then use of the feature would be dependent on transitive adoption, and that is where the big burden on developers comes from.

The degree to which we believe this "partially" is important: If we are willing to believe that the only library writers we care about doing this are those in the core, then fine. In this case we shouldn't feel compelled to suggest to library writers that they annotate, ever. I'm good with this. If the team here thinks otherwise, that we need to start a campaign to get every library writer to eventually annotate, then I have deep objections.

I read the paper, and understand how the authors felt the syntax options were all less than perfect, and choose what they did. But that choice, perhaps unwittingly, the implication that it forces -XCPP on all libraries except perhaps some of the core. This is because they all need to support previous compilers. So, a one line annotation has turned into an ugly beast, and perhaps added -XCPP where there was none, which is really unfortunate. (I, like many, consider it a defeat when one has to resort to -XCPP.)

It seems to me that the paper didn't really consider less-perfect, heuristic solutions. It might have had significantly less impact on library writers were some heuristic (no constructors exported? has any type constraint on the parameter? etc..) might have allowed most data types to go without annotation at the cost of a few (where nominal was incorrectly inferred) requiring immediate action. In this situation, a non-language feature (pragma or other device) might have been more palatable.

Finally, on the choice of terms, nominal, representational, and phantom all seem like clear, self-explanatory choices to me.

- Mark

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/ghc-devs/attachments/20140325/2a87a412/attachment-0001.html>

From kyrab at mail.ru  Tue Mar 25 16:18:17 2014
From: kyrab at mail.ru (kyra)
Date: Tue, 25 Mar 2014 20:18:17 +0400
Subject: 7.8.1 plan
In-Reply-To: <53319C9E.9040000@fuuzetsu.co.uk>
References: <CAEs96n3RWy6=xZo6Ogd=pqQ1FQbOK9JEKMzUvO5FAqxJQ7rX-g@mail.gmail.com>
 <53311BD4.3030008@mail.ru> <53319C9E.9040000@fuuzetsu.co.uk>
Message-ID: <5331AC49.3010106@mail.ru>

On 3/25/2014 19:11, Mateusz Kowalczyk wrote:
> That commit is not in 2.14.1. Do you have any benchmarks to show the 
> speedup? If the commit does some significant speedup, I'm not against 
> backporting it into Haddock released with 7.8.2 (and there is at least 
> 1 other fix I want to get into 7.8.2) but we pretty much closed the 
> 2.14.1, it's up on Hackage and everything and that's what's planned to 
> ship with 7.8.1. 

Hmm, now, when I'm trying to reproduce things I don't see haddock 
producing any assembly output let alone split it when using 7.8rc2 haddock.

It seemed to me some time ago haddock became slow when processing a 
package built with --enable-split-objs and I've decided to look into 
things and discovered haddock wants .hi interface files and produces 
assembly output to produce these interface files.

I was extremely surprised, rechecked things several times and saw the 
same picture.

Now I can't reproduce this at all.

If haddock never produced .hi interface files and/or assembly output 
then that was some mental aberration and the whole story can be dropped.

Regards,
Kyra



From fuuzetsu at fuuzetsu.co.uk  Tue Mar 25 16:52:27 2014
From: fuuzetsu at fuuzetsu.co.uk (Mateusz Kowalczyk)
Date: Tue, 25 Mar 2014 16:52:27 +0000
Subject: 7.8.1 plan
In-Reply-To: <5331AC49.3010106@mail.ru>
References: <CAEs96n3RWy6=xZo6Ogd=pqQ1FQbOK9JEKMzUvO5FAqxJQ7rX-g@mail.gmail.com>
 <53311BD4.3030008@mail.ru> <53319C9E.9040000@fuuzetsu.co.uk>
 <5331AC49.3010106@mail.ru>
Message-ID: <5331B44B.40109@fuuzetsu.co.uk>

On 25/03/14 16:18, kyra wrote:
> On 3/25/2014 19:11, Mateusz Kowalczyk wrote:
>> That commit is not in 2.14.1. Do you have any benchmarks to show the 
>> speedup? If the commit does some significant speedup, I'm not against 
>> backporting it into Haddock released with 7.8.2 (and there is at least 
>> 1 other fix I want to get into 7.8.2) but we pretty much closed the 
>> 2.14.1, it's up on Hackage and everything and that's what's planned to 
>> ship with 7.8.1. 
> 
> Hmm, now, when I'm trying to reproduce things I don't see haddock 
> producing any assembly output let alone split it when using 7.8rc2 haddock.
> 
> It seemed to me some time ago haddock became slow when processing a 
> package built with --enable-split-objs and I've decided to look into 
> things and discovered haddock wants .hi interface files and produces 
> assembly output to produce these interface files.
> 
> I was extremely surprised, rechecked things several times and saw the 
> same picture.
> 
> Now I can't reproduce this at all.
> 
> If haddock never produced .hi interface files and/or assembly output 
> then that was some mental aberration and the whole story can be dropped.
> 
> Regards,
> Kyra
> 
> 
> _______________________________________________
> ghc-devs mailing list
> ghc-devs at haskell.org
> http://www.haskell.org/mailman/listinfo/ghc-devs
> 

As far as I know (and this is mostly guessing), Haddock will ask GHC to
produce .hi files when they do not already exist. I think you might have
some luck if you simply try cabal configure && cabal haddock but I don't
know.

I took the patch because I saw no harm in it and all tests were passing
but I do admit that I did not check the performance gain (we don't have
benchmarks, perhaps we should hook some up) or loss. I think GHC has
some Haddock perf tests but I did not check the numbers and I don't
think it would even fall under that.

If you can come up with something then let me know. If you can't, I
think we'll keep the patch just in case unless someone can show it
breaks something.

The only instances of Haddock becoming really slow that I can think of
is some rather old ticket (#101 on Haddock Trac) in presence of Template
Haskell but I have closed it a while ago due to lack of information to
go on and inability to replicate without the reporter's help. Perhaps
this was your use case?

-- 
Mateusz K.

From kyrab at mail.ru  Tue Mar 25 17:09:25 2014
From: kyrab at mail.ru (kyra)
Date: Tue, 25 Mar 2014 21:09:25 +0400
Subject: 7.8.1 plan
In-Reply-To: <5331B44B.40109@fuuzetsu.co.uk>
References: <CAEs96n3RWy6=xZo6Ogd=pqQ1FQbOK9JEKMzUvO5FAqxJQ7rX-g@mail.gmail.com>
 <53311BD4.3030008@mail.ru> <53319C9E.9040000@fuuzetsu.co.uk>
 <5331AC49.3010106@mail.ru> <5331B44B.40109@fuuzetsu.co.uk>
Message-ID: <5331B845.4010702@mail.ru>

On 3/25/2014 20:52, Mateusz Kowalczyk wrote:
> The only instances of Haddock becoming really slow that I can think of
> is some rather old ticket (#101 on Haddock Trac) in presence of Template
> Haskell but I have closed it a while ago due to lack of information to
> go on and inability to replicate without the reporter's help. Perhaps
> this was your use case?
>
Aha, this is why I could not reproduce it! I checked it on packages 
which used no TH, and that slow behaviour occurred when TH was involved!

I think it is TH which really triggers producing and splitting of an 
assembly output and in this case no-splitting gives *huge* benefit. 
Sadly, I have no time to check this right now.

Regards,
Kyra


From fuuzetsu at fuuzetsu.co.uk  Tue Mar 25 17:11:30 2014
From: fuuzetsu at fuuzetsu.co.uk (Mateusz Kowalczyk)
Date: Tue, 25 Mar 2014 17:11:30 +0000
Subject: 7.8.1 plan
In-Reply-To: <5331B845.4010702@mail.ru>
References: <CAEs96n3RWy6=xZo6Ogd=pqQ1FQbOK9JEKMzUvO5FAqxJQ7rX-g@mail.gmail.com>
 <53311BD4.3030008@mail.ru> <53319C9E.9040000@fuuzetsu.co.uk>
 <5331AC49.3010106@mail.ru> <5331B44B.40109@fuuzetsu.co.uk>
 <5331B845.4010702@mail.ru>
Message-ID: <5331B8C2.9070600@fuuzetsu.co.uk>

On 25/03/14 17:09, kyra wrote:
> On 3/25/2014 20:52, Mateusz Kowalczyk wrote:
>> The only instances of Haddock becoming really slow that I can think of
>> is some rather old ticket (#101 on Haddock Trac) in presence of Template
>> Haskell but I have closed it a while ago due to lack of information to
>> go on and inability to replicate without the reporter's help. Perhaps
>> this was your use case?
>>
> Aha, this is why I could not reproduce it! I checked it on packages 
> which used no TH, and that slow behaviour occurred when TH was involved!
> 
> I think it is TH which really triggers producing and splitting of an 
> assembly output and in this case no-splitting gives *huge* benefit. 
> Sadly, I have no time to check this right now.
> 
> Regards,
> Kyra
> 
> _______________________________________________
> ghc-devs mailing list
> ghc-devs at haskell.org
> http://www.haskell.org/mailman/listinfo/ghc-devs
> 

There's no rush as it's not going to get into 7.8.1 anyway but I would
love to see some numbers before 7.8.2 so please keep us in mind.

Thanks!

-- 
Mateusz K.

From austin at well-typed.com  Tue Mar 25 22:24:53 2014
From: austin at well-typed.com (Austin Seipp)
Date: Tue, 25 Mar 2014 17:24:53 -0500
Subject: 7.8.1 plan
In-Reply-To: <5331B8C2.9070600@fuuzetsu.co.uk>
References: <CAEs96n3RWy6=xZo6Ogd=pqQ1FQbOK9JEKMzUvO5FAqxJQ7rX-g@mail.gmail.com>
 <53311BD4.3030008@mail.ru> <53319C9E.9040000@fuuzetsu.co.uk>
 <5331AC49.3010106@mail.ru> <5331B44B.40109@fuuzetsu.co.uk>
 <5331B845.4010702@mail.ru> <5331B8C2.9070600@fuuzetsu.co.uk>
Message-ID: <CAEs96n3RguQmaqYFykSsQfgwqJzpmQRJ-QvXg3iPbcN=T-erhw@mail.gmail.com>

Hello all,

As an updated, I'm looking into the report Mateusz had of 'free'
failing to build haddocks on OS X*, which I've reproduced. It seems
nasty - I'll follow up with details ASAP.

* See his recent email to ghc-devs about this problem.

On Tue, Mar 25, 2014 at 12:11 PM, Mateusz Kowalczyk
<fuuzetsu at fuuzetsu.co.uk> wrote:
> On 25/03/14 17:09, kyra wrote:
>> On 3/25/2014 20:52, Mateusz Kowalczyk wrote:
>>> The only instances of Haddock becoming really slow that I can think of
>>> is some rather old ticket (#101 on Haddock Trac) in presence of Template
>>> Haskell but I have closed it a while ago due to lack of information to
>>> go on and inability to replicate without the reporter's help. Perhaps
>>> this was your use case?
>>>
>> Aha, this is why I could not reproduce it! I checked it on packages
>> which used no TH, and that slow behaviour occurred when TH was involved!
>>
>> I think it is TH which really triggers producing and splitting of an
>> assembly output and in this case no-splitting gives *huge* benefit.
>> Sadly, I have no time to check this right now.
>>
>> Regards,
>> Kyra
>>
>> _______________________________________________
>> ghc-devs mailing list
>> ghc-devs at haskell.org
>> http://www.haskell.org/mailman/listinfo/ghc-devs
>>
>
> There's no rush as it's not going to get into 7.8.1 anyway but I would
> love to see some numbers before 7.8.2 so please keep us in mind.
>
> Thanks!
>
> --
> Mateusz K.
> _______________________________________________
> ghc-devs mailing list
> ghc-devs at haskell.org
> http://www.haskell.org/mailman/listinfo/ghc-devs
>

-- 
Regards,

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

From eir at cis.upenn.edu  Tue Mar 25 23:23:58 2014
From: eir at cis.upenn.edu (Richard Eisenberg)
Date: Tue, 25 Mar 2014 19:23:58 -0400
Subject: We need to add role annotations for 7.8
In-Reply-To: <CAAOoiFYJiGmpxPDYTbcHO107XxZMNRWpvMVZA5=waBv35oYR0g@mail.gmail.com>
References: <78518EC7-BC18-4732-90B6-1AB37048D2A3@cis.upenn.edu>
 <CAEs96n1Xxp9qmXLBf6XqKbLH3kEE3bVLcpLAuFHoVip0N+1D=w@mail.gmail.com>
 <CAEs96n1dVs8SC6an_5eCsx1aCPwbNjbahhNrKAeaSCv1=Qe3gw@mail.gmail.com>
 <CAEs96n0SCjD6_C7VkeL0NUCY+v-fZseeL=iRFZG9fL9b74AjwQ@mail.gmail.com>
 <CAEs96n1WnrVtyjk2f3jOgUZg2M4EwPSA-9bnN6+9dL1p+=Ea0w@mail.gmail.com>
 <CAK-tuPahbPSd4fxjRCMKHYPcsPuzsM3CnBFMBvkoYbAZkVmmjw@mail.gmail.com>
 <CAAOoiFZKYXzqdfS1PVfG4W_H9ig8iw3MrcTFWu5GrP4C6sgEoA@mail.gmail.com>
 <CAKFCL4Xz_W9of6SyXBsFfk+6Kp4E=T7pjPt4ZhqjqqY9wsixkw@mail.gmail.com>
 <59543203684B2244980D7E4057D5FBC1488BA55B@DB3EX14MBXC308.europe.corp.microsoft.com>
 <CAAOoiFaof89nQBRStVD38hmHQbBeNNQOU1+YEdaq_iwieKgGJA@mail.gmail.com>
 <CAJumaK_-dxYW=raqvCyfp1h-9XFwj2eKq_smWHng=DuUChfZ4w@mail.gmail.com>
 <2F1D91F2-0AD6-4E98-81E3-9A95E6024BA3@gmail.com>
 <8FD54493-CC52-4B90-9DD2-E7C91024FC30@cis.upenn.edu>
 <53313E49.1040405@ifi.lmu.de> <8761n2ob4f.fsf@gnu.org>
 <533165DF.5030206@ifi.lmu.de> <CAAOoiFYJiGmpxPDYTbcHO107XxZMNR!
 WpvMVZA5=waBv35oYR0g@mail.gmail.com>
Message-ID: <2F0B89D5-0FF1-4107-805D-60B4F7F6FC0D@cis.upenn.edu>

Hi Mark,

I appreciate your analysis in terms of classes of users -- I think that is helpful for framing the discussion.

About transitivity: I think we're in the clear here. Let's say package A exports types missing role annotations. If package B imports package A and wants to have the full safety afforded by roles, that is no problem whatsoever. Package B has annotations on its types (which may use package A's types) that may restrict certain parameters to be nominal, as appropriate. If package A had role annotations, it's quite possible that package B could omit some annotations (as role inference propagates nominal roles), but there is no problem inherent in this. (Indeed, if package A adds annotations in the future, package B would have redundant, but harmless, annotations.) So, I disagree with Mark's "partially" below -- I think we're fully OK in this regard.

About heuristics: we briefly considered some, though there's no documentation of this anywhere. Specifically, we thought about giving nominal roles to parameters used in class constraints. The problem is, in the actual datatype definition, the constraints tend not to appear? Should we look around for other functions with constraints? That seems likely to be more confusing than helpful. Furthermore, I strongly don't like the idea of using heuristics to infer a feature such as this -- it can cause strange behavior and is hard to specify.

Richard

On Mar 25, 2014, at 11:09 AM, Mark Lentczner wrote:

> Thank you to everyone who has been helping me understand this issue in greater depth.
> 
> tl;dr: As long as we don't expect any libraries beyond to core to annotate, I'm cool. This presumes that the extra safety isn't, in practice, dependent on transitive adoption by libraries. It also implies that representational is the only possible default, and that there can be no migration from it.
> 
> My approach to thinking about this is guided by thinking about supporting an eco-system with 1000s of libraries (hackage), a few dozen of which are heavily promoted (the platform), and a small set that are closely tied to the compiler (the core). The availability, speed of release, motivation, and even skill of the the developers varies widely over that range.
> 
> I also think about the various "stances" of different developers: 
> End developer: makes use of libraries, but just builds apps
> Internal developer: makes libraries for internal use in a project
> Casual library writer: makes libraries, primarily for their own needs, but distributed on hackage
> Popular library writer: actively maintains libraries which are widely used
> Core library writer: maintainer of a core package that stays in lock step with the compiler
> Then, I think about, for each of these, what is the effect on a new feature on them, their existing code, and future code? Does it affect them only if they are using the feature? If they aren't using the feature? For library writers, how does the feature affect clients? If a client wants to use a feature, under what conditions does the library need to do something? This last issue of the "transitivity" the feature is often the biggest concern.
> 
> Given that... onto type roles:
>  
> The default of representational is the only option, because a default of nominal would require far too many developers to have to update their code. I don't believe that we can ever migrate to nominal as default.
> 
> The feature implies that any abstract data type that uses a type parameter in certain ways needs annotate to get the full safety afforded now afforded. However, without annotation, the data type is still no worse off than it was before (there is added safety, but not perhaps relevant to the stand point of the library writer). Further, this (pre-existing) non-safety isn't likely a huge concern. Making sure the docs take the tone that most developers need to nothing, and when developers need to be concerned seems like an important way to ensure the right outcome.
> 
> A key question here is transitivity: Is it possible for module A to not annotate a type, and then have module B by a different author use the type in A in another abstract type, that is annotated, and get the benefit. Seems the answer is "partially". If the answer were "no", then use of the feature would be dependent on transitive adoption, and that is where the big burden on developers comes from.
> 
> The degree to which we believe this "partially" is important: If we are willing to believe that the only library writers we care about doing this are those in the core, then fine. In this case we shouldn't feel compelled to suggest to library writers that they annotate, ever. I'm good with this. If the team here thinks otherwise, that we need to start a campaign to get every library writer to eventually annotate, then I have deep objections.
> 
> I read the paper, and understand how the authors felt the syntax options were all less than perfect, and choose what they did. But that choice, perhaps unwittingly, the implication that it forces -XCPP on all libraries except perhaps some of the core. This is because they all need to support previous compilers. So, a one line annotation has turned into an ugly beast, and perhaps added -XCPP where there was none, which is really unfortunate. (I, like many, consider it a defeat when one has to resort to -XCPP.)
> 
> It seems to me that the paper didn't really consider less-perfect, heuristic solutions. It might have had significantly less impact on library writers were some heuristic (no constructors exported? has any type constraint on the parameter? etc..) might have allowed most data types to go without annotation at the cost of a few (where nominal was incorrectly inferred) requiring immediate action. In this situation, a non-language feature (pragma or other device) might have been more palatable.
> 
> Finally, on the choice of terms, nominal, representational, and phantom all seem like clear, self-explanatory choices to me.
> 
> - Mark
> 
> _______________________________________________
> ghc-devs mailing list
> ghc-devs at haskell.org
> http://www.haskell.org/mailman/listinfo/ghc-devs

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/ghc-devs/attachments/20140325/d3075f7c/attachment-0001.html>

From marlowsd at gmail.com  Wed Mar 26 09:07:17 2014
From: marlowsd at gmail.com (Simon Marlow)
Date: Wed, 26 Mar 2014 09:07:17 +0000
Subject: [commit: ghc] master: Convert haddock into a proper submodule
 (re #8545) (34b0721)
In-Reply-To: <871txsbpbr.fsf@gmail.com>
References: <20140323094934.5E7D52406B@ghc.haskell.org>
 <59543203684B2244980D7E4057D5FBC1488B8AF9@DB3EX14MBXC308.europe.corp.microsoft.com>
 <871txsbpbr.fsf@gmail.com>
Message-ID: <533298C5.5050605@gmail.com>

Thanks for the wiki page.  One thing missing I noticed is what happens 
the next time you update your tree, after having checked out master (or 
a branch) in one of the submodules.

Cheers,
Simon

On 23/03/2014 21:03, Herbert Valerio Riedel wrote:
> On 2014-03-23 at 19:53:55 +0100, Simon Peyton Jones wrote:
>> Do us na?ve users need to change our workflow with these submodule
>> changes?
>
> Probably yes... to some extent at least; that's why only haddock.git has
> been converted for now[1]: to find out empirically what's involved
> before continuing with the submodule-conversion.
>
> I've tried to describe one possible workflow (for if you need to publish
> a modification to haddock.git) at
>
>    https://ghc.haskell.org/trac/ghc/wiki/WorkingConventions/Git/Submodules#MakingchangestoGHCsubmodules
>
> I hope it makes a bit of sense :-)
>
> IMO, it's quite useful to familiarize oneself with the 'git submodule'
> family of commands, and especially 'git submodule' and 'git submodule
> summary', as those two introspection commands allow one to get a better
> picture in which state the currently cloned GHC working tree's
> submodules are.
>
>   [1]: OTOH, haddock.git is not the first/only proper Git submodule we
>        have so far; so, in some way this isn't much of a change...
> _______________________________________________
> ghc-devs mailing list
> ghc-devs at haskell.org
> http://www.haskell.org/mailman/listinfo/ghc-devs
>

From carter.schonwald at gmail.com  Wed Mar 26 15:42:53 2014
From: carter.schonwald at gmail.com (Carter Schonwald)
Date: Wed, 26 Mar 2014 11:42:53 -0400
Subject: We need to add role annotations for 7.8
In-Reply-To: <CAJ5riwKdmcTsXadPdSKy_=OEyfTga8-bTV0VvkgZf0X_Y83kcQ@mail.gmail.com>
References: <78518EC7-BC18-4732-90B6-1AB37048D2A3@cis.upenn.edu>
 <CAEs96n1Xxp9qmXLBf6XqKbLH3kEE3bVLcpLAuFHoVip0N+1D=w@mail.gmail.com>
 <CAEs96n1dVs8SC6an_5eCsx1aCPwbNjbahhNrKAeaSCv1=Qe3gw@mail.gmail.com>
 <CAEs96n0SCjD6_C7VkeL0NUCY+v-fZseeL=iRFZG9fL9b74AjwQ@mail.gmail.com>
 <CAEs96n1WnrVtyjk2f3jOgUZg2M4EwPSA-9bnN6+9dL1p+=Ea0w@mail.gmail.com>
 <CAK-tuPahbPSd4fxjRCMKHYPcsPuzsM3CnBFMBvkoYbAZkVmmjw@mail.gmail.com>
 <CAAOoiFZKYXzqdfS1PVfG4W_H9ig8iw3MrcTFWu5GrP4C6sgEoA@mail.gmail.com>
 <CAKFCL4Xz_W9of6SyXBsFfk+6Kp4E=T7pjPt4ZhqjqqY9wsixkw@mail.gmail.com>
 <59543203684B2244980D7E4057D5FBC1488BA55B@DB3EX14MBXC308.europe.corp.microsoft.com>
 <CAAOoiFaof89nQBRStVD38hmHQbBeNNQOU1+YEdaq_iwieKgGJA@mail.gmail.com>
 <CAJumaK_-dxYW=raqvCyfp1h-9XFwj2eKq_smWHng=DuUChfZ4w@mail.gmail.com>
 <2F1D91F2-0AD6-4E98-81E3-9A95E6024BA3@gmail.com>
 <8FD54493-CC52-4B90-9DD2-E7C91024FC30@cis.upenn.edu>
 <53313E49.1040405@ifi.lmu.de> <8761n2ob4f.fsf@gnu.org>
 <533165DF.5030206@ifi.lmu.de>
 <CAAOoiFYJiGmpxPDYTbcHO107XxZMNRWpvMVZA5=waBv35oYR0g@mail.gmail.com>
 <2F0B89D5-0FF1-4107-805D-60B4F7F6FC0D@cis.upenn.edu>
 <CAJ5riwKdmcTsXadPdSKy_=OEyfTga8-bTV0VvkgZf0X_Y83kcQ@mail.gmail.com>
Message-ID: <CAHYVw0yHzu086sE9da9n9zFO9bmo1r6MfjTLBPMFGs8Drr9NLw@mail.gmail.com>

I think something like that is on the table, at least for a future ghc
release.  I'm not sure if it made it into the patches for 7.8.1. But this
was actually suggested on the relevant ticket last week. (I'm Afk otherwise
id dig up the link)

On Wednesday, March 26, 2014, Casey McCann <cam at uptoisomorphism.net> wrote:

> Were any rules considered along the lines of "Representational by
> default if all the type's constructors are exported by a module not
> named 'Internal', nominal by default otherwise"? Better would probably
> include "exported by a module the package exposes" but that's
> disgustingly non-local if it's even possible at all. The module name
> thing is hacky to the extreme but at least it's a simple rule rather
> than some obscure and opaque heuristics.
>
> Anyway, the goal of something like that would be not so much "figure
> out what it should be", since that's impossible, but more "default to
> nominal if and only if there's clear indication the user is already
> thinking about restricting how the type is used".
>
> Not that I'm really even suggesting such a rule, just wondering if it
> was discussed.
>
> - C.
>
>
> On Tue, Mar 25, 2014 at 7:23 PM, Richard Eisenberg <eir at cis.upenn.edu>
> wrote:
> > Hi Mark,
> >
> > I appreciate your analysis in terms of classes of users -- I think that
> is
> > helpful for framing the discussion.
> >
> > About transitivity: I think we're in the clear here. Let's say package A
> > exports types missing role annotations. If package B imports package A
> and
> > wants to have the full safety afforded by roles, that is no problem
> > whatsoever. Package B has annotations on its types (which may use package
> > A's types) that may restrict certain parameters to be nominal, as
> > appropriate. If package A had role annotations, it's quite possible that
> > package B could omit some annotations (as role inference propagates
> nominal
> > roles), but there is no problem inherent in this. (Indeed, if package A
> adds
> > annotations in the future, package B would have redundant, but harmless,
> > annotations.) So, I disagree with Mark's "partially" below -- I think
> we're
> > fully OK in this regard.
> >
> > About heuristics: we briefly considered some, though there's no
> > documentation of this anywhere. Specifically, we thought about giving
> > nominal roles to parameters used in class constraints. The problem is, in
> > the actual datatype definition, the constraints tend not to appear?
> Should
> > we look around for other functions with constraints? That seems likely
> to be
> > more confusing than helpful. Furthermore, I strongly don't like the idea
> of
> > using heuristics to infer a feature such as this -- it can cause strange
> > behavior and is hard to specify.
> >
> > Richard
> >
> > On Mar 25, 2014, at 11:09 AM, Mark Lentczner wrote:
> >
> > Thank you to everyone who has been helping me understand this issue in
> > greater depth.
> >
> > tl;dr: As long as we don't expect any libraries beyond to core to
> annotate,
> > I'm cool. This presumes that the extra safety isn't, in practice,
> dependent
> > on transitive adoption by libraries. It also implies that
> representational
> > is the only possible default, and that there can be no migration from it.
> >
> > My approach to thinking about this is guided by thinking about
> supporting an
> > eco-system with 1000s of libraries (hackage), a few dozen of which are
> > heavily promoted (the platform), and a small set that are closely tied to
> > the compiler (the core). The availability, speed of release, motivation,
> and
> > even skill of the the developers varies widely over that range.
> >
> > I also think about the various "stances" of different developers:
> >
> > End developer: makes use of libraries, but just builds apps
> > Internal developer: makes libraries for internal use in a project
> > Casual library writer: makes libraries, primarily for their own needs,
> but
> > distributed on hackage
> > Popular library writer: actively maintains libraries which are widely
> used
> > Core library writer: maintainer of a core package that stays in lock step
> > with the compiler
> >
> > Then, I think about, for each of these, what is the effect on a new
> feature
> > on them, their existing code, and future code? Does it affect them only
> if
> > they are using the feature? If they aren't using the feature? For library
> > writers, how does the feature affect clients? If a client wants to use a
> > feature, under what conditions does the library need to do something?
> This
> > last issue of the "transitivity" the feature is often the biggest
> concern.
> >
> > Given that... onto type roles:
> >
> > The default of representational is the only option, because a default of
> > nominal would require far too many developers to have to update their
> code.
> > I don't believe that we can ever migrate to nominal as default.
> >
> > The feature implies that any abstract data type that uses a type
> parameter
> > in certain ways needs annotate to get the full safety afforded now
> afforded.
> > However, without annotation, the data type is still no worse off than it
> was
> > before (there is added safety, but not perhaps relevant to the stand
> point
> > of the library writer). Further, this (pre-existing) non-safety isn't
> likely
> > a huge concern. Making sure the docs take the tone that most developers
> need
> > to nothing, and when developers need to be concerned seems like an
> important
> > way to ensure the right outcome.
> >
> > A key question here is transitivity: Is it possible for module A to not
> > annotate a type, and then have module B b>
> _______________________________________________
> > Libraries mailing list
> > Libraries at haskell.org <javascript:;>
> > http://www.haskell.org/mailman/listinfo/libraries
> >
> _______________________________________________
> Libraries mailing list
> Libraries at haskell.org <javascript:;>
> http://www.haskell.org/mailman/listinfo/libraries
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/ghc-devs/attachments/20140326/8609519a/attachment.html>

From eir at cis.upenn.edu  Thu Mar 27 02:50:21 2014
From: eir at cis.upenn.edu (Richard Eisenberg)
Date: Wed, 26 Mar 2014 22:50:21 -0400
Subject: We need to add role annotations for 7.8
In-Reply-To: <CAJ5riwKdmcTsXadPdSKy_=OEyfTga8-bTV0VvkgZf0X_Y83kcQ@mail.gmail.com>
References: <78518EC7-BC18-4732-90B6-1AB37048D2A3@cis.upenn.edu>
 <CAEs96n1Xxp9qmXLBf6XqKbLH3kEE3bVLcpLAuFHoVip0N+1D=w@mail.gmail.com>
 <CAEs96n1dVs8SC6an_5eCsx1aCPwbNjbahhNrKAeaSCv1=Qe3gw@mail.gmail.com>
 <CAEs96n0SCjD6_C7VkeL0NUCY+v-fZseeL=iRFZG9fL9b74AjwQ@mail.gmail.com>
 <CAEs96n1WnrVtyjk2f3jOgUZg2M4EwPSA-9bnN6+9dL1p+=Ea0w@mail.gmail.com>
 <CAK-tuPahbPSd4fxjRCMKHYPcsPuzsM3CnBFMBvkoYbAZkVmmjw@mail.gmail.com>
 <CAAOoiFZKYXzqdfS1PVfG4W_H9ig8iw3MrcTFWu5GrP4C6sgEoA@mail.gmail.com>
 <CAKFCL4Xz_W9of6SyXBsFfk+6Kp4E=T7pjPt4ZhqjqqY9wsixkw@mail.gmail.com>
 <59543203684B2244980D7E4057D5FBC1488BA55B@DB3EX14MBXC308.europe.corp.microsoft.com>
 <CAAOoiFaof89nQBRStVD38hmHQbBeNNQOU1+YEdaq_iwieKgGJA@mail.gmail.com>
 <CAJumaK_-dxYW=raqvCyfp1h-9XFwj2eKq_smWHng=DuUChfZ4w@mail.gmail.com>
 <2F1D91F2-0AD6-4E98-81E3-9A95E6024BA3@gmail.com>
 <8FD54493-CC52-4B90-9DD2-E7C91024FC30@cis.upenn.edu>
 <53313E49.1040405@ifi.lmu.de> <8761n2ob4f.fsf@gnu.org>
 <533165DF.5030206@ifi.lmu.de> <CAAOoiFYJiGmpxPDYTbcHO107XxZMNR!
 WpvMVZA5=waBv35oYR0g@mail.gmail.com>
 <2F0B89D5-0FF1-4107-805D-60B4F7F6FC0D@cis.upenn.edu>
 <CAJ5riwKdmcTsXadPdSKy_=OEyfTga8-bTV0VvkgZf0X_Y83kcQ@mail.gmail.com>
Message-ID: <D74D3986-5EF2-4561-A7E7-CF8D68FF5F2F@cis.upenn.edu>

Not for more than a passing mention. Using the name of the module to control the default makes me unhappy (should choice of name be relevant in the correctness / interpretation of a program?). Other heuristics (presence of constrained functions) seem quite fragile. Of everything said so far, I think the closest suggestion is to use constrained datatypes (like `data Ord a => Set a = ...`), but that mis-appropriates datatype contexts (which are silly) into something new and different, and so I personally don't think it's really viable.

Following Mark's idea of breaking this problem up into more manageable chunks, I would want us to think about two separate (and conflicting, often) users:

1. Users of today's Haskell who have to update their code.
2. Users of Haskell in 10 years.

Would users in group (2) like these heuristics? I doubt it. I think users in group (2) would probably most like a default of nominal with role annotations (in some concrete syntax). But, users in group (1) would hate a nominal default, so we have a compromise.

Richard

On Mar 26, 2014, at 11:40 AM, Casey McCann <cam at uptoisomorphism.net> wrote:

> Were any rules considered along the lines of "Representational by
> default if all the type's constructors are exported by a module not
> named 'Internal', nominal by default otherwise"? Better would probably
> include "exported by a module the package exposes" but that's
> disgustingly non-local if it's even possible at all. The module name
> thing is hacky to the extreme but at least it's a simple rule rather
> than some obscure and opaque heuristics.
> 
> Anyway, the goal of something like that would be not so much "figure
> out what it should be", since that's impossible, but more "default to
> nominal if and only if there's clear indication the user is already
> thinking about restricting how the type is used".
> 
> Not that I'm really even suggesting such a rule, just wondering if it
> was discussed.
> 
> - C.
> 
> 
> On Tue, Mar 25, 2014 at 7:23 PM, Richard Eisenberg <eir at cis.upenn.edu> wrote:
>> Hi Mark,
>> 
>> I appreciate your analysis in terms of classes of users -- I think that is
>> helpful for framing the discussion.
>> 
>> About transitivity: I think we're in the clear here. Let's say package A
>> exports types missing role annotations. If package B imports package A and
>> wants to have the full safety afforded by roles, that is no problem
>> whatsoever. Package B has annotations on its types (which may use package
>> A's types) that may restrict certain parameters to be nominal, as
>> appropriate. If package A had role annotations, it's quite possible that
>> package B could omit some annotations (as role inference propagates nominal
>> roles), but there is no problem inherent in this. (Indeed, if package A adds
>> annotations in the future, package B would have redundant, but harmless,
>> annotations.) So, I disagree with Mark's "partially" below -- I think we're
>> fully OK in this regard.
>> 
>> About heuristics: we briefly considered some, though there's no
>> documentation of this anywhere. Specifically, we thought about giving
>> nominal roles to parameters used in class constraints. The problem is, in
>> the actual datatype definition, the constraints tend not to appear? Should
>> we look around for other functions with constraints? That seems likely to be
>> more confusing than helpful. Furthermore, I strongly don't like the idea of
>> using heuristics to infer a feature such as this -- it can cause strange
>> behavior and is hard to specify.
>> 
>> Richard
>> 
>> On Mar 25, 2014, at 11:09 AM, Mark Lentczner wrote:
>> 
>> Thank you to everyone who has been helping me understand this issue in
>> greater depth.
>> 
>> tl;dr: As long as we don't expect any libraries beyond to core to annotate,
>> I'm cool. This presumes that the extra safety isn't, in practice, dependent
>> on transitive adoption by libraries. It also implies that representational
>> is the only possible default, and that there can be no migration from it.
>> 
>> My approach to thinking about this is guided by thinking about supporting an
>> eco-system with 1000s of libraries (hackage), a few dozen of which are
>> heavily promoted (the platform), and a small set that are closely tied to
>> the compiler (the core). The availability, speed of release, motivation, and
>> even skill of the the developers varies widely over that range.
>> 
>> I also think about the various "stances" of different developers:
>> 
>> End developer: makes use of libraries, but just builds apps
>> Internal developer: makes libraries for internal use in a project
>> Casual library writer: makes libraries, primarily for their own needs, but
>> distributed on hackage
>> Popular library writer: actively maintains libraries which are widely used
>> Core library writer: maintainer of a core package that stays in lock step
>> with the compiler
>> 
>> Then, I think about, for each of these, what is the effect on a new feature
>> on them, their existing code, and future code? Does it affect them only if
>> they are using the feature? If they aren't using the feature? For library
>> writers, how does the feature affect clients? If a client wants to use a
>> feature, under what conditions does the library need to do something? This
>> last issue of the "transitivity" the feature is often the biggest concern.
>> 
>> Given that... onto type roles:
>> 
>> The default of representational is the only option, because a default of
>> nominal would require far too many developers to have to update their code.
>> I don't believe that we can ever migrate to nominal as default.
>> 
>> The feature implies that any abstract data type that uses a type parameter
>> in certain ways needs annotate to get the full safety afforded now afforded.
>> However, without annotation, the data type is still no worse off than it was
>> before (there is added safety, but not perhaps relevant to the stand point
>> of the library writer). Further, this (pre-existing) non-safety isn't likely
>> a huge concern. Making sure the docs take the tone that most developers need
>> to nothing, and when developers need to be concerned seems like an important
>> way to ensure the right outcome.
>> 
>> A key question here is transitivity: Is it possible for module A to not
>> annotate a type, and then have module B by a different author use the type
>> in A in another abstract type, that is annotated, and get the benefit. Seems
>> the answer is "partially". If the answer were "no", then use of the feature
>> would be dependent on transitive adoption, and that is where the big burden
>> on developers comes from.
>> 
>> The degree to which we believe this "partially" is important: If we are
>> willing to believe that the only library writers we care about doing this
>> are those in the core, then fine. In this case we shouldn't feel compelled
>> to suggest to library writers that they annotate, ever. I'm good with this.
>> If the team here thinks otherwise, that we need to start a campaign to get
>> every library writer to eventually annotate, then I have deep objections.
>> 
>> I read the paper, and understand how the authors felt the syntax options
>> were all less than perfect, and choose what they did. But that choice,
>> perhaps unwittingly, the implication that it forces -XCPP on all libraries
>> except perhaps some of the core. This is because they all need to support
>> previous compilers. So, a one line annotation has turned into an ugly beast,
>> and perhaps added -XCPP where there was none, which is really unfortunate.
>> (I, like many, consider it a defeat when one has to resort to -XCPP.)
>> 
>> It seems to me that the paper didn't really consider less-perfect, heuristic
>> solutions. It might have had significantly less impact on library writers
>> were some heuristic (no constructors exported? has any type constraint on
>> the parameter? etc..) might have allowed most data types to go without
>> annotation at the cost of a few (where nominal was incorrectly inferred)
>> requiring immediate action. In this situation, a non-language feature
>> (pragma or other device) might have been more palatable.
>> 
>> Finally, on the choice of terms, nominal, representational, and phantom all
>> seem like clear, self-explanatory choices to me.
>> 
>> - Mark
>> 
>> _______________________________________________
>> ghc-devs mailing list
>> ghc-devs at haskell.org
>> http://www.haskell.org/mailman/listinfo/ghc-devs
>> 
>> 
>> 
>> _______________________________________________
>> Libraries mailing list
>> Libraries at haskell.org
>> http://www.haskell.org/mailman/listinfo/libraries
>> 


From ekmett at gmail.com  Thu Mar 27 03:46:29 2014
From: ekmett at gmail.com (Edward Kmett)
Date: Wed, 26 Mar 2014 23:46:29 -0400
Subject: We need to add role annotations for 7.8
In-Reply-To: <D74D3986-5EF2-4561-A7E7-CF8D68FF5F2F@cis.upenn.edu>
References: <78518EC7-BC18-4732-90B6-1AB37048D2A3@cis.upenn.edu>
 <CAEs96n1Xxp9qmXLBf6XqKbLH3kEE3bVLcpLAuFHoVip0N+1D=w@mail.gmail.com>
 <CAEs96n1dVs8SC6an_5eCsx1aCPwbNjbahhNrKAeaSCv1=Qe3gw@mail.gmail.com>
 <CAEs96n0SCjD6_C7VkeL0NUCY+v-fZseeL=iRFZG9fL9b74AjwQ@mail.gmail.com>
 <CAEs96n1WnrVtyjk2f3jOgUZg2M4EwPSA-9bnN6+9dL1p+=Ea0w@mail.gmail.com>
 <CAK-tuPahbPSd4fxjRCMKHYPcsPuzsM3CnBFMBvkoYbAZkVmmjw@mail.gmail.com>
 <CAAOoiFZKYXzqdfS1PVfG4W_H9ig8iw3MrcTFWu5GrP4C6sgEoA@mail.gmail.com>
 <CAKFCL4Xz_W9of6SyXBsFfk+6Kp4E=T7pjPt4ZhqjqqY9wsixkw@mail.gmail.com>
 <59543203684B2244980D7E4057D5FBC1488BA55B@DB3EX14MBXC308.europe.corp.microsoft.com>
 <CAAOoiFaof89nQBRStVD38hmHQbBeNNQOU1+YEdaq_iwieKgGJA@mail.gmail.com>
 <CAJumaK_-dxYW=raqvCyfp1h-9XFwj2eKq_smWHng=DuUChfZ4w@mail.gmail.com>
 <2F1D91F2-0AD6-4E98-81E3-9A95E6024BA3@gmail.com>
 <8FD54493-CC52-4B90-9DD2-E7C91024FC30@cis.upenn.edu>
 <53313E49.1040405@ifi.lmu.de> <8761n2ob4f.fsf@gnu.org>
 <533165DF.5030206@ifi.lmu.de>
 <2F0B89D5-0FF1-4107-805D-60B4F7F6FC0D@cis.upenn.edu>
 <CAJ5riwKdmcTsXadPdSKy_=OEyfTga8-bTV0VvkgZf0X_Y83kcQ@mail.gmail.com>
 <D74D3986-5EF2-4561-A7E7-CF8D68FF5F2F@cis.upenn.edu>
Message-ID: <CAJumaK_iqWiMmJ4f49cUy5htTT9xZHbGUhuHTTHKUqDEYDLusg@mail.gmail.com>

Personally, looking at it 10 years on, having a nominal default would look
pretty terrible to me.

I'd be stuck annotating everything I write. Nothing easy could just be
easy.

The 10 years on crowd is a reasonable argument for a "real" type role
syntax, and it was indeed that argument that won me over, but if anything
the 10 year argument goes the other way for me on a nominal vs
representational default.

-Edward


On Wed, Mar 26, 2014 at 10:50 PM, Richard Eisenberg <eir at cis.upenn.edu>wrote:

> Not for more than a passing mention. Using the name of the module to
> control the default makes me unhappy (should choice of name be relevant in
> the correctness / interpretation of a program?). Other heuristics (presence
> of constrained functions) seem quite fragile. Of everything said so far, I
> think the closest suggestion is to use constrained datatypes (like `data
> Ord a => Set a = ...`), but that mis-appropriates datatype contexts (which
> are silly) into something new and different, and so I personally don't
> think it's really viable.
>
> Following Mark's idea of breaking this problem up into more manageable
> chunks, I would want us to think about two separate (and conflicting,
> often) users:
>
> 1. Users of today's Haskell who have to update their code.
> 2. Users of Haskell in 10 years.
>
> Would users in group (2) like these heuristics? I doubt it. I think users
> in group (2) would probably most like a default of nominal with role
> annotations (in some concrete syntax). But, users in group (1) would hate a
> nominal default, so we have a compromise.
>
> Richard
>
> On Mar 26, 2014, at 11:40 AM, Casey McCann <cam at uptoisomorphism.net>
> wrote:
>
> > Were any rules considered along the lines of "Representational by
> > default if all the type's constructors are exported by a module not
> > named 'Internal', nominal by default otherwise"? Better would probably
> > include "exported by a module the package exposes" but that's
> > disgustingly non-local if it's even possible at all. The module name
> > thing is hacky to the extreme but at least it's a simple rule rather
> > than some obscure and opaque heuristics.
> >
> > Anyway, the goal of something like that would be not so much "figure
> > out what it should be", since that's impossible, but more "default to
> > nominal if and only if there's clear indication the user is already
> > thinking about restricting how the type is used".
> >
> > Not that I'm really even suggesting such a rule, just wondering if it
> > was discussed.
> >
> > - C.
> >
> >
> > On Tue, Mar 25, 2014 at 7:23 PM, Richard Eisenberg <eir at cis.upenn.edu>
> wrote:
> >> Hi Mark,
> >>
> >> I appreciate your analysis in terms of classes of users -- I think that
> is
> >> helpful for framing the discussion.
> >>
> >> About transitivity: I think we're in the clear here. Let's say package A
> >> exports types missing role annotations. If package B imports package A
> and
> >> wants to have the full safety afforded by roles, that is no problem
> >> whatsoever. Package B has annotations on its types (which may use
> package
> >> A's types) that may restrict certain parameters to be nominal, as
> >> appropriate. If package A had role annotations, it's quite possible that
> >> package B could omit some annotations (as role inference propagates
> nominal
> >> roles), but there is no problem inherent in this. (Indeed, if package A
> adds
> >> annotations in the future, package B would have redundant, but harmless,
> >> annotations.) So, I disagree with Mark's "partially" below -- I think
> we're
> >> fully OK in this regard.
> >>
> >> About heuristics: we briefly considered some, though there's no
> >> documentation of this anywhere. Specifically, we thought about giving
> >> nominal roles to parameters used in class constraints. The problem is,
> in
> >> the actual datatype definition, the constraints tend not to appear?
> Should
> >> we look around for other functions with constraints? That seems likely
> to be
> >> more confusing than helpful. Furthermore, I strongly don't like the
> idea of
> >> using heuristics to infer a feature such as this -- it can cause strange
> >> behavior and is hard to specify.
> >>
> >> Richard
> >>
> >> On Mar 25, 2014, at 11:09 AM, Mark Lentczner wrote:
> >>
> >> Thank you to everyone who has been helping me understand this issue in
> >> greater depth.
> >>
> >> tl;dr: As long as we don't expect any libraries beyond to core to
> annotate,
> >> I'm cool. This presumes that the extra safety isn't, in practice,
> dependent
> >> on transitive adoption by libraries. It also implies that
> representational
> >> is the only possible default, and that there can be no migration from
> it.
> >>
> >> My approach to thinking about this is guided by thinking about
> supporting an
> >> eco-system with 1000s of libraries (hackage), a few dozen of which are
> >> heavily promoted (the platform), and a small set that are closely tied
> to
> >> the compiler (the core). The availability, speed of release,
> motivation, and
> >> even skill of the the developers varies widely over that range.
> >>
> >> I also think about the various "stances" of different developers:
> >>
> >> End developer: makes use of libraries, but just builds apps
> >> Internal developer: makes libraries for internal use in a project
> >> Casual library writer: makes libraries, primarily for their own needs,
> but
> >> distributed on hackage
> >> Popular library writer: actively maintains libraries which are widely
> used
> >> Core library writer: maintainer of a core package that stays in lock
> step
> >> with the compiler
> >>
> >> Then, I think about, for each of these, what is the effect on a new
> feature
> >> on them, their existing code, and future code? Does it affect them only
> if
> >> they are using the feature? If they aren't using the feature? For
> library
> >> writers, how does the feature affect clients? If a client wants to use a
> >> feature, under what conditions does the library need to do something?
> This
> >> last issue of the "transitivity" the feature is often the biggest
> concern.
> >>
> >> Given that... onto type roles:
> >>
> >> The default of representational is the only option, because a default of
> >> nominal would require far too many developers to have to update their
> code.
> >> I don't believe that we can ever migrate to nominal as default.
> >>
> >> The feature implies that any abstract data type that uses a type
> parameter
> >> in certain ways needs annotate to get the full safety afforded now
> afforded.
> >> However, without annotation, the data type is still no worse off than
> it was
> >> before (there is added safety, but not perhaps relevant to the stand
> point
> >> of the library writer). Further, this (pre-existing) non-safety isn't
> likely
> >> a huge concern. Making sure the docs take the tone that most developers
> need
> >> to nothing, and when developers need to be concerned seems like an
> important
> >> way to ensure the right outcome.
> >>
> >> A key question here is transitivity: Is it possible for module A to not
> >> annotate a type, and then have module B by a different author use the
> type
> >> in A in another abstract type, that is annotated, and get the benefit.
> Seems
> >> the answer is "partially". If the answer were "no", then use of the
> feature
> >> would be dependent on transitive adoption, and that is where the big
> burden
> >> on developers comes from.
> >>
> >> The degree to which we believe this "partially" is important: If we are
> >> willing to believe that the only library writers we care about doing
> this
> >> are those in the core, then fine. In this case we shouldn't feel
> compelled
> >> to suggest to library writers that they annotate, ever. I'm good with
> this.
> >> If the team here thinks otherwise, that we need to start a campaign to
> get
> >> every library writer to eventually annotate, then I have deep
> objections.
> >>
> >> I read the paper, and understand how the authors felt the syntax options
> >> were all less than perfect, and choose what they did. But that choice,
> >> perhaps unwittingly, the implication that it forces -XCPP on all
> libraries
> >> except perhaps some of the core. This is because they all need to
> support
> >> previous compilers. So, a one line annotation has turned into an ugly
> beast,
> >> and perhaps added -XCPP where there was none, which is really
> unfortunate.
> >> (I, like many, consider it a defeat when one has to resort to -XCPP.)
> >>
> >> It seems to me that the paper didn't really consider less-perfect,
> heuristic
> >> solutions. It might have had significantly less impact on library
> writers
> >> were some heuristic (no constructors exported? has any type constraint
> on
> >> the parameter? etc..) might have allowed most data types to go without
> >> annotation at the cost of a few (where nominal was incorrectly inferred)
> >> requiring immediate action. In this situation, a non-language feature
> >> (pragma or other device) might have been more palatable.
> >>
> >> Finally, on the choice of terms, nominal, representational, and phantom
> all
> >> seem like clear, self-explanatory choices to me.
> >>
> >> - Mark
> >>
> >> _______________________________________________
> >> ghc-devs mailing list
> >> ghc-devs at haskell.org
> >> http://www.haskell.org/mailman/listinfo/ghc-devs
> >>
> >>
> >>
> >> _______________________________________________
> >> Libraries mailing list
> >> Libraries at haskell.org
> >> http://www.haskell.org/mailman/listinfo/libraries
> >>
>
> _______________________________________________
> ghc-devs mailing list
> ghc-devs at haskell.org
> http://www.haskell.org/mailman/listinfo/ghc-devs
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/ghc-devs/attachments/20140326/4e273dbf/attachment-0001.html>

From ghc-dev at maartenfaddegon.nl  Thu Mar 27 10:27:13 2014
From: ghc-dev at maartenfaddegon.nl (Maarten Faddegon)
Date: Thu, 27 Mar 2014 10:27:13 +0000
Subject: Wired-in packages not found
Message-ID: <5333FD01.7080208@maartenfaddegon.nl>

Dear GHC-devs,

I want to experiment with the RTS of GHC but the compiler I built has 
problems finding some wired-in packages. How can I include these?

This is what I did:

* Download ghc-7.6.3 sources.
* Make some changes in rts/
* ./configure && make
* inplace/bin/ghc-stage2 --make my_example.lhs -v

And this is the output produced by the last step:

...
wired-in package ghc-prim mapped to ghc-prim-0.3.0.0-inplace
wired-in package integer-gmp mapped to integer-gmp-0.5.0.0-inplace
wired-in package base mapped to base-4.6.0.1-inplace
wired-in package rts mapped to builtin_rts
wired-in package template-haskell not found.
wired-in package dph-seq not found.
wired-in package dph-par not found.
...
my_example.lhs:88:8:
     Could not find module `Language.Haskell.TH'
     Locations searched:
       Language/Haskell/TH.hs
       Language/Haskell/TH.lhs

Thanks,

Maarten Faddegon

From eir at cis.upenn.edu  Thu Mar 27 11:41:40 2014
From: eir at cis.upenn.edu (Richard Eisenberg)
Date: Thu, 27 Mar 2014 07:41:40 -0400
Subject: Wired-in packages not found
In-Reply-To: <5333FD01.7080208@maartenfaddegon.nl>
References: <5333FD01.7080208@maartenfaddegon.nl>
Message-ID: <EC1B754D-AD8B-4CFB-AA5F-95A56EFFFEBC@cis.upenn.edu>

Did you `./sync-all get`? Did you `perl boot`? You may want to check out the "Building GHC" section of https://ghc.haskell.org/trac/ghc/wiki/Building to make sure you've followed all the steps.

I hope this helps,
Richard

On Mar 27, 2014, at 6:27 AM, Maarten Faddegon <ghc-dev at maartenfaddegon.nl> wrote:

> Dear GHC-devs,
> 
> I want to experiment with the RTS of GHC but the compiler I built has problems finding some wired-in packages. How can I include these?
> 
> This is what I did:
> 
> * Download ghc-7.6.3 sources.
> * Make some changes in rts/
> * ./configure && make
> * inplace/bin/ghc-stage2 --make my_example.lhs -v
> 
> And this is the output produced by the last step:
> 
> ...
> wired-in package ghc-prim mapped to ghc-prim-0.3.0.0-inplace
> wired-in package integer-gmp mapped to integer-gmp-0.5.0.0-inplace
> wired-in package base mapped to base-4.6.0.1-inplace
> wired-in package rts mapped to builtin_rts
> wired-in package template-haskell not found.
> wired-in package dph-seq not found.
> wired-in package dph-par not found.
> ...
> my_example.lhs:88:8:
>    Could not find module `Language.Haskell.TH'
>    Locations searched:
>      Language/Haskell/TH.hs
>      Language/Haskell/TH.lhs
> 
> Thanks,
> 
> Maarten Faddegon
> _______________________________________________
> ghc-devs mailing list
> ghc-devs at haskell.org
> http://www.haskell.org/mailman/listinfo/ghc-devs


From ghc-dev at maartenfaddegon.nl  Thu Mar 27 11:55:54 2014
From: ghc-dev at maartenfaddegon.nl (Maarten Faddegon)
Date: Thu, 27 Mar 2014 11:55:54 +0000
Subject: Wired-in packages not found
In-Reply-To: <EC1B754D-AD8B-4CFB-AA5F-95A56EFFFEBC@cis.upenn.edu>
References: <5333FD01.7080208@maartenfaddegon.nl>
 <EC1B754D-AD8B-4CFB-AA5F-95A56EFFFEBC@cis.upenn.edu>
Message-ID: <533411CA.6060806@maartenfaddegon.nl>

Dear Richard, GHC-devs,

Thank you for your reply.

I am using the 7.6.3 source distribution. According to 
https://ghc.haskell.org/trac/ghc/wiki/Building/QuickStart "perl boot" is 
not necessary for source distributions. I did give it a try however 
(repeating step 3 and 4 afterwards), but it did not solve my problem. 
There is no sync-all script in the source distribution.

I went with a source distribution rather than checking out from the git 
repository because it was recommended on the "Getting the GHC 
Sources"-page and because I rather make my changes to an otherwise 
stable tree. Do you think this is a bad idea?

Cheers,

Maarten Faddegon

On 27/03/14 11:41, Richard Eisenberg wrote:
> Did you `./sync-all get`? Did you `perl boot`? You may want to check out the "Building GHC" section of https://ghc.haskell.org/trac/ghc/wiki/Building to make sure you've followed all the steps.
>
> I hope this helps,
> Richard
>
> On Mar 27, 2014, at 6:27 AM, Maarten Faddegon <ghc-dev at maartenfaddegon.nl> wrote:
>
>> Dear GHC-devs,
>>
>> I want to experiment with the RTS of GHC but the compiler I built has problems finding some wired-in packages. How can I include these?
>>
>> This is what I did:
>>
>> * Download ghc-7.6.3 sources.
>> * Make some changes in rts/
>> * ./configure && make
>> * inplace/bin/ghc-stage2 --make my_example.lhs -v
>>
>> And this is the output produced by the last step:
>>
>> ...
>> wired-in package ghc-prim mapped to ghc-prim-0.3.0.0-inplace
>> wired-in package integer-gmp mapped to integer-gmp-0.5.0.0-inplace
>> wired-in package base mapped to base-4.6.0.1-inplace
>> wired-in package rts mapped to builtin_rts
>> wired-in package template-haskell not found.
>> wired-in package dph-seq not found.
>> wired-in package dph-par not found.
>> ...
>> my_example.lhs:88:8:
>>     Could not find module `Language.Haskell.TH'
>>     Locations searched:
>>       Language/Haskell/TH.hs
>>       Language/Haskell/TH.lhs
>>
>> Thanks,
>>
>> Maarten Faddegon
>> _______________________________________________
>> ghc-devs mailing list
>> ghc-devs at haskell.org
>> http://www.haskell.org/mailman/listinfo/ghc-devs


From eir at cis.upenn.edu  Thu Mar 27 12:04:33 2014
From: eir at cis.upenn.edu (Richard Eisenberg)
Date: Thu, 27 Mar 2014 08:04:33 -0400
Subject: Wired-in packages not found
In-Reply-To: <533411CA.6060806@maartenfaddegon.nl>
References: <5333FD01.7080208@maartenfaddegon.nl>
 <EC1B754D-AD8B-4CFB-AA5F-95A56EFFFEBC@cis.upenn.edu>
 <533411CA.6060806@maartenfaddegon.nl>
Message-ID: <E9D515E7-70CC-4917-B435-8F61C8EB01C2@cis.upenn.edu>

Ah -- I understand better now. I'm afraid I've never worked with the source distribution, so I don't have further advice about that. It seems odd, though, that changing rts code would cause problems with wired-in packages. Have you tried just building without any edits and then putting your edits in?

Richard

On Mar 27, 2014, at 7:55 AM, Maarten Faddegon <ghc-dev at maartenfaddegon.nl> wrote:

> Dear Richard, GHC-devs,
> 
> Thank you for your reply.
> 
> I am using the 7.6.3 source distribution. According to https://ghc.haskell.org/trac/ghc/wiki/Building/QuickStart "perl boot" is not necessary for source distributions. I did give it a try however (repeating step 3 and 4 afterwards), but it did not solve my problem. There is no sync-all script in the source distribution.
> 
> I went with a source distribution rather than checking out from the git repository because it was recommended on the "Getting the GHC Sources"-page and because I rather make my changes to an otherwise stable tree. Do you think this is a bad idea?
> 
> Cheers,
> 
> Maarten Faddegon
> 
> On 27/03/14 11:41, Richard Eisenberg wrote:
>> Did you `./sync-all get`? Did you `perl boot`? You may want to check out the "Building GHC" section of https://ghc.haskell.org/trac/ghc/wiki/Building to make sure you've followed all the steps.
>> 
>> I hope this helps,
>> Richard
>> 
>> On Mar 27, 2014, at 6:27 AM, Maarten Faddegon <ghc-dev at maartenfaddegon.nl> wrote:
>> 
>>> Dear GHC-devs,
>>> 
>>> I want to experiment with the RTS of GHC but the compiler I built has problems finding some wired-in packages. How can I include these?
>>> 
>>> This is what I did:
>>> 
>>> * Download ghc-7.6.3 sources.
>>> * Make some changes in rts/
>>> * ./configure && make
>>> * inplace/bin/ghc-stage2 --make my_example.lhs -v
>>> 
>>> And this is the output produced by the last step:
>>> 
>>> ...
>>> wired-in package ghc-prim mapped to ghc-prim-0.3.0.0-inplace
>>> wired-in package integer-gmp mapped to integer-gmp-0.5.0.0-inplace
>>> wired-in package base mapped to base-4.6.0.1-inplace
>>> wired-in package rts mapped to builtin_rts
>>> wired-in package template-haskell not found.
>>> wired-in package dph-seq not found.
>>> wired-in package dph-par not found.
>>> ...
>>> my_example.lhs:88:8:
>>>    Could not find module `Language.Haskell.TH'
>>>    Locations searched:
>>>      Language/Haskell/TH.hs
>>>      Language/Haskell/TH.lhs
>>> 
>>> Thanks,
>>> 
>>> Maarten Faddegon
>>> _______________________________________________
>>> ghc-devs mailing list
>>> ghc-devs at haskell.org
>>> http://www.haskell.org/mailman/listinfo/ghc-devs
> 


From novadenizen at gmail.com  Thu Mar 27 13:49:33 2014
From: novadenizen at gmail.com (Ken Bateman)
Date: Thu, 27 Mar 2014 09:49:33 -0400
Subject: Wired-in packages not found
In-Reply-To: <E9D515E7-70CC-4917-B435-8F61C8EB01C2@cis.upenn.edu>
References: <5333FD01.7080208@maartenfaddegon.nl>
 <EC1B754D-AD8B-4CFB-AA5F-95A56EFFFEBC@cis.upenn.edu>
 <533411CA.6060806@maartenfaddegon.nl>
 <E9D515E7-70CC-4917-B435-8F61C8EB01C2@cis.upenn.edu>
Message-ID: <CACsFjbwxZAvM0mobcuXB7gugi82X4VedDpO3AaEc-dJaNLWM4w@mail.gmail.com>

I am not the most experienced ghc developer, but I ran "configure
--prefix=$HOME/ghcinst", then eventually I ran "make" and "make install",
and put $HOME/ghcinst/bin on my PATH.

Hope this helps

-Ken

-Ken


On Thu, Mar 27, 2014 at 8:04 AM, Richard Eisenberg <eir at cis.upenn.edu>wrote:

> Ah -- I understand better now. I'm afraid I've never worked with the
> source distribution, so I don't have further advice about that. It seems
> odd, though, that changing rts code would cause problems with wired-in
> packages. Have you tried just building without any edits and then putting
> your edits in?
>
> Richard
>
> On Mar 27, 2014, at 7:55 AM, Maarten Faddegon <ghc-dev at maartenfaddegon.nl>
> wrote:
>
> > Dear Richard, GHC-devs,
> >
> > Thank you for your reply.
> >
> > I am using the 7.6.3 source distribution. According to
> https://ghc.haskell.org/trac/ghc/wiki/Building/QuickStart "perl boot" is
> not necessary for source distributions. I did give it a try however
> (repeating step 3 and 4 afterwards), but it did not solve my problem. There
> is no sync-all script in the source distribution.
> >
> > I went with a source distribution rather than checking out from the git
> repository because it was recommended on the "Getting the GHC Sources"-page
> and because I rather make my changes to an otherwise stable tree. Do you
> think this is a bad idea?
> >
> > Cheers,
> >
> > Maarten Faddegon
> >
> > On 27/03/14 11:41, Richard Eisenberg wrote:
> >> Did you `./sync-all get`? Did you `perl boot`? You may want to check
> out the "Building GHC" section of
> https://ghc.haskell.org/trac/ghc/wiki/Building to make sure you've
> followed all the steps.
> >>
> >> I hope this helps,
> >> Richard
> >>
> >> On Mar 27, 2014, at 6:27 AM, Maarten Faddegon <
> ghc-dev at maartenfaddegon.nl> wrote:
> >>
> >>> Dear GHC-devs,
> >>>
> >>> I want to experiment with the RTS of GHC but the compiler I built has
> problems finding some wired-in packages. How can I include these?
> >>>
> >>> This is what I did:
> >>>
> >>> * Download ghc-7.6.3 sources.
> >>> * Make some changes in rts/
> >>> * ./configure && make
> >>> * inplace/bin/ghc-stage2 --make my_example.lhs -v
> >>>
> >>> And this is the output produced by the last step:
> >>>
> >>> ...
> >>> wired-in package ghc-prim mapped to ghc-prim-0.3.0.0-inplace
> >>> wired-in package integer-gmp mapped to integer-gmp-0.5.0.0-inplace
> >>> wired-in package base mapped to base-4.6.0.1-inplace
> >>> wired-in package rts mapped to builtin_rts
> >>> wired-in package template-haskell not found.
> >>> wired-in package dph-seq not found.
> >>> wired-in package dph-par not found.
> >>> ...
> >>> my_example.lhs:88:8:
> >>>    Could not find module `Language.Haskell.TH'
> >>>    Locations searched:
> >>>      Language/Haskell/TH.hs
> >>>      Language/Haskell/TH.lhs
> >>>
> >>> Thanks,
> >>>
> >>> Maarten Faddegon
> >>> _______________________________________________
> >>> ghc-devs mailing list
> >>> ghc-devs at haskell.org
> >>> http://www.haskell.org/mailman/listinfo/ghc-devs
> >
>
> _______________________________________________
> ghc-devs mailing list
> ghc-devs at haskell.org
> http://www.haskell.org/mailman/listinfo/ghc-devs
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/ghc-devs/attachments/20140327/dd41b97b/attachment.html>

From ghc-dev at maartenfaddegon.nl  Thu Mar 27 15:51:40 2014
From: ghc-dev at maartenfaddegon.nl (Maarten Faddegon)
Date: Thu, 27 Mar 2014 15:51:40 +0000
Subject: Wired-in packages not found
In-Reply-To: <E9D515E7-70CC-4917-B435-8F61C8EB01C2@cis.upenn.edu>
References: <5333FD01.7080208@maartenfaddegon.nl>
 <EC1B754D-AD8B-4CFB-AA5F-95A56EFFFEBC@cis.upenn.edu>
 <533411CA.6060806@maartenfaddegon.nl>
 <E9D515E7-70CC-4917-B435-8F61C8EB01C2@cis.upenn.edu>
Message-ID: <5334490C.5050700@maartenfaddegon.nl>

Dear Richard,

I tried rebuilding a fresh source distribution which has the same 
problem. I simply don't think template-haskell is included in the source 
distribution.

I also tried building ghc from the git repository. This time I had (a 
little bit) more success: ghc builds and has template-haskell wired-in. 
However, as I feared, some development in template-haskell's git 
repository is going on that is not compatible with the example I try to 
compile (ClassP is depricated).

Maarten

On 27/03/14 12:04, Richard Eisenberg wrote:
> Ah -- I understand better now. I'm afraid I've never worked with the source distribution, so I don't have further advice about that. It seems odd, though, that changing rts code would cause problems with wired-in packages. Have you tried just building without any edits and then putting your edits in?
>
> Richard
>
> On Mar 27, 2014, at 7:55 AM, Maarten Faddegon <ghc-dev at maartenfaddegon.nl> wrote:
>
>> Dear Richard, GHC-devs,
>>
>> Thank you for your reply.
>>
>> I am using the 7.6.3 source distribution. According to https://ghc.haskell.org/trac/ghc/wiki/Building/QuickStart "perl boot" is not necessary for source distributions. I did give it a try however (repeating step 3 and 4 afterwards), but it did not solve my problem. There is no sync-all script in the source distribution.
>>
>> I went with a source distribution rather than checking out from the git repository because it was recommended on the "Getting the GHC Sources"-page and because I rather make my changes to an otherwise stable tree. Do you think this is a bad idea?
>>
>> Cheers,
>>
>> Maarten Faddegon
>>
>> On 27/03/14 11:41, Richard Eisenberg wrote:
>>> Did you `./sync-all get`? Did you `perl boot`? You may want to check out the "Building GHC" section of https://ghc.haskell.org/trac/ghc/wiki/Building to make sure you've followed all the steps.
>>>
>>> I hope this helps,
>>> Richard
>>>
>>> On Mar 27, 2014, at 6:27 AM, Maarten Faddegon <ghc-dev at maartenfaddegon.nl> wrote:
>>>
>>>> Dear GHC-devs,
>>>>
>>>> I want to experiment with the RTS of GHC but the compiler I built has problems finding some wired-in packages. How can I include these?
>>>>
>>>> This is what I did:
>>>>
>>>> * Download ghc-7.6.3 sources.
>>>> * Make some changes in rts/
>>>> * ./configure && make
>>>> * inplace/bin/ghc-stage2 --make my_example.lhs -v
>>>>
>>>> And this is the output produced by the last step:
>>>>
>>>> ...
>>>> wired-in package ghc-prim mapped to ghc-prim-0.3.0.0-inplace
>>>> wired-in package integer-gmp mapped to integer-gmp-0.5.0.0-inplace
>>>> wired-in package base mapped to base-4.6.0.1-inplace
>>>> wired-in package rts mapped to builtin_rts
>>>> wired-in package template-haskell not found.
>>>> wired-in package dph-seq not found.
>>>> wired-in package dph-par not found.
>>>> ...
>>>> my_example.lhs:88:8:
>>>>     Could not find module `Language.Haskell.TH'
>>>>     Locations searched:
>>>>       Language/Haskell/TH.hs
>>>>       Language/Haskell/TH.lhs
>>>>
>>>> Thanks,
>>>>
>>>> Maarten Faddegon
>>>> _______________________________________________
>>>> ghc-devs mailing list
>>>> ghc-devs at haskell.org
>>>> http://www.haskell.org/mailman/listinfo/ghc-devs


From austin at well-typed.com  Thu Mar 27 16:39:26 2014
From: austin at well-typed.com (Austin Seipp)
Date: Thu, 27 Mar 2014 11:39:26 -0500
Subject: Wired-in packages not found
In-Reply-To: <5334490C.5050700@maartenfaddegon.nl>
References: <5333FD01.7080208@maartenfaddegon.nl>
 <EC1B754D-AD8B-4CFB-AA5F-95A56EFFFEBC@cis.upenn.edu>
 <533411CA.6060806@maartenfaddegon.nl>
 <E9D515E7-70CC-4917-B435-8F61C8EB01C2@cis.upenn.edu>
 <5334490C.5050700@maartenfaddegon.nl>
Message-ID: <CAEs96n1jq_njpQcgTDrb9DOENLsZW-4nHb+J6Qt_sOmRZYhTXQ@mail.gmail.com>

Template Haskell is certainly included in the 7.6.3 source
distribution - but I'm afraid off hand, I couldn't tell you why it
doesn't seem to be picked up by your compilation.

FWIW, if you want a change merged upstream, it's encouraged you use
GHC from git and make the change there (because there have been a lot
of changes in HEAD since then). If I remember correctly, the Pred
change in template-haskell didn't even touch the compiler. The changes
are here:

https://github.com/ghc/packages-template-haskell/commit/9b128b3c0317283edb0759479e2e26d351b86e58
https://github.com/ghc/packages-template-haskell/commit/a02ef9d827c4473e5e4efc84d7a8a987f51522aa
https://github.com/ghc/packages-template-haskell/commit/57b662c3efd8579595c8642fce2d4cd60ba4ec0b

If you *really* don't want to update your example, you *might* get
away with reverting these commits in the template-haskell repository
(located under libraries/template-haskell after using ./sync-all), and
then build. But it's probably better if you can adapt your example to
match HEAD, if possible.

On Thu, Mar 27, 2014 at 10:51 AM, Maarten Faddegon
<ghc-dev at maartenfaddegon.nl> wrote:
> Dear Richard,
>
> I tried rebuilding a fresh source distribution which has the same problem. I
> simply don't think template-haskell is included in the source distribution.
>
> I also tried building ghc from the git repository. This time I had (a little
> bit) more success: ghc builds and has template-haskell wired-in. However, as
> I feared, some development in template-haskell's git repository is going on
> that is not compatible with the example I try to compile (ClassP is
> depricated).
>
> Maarten
>
>
> On 27/03/14 12:04, Richard Eisenberg wrote:
>>
>> Ah -- I understand better now. I'm afraid I've never worked with the
>> source distribution, so I don't have further advice about that. It seems
>> odd, though, that changing rts code would cause problems with wired-in
>> packages. Have you tried just building without any edits and then putting
>> your edits in?
>>
>> Richard
>>
>> On Mar 27, 2014, at 7:55 AM, Maarten Faddegon <ghc-dev at maartenfaddegon.nl>
>> wrote:
>>
>>> Dear Richard, GHC-devs,
>>>
>>> Thank you for your reply.
>>>
>>> I am using the 7.6.3 source distribution. According to
>>> https://ghc.haskell.org/trac/ghc/wiki/Building/QuickStart "perl boot" is not
>>> necessary for source distributions. I did give it a try however (repeating
>>> step 3 and 4 afterwards), but it did not solve my problem. There is no
>>> sync-all script in the source distribution.
>>>
>>> I went with a source distribution rather than checking out from the git
>>> repository because it was recommended on the "Getting the GHC Sources"-page
>>> and because I rather make my changes to an otherwise stable tree. Do you
>>> think this is a bad idea?
>>>
>>> Cheers,
>>>
>>> Maarten Faddegon
>>>
>>> On 27/03/14 11:41, Richard Eisenberg wrote:
>>>>
>>>> Did you `./sync-all get`? Did you `perl boot`? You may want to check out
>>>> the "Building GHC" section of https://ghc.haskell.org/trac/ghc/wiki/Building
>>>> to make sure you've followed all the steps.
>>>>
>>>> I hope this helps,
>>>> Richard
>>>>
>>>> On Mar 27, 2014, at 6:27 AM, Maarten Faddegon
>>>> <ghc-dev at maartenfaddegon.nl> wrote:
>>>>
>>>>> Dear GHC-devs,
>>>>>
>>>>> I want to experiment with the RTS of GHC but the compiler I built has
>>>>> problems finding some wired-in packages. How can I include these?
>>>>>
>>>>> This is what I did:
>>>>>
>>>>> * Download ghc-7.6.3 sources.
>>>>> * Make some changes in rts/
>>>>> * ./configure && make
>>>>> * inplace/bin/ghc-stage2 --make my_example.lhs -v
>>>>>
>>>>> And this is the output produced by the last step:
>>>>>
>>>>> ...
>>>>> wired-in package ghc-prim mapped to ghc-prim-0.3.0.0-inplace
>>>>> wired-in package integer-gmp mapped to integer-gmp-0.5.0.0-inplace
>>>>> wired-in package base mapped to base-4.6.0.1-inplace
>>>>> wired-in package rts mapped to builtin_rts
>>>>> wired-in package template-haskell not found.
>>>>> wired-in package dph-seq not found.
>>>>> wired-in package dph-par not found.
>>>>> ...
>>>>> my_example.lhs:88:8:
>>>>>     Could not find module `Language.Haskell.TH'
>>>>>     Locations searched:
>>>>>       Language/Haskell/TH.hs
>>>>>       Language/Haskell/TH.lhs
>>>>>
>>>>> Thanks,
>>>>>
>>>>> Maarten Faddegon
>>>>> _______________________________________________
>>>>> ghc-devs mailing list
>>>>> ghc-devs at haskell.org
>>>>> http://www.haskell.org/mailman/listinfo/ghc-devs
>
>
> _______________________________________________
> ghc-devs mailing list
> ghc-devs at haskell.org
> http://www.haskell.org/mailman/listinfo/ghc-devs
>

-- 
Regards,

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

From ghc-dev at maartenfaddegon.nl  Thu Mar 27 17:23:04 2014
From: ghc-dev at maartenfaddegon.nl (Maarten Faddegon)
Date: Thu, 27 Mar 2014 17:23:04 +0000
Subject: Wired-in packages not found
In-Reply-To: <CAEs96n1jq_njpQcgTDrb9DOENLsZW-4nHb+J6Qt_sOmRZYhTXQ@mail.gmail.com>
References: <5333FD01.7080208@maartenfaddegon.nl>	<EC1B754D-AD8B-4CFB-AA5F-95A56EFFFEBC@cis.upenn.edu>	<533411CA.6060806@maartenfaddegon.nl>	<E9D515E7-70CC-4917-B435-8F61C8EB01C2@cis.upenn.edu>	<5334490C.5050700@maartenfaddegon.nl>
 <CAEs96n1jq_njpQcgTDrb9DOENLsZW-4nHb+J6Qt_sOmRZYhTXQ@mail.gmail.com>
Message-ID: <53345E78.6050106@maartenfaddegon.nl>

Dear Austin, Richard,

Thank you for your help!

I updated my example and as far as I can see everything is working as 
expected now with the compiler build from the git repository.

Best,

Maarten


On 27/03/14 16:39, Austin Seipp wrote:
> Template Haskell is certainly included in the 7.6.3 source
> distribution - but I'm afraid off hand, I couldn't tell you why it
> doesn't seem to be picked up by your compilation.
>
> FWIW, if you want a change merged upstream, it's encouraged you use
> GHC from git and make the change there (because there have been a lot
> of changes in HEAD since then). If I remember correctly, the Pred
> change in template-haskell didn't even touch the compiler. The changes
> are here:
>
> https://github.com/ghc/packages-template-haskell/commit/9b128b3c0317283edb0759479e2e26d351b86e58
> https://github.com/ghc/packages-template-haskell/commit/a02ef9d827c4473e5e4efc84d7a8a987f51522aa
> https://github.com/ghc/packages-template-haskell/commit/57b662c3efd8579595c8642fce2d4cd60ba4ec0b
>
> If you *really* don't want to update your example, you *might* get
> away with reverting these commits in the template-haskell repository
> (located under libraries/template-haskell after using ./sync-all), and
> then build. But it's probably better if you can adapt your example to
> match HEAD, if possible.
>
> On Thu, Mar 27, 2014 at 10:51 AM, Maarten Faddegon
> <ghc-dev at maartenfaddegon.nl> wrote:
>> Dear Richard,
>>
>> I tried rebuilding a fresh source distribution which has the same problem. I
>> simply don't think template-haskell is included in the source distribution.
>>
>> I also tried building ghc from the git repository. This time I had (a little
>> bit) more success: ghc builds and has template-haskell wired-in. However, as
>> I feared, some development in template-haskell's git repository is going on
>> that is not compatible with the example I try to compile (ClassP is
>> depricated).
>>
>> Maarten
>>
>>
>> On 27/03/14 12:04, Richard Eisenberg wrote:
>>> Ah -- I understand better now. I'm afraid I've never worked with the
>>> source distribution, so I don't have further advice about that. It seems
>>> odd, though, that changing rts code would cause problems with wired-in
>>> packages. Have you tried just building without any edits and then putting
>>> your edits in?
>>>
>>> Richard
>>>
>>> On Mar 27, 2014, at 7:55 AM, Maarten Faddegon <ghc-dev at maartenfaddegon.nl>
>>> wrote:
>>>
>>>> Dear Richard, GHC-devs,
>>>>
>>>> Thank you for your reply.
>>>>
>>>> I am using the 7.6.3 source distribution. According to
>>>> https://ghc.haskell.org/trac/ghc/wiki/Building/QuickStart "perl boot" is not
>>>> necessary for source distributions. I did give it a try however (repeating
>>>> step 3 and 4 afterwards), but it did not solve my problem. There is no
>>>> sync-all script in the source distribution.
>>>>
>>>> I went with a source distribution rather than checking out from the git
>>>> repository because it was recommended on the "Getting the GHC Sources"-page
>>>> and because I rather make my changes to an otherwise stable tree. Do you
>>>> think this is a bad idea?
>>>>
>>>> Cheers,
>>>>
>>>> Maarten Faddegon
>>>>
>>>> On 27/03/14 11:41, Richard Eisenberg wrote:
>>>>> Did you `./sync-all get`? Did you `perl boot`? You may want to check out
>>>>> the "Building GHC" section of https://ghc.haskell.org/trac/ghc/wiki/Building
>>>>> to make sure you've followed all the steps.
>>>>>
>>>>> I hope this helps,
>>>>> Richard
>>>>>
>>>>> On Mar 27, 2014, at 6:27 AM, Maarten Faddegon
>>>>> <ghc-dev at maartenfaddegon.nl> wrote:
>>>>>
>>>>>> Dear GHC-devs,
>>>>>>
>>>>>> I want to experiment with the RTS of GHC but the compiler I built has
>>>>>> problems finding some wired-in packages. How can I include these?
>>>>>>
>>>>>> This is what I did:
>>>>>>
>>>>>> * Download ghc-7.6.3 sources.
>>>>>> * Make some changes in rts/
>>>>>> * ./configure && make
>>>>>> * inplace/bin/ghc-stage2 --make my_example.lhs -v
>>>>>>
>>>>>> And this is the output produced by the last step:
>>>>>>
>>>>>> ...
>>>>>> wired-in package ghc-prim mapped to ghc-prim-0.3.0.0-inplace
>>>>>> wired-in package integer-gmp mapped to integer-gmp-0.5.0.0-inplace
>>>>>> wired-in package base mapped to base-4.6.0.1-inplace
>>>>>> wired-in package rts mapped to builtin_rts
>>>>>> wired-in package template-haskell not found.
>>>>>> wired-in package dph-seq not found.
>>>>>> wired-in package dph-par not found.
>>>>>> ...
>>>>>> my_example.lhs:88:8:
>>>>>>      Could not find module `Language.Haskell.TH'
>>>>>>      Locations searched:
>>>>>>        Language/Haskell/TH.hs
>>>>>>        Language/Haskell/TH.lhs
>>>>>>
>>>>>> Thanks,
>>>>>>
>>>>>> Maarten Faddegon
>>>>>> _______________________________________________
>>>>>> ghc-devs mailing list
>>>>>> ghc-devs at haskell.org
>>>>>> http://www.haskell.org/mailman/listinfo/ghc-devs
>>
>> _______________________________________________
>> ghc-devs mailing list
>> ghc-devs at haskell.org
>> http://www.haskell.org/mailman/listinfo/ghc-devs
>>


From carter.schonwald at gmail.com  Fri Mar 28 05:07:30 2014
From: carter.schonwald at gmail.com (Carter Schonwald)
Date: Fri, 28 Mar 2014 01:07:30 -0400
Subject: help understanding the validate_build_xhtml failure of ./validate
 for my CPP patch
In-Reply-To: <56794DAB-D6C8-4338-864A-1331F9736AF6@me.com>
References: <CAHYVw0xX_pmNi_w=41tpho1W8x6wHpJOP6U8ymBeYH4W-+ZfUw@mail.gmail.com>
 <56794DAB-D6C8-4338-864A-1331F9736AF6@me.com>
Message-ID: <CAHYVw0xO-QLBCaO0WqwVZRNZtcDZfKt9LENF0Diyy7f0-u6nrw@mail.gmail.com>

I figured it out!

theres a mini configure.ac generated by distrib/configure.ac.in thats used
to setup the ghc settings file at install time!

https://github.com/cartazio/ghc/tree/cpp_silly-contrib-configure-in is my
current set of patches, though it needs some rebasing, cleanup, and code
review etcetc,

will update the (admittedly too long )  trac ticket with this info


On Mon, Mar 24, 2014 at 6:39 AM, Malcolm Wallace <malcolm.wallace at me.com>wrote:

>
> On 23 Mar 2014, at 20:33, Carter Schonwald wrote:
>
> > Hey all, I'm trying to get my CPP_Setttings patch to validate,
> > and i'm trying to understand why my validate is failing. At this point
> im stumped and I really could  use some help!
>
>
> This looks like the key information:
>
> > Building xhtml-3000.2.1...
> > Preprocessing library xhtml-3000.2.1...
> > ghc: could not execute:
>
> Ghc is reporting that it could not execute "".  This suggests the
> commandline for external preprocessing is incorrectly formed.
>
> Regards,
>     Malcolm
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/ghc-devs/attachments/20140328/ce95ae83/attachment.html>

From mark.lentczner at gmail.com  Fri Mar 28 16:17:18 2014
From: mark.lentczner at gmail.com (Mark Lentczner)
Date: Fri, 28 Mar 2014 09:17:18 -0700
Subject: We need to add role annotations for 7.8
In-Reply-To: <59543203684B2244980D7E4057D5FBC1488BD709@DB3EX14MBXC308.europe.corp.microsoft.com>
References: <78518EC7-BC18-4732-90B6-1AB37048D2A3@cis.upenn.edu>
 <CAEs96n1Xxp9qmXLBf6XqKbLH3kEE3bVLcpLAuFHoVip0N+1D=w@mail.gmail.com>
 <CAEs96n1dVs8SC6an_5eCsx1aCPwbNjbahhNrKAeaSCv1=Qe3gw@mail.gmail.com>
 <CAEs96n0SCjD6_C7VkeL0NUCY+v-fZseeL=iRFZG9fL9b74AjwQ@mail.gmail.com>
 <CAEs96n1WnrVtyjk2f3jOgUZg2M4EwPSA-9bnN6+9dL1p+=Ea0w@mail.gmail.com>
 <CAK-tuPahbPSd4fxjRCMKHYPcsPuzsM3CnBFMBvkoYbAZkVmmjw@mail.gmail.com>
 <CAAOoiFZKYXzqdfS1PVfG4W_H9ig8iw3MrcTFWu5GrP4C6sgEoA@mail.gmail.com>
 <CAKFCL4Xz_W9of6SyXBsFfk+6Kp4E=T7pjPt4ZhqjqqY9wsixkw@mail.gmail.com>
 <59543203684B2244980D7E4057D5FBC1488BA55B@DB3EX14MBXC308.europe.corp.microsoft.com>
 <CAAOoiFaof89nQBRStVD38hmHQbBeNNQOU1+YEdaq_iwieKgGJA@mail.gmail.com>
 <CAJumaK_-dxYW=raqvCyfp1h-9XFwj2eKq_smWHng=DuUChfZ4w@mail.gmail.com>
 <2F1D91F2-0AD6-4E98-81E3-9A95E6024BA3@gmail.com>
 <8FD54493-CC52-4B90-9DD2-E7C91024FC30@cis.upenn.edu>
 <53313E49.1040405@ifi.lmu.de> <8761n2ob4f.fsf@gnu.org>
 <533165DF.5030206@ifi.lmu.de>
 <CAAOoiFYJiGmpxPDYTbcHO107XxZMNRWpvMVZA5=waBv35oYR0g@mail.gmail.com>
 <59543203684B2244980D7E4057D5FBC1488BD709@DB3EX14MBXC308.europe.corp.microsoft.com>
Message-ID: <CAAOoiFYy31jtcoRxf6vKKGC9J9MENOk=aLYG=g4Xe9kkQcR1eA@mail.gmail.com>

*Apologies*
On Tue, Mar 25, 2014 at 8:47 AM, Simon Peyton Jones
<simonpj at microsoft.com>wrote:

> The situation today is that
> ?         A client of a library can use GND to do bad things to the
> library (e.g. change the ?key? type of (Map key value)).
> ?         Role annotations allow the library author to prevent that
> happening.
> Would you say that means that we are ?compelled to suggest to library
> writers that they annotate??
>

Well... I don't think we should.

The reason is that this situation is very sad for it puts the burden upon
the library writer, for potential abuse of an extension to Haskell she
might not even be aware of! She writes a perfectly safe, reasonable
abstracted type, and bam, now has to worry about a very hard to understand
situation involving the interaction to two separate Haskell extensions. And
furthermore, adding that protection requires yet a third (CPP), and makes
the "protection" often as long as the abstract type itself.

Looking further ahead, when you say that ?there can be no migration from
> representational-by-default?, do you have data to support that?  Notably,
> any client not using GND could not observe a change. So simply seeing how
> many library modules use GND would be an upper bound on how many libraries
> would fail to compile you were to ask us to change the default.  Is that 1%
> of Hackage modules?  10%?  0.1%?  I don?t know.


You are wrong that use of GND is the upper bound: The burden is on the type
author, not the GND user. And so, while only a small percent of Hackage
uses GND (though I note that more and more literature promotes GND (very
handy in Shake, for example)...) in order to keep them from breaking, a
potentially much larger percentage of Hackage has to get fixed.

What's more, the ability to remedy the situation is in the wrong place: If
the default changes, and my GND library breaks, all my users are broken,
and worse, I can't do anything about it until I compel the libraries I
depend on to annotate.

This is why we can't ever change the default.


On Tue, Mar 25, 2014 at 4:23 PM, Richard Eisenberg <eir at cis.upenn.edu>
 wrote:

> The problem is, in the actual datatype definition, the constraints tend
> not to appear? Should we look around for other functions with constraints?


Right - we've been advocating removing them for years, and only placing the
constraints on the functions that need them, since they really present no
constraint on the data type itself. Of course, the presence of GND and
roles means that they now *would be* saying something about the type - as
they are indicating that the integrity of the type requires the constraint.
So yes, a shift to using this as the marker for nominal would require a
change in developer habit. But so does annotation.

I agree that other heuristics are pretty fragile: names of modules,
presence of constraints in functions, and even status of constructor export
are all a) far too removed from the code site in question, and b) things
that are much more fluid during development. I would be against any of
these.


On Wed, Mar 26, 2014 at 8:46 PM, Edward Kmett <ekmett at gmail.com> wrote:

> Personally, looking at it 10 years on, having a nominal default would look
> pretty terrible to me.
> I'd be stuck annotating everything I write. Nothing easy could just be
> easy.
>

Agree whole-heartedly.
Worth reiterating: Easy things should not need annotation.


On Wed, Mar 26, 2014 at 11:44 PM, Ganesh Sittampalam <ganesh at earth.li>
 wrote:

> I think that in theory the basic principle should be that by default you
> can only write a GND if  you could have written it by hand in the same
> scope - i.e. you can only do it if you have access to the relevant
> methods and datatype constructors etc
>

This is much closer to the approach I wish had been taken: The burden is on
the correct party. The client of the lib, wishing to use it in a new way,
unbeknownst to the library author. I don't know enough about the type
theory, but could we have disallowed GND in the presence of type families
anywhere in the class being derived?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/ghc-devs/attachments/20140328/110b7223/attachment.html>

From mark.lentczner at gmail.com  Fri Mar 28 16:52:48 2014
From: mark.lentczner at gmail.com (Mark Lentczner)
Date: Fri, 28 Mar 2014 09:52:48 -0700
Subject: We need to add role annotations for 7.8
In-Reply-To: <CAAOoiFYy31jtcoRxf6vKKGC9J9MENOk=aLYG=g4Xe9kkQcR1eA@mail.gmail.com>
References: <78518EC7-BC18-4732-90B6-1AB37048D2A3@cis.upenn.edu>
 <CAEs96n1Xxp9qmXLBf6XqKbLH3kEE3bVLcpLAuFHoVip0N+1D=w@mail.gmail.com>
 <CAEs96n1dVs8SC6an_5eCsx1aCPwbNjbahhNrKAeaSCv1=Qe3gw@mail.gmail.com>
 <CAEs96n0SCjD6_C7VkeL0NUCY+v-fZseeL=iRFZG9fL9b74AjwQ@mail.gmail.com>
 <CAEs96n1WnrVtyjk2f3jOgUZg2M4EwPSA-9bnN6+9dL1p+=Ea0w@mail.gmail.com>
 <CAK-tuPahbPSd4fxjRCMKHYPcsPuzsM3CnBFMBvkoYbAZkVmmjw@mail.gmail.com>
 <CAAOoiFZKYXzqdfS1PVfG4W_H9ig8iw3MrcTFWu5GrP4C6sgEoA@mail.gmail.com>
 <CAKFCL4Xz_W9of6SyXBsFfk+6Kp4E=T7pjPt4ZhqjqqY9wsixkw@mail.gmail.com>
 <59543203684B2244980D7E4057D5FBC1488BA55B@DB3EX14MBXC308.europe.corp.microsoft.com>
 <CAAOoiFaof89nQBRStVD38hmHQbBeNNQOU1+YEdaq_iwieKgGJA@mail.gmail.com>
 <CAJumaK_-dxYW=raqvCyfp1h-9XFwj2eKq_smWHng=DuUChfZ4w@mail.gmail.com>
 <2F1D91F2-0AD6-4E98-81E3-9A95E6024BA3@gmail.com>
 <8FD54493-CC52-4B90-9DD2-E7C91024FC30@cis.upenn.edu>
 <53313E49.1040405@ifi.lmu.de> <8761n2ob4f.fsf@gnu.org>
 <533165DF.5030206@ifi.lmu.de>
 <CAAOoiFYJiGmpxPDYTbcHO107XxZMNRWpvMVZA5=waBv35oYR0g@mail.gmail.com>
 <59543203684B2244980D7E4057D5FBC1488BD709@DB3EX14MBXC308.europe.corp.microsoft.com>
 <CAAOoiFYy31jtcoRxf6vKKGC9J9MENOk=aLYG=g4Xe9kkQcR1eA@mail.gmail.com>
Message-ID: <CAAOoiFYjVpeLFLH_yXSoXGxVSs4+KQKfwXytE3Qc-g3nSv4fTQ@mail.gmail.com>

The first line was supposed to say: *Apologies for the delayed and
multi-message response.*
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/ghc-devs/attachments/20140328/3db6c655/attachment.html>

From varosi at gmail.com  Fri Mar 28 17:08:00 2014
From: varosi at gmail.com (eng. Vassil Ognyanov Keremidchiev)
Date: Fri, 28 Mar 2014 19:08:00 +0200
Subject: Fwd: Trying to compile GHC under Ubuntu as a cross-compiler for ARM
In-Reply-To: <CAGaP9ksznSpGyQV1J=g_098CaGW5fF_m-Tyy-Zo5x_CoMCkmtg@mail.gmail.com>
References: <CAGaP9ksznSpGyQV1J=g_098CaGW5fF_m-Tyy-Zo5x_CoMCkmtg@mail.gmail.com>
Message-ID: <CAGaP9kuHVgxaG_+2XooLNpyo9kTKQOHRpyBt59DHU9Zgc6LStA@mail.gmail.com>

Hello!

Could someone help me with compiling GHC under Ubuntu as a ARM
cross-compiler?

Currently I have done those steps:
sudo apt-get update
sudo apt-get install autoconf alex happy libtool autopoint zlib1g-dev
libncurses5-dev ghc-haddock
sudo export PATH=~/.cabal/bin:$PATH
sudo cabal install --reinstall happy alex terminfo libffi html regex-compat

git clone http://darcs.haskell.org/ghc.git
cd ghc

./sync-all --no-dph get
./sync-all pull
./boot
sudo ./configure --target=arm-linux-gnueabi --enable-unregisterised
cp mk/build.mk.sample mk/build.mk
# here I enable quick-cross configuration
sudo make

and I get:

echo "compiler_stage1_depfile_c_asm_EXISTS = YES" >>
compiler/stage1/build/.depend-v.c_asm.tmp
mv compiler/stage1/build/.depend-v.c_asm.tmp
compiler/stage1/build/.depend-v.c_asm
inplace/bin/deriveConstants --gen-header -o
includes/dist-derivedconstants/header/DerivedConstants.h --tmpdir
includes/dist-derivedconstants/header/ --gcc-program "/usr/bin/gcc"
--gcc-flag -fno-stack-protector --gcc-flag -Iincludes --gcc-flag
-Iincludes/dist --gcc-flag -Iincludes/dist-derivedconstants/header
--gcc-flag -Iincludes/dist-ghcconstants/header --gcc-flag -Irts --gcc-flag
-fcommon --nm-program "/usr/bin/arm-linux-gnueabi-nm"
/usr/bin/arm-linux-gnueabi-nm: includes/dist-derivedconstants/header/tmp.o:
File format not recognized
deriveConstants: readProcess: /usr/bin/arm-linux-gnueabi-nm
"includes/dist-derivedconstants/header/tmp.o" (exit 1): failed
make[1]: *** [includes/dist-derivedconstants/header/DerivedConstants.h]
Error 1
make: *** [all] Error 2


What I have done wrong? I did not understand the error message well, too.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/ghc-devs/attachments/20140328/f86008e3/attachment.html>

From karel.gardas at centrum.cz  Fri Mar 28 18:09:08 2014
From: karel.gardas at centrum.cz (Karel Gardas)
Date: Fri, 28 Mar 2014 19:09:08 +0100
Subject: Fwd: Trying to compile GHC under Ubuntu as a cross-compiler for
 ARM
In-Reply-To: <CAGaP9kuHVgxaG_+2XooLNpyo9kTKQOHRpyBt59DHU9Zgc6LStA@mail.gmail.com>
References: <CAGaP9ksznSpGyQV1J=g_098CaGW5fF_m-Tyy-Zo5x_CoMCkmtg@mail.gmail.com>
 <CAGaP9kuHVgxaG_+2XooLNpyo9kTKQOHRpyBt59DHU9Zgc6LStA@mail.gmail.com>
Message-ID: <5335BAC4.40304@centrum.cz>


Last time I did that (crossing to ARMv8) I needed to use 
--with-gcc=<cross compiler> option since for some reason I had not time 
to debug setting target triple with --target was not enough. Speaking 
about GHC HEAD as of new year eve (2014) time...

But well, since it this is already some time I'm not sure this was to 
cure issue like you have now, but at least you may give it a try...

Karel

On 03/28/14 06:08 PM, eng. Vassil Ognyanov Keremidchiev wrote:
> Hello!
>
> Could someone help me with compiling GHC under Ubuntu as a ARM
> cross-compiler?
>
> Currently I have done those steps:
> sudo apt-get update
> sudo apt-get install autoconf alex happy libtool autopoint zlib1g-dev
> libncurses5-dev ghc-haddock
> sudo export PATH=~/.cabal/bin:$PATH
> sudo cabal install --reinstall happy alex terminfo libffi html regex-compat
>
> git clone http://darcs.haskell.org/ghc.git
> cd ghc
>
> ./sync-all --no-dph get
> ./sync-all pull
> ./boot
> sudo ./configure --target=arm-linux-gnueabi --enable-unregisterised
> cp mk/build.mk.sample mk/build.mk <http://build.mk>
> # here I enable quick-cross configuration
> sudo make
>
> and I get:
>
> echo "compiler_stage1_depfile_c_asm_EXISTS = YES" >>
> compiler/stage1/build/.depend-v.c_asm.tmp
> mv compiler/stage1/build/.depend-v.c_asm.tmp
> compiler/stage1/build/.depend-v.c_asm
> inplace/bin/deriveConstants --gen-header -o
> includes/dist-derivedconstants/header/DerivedConstants.h --tmpdir
> includes/dist-derivedconstants/header/ --gcc-program "/usr/bin/gcc"
> --gcc-flag -fno-stack-protector --gcc-flag -Iincludes --gcc-flag
> -Iincludes/dist --gcc-flag -Iincludes/dist-derivedconstants/header
> --gcc-flag -Iincludes/dist-ghcconstants/header --gcc-flag -Irts
> --gcc-flag -fcommon --nm-program "/usr/bin/arm-linux-gnueabi-nm"
> /usr/bin/arm-linux-gnueabi-nm:
> includes/dist-derivedconstants/header/tmp.o: File format not recognized
> deriveConstants: readProcess: /usr/bin/arm-linux-gnueabi-nm
> "includes/dist-derivedconstants/header/tmp.o" (exit 1): failed
> make[1]: *** [includes/dist-derivedconstants/header/DerivedConstants.h]
> Error 1
> make: *** [all] Error 2
>
>
> What I have done wrong? I did not understand the error message well, too.
>
>
>
> _______________________________________________
> ghc-devs mailing list
> ghc-devs at haskell.org
> http://www.haskell.org/mailman/listinfo/ghc-devs


From eir at cis.upenn.edu  Fri Mar 28 19:56:21 2014
From: eir at cis.upenn.edu (Richard Eisenberg)
Date: Fri, 28 Mar 2014 15:56:21 -0400
Subject: We need to add role annotations for 7.8
In-Reply-To: <CAAOoiFYy31jtcoRxf6vKKGC9J9MENOk=aLYG=g4Xe9kkQcR1eA@mail.gmail.com>
References: <78518EC7-BC18-4732-90B6-1AB37048D2A3@cis.upenn.edu>
 <CAEs96n1Xxp9qmXLBf6XqKbLH3kEE3bVLcpLAuFHoVip0N+1D=w@mail.gmail.com>
 <CAEs96n1dVs8SC6an_5eCsx1aCPwbNjbahhNrKAeaSCv1=Qe3gw@mail.gmail.com>
 <CAEs96n0SCjD6_C7VkeL0NUCY+v-fZseeL=iRFZG9fL9b74AjwQ@mail.gmail.com>
 <CAEs96n1WnrVtyjk2f3jOgUZg2M4EwPSA-9bnN6+9dL1p+=Ea0w@mail.gmail.com>
 <CAK-tuPahbPSd4fxjRCMKHYPcsPuzsM3CnBFMBvkoYbAZkVmmjw@mail.gmail.com>
 <CAAOoiFZKYXzqdfS1PVfG4W_H9ig8iw3MrcTFWu5GrP4C6sgEoA@mail.gmail.com>
 <CAKFCL4Xz_W9of6SyXBsFfk+6Kp4E=T7pjPt4ZhqjqqY9wsixkw@mail.gmail.com>
 <59543203684B2244980D7E4057D5FBC1488BA55B@DB3EX14MBXC308.europe.corp.microsoft.com>
 <CAAOoiFaof89nQBRStVD38hmHQbBeNNQOU1+YEdaq_iwieKgGJA@mail.gmail.com>
 <CAJumaK_-dxYW=raqvCyfp1h-9XFwj2eKq_smWHng=DuUChfZ4w@mail.gmail.com>
 <2F1D91F2-0AD6-4E98-81E3-9A95E6024BA3@gmail.com>
 <8FD54493-CC52-4B90-9DD2-E7C91024FC30@cis.upenn.edu>
 <53313E49.1040405@ifi.lmu.de> <8761n2ob4f.fsf@gnu.org>
 <533165DF.5030206@ifi.lmu.de> <CAAOoiFYJiGmpxPDYTbcHO107XxZMNR!
 WpvMVZA5=waBv35oYR0g@mail.gmail.com>
 <59543203684B2244980D7E4057D5FBC1488BD709@DB3EX14MBXC308.europe.corp.microsoft.com>
 <CAAOoiFYy31jtcoRxf6vKKGC9J9MENOk=aLYG=g4Xe9kkQcR1eA@mail.gmail.com>
Message-ID: <7B4344AC-7EB2-4892-8C07-969456EC6602@cis.upenn.edu>

I think a few clarifications might help:

- Roles, as originally conceived, were not an attempt to make Unsafe code Safe. Instead, they make unsafe things safe. Before roles, it was quite possible to write Haskell code that would cause a seg fault at runtime. Now, this is (short of unsafeCoerce & friends) impossible, as far as we know. This is independent of any concern with Safe Haskell. That is why certain code that used to work with GND can no longer do so, and why there is no easy fix -- the old code is unsafe, not just Unsafe.

- Role annotations are never necessary to ensure type safety. To reiterate: all Haskell code, with or without type annotations, is now safe from the interaction between GND and TypeFamilies.

- The whole debate here is about *abstraction* -- whether or not a user outside of a library can fiddle with that library's expected invariants.

- Edward and Mark have said that with a default of a nominal role "Nothing easy could just be easy." Yet, we accept the need for deriving Eq and Show without question. I think, if we ignore its current alienness, a role annotation is on a similar order -- a role annotation (in a world with a nominal default) would be granting new capabilities to users of a type, just like adding instances of classes.

- If you could use GND only where the constructors are available, then some valid current use of GND would break, I believe. It would mean that GND would be unable to coerce a (Map String Int) to a (Map String Age), because the constructor of Set is (rightly) not exported. This would have a direct runtime significance for some users -- their code would run slower.

Richard

On Mar 28, 2014, at 12:17 PM, Mark Lentczner wrote:

> Apologies
> On Tue, Mar 25, 2014 at 8:47 AM, Simon Peyton Jones <simonpj at microsoft.com> wrote:
> The situation today is that
> ?         A client of a library can use GND to do bad things to the library (e.g. change the ?key? type of (Map key value)).
> ?         Role annotations allow the library author to prevent that happening.
> Would you say that means that we are ?compelled to suggest to library writers that they annotate??
> 
> Well... I don't think we should.
> 
> The reason is that this situation is very sad for it puts the burden upon the library writer, for potential abuse of an extension to Haskell she might not even be aware of! She writes a perfectly safe, reasonable abstracted type, and bam, now has to worry about a very hard to understand situation involving the interaction to two separate Haskell extensions. And furthermore, adding that protection requires yet a third (CPP), and makes the "protection" often as long as the abstract type itself.
> 
> Looking further ahead, when you say that ?there can be no migration from representational-by-default?, do you have data to support that?  Notably, any client not using GND could not observe a change. So simply seeing how many library modules use GND would be an upper bound on how many libraries would fail to compile you were to ask us to change the default.  Is that 1% of Hackage modules?  10%?  0.1%?  I don?t know.
> 
> You are wrong that use of GND is the upper bound: The burden is on the type author, not the GND user. And so, while only a small percent of Hackage uses GND (though I note that more and more literature promotes GND (very handy in Shake, for example)...) in order to keep them from breaking, a potentially much larger percentage of Hackage has to get fixed.
> 
> What's more, the ability to remedy the situation is in the wrong place: If the default changes, and my GND library breaks, all my users are broken, and worse, I can't do anything about it until I compel the libraries I depend on to annotate.
> 
> This is why we can't ever change the default.
>  
> 
> On Tue, Mar 25, 2014 at 4:23 PM, Richard Eisenberg <eir at cis.upenn.edu> wrote:
> The problem is, in the actual datatype definition, the constraints tend not to appear? Should we look around for other functions with constraints?
> 
> Right - we've been advocating removing them for years, and only placing the constraints on the functions that need them, since they really present no constraint on the data type itself. Of course, the presence of GND and roles means that they now would be saying something about the type - as they are indicating that the integrity of the type requires the constraint. So yes, a shift to using this as the marker for nominal would require a change in developer habit. But so does annotation.
> 
> I agree that other heuristics are pretty fragile: names of modules, presence of constraints in functions, and even status of constructor export are all a) far too removed from the code site in question, and b) things that are much more fluid during development. I would be against any of these.
> 
> 
> On Wed, Mar 26, 2014 at 8:46 PM, Edward Kmett <ekmett at gmail.com> wrote:
> Personally, looking at it 10 years on, having a nominal default would look pretty terrible to me. 
> I'd be stuck annotating everything I write. Nothing easy could just be easy. 
> 
> Agree whole-heartedly. 
> Worth reiterating: Easy things should not need annotation.
> 
> 
> On Wed, Mar 26, 2014 at 11:44 PM, Ganesh Sittampalam <ganesh at earth.li> wrote:
> I think that in theory the basic principle should be that by default you
> can only write a GND if  you could have written it by hand in the same
> scope - i.e. you can only do it if you have access to the relevant
> methods and datatype constructors etc
> 
> This is much closer to the approach I wish had been taken: The burden is on the correct party. The client of the lib, wishing to use it in a new way, unbeknownst to the library author. I don't know enough about the type theory, but could we have disallowed GND in the presence of type families anywhere in the class being derived?
> 
> _______________________________________________
> Libraries mailing list
> Libraries at haskell.org
> http://www.haskell.org/mailman/listinfo/libraries

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/ghc-devs/attachments/20140328/622fc57f/attachment-0001.html>

From johan.tibell at gmail.com  Sat Mar 29 09:53:49 2014
From: johan.tibell at gmail.com (Johan Tibell)
Date: Sat, 29 Mar 2014 10:53:49 +0100
Subject: Looks like I broke the build. Fixing <eom>
Message-ID: <CAK-tuPZFO19a+=or7CGViujbFvgMPGczqaK7Bsp_5y2U1nW55g@mail.gmail.com>


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/ghc-devs/attachments/20140329/97951b8a/attachment.html>

From johan.tibell at gmail.com  Sat Mar 29 10:36:45 2014
From: johan.tibell at gmail.com (Johan Tibell)
Date: Sat, 29 Mar 2014 11:36:45 +0100
Subject: Looks like I broke the build. Fixing <eom>
In-Reply-To: <CAK-tuPZFO19a+=or7CGViujbFvgMPGczqaK7Bsp_5y2U1nW55g@mail.gmail.com>
References: <CAK-tuPZFO19a+=or7CGViujbFvgMPGczqaK7Bsp_5y2U1nW55g@mail.gmail.com>
Message-ID: <CAK-tuPZZUyRUDvS7N93MotEgtuDcvpU1sy1=M_QcjMbPsJh7xQ@mail.gmail.com>

Should be fixed by 838bfb2. Sorry about the breakage.


On Sat, Mar 29, 2014 at 10:53 AM, Johan Tibell <johan.tibell at gmail.com>wrote:

>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/ghc-devs/attachments/20140329/dbea5261/attachment.html>

From mail at joachim-breitner.de  Sat Mar 29 16:11:46 2014
From: mail at joachim-breitner.de (Joachim Breitner)
Date: Sat, 29 Mar 2014 17:11:46 +0100
Subject: Looks like I broke the build. Fixing <eom>
In-Reply-To: <CAK-tuPZZUyRUDvS7N93MotEgtuDcvpU1sy1=M_QcjMbPsJh7xQ@mail.gmail.com>
References: <CAK-tuPZFO19a+=or7CGViujbFvgMPGczqaK7Bsp_5y2U1nW55g@mail.gmail.com>
 <CAK-tuPZZUyRUDvS7N93MotEgtuDcvpU1sy1=M_QcjMbPsJh7xQ@mail.gmail.com>
Message-ID: <1396109506.2549.10.camel@kirk>

Hi Johan,

back from a holiday, so time to report CI failures...

Am Samstag, den 29.03.2014, 11:36 +0100 schrieb Johan Tibell:
> Should be fixed by 838bfb2. Sorry about the breakage.

according to https://travis-ci.org/nomeata/ghc-complete/builds/21818785
there are still 
     416 unexpected failures
which were introduced, as it seems, by
 Make copy array ops out-of-line by default

Can you double-check that it is fixed?

Greetings,
Joachim


-- 
Joachim ?nomeata? Breitner
  mail at joachim-breitner.de ? http://www.joachim-breitner.de/
  Jabber: nomeata at joachim-breitner.de  ? GPG-Key: 0x4743206C
  Debian Developer: nomeata at debian.org
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 181 bytes
Desc: This is a digitally signed message part
URL: <http://www.haskell.org/pipermail/ghc-devs/attachments/20140329/881453a1/attachment.sig>

From johan.tibell at gmail.com  Sat Mar 29 16:15:40 2014
From: johan.tibell at gmail.com (Johan Tibell)
Date: Sat, 29 Mar 2014 17:15:40 +0100
Subject: Looks like I broke the build. Fixing <eom>
In-Reply-To: <1396109506.2549.10.camel@kirk>
References: <CAK-tuPZFO19a+=or7CGViujbFvgMPGczqaK7Bsp_5y2U1nW55g@mail.gmail.com>
 <CAK-tuPZZUyRUDvS7N93MotEgtuDcvpU1sy1=M_QcjMbPsJh7xQ@mail.gmail.com>
 <1396109506.2549.10.camel@kirk>
Message-ID: <CAK-tuPZTZF4b4JQJ2ww11UDTJM+gZwDMGtYiVtO_-+GaOuFcfA@mail.gmail.com>

Let me take a second look. The code validates on OS X so I'm fixing a bit
blind here.


On Sat, Mar 29, 2014 at 5:11 PM, Joachim Breitner
<mail at joachim-breitner.de>wrote:

> Hi Johan,
>
> back from a holiday, so time to report CI failures...
>
> Am Samstag, den 29.03.2014, 11:36 +0100 schrieb Johan Tibell:
> > Should be fixed by 838bfb2. Sorry about the breakage.
>
> according to https://travis-ci.org/nomeata/ghc-complete/builds/21818785
> there are still
>      416 unexpected failures
> which were introduced, as it seems, by
>  Make copy array ops out-of-line by default
>
> Can you double-check that it is fixed?
>
> Greetings,
> Joachim
>
>
> --
> Joachim "nomeata" Breitner
>   mail at joachim-breitner.de * http://www.joachim-breitner.de/
>   Jabber: nomeata at joachim-breitner.de  * GPG-Key: 0x4743206C
>   Debian Developer: nomeata at debian.org
>
> _______________________________________________
> ghc-devs mailing list
> ghc-devs at haskell.org
> http://www.haskell.org/mailman/listinfo/ghc-devs
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/ghc-devs/attachments/20140329/dd3379a9/attachment.html>

From johan.tibell at gmail.com  Sat Mar 29 16:23:09 2014
From: johan.tibell at gmail.com (Johan Tibell)
Date: Sat, 29 Mar 2014 17:23:09 +0100
Subject: Looks like I broke the build. Fixing <eom>
In-Reply-To: <CAK-tuPZTZF4b4JQJ2ww11UDTJM+gZwDMGtYiVtO_-+GaOuFcfA@mail.gmail.com>
References: <CAK-tuPZFO19a+=or7CGViujbFvgMPGczqaK7Bsp_5y2U1nW55g@mail.gmail.com>
 <CAK-tuPZZUyRUDvS7N93MotEgtuDcvpU1sy1=M_QcjMbPsJh7xQ@mail.gmail.com>
 <1396109506.2549.10.camel@kirk>
 <CAK-tuPZTZF4b4JQJ2ww11UDTJM+gZwDMGtYiVtO_-+GaOuFcfA@mail.gmail.com>
Message-ID: <CAK-tuPa4EvPkZwMBi=cU-KJNLocd6PNKGxqHHOcMeMeuJjyfCA@mail.gmail.com>

I'm validating a fix.


On Sat, Mar 29, 2014 at 5:15 PM, Johan Tibell <johan.tibell at gmail.com>wrote:

> Let me take a second look. The code validates on OS X so I'm fixing a bit
> blind here.
>
>
> On Sat, Mar 29, 2014 at 5:11 PM, Joachim Breitner <
> mail at joachim-breitner.de> wrote:
>
>> Hi Johan,
>>
>> back from a holiday, so time to report CI failures...
>>
>> Am Samstag, den 29.03.2014, 11:36 +0100 schrieb Johan Tibell:
>> > Should be fixed by 838bfb2. Sorry about the breakage.
>>
>> according to https://travis-ci.org/nomeata/ghc-complete/builds/21818785
>> there are still
>>      416 unexpected failures
>> which were introduced, as it seems, by
>>  Make copy array ops out-of-line by default
>>
>> Can you double-check that it is fixed?
>>
>> Greetings,
>> Joachim
>>
>>
>> --
>> Joachim "nomeata" Breitner
>>   mail at joachim-breitner.de * http://www.joachim-breitner.de/
>>   Jabber: nomeata at joachim-breitner.de  * GPG-Key: 0x4743206C
>>   Debian Developer: nomeata at debian.org
>>
>> _______________________________________________
>> ghc-devs mailing list
>> ghc-devs at haskell.org
>> http://www.haskell.org/mailman/listinfo/ghc-devs
>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/ghc-devs/attachments/20140329/6a0ae6c2/attachment.html>

From johan.tibell at gmail.com  Sat Mar 29 17:24:00 2014
From: johan.tibell at gmail.com (Johan Tibell)
Date: Sat, 29 Mar 2014 18:24:00 +0100
Subject: Looks like I broke the build. Fixing <eom>
In-Reply-To: <CAK-tuPa4EvPkZwMBi=cU-KJNLocd6PNKGxqHHOcMeMeuJjyfCA@mail.gmail.com>
References: <CAK-tuPZFO19a+=or7CGViujbFvgMPGczqaK7Bsp_5y2U1nW55g@mail.gmail.com>
 <CAK-tuPZZUyRUDvS7N93MotEgtuDcvpU1sy1=M_QcjMbPsJh7xQ@mail.gmail.com>
 <1396109506.2549.10.camel@kirk>
 <CAK-tuPZTZF4b4JQJ2ww11UDTJM+gZwDMGtYiVtO_-+GaOuFcfA@mail.gmail.com>
 <CAK-tuPa4EvPkZwMBi=cU-KJNLocd6PNKGxqHHOcMeMeuJjyfCA@mail.gmail.com>
Message-ID: <CAK-tuPbNJRoS0pvacHbfX=Yh-_K-uzXbx0EVSmgZ963r8iudzA@mail.gmail.com>

I fixed some more missing symbols. If this doesn't do it I'll have to
reproduce it on a Linux machine tomorrow and fix it there.


On Sat, Mar 29, 2014 at 5:23 PM, Johan Tibell <johan.tibell at gmail.com>wrote:

> I'm validating a fix.
>
>
> On Sat, Mar 29, 2014 at 5:15 PM, Johan Tibell <johan.tibell at gmail.com>wrote:
>
>> Let me take a second look. The code validates on OS X so I'm fixing a bit
>> blind here.
>>
>>
>> On Sat, Mar 29, 2014 at 5:11 PM, Joachim Breitner <
>> mail at joachim-breitner.de> wrote:
>>
>>> Hi Johan,
>>>
>>> back from a holiday, so time to report CI failures...
>>>
>>> Am Samstag, den 29.03.2014, 11:36 +0100 schrieb Johan Tibell:
>>> > Should be fixed by 838bfb2. Sorry about the breakage.
>>>
>>> according to https://travis-ci.org/nomeata/ghc-complete/builds/21818785
>>> there are still
>>>      416 unexpected failures
>>> which were introduced, as it seems, by
>>>  Make copy array ops out-of-line by default
>>>
>>> Can you double-check that it is fixed?
>>>
>>> Greetings,
>>> Joachim
>>>
>>>
>>> --
>>> Joachim "nomeata" Breitner
>>>   mail at joachim-breitner.de * http://www.joachim-breitner.de/
>>>   Jabber: nomeata at joachim-breitner.de  * GPG-Key: 0x4743206C
>>>   Debian Developer: nomeata at debian.org
>>>
>>> _______________________________________________
>>> ghc-devs mailing list
>>> ghc-devs at haskell.org
>>> http://www.haskell.org/mailman/listinfo/ghc-devs
>>>
>>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/ghc-devs/attachments/20140329/ee9e3e92/attachment.html>

From mail at joachim-breitner.de  Sat Mar 29 20:04:37 2014
From: mail at joachim-breitner.de (Joachim Breitner)
Date: Sat, 29 Mar 2014 21:04:37 +0100
Subject: Looks like I broke the build. Fixing <eom>
In-Reply-To: <CAK-tuPbNJRoS0pvacHbfX=Yh-_K-uzXbx0EVSmgZ963r8iudzA@mail.gmail.com>
References: <CAK-tuPZFO19a+=or7CGViujbFvgMPGczqaK7Bsp_5y2U1nW55g@mail.gmail.com>
 <CAK-tuPZZUyRUDvS7N93MotEgtuDcvpU1sy1=M_QcjMbPsJh7xQ@mail.gmail.com>
 <1396109506.2549.10.camel@kirk>
 <CAK-tuPZTZF4b4JQJ2ww11UDTJM+gZwDMGtYiVtO_-+GaOuFcfA@mail.gmail.com>
 <CAK-tuPa4EvPkZwMBi=cU-KJNLocd6PNKGxqHHOcMeMeuJjyfCA@mail.gmail.com>
 <CAK-tuPbNJRoS0pvacHbfX=Yh-_K-uzXbx0EVSmgZ963r8iudzA@mail.gmail.com>
Message-ID: <1396123477.2549.34.camel@kirk>

Hi,

Am Samstag, den 29.03.2014, 18:24 +0100 schrieb Johan Tibell:
> I fixed some more missing symbols. If this doesn't do it I'll have to
> reproduce it on a Linux machine tomorrow and fix it there.

thanks; now there is only one error left, not sure if it is related to
your changes:



-- 
Joachim Breitner
  e-Mail: mail at joachim-breitner.de
  Homepage: http://www.joachim-breitner.de
  Jabber-ID: nomeata at joachim-breitner.de

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 181 bytes
Desc: This is a digitally signed message part
URL: <http://www.haskell.org/pipermail/ghc-devs/attachments/20140329/01f5c5b5/attachment.sig>

From mail at joachim-breitner.de  Sat Mar 29 20:09:36 2014
From: mail at joachim-breitner.de (Joachim Breitner)
Date: Sat, 29 Mar 2014 21:09:36 +0100
Subject: Looks like I broke the build. Fixing <eom>
In-Reply-To: <CAK-tuPbNJRoS0pvacHbfX=Yh-_K-uzXbx0EVSmgZ963r8iudzA@mail.gmail.com>
References: <CAK-tuPZFO19a+=or7CGViujbFvgMPGczqaK7Bsp_5y2U1nW55g@mail.gmail.com>
 <CAK-tuPZZUyRUDvS7N93MotEgtuDcvpU1sy1=M_QcjMbPsJh7xQ@mail.gmail.com>
 <1396109506.2549.10.camel@kirk>
 <CAK-tuPZTZF4b4JQJ2ww11UDTJM+gZwDMGtYiVtO_-+GaOuFcfA@mail.gmail.com>
 <CAK-tuPa4EvPkZwMBi=cU-KJNLocd6PNKGxqHHOcMeMeuJjyfCA@mail.gmail.com>
 <CAK-tuPbNJRoS0pvacHbfX=Yh-_K-uzXbx0EVSmgZ963r8iudzA@mail.gmail.com>
Message-ID: <1396123776.2549.36.camel@kirk>

Hi,

Am Samstag, den 29.03.2014, 18:24 +0100 schrieb Johan Tibell:
> I fixed some more missing symbols. If this doesn't do it I'll have to
> reproduce it on a Linux machine tomorrow and fix it there.

thanks; now there is only one error left, and that is due to a missing
"reqlib" annotation; fixed.


(And sorry for Ctrl-Enter before the end of the message.)

Greetings,
Joachim

-- 
Joachim ?nomeata? Breitner
  mail at joachim-breitner.de ? http://www.joachim-breitner.de/
  Jabber: nomeata at joachim-breitner.de  ? GPG-Key: 0x4743206C
  Debian Developer: nomeata at debian.org
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 181 bytes
Desc: This is a digitally signed message part
URL: <http://www.haskell.org/pipermail/ghc-devs/attachments/20140329/448c3de4/attachment.sig>

From eir at cis.upenn.edu  Mon Mar 31 00:14:55 2014
From: eir at cis.upenn.edu (Richard Eisenberg)
Date: Sun, 30 Mar 2014 20:14:55 -0400
Subject: Backward-compatible role annotations
In-Reply-To: <CAHEA9tPeDLE5O80wgTth87F941=RiONnYsYaaqAA3dg6UfcN+Q@mail.gmail.com>
References: <78518EC7-BC18-4732-90B6-1AB37048D2A3@cis.upenn.edu>
 <CAEs96n1Xxp9qmXLBf6XqKbLH3kEE3bVLcpLAuFHoVip0N+1D=w@mail.gmail.com>
 <CAEs96n1dVs8SC6an_5eCsx1aCPwbNjbahhNrKAeaSCv1=Qe3gw@mail.gmail.com>
 <CAEs96n0SCjD6_C7VkeL0NUCY+v-fZseeL=iRFZG9fL9b74AjwQ@mail.gmail.com>
 <CAEs96n1WnrVtyjk2f3jOgUZg2M4EwPSA-9bnN6+9dL1p+=Ea0w@mail.gmail.com>
 <CAK-tuPahbPSd4fxjRCMKHYPcsPuzsM3CnBFMBvkoYbAZkVmmjw@mail.gmail.com>
 <CAAOoiFZKYXzqdfS1PVfG4W_H9ig8iw3MrcTFWu5GrP4C6sgEoA@mail.gmail.com>
 <CAKFCL4Xz_W9of6SyXBsFfk+6Kp4E=T7pjPt4ZhqjqqY9wsixkw@mail.gmail.com>
 <59543203684B2244980D7E4057D5FBC1488BA55B@DB3EX14MBXC308.europe.corp.microsoft.com>
 <CAAOoiFaof89nQBRStVD38hmHQbBeNNQOU1+YEdaq_iwieKgGJA@mail.gmail.com>
 <CAJumaK_-dxYW=raqvCyfp1h-9XFwj2eKq_smWHng=DuUChfZ4w@mail.gmail.com>
 <2F1D91F2-0AD6-4E98-81E3-9A95E6024BA3@gmail.com>
 <8FD54493-CC52-4B90-9DD2-E7C91024FC30@cis.upenn.edu>
 <53313E49.1040405@ifi.lmu.de> <8761n2ob4f.fsf@gnu.org>
 <533165DF.5030206@ifi.lmu.de> <59543203684B2244980D7E4057D5FBC!
 1488BD709@DB3EX14MBXC308.europe.corp.microsoft.com>
 <CAAOoiFYy31jtcoRxf6vKKGC9J9MENOk=aLYG=g4Xe9kkQcR1eA@mail.gmail.com>
 <7B4344AC-7EB2-4892-8C07-969456EC6602@cis.upenn.edu>
 <CAOv7PypbE3B9iS4MceYqqSsAqPWZNHD1FP6vJZQemD66USNcOA@mail.gmail.com>
 <CAHEA9tPeDLE5O80wgTth87F941=RiONnYsYaaqAA3dg6UfcN+Q@mail.gmail.com>
Message-ID: <1916CF2B-9B03-4CBD-8559-0AD4C4834E85@cis.upenn.edu>

I spent some time thinking about what, precisely, can be done here to make folks happier. (See the thread beginning here: http://www.haskell.org/pipermail/libraries/2014-March/022321.html) And, the answer seemed to all be in the concrete syntax. The only logical alternative (that I could think of) to having roles is to disallow GND, and I don't think anyone is proposing that. And, it is impossible to infer an author's desired roles for a datatype. The heuristics mentioned here all seem far too fragile and hard to predict to become a lasting feature of GHC (in my opinion). What's left? Concrete syntax.

So, I have written and uploaded no-role-annots-1.0, a backward-compatible alternative to role annotations -- no CPP required. It's not as principled as proper role annotations, but it should do the job for most users.

Here are two examples:

1. Datatypes:

> import Language.Haskell.RoleAnnots
>
> data Map k v =
>   (Nominal k, Representational v) => MkMap [(k,v)]

The constraints (which need be put on only one data constructor, if there are many) will get the built-in role inference mechanism to do what the user requests. In this example, the `Representational v` is actually redundant, but causes no harm. Because these classes have universal instances ("instance Nominal a") and have no methods, they should have no run-time significance. The only downside I can see is that the code above needs -XGADTs or -XExistentialQuantification to work, though it is neither a GADT nor has existentials. (Pattern-matching on such a definition needs no extensions.)

2. Newtypes:

Newtype constructors cannot be constrained, unfortunately. So, we have to resort to Template Haskell:

> import Language.Haskell.RoleAnnots
>
> roleAnnot [NominalR, RepresentationalR]
>   [d| newtype Map k v = MkMap [(k, v)] |]

This is clearly worse, but I was able to come up with no other solution that worked for newtypes. Note that, in the example, I used the fact that Template Haskell interprets a bare top-level expression as a Template Haskell splice. We could also wrap that line in $( ... ) to be more explicit about the use of TH. Also problematic here is that the code above requires -XRoleAnnotations in GHC 7.8. To get this extension enabled without using CPP, put it in a condition chunk in your .cabal file, like this:

> if impl(ghc >= 7.8)
>   default-extensions: RoleAnnotations

I hope this is helpful to everyone. Please feel free to post issues/pull requests to my github repo at github.com/goldfirere/no-role-annots.

Thanks,
Richard
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/ghc-devs/attachments/20140330/a88a79b8/attachment.html>

From dominique.devriese at cs.kuleuven.be  Mon Mar 31 06:51:18 2014
From: dominique.devriese at cs.kuleuven.be (Dominique Devriese)
Date: Mon, 31 Mar 2014 08:51:18 +0200
Subject: Backward-compatible role annotations
In-Reply-To: <1916CF2B-9B03-4CBD-8559-0AD4C4834E85@cis.upenn.edu>
References: <78518EC7-BC18-4732-90B6-1AB37048D2A3@cis.upenn.edu>
 <CAEs96n1Xxp9qmXLBf6XqKbLH3kEE3bVLcpLAuFHoVip0N+1D=w@mail.gmail.com>
 <CAEs96n1dVs8SC6an_5eCsx1aCPwbNjbahhNrKAeaSCv1=Qe3gw@mail.gmail.com>
 <CAEs96n0SCjD6_C7VkeL0NUCY+v-fZseeL=iRFZG9fL9b74AjwQ@mail.gmail.com>
 <CAEs96n1WnrVtyjk2f3jOgUZg2M4EwPSA-9bnN6+9dL1p+=Ea0w@mail.gmail.com>
 <CAK-tuPahbPSd4fxjRCMKHYPcsPuzsM3CnBFMBvkoYbAZkVmmjw@mail.gmail.com>
 <CAAOoiFZKYXzqdfS1PVfG4W_H9ig8iw3MrcTFWu5GrP4C6sgEoA@mail.gmail.com>
 <CAKFCL4Xz_W9of6SyXBsFfk+6Kp4E=T7pjPt4ZhqjqqY9wsixkw@mail.gmail.com>
 <59543203684B2244980D7E4057D5FBC1488BA55B@DB3EX14MBXC308.europe.corp.microsoft.com>
 <CAAOoiFaof89nQBRStVD38hmHQbBeNNQOU1+YEdaq_iwieKgGJA@mail.gmail.com>
 <CAJumaK_-dxYW=raqvCyfp1h-9XFwj2eKq_smWHng=DuUChfZ4w@mail.gmail.com>
 <2F1D91F2-0AD6-4E98-81E3-9A95E6024BA3@gmail.com>
 <8FD54493-CC52-4B90-9DD2-E7C91024FC30@cis.upenn.edu>
 <53313E49.1040405@ifi.lmu.de> <8761n2ob4f.fsf@gnu.org>
 <533165DF.5030206@ifi.lmu.de>
 <CAAOoiFYy31jtcoRxf6vKKGC9J9MENOk=aLYG=g4Xe9kkQcR1eA@mail.gmail.com>
 <7B4344AC-7EB2-4892-8C07-969456EC6602@cis.upenn.edu>
 <CAOv7PypbE3B9iS4MceYqqSsAqPWZNHD1FP6vJZQemD66USNcOA@mail.gmail.com>
 <CAHEA9tPeDLE5O80wgTth87F941=RiONnYsYaaqAA3dg6UfcN+Q@mail.gmail.com>
 <1916CF2B-9B03-4CBD-8559-0AD4C4834E85@cis.upenn.edu>
Message-ID: <CAML5wvv9Jgb61uMOfHHJDDgVLW8cvNad8msioUBttzW1z8vzKA@mail.gmail.com>

Richard,

(re-posting because I first used an address that is not subscribed to the lists)

I've been wondering about the following: it seems like the main
problem in this situation is that the GeneralizedNewtypeDeriving
extension changed meaning from "just coerce everything while deriving"
to "only coerce stuff if it's allowed by the relevant role
annotations".  Would it not be an alternative solution to split up the
GND extension into

* a backwards-compatible one (called GeneralizedNewtypeDeriving for
backwards compatibility ;)) that ignores role annotations (as before)
and uses unsafeCoerce whereever necessary
* a safe one (called e.g. SafeNewtypeDeriving) that respects role annotations

The first one could then be deprecated and removed in a release or
two. That might give library maintainers time to move their packages
to SafeNewtypeDeriving when they have tested that everything works...

Regards,
Dominique

P.S.: The above is based on a limited understanding of the problem, so
I'm sorry if it misses some aspect of the problem...

2014-03-31 2:14 GMT+02:00 Richard Eisenberg <eir at cis.upenn.edu>:
> I spent some time thinking about what, precisely, can be done here to make
> folks happier. (See the thread beginning here:
> http://www.haskell.org/pipermail/libraries/2014-March/022321.html) And, the
> answer seemed to all be in the concrete syntax. The only logical alternative
> (that I could think of) to having roles is to disallow GND, and I don't
> think anyone is proposing that. And, it is impossible to infer an author's
> desired roles for a datatype. The heuristics mentioned here all seem far too
> fragile and hard to predict to become a lasting feature of GHC (in my
> opinion). What's left? Concrete syntax.
>
> So, I have written and uploaded no-role-annots-1.0, a backward-compatible
> alternative to role annotations -- no CPP required. It's not as principled
> as proper role annotations, but it should do the job for most users.
>
> Here are two examples:
>
> 1. Datatypes:
>
>> import Language.Haskell.RoleAnnots
>>
>> data Map k v =
>>   (Nominal k, Representational v) => MkMap [(k,v)]
>
> The constraints (which need be put on only one data constructor, if there
> are many) will get the built-in role inference mechanism to do what the user
> requests. In this example, the `Representational v` is actually redundant,
> but causes no harm. Because these classes have universal instances
> ("instance Nominal a") and have no methods, they should have no run-time
> significance. The only downside I can see is that the code above needs
> -XGADTs or -XExistentialQuantification to work, though it is neither a GADT
> nor has existentials. (Pattern-matching on such a definition needs no
> extensions.)
>
> 2. Newtypes:
>
> Newtype constructors cannot be constrained, unfortunately. So, we have to
> resort to Template Haskell:
>
>> import Language.Haskell.RoleAnnots
>>
>> roleAnnot [NominalR, RepresentationalR]
>>   [d| newtype Map k v = MkMap [(k, v)] |]
>
> This is clearly worse, but I was able to come up with no other solution that
> worked for newtypes. Note that, in the example, I used the fact that
> Template Haskell interprets a bare top-level expression as a Template
> Haskell splice. We could also wrap that line in $( ... ) to be more explicit
> about the use of TH. Also problematic here is that the code above requires
> -XRoleAnnotations in GHC 7.8. To get this extension enabled without using
> CPP, put it in a condition chunk in your .cabal file, like this:
>
>> if impl(ghc >= 7.8)
>>   default-extensions: RoleAnnotations
>
> I hope this is helpful to everyone. Please feel free to post issues/pull
> requests to my github repo at github.com/goldfirere/no-role-annots.
>
> Thanks,
> Richard
>
> _______________________________________________
> ghc-devs mailing list
> ghc-devs at haskell.org
> http://www.haskell.org/mailman/listinfo/ghc-devs
>

From simonpj at microsoft.com  Mon Mar 31 08:44:03 2014
From: simonpj at microsoft.com (Simon Peyton Jones)
Date: Mon, 31 Mar 2014 08:44:03 +0000
Subject: Gearing up (again) for the next release: 2014.2.0.0
In-Reply-To: <1396254030124-5746686.post@n5.nabble.com>
References: <CAAOoiFYq=rZtPKPKpur_cSB+brewg54qwoUdmc4nOB555d+Z_w@mail.gmail.com>
 <CAAOoiFYC5zVsyP7=xYvKnYnGUTMK8xyRd9EqFzfrP2Xuk=GoWQ@mail.gmail.com>
 <618BE556AADD624C9C918AA5D5911BEF0C9F08@DB3PRD3001MB020.064d.mgd.msft.net>
 <1396254030124-5746686.post@n5.nabble.com>
Message-ID: <618BE556AADD624C9C918AA5D5911BEF0CA5CF@DB3PRD3001MB020.064d.mgd.msft.net>

| If I've understood #8736 correctly, GHCi on Windows can't load modules
| that
| were compiled with --dynamic-too. That's a pretty nasty regression, as
| --dynamic-too will now be the default for anything used by TH.

Well, five weeks ago we marked the ticket as "not a release blocker".  No one commented.   

And it's not a regression, is it?  I don't think -dynamic-too existed in 7.6.

We'd welcome help with this.  There is some reason it's not straightforward to fix, but I've forgotten what it is.

Simon

| -----Original Message-----
| From: Libraries [mailto:libraries-bounces at haskell.org] On Behalf Of harry
| Sent: 31 March 2014 09:21
| To: libraries at haskell.org
| Subject: RE: Gearing up (again) for the next release: 2014.2.0.0
| 
| Simon Peyton Jones wrote
| > We have not begun to think about when to release 7.8.2.  It?ll depend
| on
| > what issues show up in 7.8.1 and how urgent they seem to be.  We have
| > delayed 7.8.1 for ages, and given masses of warning about the release,
| so
| > I?d be sad if there are known, show-stopping bugs in it that we already
| > know about.  If there really really really are, maybe we should delay
| > 7.8.1 further.  But that process can go on indefinitely (as we have
| > already seen), so I?m pretty reluctant.
| >
| > But I?d certainly listen to a consensus view from the HP team. You
| > represent our customers.
| 
| If I've understood #8736 correctly, GHCi on Windows can't load modules
| that
| were compiled with --dynamic-too. That's a pretty nasty regression, as
| --dynamic-too will now be the default for anything used by TH.
| 
| 
| 
| --
| View this message in context:
| http://haskell.1045720.n5.nabble.com/Gearing-up-again-for-the-next-
| release-2014-2-0-0-tp5746660p5746686.html
| Sent from the Haskell - Libraries mailing list archive at Nabble.com.
| _______________________________________________
| Libraries mailing list
| Libraries at haskell.org
| http://www.haskell.org/mailman/listinfo/libraries

From eir at cis.upenn.edu  Mon Mar 31 15:05:23 2014
From: eir at cis.upenn.edu (Richard Eisenberg)
Date: Mon, 31 Mar 2014 11:05:23 -0400
Subject: Backward-compatible role annotations
In-Reply-To: <CAML5wvv9Jgb61uMOfHHJDDgVLW8cvNad8msioUBttzW1z8vzKA@mail.gmail.com>
References: <78518EC7-BC18-4732-90B6-1AB37048D2A3@cis.upenn.edu>
 <CAEs96n1Xxp9qmXLBf6XqKbLH3kEE3bVLcpLAuFHoVip0N+1D=w@mail.gmail.com>
 <CAEs96n1dVs8SC6an_5eCsx1aCPwbNjbahhNrKAeaSCv1=Qe3gw@mail.gmail.com>
 <CAEs96n0SCjD6_C7VkeL0NUCY+v-fZseeL=iRFZG9fL9b74AjwQ@mail.gmail.com>
 <CAEs96n1WnrVtyjk2f3jOgUZg2M4EwPSA-9bnN6+9dL1p+=Ea0w@mail.gmail.com>
 <CAK-tuPahbPSd4fxjRCMKHYPcsPuzsM3CnBFMBvkoYbAZkVmmjw@mail.gmail.com>
 <CAAOoiFZKYXzqdfS1PVfG4W_H9ig8iw3MrcTFWu5GrP4C6sgEoA@mail.gmail.com>
 <CAKFCL4Xz_W9of6SyXBsFfk+6Kp4E=T7pjPt4ZhqjqqY9wsixkw@mail.gmail.com>
 <59543203684B2244980D7E4057D5FBC1488BA55B@DB3EX14MBXC308.europe.corp.microsoft.com>
 <CAAOoiFaof89nQBRStVD38hmHQbBeNNQOU1+YEdaq_iwieKgGJA@mail.gmail.com>
 <CAJumaK_-dxYW=raqvCyfp1h-9XFwj2eKq_smWHng=DuUChfZ4w@mail.gmail.com>
 <2F1D91F2-0AD6-4E98-81E3-9A95E6024BA3@gmail.com>
 <8FD54493-CC52-4B90-9DD2-E7C91024FC30@cis.upenn.edu>
 <53313E49.1040405@ifi.lmu.de> <8761n2ob4f.fsf@gnu.org>
 <533165DF.5030206@ifi.lmu.de> <CAAOoiFYy31jtcoRxf6vKKGC9J9MENO!
 k=aLYG=g4Xe9kkQcR1eA@mail.gmail.com>
 <7B4344AC-7EB2-4892-8C07-969456EC6602@cis.upenn.edu>
 <CAOv7PypbE3B9iS4MceYqqSsAqPWZNHD1FP6vJZQemD66USNcOA@mail.gmail.com>
 <CAHEA9tPeDLE5O80wgTth87F941=RiONnYsYaaqAA3dg6UfcN+Q@mail.gmail.com>
 <1916CF2B-9B03-4CBD-8559-0AD4C4834E85@cis.upenn.edu>
 <CAML5wvv9Jgb61uMOfHHJDDgVLW8cvNad8msioUBttzW1z8vzKA@mail.gmail.com>
Message-ID: <1C0E9E4D-CEF0-4832-888F-7284A1597294@cis.upenn.edu>

Hi Dominique,

When implementing roles, I was indeed worried about the problem you're addressing: that code that previously worked with GND now won't. However, it turns out that few people have really complained about this. IIRC, in all of Hackage, only 3 packages needed to be changed because of this. If there were a larger impact to the GND breakage, I think your suggestion would be a good one.

The problem I'm adressing in this thread is different: that library authors have been given a new, not-backward-compatible way of preventing abuses of their datatypes, and no proposal I have seen really addresses all of the problems here. I'm hoping my no-role-annots package might be helpful, but it doesn't fully resolve the issues.

Richard

On Mar 31, 2014, at 2:51 AM, Dominique Devriese <dominique.devriese at cs.kuleuven.be> wrote:

> Richard,
> 
> (re-posting because I first used an address that is not subscribed to the lists)
> 
> I've been wondering about the following: it seems like the main
> problem in this situation is that the GeneralizedNewtypeDeriving
> extension changed meaning from "just coerce everything while deriving"
> to "only coerce stuff if it's allowed by the relevant role
> annotations".  Would it not be an alternative solution to split up the
> GND extension into
> 
> * a backwards-compatible one (called GeneralizedNewtypeDeriving for
> backwards compatibility ;)) that ignores role annotations (as before)
> and uses unsafeCoerce whereever necessary
> * a safe one (called e.g. SafeNewtypeDeriving) that respects role annotations
> 
> The first one could then be deprecated and removed in a release or
> two. That might give library maintainers time to move their packages
> to SafeNewtypeDeriving when they have tested that everything works...
> 
> Regards,
> Dominique
> 
> P.S.: The above is based on a limited understanding of the problem, so
> I'm sorry if it misses some aspect of the problem...
> 
> 2014-03-31 2:14 GMT+02:00 Richard Eisenberg <eir at cis.upenn.edu>:
>> I spent some time thinking about what, precisely, can be done here to make
>> folks happier. (See the thread beginning here:
>> http://www.haskell.org/pipermail/libraries/2014-March/022321.html) And, the
>> answer seemed to all be in the concrete syntax. The only logical alternative
>> (that I could think of) to having roles is to disallow GND, and I don't
>> think anyone is proposing that. And, it is impossible to infer an author's
>> desired roles for a datatype. The heuristics mentioned here all seem far too
>> fragile and hard to predict to become a lasting feature of GHC (in my
>> opinion). What's left? Concrete syntax.
>> 
>> So, I have written and uploaded no-role-annots-1.0, a backward-compatible
>> alternative to role annotations -- no CPP required. It's not as principled
>> as proper role annotations, but it should do the job for most users.
>> 
>> Here are two examples:
>> 
>> 1. Datatypes:
>> 
>>> import Language.Haskell.RoleAnnots
>>> 
>>> data Map k v =
>>>  (Nominal k, Representational v) => MkMap [(k,v)]
>> 
>> The constraints (which need be put on only one data constructor, if there
>> are many) will get the built-in role inference mechanism to do what the user
>> requests. In this example, the `Representational v` is actually redundant,
>> but causes no harm. Because these classes have universal instances
>> ("instance Nominal a") and have no methods, they should have no run-time
>> significance. The only downside I can see is that the code above needs
>> -XGADTs or -XExistentialQuantification to work, though it is neither a GADT
>> nor has existentials. (Pattern-matching on such a definition needs no
>> extensions.)
>> 
>> 2. Newtypes:
>> 
>> Newtype constructors cannot be constrained, unfortunately. So, we have to
>> resort to Template Haskell:
>> 
>>> import Language.Haskell.RoleAnnots
>>> 
>>> roleAnnot [NominalR, RepresentationalR]
>>>  [d| newtype Map k v = MkMap [(k, v)] |]
>> 
>> This is clearly worse, but I was able to come up with no other solution that
>> worked for newtypes. Note that, in the example, I used the fact that
>> Template Haskell interprets a bare top-level expression as a Template
>> Haskell splice. We could also wrap that line in $( ... ) to be more explicit
>> about the use of TH. Also problematic here is that the code above requires
>> -XRoleAnnotations in GHC 7.8. To get this extension enabled without using
>> CPP, put it in a condition chunk in your .cabal file, like this:
>> 
>>> if impl(ghc >= 7.8)
>>>  default-extensions: RoleAnnotations
>> 
>> I hope this is helpful to everyone. Please feel free to post issues/pull
>> requests to my github repo at github.com/goldfirere/no-role-annots.
>> 
>> Thanks,
>> Richard
>> 
>> _______________________________________________
>> ghc-devs mailing list
>> ghc-devs at haskell.org
>> http://www.haskell.org/mailman/listinfo/ghc-devs
>> 
> _______________________________________________
> Libraries mailing list
> Libraries at haskell.org
> http://www.haskell.org/mailman/listinfo/libraries


From dominique.devriese at cs.kuleuven.be  Mon Mar 31 18:12:59 2014
From: dominique.devriese at cs.kuleuven.be (Dominique Devriese)
Date: Mon, 31 Mar 2014 20:12:59 +0200
Subject: Backward-compatible role annotations
In-Reply-To: <1C0E9E4D-CEF0-4832-888F-7284A1597294@cis.upenn.edu>
References: <78518EC7-BC18-4732-90B6-1AB37048D2A3@cis.upenn.edu>
 <CAEs96n1Xxp9qmXLBf6XqKbLH3kEE3bVLcpLAuFHoVip0N+1D=w@mail.gmail.com>
 <CAEs96n1dVs8SC6an_5eCsx1aCPwbNjbahhNrKAeaSCv1=Qe3gw@mail.gmail.com>
 <CAEs96n0SCjD6_C7VkeL0NUCY+v-fZseeL=iRFZG9fL9b74AjwQ@mail.gmail.com>
 <CAEs96n1WnrVtyjk2f3jOgUZg2M4EwPSA-9bnN6+9dL1p+=Ea0w@mail.gmail.com>
 <CAK-tuPahbPSd4fxjRCMKHYPcsPuzsM3CnBFMBvkoYbAZkVmmjw@mail.gmail.com>
 <CAAOoiFZKYXzqdfS1PVfG4W_H9ig8iw3MrcTFWu5GrP4C6sgEoA@mail.gmail.com>
 <CAKFCL4Xz_W9of6SyXBsFfk+6Kp4E=T7pjPt4ZhqjqqY9wsixkw@mail.gmail.com>
 <59543203684B2244980D7E4057D5FBC1488BA55B@DB3EX14MBXC308.europe.corp.microsoft.com>
 <CAAOoiFaof89nQBRStVD38hmHQbBeNNQOU1+YEdaq_iwieKgGJA@mail.gmail.com>
 <CAJumaK_-dxYW=raqvCyfp1h-9XFwj2eKq_smWHng=DuUChfZ4w@mail.gmail.com>
 <2F1D91F2-0AD6-4E98-81E3-9A95E6024BA3@gmail.com>
 <8FD54493-CC52-4B90-9DD2-E7C91024FC30@cis.upenn.edu>
 <53313E49.1040405@ifi.lmu.de> <8761n2ob4f.fsf@gnu.org>
 <533165DF.5030206@ifi.lmu.de>
 <7B4344AC-7EB2-4892-8C07-969456EC6602@cis.upenn.edu>
 <CAOv7PypbE3B9iS4MceYqqSsAqPWZNHD1FP6vJZQemD66USNcOA@mail.gmail.com>
 <CAHEA9tPeDLE5O80wgTth87F941=RiONnYsYaaqAA3dg6UfcN+Q@mail.gmail.com>
 <1916CF2B-9B03-4CBD-8559-0AD4C4834E85@cis.upenn.edu>
 <CAML5wvv9Jgb61uMOfHHJDDgVLW8cvNad8msioUBttzW1z8vzKA@mail.gmail.com>
 <1C0E9E4D-CEF0-4832-888F-7284A1597294@cis.upenn.edu>
Message-ID: <CAML5wvutWoGm_xOySA72tvm7Aacf=hiUUdogEa-09FLGZ2saeA@mail.gmail.com>

Richard,

Right, but I was thinking about the debate between
"nominal/non-parametric-by-default" or
"representational/parametric-by-default" for parameters of data types
that aren't forced to nominal from inspecting the datatype
implementation.  As I understand it, representational-by-default
(currently used) may leave libraries that don't add role annotations
open for abuse, but won't unnecessarily break library users' code and
nominal-by-default prevents all abuse but may unnecessarily break code
that uses libraries that have not added proper role annotations.

What I was wondering about is if the dilemma could be solved by
choosing nominal-by-default in the long term for the role inference
(so that library writers cannot accidentally leave abstraction holes
open by forgetting to add role annotations) and use them in the
long-term-supported SafeNewtypeDeriving extension, but provide a
deprecated not-quite-as-safe GND extension for helping out users of
libraries that have not yet added role annotations. I would fancy that
this not-quite-as-safe GND could use unsafeCoerce wherever the safe
one would give an error about annotated roles.

Regards,
Dominique

2014-03-31 17:05 GMT+02:00 Richard Eisenberg <eir at cis.upenn.edu>:
> Hi Dominique,
>
> When implementing roles, I was indeed worried about the problem you're addressing: that code that previously worked with GND now won't. However, it turns out that few people have really complained about this. IIRC, in all of Hackage, only 3 packages needed to be changed because of this. If there were a larger impact to the GND breakage, I think your suggestion would be a good one.
>
> The problem I'm adressing in this thread is different: that library authors have been given a new, not-backward-compatible way of preventing abuses of their datatypes, and no proposal I have seen really addresses all of the problems here. I'm hoping my no-role-annots package might be helpful, but it doesn't fully resolve the issues.
>
> Richard
>
> On Mar 31, 2014, at 2:51 AM, Dominique Devriese <dominique.devriese at cs.kuleuven.be> wrote:
>
>> Richard,
>>
>> (re-posting because I first used an address that is not subscribed to the lists)
>>
>> I've been wondering about the following: it seems like the main
>> problem in this situation is that the GeneralizedNewtypeDeriving
>> extension changed meaning from "just coerce everything while deriving"
>> to "only coerce stuff if it's allowed by the relevant role
>> annotations".  Would it not be an alternative solution to split up the
>> GND extension into
>>
>> * a backwards-compatible one (called GeneralizedNewtypeDeriving for
>> backwards compatibility ;)) that ignores role annotations (as before)
>> and uses unsafeCoerce whereever necessary
>> * a safe one (called e.g. SafeNewtypeDeriving) that respects role annotations
>>
>> The first one could then be deprecated and removed in a release or
>> two. That might give library maintainers time to move their packages
>> to SafeNewtypeDeriving when they have tested that everything works...
>>
>> Regards,
>> Dominique
>>
>> P.S.: The above is based on a limited understanding of the problem, so
>> I'm sorry if it misses some aspect of the problem...
>>
>> 2014-03-31 2:14 GMT+02:00 Richard Eisenberg <eir at cis.upenn.edu>:
>>> I spent some time thinking about what, precisely, can be done here to make
>>> folks happier. (See the thread beginning here:
>>> http://www.haskell.org/pipermail/libraries/2014-March/022321.html) And, the
>>> answer seemed to all be in the concrete syntax. The only logical alternative
>>> (that I could think of) to having roles is to disallow GND, and I don't
>>> think anyone is proposing that. And, it is impossible to infer an author's
>>> desired roles for a datatype. The heuristics mentioned here all seem far too
>>> fragile and hard to predict to become a lasting feature of GHC (in my
>>> opinion). What's left? Concrete syntax.
>>>
>>> So, I have written and uploaded no-role-annots-1.0, a backward-compatible
>>> alternative to role annotations -- no CPP required. It's not as principled
>>> as proper role annotations, but it should do the job for most users.
>>>
>>> Here are two examples:
>>>
>>> 1. Datatypes:
>>>
>>>> import Language.Haskell.RoleAnnots
>>>>
>>>> data Map k v =
>>>>  (Nominal k, Representational v) => MkMap [(k,v)]
>>>
>>> The constraints (which need be put on only one data constructor, if there
>>> are many) will get the built-in role inference mechanism to do what the user
>>> requests. In this example, the `Representational v` is actually redundant,
>>> but causes no harm. Because these classes have universal instances
>>> ("instance Nominal a") and have no methods, they should have no run-time
>>> significance. The only downside I can see is that the code above needs
>>> -XGADTs or -XExistentialQuantification to work, though it is neither a GADT
>>> nor has existentials. (Pattern-matching on such a definition needs no
>>> extensions.)
>>>
>>> 2. Newtypes:
>>>
>>> Newtype constructors cannot be constrained, unfortunately. So, we have to
>>> resort to Template Haskell:
>>>
>>>> import Language.Haskell.RoleAnnots
>>>>
>>>> roleAnnot [NominalR, RepresentationalR]
>>>>  [d| newtype Map k v = MkMap [(k, v)] |]
>>>
>>> This is clearly worse, but I was able to come up with no other solution that
>>> worked for newtypes. Note that, in the example, I used the fact that
>>> Template Haskell interprets a bare top-level expression as a Template
>>> Haskell splice. We could also wrap that line in $( ... ) to be more explicit
>>> about the use of TH. Also problematic here is that the code above requires
>>> -XRoleAnnotations in GHC 7.8. To get this extension enabled without using
>>> CPP, put it in a condition chunk in your .cabal file, like this:
>>>
>>>> if impl(ghc >= 7.8)
>>>>  default-extensions: RoleAnnotations
>>>
>>> I hope this is helpful to everyone. Please feel free to post issues/pull
>>> requests to my github repo at github.com/goldfirere/no-role-annots.
>>>
>>> Thanks,
>>> Richard
>>>
>>> _______________________________________________
>>> ghc-devs mailing list
>>> ghc-devs at haskell.org
>>> http://www.haskell.org/mailman/listinfo/ghc-devs
>>>
>> _______________________________________________
>> Libraries mailing list
>> Libraries at haskell.org
>> http://www.haskell.org/mailman/listinfo/libraries
>

From mark.lentczner at gmail.com  Mon Mar 24 14:14:44 2014
From: mark.lentczner at gmail.com (Mark Lentczner)
Date: Mon, 24 Mar 2014 14:14:44 -0000
Subject: We need to add role annotations for 7.8
In-Reply-To: <CAK-tuPahbPSd4fxjRCMKHYPcsPuzsM3CnBFMBvkoYbAZkVmmjw@mail.gmail.com>
References: <78518EC7-BC18-4732-90B6-1AB37048D2A3@cis.upenn.edu>
 <CAK-tuPY0G0ceKK=mNp1N2H-h8S1sN47rahd2OmAXU3RrP-zukQ@mail.gmail.com>
 <CALjd_v5pCBQv4qXAm3E4_qSp8NRLjq1BKV1dJejymsUhruDReQ@mail.gmail.com>
 <CALjd_v6Ar4BVyWyYjpYDy-2UO78tVC3uOcdVyVSSpvi8M-oE9Q@mail.gmail.com>
 <CAEs96n1Xxp9qmXLBf6XqKbLH3kEE3bVLcpLAuFHoVip0N+1D=w@mail.gmail.com>
 <CAEs96n1dVs8SC6an_5eCsx1aCPwbNjbahhNrKAeaSCv1=Qe3gw@mail.gmail.com>
 <CAEs96n0SCjD6_C7VkeL0NUCY+v-fZseeL=iRFZG9fL9b74AjwQ@mail.gmail.com>
 <CAEs96n1WnrVtyjk2f3jOgUZg2M4EwPSA-9bnN6+9dL1p+=Ea0w@mail.gmail.com>
 <CAK-tuPahbPSd4fxjRCMKHYPcsPuzsM3CnBFMBvkoYbAZkVmmjw@mail.gmail.com>
Message-ID: <CAAOoiFZKYXzqdfS1PVfG4W_H9ig8iw3MrcTFWu5GrP4C6sgEoA@mail.gmail.com>

Speaking from the vantage point of platform.... This pair of comments
(emphasis mine) have my alarm index on high:

On Fri, Mar 14, 2014 at 2:36 AM, Johan Tibell <johan.tibell at gmail.com>wrote:

> I'm quite worried about this change though. I thought the default rolefor data type was nominal, as that's the safe default. *If
> the default is representational, every package author will need to be aware
> of this feature and update their packages.* That's quite a high cost.
>

On Fri, Mar 14, 2014 at 6:00 AM, Brandon Allbery <allbery.b at gmail.com>
 wrote:

> *Nominal default breaks everything that uses newtype deriving and doesn't
> have role annotations, doesn't it?* Representational default means things
> behave in 7.8 as they did in earlier GHCs.
>

Am I reading these pair of statements correctly? It seems to imply to me
that *every* parameterized type that uses a type constraint on a parameter
*must* be reviewed and possibly annotated to work correctly, one way or the
other!

Seems so:

On Fri, Mar 14, 2014 at 7:22 AM, Richard Eisenberg <eir at cis.upenn.edu>
 wrote:

> So, the best thing we came up with is this: Libraries that wish to export
> abstract data types must do two things:
> 1. Manage export lists carefully.
> *2. Use role annotations.*
>

This is huge order, and one that will produce significant strain on the
ecosystem. For one, this will set back Haskell Platform months: We have
250k lines of Haskell by 30+ authors that will need to be reviewed and
updated.

And all of this is so that data types can be coerced more safely? While I'm
all for safely, the number of places where coercion is that important seems
very small... and this addition to the language and burden on the libraries
very high.

If this feature cannot be added safely without reviewing 1/4 million lines
of library code (not to mention all of hackage)... Then I think it isn't
ready and shouldn't be released in 7.8.

- Mark
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-devs/attachments/20140324/93401ab0/attachment-0001.html>

From svenpanne at gmail.com  Mon Mar 24 14:25:23 2014
From: svenpanne at gmail.com (Sven Panne)
Date: Mon, 24 Mar 2014 14:25:23 -0000
Subject: We need to add role annotations for 7.8
In-Reply-To: <CAAOoiFZKYXzqdfS1PVfG4W_H9ig8iw3MrcTFWu5GrP4C6sgEoA@mail.gmail.com>
References: <78518EC7-BC18-4732-90B6-1AB37048D2A3@cis.upenn.edu>
 <CAK-tuPY0G0ceKK=mNp1N2H-h8S1sN47rahd2OmAXU3RrP-zukQ@mail.gmail.com>
 <CALjd_v5pCBQv4qXAm3E4_qSp8NRLjq1BKV1dJejymsUhruDReQ@mail.gmail.com>
 <CALjd_v6Ar4BVyWyYjpYDy-2UO78tVC3uOcdVyVSSpvi8M-oE9Q@mail.gmail.com>
 <CAEs96n1Xxp9qmXLBf6XqKbLH3kEE3bVLcpLAuFHoVip0N+1D=w@mail.gmail.com>
 <CAEs96n1dVs8SC6an_5eCsx1aCPwbNjbahhNrKAeaSCv1=Qe3gw@mail.gmail.com>
 <CAEs96n0SCjD6_C7VkeL0NUCY+v-fZseeL=iRFZG9fL9b74AjwQ@mail.gmail.com>
 <CAEs96n1WnrVtyjk2f3jOgUZg2M4EwPSA-9bnN6+9dL1p+=Ea0w@mail.gmail.com>
 <CAK-tuPahbPSd4fxjRCMKHYPcsPuzsM3CnBFMBvkoYbAZkVmmjw@mail.gmail.com>
 <CAAOoiFZKYXzqdfS1PVfG4W_H9ig8iw3MrcTFWu5GrP4C6sgEoA@mail.gmail.com>
Message-ID: <CANBN=mtork6rG8NsKLwGiOhrQr5um901iLEmEf6ErUjT_i7N=A@mail.gmail.com>

2014-03-24 15:14 GMT+01:00 Mark Lentczner <mark.lentczner at gmail.com>:
> Speaking from the vantage point of platform.... This pair of comments
> (emphasis mine) have my alarm index on high:
>
> On Fri, Mar 14, 2014 at 2:36 AM, Johan Tibell <johan.tibell at gmail.com>
> wrote: [...]
>> So, the best thing we came up with is this: Libraries that wish to export
>> abstract data types must do two things:
>> 1. Manage export lists carefully.
>> 2. Use role annotations.
>
> This is huge order, and one that will produce significant strain on the
> ecosystem. For one, this will set back Haskell Platform months: We have 250k
> lines of Haskell by 30+ authors that will need to be reviewed and updated. [...]

Hmmm, I didn't follow role annotations at all so far, because I
assumed it was of no concern to me as a library author *unless* I use
some shiny new machinery in my library. Did I misunderstand that? How
can I find out if I have to do something? What happens if I don't do
something? What about Haskell systems which are not GHC? Do I have to
#ifdef around those annotations? :-P

I'm a bit clueless, and I'm guess I'm not alone... :-/ If this new
feature really implies that massive amount of library code review, we
should discuss first if it's really worth the trouble. The GHC release
and the HP are already late...

Cheers,
   S.

From mark.lentczner at gmail.com  Mon Mar 24 14:44:26 2014
From: mark.lentczner at gmail.com (Mark Lentczner)
Date: Mon, 24 Mar 2014 14:44:26 -0000
Subject: We need to add role annotations for 7.8
In-Reply-To: <CAKFCL4Xz_W9of6SyXBsFfk+6Kp4E=T7pjPt4ZhqjqqY9wsixkw@mail.gmail.com>
References: <78518EC7-BC18-4732-90B6-1AB37048D2A3@cis.upenn.edu>
 <CAK-tuPY0G0ceKK=mNp1N2H-h8S1sN47rahd2OmAXU3RrP-zukQ@mail.gmail.com>
 <CALjd_v5pCBQv4qXAm3E4_qSp8NRLjq1BKV1dJejymsUhruDReQ@mail.gmail.com>
 <CALjd_v6Ar4BVyWyYjpYDy-2UO78tVC3uOcdVyVSSpvi8M-oE9Q@mail.gmail.com>
 <CAEs96n1Xxp9qmXLBf6XqKbLH3kEE3bVLcpLAuFHoVip0N+1D=w@mail.gmail.com>
 <CAEs96n1dVs8SC6an_5eCsx1aCPwbNjbahhNrKAeaSCv1=Qe3gw@mail.gmail.com>
 <CAEs96n0SCjD6_C7VkeL0NUCY+v-fZseeL=iRFZG9fL9b74AjwQ@mail.gmail.com>
 <CAEs96n1WnrVtyjk2f3jOgUZg2M4EwPSA-9bnN6+9dL1p+=Ea0w@mail.gmail.com>
 <CAK-tuPahbPSd4fxjRCMKHYPcsPuzsM3CnBFMBvkoYbAZkVmmjw@mail.gmail.com>
 <CAAOoiFZKYXzqdfS1PVfG4W_H9ig8iw3MrcTFWu5GrP4C6sgEoA@mail.gmail.com>
 <CAKFCL4Xz_W9of6SyXBsFfk+6Kp4E=T7pjPt4ZhqjqqY9wsixkw@mail.gmail.com>
Message-ID: <CAAOoiFbjjEMRtOgXPV=P6nKNhEzRy2hhH94qWdaHO=NwLZufWw@mail.gmail.com>

On Mon, Mar 24, 2014 at 7:28 AM, Brandon Allbery <allbery.b at gmail.com>wrote:

> No; if the default is representational, everything works as it did in
> earlier versions, potential bugs/unsafety and all. If the default is
> immediately switched to nominal, *then* every affected type must be
> reviewed immediately.
>

Now I'm confused about the current state of the default....

But it doesn't matter either way: The Platform is expected to work
cohesively with the GHC release, and either of these defaults spells a huge
amount of work for the Platform.


> My counter-proposal was to have 7.8 default to representational to give
> library maintainers a release cycle to add the necessary annotations, then
> switch the default to nominal in 7.10 to get the additional safety.
>

This is unworkable. How much conditional code do you want library writers
to have to have? Library writers strive to have code which works with n
prior releases where n is commonly 3. Having code that works with 7.6, 7.8,
and 7.10 would be a nighmare!

On Mon, Mar 24, 2014 at 7:32 AM, Brandon Allbery <allbery.b at gmail.com>
 wrote:

> perhaps there should be some mechanism to specify to ghc 7.8 whether a
> compile should default to representational or nominal so that authors have
> a way to test their code / look for problems.
>

Also unworkable... now we need a conditional flag for the state of the
default so the code can be written to work with either based on a GHC flag?
And how is that supposed to work with already compiled dependencies
(sandboxed or not)? Is cabal now to take this flag into account? the
Package manager signatures too?

The major problem with this feature is that it is massively global in
scope. This is extremely rare for GHC extensions (Safe comes to mind)...
and with good reason: It is very very expensive. The motivating case here,
a compiler checked safe zero-cost coerce, seems way out of proportion to
the cost: Careful review of every library abstract type, and addition of
*three+* lines of source (remember, this must be CPP guarded, so you have
to add CPP extension on to every file, too).
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-devs/attachments/20140324/44806c2a/attachment-0001.html>

From gershomb at gmail.com  Mon Mar 24 14:57:10 2014
From: gershomb at gmail.com (Gershom Bazerman)
Date: Mon, 24 Mar 2014 14:57:10 -0000
Subject: We need to add role annotations for 7.8
In-Reply-To: <CAAOoiFbjjEMRtOgXPV=P6nKNhEzRy2hhH94qWdaHO=NwLZufWw@mail.gmail.com>
References: <78518EC7-BC18-4732-90B6-1AB37048D2A3@cis.upenn.edu>
 <CAK-tuPY0G0ceKK=mNp1N2H-h8S1sN47rahd2OmAXU3RrP-zukQ@mail.gmail.com>
 <CALjd_v5pCBQv4qXAm3E4_qSp8NRLjq1BKV1dJejymsUhruDReQ@mail.gmail.com>
 <CALjd_v6Ar4BVyWyYjpYDy-2UO78tVC3uOcdVyVSSpvi8M-oE9Q@mail.gmail.com>
 <CAEs96n1Xxp9qmXLBf6XqKbLH3kEE3bVLcpLAuFHoVip0N+1D=w@mail.gmail.com>
 <CAEs96n1dVs8SC6an_5eCsx1aCPwbNjbahhNrKAeaSCv1=Qe3gw@mail.gmail.com>
 <CAEs96n0SCjD6_C7VkeL0NUCY+v-fZseeL=iRFZG9fL9b74AjwQ@mail.gmail.com>
 <CAEs96n1WnrVtyjk2f3jOgUZg2M4EwPSA-9bnN6+9dL1p+=Ea0w@mail.gmail.com>
 <CAK-tuPahbPSd4fxjRCMKHYPcsPuzsM3CnBFMBvkoYbAZkVmmjw@mail.gmail.com>
 <CAAOoiFZKYXzqdfS1PVfG4W_H9ig8iw3MrcTFWu5GrP4C6sgEoA@mail.gmail.com>
 <CAKFCL4Xz_W9of6SyXBsFfk+6Kp4E=T7pjPt4ZhqjqqY9wsixkw@mail.gmail.com>
 <CAAOoiFbjjEMRtOgXPV=P6nKNhEzRy2hhH94qWdaHO=NwLZufWw@mail.gmail.com>
Message-ID: <533047D7.70402@gmail.com>

Apols if I'm overstating the case, but let me try to clear things up.

Roles are not in place to provide a "safe" cheap coerce. Roles are in 
place to _prevent_ an unsoundness with newtype deriving in the presence 
of type families. They also happen to _allow_ a cheaper coerce. The 
unsoundness is fixed by roles, with or without specific role 
annotations, because the necessary roles for type-safety (preventing 
segfault) are inferred/enforced regardless.

With or without roles, in the past, it has been possible to circumvent 
certain mechanisms of abstraction by using newtype deriving. Explicit 
roles now _allow_ library writers to, for the first time, to enforce 
these abstraction mechanisms more strongly than in the past. We also 
happen to have a new "coerce" that will not segfault, and _if_ role 
annotations are correct, will respect representation-hiding. If 
libraries do _not_ get updated with roles, the "worst" that can happen 
is that their abstractions are precisely as deliberately circumventable 
as in the past, although there is now an "easy" function provided that 
makes this circumvention more straightforward.

So I feel it is "better" to enforce representation-hiding through proper 
usage of roles. However, it is also no great sin to _not_ enforce it for 
some span of time, since all that doing so prevents is a rather (at the 
moment) esoteric mechanism for developers to shoot themselves in the 
foot -- a mechanism that in a slightly different form has existed all along.

-g

On 3/24/14, 10:44 AM, Mark Lentczner wrote:
>
> The major problem with this feature is that it is massively global in 
> scope. This is extremely rare for GHC extensions (Safe comes to 
> mind)... and with good reason: It is very very expensive. The 
> motivating case here, a compiler checked safe zero-cost coerce, seems 
> way out of proportion to the cost: Careful review of every library 
> abstract type, and addition of *three+* lines of source (remember, 
> this must be CPP guarded, so you have to add CPP extension on to every 
> file, too).
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-devs/attachments/20140324/a4d64371/attachment-0001.html>