[GitHub] commons-collections issue #10: Add CollectionUtils#containsQuietly method an...

[AndersDJohnson]

Github user AndersDJohnson commented on the issue:

https://github.com/apache/commons-collections/pull/10
  
@chtompki Is this still a desired feature? Don't want to the invest time 
unless there is interest.


---

-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org

Re: Fwd: Re: [JCS] missing 2.2 release in jira?

[Oliver Heger]

Am 10.09.2017 um 17:28 schrieb Thomas Vandahl:
> Hi folks,
> 
> I found out again that replying to the list did reply to the sender
> instead. Does that happen to anyone else or is it my Thunderbird setting?

Me too! This seems to be a new feature of Thunderbird which came in on a
recent update. In addition to the "Reply" button I always used to press
there is a new "Reply to list" button. Obviously, one must use the
latter one. However, I keep using "Reply" and then wonder why my mail
does not show up on the list.

Oliver

> 
> Bye, Thomas
> 
>  Forwarded Message 
> Subject: Re: [JCS] missing 2.2 release in jira?
> Date: Sat, 9 Sep 2017 10:58:54 +0200
> From: Thomas Vandahl 
> To: Romain Manni-Bucau 
> 
> On 08.09.17 16:41, Romain Manni-Bucau wrote:
>> So it would be a 3.0. Do we expect anything else in a potential 3.0?
> 
> I made an attempt to integrate the ConcurrentLinkedHashMap by Ben Manes.
> See
> https://svn.apache.org/repos/asf/commons/proper/jcs/branches/jcs-core-with-clhm
> This would be a candidate feature for 3.0.
> However, several (apparently unrelated) tests started to fail. Moreover,
> the performance tests showed little or no improvement. If you want to
> give it another shot, feel free.
> 
> Bye, Thomas
> 
> -
> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
> For additional commands, e-mail: dev-h...@commons.apache.org
> 

-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org

Re: [All][Math] New component: "Commons Geometry"?

[Matt Benson]

I'm another Commons developer who:
 * Hasn't been "present" lately
 * Has no special mathematical background
 * Desires consensus
 * Repeatedly reads these exchanges in a state of vacillation between
sympathy for Gilles's situation and suspicion that his communication style
is too abrasive. Ultimately, I get that you're frustrated.

I too have felt all along that Maven modules would be an acceptable
approach wrt CM, but my view (in which I am seemingly not alone) of that
set of code as "alike" simply because it relates to mathematics is, as I
imply above, very likely rooted in ignorance. At the same time, the field
of software development is only hoped to become more accessible by those
with decreasing amounts of formal education, so perhaps it is fair that the
line be drawn in the interest of the mathematical outsider.

Even I have a reasonable understanding of basic geometry and can appreciate
that there may be more situations in which its use would be "common." On
the other hand, it still clearly feels like I would expect to find that
among "math" code. As Ray has pointed out, there is no *technical* reason a
Maven project's submodules must have synchronized release schedule or
version numbers. It would seem to me that his approach, perhaps accounting
for the notion of the "legacy" submodule, while undeniably increasing
complexity of management to some extent, still seems the most likely way
forward to give all parties *enough* satisfaction. We are developers: we
should be able to create tooling, e.g. in Jenkins or elsewhere, that could
help manage the coordination of version numbers between parent and children.

In any case, Gilles's statement that geometry represents the outer edge of
his vision for CM expansion means that this discussion needed to take place
soon anyway; the only remaining decisions should IMO be 1) whether geometry
belongs with CM5, and 2) whether numbers should be reabsorbed into such a
CM5 structure.

Matt

On Sep 10, 2017 11:35, "Raymond DeCampo"  wrote:

I know I haven't been around lately, but I this exchange caught my eye.

I was trying to figure out a way to balance the issues, first, that there
is resistance to creating a large number of projects spun out from CM and
second, that there is a practical limit to how large a project can be
maintained with the current resources.

