[CODEC] CRLF files in macOS checkout

2019-06-17 Thread sebb 
Most of the files in my clone of codec have LF endings, however a few are CRLF:

./README.md
./src/assembly/bin.xml
./src/assembly/src.xml
./src/changes/changes.xml
./src/main/java/org/apache/commons/codec/cli/Digest.java
./src/main/java/org/apache/commons/codec/language/DaitchMokotoffSoundex.java
./src/main/resources/org/apache/commons/codec/language/bm/lang.txt
./src/test/java/org/apache/commons/codec/digest/HmacAlgorithmsTest.java
./src/test/java/org/apache/commons/codec/digest/MessageDigestAlgorithmsTest.java
./src/test/java/org/apache/commons/codec/digest/PureJavaCrc32Test.java
./src/test/java/org/apache/commons/codec/language/ColognePhoneticTest.java


This causes spurious differences when the files are updated.

Can these files be easily fixed without causing huge diffs to be generated?

Also, is there any way to prevent such files being committed to the repo?

S.

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

Re: [commons-codec] branch master updated: CODEC-254 - ColognePhonetic does not treat the letter H correct

2019-06-17 Thread sebb AT ASF 
On Mon, 17 Jun 2019 at 17:59,  wrote:
>
> This is an automated email from the ASF dual-hosted git repository.
>
> sebb pushed a commit to branch master
> in repository https://gitbox.apache.org/repos/asf/commons-codec.git
>
>
> The following commit(s) were added to refs/heads/master by this push:
>  new 4f8662a  CODEC-254 - ColognePhonetic does not treat the letter H 
> correct
> 4f8662a is described below
>
> commit 4f8662a758688b845d741a932e28cc8d4fc11b96
> Author: Sebb 
> AuthorDate: Mon Jun 17 17:59:00 2019 +0100
>
> CODEC-254 - ColognePhonetic does not treat the letter H correct
> ---
>  src/changes/changes.xml| 973 
> +++--
>  .../commons/codec/language/ColognePhonetic.java|  11 +-
>  .../codec/language/ColognePhoneticTest.java| 505 +--
>  3 files changed, 747 insertions(+), 742 deletions(-)
>
> diff --git a/src/changes/changes.xml b/src/changes/changes.xml
> index 2714c5d..fcdbd5b 100644
> --- a/src/changes/changes.xml
> +++ b/src/changes/changes.xml
> @@ -1,486 +1,487 @@
> -
>

[bcel] LRU Cache for ClassPathRepository

2019-06-17 Thread Tomo Suzuki 
Hi Gary and BCEL maintainers,

My OutOfMemoryError problem that motivated BCEL-317
 ticket has been resolved
by a custom ClassPathRepository and I'm thinking to contribute this
solution to BCEL library:

BCEL-320  A new
ClassPathRepository that can scan many JAR files without OutOfMemoryError


Test cases to reproduce OutOfMemoryError:
https://github.com/suztomo/bcel-oome-example

What do you think?

Regards,
Tomo

On Wed, May 22, 2019 at 11:23 AM Tomo Suzuki  wrote:

