Re: TEXT-77 | String palindrome API

2017-06-21 Thread Bruno P. Kinoshita 
Palindromes (and other algorithms like De Bruijn graphs, lcs) are normally 
taught in most introductory bioinformatics courses. Not sure how much 
palindromes are used though. I know use cases for De Bruijn and lcs.

Maybe taking a look at BioJava could help - 
https://github.com/biojava/biojava-legacy/blob/a909c76131400e6f60048566e33a03f45da2f492/core/src/main/java/org/biojava/bio/molbio/RestrictionEnzyme.java#L291


Palindromes in bioinformatics are not normally used as in text processing. If 
we had tokenizers, then I think maybe we could identify palindromes in words, 
in sentences, and in proteins, though not entirely sure.

But would be good to find someone, maybe a bioinformatician, that could confirm 
if it would be useful, and give a few use cases, for that.

Cheers

Bruno

ps: BioJava is an interesting project, that could maybe someday use [text]. 
They already use [dbcp], [cli] (transitive from jmol I think), and [math]


From: Amey Jadiye 
To: Commons Developers List  
Sent: Thursday, 22 June 2017 3:51 PM
Subject: Re: TEXT-77 | String palindrome API



Hi,

With little research I found[1] we do have use cases for it like in biology
(I think Bruno might be referring the same fields for its application)

"Palindrome recognition is important in computational biology. Palindromic
structures can frequently be found in proteins and identifying them gives
researchers hints about the structure of nucleic acids. For example, in
nucleic acid secondary structure prediction, one is interested in
complementary palindromes which are considered in the full version."


[1]http://drops.dagstuhl.de/opus/volltexte/2014/4454/pdf/12.pdf

Regards,
Amey


On Jun 22, 2017 12:42 AM, "Emmanuel Bourg"  wrote:

> Le 21/06/2017 à 19:17, Amey Jadiye a écrit :
>
> > Though its very trivial to build, by any chance we should have palindrome
> > method in Apache Commons API ? there is nothing bad having this tool in
> > our arsenal, preferably in StringUtils ?
>
> Like sebb I fail to see the use case for this. Checking palindromes
> looks more like an academic exercise to me than a useful feature of a
> text oriented library.
>
> Emmanuel Bourg
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
> For additional commands, e-mail: dev-h...@commons.apache.org
>
>

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

Re: TEXT-77 | String palindrome API

2017-06-21 Thread Amey Jadiye 
Hi,

With little research I found[1] we do have use cases for it like in biology
(I think Bruno might be referring the same fields for its application)

"Palindrome recognition is important in computational biology. Palindromic
structures can frequently be found in proteins and identifying them gives
researchers hints about the structure of nucleic acids. For example, in
nucleic acid secondary structure prediction, one is interested in
complementary palindromes which are considered in the full version."


[1]http://drops.dagstuhl.de/opus/volltexte/2014/4454/pdf/12.pdf

Regards,
Amey

On Jun 22, 2017 12:42 AM, "Emmanuel Bourg"  wrote:

> Le 21/06/2017 à 19:17, Amey Jadiye a écrit :
>
> > Though its very trivial to build, by any chance we should have palindrome
> > method in Apache Commons API ? there is nothing bad having this tool in
> > our arsenal, preferably in StringUtils ?
>
> Like sebb I fail to see the use case for this. Checking palindromes
> looks more like an academic exercise to me than a useful feature of a
> text oriented library.
>
> Emmanuel Bourg
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
> For additional commands, e-mail: dev-h...@commons.apache.org
>
>

Re: [CLI] Changing the code style

2017-06-21 Thread Gary Gregory 
On Fri, Jun 16, 2017 at 1:50 AM, Benedikt Ritter  wrote:

> Hi,
>
> CLI unlike other components has a custom code style. While other
> components pretty much follow the Sun code guidelines, the CLI code base
> uses a style like the Maven project. For me it’s annoying the switch code
> style configurations between components. If nobody objects, I’d like to
> apply the same rules like we have them in lang or text. I’m also going to
> enforce this rules using checkstyle and will make checkstyle part of the
> Travis CI build.
>

+1

Gary


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

Re: TEXT-77 | String palindrome API

2017-06-21 Thread Rob Tompkins 


> On Jun 21, 2017, at 3:22 PM, Gary Gregory  wrote:
> 
> On Jun 21, 2017 12:12, "Emmanuel Bourg"  wrote:
> 
>> Le 21/06/2017 à 19:17, Amey Jadiye a écrit :
>> 
>> Though its very trivial to build, by any chance we should have palindrome
>> method in Apache Commons API ? there is nothing bad having this tool in
>> our arsenal, preferably in StringUtils ?
> 
> Like sebb I fail to see the use case for this. Checking palindromes
> looks more like an academic exercise to me than a useful feature of a
> text oriented library.

