On Fri, May 17, 2013 at 11:49:26AM +0200, Jan Stolarek wrote:
Now here's the tricky part. I'm testing this with test
lib/integer/integerConstantFolding in the
testsuite and the test fails because rules for quotRemInteger, divModInteger,
quotInteger and
remInteger don't fire, leaving the
Hi,
when I try to use System.Posix.Semaphore.semUnlink on Ubuntu 13.04 I get
the following liker error:
/usr/bin/ld:
/home/sol/.install/haskell/ghc-7.0.4/lib/ghc-7.0.4/unix-2.4.2.0/libHSunix-2.4.2.0.a(Semaphore__3.o):
undefined reference to symbol 'sem_unlink@@GLIBC_2.2.5'
/usr/bin/ld:
If you remove everything but the quotInteger test from
integerConstantFolding and compile with -ddump-rule-rewrites then you'll
see that the eqInteger rule fires before quotInteger. This is presumably
comparing against 0, as the definition of quot for Integer (in GHC.Real)
is
_ `quot` 0
Thanks! I'll work on getting it onto the wiki soon. My next step is to
apply hardware transactions to improve STM performance. For this I will
need to collect some meaningful STM benchmarks. If anyone has some
particular use cases or code where they would like to see improved STM
performance
Hello,
aha, I'll try to fix this some time this week, I hadn't noticed that it was
broken. It is probably because the `type-nats` branch has not been merged
with `master` in a while, so there are discrepancies between the versions
of the compiler and the libraries.
-Iavor
On Sun, May 19, 2013 at
Hello,
I just pushed a merged version that built fine, and the simple type-nat
related tests in the testsuite pass.
Happy hacking, and apologies for the breakage.
-Iavor
On Mon, May 20, 2013 at 10:02 AM, Iavor Diatchki
iavor.diatc...@gmail.comwrote:
Hello,
aha, I'll try to fix this some time
you have access to hardware for testing HTM? I thought haswell wasn't
publicly available yet...
On Mon, May 20, 2013 at 10:31 AM, Ryan Yates fryguy...@gmail.com wrote:
Thanks! I'll work on getting it onto the wiki soon. My next step is to
apply hardware transactions to improve STM
hey all,
I think it'd be valuable to add direct C - object file compilation support
to the ghc compilation driver for a number of reasons, which i have filed
/ documented in a trac feature request ticket.
http://hackage.haskell.org/trac/ghc/ticket/7922
based upon my still cursory understanding
