Hi,
Am Montag, den 16.09.2013, 05:53 + schrieb Simon Peyton-Jones:
a) A newtype can be casted only if its constructor is visible.
b) Casting below a type constructor (instance Coercible a b = Coercible
(Maybe a) (Maybe b)) is possible if the roles allow it; the
constructor
Hi Austin,
Awesome, thanks so much — that gives me a much better understanding and a
good roadmap of how to fix it. I'll start looking into it.
Edward, I'll do that, thanks!
Cheers
Luke
On Sat, Sep 14, 2013 at 12:50 AM, Austin Seipp aus...@well-typed.comwrote:
The second results are self
Joachim
I'm not convinced about your solution. It seems a bit of a hack. Moreover, the
very same issue arises for ordinary type classes, so I'd prefer to solve it for
all of them at once. Finally, the very existence of Coercible is going to
eliminate most of these (map Age) calls anyhow.
There will be a major change in primops pushed into HEAD, hopefully with next
24 hours. This change breaks backwards compatibility for comparison primops and
ONCE IT IS PUSHED will require you to:
1) Upgrade to latest versions of Alex and Happy (cabal update cabal install
alex happy). These
On 09/16/2013 09:48 AM, Jan Stolarek wrote:
There will be a major change in primops pushed into HEAD, hopefully with next
24 hours. This change
breaks backwards compatibility for comparison primops and ONCE IT IS
PUSHED will require you to:
1) Upgrade to latest versions of Alex and Happy
Hi,
Am Montag, den 16.09.2013, 15:48 +0200 schrieb Jan Stolarek:
1) Upgrade to latest versions of Alex and Happy (cabal update cabal
install alex happy). These versions are not yet available. When they
are DO NOT INSTALL THEM UNTIL CHANGES ARE PUSHED INTO HEAD.
why? Will they not be
- Oryginalna wiadomość -
Od: Jan Stolarek jan.stola...@p.lodz.pl
Do: Joachim Breitner m...@joachim-breitner.de
Wysłane: poniedziałek, 16 wrzesień 2013 15:14:01
Temat: Re: HEADS UP: New primops on the way
New Alex and Happy will have conditional checks to see whether they are
generating
(Sorry for double posting).
New Alex and Happy will have conditional checks to see whether they are
generating code for GHC =7.6 or for GHC 7.6. The only two intended
situations when things will go wrong are:
1) You have these new versions of Alex and Happy and you are trying to compile
7.7
Hi,
Am Montag, den 16.09.2013, 16:14 +0200 schrieb Jan Stolarek:
New Alex and Happy will have conditional checks to see whether they
are generating code for GHC =7.6 or for GHC 7.6.
ok, that sound good enough for Debian’s needs.
Thanks,
Joachim
--
Joachim Breitner
e-Mail:
I'm getting these validation failures today on HEAD (64 bit Linux):
OVERALL SUMMARY for test run started at Mon Sep 16 16:18:39 BST 2013
3793 total tests, which gave rise to
15020 test cases, of which
11569 were skipped
28 had missing libraries
3362 expected passes
58
Friends,
The time is here! We'll be closing off new features this week. There
are some exceptions that have been made already:
* Geoffrey will get SIMD/Template Haskell in this week, as he's been
a little busy. But it's very close.
* I believe Trevor and Iavor would still like to get Kinds
Oh, and of course, Edsko and Luite have made the final changes to
their hooks patch, and as far as I can tell, all our potential users
are quite happy! I've already given them an exception as well. I
expect I will merge it in the next day or two, after another code
review.
On Mon, Sep 16, 2013 at
Yep, the linker_unload and T5435_v are known (tracking #5435)
and I'll be fixing them today.
Edward
Excerpts from Jan Stolarek's message of Mon Sep 16 08:28:05 -0700 2013:
I'm getting these validation failures today on HEAD (64 bit Linux):
OVERALL SUMMARY for test run started at Mon Sep 16
This looks pretty exiting for LLVM IR-generation:
http://lists.cs.uiuc.edu/pipermail/llvm-commits/Week-of-Mon-20130909/188042.html
GHC 7.10 might generate LLVM IR including embedded tables without
resorting to linker tricks/postprocessing when targeting LLVM 3.4!
The relevant LLVM bug is
On 9/16/13, Carter Schonwald carter.schonw...@gmail.com wrote:
yup! its exciting.
we were talking about this a bit earlier today on #haskell-llvm, and it
sounds doable.
There were some concerns that folks had, but hopefully we can give the llvm
devs feedback about this before its finalized
May not be mandatory but it certainly just emits the values directly before
the prologue... I'm guessing this doesn't affect IR level optimizations but
likely breaks machine code optimizations without a relative jump to the
body in the prefix-data.
https://gist.github.com/NathanHowell/6589820
-n
16 matches
Mail list logo