Re: Version control systems

marlowsd: > Following lots of useful discussion and evaluation of the available DVCSs > out there, the GHC team have made a decision: we're going to switch to git. Hooray, this will generate a lot of open source good will, and help make GHC more accessible to the outside world. Just see the comm

[nightly] 05-Aug-2008 build of HEAD on i386-unknown-linux (cam-02-unx.europe.corp.microsoft.com)

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 Tue Aug 5 18:02:05 BST 2008. checking out

Re: head aches in parser/Parser.hs

On Tue, 2008-08-05 at 16:15 +0100, Claus Reinke wrote: > >>> It is confusing, though, that Cabal silently uses > >>> compiler/parser/Parser.hs, > >>> if it is meant to generate and use compiler/dist-stage[12]/Parser.hs. > >>> > >>> There should be a Cabal warning: > >>> "variant of generated file

Re: head aches in parser/Parser.hs

On Tue, 2008-08-05 at 22:11 +1000, Roman Leshchinskiy wrote: > On 05/08/2008, at 21:15, Duncan Coutts wrote: > > > It knows that .y can be pre-processed to .hs so if it finds both .hs > > and .y then it knows that .y is the ultimate source file and > > pre-processes that. > > > > Do you think this

patch applied (testsuite): Update ghci011 output

Tue Aug 5 03:30:44 PDT 2008 Ian Lynagh <[EMAIL PROTECTED]> * Update ghci011 output M ./tests/ghc-regress/ghci/scripts/ghci011.stdout -1 +1 View patch online: http://darcs.haskell.org/testsuite/_darcs/patches/20080805103044-3fd76-ad72bda509c80e0d956b1c77f3356d1af681125e.gz ___

Re: patch applied (ghc): Remove the cgi package from extralibs

Tue Aug 5 05:55:51 PDT 2008 Ian Lynagh <[EMAIL PROTECTED]> * Remove the cgi package from extralibs It has some sort of Error Monad using the old Exception type. I'm not familiar with it enough to know what the right thing to do for it with extensible exceptions is. I assume this is meant t

more orphaned head exceptions

1. several files in the time package need -fno-warn-orphans (why is this package stricter about these warnings than others?): Data\Time\Calendar\Gregorian.hs:73:9: Warning: orphan instance: instance Show Day Data\Time\LocalTime\LocalTime.hs:68:9: Warning: orphan instance: instance

patch applied (ghc): Don't make a "windows" flag in the Cabal file - os(windows) already exists!

Mon Aug 4 08:34:30 PDT 2008 Ian Lynagh <[EMAIL PROTECTED]> * Don't make a "windows" flag in the Cabal file - os(windows) already exists! Pointed out by Duncan Coutts M ./compiler/ghc.cabal -4 +1 View patch online: http://darcs.haskell.org/ghc/_darcs/patches/20080804153430-3fd76-e4446d89

patch applied (ghc): Remove the cgi package from extralibs

Tue Aug 5 05:55:51 PDT 2008 Ian Lynagh <[EMAIL PROTECTED]> * Remove the cgi package from extralibs It has some sort of Error Monad using the old Exception type. I'm not familiar with it enough to know what the right thing to do for it with extensible exceptions is. M ./libraries/Make

patch applied (ghc): Follow the tuple datatype movements

Mon Aug 4 08:54:02 PDT 2008 Ian Lynagh <[EMAIL PROTECTED]> * Follow the tuple datatype movements M ./compiler/iface/IfaceEnv.lhs -1 +2 M ./compiler/prelude/PrelNames.lhs -5 +6 View patch online: http://darcs.haskell.org/ghc/_darcs/patches/20080804155402-3fd76-1cb5f92583721fafb11ea5c3e

Re: Unfriendly HEAD is unfriendly

> > | Would it be useful if I tried to get hold of such a thing, > > I think it's safe to say that support like this would make many people happy I have an x86 Mac (running Leopard) available 24/7 which I have offered as a buildbot. Just waiting for all the buildbot admin stuff to be sorted out

Re: Unfriendly HEAD is unfriendly

> | Would it be useful if I tried to get hold of such a thing, intending to > run it > | (and make it available) in the same manner as I do the tnaur PPC 2 > machinery, > | including the above suggestions? The PPC Mac OS X's seem to be be on the > way > | out, so something would have to be done abo

