[jira] [Comment Edited] (TINKERPOP-1254) Support dropping traverser path information when it is no longer needed.

[Ted Wilmes (JIRA)]

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

Ted Wilmes edited comment on TINKERPOP-1254 at 6/16/16 10:23 PM:
-

[~okram] I pushed a very, very rough version.  Not ready for PR yet as I need 
to cleanup code and add more tests.  Having said that, if you're curious and 
want to take a look at it in its current state, I'd appreciate any feedback.  I 
think I've captured the basic ideas.  Diff can be seen at 
https://github.com/apache/tinkerpop/compare/master...TINKERPOP-1254  

I was wondering what your thoughts were on unit testing the strategy 
application.  It's different than the current strategy tests because I'm not 
rewriting the traversal, but instead setting the keep labels on certain steps.  
My simple idea was to just add a {{getKeepLabels}} to the {{PathProcessor}} 
interface so I could introspect for my unit tests, but thought you might have a 
better idea.


was (Author: twilmes):
@okram I pushed a very, very rough version.  Not ready for PR yet as I need to 
cleanup code and add more tests.  Having said that, if you're curious and want 
to take a look at it in its current state, I'd appreciate any feedback.  I 
think I've captured the basic ideas.  Diff can be seen at 
https://github.com/apache/tinkerpop/compare/master...TINKERPOP-1254  

I was wondering what your thoughts were on unit testing the strategy 
application.  It's different than the current strategy tests because I'm not 
rewriting the traversal, but instead setting the keep labels on certain steps.  
My simple idea was to just add a {{getKeepLabels}} to the {{PathProcessor}} 
interface so I could introspect for my unit tests, but thought you might have a 
better idea.

> Support dropping traverser path information when it is no longer needed.
> 
>
> Key: TINKERPOP-1254
> URL: https://issues.apache.org/jira/browse/TINKERPOP-1254
> Project: TinkerPop
>  Issue Type: Improvement
>  Components: process
>Affects Versions: 3.1.1-incubating
>Reporter: Marko A. Rodriguez
>Assignee: Ted Wilmes
>
> The most expensive traversals (especially in OLAP) are those that can not be 
> "bulked." There are various reasons why two traversers at the same object can 
> not be bulked, but the primary reason is {{PATH}} or {{LABELED_PATH}}. That 
> is, when the history of the traverser is required, the probability of two 
> traversers having the same history is low.
> A key to making traversals more efficient is to do as a much as possible to 
> remove historic information from a traverser so it can get bulked. How does 
> one do this? 
> {code}
> g.V.as('a').out().as('b').out().where(neq('a').and().neq('b')).both().name
> {code}
> The {{LABELED_PATH}} of "a" and "b" are required up to the {{where()}} and at 
> which point, at {{both()}}, they are no longer required. It would be smart to 
> support:
> {code}
> traverser.dropLabels(Set)
> traverser.dropPath()
> {code}
> We would then, via a {{TraversalOptimizationStrategy}} insert a step between 
> {{where()}} and {{both()}} called {{PathPruneStep}} which would be a 
> {{SideEffectStep}}. The strategy would know which labels were no longer 
> needed (via forward lookahead) and then do:
> {code}
> public class PathPruneStep {
>   final Set dropLabels = ...
>   final boolean dropPath = ...
>   public void sideEffect(final Traverser traverser) {
> final Traverser start = this.starts.next();
> if(this.dropPath) start.dropPath();
> else start.dropLabels(labels); 
>   }
> }
> {code}
> Again, the more we can prune historic path data no longer needed, the higher 
> the probability of bulking. Think about this in terms of {{match()}}.
> {code}
> g.V().match(
>   a.out.b,
>   b.out.c,
>   c.neq.a,
>   c.out.b,
> ).select("a")
> {code}
> All we need is "a" at the end. Thus, once a pattern has been passed and no 
> future patterns require that label, drop it! 
> This idea is related to TINKERPOP-331, but I don't think we should deal with 
> manipulating the species. Thus, I think 331 is too "low level."



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

[jira] [Commented] (TINKERPOP-1278) Implement Gremlin-Python and general purpose language variant test infrastructure

[ASF GitHub Bot (JIRA)]

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

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

Github user spmallette commented on the issue:

https://github.com/apache/tinkerpop/pull/340
  
ah - didn't realize that build was hosed in the TINKERPOP-1278 branch 
itself. 


> Implement Gremlin-Python and general purpose language variant test 
> infrastructure
> -
>
> Key: TINKERPOP-1278
> URL: https://issues.apache.org/jira/browse/TINKERPOP-1278
> Project: TinkerPop
>  Issue Type: Improvement
>  Components: language-variant
>Affects Versions: 3.2.0-incubating
>Reporter: Marko A. Rodriguez
>Assignee: Marko A. Rodriguez
>
> As discussed on dev@...
> Apache TinkerPop should provide, out-of-the-box, at least 3 Gremlin language 
> variants. It would be cool if these were:
> * Python (Mark Henderson)
> * PHP ([~PommeVerte])
> * Ruby (?[~okram])
> I think each of these should be generated using the reflection-model 
> presented in 
> http://tinkerpop.apache.org/docs/3.2.1-SNAPSHOT/tutorials/gremlin-language-variants/.
>  Moreover, on every {{mvn clean install}}, the code for these variants is 
> generated.
> Given the desire to separate language variants from language drivers, I think 
> that a language driver for each variant above should be "plugable." Moreover, 
> we should provide one driver implementation for each -- simple GremlinServer 
> REST.
> {code}
> gremlin-variants/
>   gremlin-ruby/
> gremlin_ruby.rb
> gremlin_ruby_rest_driver.rb
>   gremlin-php/
> Gremlin_PHP.php
> Gremlin_PHP_REST_Driver.php
>   gremlin-python/
> gremlin-python.py
> gremlin-python-rest-driver.py
> {code}
> Next, each variant implementation should be testable. This is PAINFUL if we 
> have to implement each {{g_V_out_repeatXasXaXX}} test case in 
> {{ProcessXXXSuite}}. Perhaps some RegEx transducer magic could be used to 
> convert all those tests from Gremlin-Java to the respective host language? 
> However, even if we do that, we still have the problem of how to test the 
> returned results. 
> I think what we should test the returned results using the JVM. For instance, 
> JRuby, Jython, JPHP (does it exist?). If we do this, we will save ourselves a 
> massive headache. All we have to do is create a {{GraphProvider}} that uses 
> {{TinkerGraph}} and whose {{TraversalSource}} is some sort of wrapper around 
> reflection-generated Ruby (e.g.).
> {code}
> g.V.out_e("knows") // returns a Ruby iterator
> {code}
> That Ruby iterator should be converted to a Java iterator and then the 
> {{ProcessXXXSuite}} can verify the results.
> With this, most everything is reflectively constructed.
> {code}
> gremlin_ruby.rb // generated via Java reflection
> gremlin_ruby_rest_driver.rb // manually coded
> match_test.rb   // generated via RegEx transducer
> has_test.rb // generated via RegEx transducer
> ...
> RubyGraphProvider.java// manually coded
> RubyProcessStandardSuite.java // manually coded
> RubyProcessComputerSuite.java // manually coded
> {code}
> Thus, the testing data flow would be:
> {code}
> MatchTest.Traversals.java --transducer-> match_test.rb
> match-test.rb --REST--> GremlinServer
> GremlinServer --GraphSON-->match-test.rb
> GraphSON --JRuby/GraphSONReader-->Java objects
> Java objects --JRuby-->MatchTest.java 
> {code}



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

[GitHub] tinkerpop issue #340: add RawExpression to gremlin_python

[spmallette]

Github user spmallette commented on the issue:

https://github.com/apache/tinkerpop/pull/340
  
