Re: Having a default constructor in Analyzers

On Feb 7, 2010, at 5:32 PM, Sanne Grinovero wrote: > Does it make sense to use different values across the same > application? Obviously in the unlikely case you want to threat > different indexes in a different way, but does it make sense when > working all on the same index? I think it entirel

Lucene Query Parser Syntax document

Earlier I had linked to http://lucene.apache.org/java/docs/queryparsersyntax.html in my product manual. That no longer works. Searching I found that the document is per release. Not sure when that changed, but having found it at http://lucene.apache.org/java/2_3_2/queryparsersyntax.html I not

Re: SegmentInfos extends Vector

IIRC: The early implementation of Vector did not extend AbstractList and thus did not have remove. On Feb 28, 2010, at 8:04 AM, Shai Erera wrote: > Why do you say remove was unsupported before? I don't see it in the class's > impl. It just inherits from Vector and so remove is supported by inhe

Re: Lucene Query Parser Syntax document

hetaphi.de > >> -Original Message- >> From: DM Smith [mailto:dmsmith...@gmail.com] >> Sent: Sunday, February 28, 2010 2:12 PM >> To: java-dev@lucene.apache.org >> Subject: Lucene Query Parser Syntax document >> >> Earlier I had linked to >> h

Re: [DISCUSS] Do away with Contrib Committers and make core committers

My 2 cents as one who has no aspirations of ever being a committer. I think with the pending re-org of contrib and the value of contrib, it doesn't make much sense to have the distinction between core and contrib let alone for contributors. Regarding the former low bar, either prune the list

Re: Proposal about Version API "relaxation"

I like the concept of version, but I'm concerned about it too. The current Version mechanism allows one to use more than one Version in their code. Imagine that we are at 3.2 and one was unable to upgrade to a most version for a particular feature. Let's also suppose that at 3.2 a new feature

Re: Proposal about Version API "relaxation"

On 04/14/2010 09:13 AM, Robert Muir wrote: Its not sidetracked at all. there seem to be more compelling alternatives to achieve the same thing, so we should consider alternative solutions, too. Maybe have the index store the version(s) and use that when constructing a reader or writer? Given en

Re: Proposal about Version API "relaxation"

what technologies are used to do searches. If the latest Lucene jar does not let me use Version (or some other mechanism) to maintain compatibility with an older index, the user will have to re-index. Or I can forgo any future upgrades with Lucene. Neither are very palatable. -- DM Smith

Re: Proposal about Version API "relaxation"

On 04/15/2010 01:50 PM, Earwin Burrfoot wrote: First, the index format. IMHO, it is a good thing for a major release to be able to read the prior major release's index. And the ability to convert it to the current format via optimize is also good. Whatever is decided on this thread should take th

Re: Proposal about Version API "relaxation"

On 04/15/2010 03:04 PM, Earwin Burrfoot wrote: BTW Earwin, we can come up w/ a migrate() method on IW to accomplish manual migration on the segments that are still on old versions. That's not the point about whether optimize() is good or not. It is the difference between telling the customer to r

Re: Proposal about Version API "relaxation"

On 04/15/2010 03:12 PM, Earwin Burrfoot wrote: On Thu, Apr 15, 2010 at 23:07, DM Smith wrote: On 04/15/2010 03:04 PM, Earwin Burrfoot wrote: BTW Earwin, we can come up w/ a migrate() method on IW to accomplish manual migration on the segments that are still on old versions. That&#

Re: Proposal about Version API "relaxation"

On 04/15/2010 03:25 PM, Shai Erera wrote: We should create a migrate() API on IW which will touch just those segments and not incur a full optimize. That API can also be used for an offline migration tool, if we decide that's what we want. What about an index that has already called optimize

Re: Proposal about Version API "relaxation"

On Apr 15, 2010, at 4:50 PM, Shai Erera wrote: > Robert ... I'm sorry but changes to Analyzers don't *force* people to > reindex. They can simply choose not to use the latest version. They can > choose not to upgrade a Unicode version. They can copy the entire Analyzer > code to match their ne

Re: Proposal about Version API "relaxation"

