sejal-pawar commented on pull request #159:
URL: https://github.com/apache/lucene/pull/159#issuecomment-888702505
> Thanks @sejal-pawar! This is more what I was originally describing in the
Jira issue. Thanks for updating your PR!
>
> I left some small comments on variable naming,
gautamworah96 commented on pull request #175:
URL: https://github.com/apache/lucene/pull/175#issuecomment-888545634
I gave this PR another shot (since the Palantir plugin has been patched in
v2.0.0 for Gradle 7 support), but had some new issues come up. The good news, I
*think* that using
gsmiller commented on pull request #227:
URL: https://github.com/apache/lucene/pull/227#issuecomment-888503779
> and explicitly rejects numbers of bits per value > 32
Ah right, of course this would be an issue here. Thanks for clarifying!
--
This is an automated message from the
mayya-sharipova commented on a change in pull request #214:
URL: https://github.com/apache/lucene/pull/214#discussion_r678516508
##
File path: lucene/core/src/java/org/apache/lucene/index/DirectoryReader.java
##
@@ -122,6 +122,23 @@ public static DirectoryReader open(final
mayya-sharipova commented on a change in pull request #214:
URL: https://github.com/apache/lucene/pull/214#discussion_r678507441
##
File path: lucene/core/src/java/org/apache/lucene/index/DirectoryReader.java
##
@@ -122,6 +122,23 @@ public static DirectoryReader open(final
[
https://issues.apache.org/jira/browse/LUCENE-10016?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17388899#comment-17388899
]
Michael Sokolov commented on LUCENE-10016:
--
as for the demo, there is a start on something we
[
https://issues.apache.org/jira/browse/LUCENE-10033?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17388892#comment-17388892
]
Adrien Grand commented on LUCENE-10033:
---
Unfortunately I noticed that the sorted queries that
jpountz commented on pull request #227:
URL: https://github.com/apache/lucene/pull/227#issuecomment-888479181
Indeed I wanted to get something out quickly for benchmarking where I could
easily play with different block sizes, while ForUtil is very rigid (hardcoded
block size of 128 and
gautamworah96 commented on a change in pull request #220:
URL: https://github.com/apache/lucene/pull/220#discussion_r678493344
##
File path:
lucene/facet/src/java/org/apache/lucene/facet/taxonomy/directory/DirectoryTaxonomyWriter.java
##
@@ -475,8 +477,15 @@ private int
gsmiller commented on pull request #227:
URL: https://github.com/apache/lucene/pull/227#issuecomment-888465657
This is really interesting/exciting!
I'm working through this PR now but I notice you've used a slightly
different approach to the FOR encoding (compared to what's done in
[
https://issues.apache.org/jira/browse/LUCENE-10040?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17388877#comment-17388877
]
Adrien Grand commented on LUCENE-10040:
---
bq. Performance can be unpredictable. If deletions are
[
https://issues.apache.org/jira/browse/LUCENE-10016?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17388868#comment-17388868
]
Robert Muir commented on LUCENE-10016:
--
Even if it isn't in the o.a.l.demo module, a simple test
[
https://issues.apache.org/jira/browse/LUCENE-10016?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17388866#comment-17388866
]
Adrien Grand commented on LUCENE-10016:
---
One thing that would still be missing would be the
mikemccand commented on a change in pull request #157:
URL: https://github.com/apache/lucene/pull/157#discussion_r678412320
##
File path:
lucene/core/src/java/org/apache/lucene/analysis/AutomatonToTokenStream.java
##
@@ -0,0 +1,197 @@
+/*
+ * Licensed to the Apache Software
wuda0112 commented on a change in pull request #224:
URL: https://github.com/apache/lucene/pull/224#discussion_r678424267
##
File path:
lucene/codecs/src/java/org/apache/lucene/codecs/simpletext/SimpleTextSkipReader.java
##
@@ -0,0 +1,179 @@
+/*
+ * Licensed to the Apache
[
https://issues.apache.org/jira/browse/LUCENE-10015?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17388834#comment-17388834
]
Julie Tibshirani edited comment on LUCENE-10015 at 7/28/21, 3:09 PM:
[
https://issues.apache.org/jira/browse/LUCENE-10015?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17388834#comment-17388834
]
Julie Tibshirani commented on LUCENE-10015:
---
> In case it's helpful context: currently we
[
https://issues.apache.org/jira/browse/LUCENE-10039?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17388813#comment-17388813
]
ASF subversion and git services commented on LUCENE-10039:
--
Commit
[
https://issues.apache.org/jira/browse/LUCENE-9823?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17388814#comment-17388814
]
ASF subversion and git services commented on LUCENE-9823:
-
Commit
[
https://issues.apache.org/jira/browse/LUCENE-10039?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Julie Tibshirani resolved LUCENE-10039.
---
Fix Version/s: 8.10
Resolution: Fixed
> With a single field,
jtibshirani merged pull request #2535:
URL: https://github.com/apache/lucene-solr/pull/2535
--
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:
jtibshirani opened a new pull request #2535:
URL: https://github.com/apache/lucene-solr/pull/2535
When there's only one field, CombinedFieldQuery will ignore its weight while
scoring. This makes the scoring inconsistent, since the field weight is
supposed
to multiply its term
[
https://issues.apache.org/jira/browse/LUCENE-10038?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Steven Rowe deleted LUCENE-10038:
-
> i have no issue
> ---
>
> Key: LUCENE-10038
> URL:
[
https://issues.apache.org/jira/browse/LUCENE-10016?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17388806#comment-17388806
]
Julie Tibshirani commented on LUCENE-10016:
---
Deletions are an interesting topic, I opened
Julie Tibshirani created LUCENE-10040:
-
Summary: Handle deletions in nearest vector search
Key: LUCENE-10040
URL: https://issues.apache.org/jira/browse/LUCENE-10040
Project: Lucene - Core
[
https://issues.apache.org/jira/browse/LUCENE-9304?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17388804#comment-17388804
]
ASF subversion and git services commented on LUCENE-9304:
-
Commit
dnhatn commented on pull request #228:
URL: https://github.com/apache/lucene/pull/228#issuecomment-888337488
Merged, thanks @mrkm4ntr. It's preferable to have a Jira ticket opened
before having a pull request. But it's okay for this change as it's
straightforward.
--
This is an
[
https://issues.apache.org/jira/browse/LUCENE-9304?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17388803#comment-17388803
]
ASF subversion and git services commented on LUCENE-9304:
-
Commit
dnhatn merged pull request #228:
URL: https://github.com/apache/lucene/pull/228
--
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:
jpountz commented on pull request #220:
URL: https://github.com/apache/lucene/pull/220#issuecomment-888288068
> What is the use of the LiveIndexWriterConfig.createdVersionMajor
It's very expert. It's necessary if you have multiple workers creating
indices that you then want to merge
mikemccand commented on pull request #157:
URL: https://github.com/apache/lucene/pull/157#issuecomment-888287420
> We have been using this change internally for a few weeks now. We no
longer encounter the ArrayIndexOutOfBounds exceptions that we were previously
experiencing. Depending on
[
https://issues.apache.org/jira/browse/LUCENE-10035?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17388751#comment-17388751
]
Adrien Grand commented on LUCENE-10035:
---
Wow! This is impressive work!
> Simple text codec add
mikemccand commented on pull request #225:
URL: https://github.com/apache/lucene/pull/225#issuecomment-888278654
> I suggest, please let's not try to "overshare" and refactor all this stuff
alongside DFA stuff until there is a query we can actually benchmark to see if
the performance is
[
https://issues.apache.org/jira/browse/LUCENE-10039?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17388737#comment-17388737
]
ASF subversion and git services commented on LUCENE-10039:
--
Commit
jtibshirani merged pull request #229:
URL: https://github.com/apache/lucene/pull/229
--
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:
jpountz commented on a change in pull request #224:
URL: https://github.com/apache/lucene/pull/224#discussion_r678249370
##
File path:
lucene/codecs/src/java/org/apache/lucene/codecs/simpletext/SimpleTextSkipReader.java
##
@@ -0,0 +1,179 @@
+/*
+ * Licensed to the Apache
rmuir commented on a change in pull request #225:
URL: https://github.com/apache/lucene/pull/225#discussion_r678255582
##
File path:
lucene/core/src/java/org/apache/lucene/util/automaton/NFARunAutomaton.java
##
@@ -0,0 +1,225 @@
+/*
+ * Licensed to the Apache Software
rmuir commented on pull request #225:
URL: https://github.com/apache/lucene/pull/225#issuecomment-888270205
> This is super exciting! I'm amazed how little code you needed to get this
first version running.
but a runautomaton for this won't run any queries on its own: brute force
jtibshirani commented on pull request #229:
URL: https://github.com/apache/lucene/pull/229#issuecomment-888241745
Great point, the existing test `testCopyFieldWithMissingFields` only very
rarely triggers this case.
--
This is an automated message from the Apache Git Service.
To respond
jtibshirani opened a new pull request #229:
URL: https://github.com/apache/lucene/pull/229
When there's only one field, CombinedFieldQuery will ignore its weight while
scoring. This makes the scoring inconsistent, since the field weight is
supposed
to multiply its term frequency.
Julie Tibshirani created LUCENE-10039:
-
Summary: With a single field, CombinedFieldQuery can score
incorrectly
Key: LUCENE-10039
URL: https://issues.apache.org/jira/browse/LUCENE-10039
Project:
[
https://issues.apache.org/jira/browse/LUCENE-?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Julie Tibshirani resolved LUCENE-.
--
Fix Version/s: 8.10
Resolution: Fixed
> CombinedFieldQuery can fail when
[
https://issues.apache.org/jira/browse/LUCENE-7020?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17388572#comment-17388572
]
Adrien Grand commented on LUCENE-7020:
--
I've just seen a similar issue to the one that Shawn is
mahnoor jabbar created LUCENE-10038:
---
Summary: i have no issue
Key: LUCENE-10038
URL: https://issues.apache.org/jira/browse/LUCENE-10038
Project: Lucene - Core
Issue Type: New Feature
44 matches
Mail list logo