RE: Unfriendly HEAD is unfriendly

| > By the way: is there anyone able to host an OS X x86 buildbot? It | > seems like a decently-sized hole in our testsuite. I'd offer to run | > it, but my iMac isn't powered on 24/7. | | Would it be useful if I tried to get hold of such a thing, intending to run it | (and make it available) in

Re: HEADS UP: base3-compat incoming

Apparently one of my attachments got lost, so here it is. Tue Aug 5 16:33:54 BST 2008 Simon Marlow <[EMAIL PROTECTED]> * bump to version 4.0 New patches: [bump to version 4.0 Simon Marlow <[EMAIL PROTECTED]>**20080805153354] hunk ./base.cabal 2 -version:3.0 +version:4.0 Cont

Re: Unfriendly HEAD is unfriendly

Hello, On Monday 04 August 2008 12:38, Simon Marlow wrote: > ... > As I see it, the biggest problem is that the Mac OS X build keeps breaking, > because we don't actively test on that platform. We *do* test on other > platforms: in fact we use the validate script that was originally proposed

Re: head aches in parser/Parser.hs

It is confusing, though, that Cabal silently uses compiler/parser/Parser.hs, if it is meant to generate and use compiler/dist-stage[12]/Parser.hs. There should be a Cabal warning: "variant of generated file in source dir, using that instead of generated file". As far as I know, if you've got c

Re: head aches in parser/Parser.hs

On 05/08/2008, at 21:15, Duncan Coutts wrote: It knows that .y can be pre-processed to .hs so if it finds both .hs and .y then it knows that .y is the ultimate source file and pre-processes that. Do you think this is the wrong behaviour or are you observing different behaviour? I think I'

Re: ghc.cabal

On Tue, Aug 05, 2008 at 12:18:55PM +0100, Duncan Coutts wrote: > On Tue, 2008-08-05 at 00:22 +0100, Ian Lynagh wrote: > > On Mon, Aug 04, 2008 at 10:40:58PM +0100, Duncan Coutts wrote: > > > On Mon, 2008-08-04 at 16:33 +0100, Simon Peyton-Jones wrote: > > > > > > > > John discovered (we think) tha

Re: head aches in parser/Parser.hs

On Tue, Aug 05, 2008 at 09:42:19AM +0100, Simon Marlow wrote: > > Ian: I suspect this is now broken. So we could either require Happy and > Alex unconditionally, in which case the wiki docs need to be updated, or we > could restore the previous behaviuor, but I'm guessing that's harder. In the

Re: ghc.cabal

On Tue, 2008-08-05 at 00:22 +0100, Ian Lynagh wrote: > On Mon, Aug 04, 2008 at 10:40:58PM +0100, Duncan Coutts wrote: > > On Mon, 2008-08-04 at 16:33 +0100, Simon Peyton-Jones wrote: > > > > > > John discovered (we think) that a new feature of the build system is > > > that all GHC's source module

Re: head aches in parser/Parser.hs

On Tue, 2008-08-05 at 14:51 +1000, Roman Leshchinskiy wrote: > On 05/08/2008, at 14:15, Judah Jacobson wrote: > > > It seems that the old, pre-Cabal build system did not clean some or > > all of the preprocessed files (such as Parser.hs). This was not much > > of a problem in practice, because th

patch applied (ghc): Fix Trac #2449

Tue Aug 5 03:54:02 PDT 2008 [EMAIL PROTECTED] * Fix Trac #2449 Deriving isn't allowed in hs-boot files (says the user manual) This patch checks properly instead of crashing! M ./compiler/typecheck/TcDeriv.lhs -11 +26 View patch online: http://darcs.haskell.org/ghc/_darcs/patches

Re: head aches in parser/Parser.hs

On Tue, 2008-08-05 at 10:30 +0100, Claus Reinke wrote: > > contrast, Cabal stores all generated files in a separate directory > > (compiler/dist-stage[1/2]), and thus doesn't need to look at relative > > timestamps; so it gets confused by the old, leftover Parser.hs et al. > > While that is cleane

patch applied (ghc): 2nd try: remove lochash, it isn't needed (now)

