Hello Simon (et al.)
While experimenting with refactoring/improving integer-gmp, I'd like to
represent a GMP number just by a ByteArrays# (and thus save a redundant
limb-count field). However, for that I'd need an efficient way to resize
a MutableByteArray# for the result value in case its
Hi *,
Quick notice: I spent some time hacking to get Phabricator to build
code reviews you publish against the GHC repository. It luckily was
not that hard to do so - hooray!
Go here for an example:
https://phabricator.haskell.org/D64
Look at the top set of information, and find 'Build
Yes, this will cause problems in some modes, namely -debug and -prof
that need to be able to scan the heap linearly. Usually we invoke the
OVERWRITING_CLOSURE() macro which overwrites the original closure with
zero words, but this won't work in your case because you want to keep
the original
Hi,
I just added a .travis.yml file to GHC master. This means that every
push will be validated automatic and for free by travis; you can check
the build status at https://travis-ci.org/ghc/ghc/builds
It is not a full validation. In particular,
* it skips DPH
* it does not build dynamic
On 7/12/14, Joachim Breitner m...@joachim-breitner.de wrote:
Hi,
I just added a .travis.yml file to GHC master. This means that every
push will be validated automatic and for free by travis; you can check
the build status at https://travis-ci.org/ghc/ghc/builds
It is not a full validation.
In building the OS X bindist for 7.8.3, I had to choose which of several
ways to build it. In particular, I could build it with a newere Xcode,
which uses clang, or an older Xcode which uses gcc. I decided to nofib
benchmark the variations and see before I released. Here is what I found...
I
I thought clang was slower than gcc because clang doesn't support thread
local variables (in some form we need) and therefore GC performance
suffered a lot on clang.
On Sat, Jul 12, 2014 at 9:27 PM, Mark Lentczner mark.lentcz...@gmail.com
wrote:
In building the OS X bindist for 7.8.3, I had to
This is great!
___
ghc-devs mailing list
ghc-devs@haskell.org
http://www.haskell.org/mailman/listinfo/ghc-devs
Thank you Luke. The binaries are uploaded and on the webpage.
On Fri, Jul 11, 2014 at 9:54 PM, Luke Iannini lukex...@gmail.com wrote:
Hi Austin/all,
Here are the iOS builds!
http://tree.is/files/ghc-7.8.3-arm-apple-ios.tar.bz2
http://tree.is/files/ghc-7.8.3-arm-apple-ios.tar.bz2.sha1
Maybe it depends on the version of OS X being used? Maybe TLS works
differently pre 10.8 or 10.9?
On Saturday, July 12, 2014, Johan Tibell johan.tib...@gmail.com wrote:
I thought clang was slower than gcc because clang doesn't support thread
local variables (in some form we need) and
I will try to measure on 10.7 later today.
Preliminary numbers for gcc 4.9 are even better than clang - it saves 12%
over gcc 4.2 builds. However, the gcc runtime isn't the same as the Apple
standard... and we are so far at a loss how to package a ghc based on 4.9
that would work for Mac users
why wouldn't it work?
heres my 4.9 gcc build, I believe it should work on any = 10.7 system that
has xcode cli tools installed,
please let me know if it fails!
http://www.wellposed.com/opensource/ghc/releasebuild-unofficial/ghc-7.8.3-x86_64-apple-darwin.tar.bz2
On Sat, Jul 12, 2014 at 9:04
On Fri, Jul 11, 2014 at 6:40 AM, Austin Seipp aus...@well-typed.com wrote:
The GHC Team is pleased to announce a new patchlevel release of GHC, 7.8.3.
haddock 2.14.3 that ships with it seems to be quite broken. Perhaps it's a
bad interaction with cabal, it's hard to say from the outside, but
So, it appears that the one ending with 21 is the likely correct result; as
opposed to 22.
Is this an issue with some underlying library (glibc etc.); or an issue
with GHC itself?
On Sat, Jul 12, 2014 at 8:03 PM, GHC ghc-devs@haskell.org wrote:
#9304: Floating point woes; Different behavior
14 matches
Mail list logo
