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, 2008-08-13 at 22:47 +1000, Roman Leshchinskiy wrote:
> Again, I'm not arguing against a build system written in Haskell. I'd
> just like it to be completely separated from Haskell's packaging
> system. In particular, "polluting" a package description with build
> information seems wr
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 13/08/2008, at 20:34, Simon Marlow wrote:
Roman Leshchinskiy wrote:
Of course there should be a standard build system for simple
packages. It could be part of Cabal or a separate tool (for which
Cabal could, again, act as a preprocessor).
GHC is a special case: we already need a build sy
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, 2008-08-13 at 11:34 +0100, Simon Marlow wrote:
> Cabal has two parts: some generic infrastructure, and a "simple" build
> system (under Distribution.Simple) that suffices for most packages. We
> distribute them together only because it's convenient; you don't have to
> use the simple b
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
Roman Leshchinskiy wrote:
Of course there should be a standard build system for simple packages.
It could be part of Cabal or a separate tool (for which Cabal could,
again, act as a preprocessor).
GHC is a special case: we already need a build system for other reasons.
I agree. I just don'
- 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.
On 13/08/2008, at 17:47, Simon Marlow wrote:
Roman Leshchinskiy wrote:
On 12/08/2008, at 20:11, Simon Marlow wrote:
- Extract the code from Cabal that generates Makefiles, and treat
it as
part of the GHC build system. Rather than generating a Makefile
complete with build rules, we generat
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,
Roman Leshchinskiy wrote:
On 12/08/2008, at 20:11, Simon Marlow wrote:
- Extract the code from Cabal that generates Makefiles, and treat it as
part of the GHC build system. Rather than generating a Makefile
complete with build rules, we generate a Makefile that just
has the package-speci
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
27 matches
Mail list logo
