[Mono-list] StringBuilder continued

[Nick Drochak]

| > Two related issues about building and tests that I noticed: 1) the build
| > spits out a bunch of warnings about unused fields, etc.  When do we
| > worry about and fix those?
|
| Most of the warnings are in a piece of code that is currently in flux
| (for the System.Reflection.Emit code).  Lets give Paolo a chance to
| finish this and then we can remove the warnings.

Yes I realized that after I took a look at the sources. However, this will
probably not be the only time this situation will come up. Would it be a
good idea to include a switch to the compiler for "in flux" sources to
suppress those warnings?  Namely the CS0649 and CS0169 warnings?  I don't
know if this is possible to do in the Nant build files selectively for
particular source files.

If so, then this would keep others from reporting to the list that the build
was broken because they would not see the warnings.  When the class is
really done, the class author could remove the suppression.
|
| > 2) A lot, maybe most, of the unit tests
| > fail.  In fact, if I try to run all the tests for corlib_test.dll, my
| > NUnitGUI just ups and disappears after a couple of seconds!  No GPF or
| > anything.  This is most troubling.
|
| Yes, we have noticed this.  We need to begin somewhere to fix those
| problems though.
|

A good beginning might be to include at the end of the build process a call
to the console version of NUnit for all the test dll's.  I do this manually
now anyway for corlib.  I don't have enough (read "any") experience with
Nant to make that change myself, however.

| > The whole point and benefit of the unit tests is lost if we just ignore
| > the fact that they are not working.  Or, am I the only one bothered by
| > this?  Maybe my machine is the only one acting this way?
|
| I would love to fix the unit tests, because they are radically
| important.  Indeed, for the compiler we do not commit code unless all
| the tests pass.
|
| We should have a system like this for the class libraries.

Agreed.  I would suggest we add something to the web site that explains
that.  In the meantime, perhaps we should notify the class maintainer of any
class that currently does not pass unit tests, and see if they can provide a
fix.  If they can not, for whatever reason, or do not respond within a
couple of days then we request that someone else take on the task. Also, as
Joel S. suggests, we should not be adding any new classes or functionality
until all the tests pass. These are, by definition, "known bugs."

If we cannot commit new classes because the tests aren't passing, maybe this
will be an incentive to get those darn things working.  Although this is a
bit extreme, I believe it's important enough to warrant it.

| > Anyway, attached is the diff of my changes for today (in diff -u format
| > for easy reading :).
|
| Did you get a chance to put those on CVS?
|

I did indeed commit those.  Over the weekend I added parameter checking to
the StringBuilder constructors and throw appropriate exceptions now, just
like the MS class.  However, I didn't get to check that in yet.  I will do
so when I get home tonight. I was distracted when my 3 year old put a bunch
of melted chocolate all over my keyboard :).

Regards,
Nick D.