On 22 October 2011 02:28, wrote:
> Author: mcucchiara
> Date: Sat Oct 22 01:28:28 2011
> New Revision: 1187627
>
> URL: http://svn.apache.org/viewvc?rev=1187627&view=rev
> Log:
> Added svn keywords property
$Date$ causes problems when comparing SVN tags with source archives.
That is because $Dat
This is the result of the performance comparison:
Apache Commons OGNL http://s.apache.org/H1u
Legacy OGNL implementation http://s.apache.org/ih
There is a huge difference. Furthermore, looks like I need to refine
declarative method cache.
Twitter :http://www.twitter.com/m_cucchiara
G+
For the record, starting from now, OGNL Runtime has a new setCacheFactory
method which allows the user to choose his preferred implementation.
Twitter :http://www.twitter.com/m_cucchiara
G+ :https://plus.google.com/107903711540963855921
Linkedin:http://www.linkedin.com/in/mauriz
Am 21.10.2011 23:19, schrieb Simone Tripodi:
Forgot to mention about checkstyle: no idea. If you built the Digester
using the provided pom, there shouldn't be ambiguity... any hint?
Being no maven guru, I haven't got a clue either. I also would expect
that the pom contains sufficient informati
>
> As I don't see the "with props" marker in the above message, I think the
> svn properties for end of line and keyword substitutions are missing.
> Could you check if it is the case ?
>
> Note that you can configure your subversion client to add these
> properties automatically when you commit a
To whom it may engage...
This is an automated request, but not an unsolicited one. For
more information please visit http://gump.apache.org/nagged.html,
and/or contact the folk at gene...@gump.apache.org.
Project commons-proxy-test has an issue affecting its community integration.
This
Le 22/10/2011 08:36, celes...@apache.org a écrit :
> Author: celestin
Hi Sébastien,
> Date: Sat Oct 22 06:36:31 2011
> New Revision: 1187657
>
> URL: http://svn.apache.org/viewvc?rev=1187657&view=rev
> Log:
> Implementation of the SYMMLQ iterative linear solver, based on Pr. Saunders
> FORTRAN
Le 22/10/2011 08:41, Sébastien Brisard a écrit :
> Hello,
Hi Sébastien,
> I'm happy to announce that the Java port of the FORTRAN SymmLQ solver
> is now ready for you all to review. I've tried to add as many
> implementation comments as possible, since the way the iterations are
> handled is not
Apropos the idea of the maven profile is very good.
+1 and thank you.
Twitter :http://www.twitter.com/m_cucchiara
G+ :https://plus.google.com/107903711540963855921
Linkedin:http://www.linkedin.com/in/mauriziocucchiara
Maurizio Cucchiara
On 22 October 2011 12:24, Maurizio Cucchi
Sure you can, before that I should merge new branch with the current trunk.
Further, FYI I have just submitted a patch for a small improvement
http://issues.carrot2.org/browse/JUNITBENCH-40
Twitter :http://www.twitter.com/m_cucchiara
G+ :https://plus.google.com/107903711540963855921
L
Hi Mau,
that for the explanation, that really helps on clarifying the graph!!!
I have an idea about merging the tests in trunk with a profile
approach that I already submitted for the Disruptor project[1] - they
have performance/benchmark tests too - if it is fine for you I can
work on it - not t
To whom it may engage...
This is an automated request, but not an unsolicited one. For
more information please visit http://gump.apache.org/nagged.html,
and/or contact the folk at gene...@gump.apache.org.
Project commons-exec-test has an issue affecting its community integration.
This i
I almost forgot there are even old vs commons comparison. Stay tuned :)
Twitter :http://www.twitter.com/m_cucchiara
G+ :https://plus.google.com/107903711540963855921
Linkedin:http://www.linkedin.com/in/mauriziocucchiara
Maurizio Cucchiara
On 22 October 2011 09:58, Maurizio Cuc
Thank you Simo,
Ok, I realized after that the graph needs at least a short explanation:
In that test I have tried to test every caches which I re-engineered.
In the graph you mentioned, there are depicted 3 different kind of
cache implementations:
1. Concurrent HashMap (CHM)
2. Thread-safe HashMap
Hi Mau,
sorry for the silly question - I'm not familiar with JUnit benchmark -
: is there any reason why performance tests have to be separated from
the rest of the project? Can we think about merging them in the core
once reached the general/lazy consensus?
TIA, have a nice WE!
Simo
http://people
15 matches
Mail list logo