@leifurhauks do you know why travis is not happy? the build took some 
errors it seems. Can you please look into that as you push your next change?


---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

[GitHub] tinkerpop pull request #342: TINKERPOP-1063 TinkerGraph Performance

[dkuppitz]

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

https://github.com/apache/tinkerpop/pull/342#discussion_r67415317
  
--- Diff: 
tinkergraph-gremlin/src/main/java/org/apache/tinkerpop/gremlin/tinkergraph/structure/TinkerGraph.java
 ---
@@ -358,6 +350,14 @@ public Features features() {
 return features;
 }
 
+private void validateHomogenousIds(final List ids) {
+final Class firstClass = ids.get(0).getClass();
+for (Object id : ids) {
+if (!id.getClass().equals(firstClass))
+throw Graph.Exceptions.idArgsMustBeEitherIdOrElement();
+}
+}
+
--- End diff --

This opens the door for NPE's.

```
gremlin> graph.vertices("a", null, 1)
java.lang.NullPointerException
Display stack trace? [yN] y
java.lang.NullPointerException
at 
org.apache.tinkerpop.gremlin.tinkergraph.structure.TinkerGraph.validateHomogenousIds(TinkerGraph.java:356)
at 
org.apache.tinkerpop.gremlin.tinkergraph.structure.TinkerGraph.createElementIterator(TinkerGraph.java:329)
at 
org.apache.tinkerpop.gremlin.tinkergraph.structure.TinkerGraph.vertices(TinkerGraph.java:269)
```

Suggestion with a few tweaks:

```
private void validateHomogenousIds(final List ids) {
final Iterator iterator = ids.iterator();
Object id = iterator.next();
if (id == null)
throw Graph.Exceptions.idArgsMustBeEitherIdOrElement();
final Class firstClass = id.getClass();
while (iterator.hasNext()) {
id = iterator.next();
if (id == null || !id.getClass().equals(firstClass))
throw Graph.Exceptions.idArgsMustBeEitherIdOrElement();
}
}
```


---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

[jira] [Commented] (TINKERPOP-1063) TinkerGraph performance enhancements

[ASF GitHub Bot (JIRA)]

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

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

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

https://github.com/apache/tinkerpop/pull/342#discussion_r67415317
  
--- Diff: 
tinkergraph-gremlin/src/main/java/org/apache/tinkerpop/gremlin/tinkergraph/structure/TinkerGraph.java
 ---
@@ -358,6 +350,14 @@ public Features features() {
 return features;
 }
 
+private void validateHomogenousIds(final List ids) {
+final Class firstClass = ids.get(0).getClass();
+for (Object id : ids) {
+if (!id.getClass().equals(firstClass))
+throw Graph.Exceptions.idArgsMustBeEitherIdOrElement();
+}
+}
+
--- End diff --

This opens the door for NPE's.

```
gremlin> graph.vertices("a", null, 1)
java.lang.NullPointerException
Display stack trace? [yN] y
java.lang.NullPointerException
at 
org.apache.tinkerpop.gremlin.tinkergraph.structure.TinkerGraph.validateHomogenousIds(TinkerGraph.java:356)
at 
org.apache.tinkerpop.gremlin.tinkergraph.structure.TinkerGraph.createElementIterator(TinkerGraph.java:329)
at 
org.apache.tinkerpop.gremlin.tinkergraph.structure.TinkerGraph.vertices(TinkerGraph.java:269)
```

Suggestion with a few tweaks:

```
private void validateHomogenousIds(final List ids) {
final Iterator iterator = ids.iterator();
Object id = iterator.next();
if (id == null)
throw Graph.Exceptions.idArgsMustBeEitherIdOrElement();
final Class firstClass = id.getClass();
while (iterator.hasNext()) {
id = iterator.next();
if (id == null || !id.getClass().equals(firstClass))
throw Graph.Exceptions.idArgsMustBeEitherIdOrElement();
}
}
```


> TinkerGraph performance enhancements
> 
>
> Key: TINKERPOP-1063
> URL: https://issues.apache.org/jira/browse/TINKERPOP-1063
> Project: TinkerPop
>  Issue Type: Improvement
>  Components: tinkergraph
>Affects Versions: 3.1.0-incubating
>Reporter: stephen mallette
>Assignee: stephen mallette
> Fix For: 3.1.3
>
>
> Improve TinkerGraph performance in relation to the Ferma Benchmark which 
> shows a reasonably wide gap between TP2 and TP3.  We probably won't achieve 
> parity with Blueprints but it would be nice to carve away some time to lessen 
> the gap.
> https://github.com/Syncleus/Ferma-benchmark



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

[GitHub] tinkerpop issue #340: add RawExpression to gremlin_python

[leifurhauks]

Github user leifurhauks commented on the issue:

https://github.com/apache/tinkerpop/pull/340
  
@okram , I realized the current implementation of bindings as dicts is 
breaking 2/3 compatibility. It also makes it bit hairy to extract just the key 
in `RawExpression`. 

I would suggest using a tuple (e.g. `('symbol', value)` ) or a simple class 
that just has two data members. May I revise the bindings implementation?


---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

[GitHub] tinkerpop issue #342: TINKERPOP-1063 TinkerGraph Performance

[okram]

Github user okram commented on the issue:

https://github.com/apache/tinkerpop/pull/342
  
Do we know that its faster?


---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

[jira] [Commented] (TINKERPOP-1063) TinkerGraph performance enhancements

[ASF GitHub Bot (JIRA)]

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

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

GitHub user spmallette opened a pull request:

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

TINKERPOP-1063 TinkerGraph Performance

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

Got rid of `Stream` usage in TinkerGraph vertex/edge iteration.  Tests all 
pass with `mvn clean install`.

VOTE +1

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

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

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

https://github.com/apache/tinkerpop/pull/342.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 #342


commit 70dd3245eadcf2dd69720c50fbffd3b0c9e92922
Author: Stephen Mallette 
Date:   2015-12-22T21:43:45Z

Improved performance of TinkerGraph around element lookup.

Primary change was to drop use of Stream and use IteratorUtils.

commit e59b93ca4ec7ffbde4a4b91319f35f5d3fd9caeb
Author: Stephen Mallette 
Date:   2016-06-16T19:08:30Z

Made TinkerGraph validate that ids be homogeneous up front.

Take this approach rather than doing it during iteration so that TinkerPop 
semantics are respected and appropriate validation exceptions are thrown at the 
right time.

commit 099e6bc62468516974a3e76531d00444dbe89edc
Author: Stephen Mallette 
Date:   2016-06-16T19:32:58Z

Updated changelog.




> TinkerGraph performance enhancements
> 
>
> Key: TINKERPOP-1063
> URL: https://issues.apache.org/jira/browse/TINKERPOP-1063
> Project: TinkerPop
>  Issue Type: Improvement
>  Components: tinkergraph
>Affects Versions: 3.1.0-incubating
>Reporter: stephen mallette
>Assignee: stephen mallette
> Fix For: 3.1.3
>
>
> Improve TinkerGraph performance in relation to the Ferma Benchmark which 
> shows a reasonably wide gap between TP2 and TP3.  We probably won't achieve 
> parity with Blueprints but it would be nice to carve away some time to lessen 
> the gap.
> https://github.com/Syncleus/Ferma-benchmark



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

[GitHub] tinkerpop pull request #342: TINKERPOP-1063 TinkerGraph Performance

[spmallette]

GitHub user spmallette opened a pull request:

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

TINKERPOP-1063 TinkerGraph Performance

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

Got rid of `Stream` usage in TinkerGraph vertex/edge iteration.  Tests all 
pass with `mvn clean install`.

VOTE +1

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

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

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

https://github.com/apache/tinkerpop/pull/342.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 #342


