Lucene.NET 3.0.3 Release Date

[Christopher Currens]

All,

I've been thinking about the future of Lucene.NET lately, and where I want
it to be by the end of the year.  So far, we've had a decent year, with two
releases, both the 2.9.4 and 2.9.4g branch, and I want to keep this release
streak going.  So, how are we doing on version 3.0.3?

Surprisingly well.  The changes to core were actually finished before the
new year, in last December.  What has been done the past three months has
been work on various Contrib libraries and making the API act a little bit
more like a .NET library should.  I think that the Contrib libraries are in
good shape, thanks to everyone that's had a hand in bug fixes and porting
the new versions.  There is one Contrib library that I feel we absolutely
cannot release without, and that is Highlighter.  It is a popular library
in the Java version, and I imagine that also goes for .NET, though there
isn't much talk about it on the one issue we have regarding porting it.
 I'm going to work on finishing porting it today, however, it is blocked
by LUCENENET-481, which will also need to be taken care of.

The only other major thing that needs to be finalized, are the sub-tasks
for LUCENENET-467, particularly the one related to changing Get and Set
methods to .NET Properties.  There has been a lot of work done on this
already, and I think it's just about completed, save for a few things that
need to be verified.  Some properties *may* need to be converted back to
properties.  I was a little gung-ho with some of the property changes,
thanks to Resharper, and there are sometimes overloads of a property that
don't act at all like data.  This will have to be fixed somehow, either by
changing the property back to separate methods or changing the API a little
bit to afford certain classes the ability to have a property, where others
shouldn't.

All of this being said, I feel we are *very* close to a release of
Lucene.NET 3.0.3.  My goal, and I hope others will agree with me, is that
we will have release 3.0.3 NO LATER THAN the end of this month, April 30th.
 I think this is a very reasonable goal, in fact, I think it's possible we
could even release it far before this.  However, the process can sometimes
be slow, so I feel giving us a maximum of a month to complete it should
suffice.

I am in the rare position of having the rest of the week pretty much 100%
available to work on the project, so I will be able to get a lot done from
now until the weekend.  Since I can probably spend more time than others
who are more busy, I'm expecting to get through a lot of different
projects.  Anyone who is working on a part of Lucene, whether it's a
particular issue, a Contrib project or anything else, let me know if you
can commit to having it done within a week or two or if you'd like to just
commit what you already have and pass it on to me or someone else.  I'll
leave a reasonable amount of time before I just start going on things I
haven't already worked on to give everyone an opportunity to respond
regarding these things we've been working on.

I'd like to hear everyone else's thoughts on being able to release by the
end of the month (honestly, my goal is to have it ready for a release by
the end of the week/beginning of next week, but that might be overly
optimistic).


Thanks,
Christopher

Re: [Lucene.Net] 2.9.4g binary

[Christopher Currens]

Andy,

I'll take a look at that today.  I actually don't know how to make the
changes, but fortunately it's all documented somewhere, and I think I can
probably figure it out.  However, the RC1 label was just accidentally left
in there.  It *is* the official release that was voted in, we just
neglected to remove the RC status from the name.


Thanks,
Christopher

On Wed, Apr 4, 2012 at 8:52 AM, Andy Pook  wrote:

> The official downloads page for 2.9.4g still seems to be for the RC1.
> As there seems to be a push to get 3.0.3 released (yay!) it'd be good to
> get these little details sewn up.
>
> Cheers
>
> On 27 February 2012 17:26, Simone Chiaretta  >wrote:
>
> > The Nuget pkg is still missing. Currently I'm at the MVP Summit in
> > Bellevue. I'll do the release when I go back home after the 11 of March
> > (doing a week of holiday after the summit).
> >
> > Simone
> >
> > On Mon, Feb 27, 2012 at 8:52 AM, Prescott Nasser  > >wrote:
> >
> > > I cant check them out at the moment, but what is in dist is the
> release.
> > I
> > > will check out the tag tonight
> > >
> > > Sent from my Windows Phone
> > > 
> > > From: Andy Pook
> > > Sent: 2/27/2012 5:09 AM
> > > To: lucene-net-...@incubator.apache.org
> > > Subject: [Lucene.Net] 2.9.4g binary
> > >
> > > So, 2.9.4g was voted as released a while ago. However, the build
> > artifacts
> > > listed when you follow the links on the web site lead you to
> > >
> >
> http://www.apache.org/dist/incubator/lucene.net/binaries/2.9.4g-incubating/
> > >  which
> > > all have an "-RC1" tag in the filename but seem to have a timestamp
> from
> > > about the right time.
> > >
> > > I can build it myself from source but I was hoping to start using the
> > > "official" binary.
> > >
> > > Can someone let us know what the status of these are?
> > >
> > > Thanks
> > >  Andy
> > >
> >
> >
> >
> > --
> > Simone Chiaretta
> > Microsoft MVP ASP.NET - ASPInsider
> > Blog: http://codeclimber.net.nz
> > RSS: http://feeds2.feedburner.com/codeclimber
> > twitter: @simonech
> >
> > Any sufficiently advanced technology is indistinguishable from magic
> > "Life is short, play hard"
> >
>

Re: 3.0.3 Tests

[Christopher Currens]

So the tests that intermittently fail, at least the ones I can find (it's
so rare they fail), are the following:

In Lucene.Net.Index:
-- TestConcurrentMergeScheduler.TestFlushExceptions

In Lucene.Net.Store:
-- TestLockFactory.TestStressLocks

In Lucene.Net.Search:
-- TestSort.TestParallelMultiSort

In Lucene.Net.Util:
-- TestFieldCacheSanityChecker.TestInsanity1
-- TestFieldCacheSanityChecker.TestInsanity2
-- (It's possible all of the insanity tests fail at one point or another)

In Lucene.Net.Support
-- TestWeakHashTableMultiThreadAccess.Test (This one doesn't actually
matter, we can remove this from the solution, we don't use the
WeakHashTable anymore in lucene.)


These should be looked into.


Thanks,
Christopher

On Tue, Apr 10, 2012 at 6:22 PM, Christopher Currens <
currens.ch...@gmail.com> wrote:

> So for a long time, we've gotten failed tests on some of the insanity
> tests in  TestFieldCacheSanityChecker.  We've also gotten them in TestSort,
> for parallel sorting and one other I can't remember off the top of my head.
>  They fail in Release and almost never in debug, since it's more likely for
> race conditions to happen.
>
> They *really* should look at them instead of just ignoring them.  I'll
> look and find the ones I've seen fail often and file an issue for them.
>
>
> Thanks,
> Christopher
>
>
> On Tue, Apr 10, 2012 at 6:01 PM, Prescott Nasser wrote:
>
>>
>>
>>
>>
>> I ran the full suite of tests against core with the following results.
>> Can anyone confirm they are seeing similar? or is this particular to my
>> system? I failed test, 3 ignored, looks like two where intential ignores
>> and I can't tell about the first one. Should we remove the intentially
>> ignored tests? Is there a point to keeping the clutter? Also, are there
>> missing tests ports that we are aware of that I can take a look at porting?
>>  (1315 tests), 1 test failed
>>  Lucene.Net.Index (369 tests), Success
>>TestIndexWriterReader (16 tests), Success
>>  TestDuringAddIndexes, Ignored
>>  Lucene.Net.Store (29 tests), Success
>>TestMultiMMap (1 test), Ignored
>>  TestDoesntExist, Ignored: Need to port tests, but we don't really
>> support MMapDirectories anyway
>>  Lucene.Net.Support (62 tests), Success
>>_SupportClassTestCases (1 test), Ignored
>>  Count, Ignored: [Intentionally ignored test case] Lucene.Net
>> TestCases:0 Other TestCases:1311
>>  Lucene.Net.Util (68 tests), 1 test failed
>>ArrayUtilTest (1 test), Success
>>TestAttributeSource (5 tests), Success
>>TestBitVector (7 tests), Success
>>TestCloseableThreadLocal (3 tests), Success
>>TestFieldCacheSanityChecker (4 tests), 1 test failed: Child test failed
>>  TestInsanity1, Success
>>  TestInsanity2, Failed:  wrong number of cache errors Expected: 1 But
>> was: 0
>>  TestInsanity3, Success
>>  TestSanity, Success
>>
>
>
>

Re: Buggy FrenchStemmer in trunk

[Christopher Currens]

Thanks, Sylvain, for the patch.

You can create issues at our issue tracker for Lucene.Net.
https://issues.apache.org/jira/browse/LUCENENET

You have a to create an account first to do it, but I've added your issue
here:  https://issues.apache.org/jira/browse/LUCENENET-485 and assigned it
to the 3.0.3 release.  If you decide to create an account, you can watch
the issue's progress, and I can assign you as the reporter, instead of me.


Thanks,
Christopher

On Sun, Apr 15, 2012 at 1:42 AM, Sylvain Rouillard wrote:

> 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

Re: Wildcard queries are not analyzed

[Christopher Currens]

Thanks Björn.

So I've compared the code with the java equivalent, and the result from
java, via running the analyzer in the QueryParser:

Field:björ*

So, it seems to have the same behavior in Java as well.  I want to see if
this is a known issue or expected behavior in java, and go from there.  If
it is, can anyone think of any unexpected side effects to fixing this, so
"björ*" becomes "bjor*"?


Thanks,
Christopher


2012/4/17 Björn Kremer 

> Hello,
>
>
> maybe I have found a little lucene problem: Wildcard queries are not
> analyzed correctly. I'm using the german analyzer with the
> 'GermanDIN2Stemmer'.
>
> In the lucene-index my name('Björn') is stored as 'bjorn'. If I performe a
> wildcard query like 'björ*' the function 'GetPrefixQuery' does not analyze
> the search term. So the query result is 'björ*' instead of 'bjor*'. (björ*
> = no match, bjor* = match)
>
>
> Thank You
> Björn
>
>

Re: Wildcard queries are not analyzed

[Christopher Currens]

I should also add, that directly reading the token stream, will produce
"bjor" (no wildcard) from "björ*".

Björn,

It would be great to see some example code that you're using to reproduce
this behavior, just to make sure we're testing it in the same way.  Also,
could I persuade you to create an issue for this here:
https://issues.apache.org/jira/browse/LUCENENET, so that we can keep track
of the progress on it?

Thanks,
Christopher

On Tue, Apr 17, 2012 at 11:34 AM, Christopher Currens <
currens.ch...@gmail.com> wrote:

> Thanks Björn.
>
> So I've compared the code with the java equivalent, and the result from
> java, via running the analyzer in the QueryParser:
>
> Field:björ*
>
> So, it seems to have the same behavior in Java as well.  I want to see if
> this is a known issue or expected behavior in java, and go from there.  If
> it is, can anyone think of any unexpected side effects to fixing this, so
> "björ*" becomes "bjor*"?
>
>
> Thanks,
> Christopher
>
>
> 2012/4/17 Björn Kremer 
>
>> Hello,
>>
>>
>> maybe I have found a little lucene problem: Wildcard queries are not
>> analyzed correctly. I'm using the german analyzer with the
>> 'GermanDIN2Stemmer'.
>>
>> In the lucene-index my name('Björn') is stored as 'bjorn'. If I performe
>> a wildcard query like 'björ*' the function 'GetPrefixQuery' does not
>> analyze the search term. So the query result is 'björ*' instead of 'bjor*'.
>> (björ* = no match, bjor* = match)
>>
>>
>> Thank You
>> Björn
>>
>>
>

Re: cms

[Christopher Currens]

I fixed it, then broke something else, then fixed that.  It was a fun
cycle.  Apparently, a new version of CMS is a little more strict than it
used to be with markdown, or a bug, idrk.  If you have markdown inside of
any html, it treats it as plain text (this is normal).  For some reason, it
used to treat it as markdown still, within certain html tags (in this case,
).

I just moved the div tag to the template.html file, and removed them from
the markdown pages.

On Mon, Apr 23, 2012 at 1:37 PM, Christopher Currens <
currens.ch...@gmail.com> wrote:

> I'll take a look at it.
>
>
> On Mon, Apr 23, 2012 at 1:28 PM, Prescott Nasser wrote:
>
>>
>>
>>
>>
>> If anyone is familiar with the CMS, something happened to the download
>> page (formatting is screwed up), but it's exactly like the other pages. I
>> could use another pair of eyes on it. ~P
>>
>
>
>

Re: Spatial contrib bug fixing

[Christopher Currens]

Robert Chapman ported Spatial to Lucene.NET, shown here in this issue:
https://issues.apache.org/jira/browse/LUCENENET-199.  DIGY only committed
the patch, and the only thing I've seen Prescott do was to
modify/apply LUCENENET-431 to trunk from 2.9.4g.  Spatial, along with the
rest of Contrib, was barely touched since Lucene.NET was resurrected into
the incubator.  Most, if not all, of the code is the exact same as the
patch contributed by Robert, which itself differed a decent amount from the
java code, so much of the reasons why it wasn't an exact port are either
lost, or the more likely case, never answered.

As far as I'm concerned, I have no qualms with you rewriting the thing from
scratch, if you wanted to pursue a more direct port from the java code.
 Aside from the original port which had many divergences from java, the
only other issue applied to spatial is LUCENENET-431, which would be easy
to include.


Thanks,
Christopher

On Tue, Apr 24, 2012 at 10:31 AM, Itamar Syn-Hershko wrote:

> Uhm.. I was referring to the .NET port, which I can see DIGY ported
>
> Nevermind I will get it from the original commit
>
> @Prescott any idea re " CartesianPolyFilterBuilder.GetBoxShape() is not an
> exact port - do you remember why? "?
>
> On Tue, Apr 24, 2012 at 12:26 AM, Christopher Currens <
> currens.ch...@gmail.com> wrote:
>
> > It's in a weird place.  And for the 3.0.3 version, its easiest to find
> the
> > code in the tags, rather than branches.
> >
> >
> >
> http://svn.apache.org/viewvc/lucene/java/tags/lucene_3_0_3/contrib/misc/src/java/org/apache/lucene/misc/
> >
> >
> > On Mon, Apr 23, 2012 at 2:20 PM, Prescott Nasser  > >wrote:
> >
> > >
> > > I'm having trouble finding chained filter in the java lucene svn...
> > >
> >
> http://svn.apache.org/viewvc/lucene/dev/branches/branch_3x/lucene/contrib/?pathrev=990167amIlooking
>  around in the wrong place?
> > >  > Date: Mon, 23 Apr 2012 11:19:51 +0300
> > > > Subject: Re: Spatial contrib bug fixing
> > > > From: ita...@code972.com
> > > > To: lucene-net-...@lucene.apache.org
> > > >
> > > > One more thing - what's the deal with ChainedFilter? I can see a
> commit
> > > by
> > > > DIGY on 7/7/2011 but it seems to have been removed since?
> > > >
> > > > On Mon, Apr 23, 2012 at 11:06 AM, Itamar Syn-Hershko <
> > ita...@code972.com
> > > >wrote:
> > > >
> > > > > For starters - CartesianPolyFilterBuilder.GetBoxShape() is not an
> > exact
> > > > > port - do you remember why?
> > > > >
> > > > > Anyway, if it was never fully ported as you say maybe I'll just go
> > > ahead
> > > > > and complete that
> > > > >
> > > > > For your reference, here are 2 failing tests which pass in Java
> > Lucene
> > > > > (can send the java file) -
> > > > >
> > >
> >
> https://github.com/synhershko/lucene.net/commit/234da7eca7cb08be5a0c2a7375ffc3f4a03bfd92
> > > > >
> > > > >
> > > > >
> > > > > On Mon, Apr 23, 2012 at 1:39 AM, Prescott Nasser <
> > > geobmx...@hotmail.com>wrote:
> > > > >
> > > > >>
> > > > >> I think that was a while ago, and I don't even recall if I fully
> > > ported
> > > > >> it or just put up the start. I had some other stuff to deal with
> the
> > > last
> > > > >> few months, so my memory is a bit lacking. I'll review the code,
> > > meanwhile
> > > > >> ask whatever questions you have - lets get this fixed up. ~P
> > > > >>  > Date: Sun, 22 Apr 2012 22:10:27 +0300
> > > > >> > Subject: Spatial contrib bug fixing
> > > > >> > From: ita...@code972.com
> > > > >> > To: lucene-net-...@lucene.apache.org
> > > > >> >
> > > > >> > Hi all,
> > > > >> >
> > > > >> > We encountered several bugs with the Sparial contrb, and the
> ones
> > we
> > > > >> tested
> > > > >> > with Java Lucene worked there (with 2.9.4). There are about 3
> open
> > > > >> tickets
> > > > >> > in the Jira bug tracker on similar issues.
> > > > >> >
> > > > >> > I'm now sitting with the ultimate goal of fixing this once and
> for
> > > all,
> > > > >> but
> > > > >> > some code parts are commented out in favor of other not
> > line-by-line
> > > > >> port
> > > > >> > of some implementations, without a comment giving reasons. I was
> > > > >> wondering
> > > > >> > if there's anyone who could answer a few questions there,
> instead
> > > of me
> > > > >> > changing things back and forth?
> > > > >> >
> > > > >> > Git history (I use the Git mirror, yes) tells me Prescott Nasser
> > is
> > > > >> behind
> > > > >> > porting this - maybe he will have the answers?
> > > > >> >
> > > > >> > Cheers,
> > > > >> >
> > > > >> > Itamar.
> > > > >>
> > > > >>
> > > > >
> > > > >
> > >
> > >
> >
>

Re: Spatial contrib bug fixing

[Christopher Currens]

Before we start, I almost forgot, we need to make sure that it can actually
be ported into the project, according to ASF guidelines.  I *think* it
should be okay, because it's licensed under the Apache 2.0 license, but we
should get some feedback from our mentors, on whether this is okay.

Stefan, are there any problems with porting code from a non-apache project
that is licensed under the Apache 2.0 license?

On Tue, Apr 24, 2012 at 2:14 PM, Itamar Syn-Hershko wrote:

> Great
>
> The actual library lives outside of Lucene (
> https://github.com/spatial4j/spatial4j ) and only some integration classes
> are within the Lucene project itself. I linked to the (long) discussions
> about this in my previous message. I will be following that approach with
> this port, and really hope there will be no API differences I won't be able
> to overcome.
>
> I'm going to start doing this sometime tomorrow, but my main efforts will
> be on Thursday. I can certainly use any help in dividing work etc - please
> anyone who can join on Thursday for live collaboration or later chip in the
> discussion.
>
> I'll keep you posted.
>
> On Wed, Apr 25, 2012 at 12:00 AM, Christopher Currens <
> currens.ch...@gmail.com> wrote:
>
> > Yes, the contrib is a MESS.  I've been favoring complete
> re-implementations
> > over porting changes, since contrib has been in such a poor, overlooked
> > state for so long.
> >
> > I'm not opposed to porting LSP over the Spatial contrib project in Java,
> > though it will might some porting challenges both now, since Lucene
> > versions are different, and as Lucene.NET evolves.  It also might not,
> I'm
> > not familiar with the LSP code.  Contrib is just that, contributed
> software
> > that is not part of the core library, and there will be projects in Java
> we
> > can't port over.  In fact, I think there are .NET specific contrib
> projects
> > that aren't in java.  Either way, my point is that I'm am happy and
> willing
> > to have LSP included if that's going to wind up being better than
> Spatial.
> >  I think we can use all the help and contributions we can get in
> > Lucene.NET.
> >
> > Of course, we'd need to look and see what is possible, with porting over
> > LSP (not sure if it relies on any version specific features that may not
> > yet be in 3.0.3).  So, I say let's go for it, and if you need any
> help/want
> > to divide work between other committers, we can arrange that, and create
> > issues for it, that is, if the other committers don't object to this.
> >
> > On Tue, Apr 24, 2012 at 1:45 PM, Itamar Syn-Hershko  > >wrote:
> >
> > > Thanks for your reply.
> > >
> > >
> > > >  Aside from the original port which had many divergences from java,
> the
> > > > only other issue applied to spatial is LUCENENET-431, which would be
> > easy
> > > > to include.
> > > >
> > > >
> > > That is not correct. LUCENENET-431 was committed, but some fixed from
> > Java
> > > Lucene 3.0.3 are in as well. The whole thing is a mess.
> > >
> > > The reason for this mess is the amount of bugs in the original Java
> > > implementation of Spatial. This is also why it has been deprecated in
> > 3.6:
> > > https://issues.apache.org/jira/browse/LUCENE-2599
> > >
> > > I think the best route at this point is to port LSP aka Spatial4j to
> .NET
> > > and start using it as the Spatial module for Lucene.NET
> > > https://issues.apache.org/jira/browse/LUCENE-3795
> > >
> > > This is a Java Lucene 4 feature, but the current spatial implementation
> > is
> > > pretty unisable.
> > >
> > > I'm going to start looking into this, and would definitely appreciate
> > your
> > > input.
> > >
> > > Itamar.
> > >
> >
>

Re: unsubscribe,

[Christopher Currens]

To unsubscribe a different e-mail - e.g. you used to be subscribed as *
user@oldname.example* - send a message to

*list*-unsubscribe-*user=oldname.example*@apache.org(lucene-net-dev-unsubscribe-user=
oldname.exam...@apache.org)

You can do this provided you can still receive e-mails sent to the old
address (you will need to respond to the confirmation). [The list
moderators can also do this.]

from: http://www.apache.org/foundation/mailinglists.html

On Mon, Apr 30, 2012 at 9:08 AM, Chris Waterman  wrote:

> Sorry to spam everyone for this but is there a way to unsubscribe a
> specific email address other than the one from which you are sending? I
> originally subscribed from one email address but my address has changed.
> I'm still receiving messages from this listserv as forwarded from my old
> address and I'd like to unsubscribe. Thanks!
>
> -Original Message-
> From: Simon Svensson [mailto:si...@devhost.se]
> Sent: Thursday, April 26, 2012 10:37 PM
> To: lucene-net-...@lucene.apache.org
> Subject: Re: unsubscribe,
>
> Hi,
>
> You can do this by sending a mail to
> lucene-net-dev-unsubscr...@lucene.apache.org.
>
> // Simon
>
> On 27 apr 2012, at 06:55, Craig Main wrote:
>
> > Hi,
> >
> > There don't seem to be unsubscribe instructions in these emails?
> > Can anyone help.
> >
> > Thanks.
>
>

Re: [Lucene.Net] Coding Standards

[Christopher Currens]

Nice.  I noticed with R# 6.1 we can share settings on a
solution/project basis along with easy import.  Do you happen to have
one pre-made with the coding standards we're using, or is one already
checked into the repo, like we have with StyleCop?

Thanks,
Christopher

On Tue, Jan 24, 2012 at 7:24 AM, Michael Herndon
 wrote:
> You can. I've used it extensively on the 4.0 branch. painful for any
> Javascript coding or projects, but it has been extremely helpful with
> writing C# code and testing.
>
> On Tue, Jan 24, 2012 at 2:23 AM, Prescott Nasser wrote:
>
>>
>> fyi, I believe you can request a free resharper license for being an
>> active committer to an open source project (ie Lucene.Net).
>>
>>
>>
>>  > Date: Mon, 23 Jan 2012 23:20:25
>> -0800 > From: currens.ch...@gmail.com > To:
>> lucene-net-...@lucene.apache.org > Subject: [Lucene.Net] Coding Standards
>> > > All, > > I just wanted to confirm everyone's stance on the coding
>> guidelines > listed in the wiki. >
>> https://cwiki.apache.org/confluence/display/LUCENENET/Coding+Guidelines >
>> > Are these the official guidelines we are using? If they are, has > anyone
>> who has Resharper already created rules so others don't have > to? I
>> believe that these are the exact rules used in StyleCop, so > people
>> without Resharper can use those rules to test the code before > check-in,
>> so we may not need to have a ruleset for those who just want > to use the
>> stylecop plugin. > > There are things I like and dislike about the
>> Microsoft Design > Standards, specifically, I prefer private variables to
>> start with an > underscore for easy identification. Either way, making sure
>> there's a > ruleset will be helpful for other people when using tools to
>> conform > to the standards. > > > Thanks, > Christopher
>>

Re: [Lucene.Net] do we have a board report due?

[Christopher Currens]

Looks great, Prescott!  Thanks for getting that done.

On Tue, Jan 31, 2012 at 11:47 AM, Troy Howard  wrote:

> Looks good.
>
> On Tue, Jan 31, 2012 at 10:38 AM, Michael Herndon
>  wrote:
> > even though we're not voting on this. +1
> >
> > On Tue, Jan 31, 2012 at 1:30 PM, Prescott Nasser  >wrote:
> >
> >> I've updated the board report: wiki.apache.org/incubator/February2012
> >>
> >> if you guys could take a moment to review.
> >>
> >> Sent from my Windows Phone
> >> 
> >> From: Stefan Bodewig
> >> Sent: 1/30/2012 8:59 PM
> >> To: lucene-net-...@incubator.apache.org
> >> Subject: Re: [Lucene.Net] do we have a board report due?
> >>
> >> On 2012-01-31, Prescott Nasser wrote:
> >>
> >> > I didn't see a notice,
> >>
> >> me neither
> >>
> >> > but something on general caught my eye.
> >>
> >>  says: yes.
> >>
> >> Thank you for reminding us.
> >>
> >> Personally I'd like to see Lucene.NET graduate over the next three
> >> months so it would be good if we could identify what is preventing the
> >> project from just doing that.
> >>
> >> Stefan
> >>
>

Re: [Lucene.Net] Blog Setup

[Christopher Currens]

Looks like the blog was successfully setup (that was quick!).  You can
access it here:  https://blogs.apache.org/lucenenet/

I've migrated the whopping 3 new entries we already have on our
index/front-page in the news section over to the blog.  I would give a shot
at integrating it into the website, but I actually have no idea how to edit
the website. :)


Thanks,
Christopher

On Mon, Feb 13, 2012 at 6:17 PM, Prescott Nasser wrote:

>
> I've submitted a ticket here:
> https://issues.apache.org/jira/browse/INFRA-4433 I only added my name, I
> wasn't sure who else would want access - if you do want it, submit a
> comment to that ticket with your apache username and full name.   I'm going
> to try and integrate this into the site soon. I also have some ideas about
> how to utilize the blog that I'll outline after I get it up and running ~P
>  > From: bode...@apache.org
> > To: lucene-net-...@incubator.apache.org
> > Date: Mon, 13 Feb 2012 13:39:11 +0100
> > Subject: [Lucene.Net] Blog Setup
> >
> > Hi all,
> >
> > If we want a blog for Lucene.Net on blogs.apache.org, the instructions
> > to request one are at
> >  >
> > Mainly we should have a list of ASF ids of the initial set of admins and
> > authors.
> >
> > I had a look at how the RSS snippets are added to www.apache.org's index
> > page and it doesn't look to difficult to adapt.
> >
> > In
> > <
> https://svn.apache.org/repos/asf/infrastructure/site/trunk/content/index.html
> >
> > there is
> >
> > {% for e in blog.list %}
> > {{ e.title }}
> > {{ e.content|safe|truncatewords_html:50
> }}
> > 
> > {% endfor %}
> >
> > which iterates over a blogs collection created in path.pm via
> >
> > [qr!^/index\.html$!, news_page =>
> >   {
> > blog => ASF::Value::Blogs->new(blog => "foundation", limit=>
> 3),
> >   },
> > ],
> >
> > and uses the ASF::Value::Blog package that is part of the CMS.
> > <
> https://svn.apache.org/repos/infra/websites/cms/build/lib/ASF/Value/Blogs.pm
> >
> >
> > So getting content from the blog to the main page is pretty easy.  I
> > think the main site is re-created every fifteen minutes to ensure things
> > are fresh, not sure how one would go about this for a page that doesn't
> > change that often (manually triggering buildbot might be an option).
> > We'd need to ask this on the site-dev mailing list which is dedicated to
> > the CMS.
> >
> > Stefan
>
>

Re: [Lucene.Net] Blog Setup

[Christopher Currens]

I made some changes to the website in staging.  Just a few things regarding
the blog list, a little bit of left padding and adding a recent news header
above it.  I also changed the link style a little bit.  Feel free to revert
any/all changes I've made. :)


Thanks,
Christopher

On Tue, Feb 14, 2012 at 9:05 PM, Prescott Nasser wrote:

>
> Editing the site: http://www.apache.org/dev/cms#usage Staging:
> http://lucene.net.staging.apache.org/lucene.net/
>  > Date: Tue, 14 Feb 2012 11:03:58 -0800
> > From: currens.ch...@gmail.com
> > To: lucene-net-...@lucene.apache.org
> > Subject: Re: [Lucene.Net] Blog Setup
> >
> > Looks like the blog was successfully setup (that was quick!).  You can
> > access it here:  https://blogs.apache.org/lucenenet/
> >
> > I've migrated the whopping 3 new entries we already have on our
> > index/front-page in the news section over to the blog.  I would give a
> shot
> > at integrating it into the website, but I actually have no idea how to
> edit
> > the website. :)
> >
> >
> > Thanks,
> > Christopher
> >
> > On Mon, Feb 13, 2012 at 6:17 PM, Prescott Nasser  >wrote:
> >
> > >
> > > I've submitted a ticket here:
> > > https://issues.apache.org/jira/browse/INFRA-4433 I only added my
> name, I
> > > wasn't sure who else would want access - if you do want it, submit a
> > > comment to that ticket with your apache username and full name.   I'm
> going
> > > to try and integrate this into the site soon. I also have some ideas
> about
> > > how to utilize the blog that I'll outline after I get it up and
> running ~P
> > >  > From: bode...@apache.org
> > > > To: lucene-net-...@incubator.apache.org
> > > > Date: Mon, 13 Feb 2012 13:39:11 +0100
> > > > Subject: [Lucene.Net] Blog Setup
> > > >
> > > > Hi all,
> > > >
> > > > If we want a blog for Lucene.Net on blogs.apache.org, the
> instructions
> > > > to request one are at
> > > > <
> https://cwiki.apache.org/confluence/display/INFRA/Resource+request+FAQs
> > > >
> > > > Mainly we should have a list of ASF ids of the initial set of admins
> and
> > > > authors.
> > > >
> > > > I had a look at how the RSS snippets are added to www.apache.org's
> index
> > > > page and it doesn't look to difficult to adapt.
> > > >
> > > > In
> > > > <
> > >
> https://svn.apache.org/repos/asf/infrastructure/site/trunk/content/index.html
> > > >
> > > > there is
> > > >
> > > > {% for e in blog.list %}
> > > > {{ e.title }}
> > > > {{ e.content|safe|truncatewords_html:50
> > > }}
> > > > 
> > > > {% endfor %}
> > > >
> > > > which iterates over a blogs collection created in path.pm via
> > > >
> > > > [qr!^/index\.html$!, news_page =>
> > > >   {
> > > > blog => ASF::Value::Blogs->new(blog => "foundation",
> limit=>
> > > 3),
> > > >   },
> > > > ],
> > > >
> > > > and uses the ASF::Value::Blog package that is part of the CMS.
> > > > <
> > >
> https://svn.apache.org/repos/infra/websites/cms/build/lib/ASF/Value/Blogs.pm
> > > >
> > > >
> > > > So getting content from the blog to the main page is pretty easy.  I
> > > > think the main site is re-created every fifteen minutes to ensure
> things
> > > > are fresh, not sure how one would go about this for a page that
> doesn't
> > > > change that often (manually triggering buildbot might be an option).
> > > > We'd need to ask this on the site-dev mailing list which is
> dedicated to
> > > > the CMS.
> > > >
> > > > Stefan
> > >
> > >
>
>

