www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - New Features Always Come With Bugs

reply Davidl <Davidl 126.com> writes:
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.
Apr 12 2007
next sibling parent reply "Frank Benoit (keinfarbton)" <benoit tionex.removethispart.de> writes:
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?
Apr 12 2007
parent Bill Baxter <dnewsgroup billbaxter.com> writes:
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
Apr 12 2007
prev sibling next sibling parent janderson <askme me.com> writes:
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
Apr 12 2007
prev sibling next sibling parent reply Falk-Florian Henrich <schreibmalwieder hammerfort.de> writes:
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
Apr 12 2007
parent Nicolas J. <Nicolas.J. lolrofl.fakeaddress.com> writes:
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 ?
Apr 12 2007
prev sibling next sibling parent Falk-Florian Henrich <schreibmalwieder hammerfort.de> writes:
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
Apr 12 2007
prev sibling parent Derek Parnell <derek psych.ward> writes:
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
Apr 12 2007