Build description = HEAD on i386-unknown-linux
(cam-02-unx.europe.corp.microsoft.com)
Build location= /playpen/ghc/nightly/HEAD-cam-02-unx
Build config file = /home/simonmar/nightly/site/msrc/conf-HEAD-cam-02-unx
Nightly build started on cam-02-unx at Mon Apr 2 19:30:00 BST 2007.
checkin
Build description = 6.6 branch on i386-unknown-linux
(cam-02-unx.europe.corp.microsoft.com)
Build location= /playpen/ghc/nightly/STABLE-cam-02-unx
Build config file = /home/simonmar/nightly/site/msrc/conf-6.6-cam-02-unx
Nightly build started on cam-02-unx at Mon Apr 2 19:00:01 BST 2007.
sven.panne:
> On Monday 02 April 2007 15:44, Malcolm Wallace wrote:
> > Done (although with some reluctance due to the general network slowness
> > of darcs.haskell.org). In the new darcs-all, I am very keen to retain
> > the ability to use package repos stored elsewhere (not at
> > darcs.haskell.
Malcolm.Wallace:
> Sven Panne <[EMAIL PROTECTED]> wrote:
>
> > * Malcolm: Could you move the polyparse repository from
> > http://www.cs.york.ac.uk/fp/darcs/polyparse to
> > darcs.haskell.org/packages, please? This would make things more
> > consistent.
>
> Done (although with some reluctance
On Monday 02 April 2007 15:44, Malcolm Wallace wrote:
> Done (although with some reluctance due to the general network slowness
> of darcs.haskell.org). In the new darcs-all, I am very keen to retain
> the ability to use package repos stored elsewhere (not at
> darcs.haskell.org).
Thanks, that wa
Sven Panne <[EMAIL PROTECTED]> wrote:
> * Malcolm: Could you move the polyparse repository from
> http://www.cs.york.ac.uk/fp/darcs/polyparse to
> darcs.haskell.org/packages, please? This would make things more
> consistent.
Done (although with some reluctance due to the general network slowne
While we are at the darcs topic: I get problems most of the time I run
several "darcs pull" commands for the same server, but different repositories
on that server via SSH (cryptic messages about not being able to get some
patches etc.). Somehow darcs seems to share the SSH ControlPath (see
Ext
From: GHC Build Reports <[EMAIL PROTECTED]>
To: cvs-ghc@haskell.org
Subject: [nightly] 02-Apr-2007 build of of 6.6 branch on i386-unknown-mingw32
(bling)
Build description = of 6.6 branch on i386-unknown-mingw32 (bling)
Build location= /fptools/builds/STABLE
Build config file = /fptools/buil
Sven Panne wrote:
Quick question: GHC's current darcs-all adds --partial by default, and the
user has to override this with --complete if this is wanted. Given my
sometimes rather strange experiences with partial repos (darcs doesn't find a
patch, "darcs changes" is silent, etc.), I've switched
Quick question: GHC's current darcs-all adds --partial by default, and the
user has to override this with --complete if this is wanted. Given my
sometimes rather strange experiences with partial repos (darcs doesn't find a
patch, "darcs changes" is silent, etc.), I've switched to --complete for
sven.panne:
> On Monday 02 April 2007 13:51, Donald Bruce Stewart wrote:
> > [...]
> > nhc does use a base containing ByteString *but* it needed a couple of
> > tweaks to compile. Those nhc patches are in the darcs repo, but not in
> > the standard base yet.
> >
> > They will be on the next merge.
On Monday 02 April 2007 13:51, Donald Bruce Stewart wrote:
> [...]
> nhc does use a base containing ByteString *but* it needed a couple of
> tweaks to compile. Those nhc patches are in the darcs repo, but not in
> the standard base yet.
>
> They will be on the next merge. [...]
Could you merge jus
sven.panne:
> On Monday 02 April 2007 13:23, Donald Bruce Stewart wrote:
> > [...]
> > The other compilers should be using a base package with fps in it, as
> > hugs and ghc do.
> >
> > fps as a package only exists as a seperate darcs repo for those systems
> > that don't have bytestrings in base.
On Monday 02 April 2007 13:23, Donald Bruce Stewart wrote:
> [...]
> The other compilers should be using a base package with fps in it, as
> hugs and ghc do.
>
> fps as a package only exists as a seperate darcs repo for those systems
> that don't have bytestrings in base. I.e. older GHC's, and nhc
sven.panne:
> I'm currently trying to unify the darcs-all scripts for GHC/Hugs/nhc, adding
> a "--release" option on the way, which is inteded to retrieve fixed versions
> from Hackage instead of the latest & greatest stuff from darcs repos. Looking
> at nhc's package list, I found a few issues:
I'm currently trying to unify the darcs-all scripts for GHC/Hugs/nhc, adding
a "--release" option on the way, which is inteded to retrieve fixed versions
from Hackage instead of the latest & greatest stuff from darcs repos. Looking
at nhc's package list, I found a few issues:
* Iavor's package
sven.panne:
> On Monday 02 April 2007 10:07, Simon Marlow wrote:
> > Since we're all demonstrating our local darcs hacks, here's mine: I use
> > HTTP for get/pull, and I have a script (attached) that grovels in
> > _darcs/prefs/repos to find the right place to push to and then pushes over
> > SSH.
On Monday 02 April 2007 10:07, Simon Marlow wrote:
> Since we're all demonstrating our local darcs hacks, here's mine: I use
> HTTP for get/pull, and I have a script (attached) that grovels in
> _darcs/prefs/repos to find the right place to push to and then pushes over
> SSH.
So what I seem to rea
On Monday 02 April 2007 10:37, Simon Peyton-Jones wrote:
> Is it documented somewhere? Thorough documentation multiplies the user
> base!
I'm quite aware of that, but the script is not 100% finished yet. Anyway, we
will need *all* packages on Hackage for "release" checkouts, but there are
curre
From: GHC Build Reports <[EMAIL PROTECTED]>
To: cvs-ghc@haskell.org
Subject: [nightly] 01-Apr-2007 build of of HEAD on i386-unknown-mingw32 (bling)
Build description = of HEAD on i386-unknown-mingw32 (bling)
Build location= /fptools/builds/HEAD
Build config file = /fptools/builds/ghc-nightly/
Ian Lynagh wrote:
On Sun, Apr 01, 2007 at 01:23:32PM +0200, Sven Panne wrote:
When getting a repo via HTTP, darcs seems to be *much* faster than via SSH.
Here as an example the cpphs repo, 3.7 patches per second vs. 0.7 patches per
second (almost unusable for large/old repos):
5. :-( Is there
Mon Apr 2 00:38:35 PDT 2007 [EMAIL PROTECTED]
* Make type-tidying work for coercion variables
When tidying a TyVar binder, we must tidy its kind if it's a coercion
variable! I had forgotten to do this, which is a serious bug. As a
result some more complicated programs were getting a
New unexpected test passes:
barton-mangler-bug 1 tnaur PPC OSX 6.6
cholewo-eval1 tnaur PPC OSX 6.6
New unexpected test failures:
arith0111 tnaur PPC OSX 6.6
barton-mangler-bug 1 tnaur PPC OSX 6.6
concprog001 1 tnaur PPC OSX 6.6
concprog0
Old unexpected test passes:
arith0081 x86 Windows head
barton-mangler-bug 2 macgyver PPC OSX head
cholewo-eval3 x86 Windows head
New unexpected test failures:
cg035 1 x86 Windows head
rand001 1 x86 Windows head fast
read001
24 matches
Mail list logo
