pgj-freebsd-amd64-stable (amd64 FreeBSD STABLE), build 128
Build succeeded
Details:
http://darcs.haskell.org/ghcBuilder/builders/pgj-freebsd-amd64-stable/128.html
darcs checkout | Success
create mk/build.mk | Success
get subrepos | Success
repo versions| Success
setting v
pgj-freebsd-i386-stable (x86 FreeBSD STABLE), build 111
Build succeeded
Details:
http://darcs.haskell.org/ghcBuilder/builders/pgj-freebsd-i386-stable/111.html
darcs checkout | Success
create mk/build.mk | Success
get subrepos | Success
repo versions| Success
setting versi
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 Mon Jan 10 18:10:02 GMT 2011.
checking out new source tree
pgj2 (amd64 FreeBSD HEAD), build 246
Build succeeded
Details: http://darcs.haskell.org/ghcBuilder/builders/pgj2/246.html
darcs checkout | Success
create mk/build.mk | Success
get subrepos | Success
repo versions| Success
setting version date | Success
booting
I agree with Roman's position. I would prefer to stay with darcs (it has its
advantages and disadvantages, but has definitely been improving much in the
past).
In any case, all of GHC including all dependencies must be available and
patchable with a *single* VCS. Mixing VCS' will lead to madn
On 10 January 2011 22:19, Simon Marlow wrote:
> We're intrested in opinions from both active and potential GHC
> developers/contributors. Let us know what you think - would this make life
> harder or easier for you? Would it make you less likely or more likely to
> contribute?
I would really li
tn23 (x86 OSX HEAD), build 239
Build succeeded
Details: http://darcs.haskell.org/ghcBuilder/builders/tn23/239.html
darcs checkout | Success
create mk/build.mk | Success
get subrepos | Success
repo versions| Success
setting version date | Success
booting | Succ
pgj (x86 FreeBSD HEAD), build 248
Build succeeded
Details: http://darcs.haskell.org/ghcBuilder/builders/pgj/248.html
darcs checkout | Success
create mk/build.mk | Success
get subrepos | Success
repo versions| Success
setting version date | Success
booting | Su
simonmar-win32-head (x86 Windows HEAD), build 212
Build failed
Details:
http://darcs.haskell.org/ghcBuilder/builders/simonmar-win32-head/212.html
darcs checkout | Success
create mk/build.mk | Success
get subrepos | Success
repo versions| Success
setting version date | Suc
simonmar-win32-stable (x86 Windows STABLE), build 147
Build failed
Details:
http://darcs.haskell.org/ghcBuilder/builders/simonmar-win32-stable/147.html
darcs checkout | Success
create mk/build.mk | Success
get subrepos | Success
repo versions| Success
setting version date
mbolingbroke (x86 OSX HEAD), build 52
Build succeeded
Details: http://darcs.haskell.org/ghcBuilder/builders/mbolingbroke/52.html
darcs checkout | Success
create mk/build.mk | Success
get subrepos | Success
repo versions| Success
setting version date | Success
booting
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 Mon Jan 10 18:10:01 GMT 2011.
checking out new s
On Jan 10, 2011, at 5:19 AM, Simon Marlow wrote:
>
> We're intrested in opinions from both active and potential GHC
> developers/contributors. Let us know what you think - would this make life
> harder or easier for you? Would it make you less likely or more likely to
> contribute?
+1 for mo
I just want to point out that since the last discussion we collected
some migration advice at
http://hackage.haskell.org/trac/ghc/wiki/GitForDarcsUsers
Some of it may be untested (or wrong), but it should be a good starting point.
On 10 January 2011 22:15, Neil Mitchell wrote:
>> As another non-
> As another non-GHC contributor, my opinion should probably also count for
> little, but my experience with git has been poor.
>
> I have used git daily in my job for the last year. Like Simon PJ, I
> struggle to understand the underlying model of git, despite reading quite a
> few tutorials. I
On Mon, Jan 10, 2011 at 5:34 AM, Pavel Perikov wrote:
> Please please consider Mercurial if migration from darcs is inevitable :)
>
For what it's worth, Mercurial generally interoperates quite well with git
and github, using the hg-git plugin. As a longtime Mercurial user and an
occasional GHC c
On 10/01/2011, at 13:27, Simon Marlow wrote:
> On 10/01/2011 13:02, Max Bolingbroke wrote:
>> However, I remember the last time this came up there were some issues
>> that might make migration painful. From the top of my head:
>>
>> 1) Some people expressed concern that they would have to use two
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 Mon Jan 10 18:00:02 GMT 2011.
checking out new source tree
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 Mon Jan 10 18:00:02 GMT 2011.
checking out new source
On 10 Jan 2011, at 14:02, Gregory Collins wrote:
+1. I don't have a lot of skin in this particular game (I'm not
currently a GHC contributor and am unlikely to become one in the near
future), but I can offer some anecdotal evidence:
As another non-GHC contributor, my opinion should probably als
On Mon, Jan 10, 2011 at 5:08 PM, Pavel Perikov wrote:
> Probably most valuable are the opinions of GHC development team of course :)
> Git really seem to be more popular, Mercurial just seem more streamlined to
> me :)
Their preference if of course very important, but they partly wanted
to make
I'd be for a move, but haven't contributed much lately. I use Git for
all my personal projects, so I consider Git to be useful. I
personally find sending patches via Git to be harder than with Darcs,
but if we use Github the pull-request-based model should work well.
I used Git on Windows two ye
On Mon, Jan 10, 2011 at 2:43 PM, Pavel Perikov wrote:
>
> On 10.01.2011, at 16:40, Johan Tibell wrote:
>> While Mercurial is a fine choice, I think there are more Haskellers
>> that use Git than Mercurial. Probably because GitHub is such an
>> awesome service.
>
> Interesting. It will be great to
I fully support this (especially if it lived on github), but we should
probably sort the top contributors to GHC in the past year or so and
consider their opinions on the matter in that order :) I certainly would not
be on that list. A git(hub)-based workflow would however facilitate any
minor cont
On Mon, Jan 10, 2011 at 2:38 PM, Johan Tibell wrote:
>> Ultimately I'm quite concerned with keeping GHC HQ happy (as you guys
>> do the lions share of the work!). I feel we should only make the
>> switch if the most frequent committers (i.e. Simon, Simon and Ian) are
>> *totally happy* with it and
On Mon, Jan 10, 2011 at 01:27:17PM +, Simon Marlow wrote:
> On 10/01/2011 13:02, Max Bolingbroke wrote:
>> 2) There was also concern that Git isn't so great on Windows. I have
>> heard that this is less of an issue now, but I never personally
>> suffered from any problems, so can't be sure. (FW
On Mon, Jan 10, 2011 at 2:34 PM, Pavel Perikov wrote:
> Please please consider Mercurial if migration from darcs is inevitable :)
While Mercurial is a fine choice, I think there are more Haskellers
that use Git than Mercurial. Probably because GitHub is such an
awesome service.
Johan
__
On Mon, Jan 10, 2011 at 2:02 PM, Max Bolingbroke
wrote:
> Naturally other workflows are possible and I'm sure other list members
> will chime in with their own favourites :-)
Here's the flow I use:
http://nvie.com/posts/a-successful-git-branching-model/
with the exception of having the master b
On Mon, Jan 10, 2011 at 12:19 PM, Simon Marlow wrote:
> We're intrested in opinions from both active and potential GHC
> developers/contributors. Let us know what you think - would this make life
> harder or easier for you? Would it make you less likely or more likely to
> contribute?
I would a
On 10/01/2011 13:02, Max Bolingbroke wrote:
On 10 January 2011 11:19, Simon Marlow wrote:
Let us know what you think - would this make life
harder or easier for you? Would it make you less likely or more likely to
contribute?
Well, as a sometime-contributor I would certainly be happier hacki
On 10 January 2011 11:19, Simon Marlow wrote:
> Let us know what you think - would this make life
> harder or easier for you? Would it make you less likely or more likely to
> contribute?
Well, as a sometime-contributor I would certainly be happier hacking
on GHC if it were git based. When worki
On 08/01/2011 08:12, Builder wrote:
OVERALL SUMMARY for test run started at Sat Jan 8 07:56:24 UTC 2011
2670 total tests, which gave rise to
14862 test cases, of which
0 caused framework failures
12496 were skipped
2274 expected passes
80 expected failures
It's time to consider again whether we should migrate GHC development
from darcs to (probably) git.
From our perspective at GHC HQ, the biggest problem that we would hope
to solve by switching is that darcs makes branching and merging very
difficult for us. We have a few branches of HEAD that
Right. I've pushed a patch that doesn't make suggestions for single-character
names.
Simon
| -Original Message-
| From: omega.th...@gmail.com [mailto:omega.th...@gmail.com] On Behalf Of Max
| Bolingbroke
| Sent: 24 December 2010 14:27
| To: Simon Peyton-Jones
| Cc: Simon Marlow; cvs-ghc@
Mon Jan 10 03:06:11 PST 2011 simo...@microsoft.com
* Follow change in out-of-scope variable suggestions
Now we don't suggest alternatives for single-character variables
M ./tests/ghc-regress/arrows/should_fail/arrowfail002.stderr -3 +1
M ./tests/ghc-regress/driver/1372/1372.stderr
Mon Jan 10 03:07:17 PST 2011 simo...@microsoft.com
* Follow wibbles in conflicting-instance error messages
M ./tests/ghc-regress/indexed-types/should_fail/SimpleFail11a.stderr -4 +4
M ./tests/ghc-regress/indexed-types/should_fail/SimpleFail11b.stderr -4 +4
M ./tests/ghc-regress/inde
Mon Jan 10 03:06:47 PST 2011 simo...@microsoft.com
* Follow improvement in kind-error message
M ./tests/ghc-regress/typecheck/should_fail/tcfail136.stderr -1 +1
M ./tests/ghc-regress/typecheck/should_fail/tcfail151.stderr -1 +1
View patch online:
http://darcs.haskell.org/cgi-bin/darcsw
Tue Jan 4 16:25:12 PST 2011 simo...@microsoft.com
* Test Trac #4870
A ./tests/ghc-regress/deSugar/should_compile/T4870.hs
A ./tests/ghc-regress/deSugar/should_compile/T4870a.hs
M ./tests/ghc-regress/deSugar/should_compile/all.T +6
View patch online:
http://darcs.haskell.org/cgi-bi
Tue Jan 4 16:15:10 PST 2011 simo...@microsoft.com
* Test Trac #4875
A ./tests/ghc-regress/typecheck/should_fail/T4875.hs
A ./tests/ghc-regress/typecheck/should_fail/T4875.stderr
M ./tests/ghc-regress/typecheck/should_fail/all.T +1
View patch online:
http://darcs.haskell.org/cgi-bi
Mon Jan 10 03:03:51 PST 2011 simo...@microsoft.com
* Do dependency analysis when kind-checking type declarations
This patch fixes Trac #4875. The main point is to do dependency
analysis on type and class declarations, and kind-check them in
dependency order, so as to improve error mess
Mon Jan 10 02:56:47 PST 2011 simo...@microsoft.com
* Move imports around (no change in behaviour)
M ./compiler/main/GHC.hs -4 +4
View patch online:
http://darcs.haskell.org/cgi-bin/darcsweb.cgi?r=ghc;a=darcs_commitdiff;h=20110110105647-1287e-5ee2ba9bec13cf1b57549d5c9fcac6c5644d0713.gz
___
Fri Jan 7 02:28:55 PST 2011 simo...@microsoft.com
* Make fuzzy matching a little less eager for short identifiers
For single-character identifiers we now don't make any suggestions
See comments in Util.fuzzyLookup
M ./compiler/utils/Util.lhs -3 +12
View patch online:
http://darcs.h
Tue Jan 4 16:27:12 PST 2011 simo...@microsoft.com
* Fix Trac #4870: get the inlining for an imported INLINABLE Id
We need the unfolding even for a *recursive* function (indeed
that's the point) and I was using the wrong function to get it
(idUnfolding rather than realIdUnfolding).
43 matches
Mail list logo