TypeLits question, how to build a Type Application with Symbol index

[Gabor Greif]

Hello devs,

I have

{{{
data D (n :: Symbol)
}}}

in my module, and I want to obtain a type

{{{
D "YAY!"
}}}

programmatically. Where can I find code that performs this (or
something similar)?

1) I have to look up |D| in the current TyEnv (what if it is in a
specific module?),
2) I have to build the type index (of kind Symbol), this involves
FastString, looks non-trivial,
3) Apply 1) on 2), this is easy.

Any hints welcome!

Thanks and cheers,

Gabor


PS: some morsels I have so far:

for 1)
compiler/prelude/PrelNames.lhs:gHC_GENERICS= mkBaseModule (fsLit
"GHC.Generics")
___
ghc-devs mailing list
ghc-devs@haskell.org
http://www.haskell.org/mailman/listinfo/ghc-devs

RE: HEADS-UP: Git submodule conversion imminent

[Simon Peyton Jones]

| > - if I have a tree with a bunch of as-yet-unpushed commits, what do I
| > do?
| 
| If you have as-yet-unpushed commits in ghc.git, there shouldn't be
| anything special to handle. Or were you referring to the case of having
| unpushed commits in the converted sub-repos?

I meant mainly in ghc.git, so what you say is reassuring.  Thank you!

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

RE: Two days old build breakage on i386.

[Simon Peyton Jones]

Thank you!!

From: Johan Tibell [mailto:johan.tib...@gmail.com]
Sent: 26 June 2014 14:06
To: Simon Peyton Jones
Cc: Karel Gardas; ghc-devs
Subject: Re: Two days old build breakage on i386.

Herbert pushed my revert for me a minute ago. Everyone should be good once they 
sync.

On Thu, Jun 26, 2014 at 2:51 PM, Johan Tibell 
mailto:johan.tib...@gmail.com>> wrote:
I guess you don't have 04dd7cb3423f1940242fdfe2ea2e3b8abd68a177 (which I pushed 
this morning) which is fine. You should be in a good state now when 
d8abf85f8ca176854e9d5d0b12371c4bc402aac3 is reverted.

On Thu, Jun 26, 2014 at 2:49 PM, Simon Peyton Jones 
mailto:simo...@microsoft.com>> wrote:

git revert d8abf85f8ca176854e9d5d0b12371c4bc402aac3

[master f958079] Revert "Add more primops for atomic ops on byte arrays"

23 files changed, 86 insertions(+), 1016 deletions(-)

rewrite compiler/nativeGen/CPrim.hs (62%)

delete mode 100644 libraries/ghc-prim/cbits/atomic.c

delete mode 100644 testsuite/tests/concurrent/should_run/AtomicPrimops.hs

delete mode 100644 testsuite/tests/concurrent/should_run/AtomicPrimops.stdout

HEAD $ git revert 04dd7cb3423f1940242fdfe2ea2e3b8abd68a177

fatal: bad object 04dd7cb3423f1940242fdfe2ea2e3b8abd68a177

HEAD $
What now?
Simon

From: Johan Tibell 
[mailto:johan.tib...@gmail.com]
Sent: 26 June 2014 13:25
To: Simon Peyton Jones
Cc: Karel Gardas; ghc-devs
Subject: Re: Two days old build breakage on i386.

Just to make sure this is the same breakage, are you on an i386 Windows 
machine? If so git revert d8abf85f8ca176854e9d5d0b12371c4bc402aac3 and 
04dd7cb3423f1940242fdfe2ea2e3b8abd68a177 to get unstuck.

On Thu, Jun 26, 2014 at 2:13 PM, Simon Peyton Jones 
mailto:simo...@microsoft.com>> wrote:
Aaaargh!  Once again the Windows build is broken.  I am utterly stalled.

Moreover -fregs-graph and -fregs-iterative now *silently* do nothing.  At least 
they should elicit warnings saying that they are disabled pending the fix to X 
and Y.

Please can someone bisect to find out which patch is the culprit?

I wish we had a more systematic way to find this out. I hate being the main 
person who gets stuck because some unrelated change has broken the Windows 
build.  (Thanks for Karel, who got to it a day before me.)

Thanks

Simon

| -Original Message-
| From: ghc-devs 
[mailto:ghc-devs-boun...@haskell.org] On 
Behalf Of Karel
| Gardas
| Sent: 26 June 2014 09:56
| To: ghc-devs; Johan Tibell
| Subject: Two days old build breakage on i386.
|
|
| Hello,
|
| builders running on i386 building for this platform caught issue which
| shows as a build breakage:
|
| ghc-stage1: panic! (the 'impossible' happened)
| (GHC version 7.9.20140624 for i386-unknown-linux):
| RegAllocLinear.allocRegsAndSpill: no spill candidates
| allocating vreg: VirtualRegI n1Q6
| assignment: [(c1PV,InMem 2),(n1Q5,InBoth (RealRegSingle 3)
| 0),(n1Q6,InMem 1),(n1Q7,InMem 3),(n1Q9,InReg (RealRegSingle 2))]
| freeRegs: FreeRegs 4282318848
| initFreeRegs: FreeRegs 4282318861
| Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug
| make[1]: ***
| [libraries/ghc-prim/dist-install/build/GHC/PrimopWrappers.o] Error 1
| libraries/ghc-prim/ghc.mk:4: recipe for target
| 'libraries/ghc-prim/dist-install/build/GHC/PrimopWrappers.o' failed
|
| Have a look for example on linux-i386 buildot log here:
| http://haskell.inf.elte.hu/builders/validator1-linux-x86-head/18/7.html
|
| Anyway, this happens on Linux, FreeBSD and Solaris buildbots on i386 so
| it's OS independent and probably 32bit/i386 platform specific and it's
| two days old breakage now. The last two night builds fail on all
| mentioned buildbots. I'm not sure but perhaps:
|
| commit d8abf85f8ca176854e9d5d0b12371c4bc402aac3
| Author: Johan Tibell mailto:johan.tib...@gmail.com>>
| Date:   Mon Jun 9 11:43:21 2014 +0200
|
| triggers that issue? I'm not claiming that the commit is actual culprit,
| this may be just recently un-hidden issue in linear regs allocator on
| i386!
|
| Thanks!
| Karel
| ___
| 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: Two days old build breakage on i386.

[Simon Peyton Jones]

After your reversion, I can build again.  Thanks!

From: Johan Tibell [mailto:johan.tib...@gmail.com]
Sent: 26 June 2014 13:51
To: Simon Peyton Jones
Cc: Karel Gardas; ghc-devs
Subject: Re: Two days old build breakage on i386.

I guess you don't have 04dd7cb3423f1940242fdfe2ea2e3b8abd68a177 (which I pushed 
this morning) which is fine. You should be in a good state now when 
d8abf85f8ca176854e9d5d0b12371c4bc402aac3 is reverted.

On Thu, Jun 26, 2014 at 2:49 PM, Simon Peyton Jones 
mailto:simo...@microsoft.com>> wrote:

git revert d8abf85f8ca176854e9d5d0b12371c4bc402aac3

[master f958079] Revert "Add more primops for atomic ops on byte arrays"

23 files changed, 86 insertions(+), 1016 deletions(-)

rewrite compiler/nativeGen/CPrim.hs (62%)

delete mode 100644 libraries/ghc-prim/cbits/atomic.c

delete mode 100644 testsuite/tests/concurrent/should_run/AtomicPrimops.hs

delete mode 100644 testsuite/tests/concurrent/should_run/AtomicPrimops.stdout

HEAD $ git revert 04dd7cb3423f1940242fdfe2ea2e3b8abd68a177

fatal: bad object 04dd7cb3423f1940242fdfe2ea2e3b8abd68a177

HEAD $
What now?
Simon

From: Johan Tibell 
[mailto:johan.tib...@gmail.com]
Sent: 26 June 2014 13:25
To: Simon Peyton Jones
Cc: Karel Gardas; ghc-devs
Subject: Re: Two days old build breakage on i386.

Just to make sure this is the same breakage, are you on an i386 Windows 
machine? If so git revert d8abf85f8ca176854e9d5d0b12371c4bc402aac3 and 
04dd7cb3423f1940242fdfe2ea2e3b8abd68a177 to get unstuck.

On Thu, Jun 26, 2014 at 2:13 PM, Simon Peyton Jones 
mailto:simo...@microsoft.com>> wrote:
Aaaargh!  Once again the Windows build is broken.  I am utterly stalled.

Moreover -fregs-graph and -fregs-iterative now *silently* do nothing.  At least 
they should elicit warnings saying that they are disabled pending the fix to X 
and Y.

Please can someone bisect to find out which patch is the culprit?

I wish we had a more systematic way to find this out. I hate being the main 
person who gets stuck because some unrelated change has broken the Windows 
build.  (Thanks for Karel, who got to it a day before me.)

Thanks

Simon

