• Davidl (25/25) Apr 12 2007 There is nothing in the world can be free of bug while offer you new
• Frank Benoit (keinfarbton) (3/3) Apr 12 2007 The frontend is open, but not the backend. So its not possible for a
• Bill Baxter (8/11) Apr 12 2007 I think the idea is that if someone wants to contribute, they can hack
• janderson (11/39) Apr 12 2007 This is true however its also true that bug fixes can cause more bugs
• Falk-Florian Henrich (10/17) Apr 12 2007 Yeah, right. I put several days into reading the D 1.011 frontend code,
• Nicolas J. (10/33) Apr 12 2007 Well, you can't blame Walter for not guessing that you discovered and fi...
• Falk-Florian Henrich (14/46) Apr 12 2007 I didn't assume anyone to be omniscient, neither did I blame anyone.
• Derek Parnell (18/23) Apr 12 2007 Are you seriously suggesting that everyone who needs a bug fixed in DMD,

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.

"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?

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

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

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

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 ?

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

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