[jira] [Commented] (MATH-650) FastMath has static code which slows the first access to FastMath
[ https://issues.apache.org/jira/browse/MATH-650?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13105918#comment-13105918 ] Luc Maisonobe commented on MATH-650: Thanks Gilles, I'll try to use that on the tablet, probably in the next few days. > FastMath has static code which slows the first access to FastMath > - > > Key: MATH-650 > URL: https://issues.apache.org/jira/browse/MATH-650 > Project: Commons Math > Issue Type: Improvement >Affects Versions: Nightly Builds > Environment: Android 2.3 (Dalvik VM with JIT) >Reporter: Alexis Robert >Priority: Minor > Attachments: FastMathLoadCheck.java, LucTestPerformance.java > > > Working on an Android application using Orekit, I've discovered that a simple > FastMath.floor() takes about 4 to 5 secs on a 1GHz Nexus One phone (only the > first time it's called). I've launched the Android profiling tool (traceview) > and the problem seems to be linked with the static portion of FastMath code > named "// Initialize tables" > The timing resulted in : > - FastMath.slowexp (40.8%) > - FastMath.expint (39.2%) > \- FastMath.quadmult() (95.6% of expint) > - FastMath.slowlog (18.2%) > Hoping that would help > Thanks! > Alexis Robert -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (SANDBOX-341) [functor] New components: summarize and aggregate
[ https://issues.apache.org/jira/browse/SANDBOX-341?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13105946#comment-13105946 ] Simone Tripodi commented on SANDBOX-341: Hi Liviu, please update your local copy of the code, I recently ported the tests to JUnit4 style. > [functor] New components: summarize and aggregate > - > > Key: SANDBOX-341 > URL: https://issues.apache.org/jira/browse/SANDBOX-341 > Project: Commons Sandbox > Issue Type: Improvement > Components: Functor > Environment: JDK 1.6.0_25 but should work with any JDK 5+ (possibly > 1.4 though I haven't tested). >Reporter: Liviu Tudor >Priority: Minor > Labels: features > Attachments: commons-functor-aggregate+summarizer.zip, > commons-functor.patch.bz2 > > > This is the next step from https://issues.apache.org/jira/browse/SANDBOX-340 > -- as instructed I'm finally hoping to get the code in the right place and > hopefully this is something that the functor component could do with. > Whereas initially I just started with the summarizer component, I have added > now the second one, the "aggregator" as they are somehow related. If this > code proves to be useful to functor in any way, it would actually be good to > get some feedback on these 2 to see if the class hierarchy can in fact be > changed to share some common functionality as I feel (probably due to the > similar needs that lead to writing/using these components) that somehow they > should share a common base. > In brief, the 2 components: > * aggregator: this just allows for data to be aggregated in a user defined > way (e.g. stored in a list for the purpose of averaging, computing the > arithmetic median etc). The classes provided actually offer the > implementation for storing data in a list and computing the above-mentioned > values or summing up everything. > * timed summarizer: this is another variation of the aggreator, however, it > adds the idea of regular "flushes", so based on a timer it will reset the > value and start summing/aggregating the data again. Rather than using an > aggregator which would store the whole data series (possibly for applying > more complex formulas), this component just computes on the fly on each > request the formula and stores the result of it. (Which does mean things like > computing arithmetic mean, median etc would be difficult to compute without > knowing upfront how many calls will be received -- i.e. how many elements we > will be required to summarize/aggregate.) So the memory footprint of running > this is much smaller -- even though, as I said, it achieves similar results. > I have only provided a summarizer which operates on integers, but obviously > others for float, double etc can be created if we go ahead with this design. > Hopefully the above make sense; this code has resulted from finding myself > writing similar components to these a few times and because it's always been > either one type (e.g. aggregator) or another (summarizer) I haven't given > quite possibly enough thought to the class design to join these 2. Also, > unfortunately, the time I sat down to make these components a bit more > general and submitted issue 340 was nearly 3 months ago so I'm trying to > remember myself all the ideas I had at a time so bear with me please if these > are still a bit fuzzy :) However, if you can make use of these I'm quite > happy to elaborate on areas that are unclear and obviously put some effort > into getting these components to the standards required to put these into a > release. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Created] (COMPRESS-157) Wrong EOF detection in CBZip2InputStream
Wrong EOF detection in CBZip2InputStream
Key: COMPRESS-157
URL: https://issues.apache.org/jira/browse/COMPRESS-157
Project: Commons Compress
Issue Type: Bug
Reporter: Jan
Priority: Minor
The following snippet form CBZip2InputStream does a wrong EOF check. The char
'thech' will never be equal to the integer '-1'. You have to check for #read()
returning -1 before casting to char.
I found the bug in
http://svn.wikimedia.org/svnroot/mediawiki/trunk/mwdumper/src/org/apache/commons/compress/bzip2/
not in your TRUNK.
{noformat}
int zzi;
char thech = 0;
try
{
thech = (char)m_input.read();
}
catch( IOException e )
{
compressedStreamEOF();
}
if( thech == -1 ) //HERE
{
compressedStreamEOF();
}
{noformat}
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (COMPRESS-157) Wrong EOF detection in CBZip2InputStream
[
https://issues.apache.org/jira/browse/COMPRESS-157?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13106082#comment-13106082
]
Sebb commented on COMPRESS-157:
---
Are you sure the class is in Compress? I can only find
BZip2CompressorInputStream which does not have the problem.
Commons VFS does have a file called CBZip2InputStream, and there is one
instance of casting read() to a char:
{code}
619 while (bsLive < 1)
620 {
621 char ch = 0;
622 try
623 {
624 ch = (char) inputStream.read();
625 }
626 catch (IOException e)
627 {
628 compressedStreamEOF();
629 }
630
631 bsBuff = (bsBuff << 8) | (ch & 0xff);
632 bsLive += 8;
633 }
{code}
That does look wrong.
> Wrong EOF detection in CBZip2InputStream
>
>
> Key: COMPRESS-157
> URL: https://issues.apache.org/jira/browse/COMPRESS-157
> Project: Commons Compress
> Issue Type: Bug
>Reporter: Jan
>Priority: Minor
>
> The following snippet form CBZip2InputStream does a wrong EOF check. The char
> 'thech' will never be equal to the integer '-1'. You have to check for
> #read() returning -1 before casting to char.
> I found the bug in
> http://svn.wikimedia.org/svnroot/mediawiki/trunk/mwdumper/src/org/apache/commons/compress/bzip2/
> not in your TRUNK.
> {noformat}
> int zzi;
> char thech = 0;
> try
> {
> thech = (char)m_input.read();
> }
> catch( IOException e )
> {
> compressedStreamEOF();
> }
> if( thech == -1 ) //HERE
> {
> compressedStreamEOF();
> }
> {noformat}
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Resolved] (COMPRESS-157) Wrong EOF detection in CBZip2InputStream
[
https://issues.apache.org/jira/browse/COMPRESS-157?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Stefan Bodewig resolved COMPRESS-157.
-
Resolution: Fixed
Fix Version/s: 1.0
The bug has been present in pre-release code of Commons Compress but it has
been fixed as part of COMPRESS-29 with svn revision 732685
> Wrong EOF detection in CBZip2InputStream
>
>
> Key: COMPRESS-157
> URL: https://issues.apache.org/jira/browse/COMPRESS-157
> Project: Commons Compress
> Issue Type: Bug
>Reporter: Jan
>Priority: Minor
> Fix For: 1.0
>
>
> The following snippet form CBZip2InputStream does a wrong EOF check. The char
> 'thech' will never be equal to the integer '-1'. You have to check for
> #read() returning -1 before casting to char.
> I found the bug in
> http://svn.wikimedia.org/svnroot/mediawiki/trunk/mwdumper/src/org/apache/commons/compress/bzip2/
> not in your TRUNK.
> {noformat}
> int zzi;
> char thech = 0;
> try
> {
> thech = (char)m_input.read();
> }
> catch( IOException e )
> {
> compressedStreamEOF();
> }
> if( thech == -1 ) //HERE
> {
> compressedStreamEOF();
> }
> {noformat}
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Created] (VFS-363) Wrong EOF detection in CBZip2InputStream
Wrong EOF detection in CBZip2InputStream Key: VFS-363 URL: https://issues.apache.org/jira/browse/VFS-363 Project: Commons VFS Issue Type: Bug Reporter: Sebb See https://issues.apache.org/jira/browse/COMPRESS-157 -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Created] (DBCP-365) StackOverflowError SharedPoolDataSource.getPooledConnectionAndInfo() Postgresql
StackOverflowError SharedPoolDataSource.getPooledConnectionAndInfo() Postgresql
---
Key: DBCP-365
URL: https://issues.apache.org/jira/browse/DBCP-365
Project: Commons Dbcp
Issue Type: Bug
Affects Versions: 1.4
Environment: Windows XP 64-bit multi-threaded
Reporter: Axl
This might be a problem with the JDBC driver for PostgreSQL 9.1 but it also
shows up here. Since this is a StackOverflowError there isn't much information
about what specifically is causing this. I'm guessing it's a Class.forName()
for one of the org.postgresql.* classes but not sure which one. The
Class.forName() goes into a loop which throws the StackOverflowError.
SharedPoolDataSource.getPooledConnectionAndInfo(String, String) line: 174
SharedPoolDataSource(InstanceKeyDataSource).getConnection(String, String) line:
701
SharedPoolDataSource(InstanceKeyDataSource).getConnection() line: 676
spds = new
org.apache.commons.dbcp.datasources.SharedPoolDataSource();
cpds = new
org.apache.commons.dbcp.cpdsadapter.DriverAdapterCPDS();
cpds.setDriver("org.postgresql.Driver");
cpds.setUrl("jdbc:postgresql://localhost:1234/mydatabasename");
cpds.setUser("myuser");
cpds.setPassword("mypass");
spds.setConnectionPoolDataSource(cpds);
spds.setMaxActive(30);
spds.setMaxWait(50);
conn = spds.getConnection();
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (OGNL-21) Remove dead and broken code from OgnlRuntime/SimpleNode
[ https://issues.apache.org/jira/browse/OGNL-21?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13107013#comment-13107013 ] Daniel Pitts commented on OGNL-21: -- Going through the diff, I've plugged OgnlRuntime.*(methodName) into google code search. While not exhaustive, it does give a sense for which methods are used. I see one of use of getPropertyDescriptorsArray, which is a broken method and either shouldn't be used, or should be fixed. I see a couple use of the deprecated method "callMethod", which is very easily replaced. I did find legitimate uses for the methods I wanted to remove from SimpleNode. So Mr. Tripodi, how do you want to handle this? I'll have to regenerate the patch since there have been commits to OgnlRuntime since I created it. Does this sound reasonable, given my research above? > Remove dead and broken code from OgnlRuntime/SimpleNode > --- > > Key: OGNL-21 > URL: https://issues.apache.org/jira/browse/OGNL-21 > Project: OGNL > Issue Type: Task >Reporter: Daniel Pitts > Labels: cleanup > Attachments: Remove-dead-code.patch > > > I noticed there are some apparently unnecessary methods in both SimpleNode > and OgnlRuntime. > I've created a patch which removes them, and the unit tests still run fine. > One of the methods was clearly buggy and would cause ClassCastExceptions if > used (it put an array into a cache which was used to also store Maps). -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
