[DISCUSS] gremlin-python 3.2.3 GA

2016-10-05 Thread Stephen Mallette 
So, I inadvertently released gremlin-python as a release candidate in
3.2.2. As it turned out, that wasn't "bad" as we were still sorta tweaking
things and wanted to be sure the APIs were solid. I didn't see us
rethinking anything in any serious way, so I would have to say that for
3.2.3 we will go ahead with GA with gremlin-python for 3.2.3 - unless i
flub the release to pypi again ;)

Anywho, I will assume lazy consensus and go this direction unless there are
objections in the next 72 hours (Saturday October 8th, 2016 at 7:30pm est).

Thanks,

Stephen

[jira] [Commented] (TINKERPOP-1455) Provide String-based withStrategy()/withoutStrategy() for language variant usage

2016-10-05 Thread ASF GitHub Bot (JIRA) 

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

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

Github user dkuppitz commented on the issue:

https://github.com/apache/tinkerpop/pull/447
  
Cool.


> Provide String-based withStrategy()/withoutStrategy() for language variant 
> usage
> 
>
> Key: TINKERPOP-1455
> URL: https://issues.apache.org/jira/browse/TINKERPOP-1455
> Project: TinkerPop
>  Issue Type: Improvement
>  Components: language-variant, process
>Affects Versions: 3.2.2
>Reporter: Marko A. Rodriguez
>Assignee: Marko A. Rodriguez
>
> Right now {{withStrategies()}} is not supported by Gremlin-Python. Why? 
> Because strategies are created via Java and thus you can't do stuff like:
> {code}
> g.withStrategies(SubgraphStrategy.build()...create())
> {code}
> Now, we have strategies that we have made "native" to 
> {{GraphTraversalSource}} by way of {{withXXX}}. For example: 
> {{withSideEffect()}}, {{withSack()}}, {{withRemote()}}, {{withPath()}}, etc.
> In order to generally support any strategy created by a user for use from a 
> language variant, we should support lambda based strategies. E.g.:
> {code}
> g.withStrategies(lambda : "SubgraphStrategy.build()...create()")
> {code}
> Like any other lambda, it is executed server side using the respective 
> {{ScriptEngine}}.
> Next, {{withoutStrategies()}} should support {{String...}} so you can do:
> {code}
> g.withoutStrategies("com.stuff.MyStrategy", "com.stuff.MyOtherStrategy")
> {code}
> ..instead of having to pass in the {{Class}} object.



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

[GitHub] tinkerpop issue #447: TINKERPOP-1455: Provide String-based withStrategy()/wi...

2016-10-05 Thread dkuppitz 
Github user dkuppitz commented on the issue:

https://github.com/apache/tinkerpop/pull/447
  
Cool.


---
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-1044) ResponseMessage should contain server-side exception name.

2016-10-05 Thread ASF GitHub Bot (JIRA) 

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

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

Github user vrkrishn commented on the issue:

https://github.com/apache/tinkerpop/pull/440
  
Yeah I can take care of the AbstractEvalOpProcessor


> ResponseMessage should contain server-side exception name.
> --
>
> Key: TINKERPOP-1044
> URL: https://issues.apache.org/jira/browse/TINKERPOP-1044
> Project: TinkerPop
>  Issue Type: Improvement
>  Components: server
>Affects Versions: 3.1.0-incubating
>Reporter: Bob Briody
>Priority: Minor
>
> When an exception occurs during execution by gremlin server, the 
> ResponseMessage currently contains the Exception message, but it would also 
> be helpful to include the Exception class name.



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

[jira] [Closed] (TINKERPOP-1486) Improve API of RemoteConnection

2016-10-05 Thread stephen mallette (JIRA) 

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

stephen mallette closed TINKERPOP-1486.
---
   Resolution: Done
Fix Version/s: 3.2.3

There was some discussion on the mailing list a while back during development 
of these APIs that basically talked about re-use of existing naming and API 
concepts and not creating "new things". I think this is one of those situations 
as your suggestions would almost takes us back to what we originally had for 
these APIs. 

