yigal chripun wrote:
> Lars T. Kyllingstad Wrote:
> 
>> yigal chripun wrote:
>>> Either you need to have a plan or you need to have a community
>>> driven process (Java JSRs, Python PEPs).
>> There is a similar option for D, although it doesn't have a fancy abbreviation: You can put enhancement requests in Bugzilla and get
>>  people to vote for them.
>> 
>> -Lars
> 
> you must be kidding right? maybe the situation is improving lately
> but not that long ago I remember posts by downs where he pointed out
> an old bug in DMD with a patch to fix that bug already in Bugzilla
> and that fix was in bugzila several *years* without anyone caring.

If that is the bug I am thinking of, the patch papered over one instance of the problem and didn't fix it at all. The patch even noted that it was incomplete. The real fix required much more extensive work, and there were higher priority problems.

My general experience with posted compiler patches is about half of them are good, the other half are incorrect and require more development.

For a more recent example, 3122 contained a patch that was marked as complete and tested, but it had two serious bugs (did not check that a filename was supplied, and did not check for file write errors) and an unnecessary hardcoded OS dependency (on path lengths). These aren't hard to fix, and I merged in the patch with fixes, I'm just trying to say that things are not as simple as just apply patches.

That said, I still appreciate and encourage posting patches to bugzilla, as even if incomplete they still cut down the work for me that is necessary to fix the problem, and hence they are valuable.

Walter Bright wrote:
> For a more recent example, 3122 contained a patch that was marked as complete and tested, but it had two serious bugs (did not check that a filename was supplied, and did not check for file write errors) and an unnecessary hardcoded OS dependency (on path lengths). These aren't hard to fix, and I merged in the patch with fixes, I'm just trying to say that things are not as simple as just apply patches.

Guilty as charged. Sorry about that. I didn't consider the case where someone would not provide a file name and didn't realize that write errors were an issue in this case. I guess I'm used to I/O code throwing exceptions when something goes wrong ;)

The MAX_PATH+2 was probably plain stupid of me. I wanted to hardcode it to '256' but then thought 'oh, MAX_PATH+2 would be better!', both of which were braindead considering that I've just checked that filename ops in DMD use dynamic allocation for this purpose. Please let me know the next time I commit a crime like this and I'll fix it gladly! I promise my next patch will be better :P

Thanks for folding it in! *g*


-- 
Tomasz Stachowiak
http://h3.team0xf.com/
h3/h3r3tic on #D freenode

Tom S wrote:
> Guilty as charged. Sorry about that. I didn't consider the case where someone would not provide a file name and didn't realize that write errors were an issue in this case. I guess I'm used to I/O code throwing exceptions when something goes wrong ;)
> 
> The MAX_PATH+2 was probably plain stupid of me. I wanted to hardcode it to '256' but then thought 'oh, MAX_PATH+2 would be better!', both of which were braindead considering that I've just checked that filename ops in DMD use dynamic allocation for this purpose. Please let me know the next time I commit a crime like this and I'll fix it gladly! I promise my next patch will be better :P

I wouldn't worry about it. We all make mistakes programming - that's what code reviews are for.


> Thanks for folding it in! *g*

Walter Bright Wrote:

> My general experience with posted compiler patches is about half of them are good, the other half are incorrect and require more

for the bad half, do you comment in the bug reports about why you think the patches are bad?

Jason House wrote:
> Walter Bright Wrote:
> 
>> My general experience with posted compiler patches is about half of them are good, the other half are incorrect and require more
> 
> for the bad half, do you comment in the bug reports about why you think the patches are bad? 

Sometimes, but not usually. I doubted anyone cared as long as they got fixed one way or another.

On Thu, 2 Jul 2009, Walter Bright wrote:

> Jason House wrote:
> > Walter Bright Wrote:
> > 
> > > My general experience with posted compiler patches is about half of them are good, the other half are incorrect and require more
> > 
> > for the bad half, do you comment in the bug reports about why you think the patches are bad?
> 
> Sometimes, but not usually. I doubted anyone cared as long as they got fixed one way or another.

Without education, the chances of the patches getting better in the future is pretty close to zero.  With a little education, the chances are pretty good.  IE, it's in your own best interest to help out the people that are willing to help you.

Later,
Brad

On Thu, 02 Jul 2009 13:55:56 -0700, Walter Bright wrote:

> Jason House wrote:
>> Walter Bright Wrote:
>> 
>>> My general experience with posted compiler patches is about half of them are good, the other half are incorrect and require more
>> 
>> for the bad half, do you comment in the bug reports about why you think the patches are bad?
> 
> Sometimes, but not usually. I doubted anyone cared as long as they got fixed one way or another.

Bzzzt ... wrong answer.

-- 
Derek Parnell
Melbourne, Australia
skype: derek.j.parnell

Walter Bright Wrote:

> Jason House wrote:
> > Walter Bright Wrote:
> > 
> >> My general experience with posted compiler patches is about half of them are good, the other half are incorrect and require more
> > 
> > for the bad half, do you comment in the bug reports about why you think the patches are bad?
If you closed every bug promptly, we probably wouldn't care. Bugs that are not closed can be for many reasons... You could be too busy, the patch requires too much time to fix, you don't understand the bug, you disagree with the bug, you forgot about the bug, you never read the bug report, etc...

Silence is frequently mistaken for apathy. Responses to bug reports generate a lot of good will and encourages further help from the community. Bugs open for years with no comments have the opposite effect...
> 
> Sometimes, but not usually. I doubted anyone cared as long as they got fixed one way or another.

Jason House wrote:
> Silence is frequently mistaken for apathy. Responses to bug reports
> generate a lot of good will and encourages further help from the
> community. Bugs open for years with no comments have the opposite
> effect...

Look at the changelog - there's regular and significant progress every month in fixing reported bugs.

If someone wants to help advance D with something that does not have me as a gating factor, a *big* help would be to get the gdb patches folded into the main branch of gdb:

http://sourceware.org/bugzilla/show_bug.cgi?id=10142

Walter Bright Wrote:

> Jason House wrote:
> > Silence is frequently mistaken for apathy. Responses to bug reports generate a lot of good will and encourages further help from the community. Bugs open for years with no comments have the opposite effect...
> 
> Look at the changelog - there's regular and significant progress every month in fixing reported bugs.
> 
> If someone wants to help advance D with something that does not have me as a gating factor, a *big* help would be to get the gdb patches folded into the main branch of gdb:
> 
> http://sourceware.org/bugzilla/show_bug.cgi?id=10142

there's already someone working on getting that patch into gdb. I've been trying lately to play with the dmd -gc output so that gdb recognizes it properly. I'm not very far, and my queries in #gdb have gone unanswered :(