www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - new version

reply l8night <l8night gmail.com> writes:
hi walter,

when will the next bugfix version be released?
Nov 28 2009
next sibling parent "Denis Koroskin" <2korden gmail.com> writes:
On Sat, 28 Nov 2009 11:16:22 +0300, l8night <l8night gmail.com> wrote:

 hi walter,

 when will the next bugfix version be released?

Why would you ask? Any specific bug is blocking your development?
Nov 28 2009
prev sibling next sibling parent KennyTM~ <kennytm gmail.com> writes:
On Nov 28, 09 16:16, l8night wrote:
 hi walter,

 when will the next bugfix version be released?

You could always use the svn version.
Nov 28 2009
prev sibling next sibling parent reply l8night <l8night gmail.com> writes:
Too many bugs - no way my superiors allow some program with that bug list and
the open date for version 2. worst is the slow bugfixes.
Nov 28 2009
next sibling parent "Denis Koroskin" <2korden gmail.com> writes:
On Sat, 28 Nov 2009 23:28:51 +0300, l8night <l8night gmail.com> wrote:

 Too many bugs - no way my superiors allow some program with that bug  
 list and the open date for version 2. worst is the slow bugfixes.

What bugs are you talking about? Mark it as a blocker if that's a known one, or submit a bugreport if it's not in bugzilla yet.
Nov 28 2009
prev sibling next sibling parent reply BCS <none anon.com> writes:
Hello l8night,

 Too many bugs - no way my superiors allow some program with that bug
 list and the open date for version 2. worst is the slow bugfixes.
 

