[jira] [Commented] (TINKERPOP-1616) Strengthen semantics around lazy iteration and graph modifications

[Daniel Kuppitz (JIRA)]

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

Daniel Kuppitz commented on TINKERPOP-1616:
---

I think we had this discussion on the list before. Or Slack? Dunno.. Anyway, I 
don't think we can say that one result is right and the other is wrong. Maybe 
{{LazyEvaluation}} should be a graph feature..?

> Strengthen semantics around lazy iteration and graph modifications
> --
>
> Key: TINKERPOP-1616
> URL: https://issues.apache.org/jira/browse/TINKERPOP-1616
> Project: TinkerPop
>  Issue Type: Improvement
>  Components: structure
>Affects Versions: 3.2.3
>Reporter: pieter martin
>
> The investigation started with the a bothE query where Sqlg returned 
> different results to TinkerGraph
> {code}
> @Test
> public void testLazy1() {
> final TinkerGraph graph = TinkerGraph.open();
> final Vertex a1 = graph.addVertex(T.label, "A");
> final Vertex b1 = graph.addVertex(T.label, "B");
> final Vertex c1 = graph.addVertex(T.label, "C");
> a1.addEdge("ab", b1);
> a1.addEdge("ac", c1);
> AtomicInteger count = new AtomicInteger(0);
> graph.traversal().V(a1).bothE().forEachRemaining(edge -> {
> a1.addEdge("ab", b1);
> c1.addEdge("ac", a1);
> count.getAndIncrement();
> });
> Assert.assertEquals(2, count.get());
> }
> {code}
> For this query TinkerGraph returns 2 and passes.
> Sqlg however returns 3. The reason being that it lazily iterates the out() 
> first and then the in().
> The following gremlin is the same but using a union(out(), in()) instead of 
> bothE()
> {code}
> @Test
> public void testLazy2() {
> final TinkerGraph graph = TinkerGraph.open();
> final Vertex a1 = graph.addVertex(T.label, "A");
> final Vertex b1 = graph.addVertex(T.label, "B");
> final Vertex c1 = graph.addVertex(T.label, "C");
> a1.addEdge("ab", b1);
> a1.addEdge("ac", c1);
> AtomicInteger count = new AtomicInteger(0);
> graph.traversal().V(a1).union(__.outE(), __.inE()).forEachRemaining(edge 
> -> {
> a1.addEdge("ab", b1);
> c1.addEdge("ac", a1);
> count.getAndIncrement();
> });
> Assert.assertEquals(2, count.get());
> }
> {code}
> In this case TinkerGraph returns 4 and Sqlg 6
> TinkerGraph returns 4 as it first walks the 2 out edges and adds 2 in edges 
> which it sees when traversing the in().
> Sqlg return 6 as it lazier than TinkerGraph.
> It first walks the "ac" out edge and adds in the 2 edges.
> Then walks "ab" and gets 2 edges. The original and the one added previously.
> It then walks "ac" in and gets 3 edges as 3 has been added so far.
> All and all 6.
> I am not sure whats the expected semantics. Sqlg is lazier than TinkerGraph 
> but not completely lazy either as it depends more on the meta data and number 
> of queries it needs to execute to walk a particular gremlin query.
> I am somewhat of the opinion that without enforcing a eager iteration when 
> modifying a graph the semantics will be different for different implementors.
> For Sqlg at least it will be hard for clients to predict the behavior.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[GitHub] tinkerpop pull request #629: TINKERPOP-1552: Clean-up Gremlin-DotNet project...

[FlorianHockmann]

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

https://github.com/apache/tinkerpop/pull/629#discussion_r122460079
  
--- Diff: gremlin-dotnet/glv/AnonymousTraversal.template ---
@@ -27,6 +27,8 @@ using Gremlin.Net.Structure;
 // THIS IS A GENERATED FILE - DO NOT MODIFY THIS FILE DIRECTLY - see 
pom.xml
 namespace Gremlin.Net.Process.Traversal
 {
+#pragma warning disable 1591
--- End diff --

Done.


---
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-1552) C# Gremlin Language Variant

[stephen mallette (JIRA)]

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

stephen mallette commented on TINKERPOP-1552:
-

dahtree - tree is killing us right now. soo many issues with tree. 

StarGraph is probably ok - it is unlikely that it would be returned via GLV 
processes. Some day we will need Graph, as {{subgraph()}} step can't work 
without it, but that opens a fairly large body of work. It would be very cool 
though. Note comments on TINKERPOP-1417

> C# Gremlin Language Variant
> ---
>
> Key: TINKERPOP-1552
> URL: https://issues.apache.org/jira/browse/TINKERPOP-1552
> Project: TinkerPop
>  Issue Type: Improvement
>  Components: language-variant
>Affects Versions: 3.2.3
>Reporter: Jorge Bay
>Assignee: stephen mallette
>
> It would be nice to have a C# GLV that runs under .NET Framework 4.5+ and 
> .NET Core.
> The maven build could use the Exec Maven Plugin to exec .NET Core's [dotnet 
> test|https://www.microsoft.com/net/core#macos] command.
> Some requirements, from the mailing list (edited):
> {quote}
> 1. The GLV should keep in line with class/method names of the java API
> where possible to ensure consistency of feel across languages.
> 2. There needs to be adequate tests (we're still discussing the approach to
> testing GLVs and i think that needs to be tackled sooner than later as more
> GLVs start to come in). Those tests should produce xunit style output
> unless there is some good reason not to.
> 3. There needs to be adequate documentation (e.g. Reference docs)
> 4. The build/deploy process needs to be bound to maven which might be one of 
> the trickier bits to deal with.
> {quote}



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Commented] (TINKERPOP-1684) Improper results with union() in a by()

[stephen mallette (JIRA)]

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

stephen mallette commented on TINKERPOP-1684:
-

This issue could have some relation to TINKERPOP-1693 as the use of {{tree()}} 
with {{by()}} seems to open up the chance for bad stuff to happen.

