[CLI] Weird deprecation case

I have a case where I have multiple no-argument options in an OptionGroup. The group comprises a deprecated option and a current option. Basically an option rename. When I check for the option I simply check if (OptionGroup.getSelected() != null). However if the deprecated value is selected

Re: [Collections] Implementation of EnhancedDoubleHasher

Pull request https://github.com/apache/commons-collections/pull/501 addresses this issue - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org

Re: [CLI] Parsing arguments with no options...

I seem to recall that the parsing multiple options code is "wonky" because it has to deal with a legacy "comma separated string". It may relate to CLI-306 On Tue, May 28, 2024 at 6:16 PM Gary Gregory wrote: > What about 'Hello World'? > > Gary > > On Tue, May 28, 2024, 11:13 AM Eric Pugh >

[CLI] Using cli to drive Ant and Maven UIs

Just an observation. I am working on the Rat tool. Part of that is that we want to harmonize the UIs (CLI, Ant, and Maven) so that there are congruent options across the UIs. The Option definition in commons-cli v1.8.0 is sufficiently complex that we can define the options in the CLI interface

Re: [VOTE] Release Apache Commons CLI 1.8.0 based on RC1

l this RC othewise it > would be a breaking change or would clutter up the API with an > additional public method. > > Gary > > On Sat, May 18, 2024 at 9:04 AM Claude Warren wrote: > > > > -1 There is a design issue. > > > > The HelpFormatter now takes a Bi

Re: [VOTE] Release Apache Commons CLI 1.8.0 based on RC1

-1 There is a design issue. The HelpFormatter now takes a BiFunction to format the description for deprecated Options. However, it is simple to implement Function instead. I think this makes for a cleaner interface. Since this interface is public facing, I would like to merge the change in

Re: [CLI] Deprecated options and helpformatting

Gary, I just realized this AM that there is a change I proposed to simplify the deprecated output. Please see pull request 277. I think the change from BiFormat to Format makes the HelpFormatter API much cleaner. Claude On Fri, May 17, 2024 at 6:26 PM Claude Warren wrote: > Gary, &g

Re: [CLI] Deprecated options and helpformatting

I can cut a release candidate > later in the week. > > Gary > > On Sat, May 11, 2024 at 6:28 AM Claude Warren wrote: > > > > Also, it appears that the deprecatedHandler is only tested on the string > > option processing. if the application retains a list of Optio

Re: [CLI] Deprecated options and helpformatting

, 09:14 Claude Warren, wrote: > I opened CLI-333 to address the Build production method issue. > > On Tue, May 14, 2024 at 10:25 PM Gary Gregory > wrote: > >> Sounds good to me! Thank you for talking it out. GoF reference appreciated >>   >> >> Looking for

Re: [Collections] Suppliers, Iterables, and Producers

I have updated Collections-854 [1] to reflect the naming that we have been talking about and will start on the refactoring soon. Please start watching that ticket. Claude [1] https://issues.apache.org/jira/browse/COLLECTIONS-854 On Mon, May 13, 2024 at 12:33 PM Claude Warren wrote

Re: [CLI] Deprecated options and helpformatting

I opened CLI-333 to address the Build production method issue. On Tue, May 14, 2024 at 10:25 PM Gary Gregory wrote: > Sounds good to me! Thank you for talking it out. GoF reference appreciated >   > > Looking forward to a PR, > Gary > > On Tue, May 14, 2024, 1:47 PM

Re: [CLI] Deprecated options and helpformatting

I have to admit that i am partial to build but in reviewing gang of four and various java build patterns i find that there are a number of terminal methods. Gary is, I now believe, correct; that the builder should implement Supplier. On Tue 14 May 2024, 19:28 Claude Warren, wrote

Re: [CLI] Deprecated options and helpformatting

