from:"Updated"

[jira] [Updated] (LUCENENET-486) Wildcard queries are not analyzed

2012-04-19 Thread Updated


 [ 
https://issues.apache.org/jira/browse/LUCENENET-486?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Björn updated LUCENENET-486:


Description: 
The lucene 'QueryParser' doesn't analyze wildcard querys. The function 
'GetPrefixQuery'(QueryParser.cs) returns the string without any analyzation.

I have performed some queries to show the problem. The analyzer is the 
'Contrib.Analyzers.DE.GermanAnalyzer'

-- indexed word: 'Häuser'; in the index stemmed as: 'hau' --

query: Hau*; hit: yes
query: Hause*; hit: no; This should be a hit.


-- indexed word: 'Angebote'; in the index stemmed as: 'angebo' 
--

query: Angebo*; hit: yes
query: Angebot*; hit: no; This should be a hit.
query: Angebote*; hit: no; This should be a hit.

-- indexed word: 'Björn'; in the index stemmed as: 'bjor' --

query: Bjor*; hit: yes
query: Björ*; hit: no; This should be a hit.

  was:
The lucene 'QueryParser' doesn't analyze wildcard querys. The function 
'GetPrefixQuery'(QueryParser.cs) returns the string without any analyzation.

I have performed some queries to show the problem. The analyzer is the 
'Contrib.Analyzers.DE.GermanAnalyzer'

 indexed word: 'Häuser'; in the index stemmed as: 'hau' 

query: Hau*; hit: yes
query: Hause*; hit: no; This should be a hit.


 indexed word: 'Angebote'; in the index stemmed as: 'angebo' 

query: Angebo*; hit: yes
query: Angebot*; hit: no; This should be a hit.
query: Angebote*; hit: no; This should be a hit.

 indexed word: 'Björn'; in the index stemmed as: 'bjor' 

query: Bjor*; hit: yes
query: Björ*; hit: no; This should be a hit.


> Wildcard queries are not analyzed
> -
>
> Key: LUCENENET-486
> URL: https://issues.apache.org/jira/browse/LUCENENET-486
> Project: Lucene.Net
>  Issue Type: Bug
>  Components: Lucene.Net Contrib, Lucene.Net Core
>Affects Versions: Lucene.Net 2.9.2, Lucene.Net 2.9.4
> Environment: Windows 7, Visual Studio 2010, .net 4.0
>Reporter: Björn
> Attachments: LuceneTest.zip
>
>
> The lucene 'QueryParser' doesn't analyze wildcard querys. The function 
> 'GetPrefixQuery'(QueryParser.cs) returns the string without any analyzation.
> I have performed some queries to show the problem. The analyzer is the 
> 'Contrib.Analyzers.DE.GermanAnalyzer'
> -- indexed word: 'Häuser'; in the index stemmed as: 'hau' --
> query: Hau*; hit: yes
> query: Hause*; hit: no; This should be a hit.
> -- indexed word: 'Angebote'; in the index stemmed as: 'angebo' 
> --
> query: Angebo*; hit: yes
> query: Angebot*; hit: no; This should be a hit.
> query: Angebote*; hit: no; This should be a hit.
> -- indexed word: 'Björn'; in the index stemmed as: 'bjor' --
> query: Bjor*; hit: yes
> query: Björ*; hit: no; This should be a hit.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Updated] (LUCENENET-486) Wildcard queries are not analyzed

2012-04-19 Thread Updated


 [ 
https://issues.apache.org/jira/browse/LUCENENET-486?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Björn updated LUCENENET-486:


Attachment: LuceneTest.zip

My test project. Requires .net 4.0

> Wildcard queries are not analyzed
> -
>
> Key: LUCENENET-486
> URL: https://issues.apache.org/jira/browse/LUCENENET-486
> Project: Lucene.Net
>  Issue Type: Bug
>  Components: Lucene.Net Contrib, Lucene.Net Core
>Affects Versions: Lucene.Net 2.9.2, Lucene.Net 2.9.4
> Environment: Windows 7, Visual Studio 2010, .net 4.0
>Reporter: Björn
> Attachments: LuceneTest.zip
>
>
> The lucene 'QueryParser' doesn't analyze wildcard querys. The function 
> 'GetPrefixQuery'(QueryParser.cs) returns the string without any analyzation.
> I have performed some queries to show the problem. The analyzer is the 
> 'Contrib.Analyzers.DE.GermanAnalyzer'
>  indexed word: 'Häuser'; in the index stemmed as: 'hau' 
> query: Hau*; hit: yes
> query: Hause*; hit: no; This should be a hit.
>  indexed word: 'Angebote'; in the index stemmed as: 'angebo' 
> query: Angebo*; hit: yes
> query: Angebot*; hit: no; This should be a hit.
> query: Angebote*; hit: no; This should be a hit.
>  indexed word: 'Björn'; in the index stemmed as: 'bjor' 
> query: Bjor*; hit: yes
> query: Björ*; hit: no; This should be a hit.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Updated] (LUCENENET-485) IndexOutOfRangeException in FrenchStemmer

2012-04-17 Thread Christopher Currens (Updated) (JIRA)


 [ 
https://issues.apache.org/jira/browse/LUCENENET-485?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Christopher Currens updated LUCENENET-485:
--

Attachment: TestFrenchAnalyzer.cs.patch

Here's a patch for tests that should pass, they fail with what is in trunk.  
These tests pass in Java 3.0.3.

Patch was made from the trunk\test\contrib\Analyzers\Fr directory.

> IndexOutOfRangeException in FrenchStemmer
> -
>
> Key: LUCENENET-485
> URL: https://issues.apache.org/jira/browse/LUCENENET-485
> Project: Lucene.Net
>  Issue Type: Bug
>  Components: Lucene.Net Contrib
>Affects Versions: Lucene.Net 3.0.3
>Reporter: Christopher Currens
> Fix For: Lucene.Net 3.0.3
>
> Attachments: TestFrenchAnalyzer.cs.patch, tt.diff
>
>
> {quote}
> Hi list,
> I am not sure how to report bugs, or even if anybody is interested in bug 
> reports. However, I have been playing with lucene lately, and found out an 
> implementation bug in the Frenchstemmer 
> (/src/contrib/Analyzers/Fr/FrenchStemmer.cs). Whenever I tried to add a new 
> document to an index, I got an index out of range error. So I looked at the 
> code and fixed that issue: see my diff file attached.
> Please note that I also changed a few funky characters to unicode notation. 
> The code worked well with the funky characters, but I think it just looks 
> better with the \uxxx bits...
> Anyways, the important bits is the replacement of a couple of sb.Insert by 
> sb.Append.
> I hope this helps.
> Cheers,
> Sylvain
> {quote}

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Updated] (LUCENENET-483) Spatial Search skipping records when one location is close to origin, another one is away and radius is wider

2012-04-16 Thread Christopher Currens (Updated) (JIRA)


 [ 
https://issues.apache.org/jira/browse/LUCENENET-483?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Christopher Currens updated LUCENENET-483:
--

Fix Version/s: Lucene.Net 3.0.3

> Spatial Search skipping records when one location is close to origin, another 
> one is away and radius is wider
> -
>
> Key: LUCENENET-483
> URL: https://issues.apache.org/jira/browse/LUCENENET-483
> Project: Lucene.Net
>  Issue Type: Bug
>  Components: Lucene.Net Contrib
>Affects Versions: Lucene.Net 2.9.4, Lucene.Net 2.9.4g
> Environment: .Net framework 4.0
>Reporter: Aleksandar Panov
>  Labels: lucene, spatialsearch
> Fix For: Lucene.Net 3.0.3
>
>
> Running a spatial query against two locations where one location is close to 
> origin (less than a mile), another one is away (24 miles) and radius is wider 
> (52 miles) returns only one result. Running query with a bit wider radius 
> (53.8) returns 2 results.
> IMPORTANT UPDATE: Problem can't be reproduced in Java, with using original 
> Lucene.Spatial (2.9.4 version) library.
> {code}
> // Origin
> private double _lat = 42.350153;
> private double _lng = -71.061667;
> private const string LatField = "lat";
> private const string LngField = "lng";
> //Locations
> AddPoint(writer, "Location 1", 42.0, -71.0); //24 miles away from 
> origin
> AddPoint(writer, "Location 2", 42.35, -71.06); //less than a mile
> [TestMethod]
> public void TestAntiM()
> {
> _directory = new RAMDirectory();
> var writer = new IndexWriter(_directory, new 
> WhitespaceAnalyzer(), true, IndexWriter.MaxFieldLength.UNLIMITED);
> SetUpPlotter(2, 15);
> AddData(writer);
> _searcher = new IndexSearcher(_directory, true);
> //const double miles = 53.8; // Correct. Returns 2 Locations.
> const double miles = 52; // Incorrect. Returns 1 Location.
> Console.WriteLine("testAntiM");
> // create a distance query
> var dq = new DistanceQueryBuilder(_lat, _lng, miles, LatField, 
> LngField, CartesianTierPlotter.DefaltFieldPrefix, true);
> Console.WriteLine(dq);
> //create a term query to search against all documents
> Query tq = new TermQuery(new Term("metafile", "doc"));
> var dsort = new DistanceFieldComparatorSource(dq.DistanceFilter);
> Sort sort = new Sort(new SortField("foo", dsort, false));
> // Perform the search, using the term query, the distance filter, 
> and the
> // distance sort
> TopDocs hits = _searcher.Search(tq, dq.Filter, 1000, sort);
> int results = hits.TotalHits;
> ScoreDoc[] scoreDocs = hits.ScoreDocs;
> // Get a list of distances
> Dictionary distances = dq.DistanceFilter.Distances;
> Console.WriteLine("Distance Filter filtered: " + distances.Count);
> Console.WriteLine("Results: " + results);
> Console.WriteLine("=");
> Console.WriteLine("Distances should be 2 " + distances.Count);
> Console.WriteLine("Results should be 2 " + results);
> Assert.AreEqual(2, distances.Count); // fixed a store of only 
> needed distances
> Assert.AreEqual(2, results);
> }
> {code} 

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Updated] (LUCENENET-484) Some possibly major tests intermittently fail

