www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - Patches, bottlenecks, OpenSource

reply bearophile <bearophileHUGS lycos.com> writes:
After the last posts about patches, I can write something myself about this
topic :-) I am far from being an expert of big software projects, but I think I
am now able to understand some things of the D project.

I like D, it's an alive project, but from what I've seen D so far is not having
a so significant success. I think lot of people (especially young programmers)
don't want "a better C++", they want no stinking C++ at all. They want
something quite different. (On the other hand now I am not so sure Scala will
have a widespread success, its type system makes it not easy to learn).

A C++-class language compiler is a big project that requires quite different
skill sets: in the D compiler there is work to do on the vector operations,
lent/uniqueness, multi-core, 64 bit, work for keep it well updated on
Mac/Linux/Win and well packaged, development of Phobos and its data structures,
work on the back-end to use the SSE registers and future CPUs or GPUs, tuning
of the associative arrays, future improvements of the core language,
improvements in the unit test system, large improvement in the D web site and
the documentation, big improvements needed for the GC to turn it into something
more modern, and so on. Such things have to be refined, debugged, efficient,
cared of, polished.

So as D develops and grows it will get hard for a single person to write all
patches to the language and other parts. As D grows this will become a
bottleneck, and from what I've seen it already is. The disadvantage of allowing
other people the rights to patch the front-end is some lost control, but Walter
can review patches after they are already applied & working (in a big project
having a director is positive). This can speed up the patching process itself.
The compiler can become more like a patchwork of different programming styles,
and Walter has to ask to other people how some parts not written by him work.
This can be doable if the front-end becomes more modular. LLVM shows a more
modular design that can be copied. This is a lot of refractoring work.

Increasing openess can increase the influx of devs and their willingness to
help the project. This is quite positive and its importance can't be
underestimated.

Pyrex (http://www.cosc.canterbury.ac.nz/greg.ewing/python/Pyrex/ ) was forked
in Cython (http://www.cython.org/ ) because Pyrex author was too much slow in
patching. A fork will not happen in D soon because there are not enough people
yet that care and work for D enough to make a fork viable. D is not a project
as alive as Pyrex. Cython is a tiny rib of the Python language circus.

I suggest to give patching rights to Don, it can be one more step forward
toward Open Sourcing D development style :-) In future such right can be given
to other few good people that have shown to deserve enough trust.

I am not sure the future of D is in the dmd back-end, llvm looks in better
shape for this purpose. LLVM is able to support 99.9% of the features of D2
(and I presume llvm devs are willing to add the few missing things if someone
gives them patches; from the unladen-swallow project I have seen they are open
enough), and it supports a large number of good features currently not
done/present by/in the back-end of dmd. Currently ldc is a compiler much better
than dmd (try it if you don't believe me!), but its devs are not appreciating
D2 language yet much. I don't like to see the Walter-locomotive so detached
from the present nice ldc D1 compiler, and from the future of LDC and llvm. I'd
still like ldc to become the official D2 compiler, developed and cared of :-)

Bye,
bearophile
Apr 10 2010
next sibling parent reply Robert Clipsham <robert octarineparrot.com> writes:
On 10/04/10 13:09, bearophile wrote:
 After the last posts about patches, I can write something myself
 about this topic :-) I am far from being an expert of big software
 projects, but I think I am now able to understand some things of the
  D project.

 I like D, it's an alive project, but from what I've seen D so far is
  not having a so significant success.

It seems this way to me too, I wonder what needs doing to change this... Perhaps getting the word out more will help (I believe Walter and Andrei are giving a 1 day talk at ACCU this week, I wonder if this will have an impact at all). I also wonder if TDPL will make a difference, I guess we'll see.
 I think lot of people (especially young programmers) don't want "a
 better C++", they want no stinking C++ at all. They want something
 quite different. (On the other hand now I am not so sure Scala will
 have a widespread success, its type system makes it not easy to
 learn).

Speaking myself as a young programmer (probably one of the youngest D users), I'm not sure where I stand on this. On one hand we have to learn from our mistakes... If C++ didn't happen D would be as much of a mess as C++ is :) On the other hand, if C++ went away I wouldn't feel so obliged to learn an obviously inferior language. I made the choice to learn D before C or C++, and as a result my motivation to learn them has been minimal...
 A C++-class language compiler is a big project that requires quite
 different skill sets: in the D compiler there is work to do on the
 vector operations, lent/uniqueness, multi-core, 64 bit, work for keep
 it well updated on Mac/Linux/Win and well packaged, development of
 Phobos and its data structures, work on the back-end to use the SSE
 registers and future CPUs or GPUs, tuning of the associative arrays,
 future improvements of the core language, improvements in the unit
 test system, large improvement in the D web site and the
 documentation, big improvements needed for the GC to turn it into
 something more modern, and so on. Such things have to be refined,
 debugged, efficient, cared of, polished.

