Version control systems

[Ian Lynagh]

On Sat, Aug 09, 2008 at 09:30:52PM +0100, Malcolm Wallace wrote:
>
> The libraries question is a difficult one.  We have made a lot of  
> effort over the last 5 years to build infrastructure and code that is  
> shared and portable across multiple implementations of the language.  
> Is this the time to fork those supposedly "common" core libraries into  
> ghc versions vs the rest?

I think the non-GHC implementations have been struggling for development
time as it is. As you say, we've been trying to increase the amount of
shared code, to reduce the burden on them. I think forking the bootlibs
would represent a huge step the other way, and, as you said later in
your e-mail, may be what finally kills them off.


Thanks
Ian

_______________________________________________
Glasgow-haskell-users mailing list
Glasgow-haskell-users@...
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users

[Thomas Schilling-2]

I had my share of problems with Darcs;  working on the GHC API I  
constantly have to avoid conflicts.  My temporary workaround is to  
not update at all.  Maybe switching to Darcs 2 format would help  
here, but there are other issues.

I initially converted GHC to Git to be able to more easily checkout  
older versions (e.g., to find a build bug using git-bisect) but with  
external core libraries this just doesn't work.  Right now, there is  
simply no practical way to check out an old, building version of GHC!

Even if we'd switch to Darcs 2 this problem could not be solved.  We  
would also still need turn to the Git repo to get change histories  
for specific files or to run commands such as 'git-blame' (unless you  
don't mind getting a cup of coffee and some biscuits each time you  
run those commands).

I think we can make things easier for existing library contributors  
by providing a darcs/git cheat sheet or even a command line wrapper.  
Previous attempts at creating such a wrapper have been abandoned,  
possibly because some commands cannot easily be modelled in Git.  
However, if we accept some limitations this is doable.  In particular  
the tricky commands are:

   darcs pull  -- (save) cherry picking requires patch dependency  
information
   darcs push  -- same as above

   (darcs pull -a  and  darcs push -a  both can be modelled easily)

   darcs replace  -- not directly supported in Git, but could be  
modelled
                  -- with a script.

