[GitHub] commons-lang issue #317: Predictable randomness in shuffle tests

[coveralls]

Github user coveralls commented on the issue:

https://github.com/apache/commons-lang/pull/317
  

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

Coverage decreased (-0.1%) to 95.137% when pulling 
**a26b6b46f1e495e7a5fd5fa6873b0bc45eea8853 on 
mureinik:shuffle-tests-predictable-random** into 
**415eb9ebb755cea4753d6191b166b88192de5b41 on apache:master**.



---

[GitHub] commons-lang issue #317: Predictable randomness in shuffle tests

[mureinik]

Github user mureinik commented on the issue:

https://github.com/apache/commons-lang/pull/317
  
This is an alternative approach to #316, and is discussed in the thread 
started in 
http://mail-archives.apache.org/mod_mbox/commons-dev/201802.mbox/%3CCAO2EVT7zk8j3-wPU54jGNKeLs%3Dyok-puAgNXg%3DGLEj38abUzHQ%40mail.gmail.com%3E


---

[jira] [Commented] (LANG-1373) Stopwatch based capability for nested, named, timings in a call stack

[Gary Gregory (JIRA)]

[ 
https://issues.apache.org/jira/browse/LANG-1373?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16379770#comment-16379770
 ] 

Gary Gregory commented on LANG-1373:


Talking about Commons Testing probably belongs in the ML. I proposed a more 
generic "Commons Testing" to allow for unit testing, integration testing, and 
so on. The idea is to have specific components for specific dependencies like 
JUnit 4 (vs. 5), MongoDB and who knows what's next.

Gary

> Stopwatch based capability for nested, named, timings in a call stack
> -
>
> Key: LANG-1373
> URL: https://issues.apache.org/jira/browse/LANG-1373
> Project: Commons Lang
>  Issue Type: New Feature
>  Components: lang.time.*
>Reporter: Otto Fowler
>Assignee: Otto Fowler
>Priority: Major
>  Labels: commons-lang,
> Attachments: LANG-1373.patch
>
>
> While working on adding some timing functionality to a Metron feature, I came 
> across the
> Stopwatch class, but found that it didn’t suite my needs.
> What I wanted to do was to create a timing from a top level function in our 
> Stellar dsl, and have have a group of related timings, such that the end 
> result was the overall time of the call, and nested timings of other calls 
> executed during the dsl execution of that function. These timings would all 
> be named, and have a path for identification and include timing the language 
> compiler/execution as well as the function execution itself. It would be 
> helpful if they were tagged in some way as well, such that the consumer could 
> filter during visitation.
> So I have written StackWatch to provide this functionality, and submitted it 
> in a Metron PR.
> From the PR description:
> StackWatch
> A set of utility classes under the new package stellar.common.timing have 
> been added. These provide the StackWatch functionality.
> StackWatch provides an abstraction over the Apache Commons StopWatch class 
> that allows callers to create multiple named and possibly nested timing 
> operations.
> <…>
> This class may be more generally useful to this and other projects, but I am 
> not sure where it would live since we wouldn’t want it in common.
> StackWatch uses a combination of Deque and a custom Tree implementation to 
> create, start and end timing operations.
> A Visitor pattern is also implemented to allow for retrieving the results 
> after the completion of the operation.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Resolved] (MATH-1445) Delete class "Complex"

[Gilles (JIRA)]

 [ 
https://issues.apache.org/jira/browse/MATH-1445?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Gilles resolved MATH-1445.
--
Resolution: Done

commit 583d9ec8647a7f667bb8f22cecf9859187149ade

> Delete class "Complex"
> --
>
> Key: MATH-1445
> URL: https://issues.apache.org/jira/browse/MATH-1445
> Project: Commons Math
>  Issue Type: Sub-task
>Reporter: Gilles
>Priority: Major
>  Labels: dependency, refactoring
> Fix For: 4.0
>
>
> Replace all occurrences of that class by its equivalent in "Commons Numbers" 
> (defined in module {{commons-numbers-complex}}).



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Commented] (MATH-1416) Depend on "Commons Numbers"

[Gilles (JIRA)]

[ 
https://issues.apache.org/jira/browse/MATH-1416?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16379699#comment-16379699
 ] 

Gilles commented on MATH-1416:
--

