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 Fri Aug 29 18:02:05 BST 2008.
checking out
Thorkil Naur <[EMAIL PROTECTED]> added the comment:
http://bugs.darcs.net/msg5757:
> I need a volunteer to do the following:
> ...
I will try to do something about this.
Best regards
Thorkil
--
assignedto: -> thorkilnaur
nosy: +thorkilnaur
status: need-volunteer -> in-progress
_
On 8/29/08, Neil Mitchell <[EMAIL PROTECTED]> wrote:
>
> Could you please upload a new document, and point at the new one? I
> think the "standard" reference for GHC Core is a link to that paper,
> and it would be nice for the references in papers to stay valid. For
> example The Monad Reader Is
2008/8/29 Ian Lynagh <[EMAIL PROTECTED]>:
>
> Hi all,
>
> I have a GHC tree that builds and uses haddock 6.10 during the build
> process, and validates.
>
> David, as I understand it you want to avoid having a separate haddock
> repo for GHC, right?
Yes, but I don't like the thought of having to v
On Fri, Aug 29, 2008 at 09:14:32AM +0100, Simon Peyton-Jones wrote:
>
> This doc should really ship with GHC, just as the manual and Haddock does do,
> and be pointed to from the manual by a relative path. Rather than pointing
> to a single stale version.
>
> Ian, how hard would that be?
Cur
On Fri, Aug 29, 2008 at 12:09:44AM +0200, [EMAIL PROTECTED] wrote:
> Thu Aug 28 17:03:31 CEST 2008 [EMAIL PROTECTED]
> * Fix linkage on OpenBSD.
Thanks! I'll push it when I next push.
Ian
___
Cvs-ghc mailing list
Cvs-ghc@haskell.org
http://www.hask
On Fri, Aug 29, 2008 at 02:48:55PM +0100, Ian Lynagh wrote:
>
> This puts haddock in a similar boat to Cabal, in that if you make
> changes to it then you need to remember to push them specially.
Oh, I guess the other consideration is that the way everything works
will be changing in a couple of
On Fri, Aug 29, 2008 at 10:49:43AM +1000, Manuel M T Chakravarty wrote:
> Thomas Schilling:
> >I tried to plot GHC's dependency graph but it just became a grey/black
> >cloud. A hierarchical module space could clean things up a bit.
>
> Compilers are (in)famous for that property. Using a hierarc
On Fri, Aug 29, 2008 at 02:58:44PM +0100, Neil Mitchell wrote:
>
> > This does mean that any patches to the main haddock repo need to pass
> > validate.
>
> I contribute patches to Haddock, but have no way to run validate (I
> don't have my own computer currently, and can't install mingw/cygwin
>
> OK so regardless of doing the "ship ExtCore ps doc with GHC" issue, we should
> in-place
> update the doc at http://www.haskell.org/ghc/docs/papers/core.ps.gz
I was actually suggesting that the documentation should _not_ be
updated in place, which I think is what Tim was initially proposing. I
OK so regardless of doing the "ship ExtCore ps doc with GHC" issue, we should
in-place update the doc at http://www.haskell.org/ghc/docs/papers/core.ps.gz
I don't know how do to that... does anyone else?
S
| -Original Message-
| From: Neil Mitchell [mailto:[EMAIL PROTECTED]
| Sent: 29
Hi
> This does mean that any patches to the main haddock repo need to pass
> validate.
I contribute patches to Haddock, but have no way to run validate (I
don't have my own computer currently, and can't install mingw/cygwin
on any of the machines I have access to). What should I do? I doubt
the p
Ian Lynagh wrote:
I installed it and ghci is able to do arithmetic, at least.
Heh, that's my usual test for a working installer too :) You'd be
surprised how many things need to be working to get GHCi to print the value
of 2+2.
Cheers,
Simon
___
Ian Lynagh wrote:
On Fri, Aug 29, 2008 at 11:35:38AM +0200, Thomas Schilling wrote:
(1) Ok, thinking about it, it would probably Ok to merge it in
after the 6.10 branch, but then backporting changes to 6.10 would
become very difficult. Maintaining it as a long-running branch would
be invo
Hi all,
I have a GHC tree that builds and uses haddock 6.10 during the build
process, and validates.
David, as I understand it you want to avoid having a separate haddock
repo for GHC, right? So currently what I've done is to make darcs-all
support absolute URLs in the packages file, e.g.:
On Fri, Aug 29, 2008 at 11:35:38AM +0200, Thomas Schilling wrote:
>
> (1) Ok, thinking about it, it would probably Ok to merge it in
> after the 6.10 branch, but then backporting changes to 6.10 would
> become very difficult. Maintaining it as a long-running branch would
> be involving, th
On Thu, Aug 28, 2008 at 10:59:53AM +0100, Simon Marlow wrote:
>
> Nevertheless we should move towards specifying everything about a flag in
> one place. I think Ian had some thoughts along those lines?
Right, we have a ticket for that:
http://hackage.haskell.org/trac/ghc/ticket/1880
Some of
Hi Tim,
> Yes, but first I was hoping that the contents of the link at:
> http://www.haskell.org/ghc/docs/papers/core.ps.gz
> (which the manual points to) could be updated. I don't have access to
> do that myself, as far as I know.
Could you please upload a new document, and point at the new one?
On Fri, Aug 29, 2008 at 11:13:29AM +1000, Manuel M T Chakravarty wrote:
> Ian Lynagh:
>
> >By the way, Manuel, is it supposed to remove the older version of
> >GHC I
> >had installed?
>
> You can have one version per branch.
Hmm, If I start off with your 6.8.3 installed:
$ ls -l /Library/
On 29 Aug 2008, at 10:37, Claus Reinke wrote:
This darcs2 style of announcements seems to be infective. Your
message sounds as if you'd like someone to tell you that no, you
shouldn't really merge?-)
1. Going directly from not-even-in-head to in-release-candidate
sounds scary, especially
the settling down I was thinking of is that I'm sure the exercise will promote
a good deal of refactoring, moving code around etc. Does this module belong
here or there? Does this function belong here or there? This takes brain
cycles, and there are only 20 days until release candidate
S
|
Simon Peyton-Jones <[EMAIL PROTECTED]> wrote:
> I'm not against this, but I urge that we postpone it until after 6.10.
> There'll be quite a bit of settling down to do, I predict.
Actually, since the module namespace is one of the few extensions that
is purely lexical, I think it is easy to guar
This darcs2 style of announcements seems to be infective. Your
message sounds as if you'd like someone to tell you that no, you
shouldn't really merge?-)
1. Going directly from not-even-in-head to in-release-candidate
sounds scary, especially if it is going to be the only alternative,
wit
On 8/29/08, Simon Peyton-Jones <[EMAIL PROTECTED]> wrote:
> It think you do! It's just part of the GHC darcs repo, at
> docs/ext-core
> It even has your name in it, last modified 5 May 08.
>
> Or maybe I'm missing the point. Perhaps it's fully up to date (thank you),
> and what you are
| On 8/29/08, Simon Peyton-Jones <[EMAIL PROTECTED]> wrote:
| > Excellent plan. Could you send us a patch? Or commit one yourself?
| >
|
| Yes, but first I was hoping that the contents of the link at:
| http://www.haskell.org/ghc/docs/papers/core.ps.gz
| (which the manual points to) could be upda
On 8/29/08, Simon Peyton-Jones <[EMAIL PROTECTED]> wrote:
> Excellent plan. Could you send us a patch? Or commit one yourself?
>
Yes, but first I was hoping that the contents of the link at:
http://www.haskell.org/ghc/docs/papers/core.ps.gz
(which the manual points to) could be updated. I don't
Excellent plan. Could you send us a patch? Or commit one yourself?
Thanks
Simon
| -Original Message-
| From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Tim Chevalier
| Sent: 28 August 2008 22:31
| To: Cvs-ghc@haskell.org
| Subject: Updating External Core docs for 6.10
|
|
| > The arguments for moving to hierarchical module names were:
| >
| > * it makes finding modules much easier for people new to the code
| > (although tools can help here). For example, Neil Mitchell said:
| > Yhc moved to heirarchical module names, and it was a fantastic
| >decision
|
Build results:
x86-64 Linux head:fail (failed stage1)
x86 Windows head: fail (failed darcs)
x86 Windows head fast:pass pass fail (failed stage2) fail (failed
darcs) fail (failed darcs) pass
fast486 head: lost
gabor head: pass
kgarda
Build results:
tnaur PPC OSX stable 2: pass
x86 Windows stable: fail (failed stage1)
x86 Windows stable fast: pass pass pass pass pass pass pass
x86-64 Linux stable: fail (failed stage1)
Old unexpected test failures:
TyFamUndec 6 gabor stable
barton-mangler-bug 1 tna
30 matches
Mail list logo