| -Original Message-
| From: ghc-devs 
[mailto:ghc-devs-boun...@haskell.org] On 
Behalf Of Karel
| Gardas
| Sent: 26 June 2014 09:56
| To: ghc-devs; Johan Tibell
| Subject: Two days old build breakage on i386.
|
|
| Hello,
|
| builders running on i386 building for this platform caught issue which
| shows as a build breakage:
|
| ghc-stage1: panic! (the 'impossible' happened)
| (GHC version 7.9.20140624 for i386-unknown-linux):
| RegAllocLinear.allocRegsAndSpill: no spill candidates
| allocating vreg: VirtualRegI n1Q6
| assignment: [(c1PV,InMem 2),(n1Q5,InBoth (RealRegSingle 3)
| 0),(n1Q6,InMem 1),(n1Q7,InMem 3),(n1Q9,InReg (RealRegSingle 2))]
| freeRegs: FreeRegs 4282318848
| initFreeRegs: FreeRegs 4282318861
| Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug
| make[1]: ***
| [libraries/ghc-prim/dist-install/build/GHC/PrimopWrappers.o] Error 1
| libraries/ghc-prim/ghc.mk:4: recipe for target
| 'libraries/ghc-prim/dist-install/build/GHC/PrimopWrappers.o' failed
|
| Have a look for example on linux-i386 buildot log here:
| http://haskell.inf.elte.hu/builders/validator1-linux-x86-head/18/7.html
|
| Anyway, this happens on Linux, FreeBSD and Solaris buildbots on i386 so
| it's OS independent and probably 32bit/i386 platform specific and it's
| two days old breakage now. The last two night builds fail on all
| mentioned buildbots. I'm not sure but perhaps:
|
| commit d8abf85f8ca176854e9d5d0b12371c4bc402aac3
| Author: Johan Tibell mailto:johan.tib...@gmail.com>>
| Date:   Mon Jun 9 11:43:21 2014 +0200
|
| triggers that issue? I'm not claiming that the commit is actual culprit,
| this may be just recently un-hidden issue in linear regs allocator on
| i386!
|
| Thanks!
| Karel
| ___
| 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: Two days old build breakage on i386.

[Johan Tibell]

Here's some more debug output. Can someone interpret it:

genRaInsn
cmpxchgl %vI_n1nF,8(%vI_n1nD,%vI_n1nE,4)
r_dying  =  [%vI_n1nD, %vI_n1nE, %vI_n1nF]
w_dying  =  []
virt_read=  [%vI_n1nD, %vI_n1nE, %vI_n1nF]
virt_written =  []
freeregs =  FreeRegs 4282318848
assig=  [n1nD :-> InMem 0,
 n1nE :-> InReg (RealRegSingle 2), n1nF :-> InReg
(RealRegSingle 3)]
ghc-stage1: panic! (the 'impossible' happened)
  (GHC version 7.9.20140626 for i386-unknown-linux):
RegAllocLinear.allocRegsAndSpill: no spill candidates

allocating vreg:  VirtualRegI n1nD
assignment:   [(n1nD,InMem 0),(n1nE,InReg (RealRegSingle
2)),(n1nF,InReg (RealRegSingle 3))]
freeRegs: FreeRegs 4282318848
initFreeRegs: FreeRegs 4282318861

(i.e. it's the cmpxchg instruction which is causing the failure.)


On Thu, Jun 26, 2014 at 8:17 PM, Johan Tibell 
wrote:

> I'm trying to understand the output from the register allocator:
>
>   (GHC version 7.9.20140626 for i386-unknown-linux):
>  RegAllocLinear.allocRegsAndSpill: no spill candidates
>
> allocating vreg:  VirtualRegI n1nD
> assignment:   [(n1nD,InMem 0),(n1nE,InReg (RealRegSingle
> 2)),(n1nF,InReg (RealRegSingle 3))]
> freeRegs: FreeRegs 4282318848
> initFreeRegs: FreeRegs 4282318861
>
> Without understanding exactly what's wrong, the message above suggests
> that we're trying to allocate a reg for n1nD, but there's already an
> assignment for that virtual reg, is that right?
>
>
>
> On Thu, Jun 26, 2014 at 3:05 PM, Johan Tibell 
> wrote:
>
>> Herbert pushed my revert for me a minute ago. Everyone should be good
>> once they sync.
>>
>>
>> On Thu, Jun 26, 2014 at 2:51 PM, Johan Tibell 
>> wrote:
>>
>>> I guess you don't have 04dd7cb3423f1940242fdfe2ea2e3b8abd68a177 (which
>>> I pushed this morning) which is fine. You should be in a good state now
>>> when d8abf85f8ca176854e9d5d0b12371c4bc402aac3 is reverted.
>>>
>>>
>>> On Thu, Jun 26, 2014 at 2:49 PM, Simon Peyton Jones <
>>> simo...@microsoft.com> wrote:
>>>
  git revert d8abf85f8ca176854e9d5d0b12371c4bc402aac3

 [master f958079] Revert "Add more primops for atomic ops on byte arrays"

 23 files changed, 86 insertions(+), 1016 deletions(-)

 rewrite compiler/nativeGen/CPrim.hs (62%)

 delete mode 100644 libraries/ghc-prim/cbits/atomic.c

 delete mode 100644
 testsuite/tests/concurrent/should_run/AtomicPrimops.hs

 delete mode 100644
 testsuite/tests/concurrent/should_run/AtomicPrimops.stdout

 HEAD $ git revert 04dd7cb3423f1940242fdfe2ea2e3b8abd68a177

 fatal: bad object 04dd7cb3423f1940242fdfe2ea2e3b8abd68a177

 HEAD $

 What now?

 Simon



 *From:* Johan Tibell [mailto:johan.tib...@gmail.com]
 *Sent:* 26 June 2014 13:25
 *To:* Simon Peyton Jones
 *Cc:* Karel Gardas; ghc-devs
 *Subject:* Re: Two days old build breakage on i386.



 Just to make sure this is the same breakage, are you on an i386 Windows
 machine? If so git revert d8abf85f8ca176854e9d5d0b12371c4bc402aac3
 and 04dd7cb3423f1940242fdfe2ea2e3b8abd68a177 to get unstuck.



 On Thu, Jun 26, 2014 at 2:13 PM, Simon Peyton Jones <
 simo...@microsoft.com> wrote:

  Aaaargh!  Once again the Windows build is broken.  I am utterly
 stalled.

 Moreover -fregs-graph and -fregs-iterative now *silently* do nothing.
  At least they should elicit warnings saying that they are disabled pending
 the fix to X and Y.

 Please can someone bisect to find out which patch is the culprit?

 I wish we had a more systematic way to find this out. I hate being the
 main person who gets stuck because some unrelated change has broken the
 Windows build.  (Thanks for Karel, who got to it a day before me.)

 Thanks

 Simon


 | -Original Message-
 | From: ghc-devs [mailto:ghc-devs-boun...@haskell.org] On Behalf Of
 Karel
 | Gardas
 | Sent: 26 June 2014 09:56
 | To: ghc-devs; Johan Tibell
 | Subject: Two days old build breakage on i386.
 |
 |
 | Hello,
 |
 | builders running on i386 building for this platform caught issue which
 | shows as a build breakage:
 |
 | ghc-stage1: panic! (the 'impossible' happened)
 | (GHC version 7.9.20140624 for i386-unknown-linux):
 | RegAllocLinear.allocRegsAndSpill: no spill candidates
 | allocating vreg: VirtualRegI n1Q6
 | assignment: [(c1PV,InMem 2),(n1Q5,InBoth (RealRegSingle 3)
 | 0),(n1Q6,InMem 1),(n1Q7,InMem 3),(n1Q9,InReg (RealRegSingle 2))]
 | freeRegs: FreeRegs 4282318848
 | initFreeRegs: FreeRegs 4282318861
 | Please report this as a GHC bug:
 http://www.haskell.org/ghc/reportabug
 | make[1]: ***
 | [libraries/ghc-prim/dist-install/build/GHC/PrimopWrappers.o] Error 1
 | librar

Re: Two days old build breakage on i386.

[Johan Tibell]

I'm trying to understand the output from the register allocator:

  (GHC version 7.9.20140626 for i386-unknown-linux):
RegAllocLinear.allocRegsAndSpill: no spill candidates

allocating vreg:  VirtualRegI n1nD
assignment:   [(n1nD,InMem 0),(n1nE,InReg (RealRegSingle
2)),(n1nF,InReg (RealRegSingle 3))]
freeRegs: FreeRegs 4282318848
initFreeRegs: FreeRegs 4282318861

Without understanding exactly what's wrong, the message above suggests that
we're trying to allocate a reg for n1nD, but there's already an assignment
for that virtual reg, is that right?



On Thu, Jun 26, 2014 at 3:05 PM, Johan Tibell 
wrote:

> Herbert pushed my revert for me a minute ago. Everyone should be good once
> they sync.
>
>
> On Thu, Jun 26, 2014 at 2:51 PM, Johan Tibell 
> wrote:
>
>> I guess you don't have 04dd7cb3423f1940242fdfe2ea2e3b8abd68a177 (which I
>> pushed this morning) which is fine. You should be in a good state now when
>> d8abf85f8ca176854e9d5d0b12371c4bc402aac3 is reverted.
>>
>>
>> On Thu, Jun 26, 2014 at 2:49 PM, Simon Peyton Jones <
>> simo...@microsoft.com> wrote:
>>
>>>  git revert d8abf85f8ca176854e9d5d0b12371c4bc402aac3
>>>
>>> [master f958079] Revert "Add more primops for atomic ops on byte arrays"
>>>
>>> 23 files changed, 86 insertions(+), 1016 deletions(-)
>>>
>>> rewrite compiler/nativeGen/CPrim.hs (62%)
>>>
>>> delete mode 100644 libraries/ghc-prim/cbits/atomic.c
>>>
>>> delete mode 100644 testsuite/tests/concurrent/should_run/AtomicPrimops.hs
>>>
>>> delete mode 100644
>>> testsuite/tests/concurrent/should_run/AtomicPrimops.stdout
>>>
>>> HEAD $ git revert 04dd7cb3423f1940242fdfe2ea2e3b8abd68a177
>>>
>>> fatal: bad object 04dd7cb3423f1940242fdfe2ea2e3b8abd68a177
>>>
>>> HEAD $
>>>
>>> What now?
>>>
>>> Simon
>>>
>>>
>>>
>>> *From:* Johan Tibell [mailto:johan.tib...@gmail.com]
>>> *Sent:* 26 June 2014 13:25
>>> *To:* Simon Peyton Jones
>>> *Cc:* Karel Gardas; ghc-devs
>>> *Subject:* Re: Two days old build breakage on i386.
>>>
>>>
>>>
>>> Just to make sure this is the same breakage, are you on an i386 Windows
>>> machine? If so git revert d8abf85f8ca176854e9d5d0b12371c4bc402aac3
>>> and 04dd7cb3423f1940242fdfe2ea2e3b8abd68a177 to get unstuck.
>>>
>>>
>>>
>>> On Thu, Jun 26, 2014 at 2:13 PM, Simon Peyton Jones <
>>> simo...@microsoft.com> wrote:
>>>
>>>  Aaaargh!  Once again the Windows build is broken.  I am utterly stalled.
>>>
>>> Moreover -fregs-graph and -fregs-iterative now *silently* do nothing.
>>>  At least they should elicit warnings saying that they are disabled pending
>>> the fix to X and Y.
>>>
>>> Please can someone bisect to find out which patch is the culprit?
>>>
>>> I wish we had a more systematic way to find this out. I hate being the
>>> main person who gets stuck because some unrelated change has broken the
>>> Windows build.  (Thanks for Karel, who got to it a day before me.)
>>>
>>> Thanks
>>>
>>> Simon
>>>
>>>
>>> | -Original Message-
>>> | From: ghc-devs [mailto:ghc-devs-boun...@haskell.org] On Behalf Of
>>> Karel
>>> | Gardas
>>> | Sent: 26 June 2014 09:56
>>> | To: ghc-devs; Johan Tibell
>>> | Subject: Two days old build breakage on i386.
>>> |
>>> |
>>> | Hello,
>>> |
>>> | builders running on i386 building for this platform caught issue which
>>> | shows as a build breakage:
>>> |
>>> | ghc-stage1: panic! (the 'impossible' happened)
>>> | (GHC version 7.9.20140624 for i386-unknown-linux):
>>> | RegAllocLinear.allocRegsAndSpill: no spill candidates
>>> | allocating vreg: VirtualRegI n1Q6
>>> | assignment: [(c1PV,InMem 2),(n1Q5,InBoth (RealRegSingle 3)
>>> | 0),(n1Q6,InMem 1),(n1Q7,InMem 3),(n1Q9,InReg (RealRegSingle 2))]
>>> | freeRegs: FreeRegs 4282318848
>>> | initFreeRegs: FreeRegs 4282318861
>>> | Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug
>>> | make[1]: ***
>>> | [libraries/ghc-prim/dist-install/build/GHC/PrimopWrappers.o] Error 1
>>> | libraries/ghc-prim/ghc.mk:4: recipe for target
>>> | 'libraries/ghc-prim/dist-install/build/GHC/PrimopWrappers.o' failed
>>> |
>>> | Have a look for example on linux-i386 buildot log here:
>>> |
>>> http://haskell.inf.elte.hu/builders/validator1-linux-x86-head/18/7.html
>>> |
>>> | Anyway, this happens on Linux, FreeBSD and Solaris buildbots on i386 so
>>> | it's OS independent and probably 32bit/i386 platform specific and it's
>>> | two days old breakage now. The last two night builds fail on all
>>> | mentioned buildbots. I'm not sure but perhaps:
>>> |
>>> | commit d8abf85f8ca176854e9d5d0b12371c4bc402aac3
>>> | Author: Johan Tibell 
>>> | Date:   Mon Jun 9 11:43:21 2014 +0200
>>> |
>>> | triggers that issue? I'm not claiming that the commit is actual
>>> culprit,
>>> | this may be just recently un-hidden issue in linear regs allocator on
>>> | i386!
>>> |
>>> | Thanks!
>>> | Karel
>>>
>>> | ___
>>> | ghc-devs mailing list
>>> | ghc-devs@haskell.org
>>> | http://www.haskell.org/mailman/listinfo/ghc-devs
>>>
>>>
>>>
>>
>>
>

Re: Two days old build breakage on i386.

[Johan Tibell]

Herbert pushed my revert for me a minute ago. Everyone should be good once
they sync.


On Thu, Jun 26, 2014 at 2:51 PM, Johan Tibell 
wrote:

> I guess you don't have 04dd7cb3423f1940242fdfe2ea2e3b8abd68a177 (which I
> pushed this morning) which is fine. You should be in a good state now when
> d8abf85f8ca176854e9d5d0b12371c4bc402aac3 is reverted.
>
>
> On Thu, Jun 26, 2014 at 2:49 PM, Simon Peyton Jones  > wrote:
>
>>  git revert d8abf85f8ca176854e9d5d0b12371c4bc402aac3
>>
>> [master f958079] Revert "Add more primops for atomic ops on byte arrays"
>>
>> 23 files changed, 86 insertions(+), 1016 deletions(-)
>>
>> rewrite compiler/nativeGen/CPrim.hs (62%)
>>
>> delete mode 100644 libraries/ghc-prim/cbits/atomic.c
>>
>> delete mode 100644 testsuite/tests/concurrent/should_run/AtomicPrimops.hs
>>
>> delete mode 100644
>> testsuite/tests/concurrent/should_run/AtomicPrimops.stdout
>>
>> HEAD $ git revert 04dd7cb3423f1940242fdfe2ea2e3b8abd68a177
>>
>> fatal: bad object 04dd7cb3423f1940242fdfe2ea2e3b8abd68a177
>>
>> HEAD $
>>
>> What now?
>>
>> Simon
>>
>>
>>
>> *From:* Johan Tibell [mailto:johan.tib...@gmail.com]
>> *Sent:* 26 June 2014 13:25
>> *To:* Simon Peyton Jones
>> *Cc:* Karel Gardas; ghc-devs
>> *Subject:* Re: Two days old build breakage on i386.
>>
>>
>>
>> Just to make sure this is the same breakage, are you on an i386 Windows
>> machine? If so git revert d8abf85f8ca176854e9d5d0b12371c4bc402aac3
>> and 04dd7cb3423f1940242fdfe2ea2e3b8abd68a177 to get unstuck.
>>
>>
>>
>> On Thu, Jun 26, 2014 at 2:13 PM, Simon Peyton Jones <
>> simo...@microsoft.com> wrote:
>>
>>  Aaaargh!  Once again the Windows build is broken.  I am utterly stalled.
>>
>> Moreover -fregs-graph and -fregs-iterative now *silently* do nothing.  At
>> least they should elicit warnings saying that they are disabled pending the
>> fix to X and Y.
>>
>> Please can someone bisect to find out which patch is the culprit?
>>
>> I wish we had a more systematic way to find this out. I hate being the
>> main person who gets stuck because some unrelated change has broken the
>> Windows build.  (Thanks for Karel, who got to it a day before me.)
>>
>> Thanks
>>
>> Simon
>>
>>
>> | -Original Message-
>> | From: ghc-devs [mailto:ghc-devs-boun...@haskell.org] On Behalf Of Karel
>> | Gardas
>> | Sent: 26 June 2014 09:56
>> | To: ghc-devs; Johan Tibell
>> | Subject: Two days old build breakage on i386.
>> |
>> |
>> | Hello,
>> |
>> | builders running on i386 building for this platform caught issue which
>> | shows as a build breakage:
>> |
>> | ghc-stage1: panic! (the 'impossible' happened)
>> | (GHC version 7.9.20140624 for i386-unknown-linux):
>> | RegAllocLinear.allocRegsAndSpill: no spill candidates
>> | allocating vreg: VirtualRegI n1Q6
>> | assignment: [(c1PV,InMem 2),(n1Q5,InBoth (RealRegSingle 3)
>> | 0),(n1Q6,InMem 1),(n1Q7,InMem 3),(n1Q9,InReg (RealRegSingle 2))]
>> | freeRegs: FreeRegs 4282318848
>> | initFreeRegs: FreeRegs 4282318861
>> | Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug
>> | make[1]: ***
>> | [libraries/ghc-prim/dist-install/build/GHC/PrimopWrappers.o] Error 1
>> | libraries/ghc-prim/ghc.mk:4: recipe for target
>> | 'libraries/ghc-prim/dist-install/build/GHC/PrimopWrappers.o' failed
>> |
>> | Have a look for example on linux-i386 buildot log here:
>> | http://haskell.inf.elte.hu/builders/validator1-linux-x86-head/18/7.html
>> |
>> | Anyway, this happens on Linux, FreeBSD and Solaris buildbots on i386 so
>> | it's OS independent and probably 32bit/i386 platform specific and it's
>> | two days old breakage now. The last two night builds fail on all
>> | mentioned buildbots. I'm not sure but perhaps:
>> |
>> | commit d8abf85f8ca176854e9d5d0b12371c4bc402aac3
>> | Author: Johan Tibell 
>> | Date:   Mon Jun 9 11:43:21 2014 +0200
>> |
>> | triggers that issue? I'm not claiming that the commit is actual culprit,
>> | this may be just recently un-hidden issue in linear regs allocator on
>> | i386!
>> |
>> | Thanks!
>> | Karel
>>
>> | ___
>> | 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: Two days old build breakage on i386.