Re: [Lucene.Net] Blog Setup

[Christopher Currens]

Erg.  Was it related to the whole documentation thing?  I'm pretty sure
it's "frowned upon" for our documentation to break SVN every time we do a
release, so we should probably figure out a solution for that.  :P


Thanks,
Christopher

On Wed, Feb 15, 2012 at 10:28 AM, Prescott Nasser wrote:

>
> Ick, I'm in the middle of publishing and working with Joe @ site-dev.
> We've totally f'd up svn. He's asked we stop doing things and he's going to
> fix it and get back to us... At least we're active.. ;) ~P
>  > Date: Wed, 15 Feb 2012 10:20:29 -0800
> > From: currens.ch...@gmail.com
> > To: lucene-net-...@lucene.apache.org
> > Subject: Re: [Lucene.Net] Blog Setup
> >
> > I made some changes to the website in staging.  Just a few things
> regarding
> > the blog list, a little bit of left padding and adding a recent news
> header
> > above it.  I also changed the link style a little bit.  Feel free to
> revert
> > any/all changes I've made. :)
> >
> >
> > Thanks,
> > Christopher
> >
> > On Tue, Feb 14, 2012 at 9:05 PM, Prescott Nasser  >wrote:
> >
> > >
> > > Editing the site: http://www.apache.org/dev/cms#usage Staging:
> > > http://lucene.net.staging.apache.org/lucene.net/
> > >  > Date: Tue, 14 Feb 2012 11:03:58 -0800
> > > > From: currens.ch...@gmail.com
> > > > To: lucene-net-...@lucene.apache.org
> > > > Subject: Re: [Lucene.Net] Blog Setup
> > > >
> > > > Looks like the blog was successfully setup (that was quick!).  You
> can
> > > > access it here:  https://blogs.apache.org/lucenenet/
> > > >
> > > > I've migrated the whopping 3 new entries we already have on our
> > > > index/front-page in the news section over to the blog.  I would give
> a
> > > shot
> > > > at integrating it into the website, but I actually have no idea how
> to
> > > edit
> > > > the website. :)
> > > >
> > > >
> > > > Thanks,
> > > > Christopher
> > > >
> > > > On Mon, Feb 13, 2012 at 6:17 PM, Prescott Nasser <
> geobmx...@hotmail.com
> > > >wrote:
> > > >
> > > > >
> > > > > I've submitted a ticket here:
> > > > > https://issues.apache.org/jira/browse/INFRA-4433 I only added my
> > > name, I
> > > > > wasn't sure who else would want access - if you do want it, submit
> a
> > > > > comment to that ticket with your apache username and full name.
> I'm
> > > going
> > > > > to try and integrate this into the site soon. I also have some
> ideas
> > > about
> > > > > how to utilize the blog that I'll outline after I get it up and
> > > running ~P
> > > > >  > From: bode...@apache.org
> > > > > > To: lucene-net-...@incubator.apache.org
> > > > > > Date: Mon, 13 Feb 2012 13:39:11 +0100
> > > > > > Subject: [Lucene.Net] Blog Setup
> > > > > >
> > > > > > Hi all,
> > > > > >
> > > > > > If we want a blog for Lucene.Net on blogs.apache.org, the
> > > instructions
> > > > > > to request one are at
> > > > > > <
> > >
> https://cwiki.apache.org/confluence/display/INFRA/Resource+request+FAQs
> > > > > >
> > > > > > Mainly we should have a list of ASF ids of the initial set of
> admins
> > > and
> > > > > > authors.
> > > > > >
> > > > > > I had a look at how the RSS snippets are added to www.apache.org
> 's
> > > index
> > > > > > page and it doesn't look to difficult to adapt.
> > > > > >
> > > > > > In
> > > > > > <
> > > > >
> > >
> https://svn.apache.org/repos/asf/infrastructure/site/trunk/content/index.html
> > > > > >
> > > > > > there is
> > > > > >
> > > > > > {% for e in blog.list %}
> > > > > > {{ e.title }}
> > > > > > {{
> e.content|safe|truncatewords_html:50
> > > > > }}
> > > > > > 
> > > > > > {% endfor %}
> > > > > >
> > > > > > which iterates over a blogs collection created in path.pm via
> > > > > >
> > > > > > [qr!^/index\.html$!, news_page =>
> > > > > >   {
> > > > > > blog => ASF::Value::Blogs->new(blog => "foundation",
> > > limit=>
> > > > > 3),
> > > > > >   },
> > > > > > ],
> > > > > >
> > > > > > and uses the ASF::Value::Blog package that is part of the CMS.
> > > > > > <
> > > > >
> > >
> https://svn.apache.org/repos/infra/websites/cms/build/lib/ASF/Value/Blogs.pm
> > > > > >
> > > > > >
> > > > > > So getting content from the blog to the main page is pretty
> easy.  I
> > > > > > think the main site is re-created every fifteen minutes to ensure
> > > things
> > > > > > are fresh, not sure how one would go about this for a page that
> > > doesn't
> > > > > > change that often (manually triggering buildbot might be an
> option).
> > > > > > We'd need to ask this on the site-dev mailing list which is
> > > dedicated to
> > > > > > the CMS.
> > > > > >
> > > > > > Stefan
> > > > >
> > > > >
> > >
> > >
>
>

Re: [Lucene.Net] MVP Summit

[Christopher Currens]

I would have loved to, especially since I'm relatively close to the
Microsoft campus, but I'm not an MVP. :)


Thanks,
Christopher

On Mon, Feb 27, 2012 at 9:27 AM, Simone Chiaretta <
simone.chiare...@gmail.com> wrote:

> Hi,
> is anybody attending the MVP Summit?
> Simone
>
> --
> Simone Chiaretta
> Microsoft MVP ASP.NET - ASPInsider
> Blog: http://codeclimber.net.nz
> RSS: http://feeds2.feedburner.com/codeclimber
> twitter: @simonech
>
> Any sufficiently advanced technology is indistinguishable from magic
> "Life is short, play hard"
>

Re: [Lucene.Net] MVP Summit

[Christopher Currens]

HAIII--CHAAA!

On Mon, Feb 27, 2012 at 10:58 AM, Troy Howard  wrote:

> NO SUMMIT 4 U!
>
> On Mon, Feb 27, 2012 at 10:55 AM, Christopher Currens
>  wrote:
> > I would have loved to, especially since I'm relatively close to the
> > Microsoft campus, but I'm not an MVP. :)
> >
> >
> > Thanks,
> > Christopher
> >
> > On Mon, Feb 27, 2012 at 9:27 AM, Simone Chiaretta <
> > simone.chiare...@gmail.com> wrote:
> >
> >> Hi,
> >> is anybody attending the MVP Summit?
> >> Simone
> >>
> >> --
> >> Simone Chiaretta
> >> Microsoft MVP ASP.NET - ASPInsider
> >> Blog: http://codeclimber.net.nz
> >> RSS: http://feeds2.feedburner.com/codeclimber
> >> twitter: @simonech
> >>
> >> Any sufficiently advanced technology is indistinguishable from magic
> >> "Life is short, play hard"
> >>
>

Re: [Lucene.Net] Official stance on API changes between major versions

[Christopher Currens]

I *really* don't mean to be a bother to anyone, but I'd like to continue
work on this.  I feel that until I can get a better sense of how the group
feels about this, I can't make much progress.  Perhaps this radio silence
is just because this email thread got lost in among the others.

On Fri, Feb 24, 2012 at 6:50 PM, Prescott Nasser wrote:

> Im not against breaking compatibility when changing the version number to
> a new major 2 -> 3. Im not sure how others feel. Matching Java access
> modifiers seems like the right move.
>
> That said, what if we mark obsolete in 3.0.3 and when we make the jump to
> 4.0 wipe them out? In my head we shouldn't spend too much time cleaning up
> 3.0.3 aside from bug fixes if were just going to swap it for 4.0 in the
> near future.
>
> There has to be a break at some point, making it with a major release is
> the best place to make it.
>
> Sent from my Windows Phone
> 
> From: Christopher Currens
> Sent: 2/24/2012 2:45 PM
> To: lucene-net-...@lucene.apache.org
> Subject: [Lucene.Net] Official stance on API changes between major versions
>
> A bit of background about what I've been doing lately on the project.
>  Because we've now confirmed that the .NET 3.0.3 branch is a completed port
> of Java 3.0.3 version, I've been spending time trying to work on some of
> the bugs and improvements that are assigned to this version.  There wasn't
> any real discussion about the actual features, I just created some (based
> on mailing list discussions) and assigned them to the 3.0.3 release.  The
> improvements I've been working on lately are ones that have bugged me
> specifically since I've started using Lucene.NET.
>
> I've worked on https://issues.apache.org/jira/browse/LUCENENET-468 and
> https://issues.apache.org/jira/browse/LUCENENET-470 so far.
>
> LUCENENET-740 is pretty much completed, all of the classes that implemented
> Closeable() now implement IDisposable, having a public void Dispose()
> and/or protected virtual void Dispose(bool disposing), depending if the
> class is sealed or not.  What is left to do on that issue would be to make
> sure that all of the tests are a) overriding the protected dispose method
> as needed and b) are actually calling Dispose or are in a using statement.
>
> I've done quite a bit of work on LUCENENET-468, as well, though it is going
> far slower than 470, because there's a lot more that needs to be done and a
> bit more carefully, if I don't want to break anyone's code when they move
> to 3.0.  I'm not doing them in any particular order, I'm really just
> running VS2010 code analysis (Rule CA1024 only, actually) and changing the
> ones suggested and ones I happen across to use Properties.  I've also spent
> some time trying to wrap public fields in public properties.  However, this
> one in particular has been posing some problems for me, and really brings
> me to the point of this email.
>
> Due to the way most class members are named (there's a lot of redundancy),
> I'm finding it difficult to move forward with some of these refactoring
> without breaking backwards compatibility or adding more things to change in
> regards to LUCENE-446 and CLS compliance.  For classes that are
> specifically marked internal, this of course, hasn't been a problem, I just
> make the breaking change and fix it other places in the library.  This is,
> of course, a problem with class that are public, including classes that
> *should not* be marked public but are anyway.  It's a little off topic, but
> we stray far sometimes from the access modifiers defined on the java
> classes.  I've found that nearly all cases were because they were needed
> for the NUnit tests.  That problem no longer exists in 3.0.3, as the Test
> library can now access those types in the core assembly.  I personally feel
> that whenever we find an difference in access modifiers, we change it to
> match java, however, if customers are using that, well, now they can't.
>  That's issue number one that I wanted to discuss with the group.
>
> Going back to the difficulties in ".NET-ifying" the API, often times if I
> want to convert a Get[name]()/Set[name]() group or individual method to a
> property, the resulting property name will conflict with an already
> existing public field, another method with the exact same name, or the name
> of the enclosing type itself.  The latter can't easily be solved, so I'm
> not fretting too much about it.  The first two are easier to solve, but not
> without breaking backwards compatibility for some users.
>
> Now, the API between 2.x and 3.x differs greatly

Re: [Lucene.Net] Merging 3.0.3 into Trunk

[Christopher Currens]

No sweat, if we're ready to merge it in, I can do it, all while trying not
to break everything! :)


On Tue, Feb 28, 2012 at 11:12 AM, Prescott Nasser wrote:

> I meant to merge, its on my to do list, might take me some time - just
> started a new job
>
> Sent from my Windows Phone
> ____
> From: Christopher Currens
> Sent: 2/28/2012 10:36 AM
> To: lucene-net-...@lucene.apache.org
> Subject: [Lucene.Net] Merging 3.0.3 into Trunk
>
> Now that we've release 2.9.4g, are we at a point to where we can merge the
> 3.0.3 branch in with Trunk?  Any thoughts on that either way?
>
>
> Thanks,
> Christopher
>

Re: [Lucene.Net] Merging 3.0.3 into Trunk

[Christopher Currens]

I agree with Prescott.  Make a patch for that sucker! :)


Thanks,
Christopher

On Thu, Mar 1, 2012 at 9:57 AM, Prescott Nasser wrote:

> Jira and then just submit your own patch imo
>
> Sent from my Windows Phone
> 
> From: Stefan Bodewig
> Sent: 3/1/2012 7:23 AM
> To: lucene-net-...@incubator.apache.org
> Subject: Re: [Lucene.Net] Merging 3.0.3 into Trunk
>
> On 2012-02-29, Stefan Bodewig wrote:
>
> > On 2012-02-28, Christopher Currens wrote:
>
> >> Alright, it's done!  3.0.3 is now merged in with Trunk!
>
> > I'll see to running RAT and looking at the line-ends over the next few
> > days so we can get them fixed once and not run into it with the release.
>
> I went for EOLs first and there are 621 files outside of lib and doc
> that need to be fixed.  What I have now is not just a patch (of more
> than 200k lines), but also a list of 621 files that need their
> svn:eol-style property to be set.
>
> I can create a JIRA ticket for that attaching my patch and the list of
> files to fix or - since I technically am a committer - could just commit
> my cleaned up workspace as is (plus JIRA ticket that I'd open and close
> myself).
>
> What would you prefer?
>
> RAT doesn't really make sense before the line feeds are correct (I've
> seen quite a few files without license headers by manual inspection).
>
> Stefan
>

Re: Getting bug fix from Lucene Java into Lucene.Net

[Christopher Currens]

That largely depends on how different the 3.4/3.5 java API is from the
current version in our trunk (3.0.3).  From a maintainability standpoint,
it would be easier for us to fix this bug when we've ported Lucene.NET to
the same version that java was at when it was fixed.  It looks like they
added a class and changed another's signature, and then changed all of the
comparator classes to inherit from the new one, instead the old.  I don't
know what that would do to our current version of code, or if that can be
worked in without major changes.

