[GitHub] tinkerpop pull request #:

2017-09-25 Thread jorgebay
Github user jorgebay commented on the pull request:


https://github.com/apache/tinkerpop/commit/2bf649c22a86f6051dc932d016a4a0bee4756ad0#commitcomment-24544868
  
In gremlin-test/features/map/Select.feature:
In gremlin-test/features/map/Select.feature on line 25:
Shouldn't this be lang agnostic gremlin (not Python): 
`g.V(v1).as("a").out("knows").as("b").select("a", "b")`


---


[jira] [Commented] (TINKERPOP-1786) Recipe and missing manifest items for Spark on Yarn

2017-09-25 Thread ASF GitHub Bot (JIRA)

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

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

Github user okram commented on the issue:

https://github.com/apache/tinkerpop/pull/721
  
This is good stuff. Is it possible to write a test case for the work? Also, 
can you fix your documentation so its `TinkerPop` not `Tinkerpop` (camel case).


> Recipe and missing manifest items for Spark on Yarn
> ---
>
> Key: TINKERPOP-1786
> URL: https://issues.apache.org/jira/browse/TINKERPOP-1786
> Project: TinkerPop
>  Issue Type: Improvement
>  Components: hadoop
>Affects Versions: 3.3.0, 3.1.8, 3.2.6
> Environment: gremlin-console
>Reporter: Marc de Lignie
>Priority: Minor
> Fix For: 3.2.7, 3.3.1
>
>
> Thorough documentation for running OLAP queries on Spark on Yarn has been 
> missing, keeping some users from getting the benefits of this nice feature of 
> the Tinkerpop stack and resulting in a significant number of questions on the 
> gremlin users list.



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


[GitHub] tinkerpop issue #721: TINKERPOP-1786 Recipe and missing manifest items for S...

2017-09-25 Thread okram
Github user okram commented on the issue:

https://github.com/apache/tinkerpop/pull/721
  
This is good stuff. Is it possible to write a test case for the work? Also, 
can you fix your documentation so its `TinkerPop` not `Tinkerpop` (camel case).


---


[GitHub] tinkerpop pull request #:

2017-09-25 Thread spmallette
Github user spmallette commented on the pull request:


https://github.com/apache/tinkerpop/commit/2bf649c22a86f6051dc932d016a4a0bee4756ad0#commitcomment-24544936
  
In gremlin-test/features/map/Select.feature:
In gremlin-test/features/map/Select.feature on line 25:
yeah.i was just trying to get the assertion to pass. i still have to 
sort out how to deal with language specific issues like that.


---


[GitHub] tinkerpop pull request #712: TINKERPOP-1752: Gremlin.Net: Generate completel...

2017-09-25 Thread jorgebay
Github user jorgebay commented on a diff in the pull request:

https://github.com/apache/tinkerpop/pull/712#discussion_r140818483
  