Class {{o.a.c.math4.complex.Complex}} was removed in commit 
583d9ec8647a7f667bb8f22cecf9859187149ade (on "master).

Class {{o.a.c.math4.complex.ComplexField}} was also removed due to its tight 
coupling with {{o.a.c.math4.complex.Complex}}.  See discussion about NUMBERS-51 
(inconclusive but verging towards the need to re-implement the "field" concept 
in a cleaner way).

> Depend on "Commons Numbers"
> ---
>
> Key: MATH-1416
> URL: https://issues.apache.org/jira/browse/MATH-1416
> Project: Commons Math
>  Issue Type: Task
>Reporter: Gilles
>Priority: Major
>  Labels: dependency, deprecated
> Fix For: 4.0
>
>
> The following codes with an equivalent in ["Commons 
> Numbers"|http://commons.apache.org/proper/commons-numbers] must be deleted 
> before the next major release (4.0):
> * Package {{o.a.c.math4.fraction}}
> * Package {{o.a.c.math4.complex}}
> * Package {{o.a.c.math4.primes}} 
> Codes that depend on these functionalities must be updated with corresponding 
> calls to "Commons Numbers" classes.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Commented] (COMMONSSITE-103) GSOC: Apache Commons bug bounty

[Kamila Molina (JIRA)]

[ 
https://issues.apache.org/jira/browse/COMMONSSITE-103?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16379596#comment-16379596
 ] 

Kamila Molina commented on COMMONSSITE-103:
---

Hi, I am a student and would be interested in moving commons-rdf to Java 9 the 
modular system or is there other issues I can work?

Kamila.

> GSOC: Apache Commons bug bounty
> ---
>
> Key: COMMONSSITE-103
> URL: https://issues.apache.org/jira/browse/COMMONSSITE-103
> Project: Commons All
>  Issue Type: New Feature
>Reporter: Stian Soiland-Reyes
>Priority: Major
>  Labels: commons, gsoc2018, library
>
> [Apache Commons|https://commons.apache.org/] is a project that manage a 
> series of independent Java libraries called 
> [components|https://commons.apache.org/components.html]. 
> Some of the perhaps most well known components include 
> [commons-io|https://commons.apache.org/proper/commons-io/], 
> [commons-lang|https://commons.apache.org/proper/commons-lang/], 
> [commons-collections|https://commons.apache.org/proper/commons-collections/] 
> and [commons-cli|https://commons.apache.org/proper/commons-cli/]
> But did you know that Commons is also managing some more specialized 
> components like 
> [commons-crypto|https://commons.apache.org/proper/commons-crypto/], 
> [commons-numbers|https://commons.apache.org/proper/commons-numbers/], 
> [commons-rng|https://commons.apache.org/proper/commons-rng/] and 
> [commons-rdf|https://commons.apache.org/proper/commons-rdf/] ?
> The potential GSOC student will propose an idea to work with one or more 
> chosen Apache Commons components to churn through any outstanding Jira 
> issues, update for Java 8/9, improve web site, documentation or testing.
> As the appropriate GSOC mentor will depend slightly on which Commons 
> component the student is interested in, prospective students are encouraged 
> to engage early by subscribing and posting to 
> [dev@commons|https://lists.apache.org/list.html?d...@commons.apache.org] 
> using the subject tag [GSOC] and the  commons  component(s) they are intested 
> in, e.g.
> {quote}
> To: d...@commons.apache.org
> Subject: [GSOC] [Crypto] Potential GSOC idea
> Hi, I am Alice, student at Foo university, and I am interested in GSOC for 
> Apache Commons, in particular Commons Crypto as I have been quite involved in 
> cryptography protocols over the years together with my friend Bob.
> What could be a good chunk of work to get started with? Perhaps adding 
> support for rot13?
> {quote}



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Commented] (LANG-1373) Stopwatch based capability for nested, named, timings in a call stack

[Gilles (JIRA)]

[ 
https://issues.apache.org/jira/browse/LANG-1373?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16379555#comment-16379555
 ] 

Gilles commented on LANG-1373:
--

bq. But I would find that confusing.  "Testing" is a meaningful word.  and it 
looks like that is what that projects current modules are for.

*I* have no problem more components.
What would "Commons Perf" contain in addition to {{StackWatch}}?

bq. Commons Testing is all about unit testing.

If the intended scope is unit testing, then perhaps call it "Commons Unit 
Testing". ;)
Examining code performance is also viewed as "testing". Nothing particularly 
shocking in having a module {{commons-testing-performance}}. Of course, care 
should be taken to segregate general-purpose utilities from those that drag 
dependencies such as Junit.

> Stopwatch based capability for nested, named, timings in a call stack
> -
>
> Key: LANG-1373
> URL: https://issues.apache.org/jira/browse/LANG-1373
> Project: Commons Lang
>  Issue Type: New Feature
>  Components: lang.time.*
>Reporter: Otto Fowler
>Assignee: Otto Fowler
>Priority: Major
>  Labels: commons-lang,
> Attachments: LANG-1373.patch
>
>
> While working on adding some timing functionality to a Metron feature, I came 
> across the
> Stopwatch class, but found that it didn’t suite my needs.
> What I wanted to do was to create a timing from a top level function in our 
> Stellar dsl, and have have a group of related timings, such that the end 
> result was the overall time of the call, and nested timings of other calls 
> executed during the dsl execution of that function. These timings would all 
> be named, and have a path for identification and include timing the language 
> compiler/execution as well as the function execution itself. It would be 
> helpful if they were tagged in some way as well, such that the consumer could 
> filter during visitation.
> So I have written StackWatch to provide this functionality, and submitted it 
> in a Metron PR.
> From the PR description:
> StackWatch
> A set of utility classes under the new package stellar.common.timing have 
> been added. These provide the StackWatch functionality.
> StackWatch provides an abstraction over the Apache Commons StopWatch class 
> that allows callers to create multiple named and possibly nested timing 
> operations.
> <…>
> This class may be more generally useful to this and other projects, but I am 
> not sure where it would live since we wouldn’t want it in common.
> StackWatch uses a combination of Deque and a custom Tree implementation to 
> create, start and end timing operations.
> A Visitor pattern is also implemented to allow for retrieving the results 
> after the completion of the operation.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Comment Edited] (LANG-1373) Stopwatch based capability for nested, named, timings in a call stack

[Gary Gregory (JIRA)]

[ 
https://issues.apache.org/jira/browse/LANG-1373?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16379530#comment-16379530
 ] 

Gary Gregory edited comment on LANG-1373 at 2/28/18 12:14 AM:
--

Commons Testing is all about unit testing. For example: I have a junit 4 
specific module. I have another junit 4 + MongoDB specific module.

See https://git1-us-west.apache.org/repos/asf?p=commons-testing.git;a=tree


was (Author: garydgregory):
Commons Testing is all about unit testing. For example: I have a junit 4 
specific module. I have another junit 4 + MongoDB specific module.

> Stopwatch based capability for nested, named, timings in a call stack
> -
>
> Key: LANG-1373
> URL: https://issues.apache.org/jira/browse/LANG-1373
> Project: Commons Lang
>  Issue Type: New Feature
>  Components: lang.time.*
>Reporter: Otto Fowler
>Assignee: Otto Fowler
>Priority: Major
>  Labels: commons-lang,
> Attachments: LANG-1373.patch
>
>
> While working on adding some timing functionality to a Metron feature, I came 
> across the
> Stopwatch class, but found that it didn’t suite my needs.
> What I wanted to do was to create a timing from a top level function in our 
> Stellar dsl, and have have a group of related timings, such that the end 
> result was the overall time of the call, and nested timings of other calls 
> executed during the dsl execution of that function. These timings would all 
> be named, and have a path for identification and include timing the language 
> compiler/execution as well as the function execution itself. It would be 
> helpful if they were tagged in some way as well, such that the consumer could 
> filter during visitation.
> So I have written StackWatch to provide this functionality, and submitted it 
> in a Metron PR.
> From the PR description:
> StackWatch
> A set of utility classes under the new package stellar.common.timing have 
> been added. These provide the StackWatch functionality.
> StackWatch provides an abstraction over the Apache Commons StopWatch class 
> that allows callers to create multiple named and possibly nested timing 
> operations.
> <…>
> This class may be more generally useful to this and other projects, but I am 
> not sure where it would live since we wouldn’t want it in common.
> StackWatch uses a combination of Deque and a custom Tree implementation to 
> create, start and end timing operations.
> A Visitor pattern is also implemented to allow for retrieving the results 
> after the completion of the operation.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Comment Edited] (LANG-1373) Stopwatch based capability for nested, named, timings in a call stack

[Gary Gregory (JIRA)]

[ 
https://issues.apache.org/jira/browse/LANG-1373?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16379530#comment-16379530
 ] 

Gary Gregory edited comment on LANG-1373 at 2/28/18 12:13 AM:
--

Commons Testing is all about unit testing. For example: I have a junit 4 
specific module. I have another junit 4 + MongoDB specific module.


was (Author: garydgregory):
Commons Testing is all about unit testing. For example: I have a junit 4 
specific module. I have another jnut 4 + MongoDB specific module.

> Stopwatch based capability for nested, named, timings in a call stack
> -
>
> Key: LANG-1373
> URL: https://issues.apache.org/jira/browse/LANG-1373
> Project: Commons Lang
>  Issue Type: New Feature
>  Components: lang.time.*
>Reporter: Otto Fowler
>Assignee: Otto Fowler
>Priority: Major
>  Labels: commons-lang,
> Attachments: LANG-1373.patch
>
>
> While working on adding some timing functionality to a Metron feature, I came 
> across the
> Stopwatch class, but found that it didn’t suite my needs.
> What I wanted to do was to create a timing from a top level function in our 
> Stellar dsl, and have have a group of related timings, such that the end 
> result was the overall time of the call, and nested timings of other calls 
> executed during the dsl execution of that function. These timings would all 
> be named, and have a path for identification and include timing the language 
> compiler/execution as well as the function execution itself. It would be 
> helpful if they were tagged in some way as well, such that the consumer could 
> filter during visitation.
> So I have written StackWatch to provide this functionality, and submitted it 
> in a Metron PR.
> From the PR description:
> StackWatch
> A set of utility classes under the new package stellar.common.timing have 
> been added. These provide the StackWatch functionality.
> StackWatch provides an abstraction over the Apache Commons StopWatch class 
> that allows callers to create multiple named and possibly nested timing 
> operations.
> <…>
> This class may be more generally useful to this and other projects, but I am 
> not sure where it would live since we wouldn’t want it in common.
> StackWatch uses a combination of Deque and a custom Tree implementation to 
> create, start and end timing operations.
> A Visitor pattern is also implemented to allow for retrieving the results 
> after the completion of the operation.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Commented] (LANG-1373) Stopwatch based capability for nested, named, timings in a call stack

[Gary Gregory (JIRA)]

[ 
https://issues.apache.org/jira/browse/LANG-1373?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16379530#comment-16379530
 ] 

Gary Gregory commented on LANG-1373:


Commons Testing is all about unit testing. For example: I have a junit 4 
specific module. I have another jnut 4 + MongoDB specific module.

> Stopwatch based capability for nested, named, timings in a call stack
> -
>
> Key: LANG-1373
> URL: https://issues.apache.org/jira/browse/LANG-1373
> Project: Commons Lang
>  Issue Type: New Feature
>  Components: lang.time.*
>Reporter: Otto Fowler
>Assignee: Otto Fowler
>Priority: Major
>  Labels: commons-lang,
> Attachments: LANG-1373.patch
>
>
> While working on adding some timing functionality to a Metron feature, I came 
> across the
> Stopwatch class, but found that it didn’t suite my needs.
> What I wanted to do was to create a timing from a top level function in our 
> Stellar dsl, and have have a group of related timings, such that the end 
> result was the overall time of the call, and nested timings of other calls 
> executed during the dsl execution of that function. These timings would all 
> be named, and have a path for identification and include timing the language 
> compiler/execution as well as the function execution itself. It would be 
> helpful if they were tagged in some way as well, such that the consumer could 
> filter during visitation.
> So I have written StackWatch to provide this functionality, and submitted it 
> in a Metron PR.
> From the PR description:
> StackWatch
> A set of utility classes under the new package stellar.common.timing have 
> been added. These provide the StackWatch functionality.
> StackWatch provides an abstraction over the Apache Commons StopWatch class 
> that allows callers to create multiple named and possibly nested timing 
> operations.
> <…>
> This class may be more generally useful to this and other projects, but I am 
> not sure where it would live since we wouldn’t want it in common.
> StackWatch uses a combination of Deque and a custom Tree implementation to 
> create, start and end timing operations.
> A Visitor pattern is also implemented to allow for retrieving the results 
> after the completion of the operation.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Updated] (COMMONSSITE-103) GSOC: Apache Commons bug bounty

[Stian Soiland-Reyes (JIRA)]

 [ 
https://issues.apache.org/jira/browse/COMMONSSITE-103?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Stian Soiland-Reyes updated COMMONSSITE-103:

Labels: gsoc2018  (was: )

> GSOC: Apache Commons bug bounty
> ---
>
> Key: COMMONSSITE-103
> URL: https://issues.apache.org/jira/browse/COMMONSSITE-103
> Project: Commons All
>  Issue Type: New Feature
>Reporter: Stian Soiland-Reyes
>Priority: Major
>  Labels: commons, gsoc2018, library
>
> [Apache Commons|https://commons.apache.org/] is a project that manage a 
> series of independent Java libraries called 
> [components|https://commons.apache.org/components.html]. 
> Some of the perhaps most well known components include 
> [commons-io|https://commons.apache.org/proper/commons-io/], 
> [commons-lang|https://commons.apache.org/proper/commons-lang/], 
> [commons-collections|https://commons.apache.org/proper/commons-collections/] 
> and [commons-cli|https://commons.apache.org/proper/commons-cli/]
> But did you know that Commons is also managing some more specialized 
> components like 
> [commons-crypto|https://commons.apache.org/proper/commons-crypto/], 
> [commons-numbers|https://commons.apache.org/proper/commons-numbers/], 
> [commons-rng|https://commons.apache.org/proper/commons-rng/] and 
> [commons-rdf|https://commons.apache.org/proper/commons-rdf/] ?
> The potential GSOC student will propose an idea to work with one or more 
> chosen Apache Commons components to churn through any outstanding Jira 
> issues, update for Java 8/9, improve web site, documentation or testing.
> As the appropriate GSOC mentor will depend slightly on which Commons 
> component the student is interested in, prospective students are encouraged 
> to engage early by subscribing and posting to 
> [dev@commons|https://lists.apache.org/list.html?d...@commons.apache.org] 
> using the subject tag [GSOC] and the  commons  component(s) they are intested 
> in, e.g.
> {quote}
> To: d...@commons.apache.org
> Subject: [GSOC] [Crypto] Potential GSOC idea
> Hi, I am Alice, student at Foo university, and I am interested in GSOC for 
> Apache Commons, in particular Commons Crypto as I have been quite involved in 
> cryptography protocols over the years together with my friend Bob.
> What could be a good chunk of work to get started with? Perhaps adding 
> support for rot13?
> {quote}



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Updated] (COMMONSSITE-103) GSOC: Apache Commons bug bounty

[Stian Soiland-Reyes (JIRA)]

 [ 
https://issues.apache.org/jira/browse/COMMONSSITE-103?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Stian Soiland-Reyes updated COMMONSSITE-103:

Labels: commons gsoc2018 library  (was: gsoc2018)

> GSOC: Apache Commons bug bounty
> ---
>
> Key: COMMONSSITE-103
> URL: https://issues.apache.org/jira/browse/COMMONSSITE-103
> Project: Commons All
>  Issue Type: New Feature
>Reporter: Stian Soiland-Reyes
>Priority: Major
>  Labels: commons, gsoc2018, library
>
> [Apache Commons|https://commons.apache.org/] is a project that manage a 
> series of independent Java libraries called 
> [components|https://commons.apache.org/components.html]. 
> Some of the perhaps most well known components include 
> [commons-io|https://commons.apache.org/proper/commons-io/], 
> [commons-lang|https://commons.apache.org/proper/commons-lang/], 
> [commons-collections|https://commons.apache.org/proper/commons-collections/] 
> and [commons-cli|https://commons.apache.org/proper/commons-cli/]
> But did you know that Commons is also managing some more specialized 
> components like 
> [commons-crypto|https://commons.apache.org/proper/commons-crypto/], 
> [commons-numbers|https://commons.apache.org/proper/commons-numbers/], 
> [commons-rng|https://commons.apache.org/proper/commons-rng/] and 
> [commons-rdf|https://commons.apache.org/proper/commons-rdf/] ?
> The potential GSOC student will propose an idea to work with one or more 
> chosen Apache Commons components to churn through any outstanding Jira 
> issues, update for Java 8/9, improve web site, documentation or testing.
> As the appropriate GSOC mentor will depend slightly on which Commons 
> component the student is interested in, prospective students are encouraged 
> to engage early by subscribing and posting to 
> [dev@commons|https://lists.apache.org/list.html?d...@commons.apache.org] 
> using the subject tag [GSOC] and the  commons  component(s) they are intested 
> in, e.g.
> {quote}
> To: d...@commons.apache.org
> Subject: [GSOC] [Crypto] Potential GSOC idea
> Hi, I am Alice, student at Foo university, and I am interested in GSOC for 
> Apache Commons, in particular Commons Crypto as I have been quite involved in 
> cryptography protocols over the years together with my friend Bob.
> What could be a good chunk of work to get started with? Perhaps adding 
> support for rot13?
> {quote}



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Created] (COMMONSSITE-103) GSOC: Apache Commons bug bounty

[Stian Soiland-Reyes (JIRA)]

Stian Soiland-Reyes created COMMONSSITE-103:
---

 Summary: GSOC: Apache Commons bug bounty
 Key: COMMONSSITE-103
 URL: https://issues.apache.org/jira/browse/COMMONSSITE-103
 Project: Commons All
  Issue Type: New Feature
Reporter: Stian Soiland-Reyes


[Apache Commons|https://commons.apache.org/] is a project that manage a series 
of independent Java libraries called 
[components|https://commons.apache.org/components.html]. 

Some of the perhaps most well known components include 
[commons-io|https://commons.apache.org/proper/commons-io/], 
[commons-lang|https://commons.apache.org/proper/commons-lang/], 
[commons-collections|https://commons.apache.org/proper/commons-collections/] 
and [commons-cli|https://commons.apache.org/proper/commons-cli/]

But did you know that Commons is also managing some more specialized components 
like [commons-crypto|https://commons.apache.org/proper/commons-crypto/], 
[commons-numbers|https://commons.apache.org/proper/commons-numbers/], 
[commons-rng|https://commons.apache.org/proper/commons-rng/] and 
[commons-rdf|https://commons.apache.org/proper/commons-rdf/] ?

The potential GSOC student will propose an idea to work with one or more chosen 
Apache Commons components to churn through any outstanding Jira issues, update 
for Java 8/9, improve web site, documentation or testing.

As the appropriate GSOC mentor will depend slightly on which Commons component 
the student is interested in, prospective students are encouraged to engage 
early by subscribing and posting to 
[dev@commons|https://lists.apache.org/list.html?d...@commons.apache.org] using 
the subject tag [GSOC] and the  commons  component(s) they are intested in, e.g.

{quote}
To: d...@commons.apache.org
Subject: [GSOC] [Crypto] Potential GSOC idea


Hi, I am Alice, student at Foo university, and I am interested in GSOC for 
Apache Commons, in particular Commons Crypto as I have been quite involved in 
cryptography protocols over the years together with my friend Bob.

What could be a good chunk of work to get started with? Perhaps adding support 
for rot13?
{quote}




--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Comment Edited] (LANG-1373) Stopwatch based capability for nested, named, timings in a call stack

[Otto Fowler (JIRA)]

[ 
https://issues.apache.org/jira/browse/LANG-1373?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16379485#comment-16379485
 ] 

Otto Fowler edited comment on LANG-1373 at 2/27/18 11:38 PM:
-

So, when I hear 'commons-testing' I think of junit, testng  etc helpers, 
annotations, mocks, base suites etc.

If you say testing is just a name ( and the fact that the first things in there 
are junit things is co-incidence ) then ok.  

We can make a module that it not for unit/integration testing, not typical mvn 
test scope stuff, and is for some other definition of testing.

But I would find that confusing.  "Testing" is a meaningful word.  and it looks 
like that is what that projects current modules are for.

 

 


was (Author: ottobackwards):
So, when I hear 'commons-testing' I think of junit, testng  etc helpers, 
annotations, mocks, base suites etc.

If you say testing is just a name ( and the fact that the first things in there 
are junit things is co-incidence ) then ok.  

We can make a module that it not for unit/integration testing, not typical mvn 
test scope stuff, and is for some other definition of testing.

But I would find that confusing.  "Testing" is a meaningful word.  and it looks 
like that is what that module is for.

 

 

> Stopwatch based capability for nested, named, timings in a call stack
> -
>
> Key: LANG-1373
> URL: https://issues.apache.org/jira/browse/LANG-1373
> Project: Commons Lang
>  Issue Type: New Feature
>  Components: lang.time.*
>Reporter: Otto Fowler
>Assignee: Otto Fowler
>Priority: Major
>  Labels: commons-lang,
> Attachments: LANG-1373.patch
>
>
> While working on adding some timing functionality to a Metron feature, I came 
> across the
> Stopwatch class, but found that it didn’t suite my needs.
> What I wanted to do was to create a timing from a top level function in our 
> Stellar dsl, and have have a group of related timings, such that the end 
> result was the overall time of the call, and nested timings of other calls 
> executed during the dsl execution of that function. These timings would all 
> be named, and have a path for identification and include timing the language 
> compiler/execution as well as the function execution itself. It would be 
> helpful if they were tagged in some way as well, such that the consumer could 
> filter during visitation.
> So I have written StackWatch to provide this functionality, and submitted it 
> in a Metron PR.
> From the PR description:
> StackWatch
> A set of utility classes under the new package stellar.common.timing have 
> been added. These provide the StackWatch functionality.
> StackWatch provides an abstraction over the Apache Commons StopWatch class 
> that allows callers to create multiple named and possibly nested timing 
> operations.
> <…>
> This class may be more generally useful to this and other projects, but I am 
> not sure where it would live since we wouldn’t want it in common.
> StackWatch uses a combination of Deque and a custom Tree implementation to 
> create, start and end timing operations.
> A Visitor pattern is also implemented to allow for retrieving the results 
> after the completion of the operation.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Commented] (LANG-1373) Stopwatch based capability for nested, named, timings in a call stack

[Otto Fowler (JIRA)]

[ 
https://issues.apache.org/jira/browse/LANG-1373?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16379485#comment-16379485
 ] 

Otto Fowler commented on LANG-1373:
---

So, when I hear 'commons-testing' I think of junit, testng  etc helpers, 
annotations, mocks, base suites etc.

If you say testing is just a name ( and the fact that the first things in there 
are junit things is co-incidence ) then ok.  

We can make a module that it not for unit/integration testing, not typical mvn 
test scope stuff, and is for some other definition of testing.

But I would find that confusing.  "Testing" is a meaningful word.  and it looks 
like that is what that module is for.

 

 

> Stopwatch based capability for nested, named, timings in a call stack
> -
>
> Key: LANG-1373
> URL: https://issues.apache.org/jira/browse/LANG-1373
> Project: Commons Lang
>  Issue Type: New Feature
>  Components: lang.time.*
>Reporter: Otto Fowler
>Assignee: Otto Fowler
>Priority: Major
>  Labels: commons-lang,
> Attachments: LANG-1373.patch
>
>
> While working on adding some timing functionality to a Metron feature, I came 
> across the
> Stopwatch class, but found that it didn’t suite my needs.
> What I wanted to do was to create a timing from a top level function in our 
> Stellar dsl, and have have a group of related timings, such that the end 
> result was the overall time of the call, and nested timings of other calls 
> executed during the dsl execution of that function. These timings would all 
> be named, and have a path for identification and include timing the language 
> compiler/execution as well as the function execution itself. It would be 
> helpful if they were tagged in some way as well, such that the consumer could 
> filter during visitation.
> So I have written StackWatch to provide this functionality, and submitted it 
> in a Metron PR.
> From the PR description:
> StackWatch
> A set of utility classes under the new package stellar.common.timing have 
> been added. These provide the StackWatch functionality.
> StackWatch provides an abstraction over the Apache Commons StopWatch class 
> that allows callers to create multiple named and possibly nested timing 
> operations.
> <…>
> This class may be more generally useful to this and other projects, but I am 
> not sure where it would live since we wouldn’t want it in common.
> StackWatch uses a combination of Deque and a custom Tree implementation to 
> create, start and end timing operations.
> A Visitor pattern is also implemented to allow for retrieving the results 
> after the completion of the operation.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Commented] (LANG-1373) Stopwatch based capability for nested, named, timings in a call stack

[Gilles (JIRA)]

[ 
https://issues.apache.org/jira/browse/LANG-1373?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16379418#comment-16379418
 ] 

Gilles commented on LANG-1373:
--

bq. I don't think I'd want to pull in things that I'd normally restrict to test 
scope into my deployments.

Why would it be restricted in any way?
The prospective module could be used in unit tests but also in "useful" code.

> Stopwatch based capability for nested, named, timings in a call stack
> -
>
> Key: LANG-1373
> URL: https://issues.apache.org/jira/browse/LANG-1373
> Project: Commons Lang
>  Issue Type: New Feature
>  Components: lang.time.*
>Reporter: Otto Fowler
>Assignee: Otto Fowler
>Priority: Major
>  Labels: commons-lang,
> Attachments: LANG-1373.patch
>
>
> While working on adding some timing functionality to a Metron feature, I came 
> across the
> Stopwatch class, but found that it didn’t suite my needs.
> What I wanted to do was to create a timing from a top level function in our 
> Stellar dsl, and have have a group of related timings, such that the end 
> result was the overall time of the call, and nested timings of other calls 
> executed during the dsl execution of that function. These timings would all 
> be named, and have a path for identification and include timing the language 
> compiler/execution as well as the function execution itself. It would be 
> helpful if they were tagged in some way as well, such that the consumer could 
> filter during visitation.
> So I have written StackWatch to provide this functionality, and submitted it 
> in a Metron PR.
> From the PR description:
> StackWatch
> A set of utility classes under the new package stellar.common.timing have 
> been added. These provide the StackWatch functionality.
> StackWatch provides an abstraction over the Apache Commons StopWatch class 
> that allows callers to create multiple named and possibly nested timing 
> operations.
> <…>
> This class may be more generally useful to this and other projects, but I am 
> not sure where it would live since we wouldn’t want it in common.
> StackWatch uses a combination of Deque and a custom Tree implementation to 
> create, start and end timing operations.
> A Visitor pattern is also implemented to allow for retrieving the results 
> after the completion of the operation.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Commented] (DAEMON-381) StopTimeout not working

[Gary Gregory (JIRA)]

[ 
https://issues.apache.org/jira/browse/DAEMON-381?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16379393#comment-16379393
 ] 

Gary Gregory commented on DAEMON-381:
-

Well, ideally both.

> StopTimeout not working
> ---
>
> Key: DAEMON-381
> URL: https://issues.apache.org/jira/browse/DAEMON-381
> Project: Commons Daemon
>  Issue Type: Bug
>  Components: Procrun
>Affects Versions: 1.0.14, 1.0.15, 1.1.0
> Environment: Windows 10, JDK 1.8.0_161, Spring Boot 1.3.6.RELEASE
>Reporter: David Webb
>Priority: Major
>
> With the stopTimeout set to 5 seconds, and a test application that sleeps for 
> 30 seconds after given the stop command, one would expect the prunsrv process 
> to be killed after 5 seconds.
> The process stays alive for 30 seconds before terminating.
> Based on the documentation I feel I am using this parameter correctly.  The 
> daemon should wait 5 seconds for the wrapped java process to terminate 
> gracefully, then terminate it.
>  
>  



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Commented] (DAEMON-381) StopTimeout not working

[David Webb (JIRA)]

[ 
https://issues.apache.org/jira/browse/DAEMON-381?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16379315#comment-16379315
 ] 

David Webb commented on DAEMON-381:
---

[~garydgregory] - A PR with what? :)  The fix or an example to reproduce? 
Thanks.

 

> StopTimeout not working
> ---
>
> Key: DAEMON-381
> URL: https://issues.apache.org/jira/browse/DAEMON-381
> Project: Commons Daemon
>  Issue Type: Bug
>  Components: Procrun
>Affects Versions: 1.0.14, 1.0.15, 1.1.0
> Environment: Windows 10, JDK 1.8.0_161, Spring Boot 1.3.6.RELEASE
>Reporter: David Webb
>Priority: Major
>
> With the stopTimeout set to 5 seconds, and a test application that sleeps for 
> 30 seconds after given the stop command, one would expect the prunsrv process 
> to be killed after 5 seconds.
> The process stays alive for 30 seconds before terminating.
> Based on the documentation I feel I am using this parameter correctly.  The 
> daemon should wait 5 seconds for the wrapped java process to terminate 
> gracefully, then terminate it.
>  
>  



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Commented] (LANG-1373) Stopwatch based capability for nested, named, timings in a call stack

[Otto Fowler (JIRA)]

[ 
https://issues.apache.org/jira/browse/LANG-1373?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16379189#comment-16379189
 ] 

Otto Fowler commented on LANG-1373:
---

[~erans], sorry, I could not find a great way to get it all working based on 
that bug. 

> Stopwatch based capability for nested, named, timings in a call stack
> -
>
> Key: LANG-1373
> URL: https://issues.apache.org/jira/browse/LANG-1373
> Project: Commons Lang
>  Issue Type: New Feature
>  Components: lang.time.*
>Reporter: Otto Fowler
>Assignee: Otto Fowler
>Priority: Major
>  Labels: commons-lang,
> Attachments: LANG-1373.patch
>
>
> While working on adding some timing functionality to a Metron feature, I came 
> across the
> Stopwatch class, but found that it didn’t suite my needs.
> What I wanted to do was to create a timing from a top level function in our 
> Stellar dsl, and have have a group of related timings, such that the end 
> result was the overall time of the call, and nested timings of other calls 
> executed during the dsl execution of that function. These timings would all 
> be named, and have a path for identification and include timing the language 
> compiler/execution as well as the function execution itself. It would be 
> helpful if they were tagged in some way as well, such that the consumer could 
> filter during visitation.
> So I have written StackWatch to provide this functionality, and submitted it 
> in a Metron PR.
> From the PR description:
> StackWatch
> A set of utility classes under the new package stellar.common.timing have 
> been added. These provide the StackWatch functionality.
> StackWatch provides an abstraction over the Apache Commons StopWatch class 
> that allows callers to create multiple named and possibly nested timing 
> operations.
> <…>
> This class may be more generally useful to this and other projects, but I am 
> not sure where it would live since we wouldn’t want it in common.
> StackWatch uses a combination of Deque and a custom Tree implementation to 
> create, start and end timing operations.
> A Visitor pattern is also implemented to allow for retrieving the results 
> after the completion of the operation.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Commented] (LANG-1373) Stopwatch based capability for nested, named, timings in a call stack

[Otto Fowler (JIRA)]

[ 
https://issues.apache.org/jira/browse/LANG-1373?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16379179#comment-16379179
 ] 

Otto Fowler commented on LANG-1373:
---

By the way [~erans] [https://bugs.openjdk.java.net/browse/JDK-8130754] is the 
issue i had with \{@code}

I am working on it again.

> Stopwatch based capability for nested, named, timings in a call stack
> -
>
> Key: LANG-1373
> URL: https://issues.apache.org/jira/browse/LANG-1373
> Project: Commons Lang
>  Issue Type: New Feature
>  Components: lang.time.*
>Reporter: Otto Fowler
>Assignee: Otto Fowler
>Priority: Major
>  Labels: commons-lang,
> Attachments: LANG-1373.patch
>
>
> While working on adding some timing functionality to a Metron feature, I came 
> across the
> Stopwatch class, but found that it didn’t suite my needs.
> What I wanted to do was to create a timing from a top level function in our 
> Stellar dsl, and have have a group of related timings, such that the end 
> result was the overall time of the call, and nested timings of other calls 
> executed during the dsl execution of that function. These timings would all 
> be named, and have a path for identification and include timing the language 
> compiler/execution as well as the function execution itself. It would be 
> helpful if they were tagged in some way as well, such that the consumer could 
> filter during visitation.
> So I have written StackWatch to provide this functionality, and submitted it 
> in a Metron PR.
> From the PR description:
> StackWatch
> A set of utility classes under the new package stellar.common.timing have 
> been added. These provide the StackWatch functionality.
> StackWatch provides an abstraction over the Apache Commons StopWatch class 
> that allows callers to create multiple named and possibly nested timing 
> operations.
> <…>
> This class may be more generally useful to this and other projects, but I am 
> not sure where it would live since we wouldn’t want it in common.
> StackWatch uses a combination of Deque and a custom Tree implementation to 
> create, start and end timing operations.
> A Visitor pattern is also implemented to allow for retrieving the results 
> after the completion of the operation.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[GitHub] commons-lang issue #316: Remove inequality check from shuffle tests

[coveralls]

Github user coveralls commented on the issue:

https://github.com/apache/commons-lang/pull/316
  

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

Coverage remained the same at 95.263% when pulling 
**fa1664f0abc5105e44e97fe8802b05965670dc67 on mureinik:shuffle-tests** into 
**415eb9ebb755cea4753d6191b166b88192de5b41 on apache:master**.



---

[GitHub] commons-lang pull request #316: Remove inequality check from shuffle tests

[mureinik]

GitHub user mureinik opened a pull request:

https://github.com/apache/commons-lang/pull/316

Remove inequality check from shuffle tests

The `ArrayUtils.shuffle` methods could conceivably shuffle an array in a 
way that leaves the shuffled array equal to the original array, and thus 
asserting that the shuffled array differs from the original
array in the test only passes statistically.

The chance of this happening increases as an inverse of the number of 
distinct values in the array. E.g., in the edge case of an array where all the 
elements are equal to each other, shuffling the array has a 100% chance of 
producing an array that's equal to the original array. A less extreme case is 
the case of
`ArrayUtilsTest#testShuffleBoolean` that shuffles an array that contains 
ten elements, but only two distinct values (true and false) has been seen to 
fail in Travis CI [1].

This patch removes this problematic assertion and leaves only the tests on 
the content of the array.

[1] https://travis-ci.org/apache/commons-lang/jobs/346806985

You can merge this pull request into a Git repository by running:

$ git pull https://github.com/mureinik/commons-lang shuffle-tests

Alternatively you can review and apply these changes as the patch at:

https://github.com/apache/commons-lang/pull/316.patch

To close this pull request, make a commit to your master/trunk branch
with (at least) the following in the commit message:

This closes #316


commit fa1664f0abc5105e44e97fe8802b05965670dc67
Author: Allon Mureinik 
Date:   2018-02-27T17:16:34Z

Remove inequality check from shuffle tests

The ArrayUtils.shuffle methods could conceivably shuffle an array in
a way that leaves the shuffled array equal to the original array, and
thus asserting that the shuffled array differs from the original
array in the test only passes statistically.

The chance of this happening increases as an inverse of the number of
distinct values in the array. E.g., in the edge case of an array
where all the elements are equal to each other, shuffling the array
has a 100% chance of producing an array that's equal to the original
array. A less extreme case is the case of
ArrayUtilsTest#testShuffleBoolean that shuffles an array that contains
ten elements, but only two distinct values (true and false) has been
seen to fail in Travis CI [1].

This patch removes this problematic assertion and leaves only the
tests on the content of the array.

[1] https://travis-ci.org/apache/commons-lang/jobs/346806985




---

[jira] [Commented] (LANG-1373) Stopwatch based capability for nested, named, timings in a call stack

[Otto Fowler (JIRA)]

[ 
https://issues.apache.org/jira/browse/LANG-1373?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16378961#comment-16378961
 ] 

Otto Fowler commented on LANG-1373:
---

Well, this is certainly taking a turn.

I don't think testing is correct for this, or stopwatch.  People may want to 
use this in non-test builds and scenarios.  I'm not sure I have a better idea, 
but I don't think I'd want to pull in things that I'd normally restrict to test 
scope into my deployments.

 

> Stopwatch based capability for nested, named, timings in a call stack
> -
>
> Key: LANG-1373
> URL: https://issues.apache.org/jira/browse/LANG-1373
> Project: Commons Lang
>  Issue Type: New Feature
>  Components: lang.time.*
>Reporter: Otto Fowler
>Assignee: Otto Fowler
>Priority: Major
>  Labels: commons-lang,
> Attachments: LANG-1373.patch
>
>
> While working on adding some timing functionality to a Metron feature, I came 
> across the
> Stopwatch class, but found that it didn’t suite my needs.
> What I wanted to do was to create a timing from a top level function in our 
> Stellar dsl, and have have a group of related timings, such that the end 
> result was the overall time of the call, and nested timings of other calls 
> executed during the dsl execution of that function. These timings would all 
> be named, and have a path for identification and include timing the language 
> compiler/execution as well as the function execution itself. It would be 
> helpful if they were tagged in some way as well, such that the consumer could 
> filter during visitation.
> So I have written StackWatch to provide this functionality, and submitted it 
> in a Metron PR.
> From the PR description:
> StackWatch
> A set of utility classes under the new package stellar.common.timing have 
> been added. These provide the StackWatch functionality.
> StackWatch provides an abstraction over the Apache Commons StopWatch class 
> that allows callers to create multiple named and possibly nested timing 
> operations.
> <…>
> This class may be more generally useful to this and other projects, but I am 
> not sure where it would live since we wouldn’t want it in common.
> StackWatch uses a combination of Deque and a custom Tree implementation to 
> create, start and end timing operations.
> A Visitor pattern is also implemented to allow for retrieving the results 
> after the completion of the operation.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Commented] (LANG-1373) Stopwatch based capability for nested, named, timings in a call stack

[ASF GitHub Bot (JIRA)]

[ 
https://issues.apache.org/jira/browse/LANG-1373?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16378949#comment-16378949
 ] 

ASF GitHub Bot commented on LANG-1373:
--

Github user ottobackwards commented on the issue:

https://github.com/apache/commons-lang/pull/311
  
@garydgregory, since we are getting out of code review / pr and into bigger 
issues, can we move your comments to jira?  Gilles doesn't have github and the 
conversation will make more sense if we are all there.


> Stopwatch based capability for nested, named, timings in a call stack
> -
>
> Key: LANG-1373
> URL: https://issues.apache.org/jira/browse/LANG-1373
> Project: Commons Lang
>  Issue Type: New Feature
>  Components: lang.time.*
>Reporter: Otto Fowler
>Assignee: Otto Fowler
>Priority: Major
>  Labels: commons-lang,
> Attachments: LANG-1373.patch
>
>
> While working on adding some timing functionality to a Metron feature, I came 
> across the
> Stopwatch class, but found that it didn’t suite my needs.
> What I wanted to do was to create a timing from a top level function in our 
> Stellar dsl, and have have a group of related timings, such that the end 
> result was the overall time of the call, and nested timings of other calls 
> executed during the dsl execution of that function. These timings would all 
> be named, and have a path for identification and include timing the language 
> compiler/execution as well as the function execution itself. It would be 
> helpful if they were tagged in some way as well, such that the consumer could 
> filter during visitation.
> So I have written StackWatch to provide this functionality, and submitted it 
> in a Metron PR.
> From the PR description:
> StackWatch
> A set of utility classes under the new package stellar.common.timing have 
> been added. These provide the StackWatch functionality.
> StackWatch provides an abstraction over the Apache Commons StopWatch class 
> that allows callers to create multiple named and possibly nested timing 
> operations.
> <…>
> This class may be more generally useful to this and other projects, but I am 
> not sure where it would live since we wouldn’t want it in common.
> StackWatch uses a combination of Deque and a custom Tree implementation to 
> create, start and end timing operations.
> A Visitor pattern is also implemented to allow for retrieving the results 
> after the completion of the operation.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[GitHub] commons-lang issue #311: LANG-1373 Stopwatch based capability for nested, na...

[ottobackwards]

Github user ottobackwards commented on the issue:

https://github.com/apache/commons-lang/pull/311
  
@garydgregory, since we are getting out of code review / pr and into bigger 
issues, can we move your comments to jira?  Gilles doesn't have github and the 
conversation will make more sense if we are all there.


---

[jira] [Commented] (LANG-1373) Stopwatch based capability for nested, named, timings in a call stack

[Gary Gregory (JIRA)]

[ 
https://issues.apache.org/jira/browse/LANG-1373?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16378944#comment-16378944
 ] 

Gary Gregory commented on LANG-1373:


Note that I recently created the Commons Testing component, there is code in 
the repo but no site yet. This was discussed a couple of months ago on the ML.

> Stopwatch based capability for nested, named, timings in a call stack
> -
>
> Key: LANG-1373
> URL: https://issues.apache.org/jira/browse/LANG-1373
> Project: Commons Lang
>  Issue Type: New Feature
>  Components: lang.time.*
>Reporter: Otto Fowler
>Assignee: Otto Fowler
>Priority: Major
>  Labels: commons-lang,
> Attachments: LANG-1373.patch
>
>
> While working on adding some timing functionality to a Metron feature, I came 
> across the
> Stopwatch class, but found that it didn’t suite my needs.
> What I wanted to do was to create a timing from a top level function in our 
> Stellar dsl, and have have a group of related timings, such that the end 
> result was the overall time of the call, and nested timings of other calls 
> executed during the dsl execution of that function. These timings would all 
> be named, and have a path for identification and include timing the language 
> compiler/execution as well as the function execution itself. It would be 
> helpful if they were tagged in some way as well, such that the consumer could 
> filter during visitation.
> So I have written StackWatch to provide this functionality, and submitted it 
> in a Metron PR.
> From the PR description:
> StackWatch
> A set of utility classes under the new package stellar.common.timing have 
> been added. These provide the StackWatch functionality.
> StackWatch provides an abstraction over the Apache Commons StopWatch class 
> that allows callers to create multiple named and possibly nested timing 
> operations.
> <…>
> This class may be more generally useful to this and other projects, but I am 
> not sure where it would live since we wouldn’t want it in common.
> StackWatch uses a combination of Deque and a custom Tree implementation to 
> create, start and end timing operations.
> A Visitor pattern is also implemented to allow for retrieving the results 
> after the completion of the operation.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Commented] (VFS-654) File system events API

[Otto Fowler (JIRA)]

[ 
https://issues.apache.org/jira/browse/VFS-654?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16378933#comment-16378933
 ] 

Otto Fowler commented on VFS-654:
-

Not that I have seen, but I've only recently been paying attention.

Besides HDFS ( which is still @unstable ) what other filesystems do you have in 
mind?

> File system events API
> --
>
> Key: VFS-654
> URL: https://issues.apache.org/jira/browse/VFS-654
> Project: Commons VFS
>  Issue Type: New Feature
>Affects Versions: 2.2
>Reporter: Boris Petrov
>Priority: Major
>
> Currently the DefaultFileMonitor walks the whole file system and notifies 
> when something changes. For large file systems and (near) real-time 
> requirements this is _extremely_ inefficient. Some file systems have an 
> events API which could be exposed (like *inotify*). Has any work towards that 
> ever been done?



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Created] (VFS-654) File system events API

[Boris Petrov (JIRA)]

Boris Petrov created VFS-654:


 Summary: File system events API
 Key: VFS-654
 URL: https://issues.apache.org/jira/browse/VFS-654
 Project: Commons VFS
  Issue Type: New Feature
Affects Versions: 2.2
Reporter: Boris Petrov


Currently the DefaultFileMonitor walks the whole file system and notifies when 
something changes. For large file systems and (near) real-time requirements 
this is _extremely_ inefficient. Some file systems have an events API which 
could be exposed (like *inotify*). Has any work towards that ever been done?



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Commented] (LANG-1373) Stopwatch based capability for nested, named, timings in a call stack

[Gilles (JIRA)]

[ 
https://issues.apache.org/jira/browse/LANG-1373?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16378768#comment-16378768
 ] 

Gilles commented on LANG-1373:
--

bq. Thoughts from anyone else?

+1 to anything that contributes to making more focused (and modular) components.

But "Commons Time" seems too vague (as your remark on overlap alludes too) and 
"Commons Perf" unnecessary (?) when JMH exists already.
A module in "Commons Testing" (where a refactored {{StopWatch}} should probably 
be transferred too)?


> Stopwatch based capability for nested, named, timings in a call stack
> -
>
> Key: LANG-1373
> URL: https://issues.apache.org/jira/browse/LANG-1373
> Project: Commons Lang
>  Issue Type: New Feature
>  Components: lang.time.*
>Reporter: Otto Fowler
>Assignee: Otto Fowler
>Priority: Major
>  Labels: commons-lang,
> Attachments: LANG-1373.patch
>
>
> While working on adding some timing functionality to a Metron feature, I came 
> across the
> Stopwatch class, but found that it didn’t suite my needs.
> What I wanted to do was to create a timing from a top level function in our 
> Stellar dsl, and have have a group of related timings, such that the end 
> result was the overall time of the call, and nested timings of other calls 
> executed during the dsl execution of that function. These timings would all 
> be named, and have a path for identification and include timing the language 
> compiler/execution as well as the function execution itself. It would be 
> helpful if they were tagged in some way as well, such that the consumer could 
> filter during visitation.
> So I have written StackWatch to provide this functionality, and submitted it 
> in a Metron PR.
> From the PR description:
> StackWatch
> A set of utility classes under the new package stellar.common.timing have 
> been added. These provide the StackWatch functionality.
> StackWatch provides an abstraction over the Apache Commons StopWatch class 
> that allows callers to create multiple named and possibly nested timing 
> operations.
> <…>
> This class may be more generally useful to this and other projects, but I am 
> not sure where it would live since we wouldn’t want it in common.
> StackWatch uses a combination of Deque and a custom Tree implementation to 
> create, start and end timing operations.
> A Visitor pattern is also implemented to allow for retrieving the results 
> after the completion of the operation.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Commented] (LANG-1373) Stopwatch based capability for nested, named, timings in a call stack

[ASF GitHub Bot (JIRA)]

[ 
https://issues.apache.org/jira/browse/LANG-1373?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16378747#comment-16378747
 ] 

ASF GitHub Bot commented on LANG-1373:
--

Github user garydgregory commented on the issue:

https://github.com/apache/commons-lang/pull/311
  
When I see code like
```
watch.visit(new StackWatch.TimingVisitor() {
@Override
public void visitTiming(int level, List path, 
StackWatch.Timing node) {
assertTrue(node.getStopWatch().getNanoTime() > 
stopWatch.getNanoTime());
}
});
```
I have my doubts as to this belonging in Commons Lang and not a new module 
like a Commons Time (but nothing with Joda-Time or java.time overlap) or 
Commons Perf.
This feels very 'framework-y' to me and beyond the otherwise simple Commons 
Lang APIs.

Thoughts from anyone else?


> Stopwatch based capability for nested, named, timings in a call stack
> -
>
> Key: LANG-1373
> URL: https://issues.apache.org/jira/browse/LANG-1373
> Project: Commons Lang
>  Issue Type: New Feature
>  Components: lang.time.*
>Reporter: Otto Fowler
>Assignee: Otto Fowler
>Priority: Major
>  Labels: commons-lang,
> Attachments: LANG-1373.patch
>
>
> While working on adding some timing functionality to a Metron feature, I came 
> across the
> Stopwatch class, but found that it didn’t suite my needs.
> What I wanted to do was to create a timing from a top level function in our 
> Stellar dsl, and have have a group of related timings, such that the end 
> result was the overall time of the call, and nested timings of other calls 
> executed during the dsl execution of that function. These timings would all 
> be named, and have a path for identification and include timing the language 
> compiler/execution as well as the function execution itself. It would be 
> helpful if they were tagged in some way as well, such that the consumer could 
> filter during visitation.
> So I have written StackWatch to provide this functionality, and submitted it 
> in a Metron PR.
> From the PR description:
> StackWatch
> A set of utility classes under the new package stellar.common.timing have 
> been added. These provide the StackWatch functionality.
> StackWatch provides an abstraction over the Apache Commons StopWatch class 
> that allows callers to create multiple named and possibly nested timing 
> operations.
> <…>
> This class may be more generally useful to this and other projects, but I am 
> not sure where it would live since we wouldn’t want it in common.
> StackWatch uses a combination of Deque and a custom Tree implementation to 
> create, start and end timing operations.
> A Visitor pattern is also implemented to allow for retrieving the results 
> after the completion of the operation.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[GitHub] commons-lang issue #311: LANG-1373 Stopwatch based capability for nested, na...

[garydgregory]

Github user garydgregory commented on the issue:

https://github.com/apache/commons-lang/pull/311
  
When I see code like
```
watch.visit(new StackWatch.TimingVisitor() {
@Override
public void visitTiming(int level, List path, 
StackWatch.Timing node) {
assertTrue(node.getStopWatch().getNanoTime() > 
stopWatch.getNanoTime());
}
});
```
I have my doubts as to this belonging in Commons Lang and not a new module 
like a Commons Time (but nothing with Joda-Time or java.time overlap) or 
Commons Perf.
This feels very 'framework-y' to me and beyond the otherwise simple Commons 
Lang APIs.

Thoughts from anyone else?


---

[jira] [Commented] (LANG-1373) Stopwatch based capability for nested, named, timings in a call stack

[ASF GitHub Bot (JIRA)]

[ 
https://issues.apache.org/jira/browse/LANG-1373?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16378689#comment-16378689
 ] 

ASF GitHub Bot commented on LANG-1373:
--

Github user ottobackwards commented on the issue:

https://github.com/apache/commons-lang/pull/311
  
@garydgregory @kinow I added the static method.  I did not squash/rebase 
though. I will if you need me to but I want the review.


> Stopwatch based capability for nested, named, timings in a call stack
> -
>
> Key: LANG-1373
> URL: https://issues.apache.org/jira/browse/LANG-1373
> Project: Commons Lang
>  Issue Type: New Feature
>  Components: lang.time.*
>Reporter: Otto Fowler
>Assignee: Otto Fowler
>Priority: Major
>  Labels: commons-lang,
> Attachments: LANG-1373.patch
>
>
> While working on adding some timing functionality to a Metron feature, I came 
> across the
> Stopwatch class, but found that it didn’t suite my needs.
> What I wanted to do was to create a timing from a top level function in our 
> Stellar dsl, and have have a group of related timings, such that the end 
> result was the overall time of the call, and nested timings of other calls 
> executed during the dsl execution of that function. These timings would all 
> be named, and have a path for identification and include timing the language 
> compiler/execution as well as the function execution itself. It would be 
> helpful if they were tagged in some way as well, such that the consumer could 
> filter during visitation.
> So I have written StackWatch to provide this functionality, and submitted it 
> in a Metron PR.
> From the PR description:
> StackWatch
> A set of utility classes under the new package stellar.common.timing have 
> been added. These provide the StackWatch functionality.
> StackWatch provides an abstraction over the Apache Commons StopWatch class 
> that allows callers to create multiple named and possibly nested timing 
> operations.
> <…>
> This class may be more generally useful to this and other projects, but I am 
> not sure where it would live since we wouldn’t want it in common.
> StackWatch uses a combination of Deque and a custom Tree implementation to 
> create, start and end timing operations.
> A Visitor pattern is also implemented to allow for retrieving the results 
> after the completion of the operation.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[GitHub] commons-lang issue #311: LANG-1373 Stopwatch based capability for nested, na...

[ottobackwards]

Github user ottobackwards commented on the issue:

https://github.com/apache/commons-lang/pull/311
  
@garydgregory @kinow I added the static method.  I did not squash/rebase 
though. I will if you need me to but I want the review.


---

[jira] [Commented] (LANG-1373) Stopwatch based capability for nested, named, timings in a call stack

[ASF GitHub Bot (JIRA)]

[ 
https://issues.apache.org/jira/browse/LANG-1373?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16378624#comment-16378624
 ] 

ASF GitHub Bot commented on LANG-1373:
--

Github user ottobackwards commented on the issue:

https://github.com/apache/commons-lang/pull/311
  
same with the static factory:

```java
 @Test
public void testTryWithResourcesStaticFactory() {
final StopWatch stopWatch = new StopWatch();

try(StackWatch watch = 
StackWatch.startStackWatch("testStackWatch")) {
stopWatch.start();
stopWatch.stop();
}
watch.visit(new StackWatch.TimingVisitor() {
@Override
public void visitTiming(int level, List path, 
StackWatch.Timing node) {
assertTrue(node.getStopWatch().getNanoTime() > 
stopWatch.getNanoTime());
}
});
}
```


> Stopwatch based capability for nested, named, timings in a call stack
> -
>
> Key: LANG-1373
> URL: https://issues.apache.org/jira/browse/LANG-1373
> Project: Commons Lang
>  Issue Type: New Feature
>  Components: lang.time.*
>Reporter: Otto Fowler
>Assignee: Otto Fowler
>Priority: Major
>  Labels: commons-lang,
> Attachments: LANG-1373.patch
>
>
> While working on adding some timing functionality to a Metron feature, I came 
> across the
> Stopwatch class, but found that it didn’t suite my needs.
> What I wanted to do was to create a timing from a top level function in our 
> Stellar dsl, and have have a group of related timings, such that the end 
> result was the overall time of the call, and nested timings of other calls 
> executed during the dsl execution of that function. These timings would all 
> be named, and have a path for identification and include timing the language 
> compiler/execution as well as the function execution itself. It would be 
> helpful if they were tagged in some way as well, such that the consumer could 
> filter during visitation.
> So I have written StackWatch to provide this functionality, and submitted it 
> in a Metron PR.
> From the PR description:
> StackWatch
> A set of utility classes under the new package stellar.common.timing have 
> been added. These provide the StackWatch functionality.
> StackWatch provides an abstraction over the Apache Commons StopWatch class 
> that allows callers to create multiple named and possibly nested timing 
> operations.
> <…>
> This class may be more generally useful to this and other projects, but I am 
> not sure where it would live since we wouldn’t want it in common.
> StackWatch uses a combination of Deque and a custom Tree implementation to 
> create, start and end timing operations.
> A Visitor pattern is also implemented to allow for retrieving the results 
> after the completion of the operation.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[GitHub] commons-lang issue #311: LANG-1373 Stopwatch based capability for nested, na...

[ottobackwards]

Github user ottobackwards commented on the issue:

https://github.com/apache/commons-lang/pull/311
  
same with the static factory:

```java
 @Test
public void testTryWithResourcesStaticFactory() {
final StopWatch stopWatch = new StopWatch();

try(StackWatch watch = 
StackWatch.startStackWatch("testStackWatch")) {
stopWatch.start();
stopWatch.stop();
}
watch.visit(new StackWatch.TimingVisitor() {
@Override
public void visitTiming(int level, List path, 
StackWatch.Timing node) {
assertTrue(node.getStopWatch().getNanoTime() > 
stopWatch.getNanoTime());
}
});
}
```


---

[jira] [Commented] (LANG-1373) Stopwatch based capability for nested, named, timings in a call stack

[ASF GitHub Bot (JIRA)]

[ 
https://issues.apache.org/jira/browse/LANG-1373?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16378622#comment-16378622
 ] 

ASF GitHub Bot commented on LANG-1373:
--

Github user ottobackwards commented on the issue:

https://github.com/apache/commons-lang/pull/311
  
the static factory, is pretty straight forward.
The try with resources, less so.  What ends up happening is you cannot stop 
the watch before visiting the nodes.

For example, this is what you want to do if you are going to time, but 
visit later:

```java
 @Test
public void testTryWithResources() {
final StopWatch stopWatch = new StopWatch();

try(StackWatch watch = new 
StackWatch<>("testStackWatch")) {
watch.start();
stopWatch.start();
stopWatch.stop();
}
watch.visit(new StackWatch.TimingVisitor() {
@Override
public void visitTiming(int level, List path, 
StackWatch.Timing node) {
assertTrue(node.getStopWatch().getNanoTime() > 
stopWatch.getNanoTime());
}
});
}
```

but it won't work/compile with try with resources




> Stopwatch based capability for nested, named, timings in a call stack
> -
>
> Key: LANG-1373
> URL: https://issues.apache.org/jira/browse/LANG-1373
> Project: Commons Lang
>  Issue Type: New Feature
>  Components: lang.time.*
>Reporter: Otto Fowler
>Assignee: Otto Fowler
>Priority: Major
>  Labels: commons-lang,
> Attachments: LANG-1373.patch
>
>
> While working on adding some timing functionality to a Metron feature, I came 
> across the
> Stopwatch class, but found that it didn’t suite my needs.
> What I wanted to do was to create a timing from a top level function in our 
> Stellar dsl, and have have a group of related timings, such that the end 
> result was the overall time of the call, and nested timings of other calls 
> executed during the dsl execution of that function. These timings would all 
> be named, and have a path for identification and include timing the language 
> compiler/execution as well as the function execution itself. It would be 
> helpful if they were tagged in some way as well, such that the consumer could 
> filter during visitation.
> So I have written StackWatch to provide this functionality, and submitted it 
> in a Metron PR.
> From the PR description:
> StackWatch
> A set of utility classes under the new package stellar.common.timing have 
> been added. These provide the StackWatch functionality.
> StackWatch provides an abstraction over the Apache Commons StopWatch class 
> that allows callers to create multiple named and possibly nested timing 
> operations.
> <…>
> This class may be more generally useful to this and other projects, but I am 
> not sure where it would live since we wouldn’t want it in common.
> StackWatch uses a combination of Deque and a custom Tree implementation to 
> create, start and end timing operations.
> A Visitor pattern is also implemented to allow for retrieving the results 
> after the completion of the operation.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[GitHub] commons-lang issue #311: LANG-1373 Stopwatch based capability for nested, na...

[ottobackwards]

Github user ottobackwards commented on the issue:

https://github.com/apache/commons-lang/pull/311
  
the static factory, is pretty straight forward.
The try with resources, less so.  What ends up happening is you cannot stop 
the watch before visiting the nodes.

For example, this is what you want to do if you are going to time, but 
visit later:

```java
 @Test
public void testTryWithResources() {
final StopWatch stopWatch = new StopWatch();

try(StackWatch watch = new 
StackWatch<>("testStackWatch")) {
watch.start();
stopWatch.start();
stopWatch.stop();
}
watch.visit(new StackWatch.TimingVisitor() {
@Override
public void visitTiming(int level, List path, 
StackWatch.Timing node) {
assertTrue(node.getStopWatch().getNanoTime() > 
stopWatch.getNanoTime());
}
});
}
```

but it won't work/compile with try with resources




---