Worst case scenario, we can't get it in until we reach 3.4, but I can
certainly see what we can do get it in earlier.  In the meantime, it seems
that Hoss Man has noted a workaround here
https://issues.apache.org/jira/browse/LUCENE-3390?focusedCommentId=13088832&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-13088832
that can be used.


Thanks,
Christopher

On Wed, Mar 14, 2012 at 6:04 AM, Tom Cabanski  wrote:

> I am running into the following problem discussed and fixed in the current
> Lucene Java version:
>
> "While sorting results over a numeric field, documents which do not contain
> a value for the sorting field seem to get 0 (ZERO) value in the sort.
> (Tested against Double, Float, Int & Long numeric fields ascending and
> descending order).
> This behavior is unexpected, as zero is "comparable" to the rest of the
> values. A better solution would either be allowing the user to define such
> a "non-value" default, or always bring those document results as the last
> ones."
>
> Is this something that can get into Lucene.Net soon?  See
> https://issues.apache.org/jira/browse/LUCENE-3390 for complete information
> on the Lucene issue and fix.
>
>
>  Tom Cabanski
> Software Developer & President 
>  5702 Kendall Hill Ln
> Sugar Land, TX 77479
> 832-766-5961
>
> *
> *
> Profiles: 
> LinkedIn
> Contact me: [image: Google Talk] t...@cabanski.com [image:
> Skype]tom.cabanski [image:
> MSN] t...@cabanski.com
> My blog: Top Ten Reasons to Avoid Taking Advanced Distributed System Design
> with Udi Dahan<
> http://tom.cabanski.com/2012/02/09/top-ten-reasons-to-avoid-taking-advanced-distributed-system-design-with-udi-dahan/
> >
>  [image: Twitter]  Latest tweet: @DataArtist
> : Ditto for Azure. It all came back. Funny thing is I think MS never even
> bothered to fix Zune problem because it was firmware
> Follow @tcabanski  Reply
> <
> http://twitter.com/?status=@tcabanski%20&in_reply_to_status_id=179875723673223170&in_reply_to=tcabanski
> >
> Retweet
> <
> http://twitter.com/?status=RT%20%40tcabanski%3A%20%40DataArtist%20%3A%20Ditto%20for%20Azure.%20%20It%20all%20came%20back.%20%20Funny%20thing%20is%20I%20think%20MS%20never%20even%20bothered%20to%20fix%20Zune%20problem%20because%20it%20was%20firmware
> >
>  05:24 Mar-14
>  Get this email app!
> <
> http://www.wisestamp.com/apps/twitter?utm_source=extension&utm_medium=email&utm_term=twitter&utm_campaign=apps
> >
>

Re: Lucene.NET 3.0.3 Build issues

[Christopher Currens]

Thanks for the feedback.  Let us know if you run into any more
issues/concerns.


Thanks,
Christopher

On Wed, Aug 8, 2012 at 1:33 PM, Granroth, Neal V. <
neal.granr...@thermofisher.com> wrote:

> Yes I pulled from the branch not the trunk. I apparently made the
> incorrect assumption that it would be slightly more stable than the current
> work-in-progress.
>
> Thanks for the quick attention and clarifications.  Especially for those
> that rely upon the binary packages.
>
> - Neal
>
>
> -Original Message-
> From: Christopher Currens [mailto:currens.ch...@gmail.com]
> Sent: Wednesday, August 08, 2012 3:21 PM
> To: lucene-net-...@lucene.apache.org
> Subject: Re: Lucene.NET 3.0.3 Build issues
>
> FYI - SVN has been updated with corrected VS2010 solutions and added VS2012
> directory/solution files.
>
> On Wed, Aug 8, 2012 at 1:12 PM, Christopher Currens <
> currens.ch...@gmail.com
> > wrote:
>
> > See inline comments.
> >
> >
> > Thanks,
> > Christopher
> >
> > On Wed, Aug 8, 2012 at 12:07 PM, Granroth, Neal V. <
> > neal.granr...@thermofisher.com> wrote:
> >
> >> I just pulled down the 3.0.3 branch from SVN and have encountered an
> >> initial problem with the VisualStudio solution file Lucene.Net.Core.sln
> in
> >> the VS2010 folder.
> >>
> >> Did you pull down the 3.0.3 branch or trunk?  Trunk is 3.0.3, I'm not
> > even sure the 3.0.3 branch exists anymore, and if it does, it is very,
> very
> > out of date.
> >
> >
> >> This solution will not load in VS2010, Visual Studio complains that it
> >> was created with a newer version.
> >> Opening the solution file in notepad reveals that it was created with
> >> VS2012 (a not yet released product)
> >>
> >> They are supposed to be VS2010, if the pathing didn't give it away.  I
> > believe it was my fault, as I usually will change them back to VS2010
> > manually, but forgot to do that while I was adding .NET 3.5 support back
> > in.  In order to automate the change, I needed to use the RC and forgot
> to
> > change the solution files back. As an aside, VS2012 solution files are
> (or
> > at least supposed to be) backwards compatible with VS2010.  On my laptop,
> > which only has VS2010 SP1, they open and compile just fine.
> >
> >
> >> It would be very helpful if those maintaining the source distribution
> >> limit themselves to released development tools only.
> >>
> >> Since that's our normal policy, this isn't really an issue.
> >
> >
> >> It also make me wonder of the viability of any binary distributions;
> they
> >> certainly should not have been created with VS2012RC
> >>
> >
> > Prescott used VS2010 to make the binary, so I don't think you need to
> > worry about this.
> >
> >
> >>
> >> - Neal G.
> >>
> >>
> >
>

Re: Lucene.Net 3.0.3 and medium trust

[Christopher Currens]

It must be something we've missed, as we want to target medium trust
locations in the future.  I can't think of anything off the top of my
head that would require medium trust, though, let alone unmanaged
code.  I'll dive into this.


Thanks,
Christopher

On Mon, Aug 13, 2012 at 10:01 PM, Simon Svensson  wrote:
> Hi,
>
> I'm having trouble upgrading a web application running under medium trust
> from 2.9.4 to 3.0.3. Code that previously worked now throws a
> SecurityException.
>
> [SecurityException: Request for the permission of type
> 'System.Security.Permissions.SecurityPermission, mscorlib, Version=4.0.0.0,
> Culture=neutral, PublicKeyToken=b77a5c561934e089' failed.]
>Lucene.Net.Support.WeakKey`1..ctor(T key) +0
>Lucene.Net.Support.WeakDictionary`2.get_Item(TKey key) +113
>Lucene.Net.Util.DefaultAttributeFactory.GetClassForInterface() +178
>Lucene.Net.Util.DefaultAttributeFactory.CreateAttributeInstance() +95
>Lucene.Net.Util.AttributeSource.AddAttribute() +375
>Lucene.Net.Analysis.CharTokenizer..ctor(TextReader input) +126
>Lucene.Net.Analysis.WhitespaceTokenizer..ctor(TextReader in) +37
>
>
> The DefaultAttributeFactory, via WeakReference, requires
> SecurityPermissionFlag.UnmanagedCode which is not present under medium
> trust. There's an AttributeFactory.DEFAULT_ATTRIBUTE_FACTORY which I could
> to replace the DefaultAttributeFactory, but it's readonly. I'm rewriting my
> code to call the constructor overload (on tokenizers) accepting an
> AttributeFactory, but this means that I cannot use any existing Analyzer
> since they don't provide an extension points to change the AttributeFactory.
>
> Is medium trust [using default classes] dropped in 3.0.3, or is this
> something we've missed?
>
> // Simon

Re: twitter questions

[Christopher Currens]

In regards to the NIOFSDirectory, we have no plans on supporting it
for several reasons, the largest being that NIO (meaning New I/O) is a
java only API.  I guess it would be good to briefly discuss what NIO
is in Java (anyone feel free to correct me when I inevitably get some
of the details wrong :)  The main features that NIO introduced were:

* Regex pattern matching for file contents (used with the new
abstractions of memory mapping a file to a buffer)
* Character set encoders/decoders
* Improved file system support with locking and memory mapping
* Async I/O (the biggest one, I think)

Most of these abstractions don't exist in .NET, but that doesn't mean
that comparable features don't either. :)  On that end, since we're
trying to use .NET constructs, I have personally been experimenting
with I think would be an equivalent to the NIOFSDirectory in java, one
that uses Async I/O (this seems to be the only thing that lucene uses
from the NIO api).

The first thing I was curious about was any speed increases using
Async I/O for index writing (lucene does not do this), and I was a
first surprised when I found that it was generally the same speed or a
little slower.  It was a learning experience because I discovered that
asynchronous writes are not always run asynchronously in windows.  I
haven't had much time to experiment with the asynchronous reading,
which is really the only different in NIOFS from a SimpleFSDirectory,
but I'm hoping to get something similar to how the NIOFSDirectory is
designed working in .NET.

I have some other ideas related to memory mapped files, which we
briefly prototyped but never added to core, but I think it would
perform very well on SSD devices and so I'd like to revisit it.

I guess the answer would be no we are not creating an NIOFSDirectory,
but we are looking into an AsyncIODirectory.  In theory, they should
be pretty much the same, the real difference is the name. ;)


Thanks,
Christopher

On Mon, Aug 20, 2012 at 8:27 AM, Prescott Nasser  wrote:
> @prescottnasser  baby! I've had that account for a while, but barely use it. 
> I've been trying to use it more..
>
>> Date: Mon, 20 Aug 2012 17:55:59 +0300
>> Subject: Re: twitter questions
>> From: ita...@code972.com
>> To: lucene-net-...@lucene.apache.org
>>
>> Get MetroTwit or TwitDeck and create your own Twitter account while at it :)
>>
>> On Mon, Aug 20, 2012 at 5:52 PM, Prescott Nasser 
>> wrote:
>>
>> > I'm terrible with social media- is there any way to have tweets directed
>> > at @LuceneDotNet sent to one of our mailing lists? Or should I just get on
>> > top of monitoring it more often?
>> >
>> > > From: casper...@caspershouse.com
>> > > To: lucene-net-...@lucene.apache.org
>> > > CC: lucene-net-...@lucene.apache.org
>> > > Subject: Re: twitter questions
>> > > Date: Mon, 20 Aug 2012 14:46:57 +
>> > >
>> > > Answered:
>> > >
>> > > http://stackoverflow.com/a/12039811/50776
>> > >
>> > >
>> > >
>> > > On Aug 20, 2012, at 10:42 AM, "Michael Herndon" <
>> > mhern...@wickedsoftware.net> wrote:
>> > >
>> > > > Thanks Nicholas for having a look at the SO question. Anyone know
>> > > > about the NIOFSDirectory off the top of their head?
>> > > >
>> > > > Cheers,
>> > > > Michael
>> > > >
>> > > >
>> > > >
>> > > > On Mon, Aug 20, 2012 at 10:28 AM, Nicholas Paldino [.NET/C# MVP]
>> > > >  wrote:
>> > > >> I've also found the question on SO, I'll give it a shot later today.
>> > > >>
>> > > >>
>> > > >>
>> > > >> On Aug 20, 2012, at 10:18 AM, "Michael Herndon" <
>> > mhern...@wickedsoftware.net> wrote:
>> > > >>
>> > > >>> I went to update the twitter feed and saw these questions in case
>> > > >>> anyone wants to answer these:
>> > > >>>
>> > > >>> @Nick_Craver
>> > > >>> @LuceneDotNet - is anyone already working on a NIOFSDirectory port?
>> > > >>> Unless I misunderstand, it would be a huge boost to our SSD
>> > > >>> environment'
>> > > >>>
>> > > >>> @intelligibabble
>> > > >>> would love it if some #lucene or @LuceneDotNet gurus took a look at
>> > my
>> > > >>> SO question stackoverflow.com/questions/1135…
>> > > >>>
>> > http://stackoverflow.com/questions/11354455/using-lucene-net-thread-safe-from-asp-net-web-application
>> > > >>>
>> > > >>
>> > > >
>> > >
>> >
>> >
>

Re: Added hunspell stemming to Contrib.Analyzers

[Christopher Currens]

I don't think you've missed anything.  I pulled the changes, and everything
immediately built with no errors, and all tests passed, so it works for me
as well.  Licenses are in order, I verified the eol-style, and the source
and test data all look to be in the correct places.  I think that's really
all we need to be mindful of when adding code to an existing project, at
least, I don't *think* I'm leaving anything out. :)


Thanks,
Christopher

On Wed, Jun 6, 2012 at 12:55 PM, Simon Svensson  wrote:

> Hi,
>
> I've just committed[1] the hunspell stuff to Contrib.Analyzers. I've added
> license headers, set svn:eol-style and ensured that the tests works. Could
> someone check if I've forgot something?
>
> [1] 
> http://svn.apache.org/viewvc?**view=revision&revision=1347076<
> http://svn.apache.org/viewvc?**view=revision&revision=1347076
> **>
>
> // Simon
>

Re: Corrupt index

[Christopher Currens]

Mike, The codebase for lucene.net should be almost identical to java's
3.0.3 release, and LUCENE-1044 is included in that.

Itamar, are you committing the index regularly?  I only ask because I can't
reproduce it myself by forcibly terminating the process while it's
indexing.  I've tried both 3.0.3 and 2.9.4.  If I don't commit at all and
terminate the process (even with a 10,000 4K documents created), there will
be no documents in the index when I open it in luke, which I expect.  If I
commit at 10,000 documents, and terminate it a few thousand after that, the
index has the first ten thousand that were committed.  I've even terminated
it *while* a second commit was taking place, and it still had all of the
documents I expected.

It may be that I'm not trying to reproducing it correctly.  Do you have a
minimal amount of code that can reproduce it?


Thanks,
Christopher

On Wed, Jun 13, 2012 at 9:31 AM, Michael McCandless <
luc...@mikemccandless.com> wrote:

> Hi Itamar,
>
> One quick question: does Lucene.Net include the fixes done for
> LUCENE-1044 (to fsync files on commit)?  Those are very important for
> an index to be intact after OS/JVM crash or power loss.
>
> More responses below:
>
> On Tue, Jun 12, 2012 at 8:20 PM, Itamar Syn-Hershko 
> wrote:
>
> > I'm a Lucene.Net committer, and there is a chance we have a bug in our
> > FSDirectory implementation that causes indexes to get corrupted when
> > indexing is cut while the IW is still open. As it roots from some
> > retroactive fixes you made, I'd appreciate your feedback.
> >
> > Correct me if I'm wrong, but by design Lucene should be able to recover
> > rather quickly from power failures or app crashes. Since existing segment
> > files are read only, only new segments that are still being written can
> get
> > corrupted. Hence, recovering from worst-case scenarios is done by simply
> > removing the write.lock file. The worst that could happen then is having
> the
> > last segment damaged, and that can be fixed by removing those files,
> > possibly by running CheckIndex on the index.
>
> You shouldn't even have to run CheckIndex ... because (as of
> LUCENE-1044) we now fsync all segment files before writing the new
> segments_N file, and then removing old segments_N files (and any
> segments that are no longer referenced).
>
> You do have to remove the write.lock if you aren't using
> NativeFSLockFactory (but this has been the default lock impl for a
> while now).
>
> > Last week I have been playing with rather large indexes and crashed my
> app
> > while it was indexing. I wasn't able to open the index, and Luke was even
> > kind enough to wipe the index folder clean even though I opened it in
> > read-only mode. I re-ran this, and after another crash running CheckIndex
> > revealed nothing - the index was detected to be an empty one. I am not
> > entirely sure what could be the cause for this, but I suspect it has
> > been corrupted by the crash.
>
> Had no commit completed (no segments file written)?
>
> If you don't fsync then all sorts of crazy things are possible...
>
> > I've been looking at these:
> >
> >
> https://issues.apache.org/jira/browse/LUCENE-3418?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
> >
> https://issues.apache.org/jira/browse/LUCENE-2328?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
>
> (And LUCENE-1044 before that ... it was LUCENE-1044 that LUCENE-2328
> broke...).
>
> > And it seems like this is what I was experiencing. Mike and Mark will
> > probably be able to tell if this is what they saw or not, but as far as I
> > can tell this is not an expected behavior of a Lucene index.
>
> Definitely not expected behavior: assuming nothing is flipping bits,
> then on OS/JVM crash or power loss your index should be fine, just
> reverted to the last successful commit.
>
> > What I'm looking for at the moment is some advice on what FSDirectory
> > implementation to use to make sure no corruption can happen. The 3.4
> version
> > (which is where LUCENE-3418 was committed to) seems to handle a lot of
> > things the 3.0 doesn't, but on the other hand LUCENE-3418 was introduced
> by
> > changes made to the 3.0 codebase.
>
> Hopefully it's just that you are missing fsync!
>
> > Also, is there any test in the suite checking for those scenarios?
>
> Our test framework has a sneaky MockDirectoryWrapper that, after a
> test finishes, goes and corrupts any unsync'd files and then verifies
> the index is still OK... it's good because it'll catch any times we
> are missing calls t sync, but, it's not low level enough such that if
> FSDir is failing to actually call fsync (that wsa the bug in
> LUCENE-3418) then it won't catch that...
>
> Mike McCandless
>
> http://blog.mikemccandless.com
>

Re: Multi-targeting and .Net (WAS Outstanding issues for 3.0.3)

[Christopher Currens]

Thanks Rob.  This was my almost exact solution to this problem, except mine
just modifies the project file and saves a copy named *.35.csproj/sln.  It
got a little more complicated, because I can't support Contrib.Spatial in
.NET 3.5 without some hefty changes I didn't want to do, so there's
(unfortunately) very specific, not really re-usable code, to detect that.
 We also have to add a conditional symbol to each project.  It all works
good enough (read no errors) and generates .NET 3.5 solutions and project
files that can be opened in Visual Studio or built via MSBuild.  I guess my
larger concern is how it can affect the workflow, and since you have some
experience maybe you can answer some of my questions.

What is your workflow with building for all these different frameworks?
 More specifically, do you code for a certain framework and then just run
the tool and hope that the rest compile (this would probably be *my*
"genius" way of doing it)?  There are certainly nice features in .NET 4.0
(Tasks, etc..) that I would prefer to use, so it would make sense to first
write for that target, build the 3.5 projects and try and add conditionals
for that.


Thanks,
Christopher

On Mon, Jul 9, 2012 at 10:21 PM, Rob Vesse  wrote:

> Hey Chris
>
> For multi-targeted stuff with .Net I've built some stuff that uses a small
> executable and NAnt to generate project files which can then be compiled
> with MSBuild.
>
> This technique is used extensively for dotNetRDF where we target up to 6
> different framework profiles for some of our libraries.  Essentially it
> takes a source project, a project template to populate and a resulting
> project name you want to generate.  It also needs a relative path to
> indicate where the source project lives in relation to the target project.
>
> When it runs it goes through the source project file and for every
> Compile/EmbeddedResource item which is directly in that project (I.e. not
> included via a Link) it adds a Link to that item to the target project
> file.
>
> The target project file is literally a stub project file (generated in
> Visual Studio with the target framework set appropriately and it's own
> AssemblyInfo.cs), see
> http://dotnetrdf.svn.sourceforge.net/viewvc/dotnetrdf/Trunk/Libraries/core.
> clientprofile/dotNetRDF.ClientProfile.csproj.template?revision=2252&view=ma
> rkup for an example template.
>
> See
> http://dotnetrdf.svn.sourceforge.net/viewvc/dotnetrdf/Trunk/Build/ExportCor
> eContentsToTemplate/ for the actual tool
>
> For the NAnt scripts with example usages see
> http://dotnetrdf.svn.sourceforge.net/viewvc/dotnetrdf/Trunk/Build/nant/dotn
> etrdf.build?revision=2252&view=markup - Look at the projectgen goals for
> invocation examples and the compile targets for invoking MSBuild on the
> end results.
>
> It may be somewhat clunky but it does work, I'm sure it can be adapted to
> your needs if you're interested - it's all open source
>
> Rob
>
> On 7/9/12 5:51 PM, "Christopher Currens"  wrote:
>
> >I've got it working, compiling and all test passing...The only caveat is
> >that I'm not sure the best way to multi-target.  It doesn't really work on
> >a project level, so you'd have to create two separate projects, one for
> >.NET 4 and the other for 3.5.  To aid me, I wrote a small tool that
> >creates
> >copies of all of the 4.0 projects and solutions to work against the 3.5
> >framework.  Anyone have experience with multi-targeting like this?
> >
> >
> >Thanks,
> >Christopher
> >
> >On Mon, Jul 9, 2012 at 11:29 AM, Prescott Nasser
> >wrote:
> >
> >>
> >> Have at it.
> >>
> >> 
> >> > Date: Mon, 9 Jul 2012 11:20:06 -0700
> >> > Subject: Re: Outstanding issues for 3.0.3
> >> > From: currens.ch...@gmail.com
> >> > To: lucene-net-...@lucene.apache.org
> >> >
> >> > If it's alright with you, I'll work on it a little bit in that branch,
> >> and
> >> > see what kind of progress I can make, since I have some time right
> >>now.
> >> >
> >> > On Mon, Jul 9, 2012 at 11:06 AM, Prescott Nasser
> >> >> >wrote:
> >> >
> >> > >
> >> > > I made some progress on 480 - checked into the 3.5 branch, there is
> >> more
> >> > > work to be done we could potentially move it to 3.0.3, but I put it
> >> into
> >> > > 3.5 because I felt that we were closer to having this released, and
> >> adding
> >> > > those changes would add a fair amount 

Re: build scripts

[Christopher Currens]

Yeah.  In Visual Studio you can just change the release configuration
manually, and no matter what, it will only build for the framework you have
selected.  With the build script, I didn't know how to update jenkins and I
knew that in all deploy cases we needed both built, so for the time being
it does it automatically...this will change in the future, though we do
still need to build both in the CI server, and also need to build both
whenever we make a nuget package.  I'm trying to think of a maintainable
way to have the packaging system make sure both of the framework targets
have been run before building the nuget package.  That would probably be
the most challenging part of it, which is probably not that challenging at
all. ;)

Thanks,
Christopher


On Mon, Jul 23, 2012 at 2:18 PM, Michael Herndon <
mhern...@wickedsoftware.net> wrote:

> heh, I thought the peculiar thing was that it was just building the .NET
> 3.5 version randomly instead of being an actual deliberate change.  I was
> trying to think how that was possible. =)
>
>
> On Sun, Jul 22, 2012 at 2:55 PM, Christopher Currens <
> currens.ch...@gmail.com> wrote:
>
> > It is, but I didn't want to deal with changing our CI server
> configuration
> > to get what is a little bit of benefit (at the moment) for the amount of
> > time it would have taken me to figure it all out.  At the moment, the
> kind
> > of packaging we need for a release would be both frameworks, so as of
> now,
> > I have it outputting both.  I am not oblivious to the awkwardness of the
> > build scripts how they are now, as the most glaringly obvious flaw with
> > outputting both, is that nunit runs the tests for .NET35 and .NET4 at the
> > same time. There are several things wrong with the way that works.
> >
> > It's not a hefty change, though, that needs to be done if you wanted to
> > change it to a build parameter, I have a mostly finished patch for that
> > since that was original first goal.  There's an extra build step that can
> > be removed and a variable added to each project page.  The larger(?)
> change
> > would the actual packaging for NUnit.  Even though it's already it's own
> > separate target, I'm sure we want to validate that both .NET35 and .NET4
> > builds have been run before packaging the output.
> >
> >
> > Thanks,
> > Christopher
> >
> >
> > On Sun, Jul 22, 2012 at 11:27 AM, Michael Herndon <
> > mhern...@wickedsoftware.net> wrote:
> >
> > > that is a peculiar behavior.
> > >
> > > On Sun, Jul 22, 2012 at 4:41 AM, Christopher Currens <
> > > currens.ch...@gmail.com> wrote:
> > >
> > > > Right now, it outputs both automatically.  I didn't put in a switch,
> it
> > > > just does it be default.
> > > >
> > > >
> > > > On Sat, Jul 21, 2012 at 2:38 PM, Michael Herndon <
> > > > mhern...@wickedsoftware.net> wrote:
> > > >
> > > > > you would need create a build variable for the .net framework
> version
> > > > > parameter for msbuild and have it run a second build and switch out
> > the
> > > > > version.
> > > > >
> > > > > On Sat, Jul 21, 2012 at 3:08 PM, Prescott Nasser <
> > > geobmx...@hotmail.com
> > > > > >wrote:
> > > > >
> > > > > >
> > > > > >
> > > > > >
> > > > > >
> > > > > > There was a commit for updating the build scripts - is there a
> > > command
> > > > I
> > > > > > can run to output both 4.0 and 3.5 binaries of everything?
> > > > > >
> > > > >
> > > >
> > >
> >
>

Re: [Lucene.Net] escaping single quotes when using query parser

[Christopher Currens]

I'm not sure you're issue is related to single quotes.  The only characters
that need to be escaped for the QueryParser are + - ! ( ) { } [ ] ^ " ~ * ?
: \  You can do that using QueryParser.Escape(string).  It's possible you it
might be related to the analyzer that you're using.  In my experience,
sometimes using a different analyzer to index than you use to search can
*sometimes* cause unexpected behavior like this.  Since I haven't myself run
into this exact problem to the best of my knowledge, it's tough for me to
give a more specific answer without your code/test data.

Thanks,
Christopher

On Thu, Apr 7, 2011 at 2:01 AM, Ben Foster  wrote:

> Hi,
>
>
>
> How should we escape single quotes when working with the query parser?
>
>
>
> Currently we have a description field that may contain single quotes.
>
>
>
> Whilst this field is correctly indexed when we search the description no
> results are returned. I'm assuming it's because we need to replace the
> single quote in the search term with an escaped version.
>
>
>
> Many thanks,
>
>
>
> Ben Foster
>
>
>
> planetcloud
> The Elms, Hawton
> Newark-on-Trent
> Nottinghamshire
> NG24 3RL
>
>
>
>   www.planetcloud.co.uk
>
>
>
>

[Lucene.Net] Adding proper System.IO.Stream support to Lucene.Net

[Christopher Currens]

All,

I've spent the past few days looking at what it would take to implement
proper streaming of data into and out of an index.  Fortunately, it hasn't
proven very difficult at all, leaving me with a solution that works very
nicely.  Now that I know it's possible, I wanted to discuss with the
community the best way to add this to the API.

Currently, it's setup that a field can have a Stream value if its binary
(System.IO.Stream StreamValue()).  I have plans to, wherever in Lucene a
byte[] is used, to replace it with streaming functions, internally.  I think
its a good idea to keep the byte[] BinaryValue() as it is, but essentially
replace it, by default, with a kind of lazy loading.  In the current version
of lucene, if a user were to open a document with a binary field, that
entire field will be loaded into memory.

The idea behind replacing the internals of FieldsReader.cs by passing a
stream along instead of a byte[], is that people using the API to stream the
data out will load no more into memory than they have to.  People using the
byte[] BinaryValue() function to get the binary data will actually have
improved performance as well, as the byte array will be loaded when calling
the method, instead of the creation of the document.

As a final note on binary data streaming, by streaming the data in, we
obviously can't support compression of those fields.  The compression in
Lucene is poor anyway, as it's not compression that can be done in blocks,
it requires large amounts of memory as it needs all the data in memory to do
the compression, which is also done in a separate byte array.  However, an
ability I had briefly talked to Troy about in person, was the ability to add
StreamFilters, so that data passed is filtered first by a compression
algorithm or such before its stored in the index.  However, that doesn't
really apply directly to the lucene domain, but it does at least afford the
user the opportunity to be able to do that via streaming data into
lucene.net.

I also want to add proper TextReader support to Lucene.Net.  A large
difference between the Java and .NET versions of lucene is that the Java
version supports setting a field's value to a TextReader, that both analyzes
and stores the data.  Due to the fact that the TextReader in .Net doesn't
support resetting or seeking of the underlying stream, we can only analyze
the text in lucene, we can't store the field.

A solution that comes to mind would be creating a util class, something
like SeekableTextReader, that inherits from TextReader that can be passed to
the field, with special behavior that allows it to be reset, and thus both
analyzed and stored.  Perhaps the largest downside to that solution, is in
order to keep the API the same while allowing it to be stored, it would
require fairly ugly checks like "if(reader is SeekableTextReader) //do
this".

Perhaps a cleaner solution would be to add yet another value to the Field
class that allowed for a SeekableTextReader to be passed.  This way has its
own downsides, in that now there are two methods that expect TextReaders,
one stores and one doesn't, seems rather confusing.  But I suppose this is
why I was looking for the community's opinion in the first place.


The more comments about this the better.  I think adding this could add some
much needed functionality to Lucene, and start setting apart its performance
from the Java version.


Thanks,
Christopher

Re: [Lucene.Net] [VOTE] Lucene.Net-2.9.4-incubator-RC2 Release

[Christopher Currens]

+1

On Thu, Nov 3, 2011 at 7:24 AM, Michael Herndon  wrote:

> +1
>
> On Thu, Nov 3, 2011 at 6:19 AM, Stefan Bodewig  wrote:
>
> > On 2011-11-02, Prescott Nasser wrote:
> >
> > > http://people.apache.org/~pnasser/Lucene.Net/2.9.4-incubating-RC2/
> >
> > As usual, no technical opinion at all, I leave that to others.
> >
> > Sigs and hashes look good.  NOTICE and LICENSE are fine.
> >
> > RAT is almost happy, we should add license headers to
> >
> src/contrib/DistributedSearch/LuceneMonitorSetup/LuceneMonitorSetup.vdproj
> > and test/contrib/SpellChecker/Contrib.SpellChecker.Test.nunit but these
> > are not blockers to me.  Two files is not the same as 120 files.
> >
> > Source distribution and
> >
> >
> http://svn.apache.org/repos/asf/incubator/lucene.net/tags/Lucene.Net_2_9_4_RC2/
> > don't match exactly, the READMEs are different.  The one of the source
> > distribution says .NET 3.5, the one of the tag says 2.0.  No biggy but
> > you should adjust the tag IMHO.
> >
> > Wearing my IPMC heat I don't see any reason to block the release, so +1
> > from me.
> >
> > Stefan
> >
>

Re: [Lucene.Net] Lucene.Net-2.9.4-incubator-RC2 Documentation

[Christopher Currens]

I noticed that we have a bit of documentation in the 'site' directory of
the, and the trunk directory.  Which one are we using to link to the
website, the one in trunk or the site folder?  I feel that maybe we could
still keep the docs in trunk zipped for each release and tag, then extract
that to the site directory when we want to release documentation.  At least
then it would keep our SVN uncluttered.  To be honest, though, I don't
really know how documentation is stored in other projects, so I'll admit
I'm not even 100% sure if that's a plausible solution.


On Mon, Nov 7, 2011 at 11:55 PM, Prescott Nasser wrote:

>
> My intention is to link it to the website, so we have browsable
> documentation
>
>
>
>
>
> 
> > Date: Mon, 7 Nov 2011 19:26:23 -0800
> > From: currens.ch...@gmail.com
> > To: lucene-net-...@lucene.apache.org
> > Subject: Re: [Lucene.Net] Lucene.Net-2.9.4-incubator-RC2 Documentation
> >
> > I don't understand why we have the rendered html in the docs. I don't
> mind
> > having the .chm rendered and put in the repo, but the entire HTML
> > documentation spans 8,000 files and over 100mb. The CHM comes in at
> around
> > 15mb.
> >
> > I don't think it's necessary to have both in the repo, but if the
> consensus
> > is to keep them both, I think we should bundle the HTML docs in a zip,
> > instead of being added as loose files, at least in trunk. I think it's
> > kinda silly the way it is now, and SVN does better at handling 1 large
> file
> > versus 8,000 smaller ones.
> >
> > On Mon, Nov 7, 2011 at 6:53 AM, Michael Herndon <
> mhern...@wickedsoftware.net
> > > wrote:
> >
> > > @Stefan.
> > >
> > > I wouldn't worry about the taking the blame, you've done plenty to
> help out
> > > and there is no way to catch everything. We'll learn as we go.
> > >
> > > As svnpub is the only option and since we can't run the binary version
> that
> > > uses ASP.NET, we'll need to probably take your suggestion commit the
> > > smaller chunks of html then.
> > >
> > > I'll do it manually this time and see if I can't write a script that
> > > automates it in the future.
> > >
> > > @Chris, thanks for the fixes to the build scripts this weekend.
> > >
> > > - Michael
> > >
> > >
> > > On Mon, Nov 7, 2011 at 9:20 AM, Stefan Bodewig 
> wrote:
> > >
> > > > On 2011-11-07, Michael Herndon wrote:
> > > >
> > > > > I can rebuild it, but the trick is replacing the version of it in
> svn
> > > so
> > > > > that it does not cause svnsync and cms to choke. Last time I just
> > > pushed
> > > > it
> > > > > into branch/site/docs. However, that is not publicly visible for
> the
> > > > > incubation website, so Prescott had to do an svn move.
> > > >
> > > > When I recommended to do the svn move I didn't realize we were
> talking
> > > > about that many files. I simply didn't check, sorry.
> > > >
> > > > > I'm not quite sure how to go about it this time around. I would
> push it
> > > > to
> > > > > jira, but it caps uploads at 10 mb.
> > > >
> > > > Then it still had to go to svn in some way.
> > > >
> > > > Personally I'm not a friend of generated documents in svn but I'm in
> a
> > > > minority here.
> > > >
> > > > With svnpubsub being your only option I think the only thing you can
> do
> > > > is split the commit into smaller chunks, committing 100 or 200 files
> at
> > > > a time. Maybe infra has better ideas than that, I don't.
> > > >
> > > > Stefan
> > > >
> > >
>

Re: [Lucene.Net] Lucene.NET 2.9.4 Question

[Christopher Currens]

We're currently working on the release of 2.9.4, and its during out release
phase that we generate the NuGet package.  There was a vote to release it a
week or so ago, but some last minute changes postponed it.  I'm not
personally working with the other committers who are packaging the release
for download from our website and NuGet, but I'm sure they're respond with
whatever progress they've made.  Of course, it's going slow, because we all
have full time jobs, which have priority over our apache commitments.

However, if I were to guess, I would say it would be in the next week or
two (don't hold me to that).  After that, I imagine it won't be too much
longer after that, we'll be releasing 3.x, as there's already some work
going on in that respect, but that largely depends on the difficulties we
have mimicing java's behavior in .NET.


Thanks,
Christopher

On Wed, Nov 16, 2011 at 11:12 AM, Ivan von Nagy
wrote:

> Is there an estimate when 2/9/4 will be available on NuGet? We have been
> using our own compiled version in order make use of the
> Lucene.Net.Analysis.CJK.CJKAnalyzer since that is not available in the
> NuGet version of Contrib.
> Thanks,
> Ivan
>
> Ivan von Nagy | senior software engineer
> (o) 503-553-2602
> webtrends | 851
> SW 6th Ave, Suite 1600, Portland, OR 97204
> The Global Leader in Mobile and Social Analytics
>
>

Re: [Lucene.Net] Roadmap

[Christopher Currens]

Regarding the 3.0.3 branch I started last week, I've put in a lot of late
nights and gotten far more done in a week and a half than I expected.  The
list of changes is very large, and fortunately, I've documented it in some
files that are in the branches root of certain projects.  I'll list what
changes have been made so far, and some of the concerns I have about them,
as well as what still needs to be done.  You can read them all in detail in
the files that are in the branch.

All changes in 3.0.3 have been ported to the Lucene.Net and
Lucene.Net.Test, except BooleanClause, LockStressTest, MMapDirectory,
NIOFSDirectory, DummyConcurrentLock, NamedThreadFactory, and
ThreadInterruptedException.

MMapDirectory and NIOFSDirectory have never been ported in the first place
for 2.9.4, so I'm not worried about those.  LockStressTest is a
command-line tool, porting it should be easy, but not essential to a 3.0.3
release, IMO.  DummyConcurrentLock also seems unnecessary (and
non-portable) for .NET, since it's based around Java's Lock class and is
only used to bypass locking, which can be done by passing new Object() to
the method.
NamedThreadFactory I'm unsure about.  It's used in ParallelMultiSearcher
(in which I've opted to use the TPL), and seems to be only used for
debugging, possibly testing.  Either way, I'm not sure it's necessary.
 Also, named threads would mean we probably would have to move the class
from the TPL, which greatly simplified the code and parallelization of it
all, as I can't see a way to Set names for a Task.  I suppose it might be
possible, as Tasks have unique Ids, and you could use a Dictionary to map
the thread's name to the ID in the factory, but you'd have to create a
helper function that would allow you to find a task by its name, which
seems more work than the resulting benefits.  VS2010 already has better
support for debugging tasks over threads (I used it when writing the
class), frankly, it's amazing how easy it was to debug.

Other than the above, the entire code base in the core dlls is at 3.0.3,
which is exciting, as I'm really hoping we can get Lucene.Net up to the
current version of Java's 3.x branch, and start working on a line-by-line
port of 4.0.  Tests need to be written for some of the collections I've
made that emulate Java's, to make sure they're even behaving the same way.
 The good news is that all of the existing tests pass as a whole, so it
seems to be working, though I'd like the peace of mind of having tests for
them (being HashMap, WeakDictionary and
IdentityCollection, it's quite possible any one of them could
be completely wrong in how they were put together.)

I'd also like to finally formalize the way we use IDisposable in
Lucene.Net, by marking the Close functions as obsolete, moving the code
into Dispose, and eventually (or immediately) removing the Close functions.
 There's so much change to the API, that now would be a good time to make
that change if we wanted to.  I'm hesitant to move from a line-by-line port
of Lucene.Net completely, but rather having it be close as possible.  The
main reason I feel this way, is when I was porting the Shingle namespace of
Contrib.Analyzers, Troy has written it in a .Net way which different
GREATLY from java lucene, and it did make porting it considerably more
difficult; to keep the language to a minimum, I'm just going to say it was
a pain, a huge pain in fact.  I love the idea of moving to a more .NET
design, but I'd like to maintain a line-by-line port anyway, as I think
porting changes is far easier and quicker that way.  At this point, I'm
more interested in getting Lucene.Net to 4.0 and caught up to java, than I
am anything else, hence the extra amount of time I've put into this project
over the past week and a half.  Though this isn't really a place for this
discussion.

The larger area of difficult for the port, however, is the Contrib section.
 There are two major problems with it that is slowing me down.  First,
there are a lot of classes that are outdated.  I've found versions of code
that still have the Apache 1.1 License attached to it, which makes the code
quite old.  Also, it was almost impossible for me to port a lot of changes
in Contrib.Analyzers, since the code was so old and different from Java's
2.9.4.

Second, we had almost no unit tests ported for any of the classes, which
means they have to be ported from scratch.

Third, there are a lot of contrib projects that have never been ported over
from java.  That list includes: smartcn (I believe this is an intelligent
Chinese analyzer), benchmark, collation, db, lucli, memory, misc,
queryparser, remote, surround, swing, wikipedia, xml-query-parser.
 However, it should be noted that I'm not even sure which, if any, SHOULD
be ported or even CAN be ported.

The progress on 3.0.3 Contrib is going steady, however.  The entire
Analyzers project (except for smartcn) has been ported, as well as the test
for them, which all pass.  There were some minor exceptio

Re: [Lucene.Net] Roadmap

[Christopher Currens]

Some of the Lucene classes have Dispose methods, well, ones that call Close
(and that Close method may or may not call base.Close(), if needed or not).
 Virtual dispose methods can be dangerous only in that they're easy to
implement wrong.  However, it shouldn't be too bad, at least with a
line-by-line port, as we would make the call to the base class whenever
Lucene does, and that would (should) give us the same behavior, implemented
properly.  I'm not aware of differences in the JVM, regarding inheritance
and base methods being called automatically, particularly Close methods.

Slightly unrelated, another annoyance is the use of Java Iterators vs C#
Enumerables.  A lot of our code is there simply because there are
Iterators, but it could be converted to Enumerables. The whole HasNext,
Next vs C#'s MoveNext(), Current is annoying, but it's used all over in the
base code, and would have to be changed there as well.  Either way, I would
like to push for that before 3.0.3 is relased.  IMO, small changes like
this still keep the code similar to the line-by-line port, in that it
doesn't add any difficulties in the porting process, but provides great
benefits to the users of the code, to have a .NET centric API.  I don't
think it would violate our project desciption we have listed on our
Incubator page, either.


Thanks,
Christopher

On Mon, Nov 21, 2011 at 12:03 PM, casper...@caspershouse.com <
casper...@caspershouse.com> wrote:

> +1 on the suggestion to move Close -> IDisposable; not being able to use
> "using" is such a pain, and an eyesore on the code.
>
>
> Although it will have to be done properly, and not just have Dispose call
> Close (you should have proper protected virtual Dispose methods to take
> inheritance into account, etc).
>
>
> - Nick
>
> 
>
> From: "Christopher Currens" 
>
> Sent: Monday, November 21, 2011 2:56 PM
>
> To: lucene-net-...@lucene.apache.org
>
> Subject: Re: [Lucene.Net] Roadmap
>
>
> Regarding the 3.0.3 branch I started last week, I've put in a lot of late
>
> nights and gotten far more done in a week and a half than I expected.  The
>
> list of changes is very large, and fortunately, I've documented it in some
>
> files that are in the branches root of certain projects.  I'll list what
>
> changes have been made so far, and some of the concerns I have about them,
>
> as well as what still needs to be done.  You can read them all in detail
> in
>
> the files that are in the branch.
>
>
> All changes in 3.0.3 have been ported to the Lucene.Net and
>
> Lucene.Net.Test, except BooleanClause, LockStressTest, MMapDirectory,
>
> NIOFSDirectory, DummyConcurrentLock, NamedThreadFactory, and
>
> ThreadInterruptedException.
>
>
> MMapDirectory and NIOFSDirectory have never been ported in the first place
>
> for 2.9.4, so I'm not worried about those.  LockStressTest is a
>
> command-line tool, porting it should be easy, but not essential to a 3.0.3
>
> release, IMO.  DummyConcurrentLock also seems unnecessary (and
>
> non-portable) for .NET, since it's based around Java's Lock class and is
>
> only used to bypass locking, which can be done by passing new Object() to
>
> the method.
>
> NamedThreadFactory I'm unsure about.  It's used in ParallelMultiSearcher
>
> (in which I've opted to use the TPL), and seems to be only used for
>
> debugging, possibly testing.  Either way, I'm not sure it's necessary.
>
> Also, named threads would mean we probably would have to move the class
>
> from the TPL, which greatly simplified the code and parallelization of it
>
> all, as I can't see a way to Set names for a Task.  I suppose it might be
>
> possible, as Tasks have unique Ids, and you could use a Dictionary to map
>
> the thread's name to the ID in the factory, but you'd have to create a
>
> helper function that would allow you to find a task by its name, which
>
> seems more work than the resulting benefits.  VS2010 already has better
>
> support for debugging tasks over threads (I used it when writing the
>
> class), frankly, it's amazing how easy it was to debug.
>
>
> Other than the above, the entire code base in the core dlls is at 3.0.3,
>
> which is exciting, as I'm really hoping we can get Lucene.Net up to the
>
> current version of Java's 3.x branch, and start working on a line-by-line
>
> port of 4.0.  Tests need to be written for some of the collections I've
>
> made that emulate Java's, to make sure they're even behaving the same way.
>
> The good news is that all of the existing tests pass as a 

Re: [Lucene.Net] Roadmap

[Christopher Currens]

To clarify, it wasn't as much *difficult* as it was more *painful*.  Above,
I was inferring that it was more difficult that the rest of the code, which
by comparison was easier.  It wasn't painless to try and map where code
changes were from the java classes into the .Net version.  I prefer that
style more for its readability and the niceties of working with a .Net
style of Lucene, however as I said before, it slowed down significantly the
porting process.  I hope it didn't come across that I thought that it was
bad code, because it's probably the most readable code we have in the
Contrib at the moment.

I want to make it clear that my intention right now is to get Lucene.Net up
to date with Java.  When I read the Java code, I understand its intent, and
I make sure the ported code represents it.  That takes enough time as it
is, moving to try and figure out where the code went in Lucene.Net, since
it wasn't a 1-1 map, was a MINOR annoyance, especially when you compare it
to the issues I had dealing with the differences between the two languages,
generics especialy.  That being said, I don't have a problem with code
being converted in a .Net idiomatic way, in fact, I welcome it, if it still
allows the changes to be ported with minimal effort.  I feel at this point
in the project, there are some limitations to how far I'd like it to
diverge.

Anyway, my opinion, which may not be in agreement with the group as a
whole, is that it would be better to bring the codebase up to date, or at
least more up to date with java's, and then maintaining a version with a
complete .net-concentric API.  I feel this would beeasier, as porting
Java's Lucene SVN commits by the week would be a relatively small workload.

On Mon, Nov 21, 2011 at 2:41 PM, Troy Howard  wrote:

> So, if we're getting back to the line by line port discussion... I
> think either side of this discussion is too extreme. For the case in
> point Chris just mentioned (which I'm not really sure what part was so
> difficult, as I ported that library in about 30 minutes from
> scratch)... anything is a pain if it sticks out in the middle of doing
> something completely different.
>
> The only reason we are able to do this "line by line" is due to the
> general similarity between Java and C#'s language syntax. If we were
> porting Lucene to a completely different language, that had a totally
> different syntax, the process would go like this:
>
> - Look at the original code, understand it's intent
> - Create similar code in the new language that expresses the same intent
>
> When applying changes:
>
> - Look at the original code diffs, understanding the intent of the change
> - Look at the ported code, and apply the changed logic's meaning in
> that language
>
> So, is just a different thought process. In my opinion, it's a better
> process because it forces the developer to actually think about the
> code instead of blindly converting syntax (possibly slightly
> incorrectly and introducing regressions). While there is a large
> volume of unit tests in Lucene, they are unfortunately not really the
> right tests and make porting much more difficult, because it's hard to
> verify that your ported code behaves the same because you can't just
> rely on the unit tests to verify your port. Therefore, it's safer to
> follow a process that requires the developer to delve deeply into the
> meaning of the code. Following a line-by-line process is convenient,
> but doesn't focus on meaning, which I think is more important.
>
> Thanks,
> Troy
>
> On Mon, Nov 21, 2011 at 2:23 PM, Christopher Currens
>  wrote:
> > Digy,
> >
> > No worries.  I wasn't taking them personally.  You've been doing this
> for a
> > lot longer than I have, but I didn't understand you pain until I had to
> go
> > through it personally. :P
> >
> > Have you looked at Contrib in a while?  There's a lot of projects that
> are
> > in Java's Contrib that are not in Lucene.Net?  Is this because there are
> > some that can't easily (if at all) be ported over to .NET or just because
> > they've been neglected?  I'm trying to get a handle on what's important
> to
> > port and what isn't.  Figured someone with experience could help me with
> a
> > starting point over deciding where to start with everything that's
> missing.
> >
> >
> > Thanks,
> > Christopher
> >
> > On Mon, Nov 21, 2011 at 2:13 PM, Digy  wrote:
> >
> >>
> >> Chris,
> >>
> >> Sorry, if you took my comments about "pain of porting" personally. That
> >> wasn't my intension.
> &

Re: [Lucene.Net] Roadmap

[Christopher Currens]

Regarding the short term goals that Scott mentioned, I agree.  I think over
the past 9 months that we've been active, it's time we see what we need to
do to graduate from the incubator.  Also, 3.0.3 is actually close to a
release, *depending* on how we feel about the Contrib libraries, which I'll
discuss in a separate thread.

Scott didn't mention directly, but I think it would be good to port the 3.x
branch past 3.0.3.  Lucene has released 3.1, 3.2, 3.3, and 3.4 in addition
to 3.0.3.  Whether this means we release all those versions, or just port
up to 3.4 and just release it, that's something we'd all have to agree
upon.  I want to get a 3.x branch up to where Java's is.  Also, deciding if
porting 4.0 can happen at the same time as 3.x is worked on and how to go
about it, particularly how far we want to diverge from java.  Either way, I
think maintaining both 3.x and 4.x would be a good thing for the community
to have.


On Tue, Nov 22, 2011 at 8:56 AM, Scott Lombard wrote:

> Mike,
>
> You're right about putting together a higher level discussion.  Here are
> the
> road map items I see.  I am interested in other have to say.
>
> None of the items I have listed are contigent on the other so they can be
> done in parallel or out of order.
>
>
> 1) Complete the release of 2.9.4
> 2) Create and release 3.0.3
>
> 3) Graduate from the incubator
> 4) Document a porting process that the community can reference.
> 5) Port 4.0
>
>
>
> Scott
>
> > -Original Message-
> > From: Michael Herndon [mailto:mhern...@wickedsoftware.net]
> > Sent: Tuesday, November 22, 2011 10:28 AM
> > To: lucene-net-...@lucene.apache.org
> > Subject: Re: [Lucene.Net] Roadmap
> >
> > While much of the content in this thread is valid and is
> > important, especially concerns, pain points, and
> > implementation details... we've gotten way off topic.
> >
> > road map != implementation details. We should keep to a much
> > a higher level discussion to get this knocked out.
> >
> > Lets outline the roadmap, put it in a wiki page.
> >
> > Then discuss how to go about each major milestone in separate
> > threads to discuss implementation details. Or at least let
> > the people who are going to work on that particular milestone
> > publish their intentions to keep everyone else informed since
> > we're currently in a do-ocracy like state.
> >
> > And by all means, discuss the next immediate milestones first
> > so people who want to dive into that can proceed.
> >
> > So what are the next two major milestones?  And from a higher
> > level perspective what are the major items that deem those
> > milestones complete?
> >
> > What would be the the next 3 ideal milestones after the first
> > two? And what would be the intentions for those milestones to
> > accomplish?
> >
> > - Michael
> >
> >
> >
> > On Mon, Nov 21, 2011 at 7:28 PM, Christopher Currens <
> > currens.ch...@gmail.com> wrote:
> >
> > > Next to impossible/really, really hard.  There are just some things
> > > that don't map quite right.  Sharpen is great, but it seems
> > you need
> > > to code written in a way that makes it easily convertible,
> > and I don't
> > > see the folks at Lucene changing their coding style to do that.
> > >
> > > An example: 3.0.3 changes classes that inherited from
> > util.Parameter,
> > > to java enums.  Java enums are more similar to classes than
> > they are in C#.
> > >  They can have methods, fields, etc.  I wound up converting
> > them into
> > > enums with extension methods and/or static classes (usually to
> > > generate the enum).  The way the code was written in Java,
> > there's no
> > > way a automated tool could figure that out on its own,
> > unless you had
> > > some sort of way to tell it what to do before hand.
> > >
> > > I imagine porting it by hand is probably easier, though it would be
> > > nice if there was a tool that would at least convert the
> > syntax from
> > > Java to C#, as well as changing the naming scheme to a .NET
> > compatible
> > > one.  However, that only really helps if you're porting
> > classes from
> > > scratch.  It could, also, hide bugs, since it's possible, however
> > > unlikely, something could port perfectly, but not behave
> > the same way.
> > >
> > > A class that has many calls to string.Substring is a good
> > example of this.
> > >  If the name of the funct