That is, despite the size of the paragraph... A huge list of tasks :D I think a lot of effort can be saved on this front by, as you mention below, utilizing the likes of llvm, improving and tweaking the code base as needed. As for the other features, I guess it's a matter of time, some of these things will need to wait for D3 (lent/uniqueness), others just need people to put in the effort.
 So as D develops and grows it will get hard for a single person to
 write all patches to the language and other parts. As D grows this
 will become a bottleneck, and from what I've seen it already is. The
  disadvantage of allowing other people the rights to patch the
 front-end is some lost control, but Walter can review patches after
 they are already applied&  working (in a big project having a
 director is positive). This can speed up the patching process itself.
 The compiler can become more like a patchwork of different
 programming styles, and Walter has to ask to other people how some
 parts not written by him work. This can be doable if the front-end
 becomes more modular. LLVM shows a more modular design that can be
 copied. This is a lot of refractoring work.

I think more and more people are noticing this recently, with about 70 patches now in bugzilla that need filtering through and pushing into the code base. I don't really think a huge refactor is practical right now, the time is better spent working out the bugs, and generally polishing up the compiler (particularly the front end, which all the current working D compilers use). Eventually as D gains momentum this will become practical, and we could end up with a clang style front end for D (I believe this was started but didn't get too far, Dang on DSource I believe :)).
 Increasing openess can increase the influx of devs and their
 willingness to help the project. This is quite positive and its
 importance can't be underestimated.

The truth of this has already been visible, when the DM backend became source available a few months ago (but not open source), a huge selection of patches appeared, and as a result DMD improved. Moving to a more open development model for dmd, and D in general will always be a good thing, the evidence is all around us.
 Pyrex (http://www.cosc.canterbury.ac.nz/greg.ewing/python/Pyrex/ )
 was forked in Cython (http://www.cython.org/ ) because Pyrex author
 was too much slow in patching. A fork will not happen in D soon
 because there are not enough people yet that care and work for D
 enough to make a fork viable. D is not a project as alive as Pyrex.
 Cython is a tiny rib of the Python language circus.

A side-effect of being completely open, eventually people will fork the project, and people have to choose what to use, causing a split in the community... Of course there have been many positive effects from forks of open source projects in the past, such as new features becoming available, and more stable code in general. The best things about forks is seeing the hard work paying off and seeing the forks merged back into the main codebase, so the advantages of each can be enjoyed by all :)
 I suggest to give patching rights to Don, it can be one more step
 forward toward Open Sourcing D development style :-) In future such
 right can be given to other few good people that have shown to
 deserve enough trust.

I have also suggested this, it would be good to see more people with commit access, even if it is just one person and they have a lot of restrictions with what can get in etc.
 I am not sure the future of D is in the dmd back-end, llvm looks in
 better shape for this purpose. LLVM is able to support 99.9% of the
 features of D2 (and I presume llvm devs are willing to add the few
 missing things if someone gives them patches; from the
 unladen-swallow project I have seen they are open enough), and it
 supports a large number of good features currently not done/present
 by/in the back-end of dmd. Currently ldc is a compiler much better
 than dmd (try it if you don't believe me!), but its devs are not
 appreciating D2 language yet much. I don't like to see the
 Walter-locomotive so detached from the present nice ldc D1 compiler,
  and from the future of LDC and llvm. I'd still like ldc to become
 the official D2 compiler, developed and cared of :-)

I don't believe the future is in the DM backend either, I don't see it disappearing for a long time though. Walter's worked on that backend for a significant proportion of his life, I can see why he would be reluctant to give it up too easily. DM will continue to evolve, particularly as D2 becomes more stable and work on the 64bit backend starts (hopefully Walter will make sure this is done in such a way that the new 64 bit code is open source and not under the restrictive backend license, we'll see though :)). I'd like to see more effort put into ldc to get it working with D2, I guess that unless the ldc developers find time for it, or other people do it won't happen for a good while yet unfortunately. I did try a while back, but realised what a huge task it was, and how little time I had available for it :/ Maybe someone else will be able to pick up where I left off :)
 Bye, bearophile