What I came up with is as follows:  suppose we take CM and split it up into
a number of modules.  Then within the project we treat each module
independently for the purposes of maintenance, release etc.  So that if the
geometry module is ready to cut a new release it may do so without being
held up by issues in the other modules.

So, how to accomplish this and still have CM appear to be and behave like
one project?  Each module would have it's own development branch.  In the
master branch would be a copy of the last released version of each module.
Development happens in the development branch.  When a module is ready to
release, it merges into the master branch, bumps the version and releases
the whole thing (i.e. all of CM).

So, e.g. say CM 4.3.5 has versions 4.1.7 of the linear algebra module and
4.2.8 of the geometry module.  The geometry module is ready to make a new
release, so it merges into master and bumps CM to 4.3.6 and geometry to
4.2.9.  The linear algebra module stays at 4.1.7.  So CM 4.3.6 is the same
as 4.3.5 except for the geometry module, which is now at 4.2.9.

While working this out I took a stab at splitting CM into modules.  I ran
into issues with the stats & distribution packages as many of the tests for
other classes depend on them.  So there's some work there to detangle some
of the packages.  But I was able to split out geometry, transform,
optimizers, filter, diffeq and machine learning without a lot of trouble.
See https://github.com/RayDeCampo/commons-math/tree/modules if you are
interested.


On Tue, Sep 5, 2017 at 8:33 AM, Emmanuel Bourg  wrote:

> Le 4/09/2017 à 15:30, Gilles a écrit :
>
> > I see it as a fundamental one: Why should codes unrelated
> > by scope be artificially tied together by management rules
> > (such as design, supported language version, release schedule,
> > etc.)?[1]
>
> Because they share the same general scope of being math related. The
> design and the supported language version can be different for each
module.
>
>
> > Why do you "prefer" multi-module, independently of the subject
> > matters being talked about?
>
> I already explained twice in this thread.
>
>
> > Please comment on my suggestion to create a single maven project
> > for the whole of "Commons".  I'd agree that this suggestion is
> > ridiculous; yet some of you do the same proposal for "everything
> > math-related".
>
> If you want to use an absurd proposal to prove your point let me try
> that game too: Please comment on my suggestion to create multiple
> components out of every Java package defined in the Commons components.
>
>
> > If you had been contributing to the math code

Re: [All][Math] New component: "Commons Geometry"?

[Raymond DeCampo]

I know I haven't been around lately, but I this exchange caught my eye.

I was trying to figure out a way to balance the issues, first, that there
is resistance to creating a large number of projects spun out from CM and
second, that there is a practical limit to how large a project can be
maintained with the current resources.

What I came up with is as follows:  suppose we take CM and split it up into
a number of modules.  Then within the project we treat each module
independently for the purposes of maintenance, release etc.  So that if the
geometry module is ready to cut a new release it may do so without being
held up by issues in the other modules.

So, how to accomplish this and still have CM appear to be and behave like
one project?  Each module would have it's own development branch.  In the
master branch would be a copy of the last released version of each module.
Development happens in the development branch.  When a module is ready to
release, it merges into the master branch, bumps the version and releases
the whole thing (i.e. all of CM).

So, e.g. say CM 4.3.5 has versions 4.1.7 of the linear algebra module and
4.2.8 of the geometry module.  The geometry module is ready to make a new
release, so it merges into master and bumps CM to 4.3.6 and geometry to
4.2.9.  The linear algebra module stays at 4.1.7.  So CM 4.3.6 is the same
as 4.3.5 except for the geometry module, which is now at 4.2.9.

While working this out I took a stab at splitting CM into modules.  I ran
into issues with the stats & distribution packages as many of the tests for
other classes depend on them.  So there's some work there to detangle some
of the packages.  But I was able to split out geometry, transform,
optimizers, filter, diffeq and machine learning without a lot of trouble.
See https://github.com/RayDeCampo/commons-math/tree/modules if you are
interested.


On Tue, Sep 5, 2017 at 8:33 AM, Emmanuel Bourg  wrote:

