pgj-freebsd-amd64-stable (amd64 FreeBSD STABLE), build 246
Build succeeded
Details:
http://darcs.haskell.org/ghcBuilder/builders/pgj-freebsd-amd64-stable/246.html
git clone | Success
create mk/build.mk| Success
get subrepos | Success
setting version date
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 May 18 18:10:01 BST 2011.
checking out new source tree
pgj-freebsd-i386-stable (x86 FreeBSD STABLE), build 229
Build succeeded
Details:
http://darcs.haskell.org/ghcBuilder/builders/pgj-freebsd-i386-stable/229.html
git clone | Success
create mk/build.mk| Success
get subrepos | Success
setting version date | S
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 May 18 18:00:01 BST 2011.
checking out new source tree
pgj2 (amd64 FreeBSD HEAD), build 364
Build succeeded
Details: http://darcs.haskell.org/ghcBuilder/builders/pgj2/364.html
git clone | Success
create mk/build.mk| Success
get subrepos | Success
setting version date | Success
booting | Succ
pgj (x86 FreeBSD HEAD), build 366
Build succeeded
Details: http://darcs.haskell.org/ghcBuilder/builders/pgj/366.html
git clone | Success
create mk/build.mk| Success
get subrepos | Success
setting version date | Success
booting | Success
Hello everyone, I'm new to here, I had a question about RTS Scheduler.
When I read through the GHC Wiki commentary on the scheduler I was
confused about this section:
"""
One reason behind marking a Capability as free when it is handed
over is to support fast callouts.
When making a safe foreig
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 May 18 18:10:01 BST 2011.
checking out new s
kgardas-opensolaris-x86-head (x86 Solaris HEAD), build 236
Build succeeded
Details:
http://darcs.haskell.org/ghcBuilder/builders/kgardas-opensolaris-x86-head/236.html
git clone | Success
create mk/build.mk| Success
get subrepos | Success
setting version date
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 May 18 18:00:01 BST 2011.
checking out new source
tn23 (x86 OSX HEAD), build 342
Build failed
Details: http://darcs.haskell.org/ghcBuilder/builders/tn23/342.html
git clone| Success
create mk/build.mk | Success
get subrepos | Success
setting version date | Success
booting | Success
configuring | Failure
On 18 May 2011 22:54, Mark Lentczner wrote:
> The range is U+EF80 through U+EFFF, called "Reserved for encoding hacks".
OK, I've applied another patch so we match this. Here's hoping that
has finally put this issue to rest :-)
> On a related note, If we want to be able to round trip file names t
On Wed, May 18, 2011 at 2:28 AM, Max Bolingbroke wrote:
> > U+F1E00 ~ U+F1EFF -- for "Fie! we need to encode bad encodings!"
> >
> > We can (I'll be happy to) register this with the unofficial registory(2).
>
I've prepared a draft for the registry and submitted it…. Only to have it
pointed out t
sparky-unreg (Sparc Solaris unreg HEAD), build 124
Build failed
Details: http://darcs.haskell.org/ghcBuilder/builders/sparky-unreg/124.html
git clone | Failure: Just (ExitFailure 9)
Build failed
Details: http://darcs.haskell.org/ghcBuilder/builders/sparky-unreg/124.html
ld.so.1: git: fatal: rel
On Wed, May 18, 2011 at 1:36 AM, Max Bolingbroke wrote:
>
> Aha! You go out of your way to detect and replace them. Interesting!
>
Yes, and necessary, as otherwise text is open to data corruption.
___
Cvs-ghc mailing list
Cvs-ghc@haskell.org
http://www
Ok sorry for the spam, just ignore this, I'd not pulled properly.
d-
> -Original Message-
> From: cvs-ghc-boun...@haskell.org [mailto:cvs-ghc-boun...@haskell.org]
> On Behalf Of Dimitrios Vytiniotis
> Sent: 18 May 2011 15:50
> To: cvs-ghc@haskell.org
> Subject: ObjLink error
>
>
> I ge
I get a strange error when building after a fetch and merge in my tree, in
file:
compiler/ghci/ObjLink.lhs
The first one is that module GHC.Foreign is not recognized and suggestion
is to use GHC.ForeignPtr. So I change this and 'make' again. Then the second
one I get later on and is also
On 05/18/11 12:09 PM, Simon Marlow wrote:
The real difficulty with the ghc sources is that fact that
over a dozen different trees, with independant commit histories
are needed to retrieve a working revision.
Right, this is something that would be fixed by using submodules or
subtree merging.
On 18/05/2011 10:02, Erik de Castro Lopo wrote:
Ben Lippmeier wrote:
The patch history doesn't provide a working build at every point
anyway.
Not every point, but from what I've seen the build breakage
is rather rare.
People push *bundles* of patches, and the build needs to work
after the b
On 15 May 2011 18:08, Mark Lentczner wrote:
> We can increase the unlikeliness of colliding with them by using
> an known unused range. I've looked at relevant on-line sources(1,2) and
> suggest:
>
> U+F1E00 ~ U+F1EFF -- for "Fie! we need to encode bad encodings!"
>
> We can (I'll be happy to) reg
Ben Lippmeier wrote:
> The patch history doesn't provide a working build at every point
> anyway.
Not every point, but from what I've seen the build breakage
is rather rare.
> People push *bundles* of patches, and the build needs to work
> after the bundle, but it doesn't need to work after ever
On 17 May 2011 19:50, Bryan O'Sullivan wrote:
> Any attempt to pack a String into a Text will replace UTF-16 surrogates with
> U+FFFD:
> https://github.com/bos/text/blob/master/Data/Text/Internal.hs#L87
> https://github.com/bos/text/blob/master/Data/Text.hs#L363
Aha! You go out of your way to det
On 18/05/2011, at 6:31 PM, Ben Lippmeier wrote:
> On 18/05/2011, at 6:17 PM, Erik de Castro Lopo wrote:
>> In what litrle spare time I have I have been working on debugging
>> a problem that only seems to arise on linux-powerpc (bug #5111).
>>
>> Since I'm time poor and CPU rich, I thought it m
On 18/05/2011, at 6:17 PM, Erik de Castro Lopo wrote:
> Hi all,
>
> In what litrle spare time I have I have been working on debugging
> a problem that only seems to arise on linux-powerpc (bug #5111).
>
> Since I'm time poor and CPU rich, I thought it might be useful to
> try and use a bisect a
Hi all,
In what litrle spare time I have I have been working on debugging
a problem that only seems to arise on linux-powerpc (bug #5111).
Since I'm time poor and CPU rich, I thought it might be useful to
try and use a bisect appraoch to try and find when the bug was
introduced. Unfortunately, if
On 14/05/2011, at 11:03 PM, Edward Z. Yang wrote:
> It's tough to tell with just the commit log. Can you pop open gitk and take a
> look? (maybe
> take a screen shot and share.)
Nevermind. If it's not a common enough problem for people to know what caused
it immediately, then I'll just ignore
26 matches
Mail list logo