Mon Aug 4 05:59:44 PDT 2008 Simon Marlow <[EMAIL PROTECTED]> * 2nd try: remove lochash, it isn't needed (now) M ./rts/Linker.c -35 M ./rts/LinkerInternals.h -3 View patch online: http://darcs.haskell.org/ghc/_darcs/patches/20080804125944-12142-4784c5b4a044428d6dce6a1b78ef86b3a1bcb894.

patch applied (ghc): FIX BUILD on Windows

Mon Aug 4 03:57:40 PDT 2008 Simon Marlow <[EMAIL PROTECTED]> * FIX BUILD on Windows M ./rts/Linker.c -4 View patch online: http://darcs.haskell.org/ghc/_darcs/patches/20080804105740-12142-91887e26029ad74998a4f6f353903a9d623861b7.gz ___ Cvs-ghc

Re: Version control systems

On 5 Aug 2008, at 11:23, Simon Marlow wrote: (Thomas: is the mirror being automatically updated now?). No. I have added the sync script as a post-apply hook, but it doesn't seem to work. Maybe I can debug this with Igloo today. / Thomas PGP.sig Description: This is a digitally signed m

Re: head aches in parser/Parser.hs

contrast, Cabal stores all generated files in a separate directory (compiler/dist-stage[1/2]), and thus doesn't need to look at relative timestamps; so it gets confused by the old, leftover Parser.hs et al. While that is cleaner, it also takes some getting used to, as generated sources are no lo

Re: benefits of extralibs/consequences of exceptions (Re: head aches in parser/Parser.hs)

Max Bolingbroke wrote: Packages that explicitly depend on base-3.x will continue to work. Unfortunately these are few and far between, despite our warnings after the 6.8 release. If this was reccomended practice, then I must have missed where it was documented. In particular, the "Upgrading pac

Version control systems

Following lots of useful discussion and evaluation of the available DVCSs out there, the GHC team have made a decision: we're going to switch to git. It came down to two things: the degree of support available, and flexibility of the tools (git is much happier to let you modify the history tha

Re: benefits of extralibs/consequences of exceptions (Re: head aches in parser/Parser.hs)

> Packages that explicitly depend on base-3.x will continue to work. > Unfortunately these are few and far between, despite our warnings after the > 6.8 release. If this was reccomended practice, then I must have missed where it was documented. In particular, the "Upgrading packages to work with r

Re: head aches in parser/Parser.hs

On 05/08/2008, at 18:30, Thomas Schilling wrote: How is that better than having only the actual source files in you src directory? All generated files will go into dist-*/ and there's no way to confuse anything. Cabal does allow including pre- generated files in dist tarballs, but for deve

Re: benefits of extralibs/consequences of exceptions (Re: head aches in parser/Parser.hs)

Claus Reinke wrote: Btw, are the exception changes meant to lead to another round of library breakage/updates, or is this just the compatibility mode not yet being in place? We're planning to have some backwards compatibility in place for the 6.10.1 release (maybe I'd get a chance to work on

Re: head aches in parser/Parser.hs

Judah Jacobson wrote: It seems that the old, pre-Cabal build system did not clean some or all of the preprocessed files (such as Parser.hs). Actually this was by design. 'make distclean' is supposed to clean everything that is not shipped in a source distribution, and source distributions a

Re: head aches in parser/Parser.hs

How is that better than having only the actual source files in you src directory? All generated files will go into dist-*/ and there's no way to confuse anything. Cabal does allow including pre-generated files in dist tarballs, but for development, generated files have intentionally be mo

benefits of extralibs/consequences of exceptions (Re: head aches in parser/Parser.hs)

It seems that the old, pre-Cabal build system did not clean some or all of the preprocessed files (such as Parser.hs). This was not much of a problem in practice, because the Makefiles used the relative timestamps to tell whether to regenerate Parser.hs from Parser.y. In contrast, Cabal stores a

Daily report for head

Build results: x86-64 Linux head:lost x86 Windows head: fail (failed stage1) x86 Windows head fast:lost pass lost pass fast486 head: pass gabor head: pass mnemosyne x86-64 Gentoo head: pass tnaur x86 Linux head: pass x86-64 L