Build description = HEAD on i386-unknown-linux (cam-02-unx)
Build location= /playpen/simonmar/nightly/HEAD
Build config file = /home/simonmar/nightly/site/msrc/conf-HEAD-cam-02-unx
Nightly build started on cam-02-unx at Tue Jan 25 18:00:02 GMT 2011.
checking out new source tree
pgj-freebsd-amd64-stable (amd64 FreeBSD STABLE), build 141
Build succeeded
Details:
http://darcs.haskell.org/ghcBuilder/builders/pgj-freebsd-amd64-stable/141.html
darcs checkout| Success
create mk/build.mk| Success
get subrepos | Success
repo versions
pgj-freebsd-i386-stable (x86 FreeBSD STABLE), build 124
Build succeeded
Details:
http://darcs.haskell.org/ghcBuilder/builders/pgj-freebsd-i386-stable/124.html
darcs checkout| Success
create mk/build.mk| Success
get subrepos | Success
repo versions | S
Build description = STABLE on i386-unknown-linux (cam-02-unx)
Build location= /playpen/simonmar/nightly/STABLE
Build config file = /home/simonmar/nightly/site/msrc/conf-STABLE-cam-02-unx
Nightly build started on cam-02-unx at Tue Jan 25 18:10:02 GMT 2011.
checking out new source tree
pgj2 (amd64 FreeBSD HEAD), build 259
Build succeeded
Details: http://darcs.haskell.org/ghcBuilder/builders/pgj2/259.html
darcs checkout| Success
create mk/build.mk| Success
get subrepos | Success
repo versions | Success
setting version date | Succ
simonmar-win32-head (x86 Windows HEAD), build 226
Build succeeded
Details:
http://darcs.haskell.org/ghcBuilder/builders/simonmar-win32-head/226.html
darcs checkout| Success
create mk/build.mk| Success
get subrepos | Success
repo versions | Success
set
simonmar-win32-stable (x86 Windows STABLE), build 161
Build succeeded
Details:
http://darcs.haskell.org/ghcBuilder/builders/simonmar-win32-stable/161.html
darcs checkout| Success
create mk/build.mk| Success
get subrepos | Success
repo versions | Succe
pgj (x86 FreeBSD HEAD), build 261
Build succeeded
Details: http://darcs.haskell.org/ghcBuilder/builders/pgj/261.html
darcs checkout| Success
create mk/build.mk| Success
get subrepos | Success
repo versions | Success
setting version date | Success
tn23 (x86 OSX HEAD), build 252
Build succeeded
Details: http://darcs.haskell.org/ghcBuilder/builders/tn23/252.html
darcs checkout| Success
create mk/build.mk| Success
get subrepos | Success
repo versions | Success
setting version date | Success
bo
Build description = HEAD on x86_64-unknown-linux (cam-04-unx)
Build location= /64playpen/simonmar/nightly/HEAD-cam-04-unx
Build config file = /home/simonmar/nightly/site/msrc/conf-HEAD-cam-04-unx
Nightly build started on cam-04-unx at Tue Jan 25 18:00:01 GMT 2011.
checking out new source
Build description = STABLE on x86_64-unknown-linux (cam-04-unx)
Build location= /64playpen/simonmar/nightly/STABLE-cam-04-unx
Build config file = /home/simonmar/nightly/site/msrc/conf-STABLE-cam-04-unx
Nightly build started on cam-04-unx at Tue Jan 25 18:10:01 GMT 2011.
checking out new s
starapple (OS X 10.6 snowleopard 64 HEAD), build 5
Build succeeded
Details: http://darcs.haskell.org/ghcBuilder/builders/starapple/5.html
darcs checkout| Success
create mk/build.mk| Success
get subrepos | Success
repo versions | Success
setting version
mbolingbroke (x86 OSX HEAD), build 61
Build succeeded
Details: http://darcs.haskell.org/ghcBuilder/builders/mbolingbroke/61.html
darcs checkout| Success
create mk/build.mk| Success
get subrepos | Success
repo versions | Success
setting version date
On Tue, Jan 25, 2011 at 5:22 PM, Roman Leshchinskiy wrote:
> 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
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 Tue, Jan 25, 2011 at 11:06 PM, Roman Leshchinskiy
wrote:
> Yes. See, for instance,
> http://hackage.haskell.org/packages/archive/vector/0.7.0.1/doc/html/Data-Vector.html#v:force
That's exactly the operation I had in mind. I have read your vector
code with enthusiasm. :)
Johan
_
Mon Jan 24 15:31:21 PST 2011 Ian Lynagh
* Keep separate linker flags, for when we want to link with gcc or ld
M ./aclocal.m4 -7 +11
M ./compiler/ghc.mk -2 +4
M ./compiler/main/DynFlags.hs -1 +2
M ./configure.ac -7 +10
M ./distrib/configure.ac.in -7 +14
M ./libffi/ghc.mk
Mon Jan 24 10:36:18 PST 2011 Ian Lynagh
* Fix validate on OS X 64
M ./rts/Linker.c -2 +3
View patch online:
http://darcs.haskell.org/cgi-bin/darcsweb.cgi?r=ghc;a=darcs_commitdiff;h=20110124183618-3fd76-e6fe85c9fc1ed357a1ba954e5368d57a4a8e7515.gz
__
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,
>> since both unsafeFreeze# and unsa
So, to summarize what you guys have been talking about, it's looking like
the primops would become:
copyArray#::Array# a -> Int# -> MutableArray# s a -> Int# ->
Int# -> State# s -> State# s
copyMutableArray# :: MutableArray# a -> Int# -> MutableArray# s a -> Int# ->
Int# -> State#
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,
> since both unsafeFreeze# and unsafeThaw# do some work we might want 4
> different var
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 ByteArray# directly to FFI calls, should
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 ByteArray# directly to FFI calls, should make memcpy safe
> even for unpinned byte arrays. A
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 memcpys on unpinned memory.
>>
>> Why
Hi Roman,
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 memcpys on unpinned memory.
>
> Why not just use memcpy?
I'm working with unpinned
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
Hi,
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. Some
preliminary benchmarks have shown that on my Mac, a memcpy-based array copy
is about 4x faster than a Haskell-based loop doing the same thing. The use
BTW I drew a diagram of the top levels of the compiler, here
http://hackage.haskell.org/trac/ghc/wiki/Commentary/Pipeline
Simon
| -Original Message-
| From: cvs-ghc-boun...@haskell.org [mailto:cvs-ghc-boun...@haskell.org] On
Behalf
| Of Simon Peyton Jones
| Sent: 25 January 2011 16:1
Tue Jan 25 08:16:32 PST 2011 simo...@microsoft.com
* Split main/GHC into GHC and GhcMake
There are two things going on in main/GHC.hs.
* It's the root module of the GHC package
* It contains lots of stuff for --make
It is also gigantic (2.7k lines)
This patch splits it into t
Tue Jan 25 05:11:15 PST 2011 simo...@microsoft.com
* Comments only
M ./compiler/hsSyn/HsExpr.lhs -1 +2
View patch online:
http://darcs.haskell.org/cgi-bin/darcsweb.cgi?r=ghc;a=darcs_commitdiff;h=20110125131115-1287e-a7f214c465248b554fcc9e48a1c43612080f.gz
_
On 25/01/2011 11:18, malcolm.wallace wrote:
Is it possible to tweak the git notification script to present the
interesting information (patch messages) first, rather than following a
screenful of random numbers? Also, is it possible to get a short commit
name into the email subject, instead of th
My guess is that the base-package modules need language extensions to compile.
These extensions are specified in libraries/base/base.cabal (search for
"extensions"). I don't think you are including these extensions in the dflags
you are using.
Personally I think it'd be better if each base-pa
Ian
In compiler/, if I say "make 1", it rebuilds the stage1 compiler, AND THEN
RE-CONFIGURES all the libraries. The latter takes ages.
The whole point of 'make 1' is to make the stage1 compiler only, without the
knock on effects. As it now stands, it takes 5 seconds to rebuild the compiler
(
Is it possible to tweak the git notification script to present the interesting information (patch messages) first, rather than following a screenful of random numbers? Also, is it possible to get a short commit name into the email subject, instead of the decidedly human-unfriendly branch/reference
Tue Jan 25 03:06:54 PST 2011 simo...@microsoft.com
* Redundant case is now eliminated
M ./tests/ghc-regress/simplCore/should_compile/T3717.stderr -15 +1
View patch online:
http://darcs.haskell.org/cgi-bin/darcsweb.cgi?r=testsuite;a=darcs_commitdiff;h=20110125110654-1287e-437f69e006095b915e
Tue Jan 25 02:20:21 PST 2011 simo...@microsoft.com
* Test Trac #4917
A ./tests/ghc-regress/typecheck/should_compile/T4917.hs
M ./tests/ghc-regress/typecheck/should_compile/all.T +1
View patch online:
http://darcs.haskell.org/cgi-bin/darcsweb.cgi?r=testsuite;a=darcs_commitdiff;h=2011012
Tue Jan 25 03:05:25 PST 2011 simo...@microsoft.com
* Fix Trac #3717 by making exprOkForSpeculation a bit cleverer
The main change here is to do with dropping redundant seqs.
See Note [exprOkForSpeculation: case expressions] in CoreUtils.
M ./compiler/coreSyn/CoreUtils.lhs -5 +14
Tue Jan 25 03:01:12 PST 2011 simo...@microsoft.com
* Fix Trac #4917: try a bit harder to unify on-the-fly
This is generally a modest improvement but, more important,
it fixes a "unify-under-forall" problem. See Note [Avoid deferring].
There's still a lurking unsatisfactory-ness in t
Tue Jan 25 03:04:18 PST 2011 simo...@microsoft.com
* Improve dataToTag# magic
dataToTag# is a bit unsatisfactory because it requires
its argument to be evaluated, and we don't have a good
way to enforce that. This patch adds some comments, and
makes exprOkForSpeculation a bit less pic
On 25 January 2011 09:35, Lars Viklund wrote:
> A subtree seems to be a way of getting the
> contents of a branch merged at a non-root location. It might be a
> relevant read and something to evaluate.
There is also the git-subtree project
(https://github.com/apenwarr/git-subtree). They explain t
On Mon, Jan 10, 2011 at 06:22:03PM -0600, David Peixotto wrote:
> Another possible advantage to git would be its support for submodules[1]. If
> we made the switch to git for all the repositories that GHC uses, then we
> could set them up as submodules. The advantage of submodules is that the GHC
The branch, master has been updated
via 9e6e96bdc19d71318ac7fc2fc9381ce57a22e399 (commit)
via eb3a1aecac72d22c618b4050fb88eac9055b527a (commit)
via dd47428295d89eb6bbf91316ac4f5a6e98b1ec70 (commit)
via 94504e0d978d48748d24676cbb5d38cf2f7c4e3d (commit)
via 79f
42 matches
Mail list logo
