Gary Gregory schrieb am Do., 2. Juni 2016 um
08:00 Uhr:
> So trunk packages would be renamed _back_ from bcel6 to the 5.2 packages?
>
That's what I understood from sebb's last message.
>
> Gary
>
> On Wed, Jun 1, 2016 at 3:43 PM, sebb wrote:
>
> > Hang on please.
> >
> > There were plans to p
So trunk packages would be renamed _back_ from bcel6 to the 5.2 packages?
Gary
On Wed, Jun 1, 2016 at 3:43 PM, sebb wrote:
> Hang on please.
>
> There were plans to produce a new incompatible release with new Maven
> coords and new package names.
> However as I recall there was some pushback fr
GitHub user zhanhb opened a pull request:
https://github.com/apache/commons-io/pull/12
Update BoundedReader.java
Bug, the return value should be -1 when get the end of the reader
https://docs.oracle.com/javase/8/docs/api/java/io/Reader.html
You can merge this pull request into a
I think we should do it all! :-)
Starting with making all of VFS a nio2 provider. Then we can do one-offs
for each file type as we go. It then should be possible to offer a more
light weight solution.
Gary
On Jun 1, 2016 5:18 PM, "Schalk Cronjé" wrote:
> I have looked at this for some time and
I would go with the first option.
sebb schrieb am Do., 2. Juni 2016 um 00:43:
> Hang on please.
>
> There were plans to produce a new incompatible release with new Maven
> coords and new package names.
> However as I recall there was some pushback from users who wished to
> have a drop-in releas
Hi Mark,
It may or may not be that heavyweight a process. It all depends on the
way it is implemented. One reason for virtual roots could be to
extract the operating system specific aspects away if possible.
However, I don't see people wanting "home" or "Photos" as urgently as
supporting common i
Hi Peter,
Implementing a new file system just to support "home" or "Photos" virtual
roots, would be a rather heavyweight approach for something that should be
configurable. Each operating system (and OS version) could have different
mappings for these roots.
Cheers,
Mark
On Wed, Jun 1, 2016 at
During the push for the last release, it seemed like some of the API
changes were breaking backward compatibility with some of the
implementations. If each implementation resides in its own repo, this would
probably be a recurrent problem, especially if the API is changing
rapidly. Has anyone given
Hi Benson,
While I don't have a strong preference in terms of the approach, my gut
feel is that the adapter approach would force people through additional
layers of VFS code.
Cheers,
Mark
On Wed, Jun 1, 2016 at 4:28 PM, Benson Margulies
wrote:
> Which direction do you have in mind here? I'd b
As long as VFS implementations can be successfully plugged in as NIO
FileSystemProvider implementations then I don't see any reason not to
add that capability in addition to the VFS APIs. Whether or not the
public VFS APIs are superceded for most users by the NIO2 APIs, with
VFS as a backend, depen
On Wed, Jun 1, 2016 at 8:18 PM, Schalk Cronjé wrote:
> I have looked at this for some time and played with some ideas. Firstly, I
> want to say that atm NIO2 sucks. It sucks because there are no decent
> provider implementations. So using the knowledge from VFS2 today, I think a
> great contributi
I have looked at this for some time and played with some ideas. Firstly,
I want to say that atm NIO2 sucks. It sucks because there are no decent
provider implementations. So using the knowledge from VFS2 today, I
think a great contribution can be made to "re-use" the VFS2 projects for
NIO2.
I
On 2 June 2016 at 00:50, Olivier Lamy wrote:
> My problem is the maven coordinate changed
That was done as part of BCEL-222.
This will have to be reverted in order to release a compatible version of BCEL.
I did not get around to doing that when I reworked the code.
> I use bcel in a maven pl
My problem is the maven coordinate changed
I use bcel in a maven plugin.
So ideally I would have been happy to simply override in the dependencies
section of the plugin with the new bcel version.
But due this non compatible change on the maven coordinate I cannot do
that
On 1 June 2016 a
Which direction do you have in mind here? I'd be up for helping to
build a device that makes commons-vfs act as an NIO2 file system
provider, but you might be aiming in the opposite direction.
On Wed, Jun 1, 2016 at 7:02 PM, Peter Ansell wrote:
> On 2 June 2016 at 01:48, Mark Fortner wrote:
>>
Why not create a release prep branch for each release when ready? The
"gitflow" treatment of master is that's what's currently "in production" or
whatever. I don't really care for that model, but it is popular. For
libraries that support multiple versions, I don't know how realistic that
is.
On We
Hello.
On Wed, 1 Jun 2016 21:53:59 +0200, Eric Barnhill wrote:
On 31/05/16 14:12, Gilles wrote:
Short as can be and close to math notation.
Another possibility may be to keep long names and to add syntactic
sugar such as
-
public static double im(Complex c) {
return c.getImaginary();
On 2 June 2016 at 01:48, Mark Fortner wrote:
> There was some discussion during the last release about a NIO-compatible
> version of VFS. This raised a few questions in my mind.
>
>1. Is there a branch where this work should start?
>2. Are there any specific API proposals, if so where are
Hang on please.
There were plans to produce a new incompatible release with new Maven
coords and new package names.
However as I recall there was some pushback from users who wished to
have a drop-in release.
That is not possible unless the release is binary compatible.
So I spent quite a bit of
Given that the 'master' branch is normally where development takes
place, this problem is going to keep recurring.
Maybe MATH should consider using 'master' as the normal development
branch and 'release' or somesuch for the release candidate.
On 29 May 2016 at 22:42, Gilles wrote:
> Hi.
>
> Tha
On Wed, Jun 1, 2016 at 12:46 PM, Oliver Heger
wrote:
>
>
> Am 31.05.2016 um 23:31 schrieb Gary Gregory:
> > While there is not much new for 1.9.3, just two fixes, I would not mind
> > pushing out a release, just to get the refreshed dependency on Commons
> > Collection out since there has been no
On 31/05/16 14:12, Gilles wrote:
Short as can be and close to math notation.
Another possibility may be to keep long names and to add syntactic
sugar such as
-
public static double im(Complex c) {
return c.getImaginary();
}
-
I have been looking at std::complex to get some idea
Am 31.05.2016 um 23:31 schrieb Gary Gregory:
> While there is not much new for 1.9.3, just two fixes, I would not mind
> pushing out a release, just to get the refreshed dependency on Commons
> Collection out since there has been noise about it related to security.
>
> Thoughts?
+1, would it be
Mark Fortner wrote:
There was some discussion during the last release about a NIO-compatible
version of VFS. This raised a few questions in my mind.
1. Is there a branch where this work should start?
This is easy enough to create one if there's desire :)
2. Are there any specific
There was some discussion during the last release about a NIO-compatible
version of VFS. This raised a few questions in my mind.
1. Is there a branch where this work should start?
2. Are there any specific API proposals, if so where are they (or will
they) be documented? Would there be
That seems reasonable based upon the other git based commons repos.
-Rob
> On May 31, 2016, at 12:08 PM, Stian Soiland-Reyes wrote:
>
> To reduce complexity and confusion, I would generally hope for
> "master" to be where development happens, rather than an additional
> "develop" - as that mea
On Wed, Jun 1, 2016 at 5:46 PM, Gilles wrote:
> On Wed, 1 Jun 2016 17:24:47 +0300, Artem Barger wrote:
>
>>
>> On Tue, May 31, 2016 at 4:04 PM, Artem Barger wrote:
>>
>> Hi,
>>>
>>> Current implementation of kmeans within CM framework, inherently uses
>>> algorithm published by Arthur, David,
On Wed, 1 Jun 2016 17:24:47 +0300, Artem Barger wrote:
On Tue, May 31, 2016 at 4:04 PM, Artem Barger
wrote:
Hi,
Current implementation of kmeans within CM framework, inherently
uses
algorithm published by Arthur, David, and Sergei Vassilvitskii.
"k-means++: The advantages of careful se
On Tue, May 31, 2016 at 4:04 PM, Artem Barger wrote:
> Hi,
>
> Current implementation of kmeans within CM framework, inherently uses
> algorithm published by Arthur, David, and Sergei Vassilvitskii.
> "k-means++: The advantages of careful seeding." *Proceedings of the
> eighteenth annual ACM-S
A couple of months ago, some contributors to Commons Math decided to create a
new project, starting with a fork of the [math] sources. This was a hard
decision for us to make. It is not the intent of this message to rationalize
our decision or to in any way disparage Apache Commons Math. I wil
Hi,
I've create a JIRA ticket MATH-1372 and attached a patch to it, also
submitted PR on GitHub: https://github.com/apache/commons-math/pull/36.
Best regards,
Artem Barger.
On Tue, May 31, 2016 at 3:32 AM, Artem Barger wrote:
>
> On Tue, May 31, 2016 at 3:17 AM, Gilles
> It does not make sense though. All of the code in the bcel6 package is
> going to be released for the first time in the upcoming 6.0 release.
Ok, didnt know that.
Then I'm fine :)
Just wanted to give a hint.
Jan
-
To unsubs
32 matches
Mail list logo
