There is nothing in the world can be free of bug while offer you new features.
So I think in some degree walter & DMD go in the right way.

And complains won't get better result, why not fix it by yourself? Most unfixed
bugs are frontend related. And frontend source is open. And I don't consider the
dummy stable branch would do any good , it just wastes time on diffing & commiting.
Cause the idea is just simple , why not use the new version with bugs fixed?
And some might complain new DMD version just not get right. Then I really suggest
those people try to wait a little bit. DMD is still in development stage. Putting
 it to STABLE status too early will never be good. Ok, of course, some people will
lampoon 1.0 thingie. Yet, it's how commercial world goes. So don't be naive ! Be
a realist! While you do business , you should never hope your product be stable ,
then announce it 1.0, your product will just lose the race.

I think Walter will pay more effort on the way how DMD development goes and the
way it will go.

The frontend is open, but not the backend. So its not possible for a community member to merge bug fixes back and build/compile a dmd release. Or did i miss something?

Davidl wrote:
> There is nothing in the world can be free of bug while offer you new features.
> So I think in some degree walter & DMD go in the right way.

This is true however its also true that bug fixes can cause more bugs (I wonder how many of the new bugs we have seen where caused by bug fixes).  So even if we had a stable branch and an development branch, new releases of the stable could still break code.  The test suit helps a lot here however it won't catch them all.  Maybe the test suit should specifically test for >1.0 features and make sure they are not enabled in 1.0 versions.

> 
> And complains won't get better result, why not fix it by yourself? Most unfixed
> bugs are frontend related. And frontend source is open. And I don't consider the
> dummy stable branch would do any good , it just wastes time on diffing & commiting.
> Cause the idea is just simple , why not use the new version with bugs fixed?
> And some might complain new DMD version just not get right. Then I really suggest
> those people try to wait a little bit. DMD is still in development stage. Putting
>  it to STABLE status too early will never be good. Ok, of course, some people will
> lampoon 1.0 thingie. Yet, it's how commercial world goes. So don't be naive ! Be
> a realist! While you do business , you should never hope your product be stable ,
> then announce it 1.0, your product will just lose the race.
> 
> I think Walter will pay more effort on the way how DMD development goes and the
> way it will go.
> 

Some good points.  I do think 1.0 will eventually start to become more stable given time.  Its only been out for a couple of months.

-Joel

Am Thu, 12 Apr 2007 23:03:49 +0800 schrieb Davidl:

> There is nothing in the world can be free of bug while offer you new features.

True, but that's not at all the point of the discussion.

> So I think in some degree walter & DMD go in the right way.
> 
> And complains won't get better result, why not fix it by yourself? Most
> unfixed
> bugs are frontend related. And frontend source is open. And I don't

Yeah, right. I put several days into reading the D 1.011 frontend code, spend another couple of days fixing some bugs only to download 1.012 which contains some sort of modifications that break my bug fixes, because the original compiler author is not aware of them. I think this problem stops many people who would like to help with D (myself included).

Right now, the only way to contribute to the D frontend is to do a fork and work on that.

Falk

Falk-Florian Henrich Wrote:

> Am Thu, 12 Apr 2007 23:03:49 +0800 schrieb Davidl:
> 
> > There is nothing in the world can be free of bug while offer you new features.
> 
> True, but that's not at all the point of the discussion.
> 
> > So I think in some degree walter & DMD go in the right way.
> > 
> > And complains won't get better result, why not fix it by yourself? Most
> > unfixed
> > bugs are frontend related. And frontend source is open. And I don't
> 
> Yeah, right. I put several days into reading the D 1.011 frontend code, spend another couple of days fixing some bugs only to download 1.012 which contains some sort of modifications that break my bug fixes, because the original compiler author is not aware of them. I think this problem stops many people who would like to help with D (myself included).
> 
> Right now, the only way to contribute to the D frontend is to do a fork and work on that.
> 
> Falk

Well, you can't blame Walter for not guessing that you discovered and fixed bugs in the compiler. He is not omniscient.

But I second the idea that two branches are necessary. Because the idea behind a STABLE branch is to have LESS bugs for each new version, not more. You could have submitted your bug fixes to this branch.