> Le 4/09/2017 à 15:30, Gilles a écrit :
>
> > I see it as a fundamental one: Why should codes unrelated
> > by scope be artificially tied together by management rules
> > (such as design, supported language version, release schedule,
> > etc.)?[1]
>
> Because they share the same general scope of being math related. The
> design and the supported language version can be different for each module.
>
>
> > Why do you "prefer" multi-module, independently of the subject
> > matters being talked about?
>
> I already explained twice in this thread.
>
>
> > Please comment on my suggestion to create a single maven project
> > for the whole of "Commons".  I'd agree that this suggestion is
> > ridiculous; yet some of you do the same proposal for "everything
> > math-related".
>
> If you want to use an absurd proposal to prove your point let me try
> that game too: Please comment on my suggestion to create multiple
> components out of every Java package defined in the Commons components.
>
>
> > If you had been contributing to the math codes (plural), you
> > perhaps would have understood that it creates more management
> > problems than it solves.[4]
>
> Please use foot references for external links only, your messages are
> unreadable if we have to go back and forth to understand them.
>
>
> > Again, I have to stress on what happened that led me to propose
> > a new "Commons RNG": obvious improvements to the CM code base
> > were outrightly rejected based on demonstrably false statements;
> > i.e. the objections were not technical but for the convenience
> > of one user.
>
> I still think that splitting RNG into its own component was a good move.
> I'm less happy with Numbers, I'd have preferred a module from a
> renovated "CM5" project started from scratch as I'm suggesting now for
> Geometry.
>
>
> > Do you think that I enjoy contradicting you on these matters?
>
> I'm starting to think that you enjoy rhetoric, probably more than
> seeking compromise unfortunately.
>
>
> > Do they want to implement another plan?  What plan?
>
> Here is my counter-proposal:
>
> 1. Refactor Commons Math as a multi-module project, bump to version 5
> 2. Create two modules: geometry and legacy
> 3. Release Commons Math 5, without the legacy module
> 4. Spin-off new modules from the legacy module when needed
>
> And I'm willing to help at least for the steps 1 and 2.
>
> Emmanuel Bourg
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
> For additional commands, e-mail: dev-h...@commons.apache.org
>
>

Re: Re: [JCS] missing 2.2 release in jira?

[Romain Manni-Bucau]

Hi Thomas,

on mails: with gmail it looks ok but think it does some things under the
hood too.

on the perf: I see and agree, will try to get some time end of the month to
investigate it, thanks for the precision!


Romain Manni-Bucau
@rmannibucau  |  Blog
 | Old Blog
 | Github  |
LinkedIn  | JavaEE Factory


2017-09-10 17:28 GMT+02:00 Thomas Vandahl :

> Hi folks,
>
> I found out again that replying to the list did reply to the sender
> instead. Does that happen to anyone else or is it my Thunderbird setting?
>
> Bye, Thomas
>
>  Forwarded Message 
> Subject: Re: [JCS] missing 2.2 release in jira?
> Date: Sat, 9 Sep 2017 10:58:54 +0200
> From: Thomas Vandahl 
> To: Romain Manni-Bucau 
>
> On 08.09.17 16:41, Romain Manni-Bucau wrote:
> > So it would be a 3.0. Do we expect anything else in a potential 3.0?
>
> I made an attempt to integrate the ConcurrentLinkedHashMap by Ben Manes.
> See
> https://svn.apache.org/repos/asf/commons/proper/jcs/
> branches/jcs-core-with-clhm
> This would be a candidate feature for 3.0.
> However, several (apparently unrelated) tests started to fail. Moreover,
> the performance tests showed little or no improvement. If you want to
> give it another shot, feel free.
>
> Bye, Thomas
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
> For additional commands, e-mail: dev-h...@commons.apache.org
>
>

Fwd: Re: [JCS] missing 2.2 release in jira?

[Thomas Vandahl]

Hi folks,

I found out again that replying to the list did reply to the sender
instead. Does that happen to anyone else or is it my Thunderbird setting?

Bye, Thomas

 Forwarded Message 
