Vector

from multiple threads?! Even Sun recommends Collection.synchronizedList over Vector when thread safty is an issue. I belive that replaced with Linked- and ArrayLists it could save a whole bunch of ticks at heavy load. ---

Re: Vector

a BooleanQuery from multiple threads?! Even Sun recommends Collection.synchronizedList over Vector when thread safty is an issue. I belive that replaced with Linked- and ArrayLists it could save a whole bunch of tick

Re: Vector

On Sat, 2006-05-06 at 03:28 -0400, Erik Hatcher wrote: On May 6, 2006, at 2:29 AM, karl wettin wrote: > > > There are a couple of Vector:s in the code. Is it really necessary to > > use this expensive thread safe artifact from the dark ages? > > +1 > > Does anyone have any numbers on the perform

Re: Vector

On May 6, 2006, at 3:40 AM, karl wettin wrote: On Sat, 2006-05-06 at 03:28 -0400, Erik Hatcher wrote: On May 6, 2006, at 2:29 AM, karl wettin wrote: There are a couple of Vector:s in the code. Is it really necessary to use this expensive thread safe artifact from the dark ages? +1 Does an

Re: Vector

On 5/6/06, karl wettin <[EMAIL PROTECTED]> wrote: There are a couple of Vector:s in the code. Is it really necessary to use this expensive thread safe artifact from the dark ages? I've wondered that myself ... seeing "Vector" in the code does hurt my eyes a little :-) I

Re: Vector

I think most of Vector (or Hashtable) references are leftovers from the pre-Java Collections era, that's all. I doubt we'd be able to get much juice out of move unsynchronized Java Collections, although I'd like to see them for the same reason as Yonik. Otis - Original Me

Re: Vector

On Sat, 2006-05-06 at 08:55 -0700, Otis Gospodnetic wrote: > I doubt we'd be able to get much juice out of move > unsynchronized Java Collections I might be the only one here that counts every wasted tick? :) But it is not the synchronization I think is the big thief. A LinkedList could do the j

Re: Vector

--- karl wettin <[EMAIL PROTECTED]> wrote: ... > Even Sun recommends Collection.synchronizedList over > Vector when thread > safty is an issue. > > I belive that replaced with Linked- and ArrayLists > it could save a whole > bunch of ticks at heavy load. Changin

Re: Vector