Supplier. > > Gary > > On Tue, May 14, 2024, 1:00 PM Gary Gregory wrote: > > > IMO future factories should only be Suppliers. > > > > Whether to deprecate current code in favor of Suppliers is possible if > > only a bit noisy. > > > > Gary > > > &

Re: [CLI] Deprecated options and helpformatting

I have submitted a draft pull request https://github.com/apache/commons-cli/pull/272 However, I would like to resolve the Builder/build Builder/get naming issue before I take it out of draft mode. On Tue, May 14, 2024 at 6:05 PM Claude Warren wrote: > I will add some tests to show w

Re: [CLI] Deprecated options and helpformatting

external code I was developing. There are probably others that we can find the code base but I was thinking an "OptionUtils" or "OptionFormat" or "OptionHelper" class that has static methods taking an Option. Are there any objections to this? On Tue, May 14, 2024

Re: [CLI] Deprecated options and helpformatting

Eric, I may have broken it with my implementation of the HelpFormatter deprecatedFormatFunc() method. On Tue, May 14, 2024 at 4:06 PM Claude Warren wrote: > We already have historical uses of builders in CLI (e.g. > CommandLine.Builder) that use build() not get(). > In addi

Re: [CLI] Deprecated options and helpformatting

etter documentation is always nice :-) > > I vote for Supplier/get() because it does not require the invention of > something new that does _exactly the same thing as the code already > provided in the JRE_. > > Gary > > On Tue, May 14, 2024 at 8:22 AM Claude Warre

Re: [CLI] Deprecated options and helpformatting

I also think that the if an Option is marked with deprecated then the HelpFormatter should, by default, inlcude the "[Deprecated]" line. (I am working on a change for this too) On Tue, May 14, 2024 at 2:22 PM Claude Warren wrote: > I find a couple of issues: > > No docume

Re: [CLI] Deprecated options and helpformatting

rs. I expect a build() method. In any case we should settle on one or the other. In case it is not obvious I vote for build(). On Mon, May 13, 2024 at 11:54 AM Claude Warren wrote: > Will do. > > On Sun, May 12, 2024 at 8:49 PM Gary Gregory > wrote: > >> How does it look now

Re: [Collections] Suppliers, Iterables, and Producers

ry Gregory wrote: > LGTM. Maybe the current PR (LGTM) should be merged first, Alex, how does > that PR look to you? > > Gary > > On Fri, May 3, 2024, 11:44 AM Claude Warren wrote: > >> Gary and Alex, >> >> Any thoughts on this? >> >> Claude >>

Re: [CLI] Deprecated options and helpformatting

Will do. On Sun, May 12, 2024 at 8:49 PM Gary Gregory wrote: > How does it look now? > > Would you check git master is OK, then I can cut a release candidate > later in the week. > > Gary > > On Sat, May 11, 2024 at 6:28 AM Claude Warren wrote:

[COLLECTIONS] Is the changes.xml file automatically updated by pull merge?

-- LinkedIn: http://www.linkedin.com/in/claudewarren

Re: [CLI] Deprecated options and helpformatting

Also, it appears that the deprecatedHandler is only tested on the string option processing. if the application retains a list of Options and passes those in to be checked the deprecation check is not execute. On Sat, May 11, 2024 at 12:18 PM Claude Warren wrote: > Greetings, > &

[CLI] Deprecated options and helpformatting

Greetings, I see that there is a deprecated option in cli 1.7.0, and that it has some nice data. But I don't see how to display the info in the help. It looks like the only option is to print "[Deprecated]" without any information from the deprecated info. I think the HelpPrinter needs a

Re: [Collections] Suppliers, Iterables, and Producers

Gary and Alex, Any thoughts on this? Claude On Wed, May 1, 2024 at 7:55 AM Claude Warren wrote: > Good suggestions. > > short-circuit. We could make this distinction by including it in the name: >> forEachUntil(Predicate ...), forEachUnless, ... > > > We need the unit

Re: [RDF] Querying a graph using SPARQL