2012-04-13 Thread Christopher Currens (Updated) (JIRA)


 [ 
https://issues.apache.org/jira/browse/LUCENENET-484?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Christopher Currens updated LUCENENET-484:
--

Description: 
These tests will fail intermittently in Debug or Release mode, in the core test 
suite:

# -Lucene.Net.Index:-
#- -TestConcurrentMergeScheduler.TestFlushExceptions-
# Lucene.Net.Store:
#- TestLockFactory.TestStressLocks
# Lucene.Net.Search:
#- TestSort.TestParallelMultiSort
# Lucene.Net.Util:
#- TestFieldCacheSanityChecker.TestInsanity1
#- TestFieldCacheSanityChecker.TestInsanity2
#- (It's possible all of the insanity tests fail at one point or another)
# Lucene.Net.Support
#- TestWeakHashTableMultiThreadAccess.Test

TestWeakHashTableMultiThreadAccess should be fine to remove along with the 
WeakHashTable in the Support namespace, since it's been replaced with 
WeakDictionary.

  was:
These tests will fail intermittently in Debug or Release mode, in the core test 
suite:

# Lucene.Net.Index:
#- TestConcurrentMergeScheduler.TestFlushExceptions
# Lucene.Net.Store:
#- TestLockFactory.TestStressLocks
# Lucene.Net.Search:
#- TestSort.TestParallelMultiSort
# Lucene.Net.Util:
#- TestFieldCacheSanityChecker.TestInsanity1
#- TestFieldCacheSanityChecker.TestInsanity2
#- (It's possible all of the insanity tests fail at one point or another)
# Lucene.Net.Support
#- TestWeakHashTableMultiThreadAccess.Test

TestWeakHashTableMultiThreadAccess should be fine to remove along with the 
WeakHashTable in the Support namespace, since it's been replaced with 
WeakDictionary.


So, I figured out the issue with the ConcurrentMergeScheduler, it was simply a 
port issue for the actual Test.  I had to add a workaround in 
{{FailOnlyOnFlush.Eval(Directory)}}, since java would compare stack frame with 
"main" (the thread running the test, it seems), and only execute the code if 
that was the case.  That doesn't exactly work in .NET code, so instead, I 
inverted the check too look for the thread name not containing "Merge Thread".  
I can no longer reproduce it at all, where I could before every time.

> Some possibly major tests intermittently fail 
> --
>
> Key: LUCENENET-484
> URL: https://issues.apache.org/jira/browse/LUCENENET-484
> Project: Lucene.Net
>  Issue Type: Bug
>  Components: Lucene.Net Core, Lucene.Net Test
>Affects Versions: Lucene.Net 3.0.3
>Reporter: Christopher Currens
> Fix For: Lucene.Net 3.0.3
>
>
> These tests will fail intermittently in Debug or Release mode, in the core 
> test suite:
> # -Lucene.Net.Index:-
> #- -TestConcurrentMergeScheduler.TestFlushExceptions-
> # Lucene.Net.Store:
> #- TestLockFactory.TestStressLocks
> # Lucene.Net.Search:
> #- TestSort.TestParallelMultiSort
> # Lucene.Net.Util:
> #- TestFieldCacheSanityChecker.TestInsanity1
> #- TestFieldCacheSanityChecker.TestInsanity2
> #- (It's possible all of the insanity tests fail at one point or another)
> # Lucene.Net.Support
> #- TestWeakHashTableMultiThreadAccess.Test
> TestWeakHashTableMultiThreadAccess should be fine to remove along with the 
> WeakHashTable in the Support namespace, since it's been replaced with 
> WeakDictionary.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Updated] (LUCENENET-483) Spatial Search skipping records when one location is close to origin, another one is away and radius is wider

