Re: Proposal Stage: Backwards Compatibility / Support
No pre/post processing involved. They are just to see how the output of these tools looks like. DIGY On Sun, Jan 2, 2011 at 11:36 PM, Prescott Nasser wrote: > > Also, was there any pre/post processing involved in these files? Was it > manual / scripts etc? Just trying to get a feel for the work involved. > > > > From: digyd...@gmail.com > > To: lucene-net-dev@lucene.apache.org > > Subject: RE: Proposal Stage: Backwards Compatibility / Support > > Date: Sun, 2 Jan 2011 19:03:25 +0200 > > > > > The 3.0.X ports should be 100% Sharpen > > Why? > > What about other alternatives? > > > > Lucene.java 3.0.3 ==> .Net Conversion Samples ( > http://people.apache.org/~digy/Lucene.Net.3.0.3.zip ) > > > > DIGY > > > > > > > > -Original Message- > > From: Troy Howard [mailto:thowar...@gmail.com] > > Sent: Saturday, January 01, 2011 1:58 AM > > To: lucene-net-dev@lucene.apache.org > > Subject: Re: Proposal Stage: Backwards Compatibility / Support > > > > We are inheriting the outstanding issues facing the Lucene.Net project. > > > > This includes remaining committed to providing a line-by-line port > > that stays in sync with the Java Lucene releases. > > > > The project is currently extremely behind schedule on this. The 2.9.2 > > code base, which is widely used and thus a fairly well received build, > > has never been formally packaged as a release (i.e. binary builds, > > etc). This is the first order of business to take care of (in terms of > > code). > > > > After that we need to evaluate weather or not to create releases to > > match all subsequent releases made by the Java Lucene project. > > > > Those releases are: > > - 3.0.0 > > - 3.0.1 > > - 2.9.3 > > - 3.0.2 > > - 2.9.4 > > - 3.0.3 > > > > In the interest of time, we could skip some of the intermediate > > releases and just get in sync at 2.9.4 and 3.0.3 releases. > > > > The 3.0.X ports should be 100% Sharpen conversions and post-processing > > scripts. Once written, anyone should be able to repeat the process of > > pulling down the appropriate Java Lucene SVN revision, executing the > > porting scripts, and building the resulting .NET code, yield a valid > > 3.0.X release with a 1:1 matching API. > > > > This is something we will need to continue being able to do for every > > subsequent Java Lucene release. > > > > This aspect of our development should be completely separate from our > > refactoring/re-imagining of a more .NET-like API. They need to be > > separate development branches, and possibly even completely different > > implementations. We will attempt to reuse as much of the automated > > port code as we can, with the understanding that the goal of the > > secondary branch is to make a high-quality .NET implementation of > > Lucene, rather than a API compatible implementation. > > > > Thanks, > > Troy > > > > > > > > On Fri, Dec 31, 2010 at 3:29 PM, Alex Thompson > wrote: > > > Maybe we could just bug-fix support the current 2.9.2 codebase unless > people > > > really need something in 2.9.x > > > > > > I think there would be a 3.0.x line-by-line port and a 3.0.x idiomatic > > > version. > > > > > > I'd like to throw another idea into the mix which is perhaps the > idiomatic > > > version could be created by an automated refactoring of the > line-by-line. It > > > might be additional upfront work but might make it easier for future > changes > > > from java lucene to be propagated down. > > > > > > Alex > > > > > > -Original Message- > > > From: mhern...@amptools.net [mailto:mhern...@amptools.net] On Behalf > Of > > > Michael Herndon > > > Sent: Friday, December 31, 2010 1:28 PM > > > To: lucene-net-dev@lucene.apache.org > > > Subject: Proposal Stage: Backwards Compatibility / Support > > > > > > *Backwards Compatibility / Support: * > > > This is definitely something we need to cover. > > > > > > I'm guessing the obvious choice would be to continue the 2.9.X versions > > > under sharpen, maintain the current api thats has java idioms so that > people > > > can continue to use it, release patches, ensure stability with the > current > > > community. This would be important for people who have built products > on top > > > of lucene.net. > > > > > > The 3.0 version should probably match java in terms of breaking the api > due > > > to the language changes or maybe even a separate project inside: > > > lucene.netredux (for lack of a better term at the moment). > > > > > > > > > * > > > * > > > -- > > > Michael Herndon > > > > > > > > > >
Re: How to submit code?
using JIRA ( https://issues.apache.org/jira/secure/Dashboard.jspa ) , you can create an issue and add your code to that. DIGY On Fri, Jan 14, 2011 at 3:07 PM, Jörg Lang wrote: > Hi > > I started looking into Lucence, as I might need it on a project. As there > was no GermanAnalyzer in the dotNet version, I ported the code that was > available in the Java version to .NET. > > As I new to the OpenSource world, I do not exactly know how I need to > proceed, that this piece of code is included? > Send it to a contributor? > > Thanks for any advice. > > Regards > Jörg Lang >
Re: IKVM (or rather OpenJDK) License Problem
Hi Stefan, * Java's bytecode doesn't contain metadata about generics and when Java is compiled, all info about generics gets lost. So, IKVMed Lucene.Net will have to live without generics. * IKVM is the java world in .NET runtime in fact. If you are , for ex, to write an analyzer, you have to override TokenStream method which accepts "java.io.Reader" instead of "System.IO.TextReader". So .NET people have to learn java namespaces/classes and develop their own java-compatible libraries * Since IKVM is a different world, remoting (for ex.) between native .NET code & IKVMed code is problematic (one uses "java.rmi.server.UnicastRemoteObject", the other one "System.MarshalByRefObject"). * It's not possible to make custom changes in IKVMed Lucene.NET unless you make your changes in java sources and compile them. I think people can find more examples. Of course, none of them is a blocking issue but too far from giving a .NET taste. DIGY On Fri, Jan 28, 2011 at 7:24 AM, Stefan Bodewig wrote: > On 2011-01-27, Granroth, Neal V. wrote: > > > Use of IKVM was discussed before. > > I'm really sorry. Normally I wouldn't have brought it up without > searching the archive - I did so in the context of "this is a question > the people we hope to attract might ask". > > Please be patient with the new people we want to attract, they will not > hunt down the mailing list archives for every idea they have. This is > why putting things on the Wiki like Scott has started is a better > approach. You can tell people "was discussed before and URL-HERE is the > outcome". > > > Adding this layer (or any other shim) on top of Lucene.NET is > > extremely unpalatable in the environment in which our products are > > deployed. > > The license rules it out anyway (unless we ikvmc'ed Harmony, yet another > can of worms) so this question is moot. But still, out of curiosity: is > there any technical reason that turned it into a bad idea? The > discussion from the other thread seemed to indicate that performance was > not an issue. > > Thanks > >Stefan >
Re: IKVM (or rather OpenJDK) License Problem
>> * It's not possible to make custom changes in IKVMed Lucene.NET unless you >> make your changes in java sources and compile them. > Wouldn't a "custom change" contradict the goal of a line-by-line > translation? What I intented to say was customizations made by Lucene.Net users, not as a Lucene.Net project. DIGY On Fri, Jan 28, 2011 at 10:44 AM, Stefan Bodewig wrote: > Hi DIGY > > On 2011-01-28, digy digy wrote: > > > * Java's bytecode doesn't contain metadata about generics and when Java > is > > compiled, all info about generics gets lost. So, IKVMed Lucene.Net will > have > > to live without generics. > > Ah, yes, the joys of type erasure. I completely missed that. > > > * IKVM is the java world in .NET runtime in fact. If you are , for ex, > to > > write an analyzer, you have to override TokenStream method which accepts > > "java.io.Reader" instead of "System.IO.TextReader". So .NET people have > to > > learn java namespaces/classes and develop their own java-compatible > > libraries > > > * Since IKVM is a different world, remoting (for ex.) between native .NET > > code & IKVMed code is problematic (one uses > > "java.rmi.server.UnicastRemoteObject", the other one > > "System.MarshalByRefObject"). > > Ugly, I agree. Although this could be meliorated by an additional .NET > centric library that took care of adapting the differences. This extra > layer would add complexity and not help with performance, of course. > > > * It's not possible to make custom changes in IKVMed Lucene.NET unless > you > > make your changes in java sources and compile them. > > Wouldn't a "custom change" contradict the goal of a line-by-line > translation? > > Many thanks, I'll add your points to the wiki > > Stefan >
Re: Icubator Infra: svn and Committers
I think I don't have write access to "../incubator/lucene.net". Since when I try to commit README.TXT as a test, I get the following error. "access to '/repos/asf/!svn/ver/897426/incubator/lucene.net/README.txt' forbidden". DIGY On Tue, Feb 1, 2011 at 11:40 AM, Stefan Bodewig wrote: > Hi all, > > since the vote is going to pass real soon now, I'll kick of a few > threads in order to streamline the infrastructure changes. > > The old <https://svn.apache.org/repos/asf/incubator/lucene.net/> still > exists so it is mainly only a matter of granting karma to the right > people. > > Right now the following ASF accounts have write access to Lucene.NET's > source tree: aroush,digy,dougsale,jrodenburg,mgarski. From the > proposal's committer list I can only identify DIGY. > > For the seven remaining people we'll have to get accounts created (I can > confirm the ICLAs are on file). Could you please send a mail to me > listing your preferred userid (with acceptable alternatives) and the > email address you want to see your @apache.org mail forwarded to (see > <http://www.apache.org/dev/pmc.html#newcommitter>) so I can initiate the > account requests? No reason to spam the list with this 8-) > > Initially I'll remove all people but DIGY from the access list and add > Benson, Gianugo and myself (so we can help with technical issues) - and > all the other committers will be added once their accounts are set up > which may take a few days. > > DIGY should be able to move the actual svn contents. Once this is done > and a site-redirect (another thread) from the old Lucene.NET page at > lucene.ao to the new incubator homepage is in place I'd remove access to > the lucene subtree so the Lucene PMC can take care of the rest. > > Commit notifications will be sent to lucene-net-commits. > > Is this correct so far? > > Stefan >
Re: Incubator Infra: mailing lists
I am the current moderator of the mailing lists. It is not much work than "reply" or "delete" but having more than one moderator would be good. DIGY On Tue, Feb 1, 2011 at 12:16 PM, Stefan Bodewig wrote: > Hi all, > > the proposal says to keep the current lists and I think that's fine. > Still there will be one more list for the "podling PMC" which will be > lucene-net-priv...@incubator.ao. All initial committers and mentors > will be asked to subscribe to that list once it is there. > > I intend to make the three mentors moderators for the private list but > have no idea if the existing mailing lists are moderated, by whom and > whether you want to change the current moderators (I already moderate > quite a few lists and a few more won't hurt, my spam filters work ;-). > > Have I missed anything? > > Stefan >
Re: Incubator Infra: JIRA
Lucene.Net users sometimes discuss the same issue in both JIRA and dev mailing list. And people mostly don't subscribe to commit list(I wouldn't also subscribe to commit-list, if I weren't a committer since it is full of spam :) ). So I would prefer leaving it as is. DIGY On Tue, Feb 1, 2011 at 1:58 PM, Sergey Mirvoda wrote: > Hello Stefan. > As for me I think JIRA notifications should go to the commits list. > > > On Tue, Feb 1, 2011 at 3:53 PM, Stefan Bodewig wrote: > > > Hi, > > > > I know JIRA is already in place. Right now all notifications seem to go > > to the dev list while on other projects I'm onvolved in the > > notifications go to the commits list. Is this a consciuos choice you > > want to keep? > > > > Also, is anybody around here JIRA admin (at least for LUCENENET)? I > > currently am not. > > > > Stefan > > > > > > -- > --Regards, Sergey Mirvoda >
Re: [Lucene.Net] Creating a Strong Named Assembly as part of our release
On Tue, Feb 22, 2011 at 3:04 AM, Troy Howard wrote:
> DIGY - Extracting the public key out is generally only used for delay
> signing.
In my senario, public key will not be used in delay signing. Just for
validating the assembly by comparing the public key in assembly with the
public key file in svn.
> I don't think delay signing would help our situation, because
> it means an end user still needs our private key to make a complete
> signed build.
>
>
An end user still has the choice of using assembly signed by Lucene.Net team
or signing it by compiling the source with his key. Of course,He can not
sign the assembly with Lucene.Net team's private key and this is the
intented behaviour of "signing"
> As a side note, I just realized that the multiple-signers scenario I
> described in my initial post wouldn't happen, since the public key
> token is included in the fully qualified assembly name. A different
> signer, using a different SNK, would create a DLL with a different
> FQAN. Side-by-side installs of the same version of Lucene.Net, built
> by different signers could function on the same machine, no problem.
>
> Anyhow, so essentially the question that remains is: Publicly
> distribute the SNK or not?
>
> It seems like trying to keep track of the private SNK file via mailing
> list may run into problems at some point.
>
> I think Robert probably is right.. That we should just include it in
> SVN publicly, and make sure we state clearly that even though an
> assembly may be signed using our strong named signature, that unless
> it validates via OpenPGP key, it is not an official build and
> shouldn't be trusted as a ASF endorsed binary. Language to that effect
> should be included in a README file for our binary releases.
>
It would be a solution too, but users will have to learn more tools.
Thanks,
> Troy
>
DIGY
>
>
> On Mon, Feb 21, 2011 at 2:25 PM, Digy wrote:
> > After we have two files,
> >one contaning public+private key(Lucene.Net.snk)
> >{sn -k Lucene.Net.snk}
> >and the other containing just public key(Lucene.Net.Public.snk)
> >{sn -p Lucene.Net.snk Lucene.Net.Public.snk}
> > we can share Lucene.Net.snk via private mailing list and put the
> Lucene.Net.Public.snk to svn.
> >
> >
> > Assuming that we create two binary releases(signed + unsigned), users
> have many alternatives like source-code, signed release or unsigned release
> and free to choose any one of them.
> >
> > I don't think that some extreme cases(like one uses the signed-release in
> GAC and then wants to compile and sign with his own key and forgets to
> remove the old one from GAC) should be handled by Lucene.Net.
> > At the end, all Lucene.Net users are developers.
> >
> > DIGY
> >
> >
> > -Original Message-
> > From: Troy Howard [mailto:thowar...@gmail.com]
> > Sent: Monday, February 21, 2011 7:08 PM
> > To: lucene-net-dev@lucene.apache.org
> > Subject: [Lucene.Net] Creating a Strong Named Assembly as part of our
> release
> >
> > All,
> >
> > There was a request, in LUCENENET-389 [1], that our binary release be
> > signed as a Strong Named Assembly (SNA). There are many compelling
> > reasons to do this, however managing this as an open source project
> > raises some questions.
> >
> > The main question is, how to manage the Strong Name Key (SNK) file?
> >
> > Since this file contains the private key in the strong-naming
> > asymmetric encryption scheme, it is supposed to be kept privately by
> > the signer. In this way, a given assembly can be verified as coming
> > from that particular signer, because only they can make a build which
> > is signed using that private key. If we include that in the source
> > trunk, we are essentially allowing anyone to sign any assembly with
> > the Lucene.Net naming key.
> >
> > This has many implications, not the least of which is that an end user
> > could change the code in a malicious manner, and recompile, signing
> > with our key, and create an assembly which seems like a valid build,
> > and specifically seems to be *endorsed* by the Apache Lucene.Net
> > brand.
> >
> >
> > If we keep the key private, how do we then manage it? Is there a place
> > to store these kinds of resources, where only the committers have
> > access? Is this even reasonable considering the seeming philosophical
> > disparity between this idea and the open source ideal?
> >
> >
> > Another option, is to provide instructions for the end user on how to
> > create their own
Re: [Lucene.Net] [VOTE] Release Apache Lucene.Net 2.9.2-incubating-RC2
+1 DIGY On Mon, Feb 28, 2011 at 11:04 AM, Glyn Darkin wrote: > +1 > On 28 Feb 2011, at 08:39, Troy Howard wrote: > > > All, > > > > A quick voting reminder... This [VOTE] thread will only be active for > > another 4 hours (72 hours total). > > > > So far, we have two +1 votes in. > > > > After this vote, the release will be proposed to the Incubator PMC, > > and will have another 72 hour vote for acceptance there. Assuming that > > passes, it will become an official ASF Incubator release. > > > > Thanks, > > Troy > > > > > > On Fri, Feb 25, 2011 at 12:29 PM, Stefan Bodewig > wrote: > >> On 2011-02-25, Troy Howard wrote: > >> > >>> I updated the .src zip and associated checksums/signatures at: > >> > >> I have verified the bin zip is still the same that I checked. All > >> signatures and hashes are fine, RAT is reasonably happy with the src zip > >> (I've updated > >> <http://people.apache.org/~bodewig/Lucene.NET/src-rat.log>). > >> > >> +1 from me for the release. Of course I haven't perfromed any technical > >> tests, just verified the artifacts meet the Incubator requirements (at > >> least all I know of). > >> > >>> Hopefully this one will pass the licensing validation! I think I got > >>> them all this time.. > >> > >> Thanks a lot. > >> > >> Stefan > >> > > Glyn Darkin > > Darkin Systems Ltd > Mob: 07961815649 > Fax: 08717145065 > Web: www.darkinsystems.com > > Company No: 6173001 > VAT No: 906350835 > > > > > >
Re: [Lucene.Net] CI Task Update: Hudkins
+1 DIGY On Mon, Feb 28, 2011 at 10:29 AM, Troy Howard wrote: > +1 to all suggestions. Hudkins is my new favourite word. ;) > > One quick concern I have, is how much of the things listed are already > available on the Apache hudson server? A lot of this is .NET specific, so > unlikely that it will already be available. We'll have to request that ASF > Infra team install these tools for us, and they may not agree, or there > might be licensing issues, etc.. Not sure. I'd start the conversation with > them now to suss this out. > > Specifically some thoughts: > > - FxCop/StyleCop/NCover/NDepend are a basics which should be viewed as a > necessity for any serious .NET project > - I love SandCastle and was about to bring that up on the list. We could > keep rolling with NDoc. Either way. > - I love Gallio/MbUnit/Moq... nunit not so much, but again, either would be > fine. > - Mono is going to be a requirement moving forward > - Project structure was being discussed on the LUCENENET-377 thread. For > the binary release, I used a structure similar to what you were describing, > and the topic of applying that structure to trunk came up. This is something > that we should discuss in detail before applying to trunk (my work was in a > branch). We need to make sure directory structure remains relatively static, > however, current structure needs a lot of improvement.. So now is a good > time to change. > > Digy suggested: > > \build > \contrib > \core > \core\Lucene.Net > \core\Test > \demo > > ... and in the recent binary release, I used a root \bin and \doc in the > same way you suggested. > > > As a combination of ideas, how about: > > Build Files: > > \build > \build\VS2008 > \build\VS2010 > > > Source Projects: > > \src > \src\contrib > \src\core > \src\demo > \src\contrib\ > \src\core\ > \src\demo\ > > > Test Projects: > > \test > \test\contrib > \test\core > \test\demo > \test\contrib\ > \test\core\ > \test\demo\ > > > Product Documentation: > > \doc > \doc\contrib > \doc\core > \doc\demo > \doc\contrib\ > \doc\core\ > \doc\demo\ > > > Third-Party Dependencies: > > \lib > \lib\ > \lib\\ > \lib\\\ > > > Binary Builds: > > \bin > \bin\contrib > \bin\core > \bin\demo > \bin\contrib\ > \bin\core\ > \bin\demo\ > > > Thanks, > Troy > > > > On Sun, Feb 27, 2011 at 11:10 PM, Michael Herndon wrote: > >> So the CI choices for Apache are the following: >> >> >>- Buildbot <http://ci.apache.org/#buildbot> >>- Continuum <http://ci.apache.org/#continuum> >>- Gump <http://ci.apache.org/#gump> >>- Hudson <http://ci.apache.org/#hudson> >> >> There is a current discussion on the build list about moving with the name >> shift of hudson to jenkins. >> >> My vote is to go with hudkins [?] because it has been successfully used >> for .net projects in the past and has plugins to help support that. Nothing >> personal against python, but there seems to be more material on integration >> .net builds inside of Hudson. >> >> I've also used Hudson in the past so I can vouch that it does a decent >> job. (This was a while ago, so I can only hope the number of plugins and >> integration points have increased). >> >> I'm going to do a bit more reading on the apache mailing list for builds >> to see if there is an actual windows slave for hudson/jenkins (which shall >> henceforth be called hudkins on this list, well at least by me). >> >> Obviously the first priority will be getting a build set up and starting >> simple. However to spark discussion and future planning: Here is a list of >> other things to include or think about for the build process long term. >> >> * fxcop - (this will probably need customized rules for strict java port >> version) >> * stylecop - (same) >> * sandcastle - (building xml comments into documentation). >> * sandcastle help file builder - (SHFB) >> * code coverage tool - possibly seeing if we can get a code coverage tool >> (possibly ncover as they used to give a free license to os projects), >> * code metrics tool - (i.e. cyclomatic complexity, ndepend used to do the >> same thing as ncover, thus worth investigating). >> * gallio test runner vs nunit. (gallio is testing automation tool capable >> of running various testing frameworks and tools including nunit). >> * extended msbuild tasks. >> * mono build. >> * project structure for the build. ** >> * insert _ any oth
Re: [Lucene.Net] [VOTE] New Directory Layout for Project
0 ".Net"s seem to be redundant under /src/contrib/ . It could be something like Analyzers Highlighter Similarity ... (Maybe, we should find a different name for contrib.net. It contains "contributions specific to Lucene.Net which are not available in Lucene.java) DIGY On Wed, Mar 9, 2011 at 9:08 PM, Prescott Nasser wrote: > > Probably just a miss - but under the src/contrib folder you also have a > number of tests in there... > > > Also, is it necessary to have all the sub folders? For the most part the > stuff in contrib.net is contrib.net - why the secondary folder? Unless > that is a requirement of NUnit to have the structure that way it seems a bit > cluttered. > > I would think something like > > src/contrib/contrib.net/ > src/contrib/Snowball.net/ > > instead of > > src/contrib/contrib.net/contrib.net/ > src/contrib/snowball/snowball.net/ > > I don't know how people feel about that > > > ~P > > > > > Date: Wed, 9 Mar 2011 13:31:34 -0500 > > From: mhern...@wickedsoftware.net > > To: lucene-net-dev@lucene.apache.org > > CC: thowar...@gmail.com > > Subject: Re: [Lucene.Net] [VOTE] New Directory Layout for Project > > > > +1 > > > > just a question though. for cmd/bat//sh files for letting people > executing > > the build or just executing other tools from the command line, would > those > > have a place in /bin or somewhere els? This is that someone can just > export > > PATH = / SET PATH= to that one folder and then be able to execute those > > commands from one location? > > > > > > > > On Sun, Mar 6, 2011 at 11:27 PM, Troy Howard wrote: > > > > > All, > > > > > > We'd like to update the project directory structure/layout. > > > > > > See below for a proposed layout. I've also uploaded an example which > > > you can navigate at: > > > > > > > http://people.apache.org/~thoward/Lucene.Net/directory-structure-example > > > > > > NOTE: This will not build!! I just put things in the appropriate > > > places without updating the solution/project files to show how we > > > might lay things out. Also, I included NUnit as an example of a > > > third-party dependency that we might include in the repository under > > > 'lib'. We of course will *not* be distributing NUnit in this manner, > > > due to licensing restrictions. > > > > > > Ok, disclaimer over... > > > > > > Please vote on this layout, or suggest a modification or alternative > > > layout. > > > > > > Voting will be open for 72 hours. > > > > > > [ ] +1 Use this directory structure exactly as described, or with a > > > minor modification > > > [ ] 0 Use a different structure (described in response) > > > [ ] -1 Do not change the directory structure at all > > > > > > > > > Text description of directory schema: > > > > > > Build Files: > > > > > > \build > > > \build\VS2008 > > > \build\VS2010 > > > > > > > > > Source Projects: > > > > > > \src > > > \src\contrib > > > \src\core > > > \src\demo > > > \src\contrib\ > > > \src\core\ > > > \src\demo\ > > > > > > > > > Test Projects: > > > > > > \test > > > \test\contrib > > > \test\core > > > \test\demo > > > \test\contrib\ > > > \test\core\ > > > \test\demo\ > > > > > > > > > Product Documentation: > > > > > > \doc > > > \doc\contrib > > > \doc\core > > > \doc\demo > > > \doc\contrib\ > > > \doc\core\ > > > \doc\demo\ > > > > > > > > > Third-Party Dependencies: > > > > > > \lib > > > \lib\ > > > \lib\\ > > > \lib\\\ > > > > > > > > > Binary Builds: > > > > > > \bin > > > \bin\contrib > > > \bin\core > > > \bin\demo > > > \bin\contrib\ > > > \bin\core\ > > > \bin\demo\ > > >
Re: [Lucene.Net] [VOTE] New Directory Layout for Project
Well, not really "core". Codes under Analyzer(by DIGY) can be moved to /src/contrib/analyzers (but they are not ports from java). The others(by M.GARSKI) are extensions to the core(something like Lucene.Net.Core.Extensions) DIGY On Thu, Mar 10, 2011 at 1:36 AM, Troy Howard wrote: > Yeah -- I also changed the Contrib.Net project folder name to > ~/src/contrib/core ... > > IMO we should just roll these into the main library if they are solid, > tested and useful.. This is keeping in line with our new philosophy > about allowing .NET specific changes, even if it means diverging from > Java Lucene to do it. > > Thanks, > Troy > > > On Wed, Mar 9, 2011 at 12:56 PM, Prescott Nasser > wrote: > > > > Actually what IS contrib.net? It looks like it replaces certain files in > Lucene.Net core - are they files better suited to .net? What are they? > > > > If they are plugins / additional contributions like snowball, etc - why > not just break it out and include the appropriate stuff in contrib? Do we > need to specify that they are not avaliable in the java version? > > > > > > > > > > > > > >> Date: Wed, 9 Mar 2011 22:18:22 +0200 > >> From: digyd...@gmail.com > >> To: lucene-net-dev@lucene.apache.org > >> Subject: Re: [Lucene.Net] [VOTE] New Directory Layout for Project > >> > >> 0 > >> > >> ".Net"s seem to be redundant under /src/contrib/ . It could be something > >> like > >> Analyzers > >> Highlighter > >> Similarity > >> ... > >> > >> > >> > >> (Maybe, we should find a different name for contrib.net. It contains > >> "contributions specific to Lucene.Net which are not available in > >> Lucene.java) > >> > >> DIGY > >> > >> On Wed, Mar 9, 2011 at 9:08 PM, Prescott Nasser wrote: > >> > >> > > >> > Probably just a miss - but under the src/contrib folder you also have > a > >> > number of tests in there... > >> > > >> > > >> > Also, is it necessary to have all the sub folders? For the most part > the > >> > stuff in contrib.net is contrib.net - why the secondary folder? > Unless > >> > that is a requirement of NUnit to have the structure that way it seems > a bit > >> > cluttered. > >> > > >> > I would think something like > >> > > >> > src/contrib/contrib.net/ > >> > src/contrib/Snowball.net/ > >> > > >> > instead of > >> > > >> > src/contrib/contrib.net/contrib.net/ > >> > src/contrib/snowball/snowball.net/ > >> > > >> > I don't know how people feel about that > >> > > >> > > >> > ~P > >> > > >> > > >> > > >> > > Date: Wed, 9 Mar 2011 13:31:34 -0500 > >> > > From: mhern...@wickedsoftware.net > >> > > To: lucene-net-dev@lucene.apache.org > >> > > CC: thowar...@gmail.com > >> > > Subject: Re: [Lucene.Net] [VOTE] New Directory Layout for Project > >> > > > >> > > +1 > >> > > > >> > > just a question though. for cmd/bat//sh files for letting people > >> > executing > >> > > the build or just executing other tools from the command line, would > >> > those > >> > > have a place in /bin or somewhere els? This is that someone can just > >> > export > >> > > PATH = / SET PATH= to that one folder and then be able to execute > those > >> > > commands from one location? > >> > > > >> > > > >> > > > >> > > On Sun, Mar 6, 2011 at 11:27 PM, Troy Howard wrote: > >> > > > >> > > > All, > >> > > > > >> > > > We'd like to update the project directory structure/layout. > >> > > > > >> > > > See below for a proposed layout. I've also uploaded an example > which > >> > > > you can navigate at: > >> > > > > >> > > > > >> > > http://people.apache.org/~thoward/Lucene.Net/directory-structure-example > >> > > > > >> > > > NOTE: This will not build!! I just put things in the appropriate > >> > > > places without updating the
Re: [Lucene.Net] svn commit: r1080881 - in /incubator/lucene.net/trunk/C#/src/Lucene.Net: Index/DocumentsWriter.cs Index/StoredFieldsWriter.cs Index/TermVectorsTermsWriter.cs Index/TermVectorsTermsWri
It would be better to attach the patches to the issue before committing.
So others can track what is going on.
DIGY
On Sat, Mar 12, 2011 at 9:20 AM, wrote:
> Author: slombard
> Date: Sat Mar 12 07:20:44 2011
> New Revision: 1080881
>
> URL: http://svn.apache.org/viewvc?rev=1080881&view=rev
> Log:
> [LUCENENET-399] (trunk) 2.9.3 - change LUCENE 2283: use shared byte[] pool
> to buffer pending stored fields & term vectors during indexing; fixes
> excessive memory usage for mixed tiny & big docs with many threads
>
> Modified:
>incubator/lucene.net/trunk/C#/src/Lucene.Net/Index/DocumentsWriter.cs
>incubator/
> lucene.net/trunk/C#/src/Lucene.Net/Index/StoredFieldsWriter.cs
>incubator/
> lucene.net/trunk/C#/src/Lucene.Net/Index/TermVectorsTermsWriter.cs
>incubator/
> lucene.net/trunk/C#/src/Lucene.Net/Index/TermVectorsTermsWriterPerField.cs
>incubator/lucene.net/trunk/C#/src/Lucene.Net/Store/RAMFile.cs
>incubator/lucene.net/trunk/C#/src/Lucene.Net/Store/RAMOutputStream.cs
>
> Modified: incubator/
> lucene.net/trunk/C#/src/Lucene.Net/Index/DocumentsWriter.cs
> URL:
> http://svn.apache.org/viewvc/incubator/lucene.net/trunk/C%23/src/Lucene.Net/Index/DocumentsWriter.cs?rev=1080881&r1=1080880&r2=1080881&view=diff
>
> ==
> ---
> incubator/lucene.net/trunk/C#/src/Lucene.Net/Index/DocumentsWriter.cs(original)
> +++ incubator/lucene.net/trunk/C#/src/Lucene.Net/Index/DocumentsWriter.csSat
> Mar 12 07:20:44 2011
> @@ -19,15 +19,16 @@ using System;
>
> using Analyzer = Lucene.Net.Analysis.Analyzer;
> using Document = Lucene.Net.Documents.Document;
> -using AlreadyClosedException = Lucene.Net.Store.AlreadyClosedException;
> -using Directory = Lucene.Net.Store.Directory;
> -using ArrayUtil = Lucene.Net.Util.ArrayUtil;
> -using Constants = Lucene.Net.Util.Constants;
> using IndexSearcher = Lucene.Net.Search.IndexSearcher;
> using Query = Lucene.Net.Search.Query;
> using Scorer = Lucene.Net.Search.Scorer;
> using Similarity = Lucene.Net.Search.Similarity;
> using Weight = Lucene.Net.Search.Weight;
> +using AlreadyClosedException = Lucene.Net.Store.AlreadyClosedException;
> +using Directory = Lucene.Net.Store.Directory;
> +using RAMFile = Lucene.Net.Store.RAMFile;
> +using ArrayUtil = Lucene.Net.Util.ArrayUtil;
> +using Constants = Lucene.Net.Util.Constants;
>
> namespace Lucene.Net.Index
> {
> @@ -104,7 +105,7 @@ namespace Lucene.Net.Index
>{
>
>internal override DocConsumer
> GetChain(DocumentsWriter documentsWriter)
> - {
> +{
>/*
>This is the current indexing chain:
>
> @@ -145,7 +146,8 @@ namespace Lucene.Net.Index
>freeLevel = (long)
> (IndexWriter.DEFAULT_RAM_BUFFER_SIZE_MB * 1024 * 1024 * 0.95);
>maxBufferedDocs =
> IndexWriter.DEFAULT_MAX_BUFFERED_DOCS;
>skipDocWriter = new SkipDocWriter();
> - byteBlockAllocator = new ByteBlockAllocator(this);
> + byteBlockAllocator = new ByteBlockAllocator(this,
> BYTE_BLOCK_SIZE);
> +perDocAllocator = new ByteBlockAllocator(this,
> PER_DOC_BLOCK_SIZE);
>waitQueue = new WaitQueue(this);
>}
>
> @@ -220,6 +222,59 @@ namespace Lucene.Net.Index
>}
>}
>
> +//Create and return a new DocWriterBuffer.
> +internal PerDocBuffer newPerDocBuffer()
> +{
> +return new PerDocBuffer(perDocAllocator);
> +}
> +
> +/// RAMFile buffer for DocWriters.
> +internal class PerDocBuffer:RAMFile
> +{
> +public PerDocBuffer(ByteBlockAllocator perDocAllocator)
> + {
> + InitBlock(perDocAllocator);
> + }
> +private void InitBlock(ByteBlockAllocator perDocAllocator)
> + {
> +this.perDocAllocator = perDocAllocator;
> + }
> +private ByteBlockAllocator perDocAllocator;
> +
> +///
> +/// Allocate bytes used from shared pool.
> +///
> +/// Size of new buffer. Fixed at cref="PER_DOC_BLOCK_SIZE"/>.
> +///
> +protected internal byte[] newBuffer(int size)
> +{
> +System.Diagnostics.Debug.Assert(size ==
> PER_DOC_BLOCK_SIZE);
> +return perDoc
Re: [Lucene.Net] release 2.9.4
Sorry, no binaries. You can download the source from https://svn.apache.org/repos/asf/incubator/lucene.net/trunk/C#/src/Lucene.Net DIGY On Tue, Apr 5, 2011 at 12:12 AM, Wyatt Barnett wrote: > Actually about to dive into a big search tweaking spike in a certain > project here, happy to do it on 2.9.4. Got binaries? > > On Mon, Apr 4, 2011 at 12:27 PM, Troy Howard wrote: > > We don't have any sort of QA report on the latest build. DIGY called > > for testing, but I haven't seen anyone respond to that request > > indicating successful testing. > > > > So, how do we want to manage this? > > > > In the business world, we'd never think of making a release without > > extensive QA first. In my other open source projects, either we've > > managed QA ourselves by 'switching hats' for a couple weeks prior to > > release, or just crossed our fingers because the user base was too > > small. > > > > Lucene.Net is a fairly high-profile project, with a large user base. I > > think it would not be responsible to make a release without a formal > > QA process. We do have extensive unit tests, but do you think those > > are sufficient to cover our QA needs? Should we try to find community > > members with a specialty in software testing that would be willing to > > fulfill this role on our project? Should we just swap hats? > > > > I didn't worry about this issue with the latest 2.9.2 release because > > it was QAed by the user base for a long time before it was an > > 'official release'. Maybe this is an effective tactic? Release first, > > and let the user base roll in bug reports fixing them on yet later > > minor maintenance releases? This seems to be the method a lot of > > projects use (i.e. no specific QA process, but rather an organic > > process of 'try our best then deal with bug reports later'). > > > > What do we think about this? > > > > Thanks, > > Troy > > > > > > On Sun, Apr 3, 2011 at 11:59 PM, Prescott Nasser > wrote: > >> > >> Hey all, > >> > >> I know we have a number of outstanding JIRA issues, but I think most of > them have been handled for the 2.9.4 release? Do we have anything > outstanding that is holding back a new release? > >> > >> ~P > > >
Re: [Lucene.Net] release 2.9.4
Thanks, updated. DIGY On Tue, Apr 5, 2011 at 11:34 PM, Granroth, Neal V. < neal.granr...@thermofisher.com> wrote: > > I had no difficulty building it in Visual Studio 2005. > The assembly copyright information appears to be out of date; shouldn't it > read 2011 not 2009 ? > > > - Neal > > -Original Message- > From: Wyatt Barnett [mailto:wyatt.barn...@gmail.com] > Sent: Tuesday, April 05, 2011 2:23 PM > To: lucene-net-dev@lucene.apache.org > Cc: Troy Howard > Subject: Re: [Lucene.Net] release 2.9.4 > > Tag [+1] > > svn export and command line build successful; I'll keep you all posted . . > . > > On Tue, Apr 5, 2011 at 3:07 PM, Troy Howard wrote: > > Yes. Once we're ready to call this revision an RC, it should be tagged as > such. > > > > Wyatt: Thanks for helping to test! Looking forward to your results. > > > > Thanks, > > Troy > > > > > > On Tue, Apr 5, 2011 at 11:37 AM, Granroth, Neal V. > > wrote: > >> > >> No, the URL in DIGY's email apepars correct and the SVN revision appears > to be 1086410. > >> > >> Question: Should there be a tag for Lucene.Net_2_9_4 as there are for > previous release candidates? > >> > >> - Neal > >> > >> -Original Message- > >> From: Wyatt Barnett [mailto:wyatt.barn...@gmail.com] > >> Sent: Tuesday, April 05, 2011 12:15 PM > >> To: lucene-net-dev@lucene.apache.org > >> Cc: digy digy > >> Subject: Re: [Lucene.Net] release 2.9.4 > >> > >> Thanks. For anyone watching, the corrected clickable link is > >> https://svn.apache.org/repos/asf/incubator/lucene.net/trunk/C%23/. > >> > >> Also, just to make sure we are looking at this right, the revision we > >> should be using is 1089138 -- main thing is I've been in and out of > >> town, not caught up on anything and I'd hate to start building stuff > >> against the wrong version . . > >> > >> On Tue, Apr 5, 2011 at 1:10 PM, digy digy wrote: > >>> Sorry, no binaries. You can download the source from > >>> > https://svn.apache.org/repos/asf/incubator/lucene.net/trunk/C#/src/Lucene.Net > >>> > >>> DIGY > >>> > >>> On Tue, Apr 5, 2011 at 12:12 AM, Wyatt Barnett < > wyatt.barn...@gmail.com>wrote: > >>> > >>>> Actually about to dive into a big search tweaking spike in a certain > >>>> project here, happy to do it on 2.9.4. Got binaries? > >>>> > >>>> On Mon, Apr 4, 2011 at 12:27 PM, Troy Howard > wrote: > >>>> > We don't have any sort of QA report on the latest build. DIGY called > >>>> > for testing, but I haven't seen anyone respond to that request > >>>> > indicating successful testing. > >>>> > > >>>> > So, how do we want to manage this? > >>>> > > >>>> > In the business world, we'd never think of making a release without > >>>> > extensive QA first. In my other open source projects, either we've > >>>> > managed QA ourselves by 'switching hats' for a couple weeks prior to > >>>> > release, or just crossed our fingers because the user base was too > >>>> > small. > >>>> > > >>>> > Lucene.Net is a fairly high-profile project, with a large user base. > I > >>>> > think it would not be responsible to make a release without a formal > >>>> > QA process. We do have extensive unit tests, but do you think those > >>>> > are sufficient to cover our QA needs? Should we try to find > community > >>>> > members with a specialty in software testing that would be willing > to > >>>> > fulfill this role on our project? Should we just swap hats? > >>>> > > >>>> > I didn't worry about this issue with the latest 2.9.2 release > because > >>>> > it was QAed by the user base for a long time before it was an > >>>> > 'official release'. Maybe this is an effective tactic? Release > first, > >>>> > and let the user base roll in bug reports fixing them on yet later > >>>> > minor maintenance releases? This seems to be the method a lot of > >>>> > projects use (i.e. no specific QA process, but rather an organic > >>>> > process of 'try our best then deal with bug reports later'). > >>>> > > >>>> > What do we think about this? > >>>> > > >>>> > Thanks, > >>>> > Troy > >>>> > > >>>> > > >>>> > On Sun, Apr 3, 2011 at 11:59 PM, Prescott Nasser < > geobmx...@hotmail.com> > >>>> wrote: > >>>> >> > >>>> >> Hey all, > >>>> >> > >>>> >> I know we have a number of outstanding JIRA issues, but I think > most of > >>>> them have been handled for the 2.9.4 release? Do we have anything > >>>> outstanding that is holding back a new release? > >>>> >> > >>>> >> ~P > >>>> > > >>>> > >>> > >> > > >
Re: [Lucene.Net] How can we implement faceted search with lucene
http://www.devatwork.nl/articles/lucenenet/faceted-search-and-drill-down-lucenenet/ DIGY On Fri, May 13, 2011 at 10:40 AM, K a r n a v wrote: > How can we implement faceted search with lucene >
Re: [Lucene.Net] [jira] [Commented] (LUCENENET-412) Replacing ArrayLists, Hashtables etc. with appropriate Generics.
just aesthetical reasons. See the java code
cache = new FilterCache(deletesMode) {
@Override
public DocIdSet mergeDeletes(final IndexReader r, final DocIdSet
docIdSet) {
return new FilteredDocIdSet(docIdSet) {
@Override
protected boolean match(int docID) {
return !r.isDeleted(docID);
}
};
}
};
DIGY
On Wed, May 18, 2011 at 2:14 AM, Rory Plaire wrote:
> This is a great improvement, but why not also remove the braces and
> returns?
>
>
> var cache = new FilterCache(deletesMode,
> (reader, docIdSet) => new FilteredDocIdSet(
> (DocIdSet)docIdSet, docid => !reader.IsDeleted(docid)));
>
>
> On Tue, May 17, 2011 at 3:01 PM, Digy (JIRA) wrote:
>
> >
> >[
> >
> https://issues.apache.org/jira/browse/LUCENENET-412?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13035092#comment-13035092
> ]
> >
> > Digy commented on LUCENENET-412:
> >
> >
> > One more sample
> > {code}
> > From:
> >class AnonymousFilterCache : FilterCache
> >{
> >class AnonymousFilteredDocIdSet : FilteredDocIdSet
> >{
> >IndexReader r;
> >public AnonymousFilteredDocIdSet(DocIdSet
> innerSet,
> > IndexReader r) : base(innerSet)
> >{
> >this.r = r;
> >}
> >public override bool Match(int docid)
> >{
> >return !r.IsDeleted(docid);
> >}
> >}
> >
> >public AnonymousFilterCache(DeletesMode deletesMode) :
> > base(deletesMode)
> >{
> >}
> >
> >protected override object MergeDeletes(IndexReader
> reader,
> > object docIdSet)
> >{
> >return new
> > AnonymousFilteredDocIdSet((DocIdSet)docIdSet, reader);
> >}
> >}
> >...
> >cache = new AnonymousFilterCache(deletesMode);
> >
> >
> >
> > To:
> >cache = new FilterCache(deletesMode,
> >(reader,docIdSet)=>{
> >return new FilteredDocIdSet((DocIdSet)docIdSet,
> >(docid) =>
> >{
> >return !reader.IsDeleted(docid);
> >});
> > });
> > {code}
> >
> > DIGY
> >
> > > Replacing ArrayLists, Hashtables etc. with appropriate Generics.
> > >
> > >
> > > Key: LUCENENET-412
> > > URL:
> https://issues.apache.org/jira/browse/LUCENENET-412
> > > Project: Lucene.Net
> > > Issue Type: Improvement
> > >Affects Versions: Lucene.Net 2.9.4
> > >Reporter: Digy
> > >Priority: Minor
> > > Fix For: Lucene.Net 2.9.4
> > >
> > > Attachments: IEquatable for Query&Subclasses.patch,
> > LUCENENET-412.patch, lucene_2.9.4g_exceptions_fix
> > >
> > >
> > > This will move Lucene.Net.2.9.4 closer to lucene.3.0.3 and allow some
> > performance gains.
> >
> > --
> > This message is automatically generated by JIRA.
> > For more information on JIRA, see:
> http://www.atlassian.com/software/jira
> >
>
Re: [Lucene.Net] [jira] [Commented] (LUCENENET-412) Replacing ArrayLists, Hashtables etc. with appropriate Generics.
On Fri, May 20, 2011 at 12:34 PM, Andy Pook wrote: > It'd be useful if There was a StopAnalyzer ctor overload that took an > IEnumerable and maybe the current one that takes List > should > be ICollection (same as internal stopWords member). > Just gives a little flexibility on the types that can be used. > > I changed List to ICollection > Also there is a little confusion around the treatment of the various > collection types. i.e. string[] gets converted to a CharArraySet. Why not > just a List ? > So is it in lucene.java > > Thoughts? > > Cheers, > Andy > DIGY > > On 18 May 2011 23:20, Digy (JIRA) wrote: > > > > >[ > > > https://issues.apache.org/jira/browse/LUCENENET-412?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13035795#comment-13035795 > ] > > > > Digy commented on LUCENENET-412: > > > > > > Hi All, > > > > Lucene.Net 2.9.4g is almost ready for testing & feedbacks. > > > > While injecting generics & making some clean up in code, I tried to be > > close to lucene 3.0.3 as much as possible. > > Therefore it's position is somewhere between lucene.Java 2.9.4 & 3.0.3 > > > > DIGY > > > > > > PS: For those who might want to try this version: > > It won't probably be a drop-in replacement since there are a few API > > changes like > > - StopAnalyzer(List stopWords) > > - Query.ExtractTerms(ICollection) > > - TopDocs.*TotalHits*, TopDocs.*ScoreDocs* > > and some removed methods/classes like > > - Filter.Bits > > - JustCompileSearch > > - Contrib/Similarity.Net > > > > > > > > > > > Replacing ArrayLists, Hashtables etc. with appropriate Generics. > > > ---- > > > > > > Key: LUCENENET-412 > > > URL: > https://issues.apache.org/jira/browse/LUCENENET-412 > > > Project: Lucene.Net > > > Issue Type: Improvement > > >Affects Versions: Lucene.Net 2.9.4 > > >Reporter: Digy > > >Priority: Minor > > > Fix For: Lucene.Net 2.9.4 > > > > > > Attachments: IEquatable for Query&Subclasses.patch, > > LUCENENET-412.patch, lucene_2.9.4g_exceptions_fix > > > > > > > > > This will move Lucene.Net.2.9.4 closer to lucene.3.0.3 and allow some > > performance gains. > > > > -- > > This message is automatically generated by JIRA. > > For more information on JIRA, see: > http://www.atlassian.com/software/jira > > >
Re: [Lucene.Net] 2.9.4g branch - test
I've never committed any code to 2.9.4g branch before testing. So, It should pass all the tests. DIGY On Mon, Jun 13, 2011 at 4:26 AM, Prescott Nasser wrote: > > Does anyone have the latest 2.9.4g branch they can run the tests on - I've > done some WP7 stuff, and I'm coming up with 6 errors throughout all the > tests. I didn't think to test before hand, and at the moment, I can't > download a fresh copy of the branch > > ~P
Re: [Lucene.Net] 2.9.4
You are right. I forgot to add a patch related with type-casting. Summary of the long story: Since CharArraySet inherits from Hashtable, some unimplemented methods such as Add(object,object) refer to the base class(Hashtable) which is wrong. Also calling GetEnumerator() using the System.Collections.ICollection interface does result in Hashtable's GetEnumerator() being invoked. So an explicit typecast is needed for invoking CharArraySet.GetEnumerator() (As a result, a bad (but *almost* working) implementation. It is rewritten in 2.9.4g) DIGY On Wed, Sep 7, 2011 at 4:11 AM, Prescott Nasser wrote: > > Also +1 - but I don't mind waiting to hear back regarding the RavenDB stuff > - but we can prepare assuming it's all good. > > > > Digy can you elaborate on 414 ( > https://issues.apache.org/jira/browse/LUCENENET-414). I must not have > understood the complaint/question as adding that one method to me doesn't > seem to resolve the issue brought up > > > > Thanks, > > ~P > > > > From: digyd...@gmail.com > > To: lucene-net-dev@lucene.apache.org > > Date: Tue, 6 Sep 2011 23:14:37 +0300 > > Subject: RE: [Lucene.Net] 2.9.4 > > > > +1 for an official release. > > DIGY > > > > -Original Message- > > From: Prescott Nasser [mailto:geobmx...@hotmail.com] > > Sent: Monday, September 05, 2011 9:22 PM > > To: lucene-net-dev@lucene.apache.org; lucene-net-u...@lucene.apache.org > > Subject: [Lucene.Net] 2.9.4 > > > > > > Hey All, > > > > > > > > How do people feel about the 2.9.4 code base? I've been using it for > > sometime, for my use cases it's be excellent. Do we feel we are ready to > > package this up and make it an official release? Or do we have some tasks > > left to take care of? > > > > > > > > ~Prescott = > > - > > Bu iletide virüs bulunamadı. > > AVG tarafından kontrol edildi - www.avg.com > > Sürüm: 2012.0.1796 / Virüs Veritabanı: 2082/4478 - Sürüm Tarihi: > 05.09.2011 > > >
Re: [Lucene.Net] 2.9.4
Since it includes some level of divergence from java I committed it to only 2.9.4g branch. https://issues.apache.org/jira/browse/LUCENE-1930 https://issues.apache.org/jira/browse/LUCENENET-431 DIGY On Wed, Sep 7, 2011 at 1:03 PM, Itamar Syn-Hershko wrote: > Ok, core compiles, and all tests pass. We are now running long tests to > measure memory usage among other things. > > There is one show stopper tho. There was a patch sent by Matt Warren for > Spatial.Net, that doesn't seem to be in. See > http://groups.google.com/group/ravendb/msg/7517f095810c48f3 > > Any chance you can get it in to 2.9.4? > > On Wed, Sep 7, 2011 at 1:01 AM, Itamar Syn-Hershko >wrote: > > > Ok, great, we will run RavenDB on top of 2.9.4 in the next few days and > > will let you know how it went. > > > > > > On Tue, Sep 6, 2011 at 8:59 PM, Michael Herndon < > > mhern...@wickedsoftware.net> wrote: > > > >> I can't tell if the apache git mirror is updated via scheduler or from > >> commit hooks, but its generally stays close to being on par with svn. > >> I'll > >> check next time I push something to svn. > >> > >> But both of those items have made it to the mirror. > >> > >> - michael > >> > >> > >> On Tue, Sep 6, 2011 at 1:44 PM, Digy wrote: > >> > >> > I don't know how often github mirror is updated. > >> > These are the original locations > >> > 2.9.4 https://svn.apache.org/repos/asf/incubator/lucene.net/trunk/ > >> > 2.9.4g > >> > > >> > > >> > https://svn.apache.org/repos/asf/incubator/lucene.net/branches/Lucene.Net_2_ > >> > 9_4g/ > >> > > >> > Both versions include ThreadLocal fix + Signing. > >> > > >> > Thanks, > >> > DIGY > >> > > >> > > >> > > >> > -Original Message- > >> > From: itamar.synhers...@gmail.com [mailto:itamar.synhers...@gmail.com > ] > >> On > >> > Behalf Of Itamar Syn-Hershko > >> > Sent: Tuesday, September 06, 2011 2:34 AM > >> > To: lucene-net-dev@lucene.apache.org > >> > Subject: Re: [Lucene.Net] 2.9.4 > >> > > >> > Not a problem, we will test RavenDB on a separate branch, also for > >> > potential > >> > memory leaks > >> > > >> > Digy, can you make sure the github mirror contains an updated 2.9.4 > tag > >> I > >> > can pull from, which includes the latest ThreadLocal fix + the > strongly > >> > signed patch applied to it? > >> > > >> > 2011/9/6 Digy > >> > > >> > > To avoid misunderstanding... > >> > > > >> > > Community==all Lucene.Net users > >> > > > >> > > DIGY > >> > > > >> > > -Original Message- > >> > > From: Digy [mailto:digyd...@gmail.com] > >> > > Sent: Monday, September 05, 2011 11:46 PM > >> > > To: 'lucene-net-dev@lucene.apache.org' > >> > > Subject: RE: [Lucene.Net] 2.9.4 > >> > > > >> > > Not bad idea, but I would prefer community's feedback instead of > >> testing > >> > > against all projects using Lucene.Net > >> > > DIGY > >> > > > >> > > -Original Message- > >> > > From: Matt Warren [mailto:mattd...@gmail.com] > >> > > Sent: Monday, September 05, 2011 11:09 PM > >> > > To: lucene-net-dev@lucene.apache.org > >> > > Subject: Re: [Lucene.Net] 2.9.4 > >> > > > >> > > If you want to test it against a large project you could take a look > >> at > >> > how > >> > > RavenDB uses it? > >> > > > >> > > At the moment it's using 2.9.2 ( > >> > > > >> > > > >> > > >> > > >> > https://github.com/ayende/ravendb/tree/master/SharedLibs/Sources/Lucene2.9.2 > >> > > ) > >> > > but if you were to recompile it against 2.9.4 and check that all > it's > >> > > unit-tests still run that would give you quite a large test case. > >> > > > >> > > On 5 September 2011 19:22, Prescott Nasser > >> > wrote: > >> > > > >> > > > > >> > > > Hey All, > >> > > > > >> > > > How do people feel about the 2.9.4 code base? I've been using it > for > >> > > > sometime, for my use cases it's be excellent. Do we feel we are > >> ready > >> > to > >> > > > package this up and make it an official release? Or do we have > some > >> > tasks > >> > > > left to take care of? > >> > > > > >> > > > ~Prescott > >> > > > >> > > >> > > >> > > >> > > > > >
Re: A warm welcome to our newest Lucene contrib committer, Koji Sekiguchi!
Congrats Mike, Welcome aboard. DIGY On Tue, Jan 26, 2010 at 6:07 AM, George Aroush wrote: > Hi Folks, > > The Lucene PMC has voted to accept Mike Garski as a new Lucene.Net > committer. > > Please join me to congratulate and welcome Mike to Lucene.Net. He has been > an asset for Lucene.Net. > > Welcome aboard Mike! > > -- George > > > PS: Once your account creation has been confirmed, you should test it by > adding your name to the "Active Committers list here: > http://incubator.apache.org/lucene.net/ (this page need to be cleaned up > and > moved as sub-project under the main Lucene page, an action item for me > which > I hope to start soon). > >
Re: Compiler warnings to worry about?
I'd prefer "single issue with three patches". DIGY On Fri, Feb 19, 2010 at 3:00 PM, Andy Pook wrote: > Subscribed > > 1- Ah, hadn't spotted ISerializable. However, the recommendation for > combining ISerializable and sealed classes is to use private instead > of protected. ( > http://msdn.microsoft.com/en-us/library/ms182343(VS.80).aspx > - "For a sealed class, make the constructor private; otherwise, make > it protected.") > > Should I create a separate issue for each or a single issue with three > patches? > > --Andy > > From"Digy" > Subject RE: Compiler warnings to worry about? > DateThu, 18 Feb 2010 17:06:39 GMT > Hi Andy, > > 1- No we can not remove the protected constructors. They are used in > serialization process via reflection. See the issue > http://issues.apache.org/jira/browse/LUCENENET-338 . > > 2- You are correct in general, but no danger in this case > (SupportClass.ThreadClass) > > 3- Yes, we should add the override/new keyword. > > Your patch is welcome. > > PS: Please subscribe to mailing list to send mails. Otherwise I'll have to > do a allow/deny confirmation (as a moderator) with every mail you send and > it can get lost among spams. > > DIGY > > > > > On 18 February 2010 10:35, Andy Pook wrote: > > > > We get a lot of compiler warnings. This has been discussed before and the > result seemed to be that it would be a lot of effort and would make it > difficult to maintain across versions as we have previously always used the > automated process. And as most of them are just to do with xml comments it's > never been much to worry about. > > However, we do have some warnings that I think we should worry about. > > I normally compile using msbuild from the command line. This makes it > easier for me to ignore most of the warnings and just see the interesting > stuff. > > msbuild > -p:NoWarn="0168,0169,0414,0612,0618,0649,1572,1573,1574,1580,1587,1591" > > Other options are added for the Release build. > > Here are the warnings. (Forgive the line breaks, I just cut/pasted from > cmd). > > "C:\projects\lucene.net\trunk\src\Lucene.Net\Lucene.Net.sln" (default > target) (1) -> > > "C:\projects\lucene.net\trunk\src\Lucene.Net\Lucene.Net.csproj" (default > target) (2) -> > > (CoreCompile target) -> > > Index\Term.cs(174,19): warning CS0628: > 'Lucene.Net.Index.Term.Term(System.Run > > time.Serialization.SerializationInfo, > System.Runtime.Serialization.StreamingCon > > text)': new protected member declared in sealed class > > Search\NumericRangeQuery.cs(389,19): warning CS0628: > 'Lucene.Net.Search.Numer > > > icRangeQuery.NumericRangeQuery(System.Runtime.Serialization.SerializationInfo, > > System.Runtime.Serialization.StreamingContext)': new protected member > declared > > in sealed class > > SupportClass.cs(132,18): warning CS0659: 'SupportClass.ThreadClass' > overrides > > Object.Equals(object o) but does not override Object.GetHashCode() > > SupportClass.cs(132,18): warning CS0661: 'SupportClass.ThreadClass' > defines o > > perator == or operator != but does not override Object.GetHashCode() > > Analysis\CharArraySet.cs(449,29): warning CS0114: > 'Lucene.Net.Analysis.CharAr > > raySet.Clear()' hides inherited member > 'System.Collections.Hashtable.Clear()'. > > To make the current member override that implementation, add the override > keywo > > rd. Otherwise add the new keyword. > > Analysis\CharArraySet.cs(418,16): warning CS0114: > 'Lucene.Net.Analysis.CharAr > > raySet.UnmodifiableCharArraySet.AddAll(System.Collections.ICollection)' > hides i > > nherited member > 'Lucene.Net.Analysis.CharArraySet.AddAll(System.Collections.ICo > > llection)'. To make the current member override that implementation, add > the ov > > erride keyword. Otherwise add the new keyword. > > QueryParser\QueryParser.cs(1421,4): warning CS0162: Unreachable code > detected > > QueryParser\QueryParser.cs(1469,4): warning CS0162: Unreachable code > detected > > QueryParser\QueryParser.cs(1482,4): warning CS0162: Unreachable code > detected > > QueryParser\QueryParser.cs(1542,4): warning CS0162: Unreachable code > detected > > QueryParser\QueryParser.cs(1633,4): warning CS0162: Unreachable code > detected > > QueryParser\QueryParser.cs(1984,4): warning CS0162: Unreachable code > detected > > Search\Filter.cs(42,7): warning CS1570: XML comment on > 'Lucene.Net.Search.Fil > >
Re: Are custom tokenizers not invoked when a wildcard is detected
Please see the issue https://issues.apache.org/jira/browse/LUCENENET-51 > Hoss Man commented on LUCENENET-51: > this is known behavior in the Java library due to the fact that there is no > "clean" way to let an analyzer process a prefix (or fuzzy or wildcard) query > ... it is covered in the FAQ... > http://wiki.apache.org/lucene-java/LuceneFAQ#head-133cf44dd3dff3680c96c1316a663e881eeac35a > "Are Wildcard, Prefix, and Fuzzy queries case sensitive?" DIGY On Tue, Jun 15, 2010 at 12:11 AM, Arne Claassen wrote: > I created a tokenizer that replaces '-', whitespace and "_" all with '_'. > > Now if i query on that field with "foo-", the parser turns it into "foo_", > but if i parse "foo-*" it stays "foo-*" and my tokenizer is never invoked. > Am I not implementing something in my tokenizer, is this intentionial or is > it a bug? > > thanks, > Arne Claassen > > MindTouch > San Diego, CA > http://twitter.com/sdether > >
Re: Range queries
just string comparison: '2' < 'N' '*' < '2' DIGY On Wed, Jun 30, 2010 at 1:04 PM, Ayende Rahien wrote: > I am seeing something strange with range queries: > > This works: > Created:[20100730100201790 TO NULL] > This returns no results: > Created:[20100730100201790 TO *] > > This return no results: > Created:[NULL TO 20100730100201790] > This works: > Created:[* TO 20100730100201790] > > Am I missing something? >
RE: Lucene.NET Community Status
Hi Grant, George and all Lucene.Net community, As a Lucene.Net committer, I didn't quit the project, but stopped deliberately answering the questions and making commits to show no other committers were willing to keep the project alive.(like Apache Board Report. The only response from commiters was after Grant's mail.) So, If there are people willing to keep Lucene.Net alive, I am in, but I don't want to be the only one. DIGY -Original Message- From: Grant Ingersoll [mailto:gsing...@apache.org] Sent: Friday, October 29, 2010 11:48 PM To: lucene-net-u...@lucene.apache.org Cc: Lucene mailing list; lucene-net-dev@lucene.apache.org Subject: Lucene.NET Community Status FYI: This message was sent to the lucene-net-...@lucene.a.o list on Oct. 25 and elicited zero replies. I am sending it here in the hopes that some of you will step forward and either bring this project back to life via going back to the Incubator or we put it in the Apache Attic and someone can take and maintain it somewhere else under a different name per the terms of the Apache License. --- Hi .Netters, The Lucene PMC would like to ask everyone involved with .NET if they might chime in on the status of this project. There hasn't been a commit since July 2010 (and that one was trivial and there were only 2 in June) and there seems to be very little activity on the dev mailing list. There also has not been a release in a long time. This was brought up at the last Lucene Board Report and it doesn't appear that there has been any action since. A community should be able to withstand the loss of a single committer, but here it appears that there are no longer any committers willing to work on the project. In order to remedy the situation, we would like the following things to be done: 1. The community needs to show some (sustained) life. Not just in code, but in discussion of the project's future, etc. We would expect the committers to take a leadership role here. 2. The community needs to do a real release that is voted on by the PMC. 3. The webpage needs to be updated to reflect that those previous "source" releases are not real releases and should be taken down. Likewise, the news section should not tout these non-releases as releases. The website should also meet the PMC Branding guidelines recently sent out. 4. Identify some new blood for contributors/committers. Or the current committers need to step up more and take a lead role in the community. We would like to see action on all of these things by the end of this year. If they can't be met, there will be one of the following actions: 1. Go back into Incubation 2. Go into the Apache Attic. If someone wants to take the code base and fork it out as a project somewhere else under a new name that does not use the Lucene trademark name (since that is owned by the ASF) than that is perfectly acceptable under the Apache license. If the conditions can be met, we think that the project should spin itself out as its own Top Level ASF project with its own PMC so that its future direction can be set by the stakeholders of the project and not by the larger Lucene project as a whole. Sincerely, Grant Ingersoll On behalf of the Lucene PMC=
RE: need some help =)
1. You don't have a field named "contents" in the index. (It is "text") use
"text" field to search.
2. Use "file_text" string while indexing ( not encoding.GetBytes(file_text) )
3. You should index the "text" field as ANALYZED.
4. You have to read some manuals before starting to code.
DIGY
-Original Message-
From: asmcad [mailto:asm...@gmail.com]
Sent: Wednesday, November 17, 2010 10:02 PM
To: lucene-net-dev
Subject: need some help =)
it's a simple index and search application but i couldn't make it work.
it doesn't give any error but it doesn't give any results too.
1.
using System;
2.
using System.Collections.Generic;
3.
using System.ComponentModel;
4.
using System.Data;
5.
using System.Drawing;
6.
using System.Linq;
7.
using System.Text;
8.
using System.Windows.Forms;
9.
using Lucene.Net;
10.
using Lucene.Net.Analysis.Standard;
11.
using Lucene.Net.Documents;
12.
using Lucene.Net.Index;
13.
using Lucene.Net.QueryParsers;
14.
using Lucene.Net.Search;
15.
using System.IO;
16.
17.
namespace newLucene
18.
{
19.
public partial class Form1 : Form
20.
{
21.
public Form1()
22.
{
23.
InitializeComponent();
24.
}
25.
26.
private void buttonIndex_Click(object sender, EventArgs e)
27.
{
28.
IndexWriter indexwrtr = new
IndexWriter(@"c:\index\",new StandardAnalyzer() , true);
29.
Document doc = new Document();
30.
string filename = @"fer.txt";
31.
Lucene.Net.QueryParsers.QueryParser df;
32.
33.
34.
35.
System.IO.StreamReader local_StreamReader = new
System.IO.StreamReader(@"C:\z\fer.txt");
36.
string file_text = local_StreamReader.ReadToEnd();
37.
38.
System.Text.UTF8Encoding encoding = new System.Text.UTF8Encoding();
39.
doc.Add(new
Field("text",encoding.GetBytes(file_text),Field.Store.YES));
40.
doc.Add(new
Field("path",encoding.GetBytes(@"C:\z\"),Field.Store.YES));
41.
doc.Add(new Field("title",
encoding.GetBytes(filename), Field.Store.YES));
42.
indexwrtr.AddDocument(doc);
43.
44.
indexwrtr.Optimize();
45.
indexwrtr.Close();
46.
47.
}
48.
49.
private void buttonSearch_Click(object sender, EventArgs e)
50.
{
51.
IndexSearcher indxsearcher = new
IndexSearcher(@"C:\index\");
52.
53.
QueryParser parser = new QueryParser("contents", new
StandardAnalyzer());
54.
Query query = parser.Parse(textBoxQuery.Text);
55.
56.
//Lucene.Net.QueryParsers.QueryParser qp = new
QueryParser(Lucene.Net.QueryParsers.CharStream
s).Parse(textBoxQuery.Text);
57.
Hits hits = indxsearcher.Search(query);
58.
59.
60.
for (int i = 0; i < hits.Length(); i++)
61.
{
62.
63.
Document doc = hits.Doc(i);
64.
65.
66.
string filename = doc.Get("title");
67.
string path = doc.Get("path");
68.
string folder = Path.GetDirectoryName(path);
69.
70.
71.
ListViewItem item = new ListViewItem(new string[]
{ null, filename, "asd", hits.Score(i).ToString() });
72.
item.Tag = path;
73.
74.
this.listViewResults.Items.Add(item);
75.
Application.DoEvents();
76.
}
77.
78.
indxsearcher.Close();
79.
80.
81.
82.
83.
}
84.
}
85.
}
thanks
RE: need some help =)
Try to see what you are indexing
http://mail-archives.apache.org/mod_mbox/lucene-lucene-net-user/201011.mbox/%3caanlktim6kyuzhwb8p7g=hvqx6dy1fkarchro0hyw+...@mail.gmail.com%3e
And you can also think of use of ASCIIFoldingFilter if it fits to your needs.
DIGY
-Original Message-
From: asmcad [mailto:asm...@gmail.com]
Sent: Wednesday, November 17, 2010 11:06 PM
To: lucene-net-dev@lucene.apache.org
Subject: Re: need some help =)
i solved the problem . now i have non-english character problem.
when i search like something "çşğuı"(i'm not sure you can see this)
characters. i don't get any results.
how can i solve this ?
by the way sorry about the "content" messing =)
thanks for the previous help =)
On 17.11.2010 20:16, Digy wrote:
>
> 1.
>using System;
> 2.
>using System.Collections.Generic;
> 3.
>using System.ComponentModel;
> 4.
>using System.Data;
> 5.
>using System.Drawing;
> 6.
>using System.Linq;
> 7.
>using System.Text;
> 8.
>using System.Windows.Forms;
> 9.
>using Lucene.Net;
>10.
>using Lucene.Net.Analysis.Standard;
>11.
>using Lucene.Net.Documents;
>12.
>using Lucene.Net.Index;
>13.
>using Lucene.Net.QueryParsers;
>14.
>using Lucene.Net.Search;
>15.
>using System.IO;
>16.
>17.
>namespace newLucene
>18.
>{
>19.
>public partial class Form1 : Form
>20.
>{
>21.
>public Form1()
>22.
>{
>23.
> InitializeComponent();
>24.
>}
>25.
>26.
>private void buttonIndex_Click(object sender, EventArgs e)
>27.
>{
>28.
> IndexWriter indexwrtr = new
>IndexWriter(@"c:\index\",new StandardAnalyzer() , true);
>29.
> Document doc = new Document();
>30.
>string filename = @"fer.txt";
>31.
> Lucene.Net.QueryParsers.QueryParser df;
>32.
>33.
>34.
>35.
>System.IO.StreamReader local_StreamReader = new
>System.IO.StreamReader(@"C:\z\fer.txt");
>36.
>string file_text = local_StreamReader.ReadToEnd();
>37.
>38.
>System.Text.UTF8Encoding encoding = new System.Text.UTF8Encoding();
>39.
> doc.Add(new
>Field("text",encoding.GetBytes(file_text),Field.Store.YES));
>40.
> doc.Add(new
>Field("path",encoding.GetBytes(@"C:\z\"),Field.Store.YES));
>41.
> doc.Add(new Field("title",
>encoding.GetBytes(filename), Field.Store.YES));
>42.
> indexwrtr.AddDocument(doc);
>43.
>44.
> indexwrtr.Optimize();
>45.
> indexwrtr.Close();
>46.
>47.
>}
>48.
>49.
>private void buttonSearch_Click(object sender, EventArgs e)
>50.
>{
>51.
> IndexSearcher indxsearcher = new
>IndexSearcher(@"C:\index\");
>52.
>53.
> QueryParser parser = new QueryParser("contents", new
>StandardAnalyzer());
>54.
> Query query = parser.Parse(textBoxQuery.Text);
>55.
>56.
>//Lucene.Net.QueryParsers.QueryParser qp = new
>QueryParser(Lucene.Net.QueryParsers.CharStream
>s).Parse(textBoxQuery.Text);
>57.
> Hits hits = indxsearcher.Search(query);
>58.
>59.
>60.
>for (int i = 0; i< hits.Length(); i++)
>61.
>{
>62.
>63.
> Document doc = hits.Doc(i);
>64.
>65.
>66.
>string filename = doc.Get("title");
>67.
>string path = doc.Get("path");
>68.
>string folder = Path.GetDirectoryName(path);
>69.
>70.
>71.
> ListViewItem item = new ListViewItem(new string[]
>{ null, filename, "asd", hits.Score(i).ToString() });
>72.
> item.Tag = path;
>73.
>74.
>this.listViewResults.Items.Add(item);
>75.
> Application.DoEvents();
>76.
>}
>77.
>78.
> indxsearcher.Close();
>79.
>80.
>81.
>82.
>83.
>}
>84.
>}
>85.
>}
>
>
> thanks
>
RE: Newbie
See the parameters of IndexWriter ("create").
If you already have an index containing docs it must be set to "false".
DIGY
-Original Message-
From: Wade Girard [mailto:wade.gir...@gmail.com]
Sent: Saturday, November 27, 2010 10:30 PM
To: lucene-net-dev@lucene.apache.org
Subject: Newbie
I am new to lucene. I purchased the Lucene in Action book and have been
using it as a guide for integrating lucene into my web site (www.
tikiwade.com).
I am having a problem where the exiting index is having all of its data
removed when I open the index and add new documents to it.
Basically I can successfully create the index at any time. But after I have
closed the index, when another process opens it up and tries to add 1 or
more documents to the index, the documents that were in the index are
removed, leaving just the newly indexed documents.
I can provide code if that would help to understand what I am doing.
Any guidance is appreciated.
Thanks
Wade Girard
wade.gir...@gmail.com
RE: [jira] Commented: (LUCENENET-379) Clean up Lucene.Net website
I got bored with being the only committer who tries to answers the user's questions and making commits to keep the project alive. So, I continue (for now) to answer some question on mailing lists but stopped committing months ago. DIGY. -Original Message- From: Prescott Nasser [mailto:geobmx...@hotmail.com] Sent: Tuesday, November 30, 2010 5:51 PM To: lucene-net-dev@lucene.apache.org Subject: RE: [jira] Commented: (LUCENENET-379) Clean up Lucene.Net website indeed. Learning as I go. > From: neal.granr...@thermofisher.com > To: lucene-net-dev@lucene.apache.org > Date: Tue, 30 Nov 2010 08:32:53 -0700 > Subject: RE: [jira] Commented: (LUCENENET-379) Clean up Lucene.Net website > > As I understand it, only the official Lucene.NET "committers" (DIGY, George Aroush, and Doug Sale) can commit alterations to the web site or the source. > > - Neal > > -Original Message- > From: Prescott Nasser (JIRA) [mailto:j...@apache.org] > Sent: Thursday, November 25, 2010 12:04 PM > To: lucene-net-dev@lucene.apache.org > Subject: [jira] Commented: (LUCENENET-379) Clean up Lucene.Net website > > > [ https://issues.apache.org/jira/browse/LUCENENET-379?page=com.atlassian.jira. plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12935819#acti on_12935819 ] > > Prescott Nasser commented on LUCENENET-379: > --- > > Can anyone commit those files in the zip to the https://svn.apache.org/repos/asf/lucene/lucene.net/site/asfcms? Or how can I get commit access to the location? > > Joe is ready to set up us asf cms space, but we need those files added. Also - if I can't commit, is there a contact I can use to get updates posted? or do I need to always upload files here and then wait for someone to add them? > > > Clean up Lucene.Net website > > --- > > > > Key: LUCENENET-379 > > URL: https://issues.apache.org/jira/browse/LUCENENET-379 > > Project: Lucene.Net > > Issue Type: Task > > Reporter: George Aroush > > Attachments: Lucene.zip > > > > > > The existing Lucene.Net home page at http://lucene.apache.org/lucene.net/ is still based on the incubation, out of date design. This JIRA task is to bring it up to date with other ASF project's web page. > > The existing website is here: https://svn.apache.org/repos/asf/lucene/lucene.net/site/ > > See http://www.apache.org/dev/project-site.html to get started. > > It would be best to start by cloning an existing ASF project's website and adopting it for Lucene.Net. Some examples, https://svn.apache.org/repos/asf/lucene/pylucene/site/ and https://svn.apache.org/repos/asf/lucene/java/site/ > > -- > This message is automatically generated by JIRA. > - > You can reply to this email to add a comment to the issue online. >
RE: Proposal Stage: Backwards Compatibility / Support
> The 3.0.X ports should be 100% Sharpen Why? What about other alternatives? Lucene.java 3.0.3 ==> .Net Conversion Samples ( http://people.apache.org/~digy/Lucene.Net.3.0.3.zip ) DIGY -Original Message- From: Troy Howard [mailto:thowar...@gmail.com] Sent: Saturday, January 01, 2011 1:58 AM To: lucene-net-dev@lucene.apache.org Subject: Re: Proposal Stage: Backwards Compatibility / Support We are inheriting the outstanding issues facing the Lucene.Net project. This includes remaining committed to providing a line-by-line port that stays in sync with the Java Lucene releases. The project is currently extremely behind schedule on this. The 2.9.2 code base, which is widely used and thus a fairly well received build, has never been formally packaged as a release (i.e. binary builds, etc). This is the first order of business to take care of (in terms of code). After that we need to evaluate weather or not to create releases to match all subsequent releases made by the Java Lucene project. Those releases are: - 3.0.0 - 3.0.1 - 2.9.3 - 3.0.2 - 2.9.4 - 3.0.3 In the interest of time, we could skip some of the intermediate releases and just get in sync at 2.9.4 and 3.0.3 releases. The 3.0.X ports should be 100% Sharpen conversions and post-processing scripts. Once written, anyone should be able to repeat the process of pulling down the appropriate Java Lucene SVN revision, executing the porting scripts, and building the resulting .NET code, yield a valid 3.0.X release with a 1:1 matching API. This is something we will need to continue being able to do for every subsequent Java Lucene release. This aspect of our development should be completely separate from our refactoring/re-imagining of a more .NET-like API. They need to be separate development branches, and possibly even completely different implementations. We will attempt to reuse as much of the automated port code as we can, with the understanding that the goal of the secondary branch is to make a high-quality .NET implementation of Lucene, rather than a API compatible implementation. Thanks, Troy On Fri, Dec 31, 2010 at 3:29 PM, Alex Thompson wrote: > Maybe we could just bug-fix support the current 2.9.2 codebase unless people > really need something in 2.9.x > > I think there would be a 3.0.x line-by-line port and a 3.0.x idiomatic > version. > > I'd like to throw another idea into the mix which is perhaps the idiomatic > version could be created by an automated refactoring of the line-by-line. It > might be additional upfront work but might make it easier for future changes > from java lucene to be propagated down. > > Alex > > -Original Message- > From: mhern...@amptools.net [mailto:mhern...@amptools.net] On Behalf Of > Michael Herndon > Sent: Friday, December 31, 2010 1:28 PM > To: lucene-net-dev@lucene.apache.org > Subject: Proposal Stage: Backwards Compatibility / Support > > *Backwards Compatibility / Support: * > This is definitely something we need to cover. > > I'm guessing the obvious choice would be to continue the 2.9.X versions > under sharpen, maintain the current api thats has java idioms so that people > can continue to use it, release patches, ensure stability with the current > community. This would be important for people who have built products on top > of lucene.net. > > The 3.0 version should probably match java in terms of breaking the api due > to the language changes or maybe even a separate project inside: > lucene.netredux (for lack of a better term at the moment). > > > * > * > -- > Michael Herndon > >
RE: [jira] Commented: (LUCENENET-380) Evaluate Sharpen as a port tool
Hi Peter, Most of them existed also in previous ports. This is why we have a huge SupportClass.cs If you compare the source with Lucene.Net 2.9.2, you can see how it was solved previously. DIGY -Original Message- From: Peter Mateja [mailto:peter.mat...@gmail.com] Sent: Friday, January 07, 2011 7:53 PM To: lucene-net-dev@lucene.apache.org Subject: Re: [jira] Commented: (LUCENENET-380) Evaluate Sharpen as a port tool Nice work Alex! Not that this represents a solution, but I did load up the core source from your conversion into a VS2010 project, then ran Resharper's code cleanup on it. This process took care of all the unused 'using Java.*' references, cleanup up formatting, etc. However, I'm still seeing a good many things that need work: 1) ICloseable -> IDisposable, including refactoring of the implementation from Close() to Dispose() (and also considering any additional refactoring of the Disposable pattern.) 2) IFieldCache is marked as an interface, but has tons of static fields, subclasses and interfaces. This may be ok in Java, but not in C#. Not sure what the best course of action here might be... perhaps create an abstract base class called FieldCache or FieldCacheBase to house this stuff, and pull out the nested classes / interfaces into their own files. 3) Use of a generic WeakReference<>, which doesn't exist in generic form in the .Net Framework. This is something which could either be refactored or implemented as generic. 4) ICloneable interface not implemented (see IndexInput.cs) 5) Unsigned bitwise shift assignment operator doesn't exist in C#. See IndexOutput.cs, WriteVInt() method. The line i >>>= 7; in java flags an error in C#. I'm not entirely sure in this case, but I believe this can safely be converted to: i >>= 7; in this case, especially given the comment that negative numbers are not supported. 6) Use of Java DecimalFormat class. An appropriate .Net replacement should be easily substituted with some refactoring of the code. 7) Use of Runtime.IdentityHashCode(). Not sure how necessary this is. 8) Java specific value type parsing calls should be refactored to .Net (e.g. double.ParseDouble() => double.Parse()) 9) Use of the java ReadResolve() object serialization pattern needs to be analyzed / refactored (see FieldCache.DefaultByteParser (or in the translated version, IFieldCache._IByteParser)). 10) Use of Sharpen references. 11) Use of Java's NumberFormatException... should be refactored to use an appropriate standard exception type (perhaps FormatException, though I'm not sure this is appropriate) or create an internal Exception class for this case. There's plenty more build issues... I need to put this down for the rest of the day, so I thought I'd at least get this out to the list. Peter Mateja peter.mat...@gmail.com On Fri, Jan 7, 2011 at 9:34 AM, Neal Granroth (JIRA) wrote: > >[ > https://issues.apache.org/jira/browse/LUCENENET-380?page=com.atlassian.jira. plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12978816#acti on_12978816] > > Neal Granroth commented on LUCENENET-380: > - > > Thanks Alex, > > What would be the plan for handling the Sharpen artifacts that prevent the > converted code from being built by the .NET SDK compiler? > > Do you envision a post-conversion script to strip out statements like: > using Java.Lang > using Java.IO > > and replace Sharpen-specific classes with standard .NET classes: > Sharpen.Collections.* > Sharpen.Runtime.* > > > > > Evaluate Sharpen as a port tool > > --- > > > > Key: LUCENENET-380 > > URL: https://issues.apache.org/jira/browse/LUCENENET-380 > > Project: Lucene.Net > > Issue Type: Task > >Reporter: George Aroush > > Attachments: 3.0.2_JavaToCSharpConverter_AfterPostProcessing.zip, > 3.0.2_JavaToCSharpConverter_NoPostProcessing.zip, IndexWriter.java, > Lucene.Net.3_0_3_Sharpen20110106.zip, Lucene.Net.Sharpen20101104.zip, > Lucene.Net.Sharpen20101114.zip, NIOFSDirectory.java, QueryParser.java, > TestBufferedIndexInput.java, TestDateFilter.java > > > > > > This task is to evaluate Sharpen as a port tool for Lucene.Net. > > The files to be evaluated are attached. We need to run those files > (which are off Java Lucene 2.9.2) against Sharpen and compare the result > against JLCA result. > > -- > This message is automatically generated by JIRA. > - > You can reply to this email to add a comment to the issue online. > >
RE: Proposal Status, Initial Committors List, Contributors List
Thanks Troy, It is very good. DIGY -Original Message- From: Troy Howard [mailto:thowar...@gmail.com] Sent: Thursday, January 06, 2011 7:47 PM To: lucene-net-dev@lucene.apache.org Subject: Proposal Status, Initial Committors List, Contributors List All, Thanks for all the recent activity in the mailing lists. I'm really eager to get this project moving forward and the discussions going on now are exactly what we need to do that. Calling attention back to the Incubator proposal, the outstanding needs for completing that proposal are: - Build Initial Committers list - Ensure that Committers have all submitted a CLA - Ensure that the proposal is inline with community interest The current draft of the proposal is located at: http://wiki.apache.org/incubator/Lucene.Net%20Proposal For each of those goals: Build Initial Committers List --- I have updated the proposal to reflect the current state of the Initial Committers list. The list, at present is (alphabetical): - Chris Currens - DIGY - Michael Herndon - Prescott Nasser - Scott Lombard - Sergey Mirvoda - Troy Howard The only other person who has been discussed as a Committer, but hasn't stated formally that they are interested in that role is Heath Aldrich (there was some discussion, but no resolution). So, Heath, if you'd like to be on the Initial Committers list, please send a quick message indicating your interest. Additionally, the following people have come forward as willing Contributors (alphabetical): - Alex Thompson - Ben Martz - Frank Yu - Glyn Darkin - Peter Mateja - Shashi Kant - Simone Chiaretta - Wyatt Barnett Ensure that Committers Have All Submitted a CLA --- For those of you on the Initial Committers list, we will need to submit CLAs for each developer before being granted commit access. Currently the only person on that list who has submitted a CLA is DIGY. I'll be sending mine in today, and I encourage the rest of you to do so by the end of the week. Information about the CLA, and how to submit is located here: http://www.apache.org/licenses/#clas Ensure That the Proposal Is Inline With Community Interest -- So far, I have not heard any feedback from the community about the text of the Incubator Proposal. Please review the current draft, and if you have any reservations about the contents or language, feel that anything is missing or should be omitted, please post to the mailing list expressing your concerns or ideas. I will be submitting the proposal on Tuesday, January 11th, so please review it and discuss prior to that. I want to make sure that everyone who is effected by our proposal has had the opportunity to review it, and either determine that they completely agree with it or give them the opportunity to discuss their opinions openly prior to submission. Again, the current draft of the proposal is located at: http://wiki.apache.org/incubator/Lucene.Net%20Proposal And, even though I sign most of my emails 'Thanks', I'd like to take a second and express my sincere appreciation for the community we have around this project and the effort and investments that have been given and will continue to be given in the future by our contributors. The project could not survive without it. Thanks, Troy
RE: Proposal Status, Initial Committors List, Contributors List
I think there are some misunderstandings about how to contribute to Lucene.Net. Everyone is free to grab to source code, work on it and post the bugs/improvements/new features. They are always welcomed. DIGY -Original Message- From: srikalyan swayampakula [mailto:srikalyansswa...@hotmail.com] Sent: Saturday, January 08, 2011 11:13 PM To: lucene-net-dev@lucene.apache.org Subject: RE: Proposal Status, Initial Committors List, Contributors List Hi Everyone, I would like to be a contributor for this project. Is there any chance to be one as I believe you have already decided on the list of people. Thanks, ~Sri. > From: digyd...@gmail.com > To: lucene-net-dev@lucene.apache.org > Subject: RE: Proposal Status, Initial Committors List, Contributors List > Date: Sat, 8 Jan 2011 16:18:36 +0200 > > Thanks Troy, > > It is very good. > > DIGY > > -Original Message- > From: Troy Howard [mailto:thowar...@gmail.com] > Sent: Thursday, January 06, 2011 7:47 PM > To: lucene-net-dev@lucene.apache.org > Subject: Proposal Status, Initial Committors List, Contributors List > > All, > > Thanks for all the recent activity in the mailing lists. I'm really > eager to get this project moving forward and the discussions going on > now are exactly what we need to do that. > > Calling attention back to the Incubator proposal, the outstanding > needs for completing that proposal are: > - Build Initial Committers list > - Ensure that Committers have all submitted a CLA > - Ensure that the proposal is inline with community interest > > The current draft of the proposal is located at: > > http://wiki.apache.org/incubator/Lucene.Net%20Proposal > > > For each of those goals: > > Build Initial Committers List > --- > > I have updated the proposal to reflect the current state of the > Initial Committers list. The list, at present is (alphabetical): > > - Chris Currens > - DIGY > - Michael Herndon > - Prescott Nasser > - Scott Lombard > - Sergey Mirvoda > - Troy Howard > > The only other person who has been discussed as a Committer, but > hasn't stated formally that they are interested in that role is Heath > Aldrich (there was some discussion, but no resolution). So, Heath, if > you'd like to be on the Initial Committers list, please send a quick > message indicating your interest. > > Additionally, the following people have come forward as willing > Contributors (alphabetical): > > - Alex Thompson > - Ben Martz > - Frank Yu > - Glyn Darkin > - Peter Mateja > - Shashi Kant > - Simone Chiaretta > - Wyatt Barnett > > > Ensure that Committers Have All Submitted a CLA > --- > > For those of you on the Initial Committers list, we will need to > submit CLAs for each developer before being granted commit access. > Currently the only person on that list who has submitted a CLA is > DIGY. I'll be sending mine in today, and I encourage the rest of you > to do so by the end of the week. > > Information about the CLA, and how to submit is located here: > > http://www.apache.org/licenses/#clas > > > > Ensure That the Proposal Is Inline With Community Interest > -- > > > So far, I have not heard any feedback from the community about the > text of the Incubator Proposal. Please review the current draft, and > if you have any reservations about the contents or language, feel that > anything is missing or should be omitted, please post to the mailing > list expressing your concerns or ideas. > > I will be submitting the proposal on Tuesday, January 11th, so please > review it and discuss prior to that. I want to make sure that everyone > who is effected by our proposal has had the opportunity to review it, > and either determine that they completely agree with it or give them > the opportunity to discuss their opinions openly prior to submission. > > Again, the current draft of the proposal is located at: > > http://wiki.apache.org/incubator/Lucene.Net%20Proposal > > > And, even though I sign most of my emails 'Thanks', I'd like to take a > second and express my sincere appreciation for the community we have > around this project and the effort and investments that have been > given and will continue to be given in the future by our contributors. > The project could not survive without it. > > Thanks, > Troy >
RE: [jira] Commented: (LUCENENET-380) Evaluate Sharpen as a port tool
Having a "buildable" & "clean" code is just a beginning and should not
result in lost of know-hows.
Before trying to fix the bugs of the output of these tools, everyone should
see how they were fixed in Lucene.Net 2.9.2.
There is no need to reinvent the wheel.
Here is a quick list of tips & tricks as far as I can remember.
* Decimal separator is not always ".", some locales use "," (while parsing
float/double).
* "Set" in Java accepts "null" as argument. A null-control is needed while
porting.
* ReadResolve should be ported by implementing the interface
"System.Runtime.Serialization.IObjectReference"
public Object
GetRealObject(System.Runtime.Serialization.StreamingContext context)
{
return ReadResolve();
}
* .NET emits "\ufffd" as invalid char but java as "\x00"
* Use StringComparer.Ordinal while comparing strings.
* FIPS compliance. use SHA1 instead of MD5
* Use "System.Runtime.Serialization.OnDeserialized" attribute on
Serializable classes.
void OnDeserialized(System.Runtime.Serialization.StreamingContext
context)
{
-
}
* Use "System.IO.Path.DirectorySeparatorChar" or "Path.Combine" instead of
using "\\". (causes problems on Mono)
* Iteration problems. "if (i.MoveNext()){...}" can not be used (in a while
loop) to detect the end of the list.
* Port of TreeSet. TreeSet in Java sorts its contents based on the default
Comparator of the items, but the ArrayList does not.
* Unexpected results when writing custom analyzers. Override
Read,ReadBlock,ReadLine,Peek,ReadToEnd in ReusableStringReader.
* Multi-dimensional arrays: "length" in java returns the number of
dimensions. In c# "Length" returns the total number of elements in all
dimensions.
* Copy private fields in the class' "Clone" method.
* Don't forget: base-36-encoding is used in filenames.
* Use "if (dataLen <=0 )" instead of "if (dataLen == -1)" to detect end of
stream.
* Case insensivity. Don't use public names such as "text" and "Text" in a
single class (problem for VB users).
* Use ThreadClass in SupportClass.cs instead of System.Threading.Thread
* Use "System.Text.Encoding.UTF8" instead of "System.Text.Encoding.ASCII"
* ">>>" is already implemented in SupportClass.
* Threshold differences between .NET & Java while comparing floats/doubles.
Use also these classes:
* There is a good implementation of WeakHashTable in SupportClass. (needs
"Generics")
* There is a very fast LRU cache impl. (SimpleLRUCache). (needs "Generics")
PS: This not a complete list and there may be many others from other
contributers of Lucene.Net
DIGY
-Original Message-
From: Peter Mateja [mailto:peter.mat...@gmail.com]
Sent: Friday, January 07, 2011 7:53 PM
To: lucene-net-dev@lucene.apache.org
Subject: Re: [jira] Commented: (LUCENENET-380) Evaluate Sharpen as a port
tool
Nice work Alex!
Not that this represents a solution, but I did load up the core source from
your conversion into a VS2010 project, then ran Resharper's code cleanup on
it.
This process took care of all the unused 'using Java.*' references, cleanup
up formatting, etc. However, I'm still seeing a good many things that need
work:
1) ICloseable -> IDisposable, including refactoring of the implementation
from Close() to Dispose() (and also considering any additional refactoring
of the Disposable pattern.)
2) IFieldCache is marked as an interface, but has tons of static fields,
subclasses and interfaces. This may be ok in Java, but not in C#. Not sure
what the best course of action here might be... perhaps create an abstract
base class called FieldCache or FieldCacheBase to house this stuff, and pull
out the nested classes / interfaces into their own files.
3) Use of a generic WeakReference<>, which doesn't exist in generic form in
the .Net Framework. This is something which could either be refactored or
implemented as generic.
4) ICloneable interface not implemented (see IndexInput.cs)
5) Unsigned bitwise shift assignment operator doesn't exist in C#. See
IndexOutput.cs, WriteVInt() method. The line i >>>= 7; in java flags an
error in C#. I'm not entirely sure in this case, but I believe this can
safely be converted to: i >>= 7; in this case, especially given the comment
that negative numbers are not supported.
6) Use of Java DecimalFormat class. An appropriate .Net replacement should
be easily substituted with some refactoring of the code.
7) Use of Runtime.IdentityHashCode(). Not sure how necessary this is.
8) Java specific value type parsing calls should be refactored to .Net (e.g.
double.ParseDouble() => double.Parse())
9) Use of the java
RE: Stefan's Newbie Questions (was Re: Proposal Status, Initial Committors List, Contributors List)
I think we should discuss it later not to hijack this thread.. DIGY -Original Message- From: Hans Merkl [mailto:h...@hmerkl.com] Sent: Wednesday, January 26, 2011 11:29 PM To: lucene-net-dev@lucene.apache.org Subject: Re: Stefan's Newbie Questions (was Re: Proposal Status, Initial Committors List, Contributors List) I use it in my desktop app and it works great. My app gets distributed and with TIKA I know what I get on the customer machine. With IFilter you never know... On Wed, Jan 26, 2011 at 15:55, Digy wrote: > Although TIKA is a very good project, I've never needed it in windows > environment. Using Ifilter interface solves most(if not all) of the > problems > related with converting a document to text. > > DIGY > > >
RE: Icubator Infra: svn and Committers
I copied Lucene.Net to the new location (https://svn.apache.org/repos/asf/incubator/lucene.net/) and changed some links in the index.html page. DIGY -Original Message- From: Stefan Bodewig [mailto:bode...@apache.org] Sent: Sunday, February 06, 2011 9:55 AM To: lucene-net-dev@lucene.apache.org Subject: Re: Icubator Infra: svn and Committers Hi all, the vote is closed and has passed now, so I've started to kick off the infrastructure tasks (more tomorrow, need to have a Family Sunday now 8-). DIGY, you should have write access to the incubator svn area now. I've created an empty status template at the incubator site which should become visible in a few hours. Cheers Stefan
RE: Arabic Analyzer
By Hand. Find-Replace is your best friend :) DIGY -Original Message- From: Prescott Nasser [mailto:geobmx...@hotmail.com] Sent: Monday, February 07, 2011 12:02 AM To: lucene-net-dev@lucene.apache.org Subject: RE: Arabic Analyzer Hey Digy, Do you use sharpen (or some other conversion tool) or for such minimal amounts of code, do you just port it by hand? ~Prescott > From: digyd...@gmail.com > To: lucene-net-dev@lucene.apache.org > Subject: RE: Arabic Analyzer > Date: Sun, 6 Feb 2011 23:58:01 +0200 > > Here is a port of lucene.java's arabic analyzer ( > https://issues.apache.org/jira/browse/LUCENENET-392 ) > > You can safely remove nunit dependency and test cases from the project. > > DIGY > > -Original Message- > From: Ben Foster [mailto:b...@planetcloud.co.uk] > Sent: Sunday, February 06, 2011 5:47 PM > To: lucene-net-dev@lucene.apache.org > Subject: Re: Arabic Analyzer > > Is it still possible to use fixed term queries in Arabic (i.e. NOT using an > Analyzer)? > > Thanks > Ben > > On 6 February 2011 00:51, Prescott Nasser wrote: > > > > > Unfortunately, I don't think we have that. We're working on creating a new > > port of the java lucene code, but I don't know the timeline yet - I'm sure > > there will be a lot of chatter on this mailing list soon. > > > > ~Prescott > > > > > > > > > > > > > > > Date: Sat, 5 Feb 2011 22:57:11 + > > > Subject: Arabic Analyzer > > > From: b...@planetcloud.co.uk > > > To: lucene-net-dev@lucene.apache.org > > > > > > Is there an Arabic Analyzer available for Lucene.NET. I see there has > > been > > > one contributed to the Java project but wasn't sure if this has been > > ported. > > > > > > Thanks, > > > > > > Ben > > > > > > -- > > Ben Foster > > planetcloud > The Elms, Hawton > Newark-on-Trent > Nottinghamshire > NG24 3RL > > www.planetcloud.co.uk > =
RE: Arabic Analyzer
Although it is a minimal code it took about 2 hours to port these (6+3) classes and then test. DIGY -Original Message- From: Prescott Nasser [mailto:geobmx...@hotmail.com] Sent: Monday, February 07, 2011 12:02 AM To: lucene-net-dev@lucene.apache.org Subject: RE: Arabic Analyzer Hey Digy, Do you use sharpen (or some other conversion tool) or for such minimal amounts of code, do you just port it by hand? ~Prescott > From: digyd...@gmail.com > To: lucene-net-dev@lucene.apache.org > Subject: RE: Arabic Analyzer > Date: Sun, 6 Feb 2011 23:58:01 +0200 > > Here is a port of lucene.java's arabic analyzer ( > https://issues.apache.org/jira/browse/LUCENENET-392 ) > > You can safely remove nunit dependency and test cases from the project. > > DIGY > > -Original Message- > From: Ben Foster [mailto:b...@planetcloud.co.uk] > Sent: Sunday, February 06, 2011 5:47 PM > To: lucene-net-dev@lucene.apache.org > Subject: Re: Arabic Analyzer > > Is it still possible to use fixed term queries in Arabic (i.e. NOT using an > Analyzer)? > > Thanks > Ben > > On 6 February 2011 00:51, Prescott Nasser wrote: > > > > > Unfortunately, I don't think we have that. We're working on creating a new > > port of the java lucene code, but I don't know the timeline yet - I'm sure > > there will be a lot of chatter on this mailing list soon. > > > > ~Prescott > > > > > > > > > > > > > > > Date: Sat, 5 Feb 2011 22:57:11 + > > > Subject: Arabic Analyzer > > > From: b...@planetcloud.co.uk > > > To: lucene-net-dev@lucene.apache.org > > > > > > Is there an Arabic Analyzer available for Lucene.NET. I see there has > > been > > > one contributed to the Java project but wasn't sure if this has been > > ported. > > > > > > Thanks, > > > > > > Ben > > > > > > -- > > Ben Foster > > planetcloud > The Elms, Hawton > Newark-on-Trent > Nottinghamshire > NG24 3RL > > www.planetcloud.co.uk > =
RE: Umlauts as Char
Hi Prescott,
1- When I open the java file, I see the code as it should be. You can try to
open it with notepad and then paste to VS for ex.
2- There is an open issue reported by Pasha Bizhan that covers some
languages (https://issues.apache.org/jira/browse/LUCENENET-372)
But I don't know it us up to date or not.
3- ASCIIFoldingFilter.cs is another example for dealing with non-ascii
chars.
DIGY
-Original Message-
From: Prescott Nasser [mailto:geobmx...@hotmail.com]
Sent: Tuesday, February 08, 2011 3:55 AM
To: lucene-net-dev@lucene.apache.org
Subject: Umlauts as Char
Hey all,
So while digging into the code a bit (and pushed by digy's Arabic conversion
yesterday). I started looking at the various other languages we were missing
from java.
I started porting the GermanAnalyzer, but ran into an issue of the
Umlauts...
http://svn.apache.org/viewvc/lucene/java/tags/lucene_2_9_4/contrib/analyzers
/common/src/java/org/apache/lucene/analysis/de/GermanStemmer.java?revision=1
040993&view=co
in the void subsitute function you'll see them:
else if ( buffer.charAt( c ) == 'ü' ) {
buffer.setCharAt( c, 'u' );
}
This does not constitue a character in .net (that I can figure out) and thus
it doesn't compile. The .java file says encoded in UTF-8. I was thinking
maybe I could do the same thing in VS2010, but I'm not finding a way, and
searching on this has been difficult.
Any ideas?
~Prescott =
RE: Umlauts as Char
One more thing, don't open
https://svn.apache.org/repos/asf/lucene/java/tags/lucene_2_9_2/contrib/analy
zers/common/src/java/org/apache/lucene/analysis/de/GermanStemmer.java using
browser. just checkout from svn and then open it.
DIGY
-Original Message-
From: Prescott Nasser [mailto:geobmx...@hotmail.com]
Sent: Tuesday, February 08, 2011 11:16 AM
To: lucene-net-dev@lucene.apache.org
Subject: RE: Umlauts as Char
Well - with regards to number 2. It was fine to dig into the code a bit -
but I guess we have them a number of them already converted, although I
guess never added source control.
Thanks for the heads up on 1 and 3.
~P
> From: digyd...@gmail.com
> To: lucene-net-dev@lucene.apache.org
> Subject: RE: Umlauts as Char
> Date: Tue, 8 Feb 2011 11:12:33 +0200
>
> Hi Prescott,
>
> 1- When I open the java file, I see the code as it should be. You can try
to
> open it with notepad and then paste to VS for ex.
> 2- There is an open issue reported by Pasha Bizhan that covers some
> languages (https://issues.apache.org/jira/browse/LUCENENET-372)
> But I don't know it us up to date or not.
> 3- ASCIIFoldingFilter.cs is another example for dealing with non-ascii
> chars.
>
> DIGY
>
> -Original Message-
> From: Prescott Nasser [mailto:geobmx...@hotmail.com]
> Sent: Tuesday, February 08, 2011 3:55 AM
> To: lucene-net-dev@lucene.apache.org
> Subject: Umlauts as Char
>
>
>
> Hey all,
>
> So while digging into the code a bit (and pushed by digy's Arabic
conversion
> yesterday). I started looking at the various other languages we were
missing
> from java.
>
> I started porting the GermanAnalyzer, but ran into an issue of the
> Umlauts...
>
>
http://svn.apache.org/viewvc/lucene/java/tags/lucene_2_9_4/contrib/analyzers
>
/common/src/java/org/apache/lucene/analysis/de/GermanStemmer.java?revision=1
> 040993&view=co
>
> in the void subsitute function you'll see them:
>
> else if ( buffer.charAt( c ) == 'ü' ) {
> buffer.setCharAt( c, 'u' );
> }
>
> This does not constitue a character in .net (that I can figure out) and
thus
> it doesn't compile. The .java file says encoded in UTF-8. I was thinking
> maybe I could do the same thing in VS2010, but I'm not finding a way, and
> searching on this has been difficult.
>
> Any ideas?
>
> ~Prescott =
> =
RE: Umlauts as Char
Altough Java doesn't write BOM, VS is clever enough to open it correctly.
The problem probably is that Apache server sends the java code using
"Content-Type: text/plain; charset=ISO-8859-1" and the receiver (possibly a
browser) incorrectly tries to convert UTF-8 to ISO-8859-1.
Using a svn client to download the code is a solution.
DIGY
-Original Message-
From: Stefan Bodewig [mailto:bode...@apache.org]
Sent: Tuesday, February 08, 2011 7:10 AM
To: lucene-net-dev@lucene.apache.org
Subject: Re: Umlauts as Char
On 2011-02-08, Prescott Nasser wrote:
> in the void subsitute function you'll see them:
> else if ( buffer.charAt( c ) == 'ü' ) {
> buffer.setCharAt( c, 'u' );
> }
> This does not constitue a character in .net (that I can figure out)
> and thus it doesn't compile. The .java file says encoded in UTF-8. I
> was thinking maybe I could do the same thing in VS2010, but I'm not
> finding a way, and searching on this has been difficult.
IIRC VS will recognize UTF-8 encoded files if they start with a byte
order mark (BOM) but Java usually doesn't write one. I think I once
found the setting for reading/writing UTF-8 in VS, will need to search
for it when at work.
If you have a JDK installed you can use its native2ascii tool that can
be used to replace non-ASCII characters with Unicoce escape sequences
that you can then use in C# as well (see Nicolas' post).
If you have Ant installed (sorry, can't resist ;-) you can convert the
whole tree in one (untested) go with something like
Stefan
RE: Incubator Infra: mailing lists
On moderation: I don't think we had a specific policy. I have usually allowed mails as long as it is related with Lucene.Net(and in English of course) DIGY -Original Message- From: Stefan Bodewig [mailto:bode...@apache.org] Sent: Thursday, February 10, 2011 11:49 AM To: lucene-net-dev@lucene.apache.org Subject: Re: Incubator Infra: mailing lists Hi, lists should now be there (if they haven't been already) and be moderated by Digy and myself. I'll ask infra to add Prescott as moderator once he has his account ready. On moderation: what has been the policy for moderating in posts by non-subscribers so far? I know projects that will never allow anybody to post who is not subscribed and others where posts by people using a service like Nabble will get moderated through. Stefan
RE: [jira] Commented: (LUCENENET-392) Arabic Analyzer
Hi Stefan, I don't see it as a "request for permission". It is rather to inform people about the change who may have different ideas and give a chance to comment on it if this change breaks something in their own local copy. DIGY -Original Message- From: Stefan Bodewig [mailto:bode...@apache.org] Sent: Thursday, February 10, 2011 12:10 PM To: lucene-net-dev@lucene.apache.org Subject: Re: [jira] Commented: (LUCENENET-392) Arabic Analyzer On 2011-02-08, Digy (JIRA) wrote: > Digy commented on LUCENENET-392: > > If no objections, I am going to commit it in a few days. Generally in a healthy project it is way easier to ask for forgiveness than for permission[1]. It is all under version control so things can be changed and even removed again easily when anything goes wrong. I hope anybody who'd be interested is subscribed to the commits list and will see the changes and can comment on them later. Cheers Stefan [1] A lesson I had to learn myself <http://marc.info/?l=ant-dev&m=86951893306302&w=2>
RE: [jira] Commented: (LUCENENET-392) Arabic Analyzer
They all contain Apache License 1.1 and compatible with v1.4.3( for ex, they don't implement ReusableTokenStream of Analyzer class) There may be also other fixes in v2.9. I think they can wait till a complete review. DIGY -Original Message- From: Prescott Nasser [mailto:geobmx...@hotmail.com] Sent: Thursday, February 10, 2011 11:22 PM To: lucene-net-dev@lucene.apache.org Subject: RE: [jira] Commented: (LUCENENET-392) Arabic Analyzer Would it make sense to also commit the analyzers that Prasha converted and submitted here: https://issues.apache.org/jira/browse/LUCENENET-372 ~P > From: digyd...@gmail.com > To: lucene-net-dev@lucene.apache.org > Subject: RE: [jira] Commented: (LUCENENET-392) Arabic Analyzer > Date: Thu, 10 Feb 2011 12:33:37 +0200 > > Hi Stefan, > > I don't see it as a "request for permission". It is rather to inform people > about the change who may have different ideas and give a chance to comment > on it if this change breaks something in their own local copy. > > DIGY > > > > > > -Original Message- > From: Stefan Bodewig [mailto:bode...@apache.org] > Sent: Thursday, February 10, 2011 12:10 PM > To: lucene-net-dev@lucene.apache.org > Subject: Re: [jira] Commented: (LUCENENET-392) Arabic Analyzer > > On 2011-02-08, Digy (JIRA) wrote: > > > Digy commented on LUCENENET-392: > > > > > If no objections, I am going to commit it in a few days. > > Generally in a healthy project it is way easier to ask for forgiveness > than for permission[1]. It is all under version control so things can > be changed and even removed again easily when anything goes wrong. > > I hope anybody who'd be interested is subscribed to the commits list and > will see the changes and can comment on them later. > > Cheers > > Stefan > > [1] A lesson I had to learn myself > <http://marc.info/?l=ant-dev&m=86951893306302&w=2> > =
RE: Old website redirects?
I changed the content of index.html at /www/lucene.apache.org/lucene.net as below. It will be active in a few hours. http://incubator.apache.org/lucene.net/";> DIGY -Original Message- From: Stefan Bodewig [mailto:bode...@apache.org] Sent: Saturday, February 12, 2011 9:13 AM To: lucene-net-dev@lucene.apache.org Subject: Old website redirects? Hi, when I visit <http://lucene.apache.org/lucene.net/> I still get to see the "old" Lucene.NET page. Wouldn't it be better if it redirected to the Incubator site? A simple .htacess file at lucene.apache.org with something like RedirectPermanent /lucene.net http://incubator.apache.org/lucene.net would probably do. Stefan
RE: Can I remove access of Lucene.NET committers to Lucene infrastructure now?
Read-only access is enough. DIGY -Original Message- From: Stefan Bodewig [mailto:bode...@apache.org] Sent: Sunday, February 13, 2011 9:04 AM To: lucene-net-dev@lucene.apache.org Subject: Can I remove access of Lucene.NET committers to Lucene infrastructure now? Hi, as far as I can tell Digy has moved over everything that was in svn or on the site. Is there still anything left that you need access to or can I modify permission so that the Lucene.NET committers no longer have write access to it? Stefan
RE: [jira] Commented: (LUCENENET-392) Arabic Analyzer
It is configured as "Embedded Resource" in project file. No need to load explicitly. DIGY -Original Message- From: Ben Foster [mailto:b...@planetcloud.co.uk] Sent: Monday, February 14, 2011 5:51 PM To: lucene-net-dev@lucene.apache.org Subject: RE: [jira] Commented: (LUCENENET-392) Arabic Analyzer Quick question - do I need to explicitly load the ArabicStopWords text file or can these be embedded into the assembly? Thanks, Ben -Original Message----- From: Digy [mailto:digyd...@gmail.com] Sent: 10 February 2011 21:41 To: lucene-net-dev@lucene.apache.org Subject: RE: [jira] Commented: (LUCENENET-392) Arabic Analyzer They all contain Apache License 1.1 and compatible with v1.4.3( for ex, they don't implement ReusableTokenStream of Analyzer class) There may be also other fixes in v2.9. I think they can wait till a complete review. DIGY -Original Message- From: Prescott Nasser [mailto:geobmx...@hotmail.com] Sent: Thursday, February 10, 2011 11:22 PM To: lucene-net-dev@lucene.apache.org Subject: RE: [jira] Commented: (LUCENENET-392) Arabic Analyzer Would it make sense to also commit the analyzers that Prasha converted and submitted here: https://issues.apache.org/jira/browse/LUCENENET-372 ~P > From: digyd...@gmail.com > To: lucene-net-dev@lucene.apache.org > Subject: RE: [jira] Commented: (LUCENENET-392) Arabic Analyzer > Date: Thu, 10 Feb 2011 12:33:37 +0200 > > Hi Stefan, > > I don't see it as a "request for permission". It is rather to inform people > about the change who may have different ideas and give a chance to comment > on it if this change breaks something in their own local copy. > > DIGY > > > > > > -Original Message- > From: Stefan Bodewig [mailto:bode...@apache.org] > Sent: Thursday, February 10, 2011 12:10 PM > To: lucene-net-dev@lucene.apache.org > Subject: Re: [jira] Commented: (LUCENENET-392) Arabic Analyzer > > On 2011-02-08, Digy (JIRA) wrote: > > > Digy commented on LUCENENET-392: > > > > > If no objections, I am going to commit it in a few days. > > Generally in a healthy project it is way easier to ask for forgiveness > than for permission[1]. It is all under version control so things can > be changed and even removed again easily when anything goes wrong. > > I hope anybody who'd be interested is subscribed to the commits list and > will see the changes and can comment on them later. > > Cheers > > Stefan > > [1] A lesson I had to learn myself > <http://marc.info/?l=ant-dev&m=86951893306302&w=2> > =
RE: [jira] Commented: (LUCENENET-392) Arabic Analyzer
AND/OR/NOT are just pseudo operators and they are converted finally to Lucene's default unary operators as +/blank/- (by QueryParser). a AND b ==> +a +b a OR b ==> a b etc. Hacking QueryParser can be a solution , but I would recommend to stick to unary operators which can globally be used. DIGY Either -Original Message- From: Ben Foster [mailto:b...@planetcloud.co.uk] Sent: Tuesday, February 15, 2011 12:25 AM To: lucene-net-dev@lucene.apache.org Subject: Re: [jira] Commented: (LUCENENET-392) Arabic Analyzer What needs to be done to support localized query parser constants? For example, in English I can do a search for "Running AND Trainers NOT Nike" How can I localize the constants for AND / NOT / OR etc.? Thanks, Ben On 14 February 2011 17:06, Ben Foster wrote: > I should have used the other zip. That's working fine. > > Thanks > > -Original Message- > From: Ben Foster [mailto:b...@planetcloud.co.uk] > Sent: 14 February 2011 16:57 > To: lucene-net-dev@lucene.apache.org > Subject: RE: [jira] Commented: (LUCENENET-392) Arabic Analyzer > > I'm using the one from the Lucene.Net.Analyzers zip. > > When I debug I get Could not find file 'C:\Program Files (x86)\Common > Files\Microsoft Shared\DevServer\10.0\ArabicStopWords.txt'. > > This was even after changing the text file to be an embedded resource. > > -Original Message- > From: Digy [mailto:digyd...@gmail.com] > Sent: 14 February 2011 16:40 > To: lucene-net-dev@lucene.apache.org > Subject: RE: [jira] Commented: (LUCENENET-392) Arabic Analyzer > > It is configured as "Embedded Resource" in project file. No need to load > explicitly. > DIGY > > > -Original Message- > From: Ben Foster [mailto:b...@planetcloud.co.uk] > Sent: Monday, February 14, 2011 5:51 PM > To: lucene-net-dev@lucene.apache.org > Subject: RE: [jira] Commented: (LUCENENET-392) Arabic Analyzer > > Quick question - do I need to explicitly load the ArabicStopWords text file > or can these be embedded into the assembly? > > Thanks, > Ben > > -Original Message- > From: Digy [mailto:digyd...@gmail.com] > Sent: 10 February 2011 21:41 > To: lucene-net-dev@lucene.apache.org > Subject: RE: [jira] Commented: (LUCENENET-392) Arabic Analyzer > > They all contain Apache License 1.1 and compatible with v1.4.3( for ex, > they > don't implement ReusableTokenStream of Analyzer class) There may be also > other fixes in v2.9. I think they can wait till a complete review. > > > DIGY > > > > > -Original Message- > From: Prescott Nasser [mailto:geobmx...@hotmail.com] > Sent: Thursday, February 10, 2011 11:22 PM > To: lucene-net-dev@lucene.apache.org > Subject: RE: [jira] Commented: (LUCENENET-392) Arabic Analyzer > > > > Would it make sense to also commit the analyzers that Prasha converted and > submitted here: > > https://issues.apache.org/jira/browse/LUCENENET-372 > > > ~P > > > > From: digyd...@gmail.com > > To: lucene-net-dev@lucene.apache.org > > Subject: RE: [jira] Commented: (LUCENENET-392) Arabic Analyzer > > Date: Thu, 10 Feb 2011 12:33:37 +0200 > > > > Hi Stefan, > > > > I don't see it as a "request for permission". It is rather to inform > people > > about the change who may have different ideas and give a chance to > > comment on it if this change breaks something in their own local copy. > > > > DIGY > > > > > > > > > > > > -Original Message- > > From: Stefan Bodewig [mailto:bode...@apache.org] > > Sent: Thursday, February 10, 2011 12:10 PM > > To: lucene-net-dev@lucene.apache.org > > Subject: Re: [jira] Commented: (LUCENENET-392) Arabic Analyzer > > > > On 2011-02-08, Digy (JIRA) wrote: > > > > > Digy commented on LUCENENET-392: > > > > > > > > If no objections, I am going to commit it in a few days. > > > > Generally in a healthy project it is way easier to ask for forgiveness > > than for permission[1]. It is all under version control so things can > > be changed and even removed again easily when anything goes wrong. > > > > I hope anybody who'd be interested is subscribed to the commits list > > and will see the changes and can comment on them later. > > > > Cheers > > > > Stefan > > > > [1] A lesson I had to learn myself > > <http://marc.info/?l=ant-dev&m=86951893306302&w=2> > > = > > > > > -- Ben Foster planetcloud The Elms, Hawton Newark-on-Trent Nottinghamshire NG24 3RL www.planetcloud.co.uk
RE: duplicate records in index
You are adding the same doc twice. (See how you add "acttime" ) DIGY -Original Message- From: Wen Gao [mailto:samuel.gao...@gmail.com] Sent: Wednesday, February 16, 2011 11:35 AM To: lucene-net-dev@lucene.apache.org Subject: duplicate records in index Hi, I am creating an index from my database, however, the record in .cfs files contains duplicate records, e.g. "book1", 1, "susan", 1 "book1", 1,"susan",1, 03/01/2010 "book2", 2,"tom", "book2",2,"tom", 2,03/02/2010 .. I got the data from several tables, and am sure that the sql only generate one record. Also, when I debug the code, the record is only added once. So I am confused whether data replicate in idex. I define my index as following format: doc.Add(new Lucene.Net.Documents.Field( "lmname", readerreader1["lmname"].ToString(), //new System.IO.StringReader(readerreader["cname"].ToString()), Lucene.Net.Documents.Field.Store.YES, Lucene.Net.Documents.Field.Index.TOKENIZED) ); //lmid doc.Add(new Lucene.Net.Documents.Field( "lmid", readerreader1["lmid"].ToString(), Lucene.Net.Documents.Field.Store.YES, Lucene.Net.Documents.Field.Index.UN_TOKENIZED)); // nick name of user doc.Add(new Lucene.Net.Documents.Field( "nickName", readerreader1["nickName"].ToString(), Lucene.Net.Documents.Field.Store.YES, Lucene.Net.Documents.Field.Index.UN_TOKENIZED)); // uid doc.Add(new Lucene.Net.Documents.Field( "uid", readerreader1["uid"].ToString(), Lucene.Net.Documents.Field.Store.YES, Lucene.Net.Documents.Field.Index.UN_TOKENIZED)); writer.AddDocument(doc); // acttime doc.Add(new Lucene.Net.Documents.Field( "acttime", readerreader1["acttime"].ToString(), Lucene.Net.Documents.Field.Store.YES, Lucene.Net.Documents.Field.Index.UN_TOKENIZED)); writer.AddDocument(doc); // Any ideas? Thanks, Wen Gao
RE: how can I get the similarity in fuzzy query
Whether *fuzzy* or not, all queries are simple term queries at the end and Lucene does not have an info like *similarity*, just scores. DIGY -Original Message- From: Wen Gao [mailto:samuel.gao...@gmail.com] Sent: Wednesday, February 16, 2011 9:47 PM To: lucene-net-dev@lucene.apache.org Subject: Re: how can I get the similarity in fuzzy query Hi, I think my situation is just to compare the similarity of strings: I want to calculate the similarity between the typed results and the returned results using *FuzzyQuery*. I have set the minimumSimilarity of FuzzyQuery as 0.5f, what i want to do is get the "similariy" instead of "score" for every result that returns. Thanks for your time. Wen 2011/2/16 Christopher Currens > I was going to post the link that Digy posted, which suggests not to > determine a match that way. If my understanding is correct, the scores > returned for a query are relative to which documents were retrieved by the > search, in that if a document is deleted from the index, the scores will > change even though the query did not, because the number of returned > documents are different. > > If the only thing you wanted to do was to calculate how a resulting string > was to a search string, I suggest the Levenshtein Distance algorithm > http://en.wikipedia.org/wiki/Levenshtein_distance...but it doesn't seem > like > that's quite what you want to accomplish based on your question. > > Christopher > > On Wed, Feb 16, 2011 at 10:55 AM, Wen Gao wrote: > > > Hi, > > I am using FuzzyQuery to get fuzzy mathed results. I want to get the > > similarity in percent for every matched record. > > for example, if i search for "databasd", and it will return results such > as > > "database", "database1", and "database11". I want to get the similarity > in > > percent for evey record, such as 87.5%, 75%, and 62.5%. > > > > How can I do this? > > > > Any ideas? > > > > Wen Gao > > >
RE: how can I get the similarity in fuzzy query
Download the source from https://svn.apache.org/repos/asf/incubator/lucene.net/tags/Lucene.Net_2_9_2 using a svn client(like TortoiseSVN), and open the project file with VS20XX. DIGY -Original Message- From: Wen Gao [mailto:samuel.gao...@gmail.com] Sent: Wednesday, February 16, 2011 9:58 PM To: lucene-net-dev@lucene.apache.org Subject: Re: how can I get the similarity in fuzzy query OK. i get it. how can I recompile a Lucene_src on Windows? Thanks. Wen 2011/2/16 Christopher Currens > As far as i know, you'll need to calculate that manually. FuzzyQuery > searches don't return any results like that. > > On Wed, Feb 16, 2011 at 11:47 AM, Wen Gao wrote: > > > Hi, > > I think my situation is just to compare the similarity of strings: I want > > to > > calculate the similarity between the typed results and the returned > results > > using *FuzzyQuery*. I have set the minimumSimilarity of FuzzyQuery as > 0.5f, > > what i want to do is get the "similariy" instead of "score" for every > > result > > that returns. > > > > Thanks for your time. > > > > Wen > > > > 2011/2/16 Christopher Currens > > > > > I was going to post the link that Digy posted, which suggests not to > > > determine a match that way. If my understanding is correct, the scores > > > returned for a query are relative to which documents were retrieved by > > the > > > search, in that if a document is deleted from the index, the scores > will > > > change even though the query did not, because the number of returned > > > documents are different. > > > > > > If the only thing you wanted to do was to calculate how a resulting > > string > > > was to a search string, I suggest the Levenshtein Distance algorithm > > > http://en.wikipedia.org/wiki/Levenshtein_distance...but it doesn't > seem > > > like > > > that's quite what you want to accomplish based on your question. > > > > > > Christopher > > > > > > On Wed, Feb 16, 2011 at 10:55 AM, Wen Gao > > wrote: > > > > > > > Hi, > > > > I am using FuzzyQuery to get fuzzy mathed results. I want to get the > > > > similarity in percent for every matched record. > > > > for example, if i search for "databasd", and it will return results > > such > > > as > > > > "database", "database1", and "database11". I want to get the > similarity > > > in > > > > percent for evey record, such as 87.5%, 75%, and 62.5%. > > > > > > > > How can I do this? > > > > > > > > Any ideas? > > > > > > > > Wen Gao > > > > > > > > > >
RE: Incubator Infra: JIRA
Sorry, I am not admin. DIGY -Original Message- From: Stefan Bodewig [mailto:bode...@apache.org] Sent: Friday, February 18, 2011 11:46 AM To: lucene-net-dev@lucene.apache.org Subject: Re: Incubator Infra: JIRA On 2011-02-18, Troy Howard wrote: > I'm not terribly familiar with JIRA. Is it possibile that we can have > more than one person as administrator? I'm not that familiar with JIRA myself either but I know it is possible to have multiple administrators. > DIGY - As admin can you grant admin access to others? Being a "project lead" in JIRA's terms doesn't necessarily imply admin rights (I just found I was made the project lead for Gump but don't have any admin rights). I'd hope Digy is admin in which case he can modify the group membership of all associated groups/roles (including admins). Stefan
RE: Proposed Roadmap
Hi Prescott, Here is the complete list of changes needed for 2.9.3 , 2.9.4 and 2.9.5. https://issues.apache.org/jira/browse/LUCENE/fixforversion/#selectedTab=com.atlassian.jira.plugin.system.project%3Aversions-panel As Troy implied, working on diffs would be much easier that a complete port. DIGY -Original Message- From: Troy Howard [mailto:thowar...@gmail.com] Sent: Friday, February 18, 2011 11:48 AM To: lucene-net-dev@lucene.apache.org Cc: Prescott Nasser Subject: Re: Proposed Roadmap Yes. If you look at the milestone dates on those two tracks of development: Lucene.Net 2.9.2 Binary release (02/28/2011) Create Production System, 2.9.2 compatible (03/28/2011) Lucene.Net 2.9.4 Source/Binary release (03/28/2011) Create Production System, 2.9.4 compatible (04/25/2011) The porting scripts are scheduled to lag behind the manual updates by one month. It seemed that this would be the most efficient way to get caught up quickly, while still moving forward with our long term goals. Thanks, Troy On Fri, Feb 18, 2011 at 1:45 AM, Prescott Nasser wrote: > > Do you imagine us doing all the "catching up on backlog" by hand? And then > later getting the automated conversion out? > > > > >> From: thowar...@gmail.com >> Date: Fri, 18 Feb 2011 01:36:00 -0800 >> Subject: Proposed Roadmap >> To: lucene-net-dev@lucene.apache.org >> >> All, >> >> Following up on Scott's post asking about JIRA issues and our >> development road map, I've put together a more detailed idea of how >> we could divide work, schedule releases, and clean up the backlog. >> >> There will be at least four main areas of work to address in the >> upcoming months: >> - Project Maintenance >> - Catching up with the backlog >> - Working on a new porting system >> - The Future: New API and Lucene 3.X >> >> Each one of those paths will need a separate road map and plan. In >> JIRA these should probably be listed as separate components, along >> with more structural components like Lucene.Net Core, Lucene.Net >> Contrib, Luke.Net, etc... >> >> Assuming we are working on these in parallel, I've included some >> rough estimate dates for completion of each listed milestone in >> the road maps. >> >> >> Project Maintenance >> == >> >> This includes the various aspects of transition from Lucene >> subproject to Incubator Podling, as well as updating the website >> and documenation. >> >> >> Roadmap >> >> * Website and branding Update (02/28/2011) >> - LUCENENET-379 - Clean up Lucene.Net website >> * NOTE: Should probably be split into a few separate issues: >> * Update website to be Apache CMS based >> * Update website to reflect current status and information >> * New site layout >> * New logo design >> >> * Documentation Update (03/28/2011) >> - LUCENENET-382 - Create a wiki page for Lucene.Net >> * NOTE: This should probably have more detailed tasks defined >> and separately assigned / managed. This should focus on 2.9.2 >> level code, examples, etc, plus FAQ, Design, and other >> similar documentation. >> >> >> Catching up with the Backlog >> == >> >> This includes finalizing the 2.9.2 release, updating that to >> Lucene 2.9.4 compatibility and applying outstanding patches and >> bug fixes. This will put is slightly out of sync with Java Lucene >> because we'll have additional patches applied that the Java Lucene >> project does not have for our 2.9.4 release. >> >> >> Roadmap >> >> * Lucene.Net 2.9.2 Binary release (02/28/2011) >> - LUCENENET-381 - Official release of Lucene.Net 2.9.2 >> * Build from existing tag, no new changes >> >> * Lucene.Net 2.9.4 Source/Binary release (03/28/2011) >> >> *EASY STUFF* >> - LUCENENET-389 - Signing the released assembly >> - LUCENENET-377 - Upgrade solution to VS2010 >> - LUCENENET-361 - Workaround for a Mono C# compiler issue >> - LUCENENET-266 - Putting support classes in separate files and >> in a separate directory >> - LUCENENET-337 - TokenAttribute for Selectively Including Tokens >> in Length Norm >> - LUCENENET-330 - Search.Regex minimal port >> - LUCENENET-371 - Unit test for Search.Regex port >> - LUCENENET-374 - IndexReader.IsCurrent returning false >> positive in some cases >> - LUCENENET-179 - SnowballFilter speed improvment >> >> *HARDER STUFF* >> - LUCENENET-??? Rollup changes from Lucene 2.9.3/2.9.4 releases >>
RE: Incubator Infra: JIRA
Hi Sergey, I added you too. DIGY -Original Message- From: Sergey Mirvoda [mailto:ser...@mirvoda.com] Sent: Friday, February 18, 2011 6:55 PM To: lucene-net-dev@lucene.apache.org Subject: Re: Incubator Infra: JIRA Hi, DIGY My jira user name is sergey_mirvoda. https://issues.apache.org/jira/secure/ViewProfile.jspa?name=sergey_mirvoda Sergey On Fri, Feb 18, 2011 at 9:47 PM, Digy wrote: > After I got the admin rights, I added all commiters as > administrators(except Sergey, since I couldn't find his JIRA username). > DIGY > > -Original Message- > From: Troy Howard [mailto:thowar...@gmail.com] > Sent: Friday, February 18, 2011 8:20 AM > To: lucene-net-dev@lucene.apache.org > Cc: Stefan Bodewig > Subject: Re: Incubator Infra: JIRA > > I'm not terribly familiar with JIRA. Is it possibile that we can have > more than one person as administrator? > > I'd like to be able to work on the Roadmap, and start doing some > scheduling, but currently don't have enough permissions to make those > kinds of changes. > > DIGY - As admin can you grant admin access to others? > > Thanks, > Troy > > > On Thu, Feb 10, 2011 at 1:50 AM, Stefan Bodewig > wrote: > > Hi, > > > > the LUCENENET JIRA is now listed as project in incubation and Digy is > > the new administrator. No other changes, so I think this piece of > > infrastructure is done. > > > > Stefan > > > > -- --Regards, Sergey Mirvoda
RE: svn commit: r1072121 - /incubator/lucene.net/branches/vs2010/
But I would prefer do the same thing on my own local copy and create a patch for trunk. Thanks, DIGY -Original Message- From: Troy Howard [mailto:thowar...@gmail.com] Sent: Friday, February 18, 2011 11:39 PM To: lucene-net-dev@lucene.apache.org Cc: Sergey Mirvoda Subject: Re: svn commit: r1072121 - /incubator/lucene.net/branches/vs2010/ It's a common practice for developers to create a branch to work on a new feature, then merge that branch back into trunk later when the changes are complete, then delete the branch. The goal is to ensure that incremental commits, performed now against the branch instead of trunk, don't leave trunk in a incompatible, unstable or un-buildable state. Perhaps that's Prescott's intention with the new vs2010 branch? Thanks, Troy On Fri, Feb 18, 2011 at 1:31 PM, Sergey Mirvoda wrote: > +1 for only one trunk upgraded to VS2010 > > On Sat, Feb 19, 2011 at 2:27 AM, Lombard, Scott > wrote: > >> I agree with DIGY. >> >> Although why wait until after the official release? >> >> Scott >> >> >> >> -Original Message- >> From: Digy [mailto:digyd...@gmail.com] >> Sent: Friday, February 18, 2011 3:38 PM >> To: lucene-net-dev@lucene.apache.org >> Subject: RE: svn commit: r1072121 - /incubator/lucene.net/branches/vs2010/ >> >> Do we really need a VS2010 branch?. Since there isn't any release since >> v2.0 and people have to compile the source by yourselves it has been good to >> support older versions of VS. But after having an offical release, we could >> update the trunk to support VS2010. >> >> Now for each change in trunk (for v2.9.3, 2.9.4 & 2.9.5) we have to update >> another repository also. >> >> DIGY >> >> -Original Message- >> From: pnas...@apache.org [mailto:pnas...@apache.org] >> Sent: Friday, February 18, 2011 10:11 PM >> To: lucene-net-comm...@lucene.apache.org >> Subject: svn commit: r1072121 - /incubator/lucene.net/branches/vs2010/ >> >> Author: pnasser >> Date: Fri Feb 18 20:10:54 2011 >> New Revision: 1072121 >> >> URL: http://svn.apache.org/viewvc?rev=1072121&view=rev >> Log: (empty) >> >> Added: >>incubator/lucene.net/branches/vs2010/ >> - copied from r1069573, incubator/lucene.net/trunk/ >> >> >> >> This message (and any associated files) is intended only for the >> use of the individual or entity to which it is addressed and may >> contain information that is confidential, subject to copyright or >> constitutes a trade secret. If you are not the intended recipient >> you are hereby notified that any dissemination, copying or >> distribution of this message, or files associated with this message, >> is strictly prohibited. If you have received this message in error, >> please notify us immediately by replying to the message and deleting >> it from your computer. Thank you, King Industries, Inc. >> > > > > -- > --Regards, Sergey Mirvoda >
RE: svn commit: r1072121 - /incubator/lucene.net/branches/vs2010/
> Although why wait until after the official release? Just for Lucene.Net users who doesn't use VS2010 and want to use the latest version. DIGY -Original Message- From: Lombard, Scott [mailto:slomb...@kingindustries.com] Sent: Friday, February 18, 2011 11:27 PM To: lucene-net-dev@lucene.apache.org Subject: RE: svn commit: r1072121 - /incubator/lucene.net/branches/vs2010/ I agree with DIGY. Although why wait until after the official release? Scott -Original Message- From: Digy [mailto:digyd...@gmail.com] Sent: Friday, February 18, 2011 3:38 PM To: lucene-net-dev@lucene.apache.org Subject: RE: svn commit: r1072121 - /incubator/lucene.net/branches/vs2010/ Do we really need a VS2010 branch?. Since there isn't any release since v2.0 and people have to compile the source by yourselves it has been good to support older versions of VS. But after having an offical release, we could update the trunk to support VS2010. Now for each change in trunk (for v2.9.3, 2.9.4 & 2.9.5) we have to update another repository also. DIGY -Original Message- From: pnas...@apache.org [mailto:pnas...@apache.org] Sent: Friday, February 18, 2011 10:11 PM To: lucene-net-comm...@lucene.apache.org Subject: svn commit: r1072121 - /incubator/lucene.net/branches/vs2010/ Author: pnasser Date: Fri Feb 18 20:10:54 2011 New Revision: 1072121 URL: http://svn.apache.org/viewvc?rev=1072121&view=rev Log: (empty) Added: incubator/lucene.net/branches/vs2010/ - copied from r1069573, incubator/lucene.net/trunk/ This message (and any associated files) is intended only for the use of the individual or entity to which it is addressed and may contain information that is confidential, subject to copyright or constitutes a trade secret. If you are not the intended recipient you are hereby notified that any dissemination, copying or distribution of this message, or files associated with this message, is strictly prohibited. If you have received this message in error, please notify us immediately by replying to the message and deleting it from your computer. Thank you, King Industries, Inc.
RE: svn commit: r1072121 - /incubator/lucene.net/branches/vs2010/
Why not having a release targeting 2.0, 3.5 and 4.0, then updating the project to 4.0 DIGY -Original Message- From: Sergey Mirvoda [mailto:ser...@mirvoda.com] Sent: Friday, February 18, 2011 11:56 PM To: lucene-net-dev@lucene.apache.org Subject: Re: svn commit: r1072121 - /incubator/lucene.net/branches/vs2010/ Why with 2.0 and not with 4.0 targeting 2.0? On Sat, Feb 19, 2011 at 2:54 AM, Wyatt Barnett wrote: > For folks who badly need to compile it, why not just add a batch file > to build the project. It is one line: > > %windir%\Microsoft.NET\Framework\v2.0.50727\msbuild lucene.net.csproj > /t:Clean;Rebuild /p:Configuration=Release > > On Fri, Feb 18, 2011 at 4:38 PM, Troy Howard wrote: > > It's a common practice for developers to create a branch to work on a > > new feature, then merge that branch back into trunk later when the > > changes are complete, then delete the branch. > > > > The goal is to ensure that incremental commits, performed now against > > the branch instead of trunk, don't leave trunk in a incompatible, > > unstable or un-buildable state. > > > > Perhaps that's Prescott's intention with the new vs2010 branch? > > > > Thanks, > > Troy > > > > > > On Fri, Feb 18, 2011 at 1:31 PM, Sergey Mirvoda > wrote: > >> +1 for only one trunk upgraded to VS2010 > >> > >> On Sat, Feb 19, 2011 at 2:27 AM, Lombard, Scott < > slomb...@kingindustries.com > >>> wrote: > >> > >>> I agree with DIGY. > >>> > >>> Although why wait until after the official release? > >>> > >>> Scott > >>> > >>> > >>> > >>> -Original Message- > >>> From: Digy [mailto:digyd...@gmail.com] > >>> Sent: Friday, February 18, 2011 3:38 PM > >>> To: lucene-net-dev@lucene.apache.org > >>> Subject: RE: svn commit: r1072121 - /incubator/ > lucene.net/branches/vs2010/ > >>> > >>> Do we really need a VS2010 branch?. Since there isn't any release since > >>> v2.0 and people have to compile the source by yourselves it has been > good to > >>> support older versions of VS. But after having an offical release, we > could > >>> update the trunk to support VS2010. > >>> > >>> Now for each change in trunk (for v2.9.3, 2.9.4 & 2.9.5) we have to > update > >>> another repository also. > >>> > >>> DIGY > >>> > >>> -Original Message- > >>> From: pnas...@apache.org [mailto:pnas...@apache.org] > >>> Sent: Friday, February 18, 2011 10:11 PM > >>> To: lucene-net-comm...@lucene.apache.org > >>> Subject: svn commit: r1072121 - /incubator/lucene.net/branches/vs2010/ > >>> > >>> Author: pnasser > >>> Date: Fri Feb 18 20:10:54 2011 > >>> New Revision: 1072121 > >>> > >>> URL: http://svn.apache.org/viewvc?rev=1072121&view=rev > >>> Log: (empty) > >>> > >>> Added: > >>>incubator/lucene.net/branches/vs2010/ > >>> - copied from r1069573, incubator/lucene.net/trunk/ > >>> > >>> > >>> > >>> This message (and any associated files) is intended only for the > >>> use of the individual or entity to which it is addressed and may > >>> contain information that is confidential, subject to copyright or > >>> constitutes a trade secret. If you are not the intended recipient > >>> you are hereby notified that any dissemination, copying or > >>> distribution of this message, or files associated with this message, > >>> is strictly prohibited. If you have received this message in error, > >>> please notify us immediately by replying to the message and deleting > >>> it from your computer. Thank you, King Industries, Inc. > >>> > >> > >> > >> > >> -- > >> --Regards, Sergey Mirvoda > >> > > > -- --Regards, Sergey Mirvoda
RE: svn commit: r1072121 - /incubator/lucene.net/branches/vs2010/
What I meant was a binary release. DIGY. -Original Message- From: Sergey Mirvoda [mailto:ser...@mirvoda.com] Sent: Saturday, February 19, 2011 12:02 AM To: lucene-net-dev@lucene.apache.org Subject: Re: svn commit: r1072121 - /incubator/lucene.net/branches/vs2010/ 4.0 rules them all. You can release 2.0 3.5 and 4.0 versions with 4.0 multitargeting On Sat, Feb 19, 2011 at 2:59 AM, Digy wrote: > Why not having a release targeting 2.0, 3.5 and 4.0, then updating the > project to 4.0 > DIGY > > -Original Message- > From: Sergey Mirvoda [mailto:ser...@mirvoda.com] > Sent: Friday, February 18, 2011 11:56 PM > To: lucene-net-dev@lucene.apache.org > Subject: Re: svn commit: r1072121 - /incubator/lucene.net/branches/vs2010/ > > Why with 2.0 and not with 4.0 targeting 2.0? > > On Sat, Feb 19, 2011 at 2:54 AM, Wyatt Barnett > wrote: > > > For folks who badly need to compile it, why not just add a batch file > > to build the project. It is one line: > > > > %windir%\Microsoft.NET\Framework\v2.0.50727\msbuild lucene.net.csproj > > /t:Clean;Rebuild /p:Configuration=Release > > > > On Fri, Feb 18, 2011 at 4:38 PM, Troy Howard > wrote: > > > It's a common practice for developers to create a branch to work on a > > > new feature, then merge that branch back into trunk later when the > > > changes are complete, then delete the branch. > > > > > > The goal is to ensure that incremental commits, performed now against > > > the branch instead of trunk, don't leave trunk in a incompatible, > > > unstable or un-buildable state. > > > > > > Perhaps that's Prescott's intention with the new vs2010 branch? > > > > > > Thanks, > > > Troy > > > > > > > > > On Fri, Feb 18, 2011 at 1:31 PM, Sergey Mirvoda > > wrote: > > >> +1 for only one trunk upgraded to VS2010 > > >> > > >> On Sat, Feb 19, 2011 at 2:27 AM, Lombard, Scott < > > slomb...@kingindustries.com > > >>> wrote: > > >> > > >>> I agree with DIGY. > > >>> > > >>> Although why wait until after the official release? > > >>> > > >>> Scott > > >>> > > >>> > > >>> > > >>> -Original Message- > > >>> From: Digy [mailto:digyd...@gmail.com] > > >>> Sent: Friday, February 18, 2011 3:38 PM > > >>> To: lucene-net-dev@lucene.apache.org > > >>> Subject: RE: svn commit: r1072121 - /incubator/ > > lucene.net/branches/vs2010/ > > >>> > > >>> Do we really need a VS2010 branch?. Since there isn't any release > since > > >>> v2.0 and people have to compile the source by yourselves it has been > > good to > > >>> support older versions of VS. But after having an offical release, we > > could > > >>> update the trunk to support VS2010. > > >>> > > >>> Now for each change in trunk (for v2.9.3, 2.9.4 & 2.9.5) we have to > > update > > >>> another repository also. > > >>> > > >>> DIGY > > >>> > > >>> -Original Message- > > >>> From: pnas...@apache.org [mailto:pnas...@apache.org] > > >>> Sent: Friday, February 18, 2011 10:11 PM > > >>> To: lucene-net-comm...@lucene.apache.org > > >>> Subject: svn commit: r1072121 - /incubator/ > lucene.net/branches/vs2010/ > > >>> > > >>> Author: pnasser > > >>> Date: Fri Feb 18 20:10:54 2011 > > >>> New Revision: 1072121 > > >>> > > >>> URL: http://svn.apache.org/viewvc?rev=1072121&view=rev > > >>> Log: (empty) > > >>> > > >>> Added: > > >>>incubator/lucene.net/branches/vs2010/ > > >>> - copied from r1069573, incubator/lucene.net/trunk/ > > >>> > > >>> > > >>> > > >>> This message (and any associated files) is intended only for the > > >>> use of the individual or entity to which it is addressed and may > > >>> contain information that is confidential, subject to copyright or > > >>> constitutes a trade secret. If you are not the intended recipient > > >>> you are hereby notified that any dissemination, copying or > > >>> distribution of this message, or files associated with this message, > > >>> is strictly prohibited. If you have received this message in error, > > >>> please notify us immediately by replying to the message and deleting > > >>> it from your computer. Thank you, King Industries, Inc. > > >>> > > >> > > >> > > >> > > >> -- > > >> --Regards, Sergey Mirvoda > > >> > > > > > > > > > -- > --Regards, Sergey Mirvoda > > -- --Regards, Sergey Mirvoda
RE: svn commit: r1072121 - /incubator/lucene.net/branches/vs2010/
Hi Prescott, I think there is a misunderstanding about the release. In Apache way, a release is a *signed* binary release(compiled version). Lucene.Net.dll has no dependency to other binaries(unless you want to test or use compression) and they will not be included in the release. DIGY -Original Message- From: Prescott Nasser [mailto:geobmx...@hotmail.com] Sent: Saturday, February 19, 2011 1:04 AM To: lucene-net-dev@lucene.apache.org Cc: ser...@mirvoda.com Subject: RE: svn commit: r1072121 - /incubator/lucene.net/branches/vs2010/ > Perhaps that's Prescott's intention with the new vs2010 branch? Yes that's the intention. I started to look at what Wyatt did https://issues.apache.org/jira/browse/LUCENENET-377. I think feel that it works well as designed. Question: Wyatt has included the nunit.dll's I know we had a conversation before about this. But I think being able to pull down everything, open a single solution which has test, contrib, src, as well as the required dependancies would be a huge boon to getting people to work on this stuff. Every change I need to make for 2.9.2-2.9.5 requires me to touch the tests. it just makes sense from my perspective to have this all in the same solution ready to roll. Is this something people are open too having in the source control, or something I should keep to my local? Also, I don't recall the legal stuff behind including nunit. Obviously a release would just be the src rolled up and packaged. > From: thowar...@gmail.com > Date: Fri, 18 Feb 2011 13:38:47 -0800 > Subject: Re: svn commit: r1072121 - /incubator/lucene.net/branches/vs2010/ > To: lucene-net-dev@lucene.apache.org > CC: ser...@mirvoda.com > > It's a common practice for developers to create a branch to work on a > new feature, then merge that branch back into trunk later when the > changes are complete, then delete the branch. > > The goal is to ensure that incremental commits, performed now against > the branch instead of trunk, don't leave trunk in a incompatible, > unstable or un-buildable state. > > Perhaps that's Prescott's intention with the new vs2010 branch? > > Thanks, > Troy > > > On Fri, Feb 18, 2011 at 1:31 PM, Sergey Mirvoda wrote: > > +1 for only one trunk upgraded to VS2010 > > > > On Sat, Feb 19, 2011 at 2:27 AM, Lombard, Scott > >> wrote: > > > >> I agree with DIGY. > >> > >> Although why wait until after the official release? > >> > >> Scott > >> > >> > >> > >> -Original Message- > >> From: Digy [mailto:digyd...@gmail.com] > >> Sent: Friday, February 18, 2011 3:38 PM > >> To: lucene-net-dev@lucene.apache.org > >> Subject: RE: svn commit: r1072121 - /incubator/lucene.net/branches/vs2010/ > >> > >> Do we really need a VS2010 branch?. Since there isn't any release since > >> v2.0 and people have to compile the source by yourselves it has been good to > >> support older versions of VS. But after having an offical release, we could > >> update the trunk to support VS2010. > >> > >> Now for each change in trunk (for v2.9.3, 2.9.4 & 2.9.5) we have to update > >> another repository also. > >> > >> DIGY > >> > >> -Original Message- > >> From: pnas...@apache.org [mailto:pnas...@apache.org] > >> Sent: Friday, February 18, 2011 10:11 PM > >> To: lucene-net-comm...@lucene.apache.org > >> Subject: svn commit: r1072121 - /incubator/lucene.net/branches/vs2010/ > >> > >> Author: pnasser > >> Date: Fri Feb 18 20:10:54 2011 > >> New Revision: 1072121 > >> > >> URL: http://svn.apache.org/viewvc?rev=1072121&view=rev > >> Log: (empty) > >> > >> Added: > >> incubator/lucene.net/branches/vs2010/ > >> - copied from r1069573, incubator/lucene.net/trunk/ > >> > >> > >> > >> This message (and any associated files) is intended only for the > >> use of the individual or entity to which it is addressed and may > >> contain information that is confidential, subject to copyright or > >> constitutes a trade secret. If you are not the intended recipient > >> you are hereby notified that any dissemination, copying or > >> distribution of this message, or files associated with this message, > >> is strictly prohibited. If you have received this message in error, > >> please notify us immediately by replying to the message and deleting > >> it from your computer. Thank you, King Industries, Inc. > >> > > > > > > > > -- > > --Regards, Sergey Mirvoda > > =
RE: [Lucene.Net] Creating a Strong Named Assembly as part of our release
After we have two files,
one contaning public+private key(Lucene.Net.snk)
{sn -k Lucene.Net.snk}
and the other containing just public key(Lucene.Net.Public.snk)
{sn -p Lucene.Net.snk Lucene.Net.Public.snk}
we can share Lucene.Net.snk via private mailing list and put the
Lucene.Net.Public.snk to svn.
Assuming that we create two binary releases(signed + unsigned), users have many
alternatives like source-code, signed release or unsigned release and free to
choose any one of them.
I don't think that some extreme cases(like one uses the signed-release in GAC
and then wants to compile and sign with his own key and forgets to remove the
old one from GAC) should be handled by Lucene.Net.
At the end, all Lucene.Net users are developers.
DIGY
-Original Message-
From: Troy Howard [mailto:thowar...@gmail.com]
Sent: Monday, February 21, 2011 7:08 PM
To: lucene-net-dev@lucene.apache.org
Subject: [Lucene.Net] Creating a Strong Named Assembly as part of our release
All,
There was a request, in LUCENENET-389 [1], that our binary release be
signed as a Strong Named Assembly (SNA). There are many compelling
reasons to do this, however managing this as an open source project
raises some questions.
The main question is, how to manage the Strong Name Key (SNK) file?
Since this file contains the private key in the strong-naming
asymmetric encryption scheme, it is supposed to be kept privately by
the signer. In this way, a given assembly can be verified as coming
from that particular signer, because only they can make a build which
is signed using that private key. If we include that in the source
trunk, we are essentially allowing anyone to sign any assembly with
the Lucene.Net naming key.
This has many implications, not the least of which is that an end user
could change the code in a malicious manner, and recompile, signing
with our key, and create an assembly which seems like a valid build,
and specifically seems to be *endorsed* by the Apache Lucene.Net
brand.
If we keep the key private, how do we then manage it? Is there a place
to store these kinds of resources, where only the committers have
access? Is this even reasonable considering the seeming philosophical
disparity between this idea and the open source ideal?
Another option, is to provide instructions for the end user on how to
create their own SNA by building from source, using their SNK. This
allows the publisher to establish trust based on their own name,
rather than ours. Unfortunately this creates a different issue;
multiple signers. Suppose there are two publishers; both creating
products that use Lucene.Net, both creating their own differently
signed SNA of the same version of Lucene.Net. Further suppose both
products end up being installed on the same box. This would cause the
second product to not be able to be installed correctly.
So, really, the only way to create a SNA and avoid the "multiple
signers" collision scenario I described above is to use a single SNK
file and always build the assembly using that file.
So what does everyone think about this?
Do we allow our SNK to be public and then run the risks of allowing
anyone to create a DLL using our signature? or do we find a way to
manage our private key privately?
Suppose we use a private key, what happens when an end user wants to
make a local modification to the Lucene.Net source but still wants the
result to be a SNA? They would need to use their own key, but now run
into the same problem of multiple signers if they weren't careful
about changing the build number to reflect their local modifications.
Perhaps we should not attempt to release a SNA?
Thanks,
Troy
[1]: https://issues.apache.org/jira/browse/LUCENENET-389
RE: [Lucene.Net] how to update the index
http://www.google.com.tr/search?q=%22Near+Realtime+Search%22+lucene DIGY -Original Message- From: Wen Gao [mailto:samuel.gao...@gmail.com] Sent: Tuesday, February 22, 2011 11:07 PM To: lucene-net-dev@lucene.apache.org Subject: [Lucene.Net] how to update the index Hi, I am using lucene to search items, my index store all the data to be searched, since the data in the index could change due to uses' update, I should update index evertytime user update data. could anyone give me some example about how to manage the index? Wen
RE: [Lucene.Net] JIRA issues for Java Lucene changes
2.3.1->2.3.2 or 2.9.1 -> 2.9.2 transitions were done with just a single patch, for ex. DIGY -Original Message- From: Lombard, Scott [mailto:slomb...@kingindustries.com] Sent: Wednesday, February 23, 2011 11:36 PM To: lucene-net-dev@lucene.apache.org Subject: [Lucene.Net] JIRA issues for Java Lucene changes Troy, I will start adding separate JIRA issues tonight. In the past do all the Java Lucene issues translate into .Net issues? Scott On Wed, Feb 23, 2011at 2:20 PM ,Troy Howard [mailto:thowar...@gmail.com] wrote: > > Scott, > > I would say the first task would be to collect all the Java changes up > and create separate JIRA issues for each one. > > Thanks, > Troy > > > On Wed, Feb 23, 2011 at 9:16 AM, Lombard, Scott > wrote: > > I am on vacation next week. So I won't be very helpful the next couple > of days. I will be able take on some things for the 2.9.4 release. Are > we going to break down the Java Lucene changes to individual items that > need to be ported or is it going to be handled as one big task? > > > > Scott > > > > > > -Original Message- > > From: Troy Howard [mailto:thowar...@gmail.com] > > Sent: Wednesday, February 23, 2011 3:32 AM > > To: lucene-net-dev@lucene.apache.org > > Subject: [Lucene.Net] Lucene.Net Tasks due by 2/28 > > > > All, > > > > I've recently been updating JIRA a lot and that's causing a lot of > > noise on the dev list. Also, because of that noise, I fear that some > > of the more important details of those changes might be passing by > > unnoticed. > > > > Mostly, I'm trying to get the project cleaned up by the end of the > > month. The goal is that March will represent a month of building out > > our new infrastructure and creating our first new release as a team > > (2.9.4). To that end, I'd like to resolve some of the outstanding > > questions about tooling so we can get started building out solutions > > with those tools. Also, I'd like to see our new status and efforts > > announced publicly, but I'm hesitant to draw much attention to the > > project until the website is updated. > > > > Additionally, I'd like to take a moment to apologize a bit for moving > > at such a rapid pace. I realize this is not sustainable and could > > cause some people to feel alienated if they don't have the time or > > energy right this second to match that pace. I also feel a bit > > self-conscious and am concerned that I'm being a little to much 'me', > > and perhaps not enough 'we'. > > > > I have been taking a lot of liberty regarding the project direction, > > bypassing some opportunities for community discussion and voting, in > > the interests of pushing the project forward and catching up a bit of > > lost time. Once we get past this initial push, I hope that we can slow > > down a bit, and maintain a healthy forward-moving pace with plenty of > > time allotted for discussion, group decision making and voting. The > > Apache Way is the way this project will succeed and thrive, and that > > requires all of us. > > > > > > So, that said, the outstanding tasks, which we can hopefully complete > > by next Monday are: > > > > Troy Howard: > > LUCENENET-381 - Official release of Lucene.Net 2.9.2 > > > > Sergey Mirvoda: > > LUCENENET-398 - LUCENENET-391 Prepare the code for ingestion > > > > Michael Herndon: > > LUCENENET-400 - Evaluate tooling for continuous integration server > > > > Prescott Nasser: > > LUCENENET-379 - Clean up Lucene.Net website > > LUCENENET-379 / LUCENENET-403 - Improve site layout and design > > LUCENENET-379 / LUCENENET-402 - Update website to reflect current > > status and information > > LUCENENET-379 / LUCENENET-401 - Update website to be Apache CMS based > > > > Alex Thompson: > > LUCENENET-380 - Evaluate Sharpen as a port tool > > > > Does anyone feel less than confident about being able to complete > > those tasks on that schedule? Need any help? Want to change > > assignments? > > > > Anyone in the community want to get involved as a contributor on any > > of these tasks (or any of the open tasks in JIRA that are not listed > > here)? Sergey could probably use some help on Luke.Net. Prescott has a > > lot of work cut out for him on the website. Perhaps we should get the > > ball rolling on 2.9.4 task assignments for everyone else? > > > > Thanks, > > Troy > > > > > > This message (and any associated files) is intended only
RE: [Lucene.Net] JIRA issues for Java Lucene changes
In the time needed to create 10s of issues, half of the fixes could be done :) DIGY -Original Message- From: Lombard, Scott [mailto:slomb...@kingindustries.com] Sent: Wednesday, February 23, 2011 11:36 PM To: lucene-net-dev@lucene.apache.org Subject: [Lucene.Net] JIRA issues for Java Lucene changes Troy, I will start adding separate JIRA issues tonight. In the past do all the Java Lucene issues translate into .Net issues? Scott On Wed, Feb 23, 2011at 2:20 PM ,Troy Howard [mailto:thowar...@gmail.com] wrote: > > Scott, > > I would say the first task would be to collect all the Java changes up > and create separate JIRA issues for each one. > > Thanks, > Troy > > > On Wed, Feb 23, 2011 at 9:16 AM, Lombard, Scott > wrote: > > I am on vacation next week. So I won't be very helpful the next couple > of days. I will be able take on some things for the 2.9.4 release. Are > we going to break down the Java Lucene changes to individual items that > need to be ported or is it going to be handled as one big task? > > > > Scott > > > > > > -Original Message- > > From: Troy Howard [mailto:thowar...@gmail.com] > > Sent: Wednesday, February 23, 2011 3:32 AM > > To: lucene-net-dev@lucene.apache.org > > Subject: [Lucene.Net] Lucene.Net Tasks due by 2/28 > > > > All, > > > > I've recently been updating JIRA a lot and that's causing a lot of > > noise on the dev list. Also, because of that noise, I fear that some > > of the more important details of those changes might be passing by > > unnoticed. > > > > Mostly, I'm trying to get the project cleaned up by the end of the > > month. The goal is that March will represent a month of building out > > our new infrastructure and creating our first new release as a team > > (2.9.4). To that end, I'd like to resolve some of the outstanding > > questions about tooling so we can get started building out solutions > > with those tools. Also, I'd like to see our new status and efforts > > announced publicly, but I'm hesitant to draw much attention to the > > project until the website is updated. > > > > Additionally, I'd like to take a moment to apologize a bit for moving > > at such a rapid pace. I realize this is not sustainable and could > > cause some people to feel alienated if they don't have the time or > > energy right this second to match that pace. I also feel a bit > > self-conscious and am concerned that I'm being a little to much 'me', > > and perhaps not enough 'we'. > > > > I have been taking a lot of liberty regarding the project direction, > > bypassing some opportunities for community discussion and voting, in > > the interests of pushing the project forward and catching up a bit of > > lost time. Once we get past this initial push, I hope that we can slow > > down a bit, and maintain a healthy forward-moving pace with plenty of > > time allotted for discussion, group decision making and voting. The > > Apache Way is the way this project will succeed and thrive, and that > > requires all of us. > > > > > > So, that said, the outstanding tasks, which we can hopefully complete > > by next Monday are: > > > > Troy Howard: > > LUCENENET-381 - Official release of Lucene.Net 2.9.2 > > > > Sergey Mirvoda: > > LUCENENET-398 - LUCENENET-391 Prepare the code for ingestion > > > > Michael Herndon: > > LUCENENET-400 - Evaluate tooling for continuous integration server > > > > Prescott Nasser: > > LUCENENET-379 - Clean up Lucene.Net website > > LUCENENET-379 / LUCENENET-403 - Improve site layout and design > > LUCENENET-379 / LUCENENET-402 - Update website to reflect current > > status and information > > LUCENENET-379 / LUCENENET-401 - Update website to be Apache CMS based > > > > Alex Thompson: > > LUCENENET-380 - Evaluate Sharpen as a port tool > > > > Does anyone feel less than confident about being able to complete > > those tasks on that schedule? Need any help? Want to change > > assignments? > > > > Anyone in the community want to get involved as a contributor on any > > of these tasks (or any of the open tasks in JIRA that are not listed > > here)? Sergey could probably use some help on Luke.Net. Prescott has a > > lot of work cut out for him on the website. Perhaps we should get the > > ball rolling on 2.9.4 task assignments for everyone else? > > > > Thanks, > > Troy > > > > > > This message (and any associated files) is intended only for the > &g
RE: [Lucene.Net] JIRA issues for Java Lucene changes
We can take,for ex, a namespace like Lucene.Net.Util(+test cases) and create a single patch for all of the related issues. (This approach needs to work on svn history, not on issues) DIGY -Original Message- From: Lombard, Scott [mailto:slomb...@kingindustries.com] Sent: Thursday, February 24, 2011 12:14 AM To: lucene-net-dev@lucene.apache.org Subject: RE: [Lucene.Net] JIRA issues for Java Lucene changes You're probably right DIGY. I will take a look at issues and create JIRA issues where the complexity deems it appropriate. I will comment or patch otherwise. Scott > -Original Message- > From: Digy [mailto:digyd...@gmail.com] > Sent: Wednesday, February 23, 2011 5:02 PM > To: lucene-net-dev@lucene.apache.org > Subject: RE: [Lucene.Net] JIRA issues for Java Lucene changes > > In the time needed to create 10s of issues, half of the fixes could be > done > :) > DIGY > > -Original Message- > From: Lombard, Scott [mailto:slomb...@kingindustries.com] > Sent: Wednesday, February 23, 2011 11:36 PM > To: lucene-net-dev@lucene.apache.org > Subject: [Lucene.Net] JIRA issues for Java Lucene changes > > Troy, > > I will start adding separate JIRA issues tonight. In the past do all the > Java Lucene issues translate into .Net issues? > > Scott > > > > On Wed, Feb 23, 2011at 2:20 PM ,Troy Howard [mailto:thowar...@gmail.com] > wrote: > > > > Scott, > > > > I would say the first task would be to collect all the Java changes up > > and create separate JIRA issues for each one. > > > > Thanks, > > Troy > > > > > > On Wed, Feb 23, 2011 at 9:16 AM, Lombard, Scott > > wrote: > > > I am on vacation next week. So I won't be very helpful the next > couple > > of days. I will be able take on some things for the 2.9.4 release. Are > > we going to break down the Java Lucene changes to individual items that > > need to be ported or is it going to be handled as one big task? > > > > > > Scott > > > > > > > > > -Original Message- > > > From: Troy Howard [mailto:thowar...@gmail.com] > > > Sent: Wednesday, February 23, 2011 3:32 AM > > > To: lucene-net-dev@lucene.apache.org > > > Subject: [Lucene.Net] Lucene.Net Tasks due by 2/28 > > > > > > All, > > > > > > I've recently been updating JIRA a lot and that's causing a lot of > > > noise on the dev list. Also, because of that noise, I fear that some > > > of the more important details of those changes might be passing by > > > unnoticed. > > > > > > Mostly, I'm trying to get the project cleaned up by the end of the > > > month. The goal is that March will represent a month of building out > > > our new infrastructure and creating our first new release as a team > > > (2.9.4). To that end, I'd like to resolve some of the outstanding > > > questions about tooling so we can get started building out solutions > > > with those tools. Also, I'd like to see our new status and efforts > > > announced publicly, but I'm hesitant to draw much attention to the > > > project until the website is updated. > > > > > > Additionally, I'd like to take a moment to apologize a bit for moving > > > at such a rapid pace. I realize this is not sustainable and could > > > cause some people to feel alienated if they don't have the time or > > > energy right this second to match that pace. I also feel a bit > > > self-conscious and am concerned that I'm being a little to much 'me', > > > and perhaps not enough 'we'. > > > > > > I have been taking a lot of liberty regarding the project direction, > > > bypassing some opportunities for community discussion and voting, in > > > the interests of pushing the project forward and catching up a bit of > > > lost time. Once we get past this initial push, I hope that we can slow > > > down a bit, and maintain a healthy forward-moving pace with plenty of > > > time allotted for discussion, group decision making and voting. The > > > Apache Way is the way this project will succeed and thrive, and that > > > requires all of us. > > > > > > > > > So, that said, the outstanding tasks, which we can hopefully complete > > > by next Monday are: > > > > > > Troy Howard: > > > LUCENENET-381 - Official release of Lucene.Net 2.9.2 > > > > > > Sergey Mirvoda: > > > LUCENENET-398 - LUCENENET-391 Prepare the code for ingestion > > &g
RE: [Lucene.Net] JIRA issues for Java Lucene changes
Instead of looking at issues, use TortoiseSVN's compare revision utility.
Some issues seem to be complex but patches are really simple. See the fix
for 2 of 103 files below
DIGY
Index: Constants.cs
===
--- Constants.cs (revision 1049646)
+++ Constants.cs (working copy)
@@ -70,7 +70,7 @@
return s.ToString();
}
- public static readonly System.String LUCENE_MAIN_VERSION =
Ident("2.9.2");
+ public static readonly System.String LUCENE_MAIN_VERSION =
Ident("2.9.4");
public static System.String LUCENE_VERSION;
static Constants()
Index: PriorityQueue.cs
===
--- PriorityQueue.cs(revision 1049646)
+++ PriorityQueue.cs(working copy)
@@ -92,7 +92,26 @@
// We allocate 1 extra to avoid if statement in top()
heapSize = 2;
else
- heapSize = maxSize + 1;
+{
+if (maxSize == Int32.MaxValue)
+{
+// Don't wrap heapSize to -1, in this case, which
+// causes a confusing NegativeArraySizeException.
+// Note that very likely this will simply then hit
+// an OOME, but at least that's more indicative to
+// caller that this values is too big. We don't +1
+// in this case, but it's very unlikely in practice
+// one will actually insert this many objects into
+// the PQ:
+heapSize = Int32.MaxValue;
+}
+else
+{
+// NOTE: we add +1 because all access to heap is
+// 1-based not 0-based. heap[0] is unused.
+heapSize = maxSize + 1;
+}
+}
heap = new System.Object[heapSize];
this.maxSize = maxSize;
-Original Message-
From: Lombard, Scott [mailto:slomb...@kingindustries.com]
Sent: Thursday, February 24, 2011 12:14 AM
To: lucene-net-dev@lucene.apache.org
Subject: RE: [Lucene.Net] JIRA issues for Java Lucene changes
You're probably right DIGY. I will take a look at issues and create JIRA
issues where the complexity deems it appropriate. I will comment or patch
otherwise.
Scott
> -Original Message-
> From: Digy [mailto:digyd...@gmail.com]
> Sent: Wednesday, February 23, 2011 5:02 PM
> To: lucene-net-dev@lucene.apache.org
> Subject: RE: [Lucene.Net] JIRA issues for Java Lucene changes
>
> In the time needed to create 10s of issues, half of the fixes could be
> done
> :)
> DIGY
>
> -Original Message-
> From: Lombard, Scott [mailto:slomb...@kingindustries.com]
> Sent: Wednesday, February 23, 2011 11:36 PM
> To: lucene-net-dev@lucene.apache.org
> Subject: [Lucene.Net] JIRA issues for Java Lucene changes
>
> Troy,
>
> I will start adding separate JIRA issues tonight. In the past do all the
> Java Lucene issues translate into .Net issues?
>
> Scott
>
>
>
> On Wed, Feb 23, 2011at 2:20 PM ,Troy Howard [mailto:thowar...@gmail.com]
> wrote:
> >
> > Scott,
> >
> > I would say the first task would be to collect all the Java changes up
> > and create separate JIRA issues for each one.
> >
> > Thanks,
> > Troy
> >
> >
> > On Wed, Feb 23, 2011 at 9:16 AM, Lombard, Scott
> > wrote:
> > > I am on vacation next week. So I won't be very helpful the next
> couple
> > of days. I will be able take on some things for the 2.9.4 release. Are
> > we going to break down the Java Lucene changes to individual items that
> > need to be ported or is it going to be handled as one big task?
> > >
> > > Scott
> > >
> > >
> > > -Original Message-
> > > From: Troy Howard [mailto:thowar...@gmail.com]
> > > Sent: Wednesday, February 23, 2011 3:32 AM
> > > To: lucene-net-dev@lucene.apache.org
> > > Subject: [Lucene.Net] Lucene.Net Tasks due by 2/28
> > >
> > > All,
> > >
> > > I've recently been updating JIRA a lot and that's causing a lot of
> > > noise on the dev list. Also, because of that noise, I fear that some
> > > of the more important details of those changes might be passing by
> > > unnoticed.
> > >
> > > Mostly, I'm trying to get the project cleaned up by the end of the
> > &
RE: [Lucene.Net] [jira] Commented: (LUCENENET-377) Upgrade solution to VS2010
What about this source tree? RC2 build contrib core Lucene.Net Test demo "src" doesn't mean anything since other dirs contain sources as well. DIGY -Original Message- From: Troy Howard (JIRA) [mailto:j...@apache.org] Sent: Friday, February 25, 2011 9:18 PM To: lucene-net-dev@lucene.apache.org Subject: [Lucene.Net] [jira] Commented: (LUCENENET-377) Upgrade solution to VS2010 [ https://issues.apache.org/jira/browse/LUCENENET-377?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12999481#comment-12999481 ] Troy Howard commented on LUCENENET-377: --- I did another version of this for the 2.9.2-incubating-RC2 build. Have a look at: https://svn.apache.org/repos/asf/incubator/lucene.net/tags/Lucene.Net_2_9_2_RC2 I placed all .sln files, as VS2010 format, in a ~/build/ directory, and updated the Release profiles to build to a ~/bin/ and ~/doc/ directories. This makes for better releases packaging structure and consolidates all solution files to a single directory (no more hunting them down). I made my changes on that branch, but could merge them in somewhere (vs2010 branch or trunk) if we like this layout/design. We also really need to address naming and namespaces. They are all over the place. I had to update a lot of things to make it all make sense. Test.dll is really inadequate naming!! I'll say more on namespaces later, in another context... Regarding VS2010 files in general, Neal brings up an interesting problem case: MsBuild 2.0 or 3.5 pre SP1 can't build a VS2010 file (even if it's target version is set to 2.0). We either need to set our standard high for end users (require .NET 3.5 SP1 or higher, and/or Visual Studio 2010), or provide VS2008 compatible versions of the solution and project files. > Upgrade solution to VS2010 > -- > > Key: LUCENENET-377 > URL: https://issues.apache.org/jira/browse/LUCENENET-377 > Project: Lucene.Net > Issue Type: Task > Components: Lucene.Net Core >Affects Versions: Lucene.Net 2.9.2, Lucene.Net 2.9.4, Lucene.Net 3.x >Reporter: Jeffrey Cameron >Assignee: Prescott Nasser > Labels: solution > Fix For: Lucene.Net 2.9.4 > > Attachments: lucene.zip > > Original Estimate: 10m > Remaining Estimate: 10m > > VS2005 is quite out of date now and there are many new improvements in > VS2010. You can still leave the framework support at .NET 2.0 if you like. -- This message is automatically generated by JIRA. - For more information on JIRA, see: http://www.atlassian.com/software/jira
RE: [Lucene.Net] [jira] Commented: (LUCENENET-377) Upgrade solution to VS2010
If this directory structure is to be used also in trunk, I must say that that I am not comfortable with this rapid changes without any previous warnings(although I understand Troy's arguments). Now, I have to reorganize all my local works. DIGY -Original Message- From: Troy Howard [mailto:thowar...@gmail.com] Sent: Saturday, February 26, 2011 1:06 AM To: lucene-net-dev@lucene.apache.org Cc: Wyatt Barnett Subject: Re: [Lucene.Net] [jira] Commented: (LUCENENET-377) Upgrade solution to VS2010 I prefer it that way as well, but the current setup has one for each project. I guess it makes sense for the Contrib projects because the folks who developed them probably worked on them in isolation from the rest of Lucene.Net. Anyway, I'd be happy to have less files to maintain. ;) If they don't have a solid and obvious purpose, axe them. Thanks, Troy On Fri, Feb 25, 2011 at 2:59 PM, Wyatt Barnett wrote: > One thing I'm not quite following -- why does one need a solution for > every single project? Point of solution files is so one can have > multiple projects linked in realish time, so we probably need a single > solution for everything or perhaps two covering core lucene and > contrib. > > > On Fri, Feb 25, 2011 at 5:51 PM, Prescott Nasser (JIRA) > wrote: >> >>[ >> https://issues.apache.org/jira/browse/LUCENENET-377?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12999618#comment-12999618 >> ] >> >> Prescott Nasser commented on LUCENENET-377: >> --- >> >> probably should wipe out the vs2010 branch in all honesty... >> >>> Upgrade solution to VS2010 >>> -- >>> >>> Key: LUCENENET-377 >>> URL: https://issues.apache.org/jira/browse/LUCENENET-377 >>> Project: Lucene.Net >>> Issue Type: Task >>> Components: Lucene.Net Core >>>Affects Versions: Lucene.Net 2.9.2, Lucene.Net 2.9.4, Lucene.Net 3.x >>>Reporter: Jeffrey Cameron >>>Assignee: Prescott Nasser >>> Labels: solution >>> Fix For: Lucene.Net 2.9.4 >>> >>> Attachments: lucene.zip >>> >>> Original Estimate: 10m >>> Remaining Estimate: 10m >>> >>> VS2005 is quite out of date now and there are many new improvements in >>> VS2010. You can still leave the framework support at .NET 2.0 if you like. >> >> -- >> This message is automatically generated by JIRA. >> - >> For more information on JIRA, see: http://www.atlassian.com/software/jira >> >> >> >
RE: [Lucene.Net] [jira] Commented: (LUCENENET-377) Upgrade solution to VS2010
First of all, I don't want to start a flame war. What I want to say is: "This is just what made sense while building this release" might not make sense for all. (I must admit, it is better than the previous one) DIGY -Original Message- From: Troy Howard [mailto:thowar...@gmail.com] Sent: Saturday, February 26, 2011 1:58 AM To: lucene-net-dev@lucene.apache.org Subject: Re: [Lucene.Net] [jira] Commented: (LUCENENET-377) Upgrade solution to VS2010 Well, the changes are currently only on a branch. Migrating these changes into trunk can be a slower process... or we could decide to go a different way altogether. This is just what made sense while building this release. That said, change, whenever it comes, does require a certain amount of adjustment for everyone. Hopefully the changes are valuable enough that they justify the costs. Thanks, Troy On Fri, Feb 25, 2011 at 3:53 PM, Digy wrote: > If this directory structure is to be used also in trunk, I must say that that > I am not comfortable with this rapid changes without any previous > warnings(although I understand Troy's arguments). Now, I have to reorganize > all my local works. > > DIGY > > -Original Message- > From: Troy Howard [mailto:thowar...@gmail.com] > Sent: Saturday, February 26, 2011 1:06 AM > To: lucene-net-dev@lucene.apache.org > Cc: Wyatt Barnett > Subject: Re: [Lucene.Net] [jira] Commented: (LUCENENET-377) Upgrade solution > to VS2010 > > I prefer it that way as well, but the current setup has one for each > project. I guess it makes sense for the Contrib projects because the > folks who developed them probably worked on them in isolation from the > rest of Lucene.Net. > > Anyway, I'd be happy to have less files to maintain. ;) > > If they don't have a solid and obvious purpose, axe them. > > Thanks, > Troy > > On Fri, Feb 25, 2011 at 2:59 PM, Wyatt Barnett > wrote: >> One thing I'm not quite following -- why does one need a solution for >> every single project? Point of solution files is so one can have >> multiple projects linked in realish time, so we probably need a single >> solution for everything or perhaps two covering core lucene and >> contrib. >> >> >> On Fri, Feb 25, 2011 at 5:51 PM, Prescott Nasser (JIRA) >> wrote: >>> >>>[ >>> https://issues.apache.org/jira/browse/LUCENENET-377?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12999618#comment-12999618 >>> ] >>> >>> Prescott Nasser commented on LUCENENET-377: >>> --- >>> >>> probably should wipe out the vs2010 branch in all honesty... >>> >>>> Upgrade solution to VS2010 >>>> -- >>>> >>>> Key: LUCENENET-377 >>>> URL: https://issues.apache.org/jira/browse/LUCENENET-377 >>>> Project: Lucene.Net >>>> Issue Type: Task >>>> Components: Lucene.Net Core >>>>Affects Versions: Lucene.Net 2.9.2, Lucene.Net 2.9.4, Lucene.Net 3.x >>>>Reporter: Jeffrey Cameron >>>>Assignee: Prescott Nasser >>>> Labels: solution >>>> Fix For: Lucene.Net 2.9.4 >>>> >>>> Attachments: lucene.zip >>>> >>>> Original Estimate: 10m >>>> Remaining Estimate: 10m >>>> >>>> VS2005 is quite out of date now and there are many new improvements in >>>> VS2010. You can still leave the framework support at .NET 2.0 if you like. >>> >>> -- >>> This message is automatically generated by JIRA. >>> - >>> For more information on JIRA, see: http://www.atlassian.com/software/jira >>> >>> >>> >> > >
RE: [Lucene.Net] [VOTE] New website / layout looks
+1 for Layout1 DIGY -Original Message- From: Prescott Nasser [mailto:geobmx...@hotmail.com] Sent: Saturday, February 26, 2011 4:04 AM To: lucene-net-dev@lucene.apache.org Subject: [Lucene.Net] [VOTE] New website / layout looks Hey all, I've uploaded two potential new layouts / site designs: https://issues.apache.org/jira/browse/LUCENENET-403. Troy has also hosted them live in his people.apache.org account: http://people.apache.org/~thoward/Lucene.Net/site/layout1/ http://people.apache.org/~thoward/Lucene.Net/site/layout2/ Please reply and specify: Layout1 or Layout2. To you want to throw your hat in the ring, upload a zip to the JIRA above and cast your vote for that. I'm out of town for the weekend, so Vote closes Tuesday @ 12PM PST (roughly 5 days from now) Thanks, ~Prescott =
RE: [Lucene.Net] irc chanel
different time zones, non-searchable content. Definitely -1 DIGY -Original Message- From: mhern...@amptools.net [mailto:mhern...@amptools.net] On Behalf Of Michael Herndon Sent: Friday, March 04, 2011 9:00 PM To: lucene-net-dev@lucene.apache.org Subject: [Lucene.Net] irc chanel If there is not already a irc chanel in use, I'm keeping #lucene.net open on irc.freenode.net /join #lucene.net
RE: [Lucene.Net] Arithmetic Overflow
No, I don't think it is a bad design. It could be limited to some number, but what would it be? 10,100,1000,100 or 1? Besides that you have other alternatives to use while searching. DIGY. -Original Message- From: steven.h...@pattersoncompanies.com [mailto:steven.h...@pattersoncompanies.com] Sent: Monday, March 21, 2011 9:16 PM To: lucene-net-dev@lucene.apache.org Subject: RE: [Lucene.Net] Arithmetic Overflow While I understand that and thank you for taking the time to respond, my concern was that passing a perfectly valid parameter leads to an exception. So this is bad design. Regards, Steve Hoff From: "Digy" To: Date: 03/21/2011 01:53 PM Subject:RE: [Lucene.Net] Arithmetic Overflow This is an expected behaviour. You get arithmetic overflow since an array[MaxInt] is created in PriorityQueue to store the results. (Lucene doesn't know the result-count before iterating over the results). If you want to collect all results( say,not the top 10 or 100), you can use HitCollector. DIGY -Original Message- From: steven.h...@pattersoncompanies.com [mailto:steven.h...@pattersoncompanies.com] Sent: Monday, March 21, 2011 7:10 PM To: lucene-net-dev@lucene.apache.org Subject: RE: [Lucene.Net] Arithmetic Overflow I'm not sure how to report this or if this is working as intended, however using the recommended Search overload of IndexSearcher and passing Int32.MaxValue, results in an arithmetic overflow exception in PriorityQueue.Initialize(int maxSize). I tested this out on several platforms, including Windows 7 - 32, 64, Server 2003, Server 2008. Perhaps the parameter that is passed to the Search method should be updated to reflect a more realistic value? Regards, Steve Hoff NOTICE: This email transmission and any attachments that accompany it may contain information that is confidential or otherwise exempt from disclosure under applicable law and is intended solely for the use of the individual(s) to whom it was intended to be addressed. If you have received this email by mistake, or you are not the intended recipient, any disclosure, dissemination, distribution, copying or other use or retention of this communication or its substance is prohibited. If you have received this communication in error, please immediately report to the author via email that you received this message by mistake and also permanently destroy printed copies and delete the original and all copies of this email and any attachments from your computer. NOTICE: This email transmission and any attachments that accompany it may contain information that is confidential or otherwise exempt from disclosure under applicable law and is intended solely for the use of the individual(s) to whom it was intended to be addressed. If you have received this email by mistake, or you are not the intended recipient, any disclosure, dissemination, distribution, copying or other use or retention of this communication or its substance is prohibited. If you have received this communication in error, please immediately report to the author via email that you received this message by mistake and also permanently destroy printed copies and delete the original and all copies of this email and any attachments from your computer.
RE: [Lucene.Net] new structure
LZOCompressor? Do we need it? DIGY -Original Message- From: Troy Howard [mailto:thowar...@gmail.com] Sent: Saturday, April 23, 2011 3:07 AM To: lucene-net-dev@lucene.apache.org Subject: Re: [Lucene.Net] new structure I guess by 'today' I meant 'In about 6 days'. Anyhow, I completed the commit of the new directory structure.. I did not delete the OLD directory structure, because they can live side-by-side. Also, please note that I only created vs2010 solutions and upgraded the projects to same. Please pull down the latest revision and validate these changes. If all goes well, I'll delete the old directory structure (everything under the 'C#' directory). Thanks, Troy On Sat, Apr 16, 2011 at 3:42 PM, Troy Howard wrote: > Apologize. I got a bit derailed. Will be commiting today. > On Apr 16, 2011 2:20 PM, "Prescott Nasser" wrote: > > > > > > Hey Troy any status update on the new structure? I'm hesistant to do > updates since I know you're going to be modifying it all shortly > > > > ~P > > >
RE: [Lucene.Net] new structure
Everything seems to be OK. +1 for removing old directory structure. Thanks Troy DIGY -Original Message- From: Troy Howard [mailto:thowar...@gmail.com] Sent: Saturday, April 23, 2011 3:07 AM To: lucene-net-dev@lucene.apache.org Subject: Re: [Lucene.Net] new structure I guess by 'today' I meant 'In about 6 days'. Anyhow, I completed the commit of the new directory structure.. I did not delete the OLD directory structure, because they can live side-by-side. Also, please note that I only created vs2010 solutions and upgraded the projects to same. Please pull down the latest revision and validate these changes. If all goes well, I'll delete the old directory structure (everything under the 'C#' directory). Thanks, Troy On Sat, Apr 16, 2011 at 3:42 PM, Troy Howard wrote: > Apologize. I got a bit derailed. Will be commiting today. > On Apr 16, 2011 2:20 PM, "Prescott Nasser" wrote: > > > > > > Hey Troy any status update on the new structure? I'm hesistant to do > updates since I know you're going to be modifying it all shortly > > > > ~P > > >
RE: [Lucene.Net] Lucene.NET 2.9.4g -- only usable with .NET 4.0 ?
Yes, we can use these classes after the work is finished. It will be easy since I use a wrapper in SupportClass for Set and Dictionary. DIGY -Original Message- From: Robert Jordan [mailto:robe...@gmx.net] Sent: Wednesday, April 27, 2011 7:46 PM To: lucene-net-...@incubator.apache.org Subject: Re: [Lucene.Net] Lucene.NET 2.9.4g -- only usable with .NET 4.0 ? On 27.04.2011 17:40, Amanuel Workneh wrote: >> Am I correct that your trial code changes make this version of Lucene.NET incompatible and un-buildable with any version of .NET prior to 4.0? > > As I understand it, 2.9.4g only replaces non-generic collections with > generic ones. Generics was introduced in .NET Framework 2.0. > > Oh, sorry, I took a look at the code just to make sure. It does use > SortedSet, a .NET 4 feature. It also uses HashSet, introduced in .NET > 3.5. We could get a copy of these classes from the Mono project: 4.0 collection classes: https://github.com/mono/mono/tree/master/mcs/class/System/System.Collections .Generic 3.5 collection classes: https://github.com/mono/mono/tree/master/mcs/class/System.Core/System.Collec tions.Generic They are licensed under the MIT/X11 license, which should be compatible with ASF's policy. Robert
RE: [Lucene.Net] new structure
Would you add the same stuff to 2.9.4g branch too? DIGY -Original Message- From: Michael Herndon [mailto:mhern...@wickedsoftware.net] Sent: Friday, April 29, 2011 10:28 PM To: lucene-net-dev@lucene.apache.org Subject: Re: [Lucene.Net] new structure I'm going to move ahead with this stuff this weekend unless anyone objects. On Sun, Apr 24, 2011 at 4:42 PM, Michael Herndon < mhern...@wickedsoftware.net> wrote: > if you celebrate Easter, Happy Easter, if not, then Happy lucene.net clean > up day. > > > couple of questions. would it be cool if I can add a .gitignore to the root > folder? > > also would it upset anyone if I add .cmd & .sh files to the /bin folder > and .xml/.build files to the /build folder ? > > and sand castle and shfb to the /lib folder? > > - Michael > > > On Sat, Apr 23, 2011 at 7:57 AM, Digy wrote: > >> Everything seems to be OK. >> +1 for removing old directory structure. >> >> Thanks Troy >> >> DIGY >> >> -Original Message- >> From: Troy Howard [mailto:thowar...@gmail.com] >> Sent: Saturday, April 23, 2011 3:07 AM >> To: lucene-net-dev@lucene.apache.org >> Subject: Re: [Lucene.Net] new structure >> >> I guess by 'today' I meant 'In about 6 days'. >> >> Anyhow, I completed the commit of the new directory structure.. I did not >> delete the OLD directory structure, because they can live side-by-side. >> Also, please note that I only created vs2010 solutions and upgraded the >> projects to same. >> >> Please pull down the latest revision and validate these changes. If all >> goes >> well, I'll delete the old directory structure (everything under the 'C#' >> directory). >> >> Thanks, >> Troy >> >> On Sat, Apr 16, 2011 at 3:42 PM, Troy Howard wrote: >> >> > Apologize. I got a bit derailed. Will be commiting today. >> > On Apr 16, 2011 2:20 PM, "Prescott Nasser" >> wrote: >> > > >> > > >> > > Hey Troy any status update on the new structure? I'm hesistant to do >> > updates since I know you're going to be modifying it all shortly >> > > >> > > ~P >> > > >> > >> >> >
RE: [Lucene.Net] var
A good blog about this. http://blogs.msdn.com/b/ericlippert/archive/2011/04/20/uses-and-misuses-of-i mplicit-typing.aspx DIGY -Original Message- From: Prescott Nasser [mailto:geobmx...@hotmail.com] Sent: Saturday, May 07, 2011 8:20 AM To: lucene-net-dev@lucene.apache.org Subject: [Lucene.Net] var Where do we stand on use of the var keyword? =
RE: [Lucene.Net] var
The new C# features are committed only to 2.9.4g branch. 2.9.4 can still be built targeting .NET 2.0. We can continue to support both version in parallel (in terms of bug fixes such as LUCENENET-172 & LUCENENET-413, maybe LUCENENET-266) and declare that 2.9.4 will be the last version supporting 2.0 framework. DIGY -Original Message- From: Troy Howard [mailto:thowar...@gmail.com] Sent: Saturday, May 07, 2011 12:06 PM To: lucene-net-dev@lucene.apache.org Subject: Re: [Lucene.Net] var Using var is wonderful and great. We'll hopefully do doing a lot of refactoring in the near future. var makes refactoring easier. I think we've committed fairly strongly to moving past 2.0 support. AFAIK the current trunk won't build under 2.0 anyhow (or am I mistaken, DIGY used HashSet in a recent patch, which is 3.5 or higher, and all the solutions I committed in the recent directory updates were VS2010, and all the csproj files updated to target 4.0). So, I don't see any reason to maintain 2.0 compatibility... The 4.0 runtime offers so many benefits over previous versions that, IMO, everyone who writes .NET apps should be working hard to migrate forward to 4.0 if they aren't already there. We can help the community along by giving them one more good reason to switch to a better runtime. Thanks, Troy On Sat, May 7, 2011 at 12:41 AM, Aaron Powell wrote: > Yes it's a C# 3 feature, but the C# 3 compiler (shipped in VS 2008) can > compile C# 2.0 and C# 3.0 assemblies. > Quick test: http://www.aaron-powell.com/get/var-csharp-2.PNG > > I don't have VS 2008 though, this test was done with VS 2010 using the > multitargetting features > > Aaron Powell > MVP - Internet Explorer (Development) | Umbraco Core Team > Member | FunnelWeb Team Member > > http://apowell.me | http://twitter.com/slace | Skype: aaron.l.powell | > MSN: aaz...@hotmail.com > > > -Original Message- > From: Prescott Nasser [mailto:geobmx...@hotmail.com] > Sent: Saturday, 7 May 2011 5:32 PM > To: lucene-net-dev@lucene.apache.org > Subject: RE: [Lucene.Net] var > > > > > ~Prescott Nasser > prescott.nas...@hotmail.com > 650.208.4205 > > It's a 3.0 keyword, can't be used pre C# 3.0 > > > > From: m...@aaron-powell.com > > To: lucene-net-dev@lucene.apache.org > > Date: Sat, 7 May 2011 07:28:36 + > > Subject: RE: [Lucene.Net] var > > > > My understanding of the 'var' keyword is just C# syntactic sugar, which > the compiler will translate into the actual CLR type for variable > assignment, so the compiler is capable of compiling CLR 2.0 assemblies > anyway. > > > > Aaron Powell > > MVP - Internet Explorer (Development) | Umbraco Core Team Member | > FunnelWeb Team Member > > > > http://apowell.me | http://twitter.com/slace | Skype: aaron.l.powell | > MSN: aaz...@hotmail.com > > > > -Original Message- > > From: Michael Herndon [mailto:mhern...@wickedsoftware.net] > > Sent: Saturday, 7 May 2011 3:56 PM > > To: lucene-net-dev@lucene.apache.org > > Subject: Re: [Lucene.Net] var > > > > I think that is going to depend on if we are continuing .net 2.0 / C# 2.0 > support or dropping it. > > > > > > On Sat, May 7, 2011 at 1:19 AM, Prescott Nasser >wrote: > > > > > > > > Where do we stand on use of the var keyword? > > > >
RE: [Lucene.Net] svn commit: r1100639 - /incubator/lucene.net/branches/Lucene.Net_2_9_4g/src/core/Support/EquatableList.cs
Hi Prescott,
Can you apply these fixes also to trunk? They don't diverge from java 2.9.4 and
can be compiled targetting .NET 2.0.
LUCENENET-361 Workaround for a Mono C# compiler issue
LUCENENET-330 Search.Regex Minimal Port
LUCENENET-371 Unit test for Search.Regex port
DIGY
-Original Message-
From: pnas...@apache.org [mailto:pnas...@apache.org]
Sent: Sunday, May 08, 2011 1:05 AM
To: lucene-net-comm...@lucene.apache.org
Subject: [Lucene.Net] svn commit: r1100639 -
/incubator/lucene.net/branches/Lucene.Net_2_9_4g/src/core/Support/EquatableList.cs
Author: pnasser
Date: Sat May 7 22:04:43 2011
New Revision: 1100639
URL: http://svn.apache.org/viewvc?rev=1100639&view=rev
Log:
LUCENENET-361 Workaround for a Mono C# Compiler issue
Modified:
incubator/lucene.net/branches/Lucene.Net_2_9_4g/src/core/Support/EquatableList.cs
Modified:
incubator/lucene.net/branches/Lucene.Net_2_9_4g/src/core/Support/EquatableList.cs
URL:
http://svn.apache.org/viewvc/incubator/lucene.net/branches/Lucene.Net_2_9_4g/src/core/Support/EquatableList.cs?rev=1100639&r1=1100638&r2=1100639&view=diff
==
---
incubator/lucene.net/branches/Lucene.Net_2_9_4g/src/core/Support/EquatableList.cs
(original)
+++
incubator/lucene.net/branches/Lucene.Net_2_9_4g/src/core/Support/EquatableList.cs
Sat May 7 22:04:43 2011
@@ -230,12 +230,16 @@ namespace Lucene.Net.Support
return GetHashCode(this);
}
+#if __MonoCS__
+public static int
GetHashCode(System.Collections.Generic.IEnumerable source)
+#else
/// Gets the hash code for the list.
-/// The
+/// The
/// implementation which will have all the contents hashed.
/// The hash code value.
public static int
GetHashCode(System.Collections.Generic.IEnumerable source)
-{
+#endif
+ {
// If source is null, then return 0.
if (source == null) return 0;
RE: [Lucene.Net] var
> I'll start a more official vote thread to finalize our stance. I think the > general consensus is "yes to var", but that might just be my bias talking. Maybe, I am missing something but "var" is just a syntactic sugar and changes nothing in IL level. So, I don't see a case to vote. If you think the code will be easier to read, use it. If not, don't. DIGY -Original Message- From: Troy Howard [mailto:thowar...@gmail.com] Sent: Monday, May 09, 2011 10:54 PM To: lucene-net-dev@lucene.apache.org Subject: Re: [Lucene.Net] var I'll start a more official vote thread to finalize our stance. I think the general consensus is "yes to var", but that might just be my bias talking. Re: Government projects and new tech.. There is nothing stopping conservative organizations from using our previous releases. Building from source or using the bleeding edge is not a smart tactic for anyone who cares about stability, government or otherwise. -T On Mon, May 9, 2011 at 10:58 AM, Michael Herndon < mhern...@wickedsoftware.net> wrote: > Let me know once this is a concrete answer. It needs to go on the wiki and > tweeted and even blogged about. > > There will most likely be some push back, especially if anyone is using > Lucene.Net inside of government projects. They always take forever in > letting you develop with the latest stable technologies. > > - Michael > > > > On Sat, May 7, 2011 at 11:09 AM, Digy wrote: > > > The new C# features are committed only to 2.9.4g branch. 2.9.4 can still > be > > built targeting .NET 2.0. > > We can continue to support both version in parallel (in terms of bug > fixes > > such as LUCENENET-172 & LUCENENET-413, maybe LUCENENET-266) and declare > that > > 2.9.4 will be the last version supporting 2.0 framework. > > > > DIGY > > > > > > > > > > -Original Message- > > From: Troy Howard [mailto:thowar...@gmail.com] > > Sent: Saturday, May 07, 2011 12:06 PM > > To: lucene-net-dev@lucene.apache.org > > Subject: Re: [Lucene.Net] var > > > > Using var is wonderful and great. We'll hopefully do doing a lot of > > refactoring in the near future. var makes refactoring easier. > > > > I think we've committed fairly strongly to moving past 2.0 support. AFAIK > > the current trunk won't build under 2.0 anyhow (or am I mistaken, DIGY > used > > HashSet in a recent patch, which is 3.5 or higher, and all the > solutions > > I committed in the recent directory updates were VS2010, and all the > csproj > > files updated to target 4.0). So, I don't see any reason to maintain 2.0 > > compatibility... The 4.0 runtime offers so many benefits over previous > > versions that, IMO, everyone who writes .NET apps should be working hard > to > > migrate forward to 4.0 if they aren't already there. > > > > We can help the community along by giving them one more good reason to > > switch to a better runtime. > > > > Thanks, > > Troy > > > > > > On Sat, May 7, 2011 at 12:41 AM, Aaron Powell > wrote: > > > > > Yes it's a C# 3 feature, but the C# 3 compiler (shipped in VS 2008) can > > > compile C# 2.0 and C# 3.0 assemblies. > > > Quick test: http://www.aaron-powell.com/get/var-csharp-2.PNG > > > > > > I don't have VS 2008 though, this test was done with VS 2010 using the > > > multitargetting features > > > > > > Aaron Powell > > > MVP - Internet Explorer (Development) | Umbraco Core Team > > > Member | FunnelWeb Team Member > > > > > > http://apowell.me | http://twitter.com/slace | Skype: aaron.l.powell | > > > MSN: aaz...@hotmail.com > > > > > > > > > -Original Message- > > > From: Prescott Nasser [mailto:geobmx...@hotmail.com] > > > Sent: Saturday, 7 May 2011 5:32 PM > > > To: lucene-net-dev@lucene.apache.org > > > Subject: RE: [Lucene.Net] var > > > > > > > > > > > > > > > ~Prescott Nasser > > > prescott.nas...@hotmail.com > > > 650.208.4205 > > > > > > It's a 3.0 keyword, can't be used pre C# 3.0 > > > > > > > > > > From: m...@aaron-powell.com > > > > To: lucene-net-dev@lucene.apache.org > > > > Date: Sat, 7 May 2011 07:28:36 + > > > > Subject: RE: [Lucene.Net] var > > > > > > > > My understanding of the 'var' keyword is just C# syntactic sugar, > which > > > the compiler will translate into the actual CLR type for
RE: [Lucene.Net] VOTE: .NET 2.0 Framework Support After Apache Lucene.Net 2.9.4
Yes, I missed something :) DIGY -Original Message- From: Troy Howard [mailto:thowar...@gmail.com] Sent: Monday, May 09, 2011 11:05 PM To: lucene-net-dev@lucene.apache.org; lucene-net-u...@lucene.apache.org Subject: [Lucene.Net] VOTE: .NET 2.0 Framework Support After Apache Lucene.Net 2.9.4 All, Please cast your votes regarding the topic of .Net Framework support. The question on the table is: Should Apache Lucene.Net 2.9.4 be the last release which supports the .Net 2.0 Framework? Some options are: [+1] - Yes, move forward to the latest .Net Framework version, and drop support for 2.0 completely. New features and performance are more important than backwards compatibility. [0] - Yes, focus on the latest .Net Framework, but also include patches and/or preprocessor directives and conditional compilation blocks to include support for 2.0 when needed. New features, performance, and backwards compatibility are all equally important and it's worth the additional complexity and coding work to meet all of those goals. [-1] No, .Net Framework 2.0 should remain our target platform. Backwards compatibility is more important than new features and performance. This vote is not limited to the Apache Lucene.Net IPMC. All users/contributors/committers/mailing list lurkers are welcome to cast their votes with an equal weight. This has been cross posted to both the dev and user mailing lists. Thanks, Troy
RE: [Lucene.Net] VOTE: .NET 2.0 Framework Support After Apache Lucene.Net 2.9.4
What about For 2.9.4: [-1] No, .Net Framework 2.0 should remain our target platform. Backwards compatibility is more important than new features and performance. AND For 2.9.4g: [+1] - Yes, move forward to the latest .Net Framework version, and drop support for 2.0 completely. New features and performance are more important than backwards compatibility. DIGY -Original Message- From: Troy Howard [mailto:thowar...@gmail.com] Sent: Monday, May 09, 2011 11:05 PM To: lucene-net-dev@lucene.apache.org; lucene-net-u...@lucene.apache.org Subject: [Lucene.Net] VOTE: .NET 2.0 Framework Support After Apache Lucene.Net 2.9.4 All, Please cast your votes regarding the topic of .Net Framework support. The question on the table is: Should Apache Lucene.Net 2.9.4 be the last release which supports the .Net 2.0 Framework? Some options are: [+1] - Yes, move forward to the latest .Net Framework version, and drop support for 2.0 completely. New features and performance are more important than backwards compatibility. [0] - Yes, focus on the latest .Net Framework, but also include patches and/or preprocessor directives and conditional compilation blocks to include support for 2.0 when needed. New features, performance, and backwards compatibility are all equally important and it's worth the additional complexity and coding work to meet all of those goals. [-1] No, .Net Framework 2.0 should remain our target platform. Backwards compatibility is more important than new features and performance. This vote is not limited to the Apache Lucene.Net IPMC. All users/contributors/committers/mailing list lurkers are welcome to cast their votes with an equal weight. This has been cross posted to both the dev and user mailing lists. Thanks, Troy
RE: [Lucene.Net] VOTE: .NET 2.0 Framework Support After Apache Lucene.Net 2.9.4
Before 2.9.4g, I would surely say "drop support for 2.0 completely". But now we have two versions(2.9.4 & 2.9.4g) and one can continue to support 2.0 till its death (2.9.4g may be used as base for future versions, but this is not true for 2.9.4) DIGY -Original Message- From: Troy Howard [mailto:thowar...@gmail.com] Sent: Monday, May 09, 2011 11:05 PM To: lucene-net-dev@lucene.apache.org; lucene-net-u...@lucene.apache.org Subject: [Lucene.Net] VOTE: .NET 2.0 Framework Support After Apache Lucene.Net 2.9.4 All, Please cast your votes regarding the topic of .Net Framework support. The question on the table is: Should Apache Lucene.Net 2.9.4 be the last release which supports the .Net 2.0 Framework? Some options are: [+1] - Yes, move forward to the latest .Net Framework version, and drop support for 2.0 completely. New features and performance are more important than backwards compatibility. [0] - Yes, focus on the latest .Net Framework, but also include patches and/or preprocessor directives and conditional compilation blocks to include support for 2.0 when needed. New features, performance, and backwards compatibility are all equally important and it's worth the additional complexity and coding work to meet all of those goals. [-1] No, .Net Framework 2.0 should remain our target platform. Backwards compatibility is more important than new features and performance. This vote is not limited to the Apache Lucene.Net IPMC. All users/contributors/committers/mailing list lurkers are welcome to cast their votes with an equal weight. This has been cross posted to both the dev and user mailing lists. Thanks, Troy
RE: [Lucene.Net] VOTE: .NET 2.0 Framework Support After Apache Lucene.Net 2.9.4
I chose the name "2.9.4g", since 2.9.5 may give a feeling of lucene.java 2.9.5 exists. 2.9.4g is somewhere between 2.9.4 & 3.0.3(more close to 3.0.3) DIGY -Original Message- From: Troy Howard [mailto:thowar...@gmail.com] Sent: Monday, May 09, 2011 11:54 PM To: lucene-net-dev@lucene.apache.org Subject: Re: [Lucene.Net] VOTE: .NET 2.0 Framework Support After Apache Lucene.Net 2.9.4 We could specify a new version starting with 2.9.4g and call it 2.9.5 ... Let 2.9.4 be 2.0 compatible, and let 2.9.5 not be. 2.9.5 would include the changes to generic collections, etc.. Thanks, Troy On Mon, May 9, 2011 at 1:49 PM, Digy wrote: > Before 2.9.4g, I would surely say "drop support for 2.0 completely". But > now we have two versions(2.9.4 & 2.9.4g) and one can continue to support 2.0 > till its death (2.9.4g may be used as base for future versions, but this is > not true for 2.9.4) > > DIGY > > -Original Message- > From: Troy Howard [mailto:thowar...@gmail.com] > Sent: Monday, May 09, 2011 11:05 PM > To: lucene-net-dev@lucene.apache.org; lucene-net-u...@lucene.apache.org > Subject: [Lucene.Net] VOTE: .NET 2.0 Framework Support After Apache > Lucene.Net 2.9.4 > > All, > > Please cast your votes regarding the topic of .Net Framework support. > > The question on the table is: > > Should Apache Lucene.Net 2.9.4 be the last release which supports the > .Net 2.0 Framework? > > Some options are: > > [+1] - Yes, move forward to the latest .Net Framework version, and drop > support for 2.0 completely. New features and performance are more important > than backwards compatibility. > [0] - Yes, focus on the latest .Net Framework, but also include patches > and/or preprocessor directives and conditional compilation blocks to > include > support for 2.0 when needed. New features, performance, and backwards > compatibility are all equally important and it's worth the additional > complexity and coding work to meet all of those goals. > [-1] No, .Net Framework 2.0 should remain our target platform. Backwards > compatibility is more important than new features and performance. > > > This vote is not limited to the Apache Lucene.Net IPMC. All > users/contributors/committers/mailing list lurkers are welcome to cast > their > votes with an equal weight. This has been cross posted to both the dev and > user mailing lists. > > Thanks, > Troy > >
RE: [Lucene.Net] VOTE: .NET 2.0 Framework Support After Apache Lucene.Net 2.9.4
By the way, the "g" in 2.9.4g stands for "Generics" DIGY -Original Message- From: Digy [mailto:digyd...@gmail.com] Sent: Tuesday, May 10, 2011 12:03 AM To: 'lucene-net-dev@lucene.apache.org' Subject: RE: [Lucene.Net] VOTE: .NET 2.0 Framework Support After Apache Lucene.Net 2.9.4 I chose the name "2.9.4g", since 2.9.5 may give a feeling of lucene.java 2.9.5 exists. 2.9.4g is somewhere between 2.9.4 & 3.0.3(more close to 3.0.3) DIGY -Original Message- From: Troy Howard [mailto:thowar...@gmail.com] Sent: Monday, May 09, 2011 11:54 PM To: lucene-net-dev@lucene.apache.org Subject: Re: [Lucene.Net] VOTE: .NET 2.0 Framework Support After Apache Lucene.Net 2.9.4 We could specify a new version starting with 2.9.4g and call it 2.9.5 ... Let 2.9.4 be 2.0 compatible, and let 2.9.5 not be. 2.9.5 would include the changes to generic collections, etc.. Thanks, Troy On Mon, May 9, 2011 at 1:49 PM, Digy wrote: > Before 2.9.4g, I would surely say "drop support for 2.0 completely". But > now we have two versions(2.9.4 & 2.9.4g) and one can continue to support 2.0 > till its death (2.9.4g may be used as base for future versions, but this is > not true for 2.9.4) > > DIGY > > -Original Message- > From: Troy Howard [mailto:thowar...@gmail.com] > Sent: Monday, May 09, 2011 11:05 PM > To: lucene-net-dev@lucene.apache.org; lucene-net-u...@lucene.apache.org > Subject: [Lucene.Net] VOTE: .NET 2.0 Framework Support After Apache > Lucene.Net 2.9.4 > > All, > > Please cast your votes regarding the topic of .Net Framework support. > > The question on the table is: > > Should Apache Lucene.Net 2.9.4 be the last release which supports the > .Net 2.0 Framework? > > Some options are: > > [+1] - Yes, move forward to the latest .Net Framework version, and drop > support for 2.0 completely. New features and performance are more important > than backwards compatibility. > [0] - Yes, focus on the latest .Net Framework, but also include patches > and/or preprocessor directives and conditional compilation blocks to > include > support for 2.0 when needed. New features, performance, and backwards > compatibility are all equally important and it's worth the additional > complexity and coding work to meet all of those goals. > [-1] No, .Net Framework 2.0 should remain our target platform. Backwards > compatibility is more important than new features and performance. > > > This vote is not limited to the Apache Lucene.Net IPMC. All > users/contributors/committers/mailing list lurkers are welcome to cast > their > votes with an equal weight. This has been cross posted to both the dev and > user mailing lists. > > Thanks, > Troy > >
RE: [Lucene.Net] VOTE: .NET 2.0 Framework Support After Apache Lucene.Net 2.9.4
It is used already. https://issues.apache.org/jira/browse/LUCENE/fixforversion/12315914 DIGY -Original Message- From: Troy Howard [mailto:thowar...@gmail.com] Sent: Tuesday, May 10, 2011 12:21 AM To: lucene-net-dev@lucene.apache.org Subject: Re: [Lucene.Net] VOTE: .NET 2.0 Framework Support After Apache Lucene.Net 2.9.4 That makes sense, however my suggestion of using 2.9.5 is for the same purpose. Since the code base is now diverging from the Java library, it makes sense that the version numbers would diverge as well. The fact that there is no Java version 2.9.5 will make that Lucene.Net version stand out as having features/code which are different from the Java library. 2.9.4g sounds like a "bug fix version" for 2.9.4. Thanks, Troy On Mon, May 9, 2011 at 2:02 PM, Digy wrote: > I chose the name "2.9.4g", since 2.9.5 may give a feeling of lucene.java > 2.9.5 exists. > 2.9.4g is somewhere between 2.9.4 & 3.0.3(more close to 3.0.3) > > DIGY > > -Original Message- > From: Troy Howard [mailto:thowar...@gmail.com] > Sent: Monday, May 09, 2011 11:54 PM > To: lucene-net-dev@lucene.apache.org > Subject: Re: [Lucene.Net] VOTE: .NET 2.0 Framework Support After Apache > Lucene.Net 2.9.4 > > We could specify a new version starting with 2.9.4g and call it 2.9.5 > ... Let 2.9.4 be 2.0 compatible, and let 2.9.5 not be. > > 2.9.5 would include the changes to generic collections, etc.. > > Thanks, > Troy > > > On Mon, May 9, 2011 at 1:49 PM, Digy wrote: > >> Before 2.9.4g, I would surely say "drop support for 2.0 completely". But >> now we have two versions(2.9.4 & 2.9.4g) and one can continue to support 2.0 >> till its death (2.9.4g may be used as base for future versions, but this is >> not true for 2.9.4) >> >> DIGY >> >> -Original Message- >> From: Troy Howard [mailto:thowar...@gmail.com] >> Sent: Monday, May 09, 2011 11:05 PM >> To: lucene-net-dev@lucene.apache.org; lucene-net-u...@lucene.apache.org >> Subject: [Lucene.Net] VOTE: .NET 2.0 Framework Support After Apache >> Lucene.Net 2.9.4 >> >> All, >> >> Please cast your votes regarding the topic of .Net Framework support. >> >> The question on the table is: >> >> Should Apache Lucene.Net 2.9.4 be the last release which supports the >> .Net 2.0 Framework? >> >> Some options are: >> >> [+1] - Yes, move forward to the latest .Net Framework version, and drop >> support for 2.0 completely. New features and performance are more important >> than backwards compatibility. >> [0] - Yes, focus on the latest .Net Framework, but also include patches >> and/or preprocessor directives and conditional compilation blocks to >> include >> support for 2.0 when needed. New features, performance, and backwards >> compatibility are all equally important and it's worth the additional >> complexity and coding work to meet all of those goals. >> [-1] No, .Net Framework 2.0 should remain our target platform. Backwards >> compatibility is more important than new features and performance. >> >> >> This vote is not limited to the Apache Lucene.Net IPMC. All >> users/contributors/committers/mailing list lurkers are welcome to cast >> their >> votes with an equal weight. This has been cross posted to both the dev and >> user mailing lists. >> >> Thanks, >> Troy >> >> > >
RE: [Lucene.Net] build scripts & v2.9.4g contrib projects build state
Thanks Michael, I fixed it. DIGY -Original Message- From: Michael Herndon [mailto:mhern...@wickedsoftware.net] Sent: Saturday, May 21, 2011 11:48 PM To: lucene-net-dev@lucene.apache.org Subject: [Lucene.Net] build scripts & v2.9.4g contrib projects build state I get a number of build errors when using vs2010/Contrib.Test.All.sln from some of the contrib projects. Is this a known state of the contrib projects ? Lucene.Net.Tests.sln builds just fine.
RE: [Lucene.Net] Adding proper System.IO.Stream support to Lucene.Net
Hi Christopher, According to my experience, this kind of eMails eighter gets no response or too many fluctuations with no result. What about preparing a *small* "Proof of Concept" code that passes all unit tests. DIGY -Original Message- From: Christopher Currens [mailto:currens.ch...@gmail.com] Sent: Wednesday, May 25, 2011 12:08 AM To: lucene-net-dev@lucene.apache.org Subject: [Lucene.Net] Adding proper System.IO.Stream support to Lucene.Net All, I've spent the past few days looking at what it would take to implement proper streaming of data into and out of an index. Fortunately, it hasn't proven very difficult at all, leaving me with a solution that works very nicely. Now that I know it's possible, I wanted to discuss with the community the best way to add this to the API. Currently, it's setup that a field can have a Stream value if its binary (System.IO.Stream StreamValue()). I have plans to, wherever in Lucene a byte[] is used, to replace it with streaming functions, internally. I think its a good idea to keep the byte[] BinaryValue() as it is, but essentially replace it, by default, with a kind of lazy loading. In the current version of lucene, if a user were to open a document with a binary field, that entire field will be loaded into memory. The idea behind replacing the internals of FieldsReader.cs by passing a stream along instead of a byte[], is that people using the API to stream the data out will load no more into memory than they have to. People using the byte[] BinaryValue() function to get the binary data will actually have improved performance as well, as the byte array will be loaded when calling the method, instead of the creation of the document. As a final note on binary data streaming, by streaming the data in, we obviously can't support compression of those fields. The compression in Lucene is poor anyway, as it's not compression that can be done in blocks, it requires large amounts of memory as it needs all the data in memory to do the compression, which is also done in a separate byte array. However, an ability I had briefly talked to Troy about in person, was the ability to add StreamFilters, so that data passed is filtered first by a compression algorithm or such before its stored in the index. However, that doesn't really apply directly to the lucene domain, but it does at least afford the user the opportunity to be able to do that via streaming data into lucene.net. I also want to add proper TextReader support to Lucene.Net. A large difference between the Java and .NET versions of lucene is that the Java version supports setting a field's value to a TextReader, that both analyzes and stores the data. Due to the fact that the TextReader in .Net doesn't support resetting or seeking of the underlying stream, we can only analyze the text in lucene, we can't store the field. A solution that comes to mind would be creating a util class, something like SeekableTextReader, that inherits from TextReader that can be passed to the field, with special behavior that allows it to be reset, and thus both analyzed and stored. Perhaps the largest downside to that solution, is in order to keep the API the same while allowing it to be stored, it would require fairly ugly checks like "if(reader is SeekableTextReader) //do this". Perhaps a cleaner solution would be to add yet another value to the Field class that allowed for a SeekableTextReader to be passed. This way has its own downsides, in that now there are two methods that expect TextReaders, one stores and one doesn't, seems rather confusing. But I suppose this is why I was looking for the community's opinion in the first place. The more comments about this the better. I think adding this could add some much needed functionality to Lucene, and start setting apart its performance from the Java version. Thanks, Christopher
RE: [Lucene.Net] Faceting
For that many unique values I would recommend to take a look at "References to adding faceted to Lucene.Net" section in that wiki page. Using BitSets(as in contrib) is good for large number of search results(say millions) with small # of facets(say 1000-4000). Using "Collector" approach is good when result set is small but number of facets is relatively large as in your case. What to use really depends on your needs(or a hybrid approach that uses both like in Solr) DIGY PS: every contribution is always welcome. -Original Message- From: Robert Stewart [mailto:robert_stew...@epam.com] Sent: Friday, June 10, 2011 10:36 PM To: Subject: [Lucene.Net] Faceting I took a brief look at the documentation for faceting in contrib. I did not look at code yet. Do you think it can work for these requirements: 1) Needs to compute facets for fields of more than one value per document (for instance a document may have many company names associated to it). 2) Needs to compute facets over any arbitrary query 3) Needs to be fast: a) I have 100 million docs distributed in about 10 indexes (10 million docs each) and use parallel distributed search and merge b) For some facet fields, we have over 100,000 possible unique values (for example, we have 150,000 possible company values) In our case, we pre-cache compressed doc sets in memory for each unique facet value. if # of values < 1/9 size of index, then we use variable byte encoding of integers, otherwise we use BitArray. These doc sets are then sorted in descending order by document frequency (so more frequent facets are counted first) We open new index "snapshots" every couple minutes and pre-load these facet doc sets into ram each time new snapshot is opened in the background. We use about 32 GB of RAM when fully loaded. At search time we gather all the doc IDs matching search into a BitArray. Then we enumerate all the facet doc sets in desc order by overall doc frequency, and count how many docs in search matched each facet. These facet counts are passed into a priority queue to gather top N counts (such that when the next total count < full priority queue min value, it breaks out of loop, that is why we do it in desc order by total doc freq) We also count # of docs per day over date range for each facet. We also compute facets for about 10 fields during search, and get top 10 facets each. Typically search over 100 million docs including facet counts and per-date counts takes about 1300ms. Our current solution actually works pretty well - but it is a burden on RAM, time to load new snapshots, and extra pressure on GC during busy times. Do you think your current facet implementation can work as above, and should I try to contrib what I have (it would definitely take a little refactoring)? Thanks, Bob On Jun 10, 2011, at 12:37 PM, Digy wrote: > Have you tried to use Lucene.Net as is, before working on optimizing your > code? There are a lot of speed improvements in it since 1.9. > There is also a Faceted Search project in contrib. > (https://cwiki.apache.org/confluence/display/LUCENENET/Simple+Faceted+Search > ) > > DIGY > > > > -Original Message- > From: Robert Stewart [mailto:robert_stew...@epam.com] > Sent: Friday, June 10, 2011 7:14 PM > To: > Subject: [Lucene.Net] Score(collector) called for each subReader - but not > what I need > > As I previously tried to explain, I have custom query for some pre-cached > terms, which I load into RAM in efficient compressed form. I need this for > faster searching and also for much faster faceting. So what I do is process > incoming query and replace certain sub-queries with my own "CachedTermQuery" > objects, which extend Query. Since these are not per-segment, I only want > scorer.Score(collector) called once, not once for each segment in my index. > Essentially what happens now if I have a search is it collects the same > documents N times, 1 time for each segment. Is there anyway to combine > different Scorers/Collectors such that I can control when it enumerates > collection by multiple sub-readers, and when not to? This all worked in > previous version of Lucene because enumerating sub-indexes (segments) was > pushed to a lower level inside Lucene API and not it is elevated to a higher > level. > > Thanks > Bob > > > On Jun 9, 2011, at 4:33 PM, Robert Stewart wrote: > >> I found the problem. The problem is that I have a custom "query > optimizer", and that replaces certain TermQuery's within a Boolean query > with a custom Query and this query has its own weight/scorer that retrieves > matching documents from an in-memory cache (and that is not Lucene backed). > But it looks like my custom hitcollectors are now wrapped in a > HitCollectorWrapper which assumes Colle
RE: [Lucene.Net] Could not load assembly
Hard to guess.
Have you seen Contrib.IsolatedStorage.Test.csproj?
DIGY
-Original Message-
From: Prescott Nasser [mailto:geobmx...@hotmail.com]
Sent: Sunday, June 12, 2011 12:33 AM
To: lucene-net-dev@lucene.apache.org
Subject: [Lucene.Net] Could not load assembly
While trying to set up a test for Contrib.IsolatedStorage, I'm running into
an issue I haven't been able to solve.
{System.TypeLoadException: Could not load type
'Lucene.Net.Documents.Document' from assembly 'Lucene.Net, Version=2.9.4.2,
Culture=neutral, PublicKeyToken=null'.
at System.Windows.Controls.Primitives.ButtonBase.OnClick()
at System.Windows.Controls.Button.OnClick()
at
System.Windows.Controls.Primitives.ButtonBase.OnMouseLeftButtonUp(MouseButto
nEventArgs e)
at System.Windows.Controls.Control.OnMouseLeftButtonUp(Control ctrl,
EventArgs e)
at MS.Internal.JoltHelper.FireEvent(IntPtr unmanagedObj, IntPtr
unmanagedObjArgs, Int32 argsTypeIndex, String eventName)
}
I'm not sure why I'm getting this. When I call the IsolatedStorageDirectory
constructor, that runs fine, but when I try to call something from the
Lucene.Net core I'm running into this error.
Directory isoDir = new IsolatedStorageDirectory("//", null);
Document doc; //this line throws the error, the above runs fine.
I've cleared the GAC, made sure I've got the latest binaries referenced etc.
Any thoughts?
Thanks,
~Prescott =
RE: [Lucene.Net] Is a Lucene.Net Line-by-Line Jave port needed?
Hi Rory, I agree with you in theory. But collecting people to work on a project is not easy as giving advise. Till now, line-by-line port have seemed to be the best with a limited human source. Would you be willing to work on your approach and maintain newer Lucene.Net releases? DIGY -Original Message- From: Rory Plaire [mailto:codekai...@gmail.com] Sent: Thursday, June 30, 2011 1:06 AM To: lucene-net-dev@lucene.apache.org Subject: Re: [Lucene.Net] Is a Lucene.Net Line-by-Line Jave port needed? For what it's worth, I've participated in a number of projects which have been "ported" from Java to .Net with varying levels of "translation" into the native style and functionalty of the .Net framework. The largest are NTS, a JTS port and NHibernate, a Java Hibernate port. My experience is that a line-by-line port isn't as valuable as people would imagine. Even if we discount the reality that a line-by-line port is really unachievable due to various differences between the frameworks, keeping even identical code in sync will always take some work: full automation on this large of a project is infeasible. During manual effort, therefore, making readable changes to the code is really not that much more work. For update maintenance, porting over code from recent versions of both projects to the .Net versions, and ".Nettifying" that code is little trouble. Since both projects use source control, it's easy to see the changes and translate them. When it comes to debugging issues, in NTS or NHibernate, I go to the Java sources, and even if the classes were largely rewritten to take advantage of IEnumerable or generics or structures, running unit tests, tracing the code, and seeing the output of each has always been straightforward. Since I'm using .Net, I'd want the Lucene.Net project to be more .Net than a line-by-line port of Java, in order to take advantage of the Framework as well as provide a better code base for .Net developers to maintain. If large .Net projects ported from Java do this, and have found considerable success, it is, in my view, a well-proven practice and shouldn't be avoided due to uncertainty of how the resulting code should work. Ultimately, that is what unit tests are for, anyway.
RE: [Lucene.Net] Is a Lucene.Net Line-by-Line Jave port needed?
Michael, You interpret the report as "whoever commits code wins"? But when I look at it, I see "a lof of talk, no work". .Net community is not interested in contributing. I really don't understand what hinders people to work on Lucene.Net. As I did for 2.9.4g, grab the code, do whatever you want on it and submit back. If it doesn't fit to the project's direction it can still find a place in contrib or in branch. All of the approaches can live side by side happily in the Lucene.Net repository. Troy, I also don't understand why do you wait for 2.9.4g? It is a *branch* and has nothing to do with the trunk. It need not be an offical release and can live in branch as a PoC. As a result, I got bored to listen to "this should be done that way". What I want to see is "I did it that way, should we continue with this". DIGY -Original Message- From: Troy Howard [mailto:thowar...@gmail.com] Sent: Thursday, June 30, 2011 10:47 PM To: lucene-net-dev@lucene.apache.org Subject: Re: [Lucene.Net] Is a Lucene.Net Line-by-Line Jave port needed? Michael, I agree with everything you said. My point in saying "whoever commits code wins" was to illustrate the reality of how and why the project has the current form. Building consensus is difficult. It is an essential first step before we can do something like make a list of bit-sized pieces of work that others can work on. This is why my real message of "Let's find a way to accommodate both" is so important. It allows us to build consensus, so that we can settle on a direction and structure our work. Until we accomplish that, it really is "whoever commits code wins", and that is an unhealthy and unmaintainable way to operate. >From a technical perspective, your statements about the unit tests are completely accurate. They really need a LOT of reworking. That's the very first step before making any significant changes. Part of the problem is that the tests themselves are not well written. The other part is that the Lucene object model was not designed for testability, and it makes writing good tests more difficult, and certain tests might not be possible. It will be difficult to write good unit tests without re-structuring. The biggest issue is the use of abstract classes with base behaviour vs interfaces or fully abstracted classes. Makes mocking tough. This is the direction I was going when I started the Lucere project. I'd like to start in on that work after the 2.9.4g release. Thanks, Troy On Thu, Jun 30, 2011 at 12:04 PM, Michael Herndon < mhern...@wickedsoftware.net> wrote: > I'd say that is all the more reasons that we need to work smarter and not > harder. I'd also say thats a good reason to make sure we build consensus > rather than just saying whoever commits code wins. > > And its a damn good reason to focus on the effort of growing the number of > contributors and lowing the barrier to submitting patches, breaking things > down into pieces that people would feel confident to work on without > being overwhelmed by the complexity of Lucene.Net. > > There is a pretty big gap between Lucene 2.9.x to Lucene 4.0 and the > internals and index formats are significantly different including nixing > the > current vint file format and using byte[] array slices for Terms instead of > char[]. > > So while porting 1 to 1 while require less knowledge or thought, its most > likely going to require more hours of work. And Its definitely not going to > guarantee the stability of the code or that its great code. > > I'd have to say that its not as stable as most would believe at the moment. > > Most of the tests avoid anything that remotely looks like it knows about > the > DRY principle and there is a static constructor in the core test case that > throws an exception if it doesn't find an environment variable "TEMP" which > will fail 90% of the tests and nunit will be unable to give you a clear > reason why. Just to name a few issues I came across working towards > getting > Lucene.Net into CI. I haven't even started really digging in under the > covers of the code yet. > > So my suggestion is to chew on this a bit more and build consensus, avoid > fracturing people into sides. Be open to reservations and concerns that > others have and continue to address them. > > - Michael > > > On Thu, Jun 30, 2011 at 2:10 PM, Digy wrote: > > > Although there are a lot of people using Lucene.Net, this is our > > contribution report for the past 5 years. > > > > > > > https://issues.apache.org/jira/secure/ConfigureReport.jspa?atl_token=A5KQ-2Q > > > > > AV-T4JA-FDED|3204f7e696067a386144705075c074e991db2a2b|lin&versionId=-1&iss
RE: [Lucene.Net] Is a Lucene.Net Line-by-Line Jave port needed?
> A) I don't to want to commit anything thats going to piss alot of people off, > B) I don't want to spend time/waste time on modifications that are going to be rejected. What I've learnt from "Apache Way" is creating a JIRA issue if you are hesitant. If no one answers in a reasonable time(mostly), then commit. DIGY -Original Message- From: Michael Herndon [mailto:mhern...@wickedsoftware.net] Sent: Thursday, June 30, 2011 11:58 PM To: lucene-net-dev@lucene.apache.org Subject: Re: [Lucene.Net] Is a Lucene.Net Line-by-Line Jave port needed? @Troy, I've already started working towards fixing unit testing issues, and prototyping some things that sure DRY up the testing just so that I can get the tests running on mono. Those changes are currently in a private git repo, however since we don't have a CI, I'm need to make some time to manually test those on at least 3 different Os (windowx, osx, and ubuntu) before putting those back into the 2.9.4g branch. The reason being I need those in working order so that I can do a write up on pulling those from source and at least running the build script to compile everything and run the tests for you. I don't know about everyone else, but thats a starting point I look for when I go to work on something or commit something back. They should make their way back sometime this month. I think the next thing I'll do is put my money where my mouth is, spend time break down the rest of the CI tasks, then seeing how much stuff I can get documented into the wiki. The simple faceted search is a decent starting template. @Digy I agree with the talk, no work. Though coming from the outside in, I still cringe when I make any commits at the moment. (even that little .gitnore file) A) I don't to want to commit anything thats going to piss alot of people off, B) I don't want to spend time/waste time on modifications that are going to be rejected. C) it took a good deal of going through things before I felt comfortable to even making a commit. D) yes I know I just need to get over it and so does everyone else (hence the obsession with the unit tests at the moment). and I think a key to relaying people to get over it, including myself, is to make the point you had more clear across the board: *"If it doesn't fit to the project's direction it can still find a place in contrib or in branch. All of the approaches can live side by side happily in the Lucene.Net repository." * +1 because that makes feel there is more leadway to experiment and any decent effort will at least go somewhere to live and not be wasted. On Thu, Jun 30, 2011 at 4:19 PM, Digy wrote: > Michael, > You interpret the report as "whoever commits code wins"? But when I look at > it, I see "a lof of talk, no work". .Net community is not interested in > contributing. > I really don't understand what hinders people to work on Lucene.Net. As I > did for 2.9.4g, grab the code, do whatever you want on it and submit back. > If it doesn't fit to the project's direction it can still find a place in > contrib or in branch. All of the approaches can live side by side happily in > the Lucene.Net repository. > > Troy, > I also don't understand why do you wait for 2.9.4g? It is a *branch* and > has nothing to do with the trunk. It need not be an offical release and can > live in branch as a PoC. > > > As a result, I got bored to listen to "this should be done that way". What > I want to see is "I did it that way, should we continue with this". > > DIGY > > > > > -Original Message- > From: Troy Howard [mailto:thowar...@gmail.com] > Sent: Thursday, June 30, 2011 10:47 PM > To: lucene-net-dev@lucene.apache.org > Subject: Re: [Lucene.Net] Is a Lucene.Net Line-by-Line Jave port needed? > > Michael, > > I agree with everything you said. My point in saying "whoever commits code > wins" was to illustrate the reality of how and why the project has the > current form. > > Building consensus is difficult. It is an essential first step before we > can > do something like make a list of bit-sized pieces of work that others can > work on. > > This is why my real message of "Let's find a way to accommodate both" is so > important. It allows us to build consensus, so that we can settle on a > direction and structure our work. > > Until we accomplish that, it really is "whoever commits code wins", and > that > is an unhealthy and unmaintainable way to operate. > > From a technical perspective, your statements about the unit tests are > completely accurate. They really need a LOT of reworking. That's the very > first step before making any significant changes. Part of th
RE: [Lucene.Net] Is a Lucene.Net Line-by-Line Jave port needed?
> Ok I think I asked the wrong question Yes, you started the flame war :) * What I realy hate in code is the Anonymous classes inhereted from JLCA which make the code impossible to read. I changed a few in 2.9.4g with replacing the single abstract method with Func<> or Action<> like in FilterCache from: protected abstract object MergeDeletes(IndexReader reader, object value); to: Func MergeDeletes; but there are zillions of those with more than 1 abstract method. I still think of how to replace them with something suitable without diverging much from Java. * I am also not satisfied with return parameters like ICollection<>, IList<>, IEnumerator<> etc. These should be standardized some way. * Support.Set & Support.Dictionary classes are just fast solutions to the problem "java's collections return null when an item does not exist in the collection whereas .NET throws exception". A better way may be used. * missing IEquatable's * making Iterators as real .NET Enumerators etc. etc. etc. It seems to be a never ending story. DIGY -Original Message- From: Scott Lombard [mailto:lombardena...@gmail.com] Sent: Friday, July 01, 2011 12:13 AM To: lucene-net-dev@lucene.apache.org Subject: RE: [Lucene.Net] Is a Lucene.Net Line-by-Line Jave port needed? Ok I think I asked the wrong question. I am trying to figure out where to put my time. I was thinking about working on the automated porting system, but when I saw the response to the .NET 4.0 discussions I started to question if that is the right direction. The community seemed to be more interested in the .NET features. The complexity of the automated tool is going to become very high and will probably end up with a line-for-line style port. So I keep asking my self is the automated tool worth it. I don't think it is. I like the method has been Digy is using for porting the code. So I guess for me the real question is Digy where did you see 2.9.4g going next and what do you need help on? Scott > -Original Message- > From: Digy [mailto:digyd...@gmail.com] > Sent: Thursday, June 30, 2011 4:20 PM > To: lucene-net-dev@lucene.apache.org > Subject: RE: [Lucene.Net] Is a Lucene.Net Line-by-Line Jave port needed? > > Michael, > You interpret the report as "whoever commits code wins"? But when I look > at it, I see "a lof of talk, no work". .Net community is not interested in > contributing. > I really don't understand what hinders people to work on Lucene.Net. As I > did for 2.9.4g, grab the code, do whatever you want on it and submit back. > If it doesn't fit to the project's direction it can still find a place in > contrib or in branch. All of the approaches can live side by side happily > in the Lucene.Net repository. > > Troy, > I also don't understand why do you wait for 2.9.4g? It is a *branch* and > has nothing to do with the trunk. It need not be an offical release and > can live in branch as a PoC. > > > As a result, I got bored to listen to "this should be done that way". What > I want to see is "I did it that way, should we continue with this". > > DIGY > > > > > -Original Message- > From: Troy Howard [mailto:thowar...@gmail.com] > Sent: Thursday, June 30, 2011 10:47 PM > To: lucene-net-dev@lucene.apache.org > Subject: Re: [Lucene.Net] Is a Lucene.Net Line-by-Line Jave port needed? > > Michael, > > I agree with everything you said. My point in saying "whoever commits code > wins" was to illustrate the reality of how and why the project has the > current form. > > Building consensus is difficult. It is an essential first step before we > can > do something like make a list of bit-sized pieces of work that others can > work on. > > This is why my real message of "Let's find a way to accommodate both" is > so > important. It allows us to build consensus, so that we can settle on a > direction and structure our work. > > Until we accomplish that, it really is "whoever commits code wins", and > that > is an unhealthy and unmaintainable way to operate. > > From a technical perspective, your statements about the unit tests are > completely accurate. They really need a LOT of reworking. That's the very > first step before making any significant changes. Part of the problem is > that the tests themselves are not well written. The other part is that the > Lucene object model was not designed for testability, and it makes writing > good tests more difficult, and certain tests might not be possible. It > will > be difficult to write good unit tests without re-structuring. The biggest > issue is the use of abstract classes with base behaviour vs
RE: [Lucene.Net] Is a Lucene.Net Line-by-Line Jave port needed?
I can not say I like this approach, but till we find an automated way(with good results), it seems to be the only way we can use. DIGY -Original Message- From: Troy Howard [mailto:thowar...@gmail.com] Sent: Friday, July 01, 2011 12:43 AM To: lucene-net-dev@lucene.apache.org Subject: Re: [Lucene.Net] Is a Lucene.Net Line-by-Line Jave port needed? Scott - The idea of the automated port is still worth doing. Perhaps it makes sense for someone more passionate about the line-by-line idea to do that work? I would say, focus on what makes sense to you. Being productive, regardless of the specific direction, is what will be most valuable. Once you start, others will join and momentum will build. That is how these things work. I like DIGY's approach too, but the problem with it is that it is a never-ending manual task. The theory behind the automated port is that it may reduce the manual work. It is complicated, but once it's built and works, it will save a lot of future development hours. If it's built in a sufficiently general manner, it could be useful for other project like Lucene.Net that want to automate a port from Java to C#. It might make sense for that to be a separate project from Lucene.Net though. -T On Thu, Jun 30, 2011 at 2:13 PM, Scott Lombard wrote: > Ok I think I asked the wrong question. I am trying to figure out where to > put my time. I was thinking about working on the automated porting system, > but when I saw the response to the .NET 4.0 discussions I started to > question if that is the right direction. The community seemed to be more > interested in the .NET features. > > The complexity of the automated tool is going to become very high and will > probably end up with a line-for-line style port. So I keep asking my self > is the automated tool worth it. I don't think it is. > > I like the method has been Digy is using for porting the code. So I guess > for me the real question is Digy where did you see 2.9.4g going next and > what do you need help on? > > Scott > > > > > > -Original Message- > > From: Digy [mailto:digyd...@gmail.com] > > Sent: Thursday, June 30, 2011 4:20 PM > > To: lucene-net-dev@lucene.apache.org > > Subject: RE: [Lucene.Net] Is a Lucene.Net Line-by-Line Jave port needed? > > > > Michael, > > You interpret the report as "whoever commits code wins"? But when I look > > at it, I see "a lof of talk, no work". .Net community is not interested > in > > contributing. > > I really don't understand what hinders people to work on Lucene.Net. As I > > did for 2.9.4g, grab the code, do whatever you want on it and submit > back. > > If it doesn't fit to the project's direction it can still find a place in > > contrib or in branch. All of the approaches can live side by side happily > > in the Lucene.Net repository. > > > > Troy, > > I also don't understand why do you wait for 2.9.4g? It is a *branch* and > > has nothing to do with the trunk. It need not be an offical release and > > can live in branch as a PoC. > > > > > > As a result, I got bored to listen to "this should be done that way". > What > > I want to see is "I did it that way, should we continue with this". > > > > DIGY > > > > > > > > > > -Original Message- > > From: Troy Howard [mailto:thowar...@gmail.com] > > Sent: Thursday, June 30, 2011 10:47 PM > > To: lucene-net-dev@lucene.apache.org > > Subject: Re: [Lucene.Net] Is a Lucene.Net Line-by-Line Jave port needed? > > > > Michael, > > > > I agree with everything you said. My point in saying "whoever commits > code > > wins" was to illustrate the reality of how and why the project has the > > current form. > > > > Building consensus is difficult. It is an essential first step before we > > can > > do something like make a list of bit-sized pieces of work that others can > > work on. > > > > This is why my real message of "Let's find a way to accommodate both" is > > so > > important. It allows us to build consensus, so that we can settle on a > > direction and structure our work. > > > > Until we accomplish that, it really is "whoever commits code wins", and > > that > > is an unhealthy and unmaintainable way to operate. > > > > From a technical perspective, your statements about the unit tests are > > completely accurate. They really need a LOT of reworking. That's the very > > first step before making any significant changes. Part of the problem is > > that the tests themselves are n
RE: [Lucene.Net] Is a Lucene.Net Line-by-Line Jave port needed?
> I've add a Paths Class under the Lucene.Net.Tests Util folder
Since it is a Lucene.Net specific code, may "Support" be a better place?
DIGY
-Original Message-
From: Michael Herndon [mailto:mhern...@wickedsoftware.net]
Sent: Friday, July 01, 2011 11:53 PM
To: lucene-net-dev@lucene.apache.org
Subject: Re: [Lucene.Net] Is a Lucene.Net Line-by-Line Jave port needed?
@Rory,
Jira in the past had the ability to create sub tasks or convert a current
task to a sub task. I'm guessing that apache's jira should be able to do
that.
@All,
I've add a Paths Class under the Lucene.Net.Tests Util folder (feel free to
rename, refactor as long as the tests still work) to help with working with
paths in general. This should help with forming paths relative to the temp
directory or the project root.
NUnit's Shadow Copy tends to throw people off when trying to get the path of
the current assembly being tested to build up a relative path, the Path
class should help with that.
- Michael
On Fri, Jul 1, 2011 at 4:09 PM, Rory Plaire wrote:
> My thinking is just a separate ticket for each one. This makes the work
> easier to manage and gives a better sense about how much work is left as
> well as makes it easier to prioritize independent issues. We could link
all
> the sub-issues to a single task / feature / whatever (that is, if JIRA has
> that capability).
>
> -r
> On Fri, Jul 1, 2011 at 12:48 PM, Michael Herndon <
> mhern...@wickedsoftware.net> wrote:
>
> > I think whatever makes sense to do.
> >
> > possibly create one jira for now with a running list that can be
modified
> > and possibly as people pull from that list, cross things off or create a
> > separate ticket that links back to to the main one.
> >
> >
> >
> >
> > On Fri, Jul 1, 2011 at 3:35 PM, Rory Plaire
> wrote:
> >
> > > @Michael -
> > >
> > > Should that list be in JIRA? It would be easier to manage, I think...
> > >
> > > If yes, I'll happily do it.
> > >
> > > -r
> > >
> > > On Fri, Jul 1, 2011 at 8:04 AM, Michael Herndon <
> > > mhern...@wickedsoftware.net
> > > > wrote:
> > >
> > > > * need to document what the build script does. whut grammerz?
> > > >
> > > > On Fri, Jul 1, 2011 at 10:52 AM, Michael Herndon <
> > > > mhern...@wickedsoftware.net> wrote:
> > > >
> > > > > @Rory, @All,
> > > > >
> > > > > The only tickets I currently have for those is LUCENE-419,
> LUCENE-418
> > > > >
> > > > > 418, I should be able to push into the 2.9.4g branch tonight.
> 419
> > is
> > > a
> > > > > long term goal and not as important as getting the tests fixed, of
> > have
> > > > the
> > > > > tests broken down into what is actually a unit test, functional
> test,
> > > > perf
> > > > > or long running test. I can get into more why it needs to be done.
> > > > >
> > > > > I'll also need to make document the what build script currently
> does
> > on
> > > > the
> > > > > wiki & and make a few notes about testing, like using the
> > RAMDirectory,
> > > > > etc.
> > > > >
> > > > > Things that need to get done or even be discussed.
> > > > > * There needs to be a running list of things to do/not to do with
> > > > testing.
> > > > > I don't know if this goes in a jira or do we keep a running list
on
> > the
> > > > wiki
> > > > > or site for people to pick up and help with.
> > > > > * Tests need to run on mono and not Fail (there is a good deal of
> > > > failing
> > > > > tests on mono, mostly due to the temp directory have the C:\ in
the
> > > > path).
> > > > > * Assert.Throw() needs to be used instead of
> > Try/Catch
> > > > > Assert.Fail. **
> > > > > * File & Path combines to the temp directory need helper methods,
> > > > > * e,g, having this in a hundred places is bad new
> > > > >
> > > >
> > >
> >
>
System.IO.FileInfo(System.IO.Path.Combine(Support.AppSettings.Get("tempDir",
> > > > > ""), "testIndex"));
> > > > > * We should still be testing deprecated methods, but we need to
> use
> > > > #pragma
> > > > > warning disable/enable 0618 for testing those. otherwise compiler
>
RE: [Lucene.Net] Is a Lucene.Net Line-by-Line Jave port needed?
Troy, What do you mean by "merging"? 2.9.4g is a superset of 2.9.4 and has * bux fixes like LUCENENET-414 * new features like LUCENENET-429, MemoryMappedDirectory(although not used yet) , PartiallyTrustedAppDomain tests * improvements like LUCENENET-427, LUCENENET-418, Refactoring of SupportClass * API changes like - StopAnalyzer(List stopWords) - Query.ExtractTerms(ICollection) - TopDocs.TotalHits, TopDocs.ScoreDocs * readibily-changes like replacing some abstract methods with Func<>, while(XXX.MoveNext())s with foreachs etc. Is it something like creating a 2.9.4 tag and replacing trunk with 2.9.4g? DIGY -Original Message- From: Troy Howard [mailto:thowar...@gmail.com] Sent: Friday, July 01, 2011 12:36 AM To: lucene-net-dev@lucene.apache.org Subject: Re: [Lucene.Net] Is a Lucene.Net Line-by-Line Jave port needed? DIGY - Re: Why do I wait.. That's mostly because I intend to make some deep changes, which would make merging the 2.9.4g branch back to trunk difficult. So, it's easier to merge those changes first. Also, I won't have enough time to make my changes until a little way in the future, but probably do have the time to put together another release, so I'll do that first because it fits with my work/life schedule. Thanks, Troy On Thu, Jun 30, 2011 at 1:19 PM, Digy wrote: > Michael, > You interpret the report as "whoever commits code wins"? But when I look at > it, I see "a lof of talk, no work". .Net community is not interested in > contributing. > I really don't understand what hinders people to work on Lucene.Net. As I > did for 2.9.4g, grab the code, do whatever you want on it and submit back. > If it doesn't fit to the project's direction it can still find a place in > contrib or in branch. All of the approaches can live side by side happily in > the Lucene.Net repository. > > Troy, > I also don't understand why do you wait for 2.9.4g? It is a *branch* and > has nothing to do with the trunk. It need not be an offical release and can > live in branch as a PoC. > > > As a result, I got bored to listen to "this should be done that way". What > I want to see is "I did it that way, should we continue with this". > > DIGY > > > > > -Original Message- > From: Troy Howard [mailto:thowar...@gmail.com] > Sent: Thursday, June 30, 2011 10:47 PM > To: lucene-net-dev@lucene.apache.org > Subject: Re: [Lucene.Net] Is a Lucene.Net Line-by-Line Jave port needed? > > Michael, > > I agree with everything you said. My point in saying "whoever commits code > wins" was to illustrate the reality of how and why the project has the > current form. > > Building consensus is difficult. It is an essential first step before we > can > do something like make a list of bit-sized pieces of work that others can > work on. > > This is why my real message of "Let's find a way to accommodate both" is so > important. It allows us to build consensus, so that we can settle on a > direction and structure our work. > > Until we accomplish that, it really is "whoever commits code wins", and > that > is an unhealthy and unmaintainable way to operate. > > From a technical perspective, your statements about the unit tests are > completely accurate. They really need a LOT of reworking. That's the very > first step before making any significant changes. Part of the problem is > that the tests themselves are not well written. The other part is that the > Lucene object model was not designed for testability, and it makes writing > good tests more difficult, and certain tests might not be possible. It will > be difficult to write good unit tests without re-structuring. The biggest > issue is the use of abstract classes with base behaviour vs interfaces or > fully abstracted classes. Makes mocking tough. This is the direction I was > going when I started the Lucere project. I'd like to start in on that work > after the 2.9.4g release. > > Thanks, > Troy > > > On Thu, Jun 30, 2011 at 12:04 PM, Michael Herndon < > mhern...@wickedsoftware.net> wrote: > > > I'd say that is all the more reasons that we need to work smarter and not > > harder. I'd also say thats a good reason to make sure we build consensus > > rather than just saying whoever commits code wins. > > > > And its a damn good reason to focus on the effort of growing the number > of > > contributors and lowing the barrier to submitting patches, breaking > things > > down into pieces that people would feel confident to work on without > > being overwhelmed by the complexity of Lucene.Net. > > > > There is a pretty big gap between Lu
RE: [Lucene.Net] Is a Lucene.Net Line-by-Line Jave port needed?
OK. Maybe I asked wrong question, Suppose I committed IsolatedStorageDirectory only to trunk. How would you merge this branch & trunk? DIGY. -Original Message- From: Troy Howard [mailto:thowar...@gmail.com] Sent: Sunday, July 03, 2011 12:28 AM To: lucene-net-dev@lucene.apache.org Subject: RE: [Lucene.Net] Is a Lucene.Net Line-by-Line Jave port needed? Yes. But if there are commits to trunk before that happens it's a merge. -T On Jul 2, 2011 1:53 PM, "Digy" wrote: > Troy, > > What do you mean by "merging"? 2.9.4g is a superset of 2.9.4 and has > * bux fixes like LUCENENET-414 > * new features like LUCENENET-429, MemoryMappedDirectory(although not used yet) , PartiallyTrustedAppDomain tests > * improvements like LUCENENET-427, LUCENENET-418, Refactoring of SupportClass > * API changes like > - StopAnalyzer(List stopWords) > - Query.ExtractTerms(ICollection) > - TopDocs.TotalHits, TopDocs.ScoreDocs > * readibily-changes like replacing some abstract methods with Func<>, while(XXX.MoveNext())s with foreachs > etc. > > Is it something like creating a 2.9.4 tag and replacing trunk with 2.9.4g? > > DIGY > > -Original Message- > From: Troy Howard [mailto:thowar...@gmail.com] > Sent: Friday, July 01, 2011 12:36 AM > To: lucene-net-dev@lucene.apache.org > Subject: Re: [Lucene.Net] Is a Lucene.Net Line-by-Line Jave port needed? > > DIGY - Re: Why do I wait.. That's mostly because I intend to make some deep > changes, which would make merging the 2.9.4g branch back to trunk difficult. > So, it's easier to merge those changes first. Also, I won't have enough time > to make my changes until a little way in the future, but probably do have > the time to put together another release, so I'll do that first because it > fits with my work/life schedule. > > Thanks, > Troy > > > On Thu, Jun 30, 2011 at 1:19 PM, Digy wrote: > >> Michael, >> You interpret the report as "whoever commits code wins"? But when I look at >> it, I see "a lof of talk, no work". .Net community is not interested in >> contributing. >> I really don't understand what hinders people to work on Lucene.Net. As I >> did for 2.9.4g, grab the code, do whatever you want on it and submit back. >> If it doesn't fit to the project's direction it can still find a place in >> contrib or in branch. All of the approaches can live side by side happily in >> the Lucene.Net repository. >> >> Troy, >> I also don't understand why do you wait for 2.9.4g? It is a *branch* and >> has nothing to do with the trunk. It need not be an offical release and can >> live in branch as a PoC. >> >> >> As a result, I got bored to listen to "this should be done that way". What >> I want to see is "I did it that way, should we continue with this". >> >> DIGY >> >> >> >> >> -Original Message- >> From: Troy Howard [mailto:thowar...@gmail.com] >> Sent: Thursday, June 30, 2011 10:47 PM >> To: lucene-net-dev@lucene.apache.org >> Subject: Re: [Lucene.Net] Is a Lucene.Net Line-by-Line Jave port needed? >> >> Michael, >> >> I agree with everything you said. My point in saying "whoever commits code >> wins" was to illustrate the reality of how and why the project has the >> current form. >> >> Building consensus is difficult. It is an essential first step before we >> can >> do something like make a list of bit-sized pieces of work that others can >> work on. >> >> This is why my real message of "Let's find a way to accommodate both" is so >> important. It allows us to build consensus, so that we can settle on a >> direction and structure our work. >> >> Until we accomplish that, it really is "whoever commits code wins", and >> that >> is an unhealthy and unmaintainable way to operate. >> >> From a technical perspective, your statements about the unit tests are >> completely accurate. They really need a LOT of reworking. That's the very >> first step before making any significant changes. Part of the problem is >> that the tests themselves are not well written. The other part is that the >> Lucene object model was not designed for testability, and it makes writing >> good tests more difficult, and certain tests might not be possible. It will >> be difficult to write good unit tests without re-structuring. The biggest >> issue is the use of abstract classes with base behaviour vs interfaces or >> fully abstracted classes. Makes mocking tough. This is the direction
RE: [Lucene.Net] Is a Lucene.Net Line-by-Line Jave port needed?
No no. It was just an example. As you already know, there are a lot of changes in contrib codes related with those API changes in Lucene.Net.2.9.4g core. Therefore, I see no option like merging other that copying. DIGY -Original Message- From: Troy Howard [mailto:thowar...@gmail.com] Sent: Sunday, July 03, 2011 1:53 AM To: lucene-net-dev@lucene.apache.org Subject: Re: [Lucene.Net] Is a Lucene.Net Line-by-Line Jave port needed? I'm not sure that I see a conflict. Are you referring to the use of generic Dictionary in IndexInput in 2.9.4g? That's the only point where I could see a possible problem, but generic dictionaries are supported on WP7, so it should be fine. In which case, the two should merge and compile correctly. Thanks, Troy On Sat, Jul 2, 2011 at 2:36 PM, Digy wrote: > OK. Maybe I asked wrong question, Suppose I committed > IsolatedStorageDirectory only to trunk. How would you merge this branch & > trunk? > > DIGY. > > -Original Message- > From: Troy Howard [mailto:thowar...@gmail.com] > Sent: Sunday, July 03, 2011 12:28 AM > To: lucene-net-dev@lucene.apache.org > Subject: RE: [Lucene.Net] Is a Lucene.Net Line-by-Line Jave port needed? > > Yes. But if there are commits to trunk before that happens it's a merge. > > -T > On Jul 2, 2011 1:53 PM, "Digy" wrote: > > Troy, > > > > What do you mean by "merging"? 2.9.4g is a superset of 2.9.4 and has > > * bux fixes like LUCENENET-414 > > * new features like LUCENENET-429, MemoryMappedDirectory(although not > used > yet) , PartiallyTrustedAppDomain tests > > * improvements like LUCENENET-427, LUCENENET-418, Refactoring of > SupportClass > > * API changes like > > - StopAnalyzer(List stopWords) > > - Query.ExtractTerms(ICollection) > > - TopDocs.TotalHits, TopDocs.ScoreDocs > > * readibily-changes like replacing some abstract methods with Func<>, > while(XXX.MoveNext())s with foreachs > > etc. > > > > Is it something like creating a 2.9.4 tag and replacing trunk with > 2.9.4g? > > > > DIGY > > > > -Original Message- > > From: Troy Howard [mailto:thowar...@gmail.com] > > Sent: Friday, July 01, 2011 12:36 AM > > To: lucene-net-dev@lucene.apache.org > > Subject: Re: [Lucene.Net] Is a Lucene.Net Line-by-Line Jave port needed? > > > > DIGY - Re: Why do I wait.. That's mostly because I intend to make some > deep > > changes, which would make merging the 2.9.4g branch back to trunk > difficult. > > So, it's easier to merge those changes first. Also, I won't have enough > time > > to make my changes until a little way in the future, but probably do have > > the time to put together another release, so I'll do that first because > it > > fits with my work/life schedule. > > > > Thanks, > > Troy > > > > > > On Thu, Jun 30, 2011 at 1:19 PM, Digy wrote: > > > >> Michael, > >> You interpret the report as "whoever commits code wins"? But when I look > at > >> it, I see "a lof of talk, no work". .Net community is not interested in > >> contributing. > >> I really don't understand what hinders people to work on Lucene.Net. As > I > >> did for 2.9.4g, grab the code, do whatever you want on it and submit > back. > >> If it doesn't fit to the project's direction it can still find a place > in > >> contrib or in branch. All of the approaches can live side by side > happily > in > >> the Lucene.Net repository. > >> > >> Troy, > >> I also don't understand why do you wait for 2.9.4g? It is a *branch* and > >> has nothing to do with the trunk. It need not be an offical release and > can > >> live in branch as a PoC. > >> > >> > >> As a result, I got bored to listen to "this should be done that way". > What > >> I want to see is "I did it that way, should we continue with this". > >> > >> DIGY > >> > >> > >> > >> > >> -Original Message- > >> From: Troy Howard [mailto:thowar...@gmail.com] > >> Sent: Thursday, June 30, 2011 10:47 PM > >> To: lucene-net-dev@lucene.apache.org > >> Subject: Re: [Lucene.Net] Is a Lucene.Net Line-by-Line Jave port needed? > >> > >> Michael, > >> > >> I agree with everything you said. My point in saying "whoever commits > code > >> wins" was to illustrate the reality of how and why the project has the > >> current form. > >> > >> B
RE: [Lucene.Net] Is a Lucene.Net Line-by-Line Jave port needed?
And just for this hard work I removed the obsolete Similarity.Net. DIGY -Original Message- From: Troy Howard [mailto:thowar...@gmail.com] Sent: Sunday, July 03, 2011 1:53 AM To: lucene-net-dev@lucene.apache.org Subject: Re: [Lucene.Net] Is a Lucene.Net Line-by-Line Jave port needed? I'm not sure that I see a conflict. Are you referring to the use of generic Dictionary in IndexInput in 2.9.4g? That's the only point where I could see a possible problem, but generic dictionaries are supported on WP7, so it should be fine. In which case, the two should merge and compile correctly. Thanks, Troy On Sat, Jul 2, 2011 at 2:36 PM, Digy wrote: > OK. Maybe I asked wrong question, Suppose I committed > IsolatedStorageDirectory only to trunk. How would you merge this branch & > trunk? > > DIGY. > > -Original Message- > From: Troy Howard [mailto:thowar...@gmail.com] > Sent: Sunday, July 03, 2011 12:28 AM > To: lucene-net-dev@lucene.apache.org > Subject: RE: [Lucene.Net] Is a Lucene.Net Line-by-Line Jave port needed? > > Yes. But if there are commits to trunk before that happens it's a merge. > > -T > On Jul 2, 2011 1:53 PM, "Digy" wrote: > > Troy, > > > > What do you mean by "merging"? 2.9.4g is a superset of 2.9.4 and has > > * bux fixes like LUCENENET-414 > > * new features like LUCENENET-429, MemoryMappedDirectory(although not > used > yet) , PartiallyTrustedAppDomain tests > > * improvements like LUCENENET-427, LUCENENET-418, Refactoring of > SupportClass > > * API changes like > > - StopAnalyzer(List stopWords) > > - Query.ExtractTerms(ICollection) > > - TopDocs.TotalHits, TopDocs.ScoreDocs > > * readibily-changes like replacing some abstract methods with Func<>, > while(XXX.MoveNext())s with foreachs > > etc. > > > > Is it something like creating a 2.9.4 tag and replacing trunk with > 2.9.4g? > > > > DIGY > > > > -Original Message- > > From: Troy Howard [mailto:thowar...@gmail.com] > > Sent: Friday, July 01, 2011 12:36 AM > > To: lucene-net-dev@lucene.apache.org > > Subject: Re: [Lucene.Net] Is a Lucene.Net Line-by-Line Jave port needed? > > > > DIGY - Re: Why do I wait.. That's mostly because I intend to make some > deep > > changes, which would make merging the 2.9.4g branch back to trunk > difficult. > > So, it's easier to merge those changes first. Also, I won't have enough > time > > to make my changes until a little way in the future, but probably do have > > the time to put together another release, so I'll do that first because > it > > fits with my work/life schedule. > > > > Thanks, > > Troy > > > > > > On Thu, Jun 30, 2011 at 1:19 PM, Digy wrote: > > > >> Michael, > >> You interpret the report as "whoever commits code wins"? But when I look > at > >> it, I see "a lof of talk, no work". .Net community is not interested in > >> contributing. > >> I really don't understand what hinders people to work on Lucene.Net. As > I > >> did for 2.9.4g, grab the code, do whatever you want on it and submit > back. > >> If it doesn't fit to the project's direction it can still find a place > in > >> contrib or in branch. All of the approaches can live side by side > happily > in > >> the Lucene.Net repository. > >> > >> Troy, > >> I also don't understand why do you wait for 2.9.4g? It is a *branch* and > >> has nothing to do with the trunk. It need not be an offical release and > can > >> live in branch as a PoC. > >> > >> > >> As a result, I got bored to listen to "this should be done that way". > What > >> I want to see is "I did it that way, should we continue with this". > >> > >> DIGY > >> > >> > >> > >> > >> -Original Message- > >> From: Troy Howard [mailto:thowar...@gmail.com] > >> Sent: Thursday, June 30, 2011 10:47 PM > >> To: lucene-net-dev@lucene.apache.org > >> Subject: Re: [Lucene.Net] Is a Lucene.Net Line-by-Line Jave port needed? > >> > >> Michael, > >> > >> I agree with everything you said. My point in saying "whoever commits > code > >> wins" was to illustrate the reality of how and why the project has the > >> current form. > >> > >> Building consensus is difficult. It is an essential first step before we > >> can > >> do something like make a list of bit-sized pieces
