[jira] [Commented] (TEXT-45) WordUtils delimiters should be strings, not char varargs

2017-01-22 Thread Pascal Schumacher (JIRA)

[ 
https://issues.apache.org/jira/browse/TEXT-45?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15833376#comment-15833376
 ] 

Pascal Schumacher commented on TEXT-45:
---

I believe this issue is still valid. WordUtils was temporary removed from 
commons-text to allow for a 1.0 release while [~dmjones500] is refactoring it.

> WordUtils delimiters should be strings, not char varargs
> 
>
> Key: TEXT-45
> URL: https://issues.apache.org/jira/browse/TEXT-45
> Project: Commons Text
>  Issue Type: Improvement
>Reporter: Andrew Pennebaker
>Priority: Minor
>  Labels: api,, interface,ease,of,use,, robustness,
> Fix For: 1.1
>
>
> Strings behave like char varargs of arbitrary length, but are much easier to 
> use.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)


[jira] [Resolved] (MATH-959) Add HAC clustering algorithm

2017-01-22 Thread Thomas Neidhart (JIRA)

 [ 
https://issues.apache.org/jira/browse/MATH-959?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Thomas Neidhart resolved MATH-959.
--
   Resolution: Won't Fix
Fix Version/s: (was: 4.0)

> Add HAC clustering algorithm
> 
>
> Key: MATH-959
> URL: https://issues.apache.org/jira/browse/MATH-959
> Project: Commons Math
>  Issue Type: Sub-task
>Reporter: Thomas Neidhart
>Assignee: Thomas Neidhart
> Attachments: MATH-748.zip
>
>
> Add at least one hierarchical clustering algorithm.
> With the refactoring of the clustering package, this should now be feasible 
> as the Cluster class can be extended.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)


[jira] [Commented] (COMPRESS-207) add notifier support for new block in BZip2CompressorInputStream

2017-01-22 Thread Thomas Meyer (JIRA)

[ 
https://issues.apache.org/jira/browse/COMPRESS-207?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15833469#comment-15833469
 ] 

Thomas Meyer commented on COMPRESS-207:
---

Hi,

I did some generalization work here 
https://github.com/thomasmey/commons-compress/commits/work/compress207
feel free to have a look at this.

> add notifier support for new block in BZip2CompressorInputStream
> 
>
> Key: COMPRESS-207
> URL: https://issues.apache.org/jira/browse/COMPRESS-207
> Project: Commons Compress
>  Issue Type: New Feature
>  Components: Compressors
>Affects Versions: 1.4.1
>Reporter: Thomas Meyer
>Priority: Minor
>  Labels: API, bzip
> Attachments: 
> 0001-Add-notifier-support-for-new-block-in-BZip2Compresso.patch, 
> BZip2CompressorInputStream-add-newBlock-notifier.patch, 
> BZip2CompressorInputStream-add-newBlock-notifier.patch, 
> BZip2CompressorInputStream-add-newBlock-notifier.patch
>
>
> hi,
> attached patch enables an program to add a listener when a new bzip2
> block is detected.
> The notifier is called with:
>  - xxx.newBlock(this, currBlockPosition)
> - this = the current BZip2CompressorInputStream object
> - currBlockPosition = The offset (i.e. start position) in the compressed
> input stream of the current block



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)


[jira] [Commented] (COMMONSRDF-51) RDF-1.1 specifies that language tags need to be compared using lower-case

2017-01-22 Thread ASF GitHub Bot (JIRA)

[ 
https://issues.apache.org/jira/browse/COMMONSRDF-51?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15833531#comment-15833531
 ] 

ASF GitHub Bot commented on COMMONSRDF-51:
--

Github user stain commented on the issue:

https://github.com/apache/commons-rdf/pull/30
  
OK, so then it makes sense for the Commons RDF tests to only care about the
value being preserved (whatever the case going in or out is upper or
lower), and that our .equals and .hashCode is based on lowercase in the
ROOT Locale.

