Version control systems

[Malcolm Wallace]

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.

Whilst I'm in no way saying that a working nhc98 head is anything like  
as important as a working ghc head, are you saying that I should  
scream louder everytime someone breaks nhc98 too?  It is happening  
several times a week at the moment.  It can be jolly frustrating when  
I have other things I could be doing.  But I accept that it is simply  
the price to pay for keeping up-to-date with the libraries everyone  
else is using.  Ghc has no monopoly on the "core" libraries.  They are  
a shared resource.

> to be honest, I don't think its a valid reason for us to go to the  
> trouble of having two vcs for ghc.

Well indeed, I don't want to stand in the way of ghc.  There are far  
more people contributing to it, so their needs have greater weight.  
But I am raising the libraries question, because I think it has an  
impact much more widely than just ghc (or Hugs or nhc98, for that  
matter).

Git may turn out to be sufficiently easy to use that this will all  
seem like a storm in a teacup once the dust has settled.  (I'm not  
filled with confidence by blog postings that say "granted, git is a  
usability disaster zone", and "[you] may find git to be hostile,  
unfriendly and needlessly complex", but those seem to be minority  
opinions.)

Regards,
     Malcolm


Regards,
     Malcolm

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

[Claus Reinke]

>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 before you're doing it;-).

However, there are so many lists to choose from, and many
often opinionated discussions on many of them that will bury
those informative messages of yours rather quickly. So if anyone
joins the world of GHC in a few weeks, they will be just as lost
as everyone was before you started outlining your plans and
giving high-level summaries of on-going work in more detail.

Perhaps it would be useful for GHC HQ to have a GHC project
blog, like other non-trivial projects that like to talk about what
they are doing/planning and how the pieces fit together (for
examples, see: google, opera, ..)?

The follow-on discussions should still be on cvs-ghc, or on
cvs-libraries, or on libraries, or on glasgow-haskell-users, or
on ghc wiki or trac, or whatever the topic requires. But the
original information would be collected in a single place, on
a blog with rss feed to which interested parties could be refered.

Given the number of things going on, I'm sure such a blog
would become required reading rather quickly, even for those
not subscribed to cvs-ghc, etc.

Just another suggestion;-)
Claus


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

[Johan Tibell-2]

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 there are plenty of if-defs on symbols like __HUGS__ in the
implementation. That seems like a bad approach to me. It doesn't
factor out the specifics of an implementation to one place but instead
litters the code with it making it hard to read and change without
breaking it. I would imagine that this slows down library development.
You could compare it to a scenario where Windows and Linux shared
their libc implementation!

If it's so difficult to share code without continuously breaking the
build then we're better of keeping the code separate.

I might have gotten this wrong so could someone please explain to me
what exactly is the problem and why we are in this situation?

Thank you,

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

[Simon Marlow-7]

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 decisions to act
upon, one of which will probably be to set up a blog so that GHC devs can
communicate what they're up to.

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

[Malcolm Wallace]

> - 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 breakage.  It is often unclear  
which parts of the code are shared and which separate, so a lot of  
breakage arises from e.g. exporting a name that is defined for ghc only.

In addition, there are some (once obscure) bugs in nhc98 that are now  
triggered increasingly frequently.  (We can't blame anyone except  
nhc98 for those of course.)  These include complex import renaming  
resolution, and contexts on pattern variables.

> - It seems to me that implementations "share" libraries using CPP.
> That seems like a bad approach to me.

Agreed.  The CPP was always intended to be as temporary as possible,  
with the goal to share as much as possible.  One of the problems is  
that the primitives provided by compilers are different.  Really,  
there should be a package below 'base' in the dependency tree,  
specific to each compiler, and non-shared.  Then everything from base  
upwards would be cleaner and more portable.

> If it's so difficult to share code without continuously breaking the
> build then we're better of keeping the code separate.

