[dmd-beta] dmd 1.058 and 2.043 beta

Robert Clipsham robert at octarineparrot.com
Wed Apr 7 12:01:04 PDT 2010

On 07/04/10 19:23, Walter Bright wrote:
> The reason for this release being in a bit of a hurry is because:
> 1. Memory corruption problems are a nasty, ugly, soul-sucking problem
> for anyone using the compiler. They make the language look really bad.
> Rolling out a fix for them is and should be first priority.

I agree, I'm glad to see it's so important for you too :)

> 2. I'm going to be gone to the ACCU next week, and so won't be working
> on the compiler. I don't think this update can wait.

Again, I'd have to agree, other non-critical patches can wait, 
particularly if you have other commitments.

> The dwarf patches you wrote are very important and I wanted to get them
> in, but there isn't time. The existing patches have already destabilized
> the build & test enough :-(

This is unfortunate, I guess they can wait though. Could you maybe 
specify which patches are causing issues so people can look at them and 
help take some of your work load? There's a lot of people who are 
willing to help test/tweak patches out there, they're generally in the 
less vocal minority though.

> Also, I'm spending my time preparing for the ACCU (Andrei and I were
> invited to do a full day tutorial on D, yay!) which is important as we
> want to get D's best foot forward. It's a great opportunity for D.

Getting the word out about D is a good idea, particularly with D2 
stabilizing and becoming feature frozen. I hope there's video's for 
some/all of this so those of us who cannot attend don't miss out, I've 
enjoyed watching previous video's from various D based presentations!

You've mentioned the time constraints are becoming more of an issue for 
you, which is holding back patches... Maybe it's time to take the next 
step in the open source development model and give others commit access 
to the dmd repository? You could of course review all commits, and set 
strict regulations on what gets in, eg bigger changes/patches must be 
run by you first, the test suite must pass etc, whatever you deem fit to 
make sure nothing too radical gets in. An ideal candidate for commit 
access would of course be Don who has been providing excellent patches 
for a long time now, and I'm sure he'd be happy to go along with 
whatever regulations you put in place... Just something for you to 
consider, particularly if you're going to have less time to work on the 
compiler here and there :)

More information about the dmd-beta mailing list