Re: [dbutils] 2_0 branch discussion

Gary, I appreciate the sentiment of not wanting to make a major change, but if you look at the commit history and the emails from 2013 you'll realize this last commit is actually fairly small. The only reason this wasn't done in 2013 was that the release process didn't seem to want to work for me,

Re: [dbutils] 2_0 branch discussion

I think we should look at the current code base we have in master and work in new features and bug fixes one PR at a time. Trying some big bang port from some now 'foreign' code base is likely to not get reviewed if it comes in one giant PR. Gary On Mon, Dec 30, 2019 at 5:17 PM Carl Hall wrote:

Re: [commons-codec] branch master updated: [CODEC-276] Reliance on default encoding in MurmurHash2 and MurmurHash3.

On Mon, Dec 30, 2019 at 4:26 PM Alex Herbert wrote: > > > > On 30 Dec 2019, at 14:58, Gary Gregory wrote: > > > > On Mon, Dec 30, 2019 at 9:38 AM Alex Herbert > > > wrote: > > > >> On Mon, 30 Dec 2019, 14:19 Gary Gregory, > wrote: > >> > >>> On Mon, Dec 30, 201

[VOTE] Release Apache Commons Codec 1.14 based on RC1

We have fixed quite a few bugs and added some significant enhancements since Apache Commons Codec 1.13 was released, so I would like to release Apache Commons Codec 1.14. Apache Commons Codec 1.14 RC1 is available for review here: https://dist.apache.org/repos/dist/dev/commons/codec/1.14-RC1 (

Re: [dbutils] 2_0 branch discussion

I just merged the code from my fork ( https://github.com/wspeirs/sop4j-dbutils/) into the commons-dbutils 2_0 branch ( https://gitbox.apache.org/repos/asf?p=commons-dbutils.git;a=commit;h=180c0990b1f0da4d0039904b68cc6b57f00558e5 ). The code builds, and all the tests pass... that's as far as I went

Re: [commons-codec] branch master updated: [CODEC-276] Reliance on default encoding in MurmurHash2 and MurmurHash3.

> On 30 Dec 2019, at 21:26, Alex Herbert wrote: > > > >> On 30 Dec 2019, at 14:58, Gary Gregory > > wrote: >> >> On Mon, Dec 30, 2019 at 9:38 AM Alex Herbert > > >> wrote: >> >>> On Mon, 30 Dec 2019, 14:19 Gary Gregory, >>

[dbutils] 2_0 branch discussion

There was a 2_0 branch started several years ago[1]. That release was abandoned, the code wasn’t merged into master, and a fork was spurred outside of Apache[2]. I’d like to rectify this and work to a release. The code was moved to a different package in both repos, so merging isn’t straightfor

[Lang] release soon

Check your PRs and Jiras... :-) I would like to release 3.10 soonish. Gary

Re: Proposal to Release

Just don't delete any tags... Gary On Mon, Dec 30, 2019 at 9:37 AM William Speirs wrote: > That 2.0 release attempt was mine... Feel free to blow it away, and proceed > with your release as 2.0. > > However, most of my changes in there should be working. The changes add > named parameter suppor

Re: Proposal to Release

Thanks for reminding me of that, Bill. I have a local branch where I’ve rebased 2_0 onto master, and reworked things where needed. I’ll review that again to see where things stand. It was a lot of work last time, so I’ll plan to go forward without it for now, and try to get a 2.0 release out aft

Re: Proposal to Release

Solid point, Gary, and it removes the collision with 2.0. win-win. :) I’ll revert that change, and proceed with a 1.8 version for release consideration. > On Dec 30, 2019, at 6:44 AM, Gary Gregory wrote: > > If the only breaking change is a change to field access level, let's revert > that kee

Re: [commons-codec] branch master updated: [CODEC-276] Reliance on default encoding in MurmurHash2 and MurmurHash3.

