Windows build broken again: urgent

[Simon Peyton Jones]

Alas.  Alack.  The Windows build is broken again.
This time it's pretty fundamental: the stage2 compiler seg-faults every time it 
invokes the linker:

*On GHCi startup

*On every Template Haskell splice
I don't know when this started, but I did a successful build at 23.10 on 24 
November, so it's during the last week.
I would gladly do any experiments if someone tells me what to do.
It would be really good to fix this.  At the moment I'm pretty much stalled on 
laptop work.
Simon
___
ghc-devs mailing list
ghc-devs@haskell.org
http://www.haskell.org/mailman/listinfo/ghc-devs

RE: Windows build broken again: urgent

[Simon Peyton Jones]

|  Just a hunch... could it have been broken by one of the recent linker-
|  related patches since Nov 24th?

That seems very plausible, yes.  But still there's the question of what to do 
about it.

Simon

|  -Original Message-
|  From: Herbert Valerio Riedel [mailto:hvrie...@gmail.com]
|  Sent: 01 December 2014 08:37
|  To: Simon Peyton Jones
|  Subject: Re: Windows build broken again: urgent
|  
|  On 2014-12-01 at 09:31:51 +0100, Simon Peyton Jones wrote:
|  > Alas.  Alack.  The Windows build is broken again.
|  > This time it's pretty fundamental: the stage2 compiler seg-faults
|  every time it invokes the linker:
|  >
|  > *On GHCi startup
|  >
|  > *On every Template Haskell splice
|  >
|  > I don't know when this started, but I did a successful build at
|  23.10 on 24 November, so it's during the last week.
|  > I would gladly do any experiments if someone tells me what to do.
|  > It would be really good to fix this.  At the moment I'm pretty much
|  stalled on laptop work.
|  
|  Just a hunch... could it have been broken by one of the recent linker-
|  related patches since Nov 24th?

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

Re: Windows build broken again: urgent

[Herbert Valerio Riedel]

Hello Simon,

On 2014-12-01 at 09:38:37 +0100, Simon Peyton Jones wrote:
> |  Just a hunch... could it have been broken by one of the recent linker-
> |  related patches since Nov 24th?
>
> That seems very plausible, yes.  But still there's the question of
> what to do about it.

 a) Empirically: Try locally 'git revert'ing

 383733b9191a36e2d3f757700842dbc3855911d9 

 and/or

 b5e8b3b162b3ff15ae6caf1afc659565365f54a8

 and see if your problem goes away, or

 b) Ask Simon Marlow (he either wrote or reviewed those two patches) if
he sees something odd in those patches that could have broken
Windows' GHCi...

Cheers,
  hvr
___
ghc-devs mailing list
ghc-devs@haskell.org
http://www.haskell.org/mailman/listinfo/ghc-devs

Re: Status and future of the LLVM backend

[Joachim Breitner]

Hi,


Am Sonntag, den 30.11.2014, 18:49 -0500 schrieb Ben Gamari:
> > Am Sonntag, den 30.11.2014, 16:48 -0500 schrieb Ben Gamari:
> >> > What would be a reliable way to make the build system pass
> >> > -B/usr/bin/ld.gold to gcc? Is
> >> > SRC_HC_OPTS += -optc-B/usr/bin/ld.gold
> >> > in mk/build.mk a good idea?
> >> >
> >> Indeed this is much cleaner. I just wanted a way to accomplish this
> >> without editing build.mk.
> >
> > Cleaner maybe, but it was not picked up either. Or maybe we are looking
> > at a different issue, not solved by using ld.gold?
> >
> I suspect that it this is the gold issue. I should have looked at your
> command line a bit more carefully; I suspect you want 
> 
> SRC_HC_OPTS += -optl-B/usr/bin/ld.gold
> 
> Hopefully this will do it; at least the option appears to make it to the
> right phase now.

Trying it right now...

> Is the Debian packaging tracked in version control somewhere? All I can
> find is the packaging tarball [1].

It’s at http://darcs.debian.org/pkg-haskell/experimental/ghc
(but due to a index.html in that directory, you cannot browse it, so you
have to "darcs get" it)

Greetings,
Joachim




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



signature.asc
Description: This is a digitally signed message part
___
ghc-devs mailing list
ghc-devs@haskell.org
http://www.haskell.org/mailman/listinfo/ghc-devs

Re: Windows build broken again: urgent

[Johan Tibell]

In general I think a good course of action when this happens is:

* Use git bisect to find the offending commit. This works now because we
moved to submodules.
* Revert the commit.
* Push the patch to master and notify the author.

This style of early rollback will become more important as we grow as it
puts the onus on fixing on the right person and minimizes negative impact
on other developers.
On Dec 1, 2014 9:43 AM, "Herbert Valerio Riedel"  wrote:

> Hello Simon,
>
> On 2014-12-01 at 09:38:37 +0100, Simon Peyton Jones wrote:
> > |  Just a hunch... could it have been broken by one of the recent linker-
> > |  related patches since Nov 24th?
> >
> > That seems very plausible, yes.  But still there's the question of
> > what to do about it.
>
>  a) Empirically: Try locally 'git revert'ing
>
>  383733b9191a36e2d3f757700842dbc3855911d9
>
>  and/or
>
>  b5e8b3b162b3ff15ae6caf1afc659565365f54a8
>
>  and see if your problem goes away, or
>
>  b) Ask Simon Marlow (he either wrote or reviewed those two patches) if
> he sees something odd in those patches that could have broken
> Windows' GHCi...
>
> Cheers,
>   hvr
> ___
> ghc-devs mailing list
> ghc-devs@haskell.org
> http://www.haskell.org/mailman/listinfo/ghc-devs
>
___
ghc-devs mailing list
ghc-devs@haskell.org
http://www.haskell.org/mailman/listinfo/ghc-devs

Re: Possible error with strict_mark in Parser.y

[Jan Stolarek]

Looking at the source code comments it seems that you're right:

data HsBang
  = HsUserBang   -- The user's source-code request
   (Maybe Bool)   -- Just True{-# UNPACK #-}
  -- Just False   {-# NOUNPACK #-}
  -- Nothing  no pragma
   Bool   -- True <=> '!' specified


Can anyone confirm?

Janek

Dnia niedziela, 30 listopada 2014, Alan & Kim Zimmerman napisał:
> If I look at the production for strict_mark in the parser
>
> https://github.com/ghc/ghc/blob/master/compiler/parser/Parser.y#L1355
>
> strict_mark :: { Located ([AddAnn],HsBang) }
>
> : '!'{ sL1 $1 ([],HsUserBang Nothing
>
> True) }
>
> | '{-# UNPACK' '#-}' { sLL $1 $> ([mo $1,mc $2],HsUserBang
>
> (Just True)  False) }
>
> | '{-# NOUNPACK' '#-}'   { sLL $1 $> ([mo $1,mc $2],HsUserBang
>
> (Just False) True) } -- ***Correct?
>
> | '{-# UNPACK' '#-}' '!' { sLL $1 $> ([mo $1,mc $2],HsUserBang
>
> (Just True)  True) }
>
> | '{-# NOUNPACK' '#-}' '!'   { sLL $1 $> ([mo $1,mc $2],HsUserBang
>
> (Just False) True) }
>
> I would expect the final True or False value to reflect the presence of the
> '!' mark.
>
> But the second line has no '!' but returns True.
>
> I suspect this is an error.
>
> Alan



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

Re: Cross-compiling GHC for ARM (RPi)

[Karel Gardas]

Two obvious questions:

1) have you installed your ncurses into your sysroot?

2) have you passed your sysroot to really all gcc invocations?

Your description looks like at least one answer to above question should 
be "no".


For example I used custom bash script to solve (2), see [1].

Cheers,
Karel
[1]: 
https://ghcarm.wordpress.com/2014/01/18/unregisterised-ghc-head-build-for-arm64-platform/


On 12/ 1/14 12:43 AM, Xandaros wrote:


-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

I'm having some trouble cross-compiling GHC (or just making a
cross-compiler, which is what I am trying to do for now).

I got my toolchain through crosstool-ng. I just took the
arm-unknown-linux-gnueabi sample and disabled the "render the toolchain
read-only" option.

Unfortunately nt-ng does not come with ncurses, so I also compiled and
installed that. I set the prefix to
~/x-tools/arm-unknown-linux-gnueabi/arm-unknown-linux-gnueabi/sysroot,
where ~/x-tools/arm-unknown-linux-gnueabi is where my toolchain is located.

I copied the mk/build.mk.sample file to mk/build.mk and uncommented the
quick-cross option. I left everything else as-is.

After configuring I executed make, which runs for quite a while but
eventually it complains about not being able to find the curses headers.

What do I do to fix this? I wouldn't mind using a different toolchain if
I can get it to work, so I am open for anything.

Configure summary of ncurses and last lines of output of make:
http://hastebin.com/uwuwenucux.txt

I hope you can help me resolve this, I've been trying to do this for a
long time now :/
-BEGIN PGP SIGNATURE-
Version: GnuPG v2

iQEcBAEBCAAGBQJUe6uhAAoJEGBf7SEXmH6sIMkH/3eK500hnjjN3+hv/7P0YmY2
QVcDWJxRMgnFCyFA9oxAeJYqKeIps2H3555NSLdB19DK7QCG1x4TJpUBGCz09PfX
mH8ZN2qIirHIYUHOZa5JdE8cqvWd3hI1syr22PsxqyI4tkDuIfKsAp8IbJOd/vSX
9oqKjHe0OYHKIoUUlHST1AI2lElMby69nxBMprhU8yugIyEFSmQg+nuxG2Hq5GA4
SgOExWeuJHrxIAW0WZ8vipw7PG3IfJTzDSCMzIAPfri8TVhy2UNNVpjg4aaq//X0
TXXweFS1O/EpDSuRkU/2b5nGlxbaNObLI5eAJ0Lot7Pl5Oa1afK5l5ZWYipx+Fk=
=ol51
-END PGP SIGNATURE-

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



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

RE: Performance regression on typechecking type families?

[Simon Peyton Jones]

| I personally have run into exponential compile times with type families.
| Unfortunately I have not
| had the time yet to reduce my test case to something tractable.

Ha!  If you do find the time, I'm sure everyone would be grateful.  Just use 
the time while waiting for the type checker. If it is truly exponential, you 
will easily have enough waiting time :-)

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

Re: Status and future of the LLVM backend

[Joachim Breitner]

Hi,


Am Montag, den 01.12.2014, 09:42 +0100 schrieb Joachim Breitner:
> Am Sonntag, den 30.11.2014, 18:49 -0500 schrieb Ben Gamari:
> > > Am Sonntag, den 30.11.2014, 16:48 -0500 schrieb Ben Gamari:
> > >> > What would be a reliable way to make the build system pass
> > >> > -B/usr/bin/ld.gold to gcc? Is
> > >> > SRC_HC_OPTS += -optc-B/usr/bin/ld.gold
> > >> > in mk/build.mk a good idea?
> > >> >
> > >> Indeed this is much cleaner. I just wanted a way to accomplish this
> > >> without editing build.mk.
> > >
> > > Cleaner maybe, but it was not picked up either. Or maybe we are looking
> > > at a different issue, not solved by using ld.gold?
> > >
> > I suspect that it this is the gold issue. I should have looked at your
> > command line a bit more carefully; I suspect you want 
> > 
> > SRC_HC_OPTS += -optl-B/usr/bin/ld.gold
> > 
> > Hopefully this will do it; at least the option appears to make it to the
> > right phase now.
> 
> Trying it right now...

no success, same error:
https://buildd.debian.org/status/fetch.php?pkg=ghc&arch=armhf&ver=7.8.20141119-6&stamp=1417438953&file=log