sure I understand. Is JFlex used by every tokenizer? > > Alternatively, we can think of writing an ICU analyzer/tokenizer, but we're > still using JFlex, so I don't know how much control we have on that ... Robert has already started one. (1488 I think). > > Shai >

Document proximity

cally consider that adjacent documents are flowing unless some token in the doucment interrupts the flow. In this case, search would return a compound document as a hit. Thanks, DM Smith - To unsubscribe, e-mail: [EMAIL PROT

Re: Document proximity

+0200, Andrzej Bialecki <[EMAIL PROTECTED]> wrote: > DM Smith wrote: > > Hi, > > > > I hope I am posting to the right list. > > Yes. > > > > > We (sword and jsword at crosswire.org) are indexing bibles with each > > verse becoming a document

Re: Lucene Benchmark - Wintel faster than Unix (?)

At home, running a dual boot WinXPsp2 and Fedora Core 3, I found that FC3 was faster. At least initially. The difference was staggering. Indexing a Bible, creating one doc per verse and storing the verse reference but not storing the verse, took a couple of minutes under FC3 and 2.5+ hours under

Re: svn commit: r164695 - in /lucene/java/trunk: CHANGES.txt src/java/org/apache/lucene/search/Hit.java src/java/org/apache/lucene/search/HitIterator.java src/java/org/apache/lucene/search/Hits.java s

Erik Hatcher wrote: On Apr 26, 2005, at 2:38 PM, Daniel Naber wrote: On Tuesday 26 April 2005 02:21, [EMAIL PROTECTED] wrote: + public String toString() { +try { + return getDocument().toString(); +} catch (IOException e) { + return null; +} + } Wouldn't it be better here t

Re: Proposal for change to DefaultSimilarity's lengthNorm to fix "short document" problem

At crosswire.org we are using Lucene to index Bibles with each Bible having its own index and each verse in the Bible is a document in the index. So each document is short. Length depends upon the language of translation, but the lengths are from 2 to less than 100. In our case the existing bia

Re: IndexWriter and system properties

From the perspective of a user of Lucene: IMHO, having system properties for a third-party library is not good: 1) System properties are not explicit in the library's api. 2) System properties are applied non-local to the use of a library's api. 3) System properties represents global variables, no

Re: DO NOT REPLY [Bug 35838] New: - Java NIO patch against Lucene 1.9

I tried to use bugzilla to record the comment, but I haven't the id yet. See below for comment: On 7/23/05, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote: > DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG· > RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT >

Re: Lucene does NOT use UTF-8

Daniel Naber wrote: On Monday 29 August 2005 19:56, Ken Krugler wrote: "Lucene writes strings as a VInt representing the length of the string in Java chars (UTF-16 code units), followed by the character data." But wouldn't UTF-16 mean 2 bytes per character? That doesn't seem to be the

Re: Lucene does NOT use UTF-8.

Ken Krugler wrote: I think the VInt should be the numbers of bytes to be stored using the UTF-8 encoding. It is trivial to use the String methods identified before to do the conversion. The String(char[]) allocates a new char array. For performance, you can use the actual CharSet encoding c

Re: Version 1.9