I don't know if it was not intended, but I don't think there is an implementation. I suspect you need to use something like Jena. On Sat, Mar 2, 2024 at 5:24 PM Fred Hauschel wrote: > Hi there, > > currently i try to understand, how i can use SPARQL with commons-rdf. > > I suspect that was not

Re: [Configuration] new feature - containsValue

Ricardo, Thank you for your effort and contribution. I find it difficult to evaluate your work without a pull request (a draft one will do) to show what changes you have made. It just makes reviewing much easier. Can you open a draft pull request please? Claude On Wed, May 1, 2024 at 3:54 AM

Re: [Collections] Suppliers, Iterables, and Producers

OLLECTIONS-854 On Tue, Apr 30, 2024 at 4:51 PM Gary D. Gregory wrote: > > > On 2024/04/30 14:33:47 Alex Herbert wrote: > > On Tue, 30 Apr 2024 at 14:45, Gary D. Gregory > wrote: > > > > > Hi Claude, > > > > > > Thank you for the detailed reply :

Re: [Collections] Suppliers, Iterables, and Producers

I will see if I can clarify the javadocs and make things clearer. What I think I specifically heard is: - Be clear that producers are fast fail iterators with predicate tests. - Rename CellConsumer to CellPredicate (?) - The semantic nomenclature: - Bitmaps are arrays of bits not

Does anyone know of a good cache testing library?

I am looking for a cache testing library to test a new cache eviction strategy that I have developed. Does anybody know of one, preferably in Java? Claude

Re: [Collections-BloomFilter][Discuss] missing functionality?

, 2024 at 3:00 PM Alex Herbert wrote: > On Sat, 20 Apr 2024 at 11:36, Claude Warren wrote: > > > The LayerdBloomFilter has a method find() that returns an array of ints > > that are the indices into the layer array. This is easily reproducible > > using an iterator. > &

Re: [Collections-BloomFilter][Discuss] missing functionality?

. This is reproducible but not as efficient using an iterator. I think the array is the proper structure. Claude On Fri, Apr 19, 2024 at 11:06 AM Alex Herbert wrote: > On Fri, 19 Apr 2024 at 08:26, Claude Warren wrote: > > > While the Deque makes clear the idea of enqueueing an

Re: Is there a blog for commons?

I was really looking for a way to reach out to developers that do not know that there is a Bloom filter implementation and may not know how they could use one. Once someone knows they'll look in the project documentation and or javadoc (so I have no issue putting the info there as well). On Fri,

Re: [Collections-BloomFilter][Discuss] missing functionality?

mFilter get(int depth) > > Performance will be the same as the Deque can be a LinkedList. This is more > about how any custom downstream code is currently using the collection of > layers. > > Alex > > On Wed, 17 Apr 2024 at 10:00, Claude Warren wrote: > > > I have an open

Re: Is there a blog for commons?

I have what is currently a series of 4 blogs that introduce the new Bloom filter implementations and framework in Commons Collections. I have a couple more in mind, they discuss what Bloom filters are and how the Commons Collections implements them, provides extension points, and how to implement

Re: [Collections-BloomFilter][Discuss] missing functionality?

I have an open pull request to fix this problem. I could use another review: https://github.com/apache/commons-collections/pull/476 On Tue, Apr 9, 2024 at 11:29 AM Claude Warren wrote: > Alex, > > I like your solution. To answer your question. We create a BloomFilter > that has

Is there a blog for commons?

I was wondering if there is a blog dedicated to commons? I have several blog posts about using the new Bloom filters in collections 4.5 and am looking for a place to publish. Claude -- LinkedIn: http://www.linkedin.com/in/claudewarren

Re: [VOTE] Release Apache Commons CLI 1.7.0 based on RC1