If these missing features don't feel like too big a handicap the  
change should be fairly easy for existing contributors.  (And with  
some time they can start and learn Git's other features.)

For our build woes integrating the libraries and the main GHC repo in  
one Git repo will be very helpful, since we can now just instruct  
build bots to try and build revision 12345deadbeef and be happy.

/ Thomas
--
My shadow / Change is coming. / Now is my time. / Listen to my muscle  
memory. / Contemplate what I've been clinging to. / Forty-six and two  
ahead of me.






_______________________________________________
Glasgow-haskell-users mailing list
Glasgow-haskell-users@...
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users

[Iavor Diatchki]

Hello,
I think that we should switch the repositories of the core libraries
to git too, not just because GHC is switching, but simply because git
is a more reliable RCS.  It seems that this does not prevent other
implementations from using them---the code in the repositories will be
still the same!
-Iavor
_______________________________________________
Glasgow-haskell-users mailing list
Glasgow-haskell-users@...
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users

[Norman Ramsey]

 > On Sat, Aug 09, 2008 at 06:56:23PM -0400, Norman Ramsey wrote:
 > >
 > >   * Our long-term goal should be to get the *entire* Haskell
 > >     development community to agree on a version-control system---one
 > >     that is not darcs.  We should expect this process to take several
 > >     years, and we should expect it to cost money.  Would Microsoft or
 > >     Galois or York or other large players be willing to donate part of
 > >     an expert's time to migrate to the new version-control system?
 >
 > It is, of course, up to people with money what they spend it on, but
 > personally I would much prefer to see money spent on making darcs
 > better, for reasons I won't repeat again.

I missed them and wouldn't mind receiving a private note.

For the last year I have been hoping to make 'a new darcs-like thing,
with a real theory founding it' an important part (one of three) of a
grant proposal in distributed computing.  So you can see I am in favor
of spending money to create a better darcs (which is not quite the
same thing as making darcs better; I want to start with a new theory).

But I am having second thoughts because I think by the time a proposal
reaches a review committee, git may be so firmly entrenched (worse is
better) that the work would be considered not worth funding.

I realize that I am now firmly off topic, but if people here have
opinions, I would be grateful to receive them (perhaps off-list).


Norman
_______________________________________________
Glasgow-haskell-users mailing list
Glasgow-haskell-users@...
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users

[Brandon S. Allbery KF8NH]

On 2008 Aug 10, at 20:17, Norman Ramsey wrote:

>> For the last year I have been hoping to make 'a new darcs-like thing,
> with a real theory founding it' an important part (one of three) of a
> grant proposal in distributed computing.  So you can see I am in favor
> of spending money to create a better darcs (which is not quite the
> same thing as making darcs better; I want to start with a new theory).

Can you elucidate what's wrong with the current one?

--
brandon s. allbery [solaris,freebsd,perl,pugs,haskell] allbery@...
system administrator [openafs,heimdal,too many hats] allbery@...
electrical and computer engineering, carnegie mellon university    KF8NH


_______________________________________________
Glasgow-haskell-users mailing list
Glasgow-haskell-users@...
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users

[Manuel M T Chakravarty]

Ian Lynagh:

> On Sun, Aug 10, 2008 at 02:16:25PM +1000, Manuel M T Chakravarty  
> wrote:
>> Duncan Coutts:
>>>
>>> I don't especially relish having to learn another vcs tool or  
>>> raising
>>> the bar for contributions to Cabal either (we have lots of people  
>>> who
>>> make small one-off contributions).
>>
>> I don't think it matters what vcs Cabal uses.  GHC does already for a
>> while use a separate repo for its version of Cabal, and the GHC Cabal
>> repo needs to be explicitly updated to ensure that changes to Cabal  
>> do
>> not randomly break GHC.  To be honest, if I had to say anything, I
>> would say that GHC has to uses fixed, stable versions of Cabal (like
>> it does of gmp).  So, it really doesn't matter what vcs Cabal uses.
>
> Unless we do get to a point where we are literally using tarballs[1]  
> of
> Cabal, I don't think using a mixture of VCSs for Cabal is a good idea.
> Having to convert patches from one VCS format to the other sounds  
> like a
> recipe for a lot of pain and suffering.
>
> [1] which I think is a bad idea anyway, as it makes it a lot more  
> hassle
> to fix Cabal bugs that GHC+bootlibs expose.

The hassle that having two different repo types for Cabal head and  
Cabal GHC is part of the price of switching from darcs to git for  
ghc.  Incidentally, that you are concerned about Cabal devel in the  
GHC tree is a consequence out of using GHC as a guinea pig for Cabal  
development, which by itself is IMHO a Very Bad Idea.  Cabal is  
supposed to be a tool like Happy or Alex.  If Cabal *were* mature  
enough to be used in GHC's build system in the way it is now, GHC  
would just use the latest stable release of Cabal and we wouldn't have  
a problem.

So, let's please not use one bad idea (using an immature and  
constantly changing build tool whose use in GHC's build tree barely  
anybody understands) to justify another bad idea (using two vcs for  
one project).

Manuel

_______________________________________________
Glasgow-haskell-users mailing list
Glasgow-haskell-users@...
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users

[Manuel M T Chakravarty]

Thomas Schilling:
> I had my share of problems with Darcs;  working on the GHC API I  
> constantly have to avoid conflicts.  My temporary workaround is to  
> not update at all.  Maybe switching to Darcs 2 format would help  
> here, but there are other issues.
>
> I initially converted GHC to Git to be able to more easily checkout  
> older versions (e.g., to find a build bug using git-bisect) but with  
> external core libraries this just doesn't work.  Right now, there is  
> simply no practical way to check out an old, building version of GHC!

Correct me if I am wrong, but this sounds as if you support my point  
that switching the GHC repo to git without doing the same for the core  
libs (in an integrated way) would not address the problems you  
experienced with darcs.

Manuel

_______________________________________________
Glasgow-haskell-users mailing list
Glasgow-haskell-users@...
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users

[Sittampalam, Ganesh]

Brandon S Allbery wrote:

> On 2008 Aug 10, at 20:17, Norman Ramsey wrote:

> > For the last year I have been hoping to make 'a new darcs-like
thing,
> > with a real theory founding it' an important part (one of three) of
a
> > grant proposal in distributed computing.  So you can see I am in
favor
> > of spending money to create a better darcs (which is not quite the
> > same thing as making darcs better; I want to start with a new
theory).

> Can you elucidate what's wrong with the current one?

Noone knows how to formalise it, and (AFAIK) only David understands the
new conflicts handling, and hasn't managed to completely communicate
that understanding to anyone else.

Ganesh

==============================================================================
Please access the attached hyperlink for an important electronic communications disclaimer:

http://www.credit-suisse.com/legal/en/disclaimer_email_ib.html
==============================================================================

_______________________________________________
Glasgow-haskell-users mailing list
Glasgow-haskell-users@...
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users

[Thomas Schilling-2]

On 11 Aug 2008, at 05:38, Manuel M T Chakravarty wrote:
> Correct me if I am wrong, but this sounds as if you support my  
> point that switching the GHC repo to git without doing the same for  
> the core libs (in an integrated way) would not address the problems  
> you experienced with darcs.

Partly.  It does address some issues (fear of conflict, speed, case-
sensitivity bugs, easier branches).  I personally wouldn't mind  
having both Darcs and Git repositories, although I can understand why  
having a mixture of both is bad.  I was just mentioning some other  
advantages of also having the libraries in Git.