[Lucene.Net] Contrib and releases

[Christopher Currens]

I wanted to take some time to discuss our position on the Contrib projects.
 Digy and I were a little off topic in the roadmap thread and I brought it
up.  Digy mentioned he always felt that it was a "nice to have" but
not necessarily required for a release.  I can't say I disagree.

I had some time to look over a lot of the contrib code in Java, and there
are quite a few projects that cannot be ported directly, as they rely on
3rd party Java libraries that have no direct .Net equivalent.  Porting them
could delay releases a long time, which is why I think it hasn't really
been kept up to date as it is.

I think a requirement for releases should be to have whatever projects that
are currently in contrib to be up to date and building, with valid and
passing tests (our 2.9.4 Contrib.Analyzers project is missing tests for 9
namespaces).  I think it should be as simple as that.  I don't think we
should worry about adding new projects, unless you feel compelled to do so.
 My opinion is that if someone wants a Contrib added to the project,
someone can port and donate the code to our project, or if they request it,
someone can volunteer to port it themselves.

People do use our Contrib assemblies, I personally think this is a fair
trade-off to only have to maintain what we already have.  I would like to
know how everyone else feels about it.


Thanks,
Christopher

Re: [Lucene.Net] Re: Memory Leak in 2.9.2.2

[Christopher Currens]

Do you know how big the documents are that you are trying to delete/update?
 I'm trying to find a copy of 2.9.2 to see if I can reproduce it.


Thanks,
Christopher

On Tue, Nov 29, 2011 at 9:11 AM, Trevor Watson <
powersearchsoftw...@gmail.com> wrote:

> Sorry for the duplicate post. I was on the road and posted both via my web
> mail and office mail by mistake
>
> The increase is a very gradual,  the program starts at about 160,000k
> according to task manager (I know that's not entirely accurate, but it was
> the best I had at the time) and would, after adding 25,000-40,000 result in
> an out of memory exception (800,000k according to taskmanager). I tried
> building a copy of 2.9.4 to test, but could not find one that worked in
> visual studio 2005
>
> I did notice using Ants memory profiler that there were a number of
> byte[32789] arrays that I didn't know where they came from in memory.
>
> On Monday, November 28, 2011, Christopher Currens  >
> wrote:
> > Hi Trevor,
> >
> > What kind of memory increase are we talking about?  Also, how big are the
> > documents that you are indexing, the ones returned from getFileInfoDoc()?
> >  Is it putting an entire file into the index?  Pre 2.9.3 versions had
> > issues with holding onto allocated byte arrays far beyond when they were
> > used.  The memory could only be freed via closing the IndexWriter.
> >
> > I'm a little unclear on exactly what's happening.  Are you noticing
> memory
> > spike and stay constant at that level or is it a gradual increase?  Is it
> > causing your application to error, (ie OutOfMemory exception, etc)?
> >
> >
> > Thanks,
> > Christopher
> >
> > On Mon, Nov 28, 2011 at 5:59 PM, Trevor Watson <
> > powersearchsoftw...@gmail.com> wrote:
> >
> >> I'm attempting to use Lucene.Net v2.9.2.2 in a Visual Studio 2005 (.NET
> >> 2.0) environment.  We had a piece of software that WAS working.  I'm not
> >> sure what has changed however, the following code results in a memory
> leak
> >> in the Lucene.Net component (or a failure to clean up used memory).
> >>
> >> The code in issue is here:
> >>
> >>  private void SaveFileToFileInfo(Lucene.Net.Index.IndexWriter iw, bool
> >> delayCommit, string sDataPath)
> >> {
> >>   Document doc = getFileInfoDoc(sDataPath);
> >>   Analyzer analyzer = clsLuceneFunctions.getAnalyzer();
> >>   if (this.FileID == 0)
> >>   {
> >>  string s = "";
> >>   }
> >>   iw.UpdateDocument(new Lucene.Net.Index.Term("FileId",
> >> this.fileID.ToString("0")), doc, analyzer);
> >>
> >>   analyzer = null;
> >>   doc = null;
> >>   if (!delayCommit)
> >>iw.Commit();
> >> }
> >>
> >> Commenting out the line iw.UpdateDocument resulted in no memory
> increase.
> >> I also tried replacing it with a deleteDocument and  AddDocument and the
> >> memory increased the same as using the UpdateDocument function
> >>
> >> The getAnalyzer() function returns a ExtendedStandardAnalyzer, but it's
> the
> >> UpdateDocument line specifically that gives me the issue.
> >>
> >> Any assistance would be greatly appreciated.
> >>
> >> Trevor Watson
> >>
> >
>

Re: [Lucene.Net] Re: Memory Leak in 2.9.2.2

[Christopher Currens]

Trevor,

I'm not sure if you can use 2.9.4, though, it looks like you're using
VS2005 and .NET 2.0.  2.9.4 targets .NET 4.0, and I'm fairly certain we use
classes only available in 4.0 (or 3.5?).  However, if you can, I would
suggest updating, as 2.9.4 should be a fairly stable release.

The leak I'm talking about is addressed here:
https://issues.apache.org/jira/browse/LUCENE-2467, and the ported code
isn't available in 2.9.2, but I've confirmed the patch is in 2.9.4.  It may
or may not be what your issue is.  You say that it was at one time working
fine, I assume you mean no memory leak.  I would take some time to see what
else in your code has changed.  Make sure you're calling Close on whatever
needs to be closed (IndexWriter/IndexReader/Analyzers, etc).

Unfortunately for us, memory leaks are hard to debug over email, and it's
difficult for us to tell if it's any change to your code or an issue with
Lucene .NET.  As far as I can tell, this is the only memory leak I can find
that affects 2.9.2.


Thanks,
Christopher

On Wed, Nov 30, 2011 at 8:25 AM, Prescott Nasser wrote:

> We just released 2.9.4 - the website didn't update last night, so ill have
> to try and update it later today. But if you follow the link to download
> 2.9.2 dist you'll see folders for 2.9.4.
>
> I'll send an email to the user and dev lists once i get the website to
> update
> 
> From: Trevor Watson
> Sent: 11/30/2011 8:14 AM
> To: lucene-net-...@lucene.apache.org
> Subject: [Lucene.Net] Re: Memory Leak in 2.9.2.2
>
> You said "pre 2.9.3"  I checked the apache lucene.net page to try to see
> if
> I could get a copy of 2.9.3, but it was never on the site, just 2.9.2.2 and
> 2.9.4(g).  Was this an un-released version?  Or am I looking in the wrong
> spot for updates to lucene.net?
>
> Thanks for all your help
>
> On Tue, Nov 29, 2011 at 2:59 PM, Trevor Watson <
> powersearchsoftw...@gmail.com> wrote:
>
> > I can send you the dll that I am using if you would like.  The documents
> > are _mostly_ small documents.  Emails and office docs size of plain text
> >
> >
> > On Tuesday, November 29, 2011, Christopher Currens <
> > currens.ch...@gmail.com> wrote:
> > > Do you know how big the documents are that you are trying to
> > delete/update?
> > >  I'm trying to find a copy of 2.9.2 to see if I can reproduce it.
> > >
> > >
> > > Thanks,
> > > Christopher
> > >
> > > On Tue, Nov 29, 2011 at 9:11 AM, Trevor Watson <
> > > powersearchsoftw...@gmail.com> wrote:
> > >
> > >> Sorry for the duplicate post. I was on the road and posted both via my
> > web
> > >> mail and office mail by mistake
> > >>
> > >> The increase is a very gradual,  the program starts at about 160,000k
> > >> according to task manager (I know that's not entirely accurate, but it
> > was
> > >> the best I had at the time) and would, after adding 25,000-40,000
> > result in
> > >> an out of memory exception (800,000k according to taskmanager). I
> tried
> > >> building a copy of 2.9.4 to test, but could not find one that worked
> in
> > >> visual studio 2005
> > >>
> > >> I did notice using Ants memory profiler that there were a number of
> > >> byte[32789] arrays that I didn't know where they came from in memory.
> > >>
> > >> On Monday, November 28, 2011, Christopher Currens <
> > currens.ch...@gmail.com
> > >> >
> > >> wrote:
> > >> > Hi Trevor,
> > >> >
> > >> > What kind of memory increase are we talking about?  Also, how big
> are
> > the
> > >> > documents that you are indexing, the ones returned from
> > getFileInfoDoc()?
> > >> >  Is it putting an entire file into the index?  Pre 2.9.3 versions
> had
> > >> > issues with holding onto allocated byte arrays far beyond when they
> > were
> > >> > used.  The memory could only be freed via closing the IndexWriter.
> > >> >
> > >> > I'm a little unclear on exactly what's happening.  Are you noticing
> > >> memory
> > >> > spike and stay constant at that level or is it a gradual increase?
> >  Is it
> > >> > causing your application to error, (ie OutOfMemory exception, etc)?
> > >> >
> > >> >
> > >> > Thanks,
> > >> > Christopher
> > >> >
> > >> >

Re: [Lucene.Net] Re: Memory Leak in 2.9.2.2

[Christopher Currens]

Trevor,

Unforunately I was unable to reproduce the memory leak you're experiencing
in 2.9.2.  Particularly with byte[], of the 18,277 that were created, only
13 were not garbage collected, and it's likely that they are not related to
Lucene (it's possible they are static, therefore would only be destroyed
with the AppDomain, outside of what the profiler can trace).  I tried to
emulate the code you showed us and there were no signs of any allocated
arrays that weren't cleaned up.  That doesn't mean there isn't one in your
code, but I just can't reproduce it with what you've shown us.  If it's
possible you can write a small program that has the same behavior, that
could help us track it down.

As a side note, what was a little disconcerting, though, was in 2.9.4 with
the same code, it created 28,565 byte[], and there was quite a few more
left uncollected (2,805 arrays).  The allocations are happening in
DocumentsWriter.ByteBlockAllocator, I'll have to look at it later though,
to see if its even a problem.


Thanks,
Christopher


On Wed, Nov 30, 2011 at 12:41 PM, Granroth, Neal V. <
neal.granr...@thermofisher.com> wrote:

> Or maybe put the changes within a conditional compile code block?
>
> Thanks DIGY, works great.
>
> - Neal
>
> -Original Message-
> From: Prescott Nasser [mailto:geobmx...@hotmail.com]
> Sent: Wednesday, November 30, 2011 2:35 PM
> To: lucene-net-...@lucene.apache.org
> Subject: RE: [Lucene.Net] Re: Memory Leak in 2.9.2.2
>
> Probably makes for a good wiki entry
>
> Sent from my Windows Phone
> 
> From: Digy
> Sent: 11/30/2011 12:04 PM
> To: lucene-net-...@lucene.apache.org
> Subject: RE: [Lucene.Net] Re: Memory Leak in 2.9.2.2
>
> OK, here is the code that can be compiled against .NET 2.0
> http://pastebin.com/k2f7JfPd
>
> DIGY
>
>
> -Original Message-
> From: Granroth, Neal V. [mailto:neal.granr...@thermofisher.com]
> Sent: Wednesday, November 30, 2011 9:26 PM
> To: lucene-net-...@lucene.apache.org
> Subject: RE: [Lucene.Net] Re: Memory Leak in 2.9.2.2
>
> DIGY,
>
> Thanks for the tip, but could you be a little more specific?
> Where and how are "extension-methods calls" replaced?
>
> For example, how would I change the CloseableThreadLocalExtensions method
>
>public static void Set(this ThreadLocal t, T val)
>{
>t.Value = val;
>}
>
>
> to eliminate the compile error
>
> Error   2   Cannot define a new extension method because the compiler
> required type 'System.Runtime.CompilerServices.ExtensionAttribute' cannot
> be
> found. Are you missing a reference to System.Core.dll?
>
> due to the Set parameter "this ThreadLocal t" ?
>
>
> - Neal
>
>
> -Original Message-
> From: Digy [mailto:digyd...@gmail.com]
> Sent: Wednesday, November 30, 2011 12:27 PM
> To: lucene-net-...@lucene.apache.org
> Subject: RE: [Lucene.Net] Re: Memory Leak in 2.9.2.2
>
> FYI, 2.9.4 can be compiled against .Net 2.0 with a few minor changes in
> CloseableThreadLocal
>
> (like uncommenting ThreadLocal class and replacing extension-methods
> calls
>
> with static calls to CloseableThreadLocalExtensions)
>
>
>
>
>
> DIGY
>
>
>
>
>
> -Original Message-
> From: Christopher Currens [mailto:currens.ch...@gmail.com]
> Sent: Wednesday, November 30, 2011 7:26 PM
> To: lucene-net-...@lucene.apache.org
> Subject: Re: [Lucene.Net] Re: Memory Leak in 2.9.2.2
>
>
>
> Trevor,
>
>
>
> I'm not sure if you can use 2.9.4, though, it looks like you're using
>
> VS2005 and .NET 2.0.  2.9.4 targets .NET 4.0, and I'm fairly certain we use
>
> classes only available in 4.0 (or 3.5?).  However, if you can, I would
>
> suggest updating, as 2.9.4 should be a fairly stable release.
>
>
>
> The leak I'm talking about is addressed here:
>
> https://issues.apache.org/jira/browse/LUCENE-2467, and the ported code
>
> isn't available in 2.9.2, but I've confirmed the patch is in 2.9.4.  It may
>
> or may not be what your issue is.  You say that it was at one time working
>
> fine, I assume you mean no memory leak.  I would take some time to see what
>
> else in your code has changed.  Make sure you're calling Close on whatever
>
> needs to be closed (IndexWriter/IndexReader/Analyzers, etc).
>
>
>
> Unfortunately for us, memory leaks are hard to debug over email, and it's
>
> difficult for us to tell if it's any change to your code or an issue with
>
> Lucene .NET.  As far as I can tell, this is the only memory leak I can find
>
> that affect

Re: [Lucene.Net] 3.0.3

[Christopher Currens]

There are a few patches that were made for 2.9.4 between when the 3.0.3
branch was forked from trunk and now that haven't been merged in.  It looks
like I branched it on Nov. 7th, so
LUCENENET-431, LUCENENET-433, LUCENENET-453, and LUCENENET-455 may or may
not be fixed, since that also largely depends on what was ported (that code
may be removed, or changed in the new version).

The Readme.txt, build.cmd line endings, and possibly the licence in
Contrib.SpellChecker.Test.nunit might need to be added as well.  I still
need to make Jira issues for quite a few things, regarding 3.0.3, since
right now what is left do to is only stated in a few scattered emails and
text files in the repository.  I was planning on doing that a few days ago,
but unfortunately life and work have gotten in the way.

So regarding merging 3.0.3 into trunk, I'd probably like to fix those
first.  I'm fine with merging 3.0.3 into trunk, though, I think a lot of it
is determined by our current AND long term goals.  It makes sense to throw
3.0.3 into trunk, but we're also already working on 4.0 in another branch.
 On top of that, our board report shows that we still want the existing
line-by-line port (which the 3.0.3 branch is), as well as a .NET idomatic
API which is also mentioned in our long term goals as not just an API, but
a new .NET version.

Now that we're finished with 2.x and we're in between versions, now is a
good time to talk about prioritizing our work.  An important point Stefan
brought up last week, was that we are all working on x number of branches
in parallel, instead of all working together to get releases pushed, of
course we can still have branches but we are all kinda doing our own thing,
I'm guilty of this as well.  We have a lot of goals, but there is seemingly
no priority for them (I realize current activities seems like a higher
priority than long term goals, but it just happened that way, and was never
discussed between all the committers).

What is more important?  The line-by-line port or the fully .NET-ified
version of Lucene?  Should we start on the .NET version now?  And what is
meant by .NET version?  Is it simply API differences or significant
internal changes, as well?  I'm not sure everyone has the same idea on
this, but it's *very* important we all do, and each way requires a
significantly different amount of work to accomplish.  Additionally, and
I'm being very frank about this, our goals of having a line-by-line port
*and* a .NET version may or may not be possible with the current number of
committers we have, considering the amount of time everyone has to give to
the project differs greatly by so many factors (I'm not trying to attack
anyone, it's just how life works, I wasn't as active as I could have been
on the project until fairly recently, and I'm having a little less time
than I had a few weeks ago).