Anyway, I agree that it could be confusing for an implementer to figure out 
what to do, so I added more javadocs/comments and made the subject of the 
problem {{nextTraverser()}} an abstract method so that implementers know to 
deal with that method specifically.

Implemented here via CTR: 
https://github.com/apache/tinkerpop/commit/d43d4e01a3299f9031a2b1ac38790e67f1fe01cb

> Improve API of RemoteConnection
> ---
>
> Key: TINKERPOP-1486
> URL: https://issues.apache.org/jira/browse/TINKERPOP-1486
> Project: TinkerPop
>  Issue Type: Improvement
>  Components: language-variant, process
>Affects Versions: 3.2.2
>Reporter: Kevin Gallardo
>Assignee: stephen mallette
> Fix For: 3.2.3
>
>
> Currently an implementor that wants to define a _RemoteConnection_ 
> implementation must return a _RemoteTraversal_ object from the 
> {{RemoteConnection#submit(Bytecode)}} method.
> Thus it needs to implement a specific _RemoteTraversal_ class. When 
> implementing a _RemoteTraversal_ we need to implement the methods {{next()}} 
> and {{hasNext()}}. However these methods never seem to get called. Moreover, 
> we need to implement the method {{nextTraverser()}} which is the one that is 
> actually going to get called, but the method is not abstract and it is not 
> natural to understand that this particular method needs to be implemented.
> It seems like all the other methods of _RemoteTraversal_ are never called as 
> well since it is only used in _RemoteStep_, which only calls 
> {{nextTraverser()}}. I wonder if we could stop using the _RemoteTraversal_ 
> and instead have the {{submit()}} method return a simple abstract class that 
> has:
> - abstract method {{nextTraverser()}} returns _Traverser_
> - abstract method {{getSideEffects()}} returns _SideEffects_
> - possibly extend it later with others



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

[GitHub] tinkerpop issue #440: TINKERPOP-1044: Gremlin server REST endpoint - Add Exc...

2016-10-05 Thread spmallette 
Github user spmallette commented on the issue:

https://github.com/apache/tinkerpop/pull/440
  
Glad that's working. Did you still intend to make the fix for the other 
channelizers in `AbstractEvalOpProcessor`? 

As for titan, i guess you would build this branch of tinkerpop with the 
work ongoing here: https://github.com/thinkaurelius/titan/pull/1312


---
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 #440: TINKERPOP-1044: Gremlin server REST endpoint - Add Exc...

2016-10-05 Thread vrkrishn 
Github user vrkrishn commented on the issue:

https://github.com/apache/tinkerpop/pull/440
  
Luckily I was able to spin up a Linux VM and run the integration tests

Tests run: 31, Failures: 0, Errors: 0, Skipped: 1, Time elapsed: 162.807 
sec - in org.apache.tinkerpop.gremlin.server.GremlinServerIntegrateTest

Results :
Tests run: 163, Failures: 0, Errors: 0, Skipped: 13


Also, I am currently using titan 1 which depends on gremlin-server 3.1 i 
think, what would be the best way to adapt this change to my current distro of 
titan?



---
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 #447: TINKERPOP-1455: Provide String-based withStrategy()/wi...

2016-10-05 Thread spmallette 
Github user spmallette commented on the issue:

https://github.com/apache/tinkerpop/pull/447
  
no problem from me.


---
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-1455) Provide String-based withStrategy()/withoutStrategy() for language variant usage

2016-10-05 Thread ASF GitHub Bot (JIRA) 

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

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

Github user okram commented on the issue:

https://github.com/apache/tinkerpop/pull/447
  
If you guys don't mind, I'm going to change the method signatures (the NEW 
methods added -- nothing from before changed).

{code}
withStrategy(String, Object...) -> withStrategies(Map...)
withoutStrategy(String) -> withoutStrategies(String...)
{code}

The reason this is smart is:

1. Registering strategies is expensive as it costs a `TraversalSource` 
clone and a `TraversalStrategies` sort. This is why doing all strategy 
declarations in one method is smart.

2. While creating `Map`s in Java is horrendous, Java users would NOT use 
these methods. They would use the Java object version of these methods. 
However, for Gremlin-Python, Groovy, JavaScript -- creating maps is natural and 
looks good. Also, we don't run into the "multi-key" issues.

Nothing fudamental here, just some asethetics. If you don't object, I will 
just do this, update docs, and merge.


> Provide String-based withStrategy()/withoutStrategy() for language variant 
> usage
> 
>
> Key: TINKERPOP-1455
> URL: https://issues.apache.org/jira/browse/TINKERPOP-1455
> Project: TinkerPop
>  Issue Type: Improvement
>  Components: language-variant, process
>Affects Versions: 3.2.2
>Reporter: Marko A. Rodriguez
>Assignee: Marko A. Rodriguez
>
> Right now {{withStrategies()}} is not supported by Gremlin-Python. Why? 
> Because strategies are created via Java and thus you can't do stuff like:
> {code}
> g.withStrategies(SubgraphStrategy.build()...create())
> {code}
> Now, we have strategies that we have made "native" to 
> {{GraphTraversalSource}} by way of {{withXXX}}. For example: 
> {{withSideEffect()}}, {{withSack()}}, {{withRemote()}}, {{withPath()}}, etc.
> In order to generally support any strategy created by a user for use from a 
> language variant, we should support lambda based strategies. E.g.:
> {code}
> g.withStrategies(lambda : "SubgraphStrategy.build()...create()")
> {code}
> Like any other lambda, it is executed server side using the respective 
> {{ScriptEngine}}.
> Next, {{withoutStrategies()}} should support {{String...}} so you can do:
> {code}
> g.withoutStrategies("com.stuff.MyStrategy", "com.stuff.MyOtherStrategy")
> {code}
> ..instead of having to pass in the {{Class}} object.



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

[jira] [Commented] (TINKERPOP-1455) Provide String-based withStrategy()/withoutStrategy() for language variant usage

2016-10-05 Thread ASF GitHub Bot (JIRA) 

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

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

Github user spmallette commented on the issue:

https://github.com/apache/tinkerpop/pull/447
  
This is a great PR. Didn't think we'd have this for 3.2.3. Nice

All tests pass with `docker/build.sh -t -i` - final "todo" would be to add 
a JIRA to track the deprecation for future removal. 

VOTE +1


> Provide String-based withStrategy()/withoutStrategy() for language variant 
> usage
> 
>
> Key: TINKERPOP-1455
> URL: https://issues.apache.org/jira/browse/TINKERPOP-1455
> Project: TinkerPop
>  Issue Type: Improvement
>  Components: language-variant, process
>Affects Versions: 3.2.2
>Reporter: Marko A. Rodriguez
>Assignee: Marko A. Rodriguez
>
> Right now {{withStrategies()}} is not supported by Gremlin-Python. Why? 
> Because strategies are created via Java and thus you can't do stuff like:
> {code}
> g.withStrategies(SubgraphStrategy.build()...create())
> {code}
> Now, we have strategies that we have made "native" to 
> {{GraphTraversalSource}} by way of {{withXXX}}. For example: 
> {{withSideEffect()}}, {{withSack()}}, {{withRemote()}}, {{withPath()}}, etc.
> In order to generally support any strategy created by a user for use from a 
> language variant, we should support lambda based strategies. E.g.:
> {code}
> g.withStrategies(lambda : "SubgraphStrategy.build()...create()")
> {code}
> Like any other lambda, it is executed server side using the respective 
> {{ScriptEngine}}.
> Next, {{withoutStrategies()}} should support {{String...}} so you can do:
> {code}
> g.withoutStrategies("com.stuff.MyStrategy", "com.stuff.MyOtherStrategy")
> {code}
> ..instead of having to pass in the {{Class}} object.



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

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

2016-10-05 Thread ASF GitHub Bot (JIRA) 

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

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

Github user okram commented on the issue:

https://github.com/apache/tinkerpop/pull/450
  
I just created this ticket: 
https://issues.apache.org/jira/browse/TINKERPOP-1490

@jorgebay -- can you review that ticket in terms of the `one()`, `list()` 
callback model you are using here to see if we can get rid of `one()` and 
`list()` and supplant it with an `async()`. 


> Provide a Javascript Gremlin Language Variant
> -
>
> Key: TINKERPOP-1489
> URL: https://issues.apache.org/jira/browse/TINKERPOP-1489
> Project: TinkerPop
>  Issue Type: Improvement
>  Components: language-variant
>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.3.4#6332)

[GitHub] tinkerpop issue #450: TINKERPOP-1489 Javascript GLV

2016-10-05 Thread okram 
Github user okram commented on the issue:

https://github.com/apache/tinkerpop/pull/450
  
I just created this ticket: 
https://issues.apache.org/jira/browse/TINKERPOP-1490

@jorgebay -- can you review that ticket in terms of the `one()`, `list()` 
callback model you are using here to see if we can get rid of `one()` and 
`list()` and supplant it with an `async()`. 


---
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-1489) Provide a Javascript Gremlin Language Variant

