Discussion:
StreamsEqual issue(s)
Gert Driesen
2008-08-13 14:04:23 UTC
Permalink
Hey Charlie,

I was having a quick look at the impact of upgrading the version of NUnit in
Mono from 2.2 to 2.4.8, and noticed some test regressions.

I had a closer look at one of these regressions, and the reason it failed is
because EqualConstraint.StreamsEqual expects both streams to be readable and
seekable. If not, this results in an exception.

I don't think an assert should result in an exception (other than
AssertionException.cs).

I also noticed NUnit is changing the position in the stream (to the start of
the stream), and doesn't change it back afterwards. Should an Assert by
itself be allowed to change the state of a stream?

I'm also not sure if NUnit should actually read these streams. What will you
do if the stream is readable and not seekable? You'd change the position in
the stream (by positioning at the beginning and by reading it), and you
can't change it back to the origin position.

Apart from this, I wondered why NUnit is not always checking for reference
equality first? Why bothering checking the content of two streams, it they
are actually the same?

Gert


-------------------------------------------------------------------------
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/
Charlie Poole
2008-08-13 16:59:08 UTC
Permalink
Hi Gert,

Hey! I'm glad someone is looking at that. :-) Are you looking
to test Mono itself with 2.4.8 or just ship with it?

I'm not real familiar with that constraint, but your points
make sense. I'll look it over.

More inline...
Post by Gert Driesen
I was having a quick look at the impact of upgrading the
version of NUnit in Mono from 2.2 to 2.4.8, and noticed some
test regressions.
I had a closer look at one of these regressions, and the
reason it failed is because EqualConstraint.StreamsEqual
expects both streams to be readable and seekable. If not,
this results in an exception.
So your test was previously comparing two streams with
Assert.AreEqual? Since NUnit had no prior code for streams,
you would be getting Stream.Equals (i.e. Object.Equals).
The easiest fix would be to use Assert.SameAs if that's
what you want.
Post by Gert Driesen
I don't think an assert should result in an exception (other
than AssertionException.cs).
Agreed... plus any ArgumentInvalid, etc. that are the fault
of the user.
Post by Gert Driesen
I also noticed NUnit is changing the position in the stream
(to the start of the stream), and doesn't change it back
afterwards. Should an Assert by itself be allowed to change
the state of a stream?
In some cases, NUnit actually creates the stream by opening
a file. But in others, it may be passed in as an argument.
Theoretically, we should not change it or at least document
that it may be changed. I'll look at it.
Post by Gert Driesen
I'm also not sure if NUnit should actually read these
streams. What will you do if the stream is readable and not
seekable? You'd change the position in the stream (by
positioning at the beginning and by reading it), and you
can't change it back to the origin position.
I can't think of any good use case for wanting to assert
on the equality of two non-seekable streams. Can you? Maybe
I should just throw an InvalidArgumentException.
Post by Gert Driesen
Apart from this, I wondered why NUnit is not always checking
for reference equality first? Why bothering checking the
content of two streams, it they are actually the same?
But why is the user bothering to use the Assert in that case?
He should be using AreSame rather than AreEqual. OTOH, I
can imagine odd cases where it would not be possible to
know in advance, so it's worth a check.

I wasn't planning to do any more development in the 2.4
code line, but I guess I could do a fix for mono if there
turn out to be any issues that require it. Alternatively,
you may want to look at 2.5, which will get active maintenance
after it is released.

Charlie
Post by Gert Driesen
Gert
--------------------------------------------------------------
-----------
This SF.Net email is sponsored by the Moblin Your Move
Developer's challenge Build the coolest Linux based
applications with Moblin SDK & win great prizes Grand prize
is a trip for two to an Open Source event anywhere in the
world http://moblin-contest.org/redirect.php?banner_id=100&url=/
_______________________________________________
nunit-developer mailing list
https://lists.sourceforge.net/lists/listinfo/nunit-developer
-------------------------------------------------------------------------
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/
Gert Driesen
2008-08-13 18:59:42 UTC
Permalink
-----Original Message-----
[mailto:nunit-developer-***@lists.sourceforge.net] On Behalf Of Charlie
Poole
Sent: woensdag 13 augustus 2008 18:59
Subject: Re: [nunit-developer] StreamsEqual issue(s)
Hi Gert,
Hey! I'm glad someone is looking at that. :-) Are you looking
to test Mono itself with 2.4.8 or just ship with it?
My intention is to test Mono with it, but since it's also used for
Grasshopper (JVM) someone on that team will also need to look into the
upgrade.