However, I think that it would be really disappointing if we would  
not move to Git for the main GHC repository.  Simon M reported that a  
merge took him over a whole day, Norman reported two weeks of lost  
work, Don reported corrupted repos, Simon PJ reported that in order  
to avoid conflicts he constantly unrecords and re-records one big  
patch;  all that doesn't give much confidence in Darcs.  
Additionally, no-one except David seems to actually understand Darcs'  
theory (and we don't even know if David actually does.)  Darcs 2  
claims to fix those problems, but I don't know how many are actually  
using it.  Darcs 1 had the exponential runtime bug and it wasn't  
discovered right away.  I don't believe that Darcs 2 can fulfil GHC's  
needs anytime soon, especially since it is always a bad idea to use a  
brand-new release of a not much used VCS.

(I am also no longer convinced that Darcs' automatic patch dependency  
calculations are actually a good idea.  Just because two patches  
don't touch the same files, doesn't mean they aren't semantically  
dependent.  Take for example "monadification" patches, which are  
typically submitted split up for each file.  A branch captures those  
dependencies just fine.)

/ Thomas
--
Push the envelope.  Watch it bend.





_______________________________________________
Glasgow-haskell-users mailing list
Glasgow-haskell-users@...
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users

[Sittampalam, Ganesh]

Thomas Schilling wrote:

> (I am also no longer convinced that Darcs'
> automatic patch dependency calculations are
> actually a good idea.  Just because two patches
> don't touch the same files, doesn't mean they
> aren't semantically dependent.  Take for
> example "monadification" patches, which are
> typically submitted split up for each file.
> A branch captures those dependencies just fine.)

But the darcs approach to dependency is what underlies cherry-picking,
which many people consider the most worthwhile feature of darcs. In fact
many people would like it to be possible to override even the
dependencies that darcs *does* find to cherry-pick patch A without patch
B that A depends on, at the expense of producing a conflict that then
has to be fixed up by hand.

Ganesh

==============================================================================
Please access the attached hyperlink for an important electronic communications disclaimer:

http://www.credit-suisse.com/legal/en/disclaimer_email_ib.html
==============================================================================

_______________________________________________
Glasgow-haskell-users mailing list
Glasgow-haskell-users@...
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users

[Duncan Coutts]

On Mon, 2008-08-11 at 12:21 +0200, Thomas Schilling wrote:

> However, I think that it would be really disappointing if we would  
> not move to Git for the main GHC repository.  Simon M reported that a  
> merge took him over a whole day, Norman reported two weeks of lost  
> work, Don reported corrupted repos, Simon PJ reported that in order  
> to avoid conflicts he constantly unrecords and re-records one big  
> patch;  all that doesn't give much confidence in Darcs.

We all accept there are problems with darcs v1 and the darcs v1 repo
format for larger projects that do lots of development in branches and
then merge back.

> Additionally, no-one except David seems to actually understand Darcs'  
> theory (and we don't even know if David actually does.)  Darcs 2  
> claims to fix those problems, but I don't know how many are actually  
> using it.

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 complained about the darcs v1
problems (justly) but spent the most effort investigating things other
than darcs v2 which would be the easiest to upgrade to and not have the
problems of using two different systems for ghc vs other libs.

On a slightly related issue, we're currently evaluating upgrading to
darcs 2 for code.h.o. We'll let people know how that goes. It's not
directly relevant to ghc since we'd not be switching to darcs v2 format
(that's the prerogative of the repo owners, not code.h.o admins).

Duncan

_______________________________________________
Glasgow-haskell-users mailing list
Glasgow-haskell-users@...
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users

[Thomas Schilling-2]

On 11 Aug 2008, at 12:38, Sittampalam, Ganesh wrote:

> Thomas Schilling wrote:
>
>> (I am also no longer convinced that Darcs'
>> automatic patch dependency calculations are
>> actually a good idea.  Just because two patches
>> don't touch the same files, doesn't mean they
>> aren't semantically dependent.  Take for
>> example "monadification" patches, which are
>> typically submitted split up for each file.
>> A branch captures those dependencies just fine.)
>
> But the darcs approach to dependency is what underlies cherry-picking,
> which many people consider the most worthwhile feature of darcs. In  
> fact
> many people would like it to be possible to override even the
> dependencies that darcs *does* find to cherry-pick patch A without  
> patch
> B that A depends on, at the expense of producing a conflict that then
> has to be fixed up by hand.

Cherry-picking just a single patch is simple in Git: "git cherry-pick  
<commit-id>"[1].
What's missing in Git is the automatic detection of dependent  
patches.  Otherwise it would be straightforward to write a Darcs  
frontend for Git.


[1]: http://www.kernel.org/pub/software/scm/git/docs/git-cherry- 
pick.html

/ Thomas
--
Push the envelope.  Watch it bend.





_______________________________________________
Glasgow-haskell-users mailing list
Glasgow-haskell-users@...
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users

[Thomas Schilling-2]

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 complained about the darcs v1
> problems (justly) but spent the most effort investigating things other
> than darcs v2 which would be the easiest to upgrade to and not have  
> the
> problems of using two different systems for ghc vs other libs.

I converted the ghc repo to darcs2 (locally):

Getting file local history:

  * darcs changes --last 20 compiler/main/HscTypes.lhs

    very quick but prints only two patches

  * darcs changes compiler/hsSyn/HsTypes.lhs

    1m22s  (16s for the second time)

    Git <1s

  * darcs get ghc2  ghc-test  (creating a *local* branch)

    real    13m25.365s
    user    0m14.677s
    sys     0m29.541s

    (at least it seems it actually worked, though)

    git clone ghc g2  (the slow method of creating a local branch)

    real    0m6.742s
    user    0m0.335s
    sys     0m0.652s

  * I haven't tested a remote pull yet.  At 80 Kb/s, it should take  
about 15min to clone via Git (70 MB).  A test of darcs would be  
interesting.

Finally, of course, we have to hope that Darcs2's conflict problems  
are actually solved.  I also had some weird automerges with Darcs  
when pulling from Max' repository, so Darcs isn't flawless there,  
either (this seemed to be one of the main critiques of Git).

/ Thomas
--
Awareness is the enemy of sanity, for once you hear the screaming, it  
never stops.



_______________________________________________
Glasgow-haskell-users mailing list
Glasgow-haskell-users@...
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users

[Sittampalam, Ganesh]

 

-----Original Message-----
From: Thomas Schilling [mailto:nominolo@...]
Sent: 11 August 2008 12:18
To: Sittampalam, Ganesh
Cc: Manuel Chakravarty; Don Stewart; Ian Lynagh; Simon Peyton-Jones; GHC
Users Mailing List
Subject: Re: Version control systems

Thomas Schilling wrote:

> On 11 Aug 2008, at 12:38, Sittampalam, Ganesh wrote:

>> Thomas Schilling wrote:
>>
>>> (I am also no longer convinced that Darcs'
>>> automatic patch dependency calculations are actually a good idea.  
>>> Just because two patches don't touch the same files, doesn't mean
>>> they aren't semantically dependent.  Take for example
>>> "monadification" patches, which are typically submitted split up for

>>> each file.
>>> A branch captures those dependencies just fine.)
>>
>> But the darcs approach to dependency is what underlies
cherry-picking,
>> which many people consider the most worthwhile feature of darcs. In
>> fact many people would like it to be possible to override even the
>> dependencies that darcs *does* find to cherry-pick patch A without
>> patch B that A depends on, at the expense of producing a conflict
that
>> then has to be fixed up by hand.

> Cherry-picking just a single patch is simple in Git: "git cherry-pick
<commit-id>"[1].

I wasn't saying that Git doesn't support cherry-picking, just that you
would expect dependencies to restrict what you can and can't
cherry-pick; if you specify dependencies just in a linear fashion along
each branch (i.e. each patch depends on all those before it on that
branch) as I thought you were suggesting, then you enormously restrict
what cherry-picks are possible.

Ganesh

==============================================================================
Please access the attached hyperlink for an important electronic communications disclaimer:

http://www.credit-suisse.com/legal/en/disclaimer_email_ib.html
==============================================================================

_______________________________________________
Glasgow-haskell-users mailing list
Glasgow-haskell-users@...
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users

[Simon Marlow-7]

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 complained about the darcs v1
> problems (justly) but spent the most effort investigating things other
> than darcs v2 which would be the easiest to upgrade to and not have the
> problems of using two different systems for ghc vs other libs.

I promised to put together our reasoning on why we don't think moving to
darcs2 would help enough.  Here's a summary:

  - using the darcs2 format may well fix the exponential-time merge problem,
    but the UI for merging conflicts is still lacking in many important ways
    in darcs:

    * The conflict markers are not annotated with the patch that they came
      from, and the ordering of patches in conflict markers is
      non-deterministic (when I asked about this problem, I was told it was
      hard to fix).

    * The 'darcs changes' output only shows one of the patches that is
      conflicting, you have to guess at the other one(s).  Also, it doesn't
      show which patches are conflict resolutions.

  - 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 whatsnew", "darcs unrecord" are all slower than darcs 1.  When
    simple operations take multiple seconds to complete, it really slows
    down your workflow.

  - I still can't use 'darcs annotate' because it's too slow.  Also, we
    can't browse the GHC repository on the web because the web interface
    wants to do 'darcs changes <file>', and that takes minutes.  It's
    possible with caching, but you still have to regenerate the cache
    after a change.

  - why can I do a complete git clone of a remote GHC repo in a few minutes,
    but it takes hours to do a complete 'darcs get'?

  - Bugs.  Many bugs have been fixed in darcs2, which is great, but we
    did already encounter one (hard to reproduce) bug on Windows,
    when trying to get an up-to-date repo.  Perhaps bugs will be less of
    an issue in the future, but we have had painful experiences
    particularly on Windows and I know the darcs developers are still
    not actively testing on Windows.


FWIW, I'd also like to stay with darcs because it has the right model, but
unfortunately the current implementation is not useable for us, and it's
holding us back.

I'll say something about core libs in a separate mail.

Cheers,
        Simon
_______________________________________________
Glasgow-haskell-users mailing list
Glasgow-haskell-users@...
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users

[Simon Marlow-7]

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 posted from reddit).  By
> requiring two vcs you will get *less* people to look at the source.
>
> This is not only to get the sources to hack them, but you effectively
> require developers to learn the commands for two vcs (when they are
> already reluctant to learn one).  For example, often enough somebody who
> changes something in GHC will modify the base package, too.  Then, to
> commit the overall work, you need to commit using both vcs.  If you need
> to branch for your work, you need to create branches in two vcs (no idea
> whether the semantics of a branch in git and darcs is anywhere
> similar).  When you merge your branch, you need to merge in both vcs.  
> You can't seriously propose such a set up!

I completely agree this is a problem.  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, unless/until the other
projects/maintainers want to migrate to git.  Some of the repositories are
not shared - for example ghc-prim, integer-gmp, template-haskell, and these
don't need to be forked.

One way we could create the forks would be to create a git repo for each
package with two branches: the master branch that GHC builds, and a
separate branch that tracks the main darcs repository, and is synced
automatically whenever patches are pushed to the main darcs repo.  We'd
have to explicitly merge the tracking branch into the master branch from
time to time.  When we want to make changes locally, we can just commit
them to the GHC branch and push the changes upstream in a batch later (and
then we'd end up having to merge them back in to the GHC branch... but
hopefully git's merge is clever enough to avoid manual intervention here).
  This is complicated and ugly of course; better suggestions welcome.

> I *strongly* object to moving to git before this isn't sorted out.  As
> Roman said before, GHC is heading into a dangerous direction.  It gets
> progressively harder to contribute to the project at the moment.  First,
> changing the build system to Cabal.  Now, proposing to use two vcs.  
> Somebody who is new to the project not only has to learn the internals
> of GHC, but they also have to learn two new vcs, and if they need to
> change the build system, they need to learn a new build tool.  Raising
> the bar for developers to contribute to a project has been proven to be
> a very bad idea many times.  Let's not take GHC down that path.

I'm not completely convinced we need to have this all worked out before GHC
switches, although it would be nice of course.  We currently have
infastructure in place for the build to work with a mixture of darcs and
git repositories, and existing developers already have to learn git anyway.
  They just need to remember to use darcs for libraries and git for the
main GHC repo, and this is only a temporary situation.


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.  However, as I
explained, there are good reasons for the way things are done now, the main
one being that the build system for packages is not written twice.

Cheers,
        Simon
_______________________________________________
Glasgow-haskell-users mailing list
Glasgow-haskell-users@...
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users

[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,
> unless/until the other projects/maintainers want to migrate to git.

Forking is much worse than using multiple vcs's, and if we don't fork,
anyone working on those libraries will have to use git at least to get GHC
HEAD to check that they're not breaking it.  And clearly GHC developers
outnumber developers of other implementations.  (I don't think a move
to git will lead to more GHC developers, but I buy the interns argument.)

My concern is that there are rather more developers of libraries and
assorted other packages, and this will place an arbitrary divide across
those.  Unless everyone moves to git, of course.
_______________________________________________
Glasgow-haskell-users mailing list
Glasgow-haskell-users@...
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users

[Jason Dagit-2]

2008/8/11 Thomas Schilling <nominolo@...>

(I am also no longer convinced that Darcs' automatic patch dependency calculations are actually a good idea.  Just because two patches don't touch the same files, doesn't mean they aren't semantically dependent.  Take for example "monadification" patches, which are typically submitted split up for each file.  A branch captures those dependencies just fine.)

Darcs has a feature to deal with patches that are unrelated in patch theory but are related from the user's point of view.  When you record you can use --ask-deps to specify dependent patches.  These dependencies are then artificially enforced in commute (where dependencies are normally detected).

Note: I'm not trying to advocate anything here, I just wanted to let you know that others noticed this and added a feature for it long ago.

Jason

_______________________________________________
Glasgow-haskell-users mailing list
Glasgow-haskell-users@...
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users

[Matthias Kilian]

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.  However, as
> I explained, there are good reasons for the way things are done now, the
> main one being that the build system for packages is not written twice.

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 anything about implementation-specific
internal build systems; instead it should rely only on it's own
metadata.  Implementation-specific stuff (such as how to run the
compiler) should be supplied by the implementation, not by Cabal.

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
ports until the GHC build system chaos settles down a little bit.

Ciao,
        Kili
_______________________________________________
Glasgow-haskell-users mailing list
Glasgow-haskell-users@...
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users

[Don Stewart-2]

kili:

> 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.  However, as
> > I explained, there are good reasons for the way things are done now, the
> > main one being that the build system for packages is not written twice.
>
> 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 anything about implementation-specific
> internal build systems; instead it should rely only on it's own
> metadata.  Implementation-specific stuff (such as how to run the
> compiler) should be supplied by the implementation, not by Cabal.
>
> 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
> ports until the GHC build system chaos settles down a little bit.

Ian, please read this.
The inability to build GHC reliably is a problem.

Can someone with a plan please describe what measures are in place
to ensure GHC emerges buildable, and the tree regains the status of a
tree that *does not break*?

-- Don
_______________________________________________
Glasgow-haskell-users mailing list
Glasgow-haskell-users@...
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users