> Hi Gary and BCEL maintainers,
>
> I've added Javadoc for the enhancement.
> https://github.com/apache/commons-bcel/pull/26
> I appreciate if you can check the direction of the implementation is good
> or bad.
>
> Regards,
> Tomo
>
>
> On Sun, May 19, 2019 at 11:40 PM Tomo Suzuki  wrote:
>
>> Hi Gary (and BCEL maintainers),
>>
>> Thank you for the comment. It has been addressed. Would you check the
>> pull request?
>> https://github.com/apache/commons-bcel/pull/26/files
>>
>> Regards,
>> Tomo
>>
>> On Wed, May 8, 2019 at 17:46 Tomo Suzuki  wrote:
>>
>>> Hi Gary,
>>> Created a draft PR to receive feedback.
>>> https://github.com/apache/commons-bcel/pull/26/files . What do you
>>> think?
>>>
>>> Regards,
>>> Tomo
>>>
>>> From: Gary Gregory 
>>> Date: Wed, May 8, 2019 at 9:40 AM
>>> To: Commons Developers List
>>>
>>> > Great. I look forward to seeing what you'll come up with :-)
>>> >
>>> > On Tue, May 7, 2019 at 4:27 PM Tomo Suzuki >> >
>>> > wrote:
>>> >
>>> > > I found the discussion on getInstance method had incurred performance
>>> > > degradation https://issues.apache.org/jira/browse/BCEL-186 .
>>> > >
>>> > > From the JIRA:
>>> > > > This feature could return as a pluggable cache if someone wants to
>>> > > provide a patch
>>> > >
>>> > > I'll think about the approach.
>>> > >
>>> > > Regards,
>>> > > Tomo
>>> > >
>>> > >
>>> > > On Thu, May 2, 2019 at 1:22 PM Gary Gregory 
>>> > > wrote:
>>> > >
>>> > > > On Thu, May 2, 2019 at 10:59 AM Tomo Suzuki
>>> 
>>> > > > wrote:
>>> > > >
>>> > > > > Gary,
>>> > > > > I didn't find ConstantUtf8.getCachedInstance
>>> > > > > <
>>> > > >
>>> > >
>>> https://github.com/apache/commons-bcel/blob/master/src/main/java/org/apache/bcel/classfile/ConstantUtf8.java#L94
>>> > > > >
>>> > > > > is used in BCEL (latest 6.3.1). I tried my custom ConstantUtf8
>>> > > > modification
>>> > > > > to leverage getCachedInstance method and it worked well:
>>> > > > >
>>> > > > > Before
>>> > > > >
>>> > > > > Without getCachedInstance, my tool created 2,6 million
>>> ConstantUtf8
>>> > > > > instances (before failing OutOfMemoryError: GC overhead limit
>>> exceeded)
>>> > > > to
>>> > > > > check ~200 jar files
>>> > > > > [image: 2644k_constantutf8_without_getCachedInstance.png]
>>> > > > >
>>> > > > >
>>> > > > > After
>>> > > > >
>>> > > > > With getCachedInstance, my tool created just 0.6 million
>>> ConstantUtf8
>>> > > > > instances. It didn't throw the OutOfMemoryError.
>>> > > > > [image: 621k_constantutf8_with_getCachedInstance.png]
>>> > > > >
>>> > > > > My modification was to use getCachedInstance for
>>> > > > > ConstantUtf8.getInstance(DataInput)
>>> > > > > <
>>> > > >
>>> > >
>>> https://github.com/apache/commons-bcel/blob/master/src/main/java/org/apache/bcel/classfile/ConstantUtf8.java#L123
>>> > > > >
>>> > > > > .
>>> > > > >
>>> > > > >
>>> > > > > Do you know why ConstantUtf8.getCachedInstance is unused?
>>> > > > >
>>> > > >
>>> > > > I do not.
>>> > > >
>>> > > > Gary
>>> > > >
>>> > > >
>>> > > > >
>>> > > > > Regards,
>>> > > > > Tomo
>>> > > > >
>>> > > > >
>>> > > > >
>>> > > > > On Wed, May 1, 2019 at 7:02 PM Gary Gregory <
>>> garydgreg...@gmail.com>
>>> > > > > wrote:
>>> > > > >
>>> > > > >> On Wed, May 1, 2019 at 6:37 PM Tomo Suzuki
>>> >> > > >
>>> > > > >> wrote:
>>> > > > >>
>>> > > > >> > Gary,
>>> > > > >> > That’s right. I missed it. I think I just need to find a way
>>> to
>>> > > > leverage
>>> > > > >> > the getCachedInstance method. Thank you for quick response.
>>> > > > >> >
>>> > > > >>
>>> > > > >> YW. Please let us know your outcome.
>>> > > > >>
>>> > > > >> Gary
>>> > > > >>
>>> > > > >>
>>> > > > >> >
>>> > > > >> > On Wed, May 1, 2019 at 18:00 Gary Gregory <
>>> garydgreg...@gmail.com>
>>> > > > >> wrote:
>>> > > > >> >
>>> > > > >> > > Why not use getCachedInstance() ?
>>> > > > >> > >
>>> > > > >> > > Gary
>>> > > > >> > >
>>> > > > >> > > On Wed, May 1, 2019 at 5:20 PM Tomo Suzuki
>>> > > > >> > > > >> >
>>> > > > >> > > wrote:
>>> > > > >> > >
>>> > > > >> > > > Hi BCEL developers,
>>> > > > >> > > >
>>> > > > >> > > > We use BCEL library to inspect Java class. Thank you for
>>> the
>>> > > great
>>> > > > >> > > library.
>>> > > > >> > > >
>>> > > > >> > > > When our tool checks classes in ~200 jar files, it
>>> creates more
>>> > > > >> than 2
>>> > > > >> > > > million BCEL ConstantUtf8 instances. I suspect many of
>>> them
>>> > > share
>>> > > > >> the
>>> > > >