So I'm not sure if my patch for upgrading to 2.4.8 will even be accepted. As
I've said, there are also other issues that surfaced after the upgrade that
would need to be fixed first.
I'm not real familiar with that constraint, but your points
make sense. I'll look it over.
More inline...
Post by Gert Driesen
I was having a quick look at the impact of upgrading the
version of NUnit in Mono from 2.2 to 2.4.8, and noticed some
test regressions.
I had a closer look at one of these regressions, and the
reason it failed is because EqualConstraint.StreamsEqual
expects both streams to be readable and seekable. If not,
this results in an exception.
So your test was previously comparing two streams with
Assert.AreEqual? Since NUnit had no prior code for streams,
you would be getting Stream.Equals (i.e. Object.Equals).
The easiest fix would be to use Assert.SameAs if that's
what you want.
It wasn't one of my tests, but the workaround would indeed be to use
Assert.AreSame (or similar).
Post by Gert Driesen
I don't think an assert should result in an exception (other
than AssertionException.cs).
Agreed... plus any ArgumentInvalid, etc. that are the fault
of the user.
Yes, of course.
Post by Gert Driesen
I also noticed NUnit is changing the position in the stream
(to the start of the stream), and doesn't change it back
afterwards. Should an Assert by itself be allowed to change
the state of a stream?
In some cases, NUnit actually creates the stream by opening
a file. But in others, it may be passed in as an argument.
Theoretically, we should not change it or at least document
that it may be changed. I'll look at it.
It the stream is both readable and seekable, then I think NUnit should store
the initial position, and reposition back at that position after comparing
the content of the stream.
Post by Gert Driesen
I'm also not sure if NUnit should actually read these
streams. What will you do if the stream is readable and not
seekable? You'd change the position in the stream (by
positioning at the beginning and by reading it), and you
can't change it back to the origin position.
I can't think of any good use case for wanting to assert
on the equality of two non-seekable streams. Can you? Maybe
I should just throw an InvalidArgumentException.
No, but if you aim for backward compatibility then this is not the best
approach.

But well, the change from Stream.Equals to actually comparing the content of
the streams isn't either.

I guess this does not apply to only Streams. I leave it up to your good
judgement to decide which approach to take.
Post by Gert Driesen
Apart from this, I wondered why NUnit is not always checking
for reference equality first? Why bothering checking the
content of two streams, it they are actually the same?
But why is the user bothering to use the Assert in that case?
He should be using AreSame rather than AreEqual. OTOH, I
can imagine odd cases where it would not be possible to
know in advance, so it's worth a check.
He should indeed be using AreSame, but this specific test even dated from
before Assert.AreSame existed (the fixture derived from Assertion, and used
AssertEquals to compare the streams). There are actually quite a few tests
in Mono that use this (long-time) deprecated construct.
I wasn't planning to do any more development in the 2.4
code line, but I guess I could do a fix for mono if there
turn out to be any issues that require it. Alternatively,
you may want to look at 2.5, which will get active maintenance
after it is released.
I don't think you should bother fixing this for 2.4. I'll even need to check
with Miguel if he wants to consider upgrading NUnit.

Perhaps he prefers to keep things as is.

Gert


