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 [mailto:ghc-devs-boun...
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
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 I think it would be an acceptable bending of this principle, if people
w
Would it be worth adding some info from the commit message to the comment with
type MPZ#? In particular, the little table you give in the commit message is
helpful, but someone looking at the code won't see it. This is subtle stuff.
Simon
| -Original Message-
| From: ghc-commits [mail
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
wrote:
> This would be fine by me – it’s a “user-experience” question.
>
>
>
> It would slightly threaten the notion that G
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 :
http://ghc.haskell.org/trac/ghc/changeset/4af1e76c701a7
* Simon Peyton Jones [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 that's not the c
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 && ghc
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 rec
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 o
On 12/01/2014 22:56, Krzysztof Gogolewski wrote:
I propose to enable -XTypeHoles in GHC by default.
GHC supports strict Haskell 2010 by default, and enabling any extensions
breaks that property. That's why we don't have any extensions on by
default.
Cheers,
Simon
__
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 flags
Statically linked 64-bit Windows GHC does not work because of #7134.
Even LARGEADDRESSAWARE flag disabling (extremely bad hack itself) does
not work anymore both on Windows 7 and Windows 8.
Or is there another (besides dynamic linking) plan to attack #7134?
I could step in to try to help with
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:
https://github.com/ghc/ghc/commits/wip/pattern-syn
Sorry for typing in a hurry.
"some time age" should be read as "some time ago".
On 1/13/2014 14:51, kyra wrote:
Statically linked 64-bit Windows GHC does not work because of #7134.
Even LARGEADDRESSAWARE flag disabling (extremely bad hack itself) does
not work anymore both on Windows 7 and Win
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:
https://github.com/ghc/ghc/commits/wip/pattern-synonyms
https:/
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 dif
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:
>>>
>>> h
On Mon, 13 Jan 2014, Mateusz Kowalczyk wrote:
Oh and also, how do I reword the commit message of the single squashed
commit? I'm asking because there are some small fixes I'd like to do on
the message.
Thanks,
Gergo
You can do an interactive rebase and stop at the commit you want to
>From what I understood, you *should* have all permissions to push to
wip/ branches. If not, please contact the admins. (IIRC Austin did
this previously).
Cheers,
Gabor
On 1/13/14, Dr. ERDI Gergo wrote:
> On Mon, 13 Jan 2014, Mateusz Kowalczyk wrote:
>
>>> Oh and also, how do I reword the c
Herbert
I did 'git pull' in my source tree and got the error below. What do I do now?
Simon
== running git pull
remote: Counting objects: 56029, done.
remote: Compressing objects: 100% (16843/16843), done.
remote: Total 55837 (delta 32572), reused 55743 (delta 32500)
Receiving objects: 100% (
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: ghc-devs@hask
..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 12:19
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 c
On 2014-01-13 at 13:18:53 +0100, Simon Peyton Jones wrote:
> and then? are all those untracked files really untracked? I
> definitely didn't add them! Have they been lost from the tree
> somehow?
Well, Git just detects there's already something which it would
overwrite (as it doesn't know what
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 [mail
On Thu, 9 Jan 2014, Austin Seipp wrote:
1) As Richard pointed out, the docs are under docs/users_guide, as
well as the release notes. Please feel free to elaborate however you
want on the feature and the bulletpoint for the release notes.
Hope to get around to these in the weekend.
2) The fa
On Mon, 13 Jan 2014, Mateusz Kowalczyk wrote:
On a somewhat related note, you should probably update your Haddock
changes on top of the current master. Let me know if you have problems
merging it on top.
Hi Mateusz,
Thanks for the offer, but it seems my patches re-apply on top of Haddock's
l
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 th
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. doub
Ah, my apologies, for some reason I thought that -XTypeHoles implied
-fdefer-type-errors, but I see it doesn't. Ignore me!
Turning on TypeHoles by default looks like a useful thing, yes.
Cheers,
Simon
On 13/01/2014 12:30, Richard Eisenberg wrote:
Maybe I'm missing something here, but
| 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 TypedHole
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 20
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 serendipit
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
also
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 t
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 consu
Hello Herbert,
the fix in a little bit extended version is already up-stream:
https://github.com/haskell/cabal/commit/98a3feb23364897779dd665758949555a84dc5b8
What is the process to ask ghc developers to update from upstream?
Thanks!
Karel
On 01/ 5/14 06:29 PM, Herbert Valerio Riedel wrote:
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 one.
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
On 13/01/14 13:25, g...@git.haskell.org wrote:
Repository : ssh://g...@git.haskell.org/integer-gmp
On branch : master
Link :
http://ghc.haskell.org/trac/ghc/changeset/7bdcadda7e884edffb1427f0685493f3a2e5c5fa/integer-gmp
---
On 2014-01-13 at 21:57:03 +0100, Simon Marlow wrote:
> On 13/01/14 13:25, g...@git.haskell.org wrote:
>> Repository : ssh://g...@git.haskell.org/integer-gmp
>>
>> On branch : master
>> Link :
>> http://ghc.haskell.org/trac/ghc/changeset/7bdcadda7e884edffb1427f0685493f3a2e5c5fa/integer-gmp
>
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 ow
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 HEA
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 imp
46 matches
Mail list logo