I can see this point fairly clearly, but I also would also be curious to see if 
openNLP or lucene/solr has such a function. It wouldn't surprise me.

That being said, we should indeed be careful about creating code with no 
obvious use case. So until we can unearth folks doing palindromic operations 
let's hold off. I do recall Bruno saying he might have some use cases though. 

-Rob

> 
> +1.
> 
> Gary
> 
> 
> Emmanuel Bourg
> 
> -
> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
> For additional commands, e-mail: dev-h...@commons.apache.org

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

Fwd: svn commit: r1799506 - in /commons/proper/configuration/trunk/src/site/xdoc: dependencies.xml userguide/howto_hierarchical.xml

2017-06-21 Thread Gary Gregory 
Why use an old version of Jackson?

Gary
-- Forwarded message --
From: 
Date: Jun 21, 2017 13:01
Subject: svn commit: r1799506 - in
/commons/proper/configuration/trunk/src/site/xdoc: dependencies.xml
userguide/howto_hierarchical.xml
To: 
Cc:

Author: oheger
> Date: Wed Jun 21 20:01:07 2017
> New Revision: 1799506
>
> URL: http://svn.apache.org/viewvc?rev=1799506=rev
> Log:
> [CONFIGURATION-258] Some documentation for new configuration classes.
>
> Listed special dependencies for JSON and YAML Configuration.
>
> Modified:
> commons/proper/configuration/trunk/src/site/xdoc/dependencies.xml
> commons/proper/configuration/trunk/src/site/xdoc/userguide/
> howto_hierarchical.xml
>
> Modified: commons/proper/configuration/trunk/src/site/xdoc/
> dependencies.xml
> URL: http://svn.apache.org/viewvc/commons/proper/configuration/
> trunk/src/site/xdoc/dependencies.xml?rev=1799506&
> r1=1799505=1799506=diff
> 
> ==
> --- commons/proper/configuration/trunk/src/site/xdoc/dependencies.xml
> (original)
> +++ commons/proper/configuration/trunk/src/site/xdoc/dependencies.xml Wed
> Jun 21 20:01:07 2017
> @@ -68,6 +68,14 @@
>  commons-codec
>  
>  
> +JSONConfiguration
> +com.fasterxml.jackson.
> core:jackson-databind
> +
> +
> +YAMLConfiguration
> +org.yaml:snakeyaml
> +
> +
>  ConfigurationDynaBean
>  commons-beanutils
>  
>
> Modified: commons/proper/configuration/trunk/src/site/xdoc/userguide/
> howto_hierarchical.xml
> URL: http://svn.apache.org/viewvc/commons/proper/configuration/
> trunk/src/site/xdoc/userguide/howto_hierarchical.xml?rev=
> 1799506=1799505=1799506=diff
> 
> ==
> --- 
> commons/proper/configuration/trunk/src/site/xdoc/userguide/howto_hierarchical.xml
> (original)
> +++ 
> commons/proper/configuration/trunk/src/site/xdoc/userguide/howto_hierarchical.xml
> Wed Jun 21 20:01:07 2017
> @@ -54,6 +54,10 @@
>  INIConfiguration
>  
>  PropertyListConfiguration
> +
> +JSONConfiguration
> +
> +YAMLConfiguration
>
>  
>
>
>
>

Re: TEXT-77 | String palindrome API

2017-06-21 Thread Gary Gregory 
On Jun 21, 2017 12:12, "Emmanuel Bourg"  wrote:

Le 21/06/2017 à 19:17, Amey Jadiye a écrit :

> Though its very trivial to build, by any chance we should have palindrome
> method in Apache Commons API ? there is nothing bad having this tool in
> our arsenal, preferably in StringUtils ?

Like sebb I fail to see the use case for this. Checking palindromes
looks more like an academic exercise to me than a useful feature of a
text oriented library.


+1.

Gary


Emmanuel Bourg

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

Re: TEXT-77 | String palindrome API

2017-06-21 Thread Emmanuel Bourg 
Le 21/06/2017 à 19:17, Amey Jadiye a écrit :

> Though its very trivial to build, by any chance we should have palindrome
> method in Apache Commons API ? there is nothing bad having this tool in
> our arsenal, preferably in StringUtils ?

Like sebb I fail to see the use case for this. Checking palindromes
looks more like an academic exercise to me than a useful feature of a
text oriented library.