-------------------------------------------------------------------------
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/
Charlie Poole
2008-08-13 19:21:29 UTC
Permalink
Hi Gert,
Post by Gert Driesen
Post by Gert Driesen
I also noticed NUnit is changing the position in the
stream (to the
Post by Gert Driesen
start of the stream), and doesn't change it back
afterwards. Should
Post by Gert Driesen
an Assert by itself be allowed to change the state of a stream?
In some cases, NUnit actually creates the stream by opening a file.
But in others, it may be passed in as an argument.
Theoretically, we should not change it or at least document that it
may be changed. I'll look at it.
It the stream is both readable and seekable, then I think
NUnit should store the initial position, and reposition back
at that position after comparing the content of the stream.
That makes sense - I'll put it into the head anyway.
Post by Gert Driesen
Post by Gert Driesen
I'm also not sure if NUnit should actually read these
streams. What
Post by Gert Driesen
will you do if the stream is readable and not seekable?
You'd change
Post by Gert Driesen
the position in the stream (by positioning at the
beginning and by
Post by Gert Driesen
reading it), and you can't change it back to the origin position.
I can't think of any good use case for wanting to assert on the
equality of two non-seekable streams. Can you? Maybe I should just
throw an InvalidArgumentException.
No, but if you aim for backward compatibility then this is
not the best approach.
My logic so far has been that it's OK to change behavior if it
only impacts something that should not have been acceptable in
the first place. Since NUnit is a /test/ framework, and isn't
(normally) shipping as part of the software being tested, pointing
out a problem is a good thing.
Post by Gert Driesen
But well, the change from Stream.Equals to actually comparing
the content of the streams isn't either.
I guess this does not apply to only Streams. I leave it up to
your good judgement to decide which approach to take.
In fact, it applies anyplace where we have added new behavior
to AreEqual(object, object). There's a tradeoff but I think it's
largely in favor of making such changes when they are useful
because,

1) They don't generally break anything but a test for reference
equality.

2) There's a preferred way to do that.
Post by Gert Driesen
Post by Gert Driesen
Apart from this, I wondered why NUnit is not always checking for
reference equality first? Why bothering checking the
content of two
Post by Gert Driesen
streams, it they are actually the same?
But why is the user bothering to use the Assert in that case?
He should be using AreSame rather than AreEqual. OTOH, I
can imagine
odd cases where it would not be possible to know in
advance, so it's
worth a check.
He should indeed be using AreSame, but this specific test
even dated from before Assert.AreSame existed (the fixture
derived from Assertion, and used AssertEquals to compare the
streams). There are actually quite a few tests in Mono that
use this (long-time) deprecated construct.
So maybe the first patch is to upgrade the tests to NUnit 2.2. :-)
Post by Gert Driesen
I wasn't planning to do any more development in the 2.4
code line, but
I guess I could do a fix for mono if there turn out to be
any issues
that require it. Alternatively, you may want to look at 2.5, which
will get active maintenance after it is released.
I don't think you should bother fixing this for 2.4. I'll
even need to check with Miguel if he wants to consider
upgrading NUnit.
I suggest running your same tests with the 2.5 alpha to see if
there are any further problems. I suspect there will not be, but
I can easily fix any incompatibilities there.

In fact, fixing anything that made it easier to use NUnit in
Mono would be a big priority.

BTW, do you think I should have some sort of install for linux?
Up to now it has been totally left to the packagers.

