Re: [I] apache jenkins: Failed to save the JUnit test result [lucene]
uschindler commented on issue #14617: URL: https://github.com/apache/lucene/issues/14617#issuecomment-2871366825 Policeman Jenkins gets it installed, ASF Jenkins needs to be pinged:  -- 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.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org - To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org For additional commands, e-mail: issues-h...@lucene.apache.org
Re: [I] apache jenkins: Failed to save the JUnit test result [lucene]
timja commented on issue #14617: URL: https://github.com/apache/lucene/issues/14617#issuecomment-2871353098 fix is available now: https://github.com/jenkinsci/junit-plugin/releases/tag/1334.vd3b_b_2094e438 -- 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.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org - To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org For additional commands, e-mail: issues-h...@lucene.apache.org
[I] Filters cannot be set in Analysis [lucene]
raiAmagi opened a new issue, #14649: URL: https://github.com/apache/lucene/issues/14649 ### Description When I select a filter from the +Add pull-down menu for “Char Filter” and “Token Filters” in the bundled Luke Analysis settings under the environment described in “Version and environment details”, I get the following error The filter cannot be set. I would like to know how to solve this problem. The same problem occurred in versions 10.0.0, 10.1.0, 10.2.0, and 10.2.1. -- 16:40:23 [INFO] org.apache.lucene.luke.app.desktop.LukeMain: Elapsed time for initializing GUI: -28061668 ms 16:40:30 [SEVERE] org.apache.lucene.luke.app.desktop.util.ExceptionHandler: Uncaught Exception java.lang.UnsupportedOperationException at java.base/java.util.ImmutableCollections.uoe(ImmutableCollections.java:142) at java.base/java.util.ImmutableCollections$AbstractImmutableCollection.add(ImmutableCollections.java:147) at org.apache.lucene.luke@10.0.0/org.apache.lucene.luke.app.desktop.components.fragments.analysis.CustomAnalyzerPanelProvider.addCharFilter(CustomAnalyzerPanelProvider.java:510) at org.apache.lucene.luke@10.0.0/org.apache.lucene.luke.app.desktop.components.fragments.analysis.CustomAnalyzerPanelProvider$ListenerFunctions.addCharFilter(CustomAnalyzerPanelProvider.java:790) at java.desktop/javax.swing.JComboBox.fireActionEvent(JComboBox.java:1294) at java.desktop/javax.swing.JComboBox.setSelectedItem(JComboBox.java:619) at java.desktop/javax.swing.JComboBox.setSelectedIndex(JComboBox.java:654) at java.desktop/javax.swing.plaf.basic.BasicComboPopup$Handler.mouseReleased(BasicComboPopup.java:946) at java.desktop/java.awt.AWTEventMulticaster.mouseReleased(AWTEventMulticaster.java:298) at java.desktop/java.awt.Component.processMouseEvent(Component.java:6621) at java.desktop/javax.swing.JComponent.processMouseEvent(JComponent.java:3404) at java.desktop/javax.swing.plaf.basic.BasicComboPopup$1.processMouseEvent(BasicComboPopup.java:551) at java.desktop/java.awt.Component.processEvent(Component.java:6386) at java.desktop/java.awt.Container.processEvent(Container.java:2266) at java.desktop/java.awt.Component.dispatchEventImpl(Component.java:4996) at java.desktop/java.awt.Container.dispatchEventImpl(Container.java:2324) at java.desktop/java.awt.Component.dispatchEvent(Component.java:4828) at java.desktop/java.awt.LightweightDispatcher.retargetMouseEvent(Container.java:4948) at java.desktop/java.awt.LightweightDispatcher.processMouseEvent(Container.java:4575) at java.desktop/java.awt.LightweightDispatcher.dispatchEvent(Container.java:4516) at java.desktop/java.awt.Container.dispatchEventImpl(Container.java:2310) at java.desktop/java.awt.Window.dispatchEventImpl(Window.java:2780) at java.desktop/java.awt.Component.dispatchEvent(Component.java:4828) at java.desktop/java.awt.EventQueue.dispatchEventImpl(EventQueue.java:775) at java.desktop/java.awt.EventQueue$4.run(EventQueue.java:720) at java.desktop/java.awt.EventQueue$4.run(EventQueue.java:714) at java.base/java.security.AccessController.doPrivileged(AccessController.java:400) at java.base/java.security.ProtectionDomain$JavaSecurityAccessImpl.doIntersectionPrivilege(ProtectionDomain.java:87) at java.base/java.security.ProtectionDomain$JavaSecurityAccessImpl.doIntersectionPrivilege(ProtectionDomain.java:98) at java.desktop/java.awt.EventQueue$5.run(EventQueue.java:747) at java.desktop/java.awt.EventQueue$5.run(EventQueue.java:745) at java.base/java.security.AccessController.doPrivileged(AccessController.java:400) at java.base/java.security.ProtectionDomain$JavaSecurityAccessImpl.doIntersectionPrivilege(ProtectionDomain.java:87) at java.desktop/java.awt.EventQueue.dispatchEvent(EventQueue.java:744) at java.desktop/java.awt.EventDispatchThread.pumpOneEventForFilters(EventDispatchThread.java:203) at java.desktop/java.awt.EventDispatchThread.pumpEventsForFilter(EventDispatchThread.java:124) at java.desktop/java.awt.EventDispatchThread.pumpEventsForHierarchy(EventDispatchThread.java:113) at java.desktop/java.awt.EventDispatchThread.pumpEvents(EventDispatchThread.java:109) at java.desktop/java.awt.EventDispatchThread.pumpEvents(EventDispatchThread.java:101) at java.desktop/java.awt.EventDispatchThread.run(EventDispatchThread.java:90) ### Version and environment details OS: windows11 24H2 java: java version "23.0.2" 2025-01-21 Java(TM) SE Runtime Environment (build 23.0.2+7-58) Java HotSpot(TM) 64-Bit Server VM (build 23.0.2+7-58, mixed mode, sharing) Lu
Re: [PR] Build: remove hard-coded Java versions from ecj.javadocs.prefs [lucene]
dsmiley commented on PR #14651: URL: https://github.com/apache/lucene/pull/14651#issuecomment-2873711276 > The command line of ECJ should not be modified. Why; is it perfection? It seems the "compliance" wasn't being set. -- 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.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org - To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org For additional commands, e-mail: issues-h...@lucene.apache.org
Re: [PR] Build: remove hard-coded Java versions from ecj.javadocs.prefs [lucene]
dsmiley commented on code in PR #14651:
URL: https://github.com/apache/lucene/pull/14651#discussion_r2085319708
##
gradle/validation/ecj-lint.gradle:
##
@@ -94,10 +96,10 @@ allprojects {
args += [ "-d", "none" ]
+assert project.java.sourceCompatibility ==
project.java.targetCompatibility
+
// Compilation environment.
-// we use -source/-target as it is significantly faster than --release
Review Comment:
Based on the ECJ documentation I linked with that excerpt, it's not going to
set "release", so we're safe. I should bring back the comment reworded as a
warning to *not* set "release" and to refer back to #484 for further info.
--
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.apache.org
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
-
To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org
For additional commands, e-mail: issues-h...@lucene.apache.org
Re: [PR] Build: remove hard-coded Java versions from ecj.javadocs.prefs [lucene]
dweiss commented on code in PR #14651:
URL: https://github.com/apache/lucene/pull/14651#discussion_r2085322774
##
gradle/validation/ecj-lint.gradle:
##
@@ -94,10 +96,10 @@ allprojects {
args += [ "-d", "none" ]
+assert project.java.sourceCompatibility ==
project.java.targetCompatibility
+
// Compilation environment.
-// we use -source/-target as it is significantly faster than --release
Review Comment:
To me, --release is equivalent to "compliance".
--
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.apache.org
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
-
To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org
For additional commands, e-mail: issues-h...@lucene.apache.org
Re: [PR] Build: remove hard-coded Java versions from ecj.javadocs.prefs [lucene]
uschindler commented on code in PR #14651: URL: https://github.com/apache/lucene/pull/14651#discussion_r2085324735 ## gradle/validation/ecj-lint/ecj.javadocs.prefs: ## @@ -15,9 +15,7 @@ org.eclipse.jdt.core.compiler.annotation.owning=org.eclipse.jdt.annotation.Ownin org.eclipse.jdt.core.compiler.annotation.resourceanalysis=disabled org.eclipse.jdt.core.compiler.codegen.inlineJsrBytecode=enabled org.eclipse.jdt.core.compiler.codegen.methodParameters=do not generate -org.eclipse.jdt.core.compiler.codegen.targetPlatform=24 Review Comment: See my comments below on how to do it. I will push a change to you branch a bit later. I will make sure it reproduces the same settings file for a eclipse IDE as it existed before. Give me a few hours, watching TV -- 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.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org - To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org For additional commands, e-mail: issues-h...@lucene.apache.org
Re: [PR] Build: remove hard-coded Java versions from ecj.javadocs.prefs [lucene]
dweiss commented on code in PR #14651:
URL: https://github.com/apache/lucene/pull/14651#discussion_r2085333753
##
gradle/validation/ecj-lint.gradle:
##
@@ -94,10 +96,10 @@ allprojects {
args += [ "-d", "none" ]
+assert project.java.sourceCompatibility ==
project.java.targetCompatibility
+
// Compilation environment.
-// we use -source/-target as it is significantly faster than --release
Review Comment:
although I just checked and I see no difference on my machine so maybe
they've fixed it.
```
main:
38.53 sec. ecjLintMain
-release:
39.06 sec. ecjLintMain
-24:
38.40 sec. ecjLintMain
```
--
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.apache.org
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
-
To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org
For additional commands, e-mail: issues-h...@lucene.apache.org
Re: [PR] Fix FuzzySet#getEstimatedNumberUniqueValuesAllowingForCollisions to account for hashCount [lucene]
gsmiller merged PR #14614: URL: https://github.com/apache/lucene/pull/14614 -- 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.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org - To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org For additional commands, e-mail: issues-h...@lucene.apache.org
[PR] build: configure 3 retries for all gradle Download tasks [lucene]
rmuir opened a new pull request, #14653: URL: https://github.com/apache/lucene/pull/14653 The default value of retries is 0. Set it to 3, to improve reliability of downloads during builds. Closes #14652 Please review, and make sure I didn't miss any `Download` tasks. The goal was just to add this to all of them, in the hopes that if someone adds a new Download task they will continue to follow the pattern. -- 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.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org - To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org For additional commands, e-mail: issues-h...@lucene.apache.org
Re: [PR] Build: remove hard-coded Java versions from ecj.javadocs.prefs [lucene]
rmuir commented on code in PR #14651:
URL: https://github.com/apache/lucene/pull/14651#discussion_r2085353966
##
gradle/validation/ecj-lint.gradle:
##
@@ -94,10 +96,10 @@ allprojects {
args += [ "-d", "none" ]
+assert project.java.sourceCompatibility ==
project.java.targetCompatibility
+
// Compilation environment.
-// we use -source/-target as it is significantly faster than --release
Review Comment:
To reproduce the slowdown, you need to have a jdk > releaseTarget. E.g.
jdk25 with -release 24 set.
--
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.apache.org
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
-
To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org
For additional commands, e-mail: issues-h...@lucene.apache.org
Re: [PR] Build: remove hard-coded Java versions from ecj.javadocs.prefs [lucene]
dweiss commented on code in PR #14651:
URL: https://github.com/apache/lucene/pull/14651#discussion_r2085357012
##
gradle/validation/ecj-lint.gradle:
##
@@ -94,10 +96,10 @@ allprojects {
args += [ "-d", "none" ]
+assert project.java.sourceCompatibility ==
project.java.targetCompatibility
+
// Compilation environment.
-// we use -source/-target as it is significantly faster than --release
Review Comment:
ah. will try it tomorrow.
--
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.apache.org
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
-
To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org
For additional commands, e-mail: issues-h...@lucene.apache.org
Re: [PR] build: configure 3 retries for all gradle Download tasks [lucene]
dweiss commented on PR #14653: URL: https://github.com/apache/lucene/pull/14653#issuecomment-2873829504 This can be done by applying a single configuration to a task type, Rob (tasks.withType(Download).configureEach...). I'm away from the computer but will tweak it tomorrow. -- 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.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org - To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org For additional commands, e-mail: issues-h...@lucene.apache.org
Re: [PR] build: configure 3 retries for all gradle Download tasks [lucene]
dweiss commented on PR #14653: URL: https://github.com/apache/lucene/pull/14653#issuecomment-2873830885 something like this - https://github.com/apache/lucene/blob/main/gradle/hacks/gradle-archives.gradle -- 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.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org - To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org For additional commands, e-mail: issues-h...@lucene.apache.org
Re: [PR] Catch and re-throw Throwable rather than using a success boolean [lucene]
thecoop commented on PR #14633: URL: https://github.com/apache/lucene/pull/14633#issuecomment-2873415595 I definitely agree that having to have a separate `throw t` as part of the exception handling is trappy (although generally ok due to flow-control changes breaking the compile without it), and I would prefer to have a single line or use try-resources with lambdas in some way, ideally without putting the whole try block in a lambda. I'll have a play around with it & see what happens. -- 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.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org - To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org For additional commands, e-mail: issues-h...@lucene.apache.org
Re: [PR] Early terminate visit BKD leaf when current value greater than upper point in sorted dim. [lucene]
vsop-479 commented on PR #12528: URL: https://github.com/apache/lucene/pull/12528#issuecomment-2872429486 > I would remove the "inverse" case as the inverse visitors are implementation details and IMHO should not be part of the API. FWIW, I implemented "inverse" case with `VisitState`. -- 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.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org - To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org For additional commands, e-mail: issues-h...@lucene.apache.org
Re: [PR] Build: remove hard-coded Java versions from ecj.javadocs.prefs [lucene]
uschindler commented on code in PR #14651:
URL: https://github.com/apache/lucene/pull/14651#discussion_r2084810166
##
gradle/validation/ecj-lint.gradle:
##
@@ -94,10 +96,10 @@ allprojects {
args += [ "-d", "none" ]
+assert project.java.sourceCompatibility ==
project.java.targetCompatibility
+
// Compilation environment.
-// we use -source/-target as it is significantly faster than --release
-args += [ "-source", project.java.sourceCompatibility ]
-args += [ "-target", project.java.targetCompatibility ]
+args += ["-$project.java.sourceCompatibility"] // "compliance" level
Review Comment:
is this correct as just a number?
--
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.apache.org
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
-
To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org
For additional commands, e-mail: issues-h...@lucene.apache.org
Re: [PR] Build: remove hard-coded Java versions from ecj.javadocs.prefs [lucene]
rmuir commented on code in PR #14651: URL: https://github.com/apache/lucene/pull/14651#discussion_r2084808570 ## gradle/validation/ecj-lint/ecj.javadocs.prefs: ## @@ -151,7 +149,6 @@ org.eclipse.jdt.core.compiler.problem.unusedTypeParameter=error org.eclipse.jdt.core.compiler.problem.unusedWarningToken=ignore org.eclipse.jdt.core.compiler.problem.varargsArgumentNeedCast=error org.eclipse.jdt.core.compiler.release=disabled -org.eclipse.jdt.core.compiler.source=24 Review Comment: These need to be set also for IDE integration. It isn't just used for linting. -- 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.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org - To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org For additional commands, e-mail: issues-h...@lucene.apache.org
Re: [PR] Build: remove hard-coded Java versions from ecj.javadocs.prefs [lucene]
uschindler commented on code in PR #14651: URL: https://github.com/apache/lucene/pull/14651#discussion_r2084815606 ## gradle/validation/ecj-lint/ecj.javadocs.prefs: ## @@ -151,7 +149,6 @@ org.eclipse.jdt.core.compiler.problem.unusedTypeParameter=error org.eclipse.jdt.core.compiler.problem.unusedWarningToken=ignore org.eclipse.jdt.core.compiler.problem.varargsArgumentNeedCast=error org.eclipse.jdt.core.compiler.release=disabled -org.eclipse.jdt.core.compiler.source=24 Review Comment: exactly! see my comment below -- 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.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org - To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org For additional commands, e-mail: issues-h...@lucene.apache.org
Re: [PR] Build: remove hard-coded Java versions from ecj.javadocs.prefs [lucene]
uschindler commented on code in PR #14651: URL: https://github.com/apache/lucene/pull/14651#discussion_r2084813285 ## gradle/validation/ecj-lint/ecj.javadocs.prefs: ## @@ -15,9 +15,7 @@ org.eclipse.jdt.core.compiler.annotation.owning=org.eclipse.jdt.annotation.Ownin org.eclipse.jdt.core.compiler.annotation.resourceanalysis=disabled org.eclipse.jdt.core.compiler.codegen.inlineJsrBytecode=enabled org.eclipse.jdt.core.compiler.codegen.methodParameters=do not generate -org.eclipse.jdt.core.compiler.codegen.targetPlatform=24 Review Comment: if we remove this from here the Eclipse task has a problem. The source and target and compliance is then missing and Eclipse IDE fails to compile. If we want to remove this here, we would need to add some task to the Eclipse ICE and append the missing lines. -- 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.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org - To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org For additional commands, e-mail: issues-h...@lucene.apache.org
Re: [PR] Build: remove hard-coded Java versions from ecj.javadocs.prefs [lucene]
dsmiley commented on code in PR #14651:
URL: https://github.com/apache/lucene/pull/14651#discussion_r2084819372
##
gradle/validation/ecj-lint.gradle:
##
@@ -94,10 +96,10 @@ allprojects {
args += [ "-d", "none" ]
+assert project.java.sourceCompatibility ==
project.java.targetCompatibility
+
// Compilation environment.
-// we use -source/-target as it is significantly faster than --release
-args += [ "-source", project.java.sourceCompatibility ]
-args += [ "-target", project.java.targetCompatibility ]
+args += ["-$project.java.sourceCompatibility"] // "compliance" level
Review Comment:
yes. See the link to the documentation that I added
--
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.apache.org
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
-
To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org
For additional commands, e-mail: issues-h...@lucene.apache.org
Re: [PR] Build: remove hard-coded Java versions from ecj.javadocs.prefs [lucene]
uschindler commented on code in PR #14651: URL: https://github.com/apache/lucene/pull/14651#discussion_r2084813285 ## gradle/validation/ecj-lint/ecj.javadocs.prefs: ## @@ -15,9 +15,7 @@ org.eclipse.jdt.core.compiler.annotation.owning=org.eclipse.jdt.annotation.Ownin org.eclipse.jdt.core.compiler.annotation.resourceanalysis=disabled org.eclipse.jdt.core.compiler.codegen.inlineJsrBytecode=enabled org.eclipse.jdt.core.compiler.codegen.methodParameters=do not generate -org.eclipse.jdt.core.compiler.codegen.targetPlatform=24 Review Comment: if we remove this from here the Eclipse task has a problem. The source and target and compliance is then missing and Eclipse IDE fails to compile. If we want to remove this here, we would need to add some task to the Eclipse IDE gradle file and append the missing lines with versions. We do this for classpath already where the java version is setup, too. -- 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.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org - To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org For additional commands, e-mail: issues-h...@lucene.apache.org
Re: [PR] Build: remove hard-coded Java versions from ecj.javadocs.prefs [lucene]
uschindler commented on code in PR #14651: URL: https://github.com/apache/lucene/pull/14651#discussion_r2084825680 ## gradle/validation/ecj-lint/ecj.javadocs.prefs: ## @@ -15,9 +15,7 @@ org.eclipse.jdt.core.compiler.annotation.owning=org.eclipse.jdt.annotation.Ownin org.eclipse.jdt.core.compiler.annotation.resourceanalysis=disabled org.eclipse.jdt.core.compiler.codegen.inlineJsrBytecode=enabled org.eclipse.jdt.core.compiler.codegen.methodParameters=do not generate -org.eclipse.jdt.core.compiler.codegen.targetPlatform=24 Review Comment: My proposal would be: Keep the linter task unmodified and just preprocess the properties file for both Eclipse IDE and ECJ. -- 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.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org - To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org For additional commands, e-mail: issues-h...@lucene.apache.org
Re: [PR] Build: remove hard-coded Java versions from ecj.javadocs.prefs [lucene]
rmuir commented on PR #14651: URL: https://github.com/apache/lucene/pull/14651#issuecomment-2874569307 Sorry, I don't have a better idea other than, try it on branch_10x, using a JDK24 where the "target" is 21. Or maybe "template" the file the same way as is done for `gradle eclipse` and then use that resulting processed file for ecj-linting, rather than CLI flags. -- 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.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org - To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org For additional commands, e-mail: issues-h...@lucene.apache.org
Re: [I] Nightly benchmark regression on 2025.05.01 [lucene]
mikemccand commented on issue #14630: URL: https://github.com/apache/lucene/issues/14630#issuecomment-2874503575 Thanks @jpountz -- I had done a full system update (`pacman -Syyu`) on 2025-05-01, and lots of packages were updated, including kernel: ``` [2025-05-01T10:18:13-0400] [ALPM] upgraded linux (6.12.4.arch1-1 -> 6.14.4.arch1-2) ``` So maybe one of these other packages somehow caused the slowdown ... but first I'll try putting just Java 23 back and then we can see/iterate. I'm also not liking these unrelated hardware errors!! But they are pre-existing for a long time now... ``` [864752.786334] [Hardware Error]: Unified Memory Controller Ext. Error Code: 0 [864752.786365] EDAC MC0: 1 CE on mc#0csrow#3channel#4 (csrow:3 channel:4 page:0x16f7d3 offset:0x340 grain:64 syndrome:0x1) [864752.882910] [Hardware Error]: cache level: L3/GEN, tx: GEN, mem-tx: RD [887362.459304] mce: [Hardware Error]: Machine check events logged [887362.493034] [Hardware Error]: Corrected error, no action required. [887362.527169] [Hardware Error]: CPU:2 (17:31:0) MC17_STATUS[-|CE|MiscV|AddrV|-|-|SyndV|CECC|-|-|Scrub]: 0x9c204100011b [887362.593777] [Hardware Error]: Error Addr: 0x4bdf4940 [887362.627330] [Hardware Error]: IPID: 0x009600450f00, Syndrome: 0xa2e800010a800e03 ``` Yay ECC RAM! -- 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.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org - To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org For additional commands, e-mail: issues-h...@lucene.apache.org
Re: [PR] Build: remove hard-coded Java versions from ecj.javadocs.prefs [lucene]
uschindler commented on PR #14651: URL: https://github.com/apache/lucene/pull/14651#issuecomment-2874579010 Use Jdk 25 EA to check. Jenkins does this all the time. -- 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.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org - To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org For additional commands, e-mail: issues-h...@lucene.apache.org
Re: [PR] Build: remove hard-coded Java versions from ecj.javadocs.prefs [lucene]
uschindler commented on code in PR #14651: URL: https://github.com/apache/lucene/pull/14651#discussion_r2085643653 ## gradle/validation/ecj-lint/ecj.javadocs.prefs: ## @@ -151,7 +149,6 @@ org.eclipse.jdt.core.compiler.problem.unusedTypeParameter=error org.eclipse.jdt.core.compiler.problem.unusedWarningToken=ignore org.eclipse.jdt.core.compiler.problem.varargsArgumentNeedCast=error org.eclipse.jdt.core.compiler.release=disabled -org.eclipse.jdt.core.compiler.source=24 Review Comment: i fixed this in a later commit -- 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.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org - To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org For additional commands, e-mail: issues-h...@lucene.apache.org
Re: [PR] Build: remove hard-coded Java versions from ecj.javadocs.prefs [lucene]
uschindler commented on code in PR #14651: URL: https://github.com/apache/lucene/pull/14651#discussion_r2085644555 ## gradle/validation/ecj-lint/ecj.javadocs.prefs: ## @@ -15,9 +15,7 @@ org.eclipse.jdt.core.compiler.annotation.owning=org.eclipse.jdt.annotation.Ownin org.eclipse.jdt.core.compiler.annotation.resourceanalysis=disabled org.eclipse.jdt.core.compiler.codegen.inlineJsrBytecode=enabled org.eclipse.jdt.core.compiler.codegen.methodParameters=do not generate -org.eclipse.jdt.core.compiler.codegen.targetPlatform=24 Review Comment: I fixed this in 965a00b006a419288a4284be8ef1d2f365484fee -- 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.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org - To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org For additional commands, e-mail: issues-h...@lucene.apache.org
Re: [PR] Build: remove hard-coded Java versions from ecj.javadocs.prefs [lucene]
uschindler commented on PR #14651: URL: https://github.com/apache/lucene/pull/14651#issuecomment-2874398269 I fixed the eclipse setup in https://github.com/apache/lucene/pull/14651/commits/965a00b006a419288a4284be8ef1d2f365484fee It basically adds the follwoing to the settingss file generated for eclipse config: ``` org.eclipse.jdt.core.compiler.codegen.targetPlatform=24 org.eclipse.jdt.core.compiler.compliance=24 org.eclipse.jdt.core.compiler.source=24 ``` To me all is fine, just try to figure out with @dweiss and @rmuir if the release flag is enabled or not. At least in my eclipse settings the "release" is not checked in the options, only source and compliance level are set. Target does not exist in eclipse config. -- 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.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org - To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org For additional commands, e-mail: issues-h...@lucene.apache.org
Re: [PR] Build: remove hard-coded Java versions from ecj.javadocs.prefs [lucene]
rmuir commented on PR #14651: URL: https://github.com/apache/lucene/pull/14651#issuecomment-2874408782 > To me all is fine, just try to figure out with @dweiss and @rmuir if the release flag is enabled or not. Please don't do it here. Please make separate PR if you want to enable that flag: it needs to be backed by benchmarks on JDK > releaseVersion, as the performance issues with it won't show with JDK == releaseVersion. -- 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.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org - To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org For additional commands, e-mail: issues-h...@lucene.apache.org
Re: [PR] Build: remove hard-coded Java versions from ecj.javadocs.prefs [lucene]
uschindler commented on PR #14651: URL: https://github.com/apache/lucene/pull/14651#issuecomment-2874416695 > > To me all is fine, just try to figure out with @dweiss and @rmuir if the release flag is enabled or not. > > Please don't do it here. Please make separate PR if you want to enable that flag: it needs to be backed by benchmarks on JDK > releaseVersion, as the performance issues with it won't show with JDK == releaseVersion. I can just give my observation: When the compliance level is set, the Eclipse IDE does not show the "release" setting enabled:  -- 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.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org - To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org For additional commands, e-mail: issues-h...@lucene.apache.org
Re: [PR] Build: remove hard-coded Java versions from ecj.javadocs.prefs [lucene]
uschindler commented on PR #14651: URL: https://github.com/apache/lucene/pull/14651#issuecomment-2874423257 But of course it may be different with the command line parameters. But to me it looks like Eclipse disables the release flag and compliance is just a combination of above pictures "source" and "target" settings and version specific preview flags. -- 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.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org - To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org For additional commands, e-mail: issues-h...@lucene.apache.org
Re: [PR] Enabling point range collector always if doc values not indexed [lucene]
github-actions[bot] commented on PR #14559: URL: https://github.com/apache/lucene/pull/14559#issuecomment-2874652171 This PR has not had activity in the past 2 weeks, labeling it as stale. If the PR is waiting for review, notify the d...@lucene.apache.org list. Thank you for your contribution! -- 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.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org - To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org For additional commands, e-mail: issues-h...@lucene.apache.org
Re: [I] Nightly benchmark regression on 2025.05.01 [lucene]
rmuir commented on issue #14630: URL: https://github.com/apache/lucene/issues/14630#issuecomment-2874660497 Thats a big kernel jump. But it is hard to reason about, or declare a problem, because I'm still not sure what we are benchmarking here. See vmstat graphs: https://benchmarks.mikemccandless.com/2025.05.01.10.59.59/index.html from my perspective, the system is idling. We should max out the hardware? -- 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.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org - To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org For additional commands, e-mail: issues-h...@lucene.apache.org
Re: [PR] Build: remove hard-coded Java versions from ecj.javadocs.prefs [lucene]
dsmiley commented on code in PR #14651: URL: https://github.com/apache/lucene/pull/14651#discussion_r2085289312 ## gradle/validation/ecj-lint/ecj.javadocs.prefs: ## @@ -15,9 +15,7 @@ org.eclipse.jdt.core.compiler.annotation.owning=org.eclipse.jdt.annotation.Ownin org.eclipse.jdt.core.compiler.annotation.resourceanalysis=disabled org.eclipse.jdt.core.compiler.codegen.inlineJsrBytecode=enabled org.eclipse.jdt.core.compiler.codegen.methodParameters=do not generate -org.eclipse.jdt.core.compiler.codegen.targetPlatform=24 Review Comment: > If we want to remove this here, we would need to add some task to the Eclipse ICE and append the missing lines. Sounds better than the current practice of a hard-coded Java version number in 3 places in this file! -- 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.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org - To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org For additional commands, e-mail: issues-h...@lucene.apache.org
Re: [PR] Build: remove hard-coded Java versions from ecj.javadocs.prefs [lucene]
dweiss commented on code in PR #14651:
URL: https://github.com/apache/lucene/pull/14651#discussion_r2085278571
##
gradle/validation/ecj-lint.gradle:
##
@@ -94,10 +96,10 @@ allprojects {
args += [ "-d", "none" ]
+assert project.java.sourceCompatibility ==
project.java.targetCompatibility
+
// Compilation environment.
-// we use -source/-target as it is significantly faster than --release
Review Comment:
I would be actually more keen on using explicit source/target/release
options - much easier to understand when you're debugging options at some
point. The major problem is that this "compliance" you switched to is actually
using the release flag, which - according to the comment above - used to be
much slower than just source/target (we did have it at some point).
--
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.apache.org
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
-
To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org
For additional commands, e-mail: issues-h...@lucene.apache.org
Re: [PR] Build: remove hard-coded Java versions from ecj.javadocs.prefs [lucene]
dsmiley commented on code in PR #14651:
URL: https://github.com/apache/lucene/pull/14651#discussion_r2085285767
##
gradle/validation/ecj-lint.gradle:
##
@@ -94,10 +96,10 @@ allprojects {
args += [ "-d", "none" ]
+assert project.java.sourceCompatibility ==
project.java.targetCompatibility
+
// Compilation environment.
-// we use -source/-target as it is significantly faster than --release
Review Comment:
I didn't see a CLI based "compliance" explicit switch, although "-$version"
is documented to set the compliance. Would setting this *and* source & target
work?
> is actually using the release flag
I suppose you are looking at its source code, maybe, to deduce that?
--
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.apache.org
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
-
To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org
For additional commands, e-mail: issues-h...@lucene.apache.org
Re: [PR] Build: remove hard-coded Java versions from ecj.javadocs.prefs [lucene]
dweiss commented on code in PR #14651:
URL: https://github.com/apache/lucene/pull/14651#discussion_r2085298100
##
gradle/validation/ecj-lint.gradle:
##
@@ -94,10 +96,10 @@ allprojects {
args += [ "-d", "none" ]
+assert project.java.sourceCompatibility ==
project.java.targetCompatibility
+
// Compilation environment.
-// we use -source/-target as it is significantly faster than --release
Review Comment:
you didn't see the switch because it was commented out - because it was much
much slower than source/target and we use javac with java version compliance
settings anyway (so anything wrong there would be detected before it hits ecj).
I think this duplicated checking + slow execution of compliance mode in ecj was
the motivation to comment it out.
--
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.apache.org
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
-
To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org
For additional commands, e-mail: issues-h...@lucene.apache.org
Re: [PR] Build: remove hard-coded Java versions from ecj.javadocs.prefs [lucene]
dweiss commented on code in PR #14651:
URL: https://github.com/apache/lucene/pull/14651#discussion_r2085295730
##
gradle/validation/ecj-lint.gradle:
##
@@ -94,10 +96,10 @@ allprojects {
args += [ "-d", "none" ]
+assert project.java.sourceCompatibility ==
project.java.targetCompatibility
+
// Compilation environment.
-// we use -source/-target as it is significantly faster than --release
Review Comment:
Hmm... I'm looking at the link you included in the patch? And I see this:
So it looks like -[num] is equivalent to setting --source, --target and
--release to the same number? Am I reading it wrong?
--
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.apache.org
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
-
To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org
For additional commands, e-mail: issues-h...@lucene.apache.org
Re: [PR] Build: remove hard-coded Java versions from ecj.javadocs.prefs [lucene]
dweiss commented on code in PR #14651:
URL: https://github.com/apache/lucene/pull/14651#discussion_r2085299262
##
gradle/validation/ecj-lint.gradle:
##
@@ -94,10 +96,10 @@ allprojects {
args += [ "-d", "none" ]
+assert project.java.sourceCompatibility ==
project.java.targetCompatibility
+
// Compilation environment.
-// we use -source/-target as it is significantly faster than --release
Review Comment:
See #484
--
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.apache.org
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
-
To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org
For additional commands, e-mail: issues-h...@lucene.apache.org
[I] asynchronous I/O + saturating NVMe bandwidth [lucene]
shbakram opened a new issue, #14655:
URL: https://github.com/apache/lucene/issues/14655
### Description
The intersection of fast NVMe SSDs that offer high I/O concurrency and
io_uring is leading to a momentum toward asynchronous request processing. For
example, PostgreSQL is the latest example to consider support for io_uring.
Our in-house analysis shows that io_uring provides better throughput for
NVMe SSDs than FileChannel#read/write and FileChannel#mmap. Others have reached
the same conclusion.
[JUring](https://www.phoronix.com/news/JUring-IO_uring-Java)
io_uring is a Linux kernel asynchronous I/O interface that allows
applications to queue multiple I/O operations into a ring buffer and submit
them all with a single syscall, enabling improved batched I/O over AIO and
user-level thread-based approaches. What does this development mean for Lucene?
Talking to Mike recently, it does seem there is room for improving query
throughput in Lucene when the index cannot fit in available DRAM capacity. It
is well-known that DRAM is a limited resource, and datasets grow faster than
improved DRAM scaling. In real-time cases, especially, limited DRAM is
pressured from new index updates (memtable), query cache, page cache, and Java
heap (including garbage). Hence, SSD serves as an extension and optimizing SSD
throughput is critical for important use cases out there.
Taking the full advantage of NVMe/io_uring requires submitting large I/O
batches. These batches can come from a single request but this limits I/O
concurrency to queries with popular terms only. Or they can come from multiple
requests. In the latter case, for example, gather read requests for index pages
from multiple queries and submit them as a batch. Then, start processing
queries when I/Os complete in any order. (Avoiding details of handling corner
cases and ordering constraints for now).
In any case, quoting Mike, “Lucene's cross-segment concurrency ("thread per
slice" within a single query) helps some with I/O concurrency, but that's still
at the whim of the index geometry, which is horribly leaky abstraction e.g., an
"optimized" index (single segment) loses all concurrency!”
I believe taking full advantage of asynchronous I/O requires a shift to a
new posting format.
So, I suggest a radical shift in the underlying posting format. Give up
log-structured format (LSM)! Give up segments. LSM aims for sequential I/O,
which is no longer relevant for NVMe SSDs. Have one monolithic index. Each term
initially gets a page for its posting and related data. If the term is popular,
progressively assign it chunks of multiple pages. Pages/chunks are chained
using forward pointers. These pointers will be stored in an on-heap (or
in-memory) data structure similar to skip offsets. (Embrace random SSD I/Os.) A
single request can be broken down into many random pages on an SSD, and all
these pages are part of the batch for io_submit(). On the write path,
similarly, gather all updates in a submit buffer and issue hundreds of random
I/Os.
Terms are no longer sorted, so range queries may suffer. Still, on-heap FST
provides a sorted view of terms. It's just they are not sorted on storage. On
the flip side, there is no CPU to waste on sorting and merging. A reasonable
tradeoff for the rapidly shifting underlying hardware technology. Saved CPU can
serve more queries in the case of real-time search (an important use case for
social media platforms).
There are many challenges indeed. What about (crash) consistency? Segments
make it easier to deal with failures somewhat gracefully. With some effort, one
can maintain logs that contain sufficient information to recover an index in
the event of failure. There are fewer index management operations like merging
so that helps offset the overhead of maintaining additional logs.
What about real-time search? Currently, the near real-time API requires
substantial effort to reopen the index using DirectoryReader.openIfChanged().
My analysis shows its overhead is prohibitive for reasonably sized indexes. The
new posting format would require less effort to expose the most recent
in-memory changes to index searchers (omitting details).
Is there a better way to utilize io_uring and fully leverage NVMe potential
without requiring radical changes to the index format? For example, has someone
observed using the new prefetch API coupled with a lot of searcher threads as a
way to saturate NVMe? Even then, I believe it does not increase I/O concurrency
on the write path. Large I/Os on the write path help, but I believe large I/Os
alone do not fully exploit the internal parallelism of modern SSDs.
I just want to start a discussion on this subject after some initial
exchanges with Mike. Thoughts?
--
This is an automated message from the Apache Git Service.
To respond to the message, ple
[I] MMapDirectory.PRELOAD_HINT should also consider FileTypeHint.INDEX [lucene]
jpountz opened a new issue, #14650: URL: https://github.com/apache/lucene/issues/14650 ### Description Currently, `MMapDirectory.PRELOAD_HINT` only looks at the `PreloadHint.INSTANCE`. In my opinion, it should look at `FileTypeHint.INDEX` as well: index files are very small by contract, and file formats expect them to reside in memory, so it makes sense to make them preloaded to avoid cold starts. An alternative would be to pass the `PreloadHint.INSTANCE` hint to every index file, but I like this alternative less. My mental model is that index files are expected to reside in memory while data files are generally not, and the `PreloadHint.INSTANCE` hint is a flag that should be set on the small minority of data files that need to reside in memory for decent performance. By the way, maybe `PreloadHint` should be renamed to `InMemoryHint` or something along these lines, to signal that the file is expected to reside in memory rather than that it should be preloaded. And then preloading is a way to help the OS load it in memory at open time instead of waiting for it to naturally get loaded in memory over time as a result of the OS figuring out that all pages of this file are hot. -- 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.apache.org.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org - To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org For additional commands, e-mail: issues-h...@lucene.apache.org
Re: [I] Nightly benchmark regression on 2025.05.01 [lucene]
jpountz commented on issue #14630: URL: https://github.com/apache/lucene/issues/14630#issuecomment-2872249319 I tried to reproduce the slowdown locally by - comparing on the commit just before we started requiring Java 24, with the baseline on Java 23 and the contender on Java 24 (by passing `javaCommand=...` on the competitor in my localrun.py), - by comparing the commit that started requiring Java 24 with current main, both on Java 24 However, neither of these benchmarks reported a significant performance difference, despite my CPU (AMD Ryzen 9 3900X) being similar to beast's. -- 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.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org - To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org For additional commands, e-mail: issues-h...@lucene.apache.org
Re: [I] TopFieldCollector mistakenly assumes that all leaves share the same index sort [lucene]
jpountz commented on issue #14399: URL: https://github.com/apache/lucene/issues/14399#issuecomment-2872278104 What are the two cases that you have in mind? I don't think that having a collector with a cache makes sense since it has an assumption that leaves are uniform, which may not be correct. However, we could have different `LeafCollector`s for the case when the search sort is a prefix of the index sort on the one hand, and the case when the sort sort is not a prefix of the index sort on the other hand. -- 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.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org - To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org For additional commands, e-mail: issues-h...@lucene.apache.org
Re: [PR] Early terminate visit BKD leaf when current value greater than upper point in sorted dim. [lucene]
vsop-479 commented on PR #12528: URL: https://github.com/apache/lucene/pull/12528#issuecomment-2872432747 I will try to measure the performance. -- 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.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org - To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org For additional commands, e-mail: issues-h...@lucene.apache.org
Re: [PR] Build: remove hard-coded Java versions from ecj.javadocs.prefs [lucene]
uschindler commented on code in PR #14651: URL: https://github.com/apache/lucene/pull/14651#discussion_r2084813285 ## gradle/validation/ecj-lint/ecj.javadocs.prefs: ## @@ -15,9 +15,7 @@ org.eclipse.jdt.core.compiler.annotation.owning=org.eclipse.jdt.annotation.Ownin org.eclipse.jdt.core.compiler.annotation.resourceanalysis=disabled org.eclipse.jdt.core.compiler.codegen.inlineJsrBytecode=enabled org.eclipse.jdt.core.compiler.codegen.methodParameters=do not generate -org.eclipse.jdt.core.compiler.codegen.targetPlatform=24 Review Comment: if we remove this from here the Eclipse IDE task has a problem. The source and target and compliance is then missing and Eclipse IDE fails to compile. If we want to remove this here, we would need to add some task to the Eclipse IDE gradle file and append the missing lines with versions. We do this for classpath already where the java version is setup, too. -- 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.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org - To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org For additional commands, e-mail: issues-h...@lucene.apache.org
Re: [PR] Add instructions to help/IDEs.txt for VSCode and Neovim [lucene]
rmuir merged PR #14646: URL: https://github.com/apache/lucene/pull/14646 -- 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.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org - To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org For additional commands, e-mail: issues-h...@lucene.apache.org
Re: [PR] Build: remove hard-coded Java versions from ecj.javadocs.prefs [lucene]
dsmiley commented on PR #14651: URL: https://github.com/apache/lucene/pull/14651#issuecomment-2872842933 I'm hoping an Eclipse user could improve this PR to address that side of the equation. I've never used Eclipse. -- 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.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org - To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org For additional commands, e-mail: issues-h...@lucene.apache.org
Re: [PR] Don't perform additional KNN querying after timeout, fixes #14639 [lucene]
msokolov merged PR #14640: URL: https://github.com/apache/lucene/pull/14640 -- 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.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org - To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org For additional commands, e-mail: issues-h...@lucene.apache.org
Re: [I] Fix bad interaction between optimistic query and query timeout [lucene]
msokolov closed issue #14639: Fix bad interaction between optimistic query and query timeout URL: https://github.com/apache/lucene/issues/14639 -- 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.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org - To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org For additional commands, e-mail: issues-h...@lucene.apache.org
Re: [PR] Build: remove hard-coded Java versions from ecj.javadocs.prefs [lucene]
uschindler commented on PR #14651: URL: https://github.com/apache/lucene/pull/14651#issuecomment-2873022378 > I'm hoping an Eclipse user could improve this PR to address that side of the equation. I've never used Eclipse. Not sure how, but if we remove the java version from the ecj javadocs setting file, we have to add the back in the .settings directory for the Eclipse IDE: https://github.com/apache/lucene/blob/92e0eb8f71e2eaad8c2d18890ed3e506bbfdc5b8/gradle/ide/eclipse.gradle#L96-L100 At this place it processes all files in the `dot.settings` directory and replaces the tag: https://github.com/apache/lucene/blob/92e0eb8f71e2eaad8c2d18890ed3e506bbfdc5b8/gradle/ide/eclipse/dot.settings/org.eclipse.jdt.core.prefs#L4 So maybe we just need to add the target version here and set those three properties. Uwe -- 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.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org - To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org For additional commands, e-mail: issues-h...@lucene.apache.org
Re: [PR] Build: remove hard-coded Java versions from ecj.javadocs.prefs [lucene]
uschindler commented on PR #14651:
URL: https://github.com/apache/lucene/pull/14651#issuecomment-2873029220
Something like:
```groovy
filter(ReplaceTokens, tokens: [
'ecj-lint-config':
ecjLintFile.getText('UTF-8').replaceAll(/=error\b/, '=' + errorMode)
+'org.eclipse.jdt.core.compiler.codegen.targetPlatform='+targetVersion /.
and so on
])
```
--
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.apache.org
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
-
To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org
For additional commands, e-mail: issues-h...@lucene.apache.org
Re: [PR] Build: remove hard-coded Java versions from ecj.javadocs.prefs [lucene]
uschindler commented on PR #14651: URL: https://github.com/apache/lucene/pull/14651#issuecomment-2873032572 But in general: Iw would keep the properties file as is and inject the Java version there. The command line of ECJ should not be modified. -- 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.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org - To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org For additional commands, e-mail: issues-h...@lucene.apache.org
