[jira] [Commented] (TINKERPOP-1892) GLV test failures for .NET

2018-03-12 Thread Jorge Bay (JIRA)

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

Jorge Bay commented on TINKERPOP-1892:
--

There might be something wrong in the test harness...
Including only the feature file that is affected might give us a clue: 
https://github.com/apache/tinkerpop/blob/bbb13772a791ae7116551ba1d62ea7d136fe60c7/gremlin-dotnet/test/Gremlin.Net.IntegrationTest/Gherkin/GherkinTestRunner.cs#L375

> GLV test failures for .NET
> --
>
> Key: TINKERPOP-1892
> URL: https://issues.apache.org/jira/browse/TINKERPOP-1892
> Project: TinkerPop
>  Issue Type: Bug
>  Components: dotnet
>Affects Versions: 3.2.7
>Reporter: stephen mallette
>Priority: Major
> Fix For: 3.2.8, 3.3.2
>
>
> There are a number of test failures with the latest updates to the GLV test 
> suite on TINKERPOP-1857. Those tests have been "ignored" in 
> {{GherkinTestRunner}}. I wasn't able to discern a pattern there to make this 
> ticket any more specific. Hopefully once someone digs into this one, a better 
> title can be written or more specific JIRA issues can be produced. 



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


[GitHub] tinkerpop pull request #815: TINKERPOP-1901 Transform enums into classes in ...

2018-03-12 Thread jorgebay
Github user jorgebay commented on a diff in the pull request:

https://github.com/apache/tinkerpop/pull/815#discussion_r173769540
  