Charlie
Post by Gert Driesen
Perhaps he prefers to keep things as is.
Gert
-------------------------------------------------------------------------
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/
Gert Driesen
2008-08-13 20:11:25 UTC
Permalink
-----Original Message-----
[mailto:nunit-developer-***@lists.sourceforge.net] On Behalf Of Charlie
Poole
Sent: woensdag 13 augustus 2008 21:21
Subject: Re: [nunit-developer] StreamsEqual issue(s)
Hey Charlie,
Post by Gert Driesen
Post by Gert Driesen
I also noticed NUnit is changing the position in the
stream (to the
Post by Gert Driesen
start of the stream), and doesn't change it back
afterwards. Should
Post by Gert Driesen
an Assert by itself be allowed to change the state of a stream?
In some cases, NUnit actually creates the stream by opening a file.
But in others, it may be passed in as an argument.
Theoretically, we should not change it or at least document that it
may be changed. I'll look at it.
It the stream is both readable and seekable, then I think
NUnit should store the initial position, and reposition back
at that position after comparing the content of the stream.
That makes sense - I'll put it into the head anyway.
Great.
Post by Gert Driesen
Post by Gert Driesen
I'm also not sure if NUnit should actually read these
streams. What
Post by Gert Driesen
will you do if the stream is readable and not seekable?
You'd change
Post by Gert Driesen
the position in the stream (by positioning at the
beginning and by
Post by Gert Driesen
reading it), and you can't change it back to the origin position.
I can't think of any good use case for wanting to assert on the
equality of two non-seekable streams. Can you? Maybe I should just
throw an InvalidArgumentException.
No, but if you aim for backward compatibility then this is
not the best approach.
My logic so far has been that it's OK to change behavior if it
only impacts something that should not have been acceptable in
the first place. Since NUnit is a /test/ framework, and isn't
(normally) shipping as part of the software being tested, pointing
out a problem is a good thing.
Yes, I agree.
Post by Gert Driesen
But well, the change from Stream.Equals to actually comparing
the content of the streams isn't either.
I guess this does not apply to only Streams. I leave it up to
your good judgement to decide which approach to take.
In fact, it applies anyplace where we have added new behavior
to AreEqual(object, object). There's a tradeoff but I think it's
largely in favor of making such changes when they are useful
because,
1) They don't generally break anything but a test for reference
equality.
2) There's a preferred way to do that.
I understand. The Stream case is probably somewhat unique, and the test
itself was kinda broken too.

I think it's sufficient to document this (and add a unit test for the
behavior with non-readable and/or non-seekable streams).
Post by Gert Driesen
Post by Gert Driesen
Apart from this, I wondered why NUnit is not always checking for
reference equality first? Why bothering checking the
content of two
Post by Gert Driesen
streams, it they are actually the same?
But why is the user bothering to use the Assert in that case?
He should be using AreSame rather than AreEqual. OTOH, I
can imagine
odd cases where it would not be possible to know in
advance, so it's
worth a check.
He should indeed be using AreSame, but this specific test
even dated from before Assert.AreSame existed (the fixture
derived from Assertion, and used AssertEquals to compare the
streams). There are actually quite a few tests in Mono that
use this (long-time) deprecated construct.
So maybe the first patch is to upgrade the tests to NUnit 2.2. :-)
If I ever get bored for a few weeks, I'll take care of that :p
Post by Gert Driesen
I wasn't planning to do any more development in the 2.4
code line, but
I guess I could do a fix for mono if there turn out to be
any issues
that require it. Alternatively, you may want to look at 2.5, which
will get active maintenance after it is released.
I don't think you should bother fixing this for 2.4. I'll
even need to check with Miguel if he wants to consider
upgrading NUnit.
I suggest running your same tests with the 2.5 alpha to see if
there are any further problems. I suspect there will not be, but
I can easily fix any incompatibilities there.
I could consider this, but I doubt a patch to upgrade to an alpha version of
NUnit will be accepted.

Perhaps the other issues I found are also just broken tests. If I recall
correctly one was about comparing floats.
Post by Gert Driesen
In fact, fixing anything that made it easier to use NUnit in
Mono would be a big priority.
BTW, do you think I should have some sort of install for linux?
Up to now it has been totally left to the packagers.
Yeah, probably. For NAnt, the Novell team creates RPMs. But I think each
open-source project should take care of this themselves to avoid becoming
dependent on the goodwill and schedule of Novell.

For NAnt, the problem was that I did not know enough about linux packaging,
and did not have enough time (or interest) to look into it.

Gert


-------------------------------------------------------------------------
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/
Charlie Poole
2008-08-14 00:03:05 UTC
Permalink
I looked at the code and realized that the entire comparison
is dependent on the stream being seekable, since it gets the
length of the streams before starting and Length is undefined
when CanSeek returns false!

Since I didn't feel like putting much work into it right now,
I put in a throw (argumentexception) if either stream is not
readable or seekable. Comparing non-seekable streams or a
seekable expected to a non-seekable actual might be useful,
so if someone with an interest in this would like to give
it a try, let me know.

