[jira] [Commented] (LUCENE-9623) Add module descriptor (module-info.java) to lucene jars
[ https://issues.apache.org/jira/browse/LUCENE-9623?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17244530#comment-17244530 ] Dawid Weiss commented on LUCENE-9623: - I don't think packages change that often and in my opinion it's actually better if it's a conscious decision what is exported and what is kept private. > Add module descriptor (module-info.java) to lucene jars > --- > > Key: LUCENE-9623 > URL: https://issues.apache.org/jira/browse/LUCENE-9623 > Project: Lucene - Core > Issue Type: Improvement > Components: general/build >Affects Versions: master (9.0) >Reporter: Tomoko Uchida >Priority: Major > Attachments: generate-all-module-info.sh > > > For a starter, module descriptors can be automatically generated by jdeps > utility. > There are two choices. > 1. generate "open" modules which allows reflective accesses with > --generate-open-module option > 2. generate non-open modules with --generate-module-info option > Which is the better - not fully sure, but maybe 2 (non-open modules)? > Also, we need to choose proper module names - just using gradle project path > for it is OK? -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org For additional commands, e-mail: issues-h...@lucene.apache.org
[GitHub] [lucene-solr] mkhludnev commented on pull request #962: LUCENE-9021 QueryParser: re-use the LookaheadSuccess exception
mkhludnev commented on pull request #962: URL: https://github.com/apache/lucene-solr/pull/962#issuecomment-739334232 Hi, @pbruski! Thanks for the contribution. would you mind to resolve the conflict? 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. 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-solr] pbruski commented on pull request #962: LUCENE-9021 QueryParser: re-use the LookaheadSuccess exception
pbruski commented on pull request #962: URL: https://github.com/apache/lucene-solr/pull/962#issuecomment-739336783 > Hi, @pbruski! Thanks for the contribution. would you mind to resolve the conflict? Not at all. Let's hope it's still green ;-) 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. 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-9632) Replace our TimSort with JDK TimSort
[ https://issues.apache.org/jira/browse/LUCENE-9632?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17244587#comment-17244587 ] Adrien Grand commented on LUCENE-9632: -- +1 to drop the ArrayUtil/CollectionUtil tim sorts, but like Uwe said we still need TimSorter. bq. In addition: Arrays/Collections.sort() makes clones of the objects instead of sorting in place. I know it used to be true for Collections.sort() but I don't think this is the case anymore, at least not with ArrayList. > Replace our TimSort with JDK TimSort > > > Key: LUCENE-9632 > URL: https://issues.apache.org/jira/browse/LUCENE-9632 > Project: Lucene - Core > Issue Type: Improvement >Affects Versions: master (9.0) >Reporter: Mike Drob >Priority: Major > > JDK 11 has a TimSort with very similar lineage to our TimSort (written by > Josh Bloch, based on Tim Peter's python list sort), we should consider > replacing our fork with a version that we don't have to maintain. -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org For additional commands, e-mail: issues-h...@lucene.apache.org
[jira] [Commented] (SOLR-10732) potential optimizations in callers of SolrIndexSearcher.numDocs when docset is empty
[
https://issues.apache.org/jira/browse/SOLR-10732?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17244595#comment-17244595
]
David Smiley commented on SOLR-10732:
-
+1 to what you're doing, but at least one maybe two of the spots in this patch
are redundant / don't save anything because the line you modified was _not_
creating a Query. I think in {{getListedTermCounts}} where the stream was.
BTW PRs are kinder on the reviewers than old patch files.
> potential optimizations in callers of SolrIndexSearcher.numDocs when docset
> is empty
>
>
> Key: SOLR-10732
> URL: https://issues.apache.org/jira/browse/SOLR-10732
> Project: Solr
> Issue Type: Improvement
>Reporter: Chris M. Hostetter
>Priority: Major
> Attachments: SOLR-10732.patch
>
>
> spin off of SOLR-10727...
> {quote}
> ...why not (also) optimize it slightly higher up and completely avoid the
> construction of the Query objects? (and in some cases: additional overhead)
> for example: the first usage of {{SolrIndexSearcher.numDocs(Query,DocSet)}} i
> found was {{RangeFacetProcessor.rangeCount(DocSet subset,...)}} ... if the
> first line of that method was {{if (0 == subset.size()) return 0}} then we'd
> not only optimize away the SolrIndexSearcher hit, but also fetching the
> SchemaField & building the range query (not to mention the much more
> expensive {{getGroupedFacetQueryCount}} in the grouping case)
> At a glance, most other callers of
> {{SolrIndexSearcher.numDocs(Query,DocSet)}} could be trivially optimize this
> way as well -- at a minimum to eliminate Query parsing/construction.
> {quote}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org
For additional commands, e-mail: issues-h...@lucene.apache.org
[jira] [Commented] (LUCENE-9632) Replace our TimSort with JDK TimSort
[ https://issues.apache.org/jira/browse/LUCENE-9632?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17244598#comment-17244598 ] Uwe Schindler commented on LUCENE-9632: --- Actually the ArrayUtils and CollectionUtils timSort methods are not special, they just use the Sorter interface implementation TimSorter to sort the array. So removing them is not removing any real code, just some getters/setters for array elements :-) If we remove them, we should also remove all other sorting methods like introSort or others!? We won't do this because every sort algorithm is used for different purposes in Lucene! So I tend to keep those utility methods, as we exactly know what sort algorithm is used and the code is tested. And we exactly know which sorting algorithm is used when applying them. *-1* to remove. > Replace our TimSort with JDK TimSort > > > Key: LUCENE-9632 > URL: https://issues.apache.org/jira/browse/LUCENE-9632 > Project: Lucene - Core > Issue Type: Improvement >Affects Versions: master (9.0) >Reporter: Mike Drob >Priority: Major > > JDK 11 has a TimSort with very similar lineage to our TimSort (written by > Josh Bloch, based on Tim Peter's python list sort), we should consider > replacing our fork with a version that we don't have to maintain. -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org For additional commands, e-mail: issues-h...@lucene.apache.org
[jira] [Comment Edited] (LUCENE-9632) Replace our TimSort with JDK TimSort
[ https://issues.apache.org/jira/browse/LUCENE-9632?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17244598#comment-17244598 ] Uwe Schindler edited comment on LUCENE-9632 at 12/5/20, 11:21 PM: -- Actually the ArrayUtils and CollectionUtils timSort methods are not special, they just use the Sorter interface implementation TimSorter to sort the array. So removing them is not removing any real code, just some getters/setters for array elements :-) If we remove them, we should also remove all other sorting methods like introSort or others!? We won't do this because every sort algorithm is used for different purposes in Lucene! So I tend to keep those utility methods, as we exactly know what sort algorithm is used and the code is tested. *-1* to remove. was (Author: thetaphi): Actually the ArrayUtils and CollectionUtils timSort methods are not special, they just use the Sorter interface implementation TimSorter to sort the array. So removing them is not removing any real code, just some getters/setters for array elements :-) If we remove them, we should also remove all other sorting methods like introSort or others!? We won't do this because every sort algorithm is used for different purposes in Lucene! So I tend to keep those utility methods, as we exactly know what sort algorithm is used and the code is tested. And we exactly know which sorting algorithm is used when applying them. *-1* to remove. > Replace our TimSort with JDK TimSort > > > Key: LUCENE-9632 > URL: https://issues.apache.org/jira/browse/LUCENE-9632 > Project: Lucene - Core > Issue Type: Improvement >Affects Versions: master (9.0) >Reporter: Mike Drob >Priority: Major > > JDK 11 has a TimSort with very similar lineage to our TimSort (written by > Josh Bloch, based on Tim Peter's python list sort), we should consider > replacing our fork with a version that we don't have to maintain. -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org For additional commands, e-mail: issues-h...@lucene.apache.org
[jira] [Commented] (LUCENE-9632) Replace our TimSort with JDK TimSort
[ https://issues.apache.org/jira/browse/LUCENE-9632?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17244599#comment-17244599 ] Uwe Schindler commented on LUCENE-9632: --- Actually the availability of this methods are good to test the TimSorter methods for correctness and compare them to JDK. > Replace our TimSort with JDK TimSort > > > Key: LUCENE-9632 > URL: https://issues.apache.org/jira/browse/LUCENE-9632 > Project: Lucene - Core > Issue Type: Improvement >Affects Versions: master (9.0) >Reporter: Mike Drob >Priority: Major > > JDK 11 has a TimSort with very similar lineage to our TimSort (written by > Josh Bloch, based on Tim Peter's python list sort), we should consider > replacing our fork with a version that we don't have to maintain. -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org For additional commands, e-mail: issues-h...@lucene.apache.org
[jira] [Comment Edited] (LUCENE-9632) Replace our TimSort with JDK TimSort
[ https://issues.apache.org/jira/browse/LUCENE-9632?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17244599#comment-17244599 ] Uwe Schindler edited comment on LUCENE-9632 at 12/5/20, 11:31 PM: -- Actually the availability of these methods are good to test the TimSorter implementation of the Sorter interface in Lucene for correctness and compare them to JDK. was (Author: thetaphi): Actually the availability of this methods are good to test the TimSorter methods for correctness and compare them to JDK. > Replace our TimSort with JDK TimSort > > > Key: LUCENE-9632 > URL: https://issues.apache.org/jira/browse/LUCENE-9632 > Project: Lucene - Core > Issue Type: Improvement >Affects Versions: master (9.0) >Reporter: Mike Drob >Priority: Major > > JDK 11 has a TimSort with very similar lineage to our TimSort (written by > Josh Bloch, based on Tim Peter's python list sort), we should consider > replacing our fork with a version that we don't have to maintain. -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org For additional commands, e-mail: issues-h...@lucene.apache.org
[jira] [Commented] (LUCENE-9623) Add module descriptor (module-info.java) to lucene jars
[
https://issues.apache.org/jira/browse/LUCENE-9623?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17244601#comment-17244601
]
Tomoko Uchida commented on LUCENE-9623:
---
{quote}it's actually better if it's a conscious decision what is exported and
what is kept private.
{quote}
I basically agree with that. Module descriptor is essentially an API that
should be carefully defined by developers.
I mean, we'd need some transition period. Making decision about what packages
are exported and what are kept private for all modules would be more than I can
handle... and if we plan to export all existing packages at the initial stage,
why don't we automate it?
> Add module descriptor (module-info.java) to lucene jars
> ---
>
> Key: LUCENE-9623
> URL: https://issues.apache.org/jira/browse/LUCENE-9623
> Project: Lucene - Core
> Issue Type: Improvement
> Components: general/build
>Affects Versions: master (9.0)
>Reporter: Tomoko Uchida
>Priority: Major
> Attachments: generate-all-module-info.sh
>
>
> For a starter, module descriptors can be automatically generated by jdeps
> utility.
> There are two choices.
> 1. generate "open" modules which allows reflective accesses with
> --generate-open-module option
> 2. generate non-open modules with --generate-module-info option
> Which is the better - not fully sure, but maybe 2 (non-open modules)?
> Also, we need to choose proper module names - just using gradle project path
> for it is OK?
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org
For additional commands, e-mail: issues-h...@lucene.apache.org
[jira] [Commented] (LUCENE-9623) Add module descriptor (module-info.java) to lucene jars
[ https://issues.apache.org/jira/browse/LUCENE-9623?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17244635#comment-17244635 ] Tomoko Uchida commented on LUCENE-9623: --- I just wanted to make things a bit clearer. To me, there are several open questions to be solved/answered. - What packages are exported and what are kept private - and how do we make the decision or get consensus about it (upon such a large codebase)? - How do we test if the modularized jars correctly work? - How do we integrate module system into our gradle build? These matters are closely interwined, I don't think we can resolve them all at once. We'd need to start from somewhere... > Add module descriptor (module-info.java) to lucene jars > --- > > Key: LUCENE-9623 > URL: https://issues.apache.org/jira/browse/LUCENE-9623 > Project: Lucene - Core > Issue Type: Improvement > Components: general/build >Affects Versions: master (9.0) >Reporter: Tomoko Uchida >Priority: Major > Attachments: generate-all-module-info.sh > > > For a starter, module descriptors can be automatically generated by jdeps > utility. > There are two choices. > 1. generate "open" modules which allows reflective accesses with > --generate-open-module option > 2. generate non-open modules with --generate-module-info option > Which is the better - not fully sure, but maybe 2 (non-open modules)? > Also, we need to choose proper module names - just using gradle project path > for it is OK? -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org For additional commands, e-mail: issues-h...@lucene.apache.org