> Improper results with union() in a by()
> ---
>
> Key: TINKERPOP-1684
> URL: https://issues.apache.org/jira/browse/TINKERPOP-1684
> Project: TinkerPop
>  Issue Type: Bug
>  Components: process
>Affects Versions: 3.2.4
>Reporter: stephen mallette
>
> There are some odd results when using a {{union()}} inside a {{by()}}. These 
> problems were initially found in {{tree().by()}} as follows:
> {code}
> gremlin> g.V(1).repeat(out()).emit().tree().next()
> ==>v[1]={v[2]={}, v[3]={}, v[4]={v[3]={}, v[5]={}}}
> gremlin> g.V(1).repeat(out()).emit().tree().by('name').next()
> ==>marko={vadas={}, josh={ripple={}, lop={}}, lop={}}
> gremlin> 
> g.V(1).repeat(out()).emit().tree().by(union(__(),repeat(out()).emit().count()).fold()).next()
> ==>[0, v[1], 5]={[0, v[4], 2]={[0, v[5]]={}}}
> ==>[v[1], 5]={[0, v[2]]={}, [0, v[3]]={}, [0, v[4], 2]={[0, v[3]]={}}}
> {code}
> For some reason the final traversal returns two entries to tree where there 
> are extra "0" values in the lists that we can't seem to account for. So, i 
> suppose this is either a bug or we need some explanation for why the extra 
> zeroes are there. 



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Closed] (TINKERPOP-1637) Expose metrics attributes in string output

[stephen mallette (JIRA)]

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

stephen mallette closed TINKERPOP-1637.
---
   Resolution: Duplicate
Fix Version/s: (was: 3.2.6)

I guess a new issue was created for this on TINKERPOP-1688 - the work is being 
done there.

> Expose metrics attributes in string output
> --
>
> Key: TINKERPOP-1637
> URL: https://issues.apache.org/jira/browse/TINKERPOP-1637
> Project: TinkerPop
>  Issue Type: Improvement
>  Components: process
>Affects Versions: 3.2.4
>Reporter: Bryn Cooke
>
> Currently the profile step won't expose metrics attributes in the string 
> output. This means that useful information provided by graph implementations 
> is never output.
> It would be great if the attributes could be output indented under each 
> metric.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Updated] (TINKERPOP-1686) Make TraversalMetrics thread safe

[stephen mallette (JIRA)]

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

stephen mallette updated TINKERPOP-1686:

Fix Version/s: 3.2.6

> Make TraversalMetrics thread safe
> -
>
> Key: TINKERPOP-1686
> URL: https://issues.apache.org/jira/browse/TINKERPOP-1686
> Project: TinkerPop
>  Issue Type: Improvement
>  Components: process
>Affects Versions: 3.2.4
>Reporter: stephen mallette
>Assignee: stephen mallette
> Fix For: 3.2.6
>
>
> Ensure that it is possible to write to metrics from multiple threads.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Commented] (TINKERPOP-1650) PathRetractionStrategy makes Match steps unsolvable

[Ted Wilmes (JIRA)]

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

Ted Wilmes commented on TINKERPOP-1650:
---

Yes, I still plan on fixing this one.

> PathRetractionStrategy makes Match steps unsolvable
> ---
>
> Key: TINKERPOP-1650
> URL: https://issues.apache.org/jira/browse/TINKERPOP-1650
> Project: TinkerPop
>  Issue Type: Bug
>  Components: process
>Affects Versions: 3.2.3, 3.2.4
>Reporter: Branden Moore
>Assignee: Ted Wilmes
>
> The `PathRetractionStrategy` can make certain Match() steps "Unsolvable".
> This (nonsensical) example demonstrates the issue:
> {code}
> gremlin> g = graph.traversal()
> ==>graphtraversalsource[tinkergraph[vertices:6 edges:6], standard]
> gremlin> 
> g.V().hasLabel("person").as("perp").match(__.as("a").out("created").as("sw"), 
> __.as("sw").has("lang", "java").as("java")).where("sw", 
> neq("a")).select("perp")
> The provided match pattern is unsolvable: [[MatchStartStep(a), 
> VertexStep(OUT,[created],vertex), MatchEndStep(sw)], [MatchStartStep(sw), 
> HasStep([lang.eq(java)]), MatchEndStep(java)], [MatchStartStep(sw), 
> WherePredicateStep(neq(a)), MatchEndStep]]
> Type ':help' or ':h' for help.
> Display stack trace? [yN]n
> gremlin> 
> {code}
> If we remove the `PathRetractionStrategy`, or use `g.withPath()` the match 
> step is solvable, and works fine.
> {code}
> g.withoutStrategies(PathRetractionStrategy).V().hasLabel("person").as("perp").match(__.as("a").out("created").as("sw"),
>  __.as("sw").has("lang", "java").as("java")).where("sw", 
> neq("a")).select("perp")
> ==>v[1]
> ==>v[4]
> ==>v[4]
> ==>v[6]
> gremlin> 
> g.withPath().V().hasLabel("person").as("perp").match(__.as("a").out("created").as("sw"),
>  __.as("sw").has("lang", "java").as("java")).where("sw", 
> neq("a")).select("perp")
> ==>v[1]
> ==>v[4]
> ==>v[4]
> ==>v[6]
> gremlin> 
> {code}



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Commented] (TINKERPOP-1650) PathRetractionStrategy makes Match steps unsolvable

[stephen mallette (JIRA)]

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

stephen mallette commented on TINKERPOP-1650:
-

[~twilmes] are you still planning to look at this one?

> PathRetractionStrategy makes Match steps unsolvable
> ---
>
> Key: TINKERPOP-1650
> URL: https://issues.apache.org/jira/browse/TINKERPOP-1650
> Project: TinkerPop
>  Issue Type: Bug
>  Components: process
>Affects Versions: 3.2.3, 3.2.4
>Reporter: Branden Moore
>Assignee: Ted Wilmes
>
> The `PathRetractionStrategy` can make certain Match() steps "Unsolvable".
> This (nonsensical) example demonstrates the issue:
> {code}
> gremlin> g = graph.traversal()
> ==>graphtraversalsource[tinkergraph[vertices:6 edges:6], standard]
> gremlin> 
> g.V().hasLabel("person").as("perp").match(__.as("a").out("created").as("sw"), 
> __.as("sw").has("lang", "java").as("java")).where("sw", 
> neq("a")).select("perp")
> The provided match pattern is unsolvable: [[MatchStartStep(a), 
> VertexStep(OUT,[created],vertex), MatchEndStep(sw)], [MatchStartStep(sw), 
> HasStep([lang.eq(java)]), MatchEndStep(java)], [MatchStartStep(sw), 
> WherePredicateStep(neq(a)), MatchEndStep]]
> Type ':help' or ':h' for help.
> Display stack trace? [yN]n
> gremlin> 
> {code}
> If we remove the `PathRetractionStrategy`, or use `g.withPath()` the match 
> step is solvable, and works fine.
> {code}
> g.withoutStrategies(PathRetractionStrategy).V().hasLabel("person").as("perp").match(__.as("a").out("created").as("sw"),
>  __.as("sw").has("lang", "java").as("java")).where("sw", 
> neq("a")).select("perp")
> ==>v[1]
> ==>v[4]
> ==>v[4]
> ==>v[6]
> gremlin> 
> g.withPath().V().hasLabel("person").as("perp").match(__.as("a").out("created").as("sw"),
>  __.as("sw").has("lang", "java").as("java")).where("sw", 
> neq("a")).select("perp")
> ==>v[1]
> ==>v[4]
> ==>v[4]
> ==>v[6]
> gremlin> 
> {code}



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