BTW, if you write any constraints, it's essential that they
throw rather than returning false when something unexpected
happens. Why? Because somebody can always put "Not." in front
of your constraint, turning the failure into a success.
That's usually not what we want.

Charlie
-----Original Message-----
Behalf Of Charlie Poole
Sent: Wednesday, August 13, 2008 12:21 PM
Subject: Re: [nunit-developer] StreamsEqual issue(s)
Hi Gert,
Post by Gert Driesen
Post by Charlie Poole
Post by Gert Driesen
I also noticed NUnit is changing the position in the
stream (to the
Post by Charlie Poole
Post by Gert Driesen
start of the stream), and doesn't change it back
afterwards. Should
Post by Charlie Poole
Post by Gert Driesen
an Assert by itself be allowed to change the state of a stream?
In some cases, NUnit actually creates the stream by
opening a file.
Post by Gert Driesen
Post by Charlie Poole
But in others, it may be passed in as an argument.
Theoretically, we should not change it or at least
document that it
Post by Gert Driesen
Post by Charlie Poole
may be changed. I'll look at it.
It the stream is both readable and seekable, then I think
NUnit should
Post by Gert Driesen
store the initial position, and reposition back at that
position after
Post by Gert Driesen
comparing the content of the stream.
That makes sense - I'll put it into the head anyway.
Post by Gert Driesen
Post by Charlie Poole
Post by Gert Driesen
I'm also not sure if NUnit should actually read these
streams. What
Post by Charlie Poole
Post by Gert Driesen
will you do if the stream is readable and not seekable?
You'd change
Post by Charlie Poole
Post by Gert Driesen
the position in the stream (by positioning at the
beginning and by
Post by Charlie Poole
Post by Gert Driesen
reading it), and you can't change it back to the origin
position.
Post by Gert Driesen
Post by Charlie Poole
I can't think of any good use case for wanting to assert on the
equality of two non-seekable streams. Can you? Maybe I
should just
Post by Gert Driesen
Post by Charlie Poole
throw an InvalidArgumentException.
No, but if you aim for backward compatibility then this is not the
best approach.
My logic so far has been that it's OK to change behavior if
it only impacts something that should not have been
acceptable in the first place. Since NUnit is a /test/
framework, and isn't
(normally) shipping as part of the software being tested,
pointing out a problem is a good thing.
Post by Gert Driesen
But well, the change from Stream.Equals to actually comparing the
content of the streams isn't either.
I guess this does not apply to only Streams. I leave it up to your
good judgement to decide which approach to take.
In fact, it applies anyplace where we have added new behavior
to AreEqual(object, object). There's a tradeoff but I think
it's largely in favor of making such changes when they are
useful because,
1) They don't generally break anything but a test for
reference equality.
2) There's a preferred way to do that.
Post by Gert Driesen
Post by Charlie Poole
Post by Gert Driesen
Apart from this, I wondered why NUnit is not always
checking for
Post by Gert Driesen
Post by Charlie Poole
Post by Gert Driesen
reference equality first? Why bothering checking the
content of two
Post by Charlie Poole
Post by Gert Driesen
streams, it they are actually the same?
But why is the user bothering to use the Assert in that case?
He should be using AreSame rather than AreEqual. OTOH, I
can imagine
Post by Charlie Poole
odd cases where it would not be possible to know in
advance, so it's
Post by Charlie Poole
worth a check.
He should indeed be using AreSame, but this specific test
even dated
Post by Gert Driesen
from before Assert.AreSame existed (the fixture derived from
Assertion, and used AssertEquals to compare the streams). There are
actually quite a few tests in Mono that use this (long-time)
deprecated construct.
So maybe the first patch is to upgrade the tests to NUnit 2.2. :-)
Post by Gert Driesen
Post by Charlie Poole
I wasn't planning to do any more development in the 2.4
code line, but
Post by Charlie Poole
I guess I could do a fix for mono if there turn out to be
any issues
Post by Charlie Poole
that require it. Alternatively, you may want to look at
2.5, which
Post by Gert Driesen
Post by Charlie Poole
will get active maintenance after it is released.
I don't think you should bother fixing this for 2.4. I'll
even need to
Post by Gert Driesen
check with Miguel if he wants to consider upgrading NUnit.
I suggest running your same tests with the 2.5 alpha to see
if there are any further problems. I suspect there will not
be, but I can easily fix any incompatibilities there.
In fact, fixing anything that made it easier to use NUnit in
Mono would be a big priority.
BTW, do you think I should have some sort of install for linux?
Up to now it has been totally left to the packagers.
Charlie
Post by Gert Driesen
Perhaps he prefers to keep things as is.
Gert
--------------------------------------------------------------
-----------
This SF.Net email is sponsored by the Moblin Your Move
Developer's challenge Build the coolest Linux based
applications with Moblin SDK & win great prizes Grand prize
is a trip for two to an Open Source event anywhere in the
world http://moblin-contest.org/redirect.php?banner_id=100&url=/
_______________________________________________
nunit-developer mailing list
https://lists.sourceforge.net/lists/listinfo/nunit-developer
-------------------------------------------------------------------------
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/
Charlie Poole
2008-08-14 00:17:40 UTC
Permalink
Hi Gert,
Post by Gert Driesen
I think it's sufficient to document this (and add a unit test
for the behavior with non-readable and/or non-seekable streams).
Will do...
Post by Gert Driesen
Post by Charlie Poole
I suggest running your same tests with the 2.5 alpha to see
if there
Post by Charlie Poole
are any further problems. I suspect there will not be, but I can
easily fix any incompatibilities there.
I could consider this, but I doubt a patch to upgrade to an
alpha version of NUnit will be accepted.
No... I just meant that you could find out if there are added
issues with 2.5 or if the amount of work is likely to be the
same. I wouldn't suggest you patch until at least a beta. :-)