We don't have equivalent tests if datatyped floats etc preserve their
specific syntactic value (e.g. "-.0"^^xsd:float) so we should not do that
for langtags either.

I'll modify the branch and merge.

On 21 Jan 2017 9:39 pm, "Andy Seaborne"  wrote:

> RDF 1.1 mentions:
>
>1. Turtle parsing - there is a lang tag rule.
>2. The text that conversion to a lowercase lexical is allowed.
>3. Value-comparison is case insensitive.
>
> Which is that test for? Lexical or value?
>
> At least acknowledging that RDF's "lowercase" is not in keeping with BCP
> 47 syntax canonicalization (the registry may change the characters)
> whatever the spec makes sense to me and I suspect domain experts; it's
> following the spec that "owns" language tags. Focus on the value 
comparison.
>
> —
> You are receiving this because you authored the thread.
> Reply to this email directly, view it on GitHub
> ,
> or mute the thread
> 

> .
>



> RDF-1.1 specifies that language tags need to be compared using lower-case
> -
>
> Key: COMMONSRDF-51
> URL: https://issues.apache.org/jira/browse/COMMONSRDF-51
> Project: Apache Commons RDF
>  Issue Type: Bug
>  Components: api
>Affects Versions: 0.3.0
>Reporter: Peter Ansell
>Assignee: Stian Soiland-Reyes
>
> The [RDF-1.1 specification states that the [value space of Literal language 
> tags is 
> lowercase|https://www.w3.org/TR/rdf11-concepts/#section-Graph-Literal], which 
> does not conflict with the case-insensitive specification in BCP47. The 
> Literal.equals and Literal.hashCode API contracts should specify that 
> language tags must be compared using lowercase, even if they are otherwise 
> stored and returned as upper-case by getLanguageTag. The API currently has 
> incorrect language by saying "character-by-character" for language tag 
> comparisons, as that implies case-sensitive comparisons are used.
> The lowercasing must also be done using a locale that is consistent (known 
> example where lowercase and uppercase do not roundtrip as expected for 
> US-ASCII characters is Turkish [1]), so I would recommend actually stating 
> that .toLowerCase(Locale.ENGLISH) is used.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)


[jira] [Commented] (COMPRESS-207) add notifier support for new block in BZip2CompressorInputStream

2017-01-22 Thread Stefan Bodewig (JIRA)

[ 
https://issues.apache.org/jira/browse/COMPRESS-207?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15833932#comment-15833932
 ] 

Stefan Bodewig commented on COMPRESS-207:
-

Thanks a lot, I've added a few inline comments but am afraid I won't get 
notified if you update your branch. I'm not sure what the best workflow may be 
right now, to be honest.

Your changes look good but may need to get expanded beyond bzip2 and gzip. Also 
I'm not sure whether block is the correct term as in the gzip case you use it 
for streams.


> add notifier support for new block in BZip2CompressorInputStream
> 
>
> Key: COMPRESS-207
> URL: https://issues.apache.org/jira/browse/COMPRESS-207
> Project: Commons Compress
>  Issue Type: New Feature
>  Components: Compressors
>Affects Versions: 1.4.1
>Reporter: Thomas Meyer
>Priority: Minor
>  Labels: API, bzip
> Attachments: 
> 0001-Add-notifier-support-for-new-block-in-BZip2Compresso.patch, 
> BZip2CompressorInputStream-add-newBlock-notifier.patch, 
> BZip2CompressorInputStream-add-newBlock-notifier.patch, 
> BZip2CompressorInputStream-add-newBlock-notifier.patch
>
>
> hi,
> attached patch enables an program to add a listener when a new bzip2
> block is detected.
> The notifier is called with:
>  - xxx.newBlock(this, currBlockPosition)
> - this = the current BZip2CompressorInputStream object
> - currBlockPosition = The offset (i.e. start position) in the compressed
> input stream of the current block



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)