Re: [VOTE] TinkerPop 3.2.5 Release

[Ted Wilmes]

VOTE: +1

--Ted

On Fri, Jun 16, 2017 at 3:18 AM, Daniel Kuppitz  wrote:

> bin/validate-distribution.sh still looking good.
>
> VOTE: +1
>
>
> On Thu, Jun 15, 2017 at 10:33 PM, Stephen Mallette 
> wrote:
>
> > Hello (again),
> >
> > We are happy to announce (again) that TinkerPop 3.2.5 is ready for
> release.
> >
> > The release artifacts can be found at this location:
> > https://dist.apache.org/repos/dist/dev/tinkerpop/3.2.5/
> >
> > The source distribution is provided by:
> > apache-tinkerpop-3.2.5-src.zip
> >
> > Two binary distributions are provided for user convenience:
> > apache-tinkerpop-gremlin-console3.2.5-bin.zip
> > apache-tinkerpop-gremlin-server-3.2.5-bin.zip
> >
> > The GPG key used to sign the release artifacts is available at:
> > https://dist.apache.org/repos/dist/dev/tinkerpop/KEYS
> >
> > The online docs can be found here:
> > http://tinkerpop.apache.org/docs/3.2.5/ (user docs)
> > http://tinkerpop.apache.org/docs/3.2.5/upgrade/ (upgrade docs)
> > http://tinkerpop.apache.org/javadocs/3.2.5/core/ (core javadoc)
> > http://tinkerpop.apache.org/javadocs/3.2.5/full/ (full javadoc)
> >
> > The tag in Apache Git can be found here:
> >
> > https://git-wip-us.apache.org/repos/asf?p=tinkerpop.git;a=tag;h=
> > 0ecbb067a212711a6b996af828cc932956282dcc
> >
> > The release notes are available here:
> >
> > https://github.com/apache/tinkerpop/blob/master/
> > CHANGELOG.asciidoc#tinkerpop-320-nine-inch-gremlins
> >
> > The [VOTE] will be open for the next 72 hours --- closing Sunday (June
> 18,
> > 2017) at  4:30pm EST
> >
> > My vote is +1 (again).
> >
> > Thank you very much,
> > Stephen
> >
>

[RESULT][VOTE] TinkerPop 3.1.7 Release

[Ted Wilmes]

This vote is now closed with a total of 3 +1s, no +0s and no -1s. The
results are:

BINDING VOTES:

+1  (3 -- Ted Wilmes, Stephen Mallette, Daniel Kuppitz)
  0  (0)
 -1  (0)

NON-BINDING VOTES:

+1 (0)
  0 (0)
 -1 (0)

Thank you very much,
Ted Wilmes

[jira] [Updated] (TINKERPOP-1637) Expose metrics attributes in string output

[stephen mallette (JIRA)]

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

stephen mallette updated TINKERPOP-1637:

Fix Version/s: 3.2.6

> Expose metrics attributes in string output
> --
>
> Key: TINKERPOP-1637
> URL: https://issues.apache.org/jira/browse/TINKERPOP-1637
> Project: TinkerPop
>  Issue Type: Improvement
>  Components: process
>Affects Versions: 3.2.4
>Reporter: Bryn Cooke
> Fix For: 3.2.6
>
>
> Currently the profile step won't expose metrics attributes in the string 
> output. This means that useful information provided by graph implementations 
> is never output.
> It would be great if the attributes could be output indented under each 
> metric.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Commented] (TINKERPOP-1632) Create a set of default functions

[stephen mallette (JIRA)]

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

stephen mallette commented on TINKERPOP-1632:
-

Might be more palatable to do if TINKERPOP-1417 was in place.

> Create a set of default functions
> -
>
> Key: TINKERPOP-1632
> URL: https://issues.apache.org/jira/browse/TINKERPOP-1632
> Project: TinkerPop
>  Issue Type: Improvement
>  Components: process
>Affects Versions: 3.3.0
>Reporter: Daniel Kuppitz
>
> We already have a a set of default BiFunctions / operators, that are not 
> treated as lambdas. We should also have a bunch of simple functions, that can 
> then be used in {{map()}} or {{sack()}} and that can be serialized as 
> bytecode. For example:
> {noformat}
> ...map(sqrt)
> ...map(log)
> ...sack(sigmoid) // compute sigmoid of the current sack and update the 
> sack
> ...sack(cos).by("x") // compute the cosine of the current element's "x" and 
> assign / overwrite the current sack value
> {noformat}



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Commented] (TINKERPOP-1616) Strengthen semantics around lazy iteration and graph modifications

[stephen mallette (JIRA)]

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

stephen mallette commented on TINKERPOP-1616:
-

[~pietermartin] i just noticed this issue. i tend to feel like TinkerGraph has 
what I would expect as a user. What I add as side-efffects probably shouldn't 
reflect in the output. 

cc/ [~dkuppitz]

