I don't think I'm as hard core on this as Neal, but remember: the
history of the Lucene.NET project is that all the intellectual work, all
the understanding of search, all the new features come from the Lucene
Java folks. Theirs is an immensely respected project, and I trust them
to add new
Can I just plug in my bit and say I agree 100% with what Moray has outlined
below.
If we move away from the line by line port then over time we'll loose out on
the momentum that is Lucene and the improvements that they make.
It is only if the Lucene.NET community has expertise in search, a
As someone from the nhibernate project
We stopped following hibernate a while ago, and haven't regretted it
We have mire features, less bugs and better code base
Sent from my Windows Phone From: Rory Plaire
Sent: Thursday, June 30, 2011 19:58
To: lucene-net-dev@lucene.apache.org
Subject: Re:
NHibernate has a much bigger community and more active devs afaict.
The proposed changes as I understand them are not about changing class
structure or APIs, but merely touch hunks of code and rewrite them to
use better .NET practices (yield, generics, LINQ etc). In conjunction
with a move
Michael,
You interpret the report as whoever commits code wins? But when I look at it,
I see a lof of talk, no work. .Net community is not interested in
contributing.
I really don't understand what hinders people to work on Lucene.Net. As I did
for 2.9.4g, grab the code, do whatever you want on
A) I don't to want to commit anything thats going to piss alot of people
off,
B) I don't want to spend time/waste time on modifications that are going
to be rejected.
What I've learnt from Apache Way is creating a JIRA issue if you are
hesitant.
If no one answers in a reasonable
DIGY - Re: Why do I wait.. That's mostly because I intend to make some deep
changes, which would make merging the 2.9.4g branch back to trunk difficult.
So, it's easier to merge those changes first. Also, I won't have enough time
to make my changes until a little way in the future, but probably do
Scott -
The idea of the automated port is still worth doing. Perhaps it makes sense
for someone more passionate about the line-by-line idea to do that work?
I would say, focus on what makes sense to you. Being productive, regardless
of the specific direction, is what will be most valuable. Once
Michael -
If you bring those changes from git into a branch in SVN, we can help with
it. It doesn't have to be complete to be committed. :)
Regarding A (angering people)/B (being rejected)/C (feeling comfortable)/D
(getting over it)...
a) Making progress is more important than keeping everyone
I can not say I like this approach, but till we find an automated way(with good
results), it seems to be the only way we can use.
DIGY
-Original Message-
From: Troy Howard [mailto:thowar...@gmail.com]
Sent: Friday, July 01, 2011 12:43 AM
To: lucene-net-dev@lucene.apache.org
Subject:
So, veering towards action - are there concrete tasks written up anywhere
for the unit tests? If a poor schlep like me wanted to dig in and start to
improve them, where would I get the understanding of what is good and what
needs help?
-r
On Thu, Jun 30, 2011 at 3:29 PM, Digy digyd...@gmail.com
On Jul 1, 2011, at 0:49, Bill Janssen jans...@parc.com wrote:
Here's some code implementing a class called PythonModule,
Hmm, no code was received here...
Andi..
which allows Java code to invoke arbitary module-level functions,
and allows use of Python's eval built-in.
The Python code
On Jul 1, 2011, at 0:49, Bill Janssen jans...@parc.com wrote:
Here's some code implementing a class called PythonModule,
Hmm, no code was received here...
Andi..
which allows Java code to invoke arbitary module-level functions,
and allows use of Python's eval built-in.
The Python code
[
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
1 - 100 of 124 matches
Mail list logo
