On Fri, Sep 11, 2009 at 8:58 AM, Matt Benson wrote:
>
>
> --- On Fri, 9/11/09, Henri Yandell wrote:
>
>> From: Henri Yandell
>> Subject: Re: [collections] generics WAS [jira] Commented: (COLLECTIONS-110)
>> Support parametized classes with commons.collections.
&
Just saw this, thought it may be of interest - Google is developing a
collections api (Apache License 2.0).
InfoQ Article:
http://www.infoq.com/news/2007/10/collections-api
Project:
http://code.google.com/p/google-collections/
API:
http://google-collections.googlecode.com/svn/trunk/javadoc
As requested, here are my views on dividing [collections] into smaller jars.
The concept comes from having a single jar file of 550K which other open
source projects have chosen to avoid. This is perhaps understandable
when often their own code may amount to only 150K. The question is
whether
Hello,
I'm creating this thread in order to discuss issue COLLECTIONS-551.
I don't know the deprecation policies of the Commons project in detail, but
based on the last comment posted by Thomas on issue COLLECTIONS-550 I
assume that:
In the next release (4.1):
- Methods using It
Hi,
we are using apache collections for several years. Now the requirements for
generics are necessary for our development team. Is there any progress
in the development for 4.0? What can we do to support the development?
Do we have to solve the last 10 issues and then 4.0 is ready?
Christian
On Sat, Sep 12, 2009 at 2:00 AM, Henri Yandell wrote:
> On Fri, Sep 11, 2009 at 8:58 AM, Matt Benson wrote:
>>
>>
>> --- On Fri, 9/11/09, Henri Yandell wrote:
>>
>>> First up would be to cp trunk to a 3.x branch. It's also
>>> possible that
>>> merging from trunk to the branch may prove easier.
>>
On Sat, Sep 12, 2009 at 5:52 AM, Henri Yandell wrote:
> On Sat, Sep 12, 2009 at 2:00 AM, Henri Yandell wrote:
>> On Fri, Sep 11, 2009 at 8:58 AM, Matt Benson wrote:
>>>
>>>
>>> --- On Fri, 9/11/09, Henri Yandell wrote:
>>>
First up would be to cp trunk to a 3.x branch. It's also
possibl
On Sat, Sep 12, 2009 at 7:26 AM, Rahul Akolkar wrote:
> On Sat, Sep 12, 2009 at 5:52 AM, Henri Yandell wrote:
>> On Sat, Sep 12, 2009 at 2:00 AM, Henri Yandell wrote:
>>> On Fri, Sep 11, 2009 at 8:58 AM, Matt Benson wrote:
--- On Fri, 9/11/09, Henri Yandell wrote:
> First
cement of the URL in the license header
>> is 4 spaces to the right of the rest of the header text's indent.
>
> Yeah... more interested in getting them the same than correct :)
>
> Getting closer, down to 30 clashes. The ones that require more thinking sadly.
Down to 2 ug
that wouldn't add any value.
One potential bad for b) would be if files were renamed, but that
didn't notably happen in this case.
It seems a shame to lose history like:
"r555925 | skestle | 2007-07-13 03:39:24 -0700 (Fri, 13 Jul 2007) | 2 lines
Added Edwin Tellman's patch for
On Sun, Sep 13, 2009 at 12:08 AM, Henri Yandell wrote:
>
> Hopeful that I can resolve the two above over the next couple of nights.
Latest status update (as I'm worried this is the kind of thing that
could fall off my priority list and lots of people are stuck waiting;
no status updates means ha
t; hasn't been genericized yet and I may commit those as is.
Taken care of. When committed I'll reopen COLLECTIONS-285 and
COLLECTIONS-255 as I've had to undo those due to refactoring in
TreeBidiMap that I didn't want to mess with. This was the only merge
issue, the others were a
On Sun, Sep 13, 2009 at 9:08 PM, Henri Yandell wrote:
>
> Tests compile (under Maven). 4 serialization ones fail when running -
> will dig into. Might be a merging issue with .obj files and id values
> in classes.
Fixed these btw by setting serialVersionUIDs to the previous values as
they didn't
> didn't notably happen in this case.
>
> It seems a shame to lose history like:
>
> "r555925 | skestle | 2007-07-13 03:39:24 -0700 (Fri, 13 Jul 2007) | 2 lines
>
> Added Edwin Tellman's patch for COLLECTIONS-243.
> It all seems pretty reasonable, and it should
--- Stephen Colebourne <[EMAIL PROTECTED]> wrote:
> As requested, here are my views on dividing
> [collections] into smaller jars.
>
Thanks. :)
> The concept comes from having a single jar file of
> 550K which other open
> source projects have chosen to
In the end, I think that no change, and a single jar file, may still
be the best option.
Whoever is concerned about jar size could reduce the size at build time.
I am not so sure it's worth the hassle to split collections like
that *shrug*
cheers
--
To
t, the
> > generics branch could go
> > further and properly separate the functor code and
> > collections, which is
> > the division that probably makes the most sense.
>
> To take this a step further, the current trunk could
> move to a 4.x target, allowi
re it's worth the hassle to split collections like
> that *shrug*
Aren't we also going to be removing quite a bit when we go to JDK5?
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
> > > code, and that will
> > > allow new growth to occur there. In fact, the
> > > generics branch could go
> > > further and properly separate the functor code
> and
> > > collections, which is
> > > the division that probably ma
> > wrote:
> >
> > > > The generics branch should remove the
> > deprecated
> > > > code, and that will
> > > > allow new growth to occur there. In fact, the
> > > > generics branch could go
> > > > further
Hello Gonçalo,
welcome to the Apache Commons community.
2015-01-29 11:57 GMT+01:00 Gonçalo Marques :
> Hello,
>
> I'm creating this thread in order to discuss issue COLLECTIONS-551.
>
> I don't know the deprecation policies of the Commons project in detail, but
&g
On 29 January 2015 at 10:57, Gonçalo Marques
wrote:
> Hello,
>
> I'm creating this thread in order to discuss issue COLLECTIONS-551.
>
> I don't know the deprecation policies of the Commons project in detail, but
> based on the last comment posted by Thomas on issu
On 01/29/2015 11:57 AM, Gonçalo Marques wrote:
> Hello,
>
> I'm creating this thread in order to discuss issue COLLECTIONS-551.
>
> I don't know the deprecation policies of the Commons project in detail, but
> based on the last comment posted by Thomas on issue COL
Hi,
Just to let you know I'm working on this.
Gonçalo
On Thu, Jan 29, 2015 at 9:07 PM, Thomas Neidhart
wrote:
> On 01/29/2015 11:57 AM, Gonçalo Marques wrote:
> > Hello,
> >
> > I'm creating this thread in order to discuss issue COLLECTIONS-551.
> >
>
Hi,
I've sent a pull request containing CollectionUtils refactor for review
(COLLECTIONS-551).
Since the next release version is 4.1, I'm wondering if methods that were
deprecated which are tagged with "@since 4.1" shouldn't be promptly removed
from CollectionUtils.
On 31 January 2015 at 18:40, Gonçalo Marques
wrote:
> Hi,
>
> I've sent a pull request containing CollectionUtils refactor for review
> (COLLECTIONS-551).
>
> Since the next release version is 4.1, I'm wondering if methods that were
> deprecated which are tagged
On 02/01/2015 07:44 PM, sebb wrote:
> On 31 January 2015 at 18:40, Gonçalo Marques
> wrote:
>> Hi,
>>
>> I've sent a pull request containing CollectionUtils refactor for review
>> (COLLECTIONS-551).
>>
>> Since the next release version is 4.1, I
On Sun, Feb 1, 2015 at 7:12 PM, Thomas Neidhart
wrote:
>
> On 02/01/2015 07:44 PM, sebb wrote:
> > On 31 January 2015 at 18:40, Gonçalo Marques
> > wrote:
> >> Hi,
> >>
> >> I've sent a pull request containing CollectionUtils refactor for revie
gt;> I've sent a pull request containing CollectionUtils refactor for review
>>>> (COLLECTIONS-551).
>>>>
>>>> Since the next release version is 4.1, I'm wondering if methods that were
>>>> deprecated which are tagged with "@since 4.1&q
18:40, Gonçalo Marques
>>>> wrote:
>>>>> Hi,
>>>>>
>>>>> I've sent a pull request containing CollectionUtils refactor for review
>>>>> (COLLECTIONS-551).
>>>>>
>>>>> Since the next release version is 4.1
Overlap between Lang and Collections is starting to increase a bit.
Requested items for ArrayUtils (LANG-238, LANG-470) are better
implemented imo as an ArraySet class. An easy add to Collections.
ComparableComparator made its way (privately) over for the new Range
class. Fair enough - Comparable
if it is not in POM)
- fix Checkstyle issues
- consider what open JIRAs to address
Gary
On Mon, Jan 7, 2013 at 10:12 AM, Christian Grünberg wrote:
> Hi,
>
> we are using apache collections for several years. Now the requirements
> for generics are necessary for our development te
On Mon, Jan 7, 2013 at 4:12 PM, Christian Grünberg wrote:
> Hi,
>
> we are using apache collections for several years. Now the requirements
> for generics are necessary for our development team. Is there any progress
> in the development for 4.0? What can we do to support the devel
Hi !
I was curious wether Commons Collections is dormant or not , since
last release is from 2010 and this release doesnt support generics.
With regards ,
Leandro A. Pezzente
1. Change the root-level package name to
org.apache.commons.collections4 (we should jump major version numbers;
go to 5 perhaps?)
2. Remove the "functors" from Collections and have collections depend
on Commons Functor (Matt Benson has done some great work on functor
already!).
3.
Henri Yandell wrote at Dienstag, 15. September 2009 08:07:
> On Sun, Sep 13, 2009 at 9:08 PM, Henri Yandell wrote:
>
>>
>> Tests compile (under Maven). 4 serialization ones fail when running -
>> will dig into. Might be a merging issue with .obj files and id values
>> in classes.
>
> Fixed thes
--- On Tue, 9/15/09, Henri Yandell wrote:
> From: Henri Yandell
> Subject: [collections] merging collections - DONE
> To: "Commons Developers List"
> Date: Tuesday, September 15, 2009, 1:07 AM
> On Sun, Sep 13, 2009 at 9:08 PM,
> Henri Yandell
> wrote:
>
On Tue, Sep 15, 2009 at 10:11 AM, Matt Benson wrote:
>
>
> --- On Tue, 9/15/09, Henri Yandell wrote:
>
>> From: Henri Yandell
>> Subject: [collections] merging collections - DONE
>> To: "Commons Developers List"
>> Date: Tuesday, September 15, 20
://github.com/coderodde/IndexedLinkedList
Does it have potential to be included in Collections?
Best regards,
rodde
Hello everybody.
I would like to know if there would be any interest of including a "disk-backed
map" into the commons-collections? The problem statement for it would be:
- while we are moving to 64bit, it will still take a couple of years until all
hardware is 64 bit and more import
Good day!
I am working on a bidirectional (bijective) hash map at
https://github.com/coderodde/BidirectionalHashMap
In
http://svn.apache.org/viewvc/commons/proper/collections/trunk/src/main/java/org/apache/commons/collections4/bidimap/DualHashBidiMap.java?view=markup
there is a note in the
Hello,
I would like to contribute to Apache Commons projects. I’ve started with
preparing a PR for issue COLLECTIONS-798:
https://github.com/apache/commons-collections/pull/278.
Proposed changes:
replacing TestBuilder with a mock object using Mockito,
stubbing method: Builder with(byte[] item
Additional thought... the Collections Test library should move to
being a first class component in Commons rather than a side thought
inside Collections. So this is three new components from one:
* Test library
* Core JDK [Lang merge?]
* Collections impls
On Wed, Dec 30, 2009 at 2:18 AM, Henri
Henri,
To make this more interesting, the new collections over in mahout-math
might be covering some of the territory you are looking for here.
--benson
On Wed, Dec 30, 2009 at 5:18 AM, Henri Yandell wrote:
> Overlap between Lang and Collections is starting to increase a bit.
> Req
Briefly looking at
http://svn.apache.org/repos/asf/lucene/mahout/trunk/math/src/main/java/org/apache/mahout/math/
- it looks like this is more along the lines of the Collections as new
data structures/algorithms rather than Collections as JDK enhancer?
Ignoring the edge case overlaps with Math
- it looks like this is more along the lines of the Collections as new
> data structures/algorithms rather than Collections as JDK enhancer?
>
> Ignoring the edge case overlaps with Math and Lang anyway.
>
> Hen
>
> On Wed, Dec 30, 2009 at 3:58 AM, Benson Margulies
> wrot
Henri Yandell wrote:
> Overlap between Lang and Collections is starting to increase a bit.
> Requested items for ArrayUtils (LANG-238, LANG-470) are better
> implemented imo as an ArraySet class. An easy add to Collections.
>
> ComparableComparator made its way (privately) over fo
I do not like the divide between Lang and Collections. I think it's a
superficial divide that can never really be complete, and the forces
of logic naturally pulls us back together in some regards. It's
consternation to keep these projects separate. Why must we keep
trying?
I'd
On Sat, Jan 2, 2010 at 9:11 AM, Phil Steitz wrote:
> Henri Yandell wrote:
>> Overlap between Lang and Collections is starting to increase a bit.
>> Requested items for ArrayUtils (LANG-238, LANG-470) are better
>> implemented imo as an ArraySet class. An ea
On Sat, Jan 2, 2010 at 10:02 AM, Henri Yandell wrote:
> On Sat, Jan 2, 2010 at 9:11 AM, Phil Steitz wrote:
>> One final comment is that a logical alternative is to just split
>> [collections] internally into multiple pieces with separate release
>> cycles. Managing d
Henri Yandell wrote:
> On Sat, Jan 2, 2010 at 9:11 AM, Phil Steitz wrote:
>> Henri Yandell wrote:
>>> Overlap between Lang and Collections is starting to increase a bit.
>>> Requested items for ArrayUtils (LANG-238, LANG-470) are better
>>> implemented imo
Each if you split Collections into Maven children, you would still
wouldn't want to release them independently. That would be a gigantic
administrative error. Struts was thinking about doing the same thing
with its libraries, but we turned away from it -- THANKFULLY. How
would you explain to
On Sat, Jan 2, 2010 at 10:45 AM, Phil Steitz wrote:
> Henri Yandell wrote:
>> I was thinking more that a smaller [collections] might have room for
>> the functor code again - not that [lang] would :) Agreed that it's
>> better out than in though.
>
> That is in
On Sat, Jan 2, 2010 at 12:36 PM, Paul Benedict wrote:
> Each if you split Collections into Maven children, you would still
> wouldn't want to release them independently. That would be a gigantic
> administrative error. Struts was thinking about doing the same thing
> with its
Henri,
> Lang's math.NumberUtils and math.Fraction for example. MathUtils and a
> little bit of StatUtils do look to be similar in scope.
I have voiced booting the whole math package from Commons Lang.
Anytime another project inches its way into another, that's my signal
its poorly placed. I stil
t; innovation happen more easily.
I don't think the way Lang and Collections does their artifacts is a
problem... BUT, I do say they stuff way too much stuff into a release.
Their cycles are slow because they cram a mountain into each release.
Rather, release often and release less. Do somethin
ons
>> components will now be available to be worked on' time might make
>> innovation happen more easily.
>
> I don't think the way Lang and Collections does their artifacts is a
> problem... BUT, I do say they stuff way too much stuff into a release.
> Their cycles ar
On Jan 2, 2010, at 3:27 PM, Henri Yandell wrote:
On Sat, Jan 2, 2010 at 10:45 AM, Phil Steitz
wrote:
Henri Yandell wrote:
I was thinking more that a smaller [collections] might have room for
the functor code again - not that [lang] would :) Agreed that it's
better out than in t
Paul Benedict wrote:
> Each if you split Collections into Maven children, you would still
> wouldn't want to release them independently. That would be a gigantic
> administrative error. Struts was thinking about doing the same thing
> with its libraries, but we turned away from
les Stream, Reader and Writer - the java.io package
[collections] - handles those interfaces defined by Sun as the Java
Collections Framework
[beanutils] - handles code that adheres to Sun's defined Java Bean framewok
[lang] - the remaining parts of java.lang and java.util
Oh, and as per the o
On Jan 5, 2010, at 7:58 PM, Stephen Colebourne wrote:
[SNIP]
And splitting [collections]? Definitely a good idea. I would remove
all the Predicate/Closure/Transformer code (if you believe in FP,
use [functor]). Then split the rest by implementations of JDK
collections, and extended JDK
Colebourne wrote:
> [SNIP]
>>
>> And splitting [collections]? Definitely a good idea. I would remove all
>> the Predicate/Closure/Transformer code (if you believe in FP, use
>> [functor]). Then split the rest by implementations of JDK collections, and
>> e
n wrote:
>>
>> On Jan 5, 2010, at 7:58 PM, Stephen Colebourne wrote:
>> [SNIP]
>>>
>>> And splitting [collections]? Definitely a good idea. I would remove all
>>> the Predicate/Closure/Transformer code (if you believe in FP, use
>>> [functo
Henri,
On Fri, Jan 8, 2010 at 1:22 AM, Henri Yandell wrote:
> How would that work?
>
> If I do work on one component and want to release it, do I have to
> wait on 7 other releases?
>
If you work on one Commons Collection artifact within a Commons
Collection release, yes.
Paul
Hello.
One week ago I proposed a patch to the issue #363 (
https://issues.apache.org/jira/browse/COLLECTIONS-363 ).
I didn't see any relevant activity though. It is my first patch to apache
projects and i'm trying to understand how everybody works here. I also
understand that apache
Hello.
One week ago I proposed a patch to the issue #363 (
https://issues.apache.org/jira/browse/COLLECTIONS-363 ).
I didn't see any relevant activity though. It is my first patch to apache
projects and i'm trying to understand how everybody works here. I also
understand that apache
Hi,
finally I've found the time to answer to this topic :) We had a similar
discussion a while ago [1]. Back then James suggested to drop
collections completely in favor of google guava. I have started to
implement QueryableCollections in trunk anyway, because I still disagree
with Jam
I would recommend guava over collections as well so it sounds like you
disagree with both of us!
:-)
On Wed, Feb 15, 2012 at 1:07 PM, Benedikt Ritter
wrote:
> finally I've found the time to answer to this topic :) We had a similar
> discussion a while ago [1]. Back then James sugges
Guava is a fine product but I'd like to see a generics version of
[collections]. I wonder what state trunk is in and if could be released
soon...
Gary
On Wed, Feb 15, 2012 at 1:13 PM, Ted Dunning wrote:
> I would recommend guava over collections as well so it sounds like you
> di
Yes , i know , but , arent other products like Tomcat 7.0 being hurt
by being dependent on a pre-generics version of Commons Collections ?
Leandro A. Pezzente
On miércoles, 15 de febrero de 2012 at 3:23 PM, Gary Gregory
wrote:Guava is a fine product but I'd like to see a generics versi
As far as I can tell, it looks pretty generified ;) But as I said, I'm
having that name clash error.
Okay, so it is consensus, that no more effort (regarding new features)
should be put into collections?
Benedikt
Am 15.02.2012 19:23, schrieb Gary Gregory:
Guava is a fine product but I&#
Am 15.02.2012 20:21, schrieb leandro.pezze...@hush.com:
Yes , i know , but , arent other products like Tomcat 7.0 being hurt
by being dependent on a pre-generics version of Commons Collections ?
That's no problem. There is no need to update to the latest version. The
old versions wi
On 15/02/2012 20:14, Benedikt Ritter wrote:
> Am 15.02.2012 20:21, schrieb leandro.pezze...@hush.com:
>> Yes , i know , but , arent other products like Tomcat 7.0 being hurt
>> by being dependent on a pre-generics version of Commons Collections ?
With my Tomcat committer hat on
Hi Benedict,
Benedikt Ritter wrote:
> Hi,
>
> finally I've found the time to answer to this topic :) We had a similar
> discussion a while ago [1]. Back then James suggested to drop
> collections completely in favor of google guava. I have started to
> implement Querya
On Wed, Feb 15, 2012 at 2:35 PM, Jörg Schaible wrote:
> Hi Benedict,
>
> Benedikt Ritter wrote:
>
>> Hi,
>>
>> finally I've found the time to answer to this topic :) We had a similar
>> discussion a while ago [1]. Back then James suggested to drop
>
d a similar
>>> discussion a while ago [1]. Back then James suggested to drop
>>> collections completely in favor of google guava. I have started to
>>> implement QueryableCollections in trunk anyway, because I still disagree
>>> with James.
>>> I would appr
ft.org/
On Wed, Feb 15, 2012 at 7:07 PM, Benedikt Ritter
wrote:
> Hi,
>
> finally I've found the time to answer to this topic :) We had a similar
> discussion a while ago [1]. Back then James suggested to drop collections
> completely in favor of google guava. I
t;> by being dependent on a pre-generics version of Commons Collections
?
With my Tomcat committer hat on:
No. Primarily because Tomcat doesn't have a dependency on collections
and hasn't for some time.
Tomcat does depend on other Commons libraries that have yet to be
converted to gen
twitter.com/simonetripodi
http://www.99soft.org/
On Wed, Feb 15, 2012 at 7:07 PM, Benedikt Ritter
wrote:
Hi,
finally I've found the time to answer to this topic :) We had a similar
discussion a while ago [1]. Back then James suggested to drop collections
completely in favor of google guava
this topic :) We had a similar
discussion a while ago [1]. Back then James suggested to drop
collections
completely in favor of google guava. I have started to implement
QueryableCollections in trunk anyway, because I still disagree with
James.
I would appreciate comments from one of commons colle
al.com/
>> http://twitter.com/simonetripodi
>> http://www.99soft.org/
>>
>>
>>
>> On Wed, Feb 15, 2012 at 7:07 PM, Benedikt Ritter
>> wrote:
>>>
>>> Hi,
>>>
>>> finally I've found the time to answer to this topic :) We had a
Hello to everyone!
I am working as a software developer and in my day to day work, I
use Apache Commons utilities extensively. I am pretty much enthusiastic
about contributing to Apache OSF and as a starting point, I have decided to
do small contributions in Commons-Collections as I am
Thanks for the contribution.
The bloomfilter package is unrelease code and is currently being rewritten.
Your PR is updating a class that will be removed.
You are welcome to review the current design in PR 258:
https://github.com/apache/commons-collections/pull/258
Alex
<https://github.
Did you see the comment on that JIRA that asked for a test case?
On Sun, Dec 19, 2010 at 11:07 PM, Igor Saprykin wrote:
> Hello.
>
> One week ago I proposed a patch to the issue #363 (
> https://issues.apache.org/jira/browse/COLLECTIONS-363 ).
>
> I didn't see any relev
o I proposed a patch to the issue #363 (
> > https://issues.apache.org/jira/browse/COLLECTIONS-363 ).
> >
> > I didn't see any relevant activity though. It is my first patch to apache
> > projects and i'm trying to understand how everybody works here. I also
&
Hi All:
Can the community opine on the solution offered in the PR: Throw an IAE
instead of fixing the tree in some way.
https://issues.apache.org/jira/browse/COLLECTIONS-714
Thank you,
Gary
GitHub user gonmarques opened a pull request:
https://github.com/apache/commons-collections/pull/7
COLLECTIONS-550
[COLLECTIONS-550] Provide a simple way for creating an arbitrary String
representation of a given Iterable
You can merge this pull request into a Git repository by
GitHub user gonmarques opened a pull request:
https://github.com/apache/commons-collections/pull/8
Collections 551
You can merge this pull request into a Git repository by running:
$ git pull https://github.com/gonmarques/commons-collections COLLECTIONS-551
Alternatively you
Github user gonmarques closed the pull request at:
https://github.com/apache/commons-collections/pull/8
---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the
GitHub user gonmarques opened a pull request:
https://github.com/apache/commons-collections/pull/9
COLLECTIONS-551
You can merge this pull request into a Git repository by running:
$ git pull https://github.com/gonmarques/commons-collections COLLECTIONS-551
Alternatively you
Github user asfgit closed the pull request at:
https://github.com/apache/commons-collections/pull/7
---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the
Welcome aboard.
The simplest way to contribute is to add a patch with unit tests to a JIRA.
If you want to add a new feature, it can be a good idea to chat on this
mailing list to see if that feature fits in the target component, like
[collections].
Gary
On Sat, Mar 7, 2015 at 5:20 AM, Orchid
a JIRA.
>
> If you want to add a new feature, it can be a good idea to chat on this
> mailing list to see if that feature fits in the target component, like
> [collections].
>
> Gary
>
> On Sat, Mar 7, 2015 at 5:20 AM, Orchid Majumder
> wrote:
>
> > Hello t
I have revived some discussion at
https://issues.apache.org/jira/browse/COLLECTIONS-479
(https://issues.apache.org/jira/browse/COLLECTIONS-479)
Basically, what interfaces an order statistic tree should implement? What comes
to the structure, will a counted AVL-tree do?
Best,
rodde
Github user chtompki commented on the issue:
https://github.com/apache/commons-collections/pull/9
@gonmarques - Do you mind rebasing this work onto the `master` branch and
opening a new pull request?
---
If your project is set up for it, you can reply to this email and have your
Github user gonmarques commented on the issue:
https://github.com/apache/commons-collections/pull/9
Hi,
It has been almost two and a half years since I opened this PR. I did a
quick rebase just to have an idea of any eventual existing conflicts and got a
non-trivial conflict
Github user chtompki commented on the issue:
https://github.com/apache/commons-collections/pull/9
Ok no stress. I'll try to see what I can do with it. Cheers, -Rob.
---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If
There have been a few PRs recently in collections with simple formatting
errors. These should be picked up by checkstyle to prevent correction
after merge.
The [collections] checkstyle configuration is old. If I replace it with
the Checkstyle version close to the Sun standard [1] then there
in GitHub:
> https://github.com/coderodde/IndexedLinkedList
>
> Does it have potential to be included in Collections?
>
> Best regards,
> rodde
--
Elliotte Rusty Harold
elh...@ibiblio.org
-
To unsubscri
Deque/List that is implemented as a doubly linked
> > list with a sublinear index speeding up single-element operations to
> > (likely) O(sqrt(n)). It passes a benchmark faster than TreeList by the
> > factor of around 5.
> >
> > The data structure is hosted in GitHub:
1 - 100 of 1222 matches
Mail list logo
