Re: commons-filter sandbox is operational

[Bernd Porr]

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 org/sonatype/aether/graph/DependencyFilter .

Any ideas where to find that?

Complete stack trace  below Bernd's reply.

Eric


On Tue, Nov 1, 2016 at 5:50 PM, Bernd Porr  wrote:


Thanks, Eric for setting up a sandbox project. What is required for "mvn
site"?

/Bernd


On 01/11/16 16:17, Eric Barnhill wrote:


I have set up a sandbox project for commons-filter in the commons sandbox
subversion repository.

I used models in the sandbox for LICENSE.txt, NOTICE.txt and the pom.xml,
and set up a folder tree for src . mvn install runs successfully, mvn site
does not.

The pom model I used (cli2) had jira-related tags. I do not appear to have
the authority to create a JIRA project. Should I create a JIRA for this
project? If so, am I missing this option because I have not yet linked my
Apache JIRA with my apache.org ID? And if so, can anyone tell me a way to
link them?

Thanks,
Eric



--
http://www.berndporr.me.uk
http://www.linux-usb-daq.co.uk
http://www.imdb.com/name/nm3293421/
+44 (0)7840 340069

-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org






[WARNING] Error injecting:
org.apache.maven.reporting.exec.DefaultMavenReportExecutor
java.lang.NoClassDefFoundError: org/sonatype/aether/graph/DependencyFilter
at java.lang.Class.getDeclaredConstructors0(Native Method)
at java.lang.Class.privateGetDeclaredConstructors(Class.java:2671)
at java.lang.Class.getDeclaredConstructors(Class.java:2020)
at
com.google.inject.spi.InjectionPoint.forConstructorOf(InjectionPoint.java:245)
at
com.google.inject.internal.ConstructorBindingImpl.create(ConstructorBindingImpl.java:99)
at
com.google.inject.internal.InjectorImpl.createUninitializedBinding(InjectorImpl.java:658)
at
com.google.inject.internal.InjectorImpl.createJustInTimeBinding(InjectorImpl.java:882)
at
com.google.inject.internal.InjectorImpl.createJustInTimeBindingRecursive(InjectorImpl.java:805)
at
com.google.inject.internal.InjectorImpl.getJustInTimeBinding(InjectorImpl.java:282)
at
com.google.inject.internal.InjectorImpl.getBindingOrThrow(InjectorImpl.java:214)
at
com.google.inject.internal.InjectorImpl.getProviderOrThrow(InjectorImpl.java:1006)
at
com.google.inject.internal.InjectorImpl.getProvider(InjectorImpl.java:1038)
at
com.google.inject.internal.InjectorImpl.getProvider(InjectorImpl.java:1001)
at
com.google.inject.internal.InjectorImpl.getInstance(InjectorImpl.java:1051)
at
org.eclipse.sisu.space.AbstractDeferredClass.get(AbstractDeferredClass.java:48)
at
com.google.inject.internal.ProviderInternalFactory.provision(ProviderInternalFactory.java:81)
at
com.google.inject.internal.InternalFactoryToInitializableAdapter.provision(InternalFactoryToInitializableAdapter.java:53)
at
com.google.inject.internal.ProviderInternalFactory$1.call(ProviderInternalFactory.java:65)
at
com.google.inject.internal.ProvisionListenerStackCallback$Provision.provision(ProvisionListenerStackCallback.java:115)
at
org.eclipse.sisu.bean.BeanScheduler$Activator.onProvision(BeanScheduler.java:176)
at
com.google.inject.internal.ProvisionListenerStackCallback$Provision.provision(ProvisionListenerStackCallback.java:126)
at
com.google.inject.internal.ProvisionListenerStackCallback.provision(ProvisionListenerStackCallback.java:68)
at
com.google.inject.internal.ProviderInternalFactory.circularGet(ProviderInternalFactory.java:63)
at
com.google.inject.internal.InternalFactoryToInitializableAdapter.get(InternalFactoryToInitializableAdapter.java:45)
at
com.google.inject.internal.ProviderToInternalFactoryAdapter$1.call(ProviderToInternalFactoryAdapter.java:46)
at
com.google.inject.internal.InjectorImpl.callInContext(InjectorImpl.java:1103)
at
com.google.inject.internal.ProviderToInternalFactoryAdapter.get(ProviderToInternalFactoryAdapter.java:40)
at
com.google.inject.internal.SingletonScope$1.get(SingletonScope.java:145)
at
com.google.inject.internal.InternalFactoryToProviderAdapter.get(InternalFactoryToProviderAdapter.java:41)
at
com.google.inject.internal.InjectorImpl$2$1.call(InjectorImpl.java:1016)
at
com.google.inject.internal.InjectorImpl.callInContext(InjectorImpl.java:1092)
at com.google.inject.internal.InjectorImpl$2.get(InjectorImpl.java:1012)
at org.eclipse.sisu.inject.LazyBeanEntry.getValue(LazyBeanEntry.java:81)
at
org.eclipse.sisu.plexus.LazyPlexusBean.getValue(LazyPlexusBean.java:51)
at
org.codehaus.plexus.DefaultPlexusContainer.lookup(DefaultPlexusContainer.java:263)
at

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