--- Diff: gremlin-dotnet/src/Gremlin.Net/Process/Traversal/Cardinality.cs 
---
@@ -26,11 +26,16 @@ namespace Gremlin.Net.Process.Traversal
 {
 #pragma warning disable 1591
 
-public enum Cardinality
+public class Cardinality : EnumWrapper
 {
-List,
-   Set,
-   Single
+private Cardinality(string enumValue)
+: base("Cardinality", enumValue)
+{
+}
+
+public static Cardinality List => new Cardinality("list");
+   public static Cardinality Set => new Cardinality("set");
--- End diff --

`"\n\t\t"` creates this weird layout as we use 4 spaces for indentation 
instead of tabs.
We can use either `"\n", followed by 8 spaces` or avoid invoking `join()` 
and call `.each()` on the template itself.


---


[jira] [Commented] (TINKERPOP-1901) Enable usage of enums in more steps in Gremlin.Net

2018-03-12 Thread ASF GitHub Bot (JIRA)

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

ASF GitHub Bot commented on TINKERPOP-1901:
---

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

https://github.com/apache/tinkerpop/pull/815#discussion_r173769540
  
--- Diff: gremlin-dotnet/src/Gremlin.Net/Process/Traversal/Cardinality.cs 
---
@@ -26,11 +26,16 @@ namespace Gremlin.Net.Process.Traversal
 {
 #pragma warning disable 1591
 
-public enum Cardinality
+public class Cardinality : EnumWrapper
 {
-List,
-   Set,
-   Single
+private Cardinality(string enumValue)
+: base("Cardinality", enumValue)
+{
+}
+
+public static Cardinality List => new Cardinality("list");
+   public static Cardinality Set => new Cardinality("set");
--- End diff --

`"\n\t\t"` creates this weird layout as we use 4 spaces for indentation 
instead of tabs.
We can use either `"\n", followed by 8 spaces` or avoid invoking `join()` 
and call `.each()` on the template itself.


> Enable usage of enums in more steps in Gremlin.Net
> --
>
> Key: TINKERPOP-1901
> URL: https://issues.apache.org/jira/browse/TINKERPOP-1901
> Project: TinkerPop
>  Issue Type: Improvement
>  Components: dotnet
>Affects Versions: 3.2.7, 3.3.1
>Reporter: Florian Hockmann
>Assignee: Florian Hockmann
>Priority: Minor
> Fix For: 3.2.8, 3.3.2
>
>
> Java enums can implement interfaces and some Gremlin steps take interfaces as 
> arguments that are implemented by enums like {{T}} or {{P}} in Java. However, 
> C# enums can't have any methods and therefore also not implement interfaces. 
> For this reason, step arguments whose type is one of those interfaces 
> ({{Predicate}}, {{Function}}, ...) currently have the type {{object}} in 
> Gremlin.Net which makes it hard for users to know what kind of values they 
> can use for these arguments.
> This overload of the {{By}} step is a good example for this:
>  * In Gremlin-java:
> {code:java}
> public default  GraphTraversal by(final Traversal traversal, 
> final Comparator comparator)
> {code}
>  * In Gremlin.Net:
> {code}
> public GraphTraversal By (object function, object comparator)
> {code}
> [~jorgebg] [suggested two possible 
> solutions|https://github.com/apache/tinkerpop/pull/792#discussion_r167847541] 
> for this problem:
> {quote} * Use a class for T (not an enum), properties like T.Id could return 
> instances of whatever interface we create for it. Given that java enums 
> functionality is more comprehensive than what C# currently supports, it makes 
> sense to use a class IMO.
>  * Generate the offending traversal methods manually.{quote}



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


[jira] [Commented] (TINKERPOP-1917) gx:BigDecimal serialization broken in Gremlin.Net on systems with ',' as decimal separator

2018-03-12 Thread Jorge Bay (JIRA)

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

Jorge Bay commented on TINKERPOP-1917:
--

Nice!

> gx:BigDecimal serialization broken in Gremlin.Net on systems with ',' as 
> decimal separator
> --
>
> Key: TINKERPOP-1917
> URL: https://issues.apache.org/jira/browse/TINKERPOP-1917
> Project: TinkerPop
>  Issue Type: Bug
>  Components: dotnet
>Affects Versions: 3.2.7, 3.3.1
>Reporter: Florian Hockmann
>Assignee: Florian Hockmann
>Priority: Minor
> Fix For: 3.2.8, 3.3.2
>
>
> The converter for {{gx:BigDecimal}} performs {{ToString()}} which takes the 
> systems culture settings into account. This leads to problems as Gremlin 
> Server can't deserialize numbers with ','  as the decimal separator.



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


[jira] [Closed] (TINKERPOP-1918) Scenarios fail because of wrong numerical types

2018-03-12 Thread stephen mallette (JIRA)

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

stephen mallette closed TINKERPOP-1918.
---
Resolution: Fixed
  Assignee: stephen mallette

Thanks for identifying the root of the problem - not sure why i didn't see that 
myself - anyway - fixed via CTR with:

https://github.com/apache/tinkerpop/commit/f38c2bbf15c456f5067c0b65873e33756329269e

> Scenarios fail because of wrong numerical types
> ---
>
> Key: TINKERPOP-1918
> URL: https://issues.apache.org/jira/browse/TINKERPOP-1918
> Project: TinkerPop
>  Issue Type: Bug
>  Components: dotnet, test-suite
>Affects Versions: 3.2.7
>Reporter: Florian Hockmann
>Assignee: stephen mallette
>Priority: Major
> Fix For: 3.2.8, 3.3.2
>
>
> Two scenarios currently fail for Gremlin.Net because the types returned by 
> the server don't match the expected ones:
>  * 
> {{g_withSackX1_sumX_VX1X_localXoutXknowsX_barrierXnormSackXX_inXknowsX_barrier_sack}}
>  expects results as {{double}}, but we receive {{gx:BigDecimal}} from the 
> server which gets deserialized to the .NET type {{decimal}}.
>  * {{g_withBulkXfalseX_withSackX1_sumX_V_out_barrier_sack}} expects results 
> as {{double}}, but we receive {{g:Int32}} from the server which gets 
> deserialized to {{int}}.
> I'm not sure whether those are actually bugs in Gremlin.Net or if the 
> specified types in the scenarios are simply wrong as there doesn't seem to be 
> much we can do in .NET to get the types correctly.



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


[jira] [Commented] (TINKERPOP-1918) Scenarios fail because of wrong numerical types

2018-03-12 Thread Florian Hockmann (JIRA)

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

Florian Hockmann commented on TINKERPOP-1918:
-

Thanks, I wasn't 100% sure that it needed to be changed in the feature files as 
the other GLVs didn't have this problem, but that's probably just because 
Python and Javascript are not type-safe (and I assume that Java and Groovy 
don't use the features yet).

> Scenarios fail because of wrong numerical types
> ---
>
> Key: TINKERPOP-1918
> URL: https://issues.apache.org/jira/browse/TINKERPOP-1918
> Project: TinkerPop
>  Issue Type: Bug
>  Components: dotnet, test-suite
>Affects Versions: 3.2.7
>Reporter: Florian Hockmann
>Assignee: stephen mallette
>Priority: Major
> Fix For: 3.2.8, 3.3.2
>
>
> Two scenarios currently fail for Gremlin.Net because the types returned by 
> the server don't match the expected ones:
>  * 
> {{g_withSackX1_sumX_VX1X_localXoutXknowsX_barrierXnormSackXX_inXknowsX_barrier_sack}}
>  expects results as {{double}}, but we receive {{gx:BigDecimal}} from the 
> server which gets deserialized to the .NET type {{decimal}}.
>  * {{g_withBulkXfalseX_withSackX1_sumX_V_out_barrier_sack}} expects results 
> as {{double}}, but we receive {{g:Int32}} from the server which gets 
> deserialized to {{int}}.
> I'm not sure whether those are actually bugs in Gremlin.Net or if the 
> specified types in the scenarios are simply wrong as there doesn't seem to be 
> much we can do in .NET to get the types correctly.



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


[GitHub] tinkerpop pull request #808: TINKERPOP-1884 Bump to Netty 4.0.56.Final

2018-03-12 Thread asfgit
Github user asfgit closed the pull request at:

https://github.com/apache/tinkerpop/pull/808


---


[jira] [Commented] (TINKERPOP-1884) Bump to Netty 4.1

2018-03-12 Thread ASF GitHub Bot (JIRA)

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

ASF GitHub Bot commented on TINKERPOP-1884:
---

Github user asfgit closed the pull request at:

https://github.com/apache/tinkerpop/pull/808


> Bump to Netty 4.1
> -
>
> Key: TINKERPOP-1884
> URL: https://issues.apache.org/jira/browse/TINKERPOP-1884
> Project: TinkerPop
>  Issue Type: Improvement
>  Components: server
>Affects Versions: 3.3.1
>Reporter: stephen mallette
>Assignee: stephen mallette
>Priority: Major
>
> Netty 4.0.x is EOL:
> https://twitter.com/normanmaurer/status/960798363695435778
> time to bump to 4.1.x



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


[jira] [Commented] (TINKERPOP-1884) Bump to Netty 4.1

2018-03-12 Thread ASF GitHub Bot (JIRA)

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

ASF GitHub Bot commented on TINKERPOP-1884:
---

Github user asfgit closed the pull request at:

https://github.com/apache/tinkerpop/pull/809


> Bump to Netty 4.1
> -
>
> Key: TINKERPOP-1884
> URL: https://issues.apache.org/jira/browse/TINKERPOP-1884
> Project: TinkerPop
>  Issue Type: Improvement
>  Components: server
>Affects Versions: 3.3.1
>Reporter: stephen mallette
>Assignee: stephen mallette
>Priority: Major
>
> Netty 4.0.x is EOL:
> https://twitter.com/normanmaurer/status/960798363695435778
> time to bump to 4.1.x



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


[GitHub] tinkerpop pull request #809: TINKERPOP-1884 Bump to Netty 4.1.21.Final

2018-03-12 Thread asfgit
Github user asfgit closed the pull request at:

https://github.com/apache/tinkerpop/pull/809


---


[jira] [Closed] (TINKERPOP-1884) Bump to Netty 4.1

2018-03-12 Thread stephen mallette (JIRA)

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

stephen mallette closed TINKERPOP-1884.
---
   Resolution: Done
Fix Version/s: 3.3.2
   3.2.8

> Bump to Netty 4.1
> -
>
> Key: TINKERPOP-1884
> URL: https://issues.apache.org/jira/browse/TINKERPOP-1884
> Project: TinkerPop
>  Issue Type: Improvement
>  Components: server
>Affects Versions: 3.3.1
>Reporter: stephen mallette
>Assignee: stephen mallette
>Priority: Major
> Fix For: 3.2.8, 3.3.2
>
>
> Netty 4.0.x is EOL:
> https://twitter.com/normanmaurer/status/960798363695435778
> time to bump to 4.1.x



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


[GitHub] tinkerpop pull request #810: TINKERPOP-1446 Added standard string representa...

2018-03-12 Thread asfgit
Github user asfgit closed the pull request at:

https://github.com/apache/tinkerpop/pull/810


---


[jira] [Commented] (TINKERPOP-1446) Add a StringFactory for Path which prefixes with type.

2018-03-12 Thread ASF GitHub Bot (JIRA)

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

ASF GitHub Bot commented on TINKERPOP-1446:
---

Github user asfgit closed the pull request at:

https://github.com/apache/tinkerpop/pull/810


> Add a StringFactory for Path which prefixes with type.
> --
>
> Key: TINKERPOP-1446
> URL: https://issues.apache.org/jira/browse/TINKERPOP-1446
> Project: TinkerPop
>  Issue Type: Improvement
>  Components: structure
>Affects Versions: 3.2.2
>Reporter: Marko A. Rodriguez
>Assignee: stephen mallette
>Priority: Trivial
> Fix For: 3.4.0
>
>
> Here are our various {{StringFactory}} looks:
> {code}
> >>> Vertex(10)
> v[10]
> >>> Edge(2,Vertex(1),"knows",Vertex(2))
> e[2][1-knows->2]
> >>> Property("name","marko")
> p[name->marko]
> >>> VertexProperty(7,"name","marko")
> vp[name->marko]
> >>> Path([],[Vertex(1),"hello",3])
> [v[1], 'hello', 3]
> {code}
> NOTE: this is the same string representation for Gremlin-Java as well.
> Given that {{Path}} is a core interface, I believe it should have a 
> toString() like the other structure interfaces. I propose:
> {code}
> path[v[1], 'hello', 3]
> {code}
> This will make it easy to distinguish it from a list as well.



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


[jira] [Closed] (TINKERPOP-1446) Add a StringFactory for Path which prefixes with type.

2018-03-12 Thread stephen mallette (JIRA)

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

stephen mallette closed TINKERPOP-1446.
---
   Resolution: Implemented
Fix Version/s: 3.4.0

> Add a StringFactory for Path which prefixes with type.
> --
>
> Key: TINKERPOP-1446
> URL: https://issues.apache.org/jira/browse/TINKERPOP-1446
> Project: TinkerPop
>  Issue Type: Improvement
>  Components: structure
>Affects Versions: 3.2.2
>Reporter: Marko A. Rodriguez
>Assignee: stephen mallette
>Priority: Trivial
> Fix For: 3.4.0
>
>
> Here are our various {{StringFactory}} looks:
> {code}
> >>> Vertex(10)
> v[10]
> >>> Edge(2,Vertex(1),"knows",Vertex(2))
> e[2][1-knows->2]
> >>> Property("name","marko")
> p[name->marko]
> >>> VertexProperty(7,"name","marko")
> vp[name->marko]
> >>> Path([],[Vertex(1),"hello",3])
> [v[1], 'hello', 3]
> {code}
> NOTE: this is the same string representation for Gremlin-Java as well.
> Given that {{Path}} is a core interface, I believe it should have a 
> toString() like the other structure interfaces. I propose:
> {code}
> path[v[1], 'hello', 3]
> {code}
> This will make it easy to distinguish it from a list as well.



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


[GitHub] tinkerpop issue #812: TINKERPOP-1911 Refactored JavaTranslator

2018-03-12 Thread jorgebay
Github user jorgebay commented on the issue:

https://github.com/apache/tinkerpop/pull/812
  
lgtm, VOTE +1


---


[jira] [Commented] (TINKERPOP-1911) Refactor JavaTranslator to cache all reflective calls

2018-03-12 Thread ASF GitHub Bot (JIRA)

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

ASF GitHub Bot commented on TINKERPOP-1911:
---

Github user jorgebay commented on the issue:

https://github.com/apache/tinkerpop/pull/812
  
lgtm, VOTE +1


> Refactor JavaTranslator to cache all reflective calls
> -
>
> Key: TINKERPOP-1911
> URL: https://issues.apache.org/jira/browse/TINKERPOP-1911
> Project: TinkerPop
>  Issue Type: Improvement
>  Components: process
>Affects Versions: 3.2.7
>Reporter: stephen mallette
>Assignee: stephen mallette
>Priority: Major
>
> For some reason {{JavaTranslator}} still has some reflection calls in it that 
> are called on every {{Bytecode}} translation. We should cache the results of 
> those expensive methods.



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


[GitHub] tinkerpop pull request #815: TINKERPOP-1901 Transform enums into classes in ...

2018-03-12 Thread FlorianHockmann
Github user FlorianHockmann commented on a diff in the pull request:

https://github.com/apache/tinkerpop/pull/815#discussion_r173842052
  
--- Diff: gremlin-dotnet/src/Gremlin.Net/Process/Traversal/Cardinality.cs 
---
@@ -26,11 +26,16 @@ namespace Gremlin.Net.Process.Traversal
 {
 #pragma warning disable 1591
 
-public enum Cardinality
+public class Cardinality : EnumWrapper
 {
-List,
-   Set,
-   Single
+private Cardinality(string enumValue)
+: base("Cardinality", enumValue)
+{
+}
+
+public static Cardinality List => new Cardinality("list");
+   public static Cardinality Set => new Cardinality("set");
--- End diff --

I decided to go with the latter so that the template can handle the 
formatting itself.


---


[jira] [Commented] (TINKERPOP-1901) Enable usage of enums in more steps in Gremlin.Net

2018-03-12 Thread ASF GitHub Bot (JIRA)

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

ASF GitHub Bot commented on TINKERPOP-1901:
---

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

https://github.com/apache/tinkerpop/pull/815#discussion_r173842052
  
--- Diff: gremlin-dotnet/src/Gremlin.Net/Process/Traversal/Cardinality.cs 
---
@@ -26,11 +26,16 @@ namespace Gremlin.Net.Process.Traversal
 {
 #pragma warning disable 1591
 
-public enum Cardinality
+public class Cardinality : EnumWrapper
 {
-List,
-   Set,
-   Single
+private Cardinality(string enumValue)
+: base("Cardinality", enumValue)
+{
+}
+
+public static Cardinality List => new Cardinality("list");
+   public static Cardinality Set => new Cardinality("set");
--- End diff --

I decided to go with the latter so that the template can handle the 
formatting itself.


> Enable usage of enums in more steps in Gremlin.Net
> --
>
> Key: TINKERPOP-1901
> URL: https://issues.apache.org/jira/browse/TINKERPOP-1901
> Project: TinkerPop
>  Issue Type: Improvement
>  Components: dotnet
>Affects Versions: 3.2.7, 3.3.1
>Reporter: Florian Hockmann
>Assignee: Florian Hockmann
>Priority: Minor
> Fix For: 3.2.8, 3.3.2
>
>
> Java enums can implement interfaces and some Gremlin steps take interfaces as 
> arguments that are implemented by enums like {{T}} or {{P}} in Java. However, 
> C# enums can't have any methods and therefore also not implement interfaces. 
> For this reason, step arguments whose type is one of those interfaces 
> ({{Predicate}}, {{Function}}, ...) currently have the type {{object}} in 
> Gremlin.Net which makes it hard for users to know what kind of values they 
> can use for these arguments.
> This overload of the {{By}} step is a good example for this:
>  * In Gremlin-java:
> {code:java}
> public default  GraphTraversal by(final Traversal traversal, 
> final Comparator comparator)
> {code}
>  * In Gremlin.Net:
> {code}
> public GraphTraversal By (object function, object comparator)
> {code}
> [~jorgebg] [suggested two possible 
> solutions|https://github.com/apache/tinkerpop/pull/792#discussion_r167847541] 
> for this problem:
> {quote} * Use a class for T (not an enum), properties like T.Id could return 
> instances of whatever interface we create for it. Given that java enums 
> functionality is more comprehensive than what C# currently supports, it makes 
> sense to use a class IMO.
>  * Generate the offending traversal methods manually.{quote}



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


[jira] [Closed] (TINKERPOP-1895) gremlin-python lambdas do not work with HaltedTraverserStrategy(DetachedFactory)

2018-03-12 Thread stephen mallette (JIRA)

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

stephen mallette closed TINKERPOP-1895.
---
   Resolution: Duplicate
Fix Version/s: (was: 3.3.2)
   (was: 3.2.8)

No longer resolve as part of TINKERPOP-1896 - see TINKERPOP-1898 for latest 
details.

> gremlin-python lambdas do not work with 
> HaltedTraverserStrategy(DetachedFactory)
> 
>
> Key: TINKERPOP-1895
> URL: https://issues.apache.org/jira/browse/TINKERPOP-1895
> Project: TinkerPop
>  Issue Type: Bug
>  Components: python
>Affects Versions: 3.3.1
>Reporter: Branden Moore
>Assignee: stephen mallette
>Priority: Major
>
> When using the HaltedTraverserStrategy(o.a.t.g.s.u.d.DetachedFactory) in 
> gremlin-python, lambdas cannot be processed, returning a Python NameError.
> Using the examples from the documentation, against 
> gremlin-server-modern-py.yaml
>  
>  g.V().out().map(lambda: "x: len(x.get().value('name'))").sum().toList()
> [24L]
> g.withStrategies(HaltedTraverserStrategy("org.apache.tinkerpop.gremlin.structure.util.detached.DetachedFactory")).V().out().map(lambda:
>  "x: len(x.get().value('name'))").sum().toList()
> GremlinServerError: 599: NameError: name 'TraversalStrategy' is not defined 
> in 

[jira] [Commented] (TINKERPOP-1898) Issue with bindings in strategies and lambdas

2018-03-12 Thread stephen mallette (JIRA)

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

stephen mallette commented on TINKERPOP-1898:
-

No longer able to resolve on TINKERPOP-1896 - had to roll back the test that 
was validating this fix because it just couldn't pass consistently. Pretty much 
always failed in Travis and seemed to only fail locally on occasion on my 
system. There is some inconsistency in how jython processes varargs. Perhaps 
related to something in [this 
discussion|http://forum.imagej.net/t/issue-with-calling-java-function-with-varargs-from-jython/7138].
 Anyway, i don't think we will get this polished up for release in a couple of 
weeks as it might be an issue that is out of our hands. Going to remove the fix 
versions for 3.2.8/3.3.2 and email the dev list directly about the situation.

> Issue with bindings in strategies and lambdas
> -
>
> Key: TINKERPOP-1898
> URL: https://issues.apache.org/jira/browse/TINKERPOP-1898
> Project: TinkerPop
>  Issue Type: Bug
>  Components: python, server
>Affects Versions: 3.3.1
>Reporter: Jean-Philippe Braun
>Assignee: stephen mallette
>Priority: Major
> Attachments: bug.py
>
>
> I'm trying to use bindings in a traversal strategy like:
> {code:java}
>     graph = Graph()
>     g = 
> graph.traversal().withRemote(DriverRemoteConnection('ws://localhost:8182/gremlin',
>  'g'))
>     g = g.withStrategies(
>     SubgraphStrategy(vertices=__.has('foo', ('b', 5)))
>     ){code}
> This works unless there is a use of lambda in the traversal:
> {code:java}
>     g.V().toList() # will work
>     g.V().filter(lambda: "true").toList() # this will not{code}
> Here is the full TB on the server:
> {code:java}
>     [ERROR] TraversalOpProcessor - Could not deserialize the Traversal 
> instance
>     javax.script.ScriptException: javax.script.ScriptException: 
> groovy.lang.MissingPropertyException: No such property: b for class: Script4
>     at 
> org.apache.tinkerpop.gremlin.groovy.jsr223.GremlinGroovyScriptEngine.eval(GremlinGroovyScriptEngine.java:397)
>     at 
> javax.script.AbstractScriptEngine.eval(AbstractScriptEngine.java:233)
>     at 
> org.apache.tinkerpop.gremlin.groovy.jsr223.GremlinGroovyScriptEngine.eval(GremlinGroovyScriptEngine.java:309)
>     at 
> org.apache.tinkerpop.gremlin.groovy.engine.GremlinExecutor.eval(GremlinExecutor.java:343)
>     at 
> org.apache.tinkerpop.gremlin.server.op.traversal.TraversalOpProcessor.iterateBytecodeTraversal(TraversalOpProcessor.java:369)
>     at 
> org.apache.tinkerpop.gremlin.server.handler.OpExecutorHandler.channelRead0(OpExecutorHandler.java:68)
>     at 
> org.apache.tinkerpop.gremlin.server.handler.OpExecutorHandler.channelRead0(OpExecutorHandler.java:43)
>     at 
> io.netty.channel.SimpleChannelInboundHandler.channelRead(SimpleChannelInboundHandler.java:105)
>     at 
> io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:356)
>     at 
> io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:342)
>     at 
> io.netty.channel.AbstractChannelHandlerContext.fireChannelRead(AbstractChannelHandlerContext.java:335)
>     at 
> io.netty.handler.codec.MessageToMessageDecoder.channelRead(MessageToMessageDecoder.java:102)
>     at 
> io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:356)
>     at 
> io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:342)
>     at 
> io.netty.channel.AbstractChannelHandlerContext.fireChannelRead(AbstractChannelHandlerContext.java:335)
>     at 
> io.netty.handler.codec.MessageToMessageDecoder.channelRead(MessageToMessageDecoder.java:102)
>     at 
> io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:356)
>     at 
> io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:342)
>     at 
> io.netty.channel.AbstractChannelHandlerContext.fireChannelRead(AbstractChannelHandlerContext.java:335)
>     at 
> io.netty.handler.codec.MessageToMessageDecoder.channelRead(MessageToMessageDecoder.java:102)
>     at 
> io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:356)
>     at 
> io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:342)
>     at 
> io.netty.channel.AbstractChannelHandlerContext.fireChannelRead(AbstractChannelHandlerContext.java:335)
>     at 
> io.netty.handler.codec.MessageToMessageDecoder.channelRead(MessageToMessageD

[jira] [Updated] (TINKERPOP-1898) Issue with bindings in strategies and lambdas

2018-03-12 Thread stephen mallette (JIRA)

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

stephen mallette updated TINKERPOP-1898:

Fix Version/s: (was: 3.3.2)
   (was: 3.2.8)

> Issue with bindings in strategies and lambdas
> -
>
> Key: TINKERPOP-1898
> URL: https://issues.apache.org/jira/browse/TINKERPOP-1898
> Project: TinkerPop
>  Issue Type: Bug
>  Components: python, server
>Affects Versions: 3.3.1
>Reporter: Jean-Philippe Braun
>Assignee: stephen mallette
>Priority: Major
> Attachments: bug.py
>
>
> I'm trying to use bindings in a traversal strategy like:
> {code:java}
>     graph = Graph()
>     g = 
> graph.traversal().withRemote(DriverRemoteConnection('ws://localhost:8182/gremlin',
>  'g'))
>     g = g.withStrategies(
>     SubgraphStrategy(vertices=__.has('foo', ('b', 5)))
>     ){code}
> This works unless there is a use of lambda in the traversal:
> {code:java}
>     g.V().toList() # will work
>     g.V().filter(lambda: "true").toList() # this will not{code}
> Here is the full TB on the server:
> {code:java}
>     [ERROR] TraversalOpProcessor - Could not deserialize the Traversal 
> instance
>     javax.script.ScriptException: javax.script.ScriptException: 
> groovy.lang.MissingPropertyException: No such property: b for class: Script4
>     at 
> org.apache.tinkerpop.gremlin.groovy.jsr223.GremlinGroovyScriptEngine.eval(GremlinGroovyScriptEngine.java:397)
>     at 
> javax.script.AbstractScriptEngine.eval(AbstractScriptEngine.java:233)
>     at 
> org.apache.tinkerpop.gremlin.groovy.jsr223.GremlinGroovyScriptEngine.eval(GremlinGroovyScriptEngine.java:309)
>     at 
> org.apache.tinkerpop.gremlin.groovy.engine.GremlinExecutor.eval(GremlinExecutor.java:343)
>     at 
> org.apache.tinkerpop.gremlin.server.op.traversal.TraversalOpProcessor.iterateBytecodeTraversal(TraversalOpProcessor.java:369)
>     at 
> org.apache.tinkerpop.gremlin.server.handler.OpExecutorHandler.channelRead0(OpExecutorHandler.java:68)
>     at 
> org.apache.tinkerpop.gremlin.server.handler.OpExecutorHandler.channelRead0(OpExecutorHandler.java:43)
>     at 
> io.netty.channel.SimpleChannelInboundHandler.channelRead(SimpleChannelInboundHandler.java:105)
>     at 
> io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:356)
>     at 
> io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:342)
>     at 
> io.netty.channel.AbstractChannelHandlerContext.fireChannelRead(AbstractChannelHandlerContext.java:335)
>     at 
> io.netty.handler.codec.MessageToMessageDecoder.channelRead(MessageToMessageDecoder.java:102)
>     at 
> io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:356)
>     at 
> io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:342)
>     at 
> io.netty.channel.AbstractChannelHandlerContext.fireChannelRead(AbstractChannelHandlerContext.java:335)
>     at 
> io.netty.handler.codec.MessageToMessageDecoder.channelRead(MessageToMessageDecoder.java:102)
>     at 
> io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:356)
>     at 
> io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:342)
>     at 
> io.netty.channel.AbstractChannelHandlerContext.fireChannelRead(AbstractChannelHandlerContext.java:335)
>     at 
> io.netty.handler.codec.MessageToMessageDecoder.channelRead(MessageToMessageDecoder.java:102)
>     at 
> io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:356)
>     at 
> io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:342)
>     at 
> io.netty.channel.AbstractChannelHandlerContext.fireChannelRead(AbstractChannelHandlerContext.java:335)
>     at 
> io.netty.handler.codec.MessageToMessageDecoder.channelRead(MessageToMessageDecoder.java:102)
>     at 
> io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:356)
>     at 
> io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:342)
>     at 
> io.netty.channel.AbstractChannelHandlerContext.fireChannelRead(AbstractChannelHandlerContext.java:335)
>     at 
> io.netty.handler.codec.MessageToMessageDecoder.channelRead(MessageToMessageDecoder.java:102)
>     at 
> io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:356)
>     at 
> io.netty.channel.AbstractChannelHandlerContext

