From: Sergei Trofimovich sly...@gentoo.org
Signed-off-by: Sergei Trofimovich sly...@gentoo.org
---
System/IO/Unsafe.hs | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/System/IO/Unsafe.hs b/System/IO/Unsafe.hs
index 1971e9f..67068c5 100644
--- a/System/IO/Unsafe.hs
+++
From: Sergei Trofimovich sly...@gentoo.org
Signed-off-by: Sergei Trofimovich sly...@gentoo.org
---
System/IO/Unsafe.hs | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/System/IO/Unsafe.hs b/System/IO/Unsafe.hs
index eb6eef6..1971e9f 100644
--- a/System/IO/Unsafe.hs
+++
This may be not a typo, but rather a reference to the IO type from the
System.IO module.
* sly...@gmail.com sly...@gmail.com [2013-09-18 16:07:03+0300]
From: Sergei Trofimovich sly...@gentoo.org
Signed-off-by: Sergei Trofimovich sly...@gentoo.org
---
System/IO/Unsafe.hs | 2 +-
1 file
On Wed, Sep 18, 2013 at 04:22:47PM +0300, Roman Cheplyaka wrote:
This may be not a typo, but rather a reference to the IO type from the
System.IO module.
Yes, if the module were intended it would be in double quotes.
This change will break the link intended for the 'IO' monad.
*
New comparison primops are now in HEAD. This change breaks backwards
compatibility for comparison primops. What you need to do after pulling the
latest HEAD is:
1) Upgrade to latest versions of Alex and Happy (cabal update cabal install
alex happy).
2) Rebase your branches on top of HEAD, if
Simon, this should now be fixed in
9960cac0996585a592b9b53cd19356eb8abb3526 - please update your copy of
hsc2hs under utils/
See
http://git.haskell.org/hsc2hs.git/commitdiff/9960cac0996585a592b9b53cd19356eb8abb3526
On Wed, Sep 18, 2013 at 12:03 PM, Simon Peyton-Jones
simo...@microsoft.com
Hm, somehow we missed an Applicative instance in HSCParser when I
applied David's patches, but I'm not sure how. I haven't seen this at
all during my validate runs...
I can push a fix momentarily.
On Wed, Sep 18, 2013 at 12:03 PM, Simon Peyton-Jones
simo...@microsoft.com wrote:
I think my tree
I've been getting failures from a few performance test:
- haddock.base (stat too good - allocation has decreased). I see that
allocation was bumped yesterday by Joachim due to changes in printf
implementation. For me this causes a failure. Actual bytes allocated: 6294339840
- T5837. Stat too
On 11/09/13 17:28, Duncan Coutts wrote:
All,
I was discussing this with Yuri earlier and I had an idea that I think
may resolve our problems.
Firstly, what are the problems:
1. ghc devs and users grumble because the ghc library depends on
Cabal, making it hard to use the ghc
This is slightly problematic. What if we have a wonderful SIMD-enabled
vector library that we compile with -fllvm, and then use it in a program
that isn't compiled with -fllvm, and some of the wonderful SIMD-enabled
functions get inlined? Presumably we get a panic in the NCG.
Did we discuss
On 12/09/13 20:28, Nicolas Frisby wrote:
On my laptop, a program showed a consistent slowdown with -fdicts-strict
I didn't find any obvious causes in the Core differences, so I turned to
Intel's Performance Counter Monitor for measurements. After trying a few
counters, I eventuall saw that
We did discuss this, but you may not have been present.
If LLVM-only primops show up in a non-LLVM codegen, a sorry error is
reported telling the user that they need to compile with -fllvm. Yes,
this is not a fantastic solution. Options I see:
1) Live with the error message.
2) Remove all SIMD
On 17/09/13 17:28, Edward Z. Yang wrote:
This would be the failing linker_unload test; known problem. Simon Marlow
is working on it.
Simon Marlow is not *actually* working on it at this very minute, and
might not get to it for a few days (I'll probably fix it at ICFP next
week). In the
On 18/09/13 20:01, Geoffrey Mainland wrote:
We did discuss this, but you may not have been present.
If LLVM-only primops show up in a non-LLVM codegen, a sorry error is
reported telling the user that they need to compile with -fllvm. Yes,
this is not a fantastic solution. Options I see:
1)
I've some thoughts on how to have a better solution, but they are feasible
only on a time scale suitable for 7.10, and not for 7.8.
a hacky solution we could do for 7.8 perhaps is have a warning that works
as follows:
either
a)
throw a warning on functions that use the SIMD primops, if that
On 9/18/13, Jan Stolarek jan.stola...@p.lodz.pl wrote:
New comparison primops are now in HEAD. This change breaks backwards
compatibility for comparison primops. What you need to do after pulling the
latest HEAD is:
1) Upgrade to latest versions of Alex and Happy (cabal update cabal
install
I had the same error, turned out that
./sync-all pull --rebase
did not correctly terminate, because I had modified files around
This helped:
./sync-all pull
perl boot
./configure
make --keep-going
HTH,
Gabor
On 9/19/13, Carter Schonwald carter.schonw...@gmail.com wrote:
hey all,
i just
what does the rebase flag do? I did my rebase via the sourcetree gui app..
On Wed, Sep 18, 2013 at 6:40 PM, Gabor Greif ggr...@gmail.com wrote:
I had the same error, turned out that
./sync-all pull --rebase
did not correctly terminate, because I had modified files around
This helped:
$ git pull --rebase
just pulls and then rebases your local commits. It gives up (with an
error message) if there are unstaged changes in the workspace.
On 9/19/13, Carter Schonwald carter.schonw...@gmail.com wrote:
what does the rebase flag do? I did my rebase via the sourcetree gui app..
On
On 09/18/2013 04:49 PM, Carter Schonwald wrote:
I've some thoughts on how to have a better solution, but they are
feasible only on a time scale suitable for 7.10, and not for 7.8.
a hacky solution we could do for 7.8 perhaps is have a warning that
works as follows:
either
a)
throw a
yup, i hit a gap in what we can currently express in haskell types. We
don't have a way of expressing static data! I actually put ticket on trac
noting this. http://ghc.haskell.org/trac/ghc/ticket/8107
(note that when i was initially writing the ticket, i incorrectly thought
the int# arg to ghc's
21 matches
Mail list logo