+1 Ubuntu 22.04.4 LTS Java openjdk 21.0.2 2024-01-16 On Sat, Apr 13, 2024 at 6:22 PM Bruno Kinoshita wrote: > +1 > > Building OK from tag with > > Apache Maven 3.8.5 (3599d3414f046de2324203b78ddcf9b5e4388aa0) > Maven home: /opt/apache-maven-3.8.5 > Java version: 17.0.10, vendor: Private

Re: [Collections-BloomFilter][Discuss] missing functionality?

depth) > > This is not supported by the Deque interface. However the LinkedList > implementation of get(int) will use the iterator from the start or end of > the list (whichever is closer) to find the element. This can use the > iterator/descendingIterator method of Deque for the same perfo

[Collections-BloomFilter][Discuss] missing functionality?

Greetings, I am attempting to use the Bloomfilter code in Kafka to manage PID generation. The requirement is to remove pid tracking after a period of time. This is possible with the LayeredBloomFilter but it has an edge case problem. The LayeredBloomFilter uses the LayerManager to manage the

Re: [Collections] New release candidate for 4.5.0-beta1 or -M1 and new Bloom Filter package

+1 on the M1 or beta1 release. On Mon, Mar 25, 2024 at 2:12 PM Gary Gregory wrote: > Hi All, > > 4.5.0 will contain a new package for Bloom Filters. > > Since this is a new package and is non-trivial, I propose we release a > version called 4.5.0-M1 or 4.5.0-beta1 to let users try this out

Re: [CLI] kabob-format?

encies. For example, in Linux, for some app -list > means the list option but in others is the same as -l -i -s -t, nasty. > > But more importantly, what insane variation of kebab formatting is kabob? > > Gary > > On Fri, Jan 5, 2024, 9:45 AM Claude Warren wrote: > > >

[CLI] kabob-format?

Is there a good reason not to support kabob-format in CLI? I can see that we have to strip the '-' nad '--' off the front but after that tis seems like anything before a space should be valid. -- LinkedIn: http://www.linkedin.com/in/claudewarren

[BEANUTILS] Is there a good reason for Converter to not be a FunctionalInterface?

I am looking at BeanUtils as part of the CLI options to parse a command line option string into a class. I see that Converter is an interface with one method; converting a String to an Object. Is there a good reason for this not to be annotated as an @FunctionalInterface? Claude -- LinkedIn:

[CLI] DISCUSS: Should Option(Builder) constructor be protected?

Is the option class intended to be extended? If not then it should probably be final. If so, then the Option(Builder) constructor should be protected so that derived classes can avail of the default settings from the Builder. I have a case where I want to pass the standard builder into the

[COLLECTIONS] Thread safe Bloom filter

I have been thinking about what it would take to make SimpleBloomFilter thread safe. I think that the answer is to use a copy on write strategy and a lock within all the merge methods. However, this leaves the problem of the cardinality calculation. Currently it is lazily performed and cached.

Re: [COLLECTIONS] Trie subclassing

maintenance and minimize the public API surface > to support. > > > > We could make it public if we are sure the API is documented and the > code isbas good as we can reasonably make it. > > > > Gary > > > > > > On Mon, Apr 17, 2023, 11:48 Claude Warren w

[COLLECTIONS] Trie subclassing

I was looking at the Trie and PatriciaTree class structure from version 4.5 over the weekend. I wanted to build a different implementation with slight modifications. However, there does not seem to be a way to inherit from AbstractPatriciaTrie as it is package protected. Was this intentional or

RE: [Collections] Bloom filters status?

Gary, The Bloom filter package is functionally complete and ready for prime time. As to beta, I have used it in several research projects and am proposing using it in an in-house project at work. I don't know what the standard process is for commons, so I leave it to your discretion. Claude

pulls 358 and 361

These pulls have conflicting changes. When one is merged I will fix the other. Claude -- I like: Like Like - The likeliest place on the web LinkedIn: http://www.linkedin.com/in/claudewarren

COLLECTIONS-824: BloomFilter: Optimize SimpleHasher.forEachIndex and SimpleHasher name change