Re: [DISCUSS] 3.2.8/3.3.2 Release Issues

2018-03-12 Thread Stephen Mallette
I just made an update on two issues that I thought needed to be done with
gremlin-python for release, specifically:

https://issues.apache.org/jira/browse/TINKERPOP-1898
https://issues.apache.org/jira/browse/TINKERPOP-1895

if you're following along, i basically closed 1895 as a duplicate of 1898
as the two issues are related - ultimately, the issues is with specifying
strategies when a lambda is present. basically, i can't get the test i had
validating a fix to pass consistently and I believe that the reason is
related to something that is out of our hands - an issue in jython
processing varargs. Anyway, i don't imagine 1898 will get closed in time
for release, but personally, I don't think this is a massive issue to block
us from moving forward. I also think we have a reasonable workaround as
gremlin-python users should be able to submit their lambdas as groovy and
get a successful traversal execution.



On Thu, Mar 8, 2018 at 9:42 AM, Florian Hockmann 
wrote:

> I already started working on TINKERPOP-1901, but some tests failed and I
> wanted to use a Docker image of the Gremlin Server for easier debugging
> which is why I created a PR for that first.
> Finishing TINKERPOP-1854 should be really easy once TINKERPOP-1901 is done.
>
> Supporting g:T (TINKERPOP-1866) shouldn't require much work. It should
> just need a small deserializer.
>
> But I'm not sure about the test related tickets (TINKERPOP-1865 and
> TINKERPOP-1892). I looked into the failing tests when the new scenarios
> were introduced and they seemed to be caused by bugs / missing
> functionality in the way we create traversals from the Gherkin features
> rather than real bugs in Gremlin.Net.
>
> I also still see the problem of releasing Gremlin.Net from a Unix system
> as strong name signing is still not supported. The newest Visual Studio
> version that was released on Monday (15.6) includes the fix, but we still
> have to wait for the next release of the dotnet CLI tool. I asked in their
> Gitter channel about an estimate but didn't get an answer so far. We might
> have to set up a small build job on AppVeyor to build and pack Gremlin.Net
> so that the release manager can download the NuGet packages from there and
> then only has to push them. I can't handle the NuGet packaging this time as
> I'm on vacation in the second half of March and first week of April.
>
> Do we have to set the release date in stone now or could we just see where
> we are at the end of next week and then decide whether we stay with the
> release date in the first week of April or whether we need more time?
>
> -Ursprüngliche Nachricht-
> Von: Jorge Bay Gondra 
> Gesendet: Donnerstag, 8. März 2018 09:26
> An: dev@tinkerpop.apache.org
> Betreff: Re: [DISCUSS] 3.2.8/3.3.2 Release Issues
>
> Lambdas in .NET is blocked by TINKERPOP-1901, I've updated JIRA to reflect
> that.
>
> I don't know if we can make it with the current scope in that timeline. I
> have very little / no time available for the .NET GLV issues until the end
> of next week...
>
> On Wed, Mar 7, 2018 at 9:35 PM, Stephen Mallette 
> wrote:
>
> > In a previous thread we had the idea that we would look to release
> > 3.2.8/3.3.2 around the first week of April which means that we will
> > likely code freeze in about 10 days to focus on review/test/docs. I
> > think that we want to see these issues polished up before we release:
> >
> > https://issues.apache.org/jira/browse/TINKERPOP-1866 (Support g:T for
> > .NET)
> > https://issues.apache.org/jira/browse/TINKERPOP-1854 (Lambdas in .NET
> > - already has a PR)
> > https://issues.apache.org/jira/browse/TINKERPOP-1865 (Run .NET tests
> > on GraphSON 3.0)
> > https://issues.apache.org/jira/browse/TINKERPOP-1892 (A few failing
> > tests in .NET)
> >
> > Jorge/Florian, hopefully you can help us get to the finish line on
> > those .NET issues?
> >
> > The following 3 are all python related around lambdas and i think
> > fixing one will fix all (i'm still digging into these):
> >
> > https://issues.apache.org/jira/browse/TINKERPOP-1895
> > https://issues.apache.org/jira/browse/TINKERPOP-1896
> > https://issues.apache.org/jira/browse/TINKERPOP-1898
> >
> > Obviously we would want to close out all current PRs that are open as
> well.
> > Committers, we could use some reviews please - there is a glut of them
> > at this point.
> >
> > Interestingly there's no problems to solve with the Javascript GLV...I
> > guess I shouldn't be paranoid :)
> >
> > Are there any concerns with trying to finish up the items I've posted?
> > Anyone know of anything else that is crucial for this release?
> >
>
>


[GitHub] tinkerpop pull request #812: TINKERPOP-1911 Refactored JavaTranslator

2018-03-12 Thread asfgit
Github user asfgit closed the pull request at:

https://github.com/apache/tinkerpop/pull/812


---


[jira] [Commented] (TINKERPOP-1911) Refactor JavaTranslator to cache all reflective calls

2018-03-12 Thread ASF GitHub Bot (JIRA)

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

ASF GitHub Bot commented on TINKERPOP-1911:
---

Github user asfgit closed the pull request at:

https://github.com/apache/tinkerpop/pull/812


> Refactor JavaTranslator to cache all reflective calls
> -
>
> Key: TINKERPOP-1911
> URL: https://issues.apache.org/jira/browse/TINKERPOP-1911
> Project: TinkerPop
>  Issue Type: Improvement
>  Components: process
>Affects Versions: 3.2.7
>Reporter: stephen mallette
>Assignee: stephen mallette
>Priority: Major
>
> For some reason {{JavaTranslator}} still has some reflection calls in it that 
> are called on every {{Bytecode}} translation. We should cache the results of 
> those expensive methods.



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


[jira] [Closed] (TINKERPOP-1911) Refactor JavaTranslator to cache all reflective calls

2018-03-12 Thread stephen mallette (JIRA)

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

stephen mallette closed TINKERPOP-1911.
---
   Resolution: Done
Fix Version/s: 3.3.2
   3.2.8

> Refactor JavaTranslator to cache all reflective calls
> -
>
> Key: TINKERPOP-1911
> URL: https://issues.apache.org/jira/browse/TINKERPOP-1911
> Project: TinkerPop
>  Issue Type: Improvement
>  Components: process
>Affects Versions: 3.2.7
>Reporter: stephen mallette
>Assignee: stephen mallette
>Priority: Major
> Fix For: 3.2.8, 3.3.2
>
>
> For some reason {{JavaTranslator}} still has some reflection calls in it that 
> are called on every {{Bytecode}} translation. We should cache the results of 
> those expensive methods.



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


[GitHub] tinkerpop issue #802: Add docker images for console and server TINKERPOP-189...

2018-03-12 Thread spmallette
Github user spmallette commented on the issue:

https://github.com/apache/tinkerpop/pull/802
  
i saw a few solutions to the issue of skipping when SNAPSHOT - not sure 
which is best, but here's one:

https://stackoverflow.com/a/39139979/1831717

we might actually find usage for this elsewhere in tinkerpop once the 
process is established. i seem to remember some hacky things we do around this 
problem, but i don't recall exactly what..maybe i'm making it up :)