As has already been said, which serious company could reasonably bet on a language which is always unstable ?
There is one point where one wants to be able to trust the tool of the trade. Even if this tool has acknowledged limitations, one learns to know them and how to deal with them. The good thing with a STABLE branch is, it offers a chance to see bug fixes without any risk of broken code.

Because the language evolves constantly, it is not possible for library writers to keep up.
The bad thing is, different libraries may take advantage of different features of the language because they were written for different versions of the compiler. This means that libraries are not guaranteed to be compatible with each other.

In order to insure compatibility between libraries, they must all be written for a defined set of features, i.e for a single version of the compiler (or for bug fix versions of this compiler). This would be the role of the STABLE branch.

Every year or so, the DEV branch becomes the STABLE branch, and all the library writers can update their code for the new stable compiler, taking advantage of its new features. And the application writer can then confidently use all these libraries, knowing that they are compatible.

This is more or less how all major languages evolve. Why would D be any different ?

Am Thu, 12 Apr 2007 15:43:51 -0400 schrieb Nicolas J.:

> Well, you can't blame Walter for not guessing that you discovered and fixed bugs in the compiler. He is not omniscient.

I didn't assume anyone to be omniscient, neither did I blame anyone. However, I do think the current development model is inefficient as it wastes resources: people who would like to help get turned away.

> 
> But I second the idea that two branches are necessary. Because the idea behind a STABLE branch is to have LESS bugs for each new version, not more. You could have submitted your bug fixes to this branch.

Exactly. In my opinion, the D source is not that difficult to read. If one is willing to spend some time it's not too hard to understand how it works. That's why I think a lot of people could actually help fixing bugs. Nevertheless, it would still be Walter's decision which patch to include and which to reject. There won't be to many crappy patches, and even if so, some two or three experienced people could filter them out so that Walter only has to deal with "good submissions". Probably, this would reduce his workload considerably.

> As has already been said, which serious company could reasonably bet on a language which is always unstable ? There is one point where one wants to be able to trust the tool of the trade. Even if this tool has acknowledged limitations, one learns to know them and how to deal with them. The good thing with a STABLE branch is, it offers a chance to see bug fixes without any risk of broken code.
> 
> Because the language evolves constantly, it is not possible for library writers to keep up. The bad thing is, different libraries may take advantage of different features of the language because they were written for different versions of the compiler. This means that libraries are not guaranteed to be compatible with each other.
> 
> In order to insure compatibility between libraries, they must all be written for a defined set of features, i.e for a single version of the compiler (or for bug fix versions of this compiler). This would be the role of the STABLE branch.
> 
> Every year or so, the DEV branch becomes the STABLE branch, and all the library writers can update their code for the new stable compiler, taking advantage of its new features. And the application writer can then confidently use all these libraries, knowing that they are compatible.
> 
> This is more or less how all major languages evolve. Why would D be any different ?

I totally agree.

Falk

Frank Benoit (keinfarbton) wrote:
> The frontend is open, but not the backend. So its not possible for a
> community member to merge bug fixes back and build/compile a dmd release.
> Or did i miss something?

I think the idea is that if someone wants to contribute, they can hack on GDC since the front end code is largely the same.  Though it does tend to be one or two releases behind the front end that's in DMD.

It would be cool if Walter could at least package up the proprietary back end as a lib and provide all the headers necessary to compile a working DMD with it.

--bb

On Thu, 12 Apr 2007 23:03:49 +0800, Davidl wrote:

> There is nothing in the world can be free of bug while offer you new
> features.
> So I think in some degree walter & DMD go in the right way.
> 
> And complains won't get better result, why not fix it by yourself?

Are you seriously suggesting that everyone who needs a bug fixed in DMD,
 ** make their own branch of the DMD C++ code
 ** possibly learn C++
 ** update their personal branch
 ** recompile DMD
 ** link in the closed-source back end
 ** perform regression testing on it
 ** be prepared to merge in every new release of DMD from Walter in future

Are you kidding?

Isn't the more practical way just to have Walter maintain the two branches - one that only gets bug fixes, and the other that also gets bug fixes plus new features.

-- 
Derek Parnell
Melbourne, Australia
"Justice for David Hicks!"
skype: derek.j.parnell