[Gilles]

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, e-mail: dev-h...@commons.apache.org

Applicability of PolyhedronsSet for high polygon counts

[Wes Gilster]

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 support structures in 3d models. Given that commons math geo 
libraries used BSP trees, I had assumed the performance would be quite 
adequate. However I'm having second thoughts as to whether this is the 
right API for this modeling. I'm building models from STL files with 
this constructor:
org.apache.commons.math3.geometry.euclidean.threed.PolyhedronsSet.PolyhedronsSet(List, 
List, double)


It seems there are some quite in-efficient loops in here, and with 
models with high polygon counts this function really performs poorly:
org.apache.commons.math3.geometry.euclidean.threed.PolyhedronsSet.buildBoundary(List, 
List, double)


It also seems as though this API is going to be quite intolerant of 
imperfect geometry.


Below is an example that loads an STL from disk and inserts into this 
the PolyhedronsSet:

https://github.com/WesGilster/Photonic3D/blob/master/host/src/main/java/org/area515/resinprinter/supports/ImpossiblePerformance.java

I'm hoping someone with a bit of experience in this API could confirm 
this assessment.


Thanks,
Wes G.

-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org

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

[wilbur]

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 this later.

--Wilhelm



--
View this message in context: 
http://apache-commons.680414.n4.nabble.com/Re-Math-Re-LU-decomposition-very-SLOW-commons-math3-linear-tp4692297p4692477.html
Sent from the Commons - Dev mailing list archive at Nabble.com.

-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org

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

[Gilles]

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 different
implementations arise. It is hard/impossible to resolve this later.


In CM, wherever there could have been interfaces, but there
aren't, was a conscious decision: it allowed to evolve the API
without breaking compatibility (e.g. adding methods).

This has come handy, since strangely enough, in CM the quality
of the design was somehow not considered on a par with the quality
of the implementations... [IOW, refactoring was frowned upon by
some even when it was the only reasonable solution to an issue!]

That's why, personally, I'd welcome attempts to improve on that
level, but I think that it should be done in new packages so that
it's possible to compare the respective merits of alternative
approaches.

Regards,
Gilles



--Wilhelm




-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org

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

[wilbur]

I second that, recalling some very rough API transitions/incompatibilities in
the past (e.g., around 'LeastSquaresOptimizer')...

--Wilhelm



--
View this message in context: 
http://apache-commons.680414.n4.nabble.com/Re-Math-Re-LU-decomposition-very-SLOW-commons-math3-linear-tp4692297p4692482.html
Sent from the Commons - Dev mailing list archive at Nabble.com.

-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org

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

[Stefan Bodewig]

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 overflow integer when
>>> we are close to Integer.MAX_VALUE - either sum pos + wanted or shift
>>> may cause this.

>> True. One fix would be to ensure position + wanted is cut to
>> Integer.MAX_VALUE in write (in case the sum turns negative) and in
>> resize set len to newLength if newLength > Integer.MAX_VALUE / 2.

> Allocation is an interesting topic in itself. I have looked at
> ArrayList allocation algorithm and I think they got it right.

> First there is more conservative approach to allocation growth - 1.5
> ratio instead of 2.0 as we use. Also there is an overflow handled.