2016-10-05 Thread ASF GitHub Bot (JIRA) 

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

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

Github user okram commented on the issue:

https://github.com/apache/tinkerpop/pull/450
  
I did a preliminary review of the code and it looks good. Primarily because 
it mimics the structure and content of Gremlin-Python. Ensuring consistency 
between all variants is important from a maintainability standpoint.

Here are some concerns:

1. I think we need a `RemoteConnection` implementation. From what I'm 
reading, it seems we don't have one.
2. @mbroecheler was pushing for async methods in Gremlin-Java (thus, 
"Gremlin"). The idea was to have `Future 
Traversal.async(Function)`. Thus, to do a "future" `toList()` in 
Java, you would do `result = g.V().out().async(Traversal::toList)`. I think we 
should do this in Gremlin-Java and then have this same "callback" model used by 
Gremlin-JS and thus, not have `one()` and `list()` with callbacks. Does that 
make sense?
3. I don't see the Gremlin `ProcessTestSuite` being run. We will need 
`Providers` to do so. Please see how this works in Gremlin-Python. 
https://github.com/apache/tinkerpop/tree/master/gremlin-python/src/test/java/org/apache/tinkerpop/gremlin/python/jsr223.
4. We will need documentation in `gremlin-variants.asciidoc`.

I suspect we will want to merge this first into an Apache TinkerPop branch 
and can nit pick things as I see them before an ultimate merge into `master/`. 
For instance, I can do 3 and 4 above if perhaps @jorgebay provides some notes 
so I get the important aspects in the documentation.


