Build description = STABLE on i386-unknown-linux
(cam-02-unx.europe.corp.microsoft.com)
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 Mon Jul 21 18:12:05 BST 2008.
checki
Malcolm.Wallace:
> [been on holiday - just catching up]
>
> > | So the point of this analogy is that the releases of ghc and the
> > | haskell platform should not be synchronised.
> >
> > Does that make sense? ... we do need to release a HLP that works, say,
> > with GHC 6.10, at the same time
On Mon, Jul 21, 2008 at 11:15 AM, Ian Lynagh <[EMAIL PROTECTED]> wrote:
> On Sun, Jul 20, 2008 at 10:46:24PM -0700, Judah Jacobson wrote:
>> Building against the HEAD currently fails (when configuring the stage1
>> compiler) if you have editline already installed in your bootstrapping
>> GHC:
>>
>>
Build description = HEAD on i386-unknown-linux
(cam-02-unx.europe.corp.microsoft.com)
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 Mon Jul 21 18:02:05 BST 2008.
checking out
On Sun, Jul 20, 2008 at 10:46:24PM -0700, Judah Jacobson wrote:
> Building against the HEAD currently fails (when configuring the stage1
> compiler) if you have editline already installed in your bootstrapping
> GHC:
>
> Configuring ghc-6.9...
> cabal-bin: At least the following dependencies are m
> Please do - I suspect that GHC structures can become quite large,
> and though they might not be as big as that benchmark, the penalty
> seems substrantial.
I will probably leave it for a short while, til I am on a better
machine to run the necessary benchmarks. But I do want to track it
down
|if I apply this to the SYB traversal, I get the expected speedup.
..
|Now I need to clean up the mess I made of the source while
|experimenting, and see how to extract this adaptation of the
|Uniplate trick for general SYB use.
I've slightly cleaned up my code and posted it, with some
explana
GNOME has managed to do this. They have regular 6 month time based
releases. Everyone knows in advance when the releases will be so nobody
complains that it should happen sooner (unless they get behind
schedule). They've managed to make the release process so smooth it's
almost boring. No firework
Simon Peyton-Jones wrote:
I wasn't suggesting changing GHC to *use* generic traversals. Rather, I was
suggesting to initially use the simplest available technology to *provide* the
possibility of generic operations to clients of the GHC API. They can choose
whether or not to use them.
Ok!
Malcolm Wallace wrote:
[been on holiday - just catching up]
| So the point of this analogy is that the releases of ghc and the
| haskell platform should not be synchronised.
Does that make sense? ... we do need to release a HLP that works, say,
with GHC 6.10, at the same time that 6.10 comes
On Mon, 2008-07-21 at 10:38 +0100, Malcolm Wallace wrote:
> [been on holiday - just catching up]
Welcome back! :-)
> > | So the point of this analogy is that the releases of ghc and the
> > | haskell platform should not be synchronised.
> >
> > Does that make sense? ... we do need to release
[been on holiday - just catching up]
> | So the point of this analogy is that the releases of ghc and the
> | haskell platform should not be synchronised.
>
> Does that make sense? ... we do need to release a HLP that works, say,
> with GHC 6.10, at the same time that 6.10 comes out.
I disagre
Build results:
x86-64 Linux head:lost
x86 Windows head: fail (failed stage3 bindist bindisttest failed
slave lost)
x86 Windows head fast:pass lost lost fail (failed stage1) fail (failed
stage1) pass
fast486 head: pass
gabor head: p
Build results:
x86 Windows stable: fail (failed runtestsuite failed slave lost)
x86 Windows stable fast: fail (failed runtestsuite) fail (failed runtestsuite)
fail (failed runtestsuite) fail (failed runtestsuite) fail (failed
runtestsuite) fail (failed runtestsuite)
x86-64 Linux stable:
14 matches
Mail list logo