And if I knew about issues before release, they might get
resolved sooner.
Post by Gert Driesen
Perhaps the other issues I found are also just broken tests.
If I recall correctly one was about comparing floats.
Pass them to me as you find them and I'll be glad to look them
over. Better yet, file bugs on them so we can keep track.
Post by Gert Driesen
Post by Charlie Poole
In fact, fixing anything that made it easier to use NUnit in Mono
would be a big priority.
BTW, do you think I should have some sort of install for linux?
Up to now it has been totally left to the packagers.
Yeah, probably. For NAnt, the Novell team creates RPMs. But I
think each open-source project should take care of this
themselves to avoid becoming dependent on the goodwill and
schedule of Novell.
For NAnt, the problem was that I did not know enough about
linux packaging, and did not have enough time (or interest)
to look into it.
That's about were I am, except I'm somewhat interested, so
I may try to make the time to learn about it at some point.

Of course, if someone reading this has the knowledge, time
and interest, I hope they'll make themselves known. :-)

Charlie
Post by Gert Driesen
Gert
-------------------------------------------------------------------------
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/
Gert Driesen
2008-08-14 03:02:37 UTC
Permalink
Hey Charlie,

I did make a few changes to the NAnt "install" target and the generated nant
script to have it align better with linux packaging practices:

http://nant.cvs.sourceforge.net/nant/nant/NAnt.build?r1=1.246&r2=1.250
http://nant.cvs.sourceforge.net/nant/nant/Makefile?r1=1.19&r2=1.20

For info on the way DESTDIR is used for creating staged installs, see:
http://www.gnu.org/prep/standards/html_node/DESTDIR.html

Gert

-----Original Message-----
From: Charlie Poole [mailto:***@pooleconsulting.com]
Sent: donderdag 14 augustus 2008 2:18
To: 'Gert Driesen'; nunit-***@lists.sourceforge.net
Subject: RE: [nunit-developer] StreamsEqual issue(s)

Hi Gert,
Post by Gert Driesen
I think it's sufficient to document this (and add a unit test
for the behavior with non-readable and/or non-seekable streams).
Will do...
Post by Gert Driesen
Post by Charlie Poole
I suggest running your same tests with the 2.5 alpha to see
if there
Post by Charlie Poole
are any further problems. I suspect there will not be, but I can
easily fix any incompatibilities there.
I could consider this, but I doubt a patch to upgrade to an
alpha version of NUnit will be accepted.
No... I just meant that you could find out if there are added
issues with 2.5 or if the amount of work is likely to be the
same. I wouldn't suggest you patch until at least a beta. :-)

