Hi,
First of all, I would like to ask whether or not someone can build
(not validate) GHC head on Mountain Lion. The reason why I ask is
that I found this issue:
http://stackoverflow.com/questions/13539066/can-write-to-a-non-blocking-fd-return-eagain-when-select-reports-it-as-writabl
On 03/14/2013 02:15 PM, Jan Stolarek wrote:
Hm, you're sure that LLVM 3.2 is in your path when you configure GHC?
I removed LLVM 3.0 from my system so there's no possibility of
mistaking 3.2 with 3.0. I'm also
getting lots of compilation warnings about untested LLVM version -
this didn't happen
I was able to reproduce Geoffrey's failure on Mac OS X 10.8, with LLVM
3.2. The stage2 compiler eventually segfaults (Segmentation Fault
11) during the build process after being compiled successfully with
stage1.
Something recently happened, because I was bootstrapping fine with
LLVM 3.2 recently
Hi folks,
I want to give you advance notice that I would like to make Cabal depend
on parsec. The implication is that GHC would therefore depend on parsec
and thus it would become a core package, rather than just a HP package.
So this would affect both GHC and the HP, though I hope not too much.
On Thu, 2013-03-14 at 14:53 +, Duncan Coutts wrote:
Hi folks,
I want to give you advance notice that I would like to make Cabal depend
on parsec. The implication is that GHC would therefore depend on parsec
and thus it would become a core package, rather than just a HP package.
So this
Where are all the fingerprints for the libraries? You only seem to have
the submodule libraries in there...
Geoff
On 03/14/2013 03:00 PM, Jan Stolarek wrote:
I'm attaching a fingerprint - is this OK?
I'm quite puzzled about this, mostly because yesterday I couldn't build GHC
using LLVM 3.0
Where are all the fingerprints for the libraries? You only seem to have
the submodule libraries in there...
Whoops, I ran the fingerprint script in the build tree which doesn't have
symlinks to .git
directories. Is this version of the fingerprint correct?
Janek
This GHC dependency on Cabal is putting a rather troubling constraint
in Cabal's evolution, which in my opinion is a serious problem. When I
first took a look at the dependencies between GHC and Cabal I found it
a bit strange that GHC would depend on Cabal as I would expect GHC to
be as low in the
On Thu, 2013-03-14 at 12:22 -0300, Administrator wrote:
This GHC dependency on Cabal is putting a rather troubling constraint
in Cabal's evolution, which in my opinion is a serious problem. When I
first took a look at the dependencies between GHC and Cabal I found it
a bit strange that GHC
I just tried building your fingerprinted tree here two different ways,
and both failed:
GHC 7.4.2 as bootstrap compiler + LLVM 3.2
GHC 7.6.2 as bootstrap compiler + LLVM 3.2
If you type llc -version at the command line, it really says it's 3.2?
Geoff
On 03/14/2013 03:06 PM, Jan Stolarek wrote:
Hi Richard,
I have a question regarding type families with overlapping syntax.
In below example the last two lines are overlapped, so the first gets selected
when I present type equality witness to GHC:
help :: Sing (ls :: Inventory a) - Sing (r :: Inventory a) - Sing (l :: a)
- Sing
Yes I think that'd be a great plan. It's bizarre that GHC depends on *all* of
Cabal, but only uses a tiny part of it (more or less the Package data type I
think).
Simon
| -Original Message-
| From: cabal-devel-boun...@haskell.org
[mailto:cabal-devel-boun...@haskell.org]
| On
On 03/14/2013 04:40 PM, Jan Stolarek wrote:
If you type llc -version at the command line, it really says it's 3.2?
You don't seem to believe me :)
Given that Austin and I have the stage 2 compiler failure and you don't,
I think it is reasonable do double check :)
[killy@xerxes : ~] llc
At least they didn't re-roll the release tarball a second time :)
Would be good to confirm that we built from the same source tree. I am
building LLVM HEAD right now and will try that with GHC.
Geoff
On 03/14/2013 04:54 PM, Austin Seipp wrote:
The LLVM 3.2 tarball has an annoying bug: it
On Thu, 2013-03-14 at 16:44 +, Simon Peyton-Jones wrote:
Yes I think that'd be a great plan. It's bizarre that GHC depends on
*all* of Cabal, but only uses a tiny part of it (more or less the
Package data type I think).
The sensible way to split it (I think) would be like this:
Hi Gabor,
I can't comment specifically on your code, because I'm afraid I don't
understand it all. But, I think I can answer your question:
GHC will select a type instance branch to use in a given type family
application if and only if the following 2 conditions hold:
1. There is a
urgh... really need to get a LLVM build bot up and running.
I'm tied up for next week or two so won't be able to address this
soon. Thanks though Austin for your work here and everyone else, great
to have the pain shared :).
Cheers,
David
On 14 March 2013 10:00, Geoffrey Mainland
My stage 2 compiler was crashing the first time it was invoked.
I just finished building GHC HEAD using LLVM compiled from HEAD, and that
worked, so perhaps this was just a 3.2 bug. I have yet to run the
testsuite though.
Geoff
On 03/14/2013 07:16 PM, Jan Stolarek wrote:
Goeff, Austin,
do
I'm trying to enable some ticky counters for profiling the RTS code (eg in
Storage.c:allocate). Much of the code was already in place, but disabled
via CPP.
I can enable the counters, but I'm having trouble making them only tick in
the debug RTS.
Can someone advise regarding the
TICKY_TICKY is the right #def to check, and it should work the straightforward
way. Why doesn't
#ifdef TICKY_TICKY
#define MYBUMP(ctr,n) ctr = ctr + n
#else
#define MYBUMP(ctr,n) /* nothing */
#endif
work?
As a trick, you can check and make sure TICKY_TICKY is actually defined by
inserting an
My stage2 compiler got built and also fails on any compilation, no matter
how trivial. After linking stage2, my build fails with:
$ make
===--- building phase 0
make -r --no-print-directory -f ghc.mk phase=0 phase_0_builds
make[1]: Nothing to be done for `phase_0_builds'.
===--- building phase 1
On 03/14/2013 09:36 PM, Austin Seipp wrote:
My stage2 compiler got built and also fails on any compilation, no
matter how trivial. After linking stage2, my build fails with:
$ make
===--- building phase 0
make -r --no-print-directory -f ghc.mk phase=0 phase_0_builds
make[1]: Nothing to be
I have Mountain Lion (10.8.2, to be exact) with XCode 4.6 installed, and I can
build GHC. I don't use XCode when building, but I believe the command-line dev
tools (like gcc) are shipped with XCode, so that might be something to look at.
Sorry I don't have any more suggestions!
Richard
On Mar
23 matches
Mail list logo
