[
https://issues.apache.org/jira/browse/LUCENE-3241?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13057635#comment-13057635
]
Chris Male commented on LUCENE-3241:
I will re-evaluate the tests and port what I
[
https://issues.apache.org/jira/browse/LUCENE-3261?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Shai Erera updated LUCENE-3261:
---
Attachment: facet-userguide.pdf
Attaching the userguide from LUCENE-3079.
Faceting module
[
https://issues.apache.org/jira/browse/LUCENE-3264?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13057668#comment-13057668
]
Shai Erera commented on LUCENE-3264:
Patch looks very good. All tests pass for me
[
https://issues.apache.org/jira/browse/LUCENE-3241?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13057694#comment-13057694
]
Chris Male commented on LUCENE-3241:
Command for patch:
{code}
svn move
[
https://issues.apache.org/jira/browse/LUCENE-3241?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Chris Male updated LUCENE-3241:
---
Attachment: LUCENE-3241.patch
New patch which incorporates Robert's suggestions.
I have salvaged
[
https://issues.apache.org/jira/browse/LUCENE-3079?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Shai Erera resolved LUCENE-3079.
Resolution: Fixed
Faceting module in 3.x and trunk, tests pass, opened follow up issues. I think
[
https://issues.apache.org/jira/browse/LUCENE-3216?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Simon Willnauer updated LUCENE-3216:
Attachment: LUCENE-3216.patch
we are getting closer to the overall target here. This
[
https://issues.apache.org/jira/browse/LUCENE-3216?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Simon Willnauer updated LUCENE-3216:
Attachment: LUCENE-3239.patch
since the vote has passed here is a patch to cut over the
[
https://issues.apache.org/jira/browse/LUCENE-3142?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Doron Cohen resolved LUCENE-3142.
-
Resolution: Fixed
r1141465: trunk
r1141468: 3x
benchmark/stats package is obsolete and unused
[
https://issues.apache.org/jira/browse/LUCENE-3216?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Simon Willnauer updated LUCENE-3216:
Comment: was deleted
(was: since the vote has passed here is a patch to cut over the
[
https://issues.apache.org/jira/browse/LUCENE-3216?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Simon Willnauer updated LUCENE-3216:
Attachment: (was: LUCENE-3239.patch)
Store DocValues per segment instead of per
[
https://issues.apache.org/jira/browse/LUCENE-3239?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Simon Willnauer updated LUCENE-3239:
Attachment: LUCENE-3239.patch
this patch moves the build and metadata to 1.6
drop java
[
https://issues.apache.org/jira/browse/LUCENE-3239?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13057765#comment-13057765
]
Uwe Schindler commented on LUCENE-3239:
---
Patch looks fine, Jenkins already moved.
[
https://issues.apache.org/jira/browse/LUCENE-3239?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13057772#comment-13057772
]
Simon Willnauer commented on LUCENE-3239:
-
I just committed that patch, I will
[
https://issues.apache.org/jira/browse/LUCENE-3239?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Simon Willnauer updated LUCENE-3239:
Attachment: LUCENE-3239.patch
here is a patch that fixes almost all todos except of the
[
https://issues.apache.org/jira/browse/LUCENE-3260?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13057778#comment-13057778
]
Michael McCandless commented on LUCENE-3260:
Thanks Shai!
The 200+
[
https://issues.apache.org/jira/browse/LUCENE-3239?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13057780#comment-13057780
]
Uwe Schindler commented on LUCENE-3239:
---
+1 as a start
drop java 5 support
[
https://issues.apache.org/jira/browse/LUCENE-3239?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13057781#comment-13057781
]
Simon Willnauer commented on LUCENE-3239:
-
bq. +1 as a start
alright I'll kick it
[
https://issues.apache.org/jira/browse/LUCENE-3239?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Simon Willnauer reassigned LUCENE-3239:
---
Assignee: Simon Willnauer
drop java 5 support
-
Cut over to Java 6 API where needed / possible
--
Key: LUCENE-3265
URL: https://issues.apache.org/jira/browse/LUCENE-3265
Project: Lucene - Java
Issue Type: Task
Affects Versions: 4.0
Improve FileLocking based on Java 1.6
--
Key: LUCENE-3266
URL: https://issues.apache.org/jira/browse/LUCENE-3266
Project: Lucene - Java
Issue Type: Improvement
Components: core/store
[
https://issues.apache.org/jira/browse/LUCENE-3239?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Simon Willnauer resolved LUCENE-3239.
-
Resolution: Fixed
Fix Version/s: 4.0
Lucene Fields: [New, Patch Available]
[
https://issues.apache.org/jira/browse/LUCENE-3264?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13057792#comment-13057792
]
Robert Muir commented on LUCENE-3264:
-
{quote}
Previously the tests took 1m20s to
[
https://issues.apache.org/jira/browse/LUCENE-3265?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13057794#comment-13057794
]
Robert Muir commented on LUCENE-3265:
-
I think we should be careful here: any
Build:
https://builds.apache.org/job/Lucene-Solr-tests-only-flexscoring-branch/66/
3 tests failed.
REGRESSION:
org.apache.solr.client.solrj.embedded.MultiCoreExampleJettyTest.testDistributed
Error Message:
Severe errors in solr configuration. Check your log files for more detailed
hmm are you concerned about the extra Math.min that happens in the
copyOf method?
I don't how that relates to intrinsic and java 1.7
I don't have strong feelings here just checking if you mix something
up in the comment you put there... I am happy to keep the old and now
current code
simon
On
Hi Robert,
you reverted a use of Arrays.copyOf() on native types which is *exactly*
implemented like this in Arrays.java code!
The slow ones are T T[] copyOf(T[] array, int newlen)
(because they use reflection).
Uwe
-
Uwe Schindler
H.-H.-Meier-Allee 63, D-28213 Bremen
because on windows 32bit at least, -client is still the default on
most jres out there.
i realize people don't care about -client, but i will police
foo[].clone() / arrays.copyOf etc to prevent problems.
There are comments about this stuff on the relevant bug reports
(oracle's site is down,
Robert I agree but doesn't that apply to Arrays.copyOf(Object[],int)
only? here we use a specialized primitive version?
simon
On Thu, Jun 30, 2011 at 3:05 PM, Robert Muir rcm...@gmail.com wrote:
because on windows 32bit at least, -client is still the default on
most jres out there.
i realize
Arrays.copyOf(primitive) is actually System.arraycopy by default. If
intrinsics are used it can only get faster. For object types it will
probably be a bit slower for -client because of a runtime check for
the component type.
Dawid
On Thu, Jun 30, 2011 at 3:05 PM, Robert Muir rcm...@gmail.com
Robert,
as noted in my other eMail, ist only slow for the generic Object[] method (as
it uses j.l.reflect.Array.newInstance(Class componentType)). We are talking
here about byte[], and the Arrays method is implemented with the same 3 lines
of code, Simon replaced. The only difference is a
We had an issue about this with FST's array growing in Mike's code, in facts
ist *much* slower for generic Arrays' T[] copyOf(T[]...), with T extends Object
(uses slow reflection).
For primitives it can only get faster in later JVMs, this is why we want to
change all ArrayUtils.grow() to use
On Thu, Jun 30, 2011 at 3:26 PM, Uwe Schindler u...@thetaphi.de wrote:
We had an issue about this with FST's array growing in Mike's code, in facts
ist *much* slower for generic Arrays' T[] copyOf(T[]...), with T extends
Object (uses slow reflection).
For primitives it can only get faster
[
https://issues.apache.org/jira/browse/SOLR-2565?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13057829#comment-13057829
]
Mark Miller commented on SOLR-2565:
---
Committed - there is still some wiki work to do.
[
https://issues.apache.org/jira/browse/SOLR-2193?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Mark Miller reopened SOLR-2193:
---
Assignee: Mark Miller (was: Robert Muir)
Re-architect Update Handler
---
[
https://issues.apache.org/jira/browse/SOLR-2193?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13057833#comment-13057833
]
Mark Miller commented on SOLR-2193:
---
This issue is superceded by: SOLR-2565 Prevent
[
https://issues.apache.org/jira/browse/SOLR-2193?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13057834#comment-13057834
]
Mark Miller commented on SOLR-2193:
---
bq. Curious; why is the resolution status invalid?
[
https://issues.apache.org/jira/browse/SOLR-2193?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Mark Miller resolved SOLR-2193.
---
Resolution: Duplicate
Re-architect Update Handler
---
[
https://issues.apache.org/jira/browse/SOLR-2565?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Mark Miller reassigned SOLR-2565:
-
Assignee: Mark Miller
Prevent IW#close and cut over to IW#commit
I think that the code here shows a bug in Lucene.NET, see
http://gist.github.com/1056231.
This happens when using 2.9.2.
After some digging I think that it's due to the way it does a Prefix search.
The main problem is shown by this code http://gist.github.com/1056242.
If the Locale is Danish,
Build: https://builds.apache.org/job/Lucene-Solr-Maven-trunk/166/
No tests ran.
Build Log (for compile errors):
[...truncated 10375 lines...]
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional
Hey Matt,
This is issue 420: https://issues.apache.org/jira/browse/LUCENENET-420
I think the theory so far has been that the user should manage the culture
rather than Lucene. If you disagree could you post on that issue ticket?
Thanks,
-Ben
- Original Message -
From: Matt Warren
I think Dawid is correct here... so we should change this back? still
personally when I see array clone() or copyOf() it makes me concerned, I
know these are as fast as arraycopy in recent versions, but depending on
which variant is used, and whether you use -server, can be slower... in
general I
Thanks for the info, after reading issue 420 it makes sense now
On 30 June 2011 15:38, Ben West bwsithspaw...@yahoo.com wrote:
Hey Matt,
This is issue 420: https://issues.apache.org/jira/browse/LUCENENET-420
I think the theory so far has been that the user should manage the culture
rather
[
https://issues.apache.org/jira/browse/LUCENE-3216?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Simon Willnauer updated LUCENE-3216:
Attachment: LUCENE-3216.patch
one more iteration adding a NestedCompoundDirectory that
[
https://issues.apache.org/jira/browse/LUCENE-3260?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13057896#comment-13057896
]
Shai Erera commented on LUCENE-3260:
I see. Thanks for the clarification. +1 to
[
https://issues.apache.org/jira/browse/LUCENE-3216?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13057894#comment-13057894
]
Michael McCandless commented on LUCENE-3216:
Looks great!
So this means, if
[
https://issues.apache.org/jira/browse/LUCENE-3216?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13057900#comment-13057900
]
Simon Willnauer commented on LUCENE-3216:
-
{quote}
So this means, if you use
[
https://issues.apache.org/jira/browse/LUCENE-3264?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13057901#comment-13057901
]
Robert Muir commented on LUCENE-3264:
-
{quote}
I don't understand. I thought that you
[
https://issues.apache.org/jira/browse/LUCENE-2793?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13057903#comment-13057903
]
Simon Willnauer commented on LUCENE-2793:
-
Varun this patch looks great. I am
[
https://issues.apache.org/jira/browse/LUCENE-3264?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13057906#comment-13057906
]
Shai Erera commented on LUCENE-3264:
Thanks Robert. This makes sense to me.
bq.
[
https://issues.apache.org/jira/browse/LUCENE-3260?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Michael McCandless resolved LUCENE-3260.
Resolution: Fixed
Fix Version/s: 4.0
need a test that uses
[
https://issues.apache.org/jira/browse/LUCENE-3216?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13057935#comment-13057935
]
Robert Muir commented on LUCENE-3216:
-
{quote}
I am not sure here, I had the same
[
https://issues.apache.org/jira/browse/SOLR-1674?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Mark Miller updated SOLR-1674:
--
Assignee: Robert Muir (was: Mark Miller)
improve analysis tests, cut over to new API
Build: https://builds.apache.org/job/Lucene-Solr-Maven-trunk/167/
No tests ran.
Build Log (for compile errors):
[...truncated 7426 lines...]
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands,
Although there are a lot of people using Lucene.Net, this is our
contribution report for the past 5 years.
https://issues.apache.org/jira/secure/ConfigureReport.jspa?atl_token=A5KQ-2Q
AV-T4JA-FDED|3204f7e696067a386144705075c074e991db2a2b|linversionId=-1issue
[
https://issues.apache.org/jira/browse/LUCENE-3216?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13057967#comment-13057967
]
Simon Willnauer commented on LUCENE-3216:
-
I will back out the config stuff and
On Thu, Jun 30, 2011 at 4:44 PM, Robert Muir rcm...@gmail.com wrote:
I think Dawid is correct here... so we should change this back? still
personally when I see array clone() or copyOf() it makes me concerned, I
know these are as fast as arraycopy in recent versions, but depending on
which
[
https://issues.apache.org/jira/browse/LUCENE-3264?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Robert Muir resolved LUCENE-3264.
-
Resolution: Fixed
ok, committed and backported.
I think we should open followup issue(s):
*
[
https://issues.apache.org/jira/browse/LUCENE-3246?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13057979#comment-13057979
]
Uwe Schindler commented on LUCENE-3246:
---
Hi Mike,
As we have now both variants to
[
https://issues.apache.org/jira/browse/LUCENE-3179?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13057980#comment-13057980
]
Uwe Schindler commented on LUCENE-3179:
---
Any other comments/microbenchmarks from
I don't seen any evidence that this is any slower though.
You need to run with -client (if the machine is a beast this is tricky
because x64 will pick -server regardless of the command-line setting)
and you need to be copying generic arrays. I think this can be shown
-- a caliper benchmark would
I think it's important Lucene keeps good performance on ordinary
machines/envs.
It's really quite dangerous that the active Lucene devs all use beasts
for development/testing. We draw false conclusions.
So we really should be testing with -client and if indeed generified
Arrays.copyOf (and
I'd say that is all the more reasons that we need to work smarter and not
harder. I'd also say thats a good reason to make sure we build consensus
rather than just saying whoever commits code wins.
And its a damn good reason to focus on the effort of growing the number of
contributors and lowing
I think it's important Lucene keeps good performance on ordinary
machines/envs.
Not that this voice will help in anything, but I think the above is
virtually impossible to achieve unless you have a bunch of machines,
OSs and VMs to continually test on and a consistent set of benchmarks
plotted
[
https://issues.apache.org/jira/browse/LUCENE-2341?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Dawid Weiss resolved LUCENE-2341.
-
Resolution: Fixed
In trunk. Long live 1.6 support.
explore morfologik integration
Build: https://builds.apache.org/job/Lucene-Solr-tests-only-3.x/9208/
1 tests failed.
REGRESSION:
org.apache.lucene.facet.util.TestScoredDocIDsUtils.testWithDeletions
Error Message:
Wrong number of (live) documents expected:65 but was:64
Stack Trace:
junit.framework.AssertionFailedError:
Fair enough, and I agree.
Though the least we could do is rotate in a Windows env, where Java
runs with -client, to our Jenkins.
But simple-to-follow rules like Don't use Arrays.copyOf; use
System.arraycopy instead (if indeed System.arraycopy seems to
generally not be slower) seem like a
this one reproduces, and just beasting the test, looks like this test
fails ~ 2% of the time on trunk and branch_3x
On Thu, Jun 30, 2011 at 3:24 PM, Apache Jenkins Server
jenk...@builds.apache.org wrote:
Build: https://builds.apache.org/job/Lucene-Solr-tests-only-3.x/9208/
1 tests failed.
Build: https://builds.apache.org/job/Lucene-Solr-tests-only-trunk/9205/
All tests passed
Build Log (for compile errors):
[...truncated 10841 lines...]
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional
javadocs failed. I'll fix it.
Dawid
On Thu, Jun 30, 2011 at 9:35 PM, Apache Jenkins Server
jenk...@builds.apache.org wrote:
Build: https://builds.apache.org/job/Lucene-Solr-tests-only-trunk/9205/
All tests passed
Build Log (for compile errors):
[...truncated 10841 lines...]
Michael,
I agree with everything you said. My point in saying whoever commits code
wins was to illustrate the reality of how and why the project has the
current form.
Building consensus is difficult. It is an essential first step before we can
do something like make a list of bit-sized pieces of
On Thu, Jun 30, 2011 at 8:50 PM, Dawid Weiss
dawid.we...@cs.put.poznan.pl wrote:
I don't seen any evidence that this is any slower though.
You need to run with -client (if the machine is a beast this is tricky
because x64 will pick -server regardless of the command-line setting)
and you need
[
https://issues.apache.org/jira/browse/LUCENE-1879?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13058072#comment-13058072
]
hao yan commented on LUCENE-1879:
-
Hi, Michael
Is there any lastest progress on this
Ok I think I asked the wrong question. I am trying to figure out where to
put my time. I was thinking about working on the automated porting system,
but when I saw the response to the .NET 4.0 discussions I started to
question if that is the right direction. The community seemed to be more
: There's no sense in CHANGES being a 'rolling list', when someone looks
: at 4.0 they should be able to see whats DIFFERENT aka what CHANGED
: from the past release.
I agree completely, the disagreement is *which* past release the list
should be relative to.
I don't know how many more ways i
On Thu, Jun 30, 2011 at 4:45 PM, Simon Willnauer
simon.willna...@googlemail.com wrote:
On Thu, Jun 30, 2011 at 8:50 PM, Dawid Weiss
dawid.we...@cs.put.poznan.pl wrote:
I don't seen any evidence that this is any slower though.
You need to run with -client (if the machine is a beast this is
[
https://issues.apache.org/jira/browse/LUCENE-3246?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13058107#comment-13058107
]
Michael McCandless commented on LUCENE-3246:
bq. As we have now both variants
[
https://issues.apache.org/jira/browse/SOLR-2623?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13058112#comment-13058112
]
Hoss Man commented on SOLR-2623:
Alexey: at first glance, i think i would prefer Shalin's
[
https://issues.apache.org/jira/browse/LUCENE-2793?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13058116#comment-13058116
]
Michael McCandless commented on LUCENE-2793:
To address the nocommits about
check-legal-lucene always checks contrib/queries/lib
Key: LUCENE-3267
URL: https://issues.apache.org/jira/browse/LUCENE-3267
Project: Lucene - Java
Issue Type: Bug
Components:
[
https://issues.apache.org/jira/browse/LUCENE-3241?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Chris Male resolved LUCENE-3241.
Resolution: Fixed
Committed revision 1141747.
Remove Lucene core's FunctionQuery impls
[
https://issues.apache.org/jira/browse/LUCENE-2883?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Chris Male resolved LUCENE-2883.
Resolution: Fixed
Committed revision 1141749.
Its done. Finally.
Consolidate Solr Lucene
[
https://issues.apache.org/jira/browse/LUCENE-3267?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13058138#comment-13058138
]
Chris Male commented on LUCENE-3267:
Woops, committed wrong thing with this issue
[
https://issues.apache.org/jira/browse/LUCENE-3267?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Chris Male updated LUCENE-3267:
---
Attachment: LUCENE-3267.patch
Actual patch for this issue.
Removes the offending
[
https://issues.apache.org/jira/browse/LUCENE-2883?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13058142#comment-13058142
]
Robert Muir commented on LUCENE-2883:
-
Thanks for all your hard refactoring work here
[
https://issues.apache.org/jira/browse/LUCENE-3267?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13058145#comment-13058145
]
Robert Muir commented on LUCENE-3267:
-
+1
check-legal-lucene always checks
[
https://issues.apache.org/jira/browse/LUCENE-2309?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13058146#comment-13058146
]
Chris Male commented on LUCENE-2309:
I'd like to pick this issue up and run with it.
TestScoredDocIDsUtils.testWithDeletions test failure
Key: LUCENE-3268
URL: https://issues.apache.org/jira/browse/LUCENE-3268
Project: Lucene - Java
Issue Type: Bug
Components:
Speed up Top-K sampling tests
-
Key: LUCENE-3269
URL: https://issues.apache.org/jira/browse/LUCENE-3269
Project: Lucene - Java
Issue Type: Test
Components: modules/facet
Reporter: Robert
additional tests enhancements to faceting module
Key: LUCENE-3270
URL: https://issues.apache.org/jira/browse/LUCENE-3270
Project: Lucene - Java
Issue Type: Test
Components:
On Thu, Jun 30, 2011 at 6:02 PM, Chris Hostetter
hossman_luc...@fucit.org wrote:
: There's no sense in CHANGES being a 'rolling list', when someone looks
: at 4.0 they should be able to see whats DIFFERENT aka what CHANGED
: from the past release.
I agree completely, the disagreement is
Move 'good' contrib/queries classes to Queries module
-
Key: LUCENE-3271
URL: https://issues.apache.org/jira/browse/LUCENE-3271
Project: Lucene - Java
Issue Type: Improvement
On Jun 30, 2011, at 9:00 PM, Robert Muir wrote:
when they look at CHANGES.txt they just want to know what
changed since the last release.
+1
- Mark Miller
lucidimagination.com
-
To unsubscribe, e-mail:
[
https://issues.apache.org/jira/browse/LUCENE-3271?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13058170#comment-13058170
]
Robert Muir commented on LUCENE-3271:
-
Thanks for working to clean this up! a few of
[
https://issues.apache.org/jira/browse/SOLR-752?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Simon Jacob updated SOLR-752:
-
Attachment: compressedtextfield.patch
I have attempted to add support for compressed stored fields by
Hi,
when looking at just a very quick glance at some of the newer
grouping/join features, I found myself a little confused about what is
exactly what, and I think users might too.
I discussed some of this with hossman, and it only seemed to make me
even more totally confused about:
* difference
Hi,
On Fri, Jul 1, 2011 at 2:30 PM, Robert Muir rcm...@gmail.com wrote:
Hi,
when looking at just a very quick glance at some of the newer
grouping/join features, I found myself a little confused about what is
exactly what, and I think users might too.
I discussed some of this with
[
https://issues.apache.org/jira/browse/LUCENE-3271?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13058187#comment-13058187
]
Chris Male edited comment on LUCENE-3271 at 7/1/11 2:39 AM:
[
https://issues.apache.org/jira/browse/LUCENE-3271?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13058187#comment-13058187
]
Chris Male edited comment on LUCENE-3271 at 7/1/11 2:40 AM:
1 - 100 of 124 matches
Mail list logo
