You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@lucene.apache.org by bu...@apache.org on 2005/04/03 23:22:41 UTC
DO NOT REPLY [Bug 32965] -
[PATCH] Use filter bits for next() and skipTo() in FilteredQuery
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG�
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
<http://issues.apache.org/bugzilla/show_bug.cgi?id=32965>.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND�
INSERTED IN THE BUG DATABASE.
http://issues.apache.org/bugzilla/show_bug.cgi?id=32965
paul.elschot@xs4all.nl changed:
What |Removed |Added
----------------------------------------------------------------------------
OtherBugsDependingO| |34279
nThis| |
--
Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.
---------------------------------------------------------------------
To unsubscribe, e-mail: java-dev-unsubscribe@lucene.apache.org
For additional commands, e-mail: java-dev-help@lucene.apache.org
Re: DO NOT REPLY [Bug 32965] - [PATCH] Use filter bits for next() and skipTo() in FilteredQuery
Posted by Paul Elschot <pa...@xs4all.nl>.
On Monday 04 April 2005 11:34, Erik Hatcher wrote:
> I added Paul's SkipFilter and overwrote my FilteredQuery class from the
> code here. However, your FilteredQuery depends on two additional
> classes: DocNrSkipper and SortedVIntList that are not provided.
> Please attach those classes to this issue.
They are in one of the bugs the filter depends on:
http://issues.apache.org/bugzilla/show_bug.cgi?id=32921
>
> I'm not personally fond of the abbreviation of "Number" to "Nr" - any
> objections to spelling out "Number" entirely?
Not at all. My tradeoff between programming line length and
identifier readability is just slightly different. For me, number is
general enough to abbreviate in an identifier.
> Any others have objections to Paul's patches here? I'll commit them
> once I have everything working locally, unless I hear otherwise.
Please note the other dependency: this filter only works correctly when
documents are always scored in document number order.
This means that the bucket table of the 1.4.3 BooleanScorer can not
be used anymore, except when sorting is added.
See also the last comments I posted at that bug:
http://issues.apache.org/bugzilla/show_bug.cgi?id=33019
The (non ordered) bucket scoring mechanism the fastest one that is
available, anything else is slower, alhough not by much.
As for the assert statements: could you comment them out in case
the dependency on java 1.4 is not acceptable? That would
leave them useable for later.
Regards,
Paul Elschot
---------------------------------------------------------------------
To unsubscribe, e-mail: java-dev-unsubscribe@lucene.apache.org
For additional commands, e-mail: java-dev-help@lucene.apache.org
Re: DO NOT REPLY [Bug 32965] - [PATCH] Use filter bits for next() and skipTo() in FilteredQuery
Posted by Erik Hatcher <er...@ehatchersolutions.com>.
I added Paul's SkipFilter and overwrote my FilteredQuery class from the
code here. However, your FilteredQuery depends on two additional
classes: DocNrSkipper and SortedVIntList that are not provided.
Please attach those classes to this issue.
I'm not personally fond of the abbreviation of "Number" to "Nr" - any
objections to spelling out "Number" entirely?
Any others have objections to Paul's patches here? I'll commit them
once I have everything working locally, unless I hear otherwise.
Erik
On Apr 3, 2005, at 5:22 PM, bugzilla@apache.org wrote:
> DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG·
> RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
> <http://issues.apache.org/bugzilla/show_bug.cgi?id=32965>.
> ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND·
> INSERTED IN THE BUG DATABASE.
>
> http://issues.apache.org/bugzilla/show_bug.cgi?id=32965
>
>
> paul.elschot@xs4all.nl changed:
>
> What |Removed |Added
> -----------------------------------------------------------------------
> -----
> OtherBugsDependingO| |34279
> nThis| |
>
>
>
>
> --
> Configure bugmail:
> http://issues.apache.org/bugzilla/userprefs.cgi?tab=email
> ------- You are receiving this mail because: -------
> You are the assignee for the bug, or are watching the assignee.
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: java-dev-unsubscribe@lucene.apache.org
> For additional commands, e-mail: java-dev-help@lucene.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: java-dev-unsubscribe@lucene.apache.org
For additional commands, e-mail: java-dev-help@lucene.apache.org
Re: lucene 2.0?
Posted by Paul Elschot <pa...@xs4all.nl>.
On Wednesday 20 April 2005 03:29, Erik Hatcher wrote:
> What shall we do with my experimental PrecedenceQueryParser? It still
> has some issues, but it also solves QueryParser operator precedence
> wackiness. I likely won't have much time to get back to it before we
> want to do a release. Does anyone want to have a go at trying to fix
> the issues identified with the tests from this?
>
> ant test -Dtestcase=TestPrecedenceQueryParser
>
> If not, we should probably pull it out so as to not distribute it with
> an official release. Thoughts?
I agree that it shouldn't be released as it is, so pulling it out and
putting it back in when its development continues after 2.0 seems
the right way to go. I've just renamed my copy with a _2_1 suffix to keep it
out of the hands of svn.
Regards,
Paul Elschot
---------------------------------------------------------------------
To unsubscribe, e-mail: java-dev-unsubscribe@lucene.apache.org
For additional commands, e-mail: java-dev-help@lucene.apache.org
Re: lucene 2.0?
Posted by "Mario Alejandro M." <ma...@gmail.com>.
>
> If you continue with your port, you are going to have to face the
> realization that you will always be behind the Java version in terms of
> features and compatibility - unless you're able to implement the
> features every time you see a commit message.
I understand this. A productive way is do changes when final milestones are
archived, not when each change is done.
Also, I don't only pretend reinvent the wheel. I plan provide this port with
unique attributes, like 100% Win32, 100% NET and maybe MONO later releases,
with 0 runtimes/external dependences, Firebird/Sql Server index storage,
Full spanish support, and Delphi RAD support....
If you don't plan on spending every waking moment porting, why not join
> forces with the SWIG Lucene folks and interface to that from Delphi?
That depend on strategic motivation. if Lucene is simply a add-on, where
this provide everything is necesary then this way is good. But if is
necesary change the code... what? I have experience in 7-10 languages but
none (except JavaScript) are of the Java/C++ crowd. I don't have expertise
or tool support or time to know how everything is in C++/Java, while C# (my
reference) is most close to Delphi, I found some C-like construct very
logic-disruptive and hard to read and understand, from my point of view...
some of this things stop me for days trying to understand it.
Computer languages like in the real worldare a barrier.... so if I want
enable Delphi community on this and, mainly, I want DEPEND on Lucene, I need
it in a environment/language I know and have control. Use the Java or C++ or
anything else is a bad move for my company, because I know I need full acces
to the inner-working when the port is done.
You're already behind and there has been dramatic changes with the
> latest codebase that will be Lucene 1.9/2.0.
I see a lot! I have a copy of Lucene 1.4. So, I wait then for have my actual
codebase working and wait for Lucene 2 (I know in this step some classes
disapear). Despite the changes, I can refactor and change the code
quickly...only worry for the test suite.
--
Mario Alejandro Montoya
MCP
www.solucionesvulcano.com <http://www.solucionesvulcano.com>
!Obtenga su sitio Web dinámico!
Re: lucene 2.0?
Posted by Erik Hatcher <er...@ehatchersolutions.com>.
On Apr 19, 2005, at 10:06 PM, Mario Alejandro M. wrote:
> LIke maybe know, I'm porting Lucene to Delphi.
>
> Taking in account that this is in progress and not a functional
> release as
> be made (however, today I archive ALPHA 2 when all indexing stuff is
> working) what can help me in not wast time on it?
There is a concerted effort to develop a SWIG Lucene and there is also
a CLucene and an active Lucene4C project. I was crazy enough to
contemplate a native Ruby port once upon a time, and developed some
low-level I/O code and then realized what a maintenance hassle it'd be
to keep up with the always evolving Java Lucene.
The PyLucene crew (credit where its due, Andi Vajda!) did something
quite amazing... using GCJ and SWIG to interface Java Lucene with
Python. This, in my opinion, is the way to future "ports" to any
language. Let Java Lucene be the base and all other ports derive from
it. I'm not sure why motivates Garrett with Lucene4C - and I certainly
do not want to discourage anyone from tackling this as at the very
least it is a great computer science exercise and surely a learning
experience for anyone attempting it.
If you continue with your port, you are going to have to face the
realization that you will always be behind the Java version in terms of
features and compatibility - unless you're able to implement the
features every time you see a commit message.
> For example, I know that portersteimmer is deprecated by snowball...
> exist
> other classes not worth to port now?
If you don't plan on spending every waking moment porting, why not join
forces with the SWIG Lucene folks and interface to that from Delphi?
> Something else I must know? The code is based in Lucene 1.4.3...
You're already behind and there has been dramatic changes with the
latest codebase that will be Lucene 1.9/2.0.
Erik
---------------------------------------------------------------------
To unsubscribe, e-mail: java-dev-unsubscribe@lucene.apache.org
For additional commands, e-mail: java-dev-help@lucene.apache.org
Re: lucene 2.0?
Posted by "Mario Alejandro M." <ma...@gmail.com>.
LIke maybe know, I'm porting Lucene to Delphi.
Taking in account that this is in progress and not a functional release as
be made (however, today I archive ALPHA 2 when all indexing stuff is
working) what can help me in not wast time on it?
For example, I know that portersteimmer is deprecated by snowball... exist
other classes not worth to port now?
Something else I must know? The code is based in Lucene 1.4.3...
--
Mario Alejandro Montoya
MCP
www.solucionesvulcano.com <http://www.solucionesvulcano.com>
!Obtenga su sitio Web dinámico!
MUTIS
The Delphi search and indexing engine
http://mutis.sourceforge.net/
Re: lucene 2.0?
Posted by Erik Hatcher <er...@ehatchersolutions.com>.
What shall we do with my experimental PrecedenceQueryParser? It still
has some issues, but it also solves QueryParser operator precedence
wackiness. I likely won't have much time to get back to it before we
want to do a release. Does anyone want to have a go at trying to fix
the issues identified with the tests from this?
ant test -Dtestcase=TestPrecedenceQueryParser
If not, we should probably pull it out so as to not distribute it with
an official release. Thoughts?
Erik
On Apr 19, 2005, at 9:15 PM, Erik Hatcher wrote:
> On Apr 19, 2005, at 6:16 PM, Doug Cutting wrote:
>> Bernhard Messer wrote:
>>> I'm not a fan of outdated software or historical systems. So i think
>>> the best would be to keep lucene still backward compatible with
>>> version 1.9 and perform the switch to JDK 1.4 with lucene 2.0.
>>
>> That sounds like a good plan.
>>
>> Which raises the question, when should we make the 1.9 and 2.0
>> releases?
>>
>> The plan for these is at:
>>
>> http://wiki.apache.org/jakarta-lucene/Lucene2Whiteboard
>>
>> We should probably make these releases before we finish everything on
>> that list. There have been a lot of good changes since 1.4.3 that
>> would be nice to get into more folks hands.
>>
>> Thoughts?
>
> I'm all for a 1.9 release, let that stabilize and shake out any
> backwards compatible issues we may have missed, and then push out the
> 2.0 as planned with all the deprecated API removed. I'm using trunk
> for all my work, and many of the contrib components have been updated
> in trunk to the latest non-deprecated API - so someone using 1.4.3
> wouldn't be able to use the spellchecker from trunk, for example.
>
> I will bump the build refactorings up in priority so that we can have
> all the contrib pieces bundled in as well, including javadoc
> integration. I'll aim for the end of the coming weekend to have that
> in place.
>
> Erik
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: java-dev-unsubscribe@lucene.apache.org
> For additional commands, e-mail: java-dev-help@lucene.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: java-dev-unsubscribe@lucene.apache.org
For additional commands, e-mail: java-dev-help@lucene.apache.org
Re: lucene 2.0?
Posted by Erik Hatcher <er...@ehatchersolutions.com>.
On Apr 19, 2005, at 6:16 PM, Doug Cutting wrote:
> Bernhard Messer wrote:
>> I'm not a fan of outdated software or historical systems. So i think
>> the best would be to keep lucene still backward compatible with
>> version 1.9 and perform the switch to JDK 1.4 with lucene 2.0.
>
> That sounds like a good plan.
>
> Which raises the question, when should we make the 1.9 and 2.0
> releases?
>
> The plan for these is at:
>
> http://wiki.apache.org/jakarta-lucene/Lucene2Whiteboard
>
> We should probably make these releases before we finish everything on
> that list. There have been a lot of good changes since 1.4.3 that
> would be nice to get into more folks hands.
>
> Thoughts?
I'm all for a 1.9 release, let that stabilize and shake out any
backwards compatible issues we may have missed, and then push out the
2.0 as planned with all the deprecated API removed. I'm using trunk
for all my work, and many of the contrib components have been updated
in trunk to the latest non-deprecated API - so someone using 1.4.3
wouldn't be able to use the spellchecker from trunk, for example.
I will bump the build refactorings up in priority so that we can have
all the contrib pieces bundled in as well, including javadoc
integration. I'll aim for the end of the coming weekend to have that
in place.
Erik
---------------------------------------------------------------------
To unsubscribe, e-mail: java-dev-unsubscribe@lucene.apache.org
For additional commands, e-mail: java-dev-help@lucene.apache.org
lucene 2.0?
Posted by Doug Cutting <cu...@apache.org>.
Bernhard Messer wrote:
> I'm not a fan of outdated software or historical systems. So i think the
> best would be to keep lucene still backward compatible with version 1.9
> and perform the switch to JDK 1.4 with lucene 2.0.
That sounds like a good plan.
Which raises the question, when should we make the 1.9 and 2.0 releases?
The plan for these is at:
http://wiki.apache.org/jakarta-lucene/Lucene2Whiteboard
We should probably make these releases before we finish everything on
that list. There have been a lot of good changes since 1.4.3 that would
be nice to get into more folks hands.
Thoughts?
Doug
---------------------------------------------------------------------
To unsubscribe, e-mail: java-dev-unsubscribe@lucene.apache.org
For additional commands, e-mail: java-dev-help@lucene.apache.org
Re: DO NOT REPLY [Bug 32965] - [PATCH] Use filter bits for next()
and skipTo() in FilteredQuery
Posted by Bernhard Messer <be...@intrafind.de>.
Erik Hatcher wrote:
> Oh, and one other thing.... Paul's code relies on JDK 1.4's assert
> keyword. It seems this is an unnecessary reason to jump to 1.4
> dependence.
>
> What do folks think about JDK 1.4 as a minimum Lucene requirement?
I'm not a fan of outdated software or historical systems. So i think the
best would be to keep lucene still backward compatible with version 1.9
and perform the switch to JDK 1.4 with lucene 2.0.
Bernhard
---------------------------------------------------------------------
To unsubscribe, e-mail: java-dev-unsubscribe@lucene.apache.org
For additional commands, e-mail: java-dev-help@lucene.apache.org
Re: DO NOT REPLY [Bug 32965] - [PATCH] Use filter bits for next() and skipTo() in FilteredQuery
Posted by Paul Elschot <pa...@xs4all.nl>.
On Monday 04 April 2005 11:36, Erik Hatcher wrote:
> Oh, and one other thing.... Paul's code relies on JDK 1.4's assert
> keyword. It seems this is an unnecessary reason to jump to 1.4
> dependence.
>
> What do folks think about JDK 1.4 as a minimum Lucene requirement?
The FilteredQuery as posted there requires jdk 1.4
because it uses BitSet.nextSetBit():
http://issues.apache.org/bugzilla/show_bug.cgi?id=32965#c2
Regards,
Paul Elschot
---------------------------------------------------------------------
To unsubscribe, e-mail: java-dev-unsubscribe@lucene.apache.org
For additional commands, e-mail: java-dev-help@lucene.apache.org
Re: DO NOT REPLY [Bug 32965] - [PATCH] Use filter bits for next()
and skipTo() in FilteredQuery
Posted by Chuck Williams <ch...@allthingslocal.com>.
Erik Hatcher writes (4/4/2005 2:36 AM):
> Oh, and one other thing.... Paul's code relies on JDK 1.4's assert
> keyword. It seems this is an unnecessary reason to jump to 1.4
> dependence.
As a 1.5 user, I'd love to see Lucene at least at 1.4. Assert's are a
good thing.
Chuck
---------------------------------------------------------------------
To unsubscribe, e-mail: java-dev-unsubscribe@lucene.apache.org
For additional commands, e-mail: java-dev-help@lucene.apache.org
Re: DO NOT REPLY [Bug 32965] - [PATCH] Use filter bits for next() and skipTo() in FilteredQuery
Posted by Erik Hatcher <er...@ehatchersolutions.com>.
On Apr 4, 2005, at 8:18 AM, Andrzej Bialecki wrote:
> Erik Hatcher wrote:
>> Oh, and one other thing.... Paul's code relies on JDK 1.4's assert
>
> Erhm.. you meant 1.5 (five), right?
No, 1.4. Assert's were added in JDK 1.4. I live in a Mac-centric
world and 1.5 (errr, 5.0!), and I've yet to run 1.5 since its not
freely available for Mac OS X yet.
Erik
---------------------------------------------------------------------
To unsubscribe, e-mail: java-dev-unsubscribe@lucene.apache.org
For additional commands, e-mail: java-dev-help@lucene.apache.org
Re: DO NOT REPLY [Bug 32965] - [PATCH] Use filter bits for next()
and skipTo() in FilteredQuery
Posted by Andrzej Bialecki <ab...@getopt.org>.
Erik Hatcher wrote:
> Oh, and one other thing.... Paul's code relies on JDK 1.4's assert
Erhm.. you meant 1.5 (five), right?
--
Best regards,
Andrzej Bialecki
___. ___ ___ ___ _ _ __________________________________
[__ || __|__/|__||\/| Information Retrieval, Semantic Web
___|||__|| \| || | Embedded Unix, System Integration
http://www.sigram.com Contact: info at sigram dot com
---------------------------------------------------------------------
To unsubscribe, e-mail: java-dev-unsubscribe@lucene.apache.org
For additional commands, e-mail: java-dev-help@lucene.apache.org
Re: DO NOT REPLY [Bug 32965] - [PATCH] Use filter bits for next()
and skipTo() in FilteredQuery
Posted by Bernhard Messer <bm...@apache.org>.
Erik Hatcher wrote:
> Oh, and one other thing.... Paul's code relies on JDK 1.4's assert
> keyword. It seems this is an unnecessary reason to jump to 1.4
> dependence.
>
> What do folks think about JDK 1.4 as a minimum Lucene requirement?
>
> Erik
I'm not a fan of outdated software or historical systems. So i think the
best would be to keep lucene still backward compatible with version 1.9
and perform the switch to JDK 1.4 with lucene 2.0.
Bernhard
---------------------------------------------------------------------
To unsubscribe, e-mail: java-dev-unsubscribe@lucene.apache.org
For additional commands, e-mail: java-dev-help@lucene.apache.org
Re: DO NOT REPLY [Bug 32965] - [PATCH] Use filter bits for next() and skipTo() in FilteredQuery
Posted by Erik Hatcher <er...@ehatchersolutions.com>.
Oh, and one other thing.... Paul's code relies on JDK 1.4's assert
keyword. It seems this is an unnecessary reason to jump to 1.4
dependence.
What do folks think about JDK 1.4 as a minimum Lucene requirement?
Erik
On Apr 3, 2005, at 5:22 PM, bugzilla@apache.org wrote:
> DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG·
> RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
> <http://issues.apache.org/bugzilla/show_bug.cgi?id=32965>.
> ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND·
> INSERTED IN THE BUG DATABASE.
>
> http://issues.apache.org/bugzilla/show_bug.cgi?id=32965
>
>
> paul.elschot@xs4all.nl changed:
>
> What |Removed |Added
> -----------------------------------------------------------------------
> -----
> OtherBugsDependingO| |34279
> nThis| |
>
>
>
>
> --
> Configure bugmail:
> http://issues.apache.org/bugzilla/userprefs.cgi?tab=email
> ------- You are receiving this mail because: -------
> You are the assignee for the bug, or are watching the assignee.
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: java-dev-unsubscribe@lucene.apache.org
> For additional commands, e-mail: java-dev-help@lucene.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: java-dev-unsubscribe@lucene.apache.org
For additional commands, e-mail: java-dev-help@lucene.apache.org