Bryan O'Sullivan wrote:
> On Mon, Oct 22, 2012 at 4:14 PM, Simon Peyton-Jones
> wrote:
>
>
>> Do you mean âsilently and foreverâ?
>>
>
> I think that's what I mean, yes.
>
> As Johan notes, many of us run our continuous builds of our packages with
> -Wall -Werror in order to keep them as clean
Ashley Yakeley wrote:
> On 22.10.2012 11:05, Johan Tibell 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 o
Repository : ssh://darcs.haskell.org//srv/darcs/ghc
On branch : master
http://hackage.haskell.org/trac/ghc/changeset/5cff4fb0a50697a04eaae4e3eceb19913ad92811
>---
commit 5cff4fb0a50697a04eaae4e3eceb19913ad92811
Author: Ro
14f... 5cff4fb...
Author: Roman Leshchinskiy
Date: Mon Oct 8 23:37:14 2012 +0100
Merge ../ghc
compiler/codeGen/CgPrimOp.hs | 35 +++
compiler/codeGen/StgCmmPrim.hs | 39 ++-
2 files changed, 41 insertions(+), 33 deleti
Repository : ssh://darcs.haskell.org//srv/darcs/ghc
On branch : master
http://hackage.haskell.org/trac/ghc/changeset/140648364f1312088876c5f94551ba3a955d083d
>---
commit 140648364f1312088876c5f94551ba3a955d083d
Author: Ro
> Any insight why this is happening is welcome.
>
> Cheers,
>
> Gabor
>
> On 1/12/12, Simon Marlow wrote:
>> On 11/01/2012 21:40, Roman Leshchinskiy wrote:
>>> On 11/01/2012, at 19:37, Gabor Greif wrote:
>>>
>>>> libraries/dph/dph-lifted-vseg/Da
On 11/01/2012, at 19:37, Gabor Greif wrote:
> libraries/dph/dph-lifted-vseg/Data/Array/Parallel/PArray/PData/Base.hs:20:8:
>Could not find module `SpecConstr'
>Use -v to see a list of the files searched for.
> make[1]: ***
> [libraries/dph/dph-lifted-vseg/dist-install/build/.depend-v.hask
On 10/01/2012, at 20:28, Gabor Greif wrote:
> My suspicion is that ghc-cabal is not prepared to see "includes:" or
> some other weirdness with "Include-Dirs:" or "Install-Includes:".
>From bytestring.cabal in the GHC tree:
include-dirs: include
includes: fpstring.h
install-in
When trying to build GHC (be it the 7.2 branch, the 7.4 branch or the
HEAD) on Windows using GHC 7.2.2, I end up with the following bits in
config.mk after configure:
WhatGccIsCalled = c:/ghc/head/inplace/mingw/bin/gcc.exe
GccVersion = 4.5.2
GccLT34 = NO
GccLT46 = YES
CC
I've noticed that -dverbose-core2core now (in 7.2) just prints "Simplifier"
before each simplifier phase where it used to print something like "Simplifier
Phase 1 [main]" or "Simplifier Phase 0 [post-liberate-case]". This was
tremendously useful and now I never know where I am when looking at Co
On 28/06/2011, at 13:20, Dan Knapp wrote:
> The other issue is that cpp, whether the llvm-gcc version or the clang
> version, does not work for us. Only gcc cpp fills our needs, and
> essentially only by the coincidence that it allows the
> technically-invalid double-tick syntax that is used in T
Manuel M T Chakravarty wrote:
> Roman Leshchinskiy:
>
>> Simon Marlow wrote:
>>
>>>
>>> No, it doesn't work like that because we wouldn't get enough
>>> parallelism. Dependencies are tracked at the module level, so the
>>> dependenc
Simon Marlow wrote:
>
> No, it doesn't work like that because we wouldn't get enough
> parallelism. Dependencies are tracked at the module level, so the
> dependency graph that make sees contains all modules of all libraries,
> including GHC itself. The Build-depends line is used to ensure that w
Johan Tibell wrote:
>
> It's not clear when the "deadline for discussion" should be used. Does
> it apply to any change or only public API changes? Does it apply even if
> it's the maintainer that making the change? Having to spent two weeks
> (even though most of the time is spent waiting) to make
On 15/05/2011, at 13:22, Ben Lippmeier wrote:
> Urgh. That's the build race I thought I had fixed. It happens because the DPH
> vectoriser needs dph-prim-seq to be compiled first before it can do its
> desugaring.
Why is there a race? Packages which contain vectorised modules depend on
dph-pri
Simon Marlow wrote:
>
> I'm not sure exactly what it means to rebase two branches "in sync". I
> know that if you rebase a branch and the target of the rebase already has
> (some of) the patches that you are rebasing, then git will drop them
> during the rebase.
Ah, that's good to know. Thanks! S
On 09/05/2011, at 12:34, Manuel M T Chakravarty wrote:
> Simon Marlow:
>>
>> - you develop in your working tree and commit patches there. At
>> this point it's completely safe to rebase - the patches are only
>> in one place.
>>
>> - you pull the patches into the validate tree (you just rebas
Ben Lippmeier wrote:
>
> Another idea would be to add some primops like the following:
>
>
> noopInt# :: Int# -> State# s -> State# s
> noopFloat# :: Float# -> State# s -> State# s
> ...
Have a look at GHC.Prim.touch#. Note that it's special and can be
instantiated with unboxed types, too.
Ro
On 17/02/2011, at 00:33, Adam Megacz wrote:
> Max Bolingbroke writes:
>>> Hrm, isn't it bad for two Var's with different fields to have the same
>>> uniq? Because if they have the same uniq, they will be Eq-equal.
>>
>> Just because two vars are eq-equal does not mean that they refer to
>> the
On 16/02/2011, at 21:09, Adam Megacz wrote:
> GHC's PredTy construct doesn't seem to correspond neatly to any specific
> part of System FC. However, there is a comment in the source code near
> it indicating that "It can be expanded into its representation".
>
> Is there a particular point in th
Johan Tibell wrote:
> On Tue, Feb 1, 2011 at 4:24 PM, Roman Leshchinskiy
> wrote:
>
>> Johan Tibell wrote:
>>
>>>
>>> Does cloneArray# really have to take and return a `State# s`?
>>>
>>
>> Oops, no, it doesn't. This was purely a ca
Johan Tibell wrote:
>
> Something struck me today. Look at the type signature for cloneArray#
>
>
> cloneArray# :: Array# a -> Int# -> Int# -> State# s -> (# State# s,
> Array# a #)
>
>
> Does cloneArray# really have to take and return a `State# s`?
Oops, no, it doesn't. This was purely a case o
Wed Jan 26 15:18:43 PST 2011 Roman Leshchinskiy
* Fix vectorisation of recursive types
M ./compiler/ghc.cabal.in -2
M ./compiler/vectorise/Vectorise.hs -5 +2
M ./compiler/vectorise/Vectorise/Builtins/Base.hs +2
M ./compiler/vectorise/Vectorise/Builtins/Initialise.hs -11 +8
Simon Marlow wrote:
>
> No - as soon as the thread enters foreign code via a safe foreign call,
> GC can happen at any time.
Ah, ok. Thanks for setting me straight!
Roman
___
Cvs-ghc mailing list
Cvs-ghc@haskell.org
http://www.haskell.org/mailman/li
Simon Peyton-Jones wrote:
>
> | AFAIK, the GC never runs during foreign calls. This, combine with the
> fact that GHC can | pass ByteArray# directly to FFI calls, should make
> memcpy safe even for unpinned | byte arrays. At least that's how I
> understand it.
>
> Unless I am much mistaken, GC
Johan Tibell wrote:
>
> OK. So we can implement copyByteArray# by FFI importing memcpy and
> using the automatic conversion of ByteArray#s into pointers in the FFI. For
> MutableByteArray#s we need to use an unsafeCoerce# as well.
No. Both ByteArray# and MutableByteArray# can be passed to FFI call
Simon Marlow wrote:
>
> I don't think Cabal supports .cmm files, so if you went that route it
> would be limited to being a GHC boot package, like integer-gmp.
I was thinking about ghc-prim.
Roman
___
Cvs-ghc mailing list
Cvs-ghc@haskell.org
http://
Daniel Peebles wrote:
> On Tue, Jan 25, 2011 at 5:22 PM, Roman Leshchinskiy
>>
>> Hmm, come to think of it, could they perhaps be written in Cmm (calling
>> memcpy etc. internally) and imported using the (rather obscure) "prim"
>> calling convention?
>>
On 25/01/2011, at 22:05, Daniel Peebles wrote:
> Roman: I'm thinking that even in the absence of GC during foreign calls, it
> still seems worthwhile to provide the plain copying primitives, if only to
> save "user" code from having to know a) the structure of a (Byte)Array# and
> where the "da
On 25/01/2011, at 21:50, Johan Tibell wrote:
> On Tue, Jan 25, 2011 at 10:30 PM, Roman Leshchinskiy
> wrote:
>> thawArray# (which creates a mutable copy), update the element, then
>> unsafeFreeze#. I thought that's what you wanted (modulo names). In theory,
>>
On 25/01/2011, at 20:57, Johan Tibell wrote:
> On Tue, Jan 25, 2011 at 9:47 PM, Roman Leshchinskiy
> wrote:
>> On 25/01/2011, at 20:26, Johan Tibell wrote:
>> AFAIK, the GC never runs during foreign calls. This, combine with the fact
>> that GHC can pass ByteArra
On 25/01/2011, at 20:26, Johan Tibell wrote:
> On Tue, Jan 25, 2011 at 6:35 PM, Roman Leshchinskiy
> wrote:
>> Daniel Peebles wrote:
>>>
>>> Johan Tibell and I have been working on some new primops for GHC that
>>> would allow people to use fast optimized
Daniel Peebles wrote:
>
> Johan Tibell and I have been working on some new primops for GHC that
> would allow people to use fast optimized memcpys on unpinned memory.
Why not just use memcpy?
> The use
> cases I can think of would be in the vector package (possibly the New
> stuff in there, but a
Manuel M T Chakravarty wrote:
> Roman Leshchinskiy:
>
>> Alternatively, should we make -fdph-* static?
>>
>
> How would that help our problem?
It wouldn't. But at least we wouldn't have flags that are silently ignored.
Roman
_
Manuel M T Chakravarty wrote:
> Roman Leshchinskiy:
>
>> Manuel M T Chakravarty wrote:
>>
>>>
>>> I would like that, too. (In fact, it is what I implemented at
>>> first.) Unfortunately, it doesn't work. Language options are dynamic
>>
Manuel M T Chakravarty wrote:
> Roman Leshchinskiy:
>
>> Do you mean that GHC now assumes -fdph-par even if DPH isn't used? That
>> doesn't seem right to me. I know we said that it should be the default
>> but I assumed the defaulting would only happen for modu
Manuel M T Chakravarty wrote:
>
> The --dph-this shouldn't be there in the configure options, but it needs
> to be passed to this invocation to GHC (that it isn't passed is actually
> the reason for the error). Why? If DPH is installed, -fdph-par is now
> the default. Unfortunately, during the b
Simon Marlow wrote:
> On 20/01/2011 08:18, Roman Leshchinskiy wrote:
>
>> and it should be using the stage2 compiler since stage1 can't compile
>> DPH anyway.
>>
>
> Not in this case - it's configuring the ghc-prim package, which is
> compiled with stage
On 20/01/2011, at 06:42, Manuel M T Chakravarty wrote:
> After some changes to GHC's handling of DPH packages, I'm currently fighting
> with the build system. In particular, I'm getting
>
>> "inplace/bin/ghc-cabal" configure
>> --with-ghc="/Users/chak/Code/ghc-test/inplace/bin/ghc-stage1"
>>
Simon Marlow wrote:
> Tue Jan 18 14:18:34 PST 2011 Edward Z. Yang
> * Fix documentation bug: newArray# accepts word count, not byte count.
Shouldn't this be "element count"?
Roman
___
Cvs-ghc mailing list
Cvs-ghc@haskell.org
http://www.haskell.org
Building the current head fails on my machine (OS X 10.6.6) with the message
below. I'm not sure where x86_64 is coming from; it should all be i386. The
output of configure is:
Building GHC version : 7.1.20110117
Build platform: i386-apple-darwin
Host platform : i386-a
On 12 Jan 2011, at 23:31, "Edward Z. Yang" wrote:
> Excerpts from Roman Leshchinskiy's message of Wed Jan 12 18:20:25 -0500 2011:
>> How would we get the current functionality of darcs-all pull? Is it even
>> possible?
>
> Here is the rebase-y workflow.
Thank you making things clearer!
>>
>
On 12/01/2011, at 22:22, Iavor Diatchki wrote:
> When you issue the command "git submodule update", you are telling git to
> advance the sub-module repo to the "expected version" (i.e., where the
> pointer points to). The reason this does not happen automatically is that
> you might have also
On 12/01/2011, at 09:22, Simon Marlow wrote:
> On 11/01/2011 23:11, Roman Leshchinskiy wrote:
>>
>> A quick look at the docs seems to indicate that we'd need to do
>>
>> git pull
>> git submodule update
>>
>> which doesn't loo
On 11/01/2011, at 22:20, Simon Marlow wrote:
> On 11/01/11 21:57, Roman Leshchinskiy wrote:
>> IMO, darcs-all works pretty well. I don't think I ever really had
>> problems with missing library patches.
>
> I often see problems where someone has done 'darcs pull&#x
On 11/01/2011, at 21:41, Iavor Diatchki wrote:
> If GHC and the libraries on which it depends were in git (migrated, or
> mirrored), then we could use git sub-modules to track the dependencies
> between changes to GHC and changes to the libraries.
>
> Roughly, the workflow would be like th
On 11/01/2011, at 16:14, Tony Finch wrote:
> On Mon, 10 Jan 2011, Roman Leshchinskiy wrote:
>>
>> It also seems to make finding buggy patches rather hard.
>
> Have a look at `git bisect`.
I'm aware of git bisect. It doesn't do what I want. I usually have a pret
On 10/01/2011, at 13:27, Simon Marlow wrote:
> On 10/01/2011 13:02, Max Bolingbroke wrote:
>> However, I remember the last time this came up there were some issues
>> that might make migration painful. From the top of my head:
>>
>> 1) Some people expressed concern that they would have to use two
Should be fixed now.
Roman
___
Cvs-ghc mailing list
Cvs-ghc@haskell.org
http://www.haskell.org/mailman/listinfo/cvs-ghc
Sat Dec 18 15:48:38 PST 2010 Roman Leshchinskiy
* vectoriser: don't always pass superclass dictionaries to PA dfuns
This is just a guess at how this should work.
M ./compiler/vectorise/Vectorise/Utils/PADict.hs -14 +38
View patch online:
http://darcs.haskell.org/cgi-bin/darcswe
Sat Dec 18 04:53:50 PST 2010 Roman Leshchinskiy
* vectoriser: delete dead code
M ./compiler/vectorise/Vectorise/Utils/PADict.hs -20 +1
View patch online:
http://darcs.haskell.org/cgi-bin/darcsweb.cgi?r=ghc;a=darcs_commitdiff;h=20101218125350-b2b0a
Sat Dec 18 03:49:53 PST 2010 Roman Leshchinskiy
* vectoriser: adapt to new superclass story part I (dictionary construction)
M ./compiler/vectorise/Vectorise/Builtins/Base.hs +1
M ./compiler/vectorise/Vectorise/Builtins/Initialise.hs -2 +5
M ./compiler/vectorise/Vectorise/Utils.hs
On 03/12/2010, at 21:01, Ian Lynagh wrote:
> Fri Dec 3 12:15:58 PST 2010 Ian Lynagh
> * Tell gcc to support back to OS X 10.5
This breaks the build on 10.6 for me. It fails with:
"/usr/bin/gcc" -o utils/unlit/dist/build/tmp/unlit -march=i686 -m32 -isysroot
/Developer/SDKs/MacOSX10.5.sdk -m
Sat Nov 27 04:50:25 PST 2010 Roman Leshchinskiy
* Inherit the ForceSpecConstr flag in non-recursive nested bindings
This makes sure that join points are fully specialised in loops which are
marked as ForceSpecConstr.
M ./compiler/specialise/SpecConstr.lhs -5 +7
View patch online
Sat Nov 27 04:35:28 PST 2010 Roman Leshchinskiy
* Document -ddump-rule-firings and -ddump-rule-rewrites
M ./docs/users_guide/debugging.xml +22
M ./docs/users_guide/flags.xml +12
M ./docs/users_guide/glasgow_exts.xml -2 +3
View patch online:
http://darcs.haskell.org/cgi-bin
Sat Nov 27 04:20:22 PST 2010 Roman Leshchinskiy
* New flag -dddump-rule-rewrites
Now, -ddump-rule-firings only shows the names of the rules that fired (it
would
show "before" and "after" with -dverbose-core2core previously) and
-ddump-rule-rewrites always sh
Thu Nov 18 13:28:39 PST 2010 Roman Leshchinskiy
* ForceSpecConstr now forces specialisation even for arguments which aren't
scrutinised
M ./compiler/specialise/SpecConstr.lhs -24 +31
View patch online:
http://darcs.haskell.org/cgi-bin/darcsweb.cgi?r=ghc;a=darcs_commitd
On 17/11/2010, at 17:32, Simon Peyton-Jones wrote:
> Why has the behavior changed? Because it depends whether eta-expansion
> happens before float-out. Now it does. I could change that back. The eta
> expander knows that (sc_sel d) is cheap, so it turns it into this
> exp = /\a. \d.\x. let
Wed Nov 10 13:02:58 PST 2010 Roman Leshchinskiy
* Add upstream URLs for vector and primitive
M ./packages -2 +2
View patch online:
http://darcs.haskell.org/cgi-bin/darcsweb.cgi?r=ghc;a=darcs_commitdiff;h=20101110210258-b2b0a-190b4e19b7d3fdb3f4555cfc8b642b56380b60b7.gz
-Original Message-----
> | From: Roman Leshchinskiy [mailto:r...@cse.unsw.edu.au]
> | Sent: 20 October 2010 09:34
> | To: Simon Peyton-Jones
> | Cc: Ian Lynagh; cvs-ghc@haskell.org
> | Subject: Re: [GHC] #4419: dph tests fail with panic
> |
> | If we generate a group of mutua
Should we just give up and use pragmas to drive SpecConstr? Annotations seem to
be more trouble than they are worth.
Roman
On 22 Oct 2010, at 15:36, Simon Peyton-Jones wrote:
> Ian
>
>
>
> When building a profiled compiler with
>
>
>
> GhcProfiled = YES
>
> GhcLibWays = v p
>
>
>
On 20/10/2010, at 14:20, Simon Peyton-Jones wrote:
> Could you add comments to the setUnfolingLazily thing to explain?
Will do.
Roman
___
Cvs-ghc mailing list
Cvs-ghc@haskell.org
http://www.haskell.org/mailman/listinfo/cvs-ghc
On 20 Oct 2010, at 12:11, Simon Peyton-Jones wrote:
> | > But why do the Ids need an unfolding at all? The simplifier will add
> one for itself, as
> | it does with ordinary Haskell code
> |
> | Because we want to make some of the bindings we generate INLINE and IIUC,
> the way
> | to do
On 20 Oct 2010, at 12:00, Simon Peyton-Jones wrote:
> | I see. I fear we can't do this in the vectoriser because we don't know
> which
> | loopbreaker the simplifier is going to choose.
>
> But why do the Ids need an unfolding at all? The simplifier will add one for
> itself, as it does wit
On 20 Oct 2010, at 11:50, Simon Peyton-Jones wrote:
> | But don't references to the other Ids in those RHS have to have the right
> unfolding?
> | That is, in
> |
> | f x = ... g y ...
> | g x = ... f y ...
> |
> | shouldn't the f in g's RHS and the g in f's RHS have the right unfolding
On 20 Oct 2010, at 10:06, Simon Peyton-Jones wrote:
> What I do in the simplifier is to put the rec group in a good order, then
> work top-to-bottom, simplifying each RHS, adding its unfolding, and then on
> to the next. No need for loops.
But don't references to the other Ids in those RHS h
If we generate a group of mutually recursive bindings, of which some have an
unfolding, do we have any choice but to use setIdUnfoldingLazily? Would it
perhaps make sense to be lazy by default and have setIdUnfoldingStrictly for
those cases where it matters?
Roman
On 20 Oct 2010, at 07:57, Sim
Sun Jun 6 22:29:03 PDT 2010 Roman Leshchinskiy
* Track changes to DPH libs
M ./compiler/vectorise/VectBuiltIn.hs -11 +12
View patch online:
http://darcs.haskell.org/cgi-bin/darcsweb.cgi?r=ghc;a=darcs_commitdiff;h=20100607052903-b2b0a-0d14b066ad944f27829cc867afe5e51fb968a552.gz
Sun Jun 6 18:26:42 PDT 2010 Roman Leshchinskiy
* Track changes to DPH libs
M ./compiler/vectorise/VectBuiltIn.hs -1 +6
View patch online:
http://darcs.haskell.org/cgi-bin/darcsweb.cgi?r=ghc;a=darcs_commitdiff;h=20100607012642-b2b0a-b736248321920f6186c9704f11d2e8052713fc02.gz
Thu Jun 3 17:57:28 PDT 2010 Roman Leshchinskiy
* Track DPH library changes
M ./compiler/vectorise/VectBuiltIn.hs +2
View patch online:
http://darcs.haskell.org/cgi-bin/darcsweb.cgi?r=ghc;a=darcs_commitdiff;h=20100604005728-b2b0a-638f7b9cb18bf180cc7f2cfc1239bf8e9ae027cf.gz
Mon May 31 21:56:30 PDT 2010 Roman Leshchinskiy
* Vectoriser: only treat a function as scalar if it actually computes
something
M ./compiler/vectorise/Vectorise.hs -1 +10
View patch online:
http://darcs.haskell.org/cgi-bin/darcsweb.cgi?r=ghc;a=darcs_commitdiff;h=20100601045630-b2b0a
dk on my disk suggests that you'd have to use
that if you want compatibility with 10.5. Presumably, the flag wouldn't be
needed in that case, although someone with access to both systems would have to
try that out.
Roman
> On 20 May 2010 17:57, Ian Lynagh wrote:
>> O
On 21/05/2010, at 00:17, Ian Lynagh wrote:
> On Thu, May 20, 2010 at 11:08:45PM +1000, Roman Leshchinskiy wrote:
>> On 20/05/2010, at 23:00, Ian Lynagh wrote:
>>
>>> On Thu, May 20, 2010 at 02:26:08PM +1000, Roman Leshchinskiy wrote:
>>>> This happens
On 20/05/2010, at 23:00, Ian Lynagh wrote:
> On Thu, May 20, 2010 at 02:26:08PM +1000, Roman Leshchinskiy wrote:
>> This happens on both 10.5 and 10.6. It dies with:
>>
>> ld: symbol dyld_stub_binding_helper not defined (usually in
>> crt1.o/dylib1.o/bundle1.o)
>
This happens on both 10.5 and 10.6. It dies with:
"inplace/bin/ghc-stage1" -package-name rts -shared -dynamic -dynload deploy
-no-auto-link-packages `cat rts/libs.depend` rts/dist/build/Adjustor.dyn_o
rts/dist/build/Arena.dyn_o rts/dist/build/Capability.dyn_o
rts/dist/build/ClosureFlags.dyn_o r
On 15/04/2010, at 01:14, Ian Lynagh wrote:
> On Wed, Apr 14, 2010 at 07:28:02PM +1000, Roman Leshchinskiy wrote:
>>
>> FWIW, Solaris sh supports test ... -ot ... but not [ ... -ot ... ].
>
> On sparky.ce.chalmers.se neither test nor [] supports -ot in sh. In bash
>
On 14/04/2010, at 23:23, Johan Tibell wrote:
> Hi!
>
> I ran into a piece of core today that I don't understand:
>
> (let {
> y_Xwv [Dmd=Just L] :: Int#
>
> y_Xwv = -# (+# a_s2gvj 1) a_s2gvj } in
> Data.Text.Builder.Buffer
> @ s1_a2gph
> ww6_s2gx7
> ww7_s2gx8
> ww8_s2gx9
> (+# ww9
On 12/04/2010, at 16:30, Matthias Kilian wrote:
> On Mon, Apr 12, 2010 at 11:47:26AM +1000, Ben Lippmeier wrote:
>> The trouble is that the boot scripts use GNU specific features.
>> I was the one that changed it to bash because I was tired of the
>> build breaking on Solaris. I think the original
With -rtsopts, GHC compiles an additional C file using mkExtraCObj. This
function calls runCc but doesn't pass machdepCCOpts to it, producing a 64 bit
file on Snow Leopard instead of 32 bit one which breaks linking. The fix is
probably just to add machdepCCOpts to the gcc call but I can't test t
boot-pkgs contains this line:
tar -zxf ../../$tarball
This fails at least on Solaris where we want gtar. We probably want to look for
gnutar, gtar and then for tar, just like in configure.
Roman
___
Cvs-ghc mailing list
Cvs-ghc@haske
the overflow checks altogether but I haven't had a chance to work on that yet.
Roman
On 28/03/2010, at 17:04, Roman Leshchinskiy wrote:
> Following the discussion in haskell-cafe, I tried changing the order of tests
> in the Integral methods from:
>
>a
Following the discussion in haskell-cafe, I tried changing the order of tests
in the Integral methods from:
a `rem` b
| b == 0 = divZeroError
| a == minBound && b == (-1) = overflowError
| otherwise = a `remInt` b
to
a `rem` b
|
On 28/03/2010, at 09:23, Ian Lynagh wrote:
> Are the dph tests expected to take large amounts of RAM while compiling?
I suspect so. The problem is that they inline almost everything, which results
in very large intermediate code. We haven't found a way to avoid this so far.
Roman
Validating on my Mac produces 150 failures. The problem is this:
+ghc: RTS options are disabled. Link with -rtsopts to enable them.
This is with up-to-date (as of yesterday) repos and no custom validate.mk.
Roman
___
Cvs-ghc mailing list
Cvs-ghc@hask
On 17/03/2010, at 23:40, Matthias Kilian wrote:
> On Wed, Mar 17, 2010 at 11:25:30AM +1100, Roman Leshchinskiy wrote:
>>> I've a patch which removes DPH from ghc-head, and a merge which
>>> removes it from ghc-6.12, and I could successfully build
>>
>> Unfor
On 17/03/2010, at 12:58, Ian Lynagh wrote:
> On Wed, Mar 17, 2010 at 11:25:30AM +1100, Roman Leshchinskiy wrote:
>> On 17/03/2010, at 09:01, Matthias Kilian wrote:
>>
>>> No, sorry. If I'm seeing unnecessary requirements and all those
>>> little hurdles
On 17/03/2010, at 09:01, Matthias Kilian wrote:
> No, sorry. If I'm seeing unnecessary requirements and all those
> little hurdles that get in your way trying to get GHC work on a
> non-first-tier platform, I get really upset. For sure I appreciate
> your work on the new build system, but what els
On 16/03/2010, at 06:03, Matthias Kilian wrote:
> On Sun, Mar 14, 2010 at 02:54:02PM -0700, Don Stewart wrote:
>> kili:
>>> ghc-stage2: panic! (the 'impossible' happened)
>>> (GHC version 6.13.20100314 for x86_64-unknown-openbsd):
>>>Cant do annotations without GHCi
>>>{59:20-31}ghc-6
Sun Feb 14 19:01:03 PST 2010 Roman Leshchinskiy
* Add comments about the ForceSpecConstr mechanism
M ./compiler/specialise/SpecConstr.lhs +39
View patch online:
http://darcs.haskell.org/ghc/_darcs/patches/20100215030103-b2b0a-541cca24842f2af43612e026a5204a4e68a9101e.gz
Sun Feb 14 18:53:08 PST 2010 Roman Leshchinskiy
* Spot ForceSpecConstr arguments in polymorphic loops
M ./compiler/specialise/SpecConstr.lhs -1 +1
View patch online:
http://darcs.haskell.org/ghc/_darcs/patches/20100215025308-b2b0a-b46dbb1f80702311feaf03f3de2b43fd796cfbb2.gz
On 04/12/2009, at 19:20, Simon Peyton-Jones wrote:
> I'm fine with this, but please add
> Note [ForceSpecConstr]
> ~~
>
> to Specialise, with at least the text in your commit message, and preferably
> some description of why this is a good thing to do.
I'll
Thu Dec 3 18:42:59 PST 2009 Roman Leshchinskiy
* Fix loading of annotations
Ignore-this: 5750856feecbf9c6aeebfec012b1a1fd
The problem was that we collected all annotations we knew about once when the
simplifier started and threaded them through the CoreM monad. If new interface
Wed Dec 2 22:54:55 PST 2009 Roman Leshchinskiy
* Add new ForceSpecConstr annotation
Ignore-this: ca5327f85d9d40c78d95e8bfe3e7fab1
Annotating a type with {-# ANN type T ForceSpecConstr #-} makes SpecConstr
ignore -fspec-constr-threshold and -fspec-constr-count for recursive functions
Wed Dec 2 19:14:52 PST 2009 Roman Leshchinskiy
* Generate INLINE pragmas for PA methods
Ignore-this: 3435044aec2737ba58d269aeff915fbd
M ./compiler/basicTypes/BasicTypes.lhs -2 +5
M ./compiler/vectorise/VectType.hs -1 +2
View patch online:
http://darcs.haskell.org/ghc/_darcs
Wed Nov 25 03:59:53 PST 2009 Roman Leshchinskiy
* Pass --no-user-package-conf to ghc-pkg in bindisttest
M ./bindisttest/Makefile -1 +2
View patch online:
http://darcs.haskell.org/ghc/_darcs/patches/20091125115953-b2b0a-f1e51de49cf1e8f7d8e060a4ac53877ece895e17.gz
Ian, Simon,
today I got the following error from validate:
/Users/rl/projects/ndp/ghc-test/bindisttest/"install dir"/bin/ghc-pkg check
There are problems in package vector-0.5:
dependency "base-4.2.0.0-inplace" doesn't exist
dependency "ghc-6.13.20091124-inplace" doesn't exist
...
The proble
Wed Nov 11 23:04:55 PST 2009 Roman Leshchinskiy
* Remove dead code
Ignore-this: d30b668cb3c396fe21e5e4cd9b8be151
M ./compiler/vectorise/VectBuiltIn.hs -3
M ./compiler/vectorise/VectUtils.hs -5 +1
View patch online:
http://darcs.haskell.org/ghc/_darcs/patches/20091112070455-b2b0a
On 19/11/2009, at 23:57, Ian Lynagh wrote:
> On Thu, Nov 19, 2009 at 09:58:17PM +1100, Roman Leshchinskiy wrote:
>> cd a/b/c/ && /usr/bin/tar --force-local -jxf
>> ../../../../bindistprep/ghc-6.13.20091119-i386-apple-darwin.tar.bz2
>> tar: Option --force-local is not
Thu Nov 19 02:26:39 PST 2009 Roman Leshchinskiy
* Fix splitAppTys
Ignore-this: e669950c7d151c8a67910cd4bbac9cd6
M ./compiler/types/Type.lhs -2 +2
View patch online:
http://darcs.haskell.org/ghc/_darcs/patches/20091119102639-b2b0a-ac72608f4bbda09992199e966c75150c88dd25c6.gz
cd a/b/c/ && /usr/bin/tar --force-local -jxf
../../../../bindistprep/ghc-6.13.20091119-i386-apple-darwin.tar.bz2
tar: Option --force-local is not supported
Usage:
List:tar -tf
Extract: tar -xf
Create: tar -cf [filenames...]
Help:tar --help
make: *** [all] Error 1
_
1 - 100 of 538 matches
Mail list logo