[Johan Tibell]

I guess you don't have 04dd7cb3423f1940242fdfe2ea2e3b8abd68a177 (which I
pushed this morning) which is fine. You should be in a good state now when
d8abf85f8ca176854e9d5d0b12371c4bc402aac3 is reverted.


On Thu, Jun 26, 2014 at 2:49 PM, Simon Peyton Jones 
wrote:

>  git revert d8abf85f8ca176854e9d5d0b12371c4bc402aac3
>
> [master f958079] Revert "Add more primops for atomic ops on byte arrays"
>
> 23 files changed, 86 insertions(+), 1016 deletions(-)
>
> rewrite compiler/nativeGen/CPrim.hs (62%)
>
> delete mode 100644 libraries/ghc-prim/cbits/atomic.c
>
> delete mode 100644 testsuite/tests/concurrent/should_run/AtomicPrimops.hs
>
> delete mode 100644
> testsuite/tests/concurrent/should_run/AtomicPrimops.stdout
>
> HEAD $ git revert 04dd7cb3423f1940242fdfe2ea2e3b8abd68a177
>
> fatal: bad object 04dd7cb3423f1940242fdfe2ea2e3b8abd68a177
>
> HEAD $
>
> What now?
>
> Simon
>
>
>
> *From:* Johan Tibell [mailto:johan.tib...@gmail.com]
> *Sent:* 26 June 2014 13:25
> *To:* Simon Peyton Jones
> *Cc:* Karel Gardas; ghc-devs
> *Subject:* Re: Two days old build breakage on i386.
>
>
>
> Just to make sure this is the same breakage, are you on an i386 Windows
> machine? If so git revert d8abf85f8ca176854e9d5d0b12371c4bc402aac3
> and 04dd7cb3423f1940242fdfe2ea2e3b8abd68a177 to get unstuck.
>
>
>
> On Thu, Jun 26, 2014 at 2:13 PM, Simon Peyton Jones 
> wrote:
>
>  Aaaargh!  Once again the Windows build is broken.  I am utterly stalled.
>
> Moreover -fregs-graph and -fregs-iterative now *silently* do nothing.  At
> least they should elicit warnings saying that they are disabled pending the
> fix to X and Y.
>
> Please can someone bisect to find out which patch is the culprit?
>
> I wish we had a more systematic way to find this out. I hate being the
> main person who gets stuck because some unrelated change has broken the
> Windows build.  (Thanks for Karel, who got to it a day before me.)
>
> Thanks
>
> Simon
>
>
> | -Original Message-
> | From: ghc-devs [mailto:ghc-devs-boun...@haskell.org] On Behalf Of Karel
> | Gardas
> | Sent: 26 June 2014 09:56
> | To: ghc-devs; Johan Tibell
> | Subject: Two days old build breakage on i386.
> |
> |
> | Hello,
> |
> | builders running on i386 building for this platform caught issue which
> | shows as a build breakage:
> |
> | ghc-stage1: panic! (the 'impossible' happened)
> | (GHC version 7.9.20140624 for i386-unknown-linux):
> | RegAllocLinear.allocRegsAndSpill: no spill candidates
> | allocating vreg: VirtualRegI n1Q6
> | assignment: [(c1PV,InMem 2),(n1Q5,InBoth (RealRegSingle 3)
> | 0),(n1Q6,InMem 1),(n1Q7,InMem 3),(n1Q9,InReg (RealRegSingle 2))]
> | freeRegs: FreeRegs 4282318848
> | initFreeRegs: FreeRegs 4282318861
> | Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug
> | make[1]: ***
> | [libraries/ghc-prim/dist-install/build/GHC/PrimopWrappers.o] Error 1
> | libraries/ghc-prim/ghc.mk:4: recipe for target
> | 'libraries/ghc-prim/dist-install/build/GHC/PrimopWrappers.o' failed
> |
> | Have a look for example on linux-i386 buildot log here:
> | http://haskell.inf.elte.hu/builders/validator1-linux-x86-head/18/7.html
> |
> | Anyway, this happens on Linux, FreeBSD and Solaris buildbots on i386 so
> | it's OS independent and probably 32bit/i386 platform specific and it's
> | two days old breakage now. The last two night builds fail on all
> | mentioned buildbots. I'm not sure but perhaps:
> |
> | commit d8abf85f8ca176854e9d5d0b12371c4bc402aac3
> | Author: Johan Tibell 
> | Date:   Mon Jun 9 11:43:21 2014 +0200
> |
> | triggers that issue? I'm not claiming that the commit is actual culprit,
> | this may be just recently un-hidden issue in linear regs allocator on
> | i386!
> |
> | Thanks!
> | Karel
>
> | ___
> | 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: Two days old build breakage on i386.

[Simon Peyton Jones]

git revert d8abf85f8ca176854e9d5d0b12371c4bc402aac3

[master f958079] Revert "Add more primops for atomic ops on byte arrays"

23 files changed, 86 insertions(+), 1016 deletions(-)

rewrite compiler/nativeGen/CPrim.hs (62%)

delete mode 100644 libraries/ghc-prim/cbits/atomic.c

delete mode 100644 testsuite/tests/concurrent/should_run/AtomicPrimops.hs

delete mode 100644 testsuite/tests/concurrent/should_run/AtomicPrimops.stdout

HEAD $ git revert 04dd7cb3423f1940242fdfe2ea2e3b8abd68a177

fatal: bad object 04dd7cb3423f1940242fdfe2ea2e3b8abd68a177

HEAD $
What now?
Simon

From: Johan Tibell [mailto:johan.tib...@gmail.com]
Sent: 26 June 2014 13:25
To: Simon Peyton Jones
Cc: Karel Gardas; ghc-devs
Subject: Re: Two days old build breakage on i386.

Just to make sure this is the same breakage, are you on an i386 Windows 
machine? If so git revert d8abf85f8ca176854e9d5d0b12371c4bc402aac3 and 
04dd7cb3423f1940242fdfe2ea2e3b8abd68a177 to get unstuck.

On Thu, Jun 26, 2014 at 2:13 PM, Simon Peyton Jones 
mailto:simo...@microsoft.com>> wrote:
Aaaargh!  Once again the Windows build is broken.  I am utterly stalled.

Moreover -fregs-graph and -fregs-iterative now *silently* do nothing.  At least 
they should elicit warnings saying that they are disabled pending the fix to X 
and Y.

Please can someone bisect to find out which patch is the culprit?

I wish we had a more systematic way to find this out. I hate being the main 
person who gets stuck because some unrelated change has broken the Windows 
build.  (Thanks for Karel, who got to it a day before me.)

Thanks

Simon

| -Original Message-
| From: ghc-devs 
[mailto:ghc-devs-boun...@haskell.org] On 
Behalf Of Karel
| Gardas
| Sent: 26 June 2014 09:56
| To: ghc-devs; Johan Tibell
| Subject: Two days old build breakage on i386.
|
|
| Hello,
|
| builders running on i386 building for this platform caught issue which
| shows as a build breakage:
|
| ghc-stage1: panic! (the 'impossible' happened)
| (GHC version 7.9.20140624 for i386-unknown-linux):
| RegAllocLinear.allocRegsAndSpill: no spill candidates
| allocating vreg: VirtualRegI n1Q6
| assignment: [(c1PV,InMem 2),(n1Q5,InBoth (RealRegSingle 3)
| 0),(n1Q6,InMem 1),(n1Q7,InMem 3),(n1Q9,InReg (RealRegSingle 2))]
| freeRegs: FreeRegs 4282318848
| initFreeRegs: FreeRegs 4282318861
| Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug
| make[1]: ***
| [libraries/ghc-prim/dist-install/build/GHC/PrimopWrappers.o] Error 1
| libraries/ghc-prim/ghc.mk:4: recipe for target
| 'libraries/ghc-prim/dist-install/build/GHC/PrimopWrappers.o' failed
|
| Have a look for example on linux-i386 buildot log here:
| http://haskell.inf.elte.hu/builders/validator1-linux-x86-head/18/7.html
|
| Anyway, this happens on Linux, FreeBSD and Solaris buildbots on i386 so
| it's OS independent and probably 32bit/i386 platform specific and it's
| two days old breakage now. The last two night builds fail on all
| mentioned buildbots. I'm not sure but perhaps:
|
| commit d8abf85f8ca176854e9d5d0b12371c4bc402aac3
| Author: Johan Tibell mailto:johan.tib...@gmail.com>>
| Date:   Mon Jun 9 11:43:21 2014 +0200
|
| triggers that issue? I'm not claiming that the commit is actual culprit,
| this may be just recently un-hidden issue in linear regs allocator on
| i386!
|
| Thanks!
| Karel
| ___
| 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: Two days old build breakage on i386.

[Simon Peyton Jones]

