George -
I completely deleted the source on my machine and retrieved the current
version from svn. The same two tests fail in the same way, on an
invalid cast.
Search\TestSort\TestNormalizedScores
Search\TestSort\TestRemoteSort
Looking at diff's in svn on the TestSort.cs file, between revision
564939and 569217, the fix for LUCENENET-86, the decimal seperator was
changed to that of a culture sensitive one (line 125). This would
explain why the patch I added to LUCENENET-94 corrects the issue as that
patch changes the casting of string to floats to using Convet.ToSingle,
and when that is inspected with Lutz Roeder's .NET Reflector the Convert
method internally uses float.Parse(value, cultureInfo). If the data in
the index is made culturally sensitive, then the comparison on it later
should be as well. I am a little stumped as to why it throws an error
when it is cast, as my culture sets the NumberDecimalSeperator as a '.'
So it appears as if it is related to cultural sensitivity as DIGY
suggested... Are you able to duplicate this at all with the latest
version of TestSort.cs?
Michael
George Aroush wrote:
Hi Michael,
For additional verification; can you get a fresh copy off SVN and test
instead of just applying the patch to your local code?
Thanks.
-- George
-----Original Message-----
From: Michael Garski [mailto:[EMAIL PROTECTED]
Sent: Wednesday, September 19, 2007 2:42 PM
To: [email protected]
Subject: Re: Unit Tests
DIGY,
Thanks! I applied that FieldDocSortedHitQueue.patch and all
tests now successfully pass!
It does appear that there is some sort of localization thing,
as when I modified the casts to use the corresponding
System.Convert method and the tests passed.
I also commented out the block of code you added regarding
the reversal of the sort:
if (docA.fields[i] == null)
{
if (docB.fields[i] == null) continue;
return fields[i].GetReverse();
}
if (docB.fields[i] == null)
{
if (docA.fields[i] == null) continue;
return !fields[i].GetReverse();
}
And the tests ran just fine - what was the intent on adding
that? I don't quite understand...
Michael
DIGY wrote:
Hi Michael,
Can you try the FieldDocSortedHitQueue.patch in LUCENENET-94?
I think it is a localization problem but don't know the reason yet.
DIGY
-----Original Message-----
From: Michael Garski [mailto:[EMAIL PROTECTED]
Sent: Wednesday, September 19, 2007 2:44 AM
To: [email protected]
Subject: Re: Unit Tests
Thanks DIGY!
I also figured out that I had to perform a build on the DemoLib
project as well to get the tests to pass. Why are there three
separate Visual Studio solutions for Lucene.Net rather than
having all
of the projects in one solution with inter-project references? Is
there some compelling reason I am not aware of?
I still see two tests that are failing:
Search\TestSort\TestNormalizedScores
Search\TestSort\TestRemoteSort
Both are coming from within the
FieldDocSortedHitQueue.LessThan(Object
a, Object b) method. Am I the only one seeing this or are
these the
last tests to get to pass for 2.1? I'm stepping through
the tests now
to determine why they are failing.
Thanks,
Michael
DIGY wrote:
Compression (Test and Lucene.Net Projects):
1- Add SHARP_ZIP_LIB to Project/Builds/Conditional Compilation
symbols
2- Add a reference to ICSharpCode.SharpZipLib.dll(which
can be found
with googling)
Remoting:
Since all tests(TestRemoteSearchable and TestSort)
releated with
remoting use port 1099, it may the case that the port is used by
another server-thread. Running tests one after another(not
alltogether) can be a solution.
These are the changes i can remember.
DIGY
-----Original Message-----
From: Michael Garski [mailto:[EMAIL PROTECTED]
Sent: Tuesday, September 18, 2007 4:47 AM
To: [email protected]
Subject: Unit Tests
I have a question on the unit tests...
I've retrieved the latest source from the svn repository and built
both solutions in VS2005, but the unit tests involving remoting or
compression fail.
Am I missing a configuration for those to pass?
Thanks,
Michael