> Strengthen semantics around lazy iteration and graph modifications
> --
>
> Key: TINKERPOP-1616
> URL: https://issues.apache.org/jira/browse/TINKERPOP-1616
> Project: TinkerPop
>  Issue Type: Improvement
>  Components: structure
>Affects Versions: 3.2.3
>Reporter: pieter martin
>
> The investigation started with the a bothE query where Sqlg returned 
> different results to TinkerGraph
> {code}
> @Test
> public void testLazy1() {
> final TinkerGraph graph = TinkerGraph.open();
> final Vertex a1 = graph.addVertex(T.label, "A");
> final Vertex b1 = graph.addVertex(T.label, "B");
> final Vertex c1 = graph.addVertex(T.label, "C");
> a1.addEdge("ab", b1);
> a1.addEdge("ac", c1);
> AtomicInteger count = new AtomicInteger(0);
> graph.traversal().V(a1).bothE().forEachRemaining(edge -> {
> a1.addEdge("ab", b1);
> c1.addEdge("ac", a1);
> count.getAndIncrement();
> });
> Assert.assertEquals(2, count.get());
> }
> {code}
> For this query TinkerGraph returns 2 and passes.
> Sqlg however returns 3. The reason being that it lazily iterates the out() 
> first and then the in().
> The following gremlin is the same but using a union(out(), in()) instead of 
> bothE()
> {code}
> @Test
> public void testLazy2() {
> final TinkerGraph graph = TinkerGraph.open();
> final Vertex a1 = graph.addVertex(T.label, "A");
> final Vertex b1 = graph.addVertex(T.label, "B");
> final Vertex c1 = graph.addVertex(T.label, "C");
> a1.addEdge("ab", b1);
> a1.addEdge("ac", c1);
> AtomicInteger count = new AtomicInteger(0);
> graph.traversal().V(a1).union(__.outE(), __.inE()).forEachRemaining(edge 
> -> {
> a1.addEdge("ab", b1);
> c1.addEdge("ac", a1);
> count.getAndIncrement();
> });
> Assert.assertEquals(2, count.get());
> }
> {code}
> In this case TinkerGraph returns 4 and Sqlg 6
> TinkerGraph returns 4 as it first walks the 2 out edges and adds 2 in edges 
> which it sees when traversing the in().
> Sqlg return 6 as it lazier than TinkerGraph.
> It first walks the "ac" out edge and adds in the 2 edges.
> Then walks "ab" and gets 2 edges. The original and the one added previously.
> It then walks "ac" in and gets 3 edges as 3 has been added so far.
> All and all 6.
> I am not sure whats the expected semantics. Sqlg is lazier than TinkerGraph 
> but not completely lazy either as it depends more on the meta data and number 
> of queries it needs to execute to walk a particular gremlin query.
> I am somewhat of the opinion that without enforcing a eager iteration when 
> modifying a graph the semantics will be different for different implementors.
> For Sqlg at least it will be hard for clients to predict the behavior.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Closed] (TINKERPOP-1569) Decompile lambdas in to regular gremlin

[Bryn Cooke (JIRA)]

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

Bryn Cooke closed TINKERPOP-1569.
-
Resolution: Won't Fix

> Decompile lambdas in to regular gremlin
> ---
>
> Key: TINKERPOP-1569
> URL: https://issues.apache.org/jira/browse/TINKERPOP-1569
> Project: TinkerPop
>  Issue Type: Improvement
>  Components: process
>Affects Versions: 3.2.3
>Reporter: Bryn Cooke
>
> I've been experimenting recently with decompilation and come up with this 
> method for decompiling lambdas:
> https://github.com/BrynCooke/dice/blob/master/lambda/src/test/java/org/jglue/dice/lambda/TestDecompiler.java
> Perhaps this could be useful for converting lamdas to regular gremlin?
> It only works with serializable lambdas BTW.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Commented] (TINKERPOP-1615) Doing a step many times can lead to unforeseen problems with the RepeatUnrollStrategy

[stephen mallette (JIRA)]

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

stephen mallette commented on TINKERPOP-1615:
-

[~jeromatron] any news on this one?

> Doing a step many times can lead to unforeseen problems with the 
> RepeatUnrollStrategy
> -
>
> Key: TINKERPOP-1615
> URL: https://issues.apache.org/jira/browse/TINKERPOP-1615
> Project: TinkerPop
>  Issue Type: Bug
>  Components: process
>Affects Versions: 3.2.3
>Reporter: Jeremy Hanna
>Assignee: Daniel Kuppitz
>
> The following traversal comes back with an error that appears to be related 
> to the {{RepeatUnrollStrategy}}:
> {code}
> g.V().has('foo', 'id', 
> '4b200757-96e2-463a-a7a0-7b9b75d4dbd3').repeat(__.in('subfolder_of')).times(100).hasNext()
> {code}
> appears to either error out or take forever.  However if I do something like:
> {code}
> g.withoutStrategies(RepeatUnrollStrategy.class).V().has('foo', 'id', 
> '4b200757-96e2-463a-a7a0-7b9b75d4dbd3').repeat(__.in('subfolder_of')).times(100).hasNext()
> {code}
> it works subsecond.
> So something funky with {{RepeatUnrollStrategy}} is going on.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Updated] (TINKERPOP-1595) Go through TraversalVertexProgram with a profile and optimize.

[stephen mallette (JIRA)]

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

stephen mallette updated TINKERPOP-1595:

Issue Type: Improvement  (was: Bug)

> Go through TraversalVertexProgram with a profile and optimize.
> --
>
> Key: TINKERPOP-1595
> URL: https://issues.apache.org/jira/browse/TINKERPOP-1595
> Project: TinkerPop
>  Issue Type: Improvement
>  Components: process
>Affects Versions: 3.2.3
>Reporter: Marko A. Rodriguez
>
> Work with [~twilmes] on profiling {{TraversalVertexProgram}}. When I was 
> doing the {{DedupGlobalStep}} work with [~dkuppitz], I noticed various 
> nick-nack optimizations. My profiling skills are poor, so if [~twilmes] could 
> identify long running sections of the code, that would be huge.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Closed] (TINKERPOP-1510) Inline comments in Gremlin console

[stephen mallette (JIRA)]

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

stephen mallette closed TINKERPOP-1510.
---
Resolution: Won't Do

This is an issue for the groovy folks - if that feature is needed we should 
open a ticket with that project.

