On Thu, Aug 28, 2008 at 04:31:16PM +1000, Manuel M T Chakravarty wrote:
> Ian Lynagh:
> >On Mon, Aug 18, 2008 at 12:21:47PM +1000, Manuel M T Chakravarty
> >wrote:
> >>From what you are saying, it seems that one "advantage" of git (in-
> >>place branch switching) is not going to be useful to GHC
Ian Lynagh:
On Mon, Aug 18, 2008 at 12:21:47PM +1000, Manuel M T Chakravarty
wrote:
From what you are saying, it seems that one "advantage" of git (in-
place branch switching) is not going to be useful to GHC in any case
Yes.
(because we use nested repositories).
That does make it harder,
I've "fixed" this problem by increasing the number of registers used on ia64 to
34. The problem will show up again if anyone finds a way to make GCC use even
more registers.
-heatsink
>>
>> Sorry, I couldn't find the rest of the preceding message. Someone
>> wrote that they had to turn dow
On Mon, Aug 18, 2008 at 12:21:47PM +1000, Manuel M T Chakravarty wrote:
> From what you are saying, it seems that one "advantage" of git (in-place
> branch switching) is not going to be useful to GHC in any case (because we
> use nested repositories).
> Manuel
I don't agree. I feel it's convi
> Sorry for being a git n00b, but does using merge mean that we need to use
> in-place branch switching (which you earlier said won't work well for ghc
> anyways)?
You have to kind of "branches" : local ones and remote ones.
remote ones represent the state of remote ones. The only way I know
> Using merge you also get a more accurate reflection of the project
> history, i.e. you can see that the two branches were being developed
> independently.
Timestamps will be preserved so not all information is lost..
Marc
___
Glasgow-haskell-users mail
> I personally don't know Git, and while I'm sure I'll be learning at
> some point, I'm always nervous about learning a VCS on something I
> care about, as mistakes can go quite wrong.
If I can lend you (or someone else) a hand don't hesitate to contact me.
(I'm not a git guru though..)
With git y
Isaac see third
> FWIW, I started a wiki page that tries a direct comparison between Darcs and
> Git:
>
>http://hackage.haskell.org/trac/ghc/wiki/GitForDarcsUsers
>
> Some mappings are simple, some are more complicated and will require
> adopting a different workflow. I still recommen
On Tue, Aug 12, 2008 at 03:17:59PM -0400, Isaac Dupree wrote:
> Thomas Schilling wrote:
> > I encourage everyone to add useful tips and examples both from users who
> > already use Git and later on, once we have gathered more experience. I
> > believe that Git has some features which can improv
On Tue, 2008-08-19 at 23:55 +1000, Ben Lippmeier wrote:
> On 19/08/2008, at 8:57 PM, Ian Lynagh wrote:
>
> > On Mon, Aug 18, 2008 at 09:20:54PM +1000, Ben Lippmeier wrote:
> >>
> >> Ian: Did this problem result in Intel CC / GCC register allocator
> >> freakouts?
> >
> > Have you got me confused w
On 19/08/2008, at 8:57 PM, Ian Lynagh wrote:
On Mon, Aug 18, 2008 at 09:20:54PM +1000, Ben Lippmeier wrote:
Ian: Did this problem result in Intel CC / GCC register allocator
freakouts?
Have you got me confused with someone else? I don't think I've ever
used
Intel CC.
Sorry, I couldn't
On Mon, Aug 18, 2008 at 09:20:54PM +1000, Ben Lippmeier wrote:
>
> Ian: Did this problem result in Intel CC / GCC register allocator
> freakouts?
Have you got me confused with someone else? I don't think I've ever used
Intel CC.
Thanks
Ian
___
Glas
Git 1.6.0 was just released [1]. Might be of interest given the
current discussion.
I cherry picked some highlights that might matter to us:
* Source changes needed for porting to MinGW environment are now all in the
main git.git codebase.
* even more documentation pages are now accessible via "
On 18/08/2008, at 8:13 PM, Simon Marlow wrote:
So would I usually, though I've had to turn down cc flags to get
darcs
to build on ia64 before (SHA1.hs generates enormous register
pressure).
We should really use a C implementation of SHA1, the Haskell version
isn't buying us anything beyon
Duncan Coutts wrote:
On Fri, 2008-08-15 at 15:12 +0100, Ian Lynagh wrote:
On Fri, Aug 15, 2008 at 11:12:20AM +1000, Manuel M T Chakravarty wrote:
Moreover, as I wrote a few times before, some reasons for switching in
the first place are invalidated by not having the core libraries in
git, to
Manuel M T Chakravarty wrote:
From what you are saying, it seems that one "advantage" of git
(in-place branch switching) is not going to be useful to GHC in any case
(because we use nested repositories).
As far as I can tell, in-place branches are not a lot of use to us compared
to just havi
On Mon, Aug 18, 2008 at 12:28:03PM +1000, Manuel M T Chakravarty wrote:
>
> does using merge mean that we need to use in-place branch switching
No; when you "git pull" (the equivalent of darcs pull -a) it will pull
and merge the changes (unless you ask it to rebase them instead of
merging them).
On Mon, Aug 18, 2008 at 12:21:47PM +1000, Manuel M T Chakravarty wrote:
> From what you are saying, it seems that one "advantage" of git (in-
> place branch switching) is not going to be useful to GHC in any case
Yes.
> (because we use nested repositories).
That does make it harder, but the m
Ian Lynagh:
On Fri, Aug 15, 2008 at 04:24:12PM +0100, Ian Lynagh wrote:
On Fri, Aug 15, 2008 at 05:09:55PM +0200, Thomas Schilling wrote:
On Fri, Aug 15, 2008 at 4:38 PM, Ian Lynagh <[EMAIL PROTECTED]> wrote:
One way that it is worse is that you will get a lot more "automatic
merge" commits wh
From what you are saying, it seems that one "advantage" of git (in-
place branch switching) is not going to be useful to GHC in any case
(because we use nested repositories).
Manuel
Ian Lynagh:
On Fri, Aug 15, 2008 at 01:01:08PM +0100, Max Bolingbroke wrote:
2008/8/15 Isaac Dupree <[EMAIL P
Gregory Wright:
On Aug 14, 2008, at 9:12 PM, Manuel M T Chakravarty wrote:
Moreover, as I wrote a few times before, some reasons for switching
in the first place are invalidated by not having the core libraries
in git, too. For example, one complaint about darcs is that it
either doesn't
On Fri, 2008-08-15 at 15:12 +0100, Ian Lynagh wrote:
> On Fri, Aug 15, 2008 at 11:12:20AM +1000, Manuel M T Chakravarty wrote:
> >
> > Moreover, as I wrote a few times before, some reasons for switching in
> > the first place are invalidated by not having the core libraries in
> > git, too. F
On Sat, Aug 16, 2008 at 12:21 AM, Thomas Schilling
<[EMAIL PROTECTED]> wrote:
> you don't use local branches?
I do. I like to keep a clean linear history on top of the upstream
repo. So I might do work in a topic branch, rebase it on my master
branch which is synced with upstream and then push.
-
Max Bolingbroke:
Then, adding complexity, git branches are normally done by
switching in-place. So how does this interact with VCS like darcs
that
doesn't have a concept of in-place switching of branches?
Since we will set up Git to ignore the contents of the Darcs repos, it
will simply lea
you don't use local branches?
On Sat, Aug 16, 2008 at 12:04 AM, Johan Tibell <[EMAIL PROTECTED]> wrote:
> On Fri, Aug 15, 2008 at 4:38 PM, Ian Lynagh <[EMAIL PROTECTED]> wrote:
>> One way that it is worse is that you will get a lot more "automatic
>> merge" commits when you pull changes from the c
On Fri, Aug 15, 2008 at 4:38 PM, Ian Lynagh <[EMAIL PROTECTED]> wrote:
> One way that it is worse is that you will get a lot more "automatic
> merge" commits when you pull changes from the central repo into a repo
> in which you have local commits. I don't think that there is anything
> bad about t
2008/8/15 Ian Lynagh <[EMAIL PROTECTED]>:
>> You can explicitly tell Git about nested Git repos using
>> http://www.kernel.org/pub/software/scm/git/docs/git-submodule.html.
>> This essentially associates a particular version of each subrepo with
>> every version of the repo that contains them, so e
On Thu, Aug 14, 2008 at 12:10 PM, Isaac Dupree <[EMAIL PROTECTED]> wrote:
> And I wonder why (it sounds like) Git doesn't have tools to do some kind of
> smart cherrypicking, using a heuristic to decide which patches in a branch
> are definitely dependencies of the cherry-picked patch. In any cas
> If you have lots of local changes (e.g. the sorts of long-running branch
> that gives darcs 1 problems), then you need to use merge. If you use
> rebase then you might end up with lots of conflicts to manually resolve.
>
> Using merge gives you automatic merge commits, If you think these are
> ug
On Fri, Aug 15, 2008 at 04:24:12PM +0100, Ian Lynagh wrote:
> On Fri, Aug 15, 2008 at 05:09:55PM +0200, Thomas Schilling wrote:
> > On Fri, Aug 15, 2008 at 4:38 PM, Ian Lynagh <[EMAIL PROTECTED]> wrote:
> > > One way that it is worse is that you will get a lot more "automatic
> > > merge" commits w
On 16/08/2008, at 00:12, Ian Lynagh wrote:
On Fri, Aug 15, 2008 at 11:12:20AM +1000, Manuel M T Chakravarty
wrote:
Moreover, as I wrote a few times before, some reasons for switching
in
the first place are invalidated by not having the core libraries in
git, too. For example, one complain
On Fri, Aug 15, 2008 at 05:09:55PM +0200, Thomas Schilling wrote:
> On Fri, Aug 15, 2008 at 4:38 PM, Ian Lynagh <[EMAIL PROTECTED]> wrote:
> > One way that it is worse is that you will get a lot more "automatic
> > merge" commits when you pull changes from the central repo into a repo
> > in which
On Fri, Aug 15, 2008 at 4:38 PM, Ian Lynagh <[EMAIL PROTECTED]> wrote:
> One way that it is worse is that you will get a lot more "automatic
> merge" commits when you pull changes from the central repo into a repo
> in which you have local commits. I don't think that there is anything
> bad about t
On Fri, Aug 15, 2008 at 01:01:08PM +0100, Max Bolingbroke wrote:
> 2008/8/15 Isaac Dupree <[EMAIL PROTECTED]>:
> > So let's figure out how it would work (I have doubts too!) So, within the
> > directory that's a git repo (ghc), we have some other repos, git (testsuite)
> > and darcs (some libraries
On Fri, Aug 15, 2008 at 11:12:20AM +1000, Manuel M T Chakravarty wrote:
>
> Moreover, as I wrote a few times before, some reasons for switching in
> the first place are invalidated by not having the core libraries in
> git, too. For example, one complaint about darcs is that it either
> doe
2008/8/15 Isaac Dupree <[EMAIL PROTECTED]>:
> So let's figure out how it would work (I have doubts too!) So, within the
> directory that's a git repo (ghc), we have some other repos, git (testsuite)
> and darcs (some libraries). Does anyone know how git handles nested repos
> even natively?
You c
Manuel M T Chakravarty wrote:
Thomas Schilling:
Are you advocating for ease of use by new developers or for existing
developers? Current GHC hackers have to learn Git anyways and know
Darcs already. Library patches still have to be recorded separately,
so it would be a bit weird, but not much ha
Hi Manuel,
On Aug 14, 2008, at 9:12 PM, Manuel M T Chakravarty wrote:
Moreover, as I wrote a few times before, some reasons for switching
in the first place are invalidated by not having the core libraries
in git, too. For example, one complaint about darcs is that it
either doesn't buil
Thomas Schilling:
Are you advocating for ease of use by new developers or for existing
developers? Current GHC hackers have to learn Git anyways and know
Darcs already. Library patches still have to be recorded separately,
so it would be a bit weird, but not much harder, really.
I am arguing fo
Are you advocating for ease of use by new developers or for existing
developers? Current GHC hackers have to learn Git anyways and know
Darcs already. Library patches still have to be recorded separately,
so it would be a bit weird, but not much harder, really.
On Fri, Aug 15, 2008 at 1:59 AM, Man
Neil Mitchell:
If it really makes the life easier for people who are having lots of
VCS pain at the moment, then its hard to object. But many of the
comments in this discussion, about how everyone is going to flock to
GHC just as soon as it switches to Git, seem overly optimistic. I
think GHC is
Hi
> So I suggest we propose moving all the core packages to git, and we
> translate all those for which nobody objects to the change. For the others,
> we'll keep them in darcs and live with the pain.
Does this mean my (now the communities) FilePath library is going to
get moved over to git?
I
Iavor Diatchki wrote:
I also don't think that the darcs model has much to offer over git, in
fact I find that it lacks some useful features (not counting a
reliable implementation). Examples include good support for
branching, and being able to easily determine the version of the
software that i
Duncan Coutts wrote:
Turns out that the reason for slow darcs whatsnew is ghc bug #2093
http://hackage.haskell.org/trac/ghc/ticket/2093
because getSymbolicLinkStatus is broken on 32bit systems in 6.8.2 it
means that the 'stat' optimisation does not work so darcs has to read
the actual contents
Duncan Coutts:
On Mon, 2008-08-11 at 13:57 +0100, Simon Marlow wrote:
- Performance. darcs2 regressed in performance for many
operations we
commonly use. I've submitted some measurements for some things,
but
it's pretty easy to find your own test cases: things like "darcs
add",
On Wed, Aug 13, 2008 at 04:19:37PM +1000, Manuel M T Chakravarty wrote:
> Simon Marlow:
> >Manuel M T Chakravarty wrote:
> >>To be honest, if you ask me, I'd go back to the old makefile based
> >>system and remove Cabal from everywhere except building of the
> >>library packages.
> >
> >I would
On Wed, Aug 13, 2008 at 04:35:42PM +1000, Manuel M T Chakravarty wrote:
>
> Rebuilding with stage1 was already needed to build GHC with a builtin
> readline. In general, it is a bad idea to build distributed binaries
> of Haskell programs with the *bootstrap compiler*. It must be done
> wi
On Mon, 2008-08-11 at 13:57 +0100, Simon Marlow wrote:
> - Performance. darcs2 regressed in performance for many operations we
> commonly use. I've submitted some measurements for some things, but
> it's pretty easy to find your own test cases: things like "darcs add",
> "darcs what
On Wed, Aug 13, 2008 at 09:03:34AM +0100, Simon Marlow wrote:
> >Yes, it relies only on the Cabal metadata, but the output is a
> >Makefile only useful for building GHC.
>
> Ok, this statement is plainly not true, since I can use 'cabal makefile'
> to build any package outside of the GHC build tr
On Wed, Aug 13, 2008 at 1:54 AM, Malcolm Wallace <
[EMAIL PROTECTED]> wrote:
> Manuel wrote:
>
> | It is worth pointing out that I *never* validate against ghc head when
>>> | I commit to the core libraries.
>>>
>>
> Sorry, but I think the only reason its halfway acceptable is that Malcolm
>> di
Excerpts from Johan Tibell's message of Wed Aug 13 02:09:00 -0500 2008:
> I'm also in favor of the switch to Git. The Git model has proved to be
> both more productive and more reliable. And the interface, as far as
> I'm concerned, is *better*.
>
Seconded. The git documentation these days I find
On Wed, Aug 13, 2008 at 3:13 PM, Malcolm Wallace
<[EMAIL PROTECTED]> wrote:
>> I think an even better analogy is probably comparing it to developer
>> of GCC changing the libc implementation of another compiler or vice
>> versa.
>
> Our shared libraries do not belong to any one compiler. They are
> I think an even better analogy is probably comparing it to developer
> of GCC changing the libc implementation of another compiler or vice
> versa.
Our shared libraries do not belong to any one compiler. They are joint
creations, with a lot of community (non-compiler-hacker) involvement.
Regar
Hello Johan,
Wednesday, August 13, 2008, 3:43:15 PM, you wrote:
>>> - Why does NHC98 break so often? Is it because people are checking in
>>> code that is not Haskell 98 compatible?
> Can we make sure that these libraries are always built with some
> Haskell 98 compatibility flag by GHC so peopl
On Wed, Aug 13, 2008 at 1:52 PM, Malcolm Wallace
<[EMAIL PROTECTED]> wrote:
>> I don't think that is the right policy. Everybody (including Malcolm)
>> should validate.
>>
>> If you contribute code to the linux kernel, comprehensive testing of
>> the code is a requirement, too.
>
> The analogy is
> I don't think that is the right policy. Everybody (including Malcolm)
> should validate.
>
> If you contribute code to the linux kernel, comprehensive testing of
> the code is a requirement, too.
The analogy is flawed. It is like asking the developers of _gcc_ to
ensure that the Linux kerne
On Wed, 2008-08-13 at 16:19 +1000, Manuel M T Chakravarty wrote:
> In a sense, it was an interesting experiment and it should still be
> useful to the development of Cabal. In fact, I see no reason why the
> experiment cannot be continued on a branch. Who knows, maybe Cabal is
> sufficient
On Wed, Aug 13, 2008 at 12:21 PM, Malcolm Wallace
<[EMAIL PROTECTED]> wrote:
>> - Why does NHC98 break so often? Is it because people are checking in
>> code that is not Haskell 98 compatible?
>
> Yes, there is a bit of that. Also, as you point out, there is quite a lot
> of CPP conditionally comp
- Why does NHC98 break so often? Is it because people are checking in
code that is not Haskell 98 compatible?
Yes, there is a bit of that. Also, as you point out, there is quite a
lot of CPP conditionally compiled code in the libraries, and I would
say that it is the major contributor to br
Claus Reinke wrote:
Perhaps it would be useful for GHC HQ to have a GHC project
blog,
Actually we have talked about doing that, and it's highly likely we'll set
one up in due course. I think it's worth letting the current discussion(s)
run their course and then we'll have a set of concrete
As someone who is not contributing to the core libraries I find a few
things in this discussions a bit puzzlng.
- Why does NHC98 break so often? Is it because people are checking in
code that is not Haskell 98 compatible?
- It seems to me that implementations "share" libraries using CPP. At
least
We (GHC HQ) are still learning the transition to wider participation
in building and hacking on GHC, which we *very much* welcome. Bear
with us if we don't get it right first time. We're trying!
And I very much like the steps I've seen recently in explaining
what you're doing (sometimes even b
Manuel wrote:
| It is worth pointing out that I *never* validate against ghc head
when
| I commit to the core libraries.
Sorry, but I think the only reason its halfway acceptable is that
Malcolm didn't break the GHC build yet. If he does, I'll be
screaming as loudly as for anybody else.
Matthias Kilian wrote:
I mean the GHC-specific template used for building the Makefile
(Distribution/Simple/GHC/Makefile.in) and the function `makefile`
in Distribution/Simple/GHC.hs (this function even spills out some
some make rules in addition to what's in Makefile.in, which looks
very wrong
Norman Ramsey wrote:
I also see repeatedly that the distinction between the build system
and packaging system is blurry: both have to know about build targets,
dependencies, and so on.
At the time of the wonderful GHC Hackathon in Portland, where the GHC
API was first introduced to the public,
Manuel M T Chakravarty wrote:
Everybody who contributes to the boot/core libraries needs to validate
their patches. If the GHC version of the libraries is in git, then all
library code needs to be validated against the git version of the
libraries before it can enter the master repository. I
| FWIW, I started a wiki page that tries a direct comparison between
| Darcs and Git:
|
|http://hackage.haskell.org/trac/ghc/wiki/GitForDarcsUsers
Very helpful thank you!
Simon
___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.or
On Wed, Aug 13, 2008 at 2:49 AM, Manuel M T Chakravarty
<[EMAIL PROTECTED]> wrote:
> Ian, I completely agree with you. I love the darcs vcs model, too.
> However, we have three discussions here:
>
> (1) Do we want darcs vcs model?
>
>Except Thomas Schilling, who seems to be dead set to get ri
Simon Peyton-Jones:
2. The version control system (VCS)
GHC needs "core libraries" without which it cannot be built. It is
obviously highly desirable that a developer can build GHC with just
one VCS, which suggests that the core libraries should be in git too.
But those same core libraries are
Ian Lynagh:
On Tue, Aug 12, 2008 at 10:20:14AM +1000, Manuel M T Chakravarty
wrote:
To be honest, if you ask me, I'd go back to the old makefile based
system and remove Cabal from everywhere except building of the
library
packages.
Manuel
PS: Just for some more collateral damage. Did any
Simon Marlow:
Manuel M T Chakravarty wrote:
To be honest, if you ask me, I'd go back to the old makefile based
system and remove Cabal from everywhere except building of the
library packages.
I wouldn't object to dropping the use of Cabal for other tools in
the build tree; the reasons for
Hello Manuel,
Wednesday, August 13, 2008, 4:39:25 AM, you wrote:
> Well, its up to you whether you want to validate for other people, but
> I don't think that is the right policy. Everybody (including Malcolm)
> should validate.
as far as we have people validating patches for their platforms (I
Hello,
On Tue, Aug 12, 2008 at 5:49 PM, Manuel M T Chakravarty
<[EMAIL PROTECTED]> wrote:
> Ian, I completely agree with you. I love the darcs vcs model, too.
> However, we have three discussions here:
>
> (1) Do we want darcs vcs model?
>
>Except Thomas Schilling, who seems to be dead set t
cs has (in my opinion, at least) a much simpler, more intuitive
interface than the other version control systems. I don't think I'm
alone here, as I think this is where a lot of the resistance against
moving to git is coming from.
* I think darcs is the Obvious, Right way to do version
Ian Lynagh:
On Tue, Aug 12, 2008 at 10:10:31AM +0100, Malcolm Wallace wrote:
On 12 Aug 2008, at 01:35, Manuel M T Chakravarty wrote:
Ah, good point! Changing ghc to git means *all* developers of boot
libraries need to use git *regardless* of what repo format the boot
libraries are in. After
Simon Peyton-Jones:
| It is worth pointing out that I *never* validate against ghc head
when
| I commit to the core libraries.
I think that's perfectly reasonable for the reasons you explain.
Sorry, but I think the only reason its halfway acceptable is that
Malcolm didn't break the GHC bui
On Tue, Aug 12, 2008 at 10:29:03PM +0200, Matthias Kilian wrote:
> Basically, the .cabal file is just converted into some other format
> that may be included by another Makefile.
Oops! I again read your (SimonM's) proposal on changing Cabal and
the GHC build system in exactly this way. Sorry for t
On Tue, Aug 12, 2008 at 11:59:37AM +0100, Simon Marlow wrote:
> >Well, at least the Makefile creation was a step (the first step?)
> >into the wrong direction, IMHO. I'll run a GHC build to get some
> >of those generated Makefiles and followup on cvs-ghc, but for a
> >starter, Cabal shouldn't know
Norman Ramsey wrote:
> At the time of the wonderful GHC Hackathon in Portland, where the GHC
> API was first introduced to the public, I urged Simon PJ to consider
> taking ghc --make and generalising it to support other languages.
> I still think this would be a good project.
>
As well as suppor
Thomas Schilling wrote:
I encourage everyone to add useful tips and examples both from users who
already use Git and later on, once we have gathered more experience. I
believe that Git has some features which can improve our productivity
and I'd like this page to also collect tips how to do so
> > I see an increasing problem in that every community comes up with
> > their own package system, instead of reusing existing frameworks.
>
> That's because there are no usable existing frameworks.
I couldn't agree more. I have been working on this problem off and on
since 1993, and the
On 12 Aug 2008, at 15:46, Simon Peyton-Jones wrote:
It's unclear exactly what to do about this. The most plausible
possibility is to keep the core libraries that are shared with other
implementations in darcs as now, and mirror them in git for GHC
developers. That will impose pain on GHC deve
Hello Simon,
Tuesday, August 12, 2008, 5:46:59 PM, you wrote:
> GHC needs "core libraries" without which it cannot be built. It is
> obviously highly desirable that a developer can build GHC with just
> one VCS, which suggests that the core libraries should be in git too.
> But those same core l
A metacomment:
As a lurker, and a reader of other languages' mail groups, I just wanted to
complement you GHC folks on the quality of your discussion. You're discussing
an issue that people clearly have strong opinions about, yet you've all
remained polite and respectful and kept the signal-to
Friends
| > I see more and more workarounds for workarounds for an unmaintainable
| > (and unusable) build system, and after the latest discussions about
| > git vs. darcs, maintaining GHC-specific branches of libraries etc.,
| > I think I'll just drop maintainership from all GHC-related OpenBSD
|
On Tue, Aug 12, 2008 at 10:20:14AM +1000, Manuel M T Chakravarty wrote:
>
> To be honest, if you ask me, I'd go back to the old makefile based
> system and remove Cabal from everywhere except building of the library
> packages.
>
> Manuel
>
> PS: Just for some more collateral damage. Did an
On Mon, 2008-08-11 at 14:29 +0200, Thomas Schilling wrote:
> On 11 Aug 2008, at 13:00, Duncan Coutts wrote:
> > It's not clear to me that we've really bothered to find out. The last
> > evaluation in relation to ghc that I'm aware of was prior to the 2.0
> > release. My impression is that we've all
On Tue, Aug 12, 2008 at 10:10:31AM +0100, Malcolm Wallace wrote:
>
> On 12 Aug 2008, at 01:35, Manuel M T Chakravarty wrote:
> >Ah, good point! Changing ghc to git means *all* developers of boot
> >libraries need to use git *regardless* of what repo format the boot
> >libraries are in. After
be good
for the community's image.
* darcs has (in my opinion, at least) a much simpler, more intuitive
interface than the other version control systems. I don't think I'm
alone here, as I think this is where a lot of the resistance against
moving to git is coming from.
* I
Matthias Kilian wrote:
On Mon, Aug 11, 2008 at 04:17:59PM +0100, Simon Marlow wrote:
[...]
As for Cabal - we had a thread on cvs-ghc last week, and as I said there
we'd love to hear suggestions for how to improve things, including wild
and crazy ideas for throwing it all away and starting again
| It is worth pointing out that I *never* validate against ghc head when
| I commit to the core libraries.
I think that's perfectly reasonable for the reasons you explain.
Simon
___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
ht
On 12 Aug 2008, at 01:35, Manuel M T Chakravarty wrote:
Ah, good point! Changing ghc to git means *all* developers of boot
libraries need to use git *regardless* of what repo format the boot
libraries are in. After all, they need to validate against the
current ghc head before pushing.
On Tue, Aug 12, 2008 at 2:46 AM, Manuel M T Chakravarty
<[EMAIL PROTECTED]> wrote:
> Ian Lynagh:
> Having two vcs for one project is bad. One reason to switch to git (I am
> told) is that people had problems with darcs on some platforms (windows and
> Solaris, for example). How is that going to b
Manuel M T Chakravarty wrote:
As far as I am concerned, building GHC is turning into a big mess. We
discussed ways to improve it again, BUT I'd rather not see it getting
any messier before it gets better. Hence, please let's have a complete
plan that we are convinced will work before making
> "Manuel" == Manuel M T Chakravarty <[EMAIL PROTECTED]> writes:
Manuel> In other words, the decision to move the ghc repo affects all
Manuel> core library developers anyway. No use pretenting that changing
Manuel> only the ghc repo (and leaving the rest in darcs) would make
Manuel> anything
Hello,
On Mon, Aug 11, 2008 at 8:20 PM, Manuel M T Chakravarty <
[EMAIL PROTECTED]> wrote:
> Simon Marlow:
>
>> Manuel M T Chakravarty wrote:
>>
>> I think all *core* libraries must switch. Seriously, requiring GHC
>>> developer to use a mix of two vcs during development is a Very Bad Idea.
>>>
On Tue, 2008-08-12 at 01:15 +0200, Johan Henriksson wrote:
> I see an increasing problem in that every community comes up with
> their own package system, instead of reusing existing frameworks.
That's because there are no usable existing frameworks. It would be
wonderful of course if there were
Ian Lynagh:
Even the current situation with Cabal is a bit of a pain, as it's easy
to forget to push patches upstream as well as GHC's repo, and that's
just with 2 repos of the same VCS.
As I said before, IMHO it is a big mistake for ghc to depend on
development versions of Cabal. GHC should
Ross Paterson:
On Mon, Aug 11, 2008 at 04:17:59PM +0100, Simon Marlow wrote:
The main obstacle with just switching the core libraries is that they
are shared by other implementations and other maintainers. So I
see no
alternative but to create forks of those repositories for use by GHC,
unle
Simon Marlow:
Manuel M T Chakravarty wrote:
I think all *core* libraries must switch. Seriously, requiring GHC
developer to use a mix of two vcs during development is a Very Bad
Idea. Don was excited about getting more people to look at the
source when it is in git (see the comments he p
1 - 100 of 162 matches
Mail list logo