> Provide a Javascript Gremlin Language Variant
> -
>
> Key: TINKERPOP-1489
> URL: https://issues.apache.org/jira/browse/TINKERPOP-1489
> Project: TinkerPop
>  Issue Type: Improvement
>  Components: language-variant
>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.3.4#6332)

[GitHub] tinkerpop issue #450: Javascript GLV

2016-10-05 Thread spmallette 
Github user spmallette commented on the issue:

https://github.com/apache/tinkerpop/pull/450
  
@jorgebay thanks for this. I have a feeling it will take a some time to 
review this work and get community input. hopefully @jbmusso will have time to 
get involved.

in the mean time could you please rename your pull request to include the 
JIRA number as the prefix - something like: "TINKERPOP-1489 Javascript GLV" 
Apache automation will then be able to do it's work with JIRA.


---
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-1489) Provide a Javascript Gremlin Language Variant

2016-10-05 Thread ASF GitHub Bot (JIRA) 

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

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

Github user spmallette commented on the issue:

https://github.com/apache/tinkerpop/pull/450
  
@jorgebay thanks for this. I have a feeling it will take a some time to 
review this work and get community input. hopefully @jbmusso will have time to 
get involved.

in the mean time could you please rename your pull request to include the 
JIRA number as the prefix - something like: "TINKERPOP-1489 Javascript GLV" 
Apache automation will then be able to do it's work with JIRA.