> Inline comments in Gremlin console
> --
>
> Key: TINKERPOP-1510
> URL: https://issues.apache.org/jira/browse/TINKERPOP-1510
> Project: TinkerPop
>  Issue Type: Bug
>  Components: console
>Affects Versions: 3.2.2
>Reporter: Daniel Kuppitz
>
> A while back it was no issue to have inline comments in multi-line Gremlin 
> traversals; code samples from the docs could easily be copied and pasted. Now 
> I just tried to paste a code block and ended up with this:
> {noformat}
> gremlin> g.V(input.head()).
> ..1>repeat(out('hasParent')).emit().as('x'). //(1)
> groovysh_parse: 3: unexpected token: . @ line 3, column 51.
>t('hasParent')).emit().as('x'). //(1)
> {noformat}
> [~robertdale], could this have something to do with any of your recent 
> changes?



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Commented] (TINKERPOP-1513) Consider transaction boundaries given withRemote()

[stephen mallette (JIRA)]

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

stephen mallette commented on TINKERPOP-1513:
-

I think this one can be partially solved by TINKERPOP-1417 potentially as it 
discusses using a local subgraph to mark transaction boundaries.

> Consider transaction boundaries given withRemote()
> --
>
> Key: TINKERPOP-1513
> URL: https://issues.apache.org/jira/browse/TINKERPOP-1513
> Project: TinkerPop
>  Issue Type: Improvement
>  Components: driver, server
>Affects Versions: 3.2.2
>Reporter: stephen mallette
>
> Not sure what this one means, but given TINKERPOP-1511 we probably need to 
> make some improvements in this area.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Commented] (TINKERPOP-1552) C# Gremlin Language Variant

[Florian Hockmann (JIRA)]

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

Florian Hockmann commented on TINKERPOP-1552:
-

I think you missed some serializers, namely those for {{Bytecode}}, 
{{Binding}}, {{P}}, {{TraversalStrategy}}, and {{RequestMessage}}. 
[~spmallette] You can see all supported serializers in the 
{{GraphSONWriter._serializerByType}} {{Dictionary}} and all deserializers in 
{{GraphSONReader._deserializerByGraphSONType}}.

I basically implemented all serializers and deserializers I found in 
Gremlin-Python. These three types seem to be not supported by Gremlin-Python: 
{{Tree}}, {{StarGraph}}, and {{TinkerGraph}} and are therefore also missing in 
Gremlin-DotNet at the moment. Apart from that I don't see anything missing 
except for the extended types of course. It shouldn't be a problem to add 
support for those until the first official release.

> C# Gremlin Language Variant
> ---
>
> Key: TINKERPOP-1552
> URL: https://issues.apache.org/jira/browse/TINKERPOP-1552
> Project: TinkerPop
>  Issue Type: Improvement
>  Components: language-variant
>Affects Versions: 3.2.3
>Reporter: Jorge Bay
>Assignee: stephen mallette
>
> It would be nice to have a C# GLV that runs under .NET Framework 4.5+ and 
> .NET Core.
> The maven build could use the Exec Maven Plugin to exec .NET Core's [dotnet 
> test|https://www.microsoft.com/net/core#macos] command.
> Some requirements, from the mailing list (edited):
> {quote}
> 1. The GLV should keep in line with class/method names of the java API
> where possible to ensure consistency of feel across languages.
> 2. There needs to be adequate tests (we're still discussing the approach to
> testing GLVs and i think that needs to be tackled sooner than later as more
> GLVs start to come in). Those tests should produce xunit style output
> unless there is some good reason not to.
> 3. There needs to be adequate documentation (e.g. Reference docs)
> 4. The build/deploy process needs to be bound to maven which might be one of 
> the trickier bits to deal with.
> {quote}



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Comment Edited] (TINKERPOP-1474) API Alignment Between Java Gremlin Graph Structure and GLVs

[stephen mallette (JIRA)]

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

stephen mallette edited comment on TINKERPOP-1474 at 6/16/17 1:11 PM:
--

I think we'll ultimately solve this one with TINKERPOP-1592 by letting users 
better specify the detachment model. See TINKERPOP-1592


was (Author: spmallette):
I think we'll ultimately solve this one with TINKERPOP-1592 by letting users 
better specify the detachment model.

> API Alignment Between Java Gremlin Graph Structure and GLVs
> ---
>
> Key: TINKERPOP-1474
> URL: https://issues.apache.org/jira/browse/TINKERPOP-1474
> Project: TinkerPop
>  Issue Type: Improvement
>  Components: io, language-variant
>Affects Versions: 3.2.2
>Reporter: Adam Holmberg
>
> The current Java GraphSON implementation and that in the Python GLV leave 
> some question about what *should* be returned from a simple traversal like 
> `g.V()`.
> The java implementation presently assumes that properties could be present 
> and returns a DetachedVertex: 
> https://github.com/apache/tinkerpop/blob/master/gremlin-core/src/main/java/org/apache/tinkerpop/gremlin/structure/io/graphson/GraphSONSerializersV2d0.java#L420-L433
> The python implementation assumes no such thing and returns something more 
> reminiscent of a ReferenceVertex: 
> https://github.com/apache/tinkerpop/blob/master/gremlin-python/src/main/jython/gremlin_python/structure/io/graphson.py#L238-L242
> Is the java version overreaching, and should not expect properties unless a 
> step calls for them (e.g. ` g.V().valueMap()` or `g.V().values('name')`, or 
> should the Python version be expanded?
> Is there something we can do to establish guidelines for this, and align 
> these APIs?



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Commented] (TINKERPOP-1474) API Alignment Between Java Gremlin Graph Structure and GLVs

[stephen mallette (JIRA)]

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

stephen mallette commented on TINKERPOP-1474:
-

I think we'll ultimately solve this one with TINKERPOP-1592 by letting users 
better specify the detachment model.

> API Alignment Between Java Gremlin Graph Structure and GLVs
> ---
>
> Key: TINKERPOP-1474
> URL: https://issues.apache.org/jira/browse/TINKERPOP-1474
> Project: TinkerPop
>  Issue Type: Improvement
>  Components: io, language-variant
>Affects Versions: 3.2.2
>Reporter: Adam Holmberg
>
> The current Java GraphSON implementation and that in the Python GLV leave 
> some question about what *should* be returned from a simple traversal like 
> `g.V()`.
> The java implementation presently assumes that properties could be present 
> and returns a DetachedVertex: 
> https://github.com/apache/tinkerpop/blob/master/gremlin-core/src/main/java/org/apache/tinkerpop/gremlin/structure/io/graphson/GraphSONSerializersV2d0.java#L420-L433
> The python implementation assumes no such thing and returns something more 
> reminiscent of a ReferenceVertex: 
> https://github.com/apache/tinkerpop/blob/master/gremlin-python/src/main/jython/gremlin_python/structure/io/graphson.py#L238-L242
> Is the java version overreaching, and should not expect properties unless a 
> step calls for them (e.g. ` g.V().valueMap()` or `g.V().values('name')`, or 
> should the Python version be expanded?
> Is there something we can do to establish guidelines for this, and align 
> these APIs?



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Commented] (TINKERPOP-1552) C# Gremlin Language Variant