And if I knew about issues before release, they might get
resolved sooner.
Post by Gert Driesen
Perhaps the other issues I found are also just broken tests.
If I recall correctly one was about comparing floats.
Pass them to me as you find them and I'll be glad to look them
over. Better yet, file bugs on them so we can keep track.
Post by Gert Driesen
Post by Charlie Poole
In fact, fixing anything that made it easier to use NUnit in Mono
would be a big priority.
BTW, do you think I should have some sort of install for linux?
Up to now it has been totally left to the packagers.
Yeah, probably. For NAnt, the Novell team creates RPMs. But I
think each open-source project should take care of this
themselves to avoid becoming dependent on the goodwill and
schedule of Novell.
For NAnt, the problem was that I did not know enough about
linux packaging, and did not have enough time (or interest)
to look into it.
That's about were I am, except I'm somewhat interested, so
I may try to make the time to learn about it at some point.

Of course, if someone reading this has the knowledge, time
and interest, I hope they'll make themselves known. :-)

Charlie
Post by Gert Driesen
Gert
-------------------------------------------------------------------------
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/
Charlie Poole
2008-08-14 04:25:19 UTC
Permalink
Thanks, I'll look it over.
-----Original Message-----
Sent: Wednesday, August 13, 2008 8:03 PM
Subject: RE: [nunit-developer] StreamsEqual issue(s)
Hey Charlie,
I did make a few changes to the NAnt "install" target and the
generated nant script to have it align better with linux
http://nant.cvs.sourceforge.net/nant/nant/NAnt.build?r1=1.246&r2=1.250
http://nant.cvs.sourceforge.net/nant/nant/Makefile?r1=1.19&r2=1.20
http://www.gnu.org/prep/standards/html_node/DESTDIR.html
Gert
-----Original Message-----
Sent: donderdag 14 augustus 2008 2:18
Subject: RE: [nunit-developer] StreamsEqual issue(s)
Hi Gert,
Post by Gert Driesen
I think it's sufficient to document this (and add a unit
test for the
Post by Gert Driesen
behavior with non-readable and/or non-seekable streams).
Will do...
Post by Gert Driesen
Post by Charlie Poole
I suggest running your same tests with the 2.5 alpha to see
if there
Post by Charlie Poole
are any further problems. I suspect there will not be, but I can
easily fix any incompatibilities there.
I could consider this, but I doubt a patch to upgrade to an alpha
version of NUnit will be accepted.
No... I just meant that you could find out if there are added
issues with 2.5 or if the amount of work is likely to be the
same. I wouldn't suggest you patch until at least a beta. :-)
And if I knew about issues before release, they might get
resolved sooner.
Post by Gert Driesen
Perhaps the other issues I found are also just broken tests.
If I recall correctly one was about comparing floats.
Pass them to me as you find them and I'll be glad to look
them over. Better yet, file bugs on them so we can keep track.
Post by Gert Driesen
Post by Charlie Poole
Post by Charlie Poole
In fact, fixing anything that made it easier to use
NUnit in Mono
Post by Gert Driesen
Post by Charlie Poole
Post by Charlie Poole
would be a big priority.
BTW, do you think I should have some sort of install for linux?
Up to now it has been totally left to the packagers.
Yeah, probably. For NAnt, the Novell team creates RPMs. But I think
each open-source project should take care of this
themselves to avoid
Post by Gert Driesen
becoming dependent on the goodwill and schedule of Novell.
For NAnt, the problem was that I did not know enough about linux
packaging, and did not have enough time (or interest) to
look into it.
That's about were I am, except I'm somewhat interested, so I
may try to make the time to learn about it at some point.
Of course, if someone reading this has the knowledge, time
and interest, I hope they'll make themselves known. :-)
Charlie
Post by Gert Driesen
Gert
-------------------------------------------------------------------------
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/

Loading...