I think it's important we discuss this and make sure everyone is on the
same page (it's possible we already are, and just haven't officially
documented it anywhere).  Then I think we can move forward as a group in
the project.


Thanks,
Christopher

On Thu, Dec 1, 2011 at 12:33 AM, Prescott Nasser wrote:

>
> With 2.9.4 out the door, do we merge 3.0.3 into the trunk? How do we want
> to handle this?

Re: [Lucene.Net] Merge 3.0.3 into trunk and other forward progress

[Christopher Currens]

Some fixes might already be in trunk, the 2.9.4g branch and even the 3.0.3
branch.  I can tell you that the code that the 3.0.3 branch was ported from
was the downloadable source, sometime around september/october and not
directly from SVN.  Assuming that Lucene's Jira is correct, then all issues
that have a fix version of 3.0.3, should already be ported in the 3.0.3
branch.  Of course, I'm not sure if Java lucene does revision versions to
fix other bugs (like if they have a 3.0.3.x version), so
I'm unfortunately in that same boat as you when it comes to knowing the
EXACT state of at least the 3.0.3 branch.  I've been meaning do diff the
source I've downloaded against whatever tag I can find, and hopefully get
some bearings on exactly what changeset that branch is at right now.

Thanks,
Christopher

On Thu, Dec 29, 2011 at 12:06 PM, Rory Plaire  wrote:

> Might some of these fixes already be in the Lucene.Net codebase? For
> example, when I looked at the subversion commits for
> https://issues.apache.org/jira/browse/LUCENE-2620 I found that the changes
> appear already in both the trunk and in the 2.9.4g branch. I'm not sure of
> the provenance of the current Lucene.Net codebase, and therefore how to
> interpret this finding.
> -r
> On Wed, Dec 28, 2011 at 10:46 PM, Prescott Nasser  >wrote:
>
> > Yeah that would work
> >
>

Re: [Lucene.Net] Lucene.Net 3 onwards and 2.9.4g

[Christopher Currens]

mplish Agenda Item #1, resume work on improving automation of
> >> > > > porting, creating scripts/tools/etc and document the process
> >> > > > 3. If having a different API for .NET is still part of our plan
> after
> >> > > > we accomplish Agenda Item #1, spec those API changes and
> associated
> >> > > > internal changes required and publish the spec
> >> > > >
> >> > > > And to drive home the point I made in my first sentence: If had
> >> > > > already accomplished those three agenda items, the time I just
> spent
> >> > > > typing this email could have been spent working on Lucene.Net. We
> need
> >> > > > to get to that point if we want to maintain any kind of
> development
> >> > > > velocity.
> >> > > >
> >> > > > Thanks,
> >> > > > Troy
> >> > > >
> >> > > >
> >> > > > On Thu, Dec 29, 2011 at 2:38 PM, Prescott Nasser <
> >> > geobmx...@hotmail.com>
> >> > > wrote:
> >> > > >> I dont think at the end of the day we want to make just cosmetic
> >> > > changes. We also have the issue of same name different casing which
> needs
> >> > > to be fixed - but it's not clear how to manage that without some
> large
> >> > > adjustments to the API.
> >> > > >>
> >> > > >>
> >> > > >>
> >> > > >> Sent from my Windows Phone
> >> > > >> 
> >> > > >> From: Troy Howard
> >> > > >> Sent: 12/29/2011 2:19 PM
> >> > > >> To: lucene-net-...@lucene.apache.org
> >> > > >> Subject: Re: [Lucene.Net] Lucene.Net 3 onwards and 2.9.4g
> >> > > >>
> >> > > >> My vote goes to merging the two:
> >> > > >>
> >> > > >> Apply the same concepts from 2.9.4g to 3.X development, using
> generics
> >> > > >> where possible, Disposable vs Close, and exposing *additional*
> APIs
> >> > > >> for generics (but leaving the existing old ones) to enable the
> >> > > >> underlying performance improvements the generics offer. Also,
> expose
> >> > > >> IEnumerable implementations vs Java style
> enumerables/iterators.
> >> > > >>
> >> > > >> If we are only adding to the existing and making relatively minor
> >> > > >> changes to enable generics, updating/maintenance should be
> relatively
> >> > > >> easy and it won't break anyone's code.
> >> > > >>
> >> > > >> Thanks,
> >> > > >> Troy
> >> > > >>
> >> > > >>
> >> > > >> On Thu, Dec 29, 2011 at 2:08 PM, Prescott Nasser <
> >> > geobmx...@hotmail.com>
> >> > > wrote:
> >> > > >>> I agree its a matter of taste. I'd vote continue with g and
> evolve it
> >> > > to where we want a .net version to be. What do others think?
> >> > > >>>
> >> > > >>> Sent from my Windows Phone
> >> > > >>> 
> >> > > >>> From: Digy
> >> > > >>> Sent: 12/29/2011 1:16 PM
> >> > > >>> To: lucene-net-...@lucene.apache.org
> >> > > >>> Subject: RE: [Lucene.Net] Lucene.Net 3 onwards and 2.9.4g
> >> > > >>>
> >> > > >>> When I started that "g" branch, I had no intention to change
> the API,
> >> > > but at
> >> > > >>> the end it resulted in a few changes
> >> > > >>> like StopAnalyzer(List stopWords),
> >> > > >>> Query.ExtractTerms(ICollection) etc.
> >> > > >>> But I think, a drop-in replacement will work for most of the
> >> > Lucene.Net
> >> > > >>> users (Of course some contribs have been also modified
> accordingly)
> >> > > >>>
> >> > > >>> Changing arraylists/collections with generic counterparts,
> >> > > GetEnumerator's
> >> > > >>> with foreach, AnonymousClass's with
> >> > > >>> Func<> or A

Re: how can I get the similarity in fuzzy query

[Christopher Currens]

I was going to post the link that Digy posted, which suggests not to
determine a match that way.  If my understanding is correct, the scores
returned for a query are relative to which documents were retrieved by the
search, in that if a document is deleted from the index, the scores will
change even though the query did not, because the number of returned
documents are different.

If the only thing you wanted to do was to calculate how a resulting string
was to a search string, I suggest the Levenshtein Distance algorithm
http://en.wikipedia.org/wiki/Levenshtein_distance...but it doesn't seem like
that's quite what you want to accomplish based on your question.

Christopher

On Wed, Feb 16, 2011 at 10:55 AM, Wen Gao  wrote:

> Hi,
> I am using FuzzyQuery to get fuzzy mathed results. I want to get the
> similarity in percent for every matched record.
> for example, if i search for "databasd", and it will return results such as
> "database", "database1", and "database11". I want to get the similarity in
> percent for evey record, such as 87.5%, 75%, and 62.5%.
>
> How can I do this?
>
> Any ideas?
>
> Wen Gao
>

Re: [Lucene.Net] [jira] Resolved: (LUCENENET-403) Improve site layout and design

[Christopher Currens]

The site does look great, I only have one concern and that is that is seems
we used bitbucket.org as our sole design inspiration.  I'm concerned that it
looks *too* much like the bitbucket site and that may cause problems in the
future.  I don't like having words and not backing it up without any
actions, so I would like to add to the design if that's alright with
everyone, I don't have anything now, but I can get something in the next few
days...I just need some time to think about the design.

Christopher

On Mon, Mar 7, 2011 at 5:59 AM, Michael Herndon  wrote:

> +1, Great Job Prescott.
>
> On Mon, Mar 7, 2011 at 3:44 AM, Glyn Darkin 
> wrote:
> > The site looks great.
> >
> > Well done!!!
> >
> > Glyn
> >
> > On 6 Mar 2011, at 23:04, Prescott Nasser (JIRA) wrote:
> >
> >>
> >> [
> https://issues.apache.org/jira/browse/LUCENENET-403?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel]
> >>
> >> Prescott Nasser resolved LUCENENET-403.
> >> ---
> >>
> >>Resolution: Fixed
> >>
> >> Latest Layout was voted upon and selected. Images were updated by Mike
> and I've moved it to staging:
> http://lucene.net.staging.apache.org/lucene.net/index.html.
> >>
> >>> Improve site layout and design
> >>> --
> >>>
> >>>Key: LUCENENET-403
> >>>URL:
> https://issues.apache.org/jira/browse/LUCENENET-403
> >>>Project: Lucene.Net
> >>> Issue Type: Sub-task
> >>> Components: Project Infrastructure
> >>>   Reporter: Troy Howard
> >>>   Assignee: Prescott Nasser
> >>>Fix For: Lucene.Net 2.9.2
> >>>
> >>>Attachments: layout1.zip, layout2.zip
> >>>
> >>>
> >>> Improve the website layout and design. Current staging design is based
> off an extremely simplistic implementation of Apache CMS basic template
> using the default Apache CMS CSS styling. Let's try to make it look better
> and have a more intuitive navigational structure.
> >>> See staging site at:
> >>> http://lucene.net.staging.apache.org/lucene.net/
> >>> To edit content, please use:
> >>> https://cms.apache.org/lucene.net/
> >>
> >> --
> >> This message is automatically generated by JIRA.
> >> For more information on JIRA, see:
> http://www.atlassian.com/software/jira
> >
> > Glyn Darkin
> >
> > Darkin Systems Ltd
> > Mob: 07961815649
> > Fax: 08717145065
> > Web: www.darkinsystems.com
> >
> > Company No: 6173001
> > VAT No: 906350835
> >
> >
> >
> >
> >
> >
>

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

[Christopher Currens (JIRA)]

[ 
https://issues.apache.org/jira/browse/LUCENENET-486?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13260708#comment-13260708
 ] 

Christopher Currens commented on LUCENENET-486:
---

I think this affects other languages more than it does English, well, at least 
it affects the German analyzer, since it does umlaut conversions.  While I 
don't think design change to Lucene.NET is necessary, it might be beneficial to 
expose the logic that converts umlauts in terms, so that developers can 
manually sanitize the terms in the query themselves (even overriding methods in 
QueryParser) so they can get the same behavior.  I think that might be a 
reasonable compromise, and only affects the GermanAnalyzer in Contrib.

> 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] [Commented] (LUCENENET-502) Recreate the missing files needed to build Lucene.Net.Distributed

[Christopher Currens (JIRA)]

[ 
https://issues.apache.org/jira/browse/LUCENENET-502?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13437984#comment-13437984
 ] 

Christopher Currens commented on LUCENENET-502:
---

I would put it in trunk and probably the 3.0.3 branch for people who want to 
experiment with it on a (more) stable branch, but I wouldn't release it.  I 
think that if there's a desire for this from the community that it be worked on 
and improved.  However, until we've updated it, added tests, and (possibly) 
updated the design, it should be source only for now.

> Recreate the missing files needed to build Lucene.Net.Distributed
> -
>
> Key: LUCENENET-502
> URL: https://issues.apache.org/jira/browse/LUCENENET-502
> Project: Lucene.Net
>  Issue Type: Improvement
>  Components: Lucene.Net Contrib
>Affects Versions: Lucene.Net 3.6
>Reporter: Zachary Gramana
>Priority: Minor
> Fix For: Lucene.Net 3.6
>
> Attachments: DistributedSearch.zip
>
>
> Zack Gramana - Recommend commit to trunk, and re-evaluate for 3.6 release.

--
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] [Resolved] (LUCENENET-464) The Lucene.Net.FastVectorHighligher.dll of the latest release 2.9.4 breaks any ASP.NET application

[Christopher Currens (JIRA)]

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

Christopher Currens resolved LUCENENET-464.
---

   Resolution: Fixed
Fix Version/s: Lucene.Net 3.0.3

Fixed in trunk.  Doesn't look like we'll be doing a hotfix, since contrib is 
now tied into the 3.x API.

> The Lucene.Net.FastVectorHighligher.dll of the latest release 2.9.4 breaks 
> any ASP.NET application
> --
>
> Key: LUCENENET-464
> URL: https://issues.apache.org/jira/browse/LUCENENET-464
> Project: Lucene.Net
>  Issue Type: Bug
>  Components: Lucene.Net Contrib
>Affects Versions: Lucene.Net 2.9.4
> Environment: Windows 7 64.bit System with ASP.NET 4.0 / C#
>Reporter: Jörg Lang
>  Labels: patch
> Fix For: Lucene.Net 3.0.3
>
>   Original Estimate: 1h
>  Remaining Estimate: 1h
>
> After I included Lucene and the Contrib modules via NuGet to my project, the 
> web application would not even start anymore.
> Before the first page was shown, I got the message I added at the end of this 
> text.
> By trial and error I found out, that when the 
> Lucene.Net.FastVectorHighligher.dll is deleted from the bin directory, the 
> application runs again.
> I then looked at the source code of Lucene.Net.FastVectorHighligher.dll and 
> found that in file support.cs the following code is located that causes the 
> problem.
> namespace System.Runtime.CompilerServices
> {
> [AttributeUsage(AttributeTargets.Method)]
> public sealed class ExtensionAttribute : Attribute
> {
> public ExtensionAttribute() { }
> }
> }
> After removing and recompiling the dll everything works, meaning my 
> application starts and also the highlighting is working correctly.
> It would be cool if this could be fixed in a patch or hotfix, so the NuGet 
> would deliver a corrected version.
> Regards
> Jörg
> Server Error in '/' Application.
> 
> Compilation Error 
> Description: An error occurred during the compilation of a resource required 
> to service this request. Please review the following specific error details 
> and modify your source code appropriately. 
> Compiler Error Message: BC30560: 'ExtensionAttribute' is ambiguous in the 
> namespace 'System.Runtime.CompilerServices'.
> Source Error:
>  
> [No relevant source lines]
>  
> Source File: InternalXmlHelper.vbLine: 9 
> Show Detailed Compiler Output:
> C:\Program Files (x86)\IIS Express> 
> "C:\Windows\Microsoft.NET\Framework\v4.0.30319\vbc.exe" /t:library 
> /utf8output 
> /R:"C:\Windows\assembly\GAC_MSIL\IKVM.OpenJDK.Util\0.46.0.1__13235d27fcbfff58\IKVM.OpenJDK.Util.dll"
>  /R:"C:\Users\jlang.EVELIX\AppData\Local\Temp\Temporary ASP.NET 
> Files\root\abef18a3\584f3aa\assembly\dl3\51d01989\a92a29aa_d2c4cc01\Lucene.Net.Contrib.Core.DLL"
>  
> /R:"C:\Windows\assembly\GAC_MSIL\IKVM.OpenJDK.Text\0.46.0.1__13235d27fcbfff58\IKVM.OpenJDK.Text.dll"
>  /R:"C:\Users\jlang.EVELIX\AppData\Local\Temp\Temporary ASP.NET 
> Files\root\abef18a3\584f3aa\assembly\dl3\74156559\d79ffad5_b7a2cc01\Xml.Schema.Linq.DLL"
>  /R:"C:\Users\jlang.EVELIX\AppData\Local\Temp\Temporary ASP.NET 
> Files\root\abef18a3\584f3aa\assembly\dl3\3a057033\005cb977_cb62ca01\DeepZoomTools.DLL"
>  /R:"C:\Users\jlang.EVELIX\AppData\Local\Temp\Temporary ASP.NET 
> Files\root\abef18a3\584f3aa\assembly\dl3\6b08d27a\eac1b816_1898cc01\Microsoft.Practices.ServiceLocation.DLL"
>  /R:"C:\Users\jlang.EVELIX\AppData\Local\Temp\Temporary ASP.NET 
> Files\root\abef18a3\584f3aa\assembly\dl3\2fe0a669\00eae495_b440cc01\Telerik.Windows.RadUploadHandler.DLL"
>  
> /R:"C:\Windows\assembly\GAC_MSIL\IKVM.OpenJDK.Core\0.46.0.1__13235d27fcbfff58\IKVM.OpenJDK.Core.dll"
>  
> /R:"C:\Windows\Microsoft.Net\assembly\GAC_32\System.Data\v4.0_4.0.0.0__b77a5c561934e089\System.Data.dll"
>  
> /R:"C:\Windows\Microsoft.Net\assembly\GAC_MSIL\System.ServiceModel.Web\v4.0_4.0.0.0__31bf3856ad364e35\System.ServiceModel.Web.dll"
>  /R:"C:\Users\jlang.EVELIX\AppData\Local\Temp\Temporary ASP.NET 
> Files\root\abef18a3\584f3aa\assembly\dl3\c2392a3f\9a92e9c6_95c0cc01\Microsoft.Practices.EnterpriseLibrary.Logging.DLL"
>  /R:"C:\Users\jlang.EVELIX\AppData\Local\Temp\Temporary ASP.NET 
> Files\root\abef18a3\584f3aa\assembly\dl3\b9daec08\db8bd216_1898cc01\Microsoft.

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

[Christopher Currens (JIRA)]

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

Christopher Currens resolved LUCENENET-445.
---

   Resolution: Fixed
Fix Version/s: Lucene.Net 3.0.3

I saw this fail when trunk was in 2.9, but not since trunk was merged with the 
3.x branch, clearly some change caused this test to now pass.  I this it's safe 
to close this issue.

> 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
> Fix For: Lucene.Net 3.0.3
>
>
> 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

[jira] [Resolved] (LUCENENET-487) Remove Obsolete Members, Fields that are marked as obsolete and to be removed in 3.0

[Christopher Currens (JIRA)]

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

Christopher Currens resolved LUCENENET-487.
---

   Resolution: Fixed
Fix Version/s: Lucene.Net 3.0.3

I did a quick search across the source in Lucene, and I think the LongParser 
and DoubleParser are the only two items in the entire source, marked obsoleted 
for removal in 3.0.  There is one other object that is marked Obsolete to be 
removed in 3.x, but it is still in the 3.0.3 java code.

I'm going to remove the obsolete attributes from those two interfaces listed, 
because of the differences of java and C# (not .NET), we can't match this API.  
Specifically, this reason is because even though Java and .NET allow static 
members and nested types (both static and instance types), it's invalid C# 
code, since it doesn't support it.

Either way, since we can't conform to the exact API that java does for the 
FieldCache, it wouldn't be a bad idea to clean it up.

> Remove Obsolete Members, Fields that are marked as obsolete and to be removed 
> in 3.0
> 
>
> Key: LUCENENET-487
> URL: https://issues.apache.org/jira/browse/LUCENENET-487
> Project: Lucene.Net
>  Issue Type: Task
>Affects Versions: Lucene.Net 3.0.3
>Reporter: Prescott Nasser
>Priority: Minor
> Fix For: Lucene.Net 3.0.3
>
>   Original Estimate: 24h
>  Remaining Estimate: 24h
>
> We have several places where things are marked as obsolete and to be removed 
> in 3.0. We should remove those. Also, care should be taken to comment what 
> was removed (and what should be used in it's place), so that we can have 
> complete and quality release notes.

--
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] [Commented] (LUCENENET-467) .NETify the public API where appropriate

[Christopher Currens (JIRA)]

[ 
https://issues.apache.org/jira/browse/LUCENENET-467?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13291130#comment-13291130
 ] 

Christopher Currens commented on LUCENENET-467:
---

Thanks.  Patch applied in revision 1347715

> .NETify the public API where appropriate
> 
>
> Key: LUCENENET-467
> URL: https://issues.apache.org/jira/browse/LUCENENET-467
> Project: Lucene.Net
>  Issue Type: Improvement
>  Components: Lucene.Net Contrib, Lucene.Net Core
>Affects Versions: Lucene.Net 2.9.2, Lucene.Net 2.9.4, Lucene.Net 2.9.4g, 
> Lucene.Net 3.0.3
> Environment: all
>    Reporter: Christopher Currens
>  Labels: refactoring
> Fix For: Lucene.Net 3.0.3
>
> Attachments: Lucenenet-467-create.patch
>
>
> Although we haven't abandoned the line-by-line port of Java lucene, there are 
> many idioms in Java that make little to no sense in a .NET assembly.  The API 
> can change to allow for a conventional .NET experience, while still 
> maintaining the ability and ease during the porting process of Java logic.
> * Change Getxxx() and Setxxx() methods to .NET Properties
> * Implement the [dispose 
> pattern|http://msdn.microsoft.com/en-us/library/fs2xkftw.aspx] properly.  
> Try, at all costs, to only use finalizers *when necessary*.  They are 
> expensive, and most of the classes used already have finalizers that will be 
> called.
> * Convert Java Iterator-style classes (see TermEnum, TermDocs and others) to 
> implement IEnumerable
> * When catching exceptions, do not use *throw;* instead of *throw ex;* to 
> maintain the stack trace

--
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] [Created] (LUCENENET-495) Use of DateTime.Now causes huge amount of System.Globalization.DaylightTime object allocations

[Christopher Currens (JIRA)]

Christopher Currens created LUCENENET-495:
-

 Summary: Use of DateTime.Now causes huge amount of 
System.Globalization.DaylightTime object allocations
 Key: LUCENENET-495
 URL: https://issues.apache.org/jira/browse/LUCENENET-495
 Project: Lucene.Net
  Issue Type: Bug
  Components: Lucene.Net Core
Affects Versions: Lucene.Net 2.9.4, Lucene.Net 3.0.3
Reporter: Christopher Currens
Assignee: Christopher Currens
Priority: Critical
 Fix For: Lucene.Net 3.0.3


This issue mostly just affects RAMDirectory.  However, RAMFile and 
RAMOutputStream are used in other (all?) directory implementations, including 
FSDirectory types.

In RAMOutputStream, the file last modified property for the RAMFile is updated 
when the stream is flushed.  It's calculated using {{DateTime.Now.Ticks / 
TimeSpan.TicksPerMillisecond}}.  I've read before that Microsoft has regretted 
making DateTime.Now a property instead of a method, and after seeing what it's 
doing, I'm starting to understand why.  DateTime.Now is returning local time.  
In order for it to calculate that, it has to get the utf offset for the 
machine, which requires the creation of a _class_, 
System.Globalization.DaylightTime.  This is bad for performance.

Using code to write 10,000 small documents to an index (4kb sizes), it created 
1,570,157 of these DaylightTime classes, a total of 62MB of extra 
memory...clearly RAMOutputStream.Flush() is called a lot.

A fix I'd like to propose is to change the RAMFile from storing the 
LastModified date to UTC instead of local.  DateTime.UtcNow doesn't create any 
additional objects and is very fast.  For this small benchmark, the performance 
increase is 31%.

I've set it to convert to local-time, when {{RAMDirectory.LastModified(string 
name)}} is called to make sure it has the same behavior (tests fail otherwise). 
 Are there any other side-effects to making this change?

--
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-337) TokenAttribute for Selectively Including Tokens in Length Norm