@aherbert I will be out of pocket for the next 1.5 weeks.  When I return I would like to see if we can resolve COLLECTIONS-824.  Do you have an implementation of EnhancedDoubleHasher that we can use? I found a bit shift method to do power calculations but am not certain that it is public

Re: [Commons-Collections] remove bloom filters?

Is a major > reengineering what you are suggesting? > > Regards, > > Alex > > On Mon, 30 Aug 2021 at 13:37, Claude Warren wrote: > > > Greetings, > > > > I see that the Bloom filter implementation has not been released. It > would > > be in V4.5. I

[Commons-Collections] remove bloom filters?

Greetings, I see that the Bloom filter implementation has not been released. It would be in V4.5. I have not had time to come back and clean it up as it should be to make is simpler and faster. I am concerned that there may be an upcoming release of 4.5 which would lock the implementation and

Re: [all] Thoughts on build system maven -> gradle??

-1 from me. I have a philosophical objection. Much like HTTP's mod_rewrite[1] gradle's greatest strength is that it allows the developer to do so much in so many ways. But its greatest weakness is that it allows the developer to do so much in so many ways. My experience with Ant and Gradle is

Re: [BloomFilters] changes to BloomFilter

I keep wondering if Bloom filters belong in Collections. They are not a collection in the standard sense of the word. Would it make more sense to spit it out as a new Commons project? How does one even go about that? On Wed, Apr 22, 2020 at 5:37 PM Alex Herbert wrote: > On Wed, 22 Apr 2020

Re: what became of beanshell in Apache commons?

I don't know for certain but here is what I piected together. The project currently resides at: https://github.com/beanshell/beanshell The documentation there says: BeanShell was proposed as an incubator project > to move to Apache >

Re: [BloomFilters] changes to BloomFilter

Bloom filters should not use generics. That has been my stated opinion. They are not like other collections in that you don't get out what you put in. They are collections of hashes so the idea that generics should be used to somehow define what goes in is misleading. If commons-collections is

Re: [BloomFilters] changes to BloomFilter

