Seems like this issue - https://ghc.haskell.org/trac/ghc/ticket/11155
I also build on OS X and haven't had any problems recently fwiw.
On Tue, Apr 5, 2016 at 6:58 PM, Sazanovich Nikita
wrote:
> Thanks for your reply, Matthew.
>
> I’ve tried to merge my local repository with ghc/master branch and
Thanks for your reply, Matthew.
I’ve tried to merge my local repository with ghc/master branch and after this I
couldn't build it (even checked out to a successful commit). I am getting this
kind of error.
Undefined symbols for architecture x86_64:
"_stg_sel_17_upd_info", referenced from:
_s1y
The cause of the initial blowup was adding the vector test suite to the
normal cabal file, in both 0O and O2 forms. This was done so that fusion
rules based bugs wouldn't lie in hiding for years.
It sounds like the issues that resulted in built blowup are fixed in 8.0.
My guess is it's a combinat
In the mean time, there is simply no way to do what you want. GHC 8 disallows
any variable whose type has a representation that contains any type variables.
Otherwise, GHC cannot be sure that the variable has a sensible runtime
representation.
Richard
On Apr 5, 2016, at 3:55 PM, Carter Schonwa
So in the mean time , if I want write a data type that's polymorphic over
types that are heap pointer represented, I'll need to use a kind type class
to bound my polymorphism? I'm interested in trying To understand if this
lets me quantify over ptry structures safely.
@ed, does any of this have an
Ryan Newton gmail.com> writes:
> Hi all, Is anyone currently working in, or interested in helping
> with, a new benchmark suite for Haskell? Perhaps, packaging up
> existing apps and app benchmarks into a new benchmark suite that
> gives a broad picture of Haskell application performance today?
No -- that's the one you want. Either wrap your EvBinds in some structure that
you can zonk, or submit a patch exporting zonkEvBinds. :)
Richard
On Apr 4, 2016, at 11:56 PM, Conal Elliott wrote:
> Thanks, Richard! Unfortunately, zonkEvBinds is not exported from TcHsSyn. Do
> you think there'
Yes, that's correct. The RuntimeRep story generally allows for such
polymorphism in the future, but it's not implemented yet. One concern is that
doing this would require RuntimeRep to look like
> data Levity = Lifted | Unlifted
> data RuntimeRep = PtrRep Levity | IntRep | VoidRep | ...
The pro
(sorry for duplicates, realized I couldn't post to the mailing list without
registering)
Hi Ryan,
I'm the student working on the CI part Joachim mentioned. It's not quite
there yet, but the ground work is done.
Basically, I'm writing a daemon that will read a config file for a list of
git re
