None seem to fail on my (Linux) box. It'd be good if someone felt able to dig
into the ones that are failing. If there is a good reason we should open a
ticket and mark them as expect_broken( ticket-number ). Thanks!
Simon
| -Original Message-
| From: ghc-devs
On 13/01/14 08:42, Simon Peyton Jones wrote:
None seem to fail on my (Linux) box. It'd be good if someone felt able to dig
into the ones that are failing. If there is a good reason we should open a
ticket and mark them as expect_broken( ticket-number ). Thanks!
Simon
Hm. I checked a log
Perhaps we should let type holes be used for one release (so we can get
some feedback) before turning it on by default?
On Mon, Jan 13, 2014 at 9:57 AM, Simon Peyton Jones
simo...@microsoft.comwrote:
This would be fine by me – it’s a “user-experience” question.
It would slightly threaten
Does this mean we have no 64-bit windows support for 7.8 (only
dynamic-linked compiler works on 64-bit windows)?
On 1/13/2014 10:28, g...@git.haskell.org wrote:
Repository : ssh://g...@git.haskell.org/ghc
On branch : master
Link :
* Simon Peyton Jones simo...@microsoft.com [2014-01-13 08:57:51+]
This would be fine by me - it's a user-experience question.
It would slightly threaten the notion that GHC is, by default, a
Haskell-2010 compiler; that is, it accepts H-2010 programs and rejects
non-H2010 programs.
But
The 64bit GHC 7.6.3 windows compiler was not dynamically linked,
although it did have -dynamic libraries (although using them is a pain
in Windows.) It loaded static object files (you can verify this
yourself: 'ghc -O foo.hs ghci foo' will load the object file, but
'ghc -dynamic -O foo.hs ghci
On 07/01/2014 18:18, Mateusz Kowalczyk wrote:
Ah, I think I understand now. If this is the case, at least the
‘alexGetChar’ could be removed, right? Is Alex 2.x compatibility
necessary for any reason whatsoever?
Yes, the backwards compatibility could be removed now that we require a
very
On 03/01/2014 18:43, Mateusz Kowalczyk wrote:
On 03/01/14 13:27, Simon Peyton-Jones wrote:
[snip]
Thank you. We need lots of help!
[snip]
While I hate to interrupt this thread, I think this is a good chance to
mention something.
I think the big issue for joining GHC development is the lack
On 07/01/2014 13:55, Benno Fünfstück wrote:
Hello,
is the following safe to do?
main = do
runGhc libdir $ do ...
runGhc libdir $ do ...
Or will this cause trouble? Is there state that is shared between the
two calls?
The main restriction here is that you can only set the static
Hi,
On Thu, 9 Jan 2014, Austin Seipp wrote:
Hi Gergo,
I went ahead and pushed the preliminary work to a new branch in the
official repositories. GHC, haddock and testsuite now have a
'wip/pattern-synonyms' branch, where you can test the code:
More on this:
On 1/13/2014 14:51, kyra wrote:
The last would be better, because dynamic-linked Windows GHC has
longer load time (which can jump to intolerable 2-3 secs, which
happens, I guess, when we approach 64k exported symbols limit).
which can jump to intolerable 2-3 secs refers to
On 13/01/14 11:06, Dr. ERDI Gergo wrote:
On Mon, 13 Jan 2014, Dr. ERDI Gergo wrote:
I went ahead and pushed the preliminary work to a new branch in the
official repositories. GHC, haddock and testsuite now have a
'wip/pattern-synonyms' branch, where you can test the code:
Hello Simon,
On 2014-01-13 at 13:08:02 +0100, Simon Peyton Jones wrote:
I did 'git pull' in my source tree and got the error below. What do
I do now?
the easist is to just move the testsuite folder out the way;
e.g. mv testsuite/ testsuite-old/
and then? are all those untracked files really untracked? I definitely didn't
add them! Have they been lost from the tree somehow?
| -Original Message-
| From: Herbert Valerio Riedel [mailto:hvrie...@gmail.com]
| Sent: 13 January 2014 12:16
| To: Simon Peyton Jones
| Cc:
..and indeed, having followed your advice, the new tree contains the claimed
not-present files. So all seems well. But it's a mystery to me.
Simon
| -Original Message-
| From: ghc-devs [mailto:ghc-devs-boun...@haskell.org] On Behalf Of Simon
| Peyton Jones
| Sent: 13 January 2014
Maybe I'm missing something here, but how does specifying TypeHoles make GHC
not compliant with Haskell 2010? Turning on TypeHoles should change only error
messages. The set of programs that compile (and their meanings) should remain
unchanged, by my understanding.
I'm mildly in favor of this
I think Austin (and the rest of us) would be thrilled if you felt able to help
with dynamic linking on Windows. Thank you.
I'm utterly ignorant of the details, but it would be SO GREAT to have some help
on this.
Austin can fill you in.
Simon
| -Original Message-
| From: ghc-devs
Perhaps already as part of such a feedback round/bikeshedding
opportunity, I'm wondering if I'm the only one who finds the name
TypeHoles confusing, since as far as I understand, the extension
enables holes in *expressions*, not types... I would personally find
something like TypedHoles (note the
Hi,
I'm cutting my teeth on some constant folding for floats in the cmm.
I have a question regarding the ticket I'm tackling:
Should floats be folded with infinite precision (and later truncated to the
platform float size) -- most useful/accurate, or folded with the platform
precision, i.e.
| Perhaps already as part of such a feedback round/bikeshedding
| opportunity, I'm wondering if I'm the only one who finds the name
| TypeHoles confusing, since as far as I understand, the extension
| enables holes in *expressions*, not types... I would personally find
| something like TypedHoles
Check out TcRnDriver.tcRnDeclsi.
Simon
| -Original Message-
| From: ghc-devs [mailto:ghc-devs-boun...@haskell.org] On Behalf Of Dr.
| ERDI Gergo
| Sent: 13 January 2014 12:49
| To: Austin Seipp
| Cc: Joachim Breitner; GHC Devs
| Subject: Re: Pattern synonyms for 7.8?
|
| On Thu, 9 Jan
Thanks. Reading what you write below, I can see two possible motivations.
1. Reduce stack sizes.
2. Eliminate memory moves
For (1) do we have any data to show that the non-overlap of areas was giving
rise to unacceptably big stacks?
For (2) that is indeed clever, but it's pretty
This is actually a bit more subtle than you'd think. Are those constants
precise and exact? (There's certainly floating point code that exploits
the cancellations in the floating point model) There's many floating point
computations that can't be done with exact rational operations. There's
Oh I see the ticket. Are you focusing on adding hex support to Double# and
Float# ? That would be splendid. We currently don have a decent way of
writing nan, and the infinities. That would be splendid.
On Monday, January 13, 2014, Carter Schonwald wrote:
This is actually a bit more subtle
I've hesitated to reply, because I have lots of questions but no time to
investigate in. I'm looking at your wiki page
https://github.com/takano-akio/ww-fusion
* Does your proposed new fold' run faster than the old one? You give
no data.
* The new foldl' is not a good
Using more stack generally (but not always) implies extra memory
traffic. I noticed it happening a lot, but I didn't make measurements -
we never had a way to generate code with just this one thing changed,
because the new code generator had lots of issues with bad code, and
this was just
I have re-sent the question to glasgow-haskell-users; to avoid duplication,
let's continue the thread there.
___
ghc-devs mailing list
ghc-devs@haskell.org
http://www.haskell.org/mailman/listinfo/ghc-devs
Hi,
I'd like to work on the primitives first. They are relatively easy to
implement. Here's how I figure it;
The internal representation of the floats in the cmm is as a Rational
(ratio of Integers), so they have infinite precision. I can implement all
the constant folding by just writing my own
Hello Karel,
On 2014-01-13 at 18:13:55 +0100, Karel Gardas wrote:
Hello Herbert,
the fix in a little bit extended version is already up-stream:
https://github.com/haskell/cabal/commit/98a3feb23364897779dd665758949555a84dc5b8
well, it's a first step that's in the master branch, but GHC HEAD
On 01/13/2014 05:21 PM, Kyle Van Berendonck wrote:
Hi,
I'd like to work on the primitives first. They are relatively easy to
implement. Here's how I figure it;
The internal representation of the floats in the cmm is as a Rational
(ratio of Integers), so they have infinite precision. I can
30 matches
Mail list logo
