Re: 3.0.3 Pre-Release Nuget Packages
Zachary, That is on its way in. Itamar said a few weeks ago he was planning on getting polygon support into the spatial module (I am assuming that this is the Geometry namespace). I'm unsure if it will make it into the official 3.0.3 release or it if it will be pushed back into a maintenance release shortly after. Thanks for submitting the issue so we can keep tabs on his progress :P Thanks, Christopher On Wed, Aug 15, 2012 at 1:10 PM, Zachary Gramana zgram...@gmail.com wrote: In attempting to migrate a project from 2.9.4.1 to 3.0.3, I noticed that the entire Lucene.Net.Spatial.Geometry namespace is missing. As far as Java Lucene goes, it's not marked as deprecated until 3.6 (see https://issues.apache.org/jira/browse/LUCENE-2599). I submitted a new issue to Jira: https://issues.apache.org/jira/browse/LUCENENET-501 On Aug 6, 2012, at 4:55 PM, Prescott Nasser geobmx...@hotmail.com wrote: Hey All, I've hidden the two depreciated Nuget packages (Lucene and Lucene Contrib). I've also added pre-release (3.0.3-RC) Packages for Lucene.Net and Lucene.Net.Contrib. If you have time, I would ask that you take them for a test drive and provide us any feedback you have. Thanks all,~Prescott
Re: Lucene.Net 3.0.3 and medium trust
I think it's because we use a WeakReferenceT that inherits from WeakReference, which in turn, requires has this security attribute: SecurityPermissionAttribute(SecurityAction.InheritanceDemand, Flags = SecurityPermissionFlag.UnmanagedCode)]. I'm going to test on a machine with a medium trust CAS and see if the change fixes anything. Thanks, Christopher On Tue, Aug 14, 2012 at 8:21 AM, Christopher Currens currens.ch...@gmail.com wrote: 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 si...@devhost.se 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
[jira] [Created] (LUCENENET-500) Lucene fails to run in medium trust ASP.NET Application
Christopher Currens created LUCENENET-500: - Summary: Lucene fails to run in medium trust ASP.NET Application Key: LUCENENET-500 URL: https://issues.apache.org/jira/browse/LUCENENET-500 Project: Lucene.Net Issue Type: Bug Components: Lucene.Net Core Affects Versions: Lucene.Net 3.0.3 Reporter: Simon Svensson Assignee: Christopher Currens Fix For: Lucene.Net 3.0.3 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 -- 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-500) Lucene fails to run in medium trust ASP.NET Application
[ https://issues.apache.org/jira/browse/LUCENENET-500?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Christopher Currens resolved LUCENENET-500. --- Resolution: Fixed Issue was in the WeakKeyT class in WeakDictionary.cs. A generic wrapper for WeakReference was being used but was inheriting from WeakReference which requires UnmanagedCode security permissions. Removing the wrapper and doing casting instead fixes the permissions issue. Lucene fails to run in medium trust ASP.NET Application --- Key: LUCENENET-500 URL: https://issues.apache.org/jira/browse/LUCENENET-500 Project: Lucene.Net Issue Type: Bug Components: Lucene.Net Core Affects Versions: Lucene.Net 3.0.3 Reporter: Simon Svensson Assignee: Christopher Currens Fix For: Lucene.Net 3.0.3 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 -- 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
Re: Lucene.Net 3.0.3 and medium trust
Inheriting from WeakReference was the problem. I'm just going to remove the wrapper entirely, it doesn't give us any real benefit. The code has already been pushed. Thanks, Christopher On Tue, Aug 14, 2012 at 8:46 AM, Prescott Nasser geobmx...@hotmail.com wrote: It'd be nice to understand where this issue is coming from as it wasn't in 2.9.4 rather than jumping to a quick fix imo. I'll dig a bit myself ~P Date: Tue, 14 Aug 2012 17:32:29 +0200 From: si...@devhost.se To: lucene-net-dev@lucene.apache.org Subject: Re: Lucene.Net 3.0.3 and medium trust Hi, It got worse. Building a custom AttributeFactory can only handle a few cases, I needed to subclass _every_ TokenStream/TokenFilter to override all attribute-handling methods (AddAttribute, GetAttribute, etc), and all analyzers to use these streams, to use a dictionary with strong references just for medium trust... I gave up before doing that. ;) Is there any use cases where we need to garbage collect attributes before the stream/attribute source is closed? Changing to a normal dictionary seems like a quick fix. // Simon On 2012-08-14 17:21, Christopher Currens wrote: 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 si...@devhost.se 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: Lucene.Net 3.0.3 and medium trust
We should probably try and have unit tests that will spin up medium trust app domains and run some basic tests in them, so we don't accidentally ship with something big like this. That is what I initially tried to do to reproduce this bug on my end, but the code that I would which should have created a medium trust app domain wasn't working. I had to create an ASP.NET project and give it medium trust to repro. I'm sure there's a way to do it, though. Thanks, Christopher On Tue, Aug 14, 2012 at 9:08 AM, Christopher Currens currens.ch...@gmail.com wrote: Inheriting from WeakReference was the problem. I'm just going to remove the wrapper entirely, it doesn't give us any real benefit. The code has already been pushed. Thanks, Christopher On Tue, Aug 14, 2012 at 8:46 AM, Prescott Nasser geobmx...@hotmail.com wrote: It'd be nice to understand where this issue is coming from as it wasn't in 2.9.4 rather than jumping to a quick fix imo. I'll dig a bit myself ~P Date: Tue, 14 Aug 2012 17:32:29 +0200 From: si...@devhost.se To: lucene-net-dev@lucene.apache.org Subject: Re: Lucene.Net 3.0.3 and medium trust Hi, It got worse. Building a custom AttributeFactory can only handle a few cases, I needed to subclass _every_ TokenStream/TokenFilter to override all attribute-handling methods (AddAttribute, GetAttribute, etc), and all analyzers to use these streams, to use a dictionary with strong references just for medium trust... I gave up before doing that. ;) Is there any use cases where we need to garbage collect attributes before the stream/attribute source is closed? Changing to a normal dictionary seems like a quick fix. // Simon On 2012-08-14 17:21, Christopher Currens wrote: 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 si...@devhost.se 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: Lucene.NET 3.0.3 Build issues
Hmm, I ran into this last week and I specifically recall fixing it, but sure enough, it is fails to build in both branches. I guess I only fixed it in my private branch. Ah well, it's fixed now. Thanks. Christopher On Mon, Aug 13, 2012 at 12:53 PM, Granroth, Neal V. neal.granr...@thermofisher.com wrote: Thanks for the updated VS2010 solution files. Lucene.Net.Core builds without a problem. Lucene.Net.Demo encounters 12 errors and will not build. All 12 are the same error and all are in IndexHtml.cs: Non-invocable member 'Lucene.Net.Index.TermEnum.Term' cannot be used like a method. An example is this statement, line 139: reader.DeleteDocuments(uidIter.Term()); Term is apparently now a property, no longer a function. - Neal -Original Message- From: Prescott Nasser [mailto:geobmx...@hotmail.com] Sent: Saturday, August 11, 2012 1:23 PM To: Lucene Developers; Lucene Users Subject: RE: Lucene.NET 3.0.3 Build issues Alright - I see Chris updated the 3.0.3 branch with the solution files and a quick fix for the NativeFSLockFactory. We've had some people downloading the pre-release packages (Lucene.Net.Contrib 11 times, Lucene.Net 23 times). Mostly all quiet regarding issues. Unless there are any issues outstanding, lets call it good, run RAT on the 3.0.3 branch to fix any issues about headers, update the changelog files to represent the changes in 3.0.3 from 2.9.4 ~P Date: Thu, 9 Aug 2012 14:44:01 -0400 Subject: Re: Lucene.NET 3.0.3 Build issues From: mhern...@wickedsoftware.net To: lucene-net-dev@lucene.apache.org , the nifty new vs feature find of the day goes to Mr. Currens. I've been using it for tons of JavaScript style development with requireJS, kendo, my own set of scripts, and custom stuff for the day job. It actually provides intellisense for JS inheritance so life is good. On Thu, Aug 9, 2012 at 1:43 AM, Christopher Currens currens.ch...@gmail.com wrote: It used to be that way. VS2012 is the first version that produces backwards compatible projects *and* solutions. There's an msdn blog entry[1] that discusses it. It does focus more projects, but starts with discussing solutions and how having it all backwards compatible would ease transitions for most companies. There are a few project types that aren't backwards compatible, but I think the solution will still open in both, with a notification that it can't load the project type. Excerpt: In other words, we now have project round-tripping capability so you can work with the latest features but still keep the solution compatible with team members using an older version of Visual Studio. Anyway, it's about time they did this. Supporting multiple versions of VS files has been an annoying missing feature. [1] http://blogs.msdn.com/b/zainnab/archive/2012/06/05/visual-studio-2012-compatibility-aka-project-round-tripping.aspx On Wed, Aug 8, 2012 at 5:41 PM, Michael Herndon mhern...@wickedsoftware.net wrote: I think it's usually the project files that are backwards compatible not the solution files. So you need a solution for each vs version but should be able to keep the proj files the same. On Wed, Aug 8, 2012 at 7:27 PM, Prescott Nasser geobmx...@hotmail.com wrote: Yes Sent from my Windows Phone From: Christopher Currens Sent: 8/8/2012 4:22 PM To: lucene-net-dev@lucene.apache.org Subject: Re: Lucene.NET 3.0.3 Build issues Oh, did you do that so we'd have a branch to do bug fixes? I had forgotten about that. On Wed, Aug 8, 2012 at 2:23 PM, Prescott Nasser geobmx...@hotmail.com wrote: I just created 3.0.3 last weekend - it should be incredibly up to date. Anything in trunk should be there Sent from my Windows Phone From: Christopher Currens Sent: 8/8/2012 1:35 PM To: lucene-net-dev@lucene.apache.org Subject: Re: Lucene.NET 3.0.3 Build issues 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-dev@lucene.apache.org Subject: Re: Lucene.NET 3.0.3 Build issues FYI - SVN has been updated with corrected VS2010 solutions and added
Re: Lucene.NET 3.0.3 Build issues
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 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 Build issues
Oh, did you do that so we'd have a branch to do bug fixes? I had forgotten about that. On Wed, Aug 8, 2012 at 2:23 PM, Prescott Nasser geobmx...@hotmail.comwrote: I just created 3.0.3 last weekend - it should be incredibly up to date. Anything in trunk should be there Sent from my Windows Phone From: Christopher Currens Sent: 8/8/2012 1:35 PM To: lucene-net-dev@lucene.apache.org Subject: Re: Lucene.NET 3.0.3 Build issues 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-dev@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 Build issues
It used to be that way. VS2012 is the first version that produces backwards compatible projects *and* solutions. There's an msdn blog entry[1] that discusses it. It does focus more projects, but starts with discussing solutions and how having it all backwards compatible would ease transitions for most companies. There are a few project types that aren't backwards compatible, but I think the solution will still open in both, with a notification that it can't load the project type. Excerpt: In other words, we now have project round-tripping capability so you can work with the latest features but still keep the solution compatible with team members using an older version of Visual Studio. Anyway, it's about time they did this. Supporting multiple versions of VS files has been an annoying missing feature. [1] http://blogs.msdn.com/b/zainnab/archive/2012/06/05/visual-studio-2012-compatibility-aka-project-round-tripping.aspx On Wed, Aug 8, 2012 at 5:41 PM, Michael Herndon mhern...@wickedsoftware.net wrote: I think it's usually the project files that are backwards compatible not the solution files. So you need a solution for each vs version but should be able to keep the proj files the same. On Wed, Aug 8, 2012 at 7:27 PM, Prescott Nasser geobmx...@hotmail.com wrote: Yes Sent from my Windows Phone From: Christopher Currens Sent: 8/8/2012 4:22 PM To: lucene-net-dev@lucene.apache.org Subject: Re: Lucene.NET 3.0.3 Build issues Oh, did you do that so we'd have a branch to do bug fixes? I had forgotten about that. On Wed, Aug 8, 2012 at 2:23 PM, Prescott Nasser geobmx...@hotmail.com wrote: I just created 3.0.3 last weekend - it should be incredibly up to date. Anything in trunk should be there Sent from my Windows Phone From: Christopher Currens Sent: 8/8/2012 1:35 PM To: lucene-net-dev@lucene.apache.org Subject: Re: Lucene.NET 3.0.3 Build issues 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-dev@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: Outstanding issues for 3.0.3
I think that while it would be nice to get it done, it's a fairly large effort, and we might be better off with doing a release. The tests are massively changed between 3.0.3 and 3.6, so I think a lot of it will get cleaned up anyway during the port. Also, a little while back, I did clean up a lot of the test code to use Assert.Throws and to remove unnecessary variables, though that might have only been in catch statements. Either way, I think we just might be ready as it is. I am eager to start working on porting 3.6. Thanks, Christopher On Wed, Aug 1, 2012 at 9:14 AM, Itamar Syn-Hershko ita...@code972.comwrote: I still have plenty to go on, but on a second thought we could do that work just the same when we work towards 3.6, so I won't hold you off anymore Up to Chris - he wanted to do some tests cleanup Also, I'll be updating the Spatial contrib during the next week or so with polygon support. I think we should hold off the release so we can provide that as well, but I suggest we will take a vote on it, don't let me hold you off. On Wed, Aug 1, 2012 at 6:58 PM, Prescott Nasser geobmx...@hotmail.com wrote: Just wanted to check in - where do we feel like we stand? What is left to do - is there anything I can help with specifically? I'll have some spare cycles this weekend. I want to really make a push to get this ready to roll and not let it languish ~P Date: Sat, 28 Jul 2012 20:38:10 +0300 Subject: Re: Outstanding issues for 3.0.3 From: ita...@code972.com To: lucene-net-dev@lucene.apache.org Go ahead with contrib and tests, ill resume with core and coordinate further later On Jul 27, 2012 7:04 PM, Christopher Currens currens.ch...@gmail.com wrote: I've got resharper and can help with that if you'd like to coordinate it. I can take a one or some of the contrib projects or part of the main library, or *shudder* the any of the test libraries. The code has needed come cleaning up for a while and some of the clean up work is an optimization some levels, so I'm definitely okay with spending some time doing that. I'm okay with waiting longer as long as something is getting done. Thanks, Christopher On Fri, Jul 27, 2012 at 9:00 AM, Itamar Syn-Hershko ita...@code972.com wrote: The cleanup consists mainly of going file by file with ReSharper and trying to get them as green as possible. Making a lot of fields readonly, removing unused vars and stuff like that. There are still loads of files left. I was also hoping to get to updating the spatial module with some recent updates, and to also support polygon searches. But that may take a bit more time, so it's really up to you guys (or we can open a vote for it). On Fri, Jul 27, 2012 at 6:35 PM, Christopher Currens currens.ch...@gmail.com wrote: Itamar, Where do we stand on the clean up now? Is there anything in particular that you're doing that you'd like help with? I have some free time today and am eager to get this version released. Thanks, Christopher On Sat, Jul 21, 2012 at 1:02 PM, Prescott Nasser geobmx...@hotmail.com wrote: Alright, I'll hold off a bit. Date: Sat, 21 Jul 2012 22:59:32 +0300 Subject: Re: Outstanding issues for 3.0.3 From: ita...@code972.com To: lucene-net-u...@lucene.apache.org CC: lucene-net-dev@lucene.apache.org Actually there was some clean up work I started doing and would want to complete, and also sign off on the suspected corruption issue we raised. I'm afraid I won't have much time this week to properly do all that, but I'll keep you posted. On Sat, Jul 21, 2012 at 10:20 PM, Prescott Nasser geobmx...@hotmail.com wrote: Alright, latest patch fixed what could be done with the cls issues at present. With that, I think we are ready to roll with a release. If people could please take some time to run all the test as well as whatever other tests they might run. We've had some issues with tests only happening on some systems so I want to make sure we have those bases covered. Unless there is anything else that should be done, I'll leave every one a week to run their tests. Next saturday I will tag the trunk and cut a release with both 3.5 and 4.0 binaries. Great work everyone. ~P Date: Mon, 9 Jul 2012 18:02:30 -0700 Subject: Re: Outstanding issues for 3.0.3 From: currens.ch...@gmail.com
Re: Outstanding issues for 3.0.3
Ah, I did overlook that. I imagine that the move from 3.0.3 to 3.6 will realistically take a while, so if we can't get spatial stuff out before then, would it take until 3.6 to be able to release new functionality into the spatial contrib project? Along those lines, I propose that we move 3.0.3 into a new branch instead of just tagging the release and merging in 3.6. That way, during the time it takes to port 3.6, we can still do any critical bug fixes and features like these and release new versions. At least then, people won't be waiting for months for bug fixes. If we did that, then it also might not be critical to get the spatial stuff out with this release, since we could get out a new release in a few weeks with updated spatial libraries...not that I'm against waiting for it now. It was just a suggestion on how we can move forward with the project. Thoughts either way on this? On Wed, Aug 1, 2012 at 9:31 AM, Itamar Syn-Hershko ita...@code972.comwrote: I agree What about the spatial stuff? you guys want to wait for it? On Wed, Aug 1, 2012 at 7:19 PM, Christopher Currens currens.ch...@gmail.com wrote: I think that while it would be nice to get it done, it's a fairly large effort, and we might be better off with doing a release. The tests are massively changed between 3.0.3 and 3.6, so I think a lot of it will get cleaned up anyway during the port. Also, a little while back, I did clean up a lot of the test code to use Assert.Throws and to remove unnecessary variables, though that might have only been in catch statements. Either way, I think we just might be ready as it is. I am eager to start working on porting 3.6. Thanks, Christopher On Wed, Aug 1, 2012 at 9:14 AM, Itamar Syn-Hershko ita...@code972.com wrote: I still have plenty to go on, but on a second thought we could do that work just the same when we work towards 3.6, so I won't hold you off anymore Up to Chris - he wanted to do some tests cleanup Also, I'll be updating the Spatial contrib during the next week or so with polygon support. I think we should hold off the release so we can provide that as well, but I suggest we will take a vote on it, don't let me hold you off. On Wed, Aug 1, 2012 at 6:58 PM, Prescott Nasser geobmx...@hotmail.com wrote: Just wanted to check in - where do we feel like we stand? What is left to do - is there anything I can help with specifically? I'll have some spare cycles this weekend. I want to really make a push to get this ready to roll and not let it languish ~P Date: Sat, 28 Jul 2012 20:38:10 +0300 Subject: Re: Outstanding issues for 3.0.3 From: ita...@code972.com To: lucene-net-dev@lucene.apache.org Go ahead with contrib and tests, ill resume with core and coordinate further later On Jul 27, 2012 7:04 PM, Christopher Currens currens.ch...@gmail.com wrote: I've got resharper and can help with that if you'd like to coordinate it. I can take a one or some of the contrib projects or part of the main library, or *shudder* the any of the test libraries. The code has needed come cleaning up for a while and some of the clean up work is an optimization some levels, so I'm definitely okay with spending some time doing that. I'm okay with waiting longer as long as something is getting done. Thanks, Christopher On Fri, Jul 27, 2012 at 9:00 AM, Itamar Syn-Hershko ita...@code972.com wrote: The cleanup consists mainly of going file by file with ReSharper and trying to get them as green as possible. Making a lot of fields readonly, removing unused vars and stuff like that. There are still loads of files left. I was also hoping to get to updating the spatial module with some recent updates, and to also support polygon searches. But that may take a bit more time, so it's really up to you guys (or we can open a vote for it). On Fri, Jul 27, 2012 at 6:35 PM, Christopher Currens currens.ch...@gmail.com wrote: Itamar, Where do we stand on the clean up now? Is there anything in particular that you're doing that you'd like help with? I have some free time today and am eager to get this version released. Thanks, Christopher On Sat, Jul 21, 2012 at 1:02 PM, Prescott Nasser geobmx...@hotmail.com wrote: Alright, I'll hold off a bit. Date: Sat, 21 Jul 2012 22:59:32 +0300 Subject: Re: Outstanding issues for 3.0.3 From: ita...@code972.com
Re: Outstanding issues for 3.0.3
Itamar, Where do we stand on the clean up now? Is there anything in particular that you're doing that you'd like help with? I have some free time today and am eager to get this version released. Thanks, Christopher On Sat, Jul 21, 2012 at 1:02 PM, Prescott Nasser geobmx...@hotmail.comwrote: Alright, I'll hold off a bit. Date: Sat, 21 Jul 2012 22:59:32 +0300 Subject: Re: Outstanding issues for 3.0.3 From: ita...@code972.com To: lucene-net-u...@lucene.apache.org CC: lucene-net-dev@lucene.apache.org Actually there was some clean up work I started doing and would want to complete, and also sign off on the suspected corruption issue we raised. I'm afraid I won't have much time this week to properly do all that, but I'll keep you posted. On Sat, Jul 21, 2012 at 10:20 PM, Prescott Nasser geobmx...@hotmail.com wrote: Alright, latest patch fixed what could be done with the cls issues at present. With that, I think we are ready to roll with a release. If people could please take some time to run all the test as well as whatever other tests they might run. We've had some issues with tests only happening on some systems so I want to make sure we have those bases covered. Unless there is anything else that should be done, I'll leave every one a week to run their tests. Next saturday I will tag the trunk and cut a release with both 3.5 and 4.0 binaries. Great work everyone. ~P Date: Mon, 9 Jul 2012 18:02:30 -0700 Subject: Re: Outstanding issues for 3.0.3 From: currens.ch...@gmail.com To: lucene-net-dev@lucene.apache.org I can set a different build target, but I can't set the actual framework to 3.5 without doing it for all build configurations. On top of that, 3.5 needs System.Core to be referenced, which is done automatically in .NET 4 (I'm not sure if MSBuild v4 does it automatically?). I did kinda get it working by putting a TargetFrameworkVersion tag of 4.0 in Debug and Release configurations and 3.5 in Debug 3.5 and Release 3.5 configurations, but that's a little...well, difficult to maintain by hand since visual studio doesn't allow you to set different framework versions per configuration, and visual studio seemed to be having trouble with references, since both frameworks were being referenced. On Mon, Jul 9, 2012 at 5:57 PM, Prescott Nasser geobmx...@hotmail.com wrote: What do you mean doesn't work at the project level? I created a different build target NET35 and then we had Debug and Release still, that seemed to work for me. But I feel like I'm missing something in your explaination. Good work though! Date: Mon, 9 Jul 2012 17:51:36 -0700 Subject: Re: Outstanding issues for 3.0.3 From: currens.ch...@gmail.com To: lucene-net-dev@lucene.apache.org 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 geobmx...@hotmail.com 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-dev@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 geobmx...@hotmail.com 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 of change so close to the release. I can add it back to the schedule, though I'm mostly just doing administrative work for the next two weeks though - I have a few things I have to take care of Date: Mon, 9 Jul 2012 10:21:42 -0700 Subject: Re: Outstanding issues for 3.0.3 From: currens.ch...@gmail.com To: lucene-net-dev@lucene.apache.org
Re: Outstanding issues for 3.0.3
I've got resharper and can help with that if you'd like to coordinate it. I can take a one or some of the contrib projects or part of the main library, or *shudder* the any of the test libraries. The code has needed come cleaning up for a while and some of the clean up work is an optimization some levels, so I'm definitely okay with spending some time doing that. I'm okay with waiting longer as long as something is getting done. Thanks, Christopher On Fri, Jul 27, 2012 at 9:00 AM, Itamar Syn-Hershko ita...@code972.comwrote: The cleanup consists mainly of going file by file with ReSharper and trying to get them as green as possible. Making a lot of fields readonly, removing unused vars and stuff like that. There are still loads of files left. I was also hoping to get to updating the spatial module with some recent updates, and to also support polygon searches. But that may take a bit more time, so it's really up to you guys (or we can open a vote for it). On Fri, Jul 27, 2012 at 6:35 PM, Christopher Currens currens.ch...@gmail.com wrote: Itamar, Where do we stand on the clean up now? Is there anything in particular that you're doing that you'd like help with? I have some free time today and am eager to get this version released. Thanks, Christopher On Sat, Jul 21, 2012 at 1:02 PM, Prescott Nasser geobmx...@hotmail.com wrote: Alright, I'll hold off a bit. Date: Sat, 21 Jul 2012 22:59:32 +0300 Subject: Re: Outstanding issues for 3.0.3 From: ita...@code972.com To: lucene-net-u...@lucene.apache.org CC: lucene-net-dev@lucene.apache.org Actually there was some clean up work I started doing and would want to complete, and also sign off on the suspected corruption issue we raised. I'm afraid I won't have much time this week to properly do all that, but I'll keep you posted. On Sat, Jul 21, 2012 at 10:20 PM, Prescott Nasser geobmx...@hotmail.com wrote: Alright, latest patch fixed what could be done with the cls issues at present. With that, I think we are ready to roll with a release. If people could please take some time to run all the test as well as whatever other tests they might run. We've had some issues with tests only happening on some systems so I want to make sure we have those bases covered. Unless there is anything else that should be done, I'll leave every one a week to run their tests. Next saturday I will tag the trunk and cut a release with both 3.5 and 4.0 binaries. Great work everyone. ~P Date: Mon, 9 Jul 2012 18:02:30 -0700 Subject: Re: Outstanding issues for 3.0.3 From: currens.ch...@gmail.com To: lucene-net-dev@lucene.apache.org I can set a different build target, but I can't set the actual framework to 3.5 without doing it for all build configurations. On top of that, 3.5 needs System.Core to be referenced, which is done automatically in .NET 4 (I'm not sure if MSBuild v4 does it automatically?). I did kinda get it working by putting a TargetFrameworkVersion tag of 4.0 in Debug and Release configurations and 3.5 in Debug 3.5 and Release 3.5 configurations, but that's a little...well, difficult to maintain by hand since visual studio doesn't allow you to set different framework versions per configuration, and visual studio seemed to be having trouble with references, since both frameworks were being referenced. On Mon, Jul 9, 2012 at 5:57 PM, Prescott Nasser geobmx...@hotmail.com wrote: What do you mean doesn't work at the project level? I created a different build target NET35 and then we had Debug and Release still, that seemed to work for me. But I feel like I'm missing something in your explaination. Good work though! Date: Mon, 9 Jul 2012 17:51:36 -0700 Subject: Re: Outstanding issues for 3.0.3 From: currens.ch...@gmail.com To: lucene-net-dev@lucene.apache.org 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 geobmx...@hotmail.com wrote: Have
[jira] [Resolved] (LUCENENET-480) Investigate what needs to happen to make both .NET 3.5 and 4.0 builds possible
[ https://issues.apache.org/jira/browse/LUCENENET-480?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Christopher Currens resolved LUCENENET-480. --- Resolution: Fixed This should be fixed now, there was an issue with the test not running properly in the CI. Now that issue fixed, I think it's working properly now, although the CI server is still occasionally failing (for different reasons)...a random IPC error was the last failure I say for the poll-changes build. The nightly ran successfully last night. Investigate what needs to happen to make both .NET 3.5 and 4.0 builds possible -- Key: LUCENENET-480 URL: https://issues.apache.org/jira/browse/LUCENENET-480 Project: Lucene.Net Issue Type: Task Components: Lucene.Net Contrib, Lucene.Net Core, Lucene.Net Demo, Lucene.Net Test Affects Versions: Lucene.Net 2.9.4, Lucene.Net 2.9.4g, Lucene.Net 3.0.3 Reporter: Christopher Currens Assignee: Christopher Currens Fix For: Lucene.Net 3.0.3 Attachments: SortedSet.cs We need to investigate what needs to be done with the source to be able to support both a .NET 3.5 and 4.0 build. There was some concern from at least one member of the community ([see here|http://mail-archives.apache.org/mod_mbox/lucene-lucene-net-dev/201202.mbox/%3C004b01cce111$871f4990$955ddcb0$@fr%3E]) that we've alienated some of our user base by making such a heavy jump from 2.0 to 4.0. There are major benefits to using 4.0 over the 2.0-based runtimes, specifically FAR superior memory management, particularly with the LOH, where Lucene.NET has had major trouble with in the past. Based on what has been done with Lucene.NET 3.0.3, we can't (easily) drop .NET 3.5/3.0 libraries and go back to 2.0. HashSetT and ISetT is used extensively in the code, that would be a major blocker to get done. I suppose it could be possible, but there hasn't been a whole lot of talk about what runtimes we intend to support. The big change between lucene 2.x and 3.x for java was also a change in runtimes, that allowed generics and enums to be used in the base code. We have a similar situation with the API (it's substantially different, with the addition of properties alone) for this next version of Lucene.NET, so I think it's reasonable to at least make a permanent move from 2.0 to 3.5, though that's only my opinion, hasn't been discussed with the committers. It seems that supporting 3.5 and 4.0 should be fairly easy, and is a decent compromise in supporting both a 2.0 and 4.0 runtime. At the very least, we should try our best to support 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] [Commented] (LUCENENET-421) Segment files ocasionaly disappearing making index corrupted
[ https://issues.apache.org/jira/browse/LUCENENET-421?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13415388#comment-13415388 ] Christopher Currens commented on LUCENENET-421: --- Jackie Wong, are you using 2.9.2 as well? 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] [Updated] (LUCENENET-480) Investigate what needs to happen to make both .NET 3.5 and 4.0 builds possible
[ https://issues.apache.org/jira/browse/LUCENENET-480?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Christopher Currens updated LUCENENET-480: -- Fix Version/s: Lucene.Net 3.0.3 I'm merging it back into trunk now. I just have to make sure all the unit tests still pass and that it can successfully be built. I also need to write up a little page on the wiki explaining how it works and how to add new projects that can also support multi-framework targeting. Investigate what needs to happen to make both .NET 3.5 and 4.0 builds possible -- Key: LUCENENET-480 URL: https://issues.apache.org/jira/browse/LUCENENET-480 Project: Lucene.Net Issue Type: Task Components: Lucene.Net Contrib, Lucene.Net Core, Lucene.Net Demo, Lucene.Net Test Affects Versions: Lucene.Net 2.9.4, Lucene.Net 2.9.4g, Lucene.Net 3.0.3 Reporter: Christopher Currens Assignee: Christopher Currens Fix For: Lucene.Net 3.0.3 Attachments: SortedSet.cs We need to investigate what needs to be done with the source to be able to support both a .NET 3.5 and 4.0 build. There was some concern from at least one member of the community ([see here|http://mail-archives.apache.org/mod_mbox/lucene-lucene-net-dev/201202.mbox/%3C004b01cce111$871f4990$955ddcb0$@fr%3E]) that we've alienated some of our user base by making such a heavy jump from 2.0 to 4.0. There are major benefits to using 4.0 over the 2.0-based runtimes, specifically FAR superior memory management, particularly with the LOH, where Lucene.NET has had major trouble with in the past. Based on what has been done with Lucene.NET 3.0.3, we can't (easily) drop .NET 3.5/3.0 libraries and go back to 2.0. HashSetT and ISetT is used extensively in the code, that would be a major blocker to get done. I suppose it could be possible, but there hasn't been a whole lot of talk about what runtimes we intend to support. The big change between lucene 2.x and 3.x for java was also a change in runtimes, that allowed generics and enums to be used in the base code. We have a similar situation with the API (it's substantially different, with the addition of properties alone) for this next version of Lucene.NET, so I think it's reasonable to at least make a permanent move from 2.0 to 3.5, though that's only my opinion, hasn't been discussed with the committers. It seems that supporting 3.5 and 4.0 should be fairly easy, and is a decent compromise in supporting both a 2.0 and 4.0 runtime. At the very least, we should try our best to support 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
Re: Outstanding issues for 3.0.3
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 geobmx...@hotmail.comwrote: 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-dev@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 geobmx...@hotmail.com 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 of change so close to the release. I can add it back to the schedule, though I'm mostly just doing administrative work for the next two weeks though - I have a few things I have to take care of Date: Mon, 9 Jul 2012 10:21:42 -0700 Subject: Re: Outstanding issues for 3.0.3 From: currens.ch...@gmail.com To: lucene-net-dev@lucene.apache.org The tests should all be fine now. We had a contributer, Luc Vanlerberghe, who did a LOT of work for us, getting these last few difficult bugs out of the way. He's responsible for half or more of the failing tests from LUCENENET-484 getting fixed, as well as LUCENE-493, with the culture sensitivity. Also, I think we should no longer get any culture issues, since the tests that are marked as culture sensitive are now all run in all installed cultures on the machine. I think CLS compliance is still important and should be handled. What about LUCENENET-480? I know that Prescott had done some work on this and I also know this was requested by several in the community. I would love to see that make it into 3.0.3, and would be able to pick up where anyone had left off or take part of it, if they don't have time to work on it. In regards to LUCENENET-446, I agree that it is pretty much complete. I think I've looked several times at it to confirm most/all methods have been converted, so this week I'll do a final check and close it out. Thanks, Christopher On Sun, Jul 8, 2012 at 12:28 PM, Simon Svensson si...@devhost.se wrote: The tests that failed when using culture=sv-se seems fixed. On 2012-07-08 20:44, Itamar Syn-Hershko wrote: What's the status on the failing tests we had? On Sun, Jul 8, 2012 at 9:02 PM, Prescott Nasser geobmx...@hotmail.com wrote: Three issues left that I see: Fixing the build output, I did some work, but I'm good on this, we can move the rest of work to 3.6 https://issues.apache.org/**jira/browse/LUCENENET-456 https://issues.apache.org/jira/browse/LUCENENET-456 CLS Compliance https://issues.apache.org/**jira/browse/LUCENENET-446 https://issues.apache.org/jira/browse/LUCENENET-446. Are we ok with this as for now? There are still a good number of issues where, some we can't really fix (sbyte and volatile are out of scope imo). In a similiar vein, our own code uses some obsolete methods and we have a lot of variable declared but never used warnings (mentally, I treat most warning as an error) GetX/SetX - https://issues.apache.org/**jira/browse/LUCENENET-470 https://issues.apache.org/jira/browse/LUCENENET-470. I think much of this has been removed, there are probably some pieces that left (and we have a difference of opinion in the group as well). I really think the only outstanding issue is the CLS compliance one, the rest can be moved to 3.6. With CLS compliance we have to ask if we've done enough for that so far, or if more is needed. I personally would like to see us make any API changes now, with the 3.0.3 release, but if we are comfortable with it, lets roll. What are your thoughts? ~P --**-- From: thowar...@gmail.com Date: Mon, 25 Jun 2012 10:34:37 -0700 Subject: Re: Outstanding issues for 3.0.3 To:
Re: Outstanding issues for 3.0.3
I can set a different build target, but I can't set the actual framework to 3.5 without doing it for all build configurations. On top of that, 3.5 needs System.Core to be referenced, which is done automatically in .NET 4 (I'm not sure if MSBuild v4 does it automatically?). I did kinda get it working by putting a TargetFrameworkVersion tag of 4.0 in Debug and Release configurations and 3.5 in Debug 3.5 and Release 3.5 configurations, but that's a little...well, difficult to maintain by hand since visual studio doesn't allow you to set different framework versions per configuration, and visual studio seemed to be having trouble with references, since both frameworks were being referenced. On Mon, Jul 9, 2012 at 5:57 PM, Prescott Nasser geobmx...@hotmail.comwrote: What do you mean doesn't work at the project level? I created a different build target NET35 and then we had Debug and Release still, that seemed to work for me. But I feel like I'm missing something in your explaination. Good work though! Date: Mon, 9 Jul 2012 17:51:36 -0700 Subject: Re: Outstanding issues for 3.0.3 From: currens.ch...@gmail.com To: lucene-net-dev@lucene.apache.org 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 geobmx...@hotmail.com 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-dev@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 geobmx...@hotmail.com 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 of change so close to the release. I can add it back to the schedule, though I'm mostly just doing administrative work for the next two weeks though - I have a few things I have to take care of Date: Mon, 9 Jul 2012 10:21:42 -0700 Subject: Re: Outstanding issues for 3.0.3 From: currens.ch...@gmail.com To: lucene-net-dev@lucene.apache.org The tests should all be fine now. We had a contributer, Luc Vanlerberghe, who did a LOT of work for us, getting these last few difficult bugs out of the way. He's responsible for half or more of the failing tests from LUCENENET-484 getting fixed, as well as LUCENE-493, with the culture sensitivity. Also, I think we should no longer get any culture issues, since the tests that are marked as culture sensitive are now all run in all installed cultures on the machine. I think CLS compliance is still important and should be handled. What about LUCENENET-480? I know that Prescott had done some work on this and I also know this was requested by several in the community. I would love to see that make it into 3.0.3, and would be able to pick up where anyone had left off or take part of it, if they don't have time to work on it. In regards to LUCENENET-446, I agree that it is pretty much complete. I think I've looked several times at it to confirm most/all methods have been converted, so this week I'll do a final check and close it out. Thanks, Christopher On Sun, Jul 8, 2012 at 12:28 PM, Simon Svensson si...@devhost.se wrote: The tests that failed when using culture=sv-se seems fixed. On 2012-07-08 20:44, Itamar Syn-Hershko wrote: What's the status on the failing tests we had? On Sun, Jul 8, 2012 at 9:02 PM, Prescott Nasser geobmx...@hotmail.com wrote: Three issues left that I see: Fixing the build output, I did some work, but I'm good on this, we can move the rest of work to 3.6 https://issues.apache.org/**jira/browse/LUCENENET-456 https://issues.apache.org/jira/browse/LUCENENET-456 CLS Compliance
Re: [VOTE] Apache Lucene.Net ready for graduation?
+1 On Sun, Jul 8, 2012 at 4:01 PM, Frank Yu fengj...@gmail.com wrote: +1 On Sun, Jul 8, 2012 at 12:23 PM, Petersen, Robert rober...@buy.com wrote: +1 Sent from my iPhone On Jul 8, 2012, at 12:22 PM, Stefan Bodewig bode...@apache.org wrote: On 2012-07-08, Prescott Nasser wrote: As a community, if you would please vote: [+1] Ready for graduation [-1] Not ready because... +1 I know I speak for all the developers on this project, we appreciate (and will continue to appreciate) everyone's contributions via the mailing list and jira. +1 as well Stefan
[jira] [Resolved] (LUCENENET-484) Some possibly major tests intermittently fail
[ https://issues.apache.org/jira/browse/LUCENENET-484?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Christopher Currens resolved LUCENENET-484. --- Resolution: Fixed Thanks for your help with all of these Luc. Thanks to your hard work, this issue is finally closed, and for the first time in a long time, the whole test suite should consistently pass! Some possibly major tests intermittently fail -- Key: LUCENENET-484 URL: https://issues.apache.org/jira/browse/LUCENENET-484 Project: Lucene.Net Issue Type: Bug Components: Lucene.Net Core, Lucene.Net Test Affects Versions: Lucene.Net 3.0.3 Environment: All Reporter: Christopher Currens Fix For: Lucene.Net 3.0.3 Attachments: Lucenenet-484-FieldCacheImpl.patch, Lucenenet-484-NativeFSLockFactory.patch, Lucenenet-484-WeakDictionary.patch, Lucenenet-484-WeakDictionaryTests.patch These tests will fail intermittently in Debug or Release mode, in the core test suite: # Lucene.Net.Index: #- TestConcurrentMergeScheduler.TestFlushExceptions -- *FIXED* # Lucene.Net.Store: #- TestLockFactory.TestStressLocks -- *FIXED* # Lucene.Net.Search: #- TestSort.TestParallelMultiSort -- *FIXED* # Lucene.Net.Util: #- TestFieldCacheSanityChecker.TestInsanity1 -- *FIXED* #- TestFieldCacheSanityChecker.TestInsanity2 -- *FIXED* # Lucene.Net.Support #- TestWeakHashTableMultiThreadAccess.Test -- *FIXED* TestWeakHashTableMultiThreadAccess should be fine to remove along with the WeakHashTable in the Support namespace, since it's been replaced with WeakDictionary. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (LUCENENET-484) Some possibly major tests intermittently fail
[ https://issues.apache.org/jira/browse/LUCENENET-484?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Christopher Currens updated LUCENENET-484: -- Description: These tests will fail intermittently in Debug or Release mode, in the core test suite: # Lucene.Net.Index: #- TestConcurrentMergeScheduler.TestFlushExceptions -- *FIXED* # Lucene.Net.Store: #- TestLockFactory.TestStressLocks -- *FIXED* # Lucene.Net.Search: #- TestSort.TestParallelMultiSort -- *FIXED* # Lucene.Net.Util: #- TestFieldCacheSanityChecker.TestInsanity1 -- *FIXED* #- TestFieldCacheSanityChecker.TestInsanity2 -- *FIXED* # Lucene.Net.Support #- TestWeakHashTableMultiThreadAccess.Test -- *FIXED* TestWeakHashTableMultiThreadAccess should be fine to remove along with the WeakHashTable in the Support namespace, since it's been replaced with WeakDictionary. was: These tests will fail intermittently in Debug or Release mode, in the core test suite: # -Lucene.Net.Index:- #- -TestConcurrentMergeScheduler.TestFlushExceptions- # Lucene.Net.Store: #- TestLockFactory.TestStressLocks # Lucene.Net.Search: #- TestSort.TestParallelMultiSort # -Lucene.Net.Util:- #- -TestFieldCacheSanityChecker.TestInsanity1- #- -TestFieldCacheSanityChecker.TestInsanity2- #- -(It's possible all of the insanity tests fail at one point or another)- # -Lucene.Net.Support- #- -TestWeakHashTableMultiThreadAccess.Test- TestWeakHashTableMultiThreadAccess should be fine to remove along with the WeakHashTable in the Support namespace, since it's been replaced with WeakDictionary. Some possibly major tests intermittently fail -- Key: LUCENENET-484 URL: https://issues.apache.org/jira/browse/LUCENENET-484 Project: Lucene.Net Issue Type: Bug Components: Lucene.Net Core, Lucene.Net Test Affects Versions: Lucene.Net 3.0.3 Environment: All Reporter: Christopher Currens Fix For: Lucene.Net 3.0.3 Attachments: Lucenenet-484-FieldCacheImpl.patch, Lucenenet-484-NativeFSLockFactory.patch, Lucenenet-484-WeakDictionary.patch, Lucenenet-484-WeakDictionaryTests.patch These tests will fail intermittently in Debug or Release mode, in the core test suite: # Lucene.Net.Index: #- TestConcurrentMergeScheduler.TestFlushExceptions -- *FIXED* # Lucene.Net.Store: #- TestLockFactory.TestStressLocks -- *FIXED* # Lucene.Net.Search: #- TestSort.TestParallelMultiSort -- *FIXED* # Lucene.Net.Util: #- TestFieldCacheSanityChecker.TestInsanity1 -- *FIXED* #- TestFieldCacheSanityChecker.TestInsanity2 -- *FIXED* # Lucene.Net.Support #- TestWeakHashTableMultiThreadAccess.Test -- *FIXED* TestWeakHashTableMultiThreadAccess should be fine to remove along with the WeakHashTable in the Support namespace, since it's been replaced with WeakDictionary. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Resolved] (LUCENENET-493) Make lucene.net culture insensitive (like the java version)
[ https://issues.apache.org/jira/browse/LUCENENET-493?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Christopher Currens resolved LUCENENET-493. --- Resolution: Fixed This should be fixed now. Added a test to LocalizedTestCase (different from the patch above) so that it will run some or all tests (if no specific tests were selected) under all installed cultures on the machine. This should be the same behavior as Java, except for that it is running all tests in one, instead of individually. However, when a test fails, it will output which test failed and which culture it failed it. I discovered issues in DateTools.cs in the ar culture, where DateTimeToString was returning culture specific formatting. I think we can resolve this now that we can confirm that the tests pass. If any future culture-sensitive bug appear, new issues can be created, and then specific tests can be written to check for those issues. Make lucene.net culture insensitive (like the java version) --- Key: LUCENENET-493 URL: https://issues.apache.org/jira/browse/LUCENENET-493 Project: Lucene.Net Issue Type: Bug Components: Lucene.Net Core, Lucene.Net Test Affects Versions: Lucene.Net 3.0.3 Reporter: Luc Vanlerberghe Labels: patch Fix For: Lucene.Net 3.0.3 Attachments: Lucenenet-493.patch, UpdatedLocalizedTestCase.patch In Java, conversion of the basic types to and from strings is locale (culture) independent. For localized input/output one needs to use the classes in the java.text package. In .Net, conversion of the basic types to and from strings depends on the default Culture. Otherwise you have to specify CultureInfo.InvariantCulture explicitly. Some of the testcases in lucene.net fail if they are not run on a machine with culture set to US. In the current version of lucene.net there are patches here and there that try to correct for some specific cases by using string replacement (like System.Double.Parse(s.Replace(., CultureInfo.CurrentCulture.NumberFormat.NumberDecimalSeparator)), but that seems really ugly. I submit a patch here that removes the old workarounds and replaces them by calls to classes in the Lucene.Net.Support namespace that try to handle the conversions in a compatible way. -- 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-436) Refactor Deprecated Code inside of tests
[ https://issues.apache.org/jira/browse/LUCENENET-436?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Christopher Currens updated LUCENENET-436: -- Affects Version/s: Lucene.Net 3.0.3 Fix Version/s: (was: Lucene.Net 3.0.3) Lucene.Net 3.5 Refactor Deprecated Code inside of tests - Key: LUCENENET-436 URL: https://issues.apache.org/jira/browse/LUCENENET-436 Project: Lucene.Net Issue Type: Sub-task Components: Lucene.Net Test Affects Versions: Lucene.Net 2.9.4g, Lucene.Net 3.0.3 Reporter: michael herndon Labels: refactoring, testing, Fix For: Lucene.Net 3.5 * We should still be testing deprecated methods, but we need to use #pragma warning disable/enable 0618 for testing those. otherwise compiler warnings are too numerous to be anywhere near helpful. * We should only be using deprecated methods in places where they are being explicitly tested, other tests that need that functionality in order to validate those tests should be re factored to use methods that are not deprecated. This is one place we should probably deviate from the parent project and make sure that any deprecated code gets isolated to the tests designed only for the deprecated methods and then use the newer API through out the testsuite. This should help move the project forward and remove deprecated API's when the time comes. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (LUCENENET-434) Remove AnonymousXXXX classes to increase readablity
[ https://issues.apache.org/jira/browse/LUCENENET-434?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Christopher Currens updated LUCENENET-434: -- Fix Version/s: (was: Lucene.Net 3.0.3) Lucene.Net 3.5 Moving to 3.5. As ugly as they are, they don't hurt anything except our eyes leaving them in there. As we port to 3.5, we can remove these as much as we can. Remove Anonymous classes to increase readablity --- Key: LUCENENET-434 URL: https://issues.apache.org/jira/browse/LUCENENET-434 Project: Lucene.Net Issue Type: Improvement Components: Lucene.Net Core Affects Versions: Lucene.Net 2.9.4g, Lucene.Net 3.0.3 Reporter: Scott Lombard Assignee: Scott Lombard Priority: Minor Fix For: Lucene.Net 3.5 Attachments: TeeSinkTokenFilter.patch Original Estimate: 168h Time Spent: 13h Remaining Estimate: 155h Replace Anonymous classes inhereted from JLCA which make the code impossible to read. Follow Digy's template to replace the single abstract method with Func or Action like in FilterCacheT from: protected abstract object MergeDeletes(IndexReader reader, object value); to: FuncIndexReader, object, object MergeDeletes; Determine a solution to the classes with more than 1 abstract method without diverging much from Java. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (LUCENENET-467) .NETify the public API where appropriate
[ https://issues.apache.org/jira/browse/LUCENENET-467?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Christopher Currens updated LUCENENET-467: -- Fix Version/s: (was: Lucene.Net 3.0.3) Lucene.Net 3.5 Moving to 3.5 .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.5 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 IEnumerableT * 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
Outstanding issues for 3.0.3
I want to discuss the outstanding issues blocking a 3.0.3 release. I've already moved quite a few bugs to 3.5 that are too time-consuming or require too many changes to the code. It's fairly obvious that we wouldn't be able to finish them. Other more serious bugs, like the culture-sensitivity issues we've been seeing and failing tests, were able to be closed due to changed checked in by committers and contributors. -- Task 470, a non-serious one, is listed only because it's mostly done and just need a few loose ends tied up. I'll hopefully have time to take care of that this weekend. -- Task 446 (CLS Compliance), is important, but there's no way we can get this done quickly. The current state of this issue is that all of the names of public members are now compliant. There are a few things that aren't, the use of sbyte (particularly those related to the FieldCache) and some conflicts with *protected or internal* fields (some with public members). Opinions on this one will be appreciated the most. My opinion is that we should draw a line on the amount of CLS compliance to have in this release, and push the rest into 3.5. -- Improvement 337 - Are we going to add this code (not present in java) to the core library? -- Improvement 456 - This is related to builds being output in Apache's release format. Do we want to do this for this release? Thanks, Christopher
Re: win phone 8
I wonder if it will still require IsolatedStorage. I would assume so? However, I would think that would only require creating a Directory type that used IsolatedStorage APIs, and added a check in FSDirectory.Open to return one of those if it's running on WP8. On Wed, Jun 20, 2012 at 10:47 AM, Prescott Nasser geobmx...@hotmail.comwrote: looks like the same .net runtime will be in windows phone 8 and windows 8 - might save us porting issues for mobile..
[jira] [Commented] (LUCENENET-480) Investigate what needs to happen to make both .NET 3.5 and 4.0 builds possible
[
https://issues.apache.org/jira/browse/LUCENENET-480?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13397690#comment-13397690
]
Christopher Currens commented on LUCENENET-480:
---
Regarding the sorted SortedSet implementation, I might consider using a
{{SortedDictionaryT}} internally instead of a {{SortedListT}}. It's faster
at removals and insertions, at the cost of a little more memory. I think in
the cases where SortedSet is used in Lucene, it won't make much of a difference
at all in memory usage, but could use the speed.
Investigate what needs to happen to make both .NET 3.5 and 4.0 builds possible
--
Key: LUCENENET-480
URL: https://issues.apache.org/jira/browse/LUCENENET-480
Project: Lucene.Net
Issue Type: Task
Components: Lucene.Net Contrib, Lucene.Net Core, Lucene.Net Demo,
Lucene.Net Test
Affects Versions: Lucene.Net 2.9.4, Lucene.Net 2.9.4g, Lucene.Net 3.0.3
Reporter: Christopher Currens
Attachments: SortedSet.cs
We need to investigate what needs to be done with the source to be able to
support both a .NET 3.5 and 4.0 build. There was some concern from at least
one member of the community ([see
here|http://mail-archives.apache.org/mod_mbox/lucene-lucene-net-dev/201202.mbox/%3C004b01cce111$871f4990$955ddcb0$@fr%3E])
that we've alienated some of our user base by making such a heavy jump from
2.0 to 4.0. There are major benefits to using 4.0 over the 2.0-based
runtimes, specifically FAR superior memory management, particularly with the
LOH, where Lucene.NET has had major trouble with in the past.
Based on what has been done with Lucene.NET 3.0.3, we can't (easily) drop
.NET 3.5/3.0 libraries and go back to 2.0. HashSetT and ISetT is used
extensively in the code, that would be a major blocker to get done. I
suppose it could be possible, but there hasn't been a whole lot of talk about
what runtimes we intend to support. The big change between lucene 2.x and
3.x for java was also a change in runtimes, that allowed generics and enums
to be used in the base code. We have a similar situation with the API (it's
substantially different, with the addition of properties alone) for this next
version of Lucene.NET, so I think it's reasonable to at least make a
permanent move from 2.0 to 3.5, though that's only my opinion, hasn't been
discussed with the committers.
It seems that supporting 3.5 and 4.0 should be fairly easy, and is a decent
compromise in supporting both a 2.0 and 4.0 runtime. At the very least, we
should try our best to support 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] [Commented] (LUCENENET-480) Investigate what needs to happen to make both .NET 3.5 and 4.0 builds possible
[
https://issues.apache.org/jira/browse/LUCENENET-480?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13397164#comment-13397164
]
Christopher Currens commented on LUCENENET-480:
---
Change {{ISetT x = new HashSetT()}} to instantiate from a factory instead.
So, it would become something like: {{ISetT x =
Lucene.Net.Support.Compatibility.GetSetT()}}. In .NET 3.5 would return a
{{WrappedHashSetT : Lucene.Net.Support.ISetT}} (which in turn just wraps a
normal HashSetT). In .NET 4, it would just return a HashSetT.
We would need to do the same with SortedSet, as well.
Investigate what needs to happen to make both .NET 3.5 and 4.0 builds possible
--
Key: LUCENENET-480
URL: https://issues.apache.org/jira/browse/LUCENENET-480
Project: Lucene.Net
Issue Type: Task
Components: Lucene.Net Contrib, Lucene.Net Core, Lucene.Net Demo,
Lucene.Net Test
Affects Versions: Lucene.Net 2.9.4, Lucene.Net 2.9.4g, Lucene.Net 3.0.3
Reporter: Christopher Currens
Attachments: SortedSet.cs
We need to investigate what needs to be done with the source to be able to
support both a .NET 3.5 and 4.0 build. There was some concern from at least
one member of the community ([see
here|http://mail-archives.apache.org/mod_mbox/lucene-lucene-net-dev/201202.mbox/%3C004b01cce111$871f4990$955ddcb0$@fr%3E])
that we've alienated some of our user base by making such a heavy jump from
2.0 to 4.0. There are major benefits to using 4.0 over the 2.0-based
runtimes, specifically FAR superior memory management, particularly with the
LOH, where Lucene.NET has had major trouble with in the past.
Based on what has been done with Lucene.NET 3.0.3, we can't (easily) drop
.NET 3.5/3.0 libraries and go back to 2.0. HashSetT and ISetT is used
extensively in the code, that would be a major blocker to get done. I
suppose it could be possible, but there hasn't been a whole lot of talk about
what runtimes we intend to support. The big change between lucene 2.x and
3.x for java was also a change in runtimes, that allowed generics and enums
to be used in the base code. We have a similar situation with the API (it's
substantially different, with the addition of properties alone) for this next
version of Lucene.NET, so I think it's reasonable to at least make a
permanent move from 2.0 to 3.5, though that's only my opinion, hasn't been
discussed with the committers.
It seems that supporting 3.5 and 4.0 should be fairly easy, and is a decent
compromise in supporting both a 2.0 and 4.0 runtime. At the very least, we
should try our best to support 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-495) Use of DateTime.Now causes huge amount of System.Globalization.DaylightTime object allocations
[
https://issues.apache.org/jira/browse/LUCENENET-495?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Christopher Currens resolved LUCENENET-495.
---
Resolution: Fixed
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-493) Make lucene.net culture insensitive (like the java version)
[
https://issues.apache.org/jira/browse/LUCENENET-493?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Christopher Currens updated LUCENENET-493:
--
Attachment: UpdatedLocalizedTestCase.patch
I've updated LocalizedTestCase, so that it will actually run against all
installed cultures. The workaround is unfortunate...there is now only 1 test
that does all localization checks. It's done more or less the same way that
java does it, however, instead of being able to override the {{runBare()}}
method, I've created a test method that will run all methods in all installed
cultures. If a method were to fail, it would list the method name, and the
culture it failed in. I've attached a patch that shows the solution, so if
anyone has a better solution, we can discuss that and possibly use it instead.
Interestingly enough, the tests that Java Lucene has set to test, don't
actually fail when using the older code that doesn't have localization changes
in it. However, when I added {{TestBoost}} to the list in {{TestQueryParser}},
that one did fail before the push that Simon did. So, it concerns me that we
don't have enough tests written that actually will cause it to fail, when run
as a localized test.
So, what I propose we do before we apply Luc's patch, is to write tests that
*will fail* when using as a LocalizedTestCase and then make sure his patch
makes all of the tests pass.
Make lucene.net culture insensitive (like the java version)
---
Key: LUCENENET-493
URL: https://issues.apache.org/jira/browse/LUCENENET-493
Project: Lucene.Net
Issue Type: Bug
Components: Lucene.Net Core, Lucene.Net Test
Affects Versions: Lucene.Net 3.0.3
Reporter: Luc Vanlerberghe
Labels: patch
Fix For: Lucene.Net 3.0.3
Attachments: Lucenenet-493.patch, UpdatedLocalizedTestCase.patch
In Java, conversion of the basic types to and from strings is locale
(culture) independent. For localized input/output one needs to use the
classes in the java.text package.
In .Net, conversion of the basic types to and from strings depends on the
default Culture. Otherwise you have to specify CultureInfo.InvariantCulture
explicitly.
Some of the testcases in lucene.net fail if they are not run on a machine
with culture set to US.
In the current version of lucene.net there are patches here and there that
try to correct for some specific cases by using string replacement (like
System.Double.Parse(s.Replace(.,
CultureInfo.CurrentCulture.NumberFormat.NumberDecimalSeparator)), but that
seems really ugly.
I submit a patch here that removes the old workarounds and replaces them by
calls to classes in the Lucene.Net.Support namespace that try to handle the
conversions in a compatible way.
--
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-480) Investigate what needs to happen to make both .NET 3.5 and 4.0 builds possible
[ https://issues.apache.org/jira/browse/LUCENENET-480?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13393610#comment-13393610 ] Christopher Currens commented on LUCENENET-480: --- I would feel most comfortable leaving it as ISetT in most (all?) places, based on the one you've created, which I'm assuming follows the same contract as .NET 4? I can see Java possibly using more and more classes that aren't HashSet, that implement ISet. What did you wind up doing with SortedSet, did you write a class for it? Investigate what needs to happen to make both .NET 3.5 and 4.0 builds possible -- Key: LUCENENET-480 URL: https://issues.apache.org/jira/browse/LUCENENET-480 Project: Lucene.Net Issue Type: Task Components: Lucene.Net Contrib, Lucene.Net Core, Lucene.Net Demo, Lucene.Net Test Affects Versions: Lucene.Net 2.9.4, Lucene.Net 2.9.4g, Lucene.Net 3.0.3 Reporter: Christopher Currens We need to investigate what needs to be done with the source to be able to support both a .NET 3.5 and 4.0 build. There was some concern from at least one member of the community ([see here|http://mail-archives.apache.org/mod_mbox/lucene-lucene-net-dev/201202.mbox/%3C004b01cce111$871f4990$955ddcb0$@fr%3E]) that we've alienated some of our user base by making such a heavy jump from 2.0 to 4.0. There are major benefits to using 4.0 over the 2.0-based runtimes, specifically FAR superior memory management, particularly with the LOH, where Lucene.NET has had major trouble with in the past. Based on what has been done with Lucene.NET 3.0.3, we can't (easily) drop .NET 3.5/3.0 libraries and go back to 2.0. HashSetT and ISetT is used extensively in the code, that would be a major blocker to get done. I suppose it could be possible, but there hasn't been a whole lot of talk about what runtimes we intend to support. The big change between lucene 2.x and 3.x for java was also a change in runtimes, that allowed generics and enums to be used in the base code. We have a similar situation with the API (it's substantially different, with the addition of properties alone) for this next version of Lucene.NET, so I think it's reasonable to at least make a permanent move from 2.0 to 3.5, though that's only my opinion, hasn't been discussed with the committers. It seems that supporting 3.5 and 4.0 should be fairly easy, and is a decent compromise in supporting both a 2.0 and 4.0 runtime. At the very least, we should try our best to support 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] [Commented] (LUCENENET-337) TokenAttribute for Selectively Including Tokens in Length Norm
[
https://issues.apache.org/jira/browse/LUCENENET-337?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13393615#comment-13393615
]
Christopher Currens commented on LUCENENET-337:
---
I'm unsure about it. It's implemented directly into the DocInverterPerField
class, which makes me slightly uncomfortable, but by default, the behavior
won't be changed, since LengthNormAttribute.IncludeInLengthNorm is set to true,
by default. I think (but don't actually remember) that the API might be
outdated, so it would have to be upgraded for 3.0.3.
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
Affects Versions: Lucene.Net 2.9.2
Reporter: Michael Garski
Priority: Minor
Fix For: Lucene.Net 3.0.3
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-495) Use of DateTime.Now causes huge amount of System.Globalization.DaylightTime object allocations
[
https://issues.apache.org/jira/browse/LUCENENET-495?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13393624#comment-13393624
]
Christopher Currens commented on LUCENENET-495:
---
Yeah, I noticed that new structure a few weeks ago. Definitely more powerful,
in that it keeps track of utc offset. DateTimeOffset.Now actually just calls
{{new DateTimeOffset(DateTime.Now)}}, so it doesn't help in this case.
Interestingly enough, this improves speed in Lucene enough, that it has exposed
other thread-safety issues in Lucene. Fortunately, I think it's only affecting
code specific to the test suite. Well, it's actually code in
CollectionHelpers, in Lucene.Net.Support, on AddIfNotContains(Hashtable,
object). However, the only usages I could find for that particular method, is
in Lucene.Net.Test.
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] [Commented] (LUCENENET-495) Use of DateTime.Now causes huge amount of System.Globalization.DaylightTime object allocations
[
https://issues.apache.org/jira/browse/LUCENENET-495?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13393631#comment-13393631
]
Christopher Currens commented on LUCENENET-495:
---
I did fix the thread-safety bug. The code was checking if a key existed in the
(synchronized) HashTable, and then tried to add it. Because there was no
locking, there was the scenario when two threads would check if the key existed
at the same time, then both add it within a few instructions of each other,
causing one to throw an ArgumentException, because the key already existed.
In all of the code code, we are using the correct types we should be (I think).
This is code in the test suite that hasn't ever been updated. In fact, it
really should be a HashSet and not a HashTable. We were using it because at
the time, it was pre-.net 3.0, and the only way to match the java code. We
could change it, but IMO, it's not really worth it right now, because it's ONLY
used in the test code. In the next version we're porting, the testing code is
significantly different, so I don't want to spend _too_ much time cleaning it
up if it works.
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
Re: svn commit: r1351173 - in /incubator/lucene.net/trunk/src/core: ./ Index/ Search/ Store/ Support/
It should have been removed and not just commented out. This should not be
obsolete in this case, because it's inheriting from System.IO.TextReader,
and it's not obsoleted in the BCL. Any Close() defined in the Lucene.NET
library should be marked as obsolete, though.
On Sun, Jun 17, 2012 at 4:01 PM, Itamar Syn-Hershko ita...@code972.comwrote:
-[Obsolete(Use Dispose() instead)]
+//[Obsolete(Use Dispose() instead)]
public override void Close()
{
Dispose();
Is Close obsolete or not?...
On Mon, Jun 18, 2012 at 1:21 AM, ccurr...@apache.org wrote:
Author: ccurrens
Date: Sun Jun 17 22:21:07 2012
New Revision: 1351173
URL: http://svn.apache.org/viewvc?rev=1351173view=rev
Log:
[LUCENENET-495] - Replaced several instances of DateTime.Now with
DateTime.UtcNow. Improves performance by ~31%
Modified:
incubator/lucene.net/trunk/src/core/Index/ReusableStringReader.cs
incubator/lucene.net/trunk/src/core/Index/SegmentInfos.cs
incubator/lucene.net/trunk/src/core/Index/Term.cs
incubator/lucene.net/trunk/src/core/Lucene.Net.csproj
incubator/lucene.net/trunk/src/core/Search/FilterManager.cs
incubator/lucene.net/trunk/src/core/Store/RAMDirectory.cs
incubator/lucene.net/trunk/src/core/Store/RAMFile.cs
incubator/lucene.net/trunk/src/core/Store/RAMOutputStream.cs
incubator/lucene.net/trunk/src/core/Support/CollectionsHelper.cs
Modified: incubator/
lucene.net/trunk/src/core/Index/ReusableStringReader.cs
URL:
http://svn.apache.org/viewvc/incubator/lucene.net/trunk/src/core/Index/ReusableStringReader.cs?rev=1351173r1=1351172r2=1351173view=diff
==
--- incubator/
lucene.net/trunk/src/core/Index/ReusableStringReader.cs(original)
+++ incubator/lucene.net/trunk/src/core/Index/ReusableStringReader.csSun
Jun 17 22:21:07 2012
@@ -67,7 +67,7 @@ namespace Lucene.Net.Index
}
}
-[Obsolete(Use Dispose() instead)]
+//[Obsolete(Use Dispose() instead)]
public override void Close()
{
Dispose();
Modified: incubator/lucene.net/trunk/src/core/Index/SegmentInfos.cs
URL:
http://svn.apache.org/viewvc/incubator/lucene.net/trunk/src/core/Index/SegmentInfos.cs?rev=1351173r1=1351172r2=1351173view=diff
==
--- incubator/lucene.net/trunk/src/core/Index/SegmentInfos.cs (original)
+++ incubator/lucene.net/trunk/src/core/Index/SegmentInfos.cs Sun Jun 17
22:21:07 2012
@@ -121,7 +121,7 @@ namespace Lucene.Net.Index
/// summary counts how often the index has been changed
by adding or deleting docs.
/// starting with the current time in milliseconds forces
to create unique version numbers.
/// /summary
- private long version = (DateTime.Now.Ticks /
TimeSpan.TicksPerMillisecond);
+ private long version = (DateTime.UtcNow.Ticks /
TimeSpan.TicksPerMillisecond);
private long generation = 0; // generation of the
segments_N for the next commit
private long lastGeneration = 0; // generation of the
segments_N file we last successfully read
@@ -303,7 +303,7 @@ namespace Lucene.Net.Index
{
// in old format the version
number
may be at the end of the file
if (input.FilePointer =
input.Length())
- version =
(DateTime.Now.Ticks / TimeSpan.TicksPerMillisecond);
+ version =
(DateTime.UtcNow.Ticks / TimeSpan.TicksPerMillisecond);
// old file format without version
number
else
version =
input.ReadLong();
// read version
Modified: incubator/lucene.net/trunk/src/core/Index/Term.cs
URL:
http://svn.apache.org/viewvc/incubator/lucene.net/trunk/src/core/Index/Term.cs?rev=1351173r1=1351172r2=1351173view=diff
==
--- incubator/lucene.net/trunk/src/core/Index/Term.cs (original)
+++ incubator/lucene.net/trunk/src/core/Index/Term.cs Sun Jun 17
22:21:07
2012
@@ -141,12 +141,12 @@ namespace Lucene.Net.Index
return String.CompareOrdinal(field,
other.field);
}
- /// summaryResets the field and text of a Term.
/summary
- internal void Set(System.String fld, System.String txt)
- {
- field = fld;
- text = txt;
- }
+/ summaryResets the field and text of a
Re: Lets talk graduation
Thanks Prescott. I noticed that we need to elect someone as Chair/VP for the project, someone to be a representative for our collective PMC to the board. Unless I'm mistaken, the job entails the quarterly report to the board and communication with the board when a new PMC member is added or the chair is being changed. Looking through the history of board reports we've done in the incubator, I've noticed that Prescott has largely been the one to put those together in a timely fashion. Since Prescott has always been an active member as well, I think he's an ideal candidate for the roll as VP for Lucene.NET. It doesn't seem much different from the role he's already been involved in. Any objections? Thanks, Christopher On Fri, Jun 15, 2012 at 1:15 PM, Prescott Nasser geobmx...@hotmail.comwrote: https://cwiki.apache.org/confluence/display/LUCENENET/Graduation+-+Resolution+Template Stefan, I think you've more than proved your value. +1
Re: svn commit: r1350178 - /incubator/lucene.net/trunk/src/core/Store/FSDirectory.cs
That comment is correct. We don't have support for NIOFSDirectory in .NET (and the JVM support for it in windows has a major bug). We also don't support MMapDirectory, because we haven't bothered to support it yet. I think digy ported it once, but it didn't add any speed benefits, and was actually fairly slower than the FSDirectory classes. It wasn't that long ago that we had the string constructors for Directory classes. I think they were in the java code and then replace with File (DirectoryInfo for .NET). I've always hated passing in DirectoryInfo, and I don't really understand why it's in the code. It doesn't seem to give much added benefit, if any. You can pass a string that is a path to an existing file and it will still create the DirectoryInfo object. I would think (but don't know) it would be better for performance to *not* use the File and Directory classes (I'm actually not sure how deep the usages of these classes go, so I'm not sure what difference it would make), since it results in added pressure on the GC with the extra object creations. +1 to this. On Thu, Jun 14, 2012 at 5:25 AM, Itamar Syn-Hershko ita...@code972.comwrote: I'd assume so, at least partially I just copy-pasted from one method below On Thu, Jun 14, 2012 at 2:52 PM, Stefan Bodewig bode...@apache.org wrote: On 2012-06-14, synhers...@apache.org wrote: /// p/Currently this returns see cref=SimpleFSDirectory / as /// NIOFSDirectory is currently not supported. /// /// p/bNOTE/b: this method may suddenly change which /// implementation is returned from release to release, in /// the event that higher performance defaults become /// possible; if the precise implementation is important to /// your application, please instantiate it directly, /// instead. On 64 bit systems, it may also good to /// return see cref=MMapDirectory /, but this is disabled /// because of officially missing unmap support in Java. /// For optimal performance you should consider using /// this implementation on 64 bit JVMs. Does this apply to the .NET code? Stefan
Re: Corrupt index
Well, the only thing I see is that there is no place where writer.Commit()
is called in the delegate assigned to corpusReader.OnDocument. I know that
lucene is very transactional, and at least in 3.x, the writer will never
auto commit to the index. You can write millions of documents, but if
commit is never called, those documents aren't actually part of the index.
Committing isn't a cheap operation, so you definitely don't want to do it
on every document.
You can test it yourself with this (naive) solution. Right below the
writer.SetUseCompoundFile(false) line, add int numDocsAdded = 0;. At the
end of the corpusReader.OnDocument delegate add:
// Example only. I wouldn't suggest committing this often
if(++numDocsAdded % 5 == 0)
{
writer.Commit();
}
I had the application crash for real on this file:
http://dumps.wikimedia.org/gawiktionary/20120613/gawiktionary-20120613-pages-meta-history.xml.bz2,
about 20% into the operation. Without the commit, the index is empty. Add
it in, and I get 755 files in the index after it crashes.
Thanks,
Christopher
On Wed, Jun 13, 2012 at 6:13 PM, Itamar Syn-Hershko ita...@code972.comwrote:
Yes, reproduced in first try. See attached program - I referenced it to
current trunk.
On Thu, Jun 14, 2012 at 3:54 AM, Itamar Syn-Hershko ita...@code972.comwrote:
Christopher,
I used the IndexBuilder app from here
https://github.com/synhershko/Talks/tree/master/LuceneNeatThings with a
8.5GB wikipedia dump.
After running for 2.5 days I had to forcefully close it (infinite loop in
the wiki-markdown parser at 92%, go figure), and the 40-something GB index
I had by then was unusable. I then was able to reproduce this
Please note I now added a few safe-guards you might want to remove to
make sure the app really crashes on process kill.
I'll try to come up with a better way to reproduce this - hopefully Mike
will be able to suggest better ways than manual process kill...
On Thu, Jun 14, 2012 at 1:41 AM, Christopher Currens
currens.ch...@gmail.com wrote:
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
ita...@code972.com
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
Re: Lets talk graduation
I've gone back and forth on whether I think we're ready for graduation or not. I had always felt like we weren't because the project isn't as active as I'd like it to be. However, I think I've been looking at it wrong. We've got a good enough process and we *have* made progress. If anything, graduating might add an urgency to the project when things get slow, since we'd be an official project and more would be expected. I don't think anybody wants the project to end up like it did last time, before we gave it a reboot. I'm up for starting this process, but I don't want it to take any time away from getting 3.0.3 released. Thanks, Christopher On Thu, Jun 14, 2012 at 9:06 AM, Benson Margulies bimargul...@gmail.comwrote: As a mentor, it's my job argue with Itamar a bit. It's not just semantics. We don't incubate projects indefinitely. I think that you all are good to go. The transition is not very much work. Please do draft a resolution and conduct a vote in the community, and we can then take it to the incubator PMC. On Thu, Jun 14, 2012 at 11:35 AM, Itamar Syn-Hershko ita...@code972.com wrote: IMHO, whatever brings more attention to the project, and I'm not sure graduation is what this project needs right now. In the end it's just semantics. I'd focus those efforts on getting more work done and having more frequent releases. Hence our proposition to sponsor dev, which still stands. On Thu, Jun 14, 2012 at 6:24 PM, Prescott Nasser geobmx...@hotmail.com wrote: I think with the addition of two new committers we've made some progress in community growth. I think we'll have 3.0.3 out the door soon - are there any other items we think we need to address before looking to graduate? ~P
Re: Releasing 3.0.3
I can't guarantee that the code is 100% in compliance with java 3.0.3. All changes that could be ported have been ported in core and most contrib projects. There are a few things that should at least be discussed regarding the compatibility in core: Occur (BooleanClause) in java is converted to an enum, from static readonly methods on a class. The reason that was never ported was because we can't override ToString() on an enum, even with extension methods and/or type converters. Currently, MUST evaluates to +, SHOULD to , and MUST_NOT to -. I'd double check this, but I think that the ToString() on occur is only used when creating string representations of a query. So, in theory, we could replace the usages in that location, and make the conversion to enum. This isn't a high-priority, especially since the fields are static readonly, this likely doesn't affect performance much or at all. FuzzyQuery uses java.util.PriorityQueueT which doesn't exists in .NET. I think we wind up using a SortedList, which was just a temporary measure that I wanted to make sure was fixed before release. I've tried to subclass from Util.PriorityQueueT, but it breaks a few tests. The current setup with SortedList works fine, but it's slower O(n) instead of O(log n) I think for some actions, and it doesn't support duplicate keys...which is bad. SegmentInfos inherits from a thread-safe collection in java (Vector). We could have used SynchronizedCollectionT and inherit from that, but I chose not to. I'm don't actually believe that lucene relies on the fact that Vector is ThreadSafe; instead, handling synchronization on its own. However, it's worth checking into, even though there are no tests that fail. Perhaps try to write one? IDK, there's a lot of multi-threaded tests, and I've yet to see a failure that's related to this. All intermittent tests that currently fail, do so for other reasons. Also, in this class, there are a few places where it should be returning a read-only HashSet, instead of returning a mutable one. === Open issues: I wanted to talk about the issues that are assigned, but just haven't had time. I think we really need to triage what is actually important and focus on that. I think I'll briefly just comment on a few of these and I hope to find out what you guys think of the open issues as well. I think can be moved to 3.5: = LUCENENET- 439 - Correctly Rethrow exceptions in C# LUCENENET- 436 - Refactor Deprecated Code inside of tests LUCENENET- 435 - Fix the test suite for Lucene.Net Core (java lucene has refactored a lot of their test suite. I think this should be backlogged) LUCENENET- 467 - .NETify the public API where appropriate -- Some of this has already been done, but it's not critical to a release. LUCENENET- 456 - Create a Build Target that outputs compiled artifacts in apache release format These are of medium importance = LUCENENET- 446 - Make Lucene.Net CLS Compliant -- The major issues with this have been more-or-less solved. The basic public API is almost completely CLS-compliant, except for usages of sbyte in FieldCacheRangeFilter and VerifyingLockFactory. Almost all classes can be used in other languages. There are 58 CLS naming issues, but most of them deal with protected members. If consumers were to use the library as is without customization, it's not blocking. However, it's not ideal to leave these issues in the release. LUCENENET- 337 - TokenAttribute for Selectively Including Tokens in Length Norm -- This is just a patch. I'm actually not sure what it does, so I haven't committed it to trunk because of that. High priority: These should be fixed or looked over before releasing = LUCENENET- 484 - Some possibly major tests intermittently fail -- Obviously, we should try and have a test suite that consistently passes. There are only two that fail now, I think. LUCENENET- 493 - Make lucene.net culture insensitive (like the java version) LUCENENET- 490 - QueryParser is culture-sensitive -- These two above are fairly important. I don't know to what extent java lucene is culture insensitive, though, and until I do some tests, I don't want to jump in and start changing things. There are culture sensitive tests in the test suite, but they don't run because of JUnit and NUnit differences. LUCENENET- 470 - Change Getxxx() and Setxxx() methods to .NET Properties -- This is practically done. I think there are only a few places where this should be updated. I only put this in high priority, because the API changes between 2.9 and 3.x are the perfect time to do this. Almost all obvious ones have been changed already. There are a few others like [typename].Size() that could probably be changed as well, but those would have to be manually found. Other's opinions and insights are appreciated. Thanks, Christopher On Thu, Jun 14, 2012 at 8:58 AM, Prescott Nasser
[jira] [Resolved] (LUCENENET-490) QueryParser is culture-sensitive
[ https://issues.apache.org/jira/browse/LUCENENET-490?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Christopher Currens resolved LUCENENET-490. --- Resolution: Fixed That is how it used to be. I believe I caused this regression in LUCENENET-478 when I re-ported QueryParser. If the LocalizedTestCase class worked correctly, we would have caught this earlier, I think. QueryParser is culture-sensitive Key: LUCENENET-490 URL: https://issues.apache.org/jira/browse/LUCENENET-490 Project: Lucene.Net Issue Type: Bug Affects Versions: Lucene.Net 3.0.3 Environment: CurrentCulture = sv-SE, CurrentUICulture = en-US. Reporter: Simon Svensson Priority: Minor Fix For: Lucene.Net 3.0.3 The QueryParser calls Single.Parse which is culture-sensitive. This will fail on cultures using other decimal separators (e.g. Swedish [sv-SE]). This does not affect 2.9.4; it calls SupportClass.Single.Parse. This looks related to LUCENENET-285. -- 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-480) Investigate what needs to happen to make both .NET 3.5 and 4.0 builds possible
[
https://issues.apache.org/jira/browse/LUCENENET-480?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13295239#comment-13295239
]
Christopher Currens commented on LUCENENET-480:
---
I'm assuming we're going to define some sort of symbol to compile code if it's
3.5 vs 4.0. If so, we can do a few things to make it easier.
1. We can. The only reason we're using the interface is because Java is. I
can see in the future this might be a problem if we has to use a set class that
was not HashSet...but at least not it's not a problem. Alternatively, we can
write our own ISet class based on the .NET 4.0 one, and use a class that wraps
HashSet and implements ISet.
2. I think the only way to do this one is write our own, as you said.
3. We can just define these in the support class, when using .NET 3.5
{code}
public delegate TResult FuncT1, T2, T3, T4, T5, T6, T7, T8, T9, TResult(T1
arg1, T2 arg2, T3 arg3, T4 arg4,
T5
arg5, T6 arg6, T7 arg7, T8 arg8, T9 arg9)
public delegate TResult FuncT1, T2, T3, T4, T5, T6, T7, T8, T9, T10,
TResult(T1 arg1, T2 arg2, T3 arg3, T4 arg4,
T5 arg5, T6 arg6, T7 arg7, T8 arg8, T9 arg9, T10 arg10)
{code}
4. We can either use Digy's (I think it uses a WeakHashTable) or we can write
our own (more work), using Thread.AllocateDataSlot(). I believe that is how it
is done internally in .NET 4.
5. ParallelMultiSearcher does have the biggest changes between .NET 3.5 (and
actually Java's version of the class, because of the use of Tasks instead of
manually spawning threads). I feel like we could remove it from the 3.5
version (at least for now), or have two versions of 3.5, where one has a
dependency on the TPL for 3.5.
Investigate what needs to happen to make both .NET 3.5 and 4.0 builds possible
--
Key: LUCENENET-480
URL: https://issues.apache.org/jira/browse/LUCENENET-480
Project: Lucene.Net
Issue Type: Task
Components: Lucene.Net Contrib, Lucene.Net Core, Lucene.Net Demo,
Lucene.Net Test
Affects Versions: Lucene.Net 2.9.4, Lucene.Net 2.9.4g, Lucene.Net 3.0.3
Reporter: Christopher Currens
We need to investigate what needs to be done with the source to be able to
support both a .NET 3.5 and 4.0 build. There was some concern from at least
one member of the community ([see
here|http://mail-archives.apache.org/mod_mbox/lucene-lucene-net-dev/201202.mbox/%3C004b01cce111$871f4990$955ddcb0$@fr%3E])
that we've alienated some of our user base by making such a heavy jump from
2.0 to 4.0. There are major benefits to using 4.0 over the 2.0-based
runtimes, specifically FAR superior memory management, particularly with the
LOH, where Lucene.NET has had major trouble with in the past.
Based on what has been done with Lucene.NET 3.0.3, we can't (easily) drop
.NET 3.5/3.0 libraries and go back to 2.0. HashSetT and ISetT is used
extensively in the code, that would be a major blocker to get done. I
suppose it could be possible, but there hasn't been a whole lot of talk about
what runtimes we intend to support. The big change between lucene 2.x and
3.x for java was also a change in runtimes, that allowed generics and enums
to be used in the base code. We have a similar situation with the API (it's
substantially different, with the addition of properties alone) for this next
version of Lucene.NET, so I think it's reasonable to at least make a
permanent move from 2.0 to 3.5, though that's only my opinion, hasn't been
discussed with the committers.
It seems that supporting 3.5 and 4.0 should be fairly easy, and is a decent
compromise in supporting both a 2.0 and 4.0 runtime. At the very least, we
should try our best to support 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
Re: Corrupt index
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 ita...@code972.com 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
[jira] [Commented] (LUCENENET-493) Make lucene.net culture insensitive (like the java version)
[ https://issues.apache.org/jira/browse/LUCENENET-493?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13293189#comment-13293189 ] Christopher Currens commented on LUCENENET-493: --- This is rather annoying, actually. Java has tests for different cultures wired into the test suite. Interestingly enough, so do we, but because of the differences between JUnit and NUnit (namely attribute based test discovery), we can't override the test running implementation in the same way java does. So, the code we've ported for testing cultures does not work...period. NUnit supports changing the cultures via attributes, but only a single culture. MbUnit allows multiple cultures and will run the test each time in that culture. We should find a workaround. Make lucene.net culture insensitive (like the java version) --- Key: LUCENENET-493 URL: https://issues.apache.org/jira/browse/LUCENENET-493 Project: Lucene.Net Issue Type: Bug Components: Lucene.Net Core, Lucene.Net Test Affects Versions: Lucene.Net 3.0.3 Reporter: Luc Vanlerberghe Labels: patch Fix For: Lucene.Net 3.0.3 Attachments: Lucenenet-493.patch In Java, conversion of the basic types to and from strings is locale (culture) independent. For localized input/output one needs to use the classes in the java.text package. In .Net, conversion of the basic types to and from strings depends on the default Culture. Otherwise you have to specify CultureInfo.InvariantCulture explicitly. Some of the testcases in lucene.net fail if they are not run on a machine with culture set to US. In the current version of lucene.net there are patches here and there that try to correct for some specific cases by using string replacement (like System.Double.Parse(s.Replace(., CultureInfo.CurrentCulture.NumberFormat.NumberDecimalSeparator)), but that seems really ugly. I submit a patch here that removes the old workarounds and replaces them by calls to classes in the Lucene.Net.Support namespace that try to handle the conversions in a compatible way. -- 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-490) QueryParser is culture-sensitive
[ https://issues.apache.org/jira/browse/LUCENENET-490?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Christopher Currens updated LUCENENET-490: -- Fix Version/s: Lucene.Net 3.0.3 QueryParser is culture-sensitive Key: LUCENENET-490 URL: https://issues.apache.org/jira/browse/LUCENENET-490 Project: Lucene.Net Issue Type: Bug Affects Versions: Lucene.Net 3.0.3 Environment: CurrentCulture = sv-SE, CurrentUICulture = en-US. Reporter: Simon Svensson Priority: Minor Fix For: Lucene.Net 3.0.3 The QueryParser calls Single.Parse which is culture-sensitive. This will fail on cultures using other decimal separators (e.g. Swedish [sv-SE]). This does not affect 2.9.4; it calls SupportClass.Single.Parse. This looks related to LUCENENET-285. -- 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-484) Some possibly major tests intermittently fail
[ https://issues.apache.org/jira/browse/LUCENENET-484?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13286699#comment-13286699 ] Christopher Currens commented on LUCENENET-484: --- Thanks Luc. This is great stuff. I'll run the patch on my local box and double check everything. Your help with this is appreciated by all of us! Some possibly major tests intermittently fail -- Key: LUCENENET-484 URL: https://issues.apache.org/jira/browse/LUCENENET-484 Project: Lucene.Net Issue Type: Bug Components: Lucene.Net Core, Lucene.Net Test Affects Versions: Lucene.Net 3.0.3 Reporter: Christopher Currens Fix For: Lucene.Net 3.0.3 Attachments: Lucenenet-484-WeakDictionary.patch, Lucenenet-484-WeakDictionaryTests.patch These tests will fail intermittently in Debug or Release mode, in the core test suite: # -Lucene.Net.Index:- #- -TestConcurrentMergeScheduler.TestFlushExceptions- # Lucene.Net.Store: #- TestLockFactory.TestStressLocks # Lucene.Net.Search: #- TestSort.TestParallelMultiSort # Lucene.Net.Util: #- TestFieldCacheSanityChecker.TestInsanity1 #- TestFieldCacheSanityChecker.TestInsanity2 #- (It's possible all of the insanity tests fail at one point or another) # Lucene.Net.Support #- TestWeakHashTableMultiThreadAccess.Test TestWeakHashTableMultiThreadAccess should be fine to remove along with the WeakHashTable in the Support namespace, since it's been replaced with WeakDictionary. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (LUCENENET-484) Some possibly major tests intermittently fail
[ https://issues.apache.org/jira/browse/LUCENENET-484?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Christopher Currens updated LUCENENET-484: -- Description: These tests will fail intermittently in Debug or Release mode, in the core test suite: # -Lucene.Net.Index:- #- -TestConcurrentMergeScheduler.TestFlushExceptions- # Lucene.Net.Store: #- TestLockFactory.TestStressLocks # Lucene.Net.Search: #- TestSort.TestParallelMultiSort # -Lucene.Net.Util:- #- -TestFieldCacheSanityChecker.TestInsanity1- #- -TestFieldCacheSanityChecker.TestInsanity2- #- -(It's possible all of the insanity tests fail at one point or another)- # -Lucene.Net.Support- #- -TestWeakHashTableMultiThreadAccess.Test- TestWeakHashTableMultiThreadAccess should be fine to remove along with the WeakHashTable in the Support namespace, since it's been replaced with WeakDictionary. was: These tests will fail intermittently in Debug or Release mode, in the core test suite: # -Lucene.Net.Index:- #- -TestConcurrentMergeScheduler.TestFlushExceptions- # Lucene.Net.Store: #- TestLockFactory.TestStressLocks # Lucene.Net.Search: #- TestSort.TestParallelMultiSort # Lucene.Net.Util: #- TestFieldCacheSanityChecker.TestInsanity1 #- TestFieldCacheSanityChecker.TestInsanity2 #- (It's possible all of the insanity tests fail at one point or another) # Lucene.Net.Support #- TestWeakHashTableMultiThreadAccess.Test TestWeakHashTableMultiThreadAccess should be fine to remove along with the WeakHashTable in the Support namespace, since it's been replaced with WeakDictionary. Environment: All Applied the patches. Getting closer to resolving this issue. Some possibly major tests intermittently fail -- Key: LUCENENET-484 URL: https://issues.apache.org/jira/browse/LUCENENET-484 Project: Lucene.Net Issue Type: Bug Components: Lucene.Net Core, Lucene.Net Test Affects Versions: Lucene.Net 3.0.3 Environment: All Reporter: Christopher Currens Fix For: Lucene.Net 3.0.3 Attachments: Lucenenet-484-WeakDictionary.patch, Lucenenet-484-WeakDictionaryTests.patch These tests will fail intermittently in Debug or Release mode, in the core test suite: # -Lucene.Net.Index:- #- -TestConcurrentMergeScheduler.TestFlushExceptions- # Lucene.Net.Store: #- TestLockFactory.TestStressLocks # Lucene.Net.Search: #- TestSort.TestParallelMultiSort # -Lucene.Net.Util:- #- -TestFieldCacheSanityChecker.TestInsanity1- #- -TestFieldCacheSanityChecker.TestInsanity2- #- -(It's possible all of the insanity tests fail at one point or another)- # -Lucene.Net.Support- #- -TestWeakHashTableMultiThreadAccess.Test- TestWeakHashTableMultiThreadAccess should be fine to remove along with the WeakHashTable in the Support namespace, since it's been replaced with WeakDictionary. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
Re: Metro port of Lucene.net
To clarify, that list is not everything missing from .NET for Metro, but rather the types in the 637 errors I found trying to compile lucene. On Wed, May 30, 2012 at 9:50 AM, Christopher Currens currens.ch...@gmail.com wrote: This MSDN page has some good information on it: http://msdn.microsoft.com/en-us/library/windows/apps/br230302(v=vs.110).aspx, though it's comprehensive, and not concise. This here: http://msdn.microsoft.com/en-us/library/windows/apps/br230232(v=vs.110).aspx is a listing of all the available namespaces and types (many are missing or added). I know that if you're using VS11, you can create a Portable Class Library to target different frameworks (much like the plans in LUCENENET-167 and LUCENENET-411). If you selected the .NET for Metro Style Apps alone, I currently get 637 errors. Here are the main classes/namespaces missing: -- System.SerializableAttribute -- System.NonSerializedAttribute -- System.ApplicationException -- System.Collection.ArrayList -- System.Converter -- System.Security.Cryptography -- System.IO.DirectoryInfo -- System.IO.FileInfo -- System.IO.FileAccess -- System.IO.FileStream -- System.Collections.Hashtable -- System.IClonable -- System.STAThreadAttribute -- System.SystemException -- System.Threading.ThreadPriority -- System.Threading.ThreadStart These are some hefty changes. The largest change is the loss of the serializable attribute. I'm actually not terribly familiar with the PCL, so I'm not sure if there's a conditional way to include things, or if preprocessor commands would be necessary. Thanks, Christopher -- On Wed, May 30, 2012 at 8:36 AM, Prescott Nasser geobmx...@hotmail.comwrote: Does anyone have a good reference for the limitations this will have? What libraries won't be accessible, etc? From: geobmx...@hotmail.com To: lucene-net-dev@lucene.apache.org Subject: RE: Metro port of Lucene.net Date: Wed, 30 May 2012 08:34:05 -0700 I haven't taken too much time to look into the limitations, but this should definitely be on the list of things to do. Date: Tue, 29 May 2012 21:18:33 -0700 Subject: Metro port of Lucene.net From: a...@kno.com To: lucene-net-dev@lucene.apache.org Wonder if there are plans to port Lucene.NET to the restricted Metro .NET libraries ? Thanks Arun
Re: Metro port of Lucene.net
This MSDN page has some good information on it: http://msdn.microsoft.com/en-us/library/windows/apps/br230302(v=vs.110).aspx, though it's comprehensive, and not concise. This here: http://msdn.microsoft.com/en-us/library/windows/apps/br230232(v=vs.110).aspx is a listing of all the available namespaces and types (many are missing or added). I know that if you're using VS11, you can create a Portable Class Library to target different frameworks (much like the plans in LUCENENET-167 and LUCENENET-411). If you selected the .NET for Metro Style Apps alone, I currently get 637 errors. Here are the main classes/namespaces missing: -- System.SerializableAttribute -- System.NonSerializedAttribute -- System.ApplicationException -- System.Collection.ArrayList -- System.Converter -- System.Security.Cryptography -- System.IO.DirectoryInfo -- System.IO.FileInfo -- System.IO.FileAccess -- System.IO.FileStream -- System.Collections.Hashtable -- System.IClonable -- System.STAThreadAttribute -- System.SystemException -- System.Threading.ThreadPriority -- System.Threading.ThreadStart These are some hefty changes. The largest change is the loss of the serializable attribute. I'm actually not terribly familiar with the PCL, so I'm not sure if there's a conditional way to include things, or if preprocessor commands would be necessary. Thanks, Christopher -- On Wed, May 30, 2012 at 8:36 AM, Prescott Nasser geobmx...@hotmail.comwrote: Does anyone have a good reference for the limitations this will have? What libraries won't be accessible, etc? From: geobmx...@hotmail.com To: lucene-net-dev@lucene.apache.org Subject: RE: Metro port of Lucene.net Date: Wed, 30 May 2012 08:34:05 -0700 I haven't taken too much time to look into the limitations, but this should definitely be on the list of things to do. Date: Tue, 29 May 2012 21:18:33 -0700 Subject: Metro port of Lucene.net From: a...@kno.com To: lucene-net-dev@lucene.apache.org Wonder if there are plans to port Lucene.NET to the restricted Metro .NET libraries ? Thanks Arun
Re: Plans for Hunspell integration (and: How do I build the trunk?)
Simon, build commit all release should work. However, we have one or two issues with our current trunk state, as you can see. It looks like an obsolete method was removed in IndexReader, but not all tests/projects compiled and run before it was committed. Not a huge issue at all, since you've seen it can easily be fixed (I've committed fixes to the things you've listed above to trunk already). I'll admit, that we *should* be able to build it using the command you've tried, but unfortunately, we're not in a state where that's possible. I use the command: build simple all release which will clean, build and generate an html report for the tests. It doesn't do stylecop rules, though you can do that after the fact with build rules all release. Make sure you have FxCop installed in the expected location (on my computer, this is C:\Program Files (x86)\Microsoft Fxcop 10.0), otherwise it will *look* like it succeeded, but actually, it will have not run the rules at all. I believe it's set to be a warning if FxCop doesn't exist. The same goes for Stylecop. Keep in mind you'll get warnings up the wazoo, but that's because the code is full of issues. We never did agree on a set of rules past use the ones Microsoft uses, so at this point, we're only asking people try to follow the rules they see in the current code...as ambiguous as that might be. I don't agree with all of the Microsoft rules, for example, but I would like to see a set of stylecop and resharper rules put together and stored in the repo. Anyway, as you might be able to tell, we do need some work done with our build scripts. Michael did a great job setting them up, but as the project has evolved, they've become slightly neglected, and there are a few problems. We also don't have any documentation with showing how to build lucene from the command-line, step by step. If you'd be willing to do some work in trying to clean them up or get documentation together, we definitely would need it. Perhaps, at the very least, you may create issues for these things in JIRA. As for your port of Hunspell, I would feel it would be best if it were added to the Analyzers project, so you can just import the code and tests into those respective projects. Past that, you won't need to update the build scripts, since it won't output any extra dlls or xmls that we would need to deal with. = For the record, though, if you WERE to create it as a separate project, this would be a normal workflow for it: Put the source in a folder such as: trunk/src/contrib/Hunspell Put the tests in a folder such as: trunk/test/contrib/Hunspell -- Make sure you sign BOTH output dlls with the signed name key in trunk/lib/Lucene.Net.snk Create the following solutions for your project in trunk/build/vs2010: -- contrib/Contrib.Hunspell.sln -- test/Contrib.Hunspell.Test.sln Add the Hunspell project to these existing solutions in trunk/build/vs2010: -- contrib/Contrib.All.sln -- test/Contrib.All.Test.sln Add/Update the build scripts in the trunk/build/scripts directory: -- Create a folder named Hunspell in this directory create a document.targets and project.targets with the correct paths (model it after an existing one) in Contrib/document.targets, add the documentation sources for your project to the existing list in Contrib/project.targets, add the Hunspell/projects.targets as an import in Contrib/Lucene.Net.Contrib.nuspec, add the dll and xml files to the existing list repeat the previous 3 steps with the target files in the All directory Thanks, Christopher On Sun, May 27, 2012 at 1:26 AM, Simon Svensson si...@devhost.se wrote: Hi, First of things first; thanks for the warm welcome. As mentioned earlier, I have ported lucene-hunspell[1], which allows hunspell dictionaries to be used for stemming, to Lucene.Net.Analysis.Hunspell[**2]. I'm using this with English and Swedish dictionaries, and I've got indications via commits, mails and questions that it is also used (or at least tried) with French and Croatian. It is my intentions to move this code into contrib, which brings the first of many questions; should it be added to Contrib.Analyzers, or a new project? I'm currently experimenting with the build environment and making sure that all tools work properly on my machine. However, I'm greeted with several execution errors when executing a build simple all release; tests for SimpleFacetedSearch and SpellChecker calls non-existant overload of IndexReader.Open and Memory tests have wrong assembly name and output path. The build will proceed if I fix these errors, but some tests fail. (one being TestQueryParser.TextWildCard with Query /term~0.7/ yielded /term~0.5/, expecting /term~0.7/). These tests do also fail in Resharpers unittest-runner. I've tried build commit all release (from the build information wiki page[3]) which fails with NCover v3 does not appear to be installed. This is correct; I've
Re: Plans for Hunspell integration (and: How do I build the trunk?)
I can't reproduce the failed tests in TestQueryParser.TestWildCard. Works for me in both debug and release builds, running via R# and Gallio. On Tue, May 29, 2012 at 10:45 AM, Prescott Nasser geobmx...@hotmail.comwrote: my intentions to move this code into contrib, which brings the first of many questions; should it be added to Contrib.Analyzers, or a new project? Analyzers sounds like the right space for it. I'm currently experimenting with the build environment and making sure that all tools work properly on my machine. However, I'm greeted with several execution errors when executing a build simple all release; tests for SimpleFacetedSearch and SpellChecker calls non-existant overload of IndexReader.Open and Memory tests have wrong assembly name and output path. The build will proceed if I fix these errors, but some tests fail. (one being TestQueryParser.TextWildCard with Query /term~0.7/ yielded /term~0.5/, expecting /term~0.7/). These tests do also fail in Resharpers unittest-runner. I'll try to take a look at this this week. We've mostly been focusing on the core, and I know that the contrib packages have started to fall to the wayside. We need to take a good look at them, make sure they are the right ports, and make the fixes to adjust to our api. If you do notice problems, I'd encourage you to at the very least throw up a JIRA issue. If it turns out it's not a problem, we can always close it. I've tried build commit all release (from the build information wiki page[3]) which fails with NCover v3 does not appear to be installed. This is correct; I've been unable to find a free version of a NCover v3. Is the commit build target perhaps only meant for build servers? I think it was Michael who did all the work around the build system, I still build the old fashioned way... VS2010 - right click, build. I've copied lib\StyleCop.4.5 to C:\Program Files (x86)\MSBuild\StyleCop\v4.5 to remove the stylecop-4.5-could-not-be-found warnings. I expect to get a gazillion stylecop-related warnings when building (stylecop has never really liked me), but get none at all. Is the code perfect, or are no rules applied? That's a good question, we discussed style cop at one point, but I don't think we every had a consensus on that.
Re: Welcome Itamar Syn-Hershko as a new committer
Welcome, Itamar! Glad to have you aboard. Thanks, Christopher On Tue, May 22, 2012 at 3:21 PM, Digy digyd...@gmail.com wrote: Welcome Itamar! DIGY -Original Message- From: Prescott Nasser [mailto:geobmx...@hotmail.com] Sent: Wednesday, May 23, 2012 12:06 AM To: lucene-net-dev@lucene.apache.org; lucene-net-u...@lucene.apache.org Subject: Welcome Itamar Syn-Hershko as a new committer Hey all, I'd like to officially welcome Itamar as a new committer. I know the community appreciates the work you've been doing with the Spatial contrib project and the past help you've provided on the mailing lists. Please join me in welcoming Itamar, ~Prescott - Checked by AVG - www.avg.com Version: 2012.0.1913 / Virus Database: 2425/5015 - Release Date: 05/22/12
[jira] [Commented] (LUCENENET-484) Some possibly major tests intermittently fail
[ https://issues.apache.org/jira/browse/LUCENENET-484?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13264032#comment-13264032 ] Christopher Currens commented on LUCENENET-484: --- Some of the tests I can only produce if a) I run it in Release mode, AND b) I run the *entire* test suite, not just the single test. Some possibly major tests intermittently fail -- Key: LUCENENET-484 URL: https://issues.apache.org/jira/browse/LUCENENET-484 Project: Lucene.Net Issue Type: Bug Components: Lucene.Net Core, Lucene.Net Test Affects Versions: Lucene.Net 3.0.3 Reporter: Christopher Currens Fix For: Lucene.Net 3.0.3 These tests will fail intermittently in Debug or Release mode, in the core test suite: # -Lucene.Net.Index:- #- -TestConcurrentMergeScheduler.TestFlushExceptions- # Lucene.Net.Store: #- TestLockFactory.TestStressLocks # Lucene.Net.Search: #- TestSort.TestParallelMultiSort # Lucene.Net.Util: #- TestFieldCacheSanityChecker.TestInsanity1 #- TestFieldCacheSanityChecker.TestInsanity2 #- (It's possible all of the insanity tests fail at one point or another) # Lucene.Net.Support #- TestWeakHashTableMultiThreadAccess.Test TestWeakHashTableMultiThreadAccess should be fine to remove along with the WeakHashTable in the Support namespace, since it's been replaced with WeakDictionary. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
Re: cms
I'll take a look at it. On Mon, Apr 23, 2012 at 1:28 PM, Prescott Nasser geobmx...@hotmail.comwrote: 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
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 geobmx...@hotmail.comwrote: 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=990167am I looking 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-dev@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.comwrote: 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-dev@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.
[jira] [Updated] (LUCENENET-485) IndexOutOfRangeException in FrenchStemmer
[
https://issues.apache.org/jira/browse/LUCENENET-485?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Christopher Currens updated LUCENENET-485:
--
Attachment: TestFrenchAnalyzer.cs.patch
Here's a patch for tests that should pass, they fail with what is in trunk.
These tests pass in Java 3.0.3.
Patch was made from the trunk\test\contrib\Analyzers\Fr directory.
IndexOutOfRangeException in FrenchStemmer
-
Key: LUCENENET-485
URL: https://issues.apache.org/jira/browse/LUCENENET-485
Project: Lucene.Net
Issue Type: Bug
Components: Lucene.Net Contrib
Affects Versions: Lucene.Net 3.0.3
Reporter: Christopher Currens
Fix For: Lucene.Net 3.0.3
Attachments: TestFrenchAnalyzer.cs.patch, tt.diff
{quote}
Hi list,
I am not sure how to report bugs, or even if anybody is interested in bug
reports. However, I have been playing with lucene lately, and found out an
implementation bug in the Frenchstemmer
(/src/contrib/Analyzers/Fr/FrenchStemmer.cs). Whenever I tried to add a new
document to an index, I got an index out of range error. So I looked at the
code and fixed that issue: see my diff file attached.
Please note that I also changed a few funky characters to unicode notation.
The code worked well with the funky characters, but I think it just looks
better with the \uxxx bits...
Anyways, the important bits is the replacement of a couple of sb.Insert by
sb.Append.
I hope this helps.
Cheers,
Sylvain
{quote}
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (LUCENENET-483) Spatial Search skipping records when one location is close to origin, another one is away and radius is wider
[
https://issues.apache.org/jira/browse/LUCENENET-483?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Christopher Currens updated LUCENENET-483:
--
Fix Version/s: Lucene.Net 3.0.3
Spatial Search skipping records when one location is close to origin, another
one is away and radius is wider
-
Key: LUCENENET-483
URL: https://issues.apache.org/jira/browse/LUCENENET-483
Project: Lucene.Net
Issue Type: Bug
Components: Lucene.Net Contrib
Affects Versions: Lucene.Net 2.9.4, Lucene.Net 2.9.4g
Environment: .Net framework 4.0
Reporter: Aleksandar Panov
Labels: lucene, spatialsearch
Fix For: Lucene.Net 3.0.3
Running a spatial query against two locations where one location is close to
origin (less than a mile), another one is away (24 miles) and radius is wider
(52 miles) returns only one result. Running query with a bit wider radius
(53.8) returns 2 results.
IMPORTANT UPDATE: Problem can't be reproduced in Java, with using original
Lucene.Spatial (2.9.4 version) library.
{code}
// Origin
private double _lat = 42.350153;
private double _lng = -71.061667;
private const string LatField = lat;
private const string LngField = lng;
//Locations
AddPoint(writer, Location 1, 42.0, -71.0); //24 miles away from
origin
AddPoint(writer, Location 2, 42.35, -71.06); //less than a mile
[TestMethod]
public void TestAntiM()
{
_directory = new RAMDirectory();
var writer = new IndexWriter(_directory, new
WhitespaceAnalyzer(), true, IndexWriter.MaxFieldLength.UNLIMITED);
SetUpPlotter(2, 15);
AddData(writer);
_searcher = new IndexSearcher(_directory, true);
//const double miles = 53.8; // Correct. Returns 2 Locations.
const double miles = 52; // Incorrect. Returns 1 Location.
Console.WriteLine(testAntiM);
// create a distance query
var dq = new DistanceQueryBuilder(_lat, _lng, miles, LatField,
LngField, CartesianTierPlotter.DefaltFieldPrefix, true);
Console.WriteLine(dq);
//create a term query to search against all documents
Query tq = new TermQuery(new Term(metafile, doc));
var dsort = new DistanceFieldComparatorSource(dq.DistanceFilter);
Sort sort = new Sort(new SortField(foo, dsort, false));
// Perform the search, using the term query, the distance filter,
and the
// distance sort
TopDocs hits = _searcher.Search(tq, dq.Filter, 1000, sort);
int results = hits.TotalHits;
ScoreDoc[] scoreDocs = hits.ScoreDocs;
// Get a list of distances
Dictionaryint, Double distances = dq.DistanceFilter.Distances;
Console.WriteLine(Distance Filter filtered: + distances.Count);
Console.WriteLine(Results: + results);
Console.WriteLine(=);
Console.WriteLine(Distances should be 2 + distances.Count);
Console.WriteLine(Results should be 2 + results);
Assert.AreEqual(2, distances.Count); // fixed a store of only
needed distances
Assert.AreEqual(2, results);
}
{code}
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
Re: user feedback on 3.0.3
Okay, I looked over the properties, and after a few slight changes, I think they nearly all of them are within reason (either doing a small mathematical computation or null check). I'm actually very eager to start hearing feedback on the API changes. I think most people will be able to figure it out easily. It would also be nice if people could find bugs we could fix before releasing it. Actually, it would be nice if people knew there was a 3.0.3 version coming out. So, I say go for it. Thanks, Christopher On Thu, Apr 12, 2012 at 6:14 PM, Christopher Currens currens.ch...@gmail.com wrote: Michael, Not quite yet. I think I was overly aggressive with some of the conversions I made with Get/Set functions to Properties, and I want to revert any that I find do too much work back into a method. After that, I think most of the API changes left to make are fairly minimal, and it would be nice to get some feedback from the community. Maybe I'll work on those properties tonight. Thanks, Christopher On Thu, Apr 12, 2012 at 5:17 PM, Michael Herndon mhern...@wickedsoftware.net wrote: Chris, Prescotts, others awesome committers working on trunk, Do you wish the project to start attempting to gain attention for 3.0.3 and possibly gain some community testing / wear and tear on it? Also are there any pressing matters you wish to gain more feedback on from the community? Our twitter account has been too silent. -Michael P.S. really great work on trunk. I've been playing with the bits as time permits and might even use the upcoming release at work. If I do, I'll put some time into contributing some docs / tutorials.
[jira] [Created] (LUCENENET-484) Some possibly major tests intermittently fail
Some possibly major tests intermittently fail -- Key: LUCENENET-484 URL: https://issues.apache.org/jira/browse/LUCENENET-484 Project: Lucene.Net Issue Type: Bug Components: Lucene.Net Core, Lucene.Net Test Affects Versions: Lucene.Net 3.0.3 Reporter: Christopher Currens Fix For: Lucene.Net 3.0.3 These tests will fail intermittently in Debug or Release mode, in the core test suite: # Lucene.Net.Index: #- TestConcurrentMergeScheduler.TestFlushExceptions # Lucene.Net.Store: #- TestLockFactory.TestStressLocks # Lucene.Net.Search: #- TestSort.TestParallelMultiSort # Lucene.Net.Util: #- TestFieldCacheSanityChecker.TestInsanity1 #- TestFieldCacheSanityChecker.TestInsanity2 #- (It's possible all of the insanity tests fail at one point or another) # Lucene.Net.Support #- TestWeakHashTableMultiThreadAccess.Test TestWeakHashTableMultiThreadAccess should be fine to remove along with the WeakHashTable in the Support namespace, since it's been replaced with WeakDictionary. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (LUCENENET-484) Some possibly major tests intermittently fail
[
https://issues.apache.org/jira/browse/LUCENENET-484?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Christopher Currens updated LUCENENET-484:
--
Description:
These tests will fail intermittently in Debug or Release mode, in the core test
suite:
# -Lucene.Net.Index:-
#- -TestConcurrentMergeScheduler.TestFlushExceptions-
# Lucene.Net.Store:
#- TestLockFactory.TestStressLocks
# Lucene.Net.Search:
#- TestSort.TestParallelMultiSort
# Lucene.Net.Util:
#- TestFieldCacheSanityChecker.TestInsanity1
#- TestFieldCacheSanityChecker.TestInsanity2
#- (It's possible all of the insanity tests fail at one point or another)
# Lucene.Net.Support
#- TestWeakHashTableMultiThreadAccess.Test
TestWeakHashTableMultiThreadAccess should be fine to remove along with the
WeakHashTable in the Support namespace, since it's been replaced with
WeakDictionary.
was:
These tests will fail intermittently in Debug or Release mode, in the core test
suite:
# Lucene.Net.Index:
#- TestConcurrentMergeScheduler.TestFlushExceptions
# Lucene.Net.Store:
#- TestLockFactory.TestStressLocks
# Lucene.Net.Search:
#- TestSort.TestParallelMultiSort
# Lucene.Net.Util:
#- TestFieldCacheSanityChecker.TestInsanity1
#- TestFieldCacheSanityChecker.TestInsanity2
#- (It's possible all of the insanity tests fail at one point or another)
# Lucene.Net.Support
#- TestWeakHashTableMultiThreadAccess.Test
TestWeakHashTableMultiThreadAccess should be fine to remove along with the
WeakHashTable in the Support namespace, since it's been replaced with
WeakDictionary.
So, I figured out the issue with the ConcurrentMergeScheduler, it was simply a
port issue for the actual Test. I had to add a workaround in
{{FailOnlyOnFlush.Eval(Directory)}}, since java would compare stack frame with
main (the thread running the test, it seems), and only execute the code if
that was the case. That doesn't exactly work in .NET code, so instead, I
inverted the check too look for the thread name not containing Merge Thread.
I can no longer reproduce it at all, where I could before every time.
Some possibly major tests intermittently fail
--
Key: LUCENENET-484
URL: https://issues.apache.org/jira/browse/LUCENENET-484
Project: Lucene.Net
Issue Type: Bug
Components: Lucene.Net Core, Lucene.Net Test
Affects Versions: Lucene.Net 3.0.3
Reporter: Christopher Currens
Fix For: Lucene.Net 3.0.3
These tests will fail intermittently in Debug or Release mode, in the core
test suite:
# -Lucene.Net.Index:-
#- -TestConcurrentMergeScheduler.TestFlushExceptions-
# Lucene.Net.Store:
#- TestLockFactory.TestStressLocks
# Lucene.Net.Search:
#- TestSort.TestParallelMultiSort
# Lucene.Net.Util:
#- TestFieldCacheSanityChecker.TestInsanity1
#- TestFieldCacheSanityChecker.TestInsanity2
#- (It's possible all of the insanity tests fail at one point or another)
# Lucene.Net.Support
#- TestWeakHashTableMultiThreadAccess.Test
TestWeakHashTableMultiThreadAccess should be fine to remove along with the
WeakHashTable in the Support namespace, since it's been replaced with
WeakDictionary.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (LUCENENET-470) Change Getxxx() and Setxxx() methods to .NET Properties
[
https://issues.apache.org/jira/browse/LUCENENET-470?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13249624#comment-13249624
]
Christopher Currens commented on LUCENENET-470:
---
I understand your concern. We've had a lot of discussion about whether to
abandon the Java style API for one more friendly to .NET, one of the more in
depth ones where we seemed to finally come to a consensus was here [in this
mailing list thread and its
history|http://mail-archives.apache.org/mod_mbox/lucene-lucene-net-dev/201112.mbox/%3ccajtrbsq8ind7yk2f-j7xuhgkjemm9jff0in28mkt+jv_evq...@mail.gmail.com%3E].
Ultimately .NET properties are nothing more than syntactical sugar, since
there's no real performance benefit over using a Get/Set method. Either one
has just as likely of a change to be inlined than the other. However, it makes
Lucene.NET stand out from the rest of the .NET libraries, where .NET features
are used (and rightly so).
I'm not sure that deviation from the original API is a valid reason not to
implement this feature (not to mention, it's been partially implemented
already), considering the plan is and always has been implementing a newer .NET
API. There have been considerations to emulate the Java API on top of the new
API in the future for people that want that, but IMO it's not really worth it.
Either way, I don't want to get into a discussion about whether to stick to the
java API here, that's something for the mailing lists. If you have objections
to the ultimate goal of the project, it would be best you voice them on the dev
mailing list. I don't think our community is as talkative as it could be, and
we only get input from non-committers from just a few vocal community members.
We'd love to hear your input on our goals.
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] [Resolved] (LUCENENET-481) Port Contrib.MemoryIndex
[ https://issues.apache.org/jira/browse/LUCENENET-481?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Christopher Currens resolved LUCENENET-481. --- Resolution: Fixed I hope you don't mind, but I had so much free time this week, I went ahead and ported this. It's been a few days since I mentioned I might be doing this on the mailing list in the email titled Lucene.NET 3.0.3 Release Date, so I hope you had at least seen it before this happened (no one has yet to respond to the email). Tests and Library have been ported. Everything looks pretty good, There were a few weird things related to term comparisons, so there are some small minor differences between the Java, but it's fairly obvious with the constraints listed. 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] [Commented] (LUCENENET-482) Lucene out of Memory issue
[ https://issues.apache.org/jira/browse/LUCENENET-482?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13240232#comment-13240232 ] Christopher Currens commented on LUCENENET-482: --- The compiled binaries can be found here: http://www.apache.org/dist/incubator/lucene.net/binaries/2.9.2-incubating/ The source can be found here: http://www.apache.org/dist/incubator/lucene.net/source/2.9.2-incubating/ 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] [Commented] (LUCENENET-481) Port Contrib.MemoryIndex
[
https://issues.apache.org/jira/browse/LUCENENET-481?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13238661#comment-13238661
]
Christopher Currens commented on LUCENENET-481:
---
If you're talking about the termComparator, that wasn't made generic until 3.1.
The comparator in 3.0.3 can't be ported the way it is anyway because of Java's
type system, but I just want to make sure you're porting 3.0.3 to keep
everything in line with the rest of the .NET versions. You'll find that the
3.x version in java uses a few other additions to the main lucene library that
aren't yet available in 3.0.3.
This problem should be easily solved without reflection. The comparator used
basically requires that it be a {{KeyValuePairTKey, TValue}}, or more
specifically, a {{KeyValuePairstring, TValue}}. There are actually only 2
different types that uses that termComparator: {{KeyValuePairstring,
ArrayIntList[]}} and {{KeyValuePairstring,Info[]}}. An exception to that is
the {{private static sort(DictionaryK,V)}} method, but that can be solved
with a static method, a type constraint (which is already implied in the java
version) and some type inference (as a nicety). I had ported most of this at
one point (somewhere on my home computer), and if memory serves me correctly, I
think this is how I solved this problem.
You can use this if you want:
{code}
class KvpComparer
{
public static int ComparerTKey, TValue(KeyValuePairTKey, TValue x,
KeyValuePairTKey, TValue y)
where TKey : IComparableTKey
{
if (x.Equals(y)) return 0;
return x.Key.CompareTo(y.Key);
}
}
sealed class KvpComparerT : KvpComparer, IComparerKeyValuePairstring, T
{
public int Compare(KeyValuePairstring, T x, KeyValuePairstring, T y)
{
return Comparer(x, y);
}
}
{code}
You can create the two instances you need for the {{string,Info}} and
{{string,ArrayIntList}} types. For the {{Map.EntryK,V[] sort(HashMapK,V
map}} method, constrain {{K}} to {{IComparableK}}, and then you can use it
like {{Array.Sort(entries, KvpComparer.Compare)}}, which is nice because it's
one less object you need to create (or more) for each type passed into sort.
Alternatively, since the {{sort}} method is private, and only uses those two
types, you can just change the signature and pass in one of the comparers
instead, removing the base class from the equation.
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] [Created] (LUCENENET-480) Investigate what needs to happen to make both .NET 3.5 and 4.0 builds possible
Investigate what needs to happen to make both .NET 3.5 and 4.0 builds possible -- Key: LUCENENET-480 URL: https://issues.apache.org/jira/browse/LUCENENET-480 Project: Lucene.Net Issue Type: Task Components: Lucene.Net Contrib, Lucene.Net Core, Lucene.Net Demo, Lucene.Net Test Affects Versions: Lucene.Net 2.9.4g, Lucene.Net 2.9.4, Lucene.Net 3.0.3 Reporter: Christopher Currens We need to investigate what needs to be done with the source to be able to support both a .NET 3.5 and 4.0 build. There was some concern from at least one member of the community ([see here|http://mail-archives.apache.org/mod_mbox/lucene-lucene-net-dev/201202.mbox/%3C004b01cce111$871f4990$955ddcb0$@fr%3E]) that we've alienated some of our user base by making such a heavy jump from 2.0 to 4.0. There are major benefits to using 4.0 over the 2.0-based runtimes, specifically FAR superior memory management, particularly with the LOH, where Lucene.NET has had major trouble with in the past. Based on what has been done with Lucene.NET 3.0.3, we can't (easily) drop .NET 3.5/3.0 libraries and go back to 2.0. HashSetT and ISetT is used extensively in the code, that would be a major blocker to get done. I suppose it could be possible, but there hasn't been a whole lot of talk about what runtimes we intend to support. The big change between lucene 2.x and 3.x for java was also a change in runtimes, that allowed generics and enums to be used in the base code. We have a similar situation with the API (it's substantially different, with the addition of properties alone) for this next version of Lucene.NET, so I think it's reasonable to at least make a permanent move from 2.0 to 3.5, though that's only my opinion, hasn't been discussed with the committers. It seems that supporting 3.5 and 4.0 should be fairly easy, and is a decent compromise in supporting both a 2.0 and 4.0 runtime. At the very least, we should try our best to support 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] [Closed] (LUCENENET-472) Operator == on Parameter does not check for null arguments
[ https://issues.apache.org/jira/browse/LUCENENET-472?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Christopher Currens closed LUCENENET-472. - Resolution: Fixed Fix Version/s: Lucene.Net 3.0.3 Equals wasn't checking for null either. I've added the equality operators to Parameter and fixed equals. However, this class is barely used anymore, since Lucene moved to enum. The only class that uses it BooleanClause, because of the overridden ToString(), which can't be emulated with enums in .NET. Operator == on Parameter does not check for null arguments -- Key: LUCENENET-472 URL: https://issues.apache.org/jira/browse/LUCENENET-472 Project: Lucene.Net Issue Type: Bug Components: Lucene.Net Core Affects Versions: Lucene.Net 2.9.4g Reporter: Pieter van Ginkel Fix For: Lucene.Net 3.0.3 The operator == and operator != of Parameter does not check for null arguments. This means that the following construct throws an NullReferenceException: if (store == null) throw new ArgumentNullException(store); Work around is to write the above as: if ((object)store == null) throw new ArgumentNullException(store); -- 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-463) Would like to be able to use a SimpleSpanFragmenter for extrcting whole sentances
[
https://issues.apache.org/jira/browse/LUCENENET-463?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13237204#comment-13237204
]
Christopher Currens commented on LUCENENET-463:
---
I pushed some changes already, namely porting these files:
{noformat}
/incubator/lucene.net/trunk/src/contrib/Highlighter/Contrib.Highlighter.csproj
/incubator/lucene.net/trunk/src/contrib/Highlighter/DefaultEncoder.cs
/incubator/lucene.net/trunk/src/contrib/Highlighter/Encoder.cs
/incubator/lucene.net/trunk/src/contrib/Highlighter/Formatter.cs
/incubator/lucene.net/trunk/src/contrib/Highlighter/Fragmenter.cs
/incubator/lucene.net/trunk/src/contrib/Highlighter/GradientFormatter.cs
/incubator/lucene.net/trunk/src/contrib/Highlighter/Highlighter.cs
/incubator/lucene.net/trunk/src/contrib/Highlighter/IEncoder.cs
/incubator/lucene.net/trunk/src/contrib/Highlighter/InvalidTokenOffsetsException.cs
/incubator/lucene.net/trunk/src/contrib/Highlighter/NullFragmenter.cs
/incubator/lucene.net/trunk/src/contrib/Highlighter/Package.html
/incubator/lucene.net/trunk/src/contrib/Highlighter/QueryScorer.cs
/incubator/lucene.net/trunk/src/contrib/Highlighter/QueryTermExtractor.cs
/incubator/lucene.net/trunk/src/contrib/Highlighter/QueryTermScorer.cs
/incubator/lucene.net/trunk/src/contrib/Highlighter/Scorer.cs
/incubator/lucene.net/trunk/src/contrib/Highlighter/SimpleFragmenter.cs
/incubator/lucene.net/trunk/src/contrib/Highlighter/SimpleHTMLEncoder.cs
/incubator/lucene.net/trunk/src/contrib/Highlighter/SimpleHTMLFormatter.cs
/incubator/lucene.net/trunk/src/contrib/Highlighter/WeightedSpanTerm.cs
/incubator/lucene.net/trunk/src/contrib/Highlighter/WeightedSpanTermExtractor.cs
/incubator/lucene.net/trunk/src/contrib/Highlighter/WeightedTerm.cs
{noformat}
It's all a moot point though, because the real problem is that Highlighter
relies on another contrib project we've never ported: MemoryIndex. In theory
it shouldn't be too bad, it's only one file (46KB, though...yikes!). I've
actually had to comment out parts of the ported Highlighter because it relies
on this and we don't have it. So until we port that, Highlighter can't really
be done.
Would like to be able to use a SimpleSpanFragmenter for extrcting whole
sentances
--
Key: LUCENENET-463
URL: https://issues.apache.org/jira/browse/LUCENENET-463
Project: Lucene.Net
Issue Type: New Feature
Components: Lucene.Net Contrib
Reporter: Steven
Priority: Minor
Fix For: Lucene.Net 3.0.3
This is described in the Java version, but it does not seem to be in the
dot.net port, is there a reason for this as I would have imagined lots of
people doing document work would want it.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Closed] (LUCENENET-479) QueryParser.SetEnablePositionIncrements(false) doesn't work
[ https://issues.apache.org/jira/browse/LUCENENET-479?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Christopher Currens closed LUCENENET-479. - Resolution: Fixed This was fixed along with re-porting the parser in LUCENENET-478. Additionally, SetEnablePositionIncrements and GetEnablePositionIncrements now uses a bool instead of a class, and is now a public property with a getter and setter (EnablePositionIncrements) QueryParser.SetEnablePositionIncrements(false) doesn't work --- Key: LUCENENET-479 URL: https://issues.apache.org/jira/browse/LUCENENET-479 Project: Lucene.Net Issue Type: Bug Components: Lucene.Net Core Affects Versions: Lucene.Net 2.9.2, Lucene.Net 2.9.4, Lucene.Net 2.9.4g Reporter: Christopher Currens Fix For: Lucene.Net 3.0.3 Trying to disable position increments via SetEnablePositionIncrements(false) has no effect, at least on phrase queries. The parsed query returned from the QueryParser with this input, should by default return a phrase query whose terms look like: Query with Stopwords should look silmilar to this if converted to a string: query ? stopwords, where ? is a null term query in the phrase query. With EnablePositionIncrements set to false, the resulting query should be similary to query stopwords. However, calling SetEnablePositionIncrements(false) has no effect on the resulting query. -- 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
[
https://issues.apache.org/jira/browse/LUCENENET-466?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Christopher Currens closed LUCENENET-466.
-
Resolution: Fixed
I've added a new stemmer in trunk called GermanDIN2Stemmer. You can specify
GermanAnalyzer use it via some new constructors that take a bool indicating if
you want to use the DIN-5007-2 stemmer instead of the default DIN-5007-1
stemmer.
This won't break compatibility with users who want to use the old default DIN1
stemmer, but enables anyone who wants to use the other.
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, ö ino 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-476) ScoreDocs in TopDocs is ambiguos when using Visual Basic .Net
[
https://issues.apache.org/jira/browse/LUCENENET-476?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Christopher Currens updated LUCENENET-476:
--
Issue Type: Bug (was: Sub-task)
Parent: (was: LUCENENET-446)
ScoreDocs in TopDocs is ambiguos when using Visual Basic .Net
-
Key: LUCENENET-476
URL: https://issues.apache.org/jira/browse/LUCENENET-476
Project: Lucene.Net
Issue Type: Bug
Components: Lucene.Net Core
Affects Versions: Lucene.Net 2.9.4
Environment: Visual Basic .Net
Reporter: Jon
Fix For: Lucene.Net 3.0.3
The field TopDocs.scoreDocs has been made obsolete and a new property
TopDocs.ScoreDocs has been added. VB.Net is case insensitive, so both resolve
to the same name, resulting in the following error message:
{quote}
'ScoreDocs' is ambiguous because multiple kinds of members with this name
exist in class 'Lucene.Net.Search.TopDocs'
{quote}
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
Re: Lucene 3.0.3 Similiarity
Similarity is in a weird spot in the java repo: http://svn.apache.org/viewvc/lucene/java/tags/lucene_3_0_3/contrib/queries/src/java/org/apache/lucene/search/ On Sat, Mar 3, 2012 at 1:00 PM, Prescott Nasser geobmx...@hotmail.comwrote: Should we remove this? It looks like it's not part of the contrib for Java 3.0.3 http://svn.apache.org/viewvc/lucene/java/tags/lucene_3_0_3/contrib/and we have no tests for it.
[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, so some customers *may* have to make changes anyway. However, that's not a good rule, since most, if not all, of the breaking changes made to Lucene.NET were first obsoleted for a period of time, and thus they were given plenty of warning to change their code. Unfortunately, with these changes, we haven't given them the same notice. So far, I've been trying my best to make sure that all changes that have been made, have been done in a way that won't break any compatibility. All of the classes that now implement Dispose() still have a Close() method that's now obsoleted (see the PS). For properties, I've been keeping the Get/Set methods, moving the code to the property, and marking them obsoleted. I figure that this is the workflow we want, but I'm finding it's not always possible, so I'd like to see what the group has to say about it. How strict will we be? Thanks, Christopher P.S. So in regards to classes implementing Dispose() and backwards compatibility. Yes, they still have a Close() method that is obsoleted. However, with some classes, for me to make the change, I had to add IDisposable to an abstract class or interface. In some cases, it was breaking. If Close() before was abstract, I made the new protected void Dispose(bool) method abstract, removed virtual from Close() and had it call Dispose(). This is a breaking change since and class that inherited from that class will now have multiple build errors, one for trying to override a non-virtual member (Close()) and another for not implementing the protected dispose method. So, perhaps that needs
[Lucene.Net] [jira] [Commented] (LUCENENET-468) Implement the Dispose pattern properly in classes with Close
[
https://issues.apache.org/jira/browse/LUCENENET-468?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13211301#comment-13211301
]
Christopher Currens commented on LUCENENET-468:
---
Pretty much all classes with Close now have a public Dispose(); non-sealed have
a protected Dispose(bool) as well. The code compiles and tests pass, but code
analysis still needs to be run to make sure Dispose is being called everywhere
internally in the code.
Implement the Dispose pattern properly in classes with Close
Key: LUCENENET-468
URL: https://issues.apache.org/jira/browse/LUCENENET-468
Project: Lucene.Net
Issue Type: Sub-task
Components: Lucene.Net Contrib, Lucene.Net Core, Lucene.Net Demo,
Lucene.Net Test
Affects Versions: Lucene.Net 2.9.2, Lucene.Net 2.9.4, Lucene.Net 3.0.3,
Lucene.Net 2.9.4g
Environment: all
Reporter: Christopher Currens
Fix For: Lucene.Net 3.0.3
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
Re: [Lucene.Net] Blog Setup
That's similar to a suggestion Stefan made in another email:
The only alternative would be [...] running a
dynamic server on a dedicated VM. The later would
be easier to negotiate for a top level project.
Though, his response seems to imply that it would need to stay hosted on
Apache servers? I'm really only saying that because it was suggested to
negotiate it for a top level project, and the use of an outside server
wasn't actually suggested by him. If we can host outside of Apache
servers, that does seems like the most straightforward answer to our
problem, that would require the least amount of changes to our build
process (probably).
In regards to readthedocs.org, I think it only supports restructured text?
You have to use Sphinx (python) to output your documentation which uses
restructured text. I don't know if we can output that from sandcastle.
Maybe there would be another way to export the xmldoc to that format, but
idk, probably not worth the amount of effort it would take to put that in
our build steps.
Thanks,
Christopher
On Wed, Feb 15, 2012 at 10:59 AM, Troy Howard thowar...@gmail.com wrote:
Why not move docs to http://readthedocs.org/
On Wed, Feb 15, 2012 at 10:45 AM, Christopher Currens
currens.ch...@gmail.com wrote:
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 geobmx...@hotmail.com
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-dev@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
geobmx...@hotmail.com
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-dev@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 %}
h4a href={{ e.url }}{{ e.title }}/a/h4
div class=section-content{{
e.content|safe|truncatewords_html:50
}}/div
hr
{% 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
Re: [Lucene.Net] Blog Setup
I guess it wouldn't be terribly difficult to do, we would have to convert all of the shfbproj to whatever doxygen uses. I do think it's a little weird to use the python-style of documentation in a .NET project however. I personally have never been a fan of python documentation in general simply because I'm used the the MSDN style docs, where I have a nice TOC on the left that I can directly browse to anything fairly easily (think the documentation to MongoDb http://api.mongodb.org/csharp/1.3.1/ ). While you do get a TOC on documentation for sphinx style, it limits you to the current topic (and it's all on a single page using named anchors), so I personally find it cluttered. However, that may not matter, since developers would have access to the CHM (though I'd prefer sandcastle's output over doxygen's), so they wouldn't have to use the online docs if they didn't want to. Plus, I may be in the minority here with my opinion of what the docs should look like. Idk, just makes sense to me to use .NET tools for the project. Of course, I'd take Sphinx over javadoc any day...It hurts my eyes! :P Thanks, Christopher On Wed, Feb 15, 2012 at 11:36 AM, Troy Howard thowar...@gmail.com wrote: My understanding is that ASF cares about what is hosted at ASF more than they care about what isn't hosted at ASF... So you're free to do whatever you like externally, hence the GitHub mirrors and NuGet and what not. Regarding readthedocs -- it uses Sphinx/ReStructured Text...So we'd have to convert the XML to that format. There's a project for that called breathe (http://michaeljones.github.com/breathe/index.html). So the build server could add steps that would: - build to binary - run doxygen to create xml - run breathe to convert to RST It could commit that to some other repo like say, on github.. (since pulling from a repo is how RTD ingests content).. then on the RTD servers it'll pull the repo, look for a conf.py file (very simple python file) and then run sphinx-build against that directory, creating documentation for us. Woot! At least that way it wouldn't bomb ASF's infrastructure. I agree with Prescott that long term, using SVN for this is just not gonna work out. Docs do change quickly. -T On Wed, Feb 15, 2012 at 11:18 AM, Christopher Currens currens.ch...@gmail.com wrote: That's similar to a suggestion Stefan made in another email: The only alternative would be [...] running a dynamic server on a dedicated VM. The later would be easier to negotiate for a top level project. Though, his response seems to imply that it would need to stay hosted on Apache servers? I'm really only saying that because it was suggested to negotiate it for a top level project, and the use of an outside server wasn't actually suggested by him. If we can host outside of Apache servers, that does seems like the most straightforward answer to our problem, that would require the least amount of changes to our build process (probably). In regards to readthedocs.org, I think it only supports restructured text? You have to use Sphinx (python) to output your documentation which uses restructured text. I don't know if we can output that from sandcastle. Maybe there would be another way to export the xmldoc to that format, but idk, probably not worth the amount of effort it would take to put that in our build steps. Thanks, Christopher On Wed, Feb 15, 2012 at 10:59 AM, Troy Howard thowar...@gmail.com wrote: Why not move docs to http://readthedocs.org/ On Wed, Feb 15, 2012 at 10:45 AM, Christopher Currens currens.ch...@gmail.com wrote: 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 geobmx...@hotmail.com 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-dev@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 geobmx...@hotmail.com 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
Re: [Lucene.Net] 3.0.3
I was sick for a while, but I finally had time to check and see if the java issues below were already ported or not. I can confirm that all of those changes, if applicable, were already included in the 3.0.3 branch. When I say if application, I mean issues like this one: https://issues.apache.org/jira/browse/LUCENE-2653, haven't been ported because there's no real equivalent in .NET. This one in particular deals with a BreakIterator, which I deals with culture sensitive text boundaries. There is not a .NET equivalent for that, as far as I know. So, from what I can tell, it looks like the core assembly for 3.0.3 should include all bug fixes and such from java. Contrib is largely there, as well, but there are still a few libraries that haven't/can't easily be ported. On this subject, it looks like 2.9.4 was successfully voted for release. Does this mean we are soon merging 3.0.3 into trunk? There are only a few issues regarding .NET-ification that I think are blocking a 3.0.3 release. Thanks, Christopher On Sun, Feb 5, 2012 at 11:46 AM, Christopher Currens currens.ch...@gmail.com wrote: 2653, 2055, 2776, 2732, 2688, 2616, 2524, 2398, 2284, 2278, 2277, and 2249 are all on JIRA that aren't on that list in the CHANGES.txt file. It looks like that file in SVN has some issues that aren't listen in JIRA. Anyway, it's possible that those issues listed here have already been ported as part of that changeset. I'm basing that on the fact that the last time these bugs were updated was Dec 1st 2010, which was before the code was released. However, we should still check to make sure. Thanks, Christopher On Sun, Feb 5, 2012 at 11:37 AM, Christopher Currens currens.ch...@gmail.com wrote: I can only guarantee that these 31 bugs here (in the 3.0.3 version): https://svn.apache.org/repos/asf/lucene/java/tags/lucene_3_0_3/CHANGES.txt are part of the code. I mean, it's possible that other's are, but we'd really need to check the others listed there to be sure that they are also included. However, that's only a difference of 9 bugs, so I think we're very close to a 3.0.3 release, depending on how many issues we want to get done that related to changing the API. Thanks, Christopher On Sat, Feb 4, 2012 at 10:03 AM, Prescott Nasser geobmx...@hotmail.comwrote: So, Chris if you did this as a direct port of the java version ( https://svn.apache.org/repos/asf/lucene/java/tags/lucene_3_0_3/), Does that mean that all of the LUCENE JIRA issues ( https://issues.apache.org/jira/secure/IssueNavigator.jspa?reset=truejqlQuery=project+%3D+LUCENE+AND+fixVersion+%3D+%223.0.3%22+AND+status+%3D+Closed+ORDER+BY+priority+DESCmode=hide) are part of this code already? That would make 3.0.3 well on it's way to release... ~P From: bode...@apache.org To: lucene-net-...@incubator.apache.org Date: Wed, 25 Jan 2012 12:35:25 +0100 Subject: Re: [Lucene.Net] 3.0.3 On 2012-01-25, Michael Herndon wrote: Do we have a standard of copy or tag of Java's version source that we're doing a compare against? I only see the 3_1 and above in the tags. Likely because the svn location has changed in between. I think it must be https://svn.apache.org/repos/asf/lucene/java/tags/lucene_3_0_3/ Stefan
Re: [Lucene.Net] 3.0.3
I can only guarantee that these 31 bugs here (in the 3.0.3 version): https://svn.apache.org/repos/asf/lucene/java/tags/lucene_3_0_3/CHANGES.txt are part of the code. I mean, it's possible that other's are, but we'd really need to check the others listed there to be sure that they are also included. However, that's only a difference of 9 bugs, so I think we're very close to a 3.0.3 release, depending on how many issues we want to get done that related to changing the API. Thanks, Christopher On Sat, Feb 4, 2012 at 10:03 AM, Prescott Nasser geobmx...@hotmail.comwrote: So, Chris if you did this as a direct port of the java version ( https://svn.apache.org/repos/asf/lucene/java/tags/lucene_3_0_3/), Does that mean that all of the LUCENE JIRA issues ( https://issues.apache.org/jira/secure/IssueNavigator.jspa?reset=truejqlQuery=project+%3D+LUCENE+AND+fixVersion+%3D+%223.0.3%22+AND+status+%3D+Closed+ORDER+BY+priority+DESCmode=hide) are part of this code already? That would make 3.0.3 well on it's way to release... ~P From: bode...@apache.org To: lucene-net-...@incubator.apache.org Date: Wed, 25 Jan 2012 12:35:25 +0100 Subject: Re: [Lucene.Net] 3.0.3 On 2012-01-25, Michael Herndon wrote: Do we have a standard of copy or tag of Java's version source that we're doing a compare against? I only see the 3_1 and above in the tags. Likely because the svn location has changed in between. I think it must be https://svn.apache.org/repos/asf/lucene/java/tags/lucene_3_0_3/ Stefan
Re: [Lucene.Net] 3.0.3
2653, 2055, 2776, 2732, 2688, 2616, 2524, 2398, 2284, 2278, 2277, and 2249 are all on JIRA that aren't on that list in the CHANGES.txt file. It looks like that file in SVN has some issues that aren't listen in JIRA. Anyway, it's possible that those issues listed here have already been ported as part of that changeset. I'm basing that on the fact that the last time these bugs were updated was Dec 1st 2010, which was before the code was released. However, we should still check to make sure. Thanks, Christopher On Sun, Feb 5, 2012 at 11:37 AM, Christopher Currens currens.ch...@gmail.com wrote: I can only guarantee that these 31 bugs here (in the 3.0.3 version): https://svn.apache.org/repos/asf/lucene/java/tags/lucene_3_0_3/CHANGES.txt are part of the code. I mean, it's possible that other's are, but we'd really need to check the others listed there to be sure that they are also included. However, that's only a difference of 9 bugs, so I think we're very close to a 3.0.3 release, depending on how many issues we want to get done that related to changing the API. Thanks, Christopher On Sat, Feb 4, 2012 at 10:03 AM, Prescott Nasser geobmx...@hotmail.comwrote: So, Chris if you did this as a direct port of the java version ( https://svn.apache.org/repos/asf/lucene/java/tags/lucene_3_0_3/), Does that mean that all of the LUCENE JIRA issues ( https://issues.apache.org/jira/secure/IssueNavigator.jspa?reset=truejqlQuery=project+%3D+LUCENE+AND+fixVersion+%3D+%223.0.3%22+AND+status+%3D+Closed+ORDER+BY+priority+DESCmode=hide) are part of this code already? That would make 3.0.3 well on it's way to release... ~P From: bode...@apache.org To: lucene-net-...@incubator.apache.org Date: Wed, 25 Jan 2012 12:35:25 +0100 Subject: Re: [Lucene.Net] 3.0.3 On 2012-01-25, Michael Herndon wrote: Do we have a standard of copy or tag of Java's version source that we're doing a compare against? I only see the 3_1 and above in the tags. Likely because the svn location has changed in between. I think it must be https://svn.apache.org/repos/asf/lucene/java/tags/lucene_3_0_3/ Stefan
Re: [Lucene.Net] 3.0.3
The source that this port was done from was the java release package. If you go to the mirrors: http://www.apache.org/dyn/closer.cgi/lucene/java/ you'll see that they have a 3.0.3 folder with a downloadable source zip. There are additional thoughts I wrote down while working on it here: https://svn.apache.org/repos/asf/incubator/lucene.net/branches/Lucene.Net.3.0.3/trunk/src/core/ChangeNotes.txt, but I really need to go through it again and even see if its up to date. 3.0.3's entirety has already been ported to the trunk, except for maybe the 7 files listed here: https://svn.apache.org/repos/asf/incubator/lucene.net/branches/Lucene.Net.3.0.3/trunk/src/core/FileDiffs.txt. Contrib has *largely* been ported but is also missing a few libraries. There are few unit tests that need to be written for new support classes, I think. A lot of code cleanup can be done as well. Sorry about the format of this email, kinda just going off the top of my head. Thanks, Christopher On Tue, Jan 24, 2012 at 4:23 PM, Michael Herndon mhern...@wickedsoftware.net wrote: Do we have a standard of copy or tag of Java's version source that we're doing a compare against? I only see the 3_1 and above in the tags. I could attempt to do something similar I did with core and version 4 and use beyond compare between 2.9.4 and 3.0.3 and make a list of files that were touched and script out wiki links. Or I could try to generate of beyond compare's diff reports and see how that stacks up and post to the above link. On Sat, Jan 14, 2012 at 5:15 AM, Prescott Nasser geobmx...@hotmail.comwrote: I've updated the confluence page to hopefully give us some direction: https://cwiki.apache.org/confluence/display/LUCENENET/Lucene.Net+3.0.3I'd think it's just easier if as you take down a Java Lucene Issue, you create a JIRA issue for Lucene.Net and associate it with 3.0.3, rather than me making a ton of issues. ~P
Re: [Lucene.Net] 3.0.3
I think CLS compatibility, in terms of types, is less important than naming. CLS compliance all while keeping the index format seems like a pretty big challenge for us to do at this point. I had worked *very little* on CLS compliance, it was mostly fixing TopDocs and some other small name changes. I had also started working on implementing IDisposable properly, and got a good start on that. I've committed the work I have done on those issues, so if you do want to do one of them feel free to assign it to yourself, if you'd like. There's a lot of issues, though for 3.0.3 now, that would be nice to have worked on, as well. Thanks, Christopher On Tue, Jan 24, 2012 at 8:04 PM, Prescott Nasser geobmx...@hotmail.com wrote: We should definitely take some time and clean the code up. With the way the voting is going in general, it'll be a week for me to beg and plead for the 3 IPMC votes we need to release 2.9.4g - so no rush.. Someone is working on the CLS issue correct? I want to take another stab at that, but I don't want to overlap too much. I was thinking of fixing the bit shifting crap I ran into last time.. ~P Date: Tue, 24 Jan 2012 18:30:34 -0800 From: currens.ch...@gmail.com To: lucene-net-dev@lucene.apache.org Subject: Re: [Lucene.Net] 3.0.3 The source that this port was done from was the java release package. If you go to the mirrors: http://www.apache.org/dyn/closer.cgi/lucene/java/ you'll see that they have a 3.0.3 folder with a downloadable source zip. There are additional thoughts I wrote down while working on it here: https://svn.apache.org/repos/asf/incubator/lucene.net/branches/Lucene.Net.3.0.3/trunk/src/core/ChangeNotes.txt, but I really need to go through it again and even see if its up to date. 3.0.3's entirety has already been ported to the trunk, except for maybe the 7 files listed here: https://svn.apache.org/repos/asf/incubator/lucene.net/branches/Lucene.Net.3.0.3/trunk/src/core/FileDiffs.txt. Contrib has *largely* been ported but is also missing a few libraries. There are few unit tests that need to be written for new support classes, I think. A lot of code cleanup can be done as well. Sorry about the format of this email, kinda just going off the top of my head. Thanks, Christopher On Tue, Jan 24, 2012 at 4:23 PM, Michael Herndon mhern...@wickedsoftware.net wrote: Do we have a standard of copy or tag of Java's version source that we're doing a compare against? I only see the 3_1 and above in the tags. I could attempt to do something similar I did with core and version 4 and use beyond compare between 2.9.4 and 3.0.3 and make a list of files that were touched and script out wiki links. Or I could try to generate of beyond compare's diff reports and see how that stacks up and post to the above link. On Sat, Jan 14, 2012 at 5:15 AM, Prescott Nasser geobmx...@hotmail.comwrote: I've updated the confluence page to hopefully give us some direction: https://cwiki.apache.org/confluence/display/LUCENENET/Lucene.Net+3.0.3I'd think it's just easier if as you take down a Java Lucene Issue, you create a JIRA issue for Lucene.Net and associate it with 3.0.3, rather than me making a ton of issues. ~P
[Lucene.Net] [jira] [Updated] (LUCENENET-446) Make Lucene.Net CLS Compliant
[ https://issues.apache.org/jira/browse/LUCENENET-446?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Christopher Currens updated LUCENENET-446: -- Fix Version/s: Lucene.Net 3.0.3 Make Lucene.Net CLS Compliant - Key: LUCENENET-446 URL: https://issues.apache.org/jira/browse/LUCENENET-446 Project: Lucene.Net Issue Type: Task Components: Lucene.Net Core Affects Versions: Lucene.Net 2.9.4 Reporter: Prescott Nasser Fix For: Lucene.Net 3.0.3 Attachments: Lucene2.9.4-CLS-partial-fix Make Lucene.Net CLS Compliant -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[Lucene.Net] [jira] [Updated] (LUCENENET-439) Correctly Rethrow exceptions in C#
[
https://issues.apache.org/jira/browse/LUCENENET-439?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Christopher Currens updated LUCENENET-439:
--
Fix Version/s: Lucene.Net 3.0.3
Correctly Rethrow exceptions in C#
--
Key: LUCENENET-439
URL: https://issues.apache.org/jira/browse/LUCENENET-439
Project: Lucene.Net
Issue Type: Sub-task
Components: Lucene.Net Core, Lucene.Net Test
Affects Versions: Lucene.Net 2.9.2, Lucene.Net 2.9.4, Lucene.Net 2.9.4g
Environment: all
Reporter: michael herndon
Labels: refactoring, testing,
Fix For: Lucene.Net 3.0.3
There are a few places in the tests and possibly in the code where exceptions
are being rethrown incorrectly and erasing stacktrace.
Please fix these as you come across them and add the ticket number in the
commit message.
BaseTokenStreamTestCase.cs has a good example of this. Inside the RunBare
method:
// Do the test again with onlyUseNewAPI=true
try
{
onlyUseNewAPI = true;
base.RunBare();
}
catch(Exception ex)
{
System.Console.Out.WriteLine(Test failure of ' + GetType() + '
occurred with onlyUseNewAPI=true);
throw ex;
}
in this case you don't need to specify the exception, and we're trapping to
write out the context of the exception problem.
try
{
onlyUseNewAPI = true;
base.RunBare();
}
catch
{
Type type = this.GetType();
Console.WriteLine(Test failure of ' + type.Name + ' occurred with
onlyUseNewAPI=true);
throw;
}
http://msdn.microsoft.com/en-us/library/ms182363(v=vs.80).aspx
http://winterdom.com/2002/09/rethrowingexceptionsinc
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[Lucene.Net] [jira] [Commented] (LUCENENET-372) NLS pack for Lucene.NET: BR, CJK, CN, CZ, DE, FR, NL, RU analyzers
[ https://issues.apache.org/jira/browse/LUCENENET-372?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13191896#comment-13191896 ] Christopher Currens commented on LUCENENET-372: --- All of this code has been ported from the 3.x Java into the 3.0.3 branch. The code above is outdated, in that is uses constructs from 2.9.4 that are no longer used/are deprecated. Are we planning on doing a separate contrib release for 2.9.4, or should this be closed? 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 Assignee: Prescott Nasser 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
[Lucene.Net] [jira] [Commented] (LUCENENET-463) Would like to be able to use a SimpleSpanFragmenter for extrcting whole sentances
[ https://issues.apache.org/jira/browse/LUCENENET-463?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13191897#comment-13191897 ] Christopher Currens commented on LUCENENET-463: --- This is, at least, on my list of things to include in 3.0.3, but only if I can find the time to do it. The entire Highlighter project has a lot of changes between what is in it now and what needs to be for it to be the same as Java's highlighter in 3.0.3. This isn't a *top* priority for 3.0.3. If you'd like to port it yourself or parts of it to help make sure it's in the next release, we'd welcome it and include it, otherwise, we'll try and get it in ourselves, time permitting. Would like to be able to use a SimpleSpanFragmenter for extrcting whole sentances -- Key: LUCENENET-463 URL: https://issues.apache.org/jira/browse/LUCENENET-463 Project: Lucene.Net Issue Type: New Feature Components: Lucene.Net Contrib Reporter: Steven Priority: Minor Fix For: Lucene.Net 3.0.3 This is described in the Java version, but it does not seem to be in the dot.net port, is there a reason for this as I would have imagined lots of people doing document work would want it. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[Lucene.Net] [jira] [Updated] (LUCENENET-463) Would like to be able to use a SimpleSpanFragmenter for extrcting whole sentances
[ https://issues.apache.org/jira/browse/LUCENENET-463?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Christopher Currens updated LUCENENET-463: -- Fix Version/s: Lucene.Net 3.0.3 Would like to be able to use a SimpleSpanFragmenter for extrcting whole sentances -- Key: LUCENENET-463 URL: https://issues.apache.org/jira/browse/LUCENENET-463 Project: Lucene.Net Issue Type: New Feature Components: Lucene.Net Contrib Reporter: Steven Priority: Minor Fix For: Lucene.Net 3.0.3 This is described in the Java version, but it does not seem to be in the dot.net port, is there a reason for this as I would have imagined lots of people doing document work would want it. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[Lucene.Net] [jira] [Updated] (LUCENENET-436) Refactor Deprecated Code inside of tests
[ https://issues.apache.org/jira/browse/LUCENENET-436?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Christopher Currens updated LUCENENET-436: -- Fix Version/s: Lucene.Net 3.0.3 This is a nice to have for the 3.x release. A lot of the tests are written with deprecated code simply, because they are that way in Java Lucene, and thus haven't been updated. Unless the majority objects, I agree that we should take this approach of removing the deprecated code ourselves, when the test isn't testing the behavior of the deprecated method itself, instead of sticking to exact Java tests. I say we try and get as much of it as we can updated, but not have this issue block a 3.x release if we run out of time. Refactor Deprecated Code inside of tests - Key: LUCENENET-436 URL: https://issues.apache.org/jira/browse/LUCENENET-436 Project: Lucene.Net Issue Type: Sub-task Components: Lucene.Net Test Affects Versions: Lucene.Net 2.9.4g Reporter: michael herndon Labels: refactoring, testing, Fix For: Lucene.Net 3.0.3 * We should still be testing deprecated methods, but we need to use #pragma warning disable/enable 0618 for testing those. otherwise compiler warnings are too numerous to be anywhere near helpful. * We should only be using deprecated methods in places where they are being explicitly tested, other tests that need that functionality in order to validate those tests should be re factored to use methods that are not deprecated. This is one place we should probably deviate from the parent project and make sure that any deprecated code gets isolated to the tests designed only for the deprecated methods and then use the newer API through out the testsuite. This should help move the project forward and remove deprecated API's when the time comes. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[Lucene.Net] [jira] [Updated] (LUCENENET-423) QueryParser differences between Java and .NET when parsing range queries involving dates
[
https://issues.apache.org/jira/browse/LUCENENET-423?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Christopher Currens updated LUCENENET-423:
--
Fix Version/s: Lucene.Net 3.0.3
Summary: QueryParser differences between Java and .NET when parsing
range queries involving dates (was: QueryParser differences between Java and
.NET)
This is a difference of behavior between searching in Java and .NET. While
.NET is more accurate about DateTime parsing, that difference in behavior seems
to be against what was discussed [in this email
thread|http://mail-archives.apache.org/mod_mbox/lucene-lucene-net-dev/201112.mbox/%3CCAFZAm_VxWaNZmCAUZPFt2%2B9HJBXJjSTmJ-uLj%3DQh-naGja9MKA%40mail.gmail.com%3E],
regarding people's wishes for the future of the project. Much of what was
agreed upon was the project having much of the same behavior of Java, in that
indexes are compatible and searches in each returning the same results for the
same search on the same index.
QueryParser differences between Java and .NET when parsing range queries
involving dates
Key: LUCENENET-423
URL: https://issues.apache.org/jira/browse/LUCENENET-423
Project: Lucene.Net
Issue Type: Bug
Affects Versions: Lucene.Net 2.9.2, Lucene.Net 2.9.4, Lucene.Net 2.9.4g
Reporter: Christopher Currens
Fix For: Lucene.Net 3.0.3
When trying to do a RangeQuery that uses dates in a certain format, .NET
behaves differently from its Java counterpart. The code is the same between
them, but as far as I can tell, it appears that it is a difference in the way
Java parses dates vs how .NET parses dates. To reproduce:
{code:java}
var queryParser = new QueryParser(Lucene.Net.Util.Version.LUCENE_29,
FullText, new StandardAnalyzer(Lucene.Net.Util.Version.LUCENE_29));
var query = queryParser.Parse(Field:[2001-01-17 TO 2001-01-20]);
{code}
You'll notice that query looks like the old DateField format (eg
0g1d64542). If you do the same query in Java (or Luke), you'll notice the
query gets parsed as if it were a RangeQuery of string. AFAIK, Java cannot
parse a string formatted in that way. If you change the string to use /
instead of - in the java, you'll get one that uses DateResolutions and
DateTools.DateToString().
It seems an appropriate fix for this, if we wanted to keep this behavior
similar to Java, would be to write our own DateTime parser that behaved the
same way to Java's parser.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[Lucene.Net] [jira] [Updated] (LUCENENET-179) SnowballFilter speed improvment
[ https://issues.apache.org/jira/browse/LUCENENET-179?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Christopher Currens updated LUCENENET-179: -- Fix Version/s: Lucene.Net 3.0.3 I haven't looked at the code, but I'm adding it into 3.0.3 anyway. When someone has the time to look over it and test it, we can decide if we plan on including it or not. At first glance, it looks good, but I wouldn't want to sign off on it until we're sure it fits in with the changes of 3.0.3 and passes all tests. SnowballFilter speed improvment --- Key: LUCENENET-179 URL: https://issues.apache.org/jira/browse/LUCENENET-179 Project: Lucene.Net Issue Type: Improvement Components: Lucene.Net Contrib Affects Versions: Lucene.Net 2.9.2 Reporter: Arian Bär Fix For: Lucene.Net 3.0.3 Attachments: FailOverSnowballFilter.cs I'm using Lucene.Net along with snowball stemming to index text from a database. The class Lucene.Net.Analysis.Snowball.SnowballFilter uses the reflection API and the invoke method to call the stem methods of snowball. I have written a Snowball filter which creates a delegate and uses this delegate to stem the words afterwards. This approach improves the indexing speed of my indexing program by about 10%. I would be happy if you include this code into lucene.net. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[Lucene.Net] [jira] [Created] (LUCENENET-467) .NETify the public API where appropriate
.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.4, Lucene.Net 2.9.2, Lucene.Net 3.0.3, Lucene.Net 2.9.4g Environment: all Reporter: Christopher Currens Fix For: Lucene.Net 3.0.3 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 IEnumerableT * 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
[Lucene.Net] [jira] [Created] (LUCENENET-468) Implement the Dispose pattern properly in classes with Close
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.4, Lucene.Net 2.9.2, Lucene.Net 3.0.3, Lucene.Net 2.9.4g Environment: all Reporter: Christopher Currens Fix For: Lucene.Net 3.0.3 Implement the dispose pattern as [suggested here|http://msdn.microsoft.com/en-us/library/fs2xkftw.aspx] on any class that implements Close(). Be sure to implement the IDisposable.Dispose() only in the base class, and have all sub-class behavior overridden in a protected method. This change will involve making sure that everywhere the classes are used in contrib, core, demo and test, that dispose is called on them. We don't want to neglect calling dispose in our own code. For those with Visual Studio 2010 Premium or higher, turning on Code Analysis in the project settings will flag a warning that Dispose needs to be called on a class, so you don't have to manually go searching for it. -- 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] [Created] (LUCENENET-469) Convert Java Iterator classes to implement IEnumerableT
Convert Java Iterator classes to implement IEnumerableT
-
Key: LUCENENET-469
URL: https://issues.apache.org/jira/browse/LUCENENET-469
Project: Lucene.Net
Issue Type: Sub-task
Components: Lucene.Net Contrib, Lucene.Net Core
Affects Versions: Lucene.Net 2.9.4, Lucene.Net 3.0.3, Lucene.Net 2.9.4g
Environment: all
Reporter: Christopher Currens
Fix For: Lucene.Net 3.0.3
The Iterator pattern in Java is equivalent to IEnumerable in .NET. Classes
that were directly ported in Java using the Iterator pattern, cannot be used
with Linq or foreach blocks in .NET.
{{Next()}} would be equivalent to .NET's {{MoveNext()}}, and in the below case,
{{Term()}} would be as .NET's {{Current}} property. In cases as below, it will
require {{TermEnum}} to become an abstract class with {{Term}} and {{DocFreq}}
properties, which would be returned from another class or method that
implemented {{IEnumerableTermEnum}}.
{noformat}
public abstract class TermEnum : IDisposable
{
public abstract bool Next();
public abstract Term Term();
public abstract int DocFreq();
public abstract void Close();
public abstract void Dispose();
}
{noformat}
would instead look something like:
{noformat}
public class TermFreq
{
public abstract Term { get; }
public abstract int { get; }
}
public abstract class TermEnum : IEnumerableTermFreq, IDisposable
{
// ...
}
{noformat}
Keep in mind that it is important that if the class being converted implements
{{IDisposable}}, the class that is enumerating the terms (in this case
{{TermEnum}}) should inherit from both {{IEnumerableT}} *and*
{{IDisposable}}. This won't be any change to the user, as the compiler
automatically calls {{IDisposable}} when used in a {{foreach}} loop.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[Lucene.Net] [jira] [Updated] (LUCENENET-468) Implement the Dispose pattern properly in classes with Close
[
https://issues.apache.org/jira/browse/LUCENENET-468?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Christopher Currens updated LUCENENET-468:
--
Description:
Implement the dispose pattern as [suggested
here|http://msdn.microsoft.com/en-us/library/fs2xkftw.aspx] on any class that
implements Close(). Be sure to implement the IDisposable.Dispose() only in the
base class, and have all sub-class behavior overridden in a protected method.
This change will involve making sure that everywhere the classes are used in
contrib, core, demo and test, that dispose is called on them. We don't want to
neglect calling dispose in our own code. For those with Visual Studio 2010
Premium or higher, turning on Code Analysis in the project settings will flag a
warning that Dispose needs to be called on a class, so you don't have to
manually go searching for it.
These changes do not have to be breaking. Instead, also make {{Close}} a
public method in the base class and have it call {{Dispose}}. Mark it with the
Obsolete attribute, so we can remove it in later releases.
was:
Implement the dispose pattern as [suggested
here|http://msdn.microsoft.com/en-us/library/fs2xkftw.aspx] on any class that
implements Close(). Be sure to implement the IDisposable.Dispose() only in the
base class, and have all sub-class behavior overridden in a protected method.
This change will involve making sure that everywhere the classes are used in
contrib, core, demo and test, that dispose is called on them. We don't want to
neglect calling dispose in our own code. For those with Visual Studio 2010
Premium or higher, turning on Code Analysis in the project settings will flag a
warning that Dispose needs to be called on a class, so you don't have to
manually go searching for it.
Implement the Dispose pattern properly in classes with Close
Key: LUCENENET-468
URL: https://issues.apache.org/jira/browse/LUCENENET-468
Project: Lucene.Net
Issue Type: Sub-task
Components: Lucene.Net Contrib, Lucene.Net Core, Lucene.Net Demo,
Lucene.Net Test
Affects Versions: Lucene.Net 2.9.2, Lucene.Net 2.9.4, Lucene.Net 3.0.3,
Lucene.Net 2.9.4g
Environment: all
Reporter: Christopher Currens
Fix For: Lucene.Net 3.0.3
Implement the dispose pattern as [suggested
here|http://msdn.microsoft.com/en-us/library/fs2xkftw.aspx] on any class that
implements Close(). Be sure to implement the IDisposable.Dispose() only in
the base class, and have all sub-class behavior overridden in a protected
method.
This change will involve making sure that everywhere the classes are used in
contrib, core, demo and test, that dispose is called on them. We don't want
to neglect calling dispose in our own code. For those with Visual Studio
2010 Premium or higher, turning on Code Analysis in the project settings will
flag a warning that Dispose needs to be called on a class, so you don't have
to manually go searching for it.
These changes do not have to be breaking. Instead, also make {{Close}} a
public method in the base class and have it call {{Dispose}}. Mark it with
the Obsolete attribute, so we can remove it in later releases.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[Lucene.Net] [jira] [Created] (LUCENENET-470) Change Getxxx() and Setxxx() methods to .NET Properties
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 3.0.3, Lucene.Net 2.9.4g
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
Re: [Lucene.Net] removing .html files
They are artifacts from java-doc. Package is for package specific comments and overview is filled with comments about multiple packages. We can remove them, we don't have any need for them. Thanks, Christopher On Mon, Jan 23, 2012 at 11:07 PM, Prescott Nasser geobmx...@hotmail.comwrote: Any reason we have all the overview and package.html files? can we remove those from the source code or are they needed for something?
[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
[Lucene.Net] [jira] [Commented] (LUCENENET-465) Error indexing a document end Filed.Store.COMPRESS
[
https://issues.apache.org/jira/browse/LUCENENET-465?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13191975#comment-13191975
]
Christopher Currens commented on LUCENENET-465:
---
It looks by the issue description that you have SharpZipLib? Where is it in
relation to the Lucene.NET dll? Can you print out the stack trace, exception
type, and actual exception method?
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
[Lucene.Net] [jira] [Commented] (LUCENENET-54) ArgumentOurOfRangeException caused by SF.Snowball.Ext.DanishStemmer
[ https://issues.apache.org/jira/browse/LUCENENET-54?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13190345#comment-13190345 ] Christopher Currens commented on LUCENENET-54: -- This affected DanishStemmer, FinnishStemmer and KpStemmer. ket-bra is used almost everywhere in that code, expect that one place, causing the issue with the index vs length. I just pushed a fix for this to the 3.0.3 branch. 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 3.0.3, Lucene.Net 2.9.4g 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
