Re: [compress] 2.0: require Java7?
On Sun, Jan 26, 2014 at 8:13 AM, Stefan Bodewig bode...@apache.org wrote: On 2014-01-25, Damjan Jovanovic wrote: On Fri, Jan 24, 2014 at 6:06 PM, Stefan Bodewig bode...@apache.org wrote: On 2013-12-30, Stefan Bodewig wrote: Compress 1.x is at Java5, personally I don't think Java6 would give us any benefits. I don't know about the other improvements in NIO2 but the java.nio.file package looks useful for compress. In the meantime it has been pointed out to me that Android doesn't support NIO2. I can imagine Android apps using Compress so this looks like a good reason to hold back requiring Java7. It's already possible to use most Java 7 language level features and compile to Android (https://github.com/yareally/Java7-on-Android). It would also possible to reimplement the needed classes (which is only SeekableByteChannel?) in nio2 using some kind of wrapper on top of Android's java.nio. It would also be a part java.nio.file.attribute, but we can re-invent that as well, if needed. What you suggest could work as long as we are careful and never assume FileChannel implements SeekableByteChannel but use some custom File = SeekableByteChannel code using Java7 if available - I'm just afraid we'll forget to be careful. Or, during compilation to Android, java.nio.channels.FileChannel could get renamed to wrapper.FileChannel, which will implement wrapper.SeekableByteChannel, so there's no problem. We could still use Java 7 / nio2 and then make a plan for Android releases. Thanks for volunteering ;-) Heh :). Stefan Damjan - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
[LANG] Towards 3.3
Hi all, we've fixed some bugs and we have some nice new features implemented (DiffBuilder, Jaro-Winkler Distance, RandomUtils, ClassPathUtils), so I'm planning to cut a RC in the first week of February. I just wanted to know if there is anything you'd like to have included in the next release. Then please tag it with fix version 3.3. Regards, Benedikt -- http://people.apache.org/~britter/ http://www.systemoutprintln.de/ http://twitter.com/BenediktRitter http://github.com/britter
Re: [LANG] Towards 3.3
On 26 January 2014 13:33, Benedikt Ritter brit...@apache.org wrote: Hi all, we've fixed some bugs and we have some nice new features implemented (DiffBuilder, Jaro-Winkler Distance, RandomUtils, ClassPathUtils), so I'm planning to cut a RC in the first week of February. I just wanted to know if there is anything you'd like to have included in the next release. Then please tag it with fix version 3.3. Regards, Benedikt I'm debating whether LANG-341 might be a candidate for inclusion. The patch is fairly complete, just needs Javadocs and a couple of additional unit tests, which I can sort over the coming week. What do you guys think? It seems like a useful addition to me. Duncan - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [LANG] Towards 3.3
Hi Duncan, 2014/1/26 Duncan Jones dun...@wortharead.com On 26 January 2014 13:33, Benedikt Ritter brit...@apache.org wrote: Hi all, we've fixed some bugs and we have some nice new features implemented (DiffBuilder, Jaro-Winkler Distance, RandomUtils, ClassPathUtils), so I'm planning to cut a RC in the first week of February. I just wanted to know if there is anything you'd like to have included in the next release. Then please tag it with fix version 3.3. Regards, Benedikt I'm debating whether LANG-341 might be a candidate for inclusion. The patch is fairly complete, just needs Javadocs and a couple of additional unit tests, which I can sort over the coming week. What do you guys think? It seems like a useful addition to me. Yes looks neat. The problem I'm seeing is, that the last activity is from Nov 2011, and the contributor has no ICLA listed (see [1]), so IP is not absolutely clear. I'm unsure if we can use this contribution without the ICLA. Anyway, Hen has contributed the patch Vincent Ricard used, so we can use Hen's patch and improve it. Benedikt [1] http://people.apache.org/committer-index.html#unlistedclas Duncan - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org -- http://people.apache.org/~britter/ http://www.systemoutprintln.de/ http://twitter.com/BenediktRitter http://github.com/britter
Re: [LANG] Towards 3.3
On 26 January 2014 18:49, Benedikt Ritter brit...@apache.org wrote: Hi Duncan, 2014/1/26 Duncan Jones dun...@wortharead.com On 26 January 2014 13:33, Benedikt Ritter brit...@apache.org wrote: Hi all, we've fixed some bugs and we have some nice new features implemented (DiffBuilder, Jaro-Winkler Distance, RandomUtils, ClassPathUtils), so I'm planning to cut a RC in the first week of February. I just wanted to know if there is anything you'd like to have included in the next release. Then please tag it with fix version 3.3. Regards, Benedikt I'm debating whether LANG-341 might be a candidate for inclusion. The patch is fairly complete, just needs Javadocs and a couple of additional unit tests, which I can sort over the coming week. What do you guys think? It seems like a useful addition to me. Yes looks neat. The problem I'm seeing is, that the last activity is from Nov 2011, and the contributor has no ICLA listed (see [1]), so IP is not absolutely clear. I'm unsure if we can use this contribution without the ICLA. Anyway, Hen has contributed the patch Vincent Ricard used, so we can use Hen's patch and improve it. Benedikt [1] http://people.apache.org/committer-index.html#unlistedclas Good point. I think in this case I'll ping the contributor to get their thoughts on an ICLA and assume this will miss v3.3. He's done a lot of work to extend Hen's patch and it would be a shame for that not to get committed if he's interested. If there's no reply (or no interest), I'll sort something for v3.4. Duncan Duncan - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org -- http://people.apache.org/~britter/ http://www.systemoutprintln.de/ http://twitter.com/BenediktRitter http://github.com/britter - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [LANG] Towards 3.3
Adding more features and fixes is Ok but at this point I'd rather regular early and release often. G Original message From: Duncan Jones dun...@wortharead.com Date:01/26/2014 11:45 (GMT-05:00) To: Commons Developers List dev@commons.apache.org Subject: Re: [LANG] Towards 3.3 On 26 January 2014 13:33, Benedikt Ritter brit...@apache.org wrote: Hi all, we've fixed some bugs and we have some nice new features implemented (DiffBuilder, Jaro-Winkler Distance, RandomUtils, ClassPathUtils), so I'm planning to cut a RC in the first week of February. I just wanted to know if there is anything you'd like to have included in the next release. Then please tag it with fix version 3.3. Regards, Benedikt I'm debating whether LANG-341 might be a candidate for inclusion. The patch is fairly complete, just needs Javadocs and a couple of additional unit tests, which I can sort over the coming week. What do you guys think? It seems like a useful addition to me. Duncan - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [LANG] Towards 3.3
On 26 January 2014 19:47, Duncan Jones dun...@wortharead.com wrote: On 26 January 2014 18:49, Benedikt Ritter brit...@apache.org wrote: Hi Duncan, 2014/1/26 Duncan Jones dun...@wortharead.com On 26 January 2014 13:33, Benedikt Ritter brit...@apache.org wrote: Hi all, we've fixed some bugs and we have some nice new features implemented (DiffBuilder, Jaro-Winkler Distance, RandomUtils, ClassPathUtils), so I'm planning to cut a RC in the first week of February. I just wanted to know if there is anything you'd like to have included in the next release. Then please tag it with fix version 3.3. Regards, Benedikt I'm debating whether LANG-341 might be a candidate for inclusion. The patch is fairly complete, just needs Javadocs and a couple of additional unit tests, which I can sort over the coming week. What do you guys think? It seems like a useful addition to me. Yes looks neat. The problem I'm seeing is, that the last activity is from Nov 2011, and the contributor has no ICLA listed (see [1]), so IP is not absolutely clear. I'm unsure if we can use this contribution without the ICLA. Anyway, Hen has contributed the patch Vincent Ricard used, so we can use Hen's patch and improve it. Benedikt [1] http://people.apache.org/committer-index.html#unlistedclas Good point. I think in this case I'll ping the contributor to get their thoughts on an ICLA and assume this will miss v3.3. He's done a lot of work to extend Hen's patch and it would be a shame for that not to get committed if he's interested. If there's no reply (or no interest), I'll sort something for v3.4. Having said that... does this still represent a problem if the contributor has patched existing code (containing the Apache license)? Are there any situations where we can take a patch and apply it to trunk without the contributor having an ICLA? I certainly had patches applied in the past without an ICLA, but perhaps things were more lax then? Duncan - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org -- http://people.apache.org/~britter/ http://www.systemoutprintln.de/ http://twitter.com/BenediktRitter http://github.com/britter - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
[math][MATH-749] Convex hull
Hi, finally, I have a patch ready to be included for MATH-749. What took me so long was some confusion about the type system in the geometry package. It is actually quite difficult to do some generic algorithm code by only specifying the relevant space type (e.g. Euclidean2D). The Vector/Point interface does not allow access to its components, thus any algorithm that needs access to them either has to cast, or explicitly specify the type. I decided now to come up with the following: There is a generic interface for convex hull generators: public interface ConvexHullGeneratorS extends Space, V extends VectorS and currently one concrete implementation for the euclidean 2d space: public class GrahamScan2DV extends Vector2D implements ConvexHullGeneratorEuclidean2D, V The reason GrahamScan2D still has a generic type parameter is because I wanted to cover also the use-case of people extending Vector2D, although I am not sure if this is realistic/useful. We may also change this to: public class GrahamScan2Dimplements ConvexHullGeneratorEuclidean2D, Vector2D Ideally, the Vector interface would have a method double getComponent(int dimension) or double[] getData() to provide access to the components of the vector and I would like to discuss this for 4.0 considering the other uses of Vector. Anyway, I would be grateful if somebody could review the patch. If the general interface is accepted, I plan to add more implementations. Thanks, Thomas - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [math][MATH-749] Convex hull
[...] The Vector/Point interface does not allow access to its components, thus any algorithm that needs access to them either has to cast, or explicitly specify the type. [...] Ideally, the Vector interface would have a method double getComponent(int dimension) or double[] getData() to provide access to the components of the vector and I would like to discuss this for 4.0 considering the other uses of Vector. [...] How would an algorithm know how to deal with the returned value if it does not know the actual type (i.e. the meaning of the components)? Gilles - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [LANG] Towards 3.3
Depends whose arguing probably :) Our license gives us a right to contributions under Apache 2.0 unless stated otherwise; the ICLA is playing safer. We can also simply take anything under a compatible license and include (with suitable licensing). I did that for a method from Spring. Hen On Sun, Jan 26, 2014 at 1:31 PM, Duncan Jones dun...@wortharead.com wrote: On 26 January 2014 19:47, Duncan Jones dun...@wortharead.com wrote: On 26 January 2014 18:49, Benedikt Ritter brit...@apache.org wrote: Hi Duncan, 2014/1/26 Duncan Jones dun...@wortharead.com On 26 January 2014 13:33, Benedikt Ritter brit...@apache.org wrote: Hi all, we've fixed some bugs and we have some nice new features implemented (DiffBuilder, Jaro-Winkler Distance, RandomUtils, ClassPathUtils), so I'm planning to cut a RC in the first week of February. I just wanted to know if there is anything you'd like to have included in the next release. Then please tag it with fix version 3.3. Regards, Benedikt I'm debating whether LANG-341 might be a candidate for inclusion. The patch is fairly complete, just needs Javadocs and a couple of additional unit tests, which I can sort over the coming week. What do you guys think? It seems like a useful addition to me. Yes looks neat. The problem I'm seeing is, that the last activity is from Nov 2011, and the contributor has no ICLA listed (see [1]), so IP is not absolutely clear. I'm unsure if we can use this contribution without the ICLA. Anyway, Hen has contributed the patch Vincent Ricard used, so we can use Hen's patch and improve it. Benedikt [1] http://people.apache.org/committer-index.html#unlistedclas Good point. I think in this case I'll ping the contributor to get their thoughts on an ICLA and assume this will miss v3.3. He's done a lot of work to extend Hen's patch and it would be a shame for that not to get committed if he's interested. If there's no reply (or no interest), I'll sort something for v3.4. Having said that... does this still represent a problem if the contributor has patched existing code (containing the Apache license)? Are there any situations where we can take a patch and apply it to trunk without the contributor having an ICLA? I certainly had patches applied in the past without an ICLA, but perhaps things were more lax then? Duncan - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org -- http://people.apache.org/~britter/ http://www.systemoutprintln.de/ http://twitter.com/BenediktRitter http://github.com/britter - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