I don't agree.  The only way to achieve convergence is to start from  
some semi-merged point, and work to eliminate the differences.  Igloo  
is doing a fantastic job of determining the dependencies and gradually  
moving stuff around to enable this to happen.

Regards,
     Malcolm

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

[Johan Tibell-2]

On Wed, Aug 13, 2008 at 12:21 PM, Malcolm Wallace
<malcolm.wallace@...> 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 compiled code in the libraries, and I would say that it
> is the major contributor to breakage.  It is often unclear which parts of
> the code are shared and which separate, so a lot of breakage arises from
> e.g. exporting a name that is defined for ghc only.
>
> In addition, there are some (once obscure) bugs in nhc98 that are now
> triggered increasingly frequently.  (We can't blame anyone except nhc98 for
> those of course.)  These include complex import renaming resolution, and
> contexts on pattern variables.

Can we make sure that these libraries are always built with some
Haskell 98 compatibility flag by GHC so people find out when they add
non Haskell 98 stuff?

>> - It seems to me that implementations "share" libraries using CPP.
>> That seems like a bad approach to me.
>
> Agreed.  The CPP was always intended to be as temporary as possible, with
> the goal to share as much as possible.  One of the problems is that the
> primitives provided by compilers are different.  Really, there should be a
> package below 'base' in the dependency tree, specific to each compiler, and
> non-shared.  Then everything from base upwards would be cleaner and more
> portable.

Some code rearrangement could go a long way to. We could put compiler
specific implementations of certain functions in a separate module. We
could then import the right compiler specific module with just one
if-def and then reexport the functions from e.g. Data.Array.

module Data.Array (
  map,
  filter
  ) where

#ifdef __GLASGOW_HASKELL__
import Ghc.Data.Array as Impl
#endif
#ifdef __HUGS__
import Hugs.Data.Array as Impl
#endif

-- | Documentation
map = Impl.map

-- | This implementation is shared.
filter p xs = ...

I don't know if this is the best way (I need to give the subject some
more thought).

>> If it's so difficult to share code without continuously breaking the
>> build then we're better of keeping the code separate.
>
> I don't agree.  The only way to achieve convergence is to start from some
> semi-merged point, and work to eliminate the differences.  Igloo is doing a
> fantastic job of determining the dependencies and gradually moving stuff
> around to enable this to happen.

Trying to come up with a solution that allows us to share code in a
sane way would of course be better.  But if that doesn't work, maybe
because the problem is inherent with the way we share code, and the
build breakages continue I would argue strongly for always keeping
HEAD buildable over sharing implementation.

Cheers,

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

[Duncan Coutts]

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  
> sufficiently mature in a year to make a switch worthwhile?  I just  
> object to using the whole GHC developer community as guinea pigs.

Sadly, I'm not so sure we've really learnt much that helps Cabal itself.
While there's been a lot of general pain I can't think of many specific
issues we've discovered in Cabal. We added a couple of minor features,
some of which we'd have needed anyway for building the libs for 6.10 (eg
due to the base-3/4 thing). As far as I can see, most of the problems
have been in the change itself and the makefile glue code.

I may well me missing some things since I've not been intimately
involved in the changes. I would most appreciate specific problems or
missing features being filed as tickets in the Cabal trac so that we can
learn things and not forget them. Roman filed #276 "Add support for
convenience libraries" and I appreciate that.

I know about the longer term need for dph for a more general 'ways'
system in ghc's package system, which will need support in Cabal. I'll
file a ticket for that one.

Duncan

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

[Malcolm Wallace]

> 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 kernel still builds after every modification to
the gcc project code base.  The projects are different, so the
suggested requirement would be an unreasonable burden.

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

[Johan Tibell-2]

On Wed, Aug 13, 2008 at 1:52 PM, Malcolm Wallace
<Malcolm.Wallace@...> 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 flawed.  It is like asking the developers of _gcc_ to
> ensure that the Linux kernel still builds after every modification to
> the gcc project code base.  The projects are different, so the
> suggested requirement would be an unreasonable burden.

