I'm still puzzled as to how validate failed on snow leopard, but is working
correctly on my mountain lion machine after fixing the warning in the primitive
package.
Ben: does validate go through on your machine after patching the primitive
package?
Here are my results for 'validate --slow':
I like it better now, thank you.
But look at https://ghc.haskell.org/trac/ghc/ticket/4175
Notice the lovely formatting of comment 10, 11.
* The typewriter font is set off as it usually is with {{{...}}}
* The list of files changed is included (a la git log --stat)
Neither shows up in comment
Hi,
I don’t trust the travis setup enough to automatically relay failures,
so I do it manually. Since these patches:
Changes to ghc:
commit 12cdd6d
Author: Duncan Coutts dun...@well-typed.com
Date: Thu Nov 14 16:02:03 2013 +
Don translate UserInterrupt into ExitFailure 1, let it
On Fri, 2013-11-15 at 11:21 +0100, Joachim Breitner wrote:
Hi,
I don’t trust the travis setup enough to automatically relay failures,
so I do it manually. Since these patches:
Changes to ghc:
Changes to base:
commit dd4
Author: Duncan Coutts dun...@well-typed.com
Date: Thu Nov 14
Hi devs,
I happened to be looking through the code dealing with known names, and I'm a
little confused about templateHaskellNames. In particular, I'm confused why
it's included in knownKeyNames only when GHCI is defined. (See lines 196-198 of
HscMain.) It's the stage 1 compiler that compiles
Hello Ryan and Nicolas,
I'm happy to see some interest in the tf-random package.
The package has not been extensively tested. I ran it on x86-64 and x86
Linux, and on x86 Windows. It would be good to check if it gives the
same results on a big-endian architecture, such as ARM, however I don't
Hi,
thanks to Duncan for fixing topHandler03. Three new tests are however
failing:
= T2494(normal) 805 of 3821 [0, 0, 0]
Actual stderr output differs from expected:
--- ./typecheck/should_compile/T2494.stderr 2013-11-15 19:07:53.298771915
+
+++
Hi possibly-interested souls,
In this patch to System.Process.readProcess from last year:
https://ghc.haskell.org/trac/ghc/changeset/b5ee908863882d18e4110d96b43ccc1bb5068ceb/process
Bas changed things so that if an async exception is received by the
thread calling readProcess (or
Windows build is failing again in a new way. It was fine a couple of days ago.
Does this ring any bells?
ghc-stage1.exe: panic! (the 'impossible' happened)
(GHC version 7.7.20131107 for i386-unknown-mingw32):
bundle
Simon
inplace/bin/ghc-stage1.exe -static -H32m -O -Werror -Wall
Not necessarily to do with Duncan's stuff. Might conceivably be me, but I
can't validate at the moment because of the bundle failure I reported. Alas.
Simon
| -Original Message-
| From: ghc-devs [mailto:ghc-devs-boun...@haskell.org] On Behalf Of
| Joachim Breitner
| Sent: 15 November
I've looked into this myself. I don't think it's actually anything wrong in
gmp-wrappers. It's because CmmBuildInfoTables expects all the info tables in
the (CmmProc info_tbls lbl g) to be defined in the graph g.
But Jan's new optimisation to the stack overflow check (Note [Always false
Hi Nicolas,
I apologize if you didn't get the notice I sent last week on the update.
Right now I am endlessly battling windows, and while I actually DO
have a dynamic GHC working for windows with the DLL split (#5987,) it
is segfaulting in the stage2 compiler when compiling the 'time'
library,
What are ways for other folks to help? (If possible)
On Friday, November 15, 2013, Austin Seipp wrote:
Hi Nicolas,
I apologize if you didn't get the notice I sent last week on the update.
Right now I am endlessly battling windows, and while I actually DO
have a dynamic GHC working for
13 matches
Mail list logo
