pgj-freebsd-amd64-stable (amd64 FreeBSD STABLE), build 130
Build succeeded
Details:
http://darcs.haskell.org/ghcBuilder/builders/pgj-freebsd-amd64-stable/130.html
darcs checkout| Success
create mk/build.mk| Success
get subrepos | Success
repo versions
pgj-freebsd-i386-stable (x86 FreeBSD STABLE), build 113
Build succeeded
Details:
http://darcs.haskell.org/ghcBuilder/builders/pgj-freebsd-i386-stable/113.html
darcs checkout| Success
create mk/build.mk| Success
get subrepos | Success
repo versions | S
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 Wed Jan 12 18:00:01 GMT 2011.
checking out new source tree
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 Wed Jan 12 18:10:01 GMT 2011.
checking out new source tree
pgj2 (amd64 FreeBSD HEAD), build 248
Build succeeded
Details: http://darcs.haskell.org/ghcBuilder/builders/pgj2/248.html
darcs checkout| Success
create mk/build.mk| Success
get subrepos | Success
repo versions | Success
setting version date | Succ
simonmar-win32-head (x86 Windows HEAD), build 214
Build succeeded
Details:
http://darcs.haskell.org/ghcBuilder/builders/simonmar-win32-head/214.html
darcs checkout| Success
create mk/build.mk| Success
get subrepos | Success
repo versions | Success
set
pgj (x86 FreeBSD HEAD), build 250
Build succeeded
Details: http://darcs.haskell.org/ghcBuilder/builders/pgj/250.html
darcs checkout| Success
create mk/build.mk| Success
get subrepos | Success
repo versions | Success
setting version date | Success
simonmar-win32-stable (x86 Windows STABLE), build 149
Build succeeded
Details:
http://darcs.haskell.org/ghcBuilder/builders/simonmar-win32-stable/149.html
darcs checkout| Success
create mk/build.mk| Success
get subrepos | Success
repo versions | Succe
tn23 (x86 OSX HEAD), build 241
Build succeeded
Details: http://darcs.haskell.org/ghcBuilder/builders/tn23/241.html
darcs checkout| Success
create mk/build.mk| Success
get subrepos | Success
repo versions | Success
setting version date | Success
bo
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 Wed Jan 12 18:00:01 GMT 2011.
checking out new source
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 Wed Jan 12 18:10:01 GMT 2011.
checking out new s
mbolingbroke (x86 OSX HEAD), build 53
Build succeeded
Details: http://darcs.haskell.org/ghcBuilder/builders/mbolingbroke/53.html
darcs checkout| Success
create mk/build.mk| Success
get subrepos | Success
repo versions | Success
setting version date
kgardas-opensolaris-x86-head (x86 Solaris HEAD), build 110
Build failed
Details:
http://darcs.haskell.org/ghcBuilder/builders/kgardas-opensolaris-x86-head/110.html
darcs checkout| Success
create mk/build.mk| Success
get subrepos | Success
repo versions
Excerpts from Roman Leshchinskiy's message of Wed Jan 12 18:20:25 -0500 2011:
> How would we get the current functionality of darcs-all pull? Is it even
> possible?
Here is the rebase-y workflow. Untested, so I might have gotten one or two
details wrong.
> Suppose I want to hack on GHC and base
On 12/01/2011, at 22:22, Iavor Diatchki wrote:
> When you issue the command "git submodule update", you are telling git to
> advance the sub-module repo to the "expected version" (i.e., where the
> pointer points to). The reason this does not happen automatically is that
> you might have also
Wed Jan 12 15:15:44 PST 2011 simo...@microsoft.com
* Test Trac #2544
A ./tests/ghc-regress/indexed-types/should_fail/T2544.hs
A ./tests/ghc-regress/indexed-types/should_fail/T2544.stderr
M ./tests/ghc-regress/indexed-types/should_fail/all.T +1
View patch online:
http://darcs.haskel
On Mon, Jan 10, 2011 at 8:52 AM, Malcolm Wallace wrote:
> 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 m
You can emulate darcs's patch re-ordering in git if you put each
independent sequence of patches on a separate branch. Then you can
re-merge the branches in whatever order you want. This is a fairly
common git workflow.
What happens after the merges? Does one maintain the branches
somehow, or do
We can't even do this reliably with darcs. Several times I've tried to
unpull one of Simon's patches to work around a bug, and the dependencies
end up being more than just the textual dependencies. Then I have to
fall back to unpulling by date, which is what git would do. And then
sometimes
On 01/12/11 02:52, Alexander McPhail wrote:
Hi,
I have a couple of branches of ghc off of HEAD.
I found that I had some difficulty _finding_ my patch submissions after
weeks of 'darcs_all pull -a'. And I understand that one complaint is the
need to create 'megapatches'.
How is this flow:
1)
* Simon Marlow:
> Thanks for this. I distilled your example into a shell script that
> uses git, and demonstrates that git gets the merge wrong:
>
> http://hpaste.org/42953/git_mismerge
>
> Still, git could get this merge right, it just doesn't (I know there
> are more complex cases that would
On 12/01/2011, at 09:22, Simon Marlow wrote:
> On 11/01/2011 23:11, Roman Leshchinskiy wrote:
>>
>> A quick look at the docs seems to indicate that we'd need to do
>>
>> git pull
>> git submodule update
>>
>> which doesn't look like a win over darcs-all. Also, I completely fail to
>> understan
Wed Jan 12 09:07:19 PST 2011 simo...@microsoft.com
* Produce an error message, not a crash, for HsOpApp with non-var operator
Fixes Trac #4877.
M ./compiler/rename/RnExpr.lhs -2 +6
View patch online:
http://darcs.haskell.org/cgi-bin/darcsweb.cgi?r=ghc;a=darcs_commitdiff;h=201101121707
Fri Jan 7 08:35:41 PST 2011 Simon Marlow
* In configure, test that GHC generates code for the correct platform (#4819)
Patch supplied by the bug reporter, tidied up by me.
$ ./configure --with-ghc=$HOME/fp/bin/i386-unknown-linux/ghc
--build=x86_64-unknown-linux
checking for gfind...
Wed Jan 12 08:02:24 PST 2011 Simon Marlow
* update to work with current packages file format
M ./sync-all -2 +4
View patch online:
http://darcs.haskell.org/cgi-bin/darcsweb.cgi?r=ghc;a=darcs_commitdiff;h=20110112160224-12142-2cf771dbd188efb41e557e8296588c41752b597f.gz
___
If everyone finds this acceptable, I will proceed to implement it in this way.
In summary:
- Generic defaults are marked by the (new) keyword "generic"
- Generic defaults have a type which has to be the same as the class method
they refer to. The context, however, can differ.
- A method can have
Wed Jan 12 08:22:08 PST 2011 simo...@microsoft.com
* Add a missing change
M ./tests/ghc-regress/indexed-types/should_compile/Gentle.stderr +11
View patch online:
http://darcs.haskell.org/cgi-bin/darcsweb.cgi?r=testsuite;a=darcs_commitdiff;h=20110112162208-1287e-c6a7a906a713f7f0a84915d1d378
Hello,
2011/1/12 Simon Peyton-Jones
>
>
> True. I don't think the generic default has to be separated from the class
> declaration; I think it is important that we can explicitly supply the
> context for it. Simon's earlier proposal seemed fine, but I don't understand
> how we can differentiate
Wed Jan 12 06:36:10 PST 2011 simo...@microsoft.com
* Test Trac #4801
A ./tests/ghc-regress/perf/compiler/T4801.hs
M ./tests/ghc-regress/perf/compiler/all.T +29
View patch online:
http://darcs.haskell.org/cgi-bin/darcsweb.cgi?r=testsuite;a=darcs_commitdiff;h=20110112143610-1287e-a244870
Wed Jan 12 07:00:30 PST 2011 simo...@microsoft.com
* Massive bunch of changes to track my massive refactoring to the typechecker
M ./tests/ghc-regress/annotations/should_fail/annfail07.stderr -1 +1
M ./tests/ghc-regress/annotations/should_fail/annfail08.stderr -6 +7
M ./tests/ghc-re
Wed Jan 12 06:36:51 PST 2011 simo...@microsoft.com
* Test Trac #2722
A ./tests/ghc-regress/typecheck/should_run/T2722.hs
A ./tests/ghc-regress/typecheck/should_run/T2722.stdout
M ./tests/ghc-regress/typecheck/should_run/all.T +1
View patch online:
http://darcs.haskell.org/cgi-bin/d
Wed Jan 12 06:56:04 PST 2011 simo...@microsoft.com
* Major refactoring of the type inference engine
This patch embodies many, many changes to the contraint solver, which
make it simpler, more robust, and more beautiful. But it has taken
me ages to get right. The forcing issue was some
see my reply to Pedro
| -Original Message-
| From: andres.l...@googlemail.com [mailto:andres.l...@googlemail.com] On
| Behalf Of Andres Loeh
| Sent: 12 January 2011 11:58
| To: José Pedro Magalhães
| Cc: Simon Peyton-Jones; Johan Jeuring; cvs-ghc@haskell.org; atze
| Subject: Re: Generic de
True. I don't think the generic default has to be separated from the class
declaration; I think it is important that we can explicitly supply the context
for it. Simon's earlier proposal seemed fine, but I don't understand how we can
differentiate between generic and standard default methods. T
Hi,
2011/1/12 Simon Peyton-Jones
>
> I agree that answers can be provided, but
> * It's a lot of new design choices,
> * I believe this new feature (decoupling the class decl from the
>provision of default methods) will require a *lot* of new hacking
> * No one is asking for this feat
| -Original Message-
| From: andres.l...@googlemail.com [mailto:andres.l...@googlemail.com] On
| Behalf Of Andres Loeh
| Sent: 12 January 2011 08:48
| To: Simon Peyton-Jones
| Cc: José Pedro Magalhães; Johan Jeuring; cvs-ghc@haskell.org; atze
| Subject: Re: Generic deriving: new default m
| I think under the hood 3 different mechanisms/concepts are now combined into
| 2 (class + instance):
| (1) class defs without defaults, giving the type of its instances
| (2) instance defs, giving values of classes
| (3) instance initializers, to be invoked for new instances of the class it is
|
On 12/01/2011 00:31, Thorkil Naur wrote:
Hello,
On Thu, Jan 06, 2011 at 11:38:13AM +, Simon Marlow wrote:
...
Presumably these are failures in the fast testsuite and would show
up in a validate, right? Any OS X folks available to take a look?
A quick look reveals:
1. A validate on tn23
The main advantages to darcs are that it can manipulate the sequence of
patches better than git.
The main advantage of git is that every version is accurately named. If
two people have a commit with a given hash, they will have exactly the
same files and history.
I've been wondering about this
On 11/01/2011 19:07, Roman Leshchinskiy wrote:
On 11/01/2011, at 16:14, Tony Finch wrote:
On Mon, 10 Jan 2011, Roman Leshchinskiy wrote:
It also seems to make finding buggy patches rather hard.
Have a look at `git bisect`.
I'm aware of git bisect. It doesn't do what I want. I usually have
On 11/01/2011 23:11, Roman Leshchinskiy wrote:
On 11/01/2011, at 22:20, Simon Marlow wrote:
On 11/01/11 21:57, Roman Leshchinskiy wrote:
IMO, darcs-all works pretty well. I don't think I ever really had
problems with missing library patches.
I often see problems where someone has done 'darcs
| * Does the generic default have to be fixed at the time of the class
| definition?
|
| I think that Pedro's proposal's say "no", whereas Simon's proposals
| imply "yes" to this question. I think that it may be a common scenario
| that someone writes a library defining a class, and someone else c
42 matches
Mail list logo
