John Lato-2 wrote
I'd like to compile ghc-7.8.2 with DynamicGhcPrograms disabled
Are you able to use template haskell (and qusiquoting) with this? Don't they
need dynamic libs?
--
View this message in context:
Hello all,
Recently I was wondering something: is there any reason to keep
-fext-core around? In particular, it's been broken for a while at this
point, see GHC bug #5630[1]
As far as I'm aware there really aren't any users of it still around
these days, at least none working with a modern GHC.
+1 from me
I’ve been meaning to say essentially the same thing as you just did. We all
seem to concentrate on *adding* things to GHC; it’s a bit refreshing to
consider *removing* something.
Echoing Austin somewhat:
- Anyone using external core is either working with an old GHC or is kludging
Hi Carter,
cabal-install-1.20.0.0, using Cabal 1.20.0.0. But this also happened IIRC
with just ghc, no libraries installed, and no cabal anywhere on the path.
In any case, thus far the worst behavior I've seen from a too-old cabal is
a compile failure, not a core dump :)
On Fri, Apr 25, 2014
I'm pleased to announce a new version of the functional graph library:
http://hackage.haskell.org/package/fgl-5.5.0.0
The main change in this version: proper Show, Read and Eq instances
for both graph implementations. Previously, Data.Graph.Inductive.Tree
had a pretty-printed Show output; now
On Sat, Apr 26, 2014 at 05:08:58PM +0200, Nicola Squartini wrote:
Version 1.15.0 of HSE was not compiled with llvm, was it? At least from
what I see from the git history.
That is correct.
I held back on adding HSE to [haskell-testing] for a long time due to
GHC 7.8 not being able to compile it
On Sat, Apr 26, 2014 at 05:27:08PM -0700, Richard Wallace wrote:
Hm. Ok so the first time I don't think I had a completely clean
repository like I thought. After adding a new package to the
cblrepo.db, I started getting the same thing when trying to build
all the packages without deleting the
On Sun, Apr 27, 2014 at 10:16:30PM +0200, Nicola Squartini wrote:
Is it possible that LLVM automatically optimizes for your
architecture or triggers the use of some simd that is not present on
my AMDs?
I suppose that might be the case. It is possible to pass options to
specific parts of the
On Sun, Apr 27, 2014 at 01:23:18PM -0700, Richard Wallace wrote:
Right, sorry for not including more details. So what I'm trying to do is
get all the needed packages for adding taffybar built. The first I tried
with was HStringTemplate. My last attempt at doing this looking a bit like
#
I never used LLVM so I'm looking at the manual right now. It's explained
here:
http://llvm.org/docs/CommandGuide/llc.html#cmdoption-mcpu
It autodetects the cpu and optimizes for it.
As I understand, in order to produce generic code you should pass
-mcpu=i686 or -mcpu=x86_64. They can be passed
On Sun, Apr 27, 2014 at 11:11:25PM +0200, Nicola Squartini wrote:
I never used LLVM so I'm looking at the manual right now. It's explained
here:
http://llvm.org/docs/CommandGuide/llc.html#cmdoption-mcpu
It autodetects the cpu and optimizes for it.
As I understand, in order to produce
Aha! I understand now. I was overusing the -c option. Things are going
much more smoothly now. Thanks!
On Sun, Apr 27, 2014 at 2:08 PM, Magnus Therning mag...@therning.orgwrote:
On Sun, Apr 27, 2014 at 01:23:18PM -0700, Richard Wallace wrote:
Right, sorry for not including more details.
On Mon, Apr 28, 2014 at 12:08:08AM +0200, Nicola Squartini wrote:
I remember reading somewhere that packages that use parallelism,
like `repa`, would benefit from the llvm backend. I've never seen
benchmarks though.
Ah, sounds interesting. What I have read in some old haskell-cafe
posts is
On Sun, Apr 27, 2014 at 03:18:34PM -0700, Richard Wallace wrote:
Aha! I understand now. I was overusing the -c option. Things are going
much more smoothly now. Thanks!
Indeed! :)
Possibly the help for -c (and maybe even -x too) can be improved.
Please let me know if you think so, and how.
14 matches
Mail list logo
