On Tue, 2014-11-04 at 21:04 +, Simon Peyton Jones wrote:
| Yeah, that's too old; and there's not been a release of a Cabal
| which is new enough to do what you want.
Wow! I'm doing the most basic thing: using Cabal to install a package with a
specified GHC.
I'll try what you
| Actually I'd suggest you use the Cabal and cabal-install that are part
| of the ghc source tree, rather than Cabal/cabal-install HEAD. The two
| are not always the same.
Aha ok, thank you. How exactly do I do that? Where is the executable
cabal-install in the tree? IN inplace/bin I see
As part of #9358 I'm considering removing these two flags:
-ddump-simpl-phases: dumps simplifier statistics for phases of the simplifier
but it works only
when used together with -ddump-simpl-stats. User can limit which statistics are
displayed by
passing in either the simplifier phase number
Hi all,
some time ago I filed:
https://github.com/ekmett/categories/issues/4
against the 'categories' library. But I cannot see what is wrong with
the code. It also builds with older GHCs (though I should re-check
with 7.8.3).
So I conjecture this is a HEAD problem in GHC HEAD. It seems weird.
Sorry for the large amount of messages.
On 5. 11. 2014 8:01, David Macek wrote:
I'm running validate to double check (detected 4 CPUs).
I got the validate results:
Unexpected results from:
TEST=linker_unload listCommand002 T5681 T5486 T7571 ghcpkg05 T3924 T7702
plugins01 T6106 ghci038
I don't use either, so fine with me!
| -Original Message-
| From: Jan Stolarek [mailto:jan.stola...@p.lodz.pl]
| Sent: 05 November 2014 10:12
| To: ghc-devs@haskell.org
| Cc: Simon Peyton Jones
| Subject: Removing -ddump-simpl-phases and -ddump-core-pipeline flags?
|
| As part of #9358
Hmmm, is this cabal mess the reason for the problems with GHC head and
Cabal head on https://travis-ci.org/haskell-opengl/StateVar/jobs/39533455#L102?
I've brought up the problem in another thread, but there was no
conclusion. As it is, there seems to be no way to test things with GHC
head on
DynFlags list some LLVM flags as hidden:
( llvm-tbaa,Opt_LlvmTBAA, nop), -- hidden flag
( llvm-pass-vectors-in-regs,Opt_LlvmPassVectorsInRegisters, nop),
-- hidden flag
Do I undertsand correctly that hidden means not documented in the User's
Guide? Is there
I found this note in CmmCallConv:
-- On X86_64, we always pass 128-bit-wide vectors in registers. On 32-bit X86
-- and for all larger vector sizes on X86_64, LLVM's GHC calling convention
-- does not currently pass vectors in registers. The patch to update the GHC
-- calling convention to support
I have placed an ordering on it so that D426 comes first, then D438 and
finally D412, there was a very minor merge update required for D412.
On Tue, Nov 4, 2014 at 11:41 PM, Alan Kim Zimmerman alan.z...@gmail.com
wrote:
Hi all
Hopefully I will be able to stop harassing everyone on this topic
I skimmed Austin's message again and then began the hunt from the main wiki
page. I ended up with these open tabs:
https://ghc.haskell.org/trac/ghc/wiki/Commentary/Libraries
https://ghc.haskell.org/trac/ghc/wiki/Debugging/InstallingPackagesInplace
TL;DR, you cant use llvm 3.5 or 3.6 with any current ghc release. use 3.4
or older
On Tue, Nov 4, 2014 at 10:56 PM, Jens Petersen juhpeter...@gmail.com
wrote:
Hi Jarl,
I think I just ran into this too for Fedora 22 rawhide on ARM and found
your posts...
On 30 October 2014 16:11, Jarl
Thanks for pointing out that virus scanners could be an issue. I found
that Microsoft Security Essentials realtime scanning was on. I'll try
disabling it and see if that helps with the -j5 case.
For what it's worth, I tried disabling the virus scanner, but it did not
help, 4/8 validation
Starting with GHC 7.8.x, fingerprints are written into
annotated gpg-signed release tags:
http://git.haskell.org/ghc.git/tag/refs/tags/ghc-7.8.3-release
That way you're able to restore via the fingerprint for a given release
via:
./utils/fingerprint/fingerprint.py restore -f (git show
Yep, I say remove them both.
On Wed, Nov 5, 2014 at 4:57 AM, Simon Peyton Jones
simo...@microsoft.com wrote:
I don't use either, so fine with me!
| -Original Message-
| From: Jan Stolarek [mailto:jan.stola...@p.lodz.pl]
| Sent: 05 November 2014 10:12
| To: ghc-devs@haskell.org
|
Hi,
A build of the ghc-7.8 branch in its current state failed for me today
in compiler/types/TypeRep.lhs
I am at commit 7b1d4c4 (release note blurb...), there was only one
more since (revert 'revert'...).
It seems as though the merge of commit d71f316ef (...precedence when
printing
Gah, sorry about that. I'll fix it!
On Wed, Nov 5, 2014 at 2:31 PM, Jost Berthold
berth...@mathematik.uni-marburg.de wrote:
Hi,
A build of the ghc-7.8 branch in its current state failed for me today in
compiler/types/TypeRep.lhs
I am at commit 7b1d4c4 (release note blurb...), there was only
Thanks Jost; I somehow totally missed this and reverted it (I'll look
into fixing it properly shortly).
On Wed, Nov 5, 2014 at 2:35 PM, Austin Seipp aus...@well-typed.com wrote:
Gah, sorry about that. I'll fix it!
On Wed, Nov 5, 2014 at 2:31 PM, Jost Berthold
Dear Trac admins,
on the left panel of the Trac wiki there is a link
https://ghc.haskell.org/trac/ghc/query?status=patchol=idcol=summarycol=ownercol=typecol=prioritycol=milestonecol=componentorder=priority
called
'Patches for review'. This shows a mix of tickets that have patches
attached, and
Hello Moritz,
I tried to do this relatively recently and recorded the problems
here: https://ghc.haskell.org/trac/ghc/ticket/9652
I didn't finish diagnosing the further error.
Edward
Excerpts from Moritz Angermann's message of 2014-11-04 10:28:18 -0800:
Hi,
today I tried to build head
Hello Gergely,
I was cleaning up LoadIface and I noticed in
commit 69fa2e558d56178d33950df815c3233606b0d44e
Author: Austin Seipp aus...@well-typed.com
Date: Fri Nov 1 22:15:53 2013 -0500
Add support for module reification (#1480)
Authored-by: Gergely Risko
21 matches
Mail list logo
