From hvr at gnu.org  Fri Nov  1 09:31:43 2013
From: hvr at gnu.org (Herbert Valerio Riedel)
Date: Fri, 01 Nov 2013 10:31:43 +0100
Subject: Current link-destination Haddock warnings in base
Message-ID: <8761sco4cg.fsf@gnu.org>

Hello *,

...currently, when generating Haddock for `base` I see the warnings
below; shall those warnings remain for GHC 7.8.1, or do we want to
export (at least some of) the missing link destinations to reduce the
amount of Haddock warnings?

,----
| Warning: Data.Type.Coercion: could not find link destinations for:
|     GHC.Types.Coercible
| Warning: Data.Typeable.Internal: could not find link destinations for:
|     GHC.Prim.Proxy#
| Warning: Text.Read: could not find link destinations for:
|     GHC.Types.Coercible
| Warning: Data.List: could not find link destinations for:
|     Data.List.nonEmptySubsequences
| Warning: GHC.Foreign: could not find link destinations for:
|     GHC.Foreign.CString GHC.Foreign.CStringLen
| Warning: GHC.IO.Handle: could not find link destinations for:
|     GHC.IO.Handle.Types.Handle__ GHC.IO.Exception.ResourceVanished
| Warning: GHC.IO.Handle.FD: could not find link destinations for:
|     GHC.IO.FD.FD System.Posix.Internals.FD
| Warning: System.IO: could not find link destinations for:
|     GHC.IO.Exception.ResourceVanished
| Warning: Prelude: could not find link destinations for:
|     GHC.Types.Coercible
| Warning: Data.Data: could not find link destinations for:
|     GHC.Types.Coercible
| Warning: GHC.Event: could not find link destinations for:
|     GHC.Event.TimerManager.TimerManager
`----

Cheers,
  hvr

From afarmer at ittc.ku.edu  Fri Nov  1 15:50:19 2013
From: afarmer at ittc.ku.edu (Andrew Farmer)
Date: Fri, 1 Nov 2013 10:50:19 -0500
Subject: Dynamically loading and unloading (C) object files
In-Reply-To: <1383257267-sup-4703@javelin>
References: <CAETJ90TwQja_EuLcsqo=20RG-oXV4iGQodb2BDgOVgDMPiD=Lw@mail.gmail.com>
 <1383257267-sup-4703@javelin>
Message-ID: <CAJ14jR_WxE-DP5G3Li-VBTu+hsJXNd+KzoEizF0aOEjgjVzNtw@mail.gmail.com>

The published version of that paper in the ACM digital library...

http://dl.acm.org/citation.cfm?id=1017478


On Thu, Oct 31, 2013 at 5:10 PM, Edward Z. Yang <ezyang at mit.edu> wrote:

> > So that leads me to wonder: are there limitations that we should be
> > aware of? Have I simply been lucky so far?
>
> If you are loading Haskell code, you will need to be very careful to
> make sure you load all of the dependencies as well.  There are a number
> of plugins packages and a paper:
> http://citeseerx.ist.psu.edu/viewdoc/summary?doi=10.1.1.9.7627
>
> GHC API changes a lot, so it's easy for these packages to get bitrotted.
>
> The upcoming release of GHC will run constructors (link-time
> initializers), but will not run destructors.
>
> There is only partial support for weak symbols.
> http://ghc.haskell.org/trac/ghc/ticket/3333
>
> Edward
> _______________________________________________
> 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/20131101/be995a8d/attachment.html>

From mark.lentczner at gmail.com  Sun Nov  3 17:57:04 2013
From: mark.lentczner at gmail.com (Mark Lentczner)
Date: Sun, 3 Nov 2013 09:57:04 -0800
Subject: Another CPP gotcha for the manual
Message-ID: <CAAOoiFZYgnLHk1XzeSENS+1vBanCiXYi_R_0xvSJn3QFv3Y5Eg@mail.gmail.com>

Turns out that c pre-processing removes C style (/*?*/) comments. Of
course, it will do this anywhere in the source. The following program can
tell if it is compiled *-cpp* or not:

module Main where

(*/**) :: Double -> Double -> Double
(*/**) a b = a / (2 ** b)

howCompiled = if use > 1/16 then "normal" else "-cpp"
  where
    use = 1 */** 2 + 3 */** 4

main = putStrLn $ "compiled " ++ howCompiled


When run:

& runhaskell CppTest.hs
compiled normal

& runhaskell -cpp CppTest.hs
compiled -cpp


An example in the wild is in the package *wai-extra*, in the file
*Network/Wai/Middleware/RequestLogger.hs* where the */* construct appears
twice in the comments.

Short of defining and implementing our own CPP-like preprocessing
(something we might actually consider), I don't think there really is any
fix for this, so the bug is that it should appear in the GHC documentation
on CPP mode  (?4.12.3), along with similar warnings about trailing
back-slashes.

Note that the way in which a multi-line comment is removed differs between
*gcc* and *clang*. In *gcc*, the comment is removed and content of the line
before the comment, and contents of the line after the comment are joined
into a single line. In *clang*, the two line fragments are kept on separate
lines. In both cases extra empty lines are added to keep the line count the
same.

The consequence of the *gcc* / *clang* difference is that neither the above
code, nor wai-extra will compile with *clang*.

Note: As far as I can tell this is not a *clang* bug, but a failure of
specs: The C definition of comments and their removal is vague, and my
guess is *gcc* choose its method based on historical use. The C++
definition makes it clear that comments are whitespace, even once removed,
and so the *clang* method is correct.

- Mark
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/ghc-devs/attachments/20131103/9e2161b8/attachment.html>

From daniel.trstenjak at gmail.com  Sun Nov  3 19:01:26 2013
From: daniel.trstenjak at gmail.com (Daniel Trstenjak)
Date: Sun, 3 Nov 2013 20:01:26 +0100
Subject: Another CPP gotcha for the manual
In-Reply-To: <CAAOoiFZYgnLHk1XzeSENS+1vBanCiXYi_R_0xvSJn3QFv3Y5Eg@mail.gmail.com>
References: <CAAOoiFZYgnLHk1XzeSENS+1vBanCiXYi_R_0xvSJn3QFv3Y5Eg@mail.gmail.com>
Message-ID: <CAPZ0SW6YtZR0TL-cP=vJowru5k4q+jynFCnKvTn-PR23sWjkFw@mail.gmail.com>

> An example in the wild is in the package wai-extra, in the
file Network/Wai/Middleware/RequestLogger.hs where the */* construct
appears twice in the comments.

An even more common case could be the operator '//' of the vector package.
cpp also removes C++ style comments.

I once almost got crazy finding this kind issue,
because the resulting code still type checked.

Greetings,
Daniel
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/ghc-devs/attachments/20131103/a1532b51/attachment.html>

From mark.lentczner at gmail.com  Sun Nov  3 23:01:32 2013
From: mark.lentczner at gmail.com (Mark Lentczner)
Date: Sun, 3 Nov 2013 15:01:32 -0800
Subject: Another CPP gotcha for the manual
In-Reply-To: <CAPZ0SW6YtZR0TL-cP=vJowru5k4q+jynFCnKvTn-PR23sWjkFw@mail.gmail.com>
References: <CAAOoiFZYgnLHk1XzeSENS+1vBanCiXYi_R_0xvSJn3QFv3Y5Eg@mail.gmail.com>
 <CAPZ0SW6YtZR0TL-cP=vJowru5k4q+jynFCnKvTn-PR23sWjkFw@mail.gmail.com>
Message-ID: <CAAOoiFa-p+75TGm8yA_fuYjTfLgg06WB_z5a9GdY=Oo_NxRRDg@mail.gmail.com>

This does not appear to be the case, at least any more. The way GHC invokes
gcc for c pre-processing only removes /*?*/ style comments, not the later
// style:

module Main where

(//) :: Double -> Double -> Double
a // b = a / b / b

main = print $ 1 // 2


works:

& runhaskell -cpp CppTest2.hs
0.25
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/ghc-devs/attachments/20131103/341f730c/attachment.html>

From austin at well-typed.com  Mon Nov  4 00:37:27 2013
From: austin at well-typed.com (Austin Seipp)
Date: Sun, 3 Nov 2013 18:37:27 -0600
Subject: 7.8.1 RC
Message-ID: <CAEs96n3QWWbMhpx5isszfN1WdaWNH5of-iOjdXfRn8q5u-uW7Q@mail.gmail.com>

Hello all,

First and foremost, I realize that I said an RC was coming on Friday
along with a branch, but I've unfortunately been a bit behind the gun
this week, and several things more things have come to my attention
recently.

For the delay, I am very sorry. Here's an update on the most pertinent
tickets and what needs to happen.

One thing is that Herbert and I would like to upload many of the
bootstrap libraries to hackage to coincide with the release, but this
requires a server upgrade that should happen quite soon (thanks to
Duncan/Herbert.)

Herber and I also went over #8305, which should (in our opinion)
certainly be part of the RC so issues can be filed, and clearly
documented. Herbert has a patch for this, and I'll review it today.

Second, the new OS X release, Mavericks (and, by association, XCode 5)
seem to be a little confusing at the moment, and I don't have access
to these machines quite yet. Only a Lion machine.

One reason this is a delay is because I don't quite understand e.g.
#8497 and #8493 in particular. There has also historically been some
issues with different OS X builds not working on different platforms
due to XCode and/or strange ABI issues, so I need to make my own to
double check.

Preprocessing seems to becoming a hot issue* on the note of #8493, and
this also certainly needs attention once I get my hands on a machine.
There's been a lot of pain around making all this 'work correctly',
and working by proxy is simply becoming difficult I think, so I just
need to dig into it a bit once I have my hands on something.

Also relevant to this is that I'll be signing the announcement, and
giving out tarballs with checksums(!), so some of these issues must be
fixed for distribution (like #5987, which I am still investigating.)

Finally, I have some incoming patches to fix a few of the critical
priority bugs (related to Windows, mostly,) but they need to be
polished and I need to investigate some other things related to them
(e.g. due to lack of time, I only have a 'very slow path' fix for
#8228, which is a bit annoying. And also this new msys2 thing.)

* Richard Smith, if you're out there, I should have listened to you on
the LLVM list. I'll learn from this one.

-- 
Regards,

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

From malcolm.wallace at me.com  Mon Nov  4 09:28:27 2013
From: malcolm.wallace at me.com (Malcolm Wallace)
Date: Mon, 04 Nov 2013 09:28:27 +0000
Subject: Another CPP gotcha for the manual
In-Reply-To: <CAAOoiFZYgnLHk1XzeSENS+1vBanCiXYi_R_0xvSJn3QFv3Y5Eg@mail.gmail.com>
References: <CAAOoiFZYgnLHk1XzeSENS+1vBanCiXYi_R_0xvSJn3QFv3Y5Eg@mail.gmail.com>
Message-ID: <70E87522-BC04-4D16-AFCE-94F78FBEB2ED@me.com>

Of course, cpphs solved this problem nearly a decade ago.

Regards,
    Malcolm


On 3 Nov 2013, at 17:57, Mark Lentczner wrote:

> Turns out that c pre-processing removes C style (/*?*/) comments. Of course, it will do this anywhere in the source. The following program can tell if it is compiled -cpp or not:
> 
> module Main where
> 
> (*/**) :: Double -> Double -> Double
> (*/**) a b = a / (2 ** b)
> 
> howCompiled = if use > 1/16 then "normal" else "-cpp"
>   where
>     use = 1 */** 2 + 3 */** 4
> 
> main = putStrLn $ "compiled " ++ howCompiled
> 
> When run:
> 
> & runhaskell CppTest.hs
> compiled normal
> 
> & runhaskell -cpp CppTest.hs
> compiled -cpp
> 
> An example in the wild is in the package wai-extra, in the file Network/Wai/Middleware/RequestLogger.hs where the */* construct appears twice in the comments.
> 
> Short of defining and implementing our own CPP-like preprocessing (something we might actually consider), I don't think there really is any fix for this, so the bug is that it should appear in the GHC documentation on CPP mode  (?4.12.3), along with similar warnings about trailing back-slashes.
> 
> Note that the way in which a multi-line comment is removed differs between gcc and clang. In gcc, the comment is removed and content of the line before the comment, and contents of the line after the comment are joined into a single line. In clang, the two line fragments are kept on separate lines. In both cases extra empty lines are added to keep the line count the same.
> 
> The consequence of the gcc / clang difference is that neither the above code, nor wai-extra will compile with clang.
> 
> Note: As far as I can tell this is not a clang bug, but a failure of specs: The C definition of comments and their removal is vague, and my guess is gcc choose its method based on historical use. The C++ definition makes it clear that comments are whitespace, even once removed, and so the clang method is correct.
> 
> - Mark
> 
> _______________________________________________
> ghc-devs mailing list
> ghc-devs at haskell.org
> http://www.haskell.org/mailman/listinfo/ghc-devs


From daniel.trstenjak at gmail.com  Mon Nov  4 09:29:50 2013
From: daniel.trstenjak at gmail.com (Daniel Trstenjak)
Date: Mon, 4 Nov 2013 10:29:50 +0100
Subject: Another CPP gotcha for the manual
In-Reply-To: <CAAOoiFa-p+75TGm8yA_fuYjTfLgg06WB_z5a9GdY=Oo_NxRRDg@mail.gmail.com>
References: <CAAOoiFZYgnLHk1XzeSENS+1vBanCiXYi_R_0xvSJn3QFv3Y5Eg@mail.gmail.com>
 <CAPZ0SW6YtZR0TL-cP=vJowru5k4q+jynFCnKvTn-PR23sWjkFw@mail.gmail.com>
 <CAAOoiFa-p+75TGm8yA_fuYjTfLgg06WB_z5a9GdY=Oo_NxRRDg@mail.gmail.com>
Message-ID: <20131104092950.GA2286@machine>


Hi Mark,


On Sun, Nov 03, 2013 at 03:01:32PM -0800, Mark Lentczner wrote:
> This does not appear to be the case, at least any more. The way GHC invokes gcc
> for c pre-processing only removes /*?*/ style comments, not the later // style:

Yes, I can reproduce your behaviour on my system and ghc seems to call cpp with
some options, because the default behaviour removes C++ style comments:

dan at machine ~> cat cpp.test 
/* comment */
code
// comment


dan at machine ~> cpp cpp.test 
# 1 "cpp.test"
# 1 "<command-line>"
# 1 "cpp.test"

code


I can't recall it exactly, if I had the C++ comment issue only with
cpphs, because cpp had problems with some Haskell code, or if I also
had the issue with cpp itself.


I just tried cpphs and its default behaviour removes the C++ style comments:

dan at machine ~> cat test.hs
(//) :: Double -> Double -> Double
a // b = a / b / b

main = print $ 1 // 2


dan at machine ~> ghci
Prelude> :set -cpp -pgmPcpphs -optP--cpp
Prelude> :l test
[1 of 1] Compiling Main             ( test.hs, interpreted )

test.hs:2:1:
    parse error (possibly incorrect indentation or mismatched brackets)
Failed, modules loaded: none.


That's a bit unfortunate, that the default behaviour of ghc using cpp and cpphs differs.


Greetings,
Daniel

From hvr at gnu.org  Mon Nov  4 09:40:47 2013
From: hvr at gnu.org (Herbert Valerio Riedel)
Date: Mon, 04 Nov 2013 10:40:47 +0100
Subject: Another CPP gotcha for the manual
In-Reply-To: <70E87522-BC04-4D16-AFCE-94F78FBEB2ED@me.com> (Malcolm Wallace's
 message of "Mon, 04 Nov 2013 09:28:27 +0000")
References: <CAAOoiFZYgnLHk1XzeSENS+1vBanCiXYi_R_0xvSJn3QFv3Y5Eg@mail.gmail.com>
 <70E87522-BC04-4D16-AFCE-94F78FBEB2ED@me.com>
Message-ID: <87sivc5wtc.fsf@gnu.org>

Hello Malcolm,

On 2013-11-04 at 10:28:27 +0100, Malcolm Wallace wrote:
> Of course, cpphs solved this problem nearly a decade ago.

Btw, what has been the reason it hasn't been adopted as bundled `cpp`
replacement in the GHC distribution in the past? (if it remains a
separate executable, its GPL licence shouldn't be an issue -- after all,
ghc relies on the gcc executable which is GPL'ed too)

cheers,
  hvr

From malcolm.wallace at me.com  Mon Nov  4 09:52:56 2013
From: malcolm.wallace at me.com (Malcolm Wallace)
Date: Mon, 04 Nov 2013 09:52:56 +0000
Subject: Another CPP gotcha for the manual
In-Reply-To: <87sivc5wtc.fsf@gnu.org>
References: <CAAOoiFZYgnLHk1XzeSENS+1vBanCiXYi_R_0xvSJn3QFv3Y5Eg@mail.gmail.com>
 <70E87522-BC04-4D16-AFCE-94F78FBEB2ED@me.com> <87sivc5wtc.fsf@gnu.org>
Message-ID: <879076D3-7808-4859-BA05-CF76BDA38950@me.com>

AFAIK, it is solely the (L)GPL licence issue.  GHC central preferred to use/distribute the GPL'd gcc compiler rather than the GPL'd cpphs preprocessor.  (No, it made no sense to me either.)

Regards,
    Malcolm


On 4 Nov 2013, at 09:40, Herbert Valerio Riedel wrote:

> Hello Malcolm,
> 
> On 2013-11-04 at 10:28:27 +0100, Malcolm Wallace wrote:
>> Of course, cpphs solved this problem nearly a decade ago.
> 
> Btw, what has been the reason it hasn't been adopted as bundled `cpp`
> replacement in the GHC distribution in the past? (if it remains a
> separate executable, its GPL licence shouldn't be an issue -- after all,
> ghc relies on the gcc executable which is GPL'ed too)
> 
> cheers,
>  hvr
> _______________________________________________
> ghc-devs mailing list
> ghc-devs at haskell.org
> http://www.haskell.org/mailman/listinfo/ghc-devs


From marlowsd at gmail.com  Mon Nov  4 10:18:43 2013
From: marlowsd at gmail.com (Simon Marlow)
Date: Mon, 04 Nov 2013 10:18:43 +0000
Subject: Why do we put GMP allocations on GHC heaps?
In-Reply-To: <CAJumaK826B25OLsKpdpuRyd5cGSmVxpnP1jQaP5gCLPkf32i+Q@mail.gmail.com>
References: <8761sp7zgg.fsf@gergely.risko.hu> <1382484659-sup-4749@javelin>
 <87ob65q480.fsf@mid.deneb.enyo.de>
 <CAJumaK826B25OLsKpdpuRyd5cGSmVxpnP1jQaP5gCLPkf32i+Q@mail.gmail.com>
Message-ID: <52777483.8020901@gmail.com>

On 31/10/2013 07:49, Edward Kmett wrote:
> That actually would be a pretty reasonable way forward, that could
> maintain the performance of the current approach without crippling GMP
> for other consumers.
>
> It'd probably be a fair bit of work, as you wind up up to your eyeballs
> in the guts of the library, limbs everywhere, colorful body part
> metaphors flying every which way.
>
> It doesn't make accessing libraries like MPFR from Haskell in the most
> high performance way all that much easier, but it does mean that if you
> linked to a library that used them you wouldn't just start randomly
> segfaulting like you do today.
>
> If someone else doesn't get around to it first, I'll probably give it a
> shot eventually.

We did originally look at targetting the mpn API, but decided against it 
for the reasons alluded to above - the mpz layer has quite a lot of 
stuff in it that you would need to replicate.  For instance, when you 
start doing an operation some calculation has to be done to figure out 
how much memory to allocate for the result.  And be extra careful, 
because the GMP code is GPL, so our replacement for the mpz bits would 
probably end up being GPL too.

Historical tidbit: hbc targets the mpn layer, IIRC.

Cheers,
Simon


>
> -Edward
>
>
> On Thu, Oct 31, 2013 at 3:39 AM, Florian Weimer <fw at deneb.enyo.de
> <mailto:fw at deneb.enyo.de>> wrote:
>
>     * Edward Z. Yang:
>
>      > Actually, this is precisely the problem.  When is a GMP integer
>     freed?
>      > It can have pointers to it from objects on the heap, so this free
>     should
>      > only occur when the integer is dead, with no references from the
>     heap.
>      > How can that be arranged?  Well, the garbage collector is responsible
>      > for figuring this out.  So why shouldn't they just live on the
>     heap, and
>      > then smoothly integrate with the existing garbage collector.
>
>     The real problem here is that GHC uses the mpz_* functions and not the
>     lower-level mpn_* functions, where the caller is responsible for
>     memory management and which would play well with garbage collection
>     (or any other memory management scheme).
>     _______________________________________________
>     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 roma at ro-che.info  Mon Nov  4 15:37:05 2013
From: roma at ro-che.info (Roman Cheplyaka)
Date: Mon, 4 Nov 2013 17:37:05 +0200
Subject: More GND + role inference woes
In-Reply-To: <B756D6A5-6890-4C9F-966D-F06CD0E8D8C3@cis.upenn.edu>
References: <CAJumaK8+Ok1-N5xjbBsrHbMbdXZ6P4EL3ssLWSURFyXLS5GJUA@mail.gmail.com>
 <CAJumaK9cFA7fNPKH9DmE1vmEw7MB=0iMZhZy7okiK8x75Df09Q@mail.gmail.com>
 <59543203684B2244980D7E4057D5FBC14864A4A7@DB3EX14MBXC308.europe.corp.microsoft.com>
 <B756D6A5-6890-4C9F-966D-F06CD0E8D8C3@cis.upenn.edu>
Message-ID: <20131104153705.GA16508@sniper>

* Richard Eisenberg <eir at cis.upenn.edu> [2013-10-16 13:28:54-0400]
> > Moreover, I think this solves the other failures in http://www.haskell.org/pipermail/ghc-devs/2013-October/002961.html.  Here is one example, in that email.  smallcheck has this:
> > newtype Series m a = Series (ReaderT Depth (LogicT m) a)
> >   deriving
> >     ( ?,  MonadLogic)
> >  
> > where logict defines MonadLogic thus:
> >  
> > class (MonadPlus m) => MonadLogic m where
> >     msplit     :: m a -> m (Maybe (a, m a))
> >  
> > So the ?bottom line? check above will attempt to find a cocercion betwem msplit?s type with m=Series m, and with m=ReaderT Depth (LogitT m).  Right?
> 
> Yes.
> 
> >   So on the left of msplit?s arrow, we?ll ask can we prove
> >  
> >      Series m a ~R ReaderT Depth (LogicT m) a
> >  
> > Can we show that?  Yes, of course? that is the very newtype coercion for Series.
> 
> Well, it's the right-hand side of the arrow that's more troublesome, but that works out in this case, too.

I just tried compiling smallcheck with GHC HEAD, and it didn't work out:

  Test/SmallCheck/SeriesMonad.hs:41:7:
      Can't make a derived instance of ?MonadLogic (Series m)?
        (even with cunning newtype deriving):
        it is not type-safe to use GeneralizedNewtypeDeriving on this class;
        ?msplit?, at type ?forall a.
                           m a -> m (Maybe (a, m a))?, cannot be converted safely
      In the newtype declaration for ?Series?

So GHC now looks at the methods, but the problem is still there.

What do you guys think?

I would agree that msplit's type is problematic (due to the nested m's),
but Simon and Richard previously said that it should work, so I'm
confused.

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

From roma at ro-che.info  Mon Nov  4 15:59:52 2013
From: roma at ro-che.info (Roman Cheplyaka)
Date: Mon, 4 Nov 2013 17:59:52 +0200
Subject: GND and Safe Haskell
Message-ID: <20131104155952.GA17404@sniper>

GHC HEAD still doesn't seem to recognize GND as Safe. I guess we can
lift this restriction now that we have roles?

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

From eir at cis.upenn.edu  Mon Nov  4 16:02:25 2013
From: eir at cis.upenn.edu (Richard Eisenberg)
Date: Mon, 4 Nov 2013 11:02:25 -0500
Subject: More GND + role inference woes
In-Reply-To: <20131104153705.GA16508@sniper>
References: <CAJumaK8+Ok1-N5xjbBsrHbMbdXZ6P4EL3ssLWSURFyXLS5GJUA@mail.gmail.com>
 <CAJumaK9cFA7fNPKH9DmE1vmEw7MB=0iMZhZy7okiK8x75Df09Q@mail.gmail.com>
 <59543203684B2244980D7E4057D5FBC14864A4A7@DB3EX14MBXC308.europe.corp.microsoft.com>
 <B756D6A5-6890-4C9F-966D-F06CD0E8D8C3@cis.upenn.edu>
 <20131104153705.GA16508@sniper>
Message-ID: <1CEC1835-9490-4C18-8443-57DF48320A5F@cis.upenn.edu>

Bah. This is a bug. I will fix.

Thanks for pointing it out!
Richard

On Nov 4, 2013, at 10:37 AM, Roman Cheplyaka <roma at ro-che.info> wrote:

> * Richard Eisenberg <eir at cis.upenn.edu> [2013-10-16 13:28:54-0400]
>>> Moreover, I think this solves the other failures in http://www.haskell.org/pipermail/ghc-devs/2013-October/002961.html.  Here is one example, in that email.  smallcheck has this:
>>> newtype Series m a = Series (ReaderT Depth (LogicT m) a)
>>>  deriving
>>>    ( ?,  MonadLogic)
>>> 
>>> where logict defines MonadLogic thus:
>>> 
>>> class (MonadPlus m) => MonadLogic m where
>>>    msplit     :: m a -> m (Maybe (a, m a))
>>> 
>>> So the ?bottom line? check above will attempt to find a cocercion betwem msplit?s type with m=Series m, and with m=ReaderT Depth (LogitT m).  Right?
>> 
>> Yes.
>> 
>>>  So on the left of msplit?s arrow, we?ll ask can we prove
>>> 
>>>     Series m a ~R ReaderT Depth (LogicT m) a
>>> 
>>> Can we show that?  Yes, of course? that is the very newtype coercion for Series.
>> 
>> Well, it's the right-hand side of the arrow that's more troublesome, but that works out in this case, too.
> 
> I just tried compiling smallcheck with GHC HEAD, and it didn't work out:
> 
>  Test/SmallCheck/SeriesMonad.hs:41:7:
>      Can't make a derived instance of ?MonadLogic (Series m)?
>        (even with cunning newtype deriving):
>        it is not type-safe to use GeneralizedNewtypeDeriving on this class;
>        ?msplit?, at type ?forall a.
>                           m a -> m (Maybe (a, m a))?, cannot be converted safely
>      In the newtype declaration for ?Series?
> 
> So GHC now looks at the methods, but the problem is still there.
> 
> What do you guys think?
> 
> I would agree that msplit's type is problematic (due to the nested m's),
> but Simon and Richard previously said that it should work, so I'm
> confused.
> 
> Roman


From eir at cis.upenn.edu  Mon Nov  4 16:04:51 2013
From: eir at cis.upenn.edu (Richard Eisenberg)
Date: Mon, 4 Nov 2013 11:04:51 -0500
Subject: GND and Safe Haskell
In-Reply-To: <20131104155952.GA17404@sniper>
References: <20131104155952.GA17404@sniper>
Message-ID: <FBE207B1-3B95-40EF-97D0-89BEC25A3AA6@cis.upenn.edu>

Roles makes GND completely type-safe. You cannot make unsafeCoerce using GND.

However, you can look around abstractions with GND, both before and after roles -- roles weren't really designed to stop you from doing this. See #5498. Whether this is grounds to make GND unSafe is up to the designers of Safe Haskell.

Richard

On Nov 4, 2013, at 10:59 AM, Roman Cheplyaka <roma at ro-che.info> wrote:

> GHC HEAD still doesn't seem to recognize GND as Safe. I guess we can
> lift this restriction now that we have roles?
> 
> Roman
> _______________________________________________
> ghc-devs mailing list
> ghc-devs at haskell.org
> http://www.haskell.org/mailman/listinfo/ghc-devs


From carter.schonwald at gmail.com  Mon Nov  4 18:37:42 2013
From: carter.schonwald at gmail.com (Carter Schonwald)
Date: Mon, 4 Nov 2013 13:37:42 -0500
Subject: Another CPP gotcha for the manual
In-Reply-To: <879076D3-7808-4859-BA05-CF76BDA38950@me.com>
References: <CAAOoiFZYgnLHk1XzeSENS+1vBanCiXYi_R_0xvSJn3QFv3Y5Eg@mail.gmail.com>
 <70E87522-BC04-4D16-AFCE-94F78FBEB2ED@me.com>
 <87sivc5wtc.fsf@gnu.org>
 <879076D3-7808-4859-BA05-CF76BDA38950@me.com>
Message-ID: <CAHYVw0yxjcgV-g7fFe20DhwsG1eOf8CGTfQQy-0uVZAUOUDpAQ@mail.gmail.com>

Maybe we should experiment with it a bit more seriously.   With cabal 1.18
it's super easy to tell ghc to call an external program for the cpp pass.
And that's our current source of problems.

On Monday, November 4, 2013, Malcolm Wallace wrote:

> AFAIK, it is solely the (L)GPL licence issue.  GHC central preferred to
> use/distribute the GPL'd gcc compiler rather than the GPL'd cpphs
> preprocessor.  (No, it made no sense to me either.)
>
> Regards,
>     Malcolm
>
>
> On 4 Nov 2013, at 09:40, Herbert Valerio Riedel wrote:
>
> > Hello Malcolm,
> >
> > On 2013-11-04 at 10:28:27 +0100, Malcolm Wallace wrote:
> >> Of course, cpphs solved this problem nearly a decade ago.
> >
> > Btw, what has been the reason it hasn't been adopted as bundled `cpp`
> > replacement in the GHC distribution in the past? (if it remains a
> > separate executable, its GPL licence shouldn't be an issue -- after all,
> > ghc relies on the gcc executable which is GPL'ed too)
> >
> > cheers,
> >  hvr
> > _______________________________________________
> > ghc-devs mailing list
> > ghc-devs at haskell.org <javascript:;>
> > http://www.haskell.org/mailman/listinfo/ghc-devs
>
> _______________________________________________
> 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/20131104/10ea5386/attachment.html>

From carter.schonwald at gmail.com  Mon Nov  4 18:39:09 2013
From: carter.schonwald at gmail.com (Carter Schonwald)
Date: Mon, 4 Nov 2013 13:39:09 -0500
Subject: Another CPP gotcha for the manual
In-Reply-To: <CAHYVw0yxjcgV-g7fFe20DhwsG1eOf8CGTfQQy-0uVZAUOUDpAQ@mail.gmail.com>
References: <CAAOoiFZYgnLHk1XzeSENS+1vBanCiXYi_R_0xvSJn3QFv3Y5Eg@mail.gmail.com>
 <70E87522-BC04-4D16-AFCE-94F78FBEB2ED@me.com>
 <87sivc5wtc.fsf@gnu.org>
 <879076D3-7808-4859-BA05-CF76BDA38950@me.com>
 <CAHYVw0yxjcgV-g7fFe20DhwsG1eOf8CGTfQQy-0uVZAUOUDpAQ@mail.gmail.com>
Message-ID: <CAHYVw0w1ZSYUCZ_frKVofYfSy2_GJn2qvOehz_UwGLe_bt464g@mail.gmail.com>

I mean, that may be the best near term fix for our problems. Does require
Haskell platform to ship with cabal 1.18, but maybe that approach would fix
all the cpp woes for the near term. ESP since most cpp use is in cabalized
projects anyways.

On Monday, November 4, 2013, Carter Schonwald wrote:

> Maybe we should experiment with it a bit more seriously.   With cabal 1.18
> it's super easy to tell ghc to call an external program for the cpp pass.
> And that's our current source of problems.
>
> On Monday, November 4, 2013, Malcolm Wallace wrote:
>
>> AFAIK, it is solely the (L)GPL licence issue.  GHC central preferred to
>> use/distribute the GPL'd gcc compiler rather than the GPL'd cpphs
>> preprocessor.  (No, it made no sense to me either.)
>>
>> Regards,
>>     Malcolm
>>
>>
>> On 4 Nov 2013, at 09:40, Herbert Valerio Riedel wrote:
>>
>> > Hello Malcolm,
>> >
>> > On 2013-11-04 at 10:28:27 +0100, Malcolm Wallace wrote:
>> >> Of course, cpphs solved this problem nearly a decade ago.
>> >
>> > Btw, what has been the reason it hasn't been adopted as bundled `cpp`
>> > replacement in the GHC distribution in the past? (if it remains a
>> > separate executable, its GPL licence shouldn't be an issue -- after all,
>> > ghc relies on the gcc executable which is GPL'ed too)
>> >
>> > cheers,
>> >  hvr
>> > _______________________________________________
>> > 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/20131104/d1b14647/attachment.html>

From eir at cis.upenn.edu  Mon Nov  4 18:52:45 2013
From: eir at cis.upenn.edu (Richard Eisenberg)
Date: Mon, 4 Nov 2013 13:52:45 -0500
Subject: More GND + role inference woes
In-Reply-To: <1CEC1835-9490-4C18-8443-57DF48320A5F@cis.upenn.edu>
References: <CAJumaK8+Ok1-N5xjbBsrHbMbdXZ6P4EL3ssLWSURFyXLS5GJUA@mail.gmail.com>
 <CAJumaK9cFA7fNPKH9DmE1vmEw7MB=0iMZhZy7okiK8x75Df09Q@mail.gmail.com>
 <59543203684B2244980D7E4057D5FBC14864A4A7@DB3EX14MBXC308.europe.corp.microsoft.com>
 <B756D6A5-6890-4C9F-966D-F06CD0E8D8C3@cis.upenn.edu>
 <20131104153705.GA16508@sniper>
 <1CEC1835-9490-4C18-8443-57DF48320A5F@cis.upenn.edu>
Message-ID: <439298DB-022C-43DF-9FF8-67E3487A9B5B@cis.upenn.edu>

Bah^2.

This is subtler than I thought.

See the ticket commentary here: http://ghc.haskell.org/trac/ghc/ticket/8503

Richard

On Nov 4, 2013, at 11:02 AM, Richard Eisenberg <eir at cis.upenn.edu> wrote:

> Bah. This is a bug. I will fix.
> 
> Thanks for pointing it out!
> Richard
> 
> On Nov 4, 2013, at 10:37 AM, Roman Cheplyaka <roma at ro-che.info> wrote:
> 
>> * Richard Eisenberg <eir at cis.upenn.edu> [2013-10-16 13:28:54-0400]
>>>> Moreover, I think this solves the other failures in http://www.haskell.org/pipermail/ghc-devs/2013-October/002961.html.  Here is one example, in that email.  smallcheck has this:
>>>> newtype Series m a = Series (ReaderT Depth (LogicT m) a)
>>>> deriving
>>>>   ( ?,  MonadLogic)
>>>> 
>>>> where logict defines MonadLogic thus:
>>>> 
>>>> class (MonadPlus m) => MonadLogic m where
>>>>   msplit     :: m a -> m (Maybe (a, m a))
>>>> 
>>>> So the ?bottom line? check above will attempt to find a cocercion betwem msplit?s type with m=Series m, and with m=ReaderT Depth (LogitT m).  Right?
>>> 
>>> Yes.
>>> 
>>>> So on the left of msplit?s arrow, we?ll ask can we prove
>>>> 
>>>>    Series m a ~R ReaderT Depth (LogicT m) a
>>>> 
>>>> Can we show that?  Yes, of course? that is the very newtype coercion for Series.
>>> 
>>> Well, it's the right-hand side of the arrow that's more troublesome, but that works out in this case, too.
>> 
>> I just tried compiling smallcheck with GHC HEAD, and it didn't work out:
>> 
>> Test/SmallCheck/SeriesMonad.hs:41:7:
>>     Can't make a derived instance of ?MonadLogic (Series m)?
>>       (even with cunning newtype deriving):
>>       it is not type-safe to use GeneralizedNewtypeDeriving on this class;
>>       ?msplit?, at type ?forall a.
>>                          m a -> m (Maybe (a, m a))?, cannot be converted safely
>>     In the newtype declaration for ?Series?
>> 
>> So GHC now looks at the methods, but the problem is still there.
>> 
>> What do you guys think?
>> 
>> I would agree that msplit's type is problematic (due to the nested m's),
>> but Simon and Richard previously said that it should work, so I'm
>> confused.
>> 
>> Roman
> 
> _______________________________________________
> ghc-devs mailing list
> ghc-devs at haskell.org
> http://www.haskell.org/mailman/listinfo/ghc-devs
> 


From conal at conal.net  Mon Nov  4 20:08:11 2013
From: conal at conal.net (Conal Elliott)
Date: Mon, 4 Nov 2013 12:08:11 -0800
Subject: Finding & assembling class dictionaries from GHC plugins?
Message-ID: <CAD6SzRJM0B-e_THKMPi7p_Jw56DTzAVMGQdbyo2sg3quVvWuNA@mail.gmail.com>

I'm working on a GHC plugin (for compiling Haskell to hardware), and I need
to synthesize Typeable (and maybe other) class dictionaries for a wide
range of types, including composite types (functions, pairs, lists, etc).
Can it be done, and how? I think I'm mainly looking for mechanics of
finding existing class instances (however they're defined) and assembling
them (for parametrized/composite dictionaries), rather than mechanisms
specific to Typeable.

Thanks, -- Conal
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/ghc-devs/attachments/20131104/eba66537/attachment.html>

From fw at deneb.enyo.de  Mon Nov  4 20:36:20 2013
From: fw at deneb.enyo.de (Florian Weimer)
Date: Mon, 04 Nov 2013 21:36:20 +0100
Subject: Why do we put GMP allocations on GHC heaps?
In-Reply-To: <52777483.8020901@gmail.com> (Simon Marlow's message of "Mon, 04
 Nov 2013 10:18:43 +0000")
References: <8761sp7zgg.fsf@gergely.risko.hu> <1382484659-sup-4749@javelin>
 <87ob65q480.fsf@mid.deneb.enyo.de>
 <CAJumaK826B25OLsKpdpuRyd5cGSmVxpnP1jQaP5gCLPkf32i+Q@mail.gmail.com>
 <52777483.8020901@gmail.com>
Message-ID: <87ppqfyke3.fsf@mid.deneb.enyo.de>

* Simon Marlow:

> We did originally look at targetting the mpn API, but decided against
> it for the reasons alluded to above - the mpz layer has quite a lot of
> stuff in it that you would need to replicate.  For instance, when you
> start doing an operation some calculation has to be done to figure out
> how much memory to allocate for the result.

Sure, and you have to do sign handling.  The advantage is that you
could use a convenient encoding for length and sign, or deal with
carry/borrow in a flexible manner (i.e., stealing another word from
the allocation buffer).  It's not exactly trivial, but the effort may
be worth it.

> And be extra careful, because the GMP code is GPL, so our
> replacement for the mpz bits would probably end up being GPL too.

Actually, it's LGPL, and interesting bits are part of libc under an
even more permissive license.

From marlowsd at gmail.com  Tue Nov  5 08:41:30 2013
From: marlowsd at gmail.com (Simon Marlow)
Date: Tue, 05 Nov 2013 08:41:30 +0000
Subject: Another CPP gotcha for the manual
In-Reply-To: <879076D3-7808-4859-BA05-CF76BDA38950@me.com>
References: <CAAOoiFZYgnLHk1XzeSENS+1vBanCiXYi_R_0xvSJn3QFv3Y5Eg@mail.gmail.com>
 <70E87522-BC04-4D16-AFCE-94F78FBEB2ED@me.com> <87sivc5wtc.fsf@gnu.org>
 <879076D3-7808-4859-BA05-CF76BDA38950@me.com>
Message-ID: <5278AF3A.2000502@gmail.com>

cpphs would be *another* GPL dependency.  It doesn't replace gcc, which 
we need for other reasons, so at the time adopting cpphs didn't solve 
any problems.  Now, arguably it would.

I'd still prefer not to add another GPL dependency(*).  But I'm not 
going to argue strongly against it.  If we're seriously considering 
using cpphs, we should carefully measure the impact on compilation time.

Cheers,
Simon

(*) For the pedants, yes I know the difference between GPL and LGPL and 
the difference between library and executable dependencies.  I was a 
pedant once too :-)

On 04/11/2013 09:52, Malcolm Wallace wrote:
> AFAIK, it is solely the (L)GPL licence issue.  GHC central preferred to use/distribute the GPL'd gcc compiler rather than the GPL'd cpphs preprocessor.  (No, it made no sense to me either.)
>
> Regards,
>      Malcolm
>
>
> On 4 Nov 2013, at 09:40, Herbert Valerio Riedel wrote:
>
>> Hello Malcolm,
>>
>> On 2013-11-04 at 10:28:27 +0100, Malcolm Wallace wrote:
>>> Of course, cpphs solved this problem nearly a decade ago.
>>
>> Btw, what has been the reason it hasn't been adopted as bundled `cpp`
>> replacement in the GHC distribution in the past? (if it remains a
>> separate executable, its GPL licence shouldn't be an issue -- after all,
>> ghc relies on the gcc executable which is GPL'ed too)
>>
>> cheers,
>>   hvr
>> _______________________________________________
>> 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 marlowsd at gmail.com  Tue Nov  5 08:51:05 2013
From: marlowsd at gmail.com (Simon Marlow)
Date: Tue, 05 Nov 2013 08:51:05 +0000
Subject: Dynamically loading and unloading (C) object files
In-Reply-To: <CAETJ90TwQja_EuLcsqo=20RG-oXV4iGQodb2BDgOVgDMPiD=Lw@mail.gmail.com>
References: <CAETJ90TwQja_EuLcsqo=20RG-oXV4iGQodb2BDgOVgDMPiD=Lw@mail.gmail.com>
Message-ID: <5278B179.1020100@gmail.com>

On 31/10/2013 18:06, Edsko de Vries wrote:
> Hi guys,
>
> We started experimenting with dynamically loading and unloading C
> object files (using the GHC API). I have a simple example with an
> object file exporting a single symbol "f"; I have two versions of the
> object file; in the first one, f is defined
>
> int f() {
>    return 1234;
> }
>
> The second one uses the value "4321" instead. I can dynamically load
> and unload these object files (using "linkObj" and "unlinkObj" from
> "ObjLink"). I can load the first, dynamically compile some Haskell
> code that imports this symbol, then upload this object file and load
> the second, and as long as I make sure that the Haskell code gets
> recompiled (perhaps a relink step suffices, haven't experimented an
> awful lot yet) it can then interact with the second object file.

So you're loading C code using linkObj, and then compiling some Haskell 
code that uses 'foreign import' to reference the C code?  That *should* 
be fine, but it's not a use-case that we have thought about.  I 
certainly wouldn't try to load Haskell code manually while also using 
the GHC API.

The RTS linker isn't thread-safe, so be careful about using the GHC API 
and calling linkObj etc. concurrently.

> All this is good news -- in fact, it is more than we had hoped for,
> because ghci does not allow dynamically unloading or loading any
> object files at all. Object files specified on the command line are
> handled in initDynLinker and the ghci top-level function doesn't even
> get to see them, and we cannot load object files from inside a ghci
> session.

Nobody asked for this, so we never implemented it :-)  It ought to be 
entirely reasonable to extend the GHC API to allow for loading and 
unloading of foreign object files, and to expose that functionality in GHCi.

Cheers,
Simon


> So that leads me to wonder: are there limitations that we should be
> aware of? Have I simply been lucky so far?
>
> Any points or suggestions for things to try would be appreciated,
>
> Edsko
> _______________________________________________
> ghc-devs mailing list
> ghc-devs at haskell.org
> http://www.haskell.org/mailman/listinfo/ghc-devs
>

From simonpj at microsoft.com  Tue Nov  5 09:13:34 2013
From: simonpj at microsoft.com (Simon Peyton-Jones)
Date: Tue, 5 Nov 2013 09:13:34 +0000
Subject: Finding & assembling class dictionaries from GHC plugins?
In-Reply-To: <CAD6SzRJM0B-e_THKMPi7p_Jw56DTzAVMGQdbyo2sg3quVvWuNA@mail.gmail.com>
References: <CAD6SzRJM0B-e_THKMPi7p_Jw56DTzAVMGQdbyo2sg3quVvWuNA@mail.gmail.com>
Message-ID: <59543203684B2244980D7E4057D5FBC148669657@DB3EX14MBXC308.europe.corp.microsoft.com>

I'm not sure what you mean by "synthesise".

Typeable instances can no longer be hand-written; they must be derived by GHC.  That's to keep them type-secure.

A core-level plug-in can't generate fresh instances.  There are some new plug-in hooks that fit earlier in the pipeline, which can.  Maybe you can use that, and generate a data type decl with "deriving Typeable"?

Simon

From: ghc-devs [mailto:ghc-devs-bounces at haskell.org] On Behalf Of Conal Elliott
Sent: 04 November 2013 20:08
To: ghc-devs at haskell.org
Subject: Finding & assembling class dictionaries from GHC plugins?

I'm working on a GHC plugin (for compiling Haskell to hardware), and I need to synthesize Typeable (and maybe other) class dictionaries for a wide range of types, including composite types (functions, pairs, lists, etc). Can it be done, and how? I think I'm mainly looking for mechanics of finding existing class instances (however they're defined) and assembling them (for parametrized/composite dictionaries), rather than mechanisms specific to Typeable.
Thanks, -- Conal
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/ghc-devs/attachments/20131105/7b18ef9f/attachment.html>

From pedro at onimail.net  Tue Nov  5 11:27:08 2013
From: pedro at onimail.net (Pedro Rodrigues)
Date: Tue,  5 Nov 2013 11:27:08 +0000
Subject: [PATCH] Fix typo in User's Guide
Message-ID: <1383650828-26219-1-git-send-email-pedro@onimail.net>

---
 docs/users_guide/glasgow_exts.xml |    2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)

diff --git a/docs/users_guide/glasgow_exts.xml b/docs/users_guide/glasgow_exts.xml
index ce07806..d61ff7a 100644
--- a/docs/users_guide/glasgow_exts.xml
+++ b/docs/users_guide/glasgow_exts.xml
@@ -8673,7 +8673,7 @@ proc (x,y) ->
 which is translated to
 <screen>
 arr (\ (x,y) -> if f x y then Left x else Right y) >>>
-        (arr (\x -> x+1) >>> f) ||| (arr (\y -> y+2) >>> g)
+        (arr (\x -> x+1) >>> g) ||| (arr (\y -> y+2) >>> h)
 </screen>
 Since the translation uses <function>|||</function>,
 the arrow concerned must belong to the <literal>ArrowChoice</literal> class.
-- 
1.7.4.1


From edskodevries at gmail.com  Tue Nov  5 12:10:32 2013
From: edskodevries at gmail.com (Edsko de Vries)
Date: Tue, 5 Nov 2013 12:10:32 +0000
Subject: Dynamically loading and unloading (C) object files
In-Reply-To: <5278B179.1020100@gmail.com>
References: <CAETJ90TwQja_EuLcsqo=20RG-oXV4iGQodb2BDgOVgDMPiD=Lw@mail.gmail.com>
 <5278B179.1020100@gmail.com>
Message-ID: <CAETJ90SO+_RixhW_K7gEYT6D7h=VEOEPb-6wVPQmSseBTtij5A@mail.gmail.com>

Ok, great. We are only loading object files from C code, not Haskell
code -- we use the GHC API for that. And we're not using *anything*
concurrently when it comes to GHC, so that should be okay too. I've
been experimenting more with this and it seems to work okay :)

Will let you know if we come across any problems.

Edsko

On Tue, Nov 5, 2013 at 8:51 AM, Simon Marlow <marlowsd at gmail.com> wrote:
> On 31/10/2013 18:06, Edsko de Vries wrote:
>>
>> Hi guys,
>>
>> We started experimenting with dynamically loading and unloading C
>> object files (using the GHC API). I have a simple example with an
>> object file exporting a single symbol "f"; I have two versions of the
>> object file; in the first one, f is defined
>>
>> int f() {
>>    return 1234;
>> }
>>
>> The second one uses the value "4321" instead. I can dynamically load
>> and unload these object files (using "linkObj" and "unlinkObj" from
>> "ObjLink"). I can load the first, dynamically compile some Haskell
>> code that imports this symbol, then upload this object file and load
>> the second, and as long as I make sure that the Haskell code gets
>> recompiled (perhaps a relink step suffices, haven't experimented an
>> awful lot yet) it can then interact with the second object file.
>
>
> So you're loading C code using linkObj, and then compiling some Haskell code
> that uses 'foreign import' to reference the C code?  That *should* be fine,
> but it's not a use-case that we have thought about.  I certainly wouldn't
> try to load Haskell code manually while also using the GHC API.
>
> The RTS linker isn't thread-safe, so be careful about using the GHC API and
> calling linkObj etc. concurrently.
>
>
>> All this is good news -- in fact, it is more than we had hoped for,
>> because ghci does not allow dynamically unloading or loading any
>> object files at all. Object files specified on the command line are
>> handled in initDynLinker and the ghci top-level function doesn't even
>> get to see them, and we cannot load object files from inside a ghci
>> session.
>
>
> Nobody asked for this, so we never implemented it :-)  It ought to be
> entirely reasonable to extend the GHC API to allow for loading and unloading
> of foreign object files, and to expose that functionality in GHCi.
>
> Cheers,
> Simon
>
>
>> So that leads me to wonder: are there limitations that we should be
>> aware of? Have I simply been lucky so far?
>>
>> Any points or suggestions for things to try would be appreciated,
>>
>> Edsko
>> _______________________________________________
>> ghc-devs mailing list
>> ghc-devs at haskell.org
>> http://www.haskell.org/mailman/listinfo/ghc-devs
>>
>

From nicolas.frisby at gmail.com  Tue Nov  5 14:36:14 2013
From: nicolas.frisby at gmail.com (Nicolas Frisby)
Date: Tue, 5 Nov 2013 08:36:14 -0600
Subject: Finding & assembling class dictionaries from GHC plugins?
In-Reply-To: <59543203684B2244980D7E4057D5FBC148669657@DB3EX14MBXC308.europe.corp.microsoft.com>
References: <CAD6SzRJM0B-e_THKMPi7p_Jw56DTzAVMGQdbyo2sg3quVvWuNA@mail.gmail.com>
 <59543203684B2244980D7E4057D5FBC148669657@DB3EX14MBXC308.europe.corp.microsoft.com>
Message-ID: <CADfHYo4GmvZWpOp4uMJFnauB5iwLNbQwOh7Tifsm9pC3VwpP=w@mail.gmail.com>

On Nov 5, 2013 3:14 AM, "Simon Peyton-Jones" <simonpj at microsoft.com> wrote:

>
> A core-level plug-in can?t generate fresh instances.  There are some new
plug-in hooks that fit earlier in the pipeline, which can.  Maybe you can
use that, and generate a data type decl with ?deriving Typeable??

We're willing to do some awkward shoehorning in HERMIT to make this work in
limited circumstances. (Hopefully including Conal's.)

We just don't know how to start ? ie how call the right functions from the
type checker. Are there any resources explaining the relevant subset of the
TcRnIf API?

Thanks.

>
>
> From: ghc-devs [mailto:ghc-devs-bounces at haskell.org] On Behalf Of Conal
Elliott
> Sent: 04 November 2013 20:08
> To: ghc-devs at haskell.org
> Subject: Finding & assembling class dictionaries from GHC plugins?
>
>
>
> I'm working on a GHC plugin (for compiling Haskell to hardware), and I
need to synthesize Typeable (and maybe other) class dictionaries for a wide
range of types, including composite types (functions, pairs, lists, etc).
Can it be done, and how? I think I'm mainly looking for mechanics of
finding existing class instances (however they're defined) and assembling
them (for parametrized/composite dictionaries), rather than mechanisms
specific to Typeable.
>
> Thanks, -- Conal
>
>
> _______________________________________________
> 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/20131105/32d57d9e/attachment.html>

From simonpj at microsoft.com  Tue Nov  5 15:37:05 2013
From: simonpj at microsoft.com (Simon Peyton-Jones)
Date: Tue, 5 Nov 2013 15:37:05 +0000
Subject: Generics bugs
Message-ID: <59543203684B2244980D7E4057D5FBC148669C4B@DB3EX14MBXC308.europe.corp.microsoft.com>

Pedro, what's the status on
#8479
#8468
#7346
?
Thanks, Simon

Microsoft Research Limited (company number 03369488) is registered in England and Wales
Registered office is at 21 Station Road, Cambridge, CB1 2FB

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

From jpm at cs.uu.nl  Tue Nov  5 15:45:55 2013
From: jpm at cs.uu.nl (=?ISO-8859-1?Q?Jos=E9_Pedro_Magalh=E3es?=)
Date: Tue, 5 Nov 2013 15:45:55 +0000
Subject: Generics bugs
In-Reply-To: <59543203684B2244980D7E4057D5FBC148669C4B@DB3EX14MBXC308.europe.corp.microsoft.com>
References: <59543203684B2244980D7E4057D5FBC148669C4B@DB3EX14MBXC308.europe.corp.microsoft.com>
Message-ID: <CA+ZFbn-urNxyt5XW_ZnUQyNLNM7XzEto2z_4pLhWXkMzuFhSTg@mail.gmail.com>

Hi Simon,


On Tue, Nov 5, 2013 at 3:37 PM, Simon Peyton-Jones <simonpj at microsoft.com>wrote:

>  Pedro, what?s the status on
>
> #8479
>
> #8468
>

I'm discussing how to best handle that with Nick, as he wrote that part of
the code.


>  #7346
>

In principle I support that idea, but you seemed to be more reluctant? I
was hoping perhaps
Andres would try a bit harder to convince you before I jumped on to
implementing it :-)


Pedro


>  ?
>
> Thanks, Simon
>
>
>
> *Microsoft Research Limited (company number 03369488) is registered in
> England and Wales *
>
> *Registered office is at 21 Station Road, Cambridge, CB1 2FB*
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/ghc-devs/attachments/20131105/050a2817/attachment.html>

From carter.schonwald at gmail.com  Tue Nov  5 18:56:23 2013
From: carter.schonwald at gmail.com (Carter Schonwald)
Date: Tue, 5 Nov 2013 13:56:23 -0500
Subject: [PATCH] Fix typo in User's Guide
In-Reply-To: <1383650828-26219-1-git-send-email-pedro@onimail.net>
References: <1383650828-26219-1-git-send-email-pedro@onimail.net>
Message-ID: <CAHYVw0z3g4f_S4eHXYJmFjUM5wZV=5ucY+YasKub2UyRW7xDQA@mail.gmail.com>

could you file a ticket on trac with the patch?


On Tue, Nov 5, 2013 at 6:27 AM, Pedro Rodrigues <pedro at onimail.net> wrote:

> ---
>  docs/users_guide/glasgow_exts.xml |    2 +-
>  1 files changed, 1 insertions(+), 1 deletions(-)
>
> diff --git a/docs/users_guide/glasgow_exts.xml
> b/docs/users_guide/glasgow_exts.xml
> index ce07806..d61ff7a 100644
> --- a/docs/users_guide/glasgow_exts.xml
> +++ b/docs/users_guide/glasgow_exts.xml
> @@ -8673,7 +8673,7 @@ proc (x,y) ->
>  which is translated to
>  <screen>
>  arr (\ (x,y) -> if f x y then Left x else Right y) >>>
> -        (arr (\x -> x+1) >>> f) ||| (arr (\y -> y+2) >>> g)
> +        (arr (\x -> x+1) >>> g) ||| (arr (\y -> y+2) >>> h)
>  </screen>
>  Since the translation uses <function>|||</function>,
>  the arrow concerned must belong to the <literal>ArrowChoice</literal>
> class.
> --
> 1.7.4.1
>
> _______________________________________________
> 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/20131105/ecb29ffd/attachment.html>

From ggreif at gmail.com  Tue Nov  5 21:08:11 2013
From: ggreif at gmail.com (Gabor Greif)
Date: Tue, 5 Nov 2013 22:08:11 +0100
Subject: [commit: packages/integer-gmp] master: Clean-up Cmm of
 import/export primitives (dfd65a2)
In-Reply-To: <20131105205807.024132406B@ghc.haskell.org>
References: <20131105205807.024132406B@ghc.haskell.org>
Message-ID: <CAK-hX0=VFAu5EzNkr-8BdrxJvv4VgOSQc9AKs4tJAfdLmVPuXg@mail.gmail.com>

I suppose the integer-simple library also needs the <new-primops> treatment.
Many embedded platforms won't have GMP.
Should we just provide 'error "unimplemented"' stubs?

Cheers,

    Gabor

On 11/5/13, git at git.haskell.org <git at git.haskell.org> wrote:
> Repository : ssh://git at git.haskell.org/integer-gmp
>
> On branch  : master
> Link       :
> http://git.haskell.org/packages/integer-gmp.git/commitdiff/dfd65a28de3fe6093d7e39fab6de960408abeb7e
>
>>---------------------------------------------------------------
>
> commit dfd65a28de3fe6093d7e39fab6de960408abeb7e
> Author: Herbert Valerio Riedel <hvr at gnu.org>
> Date:   Tue Nov 5 21:26:17 2013 +0100
>
>     Clean-up Cmm of import/export primitives
>
>     This is a follow-up to e94799c9 fixing the Cmm implementation of the
>     primops based on suggestions by Duncan Coutts.
>
>     Signed-off-by: Herbert Valerio Riedel <hvr at gnu.org>
>
>
>>---------------------------------------------------------------
>
> dfd65a28de3fe6093d7e39fab6de960408abeb7e
>  cbits/gmp-wrappers.cmm |   33 +++++++++++++++++----------------
>  1 file changed, 17 insertions(+), 16 deletions(-)
>
> diff --git a/cbits/gmp-wrappers.cmm b/cbits/gmp-wrappers.cmm
> index 186cfad..0da3db8 100644
> --- a/cbits/gmp-wrappers.cmm
> +++ b/cbits/gmp-wrappers.cmm
> @@ -71,47 +71,48 @@ import "integer-gmp" integer_cbits_decodeDouble;
>
>  integer_cmm_importIntegerzh (P_ ba, W_ of, W_ sz, W_ e)
>  {
> -  P_ p;
> -  W_ mp_result1;
> +  W_ src_ptr;
> +  W_ mp_result;
>
>  again:
>    STK_CHK_GEN_N (SIZEOF_MP_INT);
>    MAYBE_GC(again);
>
> -  p = ba + SIZEOF_StgArrWords + of;
> +  mp_result = Sp - SIZEOF_MP_INT;
>
> -  mp_result1 = Sp - SIZEOF_MP_INT;
> +  src_ptr = BYTE_ARR_CTS(ba) + of;
>
> -  ccall __gmpz_init(mp_result1 "ptr");
> -  ccall __gmpz_import(mp_result1 "ptr", sz, W_TO_INT(e), W_TO_INT(1),
> W_TO_INT(0), 0, p "ptr");
> +  ccall __gmpz_init(mp_result "ptr");
> +  ccall __gmpz_import(mp_result "ptr", sz, W_TO_INT(e), W_TO_INT(1),
> W_TO_INT(0), 0, src_ptr "ptr");
>
> -  return(TO_W_(MP_INT__mp_size(mp_result1)),
> -         MP_INT__mp_d(mp_result1) - SIZEOF_StgArrWords);
> +  return(TO_W_(MP_INT__mp_size(mp_result)),
> +         MP_INT__mp_d(mp_result) - SIZEOF_StgArrWords);
>  }
>
> +/* :: Int# -> ByteArray# -> MutableByteArray# s -> Word# -> Int# -> State#
> s -> (# State# s, Word# #) */
>  integer_cmm_exportIntegerzh (W_ s1, P_ d1, P_ mba, W_ of, W_ e)
>  {
> -  P_ dst;
> +  W_ dst_ptr;
>    W_ mp_tmp;
> -  W_ cnt_result1;
> +  W_ cnt_result;
>
>  again:
>    STK_CHK_GEN_N (SIZEOF_MP_INT + SIZEOF_W);
>    MAYBE_GC(again);
>
> -  mp_tmp     = Sp - SIZEOF_MP_INT;
> +  mp_tmp = Sp - SIZEOF_MP_INT;
>    MP_INT__mp_alloc(mp_tmp) = W_TO_INT(BYTE_ARR_WDS(d1));
>    MP_INT__mp_size(mp_tmp)  = (s1);
>    MP_INT__mp_d(mp_tmp)     = BYTE_ARR_CTS(d1);
>
> -  cnt_result1 = Sp - (SIZEOF_MP_INT + SIZEOF_W);
> -  W_[cnt_result1] = 0;
> +  cnt_result = Sp - (SIZEOF_MP_INT + SIZEOF_W);
> +  W_[cnt_result] = 0;
>
> -  dst = mba + SIZEOF_StgArrWords + of;
> +  dst_ptr = BYTE_ARR_CTS(mba) + of;
>
> -  ccall __gmpz_export(dst "ptr", cnt_result1 "ptr", W_TO_INT(e),
> W_TO_INT(1), W_TO_INT(0), 0, mp_tmp "ptr");
> +  ccall __gmpz_export(dst_ptr "ptr", cnt_result "ptr", W_TO_INT(e),
> W_TO_INT(1), W_TO_INT(0), 0, mp_tmp "ptr");
>
> -  return (W_[cnt_result1]);
> +  return (W_[cnt_result]);
>  }
>
>  integer_cmm_int2Integerzh (W_ val)
>
> _______________________________________________
> ghc-commits mailing list
> ghc-commits at haskell.org
> http://www.haskell.org/mailman/listinfo/ghc-commits
>

From conal at conal.net  Tue Nov  5 21:10:54 2013
From: conal at conal.net (Conal Elliott)
Date: Tue, 5 Nov 2013 13:10:54 -0800
Subject: Finding & assembling class dictionaries from GHC plugins?
In-Reply-To: <59543203684B2244980D7E4057D5FBC148669657@DB3EX14MBXC308.europe.corp.microsoft.com>
References: <CAD6SzRJM0B-e_THKMPi7p_Jw56DTzAVMGQdbyo2sg3quVvWuNA@mail.gmail.com>
 <59543203684B2244980D7E4057D5FBC148669657@DB3EX14MBXC308.europe.corp.microsoft.com>
Message-ID: <CAD6SzRL2yUaAmHWpV3LWu8gBf1A1f+KcXDqQHjWVFFEp+x0Juw@mail.gmail.com>

Hi Simon,

I don't think I need to construct dictionaries for new Typeable instances.
I only need to find and assemble *existing* Typeable instances into
combinations like Typeable [(Bool,Int -> String)], and I don't know how to
do so in a GHC plug-in. Pointers greatly appreciated!

-- Conal


On Tue, Nov 5, 2013 at 1:13 AM, Simon Peyton-Jones <simonpj at microsoft.com>wrote:

>  I?m not sure what you mean by ?synthesise?.
>
>
>
> Typeable instances can no longer be hand-written; they must be derived by
> GHC.  That?s to keep them type-secure.
>
>
>
> A core-level plug-in can?t generate fresh instances.  There are some new
> plug-in hooks that fit earlier in the pipeline, which can.  Maybe you can
> use that, and generate a data type decl with ?deriving Typeable??
>
>
> Simon
>
>
>
> *From:* ghc-devs [mailto:ghc-devs-bounces at haskell.org] *On Behalf Of *Conal
> Elliott
> *Sent:* 04 November 2013 20:08
> *To:* ghc-devs at haskell.org
> *Subject:* Finding & assembling class dictionaries from GHC plugins?
>
>
>
> I'm working on a GHC plugin (for compiling Haskell to hardware), and I
> need to synthesize Typeable (and maybe other) class dictionaries for a wide
> range of types, including composite types (functions, pairs, lists, etc).
> Can it be done, and how? I think I'm mainly looking for mechanics of
> finding existing class instances (however they're defined) and assembling
> them (for parametrized/composite dictionaries), rather than mechanisms
> specific to Typeable.
>
> Thanks, -- Conal
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/ghc-devs/attachments/20131105/82850899/attachment.html>

From pedro at onimail.net  Tue Nov  5 21:47:17 2013
From: pedro at onimail.net (Pedro Rodrigues)
Date: Tue, 5 Nov 2013 21:47:17 +0000
Subject: [PATCH] Fix typo in User's Guide
In-Reply-To: <CAHYVw0z3g4f_S4eHXYJmFjUM5wZV=5ucY+YasKub2UyRW7xDQA@mail.gmail.com>
References: <1383650828-26219-1-git-send-email-pedro@onimail.net>
 <CAHYVw0z3g4f_S4eHXYJmFjUM5wZV=5ucY+YasKub2UyRW7xDQA@mail.gmail.com>
Message-ID: <CADtVS2pkWvMCg7VtuRwXqgAyuDzgSbcqune7vH3n59kxq-gTpQ@mail.gmail.com>

Sure, here it is http://ghc.haskell.org/trac/ghc/ticket/8505

Should every bug fix have an associated ticket? Because from the
instructions on
Trac<http://ghc.haskell.org/trac/ghc/wiki/WorkingConventions/FixingBugs>,
I got the impression that for quick fixes it was not necessary to create a
ticket.

Cheers,
Pedro Rodrigues


On 5 November 2013 18:56, Carter Schonwald <carter.schonwald at gmail.com>wrote:

> could you file a ticket on trac with the patch?
>
>
> On Tue, Nov 5, 2013 at 6:27 AM, Pedro Rodrigues <pedro at onimail.net> wrote:
>
>> ---
>>  docs/users_guide/glasgow_exts.xml |    2 +-
>>  1 files changed, 1 insertions(+), 1 deletions(-)
>>
>> diff --git a/docs/users_guide/glasgow_exts.xml
>> b/docs/users_guide/glasgow_exts.xml
>> index ce07806..d61ff7a 100644
>> --- a/docs/users_guide/glasgow_exts.xml
>> +++ b/docs/users_guide/glasgow_exts.xml
>> @@ -8673,7 +8673,7 @@ proc (x,y) ->
>>  which is translated to
>>  <screen>
>>  arr (\ (x,y) -> if f x y then Left x else Right y) >>>
>> -        (arr (\x -> x+1) >>> f) ||| (arr (\y -> y+2) >>> g)
>> +        (arr (\x -> x+1) >>> g) ||| (arr (\y -> y+2) >>> h)
>>  </screen>
>>  Since the translation uses <function>|||</function>,
>>  the arrow concerned must belong to the <literal>ArrowChoice</literal>
>> class.
>> --
>> 1.7.4.1
>>
>> _______________________________________________
>> 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/20131105/5a5cb10c/attachment.html>

From simonpj at microsoft.com  Tue Nov  5 22:04:29 2013
From: simonpj at microsoft.com (Simon Peyton-Jones)
Date: Tue, 5 Nov 2013 22:04:29 +0000
Subject: [PATCH] Fix typo in User's Guide
In-Reply-To: <CADtVS2pkWvMCg7VtuRwXqgAyuDzgSbcqune7vH3n59kxq-gTpQ@mail.gmail.com>
References: <1383650828-26219-1-git-send-email-pedro@onimail.net>
 <CAHYVw0z3g4f_S4eHXYJmFjUM5wZV=5ucY+YasKub2UyRW7xDQA@mail.gmail.com>
 <CADtVS2pkWvMCg7VtuRwXqgAyuDzgSbcqune7vH3n59kxq-gTpQ@mail.gmail.com>
Message-ID: <59543203684B2244980D7E4057D5FBC14866B38D@DB3EX14MBXC308.europe.corp.microsoft.com>

Thanks.  the instructions are really out of date.  Now that so many of us work on GHC, it's too easy for an email to get lost. Trac is better.  I'll update the instructions!

S

From: ghc-devs [mailto:ghc-devs-bounces at haskell.org] On Behalf Of Pedro Rodrigues
Sent: 05 November 2013 21:47
To: Carter Schonwald
Cc: ghc-devs at haskell.org
Subject: Re: [PATCH] Fix typo in User's Guide

Sure, here it is http://ghc.haskell.org/trac/ghc/ticket/8505

Should every bug fix have an associated ticket? Because from the instructions on Trac<http://ghc.haskell.org/trac/ghc/wiki/WorkingConventions/FixingBugs>, I got the impression that for quick fixes it was not necessary to create a ticket.

Cheers,
Pedro Rodrigues

On 5 November 2013 18:56, Carter Schonwald <carter.schonwald at gmail.com<mailto:carter.schonwald at gmail.com>> wrote:
could you file a ticket on trac with the patch?

On Tue, Nov 5, 2013 at 6:27 AM, Pedro Rodrigues <pedro at onimail.net<mailto:pedro at onimail.net>> wrote:
---
 docs/users_guide/glasgow_exts.xml |    2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)

diff --git a/docs/users_guide/glasgow_exts.xml b/docs/users_guide/glasgow_exts.xml
index ce07806..d61ff7a 100644
--- a/docs/users_guide/glasgow_exts.xml
+++ b/docs/users_guide/glasgow_exts.xml
@@ -8673,7 +8673,7 @@ proc (x,y) ->
 which is translated to
 <screen>
 arr (\ (x,y) -> if f x y then Left x else Right y) >>>
-        (arr (\x -> x+1) >>> f) ||| (arr (\y -> y+2) >>> g)
+        (arr (\x -> x+1) >>> g) ||| (arr (\y -> y+2) >>> h)
 </screen>
 Since the translation uses <function>|||</function>,
 the arrow concerned must belong to the <literal>ArrowChoice</literal> class.
--
1.7.4.1

_______________________________________________
ghc-devs mailing list
ghc-devs at haskell.org<mailto: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/20131105/5d2c8689/attachment.html>

From simonpj at microsoft.com  Tue Nov  5 22:32:43 2013
From: simonpj at microsoft.com (Simon Peyton-Jones)
Date: Tue, 5 Nov 2013 22:32:43 +0000
Subject: Generics bugs
In-Reply-To: <CA+ZFbn-urNxyt5XW_ZnUQyNLNM7XzEto2z_4pLhWXkMzuFhSTg@mail.gmail.com>
References: <59543203684B2244980D7E4057D5FBC148669C4B@DB3EX14MBXC308.europe.corp.microsoft.com>
 <CA+ZFbn-urNxyt5XW_ZnUQyNLNM7XzEto2z_4pLhWXkMzuFhSTg@mail.gmail.com>
Message-ID: <59543203684B2244980D7E4057D5FBC14866B3FB@DB3EX14MBXC308.europe.corp.microsoft.com>

In principle I support that idea, but you seemed to be more reluctant? I was hoping perhaps
Andres would try a bit harder to convince you before I jumped on to implementing it :-)

I'm not reluctant. Rather, I just don't know what the idea IS at the moment!  The ticket doesn't provide a spec that is detailed enough for me to understand, nor a single example.  If you (or anyone else) wants to work out the design, give examples etc, I'd be happy to review/comment.
Simon

From: josepedromagalhaes at gmail.com [mailto:josepedromagalhaes at gmail.com] On Behalf Of Jos? Pedro Magalh?es
Sent: 05 November 2013 15:46
To: Simon Peyton-Jones
Cc: ghc-devs at haskell.org
Subject: Re: Generics bugs

Hi Simon,

On Tue, Nov 5, 2013 at 3:37 PM, Simon Peyton-Jones <simonpj at microsoft.com<mailto:simonpj at microsoft.com>> wrote:
Pedro, what's the status on
#8479
#8468

I'm discussing how to best handle that with Nick, as he wrote that part of the code.

#7346

In principle I support that idea, but you seemed to be more reluctant? I was hoping perhaps
Andres would try a bit harder to convince you before I jumped on to implementing it :-)

Pedro

?
Thanks, Simon

Microsoft Research Limited (company number 03369488) is registered in England and Wales
Registered office is at 21 Station Road, Cambridge, CB1 2FB


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

From simonpj at microsoft.com  Tue Nov  5 22:37:18 2013
From: simonpj at microsoft.com (Simon Peyton-Jones)
Date: Tue, 5 Nov 2013 22:37:18 +0000
Subject: Finding & assembling class dictionaries from GHC plugins?
In-Reply-To: <CADfHYo4GmvZWpOp4uMJFnauB5iwLNbQwOh7Tifsm9pC3VwpP=w@mail.gmail.com>
References: <CAD6SzRJM0B-e_THKMPi7p_Jw56DTzAVMGQdbyo2sg3quVvWuNA@mail.gmail.com>
 <59543203684B2244980D7E4057D5FBC148669657@DB3EX14MBXC308.europe.corp.microsoft.com>
 <CADfHYo4GmvZWpOp4uMJFnauB5iwLNbQwOh7Tifsm9pC3VwpP=w@mail.gmail.com>
Message-ID: <59543203684B2244980D7E4057D5FBC14866B421@DB3EX14MBXC308.europe.corp.microsoft.com>

We just don't know how to start - ie how call the right functions from the type checker. Are there any resources explaining the relevant subset of the TcRnIf API?
And I for my part don't know where to start helping you!  Conal wrote

I don't think I need to construct dictionaries for new Typeable instances. I only need to find and assemble *existing* Typeable instances into combinations like Typeable [(Bool,Int -> String)], and I don't know how to do so in a GHC plug-in

That's exactly what the constraint solver does.  (TcSimplify and friends.)  But again I need more context.

I gather you are talking to Pedro too?  He knows a lot about this stuff.

Also there are a bunch of folk (Luite, Edsko) worked on the new front-end plugin stuff, and are much more expert in it than me.

We could have a skype call if that would help

S


From: Nicolas Frisby [mailto:nicolas.frisby at gmail.com]
Sent: 05 November 2013 14:36
To: Simon Peyton-Jones
Cc: ghc-devs at haskell.org; Conal Elliott
Subject: RE: Finding & assembling class dictionaries from GHC plugins?


On Nov 5, 2013 3:14 AM, "Simon Peyton-Jones" <simonpj at microsoft.com<mailto:simonpj at microsoft.com>> wrote:

>
> A core-level plug-in can't generate fresh instances.  There are some new plug-in hooks that fit earlier in the pipeline, which can.  Maybe you can use that, and generate a data type decl with "deriving Typeable"?

We're willing to do some awkward shoehorning in HERMIT to make this work in limited circumstances. (Hopefully including Conal's.)

We just don't know how to start - ie how call the right functions from the type checker. Are there any resources explaining the relevant subset of the TcRnIf API?

Thanks.

>
>
> From: ghc-devs [mailto:ghc-devs-bounces at haskell.org<mailto:ghc-devs-bounces at haskell.org>] On Behalf Of Conal Elliott
> Sent: 04 November 2013 20:08
> To: ghc-devs at haskell.org<mailto:ghc-devs at haskell.org>
> Subject: Finding & assembling class dictionaries from GHC plugins?
>
>
>
> I'm working on a GHC plugin (for compiling Haskell to hardware), and I need to synthesize Typeable (and maybe other) class dictionaries for a wide range of types, including composite types (functions, pairs, lists, etc). Can it be done, and how? I think I'm mainly looking for mechanics of finding existing class instances (however they're defined) and assembling them (for parametrized/composite dictionaries), rather than mechanisms specific to Typeable.
>
> Thanks, -- Conal
>
>
> _______________________________________________
> ghc-devs mailing list
> ghc-devs at haskell.org<mailto: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/20131105/51a4aaa1/attachment.html>

From hvr at gnu.org  Tue Nov  5 22:46:56 2013
From: hvr at gnu.org (Herbert Valerio Riedel)
Date: Tue, 05 Nov 2013 23:46:56 +0100
Subject: [commit: packages/integer-gmp] master: Clean-up Cmm of
 import/export primitives (dfd65a2)
In-Reply-To: <CAK-hX0=VFAu5EzNkr-8BdrxJvv4VgOSQc9AKs4tJAfdLmVPuXg@mail.gmail.com>
 (Gabor Greif's message of "Tue, 5 Nov 2013 22:08:11 +0100")
References: <20131105205807.024132406B@ghc.haskell.org>
 <CAK-hX0=VFAu5EzNkr-8BdrxJvv4VgOSQc9AKs4tJAfdLmVPuXg@mail.gmail.com>
Message-ID: <87li12fov3.fsf@gnu.org>

On 2013-11-05 at 22:08:11 +0100, Gabor Greif wrote:
> I suppose the integer-simple library also needs the <new-primops> treatment.
> Many embedded platforms won't have GMP.
> Should we just provide 'error "unimplemented"' stubs?

Well, I extended the precedent set by

 http://www.haskell.org/ghc/docs/latest/html/libraries/integer-gmp-0.5.0.0/GHC-Integer-GMP-Internals.html

where the underlying `gcdInteger#` and `lcmInteger#` primitives are
provided only by `integer-gmp`, and their wrappers are located in a
module whose name clearly denotes these as being specific to GMP.

This should be regarded as an optimization to tap into GMP's highly
optimized primitives, which afaik can't be easily added outside of
integer-gmp.

However, in the long-term, I don't think packages should build-depend
directly on integer-{gmp,simple} (I was surprised to see that `text`
does this), but instead an `integer` "super-package" could abstract over
the decision whether `integer-gmp` or `integer-simple` is used as
Integer "backend" library, and pass-thru a common set of functions,
while enforcing that no function is missing and/or has a diverging
type.

Cheers,
  hvr

From nicolas.frisby at gmail.com  Tue Nov  5 23:06:59 2013
From: nicolas.frisby at gmail.com (Nicolas Frisby)
Date: Tue, 5 Nov 2013 17:06:59 -0600
Subject: Finding & assembling class dictionaries from GHC plugins?
In-Reply-To: <59543203684B2244980D7E4057D5FBC14866B421@DB3EX14MBXC308.europe.corp.microsoft.com>
References: <CAD6SzRJM0B-e_THKMPi7p_Jw56DTzAVMGQdbyo2sg3quVvWuNA@mail.gmail.com>
 <59543203684B2244980D7E4057D5FBC148669657@DB3EX14MBXC308.europe.corp.microsoft.com>
 <CADfHYo4GmvZWpOp4uMJFnauB5iwLNbQwOh7Tifsm9pC3VwpP=w@mail.gmail.com>
 <59543203684B2244980D7E4057D5FBC14866B421@DB3EX14MBXC308.europe.corp.microsoft.com>
Message-ID: <CADfHYo7wmx9+t3VGmiAh4qP14TgjNGxLmGF-aQmjN=gmjn4qJQ@mail.gmail.com>

On Tue, Nov 5, 2013 at 4:37 PM, Simon Peyton-Jones <simonpj at microsoft.com>wrote:

>
> And I for my part don?t know where to start helping you!  Conal wrote
>

Ha! Fair enough.


>
>
> I don't think I need to construct dictionaries for new Typeable instances.
> I only need to find and assemble *existing* Typeable instances into
> combinations like Typeable [(Bool,Int -> String)], and I don't know how to
> do so in a GHC plug-in
>
>
>
> That?s exactly what the constraint solver does.  (TcSimplify and
> friends.)  But again I need more context.
>
>
Even "TcSimplify and friends" gives me something new-to-my-brain to dig
around with; I'm new to this part of the compiler.

I'll defer to Conal to more fully characterize his needs for you. My role
in this specific project is to distill his and your eventual conclusion
into a HERMIT module that Conal and others can use in the future.

However, I will include my own estimation of the challenge ? it's a
question I've wondered before. "Given a list of non-top-level dictionary
bindings and a constraint type, construct a Core term inhabiting that
constraint type that can also use any top-level dictionaries in scope." How
do I do that using the functions in the module in the compiler/typechecker
directory?

I think a wiki page for this would be great. Maybe one even already exists!

(I have some unshared scaffolding for being able to run TcRn monads from a
Core plugin.)

 We could have a skype call if that would help
>
>
Thanks for putting that on the table. I'll certainly need to do some more
research before taking up a chunk of your time, but it will be very helpful
when it happens.


>
>
>
> *From:* Nicolas Frisby [mailto:nicolas.frisby at gmail.com]
> *Sent:* 05 November 2013 14:36
> *To:* Simon Peyton-Jones
> *Cc:* ghc-devs at haskell.org; Conal Elliott
> *Subject:* RE: Finding & assembling class dictionaries from GHC plugins?
>
>
>
> On Nov 5, 2013 3:14 AM, "Simon Peyton-Jones" <simonpj at microsoft.com>
> wrote:
>
> >
> > A core-level plug-in can?t generate fresh instances.  There are some new
> plug-in hooks that fit earlier in the pipeline, which can.  Maybe you can
> use that, and generate a data type decl with ?deriving Typeable??
>
> We're willing to do some awkward shoehorning in HERMIT to make this work
> in limited circumstances. (Hopefully including Conal's.)
>
> We just don't know how to start ? ie how call the right functions from the
> type checker. Are there any resources explaining the relevant subset of the
> TcRnIf API?
>
> Thanks.
>
> >
> >
> > From: ghc-devs [mailto:ghc-devs-bounces at haskell.org] On Behalf Of Conal
> Elliott
> > Sent: 04 November 2013 20:08
> > To: ghc-devs at haskell.org
> > Subject: Finding & assembling class dictionaries from GHC plugins?
> >
> >
> >
> > I'm working on a GHC plugin (for compiling Haskell to hardware), and I
> need to synthesize Typeable (and maybe other) class dictionaries for a wide
> range of types, including composite types (functions, pairs, lists, etc).
> Can it be done, and how? I think I'm mainly looking for mechanics of
> finding existing class instances (however they're defined) and assembling
> them (for parametrized/composite dictionaries), rather than mechanisms
> specific to Typeable.
> >
> > Thanks, -- Conal
> >
> >
> > _______________________________________________
> > 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/20131105/f7895860/attachment-0001.html>

From conal at conal.net  Tue Nov  5 23:41:25 2013
From: conal at conal.net (Conal Elliott)
Date: Tue, 5 Nov 2013 15:41:25 -0800
Subject: Finding & assembling class dictionaries from GHC plugins?
In-Reply-To: <59543203684B2244980D7E4057D5FBC14866B421@DB3EX14MBXC308.europe.corp.microsoft.com>
References: <CAD6SzRJM0B-e_THKMPi7p_Jw56DTzAVMGQdbyo2sg3quVvWuNA@mail.gmail.com>
 <59543203684B2244980D7E4057D5FBC148669657@DB3EX14MBXC308.europe.corp.microsoft.com>
 <CADfHYo4GmvZWpOp4uMJFnauB5iwLNbQwOh7Tifsm9pC3VwpP=w@mail.gmail.com>
 <59543203684B2244980D7E4057D5FBC14866B421@DB3EX14MBXC308.europe.corp.microsoft.com>
Message-ID: <CAD6SzRJt+q+SWJQFEguBaXkMM4N3i-jaWrzfJw7NFFFcXCscQg@mail.gmail.com>

Hi Simon,

Here's some context on what I'm after. I'll try to include enough to
clarify what I'm after, without dragging you into unnecessary detail.

I have a Core expression, which I'm systematically translating to a related
Core expression. The second one reifies the first one, so that the
generated code *evaluates* to a run-time (not compile/Core-time)
representation akin to the original Core expression. In this second
(reified) representation, I need some run-time representation of types. I
use Typeable constraints in my representation, and these constraints don't
appear in the original Core representation. For instance, I have the
following constructor for function application in a GADT of lambda
expressions:

> (:^) :: (Typeable a, Typeable b) => E (a -> b) -> E a -> E b

My reification plugin takes a Core application expression, recursively
reifies the function and argument expressions, and makes an expression that
applies (:^) to the two recursive results. However--and the point of this
thread--I also need to come up with Core expressions for the two Typeable
dictionaries.

So, to clarify my request, given a Core type representation t, I want to
construct a Core expression that evaluates to the dictionary for Typeable t
if one exists, or fail if there isn't one. Note that t is not necessarily
an atomic type; it could instead be something like [(Bool,Int -> String)].

I'm happy to Skype-chat if it'd help.

Thanks,  - Conal



On Tue, Nov 5, 2013 at 2:37 PM, Simon Peyton-Jones <simonpj at microsoft.com>wrote:

>  We just don't know how to start ? ie how call the right functions from
> the type checker. Are there any resources explaining the relevant subset of
> the TcRnIf API?
>
> And I for my part don?t know where to start helping you!  Conal wrote
>
>
>
> I don't think I need to construct dictionaries for new Typeable instances.
> I only need to find and assemble *existing* Typeable instances into
> combinations like Typeable [(Bool,Int -> String)], and I don't know how to
> do so in a GHC plug-in
>
>
>
> That?s exactly what the constraint solver does.  (TcSimplify and
> friends.)  But again I need more context.
>
>
>
> I gather you are talking to Pedro too?  He knows a lot about this stuff.
>
>
>
> Also there are a bunch of folk (Luite, Edsko) worked on the new front-end
> plugin stuff, and are much more expert in it than me.
>
>
>
> We could have a skype call if that would help
>
>
>
> S
>
>
>
>
>
> *From:* Nicolas Frisby [mailto:nicolas.frisby at gmail.com]
> *Sent:* 05 November 2013 14:36
> *To:* Simon Peyton-Jones
> *Cc:* ghc-devs at haskell.org; Conal Elliott
> *Subject:* RE: Finding & assembling class dictionaries from GHC plugins?
>
>
>
> On Nov 5, 2013 3:14 AM, "Simon Peyton-Jones" <simonpj at microsoft.com>
> wrote:
>
> >
> > A core-level plug-in can?t generate fresh instances.  There are some new
> plug-in hooks that fit earlier in the pipeline, which can.  Maybe you can
> use that, and generate a data type decl with ?deriving Typeable??
>
> We're willing to do some awkward shoehorning in HERMIT to make this work
> in limited circumstances. (Hopefully including Conal's.)
>
> We just don't know how to start ? ie how call the right functions from the
> type checker. Are there any resources explaining the relevant subset of the
> TcRnIf API?
>
> Thanks.
>
> >
> >
> > From: ghc-devs [mailto:ghc-devs-bounces at haskell.org] On Behalf Of Conal
> Elliott
> > Sent: 04 November 2013 20:08
> > To: ghc-devs at haskell.org
> > Subject: Finding & assembling class dictionaries from GHC plugins?
> >
> >
> >
> > I'm working on a GHC plugin (for compiling Haskell to hardware), and I
> need to synthesize Typeable (and maybe other) class dictionaries for a wide
> range of types, including composite types (functions, pairs, lists, etc).
> Can it be done, and how? I think I'm mainly looking for mechanics of
> finding existing class instances (however they're defined) and assembling
> them (for parametrized/composite dictionaries), rather than mechanisms
> specific to Typeable.
> >
> > Thanks, -- Conal
> >
> >
> > _______________________________________________
> > 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/20131105/6c4f8184/attachment.html>

From ggreif at gmail.com  Tue Nov  5 23:49:37 2013
From: ggreif at gmail.com (Gabor Greif)
Date: Wed, 6 Nov 2013 00:49:37 +0100
Subject: [commit: packages/integer-gmp] master: Clean-up Cmm of
 import/export primitives (dfd65a2)
In-Reply-To: <87li12fov3.fsf@gnu.org>
References: <20131105205807.024132406B@ghc.haskell.org>
 <CAK-hX0=VFAu5EzNkr-8BdrxJvv4VgOSQc9AKs4tJAfdLmVPuXg@mail.gmail.com>
 <87li12fov3.fsf@gnu.org>
Message-ID: <CAK-hX0kraQD_QoX66BoXKj6HV=JV1MZXvh++bOOHo_ffjqQvoQ@mail.gmail.com>

On 11/5/13, Herbert Valerio Riedel <hvr at gnu.org> wrote:
> On 2013-11-05 at 22:08:11 +0100, Gabor Greif wrote:
>> I suppose the integer-simple library also needs the <new-primops>
>> treatment.
>> Many embedded platforms won't have GMP.
>> Should we just provide 'error "unimplemented"' stubs?
>
> Well, I extended the precedent set by
>
> http://www.haskell.org/ghc/docs/latest/html/libraries/integer-gmp-0.5.0.0/GHC-Integer-GMP-Internals.html

Oh, I see. I'll shut up now :-)

    Gabor
>
> where the underlying `gcdInteger#` and `lcmInteger#` primitives are
> provided only by `integer-gmp`, and their wrappers are located in a
> module whose name clearly denotes these as being specific to GMP.
>
> This should be regarded as an optimization to tap into GMP's highly
> optimized primitives, which afaik can't be easily added outside of
> integer-gmp.
>
> However, in the long-term, I don't think packages should build-depend
> directly on integer-{gmp,simple} (I was surprised to see that `text`
> does this), but instead an `integer` "super-package" could abstract over
> the decision whether `integer-gmp` or `integer-simple` is used as
> Integer "backend" library, and pass-thru a common set of functions,
> while enforcing that no function is missing and/or has a diverging
> type.
>
> Cheers,
>   hvr
>

From simonpj at microsoft.com  Wed Nov  6 10:55:09 2013
From: simonpj at microsoft.com (Simon Peyton-Jones)
Date: Wed, 6 Nov 2013 10:55:09 +0000
Subject: Annotations
Message-ID: <59543203684B2244980D7E4057D5FBC14866C163@DB3EX14MBXC308.europe.corp.microsoft.com>

I've just noticed that there is no GHC language extension for annotations
http://www.haskell.org/ghc/docs/latest/html/users_guide/extending-ghc.html#annotation-pragmas
That feels like an oversight. Yes, they are in a pragma, but you may get an error message if you compile with a stage-1 compiler, for example.  Plus, the language extensions should truthfully report what extra stuff you are using.

I'm inclined to add a language extension "Annotations".

*         Without it {-# ANN ... #-} pragmas are ignored as comments

*         With it, they are treated as annotations
Do you agree?
I don't know whether this can (or even should) land in 7.8.1.  Do you care either way?
Guidance welcome
Simon

Microsoft Research Limited (company number 03369488) is registered in England and Wales
Registered office is at 21 Station Road, Cambridge, CB1 2FB

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

From johan.tibell at gmail.com  Wed Nov  6 11:01:07 2013
From: johan.tibell at gmail.com (Johan Tibell)
Date: Wed, 6 Nov 2013 12:01:07 +0100
Subject: Annotations
In-Reply-To: <59543203684B2244980D7E4057D5FBC14866C163@DB3EX14MBXC308.europe.corp.microsoft.com>
References: <59543203684B2244980D7E4057D5FBC14866C163@DB3EX14MBXC308.europe.corp.microsoft.com>
Message-ID: <CAK-tuPbGUHmXWECQXDMWd-NSzPu5nat19tQ-p0N4tiu8swkF-g@mail.gmail.com>

I agree. I would like a warning if I use {-# ANN ... #-} without the
language pragma. I clearly meant to write an annotation!


On Wed, Nov 6, 2013 at 11:55 AM, Simon Peyton-Jones
<simonpj at microsoft.com>wrote:

>  I?ve just noticed that there is no GHC language extension for annotations
>
>
> http://www.haskell.org/ghc/docs/latest/html/users_guide/extending-ghc.html#annotation-pragmas
>
> That feels like an oversight. Yes, they are in a pragma, but you may get
> an error message if you compile with a stage-1 compiler, for example.
> Plus, the language extensions should truthfully report what extra stuff you
> are using.
>
>
>
> I?m inclined to add a language extension ?Annotations?.
>
> ?         Without it {-# ANN ? #-} pragmas are ignored as comments
>
> ?         With it, they are treated as annotations
>
> Do you agree?
>
> I don?t know whether this can (or even should) land in 7.8.1.  Do you care
> either way?
>
> Guidance welcome
>
> Simon
>
>
>
> *Microsoft Research Limited (company number 03369488) is registered in
> England and Wales *
>
> *Registered office is at 21 Station Road, Cambridge, CB1 2FB*
>
>
>
> _______________________________________________
> 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/20131106/739adab3/attachment-0001.html>

From gergely at risko.hu  Wed Nov  6 11:57:14 2013
From: gergely at risko.hu (Gergely Risko)
Date: Wed, 06 Nov 2013 12:57:14 +0100
Subject: Annotations
References: <59543203684B2244980D7E4057D5FBC14866C163@DB3EX14MBXC308.europe.corp.microsoft.com>
Message-ID: <87vc05hhet.fsf@gergely.risko.hu>

On Wed, 6 Nov 2013 10:55:09 +0000, Simon Peyton-Jones <simonpj at microsoft.com> writes:

> I?m inclined to add a language extension ?Annotations?. 
>
> ? Without it {-# ANN ? #-} pragmas are ignored as comments
>
> ? With it, they are treated as annotations
>
> Do you agree?

I generally agree that this should be a language extension.

My only worry is around the just implemented TH additions regarding
annotations.  I don't clearly see what would happen if:
  - a TH library exports a function that generates annotations when spliced.
  - and the user uses this function in a .hs file,
  - without specifying the language extension.

I'd it to work even in that case.

I guess the behavior in this corner case depends heavily on how this is
actually implemented.  If e.g. the reader is the only component that
checks if the language extension is turned on, then I imagine that the
TH way of putting in the annotation into the AST would just work.

On the other hand if the reader recognizes the annotations either way
and some component after TH splicing is checking for the language
extension, then my use-case would blow up.

TH currently is lenient in cases like this.  E.g. if you know that a
Name is exported from a module and you reference it directly, without
importing it everything will just work.  I'd like to have the same
behavior for annotations.

Thanks,
Gergely


From simonpj at microsoft.com  Wed Nov  6 12:06:04 2013
From: simonpj at microsoft.com (Simon Peyton-Jones)
Date: Wed, 6 Nov 2013 12:06:04 +0000
Subject: Annotations
In-Reply-To: <87vc05hhet.fsf@gergely.risko.hu>
References: <59543203684B2244980D7E4057D5FBC14866C163@DB3EX14MBXC308.europe.corp.microsoft.com>
 <87vc05hhet.fsf@gergely.risko.hu>
Message-ID: <59543203684B2244980D7E4057D5FBC14866C32F@DB3EX14MBXC308.europe.corp.microsoft.com>

| My only worry is around the just implemented TH additions regarding
| annotations.  I don't clearly see what would happen if:
|   - a TH library exports a function that generates annotations when
| spliced.	
|   - and the user uses this function in a .hs file,
|   - without specifying the language extension.

But this is true for ANY language extension. If a TH library exports a function that generates (say) a type family declaration, and you splice that into a file, do you need -XTypeFamilies in the client file?   I think currently you do.  

So your point is a good one but it's orthogonal.

Simon

| -----Original Message-----
| From: ghc-devs [mailto:ghc-devs-bounces at haskell.org] On Behalf Of
| Gergely Risko
| Sent: 06 November 2013 11:57
| To: ghc-devs at haskell.org
| Cc: glasgow-haskell-users at haskell.org
| Subject: Re: Annotations
| 
| On Wed, 6 Nov 2013 10:55:09 +0000, Simon Peyton-Jones
| <simonpj at microsoft.com> writes:
| 
| > I?m inclined to add a language extension ?Annotations?.
| >
| > ? Without it {-# ANN ? #-} pragmas are ignored as comments
| >
| > ? With it, they are treated as annotations
| >
| > Do you agree?
| 
| I generally agree that this should be a language extension.
| 
| My only worry is around the just implemented TH additions regarding
| annotations.  I don't clearly see what would happen if:
|   - a TH library exports a function that generates annotations when
| spliced.	
|   - and the user uses this function in a .hs file,
|   - without specifying the language extension.
| 
| I'd it to work even in that case.
| 
| I guess the behavior in this corner case depends heavily on how this is
| actually implemented.  If e.g. the reader is the only component that
| checks if the language extension is turned on, then I imagine that the
| TH way of putting in the annotation into the AST would just work.
| 
| On the other hand if the reader recognizes the annotations either way
| and some component after TH splicing is checking for the language
| extension, then my use-case would blow up.
| 
| TH currently is lenient in cases like this.  E.g. if you know that a
| Name is exported from a module and you reference it directly, without
| importing it everything will just work.  I'd like to have the same
| behavior for annotations.
| 
| Thanks,
| Gergely
| 
| _______________________________________________
| ghc-devs mailing list
| ghc-devs at haskell.org
| http://www.haskell.org/mailman/listinfo/ghc-devs

From gergely at risko.hu  Wed Nov  6 12:42:00 2013
From: gergely at risko.hu (Gergely Risko)
Date: Wed, 06 Nov 2013 13:42:00 +0100
Subject: Annotations
References: <59543203684B2244980D7E4057D5FBC14866C163@DB3EX14MBXC308.europe.corp.microsoft.com>
Message-ID: <87k3glhfc7.fsf@gergely.risko.hu>

On Wed, 6 Nov 2013 10:55:09 +0000, Simon Peyton-Jones <simonpj at microsoft.com> writes:

> I?ve just noticed that there is no GHC language extension for
> annotations
>
> http://www.haskell.org/ghc/docs/latest/html/users_guide/extending-ghc.html#annotation-
> pragmas
>
> That feels like an oversight. Yes, they are in a pragma, but you may
> get an error message if you compile with a stage-1 compiler, for
> example. Plus, the language extensions should truthfully report what
> extra stuff you are using.

And are you more inclined because of the stage-1 incompatibility or
because of the second reason: "the language extensions should truthfully
report what extra stuff you are using".

Because in the second case, then maybe we should do the same for:
  - inlining,
  - SPECIALIZE,
  - unpacking,
  - rules.

All of these also have TH implementation, so the same kind of issue
would arise for them.

I agree that my issue is orthogonal, but I still see it as important.
For example when generating small boilerplate functions via TH, then you
almost always want to add the INLINE pragma without bothering the user.

I'd vote for doing this (even only for annotations, if you only want
that).  But would really like to handle the TH issue at the same time.

About MultiParamTypeClasses, I think you're correct.  But I'm not so
sure that this is general for ALL the language pragmas, I'll try them
out and report back if I find further inconsistencies.

Gergely


From ekmett at gmail.com  Wed Nov  6 12:48:01 2013
From: ekmett at gmail.com (Edward A Kmett)
Date: Wed, 6 Nov 2013 07:48:01 -0500
Subject: Annotations
In-Reply-To: <87vc05hhet.fsf@gergely.risko.hu>
References: <59543203684B2244980D7E4057D5FBC14866C163@DB3EX14MBXC308.europe.corp.microsoft.com>
 <87vc05hhet.fsf@gergely.risko.hu>
Message-ID: <32CC779B-7964-4F26-BA81-EB40CD28FCDB@gmail.com>

Currently, in all the cases I can think of if the splice generates something that uses an extension then the module must have that flag turned on.

Sent from my iPhone

> On Nov 6, 2013, at 6:57 AM, Gergely Risko <gergely at risko.hu> wrote:
> 
> On Wed, 6 Nov 2013 10:55:09 +0000, Simon Peyton-Jones <simonpj at microsoft.com> writes:
> 
>> I?m inclined to add a language extension ?Annotations?. 
>> 
>> ? Without it {-# ANN ? #-} pragmas are ignored as comments
>> 
>> ? With it, they are treated as annotations
>> 
>> Do you agree?
> 
> I generally agree that this should be a language extension.
> 
> My only worry is around the just implemented TH additions regarding
> annotations.  I don't clearly see what would happen if:
>  - a TH library exports a function that generates annotations when spliced.
>  - and the user uses this function in a .hs file,
>  - without specifying the language extension.
> 
> I'd it to work even in that case.
> 
> I guess the behavior in this corner case depends heavily on how this is
> actually implemented.  If e.g. the reader is the only component that
> checks if the language extension is turned on, then I imagine that the
> TH way of putting in the annotation into the AST would just work.
> 
> On the other hand if the reader recognizes the annotations either way
> and some component after TH splicing is checking for the language
> extension, then my use-case would blow up.
> 
> TH currently is lenient in cases like this.  E.g. if you know that a
> Name is exported from a module and you reference it directly, without
> importing it everything will just work.  I'd like to have the same
> behavior for annotations.
> 
> Thanks,
> Gergely
> 
> _______________________________________________
> ghc-devs mailing list
> ghc-devs at haskell.org
> http://www.haskell.org/mailman/listinfo/ghc-devs

From simonpj at microsoft.com  Wed Nov  6 13:43:02 2013
From: simonpj at microsoft.com (Simon Peyton-Jones)
Date: Wed, 6 Nov 2013 13:43:02 +0000
Subject: Template Haskell and stage-1
Message-ID: <59543203684B2244980D7E4057D5FBC14866C489@DB3EX14MBXC308.europe.corp.microsoft.com>

I'd like to make -XtemplateHaskell simply illegal in a stage-1 compiler. After all, it is!
But for some reason we use the stage1 compiler to generate dependencies for the DPH libraries; those libraries have {-# LANGUAGE TemplateHaskell #-}, so the dependency generation fails.  See below.
But WHY do we generate deps for DPH with stage1?  We don't *compile* the DPH libraries with stage1, because they need TH.  Can't we just generate deps with stage2?
For now I'll make it a warning, but could someone fix the build system?
Thanks
Simon



mv libraries/dph/dph-lifted-copy/dist-install/build/.depend-v-dyn.c_asm.tmp libraries/dph/dph-lifted-copy/dist-install/build/.depend-v-dyn.c_asm
"rm" -f libraries/dph/dph-lifted-copy/dist-install/build/.depend-v-dyn.haskell.tmp
"inplace/bin/ghc-stage1" -M -static  -H32m -O -Werror -Wall -H64m -O0    -package-name dph-lifted-copy-0.8.0.1 -hide-all-packages -i -ilibraries/dph/dph-lifted-copy/. -ilibraries/dph/dph-lifted-copy/dist-install/build -ilibraries/dph/dph-lifted-copy/dist-install/build/autogen -Ilibraries/dph/dph-lifted-copy/dist-install/build -Ilibraries/dph/dph-lifted-copy/dist-install/build/autogen -Ilibraries/dph/dph-lifted-copy/.    -optP-include -optPlibraries/dph/dph-lifted-copy/dist-install/build/autogen/cabal_macros.h -package array-0.5.0.0 -package base-4.7.0.0 -package dph-base-0.8.0.1 -package dph-prim-par-0.8.0.1 -package ghc-7.7.20131106 -package random-1.0.1.1 -package template-haskell-2.9.0.0 -package vector-0.10.9.1 -Odph -funbox-strict-fields -fcpr-off -fno-warn-orphans -fno-warn-missing-signatures -XHaskell98 -XTypeFamilies -XGADTs -XRankNTypes -XBangPatterns -XMagicHash -XUnboxedTuples -XTypeOperators -O2 -O -dcore-lint -fno-warn-amp  -fno-warn-deprecated-flags -Wwarn  -no-user-package-db -rtsopts      -odir libraries/dph/dph-lifted-copy/dist-install/build -hidir libraries/dph/dph-lifted-copy/dist-install/build -stubdir libraries/dph/dph-lifted-copy/dist-install/build -dep-makefile libraries/dph/dph-lifted-copy/dist-install/build/.depend-v-dyn.haskell.tmp -dep-suffix "" -dep-suffix "dyn_" -include-pkg-deps  libraries/dph/dph-lifted-copy/./Data/Array/Parallel.hs  libraries/dph/dph-lifted-copy/./Data/Array/Parallel/Lifted.hs  libraries/dph/dph-lifted-copy/./Data/Array/Parallel/Lifted/Closure.hs  libraries/dph/dph-lifted-copy/./Data/Array/Parallel/Lifted/Combinators.hs  libraries/dph/dph-lifted-copy/./Data/Array/Parallel/Lifted/PArray.hs  libraries/dph/dph-lifted-copy/./Data/Array/Parallel/Lifted/Scalar.hs  libraries/dph/dph-lifted-copy/./Data/Array/Parallel/Lifted/TH/Repr.hs  libraries/dph/dph-lifted-copy/./Data/Array/Parallel/Lifted/Unboxed.hs  libraries/dph/dph-lifted-copy/./Data/Array/Parallel/PArr.hs  libraries/dph/dph-lifted-copy/./Data/Array/Parallel/PArray.hs  libraries/dph/dph-lifted-copy/./Data/Array/Parallel/PArray/Base.hs  libraries/dph/dph-lifted-copy/./Data/Array/Parallel/PArray/PData.hs  libraries/dph/dph-lifted-copy/./Data/Array/Parallel/PArray/PDataInstances.hs  libraries/dph/dph-lifted-copy/./Data/Array/Parallel/PArray/PRepr.hs  libraries/dph/dph-lifted-copy/./Data/Array/Parallel/PArray/PReprInstances.hs  libraries/dph/dph-lifted-copy/./Data/Array/Parallel/PArray/Scalar.hs  libraries/dph/dph-lifted-copy/./Data/Array/Parallel/PArray/ScalarInstances.hs  libraries/dph/dph-lifted-copy/./Data/Array/Parallel/PArray/Types.hs  libraries/dph/dph-lifted-copy/./Data/Array/Parallel/Prelude.hs  libraries/dph/dph-lifted-copy/./Data/Array/Parallel/Prelude/Base.hs  libraries/dph/dph-lifted-copy/./Data/Array/Parallel/Prelude/Bool.hs  libraries/dph/dph-lifted-copy/./Data/Array/Parallel/Prelude/Double.hs  libraries/dph/dph-lifted-copy/./Data/Array/Parallel/Prelude/Float.hs  libraries/dph/dph-lifted-copy/./Data/Array/Parallel/Prelude/Int.hs  libraries/dph/dph-lifted-copy/./Data/Array/Parallel/Prelude/Tuple.hs  libraries/dph/dph-lifted-copy/./Data/Array/Parallel/Prelude/Word8.hs  libraries/dph/dph-lifted-copy/./Data/Array/Parallel/Prim.hs
ghc-stage1: libraries/dph/dph-lifted-copy/Data/Array/Parallel/Lifted/TH/Repr.hs:1:14-28: Template Haskell requires GHC with interpreter support
Perhaps you are using a stage-1 compiler?
Microsoft Research Limited (company number 03369488) is registered in England and Wales
Registered office is at 21 Station Road, Cambridge, CB1 2FB

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

From simonpj at microsoft.com  Wed Nov  6 13:59:15 2013
From: simonpj at microsoft.com (Simon Peyton-Jones)
Date: Wed, 6 Nov 2013 13:59:15 +0000
Subject: Finding & assembling class dictionaries from GHC plugins?
In-Reply-To: <CAD6SzRJt+q+SWJQFEguBaXkMM4N3i-jaWrzfJw7NFFFcXCscQg@mail.gmail.com>
References: <CAD6SzRJM0B-e_THKMPi7p_Jw56DTzAVMGQdbyo2sg3quVvWuNA@mail.gmail.com>
 <59543203684B2244980D7E4057D5FBC148669657@DB3EX14MBXC308.europe.corp.microsoft.com>
 <CADfHYo4GmvZWpOp4uMJFnauB5iwLNbQwOh7Tifsm9pC3VwpP=w@mail.gmail.com>
 <59543203684B2244980D7E4057D5FBC14866B421@DB3EX14MBXC308.europe.corp.microsoft.com>
 <CAD6SzRJt+q+SWJQFEguBaXkMM4N3i-jaWrzfJw7NFFFcXCscQg@mail.gmail.com>
Message-ID: <59543203684B2244980D7E4057D5FBC14866C4F1@DB3EX14MBXC308.europe.corp.microsoft.com>

Hmm. One route would be to build a HsExpr (rather than a CoreExpr) for the reification of your CoreExpr, and stick that into the maw of the type checker.  That would hand off all this dictionary construction to the type checker, which is designed for the purpose.

Simon

From: conal.elliott at gmail.com [mailto:conal.elliott at gmail.com] On Behalf Of Conal Elliott
Sent: 05 November 2013 23:41
To: Simon Peyton-Jones
Cc: Nicolas Frisby; ghc-devs at haskell.org
Subject: Re: Finding & assembling class dictionaries from GHC plugins?

Hi Simon,

Here's some context on what I'm after. I'll try to include enough to clarify what I'm after, without dragging you into unnecessary detail.

I have a Core expression, which I'm systematically translating to a related Core expression. The second one reifies the first one, so that the generated code *evaluates* to a run-time (not compile/Core-time) representation akin to the original Core expression. In this second (reified) representation, I need some run-time representation of types. I use Typeable constraints in my representation, and these constraints don't appear in the original Core representation. For instance, I have the following constructor for function application in a GADT of lambda expressions:

> (:^) :: (Typeable a, Typeable b) => E (a -> b) -> E a -> E b

My reification plugin takes a Core application expression, recursively reifies the function and argument expressions, and makes an expression that applies (:^) to the two recursive results. However--and the point of this thread--I also need to come up with Core expressions for the two Typeable dictionaries.

So, to clarify my request, given a Core type representation t, I want to construct a Core expression that evaluates to the dictionary for Typeable t if one exists, or fail if there isn't one. Note that t is not necessarily an atomic type; it could instead be something like [(Bool,Int -> String)].
I'm happy to Skype-chat if it'd help.
Thanks,  - Conal


On Tue, Nov 5, 2013 at 2:37 PM, Simon Peyton-Jones <simonpj at microsoft.com<mailto:simonpj at microsoft.com>> wrote:

We just don't know how to start - ie how call the right functions from the type checker. Are there any resources explaining the relevant subset of the TcRnIf API?
And I for my part don't know where to start helping you!  Conal wrote

I don't think I need to construct dictionaries for new Typeable instances. I only need to find and assemble *existing* Typeable instances into combinations like Typeable [(Bool,Int -> String)], and I don't know how to do so in a GHC plug-in

That's exactly what the constraint solver does.  (TcSimplify and friends.)  But again I need more context.

I gather you are talking to Pedro too?  He knows a lot about this stuff.

Also there are a bunch of folk (Luite, Edsko) worked on the new front-end plugin stuff, and are much more expert in it than me.

We could have a skype call if that would help

S


From: Nicolas Frisby [mailto:nicolas.frisby at gmail.com<mailto:nicolas.frisby at gmail.com>]
Sent: 05 November 2013 14:36
To: Simon Peyton-Jones
Cc: ghc-devs at haskell.org<mailto:ghc-devs at haskell.org>; Conal Elliott
Subject: RE: Finding & assembling class dictionaries from GHC plugins?


On Nov 5, 2013 3:14 AM, "Simon Peyton-Jones" <simonpj at microsoft.com<mailto:simonpj at microsoft.com>> wrote:

>
> A core-level plug-in can't generate fresh instances.  There are some new plug-in hooks that fit earlier in the pipeline, which can.  Maybe you can use that, and generate a data type decl with "deriving Typeable"?

We're willing to do some awkward shoehorning in HERMIT to make this work in limited circumstances. (Hopefully including Conal's.)

We just don't know how to start - ie how call the right functions from the type checker. Are there any resources explaining the relevant subset of the TcRnIf API?

Thanks.

>
>
> From: ghc-devs [mailto:ghc-devs-bounces at haskell.org<mailto:ghc-devs-bounces at haskell.org>] On Behalf Of Conal Elliott
> Sent: 04 November 2013 20:08
> To: ghc-devs at haskell.org<mailto:ghc-devs at haskell.org>
> Subject: Finding & assembling class dictionaries from GHC plugins?
>
>
>
> I'm working on a GHC plugin (for compiling Haskell to hardware), and I need to synthesize Typeable (and maybe other) class dictionaries for a wide range of types, including composite types (functions, pairs, lists, etc). Can it be done, and how? I think I'm mainly looking for mechanics of finding existing class instances (however they're defined) and assembling them (for parametrized/composite dictionaries), rather than mechanisms specific to Typeable.
>
> Thanks, -- Conal
>
>
> _______________________________________________
> ghc-devs mailing list
> ghc-devs at haskell.org<mailto: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/20131106/99dcb3a0/attachment.html>

From gergely at risko.hu  Wed Nov  6 14:24:32 2013
From: gergely at risko.hu (Gergely Risko)
Date: Wed, 06 Nov 2013 15:24:32 +0100
Subject: Template Haskell and stage-1
References: <59543203684B2244980D7E4057D5FBC14866C489@DB3EX14MBXC308.europe.corp.microsoft.com>
Message-ID: <87fvr9halb.fsf@gergely.risko.hu>

I also have a related request, if someone comes around with great build
system experience.  I usually hack on GHC with BUILD_DOCS = NO, and it
always annoys me that the xhtml and co libraries are built even then,
without ever needing those, making my build slower.

Gergely

On Wed, 6 Nov 2013 13:43:02 +0000, Simon Peyton-Jones <simonpj at microsoft.com> writes:

> I?d like to make ?XtemplateHaskell simply illegal in a stage-1
> compiler. After all, it is!
>
> But for some reason we use the stage1 compiler to generate
> dependencies for the DPH libraries; those libraries have {-# LANGUAGE
> TemplateHaskell #-}, so the dependency generation fails. See below.
>
> But WHY do we generate deps for DPH with stage1? We don?t *compile*
> the DPH libraries with stage1, because they need TH. Can?t we just
> generate deps with stage2?
>
> For now I?ll make it a warning, but could someone fix the build
> system?
>
> Thanks
>
> Simon
>
> mv
> libraries/dph/dph-lifted-copy/dist-install/build/.depend-v-dyn.c_asm.tmp
> libraries/dph/dph-lifted-copy/dist-install/build/.depend-v-dyn.c_asm
>
> "rm" -f
> libraries/dph/dph-lifted-copy/dist-install/build/.depend-v-dyn.haskell.
> tmp 
>
> "inplace/bin/ghc-stage1" -M -static -H32m -O -Werror -Wall -H64m -O0 -
> package-name dph-lifted-copy-0.8.0.1 -hide-all-packages -i -
> ilibraries/dph/dph-lifted-copy/. -
> ilibraries/dph/dph-lifted-copy/dist-install/build -
> ilibraries/dph/dph-lifted-copy/dist-install/build/autogen -
> Ilibraries/dph/dph-lifted-copy/dist-install/build -
> Ilibraries/dph/dph-lifted-copy/dist-install/build/autogen -
> Ilibraries/dph/dph-lifted-copy/. -optP-include -
> optPlibraries/dph/dph-lifted-copy/dist-install/build/autogen/cabal_macros.
> h -package array-0.5.0.0 -package base-4.7.0.0 -package
> dph-base-0.8.0.1 -package dph-prim-par-0.8.0.1 -package
> ghc-7.7.20131106 -package random-1.0.1.1 -package
> template-haskell-2.9.0.0 -package vector-0.10.9.1 -Odph -
> funbox-strict-fields -fcpr-off -fno-warn-orphans -
> fno-warn-missing-signatures -XHaskell98 -XTypeFamilies -XGADTs -
> XRankNTypes -XBangPatterns -XMagicHash -XUnboxedTuples -XTypeOperators
> -O2 -O -dcore-lint -fno-warn-amp -fno-warn-deprecated-flags -Wwarn -
> no-user-package-db -rtsopts -odir
> libraries/dph/dph-lifted-copy/dist-install/build -hidir
> libraries/dph/dph-lifted-copy/dist-install/build -stubdir
> libraries/dph/dph-lifted-copy/dist-install/build -dep-makefile
> libraries/dph/dph-lifted-copy/dist-install/build/.depend-v-dyn.haskell.
> tmp -dep-suffix "" -dep-suffix "dyn_" -include-pkg-deps
> libraries/dph/dph-lifted-copy/./Data/Array/Parallel.hs
> libraries/dph/dph-lifted-copy/./Data/Array/Parallel/Lifted.hs
> libraries/dph/dph-lifted-copy/./Data/Array/Parallel/Lifted/Closure.hs
> libraries/dph/dph-lifted-copy/./Data/Array/Parallel/Lifted/Combinators.
> hs
> libraries/dph/dph-lifted-copy/./Data/Array/Parallel/Lifted/PArray.hs
> libraries/dph/dph-lifted-copy/./Data/Array/Parallel/Lifted/Scalar.hs
> libraries/dph/dph-lifted-copy/./Data/Array/Parallel/Lifted/TH/Repr.hs
> libraries/dph/dph-lifted-copy/./Data/Array/Parallel/Lifted/Unboxed.hs
> libraries/dph/dph-lifted-copy/./Data/Array/Parallel/PArr.hs
> libraries/dph/dph-lifted-copy/./Data/Array/Parallel/PArray.hs
> libraries/dph/dph-lifted-copy/./Data/Array/Parallel/PArray/Base.hs
> libraries/dph/dph-lifted-copy/./Data/Array/Parallel/PArray/PData.hs
> libraries/dph/dph-lifted-copy/./Data/Array/Parallel/PArray/PDataInstances.
> hs libraries/dph/dph-lifted-copy/./Data/Array/Parallel/PArray/PRepr.hs
> libraries/dph/dph-lifted-copy/./Data/Array/Parallel/PArray/PReprInstances.
> hs
> libraries/dph/dph-lifted-copy/./Data/Array/Parallel/PArray/Scalar.hs
> libraries/dph/dph-lifted-copy/./Data/Array/Parallel/PArray/ScalarInstances.
> hs libraries/dph/dph-lifted-copy/./Data/Array/Parallel/PArray/Types.hs
> libraries/dph/dph-lifted-copy/./Data/Array/Parallel/Prelude.hs
> libraries/dph/dph-lifted-copy/./Data/Array/Parallel/Prelude/Base.hs
> libraries/dph/dph-lifted-copy/./Data/Array/Parallel/Prelude/Bool.hs
> libraries/dph/dph-lifted-copy/./Data/Array/Parallel/Prelude/Double.hs
> libraries/dph/dph-lifted-copy/./Data/Array/Parallel/Prelude/Float.hs
> libraries/dph/dph-lifted-copy/./Data/Array/Parallel/Prelude/Int.hs
> libraries/dph/dph-lifted-copy/./Data/Array/Parallel/Prelude/Tuple.hs
> libraries/dph/dph-lifted-copy/./Data/Array/Parallel/Prelude/Word8.hs
> libraries/dph/dph-lifted-copy/./Data/Array/Parallel/Prim.hs
>
> ghc-stage1:
> libraries/dph/dph-lifted-copy/Data/Array/Parallel/Lifted/TH/Repr.hs:1:14-
> 28: Template Haskell requires GHC with interpreter support
>
> Perhaps you are using a stage-1 compiler?
>
> Microsoft Research Limited (company number 03369488) is registered in
> England and Wales 
>
> Registered office is at 21 Station Road, Cambridge, CB1 2FB
>
>
> _______________________________________________
> ghc-devs mailing list
> ghc-devs at haskell.org
> http://www.haskell.org/mailman/listinfo/ghc-devs


From gergely at risko.hu  Wed Nov  6 15:08:53 2013
From: gergely at risko.hu (Gergely Risko)
Date: Wed, 06 Nov 2013 16:08:53 +0100
Subject: Annotations
References: <59543203684B2244980D7E4057D5FBC14866C163@DB3EX14MBXC308.europe.corp.microsoft.com>
 <87vc05hhet.fsf@gergely.risko.hu>
 <59543203684B2244980D7E4057D5FBC14866C32F@DB3EX14MBXC308.europe.corp.microsoft.com>
Message-ID: <871u2th8je.fsf@gergely.risko.hu>

[sorry if someone receives this twice, apparently gmane has some issues with crossposting]
[this is also my reply to Ekmett's comment]

On Wed, 6 Nov 2013 12:06:04 +0000, Simon Peyton-Jones <simonpj at microsoft.com> writes:

> But this is true for ANY language extension. If a TH library exports a
> function that generates (say) a type family declaration, and you
> splice that into a file, do you need -XTypeFamilies in the client
> file?   I think currently you do.

So, we've made a little bit of testing on this.

There are a lot of extensions that simply can't be used with TH:
  - n+k,
  - RecursiveDo,
  - TransformListComp,
  - Arrows,
  - ImplicitParams,
  - TupleSections,
  - Monadcomprehensions.

The rest can be grouped into two parts.

The following extensions still work when spliced in without the
corresponding language pragma:
  - UnicodeSyntax,
  - LambdaCase,
  - NamedFieldPuns,
  - RecordWildCards,
  - DataTypeContexts (and you get rid of the deprecation warning
                      generation this way :)),
  - ConstraintKind,
  - MagicHash (note that UnboxedTuples is in the other part),
  - TraditionalRecordSyntax,
  - MultiWayIf,
  - GADTs (extra nice example at the end of this message).

The following needs the pragma at the place of splicing:
  - PostfixOperators,
  - ScopedTypeVariables,
  - Rank2, RankN,
  - deriving typeable and data,
  - UnboxedTuples,
  - ViewPatterns,
  - ParallelListComp,
  - ExistentialQuantification,
  - EmptyDataDecls,
  - TypeFamilies,
  - MultiParamTypeClasses,
  - FunctionalDependencies.

I don't see any trivial distinction, like based on Reader vs Typechecker
or anything like that.
Note ViewPatterns vs LambdaCase.
Note GADTs vs Rank2.

A very interesting example is ExplicitForAll.  The AST for polymorphic
functions always have explicit foralls in TH.Syntax; so there is no way
to require the user at the point of splicing to enable the language
extension.

GADTs are cool to:
------------------------------
{-# LANGUAGE TemplateHaskell #-}
-- No need for GADTs at all!
-- {-# LANGUAGE GADTs #-}

$([d|
         data Foo where
           Foo1 :: Int -> Foo
           Foo2 :: String -> Foo

         f1 :: Foo
         f1 = Foo1 5

         f :: Foo -> Either Int String
         f (Foo1 n) = Left n
         f (Foo2 s) = Right s
        |])

main = print (f f1)
------------------------------

So all I'm asking for is that if it's not very inconvenient for the
implementor, please put the Annotations language pragma into the first
group. :)

Thanks,
Gergely


From igloo at earth.li  Wed Nov  6 17:12:40 2013
From: igloo at earth.li (Ian Lynagh)
Date: Wed, 6 Nov 2013 17:12:40 +0000
Subject: Template Haskell and stage-1
In-Reply-To: <59543203684B2244980D7E4057D5FBC14866C489@DB3EX14MBXC308.europe.corp.microsoft.com>
References: <59543203684B2244980D7E4057D5FBC14866C489@DB3EX14MBXC308.europe.corp.microsoft.com>
Message-ID: <20131106171240.GA9407@matrix.chaos.earth.li>

On Wed, Nov 06, 2013 at 01:43:02PM +0000, Simon Peyton-Jones wrote:
> I'd like to make -XtemplateHaskell simply illegal in a stage-1 compiler. After all, it is!
> But for some reason we use the stage1 compiler to generate dependencies for the DPH libraries; those libraries have {-# LANGUAGE TemplateHaskell #-}, so the dependency generation fails.  See below.
> But WHY do we generate deps for DPH with stage1?  We don't *compile* the DPH libraries with stage1, because they need TH.  Can't we just generate deps with stage2?

It's due to the build system phases:
http://ghc.haskell.org/trac/ghc/wiki/Building/Architecture/Idiom/PhaseOrdering#GHCsphases

Stage2 doesn't exist during the phase in which DPH is configured.
Changing it to use stage 2 would probably mean adding another phase for
things that need to be configured by stage 2. This might mean slower
builds due to loss of parallelism, I'm not sure.

Perhaps the decision to build DPH with the GHC build system should be
revisited? It causes some complication, and it seems that more and more
people are disabling it anyway, in order to get faster builds.


Thanks
Ian


From ggreif at gmail.com  Wed Nov  6 17:19:22 2013
From: ggreif at gmail.com (Gabor Greif)
Date: Wed, 6 Nov 2013 18:19:22 +0100
Subject: Template Haskell and stage-1
In-Reply-To: <20131106171240.GA9407@matrix.chaos.earth.li>
References: <59543203684B2244980D7E4057D5FBC14866C489@DB3EX14MBXC308.europe.corp.microsoft.com>
 <20131106171240.GA9407@matrix.chaos.earth.li>
Message-ID: <CAK-hX0kFzqmySf-W+tnV0m17amcubNzdYZmNh1+njA3ffTR4AQ@mail.gmail.com>

Maybe DPH just should be left out of being built in the default target?

Just an idea,

   Gabor

On 11/6/13, Ian Lynagh <igloo at earth.li> wrote:
> On Wed, Nov 06, 2013 at 01:43:02PM +0000, Simon Peyton-Jones wrote:
>> I'd like to make -XtemplateHaskell simply illegal in a stage-1 compiler.
>> After all, it is!
>> But for some reason we use the stage1 compiler to generate dependencies
>> for the DPH libraries; those libraries have {-# LANGUAGE TemplateHaskell
>> #-}, so the dependency generation fails.  See below.
>> But WHY do we generate deps for DPH with stage1?  We don't *compile* the
>> DPH libraries with stage1, because they need TH.  Can't we just generate
>> deps with stage2?
>
> It's due to the build system phases:
> http://ghc.haskell.org/trac/ghc/wiki/Building/Architecture/Idiom/PhaseOrdering#GHCsphases
>
> Stage2 doesn't exist during the phase in which DPH is configured.
> Changing it to use stage 2 would probably mean adding another phase for
> things that need to be configured by stage 2. This might mean slower
> builds due to loss of parallelism, I'm not sure.
>
> Perhaps the decision to build DPH with the GHC build system should be
> revisited? It causes some complication, and it seems that more and more
> people are disabling it anyway, in order to get faster builds.
>
>
> Thanks
> Ian
>
> _______________________________________________
> ghc-devs mailing list
> ghc-devs at haskell.org
> http://www.haskell.org/mailman/listinfo/ghc-devs
>

From carter.schonwald at gmail.com  Wed Nov  6 17:38:44 2013
From: carter.schonwald at gmail.com (Carter Schonwald)
Date: Wed, 6 Nov 2013 12:38:44 -0500
Subject: Template Haskell and stage-1
In-Reply-To: <CAK-hX0kFzqmySf-W+tnV0m17amcubNzdYZmNh1+njA3ffTR4AQ@mail.gmail.com>
References: <59543203684B2244980D7E4057D5FBC14866C489@DB3EX14MBXC308.europe.corp.microsoft.com>
 <20131106171240.GA9407@matrix.chaos.earth.li>
 <CAK-hX0kFzqmySf-W+tnV0m17amcubNzdYZmNh1+njA3ffTR4AQ@mail.gmail.com>
Message-ID: <CAHYVw0xjfhxtD8oMypWMZTTqiMfr2btP-0USKG2OQYoF4ppzpg@mail.gmail.com>

This sort of ties into some of the post 7.8 build system cleanup plans
perhaps?


On Wed, Nov 6, 2013 at 12:19 PM, Gabor Greif <ggreif at gmail.com> wrote:

> Maybe DPH just should be left out of being built in the default target?
>
> Just an idea,
>
>    Gabor
>
> On 11/6/13, Ian Lynagh <igloo at earth.li> wrote:
> > On Wed, Nov 06, 2013 at 01:43:02PM +0000, Simon Peyton-Jones wrote:
> >> I'd like to make -XtemplateHaskell simply illegal in a stage-1 compiler.
> >> After all, it is!
> >> But for some reason we use the stage1 compiler to generate dependencies
> >> for the DPH libraries; those libraries have {-# LANGUAGE TemplateHaskell
> >> #-}, so the dependency generation fails.  See below.
> >> But WHY do we generate deps for DPH with stage1?  We don't *compile* the
> >> DPH libraries with stage1, because they need TH.  Can't we just generate
> >> deps with stage2?
> >
> > It's due to the build system phases:
> >
> http://ghc.haskell.org/trac/ghc/wiki/Building/Architecture/Idiom/PhaseOrdering#GHCsphases
> >
> > Stage2 doesn't exist during the phase in which DPH is configured.
> > Changing it to use stage 2 would probably mean adding another phase for
> > things that need to be configured by stage 2. This might mean slower
> > builds due to loss of parallelism, I'm not sure.
> >
> > Perhaps the decision to build DPH with the GHC build system should be
> > revisited? It causes some complication, and it seems that more and more
> > people are disabling it anyway, in order to get faster builds.
> >
> >
> > Thanks
> > Ian
> >
> > _______________________________________________
> > 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/20131106/caaddcec/attachment.html>

From nicolas.frisby at gmail.com  Wed Nov  6 20:02:42 2013
From: nicolas.frisby at gmail.com (Nicolas Frisby)
Date: Wed, 6 Nov 2013 14:02:42 -0600
Subject: Any GHC plans to adopt tf-random?
Message-ID: <CADfHYo7ZDSd+nrXhJ_opRfa0AMuv=3C2N=tViEX++=6Mh0tTLQ@mail.gmail.com>

Bugs #3575 #3620 have to do with splitting StdGens yielding dependent
generators.

The Haskell 2013 paper *Splittable Pseudorandom Number Generators Using
Cryptographic Hashing* by Claessen and Pa?ka yielded the tf-random package
on Hackage.

Are there any plans to integrate these corrections into System.Random?

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

From nicolas.frisby at gmail.com  Wed Nov  6 20:12:02 2013
From: nicolas.frisby at gmail.com (Nicolas Frisby)
Date: Wed, 6 Nov 2013 14:12:02 -0600
Subject: Any GHC plans to adopt tf-random?
In-Reply-To: <CADfHYo7ZDSd+nrXhJ_opRfa0AMuv=3C2N=tViEX++=6Mh0tTLQ@mail.gmail.com>
References: <CADfHYo7ZDSd+nrXhJ_opRfa0AMuv=3C2N=tViEX++=6Mh0tTLQ@mail.gmail.com>
Message-ID: <CADfHYo6tS7C1uf_bYZKoAegb5f8ye4=jmoBg-odqHJ7=bLnmmA@mail.gmail.com>

Adding Ryan Newton to the TO field, as the maintainer of random.


On Wed, Nov 6, 2013 at 2:02 PM, Nicolas Frisby <nicolas.frisby at gmail.com>wrote:

> Bugs #3575 #3620 have to do with splitting StdGens yielding dependent
> generators.
>
> The Haskell 2013 paper *Splittable Pseudorandom Number Generators Using
> Cryptographic Hashing* by Claessen and Pa?ka yielded the tf-random
> package on Hackage.
>
> Are there any plans to integrate these corrections into System.Random?
>
> Thanks.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/ghc-devs/attachments/20131106/6229e2d9/attachment.html>

From rrnewton at gmail.com  Wed Nov  6 21:51:02 2013
From: rrnewton at gmail.com (Ryan Newton)
Date: Wed, 6 Nov 2013 16:51:02 -0500
Subject: Any GHC plans to adopt tf-random?
In-Reply-To: <CADfHYo6tS7C1uf_bYZKoAegb5f8ye4=jmoBg-odqHJ7=bLnmmA@mail.gmail.com>
References: <CADfHYo7ZDSd+nrXhJ_opRfa0AMuv=3C2N=tViEX++=6Mh0tTLQ@mail.gmail.com>
 <CADfHYo6tS7C1uf_bYZKoAegb5f8ye4=jmoBg-odqHJ7=bLnmmA@mail.gmail.com>
Message-ID: <CACYs5AY4k9NAvRs-W9Szcv2FHwtvOiYw_Yz5CJ1EJ+B+BJSSCw@mail.gmail.com>

Hi all,

It looks like since the paper has come out the code has been released to
Hackage.  I personally would love to replace System.Random with something
like this.

I think the question of whether it's time comes down to some due-diligence
issues outside the scope of the paper.  This library has C code, have
people tested it extensively on Mac/Linux/Windows?  Does it have any
performance divots we should know about?  (Though the performance of the
legacy implementation was bad in many respects -- it
is a low bar.)

  -Ryan




On Wed, Nov 6, 2013 at 3:12 PM, Nicolas Frisby <nicolas.frisby at gmail.com>wrote:

> Adding Ryan Newton to the TO field, as the maintainer of random.
>
>
> On Wed, Nov 6, 2013 at 2:02 PM, Nicolas Frisby <nicolas.frisby at gmail.com>wrote:
>
>> Bugs #3575 #3620 have to do with splitting StdGens yielding dependent
>> generators.
>>
>> The Haskell 2013 paper *Splittable Pseudorandom Number Generators Using
>> Cryptographic Hashing* by Claessen and Pa?ka yielded the tf-random
>> package on Hackage.
>>
>> Are there any plans to integrate these corrections into System.Random?
>>
>> Thanks.
>>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/ghc-devs/attachments/20131106/997eea3e/attachment.html>

From conal at conal.net  Thu Nov  7 01:07:50 2013
From: conal at conal.net (Conal Elliott)
Date: Wed, 6 Nov 2013 17:07:50 -0800
Subject: Finding & assembling class dictionaries from GHC plugins?
In-Reply-To: <59543203684B2244980D7E4057D5FBC14866C4F1@DB3EX14MBXC308.europe.corp.microsoft.com>
References: <CAD6SzRJM0B-e_THKMPi7p_Jw56DTzAVMGQdbyo2sg3quVvWuNA@mail.gmail.com>
 <59543203684B2244980D7E4057D5FBC148669657@DB3EX14MBXC308.europe.corp.microsoft.com>
 <CADfHYo4GmvZWpOp4uMJFnauB5iwLNbQwOh7Tifsm9pC3VwpP=w@mail.gmail.com>
 <59543203684B2244980D7E4057D5FBC14866B421@DB3EX14MBXC308.europe.corp.microsoft.com>
 <CAD6SzRJt+q+SWJQFEguBaXkMM4N3i-jaWrzfJw7NFFFcXCscQg@mail.gmail.com>
 <59543203684B2244980D7E4057D5FBC14866C4F1@DB3EX14MBXC308.europe.corp.microsoft.com>
Message-ID: <CAD6SzRLF1fXsRkSSjvm9gZRgUkUYMJt+QjXcRu2fY+6ur3XQCQ@mail.gmail.com>

Thanks for the suggestion. I hadn't considered backing up to an HsExpr. I
guess we'd have to start by converting the Core Type to an HsType to form a
type-annotated HsExpr. Am I on the right track here?

-- Conal


On Wed, Nov 6, 2013 at 5:59 AM, Simon Peyton-Jones <simonpj at microsoft.com>wrote:

>  Hmm. One route would be to build a HsExpr (rather than a CoreExpr) for
> the reification of your CoreExpr, and stick that into the maw of the type
> checker.  That would hand off all this dictionary construction to the type
> checker, which is designed for the purpose.
>
>
>
> Simon
>
>
>
> *From:* conal.elliott at gmail.com [mailto:conal.elliott at gmail.com] *On
> Behalf Of *Conal Elliott
> *Sent:* 05 November 2013 23:41
> *To:* Simon Peyton-Jones
> *Cc:* Nicolas Frisby; ghc-devs at haskell.org
> *Subject:* Re: Finding & assembling class dictionaries from GHC plugins?
>
>
>
> Hi Simon,
>
> Here's some context on what I'm after. I'll try to include enough to
> clarify what I'm after, without dragging you into unnecessary detail.
>
> I have a Core expression, which I'm systematically translating to a
> related Core expression. The second one reifies the first one, so that the
> generated code *evaluates* to a run-time (not compile/Core-time)
> representation akin to the original Core expression. In this second
> (reified) representation, I need some run-time representation of types. I
> use Typeable constraints in my representation, and these constraints don't
> appear in the original Core representation. For instance, I have the
> following constructor for function application in a GADT of lambda
> expressions:
>
> > (:^) :: (Typeable a, Typeable b) => E (a -> b) -> E a -> E b
>
> My reification plugin takes a Core application expression, recursively
> reifies the function and argument expressions, and makes an expression that
> applies (:^) to the two recursive results. However--and the point of this
> thread--I also need to come up with Core expressions for the two Typeable
> dictionaries.
>
> So, to clarify my request, given a Core type representation t, I want to
> construct a Core expression that evaluates to the dictionary for Typeable t
> if one exists, or fail if there isn't one. Note that t is not necessarily
> an atomic type; it could instead be something like [(Bool,Int -> String)].
>
> I'm happy to Skype-chat if it'd help.
>
> Thanks,  - Conal
>
>
>
>
>
> On Tue, Nov 5, 2013 at 2:37 PM, Simon Peyton-Jones <simonpj at microsoft.com>
> wrote:
>
>   We just don't know how to start ? ie how call the right functions from
> the type checker. Are there any resources explaining the relevant subset of
> the TcRnIf API?
>
> And I for my part don?t know where to start helping you!  Conal wrote
>
>
>
> I don't think I need to construct dictionaries for new Typeable instances.
> I only need to find and assemble *existing* Typeable instances into
> combinations like Typeable [(Bool,Int -> String)], and I don't know how to
> do so in a GHC plug-in
>
>
>
> That?s exactly what the constraint solver does.  (TcSimplify and
> friends.)  But again I need more context.
>
>
>
> I gather you are talking to Pedro too?  He knows a lot about this stuff.
>
>
>
> Also there are a bunch of folk (Luite, Edsko) worked on the new front-end
> plugin stuff, and are much more expert in it than me.
>
>
>
> We could have a skype call if that would help
>
>
>
> S
>
>
>
>
>
> *From:* Nicolas Frisby [mailto:nicolas.frisby at gmail.com]
> *Sent:* 05 November 2013 14:36
> *To:* Simon Peyton-Jones
> *Cc:* ghc-devs at haskell.org; Conal Elliott
> *Subject:* RE: Finding & assembling class dictionaries from GHC plugins?
>
>
>
> On Nov 5, 2013 3:14 AM, "Simon Peyton-Jones" <simonpj at microsoft.com>
> wrote:
>
> >
> > A core-level plug-in can?t generate fresh instances.  There are some new
> plug-in hooks that fit earlier in the pipeline, which can.  Maybe you can
> use that, and generate a data type decl with ?deriving Typeable??
>
> We're willing to do some awkward shoehorning in HERMIT to make this work
> in limited circumstances. (Hopefully including Conal's.)
>
> We just don't know how to start ? ie how call the right functions from the
> type checker. Are there any resources explaining the relevant subset of the
> TcRnIf API?
>
> Thanks.
>
> >
> >
> > From: ghc-devs [mailto:ghc-devs-bounces at haskell.org] On Behalf Of Conal
> Elliott
> > Sent: 04 November 2013 20:08
> > To: ghc-devs at haskell.org
> > Subject: Finding & assembling class dictionaries from GHC plugins?
> >
> >
> >
> > I'm working on a GHC plugin (for compiling Haskell to hardware), and I
> need to synthesize Typeable (and maybe other) class dictionaries for a wide
> range of types, including composite types (functions, pairs, lists, etc).
> Can it be done, and how? I think I'm mainly looking for mechanics of
> finding existing class instances (however they're defined) and assembling
> them (for parametrized/composite dictionaries), rather than mechanisms
> specific to Typeable.
> >
> > Thanks, -- Conal
> >
> >
> > _______________________________________________
> > 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/20131106/ce2e52f1/attachment-0001.html>

From gdr at integrable-solutions.net  Thu Nov  7 02:15:08 2013
From: gdr at integrable-solutions.net (Gabriel Dos Reis)
Date: Wed, 6 Nov 2013 20:15:08 -0600
Subject: Another CPP gotcha for the manual
In-Reply-To: <CAAOoiFZYgnLHk1XzeSENS+1vBanCiXYi_R_0xvSJn3QFv3Y5Eg@mail.gmail.com>
References: <CAAOoiFZYgnLHk1XzeSENS+1vBanCiXYi_R_0xvSJn3QFv3Y5Eg@mail.gmail.com>
Message-ID: <CAAiZkiCZ3quuRqV4rB+akRWeEpey+Yb6b4boQCxJ8T_j8FhS4w@mail.gmail.com>

On Sun, Nov 3, 2013 at 11:57 AM, Mark Lentczner
<mark.lentczner at gmail.com> wrote:
> Turns out that c pre-processing removes C style (/*?*/) comments. Of course,
> it will do this anywhere in the source. The following program can tell if it
> is compiled -cpp or not:
>
> module Main where
>
> (*/**) :: Double -> Double -> Double
> (*/**) a b = a / (2 ** b)
>
> howCompiled = if use > 1/16 then "normal" else "-cpp"
>   where
>     use = 1 */** 2 + 3 */** 4
>
> main = putStrLn $ "compiled " ++ howCompiled
>
>
> When run:
>
> & runhaskell CppTest.hs
> compiled normal
>
> & runhaskell -cpp CppTest.hs
> compiled -cpp
>
>
> An example in the wild is in the package wai-extra, in the file
> Network/Wai/Middleware/RequestLogger.hs where the */* construct appears
> twice in the comments.
>
> Short of defining and implementing our own CPP-like preprocessing (something
> we might actually consider), I don't think there really is any fix for this,
> so the bug is that it should appear in the GHC documentation on CPP mode
> (?4.12.3), along with similar warnings about trailing back-slashes.
>
> Note that the way in which a multi-line comment is removed differs between
> gcc and clang. In gcc, the comment is removed and content of the line before
> the comment, and contents of the line after the comment are joined into a
> single line. In clang, the two line fragments are kept on separate lines. In
> both cases extra empty lines are added to keep the line count the same.
>
> The consequence of the gcc / clang difference is that neither the above
> code, nor wai-extra will compile with clang.
>
> Note: As far as I can tell this is not a clang bug, but a failure of specs:
> The C definition of comments and their removal is vague, and my guess is gcc
> choose its method based on historical use. The C++ definition makes it clear
> that comments are whitespace, even once removed, and so the clang method is
> correct.

The effect of feeding CPP with a non-C or non-C++ program isn't defined :-)

-- Gaby

From simonpj at microsoft.com  Thu Nov  7 07:44:59 2013
From: simonpj at microsoft.com (Simon Peyton-Jones)
Date: Thu, 7 Nov 2013 07:44:59 +0000
Subject: Finding & assembling class dictionaries from GHC plugins?
In-Reply-To: <CAD6SzRLF1fXsRkSSjvm9gZRgUkUYMJt+QjXcRu2fY+6ur3XQCQ@mail.gmail.com>
References: <CAD6SzRJM0B-e_THKMPi7p_Jw56DTzAVMGQdbyo2sg3quVvWuNA@mail.gmail.com>
 <59543203684B2244980D7E4057D5FBC148669657@DB3EX14MBXC308.europe.corp.microsoft.com>
 <CADfHYo4GmvZWpOp4uMJFnauB5iwLNbQwOh7Tifsm9pC3VwpP=w@mail.gmail.com>
 <59543203684B2244980D7E4057D5FBC14866B421@DB3EX14MBXC308.europe.corp.microsoft.com>
 <CAD6SzRJt+q+SWJQFEguBaXkMM4N3i-jaWrzfJw7NFFFcXCscQg@mail.gmail.com>
 <59543203684B2244980D7E4057D5FBC14866C4F1@DB3EX14MBXC308.europe.corp.microsoft.com>
 <CAD6SzRLF1fXsRkSSjvm9gZRgUkUYMJt+QjXcRu2fY+6ur3XQCQ@mail.gmail.com>
Message-ID: <59543203684B2244980D7E4057D5FBC14866D14D@DB3EX14MBXC308.europe.corp.microsoft.com>

Well, you are writing a function
                reify :: CoreExpr -> HsExpr RdrName
It takes as its input a CoreExpr and produces as its output a reification of the input.  I don't see why you need start by converting Core to HsExpr. Just write reify directly!

Simon

From: conal.elliott at gmail.com [mailto:conal.elliott at gmail.com] On Behalf Of Conal Elliott
Sent: 07 November 2013 01:08
To: Simon Peyton-Jones
Cc: Nicolas Frisby; ghc-devs at haskell.org
Subject: Re: Finding & assembling class dictionaries from GHC plugins?

Thanks for the suggestion. I hadn't considered backing up to an HsExpr. I guess we'd have to start by converting the Core Type to an HsType to form a type-annotated HsExpr. Am I on the right track here?
-- Conal

On Wed, Nov 6, 2013 at 5:59 AM, Simon Peyton-Jones <simonpj at microsoft.com<mailto:simonpj at microsoft.com>> wrote:
Hmm. One route would be to build a HsExpr (rather than a CoreExpr) for the reification of your CoreExpr, and stick that into the maw of the type checker.  That would hand off all this dictionary construction to the type checker, which is designed for the purpose.

Simon

From: conal.elliott at gmail.com<mailto:conal.elliott at gmail.com> [mailto:conal.elliott at gmail.com<mailto:conal.elliott at gmail.com>] On Behalf Of Conal Elliott
Sent: 05 November 2013 23:41
To: Simon Peyton-Jones
Cc: Nicolas Frisby; ghc-devs at haskell.org<mailto:ghc-devs at haskell.org>
Subject: Re: Finding & assembling class dictionaries from GHC plugins?

Hi Simon,

Here's some context on what I'm after. I'll try to include enough to clarify what I'm after, without dragging you into unnecessary detail.

I have a Core expression, which I'm systematically translating to a related Core expression. The second one reifies the first one, so that the generated code *evaluates* to a run-time (not compile/Core-time) representation akin to the original Core expression. In this second (reified) representation, I need some run-time representation of types. I use Typeable constraints in my representation, and these constraints don't appear in the original Core representation. For instance, I have the following constructor for function application in a GADT of lambda expressions:

> (:^) :: (Typeable a, Typeable b) => E (a -> b) -> E a -> E b

My reification plugin takes a Core application expression, recursively reifies the function and argument expressions, and makes an expression that applies (:^) to the two recursive results. However--and the point of this thread--I also need to come up with Core expressions for the two Typeable dictionaries.

So, to clarify my request, given a Core type representation t, I want to construct a Core expression that evaluates to the dictionary for Typeable t if one exists, or fail if there isn't one. Note that t is not necessarily an atomic type; it could instead be something like [(Bool,Int -> String)].
I'm happy to Skype-chat if it'd help.
Thanks,  - Conal


On Tue, Nov 5, 2013 at 2:37 PM, Simon Peyton-Jones <simonpj at microsoft.com<mailto:simonpj at microsoft.com>> wrote:

We just don't know how to start - ie how call the right functions from the type checker. Are there any resources explaining the relevant subset of the TcRnIf API?
And I for my part don't know where to start helping you!  Conal wrote

I don't think I need to construct dictionaries for new Typeable instances. I only need to find and assemble *existing* Typeable instances into combinations like Typeable [(Bool,Int -> String)], and I don't know how to do so in a GHC plug-in

That's exactly what the constraint solver does.  (TcSimplify and friends.)  But again I need more context.

I gather you are talking to Pedro too?  He knows a lot about this stuff.

Also there are a bunch of folk (Luite, Edsko) worked on the new front-end plugin stuff, and are much more expert in it than me.

We could have a skype call if that would help

S


From: Nicolas Frisby [mailto:nicolas.frisby at gmail.com<mailto:nicolas.frisby at gmail.com>]
Sent: 05 November 2013 14:36
To: Simon Peyton-Jones
Cc: ghc-devs at haskell.org<mailto:ghc-devs at haskell.org>; Conal Elliott
Subject: RE: Finding & assembling class dictionaries from GHC plugins?


On Nov 5, 2013 3:14 AM, "Simon Peyton-Jones" <simonpj at microsoft.com<mailto:simonpj at microsoft.com>> wrote:

>
> A core-level plug-in can't generate fresh instances.  There are some new plug-in hooks that fit earlier in the pipeline, which can.  Maybe you can use that, and generate a data type decl with "deriving Typeable"?

We're willing to do some awkward shoehorning in HERMIT to make this work in limited circumstances. (Hopefully including Conal's.)

We just don't know how to start - ie how call the right functions from the type checker. Are there any resources explaining the relevant subset of the TcRnIf API?

Thanks.

>
>
> From: ghc-devs [mailto:ghc-devs-bounces at haskell.org<mailto:ghc-devs-bounces at haskell.org>] On Behalf Of Conal Elliott
> Sent: 04 November 2013 20:08
> To: ghc-devs at haskell.org<mailto:ghc-devs at haskell.org>
> Subject: Finding & assembling class dictionaries from GHC plugins?
>
>
>
> I'm working on a GHC plugin (for compiling Haskell to hardware), and I need to synthesize Typeable (and maybe other) class dictionaries for a wide range of types, including composite types (functions, pairs, lists, etc). Can it be done, and how? I think I'm mainly looking for mechanics of finding existing class instances (however they're defined) and assembling them (for parametrized/composite dictionaries), rather than mechanisms specific to Typeable.
>
> Thanks, -- Conal
>
>
> _______________________________________________
> ghc-devs mailing list
> ghc-devs at haskell.org<mailto: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/20131107/cb1ec56c/attachment-0001.html>

From daniel.trstenjak at gmail.com  Thu Nov  7 11:52:34 2013
From: daniel.trstenjak at gmail.com (Daniel Trstenjak)
Date: Thu, 7 Nov 2013 12:52:34 +0100
Subject: GHC error message on type mismatch
Message-ID: <20131107115234.GA815@machine>


Hello,

I don't know if I'm the only one struggeling with this GHC error message
on type mismatches or it's because I'm not a full time Haskeller, or
because I'm not a native english speaker.

Couldn't match type `A' with `B?
    Expected type: B
      Actual type: A


My problem is with 'Expected' and 'Actual', that I'm often unsure if
the compiler is "expecting" something or if I'm the expecting one
and the same goes for "actual".

I know that the compiler is the expecting one and that I'm given the
actual thing, but it's quite often that I'm looking at this error
and have to repeat this reasoning.

It's strange, because normaly I can memorize such things quite good,
but this one bothers me.

Perhaps it would be easier for myself if 'Actual type' would be called
e.g. 'Given type', I don't know, that just one of the two has a less
generic meaning.


Greetings,
Daniel

From simonpj at microsoft.com  Thu Nov  7 18:11:23 2013
From: simonpj at microsoft.com (Simon Peyton-Jones)
Date: Thu, 7 Nov 2013 18:11:23 +0000
Subject: Windows linking
Message-ID: <59543203684B2244980D7E4057D5FBC14866E183@DB3EX14MBXC308.europe.corp.microsoft.com>

Austin
Ok with the new msys2 I get the too-many-symbols thing below.  This didn't happen before.  Maybe I can switch off dynamic linking? How?
Simon
Too many symbols in DLL compiler/stage2/build/libHSghc-7.7.20131107-0-ghc7.7.20131107.dll
          [5263] ghczm7zi7zi20131107_Var_zdfUniquableVar_closure
          [5264] ghczm7zi7zi20131107_Var_zdfUniquableVar_info
          [5265] ghczm7zi7zi20131107_Var_zdwsetVarUnique_closure
          [5266] ghczm7zi7zi20131107_Var_zdwsetVarUnique_info
          [5267] ghczm7zi7zi20131107_Var_zdwupdateTyVarKindM_closure
          [5268] ghczm7zi7zi20131107_Var_zdwupdateTyVarKindM_info
          [5269] ghczm7zi7zi20131107_Var_zdwzdcgmapMp_closure
          [5270] ghczm7zi7zi20131107_Var_zdwzdcgmapMp_info
          [5271] setHeapSize

compiler/ghc.mk:472: recipe for target 'compiler/stage2/build/libHSghc-7.7.20131107-0-ghc7.7.20131107.dll' failed
make[1]: *** [compiler/stage2/build/libHSghc-7.7.20131107-0-ghc7.7.20131107.dll] Error 1
make[1]: *** Deleting file 'compiler/stage2/build/libHSghc-7.7.20131107-0-ghc7.7.20131107.dll'
Makefile:64: recipe for target 'all' failed
make: *** [all] Error 2
HEAD $
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/ghc-devs/attachments/20131107/9df1dfc2/attachment.html>

From conal at conal.net  Thu Nov  7 18:15:05 2013
From: conal at conal.net (Conal Elliott)
Date: Thu, 7 Nov 2013 10:15:05 -0800
Subject: Finding & assembling class dictionaries from GHC plugins?
In-Reply-To: <59543203684B2244980D7E4057D5FBC14866D14D@DB3EX14MBXC308.europe.corp.microsoft.com>
References: <CAD6SzRJM0B-e_THKMPi7p_Jw56DTzAVMGQdbyo2sg3quVvWuNA@mail.gmail.com>
 <59543203684B2244980D7E4057D5FBC148669657@DB3EX14MBXC308.europe.corp.microsoft.com>
 <CADfHYo4GmvZWpOp4uMJFnauB5iwLNbQwOh7Tifsm9pC3VwpP=w@mail.gmail.com>
 <59543203684B2244980D7E4057D5FBC14866B421@DB3EX14MBXC308.europe.corp.microsoft.com>
 <CAD6SzRJt+q+SWJQFEguBaXkMM4N3i-jaWrzfJw7NFFFcXCscQg@mail.gmail.com>
 <59543203684B2244980D7E4057D5FBC14866C4F1@DB3EX14MBXC308.europe.corp.microsoft.com>
 <CAD6SzRLF1fXsRkSSjvm9gZRgUkUYMJt+QjXcRu2fY+6ur3XQCQ@mail.gmail.com>
 <59543203684B2244980D7E4057D5FBC14866D14D@DB3EX14MBXC308.europe.corp.microsoft.com>
Message-ID: <CAD6SzR+UC7ePZY3+7dimz9h646bKD=VQ0pV6EcGLEsQAMbFudQ@mail.gmail.com>

On Wed, Nov 6, 2013 at 11:44 PM, Simon Peyton-Jones
<simonpj at microsoft.com>wrote:

>  Well, you are writing a function
>
>                 reify :: CoreExpr -> HsExpr RdrName
>
>
Not exactly. I'm reifying CoreExpr directly to another CoreExpr. (The
target CoreExpr calls into an API for GADT-typed lambda
terms<https://github.com/conal/lambda-ccc/blob/master/src/LambdaCCC/Lambda.hs>.
All works swimmingly as long as I'm able to avoid dictionary construction,
but I'm no longer able to do so.) I haven't explored your suggestion of
translating to HsExpr instead. Do you know of any plugins that work this
way? Do you really believe it would work out? For instance, I wouldn't know
where to insert type annotations, and I'd have to back-translate names. I
imagine there are other challenges I don't foresee.


> It takes as its input a CoreExpr and produces as its output a reification
> of the input.  I don?t see why you need start by converting Core to HsExpr.
> Just write reify directly!
>

I wasn't suggesting converting a CoreExpr to an HsExpr. Rather, I was
wondering out loud how I might get the type-checker's help to generate Core
to find/assemble a Typeable dictionary for a given Core type (since I'm
starting with Core). One idea is translate the core type cty to an HsType
hty, use hty in a very simple HsExpr like "Dict :: Dict hty" (where Dict is
from Ed K's constraints package), use the typechecker to convert that
simple HsExpr to a CoreExpr, and then extract the dictionary-forming
sub-CoreExpr. Or something simpler along the same lines.

Thanks for the help,

-- Conal


>
> Simon
>
>
>
> *From:* conal.elliott at gmail.com [mailto:conal.elliott at gmail.com] *On
> Behalf Of *Conal Elliott
> *Sent:* 07 November 2013 01:08
>
> *To:* Simon Peyton-Jones
> *Cc:* Nicolas Frisby; ghc-devs at haskell.org
> *Subject:* Re: Finding & assembling class dictionaries from GHC plugins?
>
>
>
> Thanks for the suggestion. I hadn't considered backing up to an HsExpr. I
> guess we'd have to start by converting the Core Type to an HsType to form a
> type-annotated HsExpr. Am I on the right track here?
>
> -- Conal
>
>
>
> On Wed, Nov 6, 2013 at 5:59 AM, Simon Peyton-Jones <simonpj at microsoft.com>
> wrote:
>
>  Hmm. One route would be to build a HsExpr (rather than a CoreExpr) for
> the reification of your CoreExpr, and stick that into the maw of the type
> checker.  That would hand off all this dictionary construction to the type
> checker, which is designed for the purpose.
>
>
>
> Simon
>
>
>
> *From:* conal.elliott at gmail.com [mailto:conal.elliott at gmail.com] *On
> Behalf Of *Conal Elliott
> *Sent:* 05 November 2013 23:41
> *To:* Simon Peyton-Jones
> *Cc:* Nicolas Frisby; ghc-devs at haskell.org
> *Subject:* Re: Finding & assembling class dictionaries from GHC plugins?
>
>
>
> Hi Simon,
>
> Here's some context on what I'm after. I'll try to include enough to
> clarify what I'm after, without dragging you into unnecessary detail.
>
> I have a Core expression, which I'm systematically translating to a
> related Core expression. The second one reifies the first one, so that the
> generated code *evaluates* to a run-time (not compile/Core-time)
> representation akin to the original Core expression. In this second
> (reified) representation, I need some run-time representation of types. I
> use Typeable constraints in my representation, and these constraints don't
> appear in the original Core representation. For instance, I have the
> following constructor for function application in a GADT of lambda
> expressions:
>
> > (:^) :: (Typeable a, Typeable b) => E (a -> b) -> E a -> E b
>
> My reification plugin takes a Core application expression, recursively
> reifies the function and argument expressions, and makes an expression that
> applies (:^) to the two recursive results. However--and the point of this
> thread--I also need to come up with Core expressions for the two Typeable
> dictionaries.
>
> So, to clarify my request, given a Core type representation t, I want to
> construct a Core expression that evaluates to the dictionary for Typeable t
> if one exists, or fail if there isn't one. Note that t is not necessarily
> an atomic type; it could instead be something like [(Bool,Int -> String)].
>
> I'm happy to Skype-chat if it'd help.
>
> Thanks,  - Conal
>
>
>
>
>
> On Tue, Nov 5, 2013 at 2:37 PM, Simon Peyton-Jones <simonpj at microsoft.com>
> wrote:
>
>   We just don't know how to start ? ie how call the right functions from
> the type checker. Are there any resources explaining the relevant subset of
> the TcRnIf API?
>
> And I for my part don?t know where to start helping you!  Conal wrote
>
>
>
> I don't think I need to construct dictionaries for new Typeable instances.
> I only need to find and assemble *existing* Typeable instances into
> combinations like Typeable [(Bool,Int -> String)], and I don't know how to
> do so in a GHC plug-in
>
>
>
> That?s exactly what the constraint solver does.  (TcSimplify and
> friends.)  But again I need more context.
>
>
>
> I gather you are talking to Pedro too?  He knows a lot about this stuff.
>
>
>
> Also there are a bunch of folk (Luite, Edsko) worked on the new front-end
> plugin stuff, and are much more expert in it than me.
>
>
>
> We could have a skype call if that would help
>
>
>
> S
>
>
>
>
>
> *From:* Nicolas Frisby [mailto:nicolas.frisby at gmail.com]
> *Sent:* 05 November 2013 14:36
> *To:* Simon Peyton-Jones
> *Cc:* ghc-devs at haskell.org; Conal Elliott
> *Subject:* RE: Finding & assembling class dictionaries from GHC plugins?
>
>
>
> On Nov 5, 2013 3:14 AM, "Simon Peyton-Jones" <simonpj at microsoft.com>
> wrote:
>
> >
> > A core-level plug-in can?t generate fresh instances.  There are some new
> plug-in hooks that fit earlier in the pipeline, which can.  Maybe you can
> use that, and generate a data type decl with ?deriving Typeable??
>
> We're willing to do some awkward shoehorning in HERMIT to make this work
> in limited circumstances. (Hopefully including Conal's.)
>
> We just don't know how to start ? ie how call the right functions from the
> type checker. Are there any resources explaining the relevant subset of the
> TcRnIf API?
>
> Thanks.
>
> >
> >
> > From: ghc-devs [mailto:ghc-devs-bounces at haskell.org] On Behalf Of Conal
> Elliott
> > Sent: 04 November 2013 20:08
> > To: ghc-devs at haskell.org
> > Subject: Finding & assembling class dictionaries from GHC plugins?
> >
> >
> >
> > I'm working on a GHC plugin (for compiling Haskell to hardware), and I
> need to synthesize Typeable (and maybe other) class dictionaries for a wide
> range of types, including composite types (functions, pairs, lists, etc).
> Can it be done, and how? I think I'm mainly looking for mechanics of
> finding existing class instances (however they're defined) and assembling
> them (for parametrized/composite dictionaries), rather than mechanisms
> specific to Typeable.
> >
> > Thanks, -- Conal
> >
> >
> > _______________________________________________
> > 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/20131107/d3292cc6/attachment-0001.html>

From simonpj at microsoft.com  Thu Nov  7 18:52:24 2013
From: simonpj at microsoft.com (Simon Peyton-Jones)
Date: Thu, 7 Nov 2013 18:52:24 +0000
Subject: windows agiain
Message-ID: <59543203684B2244980D7E4057D5FBC14866E267@DB3EX14MBXC308.europe.corp.microsoft.com>

Austin



I'm crashing in the testsuite as below.  On Windows with the new msys.  Any ideas?

How do I set my "Windows terminal type"?



Simon



python2 ../../../driver/runtests.py  -e ghc_compiler_always_flags="'-fforce-recomp -dcore-lint -dcmm-lint -dno-debug-output -no-user-package-db -rtsopts '" -e ghc_debugged=False -e ghc_with_native_codegen=1 -e ghc_with_vanilla=1 -e ghc_with_dynamic=1 -e ghc_with_profiling=0 -e ghc_with_threaded_rts=1 -e ghc_with_dynamic_rts=1 -e ghc_with_interpreter=0 -e ghc_unregisterised=0 -e ghc_dynamic_by_default=False -e ghc_dynamic=False -e ghc_with_smp=1 -e ghc_with_llvm=0 -e windows=True -e darwin=False -e in_tree_compiler=True -e clean_only=False --rootdir=. --config=../../../config/ghc -e 'config.confdir="../../../config"' -e 'config.compiler="C:/code/HEAD/inplace/bin/ghc-stage1.exe"' -e 'config.ghc_pkg="C:/code/HEAD/inplace/bin/ghc-pkg.exe"' -e 'config.hp2ps="C:/code/HEAD/inplace/bin/hp2ps.exe"' -e 'config.hpc="C:/code/HEAD/inplace/bin/hpc.exe"' -e 'config.gs="gs"' -e 'config.platform="i386-unknown-mingw32"' -e 'config.os="mingw32"' -e 'config.arch="i386"' -e 'config.wordsize="32"' -e 'default_testopts.cleanup=""' -e 'config.timeout=int() or config.timeout' -e 'config.timeout_prog="../../../timeout/install-inplace/bin/timeout.exe"' -e 'config.exeext=".exe"' -e 'config.top="C:/code/HEAD/testsuite"'  \

     --only=T8037 \

     \

     \

     \

     \

     \



Traceback (most recent call last):

  File "../../../driver/runtests.py", line 144, in <module>

    raise Exception("Can't detect Windows terminal type")

Exception: Can't detect Windows terminal type

../../../mk/test.mk:242: recipe for target 'test' failed

make: *** [test] Error 1

should_compile $
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/ghc-devs/attachments/20131107/c62009e1/attachment.html>

From andreas.voellmy at gmail.com  Thu Nov  7 23:21:41 2013
From: andreas.voellmy at gmail.com (Andreas Voellmy)
Date: Thu, 7 Nov 2013 18:21:41 -0500
Subject: Possible bug related to stm and exceptions
In-Reply-To: <CADdwyZn3Z1XVkdzMJc1cX6AupnxSMwqNkmygd6RrQuRTzq8a9w@mail.gmail.com>
References: <CADdwyZ=Mn2mRQBHLU8Rf7MUAehgpUTqywHBy7BUx4Jf=XYxoeg@mail.gmail.com>
 <525FA25B.4020001@gmail.com>
 <CAO27hRr3GvPCtLgJvjb3T6ex8V_yiiFP=ryd6ZGtA9rmznmGNg@mail.gmail.com>
 <CADdwyZn3Z1XVkdzMJc1cX6AupnxSMwqNkmygd6RrQuRTzq8a9w@mail.gmail.com>
Message-ID: <CADdwyZky_ihbEwAb4Sa71Akia5hrZ=7HMsX4Ak3PxQVrpcq4ag@mail.gmail.com>

Hi all,

Thanks so much for everyone's responses! I finally found the problem, so I
thought I'd follow up and share what happened...

It turned out that the problem was not in the STM implementation, but
rather in bad programming on my part. For some reason, I had a thread
(thread #1) performing a transaction that blocked until any one of several
TQueues become non-empty. On success, the thread sent a value onto another
TQueue monitored by some another thread (thread #2). Thread #2 would then
process all the items in the queues monitored by the first thread.

This lead to the following problem: when one of the TQueues became
non-empty, the first thread would just go through its loop repeatedly,
filling the other queue with values, and thread #2 wouldn't get a chance to
run for a long time. This quickly lead to huge amounts of memory being used
and the program would get totally bogged down.  I finally found the problem
when I noticed that I could make the problem less severe with -C0 and more
severe with large values for -C. Large values let the first thread repeat
the loop for a longer time before the second thread is scheduled and
removes values from the queues.

-Andi



On Thu, Oct 17, 2013 at 10:53 AM, Andreas Voellmy <andreas.voellmy at gmail.com
> wrote:

> Thanks! I'll try to reduce my test case and then I'll post an issue.
>
> I'm currently suspecting that it has something to do with signal handling
> and STM. It seems that the program goes wrong after getting a SIGPIPE from
> trying to send to a closed socket.
>
>
> On Thu, Oct 17, 2013 at 9:35 AM, Ryan Yates <fryguybob at gmail.com> wrote:
>
>> The bug that Luite and I uncovered is
>> http://ghc.haskell.org/trac/ghc/ticket/7930.  It would not be related.
>>  There was a bug relating to `catchSTM` that was fixed recently:
>> http://ghc.haskell.org/trac/ghc/ticket/8035.  And another related to
>> profiling: http://ghc.haskell.org/trac/ghc/ticket/8298.  I doubt either
>> of these is related.  I'm happy to help narrow things down.
>>
>> Ryan
>>
>>
>> On Thu, Oct 17, 2013 at 4:39 AM, Simon Marlow <marlowsd at gmail.com> wrote:
>>
>>> On 17/10/2013 03:01, Andreas Voellmy wrote:
>>>
>>>> Hi all,
>>>>
>>>> I have a program that uses STM heavily and also performs lots of foreign
>>>> calls. I've noticed that sometimes the program uses 100% CPU
>>>> indefinitely and uses lots of memory - I see it go up to about 5GB
>>>> before I kill it. I've grabbed some preliminary samples of stack traces
>>>> and see lots stm related stuff (e.g. lots of stg_atomically_frame_info
>>>> and stmCommitTransaction entries).  I can pretty reliably get the
>>>> behavior to happen now by closing a socket that my Haskell program is
>>>> trying to recv from. When this causes an exception to be raised
>>>> (something like "recv: resource vanished (Connection reset by peer)") ,
>>>> then this behavior gets triggered.  I haven't pinned down the bug yet,
>>>> but I'm suspecting it is STM related - somehow the exception causes some
>>>> STM transaction to go wrong.
>>>>
>>>> Are there any known bugs that sound similar to this?
>>>>
>>>> BTW, this is with GHC 7.6.3 from a recent HP release on OS X.
>>>>
>>>
>>> Please create a ticket and dump all the information you have in it.
>>> There might be something we can tell from the stack trace, but if not we'll
>>> need a way to reproduce it.
>>>
>>> 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/20131107/0dc9a206/attachment.html>

From carter.schonwald at gmail.com  Fri Nov  8 01:07:06 2013
From: carter.schonwald at gmail.com (Carter Schonwald)
Date: Thu, 7 Nov 2013 20:07:06 -0500
Subject: simd branch ready for review/merge
In-Reply-To: <59543203684B2244980D7E4057D5FBC1485EA861@DB3EX14MBXC306.europe.corp.microsoft.com>
References: <5237590F.5040707@apeiron.net>
 <59543203684B2244980D7E4057D5FBC1485EA861@DB3EX14MBXC306.europe.corp.microsoft.com>
Message-ID: <CAHYVw0xz6jKcyPGgHoS5si0pPtpNuHSUrSE1D8AzJL0G16cuAg@mail.gmail.com>

Hey Simon (and everyone else),

regarding matter #1:  good idea!
the static literal idea i've been chewing on, if generalized to also make
sense in a DataKinds setting, would give the machinery for writing
something like "vecOf :: Static * -> Static Nat -> #" or something like
that.


On Fri, Sep 20, 2013 at 7:22 AM, Simon Peyton-Jones
<simonpj at microsoft.com>wrote:

> Geoff
>
> I'm too far from this stuff to give it a meaningful review, at least not
> without sitting beside you.  So I suggest you just merge it!  Simon Marlow
> may want to look.
>
> The wiki page http://ghc.haskell.org/trac/ghc/wiki/SIMD/Design describes
> the design, and I think it's up to date with your patches (correct?).
> Thanks for doing that!
>
> From our previous discussion, the bit I hate is this:
>
> 1 there are so many distinct data types (Int16x4, Int32x2, etc)
>
> 2 primops.txt.pp therefore has to grow a macro-like mechanism
>   to ameliorate the burden of writing out all the zillions of
>   types and primops
>
> Concerning (2), the obvious rejoinder is: well, primops.txt.pp is really a
> program written in a domain specific language -- and that language is
> getting more elaborate.  Solution: stop building a new language, and
> instead make primops.txt.pp into an embedded DSL in Haskell; just a Haskell
> program that we run to generate the various outputs.  Then all the
> mechanisms you had to add will be trivial.
>
> Concerning (1) what we want is a way to make types Int<16,4> where the
> parameters 16 and 4 are forced to be static literals, and where you
> absolutely do not get polymorphism like  f :: Int<a><b> -> blah.  There is
> some Trac discussion about this.
>
> It can't be that hard.  I'm copying some FC friends!
>
> Simon
>
>
> | -----Original Message-----
> | From: Geoffrey Mainland [mailto:mainland at apeiron.net]
> | Sent: 16 September 2013 20:17
> | To: Simon Peyton-Jones; Simon Marlow; Austin Seipp; ghc-devs at haskell.org
> | Subject: simd branch ready for review/merge
> |
> | The SIMD branch, available as wip/simd, is ready for review/merge. It
> | could use some review---Simon and Simon, I'd be especially grateful if
> | you both had a quick look. Some major points:
> |
> | 1) I have added support for AVX 512, although this is necessarily
> | untested. AVX and AVX2 are also both supported.
> |
> | 2) After the recent churn regarding patching LLVM's GHC calling
> | convention, by default only 128-bit wide SIMD vectors are passed in
> | registers, and then only on X86_64. There is a "hidden" flag,
> | -fllvm-pass-vectors-in-regs, that causes GHC to generate LLVM code that
> | assumes all vectors are passed in registers by LLVM. This can be used
> | with a suitably patched version of LLVM, and if we get LLVM 3.4 patched,
> | we can consider turning it on by default for LLVM 3.4+. This would mean
> | that we couldn't mix LLVM <3.3-compiled object files with LLVM
> | >3.4-compiled object files, but I don't see that as much of a problem.
> |
> | 3) utils/genprimcode has been hacked up to allow us to write vector
> | operations once and have them instantiated at multiple vector types. I'm
> | not thrilled with this solution, but after discussing with Simon PJ,
> | what I've implemented seems to be the minimal reasonable solution to the
> | problem of exploding primop boilerplate. The changes are documented in
> | compiler/prelude/primops.txt.pp.
> |
> | 4) Error handling is sub-optimal. My patch checks to make sure that
> | vector primops can be compiled efficiently based on the current set of
> | dynamic flags. For example, if -mavx is not specified and the user tries
> | to use a primop that adds together two 256-bit wide vectors of
> | double-precision elements, the user will see an error message like:
> |
> | ghc-stage2: sorry! (unimplemented feature or known bug)
> |   (GHC version 7.7.20130916 for x86_64-unknown-linux):
> |     256-bit wide floating point SIMD vector instructions require at
> | least -mavx.
> |
> | This is because the only good place to check for this kind of error is
> | during STG->Cmm translation (in compiler/codeGen/StgCmmPrim.hs), and we
> | don't have much of an error handling infrastructure there in contrast to
> | when we're working in the typechecking/renaming monad. If there is a
> | better way/place to do this, please let me know.
> |
> | Thanks,
> | Geoff
> _______________________________________________
> 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/20131107/cbba1f1d/attachment.html>

From andreas.voellmy at gmail.com  Fri Nov  8 05:02:40 2013
From: andreas.voellmy at gmail.com (Andreas Voellmy)
Date: Fri, 8 Nov 2013 00:02:40 -0500
Subject: GHC 7.8 release status
In-Reply-To: <CACYs5AZgQooitEm3Mtm2NnYpD9JYLMC0ZfgCtubYbrn1qnnLeA@mail.gmail.com>
References: <59543203684B2244980D7E4057D5FBC1485BD020@DB3EX14MBXC308.europe.corp.microsoft.com>
 <CACYs5AbC+SPCpa4qyVBbC-AztMiJ=OzLNmFne4pjnA_iRM58Pw@mail.gmail.com>
 <CAEs96n0HzaS_we9Xzxr=35P5H_eEda_SoV9RQrN0rUQzGTWqtQ@mail.gmail.com>
 <CACYs5AZgQooitEm3Mtm2NnYpD9JYLMC0ZfgCtubYbrn1qnnLeA@mail.gmail.com>
Message-ID: <CADdwyZmyG9Tedtxch_MNcRm6wkc4Oj=JJtY27=50XAWHhNRL-A@mail.gmail.com>

Yes, the parallel IO manager is new in 7.8. Thanks for reminding me of that
excessive system time issue. That's been nagging me for a while. Hopefully
I can find some time in the coming days to look at this again.

-Andi


On Wed, Sep 4, 2013 at 11:42 AM, Ryan Newton <rrnewton at gmail.com> wrote:

> By the way, the parallel IO manager is also new in 7.8 right?  I'm not
> sure but I think it may have something to do with the excessive system time
> bug I just filed:
>
>     http://ghc.haskell.org/trac/ghc/ticket/8224
>
>
>
> _______________________________________________
> 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/20131108/e07fcb46/attachment.html>

From marlowsd at gmail.com  Fri Nov  8 09:27:44 2013
From: marlowsd at gmail.com (Simon Marlow)
Date: Fri, 08 Nov 2013 09:27:44 +0000
Subject: Annotations
In-Reply-To: <59543203684B2244980D7E4057D5FBC14866C163@DB3EX14MBXC308.europe.corp.microsoft.com>
References: <59543203684B2244980D7E4057D5FBC14866C163@DB3EX14MBXC308.europe.corp.microsoft.com>
Message-ID: <527CAE90.8060003@gmail.com>

Simon, Austin and I discussed this briefly yesterday. There's an 
existing ticket:

   http://ghc.haskell.org/trac/ghc/ticket/4268

I added a comment to the ticket to summarise our conclusion: we won't 
add a flag for the pragma, however we should add a warning when an ANN 
pragma is being ignored.

On 06/11/2013 10:55, Simon Peyton-Jones wrote:
> I?ve just noticed that there is no GHC language extension for annotations
>
> http://www.haskell.org/ghc/docs/latest/html/users_guide/extending-ghc.html#annotation-pragmas
>
> That feels like an oversight. Yes, they are in a pragma, but you may get
> an error message if you compile with a stage-1 compiler, for example.
> Plus, the language extensions should truthfully report what extra stuff
> you are using.
>
> I?m inclined to add a language extension ?Annotations?.
>
> ?Without it {-# ANN ? #-} pragmas are ignored as comments
>
> ?With it, they are treated as annotations
>
> Do you agree?
>
> I don?t know whether this can (or even should) land in 7.8.1.  Do you
> care either way?
>
> Guidance welcome
>
> Simon
>
> /Microsoft Research Limited (company number 03369488) is registered in
> England and Wales /
>
> /Registered office is at 21 Station Road, Cambridge, CB1 2FB/
>
>
>
> _______________________________________________
> ghc-devs mailing list
> ghc-devs at haskell.org
> http://www.haskell.org/mailman/listinfo/ghc-devs
>

From rrnewton at gmail.com  Mon Nov 11 15:01:06 2013
From: rrnewton at gmail.com (Ryan Newton)
Date: Mon, 11 Nov 2013 10:01:06 -0500
Subject: Things stopping pure Haskell code from having a cross-platform single
 semantics?
Message-ID: <CACYs5AZG+v2yHeyDJ8tFdVTp=hp2BOnEekH_F3k3pgUmdb+G8A@mail.gmail.com>

Haskell isn't like Java byte code in having a single semantics for a
program irrespective of where it is run.  In particular, "Int" has a
platform-defined width -- so the same (pure) code can yield different
answers on different machines.

numCapabilities was also a "leak" of platform information, which did not
require IO. But, happily, now it does not appear in the [Trustworthy]
module, Control.Concurrent.

Ok, what else?  What other holes are there that allow my pure functions to
change their answer on different machines?  I'm making a list of these in a
paper and I want to make sure I give a full account.

Thanks,
  -Ryan
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/ghc-devs/attachments/20131111/d78515ba/attachment.html>

From nicolas.frisby at gmail.com  Mon Nov 11 19:47:12 2013
From: nicolas.frisby at gmail.com (Nicolas Frisby)
Date: Mon, 11 Nov 2013 13:47:12 -0600
Subject: Restrictions on polytypes with type families
In-Reply-To: <CAPNUp09eJ=p4pQotH4wnZPnpa4iadQt4WThZRqRT1q_upG-pyw@mail.gmail.com>
References: <0A145076-6176-47C8-B2BD-E0FE665D08D9@cis.upenn.edu>
 <59543203684B2244980D7E4057D5FBC1477C95B1@DB3EX14MBXC306.europe.corp.microsoft.com>
 <CAGK9nuqoVbY27OXjhVU_aSGP8O2oCMZBT=JzeXMuCaFHVMs61w@mail.gmail.com>
 <59543203684B2244980D7E4057D5FBC1477C96B6@DB3EX14MBXC306.europe.corp.microsoft.com>
 <AE82CBAA-A314-4A45-BA5D-DF328017E51C@cse.unsw.edu.au>
 <59543203684B2244980D7E4057D5FBC1477CB1E5@DB3EX14MBXC306.europe.corp.microsoft.com>
 <C0207498A084F14E85CA5D588539FA0F1304CBF0@DB3EX14MBXC311.europe.corp.microsoft.com>
 <CAPNUp09eJ=p4pQotH4wnZPnpa4iadQt4WThZRqRT1q_upG-pyw@mail.gmail.com>
Message-ID: <CADfHYo7UCv-nowJTPGFs25wabbiHmQN8QXTT64WUUq7vdbpN5w@mail.gmail.com>

Has there been any other discussions/write-ups regarding the issues in this
(stale) thread? In particular, I'm interested in polytypes on the RHS of
type family instances.

The rest of this email just explains my interest a bit and culiminates in a
more domain-specific and more open-response question.

I'd like to explore some generalizations of GHC.Generics, but I think I'll
need polytypes on the RHS of a type family instances.

For example, this type family is a step towards Hinze's "Polytypic Values
Possess Polykinded Types".

type family NatroN (t::k) (s::k) :: *

type instance NatroN t s = t -> s
type instance NatroN t s = forall x. NatroN (t x) -> (s x)

However, I'm not sure how I'd write an *equally general* type class for
creating/applying such a value. Perhaps these two combinators (which I
think would type-check) would help.

 lift1 :: (forall x. NatroN (t x) (s x)) -> NatroN t s
lift1 f = f


drop1 :: forall x. NatroN t s -> NatroN (t x) (s x)
drop1 f = f

I'm hoping these definitions might enable me to unify stacks of classes,
such as

class Functor1_1 t where fmap1_1 :: (a -> b) -> t a -> t b
class Functor1_2 t where fmap1_2 :: (a -> b) -> t a y -> t b y
class Functor2_1 t where
  fmap2_1 :: (forall x. a x -> b x) -> t a -> t b
class Functor2_2 t where
  fmap2_2 :: (forall x. a x -> b x) -> t a y -> t b y

into a single class such as

class FunctorPK t where
  fmapPK :: Proxy t -> Proxy a -> Natro a b -> Natro (t a) (t b)

So, an additional question: am I barking up the wrong tree? In other words,
is there an alternative to expressing these kinds of kind-polymorphic
values that is currently more workable?

Thank you for your time.

-----

PS Here's an optimistic guess at what instances of FunctorPK might look
like, omitting the proxies for now.

newtype Example g h a = Example {unExample :: g (h a) a)}
>


instance FunctorPK (g (h Int))

    => FunctorPK (Example g h) where

  fmapPK f = Example

           . fmapPK {- at g -} (fmapPK {- at h -} f) .

           . {- drop1 ? -} (fmapPK {- at g (h a) -} f))

           . unExample
>


instance FunctorPK g => FunctorPK (Example g) where
>   fmapPK f (Example x) = Example $ fmapPK {- at g -} ({- drop1 ? -} f) x
>

>
instance FunctorPK Example where
>   fmapPK f (Example x) = Example (f x)


Thanks again.


On Fri, Apr 5, 2013 at 1:32 PM, Dimitrios Vytiniotis <dimitris at microsoft.com
> wrote:

>  Hmm, no I don?t think that Flattening is a very serious problem:
>
> Firstly, we can somehow get around that if we use implication constraints
> and higher-order flattening
>
> variables. We have discussed that (but not implemented). For example.
>
>
>
> forall a. F [a] ~ G Int
>
>
>
> becomes:
>
>
>
> forall a.  fsk a ~ G Int
>
>
>
> forall a. true => fsk a ~ F [a]
>
>
>
> Secondly:  flattening under a Forall is not terribly important, unless you
> have type families that dispatch on
>
> polymorphic types, which is admittedly a rather rare case. We lose some
> completeness but that?s ok.
>
>
>
> For me, a more serious problem are polymorphic RHS, which give rise to
> exactly the same problems for type
>
> inference as impredicative polymorphism. For instance:
>
>
>
> type instance F Int = forall a. a -> [a]
>
>
>
> g :: F Int
>
> g = undefined
>
>
>
> main = g 3
>
>
>
> Should this type check or not? And then all our discussions about
> impredicativity, explicit type applications etc become
>
> relevant again.
>
>
>
> Thanks!
>
> d-
>

If the problem with foralls on the RHS is that it devolves into
ImpredicativeTypes, what about only allowing them when ImpredicativeTypes
is on?


>
>
>
>
>
>
>
>
>
> *From:* Simon Peyton-Jones
> *Sent:* Friday, April 05, 2013 8:24 AM
> *To:* Manuel M T Chakravarty
> *Cc:* Iavor Diatchki; ghc-devs; Dimitrios Vytiniotis
> *Subject:* RE: Restrictions on polytypes with type families
>
>
>
> Manuel has an excellent point. See the Note below in TcCanonical!   I have
> no clue how to deal with this
>
>
>
> Simon
>
>
>
> Note [Flattening under a forall]
>
> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
>
> Under a forall, we
>
>   (a) MUST apply the inert subsitution
>
>   (b) MUST NOT flatten type family applications
>
> Hence FMSubstOnly.
>
>
>
> For (a) consider   c ~ a, a ~ T (forall b. (b, [c])
>
> If we don't apply the c~a substitution to the second constraint
>
> we won't see the occurs-check error.
>
>
>
> For (b) consider  (a ~ forall b. F a b), we don't want to flatten
>
> to     (a ~ forall b.fsk, F a b ~ fsk)
>
> because now the 'b' has escaped its scope.  We'd have to flatten to
>
>        (a ~ forall b. fsk b, forall b. F a b ~ fsk b)
>
> and we have not begun to think about how to make that work!
>
>
>
>
>
> *From:* Manuel M T Chakravarty [mailto:chak at cse.unsw.edu.au<chak at cse.unsw.edu.au>]
>
> *Sent:* 04 April 2013 02:01
> *To:* Simon Peyton-Jones
> *Cc:* Iavor Diatchki; ghc-devs
> *Subject:* Re: Restrictions on polytypes with type families
>
>
>
> Simon Peyton-Jones <simonpj at microsoft.com>:
>
>  isn't this moving directly into the territory of impredicative types?
>
>
>
> Ahem, maybe you are right.  Impredicativity means that you can
>
>           *instantiate a type variable with a polytype*
>
>
>
> So if we allow, say (Eq (forall a.a->a)) then we?ve instantiated Eq?s type
> variable with a polytype.  Ditto Maybe (forall a. a->a).
>
>
>
> But this is only bad from an inference point of view, especially for
> implicit instantiation.  Eg if we had
>
>           class C a where
>
>             op :: Int -> a
>
>
>
> then if we have
>
>           f :: C (forall a. a->a) =>...
>
>           f = ...op...
>
>
>
> do we expect op to be polymorphic??
>
>
>
> For type families maybe things are easier because there is no implicit
> instantiation.
>
>
>
> But I?m not sure
>
>
>
> These kinds of issues are the reason that my conclusion at the time was
> (as Richard put it)
>
>
>
>    Or, are
> | there any that are restricted because someone needs to think hard before
> | lifting it, and no one has yet done that thinking?
>
>
>
> At the time, there were also problems with what the type equality solver
> was supposed to do with foralls.
>
>
>
> I know, for example,
> | that the unify function in types/Unify.lhs will have to be completed to
> | work with foralls, but this doesn't seem hard.
>
>
>
> The solver changed quite a bit since I rewrote Tom's original prototype.
> So, maybe it is easy now, but maybe it is more tricky than you think. The
> idea of rewriting complex terms into equalities at the point of each
> application of a type synonym family (aka type function) assumes that you
> can pull subterms out of a term into a separate equality, but how is this
> going to work if a forall is in the way?  E.g., given
>
>
>
>   type family F a :: *
>
>
>
> the equality
>
>
>
>   Maybe (forall a. F [a]) ~ G b
>
>
>
> would need to be broken down to
>
>
>
>   x ~  F [a], Maybe (forall a. x) ~ G b
>
>
>
> but you cannot do that, because you just moved 'a' out of its scope. Maybe
> you can move the forall out as well?
>
>
>
> Manuel
>
>
>
>
>
>
>
> _______________________________________________
> ghc-devs mailing list
> ghc-devs at haskell.org
> http://www.haskell.org/mailman/listinfo/ghc-devs
>
>


-- 
Your ship was destroyed in a monadic eruption.
_______________________________________________
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/20131111/4db54f78/attachment-0001.html>

From simonpj at microsoft.com  Mon Nov 11 21:49:38 2013
From: simonpj at microsoft.com (Simon Peyton-Jones)
Date: Mon, 11 Nov 2013 21:49:38 +0000
Subject: Finding & assembling class dictionaries from GHC plugins?
In-Reply-To: <CAD6SzR+UC7ePZY3+7dimz9h646bKD=VQ0pV6EcGLEsQAMbFudQ@mail.gmail.com>
References: <CAD6SzRJM0B-e_THKMPi7p_Jw56DTzAVMGQdbyo2sg3quVvWuNA@mail.gmail.com>
 <59543203684B2244980D7E4057D5FBC148669657@DB3EX14MBXC308.europe.corp.microsoft.com>
 <CADfHYo4GmvZWpOp4uMJFnauB5iwLNbQwOh7Tifsm9pC3VwpP=w@mail.gmail.com>
 <59543203684B2244980D7E4057D5FBC14866B421@DB3EX14MBXC308.europe.corp.microsoft.com>
 <CAD6SzRJt+q+SWJQFEguBaXkMM4N3i-jaWrzfJw7NFFFcXCscQg@mail.gmail.com>
 <59543203684B2244980D7E4057D5FBC14866C4F1@DB3EX14MBXC308.europe.corp.microsoft.com>
 <CAD6SzRLF1fXsRkSSjvm9gZRgUkUYMJt+QjXcRu2fY+6ur3XQCQ@mail.gmail.com>
 <59543203684B2244980D7E4057D5FBC14866D14D@DB3EX14MBXC308.europe.corp.microsoft.com>
 <CAD6SzR+UC7ePZY3+7dimz9h646bKD=VQ0pV6EcGLEsQAMbFudQ@mail.gmail.com>
Message-ID: <59543203684B2244980D7E4057D5FBC1486769E8@DB3EX14MBXC308.europe.corp.microsoft.com>

Conal

Email is not good for this.  I think it'd be more productive to have a Skype call, with both of use looking at GHC's source code.

If you'd like to do that, do suggest a time.

Simon

From: conal.elliott at gmail.com [mailto:conal.elliott at gmail.com] On Behalf Of Conal Elliott
Sent: 07 November 2013 18:15
To: Simon Peyton-Jones
Cc: Nicolas Frisby; ghc-devs at haskell.org
Subject: Re: Finding & assembling class dictionaries from GHC plugins?

On Wed, Nov 6, 2013 at 11:44 PM, Simon Peyton-Jones <simonpj at microsoft.com<mailto:simonpj at microsoft.com>> wrote:
Well, you are writing a function
                reify :: CoreExpr -> HsExpr RdrName

Not exactly. I'm reifying CoreExpr directly to another CoreExpr. (The target CoreExpr calls into an API for GADT-typed lambda terms<https://github.com/conal/lambda-ccc/blob/master/src/LambdaCCC/Lambda.hs>. All works swimmingly as long as I'm able to avoid dictionary construction, but I'm no longer able to do so.) I haven't explored your suggestion of translating to HsExpr instead. Do you know of any plugins that work this way? Do you really believe it would work out? For instance, I wouldn't know where to insert type annotations, and I'd have to back-translate names. I imagine there are other challenges I don't foresee.

It takes as its input a CoreExpr and produces as its output a reification of the input.  I don't see why you need start by converting Core to HsExpr. Just write reify directly!

I wasn't suggesting converting a CoreExpr to an HsExpr. Rather, I was wondering out loud how I might get the type-checker's help to generate Core to find/assemble a Typeable dictionary for a given Core type (since I'm starting with Core). One idea is translate the core type cty to an HsType hty, use hty in a very simple HsExpr like "Dict :: Dict hty" (where Dict is from Ed K's constraints package), use the typechecker to convert that simple HsExpr to a CoreExpr, and then extract the dictionary-forming sub-CoreExpr. Or something simpler along the same lines.
Thanks for the help,
-- Conal


Simon

From: conal.elliott at gmail.com<mailto:conal.elliott at gmail.com> [mailto:conal.elliott at gmail.com<mailto:conal.elliott at gmail.com>] On Behalf Of Conal Elliott
Sent: 07 November 2013 01:08

To: Simon Peyton-Jones
Cc: Nicolas Frisby; ghc-devs at haskell.org<mailto:ghc-devs at haskell.org>
Subject: Re: Finding & assembling class dictionaries from GHC plugins?

Thanks for the suggestion. I hadn't considered backing up to an HsExpr. I guess we'd have to start by converting the Core Type to an HsType to form a type-annotated HsExpr. Am I on the right track here?
-- Conal

On Wed, Nov 6, 2013 at 5:59 AM, Simon Peyton-Jones <simonpj at microsoft.com<mailto:simonpj at microsoft.com>> wrote:
Hmm. One route would be to build a HsExpr (rather than a CoreExpr) for the reification of your CoreExpr, and stick that into the maw of the type checker.  That would hand off all this dictionary construction to the type checker, which is designed for the purpose.

Simon

From: conal.elliott at gmail.com<mailto:conal.elliott at gmail.com> [mailto:conal.elliott at gmail.com<mailto:conal.elliott at gmail.com>] On Behalf Of Conal Elliott
Sent: 05 November 2013 23:41
To: Simon Peyton-Jones
Cc: Nicolas Frisby; ghc-devs at haskell.org<mailto:ghc-devs at haskell.org>
Subject: Re: Finding & assembling class dictionaries from GHC plugins?

Hi Simon,

Here's some context on what I'm after. I'll try to include enough to clarify what I'm after, without dragging you into unnecessary detail.

I have a Core expression, which I'm systematically translating to a related Core expression. The second one reifies the first one, so that the generated code *evaluates* to a run-time (not compile/Core-time) representation akin to the original Core expression. In this second (reified) representation, I need some run-time representation of types. I use Typeable constraints in my representation, and these constraints don't appear in the original Core representation. For instance, I have the following constructor for function application in a GADT of lambda expressions:

> (:^) :: (Typeable a, Typeable b) => E (a -> b) -> E a -> E b

My reification plugin takes a Core application expression, recursively reifies the function and argument expressions, and makes an expression that applies (:^) to the two recursive results. However--and the point of this thread--I also need to come up with Core expressions for the two Typeable dictionaries.

So, to clarify my request, given a Core type representation t, I want to construct a Core expression that evaluates to the dictionary for Typeable t if one exists, or fail if there isn't one. Note that t is not necessarily an atomic type; it could instead be something like [(Bool,Int -> String)].
I'm happy to Skype-chat if it'd help.
Thanks,  - Conal


On Tue, Nov 5, 2013 at 2:37 PM, Simon Peyton-Jones <simonpj at microsoft.com<mailto:simonpj at microsoft.com>> wrote:

We just don't know how to start - ie how call the right functions from the type checker. Are there any resources explaining the relevant subset of the TcRnIf API?
And I for my part don't know where to start helping you!  Conal wrote

I don't think I need to construct dictionaries for new Typeable instances. I only need to find and assemble *existing* Typeable instances into combinations like Typeable [(Bool,Int -> String)], and I don't know how to do so in a GHC plug-in

That's exactly what the constraint solver does.  (TcSimplify and friends.)  But again I need more context.

I gather you are talking to Pedro too?  He knows a lot about this stuff.

Also there are a bunch of folk (Luite, Edsko) worked on the new front-end plugin stuff, and are much more expert in it than me.

We could have a skype call if that would help

S


From: Nicolas Frisby [mailto:nicolas.frisby at gmail.com<mailto:nicolas.frisby at gmail.com>]
Sent: 05 November 2013 14:36
To: Simon Peyton-Jones
Cc: ghc-devs at haskell.org<mailto:ghc-devs at haskell.org>; Conal Elliott
Subject: RE: Finding & assembling class dictionaries from GHC plugins?


On Nov 5, 2013 3:14 AM, "Simon Peyton-Jones" <simonpj at microsoft.com<mailto:simonpj at microsoft.com>> wrote:

>
> A core-level plug-in can't generate fresh instances.  There are some new plug-in hooks that fit earlier in the pipeline, which can.  Maybe you can use that, and generate a data type decl with "deriving Typeable"?

We're willing to do some awkward shoehorning in HERMIT to make this work in limited circumstances. (Hopefully including Conal's.)

We just don't know how to start - ie how call the right functions from the type checker. Are there any resources explaining the relevant subset of the TcRnIf API?

Thanks.

>
>
> From: ghc-devs [mailto:ghc-devs-bounces at haskell.org<mailto:ghc-devs-bounces at haskell.org>] On Behalf Of Conal Elliott
> Sent: 04 November 2013 20:08
> To: ghc-devs at haskell.org<mailto:ghc-devs at haskell.org>
> Subject: Finding & assembling class dictionaries from GHC plugins?
>
>
>
> I'm working on a GHC plugin (for compiling Haskell to hardware), and I need to synthesize Typeable (and maybe other) class dictionaries for a wide range of types, including composite types (functions, pairs, lists, etc). Can it be done, and how? I think I'm mainly looking for mechanics of finding existing class instances (however they're defined) and assembling them (for parametrized/composite dictionaries), rather than mechanisms specific to Typeable.
>
> Thanks, -- Conal
>
>
> _______________________________________________
> ghc-devs mailing list
> ghc-devs at haskell.org<mailto: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/20131111/6154ce54/attachment-0001.html>

From simonpj at microsoft.com  Mon Nov 11 22:10:04 2013
From: simonpj at microsoft.com (Simon Peyton-Jones)
Date: Mon, 11 Nov 2013 22:10:04 +0000
Subject: Windows build
Message-ID: <59543203684B2244980D7E4057D5FBC148676A5F@DB3EX14MBXC308.europe.corp.microsoft.com>

Austin, or others,
It would be SO GREAT if it was possible to validate on Windows again.
Currently I'm using msys2, which builds GHC fine, but things fail badly in the testsuite.

Traceback (most recent call last):

  File "../driver/runtests.py", line 144, in <module>

    raise Exception("Can't detect Windows terminal type")

Exception: Can't detect Windows terminal type

uname -s returns MINGW_NT-6.2
Changing the test from
    elif v.startswith("MINGW32"):
to
    elif v.startswith("MINGW"):
just produces a new error

Traceback (most recent call last):

  File "../driver/runtests.py", line 155, in <module>

    mydll = ctypes.windll

AttributeError: 'module' object has no attribute 'windll'

../mk/test.mk:242: recipe for target 'test' failed

It's all very frustrating because I can't validate.  Can anyone help?
Simon


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

From conal at conal.net  Tue Nov 12 00:35:48 2013
From: conal at conal.net (Conal Elliott)
Date: Mon, 11 Nov 2013 16:35:48 -0800
Subject: Things stopping pure Haskell code from having a cross-platform
 single semantics?
In-Reply-To: <CACYs5AZG+v2yHeyDJ8tFdVTp=hp2BOnEekH_F3k3pgUmdb+G8A@mail.gmail.com>
References: <CACYs5AZG+v2yHeyDJ8tFdVTp=hp2BOnEekH_F3k3pgUmdb+G8A@mail.gmail.com>
Message-ID: <CAD6SzRKB3FpaEtmTD_7oH4CGNpwCkOD6x8=Jv60+a5EBGJdAKQ@mail.gmail.com>

For a few more such leaks, see
http://hackage.haskell.org/package/base-4.6.0.1/docs/System-Info.html , as
mentioned in http://conal.net/blog/posts/notions-of-purity-in-haskell .  --
Conal


On Mon, Nov 11, 2013 at 7:01 AM, Ryan Newton <rrnewton at gmail.com> wrote:

> Haskell isn't like Java byte code in having a single semantics for a
> program irrespective of where it is run.  In particular, "Int" has a
> platform-defined width -- so the same (pure) code can yield different
> answers on different machines.
>
> numCapabilities was also a "leak" of platform information, which did not
> require IO. But, happily, now it does not appear in the [Trustworthy]
> module, Control.Concurrent.
>
> Ok, what else?  What other holes are there that allow my pure functions to
> change their answer on different machines?  I'm making a list of these in a
> paper and I want to make sure I give a full account.
>
> Thanks,
>   -Ryan
>
>
> _______________________________________________
> 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/20131111/c3ab51c9/attachment.html>

From kyrab at mail.ru  Tue Nov 12 06:45:17 2013
From: kyrab at mail.ru (kyra)
Date: Tue, 12 Nov 2013 10:45:17 +0400
Subject: Windows build
In-Reply-To: <59543203684B2244980D7E4057D5FBC148676A5F@DB3EX14MBXC308.europe.corp.microsoft.com>
References: <59543203684B2244980D7E4057D5FBC148676A5F@DB3EX14MBXC308.europe.corp.microsoft.com>
Message-ID: <5281CE7D.3050208@mail.ru>

I've looked into this.

Current test script picks msys2-compiled python, which, after your 
modification, can't find 'windll', because msys2-compiled python is 
cygwin-like and it's 'ctypes' has no 'windll'. If we rewrite the 
relevant part of script thus:

config.msys2 = False
....
     elif v.startswith("MINGW"):
         config.msys2 = True
....
# Try to use UTF8
if windows:
     import ctypes
     if config.cygwin or config.msys2:
         # Is this actually right? Which calling convention does it use?
         # As of the time of writing, ctypes.windll doesn't exist in the
         # cygwin python, anyway.
         mydll = ctypes.cdll
     else:
         mydll = ctypes.windll

then we go slightly further and fail with:

Traceback (most recent call last):
   File "../driver/runtests.py", line 151, in <module>
     import ctypes
   File "/usr/lib/python2.7/ctypes/__init__.py", line 451, in <module>
     pythonapi = PyDLL("libpython%d.%d.dll" % _sys.version_info[:2])
   File "/usr/lib/python2.7/ctypes/__init__.py", line 365, in __init__
     self._handle = _dlopen(self._name, mode)
OSError: No such file or directory

And this is definitely a bug in msys2 python, because there is no such a 
file ("libpython*.dll) anywhere in msys2 distribution.

What could be possible solutions?

1. I'm seeing a new version of Msys2 appearing right now here 
http://sourceforge.net/projects/msys2/files/REPOS/MSYS2/i686/. It is now 
a bunch of separate packages, I've looked into python 2.7.5 package and 
found ctypes-related things definitely changed. Thus we could wait a 
couple of days until Msys2 release process is finished and installation 
information is available, hoping it's python is working properly.

2. Another approach is to modify testing infrastructure to use some pure 
win32/mingw based python distribution. But I'm in no way an expert here, 
sorry.

Cheers,
Kyra


On 11/12/2013 02:10, Simon Peyton-Jones wrote:
>
> Austin, or others,
>
> It would be SO GREAT if it was possible to validate on Windows again.
>
> Currently I'm using msys2, which builds GHC fine, but things fail 
> badly in the testsuite.
>
> Traceback (most recent call last):
>
>   File "../driver/runtests.py", line 144, in <module>
>
>     raise Exception("Can't detect Windows terminal type")
>
> Exception: Can't detect Windows terminal type
>
> uname --s returns MINGW_NT-6.2
>
> Changing the test from
>
>     elif v.startswith("MINGW32"):
>
> to
>
> elif v.startswith("MINGW"):
>
> just produces a new error
>
> Traceback (most recent call last):
>
>   File "../driver/runtests.py", line 155, in <module>
>
>     mydll = ctypes.windll
>
> AttributeError: 'module' object has no attribute 'windll'
>
> ../mk/test.mk:242: recipe for target 'test' failed
>
> It's all very frustrating because I can't validate.  Can anyone help?
>
> 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/20131112/3602eaf6/attachment-0001.html>

From simonpj at microsoft.com  Tue Nov 12 08:58:48 2013
From: simonpj at microsoft.com (Simon Peyton-Jones)
Date: Tue, 12 Nov 2013 08:58:48 +0000
Subject: Windows build
In-Reply-To: <5281CE7D.3050208@mail.ru>
References: <59543203684B2244980D7E4057D5FBC148676A5F@DB3EX14MBXC308.europe.corp.microsoft.com>
 <5281CE7D.3050208@mail.ru>
Message-ID: <59543203684B2244980D7E4057D5FBC148677390@DB3EX14MBXC308.europe.corp.microsoft.com>

Thanks Kyra, you are a star.
Yes, msys2 has been updated to fix the ctypes bug.  I have the version from 20131022.
With your edit I now get this:

Traceback (most recent call last):

  File "../driver/runtests.py", line 164, in <module>

    if mydll.kernel32.SetConsoleCP(65001) == 0:

  File "/usr/lib/python2.7/ctypes/__init__.py", line 435, in __getattr__

    dll = self._dlltype(name)

  File "/usr/lib/python2.7/ctypes/__init__.py", line 365, in __init__

    self._handle = _dlopen(self._name, mode)

OSError: No such file or directory

Any ideas about what to do now?  I guess you can reproduce if you install the later msys2.
thanks
Simon

From: ghc-devs [mailto:ghc-devs-bounces at haskell.org] On Behalf Of kyra
Sent: 12 November 2013 06:45
To: ghc-devs at haskell.org
Subject: Re: Windows build

I've looked into this.

Current test script picks msys2-compiled python, which, after your modification, can't find 'windll', because msys2-compiled python is cygwin-like and it's 'ctypes' has no 'windll'. If we rewrite the relevant part of script thus:

config.msys2 = False
....
    elif v.startswith("MINGW"):
        config.msys2 = True
....
# Try to use UTF8
if windows:
    import ctypes
    if config.cygwin or config.msys2:
        # Is this actually right? Which calling convention does it use?
        # As of the time of writing, ctypes.windll doesn't exist in the
        # cygwin python, anyway.
        mydll = ctypes.cdll
    else:
        mydll = ctypes.windll

then we go slightly further and fail with:

Traceback (most recent call last):
  File "../driver/runtests.py", line 151, in <module>
    import ctypes
  File "/usr/lib/python2.7/ctypes/__init__.py", line 451, in <module>
    pythonapi = PyDLL("libpython%d.%d.dll" % _sys.version_info[:2])
  File "/usr/lib/python2.7/ctypes/__init__.py", line 365, in __init__
    self._handle = _dlopen(self._name, mode)
OSError: No such file or directory

And this is definitely a bug in msys2 python, because there is no such a file ("libpython*.dll) anywhere in msys2 distribution.

What could be possible solutions?

1. I'm seeing a new version of Msys2 appearing right now here http://sourceforge.net/projects/msys2/files/REPOS/MSYS2/i686/. It is now a bunch of separate packages, I've looked into python 2.7.5 package and found ctypes-related things definitely changed. Thus we could wait a couple of days until Msys2 release process is finished and installation information is available, hoping it's python is working properly.

2. Another approach is to modify testing infrastructure to use some pure win32/mingw based python distribution. But I'm in no way an expert here, sorry.

Cheers,
Kyra


On 11/12/2013 02:10, Simon Peyton-Jones wrote:
Austin, or others,
It would be SO GREAT if it was possible to validate on Windows again.
Currently I'm using msys2, which builds GHC fine, but things fail badly in the testsuite.

Traceback (most recent call last):

  File "../driver/runtests.py", line 144, in <module>

    raise Exception("Can't detect Windows terminal type")

Exception: Can't detect Windows terminal type

uname -s returns MINGW_NT-6.2
Changing the test from
    elif v.startswith("MINGW32"):
to
    elif v.startswith("MINGW"):
just produces a new error

Traceback (most recent call last):

  File "../driver/runtests.py", line 155, in <module>

    mydll = ctypes.windll

AttributeError: 'module' object has no attribute 'windll'

../mk/test.mk:242: recipe for target 'test' failed

It's all very frustrating because I can't validate.  Can anyone help?
Simon






_______________________________________________

ghc-devs mailing list

ghc-devs at haskell.org<mailto: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/20131112/f794c880/attachment.html>

From kyrab at mail.ru  Tue Nov 12 09:38:30 2013
From: kyrab at mail.ru (kyra)
Date: Tue, 12 Nov 2013 13:38:30 +0400
Subject: Windows build
In-Reply-To: <59543203684B2244980D7E4057D5FBC148677390@DB3EX14MBXC308.europe.corp.microsoft.com>
References: <59543203684B2244980D7E4057D5FBC148676A5F@DB3EX14MBXC308.europe.corp.microsoft.com>
 <5281CE7D.3050208@mail.ru>
 <59543203684B2244980D7E4057D5FBC148677390@DB3EX14MBXC308.europe.corp.microsoft.com>
Message-ID: <5281F716.2020308@mail.ru>

It looks the second option (native win32 python) works.

I've installed native win32 python, reverted my edit, leaving only 
*your* edit in place, *and* disabled msys2 python simply moving all 
msys2 python executables out of the path. It seems, all works now (I 
didn't wait the finish of tests, though).

Cheers,
Kyra


On 11/12/2013 12:58, Simon Peyton-Jones wrote:
>
> Thanks Kyra, you are a star.
>
> Yes, msys2 has been updated to fix the ctypes bug.  I have the version 
> from 20131022.
>
> With your edit I now get this:
>
> Traceback (most recent call last):
>
> File "../driver/runtests.py", line 164, in <module>
>
> if mydll.kernel32.SetConsoleCP(65001) == 0:
>
> File "/usr/lib/python2.7/ctypes/__init__.py", line 435, in __getattr__
>
> dll = self._dlltype(name)
>
> File "/usr/lib/python2.7/ctypes/__init__.py", line 365, in __init__
>
> self._handle = _dlopen(self._name, mode)
>
> OSError: No such file or directory
>
> Any ideas about what to do now?  I guess you can reproduce if you 
> install the later msys2.
>
> thanks
>
> Simon
>
> *From:*ghc-devs [mailto:ghc-devs-bounces at haskell.org] *On Behalf Of *kyra
> *Sent:* 12 November 2013 06:45
> *To:* ghc-devs at haskell.org
> *Subject:* Re: Windows build
>
> I've looked into this.
>
> Current test script picks msys2-compiled python, which, after your 
> modification, can't find 'windll', because msys2-compiled python is 
> cygwin-like and it's 'ctypes' has no 'windll'. If we rewrite the 
> relevant part of script thus:
>
> config.msys2 = False
> ....
>     elif v.startswith("MINGW"):
>         config.msys2 = True
> ....
> # Try to use UTF8
> if windows:
>     import ctypes
>     if config.cygwin or config.msys2:
>         # Is this actually right? Which calling convention does it use?
>         # As of the time of writing, ctypes.windll doesn't exist in the
>         # cygwin python, anyway.
>         mydll = ctypes.cdll
>     else:
>         mydll = ctypes.windll
>
> then we go slightly further and fail with:
>
> Traceback (most recent call last):
>   File "../driver/runtests.py", line 151, in <module>
>     import ctypes
>   File "/usr/lib/python2.7/ctypes/__init__.py", line 451, in <module>
>     pythonapi = PyDLL("libpython%d.%d.dll" % _sys.version_info[:2])
>   File "/usr/lib/python2.7/ctypes/__init__.py", line 365, in __init__
>     self._handle = _dlopen(self._name, mode)
> OSError: No such file or directory
>
> And this is definitely a bug in msys2 python, because there is no such 
> a file ("libpython*.dll) anywhere in msys2 distribution.
>
> What could be possible solutions?
>
> 1. I'm seeing a new version of Msys2 appearing right now here 
> http://sourceforge.net/projects/msys2/files/REPOS/MSYS2/i686/. It is 
> now a bunch of separate packages, I've looked into python 2.7.5 
> package and found ctypes-related things definitely changed. Thus we 
> could wait a couple of days until Msys2 release process is finished 
> and installation information is available, hoping it's python is 
> working properly.
>
> 2. Another approach is to modify testing infrastructure to use some 
> pure win32/mingw based python distribution. But I'm in no way an 
> expert here, sorry.
>
> Cheers,
> Kyra
>
>
> On 11/12/2013 02:10, Simon Peyton-Jones wrote:
>
>     Austin, or others,
>
>     It would be SO GREAT if it was possible to validate on Windows again.
>
>     Currently I'm using msys2, which builds GHC fine, but things fail
>     badly in the testsuite.
>
>     Traceback (most recent call last):
>
>       File "../driver/runtests.py", line 144, in <module>
>
>         raise Exception("Can't detect Windows terminal type")
>
>     Exception: Can't detect Windows terminal type
>
>     uname --s returns MINGW_NT-6.2
>
>     Changing the test from
>
>         elif v.startswith("MINGW32"):
>
>     to
>
>     elif v.startswith("MINGW"):
>
>     just produces a new error
>
>     Traceback (most recent call last):
>
>       File "../driver/runtests.py", line 155, in <module>
>
>         mydll = ctypes.windll
>
>     AttributeError: 'module' object has no attribute 'windll'
>
>     ../mk/test.mk:242: recipe for target 'test' failed
>
>     It's all very frustrating because I can't validate.  Can anyone help?
>
>     Simon
>
>
>
>
>     _______________________________________________
>
>     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

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

From edskodevries at gmail.com  Tue Nov 12 10:36:51 2013
From: edskodevries at gmail.com (Edsko de Vries)
Date: Tue, 12 Nov 2013 10:36:51 +0000
Subject: Pattern match failure in StgCmmExpr.hs when adding new out-of-line
 primop
Message-ID: <CAETJ90Q5uvdnOR5LbuA_oNyxNkuaRi4p9wM9D+95jpxzd44mKA@mail.gmail.com>

Hi guys,

I'm trying to add a new primop; as a starting point I just copied the
definition of "catch#" in primops.txt.pp and renamed "catch#" to
"catchRethrow#", and added the corresponding declarations following
https://ghc.haskell.org/trac/ghc/wiki/Commentary/PrimOps#AddinganewPrimOp
; however, when I do this, I get

ghc-stage1: panic! (the 'impossible' happened)
  (GHC version 7.7.20131108 for x86_64-apple-darwin):
  compiler/codeGen/StgCmmExpr.hs:508:15-48: Irrefutable pattern failed
for pattern (CoreSyn.DEFAULT, deflt)

I can't quite figure out why that is happening and how I should
address it. Any suggestions?

Thanks!

-E

From edskodevries at gmail.com  Tue Nov 12 11:02:16 2013
From: edskodevries at gmail.com (Edsko de Vries)
Date: Tue, 12 Nov 2013 11:02:16 +0000
Subject: Pattern match failure in StgCmmExpr.hs when adding new
 out-of-line primop
In-Reply-To: <528206AA.7040504@student.chalmers.se>
References: <CAETJ90Q5uvdnOR5LbuA_oNyxNkuaRi4p9wM9D+95jpxzd44mKA@mail.gmail.com>
 <528206AA.7040504@student.chalmers.se>
Message-ID: <CAETJ90T7Ge1+tU9+DtZtCrX9ZHECb05WnvWN4fBYj=Gqc3weKw@mail.gmail.com>

Hi Arash,

On Tue, Nov 12, 2013 at 10:44 AM, Arash Rouhani <rarash at student.chalmers.se>
 wrote:

> I'm really curious why you want a "catchRethrow". I'm tempted to add such
> a primop myself since I'm working on problems with stack traces. I'm really
> interested in what use-case you had in mind.
>

I'm working on dealing with problems with re-throwing asynchronous
exceptions, especially in the context of using unsafePerformIO (see #8006
and the other tickets I reference there at the top). The catchRethrow I'm
playing with is supposed to be used something like

threadCode :: IO ()
threadCode = catch (print notReallyPure) outerHandler
  where
    outerHandler :: SomeException -> IO ()
    outerHandler e = logMsg $ "Outer handler: " ++ show e

notReallyPure :: Integer
notReallyPure = unsafePerformIO $
    catchRethrow (go 10) innerHandler
  where
    go :: Integer -> IO Integer
    go 0 = return 1234
    go n = do logMsg (show n)
              threadDelay 100000
              go (n - 1)

    innerHandler :: SomeException -> IO Integer -> IO Integer
    innerHandler e rethrow = do
      logMsg $ "Inner handler: " ++ show e
      rethrow

logMsg :: String -> IO ()
logMsg str = do
  tid <- myThreadId
  putStrLn $ show tid ++ ": " ++ str

Given this main:

main :: IO ()
main = do
  a1 <- async threadCode
  a2 <- async threadCode
  threadDelay 500000
  cancel a1
  wait a2
  return ()

It should be the case that when thread a1 gets interrupted, thread a2 can
continue evaluating the notReallyPure thunk without getting either an
exception and without redoing any work. In other words, the output of this
main should look like

ThreadId 2: 10
ThreadId 2: 9
ThreadId 2: 8
ThreadId 2: 7
ThreadId 2: 6
ThreadId 2: Inner handler: thread killed
ThreadId 2: Outer handler: thread killed
ThreadId 3: 5
ThreadId 3: 4
ThreadId 3: 3
ThreadId 3: 2
ThreadId 3: 1
1234

-E
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/ghc-devs/attachments/20131112/5404c4ff/attachment.html>

From edskodevries at gmail.com  Tue Nov 12 12:09:01 2013
From: edskodevries at gmail.com (Edsko de Vries)
Date: Tue, 12 Nov 2013 12:09:01 +0000
Subject: Pattern match failure in StgCmmExpr.hs when adding new
 out-of-line primop
In-Reply-To: <CAETJ90Q5uvdnOR5LbuA_oNyxNkuaRi4p9wM9D+95jpxzd44mKA@mail.gmail.com>
References: <CAETJ90Q5uvdnOR5LbuA_oNyxNkuaRi4p9wM9D+95jpxzd44mKA@mail.gmail.com>
Message-ID: <CAETJ90TVz=DtsgMDN--c0fSdkH9d+tc0dxNNQqVC-LDPMaPFjA@mail.gmail.com>

Hmmm,  a completely clean build seems to have resolved the issue.
Indicative of a Makefile problem somewhere?

-E


On Tue, Nov 12, 2013 at 10:36 AM, Edsko de Vries <edskodevries at gmail.com>wrote:

> Hi guys,
>
> I'm trying to add a new primop; as a starting point I just copied the
> definition of "catch#" in primops.txt.pp and renamed "catch#" to
> "catchRethrow#", and added the corresponding declarations following
> https://ghc.haskell.org/trac/ghc/wiki/Commentary/PrimOps#AddinganewPrimOp
> ; however, when I do this, I get
>
> ghc-stage1: panic! (the 'impossible' happened)
>   (GHC version 7.7.20131108 for x86_64-apple-darwin):
>   compiler/codeGen/StgCmmExpr.hs:508:15-48: Irrefutable pattern failed
> for pattern (CoreSyn.DEFAULT, deflt)
>
> I can't quite figure out why that is happening and how I should
> address it. Any suggestions?
>
> Thanks!
>
> -E
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/ghc-devs/attachments/20131112/e3bb21a4/attachment.html>

From simonpj at microsoft.com  Tue Nov 12 15:24:21 2013
From: simonpj at microsoft.com (Simon Peyton-Jones)
Date: Tue, 12 Nov 2013 15:24:21 +0000
Subject: Trac formatting
Message-ID: <59543203684B2244980D7E4057D5FBC148677A0A@DB3EX14MBXC308.europe.corp.microsoft.com>

When Trac formats commit messages it is doing a terrible job.  See for example: https://ghc.haskell.org/trac/ghc/ticket/5996
The commit message is nigh illegible until typeset without makup (see comment 10).
Could this be done automatically?

Simon

Microsoft Research Limited (company number 03369488) is registered in England and Wales
Registered office is at 21 Station Road, Cambridge, CB1 2FB

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

From mail at joachim-breitner.de  Tue Nov 12 15:53:05 2013
From: mail at joachim-breitner.de (Joachim Breitner)
Date: Tue, 12 Nov 2013 16:53:05 +0100
Subject: Trac formatting
In-Reply-To: <59543203684B2244980D7E4057D5FBC148677A0A@DB3EX14MBXC308.europe.corp.microsoft.com>
References: <59543203684B2244980D7E4057D5FBC148677A0A@DB3EX14MBXC308.europe.corp.microsoft.com>
Message-ID: <1384271585.2456.37.camel@kirk>

Hi,

Am Dienstag, den 12.11.2013, 15:24 +0000 schrieb Simon Peyton-Jones:
> When Trac formats commit messages it is doing a terrible job.  See for
> example: https://ghc.haskell.org/trac/ghc/ticket/5996
> 
> The commit message is nigh illegible until typeset without makup (see
> comment 10).

I believe it is a feature, not a bug: Trac encourages you to use
markdown markup (which supposedly looks good also in plain text) in your
commit messages. This not only makes them look nice, provides additional
features like automatic linking (compare the reference to #5996 in
comment 9 and comment 10).

In this case the tables should have been indented by 4 spaces, or
surrounded by {{{..}}}, in the commit message to make it come out
nicely.

Whether this is desirable is a different question. I like it, but the
heavy users of the repository and trac need to decide what they prefer ?
the ability to use markup in the commit messages, or the freedom to do
any kind of ascii art.

Greetings,
Joachim


-- 
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: 198 bytes
Desc: This is a digitally signed message part
URL: <http://www.haskell.org/pipermail/ghc-devs/attachments/20131112/865e6dbe/attachment.sig>

From eir at cis.upenn.edu  Tue Nov 12 16:14:40 2013
From: eir at cis.upenn.edu (Richard Eisenberg)
Date: Tue, 12 Nov 2013 11:14:40 -0500
Subject: Restrictions on polytypes with type families
In-Reply-To: <CADfHYo7UCv-nowJTPGFs25wabbiHmQN8QXTT64WUUq7vdbpN5w@mail.gmail.com>
References: <0A145076-6176-47C8-B2BD-E0FE665D08D9@cis.upenn.edu>
 <59543203684B2244980D7E4057D5FBC1477C95B1@DB3EX14MBXC306.europe.corp.microsoft.com>
 <CAGK9nuqoVbY27OXjhVU_aSGP8O2oCMZBT=JzeXMuCaFHVMs61w@mail.gmail.com>
 <59543203684B2244980D7E4057D5FBC1477C96B6@DB3EX14MBXC306.europe.corp.microsoft.com>
 <AE82CBAA-A314-4A45-BA5D-DF328017E51C@cse.unsw.edu.au>
 <59543203684B2244980D7E4057D5FBC1477CB1E5@DB3EX14MBXC306.europe.corp.microsoft.com>
 <C0207498A084F14E85CA5D588539FA0F1304CBF0@DB3EX14MBXC311.europe.corp.microsoft.com>
 <CAPNUp09eJ=p4pQotH4wnZPnpa4iadQt4WThZRqRT1q_upG-pyw@mail.gmail.com>
 <CADfHYo7UCv-nowJTPGFs25wabbiHmQN8QXTT64WUUq7vdbpN5w@mail.gmail.com>
Message-ID: <5A437DA0-EAA0-4544-BCC9-2CBBEBD8562C@cis.upenn.edu>

I'm unaware of any progress on this front since the thread died out. I don't really think I have time to get too involved in an answer, but I'd be quite keen to hear of one!

Richard

On Nov 11, 2013, at 2:47 PM, Nicolas Frisby wrote:

> Has there been any other discussions/write-ups regarding the issues in this (stale) thread? In particular, I'm interested in polytypes on the RHS of type family instances.
> 
> The rest of this email just explains my interest a bit and culiminates in a more domain-specific and more open-response question.
> 
> I'd like to explore some generalizations of GHC.Generics, but I think I'll need polytypes on the RHS of a type family instances.
> 
> For example, this type family is a step towards Hinze's "Polytypic Values Possess Polykinded Types".
> 
> type family NatroN (t::k) (s::k) :: *
> type instance NatroN t s = t -> s
> type instance NatroN t s = forall x. NatroN (t x) -> (s x)
> 
> However, I'm not sure how I'd write an *equally general* type class for creating/applying such a value. Perhaps these two combinators (which I think would type-check) would help.
> 
> lift1 :: (forall x. NatroN (t x) (s x)) -> NatroN t s
> lift1 f = f
>  
> drop1 :: forall x. NatroN t s -> NatroN (t x) (s x)
> drop1 f = f
> 
> I'm hoping these definitions might enable me to unify stacks of classes, such as
> 
> class Functor1_1 t where fmap1_1 :: (a -> b) -> t a -> t b
> class Functor1_2 t where fmap1_2 :: (a -> b) -> t a y -> t b y
> class Functor2_1 t where
>   fmap2_1 :: (forall x. a x -> b x) -> t a -> t b
> class Functor2_2 t where
>   fmap2_2 :: (forall x. a x -> b x) -> t a y -> t b y
> 
> into a single class such as
> 
> class FunctorPK t where
>   fmapPK :: Proxy t -> Proxy a -> Natro a b -> Natro (t a) (t b)
> 
> So, an additional question: am I barking up the wrong tree? In other words, is there an alternative to expressing these kinds of kind-polymorphic values that is currently more workable?
> 
> Thank you for your time.
> 
> -----
> 
> PS Here's an optimistic guess at what instances of FunctorPK might look like, omitting the proxies for now.
> 
> newtype Example g h a = Example {unExample :: g (h a) a)}
>  
> instance FunctorPK (g (h Int))
>     => FunctorPK (Example g h) where
>   fmapPK f = Example
>            . fmapPK {- at g -} (fmapPK {- at h -} f) .
>            . {- drop1 ? -} (fmapPK {- at g (h a) -} f))
>            . unExample
>  
> instance FunctorPK g => FunctorPK (Example g) where
>   fmapPK f (Example x) = Example $ fmapPK {- at g -} ({- drop1 ? -} f) x
>  
> instance FunctorPK Example where
>   fmapPK f (Example x) = Example (f x)
> 
> Thanks again.
> 
> 
> On Fri, Apr 5, 2013 at 1:32 PM, Dimitrios Vytiniotis <dimitris at microsoft.com> wrote:
> Hmm, no I don?t think that Flattening is a very serious problem:
> 
> Firstly, we can somehow get around that if we use implication constraints and higher-order flattening
> 
> variables. We have discussed that (but not implemented). For example.
> 
>  
> forall a. F [a] ~ G Int
> 
>  
> becomes:
> 
>  
> forall a.  fsk a ~ G Int
> 
>  
> forall a. true => fsk a ~ F [a]
> 
>  
> Secondly:  flattening under a Forall is not terribly important, unless you have type families that dispatch on
> 
> polymorphic types, which is admittedly a rather rare case. We lose some completeness but that?s ok.
> 
>  
> For me, a more serious problem are polymorphic RHS, which give rise to exactly the same problems for type
> 
> inference as impredicative polymorphism. For instance:
> 
>  
> type instance F Int = forall a. a -> [a]
> 
>  
> g :: F Int
> 
> g = undefined
> 
>  
> main = g 3
> 
>  
> Should this type check or not? And then all our discussions about impredicativity, explicit type applications etc become
> 
> relevant again.
> 
>  
> Thanks!
> 
> d-
> 
> 
> If the problem with foralls on the RHS is that it devolves into ImpredicativeTypes, what about only allowing them when ImpredicativeTypes is on?
> 
>  
>  
>  
>  
>  
> From: Simon Peyton-Jones 
> Sent: Friday, April 05, 2013 8:24 AM
> To: Manuel M T Chakravarty
> Cc: Iavor Diatchki; ghc-devs; Dimitrios Vytiniotis
> Subject: RE: Restrictions on polytypes with type families
> 
>  
> Manuel has an excellent point. See the Note below in TcCanonical!   I have no clue how to deal with this
> 
>  
> Simon
> 
>  
> Note [Flattening under a forall]
> 
> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> 
> Under a forall, we
> 
>   (a) MUST apply the inert subsitution
> 
>   (b) MUST NOT flatten type family applications
> 
> Hence FMSubstOnly.
> 
>  
> For (a) consider   c ~ a, a ~ T (forall b. (b, [c])
> 
> If we don't apply the c~a substitution to the second constraint
> 
> we won't see the occurs-check error.
> 
>  
> For (b) consider  (a ~ forall b. F a b), we don't want to flatten
> 
> to     (a ~ forall b.fsk, F a b ~ fsk)
> 
> because now the 'b' has escaped its scope.  We'd have to flatten to
> 
>        (a ~ forall b. fsk b, forall b. F a b ~ fsk b)
> 
> and we have not begun to think about how to make that work!
> 
>  
>  
> From: Manuel M T Chakravarty [mailto:chak at cse.unsw.edu.au] 
> Sent: 04 April 2013 02:01
> To: Simon Peyton-Jones
> Cc: Iavor Diatchki; ghc-devs
> Subject: Re: Restrictions on polytypes with type families
> 
>  
> Simon Peyton-Jones <simonpj at microsoft.com>:
> 
> isn't this moving directly into the territory of impredicative types?  
> 
>  
> Ahem, maybe you are right.  Impredicativity means that you can
> 
>           instantiate a type variable with a polytype
> 
>                                               
> So if we allow, say (Eq (forall a.a->a)) then we?ve instantiated Eq?s type variable with a polytype.  Ditto Maybe (forall a. a->a).
> 
>  
> But this is only bad from an inference point of view, especially for implicit instantiation.  Eg if we had
> 
>           class C a where
> 
>             op :: Int -> a
> 
>  
> then if we have
> 
>           f :: C (forall a. a->a) =>...
> 
>           f = ...op...
> 
>  
> do we expect op to be polymorphic??
> 
>  
> For type families maybe things are easier because there is no implicit instantiation.  
> 
>  
> But I?m not sure
> 
>  
> These kinds of issues are the reason that my conclusion at the time was (as Richard put it)
> 
>  
> Or, are
> | there any that are restricted because someone needs to think hard before
> | lifting it, and no one has yet done that thinking?
> 
>  
> At the time, there were also problems with what the type equality solver was supposed to do with foralls.
> 
>  
> I know, for example,
> | that the unify function in types/Unify.lhs will have to be completed to
> | work with foralls, but this doesn't seem hard.
> 
>  
> The solver changed quite a bit since I rewrote Tom's original prototype. So, maybe it is easy now, but maybe it is more tricky than you think. The idea of rewriting complex terms into equalities at the point of each application of a type synonym family (aka type function) assumes that you can pull subterms out of a term into a separate equality, but how is this going to work if a forall is in the way?  E.g., given
> 
>  
>   type family F a :: *
> 
>  
> the equality
> 
>  
>   Maybe (forall a. F [a]) ~ G b
> 
>  
> would need to be broken down to
> 
>  
>   x ~  F [a], Maybe (forall a. x) ~ G b
> 
>  
> but you cannot do that, because you just moved 'a' out of its scope. Maybe you can move the forall out as well?
> 
>  
> Manuel
> 
>  
>  
>  
> 
> _______________________________________________
> ghc-devs mailing list
> ghc-devs at haskell.org
> http://www.haskell.org/mailman/listinfo/ghc-devs
> 
> 
> 
> 
> -- 
> Your ship was destroyed in a monadic eruption. 
> _______________________________________________
> 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/20131112/dcb54f37/attachment-0001.html>

From conal at conal.net  Tue Nov 12 18:41:32 2013
From: conal at conal.net (Conal Elliott)
Date: Tue, 12 Nov 2013 10:41:32 -0800
Subject: Finding & assembling class dictionaries from GHC plugins?
In-Reply-To: <59543203684B2244980D7E4057D5FBC1486769E8@DB3EX14MBXC308.europe.corp.microsoft.com>
References: <CAD6SzRJM0B-e_THKMPi7p_Jw56DTzAVMGQdbyo2sg3quVvWuNA@mail.gmail.com>
 <59543203684B2244980D7E4057D5FBC148669657@DB3EX14MBXC308.europe.corp.microsoft.com>
 <CADfHYo4GmvZWpOp4uMJFnauB5iwLNbQwOh7Tifsm9pC3VwpP=w@mail.gmail.com>
 <59543203684B2244980D7E4057D5FBC14866B421@DB3EX14MBXC308.europe.corp.microsoft.com>
 <CAD6SzRJt+q+SWJQFEguBaXkMM4N3i-jaWrzfJw7NFFFcXCscQg@mail.gmail.com>
 <59543203684B2244980D7E4057D5FBC14866C4F1@DB3EX14MBXC308.europe.corp.microsoft.com>
 <CAD6SzRLF1fXsRkSSjvm9gZRgUkUYMJt+QjXcRu2fY+6ur3XQCQ@mail.gmail.com>
 <59543203684B2244980D7E4057D5FBC14866D14D@DB3EX14MBXC308.europe.corp.microsoft.com>
 <CAD6SzR+UC7ePZY3+7dimz9h646bKD=VQ0pV6EcGLEsQAMbFudQ@mail.gmail.com>
 <59543203684B2244980D7E4057D5FBC1486769E8@DB3EX14MBXC308.europe.corp.microsoft.com>
Message-ID: <CAD6SzR+tT_2CadYQzpbtJfhwTO_RvEED=o0Leu-sLvOiq5u4Eg@mail.gmail.com>

Hi Simon. Yes, I'd appreciate such a call, with at least one of the HERMIT
folks in the conversation as well. They'll be implementing whatever we come
up with as an improvement to HERMIT, and I'll be using the result. I'll
follow up about choosing a time that works for all.  -- Conal






On Mon, Nov 11, 2013 at 1:49 PM, Simon Peyton-Jones
<simonpj at microsoft.com>wrote:

>  Conal
>
>
>
> Email is not good for this.  I think it?d be more productive to have a
> Skype call, with both of use looking at GHC?s source code.
>
>
>
> If you?d like to do that, do suggest a time.
>
>
>
> Simon
>
>
>
> *From:* conal.elliott at gmail.com [mailto:conal.elliott at gmail.com] *On
> Behalf Of *Conal Elliott
> *Sent:* 07 November 2013 18:15
>
> *To:* Simon Peyton-Jones
> *Cc:* Nicolas Frisby; ghc-devs at haskell.org
> *Subject:* Re: Finding & assembling class dictionaries from GHC plugins?
>
>
>
> On Wed, Nov 6, 2013 at 11:44 PM, Simon Peyton-Jones <simonpj at microsoft.com>
> wrote:
>
>  Well, you are writing a function
>
>                 reify :: CoreExpr -> HsExpr RdrName
>
>
> Not exactly. I'm reifying CoreExpr directly to another CoreExpr. (The
> target CoreExpr calls into an API for GADT-typed lambda terms<https://github.com/conal/lambda-ccc/blob/master/src/LambdaCCC/Lambda.hs>.
> All works swimmingly as long as I'm able to avoid dictionary construction,
> but I'm no longer able to do so.) I haven't explored your suggestion of
> translating to HsExpr instead. Do you know of any plugins that work this
> way? Do you really believe it would work out? For instance, I wouldn't know
> where to insert type annotations, and I'd have to back-translate names. I
> imagine there are other challenges I don't foresee.
>
>
>  It takes as its input a CoreExpr and produces as its output a
> reification of the input.  I don?t see why you need start by converting
> Core to HsExpr. Just write reify directly!
>
>
>
> I wasn't suggesting converting a CoreExpr to an HsExpr. Rather, I was
> wondering out loud how I might get the type-checker's help to generate Core
> to find/assemble a Typeable dictionary for a given Core type (since I'm
> starting with Core). One idea is translate the core type cty to an HsType
> hty, use hty in a very simple HsExpr like "Dict :: Dict hty" (where Dict is
> from Ed K's constraints package), use the typechecker to convert that
> simple HsExpr to a CoreExpr, and then extract the dictionary-forming
> sub-CoreExpr. Or something simpler along the same lines.
>
> Thanks for the help,
>
> -- Conal
>
>
>
>
>
> Simon
>
>
>
> *From:* conal.elliott at gmail.com [mailto:conal.elliott at gmail.com] *On
> Behalf Of *Conal Elliott
> *Sent:* 07 November 2013 01:08
>
>
> *To:* Simon Peyton-Jones
> *Cc:* Nicolas Frisby; ghc-devs at haskell.org
> *Subject:* Re: Finding & assembling class dictionaries from GHC plugins?
>
>
>
> Thanks for the suggestion. I hadn't considered backing up to an HsExpr. I
> guess we'd have to start by converting the Core Type to an HsType to form a
> type-annotated HsExpr. Am I on the right track here?
>
> -- Conal
>
>
>
> On Wed, Nov 6, 2013 at 5:59 AM, Simon Peyton-Jones <simonpj at microsoft.com>
> wrote:
>
>  Hmm. One route would be to build a HsExpr (rather than a CoreExpr) for
> the reification of your CoreExpr, and stick that into the maw of the type
> checker.  That would hand off all this dictionary construction to the type
> checker, which is designed for the purpose.
>
>
>
> Simon
>
>
>
> *From:* conal.elliott at gmail.com [mailto:conal.elliott at gmail.com] *On
> Behalf Of *Conal Elliott
> *Sent:* 05 November 2013 23:41
> *To:* Simon Peyton-Jones
> *Cc:* Nicolas Frisby; ghc-devs at haskell.org
> *Subject:* Re: Finding & assembling class dictionaries from GHC plugins?
>
>
>
> Hi Simon,
>
> Here's some context on what I'm after. I'll try to include enough to
> clarify what I'm after, without dragging you into unnecessary detail.
>
> I have a Core expression, which I'm systematically translating to a
> related Core expression. The second one reifies the first one, so that the
> generated code *evaluates* to a run-time (not compile/Core-time)
> representation akin to the original Core expression. In this second
> (reified) representation, I need some run-time representation of types. I
> use Typeable constraints in my representation, and these constraints don't
> appear in the original Core representation. For instance, I have the
> following constructor for function application in a GADT of lambda
> expressions:
>
> > (:^) :: (Typeable a, Typeable b) => E (a -> b) -> E a -> E b
>
> My reification plugin takes a Core application expression, recursively
> reifies the function and argument expressions, and makes an expression that
> applies (:^) to the two recursive results. However--and the point of this
> thread--I also need to come up with Core expressions for the two Typeable
> dictionaries.
>
> So, to clarify my request, given a Core type representation t, I want to
> construct a Core expression that evaluates to the dictionary for Typeable t
> if one exists, or fail if there isn't one. Note that t is not necessarily
> an atomic type; it could instead be something like [(Bool,Int -> String)].
>
> I'm happy to Skype-chat if it'd help.
>
> Thanks,  - Conal
>
>
>
>
>
> On Tue, Nov 5, 2013 at 2:37 PM, Simon Peyton-Jones <simonpj at microsoft.com>
> wrote:
>
>   We just don't know how to start ? ie how call the right functions from
> the type checker. Are there any resources explaining the relevant subset of
> the TcRnIf API?
>
> And I for my part don?t know where to start helping you!  Conal wrote
>
>
>
> I don't think I need to construct dictionaries for new Typeable instances.
> I only need to find and assemble *existing* Typeable instances into
> combinations like Typeable [(Bool,Int -> String)], and I don't know how to
> do so in a GHC plug-in
>
>
>
> That?s exactly what the constraint solver does.  (TcSimplify and
> friends.)  But again I need more context.
>
>
>
> I gather you are talking to Pedro too?  He knows a lot about this stuff.
>
>
>
> Also there are a bunch of folk (Luite, Edsko) worked on the new front-end
> plugin stuff, and are much more expert in it than me.
>
>
>
> We could have a skype call if that would help
>
>
>
> S
>
>
>
>
>
> *From:* Nicolas Frisby [mailto:nicolas.frisby at gmail.com]
> *Sent:* 05 November 2013 14:36
> *To:* Simon Peyton-Jones
> *Cc:* ghc-devs at haskell.org; Conal Elliott
> *Subject:* RE: Finding & assembling class dictionaries from GHC plugins?
>
>
>
> On Nov 5, 2013 3:14 AM, "Simon Peyton-Jones" <simonpj at microsoft.com>
> wrote:
>
> >
> > A core-level plug-in can?t generate fresh instances.  There are some new
> plug-in hooks that fit earlier in the pipeline, which can.  Maybe you can
> use that, and generate a data type decl with ?deriving Typeable??
>
> We're willing to do some awkward shoehorning in HERMIT to make this work
> in limited circumstances. (Hopefully including Conal's.)
>
> We just don't know how to start ? ie how call the right functions from the
> type checker. Are there any resources explaining the relevant subset of the
> TcRnIf API?
>
> Thanks.
>
> >
> >
> > From: ghc-devs [mailto:ghc-devs-bounces at haskell.org] On Behalf Of Conal
> Elliott
> > Sent: 04 November 2013 20:08
> > To: ghc-devs at haskell.org
> > Subject: Finding & assembling class dictionaries from GHC plugins?
> >
> >
> >
> > I'm working on a GHC plugin (for compiling Haskell to hardware), and I
> need to synthesize Typeable (and maybe other) class dictionaries for a wide
> range of types, including composite types (functions, pairs, lists, etc).
> Can it be done, and how? I think I'm mainly looking for mechanics of
> finding existing class instances (however they're defined) and assembling
> them (for parametrized/composite dictionaries), rather than mechanisms
> specific to Typeable.
> >
> > Thanks, -- Conal
> >
> >
> > _______________________________________________
> > 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/20131112/dd5268ad/attachment-0001.html>

From simonpj at microsoft.com  Tue Nov 12 22:14:18 2013
From: simonpj at microsoft.com (Simon Peyton-Jones)
Date: Tue, 12 Nov 2013 22:14:18 +0000
Subject: Restrictions on polytypes with type families
In-Reply-To: <5A437DA0-EAA0-4544-BCC9-2CBBEBD8562C@cis.upenn.edu>
References: <0A145076-6176-47C8-B2BD-E0FE665D08D9@cis.upenn.edu>
 <59543203684B2244980D7E4057D5FBC1477C95B1@DB3EX14MBXC306.europe.corp.microsoft.com>
 <CAGK9nuqoVbY27OXjhVU_aSGP8O2oCMZBT=JzeXMuCaFHVMs61w@mail.gmail.com>
 <59543203684B2244980D7E4057D5FBC1477C96B6@DB3EX14MBXC306.europe.corp.microsoft.com>
 <AE82CBAA-A314-4A45-BA5D-DF328017E51C@cse.unsw.edu.au>
 <59543203684B2244980D7E4057D5FBC1477CB1E5@DB3EX14MBXC306.europe.corp.microsoft.com>
 <C0207498A084F14E85CA5D588539FA0F1304CBF0@DB3EX14MBXC311.europe.corp.microsoft.com>
 <CAPNUp09eJ=p4pQotH4wnZPnpa4iadQt4WThZRqRT1q_upG-pyw@mail.gmail.com>
 <CADfHYo7UCv-nowJTPGFs25wabbiHmQN8QXTT64WUUq7vdbpN5w@mail.gmail.com>
 <5A437DA0-EAA0-4544-BCC9-2CBBEBD8562C@cis.upenn.edu>
Message-ID: <59543203684B2244980D7E4057D5FBC148677FC4@DB3EX14MBXC308.europe.corp.microsoft.com>

Me neither.

Simon

From: ghc-devs [mailto:ghc-devs-bounces at haskell.org] On Behalf Of Richard Eisenberg
Sent: 12 November 2013 16:15
To: Nicolas Frisby
Cc: Manuel Chakravarty; ghc-devs at haskell.org
Subject: Re: Restrictions on polytypes with type families

I'm unaware of any progress on this front since the thread died out. I don't really think I have time to get too involved in an answer, but I'd be quite keen to hear of one!

Richard

On Nov 11, 2013, at 2:47 PM, Nicolas Frisby wrote:


Has there been any other discussions/write-ups regarding the issues in this (stale) thread? In particular, I'm interested in polytypes on the RHS of type family instances.

The rest of this email just explains my interest a bit and culiminates in a more domain-specific and more open-response question.

I'd like to explore some generalizations of GHC.Generics, but I think I'll need polytypes on the RHS of a type family instances.

For example, this type family is a step towards Hinze's "Polytypic Values Possess Polykinded Types".

type family NatroN (t::k) (s::k) :: *
type instance NatroN t s = t -> s
type instance NatroN t s = forall x. NatroN (t x) -> (s x)

However, I'm not sure how I'd write an *equally general* type class for creating/applying such a value. Perhaps these two combinators (which I think would type-check) would help.

lift1 :: (forall x. NatroN (t x) (s x)) -> NatroN t s
lift1 f = f

drop1 :: forall x. NatroN t s -> NatroN (t x) (s x)
drop1 f = f

I'm hoping these definitions might enable me to unify stacks of classes, such as

class Functor1_1 t where fmap1_1 :: (a -> b) -> t a -> t b
class Functor1_2 t where fmap1_2 :: (a -> b) -> t a y -> t b y
class Functor2_1 t where
  fmap2_1 :: (forall x. a x -> b x) -> t a -> t b
class Functor2_2 t where
  fmap2_2 :: (forall x. a x -> b x) -> t a y -> t b y

into a single class such as

class FunctorPK t where
  fmapPK :: Proxy t -> Proxy a -> Natro a b -> Natro (t a) (t b)

So, an additional question: am I barking up the wrong tree? In other words, is there an alternative to expressing these kinds of kind-polymorphic values that is currently more workable?

Thank you for your time.

-----

PS Here's an optimistic guess at what instances of FunctorPK might look like, omitting the proxies for now.

newtype Example g h a = Example {unExample :: g (h a) a)}

instance FunctorPK (g (h Int))
    => FunctorPK (Example g h) where
  fmapPK f = Example
           . fmapPK {- at g -} (fmapPK {- at h -} f) .
           . {- drop1 ? -} (fmapPK {- at g (h a) -} f))
           . unExample

instance FunctorPK g => FunctorPK (Example g) where
  fmapPK f (Example x) = Example $ fmapPK {- at g -} ({- drop1 ? -} f) x

instance FunctorPK Example where
  fmapPK f (Example x) = Example (f x)

Thanks again.


On Fri, Apr 5, 2013 at 1:32 PM, Dimitrios Vytiniotis <dimitris at microsoft.com<mailto:dimitris at microsoft.com>> wrote:
Hmm, no I don't think that Flattening is a very serious problem:
Firstly, we can somehow get around that if we use implication constraints and higher-order flattening
variables. We have discussed that (but not implemented). For example.

forall a. F [a] ~ G Int

becomes:

forall a.  fsk a ~ G Int

forall a. true => fsk a ~ F [a]

Secondly:  flattening under a Forall is not terribly important, unless you have type families that dispatch on
polymorphic types, which is admittedly a rather rare case. We lose some completeness but that's ok.

For me, a more serious problem are polymorphic RHS, which give rise to exactly the same problems for type
inference as impredicative polymorphism. For instance:

type instance F Int = forall a. a -> [a]

g :: F Int
g = undefined

main = g 3

Should this type check or not? And then all our discussions about impredicativity, explicit type applications etc become
relevant again.

Thanks!
d-

If the problem with foralls on the RHS is that it devolves into ImpredicativeTypes, what about only allowing them when ImpredicativeTypes is on?






From: Simon Peyton-Jones
Sent: Friday, April 05, 2013 8:24 AM
To: Manuel M T Chakravarty
Cc: Iavor Diatchki; ghc-devs; Dimitrios Vytiniotis
Subject: RE: Restrictions on polytypes with type families

Manuel has an excellent point. See the Note below in TcCanonical!   I have no clue how to deal with this

Simon

Note [Flattening under a forall]
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Under a forall, we
  (a) MUST apply the inert subsitution
  (b) MUST NOT flatten type family applications
Hence FMSubstOnly.

For (a) consider   c ~ a, a ~ T (forall b. (b, [c])
If we don't apply the c~a substitution to the second constraint
we won't see the occurs-check error.

For (b) consider  (a ~ forall b. F a b), we don't want to flatten
to     (a ~ forall b.fsk, F a b ~ fsk)
because now the 'b' has escaped its scope.  We'd have to flatten to
       (a ~ forall b. fsk b, forall b. F a b ~ fsk b)
and we have not begun to think about how to make that work!


From: Manuel M T Chakravarty [mailto:chak at cse.unsw.edu.au]
Sent: 04 April 2013 02:01
To: Simon Peyton-Jones
Cc: Iavor Diatchki; ghc-devs
Subject: Re: Restrictions on polytypes with type families

Simon Peyton-Jones <simonpj at microsoft.com<mailto:simonpj at microsoft.com>>:
isn't this moving directly into the territory of impredicative types?

Ahem, maybe you are right.  Impredicativity means that you can
          instantiate a type variable with a polytype

So if we allow, say (Eq (forall a.a->a)) then we've instantiated Eq's type variable with a polytype.  Ditto Maybe (forall a. a->a).

But this is only bad from an inference point of view, especially for implicit instantiation.  Eg if we had
          class C a where
            op :: Int -> a

then if we have
          f :: C (forall a. a->a) =>...
          f = ...op...

do we expect op to be polymorphic??

For type families maybe things are easier because there is no implicit instantiation.

But I'm not sure

These kinds of issues are the reason that my conclusion at the time was (as Richard put it)

Or, are
| there any that are restricted because someone needs to think hard before
| lifting it, and no one has yet done that thinking?

At the time, there were also problems with what the type equality solver was supposed to do with foralls.

I know, for example,
| that the unify function in types/Unify.lhs will have to be completed to
| work with foralls, but this doesn't seem hard.

The solver changed quite a bit since I rewrote Tom's original prototype. So, maybe it is easy now, but maybe it is more tricky than you think. The idea of rewriting complex terms into equalities at the point of each application of a type synonym family (aka type function) assumes that you can pull subterms out of a term into a separate equality, but how is this going to work if a forall is in the way?  E.g., given

  type family F a :: *

the equality

  Maybe (forall a. F [a]) ~ G b

would need to be broken down to

  x ~  F [a], Maybe (forall a. x) ~ G b

but you cannot do that, because you just moved 'a' out of its scope. Maybe you can move the forall out as well?

Manuel




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



--
Your ship was destroyed in a monadic eruption.
_______________________________________________
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<mailto: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/20131112/5e05520b/attachment-0001.html>

From simonpj at microsoft.com  Tue Nov 12 23:26:54 2013
From: simonpj at microsoft.com (Simon Peyton-Jones)
Date: Tue, 12 Nov 2013 23:26:54 +0000
Subject: Windows build
In-Reply-To: <5281FA67.7070000@mail.ru>
References: <59543203684B2244980D7E4057D5FBC148676A5F@DB3EX14MBXC308.europe.corp.microsoft.com>
 <5281CE7D.3050208@mail.ru>
 <59543203684B2244980D7E4057D5FBC148677390@DB3EX14MBXC308.europe.corp.microsoft.com>
 <5281F716.2020308@mail.ru>
 <59543203684B2244980D7E4057D5FBC1486774B2@DB3EX14MBXC308.europe.corp.microsoft.com>
 <5281FA67.7070000@mail.ru>
Message-ID: <59543203684B2244980D7E4057D5FBC148678167@DB3EX14MBXC308.europe.corp.microsoft.com>

Great...that works.
I also had to edit mk/boilerplate.mk to comment out these lines

# ifeq "$(shell $(SHELL) -c 'python2 -c 0' 2> /dev/null && echo exists)" "exists"

# PYTHON = python2

# endif
Because msys2 has python2.exe as well as python.exe.  (Or I could have moved that out of the way too.)
Thanks
Austin please note for the msys2 instructions you are writing
Simon

From: kyra [mailto:kyrab at mail.ru]
Sent: 12 November 2013 09:53
To: Simon Peyton-Jones
Subject: Re: Windows build

http://www.python.org/download/

This is what is recommended at https://ghc.haskell.org/trac/ghc/wiki/Building/Preparation/Windows

I think you already has it installed, because this is required for msys build.

Hence all you should do is:
1. make your edit (MINGW32 -> MINGW)
2. disable msys2 python


On 11/12/2013 13:44, Simon Peyton-Jones wrote:
OK... where did you get native python from?

From: ghc-devs [mailto:ghc-devs-bounces at haskell.org] On Behalf Of kyra
Sent: 12 November 2013 09:39
To: ghc-devs at haskell.org<mailto:ghc-devs at haskell.org>
Subject: Re: Windows build

It looks the second option (native win32 python) works.

I've installed native win32 python, reverted my edit, leaving only *your* edit in place, *and* disabled msys2 python simply moving all msys2 python executables out of the path. It seems, all works now (I didn't wait the finish of tests, though).

Cheers,
Kyra


On 11/12/2013 12:58, Simon Peyton-Jones wrote:
Thanks Kyra, you are a star.
Yes, msys2 has been updated to fix the ctypes bug.  I have the version from 20131022.
With your edit I now get this:

Traceback (most recent call last):

  File "../driver/runtests.py", line 164, in <module>

    if mydll.kernel32.SetConsoleCP(65001) == 0:

  File "/usr/lib/python2.7/ctypes/__init__.py", line 435, in __getattr__

    dll = self._dlltype(name)

  File "/usr/lib/python2.7/ctypes/__init__.py", line 365, in __init__

    self._handle = _dlopen(self._name, mode)

OSError: No such file or directory

Any ideas about what to do now?  I guess you can reproduce if you install the later msys2.
thanks
Simon

From: ghc-devs [mailto:ghc-devs-bounces at haskell.org] On Behalf Of kyra
Sent: 12 November 2013 06:45
To: ghc-devs at haskell.org<mailto:ghc-devs at haskell.org>
Subject: Re: Windows build

I've looked into this.

Current test script picks msys2-compiled python, which, after your modification, can't find 'windll', because msys2-compiled python is cygwin-like and it's 'ctypes' has no 'windll'. If we rewrite the relevant part of script thus:

config.msys2 = False
....
    elif v.startswith("MINGW"):
        config.msys2 = True
....
# Try to use UTF8
if windows:
    import ctypes
    if config.cygwin or config.msys2:
        # Is this actually right? Which calling convention does it use?
        # As of the time of writing, ctypes.windll doesn't exist in the
        # cygwin python, anyway.
        mydll = ctypes.cdll
    else:
        mydll = ctypes.windll

then we go slightly further and fail with:

Traceback (most recent call last):
  File "../driver/runtests.py", line 151, in <module>
    import ctypes
  File "/usr/lib/python2.7/ctypes/__init__.py", line 451, in <module>
    pythonapi = PyDLL("libpython%d.%d.dll" % _sys.version_info[:2])
  File "/usr/lib/python2.7/ctypes/__init__.py", line 365, in __init__
    self._handle = _dlopen(self._name, mode)
OSError: No such file or directory

And this is definitely a bug in msys2 python, because there is no such a file ("libpython*.dll) anywhere in msys2 distribution.

What could be possible solutions?

1. I'm seeing a new version of Msys2 appearing right now here http://sourceforge.net/projects/msys2/files/REPOS/MSYS2/i686/. It is now a bunch of separate packages, I've looked into python 2.7.5 package and found ctypes-related things definitely changed. Thus we could wait a couple of days until Msys2 release process is finished and installation information is available, hoping it's python is working properly.

2. Another approach is to modify testing infrastructure to use some pure win32/mingw based python distribution. But I'm in no way an expert here, sorry.

Cheers,
Kyra


On 11/12/2013 02:10, Simon Peyton-Jones wrote:
Austin, or others,
It would be SO GREAT if it was possible to validate on Windows again.
Currently I'm using msys2, which builds GHC fine, but things fail badly in the testsuite.

Traceback (most recent call last):

  File "../driver/runtests.py", line 144, in <module>

    raise Exception("Can't detect Windows terminal type")

Exception: Can't detect Windows terminal type

uname -s returns MINGW_NT-6.2
Changing the test from
    elif v.startswith("MINGW32"):
to
    elif v.startswith("MINGW"):
just produces a new error

Traceback (most recent call last):

  File "../driver/runtests.py", line 155, in <module>

    mydll = ctypes.windll

AttributeError: 'module' object has no attribute 'windll'

../mk/test.mk:242: recipe for target 'test' failed

It's all very frustrating because I can't validate.  Can anyone help?
Simon








_______________________________________________

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<mailto: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/20131112/6fb8570e/attachment.html>

From carter.schonwald at gmail.com  Wed Nov 13 02:35:02 2013
From: carter.schonwald at gmail.com (Carter Schonwald)
Date: Tue, 12 Nov 2013 21:35:02 -0500
Subject: Adding new library dependencies to GHC
In-Reply-To: <CAEx4-7npD+Lv3SNHSh71eUArKYBBRRj0QouqnGsCionhzAZdEA@mail.gmail.com>
References: <CAEx4-7npD+Lv3SNHSh71eUArKYBBRRj0QouqnGsCionhzAZdEA@mail.gmail.com>
Message-ID: <CAHYVw0zJ_SYvb5QKwyQCkH5swL2WAdkxzCWpcuNfBsxmdXejYA@mail.gmail.com>

Hey Alex,
very very cool!

a few thoughts: ghc stage1 has no GHCI, and thus can't build / use a lib
that has template haskell.
LLVM-General uses template haskell pretty heavily to generate the FFI code!

see
https://github.com/bscarlet/llvm-general/blob/master/llvm-general/src/LLVM/General/Internal/FFI/Builder.hs#L66
example and
https://github.com/bscarlet/llvm-general/blob/master/llvm-general/src/LLVM/General/Internal/FFI/Constant.hs#L89

for another

so your choices are: figure out how to support TH in stage 1 ghc, OR use
llvm-general-pure, and cope with just having llvm pretty printing and
parsing.  Alternatively, you could treat the "llvm-general" way as being an
alternative to the -fasm and -fllvm backends, and have it only be built /
supported in the stage2 backend.

point being: start with getting -flllvm working just using llvm-general-pure
then once you've got that working, having an llvm alternative that can ghc
can enable in stage2 (when ghci/th is a thing) can be made to work.

either way, very cool! it gives a path towards bundling llvm with ghc, or
at least is a decent experiment towards that.

one thing you may want to consider is how to remove the TH deps from llvm
general. This would make it possible use it in stage1 GHC, which would make
it much more likely to be actually merged into GHC proper.

again, props for getting this experimentation started!
-Carter




On Tue, Nov 12, 2013 at 2:53 PM, Alex Ford <alexander.r.ford at gmail.com>wrote:

> Hi,
>
> I've made some changes to the LLVM backend of GHC to make it use
> llvm-general to output bitcode rather than pretty printing human readable
> LLVM assembly. However, I've been having trouble linking the required
> libraries (llvm-general and its transitive dependencies). The steps I've
> taken so far are to put the required libraries in the build tree under
> libraries, and added them to the packages file, to PACKAGES_STAGE0 and
> PACKAGES_STAGE1 in ghc.mk, and to the build depends section in compiler/
> ghc.cabal.in.
>
> The build fails in phase 1 when trying to link utf8-string (a dependency
> of llvm-general) during the build of llvm-general, with:
> Loading package utf8-string-0.3.7 ... <command line>: can't load .so/.DLL
> for: libHSutf8-string-0.3.7.so (libHSutf8-string-0.3.7.so: cannot open
> shared object file: No such file or directory)
>
> The problem seems to be that with pre-existing library dependencies, the
> system-wide libraries at /usr/lib/ghc-7.6.3/<libname>/ are pulled in,
> whereas with the new dependencies, versions within the build tree (e.g. at
> libraries/utf8-string/dist-install/build/) are tried instead, despite these
> new libraries being installed globally within the same parent directory and
> being listed by ghc-pkg (no errors upon ghc-pkg check either).
>
> For example, in compiler/stage1/package-data.mk,
> compiler_stage1_DEP_LIB_DIRS_SEARCHPATH
> specifies /usr/lib/ghc-7.6.3/bytestring-0.10.0.2, and bytestring links
> successfully, but for utf8-string specifies
> <ghc-base-dir>/libraries/utf8-string/dist-boot/build.
>
> I've read through the documentation on libraries for GHC but can't figure
> out how to make this work. Could anyone suggest how I could go about fixing
> this?
>
> As a slightly related question, llvm-general depends on template-haskell.
> Will this cause problems when building GHC normally, since the stage 1
> compiler does not support TH? If so is there any way to compile stage 2
> directly using the stage 0 compiler?
>
> Many thanks,
> Alex
>
> _______________________________________________
> Glasgow-haskell-users mailing list
> Glasgow-haskell-users at haskell.org
> http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/ghc-devs/attachments/20131112/99f2bc69/attachment-0001.html>

From benl at ouroborus.net  Wed Nov 13 03:46:02 2013
From: benl at ouroborus.net (Ben Lippmeier)
Date: Wed, 13 Nov 2013 14:46:02 +1100
Subject: Validate broken on Snow Leopard and Mountain Lion
Message-ID: <21E81090-2380-4DF9-96F7-86773FCEC65C@ouroborus.net>


The Snow Leopard says:
----------------------
Loading package primitive-0.5.1.0 ... linking ... done.
Loading package vector-0.10.9.1 ... <command line>: can't load .so/.DLL for: /Users/benl/devel/ghc/ghc-head-validate/libraries/vector/dist-install/build/libHSvector-0.10.9.1-ghc7.7.20131113.dylib (dlopen(/Users/benl/devel/ghc/ghc-head-validate/libraries/vector/dist-install/build/libHSvector-0.10.9.1-ghc7.7.20131113.dylib, 9): Library not loaded: @rpath/primitive-0.5.1.0/libHSprimitive-0.5.1.0-ghc7.7.20131113.dylib
  Referenced from: /Users/benl/devel/ghc/ghc-head-validate/libraries/vector/dist-install/build/libHSvector-0.10.9.1-ghc7.7.20131113.dylib
  Reason: image not found)
make[1]: *** [libraries/dph/dph-lifted-copy/dist-install/build/Data/Array/Parallel/PArray/PData.o] Error 1
make[1]: *** Waiting for unfinished jobs....
make: *** [all] Error 2


The Mountain Lion says:
-----------------------
libraries/primitive/cbits/primitive-memops.c:48:0:
     warning: dereferencing type-punned pointer will break strict-aliasing rules
libraries/primitive/cbits/primitive-memops.c: In function ?hsprimitive_memset_Float?:

libraries/primitive/cbits/primitive-memops.c:49:0:
     warning: dereferencing type-punned pointer will break strict-aliasing rules
libraries/primitive/cbits/primitive-memops.c: In function ?hsprimitive_memset_Double?:

libraries/primitive/cbits/primitive-memops.c:50:0:
     warning: dereferencing type-punned pointer will break strict-aliasing rules
make[1]: *** [libraries/primitive/dist-install/build/cbits/primitive-memops.dyn_o] Error 1
make: *** [all] Error 2


Neither seems pleased.

Ben.


From christiaan.baaij at gmail.com  Wed Nov 13 09:02:49 2013
From: christiaan.baaij at gmail.com (Christiaan Baaij)
Date: Wed, 13 Nov 2013 10:02:49 +0100
Subject: Validate broken on Snow Leopard and Mountain Lion
In-Reply-To: <21E81090-2380-4DF9-96F7-86773FCEC65C@ouroborus.net>
References: <21E81090-2380-4DF9-96F7-86773FCEC65C@ouroborus.net>
Message-ID: <7ECCA023-9D11-4423-BEA5-3ADA6D1D8588@gmail.com>

The error in snow leopard is the result of my patch [1] for #8266 [2], which ensures that the original build directory is no longer referenced in installed packages/libs.
The patch is just a proper implementation of the original design though.

Perhaps the "relative-dynlib-references" procedure should be called just before the install phase, instead of after the build phase.
That, or the validate-related scripts/binaries should references the libraries in "inplace/lib" instead of the build dirs?
Does validate work for the DPH packages on Linux?

-- Christiaan

[1] https://ghc.haskell.org/trac/ghc/changeset/f213e48447050bf468bc4d91fc4d810402c23b85/ghc
[2] https://ghc.haskell.org/trac/ghc/ticket/8266

On Nov 13, 2013, at 4:46 AM, Ben Lippmeier <benl at ouroborus.net> wrote:

> 
> The Snow Leopard says:
> ----------------------
> Loading package primitive-0.5.1.0 ... linking ... done.
> Loading package vector-0.10.9.1 ... <command line>: can't load .so/.DLL for: /Users/benl/devel/ghc/ghc-head-validate/libraries/vector/dist-install/build/libHSvector-0.10.9.1-ghc7.7.20131113.dylib (dlopen(/Users/benl/devel/ghc/ghc-head-validate/libraries/vector/dist-install/build/libHSvector-0.10.9.1-ghc7.7.20131113.dylib, 9): Library not loaded: @rpath/primitive-0.5.1.0/libHSprimitive-0.5.1.0-ghc7.7.20131113.dylib
>  Referenced from: /Users/benl/devel/ghc/ghc-head-validate/libraries/vector/dist-install/build/libHSvector-0.10.9.1-ghc7.7.20131113.dylib
>  Reason: image not found)
> make[1]: *** [libraries/dph/dph-lifted-copy/dist-install/build/Data/Array/Parallel/PArray/PData.o] Error 1
> make[1]: *** Waiting for unfinished jobs....
> make: *** [all] Error 2
> 
> 
> The Mountain Lion says:
> -----------------------
> libraries/primitive/cbits/primitive-memops.c:48:0:
>     warning: dereferencing type-punned pointer will break strict-aliasing rules
> libraries/primitive/cbits/primitive-memops.c: In function ?hsprimitive_memset_Float?:
> 
> libraries/primitive/cbits/primitive-memops.c:49:0:
>     warning: dereferencing type-punned pointer will break strict-aliasing rules
> libraries/primitive/cbits/primitive-memops.c: In function ?hsprimitive_memset_Double?:
> 
> libraries/primitive/cbits/primitive-memops.c:50:0:
>     warning: dereferencing type-punned pointer will break strict-aliasing rules
> make[1]: *** [libraries/primitive/dist-install/build/cbits/primitive-memops.dyn_o] Error 1
> make: *** [all] Error 2
> 
> 
> Neither seems pleased.
> 
> Ben.
> 
> _______________________________________________
> ghc-devs mailing list
> ghc-devs at haskell.org
> http://www.haskell.org/mailman/listinfo/ghc-devs


From simonpj at microsoft.com  Wed Nov 13 09:24:43 2013
From: simonpj at microsoft.com (Simon Peyton-Jones)
Date: Wed, 13 Nov 2013 09:24:43 +0000
Subject: [commit: ghc] master: Make the fields in NameCache strict
 (bed118a)
In-Reply-To: <20131113034004.8950424069@ghc.haskell.org>
References: <20131113034004.8950424069@ghc.haskell.org>
Message-ID: <59543203684B2244980D7E4057D5FBC1486785FF@DB3EX14MBXC308.europe.corp.microsoft.com>

Patrick, does this have any effect on the performance of the compiler (runtime, allocation)?

Simon

| -----Original Message-----
| From: ghc-commits [mailto:ghc-commits-bounces at haskell.org] On Behalf Of
| git at git.haskell.org
| Sent: 13 November 2013 03:40
| To: ghc-commits at haskell.org
| Subject: [commit: ghc] master: Make the fields in NameCache strict
| (bed118a)
| 
| Repository : ssh://git at git.haskell.org/ghc
| 
| On branch  : master
| Link       :
| http://ghc.haskell.org/trac/ghc/changeset/bed118a43019e02ca0bc763fa6e418
| 45b1deb21f/ghc
| 
| >---------------------------------------------------------------
| 
| commit bed118a43019e02ca0bc763fa6e41845b1deb21f
| Author: Patrick Palka <patrick at parcs.ath.cx>
| Date:   Sat Nov 9 14:23:46 2013 -0500
| 
|     Make the fields in NameCache strict
| 
|     We've already been making sure to strictly modify the global name
| cache
|     in order to avoid space leaks.  However, that does us little good if
| the
|     fields of the name cache are not made strict as well.
| 
| 
| >---------------------------------------------------------------
| 
| bed118a43019e02ca0bc763fa6e41845b1deb21f
|  compiler/main/HscTypes.lhs |    4 ++--
|  1 file changed, 2 insertions(+), 2 deletions(-)
| 
| diff --git a/compiler/main/HscTypes.lhs b/compiler/main/HscTypes.lhs
| index 1004a6b..a3c6a65 100644
| --- a/compiler/main/HscTypes.lhs
| +++ b/compiler/main/HscTypes.lhs
| @@ -2033,9 +2033,9 @@ its binding site, we fix it up.
|  -- each original name; i.e. (module-name, occ-name) pair and provides
|  -- something of a lookup mechanism for those names.
|  data NameCache
| - = NameCache {  nsUniqs :: UniqSupply,
| + = NameCache {  nsUniqs :: !UniqSupply,
|                  -- ^ Supply of uniques
| -                nsNames :: OrigNameCache
| +                nsNames :: !OrigNameCache
|                  -- ^ Ensures that one original name gets one unique
|     }
| 
| 
| _______________________________________________
| ghc-commits mailing list
| ghc-commits at haskell.org
| http://www.haskell.org/mailman/listinfo/ghc-commits

From marlowsd at gmail.com  Wed Nov 13 10:36:13 2013
From: marlowsd at gmail.com (Simon Marlow)
Date: Wed, 13 Nov 2013 10:36:13 +0000
Subject: Trac formatting
In-Reply-To: <1384271585.2456.37.camel@kirk>
References: <59543203684B2244980D7E4057D5FBC148677A0A@DB3EX14MBXC308.europe.corp.microsoft.com>
 <1384271585.2456.37.camel@kirk>
Message-ID: <5283561D.5090702@gmail.com>

On 12/11/13 15:53, Joachim Breitner wrote:

> Am Dienstag, den 12.11.2013, 15:24 +0000 schrieb Simon Peyton-Jones:
>> When Trac formats commit messages it is doing a terrible job.  See for
>> example: https://ghc.haskell.org/trac/ghc/ticket/5996
>>
>> The commit message is nigh illegible until typeset without makup (see
>> comment 10).
>
> I believe it is a feature, not a bug: Trac encourages you to use
> markdown markup (which supposedly looks good also in plain text) in your
> commit messages. This not only makes them look nice, provides additional
> features like automatic linking (compare the reference to #5996 in
> comment 9 and comment 10).
>
> In this case the tables should have been indented by 4 spaces, or
> surrounded by {{{..}}}, in the commit message to make it come out
> nicely.
>
> Whether this is desirable is a different question. I like it, but the
> heavy users of the repository and trac need to decide what they prefer ?
> the ability to use markup in the commit messages, or the freedom to do
> any kind of ascii art.

I'm with Simon on this one.  I much preferred the old plain-text 
rendering of commit messages.

I don't want to start using a particular markup format (which is not 
markdown, it's Trac's own format AIUI) in our commit messages.  What 
happens if we switch from Trac to something else in the future?

Cheers,
Simon


From patrick at parcs.ath.cx  Wed Nov 13 13:56:31 2013
From: patrick at parcs.ath.cx (Patrick Palka)
Date: Wed, 13 Nov 2013 08:56:31 -0500
Subject: [commit: ghc] master: Make the fields in NameCache strict
 (bed118a)
In-Reply-To: <59543203684B2244980D7E4057D5FBC1486785FF@DB3EX14MBXC308.europe.corp.microsoft.com>
References: <20131113034004.8950424069@ghc.haskell.org>
 <59543203684B2244980D7E4057D5FBC1486785FF@DB3EX14MBXC308.europe.corp.microsoft.com>
Message-ID: <CA+C-WL_M08TpdFhLem3TeHixXU6sNAHFY5nGxb8zT3dW3=FFpA@mail.gmail.com>

Hi Simon,

On Wed, Nov 13, 2013 at 4:24 AM, Simon Peyton-Jones
<simonpj at microsoft.com> wrote:
> Patrick, does this have any effect on the performance of the compiler (runtime, allocation)?
>
> Simon

I haven't noticed a difference in performance in my measurements.

From eir at cis.upenn.edu  Wed Nov 13 20:15:30 2013
From: eir at cis.upenn.edu (Richard Eisenberg)
Date: Wed, 13 Nov 2013 15:15:30 -0500
Subject: restrictions on Coercible
Message-ID: <0F1A9FC9-3AAA-47A7-891F-A2E9C3F5522D@cis.upenn.edu>

Hi Simon, Joachim, and others,

I'm in the midst of reimplementing GeneralizedNewtypeDeriving in terms of coerce. See #8503 for why I'm doing this. But, I've run up against a limitation of Coercible I'd like to know more about. Currently, the stage2 compiler fails to build because of the problem.

In Module.lhs, there is this line:

> newtype PackageId = PId FastString deriving( Eq, Typeable )

The deriving mechanism sensibly prefers to use the GND mechanism when it can, and it can (seemingly) for Eq here. But, I get this error:

> compiler/basicTypes/Module.lhs:297:46:
>     No instance for (ghc-prim:GHC.Types.Coercible FastString PackageId)
>       because ?PackageId? is a recursive type constuctor

This is curious, because PackageId is manifestly *not* recursive. A little poking around tells me that any datatype mentioned in a .hs-boot file is considered recursive. There is sense to this, but the error message sure is confusing. In any case, this opens up a broader issue: we want GND to work with recursive newtypes. For example:

> class C a where
>   meth :: a
>
> instance C (Either a String) where
>   meth = Right ""
>
> newtype RecNT = MkRecNT (Either RecNT String)
>   deriving C

The above code works just fine in 7.6.3. But, if Coercible isn't allowed over recursive newtypes, then this wouldn't work if GND is implemented in terms of coerce.

So, my question is: why have this restriction? And, if there is a good reason for it, it should probably be documented somewhere. I couldn't find mention of it in the user's guide or in the haddock docs. If we do keep this restriction, what to do about GND? Seems like this may kill the idea of implementing GND in terms of coerce, but that makes me sad.

Thanks,
Richard

From simonpj at microsoft.com  Wed Nov 13 23:27:23 2013
From: simonpj at microsoft.com (Simon Peyton-Jones)
Date: Wed, 13 Nov 2013 23:27:23 +0000
Subject: restrictions on Coercible
In-Reply-To: <0F1A9FC9-3AAA-47A7-891F-A2E9C3F5522D@cis.upenn.edu>
References: <0F1A9FC9-3AAA-47A7-891F-A2E9C3F5522D@cis.upenn.edu>
Message-ID: <59543203684B2244980D7E4057D5FBC14867B939@DB3EX14MBXC308.europe.corp.microsoft.com>

Ah, life is never as simple as you hope.

The whole treatment of recursive types is a bit flaky in GHC.  For newtypes here is the motivation
	newtype R = MkR R
Now if we have an instance
	instance Coercible a R => Coercible a R
we aren't going to make much progress.  Mutual recursion is similar.

This is very much a corner case.  I think that if the recursion is under a type constructor eg
	newtype R1 = MkR [R1]
then we are fine.  But the current test is conservative.  I worry about
	newtype R2 a = MkR (F a)
because perhaps
	type instance F Int = R2 Int
and now R2 Int is just like R.  But GHC won't spot this today.

In any case, I suppose that, provided it was documented, GND could simply ignore the recursion problem, behave as advertised, and if that gives a loop it's the programmer's fault.

Things in hs-boot files are treated (again conservatively) as if they might be recursive.

A related thing is unpacking data types.  Consider
	data T = MkT {-# UNPACK #-} !S
	data S = MkS {-# UNPAXCK #-} !Int {-# UNPAXCK #-} !Int
A S-value is represented as a pair of Int# values.  And similarly T.  But what about
	data S2 = MkS2 {-# UNPACK #-} !Int {-# UNPACK #-} !S2
We don?t want to unpack infinitely.  Strictness analysis also risks infinitely unpacking a strict argument.

I think the rules for newtypes could be different (and perhaps more generous) than for data types.

Simon


| -----Original Message-----
| From: Richard Eisenberg [mailto:eir at cis.upenn.edu]
| Sent: 13 November 2013 20:16
| To: Simon Peyton-Jones; Joachim Breitner
| Cc: ghc-devs at haskell.org Devs
| Subject: restrictions on Coercible
| 
| Hi Simon, Joachim, and others,
| 
| I'm in the midst of reimplementing GeneralizedNewtypeDeriving in terms
| of coerce. See #8503 for why I'm doing this. But, I've run up against a
| limitation of Coercible I'd like to know more about. Currently, the
| stage2 compiler fails to build because of the problem.
| 
| In Module.lhs, there is this line:
| 
| > newtype PackageId = PId FastString deriving( Eq, Typeable )
| 
| The deriving mechanism sensibly prefers to use the GND mechanism when
| it can, and it can (seemingly) for Eq here. But, I get this error:
| 
| > compiler/basicTypes/Module.lhs:297:46:
| >     No instance for (ghc-prim:GHC.Types.Coercible FastString
| PackageId)
| >       because ?PackageId? is a recursive type constuctor
| 
| This is curious, because PackageId is manifestly *not* recursive. A
| little poking around tells me that any datatype mentioned in a .hs-boot
| file is considered recursive. There is sense to this, but the error
| message sure is confusing. In any case, this opens up a broader issue:
| we want GND to work with recursive newtypes. For example:
| 
| > class C a where
| >   meth :: a
| >
| > instance C (Either a String) where
| >   meth = Right ""
| >
| > newtype RecNT = MkRecNT (Either RecNT String)
| >   deriving C
| 
| The above code works just fine in 7.6.3. But, if Coercible isn't
| allowed over recursive newtypes, then this wouldn't work if GND is
| implemented in terms of coerce.
| 
| So, my question is: why have this restriction? And, if there is a good
| reason for it, it should probably be documented somewhere. I couldn't
| find mention of it in the user's guide or in the haddock docs. If we do
| keep this restriction, what to do about GND? Seems like this may kill
| the idea of implementing GND in terms of coerce, but that makes me sad.
| 
| Thanks,
| Richard

From nkpart at gmail.com  Thu Nov 14 02:29:37 2013
From: nkpart at gmail.com (Nick Partridge)
Date: Thu, 14 Nov 2013 12:29:37 +1000
Subject: Problems building HEAD on Mac OS X Mavericks/Xcode 5
Message-ID: <CAFXb89Bf4Nnbc6FVnKKDj+L2MYo8w1UyWH_ue2XobSoCyNKa2g@mail.gmail.com>

Hi,

I've hit a build failure when trying to build HEAD on Mavericks. I've
logged a bug here with a lot of detail:
https://ghc.haskell.org/trac/ghc/ticket/8528.

When using alex 3.1.2, some of the generated files have spaces preceding
preprocessor statements, while alex 3.1.0 doesn't do this. I guess this is
possibly an alex bug, but this is my first time building GHC so I'm not
really sure how the ecosystem works :)

Huge shout-out to Carter S. for giving me a ton of help in nailing down
this issue!

- Nick
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/ghc-devs/attachments/20131114/80b567b5/attachment.html>

From simonpj at microsoft.com  Thu Nov 14 02:57:11 2013
From: simonpj at microsoft.com (Simon Peyton-Jones)
Date: Thu, 14 Nov 2013 02:57:11 +0000
Subject: [commit: ghc] master: Make type-level evaluation work with
 :kind! (b2fa2d4)
In-Reply-To: <20131113003637.4C4832406B@ghc.haskell.org>
References: <20131113003637.4C4832406B@ghc.haskell.org>
Message-ID: <59543203684B2244980D7E4057D5FBC14867B9E2@DB3EX14MBXC308.europe.corp.microsoft.com>

That is indeed revolting.

Why not make
    sfMatchFam :: [Type] -> Maybe (CoAxiomRule, [Type], Type)
thus getting rid of the TcCoercion, and baking in the flaky assumption by construction.

Then I think you can put the whole definition of TcBuiltInSynFamily (with a non-Tc name) into CoAxiom.

Would that work?

Simon

| -----Original Message-----
| From: ghc-commits [mailto:ghc-commits-bounces at haskell.org] On Behalf Of
| git at git.haskell.org
| Sent: 13 November 2013 00:37
| To: ghc-commits at haskell.org
| Subject: [commit: ghc] master: Make type-level evaluation work with
| :kind! (b2fa2d4)
| 
| Repository : ssh://git at git.haskell.org/ghc
| 
| On branch  : master
| Link       :
| http://ghc.haskell.org/trac/ghc/changeset/b2fa2d41032882d3cf67be083489c
| bcbf9e4ec07/ghc
| 
| >---------------------------------------------------------------
| 
| commit b2fa2d41032882d3cf67be083489cbcbf9e4ec07
| Author: Iavor S. Diatchki <diatchki at galois.com>
| Date:   Tue Nov 12 16:36:23 2013 -0800
| 
|     Make type-level evaluation work with :kind!
| 
|     The main change is to add a case to `reduceTyFamApp_maybe` to
| evaluate
|     built-in type constructors (e.g., (+), (*), and friends).
| 
|     To avoid problems with recursive modules, I moved the definition of
|     TcBuiltInSynFamily from `FamInst` to `FamInstEnv`.  I am still not
| sure if
|     this is the right place.
| 
|     There is also a wibble that it'd be nice to fix:
| 
|     when we evaluate a built-in type function, using`sfMatchFam`, we
| get
|     a `TcCoercion`.  However, `reduceTyFamApp_maybe` needs a
| `Corecion`.
|     I couldn't find a nice way to convert between the two, so I
| resorted to
|     a bit of hack (marked with `XXX`).
| 
|     The hack is that we happen to know that the built-in constructors
| for
|     the type-nat functions always return coercions of shape
| `TcAxiomRuleCo`,
|     with no assumptions, so it easy to convert `TcCoercion` to
| `Coercion`
|     in this one case.  This is enough to make things work, but it is
| clearly
|     a cludge.
| 
| 
| >---------------------------------------------------------------
| 
| b2fa2d41032882d3cf67be083489cbcbf9e4ec07
|  compiler/ghc.mk                                    |    2 +-
|  compiler/typecheck/FamInst.lhs                     |   27 +-----------
|  compiler/typecheck/TcInteract.lhs                  |    2 +-
|  compiler/typecheck/TcTypeNats.hs                   |    2 +-
|  compiler/types/FamInstEnv.lhs                      |   43
| +++++++++++++++++++-
|  .../FamInst.lhs-boot => types/FamInstEnv.lhs-boot} |    2 +-
|  compiler/types/TyCon.lhs                           |    2 +-
|  7 files changed, 47 insertions(+), 33 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
| b2fa2d41032882d3cf67be083489cbcbf9e4ec07
| _______________________________________________
| ghc-commits mailing list
| ghc-commits at haskell.org
| http://www.haskell.org/mailman/listinfo/ghc-commits

From eir at cis.upenn.edu  Thu Nov 14 03:38:35 2013
From: eir at cis.upenn.edu (Richard Eisenberg)
Date: Wed, 13 Nov 2013 22:38:35 -0500
Subject: restrictions on Coercible
In-Reply-To: <59543203684B2244980D7E4057D5FBC14867B939@DB3EX14MBXC308.europe.corp.microsoft.com>
References: <0F1A9FC9-3AAA-47A7-891F-A2E9C3F5522D@cis.upenn.edu>
 <59543203684B2244980D7E4057D5FBC14867B939@DB3EX14MBXC308.europe.corp.microsoft.com>
Message-ID: <BAA9D11F-F21B-40C6-9A62-43482FD7F0A8@cis.upenn.edu>

I've moved this conversation to the comments on #8503, which is where I should have started it in the first place. Please see there for my response.

Richard

On Nov 13, 2013, at 6:27 PM, Simon Peyton-Jones <simonpj at microsoft.com> wrote:

> Ah, life is never as simple as you hope.
> 
> The whole treatment of recursive types is a bit flaky in GHC.  For newtypes here is the motivation
> 	newtype R = MkR R
> Now if we have an instance
> 	instance Coercible a R => Coercible a R
> we aren't going to make much progress.  Mutual recursion is similar.
> 
> This is very much a corner case.  I think that if the recursion is under a type constructor eg
> 	newtype R1 = MkR [R1]
> then we are fine.  But the current test is conservative.  I worry about
> 	newtype R2 a = MkR (F a)
> because perhaps
> 	type instance F Int = R2 Int
> and now R2 Int is just like R.  But GHC won't spot this today.
> 
> In any case, I suppose that, provided it was documented, GND could simply ignore the recursion problem, behave as advertised, and if that gives a loop it's the programmer's fault.
> 
> Things in hs-boot files are treated (again conservatively) as if they might be recursive.
> 
> A related thing is unpacking data types.  Consider
> 	data T = MkT {-# UNPACK #-} !S
> 	data S = MkS {-# UNPAXCK #-} !Int {-# UNPAXCK #-} !Int
> A S-value is represented as a pair of Int# values.  And similarly T.  But what about
> 	data S2 = MkS2 {-# UNPACK #-} !Int {-# UNPACK #-} !S2
> We don?t want to unpack infinitely.  Strictness analysis also risks infinitely unpacking a strict argument.
> 
> I think the rules for newtypes could be different (and perhaps more generous) than for data types.
> 
> Simon
> 
> 
> | -----Original Message-----
> | From: Richard Eisenberg [mailto:eir at cis.upenn.edu]
> | Sent: 13 November 2013 20:16
> | To: Simon Peyton-Jones; Joachim Breitner
> | Cc: ghc-devs at haskell.org Devs
> | Subject: restrictions on Coercible
> | 
> | Hi Simon, Joachim, and others,
> | 
> | I'm in the midst of reimplementing GeneralizedNewtypeDeriving in terms
> | of coerce. See #8503 for why I'm doing this. But, I've run up against a
> | limitation of Coercible I'd like to know more about. Currently, the
> | stage2 compiler fails to build because of the problem.
> | 
> | In Module.lhs, there is this line:
> | 
> | > newtype PackageId = PId FastString deriving( Eq, Typeable )
> | 
> | The deriving mechanism sensibly prefers to use the GND mechanism when
> | it can, and it can (seemingly) for Eq here. But, I get this error:
> | 
> | > compiler/basicTypes/Module.lhs:297:46:
> | >     No instance for (ghc-prim:GHC.Types.Coercible FastString
> | PackageId)
> | >       because ?PackageId? is a recursive type constuctor
> | 
> | This is curious, because PackageId is manifestly *not* recursive. A
> | little poking around tells me that any datatype mentioned in a .hs-boot
> | file is considered recursive. There is sense to this, but the error
> | message sure is confusing. In any case, this opens up a broader issue:
> | we want GND to work with recursive newtypes. For example:
> | 
> | > class C a where
> | >   meth :: a
> | >
> | > instance C (Either a String) where
> | >   meth = Right ""
> | >
> | > newtype RecNT = MkRecNT (Either RecNT String)
> | >   deriving C
> | 
> | The above code works just fine in 7.6.3. But, if Coercible isn't
> | allowed over recursive newtypes, then this wouldn't work if GND is
> | implemented in terms of coerce.
> | 
> | So, my question is: why have this restriction? And, if there is a good
> | reason for it, it should probably be documented somewhere. I couldn't
> | find mention of it in the user's guide or in the haddock docs. If we do
> | keep this restriction, what to do about GND? Seems like this may kill
> | the idea of implementing GND in terms of coerce, but that makes me sad.
> | 
> | Thanks,
> | Richard
> 


From coreyoconnor at gmail.com  Thu Nov 14 03:59:44 2013
From: coreyoconnor at gmail.com (Corey O'Connor)
Date: Wed, 13 Nov 2013 19:59:44 -0800
Subject: Problems building HEAD on Mac OS X Mavericks/Xcode 5
In-Reply-To: <CAFXb89Bf4Nnbc6FVnKKDj+L2MYo8w1UyWH_ue2XobSoCyNKa2g@mail.gmail.com>
References: <CAFXb89Bf4Nnbc6FVnKKDj+L2MYo8w1UyWH_ue2XobSoCyNKa2g@mail.gmail.com>
Message-ID: <CANTmfBS50t48CnUbsBNqWx79RohPk78HoDKMPfXDRiBupHM6sg@mail.gmail.com>

Hi,
Sound similar to an issue I've run into. There is some additional
information here:
https://github.com/simonmar/alex/pull/33#issuecomment-27543618

This appears to occur in both happy and alex.

Cheers,
Corey


-Corey O'Connor
coreyoconnor at gmail.com
http://corebotllc.com/


On Wed, Nov 13, 2013 at 6:29 PM, Nick Partridge <nkpart at gmail.com> wrote:

> Hi,
>
> I've hit a build failure when trying to build HEAD on Mavericks. I've
> logged a bug here with a lot of detail:
> https://ghc.haskell.org/trac/ghc/ticket/8528.
>
> When using alex 3.1.2, some of the generated files have spaces preceding
> preprocessor statements, while alex 3.1.0 doesn't do this. I guess this is
> possibly an alex bug, but this is my first time building GHC so I'm not
> really sure how the ecosystem works :)
>
> Huge shout-out to Carter S. for giving me a ton of help in nailing down
> this issue!
>
> - Nick
>
> _______________________________________________
> 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/20131113/c0438ee3/attachment.html>

From benl at ouroborus.net  Thu Nov 14 04:09:28 2013
From: benl at ouroborus.net (Ben Lippmeier)
Date: Thu, 14 Nov 2013 15:09:28 +1100
Subject: Validate broken on Snow Leopard and Mountain Lion
In-Reply-To: <7ECCA023-9D11-4423-BEA5-3ADA6D1D8588@gmail.com>
References: <21E81090-2380-4DF9-96F7-86773FCEC65C@ouroborus.net>
 <7ECCA023-9D11-4423-BEA5-3ADA6D1D8588@gmail.com>
Message-ID: <F59FB7DC-0CED-4F6B-AD8E-A343E66DEA3B@ouroborus.net>


On 13/11/2013, at 8:02 PM, Christiaan Baaij wrote:

> Does validate work for the DPH packages on Linux?

"sh validate" runs fine on my Linux machine, but neither of my Macs.

I can also run the dph tests manually on Linux, and they work fine.

Ben.


From carter.schonwald at gmail.com  Thu Nov 14 04:14:46 2013
From: carter.schonwald at gmail.com (Carter Schonwald)
Date: Wed, 13 Nov 2013 23:14:46 -0500
Subject: Problems building HEAD on Mac OS X Mavericks/Xcode 5
In-Reply-To: <CAFXb89Bf4Nnbc6FVnKKDj+L2MYo8w1UyWH_ue2XobSoCyNKa2g@mail.gmail.com>
References: <CAFXb89Bf4Nnbc6FVnKKDj+L2MYo8w1UyWH_ue2XobSoCyNKa2g@mail.gmail.com>
Message-ID: <CAHYVw0ysEhE1cj6nH-DyYuZQj7cdNZnXLOHQGQ6x0D4GM3AoKQ@mail.gmail.com>

Great job nick!

now we just need to sort out the problem and fix it! :)


On Wed, Nov 13, 2013 at 9:29 PM, Nick Partridge <nkpart at gmail.com> wrote:

> Hi,
>
> I've hit a build failure when trying to build HEAD on Mavericks. I've
> logged a bug here with a lot of detail:
> https://ghc.haskell.org/trac/ghc/ticket/8528.
>
> When using alex 3.1.2, some of the generated files have spaces preceding
> preprocessor statements, while alex 3.1.0 doesn't do this. I guess this is
> possibly an alex bug, but this is my first time building GHC so I'm not
> really sure how the ecosystem works :)
>
> Huge shout-out to Carter S. for giving me a ton of help in nailing down
> this issue!
>
> - Nick
>
> _______________________________________________
> 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/20131113/8691d66a/attachment.html>

From carter.schonwald at gmail.com  Thu Nov 14 04:23:54 2013
From: carter.schonwald at gmail.com (Carter Schonwald)
Date: Wed, 13 Nov 2013 23:23:54 -0500
Subject: Validate broken on Snow Leopard and Mountain Lion
In-Reply-To: <F59FB7DC-0CED-4F6B-AD8E-A343E66DEA3B@ouroborus.net>
References: <21E81090-2380-4DF9-96F7-86773FCEC65C@ouroborus.net>
 <7ECCA023-9D11-4423-BEA5-3ADA6D1D8588@gmail.com>
 <F59FB7DC-0CED-4F6B-AD8E-A343E66DEA3B@ouroborus.net>
Message-ID: <CAHYVw0yCxAagJxCB3Mw=OH=DadneW-Rc5Okqk2N_DxL_x2qBrg@mail.gmail.com>

Ben has an excellent point:

if things are broken on mac, lets fix it!  Especially since we should be
hitting RC status shortly.... any breakages should be smashed ASAP.

This does raise a point I hope we'll address more aggressively after the
7.8 release, namely trying to keep ghc less broken by default! GHC being
really really really broken between releases is probably the single HUGEST
barrier to more people getting involved in helping GHC dev. And I think
thats a huge problem we need to take more seriously.




On Wed, Nov 13, 2013 at 11:09 PM, Ben Lippmeier <benl at ouroborus.net> wrote:

>
> On 13/11/2013, at 8:02 PM, Christiaan Baaij wrote:
>
> > Does validate work for the DPH packages on Linux?
>
> "sh validate" runs fine on my Linux machine, but neither of my Macs.
>
> I can also run the dph tests manually on Linux, and they work fine.
>
> Ben.
>
> _______________________________________________
> 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/20131113/fd87a18b/attachment.html>

From simonpj at microsoft.com  Thu Nov 14 09:03:54 2013
From: simonpj at microsoft.com (Simon Peyton-Jones)
Date: Thu, 14 Nov 2013 09:03:54 +0000
Subject: Validate broken on Snow Leopard and Mountain Lion
In-Reply-To: <CAHYVw0yCxAagJxCB3Mw=OH=DadneW-Rc5Okqk2N_DxL_x2qBrg@mail.gmail.com>
References: <21E81090-2380-4DF9-96F7-86773FCEC65C@ouroborus.net>
 <7ECCA023-9D11-4423-BEA5-3ADA6D1D8588@gmail.com>
 <F59FB7DC-0CED-4F6B-AD8E-A343E66DEA3B@ouroborus.net>
 <CAHYVw0yCxAagJxCB3Mw=OH=DadneW-Rc5Okqk2N_DxL_x2qBrg@mail.gmail.com>
Message-ID: <59543203684B2244980D7E4057D5FBC14867BBF6@DB3EX14MBXC308.europe.corp.microsoft.com>

This does raise a point I hope we'll address more aggressively after the 7.8 release, namely trying to keep ghc less broken by default! GHC being really really really broken between releases is probably the single HUGEST barrier to more people getting involved in helping GHC dev. And I think thats a huge problem we need to take more seriously.

I totally agree with this.  What it needs is a Mac SWAT team who build GHC on Macs nightly, warn about problems and help fix them.

One recent total Mac breakage was due to the compulsory move to clang instead of gcc.   I gather that has caused a lot of pain.  I?ve seen a lot about Xcode too, whatever that is.

Anyway, Mac folk, we need you!

Simon

From: ghc-devs [mailto:ghc-devs-bounces at haskell.org] On Behalf Of Carter Schonwald
Sent: 14 November 2013 04:24
To: Ben Lippmeier
Cc: ghc-devs at haskell.org
Subject: Re: Validate broken on Snow Leopard and Mountain Lion

Ben has an excellent point:

if things are broken on mac, lets fix it!  Especially since we should be hitting RC status shortly.... any breakages should be smashed ASAP.
This does raise a point I hope we'll address more aggressively after the 7.8 release, namely trying to keep ghc less broken by default! GHC being really really really broken between releases is probably the single HUGEST barrier to more people getting involved in helping GHC dev. And I think thats a huge problem we need to take more seriously.


On Wed, Nov 13, 2013 at 11:09 PM, Ben Lippmeier <benl at ouroborus.net<mailto:benl at ouroborus.net>> wrote:

On 13/11/2013, at 8:02 PM, Christiaan Baaij wrote:

> Does validate work for the DPH packages on Linux?
"sh validate" runs fine on my Linux machine, but neither of my Macs.

I can also run the dph tests manually on Linux, and they work fine.

Ben.

_______________________________________________
ghc-devs mailing list
ghc-devs at haskell.org<mailto: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/20131114/e48cec8c/attachment-0001.html>

From christiaan.baaij at gmail.com  Thu Nov 14 09:57:02 2013
From: christiaan.baaij at gmail.com (Christiaan Baaij)
Date: Thu, 14 Nov 2013 10:57:02 +0100
Subject: Validate broken on Snow Leopard and Mountain Lion
In-Reply-To: <CAHYVw0yCxAagJxCB3Mw=OH=DadneW-Rc5Okqk2N_DxL_x2qBrg@mail.gmail.com>
References: <21E81090-2380-4DF9-96F7-86773FCEC65C@ouroborus.net>
 <7ECCA023-9D11-4423-BEA5-3ADA6D1D8588@gmail.com>
 <F59FB7DC-0CED-4F6B-AD8E-A343E66DEA3B@ouroborus.net>
 <CAHYVw0yCxAagJxCB3Mw=OH=DadneW-Rc5Okqk2N_DxL_x2qBrg@mail.gmail.com>
Message-ID: <26BB04BE-7C8D-4FEA-A6E3-26F86871EEAC@gmail.com>

Looking at the  "offending" c-code of the primitive library, with my limited C knowledge and understanding of this strict-aliasing, I think the gcc warning on Lion is correct: the strict-aliasing rule is violated.
However, after asking my colleague, we don't think the gcc optimizer will break the code in this particular case.

It's weird that the warning doesn't show on your linux install.
What version of gcc are you using on linux? Is it higher or lower than the on on OS X?

Changing line 22 in primitive-memops.c to:
const int *r = (const int *)(void *)&x;

Makes the warning go away.

For reference, my system:
OS X 10.8.5 (Mountain Lion), X Code 4.6.2, gcc version 4.2.1 (Based on Apple Inc. build 5658) (LLVM build 2336.11.00)


On Nov 14, 2013, at 5:23 AM, Carter Schonwald <carter.schonwald at gmail.com> wrote:

> Ben has an excellent point: 
> 
> if things are broken on mac, lets fix it!  Especially since we should be hitting RC status shortly.... any breakages should be smashed ASAP.
> 
> This does raise a point I hope we'll address more aggressively after the 7.8 release, namely trying to keep ghc less broken by default! GHC being really really really broken between releases is probably the single HUGEST barrier to more people getting involved in helping GHC dev. And I think thats a huge problem we need to take more seriously. 
> 
> 
> 
> 
> On Wed, Nov 13, 2013 at 11:09 PM, Ben Lippmeier <benl at ouroborus.net> wrote:
> 
> On 13/11/2013, at 8:02 PM, Christiaan Baaij wrote:
> 
> > Does validate work for the DPH packages on Linux?
> 
> "sh validate" runs fine on my Linux machine, but neither of my Macs.
> 
> I can also run the dph tests manually on Linux, and they work fine.
> 
> Ben.
> 
> _______________________________________________
> ghc-devs mailing list
> ghc-devs at haskell.org
> http://www.haskell.org/mailman/listinfo/ghc-devs
> 


From hvr at gnu.org  Thu Nov 14 10:11:30 2013
From: hvr at gnu.org (Herbert Valerio Riedel)
Date: Thu, 14 Nov 2013 11:11:30 +0100
Subject: Trac formatting
In-Reply-To: <5283561D.5090702@gmail.com> (Simon Marlow's message of "Wed, 13
 Nov 2013 10:36:13 +0000")
References: <59543203684B2244980D7E4057D5FBC148677A0A@DB3EX14MBXC308.europe.corp.microsoft.com>
 <1384271585.2456.37.camel@kirk> <5283561D.5090702@gmail.com>
Message-ID: <878uwrthrh.fsf@gnu.org>

On 2013-11-13 at 11:36:13 +0100, Simon Marlow wrote:
> On 12/11/13 15:53, Joachim Breitner wrote:
>
>> Am Dienstag, den 12.11.2013, 15:24 +0000 schrieb Simon Peyton-Jones:
>>> When Trac formats commit messages it is doing a terrible job.  See for
>>> example: https://ghc.haskell.org/trac/ghc/ticket/5996
>>>
>>> The commit message is nigh illegible until typeset without makup (see
>>> comment 10).
>>
>> I believe it is a feature, not a bug: Trac encourages you to use
>> markdown markup (which supposedly looks good also in plain text) in your
>> commit messages. This not only makes them look nice, provides additional
>> features like automatic linking (compare the reference to #5996 in
>> comment 9 and comment 10).
>>
>> In this case the tables should have been indented by 4 spaces, or
>> surrounded by {{{..}}}, in the commit message to make it come out
>> nicely.
>>
>> Whether this is desirable is a different question. I like it, but the
>> heavy users of the repository and trac need to decide what they prefer ?
>> the ability to use markup in the commit messages, or the freedom to do
>> any kind of ascii art.
>
> I'm with Simon on this one.  I much preferred the old plain-text
> rendering of commit messages.

Luckily, this is an exposed trac.ini setting
(for future reference: changeset.wiki_format_messages)

I've disabled wiki-rendering for commit messages so you can see the
effect. As Joachim already observed, since this is an an all-or-nothing
setting, you lose automatic hyperlinking to Trac tickets, Wiki pages,
other changesets, and even HTTP URLs in every places where commit
messages are rendered.

See for instance,

    https://ghc.haskell.org/trac/ghc/changeset/5a3918febb7354e0900c4f04151599d833716032/ghc

where you have to manually lookup the ticket-no. as well as the
commit-id of the referenced other commit that this commit tries to
compensate for.

So this undermines one of Trac's principal design goals, that is

    "Trac allows wiki markup in issue descriptions and commit messages,
    creating links and seamless references between bugs, tasks,
    changesets, files and wiki pages."

as is written in the introductory front-page at http://trac.edgewall.org

> I don't want to start using a particular markup format (which is not
> markdown, it's Trac's own format AIUI) in our commit messages.  What
> happens if we switch from Trac to something else in the future?

It's an unfortunate situation that when Trac came to life around 2005 it
wasn't clear that Markdown would become so popular (and it couldn't have
been used as-is without syntax extensions to allow seamless hyperlinks).

However, if you don't like Trac's Wiki markup and its primary goal of
tight & seamless hyperlinking from everywhere to everywhere, why did you
chose to deploy Trac in the first place? After all, should the GHC
project ever want to switch from Trac to something else, converting the
existing Trac tickets and the GHC Wiki Commentary will be quite an
undertaking retaining the crossrefs as well as stripping out all
Trac-isms... just saying...

PS: Btw, fwiw, http://trac.edgewall.org/wiki/WikiCreole.

Cheers,
  hvr

From christiaan.baaij at gmail.com  Thu Nov 14 11:04:57 2013
From: christiaan.baaij at gmail.com (Christiaan Baaij)
Date: Thu, 14 Nov 2013 12:04:57 +0100
Subject: Validate broken on Snow Leopard and Mountain Lion
In-Reply-To: <CAHYVw0yCxAagJxCB3Mw=OH=DadneW-Rc5Okqk2N_DxL_x2qBrg@mail.gmail.com>
References: <21E81090-2380-4DF9-96F7-86773FCEC65C@ouroborus.net>
 <7ECCA023-9D11-4423-BEA5-3ADA6D1D8588@gmail.com>
 <F59FB7DC-0CED-4F6B-AD8E-A343E66DEA3B@ouroborus.net>
 <CAHYVw0yCxAagJxCB3Mw=OH=DadneW-Rc5Okqk2N_DxL_x2qBrg@mail.gmail.com>
Message-ID: <1053217B-1C60-4E20-A8B8-CCF9FF9A0BD1@gmail.com>

After fixing the warning in the C-code of the primitive package, validate (including dph tests) seems to be working for me:

OVERALL SUMMARY for test run started at Thu Nov 14 11:03:26 2013 CET
 0:46:34 spent to go through
    3818 total tests, which gave rise to
   14930 test cases, of which
   11445 were skipped

      28 had missing libraries
    3394 expected passes
      58 expected failures

       0 caused framework failures
       1 unexpected passes
       4 unexpected failures

Unexpected passes:
   ghci/linking  T3333 (normal)

Unexpected failures:
   driver         static001 [bad stderr] (normal)
   driver/T3007   T3007 [bad exit code] (normal)
   perf/compiler  T3064 [stat not good enough] (normal)
   perf/compiler  T4801 [stat too good] (normal)

I'll try again with a 'make maintainer-clean', include profiling libs, and do a ./validate --slow.


On Nov 14, 2013, at 5:23 AM, Carter Schonwald <carter.schonwald at gmail.com> wrote:

> Ben has an excellent point: 
> 
> if things are broken on mac, lets fix it!  Especially since we should be hitting RC status shortly.... any breakages should be smashed ASAP.
> 
> This does raise a point I hope we'll address more aggressively after the 7.8 release, namely trying to keep ghc less broken by default! GHC being really really really broken between releases is probably the single HUGEST barrier to more people getting involved in helping GHC dev. And I think thats a huge problem we need to take more seriously. 
> 
> 
> 
> 
> On Wed, Nov 13, 2013 at 11:09 PM, Ben Lippmeier <benl at ouroborus.net> wrote:
> 
> On 13/11/2013, at 8:02 PM, Christiaan Baaij wrote:
> 
> > Does validate work for the DPH packages on Linux?
> 
> "sh validate" runs fine on my Linux machine, but neither of my Macs.
> 
> I can also run the dph tests manually on Linux, and they work fine.
> 
> Ben.
> 
> _______________________________________________
> ghc-devs mailing list
> ghc-devs at haskell.org
> http://www.haskell.org/mailman/listinfo/ghc-devs
> 


From marlowsd at gmail.com  Thu Nov 14 12:07:00 2013
From: marlowsd at gmail.com (Simon Marlow)
Date: Thu, 14 Nov 2013 12:07:00 +0000
Subject: Trac formatting
In-Reply-To: <878uwrthrh.fsf@gnu.org>
References: <59543203684B2244980D7E4057D5FBC148677A0A@DB3EX14MBXC308.europe.corp.microsoft.com>	<1384271585.2456.37.camel@kirk>
 <5283561D.5090702@gmail.com> <878uwrthrh.fsf@gnu.org>
Message-ID: <5284BCE4.2040800@gmail.com>

On 14/11/13 10:11, Herbert Valerio Riedel wrote:
> On 2013-11-13 at 11:36:13 +0100, Simon Marlow wrote:
>> On 12/11/13 15:53, Joachim Breitner wrote:
>>
>>> Am Dienstag, den 12.11.2013, 15:24 +0000 schrieb Simon Peyton-Jones:
>>>> When Trac formats commit messages it is doing a terrible job.  See for
>>>> example: https://ghc.haskell.org/trac/ghc/ticket/5996
>>>>
>>>> The commit message is nigh illegible until typeset without makup (see
>>>> comment 10).
>>>
>>> I believe it is a feature, not a bug: Trac encourages you to use
>>> markdown markup (which supposedly looks good also in plain text) in your
>>> commit messages. This not only makes them look nice, provides additional
>>> features like automatic linking (compare the reference to #5996 in
>>> comment 9 and comment 10).
>>>
>>> In this case the tables should have been indented by 4 spaces, or
>>> surrounded by {{{..}}}, in the commit message to make it come out
>>> nicely.
>>>
>>> Whether this is desirable is a different question. I like it, but the
>>> heavy users of the repository and trac need to decide what they prefer ?
>>> the ability to use markup in the commit messages, or the freedom to do
>>> any kind of ascii art.
>>
>> I'm with Simon on this one.  I much preferred the old plain-text
>> rendering of commit messages.
>
> Luckily, this is an exposed trac.ini setting
> (for future reference: changeset.wiki_format_messages)
>
> I've disabled wiki-rendering for commit messages so you can see the
> effect. As Joachim already observed, since this is an an all-or-nothing
> setting, you lose automatic hyperlinking to Trac tickets, Wiki pages,
> other changesets, and even HTTP URLs in every places where commit
> messages are rendered.
>
> See for instance,
>
>      https://ghc.haskell.org/trac/ghc/changeset/5a3918febb7354e0900c4f04151599d833716032/ghc
>
> where you have to manually lookup the ticket-no. as well as the
> commit-id of the referenced other commit that this commit tries to
> compensate for.

That's unfortunate. Ideally the tickets and commit hashes should be 
hyperlinked.

Commit logs are viewed more often in a terminal or an editor than on 
Trac itself, so I think markup isn't worth the effort.  Also you don't 
get to compose your commit message in the browser, so you can't see 
whether you've made a markup error.

> So this undermines one of Trac's principal design goals, that is
>
>      "Trac allows wiki markup in issue descriptions and commit messages,
>      creating links and seamless references between bugs, tasks,
>      changesets, files and wiki pages."
>
> as is written in the introductory front-page at http://trac.edgewall.org
>
>> I don't want to start using a particular markup format (which is not
>> markdown, it's Trac's own format AIUI) in our commit messages.  What
>> happens if we switch from Trac to something else in the future?
>
> It's an unfortunate situation that when Trac came to life around 2005 it
> wasn't clear that Markdown would become so popular (and it couldn't have
> been used as-is without syntax extensions to allow seamless hyperlinks).
>
> However, if you don't like Trac's Wiki markup and its primary goal of
> tight & seamless hyperlinking from everywhere to everywhere, why did you
> chose to deploy Trac in the first place?

We chose Trac because it was better than SourceForge :-) (also github 
wasn't usable at the time)

> After all, should the GHC
> project ever want to switch from Trac to something else, converting the
> existing Trac tickets and the GHC Wiki Commentary will be quite an
> undertaking retaining the crossrefs as well as stripping out all
> Trac-isms... just saying...
>
> PS: Btw, fwiw, http://trac.edgewall.org/wiki/WikiCreole.

Obviously this is all just MHO, if everyone else wants markup in commit 
messages then I won't complain.

Cheers,
	Simon



From hvr at gnu.org  Thu Nov 14 13:05:37 2013
From: hvr at gnu.org (Herbert Valerio Riedel)
Date: Thu, 14 Nov 2013 14:05:37 +0100
Subject: Trac formatting
In-Reply-To: <5284BCE4.2040800@gmail.com> (Simon Marlow's message of "Thu, 14
 Nov 2013 12:07:00 +0000")
References: <59543203684B2244980D7E4057D5FBC148677A0A@DB3EX14MBXC308.europe.corp.microsoft.com>
 <1384271585.2456.37.camel@kirk> <5283561D.5090702@gmail.com>
 <878uwrthrh.fsf@gnu.org> <5284BCE4.2040800@gmail.com>
Message-ID: <874n7ft9pa.fsf@gnu.org>

On 2013-11-14 at 13:07:00 +0100, Simon Marlow wrote:

[...]

> Obviously this is all just MHO, if everyone else wants markup in
> commit messages then I won't complain.

btw, I'm keeping my eyes open to see how easy it'd be to support
specific renderer for commit messages, with a simple/reasonable subset
of markdown (top-level unordered-lists, blockquotes by indentation,
code-blocks, emphasis, ``) in commit messages w/ the ability to link at
least to commit-hashes and ticket numbers...

Cheers,
  hvr

From iavor.diatchki at gmail.com  Thu Nov 14 18:53:34 2013
From: iavor.diatchki at gmail.com (Iavor Diatchki)
Date: Thu, 14 Nov 2013 10:53:34 -0800
Subject: [commit: ghc] master: Make type-level evaluation work with :kind!
 (b2fa2d4)
In-Reply-To: <59543203684B2244980D7E4057D5FBC14867B9E2@DB3EX14MBXC308.europe.corp.microsoft.com>
References: <20131113003637.4C4832406B@ghc.haskell.org>
 <59543203684B2244980D7E4057D5FBC14867B9E2@DB3EX14MBXC308.europe.corp.microsoft.com>
Message-ID: <CAGK9nuo6xhuk-Pm5qrJ0_xhuQ6w4s0LDu0W6ShCe8g_axdz2Jg@mail.gmail.com>

Good idea! I made the change in commit
 19b8809c477f4d296cbd6c1736e9a288fdcd6220.




On Wed, Nov 13, 2013 at 6:57 PM, Simon Peyton-Jones
<simonpj at microsoft.com>wrote:

> That is indeed revolting.
>
> Why not make
>     sfMatchFam :: [Type] -> Maybe (CoAxiomRule, [Type], Type)
> thus getting rid of the TcCoercion, and baking in the flaky assumption by
> construction.
>
> Then I think you can put the whole definition of TcBuiltInSynFamily (with
> a non-Tc name) into CoAxiom.
>
> Would that work?
>
> Simon
>
> | -----Original Message-----
> | From: ghc-commits [mailto:ghc-commits-bounces at haskell.org] On Behalf Of
> | git at git.haskell.org
> | Sent: 13 November 2013 00:37
> | To: ghc-commits at haskell.org
> | Subject: [commit: ghc] master: Make type-level evaluation work with
> | :kind! (b2fa2d4)
> |
> | Repository : ssh://git at git.haskell.org/ghc
> |
> | On branch  : master
> | Link       :
> | http://ghc.haskell.org/trac/ghc/changeset/b2fa2d41032882d3cf67be083489c
> | bcbf9e4ec07/ghc
> |
> | >---------------------------------------------------------------
> |
> | commit b2fa2d41032882d3cf67be083489cbcbf9e4ec07
> | Author: Iavor S. Diatchki <diatchki at galois.com>
> | Date:   Tue Nov 12 16:36:23 2013 -0800
> |
> |     Make type-level evaluation work with :kind!
> |
> |     The main change is to add a case to `reduceTyFamApp_maybe` to
> | evaluate
> |     built-in type constructors (e.g., (+), (*), and friends).
> |
> |     To avoid problems with recursive modules, I moved the definition of
> |     TcBuiltInSynFamily from `FamInst` to `FamInstEnv`.  I am still not
> | sure if
> |     this is the right place.
> |
> |     There is also a wibble that it'd be nice to fix:
> |
> |     when we evaluate a built-in type function, using`sfMatchFam`, we
> | get
> |     a `TcCoercion`.  However, `reduceTyFamApp_maybe` needs a
> | `Corecion`.
> |     I couldn't find a nice way to convert between the two, so I
> | resorted to
> |     a bit of hack (marked with `XXX`).
> |
> |     The hack is that we happen to know that the built-in constructors
> | for
> |     the type-nat functions always return coercions of shape
> | `TcAxiomRuleCo`,
> |     with no assumptions, so it easy to convert `TcCoercion` to
> | `Coercion`
> |     in this one case.  This is enough to make things work, but it is
> | clearly
> |     a cludge.
> |
> |
> | >---------------------------------------------------------------
> |
> | b2fa2d41032882d3cf67be083489cbcbf9e4ec07
> |  compiler/ghc.mk                                    |    2 +-
> |  compiler/typecheck/FamInst.lhs                     |   27 +-----------
> |  compiler/typecheck/TcInteract.lhs                  |    2 +-
> |  compiler/typecheck/TcTypeNats.hs                   |    2 +-
> |  compiler/types/FamInstEnv.lhs                      |   43
> | +++++++++++++++++++-
> |  .../FamInst.lhs-boot => types/FamInstEnv.lhs-boot} |    2 +-
> |  compiler/types/TyCon.lhs                           |    2 +-
> |  7 files changed, 47 insertions(+), 33 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
> | b2fa2d41032882d3cf67be083489cbcbf9e4ec07
> | _______________________________________________
> | ghc-commits mailing list
> | ghc-commits at haskell.org
> | http://www.haskell.org/mailman/listinfo/ghc-commits
> _______________________________________________
> 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/20131114/ff797dcd/attachment.html>

From mainland at apeiron.net  Thu Nov 14 19:25:25 2013
From: mainland at apeiron.net (Geoffrey Mainland)
Date: Thu, 14 Nov 2013 14:25:25 -0500
Subject: Out with the new, in with the old for the vector library WAS: [commit:
 packages/vector] ghc-head: Snapshot of the real 0.10.0.1 release
 (a3a65b5)
In-Reply-To: <20130926095437.082B024065@ghc.haskell.org>
References: <20130926095437.082B024065@ghc.haskell.org>
Message-ID: <528523A5.1030906@apeiron.net>

Hi Bryan,

I apologize for not bringing this issue up in a more timely fashion.

I'm curious why the Bundle support that Roman added to the vector
library was removed. I understand that the change in representation made
it difficult for, e.g., dph to use the new vector library, but this
change in representation was vital to our work on exploiting SIMD
instructions. FWIW, I have been maintaining (and rebasing) a set of
patches to DPH that allowed it to use Roman's new version of the vector
library.

If this is the path forward for the vector library, then I'm afraid
anyone who wants to get any real use out of the new SIMD primops in GHC
will be still stuck building their own version of the compiler using my
patched primitive, vector, and dph libraries. That also requires me to
maintain patched versions of these three libraries.

Perhaps the roll-back in functionality was just done to get 7.8 out the
door?

Thanks,
Geoff

On 09/26/2013 05:54 AM, git at git.haskell.org wrote:
> Repository : ssh://git at git.haskell.org/vector
>
> On branch  : ghc-head
> Link       :
http://git.haskell.org/packages/vector.git/commitdiff/a3a65b56a7d09e5166655c3877c389b7b71fb8af
>
>> ---------------------------------------------------------------
>
> commit a3a65b56a7d09e5166655c3877c389b7b71fb8af
> Author: Bryan O'Sullivan <bos at serpentine.com>
> Date:   Wed Sep 25 10:39:32 2013 -0700
>
>     Snapshot of the real 0.10.0.1 release
>
>
>> ---------------------------------------------------------------
>
> a3a65b56a7d09e5166655c3877c389b7b71fb8af
>  Data/Vector.hs                                |   16 +-
>  Data/Vector/Fusion/Bundle/Monadic.hs          | 1098
-------------------------
>  Data/Vector/Fusion/{Bundle.hs => Stream.hs}   |  361 ++++----
>  Data/Vector/Fusion/Stream/Monadic.hs          |  517 +++++-------
>  Data/Vector/Fusion/{Bundle => Stream}/Size.hs |    4 +-
>  Data/Vector/Generic.hs                        |  463 ++++++-----
>  Data/Vector/Generic/Base.hs                   |    4 +-
>  Data/Vector/Generic/Mutable.hs                |  273 +++---
>  Data/Vector/Generic/Mutable/Base.hs           |  135 ---
>  Data/Vector/Generic/New.hs                    |  103 ++-
>  Data/Vector/Primitive.hs                      |   16 +-
>  Data/Vector/Storable.hs                       |   16 +-
>  Data/Vector/Unboxed.hs                        |   16 +-
>  benchmarks/vector-benchmarks.cabal            |    4 +-
>  include/vector.h                              |   10 +-
>  internal/GenUnboxTuple.hs                     |    4 +-
>  internal/unbox-tuple-instances                |   30 +-
>  old-testsuite/Main.hs                         |   13 -
>  old-testsuite/Testsuite/Stream/AsList.hs      |  134 ---
>  old-testsuite/Testsuite/Stream/Errors.hs      |   41 -
>  old-testsuite/Testsuite/Utils/Generator.hs    |   22 -
>  old-testsuite/Testsuite/Utils/List.hs         |   25 -
>  old-testsuite/Testsuite/Utils/Property.hs     |  155 ----
>  old-testsuite/Testsuite/Utils/Test.hs         |  123 ---
>  old-testsuite/Testsuite/Vector/AsList.hs      |  174 ----
>  old-testsuite/Testsuite/Vector/Errors.hs      |   47 --
>  old-testsuite/microsuite/README               |    8 -
>  old-testsuite/microsuite/Test.hs              |  200 -----
>  old-testsuite/microsuite/and.hs               |    3 -
>  old-testsuite/microsuite/append.hs            |    5 -
>  old-testsuite/microsuite/cons.hs              |    3 -
>  old-testsuite/microsuite/drop.hs              |    4 -
>  old-testsuite/microsuite/elem.hs              |    4 -
>  old-testsuite/microsuite/empty.hs             |    3 -
>  old-testsuite/microsuite/eq.hs                |    6 -
>  old-testsuite/microsuite/filter.hs            |    4 -
>  old-testsuite/microsuite/find.hs              |    4 -
>  old-testsuite/microsuite/findIndex.hs         |    4 -
>  old-testsuite/microsuite/foldl1.hs            |    4 -
>  old-testsuite/microsuite/from-to.hs           |    2 -
>  old-testsuite/microsuite/head.hs              |    4 -
>  old-testsuite/microsuite/index.hs             |    3 -
>  old-testsuite/microsuite/init.hs              |    4 -
>  old-testsuite/microsuite/last.hs              |    4 -
>  old-testsuite/microsuite/length-bool.hs       |    3 -
>  old-testsuite/microsuite/length-char.hs       |    3 -
>  old-testsuite/microsuite/length-double.hs     |    3 -
>  old-testsuite/microsuite/length-float.hs      |    3 -
>  old-testsuite/microsuite/length-int16.hs      |    4 -
>  old-testsuite/microsuite/length-int32.hs      |    4 -
>  old-testsuite/microsuite/length-int64.hs      |    4 -
>  old-testsuite/microsuite/length-int8.hs       |    4 -
>  old-testsuite/microsuite/length-unit.hs       |    3 -
>  old-testsuite/microsuite/length-word.hs       |    4 -
>  old-testsuite/microsuite/length-word16.hs     |    4 -
>  old-testsuite/microsuite/length-word32.hs     |    4 -
>  old-testsuite/microsuite/length-word64.hs     |    4 -
>  old-testsuite/microsuite/length-word8.hs      |    4 -
>  old-testsuite/microsuite/length.hs            |    3 -
>  old-testsuite/microsuite/lookup.hs            |    5 -
>  old-testsuite/microsuite/map.hs               |    4 -
>  old-testsuite/microsuite/maximum.hs           |    4 -
>  old-testsuite/microsuite/maximumBy.hs         |    4 -
>  old-testsuite/microsuite/minimum.hs           |    4 -
>  old-testsuite/microsuite/minimumBy.hs         |    4 -
>  old-testsuite/microsuite/null-ndp.hs          |    3 -
>  old-testsuite/microsuite/null.hs              |    3 -
>  old-testsuite/microsuite/or.hs                |    3 -
>  old-testsuite/microsuite/product.hs           |    4 -
>  old-testsuite/microsuite/repeat.hs            |    4 -
>  old-testsuite/microsuite/replicate.hs         |    3 -
>  old-testsuite/microsuite/singleton.hs         |    3 -
>  old-testsuite/microsuite/snoc.hs              |    3 -
>  old-testsuite/microsuite/sum-complex.hs       |    5 -
>  old-testsuite/microsuite/sum-ratio.hs         |    5 -
>  old-testsuite/microsuite/sum.hs               |    8 -
>  old-testsuite/microsuite/tail.hs              |    4 -
>  old-testsuite/microsuite/take.hs              |    4 -
>  old-testsuite/microsuite/takeWhile.hs         |    7 -
>  old-testsuite/microsuite/unfold.hs            |    5 -
>  old-testsuite/microsuite/zip.hs               |    6 -
>  old-testsuite/microsuite/zipwith.hs           |    6 -
>  old-testsuite/microsuite/zipwith3.hs          |    7 -
>  tests/Main.hs                                 |    4 +-
>  tests/Tests/Bundle.hs                         |  163 ----
>  tests/Tests/Stream.hs                         |  163 ++++
>  tests/Tests/Vector.hs                         |    4 +-
>  tests/Utilities.hs                            |   16 +-
>  tests/vector-tests.cabal                      |    6 +-
>  vector.cabal                                  |   10 +-
>  90 files changed, 991 insertions(+), 3610 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
a3a65b56a7d09e5166655c3877c389b7b71fb8af
> _______________________________________________
> ghc-commits mailing list
> ghc-commits at haskell.org
> http://www.haskell.org/mailman/listinfo/ghc-commits
>



From bos at serpentine.com  Thu Nov 14 19:33:39 2013
From: bos at serpentine.com (Bryan O'Sullivan)
Date: Thu, 14 Nov 2013 11:33:39 -0800
Subject: Out with the new, in with the old for the vector library WAS:
 [commit: packages/vector] ghc-head: Snapshot of the real 0.10.0.1 release
 (a3a65b5)
In-Reply-To: <528523A5.1030906@apeiron.net>
References: <20130926095437.082B024065@ghc.haskell.org>
 <528523A5.1030906@apeiron.net>
Message-ID: <CACw0niKuAVWRJBJzLU0L5yRH8TTBtm4rH+pH_7jtYFoWqDM2XQ@mail.gmail.com>

On Thu, Nov 14, 2013 at 11:25 AM, Geoffrey Mainland <mainland at apeiron.net>wrote:

> Perhaps the roll-back in functionality was just done to get 7.8 out the
> door?
>

That's correct. Also, the vector repo was never properly tagged, so it was
impossible to untangle the work in progress on bundles from anything stable.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/ghc-devs/attachments/20131114/587cd7a2/attachment-0001.html>

From andreas.voellmy at gmail.com  Fri Nov 15 03:38:51 2013
From: andreas.voellmy at gmail.com (Andreas Voellmy)
Date: Thu, 14 Nov 2013 22:38:51 -0500
Subject: GHC 7.8 release status
In-Reply-To: <CADdwyZmyG9Tedtxch_MNcRm6wkc4Oj=JJtY27=50XAWHhNRL-A@mail.gmail.com>
References: <59543203684B2244980D7E4057D5FBC1485BD020@DB3EX14MBXC308.europe.corp.microsoft.com>
 <CACYs5AbC+SPCpa4qyVBbC-AztMiJ=OzLNmFne4pjnA_iRM58Pw@mail.gmail.com>
 <CAEs96n0HzaS_we9Xzxr=35P5H_eEda_SoV9RQrN0rUQzGTWqtQ@mail.gmail.com>
 <CACYs5AZgQooitEm3Mtm2NnYpD9JYLMC0ZfgCtubYbrn1qnnLeA@mail.gmail.com>
 <CADdwyZmyG9Tedtxch_MNcRm6wkc4Oj=JJtY27=50XAWHhNRL-A@mail.gmail.com>
Message-ID: <CADdwyZmuvyafpizqsaZ+1zM03y5RZPh7P7YPzkRt7fuDBR6TSg@mail.gmail.com>

I added a note about the parallel IO manager status to
https://ghc.haskell.org/trac/ghc/wiki/Status/GHC-7.8. There are two issues
I'd still like to resolve.  Is there a target date for the release?

-Andi


On Fri, Nov 8, 2013 at 12:02 AM, Andreas Voellmy
<andreas.voellmy at gmail.com>wrote:

> Yes, the parallel IO manager is new in 7.8. Thanks for reminding me of
> that excessive system time issue. That's been nagging me for a while.
> Hopefully I can find some time in the coming days to look at this again.
>
> -Andi
>
>
> On Wed, Sep 4, 2013 at 11:42 AM, Ryan Newton <rrnewton at gmail.com> wrote:
>
>> By the way, the parallel IO manager is also new in 7.8 right?  I'm not
>> sure but I think it may have something to do with the excessive system time
>> bug I just filed:
>>
>>     http://ghc.haskell.org/trac/ghc/ticket/8224
>>
>>
>>
>> _______________________________________________
>> 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/20131114/82042c7b/attachment.html>

From andreas.voellmy at gmail.com  Fri Nov 15 03:40:08 2013
From: andreas.voellmy at gmail.com (Andreas Voellmy)
Date: Thu, 14 Nov 2013 22:40:08 -0500
Subject: GHC 7.8 release status
In-Reply-To: <CADdwyZmuvyafpizqsaZ+1zM03y5RZPh7P7YPzkRt7fuDBR6TSg@mail.gmail.com>
References: <59543203684B2244980D7E4057D5FBC1485BD020@DB3EX14MBXC308.europe.corp.microsoft.com>
 <CACYs5AbC+SPCpa4qyVBbC-AztMiJ=OzLNmFne4pjnA_iRM58Pw@mail.gmail.com>
 <CAEs96n0HzaS_we9Xzxr=35P5H_eEda_SoV9RQrN0rUQzGTWqtQ@mail.gmail.com>
 <CACYs5AZgQooitEm3Mtm2NnYpD9JYLMC0ZfgCtubYbrn1qnnLeA@mail.gmail.com>
 <CADdwyZmyG9Tedtxch_MNcRm6wkc4Oj=JJtY27=50XAWHhNRL-A@mail.gmail.com>
 <CADdwyZmuvyafpizqsaZ+1zM03y5RZPh7P7YPzkRt7fuDBR6TSg@mail.gmail.com>
Message-ID: <CADdwyZ=e2ir3_YSi8mVSBvvr_tXJQpBw0QmBs8+0UugcrtKugw@mail.gmail.com>

On Thu, Nov 14, 2013 at 10:38 PM, Andreas Voellmy <andreas.voellmy at gmail.com
> wrote:

> I added a note about the parallel IO manager status to
> https://ghc.haskell.org/trac/ghc/wiki/Status/GHC-7.8. There are two
> issues I'd still like to resolve.  Is there a target date for the release?
>

Oh, I just noticed
http://permalink.gmane.org/gmane.comp.lang.haskell.ghc.devel/2569 which
answers my question (target is Nov. 25).


>
> -Andi
>
>
> On Fri, Nov 8, 2013 at 12:02 AM, Andreas Voellmy <
> andreas.voellmy at gmail.com> wrote:
>
>> Yes, the parallel IO manager is new in 7.8. Thanks for reminding me of
>> that excessive system time issue. That's been nagging me for a while.
>> Hopefully I can find some time in the coming days to look at this again.
>>
>> -Andi
>>
>>
>> On Wed, Sep 4, 2013 at 11:42 AM, Ryan Newton <rrnewton at gmail.com> wrote:
>>
>>> By the way, the parallel IO manager is also new in 7.8 right?  I'm not
>>> sure but I think it may have something to do with the excessive system time
>>> bug I just filed:
>>>
>>>     http://ghc.haskell.org/trac/ghc/ticket/8224
>>>
>>>
>>>
>>> _______________________________________________
>>> 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/20131114/40ffaae5/attachment.html>

From nicolas.frisby at gmail.com  Fri Nov 15 05:45:29 2013
From: nicolas.frisby at gmail.com (Nicolas Frisby)
Date: Thu, 14 Nov 2013 23:45:29 -0600
Subject: GHC 7.8 release status
In-Reply-To: <CADdwyZ=e2ir3_YSi8mVSBvvr_tXJQpBw0QmBs8+0UugcrtKugw@mail.gmail.com>
References: <59543203684B2244980D7E4057D5FBC1485BD020@DB3EX14MBXC308.europe.corp.microsoft.com>
 <CACYs5AbC+SPCpa4qyVBbC-AztMiJ=OzLNmFne4pjnA_iRM58Pw@mail.gmail.com>
 <CAEs96n0HzaS_we9Xzxr=35P5H_eEda_SoV9RQrN0rUQzGTWqtQ@mail.gmail.com>
 <CACYs5AZgQooitEm3Mtm2NnYpD9JYLMC0ZfgCtubYbrn1qnnLeA@mail.gmail.com>
 <CADdwyZmyG9Tedtxch_MNcRm6wkc4Oj=JJtY27=50XAWHhNRL-A@mail.gmail.com>
 <CADdwyZmuvyafpizqsaZ+1zM03y5RZPh7P7YPzkRt7fuDBR6TSg@mail.gmail.com>
 <CADdwyZ=e2ir3_YSi8mVSBvvr_tXJQpBw0QmBs8+0UugcrtKugw@mail.gmail.com>
Message-ID: <CADfHYo5v2PKmTnf9cU8=AWo4-cC-TyPCmj4BupLnyZj7Yff7_A@mail.gmail.com>

Unless I missed an RC announcement, I'm pretty sure we're running a little
behind the schedule from that email.

Deciders, has the Nov 25 target slid back? Any new estimates, if so?

Thanks much.
On Nov 14, 2013 9:40 PM, "Andreas Voellmy" <andreas.voellmy at gmail.com>
wrote:

>
>
>
> On Thu, Nov 14, 2013 at 10:38 PM, Andreas Voellmy <
> andreas.voellmy at gmail.com> wrote:
>
>> I added a note about the parallel IO manager status to
>> https://ghc.haskell.org/trac/ghc/wiki/Status/GHC-7.8. There are two
>> issues I'd still like to resolve.  Is there a target date for the release?
>>
>
> Oh, I just noticed
> http://permalink.gmane.org/gmane.comp.lang.haskell.ghc.devel/2569 which
> answers my question (target is Nov. 25).
>
>
>>
>> -Andi
>>
>>
>> On Fri, Nov 8, 2013 at 12:02 AM, Andreas Voellmy <
>> andreas.voellmy at gmail.com> wrote:
>>
>>> Yes, the parallel IO manager is new in 7.8. Thanks for reminding me of
>>> that excessive system time issue. That's been nagging me for a while.
>>> Hopefully I can find some time in the coming days to look at this again.
>>>
>>> -Andi
>>>
>>>
>>> On Wed, Sep 4, 2013 at 11:42 AM, Ryan Newton <rrnewton at gmail.com> wrote:
>>>
>>>> By the way, the parallel IO manager is also new in 7.8 right?  I'm not
>>>> sure but I think it may have something to do with the excessive system time
>>>> bug I just filed:
>>>>
>>>>     http://ghc.haskell.org/trac/ghc/ticket/8224
>>>>
>>>>
>>>>
>>>> _______________________________________________
>>>> 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/20131114/d54d53e7/attachment.html>

From simonpj at microsoft.com  Fri Nov 15 07:38:52 2013
From: simonpj at microsoft.com (Simon Peyton-Jones)
Date: Fri, 15 Nov 2013 07:38:52 +0000
Subject: Trac formatting
In-Reply-To: <1384271585.2456.37.camel@kirk>
References: <59543203684B2244980D7E4057D5FBC148677A0A@DB3EX14MBXC308.europe.corp.microsoft.com>
 <1384271585.2456.37.camel@kirk>
Message-ID: <59543203684B2244980D7E4057D5FBC148684A59@DB3EX14MBXC306.europe.corp.microsoft.com>

Personally I think commit messages should be formatting-free. 
* I type them into an emacs buffer, with no way to preview any formatting.
* When viewing with git log or other such tools, the formatting just
   gets in the way

Is it easy to change?

Simon

| -----Original Message-----
| From: ghc-devs [mailto:ghc-devs-bounces at haskell.org] On Behalf Of
| Joachim Breitner
| Sent: 12 November 2013 15:53
| To: ghc-devs at haskell.org
| Subject: Re: Trac formatting
| 
| Hi,
| 
| Am Dienstag, den 12.11.2013, 15:24 +0000 schrieb Simon Peyton-Jones:
| > When Trac formats commit messages it is doing a terrible job.  See for
| > example: https://ghc.haskell.org/trac/ghc/ticket/5996
| >
| > The commit message is nigh illegible until typeset without makup (see
| > comment 10).
| 
| I believe it is a feature, not a bug: Trac encourages you to use
| markdown markup (which supposedly looks good also in plain text) in your
| commit messages. This not only makes them look nice, provides additional
| features like automatic linking (compare the reference to #5996 in
| comment 9 and comment 10).
| 
| In this case the tables should have been indented by 4 spaces, or
| surrounded by {{{..}}}, in the commit message to make it come out
| nicely.
| 
| Whether this is desirable is a different question. I like it, but the
| heavy users of the repository and trac need to decide what they prefer ?
| the ability to use markup in the commit messages, or the freedom to do
| any kind of ascii art.
| 
| Greetings,
| Joachim
| 
| 
| --
| Joachim Breitner
|   e-Mail: mail at joachim-breitner.de
|   Homepage: http://www.joachim-breitner.de
|   Jabber-ID: nomeata at joachim-breitner.de


From christiaan.baaij at gmail.com  Fri Nov 15 08:04:30 2013
From: christiaan.baaij at gmail.com (Christiaan Baaij)
Date: Fri, 15 Nov 2013 09:04:30 +0100
Subject: Validate broken on Snow Leopard and Mountain Lion
In-Reply-To: <1053217B-1C60-4E20-A8B8-CCF9FF9A0BD1@gmail.com>
References: <21E81090-2380-4DF9-96F7-86773FCEC65C@ouroborus.net>
 <7ECCA023-9D11-4423-BEA5-3ADA6D1D8588@gmail.com>
 <F59FB7DC-0CED-4F6B-AD8E-A343E66DEA3B@ouroborus.net>
 <CAHYVw0yCxAagJxCB3Mw=OH=DadneW-Rc5Okqk2N_DxL_x2qBrg@mail.gmail.com>
 <1053217B-1C60-4E20-A8B8-CCF9FF9A0BD1@gmail.com>
Message-ID: <5D787D9D-E8D6-4C9E-8102-D9954DA43763@gmail.com>

I'm still puzzled as to how validate failed on snow leopard, but is working correctly on my mountain lion machine after fixing the warning in the primitive package.
Ben: does validate go through on your machine after patching the primitive package?

Here are my results for 'validate --slow':

OVERALL SUMMARY for test run started at Thu Nov 14 14:32:18 2013 CET
 4:15:58 spent to go through
    3818 total tests, which gave rise to
   14934 test cases, of which
    3146 were skipped

     145 had missing libraries
   11465 expected passes
     137 expected failures

       0 caused framework failures
       5 unexpected passes
      36 unexpected failures

Unexpected passes:
   codeGen/should_run           cgrun071 (optllvm)
   ghci/linking                 T3333 (normal)
   rename/should_compile/T3103  T3103 (hpc,optasm,optllvm)

Unexpected failures:
   ../../libraries/unix/tests  signals004 [bad exit code] (threaded2)
   concurrent/should_run       conc012 [bad exit code] (ghci)
   driver                      static001 [bad stderr] (normal)
   gadt                        type-rep [exit code non-0] (hpc,optasm,threaded2,dyn,optllvm)
   ghc-api/apirecomp001        apirecomp001 [bad stderr] (normal)
   lib/integer                 integerConstantFolding [bad stderr] (normal)
   perf/compiler               T3064 [stat not good enough] (normal)
   perf/compiler               T3294 [stderr mismatch] (normal)
   perf/compiler               T4801 [stat too good] (normal)
   perf/compiler               T5642 [stat not good enough] (normal)
   perf/haddock                haddock.Cabal [stat not good enough] (normal)
   perf/haddock                haddock.compiler [stat not good enough] (normal)
   perf/space_leaks            space_leak_001 [stat too good] (hpc,optasm,dyn,optllvm)
   polykinds                   T6068 [bad stderr] (ghci)
   rts                         T7919 [exit code non-0] (normal,hpc,optasm,threaded1,threaded2,optllvm)
   th/TH_import_loop           TH_import_loop [bad stdout or stderr] (ghci)
   typecheck/should_run        T7861 [bad stderr] (normal,hpc,optasm,threaded1,threaded2,dyn,optllvm)
   typecheck/should_run        T7861 [bad stdout or stderr] (ghci)

On Nov 14, 2013, at 12:04 PM, Christiaan Baaij <christiaan.baaij at gmail.com> wrote:

> After fixing the warning in the C-code of the primitive package, validate (including dph tests) seems to be working for me:
> 
> OVERALL SUMMARY for test run started at Thu Nov 14 11:03:26 2013 CET
> 0:46:34 spent to go through
>    3818 total tests, which gave rise to
>   14930 test cases, of which
>   11445 were skipped
> 
>      28 had missing libraries
>    3394 expected passes
>      58 expected failures
> 
>       0 caused framework failures
>       1 unexpected passes
>       4 unexpected failures
> 
> Unexpected passes:
>   ghci/linking  T3333 (normal)
> 
> Unexpected failures:
>   driver         static001 [bad stderr] (normal)
>   driver/T3007   T3007 [bad exit code] (normal)
>   perf/compiler  T3064 [stat not good enough] (normal)
>   perf/compiler  T4801 [stat too good] (normal)
> 
> I'll try again with a 'make maintainer-clean', include profiling libs, and do a ./validate --slow.
> 
> 
> On Nov 14, 2013, at 5:23 AM, Carter Schonwald <carter.schonwald at gmail.com> wrote:
> 
>> Ben has an excellent point: 
>> 
>> if things are broken on mac, lets fix it!  Especially since we should be hitting RC status shortly.... any breakages should be smashed ASAP.
>> 
>> This does raise a point I hope we'll address more aggressively after the 7.8 release, namely trying to keep ghc less broken by default! GHC being really really really broken between releases is probably the single HUGEST barrier to more people getting involved in helping GHC dev. And I think thats a huge problem we need to take more seriously. 
>> 
>> 
>> 
>> 
>> On Wed, Nov 13, 2013 at 11:09 PM, Ben Lippmeier <benl at ouroborus.net> wrote:
>> 
>> On 13/11/2013, at 8:02 PM, Christiaan Baaij wrote:
>> 
>>> Does validate work for the DPH packages on Linux?
>> 
>> "sh validate" runs fine on my Linux machine, but neither of my Macs.
>> 
>> I can also run the dph tests manually on Linux, and they work fine.
>> 
>> Ben.
>> 
>> _______________________________________________
>> ghc-devs mailing list
>> ghc-devs at haskell.org
>> http://www.haskell.org/mailman/listinfo/ghc-devs
>> 
> 


From simonpj at microsoft.com  Fri Nov 15 09:39:29 2013
From: simonpj at microsoft.com (Simon Peyton-Jones)
Date: Fri, 15 Nov 2013 09:39:29 +0000
Subject: Trac formatting
In-Reply-To: <878uwrthrh.fsf@gnu.org>
References: <59543203684B2244980D7E4057D5FBC148677A0A@DB3EX14MBXC308.europe.corp.microsoft.com>
 <1384271585.2456.37.camel@kirk> <5283561D.5090702@gmail.com>
 <878uwrthrh.fsf@gnu.org>
Message-ID: <59543203684B2244980D7E4057D5FBC1486872A4@DB3EX14MBXC306.europe.corp.microsoft.com>

I like it better now, thank you.

But look at https://ghc.haskell.org/trac/ghc/ticket/4175

Notice the lovely formatting of comment 10, 11.  

* The typewriter font is set off as it usually is with {{{...}}}
* The list of files changed is included (a la git log --stat)

Neither shows up in comment 13, the new style.

Would it be possible to get the old style back?

Thanks

Simon

| -----Original Message-----
| From: ghc-devs [mailto:ghc-devs-bounces at haskell.org] On Behalf Of
| Herbert Valerio Riedel
| Sent: 14 November 2013 10:12
| To: Simon Marlow
| Cc: Joachim Breitner; ghc-devs at haskell.org
| Subject: Re: Trac formatting
| 
| On 2013-11-13 at 11:36:13 +0100, Simon Marlow wrote:
| > On 12/11/13 15:53, Joachim Breitner wrote:
| >
| >> Am Dienstag, den 12.11.2013, 15:24 +0000 schrieb Simon Peyton-Jones:
| >>> When Trac formats commit messages it is doing a terrible job.  See
| for
| >>> example: https://ghc.haskell.org/trac/ghc/ticket/5996
| >>>
| >>> The commit message is nigh illegible until typeset without makup
| (see
| >>> comment 10).
| >>
| >> I believe it is a feature, not a bug: Trac encourages you to use
| >> markdown markup (which supposedly looks good also in plain text) in
| your
| >> commit messages. This not only makes them look nice, provides
| additional
| >> features like automatic linking (compare the reference to #5996 in
| >> comment 9 and comment 10).
| >>
| >> In this case the tables should have been indented by 4 spaces, or
| >> surrounded by {{{..}}}, in the commit message to make it come out
| >> nicely.
| >>
| >> Whether this is desirable is a different question. I like it, but the
| >> heavy users of the repository and trac need to decide what they
| prefer ?
| >> the ability to use markup in the commit messages, or the freedom to
| do
| >> any kind of ascii art.
| >
| > I'm with Simon on this one.  I much preferred the old plain-text
| > rendering of commit messages.
| 
| Luckily, this is an exposed trac.ini setting
| (for future reference: changeset.wiki_format_messages)
| 
| I've disabled wiki-rendering for commit messages so you can see the
| effect. As Joachim already observed, since this is an an all-or-nothing
| setting, you lose automatic hyperlinking to Trac tickets, Wiki pages,
| other changesets, and even HTTP URLs in every places where commit
| messages are rendered.
| 
| See for instance,
| 
| 
| https://ghc.haskell.org/trac/ghc/changeset/5a3918febb7354e0900c4f0415159
| 9d833716032/ghc
| 
| where you have to manually lookup the ticket-no. as well as the
| commit-id of the referenced other commit that this commit tries to
| compensate for.
| 
| So this undermines one of Trac's principal design goals, that is
| 
|     "Trac allows wiki markup in issue descriptions and commit messages,
|     creating links and seamless references between bugs, tasks,
|     changesets, files and wiki pages."
| 
| as is written in the introductory front-page at http://trac.edgewall.org
| 
| > I don't want to start using a particular markup format (which is not
| > markdown, it's Trac's own format AIUI) in our commit messages.  What
| > happens if we switch from Trac to something else in the future?
| 
| It's an unfortunate situation that when Trac came to life around 2005 it
| wasn't clear that Markdown would become so popular (and it couldn't have
| been used as-is without syntax extensions to allow seamless hyperlinks).
| 
| However, if you don't like Trac's Wiki markup and its primary goal of
| tight & seamless hyperlinking from everywhere to everywhere, why did you
| chose to deploy Trac in the first place? After all, should the GHC
| project ever want to switch from Trac to something else, converting the
| existing Trac tickets and the GHC Wiki Commentary will be quite an
| undertaking retaining the crossrefs as well as stripping out all
| Trac-isms... just saying...
| 
| PS: Btw, fwiw, http://trac.edgewall.org/wiki/WikiCreole.
| 
| Cheers,
|   hvr
| _______________________________________________
| ghc-devs mailing list
| ghc-devs at haskell.org
| http://www.haskell.org/mailman/listinfo/ghc-devs

From mail at joachim-breitner.de  Fri Nov 15 10:21:08 2013
From: mail at joachim-breitner.de (Joachim Breitner)
Date: Fri, 15 Nov 2013 11:21:08 +0100
Subject: topHandler03 failing
Message-ID: <1384510868.2582.2.camel@kirk>

Hi,

I don?t trust the travis setup enough to automatically relay failures,
so I do it manually. Since these patches:

Changes to ghc:
commit 12cdd6d
Author: Duncan Coutts <duncan at well-typed.com>
Date:   Thu Nov 14 16:02:03 2013 +0000

    Don translate UserInterrupt into ExitFailure 1, let it propagate

    It is important that if a program recieved ^C from the user, and the
    program terminates as a result, that it exit with SIGINT so that the
    parent process knows that was the case. For example cabal calling ghc
    will then be able to tell the difference between it failing and the user
    interrupting with ^C and report (or not) appropriately.

    So we should just let the UserInterrupt exception propagate to the top
    level error handler which will do the right thing.

    See http://www.cons.org/cracauer/sigint.html

commit a987b80
Author: Duncan Coutts <duncan at well-typed.com>
Date:   Thu Nov 14 15:54:13 2013 +0000

    Improve the shutdownHaskellAndSignal and add fast exit

    This is the RTS part of a patch to base's topHandler to handle exiting
    by a signal.

    The intended behaviour is that on Unix, throwing ExitFailure (-sig)
    results in the process terminating with that signal. Previously
    shutdownHaskellAndSignal was only used for exiting with SIGINT due to
    the UserInterrupt exception.

    Improve shutdownHaskellAndSignal to do the signal part more carefully.
    In particular, it (should) now reliably terminates the process one way
    or another. Previusly if the signal was blocked, ignored or handled then
    shutdownHaskellAndSignal would actually return!

    Also, the topHandler code has two paths a careful shutdown and a "fast
    exit" where it does not give finalisers a chance to run. We want to
    support that mode also when we want to exit by signal. So rather than
    the base code directly calling stg_exit as it did before, we have a
    fastExit bool paramater for both shutdownHaskellAnd{Exit,Signal}.

Changes to base:
commit dd00004
Author: Duncan Coutts <duncan at well-typed.com>
Date:   Thu Nov 14 15:16:30 2013 +0000

    Add tests for the top level exception handler

    The top level exception handler is wrapped around main, and FFI exports.
    It handles exceptions that are not otherwise caught in user code. For
    most exception is just prints them, but handles a few specially,
    including ExitCode and UserInterrupt.

    On Unix it installs a signal handler for SIGINT to translate it into a
    UserInterrupt async exception.

    So we test that:

    1. receiving SIGINT does trigger a UserInterrupt async exception
    2. an unhandled UserInterrupt makes us kill ourselves with SIGINT
    3. an unhandled ExitFailure (-sig) makes us kill ourselves with sig

commit 6b22a6e
Author: Duncan Coutts <duncan at well-typed.com>
Date:   Thu Nov 14 15:15:31 2013 +0000

    Handle ExitFailure (-sig) by killing process with signal

    On Unix we now use negative exit codes in ExitFailure to indicate that a
    process exited due to a signal. This patch implements the case for when
    a ExitFailure exception propagates out of the top of main (and is
    handled by the topHandler).

    For a negative ExitFailure code, we try to kill the process using that
    signal (the details of that are handled by shutdownHaskellAndSignal from
    the RTS). For an exit code outside the valid ranges, we use 0xff.

Changes to process:
commit 3ebbe13
Author: Duncan Coutts <duncan at well-typed.com>
Date:   Thu Nov 14 13:59:57 2013 +0000

    Change the unix ExitCode encoding again! Now simply -signum

    So rather than a bitfield encoding, covering normal exit codes, signals
    and core dumps, we now simply use negative numbers for signal exit
    codes. We thus do not report core dumps by this mechanism.

    This encoding is a lot simpler to explain and use. It also happens to be
    the same encoding as Python's subprocess package uses.

    Anyone who cares about core dumps can still use the unix package.

I get this failure on travis:

=====> topHandler03(normal) 3622 of 3821 [0, 0, 0] 
Actual stderr output differs from expected:
--- /dev/null	2013-11-14 17:46:34.724312327 +0000
+++ ../../libraries/base/tests/topHandler03.run.stderr	2013-11-14 18:24:52.367542630 +0000
@@ -0,0 +1 @@
+Terminated
*** unexpected failure for topHandler03(normal)

(Full log at https://s3.amazonaws.com/archive.travis-ci.org/jobs/13982142/log.txt)

Does anyone feel responsible?

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: 198 bytes
Desc: This is a digitally signed message part
URL: <http://www.haskell.org/pipermail/ghc-devs/attachments/20131115/cb18d907/attachment.sig>

From duncan at well-typed.com  Fri Nov 15 14:06:32 2013
From: duncan at well-typed.com (Duncan Coutts)
Date: Fri, 15 Nov 2013 14:06:32 +0000
Subject: topHandler03 failing
In-Reply-To: <1384510868.2582.2.camel@kirk>
References: <1384510868.2582.2.camel@kirk>
Message-ID: <1384524392.7607.119.camel@dunky.localdomain>

On Fri, 2013-11-15 at 11:21 +0100, Joachim Breitner wrote:
> Hi,
> 
> I don?t trust the travis setup enough to automatically relay failures,
> so I do it manually. Since these patches:
> 
> Changes to ghc:
> Changes to base:
> commit dd00004
> Author: Duncan Coutts <duncan at well-typed.com>
> Date:   Thu Nov 14 15:16:30 2013 +0000
> 
>     Add tests for the top level exception handler

>     So we test that:

>     3. an unhandled ExitFailure (-sig) makes us kill ourselves with sig

[..snip..]

> I get this failure on travis:
> 
> =====> topHandler03(normal) 3622 of 3821 [0, 0, 0] 
> Actual stderr output differs from expected:
> --- /dev/null	2013-11-14 17:46:34.724312327 +0000
> +++ ../../libraries/base/tests/topHandler03.run.stderr	2013-11-14 18:24:52.367542630 +0000
> @@ -0,0 +1 @@
> +Terminated

> Does anyone feel responsible?

Yep, that'd be me.

Turns out it's an annoying difference in shell behaviour between systems
(or maybe even configurations). When a process exits with a signal, some
shells print out a line indicating what the signal was, e.g.
"Terminated" for SIGTERM, oh "Hangup" for SIGHUP.

$ sh -c 'kill -TERM $$'
Terminated

For some reason on my system I didn't get any message so I didn't
notice. Anyway, the solution was to annotate the test runner so it
ignores stdout for that test.

I have no idea why our python test framework is running the Haskell
progs via a shell, rather than directly. It also means that the exit
code handling is rather messed up (see the python test driver code for
all the e << 8, e >> 8 bit twiddling madness); instead of cleanly
getting the exit signal, we get an encoding using 128 + sig.

-- 
Duncan Coutts, Haskell Consultant
Well-Typed LLP, http://www.well-typed.com/


From eir at cis.upenn.edu  Fri Nov 15 14:56:48 2013
From: eir at cis.upenn.edu (Richard Eisenberg)
Date: Fri, 15 Nov 2013 09:56:48 -0500
Subject: templateHaskellNames
Message-ID: <87A4475C-1E4A-4646-ABD0-B5216BE93C09@cis.upenn.edu>

Hi devs,

I happened to be looking through the code dealing with known names, and I'm a little confused about templateHaskellNames. In particular, I'm confused why it's included in knownKeyNames only when GHCI is defined. (See lines 196-198 of HscMain.) It's the stage 1 compiler that compiles the TH library, when the known key names are so important. Couldn't this cause very strange behavior if some of the numbers are changed? Or, am I misunderstanding something here?

This is certainly a minor problem, but it could give someone down the road a headache if it were to happen.

Thanks,
Richard

From michal.palka at chalmers.se  Fri Nov 15 16:38:39 2013
From: michal.palka at chalmers.se (=?UTF-8?Q?Micha=C5=82_Pa=C5=82ka?=)
Date: Fri, 15 Nov 2013 17:38:39 +0100
Subject: Fwd: Any GHC plans to adopt tf-random?
In-Reply-To: <984FAE40-0D5F-4776-9846-E33242357BAE@gmail.com>
References: <CACYs5AY4k9NAvRs-W9Szcv2FHwtvOiYw_Yz5CJ1EJ+B+BJSSCw@mail.gmail.com>
 <984FAE40-0D5F-4776-9846-E33242357BAE@gmail.com>
Message-ID: <1384533519.2752.5.camel@michal-Latitude-E6410>

Hello Ryan and Nicolas,

I'm happy to see some interest in the tf-random package.

The package has not been extensively tested. I ran it on x86-64 and x86
Linux, and on x86 Windows. It would be good to check if it gives the
same results on a big-endian architecture, such as ARM, however I don't
have access to such a machine.

When it comes to the performance, it is good on x86-64, but
significantly slower on x86, and probably on other 32-bit architectures,
because the cipher's code is optimised for 64-bit arithmetic. It may be
possible to use a 32-bit optimised version for the 32-bit architectures
to mitigate that, but that would mean even more C code to review.

Another issue is whether to change the RandomGen/Random API, which might
be considered at the same time. The current Random instances are slow,
suffer from the modulo bias, and work only when the range of numbers
returned by the generator is (0, 2147483562). However, I am aware that
the disturbance would potentially be much larger if the API is changed,
so doing it may need some planning.

Ideally, it would be nice if people started using the package and see
how it performs in practice before any decisions are made.

Best regards,
Micha?

> Begin forwarded message:

> > From: Ryan Newton <rrnewton at gmail.com>
> > Subject: Re: Any GHC plans to adopt tf-random?
> > Date: 6 november 2013 22:51:02 CET
> > To: Nicolas Frisby <nicolas.frisby at gmail.com>
> > Cc: "ghc-devs at haskell.org" <ghc-devs at haskell.org>
> > Reply-To: rrnewton at gmail.com

> > Hi all,

> > It looks like since the paper has come out the code has been
> > released to Hackage.  I personally would love to replace
> > System.Random with something like this.

> > I think the question of whether it's time comes down to some
> > due-diligence issues outside the scope of the paper.  This library
> > has C code, have people tested it extensively on Mac/Linux/Windows?
> >  Does it have any performance divots we should know about?  (Though
> > the performance of the legacy implementation was bad in many
> > respects -- it 
> > is a low bar.)

> >   -Ryan
> > 


> > 
> > On Wed, Nov 6, 2013 at 3:12 PM, Nicolas Frisby
> > <nicolas.frisby at gmail.com> wrote:
> >         Adding Ryan Newton to the TO field, as the maintainer of
> >         random.
> >         
> >         
> >         On Wed, Nov 6, 2013 at 2:02 PM, Nicolas Frisby
> >         <nicolas.frisby at gmail.com> wrote:
> >                 Bugs #3575 #3620 have to do with splitting StdGens
> >                 yielding dependent generators.
> >                 
> >                 The Haskell 2013 paper Splittable Pseudorandom
> >                 Number Generators Using Cryptographic Hashing by
> >                 Claessen and Pa?ka yielded the tf-random package on
> >                 Hackage.
> >                 
> >                 Are there any plans to integrate these corrections
> >                 into System.Random?

> >                 Thanks.
> >                 


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







From mail at joachim-breitner.de  Fri Nov 15 21:32:43 2013
From: mail at joachim-breitner.de (Joachim Breitner)
Date: Fri, 15 Nov 2013 21:32:43 +0000
Subject: tcfail174, T2494 and Simple14 failing
Message-ID: <1384551163.4193.6.camel@kirk>

Hi,

thanks to Duncan for fixing topHandler03. Three new tests are however
failing:

=====> T2494(normal) 805 of 3821 [0, 0, 0] 
Actual stderr output differs from expected:
--- ./typecheck/should_compile/T2494.stderr	2013-11-15 19:07:53.298771915 +0000
+++ ./typecheck/should_compile/T2494.comp.stderr	2013-11-15 19:41:46.626713597 +0000
@@ -1,10 +1,10 @@
 
 T2494.hs:15:14:
-    Couldn't match type ?a? with ?b?
-      ?a? is a rigid type variable bound by
-          the RULE "foo/foo" at T2494.hs:13:16
+    Couldn't match type ?b? with ?a?
       ?b? is a rigid type variable bound by
           the RULE "foo/foo" at T2494.hs:14:16
+      ?a? is a rigid type variable bound by
+          the RULE "foo/foo" at T2494.hs:13:16
     Expected type: Maybe (m a) -> Maybe (m a)
       Actual type: Maybe (m b) -> Maybe (m b)
     Relevant bindings include
@@ -17,11 +17,11 @@
     In the second argument of ?foo?, namely ?(foo g x)?
 
 T2494.hs:15:30:
-    Couldn't match type ?a? with ?b?
-      ?a? is a rigid type variable bound by
-          the RULE "foo/foo" at T2494.hs:13:16
+    Couldn't match type ?b? with ?a?
       ?b? is a rigid type variable bound by
           the RULE "foo/foo" at T2494.hs:14:16
+      ?a? is a rigid type variable bound by
+          the RULE "foo/foo" at T2494.hs:13:16
     Expected type: Maybe (m a) -> Maybe (m a)
       Actual type: Maybe (m b) -> Maybe (m b)
     Relevant bindings include
*** unexpected failure for T2494(normal)


=====> tcfail174(normal) 1068 of 3821 [0, 1, 0] 
Actual stderr output differs from expected:
--- ./typecheck/should_fail/tcfail174.stderr	2013-11-15 19:07:53.462762490 +0000
+++ ./typecheck/should_fail/tcfail174.comp.stderr	2013-11-15 19:42:10.823320120 +0000
@@ -6,11 +6,11 @@
     In the expression: Base id
 
 tcfail174.hs:13:14:
-    Couldn't match type ?a? with ?a1?
-      because type variable ?a1? would escape its scope
-    This (rigid, skolem) type variable is bound by
-      the type forall a2. a2 -> a2
-      at tcfail174.hs:13:14
+    Couldn't match type ?a1? with ?a?
+      ?a1? is a rigid type variable bound by
+           the type forall a2. a2 -> a2 at tcfail174.hs:13:14
+      ?a? is a rigid type variable bound by
+          the inferred type of h1 :: Capture a at tcfail174.hs:13:1
     Expected type: Capture (forall x. x -> a)
       Actual type: Capture (forall a. a -> a)
     Relevant bindings include
*** unexpected failure for tcfail174(normal)


=====> Simple14(normal) 3306 of 3821 [0, 2, 0] 
Actual stderr output differs from expected:
--- ./indexed-types/should_compile/Simple14.stderr	2013-11-15
19:07:52.465819783 +0000
+++ ./indexed-types/should_compile/Simple14.comp.stderr	2013-11-15
19:48:37.218070046 +0000
@@ -1,8 +1,7 @@
 
 Simple14.hs:17:19:
-    Couldn't match type ?z0? with ?n?
-      ?z0? is untouchable
-        inside the constraints (Maybe m ~ Maybe n)
+    Could not deduce (n ~ z0)
+    from the context (Maybe m ~ Maybe n)
         bound by a type expected by the context:
                    Maybe m ~ Maybe n => EQ_ z0 z0
         at Simple14.hs:17:12-33
*** unexpected failure for Simple14(normal)


I guess these have been introduced by SPJ?s most recent changes
(https://github.com/nomeata/ghc-complete/commit/a8030acfc591f4069c27c9df86a806ddb6a30003)

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: 198 bytes
Desc: This is a digitally signed message part
URL: <http://www.haskell.org/pipermail/ghc-devs/attachments/20131115/4d918b74/attachment.sig>

From duncan.coutts at googlemail.com  Fri Nov 15 21:59:46 2013
From: duncan.coutts at googlemail.com (Duncan Coutts)
Date: Fri, 15 Nov 2013 21:59:46 +0000
Subject: Behaviour of readProcess, and code simplicity (or lack thereof)
Message-ID: <1384552786.7607.141.camel@dunky.localdomain>

Hi possibly-interested souls,

In this patch to System.Process.readProcess from last year:

https://ghc.haskell.org/trac/ghc/changeset/b5ee908863882d18e4110d96b43ccc1bb5068ceb/process

Bas changed things so that if an async exception is received by the
thread calling readProcess (or readProcessWithExitCode) then the
external process gets forcibly terminated. I do mean forcibly, it's
TerminateProcess() on Windows and SIGKILL (not SIGTERM) on Unix.

I was wondering if this is really desirable behaviour. There are
certainly programs out there that will leave stale lock files (or worse)
if forcibly terminated, that can shut down reasonably cleanly if asked
more nicely.

I have to say, it does make me a bit nervous.

That said, terminating programs cleanly is a tricky business. While
there is SIGTERM on Unix, there's no simple way to do it on Windows;
there's no softer equivalent of TerminateProcess().

But if we think it *is* the right behaviour then I think we ought to be
doing it consistently. There are other System.Process functions that run
processes synchronously that should have the same behaviour.

And it turns out that cleaning up is rather subtle. Takano recently sent
in a patch to fix a deadlock due to the order in which the cleanup
happens:

https://ghc.haskell.org/trac/ghc/changeset/32223a9ab174c22e939c81e24b6f48223c7cb020/process

So if it is desirable behaviour and is so subtle we ought to provide the
users with some help to do it (or indeed to do alternatives if we think
no one policy fits all).

For example, we could provide:

-- | A 'bracketOnError'-style resource handler for 'createProcess'.
--
-- In normal operation it adds nothing, you are still responsible for
-- waiting for (or forcing) process termination and closing any
-- 'Handle's. It only does automatic cleanup if there is an exception.
-- If there is an exception in the body then it ensures that the process
-- gets terminated and any 'CreatePipe' 'Handle's are closed. In
-- particular this means that if the Haskell thread is killed (e.g.
-- 'killThread'), that the external process is also terminated.
--
withCreateProcess
  :: CreateProcess
  -> (Maybe Handle -> Maybe Handle -> Maybe Handle
                   -> ProcessHandle -> IO a)
  -> IO a
withCreateProcess c action =
    bracketOnError
      (createProcess c) cleanupProcess
      (\(m_in, m_out, m_err, ph) -> action m_in m_out m_err ph)

cleanupProcess
  :: (Maybe Handle, Maybe Handle, Maybe Handle, ProcessHandle)
  -> IO ExitCode
cleanupProcess (mb_stdin, mb_stdout, mb_stderr, ph) = do
  -- We rely on the fact that terminateProcess really does terminate it
  -- and not just ask it nicely. Otherwise we could deadlock if there
  -- are other threads holding the lock on the stdin/out/err Handles.
  terminateProcess ph
  maybe (return ()) hClose mb_stdin
  maybe (return ()) hClose mb_stdout
  maybe (return ()) hClose mb_stderr
  waitForProcess ph

As it is, the docs say:

        'readProcess' and 'readProcessWithExitCode' are fairly simple
        wrappers around 'createProcess'.  Constructing variants of these
        functions is quite easy: follow the link to the source code to
        see how 'readProcess' is implemented.

but if you do look at the source you see that while it may originally
have been true, it certainly is not anymore! Providing and using a
withCreateProcess-style would help quite a bit.

Also, the ignoring EPIPE stuff is rather unsatisfactory and
non-portable. It's not used consistently and it's impossible for anyone
else to implement it themselves without using GHC internals. It's almost
possible in a nice way, since you could check if it's ResourceVanished
rather than errno = EPIPE, but actually ResourceVanished is not exposed
via System.IO.Error either.

I think it's worth if at all possible making it true that people can
write useful and reliable special cases of createProcess, but we'd need
to provide more help.



From simonpj at microsoft.com  Fri Nov 15 22:17:32 2013
From: simonpj at microsoft.com (Simon Peyton-Jones)
Date: Fri, 15 Nov 2013 22:17:32 +0000
Subject: bundle panic
Message-ID: <59543203684B2244980D7E4057D5FBC14869FFAE@DB3EX14MBXC306.europe.corp.microsoft.com>

Windows build is failing again in a new way.  It was fine a couple of days ago. Does this ring any bells?

ghc-stage1.exe: panic! (the 'impossible' happened)

  (GHC version 7.7.20131107 for i386-unknown-mingw32):

     bundle

Simon



"inplace/bin/ghc-stage1.exe" -static  -H32m -O -Werror -Wall -H64m -O0    -package-name integer-gmp-0.5.1.0 -hide-all-packages -i -ilibraries/integer-gmp/. -ilibraries/integer-gmp/dist-install/build -ilibraries/integer-gmp/dist-install/build/autogen -Ilibraries/integer-gmp/dist-install/build -Ilibraries/integer-gmp/dist-install/build/autogen -Ilibraries/integer-gmp/.    -optP-include -optPlibraries/integer-gmp/dist-install/build/autogen/cabal_macros.h -package ghc-prim-0.3.1.0 -Wall -package-name integer-gmp -XHaskell2010 -dcore-lint  -no-user-package-db -rtsopts -Ilibraries/integer-gmp/mkGmpDerivedConstants/dist     -c libraries/integer-gmp/cbits/gmp-wrappers.cmm -o libraries/integer-gmp/dist-install/build/cbits/gmp-wrappers.o

ghc-stage1.exe: panic! (the 'impossible' happened)

  (GHC version 7.7.20131107 for i386-unknown-mingw32):

     bundle

    c8 integer_cmm_importIntegerFromByteArrayzh [(c8,

                                                  label: block{v c8}_info

                                                  rep:StackRep [False, True, True, True]),

                                                 (cg,

                                                  label: block{v cg}_info

                                                  rep:StackRep [False, True, True, True])]



Please report this as a GHC bug:  http://www.haskell.org/ghc/reportabug



HEAD (master)$
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/ghc-devs/attachments/20131115/0215c2dc/attachment-0001.html>

From simonpj at microsoft.com  Fri Nov 15 22:28:10 2013
From: simonpj at microsoft.com (Simon Peyton-Jones)
Date: Fri, 15 Nov 2013 22:28:10 +0000
Subject: tcfail174, T2494 and Simple14 failing
In-Reply-To: <1384551163.4193.6.camel@kirk>
References: <1384551163.4193.6.camel@kirk>
Message-ID: <59543203684B2244980D7E4057D5FBC1486A0055@DB3EX14MBXC306.europe.corp.microsoft.com>

Not necessarily to do with Duncan's stuff.  Might conceivably be me, but I can't validate at the moment because of the "bundle" failure I reported.  Alas.

Simon

| -----Original Message-----
| From: ghc-devs [mailto:ghc-devs-bounces at haskell.org] On Behalf Of
| Joachim Breitner
| Sent: 15 November 2013 21:33
| To: ghc-devs at haskell.org
| Subject: tcfail174, T2494 and Simple14 failing
| 
| Hi,
| 
| thanks to Duncan for fixing topHandler03. Three new tests are however
| failing:
| 
| =====> T2494(normal) 805 of 3821 [0, 0, 0]
| Actual stderr output differs from expected:
| --- ./typecheck/should_compile/T2494.stderr	2013-11-15
| 19:07:53.298771915 +0000
| +++ ./typecheck/should_compile/T2494.comp.stderr	2013-11-15
| 19:41:46.626713597 +0000
| @@ -1,10 +1,10 @@
| 
|  T2494.hs:15:14:
| -    Couldn't match type ?a? with ?b?
| -      ?a? is a rigid type variable bound by
| -          the RULE "foo/foo" at T2494.hs:13:16
| +    Couldn't match type ?b? with ?a?
|        ?b? is a rigid type variable bound by
|            the RULE "foo/foo" at T2494.hs:14:16
| +      ?a? is a rigid type variable bound by
| +          the RULE "foo/foo" at T2494.hs:13:16
|      Expected type: Maybe (m a) -> Maybe (m a)
|        Actual type: Maybe (m b) -> Maybe (m b)
|      Relevant bindings include
| @@ -17,11 +17,11 @@
|      In the second argument of ?foo?, namely ?(foo g x)?
| 
|  T2494.hs:15:30:
| -    Couldn't match type ?a? with ?b?
| -      ?a? is a rigid type variable bound by
| -          the RULE "foo/foo" at T2494.hs:13:16
| +    Couldn't match type ?b? with ?a?
|        ?b? is a rigid type variable bound by
|            the RULE "foo/foo" at T2494.hs:14:16
| +      ?a? is a rigid type variable bound by
| +          the RULE "foo/foo" at T2494.hs:13:16
|      Expected type: Maybe (m a) -> Maybe (m a)
|        Actual type: Maybe (m b) -> Maybe (m b)
|      Relevant bindings include
| *** unexpected failure for T2494(normal)
| 
| 
| =====> tcfail174(normal) 1068 of 3821 [0, 1, 0]
| Actual stderr output differs from expected:
| --- ./typecheck/should_fail/tcfail174.stderr	2013-11-15
| 19:07:53.462762490 +0000
| +++ ./typecheck/should_fail/tcfail174.comp.stderr	2013-11-15
| 19:42:10.823320120 +0000
| @@ -6,11 +6,11 @@
|      In the expression: Base id
| 
|  tcfail174.hs:13:14:
| -    Couldn't match type ?a? with ?a1?
| -      because type variable ?a1? would escape its scope
| -    This (rigid, skolem) type variable is bound by
| -      the type forall a2. a2 -> a2
| -      at tcfail174.hs:13:14
| +    Couldn't match type ?a1? with ?a?
| +      ?a1? is a rigid type variable bound by
| +           the type forall a2. a2 -> a2 at tcfail174.hs:13:14
| +      ?a? is a rigid type variable bound by
| +          the inferred type of h1 :: Capture a at tcfail174.hs:13:1
|      Expected type: Capture (forall x. x -> a)
|        Actual type: Capture (forall a. a -> a)
|      Relevant bindings include
| *** unexpected failure for tcfail174(normal)
| 
| 
| =====> Simple14(normal) 3306 of 3821 [0, 2, 0]
| Actual stderr output differs from expected:
| --- ./indexed-types/should_compile/Simple14.stderr	2013-11-15
| 19:07:52.465819783 +0000
| +++ ./indexed-types/should_compile/Simple14.comp.stderr	2013-11-15
| 19:48:37.218070046 +0000
| @@ -1,8 +1,7 @@
| 
|  Simple14.hs:17:19:
| -    Couldn't match type ?z0? with ?n?
| -      ?z0? is untouchable
| -        inside the constraints (Maybe m ~ Maybe n)
| +    Could not deduce (n ~ z0)
| +    from the context (Maybe m ~ Maybe n)
|          bound by a type expected by the context:
|                     Maybe m ~ Maybe n => EQ_ z0 z0
|          at Simple14.hs:17:12-33
| *** unexpected failure for Simple14(normal)
| 
| 
| I guess these have been introduced by SPJ?s most recent changes
| (https://github.com/nomeata/ghc-
| complete/commit/a8030acfc591f4069c27c9df86a806ddb6a30003)
| 
| 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 simonpj at microsoft.com  Sat Nov 16 00:16:49 2013
From: simonpj at microsoft.com (Simon Peyton-Jones)
Date: Sat, 16 Nov 2013 00:16:49 +0000
Subject: bundle panic
Message-ID: <59543203684B2244980D7E4057D5FBC1486A0192@DB3EX14MBXC306.europe.corp.microsoft.com>

I've looked into this myself.  I don't think it's actually anything wrong in gmp-wrappers.  It's because CmmBuildInfoTables expects all the info tables in the (CmmProc info_tbls lbl g) to be defined in the graph g.

But Jan's new optimisation to the stack overflow check (Note [Always false stack check] in CmmLayoutStack) ends up dropping a conditional branch, so a call to gc is eliminated, and hence a proc point is eliminated, and we end up with an unused thing in info_tbls, which confuses CmmBuildInfoTables

Sigh. I don't know why this only happens on Windows.  I'm looking into a fix

Simon



From: Simon Peyton-Jones
Sent: 15 November 2013 22:18
To: ghc-devs at haskell.org
Subject: bundle panic

Windows build is failing again in a new way.  It was fine a couple of days ago. Does this ring any bells?

ghc-stage1.exe: panic! (the 'impossible' happened)

  (GHC version 7.7.20131107 for i386-unknown-mingw32):

     bundle

Simon



"inplace/bin/ghc-stage1.exe" -static  -H32m -O -Werror -Wall -H64m -O0    -package-name integer-gmp-0.5.1.0 -hide-all-packages -i -ilibraries/integer-gmp/. -ilibraries/integer-gmp/dist-install/build -ilibraries/integer-gmp/dist-install/build/autogen -Ilibraries/integer-gmp/dist-install/build -Ilibraries/integer-gmp/dist-install/build/autogen -Ilibraries/integer-gmp/.    -optP-include -optPlibraries/integer-gmp/dist-install/build/autogen/cabal_macros.h -package ghc-prim-0.3.1.0 -Wall -package-name integer-gmp -XHaskell2010 -dcore-lint  -no-user-package-db -rtsopts -Ilibraries/integer-gmp/mkGmpDerivedConstants/dist     -c libraries/integer-gmp/cbits/gmp-wrappers.cmm -o libraries/integer-gmp/dist-install/build/cbits/gmp-wrappers.o

ghc-stage1.exe: panic! (the 'impossible' happened)

  (GHC version 7.7.20131107 for i386-unknown-mingw32):

     bundle

    c8 integer_cmm_importIntegerFromByteArrayzh [(c8,

                                                  label: block{v c8}_info

                                                  rep:StackRep [False, True, True, True]),

                                                 (cg,

                                                  label: block{v cg}_info

                                                  rep:StackRep [False, True, True, True])]



Please report this as a GHC bug:  http://www.haskell.org/ghc/reportabug



HEAD (master)$
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/ghc-devs/attachments/20131116/f17670ef/attachment.html>

From austin at well-typed.com  Sat Nov 16 00:24:12 2013
From: austin at well-typed.com (Austin Seipp)
Date: Fri, 15 Nov 2013 18:24:12 -0600
Subject: GHC 7.8 release status
In-Reply-To: <CADfHYo5v2PKmTnf9cU8=AWo4-cC-TyPCmj4BupLnyZj7Yff7_A@mail.gmail.com>
References: <59543203684B2244980D7E4057D5FBC1485BD020@DB3EX14MBXC308.europe.corp.microsoft.com>
 <CACYs5AbC+SPCpa4qyVBbC-AztMiJ=OzLNmFne4pjnA_iRM58Pw@mail.gmail.com>
 <CAEs96n0HzaS_we9Xzxr=35P5H_eEda_SoV9RQrN0rUQzGTWqtQ@mail.gmail.com>
 <CACYs5AZgQooitEm3Mtm2NnYpD9JYLMC0ZfgCtubYbrn1qnnLeA@mail.gmail.com>
 <CADdwyZmyG9Tedtxch_MNcRm6wkc4Oj=JJtY27=50XAWHhNRL-A@mail.gmail.com>
 <CADdwyZmuvyafpizqsaZ+1zM03y5RZPh7P7YPzkRt7fuDBR6TSg@mail.gmail.com>
 <CADdwyZ=e2ir3_YSi8mVSBvvr_tXJQpBw0QmBs8+0UugcrtKugw@mail.gmail.com>
 <CADfHYo5v2PKmTnf9cU8=AWo4-cC-TyPCmj4BupLnyZj7Yff7_A@mail.gmail.com>
Message-ID: <CAEs96n1TAN8Mp-9MngxfQ5ZabUg4-RDvc6BD-30ru2Q0kAje+g@mail.gmail.com>

Hi Nicolas,

I apologize if you didn't get the notice I sent last week on the update.

Right now I am endlessly battling windows, and while I actually DO
have a dynamic GHC working for windows with the DLL split (#5987,) it
is segfaulting in the stage2 compiler when compiling the 'time'
library, and I am still looking into it for the past day or so. This
is really my biggest hold up in pushing some needed fixes (I'll post
some details out here on the list soon, so others can help.)

I'm working this weekend to try and get a lot of it sorted out and
post an update, but I will unfortunately be gone part of Saturday.

On Thu, Nov 14, 2013 at 11:45 PM, Nicolas Frisby
<nicolas.frisby at gmail.com> wrote:
> Unless I missed an RC announcement, I'm pretty sure we're running a little
> behind the schedule from that email.
>
> Deciders, has the Nov 25 target slid back? Any new estimates, if so?
>
> Thanks much.
>
> On Nov 14, 2013 9:40 PM, "Andreas Voellmy" <andreas.voellmy at gmail.com>
> wrote:
>>
>>
>>
>>
>> On Thu, Nov 14, 2013 at 10:38 PM, Andreas Voellmy
>> <andreas.voellmy at gmail.com> wrote:
>>>
>>> I added a note about the parallel IO manager status to
>>> https://ghc.haskell.org/trac/ghc/wiki/Status/GHC-7.8. There are two issues
>>> I'd still like to resolve.  Is there a target date for the release?
>>
>>
>> Oh, I just noticed
>> http://permalink.gmane.org/gmane.comp.lang.haskell.ghc.devel/2569 which
>> answers my question (target is Nov. 25).
>>
>>>
>>>
>>> -Andi
>>>
>>>
>>> On Fri, Nov 8, 2013 at 12:02 AM, Andreas Voellmy
>>> <andreas.voellmy at gmail.com> wrote:
>>>>
>>>> Yes, the parallel IO manager is new in 7.8. Thanks for reminding me of
>>>> that excessive system time issue. That's been nagging me for a while.
>>>> Hopefully I can find some time in the coming days to look at this again.
>>>>
>>>> -Andi
>>>>
>>>>
>>>> On Wed, Sep 4, 2013 at 11:42 AM, Ryan Newton <rrnewton at gmail.com> wrote:
>>>>>
>>>>> By the way, the parallel IO manager is also new in 7.8 right?  I'm not
>>>>> sure but I think it may have something to do with the excessive system time
>>>>> bug I just filed:
>>>>>
>>>>>     http://ghc.haskell.org/trac/ghc/ticket/8224
>>>>>
>>>>>
>>>>>
>>>>> _______________________________________________
>>>>> 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 carter.schonwald at gmail.com  Sat Nov 16 01:11:56 2013
From: carter.schonwald at gmail.com (Carter Schonwald)
Date: Fri, 15 Nov 2013 20:11:56 -0500
Subject: GHC 7.8 release status
In-Reply-To: <CAEs96n1TAN8Mp-9MngxfQ5ZabUg4-RDvc6BD-30ru2Q0kAje+g@mail.gmail.com>
References: <59543203684B2244980D7E4057D5FBC1485BD020@DB3EX14MBXC308.europe.corp.microsoft.com>
 <CACYs5AbC+SPCpa4qyVBbC-AztMiJ=OzLNmFne4pjnA_iRM58Pw@mail.gmail.com>
 <CAEs96n0HzaS_we9Xzxr=35P5H_eEda_SoV9RQrN0rUQzGTWqtQ@mail.gmail.com>
 <CACYs5AZgQooitEm3Mtm2NnYpD9JYLMC0ZfgCtubYbrn1qnnLeA@mail.gmail.com>
 <CADdwyZmyG9Tedtxch_MNcRm6wkc4Oj=JJtY27=50XAWHhNRL-A@mail.gmail.com>
 <CADdwyZmuvyafpizqsaZ+1zM03y5RZPh7P7YPzkRt7fuDBR6TSg@mail.gmail.com>
 <CADdwyZ=e2ir3_YSi8mVSBvvr_tXJQpBw0QmBs8+0UugcrtKugw@mail.gmail.com>
 <CADfHYo5v2PKmTnf9cU8=AWo4-cC-TyPCmj4BupLnyZj7Yff7_A@mail.gmail.com>
 <CAEs96n1TAN8Mp-9MngxfQ5ZabUg4-RDvc6BD-30ru2Q0kAje+g@mail.gmail.com>
Message-ID: <CAHYVw0xCPFdAv2QF2hER6S0FVFb=X00MdpD4a4a635KKT_Jgow@mail.gmail.com>

What are ways for other folks to help? (If possible)

On Friday, November 15, 2013, Austin Seipp wrote:

> Hi Nicolas,
>
> I apologize if you didn't get the notice I sent last week on the update.
>
> Right now I am endlessly battling windows, and while I actually DO
> have a dynamic GHC working for windows with the DLL split (#5987,) it
> is segfaulting in the stage2 compiler when compiling the 'time'
> library, and I am still looking into it for the past day or so. This
> is really my biggest hold up in pushing some needed fixes (I'll post
> some details out here on the list soon, so others can help.)
>
> I'm working this weekend to try and get a lot of it sorted out and
> post an update, but I will unfortunately be gone part of Saturday.
>
> On Thu, Nov 14, 2013 at 11:45 PM, Nicolas Frisby
> <nicolas.frisby at gmail.com <javascript:;>> wrote:
> > Unless I missed an RC announcement, I'm pretty sure we're running a
> little
> > behind the schedule from that email.
> >
> > Deciders, has the Nov 25 target slid back? Any new estimates, if so?
> >
> > Thanks much.
> >
> > On Nov 14, 2013 9:40 PM, "Andreas Voellmy" <andreas.voellmy at gmail.com<javascript:;>
> >
> > wrote:
> >>
> >>
> >>
> >>
> >> On Thu, Nov 14, 2013 at 10:38 PM, Andreas Voellmy
> >> <andreas.voellmy at gmail.com <javascript:;>> wrote:
> >>>
> >>> I added a note about the parallel IO manager status to
> >>> https://ghc.haskell.org/trac/ghc/wiki/Status/GHC-7.8. There are two
> issues
> >>> I'd still like to resolve.  Is there a target date for the release?
> >>
> >>
> >> Oh, I just noticed
> >> http://permalink.gmane.org/gmane.comp.lang.haskell.ghc.devel/2569 which
> >> answers my question (target is Nov. 25).
> >>
> >>>
> >>>
> >>> -Andi
> >>>
> >>>
> >>> On Fri, Nov 8, 2013 at 12:02 AM, Andreas Voellmy
> >>> <andreas.voellmy at gmail.com <javascript:;>> wrote:
> >>>>
> >>>> Yes, the parallel IO manager is new in 7.8. Thanks for reminding me of
> >>>> that excessive system time issue. That's been nagging me for a while.
> >>>> Hopefully I can find some time in the coming days to look at this
> again.
> >>>>
> >>>> -Andi
> >>>>
> >>>>
> >>>> On Wed, Sep 4, 2013 at 11:42 AM, Ryan Newton <rrnewton at gmail.com<javascript:;>>
> wrote:
> >>>>>
> >>>>> By the way, the parallel IO manager is also new in 7.8 right?  I'm
> not
> >>>>> sure but I think it may have something to do with the excessive
> system time
> >>>>> bug I just filed:
> >>>>>
> >>>>>     http://ghc.haskell.org/trac/ghc/ticket/8224
> >>>>>
> >>>>>
> >>>>>
> >>>>> _______________________________________________
> >>>>> ghc-devs mailing list
> >>>>> ghc-devs at haskell.org <javascript:;>
> >>>>> http://www.haskell.org/mailman/listinfo/ghc-devs
> >>>>>
> >>>>
> >>>
> >>
> >>
> >> _______________________________________________
> >> ghc-devs mailing list
> >> ghc-devs at haskell.org <javascript:;>
> >> 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 <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/20131115/c305c518/attachment-0001.html>

From nicolas.frisby at gmail.com  Sat Nov 16 01:51:06 2013
From: nicolas.frisby at gmail.com (Nicolas Frisby)
Date: Fri, 15 Nov 2013 19:51:06 -0600
Subject: GHC 7.8 release status
In-Reply-To: <CAEs96n1TAN8Mp-9MngxfQ5ZabUg4-RDvc6BD-30ru2Q0kAje+g@mail.gmail.com>
References: <59543203684B2244980D7E4057D5FBC1485BD020@DB3EX14MBXC308.europe.corp.microsoft.com>
 <CACYs5AbC+SPCpa4qyVBbC-AztMiJ=OzLNmFne4pjnA_iRM58Pw@mail.gmail.com>
 <CAEs96n0HzaS_we9Xzxr=35P5H_eEda_SoV9RQrN0rUQzGTWqtQ@mail.gmail.com>
 <CACYs5AZgQooitEm3Mtm2NnYpD9JYLMC0ZfgCtubYbrn1qnnLeA@mail.gmail.com>
 <CADdwyZmyG9Tedtxch_MNcRm6wkc4Oj=JJtY27=50XAWHhNRL-A@mail.gmail.com>
 <CADdwyZmuvyafpizqsaZ+1zM03y5RZPh7P7YPzkRt7fuDBR6TSg@mail.gmail.com>
 <CADdwyZ=e2ir3_YSi8mVSBvvr_tXJQpBw0QmBs8+0UugcrtKugw@mail.gmail.com>
 <CADfHYo5v2PKmTnf9cU8=AWo4-cC-TyPCmj4BupLnyZj7Yff7_A@mail.gmail.com>
 <CAEs96n1TAN8Mp-9MngxfQ5ZabUg4-RDvc6BD-30ru2Q0kAje+g@mail.gmail.com>
Message-ID: <CADfHYo6cqy3JSNidfmFG6TGVX=-=gGNU389aVyYdmei_8QF28w@mail.gmail.com>

I did get it. And I certainly appreciate that there's a lot of work
happening. I just didn't see any answers to my date-related questions in it.

Thanks.


On Fri, Nov 15, 2013 at 6:24 PM, Austin Seipp <austin at well-typed.com> wrote:

> Hi Nicolas,
>
> I apologize if you didn't get the notice I sent last week on the update.
>
> Right now I am endlessly battling windows, and while I actually DO
> have a dynamic GHC working for windows with the DLL split (#5987,) it
> is segfaulting in the stage2 compiler when compiling the 'time'
> library, and I am still looking into it for the past day or so. This
> is really my biggest hold up in pushing some needed fixes (I'll post
> some details out here on the list soon, so others can help.)
>
> I'm working this weekend to try and get a lot of it sorted out and
> post an update, but I will unfortunately be gone part of Saturday.
>
> On Thu, Nov 14, 2013 at 11:45 PM, Nicolas Frisby
> <nicolas.frisby at gmail.com> wrote:
> > Unless I missed an RC announcement, I'm pretty sure we're running a
> little
> > behind the schedule from that email.
> >
> > Deciders, has the Nov 25 target slid back? Any new estimates, if so?
> >
> > Thanks much.
> >
> > On Nov 14, 2013 9:40 PM, "Andreas Voellmy" <andreas.voellmy at gmail.com>
> > wrote:
> >>
> >>
> >>
> >>
> >> On Thu, Nov 14, 2013 at 10:38 PM, Andreas Voellmy
> >> <andreas.voellmy at gmail.com> wrote:
> >>>
> >>> I added a note about the parallel IO manager status to
> >>> https://ghc.haskell.org/trac/ghc/wiki/Status/GHC-7.8. There are two
> issues
> >>> I'd still like to resolve.  Is there a target date for the release?
> >>
> >>
> >> Oh, I just noticed
> >> http://permalink.gmane.org/gmane.comp.lang.haskell.ghc.devel/2569 which
> >> answers my question (target is Nov. 25).
> >>
> >>>
> >>>
> >>> -Andi
> >>>
> >>>
> >>> On Fri, Nov 8, 2013 at 12:02 AM, Andreas Voellmy
> >>> <andreas.voellmy at gmail.com> wrote:
> >>>>
> >>>> Yes, the parallel IO manager is new in 7.8. Thanks for reminding me of
> >>>> that excessive system time issue. That's been nagging me for a while.
> >>>> Hopefully I can find some time in the coming days to look at this
> again.
> >>>>
> >>>> -Andi
> >>>>
> >>>>
> >>>> On Wed, Sep 4, 2013 at 11:42 AM, Ryan Newton <rrnewton at gmail.com>
> wrote:
> >>>>>
> >>>>> By the way, the parallel IO manager is also new in 7.8 right?  I'm
> not
> >>>>> sure but I think it may have something to do with the excessive
> system time
> >>>>> bug I just filed:
> >>>>>
> >>>>>     http://ghc.haskell.org/trac/ghc/ticket/8224
> >>>>>
> >>>>>
> >>>>>
> >>>>> _______________________________________________
> >>>>> 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/20131115/1bef5c0f/attachment.html>

From marlowsd at gmail.com  Sun Nov 17 09:57:00 2013
From: marlowsd at gmail.com (Simon Marlow)
Date: Sun, 17 Nov 2013 09:57:00 +0000
Subject: bundle panic
In-Reply-To: <59543203684B2244980D7E4057D5FBC1486A0192@DB3EX14MBXC306.europe.corp.microsoft.com>
References: <59543203684B2244980D7E4057D5FBC1486A0192@DB3EX14MBXC306.europe.corp.microsoft.com>
Message-ID: <528892EC.60707@gmail.com>

On 16/11/13 00:16, Simon Peyton-Jones wrote:
> I?ve looked into this myself.  I don?t think it?s actually anything
> wrong in gmp-wrappers.  It?s because CmmBuildInfoTables expects all the
> info tables in the (CmmProc info_tbls lbl g) to be defined in the graph g.
>
> But Jan?s new optimisation to the stack overflow check (Note [Always
> false stack check] in CmmLayoutStack) ends up dropping a conditional
> branch, so a call to gc is eliminated, and hence a proc point is
> eliminated, and we end up with an unused thing in info_tbls, which
> confuses CmmBuildInfoTables

> Sigh. I don?t know why this only happens on Windows.  I?m looking into a fix

Perhaps this is a problem that only shows up with proc points, which is 
why you wouldn't see it on x86_64/Linux.  Let me know if you get stuck 
and I'll try to look into it.

FYI eliminating always-false stack checks is not new, it was temporarily 
broken by:

commit 94125c97e49987e91fa54da6c86bc6d17417f5cf
Author: Jan Stolarek <jan.stolarek at p.lodz.pl>
Date:   Wed Oct 16 09:45:56 2013 +0200

     Generate (old + 0) instead of Sp in stack checks

and then fixed up by:

commit 1cf0c8ad321d1d358cbec46d35be02566faf2d00
Author: Jan Stolarek <jan.stolarek at p.lodz.pl>
Date:   Thu Oct 17 23:17:06 2013 +0200

     Optimise stack checks that are always false

Cheers,
Simon


>
>
> Simon
>
> *From:*Simon Peyton-Jones
> *Sent:* 15 November 2013 22:18
> *To:* ghc-devs at haskell.org
> *Subject:* bundle panic
>
> Windows build is failing again in a new way.  It was fine a couple of
> days ago. Does this ring any bells?
>
> ghc-stage1.exe: panic! (the 'impossible' happened)
>
>    (GHC version 7.7.20131107 for i386-unknown-mingw32):
>
>       bundle
>
> Simon
>
> "inplace/bin/ghc-stage1.exe" -static  -H32m -O -Werror -Wall -H64m
> -O0    -package-name integer-gmp-0.5.1.0 -hide-all-packages -i
> -ilibraries/integer-gmp/. -ilibraries/integer-gmp/dist-install/build
> -ilibraries/integer-gmp/dist-install/build/autogen
> -Ilibraries/integer-gmp/dist-install/build
> -Ilibraries/integer-gmp/dist-install/build/autogen
> -Ilibraries/integer-gmp/.    -optP-include
> -optPlibraries/integer-gmp/dist-install/build/autogen/cabal_macros.h
> -package ghc-prim-0.3.1.0 -Wall -package-name integer-gmp -XHaskell2010
> -dcore-lint  -no-user-package-db -rtsopts
> -Ilibraries/integer-gmp/mkGmpDerivedConstants/dist     -c
> libraries/integer-gmp/cbits/gmp-wrappers.cmm -o
> libraries/integer-gmp/dist-install/build/cbits/gmp-wrappers.o
>
> ghc-stage1.exe: panic! (the 'impossible' happened)
>
>    (GHC version 7.7.20131107 for i386-unknown-mingw32):
>
>       bundle
>
>      c8 integer_cmm_importIntegerFromByteArrayzh [(c8,
>
>                                                    label: block{v c8}_info
>
>                                                    rep:StackRep [False,
> True, True, True]),
>
>                                                   (cg,
>
>                                                    label: block{v cg}_info
>
>                                                    rep:StackRep [False,
> True, True, True])]
>
> Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug
>
> HEAD (master)$
>
>
>
> _______________________________________________
> ghc-devs mailing list
> ghc-devs at haskell.org
> http://www.haskell.org/mailman/listinfo/ghc-devs
>


From kazu at iij.ad.jp  Mon Nov 18 06:13:04 2013
From: kazu at iij.ad.jp (Kazu Yamamoto (=?iso-2022-jp?B?GyRCOzNLXE9CSScbKEI=?=))
Date: Mon, 18 Nov 2013 15:13:04 +0900 (JST)
Subject: Building GHC head with clang on Mavericks
Message-ID: <20131118.151304.1483841058307923622.kazu@iij.ad.jp>

Hi,

As I wrote in the following blog article, I could build GHC head on
Mavericks 20 days ago.

	http://d.hatena.ne.jp/kazu-yamamoto/20131028/1382921924

But I cannot build it recently:

----
"/usr/bin/ghc" -hisuf hi -osuf  o -hcsuf hc -static  -H32m -O  -package-db libraries/bootstrapping.conf   -i -iutils/genprimopcode/. -iutils/genprimopcode/dist/build -iutils/genprimopcode/dist/build/autogen -Iutils/genprimopcode/dist/build -Iutils/genprimopcode/dist/build/autogen       -package array  -no-user-package-db -rtsopts      -odir utils/genprimopcode/dist/build -hidir utils/genprimopcode/dist/build -stubdir utils/genprimopcode/dist/build   -c utils/genprimopcode/dist/build/Lexer.hs -o utils/genprimopcode/dist/build/Lexer.o 

<built-in>:2:2: Not in scope: `#'
make[1]: *** [utils/genprimopcode/dist/build/Lexer.o] Error 1
make[1]: *** Waiting for unfinished jobs....
shift/reduce conflicts:  46
reduce/reduce conflicts: 1
make: *** [all] Error 2
----

I seems to me that linemarkers generated by GCC(CPP) is not correctly
handled when alex is used. Note I can build GHC head on FreeBSD and
Linux.

I'm using clang with clang-xcode5-wrapper.hs.

Any suggestions?

--Kazu

From carter.schonwald at gmail.com  Mon Nov 18 06:29:39 2013
From: carter.schonwald at gmail.com (Carter Schonwald)
Date: Mon, 18 Nov 2013 01:29:39 -0500
Subject: Building GHC head with clang on Mavericks
In-Reply-To: <20131118.151304.1483841058307923622.kazu@iij.ad.jp>
References: <20131118.151304.1483841058307923622.kazu@iij.ad.jp>
Message-ID: <CAHYVw0yow6pLTwuQ8sdQ3c05tdSHKT-bw13yrX_DXokTqahrhA@mail.gmail.com>

Hey Kazu,
Nick Partridge hit this recently and he's got PR's pending for Happy and
Alex https://github.com/simonmar/alex/pull/37 and
https://github.com/simonmar/happy/pull/12


On Mon, Nov 18, 2013 at 1:13 AM, Kazu Yamamoto <kazu at iij.ad.jp> wrote:

> Hi,
>
> As I wrote in the following blog article, I could build GHC head on
> Mavericks 20 days ago.
>
>         http://d.hatena.ne.jp/kazu-yamamoto/20131028/1382921924
>
> But I cannot build it recently:
>
> ----
> "/usr/bin/ghc" -hisuf hi -osuf  o -hcsuf hc -static  -H32m -O  -package-db
> libraries/bootstrapping.conf   -i -iutils/genprimopcode/.
> -iutils/genprimopcode/dist/build -iutils/genprimopcode/dist/build/autogen
> -Iutils/genprimopcode/dist/build -Iutils/genprimopcode/dist/build/autogen
>     -package array  -no-user-package-db -rtsopts      -odir
> utils/genprimopcode/dist/build -hidir utils/genprimopcode/dist/build
> -stubdir utils/genprimopcode/dist/build   -c
> utils/genprimopcode/dist/build/Lexer.hs -o
> utils/genprimopcode/dist/build/Lexer.o
>
> <built-in>:2:2: Not in scope: `#'
> make[1]: *** [utils/genprimopcode/dist/build/Lexer.o] Error 1
> make[1]: *** Waiting for unfinished jobs....
> shift/reduce conflicts:  46
> reduce/reduce conflicts: 1
> make: *** [all] Error 2
> ----
>
> I seems to me that linemarkers generated by GCC(CPP) is not correctly
> handled when alex is used. Note I can build GHC head on FreeBSD and
> Linux.
>
> I'm using clang with clang-xcode5-wrapper.hs.
>
> Any suggestions?
>
> --Kazu
> _______________________________________________
> 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/20131118/17e72049/attachment.html>

From simonpj at microsoft.com  Mon Nov 18 10:36:52 2013
From: simonpj at microsoft.com (Simon Peyton-Jones)
Date: Mon, 18 Nov 2013 10:36:52 +0000
Subject: tcfail174, T2494 and Simple14 failing
In-Reply-To: <1384551163.4193.6.camel@kirk>
References: <1384551163.4193.6.camel@kirk>
Message-ID: <59543203684B2244980D7E4057D5FBC1486A35DA@DB3EX14MBXC306.europe.corp.microsoft.com>

Just to confirm, I'm about to push a fix to this.  Mea cupla

Simon

| -----Original Message-----
| From: ghc-devs [mailto:ghc-devs-bounces at haskell.org] On Behalf Of
| Joachim Breitner
| Sent: 15 November 2013 21:33
| To: ghc-devs at haskell.org
| Subject: tcfail174, T2494 and Simple14 failing
| 
| Hi,
| 
| thanks to Duncan for fixing topHandler03. Three new tests are however
| failing:
| 
| =====> T2494(normal) 805 of 3821 [0, 0, 0]
| Actual stderr output differs from expected:
| --- ./typecheck/should_compile/T2494.stderr	2013-11-15
| 19:07:53.298771915 +0000
| +++ ./typecheck/should_compile/T2494.comp.stderr	2013-11-15
| 19:41:46.626713597 +0000
| @@ -1,10 +1,10 @@
| 
|  T2494.hs:15:14:
| -    Couldn't match type ?a? with ?b?
| -      ?a? is a rigid type variable bound by
| -          the RULE "foo/foo" at T2494.hs:13:16
| +    Couldn't match type ?b? with ?a?
|        ?b? is a rigid type variable bound by
|            the RULE "foo/foo" at T2494.hs:14:16
| +      ?a? is a rigid type variable bound by
| +          the RULE "foo/foo" at T2494.hs:13:16
|      Expected type: Maybe (m a) -> Maybe (m a)
|        Actual type: Maybe (m b) -> Maybe (m b)
|      Relevant bindings include
| @@ -17,11 +17,11 @@
|      In the second argument of ?foo?, namely ?(foo g x)?
| 
|  T2494.hs:15:30:
| -    Couldn't match type ?a? with ?b?
| -      ?a? is a rigid type variable bound by
| -          the RULE "foo/foo" at T2494.hs:13:16
| +    Couldn't match type ?b? with ?a?
|        ?b? is a rigid type variable bound by
|            the RULE "foo/foo" at T2494.hs:14:16
| +      ?a? is a rigid type variable bound by
| +          the RULE "foo/foo" at T2494.hs:13:16
|      Expected type: Maybe (m a) -> Maybe (m a)
|        Actual type: Maybe (m b) -> Maybe (m b)
|      Relevant bindings include
| *** unexpected failure for T2494(normal)
| 
| 
| =====> tcfail174(normal) 1068 of 3821 [0, 1, 0]
| Actual stderr output differs from expected:
| --- ./typecheck/should_fail/tcfail174.stderr	2013-11-15
| 19:07:53.462762490 +0000
| +++ ./typecheck/should_fail/tcfail174.comp.stderr	2013-11-15
| 19:42:10.823320120 +0000
| @@ -6,11 +6,11 @@
|      In the expression: Base id
| 
|  tcfail174.hs:13:14:
| -    Couldn't match type ?a? with ?a1?
| -      because type variable ?a1? would escape its scope
| -    This (rigid, skolem) type variable is bound by
| -      the type forall a2. a2 -> a2
| -      at tcfail174.hs:13:14
| +    Couldn't match type ?a1? with ?a?
| +      ?a1? is a rigid type variable bound by
| +           the type forall a2. a2 -> a2 at tcfail174.hs:13:14
| +      ?a? is a rigid type variable bound by
| +          the inferred type of h1 :: Capture a at tcfail174.hs:13:1
|      Expected type: Capture (forall x. x -> a)
|        Actual type: Capture (forall a. a -> a)
|      Relevant bindings include
| *** unexpected failure for tcfail174(normal)
| 
| 
| =====> Simple14(normal) 3306 of 3821 [0, 2, 0]
| Actual stderr output differs from expected:
| --- ./indexed-types/should_compile/Simple14.stderr	2013-11-15
| 19:07:52.465819783 +0000
| +++ ./indexed-types/should_compile/Simple14.comp.stderr	2013-11-15
| 19:48:37.218070046 +0000
| @@ -1,8 +1,7 @@
| 
|  Simple14.hs:17:19:
| -    Couldn't match type ?z0? with ?n?
| -      ?z0? is untouchable
| -        inside the constraints (Maybe m ~ Maybe n)
| +    Could not deduce (n ~ z0)
| +    from the context (Maybe m ~ Maybe n)
|          bound by a type expected by the context:
|                     Maybe m ~ Maybe n => EQ_ z0 z0
|          at Simple14.hs:17:12-33
| *** unexpected failure for Simple14(normal)
| 
| 
| I guess these have been introduced by SPJ?s most recent changes
| (https://github.com/nomeata/ghc-
| complete/commit/a8030acfc591f4069c27c9df86a806ddb6a30003)
| 
| 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 kazu at iij.ad.jp  Mon Nov 18 12:19:56 2013
From: kazu at iij.ad.jp (Kazu Yamamoto (=?iso-2022-jp?B?GyRCOzNLXE9CSScbKEI=?=))
Date: Mon, 18 Nov 2013 21:19:56 +0900 (JST)
Subject: Building GHC head with clang on Mavericks
In-Reply-To: <CAHYVw0yow6pLTwuQ8sdQ3c05tdSHKT-bw13yrX_DXokTqahrhA@mail.gmail.com>
References: <20131118.151304.1483841058307923622.kazu@iij.ad.jp>
 <CAHYVw0yow6pLTwuQ8sdQ3c05tdSHKT-bw13yrX_DXokTqahrhA@mail.gmail.com>
Message-ID: <20131118.211956.1449605752503311315.kazu@iij.ad.jp>

Hi Carter,

> Nick Partridge hit this recently and he's got PR's pending for Happy and
> Alex https://github.com/simonmar/alex/pull/37 and
> https://github.com/simonmar/happy/pull/12

I'm not using GCC. (In my previous message, I made a typo. "GCC"
should be read as "clang"). So, I think that this is a different
problem.

--Kazu

From kazu at iij.ad.jp  Mon Nov 18 12:24:06 2013
From: kazu at iij.ad.jp (Kazu Yamamoto (=?iso-2022-jp?B?GyRCOzNLXE9CSScbKEI=?=))
Date: Mon, 18 Nov 2013 21:24:06 +0900 (JST)
Subject: Building GHC head with clang on Mavericks
In-Reply-To: <20131118.151304.1483841058307923622.kazu@iij.ad.jp>
References: <20131118.151304.1483841058307923622.kazu@iij.ad.jp>
Message-ID: <20131118.212406.751890840897632790.kazu@iij.ad.jp>

Hi,

Adding the "-v" option, GHC displays:

----
*** Checking old interface for main:Lexer:
*** Parser:
*** Renamer/typechecker:

<built-in>:2:2: Not in scope: `#'
----

"-keep-tmp-files" keeps generated .hscpp file. The beginning of the
generated .hscpp is:

----
# 1 "utils/genprimopcode/dist/build/Lexer.hs"
# 1 "<built-in>" 1
# 1 "utils/genprimopcode/dist/build/Lexer.hs" 2
{-# LANGUAGE CPP,MagicHash #-}
{-# LINE 2 "utils/genprimopcode/./Lexer.x" #-}
----

"<built-in>:2:2: Not in scope: `#'" in my previous message indicates
this line 2.

I don't know why Renamer/typechecker cannot handle this .hsccp file.

--Kazu

> Hi,
> 
> As I wrote in the following blog article, I could build GHC head on
> Mavericks 20 days ago.
> 
> 	http://d.hatena.ne.jp/kazu-yamamoto/20131028/1382921924
> 
> But I cannot build it recently:
> 
> ----
> "/usr/bin/ghc" -hisuf hi -osuf  o -hcsuf hc -static  -H32m -O  -package-db libraries/bootstrapping.conf   -i -iutils/genprimopcode/. -iutils/genprimopcode/dist/build -iutils/genprimopcode/dist/build/autogen -Iutils/genprimopcode/dist/build -Iutils/genprimopcode/dist/build/autogen       -package array  -no-user-package-db -rtsopts      -odir utils/genprimopcode/dist/build -hidir utils/genprimopcode/dist/build -stubdir utils/genprimopcode/dist/build   -c utils/genprimopcode/dist/build/Lexer.hs -o utils/genprimopcode/dist/build/Lexer.o 
> 
> <built-in>:2:2: Not in scope: `#'
> make[1]: *** [utils/genprimopcode/dist/build/Lexer.o] Error 1
> make[1]: *** Waiting for unfinished jobs....
> shift/reduce conflicts:  46
> reduce/reduce conflicts: 1
> make: *** [all] Error 2
> ----
> 
> I seems to me that linemarkers generated by GCC(CPP) is not correctly
> handled when alex is used. Note I can build GHC head on FreeBSD and
> Linux.
> 
> I'm using clang with clang-xcode5-wrapper.hs.
> 
> Any suggestions?
> 
> --Kazu

From maxwellswadling at gmail.com  Mon Nov 18 21:46:54 2013
From: maxwellswadling at gmail.com (Maxwell Swadling)
Date: Tue, 19 Nov 2013 08:46:54 +1100
Subject: Validate broken on Snow Leopard and Mountain Lion
In-Reply-To: <59543203684B2244980D7E4057D5FBC14867BBF6@DB3EX14MBXC308.europe.corp.microsoft.com>
References: <21E81090-2380-4DF9-96F7-86773FCEC65C@ouroborus.net>
 <7ECCA023-9D11-4423-BEA5-3ADA6D1D8588@gmail.com>
 <F59FB7DC-0CED-4F6B-AD8E-A343E66DEA3B@ouroborus.net>
 <CAHYVw0yCxAagJxCB3Mw=OH=DadneW-Rc5Okqk2N_DxL_x2qBrg@mail.gmail.com>
 <59543203684B2244980D7E4057D5FBC14867BBF6@DB3EX14MBXC308.europe.corp.microsoft.com>
Message-ID: <60E0CE93-29E4-4815-9D72-3B8009E85379@gmail.com>

Good idea!

I've setup nightly builds from my Mountain Lion machine.

You can see the result and log files at http://maxsbot.net

If anyone else has machines they can add, email me.
Hopefully we can find one for Snow Leopard and one for Mavericks.

On 14/11/2013, at 8:03 PM, Simon Peyton-Jones <simonpj at microsoft.com> wrote:

> This does raise a point I hope we'll address more aggressively after the 7.8 release, namely trying to keep ghc less broken by default! GHC being really really really broken between releases is probably the single HUGEST barrier to more people getting involved in helping GHC dev. And I think thats a huge problem we need to take more seriously.
> 
>  
> I totally agree with this.  What it needs is a Mac SWAT team who build GHC on Macs nightly, warn about problems and help fix them.
>  
> One recent total Mac breakage was due to the compulsory move to clang instead of gcc.   I gather that has caused a lot of pain.  I?ve seen a lot about Xcode too, whatever that is.
>  
> Anyway, Mac folk, we need you!
>  
> Simon
>  
> From: ghc-devs [mailto:ghc-devs-bounces at haskell.org] On Behalf Of Carter Schonwald
> Sent: 14 November 2013 04:24
> To: Ben Lippmeier
> Cc: ghc-devs at haskell.org
> Subject: Re: Validate broken on Snow Leopard and Mountain Lion
>  
> Ben has an excellent point: 
> 
> if things are broken on mac, lets fix it!  Especially since we should be hitting RC status shortly.... any breakages should be smashed ASAP.
> 
> This does raise a point I hope we'll address more aggressively after the 7.8 release, namely trying to keep ghc less broken by default! GHC being really really really broken between releases is probably the single HUGEST barrier to more people getting involved in helping GHC dev. And I think thats a huge problem we need to take more seriously.
> 
>  
> 
>  
> 
> On Wed, Nov 13, 2013 at 11:09 PM, Ben Lippmeier <benl at ouroborus.net> wrote:
> 
> 
> On 13/11/2013, at 8:02 PM, Christiaan Baaij wrote:
> 
> > Does validate work for the DPH packages on Linux?
> 
> "sh validate" runs fine on my Linux machine, but neither of my Macs.
> 
> I can also run the dph tests manually on Linux, and they work fine.
> 
> 
> Ben.
> 
> _______________________________________________
> 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/20131119/593d7578/attachment.html>

From ezyang at MIT.EDU  Tue Nov 19 00:17:38 2013
From: ezyang at MIT.EDU (Edward Z. Yang)
Date: Mon, 18 Nov 2013 16:17:38 -0800
Subject: Validate broken on Snow Leopard and Mountain Lion
In-Reply-To: <5D787D9D-E8D6-4C9E-8102-D9954DA43763@gmail.com>
References: <21E81090-2380-4DF9-96F7-86773FCEC65C@ouroborus.net>
 <7ECCA023-9D11-4423-BEA5-3ADA6D1D8588@gmail.com>
 <F59FB7DC-0CED-4F6B-AD8E-A343E66DEA3B@ouroborus.net>
 <CAHYVw0yCxAagJxCB3Mw=OH=DadneW-Rc5Okqk2N_DxL_x2qBrg@mail.gmail.com>
 <1053217B-1C60-4E20-A8B8-CCF9FF9A0BD1@gmail.com>
 <5D787D9D-E8D6-4C9E-8102-D9954DA43763@gmail.com>
Message-ID: <1384820249-sup-5643@javelin>

Is this pushed?

Edward

Excerpts from Christiaan Baaij's message of 2013-11-15 00:04:30 -0800:
> I'm still puzzled as to how validate failed on snow leopard, but is working correctly on my mountain lion machine after fixing the warning in the primitive package.
> Ben: does validate go through on your machine after patching the primitive package?
> 
> Here are my results for 'validate --slow':
> 
> OVERALL SUMMARY for test run started at Thu Nov 14 14:32:18 2013 CET
>  4:15:58 spent to go through
>     3818 total tests, which gave rise to
>    14934 test cases, of which
>     3146 were skipped
> 
>      145 had missing libraries
>    11465 expected passes
>      137 expected failures
> 
>        0 caused framework failures
>        5 unexpected passes
>       36 unexpected failures
> 
> Unexpected passes:
>    codeGen/should_run           cgrun071 (optllvm)
>    ghci/linking                 T3333 (normal)
>    rename/should_compile/T3103  T3103 (hpc,optasm,optllvm)
> 
> Unexpected failures:
>    ../../libraries/unix/tests  signals004 [bad exit code] (threaded2)
>    concurrent/should_run       conc012 [bad exit code] (ghci)
>    driver                      static001 [bad stderr] (normal)
>    gadt                        type-rep [exit code non-0] (hpc,optasm,threaded2,dyn,optllvm)
>    ghc-api/apirecomp001        apirecomp001 [bad stderr] (normal)
>    lib/integer                 integerConstantFolding [bad stderr] (normal)
>    perf/compiler               T3064 [stat not good enough] (normal)
>    perf/compiler               T3294 [stderr mismatch] (normal)
>    perf/compiler               T4801 [stat too good] (normal)
>    perf/compiler               T5642 [stat not good enough] (normal)
>    perf/haddock                haddock.Cabal [stat not good enough] (normal)
>    perf/haddock                haddock.compiler [stat not good enough] (normal)
>    perf/space_leaks            space_leak_001 [stat too good] (hpc,optasm,dyn,optllvm)
>    polykinds                   T6068 [bad stderr] (ghci)
>    rts                         T7919 [exit code non-0] (normal,hpc,optasm,threaded1,threaded2,optllvm)
>    th/TH_import_loop           TH_import_loop [bad stdout or stderr] (ghci)
>    typecheck/should_run        T7861 [bad stderr] (normal,hpc,optasm,threaded1,threaded2,dyn,optllvm)
>    typecheck/should_run        T7861 [bad stdout or stderr] (ghci)
> 
> On Nov 14, 2013, at 12:04 PM, Christiaan Baaij <christiaan.baaij at gmail.com> wrote:
> 
> > After fixing the warning in the C-code of the primitive package, validate (including dph tests) seems to be working for me:
> > 
> > OVERALL SUMMARY for test run started at Thu Nov 14 11:03:26 2013 CET
> > 0:46:34 spent to go through
> >    3818 total tests, which gave rise to
> >   14930 test cases, of which
> >   11445 were skipped
> > 
> >      28 had missing libraries
> >    3394 expected passes
> >      58 expected failures
> > 
> >       0 caused framework failures
> >       1 unexpected passes
> >       4 unexpected failures
> > 
> > Unexpected passes:
> >   ghci/linking  T3333 (normal)
> > 
> > Unexpected failures:
> >   driver         static001 [bad stderr] (normal)
> >   driver/T3007   T3007 [bad exit code] (normal)
> >   perf/compiler  T3064 [stat not good enough] (normal)
> >   perf/compiler  T4801 [stat too good] (normal)
> > 
> > I'll try again with a 'make maintainer-clean', include profiling libs, and do a ./validate --slow.
> > 
> > 
> > On Nov 14, 2013, at 5:23 AM, Carter Schonwald <carter.schonwald at gmail.com> wrote:
> > 
> >> Ben has an excellent point: 
> >> 
> >> if things are broken on mac, lets fix it!  Especially since we should be hitting RC status shortly.... any breakages should be smashed ASAP.
> >> 
> >> This does raise a point I hope we'll address more aggressively after the 7.8 release, namely trying to keep ghc less broken by default! GHC being really really really broken between releases is probably the single HUGEST barrier to more people getting involved in helping GHC dev. And I think thats a huge problem we need to take more seriously. 
> >> 
> >> 
> >> 
> >> 
> >> On Wed, Nov 13, 2013 at 11:09 PM, Ben Lippmeier <benl at ouroborus.net> wrote:
> >> 
> >> On 13/11/2013, at 8:02 PM, Christiaan Baaij wrote:
> >> 
> >>> Does validate work for the DPH packages on Linux?
> >> 
> >> "sh validate" runs fine on my Linux machine, but neither of my Macs.
> >> 
> >> I can also run the dph tests manually on Linux, and they work fine.
> >> 
> >> Ben.
> >> 
> >> _______________________________________________
> >> ghc-devs mailing list
> >> ghc-devs at haskell.org
> >> http://www.haskell.org/mailman/listinfo/ghc-devs
> >> 
> > 
> 

From kazu at iij.ad.jp  Tue Nov 19 01:05:15 2013
From: kazu at iij.ad.jp (Kazu Yamamoto (=?iso-2022-jp?B?GyRCOzNLXE9CSScbKEI=?=))
Date: Tue, 19 Nov 2013 10:05:15 +0900 (JST)
Subject: Building GHC head with clang on Mavericks
In-Reply-To: <87li0lg6aw.fsf@gnu.org>
References: <20131118.151304.1483841058307923622.kazu@iij.ad.jp>
 <20131118.212406.751890840897632790.kazu@iij.ad.jp>
 <87li0lg6aw.fsf@gnu.org>
Message-ID: <20131119.100515.1464572160880688810.kazu@iij.ad.jp>

Hi,

> btw, is there really no whitespace before the '#' in line 2 ?

No space. The line starts with '#'.

For testing, I created a valid HS file using CPP and complied it with
GHC 7.6.3. A .hscpp file contains:

----
# 1 "a.hs"
# 1 "<built-in>"
# 1 "<command-line>"
# 1 "a.hs"
{-# LANGUAGE CPP #-}
----

The line 2 also starts with '#'.

Comparing this with the previous one, the difference is '1' in the end
of line.

----
# 1 "utils/genprimopcode/dist/build/Lexer.hs"
# 1 "<built-in>" 1
# 1 "utils/genprimopcode/dist/build/Lexer.hs" 2
{-# LANGUAGE CPP,MagicHash #-}
----

--Kazu

From kazu at iij.ad.jp  Tue Nov 19 01:09:38 2013
From: kazu at iij.ad.jp (Kazu Yamamoto (=?iso-2022-jp?B?GyRCOzNLXE9CSScbKEI=?=))
Date: Tue, 19 Nov 2013 10:09:38 +0900 (JST)
Subject: Building GHC head with clang on Mavericks
In-Reply-To: <20131118.212406.751890840897632790.kazu@iij.ad.jp>
References: <20131118.151304.1483841058307923622.kazu@iij.ad.jp>
 <20131118.212406.751890840897632790.kazu@iij.ad.jp>
Message-ID: <20131119.100938.717289870030761901.kazu@iij.ad.jp>

Hi,

I can finally build GHC head on Mavericks. I gave up on clang and
installed GHC 4.8 with MacPorts.

Then, I compiled alex and happy with GHC 7.6.3/GHC 4.8. With this, I
can build GHC head.

This step is a MUST. If alex and happy are complied GHC
7.6.3/clang-wrapper, I cannot build GHC head with GHC 7.6.3/GHC 4.8.

--Kazu

> Hi,
> 
> Adding the "-v" option, GHC displays:
> 
> ----
> *** Checking old interface for main:Lexer:
> *** Parser:
> *** Renamer/typechecker:
> 
> <built-in>:2:2: Not in scope: `#'
> ----
> 
> "-keep-tmp-files" keeps generated .hscpp file. The beginning of the
> generated .hscpp is:
> 
> ----
> # 1 "utils/genprimopcode/dist/build/Lexer.hs"
> # 1 "<built-in>" 1
> # 1 "utils/genprimopcode/dist/build/Lexer.hs" 2
> {-# LANGUAGE CPP,MagicHash #-}
> {-# LINE 2 "utils/genprimopcode/./Lexer.x" #-}
> ----
> 
> "<built-in>:2:2: Not in scope: `#'" in my previous message indicates
> this line 2.
> 
> I don't know why Renamer/typechecker cannot handle this .hsccp file.
> 
> --Kazu
> 
>> Hi,
>> 
>> As I wrote in the following blog article, I could build GHC head on
>> Mavericks 20 days ago.
>> 
>> 	http://d.hatena.ne.jp/kazu-yamamoto/20131028/1382921924
>> 
>> But I cannot build it recently:
>> 
>> ----
>> "/usr/bin/ghc" -hisuf hi -osuf  o -hcsuf hc -static  -H32m -O  -package-db libraries/bootstrapping.conf   -i -iutils/genprimopcode/. -iutils/genprimopcode/dist/build -iutils/genprimopcode/dist/build/autogen -Iutils/genprimopcode/dist/build -Iutils/genprimopcode/dist/build/autogen       -package array  -no-user-package-db -rtsopts      -odir utils/genprimopcode/dist/build -hidir utils/genprimopcode/dist/build -stubdir utils/genprimopcode/dist/build   -c utils/genprimopcode/dist/build/Lexer.hs -o utils/genprimopcode/dist/build/Lexer.o 
>> 
>> <built-in>:2:2: Not in scope: `#'
>> make[1]: *** [utils/genprimopcode/dist/build/Lexer.o] Error 1
>> make[1]: *** Waiting for unfinished jobs....
>> shift/reduce conflicts:  46
>> reduce/reduce conflicts: 1
>> make: *** [all] Error 2
>> ----
>> 
>> I seems to me that linemarkers generated by GCC(CPP) is not correctly
>> handled when alex is used. Note I can build GHC head on FreeBSD and
>> Linux.
>> 
>> I'm using clang with clang-xcode5-wrapper.hs.
>> 
>> Any suggestions?
>> 
>> --Kazu

From carter.schonwald at gmail.com  Tue Nov 19 01:22:36 2013
From: carter.schonwald at gmail.com (Carter Schonwald)
Date: Mon, 18 Nov 2013 20:22:36 -0500
Subject: Building GHC head with clang on Mavericks
In-Reply-To: <20131119.100938.717289870030761901.kazu@iij.ad.jp>
References: <20131118.151304.1483841058307923622.kazu@iij.ad.jp>
 <20131118.212406.751890840897632790.kazu@iij.ad.jp>
 <20131119.100938.717289870030761901.kazu@iij.ad.jp>
Message-ID: <CAHYVw0ygqa=e=yYHA-fYiAir01Dyjcb7HpYb72jtfO81g-7LwA@mail.gmail.com>

Kazu. This is exactly the problem I linked to.  Could you try the proposed
patches to test if they allow builds to succeed with a wrapped clang on
your machine?

On Monday, November 18, 2013, Kazu Yamamoto wrote:

> Hi,
>
> I can finally build GHC head on Mavericks. I gave up on clang and
> installed GHC 4.8 with MacPorts.
>
> Then, I compiled alex and happy with GHC 7.6.3/GHC 4.8. With this, I
> can build GHC head.
>
> This step is a MUST. If alex and happy are complied GHC
> 7.6.3/clang-wrapper, I cannot build GHC head with GHC 7.6.3/GHC 4.8.
>
> --Kazu
>
> > Hi,
> >
> > Adding the "-v" option, GHC displays:
> >
> > ----
> > *** Checking old interface for main:Lexer:
> > *** Parser:
> > *** Renamer/typechecker:
> >
> > <built-in>:2:2: Not in scope: `#'
> > ----
> >
> > "-keep-tmp-files" keeps generated .hscpp file. The beginning of the
> > generated .hscpp is:
> >
> > ----
> > # 1 "utils/genprimopcode/dist/build/Lexer.hs"
> > # 1 "<built-in>" 1
> > # 1 "utils/genprimopcode/dist/build/Lexer.hs" 2
> > {-# LANGUAGE CPP,MagicHash #-}
> > {-# LINE 2 "utils/genprimopcode/./Lexer.x" #-}
> > ----
> >
> > "<built-in>:2:2: Not in scope: `#'" in my previous message indicates
> > this line 2.
> >
> > I don't know why Renamer/typechecker cannot handle this .hsccp file.
> >
> > --Kazu
> >
> >> Hi,
> >>
> >> As I wrote in the following blog article, I could build GHC head on
> >> Mavericks 20 days ago.
> >>
> >>      http://d.hatena.ne.jp/kazu-yamamoto/20131028/1382921924
> >>
> >> But I cannot build it recently:
> >>
> >> ----
> >> "/usr/bin/ghc" -hisuf hi -osuf  o -hcsuf hc -static  -H32m -O
>  -package-db libraries/bootstrapping.conf   -i -iutils/genprimopcode/.
> -iutils/genprimopcode/dist/build -iutils/genprimopcode/dist/build/autogen
> -Iutils/genprimopcode/dist/build -Iutils/genprimopcode/dist/build/autogen
>     -package array  -no-user-package-db -rtsopts      -odir
> utils/genprimopcode/dist/build -hidir utils/genprimopcode/dist/build
> -stubdir utils/genprimopcode/dist/build   -c
> utils/genprimopcode/dist/build/Lexer.hs -o
> utils/genprimopcode/dist/build/Lexer.o
> >>
> >> <built-in>:2:2: Not in scope: `#'
> >> make[1]: *** [utils/genprimopcode/dist/build/Lexer.o] Error 1
> >> make[1]: *** Waiting for unfinished jobs....
> >> shift/reduce conflicts:  46
> >> reduce/reduce conflicts: 1
> >> make: *** [all] Error 2
> >> ----
> >>
> >> I seems to me that linemarkers generated by GCC(CPP) is not correctly
> >> handled when alex is used. Note I can build GHC head on FreeBSD and
> >> Linux.
> >>
> >> I'm using clang with clang-xcode5-wrapper.hs.
> >>
> >> Any suggestions?
> >>
> >> --Kazu
> _______________________________________________
> 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/20131118/743d167a/attachment.html>

From carter.schonwald at gmail.com  Tue Nov 19 08:04:42 2013
From: carter.schonwald at gmail.com (Carter Schonwald)
Date: Tue, 19 Nov 2013 03:04:42 -0500
Subject: example of great getting started guide (possible guide to improve it
 for ghc)
Message-ID: <CAHYVw0yOvdnPa=KmnZabuftcLw5HtWUZrv55Q4nJGnPQBqaXzA@mail.gmail.com>

Hey All,
I just came across the mozilla firefox "how to get involved in the dev" docs
http://codefirefox.com/ and https://news.ycombinator.com/item?id=6753583and
https://developer.mozilla.org/en-US/docs/introduction

One thing I've been very active on lately is trying to figure out how to
talk more people into trying to help out with ghc.  And  the firefox stuff
there seems to lay out a great collection of examples of ways to make it a
bit easier / managable to get involved!

figured it'd be worth sharing
-Carter
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/ghc-devs/attachments/20131119/29dbf361/attachment.html>

From difrumin at gmail.com  Tue Nov 19 09:26:06 2013
From: difrumin at gmail.com (Daniil Frumin)
Date: Tue, 19 Nov 2013 13:26:06 +0400
Subject: example of great getting started guide (possible guide to improve
 it for ghc)
In-Reply-To: <CAHYVw0yOvdnPa=KmnZabuftcLw5HtWUZrv55Q4nJGnPQBqaXzA@mail.gmail.com>
References: <CAHYVw0yOvdnPa=KmnZabuftcLw5HtWUZrv55Q4nJGnPQBqaXzA@mail.gmail.com>
Message-ID: <CACxkR4AmOf0qgUne84ZYLR6jHmnvEUsP+2SxH0hU+vMVLWR5hA@mail.gmail.com>

I like that codefirefox.com site!

GHC wiki has something similar to Mozilla's introduction page:
https://ghc.haskell.org/trac/ghc/wiki/Newcomers


On Tue, Nov 19, 2013 at 12:04 PM, Carter Schonwald <
carter.schonwald at gmail.com> wrote:

> Hey All,
> I just came across the mozilla firefox "how to get involved in the dev"
> docs
> http://codefirefox.com/ and https://news.ycombinator.com/item?id=6753583and
> https://developer.mozilla.org/en-US/docs/introduction
>
> One thing I've been very active on lately is trying to figure out how to
> talk more people into trying to help out with ghc.  And  the firefox stuff
> there seems to lay out a great collection of examples of ways to make it a
> bit easier / managable to get involved!
>
> figured it'd be worth sharing
> -Carter
>
> _______________________________________________
> ghc-devs mailing list
> ghc-devs at haskell.org
> http://www.haskell.org/mailman/listinfo/ghc-devs
>
>


-- 
Sincerely yours,
-- Daniil
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/ghc-devs/attachments/20131119/53cd5968/attachment.html>

From carter.schonwald at gmail.com  Tue Nov 19 09:39:28 2013
From: carter.schonwald at gmail.com (Carter Schonwald)
Date: Tue, 19 Nov 2013 04:39:28 -0500
Subject: example of great getting started guide (possible guide to improve
 it for ghc)
In-Reply-To: <CACxkR4AmOf0qgUne84ZYLR6jHmnvEUsP+2SxH0hU+vMVLWR5hA@mail.gmail.com>
References: <CAHYVw0yOvdnPa=KmnZabuftcLw5HtWUZrv55Q4nJGnPQBqaXzA@mail.gmail.com>
 <CACxkR4AmOf0qgUne84ZYLR6jHmnvEUsP+2SxH0hU+vMVLWR5hA@mail.gmail.com>
Message-ID: <CAHYVw0xZc2Eg8uKUOSdcj-+FwgsuJ9rRcKCZhhHMA2km=A_XLw@mail.gmail.com>

good point, that should maybe be more prominently discoverable!

relatedly: how are the 'low haning fruit" tickets on that page generated? I
can't see how


On Tue, Nov 19, 2013 at 4:26 AM, Daniil Frumin <difrumin at gmail.com> wrote:

> I like that codefirefox.com site!
>
> GHC wiki has something similar to Mozilla's introduction page:
> https://ghc.haskell.org/trac/ghc/wiki/Newcomers
>
>
> On Tue, Nov 19, 2013 at 12:04 PM, Carter Schonwald <
> carter.schonwald at gmail.com> wrote:
>
>> Hey All,
>> I just came across the mozilla firefox "how to get involved in the dev"
>> docs
>> http://codefirefox.com/ and https://news.ycombinator.com/item?id=6753583and
>> https://developer.mozilla.org/en-US/docs/introduction
>>
>> One thing I've been very active on lately is trying to figure out how to
>> talk more people into trying to help out with ghc.  And  the firefox stuff
>> there seems to lay out a great collection of examples of ways to make it a
>> bit easier / managable to get involved!
>>
>> figured it'd be worth sharing
>> -Carter
>>
>> _______________________________________________
>> ghc-devs mailing list
>> ghc-devs at haskell.org
>> http://www.haskell.org/mailman/listinfo/ghc-devs
>>
>>
>
>
> --
> Sincerely yours,
> -- Daniil
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/ghc-devs/attachments/20131119/a7e546e7/attachment.html>

From simonpj at microsoft.com  Tue Nov 19 09:57:53 2013
From: simonpj at microsoft.com (Simon Peyton-Jones)
Date: Tue, 19 Nov 2013 09:57:53 +0000
Subject: example of great getting started guide (possible guide to
 improve it for ghc)
In-Reply-To: <CAHYVw0yOvdnPa=KmnZabuftcLw5HtWUZrv55Q4nJGnPQBqaXzA@mail.gmail.com>
References: <CAHYVw0yOvdnPa=KmnZabuftcLw5HtWUZrv55Q4nJGnPQBqaXzA@mail.gmail.com>
Message-ID: <59543203684B2244980D7E4057D5FBC1486A4F41@DB3EX14MBXC306.europe.corp.microsoft.com>

I think it?d be great to reduce the barrier to entry for newcomers, and would welcome anything you (or anyone else) can do to help.  Thanks!

Simon

From: ghc-devs [mailto:ghc-devs-bounces at haskell.org] On Behalf Of Carter Schonwald
Sent: 19 November 2013 08:05
To: ghc-devs at haskell.org
Subject: example of great getting started guide (possible guide to improve it for ghc)

Hey All,
I just came across the mozilla firefox "how to get involved in the dev" docs
http://codefirefox.com/ and https://news.ycombinator.com/item?id=6753583 and https://developer.mozilla.org/en-US/docs/introduction
One thing I've been very active on lately is trying to figure out how to talk more people into trying to help out with ghc.  And  the firefox stuff there seems to lay out a great collection of examples of ways to make it a bit easier / managable to get involved!
figured it'd be worth sharing
-Carter
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/ghc-devs/attachments/20131119/b037b28c/attachment-0001.html>

From simonpj at microsoft.com  Tue Nov 19 10:58:30 2013
From: simonpj at microsoft.com (Simon Peyton-Jones)
Date: Tue, 19 Nov 2013 10:58:30 +0000
Subject: templateHaskellNames
In-Reply-To: <87A4475C-1E4A-4646-ABD0-B5216BE93C09@cis.upenn.edu>
References: <87A4475C-1E4A-4646-ABD0-B5216BE93C09@cis.upenn.edu>
Message-ID: <59543203684B2244980D7E4057D5FBC1486A563F@DB3EX14MBXC306.europe.corp.microsoft.com>

Uniques are only fixed per-run of the compiler.
So when DsMeta (which uses those Names) runs, it generates Core with Names in it (e.g. Language.Hasekell.TH.Syntax.returnQ.  When we go to Language/Hasekell/TH/Syntax.hi interface file, and read it in, we'd better use the same unique for return that DsMeta generated.  But DsMeta only runs in stage2.

So I think it's fine.

Simon

| -----Original Message-----
| From: ghc-devs [mailto:ghc-devs-bounces at haskell.org] On Behalf Of
| Richard Eisenberg
| Sent: 15 November 2013 14:57
| To: ghc-devs at haskell.org Devs
| Subject: templateHaskellNames
| 
| Hi devs,
| 
| I happened to be looking through the code dealing with known names, and
| I'm a little confused about templateHaskellNames. In particular, I'm
| confused why it's included in knownKeyNames only when GHCI is defined.
| (See lines 196-198 of HscMain.) It's the stage 1 compiler that compiles
| the TH library, when the known key names are so important. Couldn't this
| cause very strange behavior if some of the numbers are changed? Or, am I
| misunderstanding something here?
| 
| This is certainly a minor problem, but it could give someone down the
| road a headache if it were to happen.
| 
| Thanks,
| Richard
| _______________________________________________
| ghc-devs mailing list
| ghc-devs at haskell.org
| http://www.haskell.org/mailman/listinfo/ghc-devs

From jan.stolarek at p.lodz.pl  Tue Nov 19 12:45:07 2013
From: jan.stolarek at p.lodz.pl (Jan Stolarek)
Date: Tue, 19 Nov 2013 13:45:07 +0100
Subject: example of great getting started guide (possible guide to improve
 it for ghc)
In-Reply-To: <CAHYVw0xZc2Eg8uKUOSdcj-+FwgsuJ9rRcKCZhhHMA2km=A_XLw@mail.gmail.com>
References: <CAHYVw0yOvdnPa=KmnZabuftcLw5HtWUZrv55Q4nJGnPQBqaXzA@mail.gmail.com>
 <CACxkR4AmOf0qgUne84ZYLR6jHmnvEUsP+2SxH0hU+vMVLWR5hA@mail.gmail.com>
 <CAHYVw0xZc2Eg8uKUOSdcj-+FwgsuJ9rRcKCZhhHMA2km=A_XLw@mail.gmail.com>
Message-ID: <201311191345.07644.jan.stolarek@p.lodz.pl>

> relatedly: how are the 'low haning fruit" tickets on that page generated? I
> can't see how
Arbitrarily :-) Any developer can add a "low hanging fruit" ticket if he judges that: a) ticket is 
relatively easy for a beginner to tackle and; b) is willing to aid a beginner in working on that 
ticket (though this is not strictly necessary if one judges that support from ghc-devs will be 
sufficient). For example I added #8308 because I can guide a beginner through implementation of 
that ticket (at least I believe so).

> I think it?d be great to reduce the barrier to entry for newcomers, and would welcome anything 
you (or anyone else) can do to help.? Thanks!
Yes, reducing barrier for beginners would be a great thing to do (I remember how frustrating were 
my beginnings with GHC) but that would be an investment - meaning that we would have to put a lot 
of effort into it hoping that in the future we will have more developers. The best thing I could 
imagine would be videos presenting implementation of GHC. Something like that was already 
recorded during Hackathons but that vidoes have horrible quality and are almost impossible to 
watch. If we could re-record that with better quality (and more up-to-date) it would be great.

Janek

>
> On Tue, Nov 19, 2013 at 4:26 AM, Daniil Frumin <difrumin at gmail.com> wrote:
> > I like that codefirefox.com site!
> >
> > GHC wiki has something similar to Mozilla's introduction page:
> > https://ghc.haskell.org/trac/ghc/wiki/Newcomers
> >
> >
> > On Tue, Nov 19, 2013 at 12:04 PM, Carter Schonwald <
> >
> > carter.schonwald at gmail.com> wrote:
> >> Hey All,
> >> I just came across the mozilla firefox "how to get involved in the dev"
> >> docs
> >> http://codefirefox.com/ and
> >> https://news.ycombinator.com/item?id=6753583and
> >> https://developer.mozilla.org/en-US/docs/introduction
> >>
> >> One thing I've been very active on lately is trying to figure out how to
> >> talk more people into trying to help out with ghc.  And  the firefox
> >> stuff there seems to lay out a great collection of examples of ways to
> >> make it a bit easier / managable to get involved!
> >>
> >> figured it'd be worth sharing
> >> -Carter
> >>
> >> _______________________________________________
> >> ghc-devs mailing list
> >> ghc-devs at haskell.org
> >> http://www.haskell.org/mailman/listinfo/ghc-devs
> >
> > --
> > Sincerely yours,
> > -- Daniil



From jan.stolarek at p.lodz.pl  Tue Nov 19 13:14:57 2013
From: jan.stolarek at p.lodz.pl (Jan Stolarek)
Date: Tue, 19 Nov 2013 14:14:57 +0100
Subject: bundle panic
In-Reply-To: <528892EC.60707@gmail.com>
References: <59543203684B2244980D7E4057D5FBC1486A0192@DB3EX14MBXC306.europe.corp.microsoft.com>
 <528892EC.60707@gmail.com>
Message-ID: <201311191414.57047.jan.stolarek@p.lodz.pl>

I don't see any commit fixing this so I assume that this is still relevant.

> Perhaps this is a problem that only shows up with proc points, which is
> why you wouldn't see it on x86_64/Linux. 
Wouldn't this also break some of Mac builds? Besides, my change was commited a few weeks ago, 
while Simon says this didn't happen a few days before.

> But Jan?s new optimisation to the stack overflow check (Note [Always false stack check] in
> CmmLayoutStack) ends up dropping a conditional branch, 
In theory my optimisation should not affect elimination of unnecessary branches in any way - this 
optimisation was there before. Note also that the last thing we do in Cmm pipeline is call to 
removeUnreachableBlocksProc so any unreachable block should be eliminated from the final graph - 
bundle is called later.

>so a call to gc is eliminated
A random guess: https://github.com/ghc/ghc/commit/ad0b943293cce74baf06ea36e1a4d51a3631dfdf
This was commited two days before you reported the problem and is GC-related.

Janek

Dnia niedziela, 17 listopada 2013, Simon Marlow napisa?:
> On 16/11/13 00:16, Simon Peyton-Jones wrote:
> > I?ve looked into this myself.  I don?t think it?s actually anything
> > wrong in gmp-wrappers.  It?s because CmmBuildInfoTables expects all the
> > info tables in the (CmmProc info_tbls lbl g) to be defined in the graph
> > g.
> >
> > But Jan?s new optimisation to the stack overflow check (Note [Always
> > false stack check] in CmmLayoutStack) ends up dropping a conditional
> > branch, so a call to gc is eliminated, and hence a proc point is
> > eliminated, and we end up with an unused thing in info_tbls, which
> > confuses CmmBuildInfoTables
> >
> > Sigh. I don?t know why this only happens on Windows.  I?m looking into a
> > fix
>
> Perhaps this is a problem that only shows up with proc points, which is
> why you wouldn't see it on x86_64/Linux.  Let me know if you get stuck
> and I'll try to look into it.
>
> FYI eliminating always-false stack checks is not new, it was temporarily
> broken by:
>
> commit 94125c97e49987e91fa54da6c86bc6d17417f5cf
> Author: Jan Stolarek <jan.stolarek at p.lodz.pl>
> Date:   Wed Oct 16 09:45:56 2013 +0200
>
>      Generate (old + 0) instead of Sp in stack checks
>
> and then fixed up by:
>
> commit 1cf0c8ad321d1d358cbec46d35be02566faf2d00
> Author: Jan Stolarek <jan.stolarek at p.lodz.pl>
> Date:   Thu Oct 17 23:17:06 2013 +0200
>
>      Optimise stack checks that are always false
>
> Cheers,
> Simon
>
> > Simon
> >
> > *From:*Simon Peyton-Jones
> > *Sent:* 15 November 2013 22:18
> > *To:* ghc-devs at haskell.org
> > *Subject:* bundle panic
> >
> > Windows build is failing again in a new way.  It was fine a couple of
> > days ago. Does this ring any bells?
> >
> > ghc-stage1.exe: panic! (the 'impossible' happened)
> >
> >    (GHC version 7.7.20131107 for i386-unknown-mingw32):
> >
> >       bundle
> >
> > Simon
> >
> > "inplace/bin/ghc-stage1.exe" -static  -H32m -O -Werror -Wall -H64m
> > -O0    -package-name integer-gmp-0.5.1.0 -hide-all-packages -i
> > -ilibraries/integer-gmp/. -ilibraries/integer-gmp/dist-install/build
> > -ilibraries/integer-gmp/dist-install/build/autogen
> > -Ilibraries/integer-gmp/dist-install/build
> > -Ilibraries/integer-gmp/dist-install/build/autogen
> > -Ilibraries/integer-gmp/.    -optP-include
> > -optPlibraries/integer-gmp/dist-install/build/autogen/cabal_macros.h
> > -package ghc-prim-0.3.1.0 -Wall -package-name integer-gmp -XHaskell2010
> > -dcore-lint  -no-user-package-db -rtsopts
> > -Ilibraries/integer-gmp/mkGmpDerivedConstants/dist     -c
> > libraries/integer-gmp/cbits/gmp-wrappers.cmm -o
> > libraries/integer-gmp/dist-install/build/cbits/gmp-wrappers.o
> >
> > ghc-stage1.exe: panic! (the 'impossible' happened)
> >
> >    (GHC version 7.7.20131107 for i386-unknown-mingw32):
> >
> >       bundle
> >
> >      c8 integer_cmm_importIntegerFromByteArrayzh [(c8,
> >
> >                                                    label: block{v
> > c8}_info
> >
> >                                                    rep:StackRep [False,
> > True, True, True]),
> >
> >                                                   (cg,
> >
> >                                                    label: block{v
> > cg}_info
> >
> >                                                    rep:StackRep [False,
> > True, True, True])]
> >
> > Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug
> >
> > HEAD (master)$
> >
> >
> >
> > _______________________________________________
> > 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 christiaan.baaij at gmail.com  Tue Nov 19 13:46:32 2013
From: christiaan.baaij at gmail.com (Christiaan Baaij)
Date: Tue, 19 Nov 2013 14:46:32 +0100
Subject: Validate broken on Snow Leopard and Mountain Lion
In-Reply-To: <1384820249-sup-5643@javelin>
References: <21E81090-2380-4DF9-96F7-86773FCEC65C@ouroborus.net>
 <7ECCA023-9D11-4423-BEA5-3ADA6D1D8588@gmail.com>
 <F59FB7DC-0CED-4F6B-AD8E-A343E66DEA3B@ouroborus.net>
 <CAHYVw0yCxAagJxCB3Mw=OH=DadneW-Rc5Okqk2N_DxL_x2qBrg@mail.gmail.com>
 <1053217B-1C60-4E20-A8B8-CCF9FF9A0BD1@gmail.com>
 <5D787D9D-E8D6-4C9E-8102-D9954DA43763@gmail.com>
 <1384820249-sup-5643@javelin>
Message-ID: <721D4D19-D84E-4C40-BF2C-0FE3C17E2A94@gmail.com>

Raised as issue on github: https://github.com/haskell/primitive/issues/4

On Nov 19, 2013, at 1:17 AM, Edward Z. Yang <ezyang at MIT.EDU> wrote:

> Is this pushed?
> 
> Edward
> 
> Excerpts from Christiaan Baaij's message of 2013-11-15 00:04:30 -0800:
>> I'm still puzzled as to how validate failed on snow leopard, but is working correctly on my mountain lion machine after fixing the warning in the primitive package.
>> Ben: does validate go through on your machine after patching the primitive package?
>> 
>> Here are my results for 'validate --slow':
>> 
>> OVERALL SUMMARY for test run started at Thu Nov 14 14:32:18 2013 CET
>> 4:15:58 spent to go through
>>    3818 total tests, which gave rise to
>>   14934 test cases, of which
>>    3146 were skipped
>> 
>>     145 had missing libraries
>>   11465 expected passes
>>     137 expected failures
>> 
>>       0 caused framework failures
>>       5 unexpected passes
>>      36 unexpected failures
>> 
>> Unexpected passes:
>>   codeGen/should_run           cgrun071 (optllvm)
>>   ghci/linking                 T3333 (normal)
>>   rename/should_compile/T3103  T3103 (hpc,optasm,optllvm)
>> 
>> Unexpected failures:
>>   ../../libraries/unix/tests  signals004 [bad exit code] (threaded2)
>>   concurrent/should_run       conc012 [bad exit code] (ghci)
>>   driver                      static001 [bad stderr] (normal)
>>   gadt                        type-rep [exit code non-0] (hpc,optasm,threaded2,dyn,optllvm)
>>   ghc-api/apirecomp001        apirecomp001 [bad stderr] (normal)
>>   lib/integer                 integerConstantFolding [bad stderr] (normal)
>>   perf/compiler               T3064 [stat not good enough] (normal)
>>   perf/compiler               T3294 [stderr mismatch] (normal)
>>   perf/compiler               T4801 [stat too good] (normal)
>>   perf/compiler               T5642 [stat not good enough] (normal)
>>   perf/haddock                haddock.Cabal [stat not good enough] (normal)
>>   perf/haddock                haddock.compiler [stat not good enough] (normal)
>>   perf/space_leaks            space_leak_001 [stat too good] (hpc,optasm,dyn,optllvm)
>>   polykinds                   T6068 [bad stderr] (ghci)
>>   rts                         T7919 [exit code non-0] (normal,hpc,optasm,threaded1,threaded2,optllvm)
>>   th/TH_import_loop           TH_import_loop [bad stdout or stderr] (ghci)
>>   typecheck/should_run        T7861 [bad stderr] (normal,hpc,optasm,threaded1,threaded2,dyn,optllvm)
>>   typecheck/should_run        T7861 [bad stdout or stderr] (ghci)
>> 
>> On Nov 14, 2013, at 12:04 PM, Christiaan Baaij <christiaan.baaij at gmail.com> wrote:
>> 
>>> After fixing the warning in the C-code of the primitive package, validate (including dph tests) seems to be working for me:
>>> 
>>> OVERALL SUMMARY for test run started at Thu Nov 14 11:03:26 2013 CET
>>> 0:46:34 spent to go through
>>>   3818 total tests, which gave rise to
>>>  14930 test cases, of which
>>>  11445 were skipped
>>> 
>>>     28 had missing libraries
>>>   3394 expected passes
>>>     58 expected failures
>>> 
>>>      0 caused framework failures
>>>      1 unexpected passes
>>>      4 unexpected failures
>>> 
>>> Unexpected passes:
>>>  ghci/linking  T3333 (normal)
>>> 
>>> Unexpected failures:
>>>  driver         static001 [bad stderr] (normal)
>>>  driver/T3007   T3007 [bad exit code] (normal)
>>>  perf/compiler  T3064 [stat not good enough] (normal)
>>>  perf/compiler  T4801 [stat too good] (normal)
>>> 
>>> I'll try again with a 'make maintainer-clean', include profiling libs, and do a ./validate --slow.
>>> 
>>> 
>>> On Nov 14, 2013, at 5:23 AM, Carter Schonwald <carter.schonwald at gmail.com> wrote:
>>> 
>>>> Ben has an excellent point: 
>>>> 
>>>> if things are broken on mac, lets fix it!  Especially since we should be hitting RC status shortly.... any breakages should be smashed ASAP.
>>>> 
>>>> This does raise a point I hope we'll address more aggressively after the 7.8 release, namely trying to keep ghc less broken by default! GHC being really really really broken between releases is probably the single HUGEST barrier to more people getting involved in helping GHC dev. And I think thats a huge problem we need to take more seriously. 
>>>> 
>>>> 
>>>> 
>>>> 
>>>> On Wed, Nov 13, 2013 at 11:09 PM, Ben Lippmeier <benl at ouroborus.net> wrote:
>>>> 
>>>> On 13/11/2013, at 8:02 PM, Christiaan Baaij wrote:
>>>> 
>>>>> Does validate work for the DPH packages on Linux?
>>>> 
>>>> "sh validate" runs fine on my Linux machine, but neither of my Macs.
>>>> 
>>>> I can also run the dph tests manually on Linux, and they work fine.
>>>> 
>>>> Ben.
>>>> 
>>>> _______________________________________________
>>>> ghc-devs mailing list
>>>> ghc-devs at haskell.org
>>>> http://www.haskell.org/mailman/listinfo/ghc-devs
>>>> 
>>> 
>> 


From kazu at iij.ad.jp  Tue Nov 19 14:02:28 2013
From: kazu at iij.ad.jp (Kazu Yamamoto (=?iso-2022-jp?B?GyRCOzNLXE9CSScbKEI=?=))
Date: Tue, 19 Nov 2013 23:02:28 +0900 (JST)
Subject: Building GHC head with clang on Mavericks
In-Reply-To: <CAHYVw0ygqa=e=yYHA-fYiAir01Dyjcb7HpYb72jtfO81g-7LwA@mail.gmail.com>
References: <20131118.212406.751890840897632790.kazu@iij.ad.jp>
 <20131119.100938.717289870030761901.kazu@iij.ad.jp>
 <CAHYVw0ygqa=e=yYHA-fYiAir01Dyjcb7HpYb72jtfO81g-7LwA@mail.gmail.com>
Message-ID: <20131119.230228.844779637094695740.kazu@iij.ad.jp>

Hi Carter,
SimonM, please read this message.

I will answer Carter's question and show a solution of my problem.

> Kazu. This is exactly the problem I linked to.  Could you try the proposed
> patches to test if they allow builds to succeed with a wrapped clang on
> your machine?

I installed nkpart's alex and happy with GHC/clang-wrapper. With this
alex and happy, I can build GHC head with GHC/GCC42. But I cannot
build GHC head with GHC/clang-wrapper.

Moreover, I can install happy and alex with GHC/clang-wrapper without
nkpart's patches.

I think that your problem is how to build alex and happy with
GHC/clang-wrapper. But my problem is how to compile HS files created
by alex and happy with GHC/clang-wrapper.

After deep investigation, I found the source of my problem. Consider
the following file created by CPP of clang or GCC:

----
# 1 "<built-inxxx>" 1
# 1 "templates/GenericTemplatexxx.hs" 2
{-# FOO
  #-}
----

% clang -E -undef -x assembler-with-cpp this_file
generates:

----
# 1 "test"
# 1 "<built-in>" 1
# 1 "test" 2
 # 1 "<built-inxxx>" 1

 # 1 "templates/GenericTemplatexxx.hs" 2

{-# FOO
  #-}
----

So, the line started with " #" cannot be treated by GHC. This is the
problem.

% clang -E -undef -x c this_file
generates:

----
# 1 "test"
# 1 "<built-in>" 1
# 1 "<built-in>" 3



# 1 "<command line>" 1
# 1 "<built-in>" 2
# 1 "test" 2
# 1 "<built-inxxx>" 1
# 1 "templates/GenericTemplatexxx.hs" 2
{-# FOO
----

And an error occurs because of "  #-}".

So, replacing "-x c" with "-x assembler-with-cpp" in a wrapper is a
MUST. And HS files generated by alex and happy should not include
lines started with "# ".

My solution so far is adding "-optP-P" to alex and happy to not
generate line markers. An example patch to alex is attached.

I can build GHC head with GHC/clang-wrapper and with alex and happy
with this hack.

--Kazu

diff --git a/Setup.lhs b/Setup.lhs
index 302a3f0..6ab62d5 100644
--- a/Setup.lhs
+++ b/Setup.lhs
@@ -44,7 +44,7 @@ myPostBuild _ flags _ lbi = do
       runProgram p = rawSystemProgramConf verbosity p (withPrograms lbi)
       cpp_template src dst opts = do
         let tmp = dst ++ ".tmp"
-        runProgram ghcProgram (["-o", tmp, "-E", "-cpp", "templates" </> src] ++ opts)
+        runProgram ghcProgram (["-o", tmp, "-E", "-cpp", "-optP-P", "templates" </> src] ++ opts)
         writeFile dst . unlines . map mungeLinePragma . lines =<< readFile tmp
         removeFile tmp
 





From carter.schonwald at gmail.com  Tue Nov 19 16:24:13 2013
From: carter.schonwald at gmail.com (Carter Schonwald)
Date: Tue, 19 Nov 2013 11:24:13 -0500
Subject: Building GHC head with clang on Mavericks
In-Reply-To: <20131119.230228.844779637094695740.kazu@iij.ad.jp>
References: <20131118.212406.751890840897632790.kazu@iij.ad.jp>
 <20131119.100938.717289870030761901.kazu@iij.ad.jp>
 <CAHYVw0ygqa=e=yYHA-fYiAir01Dyjcb7HpYb72jtfO81g-7LwA@mail.gmail.com>
 <20131119.230228.844779637094695740.kazu@iij.ad.jp>
Message-ID: <CAHYVw0xYGPS3C31Xb1rS7g8URP_zFSWETFxqwJvVQW=RFypRyg@mail.gmail.com>

So did you find a bug in the current design of the clang-wrapper hack? If
so it'd be better to get it fixed there rather than in the Alex/happy setup
HS files.

On Tuesday, November 19, 2013, Kazu Yamamoto wrote:

> Hi Carter,
> SimonM, please read this message.
>
> I will answer Carter's question and show a solution of my problem.
>
> > Kazu. This is exactly the problem I linked to.  Could you try the
> proposed
> > patches to test if they allow builds to succeed with a wrapped clang on
> > your machine?
>
> I installed nkpart's alex and happy with GHC/clang-wrapper. With this
> alex and happy, I can build GHC head with GHC/GCC42. But I cannot
> build GHC head with GHC/clang-wrapper.
>
> Moreover, I can install happy and alex with GHC/clang-wrapper without
> nkpart's patches.
>
> I think that your problem is how to build alex and happy with
> GHC/clang-wrapper. But my problem is how to compile HS files created
> by alex and happy with GHC/clang-wrapper.
>
> After deep investigation, I found the source of my problem. Consider
> the following file created by CPP of clang or GCC:
>
> ----
> # 1 "<built-inxxx>" 1
> # 1 "templates/GenericTemplatexxx.hs" 2
> {-# FOO
>   #-}
> ----
>
> % clang -E -undef -x assembler-with-cpp this_file
> generates:
>
> ----
> # 1 "test"
> # 1 "<built-in>" 1
> # 1 "test" 2
>  # 1 "<built-inxxx>" 1
>
>  # 1 "templates/GenericTemplatexxx.hs" 2
>
> {-# FOO
>   #-}
> ----
>
> So, the line started with " #" cannot be treated by GHC. This is the
> problem.
>
> % clang -E -undef -x c this_file
> generates:
>
> ----
> # 1 "test"
> # 1 "<built-in>" 1
> # 1 "<built-in>" 3
>
>
>
> # 1 "<command line>" 1
> # 1 "<built-in>" 2
> # 1 "test" 2
> # 1 "<built-inxxx>" 1
> # 1 "templates/GenericTemplatexxx.hs" 2
> {-# FOO
> ----
>
> And an error occurs because of "  #-}".
>
> So, replacing "-x c" with "-x assembler-with-cpp" in a wrapper is a
> MUST. And HS files generated by alex and happy should not include
> lines started with "# ".
>
> My solution so far is adding "-optP-P" to alex and happy to not
> generate line markers. An example patch to alex is attached.
>
> I can build GHC head with GHC/clang-wrapper and with alex and happy
> with this hack.
>
> --Kazu
>
> diff --git a/Setup.lhs b/Setup.lhs
> index 302a3f0..6ab62d5 100644
> --- a/Setup.lhs
> +++ b/Setup.lhs
> @@ -44,7 +44,7 @@ myPostBuild _ flags _ lbi = do
>        runProgram p = rawSystemProgramConf verbosity p (withPrograms lbi)
>        cpp_template src dst opts = do
>          let tmp = dst ++ ".tmp"
> -        runProgram ghcProgram (["-o", tmp, "-E", "-cpp", "templates" </>
> src] ++ opts)
> +        runProgram ghcProgram (["-o", tmp, "-E", "-cpp", "-optP-P",
> "templates" </> src] ++ opts)
>          writeFile dst . unlines . map mungeLinePragma . lines =<<
> readFile tmp
>          removeFile tmp
>
>
>
>
>
> _______________________________________________
> 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/20131119/5a5d4553/attachment-0001.html>

From kazu at iij.ad.jp  Tue Nov 19 21:52:09 2013
From: kazu at iij.ad.jp (Kazu Yamamoto (=?iso-2022-jp?B?GyRCOzNLXE9CSScbKEI=?=))
Date: Wed, 20 Nov 2013 06:52:09 +0900 (JST)
Subject: Building GHC head with clang on Mavericks
In-Reply-To: <CAHYVw0xYGPS3C31Xb1rS7g8URP_zFSWETFxqwJvVQW=RFypRyg@mail.gmail.com>
References: <CAHYVw0ygqa=e=yYHA-fYiAir01Dyjcb7HpYb72jtfO81g-7LwA@mail.gmail.com>
 <20131119.230228.844779637094695740.kazu@iij.ad.jp>
 <CAHYVw0xYGPS3C31Xb1rS7g8URP_zFSWETFxqwJvVQW=RFypRyg@mail.gmail.com>
Message-ID: <20131120.065209.105301243586485441.kazu@iij.ad.jp>

> So did you find a bug in the current design of the clang-wrapper hack? 

No. What I found is that the current design of the clang-wrapper hack
is appropriate.

"-x assembler-with-cpp" is necessary to rescue
----
{-# RULE whatever
  #-}
---

> If so it'd be better to get it fixed there rather than in the
> Alex/happy setup HS files.

If we can do this, it's very good. But this is not good enough. 
happy/alex hack are also necessary to not generate
----
 # 1 "<built-inxxx>" 1

 # 1 "templates/GenericTemplatexxx.hs" 2
----

--Kazu

From carter.schonwald at gmail.com  Tue Nov 19 22:17:09 2013
From: carter.schonwald at gmail.com (Carter Schonwald)
Date: Tue, 19 Nov 2013 17:17:09 -0500
Subject: Building GHC head with clang on Mavericks
In-Reply-To: <20131120.065209.105301243586485441.kazu@iij.ad.jp>
References: <CAHYVw0ygqa=e=yYHA-fYiAir01Dyjcb7HpYb72jtfO81g-7LwA@mail.gmail.com>
 <20131119.230228.844779637094695740.kazu@iij.ad.jp>
 <CAHYVw0xYGPS3C31Xb1rS7g8URP_zFSWETFxqwJvVQW=RFypRyg@mail.gmail.com>
 <20131120.065209.105301243586485441.kazu@iij.ad.jp>
Message-ID: <CAHYVw0xRKXstH7xMtLLChqa1Ur1ha2BWO=o_UMEga-GseubJbw@mail.gmail.com>

so what are you proposing? Are you agreeing that those patches work with
clang wrapper, but also remarking that its unfortunate that such a hack is
needed?




On Tue, Nov 19, 2013 at 4:52 PM, Kazu Yamamoto <kazu at iij.ad.jp> wrote:

> > So did you find a bug in the current design of the clang-wrapper hack?
>
> No. What I found is that the current design of the clang-wrapper hack
> is appropriate.
>
> "-x assembler-with-cpp" is necessary to rescue
> ----
> {-# RULE whatever
>   #-}
> ---
>
> > If so it'd be better to get it fixed there rather than in the
> > Alex/happy setup HS files.
>
> If we can do this, it's very good. But this is not good enough.
> happy/alex hack are also necessary to not generate
> ----
>  # 1 "<built-inxxx>" 1
>
>  # 1 "templates/GenericTemplatexxx.hs" 2
> ----
>
> --Kazu
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/ghc-devs/attachments/20131119/a2673a70/attachment.html>

From kazu at iij.ad.jp  Wed Nov 20 00:21:46 2013
From: kazu at iij.ad.jp (Kazu Yamamoto (=?iso-2022-jp?B?GyRCOzNLXE9CSScbKEI=?=))
Date: Wed, 20 Nov 2013 09:21:46 +0900 (JST)
Subject: Building GHC head with clang on Mavericks
In-Reply-To: <CAHYVw0xRKXstH7xMtLLChqa1Ur1ha2BWO=o_UMEga-GseubJbw@mail.gmail.com>
References: <CAHYVw0xYGPS3C31Xb1rS7g8URP_zFSWETFxqwJvVQW=RFypRyg@mail.gmail.com>
 <20131120.065209.105301243586485441.kazu@iij.ad.jp>
 <CAHYVw0xRKXstH7xMtLLChqa1Ur1ha2BWO=o_UMEga-GseubJbw@mail.gmail.com>
Message-ID: <20131120.092146.1218524942679029115.kazu@iij.ad.jp>

Hi,

> so what are you proposing?

I'm not proposing anything. I just want to share information so that
we can find a good solution.

> Are you agreeing that those patches work with clang wrapper, but
> also remarking that its unfortunate that such a hack is needed?

As I said, nkpart's patches are not necessary in my environment. But
they do not side-effect, so it is fine with me to apply these patches.

--Kazu

From kazu at iij.ad.jp  Wed Nov 20 00:55:07 2013
From: kazu at iij.ad.jp (Kazu Yamamoto (=?iso-2022-jp?B?GyRCOzNLXE9CSScbKEI=?=))
Date: Wed, 20 Nov 2013 09:55:07 +0900 (JST)
Subject: Building GHC head with clang on Mavericks
In-Reply-To: <20131120.065209.105301243586485441.kazu@iij.ad.jp>
References: <20131119.230228.844779637094695740.kazu@iij.ad.jp>
 <CAHYVw0xYGPS3C31Xb1rS7g8URP_zFSWETFxqwJvVQW=RFypRyg@mail.gmail.com>
 <20131120.065209.105301243586485441.kazu@iij.ad.jp>
Message-ID: <20131120.095507.611297567268489475.kazu@iij.ad.jp>

Hi,

> No. What I found is that the current design of the clang-wrapper hack
> is appropriate.
> 
> "-x assembler-with-cpp" is necessary to rescue
> ----
> {-# RULE whatever
>   #-}
> ---

I read the source of clang. The argument of "-x" is defined in
lib/Frontend/CompilerInvocation.cpp:

      .Case("c", IK_C)
      .Case("cl", IK_OpenCL)
      .Case("cuda", IK_CUDA)
      .Case("c++", IK_CXX)
      .Case("objective-c", IK_ObjC)
      .Case("objective-c++", IK_ObjCXX)
      .Case("cpp-output", IK_PreprocessedC)
      .Case("assembler-with-cpp", IK_Asm)
      .Case("c++-cpp-output", IK_PreprocessedCXX)
      .Case("objective-c-cpp-output", IK_PreprocessedObjC)
      .Case("objc-cpp-output", IK_PreprocessedObjC)
      .Case("objective-c++-cpp-output", IK_PreprocessedObjCXX)
      .Case("objc++-cpp-output", IK_PreprocessedObjCXX)
      .Case("c-header", IK_C)
      .Case("cl-header", IK_OpenCL)
      .Case("objective-c-header", IK_ObjC)
      .Case("c++-header", IK_CXX)
      .Case("objective-c++-header", IK_ObjCXX)
      .Cases("ast", "pcm", IK_AST)
      .Case("ir", IK_LLVM_IR)

In my experiment, no argument except "assembler-with-cpp" can rescue
"  #-}".

--Kazu


From carter.schonwald at gmail.com  Wed Nov 20 03:36:32 2013
From: carter.schonwald at gmail.com (Carter Schonwald)
Date: Tue, 19 Nov 2013 22:36:32 -0500
Subject: Building GHC head with clang on Mavericks
In-Reply-To: <20131120.095507.611297567268489475.kazu@iij.ad.jp>
References: <20131119.230228.844779637094695740.kazu@iij.ad.jp>
 <CAHYVw0xYGPS3C31Xb1rS7g8URP_zFSWETFxqwJvVQW=RFypRyg@mail.gmail.com>
 <20131120.065209.105301243586485441.kazu@iij.ad.jp>
 <20131120.095507.611297567268489475.kazu@iij.ad.jp>
Message-ID: <CAHYVw0xhCYY--oRtWTGnXKpPLLEOdqD_4ZxPsHN29pjhP1VrKA@mail.gmail.com>

Yes.  So we agree.

 Clang only works with ghc when passed that flag.  Hence for building ghc,
clang should only be called via a wrapper script if the host ghc is 7.6 or
older.

The whole point of the clang wrapper script is to pass that flag.

Nicks patch to Alex and happy is to address a further quirk of clang cpp.

Was there an issue if you used a wrapped clang and those patches or not?
I'm really confused.

Cheers

-carter


On Tuesday, November 19, 2013, Kazu Yamamoto wrote:

> Hi,
>
> > No. What I found is that the current design of the clang-wrapper hack
> > is appropriate.
> >
> > "-x assembler-with-cpp" is necessary to rescue
> > ----
> > {-# RULE whatever
> >   #-}
> > ---
>
> I read the source of clang. The argument of "-x" is defined in
> lib/Frontend/CompilerInvocation.cpp:
>
>       .Case("c", IK_C)
>       .Case("cl", IK_OpenCL)
>       .Case("cuda", IK_CUDA)
>       .Case("c++", IK_CXX)
>       .Case("objective-c", IK_ObjC)
>       .Case("objective-c++", IK_ObjCXX)
>       .Case("cpp-output", IK_PreprocessedC)
>       .Case("assembler-with-cpp", IK_Asm)
>       .Case("c++-cpp-output", IK_PreprocessedCXX)
>       .Case("objective-c-cpp-output", IK_PreprocessedObjC)
>       .Case("objc-cpp-output", IK_PreprocessedObjC)
>       .Case("objective-c++-cpp-output", IK_PreprocessedObjCXX)
>       .Case("objc++-cpp-output", IK_PreprocessedObjCXX)
>       .Case("c-header", IK_C)
>       .Case("cl-header", IK_OpenCL)
>       .Case("objective-c-header", IK_ObjC)
>       .Case("c++-header", IK_CXX)
>       .Case("objective-c++-header", IK_ObjCXX)
>       .Cases("ast", "pcm", IK_AST)
>       .Case("ir", IK_LLVM_IR)
>
> In my experiment, no argument except "assembler-with-cpp" can rescue
> "  #-}".
>
> --Kazu
>
> _______________________________________________
> 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/20131119/962353be/attachment.html>

From kazu at iij.ad.jp  Wed Nov 20 04:08:42 2013
From: kazu at iij.ad.jp (Kazu Yamamoto (=?iso-2022-jp?B?GyRCOzNLXE9CSScbKEI=?=))
Date: Wed, 20 Nov 2013 13:08:42 +0900 (JST)
Subject: Building GHC head with clang on Mavericks
In-Reply-To: <CAHYVw0xhCYY--oRtWTGnXKpPLLEOdqD_4ZxPsHN29pjhP1VrKA@mail.gmail.com>
References: <20131120.065209.105301243586485441.kazu@iij.ad.jp>
 <20131120.095507.611297567268489475.kazu@iij.ad.jp>
 <CAHYVw0xhCYY--oRtWTGnXKpPLLEOdqD_4ZxPsHN29pjhP1VrKA@mail.gmail.com>
Message-ID: <20131120.130842.1429417080648172572.kazu@iij.ad.jp>

> Was there an issue if you used a wrapped clang and those patches or not?
> I'm really confused.

Even with GHC/clang-wrapper and alex/happy with Nick's patches, I
cannot build GHC head. (I'm not using GCC 42 at all in this case.)

AlexTemplate (pre-processed by clang) has linemarkers like this:

----
# 1 "<built-in>"
----

So, Lexer.hs generated from Lexer.x by alex also includes this one. 

Lexer.hs is CPP language extension. So, it is pre-processed again by
clang. Since clang-wrapper specifies "-x assembler-with-cpp", 
generated Lexcer.hscpp contains:

----
 # 1 "<built-in>"
----

GHC cannot handle this, so build fails.

My hack lets alex and happy not to produce linemarkers at all.

Is this explanation clear to you?

P.S.

If we modify clang-wrapper to not convert "-x c" to "-x
assembler-with-cpp", some other files which contains " #-}" cannot be
compiled.

--Kazu

From carter.schonwald at gmail.com  Wed Nov 20 05:13:32 2013
From: carter.schonwald at gmail.com (Carter Schonwald)
Date: Wed, 20 Nov 2013 00:13:32 -0500
Subject: Building GHC head with clang on Mavericks
In-Reply-To: <20131120.130842.1429417080648172572.kazu@iij.ad.jp>
References: <20131120.065209.105301243586485441.kazu@iij.ad.jp>
 <20131120.095507.611297567268489475.kazu@iij.ad.jp>
 <CAHYVw0xhCYY--oRtWTGnXKpPLLEOdqD_4ZxPsHN29pjhP1VrKA@mail.gmail.com>
 <20131120.130842.1429417080648172572.kazu@iij.ad.jp>
Message-ID: <CAHYVw0zGh6Ytq_BwmjPQRa1szC+MAjNTO0zYYKy8FPfcAb1x=w@mail.gmail.com>

Ok.   Got it.  So some more patches were needed.

Pardon the asking, was somehow getting confused earlier.

On Tuesday, November 19, 2013, Kazu Yamamoto wrote:

> > Was there an issue if you used a wrapped clang and those patches or not?
> > I'm really confused.
>
> Even with GHC/clang-wrapper and alex/happy with Nick's patches, I
> cannot build GHC head. (I'm not using GCC 42 at all in this case.)
>
> AlexTemplate (pre-processed by clang) has linemarkers like this:
>
> ----
> # 1 "<built-in>"
> ----
>
> So, Lexer.hs generated from Lexer.x by alex also includes this one.
>
> Lexer.hs is CPP language extension. So, it is pre-processed again by
> clang. Since clang-wrapper specifies "-x assembler-with-cpp",
> generated Lexcer.hscpp contains:
>
> ----
>  # 1 "<built-in>"
> ----
>
> GHC cannot handle this, so build fails.
>
> My hack lets alex and happy not to produce linemarkers at all.
>
> Is this explanation clear to you?
>
> P.S.
>
> If we modify clang-wrapper to not convert "-x c" to "-x
> assembler-with-cpp", some other files which contains " #-}" cannot be
> compiled.
>
> --Kazu
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/ghc-devs/attachments/20131120/518fd2b0/attachment.html>

From kazu at iij.ad.jp  Wed Nov 20 05:25:56 2013
From: kazu at iij.ad.jp (Kazu Yamamoto (=?iso-2022-jp?B?GyRCOzNLXE9CSScbKEI=?=))
Date: Wed, 20 Nov 2013 14:25:56 +0900 (JST)
Subject: Building GHC head with clang on Mavericks
In-Reply-To: <CAHYVw0zGh6Ytq_BwmjPQRa1szC+MAjNTO0zYYKy8FPfcAb1x=w@mail.gmail.com>
References: <CAHYVw0xhCYY--oRtWTGnXKpPLLEOdqD_4ZxPsHN29pjhP1VrKA@mail.gmail.com>
 <20131120.130842.1429417080648172572.kazu@iij.ad.jp>
 <CAHYVw0zGh6Ytq_BwmjPQRa1szC+MAjNTO0zYYKy8FPfcAb1x=w@mail.gmail.com>
Message-ID: <20131120.142556.1892250232078560257.kazu@iij.ad.jp>

> Ok.   Got it.  So some more patches were needed.

Nice.

> Pardon the asking, was somehow getting confused earlier.

No problem. Maybe I explained too quickly.

--Kazu

From difrumin at gmail.com  Wed Nov 20 07:44:49 2013
From: difrumin at gmail.com (Daniil Frumin)
Date: Wed, 20 Nov 2013 11:44:49 +0400
Subject: example of great getting started guide (possible guide to improve
 it for ghc)
In-Reply-To: <201311191345.07644.jan.stolarek@p.lodz.pl>
References: <CAHYVw0yOvdnPa=KmnZabuftcLw5HtWUZrv55Q4nJGnPQBqaXzA@mail.gmail.com>
 <CACxkR4AmOf0qgUne84ZYLR6jHmnvEUsP+2SxH0hU+vMVLWR5hA@mail.gmail.com>
 <CAHYVw0xZc2Eg8uKUOSdcj-+FwgsuJ9rRcKCZhhHMA2km=A_XLw@mail.gmail.com>
 <201311191345.07644.jan.stolarek@p.lodz.pl>
Message-ID: <CACxkR4Dm6t9iijpdaNFb+nRA7WqL640A8HR2d+A2pgZ-TutuYQ@mail.gmail.com>

On Tue, Nov 19, 2013 at 4:45 PM, Jan Stolarek <jan.stolarek at p.lodz.pl>wrote:

> > relatedly: how are the 'low haning fruit" tickets on that page
> generated? I
> > can't see how
> Arbitrarily :-) Any developer can add a "low hanging fruit" ticket if he
> judges that: a) ticket is
> relatively easy for a beginner to tackle and; b) is willing to aid a
> beginner in working on that
> ticket (though this is not strictly necessary if one judges that support
> from ghc-devs will be
> sufficient). For example I added #8308 because I can guide a beginner
> through implementation of
> that ticket (at least I believe so).
>
> > I think it?d be great to reduce the barrier to entry for newcomers, and
> would welcome anything
> you (or anyone else) can do to help.  Thanks!
> Yes, reducing barrier for beginners would be a great thing to do (I
> remember how frustrating were
> my beginnings with GHC) but that would be an investment - meaning that we
> would have to put a lot
> of effort into it hoping that in the future we will have more developers.
> The best thing I could
> imagine would be videos presenting implementation of GHC. Something like
> that was already
> recorded during Hackathons but that vidoes have horrible quality and are
> almost impossible to
> watch. If we could re-record that with better quality (and more
> up-to-date) it would be great.
>
>
I agree that videos might boost the interest in GHC hacking. Maybe if Chris
Forno [1] starts hacking on GHC we will see some cool videocasts :)

[1]
http://www.youtube.com/watch?v=FEFETKhhq8w&list=PLxj9UAX4Em-IBXkvcC3MycLlcxyoi7v8B


> Janek
>
> >
> > On Tue, Nov 19, 2013 at 4:26 AM, Daniil Frumin <difrumin at gmail.com>
> wrote:
> > > I like that codefirefox.com site!
> > >
> > > GHC wiki has something similar to Mozilla's introduction page:
> > > https://ghc.haskell.org/trac/ghc/wiki/Newcomers
> > >
> > >
> > > On Tue, Nov 19, 2013 at 12:04 PM, Carter Schonwald <
> > >
> > > carter.schonwald at gmail.com> wrote:
> > >> Hey All,
> > >> I just came across the mozilla firefox "how to get involved in the
> dev"
> > >> docs
> > >> http://codefirefox.com/ and
> > >> https://news.ycombinator.com/item?id=6753583and
> > >> https://developer.mozilla.org/en-US/docs/introduction
> > >>
> > >> One thing I've been very active on lately is trying to figure out how
> to
> > >> talk more people into trying to help out with ghc.  And  the firefox
> > >> stuff there seems to lay out a great collection of examples of ways to
> > >> make it a bit easier / managable to get involved!
> > >>
> > >> figured it'd be worth sharing
> > >> -Carter
> > >>
> > >> _______________________________________________
> > >> ghc-devs mailing list
> > >> ghc-devs at haskell.org
> > >> http://www.haskell.org/mailman/listinfo/ghc-devs
> > >
> > > --
> > > Sincerely yours,
> > > -- Daniil
>
>
>


-- 
Sincerely yours,
-- Daniil
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/ghc-devs/attachments/20131120/91b4cd2b/attachment.html>

From gale at sefer.org  Wed Nov 20 10:27:23 2013
From: gale at sefer.org (Yitzchak Gale)
Date: Wed, 20 Nov 2013 12:27:23 +0200
Subject: Behaviour of readProcess, and code simplicity (or lack thereof)
In-Reply-To: <1384552786.7607.141.camel@dunky.localdomain>
References: <1384552786.7607.141.camel@dunky.localdomain>
Message-ID: <CAOrUaLbofJUhQRKPn5s-+kNNBGR9Ntxvjz_u0dcWqCSbhTPCSw@mail.gmail.com>

Whether or not we provide Duncan's proposed interface,
we need to add prominent warnings about this
to the documentation for every function that has this
issue. People need to be aware that the result of an
async exception will be a gunshot to the head.


On Fri, Nov 15, 2013 at 11:59 PM, Duncan Coutts
<duncan.coutts at googlemail.com> wrote:
> Hi possibly-interested souls,
>
> In this patch to System.Process.readProcess from last year:
>
> https://ghc.haskell.org/trac/ghc/changeset/b5ee908863882d18e4110d96b43ccc1bb5068ceb/process
>
> Bas changed things so that if an async exception is received by the
> thread calling readProcess (or readProcessWithExitCode) then the
> external process gets forcibly terminated. I do mean forcibly, it's
> TerminateProcess() on Windows and SIGKILL (not SIGTERM) on Unix.
>
> I was wondering if this is really desirable behaviour. There are
> certainly programs out there that will leave stale lock files (or worse)
> if forcibly terminated, that can shut down reasonably cleanly if asked
> more nicely.
>
> I have to say, it does make me a bit nervous.
>
> That said, terminating programs cleanly is a tricky business. While
> there is SIGTERM on Unix, there's no simple way to do it on Windows;
> there's no softer equivalent of TerminateProcess().
>
> But if we think it *is* the right behaviour then I think we ought to be
> doing it consistently. There are other System.Process functions that run
> processes synchronously that should have the same behaviour.
>
> And it turns out that cleaning up is rather subtle. Takano recently sent
> in a patch to fix a deadlock due to the order in which the cleanup
> happens:
>
> https://ghc.haskell.org/trac/ghc/changeset/32223a9ab174c22e939c81e24b6f48223c7cb020/process
>
> So if it is desirable behaviour and is so subtle we ought to provide the
> users with some help to do it (or indeed to do alternatives if we think
> no one policy fits all).
>
> For example, we could provide:
>
> -- | A 'bracketOnError'-style resource handler for 'createProcess'.
> --
> -- In normal operation it adds nothing, you are still responsible for
> -- waiting for (or forcing) process termination and closing any
> -- 'Handle's. It only does automatic cleanup if there is an exception.
> -- If there is an exception in the body then it ensures that the process
> -- gets terminated and any 'CreatePipe' 'Handle's are closed. In
> -- particular this means that if the Haskell thread is killed (e.g.
> -- 'killThread'), that the external process is also terminated.
> --
> withCreateProcess
>   :: CreateProcess
>   -> (Maybe Handle -> Maybe Handle -> Maybe Handle
>                    -> ProcessHandle -> IO a)
>   -> IO a
> withCreateProcess c action =
>     bracketOnError
>       (createProcess c) cleanupProcess
>       (\(m_in, m_out, m_err, ph) -> action m_in m_out m_err ph)
>
> cleanupProcess
>   :: (Maybe Handle, Maybe Handle, Maybe Handle, ProcessHandle)
>   -> IO ExitCode
> cleanupProcess (mb_stdin, mb_stdout, mb_stderr, ph) = do
>   -- We rely on the fact that terminateProcess really does terminate it
>   -- and not just ask it nicely. Otherwise we could deadlock if there
>   -- are other threads holding the lock on the stdin/out/err Handles.
>   terminateProcess ph
>   maybe (return ()) hClose mb_stdin
>   maybe (return ()) hClose mb_stdout
>   maybe (return ()) hClose mb_stderr
>   waitForProcess ph
>
> As it is, the docs say:
>
>         'readProcess' and 'readProcessWithExitCode' are fairly simple
>         wrappers around 'createProcess'.  Constructing variants of these
>         functions is quite easy: follow the link to the source code to
>         see how 'readProcess' is implemented.
>
> but if you do look at the source you see that while it may originally
> have been true, it certainly is not anymore! Providing and using a
> withCreateProcess-style would help quite a bit.
>
> Also, the ignoring EPIPE stuff is rather unsatisfactory and
> non-portable. It's not used consistently and it's impossible for anyone
> else to implement it themselves without using GHC internals. It's almost
> possible in a nice way, since you could check if it's ResourceVanished
> rather than errno = EPIPE, but actually ResourceVanished is not exposed
> via System.IO.Error either.
>
> I think it's worth if at all possible making it true that people can
> write useful and reliable special cases of createProcess, but we'd need
> to provide more help.
>
>
> _______________________________________________
> ghc-devs mailing list
> ghc-devs at haskell.org
> http://www.haskell.org/mailman/listinfo/ghc-devs

From kazu at iij.ad.jp  Wed Nov 20 13:40:27 2013
From: kazu at iij.ad.jp (Kazu Yamamoto (=?iso-2022-jp?B?GyRCOzNLXE9CSScbKEI=?=))
Date: Wed, 20 Nov 2013 22:40:27 +0900 (JST)
Subject: clang/wrapper cannot build GHC head with integer-gmp on Mavericks
Message-ID: <20131120.224027.686636728689837336.kazu@iij.ad.jp>

Hi,

I'm try to make GHC head stably buildable with clang/wrapper on
Mavericks because we cannot ask all Mavericks users to install
apple-gcc or GCC.

The last big item for me is integer-gmp. GHC head cannot be built with
clang/wrapper if integer-gmp is used. (integer-simple is OK.)

This is because "configure" of libgmp fails. Now I understand why this
happens. The source of this problem is "/usr/bin/gcc" which is a
wrapper for clang (not gcc actually). This cheats "configure" of libgmp.

If we type "CC=clang ./configure", it works. The problem is how to
specify "CC=clang" to configure of libgmp when we build GHC head.  If
we modified "libraries/integer-gmp/gmp/ghc.mk" manually, we can build
GHC head. But I don't like this one since "make maintainer-clean"
removes "ghc.mk".

Any ideas?

Ticket is here:

	https://ghc.haskell.org/trac/ghc/ticket/8497

--Kazu

From hvr at gnu.org  Wed Nov 20 14:06:30 2013
From: hvr at gnu.org (Herbert Valerio Riedel)
Date: Wed, 20 Nov 2013 15:06:30 +0100
Subject: clang/wrapper cannot build GHC head with integer-gmp on Mavericks
In-Reply-To: <20131120.224027.686636728689837336.kazu@iij.ad.jp> ("Kazu
 Yamamoto \=\?utf-8\?B\?KOWxseacrOWSjOW9pikiJ3M\=\?\= message of "Wed,
 20 Nov 2013 22:40:27 +0900 (JST)")
References: <20131120.224027.686636728689837336.kazu@iij.ad.jp>
Message-ID: <8761rnkw0p.fsf@gnu.org>

On 2013-11-20 at 14:40:27 +0100, Kazu Yamamoto (????) wrote:

[...]

> If we type "CC=clang ./configure", it works. The problem is how to
> specify "CC=clang" to configure of libgmp when we build GHC head.  If
> we modified "libraries/integer-gmp/gmp/ghc.mk" manually, we can build
> GHC head. But I don't like this one since "make maintainer-clean"
> removes "ghc.mk".

are you sure gmp/ghc.mk is removed? After all, it's a file checked into Git:

 http://git.haskell.org/packages/integer-gmp.git/blob/HEAD:/gmp/ghc.mk

From kazu at iij.ad.jp  Wed Nov 20 14:15:04 2013
From: kazu at iij.ad.jp (Kazu Yamamoto (=?iso-2022-jp?B?GyRCOzNLXE9CSScbKEI=?=))
Date: Wed, 20 Nov 2013 23:15:04 +0900 (JST)
Subject: clang/wrapper cannot build GHC head with integer-gmp on Mavericks
In-Reply-To: <8761rnkw0p.fsf@gnu.org>
References: <20131120.224027.686636728689837336.kazu@iij.ad.jp>
 <8761rnkw0p.fsf@gnu.org>
Message-ID: <20131120.231504.507777664653856321.kazu@iij.ad.jp>

> are you sure gmp/ghc.mk is removed? After all, it's a file checked into Git:

Oh. Probably I was confused.

So, should we introduce a hack for Mavericks to gmp/ghc.mk?

--Kazu

From simonpj at microsoft.com  Wed Nov 20 21:11:10 2013
From: simonpj at microsoft.com (Simon Peyton-Jones)
Date: Wed, 20 Nov 2013 21:11:10 +0000
Subject: Too many symbols
Message-ID: <59543203684B2244980D7E4057D5FBC1486A8F9D@DB3EX14MBXC306.europe.corp.microsoft.com>

Friends
I'm getting the dreaded "Too many symbols in DLL" problem on Windows (see below).
I believe I can get round it by using static linking only, yes?  But how do I do that?  I have

DYNAMIC_BY_DEFAULT   = NO

DYNAMIC_GHC_PROGRAMS = NO
in my validate.mk, but it still happens.  Static only will do me fine!
Thanks!
Simon


Number of symbols in compiler/stage2/build/libHSghc-7.7.20131119-0-ghc7.7.20131119.dll: 69595

case `C:/code/HEAD/inplace/mingw/bin/objdump.exe -p compiler/stage2/build/libHSghc-7.7.20131119-0-ghc7.7.20131119.dll | sed -n "1,/^.Ordinal\/Name Pointer/ D; p; /^$/ q" | grep "\[ *0\]" | wc -l` in 1) echo DLL compiler/stage2/build/libHSghc-7.7.20131119-0-ghc7.7.20131119.dll OK;; 0) echo No symbols in DLL compiler/stage2/build/libHSghc-7.7.20131119-0-ghc7.7.20131119.dll; exit 1;; [0-9]*) echo Too many symbols in DLL compiler/stage2/build/libHSghc-7.7.20131119-0-ghc7.7.20131119.dll; C:/code/HEAD/inplace/mingw/bin/objdump.exe -p compiler/stage2/build/libHSghc-7.7.20131119-0-ghc7.7.20131119.dll | sed -n "1,/^.Ordinal\/Name Pointer/ D; p; /^$/ q" | tail; exit 1;; *) echo bad DLL compiler/stage2/build/libHSghc-7.7.20131119-0-ghc7.7.20131119.dll; exit 1;; esac

Too many symbols in DLL compiler/stage2/build/libHSghc-7.7.20131119-0-ghc7.7.20131119.dll

     [4050] ghczm7zi7zi20131119_Var_zdfUniquableVar_closure

     [4051] ghczm7zi7zi20131119_Var_zdfUniquableVar_info

     [4052] ghczm7zi7zi20131119_Var_zdwsetVarUnique_closure

     [4053] ghczm7zi7zi20131119_Var_zdwsetVarUnique_info

     [4054] ghczm7zi7zi20131119_Var_zdwupdateTyVarKindM_closure

     [4055] ghczm7zi7zi20131119_Var_zdwupdateTyVarKindM_info

     [4056] ghczm7zi7zi20131119_Var_zdwzdcgmapMp_closure

     [4057] ghczm7zi7zi20131119_Var_zdwzdcgmapMp_info

     [4058] setHeapSize



compiler/ghc.mk:472: recipe for target 'compiler/stage2/build/libHSghc-7.7.20131119-0-ghc7.7.20131119.dll' failed

make[1]: *** [compiler/stage2/build/libHSghc-7.7.20131119-0-ghc7.7.20131119.dll] Error 1

make[1]: *** Deleting file 'compiler/stage2/build/libHSghc-7.7.20131119-0-ghc7.7.20131119.dll'

Makefile:64: recipe for target 'all' failed

make: *** [all] Error 2
HEAD $
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/ghc-devs/attachments/20131120/b4bceb21/attachment.html>

From kazu at iij.ad.jp  Thu Nov 21 04:38:21 2013
From: kazu at iij.ad.jp (Kazu Yamamoto (=?iso-2022-jp?B?GyRCOzNLXE9CSScbKEI=?=))
Date: Thu, 21 Nov 2013 13:38:21 +0900 (JST)
Subject: clang/wrapper cannot build GHC head with integer-gmp on Mavericks
In-Reply-To: <20131120.231504.507777664653856321.kazu@iij.ad.jp>
References: <20131120.224027.686636728689837336.kazu@iij.ad.jp>
 <8761rnkw0p.fsf@gnu.org>
 <20131120.231504.507777664653856321.kazu@iij.ad.jp>
Message-ID: <20131121.133821.744862007800485768.kazu@iij.ad.jp>

Hi,

> Oh. Probably I was confused.
> 
> So, should we introduce a hack for Mavericks to gmp/ghc.mk?

OK. I created a patch:

	https://ghc.haskell.org/trac/ghc/ticket/8497#comment:8

With this patch, I can build GHC head/integer-gmp with GHC
7.6.3/clang-wrapper on Mavericks/XCode 5. (Note that patched alex and
happy are also necessary.)

--Kazu

From nkpart at gmail.com  Thu Nov 21 05:12:21 2013
From: nkpart at gmail.com (Nick Partridge)
Date: Thu, 21 Nov 2013 15:12:21 +1000
Subject: Building GHC head with clang on Mavericks
In-Reply-To: <20131120.142556.1892250232078560257.kazu@iij.ad.jp>
References: <CAHYVw0xhCYY--oRtWTGnXKpPLLEOdqD_4ZxPsHN29pjhP1VrKA@mail.gmail.com>
 <20131120.130842.1429417080648172572.kazu@iij.ad.jp>
 <CAHYVw0zGh6Ytq_BwmjPQRa1szC+MAjNTO0zYYKy8FPfcAb1x=w@mail.gmail.com>
 <20131120.142556.1892250232078560257.kazu@iij.ad.jp>
Message-ID: <CAFXb89BMkFJY8xfms8Laz_cE5yEvMATbZj6gDMFajdFC9mybJQ@mail.gmail.com>

I think these are difficult problems to talk about, because there are so
many different versions of things flying about. But if I can sum up what I
think has gone on here, I want to make sure we know what needs to happen
next:

* Kazu has verified that my patches to happy/alex allow us to build HEAD
using GHC 7.6 + GCC 4.8.

* There are separate patches needed for happy/alex to allow building of
HEAD using GHC 7.6 + Clang (and as I see in the other thread, also a patch
for ghc.mk)

Kazu, can you put create pull requests for happy and alex with your
required changes?

If those changes play nice, hopefully we can then ship new versions of
happy and alex for mac users shortly.

- Nick





On Wed, Nov 20, 2013 at 3:25 PM, Kazu Yamamoto <kazu at iij.ad.jp> wrote:

> > Ok.   Got it.  So some more patches were needed.
>
> Nice.
>
> > Pardon the asking, was somehow getting confused earlier.
>
> No problem. Maybe I explained too quickly.
>
> --Kazu
> _______________________________________________
> 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/20131121/3a7ae19a/attachment.html>

From kazu at iij.ad.jp  Thu Nov 21 05:25:56 2013
From: kazu at iij.ad.jp (Kazu Yamamoto (=?iso-2022-jp?B?GyRCOzNLXE9CSScbKEI=?=))
Date: Thu, 21 Nov 2013 14:25:56 +0900 (JST)
Subject: Building GHC head with clang on Mavericks
In-Reply-To: <CAFXb89BMkFJY8xfms8Laz_cE5yEvMATbZj6gDMFajdFC9mybJQ@mail.gmail.com>
References: <CAHYVw0zGh6Ytq_BwmjPQRa1szC+MAjNTO0zYYKy8FPfcAb1x=w@mail.gmail.com>
 <20131120.142556.1892250232078560257.kazu@iij.ad.jp>
 <CAFXb89BMkFJY8xfms8Laz_cE5yEvMATbZj6gDMFajdFC9mybJQ@mail.gmail.com>
Message-ID: <20131121.142556.471882438928640756.kazu@iij.ad.jp>

Hi,

> Kazu, can you put create pull requests for happy and alex with your
> required changes?

I have one concern.

The version of alex on Hackage is 3.1.2. But that of github is
3.1.1:

	https://github.com/simonmar/alex/blob/master/alex.cabal

# This inconsistency exists in happy, too.

Did SimonM forget to push his local changes?

Should I send pull requests on github, anyway?

--Kazu

From nkpart at gmail.com  Thu Nov 21 05:38:42 2013
From: nkpart at gmail.com (Nick Partridge)
Date: Thu, 21 Nov 2013 15:38:42 +1000
Subject: Building GHC head with clang on Mavericks
In-Reply-To: <20131121.142556.471882438928640756.kazu@iij.ad.jp>
References: <CAHYVw0zGh6Ytq_BwmjPQRa1szC+MAjNTO0zYYKy8FPfcAb1x=w@mail.gmail.com>
 <20131120.142556.1892250232078560257.kazu@iij.ad.jp>
 <CAFXb89BMkFJY8xfms8Laz_cE5yEvMATbZj6gDMFajdFC9mybJQ@mail.gmail.com>
 <20131121.142556.471882438928640756.kazu@iij.ad.jp>
Message-ID: <CAFXb89CCv4GKhJQR5WRh6UTdgRXcvvoSowH03HCa9s4DeQ3C-g@mail.gmail.com>

I think he has forgotten, yes. But yeah do send the pull requests anyway,
my last set got merged in. The missing code seems to just be the version
bump and a new test case:
http://hdiff.luite.com/cgit/alex/commit/?id=f0f1f332d56b3fd21930d771b15b7c0d92ffbe7b



On Thu, Nov 21, 2013 at 3:25 PM, Kazu Yamamoto <kazu at iij.ad.jp> wrote:

> Hi,
>
> > Kazu, can you put create pull requests for happy and alex with your
> > required changes?
>
> I have one concern.
>
> The version of alex on Hackage is 3.1.2. But that of github is
> 3.1.1:
>
>         https://github.com/simonmar/alex/blob/master/alex.cabal
>
> # This inconsistency exists in happy, too.
>
> Did SimonM forget to push his local changes?
>
> Should I send pull requests on github, anyway?
>
> --Kazu
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/ghc-devs/attachments/20131121/d2a10897/attachment-0001.html>

From kazu at iij.ad.jp  Thu Nov 21 06:54:30 2013
From: kazu at iij.ad.jp (Kazu Yamamoto (=?iso-2022-jp?B?GyRCOzNLXE9CSScbKEI=?=))
Date: Thu, 21 Nov 2013 15:54:30 +0900 (JST)
Subject: Building GHC head with clang on Mavericks
In-Reply-To: <CAFXb89CCv4GKhJQR5WRh6UTdgRXcvvoSowH03HCa9s4DeQ3C-g@mail.gmail.com>
References: <CAFXb89BMkFJY8xfms8Laz_cE5yEvMATbZj6gDMFajdFC9mybJQ@mail.gmail.com>
 <20131121.142556.471882438928640756.kazu@iij.ad.jp>
 <CAFXb89CCv4GKhJQR5WRh6UTdgRXcvvoSowH03HCa9s4DeQ3C-g@mail.gmail.com>
Message-ID: <20131121.155430.37558810975251514.kazu@iij.ad.jp>

> I think he has forgotten, yes. But yeah do send the pull requests anyway,
> my last set got merged in. 

Done:
	https://github.com/simonmar/happy/pull/13
	https://github.com/simonmar/alex/pull/38

--Kazu

From tkn.akio at gmail.com  Thu Nov 21 08:52:58 2013
From: tkn.akio at gmail.com (Akio Takano)
Date: Thu, 21 Nov 2013 17:52:58 +0900
Subject: Behaviour of readProcess, and code simplicity (or lack thereof)
In-Reply-To: <1384552786.7607.141.camel@dunky.localdomain>
References: <1384552786.7607.141.camel@dunky.localdomain>
Message-ID: <CAOGQyFsOfGQM2VQr4y9bjZ6BeFVLazmR4CUR4km17rXcqApJ2Q@mail.gmail.com>

Hi,


On Sat, Nov 16, 2013 at 6:59 AM, Duncan Coutts <duncan.coutts at googlemail.com
> wrote:

> Hi possibly-interested souls,
>
> In this patch to System.Process.readProcess from last year:
>
>
> https://ghc.haskell.org/trac/ghc/changeset/b5ee908863882d18e4110d96b43ccc1bb5068ceb/process
>
> Bas changed things so that if an async exception is received by the
> thread calling readProcess (or readProcessWithExitCode) then the
> external process gets forcibly terminated. I do mean forcibly, it's
> TerminateProcess() on Windows and SIGKILL (not SIGTERM) on Unix.
>

The documentation says 'terminateProcess sends the process the SIGTERM
signal'. Also it seems to agree with the implementation
(cbits/runProcess.c:321).

Takano Akio
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/ghc-devs/attachments/20131121/9b826443/attachment.html>

From marlowsd at gmail.com  Thu Nov 21 10:31:58 2013
From: marlowsd at gmail.com (Simon Marlow)
Date: Thu, 21 Nov 2013 10:31:58 +0000
Subject: Building GHC head with clang on Mavericks
In-Reply-To: <20131121.155430.37558810975251514.kazu@iij.ad.jp>
References: <CAFXb89BMkFJY8xfms8Laz_cE5yEvMATbZj6gDMFajdFC9mybJQ@mail.gmail.com>
 <20131121.142556.471882438928640756.kazu@iij.ad.jp>
 <CAFXb89CCv4GKhJQR5WRh6UTdgRXcvvoSowH03HCa9s4DeQ3C-g@mail.gmail.com>
 <20131121.155430.37558810975251514.kazu@iij.ad.jp>
Message-ID: <528DE11E.2010305@gmail.com>

On 21/11/13 06:54, Kazu Yamamoto (????) wrote:
>> I think he has forgotten, yes. But yeah do send the pull requests anyway,
>> my last set got merged in.
>
> Done:
> 	https://github.com/simonmar/happy/pull/13
> 	https://github.com/simonmar/alex/pull/38

Sorry, I closed your pull requests without seeing this discussion.

But I'm not sure about this fix.  I'm happy to merge in fixes for Mac in 
general, but in this case we seem to lose the line pragmas, which are 
actually useful (error messages will point to the original source, 
instead of some preprocessed file).

Cheers,
Simon


From rarash at student.chalmers.se  Thu Nov 21 10:38:38 2013
From: rarash at student.chalmers.se (Arash Rouhani)
Date: Thu, 21 Nov 2013 11:38:38 +0100
Subject: [PATCH] Fix typo in User's Guide
In-Reply-To: <59543203684B2244980D7E4057D5FBC14866B38D@DB3EX14MBXC308.europe.corp.microsoft.com>
References: <1383650828-26219-1-git-send-email-pedro@onimail.net>
 <CAHYVw0z3g4f_S4eHXYJmFjUM5wZV=5ucY+YasKub2UyRW7xDQA@mail.gmail.com>
 <CADtVS2pkWvMCg7VtuRwXqgAyuDzgSbcqune7vH3n59kxq-gTpQ@mail.gmail.com>
 <59543203684B2244980D7E4057D5FBC14866B38D@DB3EX14MBXC308.europe.corp.microsoft.com>
Message-ID: <528DE2AE.9090505@student.chalmers.se>

Hello Simon,

If you look at this wikipage [1], it still says we can contribute using 
the `git send-email` to ghc-devs. Now I know you like for people to 
create tickets for bug fixes. But what about really tiny documentation 
patches? The WorkingConventions [2] page only mentions how to submit 
bugfixes and new feature patches.

So should I still use the instructions at [1] or is there some 
information missing in the wiki? Or should I really create a ticket for 
tiny patches?

[1]: 
https://ghc.haskell.org/trac/ghc/wiki/WorkingConventions/Git#Contributingpatches
[2]: https://ghc.haskell.org/trac/ghc/wiki/WorkingConventions


Best Regards,
Arash

On 2013-11-05 23:04, Simon Peyton-Jones wrote:
>
> Thanks. the instructions are really out of date.  Now that so many of 
> us work on GHC, it's too easy for an email to get lost. Trac is 
> better.  I'll update the instructions!
>
> S
>
> *From:*ghc-devs [mailto:ghc-devs-bounces at haskell.org] *On Behalf Of 
> *Pedro Rodrigues
> *Sent:* 05 November 2013 21:47
> *To:* Carter Schonwald
> *Cc:* ghc-devs at haskell.org
> *Subject:* Re: [PATCH] Fix typo in User's Guide
>
> Sure, here it is http://ghc.haskell.org/trac/ghc/ticket/8505
>
> Should every bug fix have an associated ticket? Because from the 
> instructions on Trac 
> <http://ghc.haskell.org/trac/ghc/wiki/WorkingConventions/FixingBugs>, 
> I got the impression that for quick fixes it was not necessary to 
> create a ticket.
>
> Cheers,
>
> Pedro Rodrigues
>
> On 5 November 2013 18:56, Carter Schonwald <carter.schonwald at gmail.com 
> <mailto:carter.schonwald at gmail.com>> wrote:
>
>     could you file a ticket on trac with the patch?
>
>     On Tue, Nov 5, 2013 at 6:27 AM, Pedro Rodrigues <pedro at onimail.net
>     <mailto:pedro at onimail.net>> wrote:
>
>         ---
>          docs/users_guide/glasgow_exts.xml |    2 +-
>          1 files changed, 1 insertions(+), 1 deletions(-)
>
>         diff --git a/docs/users_guide/glasgow_exts.xml
>         b/docs/users_guide/glasgow_exts.xml
>         index ce07806..d61ff7a 100644
>         --- a/docs/users_guide/glasgow_exts.xml
>         +++ b/docs/users_guide/glasgow_exts.xml
>         @@ -8673,7 +8673,7 @@ proc (x,y) ->
>          which is translated to
>          <screen>
>          arr (\ (x,y) -> if f x y then Left x else Right y) >>>
>         -        (arr (\x -> x+1) >>> f) ||| (arr (\y -> y+2) >>> g)
>         +        (arr (\x -> x+1) >>> g) ||| (arr (\y -> y+2) >>> h)
>          </screen>
>          Since the translation uses <function>|||</function>,
>          the arrow concerned must belong to the
>         <literal>ArrowChoice</literal> class.
>         --
>         1.7.4.1
>
>         _______________________________________________
>         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

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

From marlowsd at gmail.com  Thu Nov 21 10:49:35 2013
From: marlowsd at gmail.com (Simon Marlow)
Date: Thu, 21 Nov 2013 10:49:35 +0000
Subject: [commit: testsuite] master: Much better perf on 5030, higher
 peak on 3064 (53b3199)
In-Reply-To: <20131112150751.A29F32406B@ghc.haskell.org>
References: <20131112150751.A29F32406B@ghc.haskell.org>
Message-ID: <528DE53F.7060901@gmail.com>

On 12/11/13 15:07, git at git.haskell.org wrote:
> Repository : ssh://git at git.haskell.org/testsuite
>
> On branch  : master
> Link       : http://ghc.haskell.org/trac/ghc/changeset/53b3199b03bd2e52c63babffd33d478242ae74d5/testsuite
>
>> ---------------------------------------------------------------
>
> commit 53b3199b03bd2e52c63babffd33d478242ae74d5
> Author: Simon Peyton Jones <simonpj at microsoft.com>
> Date:   Tue Nov 12 15:06:56 2013 +0000
>
>      Much better perf on 5030, higher peak on 3064
>
>      The peak-megabytes is vulnerable to when GC runs

Juat a reminder to everyone: when peak_megabytes or max_bytes_used 
changes, please run with +RTS -h -i0.01 to get a heap profile and check 
whether it's a real change or not.  You don't need to compile for 
profiling or anything.

Cheers,
Simon


From simonpj at microsoft.com  Thu Nov 21 11:50:08 2013
From: simonpj at microsoft.com (Simon Peyton-Jones)
Date: Thu, 21 Nov 2013 11:50:08 +0000
Subject: [PATCH] Fix typo in User's Guide
In-Reply-To: <528DE2AE.9090505@student.chalmers.se>
References: <1383650828-26219-1-git-send-email-pedro@onimail.net>
 <CAHYVw0z3g4f_S4eHXYJmFjUM5wZV=5ucY+YasKub2UyRW7xDQA@mail.gmail.com>
 <CADtVS2pkWvMCg7VtuRwXqgAyuDzgSbcqune7vH3n59kxq-gTpQ@mail.gmail.com>
 <59543203684B2244980D7E4057D5FBC14866B38D@DB3EX14MBXC308.europe.corp.microsoft.com>
 <528DE2AE.9090505@student.chalmers.se>
Message-ID: <59543203684B2244980D7E4057D5FBC1486A9F0D@DB3EX14MBXC306.europe.corp.microsoft.com>

Personally I think that even tiny patches should turn into tickets, and we should update the wiki to say so.   For non-committers, there is too much danger that the patch simply gets lost if it's not in a ticket with "patch" status.

People with commit rights can simply commit the tiny patch, so the issue doesn't arise.  And if you are in a dialogue with a committer you can send the patches that they are going to commit.  But for otherwise-unconnected patches, make a ticket.

Does everyone agree? If so does anyone feel able to update the wiki pages to say this?

Simon

From: ghc-devs [mailto:ghc-devs-bounces at haskell.org] On Behalf Of Arash Rouhani
Sent: 21 November 2013 10:39
To: ghc-devs at haskell.org
Subject: Re: [PATCH] Fix typo in User's Guide

Hello Simon,

If you look at this wikipage [1], it still says we can contribute using the `git send-email` to ghc-devs. Now I know you like for people to create tickets for bug fixes. But what about really tiny documentation patches? The WorkingConventions [2] page only mentions how to submit bugfixes and new feature patches.

So should I still use the instructions at [1] or is there some information missing in the wiki? Or should I really create a ticket for tiny patches?

[1]: https://ghc.haskell.org/trac/ghc/wiki/WorkingConventions/Git#Contributingpatches
[2]: https://ghc.haskell.org/trac/ghc/wiki/WorkingConventions


Best Regards,
Arash
On 2013-11-05 23:04, Simon Peyton-Jones wrote:
Thanks.  the instructions are really out of date.  Now that so many of us work on GHC, it's too easy for an email to get lost. Trac is better.  I'll update the instructions!

S

From: ghc-devs [mailto:ghc-devs-bounces at haskell.org] On Behalf Of Pedro Rodrigues
Sent: 05 November 2013 21:47
To: Carter Schonwald
Cc: ghc-devs at haskell.org<mailto:ghc-devs at haskell.org>
Subject: Re: [PATCH] Fix typo in User's Guide

Sure, here it is http://ghc.haskell.org/trac/ghc/ticket/8505

Should every bug fix have an associated ticket? Because from the instructions on Trac<http://ghc.haskell.org/trac/ghc/wiki/WorkingConventions/FixingBugs>, I got the impression that for quick fixes it was not necessary to create a ticket.

Cheers,
Pedro Rodrigues

On 5 November 2013 18:56, Carter Schonwald <carter.schonwald at gmail.com<mailto:carter.schonwald at gmail.com>> wrote:
could you file a ticket on trac with the patch?

On Tue, Nov 5, 2013 at 6:27 AM, Pedro Rodrigues <pedro at onimail.net<mailto:pedro at onimail.net>> wrote:
---
 docs/users_guide/glasgow_exts.xml |    2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)

diff --git a/docs/users_guide/glasgow_exts.xml b/docs/users_guide/glasgow_exts.xml
index ce07806..d61ff7a 100644
--- a/docs/users_guide/glasgow_exts.xml
+++ b/docs/users_guide/glasgow_exts.xml
@@ -8673,7 +8673,7 @@ proc (x,y) ->
 which is translated to
 <screen>
 arr (\ (x,y) -> if f x y then Left x else Right y) >>>
-        (arr (\x -> x+1) >>> f) ||| (arr (\y -> y+2) >>> g)
+        (arr (\x -> x+1) >>> g) ||| (arr (\y -> y+2) >>> h)
 </screen>
 Since the translation uses <function>|||</function>,
 the arrow concerned must belong to the <literal>ArrowChoice</literal> class.
--
1.7.4.1

_______________________________________________
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<mailto: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/20131121/975618a5/attachment.html>

From simonpj at microsoft.com  Thu Nov 21 11:55:30 2013
From: simonpj at microsoft.com (Simon Peyton-Jones)
Date: Thu, 21 Nov 2013 11:55:30 +0000
Subject: [commit: testsuite] master: Much better perf on 5030, higher
 peak on 3064 (53b3199)
In-Reply-To: <528DE53F.7060901@gmail.com>
References: <20131112150751.A29F32406B@ghc.haskell.org>
 <528DE53F.7060901@gmail.com>
Message-ID: <59543203684B2244980D7E4057D5FBC1486A9F7F@DB3EX14MBXC306.europe.corp.microsoft.com>

Aha.  I've updated
https://ghc.haskell.org/trac/ghc/wiki/Building/RunningTests/Updating

Simon

| -----Original Message-----
| From: ghc-devs [mailto:ghc-devs-bounces at haskell.org] On Behalf Of Simon
| Marlow
| Sent: 21 November 2013 10:50
| To: ghc-devs at haskell.org
| Subject: Re: [commit: testsuite] master: Much better perf on 5030,
| higher peak on 3064 (53b3199)
| 
| On 12/11/13 15:07, git at git.haskell.org wrote:
| > Repository : ssh://git at git.haskell.org/testsuite
| >
| > On branch  : master
| > Link       :
| http://ghc.haskell.org/trac/ghc/changeset/53b3199b03bd2e52c63babffd33d47
| 8242ae74d5/testsuite
| >
| >> ---------------------------------------------------------------
| >
| > commit 53b3199b03bd2e52c63babffd33d478242ae74d5
| > Author: Simon Peyton Jones <simonpj at microsoft.com>
| > Date:   Tue Nov 12 15:06:56 2013 +0000
| >
| >      Much better perf on 5030, higher peak on 3064
| >
| >      The peak-megabytes is vulnerable to when GC runs
| 
| Juat a reminder to everyone: when peak_megabytes or max_bytes_used
| changes, please run with +RTS -h -i0.01 to get a heap profile and check
| whether it's a real change or not.  You don't need to compile for
| profiling or anything.
| 
| Cheers,
| Simon
| 
| _______________________________________________
| ghc-devs mailing list
| ghc-devs at haskell.org
| http://www.haskell.org/mailman/listinfo/ghc-devs

From mail at joachim-breitner.de  Thu Nov 21 11:57:19 2013
From: mail at joachim-breitner.de (Joachim Breitner)
Date: Thu, 21 Nov 2013 11:57:19 +0000
Subject: [PATCH] Fix typo in User's Guide
In-Reply-To: <59543203684B2244980D7E4057D5FBC1486A9F0D@DB3EX14MBXC306.europe.corp.microsoft.com>
References: <1383650828-26219-1-git-send-email-pedro@onimail.net>
 <CAHYVw0z3g4f_S4eHXYJmFjUM5wZV=5ucY+YasKub2UyRW7xDQA@mail.gmail.com>
 <CADtVS2pkWvMCg7VtuRwXqgAyuDzgSbcqune7vH3n59kxq-gTpQ@mail.gmail.com>
 <59543203684B2244980D7E4057D5FBC14866B38D@DB3EX14MBXC308.europe.corp.microsoft.com>
 <528DE2AE.9090505@student.chalmers.se>
 <59543203684B2244980D7E4057D5FBC1486A9F0D@DB3EX14MBXC306.europe.corp.microsoft.com>
Message-ID: <1385035039.10089.10.camel@kirk>

Hi,

Am Donnerstag, den 21.11.2013, 11:50 +0000 schrieb Simon Peyton-Jones:
> Personally I think that even tiny patches should turn into tickets,
> and we should update the wiki to say so.   For non-committers, there
> is too much danger that the patch simply gets lost if it?s not in a
> ticket with ?patch? status.   
> 
> People with commit rights can simply commit the tiny patch, so the
> issue doesn?t arise.  And if you are in a dialogue with a committer
> you can send the patches that they are going to commit.  But for
> otherwise-unconnected patches, make a ticket.

I would phrase it this way (or similar):

?Tiny patches do not require a ticket, so if you can commit it yourself,
or get a committer to do it right away, go ahead. Otherwise, please open
a ticket so that your contribution is not lost.?

(This sounds less like strict rules and more like ?we care about your
contributions, please help us not lose them?.)

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: 198 bytes
Desc: This is a digitally signed message part
URL: <http://www.haskell.org/pipermail/ghc-devs/attachments/20131121/005f0b46/attachment.sig>

From kyrab at mail.ru  Thu Nov 21 12:12:10 2013
From: kyrab at mail.ru (kyra)
Date: Thu, 21 Nov 2013 16:12:10 +0400
Subject: Too many symbols
In-Reply-To: <59543203684B2244980D7E4057D5FBC1486A8F9D@DB3EX14MBXC306.europe.corp.microsoft.com>
References: <59543203684B2244980D7E4057D5FBC1486A8F9D@DB3EX14MBXC306.europe.corp.microsoft.com>
Message-ID: <528DF89A.9000501@mail.ru>

I had a similar problem until I removed these lines:

ifeq "$(PlatformSupportsSharedLibs)" "YES"
GhcLibWays += dyn
endif

from my build.mk.

On 11/21/2013 01:11, Simon Peyton-Jones wrote:
>
> Friends
>
> I'm getting the dreaded "Too many symbols in DLL" problem on Windows 
> (see below).
>
> I believe I can get round it by using static linking only, yes?  But 
> how do I do that?  I have
>
> DYNAMIC_BY_DEFAULT   = NO
>
> DYNAMIC_GHC_PROGRAMS = NO
>
> in my validate.mk, but it still happens. Static only will do me fine!
>
> Thanks!
>
> Simon
>
> Number of symbols in 
> compiler/stage2/build/libHSghc-7.7.20131119-0-ghc7.7.20131119.dll: 69595
>
> case `C:/code/HEAD/inplace/mingw/bin/objdump.exe -p 
> compiler/stage2/build/libHSghc-7.7.20131119-0-ghc7.7.20131119.dll | 
> sed -n "1,/^.Ordinal\/Name Pointer/ D; p; /^$/ q" | grep "\[ *0\]" | 
> wc -l` in 1) echo DLL 
> compiler/stage2/build/libHSghc-7.7.20131119-0-ghc7.7.20131119.dll OK;; 
> 0) echo No symbols in DLL 
> compiler/stage2/build/libHSghc-7.7.20131119-0-ghc7.7.20131119.dll; 
> exit 1;; [0-9]*) echo Too many symbols in DLL 
> compiler/stage2/build/libHSghc-7.7.20131119-0-ghc7.7.20131119.dll; 
> C:/code/HEAD/inplace/mingw/bin/objdump.exe -p 
> compiler/stage2/build/libHSghc-7.7.20131119-0-ghc7.7.20131119.dll | 
> sed -n "1,/^.Ordinal\/Name Pointer/ D; p; /^$/ q" | tail; exit 1;; *) 
> echo bad DLL 
> compiler/stage2/build/libHSghc-7.7.20131119-0-ghc7.7.20131119.dll; 
> exit 1;; esac
>
> Too many symbols in DLL 
> compiler/stage2/build/libHSghc-7.7.20131119-0-ghc7.7.20131119.dll
>
>      [4050] ghczm7zi7zi20131119_Var_zdfUniquableVar_closure
>
>      [4051] ghczm7zi7zi20131119_Var_zdfUniquableVar_info
>
>      [4052] ghczm7zi7zi20131119_Var_zdwsetVarUnique_closure
>
>      [4053] ghczm7zi7zi20131119_Var_zdwsetVarUnique_info
>
>      [4054] ghczm7zi7zi20131119_Var_zdwupdateTyVarKindM_closure
>
>      [4055] ghczm7zi7zi20131119_Var_zdwupdateTyVarKindM_info
>
>      [4056] ghczm7zi7zi20131119_Var_zdwzdcgmapMp_closure
>
>      [4057] ghczm7zi7zi20131119_Var_zdwzdcgmapMp_info
>
>      [4058] setHeapSize
>
> compiler/ghc.mk:472: recipe for target 
> 'compiler/stage2/build/libHSghc-7.7.20131119-0-ghc7.7.20131119.dll' failed
>
> make[1]: *** 
> [compiler/stage2/build/libHSghc-7.7.20131119-0-ghc7.7.20131119.dll] 
> Error 1
>
> make[1]: *** Deleting file 
> 'compiler/stage2/build/libHSghc-7.7.20131119-0-ghc7.7.20131119.dll'
>
> Makefile:64: recipe for target 'all' failed
>
> make: *** [all] Error 2
>
> HEAD $
>
>
>
> _______________________________________________
> 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/20131121/25bac64c/attachment.html>

From kazu at iij.ad.jp  Thu Nov 21 13:05:43 2013
From: kazu at iij.ad.jp (Kazu Yamamoto (=?iso-2022-jp?B?GyRCOzNLXE9CSScbKEI=?=))
Date: Thu, 21 Nov 2013 22:05:43 +0900 (JST)
Subject: Building GHC head with clang on Mavericks
In-Reply-To: <528DE11E.2010305@gmail.com>
References: <CAFXb89CCv4GKhJQR5WRh6UTdgRXcvvoSowH03HCa9s4DeQ3C-g@mail.gmail.com>
 <20131121.155430.37558810975251514.kazu@iij.ad.jp>
 <528DE11E.2010305@gmail.com>
Message-ID: <20131121.220543.410665252314006414.kazu@iij.ad.jp>

Hi SimonM,

> But I'm not sure about this fix.  I'm happy to merge in fixes for Mac
> in general, but in this case we seem to lose the line pragmas, which
> are actually useful (error messages will point to the original source,
> instead of some preprocessed file).

Yes. If we can find another solution which keeps line markers, it is
much better, anyway.

But this patch effects templates only. When a template is included
into an HS file (genearted from a '.x' file), the position is
shifted. So, I'm not sure that line markers are important as you
think.

--Kazu

From marlowsd at gmail.com  Thu Nov 21 15:33:08 2013
From: marlowsd at gmail.com (Simon Marlow)
Date: Thu, 21 Nov 2013 15:33:08 +0000
Subject: Building GHC head with clang on Mavericks
In-Reply-To: <20131121.220543.410665252314006414.kazu@iij.ad.jp>
References: <CAFXb89CCv4GKhJQR5WRh6UTdgRXcvvoSowH03HCa9s4DeQ3C-g@mail.gmail.com>	<20131121.155430.37558810975251514.kazu@iij.ad.jp>	<528DE11E.2010305@gmail.com>
 <20131121.220543.410665252314006414.kazu@iij.ad.jp>
Message-ID: <528E27B4.9070600@gmail.com>

On 21/11/2013 13:05, Kazu Yamamoto (????) wrote:
> Hi SimonM,
>
>> But I'm not sure about this fix.  I'm happy to merge in fixes for Mac
>> in general, but in this case we seem to lose the line pragmas, which
>> are actually useful (error messages will point to the original source,
>> instead of some preprocessed file).
>
> Yes. If we can find another solution which keeps line markers, it is
> much better, anyway.
>
> But this patch effects templates only. When a template is included
> into an HS file (genearted from a '.x' file), the position is
> shifted. So, I'm not sure that line markers are important as you
> think.

Isn't this why the line pragmas are important?  If GHC reports an error 
in the template code, we want the error message to point to the template 
source (GenericTemplate.hs), not the generated source file.  This works 
right now, it'd be a shame to lose it.

Cheers,
Simon

From simonpj at microsoft.com  Thu Nov 21 19:05:06 2013
From: simonpj at microsoft.com (Simon Peyton-Jones)
Date: Thu, 21 Nov 2013 19:05:06 +0000
Subject: Too many symbols
In-Reply-To: <CAEs96n2hbpOQyg4z3pBsaVUzdJ+VO4NG0dK6b-0G93UNi34ZMg@mail.gmail.com>
References: <59543203684B2244980D7E4057D5FBC1486A8F9D@DB3EX14MBXC306.europe.corp.microsoft.com>
 <CAEs96n2hbpOQyg4z3pBsaVUzdJ+VO4NG0dK6b-0G93UNi34ZMg@mail.gmail.com>
Message-ID: <59543203684B2244980D7E4057D5FBC1486AACF9@DB3EX14MBXC306.europe.corp.microsoft.com>

Right GhcLibWays=v did the job, thanks

Simon

| -----Original Message-----
| From: Austin Seipp [mailto:aseipp at pobox.com]
| Sent: 21 November 2013 12:13
| To: Simon Peyton-Jones
| Cc: ghc-devs at haskell.org Devs
| Subject: Re: Too many symbols
| 
| Hi Simon,
| 
| I believe I've found the problem. The issue is that even with
| DYNAMIC_* variables set, GhcLibWays still contains the 'dyn' way as
| opposed to just the 'vanilla' way. If you do:
| 
| $ make show VALUE=GhcLibWays
| 
| in your build tree, it will probably say "v dyn", indicating it'll
| build the GHC DLL as well as vanilla objects. This makes sense since
| we rebuild using different ways in a lot of cases - dynamic-too is
| just a special case, and the other variables (DYNAMIC_TOO,
| DYNAMIC_GHC_PROGRAMS and DYNAMIC_BY_DEFAULT) don't make a difference
| here.
| 
| In the short term, you can hardcode GhcLibWays=v in your build
| settings, but the default templates should perhaps expose something
| more sensible. (They should also precisely document the impact of
| these variables too.)
| 
| On Wed, Nov 20, 2013 at 3:11 PM, Simon Peyton-Jones
| <simonpj at microsoft.com> wrote:
| > Friends
| >
| > I?m getting the dreaded ?Too many symbols in DLL? problem on Windows
| (see
| > below).
| >
| > I believe I can get round it by using static linking only, yes?  But
| how do
| > I do that?  I have
| >
| > DYNAMIC_BY_DEFAULT   = NO
| >
| > DYNAMIC_GHC_PROGRAMS = NO
| >
| > in my validate.mk, but it still happens.  Static only will do me
| fine!
| >
| > Thanks!
| >
| > Simon
| >
| >
| >
| > Number of symbols in
| > compiler/stage2/build/libHSghc-7.7.20131119-0-ghc7.7.20131119.dll:
| 69595
| >
| > case `C:/code/HEAD/inplace/mingw/bin/objdump.exe -p
| > compiler/stage2/build/libHSghc-7.7.20131119-0-ghc7.7.20131119.dll |
| sed -n
| > "1,/^.Ordinal\/Name Pointer/ D; p; /^$/ q" | grep "\[ *0\]" | wc -l`
| in 1)
| > echo DLL compiler/stage2/build/libHSghc-7.7.20131119-0-
| ghc7.7.20131119.dll
| > OK;; 0) echo No symbols in DLL
| > compiler/stage2/build/libHSghc-7.7.20131119-0-ghc7.7.20131119.dll;
| exit 1;;
| > [0-9]*) echo Too many symbols in DLL
| > compiler/stage2/build/libHSghc-7.7.20131119-0-ghc7.7.20131119.dll;
| > C:/code/HEAD/inplace/mingw/bin/objdump.exe -p
| > compiler/stage2/build/libHSghc-7.7.20131119-0-ghc7.7.20131119.dll |
| sed -n
| > "1,/^.Ordinal\/Name Pointer/ D; p; /^$/ q" | tail; exit 1;; *) echo
| bad DLL
| > compiler/stage2/build/libHSghc-7.7.20131119-0-ghc7.7.20131119.dll;
| exit 1;;
| > esac
| >
| > Too many symbols in DLL
| > compiler/stage2/build/libHSghc-7.7.20131119-0-ghc7.7.20131119.dll
| >
| >      [4050] ghczm7zi7zi20131119_Var_zdfUniquableVar_closure
| >
| >      [4051] ghczm7zi7zi20131119_Var_zdfUniquableVar_info
| >
| >      [4052] ghczm7zi7zi20131119_Var_zdwsetVarUnique_closure
| >
| >      [4053] ghczm7zi7zi20131119_Var_zdwsetVarUnique_info
| >
| >      [4054] ghczm7zi7zi20131119_Var_zdwupdateTyVarKindM_closure
| >
| >      [4055] ghczm7zi7zi20131119_Var_zdwupdateTyVarKindM_info
| >
| >      [4056] ghczm7zi7zi20131119_Var_zdwzdcgmapMp_closure
| >
| >      [4057] ghczm7zi7zi20131119_Var_zdwzdcgmapMp_info
| >
| >      [4058] setHeapSize
| >
| >
| >
| > compiler/ghc.mk:472: recipe for target
| > 'compiler/stage2/build/libHSghc-7.7.20131119-0-ghc7.7.20131119.dll'
| failed
| >
| > make[1]: ***
| > [compiler/stage2/build/libHSghc-7.7.20131119-0-ghc7.7.20131119.dll]
| Error 1
| >
| > make[1]: *** Deleting file
| > 'compiler/stage2/build/libHSghc-7.7.20131119-0-ghc7.7.20131119.dll'
| >
| > Makefile:64: recipe for target 'all' failed
| >
| > make: *** [all] Error 2
| >
| > HEAD $
| >
| >
| > _______________________________________________
| > ghc-devs mailing list
| > ghc-devs at haskell.org
| > http://www.haskell.org/mailman/listinfo/ghc-devs
| >
| 
| 
| 
| --
| Regards,
| Austin - PGP: 4096R/0x91384671

From mail at joachim-breitner.de  Thu Nov 21 21:44:02 2013
From: mail at joachim-breitner.de (Joachim Breitner)
Date: Thu, 21 Nov 2013 21:44:02 +0000
Subject: Travis now also tests with -DDEBUG
Message-ID: <1385070242.26867.5.camel@kirk>

Hi,

after I got confused by panics in the testsuite that were not caused by
my changes I configured travis to build GHC (stage2) with and without
-DDEBUG. The current result can be viewed here:
https://travis-ci.org/nomeata/ghc-complete/builds/14332594

You see that it works without -DDEBUG (this is also what vanilla validate
does), but fails with (due to http://ghc.haskell.org/trac/ghc/ticket/8553).

I hope this will make such issues known sooner.

Again: I believe someone is working or planning on a proper
infrastructure to do GHC QA, this is a crutch until then.

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: 198 bytes
Desc: This is a digitally signed message part
URL: <http://www.haskell.org/pipermail/ghc-devs/attachments/20131121/9926000b/attachment-0001.sig>

From kazu at iij.ad.jp  Fri Nov 22 04:48:53 2013
From: kazu at iij.ad.jp (Kazu Yamamoto (=?iso-2022-jp?B?GyRCOzNLXE9CSScbKEI=?=))
Date: Fri, 22 Nov 2013 13:48:53 +0900 (JST)
Subject: Building GHC head with clang on Mavericks
In-Reply-To: <528E27B4.9070600@gmail.com>
References: <528DE11E.2010305@gmail.com>
 <20131121.220543.410665252314006414.kazu@iij.ad.jp>
 <528E27B4.9070600@gmail.com>
Message-ID: <20131122.134853.746976374770177185.kazu@iij.ad.jp>

Hi SimonM,

>> But this patch effects templates only. When a template is included
>> into an HS file (genearted from a '.x' file), the position is
>> shifted. So, I'm not sure that line markers are important as you
>> think.
> 
> Isn't this why the line pragmas are important?  If GHC reports an
> error in the template code, we want the error message to point to the
> template source (GenericTemplate.hs), not the generated source file.
> This works right now, it'd be a shame to lose it.

This is what I did not understand. Thank you for this explanation.

I was wondering why you are talking about line pragmas while I'm
talking about line markers. And I noticed the real problem.

It is the format change of clang's line markers. GCC's line marker is
as follows:

----
# 1 "<built-in>"
----

But clang's one is as follows:

----
# 1 "<built-in>" 1
----

Since this kind of line markers consist of four tokens, Setup of
alex/happy cannot convert to GHC's line pragmas. So, line markers are
left in templates as is, resulting compile errors with
GHC/clang-wrapper later.

I sent pull requests to fix this:
	https://github.com/simonmar/alex/pull/39
	https://github.com/simonmar/happy/pull/15

I confirmed that I can build GHC head with this patched alex/happy.

The patches are redundant. SimonM may want to simplify them by
defining local functions.

--Kazu

From carter.schonwald at gmail.com  Fri Nov 22 04:53:54 2013
From: carter.schonwald at gmail.com (Carter Schonwald)
Date: Thu, 21 Nov 2013 23:53:54 -0500
Subject: Building GHC head with clang on Mavericks
In-Reply-To: <20131122.134853.746976374770177185.kazu@iij.ad.jp>
References: <528DE11E.2010305@gmail.com>
 <20131121.220543.410665252314006414.kazu@iij.ad.jp>
 <528E27B4.9070600@gmail.com>
 <20131122.134853.746976374770177185.kazu@iij.ad.jp>
Message-ID: <CAHYVw0xqx56nOrhXoEtHpcRnc1Pc0iT7Z3Eiw1UsKdJv=PkzgQ@mail.gmail.com>

great sleuthing! thanks Kazu


On Thu, Nov 21, 2013 at 11:48 PM, Kazu Yamamoto <kazu at iij.ad.jp> wrote:

> Hi SimonM,
>
> >> But this patch effects templates only. When a template is included
> >> into an HS file (genearted from a '.x' file), the position is
> >> shifted. So, I'm not sure that line markers are important as you
> >> think.
> >
> > Isn't this why the line pragmas are important?  If GHC reports an
> > error in the template code, we want the error message to point to the
> > template source (GenericTemplate.hs), not the generated source file.
> > This works right now, it'd be a shame to lose it.
>
> This is what I did not understand. Thank you for this explanation.
>
> I was wondering why you are talking about line pragmas while I'm
> talking about line markers. And I noticed the real problem.
>
> It is the format change of clang's line markers. GCC's line marker is
> as follows:
>
> ----
> # 1 "<built-in>"
> ----
>
> But clang's one is as follows:
>
> ----
> # 1 "<built-in>" 1
> ----
>
> Since this kind of line markers consist of four tokens, Setup of
> alex/happy cannot convert to GHC's line pragmas. So, line markers are
> left in templates as is, resulting compile errors with
> GHC/clang-wrapper later.
>
> I sent pull requests to fix this:
>         https://github.com/simonmar/alex/pull/39
>         https://github.com/simonmar/happy/pull/15
>
> I confirmed that I can build GHC head with this patched alex/happy.
>
> The patches are redundant. SimonM may want to simplify them by
> defining local functions.
>
> --Kazu
> _______________________________________________
> 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/20131121/5f7354ee/attachment.html>

From simonpj at microsoft.com  Fri Nov 22 10:15:27 2013
From: simonpj at microsoft.com (Simon Peyton-Jones)
Date: Fri, 22 Nov 2013 10:15:27 +0000
Subject: bundle panic
In-Reply-To: <528892EC.60707@gmail.com>
References: <59543203684B2244980D7E4057D5FBC1486A0192@DB3EX14MBXC306.europe.corp.microsoft.com>
 <528892EC.60707@gmail.com>
Message-ID: <59543203684B2244980D7E4057D5FBC1486B24BF@DB3EX14MBXC312.europe.corp.microsoft.com>

I fixed this.

commit 3f0d4530a716b6db3c20b63825b56597e08b0d5e
Author: Simon Peyton Jones <simonpj at microsoft.com>
Date:   Fri Nov 22 10:12:55 2013 +0000

    When removing unreachable code, remove unreachable info tables too
    
    This bug only shows up when you are using proc-point splitting.
    What was happening was:
      * We generate a proc-point for the stack check
      * And an info table
      * We eliminate the stack check because it's redundant
      * And the dangling info table caused a panic in
        CmmBuildInfoTables.bundle

| -----Original Message-----
| From: Simon Marlow [mailto:marlowsd at gmail.com]
| Sent: 17 November 2013 09:57
| To: Simon Peyton-Jones; ghc-devs at haskell.org
| Subject: Re: bundle panic
| 
| On 16/11/13 00:16, Simon Peyton-Jones wrote:
| > I've looked into this myself.  I don't think it's actually anything
| > wrong in gmp-wrappers.  It's because CmmBuildInfoTables expects all
| the
| > info tables in the (CmmProc info_tbls lbl g) to be defined in the
| graph g.
| >
| > But Jan's new optimisation to the stack overflow check (Note [Always
| > false stack check] in CmmLayoutStack) ends up dropping a conditional
| > branch, so a call to gc is eliminated, and hence a proc point is
| > eliminated, and we end up with an unused thing in info_tbls, which
| > confuses CmmBuildInfoTables
| 
| > Sigh. I don't know why this only happens on Windows.  I'm looking into
| a fix
| 
| Perhaps this is a problem that only shows up with proc points, which is
| why you wouldn't see it on x86_64/Linux.  Let me know if you get stuck
| and I'll try to look into it.
| 
| FYI eliminating always-false stack checks is not new, it was temporarily
| broken by:
| 
| commit 94125c97e49987e91fa54da6c86bc6d17417f5cf
| Author: Jan Stolarek <jan.stolarek at p.lodz.pl>
| Date:   Wed Oct 16 09:45:56 2013 +0200
| 
|      Generate (old + 0) instead of Sp in stack checks
| 
| and then fixed up by:
| 
| commit 1cf0c8ad321d1d358cbec46d35be02566faf2d00
| Author: Jan Stolarek <jan.stolarek at p.lodz.pl>
| Date:   Thu Oct 17 23:17:06 2013 +0200
| 
|      Optimise stack checks that are always false
| 
| Cheers,
| Simon
| 
| 
| >
| >
| > Simon
| >
| > *From:*Simon Peyton-Jones
| > *Sent:* 15 November 2013 22:18
| > *To:* ghc-devs at haskell.org
| > *Subject:* bundle panic
| >
| > Windows build is failing again in a new way.  It was fine a couple of
| > days ago. Does this ring any bells?
| >
| > ghc-stage1.exe: panic! (the 'impossible' happened)
| >
| >    (GHC version 7.7.20131107 for i386-unknown-mingw32):
| >
| >       bundle
| >
| > Simon
| >
| > "inplace/bin/ghc-stage1.exe" -static  -H32m -O -Werror -Wall -H64m
| > -O0    -package-name integer-gmp-0.5.1.0 -hide-all-packages -i
| > -ilibraries/integer-gmp/. -ilibraries/integer-gmp/dist-install/build
| > -ilibraries/integer-gmp/dist-install/build/autogen
| > -Ilibraries/integer-gmp/dist-install/build
| > -Ilibraries/integer-gmp/dist-install/build/autogen
| > -Ilibraries/integer-gmp/.    -optP-include
| > -optPlibraries/integer-gmp/dist-install/build/autogen/cabal_macros.h
| > -package ghc-prim-0.3.1.0 -Wall -package-name integer-gmp -
| XHaskell2010
| > -dcore-lint  -no-user-package-db -rtsopts
| > -Ilibraries/integer-gmp/mkGmpDerivedConstants/dist     -c
| > libraries/integer-gmp/cbits/gmp-wrappers.cmm -o
| > libraries/integer-gmp/dist-install/build/cbits/gmp-wrappers.o
| >
| > ghc-stage1.exe: panic! (the 'impossible' happened)
| >
| >    (GHC version 7.7.20131107 for i386-unknown-mingw32):
| >
| >       bundle
| >
| >      c8 integer_cmm_importIntegerFromByteArrayzh [(c8,
| >
| >                                                    label: block{v
| c8}_info
| >
| >                                                    rep:StackRep
| [False,
| > True, True, True]),
| >
| >                                                   (cg,
| >
| >                                                    label: block{v
| cg}_info
| >
| >                                                    rep:StackRep
| [False,
| > True, True, True])]
| >
| > Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug
| >
| > HEAD (master)$
| >
| >
| >
| > _______________________________________________
| > ghc-devs mailing list
| > ghc-devs at haskell.org
| > http://www.haskell.org/mailman/listinfo/ghc-devs
| >


From mail at joachim-breitner.de  Fri Nov 22 22:08:06 2013
From: mail at joachim-breitner.de (Joachim Breitner)
Date: Fri, 22 Nov 2013 22:08:06 +0000
Subject: Moving travis CI repo to git.haskell.org?
Message-ID: <1385158086.10037.7.camel@kirk>

Hi,

so far the experiment with
https://travis-ci.org/nomeata/ghc-complete/builds is quite successful.
Now that I started to also run the testsuite with -DDEBUG I was able
spot some tests broken due to asserts in a timely manner, timely enough
to identify (with high certainty) the causing commit.

So it is a useful tool, and I would like to see it at
https://travis-ci.org/ghc/ghc-complete/ghc instead, i.e. not tied to my
name. Unfortunately, I cannot do that myself. Therefore, if you agree
that this is a good thing (until we have a CI of our own), would someone
with appropriate permissions please
 * Pull the repo from https://github.com/nomeata/ghc-complete to  
   git.haskell.org.
 * Set up the mirror on github.com/ghc for ghc-complete (if that is a 
   separate step)
 * and enable it on travis-ci.org.

Once that is done I can change my cronjob (which is generating the
commits) to push to git.haskell.org. If you also want to run that code,
even better: just set up a cronjob that calls update.sh in a checkout of
the repo, and adjust the --author flag therein.

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: 198 bytes
Desc: This is a digitally signed message part
URL: <http://www.haskell.org/pipermail/ghc-devs/attachments/20131122/b5740efa/attachment.sig>

From johan.tibell at gmail.com  Fri Nov 22 22:36:45 2013
From: johan.tibell at gmail.com (Johan Tibell)
Date: Fri, 22 Nov 2013 23:36:45 +0100
Subject: Moving travis CI repo to git.haskell.org?
In-Reply-To: <1385158086.10037.7.camel@kirk>
References: <1385158086.10037.7.camel@kirk>
Message-ID: <CAK-tuPbW_oCGhFBUwGoONGWiwq7nJawh48FOQLHe-+GV6+m8LQ@mail.gmail.com>

What's the difference between the ghc and ghc-complete repos?


On Fri, Nov 22, 2013 at 11:08 PM, Joachim Breitner <mail at joachim-breitner.de
> wrote:

> Hi,
>
> so far the experiment with
> https://travis-ci.org/nomeata/ghc-complete/builds is quite successful.
> Now that I started to also run the testsuite with -DDEBUG I was able
> spot some tests broken due to asserts in a timely manner, timely enough
> to identify (with high certainty) the causing commit.
>
> So it is a useful tool, and I would like to see it at
> https://travis-ci.org/ghc/ghc-complete/ghc instead, i.e. not tied to my
> name. Unfortunately, I cannot do that myself. Therefore, if you agree
> that this is a good thing (until we have a CI of our own), would someone
> with appropriate permissions please
>  * Pull the repo from https://github.com/nomeata/ghc-complete to
>    git.haskell.org.
>  * Set up the mirror on github.com/ghc for ghc-complete (if that is a
>    separate step)
>  * and enable it on travis-ci.org.
>
> Once that is done I can change my cronjob (which is generating the
> commits) to push to git.haskell.org. If you also want to run that code,
> even better: just set up a cronjob that calls update.sh in a checkout of
> the repo, and adjust the --author flag therein.
>
> 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/20131122/3b7a30d0/attachment.html>

From mail at joachim-breitner.de  Fri Nov 22 23:23:44 2013
From: mail at joachim-breitner.de (Joachim Breitner)
Date: Fri, 22 Nov 2013 23:23:44 +0000
Subject: Moving travis CI repo to git.haskell.org?
In-Reply-To: <CAK-tuPbW_oCGhFBUwGoONGWiwq7nJawh48FOQLHe-+GV6+m8LQ@mail.gmail.com>
References: <1385158086.10037.7.camel@kirk>
 <CAK-tuPbW_oCGhFBUwGoONGWiwq7nJawh48FOQLHe-+GV6+m8LQ@mail.gmail.com>
Message-ID: <1385162624.10037.22.camel@kirk>

Hi,

Am Freitag, den 22.11.2013, 23:36 +0100 schrieb Johan Tibell:
> What's the difference between the ghc and ghc-complete repos?

ghc-complete is a repository that contains (besides some scripts) only
one file, a fingerprint:

~/build/haskell/ghc-complete $ cat fingerprint 
.|5874f13fd83409b28c4f781a93e80f4605d0593e
libffi-tarballs|a0088d1da0e171849ddb47a46c869856037a01d1
libraries/Cabal|e3e3702a6997f9a431ca562156cf667c93bd0e5e
libraries/Win32|3da00d80f2fd7d1032e3530e1af1b39fba79aac3
libraries/array|26ff04744117b0ad8233a1a2b5635fa1277b88d9
libraries/base|f3e5ad387c2e77bed36fc41b6319514fc38e59f2
libraries/binary|2799c25d85b4627200f2e4dcb30d2128488780c3
...

It is updated regularly (currently a cronjob every 15 minutes, ideally
by push hooks), and each push triggers a build of exactly these recorded
versions of all components via travis:
https://travis-ci.org/nomeata/ghc-complete/builds

This way, travis builds are triggered also by updates to, say, the
testsuite, it allows for reproducible builds, and possibly allows
bisecting and other stuff. It is a weak substitute for having everything
in proper submodules.

As a developer, you usually would not interact with ghc-complete.

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: 198 bytes
Desc: This is a digitally signed message part
URL: <http://www.haskell.org/pipermail/ghc-devs/attachments/20131122/316cd3db/attachment.sig>

From edskodevries at gmail.com  Mon Nov 25 16:47:50 2013
From: edskodevries at gmail.com (Edsko de Vries)
Date: Mon, 25 Nov 2013 16:47:50 +0000
Subject: Cannot build tagged with HEAD
Message-ID: <CAETJ90Sf=rv3EN5T4fBXf8yfUThbeW6ZYHEU5HVo8Dw-D+ED4A@mail.gmail.com>

I'm getting the errors below if I try to build tagged with head:

src/Data/Tagged.hs:57:5:
    'Tagged' is applied to too many type arguments
    In an expression type signature:
      Tagged k s b -> Tagged k s b -> Bool
    In the expression:
        ghc-prim:GHC.Prim.coerce ((==) :: b -> b -> Bool) ::
          Tagged k s b -> Tagged k s b -> Bool
    In an equation for '==':
        (==)
          = ghc-prim:GHC.Prim.coerce ((==) :: b -> b -> Bool) ::
              Tagged k s b -> Tagged k s b -> Bool

src/Data/Tagged.hs:57:9:
    'Tagged' is applied to too many type arguments
    In an expression type signature:
      Tagged k s b -> Tagged k s b -> Ordering
    In the expression:
        ghc-prim:GHC.Prim.coerce (compare :: b -> b -> Ordering) ::
          Tagged k s b -> Tagged k s b -> Ordering
    In an equation for 'compare':
        compare
          = ghc-prim:GHC.Prim.coerce (compare :: b -> b -> Ordering) ::
              Tagged k s b -> Tagged k s b -> Ordering

src/Data/Tagged.hs:57:14:
    'Tagged' is applied to too many type arguments
    In an expression type signature:
      (,) (Tagged k s b) (Tagged k s b) -> [] (Tagged k s b)
    In the expression:
        ghc-prim:GHC.Prim.coerce (range :: (,) b b -> [] b) ::
          (,) (Tagged k s b) (Tagged k s b) -> [] (Tagged k s b)
    In an equation for 'range':
        range
          = ghc-prim:GHC.Prim.coerce (range :: (,) b b -> [] b) ::
              (,) (Tagged k s b) (Tagged k s b) -> [] (Tagged k s b)

src/Data/Tagged.hs:57:18:
    'Tagged' is applied to too many type arguments
    In an expression type signature: Tagged k s b
    In the expression:
        ghc-prim:GHC.Prim.coerce (minBound :: b) :: Tagged k s b
    In an equation for 'minBound':
        minBound = ghc-prim:GHC.Prim.coerce (minBound :: b) :: Tagged k s b

Line 57 is the "(" in

newtype Tagged s b = Tagged { unTagged :: b } deriving
  ( Eq, Ord, Ix, Bounded
#if __GLASGOW_HASKELL__ >= 707
  , Typeable
#endif
  )

Anyone any ideas what's going on?

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

From simonpj at microsoft.com  Mon Nov 25 17:06:10 2013
From: simonpj at microsoft.com (Simon Peyton-Jones)
Date: Mon, 25 Nov 2013 17:06:10 +0000
Subject: Cannot build tagged with HEAD
In-Reply-To: <CAETJ90Sf=rv3EN5T4fBXf8yfUThbeW6ZYHEU5HVo8Dw-D+ED4A@mail.gmail.com>
References: <CAETJ90Sf=rv3EN5T4fBXf8yfUThbeW6ZYHEU5HVo8Dw-D+ED4A@mail.gmail.com>
Message-ID: <59543203684B2244980D7E4057D5FBC1486CAFD3@DB3EX14MBXC308.europe.corp.microsoft.com>

looks like something to do with the new GND story.. Richard, Joachim?

Simon

From: ghc-devs [mailto:ghc-devs-bounces at haskell.org] On Behalf Of Edsko de Vries
Sent: 25 November 2013 16:48
To: ghc-devs at haskell.org
Subject: Cannot build tagged with HEAD

I'm getting the errors below if I try to build tagged with head:

src/Data/Tagged.hs:57:5:
    ?Tagged? is applied to too many type arguments
    In an expression type signature:
      Tagged k s b -> Tagged k s b -> Bool
    In the expression:
        ghc-prim:GHC.Prim.coerce ((==) :: b -> b -> Bool) ::
          Tagged k s b -> Tagged k s b -> Bool
    In an equation for ?==?:
        (==)
          = ghc-prim:GHC.Prim.coerce ((==) :: b -> b -> Bool) ::
              Tagged k s b -> Tagged k s b -> Bool

src/Data/Tagged.hs:57:9:
    ?Tagged? is applied to too many type arguments
    In an expression type signature:
      Tagged k s b -> Tagged k s b -> Ordering
    In the expression:
        ghc-prim:GHC.Prim.coerce (compare :: b -> b -> Ordering) ::
          Tagged k s b -> Tagged k s b -> Ordering
    In an equation for ?compare?:
        compare
          = ghc-prim:GHC.Prim.coerce (compare :: b -> b -> Ordering) ::
              Tagged k s b -> Tagged k s b -> Ordering

src/Data/Tagged.hs:57:14:
    ?Tagged? is applied to too many type arguments
    In an expression type signature:
      (,) (Tagged k s b) (Tagged k s b) -> [] (Tagged k s b)
    In the expression:
        ghc-prim:GHC.Prim.coerce (range :: (,) b b -> [] b) ::
          (,) (Tagged k s b) (Tagged k s b) -> [] (Tagged k s b)
    In an equation for ?range?:
        range
          = ghc-prim:GHC.Prim.coerce (range :: (,) b b -> [] b) ::
              (,) (Tagged k s b) (Tagged k s b) -> [] (Tagged k s b)

src/Data/Tagged.hs:57:18:
    ?Tagged? is applied to too many type arguments
    In an expression type signature: Tagged k s b
    In the expression:
        ghc-prim:GHC.Prim.coerce (minBound :: b) :: Tagged k s b
    In an equation for ?minBound?:
        minBound = ghc-prim:GHC.Prim.coerce (minBound :: b) :: Tagged k s b

Line 57 is the "(" in

newtype Tagged s b = Tagged { unTagged :: b } deriving
  ( Eq, Ord, Ix, Bounded
#if __GLASGOW_HASKELL__ >= 707
  , Typeable
#endif
  )

Anyone any ideas what's going on?

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

From mail at joachim-breitner.de  Mon Nov 25 17:18:34 2013
From: mail at joachim-breitner.de (Joachim Breitner)
Date: Mon, 25 Nov 2013 17:18:34 +0000
Subject: Cannot build tagged with HEAD
In-Reply-To: <CAETJ90Sf=rv3EN5T4fBXf8yfUThbeW6ZYHEU5HVo8Dw-D+ED4A@mail.gmail.com>
References: <CAETJ90Sf=rv3EN5T4fBXf8yfUThbeW6ZYHEU5HVo8Dw-D+ED4A@mail.gmail.com>
Message-ID: <1385399914.2549.3.camel@kirk>

Hi Edsko,

Am Montag, den 25.11.2013, 16:47 +0000 schrieb Edsko de Vries:
> I'm getting the errors below if I try to build tagged with head:
>
> src/Data/Tagged.hs:57:5:
>     ?Tagged? is applied to too many type arguments
>     In an expression type signature:
>       Tagged k s b -> Tagged k s b -> Bool
>     In the expression:
>         ghc-prim:GHC.Prim.coerce ((==) :: b -> b -> Bool) ::
>           Tagged k s b -> Tagged k s b -> Bool
>     In an equation for ?==?:
>         (==)
>           = ghc-prim:GHC.Prim.coerce ((==) :: b -> b -> Bool) ::
>               Tagged k s b -> Tagged k s b -> Bool

that is the new GND code failing; this now tries to write instances
using ?coerce?, and it seems the code generating the type annotations
does wrong stuff.

Can you create ticket, preferably with a small example, and I?ll look
into it.

Thanks for testing HEAD!
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: 198 bytes
Desc: This is a digitally signed message part
URL: <http://www.haskell.org/pipermail/ghc-devs/attachments/20131125/946d5c02/attachment.sig>

From edskodevries at gmail.com  Mon Nov 25 17:46:59 2013
From: edskodevries at gmail.com (Edsko de Vries)
Date: Mon, 25 Nov 2013 17:46:59 +0000
Subject: Cannot build tagged with HEAD
In-Reply-To: <1385399914.2549.3.camel@kirk>
References: <CAETJ90Sf=rv3EN5T4fBXf8yfUThbeW6ZYHEU5HVo8Dw-D+ED4A@mail.gmail.com>
 <1385399914.2549.3.camel@kirk>
Message-ID: <CAETJ90QwBNuh49evEV9pPwtyhgkCo4e3MLiBw-6f4d0Dhn7qoA@mail.gmail.com>

Ok, created a ticket: https://ghc.haskell.org/trac/ghc/ticket/8563 .

Thanks,

Edsko


On Mon, Nov 25, 2013 at 5:18 PM, Joachim Breitner
<mail at joachim-breitner.de>wrote:

> Hi Edsko,
>
> Am Montag, den 25.11.2013, 16:47 +0000 schrieb Edsko de Vries:
> > I'm getting the errors below if I try to build tagged with head:
> >
> > src/Data/Tagged.hs:57:5:
> >     'Tagged' is applied to too many type arguments
> >     In an expression type signature:
> >       Tagged k s b -> Tagged k s b -> Bool
> >     In the expression:
> >         ghc-prim:GHC.Prim.coerce ((==) :: b -> b -> Bool) ::
> >           Tagged k s b -> Tagged k s b -> Bool
> >     In an equation for '==':
> >         (==)
> >           = ghc-prim:GHC.Prim.coerce ((==) :: b -> b -> Bool) ::
> >               Tagged k s b -> Tagged k s b -> Bool
>
> that is the new GND code failing; this now tries to write instances
> using "coerce", and it seems the code generating the type annotations
> does wrong stuff.
>
> Can you create ticket, preferably with a small example, and I'll look
> into it.
>
> Thanks for testing HEAD!
> 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 --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/ghc-devs/attachments/20131125/bd835655/attachment.html>

From kazu at iij.ad.jp  Tue Nov 26 02:44:37 2013
From: kazu at iij.ad.jp (Kazu Yamamoto (=?iso-2022-jp?B?GyRCOzNLXE9CSScbKEI=?=))
Date: Tue, 26 Nov 2013 11:44:37 +0900 (JST)
Subject: Cannot instantiate unification variable
Message-ID: <20131126.114437.1254426457474039887.kazu@iij.ad.jp>

Hi,

Recent GHC head on 32bit Linux cannot build conduit-1.0.9.2. (See the
attached log.)  A while ago, GHC head on 32bit Linux could build it.
The same GHC head on 64bit Linux can build it.

Michael Snoyman suggested me to add ImpredicativeTypes. When I added
it to the Internal.hs, GHC head on 32bit Linux can build it.  And he
said to other released GHCs can build it. Actually, GHC 7.4.2 on
32bit Linux can build it.

He believes that this is a bug of GHC head (on 32bit Linux). Any
information?

Note that conduit-1.0.9.3 already includes ImpredicativeTypes.

--Kazu

Building conduit-1.0.9.2...
Preprocessing library conduit-1.0.9.2...
[2 of 8] Compiling Data.Conduit.Internal ( Data/Conduit/Internal.hs, dist/build/Dat
a/Conduit/Internal.o )

Data/Conduit/Internal.hs:211:105:
    Cannot instantiate unification variable ?b0?
    with a type involving foralls:
      (forall a. m1 a -> n1 a)
      -> ConduitM i o m1 b1 -> ConduitM i o n1 b1
      Perhaps you want ImpredicativeTypes
    In the expression:
        GHC.Exts.coerce
          (hoist ::
             (forall (a :: *). m a -> n a)
             -> Pipe i i o () m b -> Pipe i i o () n b) ::
          forall (m :: * -> *) (b :: *) (n :: * -> *). Monad m =>
          (forall (a :: *). m a -> n a)
          -> ConduitM i o m b -> ConduitM i o n b
    In an equation for ?hoist?:
        hoist
          = GHC.Exts.coerce
              (hoist ::
                 (forall (a :: *). m a -> n a)
                 -> Pipe i i o () m b -> Pipe i i o () n b) ::
              forall (m :: * -> *) (b :: *) (n :: * -> *). Monad m =>
              (forall (a :: *). m a -> n a)
              -> ConduitM i o m b -> ConduitM i o n b

From amos.robinson at gmail.com  Tue Nov 26 04:39:14 2013
From: amos.robinson at gmail.com (Amos Robinson)
Date: Tue, 26 Nov 2013 15:39:14 +1100
Subject: Link error with head Re: [commit: ghc] master: GHCi: Properly
 generate jump code for ARM (#8380) (5bab1a5)
Message-ID: <CAKFe=dX0NFVzMCfORLJQuUFmMFRWE33NGSP1WAnY0-YLFMJBUQ@mail.gmail.com>

Hi,
I'm having trouble linking with head:

> [1 of 1] Compiling Main             ( bindisttest/HelloWorld.lhs, bindisttest/HelloWorld.o )
> Linking bindisttest/HelloWorld ...
> Undefined symbols for architecture x86_64:
>   "___builtin___clear_cache", referenced from:
>      _flushExec in libHSrts.a(Storage.o)
> ld: symbol(s) not found for architecture x86_64
> collect2: ld returned 1 exit status

This is on OSX 10.8.5, where gcc --version gives me
> i686-apple-darwin11-llvm-gcc-4.2 (GCC) 4.2.1 (Based on Apple Inc. build 5658) (LLVM build 2336.11.00)

I get the impression that this commit is related. Is it the case that
Apple switched from gcc to clang recently? Could that be why
___builtin__clear_cache is missing?

I'm sorry, I don't really know anything about the runtime system, so
am kind of stuck.


On Sat, Nov 23, 2013 at 1:22 AM,  <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/5bab1a57f572e29dfdffd6d1ce8e53a2772b18fd/ghc
>
>>---------------------------------------------------------------
>
> commit 5bab1a57f572e29dfdffd6d1ce8e53a2772b18fd
> Author: Austin Seipp <austin at well-typed.com>
> Date:   Mon Nov 11 10:26:03 2013 -0600
>
>     GHCi: Properly generate jump code for ARM (#8380)
>
>     This adds code for jumping to given addresses for ARM, written by Ben
>     Gamari.
>
>     However, when allocating new infotables for bytecode (which is where
>     this jump code occurs), we need to be sure to flush the cache on the
>     execute pointer returned from allocateExec() - on systems like ARM, the
>     processor won't reliably read back code or automatically cache flush,
>     where x86 will.
>
>     So we add a new flushExec primitive to call out to GCC's
>     __builtin___clear_cache primitive, which will properly generate the
>     correct code (nothing on x86, and a call to libgcc's __clear_cache on
>     ARM) and make sure we use it after writing the code out.
>
>     Authored-by: Ben Gamari <bgamari.foss at gmail.com>
>     Authored-by: Austin Seipp <austin at well-typed.com>
>     Signed-off-by: Austin Seipp <austin at well-typed.com>
>
>
>>---------------------------------------------------------------
>
> 5bab1a57f572e29dfdffd6d1ce8e53a2772b18fd
>  compiler/ghci/ByteCodeItbls.lhs |   21 ++++++++++++++++++++-
>  includes/rts/storage/GC.h       |    1 +
>  rts/Linker.c                    |    1 +
>  rts/sm/Storage.c                |   27 +++++++++++++++++++++++++++
>  4 files changed, 49 insertions(+), 1 deletion(-)
>
> diff --git a/compiler/ghci/ByteCodeItbls.lhs b/compiler/ghci/ByteCodeItbls.lhs
> index 0d07be5..2180f87 100644
> --- a/compiler/ghci/ByteCodeItbls.lhs
> +++ b/compiler/ghci/ByteCodeItbls.lhs
> @@ -227,6 +227,20 @@ mkJumpToAddr dflags a = case platformArch (targetPlatform dflags) of
>                   , fromIntegral (w64 .&. 0x0000FFFF)
>                   , fromIntegral ((w64 `shiftR` 32) .&. 0x0000FFFF) ]
>
> +    ArchARM { } ->
> +        -- Generates Thumb sequence,
> +        --      ldr r1, [pc, #0]
> +        --      bx r1
> +        --
> +        -- which looks like:
> +        --     00000000 <.addr-0x8>:
> +        --     0:      4900        ldr    r1, [pc]      ; 8 <.addr>
> +        --     4:      4708        bx     r1
> +        let w32 = fromIntegral (ptrToInt a) :: Word32
> +        in Left [ 0x49, 0x00
> +                , 0x47, 0x08
> +                , byte0 w32, byte1 w32, byte2 w32, byte3 w32]
> +
>      arch ->
>          panic ("mkJumpToAddr not defined for " ++ show arch)
>
> @@ -374,11 +388,16 @@ load = do addr <- advance
>  newExecConItbl :: DynFlags -> StgConInfoTable -> IO (FunPtr ())
>  newExecConItbl dflags obj
>     = alloca $ \pcode -> do
> -        wr_ptr <- _allocateExec (fromIntegral (sizeOfConItbl dflags obj)) pcode
> +        let sz = fromIntegral (sizeOfConItbl dflags obj)
> +        wr_ptr <- _allocateExec sz pcode
>          ex_ptr <- peek pcode
>          pokeConItbl dflags wr_ptr ex_ptr obj
> +        _flushExec sz ex_ptr -- Cache flush (if needed)
>          return (castPtrToFunPtr ex_ptr)
>
>  foreign import ccall unsafe "allocateExec"
>    _allocateExec :: CUInt -> Ptr (Ptr a) -> IO (Ptr a)
> +
> +foreign import ccall unsafe "flushExec"
> +  _flushExec :: CUInt -> Ptr a -> IO ()
>  \end{code}
> diff --git a/includes/rts/storage/GC.h b/includes/rts/storage/GC.h
> index 8133496..f8b8afe 100644
> --- a/includes/rts/storage/GC.h
> +++ b/includes/rts/storage/GC.h
> @@ -161,6 +161,7 @@ typedef void* AdjustorWritable;
>  typedef void* AdjustorExecutable;
>
>  AdjustorWritable allocateExec(W_ len, AdjustorExecutable *exec_addr);
> +void flushExec(W_ len, AdjustorExecutable exec_addr);
>  #if defined(ios_HOST_OS)
>  AdjustorWritable execToWritable(AdjustorExecutable exec);
>  #endif
> diff --git a/rts/Linker.c b/rts/Linker.c
> index 77943a5..14ebac3 100644
> --- a/rts/Linker.c
> +++ b/rts/Linker.c
> @@ -1350,6 +1350,7 @@ typedef struct _RtsSymbolVal {
>        SymI_HasProto(g0)                                                 \
>        SymI_HasProto(allocate)                                           \
>        SymI_HasProto(allocateExec)                                       \
> +      SymI_HasProto(flushExec)                                          \
>        SymI_HasProto(freeExec)                                           \
>        SymI_HasProto(getAllocations)                                     \
>        SymI_HasProto(revertCAFs)                                         \
> diff --git a/rts/sm/Storage.c b/rts/sm/Storage.c
> index 112ad83..c1a1a5a 100644
> --- a/rts/sm/Storage.c
> +++ b/rts/sm/Storage.c
> @@ -1152,6 +1152,15 @@ AdjustorWritable allocateExec (W_ bytes, AdjustorExecutable *exec_ret)
>      return (ret + 1);
>  }
>
> +void flushExec (W_ len, AdjustorExecutable exec_addr)
> +{
> +  /* On ARM and other platforms, we need to flush the cache after
> +     writing code into memory, so the processor reliably sees it. */
> +  unsigned char* begin = (unsigned char*)exec_addr;
> +  unsigned char* end   = begin + len;
> +  __builtin___clear_cache(begin, end);
> +}
> +
>  // freeExec gets passed the executable address, not the writable address.
>  void freeExec (AdjustorExecutable addr)
>  {
> @@ -1198,6 +1207,15 @@ AdjustorWritable execToWritable(AdjustorExecutable exec)
>      return writ;
>  }
>
> +void flushExec (W_ len, AdjustorExecutable exec_addr)
> +{
> +  /* On ARM and other platforms, we need to flush the cache after
> +     writing code into memory, so the processor reliably sees it. */
> +  unsigned char* begin = (unsigned char*)exec_addr;
> +  unsigned char* end   = begin + len;
> +  __builtin___clear_cache(begin, end);
> +}
> +
>  void freeExec(AdjustorExecutable exec)
>  {
>      AdjustorWritable writ;
> @@ -1251,6 +1269,15 @@ AdjustorWritable allocateExec (W_ bytes, AdjustorExecutable *exec_ret)
>      return ret;
>  }
>
> +void flushExec (W_ len, AdjustorExecutable exec_addr)
> +{
> +  /* On ARM and other platforms, we need to flush the cache after
> +     writing code into memory, so the processor reliably sees it. */
> +  unsigned char* begin = (unsigned char*)exec_addr;
> +  unsigned char* end   = begin + len;
> +  __builtin___clear_cache(begin, end);
> +}
> +
>  void freeExec (void *addr)
>  {
>      StgPtr p = (StgPtr)addr - 1;
>
> _______________________________________________
> ghc-commits mailing list
> ghc-commits at haskell.org
> http://www.haskell.org/mailman/listinfo/ghc-commits

From amos.robinson at gmail.com  Tue Nov 26 04:55:37 2013
From: amos.robinson at gmail.com (Amos Robinson)
Date: Tue, 26 Nov 2013 15:55:37 +1100
Subject: Link error with head Re: [commit: ghc] master: GHCi: Properly
 generate jump code for ARM (#8380) (5bab1a5)
In-Reply-To: <CAKFe=dX0NFVzMCfORLJQuUFmMFRWE33NGSP1WAnY0-YLFMJBUQ@mail.gmail.com>
References: <CAKFe=dX0NFVzMCfORLJQuUFmMFRWE33NGSP1WAnY0-YLFMJBUQ@mail.gmail.com>
Message-ID: <CAKFe=dVssv4WTTQGKCszCDtBSmUbNHbs6iZxnpQx1MREtLJrNA@mail.gmail.com>

Sorry for the noise, it turns out there's already a trac ticket:
https://ghc.haskell.org/trac/ghc/ticket/8561
(I didn't find it because I was searching for ___builtin? instead of __builtin!)

On Tue, Nov 26, 2013 at 3:39 PM, Amos Robinson <amos.robinson at gmail.com> wrote:
> Hi,
> I'm having trouble linking with head:
>
>> [1 of 1] Compiling Main             ( bindisttest/HelloWorld.lhs, bindisttest/HelloWorld.o )
>> Linking bindisttest/HelloWorld ...
>> Undefined symbols for architecture x86_64:
>>   "___builtin___clear_cache", referenced from:
>>      _flushExec in libHSrts.a(Storage.o)
>> ld: symbol(s) not found for architecture x86_64
>> collect2: ld returned 1 exit status
>
> This is on OSX 10.8.5, where gcc --version gives me
>> i686-apple-darwin11-llvm-gcc-4.2 (GCC) 4.2.1 (Based on Apple Inc. build 5658) (LLVM build 2336.11.00)
>
> I get the impression that this commit is related. Is it the case that
> Apple switched from gcc to clang recently? Could that be why
> ___builtin__clear_cache is missing?
>
> I'm sorry, I don't really know anything about the runtime system, so
> am kind of stuck.
>
>
--SNIP--

From carter.schonwald at gmail.com  Tue Nov 26 05:13:17 2013
From: carter.schonwald at gmail.com (Carter Schonwald)
Date: Tue, 26 Nov 2013 00:13:17 -0500
Subject: Link error with head Re: [commit: ghc] master: GHCi: Properly
 generate jump code for ARM (#8380) (5bab1a5)
In-Reply-To: <CAKFe=dVssv4WTTQGKCszCDtBSmUbNHbs6iZxnpQx1MREtLJrNA@mail.gmail.com>
References: <CAKFe=dX0NFVzMCfORLJQuUFmMFRWE33NGSP1WAnY0-YLFMJBUQ@mail.gmail.com>
 <CAKFe=dVssv4WTTQGKCszCDtBSmUbNHbs6iZxnpQx1MREtLJrNA@mail.gmail.com>
Message-ID: <CAHYVw0wOegdB-eBj4=+t15DSO_NcGXf0J33BpkC+iCv_im1gtg@mail.gmail.com>

It's because you're using GCC 4.2 on your Mac.  It's not in GCC till 4.3.

But should be cppd so that it's not used on x86 architectures so that this
use doesn't happen

On Monday, November 25, 2013, Amos Robinson wrote:

> Sorry for the noise, it turns out there's already a trac ticket:
> https://ghc.haskell.org/trac/ghc/ticket/8561
> (I didn't find it because I was searching for ___builtin? instead of
> __builtin!)
>
> On Tue, Nov 26, 2013 at 3:39 PM, Amos Robinson <amos.robinson at gmail.com<javascript:;>>
> wrote:
> > Hi,
> > I'm having trouble linking with head:
> >
> >> [1 of 1] Compiling Main             ( bindisttest/HelloWorld.lhs,
> bindisttest/HelloWorld.o )
> >> Linking bindisttest/HelloWorld ...
> >> Undefined symbols for architecture x86_64:
> >>   "___builtin___clear_cache", referenced from:
> >>      _flushExec in libHSrts.a(Storage.o)
> >> ld: symbol(s) not found for architecture x86_64
> >> collect2: ld returned 1 exit status
> >
> > This is on OSX 10.8.5, where gcc --version gives me
> >> i686-apple-darwin11-llvm-gcc-4.2 (GCC) 4.2.1 (Based on Apple Inc. build
> 5658) (LLVM build 2336.11.00)
> >
> > I get the impression that this commit is related. Is it the case that
> > Apple switched from gcc to clang recently? Could that be why
> > ___builtin__clear_cache is missing?
> >
> > I'm sorry, I don't really know anything about the runtime system, so
> > am kind of stuck.
> >
> >
> --SNIP--
> _______________________________________________
> 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/20131126/eeeab843/attachment-0001.html>

From carter.schonwald at gmail.com  Tue Nov 26 05:27:06 2013
From: carter.schonwald at gmail.com (Carter Schonwald)
Date: Tue, 26 Nov 2013 00:27:06 -0500
Subject: Link error with head Re: [commit: ghc] master: GHCi: Properly
 generate jump code for ARM (#8380) (5bab1a5)
In-Reply-To: <CAHYVw0wOegdB-eBj4=+t15DSO_NcGXf0J33BpkC+iCv_im1gtg@mail.gmail.com>
References: <CAKFe=dX0NFVzMCfORLJQuUFmMFRWE33NGSP1WAnY0-YLFMJBUQ@mail.gmail.com>
 <CAKFe=dVssv4WTTQGKCszCDtBSmUbNHbs6iZxnpQx1MREtLJrNA@mail.gmail.com>
 <CAHYVw0wOegdB-eBj4=+t15DSO_NcGXf0J33BpkC+iCv_im1gtg@mail.gmail.com>
Message-ID: <CAHYVw0wwg8RX6NHSfvXKNQNGU8K-J-FbpBuef386XCpCqezWgA@mail.gmail.com>

I'll cook up a patch and post it to trac in the next hour.

On Tuesday, November 26, 2013, Carter Schonwald wrote:

> It's because you're using GCC 4.2 on your Mac.  It's not in GCC till 4.3.
>
> But should be cppd so that it's not used on x86 architectures so that this
> use doesn't happen
>
> On Monday, November 25, 2013, Amos Robinson wrote:
>
>> Sorry for the noise, it turns out there's already a trac ticket:
>> https://ghc.haskell.org/trac/ghc/ticket/8561
>> (I didn't find it because I was searching for ___builtin? instead of
>> __builtin!)
>>
>> On Tue, Nov 26, 2013 at 3:39 PM, Amos Robinson <amos.robinson at gmail.com>
>> wrote:
>> > Hi,
>> > I'm having trouble linking with head:
>> >
>> >> [1 of 1] Compiling Main             ( bindisttest/HelloWorld.lhs,
>> bindisttest/HelloWorld.o )
>> >> Linking bindisttest/HelloWorld ...
>> >> Undefined symbols for architecture x86_64:
>> >>   "___builtin___clear_cache", referenced from:
>> >>      _flushExec in libHSrts.a(Storage.o)
>> >> ld: symbol(s) not found for architecture x86_64
>> >> collect2: ld returned 1 exit status
>> >
>> > This is on OSX 10.8.5, where gcc --version gives me
>> >> i686-apple-darwin11-llvm-gcc-4.2 (GCC) 4.2.1 (Based on Apple Inc.
>> build 5658) (LLVM build 2336.11.00)
>> >
>> > I get the impression that this commit is related. Is it the case that
>> > Apple switched from gcc to clang recently? Could that be why
>> > ___builtin__clear_cache is missing?
>> >
>> > I'm sorry, I don't really know anything about the runtime system, so
>> > am kind of stuck.
>> >
>> >
>> --SNIP--
>> _______________________________________________
>> 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/20131126/07646348/attachment.html>

From amos.robinson at gmail.com  Tue Nov 26 05:30:53 2013
From: amos.robinson at gmail.com (Amos Robinson)
Date: Tue, 26 Nov 2013 16:30:53 +1100
Subject: Link error with head Re: [commit: ghc] master: GHCi: Properly
 generate jump code for ARM (#8380) (5bab1a5)
In-Reply-To: <CAHYVw0wwg8RX6NHSfvXKNQNGU8K-J-FbpBuef386XCpCqezWgA@mail.gmail.com>
References: <CAKFe=dX0NFVzMCfORLJQuUFmMFRWE33NGSP1WAnY0-YLFMJBUQ@mail.gmail.com>
 <CAKFe=dVssv4WTTQGKCszCDtBSmUbNHbs6iZxnpQx1MREtLJrNA@mail.gmail.com>
 <CAHYVw0wOegdB-eBj4=+t15DSO_NcGXf0J33BpkC+iCv_im1gtg@mail.gmail.com>
 <CAHYVw0wwg8RX6NHSfvXKNQNGU8K-J-FbpBuef386XCpCqezWgA@mail.gmail.com>
Message-ID: <CAKFe=dVY=E26VjbrNQP4k9YnQm2jTUpwHxLn2Zx5TWnkVs+vpQ@mail.gmail.com>

Thanks so much, Carter.

What I'm still confused about is this: I was able to build stage 1 and
then build stage 2 using stage 1. However, if I try building anything
with either stage, it won't link. How was it able to link stage 2?

On Tue, Nov 26, 2013 at 4:27 PM, Carter Schonwald
<carter.schonwald at gmail.com> wrote:
> I'll cook up a patch and post it to trac in the next hour.
>
>
> On Tuesday, November 26, 2013, Carter Schonwald wrote:
>>
>> It's because you're using GCC 4.2 on your Mac.  It's not in GCC till 4.3.
>>
>> But should be cppd so that it's not used on x86 architectures so that this
>> use doesn't happen
>>
>> On Monday, November 25, 2013, Amos Robinson wrote:
>>>
>>> Sorry for the noise, it turns out there's already a trac ticket:
>>> https://ghc.haskell.org/trac/ghc/ticket/8561
>>> (I didn't find it because I was searching for ___builtin? instead of
>>> __builtin!)
>>>
>>> On Tue, Nov 26, 2013 at 3:39 PM, Amos Robinson <amos.robinson at gmail.com>
>>> wrote:
>>> > Hi,
>>> > I'm having trouble linking with head:
>>> >
>>> >> [1 of 1] Compiling Main             ( bindisttest/HelloWorld.lhs,
>>> >> bindisttest/HelloWorld.o )
>>> >> Linking bindisttest/HelloWorld ...
>>> >> Undefined symbols for architecture x86_64:
>>> >>   "___builtin___clear_cache", referenced from:
>>> >>      _flushExec in libHSrts.a(Storage.o)
>>> >> ld: symbol(s) not found for architecture x86_64
>>> >> collect2: ld returned 1 exit status
>>> >
>>> > This is on OSX 10.8.5, where gcc --version gives me
>>> >> i686-apple-darwin11-llvm-gcc-4.2 (GCC) 4.2.1 (Based on Apple Inc.
>>> >> build 5658) (LLVM build 2336.11.00)
>>> >
>>> > I get the impression that this commit is related. Is it the case that
>>> > Apple switched from gcc to clang recently? Could that be why
>>> > ___builtin__clear_cache is missing?
>>> >
>>> > I'm sorry, I don't really know anything about the runtime system, so
>>> > am kind of stuck.
>>> >
>>> >
>>> --SNIP--
>>> _______________________________________________
>>> ghc-devs mailing list
>>> ghc-devs at haskell.org
>>> http://www.haskell.org/mailman/listinfo/ghc-devs

From carter.schonwald at gmail.com  Tue Nov 26 05:48:01 2013
From: carter.schonwald at gmail.com (Carter Schonwald)
Date: Tue, 26 Nov 2013 00:48:01 -0500
Subject: Link error with head Re: [commit: ghc] master: GHCi: Properly
 generate jump code for ARM (#8380) (5bab1a5)
In-Reply-To: <CAKFe=dVY=E26VjbrNQP4k9YnQm2jTUpwHxLn2Zx5TWnkVs+vpQ@mail.gmail.com>
References: <CAKFe=dX0NFVzMCfORLJQuUFmMFRWE33NGSP1WAnY0-YLFMJBUQ@mail.gmail.com>
 <CAKFe=dVssv4WTTQGKCszCDtBSmUbNHbs6iZxnpQx1MREtLJrNA@mail.gmail.com>
 <CAHYVw0wOegdB-eBj4=+t15DSO_NcGXf0J33BpkC+iCv_im1gtg@mail.gmail.com>
 <CAHYVw0wwg8RX6NHSfvXKNQNGU8K-J-FbpBuef386XCpCqezWgA@mail.gmail.com>
 <CAKFe=dVY=E26VjbrNQP4k9YnQm2jTUpwHxLn2Zx5TWnkVs+vpQ@mail.gmail.com>
Message-ID: <CAHYVw0yfHuRJws3PtF2oDpovrc_Jh5V3MHzqcDSG162SWGOzfg@mail.gmail.com>

No clue.  I'll find out once I get on my computer.   I think Mebe because
stage 1 has no ghci? Pure ignorant speculation mind you.  Please  be sure
to test the fix once I put it on trac (I'll test too of course. )

On Tuesday, November 26, 2013, Amos Robinson wrote:

> Thanks so much, Carter.
>
> What I'm still confused about is this: I was able to build stage 1 and
> then build stage 2 using stage 1. However, if I try building anything
> with either stage, it won't link. How was it able to link stage 2?
>
> On Tue, Nov 26, 2013 at 4:27 PM, Carter Schonwald
> <carter.schonwald at gmail.com <javascript:;>> wrote:
> > I'll cook up a patch and post it to trac in the next hour.
> >
> >
> > On Tuesday, November 26, 2013, Carter Schonwald wrote:
> >>
> >> It's because you're using GCC 4.2 on your Mac.  It's not in GCC till
> 4.3.
> >>
> >> But should be cppd so that it's not used on x86 architectures so that
> this
> >> use doesn't happen
> >>
> >> On Monday, November 25, 2013, Amos Robinson wrote:
> >>>
> >>> Sorry for the noise, it turns out there's already a trac ticket:
> >>> https://ghc.haskell.org/trac/ghc/ticket/8561
> >>> (I didn't find it because I was searching for ___builtin? instead of
> >>> __builtin!)
> >>>
> >>> On Tue, Nov 26, 2013 at 3:39 PM, Amos Robinson <
> amos.robinson at gmail.com <javascript:;>>
> >>> wrote:
> >>> > Hi,
> >>> > I'm having trouble linking with head:
> >>> >
> >>> >> [1 of 1] Compiling Main             ( bindisttest/HelloWorld.lhs,
> >>> >> bindisttest/HelloWorld.o )
> >>> >> Linking bindisttest/HelloWorld ...
> >>> >> Undefined symbols for architecture x86_64:
> >>> >>   "___builtin___clear_cache", referenced from:
> >>> >>      _flushExec in libHSrts.a(Storage.o)
> >>> >> ld: symbol(s) not found for architecture x86_64
> >>> >> collect2: ld returned 1 exit status
> >>> >
> >>> > This is on OSX 10.8.5, where gcc --version gives me
> >>> >> i686-apple-darwin11-llvm-gcc-4.2 (GCC) 4.2.1 (Based on Apple Inc.
> >>> >> build 5658) (LLVM build 2336.11.00)
> >>> >
> >>> > I get the impression that this commit is related. Is it the case that
> >>> > Apple switched from gcc to clang recently? Could that be why
> >>> > ___builtin__clear_cache is missing?
> >>> >
> >>> > I'm sorry, I don't really know anything about the runtime system, so
> >>> > am kind of stuck.
> >>> >
> >>> >
> >>> --SNIP--
> >>> _______________________________________________
> >>> 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/20131126/d6a2db0a/attachment.html>

From carter.schonwald at gmail.com  Tue Nov 26 08:36:49 2013
From: carter.schonwald at gmail.com (Carter Schonwald)
Date: Tue, 26 Nov 2013 03:36:49 -0500
Subject: Link error with head Re: [commit: ghc] master: GHCi: Properly
 generate jump code for ARM (#8380) (5bab1a5)
In-Reply-To: <CAHYVw0yfHuRJws3PtF2oDpovrc_Jh5V3MHzqcDSG162SWGOzfg@mail.gmail.com>
References: <CAKFe=dX0NFVzMCfORLJQuUFmMFRWE33NGSP1WAnY0-YLFMJBUQ@mail.gmail.com>
 <CAKFe=dVssv4WTTQGKCszCDtBSmUbNHbs6iZxnpQx1MREtLJrNA@mail.gmail.com>
 <CAHYVw0wOegdB-eBj4=+t15DSO_NcGXf0J33BpkC+iCv_im1gtg@mail.gmail.com>
 <CAHYVw0wwg8RX6NHSfvXKNQNGU8K-J-FbpBuef386XCpCqezWgA@mail.gmail.com>
 <CAKFe=dVY=E26VjbrNQP4k9YnQm2jTUpwHxLn2Zx5TWnkVs+vpQ@mail.gmail.com>
 <CAHYVw0yfHuRJws3PtF2oDpovrc_Jh5V3MHzqcDSG162SWGOzfg@mail.gmail.com>
Message-ID: <CAHYVw0xHuvEj1zuyv6qUMnJoFYhE2fDU0u1tkG2guB_BzRaFmQ@mail.gmail.com>

Austin indicates he's got a fix already on his merge queue,
in the mean time just delete the offending code (if you're on an x86/ 64
system) and the build should work


On Tue, Nov 26, 2013 at 12:48 AM, Carter Schonwald <
carter.schonwald at gmail.com> wrote:

> No clue.  I'll find out once I get on my computer.   I think Mebe because
> stage 1 has no ghci? Pure ignorant speculation mind you.  Please  be sure
> to test the fix once I put it on trac (I'll test too of course. )
>
>
> On Tuesday, November 26, 2013, Amos Robinson wrote:
>
>> Thanks so much, Carter.
>>
>> What I'm still confused about is this: I was able to build stage 1 and
>> then build stage 2 using stage 1. However, if I try building anything
>> with either stage, it won't link. How was it able to link stage 2?
>>
>> On Tue, Nov 26, 2013 at 4:27 PM, Carter Schonwald
>> <carter.schonwald at gmail.com> wrote:
>> > I'll cook up a patch and post it to trac in the next hour.
>> >
>> >
>> > On Tuesday, November 26, 2013, Carter Schonwald wrote:
>> >>
>> >> It's because you're using GCC 4.2 on your Mac.  It's not in GCC till
>> 4.3.
>> >>
>> >> But should be cppd so that it's not used on x86 architectures so that
>> this
>> >> use doesn't happen
>> >>
>> >> On Monday, November 25, 2013, Amos Robinson wrote:
>> >>>
>> >>> Sorry for the noise, it turns out there's already a trac ticket:
>> >>> https://ghc.haskell.org/trac/ghc/ticket/8561
>> >>> (I didn't find it because I was searching for ___builtin? instead of
>> >>> __builtin!)
>> >>>
>> >>> On Tue, Nov 26, 2013 at 3:39 PM, Amos Robinson <
>> amos.robinson at gmail.com>
>> >>> wrote:
>> >>> > Hi,
>> >>> > I'm having trouble linking with head:
>> >>> >
>> >>> >> [1 of 1] Compiling Main             ( bindisttest/HelloWorld.lhs,
>> >>> >> bindisttest/HelloWorld.o )
>> >>> >> Linking bindisttest/HelloWorld ...
>> >>> >> Undefined symbols for architecture x86_64:
>> >>> >>   "___builtin___clear_cache", referenced from:
>> >>> >>      _flushExec in libHSrts.a(Storage.o)
>> >>> >> ld: symbol(s) not found for architecture x86_64
>> >>> >> collect2: ld returned 1 exit status
>> >>> >
>> >>> > This is on OSX 10.8.5, where gcc --version gives me
>> >>> >> i686-apple-darwin11-llvm-gcc-4.2 (GCC) 4.2.1 (Based on Apple Inc.
>> >>> >> build 5658) (LLVM build 2336.11.00)
>> >>> >
>> >>> > I get the impression that this commit is related. Is it the case
>> that
>> >>> > Apple switched from gcc to clang recently? Could that be why
>> >>> > ___builtin__clear_cache is missing?
>> >>> >
>> >>> > I'm sorry, I don't really know anything about the runtime system, so
>> >>> > am kind of stuck.
>> >>> >
>> >>> >
>> >>> --SNIP--
>> >>> _______________________________________________
>> >>> 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/20131126/1c05e4fa/attachment-0001.html>

From simonpj at microsoft.com  Tue Nov 26 11:02:21 2013
From: simonpj at microsoft.com (Simon Peyton-Jones)
Date: Tue, 26 Nov 2013 11:02:21 +0000
Subject: Cannot instantiate unification variable
In-Reply-To: <20131126.114437.1254426457474039887.kazu@iij.ad.jp>
References: <20131126.114437.1254426457474039887.kazu@iij.ad.jp>
Message-ID: <59543203684B2244980D7E4057D5FBC1486CE526@DB3EX14MBXC308.europe.corp.microsoft.com>

Ah.  Good point. I've made a simplified test case

https://ghc.haskell.org/trac/ghc/ticket/8565

Thanks

Simon

| -----Original Message-----
| From: ghc-devs [mailto:ghc-devs-bounces at haskell.org] On Behalf Of Kazu
| Yamamoto
| Sent: 26 November 2013 02:45
| To: ghc-devs at haskell.org
| Subject: Cannot instantiate unification variable
| 
| Hi,
| 
| Recent GHC head on 32bit Linux cannot build conduit-1.0.9.2. (See the
| attached log.)  A while ago, GHC head on 32bit Linux could build it.
| The same GHC head on 64bit Linux can build it.
| 
| Michael Snoyman suggested me to add ImpredicativeTypes. When I added
| it to the Internal.hs, GHC head on 32bit Linux can build it.  And he
| said to other released GHCs can build it. Actually, GHC 7.4.2 on
| 32bit Linux can build it.
| 
| He believes that this is a bug of GHC head (on 32bit Linux). Any
| information?
| 
| Note that conduit-1.0.9.3 already includes ImpredicativeTypes.
| 
| --Kazu
| 
| Building conduit-1.0.9.2...
| Preprocessing library conduit-1.0.9.2...
| [2 of 8] Compiling Data.Conduit.Internal ( Data/Conduit/Internal.hs,
| dist/build/Dat
| a/Conduit/Internal.o )
| 
| Data/Conduit/Internal.hs:211:105:
|     Cannot instantiate unification variable ?b0?
|     with a type involving foralls:
|       (forall a. m1 a -> n1 a)
|       -> ConduitM i o m1 b1 -> ConduitM i o n1 b1
|       Perhaps you want ImpredicativeTypes
|     In the expression:
|         GHC.Exts.coerce
|           (hoist ::
|              (forall (a :: *). m a -> n a)
|              -> Pipe i i o () m b -> Pipe i i o () n b) ::
|           forall (m :: * -> *) (b :: *) (n :: * -> *). Monad m =>
|           (forall (a :: *). m a -> n a)
|           -> ConduitM i o m b -> ConduitM i o n b
|     In an equation for ?hoist?:
|         hoist
|           = GHC.Exts.coerce
|               (hoist ::
|                  (forall (a :: *). m a -> n a)
|                  -> Pipe i i o () m b -> Pipe i i o () n b) ::
|               forall (m :: * -> *) (b :: *) (n :: * -> *). Monad m =>
|               (forall (a :: *). m a -> n a)
|               -> ConduitM i o m b -> ConduitM i o n b
| _______________________________________________
| ghc-devs mailing list
| ghc-devs at haskell.org
| http://www.haskell.org/mailman/listinfo/ghc-devs

From ggreif at gmail.com  Wed Nov 27 22:15:29 2013
From: ggreif at gmail.com (Gabor Greif)
Date: Wed, 27 Nov 2013 23:15:29 +0100
Subject: RTS warnings
Message-ID: <CAK-hX0krhbdxHwf4kMWS6r_vthdBffAE1g6NYm3N0A9WNLZzHg@mail.gmail.com>

Hi all!

I spottes these warnings in today's

   $ make INTEGER_LIBRARY=integer-simple V=0

build:

rts/Stats.c: In function 'stat_exit':

rts/Stats.c:695:0:
     warning: format '%16zu' expects type 'size_t', but argument 2 has
type 'unsigned int'

rts/sm/Storage.c: In function 'flushExec':

rts/sm/Storage.c:1294:0:
     warning: implicit declaration of function '__builtin___clear_cache'

rts/sm/Storage.c:1294:0:
     warning: nested extern declaration of '__builtin___clear_cache'


this is my "GCC":

ggreif$ gcc --version
i686-apple-darwin11-llvm-gcc-4.2 (GCC) 4.2.1 (Based on Apple Inc.
build 5658) (LLVM build 2336.11.00)
Copyright (C) 2007 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.  There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

Cheers,

    Gabor

PS: there is also this low-hanging fruit:

libraries/containers/Data/IntSet/Base.hs:1196:17: Warning:
    In the use of 'bitSize' (imported from Data.Bits):
    Deprecated: "Use bitSizeMaybe or finiteBitSize instead"

From hvriedel at gmail.com  Wed Nov 27 22:20:35 2013
From: hvriedel at gmail.com (Herbert Valerio Riedel)
Date: Wed, 27 Nov 2013 23:20:35 +0100
Subject: RTS warnings
In-Reply-To: <CAK-hX0krhbdxHwf4kMWS6r_vthdBffAE1g6NYm3N0A9WNLZzHg@mail.gmail.com>
 (Gabor Greif's message of "Wed, 27 Nov 2013 23:15:29 +0100")
References: <CAK-hX0krhbdxHwf4kMWS6r_vthdBffAE1g6NYm3N0A9WNLZzHg@mail.gmail.com>
Message-ID: <87a9gpqyfg.fsf@gmail.com>

On 2013-11-27 at 23:15:29 +0100, Gabor Greif wrote:

[...]

> PS: there is also this low-hanging fruit:
>
> libraries/containers/Data/IntSet/Base.hs:1196:17: Warning:
>     In the use of 'bitSize' (imported from Data.Bits):
>     Deprecated: "Use bitSizeMaybe or finiteBitSize instead"

fyi,

https://github.com/haskell/containers/commit/501fa5b32c

From kazu at iij.ad.jp  Thu Nov 28 03:43:29 2013
From: kazu at iij.ad.jp (Kazu Yamamoto (=?iso-2022-jp?B?GyRCOzNLXE9CSScbKEI=?=))
Date: Thu, 28 Nov 2013 12:43:29 +0900 (JST)
Subject: build errors
Message-ID: <20131128.124329.1368767284961267993.kazu@iij.ad.jp>

Hi,

I cannot build GHC head on Linux and Mac (Mavericks) today:

compiler/typecheck/TcEvidence.lhs:152:16:
    Not in scope: data constructor `ASSERT2'

compiler/typecheck/TcEvidence.lhs:174:5:
    Not in scope: data constructor `ASSERT2'

compiler/typecheck/TcEvidence.lhs:489:15:
    Not in scope: data constructor `ASSERT2'

compiler/typecheck/TcEvidence.lhs:712:5:
    Not in scope: data constructor `ASSERT2'
make[1]: *** [compiler/stage1/build/TcEvidence.o] Error 1
make[1]: *** Waiting for unfinished jobs....
make: *** [all] Error 2

--Kazu

From mail at joachim-breitner.de  Thu Nov 28 08:23:50 2013
From: mail at joachim-breitner.de (Joachim Breitner)
Date: Thu, 28 Nov 2013 08:23:50 +0000
Subject: build errors
In-Reply-To: <20131128.124329.1368767284961267993.kazu@iij.ad.jp>
References: <20131128.124329.1368767284961267993.kazu@iij.ad.jp>
Message-ID: <1385627030.2465.3.camel@kirk>

Hi,

Am Donnerstag, den 28.11.2013, 12:43 +0900 schrieb Kazu Yamamoto:
> I cannot build GHC head on Linux and Mac (Mavericks) today:
> 
> compiler/typecheck/TcEvidence.lhs:152:16:
>     Not in scope: data constructor `ASSERT2'
> 
> compiler/typecheck/TcEvidence.lhs:174:5:
>     Not in scope: data constructor `ASSERT2'
> 
> compiler/typecheck/TcEvidence.lhs:489:15:
>     Not in scope: data constructor `ASSERT2'
> 
> compiler/typecheck/TcEvidence.lhs:712:5:
>     Not in scope: data constructor `ASSERT2'
> make[1]: *** [compiler/stage1/build/TcEvidence.o] Error 1
> make[1]: *** Waiting for unfinished jobs....
> make: *** [all] Error 2

these were added by me, but these are CPP macros that should be always
defined (in HsVersions.h). Also, the problem is not a general one, as
you can see on https://travis-ci.org/nomeata/ghc-complete/builds)

Do you have any idea what might be unusual about your CPP setup?

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: 198 bytes
Desc: This is a digitally signed message part
URL: <http://www.haskell.org/pipermail/ghc-devs/attachments/20131128/29593162/attachment.sig>

From mail at joachim-breitner.de  Thu Nov 28 09:08:13 2013
From: mail at joachim-breitner.de (Joachim Breitner)
Date: Thu, 28 Nov 2013 09:08:13 +0000
Subject: worker-wrapper correctness
Message-ID: <1385629693.2465.33.camel@kirk>

Hi,

I first planned to post this to
https://ghc.haskell.org/trac/ghc/ticket/1600 but it might be of wider
interest, and is not only related to CPR.

SPJ pointed me to this? paper by Graham Hutton (thanks for that). It
lists three sufficient conditions for the w/w-wrapper to be semantically
correct:

        (1) wrap ? unwrap = id
        (2) wrap ? unwrap ? body = body
        (3) fix (wrap ? unwrap ? body) = fix body
        
The first one is often not true when we do w/w in GHC. The third one
seems to be out of reach: Arguing about a recursive function in this way
smells like solving the halting problem. So it seems that we should be
aiming for

        (2) wrap ? unwrap ? body = body

With this in mind, setting the CPR info of recursive things to ?, i.e.
?we don?t know anything? _when analyzing their RHS_ should do the right
thing: If we assume nothing about the argument of `body`, the result
will hold for all, which precisely is `wrap ? unwrap ? body = body`.

And this should be the case not only for CPR, but for anything that does
a w/w-transformation, i.e. Demand analysis as well.

But what about strictness analysis? Clearly, for

        f :: Int -> Int -> Int
        f n m = if n == 0 then m else f (n-1) m
        
we want to know (as we do in 7.6. and in HEAD) that it is strict in m...

Interesting fact here: GHC-7.6 will find this worker signature

    wf :: Int# -> Int -> Int

(which is compatible with condition (2)), but GHC HEAD will do

    wf :: Int# -> Int# -> Int#

where equation (2) is no longer holds. In this case (3) happens to hold
(at least wrt to a semantics that does not distinguish non-termination
of other kinds of ?).


Conclusion: The correctness of GHC?s w/w-transformation is currently not
formally well supported, and it only works due to delicate and
non-obvious? interaction between the analysis and the transformation
(see comment 20 of #1600 for an example how easily it breaks). But if we
systematically ensure the correctness, by always guaranteeing (2), we
are losing existing chances for optimization.


Some more less consistent thoughts:

There seems to be a conceptual difference between the CPR
w/w-transformation and the others: Unboxing arguments pulls work out of
the worker to be done _before_ it is being called. Clearly, this will
never make the recursive call to the work diverge, unless it would
diverge anyways. And if the work pulled out diverges (e.g. if m =
undefined in the example above), then either the worker would have
diverged (but that is fine) or, assuming the analysis is correct, would
have performed the work. So for these transformations it is ok to use
the full information in the recursive case.

But the CPR transformation is different: The w/w transformation forces
the evaluation of the result of the recursive call and in that sense
moves work into it. And if this again triggers work to be moved into the
next recursive calls, we can cause divergence.

So by this handwavy argument, we are fine for unboxing arguments and
strictness analysis, but for CPR we really should forget what we know
about the f when analyzing f?s body.



Thanks for your attention,
Joachim

? http://www.cs.nott.ac.uk/~gmh/wrapper.pdf
? to me at least ? I might be missing something
-- 
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: 198 bytes
Desc: This is a digitally signed message part
URL: <http://www.haskell.org/pipermail/ghc-devs/attachments/20131128/b65888ee/attachment.sig>

From marlowsd at gmail.com  Thu Nov 28 09:11:50 2013
From: marlowsd at gmail.com (Simon Marlow)
Date: Thu, 28 Nov 2013 09:11:50 +0000
Subject: Building GHC head with clang on Mavericks
In-Reply-To: <20131121.155430.37558810975251514.kazu@iij.ad.jp>
References: <CAFXb89BMkFJY8xfms8Laz_cE5yEvMATbZj6gDMFajdFC9mybJQ@mail.gmail.com>
 <20131121.142556.471882438928640756.kazu@iij.ad.jp>
 <CAFXb89CCv4GKhJQR5WRh6UTdgRXcvvoSowH03HCa9s4DeQ3C-g@mail.gmail.com>
 <20131121.155430.37558810975251514.kazu@iij.ad.jp>
Message-ID: <529708D6.9030009@gmail.com>

On 21/11/13 06:54, Kazu Yamamoto (????) wrote:
>> I think he has forgotten, yes. But yeah do send the pull requests anyway,
>> my last set got merged in.
>
> Done:
> 	https://github.com/simonmar/happy/pull/13
> 	https://github.com/simonmar/alex/pull/38

I've merged these and made new releases of Happy (1.19.2) and Alex (3.1.3).

Cheers,
	Simon



From lukexipd at gmail.com  Thu Nov 28 10:44:40 2013
From: lukexipd at gmail.com (Luke Iannini)
Date: Thu, 28 Nov 2013 03:44:40 -0700
Subject: build errors
In-Reply-To: <1385627030.2465.3.camel@kirk>
References: <20131128.124329.1368767284961267993.kazu@iij.ad.jp>
 <1385627030.2465.3.camel@kirk>
Message-ID: <CAGo83CjEzrm79Jm=ZAuF5-C08YjXpy8yShiTBFF33oX_pGQ5-w@mail.gmail.com>

Hi guys,

This is more clang CPP funniness ? I've patched this kind of thing before
(e.g.
https://ghc.haskell.org/trac/ghc/attachment/ticket/8445/fix-xcode5-cpp-errors.patch).
Basically clang CPP can't handle the space before the open-paren, so it
needs to be removed to be recognized and processed as a macro.

Cheers
Luke


On Thu, Nov 28, 2013 at 1:23 AM, Joachim Breitner
<mail at joachim-breitner.de>wrote:

> Hi,
>
> Am Donnerstag, den 28.11.2013, 12:43 +0900 schrieb Kazu Yamamoto:
> > I cannot build GHC head on Linux and Mac (Mavericks) today:
> >
> > compiler/typecheck/TcEvidence.lhs:152:16:
> >     Not in scope: data constructor `ASSERT2'
> >
> > compiler/typecheck/TcEvidence.lhs:174:5:
> >     Not in scope: data constructor `ASSERT2'
> >
> > compiler/typecheck/TcEvidence.lhs:489:15:
> >     Not in scope: data constructor `ASSERT2'
> >
> > compiler/typecheck/TcEvidence.lhs:712:5:
> >     Not in scope: data constructor `ASSERT2'
> > make[1]: *** [compiler/stage1/build/TcEvidence.o] Error 1
> > make[1]: *** Waiting for unfinished jobs....
> > make: *** [all] Error 2
>
> these were added by me, but these are CPP macros that should be always
> defined (in HsVersions.h). Also, the problem is not a general one, as
> you can see on https://travis-ci.org/nomeata/ghc-complete/builds)
>
> Do you have any idea what might be unusual about your CPP setup?
>
> 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/20131128/6c01c4a8/attachment.html>

From marlowsd at gmail.com  Thu Nov 28 12:30:49 2013
From: marlowsd at gmail.com (Simon Marlow)
Date: Thu, 28 Nov 2013 12:30:49 +0000
Subject: [commit: testsuite] master: Higher residency in Haddock (15c09a3)
In-Reply-To: <20131122164301.BBD562406B@ghc.haskell.org>
References: <20131122164301.BBD562406B@ghc.haskell.org>
Message-ID: <52973779.1000600@gmail.com>

On 22/11/13 16:43, git at git.haskell.org wrote:
> Repository : ssh://git at git.haskell.org/testsuite
>
> On branch  : master
> Link       : http://ghc.haskell.org/trac/ghc/changeset/15c09a332cd24e5d6c4c9a0ede9b151c9a095f66/testsuite
>
>> ---------------------------------------------------------------
>
> commit 15c09a332cd24e5d6c4c9a0ede9b151c9a095f66
> Author: Simon Peyton Jones <simonpj at microsoft.com>
> Date:   Fri Nov 22 16:42:43 2013 +0000
>
>      Higher residency in Haddock
>
>      I think there really is a slight worsening in the situation here, but
>      it needs someone to build a profiled compiler and take a proper look.

Maybe make a ticket for the next milestone then?

I'm getting slightly worried that we keep pushing these performance 
bounds up without really investigating why.  The great thing about the 
perf tests is that they catch something immediately, rather than us 
having to bisect it or do lengthy profiling investigations later.

What should we do about this?  I realise it's a pain when you've got a 
working patch and the only thing holding it up is some random perf test 
that seems to be completely unrelated.  Let's have a brainstorm on how 
we can improve things.  What tools can we build to help?  Maybe this is 
a good way that new contributors could get involved.

Here's one idea off the top of my head: let's make a way to take heap 
samples at deterministic points during compilation, say between phases. 
  Then make a tool to compare profiles made this way, so that we can say 
what changed between two compiler versions.  I'm pretty sure this will 
spot leaks pretty quickly, and tell you something about what is leaking 
(which constructors).

I think we've accrued some bloat recently.  I had to increase the memory 
in my VM because it ceased to be able to build HEAD at some point.

Cheers,
Simon


From simonpj at microsoft.com  Thu Nov 28 12:42:06 2013
From: simonpj at microsoft.com (Simon Peyton-Jones)
Date: Thu, 28 Nov 2013 12:42:06 +0000
Subject: [commit: testsuite] master: Update some perf results for master
 (4afbacc)
In-Reply-To: <20131128123602.D5E5E2406B@ghc.haskell.org>
References: <20131128123602.D5E5E2406B@ghc.haskell.org>
Message-ID: <59543203684B2244980D7E4057D5FBC1486D42C6@DB3EX14MBXC308.europe.corp.microsoft.com>

Wait. Are you really increasing "bytes allocated" from 97M to 237M?  That's a big change, and in an important number.  Do you know why?

Simon

| -----Original Message-----
| From: ghc-commits [mailto:ghc-commits-bounces at haskell.org] On Behalf Of
| git at git.haskell.org
| Sent: 28 November 2013 12:36
| To: ghc-commits at haskell.org
| Subject: [commit: testsuite] master: Update some perf results for
| master (4afbacc)
| 
| Repository : ssh://git at git.haskell.org/testsuite
| 
| On branch  : master
| Link       :
| http://ghc.haskell.org/trac/ghc/changeset/4afbacc299d843eb632df1f71eee2
| c91746c85a8/testsuite
| 
| >---------------------------------------------------------------
| 
| commit 4afbacc299d843eb632df1f71eee2c91746c85a8
| Author: Joachim Breitner <mail at joachim-breitner.de>
| Date:   Thu Nov 28 12:36:15 2013 +0000
| 
|     Update some perf results for master
| 
| 
| >---------------------------------------------------------------
| 
| 4afbacc299d843eb632df1f71eee2c91746c85a8
|  tests/perf/compiler/all.T    |   11 ++++++-----
|  tests/perf/space_leaks/all.T |    2 +-
|  2 files changed, 7 insertions(+), 6 deletions(-)
| 
| diff --git a/tests/perf/compiler/all.T b/tests/perf/compiler/all.T
| index a580bf9..759b5d0 100644
| --- a/tests/perf/compiler/all.T
| +++ b/tests/perf/compiler/all.T
| @@ -344,10 +344,11 @@ test('T5837',
|  test('T6048',
|       [ only_ways(['optasm']),
|        compiler_stats_num_field('bytes allocated',
| -          [(wordsize(32), 48887164, 10),
| -            # prev:       38000000 (x86/Linux)
| -            # 2012-10-08: 48887164 (x86/Linux)
| -           (wordsize(64), 97247032, 10)])
| -             # 18/09/2012 97247032 amd64/Linux
| +          [(wordsize(32),   48887164, 10),
| +            # prev:         38000000 (x86/Linux)
| +            # 2012-10-08:   48887164 (x86/Linux)
| +           (wordsize(64),  237077056, 10)])
| +             # 18/09/2012   97247032 amd64/Linux
| +	     # 2013-11-26: 237077056 amd64/Linux
|        ],
|        compile,[''])
| diff --git a/tests/perf/space_leaks/all.T
| b/tests/perf/space_leaks/all.T
| index a1fd641..ac60c8f 100644
| --- a/tests/perf/space_leaks/all.T
| +++ b/tests/perf/space_leaks/all.T
| @@ -6,7 +6,7 @@ test('space_leak_001',
|       #           5 (x86/Linux)
|       [stats_num_field('peak_megabytes_allocated', (4, 1)),
|        stats_num_field('max_bytes_used',
| -          [(wordsize(64), 440000, 10),
| +          [(wordsize(64), 440000, 15),
|                          # 440224 (amd64/Linux)
|                          # 417016 (x86/OS X)
|                          # 415672 (x86/Windows)
| 
| _______________________________________________
| ghc-commits mailing list
| ghc-commits at haskell.org
| http://www.haskell.org/mailman/listinfo/ghc-commits

From simonpj at microsoft.com  Thu Nov 28 12:56:25 2013
From: simonpj at microsoft.com (Simon Peyton-Jones)
Date: Thu, 28 Nov 2013 12:56:25 +0000
Subject: [commit: testsuite] master: Higher residency in Haddock (15c09a3)
In-Reply-To: <52973779.1000600@gmail.com>
References: <20131122164301.BBD562406B@ghc.haskell.org>
 <52973779.1000600@gmail.com>
Message-ID: <59543203684B2244980D7E4057D5FBC1486D437A@DB3EX14MBXC308.europe.corp.microsoft.com>

I agree.  The most direct approach is for someone to build profiled compilers and get some sense of where the space and time is going in a run of Haddock, or GHC.  

I would be thrilled if someone felt able to do some forensic performance comparison between different versions of GHC and/or Haddock. Would anyone like to do that?  There is almost certainly plenty of low-hanging fruit -- you might speed up GHC by 20% and everyone would be Very Happy.

On particular compilation of the Haddock tests is that they embody two distinct sources of variation: 
  1.  Cabal (the source code examined by the run of Haddock
      has more/different code
  2.  Haddock itself may have gotten slower/fatter

(1) is a motivation-sapping problem.  Performance tests should have stable input data.

Better tools would certainly help. If we are to retain memory-size numbers, maybe the tests should always be run in such a way that the numbers are stable and predictable.

The other real difficulty is this: if space usage really does go up by 10% in an extremely large and complicated program like Haddock or GHC, it can be jolly hard to nail down what's causing it.  If it goes through the roof, it's (relatively) easy to find.  If bytes-allocated goes up it's easy to find (use -ticky). But a 10% increase in space usage is always going be hard.

Simon



| -----Original Message-----
| From: ghc-devs [mailto:ghc-devs-bounces at haskell.org] On Behalf Of Simon
| Marlow
| Sent: 28 November 2013 12:31
| To: ghc-devs at haskell.org
| Subject: Re: [commit: testsuite] master: Higher residency in Haddock
| (15c09a3)
| 
| On 22/11/13 16:43, git at git.haskell.org wrote:
| > Repository : ssh://git at git.haskell.org/testsuite
| >
| > On branch  : master
| > Link       :
| http://ghc.haskell.org/trac/ghc/changeset/15c09a332cd24e5d6c4c9a0ede9b1
| 51c9a095f66/testsuite
| >
| >> ---------------------------------------------------------------
| >
| > commit 15c09a332cd24e5d6c4c9a0ede9b151c9a095f66
| > Author: Simon Peyton Jones <simonpj at microsoft.com>
| > Date:   Fri Nov 22 16:42:43 2013 +0000
| >
| >      Higher residency in Haddock
| >
| >      I think there really is a slight worsening in the situation
| here, but
| >      it needs someone to build a profiled compiler and take a proper
| look.
| 
| Maybe make a ticket for the next milestone then?
| 
| I'm getting slightly worried that we keep pushing these performance
| bounds up without really investigating why.  The great thing about the
| perf tests is that they catch something immediately, rather than us
| having to bisect it or do lengthy profiling investigations later.
| 
| What should we do about this?  I realise it's a pain when you've got a
| working patch and the only thing holding it up is some random perf test
| that seems to be completely unrelated.  Let's have a brainstorm on how
| we can improve things.  What tools can we build to help?  Maybe this is
| a good way that new contributors could get involved.
| 
| Here's one idea off the top of my head: let's make a way to take heap
| samples at deterministic points during compilation, say between phases.
|   Then make a tool to compare profiles made this way, so that we can
| say
| what changed between two compiler versions.  I'm pretty sure this will
| spot leaks pretty quickly, and tell you something about what is leaking
| (which constructors).
| 
| I think we've accrued some bloat recently.  I had to increase the
| memory
| in my VM because it ceased to be able to build HEAD at some point.
| 
| Cheers,
| Simon
| 
| _______________________________________________
| ghc-devs mailing list
| ghc-devs at haskell.org
| http://www.haskell.org/mailman/listinfo/ghc-devs

From mail at joachim-breitner.de  Thu Nov 28 13:20:10 2013
From: mail at joachim-breitner.de (Joachim Breitner)
Date: Thu, 28 Nov 2013 13:20:10 +0000
Subject: [commit: testsuite] master: Update some perf results for master
 (4afbacc)
In-Reply-To: <59543203684B2244980D7E4057D5FBC1486D42C6@DB3EX14MBXC308.europe.corp.microsoft.com>
References: <20131128123602.D5E5E2406B@ghc.haskell.org>
 <59543203684B2244980D7E4057D5FBC1486D42C6@DB3EX14MBXC308.europe.corp.microsoft.com>
Message-ID: <1385644810.2465.41.camel@kirk>

Hi,

Am Donnerstag, den 28.11.2013, 12:42 +0000 schrieb Simon Peyton-Jones:
> Wait. Are you really increasing "bytes allocated" from 97M to 237M?
> That's a big change, and in an important number.  Do you know why?

no; but this is master, not my branch, and it seems to be a test not run
by validate (which calls "make -C testsuite fast"), so I have to assume
it could be anything in the recent past.

If I get access to a fast machine to build stuff, I can try to bisect
it.

But that why we need a proper CI setup, which should then probably run
"./validate.sh --slow"! The test suite is only half as useful as it
could be if one first has to clean it up before one can reliably
investigate the effect of one own?s changes.

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: 198 bytes
Desc: This is a digitally signed message part
URL: <http://www.haskell.org/pipermail/ghc-devs/attachments/20131128/0807fbbd/attachment.sig>

From marlowsd at gmail.com  Thu Nov 28 13:22:19 2013
From: marlowsd at gmail.com (Simon Marlow)
Date: Thu, 28 Nov 2013 13:22:19 +0000
Subject: [commit: testsuite] master: Higher residency in Haddock (15c09a3)
In-Reply-To: <59543203684B2244980D7E4057D5FBC1486D437A@DB3EX14MBXC308.europe.corp.microsoft.com>
References: <20131122164301.BBD562406B@ghc.haskell.org>
 <52973779.1000600@gmail.com>
 <59543203684B2244980D7E4057D5FBC1486D437A@DB3EX14MBXC308.europe.corp.microsoft.com>
Message-ID: <5297438B.7030209@gmail.com>

On 28/11/13 12:56, Simon Peyton-Jones wrote:
> I agree.  The most direct approach is for someone to build profiled compilers and get some sense of where the space and time is going in a run of Haddock, or GHC.
>
> I would be thrilled if someone felt able to do some forensic performance comparison between different versions of GHC and/or Haddock. Would anyone like to do that?  There is almost certainly plenty of low-hanging fruit -- you might speed up GHC by 20% and everyone would be Very Happy.
>
> On particular compilation of the Haddock tests is that they embody two distinct sources of variation:
>    1.  Cabal (the source code examined by the run of Haddock
>        has more/different code
>    2.  Haddock itself may have gotten slower/fatter

Most of the cost in Haddock is in typechecking all the source code, 
which is done by GHC.  I think this is why we have perf tests for 
Haddock - they're GHC tests, kind-of.  The annoying thing about the 
Haddock perf tests is that they're difficult to re-run though.

> (1) is a motivation-sapping problem.  Performance tests should have stable input data.

Yes, that's not good.  Cabal changing is certainly a legitimate reason 
to bump the thresholds for the Haddock tests though.

> Better tools would certainly help. If we are to retain memory-size numbers, maybe the tests should always be run in such a way that the numbers are stable and predictable.

I've been thinking about this.  Just increasing the frequency of samples 
would help, but I think taking samples at deterministic points (like 
between phases) would help more.  It needs someone to add some support 
for this though, in the form of an API for heap sampling that we can 
call from Haskell.

Cheers,
Simon


> Simon
>
>
>
> | -----Original Message-----
> | From: ghc-devs [mailto:ghc-devs-bounces at haskell.org] On Behalf Of Simon
> | Marlow
> | Sent: 28 November 2013 12:31
> | To: ghc-devs at haskell.org
> | Subject: Re: [commit: testsuite] master: Higher residency in Haddock
> | (15c09a3)
> |
> | On 22/11/13 16:43, git at git.haskell.org wrote:
> | > Repository : ssh://git at git.haskell.org/testsuite
> | >
> | > On branch  : master
> | > Link       :
> | http://ghc.haskell.org/trac/ghc/changeset/15c09a332cd24e5d6c4c9a0ede9b1
> | 51c9a095f66/testsuite
> | >
> | >> ---------------------------------------------------------------
> | >
> | > commit 15c09a332cd24e5d6c4c9a0ede9b151c9a095f66
> | > Author: Simon Peyton Jones <simonpj at microsoft.com>
> | > Date:   Fri Nov 22 16:42:43 2013 +0000
> | >
> | >      Higher residency in Haddock
> | >
> | >      I think there really is a slight worsening in the situation
> | here, but
> | >      it needs someone to build a profiled compiler and take a proper
> | look.
> |
> | Maybe make a ticket for the next milestone then?
> |
> | I'm getting slightly worried that we keep pushing these performance
> | bounds up without really investigating why.  The great thing about the
> | perf tests is that they catch something immediately, rather than us
> | having to bisect it or do lengthy profiling investigations later.
> |
> | What should we do about this?  I realise it's a pain when you've got a
> | working patch and the only thing holding it up is some random perf test
> | that seems to be completely unrelated.  Let's have a brainstorm on how
> | we can improve things.  What tools can we build to help?  Maybe this is
> | a good way that new contributors could get involved.
> |
> | Here's one idea off the top of my head: let's make a way to take heap
> | samples at deterministic points during compilation, say between phases.
> |   Then make a tool to compare profiles made this way, so that we can
> | say
> | what changed between two compiler versions.  I'm pretty sure this will
> | spot leaks pretty quickly, and tell you something about what is leaking
> | (which constructors).
> |
> | I think we've accrued some bloat recently.  I had to increase the
> | memory
> | in my VM because it ceased to be able to build HEAD at some point.
> |
> | Cheers,
> | Simon
> |
> | _______________________________________________
> | ghc-devs mailing list
> | ghc-devs at haskell.org
> | http://www.haskell.org/mailman/listinfo/ghc-devs
>


From marlowsd at gmail.com  Thu Nov 28 13:36:15 2013
From: marlowsd at gmail.com (Simon Marlow)
Date: Thu, 28 Nov 2013 13:36:15 +0000
Subject: [commit: testsuite] master: Update some perf results for master
 (4afbacc)
In-Reply-To: <59543203684B2244980D7E4057D5FBC1486D42C6@DB3EX14MBXC308.europe.corp.microsoft.com>
References: <20131128123602.D5E5E2406B@ghc.haskell.org>
 <59543203684B2244980D7E4057D5FBC1486D42C6@DB3EX14MBXC308.europe.corp.microsoft.com>
Message-ID: <529746CF.5040402@gmail.com>

I now get:

update the test so that GHC doesn't regress again)
     Expected    bytes allocated: 237077056 +/-10%
     Lower bound bytes allocated: 213369350
     Upper bound bytes allocated: 260784762
     Actual      bytes allocated: 101150736

Joachim: if you're building with DEBUG, that will adversely affect the 
performance tests, so you probably shouldn't run those.

Cheers,
Simon

On 28/11/13 12:42, Simon Peyton-Jones wrote:
> Wait. Are you really increasing "bytes allocated" from 97M to 237M?  That's a big change, and in an important number.  Do you know why?
>
> Simon
>
> | -----Original Message-----
> | From: ghc-commits [mailto:ghc-commits-bounces at haskell.org] On Behalf Of
> | git at git.haskell.org
> | Sent: 28 November 2013 12:36
> | To: ghc-commits at haskell.org
> | Subject: [commit: testsuite] master: Update some perf results for
> | master (4afbacc)
> |
> | Repository : ssh://git at git.haskell.org/testsuite
> |
> | On branch  : master
> | Link       :
> | http://ghc.haskell.org/trac/ghc/changeset/4afbacc299d843eb632df1f71eee2
> | c91746c85a8/testsuite
> |
> | >---------------------------------------------------------------
> |
> | commit 4afbacc299d843eb632df1f71eee2c91746c85a8
> | Author: Joachim Breitner <mail at joachim-breitner.de>
> | Date:   Thu Nov 28 12:36:15 2013 +0000
> |
> |     Update some perf results for master
> |
> |
> | >---------------------------------------------------------------
> |
> | 4afbacc299d843eb632df1f71eee2c91746c85a8
> |  tests/perf/compiler/all.T    |   11 ++++++-----
> |  tests/perf/space_leaks/all.T |    2 +-
> |  2 files changed, 7 insertions(+), 6 deletions(-)
> |
> | diff --git a/tests/perf/compiler/all.T b/tests/perf/compiler/all.T
> | index a580bf9..759b5d0 100644
> | --- a/tests/perf/compiler/all.T
> | +++ b/tests/perf/compiler/all.T
> | @@ -344,10 +344,11 @@ test('T5837',
> |  test('T6048',
> |       [ only_ways(['optasm']),
> |        compiler_stats_num_field('bytes allocated',
> | -          [(wordsize(32), 48887164, 10),
> | -            # prev:       38000000 (x86/Linux)
> | -            # 2012-10-08: 48887164 (x86/Linux)
> | -           (wordsize(64), 97247032, 10)])
> | -             # 18/09/2012 97247032 amd64/Linux
> | +          [(wordsize(32),   48887164, 10),
> | +            # prev:         38000000 (x86/Linux)
> | +            # 2012-10-08:   48887164 (x86/Linux)
> | +           (wordsize(64),  237077056, 10)])
> | +             # 18/09/2012   97247032 amd64/Linux
> | +	     # 2013-11-26: 237077056 amd64/Linux
> |        ],
> |        compile,[''])
> | diff --git a/tests/perf/space_leaks/all.T
> | b/tests/perf/space_leaks/all.T
> | index a1fd641..ac60c8f 100644
> | --- a/tests/perf/space_leaks/all.T
> | +++ b/tests/perf/space_leaks/all.T
> | @@ -6,7 +6,7 @@ test('space_leak_001',
> |       #           5 (x86/Linux)
> |       [stats_num_field('peak_megabytes_allocated', (4, 1)),
> |        stats_num_field('max_bytes_used',
> | -          [(wordsize(64), 440000, 10),
> | +          [(wordsize(64), 440000, 15),
> |                          # 440224 (amd64/Linux)
> |                          # 417016 (x86/OS X)
> |                          # 415672 (x86/Windows)
> |
> | _______________________________________________
> | ghc-commits mailing list
> | ghc-commits at haskell.org
> | http://www.haskell.org/mailman/listinfo/ghc-commits
> _______________________________________________
> ghc-devs mailing list
> ghc-devs at haskell.org
> http://www.haskell.org/mailman/listinfo/ghc-devs
>


From marlowsd at gmail.com  Thu Nov 28 13:44:14 2013
From: marlowsd at gmail.com (Simon Marlow)
Date: Thu, 28 Nov 2013 13:44:14 +0000
Subject: [commit: testsuite] master: Update some perf results for master
 (4afbacc)
In-Reply-To: <1385644810.2465.41.camel@kirk>
References: <20131128123602.D5E5E2406B@ghc.haskell.org>
 <59543203684B2244980D7E4057D5FBC1486D42C6@DB3EX14MBXC308.europe.corp.microsoft.com>
 <1385644810.2465.41.camel@kirk>
Message-ID: <529748AE.2010406@gmail.com>

On 28/11/13 13:20, Joachim Breitner wrote:
> Hi,
>
> Am Donnerstag, den 28.11.2013, 12:42 +0000 schrieb Simon Peyton-Jones:
>> Wait. Are you really increasing "bytes allocated" from 97M to 237M?
>> That's a big change, and in an important number.  Do you know why?
>
> no; but this is master, not my branch, and it seems to be a test not run
> by validate (which calls "make -C testsuite fast"), so I have to assume
> it could be anything in the recent past.

But T6048 *is* run by validate.

Cheers,
Simon


From mail at joachim-breitner.de  Thu Nov 28 13:48:33 2013
From: mail at joachim-breitner.de (Joachim Breitner)
Date: Thu, 28 Nov 2013 13:48:33 +0000
Subject: [commit: testsuite] master: Update some perf results for master
 (4afbacc)
In-Reply-To: <529746CF.5040402@gmail.com>
References: <20131128123602.D5E5E2406B@ghc.haskell.org>
 <59543203684B2244980D7E4057D5FBC1486D42C6@DB3EX14MBXC308.europe.corp.microsoft.com>
 <529746CF.5040402@gmail.com>
Message-ID: <1385646513.2465.45.camel@kirk>

Hi,

Am Donnerstag, den 28.11.2013, 13:36 +0000 schrieb Simon Marlow:
> update the test so that GHC doesn't regress again)
>      Expected    bytes allocated: 237077056 +/-10%
>      Lower bound bytes allocated: 213369350
>      Upper bound bytes allocated: 260784762
>      Actual      bytes allocated: 101150736
> 
> Joachim: if you're building with DEBUG, that will adversely affect the 
> performance tests, so you probably shouldn't run those.

ah, ok, sorry, that?s it. My bad.

With these you mean perf/compiler, but probably not all perf tests,
right? Could we mark those tests as with
        when(compiler_debugged(),skip())
then? At the risk of repeating my self, and especially with a ever
growing number of contributors to GHC, especially new ones, the test
should should give reproducible and correct results.


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: 198 bytes
Desc: This is a digitally signed message part
URL: <http://www.haskell.org/pipermail/ghc-devs/attachments/20131128/85380a7c/attachment.sig>

From marlowsd at gmail.com  Thu Nov 28 14:11:27 2013
From: marlowsd at gmail.com (Simon Marlow)
Date: Thu, 28 Nov 2013 14:11:27 +0000
Subject: [commit: testsuite] master: Update some perf results for master
 (4afbacc)
In-Reply-To: <1385646513.2465.45.camel@kirk>
References: <20131128123602.D5E5E2406B@ghc.haskell.org>
 <59543203684B2244980D7E4057D5FBC1486D42C6@DB3EX14MBXC308.europe.corp.microsoft.com>
 <529746CF.5040402@gmail.com> <1385646513.2465.45.camel@kirk>
Message-ID: <52974F0F.9080308@gmail.com>

On 28/11/13 13:48, Joachim Breitner wrote:
> Hi,
>
> Am Donnerstag, den 28.11.2013, 13:36 +0000 schrieb Simon Marlow:
>> update the test so that GHC doesn't regress again)
>>       Expected    bytes allocated: 237077056 +/-10%
>>       Lower bound bytes allocated: 213369350
>>       Upper bound bytes allocated: 260784762
>>       Actual      bytes allocated: 101150736
>>
>> Joachim: if you're building with DEBUG, that will adversely affect the
>> performance tests, so you probably shouldn't run those.
>
> ah, ok, sorry, that?s it. My bad.
>
> With these you mean perf/compiler, but probably not all perf tests,
> right? Could we mark those tests as with
>          when(compiler_debugged(),skip())
> then?

Yes, that would be good.

> At the risk of repeating my self, and especially with a ever
> growing number of contributors to GHC, especially new ones, the test
> should should give reproducible and correct results.

Of course!  If you find cases where that's not true, please go ahead and 
fix them.

Cheers,
Simon


From mail at joachim-breitner.de  Thu Nov 28 14:22:12 2013
From: mail at joachim-breitner.de (Joachim Breitner)
Date: Thu, 28 Nov 2013 14:22:12 +0000
Subject: [commit: testsuite] master: Update some perf results for master
 (4afbacc)
In-Reply-To: <52974F0F.9080308@gmail.com>
References: <20131128123602.D5E5E2406B@ghc.haskell.org>
 <59543203684B2244980D7E4057D5FBC1486D42C6@DB3EX14MBXC308.europe.corp.microsoft.com>
 <529746CF.5040402@gmail.com> <1385646513.2465.45.camel@kirk>
 <52974F0F.9080308@gmail.com>
Message-ID: <1385648532.2465.46.camel@kirk>

Hi,

Am Donnerstag, den 28.11.2013, 14:11 +0000 schrieb Simon Marlow:
> > With these you mean perf/compiler, but probably not all perf tests,
> > right? Could we mark those tests as with
> >          when(compiler_debugged(),skip())
> > then?
> 
> Yes, that would be good.

Done in the test runner for all tests with compiler_stats_num_field, 
and mentioned on 
https://ghc.haskell.org/trac/ghc/wiki/Building/RunningTests/Adding
in the documentation for compiler_stats_num_field.

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: 198 bytes
Desc: This is a digitally signed message part
URL: <http://www.haskell.org/pipermail/ghc-devs/attachments/20131128/29c8d7ce/attachment.sig>

From simonpj at microsoft.com  Thu Nov 28 15:45:14 2013
From: simonpj at microsoft.com (Simon Peyton-Jones)
Date: Thu, 28 Nov 2013 15:45:14 +0000
Subject: [commit: testsuite] master: Summarily skip compiler_perf tests
 when DEBUG is on (715e313)
In-Reply-To: <20131128141914.BA69C2406B@ghc.haskell.org>
References: <20131128141914.BA69C2406B@ghc.haskell.org>
Message-ID: <59543203684B2244980D7E4057D5FBC1486D4661@DB3EX14MBXC308.europe.corp.microsoft.com>

Good!  but please add a comment to explain why!  The code is fully of mysterious un-commented things like this.

Simon

| -----Original Message-----
| From: ghc-commits [mailto:ghc-commits-bounces at haskell.org] On Behalf Of
| git at git.haskell.org
| Sent: 28 November 2013 14:19
| To: ghc-commits at haskell.org
| Subject: [commit: testsuite] master: Summarily skip compiler_perf tests
| when DEBUG is on (715e313)
| 
| Repository : ssh://git at git.haskell.org/testsuite
| 
| On branch  : master
| Link       :
| http://ghc.haskell.org/trac/ghc/changeset/715e313d84f4e919e12c6bba6cd646
| e488cffa74/testsuite
| 
| >---------------------------------------------------------------
| 
| commit 715e313d84f4e919e12c6bba6cd646e488cffa74
| Author: Joachim Breitner <mail at joachim-breitner.de>
| Date:   Thu Nov 28 14:17:35 2013 +0000
| 
|     Summarily skip compiler_perf tests when DEBUG is on
| 
|     by ensuring this in the test runner.
| 
| 
| >---------------------------------------------------------------
| 
| 715e313d84f4e919e12c6bba6cd646e488cffa74
|  driver/testlib.py |    3 +++
|  1 file changed, 3 insertions(+)
| 
| diff --git a/driver/testlib.py b/driver/testlib.py
| index ed7d02f..bdb91b8 100644
| --- a/driver/testlib.py
| +++ b/driver/testlib.py
| @@ -291,6 +291,9 @@ def _compiler_stats_num_field( name, opts, field,
| expecteds ):
|      if field in opts.compiler_stats_range_fields:
|          framework_fail(name, 'duplicate-numfield', 'Duplicate ' + field
| + ' num_field check')
| 
| +    if compiler_debugged():
| +        skip(name, opts)
| +
|      for (b, expected, dev) in expecteds:
|          if b:
|              opts.compiler_stats_range_fields[field] = (expected, dev)
| 
| _______________________________________________
| ghc-commits mailing list
| ghc-commits at haskell.org
| http://www.haskell.org/mailman/listinfo/ghc-commits

From kazu at iij.ad.jp  Fri Nov 29 02:30:56 2013
From: kazu at iij.ad.jp (Kazu Yamamoto (=?iso-2022-jp?B?GyRCOzNLXE9CSScbKEI=?=))
Date: Fri, 29 Nov 2013 11:30:56 +0900 (JST)
Subject: build errors
In-Reply-To: <20131128.124329.1368767284961267993.kazu@iij.ad.jp>
References: <20131128.124329.1368767284961267993.kazu@iij.ad.jp>
Message-ID: <20131129.113056.743188938973219924.kazu@iij.ad.jp>

Hi,

> I cannot build GHC head on Linux and Mac (Mavericks) today:
> 
> compiler/typecheck/TcEvidence.lhs:152:16:
>     Not in scope: data constructor `ASSERT2'

The attached patches are necessary to build GHC head on Mavericks.

--Kazu

diff --git a/compiler/coreSyn/CoreUtils.lhs b/compiler/coreSyn/CoreUtils.lhs
index 91f68a2..9e23348 100644
--- a/compiler/coreSyn/CoreUtils.lhs
+++ b/compiler/coreSyn/CoreUtils.lhs
@@ -190,7 +190,7 @@ applyTypeToArgs e op_ty args
 -- | Wrap the given expression in the coercion safely, dropping
 -- identity coercions and coalescing nested coercions
 mkCast :: CoreExpr -> Coercion -> CoreExpr
-mkCast e co | ASSERT2 ( coercionRole co == Representational
+mkCast e co | ASSERT2( coercionRole co == Representational
                       , ptext (sLit "coercion") <+> ppr co <+> ptext (sLit "passed to mkCast") <+> ppr e <+> ptext (sLit "has wrong role") <+> ppr (coercionRole co) )
               isReflCo co = e
 
diff --git a/compiler/deSugar/DsBinds.lhs b/compiler/deSugar/DsBinds.lhs
index 9866453..5764d11 100644
--- a/compiler/deSugar/DsBinds.lhs
+++ b/compiler/deSugar/DsBinds.lhs
@@ -705,7 +705,7 @@ dsHsWrapper (WpTyApp ty)      e = return $ App e (Type ty)
 dsHsWrapper (WpLet ev_binds)  e = do bs <- dsTcEvBinds ev_binds
                                      return (mkCoreLets bs e)
 dsHsWrapper (WpCompose c1 c2) e = dsHsWrapper c1 =<< dsHsWrapper c2 e
-dsHsWrapper (WpCast co)       e = ASSERT (tcCoercionRole co == Representational)
+dsHsWrapper (WpCast co)       e = ASSERT(tcCoercionRole co == Representational)
                                   dsTcCoercion co (mkCast e)
 dsHsWrapper (WpEvLam ev)      e = return $ Lam ev e 
 dsHsWrapper (WpTyLam tv)      e = return $ Lam tv e 
diff --git a/compiler/typecheck/TcCanonical.lhs b/compiler/typecheck/TcCanonical.lhs
index d51fbf6..8f60bc5 100644
--- a/compiler/typecheck/TcCanonical.lhs
+++ b/compiler/typecheck/TcCanonical.lhs
@@ -1132,7 +1132,7 @@ canEqLeafTyVar ev tv s2              -- ev :: tv ~ s2
 
            (Just tv1, Just tv2) | tv1 == tv2
               -> do { when (isWanted ev) $
-                      ASSERT ( tcCoercionRole co == Nominal )
+                      ASSERT( tcCoercionRole co == Nominal )
                       setEvBind (ctev_evar ev) (mkEvCast (EvCoercion (mkTcReflCo Nominal xi1)) (mkTcSubCo co))
                     ; return Stop }
 
diff --git a/compiler/typecheck/TcEvidence.lhs b/compiler/typecheck/TcEvidence.lhs
index 6b1ee3e..c233d71 100644
--- a/compiler/typecheck/TcEvidence.lhs
+++ b/compiler/typecheck/TcEvidence.lhs
@@ -149,7 +149,7 @@ mkTcTyConAppCo role tc cos -- No need to expand type synonyms
 -- mkSubCo will do some normalisation. We do not do it for TcCoercions, but
 -- defer that to desugaring; just to reduce the code duplication a little bit
 mkTcSubCo :: TcCoercion -> TcCoercion
-mkTcSubCo co = ASSERT2 ( tcCoercionRole co == Nominal, ppr co)
+mkTcSubCo co = ASSERT2( tcCoercionRole co == Nominal, ppr co)
                TcSubCo co
 
 maybeTcSubCo2_maybe :: Role   -- desired role
@@ -171,7 +171,7 @@ maybeTcSubCo2 r1 r2 co
 
 mkTcAxInstCo :: Role -> CoAxiom br -> Int -> [TcType] -> TcCoercion
 mkTcAxInstCo role ax index tys
-  | ASSERT2 ( not (role == Nominal && ax_role == Representational) , ppr (ax, tys) )
+  | ASSERT2( not (role == Nominal && ax_role == Representational) , ppr (ax, tys) )
     arity == n_tys = maybeTcSubCo2 role ax_role $ TcAxiomInstCo ax_br index rtys
   | otherwise      = ASSERT( arity < n_tys )
                      maybeTcSubCo2 role ax_role $ 
@@ -486,7 +486,7 @@ c <.> WpHole = c
 c1 <.> c2    = c1 `WpCompose` c2
 
 mkWpCast :: TcCoercion -> HsWrapper
-mkWpCast co = ASSERT2 (tcCoercionRole co == Representational, ppr co)
+mkWpCast co = ASSERT2(tcCoercionRole co == Representational, ppr co)
               WpCast co
 
 mkWpTyApps :: [Type] -> HsWrapper
@@ -709,7 +709,7 @@ The story for kind `Symbol` is analogous:
 \begin{code}
 mkEvCast :: EvTerm -> TcCoercion -> EvTerm
 mkEvCast ev lco
-  | ASSERT2 (tcCoercionRole lco == Representational, (vcat [ptext (sLit "Coercion of wrong role passed to mkEvCast:"), ppr ev, ppr lco]))
+  | ASSERT2(tcCoercionRole lco == Representational, (vcat [ptext (sLit "Coercion of wrong role passed to mkEvCast:"), ppr ev, ppr lco]))
     isTcReflCo lco = ev
   | otherwise      = EvCast ev lco
 
diff --git a/compiler/typecheck/TcSMonad.lhs b/compiler/typecheck/TcSMonad.lhs
index 90fe446..06856d7 100644
--- a/compiler/typecheck/TcSMonad.lhs
+++ b/compiler/typecheck/TcSMonad.lhs
@@ -1708,7 +1708,7 @@ rewriteCtFlavor (CtGiven { ctev_evtm = old_tm , ctev_loc = loc }) new_pred co
 
 rewriteCtFlavor (CtWanted { ctev_evar = evar, ctev_loc = loc }) new_pred co
   = do { new_evar <- newWantedEvVar loc new_pred
-       ; MASSERT ( tcCoercionRole co == Nominal )
+       ; MASSERT( tcCoercionRole co == Nominal )
        ; setEvBind evar (mkEvCast (getEvTerm new_evar) (mkTcSubCo co))
        ; case new_evar of
             Fresh ctev -> return (Just ctev)

From kazu at iij.ad.jp  Fri Nov 29 02:37:43 2013
From: kazu at iij.ad.jp (Kazu Yamamoto (=?iso-2022-jp?B?GyRCOzNLXE9CSScbKEI=?=))
Date: Fri, 29 Nov 2013 11:37:43 +0900 (JST)
Subject: __builtin___clear_cache
Message-ID: <20131129.113743.2086479021786836429.kazu@iij.ad.jp>

Hi,

5bab1a57f572e29dfdffd6d1ce8e53a2772b18fd introduced
__builtin___clear_cache. I think this is GCC specific.
So, Storage.c cannot be compiled with clang:

----
rts/sm/Storage.c:1294:3:
     error: use of unknown builtin '__builtin___clear_cache' [-Wimplicit-function-declaration]
      __builtin___clear_cache(begin, end);
      ^
1 error generated.
----

--Kazu

From hvr at gnu.org  Fri Nov 29 08:13:27 2013
From: hvr at gnu.org (Herbert Valerio Riedel)
Date: Fri, 29 Nov 2013 09:13:27 +0100
Subject: build errors
In-Reply-To: <20131129.113056.743188938973219924.kazu@iij.ad.jp> ("Kazu
 Yamamoto \=\?utf-8\?B\?KOWxseacrOWSjOW9pikiJ3M\=\?\= message of "Fri,
 29 Nov 2013 11:30:56 +0900 (JST)")
References: <20131128.124329.1368767284961267993.kazu@iij.ad.jp>
 <20131129.113056.743188938973219924.kazu@iij.ad.jp>
Message-ID: <87vbzbaamw.fsf@gmail.com>

On 2013-11-29 at 03:30:56 +0100, Kazu Yamamoto (????) wrote:
>> I cannot build GHC head on Linux and Mac (Mavericks) today:
>> 
>> compiler/typecheck/TcEvidence.lhs:152:16:
>>     Not in scope: data constructor `ASSERT2'
>
> The attached patches are necessary to build GHC head on Mavericks.

thanks, applied per

 http://git.haskell.org/ghc.git/commitdiff/96416412cc8100bd1c1625e10c09df17c88a67b7

btw, curiously, Clang seems happy to compile "ASSERT (...)"  occurences
in C files such as rts/STM.c which have several of those...

Cheers,
  hvr

From kazu at iij.ad.jp  Fri Nov 29 08:21:49 2013
From: kazu at iij.ad.jp (Kazu Yamamoto (=?iso-2022-jp?B?GyRCOzNLXE9CSScbKEI=?=))
Date: Fri, 29 Nov 2013 17:21:49 +0900 (JST)
Subject: build errors
In-Reply-To: <87vbzbaamw.fsf@gmail.com>
References: <20131128.124329.1368767284961267993.kazu@iij.ad.jp>
 <20131129.113056.743188938973219924.kazu@iij.ad.jp>
 <87vbzbaamw.fsf@gmail.com>
Message-ID: <20131129.172149.1498300402330553017.kazu@iij.ad.jp>

> btw, curiously, Clang seems happy to compile "ASSERT (...)"  occurences
> in C files such as rts/STM.c which have several of those...

Yes. Clang supports it according to my test.
I don't know why this happens.

--Kazu

From hvr at gnu.org  Fri Nov 29 08:23:33 2013
From: hvr at gnu.org (Herbert Valerio Riedel)
Date: Fri, 29 Nov 2013 09:23:33 +0100
Subject: __builtin___clear_cache
In-Reply-To: <20131129.113743.2086479021786836429.kazu@iij.ad.jp> ("Kazu
 Yamamoto \=\?utf-8\?B\?KOWxseacrOWSjOW9pikiJ3M\=\?\= message of "Fri,
 29 Nov 2013 11:37:43 +0900 (JST)")
References: <20131129.113743.2086479021786836429.kazu@iij.ad.jp>
Message-ID: <87r49zaa62.fsf@gmail.com>

On 2013-11-29 at 03:37:43 +0100, Kazu Yamamoto (????) wrote:
> 5bab1a57f572e29dfdffd6d1ce8e53a2772b18fd introduced
> __builtin___clear_cache. I think this is GCC specific.
> So, Storage.c cannot be compiled with clang:
>
> ----
> rts/sm/Storage.c:1294:3:
>      error: use of unknown builtin '__builtin___clear_cache' [-Wimplicit-function-declaration]
>       __builtin___clear_cache(begin, end);
>       ^
> 1 error generated.
> ----

Fyi, the following posting seems related:

 http://lists.nongnu.org/archive/html/libunwind-devel/2012-08/msg00057.html


From kazu at iij.ad.jp  Fri Nov 29 08:44:12 2013
From: kazu at iij.ad.jp (Kazu Yamamoto (=?iso-2022-jp?B?GyRCOzNLXE9CSScbKEI=?=))
Date: Fri, 29 Nov 2013 17:44:12 +0900 (JST)
Subject: __builtin___clear_cache
In-Reply-To: <87r49zaa62.fsf@gmail.com>
References: <20131129.113743.2086479021786836429.kazu@iij.ad.jp>
 <87r49zaa62.fsf@gmail.com>
Message-ID: <20131129.174412.1952476927693992470.kazu@iij.ad.jp>

Hi,

I was discussed this with Austin in private messages. He understand
what's the source of this problem and will fix it.

--Kazu

> On 2013-11-29 at 03:37:43 +0100, Kazu Yamamoto (????) wrote:
>> 5bab1a57f572e29dfdffd6d1ce8e53a2772b18fd introduced
>> __builtin___clear_cache. I think this is GCC specific.
>> So, Storage.c cannot be compiled with clang:
>>
>> ----
>> rts/sm/Storage.c:1294:3:
>>      error: use of unknown builtin '__builtin___clear_cache' [-Wimplicit-function-declaration]
>>       __builtin___clear_cache(begin, end);
>>       ^
>> 1 error generated.
>> ----
> 
> Fyi, the following posting seems related:
> 
>  http://lists.nongnu.org/archive/html/libunwind-devel/2012-08/msg00057.html
> 

From kazu at iij.ad.jp  Fri Nov 29 08:45:12 2013
From: kazu at iij.ad.jp (Kazu Yamamoto (=?iso-2022-jp?B?GyRCOzNLXE9CSScbKEI=?=))
Date: Fri, 29 Nov 2013 17:45:12 +0900 (JST)
Subject: Building GHC head with clang on Mavericks
In-Reply-To: <529708D6.9030009@gmail.com>
References: <CAFXb89CCv4GKhJQR5WRh6UTdgRXcvvoSowH03HCa9s4DeQ3C-g@mail.gmail.com>
 <20131121.155430.37558810975251514.kazu@iij.ad.jp>
 <529708D6.9030009@gmail.com>
Message-ID: <20131129.174512.682731754748116086.kazu@iij.ad.jp>

Hi Simon,

>>> I think he has forgotten, yes. But yeah do send the pull requests
>>> anyway,
>>> my last set got merged in.
>>
>> Done:
>> 	https://github.com/simonmar/happy/pull/13
>> 	https://github.com/simonmar/alex/pull/38
> 
> I've merged these and made new releases of Happy (1.19.2) and Alex
> (3.1.3).

I verified that this happy and alex can build GHC head on Mavericks.
Thank you!

--Kazu

From marlowsd at gmail.com  Fri Nov 29 10:08:43 2013
From: marlowsd at gmail.com (Simon Marlow)
Date: Fri, 29 Nov 2013 10:08:43 +0000
Subject: [commit: testsuite] master: Explain skipping compiler-perf tests
 when debugging is on (14958ae)
In-Reply-To: <20131128155552.BD5D42406B@ghc.haskell.org>
References: <20131128155552.BD5D42406B@ghc.haskell.org>
Message-ID: <529867AB.7030001@gmail.com>

Actually this isn't quite right.  compiler_debugged() is true when 
GhcDebugged=YES in the build system, and GhcDebugged controls whether 
GHC is compiled with -debug or not.

That is, compiler_debugged() tells us whether the compiler was compiled 
with -debug, not -DDEBUG.  The -debug flag links in the debug RTS and 
doesn't change allocation or heap residency, whereas -DDEBUG enables 
assertions in the compiler and *does* change allocation and heap residency.

It looks like we need another predicate to tell us whether GHC was 
compiled with -DDEBUG or not.

Would you mind backing out these changes in the meantime?

Cheers,
Simon

On 28/11/13 15:55, git at git.haskell.org wrote:
> Repository : ssh://git at git.haskell.org/testsuite
>
> On branch  : master
> Link       : http://ghc.haskell.org/trac/ghc/changeset/14958ae02b99bafc06288493d186b9313ee8c4b9/testsuite
>
>> ---------------------------------------------------------------
>
> commit 14958ae02b99bafc06288493d186b9313ee8c4b9
> Author: Joachim Breitner <mail at joachim-breitner.de>
> Date:   Thu Nov 28 15:56:16 2013 +0000
>
>      Explain skipping compiler-perf tests when debugging is on
>
>
>> ---------------------------------------------------------------
>
> 14958ae02b99bafc06288493d186b9313ee8c4b9
>   driver/testlib.py |    2 ++
>   1 file changed, 2 insertions(+)
>
> diff --git a/driver/testlib.py b/driver/testlib.py
> index bdb91b8..8c8c60d 100644
> --- a/driver/testlib.py
> +++ b/driver/testlib.py
> @@ -291,6 +291,8 @@ def _compiler_stats_num_field( name, opts, field, expecteds ):
>       if field in opts.compiler_stats_range_fields:
>           framework_fail(name, 'duplicate-numfield', 'Duplicate ' + field + ' num_field check')
>
> +    # Compiler performance numbers change when debugging is on, making the results
> +    # useless and confusing. Therefore, skip if debugging is on.
>       if compiler_debugged():
>           skip(name, opts)
>
>
> _______________________________________________
> ghc-commits mailing list
> ghc-commits at haskell.org
> http://www.haskell.org/mailman/listinfo/ghc-commits
>


From mail at joachim-breitner.de  Fri Nov 29 10:28:42 2013
From: mail at joachim-breitner.de (Joachim Breitner)
Date: Fri, 29 Nov 2013 10:28:42 +0000
Subject: [commit: testsuite] master: Explain skipping compiler-perf
 tests when debugging is on (14958ae)
In-Reply-To: <529867AB.7030001@gmail.com>
References: <20131128155552.BD5D42406B@ghc.haskell.org>
 <529867AB.7030001@gmail.com>
Message-ID: <1385720922.2431.16.camel@kirk>

Hi,

Am Freitag, den 29.11.2013, 10:08 +0000 schrieb Simon Marlow:
> Actually this isn't quite right.  compiler_debugged() is true when 
> GhcDebugged=YES in the build system, and GhcDebugged controls whether 
> GHC is compiled with -debug or not.
> 
> That is, compiler_debugged() tells us whether the compiler was compiled 
> with -debug, not -DDEBUG.  The -debug flag links in the debug RTS and 
> doesn't change allocation or heap residency, whereas -DDEBUG enables 
> assertions in the compiler and *does* change allocation and heap residency.
> 
> It looks like we need another predicate to tell us whether GHC was 
> compiled with -DDEBUG or not.
> 
> Would you mind backing out these changes in the meantime?

are you sure? compiler_debugged() is certainly true when I build ghc
with
        GhcStage2HcOpts    = -O0 -DDEBUG
which yields
        ./inplace/bin/ghc-stage2 --info|grep 'Debug on'
         ,("Debug on","True")
but
        ./inplace/bin/ghc-stage2 +RTS --info|grep -i debug
is empty. 

The test runner sets the value testsuite/mk/ghc-config.hs:
  info <- readProcess ghc ["--info"] ""
  let fields = read info :: [(String,String)]
  getGhcFieldOrFail fields "GhcDebugged" "Debug on"
which writes to testsuite/mk/ghcconfig_*
which is then read by testsuite/mk/boilerplate.mk
which is included everywhere
including mk/test.mk which sets "-e ghc_debugged=$(GhcDebugged)"

So it seems that it is simply the wiki documentation that is wrong here.

(And judging from the git history, it has always been the case since it
was introduced by Ian one year ago
(888daa51a7d656bba5f39e16e6396ba9d4d29f4c).

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: 198 bytes
Desc: This is a digitally signed message part
URL: <http://www.haskell.org/pipermail/ghc-devs/attachments/20131129/4d242592/attachment.sig>

From mail at joachim-breitner.de  Fri Nov 29 11:54:05 2013
From: mail at joachim-breitner.de (Joachim Breitner)
Date: Fri, 29 Nov 2013 11:54:05 +0000
Subject: Can cardinality analysis subsume strictness analysis
Message-ID: <1385726045.2431.21.camel@kirk>

Hi,

after playing a bit with the Demand analyser and trying debug tricky
bugs (#8569), I begin to wonder: Can cardinality analysis subsume
strictness analysis?

Not directly, obviously, but if we change

data Count = One | Many
to
data Count = AtMostOne | ExactlyOne | AtLeastOne | Many
(or some other form that would allow us to express all possible
intervals in {0,1,?}), would the demand and cardinality analysis then
not subsume strictness, given that:
        A value is used strictly if is definitely used at least once?

That might simplify the Demand.lhs code, and also the demand signatures,
quite a bit, because currently it carries strictness and demand data
around separately, duplicating lots of stuff.

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: 198 bytes
Desc: This is a digitally signed message part
URL: <http://www.haskell.org/pipermail/ghc-devs/attachments/20131129/4dde7d1f/attachment.sig>

From mrblairarchibald at gmail.com  Fri Nov 29 12:39:48 2013
From: mrblairarchibald at gmail.com (Blair Archibald)
Date: Fri, 29 Nov 2013 12:39:48 +0000
Subject: Getting Involved
Message-ID: <CAJg8PKPX-z3VFX2Z=CzyUp44dAo0nB7vs9Kg8qPTrmT_boxwiQ@mail.gmail.com>

Hi,

I'm looking to get involved working on GHC - I've been using Haskell for
quite a while now and thought I'd give back to the community.

Bit about me: I'm Blair an (4th year) Undergraduate at the University of
Glasgow and my main interests at the moment are Functional Programming,
Runtime systems (mainly memory management/GC work) and Transactional Memory
(making GHC a great place to be!)

I've noticed that there is talk of adding a better flags parser to the RTS
and this seems like a good place to start (less likely to break things!).
Ticket: #4243

Is anyone currently working in this area or have plans to start work in
this area?


Many thanks,
Blair
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/ghc-devs/attachments/20131129/acbbaac3/attachment.html>

From jan.stolarek at p.lodz.pl  Fri Nov 29 20:29:30 2013
From: jan.stolarek at p.lodz.pl (Jan Stolarek)
Date: Fri, 29 Nov 2013 21:29:30 +0100
Subject: Getting Involved
In-Reply-To: <CAJg8PKPX-z3VFX2Z=CzyUp44dAo0nB7vs9Kg8qPTrmT_boxwiQ@mail.gmail.com>
References: <CAJg8PKPX-z3VFX2Z=CzyUp44dAo0nB7vs9Kg8qPTrmT_boxwiQ@mail.gmail.com>
Message-ID: <201311292129.30805.jan.stolarek@p.lodz.pl>

Hi Blair,

have you seen this page on the wiki: https://ghc.haskell.org/trac/ghc/wiki/Newcomers ? It should 
help you get started and give you some alternative ideas on tickets worth picking up.

Janek

Dnia pi?tek, 29 listopada 2013, Blair Archibald napisa?:
> Hi,
>
> I'm looking to get involved working on GHC - I've been using Haskell for
> quite a while now and thought I'd give back to the community.
>
> Bit about me: I'm Blair an (4th year) Undergraduate at the University of
> Glasgow and my main interests at the moment are Functional Programming,
> Runtime systems (mainly memory management/GC work) and Transactional Memory
> (making GHC a great place to be!)
>
> I've noticed that there is talk of adding a better flags parser to the RTS
> and this seems like a good place to start (less likely to break things!).
> Ticket: #4243
>
> Is anyone currently working in this area or have plans to start work in
> this area?
>
>
> Many thanks,
> Blair



From fuuzetsu at fuuzetsu.co.uk  Fri Nov 29 21:03:58 2013
From: fuuzetsu at fuuzetsu.co.uk (Mateusz Kowalczyk)
Date: Fri, 29 Nov 2013 21:03:58 +0000
Subject: Getting Involved
In-Reply-To: <201311292129.30805.jan.stolarek@p.lodz.pl>
References: <CAJg8PKPX-z3VFX2Z=CzyUp44dAo0nB7vs9Kg8qPTrmT_boxwiQ@mail.gmail.com>
 <201311292129.30805.jan.stolarek@p.lodz.pl>
Message-ID: <5299013E.9090501@fuuzetsu.co.uk>

On 29/11/13 20:29, Jan Stolarek wrote:
> Hi Blair,
> 
> have you seen this page on the wiki: https://ghc.haskell.org/trac/ghc/wiki/Newcomers ? It should 
> help you get started and give you some alternative ideas on tickets worth picking up.
> 
> Janek
> 

I mentioned this recently in #ghc but that page is _really_ hard to find
on the Wiki and unless you know it exists, you're not going to have seen
it. If possible, could someone put it in a more visible place? I realise
that it's on the WorkingConventions page (only now I realise this) but
perhaps a direct link in the sidebar or maybe even a link on the front
page in Developer Documentation section would be appropriate!

-- 
Mateusz K.

From carter.schonwald at gmail.com  Fri Nov 29 21:59:29 2013
From: carter.schonwald at gmail.com (Carter Schonwald)
Date: Fri, 29 Nov 2013 16:59:29 -0500
Subject: Getting Involved
In-Reply-To: <5299013E.9090501@fuuzetsu.co.uk>
References: <CAJg8PKPX-z3VFX2Z=CzyUp44dAo0nB7vs9Kg8qPTrmT_boxwiQ@mail.gmail.com>
 <201311292129.30805.jan.stolarek@p.lodz.pl>
 <5299013E.9090501@fuuzetsu.co.uk>
Message-ID: <CAHYVw0yURj7xz-ZN0pBW8jPuweJB7WMd-7hgj7OxZn5rcvRzjg@mail.gmail.com>

That's a good idea.  Herberto (hvr on #ghc)
Is the expert on matters related to trac, but you might be able to edit the
wiki yourself.

On Friday, November 29, 2013, Mateusz Kowalczyk wrote:

> On 29/11/13 20:29, Jan Stolarek wrote:
> > Hi Blair,
> >
> > have you seen this page on the wiki:
> https://ghc.haskell.org/trac/ghc/wiki/Newcomers ? It should
> > help you get started and give you some alternative ideas on tickets
> worth picking up.
> >
> > Janek
> >
>
> I mentioned this recently in #ghc but that page is _really_ hard to find
> on the Wiki and unless you know it exists, you're not going to have seen
> it. If possible, could someone put it in a more visible place? I realise
> that it's on the WorkingConventions page (only now I realise this) but
> perhaps a direct link in the sidebar or maybe even a link on the front
> page in Developer Documentation section would be appropriate!
>
> --
> Mateusz K.
> _______________________________________________
> 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/20131129/6c486d2b/attachment.html>