Check me on this but there may be more know bugs in things like FireFox then in DMD. The length of the bug list in and of its self say almost nothing about a program. (OTOH it makes a handy metric for people who don't know that.) To answer your original question; look at the change log to get an idea about how fast versions come out. "Within a month or so" would be a good guess for minor versions. If your talking about V3, expect a few years.
Nov 30 2009
parent reply dsimcha <dsimcha yahoo.com> writes:
== Quote from BCS (none anon.com)'s article
 Hello l8night,
 Too many bugs - no way my superiors allow some program with that bug
 list and the open date for version 2. worst is the slow bugfixes.

in DMD. The length of the bug list in and of its self say almost nothing about a program. (OTOH it makes a handy metric for people who don't know that.) To answer your original question; look at the change log to get an idea about how fast versions come out. "Within a month or so" would be a good guess for minor versions. If your talking about V3, expect a few years.

What's really important is how many *severe* bugs there are, i.e. bugs that really have a major effect on the usability of the language. There are a few features, such as array ops and alias this, where DMD is buggy enough that these features are practically useless. On the other hand, I don't get too mad about this because these are features that most other languages just plain don't have, and the situation is continually and rapidly improving (thanks to Walter and Don). Even if the *total* bug count is going up, IMHO the *severe* bug count is going down.
Nov 30 2009
parent reply l8night <l8night gmail.com> writes:
hi,
thank you all for your answers. i think your are right with “look for the
severity of bugs”. for my superiors however the thing is different. they just
see a huge amount of bugs, missing gui libraries, missing database libraries
and nothing close to anything that m$ offers in the way of development. than
there are 2 libraries, one with no collections and no way they seem to come
together. There is no advertising (such as go language) and seemingly slow
updates (bug fixes).
and for me - shit if this doesn’t change somehow to the better, i end up doing
the next tool/project in delphi instead of D2.
and that sucks, since i at least got them to think about D.


dsimcha Wrote:

 == Quote from BCS (none anon.com)'s article
 Hello l8night,
 Too many bugs - no way my superiors allow some program with that bug
 list and the open date for version 2. worst is the slow bugfixes.

in DMD. The length of the bug list in and of its self say almost nothing about a program. (OTOH it makes a handy metric for people who don't know that.) To answer your original question; look at the change log to get an idea about how fast versions come out. "Within a month or so" would be a good guess for minor versions. If your talking about V3, expect a few years.

What's really important is how many *severe* bugs there are, i.e. bugs that really have a major effect on the usability of the language. There are a few features, such as array ops and alias this, where DMD is buggy enough that these features are practically useless. On the other hand, I don't get too mad about this because these are features that most other languages just plain don't have, and the situation is continually and rapidly improving (thanks to Walter and Don). Even if the *total* bug count is going up, IMHO the *severe* bug count is going down.

Nov 30 2009
parent Don <nospam nospam.com> writes:
l8night wrote:
 hi,
 thank you all for your answers. i think your are right with “look for the
severity of bugs”. for my superiors however the thing is different. they just
see a huge amount of bugs, missing gui libraries, missing database libraries
and nothing close to anything that m$ offers in the way of development. than
there are 2 libraries, one with no collections and no way they seem to come
together. There is no advertising (such as go language) and seemingly slow
updates (bug fixes).
 and for me - shit if this doesn’t change somehow to the better, i end up doing
the next tool/project in delphi instead of D2.
 and that sucks, since i at least got them to think about D.

Yes, that's always been a problem. But it seems there'll be only a couple more releases before there is a feature-complete D2 release. Once that happens, we'll stop having bugs due to newly-introduced features. Also, now that the severe bug count has dropped so much, it's getting easier to deal with the minor ones. Obviously there's still a very long way to go.
 
 dsimcha Wrote:
 
 == Quote from BCS (none anon.com)'s article
 Hello l8night,
 Too many bugs - no way my superiors allow some program with that bug
 list and the open date for version 2. worst is the slow bugfixes.

in DMD. The length of the bug list in and of its self say almost nothing about a program. (OTOH it makes a handy metric for people who don't know that.) To answer your original question; look at the change log to get an idea about how fast versions come out. "Within a month or so" would be a good guess for minor versions. If your talking about V3, expect a few years.

have a major effect on the usability of the language. There are a few features, such as array ops and alias this, where DMD is buggy enough that these features are practically useless. On the other hand, I don't get too mad about this because these are features that most other languages just plain don't have, and the situation is continually and rapidly improving (thanks to Walter and Don). Even if the *total* bug count is going up, IMHO the *severe* bug count is going down.


Nov 30 2009
prev sibling next sibling parent reply Walter Bright <newshound1 digitalmars.com> writes:
l8night wrote:
 Too many bugs - no way my superiors allow some program with that bug list

Here's the gcc bug list with 5,442 open issues: http://gcc.gnu.org/bugzilla/buglist.cgi?query_format=specific&order=relevance+desc&bug_status=__open__&product=&content= and the d bug list with 1,403 open issues: http://d.puremagic.com/issues/buglist.cgi?query_format=advanced&short_desc_type=allwordssubstr&short_desc=&long_desc_type=allwordssubstr&long_desc=&bug_file_loc_type=allwordssubstr&bug_file_loc=&keywords_type=allwords&keywords=&bug_status=NEW&bug_status=ASSIGNED&bug_status=REOPENED&emailassigned_to1=1&emailtype1=substring&email1=&emailassigned_to2=1&emailreporter2=1&emailcc2=1&emailtype2=substring&email2=&bugidtype=include&bug_id=&votes=&chfieldfrom=&chfieldto=Now&chfieldvalue=&cmdtype=doit&order=Bug+Number&remtype=asdefault&field0-0-0=noop&type0-0-0=noop&value0-0-0=
Dec 02 2009
next sibling parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
Leandro Lucarella wrote:
 Walter Bright, el  2 de diciembre a las 12:23 me escribiste:
 l8night wrote:
 Too many bugs - no way my superiors allow some program with that bug list

http://gcc.gnu.org/bugzilla/buglist.cgi?query_format=specific&order=relevance+desc&bug_status=__open__&product=&content= and the d bug list with 1,403 open issues: http://d.puremagic.com/issues/buglist.cgi?query_format=advanced&short_desc_type=allwordssubstr&short_desc=&long_desc_type=allwordssubstr&long_desc=&bug_file_loc_type=allwordssubstr&bug_file_loc=&keywords_type=allwords&keywords=&bug_status=NEW&bug_status=ASSIGNED&bug_status=REOPENED&emailassigned_to1=1&emailtype1=substring&email1=&emailassigned_to2=1&emailreporter2=1&emailcc2=1&emailtype2=substring&email2=&bugidtype=include&bug_id=&votes=&chfieldfrom=&chfieldto=Now&chfieldvalue=&cmdtype=doit&order=Bug+Number&remtype=asdefault&field0-0-0=noop&type0-0-0=noop&value0-0-0=

I'd like to compare the user base and calculate the bugs/users ratio. I guess GCC's would be orders of magnitude smaller.

I haven't heard of bug/user ratio (but then I know next to nothing about such metrics). Probably you want to take the bugs * users product. One bug affects more users in a popular product. Andrei
Dec 02 2009
next sibling parent reply Don <nospam nospam.com> writes:
Andrei Alexandrescu wrote:
 Leandro Lucarella wrote:
 Walter Bright, el  2 de diciembre a las 12:23 me escribiste:
 l8night wrote:
 Too many bugs - no way my superiors allow some program with that bug 
 list

http://gcc.gnu.org/bugzilla/buglist.cgi?query_format=specific&order=relevance+desc&bug_status=__open _&product=&content= and the d bug list with 1,403 open issues: http://d.puremagic.com/issues/buglist.cgi?query_format=advanced&short_desc_type=allwordssubstr&short_desc=&long_desc_type=allwordssubstr&long_desc=&bug_file_loc_type=allwordssubstr&bug_file_loc=&keywords_type=allwords&keywords=&bug_status=NEW&bug_status=ASSIGNED&bug_status=REOPENED&emailassigned_to1=1&emailtype1=substring&email1=&emailassigned_to2=1&emailreporter2=1&emailcc2=1&emailtype2=substring&email2=&bugidtype=include&bug_id=&votes=&chfieldfrom=&chfieldto=Now&chfieldvalue=&cmdtype=doit&order=Bug+Number&remtype=asdefault&field0-0-0=noop&type0- -0=noop&value0-0-0=

I'd like to compare the user base and calculate the bugs/users ratio. I guess GCC's would be orders of magnitude smaller.

I haven't heard of bug/user ratio (but then I know next to nothing about such metrics). Probably you want to take the bugs * users product. One bug affects more users in a popular product. Andrei

imagine. The more users you have, the higher the fraction of the total number of bugs that you find. Bug reports ought to follow a logistic curve: a small number of bugs means that you have very few users, or that you are Knuth.
Dec 02 2009
parent Walter Bright <newshound1 digitalmars.com> writes:
Don wrote:
 Interesting question. It'll be some kind of binomial distibution, I 
 imagine. The more users you have, the higher the fraction of the total 
 number of bugs that you find. Bug reports ought to follow a logistic 
 curve: a small number of bugs means that you have very few users, or 
 that you are Knuth.

I've definitely noticed that the bug count goes up the more use a product gets. No bugs == nobody using it. It's not a linear thing, though, as you get more users they will mostly rediscover the same issues.
Dec 02 2009
prev sibling parent Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
Leandro Lucarella wrote:
 Andrei Alexandrescu, el  2 de diciembre a las 13:03 me escribiste:
 Leandro Lucarella wrote:
 Walter Bright, el  2 de diciembre a las 12:23 me escribiste:
 l8night wrote:
 Too many bugs - no way my superiors allow some program with that bug list

http://gcc.gnu.org/bugzilla/buglist.cgi?query_format=specific&order=relevance+desc&bug_status=__open__&product=&content= and the d bug list with 1,403 open issues: http://d.puremagic.com/issues/buglist.cgi?query_format=advanced&short_desc_type=allwordssubstr&short_desc=&long_desc_type=allwordssubstr&long_desc=&bug_file_loc_type=allwordssubstr&bug_file_loc=&keywords_type=allwords&keywords=&bug_status=NEW&bug_status=ASSIGNED&bug_status=REOPENED&emailassigned_to1=1&emailtype1=substring&email1=&emailassigned_to2=1&emailreporter2=1&emailcc2=1&emailtype2=substring&email2=&bugidtype=include&bug_id=&votes=&chfieldfrom=&chfieldto=Now&chfieldvalue=&cmdtype=doit&order=Bug+Number&remtype=asdefault&field0-0-0=noop&type0-0-0=noop&value0-0-0=

I guess GCC's would be orders of magnitude smaller.

about such metrics). Probably you want to take the bugs * users product. One bug affects more users in a popular product.

You are asuming all bugs affect all users, which is far from reality.

There would be a normalization constant, but as far as I know I need to be convinced that bugs/user is of any more relevance than bugs * user. Andrei
Dec 02 2009
prev sibling next sibling parent dsimcha <dsimcha yahoo.com> writes:
== Quote from Leandro Lucarella (llucax gmail.com)'s article
 And BTW, GCC implements 7 languages (at least 7 languages are present as
 bugzilla components: ada, c, c++, fortran, java, objc and objc++), so
 doing a rough estimative, 5442/7 ~= 800, less than DMD, which implements
 only D.
 Seriously Walter, you *can't* possibly compare DMD with GCC, it's almost
 funny when you do it =P

The comparison is ridiculous anyway. D is a rapidly evolving language that doesn't even have a stable spec yet. "Walking on water and developing software from a specification are easy if both are frozen." -- Edward V Berard Seriously, all of the languages GCC implements have been around since at least the Paleozoic Era, some since the Big Bang. This means that they have a stable spec and that there's been plenty of time for bug fixing. A lot of bugs in Bugzilla are D2-only, though I can't quantify this. D1 had been relatively well-debugged. If you want the latest and greatest features, you have to accept the possibility of more bugs. This is, always has been, and always will be a fact of life in all software and it's ridiculous to think that D should somehow be an exception.
Dec 02 2009
prev sibling next sibling parent reply Walter Bright <newshound1 digitalmars.com> writes:
Leandro Lucarella wrote:
 Leandro Lucarella, el  2 de diciembre a las 17:53 me escribiste:
 Walter Bright, el  2 de diciembre a las 12:23 me escribiste:
 l8night wrote:
 Too many bugs - no way my superiors allow some program with that bug list

http://gcc.gnu.org/bugzilla/buglist.cgi?query_format=specific&order=relevance+desc&bug_status=__open__&product=&content= and the d bug list with 1,403 open issues: http://d.puremagic.com/issues/buglist.cgi?query_format=advanced&short_desc_type=allwordssubstr&short_desc=&long_desc_type=allwordssubstr&long_desc=&bug_file_loc_type=allwordssubstr&bug_file_loc=&keywords_type=allwords&keywords=&bug_status=NEW&bug_status=ASSIGNED&bug_status=REOPENED&emailassigned_to1=1&emailtype1=substring&email1=&emailassigned_to2=1&emailreporter2=1&emailcc2=1&emailtype2=substring&email2=&bugidtype=include&bug_id=&votes=&chfieldfrom=&chfieldto=Now&chfieldvalue=&cmdtype=doit&order=Bug+Number&remtype=asdefault&field0-0-0=noop&type0-0-0=noop&value0-0-0=

I guess GCC's would be orders of magnitude smaller.

And BTW, GCC implements 7 languages (at least 7 languages are present as bugzilla components: ada, c, c++, fortran, java, objc and objc++), so doing a rough estimative, 5442/7 ~= 800, less than DMD, which implements only D. Seriously Walter, you *can't* possibly compare DMD with GCC, it's almost funny when you do it =P

My post was in response to the bug *count* being a showstopper. My point is it's absurd, because you can always slice the data to mean whatever you want it to mean. For example, many of the "bugs" in the dmd list are enhancement requests, bugs in the library (not the compiler), bugs in the documentation (not the compiler), etc. My original resistance to even having a public buglist is precisely because people will merely count the number of issues and declare it to be a "buggy" product.
Dec 02 2009
next sibling parent Walter Bright <newshound1 digitalmars.com> writes:
Leandro Lucarella wrote:
 Walter Bright, el  2 de diciembre a las 13:29 me escribiste:
 I'd like to compare the user base and calculate the bugs/users ratio.
 I guess GCC's would be orders of magnitude smaller.

bugzilla components: ada, c, c++, fortran, java, objc and objc++), so doing a rough estimative, 5442/7 ~= 800, less than DMD, which implements only D. Seriously Walter, you *can't* possibly compare DMD with GCC, it's almost funny when you do it =P

point is it's absurd, because you can always slice the data to mean whatever you want it to mean. For example, many of the "bugs" in the dmd list are enhancement requests, bugs in the library (not the compiler), bugs in the documentation (not the compiler), etc.

Sure, but your comparison with GCC just makes things more absurd, not less. I completely agree with you that bug count (alone) is not a good measure of compiler quality, I just don't agree with the GCC comparison to prove it.

I *meant* to show it was absurd by showing the GCC bug list.
 I hope you can change the license some time, and you start
 encouraging other people involvement more actively, so the number of
 contributors to DMD keep growing.

I encourage other people to submit patches. Don has been especially productive in this. But I still want to be the gateway to getting them integrated into the trunk, because otherwise I will lose track of how it works, and because sometimes patches are not quite the right place to fix the problem, although they are usually close and still very helpful.
Dec 02 2009
prev sibling parent Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
Leandro Lucarella wrote:
 Walter Bright, el  2 de diciembre a las 13:29 me escribiste:
 I'd like to compare the user base and calculate the bugs/users ratio.
 I guess GCC's would be orders of magnitude smaller.

bugzilla components: ada, c, c++, fortran, java, objc and objc++), so doing a rough estimative, 5442/7 ~= 800, less than DMD, which implements only D. Seriously Walter, you *can't* possibly compare DMD with GCC, it's almost funny when you do it =P

point is it's absurd, because you can always slice the data to mean whatever you want it to mean. For example, many of the "bugs" in the dmd list are enhancement requests, bugs in the library (not the compiler), bugs in the documentation (not the compiler), etc.

Sure, but your comparison with GCC just makes things more absurd, not less. I completely agree with you that bug count (alone) is not a good measure of compiler quality, I just don't agree with the GCC comparison to prove it. And I think DMD is far buggier than GCC, I just never came across a GCC bug, and I hit several DMD bugs (and I use GCC much, *MUCH* more than DMD). I think GCC being developed by hundreds of people is the big factor. DMD is getting *FAR* better since you opened the code.
 My original resistance to even having a public buglist is precisely
 because people will merely count the number of issues and declare it
 to be a "buggy" product.

No, I think people thinks DMD is buggy because if you code in D, you are almost guaranteed to end up filling a bug report (or at least searching for one and seeing it's already reported). That doesn't happen with GCC. Again, fortunately, since you opened the DMD code, this is improving fairly fast. I hope you can change the license some time, and you start encouraging other people involvement more actively, so the number of contributors to DMD keep growing.

Historically GCC has been extremely buggy. It has really made a turnaround of reputation. What it was notorious for only seven years ago was for bugs, incompatibilities, slow compilation, and generation of slow code. Andrei
Dec 02 2009
prev sibling next sibling parent Don <nospam nospam.com> writes:
Leandro Lucarella wrote:
 Leandro Lucarella, el  2 de diciembre a las 17:53 me escribiste:
 Walter Bright, el  2 de diciembre a las 12:23 me escribiste:
 l8night wrote:
 Too many bugs - no way my superiors allow some program with that bug list

http://gcc.gnu.org/bugzilla/buglist.cgi?query_format=specific&order=relevance+desc&bug_status=__open__&product=&content= and the d bug list with 1,403 open issues: http://d.puremagic.com/issues/buglist.cgi?query_format=advanced&short_desc_type=allwordssubstr&short_desc=&long_desc_type=allwordssubstr&long_desc=&bug_file_loc_type=allwordssubstr&bug_file_loc=&keywords_type=allwords&keywords=&bug_status=NEW&bug_status=ASSIGNED&bug_status=REOPENED&emailassigned_to1=1&emailtype1=substring&email1=&emailassigned_to2=1&emailreporter2=1&emailcc2=1&emailtype2=substring&email2=&bugidtype=include&bug_id=&votes=&chfieldfrom=&chfieldto=Now&chfieldvalue=&cmdtype=doit&order=Bug+Number&remtype=asdefault&field0-0-0=noop&type0-0-0=noop&value0-0-0=

I guess GCC's would be orders of magnitude smaller.

And BTW, GCC implements 7 languages (at least 7 languages are present as bugzilla components: ada, c, c++, fortran, java, objc and objc++), so doing a rough estimative, 5442/7 ~= 800, less than DMD, which implements only D. Seriously Walter, you *can't* possibly compare DMD with GCC, it's almost funny when you do it =P

I think it's a fair comparison in this case. The original poster had said that he couldn't use DMD because it has so many open bugs. I would presume that he can't use GCC either, for the same reason. But probably "total number of open bugs" is not the real criterion; as you say, a mindless comparison gives quite ridiculous results (suggesting that dmd is more stable than gcc!)
Dec 02 2009
prev sibling parent reply Eldar Insafutdinov <e.insafutdinov gmail.com> writes:
Leandro Lucarella Wrote:

 Walter Bright, el  2 de diciembre a las 12:23 me escribiste:
 l8night wrote:
Too many bugs - no way my superiors allow some program with that bug list

Here's the gcc bug list with 5,442 open issues: http://gcc.gnu.org/bugzilla/buglist.cgi?query_format=specific&order=relevance+desc&bug_status=__open__&product=&content= and the d bug list with 1,403 open issues: http://d.puremagic.com/issues/buglist.cgi?query_format=advanced&short_desc_type=allwordssubstr&short_desc=&long_desc_type=allwordssubstr&long_desc=&bug_file_loc_type=allwordssubstr&bug_file_loc=&keywords_type=allwords&keywords=&bug_status=NEW&bug_status=ASSIGNED&bug_status=REOPENED&emailassigned_to1=1&emailtype1=substring&email1=&emailassigned_to2=1&emailreporter2=1&emailcc2=1&emailtype2=substring&email2=&bugidtype=include&bug_id=&votes=&chfieldfrom=&chfieldto=Now&chfieldvalue=&cmdtype=doit&order=Bug+Number&remtype=asdefault&field0-0-0=noop&type0-0-0=noop&value0-0-0=

I'd like to compare the user base and calculate the bugs/users ratio. I guess GCC's would be orders of magnitude smaller. -- Leandro Lucarella (AKA luca) http://llucax.com.ar/ ---------------------------------------------------------------------- GPG Key: 5F5A8D05 (F8CD F9A7 BF00 5431 4145 104C 949E BFB6 5F5A 8D05) ---------------------------------------------------------------------- There is no such thing as right or wrong Only consequences

What Leandro meant to say by this, that if dmd had a user base the size of gcc, the amount of bugs would be significantly bigger than currently.
Dec 02 2009
parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
Eldar Insafutdinov wrote:
 Leandro Lucarella Wrote:
 
 Walter Bright, el  2 de diciembre a las 12:23 me escribiste:
 l8night wrote:
 Too many bugs - no way my superiors allow some program with that bug list

http://gcc.gnu.org/bugzilla/buglist.cgi?query_format=specific&order=relevance+desc&bug_status=__open__&product=&content= and the d bug list with 1,403 open issues: http://d.puremagic.com/issues/buglist.cgi?query_format=advanced&short_desc_type=allwordssubstr&short_desc=&long_desc_type=allwordssubstr&long_desc=&bug_file_loc_type=allwordssubstr&bug_file_loc=&keywords_type=allwords&keywords=&bug_status=NEW&bug_status=ASSIGNED&bug_status=REOPENED&emailassigned_to1=1&emailtype1=substring&email1=&emailassigned_to2=1&emailreporter2=1&emailcc2=1&emailtype2=substring&email2=&bugidtype=include&bug_id=&votes=&chfieldfrom=&chfieldto=Now&chfieldvalue=&cmdtype=doit&order=Bug+Number&remtype=asdefault&field0-0-0=noop&type0-0-0=noop&value0-0-0=

I guess GCC's would be orders of magnitude smaller. -- Leandro Lucarella (AKA luca) http://llucax.com.ar/ ---------------------------------------------------------------------- GPG Key: 5F5A8D05 (F8CD F9A7 BF00 5431 4145 104C 949E BFB6 5F5A 8D05) ---------------------------------------------------------------------- There is no such thing as right or wrong Only consequences

What Leandro meant to say by this, that if dmd had a user base the size of gcc, the amount of bugs would be significantly bigger than currently.

There's also the ratio of bugs/developer to think of. Andrei
Dec 02 2009
parent l8night <l8night gmail.com> writes:
hi,

gcc is widely used for a long time and everybody knows it has bug. it seems
like a case, that is regulated by the fda. if a software is used more than
250000 time it is regarded as being validated. this is not the case here and
everybody perceives d as being utterly new, even if it is around a long time.
the lack of tools and libraries for commercial development is hurting too. most
organizations looking at d, want to use it and not develop it. it is a matter
of time.


gcc is widly 

Andrei Alexandrescu Wrote:

 Eldar Insafutdinov wrote:
 Leandro Lucarella Wrote:
 
 Walter Bright, el  2 de diciembre a las 12:23 me escribiste:
 l8night wrote:
 Too many bugs - no way my superiors allow some program with that bug list

http://gcc.gnu.org/bugzilla/buglist.cgi?query_format=specific&order=relevance+desc&bug_status=__open__&product=&content= and the d bug list with 1,403 open issues: http://d.puremagic.com/issues/buglist.cgi?query_format=advanced&short_desc_type=allwordssubstr&short_desc=&long_desc_type=allwordssubstr&long_desc=&bug_file_loc_type=allwordssubstr&bug_file_loc=&keywords_type=allwords&keywords=&bug_status=NEW&bug_status=ASSIGNED&bug_status=REOPENED&emailassigned_to1=1&emailtype1=substring&email1=&emailassigned_to2=1&emailreporter2=1&emailcc2=1&emailtype2=substring&email2=&bugidtype=include&bug_id=&votes=&chfieldfrom=&chfieldto=Now&chfieldvalue=&cmdtype=doit&order=Bug+Number&remtype=asdefault&field0-0-0=noop&type0-0-0=noop&value0-0-0=

I guess GCC's would be orders of magnitude smaller. -- Leandro Lucarella (AKA luca) http://llucax.com.ar/ ---------------------------------------------------------------------- GPG Key: 5F5A8D05 (F8CD F9A7 BF00 5431 4145 104C 949E BFB6 5F5A 8D05) ---------------------------------------------------------------------- There is no such thing as right or wrong Only consequences

What Leandro meant to say by this, that if dmd had a user base the size of gcc, the amount of bugs would be significantly bigger than currently.

There's also the ratio of bugs/developer to think of. Andrei

Dec 02 2009
prev sibling next sibling parent retard <re tard.com.invalid> writes:
Wed, 02 Dec 2009 22:48:14 +0100, Don wrote:

 Andrei Alexandrescu wrote:
 Leandro Lucarella wrote:
 Walter Bright, el  2 de diciembre a las 12:23 me escribiste:
 l8night wrote:
 Too many bugs - no way my superiors allow some program with that bug
 list

http://gcc.gnu.org/bugzilla/buglist.cgi?




+desc&bug_status=__open__&product=&content=
 and the d bug list with 1,403 open issues:

 http://d.puremagic.com/issues/buglist.cgi?




+Number&remtype=asdefault&field0-0-0=noop&type0-0-0=noop&value0-0-0=

I guess GCC's would be orders of magnitude smaller.

I haven't heard of bug/user ratio (but then I know next to nothing about such metrics). Probably you want to take the bugs * users product. One bug affects more users in a popular product. Andrei

imagine. The more users you have, the higher the fraction of the total number of bugs that you find. Bug reports ought to follow a logistic curve: a small number of bugs means that you have very few users, or that you are Knuth.

You should also keep track of the size of target audience on each platform it supports. If a VAX port has 2 million bugs and x86 version 5, it's not fair to say gcc has thousands of bugs per arch on average. VAX only has a handful of users these days, but x86 has hundreds of millions. What matters to an end user is the amount of bugs on the platform (s)he is on. Some bugs are also more serious than others. Some applications on the shiny leading star of open source desktops, kde 4, can be crashed with less than 10 keypresses on all supported arches because the QA sucks. OTOH if you need 1000 specially hand crafted LOC to trigger a bug in some c++ compiler, that bug has a lot lower visibility. C/C++ compilers like gcc have very little amounts of easily accessible bugs. They have a huge test suite - almost every desktop application is succesfully compiled with them. DMD, on the other hand, has trivial bugs (also in the spec) that affect the end user experience very quickly. For instance you can't tell by looking at the spec what this does: template T(A...) { alias A T; } class B: private Object { T!(int,int) b; } void main() { writefln(B.tupleof.stringof); }
Dec 02 2009
prev sibling parent "Simen kjaeraas" <simen.kjaras gmail.com> writes:
Leandro Lucarella <llucax gmail.com> wrote:

 Maybe you could comment on patches, and tell people how to fix them to be
 accepted, that help a lot when you're willing to contribute. It's really
 frustrating when you make a patch and it's not accepted (or delayed) and
 you don't know why. This way people can learn about the code too, and
 where the fix should be really in, and how do you like patches to be
 formatted, etc.

 A mailing list (or NG) to submit patches and doing peer review would be
 really nice

I really like this idea - votes++ -- Simen
Dec 02 2009
prev sibling next sibling parent Leandro Lucarella <llucax gmail.com> writes:
Walter Bright, el  2 de diciembre a las 12:23 me escribiste:
 l8night wrote:
Too many bugs - no way my superiors allow some program with that bug list

Here's the gcc bug list with 5,442 open issues: http://gcc.gnu.org/bugzilla/buglist.cgi?query_format=specific&order=relevance+desc&bug_status=__open__&product=&content= and the d bug list with 1,403 open issues: http://d.puremagic.com/issues/buglist.cgi?query_format=advanced&short_desc_type=allwordssubstr&short_desc=&long_desc_type=allwordssubstr&long_desc=&bug_file_loc_type=allwordssubstr&bug_file_loc=&keywords_type=allwords&keywords=&bug_status=NEW&bug_status=ASSIGNED&bug_status=REOPENED&emailassigned_to1=1&emailtype1=substring&email1=&emailassigned_to2=1&emailreporter2=1&emailcc2=1&emailtype2=substring&email2=&bugidtype=include&bug_id=&votes=&chfieldfrom=&chfieldto=Now&chfieldvalue=&cmdtype=doit&order=Bug+Number&remtype=asdefault&field0-0-0=noop&type0-0-0=noop&value0-0-0=

I'd like to compare the user base and calculate the bugs/users ratio. I guess GCC's would be orders of magnitude smaller. -- Leandro Lucarella (AKA luca) http://llucax.com.ar/ ---------------------------------------------------------------------- GPG Key: 5F5A8D05 (F8CD F9A7 BF00 5431 4145 104C 949E BFB6 5F5A 8D05) ---------------------------------------------------------------------- There is no such thing as right or wrong Only consequences
Dec 02 2009
prev sibling next sibling parent Leandro Lucarella <llucax gmail.com> writes:
Leandro Lucarella, el  2 de diciembre a las 17:53 me escribiste:
 Walter Bright, el  2 de diciembre a las 12:23 me escribiste:
 l8night wrote:
Too many bugs - no way my superiors allow some program with that bug list

Here's the gcc bug list with 5,442 open issues: http://gcc.gnu.org/bugzilla/buglist.cgi?query_format=specific&order=relevance+desc&bug_status=__open__&product=&content= and the d bug list with 1,403 open issues: http://d.puremagic.com/issues/buglist.cgi?query_format=advanced&short_desc_type=allwordssubstr&short_desc=&long_desc_type=allwordssubstr&long_desc=&bug_file_loc_type=allwordssubstr&bug_file_loc=&keywords_type=allwords&keywords=&bug_status=NEW&bug_status=ASSIGNED&bug_status=REOPENED&emailassigned_to1=1&emailtype1=substring&email1=&emailassigned_to2=1&emailreporter2=1&emailcc2=1&emailtype2=substring&email2=&bugidtype=include&bug_id=&votes=&chfieldfrom=&chfieldto=Now&chfieldvalue=&cmdtype=doit&order=Bug+Number&remtype=asdefault&field0-0-0=noop&type0-0-0=noop&value0-0-0=

I'd like to compare the user base and calculate the bugs/users ratio. I guess GCC's would be orders of magnitude smaller.

And BTW, GCC implements 7 languages (at least 7 languages are present as bugzilla components: ada, c, c++, fortran, java, objc and objc++), so doing a rough estimative, 5442/7 ~= 800, less than DMD, which implements only D. Seriously Walter, you *can't* possibly compare DMD with GCC, it's almost funny when you do it =P -- Leandro Lucarella (AKA luca) http://llucax.com.ar/ ---------------------------------------------------------------------- GPG Key: 5F5A8D05 (F8CD F9A7 BF00 5431 4145 104C 949E BFB6 5F5A 8D05) ---------------------------------------------------------------------- - Mire, don Inodoro! Una paloma con un anillo en la pata! Debe ser mensajera y cayó aquí! - Y... si no es mensajera es coqueta... o casada. -- Mendieta e Inodoro Pereyra
Dec 02 2009
prev sibling next sibling parent Leandro Lucarella <llucax gmail.com> writes:
Walter Bright, el  2 de diciembre a las 13:29 me escribiste:
I'd like to compare the user base and calculate the bugs/users ratio.
I guess GCC's would be orders of magnitude smaller.

And BTW, GCC implements 7 languages (at least 7 languages are present as bugzilla components: ada, c, c++, fortran, java, objc and objc++), so doing a rough estimative, 5442/7 ~= 800, less than DMD, which implements only D. Seriously Walter, you *can't* possibly compare DMD with GCC, it's almost funny when you do it =P

My post was in response to the bug *count* being a showstopper. My point is it's absurd, because you can always slice the data to mean whatever you want it to mean. For example, many of the "bugs" in the dmd list are enhancement requests, bugs in the library (not the compiler), bugs in the documentation (not the compiler), etc.

Sure, but your comparison with GCC just makes things more absurd, not less. I completely agree with you that bug count (alone) is not a good measure of compiler quality, I just don't agree with the GCC comparison to prove it. And I think DMD is far buggier than GCC, I just never came across a GCC bug, and I hit several DMD bugs (and I use GCC much, *MUCH* more than DMD). I think GCC being developed by hundreds of people is the big factor. DMD is getting *FAR* better since you opened the code.
 My original resistance to even having a public buglist is precisely
 because people will merely count the number of issues and declare it
 to be a "buggy" product.

No, I think people thinks DMD is buggy because if you code in D, you are almost guaranteed to end up filling a bug report (or at least searching for one and seeing it's already reported). That doesn't happen with GCC. Again, fortunately, since you opened the DMD code, this is improving fairly fast. I hope you can change the license some time, and you start encouraging other people involvement more actively, so the number of contributors to DMD keep growing. -- Leandro Lucarella (AKA luca) http://llucax.com.ar/ ---------------------------------------------------------------------- GPG Key: 5F5A8D05 (F8CD F9A7 BF00 5431 4145 104C 949E BFB6 5F5A 8D05) ---------------------------------------------------------------------- Sometimes I think the sure sign that life exists elsewhere in the universe Is that that none of them tried to contact us
Dec 02 2009
prev sibling next sibling parent Leandro Lucarella <llucax gmail.com> writes:
Andrei Alexandrescu, el  2 de diciembre a las 13:03 me escribiste:
 Leandro Lucarella wrote:
Walter Bright, el  2 de diciembre a las 12:23 me escribiste:
l8night wrote:
Too many bugs - no way my superiors allow some program with that bug list

http://gcc.gnu.org/bugzilla/buglist.cgi?query_format=specific&order=relevance+desc&bug_status=__open__&product=&content= and the d bug list with 1,403 open issues: http://d.puremagic.com/issues/buglist.cgi?query_format=advanced&short_desc_type=allwordssubstr&short_desc=&long_desc_type=allwordssubstr&long_desc=&bug_file_loc_type=allwordssubstr&bug_file_loc=&keywords_type=allwords&keywords=&bug_status=NEW&bug_status=ASSIGNED&bug_status=REOPENED&emailassigned_to1=1&emailtype1=substring&email1=&emailassigned_to2=1&emailreporter2=1&emailcc2=1&emailtype2=substring&email2=&bugidtype=include&bug_id=&votes=&chfieldfrom=&chfieldto=Now&chfieldvalue=&cmdtype=doit&order=Bug+Number&remtype=asdefault&field0-0-0=noop&type0-0-0=noop&value0-0-0=

I'd like to compare the user base and calculate the bugs/users ratio. I guess GCC's would be orders of magnitude smaller.

I haven't heard of bug/user ratio (but then I know next to nothing about such metrics). Probably you want to take the bugs * users product. One bug affects more users in a popular product.

You are asuming all bugs affect all users, which is far from reality. I don't know what metric one could take to calculate bug <-> number of users affected to calculate a meaningful "affected users count". -- Leandro Lucarella (AKA luca) http://llucax.com.ar/ ---------------------------------------------------------------------- GPG Key: 5F5A8D05 (F8CD F9A7 BF00 5431 4145 104C 949E BFB6 5F5A 8D05) ---------------------------------------------------------------------- All men are born equal But quite a few get over it
Dec 02 2009
prev sibling parent reply Leandro Lucarella <llucax gmail.com> writes:
Walter Bright, el  2 de diciembre a las 14:46 me escribiste:
 Leandro Lucarella wrote:
Walter Bright, el  2 de diciembre a las 13:29 me escribiste:
I'd like to compare the user base and calculate the bugs/users ratio.
I guess GCC's would be orders of magnitude smaller.

bugzilla components: ada, c, c++, fortran, java, objc and objc++), so doing a rough estimative, 5442/7 ~= 800, less than DMD, which implements only D. Seriously Walter, you *can't* possibly compare DMD with GCC, it's almost funny when you do it =P

point is it's absurd, because you can always slice the data to mean whatever you want it to mean. For example, many of the "bugs" in the dmd list are enhancement requests, bugs in the library (not the compiler), bugs in the documentation (not the compiler), etc.

Sure, but your comparison with GCC just makes things more absurd, not less. I completely agree with you that bug count (alone) is not a good measure of compiler quality, I just don't agree with the GCC comparison to prove it.

I *meant* to show it was absurd by showing the GCC bug list.

OK, my bad then. Sorry for the noise.
I hope you can change the license some time, and you start
encouraging other people involvement more actively, so the number of
contributors to DMD keep growing.

I encourage other people to submit patches. Don has been especially productive in this. But I still want to be the gateway to getting them integrated into the trunk, because otherwise I will lose track of how it works,

Sure, that's a good idea. Git (and DVCS in general) are very helpful in managing projects like this, with a person in charge as a gateway.
 and because sometimes patches are not quite the right place to fix the
 problem, although they are usually close and still very helpful.

Maybe you could comment on patches, and tell people how to fix them to be accepted, that help a lot when you're willing to contribute. It's really frustrating when you make a patch and it's not accepted (or delayed) and you don't know why. This way people can learn about the code too, and where the fix should be really in, and how do you like patches to be formatted, etc. A mailing list (or NG) to submit patches and doing peer review would be really nice, and I think it will be a big boost to D open-source-friendliness, which will attract more people to contribute. Right now it looks like making a patch is not much better than simply suggesting a feature (or submitting a bug), even when in reality it could be true that features or bugs with patches are much closer to make it, because the lack of feedback. You never know if your patch is not applied because it sucked, because is missing some little detail or because you never saw it. I hope you think about this, really, I think D is needing even more tools to attract contributions :) Thanks! -- Leandro Lucarella (AKA luca) http://llucax.com.ar/ ---------------------------------------------------------------------- GPG Key: 5F5A8D05 (F8CD F9A7 BF00 5431 4145 104C 949E BFB6 5F5A 8D05) ---------------------------------------------------------------------- 41% of all people take people with curly hair less seriously
Dec 02 2009
parent BCS <none anon.com> writes:
Hello Leandro,

 Walter Bright, el  2 de diciembre a las 14:46 me escribiste:
 
 Leandro Lucarella wrote:
 
 Walter Bright, el  2 de diciembre a las 13:29 me escribiste:
 
 I'd like to compare the user base and calculate the bugs/users
 ratio. I guess GCC's would be orders of magnitude smaller.
 

present as bugzilla components: ada, c, c++, fortran, java, objc and objc++), so doing a rough estimative, 5442/7 ~= 800, less than DMD, which implements only D. Seriously Walter, you *can't* possibly compare DMD with GCC, it's almost funny when you do it =P

point is it's absurd, because you can always slice the data to mean whatever you want it to mean. For example, many of the "bugs" in the dmd list are enhancement requests, bugs in the library (not the compiler), bugs in the documentation (not the compiler), etc.

not less. I completely agree with you that bug count (alone) is not a good measure of compiler quality, I just don't agree with the GCC comparison to prove it.


 I hope you can change the license some time, and you start
 encouraging other people involvement more actively, so the number of
 contributors to DMD keep growing.
 

productive in this. But I still want to be the gateway to getting them integrated into the trunk, because otherwise I will lose track of how it works,

in managing projects like this, with a person in charge as a gateway.
 and because sometimes patches are not quite the right place to fix
 the problem, although they are usually close and still very helpful.
 

be accepted, that help a lot when you're willing to contribute. A mailing list (or NG) to submit patches and doing peer review would be really nice,

vote++
Dec 04 2009