We have done this two years ago, for Lucene 1.2. The major challenge was the Floating points and a few classes. (We used this pack http://mywebpages.comcast.net/ohommes/MathFP/) As u said J2ME has a very limited API for data structures. I'm not sure there is need for all the classes of Lucene to

Re: Vector

Hi, A few months ago, I did some benchmarking on file reading operations, not for the collection classes, I'm affraid. I wrote a couple of lines to see which method of reading files would perform better than the others(XP 1Gb mem, P4 3.19Hhz, java 1.4.2). I experimented on TREC collection. The att

Re: Vector

On Sat, 2006-05-06 at 09:40 +0200, karl wettin wrote: > > There are a couple of Vector:s in the code. Is it really > necessary to use this expensive thread safe artifact from the dark > ages? > The question is what needs and not needs to be synchronized. I take it > nothing needs to, but I'm not

Re: Vector

On 5/9/06, karl wettin <[EMAIL PROTECTED]> wrote: Did anybody know what needs to be synchronized and what does not need to be synchronized? Needs to be considered on a case-by-case basis IMO. Should I summarize the uses and post it here for discussion? Sure! -Yonik http://incubator.apache.

Re: Vector

here for > > discussion? > Sure! Here we go. I think it it safe to go ArrayList on all but RAMFile. The IndexWriter is already synchronized, right? StandardTokenizer: private java.util.Vector jj_expentries Document: List fields = new Vector(); IndexWriter: addIndexes(

Re: Vector

for sure, here are my comments. > StandardTokenizer: > private java.util.Vector jj_expentries If the standard analyzer is not thread safe, does this make sense? Looks genereted in my eyes. Did not look at the code. > > Document: > List fields = new Vector(); ArrayList. People don'

Re: Vector

ent for a couple of minutes. > > > > StandardTokenizer: > > private java.util.Vector jj_expentries > > If the standard analyzer is not thread safe, does this make sense? Looks > genereted in my eyes. Did not look at the code. > > > > > Document: >

J2ME (was: Vector)

On Sun, 2006-05-07 at 12:55 +0100, [EMAIL PROTECTED] wrote: > > Some what off topic, but I've started looking in to porting Lucene to > > J2ME (that leaves me with only pre-JCF collections and no floats). I > > have absolutely no idea what to use it for, but imagine something in the > > lines of d

SegmentInfos extends Vector

Hi What's the reason SegmentInfos extends Vector rather than say ArrayList? Do we need the synchronization around it which Vector provides? Shai

Re: J2ME (was: Vector)

ld be performed by the library I mentioned before (There is also one library in java.net, it might be the same though). -Replace all non-J2ME classes, with their equivalent ones (either with Vector/Hashtable or your own) As far as remember, there is no file operations in MIDP 2.0. You may want to check

Vector and Hashtable usage

I noticed that Vector and Hashtable are fairly widely used in Lucene both within classes and in their API. Looking at it, it appears that synchronization is inconsistent and that the classes were used more as a collection rather than for its sync. For example, I frequently see something

RE: SegmentInfos extends Vector

I think this is historically. I have seen this in my big 3.0 generification patches, too. But I did not wanted to change it as Vector has other allocation schema than ArrayList. But maybe we should simply change it, it’s a package-private class, right? But in general subclassing those

Re: SegmentInfos extends Vector

a Map-like interface, but perhaps other code needs things ordered (which is why we can keep a TreeMap inside, or LinkedHahsMap). That's a great example to why it should have its own API. The Lucene code usually calls SegmentInfos.info(int), but some places call get(int) (which is inherited from

RE: SegmentInfos extends Vector

phi.de eMail: u...@thetaphi.de From: Shai Erera [mailto:ser...@gmail.com] Sent: Sunday, February 28, 2010 1:20 PM To: java-dev@lucene.apache.org Subject: Re: SegmentInfos extends Vector Yes that's what I've been thinking as well - SegmentInfos should have a segments-related

Re: SegmentInfos extends Vector

8213 Bremen > > http://www.thetaphi.de > > eMail: u...@thetaphi.de > > > > *From:* Shai Erera [mailto:ser...@gmail.com] > *Sent:* Sunday, February 28, 2010 1:20 PM > > *To:* java-dev@lucene.apache.org > *Subject:* Re: SegmentInfos extends Vector > > > >

RE: SegmentInfos extends Vector

would have done that before, his code was broken either way (this is one problem of exposing the List interface as done by Vector? I just try to resume what the options are. But backwards compatibility would be broken also, if somebody would call a Vector-method like elementAt(int). So implementing

RE: SegmentInfos extends Vector

xtends Vector I would rather avoid implementing List .. we should implement Iterable for sure, but I'd like to keep the API open either iterating in-order or getting a particular SegmentInfo. Another thing, I haven't seen anywhere that remove is called. In general I don't like to i

Re: SegmentInfos extends Vector

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 inheritance. Since the class is public, someone may have called it. Even if we change the class to impl List, period, we'll break back-compa

RE: SegmentInfos extends Vector

right, it does not make real sense. With backwards compatibility I think of plug-in compatibility, not behavior compatibility. If we want to keep behavior compatibility, we must extend Vector J and allow all modifications. So implementing a non-modifiable Collection/List may be the best. But

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

Re: SegmentInfos extends Vector

ctions can disabled by that exception, the docs state that. > > > > But you are right, it does not make real sense. With backwards > compatibility I think of plug-in compatibility, not behavior compatibility. > If we want to keep behavior compatibility, we must extend Vecto

RE: SegmentInfos extends Vector

Hi Shai, I am only the Generics Police but not the Generics Homeland Security and also not the Backwards Homeland Security J I think if we break backwards, lets break it complete and remove the “extends Vector”. And then let’s make the Iterator/Iterable/Collection unmodifiable. That would

Re: SegmentInfos extends Vector

erics Police but not the Generics Homeland Security and > also not the Backwards Homeland Security J I think if we break backwards, > lets break it complete and remove the “extends Vector”. And then let’s make > the Iterator/Iterable/Collection unmodifiable. That would get a big +1 from >

Re: SegmentInfos extends Vector

This class is @lucene.experimental, so we are free to break it. +1 to not "extends Vector". I don't think we should change to @lucene.internal since the thinking is apps outside Lucene should be able to introspect and see segment structure in the index. Ie we made this API p

Re: SegmentInfos extends Vector

ental then. I'll work on it soon. Shai On Sun, Feb 28, 2010 at 6:48 PM, Michael McCandless < luc...@mikemccandless.com> wrote: > This class is @lucene.experimental, so we are free to break it. +1 to > not "extends Vector". > > I don't think we should cha

Resolving term vector even when not stored?

I propose a change of the current IndexReader.getTermFreqVector/s- code so that it /always/ return the vector space model of a document, even when set fields are set as Field.TermVector.NO. Is that crazy? Could be really slow, but except for that.. And if it is cached then that information

[jira] Created: (LUCENE-959) Document Vector->ArrayList

Document Vector->ArrayList -- Key: LUCENE-959 URL: https://issues.apache.org/jira/browse/LUCENE-959 Project: Lucene - Java Issue Type: Improvement Reporter: Yonik Seeley Priority: Triv

[jira] Updated: (LUCENE-959) Document Vector->ArrayList

[ https://issues.apache.org/jira/browse/LUCENE-959?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Yonik Seeley updated LUCENE-959: Attachment: Document.patch Trivial patch attached. Any concerns? > Document Vector->Arr

[jira] Resolved: (LUCENE-959) Document Vector->ArrayList

[ https://issues.apache.org/jira/browse/LUCENE-959?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Yonik Seeley resolved LUCENE-959. - Resolution: Fixed committed. > Document Vector->Arr

[jira] Created: (LUCENE-1008) document with no term vector fields after documents with term vector fields corrupts the index

document with no term vector fields after documents with term vector fields corrupts the index -- Key: LUCENE-1008 URL: https://issues.apache.org/jira/browse/LUCENE-1008

[jira] Resolved: (LUCENE-1008) document with no term vector fields after documents with term vector fields corrupts the index

problem we need to understand why ie, are you also adding docs with no term vector fields? > document with no term vector fields after documents with term vector fields > corrupts the

[jira] Updated: (LUCENE-95) [PATCH] Term Vector support

protected and added some documentation. Contents: patch.txt -- The svn diff patch to QueryTermVector newFiles.tar -- The new files for QueryTermPositionVector Thanks, Grant > [PATCH] Term Vector support > --- > > Key: LUCENE-95 >

Re: Resolving term vector even when not stored?

On 3/15/07, karl wettin <[EMAIL PROTECTED]> wrote: I propose a change of the current IndexReader.getTermFreqVector/s- code so that it /always/ return the vector space model of a document, even when set fields are set as Field.TermVector.NO. Is that crazy? Could be really slow, but exce

Re: Resolving term vector even when not stored?

"Mike Klaas" <[EMAIL PROTECTED]> wrote on 16/03/2007 14:26:46: > On 3/15/07, karl wettin <[EMAIL PROTECTED]> wrote: > > I propose a change of the current IndexReader.getTermFreqVector/s- > > code so that it /always/ return the vector space model of a document

Re: Resolving term vector even when not stored?

17 mar 2007 kl. 08.15 skrev Doron Cohen: "Mike Klaas" <[EMAIL PROTECTED]> wrote on 16/03/2007 14:26:46: On 3/15/07, karl wettin <[EMAIL PROTECTED]> wrote: I propose a change of the current IndexReader.getTermFreqVector/s- code so that it /always/ return the v

DO NOT REPLY [Bug 18927] - [PATCH] Term Vector support

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG· RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT . ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND· INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bu

DO NOT REPLY [Bug 18927] - [PATCH] Term Vector support

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG· RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT . ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND· INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bu

[jira] Created: (LUCENE-1016) TermVectorAccessor, transparent vector space access

TermVectorAccessor, transparent vector space access Key: LUCENE-1016 URL: https://issues.apache.org/jira/browse/LUCENE-1016 Project: Lucene - Java Issue Type: New Feature

[jira] Updated: (LUCENE-1016) TermVectorAccessor, transparent vector space access

[ https://issues.apache.org/jira/browse/LUCENE-1016?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Karl Wettin updated LUCENE-1016: Attachment: LUCENE-1016.txt > TermVectorAccessor, transparent vector space acc

[jira] Updated: (LUCENE-1016) TermVectorAccessor, transparent vector space access

[ https://issues.apache.org/jira/browse/LUCENE-1016?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Karl Wettin updated LUCENE-1016: Attachment: (was: LUCENE-1016.txt) > TermVectorAccessor, transparent vector space acc

[jira] Updated: (LUCENE-1016) TermVectorAccessor, transparent vector space access

. > TermVectorAccessor, transparent vector space access > > > Key: LUCENE-1016 > URL: https://issues.apache.org/jira/browse/LUCENE-1016 > Project: Lucene - Java > Is

[jira] Updated: (LUCENE-1016) TermVectorAccessor, transparent vector space access

, used to calculate the distance between the vector space of two documents. My math skills are pretty lame, but I think I got it right. > TermVectorAccessor, transparent vector space access > > > Key:

[jira] Commented: (LUCENE-1016) TermVectorAccessor, transparent vector space access

project, or is that something I should post in UIMA or so? > TermVectorAccessor, transparent vector space access > > > Key: LUCENE-1016 > URL: https://issues.apache.org/jira/browse/LUCENE-1016 >

[jira] Commented: (LUCENE-1016) TermVectorAccessor, transparent vector space access

we will have 1.5 > TermVectorAccessor, transparent vector space access > > > Key: LUCENE-1016 > URL: https://issues.apache.org/jira/browse/LUCENE-1016 > Project: Lucene - Java >

[jira] Commented: (LUCENE-1016) TermVectorAccessor, transparent vector space access

t; > Soon, very soon (in Lucene terms), we will have 1.5 This is why I placed it in contrib/misc, I was under the impression contrib allowed 1.5? > TermVectorAccessor, transparent vector space access > > >

[jira] Commented: (LUCENE-1016) TermVectorAccessor, transparent vector space access

de in TanimotoDocumentSimilarity. I'll post something nice and refactored soon. I was just really thrilled that I managed to figure out all them greek characters in the whitepaper. > TermVectorAccessor, transparent vector

[jira] Updated: (LUCENE-1016) TermVectorAccessor, transparent vector space access

needs optimization, use carrot instead. This is just me fooling aroung.) Have fun! > TermVectorAccessor, transparent vector space access > > > Key: LUCENE-1016 > URL: https://issues.apache.org/jir

[jira] Commented: (LUCENE-1016) TermVectorAccessor, transparent vector space access

[ https://issues.apache.org/jira/browse/LUCENE-1016?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12532227 ] Karl Wettin commented on LUCENE-1016: - TermVectorMapper should probably also be able to extract the term vector

[jira] Commented: (LUCENE-1016) TermVectorAccessor, transparent vector space access

lso be able.. TermVectorAccessor, that is. > TermVectorAccessor, transparent vector space access > > > Key: LUCENE-1016 > URL: https://issues.apache.org/jira/browse/LUCENE-1016 > P

[jira] Updated: (LUCENE-1016) TermVectorAccessor, transparent vector space access

in some cases before This patch is TermVectorAccessor code only, nothing else. > TermVectorAccessor, transparent vector space access > > > Key: LUCENE-1016 > URL: https://issues.apache.org/jira/bro

[jira] Updated: (LUCENE-1016) TermVectorAccessor, transparent vector space access

[ https://issues.apache.org/jira/browse/LUCENE-1016?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Karl Wettin updated LUCENE-1016: Attachment: (was: out.png) > TermVectorAccessor, transparent vector space acc

[jira] Updated: (LUCENE-1016) TermVectorAccessor, transparent vector space access

[ https://issues.apache.org/jira/browse/LUCENE-1016?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Karl Wettin updated LUCENE-1016: Attachment: (was: LUCENE-1016-clusterer.txt) > TermVectorAccessor, transparent vector sp

[jira] Updated: (LUCENE-1016) TermVectorAccessor, transparent vector space access

that had nothing to do with this patch. > TermVectorAccessor, transparent vector space access > > > Key: LUCENE-1016 > URL: https://issues.apache.org/jira/browse/LUCENE-1016 > Proj

[jira] Updated: (LUCENE-1016) TermVectorAccessor, transparent vector space access

[ https://issues.apache.org/jira/browse/LUCENE-1016?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Karl Wettin updated LUCENE-1016: Attachment: (was: LUCENE-1016.txt) > TermVectorAccessor, transparent vector space acc

[jira] Updated: (LUCENE-1016) TermVectorAccessor, transparent vector space access

[ https://issues.apache.org/jira/browse/LUCENE-1016?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Karl Wettin updated LUCENE-1016: Attachment: (was: LUCENE-1016-Tanimoto.txt) > TermVectorAccessor, transparent vector sp

[jira] Updated: (LUCENE-1016) TermVectorAccessor, transparent vector space access

[ https://issues.apache.org/jira/browse/LUCENE-1016?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Karl Wettin updated LUCENE-1016: Attachment: (was: LUCENE-1016.txt) > TermVectorAccessor, transparent vector space acc

[jira] Commented: (LUCENE-1016) TermVectorAccessor, transparent vector space access

-TermFreqVector-from-an-existing-index-tf4756257.html#a13601345 I'll have to look in to the file format and see if it is possible to persist a term vector retreived from the inverted index. That could be a nice addition to this issue. > TermVectorAccessor, transparent vector spac

[jira] Commented: (LUCENE-1016) TermVectorAccessor, transparent vector space access

t of this would be faster than reanalyzing a document. Just thinking outloud, but I have wondering about a Highlighter that uses the new TermVectorMapper, but that doesn't account for non-TermVector based. Was thinking this might account for both cases. > TermVectorAccessor, transpa

[jira] Commented: (LUCENE-1016) TermVectorAccessor, transparent vector space access

ccess to the source data. It was used together with a TermVectorMappingCachedTokenStreamFactory to extract re-indexable documents from any directory. If you think of this peice of code and highlighter together, I would consider something else, perhaps a tool that could add the term vector to all d

[jira] Updated: (LUCENE-1016) TermVectorAccessor, transparent vector space access

[ https://issues.apache.org/jira/browse/LUCENE-1016?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Karl Wettin updated LUCENE-1016: Fix Version/s: 2.4 I'll commit this soon. > TermVectorAccessor, transparent vector spac

[jira] Updated: (LUCENE-1016) TermVectorAccessor, transparent vector space access

[ https://issues.apache.org/jira/browse/LUCENE-1016?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Karl Wettin updated LUCENE-1016: Attachment: LUCENE-1016.txt Documentation > TermVectorAccessor, transparent vector space acc

[jira] Assigned: (LUCENE-1016) TermVectorAccessor, transparent vector space access

! > TermVectorAccessor, transparent vector space access > > > Key: LUCENE-1016 > URL: https://issues.apache.org/jira/browse/LUCENE-1016 > Project: Lucene - Java > Is

[jira] Closed: (LUCENE-1016) TermVectorAccessor, transparent vector space access

[ https://issues.apache.org/jira/browse/LUCENE-1016?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Karl Wettin closed LUCENE-1016. --- Resolution: Fixed > TermVectorAccessor, transparent vector space acc

DO NOT REPLY [Bug 31368] - Waiting for Vector in org.apache.lucene.index.FieldInfos.fieldInfo

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG· RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT . ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND· INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bu

DO NOT REPLY [Bug 31368] - Waiting for Vector in org.apache.lucene.index.FieldInfos.fieldInfo

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG· RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT . ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND· INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bu

[jira] Created: (LUCENE-1346) replace Vector with ArrayList in Queries

replace Vector with ArrayList in Queries Key: LUCENE-1346 URL: https://issues.apache.org/jira/browse/LUCENE-1346 Project: Lucene - Java Issue Type: Improvement Reporter: Yonik Seeley

[jira] Updated: (LUCENE-1346) replace Vector with ArrayList in Queries

[ https://issues.apache.org/jira/browse/LUCENE-1346?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Yonik Seeley updated LUCENE-1346: - Attachment: LUCENE-1346.patch Attaching patch that changes Vector to ArrayList in PhraseQuery

[jira] Resolved: (LUCENE-1346) replace Vector with ArrayList in Queries

[ https://issues.apache.org/jira/browse/LUCENE-1346?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Yonik Seeley resolved LUCENE-1346. -- Resolution: Fixed Fix Version/s: 2.4 committed. > replace Vector with ArrayList

Push fast-vector-highlighter mvn artifacts for 3.0 and 2.9

hi folks, The maven artifacts for fast-vector-highlighter have never been pushed since it was released because there were no pom.xml.template inside the module. I added a pom file a day ago in the context of LUCENE-2107. I already talked to uwe and grant how to deal with this issues and if we

[jira] Created: (LUCENE-1809) highlight-vs-vector-highlight.alg is unfair

highlight-vs-vector-highlight.alg is unfair --- Key: LUCENE-1809 URL: https://issues.apache.org/jira/browse/LUCENE-1809 Project: Lucene - Java Issue Type: Bug Components: contrib/benchmark

[jira] Updated: (LUCENE-1809) highlight-vs-vector-highlight.alg is unfair

enwikiQueryMaker.disableSpanQueries. If it is set to true (default is false), EnwikiQueryMaker doesn't make SpanQueries. results (elapsedSec) are: || ||FastVectorHL||HL|| |w/o patch|7.70|20.25| |w/ patch|7.67|19.07| > highlight-vs-vector-highlight.alg i

[jira] Updated: (LUCENE-1809) highlight-vs-vector-highlight.alg is unfair

mance when processing large docs, this patch includes: * set max.field.length Integer.MAX_VALUE in the alg file * introduces a new property "highlighter.maxDocCharsToAnalyze" and set it Integer.MAX_VALUE in the alg file > highlight-vs-vector-highl

[jira] Assigned: (LUCENE-1809) highlight-vs-vector-highlight.alg is unfair

[ https://issues.apache.org/jira/browse/LUCENE-1809?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael McCandless reassigned LUCENE-1809: -- Assignee: Michael McCandless > highlight-vs-vector-highlight.alg is unf

[jira] Commented: (LUCENE-1809) highlight-vs-vector-highlight.alg is unfair

Koji. I'll commit shortly! > highlight-vs-vector-highlight.alg is unfair > --- > > Key: LUCENE-1809 > URL: https://issues.apache.org/jira/browse/LUCENE-1809 > Project: Lucene - Java

[jira] Resolved: (LUCENE-1809) highlight-vs-vector-highlight.alg is unfair

[ https://issues.apache.org/jira/browse/LUCENE-1809?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael McCandless resolved LUCENE-1809. Resolution: Fixed Fix Version/s: 2.9 Thanks Koji! > highlight-vs-vec

[jira] Created: (LUCENE-711) BooleanWeight should size the weights Vector correctly

BooleanWeight should size the weights Vector correctly -- Key: LUCENE-711 URL: http://issues.apache.org/jira/browse/LUCENE-711 Project: Lucene - Java Issue Type: Improvement

[jira] Updated: (LUCENE-711) BooleanWeight should size the weights Vector correctly

the weights Vector correctly > -- > > Key: LUCENE-711 > URL: http://issues.apache.org/jira/browse/LUCENE-711 > Project: Lucene - Java > Issue Type: Improvement > Compone

[jira] Issue Comment Edited: (LUCENE-1016) TermVectorAccessor, transparent vector space access

I have wondering about a Highlighter that uses the new TermVectorMapper, but that doesn't account for non-TermVector based. Was thinking this might account for both cases. > TermVectorAccessor, transparent vector space access > &

[jira] Created: (LUCENE-1369) Eliminate unnecessary uses of Hashtable and Vector

Eliminate unnecessary uses of Hashtable and Vector -- Key: LUCENE-1369 URL: https://issues.apache.org/jira/browse/LUCENE-1369 Project: Lucene - Java Issue Type: Improvement Affects

[jira] Updated: (LUCENE-1369) Eliminate unnecessary uses of Hashtable and Vector

[ https://issues.apache.org/jira/browse/LUCENE-1369?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] DM Smith updated LUCENE-1369: - Attachment: LUCENE-1369.patch > Eliminate unnecessary uses of Hashtable and Vec

[jira] Assigned: (LUCENE-1369) Eliminate unnecessary uses of Hashtable and Vector

and Vector > -- > > Key: LUCENE-1369 > URL: https://issues.apache.org/jira/browse/LUCENE-1369 > Project: Lucene - Java > Issue Type: Improvement >Affects Versions: 2.3.2 >

[jira] Commented: (LUCENE-1369) Eliminate unnecessary uses of Hashtable and Vector

wn "implements PrecedenceQueryParserConstants", it failed to compile. I plan to commit in a day or two. > Eliminate unnecessary uses of Hashtable and Vector > -- > > Key: LUCENE-1369 > URL: https://is

[jira] Resolved: (LUCENE-1369) Eliminate unnecessary uses of Hashtable and Vector

Available, New]) Thanks DM! > Eliminate unnecessary uses of Hashtable and Vector > -- > > Key: LUCENE-1369 > URL: https://issues.apache.org/jira/browse/LUCENE-1369 > Project: Lucene - Java >

[jira] Updated: (LUCENE-711) BooleanWeight should size the weights Vector correctly

to trunk. > BooleanWeight should size the weights Vector correctly > -- > > Key: LUCENE-711 > URL: https://issues.apache.org/jira/browse/LUCENE-711 > Project: Lucene - Java >

[jira] Resolved: (LUCENE-711) BooleanWeight should size the weights Vector correctly

/lucene/search/BooleanQuery.java Transmitting file data . Committed revision 713634. > BooleanWeight should size the weights Vector correctly > -- > > Key: LUCENE-711 > URL: https://issues.apache.

[jira] Commented: (LUCENE-1369) Eliminate unnecessary uses of Hashtable and Vector

with adding more expressive range query syntax that I plan to finish up, so whats the verdict on these types of changes? Might as well do as many at once as we can if we are going to do it. > Eliminate unnecessary uses of Hashtable and

[jira] Commented: (LUCENE-1369) Eliminate unnecessary uses of Hashtable and Vector

s why I didn't do these replacements in QueryParser when I did the others. > Eliminate unnecessary uses of Hashtable and Vector > -- > > Key: LUCENE-1369 > URL: https://issues.apache.org/jira/browse

[jira] Commented: (LUCENE-1369) Eliminate unnecessary uses of Hashtable and Vector

reak in back-compat -- my bad. I missed that this change would mean we silently stop calling the Vector-based methods in subclasses. I'll send an email to java-user. > Eliminate unnecessary uses of Hashtable and Vector > -- > >

Re: Push fast-vector-highlighter mvn artifacts for 3.0 and 2.9

t; The maven artifacts for fast-vector-highlighter have never been pushed > since it was released because there were no pom.xml.template inside > the module. I added a pom file a day ago in the context of > LUCENE-2107. I already talked to uwe and grant how to deal with this > issues and

Re: Push fast-vector-highlighter mvn artifacts for 3.0 and 2.9

ures. Yep - that might be the best solution as it does not change code though. Whoever volunteers to do so has to checkout the same revision to make sure it is the same code while I doubt that we had changes in fast-vector-highlighter in the branch. -- Doh! no change in 3.0 branch but in 2.9. simon >

RE: Push fast-vector-highlighter mvn artifacts for 3.0 and 2.9

Simon Willnauer [mailto:simon.willna...@googlemail.com] > Sent: Saturday, December 05, 2009 10:34 PM > To: java-dev@lucene.apache.org > Subject: Re: Push fast-vector-highlighter mvn artifacts for 3.0 and 2.9 > > On Sat, Dec 5, 2009 at 10:25 PM, Grant Ingersoll > wrote: > >

RE: Push fast-vector-highlighter mvn artifacts for 3.0 and 2.9

I rebuilt the maven-dir for 2.9.1 and 3.0.0, merged them (3.0.0 is top-level version) and extracted only fast-vector-highlighter: http://people.apache.org/~uschindler/staging-area/ I will copy this dir to the maven folder on people.a.o, when I got votes (how many)? At least someone should check

  1   2   >