commit 70dd3245eadcf2dd69720c50fbffd3b0c9e92922
Author: Stephen Mallette 
Date:   2015-12-22T21:43:45Z

Improved performance of TinkerGraph around element lookup.

Primary change was to drop use of Stream and use IteratorUtils.

commit e59b93ca4ec7ffbde4a4b91319f35f5d3fd9caeb
Author: Stephen Mallette 
Date:   2016-06-16T19:08:30Z

Made TinkerGraph validate that ids be homogeneous up front.

Take this approach rather than doing it during iteration so that TinkerPop 
semantics are respected and appropriate validation exceptions are thrown at the 
right time.

commit 099e6bc62468516974a3e76531d00444dbe89edc
Author: Stephen Mallette 
Date:   2016-06-16T19:32:58Z

Updated changelog.




---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

[jira] [Commented] (TINKERPOP-1063) TinkerGraph performance enhancements

[stephen mallette (JIRA)]

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

stephen mallette commented on TINKERPOP-1063:
-

Ended up implementing the latter in the comment above - tests pass now.

> TinkerGraph performance enhancements
> 
>
> Key: TINKERPOP-1063
> URL: https://issues.apache.org/jira/browse/TINKERPOP-1063
> Project: TinkerPop
>  Issue Type: Improvement
>  Components: tinkergraph
>Affects Versions: 3.1.0-incubating
>Reporter: stephen mallette
>Assignee: stephen mallette
> Fix For: 3.1.3
>
>
> Improve TinkerGraph performance in relation to the Ferma Benchmark which 
> shows a reasonably wide gap between TP2 and TP3.  We probably won't achieve 
> parity with Blueprints but it would be nice to carve away some time to lessen 
> the gap.
> https://github.com/Syncleus/Ferma-benchmark



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

[jira] [Commented] (TINKERPOP-939) Neo4jGraph should support HighAvailability (Neo4jHA).

[stephen mallette (JIRA)]

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

stephen mallette commented on TINKERPOP-939:


Just for future reference, in case there's a need to test again. You can open 
three Gremlin Console instances and then paste one of these in each:

{code}
conf = new BaseConfiguration()
conf.setProperty('gremlin.neo4j.directory','/tmp/neo4j.server1')
conf.setProperty('gremlin.neo4j.conf.ha.server_id','1')
conf.setProperty('gremlin.neo4j.conf.ha.initial_hosts','localhost:5001\\,localhost:5002\\,localhost:5003')
conf.setProperty('gremlin.neo4j.conf.ha.cluster_server','localhost:5001')
conf.setProperty('gremlin.neo4j.conf.ha.server','localhost:6001')
graph = Neo4jGraph.open(conf)

conf = new BaseConfiguration()
conf.setProperty('gremlin.neo4j.directory','/tmp/neo4j.server2')
conf.setProperty('gremlin.neo4j.conf.ha.server_id','2')
conf.setProperty('gremlin.neo4j.conf.ha.initial_hosts','localhost:5001\\,localhost:5002\\,localhost:5003')
conf.setProperty('gremlin.neo4j.conf.ha.cluster_server','localhost:5002')
conf.setProperty('gremlin.neo4j.conf.ha.server','localhost:6002')
graph = Neo4jGraph.open(conf)

conf = new BaseConfiguration()
conf.setProperty('gremlin.neo4j.directory','/tmp/neo4j.server3')
conf.setProperty('gremlin.neo4j.conf.ha.server_id','3')
conf.setProperty('gremlin.neo4j.conf.ha.initial_hosts','localhost:5001\\,localhost:5002\\,localhost:5003')
conf.setProperty('gremlin.neo4j.conf.ha.cluster_server','localhost:5003')
conf.setProperty('gremlin.neo4j.conf.ha.server','localhost:6003')
graph = Neo4jGraph.open(conf)
{code}

> Neo4jGraph should support HighAvailability (Neo4jHA).
> -
>
> Key: TINKERPOP-939
> URL: https://issues.apache.org/jira/browse/TINKERPOP-939
> Project: TinkerPop
>  Issue Type: Improvement
>  Components: neo4j
>Affects Versions: 3.1.0-incubating
>Reporter: Marko A. Rodriguez
>Assignee: stephen mallette
> Fix For: 3.1.3
>
>
> We should support Neo4j HA in the {{Neo4jGraph}} distribution.



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

[GitHub] tinkerpop issue #340: add RawExpression to gremlin_python

[leifurhauks]

Github user leifurhauks commented on the issue:

https://github.com/apache/tinkerpop/pull/340
  
> This is just for the GeoPoint-style adding classes?

More generally, it can be used to create expressions that make use of APIs, 
presumably provided by the graph vendor, that aren't strictly part of gremlin. 
My immediate use case is to call static methods on Titan's Geoshape class.

I'll add an example to the asciidoc.


---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

[jira] [Commented] (TINKERPOP-1332) Improve .explain() Dialogue

[Marko A. Rodriguez (JIRA)]

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

Marko A. Rodriguez commented on TINKERPOP-1332:
---

I now have {{prettyPrint(int maxLineWidth)}} and in the GremlinConsole, that 
line width is determined from JLine. Thus, we get it as such:

{code}
gremlin> g.V().out().out().out().out().repeat(out()).explain()
==>Traversal Explanation
=
Original Traversal [GraphStep(vertex,[]), 
VertexStep(OUT,vertex), VertexStep(OUT,vertex),
  VertexStep(OUT,vertex), 
VertexStep(OUT,vertex), RepeatStep([VertexStep(OUT,vertex),
  RepeatEndStep],until(false),emit(false))]

ConnectiveStrategy   [D]   [GraphStep(vertex,[]), 
VertexStep(OUT,vertex), VertexStep(OUT,vertex),
  VertexStep(OUT,vertex), 
VertexStep(OUT,vertex), RepeatStep([VertexStep(OUT,vertex),
  RepeatEndStep],until(false),emit(false))]
...
{code}

Make the window smaller in the same session and:

{code}
gremlin> g.V().out().out().out().out().out().explain()
==>Traversal Explanation
===
Original Traversal [GraphStep(vertex,[]), 
VertexStep(OUT,vertex),
  VertexStep(OUT,vertex), 
VertexStep(OUT,vertex),
  VertexStep(OUT,vertex), 
VertexStep(OUT,vertex)]

ConnectiveStrategy   [D]   [GraphStep(vertex,[]), 
VertexStep(OUT,vertex),
  VertexStep(OUT,vertex), 
VertexStep(OUT,vertex),
  VertexStep(OUT,vertex), 
VertexStep(OUT,vertex)]
...
{code}

The {{toString()}} is simply {{prettyPrint(Integer.MAX_LENGTH)}}. 