[Jorge Bay (JIRA)]

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

Jorge Bay commented on TINKERPOP-1552:
--

For serialization, it supports:
{code}
"g:Int32"
"g:Int64"
"g:Float"
"g:Double"
"g:UUID"
"g:Date"
"g:Timestamp"
"g:Vertex"
"g:Edge"
"g:Property"
"g:VertexProperty"
"g:Path"
"g:"
{code}

And for deserialization:
{code}
"g:Traverser"
"g:Int32"
"g:Int64"
"g:Float"
"g:Double"
"g:UUID"
"g:Date"
"g:Timestamp"
"g:Vertex"
"g:Edge"
"g:Property"
"g:VertexProperty"
"g:Path"
{code}

> C# Gremlin Language Variant
> ---
>
> Key: TINKERPOP-1552
> URL: https://issues.apache.org/jira/browse/TINKERPOP-1552
> Project: TinkerPop
>  Issue Type: Improvement
>  Components: language-variant
>Affects Versions: 3.2.3
>Reporter: Jorge Bay
>Assignee: stephen mallette
>
> It would be nice to have a C# GLV that runs under .NET Framework 4.5+ and 
> .NET Core.
> The maven build could use the Exec Maven Plugin to exec .NET Core's [dotnet 
> test|https://www.microsoft.com/net/core#macos] command.
> Some requirements, from the mailing list (edited):
> {quote}
> 1. The GLV should keep in line with class/method names of the java API
> where possible to ensure consistency of feel across languages.
> 2. There needs to be adequate tests (we're still discussing the approach to
> testing GLVs and i think that needs to be tackled sooner than later as more
> GLVs start to come in). Those tests should produce xunit style output
> unless there is some good reason not to.
> 3. There needs to be adequate documentation (e.g. Reference docs)
> 4. The build/deploy process needs to be bound to maven which might be one of 
> the trickier bits to deal with.
> {quote}



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Commented] (TINKERPOP-1669) EdgeVertexStep should be designed for extension

[stephen mallette (JIRA)]

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

stephen mallette commented on TINKERPOP-1669:
-

[~okram] can we do this? or did you have some additional response for bryn?

> EdgeVertexStep should be designed for extension
> ---
>
> Key: TINKERPOP-1669
> URL: https://issues.apache.org/jira/browse/TINKERPOP-1669
> Project: TinkerPop
>  Issue Type: Improvement
>  Components: process, structure
>Affects Versions: 3.2.4
>Reporter: Bryn Cooke
>
> GraphStep, VertexStep and PropertiesStep are all not final, so I was 
> surprised to find that I couldn't extend EdgeVertexStep. In the end I had to 
> duplicate the entire class
> If there are concerns about simply making this class non-final then it could 
> be designed for extension by making most of the methods final (except 
> toString), but the leaving the class non-final.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Commented] (TINKERPOP-1552) C# Gremlin Language Variant

[stephen mallette (JIRA)]

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

stephen mallette commented on TINKERPOP-1552:
-

What kind of GraphSON support do we have in this GLV? I was skimming through 
the serializers and it wasn't clear to me if we have complete coverage of all 
the types in GraphSON 2.0:

http://tinkerpop.apache.org/docs/current/dev/io/#graphson-2d0

Python i think covers all of them except for the "extended" set:

http://tinkerpop.apache.org/docs/current/dev/io/#_extended

which we have a ticket for and will have done for next release: TINKERPOP-1435

> C# Gremlin Language Variant
> ---
>
> Key: TINKERPOP-1552
> URL: https://issues.apache.org/jira/browse/TINKERPOP-1552
> Project: TinkerPop
>  Issue Type: Improvement
>  Components: language-variant
>Affects Versions: 3.2.3
>Reporter: Jorge Bay
>Assignee: stephen mallette
>
> It would be nice to have a C# GLV that runs under .NET Framework 4.5+ and 
> .NET Core.
> The maven build could use the Exec Maven Plugin to exec .NET Core's [dotnet 
> test|https://www.microsoft.com/net/core#macos] command.
> Some requirements, from the mailing list (edited):
> {quote}
> 1. The GLV should keep in line with class/method names of the java API
> where possible to ensure consistency of feel across languages.
> 2. There needs to be adequate tests (we're still discussing the approach to
> testing GLVs and i think that needs to be tackled sooner than later as more
> GLVs start to come in). Those tests should produce xunit style output
> unless there is some good reason not to.
> 3. There needs to be adequate documentation (e.g. Reference docs)
> 4. The build/deploy process needs to be bound to maven which might be one of 
> the trickier bits to deal with.
> {quote}



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Assigned] (TINKERPOP-1435) Support for extended GraphSON 2.0 in gremlin-python

[stephen mallette (JIRA)]

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

stephen mallette reassigned TINKERPOP-1435:
---

Assignee: David M. Brown

> Support for extended GraphSON 2.0 in gremlin-python
> ---
>
> Key: TINKERPOP-1435
> URL: https://issues.apache.org/jira/browse/TINKERPOP-1435
> Project: TinkerPop
>  Issue Type: Improvement
>  Components: language-variant
>Affects Versions: 3.2.2
>Reporter: stephen mallette
>Assignee: David M. Brown
>Priority: Minor
>
> Support the "gx" GraphSON module for full compatibility with GraphSON 2.0 in 
> gremlin-python.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Commented] (TINKERPOP-1417) Create a Gremlin language subset that is easy to implement on any VM

[stephen mallette (JIRA)]

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

stephen mallette commented on TINKERPOP-1417:
-

This has an interesting potential impact on GLVs because "Little Gremlin" could 
be implemented within them for client-side traversals over remote subgraphs, 
where the subgraph is like a remote transaction. All graph mutations 
essentially build a subgraph which is merged into the primary graph. That 
subgraph is effectively the "transaction". Build it locally then submit it 
remotely and have the server sort out the merging. It's perhaps the most 
natural way to load data. With "Gremlinito" you then get the added power of 
being able to traverse a local subgraph.

