I have added a section Ticky-ticky quick start to our ticky-ticky profiling
page, to explain how I go about dealing with the problem you describe
https://ghc.haskell.org/trac/ghc/wiki/Debugging/TickyTicky
Simon
| -Original Message-
| From: David Feuer [mailto:david.fe...@gmail.com]
|
Hi,
I tried setting 'stage=2' in my mk/build.mk file, but the stage 1 compiler
is still getting rebuilt (and of course this causes the stage 2 compiler
to be rebuilt from scratch...). I am using BuildFlavour=devel2. What am I
missing?
Thanks,
Gergo
I don't see any relevant change in the last week. I'll give it a
try and see if I can reproduce.
Edward
Excerpts from Dr. ERDI Gergo's message of 2014-08-29 12:44:07 +0100:
Hi,
I tried setting 'stage=2' in my mk/build.mk file, but the stage 1 compiler
is still getting rebuilt (and of
On Fri, 29 Aug 2014, Edward Z. Yang wrote:
I don't see any relevant change in the last week. I'll give it a
try and see if I can reproduce.
I don't think it's been working properly for me for months now.
___
ghc-devs mailing list
OK, it's definitely worked for me in that time. Do you have
mk/are-validating.mk in your tree? Also do try on a fresh working copy.
Edward
Excerpts from Dr. ERDI Gergo's message of 2014-08-29 13:01:44 +0100:
On Fri, 29 Aug 2014, Edward Z. Yang wrote:
I don't see any relevant change in the
On Fri, 29 Aug 2014, Edward Z. Yang wrote:
OK, it's definitely worked for me in that time. Do you have
mk/are-validating.mk in your tree? Also do try on a fresh working copy.
Yes I do! Is that the remnant of some failed validation process? Should I
remove it?
I think make maintainer-clean removes it. I find this hidden pieces of
state annoying. It has definitely tripped me up in the past. Perhaps we can
have make clean remove it?
On Fri, Aug 29, 2014 at 2:14 PM, Dr. ERDI Gergo ge...@erdi.hu wrote:
On Fri, 29 Aug 2014, Edward Z. Yang wrote:
OK,
are-validating.mk flips GHC tree into validating mode, which makes
it ignore mk/build.mk. Remember to delete it when you are done
validating.
Edward
Excerpts from Dr. ERDI Gergo's message of 2014-08-29 13:14:04 +0100:
On Fri, 29 Aug 2014, Edward Z. Yang wrote:
OK, it's definitely worked for
On Fri, 29 Aug 2014, Johan Tibell wrote:
I think make maintainer-clean removes it. I find this hidden pieces of state
annoying.
It has definitely tripped me up in the past. Perhaps we can have make clean
remove it?
I've removed it manually and now 'stage=2' works as it used to. Thanks
both
Hello Herbert,
I think the pre-commit hook needs to be adjusted; I used to have
push rights on master, but I cannot seem to push to ghc-head.
Thanks,
Edward
Excerpts from Herbert Valerio Riedel's message of 2014-08-16 16:34:46 +0100:
On 2014-08-16 at 16:59:51 +0200, Mateusz Kowalczyk wrote:
Hello,
I am trying to compile GHC 7.8.3 on Windows. I was following the
instructions from the GHC wiki, but I have encountered errors during the
make process.
I have filed a bug report describing my issue:
https://ghc.haskell.org/trac/ghc/ticket/9513
Does anyone had working setup for building
Duncan has landed his changes to remove GHC's dep on Cabal, so you'll
need to do a clean and full rebuild once you pull from master.
Cheers,
Edward
___
ghc-devs mailing list
ghc-devs@haskell.org
http://www.haskell.org/mailman/listinfo/ghc-devs
1. I see you've set ticket's 'Architecture' field to be 'x86_64' while
make output suggests you try to build 32-bit ghc.
2. You are using 'old' MSys which is known to be problematic when
building GHC. It's much better to use MSYS2 now:
Thank you! I will dig into using that ASAP now that I can understand the
directions.
On Aug 29, 2014 5:50 AM, Simon Peyton Jones simo...@microsoft.com wrote:
I have added a section Ticky-ticky quick start to our ticky-ticky
profiling page, to explain how I go about dealing with the problem you
Hi Edward,
2014-08-29 16:11 GMT+02:00 Edward Z. Yang ezy...@mit.edu:
Duncan has landed his changes to remove GHC's dep on Cabal, so you'll
need to do a clean and full rebuild once you pull from master.
Do you know if this is related:
[..]
libraries\bin-package-db\GHC\PackageDb.hs:264:11:
Not
2014-08-29 17:59 GMT+02:00 kyra ky...@mail.ru:
it's extremely
important to remember you must *not* use msys2_shell.bat to start MSYS2
shell, only mingwXX_shell.bat (XX stands for 32 or 64) shall be used to
start MSYS2 shell -- otherwise GHC make system would not recognize build
triplet.
For
Yes, this is a bug, it looks like the Windows code bitrotted.
Could you go ahead and fix them (looks straightforward) and post your
patch?
Thanks,
Edward
Excerpts from Páli Gábor János's message of 2014-08-29 17:17:47 +0100:
Hi Edward,
2014-08-29 16:11 GMT+02:00 Edward Z. Yang
Hi,
Am Freitag, den 29.08.2014, 10:04 + schrieb Simon Peyton Jones:
I’ve pushed patches that should finally fix the build. (including
improved performance in the compiler itself!)
oh wow, what a huge number of patches. It’ll take a few days for
http://ghcspeed-nomeata.rhcloud.com/ to
Sorry,
Am Freitag, den 29.08.2014, 09:53 -0700 schrieb Joachim Breitner:
¹ https://github.com/tobami/codespeed
should have been
https://github.com/tobami/codespeed/issues/173
Greetings,
Joachim
--
Joachim “nomeata” Breitner
m...@joachim-breitner.de • http://www.joachim-breitner.de/
2014-08-29 18:23 GMT+02:00 Edward Z. Yang ezy...@mit.edu:
Could you go ahead and fix them [..] and post your patch?
Sure. Please find it attached.
diff --git a/libraries/bin-package-db/GHC/PackageDb.hs
b/libraries/bin-package-db/GHC/PackageDb.hs
index 5039a01..76fa697 100644
---
Hi Austin,
I've pushed wip/dph-fix branches to the dph and ghc repos. dph is not in
Phabricator, so I didn't submit anything for review. I think this is
small enough that we can probably just merge it directly, but it would
be nice to have DPH in Phabricator eventually.
I only validated on Linux
Yup. This is the MSYSTEM env. variable which determines 'uname' output
for client, see:
http://www.haskell.org/pipermail/ghc-devs/2013-October/002920.html.
Cheers,
Kyra
On 8/29/2014 20:22, Páli Gábor János wrote:
2014-08-29 17:59 GMT+02:00 kyra ky...@mail.ru:
it's extremely
important to
Phabricator complains about these two:
Unexpected failures:
ghc-api ghcApi [exit code non-0] (normal)
simplCore/should_compile T6056 [stderr mismatch] (optasm)
I doubt they are from me, as I only changed a (different) test and
fixed some comments.
Hmm. Did not fail for me when I validated but I'll try again. On my laptop.
S
| -Original Message-
| From: Gabor Greif [mailto:ggr...@gmail.com]
| Sent: 29 August 2014 19:41
| To: Simon Peyton Jones
| Cc: ghc-devs
| Subject: Re: build fixes
|
| Phabricator complains about these two:
Thank you! I've pushed it.
Simon
| -Original Message-
| From: ghc-devs [mailto:ghc-devs-boun...@haskell.org] On Behalf Of Páli
| Gábor János
| Sent: 29 August 2014 18:29
| To: Edward Z. Yang
| Cc: ghc-devs
| Subject: Re: HEADS UP: full rebuild necessary
|
| 2014-08-29 18:23 GMT+02:00
The ghc-api one is a known issue, I've been meaning to fix it but
haven't gotten around to it (the ghc-api test doesn't like being run
in parallel.)
Edward
Excerpts from Gabor Greif's message of 2014-08-29 19:40:58 +0100:
Phabricator complains about these two:
Unexpected failures:
On Thu, Aug 28, 2014 at 6:22 AM, Simon Peyton Jones
simo...@microsoft.com wrote:
Oh, now I understand. In
loop g = sum . map g $ [1..100]
GHC can share [1..10] across all calls to loop, although that nixes
fusion. Because each call of loop may have a different g.
But in
27 matches
Mail list logo