Thanks.  It’s blocking me from building GHC at all on my laptop, so temporary 
reversion would be great
Thank you!
Simon


From: ghc-devs [mailto:ghc-devs-boun...@haskell.org] On Behalf Of Johan Tibell
Sent: 26 June 2014 11:38
To: Karel Gardas
Cc: Simon Marlow; ghc-devs
Subject: Re: Two days old build breakage on i386.

I think it's reasonable to say my change triggers the issue, but I don't know 
why and I need someone who understand the register allocator better (e.g. Simon 
M) to at least give me some pointers on how to debug this. If this is causing 
more trouble than build bot breakages (which is bad enough), let me know and 
I'll either revert temporarily and or try to work around the issue.

Also, how do I repro this if I don't have a x86 machine lying around? Have 
people been successful working on these kind of issues in a VM?

On Thu, Jun 26, 2014 at 10:55 AM, Karel Gardas 
mailto:karel.gar...@centrum.cz>> wrote:

Hello,

builders running on i386 building for this platform caught issue which shows as 
a build breakage:

ghc-stage1: panic! (the 'impossible' happened)
(GHC version 7.9.20140624 for i386-unknown-linux):
RegAllocLinear.allocRegsAndSpill: no spill candidates
allocating vreg: VirtualRegI n1Q6
assignment: [(c1PV,InMem 2),(n1Q5,InBoth (RealRegSingle 3) 0),(n1Q6,InMem 
1),(n1Q7,InMem 3),(n1Q9,InReg (RealRegSingle 2))]
freeRegs: FreeRegs 4282318848
initFreeRegs: FreeRegs 4282318861
Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug
make[1]: *** [libraries/ghc-prim/dist-install/build/GHC/PrimopWrappers.o] Error 
1
libraries/ghc-prim/ghc.mk:4: recipe for target 
'libraries/ghc-prim/dist-install/build/GHC/PrimopWrappers.o' failed

Have a look for example on linux-i386 buildot log here: 
http://haskell.inf.elte.hu/builders/validator1-linux-x86-head/18/7.html

Anyway, this happens on Linux, FreeBSD and Solaris buildbots on i386 so it's OS 
independent and probably 32bit/i386 platform specific and it's two days old 
breakage now. The last two night builds fail on all mentioned buildbots. I'm 
not sure but perhaps:

commit d8abf85f8ca176854e9d5d0b12371c4bc402aac3
Author: Johan Tibell mailto:johan.tib...@gmail.com>>
Date:   Mon Jun 9 11:43:21 2014 +0200

triggers that issue? I'm not claiming that the commit is actual culprit, this 
may be just recently un-hidden issue in linear regs allocator on i386!

Thanks!
Karel

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

Re: HEADS-UP: Git submodule conversion imminent

[Herbert Valerio Riedel]

Hi Simon,

On 2014-06-26 at 14:13:08 +0200, Simon Peyton Jones wrote:
> Did you follow up with more specific instructions?
>
> In particular, 
> - how do I bring an existing clean tree up to date?

I tought I addressed that right at the start of

 http://www.haskell.org/pipermail/ghc-devs/2014-June/005311.html

?

> - if I have a tree with a bunch of as-yet-unpushed commits, what do I
> do?

If you have as-yet-unpushed commits in ghc.git, there shouldn't be
anything special to handle. Or were you referring to the case of having
unpushed commits in the converted sub-repos?


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

Re: Two days old build breakage on i386.

[Herbert Valerio Riedel]

On 2014-06-26 at 13:42:47 +0200, Karel Gardas wrote:
> On 06/26/14 12:37 PM, Johan Tibell wrote:
[...]

>> Also, how do I repro this if I don't have a x86 machine lying around?
>> Have people been successful working on these kind of issues in a VM?
>
> My simplest way is to install VirtualBox and inside it i386-ubuntu,
> give it 2 GB RAM, 15GB drive and this should get you going really
> quickly. Then you will need to:

Fwiw, on Ubuntu I'd rather recommend something more lightweight such as
schroot or using LXC, i.e.

  https://help.ubuntu.com/lts/serverguide/lxc.html#lxc-basic-usage

as using such a container seems to have less SMP-scheduling overhead and
memory overhead.

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

Re: Two days old build breakage on i386.

[Johan Tibell]

I'm going to push a revert to HEAD. I'm validating the commit now so it
should reach HEAD soonish.


On Thu, Jun 26, 2014 at 2:24 PM, Johan Tibell 
wrote:

> Just to make sure this is the same breakage, are you on an i386 Windows
> machine? If so git revert d8abf85f8ca176854e9d5d0b12371c4bc402aac3
> and 04dd7cb3423f1940242fdfe2ea2e3b8abd68a177 to get unstuck.
>
>
> On Thu, Jun 26, 2014 at 2:13 PM, Simon Peyton Jones  > wrote:
>
>> Aaaargh!  Once again the Windows build is broken.  I am utterly stalled.
>>
>> Moreover -fregs-graph and -fregs-iterative now *silently* do nothing.  At
>> least they should elicit warnings saying that they are disabled pending the
>> fix to X and Y.
>>
>> Please can someone bisect to find out which patch is the culprit?
>>
>> I wish we had a more systematic way to find this out. I hate being the
>> main person who gets stuck because some unrelated change has broken the
>> Windows build.  (Thanks for Karel, who got to it a day before me.)
>>
>> Thanks
>>
>> Simon
>>
>> | -Original Message-
>> | From: ghc-devs [mailto:ghc-devs-boun...@haskell.org] On Behalf Of Karel
>> | Gardas
>> | Sent: 26 June 2014 09:56
>> | To: ghc-devs; Johan Tibell
>> | Subject: Two days old build breakage on i386.
>> |
>> |
>> | Hello,
>> |
>> | builders running on i386 building for this platform caught issue which
>> | shows as a build breakage:
>> |
>> | ghc-stage1: panic! (the 'impossible' happened)
>> | (GHC version 7.9.20140624 for i386-unknown-linux):
>> | RegAllocLinear.allocRegsAndSpill: no spill candidates
>> | allocating vreg: VirtualRegI n1Q6
>> | assignment: [(c1PV,InMem 2),(n1Q5,InBoth (RealRegSingle 3)
>> | 0),(n1Q6,InMem 1),(n1Q7,InMem 3),(n1Q9,InReg (RealRegSingle 2))]
>> | freeRegs: FreeRegs 4282318848
>> | initFreeRegs: FreeRegs 4282318861
>> | Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug
>> | make[1]: ***
>> | [libraries/ghc-prim/dist-install/build/GHC/PrimopWrappers.o] Error 1
>> | libraries/ghc-prim/ghc.mk:4: recipe for target
>> | 'libraries/ghc-prim/dist-install/build/GHC/PrimopWrappers.o' failed
>> |
>> | Have a look for example on linux-i386 buildot log here:
>> | http://haskell.inf.elte.hu/builders/validator1-linux-x86-head/18/7.html
>> |
>> | Anyway, this happens on Linux, FreeBSD and Solaris buildbots on i386 so
>> | it's OS independent and probably 32bit/i386 platform specific and it's
>> | two days old breakage now. The last two night builds fail on all
>> | mentioned buildbots. I'm not sure but perhaps:
>> |
>> | commit d8abf85f8ca176854e9d5d0b12371c4bc402aac3
>> | Author: Johan Tibell 
>> | Date:   Mon Jun 9 11:43:21 2014 +0200
>> |
>> | triggers that issue? I'm not claiming that the commit is actual culprit,
>> | this may be just recently un-hidden issue in linear regs allocator on
>> | i386!
>> |
>> | Thanks!
>> | Karel
>> | ___
>> | 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: Two days old build breakage on i386.

[Johan Tibell]

On Thu, Jun 26, 2014 at 2:31 PM, Mateusz Kowalczyk 
wrote:

> On 06/26/2014 12:37 PM, Johan Tibell wrote:
> > I think it's reasonable to say my change triggers the issue, but I don't
> > know why and I need someone who understand the register allocator better
> > (e.g. Simon M) to at least give me some pointers on how to debug this. If
> > this is causing more trouble than build bot breakages (which is bad
> > enough), let me know and I'll either revert temporarily and or try to
> work
> > around the issue.
> >
> > Also, how do I repro this if I don't have a x86 machine lying around?
> Have
> > people been successful working on these kind of issues in a VM?
> >
>
> I can give you shell access to the machine in the OP but it's not the
> fastest thing in the world (3GHz Core 2 Duo). Let me know if you want it.


Thanks, but I'll try to see if I can install VirtualBox on my OS X machine
first.
___
ghc-devs mailing list
ghc-devs@haskell.org
http://www.haskell.org/mailman/listinfo/ghc-devs

Re: Two days old build breakage on i386.

[Mateusz Kowalczyk]

On 06/26/2014 12:37 PM, Johan Tibell wrote:
> I think it's reasonable to say my change triggers the issue, but I don't
> know why and I need someone who understand the register allocator better
> (e.g. Simon M) to at least give me some pointers on how to debug this. If
> this is causing more trouble than build bot breakages (which is bad
> enough), let me know and I'll either revert temporarily and or try to work
> around the issue.
> 
> Also, how do I repro this if I don't have a x86 machine lying around? Have
> people been successful working on these kind of issues in a VM?
> 

