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 p
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)
> thro
$ 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 wrote:
> what does the rebase flag do? I did my rebase via the sourcetree gui app..
>
>
> On Wed, Sep 18, 2013 at 6:
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 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:
> ./sync-all pull
>
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 wrote:
> hey all,
> i just rebased my prefetch patch
hey all,
i just rebased my prefetch patch onto HEAD, and now i'm working on getting
ghc to build
looks like Data.Primitive.Types is trying to import PrimWrappers rather
than PrimOpWrappers?
i patched that up in my local build, but that seems to be missing, unless
i'm overlooking somthing and i'm
On 9/18/13, Jan Stolarek 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 alex happy).
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 funct
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)
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 mean
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 SIM
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 there
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 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 lib
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 l
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
wrote:
> I think my tree is up to date but I’m
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
wrote:
> I think my tree is
I think my tree is up to date but I’m getting this. Any ideas?
simon
"inplace/bin/ghc-stage1" -hisuf hi -osuf o -hcsuf hc -static -H32m -O -Werror
-Wall -H64m -O0-package-name xhtml-3000.2.1 -hide-all-packages -i
-ilibraries/xhtml/. -ilibraries/xhtml/dist-install/build
-ilibraries/xhtml/d
Hi,
Am Mittwoch, den 18.09.2013, 17:03 + schrieb Simon Peyton-Jones:
> utils/hsc2hs/HSCParser.hs:24:10: Warning:
>
> ‛Parser’ is an instance of Monad but not Applicative - this will
> become an error in GHC 7.10, under the Applicative-Monad Proposal.
I had this as well, went away after a
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, i
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.
> * sly...@gmai
This may be not a typo, but rather a reference to the IO type from the
System.IO module.
* sly...@gmail.com [2013-09-18 16:07:03+0300]
> From: Sergei Trofimovich
>
> Signed-off-by: Sergei Trofimovich
> ---
> System/IO/Unsafe.hs | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff
From: Sergei Trofimovich
Signed-off-by: Sergei Trofimovich
---
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
+++ b/System/IO/Unsafe.hs
@@ -33,7 +33,7 @@ im
From: Sergei Trofimovich
Signed-off-by: Sergei Trofimovich
---
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
+++ b/System/IO/Unsafe.hs
@@ -16,7 +16,7 @@
-
24 matches
Mail list logo