--- Diff: gremlin-dotnet/src/Gremlin.Net/Process/Traversal/Bytecode.cs ---
@@ -79,7 +85,77 @@ public void AddSource(string sourceName, params object[] 
args)
 /// The traversal method arguments.
 public void AddStep(string stepName, params object[] args)
 {
-StepInstructions.Add(new Instruction(stepName, args));
+StepInstructions.Add(new Instruction(stepName, 
FlattenArguments(args)));
+Bindings.Clear();
--- End diff --

Even though `Bindings` is based on a `ThreadLocal` instance, I think the 
implementation is not thread-safe.

For example: Multiple tasks executed serially on the same thread, modifying 
the same bindings dictionary.
Besides not being thread-safe, it doesn't support defining a binding on 1 
thread and adding the step on another, sample:

```csharp
// thread 1
// define bindings
Bindings.Instance.Of(/* */);
await SomeUnRelatedTask();
// thread 2
// Do something with that binding
g.V()/**/;
```


---


[GitHub] tinkerpop pull request #712: TINKERPOP-1752: Gremlin.Net: Generate completel...

2017-09-25 Thread jorgebay
Github user jorgebay commented on a diff in the pull request:

https://github.com/apache/tinkerpop/pull/712#discussion_r140818845
  
--- Diff: gremlin-dotnet/src/Gremlin.Net/Process/Traversal/Bindings.cs ---
@@ -29,14 +32,42 @@ namespace Gremlin.Net.Process.Traversal
 public class Bindings
 {
 /// 
+/// Gets an instance of the  class.
+/// 
+public static Bindings Instance { get; } = new Bindings();
+
+private static readonly ThreadLocal> 
BoundVariableByValue =
+new ThreadLocal>();
+
+/// 
 /// Binds the variable to the specified value.
 /// 
 /// The variable to bind.
 /// The value to which the variable should be 
bound.
 /// The bound value.
-public Binding Of(string variable, object value)
+public TV Of(string variable, TV value)
+{
+var dict = BoundVariableByValue.Value;
+if (dict == null)
+{
+dict = new Dictionary();
+BoundVariableByValue.Value = dict;
+}
+dict[value] = variable;
+return value;
+}
+
+internal static string GetBoundVariable(TV value)
+{
+var dict = BoundVariableByValue.Value;
+if (dict == null)
+return null;
+return !dict.ContainsKey(value) ? null : dict[value];
--- End diff --

Use `Dictionary{K, V}.TryGetValue()` to save one operation.


---


[GitHub] tinkerpop pull request #712: TINKERPOP-1752: Gremlin.Net: Generate completel...

2017-09-25 Thread jorgebay
Github user jorgebay commented on a diff in the pull request:

https://github.com/apache/tinkerpop/pull/712#discussion_r140812056
  
--- Diff: gremlin-dotnet/glv/GraphTraversal.template ---
@@ -65,9 +65,17 @@ namespace Gremlin.Net.Process.Traversal
 /// 
 /// Adds the <%= method.methodName %> step to this .
 /// 
-public GraphTraversal< <%= method.t1 %> , <%= method.t2 %> > <%= 
toCSharpMethodName.call(method.methodName) %><%= method.tParam %> (params 
object[] args)
+public GraphTraversal< <%= method.t1 %> , <%= method.t2 %> > <%= 
toCSharpMethodName.call(method.methodName) %><%= method.tParam %> (<%= 
method.parameters %>)
 {
-Bytecode.AddStep("<%= method.methodName %>", args);
+<%  if (method.parameters.contains("params ")) {
+  %>var args = new List {<%= 
method.paramNames.init().join(", ") %>};
--- End diff --

We should set the initial capacity of the list to avoid unnecessary 
resizing of the underlying array.
It should be the sum of the length of `method.paramNames.init()` and 
`method.paramNames.last()`.


---


Re: [DISCUSS] GLV Test Suite

2017-09-25 Thread Jorge Bay Gondra
I was able to build a proof of concept for a Gherkin-based test runner in
C#, that takes the proposed count and select features

and runs them using C# step definitions.

It uses the Gherkin parser  from
cucumber, there isn't a release of the parser with .NET Core support so I've
asked them to release one
 (there is no
limitation from their source files). If they are not able to release it in
the next few days, we can implement our own as it should be pretty straight
forward.

On Fri, Sep 22, 2017 at 2:23 PM, Stephen Mallette 
wrote:

> Thanks for the update. I'm trying to keep the test language as simple as
> possible so that we don't need an overly complicated test implementation.
> Hopefully that will help make the .NET approach as easy as possible.
>
> On Fri, Sep 22, 2017 at 8:20 AM, Jorge Bay Gondra <
> jorgebaygon...@gmail.com>
> wrote:
>
> > I've been looking into Gherkin support for .NET: SpecFlow, the cucumber
> > implementation for .NET  cucumber-implementations
> > >,
> > does not support .NET Core platform (we use .NET Core build tools for the
> > .NET GLV) and only supports .NET Framework.
> >
> > From what I can see ,
> > .NET
> > Core support on SpecFlow is coming at a very slow pace and we shouldn't
> > expect to land any time soon (there were some design decisions in
> SpecFlow
> > library that makes supporting other platforms non-trivial, like requiring
> > code gen).
> >
> > The alternative would be to implement our own harness to support it:
> from a
> > xunit test, look for certain types and parse the annotations, and execute
> > them using the Gherkin features.
> > There is a .NET cross-platform Gherkin parser:
> > https://github.com/cucumber/gherkin-dotnet
> > I'll continue looking into this option and try to understand the effort
> > required...
> >
> > On Tue, Sep 19, 2017 at 6:21 PM, Jorge Bay Gondra <
> > jorgebaygon...@gmail.com>
> > wrote:
> >
> > > Nice! Gherkin will make our lives easier with a growing number of GLVs.
> > >
> > > We should find a way to define the different features supported by each
> > > GLV, as it's reasonable to have different maturity levels per GLV (ie:
> > > lambdas support, traversal strategy, ...). I don't know if it will be
> > > beneficial to do it in the Gherkin files or within each GLV
> > implementation.
> > > Also, we should consider the process of rolling out a new method /
> class
> > > in the java implementation, how that could affect each GLV.
> > >
> > > On Thu, Sep 14, 2017 at 11:12 PM, Stephen Mallette <
> spmalle...@gmail.com
> > >
> > > wrote:
> > >
> > >> that's what i meant by "reflection" or as you suggest eval(). I guess
> > the
> > >> point is that if the language can support some way of taking the
> string
> > >> value and turning it automatically into a traversal in that GLVs style
> > >> then
> > >> we should do that.
> > >>
> > >> On Thu, Sep 14, 2017 at 4:45 PM, Daniel Kuppitz 
> > wrote:
> > >>
> > >> > For unparameterized queries it can probably be as easy as:
> > >> >
> > >> > @given("the traversal of")
> > >> > def translate_traversal(step):
> > >> > g = step.context.g
> > >> > step.context.traversal = eval(step.text)
> > >> >
> > >> >
> > >> > Cheers,
> > >> > Daniel
> > >> >
> > >> >
> > >> > On Thu, Sep 14, 2017 at 1:39 PM, Daniel Kuppitz 
> > >> wrote:
> > >> >
> > >> > > That's great stuff. I haven't used Cucumber / Gherkin for years,
> > but I
> > >> > > really like the BDD approach.
> > >> > >
> > >> > > and then you can look at the GLV Gremlin translations specifically
> > >> here:
> > >> > >> https://github.com/apache/tinkerpop/blob/TINKERPOP-1784/grem
> > >> > >> lin-python/src/main/jython/radish/count_features_step.py#L34-L46
> > >> > >
> > >> > >
> > >> > > This part is the only thing that looks weird to me. You're
> basically
> > >> > > writing every query twice; is there really no easier way to do
> that?
> > >> > >
> > >> > > Cheers,
> > >> > > Daniel
> > >> > >
> > >> > >
> > >> > > On Thu, Sep 14, 2017 at 1:17 PM, Stephen Mallette <
> > >> spmalle...@gmail.com>
> > >> > > wrote:
> > >> > >
> > >> > >> I've brought this issue up in the past and had suggested some
> > >> options I
> > >> > >> had
> > >> > >> in mind but now I've finally put the basics of those ideas in
> place
> > >> so I
> > >> > >> figured I'd start a fresh thread. Recall that the issue at hand
> is
> > >> that
> > >> > we
> > >> > >> don't have a test suite for GLVs as gremlin-test is bound to the
> > >> JVM. We
> > >> > >> have some tricks that let us test gremlin-python with it but
> those
> > >> > tricks
> > >> > >> won't work for every language and we now have the first language
> in
> > >> > >> gremlin-dotnet 

[jira] [Commented] (TINKERPOP-1752) Gremlin.Net: Generate completely type-safe methods

2017-09-25 Thread ASF GitHub Bot (JIRA)

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

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

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

https://github.com/apache/tinkerpop/pull/712#discussion_r140818845
  
--- Diff: gremlin-dotnet/src/Gremlin.Net/Process/Traversal/Bindings.cs ---
@@ -29,14 +32,42 @@ namespace Gremlin.Net.Process.Traversal
 public class Bindings
 {
 /// 
+/// Gets an instance of the  class.
+/// 
+public static Bindings Instance { get; } = new Bindings();
+
+private static readonly ThreadLocal> 
BoundVariableByValue =
+new ThreadLocal>();
+
+/// 
 /// Binds the variable to the specified value.
 /// 
 /// The variable to bind.
 /// The value to which the variable should be 
bound.
 /// The bound value.
-public Binding Of(string variable, object value)
+public TV Of(string variable, TV value)
+{
+var dict = BoundVariableByValue.Value;
+if (dict == null)
+{
+dict = new Dictionary();
+BoundVariableByValue.Value = dict;
+}
+dict[value] = variable;
+return value;
+}
+
+internal static string GetBoundVariable(TV value)
+{
+var dict = BoundVariableByValue.Value;
+if (dict == null)
+return null;
+return !dict.ContainsKey(value) ? null : dict[value];
--- End diff --

Use `Dictionary{K, V}.TryGetValue()` to save one operation.


> Gremlin.Net: Generate completely type-safe methods
> --
>
> Key: TINKERPOP-1752
> URL: https://issues.apache.org/jira/browse/TINKERPOP-1752
> Project: TinkerPop
>  Issue Type: Improvement
>  Components: dotnet
>Affects Versions: 3.2.5
>Reporter: Florian Hockmann
>Priority: Minor
>
> Currently the generated traversal methods in Gremlin.Net take {{params 
> object[] args}} as an argument which allows the user to provide an arbitrary 
> number of arguments with any type. While this makes the generation rather 
> simple, it doesn't tell the user which arguments are actually valid so users 
> can submit completely invalid traversals like:
> {code}
> g.V(1).AddE(1234, "invalidArgument2").Next()
> {code}
> Type-safe methods could also use the original argument names to tell users 
> something about what kind of values the methods expect. Consider for example 
> the following method signatures for the C# step {{AddE}} that are basically a 
> 1:1 representation of the original Java {{addE}} step:
> {code}
> public GraphTraversal< S , Edge > AddE (Direction direction, string 
> firstVertexKeyOrEdgeLabel, string edgeLabelOrSecondVertexKey, params object[] 
> propertyKeyValues);
> public GraphTraversal< S , Edge > AddE (string edgeLabel);
> {code}
> Implementing this should make TINKERPOP-1725 obsolete and also resolve 
> TINKERPOP-1751.



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


[jira] [Commented] (TINKERPOP-1752) Gremlin.Net: Generate completely type-safe methods

2017-09-25 Thread ASF GitHub Bot (JIRA)

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

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

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

https://github.com/apache/tinkerpop/pull/712#discussion_r140818483
  
--- Diff: gremlin-dotnet/src/Gremlin.Net/Process/Traversal/Bytecode.cs ---
@@ -79,7 +85,77 @@ public void AddSource(string sourceName, params object[] 
args)
 /// The traversal method arguments.
 public void AddStep(string stepName, params object[] args)
 {
-StepInstructions.Add(new Instruction(stepName, args));
+StepInstructions.Add(new Instruction(stepName, 
FlattenArguments(args)));
+Bindings.Clear();
--- End diff --

Even though `Bindings` is based on a `ThreadLocal` instance, I think the 
implementation is not thread-safe.

For example: Multiple tasks executed serially on the same thread, modifying 
the same bindings dictionary.
Besides not being thread-safe, it doesn't support defining a binding on 1 
thread and adding the step on another, sample:

```csharp
// thread 1
// define bindings
Bindings.Instance.Of(/* */);
await SomeUnRelatedTask();
// thread 2
// Do something with that binding
g.V()/**/;
```


> Gremlin.Net: Generate completely type-safe methods
> --
>
> Key: TINKERPOP-1752
> URL: https://issues.apache.org/jira/browse/TINKERPOP-1752
> Project: TinkerPop
>  Issue Type: Improvement
>  Components: dotnet
>Affects Versions: 3.2.5
>Reporter: Florian Hockmann
>Priority: Minor
>
> Currently the generated traversal methods in Gremlin.Net take {{params 
> object[] args}} as an argument which allows the user to provide an arbitrary 
> number of arguments with any type. While this makes the generation rather 
> simple, it doesn't tell the user which arguments are actually valid so users 
> can submit completely invalid traversals like:
> {code}
> g.V(1).AddE(1234, "invalidArgument2").Next()
> {code}
> Type-safe methods could also use the original argument names to tell users 
> something about what kind of values the methods expect. Consider for example 
> the following method signatures for the C# step {{AddE}} that are basically a 
> 1:1 representation of the original Java {{addE}} step:
> {code}
> public GraphTraversal< S , Edge > AddE (Direction direction, string 
> firstVertexKeyOrEdgeLabel, string edgeLabelOrSecondVertexKey, params object[] 
> propertyKeyValues);
> public GraphTraversal< S , Edge > AddE (string edgeLabel);
> {code}
> Implementing this should make TINKERPOP-1725 obsolete and also resolve 
> TINKERPOP-1751.



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


[jira] [Commented] (TINKERPOP-1752) Gremlin.Net: Generate completely type-safe methods

2017-09-25 Thread ASF GitHub Bot (JIRA)

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

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

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

https://github.com/apache/tinkerpop/pull/712#discussion_r140812056
  
--- Diff: gremlin-dotnet/glv/GraphTraversal.template ---
@@ -65,9 +65,17 @@ namespace Gremlin.Net.Process.Traversal
 /// 
 /// Adds the <%= method.methodName %> step to this .
 /// 
-public GraphTraversal< <%= method.t1 %> , <%= method.t2 %> > <%= 
toCSharpMethodName.call(method.methodName) %><%= method.tParam %> (params 
object[] args)
+public GraphTraversal< <%= method.t1 %> , <%= method.t2 %> > <%= 
toCSharpMethodName.call(method.methodName) %><%= method.tParam %> (<%= 
method.parameters %>)
 {
-Bytecode.AddStep("<%= method.methodName %>", args);
+<%  if (method.parameters.contains("params ")) {
+  %>var args = new List {<%= 
method.paramNames.init().join(", ") %>};
--- End diff --

We should set the initial capacity of the list to avoid unnecessary 
resizing of the underlying array.
It should be the sum of the length of `method.paramNames.init()` and 
`method.paramNames.last()`.


> Gremlin.Net: Generate completely type-safe methods
> --
>
> Key: TINKERPOP-1752
> URL: https://issues.apache.org/jira/browse/TINKERPOP-1752
> Project: TinkerPop
>  Issue Type: Improvement
>  Components: dotnet
>Affects Versions: 3.2.5
>Reporter: Florian Hockmann
>Priority: Minor
>
> Currently the generated traversal methods in Gremlin.Net take {{params 
> object[] args}} as an argument which allows the user to provide an arbitrary 
> number of arguments with any type. While this makes the generation rather 
> simple, it doesn't tell the user which arguments are actually valid so users 
> can submit completely invalid traversals like:
> {code}
> g.V(1).AddE(1234, "invalidArgument2").Next()
> {code}
> Type-safe methods could also use the original argument names to tell users 
> something about what kind of values the methods expect. Consider for example 
> the following method signatures for the C# step {{AddE}} that are basically a 
> 1:1 representation of the original Java {{addE}} step:
> {code}
> public GraphTraversal< S , Edge > AddE (Direction direction, string 
> firstVertexKeyOrEdgeLabel, string edgeLabelOrSecondVertexKey, params object[] 
> propertyKeyValues);
> public GraphTraversal< S , Edge > AddE (string edgeLabel);
> {code}
> Implementing this should make TINKERPOP-1725 obsolete and also resolve 
> TINKERPOP-1751.



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


[jira] [Updated] (TINKERPOP-1792) Random TraversalSource Selection in GremlinScriptEngine

2017-09-25 Thread stephen mallette (JIRA)

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

stephen mallette updated TINKERPOP-1792:

Summary: Random TraversalSource Selection in GremlinScriptEngine  (was: 
Random TraversalSource selection )

> Random TraversalSource Selection in GremlinScriptEngine
> ---
>
> Key: TINKERPOP-1792
> URL: https://issues.apache.org/jira/browse/TINKERPOP-1792
> Project: TinkerPop
>  Issue Type: Bug
>Reporter: stephen mallette
>




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


[jira] [Updated] (TINKERPOP-1792) Random TraversalSource Selection in GremlinScriptEngine

2017-09-25 Thread stephen mallette (JIRA)

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

stephen mallette updated TINKERPOP-1792:

Priority: Critical  (was: Major)

> Random TraversalSource Selection in GremlinScriptEngine
> ---
>
> Key: TINKERPOP-1792
> URL: https://issues.apache.org/jira/browse/TINKERPOP-1792
> Project: TinkerPop
>  Issue Type: Bug
>Reporter: stephen mallette
>Priority: Critical
>




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


[jira] [Created] (TINKERPOP-1792) Random TraversalSource selection

2017-09-25 Thread stephen mallette (JIRA)
stephen mallette created TINKERPOP-1792:
---

 Summary: Random TraversalSource selection 
 Key: TINKERPOP-1792
 URL: https://issues.apache.org/jira/browse/TINKERPOP-1792
 Project: TinkerPop
  Issue Type: Bug
Reporter: stephen mallette






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


[jira] [Updated] (TINKERPOP-1792) Random TraversalSource Selection in GremlinScriptEngine

2017-09-25 Thread stephen mallette (JIRA)

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

stephen mallette updated TINKERPOP-1792:

Affects Version/s: 3.2.6

> Random TraversalSource Selection in GremlinScriptEngine
> ---
>
> Key: TINKERPOP-1792
> URL: https://issues.apache.org/jira/browse/TINKERPOP-1792
> Project: TinkerPop
>  Issue Type: Bug
>Affects Versions: 3.2.6
>Reporter: stephen mallette
>Priority: Critical
>




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


[jira] [Updated] (TINKERPOP-1792) Random TraversalSource Selection in GremlinScriptEngine

2017-09-25 Thread stephen mallette (JIRA)

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

stephen mallette updated TINKERPOP-1792:

Description: {{GremlinScriptEngine}} implementations make a random 
{{TraversalSource}} selection when processing lambdas. Obviously it should be 
bound more clearly to the specific {{TraversalSource}} the caller requests. 
This likely means deprecating the 

> Random TraversalSource Selection in GremlinScriptEngine
> ---
>
> Key: TINKERPOP-1792
> URL: https://issues.apache.org/jira/browse/TINKERPOP-1792
> Project: TinkerPop
>  Issue Type: Bug
>Affects Versions: 3.2.6
>Reporter: stephen mallette
>Priority: Critical
>  Labels: deprecation
>
> {{GremlinScriptEngine}} implementations make a random {{TraversalSource}} 
> selection when processing lambdas. Obviously it should be bound more clearly 
> to the specific {{TraversalSource}} the caller requests. This likely means 
> deprecating the 



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


[jira] [Updated] (TINKERPOP-1792) Random TraversalSource Selection in GremlinScriptEngine

2017-09-25 Thread stephen mallette (JIRA)

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

stephen mallette updated TINKERPOP-1792:

Labels: deprecation  (was: )

> Random TraversalSource Selection in GremlinScriptEngine
> ---
>
> Key: TINKERPOP-1792
> URL: https://issues.apache.org/jira/browse/TINKERPOP-1792
> Project: TinkerPop
>  Issue Type: Bug
>Affects Versions: 3.2.6
>Reporter: stephen mallette
>Priority: Critical
>  Labels: deprecation
>
> {{GremlinScriptEngine}} implementations make a random {{TraversalSource}} 
> selection when processing lambdas. Obviously it should be bound more clearly 
> to the specific {{TraversalSource}} the caller requests. This likely means 
> deprecating the 



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


[jira] [Updated] (TINKERPOP-1792) Random TraversalSource Selection in GremlinScriptEngine

2017-09-25 Thread stephen mallette (JIRA)

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

stephen mallette updated TINKERPOP-1792:

Description: {{GremlinScriptEngine}} implementations make a random 
{{TraversalSource}} selection when processing lambdas. Obviously it should be 
bound more clearly to the specific {{TraversalSource}} the caller requests. 
Another issue that isn't completely clear is that bindings passed from the 
client share the same namespace as {{TraversalSource}} bindings which means 
that if the {{TraversalSource}} is "g" then you couldn't write a traversal 
like: {{withSideEffect(“g”, “hello”)}}. That could be smarter as well.  (was: 
{{GremlinScriptEngine}} implementations make a random {{TraversalSource}} 
selection when processing lambdas. Obviously it should be bound more clearly to 
the specific {{TraversalSource}} the caller requests. This likely means 
deprecating the )

> Random TraversalSource Selection in GremlinScriptEngine
> ---
>
> Key: TINKERPOP-1792
> URL: https://issues.apache.org/jira/browse/TINKERPOP-1792
> Project: TinkerPop
>  Issue Type: Bug
>Affects Versions: 3.2.6
>Reporter: stephen mallette
>Priority: Critical
>  Labels: deprecation
>
> {{GremlinScriptEngine}} implementations make a random {{TraversalSource}} 
> selection when processing lambdas. Obviously it should be bound more clearly 
> to the specific {{TraversalSource}} the caller requests. Another issue that 
> isn't completely clear is that bindings passed from the client share the same 
> namespace as {{TraversalSource}} bindings which means that if the 
> {{TraversalSource}} is "g" then you couldn't write a traversal like: 
> {{withSideEffect(“g”, “hello”)}}. That could be smarter as well.



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


[jira] [Commented] (TINKERPOP-1787) Allow :remote command to accept a user defined Cluster instance

2017-09-25 Thread ASF GitHub Bot (JIRA)

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

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

Github user asfgit closed the pull request at:

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


> Allow :remote command to accept a user defined Cluster instance
> ---
>
> Key: TINKERPOP-1787
> URL: https://issues.apache.org/jira/browse/TINKERPOP-1787
> Project: TinkerPop
>  Issue Type: Improvement
>  Components: plugin
>Affects Versions: 3.2.6
>Reporter: stephen mallette
>Assignee: stephen mallette
>Priority: Minor
> Fix For: 3.2.7, 3.3.1
>
>
> Make a minor adjustment to the {{DriverRemoteAcceptor}} to allow for this 
> type of syntax:
> {code}
> gremlin> cluster = Cluster.open()
> ==>localhost/127.0.0.1:8182
> gremlin> :remote connect tinkerpop.server cluster
> ==>Configured localhost/127.0.0.1:8182
> {code}
> which will provide more flexibility to those those who are trying to script 
> the console.



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


[GitHub] tinkerpop pull request #718: TINKERPOP-1787 Add syntax for :remote to accept...

2017-09-25 Thread asfgit
Github user asfgit closed the pull request at:

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


---


[GitHub] tinkerpop issue #695: TINKERPOP-1489 JavaScript GLV

2017-09-25 Thread spmallette
Github user spmallette commented on the issue:

https://github.com/apache/tinkerpop/pull/695
  
Just a note for those following this ticket's progress. I'm in the process 
of doing TINKERPOP-1784 which will add a language agnostic test suite using 
gherkin defined feature files. That should allow us to test all GLVs in a nice 
way. 


---


[jira] [Commented] (TINKERPOP-1489) Provide a Javascript Gremlin Language Variant

2017-09-25 Thread ASF GitHub Bot (JIRA)

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

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

Github user spmallette commented on the issue:

https://github.com/apache/tinkerpop/pull/695
  
Just a note for those following this ticket's progress. I'm in the process 
of doing TINKERPOP-1784 which will add a language agnostic test suite using 
gherkin defined feature files. That should allow us to test all GLVs in a nice 
way. 


> Provide a Javascript Gremlin Language Variant
> -
>
> Key: TINKERPOP-1489
> URL: https://issues.apache.org/jira/browse/TINKERPOP-1489
> Project: TinkerPop
>  Issue Type: Improvement
>  Components: javascript
>Affects Versions: 3.2.5
>Reporter: Jorge Bay
>
> It would be nice to have a Javascript Gremlin Language Variant that could 
> work with any ES5 runtime, specially the ones that support 
> [CommonJs|http://requirejs.org/docs/commonjs.html], like Node.js.
> Nashorn, the engine shipped with JDK 8+, does not implement CommonJs but 
> provides [additional 
> extensions|https://wiki.openjdk.java.net/display/Nashorn/Nashorn+extensions] 
> making modular JavaScript possible. Nashorn should be supported in order to 
> run glv tests under the same infrastructure (JDK8).



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