---


[jira] [Commented] (TINKERPOP-1897) Provide Docker images of Gremlin Server and Console

2018-03-12 Thread ASF GitHub Bot (JIRA)

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

ASF GitHub Bot commented on TINKERPOP-1897:
---

Github user spmallette commented on the issue:

https://github.com/apache/tinkerpop/pull/802
  
i saw a few solutions to the issue of skipping when SNAPSHOT - not sure 
which is best, but here's one:

https://stackoverflow.com/a/39139979/1831717

we might actually find usage for this elsewhere in tinkerpop once the 
process is established. i seem to remember some hacky things we do around this 
problem, but i don't recall exactly what..maybe i'm making it up :)


> Provide Docker images of Gremlin Server and Console
> ---
>
> Key: TINKERPOP-1897
> URL: https://issues.apache.org/jira/browse/TINKERPOP-1897
> Project: TinkerPop
>  Issue Type: Improvement
>  Components: console, server
>Affects Versions: 3.2.7
>Reporter: Florian Hockmann
>Assignee: Florian Hockmann
>Priority: Major
>
> TinkerPop should provide Docker images of Gremlin Server and Gremlin Console 
> that are deployed together with each release.
> This originated from the mailing list:
> [https://lists.apache.org/thread.html/744ae19afa9b2fd1984c1e4dddc588e98786d9c21b633aab8bfa@%3Cdev.tinkerpop.apache.org%3E]



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


[jira] [Commented] (TINKERPOP-1892) GLV test failures for .NET

2018-03-12 Thread stephen mallette (JIRA)

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

stephen mallette commented on TINKERPOP-1892:
-

is it possible that when a failure occurs, that the rest of the feature file 
stops testing, so that tests following the failure in that particular feature 
file aren't counted?

> GLV test failures for .NET
> --
>
> Key: TINKERPOP-1892
> URL: https://issues.apache.org/jira/browse/TINKERPOP-1892
> Project: TinkerPop
>  Issue Type: Bug
>  Components: dotnet
>Affects Versions: 3.2.7
>Reporter: stephen mallette
>Priority: Major
> Fix For: 3.2.8, 3.3.2
>
>
> There are a number of test failures with the latest updates to the GLV test 
> suite on TINKERPOP-1857. Those tests have been "ignored" in 
> {{GherkinTestRunner}}. I wasn't able to discern a pattern there to make this 
> ticket any more specific. Hopefully once someone digs into this one, a better 
> title can be written or more specific JIRA issues can be produced. 



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


[jira] [Created] (TINKERPOP-1922) Gherkin features fail that contain P.not() in Gremlin.Net

2018-03-12 Thread Florian Hockmann (JIRA)
Florian Hockmann created TINKERPOP-1922:
---

 Summary: Gherkin features fail that contain P.not() in Gremlin.Net
 Key: TINKERPOP-1922
 URL: https://issues.apache.org/jira/browse/TINKERPOP-1922
 Project: TinkerPop
  Issue Type: Bug
  Components: dotnet
Affects Versions: 3.2.7
Reporter: Florian Hockmann
 Fix For: 3.2.8, 3.3.2


Gherkin scenarios that contain {{P.not()}} currently fail in Gremlin.Net. The 
server prints an exception that hints at problems with deserialization of 
{{P.not()}}:
{code:java}
Could not deserialize the JSON value as required. Nested exception: 
java.lang.IllegalStateException: 
org.apache.tinkerpop.gremlin.process.traversal.P.not([Ljava.lang.Object;){code}



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


[jira] [Commented] (TINKERPOP-1892) GLV test failures for .NET

2018-03-12 Thread Florian Hockmann (JIRA)

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

Florian Hockmann commented on TINKERPOP-1892:
-

{quote}is it possible that when a failure occurs, that the rest of the feature 
file stops testing, so that tests following the failure in that particular 
feature file aren't counted?
{quote}
Turns out that you were nearly right: The {{GherkinTestRunner}} stopped 
processing a feature file after one scenario was _skipped_. This was simply 
causes by a {{break}} that should be a {{continue}}.

I fixed that with a CTR commit:

[https://github.com/apache/tinkerpop/commit/b25b9767547b2956f224cbe6fb55c756d5df612e]

This also showed yet another category of test failures in Gremlin.Net for which 
I created TINKERPOP-1922.

Now I'm getting on {{tp32}}: _Total scenarios: 451. Passed: 417. Failed: 0. 
Skipped: 34._

So the total number is right although 34 scenarios are skipped.

> GLV test failures for .NET
> --
>
> Key: TINKERPOP-1892
> URL: https://issues.apache.org/jira/browse/TINKERPOP-1892
> Project: TinkerPop
>  Issue Type: Bug
>  Components: dotnet
>Affects Versions: 3.2.7
>Reporter: stephen mallette
>Priority: Major
> Fix For: 3.2.8, 3.3.2
>
>
> There are a number of test failures with the latest updates to the GLV test 
> suite on TINKERPOP-1857. Those tests have been "ignored" in 
> {{GherkinTestRunner}}. I wasn't able to discern a pattern there to make this 
> ticket any more specific. Hopefully once someone digs into this one, a better 
> title can be written or more specific JIRA issues can be produced. 



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


[jira] [Commented] (TINKERPOP-1922) Gherkin features fail that contain P.not() in Gremlin.Net

2018-03-12 Thread Florian Hockmann (JIRA)

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

Florian Hockmann commented on TINKERPOP-1922:
-

Completely forgot that there was already an issue for deserialization problems 
with {{P.not()}}.

> Gherkin features fail that contain P.not() in Gremlin.Net
> -
>
> Key: TINKERPOP-1922
> URL: https://issues.apache.org/jira/browse/TINKERPOP-1922
> Project: TinkerPop
>  Issue Type: Bug
>  Components: dotnet
>Affects Versions: 3.2.7
>Reporter: Florian Hockmann
>Priority: Major
> Fix For: 3.2.8, 3.3.2
>
>
> Gherkin scenarios that contain {{P.not()}} currently fail in Gremlin.Net. The 
> server prints an exception that hints at problems with deserialization of 
> {{P.not()}}:
> {code:java}
> Could not deserialize the JSON value as required. Nested exception: 
> java.lang.IllegalStateException: 
> org.apache.tinkerpop.gremlin.process.traversal.P.not([Ljava.lang.Object;){code}



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


[GitHub] tinkerpop pull request #816: TINKERPOP-1919 Merge classes P and TraversalPre...

2018-03-12 Thread FlorianHockmann
GitHub user FlorianHockmann opened a pull request:

https://github.com/apache/tinkerpop/pull/816

TINKERPOP-1919 Merge classes P and TraversalPredicate in Gremlin.Net

https://issues.apache.org/jira/browse/TINKERPOP-1919

This removes the `TraversalPredicate` class by including its functionality 
into `P`. That made it easier to enable our Gherkin runner to work with 
`P.And()` and `P.Or()` and having `P` as the type for step parameters is 
probably also easier to understand for users than `TraversalPredicate`.

I added a `CHANGELOG` entry as this is technically a breaking change as it 
removes a public class, but I think that it's unlikely that users interacted 
directly with `TraversalPredicate` instead of only via `P.Something().And()`.

This affected 4 previously ignored scenarios. Unfortunately, 2 of those are 
still ignored because of TINKERPOP-1922.

VOTE +1

You can merge this pull request into a Git repository by running:

$ git pull https://github.com/apache/tinkerpop TINKERPOP-1919

Alternatively you can review and apply these changes as the patch at:

https://github.com/apache/tinkerpop/pull/816.patch

To close this pull request, make a commit to your master/trunk branch
with (at least) the following in the commit message:

This closes #816


commit 97c179d29d7440ac31be791dbeb39e41e54d9a22
Author: Florian Hockmann 
Date:   2018-03-12T20:16:18Z

 TINKERPOP-1919 Merge classes P and TraversalPredicate

There is no good reason to keep those two classes separate anymore and
having P as the type for step parameters is probably easier to
understand for users than TraversalPredicate.




---


[jira] [Assigned] (TINKERPOP-1919) Gherkin runner doesn't work with P.And() and P.Or() in Gremlin.Net

2018-03-12 Thread Florian Hockmann (JIRA)

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

Florian Hockmann reassigned TINKERPOP-1919:
---

Assignee: Florian Hockmann

> Gherkin runner doesn't work with P.And() and P.Or() in Gremlin.Net
> --
>
> Key: TINKERPOP-1919
> URL: https://issues.apache.org/jira/browse/TINKERPOP-1919
> Project: TinkerPop
>  Issue Type: Bug
>  Components: dotnet
>Affects Versions: 3.2.7
>Reporter: Florian Hockmann
>Assignee: Florian Hockmann
>Priority: Major
> Fix For: 3.2.8, 3.3.2
>
>
> Gremlin.Net has split {{P}} into two classes: {{P}} and 
> {{TraversalPredicate}}. This is problematic for the Gherkin runner as it 
> tries to call methods on {{P}} that are only in {{TraversalPredicate}}.
> We can now either let the Gherkin parser try to call {{P}} methods on both 
> classes or we could also just merge those two classes together. I think the 
> reason why they are split was simply that the methods in 
> {{TraversalPredicate}} are written by hand whereas {{P}} is completely 
> generated and I didn't want to write much code inside of Groovy strings that 
> were part of the {{pom.xml}} before [~spmallette] introduced templates for 
> the GLV generation.



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


[jira] [Commented] (TINKERPOP-1919) Gherkin runner doesn't work with P.And() and P.Or() in Gremlin.Net

2018-03-12 Thread ASF GitHub Bot (JIRA)

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

ASF GitHub Bot commented on TINKERPOP-1919:
---

GitHub user FlorianHockmann opened a pull request:

https://github.com/apache/tinkerpop/pull/816

TINKERPOP-1919 Merge classes P and TraversalPredicate in Gremlin.Net

https://issues.apache.org/jira/browse/TINKERPOP-1919

This removes the `TraversalPredicate` class by including its functionality 
into `P`. That made it easier to enable our Gherkin runner to work with 
`P.And()` and `P.Or()` and having `P` as the type for step parameters is 
probably also easier to understand for users than `TraversalPredicate`.

I added a `CHANGELOG` entry as this is technically a breaking change as it 
removes a public class, but I think that it's unlikely that users interacted 
directly with `TraversalPredicate` instead of only via `P.Something().And()`.

This affected 4 previously ignored scenarios. Unfortunately, 2 of those are 
still ignored because of TINKERPOP-1922.

VOTE +1

You can merge this pull request into a Git repository by running:

$ git pull https://github.com/apache/tinkerpop TINKERPOP-1919

Alternatively you can review and apply these changes as the patch at:

https://github.com/apache/tinkerpop/pull/816.patch

To close this pull request, make a commit to your master/trunk branch
with (at least) the following in the commit message:

This closes #816


commit 97c179d29d7440ac31be791dbeb39e41e54d9a22
Author: Florian Hockmann 
Date:   2018-03-12T20:16:18Z

 TINKERPOP-1919 Merge classes P and TraversalPredicate

There is no good reason to keep those two classes separate anymore and
having P as the type for step parameters is probably easier to
understand for users than TraversalPredicate.




> Gherkin runner doesn't work with P.And() and P.Or() in Gremlin.Net
> --
>
> Key: TINKERPOP-1919
> URL: https://issues.apache.org/jira/browse/TINKERPOP-1919
> Project: TinkerPop
>  Issue Type: Bug
>  Components: dotnet
>Affects Versions: 3.2.7
>Reporter: Florian Hockmann
>Priority: Major
> Fix For: 3.2.8, 3.3.2
>
>
> Gremlin.Net has split {{P}} into two classes: {{P}} and 
> {{TraversalPredicate}}. This is problematic for the Gherkin runner as it 
> tries to call methods on {{P}} that are only in {{TraversalPredicate}}.
> We can now either let the Gherkin parser try to call {{P}} methods on both 
> classes or we could also just merge those two classes together. I think the 
> reason why they are split was simply that the methods in 
> {{TraversalPredicate}} are written by hand whereas {{P}} is completely 
> generated and I didn't want to write much code inside of Groovy strings that 
> were part of the {{pom.xml}} before [~spmallette] introduced templates for 
> the GLV generation.



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