On 9/18/05, Jeff Breidenbach <[EMAIL PROTECTED]> wrote: > > Putting on my Debian maintainer hat: > > 1) Does it make sense for Linux distributions to ship > Lucene 1.9, or simply wait for 2.0? (I'm thinking 2.0...) I think it should include what is available. If pre-2.0, it should be 1.4.3and

Re: Basic Question on Documents and File Format

Ashwin Satyanarayana wrote: Hello, I am new to Lucene. I was trying to use Lucene with TREC-6 Data. The dataset for TREC-6 used in 1997 contains many input files. Each input file hasmultiple documents (some files contain over 200 documents) tagged by DOCNO. The result given by Lucene to a qu

Lucene 1.9 Field implementation

I was looking at how compatible 1.9 is with 1.4.3 wrt my implementation. Turns out it works without problem. There were only three deprecations that would need to be taken care of to migrate to 2.0. When I looked into the changes that would need to be made to go to 2.0, I noticed an opportunity fo

Re: "Advanced" query language

One thing I like about the possibility of XML (as opposed to other syntax) is that I could create query templates and process them with XSLT. And I can do this client side and also in most modern browsers. - To unsubscribe, e-m

Re: NioFile cache performance

John Haxby wrote: Robert Engels wrote: Using a 4mb file (so I could be "guarantee" the disk data would be in the OS cache as well), the test shows the following results. Which OS? If it's Linux, what kernel version and distro? What hardware (disk type, controller etc). It's important

Re: NioFile cache performance

ibles. And the minimum hardware requirement is a Win98 laptop, which many of our user's have.) -Original Message- From: DM Smith [mailto:[EMAIL PROTECTED] Sent: Friday, December 09, 2005 7:07 AM To: java-dev@lucene.apache.org Subject: Re: NioFile cache performance John Haxby wro

Re: [jira] Commented: (LUCENE-486) Core Test should not have dependencies on the Demo code

I have a principle that I code by: The Principle of Least Surprise - Write code in such a way that it minimize surprises. It is surprising to me that test cases would have a dependency on demo code. IMHO, the dependency should be removed. Yesterday I installed lucene from jpackage using y

Re: Tree based BitSet (aka IntegerSet, DocSet...)

Andrzej Bialecki wrote: Paul Elschot wrote: On Saturday 28 January 2006 19:27, eks dev wrote: might be interesting: http://www.iis.uni-stuttgart.de/intset/ Another way to represent Bit(Integer)Set. Should outperform nicely BitSet or HashBitSet as far as iteration speed and memory is concern.

Re: 1.9 RC1

Not to get to far ahead, but what is the schedule relation between 1.9 and 2.0? What are the dependencies on releasing 2.0? Doug Cutting wrote: I'd like to push out a 1.9 release candidate in the next week or so. Are there any patches folks are really hoping to sneak into 1.9? If so, now's th

Re: 1.9 RC1

Erik Hatcher wrote: On Feb 15, 2006, at 9:11 AM, DM Smith wrote: Not to get to far ahead, but what is the schedule relation between 1.9 and 2.0? What are the dependencies on releasing 2.0? My understanding is that 2.0 will be 1.9 with all the deprecated API removed. Maybe there are other

Re: wildcard search with variable length

Andrzej Bialecki wrote: Tiago Silveira wrote: IMHO, using "cat cat?" or even "cat cat? cat??" is so simple that it doesn't justify keeping the old, undocumented, arguably incorrect behavior. I have a different view on this issue - IMHO treating "?" as "exactly one character" is counterint

Re: wildcard search with variable length

John Haxby wrote: Doug Cutting wrote: DM Smith wrote: Personally, I don't want an either/or. I want a both/and. Modern unix shells provide both/and, albeit with different syntax. I see this more as a feature request than an argument as to the usefulness or properness of either. Bot

Re: Lucene 1.9 RC1 release available

Erik Hatcher wrote: On Feb 25, 2006, at 3:24 PM, Daniel Naber wrote: On Freitag 24 Februar 2006 00:50, Doug Cutting wrote: Are these all modules that don't need external libs? So far as I know! I found another module that requires external libraries: regex. These are even defined in th

Re: Lucene 1.9-final release available

To ask the obvious question: When will 2.0 be released? I would favor an earlier release date so that there won't be much difference between 1.9 and 2.0 except what's stated below. Doug Cutting wrote: Release 1.9-final of Lucene is now available from: http://www.apache.org/dyn/closer.cgi/luce

Index compatibility question

I have just upgraded to 1.9-final and am now testing my use of it. One question regarding compatibility. Does 1.4.3 search 1.9-final built indexes? I find that 1.9 reads my 1.4.3 built indexes just fine. But not the other way around. -

Re: this == that

karl wettin wrote: The code is filled with string equality code using == rather than equals(). I honestly don't think it saves a single clock tick as the JIT takes care of it when the first line of code in the equals method is if (this == that) return true; If the strings are intern() then it

Re: J2ME

I have an application I'd like to move to J2ME which uses lucene for creating and searching indexes. I can get by with the capabilities of search. karl wettin wrote: On Sun, 2006-05-07 at 12:55 +0100, [EMAIL PROTECTED] wrote: Some what off topic, but I've started looking in to porting Luc

Lucene 2.0

Could someone enumerate what needs to be done before 2.0 is released. From following this thread, it was stated that 2.0 was 1.9 with deprecations removed. Recently it appears to be becoming much more than that. Personally, I'd like to see a 2.0 now and if there are changes then subsequent rel

Re: Lucene 2.0

Chris Hostetter wrote: : Could someone enumerate what needs to be done before 2.0 is released. : From following this thread, it was stated that 2.0 was 1.9 with : deprecations removed. : Recently it appears to be becoming much more than that. I believe Doug's suggestion was to hold off just l

JPackage was Re: [VOTE] 2.0 release this Friday?

I read the ReleaseTodo and saw a task to push to maven, but not to JPackage. Any possibility of adding a task to notify the JPackage folks of the release and perhaps in the future maintaining the package? Otis Gospodnetic wrote: +1 If you want, I can try doing this, but I'm likely going to ha

Re: Lucene and Java 1.5

Please don't move to Java 5. My reasons are simple (and some perhaps stem out of old information or misinformation): MacOS 9 does not run Java 1.5, which is one of my target platforms. Has Java 5 been ported to all target platforms? Java 5 has nice syntax sugar but no real substance other

Re: Lucene and Java 1.5

. In this case there is some level of control over the execution environment. My use is client side application and I don't have much control over the execution environment. I think it may be constructive to poll the lucene users mailing list as to what they need. -Original Message- F

Re: Lucene and Java 1.5

raries are reason enough to move. You can't get Sun to fix these old JDK issues, why should we be attempting to work around them. -Original Message- From: DM Smith [mailto:[EMAIL PROTECTED] Sent: Tuesday, May 30, 2006 8:52 AM To: java-dev@lucene.apache.org Subject: Re: Lucene and J

Re: Lucene and Java 1.5

Robert Engels wrote: If you can control them to run 1.4, you can probably control them to run 1.5. I cannot control my application's users to run Java 1.4. We moved from Java 1.3 to Java 1.4 only after all platforms our users were running had a Java 1.4 jvm available. We did make a conscio

Re: Lucene and Java 1.5

What features should be encouraged? discouraged? not allowed? For example, should annotations be used where possible? or is it purely optional? What about "static import"? I find that DoHicky.WHATS_IT a bit more revealing than WHATS_IT, as it tells me its origin. Should enhanced for loops b

Re: Lucene and Java 1.5

Erik Hatcher wrote: On May 30, 2006, at 11:45 AM, DM Smith wrote: By stating that I needed to run on Mac OS 9, this also implies that I need to run on OSX prior to Tiger (10.4) which does not have Java 5 and according to everything that I read, won't. OSX 10.3 does not seem li

Re: Lucene and Java 1.5

is something new to say, I'll be quiet ;) -Original Message- From: Erik Hatcher [mailto:[EMAIL PROTECTED] Sent: Tuesday, May 30, 2006 11:55 AM To: java-dev@lucene.apache.org Subject: Re: Lucene and Java 1.5 On May 30, 2006, at 11:45 AM, DM Smith wrote: By stating that I needed

Re: svn commit: r410680 - in /lucene/java/branches/lucene_2_0: CHANGES.txt src/jsp/results.jsp

Just my opinion based on working with SVN with an entirely different development model: Trunk is production and branches are different people individual or collaborative efforts, with one branch for maintenance changes. When enough maintenance changes are ready for a release, we merge it into

Re: Results (Re: Survey: Lucene and Java 1.4 vs. 1.5)

Just got back from a long weekend vacation without any net access. Talk about withdrawal:) I have just gotten through reading this entire thread... Whew. On Jun 19, 2006, at 8:48 PM, Robert Engels wrote: People making these arguments against 1.5 sound really ill- informed, or lazy. Neith