> Provide a Javascript Gremlin Language Variant
> -
>
> Key: TINKERPOP-1489
> URL: https://issues.apache.org/jira/browse/TINKERPOP-1489
> Project: TinkerPop
>  Issue Type: Improvement
>  Components: language-variant
>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.3.4#6332)

[GitHub] tinkerpop issue #450: Javascript GLV

2016-10-05 Thread jorgebay 
Github user jorgebay commented on the issue:

https://github.com/apache/tinkerpop/pull/450
  
Thanks @PommeVerte for getting a first look at it so fast.

About `list()` and `one()`:

- `next()` is a method exposed by the [Iterator protocol][1] which in newer 
versions of Ecmascript are used by [generators][2]. It could be confusing for 
the users, as it could give the impression that it is iterable but it isn't, 
users might be misguided to use it in this way: `for (let vertex of g.V())` 
(doesn't work because iterator protocol is sync only). Other possible names 
besides `one(callback)`: `getNext(callback)`, `getFirst(callback)`, 
`first(callback)`, `single(callback)` .
- `toList()` in JS sounded to me like a sync conversion method, ie: `const 
x = y.toList()`, so I went for leaving the `to` out: `list(callback)`, but 
maybe this is too personal...

Regarding not including the driver:

I think different `RemoteConnection` implementations could live outside of 
the TinkerPop repository (at least for now) as it would increase the complexity 
of the test harness inside TinkerPop.
[gremlin-javascript client][3] already implements most of the logic of the 
driver for Node.js, it would be possible to repurpose it to be a GLV 
`RemoteConnection` implementation but it would only be valid for Node.js (4+?).


[1]:https://developer.mozilla.org/en/docs/Web/JavaScript/Reference/Iteration_protocols#iterator

[2]:https://developer.mozilla.org/en/docs/Web/JavaScript/Reference/Iteration_protocols#With_a_generator

[3]:https://github.com/jbmusso/gremlin-javascript/blob/master/src/GremlinClient.js


---
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 #450: Javascript GLV

2016-10-05 Thread PommeVerte 
Github user PommeVerte commented on the issue:

https://github.com/apache/tinkerpop/pull/450
  
Nice PR @jorgebay 
Can you elaborate on why you went for `list()` and `one()` rather than 
keeping the original method names of `toList()` and `next()`? I understand that 
they would still have to require callbacks but I guess the point I'm trying to 
make is that it would probably be better to stick to the original naming to 
stay consistent with gremlin documentation, and then document the variations in 
a JS GLV specific documentation. 
So : 

```javascript
g.V().hasLabel('software').toList((err, vertices) => { 
  vertices.forEach(console.log);
});

g.V().has('name','marko').next((err, vertex) => { 
  console.log(vertex.label); // person
});
```

Thoughts?

Also, you mentioned not including the Driver because Javascript engines 
does not provide a standard IO library. What would your suggestion be here? Was 
that just an invitation for the community to figure out if we should use an 
existing library or write a new driver?
Do you have any insight here in regards to something like 
[gremlin-javascript](https://github.com/jbmusso/gremlin-javascript)? (minus 
that it's not 
 ECMAScript5 native and doesn't currently support ByteCode). 

Anyways, I think we would proceed to rewrite a minimal version for the GLV 
anyways. 





---
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-1489) Provide a Javascript Gremlin Language Variant

2016-10-05 Thread ASF GitHub Bot (JIRA) 

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

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

GitHub user jorgebay opened a pull request:

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

Javascript GLV

For [TINKERPOP-1489](https://issues.apache.org/jira/browse/TINKERPOP-1489).
- Should work with any ES5 engine that supports CommonJs: tested with 
Nashorn and Node.js.
- Maintained the same structure as the Python GLV.
- Used groovy classes to generate all the traversal methods.
- Javascript tests run in the test maven phase (JS test names are not 
printed though...)
- Javascript engines are designed to run user code in a single thread, IO 
libraries (like libuv on Node.js) are async only. With that in mind, there 
isn't sync IO methods exposed in the Traversal (ie: `#next()`, `#toList()`). 
Instead I exposed `#list()` and `one()` that take a callback as a parameter:

```javascript
g.V().hasLabel('software').list((err, vertices) => { 
  vertices.forEach(console.log);
});

g.V().has('name','marko').one((err, vertex) => { 
  console.log(vertex.label); // person
});
```

This patch is focused in providing a Javascript GLV that would be useful 
for most runtimes, most notably Node.js. It implements a Graph, GraphTraversal 
and GraphTraversalSource, along with GraphSONReader and GraphSONWriter.
It includes base classes for RemoteConnection, RemoteTraversal and 
RemoteStrategy, but doesn't include DriverRemoteConnection implementation as 
Javascript engines does not provide a standard IO library.

As a first step, the idea is to include in the TinkerPop project the 
specification for the language variant, the serialization functionality and the 
execution methods (currently named `list()` and `one()`).

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

$ git pull https://github.com/jorgebay/tinkerpop javascript-glv

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

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


commit 5f7a670bceedd0c65f5c1b8e00a06f4d8cdac912
Author: Jorge Bay Gondra 
Date:   2016-10-05T14:14:46Z

Javascript GLV




> Provide a Javascript Gremlin Language Variant
> -
>
> Key: TINKERPOP-1489
> URL: https://issues.apache.org/jira/browse/TINKERPOP-1489
> Project: TinkerPop
>  Issue Type: Improvement
>  Components: language-variant
>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.3.4#6332)

[GitHub] tinkerpop pull request #450: Javascript GLV

2016-10-05 Thread jorgebay 
GitHub user jorgebay opened a pull request:

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

Javascript GLV

For [TINKERPOP-1489](https://issues.apache.org/jira/browse/TINKERPOP-1489).
- Should work with any ES5 engine that supports CommonJs: tested with 
Nashorn and Node.js.
- Maintained the same structure as the Python GLV.
- Used groovy classes to generate all the traversal methods.
- Javascript tests run in the test maven phase (JS test names are not 
printed though...)
- Javascript engines are designed to run user code in a single thread, IO 
libraries (like libuv on Node.js) are async only. With that in mind, there 
isn't sync IO methods exposed in the Traversal (ie: `#next()`, `#toList()`). 
Instead I exposed `#list()` and `one()` that take a callback as a parameter:

```javascript
g.V().hasLabel('software').list((err, vertices) => { 
  vertices.forEach(console.log);
});

g.V().has('name','marko').one((err, vertex) => { 
  console.log(vertex.label); // person
});
```

This patch is focused in providing a Javascript GLV that would be useful 
for most runtimes, most notably Node.js. It implements a Graph, GraphTraversal 
and GraphTraversalSource, along with GraphSONReader and GraphSONWriter.
It includes base classes for RemoteConnection, RemoteTraversal and 
RemoteStrategy, but doesn't include DriverRemoteConnection implementation as 
Javascript engines does not provide a standard IO library.

As a first step, the idea is to include in the TinkerPop project the 
specification for the language variant, the serialization functionality and the 
execution methods (currently named `list()` and `one()`).

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

$ git pull https://github.com/jorgebay/tinkerpop javascript-glv

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

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


commit 5f7a670bceedd0c65f5c1b8e00a06f4d8cdac912
Author: Jorge Bay Gondra 
Date:   2016-10-05T14:14:46Z

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

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

2016-10-05 Thread Jorge Bay (JIRA) 

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

Jorge Bay commented on TINKERPOP-1489:
--

I'll submit a pull request shortly for a Javascript GLV, using the same 
approach as the Python GLV (generating methods in groovy; similar structure; 
...) 

> Provide a Javascript Gremlin Language Variant
> -
>
> Key: TINKERPOP-1489
> URL: https://issues.apache.org/jira/browse/TINKERPOP-1489
> Project: TinkerPop
>  Issue Type: Improvement
>  Components: language-variant
>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.3.4#6332)

[jira] [Commented] (TINKERPOP-1455) Provide String-based withStrategy()/withoutStrategy() for language variant usage

2016-10-05 Thread ASF GitHub Bot (JIRA) 

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

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

Github user dkuppitz commented on the issue:

https://github.com/apache/tinkerpop/pull/447
  
Code looks good, `docker/build.sh -t -i` succeeded.

VOTE: +1


> Provide String-based withStrategy()/withoutStrategy() for language variant 
> usage
> 
>
> Key: TINKERPOP-1455
> URL: https://issues.apache.org/jira/browse/TINKERPOP-1455
> Project: TinkerPop
>  Issue Type: Improvement
>  Components: language-variant, process
>Affects Versions: 3.2.2
>Reporter: Marko A. Rodriguez
>Assignee: Marko A. Rodriguez
>
> Right now {{withStrategies()}} is not supported by Gremlin-Python. Why? 
> Because strategies are created via Java and thus you can't do stuff like:
> {code}
> g.withStrategies(SubgraphStrategy.build()...create())
> {code}
> Now, we have strategies that we have made "native" to 
> {{GraphTraversalSource}} by way of {{withXXX}}. For example: 
> {{withSideEffect()}}, {{withSack()}}, {{withRemote()}}, {{withPath()}}, etc.
> In order to generally support any strategy created by a user for use from a 
> language variant, we should support lambda based strategies. E.g.:
> {code}
> g.withStrategies(lambda : "SubgraphStrategy.build()...create()")
> {code}
> Like any other lambda, it is executed server side using the respective 
> {{ScriptEngine}}.
> Next, {{withoutStrategies()}} should support {{String...}} so you can do:
> {code}
> g.withoutStrategies("com.stuff.MyStrategy", "com.stuff.MyOtherStrategy")
> {code}
> ..instead of having to pass in the {{Class}} object.



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

[GitHub] tinkerpop issue #447: TINKERPOP-1455: Provide String-based withStrategy()/wi...

2016-10-05 Thread dkuppitz 
Github user dkuppitz commented on the issue:

https://github.com/apache/tinkerpop/pull/447
  
Code looks good, `docker/build.sh -t -i` succeeded.

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

[GitHub] tinkerpop issue #444: TINKERPOP-1158 gremlin.sh -v emits log4j initializatio...

2016-10-05 Thread dkuppitz 
Github user dkuppitz commented on the issue:

https://github.com/apache/tinkerpop/pull/444
  
The gist was that you could live without the 2 additional files, but your 
life would be affected by an everlasting sadness. Hence we concluded that we 
keep the symbolic links.

However, I still need one more vote to merge this PR.


---
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-1158) gremlin.sh -v emits log4j initialization errors

2016-10-05 Thread ASF GitHub Bot (JIRA) 

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

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

Github user dkuppitz commented on the issue:

https://github.com/apache/tinkerpop/pull/444
  
The gist was that you could live without the 2 additional files, but your 
life would be affected by an everlasting sadness. Hence we concluded that we 
keep the symbolic links.

However, I still need one more vote to merge this PR.


> gremlin.sh -v emits log4j initialization errors
> ---
>
> Key: TINKERPOP-1158
> URL: https://issues.apache.org/jira/browse/TINKERPOP-1158
> Project: TinkerPop
>  Issue Type: Bug
>  Components: console
>Affects Versions: 3.1.1-incubating
>Reporter: Ariel Weisberg
>Assignee: Daniel Kuppitz
>Priority: Trivial
>
> I get a bunch of unrelated noise from log4j when I run hash 
> [c0b79c5|https://github.com/apache/incubator-tinkerpop/tree/c0b79c5c65db6424407ca00144be5167052c6c6b].
> I am running from the bin directory of the repository after {{mvn clean 
> install}}.
> {noformat}
> $ ./gremlin.sh -v
>  log4j:WARN No appenders could be found for logger 
> (com.jcabi.manifests.Manifests).
> log4j:WARN Please initialize the log4j system properly.
> log4j:WARN See http://logging.apache.org/log4j/1.2/faq.html#noconfig for more 
> info.
> gremlin 3.2.0-SNAPSHOT
> {noformat}



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

[jira] [Commented] (TINKERPOP-1455) Provide String-based withStrategy()/withoutStrategy() for language variant usage

2016-10-05 Thread ASF GitHub Bot (JIRA) 

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

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

Github user okram commented on the issue:

https://github.com/apache/tinkerpop/pull/447
  
```
[INFO] 

[INFO] BUILD SUCCESS
[INFO] 

[INFO] Total time: 05:09 h
[INFO] Finished at: 2016-10-04T22:33:42-06:00
[INFO] Final Memory: 157M/1520M
[INFO] 

```


> Provide String-based withStrategy()/withoutStrategy() for language variant 
> usage
> 
>
> Key: TINKERPOP-1455
> URL: https://issues.apache.org/jira/browse/TINKERPOP-1455
> Project: TinkerPop
>  Issue Type: Improvement
>  Components: language-variant, process
>Affects Versions: 3.2.2
>Reporter: Marko A. Rodriguez
>Assignee: Marko A. Rodriguez
>
> Right now {{withStrategies()}} is not supported by Gremlin-Python. Why? 
> Because strategies are created via Java and thus you can't do stuff like:
> {code}
> g.withStrategies(SubgraphStrategy.build()...create())
> {code}
> Now, we have strategies that we have made "native" to 
> {{GraphTraversalSource}} by way of {{withXXX}}. For example: 
> {{withSideEffect()}}, {{withSack()}}, {{withRemote()}}, {{withPath()}}, etc.
> In order to generally support any strategy created by a user for use from a 
> language variant, we should support lambda based strategies. E.g.:
> {code}
> g.withStrategies(lambda : "SubgraphStrategy.build()...create()")
> {code}
> Like any other lambda, it is executed server side using the respective 
> {{ScriptEngine}}.
> Next, {{withoutStrategies()}} should support {{String...}} so you can do:
> {code}
> g.withoutStrategies("com.stuff.MyStrategy", "com.stuff.MyOtherStrategy")
> {code}
> ..instead of having to pass in the {{Class}} object.



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

[jira] [Commented] (TINKERPOP-1158) gremlin.sh -v emits log4j initialization errors

2016-10-05 Thread ASF GitHub Bot (JIRA) 

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

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

Github user okram commented on the issue:

https://github.com/apache/tinkerpop/pull/444
  
Already did. Told @dkuppitz what he wanted to know... I forget what he 
deduced from that.


> gremlin.sh -v emits log4j initialization errors
> ---
>
> Key: TINKERPOP-1158
> URL: https://issues.apache.org/jira/browse/TINKERPOP-1158
> Project: TinkerPop
>  Issue Type: Bug
>  Components: console
>Affects Versions: 3.1.1-incubating
>Reporter: Ariel Weisberg
>Assignee: Daniel Kuppitz
>Priority: Trivial
>
> I get a bunch of unrelated noise from log4j when I run hash 
> [c0b79c5|https://github.com/apache/incubator-tinkerpop/tree/c0b79c5c65db6424407ca00144be5167052c6c6b].
> I am running from the bin directory of the repository after {{mvn clean 
> install}}.
> {noformat}
> $ ./gremlin.sh -v
>  log4j:WARN No appenders could be found for logger 
> (com.jcabi.manifests.Manifests).
> log4j:WARN Please initialize the log4j system properly.
> log4j:WARN See http://logging.apache.org/log4j/1.2/faq.html#noconfig for more 
> info.
> gremlin 3.2.0-SNAPSHOT
> {noformat}



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