Greetings,
Joachim
-- 
Joachim “nomeata” Breitner
  m...@joachim-breitner.de • http://www.joachim-breitner.de/
  Jabber: nome...@joachim-breitner.de  • GPG-Key: 0xF0FBF51F
  Debian Developer: nome...@debian.org



signature.asc
Description: This is a digitally signed message part
___
ghc-devs mailing list
ghc-devs@haskell.org
http://www.haskell.org/mailman/listinfo/ghc-devs

RE: Windows build broken again: urgent

[Simon Peyton Jones]

Indeed.  But each bisect takes quite a while.  So my attention switches and it 
takes a while to get back.  I was hoping some machine might do it for me.

Herbert suggested some commits to revert. I’ll try that first

From: Johan Tibell [mailto:johan.tib...@gmail.com]
Sent: 01 December 2014 09:45
To: Herbert Valerio Riedel
Cc: ghc-devs@haskell.org; Simon Marlow; Simon Peyton Jones
Subject: Re: Windows build broken again: urgent


In general I think a good course of action when this happens is:

* Use git bisect to find the offending commit. This works now because we moved 
to submodules.
* Revert the commit.
* Push the patch to master and notify the author.

This style of early rollback will become more important as we grow as it puts 
the onus on fixing on the right person and minimizes negative impact on other 
developers.
On Dec 1, 2014 9:43 AM, "Herbert Valerio Riedel" 
mailto:hvrie...@gmail.com>> wrote:
Hello Simon,

On 2014-12-01 at 09:38:37 +0100, Simon Peyton Jones wrote:
> |  Just a hunch... could it have been broken by one of the recent linker-
> |  related patches since Nov 24th?
>
> That seems very plausible, yes.  But still there's the question of
> what to do about it.

 a) Empirically: Try locally 'git revert'ing

 383733b9191a36e2d3f757700842dbc3855911d9

 and/or

 b5e8b3b162b3ff15ae6caf1afc659565365f54a8

 and see if your problem goes away, or

 b) Ask Simon Marlow (he either wrote or reviewed those two patches) if
he sees something odd in those patches that could have broken
Windows' GHCi...

Cheers,
  hvr
___
ghc-devs mailing list
ghc-devs@haskell.org
http://www.haskell.org/mailman/listinfo/ghc-devs
___
ghc-devs mailing list
ghc-devs@haskell.org
http://www.haskell.org/mailman/listinfo/ghc-devs

GHC Weekly News - 2014/12/01

[Austin Seipp]

Hi *,

It's that time again for some good ol' fashion GHC news, this time
just after the holidays. Some of the things happening in the past week
include:

  - Partial Type Signatures has been merged into HEAD. Many thanks to
Thomas Winant, who worked on this feature for several months!

  - As mentioned last week, GHC 7.10 will no longer ship `haskell98`
and `haskell2010`, nor `old-time` or `old-locale`.

  - Neil Mitchell asked a very good question on `ghc-devs`: what's the
process for getting your library synced for the GHC 7.10 release? As
the maintainer of `filepath` he'd like to know, and Herbert responded
quickly: https://www.haskell.org/pipermail/ghc-devs/2014-November/007394.html

  - Yuras Shumovich has more questions about exception handling,
primarily: why is `mask` used in `waitQSem`? Simon Marlow responds:
https://www.haskell.org/pipermail/ghc-devs/2014-November/007394.html

  - Carter Schonwald reports that GHC is having problems building on
OS X with XCode 6, but Kazu Yamamoto replied he had no problem -
perhaps some OS X wizards can help figure out the discrepancy:
https://www.haskell.org/pipermail/ghc-devs/2014-November/007394.html

  - Austin Seipp announced GHC 7.8.4 Release Candidate 1, with about a
dozen bugfixes for major features:
https://www.haskell.org/pipermail/ghc-devs/2014-November/007438.html

  - Gergo Erdi asked about backporting pattern synonym type signatures
to 7.8.4. The conclusion? Probably won't happen - it's a bit too late!
https://www.haskell.org/pipermail/ghc-devs/2014-November/007440.html

  - Carter Schonwald had some questions about the let-app invariant
and primop code, which he was puzzling about to help with some code
generation work. There are also some nice discussions of caches and
prefetching in pure programs later on, too:
https://www.haskell.org/pipermail/ghc-devs/2014-November/007440.html &
https://www.haskell.org/pipermail/ghc-devs/2014-November/007410.html

  - Ben Gamari talked about the current status of GHC and LLVM, GHC on
ARM, and the future of our LLVM support on both the mailing lists, and
his blog. A good read overall for those interested in the war-stories
of GHC-on-ARM: 
https://www.haskell.org/pipermail/ghc-devs/2014-November/007469.html

Closed tickets this week include: #9827, #7475, #9826, #7460, #7643,
#8044, #8031, #7072, #3654, #7033, #9834, #6098, #6022, #5859, #5763,
#9838, #9830, #7243, #9736, #9574, #5158, #9844, #9281, #9818, #4429,
#8815, #2182, #4290, #9005, #9828, #9833, #9582, and #9850.

Another huge thanks to **Thomas Miedema** who closed an extraordinary
amount of tickets for us - the above list is still not even complete,
and he's made a huge impact on the amount of open tickets in the past
month or so.

-- 
Regards,

Austin Seipp, Haskell Consultant
Well-Typed LLP, http://www.well-typed.com/
___
ghc-devs mailing list
ghc-devs@haskell.org
http://www.haskell.org/mailman/listinfo/ghc-devs

Re: Back-porting pattern synonym type signature syntax for GHC 7.8.4 [Re: ANNOUNCE: GHC 7.8.4 Release Candidate 1]

[Gabor Greif]

Gergö,

even if it might be too late for 7.8.4, don't give up hope for 7.8.5 :-)

 Gabor