Subject: Re: [JCS] missing 2.2 release in jira?
Date: Sat, 9 Sep 2017 10:58:54 +0200
From: Thomas Vandahl 
To: Romain Manni-Bucau 

On 08.09.17 16:41, Romain Manni-Bucau wrote:
> So it would be a 3.0. Do we expect anything else in a potential 3.0?

I made an attempt to integrate the ConcurrentLinkedHashMap by Ben Manes.
See
https://svn.apache.org/repos/asf/commons/proper/jcs/branches/jcs-core-with-clhm
This would be a candidate feature for 3.0.
However, several (apparently unrelated) tests started to fail. Moreover,
the performance tests showed little or no improvement. If you want to
give it another shot, feel free.

Bye, Thomas

-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org

Re: [JCS] missing 2.2 release in jira?

[Thomas Vandahl]

On 09.09.17 15:43, Romain Manni-Bucau wrote:
> What does references "perf test" here? something from the project? I'm
> interested in the fact CompositeCache doesn't have this synchronized
> block anymore which could scale way better with multiple threads if we
> ensure nested calls can scale as well (are not themself synchronized).

My reference always is JCSConcurrentCacheAccessUnitTest.java. The memory
caches should have locking mechanisms on their own and the auxiliary
updates are asynchronous anyway.

Bye, Thomas

-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org

[text] Invalid unicode sequences on .substring of RandomStringGenerator

[Amey Jadiye]

Hi Folks,

While working on RandomStringGenerator I found when I'm doing .substring on
generated random string its failing intermittently with sequence of
surrogate pair.
same bug was raised in commons-lang
https://issues.apache.org/jira/browse/LANG-100

Is this possible bug with RandomStringGenerator ? or is this expected ?

@Test
public void testSubStringWithSurrogatePair() {
final int size = 5000;
final Charset charset = Charset.forName("UTF-8");
RandomStringGenerator generator = new
RandomStringGenerator.Builder().build();
String orig = generator.generate(size).substring(0,2500);

final byte[] bytes = orig.getBytes(charset);
final String copy = new String(bytes, charset);

for (int i=0; i < orig.length() && i < copy.length(); i++) {
final char o = orig.charAt(i);
final char c = copy.charAt(i);
assertEquals("differs at " + i + "(" + Integer.toHexString(new
Character(o).hashCode()) + "," +
Integer.toHexString(new Character(c).hashCode()) + ")", o,
c);
}

}

Regards,
Amey


-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org

[GitHub] commons-text issue #62: TEXT-101: Moved RandomStringUtils to Commons-text

[ameyjadiye]

Github user ameyjadiye commented on the issue:

https://github.com/apache/commons-text/pull/62
  
@chtompki , can you please take look at this PR ?


---

-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org

[GitHub] commons-text issue #62: TEXT-101: Moved RandomStringUtils to Commons-text

[coveralls]

Github user coveralls commented on the issue:

https://github.com/apache/commons-text/pull/62
  

[![Coverage 
Status](https://coveralls.io/builds/13202986/badge)](https://coveralls.io/builds/13202986)

Coverage increased (+0.0002%) to 98.292% when pulling 
**0f59229bcceafd97bbb3d7a0fdac6b006d09e829 on ameyjadiye:TEXT-101** into 
**30a29e2cf20e4c2036b423399a91cd01cd1759b6 on apache:master**.



---

-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org

[GitHub] commons-text issue #62: TEXT-101: Moved RandomStringUtils to Commons-text

[coveralls]

Github user coveralls commented on the issue:

https://github.com/apache/commons-text/pull/62
  

[![Coverage 
Status](https://coveralls.io/builds/13202986/badge)](https://coveralls.io/builds/13202986)

Coverage increased (+0.0002%) to 98.292% when pulling 
**0f59229bcceafd97bbb3d7a0fdac6b006d09e829 on ameyjadiye:TEXT-101** into 
**30a29e2cf20e4c2036b423399a91cd01cd1759b6 on apache:master**.



---

-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org