Re: commons-filter sandbox is operational

Hi Eric, there hasn't been any documentation except of javadoc on it. I've added a page in the APT format. msv site requires documentation. Not sure what's required here. Best, /Bernd On 02/11/16 09:09, Eric Barnhill wrote: Hi Bernd, looks like I need

[ALL] Git repository for a sandbox component? (Was: commons-filter sandbox is operational)

Hello. I noticed that the "Text" component uses "git". It would be simpler to also use git for the "filter" component. Regards, Gilles - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands,

Applicability of PolyhedronsSet for high polygon counts

I've been using the commons math geometry libraries for some simple 2d intersection functions, but I'm now interested in expanding it's use to include some manipulation of 3d models with polygon counts that will easily reach 200,000 tris. More specifically I would like to build physical

Re: [Math] Re: LU decomposition very SLOW (commons.math3.linear)

Makes all sense. I will prepare a "minimally invasive" patch that exactly mimics the original behavior. In a possible future version, I think interfaces should be used from the beginning, even if there is only a small chance that different implementations arise. It is hard/impossible to resolve

Re: [Math] Re: LU decomposition very SLOW (commons.math3.linear)

On Fri, 4 Nov 2016 03:16:29 -0700 (PDT), wilbur wrote: Makes all sense. I will prepare a "minimally invasive" patch that exactly mimics the original behavior. In a possible future version, I think interfaces should be used from the beginning, even if there is only a small chance that

Re: [Math] Re: LU decomposition very SLOW (commons.math3.linear)

I second that, recalling some very rough API transitions/incompatibilities in the past (e.g., around 'LeastSquaresOptimizer')... --Wilhelm -- View this message in context:

Re: [compress] Added in-memory support for zip and 7z

On 2016-11-01, M N wrote: >> read never indicates EOF as it stands, I think we should return -1 >> rather than 0 when position equals size. WDYT? > Yes, indeed the contract specifies to return -1 in this case so we > should change this. will do. >>> In resize() method there is also a danger to

[digester] MultiVariableExpander Using upper bounded wildcards

Hello, Apologies if this has already been discussed. I searched the mailing lists and issue tracker but couldn't find any references. I'm using MultiVariableExpander, and the compilation of my code, which was working with 1.8.1, starting failing with digester 2.0 (it also fails with digester3):

Fwd: commons-compress git commit: avoid overflow when resizing

Isn't this worthy of a JIRA and note in changes.xml? Gary -- Forwarded message -- From: Date: Fri, Nov 4, 2016 at 8:50 AM Subject: commons-compress git commit: avoid overflow when resizing To: comm...@commons.apache.org Repository: commons-compress Updated

Re: Fwd: commons-compress git commit: avoid overflow when resizing

On 2016-11-04, Gary Gregory wrote: >> Repository: commons-compress >> Updated Branches: >> refs/heads/master 46f57bf93 -> f538f38bd > >> avoid overflow when resizing > Isn't this worthy of a JIRA and note in changes.xml? the change is to a class completely new in 1.13. Stefan