I can give you shell access to the machine in the OP but it's not the
fastest thing in the world (3GHz Core 2 Duo). Let me know if you want it.

> 
> On Thu, Jun 26, 2014 at 10:55 AM, Karel Gardas 
> wrote:
> 
>>
>> Hello,
>>
>> builders running on i386 building for this platform caught issue which
>> shows as a build breakage:
>>
>> ghc-stage1: panic! (the 'impossible' happened)
>> (GHC version 7.9.20140624 for i386-unknown-linux):
>> RegAllocLinear.allocRegsAndSpill: no spill candidates
>> allocating vreg: VirtualRegI n1Q6
>> assignment: [(c1PV,InMem 2),(n1Q5,InBoth (RealRegSingle 3) 0),(n1Q6,InMem
>> 1),(n1Q7,InMem 3),(n1Q9,InReg (RealRegSingle 2))]
>> freeRegs: FreeRegs 4282318848
>> initFreeRegs: FreeRegs 4282318861
>> Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug
>> make[1]: *** [libraries/ghc-prim/dist-install/build/GHC/PrimopWrappers.o]
>> Error 1
>> libraries/ghc-prim/ghc.mk:4: recipe for target 'libraries/ghc-prim/dist-
>> install/build/GHC/PrimopWrappers.o' failed
>>
>> Have a look for example on linux-i386 buildot log here:
>> http://haskell.inf.elte.hu/builders/validator1-linux-x86-head/18/7.html
>>
>> Anyway, this happens on Linux, FreeBSD and Solaris buildbots on i386 so
>> it's OS independent and probably 32bit/i386 platform specific and it's two
>> days old breakage now. The last two night builds fail on all mentioned
>> buildbots. I'm not sure but perhaps:
>>
>> commit d8abf85f8ca176854e9d5d0b12371c4bc402aac3
>> Author: Johan Tibell 
>> Date:   Mon Jun 9 11:43:21 2014 +0200
>>
>> triggers that issue? I'm not claiming that the commit is actual culprit,
>> this may be just recently un-hidden issue in linear regs allocator on i386!
>>
>> Thanks!
>> Karel
>>
> 
> 
> 
> ___
> ghc-devs mailing list
> ghc-devs@haskell.org
> http://www.haskell.org/mailman/listinfo/ghc-devs
> 


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

Re: Two days old build breakage on i386.

[Johan Tibell]

Just to make sure this is the same breakage, are you on an i386 Windows
machine? If so git revert d8abf85f8ca176854e9d5d0b12371c4bc402aac3
and 04dd7cb3423f1940242fdfe2ea2e3b8abd68a177 to get unstuck.


On Thu, Jun 26, 2014 at 2:13 PM, Simon Peyton Jones 
wrote:

> Aaaargh!  Once again the Windows build is broken.  I am utterly stalled.
>
> Moreover -fregs-graph and -fregs-iterative now *silently* do nothing.  At
> least they should elicit warnings saying that they are disabled pending the
> fix to X and Y.
>
> Please can someone bisect to find out which patch is the culprit?
>
> I wish we had a more systematic way to find this out. I hate being the
> main person who gets stuck because some unrelated change has broken the
> Windows build.  (Thanks for Karel, who got to it a day before me.)
>
> Thanks
>
> Simon
>
> | -Original Message-
> | From: ghc-devs [mailto:ghc-devs-boun...@haskell.org] On Behalf Of Karel
> | Gardas
> | Sent: 26 June 2014 09:56
> | To: ghc-devs; Johan Tibell
> | Subject: Two days old build breakage on i386.
> |
> |
> | Hello,
> |
> | builders running on i386 building for this platform caught issue which
> | shows as a build breakage:
> |
> | ghc-stage1: panic! (the 'impossible' happened)
> | (GHC version 7.9.20140624 for i386-unknown-linux):
> | RegAllocLinear.allocRegsAndSpill: no spill candidates
> | allocating vreg: VirtualRegI n1Q6
> | assignment: [(c1PV,InMem 2),(n1Q5,InBoth (RealRegSingle 3)
> | 0),(n1Q6,InMem 1),(n1Q7,InMem 3),(n1Q9,InReg (RealRegSingle 2))]
> | freeRegs: FreeRegs 4282318848
> | initFreeRegs: FreeRegs 4282318861
> | Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug
> | make[1]: ***
> | [libraries/ghc-prim/dist-install/build/GHC/PrimopWrappers.o] Error 1
> | libraries/ghc-prim/ghc.mk:4: recipe for target
> | 'libraries/ghc-prim/dist-install/build/GHC/PrimopWrappers.o' failed
> |
> | Have a look for example on linux-i386 buildot log here:
> | http://haskell.inf.elte.hu/builders/validator1-linux-x86-head/18/7.html
> |
> | Anyway, this happens on Linux, FreeBSD and Solaris buildbots on i386 so
> | it's OS independent and probably 32bit/i386 platform specific and it's
> | two days old breakage now. The last two night builds fail on all
> | mentioned buildbots. I'm not sure but perhaps:
> |
> | commit d8abf85f8ca176854e9d5d0b12371c4bc402aac3
> | Author: Johan Tibell 
> | Date:   Mon Jun 9 11:43:21 2014 +0200
> |
> | triggers that issue? I'm not claiming that the commit is actual culprit,
> | this may be just recently un-hidden issue in linear regs allocator on
> | i386!
> |
> | Thanks!
> | Karel
> | ___
> | 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: Two days old build breakage on i386.

[Simon Peyton Jones]

Aaaargh!  Once again the Windows build is broken.  I am utterly stalled.

Moreover -fregs-graph and -fregs-iterative now *silently* do nothing.  At least 
they should elicit warnings saying that they are disabled pending the fix to X 
and Y.

Please can someone bisect to find out which patch is the culprit?  

I wish we had a more systematic way to find this out. I hate being the main 
person who gets stuck because some unrelated change has broken the Windows 
build.  (Thanks for Karel, who got to it a day before me.)

Thanks

Simon

| -Original Message-
| From: ghc-devs [mailto:ghc-devs-boun...@haskell.org] On Behalf Of Karel
| Gardas
| Sent: 26 June 2014 09:56
| To: ghc-devs; Johan Tibell
| Subject: Two days old build breakage on i386.
| 
| 
| Hello,
| 
| builders running on i386 building for this platform caught issue which
| shows as a build breakage:
| 
| ghc-stage1: panic! (the 'impossible' happened)
| (GHC version 7.9.20140624 for i386-unknown-linux):
| RegAllocLinear.allocRegsAndSpill: no spill candidates
| allocating vreg: VirtualRegI n1Q6
| assignment: [(c1PV,InMem 2),(n1Q5,InBoth (RealRegSingle 3)
| 0),(n1Q6,InMem 1),(n1Q7,InMem 3),(n1Q9,InReg (RealRegSingle 2))]
| freeRegs: FreeRegs 4282318848
| initFreeRegs: FreeRegs 4282318861
| Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug
| make[1]: ***
| [libraries/ghc-prim/dist-install/build/GHC/PrimopWrappers.o] Error 1
| libraries/ghc-prim/ghc.mk:4: recipe for target
| 'libraries/ghc-prim/dist-install/build/GHC/PrimopWrappers.o' failed
| 
| Have a look for example on linux-i386 buildot log here:
| http://haskell.inf.elte.hu/builders/validator1-linux-x86-head/18/7.html
| 
| Anyway, this happens on Linux, FreeBSD and Solaris buildbots on i386 so
| it's OS independent and probably 32bit/i386 platform specific and it's
| two days old breakage now. The last two night builds fail on all
| mentioned buildbots. I'm not sure but perhaps:
| 
| commit d8abf85f8ca176854e9d5d0b12371c4bc402aac3
| Author: Johan Tibell 
| Date:   Mon Jun 9 11:43:21 2014 +0200
| 
| triggers that issue? I'm not claiming that the commit is actual culprit,
| this may be just recently un-hidden issue in linear regs allocator on
| i386!
| 
| Thanks!
| Karel
| ___
| 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: Pruning GADT case alternatives with uninhabitable coercion parameters

[Simon Peyton Jones]

I’m on a train, so can’t look at your code.  But I urge you (or whoever) to 
split the task into two:

·Traverse the Core tree, gathering given constraints, deleting 
unreachable branches

·The Contradiction Checker (CCK)

CCK is independently useful; for example George et al may use it when 
traversing HsSyn to report overlapping patterns.

The API of CCK might look something like this:

   contradictionCheck :: FamInstEnvs -> [PredType] -> [PredType] -> 
Bool


·FamInstEnvs tells it what type-family-instances exist

·The first [PredType] are the enclosing givens

·The second [PredType] are the givens of a new pattern match

·Result is True if the new pattern match is inaccessible

One might also consider a more incremental API, something like
   data ContradictionChecker
   newCCK :: FamInstEnvs -> ContradictionChecker
   check :: ContradictionChecker -> [PredType] -> Maybe 
ContradictionChecker

Returns Nothing for a contradiction, (Just cc) if the branch is reachable, 
where you should use cc for the body of the branch.

I like the latter API.  For example a ContrdictionChecker might carry a 
renaming of type variables, to account for shadowing.

Simon

