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
| 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]
|
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
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
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
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,
| 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
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
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
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
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 ge...@erdi.hu 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
Maybe this (https://ghc.haskell.org/trac/ghc/ticket/7908) is fixed too?
Cheers,
Gabor
On 12/1/14, g...@git.haskell.org g...@git.haskell.org wrote:
Repository : ssh://g...@git.haskell.org/ghc
On branch : master
Link :
Yes, ideally this would have been caught by a Windows build bot.
On Mon, Dec 1, 2014 at 4:34 PM, Simon Peyton Jones simo...@microsoft.com
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
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
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:
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
|
|
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
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 simo...@microsoft.com wrote:
The issue is not so
So it could be regarded as a bugfix?
Em terça-feira, 2 de dezembro de 2014, Dr. ÉRDI Gergő ge...@erdi.hu
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
With enough intellectual dishonesty, sure...
On Dec 2, 2014 7:29 AM, Gabor Greif ggr...@gmail.com wrote:
So it could be regarded as a bugfix?
Em terça-feira, 2 de dezembro de 2014, Dr. ÉRDI Gergő ge...@erdi.hu
escreveu:
It is clear to everyone that all it would change is the *output* of
20 matches
Mail list logo