s to move the BloomFilter > API forward that consolidates the current functionality but makes it > simpler to use for the common case. > > > On 18 Mar 2020, at 17:12, Claude Warren wrote: > > > > bf.getBits() * Long.BYTES may be as long as Math.Ceil( > > Shape.getNumberOf

Re: [BloomFilters] changes to BloomFilter

of bit indexes (via OfInt) and there are ways to reconstruct a BloomFilter if you were to write that out and read it back. On Wed, Mar 18, 2020 at 4:07 PM Alex Herbert wrote: > > > > On 18 Mar 2020, at 14:39, Claude Warren wrote: > > > >>> Shape Discussion: >

Re: [BloomFilters] changes to BloomFilter

pe. It also may be longer. If you want to create a copy of the byte[] you have to know how long it should be. The only way to determine that is from Shape, and currently only if you do the Ceil() method noted above. There is a convenience in knowing how long (in bytes) the buffer can be. On

Re: [BloomFilters] changes to BloomFilter

Store values in long blocks or as integers in a list, that sort of thing. Perhaps in a month or so when we really have some idea. On Wed, Mar 18, 2020 at 2:16 PM Claude Warren wrote: > You don't need Iterator iterator() as we have forEachCount( > BitCountConsumer ) > > I guess we n

Re: [BloomFilters] changes to BloomFilter

:50 AM Alex Herbert wrote: > > > > On 18 Mar 2020, at 11:14, Claude Warren wrote: > > > > On a slightly different note. CountingBloomFilters have no way to > perform > > a reload. All other bloom filters you can dump the bits and reload > > (trivial) but

Re: [BloomFilters] changes to BloomFilter

somehow. On Tue, Mar 17, 2020 at 10:34 PM Claude Warren wrote: > Builder discussion: > > Let's go with > > >> Builder with(CharSequence, Charset); > >> Builder withUnencoded(CharSequence); > > Shape Discussion: > > as for getNumberOfBytes() it should ret

Re: [BloomFilters] changes to BloomFilter

with a Hasher, remove the duplicates, and perform the same test. I see no reason not to add them. On Tue, Mar 17, 2020 at 6:23 PM Alex Herbert wrote: > > > > On 17 Mar 2020, at 17:06, Claude Warren wrote: > > > > On Tue, Mar 17, 2020 at 4:38 PM Alex Herbert > > wrote:

Re: [BloomFilters] changes to BloomFilter

On Tue, Mar 17, 2020 at 4:38 PM Alex Herbert wrote: > > > > On 17 Mar 2020, at 15:41, Claude Warren wrote: > > > > I agree with the HashFunction changes. > > OK, but which ones? > DOH! this one... > > Changing HashFunction to have two methods: > >

Re: [BloomFilters] changes to BloomFilter

/pull/131 get merged so that we can have more than one example of a hasher that actually hashes. On Tue, Mar 17, 2020 at 1:53 PM Alex Herbert wrote: > > > > On 17 Mar 2020, at 11:08, Claude Warren wrote: > > > > On Tue, Mar 17, 2020 at 12:28 AM Alex Herbert <mail

Re: [BloomFilters] changes to BloomFilter

gt; In summary: > > 1. change Hasher getBits to iterator > agree > 2. improve documentation of Hasher and the contract that it should fulfil > with respect to items and a Shape > absolutly > 3. potentially drop Hasher.Builder unless there is a way to reset the > Builder or create more

Re: [BloomFilters] changes to BloomFilter

) will return the same values. Did I misunderstand something? Claude On Mon, Mar 16, 2020 at 6:34 PM Alex Herbert wrote: > > On 16/03/2020 07:57, Claude Warren wrote: > > I made a quick pass at changing getHasher() to iterator(). > > A look at the feasibility or hav

Re: [BloomFilters] changes to BloomFilter

an Iterator. On Sun, Mar 15, 2020 at 6:08 PM Alex Herbert wrote: > On Sun, 15 Mar 2020, 17:27 Claude Warren, wrote: > > > We have spoken elsewhere about removing getHasher() and adding iterator() > > In addition should we add forEachBit( IntConsumer )?I > > > I was think

[BloomFilters] changes to BloomFilter

We have spoken elsewhere about removing getHasher() and adding iterator() In addition should we add forEachBit( IntConsumer )? -- I like: Like Like - The likeliest place on the web LinkedIn: http://www.linkedin.com/in/claudewarren

Re: [collections] Bloom filters

ts. But bundling > the hash function identity and number of hash functions saves you having to > pass that separately to any Bloom filter and removes the requirement to > specify these separately in the Bloom filter interface. > > > > On Sat, 14 Mar 2020, 09:31 Claude Warren,

Re: [collections] Bloom filters

Shape is not intended to "Perform the standard computations using some of n, m, k, p to produce optimal values for the other values of n, m, k, p:" that is left to the developer to determine possibly with the help of https://hur.st/bloomfilter/ as referenced in the class javadoc. However, writing

Restart Build?

