Re: [fileupload] Have a FileUpload release (after 3.5 years)
Hello, Does anyone know what the state of 2.0 development is here? It looks like the last feature-related changes were from Sept 2021. Is there anything preventing a release? Regards, Matt J On Mon, Jul 11, 2022 at 9:51 AM Christoph Grüninger wrote: > > Dear Apaches! > > Apache FileUpload saw its last release in December 2018. Since then security > issues have been found in some dependencies and the Jakarta namespace was > introduced. More improvements are part of trunk. > > What needs to be done to get a FileUpload release out of the door? What kind > of help can we users provide? What needs to be done by Apache developers? > > It's not only me, but Apache Wicket, Jenkins, Piranha Cloud and some more: > https://issues.apache.org/jira/browse/FILEUPLOAD-309 > (and similar -343, -345). > > Kind regards, > Christoph - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [numbers][gsoc] GSoC 2022 - NUMBERS-186 Proposal
On Mon, 11 Jul 2022 at 22:56, Gilles Sadowski wrote:
> Le lun. 11 juil. 2022 à 20:03, Sumanth Rajkumar
> a écrit :
> >
> > Hi,
> >
> > I have finished updating the test classes, but I am encountering a
> problem
> > in the ComplexEdgeCaseTest class.
> >
> > private static void assertComplex(double a, double b,
> > String name, UnaryOperator
> > operation,
> > ComplexUnaryOperator
> > operation2,
> > double x, double y, long maxUlps) {
> > }
> >
> >
> > I added my ComplexUnaryOperator as a parameter and am getting the error
> of
> > having more than 7 parameters in this method.
> > Is there anything I can do?
>
> Assuming that the error is raised by "CheckStyle" (?), this check can
> be disabled
> on a class by class basis in this configuration file:
> src/main/resources/checkstyle/checkstyle-suppressions.xml
>
It may be a PMD error too [1]. The PMD error can be suppressed using the
file:
src/main/resources/pmd/pmd-ruleset.xml
However in Numbers there is a checkstyle suppression for ParameterNumber
but no suppressions for PMD for ExcessiveParameterList, so you may not need
this.
Alex
[1]
https://pmd.github.io/latest/pmd_rules_apex_design.html#excessiveparameterlist
Re: [collections] JMH results for IndexedLinkedList
On Mon, 11 Jul 2022 at 17:16, Gilles Sadowski wrote: > Le lun. 11 juil. 2022 à 09:51, Rodion Efremov a > écrit : > > > > Hi Gilles, > > > > Would it be sufficient to include .txt files for the tables and the .ods > > file provided by Matt? > > It would be more handy for readers that tables are inserted "inline" > within a comment (using the JIRA syntax) and plots are uploaded > as PNG images. See e.g. this report: > https://issues.apache.org/jira/browse/NUMBERS-156 Note that the Jira web editor will accept a table copied from Excel/OpenOffice and pasted in when in 'Visual' mode. You can then switch from 'Visual' to 'Text' mode to see the raw JIRA syntax and make changes to improve the layout. The 'Visual' mode has some editor buttons to manipulate the table. Alex
Re: [numbers][gsoc] GSoC 2022 - NUMBERS-186 Proposal
Le lun. 11 juil. 2022 à 20:03, Sumanth Rajkumar
a écrit :
>
> Hi,
>
> I have finished updating the test classes, but I am encountering a problem
> in the ComplexEdgeCaseTest class.
>
> private static void assertComplex(double a, double b,
> String name, UnaryOperator
> operation,
> ComplexUnaryOperator
> operation2,
> double x, double y, long maxUlps) {
> }
>
>
> I added my ComplexUnaryOperator as a parameter and am getting the error of
> having more than 7 parameters in this method.
> Is there anything I can do?
Assuming that the error is raised by "CheckStyle" (?), this check can
be disabled
on a class by class basis in this configuration file:
src/main/resources/checkstyle/checkstyle-suppressions.xml
Regards,
Gilles
> > [...]
-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org
Re: [numbers][gsoc] GSoC 2022 - NUMBERS-186 Proposal
Hi,
I have finished updating the test classes, but I am encountering a problem
in the ComplexEdgeCaseTest class.
private static void assertComplex(double a, double b,
String name, UnaryOperator
operation,
ComplexUnaryOperator
operation2,
double x, double y, long maxUlps) {
}
I added my ComplexUnaryOperator as a parameter and am getting the error of
having more than 7 parameters in this method.
Is there anything I can do?
Thanks,
Sumanth
On Tue, 5 Jul 2022 at 15:50, Sumanth Rajkumar
wrote:
> Thanks for the feedback Alex,
>
> > Not a problem. Just write a dedicated method for Complex and a generic
> > method in ComplexFunctions. This small level of code duplication is
> > acceptable where the efficiency of the method is greatly improved by
> > rewriting it, as has been done for the scalar functions.
>
> For proj(), I had to take it out of ComplexFunctions for now to pass the
> coverage checks,
> but I have left the original code for proj() in the Complex class.
>
> > Why should I have to return a ComplexDouble? Since the ComplexConstructor
> > is typed it makes more sense to have the methods that use it to also be
> > typed. These methods should perform an operation that generates a real
> and
> > imaginary part. This is passed to the provided constructor. It should be
> up
> > to the provider of the constructor (i.e. the caller) to decide what to do
> > with the result. By typing to ComplexDouble you are removing that
> > flexibility.
>
> > However there is no requirement to specify what R is, allowing it to be
> > Void. This also decouples the interface from Complex and ComplexDouble.
> > Note that this may make ComplexDouble obsolete which would simplify the
> > current changes.
>
> > I've not applied this change to your entire current diff so there may be
> > some issues, for example with the scalar functions. I am interested to
> see
> > if this would work.
>
> So, I have made all interfaces typed and updated the method signatures
> accordingly.
> Please let me know if there are any problems with these changes.
>
> As for updating the test suite, I am currently working on that right now
> and will let you know as soon as I am done.
>
> Thanks,
>
> Sumanth
>
>
>
Re: [collections] JMH results for IndexedLinkedList
Le lun. 11 juil. 2022 à 09:51, Rodion Efremov a écrit : > > Hi Gilles, > > Would it be sufficient to include .txt files for the tables and the .ods > file provided by Matt? It would be more handy for readers that tables are inserted "inline" within a comment (using the JIRA syntax) and plots are uploaded as PNG images. See e.g. this report: https://issues.apache.org/jira/browse/NUMBERS-156 Regards, Gilles > > Best regards, > rodde > > ma 11.7.2022 klo 10.33 Gilles Sadowski kirjoitti: > > > Hi. > > > > Le lun. 11 juil. 2022 à 07:23, Rodion Efremov a > > écrit : > > > > > > Hello Matt and community, > > > > > > I have created an ASF JIRA issue back in the days: > > > > > https://issues.apache.org/jira/projects/COLLECTIONS/issues/COLLECTIONS-797?filter=allopenissues > > > > I suggest that the benchmark tables and figures be copied over there. > > [Preferably, in separate files in formats that can be readily > > displayed in a browser.] > > > > Gilles > > > > > > > > Best regards, > > > rodde > > > > > > On Mon, Jul 11, 2022 at 6:23 AM Matt Juntunen > > > > > wrote: > > > > > > > Hello rodde, > > > > > > > > Thanks for your patience while I looked at this. I've made a PR [1] on > > > > your benchmark project with an updated benchmark class. (I used the > > > > completely uninspired class name of IndexedLinkedListPerformance2 :-) > > > > The results back up what you've been saying about the performance of > > > > this list implementation. I've attached a spreadsheet summarizing the > > > > data for a number of different operations along with some images of > > > > some of the most interesting comparisons. I've compared results for > > > > java.util.ArrayList, java.util.LinkedList, > > > > org.apache.commons.collections4.list.TreeList, and > > > > com.github.coderodde.util.IndexedLinkedList (the list in question > > > > here) using JDK 18 on list sizes of 10, 100, 1000, and 1. > > > > > > > > Below are some notes on the attached images. > > > > - get-random.png - Displays timings for element access at random > > > > indices. As expected, ArrayList is by far the best. TreeList and > > > > IndexedLinkedList are relatively close to each other but > > > > IndexedLinkedList is consistently faster. LinkedList was too terrible > > > > to even include on the graph. > > > > - iterate.png - Displays timings for list traversal using the list's > > > > iterator. This was unexpectedly bad for TreeList, which performed far > > > > worse than the others. The performance of IndexedLinkedList was on par > > > > with the JDK lists overall. > > > > - iterate-and-modify.png - Displays timings for iterating through the > > > > list while randomly adding and removing elements via the iterator. > > > > IndexedLinkedList did extraordinarily well here, with performance very > > > > close to LinkedList. Surprisingly, TreeList did worse than all of the > > > > others, including ArrayList. > > > > > > > > Overall, I think this list implementation would be a good option to > > > > include in commons-collections. Does anyone have any objections to > > > > opening a Jira ticket to pursue this? > > > > > > > > Regards, > > > > Matt J > > > > > > > > [1] https://github.com/coderodde/IndexedLinkedListBenchmark/pull/3 > > > > > > > > > [...] - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
[fileupload] Have a FileUpload release (after 3.5 years)
Dear Apaches! Apache FileUpload saw its last release in December 2018. Since then security issues have been found in some dependencies and the Jakarta namespace was introduced. More improvements are part of trunk. What needs to be done to get a FileUpload release out of the door? What kind of help can we users provide? What needs to be done by Apache developers? It's not only me, but Apache Wicket, Jenkins, Piranha Cloud and some more: https://issues.apache.org/jira/browse/FILEUPLOAD-309 (and similar -343, -345). Kind regards, Christoph
Re: [collections] JMH results for IndexedLinkedList
Hi Gilles, Would it be sufficient to include .txt files for the tables and the .ods file provided by Matt? Best regards, rodde ma 11.7.2022 klo 10.33 Gilles Sadowski kirjoitti: > Hi. > > Le lun. 11 juil. 2022 à 07:23, Rodion Efremov a > écrit : > > > > Hello Matt and community, > > > > I have created an ASF JIRA issue back in the days: > > > https://issues.apache.org/jira/projects/COLLECTIONS/issues/COLLECTIONS-797?filter=allopenissues > > I suggest that the benchmark tables and figures be copied over there. > [Preferably, in separate files in formats that can be readily > displayed in a browser.] > > Gilles > > > > > Best regards, > > rodde > > > > On Mon, Jul 11, 2022 at 6:23 AM Matt Juntunen > > > wrote: > > > > > Hello rodde, > > > > > > Thanks for your patience while I looked at this. I've made a PR [1] on > > > your benchmark project with an updated benchmark class. (I used the > > > completely uninspired class name of IndexedLinkedListPerformance2 :-) > > > The results back up what you've been saying about the performance of > > > this list implementation. I've attached a spreadsheet summarizing the > > > data for a number of different operations along with some images of > > > some of the most interesting comparisons. I've compared results for > > > java.util.ArrayList, java.util.LinkedList, > > > org.apache.commons.collections4.list.TreeList, and > > > com.github.coderodde.util.IndexedLinkedList (the list in question > > > here) using JDK 18 on list sizes of 10, 100, 1000, and 1. > > > > > > Below are some notes on the attached images. > > > - get-random.png - Displays timings for element access at random > > > indices. As expected, ArrayList is by far the best. TreeList and > > > IndexedLinkedList are relatively close to each other but > > > IndexedLinkedList is consistently faster. LinkedList was too terrible > > > to even include on the graph. > > > - iterate.png - Displays timings for list traversal using the list's > > > iterator. This was unexpectedly bad for TreeList, which performed far > > > worse than the others. The performance of IndexedLinkedList was on par > > > with the JDK lists overall. > > > - iterate-and-modify.png - Displays timings for iterating through the > > > list while randomly adding and removing elements via the iterator. > > > IndexedLinkedList did extraordinarily well here, with performance very > > > close to LinkedList. Surprisingly, TreeList did worse than all of the > > > others, including ArrayList. > > > > > > Overall, I think this list implementation would be a good option to > > > include in commons-collections. Does anyone have any objections to > > > opening a Jira ticket to pursue this? > > > > > > Regards, > > > Matt J > > > > > > [1] https://github.com/coderodde/IndexedLinkedListBenchmark/pull/3 > > > > > > > [...] > > - > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org > For additional commands, e-mail: dev-h...@commons.apache.org > >
Re: [collections] JMH results for IndexedLinkedList
Hi. Le lun. 11 juil. 2022 à 07:23, Rodion Efremov a écrit : > > Hello Matt and community, > > I have created an ASF JIRA issue back in the days: > https://issues.apache.org/jira/projects/COLLECTIONS/issues/COLLECTIONS-797?filter=allopenissues I suggest that the benchmark tables and figures be copied over there. [Preferably, in separate files in formats that can be readily displayed in a browser.] Gilles > > Best regards, > rodde > > On Mon, Jul 11, 2022 at 6:23 AM Matt Juntunen > wrote: > > > Hello rodde, > > > > Thanks for your patience while I looked at this. I've made a PR [1] on > > your benchmark project with an updated benchmark class. (I used the > > completely uninspired class name of IndexedLinkedListPerformance2 :-) > > The results back up what you've been saying about the performance of > > this list implementation. I've attached a spreadsheet summarizing the > > data for a number of different operations along with some images of > > some of the most interesting comparisons. I've compared results for > > java.util.ArrayList, java.util.LinkedList, > > org.apache.commons.collections4.list.TreeList, and > > com.github.coderodde.util.IndexedLinkedList (the list in question > > here) using JDK 18 on list sizes of 10, 100, 1000, and 1. > > > > Below are some notes on the attached images. > > - get-random.png - Displays timings for element access at random > > indices. As expected, ArrayList is by far the best. TreeList and > > IndexedLinkedList are relatively close to each other but > > IndexedLinkedList is consistently faster. LinkedList was too terrible > > to even include on the graph. > > - iterate.png - Displays timings for list traversal using the list's > > iterator. This was unexpectedly bad for TreeList, which performed far > > worse than the others. The performance of IndexedLinkedList was on par > > with the JDK lists overall. > > - iterate-and-modify.png - Displays timings for iterating through the > > list while randomly adding and removing elements via the iterator. > > IndexedLinkedList did extraordinarily well here, with performance very > > close to LinkedList. Surprisingly, TreeList did worse than all of the > > others, including ArrayList. > > > > Overall, I think this list implementation would be a good option to > > include in commons-collections. Does anyone have any objections to > > opening a Jira ticket to pursue this? > > > > Regards, > > Matt J > > > > [1] https://github.com/coderodde/IndexedLinkedListBenchmark/pull/3 > > > > > [...] - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