From: conal.elli...@gmail.com [mailto:conal.elli...@gmail.com] On Behalf Of 
Conal Elliott
Sent: 25 June 2014 00:11
To: Simon Peyton Jones
Cc: Dimitrios Vytiniotis; ghc-devs@haskell.org; Nikolaos S. Papaspyrou 
(nic...@softlab.ntua.gr); George Karachalias
Subject: Re: Pruning GADT case alternatives with uninhabitable coercion 
parameters

I'm glad for the interest and help. I can make an initial go of it. My current 
simple plan is to traverse expressions, collecting type equalities from bound 
coercion variables as I descend, combining them progressively with successive 
type unifications. The traversal is thus parametrized by a TvSubst and yields a 
Maybe TvSubst. The coercion variables will come from lambdas, let bindings and 
case alternatives. If an added equality is not unifiable given the current 
TvSubst, we've reached a contradiction. If the contradiction arises for one of 
the variables in a case alternative, then remove that alternative.

How does this strategy sound?

Some issues:

*   Nominal vs representational type equalities.
*   Will I want to normalize the types (with normaliseType) before unifying?
*   How can I unify while carrying along a type substitution environment? The 
Unify module exports tcUnifyTy, which takes no such environment, but not unify, 
which does.
-- Conal

On Tue, Jun 24, 2014 at 4:43 AM, Simon Peyton Jones 
mailto:simo...@microsoft.com>> wrote:
we need to do a bit more work to re-connect to source pattern locations and 
nested patterns? I can’t assess very well yet if this is a real problem though

That is a very good point.

Nevertheless, given

