Hello there,
I have just found the builds are failing due to this (see [1] for the full log):
"/usr/home/ghc-builder/work/builder/tempbuild/build/inplace/bin/haddock"
--odir="compiler/stage2/doc/html/ghc" --no-tmp-comp-dir
--dump-interface=compiler/stage2/doc/html/ghc/ghc.haddock --html
--hoogle
I've used Phabricator for the first time yesterday and have also experienced
most of the problems
mentioned by Richard. The most painful ones were:
1. Complaining about any untracked or uncommited changes in the source tree.
This is mostly
annoying. How can I tell arcanist to ignore such chang
On 07/17/2014 09:05 AM, Páli Gábor János wrote:
> Hello there,
>
> I have just found the builds are failing due to this (see [1] for the full
> log):
>
> "/usr/home/ghc-builder/work/builder/tempbuild/build/inplace/bin/haddock"
> --odir="compiler/stage2/doc/html/ghc" --no-tmp-comp-dir
> --dump-in
On 2014-07-17 at 08:54:32 +0200, Simon Peyton Jones wrote:
[...]
> - it's at the bottom of a long page, most of which is irrelevant if you use
> ./sync-all (I think??)
Fwiw, the page was written to be a `./sync-all`-agnostic on purpose (in
fact, ./sync-all isn't mentioned only once for pre-subm
| > parse error on input ‘-- *kind* and role of its argument.
| Luckily,
| > laziness should’
| >
| > [1] http://haskell.inf.elte.hu/builders/freebsd-amd64-
| head/322/10.html
| > ___
| > ghc-devs mailing list
| > ghc-devs@haskell.org
| > http://www.
Johan Tibell :
>
> On Thu, Jul 17, 2014 at 8:40 AM, Simon Peyton Jones
> wrote:
>> | I used to be a 80 column guy, but moved away from that the last years.
>> | But you are right, there must be an upper limit and, if >80 is a
>> | problem for code reviews, then it's a reasonable choice.
>>
>> As
| Maybe we need different two different presentations. One concise
| reference-like wiki page for Git-gnostic devs, and one for `./sync-
| all`-accustomed devs (or maybe even a rosetta-stone like translation
| between 'sync-all' invocations, and what the respective Git-only
| commands look like)
M
On Thu, Jul 17, 2014 at 08:21:43AM +, Simon Peyton Jones wrote:
>
> | > parse error on input ‘-- *kind* and role of its argument.
> | Luckily,
> | > laziness should’
> | >
> | > [1] http://haskell.inf.elte.hu/builders/freebsd-amd64-
> | head/322/10.html
> | > __
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
On 17/07/14 08:57, Johan Tibell wrote:
> * Wider screens let you have several Emacs buffers next to each
> other. At 80 chars you can have about 2 buffers next to each other
> on a 13" screen.
This is my main grief with 100 char lines (which is the
This is totally brilliant: thank you Joachim!
Simon
| -Original Message-
| From: ghc-devs [mailto:ghc-devs-boun...@haskell.org] On Behalf Of
| Joachim Breitner
| Sent: 16 July 2014 09:02
| To: ghc-devs@haskell.org
| Subject: Beta Performance dashboard
|
| Hi,
|
| I guess it’s time to ta
Oops. I was relying on Travis's validation, which skips haddocking.
This is most likely why Phab's build failed.
Thanks for fixing it!
Richard
On Jul 17, 2014, at 4:44 AM, Simon Hengel wrote:
> On Thu, Jul 17, 2014 at 08:21:43AM +, Simon Peyton Jones wrote:
>>
>> | > parse error on in
gcc has -march=native which uses the current CPU's architecture, but I
think it would be a really bad idea to turn that on by default, because
it would mean that we have to be really careful which machine we build
the distributions on.
On my Linux box, gcc -v says it was configured with --with
Hi,
On Saturday 6th September is the Haskell Implementers Workshop. There
has been plenty of discussion over the last 12 months about making
contributions to GHC less formidable. Is this story going to be told
at HIW? A talk about revised contribution guidelines and helpful tool
support might enga
wearing my "i'm on the HIW PC" hat, i'm going to speculatively say, "Yes!",
though i'm ccing Jost into this dialogue :)
On Thu, Jul 17, 2014 at 2:18 PM, Rob Stewart wrote:
> Hi,
>
> On Saturday 6th September is the Haskell Implementers Workshop. There
> has been plenty of discussion over the
| On my Linux box, gcc -v says it was configured with --with-arch-32=i686,
which means that -march=i686 is the default for 32-bit code. We shouldn't
go any later than that IMO.
|
| Anyway, this is all beside the point, if we aren't able to run the code
generated by gcc (in whatever mode) then ther
Can someone see if adding
Cc-options: -march=i686
To ghc-prim.cabal resolves the issue?
On Jul 17, 2014 9:06 PM, "Simon Marlow" wrote:
> gcc has -march=native which uses the current CPU's architecture, but I
> think it would be a really bad idea to turn that on by default, because it
> would
Now I have an extremely simple patch that I have confirmed is working.
As it is in the autoconfig stuff, one needs to run:
autoreconf
make distclean
./boot
and so on
As apparently everything has been built with i386 before, I'm curious about
if there's a performance increase when going i686.
2014-07-17 22:05 GMT+02:00 Niklas Larsson :
> The bug is that the mingw32 build is generating
> code for i386, which lacks these assembler primitives.
I think this might be a feature instead. As I wrote earlier, on
FreeBSD/i386, arch is set to i486 in GCC's configure script [1].
Hence, whatever v
2014-07-17 22:05 GMT+02:00 Johan Tibell :
> Can someone see if adding
>
> Cc-options: -march=i686
>
> To ghc-prim.cabal resolves the issue?
Yes, I can confirm that it works. However, it shall be prefixed with
a conditional such as (os(windows) && arch(i386)) as x86_64 does not
support -march=i6
Yes, ultimately the problem is that the mingw-gcc that is in the tarball
git has a too low target. But that is a rather larger fix than setting the
arch targetted in configure.
2014-07-17 22:50 GMT+02:00 Páli Gábor János :
> 2014-07-17 22:05 GMT+02:00 Niklas Larsson :
> > The bug is that the min
20 matches
Mail list logo