I think an even better analogy is probably comparing it to developer
of GCC changing the libc implementation of another compiler or vice
versa.

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

[Bulat Ziganshin-2]

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 people find out when they add
> non Haskell 98 stuff?

on ghc, we use many non-h98 features. actually, there are even non-h98
features that are common to all 3 compilers (f.e. rank-2 types, afair)

we need to check that non-nhc features are not used in *shared* code and
the best tool to do such checks is nhc itself

--
Best regards,
 Bulat                            mailto:Bulat.Ziganshin@...

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

[Malcolm Wallace]

> 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.

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

[Johan Tibell-2]

On Wed, Aug 13, 2008 at 3:13 PM, Malcolm Wallace
<Malcolm.Wallace@...> 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 joint
> creations, with a lot of community (non-compiler-hacker) involvement.

I'm very grateful these people took the time to write these libraries.
However, how these modules were created is irrelevant when it comes to
addressing the current problem. Parts of their implementation is
compiler dependent and having compiler specific code live together is
bound to lead to problems because the people hacking on those modules
are likely to use and validate on only one compiler. It would be
difficult to require them to do otherwise too. To avoid this problem
either the compiler dependent code has to be abstracted out from these
modules so people can ignore the differences or the implementations of
these files need to be kept separate.

Consider the following scenario. GHC hackers implement Data.Array in
A.hs, Hugs and NHC98 hackers develop separate implementations in B.hs
and C.hs respectively. We now run something like

diff A.hs B.hs C.hs | sed <diff markers with if-defs> > X.hs

X.hs could be likened to what current implementation of these files
look like. If the three groups don't validate their changes on all
compilers they risk breaking someones build. Especially note the poor
scaling properties of this approach were each new implementation adds
one more compiler for everyone to verify on. I think the reason this
works at all right now is that most work is happening on GHC and
that's also were the most users are.

Cheers,

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

[Austin Seipp]

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 is excellent; many
of the man pages have fairly lucid examples and explanations of their
usage. The documentation on kernel.org is also very extensive. This
software is used by a lot of people already and has proven to be
reliable for projects the size of e.g. the linux kernel.

While it may be true that in the past git was cumbersome and difficult
to use, I can't agree with such an assessment these days. In many
instances, you can probably get away with ignoring most of the more
'advanced' commands and simply using it like any other DVCS. "Everyday
git" in fact, is surprisingly simple I think. I certainly don't think
that the GHC devs will need anything under the porcelain commands
either. You don't have to use super-advanced commands that might
endanger your history (and commands like git-reflog are a safety net
around that too.) You can get far with just a little.

Also, this tutorial (and its sequel in particular) should do well for
anybody new to git:

http://www.kernel.org/pub/software/scm/git/docs/gittutorial.html

It's really not that bad and should take you no more than a few
minutes to read it and the second part. I encourage those who might be
confused to read it.

And besides familiarity, what does darcs give us that git doesn't? I
find git's core model (objects, trees, blobs and tags are it) more
simple and straightforward than the blackbox that is darcs.

(And although it's already been elaborated upon before I'm sure,
waiting on your tools is nothing but a waste of time. If I even want
to get the latest HEAD, I find I can spend a lot of time waiting on
darcs. I rarely wait on git for anything - it's fairly instant most of
the time.)

So I'm with Johan and Thomas for a switch to git.

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

[Jason Dagit-2]

On Wed, Aug 13, 2008 at 1:54 AM, Malcolm Wallace <malcolm.wallace@...> 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 didn't break the GHC build yet.  If he does, I'll be screaming as loudly as for anybody else.

Whilst I'm in no way saying that a working nhc98 head is anything like as important as a working ghc head, are you saying that I should scream louder everytime someone breaks nhc98 too?  It is happening several times a week at the moment.  It can be jolly frustrating when I have other things I could be doing.  But I accept that it is simply the price to pay for keeping up-to-date with the libraries everyone else is using.  Ghc has no monopoly on the "core" libraries.  They are a shared resource.

