Re: [VOTE] Release Apache Commons CSV 1.8 based on RC1

> On 21 Jan 2020, at 00:00, Gary Gregory wrote: > > On Mon, Jan 20, 2020 at 6:43 PM Rob Tompkins > wrote: > >> >> >>> On Jan 20, 2020, at 6:41 PM, Gary Gregory >> wrote: >>> >>> On Mon, Jan 20, 2020 at 6:28 PM Gary Gregory >> wrote: >>> > On Sun, Jan 19,

Re: [VOTE] Release Apache Commons CSV 1.8 based on RC1

On Mon, Jan 20, 2020 at 6:43 PM Rob Tompkins wrote: > > > > On Jan 20, 2020, at 6:41 PM, Gary Gregory > wrote: > > > > On Mon, Jan 20, 2020 at 6:28 PM Gary Gregory > wrote: > > > >>> On Sun, Jan 19, 2020 at 7:39 AM Alex Herbert > > >>> wrote: > >>> > >>> Hi Gary, > >>> > >>> I raised a few

Re: [codec] Base32/Base64 trailing bit validation is incomplete

> On 20 Jan 2020, at 23:54, Gary Gregory wrote: > > On Mon, Jan 20, 2020 at 6:45 PM Alex Herbert > > wrote: > >> >> >>> On 20 Jan 2020, at 23:20, Gary Gregory wrote: >>> >>> I hope this would be at the level of BaseNCodec, not just Base64. >>> >>> I am

Re: [VOTE] Release Apache Commons CSV 1.8 based on RC1

> On 20 Jan 2020, at 23:28, Gary Gregory wrote: > > On Sun, Jan 19, 2020 at 7:39 AM Alex Herbert > > wrote: > >> Hi Gary, >> >> I raised a few niggles a while back with CSV and the discussion did not >> receive a response on how to proceed. >> >> There is

Re: [codec] Base32/Base64 trailing bit validation is incomplete

On Mon, Jan 20, 2020 at 6:45 PM Alex Herbert wrote: > > > > On 20 Jan 2020, at 23:20, Gary Gregory wrote: > > > > I hope this would be at the level of BaseNCodec, not just Base64. > > > > I am not sure I like BaseNCodec#setAllowTrailingBits(boolean), maybe > > someone more general like

Re: [VOTE] Release Apache Commons CSV 1.8 based on RC1

On Sun, Jan 19, 2020 at 7:39 AM Alex Herbert wrote: > Hi Gary, > > I raised a few niggles a while back with CSV and the discussion did not > receive a response on how to proceed. > > There is the major bug CSV-248 where the CSVRecord is not Serializable > [1]. This requires a decision on what to

Re: [codec] Base32/Base64 trailing bit validation is incomplete

> On 20 Jan 2020, at 23:20, Gary Gregory wrote: > > I hope this would be at the level of BaseNCodec, not just Base64. > > I am not sure I like BaseNCodec#setAllowTrailingBits(boolean), maybe > someone more general like BaseNCodec.setStrictDecoding(boolean) where the > default is false for

Re: [VOTE] Release Apache Commons CSV 1.8 based on RC1

> On Jan 20, 2020, at 6:41 PM, Gary Gregory wrote: > > On Mon, Jan 20, 2020 at 6:28 PM Gary Gregory wrote: > >>> On Sun, Jan 19, 2020 at 7:39 AM Alex Herbert >>> wrote: >>> >>> Hi Gary, >>> >>> I raised a few niggles a while back with CSV and the discussion did not >>> receive a

Re: [VOTE] Release Apache Commons CSV 1.8 based on RC1

On Mon, Jan 20, 2020 at 6:28 PM Gary Gregory wrote: > On Sun, Jan 19, 2020 at 7:39 AM Alex Herbert > wrote: > >> Hi Gary, >> >> I raised a few niggles a while back with CSV and the discussion did not >> receive a response on how to proceed. >> >> There is the major bug CSV-248 where the

Re: [VOTE] Release Apache Commons CSV 1.8 based on RC1

On Sun, Jan 19, 2020 at 7:39 AM Alex Herbert wrote: > Hi Gary, > > I raised a few niggles a while back with CSV and the discussion did not > receive a response on how to proceed. > > There is the major bug CSV-248 where the CSVRecord is not Serializable > [1]. This requires a decision on what to

Re: [codec] Base32/Base64 trailing bit validation is incomplete

I hope this would be at the level of BaseNCodec, not just Base64. I am not sure I like BaseNCodec#setAllowTrailingBits(boolean), maybe someone more general like BaseNCodec.setStrictDecoding(boolean) where the default is false for backward compatibility. I do not think we want to go as far as

Re: [VOTE] Release Apache Commons CSV 1.8 based on RC1

On Sun, Jan 19, 2020 at 7:55 PM sebb wrote: > What is the use case for needing serialisation? > It's a lot of effort to maintain a serialisable class, and it opens > the class to deserialisation attacks. > I think the larger context is whether we can effectively remove (or leave broken)

Re: [geometry] Rename Transform to AffineTransform

Gilles, > I was not indicating that the name "EuclideanTransform" would be > better than "AffineTransform", I was wondering about whether the > class itself is redundant. Oh, I misunderstood. The "EuclideanTransform" interface is important because it adds the "applyVector(Vector)" method, which

Re: [geometry] Rename Transform to AffineTransform

Hello. Le lun. 20 janv. 2020 à 16:57, Matt Juntunen a écrit : > > Gilles, > > > From a design POV, I still think that "AffineTransform" is redundant: > > The "AffineTransform" name change has been reverted. It is now the original > "EuclideanTransform". I was not indicating that the name

Re: [geometry] Rename Transform to AffineTransform

Gilles, > From a design POV, I still think that "AffineTransform" is redundant: The "AffineTransform" name change has been reverted. It is now the original "EuclideanTransform". I've closed PR #58 and created PR #59 with the latest commits squashed. > IIUC, the required (not just "desired")

[codec] Base32/Base64 trailing bit validation is incomplete

In release 1.14 I fixed a patch made in 1.13 to reject decoding bytes that cannot be re-encoded to the same bytes (Codec-134 [1]). My fix was to correct the use of a mask to check the trailing bytes. The implementation checks trailing bits that are to be discarded are all zero. However the

Re: [geometry] Rename Transform to AffineTransform

Hello. 2020-01-20 14:28 UTC+01:00, Matt Juntunen : > Gilles, > >> I had a (quick) look; is it necessary to split functionality among >> "Transform" >> (in "core") and its subinterfaces/classes in other modules? IOW, if >> "Transform" >> can only be affine, it looks strange to have

Re: [geometry] Rename Transform to AffineTransform

Gilles, > I had a (quick) look; is it necessary to split functionality among "Transform" > (in "core") and its subinterfaces/classes in other modules? IOW, if > "Transform" > can only be affine, it looks strange to have "AffineTransform" (re)defined. This is a documentation issue. The name

Re: [math]New feature MiniBatchKMeansClusterer

Hi. 2020-01-20 3:08 UTC+01:00, CT : > Hi, In my picture search project, I need a cluster algorithm to narrow > the dataset, for accelerate the search on millions of pictures. > First we use python+pytorch+kmean, with the growing data from > thousands to millions, the KMeans clustering became