Re: [VOTE] Release Apache Commons Daemon 1.1.1

2019-06-17 Thread Mark Thomas 
On 17/06/2019 15:58, Gary Gregory wrote:
> The version in the release notes at the top still says "1.1" instead of
> "1.1.1".

My understanding was they referred to 1.1.x (i.e. all of the 1.1
releases) so the version number was appropriate.

> It seems to me that 1.2 would be more appropriate since we upgraded both
> the Java and OS requirements.

No we didn't. See the changelog. The Java and OS requirements are the
same for 1.1.1 as they are for 1.1.0.

Mark


> 
> Gary
> 
> On Mon, Jun 17, 2019, 08:13 Mark Thomas  wrote:
> 
>> It has been ~18 months since the last Commons Daemon release. After the
>> recent flurry of activity, I think we are ready for a release.
>>
>> Notable changes include:
>> - Improved JRE/JDK detection to support increased range of both JVM
>>   versions and vendors.
>> - Procrun. Change the default service from LocalSystem to
>>   'NT Authority\LocalService'
>>
>> The full set of changes is in the changelog
>>
>> 1.1.1 can be obtained from (r34537):
>> https://dist.apache.org/repos/dist/dev/commons/daemon/
>>
>> The git tag is:
>> https://github.com/apache/commons-daemon/commits/COMMONS_DAEMON_1_1_1
>> 4319f482e1ff6ea7655e1377120750fd6ecc3810
>> 
>>
>> The Maven Staging repo is:
>> https://repository.apache.org/content/repositories/orgapachecommons-1441/
>>
>> The Windows binaries have been signed by the Symantec code signing service.
>>
>>
>>
>> [ ] Approved - go ahead and release Commons Daemon 1.1.1
>> [ ] Broken   - do not release because...
>>
>> -
>> 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: [VOTE] Release Apache Commons Daemon 1.1.1

2019-06-17 Thread Gary Gregory 
The version in the release notes at the top still says "1.1" instead of
"1.1.1".

It seems to me that 1.2 would be more appropriate since we upgraded both
the Java and OS requirements.

Gary

On Mon, Jun 17, 2019, 08:13 Mark Thomas  wrote:

> It has been ~18 months since the last Commons Daemon release. After the
> recent flurry of activity, I think we are ready for a release.
>
> Notable changes include:
> - Improved JRE/JDK detection to support increased range of both JVM
>   versions and vendors.
> - Procrun. Change the default service from LocalSystem to
>   'NT Authority\LocalService'
>
> The full set of changes is in the changelog
>
> 1.1.1 can be obtained from (r34537):
> https://dist.apache.org/repos/dist/dev/commons/daemon/
>
> The git tag is:
> https://github.com/apache/commons-daemon/commits/COMMONS_DAEMON_1_1_1
> 4319f482e1ff6ea7655e1377120750fd6ecc3810
> 
>
> The Maven Staging repo is:
> https://repository.apache.org/content/repositories/orgapachecommons-1441/
>
> The Windows binaries have been signed by the Symantec code signing service.
>
>
>
> [ ] Approved - go ahead and release Commons Daemon 1.1.1
> [ ] Broken   - do not release because...
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
> For additional commands, e-mail: dev-h...@commons.apache.org
>
>

[GSoC][Commons][STATISTICS][Regression][Matrix] Flexibility in Matrix Libraries in Regression Component?

2019-06-17 Thread Ben Nguyen 
Hello,

If I recall/assume correctly, there is currently no concrete plan to create a 
new matrix library any time soon; leading me to use the EJML as suggested by 
Mr. Eric Barnhill. This seems to be temporary until the CM matrix component is 
upgraded, or perhaps it’s permanent? I don’t believe the plan is or that the 
use of EJML should be permanent…. 
So should I design the regression component (which heavily uses matrices and 
vectors) to use a matrix interfaces to allow for simpler reformatting later…. 
or even as a means of allowing the user to use any matrix library they want for 
computing regressions? 
This also aligns with what Mr. Alex Herbert told me about decoupling in regards 
to the input data and builder/loader functionality: 
https://issues.apache.org/jira/browse/STATISTICS-11

Thank you for your response,
Cheers,
-Ben

Re: [VOTE] Release Apache Commons Daemon 1.1.1