Apr 10 2010
parent reply Eric Poggel <dnewsgroup yage3d.net> writes:
On 4/10/2010 8:40 AM, Robert Clipsham wrote:
 I'd like to see more effort put into ldc to get it working with D2, I
 guess that unless the ldc developers find time for it, or other people
 do it won't happen for a good while yet unfortunately. I did try a while
 back, but realised what a huge task it was, and how little time I had
 available for it :/ Maybe someone else will be able to pick up where I
 left off :)

Speaking of ldc, does anyone know how Windows support is coming? Last I heard llvm was lacking support for exception handling on Windows, which sort of stalled things.
Apr 10 2010
parent Robert Clipsham <robert octarineparrot.com> writes:
On 10/04/10 15:49, Eric Poggel wrote:
 Speaking of ldc, does anyone know how Windows support is coming? Last I
 heard llvm was lacking support for exception handling on Windows, which
 sort of stalled things.

LDC on windows works just fine, providing you don't need exceptions. Until LLVM supports exceptions on Windows, Windows users most likely won't be able to use LDC on Windows. I believe the topic has come up many times, but no one has been willing to implement it. You'd have to ask the LLVM devs for the status about it.
Apr 10 2010
prev sibling next sibling parent "Adam D. Ruppe" <destructionator gmail.com> writes:
On Sat, Apr 10, 2010 at 08:09:34AM -0400, bearophile wrote:
 I like D, it's an alive project, but from what I've seen D so far is not
having a so significant success.

D2 hasn't even launched to beta status yet; it is pretty premature to say anything about its success. "That fetus has a heartbeat, but from what I've seen so far, it hasn't landed a very good job."
 So as D develops and grows it will get hard for a single person to write all
patches to the language and other parts.

There's about a dozen contributors now that I know of to phobos, and about half the things you listed are library issues - some of those things have been improved upon in just the last couple months, and in the next couple, there's lots more in store. IMO, the language itself is pretty well complete. The list I have of requests is very small and all low priority - what's left is beautifying the library, fixing bugs, and improving performance, and D has a pretty good team on this today. -- Adam D. Ruppe http://arsdnet.net
Apr 10 2010
prev sibling next sibling parent Ellery Newcomer <ellery-newcomer utulsa.edu> writes:
On 04/10/2010 07:09 AM, bearophile wrote:
 Currently ldc is a compiler much better than dmd (try it if you don't believe
me!)

 Bye,
 bearophile

I've tried it several times recently and I don't believe you as a result. I have yet to see it not crash AND generate faster code than dmd.
Apr 10 2010
prev sibling next sibling parent Spacen Jasset <spacenjasset yahoo.co.uk> writes:
bearophile wrote:
 After the last posts about patches, I can write something myself about this
topic :-) I am far from being an expert of big software projects, but I think I
am now able to understand some things of the D project.
 
 I like D, it's an alive project, but from what I've seen D so far is not
having a so significant success. I think lot of people (especially young
programmers) don't want "a better C++", they want no stinking C++ at all. They
want something quite different. (On the other hand now I am not so sure Scala
will have a widespread success, its type system makes it not easy to learn).
 
 A C++-class language compiler is a big project that requires quite different
skill sets: in the D compiler there is work to do on the vector operations,
lent/uniqueness, multi-core, 64 bit, work for keep it well updated on
Mac/Linux/Win and well packaged, development of Phobos and its data structures,
work on the back-end to use the SSE registers and future CPUs or GPUs, tuning
of the associative arrays, future improvements of the core language,
improvements in the unit test system, large improvement in the D web site and
the documentation, big improvements needed for the GC to turn it into something
more modern, and so on. Such things have to be refined, debugged, efficient,
cared of, polished.
 
 So as D develops and grows it will get hard for a single person to write all
patches to the language and other parts. As D grows this will become a
bottleneck, and from what I've seen it already is. The disadvantage of allowing
other people the rights to patch the front-end is some lost control, but Walter
can review patches after they are already applied & working (in a big project
having a director is positive). This can speed up the patching process itself.
The compiler can become more like a patchwork of different programming styles,
and Walter has to ask to other people how some parts not written by him work.
This can be doable if the front-end becomes more modular. LLVM shows a more
modular design that can be copied. This is a lot of refractoring work.
 
 Increasing openess can increase the influx of devs and their willingness to