2012-04-09 Thread Aleksandar Panov (Updated) (JIRA)


 [ 
https://issues.apache.org/jira/browse/LUCENENET-483?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Aleksandar Panov updated LUCENENET-483:
---

Description: 
Running a spatial query against two locations where one location is close to 
origin (less than a mile), another one is away (24 miles) and radius is wider 
(52 miles) returns only one result. Running query with a bit wider radius 
(53.8) returns 2 results.

IMPORTANT UPDATE: Problem can't be reproduced in Java, with using original 
Lucene.Spatial (2.9.4 version) library.

{code}

// Origin
private double _lat = 42.350153;
private double _lng = -71.061667;
private const string LatField = "lat";
private const string LngField = "lng";

//Locations
AddPoint(writer, "Location 1", 42.0, -71.0); //24 miles away from origin
AddPoint(writer, "Location 2", 42.35, -71.06); //less than a mile

[TestMethod]
public void TestAntiM()
{
_directory = new RAMDirectory();

var writer = new IndexWriter(_directory, new WhitespaceAnalyzer(), 
true, IndexWriter.MaxFieldLength.UNLIMITED);

SetUpPlotter(2, 15);

AddData(writer);


_searcher = new IndexSearcher(_directory, true);

//const double miles = 53.8; // Correct. Returns 2 Locations.
const double miles = 52; // Incorrect. Returns 1 Location.

Console.WriteLine("testAntiM");
// create a distance query
var dq = new DistanceQueryBuilder(_lat, _lng, miles, LatField, 
LngField, CartesianTierPlotter.DefaltFieldPrefix, true);

Console.WriteLine(dq);
//create a term query to search against all documents
Query tq = new TermQuery(new Term("metafile", "doc"));

var dsort = new DistanceFieldComparatorSource(dq.DistanceFilter);
Sort sort = new Sort(new SortField("foo", dsort, false));

// Perform the search, using the term query, the distance filter, 
and the
// distance sort
TopDocs hits = _searcher.Search(tq, dq.Filter, 1000, sort);
int results = hits.TotalHits;
ScoreDoc[] scoreDocs = hits.ScoreDocs;

// Get a list of distances
Dictionary distances = dq.DistanceFilter.Distances;

Console.WriteLine("Distance Filter filtered: " + distances.Count);
Console.WriteLine("Results: " + results);
Console.WriteLine("=");
Console.WriteLine("Distances should be 2 " + distances.Count);
Console.WriteLine("Results should be 2 " + results);

Assert.AreEqual(2, distances.Count); // fixed a store of only 
needed distances
Assert.AreEqual(2, results);
}

{code} 

  was:
Running a spatial query against two locations where one location is close to 
origin (less than a mile), another one is away (24 miles) and radius is wider 
(52 miles) returns only one result. Running query with a bit wider radius 
(53.8) returns 2 results.

IMPORTANT UPDATE: Problem can't be reproduce in Java, with using original 
Lucene.Spatial (2.9.4 version) library.

{code}

// Origin
private double _lat = 42.350153;
private double _lng = -71.061667;
private const string LatField = "lat";
private const string LngField = "lng";

//Locations
AddPoint(writer, "Location 1", 42.0, -71.0); //24 miles away from origin
AddPoint(writer, "Location 2", 42.35, -71.06); //less than a mile

[TestMethod]
public void TestAntiM()
{
_directory = new RAMDirectory();

var writer = new IndexWriter(_directory, new WhitespaceAnalyzer(), 
true, IndexWriter.MaxFieldLength.UNLIMITED);

SetUpPlotter(2, 15);

AddData(writer);


_searcher = new IndexSearcher(_directory, true);

//const double miles = 53.8; // Correct. Returns 2 Locations.
const double miles = 52; // Incorrect. Returns 1 Location.

Console.WriteLine("testAntiM");
// create a distance query
var dq = new DistanceQueryBuilder(_lat, _lng, miles, LatField, 
LngField, CartesianTierPlotter.DefaltFieldPrefix, true);

Console.WriteLine(dq);
//create a term query to search against all documents
Query tq = new TermQuery(new Term("metafile", "doc"));

var dsort = new DistanceFieldComparatorSource(dq.DistanceFilter);
Sort sort = new Sort(new SortField("foo", dsort, false));

// Perform the search, using t

[jira] [Updated] (LUCENENET-483) Spatial Search skipping records when one location is close to origin, another one is away and radius is wider

2012-04-09 Thread Aleksandar Panov (Updated) (JIRA)


 [ 
https://issues.apache.org/jira/browse/LUCENENET-483?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Aleksandar Panov updated LUCENENET-483:
---

Description: 
Running a spatial query against two locations where one location is close to 
origin (less than a mile), another one is away (24 miles) and radius is wider 
(52 miles) returns only one result. Running query with a bit wider radius 
(53.8) returns 2 results.

IMPORTANT UPDATE: Problem can't be reproduce in Java, with using original 
Lucene.Spatial (2.9.4 version) library.

{code}

// Origin
private double _lat = 42.350153;
private double _lng = -71.061667;
private const string LatField = "lat";
private const string LngField = "lng";

//Locations
AddPoint(writer, "Location 1", 42.0, -71.0); //24 miles away from origin
AddPoint(writer, "Location 2", 42.35, -71.06); //less than a mile

[TestMethod]
public void TestAntiM()
{
_directory = new RAMDirectory();

var writer = new IndexWriter(_directory, new WhitespaceAnalyzer(), 
true, IndexWriter.MaxFieldLength.UNLIMITED);

SetUpPlotter(2, 15);

AddData(writer);


_searcher = new IndexSearcher(_directory, true);

//const double miles = 53.8; // Correct. Returns 2 Locations.
const double miles = 52; // Incorrect. Returns 1 Location.

Console.WriteLine("testAntiM");
// create a distance query
var dq = new DistanceQueryBuilder(_lat, _lng, miles, LatField, 
LngField, CartesianTierPlotter.DefaltFieldPrefix, true);

Console.WriteLine(dq);
//create a term query to search against all documents
Query tq = new TermQuery(new Term("metafile", "doc"));

var dsort = new DistanceFieldComparatorSource(dq.DistanceFilter);
Sort sort = new Sort(new SortField("foo", dsort, false));

// Perform the search, using the term query, the distance filter, 
and the
// distance sort
TopDocs hits = _searcher.Search(tq, dq.Filter, 1000, sort);
int results = hits.TotalHits;
ScoreDoc[] scoreDocs = hits.ScoreDocs;

// Get a list of distances
Dictionary distances = dq.DistanceFilter.Distances;

Console.WriteLine("Distance Filter filtered: " + distances.Count);
Console.WriteLine("Results: " + results);
Console.WriteLine("=");
Console.WriteLine("Distances should be 2 " + distances.Count);
Console.WriteLine("Results should be 2 " + results);

Assert.AreEqual(2, distances.Count); // fixed a store of only 
needed distances
Assert.AreEqual(2, results);
}

{code} 

  was:
Running a spatial query against two locations where one location is close to 
origin (less than a mile), another one is away (24 miles) and radius is wider 
(52 miles) returns only one result. Running query with a bit wider radius 
(53.8) returns 2 results.

{code}

// Origin
private double _lat = 42.350153;
private double _lng = -71.061667;
private const string LatField = "lat";
private const string LngField = "lng";

//Locations
AddPoint(writer, "Location 1", 42.0, -71.0); //24 miles away from origin
AddPoint(writer, "Location 2", 42.35, -71.06); //less than a mile

[TestMethod]
public void TestAntiM()
{
_directory = new RAMDirectory();

var writer = new IndexWriter(_directory, new WhitespaceAnalyzer(), 
true, IndexWriter.MaxFieldLength.UNLIMITED);

SetUpPlotter(2, 15);

AddData(writer);


_searcher = new IndexSearcher(_directory, true);

//const double miles = 53.8; // Correct. Returns 2 Locations.
const double miles = 52; // Incorrect. Returns 1 Location.

Console.WriteLine("testAntiM");
// create a distance query
var dq = new DistanceQueryBuilder(_lat, _lng, miles, LatField, 
LngField, CartesianTierPlotter.DefaltFieldPrefix, true);

Console.WriteLine(dq);
//create a term query to search against all documents
Query tq = new TermQuery(new Term("metafile", "doc"));

var dsort = new DistanceFieldComparatorSource(dq.DistanceFilter);
Sort sort = new Sort(new SortField("foo", dsort, false));

// Perform the search, using the term query, the distance filter, 
and the
// distance sort
TopDocs hi

[jira] [Updated] (LUCENENET-483) Spatial Search skipping records when one location is close to origin, another one is away and radius is wider

2012-04-09 Thread Aleksandar Panov (Updated) (JIRA)


 [ 
https://issues.apache.org/jira/browse/LUCENENET-483?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Aleksandar Panov updated LUCENENET-483:
---

Summary: Spatial Search skipping records when one location is close to 
origin, another one is away and radius is wider  (was: Spatial Search skipping 
records when one location is close to origin, another is away and radius is 
wider)

> Spatial Search skipping records when one location is close to origin, another 
> one is away and radius is wider
> -
>
> Key: LUCENENET-483
> URL: https://issues.apache.org/jira/browse/LUCENENET-483
> Project: Lucene.Net
>  Issue Type: Bug
>  Components: Lucene.Net Contrib
>Affects Versions: Lucene.Net 2.9.4, Lucene.Net 2.9.4g
> Environment: .Net framework 4.0
>Reporter: Aleksandar Panov
>  Labels: lucene, spatialsearch
>
> Running a spatial query against two locations where one location is close to 
> origin (less than a mile), another one is away (24 miles) and radius is wider 
> (52 miles) returns only one result. Running query with a bit wider radius 
> (53.8) returns 2 results.
> {code}
> // Origin
> private double _lat = 42.350153;
> private double _lng = -71.061667;
> private const string LatField = "lat";
> private const string LngField = "lng";
> //Locations
> AddPoint(writer, "Location 1", 42.0, -71.0); //24 miles away from 
> origin
> AddPoint(writer, "Location 2", 42.35, -71.06); //less than a mile
> [TestMethod]
> public void TestAntiM()
> {
> _directory = new RAMDirectory();
> var writer = new IndexWriter(_directory, new 
> WhitespaceAnalyzer(), true, IndexWriter.MaxFieldLength.UNLIMITED);
> SetUpPlotter(2, 15);
> AddData(writer);
> _searcher = new IndexSearcher(_directory, true);
> //const double miles = 53.8; // Correct. Returns 2 Locations.
> const double miles = 52; // Incorrect. Returns 1 Location.
> Console.WriteLine("testAntiM");
> // create a distance query
> var dq = new DistanceQueryBuilder(_lat, _lng, miles, LatField, 
> LngField, CartesianTierPlotter.DefaltFieldPrefix, true);
> Console.WriteLine(dq);
> //create a term query to search against all documents
> Query tq = new TermQuery(new Term("metafile", "doc"));
> var dsort = new DistanceFieldComparatorSource(dq.DistanceFilter);
> Sort sort = new Sort(new SortField("foo", dsort, false));
> // Perform the search, using the term query, the distance filter, 
> and the
> // distance sort
> TopDocs hits = _searcher.Search(tq, dq.Filter, 1000, sort);
> int results = hits.TotalHits;
> ScoreDoc[] scoreDocs = hits.ScoreDocs;
> // Get a list of distances
> Dictionary distances = dq.DistanceFilter.Distances;
> Console.WriteLine("Distance Filter filtered: " + distances.Count);
> Console.WriteLine("Results: " + results);
> Console.WriteLine("=");
> Console.WriteLine("Distances should be 2 " + distances.Count);
> Console.WriteLine("Results should be 2 " + results);
> Assert.AreEqual(2, distances.Count); // fixed a store of only 
> needed distances
> Assert.AreEqual(2, results);
> }
> {code} 

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Updated] (LUCENENET-477) NullReferenceException in ThreadLocal when Lucene.Net compiled for .Net 2.0

2012-03-21 Thread Andrew Sampson (Updated) (JIRA)


 [ 
https://issues.apache.org/jira/browse/LUCENENET-477?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Andrew Sampson updated LUCENENET-477:
-

Attachment: CloseableThreadLocal.cs.patch

fixes nullReferenceException in ThreadLocal class under .net 2

> NullReferenceException in ThreadLocal when Lucene.Net compiled for .Net 2.0
> ---
>
> Key: LUCENENET-477
> URL: https://issues.apache.org/jira/browse/LUCENENET-477
> Project: Lucene.Net
>  Issue Type: Bug
>  Components: Lucene.Net Core
>Affects Versions: Lucene.Net 2.9.4g
> Environment: .Net 2.0
>Reporter: Andrew Sampson
> Attachments: CloseableThreadLocal.cs.patch
>
>
> A NullReferenceException occurs in Lucene.Net.Util.ThreadLocal. This class is 
> only included when Lucene is compiled for .Net 2.0. 
> The cause is that the threadstatic "slots" variable is lazily-initialized, 
> but there is no null-check in the dispose.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Updated] (LUCENENET-476) ScoreDocs in TopDocs is ambiguos when using Visual Basic .Net

2012-03-19 Thread Christopher Currens (Updated) (JIRA)


 [ 
https://issues.apache.org/jira/browse/LUCENENET-476?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Christopher Currens updated LUCENENET-476:
--

Issue Type: Bug  (was: Sub-task)
Parent: (was: LUCENENET-446)

> ScoreDocs in TopDocs is ambiguos when using Visual Basic .Net
> -
>
> Key: LUCENENET-476
> URL: https://issues.apache.org/jira/browse/LUCENENET-476
> Project: Lucene.Net
>  Issue Type: Bug
>  Components: Lucene.Net Core
>Affects Versions: Lucene.Net 2.9.4
> Environment: Visual Basic .Net
>Reporter: Jon
> Fix For: Lucene.Net 3.0.3
>
>
> The field TopDocs.scoreDocs has been made obsolete and a new property 
> TopDocs.ScoreDocs has been added. VB.Net is case insensitive, so both resolve 
> to the same name, resulting in the following error message:
> {quote}
> 'ScoreDocs' is ambiguous because multiple kinds of members with this name 
> exist in class 'Lucene.Net.Search.TopDocs'
> {quote}

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Updated] (LUCENENET-476) ScoreDocs in TopDocs is ambiguos when using Visual Basic .Net

2012-03-19 Thread Christopher Currens (Updated) (JIRA)


 [ 
https://issues.apache.org/jira/browse/LUCENENET-476?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Christopher Currens updated LUCENENET-476:
--

Issue Type: Sub-task  (was: Bug)
Parent: LUCENENET-446

> ScoreDocs in TopDocs is ambiguos when using Visual Basic .Net
> -
>
> Key: LUCENENET-476
> URL: https://issues.apache.org/jira/browse/LUCENENET-476
> Project: Lucene.Net
>  Issue Type: Sub-task
>  Components: Lucene.Net Core
>Affects Versions: Lucene.Net 2.9.4
> Environment: Visual Basic .Net
>Reporter: Jon
>
> The field TopDocs.scoreDocs has been made obsolete and a new property 
> TopDocs.ScoreDocs has been added. VB.Net is case insensitive, so both resolve 
> to the same name, resulting in the following error message:
> {quote}
> 'ScoreDocs' is ambiguous because multiple kinds of members with this name 
> exist in class 'Lucene.Net.Search.TopDocs'
> {quote}

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Updated] (LUCENENET-475) DanishStemmer doesn't work.

2012-03-11 Thread Johannes Hansen (Updated) (JIRA)


 [ 
https://issues.apache.org/jira/browse/LUCENENET-475?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Johannes Hansen updated LUCENENET-475:
--

Description: 
The following code fails with a ArgumentOutOfRangeException in line 467 of 
"\src\contrib\Snowball\SF\Snowball\SnowballProgram.cs":

var stemmer = new DanishStemmer();
stemmer.SetCurrent("heste");
stemmer.Stem();
Console.WriteLine(stemmer.GetCurrent());

Expected: Output "hest" to console.

Possible fix: Seems like the line should have been

s.Append(current.ToString(bra, len));

instead of:

s.Append(current.ToString(bra, ket));

  was:
The following code fails with a ArgumentOutOfRangeException in line 467 of 
"\src\contrib\Snowball\SF\Snowball\SnowballProgram.cs":

var stemmer = new DanishStemmer();
stemmer.SetCurrent("hest");
stemmer.Stem();
Console.WriteLine(stemmer.GetCurrent());

Expected: Output "hest" to console.

Possible fix: Seems like the line should have been

s.Append(current.ToString(bra, len));

instead of:

s.Append(current.ToString(bra, ket));


> DanishStemmer doesn't work.
> ---
>
> Key: LUCENENET-475
> URL: https://issues.apache.org/jira/browse/LUCENENET-475
> Project: Lucene.Net
>  Issue Type: Bug
>  Components: Lucene.Net Contrib
>Affects Versions: Lucene.Net 2.9.4g
>Reporter: Johannes Hansen
>  Labels: danish, snowball, stemmer
>
> The following code fails with a ArgumentOutOfRangeException in line 467 of 
> "\src\contrib\Snowball\SF\Snowball\SnowballProgram.cs":
> var stemmer = new DanishStemmer();
> stemmer.SetCurrent("heste");
> stemmer.Stem();
> Console.WriteLine(stemmer.GetCurrent());
> Expected: Output "hest" to console.
> Possible fix: Seems like the line should have been
> s.Append(current.ToString(bra, len));
> instead of:
> s.Append(current.ToString(bra, ket));

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira

[Lucene.Net] [jira] [Updated] (LUCENENET-474) Missing License Headers in trunk after 3.0.3 merge

2012-03-02 Thread Stefan Bodewig (Updated) (JIRA)


 [ 
https://issues.apache.org/jira/browse/LUCENENET-474?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Stefan Bodewig updated LUCENENET-474:
-

Attachment: LUCENENET-474.patch

Patch that adds the missing license headers

> Missing License Headers in trunk after 3.0.3 merge
> --
>
> Key: LUCENENET-474
> URL: https://issues.apache.org/jira/browse/LUCENENET-474
> Project: Lucene.Net
>  Issue Type: Bug
>Reporter: Stefan Bodewig
>Priority: Blocker
> Fix For: Lucene.Net 3.0.3
>
> Attachments: LUCENENET-474.patch
>
>
> I'll attach a RAT generated patch shortly.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira

[Lucene.Net] [jira] [Updated] (LUCENENET-468) Implement the Dispose pattern properly in classes with Close

2012-01-23 Thread Christopher Currens (Updated) (JIRA)


 [ 
https://issues.apache.org/jira/browse/LUCENENET-468?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Christopher Currens updated LUCENENET-468:
--

Description: 
Implement the dispose pattern as [suggested 
here|http://msdn.microsoft.com/en-us/library/fs2xkftw.aspx] on any class that 
implements Close().  Be sure to implement the IDisposable.Dispose() only in the 
base class, and have all sub-class behavior overridden in a protected method.

This change will involve making sure that everywhere the classes are used in 
contrib, core, demo and test, that dispose is called on them.  We don't want to 
neglect calling dispose in our own code.  For those with Visual Studio 2010 
Premium or higher, turning on Code Analysis in the project settings will flag a 
warning that Dispose needs to be called on a class, so you don't have to 
manually go searching for it.

These changes do not have to be breaking.  Instead, also make {{Close}} a 
public method in the base class and have it call {{Dispose}}.  Mark it with the 
Obsolete attribute, so we can remove it in later releases.

  was:
Implement the dispose pattern as [suggested 
here|http://msdn.microsoft.com/en-us/library/fs2xkftw.aspx] on any class that 
implements Close().  Be sure to implement the IDisposable.Dispose() only in the 
base class, and have all sub-class behavior overridden in a protected method.

This change will involve making sure that everywhere the classes are used in 
contrib, core, demo and test, that dispose is called on them.  We don't want to 
neglect calling dispose in our own code.  For those with Visual Studio 2010 
Premium or higher, turning on Code Analysis in the project settings will flag a 
warning that Dispose needs to be called on a class, so you don't have to 
manually go searching for it.


> Implement the Dispose pattern properly in classes with Close
> 
>
> Key: LUCENENET-468
> URL: https://issues.apache.org/jira/browse/LUCENENET-468
> Project: Lucene.Net
>  Issue Type: Sub-task
>  Components: Lucene.Net Contrib, Lucene.Net Core, Lucene.Net Demo, 
> Lucene.Net Test
>Affects Versions: Lucene.Net 2.9.2, Lucene.Net 2.9.4, Lucene.Net 3.0.3, 
> Lucene.Net 2.9.4g
> Environment: all
>Reporter: Christopher Currens
> Fix For: Lucene.Net 3.0.3
>
>
> Implement the dispose pattern as [suggested 
> here|http://msdn.microsoft.com/en-us/library/fs2xkftw.aspx] on any class that 
> implements Close().  Be sure to implement the IDisposable.Dispose() only in 
> the base class, and have all sub-class behavior overridden in a protected 
> method.
> This change will involve making sure that everywhere the classes are used in 
> contrib, core, demo and test, that dispose is called on them.  We don't want 
> to neglect calling dispose in our own code.  For those with Visual Studio 
> 2010 Premium or higher, turning on Code Analysis in the project settings will 
> flag a warning that Dispose needs to be called on a class, so you don't have 
> to manually go searching for it.
> These changes do not have to be breaking.  Instead, also make {{Close}} a 
> public method in the base class and have it call {{Dispose}}.  Mark it with 
> the Obsolete attribute, so we can remove it in later releases.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira

[Lucene.Net] [jira] [Updated] (LUCENENET-445) Lucene.Net.Index.TestIndexWriter.TestFutureCommit() Fails

2012-01-23 Thread Christopher Currens (Updated) (JIRA)


 [ 
https://issues.apache.org/jira/browse/LUCENENET-445?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Christopher Currens updated LUCENENET-445:
--


This doesn't fail in Debug or Release in the 3.0.3 branch.  I'm not even sure 
if it still fails in 2.9.4?  Can this be closed?

> Lucene.Net.Index.TestIndexWriter.TestFutureCommit() Fails
> -
>
> Key: LUCENENET-445
> URL: https://issues.apache.org/jira/browse/LUCENENET-445
> Project: Lucene.Net
>  Issue Type: Bug
>Affects Versions: Lucene.Net 2.9.4
>Reporter: Prescott Nasser
>Priority: Minor
>
> Fails with the following error:
> System.Collections.Generic.KeyNotFoundException was unhandled by user code
>   Message=The given key was not present in the dictionary.
>   Source=mscorlib
>   StackTrace:
>at System.Collections.Generic.Dictionary`2.get_Item(TKey key)
>at Lucene.Net.Index.TestIndexWriter.TestFutureCommit() in 
> C:\Users\GeoBMX540\Desktop\Trunk\test\core\Index\TestIndexWriter.cs:line 5969
>   InnerException: 

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira

[Lucene.Net] [jira] [Updated] (LUCENENET-179) SnowballFilter speed improvment

2012-01-23 Thread Christopher Currens (Updated) (JIRA)


 [ 
https://issues.apache.org/jira/browse/LUCENENET-179?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Christopher Currens updated LUCENENET-179:
--

Fix Version/s: Lucene.Net 3.0.3

I haven't looked at the code, but I'm adding it into 3.0.3 anyway.  When 
someone has the time to look over it and test it, we can decide if we plan on 
including it or not.  At first glance, it looks good, but I wouldn't want to 
sign off on it until we're sure it fits in with the changes of 3.0.3 and passes 
all tests.

> SnowballFilter speed improvment
> ---
>
> Key: LUCENENET-179
> URL: https://issues.apache.org/jira/browse/LUCENENET-179
> Project: Lucene.Net
>  Issue Type: Improvement
>  Components: Lucene.Net Contrib
>Affects Versions: Lucene.Net 2.9.2
>Reporter: Arian Bär
> Fix For: Lucene.Net 3.0.3
>
> Attachments: FailOverSnowballFilter.cs
>
>
> I'm using Lucene.Net along with snowball stemming to index text from a 
> database. The class Lucene.Net.Analysis.Snowball.SnowballFilter uses the 
> reflection API and the invoke method to call the stem methods of snowball. I 
> have written a Snowball filter which creates a delegate and uses this 
> delegate to stem the words afterwards. This approach improves the indexing 
> speed of my indexing program by about 10%. I would be happy if you include 
> this code into lucene.net.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira

[Lucene.Net] [jira] [Updated] (LUCENENET-423) QueryParser differences between Java and .NET when parsing range queries involving dates

2012-01-23 Thread Christopher Currens (Updated) (JIRA)


 [ 
https://issues.apache.org/jira/browse/LUCENENET-423?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Christopher Currens updated LUCENENET-423:
--

Fix Version/s: Lucene.Net 3.0.3
  Summary: QueryParser differences between Java and .NET when parsing 
range queries involving dates  (was: QueryParser differences between Java and 
.NET)

This is a difference of behavior between searching in Java and .NET.  While 
.NET is more accurate about DateTime parsing, that difference in behavior seems 
to be against what was discussed [in this email 
thread|http://mail-archives.apache.org/mod_mbox/lucene-lucene-net-dev/201112.mbox/%3CCAFZAm_VxWaNZmCAUZPFt2%2B9HJBXJjSTmJ-uLj%3DQh-naGja9MKA%40mail.gmail.com%3E],
 regarding people's wishes for the future of the project.  Much of what was 
agreed upon was the project having much of the same behavior of Java, in that 
indexes are compatible and searches in each returning the same results for the 
same search on the same index.

> QueryParser differences between Java and .NET when parsing range queries 
> involving dates
> 
>
> Key: LUCENENET-423
> URL: https://issues.apache.org/jira/browse/LUCENENET-423
> Project: Lucene.Net
>  Issue Type: Bug
>Affects Versions: Lucene.Net 2.9.2, Lucene.Net 2.9.4, Lucene.Net 2.9.4g
>Reporter: Christopher Currens
> Fix For: Lucene.Net 3.0.3
>
>
> When trying to do a RangeQuery that uses dates in a certain format, .NET 
> behaves differently from its Java counterpart.  The code is the same between 
> them, but as far as I can tell, it appears that it is a difference in the way 
> Java parses dates vs how .NET parses dates.  To reproduce:
> {code:java}
> var queryParser = new QueryParser(Lucene.Net.Util.Version.LUCENE_29, 
> "FullText", new StandardAnalyzer(Lucene.Net.Util.Version.LUCENE_29));
> var query = queryParser.Parse("Field:[2001-01-17 TO 2001-01-20]");
> {code}
> You'll notice that query looks like the old DateField format (eg 
> "0g1d64542").  If you do the same query in Java (or Luke), you'll notice the 
> query gets parsed as if it were a RangeQuery of string.  AFAIK, Java cannot 
> parse a string formatted in that way.  If you change the string to use / 
> instead of - in the java, you'll get one that uses DateResolutions and 
> DateTools.DateToString().
> It seems an appropriate fix for this, if we wanted to keep this behavior 
> similar to Java, would be to write our own DateTime parser that behaved the 
> same way to Java's parser.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira

[Lucene.Net] [jira] [Updated] (LUCENENET-435) Fix the test suite for Lucene.Net Core

2012-01-23 Thread Christopher Currens (Updated) (JIRA)

[
https://issues.apache.org/jira/browse/LUCENENET-435?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]

Christopher Currens updated LUCENENET-435:
--

Description:
If wish to work on one of these, create a new sub-task from this one, assign it
to yourself and submit the patch or commit it. make sure that if you create any
new files to include the apache 2.0 license.

* There needs to be a running list of things to do/not to do with testing. I
don't know if this goes in a jira or do we keep a running list on the wiki or
site for people to pick up and help with.
* Tests need to run on mono and not Fail (there is a good deal of failing
tests on mono, mostly due to the temp directory have the C:\ in the path).
* Assert.Throw() needs to be used instead of Try/Catch
Assert.Fail. **
* File & Path combines to the temp directory need helper methods,
* e,g, having this in a hundred places is bad new
System.IO.FileInfo(System.IO.Path.Combine(Support.AppSettings.Get("tempDir",
""), "testIndex"));
* We should still be testing deprecated methods, but we need to use #pragma
warning disable/enable 0618 for testing those. otherwise compiler warnings are
too numerous to be anywhere near helpful.
* We should only be using deprecated methods in places where they are being
explicitly tested, other tests that need that functionality in order to
validate those tests should be re factored to use methods that are not
deprecated.
* Identify code that could be abstracted into test utility classes.
* Infrastructure Validation tests need to be made, anything that seems like
infrastructure. e.g. does the temp directory exist, does the folders that the
tests use inside the temp directory exist, can we read/write to those folders.
(if a ton of tests fail due to the file system, we should be able to point out
that it was due to permissions or missing folders, files, etc).
* Identify what classes need an interface, abstract class or inherited in
order to create testing mocks. (once those classes are created, they should be
documented in the wiki).
* fix rethrows inside try/catches that log information then rethrows the
exception. i.e. use throw; instead of throw ex;

Note Assert.Throws needs to replace stuff like the following. We should also be
checking the messages for exceptions and make sure they make sense and can help
users fix isses if the exceptions are aimed at the library users.
try
{
d = DateTools.StringToDate("97"); // no date
Assert.Fail();
}
catch (System.FormatException e)
{
/* expected exception */

was:
If wish to work on one of these, create a new sub-task from this one, assign it
to yourself and submit the patch or commit it. make sure that if you create any
new files to include the apache 2.0 license.

[Lucene.Net] [jira] [Updated] (LUCENENET-436) Refactor Deprecated Code inside of tests

2012-01-23 Thread Christopher Currens (Updated) (JIRA)


 [ 
https://issues.apache.org/jira/browse/LUCENENET-436?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Christopher Currens updated LUCENENET-436:
--

Fix Version/s: Lucene.Net 3.0.3

This is a nice to have for the 3.x release.  A lot of the tests are written 
with deprecated code simply, because they are that way in Java Lucene, and thus 
haven't been updated.  Unless the majority objects, I agree that we should take 
this approach of removing the deprecated code ourselves, when the test isn't 
testing the behavior of the deprecated method itself, instead of sticking to 
exact Java tests.

I say we try and get as much of it as we can updated, but not have this issue 
block a 3.x release if we run out of time.

> Refactor Deprecated Code inside of tests 
> -
>
> Key: LUCENENET-436
> URL: https://issues.apache.org/jira/browse/LUCENENET-436
> Project: Lucene.Net
>  Issue Type: Sub-task
>  Components: Lucene.Net Test
>Affects Versions: Lucene.Net 2.9.4g
>Reporter: michael herndon
>  Labels: refactoring, testing,
> Fix For: Lucene.Net 3.0.3
>
>
> * We should still be testing deprecated methods, but we need to use #pragma 
> warning disable/enable 0618 for testing those. otherwise compiler warnings 
> are too numerous to be anywhere near helpful.
> * We should only be using deprecated methods in places where they are being 
> explicitly tested, other tests that need that functionality in 
> order to validate those tests should be re factored to use methods that are 
> not deprecated.
> This is one place we should probably deviate from the parent project and make 
> sure that any deprecated code gets isolated to the tests designed only for 
> the deprecated methods and then use the newer API through out the testsuite.
> This should help move the project forward and remove deprecated API's when 
> the time comes.   

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira

[Lucene.Net] [jira] [Updated] (LUCENENET-456) Create a Build Target that outputs compiled artifacts in apache release format

2012-01-23 Thread Christopher Currens (Updated) (JIRA)


 [ 
https://issues.apache.org/jira/browse/LUCENENET-456?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Christopher Currens updated LUCENENET-456:
--

  Component/s: Lucene.Net Core
Fix Version/s: Lucene.Net 3.0.3

I would like to have this in and as part of our release process before 3.0.3 is 
released.

> Create a Build Target that outputs compiled artifacts in apache release format
> --
>
> Key: LUCENENET-456
> URL: https://issues.apache.org/jira/browse/LUCENENET-456
> Project: Lucene.Net
>  Issue Type: Improvement
>  Components: Lucene.Net Core
>Reporter: Prescott Nasser
>Priority: Trivial
> Fix For: Lucene.Net 3.0.3
>
>
> When building in "release" the artifacts are sent to various folders. It 
> would be great if we could model the output of the release to mirror the 
> output we use when cutting a release (saving some time).
> /bin/Contrib/*files
> /bin/Demo/*files
> /bin/Lucene.Net.dll
> /doc/Contrib/*files
> /doc/Demo/*files
> /doc/Lucene.Net.xml

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira

[Lucene.Net] [jira] [Updated] (LUCENENET-463) Would like to be able to use a SimpleSpanFragmenter for extrcting whole sentances

2012-01-23 Thread Christopher Currens (Updated) (JIRA)


 [ 
https://issues.apache.org/jira/browse/LUCENENET-463?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Christopher Currens updated LUCENENET-463:
--

Fix Version/s: Lucene.Net 3.0.3

> Would like to be able to use a SimpleSpanFragmenter for extrcting whole 
> sentances 
> --
>
> Key: LUCENENET-463
> URL: https://issues.apache.org/jira/browse/LUCENENET-463
> Project: Lucene.Net
>  Issue Type: New Feature
>  Components: Lucene.Net Contrib
>Reporter: Steven
>Priority: Minor
> Fix For: Lucene.Net 3.0.3
>
>
> This is described in the Java version, but it does not seem to be in the 
> dot.net port, is there a reason for this as I would have imagined lots of 
> people doing document work would want it.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira

[Lucene.Net] [jira] [Updated] (LUCENENET-439) Correctly Rethrow exceptions in C#

2012-01-23 Thread Christopher Currens (Updated) (JIRA)


 [ 
https://issues.apache.org/jira/browse/LUCENENET-439?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Christopher Currens updated LUCENENET-439:
--

Fix Version/s: Lucene.Net 3.0.3

> Correctly Rethrow exceptions in C#
> --
>
> Key: LUCENENET-439
> URL: https://issues.apache.org/jira/browse/LUCENENET-439
> Project: Lucene.Net
>  Issue Type: Sub-task
>  Components: Lucene.Net Core, Lucene.Net Test
>Affects Versions: Lucene.Net 2.9.2, Lucene.Net 2.9.4, Lucene.Net 2.9.4g
> Environment: all
>Reporter: michael herndon
>  Labels: refactoring, testing,
> Fix For: Lucene.Net 3.0.3
>
>
> There are a few places in the tests and possibly in the code where exceptions 
> are being rethrown incorrectly and erasing stacktrace.  
> Please fix these as you come across them and add the ticket number in the 
> commit message. 
> BaseTokenStreamTestCase.cs has a good example of this. Inside the RunBare 
> method:
> // Do the test again with onlyUseNewAPI=true
> try
> {
> onlyUseNewAPI = true;
> base.RunBare();
> }
> catch(Exception ex) 
> {
> System.Console.Out.WriteLine("Test failure of '" + GetType() + "' 
> occurred with onlyUseNewAPI=true");
> throw ex;
> }
> in this case you don't need to specify the exception, and we're trapping to 
> write out the context of the exception problem. 
> try
> {
> onlyUseNewAPI = true;
> base.RunBare();
> }
> catch 
> {
> Type type = this.GetType();
> Console.WriteLine("Test failure of '" + type.Name + "' occurred with 
> onlyUseNewAPI=true");
> throw;
> }
> http://msdn.microsoft.com/en-us/library/ms182363(v=vs.80).aspx
> http://winterdom.com/2002/09/rethrowingexceptionsinc 

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira

[Lucene.Net] [jira] [Updated] (LUCENENET-446) Make Lucene.Net CLS Compliant

2012-01-23 Thread Christopher Currens (Updated) (JIRA)


 [ 
https://issues.apache.org/jira/browse/LUCENENET-446?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Christopher Currens updated LUCENENET-446:
--

Fix Version/s: Lucene.Net 3.0.3

> Make Lucene.Net CLS Compliant
> -
>
> Key: LUCENENET-446
> URL: https://issues.apache.org/jira/browse/LUCENENET-446
> Project: Lucene.Net
>  Issue Type: Task
>  Components: Lucene.Net Core
>Affects Versions: Lucene.Net 2.9.4
>Reporter: Prescott Nasser
> Fix For: Lucene.Net 3.0.3
>
> Attachments: Lucene2.9.4-CLS-partial-fix
>
>
> Make Lucene.Net CLS Compliant

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira

[Lucene.Net] [jira] [Updated] (LUCENENET-460) Missing License Headers in 2.9.4g branch

2012-01-02 Thread Stefan Bodewig (Updated) (JIRA)


 [ 
https://issues.apache.org/jira/browse/LUCENENET-460?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Stefan Bodewig updated LUCENENET-460:
-

Attachment: 2.9.4g.headers.patch

> Missing License Headers in 2.9.4g branch
> 
>
> Key: LUCENENET-460
> URL: https://issues.apache.org/jira/browse/LUCENENET-460
> Project: Lucene.Net
>  Issue Type: Bug
>  Components: ASF Process
>Reporter: Stefan Bodewig
> Fix For: Lucene.Net 2.9.4g
>
> Attachments: 2.9.4g.headers.patch
>
>
> The patch I'm going to attach doesn't cover bin or lib or doc as we don't 
> distribute either.
> The patch looks bigger than necessary as I ran RAT on Linux (sorry, don't 
> have access to a Windows box right now) and many of the affected files don't 
> have the svn:eol-style property set.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira

[Lucene.Net] [jira] [Updated] (LUCENENET-434) Remove AnonymousXXXX classes to increase readablity

2011-12-23 Thread Scott Lombard (Updated) (JIRA)


 [ 
https://issues.apache.org/jira/browse/LUCENENET-434?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Scott Lombard updated LUCENENET-434:


 Priority: Minor  (was: Major)
Affects Version/s: Lucene.Net 3.x
Fix Version/s: (was: Lucene.Net 2.9.4g)
   Lucene.Net 3.x

This does not affect the function of the core it provides better readablity.  
The classes were created as part of the automated porting tool used in the 
orginal conversion.  Removing them is a process that can happen over time.

> Remove Anonymous classes to increase readablity
> ---
>
> Key: LUCENENET-434
> URL: https://issues.apache.org/jira/browse/LUCENENET-434
> Project: Lucene.Net
>  Issue Type: Improvement
>  Components: Lucene.Net Core
>Affects Versions: Lucene.Net 3.x, Lucene.Net 2.9.4g
>Reporter: Scott Lombard
>Assignee: Scott Lombard
>Priority: Minor
> Fix For: Lucene.Net 3.x
>
> Attachments: TeeSinkTokenFilter.patch
>
>   Original Estimate: 168h
>  Time Spent: 13h
>  Remaining Estimate: 155h
>
> Replace Anonymous classes inhereted from JLCA which make the code 
> impossible to read.
> Follow Digy's template to replace the single abstract method with Func<> or 
> Action<>
>  
> like in FilterCache from:
> protected abstract object MergeDeletes(IndexReader reader, object value);
> to:
> Func MergeDeletes;
>  
> Determine a solution to the classes with more than 1 abstract method without 
> diverging much from Java.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira

[Lucene.Net] [jira] [Updated] (LUCENENET-459) Italian stemmer (from SnowballAnalyzer) does not work

2011-12-22 Thread Digy (Updated) (JIRA)


 [ 
https://issues.apache.org/jira/browse/LUCENENET-459?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Digy updated LUCENENET-459:
---

Affects Version/s: Lucene.Net 2.9.4g
Fix Version/s: Lucene.Net 2.9.4g

> Italian stemmer (from SnowballAnalyzer) does not work
> -
>
> Key: LUCENENET-459
> URL: https://issues.apache.org/jira/browse/LUCENENET-459
> Project: Lucene.Net
>  Issue Type: Bug
>  Components: Lucene.Net Contrib
>Affects Versions: Lucene.Net 2.9.2, Lucene.Net 2.9.4, Lucene.Net 2.9.4g
>Reporter: Santiago M. Mola
> Fix For: Lucene.Net 2.9.4g
>
>
> Italian stemmer does not work.
> Consider this code:
>   var englishAnalyzer = new SnowballAnalyzer("English");
>   var tk = englishAnalyzer.TokenStream("text", new 
> StringReader("horses"));
>   var ta = 
> (TermAttribute)tk.GetAttribute(typeof(TermAttribute));
>   tk.IncrementToken();
>   Console.WriteLine("English stemmer: horses -> " + 
> ta.Term());
>   
>   var italianAnalyzer = new SnowballAnalyzer("Italian");
>   tk = italianAnalyzer.TokenStream("text", new 
> StringReader("abbandonata"));
>   ta = 
> (TermAttribute)tk.GetAttribute(typeof(TermAttribute));
>   tk.IncrementToken();
>   Console.WriteLine("Italian stemmer: abbandonata -> " + 
> ta.Term());
> It outputs:
> English stemmer: horses -> hors
> Italian stemmer: abbandonata -> abbandonata
> While Java Lucene 2.9.4 outputs:
> English stemmer: horses -> hors
> Italian stemmer: abbandonata -> abbandon

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira

[Lucene.Net] [jira] [Updated] (LUCENENET-431) Spatial.Net Cartesian won't find docs in radius in certain cases

2011-11-10 Thread Prescott Nasser (Updated) (JIRA)


 [ 
https://issues.apache.org/jira/browse/LUCENENET-431?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Prescott Nasser updated LUCENENET-431:
--

Affects Version/s: Lucene.Net 2.9.4g
Fix Version/s: Lucene.Net 2.9.4

Updating affected builds

> Spatial.Net Cartesian won't find docs in radius in certain cases
> 
>
> Key: LUCENENET-431
> URL: https://issues.apache.org/jira/browse/LUCENENET-431
> Project: Lucene.Net
>  Issue Type: Bug
>  Components: Lucene.Net Contrib
>Affects Versions: Lucene.Net 2.9.4, Lucene.Net 2.9.4g
> Environment: Windows 7 x64
>Reporter: Olle Jacobsen
>Assignee: Prescott Nasser
>  Labels: spatialsearch
> Fix For: Lucene.Net 2.9.4, Lucene.Net 2.9.4g
>
> Attachments: Lucenenet-431-Spatial.Net
>
>
> To replicate change Lucene.Net.Contrib.Spatial.Test.TestCartesian to the 
> following witch should return 3 results.
> Line
> 42: private double _lat = 55.6880508001;
> 43: private double _lng = 13.5871808352; // This passes: 13.6271808352
> 73: AddPoint(writer, "Within radius", 55.6880508001, 13.5717346673);
> 74: AddPoint(writer, "Within radius", 55.6821978456, 13.6076183965);
> 75: AddPoint(writer, "Within radius", 55.673251569, 13.5946697607);
> 76: AddPoint(writer, "Close but not in radius", 55.8634157297, 13.5497731987);
> 77: AddPoint(writer, "Faar away", 40.7137578228, -74.0126901936);
> 130: const double miles = 5.0;
> 156: Console.WriteLine("Distances should be 3 " + distances.Count);
> 157: Console.WriteLine("Results should be 3 " + results);
> 159: Assert.AreEqual(3, distances.Count); // fixed a store of only needed 
> distances
> 160: Assert.AreEqual(3, results);

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira

[Lucene.Net] [jira] [Updated] (LUCENENET-431) Spatial.Net Cartesian won't find docs in radius in certain cases

2011-11-10 Thread Prescott Nasser (Updated) (JIRA)


 [ 
https://issues.apache.org/jira/browse/LUCENENET-431?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Prescott Nasser updated LUCENENET-431:
--

Attachment: Lucenenet-431-Spatial.Net

Patch for the trunk

> Spatial.Net Cartesian won't find docs in radius in certain cases
> 
>
> Key: LUCENENET-431
> URL: https://issues.apache.org/jira/browse/LUCENENET-431
> Project: Lucene.Net
>  Issue Type: Bug
>  Components: Lucene.Net Contrib
>Affects Versions: Lucene.Net 2.9.4
> Environment: Windows 7 x64
>Reporter: Olle Jacobsen
>Assignee: Prescott Nasser
>  Labels: spatialsearch
> Fix For: Lucene.Net 2.9.4g
>
> Attachments: Lucenenet-431-Spatial.Net
>
>
> To replicate change Lucene.Net.Contrib.Spatial.Test.TestCartesian to the 
> following witch should return 3 results.
> Line
> 42: private double _lat = 55.6880508001;
> 43: private double _lng = 13.5871808352; // This passes: 13.6271808352
> 73: AddPoint(writer, "Within radius", 55.6880508001, 13.5717346673);
> 74: AddPoint(writer, "Within radius", 55.6821978456, 13.6076183965);
> 75: AddPoint(writer, "Within radius", 55.673251569, 13.5946697607);
> 76: AddPoint(writer, "Close but not in radius", 55.8634157297, 13.5497731987);
> 77: AddPoint(writer, "Faar away", 40.7137578228, -74.0126901936);
> 130: const double miles = 5.0;
> 156: Console.WriteLine("Distances should be 3 " + distances.Count);
> 157: Console.WriteLine("Results should be 3 " + results);
> 159: Assert.AreEqual(3, distances.Count); // fixed a store of only needed 
> distances
> 160: Assert.AreEqual(3, results);

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira

[Lucene.Net] [jira] [Updated] (LUCENENET-453) Many files need proper svn properties to set the linefeeds

2011-11-03 Thread Stefan Bodewig (Updated) (JIRA)


 [ 
https://issues.apache.org/jira/browse/LUCENENET-453?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Stefan Bodewig updated LUCENENET-453:
-

Attachment: LUCENENET-453.list-of-files-with-missing-svn_eol-style.txt

list of files that need their svn:eol-style property set to native

> Many files need proper svn properties to set the linefeeds
> --
>
> Key: LUCENENET-453
> URL: https://issues.apache.org/jira/browse/LUCENENET-453
> Project: Lucene.Net
>  Issue Type: Bug
>Reporter: Stefan Bodewig
>Priority: Minor
> Attachments: LUCENENET-453.inconsistent-eol.patch, 
> LUCENENET-453.list-of-files-with-missing-svn_eol-style.txt
>
>
> Many files are lacking the svn:eol-style proper which should be set to 
> native, I'll attach a list later.
> Some files have inconsistent linefeeds, I'll attach a patch.
> Some files even have bad mine-types.  You need to run
> svn pd svn:mime-type
> on
> test/contrib/Core/Analysis/Ext/Analysis.Ext.Test.cs
> build.cmd should likely get an svn:eol-style of crlf

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira

[Lucene.Net] [jira] [Updated] (LUCENENET-453) Many files need proper svn properties to set the linefeeds

2011-11-03 Thread Stefan Bodewig (Updated) (JIRA)


 [ 
https://issues.apache.org/jira/browse/LUCENENET-453?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Stefan Bodewig updated LUCENENET-453:
-

Attachment: LUCENENET-453.inconsistent-eol.patch

patch that fixes inconsistent linefeeds

> Many files need proper svn properties to set the linefeeds
> --
>
> Key: LUCENENET-453
> URL: https://issues.apache.org/jira/browse/LUCENENET-453
> Project: Lucene.Net
>  Issue Type: Bug
>Reporter: Stefan Bodewig
>Priority: Minor
> Attachments: LUCENENET-453.inconsistent-eol.patch
>
>
> Many files are lacking the svn:eol-style proper which should be set to 
> native, I'll attach a list later.
> Some files have inconsistent linefeeds, I'll attach a patch.
> Some files even have bad mine-types.  You need to run
> svn pd svn:mime-type
> on
> test/contrib/Core/Analysis/Ext/Analysis.Ext.Test.cs
> build.cmd should likely get an svn:eol-style of crlf

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira

[Lucene.Net] [jira] [Updated] (LUCENENET-451) Missing License Headers in trunk

2011-11-01 Thread Christopher Currens (Updated) (JIRA)


 [ 
https://issues.apache.org/jira/browse/LUCENENET-451?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Christopher Currens updated LUCENENET-451:
--

Attachment: LUCENENET-451.slnfix.trunk.patch

Attached a patch against trunk that moves the license headers in all the 
solution files.

This patch was created on revision 1195735, which already has the 
LUCENENET-451.trunk.patch applied.  I'm not so great with SVN, so I'm sure how 
to merge these into one patch, so any branches will have to run 
LUCENENET-451.trunk.patch first and then LUCENENET-451.slnfix.trunk.patch.

> Missing License Headers in trunk
> 
>
> Key: LUCENENET-451
> URL: https://issues.apache.org/jira/browse/LUCENENET-451
> Project: Lucene.Net
>  Issue Type: Bug
>Reporter: Stefan Bodewig
>Assignee: Christopher Currens
> Fix For: Lucene.Net 2.9.4
>
> Attachments: LUCENENET-451.slnfix.trunk.patch, 
> LUCENENET-451.trunk.patch
>
>
> Many files lack the ASF license headers, I'll attach a patch against trunk 
> shortly.
> I can provide patches against branches as well if this seems easier than 
> merging from trunk.
> So far I have deliberately skipped the docs and lib directories as docs seems 
> to contain generated files only and the lib folder is something that needs to 
> be talked about separately anyway.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira

[Lucene.Net] [jira] [Updated] (LUCENENET-448) GeoHashFilteredDocIdSet does not work at all

2011-11-01 Thread Digy (Updated) (JIRA)


 [ 
https://issues.apache.org/jira/browse/LUCENENET-448?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Digy updated LUCENENET-448:
---

Affects Version/s: (was: Lucene.Net 2.9.4)
   Lucene.Net 2.9.4g
Fix Version/s: (was: Lucene.Net 2.9.4)
   Lucene.Net 2.9.4g

> GeoHashFilteredDocIdSet does not work at all
> 
>
> Key: LUCENENET-448
> URL: https://issues.apache.org/jira/browse/LUCENENET-448
> Project: Lucene.Net
>  Issue Type: Bug
>  Components: Lucene.Net Contrib
>Affects Versions: Lucene.Net 2.9.4g
> Environment: Windows 7 x64
>Reporter: Jeff Johnson
>  Labels: contrib, spatial
> Fix For: Lucene.Net 2.9.4g
>
>   Original Estimate: 1h
>  Remaining Estimate: 1h
>
> The GeoHashFilteredDocIdSet is assuming the values are always in the cache 
> which is wrong. A proposed fix for the method is listed here for 
> GeoHashDistanceFilter.cs:
> public GeoHashFilteredDocIdSet(DocIdSet innerSet, string[] geoHashValues, 
> Dictionary distanceLookupCache, double lat, double lng, int 
> docBase, double distance, Dictionary distances) 
> : base(innerSet , (docid) => /* was: public override Match */
>   {
>   String geoHash = geoHashValues[docid];
>   double[] coords = GeoHashUtils.Decode(geoHash);
>   double x = coords[0];
>   double y = coords[1];
>   double cachedDistance;
> distanceLookupCache.TryGetValue(geoHash, out cachedDistance);
>   double d;
>   if (cachedDistance > 0)
>   {
>   d = cachedDistance;
>   }
>   else
>   {
>   d = 
> DistanceUtils.GetInstance().GetDistanceMi(lat, lng, x, y);
>   distanceLookupCache[geoHash] = d;
>   }
>   if (d < distance)
>   {
>   distances[docid + docBase] = d;
>   return true;
>   }
>   
>   return false;
>   })
>   {
>   _geoHashValues = geoHashValues;
>   _distances = distances;
>   _distance = distance;
>   _docBase = docBase;
>   _lng = lng;
>   _lat = lat;
>   _distanceLookupCache = distanceLookupCache;
>   }

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira

[Lucene.Net] [jira] [Updated] (LUCENENET-452) Add docs to release

2011-10-31 Thread michael herndon (Updated) (JIRA)


 [ 
https://issues.apache.org/jira/browse/LUCENENET-452?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

michael herndon updated LUCENENET-452:
--

Attachment: lucene.net.xml.zip

xml & nupkg files. 

> Add docs to release
> ---
>
> Key: LUCENENET-452
> URL: https://issues.apache.org/jira/browse/LUCENENET-452
> Project: Lucene.Net
>  Issue Type: Task
>  Components: ASF Process
>Affects Versions: Lucene.Net 2.9.4
>Reporter: michael herndon
>Assignee: Prescott Nasser
>  Labels: docuentation, process, release
> Fix For: Lucene.Net 2.9.4
>
> Attachments: lucene.net.xml.zip
>
>
> Here are the generated chm & website files for the site. 
> https://svn.apache.org/repos/asf/incubator/lucene.net/site/docs/2.9.4
> The docs were too big to save as a zip attachment, jira has a 10 mb limit. 
> the xml files and nupkg will be attached as a zip file. 
> The .nupkg function as zip files. This is in case the packages were not made 
> when the binaries were. Use the official release binaries to replace the ones 
> in the packages, zip, rename to nupkg. You can also use the package GUI for 
> nuget.  

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira

[Lucene.Net] [jira] [Updated] (LUCENENET-452) Add docs to release

2011-10-31 Thread michael herndon (Updated) (JIRA)


 [ 
https://issues.apache.org/jira/browse/LUCENENET-452?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

michael herndon updated LUCENENET-452:
--

Description: 
Here are the generated chm & website files for the site. 
https://svn.apache.org/repos/asf/incubator/lucene.net/site/docs/2.9.4

The docs were too big to save as a zip attachment, jira has a 10 mb limit. 

the xml files and nupkg will be attached as a zip file. 

The .nupkg function as zip files. This is in case the packages were not made 
when the binaries were. Use the official release binaries to replace the ones 
in the packages, zip, rename to nupkg. You can also use the package GUI for 
nuget.  

  was:
Here are the generated xml files, chm & website files for the site. 

These also include the nuget packages since, the .nupkg are zip files. This is 
in case the packages were not made when the binaries were. Use the official 
release binaries to replace the ones in the packages, zip, rename to nupkg. You 
can also use the package Gui.  


> Add docs to release
> ---
>
> Key: LUCENENET-452
> URL: https://issues.apache.org/jira/browse/LUCENENET-452
> Project: Lucene.Net
>  Issue Type: Task
>  Components: ASF Process
>Affects Versions: Lucene.Net 2.9.4
>Reporter: michael herndon
>Assignee: Prescott Nasser
>  Labels: docuentation, process, release
> Fix For: Lucene.Net 2.9.4
>
>
> Here are the generated chm & website files for the site. 
> https://svn.apache.org/repos/asf/incubator/lucene.net/site/docs/2.9.4
> The docs were too big to save as a zip attachment, jira has a 10 mb limit. 
> the xml files and nupkg will be attached as a zip file. 
> The .nupkg function as zip files. This is in case the packages were not made 
> when the binaries were. Use the official release binaries to replace the ones 
> in the packages, zip, rename to nupkg. You can also use the package GUI for 
> nuget.  

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira

[Lucene.Net] [jira] [Updated] (LUCENENET-451) Missing License Headers in trunk

2011-10-31 Thread Stefan Bodewig (Updated) (JIRA)


 [ 
https://issues.apache.org/jira/browse/LUCENENET-451?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Stefan Bodewig updated LUCENENET-451:
-

Attachment: LUCENENET-451.trunk.patch

Patch that adds ASF license to files that lack them.

The only files flagged by RAT outside of doc and lib after applying this patch 
are plain text files or generated.

> Missing License Headers in trunk
> 
>
> Key: LUCENENET-451
> URL: https://issues.apache.org/jira/browse/LUCENENET-451
> Project: Lucene.Net
>  Issue Type: Bug
>Reporter: Stefan Bodewig
> Attachments: LUCENENET-451.trunk.patch
>
>
> Many files lack the ASF license headers, I'll attach a patch against trunk 
> shortly.
> I can provide patches against branches as well if this seems easier than 
> merging from trunk.
> So far I have deliberately skipped the docs and lib directories as docs seems 
> to contain generated files only and the lib folder is something that needs to 
> be talked about separately anyway.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira

[Lucene.Net] [jira] [Updated] (LUCENENET-451) Missing License Headers in trunk

2011-10-31 Thread Stefan Bodewig (Updated) (JIRA)


 [ 
https://issues.apache.org/jira/browse/LUCENENET-451?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Stefan Bodewig updated LUCENENET-451:
-

Attachment: (was: LUCENENET-451.trunk.patch)

> Missing License Headers in trunk
> 
>
> Key: LUCENENET-451
> URL: https://issues.apache.org/jira/browse/LUCENENET-451
> Project: Lucene.Net
>  Issue Type: Bug
>Reporter: Stefan Bodewig
>
> Many files lack the ASF license headers, I'll attach a patch against trunk 
> shortly.
> I can provide patches against branches as well if this seems easier than 
> merging from trunk.
> So far I have deliberately skipped the docs and lib directories as docs seems 
> to contain generated files only and the lib folder is something that needs to 
> be talked about separately anyway.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira

[Lucene.Net] [jira] [Updated] (LUCENENET-451) Missing License Headers in trunk

2011-10-30 Thread Stefan Bodewig (Updated) (JIRA)


 [ 
https://issues.apache.org/jira/browse/LUCENENET-451?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Stefan Bodewig updated LUCENENET-451:
-

Attachment: LUCENENET-451.trunk.patch

Patch against trunk that adds licenses to most files that lack them.

Some patches look bigger than expected as I created them on Linux and many 
files lack the svn:eol-style Subversion property.

> Missing License Headers in trunk
> 
>
> Key: LUCENENET-451
> URL: https://issues.apache.org/jira/browse/LUCENENET-451
> Project: Lucene.Net
>  Issue Type: Bug
>Reporter: Stefan Bodewig
> Attachments: LUCENENET-451.trunk.patch
>
>
> Many files lack the ASF license headers, I'll attach a patch against trunk 
> shortly.
> I can provide patches against branches as well if this seems easier than 
> merging from trunk.
> So far I have deliberately skipped the docs and lib directories as docs seems 
> to contain generated files only and the lib folder is something that needs to 
> be talked about separately anyway.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira

[Lucene.Net] [jira] [Updated] (LUCENENET-450) Incorrect use of StreamReader in MoreLikeThis

2011-10-30 Thread Prescott Nasser (Updated) (JIRA)


 [ 
https://issues.apache.org/jira/browse/LUCENENET-450?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Prescott Nasser updated LUCENENET-450:
--

Affects Version/s: (was: Lucene.Net 2.9.4g)
Fix Version/s: (was: Lucene.Net 2.9.4g)

Similarity isn't in 2.9.4g

> Incorrect use of StreamReader in MoreLikeThis
> -
>
> Key: LUCENENET-450
> URL: https://issues.apache.org/jira/browse/LUCENENET-450
> Project: Lucene.Net
>  Issue Type: Bug
>  Components: Lucene.Net Contrib
>Affects Versions: Lucene.Net 2.9.2, Lucene.Net 2.9.4, Lucene.Net 3.x
>Reporter: Itamar Syn-Hershko
>Assignee: Prescott Nasser
> Fix For: Lucene.Net 2.9.4
>
> Attachments: Lucenenet-450.patch
>
>
> In the MoreLike this implementation (looking at the trunk), line 772 
> incorrectly creates a new StreamReader instead of using StringReader. This 
> causes the following exception to be thrown, since the ctor expects a file 
> path and not an input string:
> System.ArgumentException: Illegal characters in path.
>at 
> System.Security.Permissions.FileIOPermission.HasIllegalCharacters(String[] 
> str)
>at 
> System.Security.Permissions.FileIOPermission.AddPathList(FileIOPermissionAccess
>  access, AccessControlActions control, String[] pathListOrig, Boolean 
> checkForDuplicates, Boolean needFullPath, Boolean copyPathList)
>at 
> System.Security.Permissions.FileIOPermission..ctor(FileIOPermissionAccess 
> access, AccessControlActions control, String[] pathList, Boolean 
> checkForDuplicates, Boolean needFullPath)
>at System.IO.FileStream.Init(String path, FileMode mode, FileAccess 
> access, Int32 rights, Boolean useRights, FileShare share, Int32 bufferSize, 
> FileOptions options, SECURITY_ATTRIBUTES secAttrs, String msgPath, Boolean 
> bFromProxy, Boolean useLongPath)
>at System.IO.FileStream..ctor(String path, FileMode mode, FileAccess 
> access, FileShare share, Int32 bufferSize, FileOptions options, String 
> msgPath, Boolean bFromProxy)
>at System.IO.FileStream..ctor(String path, FileMode mode, FileAccess 
> access, FileShare share, Int32 bufferSize, FileOptions options)
>at System.IO.StreamReader..ctor(String path, Encoding encoding, Boolean 
> detectEncodingFromByteOrderMarks, Int32 bufferSize)
>at System.IO.StreamReader..ctor(String path, Boolean 
> detectEncodingFromByteOrderMarks)
>at Similarity.Net.MoreLikeThis.RetrieveTerms(Int32 docNum) in 
> MoreLikeThis.cs:line 773
>at Similarity.Net.MoreLikeThis.Like(Int32 docNum) in MoreLikeThis.cs:line 
> 507
> Simply replacing StreamReader with StringReader will do the job

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira

[Lucene.Net] [jira] [Updated] (LUCENENET-450) Incorrect use of StreamReader in MoreLikeThis

2011-10-30 Thread Prescott Nasser (Updated) (JIRA)


 [ 
https://issues.apache.org/jira/browse/LUCENENET-450?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Prescott Nasser updated LUCENENET-450:
--

Attachment: Lucenenet-450.patch

Attached patch; also merged to the trunk

> Incorrect use of StreamReader in MoreLikeThis
> -
>
> Key: LUCENENET-450
> URL: https://issues.apache.org/jira/browse/LUCENENET-450
> Project: Lucene.Net
>  Issue Type: Bug
>  Components: Lucene.Net Contrib
>Affects Versions: Lucene.Net 2.9.2, Lucene.Net 2.9.4, Lucene.Net 3.x, 
> Lucene.Net 2.9.4g
>Reporter: Itamar Syn-Hershko
> Attachments: Lucenenet-450.patch
>
>
> In the MoreLike this implementation (looking at the trunk), line 772 
> incorrectly creates a new StreamReader instead of using StringReader. This 
> causes the following exception to be thrown, since the ctor expects a file 
> path and not an input string:
> System.ArgumentException: Illegal characters in path.
>at 
> System.Security.Permissions.FileIOPermission.HasIllegalCharacters(String[] 
> str)
>at 
> System.Security.Permissions.FileIOPermission.AddPathList(FileIOPermissionAccess
>  access, AccessControlActions control, String[] pathListOrig, Boolean 
> checkForDuplicates, Boolean needFullPath, Boolean copyPathList)
>at 
> System.Security.Permissions.FileIOPermission..ctor(FileIOPermissionAccess 
> access, AccessControlActions control, String[] pathList, Boolean 
> checkForDuplicates, Boolean needFullPath)
>at System.IO.FileStream.Init(String path, FileMode mode, FileAccess 
> access, Int32 rights, Boolean useRights, FileShare share, Int32 bufferSize, 
> FileOptions options, SECURITY_ATTRIBUTES secAttrs, String msgPath, Boolean 
> bFromProxy, Boolean useLongPath)
>at System.IO.FileStream..ctor(String path, FileMode mode, FileAccess 
> access, FileShare share, Int32 bufferSize, FileOptions options, String 
> msgPath, Boolean bFromProxy)
>at System.IO.FileStream..ctor(String path, FileMode mode, FileAccess 
> access, FileShare share, Int32 bufferSize, FileOptions options)
>at System.IO.StreamReader..ctor(String path, Encoding encoding, Boolean 
> detectEncodingFromByteOrderMarks, Int32 bufferSize)
>at System.IO.StreamReader..ctor(String path, Boolean 
> detectEncodingFromByteOrderMarks)
>at Similarity.Net.MoreLikeThis.RetrieveTerms(Int32 docNum) in 
> MoreLikeThis.cs:line 773
>at Similarity.Net.MoreLikeThis.Like(Int32 docNum) in MoreLikeThis.cs:line 
> 507
> Simply replacing StreamReader with StringReader will do the job

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira

[Lucene.Net] [jira] [Updated] (LUCENENET-446) Make Lucene.Net CLS Compliant

2011-10-01 Thread Prescott Nasser (Updated) (JIRA)


 [ 
https://issues.apache.org/jira/browse/LUCENENET-446?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Prescott Nasser updated LUCENENET-446:
--

Attachment: Lucene2.9.4-CLS-partial-fix

This is a partial fix (it will allow Lucene to build, but there are infinite 
loops) - however, it has horrible conseqenses and should not be used.

Here's the jist of what's been done in this patch:
- uint (UInt32) -> Int64 (long)
- sbyte -> Int16 (short)
There are a few sbyte values left, but it's relating to the FieldCacheImpl and 
used as a key in the dictionary (as a string value) so this should be fine

- Const fields cannot have _ as first character, removed _ and appended 
internal or protected to the name if neccessary

- Volatile, is CLS complaint, but mostly only non CLS Compliant fields can be 
marked as volatile (exception int). Most fields were uint and sbyte, so those 
were
changed to the .net cls compliant version, and locks were put in where more 
than a single read or write to these variables was occuring

- Differing only in case is not CLS Compliant. I appended internal (or 
protected if the field was not marked as internal) to field definitions

Issues:
- ulong (UInt64) -> decimal, Lucene.Net.QueryParsers.QueryParserTokenManager 
didn't like a lot of the Decimal conversions, so I didn't make the ulong -> 
decimal type change.
Oddly, there are no CLS compliance warnings from the ulongs here.

- Lucene.Net.QueryParsers.QueryParser.Term - differing only in case - but 
couldn't find the other term with different case
- Lucene.Net.Search.TopDocs.scoreDocs and ScoreDocs - I could not adjust these, 
without changing the public interface for Luncene.Net
- Lucene.Net.Search.TopDocs.totalHits and TotalHits - same issue as ScoreDoc
- Lucene.Net.Search.Similarity idfExplain() and IdfExplain - same issue as 
ScoreDoc


> Make Lucene.Net CLS Compliant
> -
>
> Key: LUCENENET-446
> URL: https://issues.apache.org/jira/browse/LUCENENET-446
> Project: Lucene.Net
>  Issue Type: Task
>  Components: Lucene.Net Core
>Affects Versions: Lucene.Net 2.9.4
>Reporter: Prescott Nasser
> Attachments: Lucene2.9.4-CLS-partial-fix
>
>
> Make Lucene.Net CLS Compliant

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira

40 matches

Mail list logo