[GitHub] [lucene] mocobeta opened a new pull request #694: supress Actions jobs when only text files are changed
mocobeta opened a new pull request #694: URL: https://github.com/apache/lucene/pull/694 - A follow-up of #674 - It wouldn't be needed to run check jobs when only text files (CHANGES, etc.) are changed. https://docs.github.com/en/actions/using-workflows/workflow-syntax-for-github-actions#example-excluding-paths -- 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
[GitHub] [lucene] mocobeta commented on pull request #694: supress Actions jobs when only text files are changed
mocobeta commented on pull request #694: URL: https://github.com/apache/lucene/pull/694#issuecomment-1046018874 The syntax is fine - I assume there is no harm in merging this. -- 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
[GitHub] [lucene] rmuir commented on pull request #692: LUCENE-10311: Different implementations of DocIdSetBuilder for points and terms
rmuir commented on pull request #692: URL: https://github.com/apache/lucene/pull/692#issuecomment-1046065536 I'm still a bit confused about why we need to `grow(long)` on a bitset that can only hold `Integer.MAX_VALUE` elements. I've re-read the description of the JIRA several times this morning, but honestly I was confused about this before, too. It seems the only purpose of the `long`, we're doing a lot of elaborate work just to estimate the cardinality that we'll ultimately pass down to the bitset? I don't see any other use of the `long` value other than this `counter`, and that's all we are doing with it. But surely using a `long` isn't helpful to this estimation, maybe we should just estimate it differently? Sorry if my comment isn't very helpful, but I want to really understand the problem and why we need to bring 64 bits into this, currently it is very confusing. Perhaps we should remove this `counter` completely (temporarily), and use the other `BitDocIdSet` constructor. How simpler does the code get then? It turns the problem around, into, how can we estimate the cost better. I don't think we should have to majorly reorganize the code just for this `counter`, it doesn't seem right at all. There are other ways we could estimate the cost rather than summing up the calls to `grow()`. For example in the sparse/buffer case, wouldn't a much simpler estimation simply be the `length` of int array? I'm also confused why we have this sorted array buffer case instead of using SparseFixedBitSet (which has approximateCardinality already and needs no such special grow-tracking). -- 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
[GitHub] [lucene] dweiss commented on pull request #694: supress Actions jobs when only text files are changed
dweiss commented on pull request #694: URL: https://github.com/apache/lucene/pull/694#issuecomment-1046084341 I wouldn't do it. You never know what those text files - they can be resources that are compiled or used at runtime, etc. Why bother? This is what the CI is for - to make sure we (committers) didn't screw up. -- 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
[GitHub] [lucene] dweiss edited a comment on pull request #694: supress Actions jobs when only text files are changed
dweiss edited a comment on pull request #694: URL: https://github.com/apache/lucene/pull/694#issuecomment-1046084341 I wouldn't do it. You never know what those text files are - they can be resources that are compiled or used at runtime, etc. Why bother? This is what the CI is for - to make sure we (committers) didn't screw up. -- 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
[GitHub] [lucene] mocobeta commented on pull request #693: LUCENE-10400: revise binary dictionaries' constructor in nori
mocobeta commented on pull request #693: URL: https://github.com/apache/lucene/pull/693#issuecomment-1046177607 > We will also have a second PR to remove the deprecated APIs in main branch? Yes, I will. -- 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
[GitHub] [lucene] mocobeta merged pull request #693: LUCENE-10400: revise binary dictionaries' constructor in nori
mocobeta merged pull request #693: URL: https://github.com/apache/lucene/pull/693 -- 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
[jira] [Commented] (LUCENE-10400) Clean up the constructors' API signature of dictionary classes in kuromoji and nori
[ https://issues.apache.org/jira/browse/LUCENE-10400?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17495094#comment-17495094 ] ASF subversion and git services commented on LUCENE-10400: -- Commit 58fa95deeac6ae00f1a3d4456e9c6ff2164312a6 in lucene's branch refs/heads/main from Tomoko Uchida [ https://gitbox.apache.org/repos/asf?p=lucene.git;h=58fa95d ] LUCENE-10400: revise binary dictionaries' constructor in nori (#693) > Clean up the constructors' API signature of dictionary classes in kuromoji > and nori > --- > > Key: LUCENE-10400 > URL: https://issues.apache.org/jira/browse/LUCENE-10400 > Project: Lucene - Core > Issue Type: Improvement > Components: modules/analysis >Reporter: Tomoko Uchida >Priority: Major > Time Spent: 11h > Remaining Estimate: 0h > > It was suggested in a few issues/pr comments. > * do not delegate to load class resources to other classes > * do not allow to switch the location (classpath/file path) of the resource > by constructor parameter > Before working on LUCENE-8816 or LUCENE-10393, we'd need to sort the > protected constructor APIs. -- This message was sent by Atlassian Jira (v8.20.1#820001) - To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org For additional commands, e-mail: issues-h...@lucene.apache.org
[jira] [Commented] (LUCENE-10400) Clean up the constructors' API signature of dictionary classes in kuromoji and nori
[ https://issues.apache.org/jira/browse/LUCENE-10400?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17495095#comment-17495095 ] ASF subversion and git services commented on LUCENE-10400: -- Commit e3a7d279b0211d5ed5beddb20e9511dc1c562eab in lucene's branch refs/heads/branch_9x from Tomoko Uchida [ https://gitbox.apache.org/repos/asf?p=lucene.git;h=e3a7d27 ] LUCENE-10400: revise binary dictionaries' constructor in nori (#693) > Clean up the constructors' API signature of dictionary classes in kuromoji > and nori > --- > > Key: LUCENE-10400 > URL: https://issues.apache.org/jira/browse/LUCENE-10400 > Project: Lucene - Core > Issue Type: Improvement > Components: modules/analysis >Reporter: Tomoko Uchida >Priority: Major > Time Spent: 11h 10m > Remaining Estimate: 0h > > It was suggested in a few issues/pr comments. > * do not delegate to load class resources to other classes > * do not allow to switch the location (classpath/file path) of the resource > by constructor parameter > Before working on LUCENE-8816 or LUCENE-10393, we'd need to sort the > protected constructor APIs. -- This message was sent by Atlassian Jira (v8.20.1#820001) - To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org For additional commands, e-mail: issues-h...@lucene.apache.org
[GitHub] [lucene] mocobeta opened a new pull request #695: LUCENE-10400: Remove deprecated constructors in Nori
mocobeta opened a new pull request #695: URL: https://github.com/apache/lucene/pull/695 This removes the deprecated APIs in #693. -- 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