> Take a look at ArrayList.grow() method. The question is how to use
> this approach not to violate any license/intellectual property?

Don't copy it. Really.

> In the meantime I have created a patch with additional constructors,
> javadocs and also simple examples for in-memory cases .

Many thanks, I've applied it.

Stefan

-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org

[digester] MultiVariableExpander Using upper bounded wildcards

[Jon Harper]

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):
incompatible types: java.util.Map cannot
be converted to java.util.Map

Since the source maps in the MultiVariableExpander are read only, it is
possible to use upper bounded wildcards ("? extends Object") to avoid
breaking existing code (and more generally support more input types). See
the following patch: http://pastebin.com/vJE69CiV

There are probably other places where this would be useful.

Has this already been examined ? Is this something you want to fix ? Is
there a problem with using upper bounded wildcards ?

Cheers,
Jon

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

[Gary Gregory]

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 Branches:
  refs/heads/master 46f57bf93 -> f538f38bd


avoid overflow when resizing


Project: http://git-wip-us.apache.org/repos/asf/commons-compress/repo
Commit: http://git-wip-us.apache.org/repos/asf/commons-compress/
commit/f538f38b
Tree: http://git-wip-us.apache.org/repos/asf/commons-compress/tree/f538f38b
Diff: http://git-wip-us.apache.org/repos/asf/commons-compress/diff/f538f38b

Branch: refs/heads/master
Commit: f538f38bd4db41349fb8f753ec17850861de5e0e
Parents: 46f57bf
Author: Stefan Bodewig 
Authored: Fri Nov 4 16:50:23 2016 +0100
Committer: Stefan Bodewig 
Committed: Fri Nov 4 16:50:23 2016 +0100

--
 .../utils/SeekableInMemoryByteChannel.java| 18 +++---
 1 file changed, 15 insertions(+), 3 deletions(-)
--


http://git-wip-us.apache.org/repos/asf/commons-compress/
blob/f538f38b/src/main/java/org/apache/commons/compress/utils/
SeekableInMemoryByteChannel.java
--
diff --git a/src/main/java/org/apache/commons/compress/utils/
SeekableInMemoryByteChannel.java b/src/main/java/org/apache/
commons/compress/utils/SeekableInMemoryByteChannel.java
index 75619b0..eece7f5 100644
--- a/src/main/java/org/apache/commons/compress/utils/
SeekableInMemoryByteChannel.java
+++ b/src/main/java/org/apache/commons/compress/utils/
SeekableInMemoryByteChannel.java
@@ -37,6 +37,8 @@ import java.util.concurrent.atomic.AtomicBoolean;
  */
 public class SeekableInMemoryByteChannel implements SeekableByteChannel {

+private static final int NAIVE_RESIZE_LIMIT = Integer.MAX_VALUE >> 1;
+
 private byte[] data;
 private final AtomicBoolean closed = new AtomicBoolean();
 private int position, size;
@@ -134,7 +136,13 @@ public class SeekableInMemoryByteChannel implements
SeekableByteChannel {
 int wanted = b.remaining();
 int possibleWithoutResize = size - position;
 if (wanted > possibleWithoutResize) {
-resize(position + wanted);
+int newSize = position + wanted;
+if (newSize < 0) { // overflow
+resize(Integer.MAX_VALUE);
+wanted = Integer.MAX_VALUE - position;
+} else {
+resize(newSize);
+}
 }
 b.get(data, position, wanted);
 position += wanted;
@@ -162,8 +170,12 @@ public class SeekableInMemoryByteChannel implements
SeekableByteChannel {
 if (len <= 0) {
 len = 1;
 }
-while (len < newLength) {
-len <<= 1;
+if (newLength < NAIVE_RESIZE_LIMIT) {
+while (len < newLength) {
+len <<= 1;
+}
+} else { // avoid overflow
+len = newLength;
 }
 data = Arrays.copyOf(data, len);
 }




-- 
E-Mail: garydgreg...@gmail.com | ggreg...@apache.org
Java Persistence with Hibernate, Second Edition



JUnit in Action, Second Edition



Spring Batch in Action


Blog: http://garygregory.wordpress.com
Home: http://garygregory.com/
Tweet! http://twitter.com/GaryGregory

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

[Stefan Bodewig]

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

-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org