Re: Fwd: commons-compress git commit: COMPRESS-271 xxhash32 checksum

On 2017-01-24, Gary Gregory wrote: > Once [compress] has its next release, what about copying XXHash32 to > [codec]? That seems to me like the proper home for such things. That's why I started the other thread ;-) Stefan - To

Re: Best Home for Checksum Implementations?

On 2017-01-24, Emmanuel Bourg wrote: > Le 24/01/2017 à 10:08, Stefan Bodewig a écrit : >> I was wondering whether these implementations would belong in one of the >> other components (as well as - rather than instead of - compress) but >> I'm not sure where it would fit. > What about a

Re: Best Home for Checksum Implementations?

On 2017-01-24, Gary Gregory wrote: > Commons Codec already has: > org.apache.commons.codec.digest.PureJavaCrc32 > org.apache.commons.codec.digest.PureJavaCrc32C > This is in SVN slated for 1.11. Oh, didn't see that as I only looked at the released javadocs. PureJavaCrc32C likely has the same

Re: Best Home for Checksum Implementations?

On 2017-01-24, Javen O'Neal wrote: > [Crypto] is another possible home since hashing and crypto are commonly > used together, The checksums we have in [compress] are not cryptographically strong, adding them to [crypto] would send the wrong signal IMHO. Stefan

Re: [text] shade plugin into beta package

> On Jan 24, 2017, at 3:56 PM, Gary Gregory wrote: > > I'm not a fan of shading within commons. > > In most projects I work on, I end up depending on a ton of stuff and it > seems silly to create duplication within Commons itself. > > Am I ever going to write a

Re: Best Home for Checksum Implementations?

For me, a new component called [checksum] is too small and a subset of the more general [codec]. YMMV, Gary On Tue, Jan 24, 2017 at 1:03 PM, Javen O'Neal wrote: > [Crypto] is another possible home since hashing and crypto are commonly > used together, but a standalone

Fwd: commons-compress git commit: COMPRESS-271 xxhash32 checksum

Once [compress] has its next release, what about copying XXHash32 to [codec]? That seems to me like the proper home for such things. Gary -- Forwarded message -- From: Date: Tue, Jan 24, 2017 at 11:53 AM Subject: commons-compress git commit: COMPRESS-271

Re: Best Home for Checksum Implementations?

[Crypto] is another possible home since hashing and crypto are commonly used together, but a standalone component may be easier for other projects to use with regard to technology export control and easier for [Checksum] to grow without revving a more mature library like [Crypto]. On Jan 24, 2017

Fwd: [text] shade plugin into beta package

I'm not a fan of shading within commons. In most projects I work on, I end up depending on a ton of stuff and it seems silly to create duplication within Commons itself. Am I ever going to write a program that depends solely on [text]? I doubt it. And if I did and it depended on [lang3]

Re: Best Home for Checksum Implementations?

These two implement java.util.zip.Checksum BTW. Gary On Tue, Jan 24, 2017 at 12:25 PM, Gary Gregory wrote: > Commons Codec already has: > > org.apache.commons.codec.digest.PureJavaCrc32 > org.apache.commons.codec.digest.PureJavaCrc32C > > This is in SVN slated for 1.11.

Re: Best Home for Checksum Implementations?

Commons Codec already has: org.apache.commons.codec.digest.PureJavaCrc32 org.apache.commons.codec.digest.PureJavaCrc32C This is in SVN slated for 1.11. Gary On Tue, Jan 24, 2017 at 1:08 AM, Stefan Bodewig wrote: > Hi > > inside of [compress] we've already got an

Re: Best Home for Checksum Implementations?

> Am 24.01.2017 um 11:35 schrieb Emmanuel Bourg : > > Le 24/01/2017 à 10:08, Stefan Bodewig a écrit : > >> I was wondering whether these implementations would belong in one of the >> other components (as well as - rather than instead of - compress) but >> I'm not sure where

Re: Best Home for Checksum Implementations?

Le 24/01/2017 à 10:08, Stefan Bodewig a écrit : > I was wondering whether these implementations would belong in one of the > other components (as well as - rather than instead of - compress) but > I'm not sure where it would fit. What about a dedicated component for checksum implementations? It

Re: Best Home for Checksum Implementations?

On 2017-01-24, Stefan Bodewig wrote: > On 2017-01-24, Torsten Curdt wrote: Maybe create a "checksum" package in codec? >>> Alternatively, we could start a new component called Commons Checksum… >> Depends on how many implementations we can gather I guess. > Compress will have two by the

Re: Best Home for Checksum Implementations?

Le 24/01/2017 à 11:19, Torsten Curdt a écrit : > Depends on how many implementations we can gather I guess. CRC32C, xxhash32, potentially a few more useful CRCs [1]. I also have a Checksum implementation that skips some positions in the input data [2] (used for skipping the part of the file that

Re: Best Home for Checksum Implementations?

On 2017-01-24, Torsten Curdt wrote: >>> Maybe create a "checksum" package in codec? >> Alternatively, we could start a new component called Commons Checksum… > Depends on how many implementations we can gather I guess. Compress will have two by the end of this week. Cassandra likely has a

Re: Best Home for Checksum Implementations?

I think Validator has some checksum code. On 24 January 2017 at 10:19, Torsten Curdt wrote: >> >> > Maybe create a "checksum" package in codec? >> >> Alternatively, we could start a new component called Commons Checksum… >> > > Depends on how many implementations we can gather

Re: Best Home for Checksum Implementations?

> > > Maybe create a "checksum" package in codec? > > Alternatively, we could start a new component called Commons Checksum… > Depends on how many implementations we can gather I guess.

Re: Best Home for Checksum Implementations?

Hi, > Am 24.01.2017 um 10:48 schrieb Torsten Curdt : > > On Tue, Jan 24, 2017 at 10:08 AM, Stefan Bodewig > wrote: > >> Hi >> >> inside of [compress] we've already got an implementation of CRC32C (used >> by Snappy, "borrowed"

Re: Best Home for Checksum Implementations?

On Tue, Jan 24, 2017 at 10:08 AM, Stefan Bodewig wrote: > Hi > > inside of [compress] we've already got an implementation of CRC32C (used > by Snappy, "borrowed" from Hadoop) and will soonish have xxhash32 (used > by LZ4). > > I was wondering whether these implementations

[GitHub] commons-rdf issue #30: COMMONSRDF-51 language tags compared lower case

Github user afs commented on the issue: https://github.com/apache/commons-rdf/pull/30 You mean you tried to Graph.delete a triple? That deletes exact triples (.equals). Graph.remove deletes triples that match (same value) by using "find" that has the value-matching

Best Home for Checksum Implementations?

Hi inside of [compress] we've already got an implementation of CRC32C (used by Snappy, "borrowed" from Hadoop) and will soonish have xxhash32 (used by LZ4). I was wondering whether these implementations would belong in one of the other components (as well as - rather than instead of - compress)