2019-06-17 Thread Gary Gregory 
I am also getting a 404 for the link
https://github.com/apache/commons-daemon/commits/COMMONS_DAEMON_1_1_14319f482e1ff6ea7655e1377120750fd6ecc3810
which
might be a cut and paste issue or the way Gmail renders this URL.

Gary

On Mon, Jun 17, 2019 at 8:45 AM Gary Gregory  wrote:

> This email is missing a few elements based on our release procedures at
> https://commons.apache.org/releases/prepare.html
>
> - Hashes to files on dist/dev
> - Link to site
> - Link to KEYS file
> - Link to apache.org instead of github.com for the tag
>
> Gary
>
> On Mon, Jun 17, 2019 at 8:13 AM Mark Thomas  wrote:
>
>> It has been ~18 months since the last Commons Daemon release. After the
>> recent flurry of activity, I think we are ready for a release.
>>
>> Notable changes include:
>> - Improved JRE/JDK detection to support increased range of both JVM
>>   versions and vendors.
>> - Procrun. Change the default service from LocalSystem to
>>   'NT Authority\LocalService'
>>
>> The full set of changes is in the changelog
>>
>> 1.1.1 can be obtained from (r34537):
>> https://dist.apache.org/repos/dist/dev/commons/daemon/
>>
>> The git tag is:
>> https://github.com/apache/commons-daemon/commits/COMMONS_DAEMON_1_1_1
>> 4319f482e1ff6ea7655e1377120750fd6ecc3810
>> 
>>
>> The Maven Staging repo is:
>> https://repository.apache.org/content/repositories/orgapachecommons-1441/
>>
>> The Windows binaries have been signed by the Symantec code signing
>> service.
>>
>>
>>
>> [ ] Approved - go ahead and release Commons Daemon 1.1.1
>> [ ] Broken   - do not release because...
>>
>> -
>> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
>> For additional commands, e-mail: dev-h...@commons.apache.org
>>
>>

Re: [VOTE] Release Apache Commons Daemon 1.1.1

2019-06-17 Thread Gary Gregory 
This email is missing a few elements based on our release procedures at
https://commons.apache.org/releases/prepare.html

- Hashes to files on dist/dev
- Link to site
- Link to KEYS file
- Link to apache.org instead of github.com for the tag

Gary

On Mon, Jun 17, 2019 at 8:13 AM Mark Thomas  wrote:

> It has been ~18 months since the last Commons Daemon release. After the
> recent flurry of activity, I think we are ready for a release.
>
> Notable changes include:
> - Improved JRE/JDK detection to support increased range of both JVM
>   versions and vendors.
> - Procrun. Change the default service from LocalSystem to
>   'NT Authority\LocalService'
>
> The full set of changes is in the changelog
>
> 1.1.1 can be obtained from (r34537):
> https://dist.apache.org/repos/dist/dev/commons/daemon/
>
> The git tag is:
> https://github.com/apache/commons-daemon/commits/COMMONS_DAEMON_1_1_1
> 4319f482e1ff6ea7655e1377120750fd6ecc3810
> 
>
> The Maven Staging repo is:
> https://repository.apache.org/content/repositories/orgapachecommons-1441/
>
> The Windows binaries have been signed by the Symantec code signing service.
>
>
>
> [ ] Approved - go ahead and release Commons Daemon 1.1.1
> [ ] Broken   - do not release because...
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
> For additional commands, e-mail: dev-h...@commons.apache.org
>
>

[VOTE] Release Apache Commons Daemon 1.1.1

2019-06-17 Thread Mark Thomas 
It has been ~18 months since the last Commons Daemon release. After the
recent flurry of activity, I think we are ready for a release.

Notable changes include:
- Improved JRE/JDK detection to support increased range of both JVM
  versions and vendors.
- Procrun. Change the default service from LocalSystem to
  'NT Authority\LocalService'

The full set of changes is in the changelog

1.1.1 can be obtained from (r34537):
https://dist.apache.org/repos/dist/dev/commons/daemon/

The git tag is:
https://github.com/apache/commons-daemon/commits/COMMONS_DAEMON_1_1_1
4319f482e1ff6ea7655e1377120750fd6ecc3810

The Maven Staging repo is:
https://repository.apache.org/content/repositories/orgapachecommons-1441/

The Windows binaries have been signed by the Symantec code signing service.



[ ] Approved - go ahead and release Commons Daemon 1.1.1
[ ] Broken   - do not release because...

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