to be honest, I don't think its a valid reason for us to go to the trouble of having two vcs for ghc.

Well indeed, I don't want to stand in the way of ghc.  There are far more people contributing to it, so their needs have greater weight.  But I am raising the libraries question, because I think it has an impact much more widely than just ghc (or Hugs or nhc98, for that matter).

Git may turn out to be sufficiently easy to use that this will all seem like a storm in a teacup once the dust has settled.  (I'm not filled with confidence by blog postings that say "granted, git is a usability disaster zone", and "[you] may find git to be hostile, unfriendly and needlessly complex", but those seem to be minority opinions.)

I'm not a contributor for hugs, nhc, jhc, ghc, or any other project that is affect here, but when I see this part of the discussion come up again and again I have to wonder if anyone has done the obvious thing of asking these other communities if they would mind switching to git?

Of course each of them are free to say "No, we won't switch" for any reason they like and you'd have to then deal with the situation.  But, it seems that it can't hurt to ask, and I get the impression no one has asked them formally.  If everyone did happen to agree on using git for the shared libraries, wouldn't that end this part of the debate?

Just my $0.02,
Jason

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

[Matthias Kilian]

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 tree.  So perhaps I've
> misunderstood your point?

No, I was confused (a little bit over-worked).

> >$ ./Setup mkmetadata -prefix foo-
> >
> >which just produces some simple variable declarations like
> >
> > foo-impl-ghc-build-depends = rts
> > foo-impl-ghc-exposed-modules = Data.Generics Data.Generics.Aliases
[...]
> Yes, we could use this to implement GHC's build system.  It's somewhat
> similar to the scheme I suggested in the other thread, but more generic.
>  I'd be completely happy to do it this way if the functionality would
> be useful to others outside GHC too.

I've a little bit spare time from august 25th to august 31th.  This
should be enough time for implementing it (in Cabal and in the GHC
build system) to see how it feels.

Ciao,
        Kili

--
CRM114 isn't ugly like PERL.  It's a whole different kind of ugly.
                -- John Bowker
_______________________________________________
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 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 whatsnew", "darcs unrecord" are all slower than darcs 1.  When
>     simple operations take multiple seconds to complete, it really slows
>     down your workflow.

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 of many files. Obviously that's very slow,
especially over nfs. That explains why it worked for me in 0.2 seconds
but for you took several seconds user time and (even more real time due
to nfs).

If you were using http://darcs.haskell.org/ghc-hashedrepo/ then there's
a further explanation. According to the darcs devs that repo is:
        "in some weird intermediate (not final) hashed format that
        doesn't keep (original) filesizes in filenames. So in effect,
        it's running like with --ignore-times still"

So I suggest we get rid of that old repo so as not to further the
confusion.

Duncan

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

[Manuel M T Chakravarty]

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",
>>    "darcs whatsnew", "darcs unrecord" are all slower than darcs 1.  
>> When
>>    simple operations take multiple seconds to complete, it really  
>> slows
>>    down your workflow.
>
> 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 of many files. Obviously that's very slow,
> especially over nfs. That explains why it worked for me in 0.2 seconds
> but for you took several seconds user time and (even more real time  
> due
> to nfs).

LOL - that is funny.  GHC devel slowed down by slow darcs due to GHC  
bug.

The bug is fixed, isn't it?  So, recompiling darcs with 6.8.3 should  
improve matters.

Manuel

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

[Simon Marlow-7]

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 of many files. Obviously that's very slow,
> especially over nfs. That explains why it worked for me in 0.2 seconds
> but for you took several seconds user time and (even more real time due
> to nfs).

Yes, I was aware of the #2093 problem (someone else pointed it out to me
earlier), but it's not the cause of the slow whatsnew I'm seeing: my darcs
is compiled with 6.8.3.