> Improve .explain() Dialogue 
> 
>
> Key: TINKERPOP-1332
> URL: https://issues.apache.org/jira/browse/TINKERPOP-1332
> Project: TinkerPop
>  Issue Type: Improvement
>  Components: process
>Affects Versions: 3.2.0-incubating
>Reporter: Russell Alexander Spitzer
>Assignee: Marko A. Rodriguez
>Priority: Minor
>
> Currently the output of explain gives you a long list of strategies but no 
> details about their application
> {code}
> ==>Traversal Explanation
> 
> Original Traversal [GraphStep(vertex,[]), CountGlobalStep]
> HaltedTraverserStrategy  [D]   [GraphStep(vertex,[]), CountGlobalStep]
> ConnectiveStrategy   [D]   [GraphStep(vertex,[]), CountGlobalStep]
> VertexProgramStrategy[D]   
> [TraversalVertexProgramStep([GraphStep(vertex,[]), CountGlobalStep]), 
> ComputerResultStep]
> OrderLimitStrategy   [O]   
> [TraversalVertexProgramStep([GraphStep(vertex,[]), CountGlobalStep]), 
> ComputerResultStep]
> IdentityRemovalStrategy  [O]   
> [TraversalVertexProgramStep([GraphStep(vertex,[]), CountGlobalStep]), 
> ComputerResultStep]
> FilterRankingStrategy[O]   
> [TraversalVertexProgramStep([GraphStep(vertex,[]), CountGlobalStep]), 
> ComputerResultStep]
> IncidentToAdjacentStrategy   [O]   
> [TraversalVertexProgramStep([GraphStep(vertex,[]), CountGlobalStep]), 
> ComputerResultStep]
> RangeByIsCountStrategy   [O]   
> [TraversalVertexProgramStep([GraphStep(vertex,[]), CountGlobalStep]), 
> ComputerResultStep]
> AdjacentToIncidentStrategy   [O]   
> [TraversalVertexProgramStep([GraphStep(vertex,[]), CountGlobalStep]), 
> ComputerResultStep]
> MatchPredicateStrategy   [O]   
> [TraversalVertexProgramStep([GraphStep(vertex,[]), CountGlobalStep]), 
> ComputerResultStep]
> GraphFilterStrategy  [O]   
> [TraversalVertexProgramStep([GraphStep(vertex,[]), CountGlobalStep]), 
> ComputerResultStep]
> PathProcessorStrategy[O]   
> [TraversalVertexProgramStep([GraphStep(vertex,[]), CountGlobalStep]), 
> ComputerResultStep]
> SparkInterceptorStrategy [P]   
> [TraversalVertexProgramStep([GraphStep(vertex,[]), CountGlobalStep]), 
> ComputerResultStep]
> SparkSingleIterationStrategy [P]   
> [TraversalVertexProgramStep([GraphStep(vertex,[]), CountGlobalStep]), 
> ComputerResultStep]
> ProfileStrategy  [F]   
> [TraversalVertexProgramStep([GraphStep(vertex,[]), CountGlobalStep]), 
> ComputerResultStep]
> LambdaRestrictionStrategy[V]   
> [TraversalVertexProgramStep([GraphStep(vertex,[]), CountGlobalStep]), 
> ComputerResultStep]
> ComputerVerificationStrategy [V]   
> [TraversalVertexProgramStep([GraphStep(vertex,[]), CountGlobalStep]), 
> 

[jira] [Commented] (TINKERPOP-1278) Implement Gremlin-Python and general purpose language variant test infrastructure

[ASF GitHub Bot (JIRA)]

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

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

Github user okram commented on the issue:

https://github.com/apache/tinkerpop/pull/340
  
How do we use this again? This is just for the `GeoPoint`-style adding 
classes? Can you provide an example so we can add it to the docs. See:


https://github.com/apache/tinkerpop/blob/TINKERPOP-1278/docs/src/reference/gremlin-variants.asciidoc




> Implement Gremlin-Python and general purpose language variant test 
> infrastructure
> -
>
> Key: TINKERPOP-1278
> URL: https://issues.apache.org/jira/browse/TINKERPOP-1278
> Project: TinkerPop
>  Issue Type: Improvement
>  Components: language-variant
>Affects Versions: 3.2.0-incubating
>Reporter: Marko A. Rodriguez
>Assignee: Marko A. Rodriguez
>
> As discussed on dev@...
> Apache TinkerPop should provide, out-of-the-box, at least 3 Gremlin language 
> variants. It would be cool if these were:
> * Python (Mark Henderson)
> * PHP ([~PommeVerte])
> * Ruby (?[~okram])
> I think each of these should be generated using the reflection-model 
> presented in 
> http://tinkerpop.apache.org/docs/3.2.1-SNAPSHOT/tutorials/gremlin-language-variants/.
>  Moreover, on every {{mvn clean install}}, the code for these variants is 
> generated.
> Given the desire to separate language variants from language drivers, I think 
> that a language driver for each variant above should be "plugable." Moreover, 
> we should provide one driver implementation for each -- simple GremlinServer 
> REST.
> {code}
> gremlin-variants/
>   gremlin-ruby/
> gremlin_ruby.rb
> gremlin_ruby_rest_driver.rb
>   gremlin-php/
> Gremlin_PHP.php
> Gremlin_PHP_REST_Driver.php
>   gremlin-python/
> gremlin-python.py
> gremlin-python-rest-driver.py
> {code}
> Next, each variant implementation should be testable. This is PAINFUL if we 
> have to implement each {{g_V_out_repeatXasXaXX}} test case in 
> {{ProcessXXXSuite}}. Perhaps some RegEx transducer magic could be used to 
> convert all those tests from Gremlin-Java to the respective host language? 
> However, even if we do that, we still have the problem of how to test the 
> returned results. 
> I think what we should test the returned results using the JVM. For instance, 
> JRuby, Jython, JPHP (does it exist?). If we do this, we will save ourselves a 
> massive headache. All we have to do is create a {{GraphProvider}} that uses 
> {{TinkerGraph}} and whose {{TraversalSource}} is some sort of wrapper around 
> reflection-generated Ruby (e.g.).
> {code}
> g.V.out_e("knows") // returns a Ruby iterator
> {code}
> That Ruby iterator should be converted to a Java iterator and then the 
> {{ProcessXXXSuite}} can verify the results.
> With this, most everything is reflectively constructed.
> {code}
> gremlin_ruby.rb // generated via Java reflection
> gremlin_ruby_rest_driver.rb // manually coded
> match_test.rb   // generated via RegEx transducer
> has_test.rb // generated via RegEx transducer
> ...
> RubyGraphProvider.java// manually coded
> RubyProcessStandardSuite.java // manually coded
> RubyProcessComputerSuite.java // manually coded
> {code}
> Thus, the testing data flow would be:
> {code}
> MatchTest.Traversals.java --transducer-> match_test.rb
> match-test.rb --REST--> GremlinServer
> GremlinServer --GraphSON-->match-test.rb
> GraphSON --JRuby/GraphSONReader-->Java objects
> Java objects --JRuby-->MatchTest.java 
> {code}



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

[GitHub] tinkerpop pull request #340: add RawExpression to gremlin_python

[leifurhauks]

GitHub user leifurhauks opened a pull request:

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

add RawExpression to gremlin_python

As described on dev@tinkerpop.apache.org thread gremlin_python GLV

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

$ git pull https://github.com/leifurhauks/incubator-tinkerpop raw_expr

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

https://github.com/apache/tinkerpop/pull/340.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 #340


commit 210d1a87fc0532b77ccf67bed57e149982b1e08a
Author: Leifur Halldor Asgeirsson 
Date:   2016-06-16T14:13:10Z

cpython gitignore

commit e931d21457441e91efc0cfc8b9e70a5a4592b80f
Author: Leifur Halldor Asgeirsson 
Date:   2016-06-16T15:59:58Z

add RawExpression to gremlin_python

As described on dev@tinkerpop.apache.org thread gremlin_python GLV




---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

Re: [DISCUSS] Gremlin Language variants in the Gremlin console

[Marko Rodriguez]

Yea — submodules is a good idea.

Also, I think we should create gremlin-jython, gremlin-ruby, etc. ScriptEngines 
that have all the imports loaded and ready to go much like we have with 
gremlin-groovy.

Marko.

http://markorodriguez.com



> On Jun 16, 2016, at 10:19 AM, Stephen Mallette  wrote:
> 
> I would think that we want individual plugins for each variant.
> 
> This does lead me back to an earlier discussion about gremlin-variant
> packaging. We didn't want to do
> 
> gremlin-variant
> +-- gremlin-variant-python
> +-- gremlin-variant-js,
> +-- 
> +-- gremlin-variant-X
> 
> so with gremlin-variant users are going to just get everything when they
> depend on it. To my knowledge, we are only kinda viewing this from a python
> perspective atm and haven't really researched all the languages we support,
> but I sense that ultimately as we add more GLVs we're going to end up with
> a really messy pom.xml for gremlin-variant with the potential for conflict
> as we try to make maven deal with packaging issues for all those disparate
> languages. Again, hard to say how much trouble this will eventually be, but
> might be worth noodling on again in case anyone has any new thoughts on the
> matter.
> 
> 
> 
> On Thu, Jun 16, 2016 at 12:10 PM, Daniel Kuppitz  wrote:
> 
>> The last few days I've been working on a Gremlin Python code executor for
>> the TinkerPop docs. What I noticed was that we can't simply execute Gremlin
>> Python code in our Gremlin Groovy console, simply because the console has
>> no dependency to the gremlin-variants projects.
>> 
>> That was unfortunate for the docs pre-processor, but what about the normal
>> user? Do we need to have those language variants always available or would
>> it be sufficient to have a Gremlin-Xyz plugin (where Xyz could be Python,
>> Ruby, etc.)?
>> 
>> I've added the "missing" dependency for now to get the docs pre-processor
>> extension done, but I think we should remove that dependency again and
>> create a plugin instead, before the branch gets merged into master.
>> 
>> Cheers,
>> Daniel
>> 

[jira] [Commented] (TINKERPOP-939) Neo4jGraph should support HighAvailability (Neo4jHA).

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on TINKERPOP-939:
--

Github user dkuppitz commented on the issue:

https://github.com/apache/tinkerpop/pull/339
  
VOTE: +1


> Neo4jGraph should support HighAvailability (Neo4jHA).
> -
>
> Key: TINKERPOP-939
> URL: https://issues.apache.org/jira/browse/TINKERPOP-939
> Project: TinkerPop
>  Issue Type: Improvement
>  Components: neo4j
>Affects Versions: 3.1.0-incubating
>Reporter: Marko A. Rodriguez
>Assignee: stephen mallette
> Fix For: 3.1.3
>
>
> We should support Neo4j HA in the {{Neo4jGraph}} distribution.



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

[GitHub] tinkerpop issue #339: TINKERPOP-939 Added docs for Neo4j HA configuration.

[dkuppitz]

Github user dkuppitz commented on the issue:

https://github.com/apache/tinkerpop/pull/339
  
VOTE: +1


---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

Re: Gremlin-Python package structure

[Stephen Mallette]

> Please make the changes as you see fit and provide a PR.

+1

On Thu, Jun 16, 2016 at 12:23 PM, Marko Rodriguez 
wrote:

> HI David,
>
> Please make the changes as you see fit and provide a PR. I read through
> your explanation and it “makes sense” with the limited knowledge I have.
> What I would really like to understand is this whole __init__.py business
> and how you structure and document/etc. everything.
>
> Thank you for thinking about this,
> Marko.
>
> http://markorodriguez.com
>
>
>
> > On Jun 16, 2016, at 10:09 AM, David Brown  wrote:
> >
> > Hello everyone,
> >
> > I was thinking about the current Gremlin-Python distribution package
> > structure and names. As is, a user will install with:
> >
> > pip install gremlinpython
> >
> > Then, imports in application code will be something like this:
> >
> > from gremlin_python import PythonGraphTraversalSource, GroovyTranslator
> > from gremlin_rest_driver import RESTRemoteConnection
> >
> > (assuming the REST driver is part of the package)
> >
> > Or, in the case of a driver developer using the provided base classes:
> >
> > from gremlin_driver import RemoteConnection, Traverser
> >
> > This works fine, but I think it would make more sense to consolidate
> > commonly used classes, modules, and packages under the gremlin_python
> > namespace. Then, installation and use would look something like:
> >
> > pip install gremlin_python
> >
> > from gremlin_python import RESTRemoteConnection, ...
> > from gremlin_python.gremlin_driver import RemoteConnection ...
> >
> > I think in general this is the expected pattern for a Python
> > developer. While style generally dictates that distribution package
> > names don't use underscores, as Leif pointed out, underscores are
> > syntactically fine and in this case they emulate the naming convention
> > (a dash) used with the other GLVs.
> >
> > Therefore, I would propose changing the distribution name to:
> > gremlin_python. Then, change the directory structure so the two other
> > packages (gremlin_driver, gremlin_rest_driver) are contained within
> > the directory gremlin_python and updating the imports in the __init__
> > files as necessary:
> >
> > jython/
> > ...
> > jython/gremlin_python/
> > jython/gremlin_python/gremlin_driver/  # or you could just remove the
> > jython/gremlin_python/gremlin_rest_driver/
> >
> > Alternatively, all three packages could be included in a new directory
> > called gremlin_python
> >
> > jython/
> > ...
> > jython/gremlin_python/gremlin_python/
> > jython/gremlin_python/gremlin_driver/  # or you could just remove the
> > jython/gremlin_python/gremlin_rest_driver/
> >
> >
> > Also, on another note, I think we should use absolute package imports
> > inside the gremlin_python package.
> >
> > Ideas? Again I am happy to make these changes in a PR, or a committer
> > can just go ahead and do it if everyone agrees.
> >
> > Best,
> > --
> > David M. Brown
> > R.A. CulturePlex Lab, Western University
>
>

Re: Gremlin-Python package structure

[Marko Rodriguez]

HI David,

Please make the changes as you see fit and provide a PR. I read through your 
explanation and it “makes sense” with the limited knowledge I have. What I 
would really like to understand is this whole __init__.py business and how you 
structure and document/etc. everything.

Thank you for thinking about this,
Marko.

http://markorodriguez.com



> On Jun 16, 2016, at 10:09 AM, David Brown  wrote:
> 
> Hello everyone,
> 
> I was thinking about the current Gremlin-Python distribution package
> structure and names. As is, a user will install with:
> 
> pip install gremlinpython
> 
> Then, imports in application code will be something like this:
> 
> from gremlin_python import PythonGraphTraversalSource, GroovyTranslator
> from gremlin_rest_driver import RESTRemoteConnection
> 
> (assuming the REST driver is part of the package)
> 
> Or, in the case of a driver developer using the provided base classes:
> 
> from gremlin_driver import RemoteConnection, Traverser
> 
> This works fine, but I think it would make more sense to consolidate
> commonly used classes, modules, and packages under the gremlin_python
> namespace. Then, installation and use would look something like:
> 
> pip install gremlin_python
> 
> from gremlin_python import RESTRemoteConnection, ...
> from gremlin_python.gremlin_driver import RemoteConnection ...
> 
> I think in general this is the expected pattern for a Python
> developer. While style generally dictates that distribution package
> names don't use underscores, as Leif pointed out, underscores are
> syntactically fine and in this case they emulate the naming convention
> (a dash) used with the other GLVs.
> 
> Therefore, I would propose changing the distribution name to:
> gremlin_python. Then, change the directory structure so the two other
> packages (gremlin_driver, gremlin_rest_driver) are contained within
> the directory gremlin_python and updating the imports in the __init__
> files as necessary:
> 
> jython/
> ...
> jython/gremlin_python/
> jython/gremlin_python/gremlin_driver/  # or you could just remove the
> jython/gremlin_python/gremlin_rest_driver/
> 
> Alternatively, all three packages could be included in a new directory
> called gremlin_python
> 
> jython/
> ...
> jython/gremlin_python/gremlin_python/
> jython/gremlin_python/gremlin_driver/  # or you could just remove the
> jython/gremlin_python/gremlin_rest_driver/
> 
> 
> Also, on another note, I think we should use absolute package imports
> inside the gremlin_python package.
> 
> Ideas? Again I am happy to make these changes in a PR, or a committer
> can just go ahead and do it if everyone agrees.
> 
> Best,
> -- 
> David M. Brown
> R.A. CulturePlex Lab, Western University

[GitHub] tinkerpop issue #336: TINKERPOP-1320 fix GremlinGroovyScriptEngineFileSandbo...

[spmallette]

Github user spmallette commented on the issue:

https://github.com/apache/tinkerpop/pull/336
  
`gremlin-core` just have tests that need the some of the same exact 
functions that are in `gremlin-test`, but the dependencies are such that 
`gremlin-core` can't use the `TestHelper` in `gremlin-test` and `gremlin-test` 
can't use the `TestHelper` in `gremlin-core` so there are two of them. 

I suppose we could move `TestHelper` out of `gremlin-core/test` to the main 
source code as a utility??? then there could be one. Or we publish 
`gremlin-core/test` as an artifiact which i kinda hate. Or we create a new 
dependency all together for `gremlin-core` and `gremlin-test` to depend on. All 
of the answers sorta stink i guess. Up until now, copying one file seemed to 
smell the best of all of them


---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

[DISCUSS] Gremlin Language variants in the Gremlin console

[Daniel Kuppitz]

The last few days I've been working on a Gremlin Python code executor for
the TinkerPop docs. What I noticed was that we can't simply execute Gremlin
Python code in our Gremlin Groovy console, simply because the console has
no dependency to the gremlin-variants projects.

That was unfortunate for the docs pre-processor, but what about the normal
user? Do we need to have those language variants always available or would
it be sufficient to have a Gremlin-Xyz plugin (where Xyz could be Python,
Ruby, etc.)?

I've added the "missing" dependency for now to get the docs pre-processor
extension done, but I think we should remove that dependency again and
create a plugin instead, before the branch gets merged into master.

Cheers,
Daniel

[GitHub] tinkerpop issue #339: TINKERPOP-939 Added docs for Neo4j HA configuration.

[okram]

Github user okram commented on the issue:

https://github.com/apache/tinkerpop/pull/339
  
Beautiful. Thank you for doing testing that and finally getting that ticket 
done. Crazy it worked the whole time we just didn't know... VOTE +1.


---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

[jira] [Commented] (TINKERPOP-939) Neo4jGraph should support HighAvailability (Neo4jHA).

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on TINKERPOP-939:
--

GitHub user spmallette opened a pull request:

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

TINKERPOP-939 Added docs for Neo4j HA configuration.

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

I manually tested this with a local 3 node cluster both in Gremlin Console 
and in Gremlin Server. Everything seems to work fine. I basically just wrote 
some basic docs for how to setup but since TinkerPop is really just a pass 
through for configuration options, most of the docs for "how" are on the Neo4j 
side.

I don't know that there is a way to do testing for this on our current 
framework or if there is a ton of value to doing so as this is all pass through 
- we don't even use a separate "HA Graph instance" like we did in Blueprints. 
Thoughts welcome on that matter

Personally, I think the docs are enough for now to close this old issue. If 
we really want tests we could open a new issue to write some "integration" 
tests that do some basic checks and would stand apart from the standard 
framework. So based on that

VOTE +1

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

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

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

https://github.com/apache/tinkerpop/pull/339.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 #339


commit 6220653868fc0c00a397456f9b7cceae82c3cb4a
Author: Stephen Mallette 
Date:   2016-06-16T15:54:02Z

Added docs for Neo4j HA configuration.




> Neo4jGraph should support HighAvailability (Neo4jHA).
> -
>
> Key: TINKERPOP-939
> URL: https://issues.apache.org/jira/browse/TINKERPOP-939
> Project: TinkerPop
>  Issue Type: Improvement
>  Components: neo4j
>Affects Versions: 3.1.0-incubating
>Reporter: Marko A. Rodriguez
>Assignee: Daniel Kuppitz
> Fix For: 3.1.3
>
>
> We should support Neo4j HA in the {{Neo4jGraph}} distribution.



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

[jira] [Assigned] (TINKERPOP-939) Neo4jGraph should support HighAvailability (Neo4jHA).

[stephen mallette (JIRA)]

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

stephen mallette reassigned TINKERPOP-939:
--

Assignee: stephen mallette  (was: Daniel Kuppitz)

> Neo4jGraph should support HighAvailability (Neo4jHA).
> -
>
> Key: TINKERPOP-939
> URL: https://issues.apache.org/jira/browse/TINKERPOP-939
> Project: TinkerPop
>  Issue Type: Improvement
>  Components: neo4j
>Affects Versions: 3.1.0-incubating
>Reporter: Marko A. Rodriguez
>Assignee: stephen mallette
> Fix For: 3.1.3
>
>
> We should support Neo4j HA in the {{Neo4jGraph}} distribution.



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

[jira] [Closed] (TINKERPOP-1328) Provide [gremlin-python] as an code executor in docs

[Daniel Kuppitz (JIRA)]

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

Daniel Kuppitz closed TINKERPOP-1328.
-
Resolution: Fixed

Done in branch {{TINKERPOP-1278}} in commit 
[e16ef67|https://github.com/apache/tinkerpop/commit/e16ef6736b7dfdd55b9e73b3e7dc93e4a042fbc8].

> Provide [gremlin-python] as an code executor in docs
> 
>
> Key: TINKERPOP-1328
> URL: https://issues.apache.org/jira/browse/TINKERPOP-1328
> Project: TinkerPop
>  Issue Type: Improvement
>  Components: documentation
>Affects Versions: 3.2.0-incubating
>Reporter: Marko A. Rodriguez
>Assignee: Daniel Kuppitz
> Fix For: 3.2.1
>
>
> We currently support {{[gremlin-groovy]}} and 
> {{[gremlin-groovy,modern]}}-style code block annotations. It would be good to 
> also support {{[gremlin-python]}} and {{[gremlin-python,modern]}}. Likewise, 
> ensure a generalization for the future when {{gremlin-ruby}} and 
> {{gremlin-php}} are added.
> Gremlin-Python source can be evaluated using Groovy and the Jython 
> ScriptEngine. Suppose the following code block:
> {code}
> [gremlin-python,modern]
> g.V().out().name
> {code}
> *GROOVY*
> First, assume the following startup code that should be evaluated once and 
> only once into the Gremlin-Groovy script engine.
> {code}
> import javax.script.ScriptEngineManager
> import javax.script.SimpleBindings
> loader = new URLClassLoader(new 
> File("/Applications/jython-2.7.0/jython.jar").toURI().toURL()) // JYTHON_PATH 
> is better
> jython = new ScriptEngineManager(loader).getEngineByName("jython")
> jython.eval("import sys");
> jython.eval("sys.path.append('/Users/marko/software/tinkerpop/gremlin-variant/src/main/jython/gremlin_python')");
>  // PYTHON_PATH is better
> jython.eval("from gremlin_python import *");
> jythonBindings = new SimpleBindings();
> jythonBindings.put("g", jython.eval("PythonGraphTraversalSource('g')"));
> jython.getContext().setBindings(jythonBindings, 
> javax.script.ScriptContext.GLOBAL_SCOPE);
> {code}
> *The above requires that a global variable exist to where Jython is installed 
> as well as to where Gremlin-Python is installed. Though, for the latter, you 
> will simply be able to use {{pip}} to install dynamically ({{PYTHON_PATH}}) 
> is set to the location of Gremlin-Python.*
> From there, the code block above would be evaluated as:
> {code}
> g = TinkerGraphFactory.createModern().traversal()
> Eval.me("g", g, jython.eval("g.V().out().name").toString())
> {code}
> This looks as follow:
> {code}
> gremlin> g = TinkerFactory.createModern().traversal()
> ==>graphtraversalsource[tinkergraph[vertices:6 edges:6], standard]
> gremlin> Eval.me("g", g, jython.eval("g.V().out().name").toString())
> ==>lop
> ==>vadas
> ==>josh
> ==>ripple
> ==>lop
> ==>lop
> {code}
> And thats that...



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

[jira] [Commented] (TINKERPOP-1320) GremlinGroovyScriptEngineFileSandboxTest throws error: URI is not hierarchical

[ASF GitHub Bot (JIRA)]

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

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

Github user pluradj commented on the issue:

https://github.com/apache/tinkerpop/pull/336
  
Can you expand on that more, re: the duplication on `TestHelper.java`? I'd 
bumped into the two classes previously but haven't spent any time trying to 
figure out the reason why there are two of them.


> GremlinGroovyScriptEngineFileSandboxTest throws error: URI is not hierarchical
> --
>
> Key: TINKERPOP-1320
> URL: https://issues.apache.org/jira/browse/TINKERPOP-1320
> Project: TinkerPop
>  Issue Type: Bug
>  Components: test-suite
>Affects Versions: 3.2.0-incubating, 3.1.2-incubating
>Reporter: Jason Plurad
>Assignee: Jason Plurad
>Priority: Minor
> Fix For: 3.1.3, 3.2.1
>
>
> This is similar to TINKERPOP-1317. The differences here are
> * The {{TestHelper.generateTempFileFromResource()}} call to load the resource 
> is happening from the {{public static void init()}} method before a graph 
> instance is available.
> * A reference to {{GremlinGroovyScriptEngineFileSandboxTest.class}} is still 
> required to located the {{sandbox.yaml}} found in the {{gremlin-test.jar}}.



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

[GitHub] tinkerpop issue #336: TINKERPOP-1320 fix GremlinGroovyScriptEngineFileSandbo...

[pluradj]

Github user pluradj commented on the issue:

https://github.com/apache/tinkerpop/pull/336
  
Can you expand on that more, re: the duplication on `TestHelper.java`? I'd 
bumped into the two classes previously but haven't spent any time trying to 
figure out the reason why there are two of them.


---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

[GitHub] tinkerpop issue #336: TINKERPOP-1320 fix GremlinGroovyScriptEngineFileSandbo...

[spmallette]

Github user spmallette commented on the issue:

https://github.com/apache/tinkerpop/pull/336
  
I didn't re-test this but both travis builds are good and the code looks 
right. Just a side note - @pluradj I didn't review this but note that we have a 
bit of an ugly reality where `TestHelper` has a twin over in 
`gremlin-core/test`. There are test classes in there that need that kind of 
functionality and since `gremlin-core` can't depend on `gremlin-test` I just 
copied the file. :grimacing: Note sure if any of your changes needs to be 
propagated over there or not, but probably something you should look at before 
you finalize this one and merge. Pending that little investigation:

VOTE +1


---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

[jira] [Commented] (TINKERPOP-1320) GremlinGroovyScriptEngineFileSandboxTest throws error: URI is not hierarchical

[ASF GitHub Bot (JIRA)]

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

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

Github user spmallette commented on the issue:

https://github.com/apache/tinkerpop/pull/336
  
I didn't re-test this but both travis builds are good and the code looks 
right. Just a side note - @pluradj I didn't review this but note that we have a 
bit of an ugly reality where `TestHelper` has a twin over in 
`gremlin-core/test`. There are test classes in there that need that kind of 
functionality and since `gremlin-core` can't depend on `gremlin-test` I just 
copied the file. :grimacing: Note sure if any of your changes needs to be 
propagated over there or not, but probably something you should look at before 
you finalize this one and merge. Pending that little investigation:

VOTE +1


> GremlinGroovyScriptEngineFileSandboxTest throws error: URI is not hierarchical
> --
>
> Key: TINKERPOP-1320
> URL: https://issues.apache.org/jira/browse/TINKERPOP-1320
> Project: TinkerPop
>  Issue Type: Bug
>  Components: test-suite
>Affects Versions: 3.2.0-incubating, 3.1.2-incubating
>Reporter: Jason Plurad
>Assignee: Jason Plurad
>Priority: Minor
> Fix For: 3.1.3, 3.2.1
>
>
> This is similar to TINKERPOP-1317. The differences here are
> * The {{TestHelper.generateTempFileFromResource()}} call to load the resource 
> is happening from the {{public static void init()}} method before a graph 
> instance is available.
> * A reference to {{GremlinGroovyScriptEngineFileSandboxTest.class}} is still 
> required to located the {{sandbox.yaml}} found in the {{gremlin-test.jar}}.



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

Re: [DISCUSS] S-Type

[Marko Rodriguez]

BTW: Here is GroovyTranslator for Gremlin-Python.

https://gist.github.com/okram/406157b21371a540d2641f52a4208760 


Realize that Translator exists as a class in both Java and in Python with 
identical APIs. … and will exist as such in JavaScript, Ruby, etc.

Its really not that complicated to create a Translator. The complication exists 
in XXXTraversal, XXXTraversalSource, and XXXAnonymousTraversal:
https://gist.github.com/okram/fe6bdfe36b970af73b2bcb9e3cfc5e3d 

..but that is written once and used over and over by various translators. 
Moreover, that source code is generated automagically via introspection into 
the Gremlin-Java API.
https://gist.github.com/okram/88f0ddbd9d0d257d1113b0740260a6b6 


Marko.

http://markorodriguez.com



> On Jun 16, 2016, at 7:35 AM, Marko Rodriguez  wrote:
> 
> Hello,
> 
>> I think this is generally on the right track as there aren't many other
>> tracks to get this to work. Is it possible to leave open the option for a
>> language that is translating into itself (e.g. javascript to javascript) to
>> have the ability to take a non-string lambda if it is a language that is
>> capable of inspecting itself to get the string representation of its own
>> code?
> 
> Yes. So with Python we can inspect the lambda. Thus, if you are in CPython 
> and want to submit a Gremlin-Python traversal to GremlinServer running 
> Jython, then the PythonTranslator would NOT just evaluate the lambda for a 
> String, but instead would do the following — inspect the lambda for a String:
> 
> >>> from dill.source import getsource
> >>> x = lambda a: a + 2
> >>> x
>  at 0x10bfe70c8>
> >>> getsource(x)
> 'x = lambda a: a + 2\n'
> >>>
> 
> Realize that since we have decoupled the “translator” from the “language,” 
> anyone can use Gremlin-Python and write their own translator. That translator 
> can do as they please with each step(args). Thus, CPython->Jython can do as 
> above with lambdas and introspect to get the code string during translation. 
> For Gremlin-Python with GroovyTranslator, the best I have come up with is:
> 
> >>> g.V().out().map(lambda: "it.get().value('name')")
> g.V().out().map({it.get().value('name')})
> 
> Now, another drawback of “the best I have come up with" is that the 
> translator’s target language is showing up in the host language. That is, the 
> traversal above is forced to use a GroovyTranslator and thus is not portable 
> to any other translator. While, if a traversal did NOT have lambdas, you 
> could easily change the translator and everything would just work as expected.
> 
> Take care,
> Marko.
> 
> http://markorodriguez.com 
> 
> 
>> 
>> On Thu, Jun 16, 2016 at 2:12 AM, Daniel Kuppitz > > wrote:
>> 
>>> I wouldn't say that I like it, cause code as a String will always be very
>>> error prone, but still, it's likely the only way to get lambdas working in
>>> all language variants. Hence: "cool".
>>> 
>>> Cheers,
>>> Daniel
>>> 
>>> 
>>> On Thu, Jun 16, 2016 at 12:03 AM, Marko Rodriguez >> >
>>> wrote:
>>> 
 Hi,
 
 What do people think of this idea:
 
https://gist.github.com/okram/df6a104bde51a4f4f6f0da11f46909d5 
  <
 https://gist.github.com/okram/df6a104bde51a4f4f6f0da11f46909d5 
 >
 
 If you pass a lambda/closure/anonymousFunction/etc. in the respective
 language (during translation), it calls it to get the string
 representation. … ?
 
 Marko.
 
 http://markorodriguez.com 
 
 
 
> On Jun 15, 2016, at 10:50 AM, Marko Rodriguez 
 wrote:
> 
> Hello,
> 
> I think we should introduce an S object. It would stand for Script and
 would allow you to do:
> 
> S.f(“{ it.length }”)
> 
> Where does this come in handy? Language variants.
> 
> Imagine using gremlin_python that will compile to Gremlin-Groovy for
 execution at GremlinServer.
> 
>  g.V().out(“knows”)[0:2].name.map(f(“{ it.length }”))
> 
> Next, imagine you are in Gremlin-Java and want to submit a traversal to
 GremlinServer, but it has a lambda. No worries, just use the
 GroovyTranslator and you have:
> 
>  g.V().out(“knows”).limit(2).values(“name”).map(f(“{ it.length
>>> }”))
> 
> We could also have:
> 
>  S.s = supplier
>  S.c = consumer
>  S.f = function
>  S.o = operator
> 
> This gets to the general problem of being able to translate 

[jira] [Closed] (TINKERPOP-1301) Provide Javadoc for ScriptInput/OutputFormat's

[stephen mallette (JIRA)]

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

stephen mallette closed TINKERPOP-1301.
---
   Resolution: Done
 Assignee: stephen mallette
Fix Version/s: 3.2.1
   3.1.3

> Provide Javadoc for ScriptInput/OutputFormat's
> --
>
> Key: TINKERPOP-1301
> URL: https://issues.apache.org/jira/browse/TINKERPOP-1301
> Project: TinkerPop
>  Issue Type: Improvement
>  Components: documentation
>Affects Versions: 3.2.0-incubating
>Reporter: Lewis John McGibbney
>Assignee: stephen mallette
>Priority: Minor
> Fix For: 3.1.3, 3.2.1
>
>
> Right now 
> [ScriptInputFormat|http://tinkerpop.apache.org/javadocs/3.2.1-SNAPSHOT/full/index.html?org/apache/tinkerpop/gremlin/hadoop/structure/io/script/ScriptInputFormat.html]
>  and 
> [ScriptOutputFormat|http://tinkerpop.apache.org/javadocs/3.2.1-SNAPSHOT/full/index.html?org/apache/tinkerpop/gremlin/hadoop/structure/io/script/ScriptOutputFormat.html]
>  are not documented. Descriptions are however present over on some old 
> [TitanDB 
> documentation|http://s3.thinkaurelius.com/docs/titan/0.5.0/script-io-format.html]
>  which can be used to provide Javadoc level documentation for developers. 



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

[jira] [Commented] (TINKERPOP-1139) [Neo4JGraph] GraphTraversal with SubgraphStrategy removes addLabelStep (as("b"))

[stephen mallette (JIRA)]

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

stephen mallette commented on TINKERPOP-1139:
-

[~mm33] thanks for reporting this - it will be fixed in the 3.1.3 and 3.2.1 
releases.

> [Neo4JGraph] GraphTraversal with SubgraphStrategy removes addLabelStep 
> (as("b"))
> 
>
> Key: TINKERPOP-1139
> URL: https://issues.apache.org/jira/browse/TINKERPOP-1139
> Project: TinkerPop
>  Issue Type: Bug
>  Components: neo4j
>Affects Versions: 3.1.0-incubating
>Reporter: Martijn Maas
>Assignee: stephen mallette
> Fix For: 3.1.3, 3.2.1
>
>
> I am using the Neo4jGraph with the following SubgraphStrategy:
> {code}
> SubgraphStrategy.build().vertexCriterion(has("isLatest", true)).create();
> {code}
> I have 2 traversals. This one working works:
> {code}
> Map languageCounts =  
> searchResult.as("a").inE("isCreatedBy").outV().outE("hasWorkLanguage").inV().as("b").dedup("a",
>  "b")
>   .has("wwlanguage_name").groupCount()
> .by("wwlanguage_name").next();
> {code}
> This translates to:
> {code}
> [Neo4jGraphStep([],vertex)@[a], 
> TraversalFilterStep([HasStep([isLatest.eq(true)])]), 
> VertexStep(IN,[isCreatedBy],edge), 
> TraversalFilterStep([AndStep([[EdgeVertexStep(IN), 
> TraversalFilterStep([HasStep([isLatest.eq(true)])]), 
> TraversalFilterStep([HasStep([isLatest.eq(true)])])], [EdgeVertexStep(OUT), 
> TraversalFilterStep([HasStep([isLatest.eq(true)])]), 
> TraversalFilterStep([HasStep([isLatest.eq(true)])])]])]), 
> EdgeVertexStep(OUT), TraversalFilterStep([HasStep([isLatest.eq(true)])]), 
> VertexStep(OUT,[hasWorkLanguage],edge), 
> TraversalFilterStep([AndStep([[EdgeVertexStep(IN), 
> TraversalFilterStep([HasStep([isLatest.eq(true)])]), 
> TraversalFilterStep([HasStep([isLatest.eq(true)])])], [EdgeVertexStep(OUT), 
> TraversalFilterStep([HasStep([isLatest.eq(true)])]), 
> TraversalFilterStep([HasStep([isLatest.eq(true)])])]])]), 
> EdgeVertexStep(IN)@[b], TraversalFilterStep([HasStep([isLatest.eq(true)])]), 
> TraversalFilterStep([PropertiesStep([wwlanguage_name],property)]), 
> DedupGlobalStep([a, b]), GroupCountStep(value(wwlanguage_name))]
> {code}
> This one fails:
> {code}
> Map languageCounts = 
> searchResult.as("a").in("isCreatedBy").out("hasWorkLanguage").as("b")
>.dedup("a", 
> "b").has("wwlanguage_name")
>   .groupCount().by("wwlanguage_name").next();
> {code}
> This translates to:
> {code}
> [Neo4jGraphStep([],vertex)@[a], 
> TraversalFilterStep([HasStep([isLatest.eq(true)])]), 
> VertexStep(IN,[isCreatedBy],edge), 
> TraversalFilterStep([AndStep([[EdgeVertexStep(IN), 
> TraversalFilterStep([HasStep([isLatest.eq(true)])]), 
> TraversalFilterStep([HasStep([isLatest.eq(true)])])], [EdgeVertexStep(OUT), 
> TraversalFilterStep([HasStep([isLatest.eq(true)])]), 
> TraversalFilterStep([HasStep([isLatest.eq(true)])])]])]), 
> EdgeVertexStep(OUT), TraversalFilterStep([HasStep([isLatest.eq(true)])]), 
> VertexStep(OUT,[hasWorkLanguage],edge), 
> TraversalFilterStep([AndStep([[EdgeVertexStep(IN), 
> TraversalFilterStep([HasStep([isLatest.eq(true)])]), 
> TraversalFilterStep([HasStep([isLatest.eq(true)])])], [EdgeVertexStep(OUT), 
> TraversalFilterStep([HasStep([isLatest.eq(true)])]), 
> TraversalFilterStep([HasStep([isLatest.eq(true)])])]])]), EdgeVertexStep(IN), 
> TraversalFilterStep([HasStep([isLatest.eq(true)])]), 
> TraversalFilterStep([PropertiesStep([wwlanguage_name],property)]), 
> DedupGlobalStep([a, b]), GroupCountStep(value(wwlanguage_name))]
> {code}
> The failing query misses the '@[b]' of the last EdgeVertexStep(IN).



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