help the project. This is quite positive and its importance can't be
underestimated.
 
 Pyrex (http://www.cosc.canterbury.ac.nz/greg.ewing/python/Pyrex/ ) was forked
in Cython (http://www.cython.org/ ) because Pyrex author was too much slow in
patching. A fork will not happen in D soon because there are not enough people
yet that care and work for D enough to make a fork viable. D is not a project
as alive as Pyrex. Cython is a tiny rib of the Python language circus.
 
 I suggest to give patching rights to Don, it can be one more step forward
toward Open Sourcing D development style :-) In future such right can be given
to other few good people that have shown to deserve enough trust.
 
 I am not sure the future of D is in the dmd back-end, llvm looks in better
shape for this purpose. LLVM is able to support 99.9% of the features of D2
(and I presume llvm devs are willing to add the few missing things if someone
gives them patches; from the unladen-swallow project I have seen they are open
enough), and it supports a large number of good features currently not
done/present by/in the back-end of dmd. Currently ldc is a compiler much better
than dmd (try it if you don't believe me!), but its devs are not appreciating
D2 language yet much. I don't like to see the Walter-locomotive so detached
from the present nice ldc D1 compiler, and from the future of LDC and llvm. I'd
still like ldc to become the official D2 compiler, developed and cared of :-)
 
 Bye,
 bearophile

It's all true. I also think we should use a DVCS too so that Walter can apply patches easily and we can upload patch branches directly to somewhere that can be merged and or reconciled by the original authors in case of conflict. It's all good. The history of the patch itself can also be tracked even after merging. I suggest Bazaar but I am deeply biased on the matter. Further, Don et al. could act as gatekeeper to prevent Walter getting bogged down with too many patches. And then things will be all good and I may find the time to get interested in D again.
Apr 13 2010
prev sibling next sibling parent reply Don <nospam nospam.com> writes:
bearophile wrote:
 After the last posts about patches, I can write something myself about this
topic :-) I am far from being an expert of big software projects, but I think I
am now able to understand some things of the D project.
 
 I like D, it's an alive project, but from what I've seen D so far is not
having a so significant success. I think lot of people (especially young
programmers) don't want "a better C++", they want no stinking C++ at all.

D also falls down pretty badly in terms of marketing...
 A C++-class language compiler is a big project that requires quite different
skill sets: in the D compiler there is work to do on the vector operations,
lent/uniqueness, multi-core, 64 bit, work for keep it well updated on
Mac/Linux/Win and well packaged, development of Phobos and its data structures,
work on the back-end to use the SSE registers and future CPUs or GPUs, tuning
of the associative arrays, future improvements of the core language,
improvements in the unit test system, large improvement in the D web site and
the documentation, big improvements needed for the GC to turn it into something
more modern, and so on. Such things have to be refined, debugged, efficient,
cared of, polished.

Indeed, D is targetting the most difficult language market. But, many of the things you've listed are library things. Walter has successfully handed over almost all the library stuff. And really, D doesn't need many people working on the DMD compiler. We really need a lot more library development. That's where I see the bottleneck.
 So as D develops and grows it will get hard for a single person to write all
patches to the language and other parts.
 As D grows this will become a bottleneck, and from what I've seen it already
is. 

I think the folding in of compiler patches is far from being a bottleneck at present, and I doubt it ever will be. Some of the top developers on the Linux kernel are responsible for integrating thousands of patches. Currently, there are 70 open compiler patches. 30 of them come from the last 2 weeks. Most of the older patches are incomplete or have some other problem; 12 are enhancements. So the situation really isn't too bad at all.
 I suggest to give patching rights to Don, it can be one more step 

right can be given to other few good people that have shown to deserve enough trust. Many people have commit rights to Phobos and druntime, yet there are almost 40 open Phobos/Druntime patches. OTOH Rainer and I are flooding Walter with patches; eventually he might get sick of spending all his time on our patches. Although after years of doing all the work alone, it probably hasn't irritated him yet <g>.
Apr 15 2010
next sibling parent reply bearophile <bearophileHUGS lycos.com> writes:
Don:

And really, D doesn't need many people working on the DMD compiler.<

I agree, it's like having many people working around a dead corpse trying to revive it. Better use the time to adopt gcc and llvm back-ends at their best, keeping in mind, while designing D, that there are features that those back-ends have and the dmd back-end doesn't have that it will be good to add to the language. Simple example: refusing computed gotos because they are a lot of work to implement is not a justification that holds if both gcc and llvm already implement them and allow the front-end to just use them in a simple enough way. Bye, bearophile
Apr 15 2010
next sibling parent Justin Spahr-Summers <Justin.SpahrSummers gmail.com> writes:
On Thu, 15 Apr 2010 15:41:20 -0400, bearophile 
<bearophileHUGS lycos.com> wrote:
 
 Don:
 