Re: Results (Re: Survey: Lucene and Java 1.4 vs. 1.5)

I would like to suggest that a central core Lucene be identified and that core be maintained as compatible for Java 1.4. It has also been stated that J2ME compatibility is a future goal. It would be nice to consider that in defining a central core. (BTW, there are two J2ME standards, one is a

Re: Results (Re: Survey: Lucene and Java 1.4 vs. 1.5)

On 6/20/06, Otis Gospodnetic <[EMAIL PROTECTED]> wrote: Sorry, for some reason my Yahoo email doesn't prepend ">" on replies, so I'll use "OG" for my lines. - Original Message From: Dan Armbrust <[EMAIL PROTECTED]> Also, at my place of employment we have about 40,000 desktop comput

Re: Results (Re: Survey: Lucene and Java 1.4 vs. 1.5)

This poll does not indicate anything about Lucene. It is open to anyone who goes to quimble and searches on Java. On 6/16/06, Otis Gospodnetic <[EMAIL PROTECTED]> wrote: It looks like I would have won a beer had anyone wagered me. 1.5 IS the Java version that the majority Lucene users use, not

Re: Results (Re: Survey: Lucene and Java 1.4 vs. 1.5)

On 6/20/06, Yonik Seeley <[EMAIL PROTECTED]> wrote: In any case, there is still GCJ too. If GCJ supported 1.5, and we could make a 1.4 library with Retrotranslator, that should cover most users, right? I just took a look at GCJ again. If I am not mistaken: future support for 1.5 in gcj is

Re: Results (Re: Survey: Lucene and Java 1.4 vs. 1.5)

On Jun 20, 2006, at 5:09 PM, Otis Gospodnetic wrote: - Original Message From: DM Smith On 6/20/06, Otis Gospodnetic wrote: Sorry, for some reason my Yahoo email doesn't prepend ">" on replies, so I'll use "OG" for my lines. In my situ

Re: Results (Re: Survey: Lucene and Java 1.4 vs. 1.5)

On Jun 20, 2006, at 5:21 PM, Yonik Seeley wrote: On 6/20/06, DM Smith <[EMAIL PROTECTED]> wrote: > In any case, there is still GCJ too. If GCJ supported 1.5, and we > could make a 1.4 library with Retrotranslator, that should cover most > users, right? If I am not m

Re: Core vs Contrib

I think that it might be good to define 3 levels: fundamental - what all programs probably will use useful - what many programs might use and contrib - mostly examples and code that is not quite ready to be classed as useful On Jun 16, 2006, at 6:03 PM, Chris Hostetter wrote: Are there any

Re: Results (Re: Survey: Lucene and Java 1.4 vs. 1.5)

On Jun 20, 2006, at 6:43 PM, Yonik Seeley wrote: On 6/20/06, DM Smith <[EMAIL PROTECTED]> wrote: The problem we have is trying to explain to users how to install java in order to get our application to work. Ahh... if you didn't already have a large code base, I'd suggest tr

Re: Core vs Contrib

On Jun 21, 2006, at 3:43 AM, Chris Hostetter wrote: : I think that it might be good to define 3 levels: : fundamental - what all programs probably will use : useful - what many programs might use : contrib - mostly examples and code that is not quite ready to be : classed as useful Those thre

Re: Results (Re: Survey: Lucene and Java 1.4 vs. 1.5)

ginal Message- From: DM Smith [mailto:[EMAIL PROTECTED] Sent: Tuesday, June 20, 2006 5:24 PM To: java-dev@lucene.apache.org Subject: Re: Results (Re: Survey: Lucene and Java 1.4 vs. 1.5) On Jun 20, 2006, at 5:21 PM, Yonik Seeley wrote: On 6/20/06, DM Smith <[EMAIL PROTECTED]> wrote:

Re: Results (Re: Survey: Lucene and Java 1.4 vs. 1.5)

leDesktop 3.0 (which includes Lucene 2.1). Certainly seems like a packaging/marketing issue for you. Your users would not know if they were running Lucene 1.4, 1.9 2.0 or 2.1, nor would they care. -Original Message- From: DM Smith [mailto:[EMAIL PROTECTED] Sent: Tuesday, June 20, 2006

Re: Results (Re: Survey: Lucene and Java 1.4 vs. 1.5)

ferent. Our users want the latest and greatest BibleDesktop (at any rate, that's what we tell ourselves). Lucene is immaterial to them. In the meantime, maybe the good lord will see fit to perform some miracle and upgrade your user's systems. I would like that very much! -O

Re: Core vs Contrib

Otis, I should have taken a closer look before I made my comment. I have just now. So never mind. DM On 6/21/06, Otis Gospodnetic <[EMAIL PROTECTED]> wrote: Chris, Judging from a cursory look at LUCENE-406, that should be in the core (my reasoning was: well, if it's simply the direct opposite

Bug in BooleanScorer2

Matchers; } It complains about the calls to doc(), with the following error message: The method doc is defined in an inherited type and in an enclosing scope. Not sure what the solution should be: this.doc(); BooleanScorer2.this.doc(); or super.doc(); If I did, I'd send a patch. -- DM Smith

Re: Results (Re: Survey: Lucene and Java 1.4 vs. 1.5)

On 6/21/06, Otis Gospodnetic <[EMAIL PROTECTED]> wrote: Hi, - Original Message From: DM Smith <[EMAIL PROTECTED]> On Jun 21, 2006, at 7:52 AM, Grant Ingersoll wrote: > This sounds reasonable to me... OG: It sounded reasonable to me, too. I don't quite understan

Re: Bug in BooleanScorer2

On 6/21/06, Chris Hostetter <[EMAIL PROTECTED]> wrote: : Not sure what the solution should be: I haven't looed at the code so i'm not sure ... but my first thought would be to try both this.doc() and BooleanScorer2.this.doc(), and see which one passes all the unit tests. Of course, if both of

Re: Bug in BooleanScorer2

On 6/21/06, Chris Hostetter <[EMAIL PROTECTED]> wrote: : > I haven't looed at the code so i'm not sure ... but my first thought would : > be to try both this.doc() and BooleanScorer2.this.doc(), and see which one : > passes all the unit tests. Of course, if both of them pass the unit : > tests

Re: Results (Re: Survey: Lucene and Java 1.4 vs. 1.5)

On Jun 22, 2006, at 4:31 AM, John Haxby wrote: DM Smith wrote: Generally open source projects have a policy to change as little of the file as possible, only changing what is necessary. Hmmm. Necessary by what criterion? Necessary to make, say, Lucene exploit the new interator

Re: Results (Re: Survey: Lucene and Java 1.4 vs. 1.5)

On 6/22/06, John Haxby <[EMAIL PROTECTED]> wrote: DM Smith wrote: > I simply meant that the change that is being made should be done in > such a way that one applying the patch can readily see what is being > changed. The most common case of unnecessary change is that of > wh

Re: Results (Re: Survey: Lucene and Java 1.4 vs. 1.5)

On 6/22/06, Doug Cutting <[EMAIL PROTECTED]> wrote: DM Smith wrote: > In an earlier note, I suggested that there needs to be guidance as to how > Java 5 constructs are to be incorporated into code, contrib and core. > (Sooner or later, core will change to Java 5) Or does anythi

Re: Results (Re: Survey: Lucene and Java 1.4 vs. 1.5)

On Jun 22, 2006, at 5:46 PM, Doug Cutting wrote: DM Smith wrote: One of the things I liked about 2.0 was that 1.9 was a bridge to it from 1.4.3 via deprecations. It made migration fairly straightforward. I would like to see this going forward to 2.1. If so there needs to be some thought

Re: Java 1.5 (was ommented: (LUCENE-565) Supporting deleteDocuments in IndexWriter (Code and Performance Results Provided))

Otis, First let me say, I don't want to rehash the arguments for or against Java 1.5. We can all go back and read the last two major threads on the issue. I don't think there is anything new to say. However, I think statements like: "no strong arguments" (I think the

Re: Java 1.5 (was ommented: (LUCENE-565) Supporting deleteDocuments in IndexWriter (Code and Performance Results Provided))

think it is going to come in 2 parts: 1) It supports all the new language features of Java 1.5. 2) It has an implementation of all the new classes and methods that Lucene uses. For me the test is that it is released for MacOSX. With these three things, I'd be happy :) DM Smith, sti

Re: Java 1.5 (was ommented: (LUCENE-565) Supporting deleteDocuments in IndexWriter (Code and Performance Results Provided))

On Jul 8, 2006, at 12:56 PM, Chuck Williams wrote: I prefer to contribute to Lucene, but my workload simply does not allow time to be spent on backporting. I'll stand by my offer to do the backporting when it is possible and does not do violence to the implementation. I'd prefer to wait

Re: Java 1.5 (was ommented: (LUCENE-565) Supporting deleteDocuments in IndexWriter (Code and Performance Results Provided))

On Jul 11, 2006, at 12:17 AM, Daniel John Debrunner wrote: Doug Cutting wrote: Since GCJ is effectively available on all platforms, we could say that we will start accepting 1.5 features when a GCJ release supports those features. Does that seem reasonable? Seems potentially a little s

Re: Java 1.5 (was ommented: (LUCENE-565) Supporting deleteDocuments in IndexWriter (Code and Performance Results Provided))

On Jul 11, 2006, at 3:51 AM, Doug Cutting wrote: Andi Vajda wrote: I'd be interested in doing this but what is it that we're after in 'supporting gcj' actually ? I think it would sufficient to: 1. Compile only .jar and .class with gcj (not .java). 2. Pass all unit tests on a single platfor

Re: System Requirements

On Dec 9, 2006, at 9:27 AM, Grant Ingersoll wrote: Do we claim to support J2ME? I don't think so. I think that J2ME is a subset of Java 1.3. Personally, I'd like to see support for it even if it were a limited subset of Lucene. Perhaps one that could search a lucene index. --

Re: [VOTE] release Lucene 2.1

I've been reading this thread and here is my take as I will be updating jpackage for a 2.1 release. The content of a binary distribution differs widely as to what is included in it. It obviously needs to have one or more jar files that represent the product. Beyond that I have never really

Re: Modularization (was: Re: New flexible query parser)

question of the oobe for reviewers, today, it is what does Lucene-core.jar do. With more jars it would be what does this core collection of jars do or what does lucene-esssentials. -- DM Smith - To unsubscribe,

Re: Is TopDocCollector's collect() implementation correct?

On Mar 26, 2009, at 6:55 AM, Michael McCandless wrote: think we need to deprecate HC, in favor of MRHC (or if we can think of a better name... ResultCollector?). I like your suggestion for the name. - To unsubscribe, e-mai

Re: [jira] Commented: (LUCENE-1575) Refactoring Lucene collectors (HitCollector and extensions)

On Apr 1, 2009, at 5:29 AM, Shai Erera (JIRA) wrote: [ https://issues.apache.org/jira/browse/LUCENE-1575?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12694443 #action_12694443 ] Shai Erera commented on LUCENE-1575: ---

Re: ArabicAnalyzer

nce. The code is released under Apache 2.0 license. And I would be very happy if you include it with the code tree. Sounds super. Do you know if it will handle Farsi as well? -- DM Smith

Re: ArabicAnalyzer

don't know really... but it shouldn't be hard to support it. --- On Sun, 5/3/09, DM Smith wrote: From: DM Smith Subject: Re: ArabicAnalyzer To: java-dev@lucene.apache.org Date: Sunday, May 3, 2009, 4:05 AM On May 2, 2009, at 6:43 PM, Ahmed Al-Obaidy wrote: I've wrote a simpl

Re: [jira] Commented: (LUCENE-1629) contrib intelligent Analyzer for Chinese

I'd prefer it to stay 1.4 for now and would be willing to make the change, if needed. -- DM On May 7, 2009, at 3:04 PM, Michael McCandless (JIRA) wrote: [ https://issues.apache.org/jira/browse/LUCENE-1629?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommen

Re: Lucene's default settings & back compatibility

On May 18, 2009, at 11:31 PM, Robert Muir wrote: I am curious about this, do you think its a better default because it avoids the max boolean clauses problem? or because for a lot of these scoring doesn't make much sense anyway? I ran tests on a pretty big index, you pay a price for the co

Re: Lucene's default settings & back compatibility

On May 19, 2009, at 6:39 AM, Michael McCandless wrote: On Mon, May 18, 2009 at 8:51 PM, Yonik Seeley wrote: On Mon, May 18, 2009 at 5:06 PM, Michael McCandless wrote: * StopFilter should enable position increments by default Is this one an actual improvement in the general case? A query o

Re: Lucene's default settings & back compatibility

On May 19, 2009, at 7:45 AM, Michael McCandless wrote: On Tue, May 19, 2009 at 6:47 AM, DM Smith wrote: It is common in my application, a Bible program, that indexes each verse (think of a verse as a numbered sentence) as a separate document. We index everything, including words that

Re: Lucene's default settings & back compatibility

I like the idea of settings however it is implemented. With the blurring of core and contrib in the repackaging of Lucene, the issue of backward compatibility becomes more difficult. (maybe, I'm imagining problems where they don't exist.) My concern with any of these mechanisms: codifying p

Re: Lucene's default settings & back compatibility

On May 21, 2009, at 7:17 AM, Michael McCandless wrote: 1) Default settings can change; we will always choose defaults based on "latest & greatest for new users". This only affects "runtime behavior". EG in 2.9, when sorting by field you won't get scores by default. When we do th

Re: SegmentReader instantiation

Michael McCandless wrote: On Thu, May 21, 2009 at 10:53 AM, Earwin Burrfoot wrote: I agree we should probably remove it, unless there are users relying on this. Maintaining side-by-side sources is difficult with time. As I said in the initial message, this feature introduces no run

Re: Lucene's default settings & back compatibility

Michael McCandless wrote: On Thu, May 21, 2009 at 8:24 AM, DM Smith wrote: On May 21, 2009, at 7:17 AM, Michael McCandless wrote: 1) Default settings can change; we will always choose defaults based on "latest & greatest for new users". This only affects "

Re: Lucene's default settings & back compatibility

Michael McCandless wrote: On Thu, May 21, 2009 at 12:19 PM, Robert Muir wrote: even as simple as changing default stopword list for some analyzer could be an issue, if the user doesn't re-index in response to that change. OK, right. So say we forgot to include "the" in the default En

Re: Lucene's default settings & back compatibility

Yonik Seeley wrote: On Fri, May 22, 2009 at 1:22 PM, Michael McCandless wrote: (That said, unrelated to this discussion, I would actually like to record per-segment which version of Lucene wrote the segment; this would be very helpful when debugging issues like LUCENE-1474 where I need to kn

Re: Lucene's default settings & back compatibility

Michael McCandless wrote: On Fri, May 22, 2009 at 12:52 PM, Marvin Humphrey wrote: when working on 3.1 if we make some great improvement, I'd like new users in 3.1 to see the improvement by default. Sounds like an argument for more frequent major releases. Yeah. Or "rebrandin

Re: Lucene's default settings & back compatibility

Marvin Humphrey wrote: I feel the opposite: I'd like new users to see improvements by default, and users that require strict back-compate to ask for that. By "strict back-compat", do you mean "people who would like their search app to not fail silently"? ;) A "new user" who follows your a

Re: Lucene's default settings & back compatibility

Michael McCandless wrote: On Fri, May 22, 2009 at 2:27 PM, DM Smith wrote: Marvin Humphrey wrote: I feel the opposite: I'd like new users to see improvements by default, and users that require strict back-compate to ask for that. By "strict back-compat", do y

Re: Lucene's default settings & back compatibility

s to such unfavorable results? Yes, we all sit here and say "well that's not a fair review because you didn't properly tune Lucene", yet, this kind of thing happens all the time. If Lucene had better defaults out of the box it'd reduce how often that happens. Mike On F

Re: Lucene's default settings & back compatibility

Earwin Burrfoot wrote: 4. [Maybe?] Allow certain limited changes that will require source code changes in your app on upgrading to a new minor release: adding a new method to an interface, adding a new abstract method to an abstract class, renaming of deprecated methods. Yaho

  1   2   3   >