[Christopher Currens (JIRA)]

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

Christopher Currens updated LUCENENET-337:
--

Affects Version/s: (was: Lucene.Net 2.9.2)
Fix Version/s: (was: Lucene.Net 3.0.3)
   Lucene.Net 3.6

Moving to 3.6.  We need to evaluate community desire for this patch.

> TokenAttribute for Selectively Including Tokens in Length Norm
> --
>
> Key: LUCENENET-337
> URL: https://issues.apache.org/jira/browse/LUCENENET-337
> Project: Lucene.Net
>  Issue Type: Improvement
>  Components: Lucene.Net Core
>Reporter: Michael Garski
>Priority: Minor
> Fix For: Lucene.Net 3.6
>
> Attachments: LengthNorm.patch
>
>
> This patch adds functionality to Lucene.Net that allow a TokenFilter to mark 
> a Token as not to be included in the length norm calculation through the use 
> of a new TokenAttribute interface LengthNormAttribute and a corresponding 
> implementation LengthNormAttributeImpl.  This functionality is useful to 
> prevent the increase of the length norm during synonym injection, 
> particularly in cases where there are a large number of synonyms in relation 
> to the number of original tokens.
> Following is an example of how to use the new attribute.
> Within your custom TokenFilter, define a field to persist a reference to the 
> attribute and set it's value in the constructor.  When a the stream advances 
> to a new Token within the call to IncrementToken() the value of the 
> IncludeInLengthNorm property of the attribute is set to false for Tokens 
> which should not be included in the length norm calculation.  It defaults to 
> true and is reset to true after each Token is consumed within 
> DocInverterPerField.ProcessFields.
> {code:title=CustomTokenFilter.cs|borderStyle=solid}
> public class CustomTokenFilter : TokenFilter
> {
>   private LengthNormAttribute lnAttribute;
>   
>   public CustomTokenFilter(TokenStream input) : base(input)
>   {
>   this.lnAttribute = 
> (LengthNormAttribute)AddAttribute(typeof(LengthNormAttribute));
>   }
>   
>   public override bool IncrementToken()
>   {
>   if (input.IncrementToken())
>   {
>   // make determination that the token is not to be 
>   // included in the length norm value
>   // this example marks all tokens to not be 
>   // included in the length norm value
>   this.lnAttribute.IncludeInLengthNorm = false;
>   return true;
>   }
>   else
>   {
>   return false;
>   }
>   }
> }
> {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] [Commented] (LUCENENET-421) Segment files ocasionaly disappearing making index corrupted

[Christopher Currens (JIRA)]

[ 
https://issues.apache.org/jira/browse/LUCENENET-421?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13417213#comment-13417213
 ] 

Christopher Currens commented on LUCENENET-421:
---

Can you reproduce the issue in 2.9.4 or trunk?

> Segment files ocasionaly disappearing making index corrupted
> 
>
> Key: LUCENENET-421
> URL: https://issues.apache.org/jira/browse/LUCENENET-421
> Project: Lucene.Net
>  Issue Type: Bug
>  Components: Lucene.Net Core
>Affects Versions: Lucene.Net 2.9.2
> Environment: Media Chase ECF50 in the MastermindToys.com online toy 
> store, IIS 7 under Win 2008 R2, index on RAID 1
>Reporter: Fedor Taiakin
>
> IIS 7 under Win 2008 R2, index located on RAID 1
> The only operations Add Document and Delete Document, optimize = false.
> Ocasionally the segment files disappear, corrupting index. No other 
> exceptions prior to inability to open index:
> 'C:\Projects\MMT\ECF50\main\src\PublicLayer\SearchIndex\eCommerceFramework\CatalogEntryIndexer\_b6k.cfs'."
>  ---> System.IO.FileNotFoundException: Could not find file 
> 'C:\Projects\MMT\ECF50\main\src\PublicLayer\SearchIndex\eCommerceFramework\CatalogEntryIndexer\_b6k.cfs'.
> File name: 
> 'C:\Projects\MMT\ECF50\main\src\PublicLayer\SearchIndex\eCommerceFramework\CatalogEntryIndexer\_b6k.cfs'
>at Lucene.Net.Index.SegmentInfos.FindSegmentsFile.Run()
>at Lucene.Net.Index.IndexReader.Open(Directory directory)

--
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] [Commented] (PYLUCENE-9) QueryParser replacing stop words with wildcards

[Christopher Currens (JIRA)]

[ 
https://issues.apache.org/jira/browse/PYLUCENE-9?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13031284#comment-13031284
 ] 

Christopher Currens commented on PYLUCENE-9:


Hmm, the code I have is nearly identical, and when I pull it out of the 
contained code, it behaves as it should.  I can't post the whole code, but the 
issue must be that there's a lingering Version.LUCENE_24 somewhere I suppose.  
I'll try figuring it out on my own, I'm glad to see its something idiotic I've 
done. :)

> QueryParser replacing stop words with wildcards
> ---
>
> Key: PYLUCENE-9
> URL: https://issues.apache.org/jira/browse/PYLUCENE-9
> Project: PyLucene
>  Issue Type: Bug
> Environment: Windows XP 32-bit Sp3, Ubuntu 10.04.2 LTS i686 
> GNU/Linux, jdk1.6.0_23
>Reporter: Christopher Currens
>
> Was using query parser to build a query.  In Java Lucene (as well as 
> Lucene.Net), the query "Calendar Item as Msg" (quotes included), is parsed 
> properly as FullText:"calendar item msg" in Java Lucene and Lucene.Net.  In 
> pylucene, it is parsed as: FullText:"calendar item ? msg".  This causes 
> obvious problems when comparing search results from python, java and .net.
> Initially, I thought it was the Analyzer I was using, but I've tried the 
> StandardAnalyzer and StopAnalyzer, which work properly in Java and .Net, but 
> not pylucene.
> Here is code I've used to reproduce the issue:
> >>> from lucene import StandardAnalyzer, StopAnalyzer, QueryParser, Version
> >>> analyzer = StandardAnalyzer(Version.LUCENE_30)
> >>> query = QueryParser(Version.LUCENE_30, "FullText", analyzer)
> >>> parsedQuery = query.parse("\"Calendar Item as Msg\"")
> >>> parsedQuery
> 
> >>> analyzer = StopAnalyzer(Version.LUCENE_30)
> >>> query = QueryParser(Version.LUCENE_30)
> >>> parsedQuery = query.parse("\"Calendar Item as Msg\"")
> >>> parsedQuery
> 
> I've noticed this in pylucene 2.9.4, 2.9.3, and 3.0.3

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Commented] (PYLUCENE-9) QueryParser replacing stop words with wildcards

[Christopher Currens (JIRA)]

[ 
https://issues.apache.org/jira/browse/PYLUCENE-9?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13034961#comment-13034961
 ] 

Christopher Currens commented on PYLUCENE-9:


We can close it.  Thanks for the help.

> QueryParser replacing stop words with wildcards
> ---
>
> Key: PYLUCENE-9
> URL: https://issues.apache.org/jira/browse/PYLUCENE-9
> Project: PyLucene
>  Issue Type: Bug
> Environment: Windows XP 32-bit Sp3, Ubuntu 10.04.2 LTS i686 
> GNU/Linux, jdk1.6.0_23
>    Reporter: Christopher Currens
>
> Was using query parser to build a query.  In Java Lucene (as well as 
> Lucene.Net), the query "Calendar Item as Msg" (quotes included), is parsed 
> properly as FullText:"calendar item msg" in Java Lucene and Lucene.Net.  In 
> pylucene, it is parsed as: FullText:"calendar item ? msg".  This causes 
> obvious problems when comparing search results from python, java and .net.
> Initially, I thought it was the Analyzer I was using, but I've tried the 
> StandardAnalyzer and StopAnalyzer, which work properly in Java and .Net, but 
> not pylucene.
> Here is code I've used to reproduce the issue:
> >>> from lucene import StandardAnalyzer, StopAnalyzer, QueryParser, Version
> >>> analyzer = StandardAnalyzer(Version.LUCENE_30)
> >>> query = QueryParser(Version.LUCENE_30, "FullText", analyzer)
> >>> parsedQuery = query.parse("\"Calendar Item as Msg\"")
> >>> parsedQuery
> 
> >>> analyzer = StopAnalyzer(Version.LUCENE_30)
> >>> query = QueryParser(Version.LUCENE_30)
> >>> parsedQuery = query.parse("\"Calendar Item as Msg\"")
> >>> parsedQuery
> 
> I've noticed this in pylucene 2.9.4, 2.9.3, and 3.0.3

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

[Lucene.Net] [jira] [Commented] (LUCENENET-425) MMapDirectory implementation

[Christopher Currens (JIRA)]

[ 
https://issues.apache.org/jira/browse/LUCENENET-425?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13049359#comment-13049359
 ] 

Christopher Currens commented on LUCENENET-425:
---

On a 1.18GB index of only text:

FS Reader: 27
MMap Reader: 90
---
FS Reader: 38
MMap Reader: 77
Press any key to continue . . .

> MMapDirectory implementation
> 
>
> Key: LUCENENET-425
> URL: https://issues.apache.org/jira/browse/LUCENENET-425
> Project: Lucene.Net
>  Issue Type: New Feature
>Affects Versions: Lucene.Net 2.9.4g
>Reporter: Digy
>Priority: Trivial
> Fix For: Lucene.Net 2.9.4g
>
> Attachments: MMapDirectory.patch
>
>
> Since this is not a direct port of MMapDirectory.java, I'll put it under 
> "Support" and implement MMapDirectory as 
> {code}
> public class MMapDirectory:Lucene.Net.Support.MemoryMappedDirectory
> {
> }
> {code}
> If a Mem-Map can not be created(for ex, if the file is too big to fit in 32 
> bit address range), it will default to FSDirectory.FSIndexInput
> In my tests, I didn't see any performance gain in 32bit environment and I 
> consider it as better then nothing. 
> I would be happy if someone could send test results on 64bit platform.
> DIGY

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

[Lucene.Net] [jira] [Updated] (LUCENENET-425) MMapDirectory implementation

[Christopher Currens (JIRA)]

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

Christopher Currens updated LUCENENET-425:
--

Comment: was deleted

(was: On a 1.18GB index of only text:

FS Reader: 27
MMap Reader: 90
---
FS Reader: 38
MMap Reader: 77
Press any key to continue . . .)

> MMapDirectory implementation
> 
>
> Key: LUCENENET-425
> URL: https://issues.apache.org/jira/browse/LUCENENET-425
> Project: Lucene.Net
>  Issue Type: New Feature
>Affects Versions: Lucene.Net 2.9.4g
>Reporter: Digy
>Priority: Trivial
> Fix For: Lucene.Net 2.9.4g
>
> Attachments: MMapDirectory.patch
>
>
> Since this is not a direct port of MMapDirectory.java, I'll put it under 
> "Support" and implement MMapDirectory as 
> {code}
> public class MMapDirectory:Lucene.Net.Support.MemoryMappedDirectory
> {
> }
> {code}
> If a Mem-Map can not be created(for ex, if the file is too big to fit in 32 
> bit address range), it will default to FSDirectory.FSIndexInput
> In my tests, I didn't see any performance gain in 32bit environment and I 
> consider it as better then nothing. 
> I would be happy if someone could send test results on 64bit platform.
> DIGY

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Updated] (LUCENENET-481) Port Contrib.MemoryIndex

[Christopher Currens (Updated) (JIRA)]

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

Christopher Currens updated LUCENENET-481:
--

Fix Version/s: Lucene.Net 3.0.3

> Port Contrib.MemoryIndex
> 
>
> Key: LUCENENET-481
> URL: https://issues.apache.org/jira/browse/LUCENENET-481
> Project: Lucene.Net
>  Issue Type: New Feature
>Affects Versions: Lucene.Net 3.0.3
>    Reporter: Christopher Currens
> Fix For: Lucene.Net 3.0.3
>
>
> We need to port MemoryIndex from contrib, if we want to be able to port a few 
> other contrib libraries.

--
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] [Assigned] (LUCENENET-463) Would like to be able to use a SimpleSpanFragmenter for extrcting whole sentances

[Christopher Currens (Assigned) (JIRA)]

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

Christopher Currens reassigned LUCENENET-463:
-

Assignee: Christopher Currens

> 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
>    Assignee: Christopher Currens
>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

[jira] [Resolved] (LUCENENET-468) Implement the Dispose pattern properly in classes with Close

[Christopher Currens (Resolved) (JIRA)]

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

Christopher Currens resolved LUCENENET-468.
---

Resolution: Fixed

I'm closing this as fixed.  All types that implement Close now implement the 
Dispose pattern properly.  However, not all references to Close() have been 
replaced with Dispose().  I don't think that should block this issue from being 
close (or block a release).  It would be easiest to remove these references 
when Close() is removed in the future.

> 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 2.9.4g, 
> Lucene.Net 3.0.3
>     Environment: all
>Reporter: Christopher Currens
> Fix For: Lucene.Net 3.0.3
>
>  Time Spent: 1m
>  Remaining Estimate: 0h
>
> 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

[jira] [Commented] (LUCENENET-470) Change Getxxx() and Setxxx() methods to .NET Properties

[Christopher Currens (Commented) (JIRA)]

[ 
https://issues.apache.org/jira/browse/LUCENENET-470?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13253542#comment-13253542
 ] 

Christopher Currens commented on LUCENENET-470:
---

Thanks for the feedback, Itamar.  I'm hoping soon to get feedback from others 
in the community soon, I think Michael is on his way to start promoting it.  I 
suppose whatever feedback we get from the majority will shape what we decide to 
do with it.

That being said, it would be good to record the progress of this issue here.  
It's so close to being done, there are only a few other methods I'd like to 
convert to properties.  I think in some of the attributes there are methods 
like {{public string Term()}}, which are ideal candidates for property 
conversion.

> Change Getxxx() and Setxxx() methods to .NET Properties
> ---
>
> Key: LUCENENET-470
> URL: https://issues.apache.org/jira/browse/LUCENENET-470
> Project: Lucene.Net
>  Issue Type: Sub-task
>  Components: Lucene.Net Contrib, Lucene.Net Core
>Affects Versions: Lucene.Net 2.9.4, Lucene.Net 2.9.4g, Lucene.Net 3.0.3
> Environment: all
>Reporter: Christopher Currens
> Fix For: Lucene.Net 3.0.3
>
>
> We should use .NET properties where ever possible.  There are many methods in 
> the API that use methods similar to {{Class.Getx()}} or 
> {{Class.Setx()}}.  These methods often just return a less-accessible 
> field, with no real logic behind it.
> * If there are both public Get/Set methods with no special logic, they can be 
> turned into an automatic property: Name { get; set; }
> * If there are both Get/Set methods with no special logic and the setter is 
> private, use an automatic property: Name { get; private set; }
> * In other cases, use good judgement based with the amount of logic that is 
> present in the getter and setter methods.

--
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] [Commented] (LUCENENET-446) Make Lucene.Net CLS Compliant

[Christopher Currens (Commented) (JIRA)]

[ 
https://issues.apache.org/jira/browse/LUCENENET-446?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13253598#comment-13253598
 ] 

Christopher Currens commented on LUCENENET-446:
---

So, I've been using VS11 for all my development lately (it's ridiculously 
faster than VS2010).  One of the great new features is that you can quickly and 
easily search through the Error List and find warnings you actually care about 
(we have 1700 warnings in Lucene.NET).

If you do a search for CLS, you'll find we only have 53 violations!  This is 
great news, because it means that we are getting ever closer to fixing this 
issue.

However, here's the issue we need to address, that is not so simple.  Of 
course, the main issue we have with CLS Compliance is having identifiers only 
differing in case.  This is due in part to LUCENENET-468, where some properties 
now have the same name differing only in case with protected internal fields.

Now, in many cases, this isn't an issue, since you can just turn it into an 
automatic property, where the setter is protected internal.  However, my guts 
tells me it's not okay to do with properties that are virtual.  So, how can we 
solve this?  It seems we need to change the name of one of them, and prefixing 
the field with an underscore is not only the wrong naming style, it's actually 
not CLS compliant.

Any thoughts?

> 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

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

[Christopher Currens (Created) (JIRA)]

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


{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-485) IndexOutOfRangeException in FrenchStemmer

[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: tt.diff

The diff doesn't specify files, but should be easy to figure out.

> 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: 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] [Resolved] (LUCENENET-54) ArgumentOurOfRangeException caused by SF.Snowball.Ext.DanishStemmer

[Christopher Currens (Resolved) (JIRA)]

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

Christopher Currens resolved LUCENENET-54.
--

Resolution: Fixed

> ArgumentOurOfRangeException caused by SF.Snowball.Ext.DanishStemmer
> ---
>
> Key: LUCENENET-54
> URL: https://issues.apache.org/jira/browse/LUCENENET-54
> Project: Lucene.Net
>  Issue Type: Bug
>Affects Versions: Lucene.Net 2.9.4, Lucene.Net 2.9.4g, Lucene.Net 3.0.3
> Environment: Windows XP SP2, lucene.net v2.0 004
>Reporter: Torsten Rendelmann
>Priority: Critical
> Fix For: Lucene.Net 3.0.3
>
>
> Exception Information
> System.SystemException: System.Reflection.TargetInvocationException: 
> Exception has been thrown by the target of an invocation. ---> 
> System.ArgumentOutOfRangeException: Index and length must refer to a location 
> within the string.
> Parameter name: length
>at System.String.Substring(Int32 startIndex, Int32 length)
>at System.Text.StringBuilder.ToString(Int32 startIndex, Int32 length)
>at SF.Snowball.SnowballProgram.slice_to(StringBuilder s)
>at SF.Snowball.Ext.DanishStemmer.r_undouble()
>at SF.Snowball.Ext.DanishStemmer.Stem()
>--- End of inner exception stack trace ---
>at System.Reflection.RuntimeMethodInfo.InternalInvoke(Object obj, 
> BindingFlags invokeAttr, Binder binder, Object[] parameters, CultureInfo 
> culture, Boolean isBinderDefault, Assembly caller, Boolean verifyAccess)
>at System.Reflection.RuntimeMethodInfo.InternalInvoke(Object obj, 
> BindingFlags invokeAttr, Binder binder, Object[] parameters, CultureInfo 
> culture, Boolean verifyAccess)
>at System.Reflection.RuntimeMethodInfo.Invoke(Object obj, BindingFlags 
> invokeAttr, Binder binder, Object[] parameters, CultureInfo culture)
>at System.Reflection.MethodBase.Invoke(Object obj, Object[] parameters)
>at System.Reflection.MethodInfo.Invoke(Object obj, Object[] parameters)
>at Lucene.Net.Analysis.Snowball.SnowballFilter.Next()
>at Lucene.Net.Analysis.Snowball.SnowballFilter.Next()
>at Lucene.Net.Index.DocumentWriter.InvertDocument(Document doc)
>at Lucene.Net.Index.DocumentWriter.AddDocument(String segment, Document 
> doc)
>at Lucene.Net.Index.IndexWriter.AddDocument(Document doc, Analyzer 
> analyzer)

--
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] [Resolved] (LUCENENET-475) DanishStemmer doesn't work.

[Christopher Currens (Resolved) (JIRA)]

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

Christopher Currens resolved LUCENENET-475.
---

   Resolution: Fixed
Fix Version/s: Lucene.Net 3.0.3

This has already been fixed in trunk.  Contrib was largely forgotten about in 
past released, though this has changed during the development of 3.x.

> 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
> Fix For: Lucene.Net 3.0.3
>
>
> 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

[jira] [Resolved] (LUCENENET-474) Missing License Headers in trunk after 3.0.3 merge

[Christopher Currens (Resolved) (JIRA)]

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

Christopher Currens resolved LUCENENET-474.
---

Resolution: Fixed

Committed patch.  Everything compiles and tests pass as normal.

> 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

[jira] [Commented] (LUCENENET-167) Compact Framework & Silverlight Support

[Christopher Currens (Commented) (JIRA)]

[ 
https://issues.apache.org/jira/browse/LUCENENET-167?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13228713#comment-13228713
 ] 

Christopher Currens commented on LUCENENET-167:
---

It's still on our list of things to do.  It will be very difficult to 
accomplish, and to be frank, we don't have enough committers to pull it off at 
this point.  Lucene core (I don't even want to look at the contrib) has 500 
errors if you try to compile it using the Portable Class Library tools in VS11 
or the VS2010 extensions.  There's actually far more than that, since VS tends 
to stop parsing files for certain errors.  Some of the things are easier than 
others, for example, the Serializable attribute isn't supported in Silverlight, 
but we can easily wrap that in a preprocessor conditional (*shudder*).  The 
more difficult things to handle would be IClonable (it's used EVERYWHERE), the 
lack of HashSet, everything related to file system information, and other 
things.

If we had more committers, we could get this done quicker once we've done a bit 
of planning.  It *will* eventually happen, as to when however, that's very much 
up in the air.

> Compact Framework & Silverlight Support
> ---
>
> Key: LUCENENET-167
> URL: https://issues.apache.org/jira/browse/LUCENENET-167
> Project: Lucene.Net
>  Issue Type: Wish
>  Components: Lucene.Net Contrib, Lucene.Net Core, Lucene.Net Demo, 
> Lucene.Net Test
>Reporter: Andrew C. Smith
>Priority: Minor
>  Labels: silverlight
>
> Lucene.Net should support the Compact Framework & Silverlight versions of the 
> .NET Framework.
> I've looked into what it might take to do this and most of it is pretty 
> trivial to be able to support these frameworks. Most of what this would take 
> is just changing the different type of classes to use for collection classes 
> used inside of Lucene.Net. 
> This does require changing some details in a lot of places, However this 
> should *not* bring any compatibility issues with *Java Lucene*'s API or index 
> format. It will just change the classes used to some different ones that the 
> frameworks support and also maybe need 1 to 3 classes that might need to be 
> implemented in Lucene.net itself.
> Having made these changes Lucene.Net can be more available to new devices 
> such as running on a window mobile cell phone, or your pda, or run in a 
> Windows, Linux, or Mac computer that runs a silverlight application. This 
> will allow the .Net compact framework & silverlight developers to use 
> Lucene.Net in their applications to provide their users with the same 
> capabilities of an awesome search framework. Developers can also use 
> Lucene.Net to provide them spell checking capabilities in these environments. 

--
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] [Closed] (LUCENENET-465) Error indexing a document end Filed.Store.COMPRESS

[Christopher Currens (Closed) (JIRA)]

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

Christopher Currens closed LUCENENET-465.
-

Resolution: Cannot Reproduce

I can't reproduce this problem, and there's been a month and a half of silence 
on the issue.  If there's still a problem, we can reopen this later.

> Error indexing a document end Filed.Store.COMPRESS
> --
>
> Key: LUCENENET-465
> URL: https://issues.apache.org/jira/browse/LUCENENET-465
> Project: Lucene.Net
>  Issue Type: Bug
>  Components: .NET API
>Affects Versions: Lucene.Net 2.9.4
> Environment: Windows 7 x64 Professional, Visual Studio 2010 Ultimate 
> SP1, .NET 4.0, Lucene.net 2.9.4.1, SharpZipLib 0.86.0.518
>Reporter: João Rosa
>Priority: Blocker
>  Labels: lucene
> Fix For: Lucene.Net 2.9.4
>
>
> I'm developing a index, and need to store values compressed, because its 
> needed to show that info to the user.
> I've the current error: "Can not load ICSharpCode.SharpZipLib.dll", when I do 
> the "writer.AddDocument(doc);"
> The DLLs are from NuGet.
> Snippet:
>  //retirar o directório
> System.IO.DirectoryInfo directoryInfo = new 
> System.IO.DirectoryInfo(path);
> //criar o directório para o lucene
> Directory directory = FSDirectory.Open(directoryInfo);
> //instanciar o analyser
> Analyzer analyzer = new SnowballAnalyzer("Portuguese");
> //abrir o indíce
> bool isNew = !IndexReader.IndexExists(directory);
> IndexWriter writer = new IndexWriter(directory, analyzer, 
> isNew, Lucene.Net.Index.IndexWriter.MaxFieldLength.UNLIMITED);
> //gravar o documento
> Document doc = new Document();
> NumericField numericField = new NumericField("id", 
> Field.Store.YES, false);
> numericField.SetIntValue(id);
> doc.Add(numericField);
> Field field = new Field("title", title, Field.Store.COMPRESS, 
> Field.Index.ANALYZED);
> field.SetBoost(7);
> doc.Add(field);
> field = new Field("description", tescription, 
> Field.Store.COMPRESS, Field.Index.ANALYZED);
> doc.Add(field);
> writer.AddDocument(doc);
> writer.Optimize();
> //Close the writer
> writer.Commit();
> writer.Close();
> }
> catch (Exception ex)
> {
> throw ex;
> }