And really, D doesn't need many people working on the DMD compiler.<

I agree, it's like having many people working around a dead corpse trying to revive it. Better use the time to adopt gcc and llvm back-ends at their best, keeping in mind, while designing D, that there are features that those back-ends have and the dmd back-end doesn't have that it will be good to add to the language. Simple example: refusing computed gotos because they are a lot of work to implement is not a justification that holds if both gcc and llvm already

 
 Bye,
 bearophile

I like DMD, personally, and I've liked the benchmarks that I've seen of it (although lack of PowerPC support saddens me). GCC is a behemoth according to anyone who's ever done any work with it, and I like DMD's official status... even if LDC (for instance) were to become the "official" D compiler, the D compilation is so dependent on the LLVM system that it'd probably eventually run into issues like what Apple had with GCC not doing what they wanted; in Apple's case, they started a new project (clang, for those not familiar) so they could have solid control over the codebase. As far as computed gotos, I think Walter explains somewhere on the D website that D should be an easy language for compiler writers to implement. I don't know the relative implementation difficulty of computed gotos, but I think the rationale for minimizing features actually in the compiler itself is sound. Reduces feature creep and all that good stuff.
Apr 15 2010
prev sibling parent Don <nospam nospam.com> writes:
bearophile wrote:
 Don:
 
 And really, D doesn't need many people working on the DMD compiler.<

I agree, it's like having many people working around a dead corpse trying to revive it. Better use the time to adopt gcc and llvm back-ends at their best, keeping in mind, while designing D, that there are features that those back-ends have and the dmd back-end doesn't have that it will be good to add to the language. Simple example: refusing computed gotos because they are a lot of work to implement is not a justification that holds if both gcc and llvm already implement them and allow the front-end to just use them in a simple enough way. Bye, bearophile

That's not what I meant. The fraction of the community working on compilers should be very small. BTW the DMD backend really has very few bugs. Historically, much less than 1% of the bugs in DMD are in the backend. Currently there are 2 open backend bugs, and they're both extremely obscure.
Apr 16 2010
prev sibling next sibling parent reply "Adam D. Ruppe" <destructionator gmail.com> writes:
On Thu, Apr 15, 2010 at 03:41:20PM -0400, bearophile wrote:
 it's like having many people working around a dead corpse trying to revive it.
Better use the time to adopt gcc and llvm back-ends at their best,

"Yeah, I know D doesn't work on Windows, or even many Linux boxes, but it totally uses a `modern` back end! Yeah, I know it is hard to install too, but if you spend all day following these obscure instructions and have God smiling upon you, you might be able to get it to run on your Game Boy! WOOO!" ...not a trade I'm willing to make. -- Adam D. Ruppe http://arsdnet.net
Apr 15 2010
parent BCS <none anon.com> writes:
Hello Adam,

 On Thu, Apr 15, 2010 at 03:41:20PM -0400, bearophile wrote:
 
 it's like having many people working around a dead corpse trying to
 revive it. Better use the time to adopt gcc and llvm back-ends at
 their best,
 

it totally uses a `modern` back end! Yeah, I know it is hard to install too, but if you spend all day following these obscure instructions and have God smiling upon you, you might be able to get it to run on your Game Boy! WOOO!" ...not a trade I'm willing to make.

But solve those problems... -- ... <IXOYE><
Apr 15 2010
prev sibling parent Fawzi Mohamed <fawzi gmx.ch> writes:
On 16-apr-10, at 09:12, Don wrote:

 bearophile wrote:
 Don:
 And really, D doesn't need many people working on the DMD compiler.<

trying to revive it. Better use the time to adopt gcc and llvm back- ends at their best, keeping in mind, while designing D, that there are features that those back-ends have and the dmd back-end doesn't have that it will be good to add to the language. Simple example: refusing computed gotos because they are a lot of work to implement is not a justification that holds if both gcc and llvm already implement them and allow the front-end to just use them in a simple enough way. Bye, bearophile

That's not what I meant. The fraction of the community working on compilers should be very small. BTW the DMD backend really has very few bugs. Historically, much less than 1% of the bugs in DMD are in the backend. Currently there are 2 open backend bugs, and they're both extremely obscure.