On 11/29/14, Dr. ERDI Gergo  wrote:
> On Wed, 26 Nov 2014, Simon Peyton Jones wrote:
>
>> My instinct is that (a)-(c) overwhelm (d); i.e. let sleeping dogs lie.
>> But what do others think?
>
> Just to give an idea of how limited the scope of this change would be,
> I've went and implemented it, on the 'wip/pattern-synonym-sig-backport'
> branch (of both GHC and Haddock).
> ___
> ghc-devs mailing list
> ghc-devs@haskell.org
> http://www.haskell.org/mailman/listinfo/ghc-devs
>
___
ghc-devs mailing list
ghc-devs@haskell.org
http://www.haskell.org/mailman/listinfo/ghc-devs

Re: [commit: ghc] master: Fix the handling of instance signatures (Trac #9582, #9833) (e6a2050)

[Gabor Greif]

Maybe this (https://ghc.haskell.org/trac/ghc/ticket/7908) is fixed too?

Cheers,

Gabor

On 12/1/14, g...@git.haskell.org  wrote:
> Repository : ssh://g...@git.haskell.org/ghc
>
> On branch  : master
> Link   :
> http://ghc.haskell.org/trac/ghc/changeset/e6a2050ebb6da316aecec66a6795715fbab355ca/ghc
>
>>---
>
> commit e6a2050ebb6da316aecec66a6795715fbab355ca
> Author: Simon Peyton Jones 
> Date:   Mon Dec 1 11:43:20 2014 +
>
> Fix the handling of instance signatures (Trac #9582, #9833)
>
> This finally solves the issue of instance-method signatures that are
> more polymorphic than the instanted class method.
>
> See Note [Instance method signatures] in TcInstDcls.
>
> A very nice fix for the two Trac tickets above.
>
>
>>---
>
> e6a2050ebb6da316aecec66a6795715fbab355ca
>  compiler/typecheck/TcBinds.lhs |  18 ++-
>  compiler/typecheck/TcClassDcl.lhs  |  16 +--
>  compiler/typecheck/TcInstDcls.lhs  | 121
> -
>  docs/users_guide/glasgow_exts.xml  |  29 -
>  .../tests/indexed-types/should_compile/T9582.hs|  14 +++
>  testsuite/tests/indexed-types/should_compile/all.T |   1 +
>  testsuite/tests/polykinds/T9833.hs |  18 +++
>  testsuite/tests/polykinds/all.T|   2 +
>  testsuite/tests/typecheck/should_fail/T6001.stderr |   9 +-
>  testsuite/tests/typecheck/should_fail/T7545.hs |   1 +
>  testsuite/tests/typecheck/should_fail/T7545.stderr |   5 -
>  testsuite/tests/typecheck/should_fail/all.T|   2 +-
>  12 files changed, 157 insertions(+), 79 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 e6a2050ebb6da316aecec66a6795715fbab355ca
> ___
> ghc-commits mailing list
> ghc-comm...@haskell.org
> http://www.haskell.org/mailman/listinfo/ghc-commits
>
___
ghc-devs mailing list
ghc-devs@haskell.org
http://www.haskell.org/mailman/listinfo/ghc-devs

Re: Windows build broken again: urgent

[Johan Tibell]

Yes, ideally this would have been caught by a Windows build bot.

On Mon, Dec 1, 2014 at 4:34 PM, Simon Peyton Jones 
wrote:

>  Indeed.  But each bisect takes quite a while.  So my attention switches
> and it takes a while to get back.  I was hoping some machine might do it
> for me.
>
>
>
> Herbert suggested some commits to revert. I’ll try that first
>
>
>
> *From:* Johan Tibell [mailto:johan.tib...@gmail.com]
> *Sent:* 01 December 2014 09:45
> *To:* Herbert Valerio Riedel
> *Cc:* ghc-devs@haskell.org; Simon Marlow; Simon Peyton Jones
> *Subject:* Re: Windows build broken again: urgent
>
>
>
> In general I think a good course of action when this happens is:
>
> * Use git bisect to find the offending commit. This works now because we
> moved to submodules.
> * Revert the commit.
> * Push the patch to master and notify the author.
>
> This style of early rollback will become more important as we grow as it
> puts the onus on fixing on the right person and minimizes negative impact
> on other developers.
>
> On Dec 1, 2014 9:43 AM, "Herbert Valerio Riedel" 
> wrote:
>
> Hello Simon,
>
> On 2014-12-01 at 09:38:37 +0100, Simon Peyton Jones wrote:
> > |  Just a hunch... could it have been broken by one of the recent linker-
> > |  related patches since Nov 24th?
> >
> > That seems very plausible, yes.  But still there's the question of
> > what to do about it.
>
>  a) Empirically: Try locally 'git revert'ing
>
>  383733b9191a36e2d3f757700842dbc3855911d9
>
>  and/or
>
>  b5e8b3b162b3ff15ae6caf1afc659565365f54a8
>
>  and see if your problem goes away, or
>
>  b) Ask Simon Marlow (he either wrote or reviewed those two patches) if
> he sees something odd in those patches that could have broken
> Windows' GHCi...
>
> Cheers,
>   hvr
> ___
> ghc-devs mailing list
> ghc-devs@haskell.org
> http://www.haskell.org/mailman/listinfo/ghc-devs
>
>
___
ghc-devs mailing list
ghc-devs@haskell.org
http://www.haskell.org/mailman/listinfo/ghc-devs

Re: Status and future of the LLVM backend

[Ben Gamari]

Joachim Breitner  writes:

> Hi,
>
>
> Am Montag, den 01.12.2014, 09:42 +0100 schrieb Joachim Breitner:
>> Am Sonntag, den 30.11.2014, 18:49 -0500 schrieb Ben Gamari:
>> > I suspect that it this is the gold issue. I should have looked at your
>> > command line a bit more carefully; I suspect you want 
>> > 
>> > SRC_HC_OPTS += -optl-B/usr/bin/ld.gold
>> > 
>> > Hopefully this will do it; at least the option appears to make it to the
>> > right phase now.
>> 
>> Trying it right now...
>
> no success, same error:
> https://buildd.debian.org/status/fetch.php?pkg=ghc&arch=armhf&ver=7.8.20141119-6&stamp=1417438953&file=log
>
Is there any way you could poke around at the state of the tree after
the failure? It would be nice to confirm that this is in fact that
bfd/gold issue and perhaps figure out why ld.gold isn't being used.

Otherwise I can try to reproduce this on my ARM box.

Cheers,

- Ben


pgp7eO547edbK.pgp
Description: PGP signature
___
ghc-devs mailing list
ghc-devs@haskell.org
http://www.haskell.org/mailman/listinfo/ghc-devs

more parser conflicts?

[Richard Eisenberg]

Hi devs,

In unrelated work, I saw this scroll across when happy'ing the parser:

> shift/reduce conflicts:  60
> reduce/reduce conflicts: 16

These numbers seem quite a bit higher than what I last remember (which is 
something like 48 and 1, not 60 and 16). Does anyone know why?

Thanks,
Richard
___
ghc-devs mailing list
ghc-devs@haskell.org
http://www.haskell.org/mailman/listinfo/ghc-devs

Re: help wrt semantics / primops for pure prefetches

[Gregory Collins]

On Sat, Nov 29, 2014 at 6:33 PM, Carter Schonwald <
carter.schonw...@gmail.com> wrote:

> @greg, i'd love more code review if you dont mind :)


I'm not familiar enough with the relevant code to have anything to say
about your patch one way or the other, I'm afraid :(.

LGTM, in principle.

G
-- 
Gregory Collins 
___
ghc-devs mailing list
ghc-devs@haskell.org
http://www.haskell.org/mailman/listinfo/ghc-devs

RE: [commit: ghc] master: Fix the handling of instance signatures (Trac #9582, #9833) (e6a2050)

[Simon Peyton Jones]

Good point, thank you!

| -Original Message-
| From: ghc-devs [mailto:ghc-devs-boun...@haskell.org] On Behalf Of Gabor
| Greif
| Sent: 01 December 2014 16:01
| To: ghc-devs@haskell.org
| Subject: Re: [commit: ghc] master: Fix the handling of instance
| signatures (Trac #9582, #9833) (e6a2050)
| 
| Maybe this (https://ghc.haskell.org/trac/ghc/ticket/7908) is fixed too?
| 
| Cheers,
| 
| Gabor
| 
| On 12/1/14, g...@git.haskell.org  wrote:
| > Repository : ssh://g...@git.haskell.org/ghc
| >
| > On branch  : master
| > Link   :
| >
| http://ghc.haskell.org/trac/ghc/changeset/e6a2050ebb6da316aecec66a6795715
| fbab355ca/ghc
| >
| >>---
| >
| > commit e6a2050ebb6da316aecec66a6795715fbab355ca
| > Author: Simon Peyton Jones 
| > Date:   Mon Dec 1 11:43:20 2014 +
| >
| > Fix the handling of instance signatures (Trac #9582, #9833)
| >
| > This finally solves the issue of instance-method signatures that
| are
| > more polymorphic than the instanted class method.
| >
| > See Note [Instance method signatures] in TcInstDcls.
| >
| > A very nice fix for the two Trac tickets above.
| >
| >
| >>---
| >
| > e6a2050ebb6da316aecec66a6795715fbab355ca
| >  compiler/typecheck/TcBinds.lhs |  18 ++-
| >  compiler/typecheck/TcClassDcl.lhs  |  16 +--
| >  compiler/typecheck/TcInstDcls.lhs  | 121
| > -
| >  docs/users_guide/glasgow_exts.xml  |  29 -
| >  .../tests/indexed-types/should_compile/T9582.hs|  14 +++
| >  testsuite/tests/indexed-types/should_compile/all.T |   1 +
| >  testsuite/tests/polykinds/T9833.hs |  18 +++
| >  testsuite/tests/polykinds/all.T|   2 +
| >  testsuite/tests/typecheck/should_fail/T6001.stderr |   9 +-
| >  testsuite/tests/typecheck/should_fail/T7545.hs |   1 +
| >  testsuite/tests/typecheck/should_fail/T7545.stderr |   5 -
| >  testsuite/tests/typecheck/should_fail/all.T|   2 +-
| >  12 files changed, 157 insertions(+), 79 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 e6a2050ebb6da316aecec66a6795715fbab355ca
| > ___
| > ghc-commits mailing list
| > ghc-comm...@haskell.org
| > http://www.haskell.org/mailman/listinfo/ghc-commits
| >
| ___
| ghc-devs mailing list
| ghc-devs@haskell.org
| http://www.haskell.org/mailman/listinfo/ghc-devs
___
ghc-devs mailing list
ghc-devs@haskell.org
http://www.haskell.org/mailman/listinfo/ghc-devs

RE: Back-porting pattern synonym type signature syntax for GHC 7.8.4 [Re: ANNOUNCE: GHC 7.8.4 Release Candidate 1]

[Simon Peyton Jones]

The issue is not so much timing for 7.8.4 (it's a modes change to 
pretty-printing only) but rather that it would make 7.8.4 behave differently to 
7.8.3 (although similarly to 7.10). We typically do not do that.  And the same 
would be true of 7.8.5.

Simon

| -Original Message-
| From: Gabor Greif [mailto:ggr...@gmail.com]
| Sent: 01 December 2014 15:53
| To: Dr. ERDI Gergo
| Cc: Simon Peyton Jones; ghc-devs@haskell.org
| Subject: Re: Back-porting pattern synonym type signature syntax for GHC
| 7.8.4 [Re: ANNOUNCE: GHC 7.8.4 Release Candidate 1]
| 
| Gergö,
| 
| even if it might be too late for 7.8.4, don't give up hope for 7.8.5 :-)
| 
|  Gabor
| 
| 
| On 11/29/14, Dr. ERDI Gergo  wrote:
| > On Wed, 26 Nov 2014, Simon Peyton Jones wrote:
| >
| >> My instinct is that (a)-(c) overwhelm (d); i.e. let sleeping dogs lie.
| >> But what do others think?
| >
| > Just to give an idea of how limited the scope of this change would be,
| > I've went and implemented it, on the 'wip/pattern-synonym-sig-backport'
| > branch (of both GHC and Haddock).
| > ___
| > ghc-devs mailing list
| > ghc-devs@haskell.org
| > http://www.haskell.org/mailman/listinfo/ghc-devs
| >
___
ghc-devs mailing list
ghc-devs@haskell.org
http://www.haskell.org/mailman/listinfo/ghc-devs

RE: Possible error with strict_mark in Parser.y

[Simon Peyton Jones]

Thanks.  It was totally wrong.  I have fixed it. 

Simon

| -Original Message-
| From: ghc-devs [mailto:ghc-devs-boun...@haskell.org] On Behalf Of Jan
| Stolarek
| Sent: 01 December 2014 09:45
| To: ghc-devs@haskell.org
| Subject: Re: Possible error with strict_mark in Parser.y
| 
| Looking at the source code comments it seems that you're right:
| 
| data HsBang
|   = HsUserBang   -- The user's source-code request
|(Maybe Bool)   -- Just True{-# UNPACK #-}
|   -- Just False   {-# NOUNPACK #-}
|   -- Nothing  no pragma
|Bool   -- True <=> '!' specified
| 
| 
| Can anyone confirm?
| 
| Janek
| 
| Dnia niedziela, 30 listopada 2014, Alan & Kim Zimmerman napisał:
| > If I look at the production for strict_mark in the parser
| >
| > https://github.com/ghc/ghc/blob/master/compiler/parser/Parser.y#L1355
| >
| > strict_mark :: { Located ([AddAnn],HsBang) }
| >
| > : '!'{ sL1 $1 ([],HsUserBang Nothing
| >
| > True) }
| >
| > | '{-# UNPACK' '#-}' { sLL $1 $> ([mo $1,mc
| $2],HsUserBang
| >
| > (Just True)  False) }
| >
| > | '{-# NOUNPACK' '#-}'   { sLL $1 $> ([mo $1,mc
| $2],HsUserBang
| >
| > (Just False) True) } -- ***Correct?
| >
| > | '{-# UNPACK' '#-}' '!' { sLL $1 $> ([mo $1,mc
| $2],HsUserBang
| >
| > (Just True)  True) }
| >
| > | '{-# NOUNPACK' '#-}' '!'   { sLL $1 $> ([mo $1,mc
| $2],HsUserBang
| >
| > (Just False) True) }
| >
| > I would expect the final True or False value to reflect the presence of
| the
| > '!' mark.
| >
| > But the second line has no '!' but returns True.
| >
| > I suspect this is an error.
| >
| > Alan
| 
| 
| 
| ___
| ghc-devs mailing list
| ghc-devs@haskell.org
| http://www.haskell.org/mailman/listinfo/ghc-devs
___
ghc-devs mailing list
ghc-devs@haskell.org
http://www.haskell.org/mailman/listinfo/ghc-devs

Re: [commit: ghc] master: Fix the handling of instance signatures (Trac #9582, #9833) (e6a2050)

[Gabor Greif]

I tried to build HEAD to verify this, but got a linker error. IIRC when I
filed this bug I provided a test case which did compile, but you had to
uncomment signatures to see an error. I did not see those sigs uncommented
in your repro checkin.

So it might be too early for a party...

   Gabor

Em segunda-feira, 1 de dezembro de 2014, Simon Peyton Jones <
simo...@microsoft.com> escreveu:

> Good point, thank you!
>
> | -Original Message-
> | From: ghc-devs [mailto:ghc-devs-boun...@haskell.org ] On
> Behalf Of Gabor
> | Greif
> | Sent: 01 December 2014 16:01
> | To: ghc-devs@haskell.org 
> | Subject: Re: [commit: ghc] master: Fix the handling of instance
> | signatures (Trac #9582, #9833) (e6a2050)
> |
> | Maybe this (https://ghc.haskell.org/trac/ghc/ticket/7908) is fixed too?
> |
> | Cheers,
> |
> | Gabor
> |
> | On 12/1/14, g...@git.haskell.org   > wrote:
> | > Repository : ssh://g...@git.haskell.org/ghc
> | >
> | > On branch  : master
> | > Link   :
> | >
> |
> http://ghc.haskell.org/trac/ghc/changeset/e6a2050ebb6da316aecec66a6795715
> | fbab355ca/ghc
> | >
> | >>---
> | >
> | > commit e6a2050ebb6da316aecec66a6795715fbab355ca
> | > Author: Simon Peyton Jones >
> | > Date:   Mon Dec 1 11:43:20 2014 +
> | >
> | > Fix the handling of instance signatures (Trac #9582, #9833)
> | >
> | > This finally solves the issue of instance-method signatures that
> | are
> | > more polymorphic than the instanted class method.
> | >
> | > See Note [Instance method signatures] in TcInstDcls.
> | >
> | > A very nice fix for the two Trac tickets above.
> | >
> | >
> | >>---
> | >
> | > e6a2050ebb6da316aecec66a6795715fbab355ca
> | >  compiler/typecheck/TcBinds.lhs |  18 ++-
> | >  compiler/typecheck/TcClassDcl.lhs  |  16 +--
> | >  compiler/typecheck/TcInstDcls.lhs  | 121
> | > -
> | >  docs/users_guide/glasgow_exts.xml  |  29 -
> | >  .../tests/indexed-types/should_compile/T9582.hs|  14 +++
> | >  testsuite/tests/indexed-types/should_compile/all.T |   1 +
> | >  testsuite/tests/polykinds/T9833.hs |  18 +++
> | >  testsuite/tests/polykinds/all.T|   2 +
> | >  testsuite/tests/typecheck/should_fail/T6001.stderr |   9 +-
> | >  testsuite/tests/typecheck/should_fail/T7545.hs |   1 +
> | >  testsuite/tests/typecheck/should_fail/T7545.stderr |   5 -
> | >  testsuite/tests/typecheck/should_fail/all.T|   2 +-
> | >  12 files changed, 157 insertions(+), 79 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 e6a2050ebb6da316aecec66a6795715fbab355ca
> | > ___
> | > ghc-commits mailing list
> | > ghc-comm...@haskell.org 
> | > http://www.haskell.org/mailman/listinfo/ghc-commits
> | >
> | ___
> | ghc-devs mailing list
> | ghc-devs@haskell.org 
> | http://www.haskell.org/mailman/listinfo/ghc-devs
>
___
ghc-devs mailing list
ghc-devs@haskell.org
http://www.haskell.org/mailman/listinfo/ghc-devs

RE: Back-porting pattern synonym type signature syntax for GHC 7.8.4 [Re: ANNOUNCE: GHC 7.8.4 Release Candidate 1]

[Dr . ÉRDI Gergő]

It is clear to everyone that all it would change is the *output* of GHCi's
:info and Haddock-generated docs, right? There's no change whatsoever to
what programs are accepted by GHC, or what they mean.
On Dec 2, 2014 5:44 AM, "Simon Peyton Jones"  wrote:

> The issue is not so much timing for 7.8.4 (it's a modes change to
> pretty-printing only) but rather that it would make 7.8.4 behave
> differently to 7.8.3 (although similarly to 7.10). We typically do not do
> that.  And the same would be true of 7.8.5.
>
> Simon
>
> | -Original Message-
> | From: Gabor Greif [mailto:ggr...@gmail.com]
> | Sent: 01 December 2014 15:53
> | To: Dr. ERDI Gergo
> | Cc: Simon Peyton Jones; ghc-devs@haskell.org
> | Subject: Re: Back-porting pattern synonym type signature syntax for GHC
> | 7.8.4 [Re: ANNOUNCE: GHC 7.8.4 Release Candidate 1]
> |
> | Gergö,
> |
> | even if it might be too late for 7.8.4, don't give up hope for 7.8.5 :-)
> |
> |  Gabor
> |
> |
> | On 11/29/14, Dr. ERDI Gergo  wrote:
> | > On Wed, 26 Nov 2014, Simon Peyton Jones wrote:
> | >
> | >> My instinct is that (a)-(c) overwhelm (d); i.e. let sleeping dogs lie.
> | >> But what do others think?
> | >
> | > Just to give an idea of how limited the scope of this change would be,
> | > I've went and implemented it, on the 'wip/pattern-synonym-sig-backport'
> | > branch (of both GHC and Haddock).
> | > ___
> | > ghc-devs mailing list
> | > ghc-devs@haskell.org
> | > http://www.haskell.org/mailman/listinfo/ghc-devs
> | >
>
___
ghc-devs mailing list
ghc-devs@haskell.org
http://www.haskell.org/mailman/listinfo/ghc-devs

Re: Back-porting pattern synonym type signature syntax for GHC 7.8.4 [Re: ANNOUNCE: GHC 7.8.4 Release Candidate 1]

[Gabor Greif]

So it could be regarded as a bugfix?

Em terça-feira, 2 de dezembro de 2014, Dr. ÉRDI Gergő 
escreveu:

> It is clear to everyone that all it would change is the *output* of GHCi's
> :info and Haddock-generated docs, right? There's no change whatsoever to
> what programs are accepted by GHC, or what they mean.
> On Dec 2, 2014 5:44 AM, "Simon Peyton Jones"  > wrote:
>
>> The issue is not so much timing for 7.8.4 (it's a modes change to
>> pretty-printing only) but rather that it would make 7.8.4 behave
>> differently to 7.8.3 (although similarly to 7.10). We typically do not do
>> that.  And the same would be true of 7.8.5.
>>
>> Simon
>>
>> | -Original Message-
>> | From: Gabor Greif [mailto:ggr...@gmail.com
>> ]
>> | Sent: 01 December 2014 15:53
>> | To: Dr. ERDI Gergo
>> | Cc: Simon Peyton Jones; ghc-devs@haskell.org
>> 
>> | Subject: Re: Back-porting pattern synonym type signature syntax for GHC
>> | 7.8.4 [Re: ANNOUNCE: GHC 7.8.4 Release Candidate 1]
>> |
>> | Gergö,
>> |
>> | even if it might be too late for 7.8.4, don't give up hope for 7.8.5 :-)
>> |
>> |  Gabor
>> |
>> |
>> | On 11/29/14, Dr. ERDI Gergo > > wrote:
>> | > On Wed, 26 Nov 2014, Simon Peyton Jones wrote:
>> | >
>> | >> My instinct is that (a)-(c) overwhelm (d); i.e. let sleeping dogs
>> lie.
>> | >> But what do others think?
>> | >
>> | > Just to give an idea of how limited the scope of this change would be,
>> | > I've went and implemented it, on the
>> 'wip/pattern-synonym-sig-backport'
>> | > branch (of both GHC and Haddock).
>> | > ___
>> | > ghc-devs mailing list
>> | > ghc-devs@haskell.org
>> 
>> | > http://www.haskell.org/mailman/listinfo/ghc-devs
>> | >
>>
>
___
ghc-devs mailing list
ghc-devs@haskell.org
http://www.haskell.org/mailman/listinfo/ghc-devs

Re: Back-porting pattern synonym type signature syntax for GHC 7.8.4 [Re: ANNOUNCE: GHC 7.8.4 Release Candidate 1]

[Dr . ÉRDI Gergő]

With enough intellectual dishonesty, sure...
On Dec 2, 2014 7:29 AM, "Gabor Greif"  wrote:

> So it could be regarded as a bugfix?
>
> Em terça-feira, 2 de dezembro de 2014, Dr. ÉRDI Gergő 
> escreveu:
>
>> It is clear to everyone that all it would change is the *output* of
>> GHCi's :info and Haddock-generated docs, right? There's no change
>> whatsoever to what programs are accepted by GHC, or what they mean.
>> On Dec 2, 2014 5:44 AM, "Simon Peyton Jones" 
>> wrote:
>>
>>> The issue is not so much timing for 7.8.4 (it's a modes change to
>>> pretty-printing only) but rather that it would make 7.8.4 behave
>>> differently to 7.8.3 (although similarly to 7.10). We typically do not do
>>> that.  And the same would be true of 7.8.5.
>>>
>>> Simon
>>>
>>> | -Original Message-
>>> | From: Gabor Greif [mailto:ggr...@gmail.com]
>>> | Sent: 01 December 2014 15:53
>>> | To: Dr. ERDI Gergo
>>> | Cc: Simon Peyton Jones; ghc-devs@haskell.org
>>> | Subject: Re: Back-porting pattern synonym type signature syntax for GHC
>>> | 7.8.4 [Re: ANNOUNCE: GHC 7.8.4 Release Candidate 1]
>>> |
>>> | Gergö,
>>> |
>>> | even if it might be too late for 7.8.4, don't give up hope for 7.8.5
>>> :-)
>>> |
>>> |  Gabor
>>> |
>>> |
>>> | On 11/29/14, Dr. ERDI Gergo  wrote:
>>> | > On Wed, 26 Nov 2014, Simon Peyton Jones wrote:
>>> | >
>>> | >> My instinct is that (a)-(c) overwhelm (d); i.e. let sleeping dogs
>>> lie.
>>> | >> But what do others think?
>>> | >
>>> | > Just to give an idea of how limited the scope of this change would
>>> be,
>>> | > I've went and implemented it, on the
>>> 'wip/pattern-synonym-sig-backport'
>>> | > branch (of both GHC and Haddock).
>>> | > ___
>>> | > ghc-devs mailing list
>>> | > ghc-devs@haskell.org
>>> | > http://www.haskell.org/mailman/listinfo/ghc-devs
>>> | >
>>>
>>
> ___
> ghc-devs mailing list
> ghc-devs@haskell.org
> http://www.haskell.org/mailman/listinfo/ghc-devs
>
>
___
ghc-devs mailing list
ghc-devs@haskell.org
http://www.haskell.org/mailman/listinfo/ghc-devs

Re: Keeping the "Newcomers" wiki page alive

[James Crayne]

I am entirely new, in fact, this is my first post on this list, and I am
not entirely sure I have picked the right spot to jump in tbh.

I tried to think of a word for this category that fits better than
difficulty, and it seems to me that the word that best captures what I
understand to be the intention is something like "Barrier" as in barrier to
entry.

Perhaps the barrier to entry might best be read component-wise, as in
Compiler-{virgin,newbie,veteren} etc? And so that could be combined into
the component tag?


On Thu, Nov 27, 2014 at 3:54 AM, Simon Marlow  wrote:

> On 13/11/2014 07:43, Jan Stolarek wrote:
>
>> I believe that current difficulty field is intended to mean "the amount
>> of time required by
>> someone who already knows what to do". Obviously, that's not the metric
>> that we want to use for
>> labelling newcomer-friendly tasks. (I wonder if the difficulty field in
>> its current form is even
>> useful to us?)
>>
>> Obviously, the metric that we want is "the amount of code familiarity
>> required to fix a bug". For
>> newcommers we probably want tickets that require knowledge of <1000 lines
>> of code.
>>
>> I think the important questions are:
>>
>> 1. Do we find the current "difficulty" field useful?
>> 2. Should we have a Trac field to label accessibility for newcomers?
>>
>> My answers are:
>> 1. No.
>>
>
> We could remove the Difficulty field, given that it hasn't really been
> useful and it can be subsumed by the keywords field for the things we want
> it for.  It was originally intended to help (a) new developers find tickets
> to work on, and (b) help us find good projects for the GSoc. Both of which
> can be keywords, so I'd be happy to get rid of Difficulty.
>
> Cheers,
> Simon
>
>
>
>
>  2. Yes, we should have a filed with accessibility levels like:
>> newcomer/intermediate/advanced/rocket science.
>>
>> If we have 2) then we can have a list of tickets in the Newcomers page
>> generated dynamically.
>>
>> Janek
>>
>> Dnia czwartek, 13 listopada 2014, Richard Eisenberg napisał:
>>
>>> Forgive me if I'm repeating others' comments, but the newcomer label, to
>>> me, is independent of level of difficulty -- it has much more to do with
>>> how "messy" the work is, I think.
>>>
>>> I'll make a concrete proposal: Tag appropriate bugs/feature requests with
>>> "newcomer" and, if you want, mention that you'll mentor in a comment. I
>>> don't think there's a glaring need to be able to search by mentor, so I'm
>>> not proposing a Trac field for that.
>>>
>>> If I see here that a few others will adopt this proposal, I'll start
>>> doing
>>> it -- I already have several tickets in mind.
>>>
>>> Richard
>>>
>>> On Nov 12, 2014, at 6:27 PM, Isaac Hollander McCreery <
>>> ihmccre...@gmail.com> wrote:
>>>
 Glad people are excited about this,

 I like "beginner/intermediate/advanced".  I think it's more accurate
 than
 "easy/hard" and clearer than "accessible", "welcoming", etc.

 I also want to call out the "mentor" label that the Rust team is using:
 experienced devs nominate themselves as mentors on projects, then
 newcomers can tackle them with some support.  As a newcomer, that's
 *extremely* appealing to me.

 Cheers,
 Ike

 On Wed, Nov 12, 2014 at 2:34 PM, Brandon Allbery 
 wrote: On Wed, Nov 12, 2014 at 5:32 PM, Joachim Breitner
  wrote: The quality that we are looking for
 is
 “tacklabe by a newcomer“, i.e. not requiring too deep knowledge of GHC.
 Is there a nice word for that? I found “accessible”, “welcoming”,
 “appealing” – anything that sounds good in native English speaker’s
 ears?
 :-)

 Various projects I'm involved with use

 difficulty: beginner (or just "beginner")
 babydev-bait (!)
 newcomer (several use "newbie" but I do not recommend that label)

 --
 brandon s allbery kf8nh   sine nomine
 associates allber...@gmail.com
 ballb...@sinenomine.net unix, openafs, kerberos, infrastructure, xmonad
   http://sinenomine.net

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


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

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