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 Wed Jan 26 18:00:01 GMT 2011.
checking out new source tree
pgj-freebsd-amd64-stable (amd64 FreeBSD STABLE), build 142
Build succeeded
Details:
http://darcs.haskell.org/ghcBuilder/builders/pgj-freebsd-amd64-stable/142.html
darcs checkout| Success
create mk/build.mk| Success
get subrepos | Success
repo versions
pgj-freebsd-i386-stable (x86 FreeBSD STABLE), build 125
Build succeeded
Details:
http://darcs.haskell.org/ghcBuilder/builders/pgj-freebsd-i386-stable/125.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 Wed Jan 26 18:10:01 GMT 2011.
checking out new source tree
pgj2 (amd64 FreeBSD HEAD), build 260
Build succeeded
Details: http://darcs.haskell.org/ghcBuilder/builders/pgj2/260.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 227
Build succeeded
Details:
http://darcs.haskell.org/ghcBuilder/builders/simonmar-win32-head/227.html
darcs checkout| Success
create mk/build.mk| Success
get subrepos | Success
repo versions | Success
set
simonmar-win32-stable (x86 Windows STABLE), build 162
Build succeeded
Details:
http://darcs.haskell.org/ghcBuilder/builders/simonmar-win32-stable/162.html
darcs checkout| Success
create mk/build.mk| Success
get subrepos | Success
repo versions | Succe
pgj (x86 FreeBSD HEAD), build 262
Build succeeded
Details: http://darcs.haskell.org/ghcBuilder/builders/pgj/262.html
darcs checkout| Success
create mk/build.mk| Success
get subrepos | Success
repo versions | Success
setting version date | Success
tn23 (x86 OSX HEAD), build 253
Build succeeded
Details: http://darcs.haskell.org/ghcBuilder/builders/tn23/253.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 Wed Jan 26 18:00:02 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 Wed Jan 26 18:10:01 GMT 2011.
checking out new s
mbolingbroke (x86 OSX HEAD), build 62
Build succeeded
Details: http://darcs.haskell.org/ghcBuilder/builders/mbolingbroke/62.html
darcs checkout| Success
create mk/build.mk| Success
get subrepos | Success
repo versions | Success
setting version date
On Tue, Jan 25, 2011 at 11:37:18AM +, Simon Peyton-Jones wrote:
>
> In compiler/, if I say "make 1", it rebuilds the stage1 compiler, AND THEN
> RE-CONFIGURES all the libraries. The latter takes ages.
Sorry, should be fixed now.
Thanks
Ian
___
Wed Jan 26 16:17:39 PST 2011 Ian Lynagh
* Fix "make 1" etc following the build system changes
The logic is now in mk/compiler-ghc.mk rather than being duplicated in
ghc/Makefile and compiler/Makefile.
M ./Makefile +2
M ./compiler/Makefile -25 +2
M ./ghc/Makefile -44 +1
A ./
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
kgardas-opensolaris-x86-head (x86 Solaris HEAD), build 122
Build succeeded
Details:
http://darcs.haskell.org/ghcBuilder/builders/kgardas-opensolaris-x86-head/122.html
darcs checkout| Success
create mk/build.mk| Success
get subrepos | Success
repo versions
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-7.0/ghc;a=darcs_commitdiff;h=20110124183618-3fd76-e6fe85c9fc1ed357a1ba954e5368d57a4a8e7515.gz
__
Fri Dec 17 15:41:24 PST 2010 Ian Lynagh
* Whitespace-only in rts/Linker.c
M ./rts/Linker.c -909 +909
View patch online:
http://darcs.haskell.org/cgi-bin/darcsweb.cgi?r=ghc-7.0/ghc;a=darcs_commitdiff;h=20101217234124-3fd76-edd31232e8b46645bf0eacbd64a86dbbf298d178.gz
__
Fri Dec 10 01:00:45 PST 2010 Simon Marlow
* Fix Windows build: move rtsTimerSignal to the POSIX-only section
M ./rts/Linker.c -2 +2
View patch online:
http://darcs.haskell.org/cgi-bin/darcsweb.cgi?r=ghc-7.0/ghc;a=darcs_commitdiff;h=20101210090045-12142-27d25221b7b0158830777e9b874059dde9dc
Fri Dec 17 14:38:11 PST 2010 Ian Lynagh
* Add some casts to fix warnings; patch from Greg Wright
M ./rts/Linker.c -4 +4
View patch online:
http://darcs.haskell.org/cgi-bin/darcsweb.cgi?r=ghc-7.0/ghc;a=darcs_commitdiff;h=20101217223811-3fd76-932ec584c0ccba175976f934f95d5968b68a3bd9.gz
___
Wed Dec 8 10:37:55 PST 2010 Dmitry Astapov
* Export the value of the signal used by scheduler (#4504)
M ./includes/rts/Timer.h +1
M ./rts/Linker.c +1
M ./rts/posix/Itimer.c +6
View patch online:
http://darcs.haskell.org/cgi-bin/darcsweb.cgi?r=ghc-7.0/ghc;a=darcs_commitdiff;h=2010
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
On 01/26/11 06:22, Simon Marlow wrote:
No - as soon as the thread enters foreign code via a safe foreign call,
GC can happen at any time.
(Which is a very good thing: if you *want* to call a long-running, or
running forever, piece of foreign code, there is a way to do it without
breaking the
Wed Jan 26 09:31:38 PST 2011 simo...@microsoft.com
* Test Trac #4918
M ./tests/ghc-regress/simplCore/should_compile/Makefile +6
A ./tests/ghc-regress/simplCore/should_compile/T4918.hs
A ./tests/ghc-regress/simplCore/should_compile/T4918.stdout
A ./tests/ghc-regress/simplCore/sho
Wed Jan 26 09:08:50 PST 2011 simo...@microsoft.com
* Test Trac #4912
A ./tests/ghc-regress/typecheck/should_compile/T4912.hs
A ./tests/ghc-regress/typecheck/should_compile/T4912.stderr
A ./tests/ghc-regress/typecheck/should_compile/T4912a.hs
M ./tests/ghc-regress/typecheck/shoul
Wed Jan 26 09:09:48 PST 2011 simo...@microsoft.com
* Test Trac #4903
M ./tests/ghc-regress/simplCore/should_compile/Makefile +6
A ./tests/ghc-regress/simplCore/should_compile/T4903.hs
A ./tests/ghc-regress/simplCore/should_compile/T4903a.hs
M ./tests/ghc-regress/simplCore/should
Wed Jan 26 09:21:12 PST 2011 simo...@microsoft.com
* Fix dependencies among specialisations for imported Ids
This was a subtle one (Trac #4903). See
Note [Glom the bindings if imported functions are specialised]
in Speclialise.
Fundamentally, a specialised binding for an importe
Wed Jan 26 09:18:03 PST 2011 simo...@microsoft.com
* Fix bug in roughTopNames
roughTopNames was returning a name that in fact might be
"looked though" by the rule matcher. Result: a rule
that should match was being pre-emptively discarded.
See Note [Care with roughTopName].
Fi
Wed Jan 26 09:12:55 PST 2011 simo...@microsoft.com
* Comments only, plus a tiny bit of debug printing
M ./compiler/coreSyn/CoreUnfold.lhs -7 +8
View patch online:
http://darcs.haskell.org/cgi-bin/darcsweb.cgi?r=ghc;a=darcs_commitdiff;h=20110126171255-1287e-15323014293f657549c6bc6d27dc0df7d
Wed Jan 26 09:10:30 PST 2011 simo...@microsoft.com
* Bleat a bit more informatively in unionLists
M ./compiler/utils/ListSetOps.lhs -2 +6
View patch online:
http://darcs.haskell.org/cgi-bin/darcsweb.cgi?r=ghc;a=darcs_commitdiff;h=20110126171030-1287e-457f7a4d453289066426ece3ded6f30a43632f0
Wed Jan 26 09:12:29 PST 2011 simo...@microsoft.com
* Look through type synonyms when computing orphans
I renamed functions tyClsNamesOfTypes to oprhNamesOfType,
because it's only used in that capacity, and we therefore
want to look through type synonyms. Similarly exprOrphNames.
T
Wed Jan 26 09:12:35 PST 2011 simo...@microsoft.com
* Comments only
M ./compiler/basicTypes/Var.lhs -4 +10
View patch online:
http://darcs.haskell.org/cgi-bin/darcsweb.cgi?r=ghc;a=darcs_commitdiff;h=20110126171235-1287e-54c7f310eebcbc05899316b9af14cb1e04006e61.gz
__
I worked with setContext, et. al., to get something other than an empty list.
However, while working on a good test case, it occurred to me that setContext
and getNamesInScope is not the correct approach -- the GHC interface assumes a
static environment, not a dynamic environment as exemplified
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
On 26/01/2011 11:15, Roman Leshchinskiy wrote:
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
unders
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
On Wed, Jan 26, 2011 at 11:57 AM, 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
| 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 absolutely does run during *safe* for
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
On Tue, Jan 25, 2011 at 11: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 ha
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://
On 26/01/2011 09:52, Roman Leshchinskiy wrote:
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?
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?
>>
>>
>> http://www.haskell.org/ghc/docs/7.0-l
On 25/01/2011 21:30, Roman Leshchinskiy wrote:
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 Byte
44 matches
Mail list logo