Yes I agree with your point of view, D is good enough to be used seriously, you don't think that many persons should work actively on D or its compiler. Actually I don't want to work on the compiler, I am actually afraid of touching it too much because I like to go low level at times, and I am very afraid of what working seriously on a compiler would mean for my productivity. Work on actual programs and libraries is much more important now. Yes the language is not perfect, but you know no language ever is, different languages allow you to express different things with different ease, and all have their problems and pitfalls. In my opinion D sticks reasonably well to perl tenet "easy things easy, difficult things possible". Now users should not have to redevelop everything from scratch, either because there are no libraries or due to limitations of libraries. Library and application development is a major undertaking, it is not just an application of the language, also there much creativity, and (as it must be a practical thing) also working around bugs. Bearophile is right that problems of the toolchain are also problems of a language. I saw what I consider one of the most beautiful languages for numerics, one that could map mathematical concepts cleanly, die due to that. It was Aldor and had very nice things. Templates for example unlike the C++ tradition don't automatically apply on all possible matching types, but had to be explicitly instantiated. This might seem like a drawback, but you could create templated modules that had exported several templates at once. The result was that for example even the use of symbols like [] for array construction could be overridden, and do different things depending on the types and and the imported things: import List(Integer) and Array(Float) and [1,2,3] would be a list, and [1.0,2.0,3.0] an array. Import also List(Float) and you had to disambiguate... Type inference was very powerful, so that one could very often avoid declaring the type, it was performed also on the return type, so one could implement FromInteger and fromRational and get automatic casting that did the right thing. There ways to easily extend a library type, or create a copy based on the original but with some differences (sort did always use the default comparison operator, but one could easily feed to it an in place converted type that had a different ordering. Aldor also had a powerful CTFE, and being strongly typed and templatized it was fast. And the list goes on and on. Still where is this language? Did anybody here even know it? I don't think so because it died. The compiler was never sold standalone, only a part of the (expensive) Axiom. The compiler was very complex, and had been paid a lot of money (it went from IBM to NAG), and nobody knew exactly what to do, they tried to opensource it, but never fully (hoping to reap back some money, and for difficult copyright status of some pieces?), so that people got so annoyed by not having a compiler or critical library parts available, and having strange restrictions, supporting only few platforms, not being able to see the full source to fix things, until everybody left. I just burned several hours looking in what happened to the various projects in the meantime. I have to say, that while Aldor is still dead that I was pleasantly surprised to find FriCAS, Open-Axiom and Axiom reasonably alive and progressing using the fully free Aldor precursor SPUD (but being lisp based I think not as good for heavy numerics). Lukily D (sorry for the aside on aldor) is in a much better shape the frontend is fully opensource, and source for everything is available. dmd backend is reasonably good for windows and 32 bit development. For serious numeric and computation 64bit is kind of needed, especially if you run on clusters maintained by other that have (rightly) switched to 64 bits. There ldc and llvm look like very good future proof choice as backend for linux,osx, and probably soon also various things (GPU, ARM,... are progressing quickly), but definitely not for windows at the moment. I understand bearophile frustration, and share it up to a point (I am still firmly D 1.0 for these reasons), but llvm is not always better than the dmd backend. That said for my applications it looks like the best choice for the present and close future (with ldc and D 1.0). Fawzi
Apr 16 2010
prev sibling parent Leandro Lucarella <llucax gmail.com> writes:
bearophile, el 10 de abril a las 08:09 me escribiste:
 much slow in patching. A fork will not happen in D soon because there
 are not enough people yet that care and work for D enough to make a fork
 viable.

I think there were some sort of forks in the D history. I see Ares/Tango as a fork of the runtime, and LDC has somehow forked the front-end too to fix some bugs. But fortunatelly there are still intentions in the D community to merge the forks. The problem is when Walter is not responsive enough to the merge requests.
 I suggest to give patching rights to Don, it can be one more step
 forward toward Open Sourcing D development style :-) In future such
 right can be given to other few good people that have shown to deserve
 enough trust.

I agree that having more people with some kind of commit access would improve the situation. -- Leandro Lucarella (AKA luca) http://llucax.com.ar/ ---------------------------------------------------------------------- GPG Key: 5F5A8D05 (F8CD F9A7 BF00 5431 4145 104C 949E BFB6 5F5A 8D05) ---------------------------------------------------------------------- And I am not frightened of dying, any time will do, I don't mind. Why should I be frightened of dying? There's no reason for it, you've gotta go sometime. If you can hear this whispering you are dying. I never said I was frightened of dying.
Apr 19 2010