ove BaseTokenStreamTestCase to uses a fake attribute to check if
> clearAttributes() was called correctly - found bugs in contrib/analyzers
> -
>
> K
because of incorrect Token
reuse in a call to this.next(reusableToken). This patch now also contains the
merged LUCENE-1939, which was missing.
I commit this now.
> Improve BaseTokenStreamTestCase to uses a fake attribute to check if
> clearAttributes() was called correctly - found bugs in c
() was called correctly - found bugs in contrib/analyzers
(was: Advances BaseTokenStreamTestCase that uses a fake attribute to check, if
clearAttributes() was called correctly - found bugs in contrib/analyzers)
> Improve BaseTokenStreamTestCase to uses a fake attribute to check
to check if
> clearAttributes() was called correctly - found bugs in contrib/analyzers
> -
>
> Key: LUCENE-2211
>
ces BaseTokenStreamTestCase that uses a fake attribute to check, if
> clearAttributes() was called correctly - found bugs in contrib/ana
9639
> Advances BaseTokenStreamTestCase that uses a fake attribute to check, if
> clearAttributes() was called correctly - found bugs in contrib
ces BaseTokenStreamTestCase that uses a fake attribute to check, if
> clearAttributes() was called correctly - found bugs in contrib/analyzers
> -
>
>
s etc.
> Advances BaseTokenStreamTestCase that uses a fake attribute to check, if
> clearAttributes() was called correctly - found bugs in contri
9627
> Advances BaseTokenStreamTestCase that uses a fake attribute to check, if
> clearAttributes() was called correctly - found bugs in contrib
, 2 in
highlighter, 1 in memory.
i also fixed all helper tokenstreams in core/contrib tests.
> Advances BaseTokenStreamTestCase that uses a fake attribute to check, if
> clearAttributes() was called correctly - found bugs in contrib/ana
still call
clearAttributes to force TS to not reuse attributes from previous calls to
incrementToken(). This was one of the first traps, Robert investigated in 2.9.
> Advances BaseTokenStreamTestCase that uses a fake attribute to check, if
> clearAttributes() was called correctly - found b
ces BaseTokenStreamTestCase that uses a fake attribute to check, if
> clearAttributes() was called correctly - found bugs in contrib/ana
tried all
others i could find but I think the rest are ok.
> Advances BaseTokenStreamTestCase that uses a fake attribute to check, if
> clearAttributes() was called correctly - found bugs in contrib/ana
rectly - found bugs in contrib/analyzers
> -
>
> Key: LUCENE-2211
> URL: https://issues.apache.org/jira/
ly - found bugs in contrib/analyzers
> -
>
> Key: LUCENE-2211
> URL: https://issues.apache.org/j
ds, n-gram filter, and edge n-gram filter
> Advances BaseTokenStreamTestCase that uses a fake attribute to check, if
> clearAttributes() was called correctly - found bugs in contri
2.9.2
The ngram things are serious, so also backport.
We get the non-generic java 1.4 version for solr 1.5 for free.
> Advances BaseTokenStreamTestCase that uses a fake attribute to check, if
> clearAttributes() was called correctly - found bugs in contrib/ana
ute to check, if
> clearAttributes() was called correctly - found bugs in contrib/analyzers
> -
>
> Key: LUCENE-2211
>
Advances BaseTokenStreamTestCase that uses a fake attribute to check, if
clearAttributes() was called correctly - found bugs in contrib/analyzers
er, in the future please notify me about any suspected bugs in
Luke, otherwise I may miss reports like this.
--
Best regards,
Andrzej Bialecki <><
___. ___ ___ ___ _ _ __
[__ || __|__/|__||\/| Information Retrieval, Semantic Web
___|||__
ke really means is there are 0 fields found in the index, ie it's an
empty index.
You're lucky that I spotted this message ... ;)
I'll fix it in the next minor release of Luke, pretty soon.
However, in the future please notify me about any suspected bugs in
Luke, otherwise
[
https://issues.apache.org/jira/browse/LUCENE-740?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Karl Wettin closed LUCENE-740.
--
Resolution: Won't Fix
Duplicate, see LUCENE-1142
> Bugs in contrib/snowball/.../SnowballProg
[
https://issues.apache.org/jira/browse/LUCENE-1249?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Michael McCandless resolved LUCENE-1249.
Resolution: Fixed
Thanks David!
> Bugs
[
https://issues.apache.org/jira/browse/LUCENE-1249?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Michael McCandless reassigned LUCENE-1249:
--
Assignee: Michael McCandless
> Bugs
[
https://issues.apache.org/jira/browse/LUCENE-1249?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Michael Busch updated LUCENE-1249:
--
Fix Version/s: (was: 2.3.2)
2.4
> Bugs
Bugs in org.apache.lucene.index.TermVectorsReader.clone()
-
Key: LUCENE-1249
URL: https://issues.apache.org/jira/browse/LUCENE-1249
Project: Lucene - Java
Issue Type: Bug
])
Committed.
> BoostingTermQuery.explain() bugs
>
>
> Key: LUCENE-991
> URL: https://issues.apache.org/jira/browse/LUCENE-991
> Project: Lucene - Java
> Issue Type: Bug
> Compone
[
https://issues.apache.org/jira/browse/LUCENE-991?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12525734
]
Peter Keegan commented on LUCENE-991:
-
Confirmed - thanks.
> BoostingTermQuery.explain() b
similarity change and the
test passes
> BoostingTermQuery.explain() bugs
>
>
> Key: LUCENE-991
> URL: https://issues.apache.org/jira/browse/LUCENE-991
> Project: Lucene - Java
>
;ll see the difference. Even terms with 0 weight are
included in the explanation. Make sense?
Peter
> BoostingTermQuery.explain() bugs
>
>
> Key: LUCENE-991
> URL: https://issues.apache.org/jira/browse/LUCENE-991
. Attached is an update of the
Test, plus a fix for #1.
> BoostingTermQuery.explain() bugs
>
>
> Key: LUCENE-991
> URL: https://issues.apache.org/jira/browse/LUCENE-991
> Project: Lucene - Java
>
the fact that the Similarity override for this test sets the
tf() to 1, regardless of the frequency coming in. Thus, for the "foo" clause,
it
Let me know what you think of this patch.
> BoostingTermQuery.explain() bugs
>
>
>
True("hits Size: " + hits.totalHits + " is not: " + 0, hits.totalHits ==
0);
Or, perhaps I am missing something? I guess I don't see why the boost part
needs to be in there? Can't you have a test that has no payloa
[
https://issues.apache.org/jira/browse/LUCENE-991?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Grant Ingersoll reassigned LUCENE-991:
--
Assignee: Grant Ingersoll
> BoostingTermQuery.explain() b
[
https://issues.apache.org/jira/browse/LUCENE-991?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Peter Keegan updated LUCENE-991:
Attachment: TestBoostingTermQuery.patch
Added 'testNoPayload'
> BoostingTermQuery.e
BoostingTermQuery.explain() bugs
Key: LUCENE-991
URL: https://issues.apache.org/jira/browse/LUCENE-991
Project: Lucene - Java
Issue Type: Bug
Components: Search
Affects Versions: 2.2
-LICENSE.TXT
to the META-INF dir of the snowball jar after LUCENE-908 is committed and the
manifests are customizable.
Thanks for the patch, Steven!
> Bugs in contrib/snowball/.../SnowballProgram.java -> Kraaij-Pohlmann gives
> Index-OOB
commit it today in case there are no objections.
> Bugs in contrib/snowball/.../SnowballProgram.java -> Kraaij-Pohlmann gives
> Index-OOB Exception
> --
>
> Key: LUCENE-740
>
license files
in the patch could be applied, since 2.2 seems to be catching lots of those.
> Bugs in contrib/snowball/.../SnowballProgram.java -> Kraaij-Pohlmann gives
> Index-OOB
[
https://issues.apache.org/jira/browse/LUCENE-740?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Steven Parkes updated LUCENE-740:
-
Attachment: 740-license.txt
> Bugs in contrib/snowball/.../SnowballProgram.java ->
ve added a few lines
to NOTICE.txt as seems to be required(?):
http://www.apache.org/licenses/example-NOTICE.txt
> Bugs in contrib/snowball/.../SnowballProgram.java -> Kraaij-Pohlmann gives
> Index-OOB Exception
>
icense
too, as something like SNOWBALL-LICENSE.txt.
> Bugs in contrib/snowball/.../SnowballProgram.java -> Kraaij-Pohlmann gives
> Index-OOB Exception
> --
>
>
necessary?
Did the original snowball authors agree to license the software under the
AL2.0? That's what LICENSE.txt says now. The source site cites the BSD license
and says you can't claim it's licensed under another license.
> Bugs in contrib/snowball/.../SnowballProgram.java
ably add a simple test for each stemmer.
2. Licensing: when attaching the patch I granted it for ASF inclusion. But this
only covers my (minimal) changes to this code. Stemmers themselves go under
Snowball licensing - http://snowball.tartarus.org/license.php
> Bugs in con
demostrates this Kp stemmer bug.
Lucene tests and contrib/snowball tests pass.
> Bugs in contrib/snowball/.../SnowballProgram.java -> Kraaij-Pohlmann gives
> Index-OOB Exception
> --
>
[ http://issues.apache.org/jira/browse/LUCENE-740?page=all ]
Doron Cohen updated LUCENE-740:
---
Attachment: snowball.patch.txt
Updated + new stemmers and SnowballProgram fix from http://snowball.tartarus.org
> Bugs in contrib/snowb
[
http://issues.apache.org/jira/browse/LUCENE-740?page=comments#action_12457465 ]
Otis Gospodnetic commented on LUCENE-740:
-
+1 for latest and greatest.
> Bugs in contrib/snowball/.../SnowballProgram.java -> Kraaij-Pohlmann
Lucene, and Hungarian
stemmer was added. Any reason not to update all the stemmers with this fix?
> Bugs in contrib/snowball/.../SnowballProgram.java -> Kraaij-Pohlmann gives
> Index-OOB
[
http://issues.apache.org/jira/browse/LUCENE-740?page=comments#action_12457458 ]
Yonik Seeley commented on LUCENE-740:
-
Speaking of licensing, that should probably be cleaned up.
> Bugs in contrib/snowball/.../SnowballProgram.j
.
> Bugs in contrib/snowball/.../SnowballProgram.java -> Kraaij-Pohlmann gives
> Index-OOB Exception
> --
>
> Key: LUCENE-740
> URL: http://issues.apache.org/j
Bugs in contrib/snowball/.../SnowballProgram.java -> Kraaij-Pohlmann gives
Index-OOB Exception
--
Key: LUCENE-740
URL: http://issues.apache.org/jira/browse/LUCENE-
I am using ParallelMultSearcher to search across 10 different servers.
Here is the problem I bumped into:
Sometimes when I search for a term, my program just hang there. No result,
no response.
I decided to take one server (No. 10 in my list of servers) off the list,
searching was as smooth as i
d say, although I suspect most people
don't vote. I try to vote when I remember and like the fix.
Otis
- Original Message
From: Grant Ingersoll <[EMAIL PROTECTED]>
To: Lucene Developer's List
Sent: Wednesday, June 14, 2006 7:52:01 PM
Subject: Bugs
So, being the new
: > unfortunately, many people don't think to search "resolved" or "closed"
: > bugs for similar problems.
: It's kind of ironic that people working on a search engine wouldn't
: think to search first! :-) Human nature, I guess...
well, yeah ... bu
On Thursday 15 June 2006 13:56, Grant Ingersoll wrote:
> Hey Chris,
...
> >
> If you would like a second pair of eyes on anything, just let me know.
Some sandboxes were mentioned, where's the playground?
Regards,
Paul Elschot
--
Hey Chris,
All good points. See some more of my thoughts below...
Chris Hostetter wrote:
: them are listed as increased priority. There are also a number of bugs
: that date back as far as 2002 which I highly doubt are all that useful
: at this point unless someone wants to patch a specific
: them are listed as increased priority. There are also a number of bugs
: that date back as far as 2002 which I highly doubt are all that useful
: at this point unless someone wants to patch a specific branch.
:
: So, I guess I am wondering where I can be the most helpful? I would
: like to
So, being the newbie committer, I have been looking through the bug list
trying to figure out where I can contribute some help. It seems to me
like there are a lot of patches/bugs that are languishing (through no
one's fault, we are all busy and this is a volunteer project). I know
yo
Chuck Williams wrote:
Thanks Erik. If you don't here more, I'm sure this fixes a whole class
of problems and is better than the previous situation. I'm also
confident that it will do the right thing for all the query types built
into Lucene.
To me Chucks patch also looks very good.
In parall
a whole and computes
the (reasonably) best single query to distribute. This patch is
slightly better than what I sent via email last night:
1. It's a patch that can be applied in the usual way
2. It handles the missing optimization cases I noted in last
night's email
3. It fixes po
te. This patch is slightly better than
what I sent via email last night:
1. It's a patch that can be applied in the usual way
2. It handles the missing optimization cases I noted in last night's
email
3. It fixes potential bugs that would not arise with Lucene's query
t
ght's
email
3. It fixes potential bugs that would not arise with Lucene's query
types but could arise with user-written queries (e.g., user queries that
rewrite differently in arbitrary ways for the different sub-serarchers).
Doug and Wolf, please review the patch. All tests pass
62 matches
Mail list logo