I have a pull request ( https://github.com/apache/commons-collections/pull/131) that failed due to an external connection being reset. Is there a way to restart the build without creating a new pull request or pushing to git? Claude -- I like: Like Like - The likeliest place on the web

Re: [collections] Bloom filters

With the upcoming change the StaticHash usage model has changed. It was serving two purposes: 1. as a mechanism to preserve the list of integers from the BloomFilter as well as the shape. 2. as a way to construct a Hasher from a collection of integers and a shape so that they could

Re: [collections] Bloom filters

:54 AM Alex Herbert wrote: > > On 02/03/2020 22:34, Claude Warren wrote: > > So what we have then is: > > > > *public* *interface* BloomFilter { > > > > *int* andCardinality(BloomFilter other); > > > > *int* cardinality(); &g

Re: [collections] Bloom filters

impacts the uses that I currently have. Shall we move forward? Claude On Mon, Mar 2, 2020 at 6:02 PM Alex Herbert wrote: > > On 02/03/2020 16:12, Claude Warren wrote: > > Does getCounts() return a snapshot of the values when the call was made > or > > does it return value

Re: [collections] Bloom filters

ks quickly as we turn bits on. Makes me think we might need to implement StandardBloomFilter to use long[] as well. Claude On Mon, Mar 2, 2020 at 1:12 PM Alex Herbert wrote: > > On 02/03/2020 11:32, Claude Warren wrote: > > my thought on changing the BloomFilter.merge() to retur

Re: [collections] Bloom filters

for the specific index. int getCount( int index ); With these methods It becomes possible to construct an iterator of int[] or Map.Entry or whatever else the developer wants. Claude On Mon, Mar 2, 2020 at 10:48 AM Alex Herbert wrote: > On 02/03/2020 09:38, Claude Warren wrote: > > It i

Re: [collections] Bloom filters

It is not too late to update the BloomFIlter interface to have the merge return a boolean. The incorrect Shape would still throw an exception, so the return value would only come into play if the bits could not be set. thoughts? On Mon, Mar 2, 2020 at 7:56 AM Claude Warren wrote

Re: [collections] Bloom filters

happy with a plain Iterator as the return. Claude On Mon, Mar 2, 2020 at 1:02 AM Alex Herbert wrote: > > > > On 1 Mar 2020, at 15:39, Claude Warren wrote: > > > > I think the CountingBloomFilter interface needs to extend BloomFilter. > > I said that but did no

Re: [collections] Bloom filters

: > > > > On 1 Mar 2020, at 09:28, Claude Warren wrote: > > > > The idea of a backing array is fine and the only problem I see with it is > > in very large filters (on the order of 10^8 bits and larger) but document > > the size calculation and let the developer worry about

Re: [collections] Bloom filters

with duplicate counting, but I am not certain of the validity of such a count and I fear that it muddies the waters with respect to what the CountingBloomFilter is counting. Claude On Sat, Feb 29, 2020 at 2:13 PM Alex Herbert wrote: > > > > On 29 Feb 2020, at 07:46, Claude Warren wrote:

Re: [collections] Bloom filters

Alex would you take a look at pull request 131 [1]. it adds a new hasher implementation and makes the HashFunctionValidator available for public use. https://github.com/apache/commons-collections/pull/131 On Tue, Feb 25, 2020 at 12:35 AM Alex Herbert wrote: > I have created a PR that contains

Re: [collections] Bloom filters

; } among other changes. Those were the changes I was referring to. Claude On Wed, Feb 19, 2020 at 11:33 PM Alex Herbert wrote: > > > > On 19 Feb 2020, at 21:14, Claude Warren wrote: > > > > I think the compromise solution of removing the thrown exception and &

Re: [collections] Bloom filters

18 Feb 2020, at 22:34, Gary Gregory wrote: > > > > On Tue, Feb 18, 2020 at 5:32 PM Claude Warren wrote: > > > >> Last one first, why a tree map? I think it is a holdover from an > earlier > >> implementation. It can be any reasonable Map (e.g. HashMap).

Re: [collections] Bloom filters

ices important? > > Or do you have some benchmarks to show that the TreeMap handles lots of > growth and shrinkage better than a HashMap. There are situations where > each one would be a better choice and so perhaps this is a case for > having a CountingBloomFilter with

Re: [collections] Bloom filters

On Tue, Feb 18, 2020 at 9:12 AM Alex Herbert wrote: > > My maths is rusty. If A=0xF000ABCD as interpreted as an unsigned and > > B=0xF000ABCD but interpreted as a signed does (A mod N) = (B mod N) for > all > > positive values of N? If so then you are correct and Signedness does not > >

Re: [collections] Bloom filters

On Mon, Feb 17, 2020 at 9:52 PM Alex Herbert wrote: > > > > On 17 Feb 2020, at 20:30, Claude Warren wrote: > > > > Alex, > > > > Thank you for your comments. > > > > See comments inline. > > > > > > > > On Mon, Feb 17, 20

Re: [collections] Bloom filters

Alex, Thank you for your comments. See comments inline. On Mon, Feb 17, 2020 at 3:20 PM Alex Herbert wrote: > I had a look through all the BloomFilter code. Thanks Claude for the > contribution. > > Some items that need clarifying: > > > 1. HashFunctionIdentity.Signedness > > This is not

Re: [collections] example code.

; > > garydgreg...@gmail.com> wrote: > > > > I think the simplest is to create an examples package under src/test > which > > also let you put example data under src/resources. > > > > This way, that code would get processed just like any other test code > > i

FOSDEM 2020

Is anyone on this list (besides me) planning on attending FOSDEM 2020[1]? If so would you be interested in hosting the Apache table? By "hosting" I mean we stand there talk to people and promote Apache commons. Claude [1] https://cwiki.apache.org/confluence/display/COMDEV/FOSDEM+2020 -- I

[collections] example code.

I see that there is no example code directory in the collections project. I was thinking of contributing an example of how to construct a Bloom filter that operates like the Hadoop Bloom filter but this seems like something that we may not want to include in the library. In the Jena project we

Re: [Collections] Bloom filters are in

Now to get some documentation done! On Sat, Jan 25, 2020 at 1:58 PM Gary Gregory wrote: > ... git master. Thank you Claude! > > Gary > -- I like: Like Like - The likeliest place on the web LinkedIn: http://www.linkedin.com/in/claudewarren

[collections] Bloom filter signature calculation

The HashFunctionIdentity.getSignature() method is intended to be used as in a quick comparison of a HashFunctionIdentities. As such it is supposed to encompass the name, signedness and process as well as some indication that the function implementation is the same as any other implementation of

Re: [collections] bloom filters comments

. Kinoshita wrote: > Sorry, I'd read Gary's reply as if there was no PR yet. Reviewed it a bit > now, lots of tests! Will play with the code and read the comments and > finish the review by the end of the week. > > Thanks Claude > > On Thursday, 9 January 2020, 11:20:40 a

Re: [collections] bloom filters comments

better if > there's some code to read along. And I am used to GitHub/GitLab diff > interface. > So I agree with Gary that this could be a good time for a PR (maybe a > draft one). > Bruno > > > On Thursday, 9 January 2020, 6:32:09 am NZDT, Claude Warren < > cla...@xenei.

Re: [collections] bloom filters comments

I believe the issue (I think history is at https://issues.apache.org/jira/browse/COLLECTIONS-728?page=com.atlassian.jira.plugin.system.issuetabpanels%3Acomment-tabpanel=17003600) is about the identification of hash implementations. Currently there are a couple of classes involved: Hasher

Re: [VOTE] Release Apache Commons Codec 1.14 based on RC1

I am not a PMC member but, I'll report any way +0 (non binding) *FindBug* issues show: MurmurHash3 case fall through issues. I believe these are expected and can be fixed with an annotation. Suggest release and fix in next update *CPD* issues shows private static long getLittleEndianLong(final

Re: [codec] release soon

o be to add a default > >>> block > >>> > for > >>> > >> the switch statement. > >>> > >> > >>> > > > >>> > > I'm OK to drop the code, or replace the AssewrtionError with an > >&

Re: [collections] bloom filters comments

It is currently a sub-class. There was a suggestion to move it outside of the BloomFilter interface. On Sun, Dec 29, 2019 at 3:47 PM Gilles Sadowski wrote: > Le dim. 29 déc. 2019 à 15:30, Claude Warren a écrit : > > > > If the Shape class (BloomFilter.Shape) is extracted from

  1   2   >