akhgeek30 commented on issue #11864:
URL: https://github.com/apache/lucene/issues/11864#issuecomment-1291592656
@romseygeek It might be possible the bug is present at SOLR but do you think
hardcoding the value inside the newSynonymQuery method is feasible if the list
is empty? In the method
mcimadamore commented on PR #912:
URL: https://github.com/apache/lucene/pull/912#issuecomment-1291775655
@uschindler Just curious - did you get any feedback re. performance? Thanks
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitH
uschindler commented on PR #912:
URL: https://github.com/apache/lucene/pull/912#issuecomment-1291795040
Hi @mcimadamore
> @uschindler Just curious - did you get any feedback re. performance? Thanks
No official feedback yet. But Elasticsearch and Opensearch seem to
benchmark. U
mikemccand commented on PR #912:
URL: https://github.com/apache/lucene/pull/912#issuecomment-1291905742
> I will ask @mikemccand to at least enable --enable-preview on the nightly
pure Lucene benchmark by default (and use JDK 19).
Ack -- I'll enable this starting from tonite's run.
reta commented on PR #11875:
URL: https://github.com/apache/lucene/pull/11875#issuecomment-1291944060
Thanks @jpountz
> Adding a getter works for me,
:+1:
> but I'd prefer not to make other implementation details like the custom
bulk scorer public, why do you need thi
msokolov opened a new pull request, #11878:
URL: https://github.com/apache/lucene/pull/11878
... on operands until doubleValue() is called
This doesn't change the outcome in any way and may have some positive impact
if there are expensive advancers in the closure of the expression.
uschindler commented on PR #912:
URL: https://github.com/apache/lucene/pull/912#issuecomment-1292321865
@mikemccand Maybe do this in a 2 step process:
- First update to Java 19, so we get a clean state
- Then add `--enable-preview`
If we do both at same time, we won't see a diffe
timoteostewart opened a new pull request, #11879:
URL: https://github.com/apache/lucene/pull/11879
### Description
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment
gf2121 opened a new pull request, #11880:
URL: https://github.com/apache/lucene/pull/11880
After https://github.com/apache/lucene/pull/11876 I find some other codes
are still using`Arrays#compareUnAssigned` which can be repaced by
`ByteArrayComparator` or `ArrayUtil#compareUnsigned4`.
msokolov merged PR #11878:
URL: https://github.com/apache/lucene/pull/11878
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: issues-unsubscr...@lucene.ap
jmazanec15 commented on issue #11354:
URL: https://github.com/apache/lucene/issues/11354#issuecomment-1292424527
@harishankar-gopalan I am not sure. The benchmarks I ran above compare merge
with and without my draft PR changes - all containing KNN vector field.
--
This is an automated mes
gsmiller opened a new pull request, #11881:
URL: https://github.com/apache/lucene/pull/11881
### Description
This change optimizes the doc-at-a-time drill-sideways scoring approach to
borrow ideas from the "min should match" logic in `WANDScorer`.
Note that `luceneutil` doesn't
gf2121 closed pull request #436: LUCENE-10231: Do not cache too large
PointInSetQuery
URL: https://github.com/apache/lucene/pull/436
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comm
jebnix commented on issue #11870:
URL: https://github.com/apache/lucene/issues/11870#issuecomment-1292531335
@msokolov @dweiss As active contributors, any opinions?
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
U
dweiss commented on issue #11870:
URL: https://github.com/apache/lucene/issues/11870#issuecomment-1292543030
To be honest - I'd stick to plain javadoc in code documentation. It's
supported by the tools, it's the standard everyone expects and it's there when
you're browsing the source code.
gsmiller commented on PR #11881:
URL: https://github.com/apache/lucene/pull/11881#issuecomment-1292806151
Converting to DRAFT temporarily to add some more testing. While the
randomized testing does cover the various use-cases, I think it would be good
to increase the testing given the non-t
zhaih opened a new pull request, #11882:
URL: https://github.com/apache/lucene/pull/11882
### Description
issue #11839
It's my first time really working on gradle script so I'm pretty uncertain
whether I've done something wrong :) I tested with `./gradlew coverage` and it
dweiss commented on code in PR #11882:
URL: https://github.com/apache/lucene/pull/11882#discussion_r1006457852
##
lucene/build.gradle:
##
@@ -15,6 +15,8 @@
* limitations under the License.
*/
+apply plugin: 'java'
Review Comment:
I don't know what that aggregate report
dweiss commented on code in PR #11882:
URL: https://github.com/apache/lucene/pull/11882#discussion_r1006460293
##
lucene/build.gradle:
##
@@ -15,6 +15,8 @@
* limitations under the License.
*/
+apply plugin: 'java'
Review Comment:
Seems to me like report aggregation is
19 matches
Mail list logo