• the typechecked HsSyn (i.e. still in source form, but with type 
inference fully completed

• the independent contradiction-detector described below (which is 
independent of whether the contradiction problems it is given come from HsSyn 
or Core)
it would be easy to give source-localised error messages

Simon

From: Dimitrios Vytiniotis
Sent: 24 June 2014 11:58
To: Simon Peyton Jones; Conal Elliott; 
ghc-devs@haskell.org
Cc: Nikolaos S. Papaspyrou 
(nic...@softlab.ntua.gr); George Karachalias

Subject: RE: Pruning GADT case alternatives with uninhabitable coercion 
parameters


Yes it would be better in the sense that we don’t really want to be dealing 
with unification variables and evidence when we simply use the constraint 
solver to detect inconsistencies in possibly missing patterns, but the concern 
has been that if we are already desugared and in core maybe we need to do a bit 
more work to re-connect to source pattern locations and nested patterns? I 
can’t assess very well yet if this is a real problem though …

In general I agree that a simple constraint solver for Core might be an 
independently useful tool for this kind of optimization. (I think George had 
thought about this too).

Thanks!
d-



From: Simon Peyton Jones
Sent: Tuesday, June 24, 2014 11:41 AM
To: Conal Elliott; ghc-devs@haskell.org
Cc: Dimitrios Vytiniotis; Nikolaos S. Papaspyrou 
(nic...@softlab.ntua.gr); George Karachalias; 
Simon Peyton Jones
Subject: RE: Pruning GADT case alternatives with uninhabitable coercion 
parameters

Conal

This also relates to detecting redundant or overlapped patterns in source 
programs. I know that Dimitrios is looking at this with Tom, Nikolas, George 
who I’m cc’ing him.

I think their current approach may be to integrate the overlap checking with 
the constraint solver in the type checker.  But that isn’t going to work for 
optimising Core.

An alternative approach would be to implement a specialised constraint solver.  
It cou

RE: HEADS-UP: Git submodule conversion imminent

[Simon Peyton Jones]

Thank you Herbert!

Did you follow up with more specific instructions?

In particular, 
- how do I bring an existing clean tree up to date?
- if I have a tree with a bunch of as-yet-unpushed commits, what do I do?

Thanks

Simon

| -Original Message-
| From: ghc-devs [mailto:ghc-devs-boun...@haskell.org] On Behalf Of Herbert
| Valerio Riedel
| Sent: 25 June 2014 08:47
| To: ghc-devs
| Subject: HEADS-UP: Git submodule conversion imminent
| 
| Hello GHC Devs!
| 
| In order to not drag this out any longer, I'll completing the submodule
| conversion in the next few hours by converting the remaining sub-repo
| packages into proper submodules.
| 
| This is represents phase 1 of the reorganization (phase 2 comprises
| officially transitioning the push-urls of *some* the packages to
| github.com/haskell as happened with haddock). However, this phase 1 is
| important to get done early (ideally half a year ago) in order to make
| 'ghc-complete' bit more redundant (I hope Joachim doesn't mind... :-) )
| and allow to properly 'git bisect' as far back as possible into the
| past.
| 
| While the workflow changes[1] to additionally have the sub-repo change
| also
| registed in ghc.git, practically, this should affect only a minority of
| you, as the remaining packages (see list at the bottom of this mail) to
| be
| converted into submodules are modified *very* seldom.
| 
| This will be similiar to the conversion of haddock.git into a proper
| submodule of which you read up in
| 
|  * 
|  * 
|  * 
| 
| List of packages converted into proper submodules:
| 
|  * libffi-tarballs libffi-tarballs.git
|  * utils/hsc2hshsc2hs.git
|  * libraries/array packages/array.git
|  * libraries/deepseq   packages/deepseq.git
|  * libraries/directory packages/directory.git
|  * libraries/filepath  packages/filepath.git
|  * libraries/haskell98 packages/haskell98.git
|  * libraries/haskell2010   packages/haskell2010.git
|  * libraries/hoopl packages/hoopl.git
|  * libraries/hpc   packages/hpc.git
|  * libraries/old-localepackages/old-locale.git
|  * libraries/old-time  packages/old-time.git
|  * libraries/process   packages/process.git
|  * libraries/unix  packages/unix.git
|  * nofib   nofib.git
|  * libraries/parallel  packages/parallel.git
|  * libraries/stm   packages/stm.git
|  * libraries/dph   packages/dph.git
| 
| 
| Ideally, you won't have any outstanding changes in those repos (hint,
| hint!) to make the transition for your GHC clones easier. I'll follow up
| with more specific instructions as soon as I've pushed the changes.
| 
| 
| N.B.: ghc-tarballs will *not* become a submodule, as it would impose a
|   non-neglible cost on everyone, not only the developers on windows
|   and, moreover, the plan is to turn ghc-tarballs into a scripted
|   download (or maybe something git-annex based) as Git is not really
|   suited for such large blobs.
| 
|   See also discussion at
|   
| 
| 
|  [1]: For the new workflow in case you really happen to have to touch
|   one of the affected modules, see the work-in-progress Wiki entry at
| 
| https://ghc.haskell.org/trac/ghc/wiki/WorkingConventions/Git/Submodules#M
| akingchangestoGHCsubmodules
| ___
| 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: Two days old build breakage on i386.

[Karel Gardas]

On 06/26/14 12:37 PM, Johan Tibell wrote:

I think it's reasonable to say my change triggers the issue, but I don't
know why and I need someone who understand the register allocator better
(e.g. Simon M) to at least give me some pointers on how to debug this.
If this is causing more trouble than build bot breakages (which is bad
enough), let me know and I'll either revert temporarily and or try to
work around the issue.


it does not hurt me as long as it does not go to 7.10 release so it's 
enough time to fix that. So feel free not to revert your patch 
especially if you do have some time to look into real culprit in regs alloc.



Also, how do I repro this if I don't have a x86 machine lying around?
Have people been successful working on these kind of issues in a VM?


My simplest way is to install VirtualBox and inside it i386-ubuntu, give 
it 2 GB RAM, 15GB drive and this should get you going really quickly. 
Then you will need to:


sudo apt-get install gcc ghc make git (in ubuntu)

which should be enough and then just follow ghc's wiki to obtain source 
tree and bootstrap on linux...


Roughly it should be that IMHO. If not, I may do that myself and send 
you exact stepts to follow...


Thanks!
Karel




On Thu, Jun 26, 2014 at 10:55 AM, Karel Gardas mailto:karel.gar...@centrum.cz>> wrote:


Hello,

builders running on i386 building for this platform caught issue
which shows as a build breakage:

ghc-stage1: panic! (the 'impossible' happened)
(GHC version 7.9.20140624 for i386-unknown-linux):
RegAllocLinear.__allocRegsAndSpill: no spill candidates
allocating vreg: VirtualRegI n1Q6
assignment: [(c1PV,InMem 2),(n1Q5,InBoth (RealRegSingle 3)
0),(n1Q6,InMem 1),(n1Q7,InMem 3),(n1Q9,InReg (RealRegSingle 2))]
freeRegs: FreeRegs 4282318848
initFreeRegs: FreeRegs 4282318861
Please report this as a GHC bug:
http://www.haskell.org/ghc/__reportabug

make[1]: ***
[libraries/ghc-prim/dist-__install/build/GHC/__PrimopWrappers.o] Error 1
libraries/ghc-prim/ghc.mk:4 : recipe for target
'libraries/ghc-prim/dist-__install/build/GHC/__PrimopWrappers.o' failed

Have a look for example on linux-i386 buildot log here:
http://haskell.inf.elte.hu/__builders/validator1-linux-x86-__head/18/7.html


Anyway, this happens on Linux, FreeBSD and Solaris buildbots on i386
so it's OS independent and probably 32bit/i386 platform specific and
it's two days old breakage now. The last two night builds fail on
all mentioned buildbots. I'm not sure but perhaps:

commit d8abf85f8ca176854e9d5d0b12371c__4bc402aac3
Author: Johan Tibell mailto:johan.tib...@gmail.com>>
Date:   Mon Jun 9 11:43:21 2014 +0200

triggers that issue? I'm not claiming that the commit is actual
culprit, this may be just recently un-hidden issue in linear regs
allocator on i386!

Thanks!
Karel




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

Re: Two days old build breakage on i386.

[Páli Gábor János]

2014-06-26 12:37 GMT+02:00 Johan Tibell :
> Also, how do I repro this if I don't have a x86 machine lying around? Have
> people been successful working on these kind of issues in a VM?

For what it is worth, the FreeBSD/i386 builder actually runs in jail
with a 32-bit userland on a 64-bit host, and it apparently can
reproduce the problem.
___
ghc-devs mailing list
ghc-devs@haskell.org
http://www.haskell.org/mailman/listinfo/ghc-devs

Re: Two days old build breakage on i386.

[Johan Tibell]

I think it's reasonable to say my change triggers the issue, but I don't
know why and I need someone who understand the register allocator better
(e.g. Simon M) to at least give me some pointers on how to debug this. If
this is causing more trouble than build bot breakages (which is bad
enough), let me know and I'll either revert temporarily and or try to work
around the issue.

Also, how do I repro this if I don't have a x86 machine lying around? Have
people been successful working on these kind of issues in a VM?


On Thu, Jun 26, 2014 at 10:55 AM, Karel Gardas 
wrote:

>
> Hello,
>
> builders running on i386 building for this platform caught issue which
> shows as a build breakage:
>
> ghc-stage1: panic! (the 'impossible' happened)
> (GHC version 7.9.20140624 for i386-unknown-linux):
> RegAllocLinear.allocRegsAndSpill: no spill candidates
> allocating vreg: VirtualRegI n1Q6
> assignment: [(c1PV,InMem 2),(n1Q5,InBoth (RealRegSingle 3) 0),(n1Q6,InMem
> 1),(n1Q7,InMem 3),(n1Q9,InReg (RealRegSingle 2))]
> freeRegs: FreeRegs 4282318848
> initFreeRegs: FreeRegs 4282318861
> Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug
> make[1]: *** [libraries/ghc-prim/dist-install/build/GHC/PrimopWrappers.o]
> Error 1
> libraries/ghc-prim/ghc.mk:4: recipe for target 'libraries/ghc-prim/dist-
> install/build/GHC/PrimopWrappers.o' failed
>
> Have a look for example on linux-i386 buildot log here:
> http://haskell.inf.elte.hu/builders/validator1-linux-x86-head/18/7.html
>
> Anyway, this happens on Linux, FreeBSD and Solaris buildbots on i386 so
> it's OS independent and probably 32bit/i386 platform specific and it's two
> days old breakage now. The last two night builds fail on all mentioned
> buildbots. I'm not sure but perhaps:
>
> commit d8abf85f8ca176854e9d5d0b12371c4bc402aac3
> Author: Johan Tibell 
> Date:   Mon Jun 9 11:43:21 2014 +0200
>
> triggers that issue? I'm not claiming that the commit is actual culprit,
> this may be just recently un-hidden issue in linear regs allocator on i386!
>
> Thanks!
> Karel
>
___
ghc-devs mailing list
ghc-devs@haskell.org
http://www.haskell.org/mailman/listinfo/ghc-devs

Two days old build breakage on i386.

[Karel Gardas]

Hello,

builders running on i386 building for this platform caught issue which 
shows as a build breakage:


ghc-stage1: panic! (the 'impossible' happened)
(GHC version 7.9.20140624 for i386-unknown-linux):
RegAllocLinear.allocRegsAndSpill: no spill candidates
allocating vreg: VirtualRegI n1Q6
assignment: [(c1PV,InMem 2),(n1Q5,InBoth (RealRegSingle 3) 
0),(n1Q6,InMem 1),(n1Q7,InMem 3),(n1Q9,InReg (RealRegSingle 2))]

freeRegs: FreeRegs 4282318848
initFreeRegs: FreeRegs 4282318861
Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug
make[1]: *** 
[libraries/ghc-prim/dist-install/build/GHC/PrimopWrappers.o] Error 1
libraries/ghc-prim/ghc.mk:4: recipe for target 
'libraries/ghc-prim/dist-install/build/GHC/PrimopWrappers.o' failed


Have a look for example on linux-i386 buildot log here: 
http://haskell.inf.elte.hu/builders/validator1-linux-x86-head/18/7.html


Anyway, this happens on Linux, FreeBSD and Solaris buildbots on i386 so 
it's OS independent and probably 32bit/i386 platform specific and it's 
two days old breakage now. The last two night builds fail on all 
mentioned buildbots. I'm not sure but perhaps:


commit d8abf85f8ca176854e9d5d0b12371c4bc402aac3
Author: Johan Tibell 
Date:   Mon Jun 9 11:43:21 2014 +0200

triggers that issue? I'm not claiming that the commit is actual culprit, 
this may be just recently un-hidden issue in linear regs allocator on i386!


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

2nd call for contributions: Haskell Implementors' Workshop 2014

[Jost Berthold]

Dear fellow Haskellers,

We are 20 days away from the deadline for HIW 2014.

If you have an exciting topic you would like to present, please propose 
a talk by submitting an abstract (through easychair, see below).


Best regards
Jost Berthold



Call for Contributions
   ACM SIGPLAN Haskell Implementors' Workshop

http://haskell.org/haskellwiki/HaskellImplementorsWorkshop/2014
Gothenburg, Sweden, 06 September, 2014

Co-located with ICFP 2014
   http://www.icfpconference.org/icfp2014/

Important dates
---
Proposal Deadline:  Monday, 14 July, 2014 (anywhere on earth)
Notification:   21 July  2014
Workshop:   Saturday, 6 September 2014

The 6th Haskell Implementors' Workshop is to be held alongside ICFP
2014 this year in Gothenburg. It is a forum for people involved in the
design and development of Haskell implementations, tools, libraries,
and supporting infrastructure, to share their work and discuss future
directions and collaborations with others.

Talks and/or demos are proposed by submitting an abstract, and
selected by a small program committee. There will be no published
proceedings; the workshop will be informal and interactive, with a
flexible timetable and plenty of room for ad-hoc discussion, demos,
and impromptu short talks.

Attendance figures clearly reflect the growth of the Haskell user
community and a constant interest in implementation aspects.

Scope and target audience
-

It is important to distinguish the Haskell Implementors' Workshop from
the Haskell Symposium which is also co-located with ICFP 2014. The
Haskell Symposium is for the publication of Haskell-related research. In
contrast, the Haskell Implementors' Workshop will have no proceedings --
although we will aim to make talk videos, slides and presented data
available with the consent of the speakers.

In the Haskell Implementors' Workshop, we hope to study the underlying
technology. We want to bring together anyone interested in the
nitty-gritty details behind turning plain-text source code into a
deployed product. Having said that, members of the wider Haskell
community are more than welcome to attend the workshop -- we need your
feedback to keep the Haskell ecosystem thriving.

The scope covers any of the following topics. There may be some topics
that people feel we've missed, so by all means submit a proposal even if
it doesn't fit exactly into one of these buckets:

  * Compilation techniques
  * Language features and extensions
  * Type system implementation
  * Concurrency and parallelism: language design and implementation
  * Performance, optimisation and benchmarking
  * Virtual machines and run-time systems
  * Libraries and tools for development or deployment

Talks
-

At this stage we would like to invite proposals from potential speakers
for talks and demonstrations. We are aiming for 20 minute talks with 10
minutes for questions and changeovers. We want to hear from people
writing compilers, tools, or libraries, people with cool ideas for
directions in which we should take the platform, proposals for new
features to be implemented, and half-baked crazy ideas. Please submit a
talk title and abstract of no more than 300 words.

Submissions should be made via EasyChair. The website is:
  https://www.easychair.org/conferences/?conf=hiw2014

If you don't have an account you can create one here:
  https://www.easychair.org/account/signup.cgi

Because the submission is an abstract only, please click the "abstract
only" button when you make your submission.  There is no need to
attach a separate file.

We will also have a lightning talks session which will be organised on
the day. These talks will be 5-10 minutes, depending on available time.
Suggested topics for lightning talks are to present a single idea, a
work-in-progress project, a problem to intrigue and perplex Haskell
implementors, or simply to ask for feedback and collaborators.

Organisers
--

  * Jost Berthold (co-chair) (University of Copenhagen)
  * Kevin Hammond(University of St.Andrews)
  * Gabriele Keller  (University of New South Wales)
  * Paul Liu (Intel Labs)
  * Rita Loogen  (Philipps-Universitat Marburg)
  * Geoffrey Mainland (co-chair) (Drexel University, Philadelphia)
  * Carter Schonwald (WellPosed Ltd)

Contact
---

  * hiw2...@easychair.org
  * Jost Berthold 
  * Geoffrey Mainland 
___
ghc-devs mailing list
ghc-devs@haskell.org
http://www.haskell.org/mailman/listinfo/ghc-devs

Re: HEADS-UP: Git submodule conversion imminent

[山本和彦]

Johan,

> Should be fixed in 04dd7cb3423f1940242fdfe2ea2e3b8abd68a177.

Thanks.

"validate" is finished with new settings on Mac. :-)

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