--
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] [Resolved] (LUCENENET-477) NullReferenceException in ThreadLocal when Lucene.Net compiled for .Net 2.0

[Christopher Currens (Resolved) (JIRA)]

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

Christopher Currens resolved LUCENENET-477.
---

   Resolution: Fixed
Fix Version/s: Lucene.Net 3.0.3

Thanks for the patch.  It's been applied to trunk for version 3.0.3.

> 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
> Fix For: Lucene.Net 3.0.3
>
> 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] [Closed] (LUCENENET-179) SnowballFilter speed improvment

[Christopher Currens (Closed) (JIRA)]

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

Christopher Currens closed LUCENENET-179.
-

Resolution: Invalid

It's been so long since this patch was submitted (2009), that it's no longer 
needed.  The new version of the SnowballFilter from 3.0.3 only uses reflection 
in the constructor to create the filter (as does the patch).  It's too bad this 
didn't make it into 2.9.4, where it could have really been used.

> 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

[jira] [Closed] (LUCENENET-372) NLS pack for Lucene.NET: BR, CJK, CN, CZ, DE, FR, NL, RU analyzers

[Christopher Currens (Closed) (JIRA)]

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

Christopher Currens closed LUCENENET-372.
-

Resolution: Won't Fix
  Assignee: (was: Prescott Nasser)

We're not doing a separate contrib release for these, and it's already ported 
into 3.0.3.  Closing issue as won't fix.  

I apologize that this didn't make it into the official release of 2.9.4.  I 
hope this doesn't discourage you from contributing in the future.

> NLS pack for Lucene.NET: BR, CJK, CN, CZ, DE, FR, NL, RU analyzers
> --
>
> Key: LUCENENET-372
> URL: https://issues.apache.org/jira/browse/LUCENENET-372
> Project: Lucene.Net
>  Issue Type: New Feature
>  Components: Lucene.Net Contrib
>Reporter: Pasha Bizhan
>Priority: Minor
>  Labels: Analyzers
> Attachments: lucene-net-nls.zip
>
>
> Port of java analyzers. Sorry for 1.4 version, it's from 2005 year
> Update to 2.9.2/2.9.4 compatibility for 2.9.4 release. 

--
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] [Commented] (LUCENENET-466) optimisation for the GermanStemmer.vb‏

[Christopher Currens (Commented) (JIRA)]

[ 
https://issues.apache.org/jira/browse/LUCENENET-466?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13235915#comment-13235915
 ] 

Christopher Currens commented on LUCENENET-466:
---

Since both DIN-5007-1 and DIN-5007-2 are both valid ways of sorting they should 
probably both be included as an option.  DIN-5007-1 is used for words, and is 
the current version of the GermanStemmer class.  DIN-5007-2 is a special 
sorting for lists of names (phone book sorting).  Either way, I can see where 
it could be beneficial to have both.  Since I don't want to diverge from the 
Java stemmer too much, I think it should probably just be an additional 
constructor on the GermanAnalyzer class that would allow you to pass a bool if 
you want to use DIN-5007-2.


For reference:

||Letter||DIN-5007-1||DIN5007-2||
|ä|a|ae|
|ö|o|oe|
|ü|u|ue|
|ß|ss|ss|

> optimisation for the GermanStemmer.vb‏
> --
>
> Key: LUCENENET-466
> URL: https://issues.apache.org/jira/browse/LUCENENET-466
> Project: Lucene.Net
>  Issue Type: Improvement
>  Components: Lucene.Net Contrib
>Affects Versions: Lucene.Net 2.9.4, Lucene.Net 2.9.4g, Lucene.Net 3.0.3
>Reporter: Prescott Nasser
>Priority: Minor
> Fix For: Lucene.Net 3.0.3
>
>
> I have a little optimisation for the GermanStemmer.vb (in 
> Contrib.Analyzers) class. At the moment the function "Substitute" 
> converts the german "Umlaute" "ä" in "a", "ö" in"o" and "ü" in "u". This 
> is not the correct german translation. They must be converted to "ae", 
> "oe" and "ue". So I can write the name "Björn" or "Bjoern" but not 
> "Bjorn". With this optimization a user can search for "Björn" and also 
> find "Bjoern".
>  
> Here is the optimized code snippet:
>  
> else if ( buffer[c] == 'ä' )
>  {
>  buffer[c] = 'a';
>  buffer.Insert(c + 1, 'e');
>  }
>  else if ( buffer[c] == 'ö' )
>  {
>  buffer[c] = 'o';
>  buffer.Insert(c + 1,'e');
>  }
>  else if ( buffer[c] == 'ü' )
>  {
>  buffer[c] = 'u';
>  buffer.Insert(c + 1,'e');
>  }
>  
> Thank You
> Björn

--
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] [Created] (LUCENENET-478) Parts of QueryParser are outdated or weren't previously ported correctly

[Christopher Currens (Created) (JIRA)]

Parts of QueryParser are outdated or weren't previously ported correctly


 Key: LUCENENET-478
 URL: https://issues.apache.org/jira/browse/LUCENENET-478
 Project: Lucene.Net
  Issue Type: Bug
  Components: Lucene.Net Core
Affects Versions: Lucene.Net 2.9.4g, Lucene.Net 2.9.4
Reporter: Christopher Currens
Priority: Blocker
 Fix For: Lucene.Net 3.0.3


Parts of the QueryParser class are _very_ old.  I'm not sure exactly how much 
of it is old or hasn't even been ported, but I can say this probably has some 
effect on how the parser differs from the java version.  I'm not sure about 
exact behavior differences, but this needs to be ported from scratch again to 
make sure that it's on par with Java's queryparser.

--
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-462) Spatial Search skipping records with small radius e.g. 1 mile

[Christopher Currens (Updated) (JIRA)]

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

Christopher Currens updated LUCENENET-462:
--

Description: 
Running a spatial query against a list of locations all within 1 mile of a 
location returns correct results for 2 miles, but incorrect results for 1 mile. 
For the one mile query, only 2 of the 8 rows are returned. 

Locations & Test below:
{code}

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

// Locations
AddPoint(writer, "Location 1", 51.5073802128877, -0.124669075012207);
AddPoint(writer, "Location 2", 51.5091, -0.1235);
AddPoint(writer, "Location 3", 51.5093, -0.1232);
AddPoint(writer, "Location 4", 51.5112531582845, -0.12509822845459);
AddPoint(writer, "Location 5", 51.5107, -0.123);
AddPoint(writer, "Location 6", 51.512, -0.1246);
AddPoint(writer, "Location 8", 51.5088760101322, -0.143165588378906);
AddPoint(writer, "Location 9", 51.5087958793819, -0.143508911132813);
{code}
{code}
[Test]
public void TestAntiM()
{
_searcher = new IndexSearcher(_directory, true);

const double miles = 1.0; // Bug? Only returns 2 locations. Should 
return 8. 
// const double miles = 2.0; // Correct. Returns 8 Locations.

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 8 " + distances.Count);
Console.WriteLine("Results should be 8 " + results);

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



  was:
Running a spatial query against a list of locations all within 1 mile of a 
location returns correct results for 2 miles, but incorrect results for 1 mile. 
For the one mile query, only 2 of the 8 rows are returned. 

Locations & Test below:

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

// Locations
AddPoint(writer, "Location 1", 51.5073802128877, -0.124669075012207);
AddPoint(writer, "Location 2", 51.5091, -0.1235);
AddPoint(writer, "Location 3", 51.5093, -0.1232);
AddPoint(writer, "Location 4", 51.5112531582845, -0.12509822845459);
AddPoint(writer, "Location 5", 51.5107, -0.123);
AddPoint(writer, "Location 6", 51.512, -0.1246);
AddPoint(writer, "Location 8", 51.5088760101322, -0.143165588378906);
AddPoint(writer, "Location 9", 51.5087958793819, -0.143508911132813);


[Test]
public void TestAntiM()
{
_searcher = new IndexSearcher(_directory, true);

const double miles = 1.0; // Bug? Only returns 2 
locations. Should return 8. 
// const double miles = 2.0; // Correct. Returns 8 
Locations.

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 th

[jira] [Created] (LUCENENET-481) Port Contrib.MemoryIndex

[Christopher Currens (Created) (JIRA)]

Port Contrib.MemoryIndex


 Key: LUCENENET-481
 URL: https://issues.apache.org/jira/browse/LUCENENET-481
 Project: Lucene.Net
  Issue Type: New Feature
Affects Versions: Lucene.Net 3.0.3
Reporter: Christopher Currens


We need to port MemoryIndex from contrib, if we want to be able to port a few 
other contrib libraries.

--
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] [Reopened] (LUCENENET-466) optimisation for the GermanStemmer.vb‏

[Christopher Currens (Reopened) (JIRA)]

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

Christopher Currens reopened LUCENENET-466:
---


I see what you're saying.  I missed that in the original conversation that was 
linked to in an earlier comment.

{quote}
"ue" occurs pretty often as an infix (think of *steuer*): about 1.5%
of the words of the German aspell dictionary are affected. "ae" and
"oe" are rather seldom.

Still, it may be worth a try, because the stemmer doesn't work
morphologically anyway. It doesn't really matter if "steuer" is
stemmed as "steur" or "steu" as long as it's consistent.
{quote}

I'm thinking that as long as it is made clear that this behavior is in the 
second stemmer, this would probably be an okay change to make as the second 
option in a way that doesn't break the root of the word.

> optimisation for the GermanStemmer.vb‏
> --
>
> Key: LUCENENET-466
> URL: https://issues.apache.org/jira/browse/LUCENENET-466
> Project: Lucene.Net
>  Issue Type: Improvement
>  Components: Lucene.Net Contrib
>Affects Versions: Lucene.Net 2.9.4, Lucene.Net 2.9.4g, Lucene.Net 3.0.3
>Reporter: Prescott Nasser
>Priority: Minor
> Fix For: Lucene.Net 3.0.3
>
>
> I have a little optimisation for the GermanStemmer.vb (in 
> Contrib.Analyzers) class. At the moment the function "Substitute" 
> converts the german "Umlaute" "ä" in "a", "ö" in"o" and "ü" in "u". This 
> is not the correct german translation. They must be converted to "ae", 
> "oe" and "ue". So I can write the name "Björn" or "Bjoern" but not 
> "Bjorn". With this optimization a user can search for "Björn" and also 
> find "Bjoern".
>  
> Here is the optimized code snippet:
>  
> else if ( buffer[c] == 'ä' )
>  {
>  buffer[c] = 'a';
>  buffer.Insert(c + 1, 'e');
>  }
>  else if ( buffer[c] == 'ö' )
>  {
>  buffer[c] = 'o';
>  buffer.Insert(c + 1,'e');
>  }
>  else if ( buffer[c] == 'ü' )
>  {
>  buffer[c] = 'u';
>  buffer.Insert(c + 1,'e');
>  }
>  
> Thank You
> Björn

--
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-466) optimisation for the GermanStemmer.vb‏

[Christopher Currens (Updated) (JIRA)]

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

Christopher Currens updated LUCENENET-466:
--

Attachment: DIN2Stemmer.patch

Bjorn,

I've made this patch from the src/contrib/Analyzers folder, on top of the DIN2 
changes already committed to trunk.  Since the extent of my German is "danke!", 
I was hoping you could see if this stemmer is working properly before I commit 
it to trunk.

These were the test cases I made that should hopefully emulate the results of 
the normal DIN1 stemmer, where the word left of the semicolon is the word, and 
to the right, the result.

{noformat}
# Test cases for words with ae, ue, or oe in them
Haus;hau
Hauses;hau
Haeuser;hau
Haeusern;hau
steuer;steur
rueckwaerts;ruckwar
geheimtuer;geheimtur
{noformat}

With the last word in particular, it produces fairly different results in each 
stemmer, though I think they are expected, due to the different DIN.

Also, the DIN2 stemmer will also translate 'Häuser' and 'Häusern' properly (to 
hau), so there is support for both umlauts and the expanded 'ae', 'oe' and 'ue' 
forms.

> optimisation for the GermanStemmer.vb‏
> --
>
> Key: LUCENENET-466
> URL: https://issues.apache.org/jira/browse/LUCENENET-466
> Project: Lucene.Net
>  Issue Type: Improvement
>  Components: Lucene.Net Contrib
>Affects Versions: Lucene.Net 2.9.4, Lucene.Net 2.9.4g, Lucene.Net 3.0.3
>Reporter: Prescott Nasser
>Priority: Minor
> Fix For: Lucene.Net 3.0.3
>
> Attachments: DIN2Stemmer.patch
>
>
> I have a little optimisation for the GermanStemmer.vb (in 
> Contrib.Analyzers) class. At the moment the function "Substitute" 
> converts the german "Umlaute" "ä" in "a", "ö" in"o" and "ü" in "u". This 
> is not the correct german translation. They must be converted to "ae", 
> "oe" and "ue". So I can write the name "Björn" or "Bjoern" but not 
> "Bjorn". With this optimization a user can search for "Björn" and also 
> find "Bjoern".
>  
> Here is the optimized code snippet:
>  
> else if ( buffer[c] == 'ä' )
>  {
>  buffer[c] = 'a';
>  buffer.Insert(c + 1, 'e');
>  }
>  else if ( buffer[c] == 'ö' )
>  {
>  buffer[c] = 'o';
>  buffer.Insert(c + 1,'e');
>  }
>  else if ( buffer[c] == 'ü' )
>  {
>  buffer[c] = 'u';
>  buffer.Insert(c + 1,'e');
>  }
>  
> Thank You
> Björn

--
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] [Commented] (LUCENENET-482) Lucene out of Memory issue

[Christopher Currens (Commented) (JIRA)]

[ 
https://issues.apache.org/jira/browse/LUCENENET-482?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13239594#comment-13239594
 ] 

Christopher Currens commented on LUCENENET-482:
---

Yes, 2.9.2 is the newest stable version that runs on the .NET 2.0 runtime.  If 
you can't go to the 3.5/4.0 frameworks, that would be the version to use.

> Lucene out of Memory issue
> --
>
> Key: LUCENENET-482
> URL: https://issues.apache.org/jira/browse/LUCENENET-482
> Project: Lucene.Net
>  Issue Type: Bug
> Environment: Windows server 2003 and lucene .Net ver 2.3.2
>Reporter: Suraj Pant
>
> Hi We have recently tried to upgraded to lucene ver 2.3.2, at current we are 
> using ver 1.9.1. While tryiong to upgrade we get an error for which 
> description is provided as below:
> Could not process request
> System.OutOfMemoryException: Exception of type 'System.OutOfMemoryException' 
> was thrown.
>at Lucene.Net.Store.BufferedIndexInput.Refill() in C:\2 - Personal 
> Projects\SubText\Search-testing\Lucene.Net_2_3_2\src\Lucene.Net\Store\BufferedIndexInput.cs:line
>  176
> Please let us know in case of any solution for this error.
> Also please let us know from where we can download earlier then 2.3.2 version 
> of lucene .Net DLLs.
> An early response is highly appriciated.
> Regards,
> Suraj

--
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] [Closed] (LUCENENET-466) optimisation for the GermanStemmer.vb‏

[Christopher Currens (Closed) (JIRA)]

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

Christopher Currens closed LUCENENET-466.
-

Resolution: Fixed

Committed to trunk

> optimisation for the GermanStemmer.vb‏
> --
>
> Key: LUCENENET-466
> URL: https://issues.apache.org/jira/browse/LUCENENET-466
> Project: Lucene.Net
>  Issue Type: Improvement
>  Components: Lucene.Net Contrib
>Affects Versions: Lucene.Net 2.9.4, Lucene.Net 2.9.4g, Lucene.Net 3.0.3
>Reporter: Prescott Nasser
>Priority: Minor
> Fix For: Lucene.Net 3.0.3
>
> Attachments: DIN2Stemmer.patch
>
>
> I have a little optimisation for the GermanStemmer.vb (in 
> Contrib.Analyzers) class. At the moment the function "Substitute" 
> converts the german "Umlaute" "ä" in "a", "ö" in"o" and "ü" in "u". This 
> is not the correct german translation. They must be converted to "ae", 
> "oe" and "ue". So I can write the name "Björn" or "Bjoern" but not 
> "Bjorn". With this optimization a user can search for "Björn" and also 
> find "Bjoern".
>  
> Here is the optimized code snippet:
>  
> else if ( buffer[c] == 'ä' )
>  {
>  buffer[c] = 'a';
>  buffer.Insert(c + 1, 'e');
>  }
>  else if ( buffer[c] == 'ö' )
>  {
>  buffer[c] = 'o';
>  buffer.Insert(c + 1,'e');
>  }
>  else if ( buffer[c] == 'ü' )
>  {
>  buffer[c] = 'u';
>  buffer.Insert(c + 1,'e');
>  }
>  
> Thank You
> Björn

--
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] [Assigned] (LUCENENET-438) replace java doc notation with ms style xml comments notation.

[Christopher Currens (Assigned) (JIRA)]

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

Christopher Currens reassigned LUCENENET-438:
-

Assignee: Christopher Currens

> replace java doc notation with ms style xml comments notation.  
> 
>
> Key: LUCENENET-438
> URL: https://issues.apache.org/jira/browse/LUCENENET-438
> Project: Lucene.Net
>  Issue Type: Improvement
>  Components: Lucene.Net Contrib, Lucene.Net Core
>Affects Versions: Lucene.Net 2.9.4g
> Environment: all
>Reporter: michael herndon
>    Assignee: Christopher Currens
>  Labels: documentation,
>
> The are a ton of java doc style notations inside the xml code comments, i.e. 
> {@link #IncrementToken} 
> These need to use the ms xml code comment style if there is an existing 
> equivalent.  I'm not assigning this one. If you come across this on code you 
> are working on, please take an extra few minutes to fix up the comments. 
> If you need help, grab me on #lucene.net on irc or michaelherndon on skype. 
> Just let me know who you are and what help you need. 
> A guide for code documentation, it includes a table that shows JavaDoc and 
> XML doc comment equivalents:
> https://cwiki.apache.org/confluence/display/LUCENENET/Documenting+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] [Reopened] (LUCENENET-451) Missing License Headers in trunk

[Christopher Currens (Reopened) (JIRA)]

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

Christopher Currens reopened LUCENENET-451:
---

  Assignee: Christopher Currens  (was: Prescott Nasser)

I'm reopening this because the addition of the headers in the solution files 
cause the solutions files to not be recognized by Visual Studio 2010, where the 
express solutions could before be imported.  (This may affect Visual C# Express 
edition as well).

The header comments for these files are currently being placed at the beginning 
of the file.  Instead, they should be put after the following two lines in the 
lucene solution and each of the contrib and test solutions:

{quote}
Microsoft Visual Studio Solution File, Format Version 11.00
# Visual C# Express 2010
{quote}

I can make a fix and push to trunk shortly, but I will also upload another 
patch for the other branches.

> 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.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] [Issue Comment Edited] (LUCENENET-451) Missing License Headers in trunk

[Christopher Currens (Issue Comment Edited) (JIRA)]

[ 
https://issues.apache.org/jira/browse/LUCENENET-451?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13141637#comment-13141637
 ] 

Christopher Currens edited comment on LUCENENET-451 at 11/1/11 9:43 PM:


I'm reopening this because the addition of the headers in the solution files 
cause the solutions files to not be recognized by Visual Studio 2010, where the 
express solutions could before be imported.  (This may affect Visual C# Express 
edition as well).

The header comments for these files are currently being placed at the beginning 
of the file.  Instead, they should be put after the following two lines in the 
lucene solution and each of the contrib and test solutions:

{code:xml}
Microsoft Visual Studio Solution File, Format Version 11.00
# Visual C# Express 2010
{code}

I can make a fix and push to trunk shortly, but I will also upload another 
patch for the other branches.

  was (Author: ccurrens):
I'm reopening this because the addition of the headers in the solution 
files cause the solutions files to not be recognized by Visual Studio 2010, 
where the express solutions could before be imported.  (This may affect Visual 
C# Express edition as well).

The header comments for these files are currently being placed at the beginning 
of the file.  Instead, they should be put after the following two lines in the 
lucene solution and each of the contrib and test solutions:

{quote}
Microsoft Visual Studio Solution File, Format Version 11.00
# Visual C# Express 2010
{quote}

I can make a fix and push to trunk shortly, but I will also upload another 
patch for the other branches.
  
> 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.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