[jira] [Commented] (COMMONSRDF-49) Make AbstractRDFParser serializable

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on COMMONSRDF-49:
--

Github user stain commented on the issue:

https://github.com/apache/commons-rdf/pull/43
  
You may have better ideas on how to do something like 
[ParserConfigImpl](https://github.com/apache/commons-rdf/blob/fluent-parser/commons-rdf-api/src/main/java/org/apache/commons/rdf/api/io/ParserConfigImpl.java)
 so it is serializable.  For instance the 
[ParserSource](https://github.com/apache/commons-rdf/blob/fluent-parser/commons-rdf-api/src/main/java/org/apache/commons/rdf/api/io/ParserSource.java)
 beans might or might not be serializable depending on the implementation.

(Surely one that is just connected to an open InputStream is not 
serializable, but one that has just got an IRI should be serializable. I made 
the implementations package private: 
[IRIParserSource](https://github.com/apache/commons-rdf/blob/fluent-parser/commons-rdf-api/src/main/java/org/apache/commons/rdf/api/io/IRIParserSource.java)
 which meant I had to make a new 
[IRIImpl](https://github.com/apache/commons-rdf/blob/fluent-parser/commons-rdf-api/src/main/java/org/apache/commons/rdf/api/io/IRIImpl.java)
 to avoid Simple dependency)


> Make AbstractRDFParser serializable
> ---
>
> Key: COMMONSRDF-49
> URL: https://issues.apache.org/jira/browse/COMMONSRDF-49
> Project: Apache Commons RDF
>  Issue Type: New Feature
>  Components: simple
>Affects Versions: 0.3.0
>Reporter: Stian Soiland-Reyes
>Assignee: Stian Soiland-Reyes
>Priority: Major
>  Labels: parser
> Fix For: 0.6.0
>
>
> Raised by [~p_ansell] in [pull request 
> 25|(https://github.com/apache/incubator-commonsrdf/pull/25#discussion_r85436754]
> {quote}
> The use of optional here as a field type makes it impossible to serialise. 
> Need to have the raw values stored in fields if you want to support 
> serialisation in the future, which should otherwise be possible.
> {quote}
> The suggestion is to avoid {{Optional}} in the private fields of 
> {{AbstractRDFParser}} so it can be serialized - it can still be {{Optional}} 
> in the accessor methods.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Commented] (COMMONSRDF-49) Make AbstractRDFParser serializable

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on COMMONSRDF-49:
--

Github user stain commented on the issue:

https://github.com/apache/commons-rdf/pull/43
  
Thanks, @ajs6f !

I found some old code where I had tried to make a fluent interface.. I 
managed to update it to the current master and sorted some issues.

I pushed it to the `fluent-parser` branch

See https://github.com/apache/commons-rdf/compare/fluent-parser 

I haven't implemented the `Parser` yet or written any tests.

Basically the idea is this:

```java
  Parsed p = rdf.parserBuilder()
  .syntax(RDFSyntax.JSONLD)
  .source("http://example.com/data.jsonld;)
  .parse();
```

or:

```java
rdf.parserBuilder()
  .syntax(RDFSyntax.TURTLE)
  .target(quad -> System.out.println(quad.getSubject()))  
  .source(Paths.get("/tmp/file.ttl").
  .async().parseAsync();
```

Now there is a set of interfaces, one for each step along the way, e.g. 
`NeedTarget`, and 
some internal `_` package interfaces to ensure consistency (but this can be 
flattened). Note that it is easier in this code to explore this in Eclipse with 
auto-complete as the interfaces have not been flattened yet.

It is implemented by a single `AbstractParserBuilder` which keeps all its 
state (except async executor) in a `ParserConfig` bean. The builder can be made 
immutable using `.build()` after which any change will make it mutable again.  
While it's mutable it will mutate the bean without any copies.

There is also a more low-level `Parser` which takes a `ParserConfig` - this 
is basically how the RDF implementations can be invoked.

I have not moved over the preflight checks in AbstractRDFParser there.

Feel free to use it as a starting ground or inspiration! It's quite hard to 
do fluent interfaces..


> Make AbstractRDFParser serializable
> ---
>
> Key: COMMONSRDF-49
> URL: https://issues.apache.org/jira/browse/COMMONSRDF-49
> Project: Apache Commons RDF
>  Issue Type: New Feature
>  Components: simple
>Affects Versions: 0.3.0
>Reporter: Stian Soiland-Reyes
>Assignee: Stian Soiland-Reyes
>Priority: Major
>  Labels: parser
> Fix For: 0.6.0
>
>
> Raised by [~p_ansell] in [pull request 
> 25|(https://github.com/apache/incubator-commonsrdf/pull/25#discussion_r85436754]
> {quote}
> The use of optional here as a field type makes it impossible to serialise. 
> Need to have the raw values stored in fields if you want to support 
> serialisation in the future, which should otherwise be possible.
> {quote}
> The suggestion is to avoid {{Optional}} in the private fields of 
> {{AbstractRDFParser}} so it can be serialized - it can still be {{Optional}} 
> in the accessor methods.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Commented] (MATH-1450) PolygonsSet sets incorrect value for last vertex in open loops

[Matt Juntunen (JIRA)]

[ 
https://issues.apache.org/jira/browse/MATH-1450?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16365049#comment-16365049
 ] 

Matt Juntunen commented on MATH-1450:
-

I've updated the pull request listed above with the extra tests. I'm not sure 
what "else" branch you're referring to, though.

> PolygonsSet sets incorrect value for last vertex in open loops
> --
>
> Key: MATH-1450
> URL: https://issues.apache.org/jira/browse/MATH-1450
> Project: Commons Math
>  Issue Type: Bug
>Affects Versions: 4.0, 3.5, 3.6
>Reporter: Matt Juntunen
>Priority: Major
> Fix For: 4.0
>
>
> According to the documentation, for open infinite vertex loops returned by 
> the PolygonsSet.getVertices() method, the last two points can be used to 
> determine the direction of the last edge in the loop. However, the current 
> code returns a point from the second-to-last edge. For example, the code 
> below builds a box open on the top. It currently returns the vertex loop 
> [null, \{0; 1}, \{0; 0}, \{1; 0}, \{1; 0}], where the last two vertices are 
> the same point and cannot be used to determine the direction of the last 
> edge. The returned vertex loop should be [null, \{0; 1}, \{0; 0}, \{1; 0}, 
> \{1; 1}].
> {code:java}
> Cartesian2D v0 = new Cartesian2D(0, 1);
>     Cartesian2D v1 = new Cartesian2D(0, 0);
>     Cartesian2D v2 = new Cartesian2D(1, 0);
>     Cartesian2D v3 = new Cartesian2D(1, 1);
>     Line left = new Line(v0, v1, 1e-10);
>     Line bottom = new Line(v1, v2, 1e-10);
>     Line right = new Line(v2, v3, 1e-10);
>     List boundaries = new ArrayList<>();
>     boundaries.add(new SubLine(left, new 
> IntervalsSet(left.toSubSpace(v0).getX(), left.toSubSpace(v1).getX(), 1e-10)));
>     boundaries.add(new SubLine(bottom, new 
> IntervalsSet(bottom.toSubSpace(v1).getX(), bottom.toSubSpace(v2).getX(), 
> 1e-10)));
>     boundaries.add(new SubLine(right, new 
> IntervalsSet(right.toSubSpace(v2).getX(), right.toSubSpace(v3).getX(), 
> 1e-10)));
>     PolygonsSet polygon = new PolygonsSet(boundaries, 1e-10);
>     polygon.getVertices();{code}
>   
>  
> Pull Request: [https://github.com/apache/commons-math/pull/81]



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Created] (NET-657) Reverse tethering support

[Grzegorz Ostrowski (JIRA)]

Grzegorz Ostrowski created NET-657:
--

 Summary: Reverse tethering support
 Key: NET-657
 URL: https://issues.apache.org/jira/browse/NET-657
 Project: Commons Net
  Issue Type: New Feature
  Components: FTP
Affects Versions: 3.6
Reporter: Grzegorz Ostrowski


I am using your library to upload photos in android app. When device uses Wi-Fi 
everything is fine, photos are uploaded to FTP server. But my customer wants 
this app to be able to do the same when Wi-Fi in app is turned off and device 
gets net from personal computer(Windows) connected to the device via USB cable. 
I was able to connect device using "gnirehtet":

https://medium.com/genymobile/gnirehtet-reverse-tethering-android-2afacdbdaec7

When I use gnirehtet my app uploads only firsth photo to FTP server and hangs 
on getting reply code at the end of "_storeFile" function in FTPClient class of 
AppacheCommonsNet. When I use WiFi everything is ok, the problem is only when I 
use reverse tethering. I checked other reverse thetering solutions and I met 
the same problem.
 
 
Maybe I do something wrong but I think that your library may not support 
reverse tethering. Could you consider expanding your library with support for 
reverse tethering?



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Commented] (MATH-1451) Infinite loop for CycleCrossover with duplicates

[Gabriele Rossi (JIRA)]

[ 
https://issues.apache.org/jira/browse/MATH-1451?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16364687#comment-16364687
 ] 

Gabriele Rossi commented on MATH-1451:
--

Hi Gilles, thank you for clarification, sounds good. Sent an e-mail to "dev" ML.

> Infinite loop for CycleCrossover with duplicates
> 
>
> Key: MATH-1451
> URL: https://issues.apache.org/jira/browse/MATH-1451
> Project: Commons Math
>  Issue Type: Bug
>Affects Versions: 3.6.1
> Environment: Home PC
>Reporter: Gabriele Rossi
>Priority: Major
> Attachments: test-apache-math3.zip
>
>
> I've found an infinite loop when recombining two integers Chromosomes 
> admitting duplicates with CycleCrossover class.
> For example, recombining example Chromosomes it works fine, but, if you 
> substitute all "8" with "7", you run into an infinite loop while mating.
> I attach the self-contained unit test (JUnit) for a better comprehension 
> (issue a mvn clean install to run).
> I added a little quick patch to fix, which I'm happy to provide, even could 
> be less efficient than original.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Updated] (RNG-44) Invalid links on web site

[Gilles (JIRA)]

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

Gilles updated RNG-44:
--
Fix Version/s: (was: 1.1)

> Invalid links on web site
> -
>
> Key: RNG-44
> URL: https://issues.apache.org/jira/browse/RNG-44
> Project: Commons RNG
>  Issue Type: Bug
>Reporter: Gilles
>Priority: Minor
>  Labels: web-site
>
> On [that 
> page|http://commons.apache.org/proper/commons-rng/commons-rng-client-api/source-repository.html]
>  (and similar for the other maven modules), the "Web Browser Access" link 
> points to a non-existing project (because the module name is appended to the 
> URL of the git repository).



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Updated] (RNG-48) Prepare next release (v1.1)

[Gilles (JIRA)]

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

Gilles updated RNG-48:
--
Description: 
(/) Clirr: Please provide feedback in [this ML 
thread|http://markmail.org/message/24t4v2bsh5x366fe]
(/) JDK 9 ready? (!) Should be revisited (cf. RNG-40)
(x) Modular component: Use new release plugin?

  was:
(/) Clirr: Please provide feedback in [this ML 
thread|http://markmail.org/message/24t4v2bsh5x366fe]
(x) JDK 9 ready?
(x) Modular component: Use new release plugin?


> Prepare next release (v1.1)
> ---
>
> Key: RNG-48
> URL: https://issues.apache.org/jira/browse/RNG-48
> Project: Commons RNG
>  Issue Type: Task
>Reporter: Gilles
>Priority: Minor
>  Labels: distribution, jdk9, release
> Fix For: 1.1
>
>
> (/) Clirr: Please provide feedback in [this ML 
> thread|http://markmail.org/message/24t4v2bsh5x366fe]
> (/) JDK 9 ready? (!) Should be revisited (cf. RNG-40)
> (x) Modular component: Use new release plugin?



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Resolved] (RNG-40) Ready for JDK 9 ?

[Gilles (JIRA)]

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

Gilles resolved RNG-40.
---
Resolution: Works for Me

> Ready for JDK 9 ?
> -
>
> Key: RNG-40
> URL: https://issues.apache.org/jira/browse/RNG-40
> Project: Commons RNG
>  Issue Type: Sub-task
>Reporter: Gilles
>Priority: Major
>  Labels: java9
> Fix For: 1.1
>
>
> Cf. [this post|http://markmail.org/message/j7ki3x67kd2kpavj] on the ML.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Commented] (RNG-40) Ready for JDK 9 ?

[Gilles (JIRA)]

[ 
https://issues.apache.org/jira/browse/RNG-40?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16364679#comment-16364679
 ] 

Gilles commented on RNG-40:
---

bq. add to the release notes that the core package should not be used directly 
in applications

commit 22ca66d5b0cb54e587de2dd8456e1ef8f87dbd44

> Ready for JDK 9 ?
> -
>
> Key: RNG-40
> URL: https://issues.apache.org/jira/browse/RNG-40
> Project: Commons RNG
>  Issue Type: Sub-task
>Reporter: Gilles
>Priority: Major
>  Labels: java9
> Fix For: 1.1
>
>
> Cf. [this post|http://markmail.org/message/j7ki3x67kd2kpavj] on the ML.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Commented] (TEXT-25) Add a duration parser

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on TEXT-25:


Github user asfgit closed the pull request at:

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


> Add a duration parser
> -
>
> Key: TEXT-25
> URL: https://issues.apache.org/jira/browse/TEXT-25
> Project: Commons Text
>  Issue Type: New Feature
>Reporter: Bruno P. Kinoshita
>Priority: Minor
>
> Duration parses interpret text such as *2 hours, 1 mn and 22sec*.
> Examples exist, such as https://github.com/jchampemont/gunip, written in 
> Javaby Jean Champémont, inspired by https://github.com/domchristie/juration 
> (JavaScript).



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Commented] (TEXT-80) StrLookup API confusing

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on TEXT-80:


Github user asfgit closed the pull request at:

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


> StrLookup API confusing
> ---
>
> Key: TEXT-80
> URL: https://issues.apache.org/jira/browse/TEXT-80
> Project: Commons Text
>  Issue Type: Bug
>Reporter: Etienne Neveu
>Assignee: Pascal Schumacher
>Priority: Major
> Fix For: 1.3
>
>
> [bayard: copying this from LANG-564]
> I don't see the point of having a generic type parameter on the StrLookup 
> class, if it's not used anywhere. No method / field in StrLookup references 
> this type parameter. IntelliJ IDEA itself reports a warning: "Type parameter 
> 'V' is never used". Moreover, Java generics are not reified, so there is no 
> reliable way to access the type parameter at runtime (and I don't see the 
> point of doing that anyway...).
> While the Javadoc tries to clarify the purpose of a StrLookup, the unused 
> type parameter is still confusing, and the client code has to un-necessarily 
> specify type parameters. For example, I have to write:
> StrLookup lookup = StrLookup.noneLookup();
> StrLookup lookup2 = StrLookup.systemPropertiesLookup();
> StrLookup lookup3 = StrLookup.mapLookup(integerMap);
> instead of
> StrLookup lookup = StrLookup.noneLookup();
> StrLookup lookup2 = StrLookup.systemPropertiesLookup();
> StrLookup lookup3 = StrLookup.mapLookup(integerMap);
> My best guess is that this type parameter was added when commons-lang was 
> generified, because StringLookup.mapLookup() takes a generified Map. Doing 
> this is not really needed, though: we could remove the  type parameter 
> everywhere, and replace the StrLookup.mapLookup()'s Map with a 
> Map (which is the same as Map, but 
> shorter).
> I guess it's too late to change this now, due to backward compatibility... 
> But I thought I'd comment just in case it's still possible.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Commented] (TEXT-80) StrLookup API confusing

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on TEXT-80:


Github user PascalSchumacher commented on the issue:

https://github.com/apache/commons-text/pull/44
  
I'm closing this as `StrLookup` will deprecated and replaced with 
`StringLookup` in the next release.


> StrLookup API confusing
> ---
>
> Key: TEXT-80
> URL: https://issues.apache.org/jira/browse/TEXT-80
> Project: Commons Text
>  Issue Type: Bug
>Reporter: Etienne Neveu
>Assignee: Pascal Schumacher
>Priority: Major
> Fix For: 1.3
>
>
> [bayard: copying this from LANG-564]
> I don't see the point of having a generic type parameter on the StrLookup 
> class, if it's not used anywhere. No method / field in StrLookup references 
> this type parameter. IntelliJ IDEA itself reports a warning: "Type parameter 
> 'V' is never used". Moreover, Java generics are not reified, so there is no 
> reliable way to access the type parameter at runtime (and I don't see the 
> point of doing that anyway...).
> While the Javadoc tries to clarify the purpose of a StrLookup, the unused 
> type parameter is still confusing, and the client code has to un-necessarily 
> specify type parameters. For example, I have to write:
> StrLookup lookup = StrLookup.noneLookup();
> StrLookup lookup2 = StrLookup.systemPropertiesLookup();
> StrLookup lookup3 = StrLookup.mapLookup(integerMap);
> instead of
> StrLookup lookup = StrLookup.noneLookup();
> StrLookup lookup2 = StrLookup.systemPropertiesLookup();
> StrLookup lookup3 = StrLookup.mapLookup(integerMap);
> My best guess is that this type parameter was added when commons-lang was 
> generified, because StringLookup.mapLookup() takes a generified Map. Doing 
> this is not really needed, though: we could remove the  type parameter 
> everywhere, and replace the StrLookup.mapLookup()'s Map with a 
> Map (which is the same as Map, but 
> shorter).
> I guess it's too late to change this now, due to backward compatibility... 
> But I thought I'd comment just in case it's still possible.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Closed] (TEXT-25) Add a duration parser

[Pascal Schumacher (JIRA)]

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

Pascal Schumacher closed TEXT-25.
-
   Resolution: Won't Fix
 Assignee: (was: Bruno P. Kinoshita)
Fix Version/s: (was: 1.x)

Closing this as "Won't Fix" after reading the latest comments. Feel free to 
reopen if you disagree.

> Add a duration parser
> -
>
> Key: TEXT-25
> URL: https://issues.apache.org/jira/browse/TEXT-25
> Project: Commons Text
>  Issue Type: New Feature
>Reporter: Bruno P. Kinoshita
>Priority: Minor
>
> Duration parses interpret text such as *2 hours, 1 mn and 22sec*.
> Examples exist, such as https://github.com/jchampemont/gunip, written in 
> Javaby Jean Champémont, inspired by https://github.com/domchristie/juration 
> (JavaScript).



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Resolved] (TEXT-80) StrLookup API confusing

[Pascal Schumacher (JIRA)]

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

Pascal Schumacher resolved TEXT-80.
---
   Resolution: Fixed
 Assignee: Pascal Schumacher
Fix Version/s: (was: 2.0)
   1.3

StrLookup will deprecated and replaced with StringLookup in 1.3.

> StrLookup API confusing
> ---
>
> Key: TEXT-80
> URL: https://issues.apache.org/jira/browse/TEXT-80
> Project: Commons Text
>  Issue Type: Bug
>Reporter: Etienne Neveu
>Assignee: Pascal Schumacher
>Priority: Major
> Fix For: 1.3
>
>
> [bayard: copying this from LANG-564]
> I don't see the point of having a generic type parameter on the StrLookup 
> class, if it's not used anywhere. No method / field in StrLookup references 
> this type parameter. IntelliJ IDEA itself reports a warning: "Type parameter 
> 'V' is never used". Moreover, Java generics are not reified, so there is no 
> reliable way to access the type parameter at runtime (and I don't see the 
> point of doing that anyway...).
> While the Javadoc tries to clarify the purpose of a StrLookup, the unused 
> type parameter is still confusing, and the client code has to un-necessarily 
> specify type parameters. For example, I have to write:
> StrLookup lookup = StrLookup.noneLookup();
> StrLookup lookup2 = StrLookup.systemPropertiesLookup();
> StrLookup lookup3 = StrLookup.mapLookup(integerMap);
> instead of
> StrLookup lookup = StrLookup.noneLookup();
> StrLookup lookup2 = StrLookup.systemPropertiesLookup();
> StrLookup lookup3 = StrLookup.mapLookup(integerMap);
> My best guess is that this type parameter was added when commons-lang was 
> generified, because StringLookup.mapLookup() takes a generified Map. Doing 
> this is not really needed, though: we could remove the  type parameter 
> everywhere, and replace the StrLookup.mapLookup()'s Map with a 
> Map (which is the same as Map, but 
> shorter).
> I guess it's too late to change this now, due to backward compatibility... 
> But I thought I'd comment just in case it's still possible.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Commented] (COMMONSRDF-49) Make AbstractRDFParser serializable

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on COMMONSRDF-49:
--

Github user ajs6f commented on the issue:

https://github.com/apache/commons-rdf/pull/43
  
Okay, I'll get to work on factoring out a (serializable) factory. Thanks 
for the discussion everyone! I think the parser types will be much stronger for 
it.


> Make AbstractRDFParser serializable
> ---
>
> Key: COMMONSRDF-49
> URL: https://issues.apache.org/jira/browse/COMMONSRDF-49
> Project: Apache Commons RDF
>  Issue Type: New Feature
>  Components: simple
>Affects Versions: 0.3.0
>Reporter: Stian Soiland-Reyes
>Assignee: Stian Soiland-Reyes
>Priority: Major
>  Labels: parser
> Fix For: 0.6.0
>
>
> Raised by [~p_ansell] in [pull request 
> 25|(https://github.com/apache/incubator-commonsrdf/pull/25#discussion_r85436754]
> {quote}
> The use of optional here as a field type makes it impossible to serialise. 
> Need to have the raw values stored in fields if you want to support 
> serialisation in the future, which should otherwise be possible.
> {quote}
> The suggestion is to avoid {{Optional}} in the private fields of 
> {{AbstractRDFParser}} so it can be serialized - it can still be {{Optional}} 
> in the accessor methods.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Commented] (COMMONSRDF-49) Make AbstractRDFParser serializable

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on COMMONSRDF-49:
--

Github user asfgit closed the pull request at:

https://github.com/apache/commons-rdf/pull/43


> Make AbstractRDFParser serializable
> ---
>
> Key: COMMONSRDF-49
> URL: https://issues.apache.org/jira/browse/COMMONSRDF-49
> Project: Apache Commons RDF
>  Issue Type: New Feature
>  Components: simple
>Affects Versions: 0.3.0
>Reporter: Stian Soiland-Reyes
>Assignee: Stian Soiland-Reyes
>Priority: Major
>  Labels: parser
> Fix For: 0.6.0
>
>
> Raised by [~p_ansell] in [pull request 
> 25|(https://github.com/apache/incubator-commonsrdf/pull/25#discussion_r85436754]
> {quote}
> The use of optional here as a field type makes it impossible to serialise. 
> Need to have the raw values stored in fields if you want to support 
> serialisation in the future, which should otherwise be possible.
> {quote}
> The suggestion is to avoid {{Optional}} in the private fields of 
> {{AbstractRDFParser}} so it can be serialized - it can still be {{Optional}} 
> in the accessor methods.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Commented] (TEXT-109) Implement or document how to use edit distances that consider the keyboard layout

[Mark Dacek (JIRA)]

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

Mark Dacek commented on TEXT-109:
-

Hello. I discussed this with [~chtompki] today. We will be attempting this 
shortly. 

> Implement or document how to use edit distances that consider the keyboard 
> layout
> -
>
> Key: TEXT-109
> URL: https://issues.apache.org/jira/browse/TEXT-109
> Project: Commons Text
>  Issue Type: New Feature
>Reporter: Bruno P. Kinoshita
>Priority: Minor
>  Labels: discussion, edit-distance, help-wanted
>
> Most edit distances take into consideration number of "changes" required in 
> one string to match with another string. And they give you a value that 
> represent the distance between the words.
> While it is helpful, when working with datasets and corpora that have been 
> created with keyboards (e.g. SMS, e-mail, transcripts) it is common to have 
> mistakes. In some cases a letter was accidentally mistyped. But the character 
> used is normally close to the correct character.
> For example, given the word "one", and two incorrect misspellings "onr" and 
> "oni". The Levenshtein distance for both would be 1. But if you are aware 
> that the keyboard layout is English with the QUERTY layout (notice the E and 
> the R), so the distance between "one" and "onr", would be greater than the 
> distance between "one" and "oni", because in the English keyboard the letter 
> 'E' is neighbouring 'R'. Whereas 'I' is not even covered by the left hand, 
> but by the right hand.
> Here's some reference links for further research.
> * https://findsomethingnewtoday.wordpress.com/2013/07/20/986/
> * https://www.joyofdata.de/blog/comparison-of-string-distance-algorithms/
> * http://www.nada.kth.se/~ann/exjobb/axel_samuelsson.pdf
> * https://github.com/wsong/Typo-Distance
> * 
> https://stackoverflow.com/questions/29233888/edit-distance-such-as-levenshtein-taking-into-account-proximity-on-keyboard
> Ideally such edit distance would be extensible to support other keyboard 
> layouts.
> There is some indication that perhaps an existing edit distance like 
> levenshtein could be extended to take into consideration the keyboard layout. 
> So perhaps a new edit distance is not entirely necessary.
> We could come with the the decision that it is too hard to implement, and it 
> would be better done in a spell checker, or that it would require some 
> statistics and would be out of the scope of Text. Or we could simply add 
> documentation on how to do it, without adding any code. Or, perhaps we add a 
> new edit distance.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Commented] (COMMONSRDF-49) Make AbstractRDFParser serializable

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on COMMONSRDF-49:
--

Github user ajs6f commented on the issue:

https://github.com/apache/commons-rdf/pull/43
  
Hm... if @afs and @stain are both feeling reluctant to go this way... I 
would still be happy to merge it as-is and then work forward to the fluent-ish 
factory design (since @ansell has given a LGTM) and there is agreement that 
having fields not be `Optional`s is good in any case. @stain, would you like to 
see some checks against `null`-valued fields? I can certainly add those easily 
enough.


> Make AbstractRDFParser serializable
> ---
>
> Key: COMMONSRDF-49
> URL: https://issues.apache.org/jira/browse/COMMONSRDF-49
> Project: Apache Commons RDF
>  Issue Type: New Feature
>  Components: simple
>Affects Versions: 0.3.0
>Reporter: Stian Soiland-Reyes
>Assignee: Stian Soiland-Reyes
>Priority: Major
>  Labels: parser
> Fix For: 0.6.0
>
>
> Raised by [~p_ansell] in [pull request 
> 25|(https://github.com/apache/incubator-commonsrdf/pull/25#discussion_r85436754]
> {quote}
> The use of optional here as a field type makes it impossible to serialise. 
> Need to have the raw values stored in fields if you want to support 
> serialisation in the future, which should otherwise be possible.
> {quote}
> The suggestion is to avoid {{Optional}} in the private fields of 
> {{AbstractRDFParser}} so it can be serialized - it can still be {{Optional}} 
> in the accessor methods.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Commented] (NUMBERS-60) Check Javadoc with respect to NaN

[Gilles (JIRA)]

[ 
https://issues.apache.org/jira/browse/NUMBERS-60?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16363750#comment-16363750
 ] 

Gilles commented on NUMBERS-60:
---

I've just look back into history, to figure out that I raised the same question 
years ago.
Could you please add a comment in the code to the effect that the inconsistency 
between the math and the implementation is assumed (and the reason why it is so 
if you have it from the C99 specs)?  Thanks a lot.

> Check Javadoc with respect to NaN
> -
>
> Key: NUMBERS-60
> URL: https://issues.apache.org/jira/browse/NUMBERS-60
> Project: Commons Numbers
>  Issue Type: Task
>  Components: complex
>Reporter: Gilles
>Priority: Minor
>  Labels: API, javadoc
> Fix For: 1.0
>
>
> See e.g. the doc for method {{negate}}:
> {code}
> /**
>  * Returns a {@code Complex} whose value is {@code (-this)}.
>  * Returns {@code NaN} if either real or imaginary
>  * part of this complex number is {@code Double.NaN}.
>  *
>  * @return {@code -this}.
>  */
> public Complex negate() {
> return new Complex(-real, -imaginary);
> }
> {code}
> The "NaN" advertized in the the Javadoc seems to refer to the {{Complex.NaN}} 
> field, but {{negate}} is able to construct instances for which the contract 
> of method {{equals(Object)}} will be broken.
> As a related issue, I would make the {{NaN}} field "private" (and rename it 
> "NAN" to avoid the CheckStyle warning); users who need to check for (any 
> combination of) NaN should use the {{isNaN()}} method.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Commented] (RNG-40) Ready for JDK 9 ?

[Gilles (JIRA)]

[ 
https://issues.apache.org/jira/browse/RNG-40?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16363683#comment-16363683
 ] 

Gilles commented on RNG-40:
---

Oh; that's fairly annoying, and it pretty much prevents true modularization.

Then, I'll just add to the release notes that the {{core}} package should not 
be used directly in applications, in order to avoid breakage by being shut out 
in a future release.
OK?

> Ready for JDK 9 ?
> -
>
> Key: RNG-40
> URL: https://issues.apache.org/jira/browse/RNG-40
> Project: Commons RNG
>  Issue Type: Sub-task
>Reporter: Gilles
>Priority: Major
>  Labels: java9
> Fix For: 1.1
>
>
> Cf. [this post|http://markmail.org/message/j7ki3x67kd2kpavj] on the ML.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Commented] (MATH-1450) PolygonsSet sets incorrect value for last vertex in open loops

[Gilles (JIRA)]

[ 
https://issues.apache.org/jira/browse/MATH-1450?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16363669#comment-16363669
 ] 

Gilles commented on MATH-1450:
--

Fine.  While at it, please add braces to enclose the {{else}} branch. :)
Thanks.

> PolygonsSet sets incorrect value for last vertex in open loops
> --
>
> Key: MATH-1450
> URL: https://issues.apache.org/jira/browse/MATH-1450
> Project: Commons Math
>  Issue Type: Bug
>Affects Versions: 4.0, 3.5, 3.6
>Reporter: Matt Juntunen
>Priority: Major
> Fix For: 4.0
>
>
> According to the documentation, for open infinite vertex loops returned by 
> the PolygonsSet.getVertices() method, the last two points can be used to 
> determine the direction of the last edge in the loop. However, the current 
> code returns a point from the second-to-last edge. For example, the code 
> below builds a box open on the top. It currently returns the vertex loop 
> [null, \{0; 1}, \{0; 0}, \{1; 0}, \{1; 0}], where the last two vertices are 
> the same point and cannot be used to determine the direction of the last 
> edge. The returned vertex loop should be [null, \{0; 1}, \{0; 0}, \{1; 0}, 
> \{1; 1}].
> {code:java}
> Cartesian2D v0 = new Cartesian2D(0, 1);
>     Cartesian2D v1 = new Cartesian2D(0, 0);
>     Cartesian2D v2 = new Cartesian2D(1, 0);
>     Cartesian2D v3 = new Cartesian2D(1, 1);
>     Line left = new Line(v0, v1, 1e-10);
>     Line bottom = new Line(v1, v2, 1e-10);
>     Line right = new Line(v2, v3, 1e-10);
>     List boundaries = new ArrayList<>();
>     boundaries.add(new SubLine(left, new 
> IntervalsSet(left.toSubSpace(v0).getX(), left.toSubSpace(v1).getX(), 1e-10)));
>     boundaries.add(new SubLine(bottom, new 
> IntervalsSet(bottom.toSubSpace(v1).getX(), bottom.toSubSpace(v2).getX(), 
> 1e-10)));
>     boundaries.add(new SubLine(right, new 
> IntervalsSet(right.toSubSpace(v2).getX(), right.toSubSpace(v3).getX(), 
> 1e-10)));
>     PolygonsSet polygon = new PolygonsSet(boundaries, 1e-10);
>     polygon.getVertices();{code}
>   
>  
> Pull Request: [https://github.com/apache/commons-math/pull/81]



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Commented] (NUMBERS-60) Check Javadoc with respect to NaN

[Eric Barnhill (JIRA)]

[ 
https://issues.apache.org/jira/browse/NUMBERS-60?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16363665#comment-16363665
 ] 

Eric Barnhill commented on NUMBERS-60:
--

{code:java}
if (c == 0 && d == 0) { return NAN; }
{code}
 This is the first block of code, put in to conform to C99. I think it is 
pretty failsafe.

> Check Javadoc with respect to NaN
> -
>
> Key: NUMBERS-60
> URL: https://issues.apache.org/jira/browse/NUMBERS-60
> Project: Commons Numbers
>  Issue Type: Task
>  Components: complex
>Reporter: Gilles
>Priority: Minor
>  Labels: API, javadoc
> Fix For: 1.0
>
>
> See e.g. the doc for method {{negate}}:
> {code}
> /**
>  * Returns a {@code Complex} whose value is {@code (-this)}.
>  * Returns {@code NaN} if either real or imaginary
>  * part of this complex number is {@code Double.NaN}.
>  *
>  * @return {@code -this}.
>  */
> public Complex negate() {
> return new Complex(-real, -imaginary);
> }
> {code}
> The "NaN" advertized in the the Javadoc seems to refer to the {{Complex.NaN}} 
> field, but {{negate}} is able to construct instances for which the contract 
> of method {{equals(Object)}} will be broken.
> As a related issue, I would make the {{NaN}} field "private" (and rename it 
> "NAN" to avoid the CheckStyle warning); users who need to check for (any 
> combination of) NaN should use the {{isNaN()}} method.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Comment Edited] (NUMBERS-60) Check Javadoc with respect to NaN

[Eric Barnhill (JIRA)]

[ 
https://issues.apache.org/jira/browse/NUMBERS-60?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16363665#comment-16363665
 ] 

Eric Barnhill edited comment on NUMBERS-60 at 2/14/18 9:10 AM:
---

{code:java}
final double c = divisor.real; 
final double d = divisor.imaginary;
if (c == 0 && d == 0) { return NAN; }
{code}
 This is the first block of code, put in to conform to C99. I think it is 
pretty failsafe.


was (Author: ericbarnhill):
{code:java}
if (c == 0 && d == 0) { return NAN; }
{code}
 This is the first block of code, put in to conform to C99. I think it is 
pretty failsafe.

> Check Javadoc with respect to NaN
> -
>
> Key: NUMBERS-60
> URL: https://issues.apache.org/jira/browse/NUMBERS-60
> Project: Commons Numbers
>  Issue Type: Task
>  Components: complex
>Reporter: Gilles
>Priority: Minor
>  Labels: API, javadoc
> Fix For: 1.0
>
>
> See e.g. the doc for method {{negate}}:
> {code}
> /**
>  * Returns a {@code Complex} whose value is {@code (-this)}.
>  * Returns {@code NaN} if either real or imaginary
>  * part of this complex number is {@code Double.NaN}.
>  *
>  * @return {@code -this}.
>  */
> public Complex negate() {
> return new Complex(-real, -imaginary);
> }
> {code}
> The "NaN" advertized in the the Javadoc seems to refer to the {{Complex.NaN}} 
> field, but {{negate}} is able to construct instances for which the contract 
> of method {{equals(Object)}} will be broken.
> As a related issue, I would make the {{NaN}} field "private" (and rename it 
> "NAN" to avoid the CheckStyle warning); users who need to check for (any 
> combination of) NaN should use the {{isNaN()}} method.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)