If we could ever get the test suite "right" we could probably have to test 
specifications one for "Gremlin Minor" and one for "Gremlin Major". Then you 
just build your implementation against the spec that you want to support. We 
could drive the specification by the test suite.

fyi [~bryncooke] 

> Create a Gremlin language subset that is easy to implement on any VM
> 
>
> Key: TINKERPOP-1417
> URL: https://issues.apache.org/jira/browse/TINKERPOP-1417
> Project: TinkerPop
>  Issue Type: Improvement
>  Components: process
>Affects Versions: 3.2.1
>Reporter: Marko A. Rodriguez
>
> Implementing the Gremlin VM in another language is pretty straightforward. 
> However, its a lot of code.. all these steps implementations. One thing we 
> could do to make it easy for database providers not on the JVM (e.g. ArangoDB 
> and C) is to create "Gremlito" (Gremlin--). This language subset wouldn't 
> support side-effects, sacks, match, etc. Basically, just simple traversal 
> steps and reducing barrier terminals.
> Thus:
> * out, in, both, values, outE, inV, id, label, etc.
> * repeat
> * select, project
> * where, has, limit, range, is, dedup
> * path, simplePath, cyclicPath
> * groupCount, sum, group, count, max, min, etc. (reducing barriers)
> I suspect the steps above make up 90% of user traversals and all are easy to 
> implement.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Closed] (TINKERPOP-1395) Consider replacing ConnectionPool with Netty ChannelPool

[stephen mallette (JIRA)]

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

stephen mallette closed TINKERPOP-1395.
---
Resolution: Won't Do

Looked into this a while back. I don't think it makes sense. Represents massive 
upheaval in the driver for limited gain.

> Consider replacing ConnectionPool with Netty ChannelPool
> 
>
> Key: TINKERPOP-1395
> URL: https://issues.apache.org/jira/browse/TINKERPOP-1395
> Project: TinkerPop
>  Issue Type: Improvement
>  Components: driver
>Affects Versions: 3.2.1
>Reporter: stephen mallette
>Assignee: stephen mallette
>Priority: Minor
>
> The Netty {{ChannelPool}} looks like it has similar features to our homegrown 
> {{ConnectionPool}} - might be nice to see if we could use the netty one 
> instead:
> http://netty.io/4.0/api/io/netty/channel/pool/ChannelPool.html



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Created] (TINKERPOP-1693) Tree may produce incorrect results when nodes are not unique

[stephen mallette (JIRA)]

stephen mallette created TINKERPOP-1693:
---

 Summary: Tree may produce incorrect results when nodes are not 
unique
 Key: TINKERPOP-1693
 URL: https://issues.apache.org/jira/browse/TINKERPOP-1693
 Project: TinkerPop
  Issue Type: Bug
  Components: process
Affects Versions: 3.2.5
Reporter: stephen mallette


Consider the following:

{code}
gremlin> g = TinkerFactory.createModern().traversal()
==>graphtraversalsource[tinkergraph[vertices:6 edges:6], standard]
gremlin> g.V(1).repeat(out()).emit().tree()
==>[v[1]:[v[2]:[],v[3]:[],v[4]:[v[3]:[],v[5]:[
gremlin> g.V(1).repeat(out()).emit().tree().by(label)
==>[person:[software:[],person:[software:[
gremlin> g.V(1).repeat(out()).emit().tree().by("name")
==>[marko:[vadas:[],josh:[ripple:[],lop:[]],lop:[]]]
{code}

Since {{Tree}} extends {{HashMap}} we end up with keys having to be unique and 
when they aren't we lose some of the tree structure.




--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

Re: [VOTE] TinkerPop 3.2.5 Release

[Daniel Kuppitz]

bin/validate-distribution.sh still looking good.

VOTE: +1


On Thu, Jun 15, 2017 at 10:33 PM, Stephen Mallette 
wrote:

> Hello (again),
>
> We are happy to announce (again) that TinkerPop 3.2.5 is ready for release.
>
> The release artifacts can be found at this location:
> https://dist.apache.org/repos/dist/dev/tinkerpop/3.2.5/
>
> The source distribution is provided by:
> apache-tinkerpop-3.2.5-src.zip
>
> Two binary distributions are provided for user convenience:
> apache-tinkerpop-gremlin-console3.2.5-bin.zip
> apache-tinkerpop-gremlin-server-3.2.5-bin.zip
>
> The GPG key used to sign the release artifacts is available at:
> https://dist.apache.org/repos/dist/dev/tinkerpop/KEYS
>
> The online docs can be found here:
> http://tinkerpop.apache.org/docs/3.2.5/ (user docs)
> http://tinkerpop.apache.org/docs/3.2.5/upgrade/ (upgrade docs)
> http://tinkerpop.apache.org/javadocs/3.2.5/core/ (core javadoc)
> http://tinkerpop.apache.org/javadocs/3.2.5/full/ (full javadoc)
>
> The tag in Apache Git can be found here:
>
> https://git-wip-us.apache.org/repos/asf?p=tinkerpop.git;a=tag;h=
> 0ecbb067a212711a6b996af828cc932956282dcc
>
> The release notes are available here:
>
> https://github.com/apache/tinkerpop/blob/master/
> CHANGELOG.asciidoc#tinkerpop-320-nine-inch-gremlins
>
> The [VOTE] will be open for the next 72 hours --- closing Sunday (June 18,
> 2017) at  4:30pm EST
>
> My vote is +1 (again).
>
> Thank you very much,
> Stephen
>

[jira] [Commented] (TINKERPOP-1552) C# Gremlin Language Variant

[ASF GitHub Bot (JIRA)]

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

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

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

https://github.com/apache/tinkerpop/pull/629#discussion_r122388282
  
--- Diff: gremlin-dotnet/glv/AnonymousTraversal.template ---
@@ -27,6 +27,8 @@ using Gremlin.Net.Structure;
 // THIS IS A GENERATED FILE - DO NOT MODIFY THIS FILE DIRECTLY - see 
pom.xml
 namespace Gremlin.Net.Process.Traversal
 {
+#pragma warning disable 1591
--- End diff --

Looks like you're right. I thought that it would be necessary to also 
document all function arguments and return values, but it seems to be enough to 
have a `summary` for each element. This also applies to the `GraphTraversal` 
class. I'll update the pull request to remove the `pragmas` for both classes.


> C# Gremlin Language Variant
> ---
>
> Key: TINKERPOP-1552
> URL: https://issues.apache.org/jira/browse/TINKERPOP-1552
> Project: TinkerPop
>  Issue Type: Improvement
>  Components: language-variant
>Affects Versions: 3.2.3
>Reporter: Jorge Bay
>Assignee: stephen mallette
>
> It would be nice to have a C# GLV that runs under .NET Framework 4.5+ and 
> .NET Core.
> The maven build could use the Exec Maven Plugin to exec .NET Core's [dotnet 
> test|https://www.microsoft.com/net/core#macos] command.
> Some requirements, from the mailing list (edited):
> {quote}
> 1. The GLV should keep in line with class/method names of the java API
> where possible to ensure consistency of feel across languages.
> 2. There needs to be adequate tests (we're still discussing the approach to
> testing GLVs and i think that needs to be tackled sooner than later as more
> GLVs start to come in). Those tests should produce xunit style output
> unless there is some good reason not to.
> 3. There needs to be adequate documentation (e.g. Reference docs)
> 4. The build/deploy process needs to be bound to maven which might be one of 
> the trickier bits to deal with.
> {quote}



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[GitHub] tinkerpop pull request #629: TINKERPOP-1552: Clean-up Gremlin-DotNet project...

[FlorianHockmann]

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

https://github.com/apache/tinkerpop/pull/629#discussion_r122388282
  
--- Diff: gremlin-dotnet/glv/AnonymousTraversal.template ---
@@ -27,6 +27,8 @@ using Gremlin.Net.Structure;
 // THIS IS A GENERATED FILE - DO NOT MODIFY THIS FILE DIRECTLY - see 
pom.xml
 namespace Gremlin.Net.Process.Traversal
 {
+#pragma warning disable 1591
--- End diff --

Looks like you're right. I thought that it would be necessary to also 
document all function arguments and return values, but it seems to be enough to 
have a `summary` for each element. This also applies to the `GraphTraversal` 
class. I'll update the pull request to remove the `pragmas` for both classes.


---
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-1552) C# Gremlin Language Variant

[ASF GitHub Bot (JIRA)]

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

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

Github user jorgebay commented on the issue:

https://github.com/apache/tinkerpop/pull/629
  
Apart from my previous comment, lgtm.


> C# Gremlin Language Variant
> ---
>
> Key: TINKERPOP-1552
> URL: https://issues.apache.org/jira/browse/TINKERPOP-1552
> Project: TinkerPop
>  Issue Type: Improvement
>  Components: language-variant
>Affects Versions: 3.2.3
>Reporter: Jorge Bay
>Assignee: stephen mallette
>
> It would be nice to have a C# GLV that runs under .NET Framework 4.5+ and 
> .NET Core.
> The maven build could use the Exec Maven Plugin to exec .NET Core's [dotnet 
> test|https://www.microsoft.com/net/core#macos] command.
> Some requirements, from the mailing list (edited):
> {quote}
> 1. The GLV should keep in line with class/method names of the java API
> where possible to ensure consistency of feel across languages.
> 2. There needs to be adequate tests (we're still discussing the approach to
> testing GLVs and i think that needs to be tackled sooner than later as more
> GLVs start to come in). Those tests should produce xunit style output
> unless there is some good reason not to.
> 3. There needs to be adequate documentation (e.g. Reference docs)
> 4. The build/deploy process needs to be bound to maven which might be one of 
> the trickier bits to deal with.
> {quote}



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[GitHub] tinkerpop issue #629: TINKERPOP-1552: Clean-up Gremlin-DotNet project files

[jorgebay]

Github user jorgebay commented on the issue:

https://github.com/apache/tinkerpop/pull/629
  
Apart from my previous comment, lgtm.


---
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-1552) C# Gremlin Language Variant

[ASF GitHub Bot (JIRA)]

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

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

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

https://github.com/apache/tinkerpop/pull/629#discussion_r122383928
  
--- Diff: gremlin-dotnet/glv/AnonymousTraversal.template ---
@@ -27,6 +27,8 @@ using Gremlin.Net.Structure;
 // THIS IS A GENERATED FILE - DO NOT MODIFY THIS FILE DIRECTLY - see 
pom.xml
 namespace Gremlin.Net.Process.Traversal
 {
+#pragma warning disable 1591
--- End diff --

Is this needed for this source file, all methods are being generated with 
docs.


> C# Gremlin Language Variant
> ---
>
> Key: TINKERPOP-1552
> URL: https://issues.apache.org/jira/browse/TINKERPOP-1552
> Project: TinkerPop
>  Issue Type: Improvement
>  Components: language-variant
>Affects Versions: 3.2.3
>Reporter: Jorge Bay
>Assignee: stephen mallette
>
> It would be nice to have a C# GLV that runs under .NET Framework 4.5+ and 
> .NET Core.
> The maven build could use the Exec Maven Plugin to exec .NET Core's [dotnet 
> test|https://www.microsoft.com/net/core#macos] command.
> Some requirements, from the mailing list (edited):
> {quote}
> 1. The GLV should keep in line with class/method names of the java API
> where possible to ensure consistency of feel across languages.
> 2. There needs to be adequate tests (we're still discussing the approach to
> testing GLVs and i think that needs to be tackled sooner than later as more
> GLVs start to come in). Those tests should produce xunit style output
> unless there is some good reason not to.
> 3. There needs to be adequate documentation (e.g. Reference docs)
> 4. The build/deploy process needs to be bound to maven which might be one of 
> the trickier bits to deal with.
> {quote}



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[GitHub] tinkerpop pull request #629: TINKERPOP-1552: Clean-up Gremlin-DotNet project...

[jorgebay]

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

https://github.com/apache/tinkerpop/pull/629#discussion_r122383928
  
--- Diff: gremlin-dotnet/glv/AnonymousTraversal.template ---
@@ -27,6 +27,8 @@ using Gremlin.Net.Structure;
 // THIS IS A GENERATED FILE - DO NOT MODIFY THIS FILE DIRECTLY - see 
pom.xml
 namespace Gremlin.Net.Process.Traversal
 {
+#pragma warning disable 1591
--- End diff --

Is this needed for this source file, all methods are being generated with 
docs.


---
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.
---