062... ddd1c8b...
Author: Johan Tibell
Date: Thu Nov 29 20:04:29 2012 -0800
Merge branch 'master' of https://github.com/ghc/testsuite
config/ghc | 54 +--
driver/runtests.py |5 +-
driver/t
f99... 7ad5ea6...
Author: Johan Tibell
Date: Wed Sep 12 17:33:22 2012 +0200
Merge branch 'master' of https://github.com/ghc/testsuite
driver/testlib.py |5 +
mk/test.mk |1 -
tests/annotations/should
Repository : ssh://darcs.haskell.org//srv/darcs/testsuite
On branch : master
http://hackage.haskell.org/trac/ghc/changeset/93a9f9907985a454015848ab44e49b0c40697a8e
>---
commit 93a9f9907985a454015848ab44e49b0c40697a8e
Author: Jo
Repository : ssh://darcs.haskell.org//srv/darcs/testsuite
On branch : master
http://hackage.haskell.org/trac/ghc/changeset/2c3d47475e69cac5a6672258d4bb6db7a4eebe3d
>---
commit 2c3d47475e69cac5a6672258d4bb6db7a4eebe3d
Author: Jo
f21... 894e4a2...
Author: Johan Tibell
Date: Thu Dec 13 07:50:12 2012 -0800
Merge branch 'master' of https://github.com/ghc/testsuite
mk/boilerplate.mk |3 +
tests/generics/GenCanDoRep1.hs |4 +
tests/ghc-a
261... 55b6fd4...
Author: Johan Tibell
Date: Mon Jan 7 18:00:45 2013 -0800
Merge branch 'master' of https://github.com/ghc/testsuite
config/ghc |3 +
driver/testglobals.py |3 +
driv
On Thu, Jan 3, 2013 at 12:11 PM, Daniel Fischer
wrote:
> On Donnerstag, 3. Januar 2013, 09:01:11, Geoffrey Mainland wrote:
>>
>> Fix LLVM code generated for word2Float# and word2Double#.
>>
>
> That reminds me, on 32-bit,
>
> 2^53 :: Word
>
> is 0, and that means the test fails.
I don't have
Repository : ssh://darcs.haskell.org//srv/darcs/testsuite
On branch : master
http://hackage.haskell.org/trac/ghc/changeset/9f4dd2d2235aaa4bb3965c0752775ad309c2fafb
>---
commit 9f4dd2d2235aaa4bb3965c0752775ad309c2fafb
Author: Jo
On Tue, Dec 18, 2012 at 2:32 AM, Simon Peyton-Jones
wrote:
> OK? We should document this convention somewhere.
As long as this is the policy nowadays I don't feel a strong need to
document it, but feel free to if you want.
___
Cvs-ghc mailing list
Cvs
Repository : ssh://darcs.haskell.org//srv/darcs/testsuite
On branch : master
http://hackage.haskell.org/trac/ghc/changeset/8b3c309b6ef75b21e3e888b89f3bb3e8717e7e3e
>---
commit 8b3c309b6ef75b21e3e888b89f3bb3e8717e7e3e
Author: Jo
Repository : ssh://darcs.haskell.org//srv/darcs/ghc
On branch : master
http://hackage.haskell.org/trac/ghc/changeset/2e8c769422740c001e0a247bfec61d4f78598582
>---
commit 2e8c769422740c001e0a247bfec61d4f78598582
Author: Johan Tib
On Thu, Dec 13, 2012 at 11:23 AM, Erik de Castro Lopo
wrote:
> I've been seeing this as well on my PowerPC build machine
> where is complains about Intel instrictions.
>
> My investigation so far has found (I was about to raise a
> bug):
>
> a) This seems to be some sort of build system race condi
On Wed, Dec 12, 2012 at 4:35 AM, Simon Marlow wrote:
> On 11/12/12 21:33, Johan Tibell wrote:
>> I'd definitely be interesting in understanding why as it, like you
>> say, makes it harder for LLVM to understand what our code does and
>> optimize it well.
>
>
&g
On Wed, Dec 12, 2012 at 5:27 AM, Simon Marlow wrote:
> On 11/12/12 21:31, Johan Tibell wrote:
>> On Tue, Dec 11, 2012 at 1:02 PM, Simon Peyton-Jones
>> wrote:
>>> | I'm happy to call this -funbox-strict-small-fields. However, I'd like
>>> | the docum
On Tue, Dec 11, 2012 at 11:16 AM, Simon Peyton-Jones
wrote:
> Notice that the stack is now *explicit* rather than implicit, and LLVM has no
> hope of moving the assignment to z past the call to g (which is trivial in
> the original). I can explain WHY we do this (there is stuff on the wiki) but
On Tue, Dec 11, 2012 at 1:02 PM, Simon Peyton-Jones
wrote:
> | >data T = MkT !S
> | >data S = MkS Int
> | >
> | > then my impl will unbox the S field of MkT because the result is only
> one field
> | wide, namely an Int.
> |
> | Wouldn't Johan's have unboxed S too? (if not,
Simon,
On Tue, Dec 11, 2012 at 4:29 AM, Simon Peyton-Jones
wrote:
> So I totally refactored everything which cost me a couple of days (because it
> has quite wide span). I'm validating now.
Yay for code clean-ups!
> So I changed it to "...AND the unboxed version is at most one field wide".
On Tue, Dec 11, 2012 at 7:04 AM, Ian Lynagh wrote:
> Does that sound reasonable? Does anyone have any further questions or
> comments?
Sound good to me. Thanks for working on this.
-- Johan
___
Cvs-ghc mailing list
Cvs-ghc@haskell.org
http://www.haske
Repository : ssh://darcs.haskell.org//srv/darcs/ghc
On branch : master
http://hackage.haskell.org/trac/ghc/changeset/332e68122d578fbc09f49b61a628217a60a70877
>---
commit 332e68122d578fbc09f49b61a628217a60a70877
Author: Johan Tib
Repository : ssh://darcs.haskell.org//srv/darcs/ghc
On branch : master
http://hackage.haskell.org/trac/ghc/changeset/1435eef2422d3f9120b9bafb3fa497b0c505055d
>---
commit 1435eef2422d3f9120b9bafb3fa497b0c505055d
Author: Johan Tib
Repository : ssh://darcs.haskell.org//srv/darcs/ghc
On branch : master
http://hackage.haskell.org/trac/ghc/changeset/7bf6eb9a86c160a54ea3df553ade040d5c37c627
>---
commit 7bf6eb9a86c160a54ea3df553ade040d5c37c627
Author: Johan Tib
On Fri, Dec 7, 2012 at 3:23 AM, Simon Marlow wrote:
> I don't think you wanted to add this file to
> tests/ghc-regress/typecheck/..., it should go in tests/typecheck/...
Fixed. I must have had an old testsuite tree at some point because we
don't seem to use the ghc-regress/ dir anymore.
Repository : ssh://darcs.haskell.org//srv/darcs/testsuite
On branch : master
http://hackage.haskell.org/trac/ghc/changeset/56036c90222965ee248588ebf45bab93d2187959
>---
commit 56036c90222965ee248588ebf45bab93d2187959
Author: Jo
Repository : ssh://darcs.haskell.org//srv/darcs/ghc
On branch : master
http://hackage.haskell.org/trac/ghc/changeset/4f7027d6947af9c5cdecc0c18097268594c4592b
>---
commit 4f7027d6947af9c5cdecc0c18097268594c4592b
Author: Johan Tib
On Thu, Dec 6, 2012 at 6:06 AM, Simon Peyton-Jones
wrote:
> Johan
>
> Yes broadly that looks like the right kind of thing.
>
> I think it'd be better to look more like "can_unbox". So first check for a
> product tycon (ie one data constructor), then deal with newtypes, and *then*
> do something
Repository : ssh://darcs.haskell.org//srv/darcs/testsuite
On branch : master
http://hackage.haskell.org/trac/ghc/changeset/b2c5047da15f0b6441db7e615a84ce64d0f77890
>---
commit b2c5047da15f0b6441db7e615a84ce64d0f77890
Author: Jo
Repository : ssh://darcs.haskell.org//srv/darcs/ghc
On branch : master
http://hackage.haskell.org/trac/ghc/changeset/566920c77bce252d807e9a7cc3da862e5817d340
>---
commit 566920c77bce252d807e9a7cc3da862e5817d340
Author: Johan Tib
On Thu, Dec 6, 2012 at 1:49 PM, David Terei wrote:
> I think that sounds too involved. How many maintainers would we really
> be looking at at this point? I think only around 5 - 10 really. So a
> single file in the root seems easiest.
>
> The other concern is some components of GHC are all over t
On Thu, Dec 6, 2012 at 8:32 AM, Ian Lynagh wrote:
> Perhaps we could have "maintainers" instead?
If maintenance can be defined on a per-directory level we can put a
MAINTAINERS file in listing maintainers for a directory and all its
subdirectories. For example,
ghc/MAINTAINERS would contain
On Dec 6, 2012 4:39 AM, "Simon Peyton-Jones" wrote:
>
> (Narrowing to cvs-ghc for now.)
>
> Speaking for myself, I would welcome a code-ownership model along the
lines that Ben suggests. If it works well it would
> a) spread the load
> b) broaden a genuine sense of ownership
> c) because of
Repository : ssh://darcs.haskell.org//srv/darcs/nofib
On branch : master
http://hackage.haskell.org/trac/ghc/changeset/14bccff2c547c0e06fe8f98607b9cf18890ef051
>---
commit 14bccff2c547c0e06fe8f98607b9cf18890ef051
Author: Johan Tib
First, thanks to Ian for implementing this.
On Sun, Nov 25, 2012 at 1:18 PM, Ian Lynagh wrote:
> On Fri, Nov 02, 2012 at 08:10:04PM +, Ian Lynagh wrote:
>>
>> We have been working on a new way in which we handle the repositories
>> that make up a GHC tree, in order to makes the process smooth
On Thursday, November 22, 2012, Simon Peyton-Jones wrote:
>
> (He remarked that the new Cabal installs both static and dynamic by
> default; should that be dynamic only? Do others have opinions?
>
> This seems pretty urgent to me.
This seems pretty urgent to me as well. Is there some write-up ab
On Mon, Oct 22, 2012 at 9:14 AM, Simon Peyton-Jones
wrote:
> Do you mean “silently and forever”? Deprecation simply means that
> everything continues to work, but you get a little nudge to change. Isn’t
> that what it’s for? If you treat deprecation as equivalent to error, then
> there isn’t m
On Mon, Oct 22, 2012 at 11:02 AM, Ashley Yakeley wrote:
> I think it's OK if a compiler accepts a program incorrectly marked
> "Rank2Types" when it actually requires rank-n types?
It's an interesting question: does Rank2Types mean "I require at least
rank-2 types" or "I only use rank-2 types"?
_
On Mon, Oct 22, 2012 at 9:14 AM, Simon Peyton-Jones
wrote:
> Do you mean “silently and forever”? Deprecation simply means that
> everything continues to work, but you get a little nudge to change. Isn’t
> that what it’s for? If you treat deprecation as equivalent to error, then
> there isn’t m
Hi Simon,
On Fri, Oct 19, 2012 at 4:49 AM, Simon Peyton-Jones
wrote:
> As discussed in Trac #6032 I am deprecating
>
> Rank2Types
>
> PolymorphicComponents
>
> in favour of the single flag
>
> RankNTypes
I'm fine with making the changes to cabal, but before I do, I
Could we have the primop take the length instead of requiring a
null-terminated string? That way we can more efficiently support using
the primops with ByteStrings or Texts without copying them just to add
a null terminator. Also, it's slightly safer to have explicit lengths.
On Mon, Oct 15, 2012
On Sun, Oct 14, 2012 at 12:00 PM, Gábor Lehel wrote:
> On Sun, Oct 14, 2012 at 8:47 PM, Dan Burton wrote:
>> At the risk of useless bikeshedding... might I suggest "r" as a mnemonic for
>> "result"?
>>
>> foldl :: (a -> r -> r) -> r -> [a] -> r
>> foldr :: (r -> a -> r) -> r -> [a] -> r
>>
>> --
On Thu, Sep 27, 2012 at 3:12 AM, Ilya Sergey wrote:
> Do not pull master!!
>
> I think, I messed up terribly by making a "force" git push into master.
> As a result, the commit history since 21 august was lost.
>
> Could someone, please, restore the history by push a right commit history
> since t
On Wednesday, September 5, 2012, Simon Marlow wrote:
> I've started a wiki page to list the cleanup tasks we need to get done now
> that the new codegen is enabled by default. (since this is a bit
> open-ended and fluid I thought a wiki page would be better than a ticket
> for now).
>
> http://ha
On Mon, Aug 27, 2012 at 11:21 PM, Simon Hengel wrote:
> Hi,
> we have several issues on Haddock's ghc-7.6 branch. I fixed some of
> those, but some still persist.
>
> Isolated, none of those issues are a big deal. But combined they are.
> Is there a way we can prevent situations like this in the
On Tue, Mar 6, 2012 at 8:54 AM, Simon Marlow wrote:
> what loop unrolling? In LLVM you mean?
>
I added loop unrolling for the thawArray# etc primops both to the NCG and
the LLVM backend.
> Eventually hoopl should buy us the ability to do some great optimisations
> at the C-- level, before we'
On Tue, Mar 6, 2012 at 7:23 AM, Simon Marlow wrote:
> However it's possible that we'll replace the mini-inliner entirely. It
> has always been a bit of a hack, and the new code generator is quite
> effective at exposing its shortcomings. Edward's CmmRewriteAssignments
> pass was supposed to be
Is this something that should be ported to master?
___
Cvs-ghc mailing list
Cvs-ghc@haskell.org
http://www.haskell.org/mailman/listinfo/cvs-ghc
On Wed, Jan 18, 2012 at 8:47 AM, Simon Marlow wrote:
> On 18/01/2012 15:35, Simon Peyton-Jones wrote:
>>
>> Ian
>>
>> Fixed... but I had to add
>>
>> {-# OPTIONS_GHC -Wwarn #-}
>>
>> to containers:Data.Sequence
>
>
> FWIW, the right thing in cases like this is to add another -Wwarn line to
> mk/va
I was going to merge the commit into the upstream containers repo but
couldn't find it here:
https://github.com/ghc/packages-containers/commits/master
On Wed, Jan 18, 2012 at 7:35 AM, Simon Peyton-Jones
wrote:
> Ian
>
> Fixed... but I had to add
>
> {-# OPTIONS_GHC -Wwarn #-}
>
> to containers:D
Repository : ssh://darcs.haskell.org//srv/darcs/ghc
On branch : ghc-7.4
http://hackage.haskell.org/trac/ghc/changeset/7dfa17d4ed8fa7604cb681e375133db4773b8910
>---
commit 7dfa17d4ed8fa7604cb681e375133db4773b8910
Author: Johan Tib
This is great.
P.S. Have someone tried to compile e.g. fibon or some other more realistic
benchmark with -funbox-strict-fields? I guess one problem might be that not
enough fields are made strict though...
On Wed, Nov 9, 2011 at 3:36 AM, Simon Marlow wrote:
> Repository : ssh://darcs.haskell.or
On Thu, Nov 3, 2011 at 8:39 AM, Thomas Schilling wrote:
> As for my personal stance on upgrading: My 10.5 laptop is a 1st-gen
> MacBook which are 32 bit only, so it doesn't make much sense to
> upgrade to 10.6. My work Mac does run 10.6 but I've only heard of
> people having problems with 10.7,
Just saw the branch name. This is in a branch. Please ignore me.
On Tue, Nov 1, 2011 at 10:32 AM, Johan Tibell wrote:
> Is this going into 7.4? Does this mean all heap objects now use 4 words
> (e.g. Int is now twice as big)?
>
>
> On Tue, Nov 1, 2011 at 10:22 AM, Geoffrey
Is this going into 7.4? Does this mean all heap objects now use 4 words
(e.g. Int is now twice as big)?
On Tue, Nov 1, 2011 at 10:22 AM, Geoffrey Mainlain wrote:
> Repository : ssh://darcs.haskell.org//srv/darcs/ghc
>
> On branch : simd
>
>
> http://hackage.haskell.org/trac/ghc/changeset/08ba8f7
On Wed, Oct 26, 2011 at 11:04 AM, Daniel Fischer <
daniel.is.fisc...@googlemail.com> wrote:
> I don't understand this. If I don't use Safe Haskell, the compiler should
> ignore all the Safe/Trustworthy/Unsafe pragmas no matter what's the
> default.
> Only if I explicitly choose to use Safe Haskell
On Wed, Oct 26, 2011 at 9:04 AM, Thomas Schilling
wrote:
> I while ago I saw a commit to Safe Haskell changing modules from
> default Unsafe to default Safe.
>
> This seems wrong to me (and Duncan agreed on IRC) -- in security the
> usual advice is to use white listing instead of black listing. T
On Sat, Oct 22, 2011 at 6:40 AM, David Peixotto wrote:
> Ok, so to do it the "quick" way would be to change the translation of the
> PopCnt primop in compiler/codeGen/CgPrimOp.hs? The change would be to first
> narrow the argument by generating code for the narrow primop before the code
> for the
Hi,
On Fri, Oct 21, 2011 at 1:34 PM, David Peixotto wrote:
> I believe that we should be narrowing the argument before calling the
> function (and in fact both gcc and llvm-gcc will narrow it before a
> call to hs_popcnt8). My question is what is the right way to do
> that in the code generator?
Repository : ssh://darcs.haskell.org//srv/darcs/testsuite
On branch : master
http://hackage.haskell.org/trac/ghc/changeset/14619423995f69a76061b5f84025188ca2fedd03
>---
commit 14619423995f69a76061b5f84025188ca2fedd03
Author: Jo
Repository : ssh://darcs.haskell.org//srv/darcs/ghc
On branch : master
http://hackage.haskell.org/trac/ghc/changeset/c579340ca8494908abdec0a50952ea81b8eaa6ab
>---
commit c579340ca8494908abdec0a50952ea81b8eaa6ab
Author: Johan Tib
Simon fixed the 32-bit issue in
https://github.com/ghc/ghc/commit/548765e28739af5479e47e05bc4e6051cd709c66
Thanks Simon!
___
Cvs-ghc mailing list
Cvs-ghc@haskell.org
http://www.haskell.org/mailman/listinfo/cvs-ghc
On Thu, Aug 18, 2011 at 11:45 PM, Simon Marlow wrote:
> It's broken on 32-bit platforms (like Johan, I validated on 64-bit and
> didn't notice the 32-bit breakage). I have a fix on the way...
I got alerted to the problem this morning (which is 32-bit only) and
had a fix that Simon was validating
Just tried on my OS X/x86_64 and it builds fine for me. Make sure you have
https://github.com/ghc/packages-ghc-prim/commit/cefc19afafe5107ff98d5205c204b190da1d497b
On Thu, Aug 18, 2011 at 4:36 PM, Johan Tibell wrote:
> It works on my machine, could it be due to different OS X versions?
&g
It works on my machine, could it be due to different OS X versions?
I'm still on Snow Leopard. The symbols are defined in ghc-prim,
perhaps you need to pull the latest version?
On Thu, Aug 18, 2011 at 4:29 PM, Manuel M T Chakravarty
wrote:
> This popCnt stuff doesn't seem to work on OS X/x86_64:
On Thu, Aug 18, 2011 at 12:43 PM, Alexander Kjeldaas
wrote:
> Unaligned word-sized loads work fine on x86, and this would be x86-64 only,
> or even Nehalem (and later) only. Or, from a cost perspective, it could
> be interesting for non-Nehalem as well, as RAM is (usually) the most
> expensive
On Thu, Aug 18, 2011 at 12:22 PM, Alexander Kjeldaas
wrote:
> The Nehalem micro-architecture has made unaligned loads very cheap, as long
> as they do not cross a cache line boundary.
> I am thinking that this makes it possible for ghc to use 40-bit pointers,
> and generally use "packed" structure
On Thu, Jul 21, 2011 at 11:20 AM, Johan Tibell wrote:
> After having spent about 8 hours trying to add a new static library as
> a dependency of ghc-prim I feel with you. I've read all the wiki
> pages, make -p:ed myself to death, tried to imitate other files, read
> throu
Hi all,
On Thu, May 12, 2011 at 8:58 AM, Ben Lippmeier wrote:
> Hi All,
> I thought I'd take a moment to mention that the GHC build system is basically
> unmaintainable by anyone except the original authors. It's clear that a
> heroic effort has been made to fit a square peg into a round hole,
On Tue, Jul 12, 2011 at 3:34 PM, Karel Gardas wrote:
> Hello,
>
> I've forked ghc/ghc repo on github.com to work on ARM port. Now I'd like to
> check it out and compile it, but I'm not able to `sync-all get' since git
> complains with `warning: remote HEAD refers to nonexistent ref, unable to
> ch
On Fri, Jul 8, 2011 at 5:10 PM, Ian Lynagh wrote:
> @@ -201,6 +214,15 @@ foreign import ccall interruptible
> deprecated, has now been removed.
>
>
> +
> +
> +
> + There is a new VECTORISE pragma, where
> + {-# VECTORISE var = exp #-}
> +
On Fri, Jun 24, 2011 at 5:42 PM, Max Bolingbroke
wrote:
> On 24 June 2011 16:09, Johan Tibell wrote:
>> Are you sure this is the case? If so we should perhaps file a bug on
>> GitHub to get that working.
>>
>> I thought --mirror essentially did a -f.
>
> Yes it
On Fri, Jun 24, 2011 at 4:46 PM, Max Bolingbroke
wrote:
> I got this error when I pushed to GHC just now:
>
> """
> Sorry, you can't push to the refs/pull/* hierarchy
> To g...@github.com:ghc/ghc.git
> ! [remote rejected] master -> master (pre-receive hook declined)
> ! [remote rejected] superco
Repository : ssh://darcs.haskell.org//srv/darcs/ghc
On branch : master
http://hackage.haskell.org/trac/ghc/changeset/e9bc0dde881a615e01f8fc5e52dd2264f163e5fd
>---
commit e9bc0dde881a615e01f8fc5e52dd2264f163e5fd
Author: Johan Tib
OK.
David, could you please the commit the last patch when you have time?
Thanks!
On Fri, Jun 17, 2011 at 1:55 PM, Simon Peyton-Jones
wrote:
> i don't think it's hour-to-hour urgent. After all Safe Hsakell isn't in yet!
>
> | -Original Message-
> | From: Joh
Note. There's only one patch left to commit:
0001-codeGen-Make-emitCopyByteArray-less-pessimistic.patch
On Fri, Jun 17, 2011 at 1:16 PM, Simon Peyton-Jones
wrote:
> fine... is David committing these # 5210 patches?
>
> | -Original Message-----
> | From: Johan Tibell
e # 5210 patches?
>
> | -Original Message-----
> | From: Johan Tibell [mailto:johan.tib...@gmail.com]
> | Sent: 17 June 2011 10:38
> | To: Simon Peyton-Jones
> | Cc: David Terei; GHC
> | Subject: Re: GHC 7.2
> |
> | Hi Simon,
> |
> | I'd like to see the last
Hi Simon,
I'd like to see the last patch
(0001-codeGen-Make-emitCopyByteArray-less-pessimistic.patch) from
http://hackage.haskell.org/trac/ghc/ticket/5210 go in. It contains
some final clean-ups for the new array copy primops I've added for
7.2.
I've just validated it.
Cheers,
Johan
___
Yes. They made it know. Ian had to kick something manually. I think it
was permissions related.
On Wed, Jun 15, 2011 at 8:05 PM, David Terei wrote:
> On 15 June 2011 03:53, Edward Z. Yang wrote:
>> Was this commit supposed to have made it to master? I don't see it, for some
>> reason...
>
> Yes.
exited with error code 1
To ti...@darcs.haskell.org:/home/darcs/ghc.git
4ed2634..ef2ac83 master -> master
On Wed, Jun 15, 2011 at 2:30 PM, Johan Tibell wrote:
> On Wed, Jun 15, 2011 at 2:24 PM, Manuel M T Chakravarty
> wrote:
>> compiler/nativeGen/X86/CodeGen.hs:1510:32:
>>
Repository : ssh://darcs.haskell.org//srv/darcs/ghc
On branch : master
http://hackage.haskell.org/trac/ghc/changeset/ef2ac839746750300dc8e96b8accaee8498298d7
>---
commit ef2ac839746750300dc8e96b8accaee8498298d7
Author: Johan Tib
estsuite
>>
>> On branch : master
>>
>> http://hackage.haskell.org/trac/ghc/changeset/01c9b2f8ece0a7f1226d0768e811666f792787bc
>>
>> >-------
>>
>> commit 01c9b2f8ece0a7f1226d0768e811666f792787bc
>>
On Wed, Jun 15, 2011 at 2:24 PM, Manuel M T Chakravarty
wrote:
> compiler/nativeGen/X86/CodeGen.hs:1510:32:
> Warning: Defined but not used: `args'
>
> compiler/nativeGen/X86/CodeGen.hs:1552:32:
> Warning: Defined but not used: `args'
>
> :
> Failing due to -Werror.
>
> make[1]: *** [compile
+-- EZY: This code has an unusually high amount of assignTemp calls, seen
+-- nowhere else in the code generator. This is mostly because these
+-- "primitive" ops result in a surprisingly large amount of code. It
+-- will likely be worthwhile to optimize what is emitted here, so that
+-- our opti
On Mon, Jun 6, 2011 at 5:17 AM, Simon Marlow wrote:
> Johan has a test that compares assembly output I think - Johan, is it in
> yet?
The test I wrote was for the memcpy primops. I can write a test for
this optimization as well as soon as the test support patch itself [1]
is in.
1. http://hackag
Repository : ssh://darcs.haskell.org//srv/darcs/testsuite
On branch : master
http://hackage.haskell.org/trac/ghc/changeset/fa85978a50435b596c10f2a5a79fb2d54ca105b3
>---
commit fa85978a50435b596c10f2a5a79fb2d54ca105b3
Author: Jo
Repository : ssh://darcs.haskell.org//srv/darcs/ghc
On branch : master
http://hackage.haskell.org/trac/ghc/changeset/18691d440f90a3dff4ef538091c886af505e5cf5
>---
commit 18691d440f90a3dff4ef538091c886af505e5cf5
Author: Johan Tib
On Thu, May 26, 2011 at 9:37 AM, Simon Peyton-Jones
wrote:
> Friends
>
> Thanks to those who responded to the message below, about improving the
> process for developing the core Haskell libraries.
> http://www.haskell.org/haskellwiki/Library_submissions/NewDraft
>
> Feedback has been broa
Duncan, didn't you add capabilities sets recently?
On Fri, May 20, 2011 at 4:11 PM, Simon Peyton-Jones
wrote:
> I’m getting this build failure on a clean “sh validate” on Windows. All the
> configure stuff has happened from scratch. Anyone got any ideas?
>
> Simon
>
>
>
> "inplace/bin/ghc-stage
Hi Simon,
On Fri, May 20, 2011 at 2:31 PM, Simon Peyton-Jones
wrote:
> But I understand you as saying "fine, let's try it and see".
Lets try and see.
> There's a balance isn't there? Changing the API of a widely used library
> imposes costs on lots of other people, and it's reasonable to take
Hi Simon,
I have re-read the entire document and I'm willing to try it out in
its current form. I'd like to use the remainder of this email to note
my remaining reservations, to clarify my thinking on these issues if
nothing else.
Motivation and momentum
==
Keeping oneself mo
On Thu, May 19, 2011 at 2:18 PM, Simon Peyton-Jones
wrote:
> No, we intended that the maintainer is never *required* to accept a change.
> To quote "the community offers opinions; the maintainer decides". If you
> think that point should be made even more strongly, can you go ahead and edit?
On Thu, May 19, 2011 at 10:35 AM, Simon Peyton-Jones
wrote:
> | > So if someone actually follows through with this as an official
> | > libraries submission (with a patch, deadline, etc.), the odds seem in
> | > favor of it.
> |
> | I'll try to see it through, although the process seems rather dau
On Sun, May 15, 2011 at 2:12 PM, Edward Z. Yang wrote:
> I'm getting some mysterious DPH linking error when I am attempting a validate:
>
> http://hpaste.org/46695/dph_dynamic_error
I saw the same problem on a non-validate build.
I rm -rf libraries/dph :)
___
On Thu, May 12, 2011 at 2:12 PM, Max Bolingbroke
wrote:
> If we outlawed them now we'd have to take an annoying one-time hit
> removing all the (tons) of existing tabs, generating lots of merge
> conflicts on all GHC branches for little immediate gain :-(
>
> So while I share your sentiment, I don
Hi Ben,
On Thu, May 12, 2011 at 1:10 PM, Ben Lippmeier wrote:
> Perhaps "sh validate" should also run "./sync-all pull" and "./sync-all get"
> first? Can anyone think of a reason not to? This has also bitten me in the
> past.
That would make it impossible to validate anything but HEAD, wouldn'
Hi,
On Thu, Apr 14, 2011 at 5:33 PM, Simon Peyton-Jones
wrote:
> Oh *bother*. I have no clue how this happened but I appear to have merged
> ghc-generics into the HEAD. I certainly did not intend to do so.
> ghc-generics is supposed to be a separate branch, and to stay that way till
> it wo
On Sun, Apr 10, 2011 at 3:24 PM, Edward Z. Yang wrote:
> For me, at least, Github is a convenient way to share commits between machines
> that I do development on, without needing to spend X megabytes for the whole
> repository history (since Github can share objects across forked repositories:
>
On Tue, Apr 5, 2011 at 1:38 AM, Ian Lynagh wrote:
> What's the best way to do that, given people already have the other repo
> checked out? i.e. can we do better than asking everyone to
> rm -rf libraries/binary
> ./sync-all get
Yes. In this case I think that's the best way.
Johan
___
On Mon, Apr 4, 2011 at 6:26 PM, Lennart Kolmodin wrote:
> It's not important to me that it's in my account though, as binary is a
> community effort. Maybe it should be based in some kind of Haskell Community
> account? If not, I'll keep it.
The current location works for me. If you want we could
On Sat, Apr 2, 2011 at 3:45 PM, Ian Lynagh wrote:
> The binary git repo is converted from a git mirror of the upstream darcs
> repo, rather than from GHC's darcs repo, and upstream haven't applied
> this patch:
>
> Tue Nov 2 18:58:52 GMT 2010 Ian Lynagh
> * Avoid "-fglasgow-exts depreca
On Sun, Apr 3, 2011 at 1:52 AM, Ian Lynagh wrote:
>
> There's now a github mirror here:
> https://github.com/ghc/ghc
>
> I'll add mirrors of the other repos soon.
Nice!
___
Cvs-ghc mailing list
Cvs-ghc@haskell.org
http://www.haskell.org/mailman/list
On Fri, Mar 4, 2011 at 10:42 AM, Ian Lynagh wrote:
> We've made a list of which repos we suggest should be converted, and
> which should be mirrored, here:
> http://hackage.haskell.org/trac/ghc/wiki/DarcsConversion#Planforlibraries
>
> Can you please let us know if you think any of the repos ha
1 - 100 of 133 matches
Mail list logo