> On 30 Dec 2019, at 14:58, Gary Gregory wrote: > > On Mon, Dec 30, 2019 at 9:38 AM Alex Herbert > > wrote: > >> On Mon, 30 Dec 2019, 14:19 Gary Gregory, wrote: >> >>> On Mon, Dec 30, 2019 at 9:10 AM Alex Herbert >>> wrote: >>> On my second review I f

Re: [commons-codec] branch master updated: [CODEC-276] Reliance on default encoding in MurmurHash2 and MurmurHash3.

On Mon, Dec 30, 2019 at 9:38 AM Alex Herbert wrote: > On Mon, 30 Dec 2019, 14:19 Gary Gregory, wrote: > > > On Mon, Dec 30, 2019 at 9:10 AM Alex Herbert > > wrote: > > > > > On my second review I fixed the potential overflow in the incremental > > hash > > > for murmur3. > > > > > > I did note

Re: Proposal to Release

If the only breaking change is a change to field access level, let's revert that keep binary compatibility IMO. Gary On Mon, Dec 30, 2019 at 1:43 AM Carl Hall wrote: > Hi all, > > It’s been another couple of years since DbUtils had a release[1], and some > good changes are ready to ship. Since

Re: [commons-codec] branch master updated: [CODEC-276] Reliance on default encoding in MurmurHash2 and MurmurHash3.

On Mon, 30 Dec 2019, 14:19 Gary Gregory, wrote: > On Mon, Dec 30, 2019 at 9:10 AM Alex Herbert > wrote: > > > On my second review I fixed the potential overflow in the incremental > hash > > for murmur3. > > > I did note that fix flying by in a commit but I would have loved to see it > accompani

Re: Proposal to Release

That 2.0 release attempt was mine... Feel free to blow it away, and proceed with your release as 2.0. However, most of my changes in there should be working. The changes add named parameter support, and a fluent API to the library. The only reason it wasn't released was because I couldn't figure o

Re: [numbers] Complex missing some C++ standards

On Mon, 30 Dec 2019, 02:23 Gilles Sadowski, wrote: > Hi. > > Le dim. 29 déc. 2019 à 23:25, Alex Herbert a > écrit : > > > > I’ve dropped the static equals methods and reciprocal and pushed the > updated class with MathJax. > > > > I put MathJax in whenever possible. This may be a bit too much. T

Re: [commons-codec] branch master updated: [CODEC-276] Reliance on default encoding in MurmurHash2 and MurmurHash3.

On Mon, Dec 30, 2019 at 9:10 AM Alex Herbert wrote: > On my second review I fixed the potential overflow in the incremental hash > for murmur3. I did note that fix flying by in a commit but I would have loved to see it accompanied by a // comment. Since I am not sure that fix came with a test,

Re: [commons-codec] branch master updated: [CODEC-276] Reliance on default encoding in MurmurHash2 and MurmurHash3.

On my second review I fixed the potential overflow in the incremental hash for murmur3. Maybe this type of code is present elsewhere in codec for other incremental algorithms. Basically you have to guard against someone incrementally adding max length arrays which will overflow a small count of unp

Re: [commons-codec] branch master updated: [CODEC-276] Reliance on default encoding in MurmurHash2 and MurmurHash3.

On Sun, Dec 29, 2019 at 5:46 PM Alex Herbert wrote: > OK. > > If you are going to make the behaviour change for the string methods then > the javadoc should be updated. It currently states: > > "The string is converted to bytes using the default encoding.” > > So perhaps switch this to: > > “Befo

Re: [Compress]Discussion about COMPRESS-499

On 2019-12-19, Peter Lee wrote: > Hi all. > A recent issue COMPRESS-499( > https://issues.apache.org/jira/projects/COMPRESS/issues/COMPRESS-499) > discussed about a potential problem in SeekableInMemoryByteChannel. > Based on the java docs( > https://docs.oracle.com/en/java/javase/11/docs/api/jav