[jira] [Comment Edited] (FILEUPLOAD-338) FileItem.write crash on Windows Tomcat
[ https://issues.apache.org/jira/browse/FILEUPLOAD-338?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17369774#comment-17369774 ] yangshulin edited comment on FILEUPLOAD-338 at 6/26/21, 1:00 AM: - Sorry, I don't know how to unit test FileUpload. Below is the critical crash stack: java.io.IOException: Failed to delete original file 'C:\Users\XX\AppData\Local\Temp\upload_69595089_ccd2_42e5_9be0_367b7e24bdc7_0005.tmp' after copy to 'C:\Users\XX\Documents\Web\.metadata\.plugins\org.eclipse.wst.server.core\tmp2\wtpwebapps\medias\1624669113739.jpg' at org.apache.commons.io.FileUtils.moveFile(FileUtils.java:2578) at org.apache.commons.fileupload.disk.DiskFileItem.write(DiskFileItem.java:405) I think it is a bug of FileUtils.moveFile, this crash appears on FileUpload 1.4, FileUpload 1.3 works well, because it uses IOUtils to copy streams. was (Author: yang2021): Sorry, I don't know how to unit test FileUpload. Below is the critical crash stack: org.apache.commons.io.FileExistsException: Destination 'C:\Users\XX\Documents\Web\.metadata\.plugins\org.eclipse.wst.server.core\tmp2\wtpwebapps\medias\1624668135089.jpg' already exists at org.apache.commons.io.FileUtils.moveFile(FileUtils.java:2568) at org.apache.commons.fileupload.disk.DiskFileItem.write(DiskFileItem.java:405) I think it is a bug of FileUtils.moveFile, this crash appears on FileUpload 1.4, FileUpload 1.3 works well, because it uses IOUtils to copy streams. > FileItem.write crash on Windows Tomcat > -- > > Key: FILEUPLOAD-338 > URL: https://issues.apache.org/jira/browse/FILEUPLOAD-338 > Project: Commons FileUpload > Issue Type: Bug >Affects Versions: 1.4 >Reporter: yangshulin >Priority: Critical > > When I use FileItem.write on FileUpload 1.4, it will crash on Windows Tomcat, > linux server has not been tested. I find it is crashed by FileUtils.moveFile, > which reports IO Exception. FileUpload 1.3 works well, because it use file > streams copying. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Comment Edited] (FILEUPLOAD-338) FileItem.write crash on Windows Tomcat
[ https://issues.apache.org/jira/browse/FILEUPLOAD-338?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17369774#comment-17369774 ] yangshulin edited comment on FILEUPLOAD-338 at 6/26/21, 1:01 AM: - Sorry, I don't know how to unit test FileUpload. Below is the critical crash stack: java.io.IOException: Failed to delete original file 'C:\Users\XX\AppData\Local\Temp\upload_69595089_ccd2_42e5_9be0_367b7e24bdc7_0005.tmp' after copy to 'C:\Users\XX\Documents\Web\.metadata\.plugins\org.eclipse.wst.server.core\tmp2\wtpwebapps\medias\1624669113739.jpg' at org.apache.commons.io.FileUtils.moveFile(FileUtils.java:2578) at org.apache.commons.fileupload.disk.DiskFileItem.write(DiskFileItem.java:405) I think it is a bug of FileUtils.moveFile, this crash appears on FileUpload 1.4, FileUpload 1.3 works well, because it uses IOUtils to copy streams. was (Author: yang2021): Sorry, I don't know how to unit test FileUpload. Below is the critical crash stack: java.io.IOException: Failed to delete original file 'C:\Users\XX\AppData\Local\Temp\upload_69595089_ccd2_42e5_9be0_367b7e24bdc7_0005.tmp' after copy to 'C:\Users\XX\Documents\Web\.metadata\.plugins\org.eclipse.wst.server.core\tmp2\wtpwebapps\medias\1624669113739.jpg' at org.apache.commons.io.FileUtils.moveFile(FileUtils.java:2578) at org.apache.commons.fileupload.disk.DiskFileItem.write(DiskFileItem.java:405) I think it is a bug of FileUtils.moveFile, this crash appears on FileUpload 1.4, FileUpload 1.3 works well, because it uses IOUtils to copy streams. > FileItem.write crash on Windows Tomcat > -- > > Key: FILEUPLOAD-338 > URL: https://issues.apache.org/jira/browse/FILEUPLOAD-338 > Project: Commons FileUpload > Issue Type: Bug >Affects Versions: 1.4 >Reporter: yangshulin >Priority: Critical > > When I use FileItem.write on FileUpload 1.4, it will crash on Windows Tomcat, > linux server has not been tested. I find it is crashed by FileUtils.moveFile, > which reports IO Exception. FileUpload 1.3 works well, because it use file > streams copying. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Comment Edited] (FILEUPLOAD-338) FileItem.write crash on Windows Tomcat
[ https://issues.apache.org/jira/browse/FILEUPLOAD-338?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17369774#comment-17369774 ] yangshulin edited comment on FILEUPLOAD-338 at 6/26/21, 12:55 AM: -- Sorry, I don't know how to unit test FileUpload. Below is the critical crash stack: org.apache.commons.io.FileExistsException: Destination 'C:\Users\XX\Documents\Web\.metadata\.plugins\org.eclipse.wst.server.core\tmp2\wtpwebapps\medias\1624668135089.jpg' already exists at org.apache.commons.io.FileUtils.moveFile(FileUtils.java:2568) at org.apache.commons.fileupload.disk.DiskFileItem.write(DiskFileItem.java:405) I think it is a bug of FileUtils.moveFile, this crash appears on FileUpload 1.4, FileUpload 1.3 works well, because it uses IOUtils to copy streams. was (Author: yang2021): I don't think this library can be unit test. Below is the critical crash stack: org.apache.commons.io.FileExistsException: Destination 'C:\Users\XX\Documents\Web\.metadata\.plugins\org.eclipse.wst.server.core\tmp2\wtpwebapps\medias\1624668135089.jpg' already exists at org.apache.commons.io.FileUtils.moveFile(FileUtils.java:2568) at org.apache.commons.fileupload.disk.DiskFileItem.write(DiskFileItem.java:405) I think it is a bug of FileUtils > FileItem.write crash on Windows Tomcat > -- > > Key: FILEUPLOAD-338 > URL: https://issues.apache.org/jira/browse/FILEUPLOAD-338 > Project: Commons FileUpload > Issue Type: Bug >Affects Versions: 1.4 >Reporter: yangshulin >Priority: Critical > > When I use FileItem.write on FileUpload 1.4, it will crash on Windows Tomcat, > linux server has not been tested. I find it is crashed by FileUtils.moveFile, > which reports IO Exception. FileUpload 1.3 works well, because it use file > streams copying. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Comment Edited] (FILEUPLOAD-338) FileItem.write crash on Windows Tomcat
[ https://issues.apache.org/jira/browse/FILEUPLOAD-338?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17369774#comment-17369774 ] yangshulin edited comment on FILEUPLOAD-338 at 6/26/21, 12:51 AM: -- I don't think this library can be unit test. Below is the critical crash stack: org.apache.commons.io.FileExistsException: Destination 'C:\Users\XX\Documents\Web\.metadata\.plugins\org.eclipse.wst.server.core\tmp2\wtpwebapps\medias\1624668135089.jpg' already exists at org.apache.commons.io.FileUtils.moveFile(FileUtils.java:2568) at org.apache.commons.fileupload.disk.DiskFileItem.write(DiskFileItem.java:405) I think it is a bug of FileUtils was (Author: yang2021): I don't think this library can be unit test. Below is the critical crash stack: org.apache.commons.io.FileExistsException: Destination 'C:\Users\XX\Documents\Web\.metadata\.plugins\org.eclipse.wst.server.core\tmp2\wtpwebapps\medias\1624668135089.jpg' already exists at org.apache.commons.io.FileUtils.moveFile(FileUtils.java:2568) at org.apache.commons.fileupload.disk.DiskFileItem.write(DiskFileItem.java:405) > FileItem.write crash on Windows Tomcat > -- > > Key: FILEUPLOAD-338 > URL: https://issues.apache.org/jira/browse/FILEUPLOAD-338 > Project: Commons FileUpload > Issue Type: Bug >Affects Versions: 1.4 >Reporter: yangshulin >Priority: Critical > > When I use FileItem.write on FileUpload 1.4, it will crash on Windows Tomcat, > linux server has not been tested. I find it is crashed by FileUtils.moveFile, > which reports IO Exception. FileUpload 1.3 works well, because it use file > streams copying. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (FILEUPLOAD-338) FileItem.write crash on Windows Tomcat
[ https://issues.apache.org/jira/browse/FILEUPLOAD-338?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17369774#comment-17369774 ] yangshulin commented on FILEUPLOAD-338: --- I don't think this library can be unit test. Below is the critical crash stack: org.apache.commons.io.FileExistsException: Destination 'C:\Users\XX\Documents\Web\.metadata\.plugins\org.eclipse.wst.server.core\tmp2\wtpwebapps\medias\1624668135089.jpg' already exists at org.apache.commons.io.FileUtils.moveFile(FileUtils.java:2568) at org.apache.commons.fileupload.disk.DiskFileItem.write(DiskFileItem.java:405) > FileItem.write crash on Windows Tomcat > -- > > Key: FILEUPLOAD-338 > URL: https://issues.apache.org/jira/browse/FILEUPLOAD-338 > Project: Commons FileUpload > Issue Type: Bug >Affects Versions: 1.4 >Reporter: yangshulin >Priority: Critical > > When I use FileItem.write on FileUpload 1.4, it will crash on Windows Tomcat, > linux server has not been tested. I find it is crashed by FileUtils.moveFile, > which reports IO Exception. FileUpload 1.3 works well, because it use file > streams copying. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Comment Edited] (FILEUPLOAD-338) FileItem.write crash on Windows Tomcat
[ https://issues.apache.org/jira/browse/FILEUPLOAD-338?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17369774#comment-17369774 ] yangshulin edited comment on FILEUPLOAD-338 at 6/26/21, 12:50 AM: -- I don't think this library can be unit test. Below is the critical crash stack: org.apache.commons.io.FileExistsException: Destination 'C:\Users\XX\Documents\Web\.metadata\.plugins\org.eclipse.wst.server.core\tmp2\wtpwebapps\medias\1624668135089.jpg' already exists at org.apache.commons.io.FileUtils.moveFile(FileUtils.java:2568) at org.apache.commons.fileupload.disk.DiskFileItem.write(DiskFileItem.java:405) was (Author: yang2021): I don't think this library can be unit test. Below is the critical crash stack: org.apache.commons.io.FileExistsException: Destination 'C:\Users\XX\Documents\Web\.metadata\.plugins\org.eclipse.wst.server.core\tmp2\wtpwebapps\medias\1624668135089.jpg' already exists at org.apache.commons.io.FileUtils.moveFile(FileUtils.java:2568) at org.apache.commons.fileupload.disk.DiskFileItem.write(DiskFileItem.java:405) > FileItem.write crash on Windows Tomcat > -- > > Key: FILEUPLOAD-338 > URL: https://issues.apache.org/jira/browse/FILEUPLOAD-338 > Project: Commons FileUpload > Issue Type: Bug >Affects Versions: 1.4 >Reporter: yangshulin >Priority: Critical > > When I use FileItem.write on FileUpload 1.4, it will crash on Windows Tomcat, > linux server has not been tested. I find it is crashed by FileUtils.moveFile, > which reports IO Exception. FileUpload 1.3 works well, because it use file > streams copying. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (MATH-1390) LUDecomposition slow on larger matrices
[ https://issues.apache.org/jira/browse/MATH-1390?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gilles Sadowski updated MATH-1390: -- Fix Version/s: (was: 4.0) 4.X > LUDecomposition slow on larger matrices > --- > > Key: MATH-1390 > URL: https://issues.apache.org/jira/browse/MATH-1390 > Project: Commons Math > Issue Type: Improvement >Affects Versions: 4.0, 3.7 >Reporter: Wilhelm Burger >Priority: Minor > Labels: performance > Fix For: 4.X > > Original Estimate: 6h > Remaining Estimate: 6h > > Commons-math LUDecomposition runs ca. 10 times slower than the original > (referenced) JAMA implementation for a matrix of size 1600 x 1600, slowdown > is noticable above size 750 x 750, regardless of matrix type. > It is suggested to revert to the proven (and fast) JAMA implementation and > overhaul the LUDecomposition class (and related classes) in the 'linear' > package. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (MATH-1576) Reinstate "checkstyle"
[ https://issues.apache.org/jira/browse/MATH-1576?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17369581#comment-17369581 ] Alex Herbert commented on MATH-1576: Fixed a lot of checkstyle in commits: f8741d3ab644b940ce309bc2f68796ff415886d5 4ec8e6dfe6f5da30c50973eb971af59910635328 The following modules have been commented out: ParameterNumber - 50 errors MethodParamPad - 94 errors NoWhitespaceAfter - 3949 errors NoWhitespaceBefore - 1605 errors OperatorWrap - 54 errors ParenPad - 884 errors WhitespaceAfter - 7543 errors WhitespaceAround - 2198 errors HiddenField - 64 errors ArrayTypeStyle - 197 errors Indentation - 7293 errors The indentation and whitespace seems to be a big problem. I may look at this another time. For now checkstyle is at least working and any code lifted from the legacy module will have to be corrected for these last issues. > Reinstate "checkstyle" > -- > > Key: MATH-1576 > URL: https://issues.apache.org/jira/browse/MATH-1576 > Project: Commons Math > Issue Type: Sub-task >Reporter: Gilles Sadowski >Priority: Critical > Labels: checkstyle > Fix For: 4.0 > > > Modularization configuration was copied from Commons Numbers that used a > newer Checkstyle with a different syntax. The checks trigger more than 31000 > errors in Commons Math; so all checks have been disabled. :( > The syntax of the configuration that worked before modularization should be > adapted to the new syntax... -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Closed] (JEXL-352) Possible memory leak regarding parser jjtree nodes in JEXL 3.2
[
https://issues.apache.org/jira/browse/JEXL-352?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Henri Biestro closed JEXL-352.
--
> Possible memory leak regarding parser jjtree nodes in JEXL 3.2
> --
>
> Key: JEXL-352
> URL: https://issues.apache.org/jira/browse/JEXL-352
> Project: Commons JEXL
> Issue Type: Bug
>Affects Versions: 3.2
> Environment: * JEXL 3.2
> * Java 11
> * Jetty 9.4.41.v20210516
>
>Reporter: Øyvind Horneland
>Assignee: Henri Biestro
>Priority: Critical
> Fix For: 3.2.1
>
> Attachments: jexl-engine-hprof.png
>
>
> Our application encountered a memory leak issue after upgrading from JEXL 3.1
> to 3.2.
> It seems that every call to JexlEngine createExpression now adds new entries
> to engine.parser.jjtree.nodes. In our case we suddenly had millions of nodes
> in this list.
> This sample seems to reproduce the issue
> {code:java}
> JexlEngine jexlEngine = new JexlBuilder().create();
> String testExpression = "dummy";
> jexlEngine.createExpression(testExpression); //
> jexlEngine.parser.jjtree.nodes.size() == 1
> jexlEngine.createExpression(testExpression); //
> jexlEngine.parser.jjtree.nodes.size() == 2
> {code}
> We currently don't cache the returned expression and JexlEngine is configured
> with defaults as shown in the sample.
> Note that calling jexlEngine.clearCache() does not free the nodes.
> Attached screenshot for the hprof of our application with ~ 1.7 million nodes
> in jjtree.
>
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Closed] (JEXL-350) map[null] throws "unsolvable property" when a Sandbox is used
[
https://issues.apache.org/jira/browse/JEXL-350?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Henri Biestro closed JEXL-350.
--
> map[null] throws "unsolvable property" when a Sandbox is used
> -
>
> Key: JEXL-350
> URL: https://issues.apache.org/jira/browse/JEXL-350
> Project: Commons JEXL
> Issue Type: Improvement
>Affects Versions: 3.1
> Environment: jdk-11.0.5_10-hotspot
> JEXL git pull on 2021-06-03
>
>Reporter: David Costanzo
>Assignee: Henri Biestro
>Priority: Major
> Fix For: 3.2.1
>
>
> In JEXL 3.2 SNAPSHOT, you can can access a null property in a map if you have
> no sandbox, but you cannot access a null property in a map if you have an
> "allow box" sandbox. This asymmetry is weird and might be an oversight.
> The fix for JEXL-327 allows setting a null property in a map using the array
> syntax, but only for the case where there is no sandbox. The fix for
> JEXL-291 allows array-style access to values in a map when using a sandbox.
> What remains is the intersection of these two use cases: accessing a null
> property in a map using the array-access syntax when there's a sandbox.
>
> *Impact:*
> In my domain (working with data from clinical trials), a null numeric value
> means "missing", which is a valid value. Our JEXL programmers implement
> "switch" statements using a map, so you might see an expression that
> translates a coded variable named "DMSEX" into an English description like:
> {code:java}
> {
>null : "Unknown",
>1: "MALE",
>2: "FEMALE"
> }[DMSEX]{code}
> Not being able to read the "Unknown" value when DMSEX=null is a problem that
> we've had to work around by copying the internal class SandboxUberspect and
> hacking it to allow this.
>
> *Technical Details:*
> I think the problem starts in SandboxUbserspect.getPropertyGet() because
> identifier is null. In this case, the most of the logic is skipped and null
> is returned, indicating that the property is undefined.
> {code:java}
> @Override
> public JexlPropertyGet getPropertyGet(final List resolvers,
> final Object obj,
> final Object identifier) {
> if (obj != null && identifier != null) {
> final String property = identifier.toString();
> final String actual = sandbox.read(obj.getClass(), property);
> if (actual != null) {
> // no transformation, strict equality: use identifier before
> string conversion
> final Object pty = actual == property? identifier : actual;
> return uberspect.getPropertyGet(resolvers, obj, pty);
> }
> }
> return null;
> }
> {code}
> In my superficial understanding, the Sandbox.read() method doesn't have a way
> to distinguish between "null is the property you want to read" and "access is
> blocked" so in my hack, I had to always allow read access of null.
>
> *Steps to Reproduce:*
> Below are some unit tests which show the four possibilities of with/without
> sandbox and get/set null. I've included the behavior in JEXL 3.1 and a
> recent build of github as comments.
> {code:java}
> @Test
> public void testGetNullKeyWithNoSandbox() throws Exception {
> JexlEngine jexl = new JexlBuilder().create();
> JexlContext jc = new MapContext();
> JexlExpression expression = jexl.createExpression("{null : 'foo'}[null]");
> // JEXL 3.1, works
> // JEXL 3.2, works
> Object o = expression.evaluate(jc);
> Assert.assertEquals("foo", o);
> }
>
> @Test
> public void testGetNullKeyWithSandbox() throws Exception {
> JexlEngine jexl = new JexlBuilder().sandbox(new
> JexlSandbox(true)).create();
> JexlContext jc = new MapContext();
> JexlExpression expression = jexl.createExpression("{null : 'foo'}[null]");
> // JEXL 3.1, throws JexlException$Property "unsolvable property
> '.'"
> // JEXL 3.2, throws JexlException$Property "undefined property
> '.'"
> Object o = expression.evaluate(jc);
> Assert.assertEquals("foo", o);
> }
> @Test
> public void testSetNullKeyWithNoSandbox() throws Exception {
> JexlEngine jexl = new JexlBuilder().create();
> JexlContext jc = new MapContext();
> JexlExpression expression = jexl.createExpression("{null : 'foo'}[null] =
> 'bar'");
>
> // JEXL 3.1, throws JexlException$Property "unsolvable property
> '.'"
> // JEXL 3.2, works
> expression.evaluate(jc);
> }
> @Test
> public void testSetNullKeyWithSandbox() throws Exception {
> JexlEngine jexl = new JexlBuilder().sandbox(new
> JexlSandbox(true)).create();
> JexlContext jc = new MapContext();
> JexlExpression expression = jexl.createExpression("{null : 'foo'}[null] =
> 'bar'");
> // JEXL 3.1, throws
[jira] [Closed] (JEXL-351) JXLT Template fails when using sandboxing
[ https://issues.apache.org/jira/browse/JEXL-351?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Henri Biestro closed JEXL-351. -- > JXLT Template fails when using sandboxing > - > > Key: JEXL-351 > URL: https://issues.apache.org/jira/browse/JEXL-351 > Project: Commons JEXL > Issue Type: Bug >Affects Versions: 3.2 >Reporter: Henri Biestro >Assignee: Henri Biestro >Priority: Critical > Fix For: 3.2.1 > > > Regression, total loss of functionality. > In 3.2: > When the JEXL engine is built with a custom sandboxing Uberspect that > strictly narrows the classes and methods allowed, the TemplateInterpreter > methods may end up being in the blocked list. Since the interpreter relies on > finding the methods to operate, the whole template silently fails with an > empty content. > The fix is to mimic 3.1, the AST nodes for the jexl:print and jexl:includes > calls being interpreted directly. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (JEXL-235) Verify JexlScriptEngineFactory.{getLanguageVersion,getEngineVersion} before release
[
https://issues.apache.org/jira/browse/JEXL-235?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Henri Biestro updated JEXL-235:
---
Fix Version/s: (was: 3.2.1)
Later
> Verify JexlScriptEngineFactory.{getLanguageVersion,getEngineVersion} before
> release
> ---
>
> Key: JEXL-235
> URL: https://issues.apache.org/jira/browse/JEXL-235
> Project: Commons JEXL
> Issue Type: Task
>Affects Versions: 3.2
>Reporter: Henri Biestro
>Priority: Major
> Fix For: Later
>
>
> JexlScriptEngineFactory.getLanguageVersion and
> JexlScriptEngineFactory.getEngine version should reflect the syntax version
> and the engine version respectively.
> As a rule, any new operator or syntax should bump the language version, any
> release should update the engine version that should match the jar version.
> (see JEXL-227 for discussion on the issue).
> This task must be checked for each version.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Resolved] (MATH-1612) Regression in "SimpsonIntegrator"?
[
https://issues.apache.org/jira/browse/MATH-1612?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Gilles Sadowski resolved MATH-1612.
---
Resolution: Done
Doc updated in commit cd54910edcb60f4d67fe3af3e26a5f184699dd16 ("master"
branch).
See also MATH-1613.
> Regression in "SimpsonIntegrator"?
> --
>
> Key: MATH-1612
> URL: https://issues.apache.org/jira/browse/MATH-1612
> Project: Commons Math
> Issue Type: Bug
>Reporter: Gilles Sadowski
>Priority: Major
> Fix For: 4.0
>
>
> The following code:
> {code}
> final UnivariateFunction f = PolynomialsUtils.createHermitePolynomial(deg);
> final double integ = new SimpsonIntegrator(9, 50).integrate(1100, f, 0, 0.5);
> {code}
> terminates as expected, while this one
> {code}
> final UnivariateFunction f = PolynomialsUtils.createHermitePolynomial(deg);
> final double integ = new SimpsonIntegrator(10, 50).integrate(1100, f, 0, 0.5);
> {code}
> raises an exception:
> {noformat}
> TooManyEvaluationsException: illegal state: maximal count (1,100) exceeded:
> evaluations
> {noformat}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Resolved] (MATH-1613) Maximal number of iterations too large in "SimpsonIntegrator"
[
https://issues.apache.org/jira/browse/MATH-1613?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Gilles Sadowski resolved MATH-1613.
---
Resolution: Fixed
Commit c98e638d7313fec1cc5808cfaa18b2bceaa9864c ("master" branch).
> Maximal number of iterations too large in "SimpsonIntegrator"
> -
>
> Key: MATH-1613
> URL: https://issues.apache.org/jira/browse/MATH-1613
> Project: Commons Math
> Issue Type: Bug
>Reporter: Gilles Sadowski
>Priority: Major
> Fix For: 4.0
>
>
> As noted by [~aherbert] in MATH-1612, the internal counter of function
> _evaluations_ does not support values larger than {{Integer.MAX_VALUE}}.
> The current default for the number of _iterations_ (63) would require the
> range of {{Long}}.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (MATH-1576) Reinstate "checkstyle"
[ https://issues.apache.org/jira/browse/MATH-1576?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17369427#comment-17369427 ] Alex Herbert commented on MATH-1576: IDK. I am looking t it now by adding back modules one at a time. So far I have fixed trailing whitepsace, the license header file and removing tab characters. These seem things that shold be fixed. When it gets into the code format then I should be able to make the rules more lenient. > Reinstate "checkstyle" > -- > > Key: MATH-1576 > URL: https://issues.apache.org/jira/browse/MATH-1576 > Project: Commons Math > Issue Type: Sub-task >Reporter: Gilles Sadowski >Priority: Critical > Labels: checkstyle > Fix For: 4.0 > > > Modularization configuration was copied from Commons Numbers that used a > newer Checkstyle with a different syntax. The checks trigger more than 31000 > errors in Commons Math; so all checks have been disabled. :( > The syntax of the configuration that worked before modularization should be > adapted to the new syntax... -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (MATH-1576) Reinstate "checkstyle"
[ https://issues.apache.org/jira/browse/MATH-1576?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17369425#comment-17369425 ] Gilles Sadowski commented on MATH-1576: --- bq. Checkstyle has been suppressed for the legacy module. Do you know whether there is a tool that translate the old (more lenient) CM's config into the new syntax? It would at least avoid some style changes in the legacy module. > Reinstate "checkstyle" > -- > > Key: MATH-1576 > URL: https://issues.apache.org/jira/browse/MATH-1576 > Project: Commons Math > Issue Type: Sub-task >Reporter: Gilles Sadowski >Priority: Critical > Labels: checkstyle > Fix For: 4.0 > > > Modularization configuration was copied from Commons Numbers that used a > newer Checkstyle with a different syntax. The checks trigger more than 31000 > errors in Commons Math; so all checks have been disabled. :( > The syntax of the configuration that worked before modularization should be > adapted to the new syntax... -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (MATH-1612) Regression in "SimpsonIntegrator"?
[
https://issues.apache.org/jira/browse/MATH-1612?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17369418#comment-17369418
]
Gilles Sadowski commented on MATH-1612:
---
bq. maximumIterationCount of 31 and not 63.
Shouldn't it rather be 30, or perhaps even 29 (since a few evaluations are
performed before the counter is incremented)?
> Regression in "SimpsonIntegrator"?
> --
>
> Key: MATH-1612
> URL: https://issues.apache.org/jira/browse/MATH-1612
> Project: Commons Math
> Issue Type: Bug
>Reporter: Gilles Sadowski
>Priority: Major
> Fix For: 4.0
>
>
> The following code:
> {code}
> final UnivariateFunction f = PolynomialsUtils.createHermitePolynomial(deg);
> final double integ = new SimpsonIntegrator(9, 50).integrate(1100, f, 0, 0.5);
> {code}
> terminates as expected, while this one
> {code}
> final UnivariateFunction f = PolynomialsUtils.createHermitePolynomial(deg);
> final double integ = new SimpsonIntegrator(10, 50).integrate(1100, f, 0, 0.5);
> {code}
> raises an exception:
> {noformat}
> TooManyEvaluationsException: illegal state: maximal count (1,100) exceeded:
> evaluations
> {noformat}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (MATH-1576) Reinstate "checkstyle"
[ https://issues.apache.org/jira/browse/MATH-1576?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17369410#comment-17369410 ] Alex Herbert commented on MATH-1576: Reinstated checkstyle in commit: 6ce950d5a36cbf61323cd83b9b68654637803639 Checkstyle has been suppressed for the legacy module. Fixed the new modules to pass the checkstyle configuration ported from Commons-Numbers. > Reinstate "checkstyle" > -- > > Key: MATH-1576 > URL: https://issues.apache.org/jira/browse/MATH-1576 > Project: Commons Math > Issue Type: Sub-task >Reporter: Gilles Sadowski >Priority: Critical > Labels: checkstyle > Fix For: 4.0 > > > Modularization configuration was copied from Commons Numbers that used a > newer Checkstyle with a different syntax. The checks trigger more than 31000 > errors in Commons Math; so all checks have been disabled. :( > The syntax of the configuration that worked before modularization should be > adapted to the new syntax... -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (CSV-275) Make CSVRecord.toList() public
[ https://issues.apache.org/jira/browse/CSV-275?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17369381#comment-17369381 ] Michael Wyraz commented on CSV-275: --- Thank you! Is there a release planned in near future? > Make CSVRecord.toList() public > -- > > Key: CSV-275 > URL: https://issues.apache.org/jira/browse/CSV-275 > Project: Commons CSV > Issue Type: Improvement > Components: Parser >Affects Versions: 1.8 >Reporter: Michael Wyraz >Priority: Trivial > Fix For: 1.9.0 > > > There was already an issue (CSV-266) requesting this. It was closed because > the use case could be solved otherwise. > I have a different use case that needs a list of items in a record. There are > only inefficient ways to get this list (e.g. convert the iterator back to a > list). The toList() method should really be public since it's the most > efficient way to get a list if entries. And there's even a comment on it > saying "TODO: Maybe make this public?" > -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Closed] (CSV-275) Make CSVRecord.toList() public
[ https://issues.apache.org/jira/browse/CSV-275?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Wyraz closed CSV-275. - > Make CSVRecord.toList() public > -- > > Key: CSV-275 > URL: https://issues.apache.org/jira/browse/CSV-275 > Project: Commons CSV > Issue Type: Improvement > Components: Parser >Affects Versions: 1.8 >Reporter: Michael Wyraz >Priority: Trivial > Fix For: 1.9.0 > > > There was already an issue (CSV-266) requesting this. It was closed because > the use case could be solved otherwise. > I have a different use case that needs a list of items in a record. There are > only inefficient ways to get this list (e.g. convert the iterator back to a > list). The toList() method should really be public since it's the most > efficient way to get a list if entries. And there's even a comment on it > saying "TODO: Maybe make this public?" > -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (MATH-1612) Regression in "SimpsonIntegrator"?
[
https://issues.apache.org/jira/browse/MATH-1612?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17369379#comment-17369379
]
Gilles Sadowski commented on MATH-1612:
---
bq. sanity check?
For now, I'll add a warning in the documentation.
> Regression in "SimpsonIntegrator"?
> --
>
> Key: MATH-1612
> URL: https://issues.apache.org/jira/browse/MATH-1612
> Project: Commons Math
> Issue Type: Bug
>Reporter: Gilles Sadowski
>Priority: Major
> Fix For: 4.0
>
>
> The following code:
> {code}
> final UnivariateFunction f = PolynomialsUtils.createHermitePolynomial(deg);
> final double integ = new SimpsonIntegrator(9, 50).integrate(1100, f, 0, 0.5);
> {code}
> terminates as expected, while this one
> {code}
> final UnivariateFunction f = PolynomialsUtils.createHermitePolynomial(deg);
> final double integ = new SimpsonIntegrator(10, 50).integrate(1100, f, 0, 0.5);
> {code}
> raises an exception:
> {noformat}
> TooManyEvaluationsException: illegal state: maximal count (1,100) exceeded:
> evaluations
> {noformat}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Created] (MATH-1613) Maximal number of iterations too large in "SimpsonIntegrator"
Gilles Sadowski created MATH-1613:
-
Summary: Maximal number of iterations too large in
"SimpsonIntegrator"
Key: MATH-1613
URL: https://issues.apache.org/jira/browse/MATH-1613
Project: Commons Math
Issue Type: Bug
Reporter: Gilles Sadowski
Fix For: 4.0
As noted by [~aherbert] in MATH-1612, the internal counter of function
_evaluations_ does not support values larger than {{Integer.MAX_VALUE}}.
The current default for the number of _iterations_ (63) would require the range
of {{Long}}.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
