[geometry] Subhyperplane PR Feedback
Hello. I just submitted a PR with some large API changes in the subhyperplane classes and I'd like to see if anyone has any feedback. The PR is here: https://github.com/apache/commons-geometry/pull/75. The changes are detailed in the issues GEOMETRY-92 and GEOMETRY-93 but, in short, they make improvements to the subhyperplane and line class hierarchies. For example, here is how to create a 2D ray in the previous code: Segment ray = Segment.fromPointAndDirection(p1, dir, precision); The class of the created object is "Segment", which clearly doesn't match the concept of a ray at all. Here is the new form: Ray ray = Ray.fromPointAndDirection(p1, dir, precision); The created object now has a much more correct, descriptive class name. Similar changes are made for lines in 3D. With the way the objects are now structured, I also noticed (via jmh gc profiling) a significant reduction in the memory required for subhyperplane operations in 2D and 3D. The 2D convex subhyperplanes no longer need references to 1D subspaces, considerably reducing the number of objects needed for the representation. Regards, Matt
Re: [crypto] Help Releasing new Commons Crypto
As promised, I added support for further environments to Travis - https://github.com/apache/commons-crypto/pull/96 On Mon, 13 Apr 2020 at 16:35, Alex Remily wrote: > > I don't know whether it would help the build manager with the release > process, but I think it would be a good idea to update the build matrix > regardless. I made an attempt a while ago to add coverage for more > environments, but ultimately I wasn't successful. I don't recall if the > limitations were Travis's or my own, but I would certainly welcome someone > fleshing out the build matrix to test against OpenSSL 1.0 and 1.1 APIs in > whatever Windows, Mac, Linux and Arm64 environments Travis supports. My > $0.02. > > Alex > > On Mon, Apr 13, 2020 at 2:53 AM Adam Retter > wrote: > > > Travis now offer Arm64 and Mac. I could setup a job to build binaries on > > Travis and keep a copy either on every commit or when a tag is created. > > Would that be helpful? > > > > On Mon, 13 Apr 2020, 03:13 Gary Gregory, wrote: > > > > > On Sun, Apr 12, 2020 at 8:57 PM Alex Remily > > wrote: > > > > > > > I can do the 64 bit builds on Mac, Linux and Windows, so I'm happy to > > > > provide whichever of those is required. It seems that Geoff can do the > > > > arm64 build. Do we even bother supporting 32 bit architectures at this > > > > point? > > > > > > > > > > Unfortunately, we cannot just pick up bits from folks here and there. It > > > all has to be buildable from Maven by the release manager in order to > > > generate the file signatures properly. > > > > > > Based on what I see in the docs, it looks like this is buildable using > > > cross-compilation with MinGW on Windows. Not sure about the Mac stuff > > yet. > > > > > > I'm not sure what the use-case is for 32-bit at this point. > > > > > > Gary > > > > > > > > > > On Sun, Apr 12, 2020 at 7:36 PM Marcelo Vanzin > > > wrote: > > > > > > > > > Hi Gary, > > > > > > > > > > On Sun, Apr 12, 2020 at 8:53 AM Gary Gregory > > > > > > > wrote: > > > > > > > The 1.0 release on maven central only included linux32 and > > linux64 > > > > > native > > > > > > > libs, even though the Makefile supports many more targets > > > > > > > > > > > > > > > > > > > Please see the snapshot builds which now include more: > > > > > > > > > > > > > > > > > > > > https://repository.apache.org/content/repositories/snapshots/org/apache/commons/commons-crypto/1.1.0-SNAPSHOT > > > > > > > > > > Here's the native stuff in your snapshot jar: > > > > > > > > > > $ jar tf commons-crypto-1.1.0-20200411.124009-5.jar | grep > > > > > nativeorg/apache/commons/crypto/native/ > > > > > org/apache/commons/crypto/native/Linux/ > > > > > org/apache/commons/crypto/native/Linux/x86_64/ > > > > > org/apache/commons/crypto/native/Linux/x86_64/libcommons-crypto.so > > > > > > > > > > Here's the 1.0 release: > > > > > > > > > > $ jar tf > > > > > > > > > > > > > > ~/.ivy2/cache/org.apache.commons/commons-crypto/jars/commons-crypto-1.0.0.jar > > > > > | grep native > > > > > org/apache/commons/crypto/native/ > > > > > org/apache/commons/crypto/native/Linux/ > > > > > org/apache/commons/crypto/native/Linux/x86/ > > > > > org/apache/commons/crypto/native/Linux/x86_64/ > > > > > org/apache/commons/crypto/native/Mac/ > > > > > org/apache/commons/crypto/native/Mac/x86_64/ > > > > > org/apache/commons/crypto/native/Windows/ > > > > > org/apache/commons/crypto/native/Windows/x86/ > > > > > org/apache/commons/crypto/native/Windows/x86_64/ > > > > > org/apache/commons/crypto/native/Linux/x86/libcommons-crypto.so > > > > > org/apache/commons/crypto/native/Linux/x86_64/libcommons-crypto.so > > > > > org/apache/commons/crypto/native/Mac/x86_64/libcommons-crypto.jnilib > > > > > org/apache/commons/crypto/native/Windows/x86/commons-crypto.dll > > > > > org/apache/commons/crypto/native/Windows/x86_64/commons-crypto.dll > > > > > > > > > > That's the only thing that worries me: finding someone who can build > > > > > all those extra native libraries. I tend to agree that linux64 is the > > > > > most important one, but it would be technically a regression from 1.0 > > > > > to skip the others. > > > > > > > > > > That being said, if we can't solve that, I think it's better to > > > > > release something rather than nothing. > > > > > > > > > > - > > > > > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org > > > > > For additional commands, e-mail: dev-h...@commons.apache.org > > > > > > > > > > > > > > > > > > > -- Adam Retter skype: adam.retter tweet: adamretter http://www.adamretter.org.uk - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [crypto] Help Releasing new Commons Crypto
Thanks Adam. Very much appreciated. How much effort would it be to do the same for OpenSSL 1.1.x? On Sat, Apr 18, 2020 at 11:41 AM Adam Retter wrote: > As promised, I added support for further environments to Travis - > https://github.com/apache/commons-crypto/pull/96 > > On Mon, 13 Apr 2020 at 16:35, Alex Remily wrote: > > > > I don't know whether it would help the build manager with the release > > process, but I think it would be a good idea to update the build matrix > > regardless. I made an attempt a while ago to add coverage for more > > environments, but ultimately I wasn't successful. I don't recall if the > > limitations were Travis's or my own, but I would certainly welcome > someone > > fleshing out the build matrix to test against OpenSSL 1.0 and 1.1 APIs in > > whatever Windows, Mac, Linux and Arm64 environments Travis supports. My > > $0.02. > > > > Alex > > > > On Mon, Apr 13, 2020 at 2:53 AM Adam Retter > > wrote: > > > > > Travis now offer Arm64 and Mac. I could setup a job to build binaries > on > > > Travis and keep a copy either on every commit or when a tag is created. > > > Would that be helpful? > > > > > > On Mon, 13 Apr 2020, 03:13 Gary Gregory, > wrote: > > > > > > > On Sun, Apr 12, 2020 at 8:57 PM Alex Remily > > > wrote: > > > > > > > > > I can do the 64 bit builds on Mac, Linux and Windows, so I'm happy > to > > > > > provide whichever of those is required. It seems that Geoff can > do the > > > > > arm64 build. Do we even bother supporting 32 bit architectures at > this > > > > > point? > > > > > > > > > > > > > Unfortunately, we cannot just pick up bits from folks here and > there. It > > > > all has to be buildable from Maven by the release manager in order to > > > > generate the file signatures properly. > > > > > > > > Based on what I see in the docs, it looks like this is buildable > using > > > > cross-compilation with MinGW on Windows. Not sure about the Mac stuff > > > yet. > > > > > > > > I'm not sure what the use-case is for 32-bit at this point. > > > > > > > > Gary > > > > > > > > > > > > > On Sun, Apr 12, 2020 at 7:36 PM Marcelo Vanzin > > > > wrote: > > > > > > > > > > > Hi Gary, > > > > > > > > > > > > On Sun, Apr 12, 2020 at 8:53 AM Gary Gregory < > garydgreg...@gmail.com > > > > > > > > > > wrote: > > > > > > > > The 1.0 release on maven central only included linux32 and > > > linux64 > > > > > > native > > > > > > > > libs, even though the Makefile supports many more targets > > > > > > > > > > > > > > > > > > > > > > Please see the snapshot builds which now include more: > > > > > > > > > > > > > > > > > > > > > > > > > > https://repository.apache.org/content/repositories/snapshots/org/apache/commons/commons-crypto/1.1.0-SNAPSHOT > > > > > > > > > > > > Here's the native stuff in your snapshot jar: > > > > > > > > > > > > $ jar tf commons-crypto-1.1.0-20200411.124009-5.jar | grep > > > > > > nativeorg/apache/commons/crypto/native/ > > > > > > org/apache/commons/crypto/native/Linux/ > > > > > > org/apache/commons/crypto/native/Linux/x86_64/ > > > > > > > org/apache/commons/crypto/native/Linux/x86_64/libcommons-crypto.so > > > > > > > > > > > > Here's the 1.0 release: > > > > > > > > > > > > $ jar tf > > > > > > > > > > > > > > > > > > > ~/.ivy2/cache/org.apache.commons/commons-crypto/jars/commons-crypto-1.0.0.jar > > > > > > | grep native > > > > > > org/apache/commons/crypto/native/ > > > > > > org/apache/commons/crypto/native/Linux/ > > > > > > org/apache/commons/crypto/native/Linux/x86/ > > > > > > org/apache/commons/crypto/native/Linux/x86_64/ > > > > > > org/apache/commons/crypto/native/Mac/ > > > > > > org/apache/commons/crypto/native/Mac/x86_64/ > > > > > > org/apache/commons/crypto/native/Windows/ > > > > > > org/apache/commons/crypto/native/Windows/x86/ > > > > > > org/apache/commons/crypto/native/Windows/x86_64/ > > > > > > org/apache/commons/crypto/native/Linux/x86/libcommons-crypto.so > > > > > > > org/apache/commons/crypto/native/Linux/x86_64/libcommons-crypto.so > > > > > > > org/apache/commons/crypto/native/Mac/x86_64/libcommons-crypto.jnilib > > > > > > org/apache/commons/crypto/native/Windows/x86/commons-crypto.dll > > > > > > > org/apache/commons/crypto/native/Windows/x86_64/commons-crypto.dll > > > > > > > > > > > > That's the only thing that worries me: finding someone who can > build > > > > > > all those extra native libraries. I tend to agree that linux64 > is the > > > > > > most important one, but it would be technically a regression > from 1.0 > > > > > > to skip the others. > > > > > > > > > > > > That being said, if we can't solve that, I think it's better to > > > > > > release something rather than nothing. > > > > > > > > > > > > > - > > > > > > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org > > > > > > For additional commands, e-mail: dev-h...@commons.apache.org > > > > > > > > > > > > > > > > > > > > > > > > > > > > -- > Adam Rette