~/darcs/ghc-testing/testsuite-hashed > darcs +RTS --info
  [("GHC RTS", "Yes")
  ,("GHC version", "6.8.3")
  ,("RTS way", "rts_thr")
  ,("Host platform", "x86_64-unknown-linux")
  ,("Build platform", "x86_64-unknown-linux")
  ,("Target platform", "x86_64-unknown-linux")
  ,("Compiler unregisterised", "NO")
  ,("Tables next to code", "YES")
  ]
~/darcs/ghc-testing/testsuite-hashed > time darcs wh
No changes!
[2]    15793 exit 1     darcs wh
21.35s real   9.56s user   4.28s system   64% darcs wh
~/darcs/ghc-testing/testsuite-hashed > darcs --version
2.0.1rc2 (2.0.1rc2 (+ -1 patch))
~/darcs/ghc-testing/testsuite-hashed > darcs query repo
           Type: darcs
         Format: hashed
           Root: /home/simonmar/darcs-all/work/ghc-testing/testsuite-hashed
       Pristine: HashedPristine
          Cache:
thisrepo:/home/simonmar/darcs-all/work/ghc-testing/testsuite-hashed
boringfile Pref: .darcs-boring
Default Remote: /home/simonmar/darcs-all/work/ghc-testing/testsuite
    Num Patches: 2834

It's better on the darcs-2 version of the repo:

~/darcs/ghc-testing/testsuite-hashed2 > darcs query repo
           Type: darcs
         Format: hashed, darcs-2
           Root: /home/simonmar/darcs-all/work/ghc-testing/testsuite-hashed2
       Pristine: HashedPristine
          Cache:
thisrepo:/home/simonmar/darcs-all/work/ghc-testing/testsuite-hashed2
    Num Patches: 2834
~/darcs/ghc-testing/testsuite-hashed2 > time darcs wh
No changes!
[2]    15824 exit 1     darcs wh
3.69s real   1.08s user   0.53s system   43% darcs wh

Better, but still a factor of ~4 slower than on the darcs-1 repo.

> If you were using http://darcs.haskell.org/ghc-hashedrepo/ then there's
> a further explanation. According to the darcs devs that repo is:
>         "in some weird intermediate (not final) hashed format that
>         doesn't keep (original) filesizes in filenames. So in effect,
>         it's running like with --ignore-times still"

Nope, I'm not using that repo, these were ones I created freshly yesterday.

I will try building a fresh darcs to see if that helps.

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

[Ian Lynagh]

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 wouldn't object to dropping the use of Cabal for other tools in  
> >the build tree; the reasons for using it elsewhere are certainly not  
> >as compelling as for packages.
> >
> >Ian, I realise this means backing out a lot of the work you've been  
> >doing recently, and it would mean that we'd lose a lot of time in  
> >the runup to 6.10.1, but perhaps it's a step that we need to take to  
> >get us back on the right track again?
>
> I do realise that this would mean backing out a lot of Ian recent  
> work, and that's why I haven't proposed going back to the old system  
> before you explicitly asked.  However, I am increasingly getting the  
> feeling that the move to Cabal was pre-mature, and the overall loss  
> will be minimised by backing out now.

We're only talking about "other tools", not the libraries (including the
GHC library), right?

This seems like it would be a step backwards to me (after all, I
wouldn't have spent the time moving to Cabal if I didn't think it was a
step forwards), and I'm not really sure what benefit you see in it: how
much time do you spend working in utils/?


Thanks
Ian

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

[Ian Lynagh]

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  
> with the stage1 compiler.  (If you are unsure why, I'll happily  
> elaborate.)

No, I understand why it was necessary, I just had problems with the way
it was done.

Of course, it would have been possible to extend the old build system to
build the two versions in separate directories, but it would have meant
adding more complexity to an already-complex system. I believe that
using a Cabal-based build system instead has made things simpler.


Thanks
Ian

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