Emmanuel Bourg

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

TEXT-77 | String palindrome API

2017-06-21 Thread Amey Jadiye 
Hi All,

Though its very trivial to build, by any chance we should have palindrome
method in Apache Commons API ? there is nothing bad having this tool in
our arsenal, preferably in StringUtils ?

https://issues.apache.org/jira/browse/TEXT-77

Regards,
Amey

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

[GitHub] commons-text pull request #52: Test: Improved testcase coverage for StrBuild...

2017-06-21 Thread asfgit 
Github user asfgit closed the pull request at:

https://github.com/apache/commons-text/pull/52


---
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 feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

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

[GitHub] commons-text issue #52: Test: Improved testcase coverage for StrBuilder

2017-06-21 Thread chtompki 
Github user chtompki commented on the issue:

https://github.com/apache/commons-text/pull/52
  
Thanks Amey.


---
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 feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

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

[text] Re: CharSequence vs. String (was Re: [GitHub] commons-text pull request #46: TEXT-85:Added CaseUtils class with camel case...)

2017-06-21 Thread Bruno P. Kinoshita 
>If a method doesn't intrinsically require a String, then I prefer
CharSequence. It's probable that sooner or later something is going to
demand a String, but that's not a good reason to be "that guy" :-)
I lean towards using CharSequence when that makes sense too (i.e. suggesting we 
are working on code points, and supporting implementations of charsequence). 
The tdebatty/java-string-similarity library work only Strings I think. Others 
like LingPipe, ICU4J, Lucene, Apache Commons Text, and Apache OpenNLP use both 
CharSequence and String.

Analysing the use of CharSequence and String could be an interesting idea for a 
blog post, and could even raise some tickets to fix consistency in the API of 
[text] or some other component/project.

>Also, wouldn't  some sort of low-space-overhead string storage be a good fit 
>for text?

Sounds interesting. Normally when I have some idea like that for [text] (or for 
other projects/components) I either note it down somewhere (normally first at 
http://kinoshita.eti.br/todo/), and then file an issue like TEXT-71, TEXT-77, 
TEXT-78, or TEXT-79, to start investigating it.

If you have some idea of how that could be implemented, or know about some 
projects for that, feel free to suggest it in a JIRA ticket, or start another 
thread here in the mailing list.

Cheers
Bruno



From: Simon Spero 
To: Commons Developers List  
Sent: Tuesday, 20 June 2017 1:39 AM
Subject: CharSequence vs. String (was Re: [GitHub] commons-text pull request 
#46: TEXT-85:Added CaseUtils class with camel case...)



On Jun 12, 2017 10:47 AM, "arunvinudss"  wrote:


Github user arunvinudss commented on a diff in the pull request:


I am a bit biased towards using String instead of CharSequence . Yes

CharSequence allows us to pass String Buffers and builders and other types

as input potentially increasing the scope of the function but considering

the nature of work we do in this particular method it may not necessarily

be a good idea. My basic contention is that the minute we call toString()

on a charSequence  to do any sort of manipulation it becomes a costly

operation and we may lose performance .



True if the particular CharSequence is not in fact an instance of String.

String::toString returns this.


The bigger problem is that too many methods use String as a parameter or

return type, when  CharSequence would serve just as well. This indeed

requires the invocation of Object::toString.


For methods that use String as the return type, changing the result to

CharSequence is source and binary incompatible, and properly so (since at

some point the user may actually need a String).


A  generic method with Type parameter with CharSequence as bound (T extends

CharSequence) can sometimes be useful, and can be added in addition to

methods taking String arguments, but can't replace them.


There are some places in javac that have special treatment for String - for

example, the + operator , but jdk9 reduces that particular win by indyfying

concat.

If a method doesn't intrinsically require a String, then I prefer

CharSequence. It's probable that sooner or later something is going to

demand a String, but that's not a good reason to be "that guy" :-)


Note:

Strings can be an incredible waste of memory; 40 +  ⌈length/4⌉  bytes

(reduced to a mere  40 + ⌈length/8⌉ bytes in jdk9 when compact strings can

be used).


This is incredibly painful if you have a vast number of small "strings",

which may not all need to be materialized simultaneously. See e.g. [1]

(~50MiB of UTF-8 chars becomes ~250MiB of Strings. And since there's no

individual humongous object  they all get to make the journey from TLAB to

Old Space the hard way. Note this predates jdk 9,but illustrates some of

the win from compact strings)


Storing the character data in a shared byte array is a huge win. Someone

should tell the jdk implementors to look at applications that do this.

Like, um, javac :-)


Materializing these strings as possibly transient  CharSequence's  is

really convenient... until some method just has to have a String


Also, wouldn't  some sort of low-space-overhead string storage be a good

fit for text?


Simon

[1]  Spero,S. (2015). Time And Relative Dimensions In Semantics: Is OWL

Bigger On The Inside? OWLED 2015. Available at

http://cgi.csc.liv.ac.uk/~valli/OWLED2015/OWLED_2015_paper_12.pdf

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

[GitHub] commons-text issue #52: Test: Improved testcase coverage for StrBuilder

2017-06-21 Thread kinow 
Github user kinow commented on the issue:

https://github.com/apache/commons-text/pull/52
  
Looking good! :+1: 


---
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 feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

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

Re: OSGi Version at Package Level

2017-06-21 Thread Bernd Eckenfels 
Hello,

Just a pointer, those constraints come in handy when you plan to have OSGi do. 
the final resolving of actual deployed systems as well. It might not be your 
cup of coffee but I recommend the modularity talk of Peter Kriens 2016 at the 
modconf in Darmstadt: https://youtu.be/VwD0pYNOvFQ to get a radically different 
view.

(But Imagree with others that for most commons projects (especially tools 
libraries) there is not much benefit for having package versions different from 
bundle versions. Especially not since there is no overall OSGi theme going on.)

Gruss
Bernd
--
http://bernd.eckenfels.net

From: Bertrand Delacretaz 
Sent: Wednesday, June 21, 2017 9:03:28 AM
To: Commons Developers List
Subject: Re: OSGi Version at Package Level

On Wed, Jun 21, 2017 at 12:08 AM, Simon Spero  wrote:
> Bundles can specify all sorts of Requirements, including implementations,
> and bugfix version ranges...It can be a
> little too expressive :-)...

Yes, in the OSGi projects where I'm involved we avoid these things as
they create more coupling than we like.

When working in that way, getting the right implementations is a
deployment concern, and the OSGi framework "just" makes sure
everything that's deployed is compatible at the API level.

-Bertrand

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

[GitHub] commons-text issue #52: Test: Improved testcase coverage for StrBuilder

2017-06-21 Thread ameyjadiye 
Github user ameyjadiye commented on the issue:

https://github.com/apache/commons-text/pull/52
  
Cool, seems clean now :+1: thanks Pascal. Trick will be certainly 
beneficial in future to me 😉 


---
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 feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

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

[GitHub] commons-text issue #52: Test: Improved testcase coverage for StrBuilder

2017-06-21 Thread PascalSchumacher 
Github user PascalSchumacher commented on the issue:

https://github.com/apache/commons-text/pull/52
  
Thanks. I was not as easy as I expected (I had to merge).

I followed these steps:

`git rebase -i head~5`

Edit the rebase-todo-to to contain:
```
drop 06e8b3d test: Improved testcase coverage for StrBuilder
drop  27e110b revert to master
pick d23bd1d Test: Improved testcase coverage for StrBuilder
squash 242ad5e Style fixes for StrBuilderTest
pick 31a5cd1 Fixed formatting for StrBuilder
```

Edit merge conflict.

`git rebase --continue`

Editmerge conflicts (nothing to do, just confirm merge was good).

`git rebase --continue`

`push -f`

Please remove my access to the repository. Thanks!


---
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 feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

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

[GitHub] commons-text issue #52: Test: Improved testcase coverage for StrBuilder

2017-06-21 Thread coveralls 
Github user coveralls commented on the issue:

https://github.com/apache/commons-text/pull/52
  

[![Coverage 
Status](https://:/builds/12062509/badge)](https://:/builds/12062509)

Coverage increased (+0.4%) to 97.317% when pulling 
**eb25d61ca6bd845815bb30feb2ba0cf9f6e106ff on ameyjadiye:test-StrBuilder** into 
**9f6e5e45e925511d0fdbf59bb264aafa6b91f997 on apache:master**.



---
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 feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

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

Re: OSGi Version at Package Level

2017-06-21 Thread Bertrand Delacretaz 
On Wed, Jun 21, 2017 at 12:08 AM, Simon Spero  wrote:
> Bundles can specify all sorts of Requirements, including implementations,
> and bugfix version ranges...It can be a
> little too expressive :-)...

Yes, in the OSGi projects where I'm involved we avoid these things as
they create more coupling than we like.

When working in that way, getting the right implementations is a
deployment concern, and the OSGi framework "just" makes sure
everything that's deployed is compatible at the API level.

-Bertrand

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