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

[Stephen Mallette]

The diagram is excellent. Nice to see that we have the separate modules
approach in place for each GLV - very nice direction.

I like this idea:

> 1. bin/gremlin.sh —language gremlin-python

it would be nice to have a universal gremlin console though it may mean a
departure from the dependence on groovysh to do so. I'd have to think about
that one - it might not be as easy as just "swapping out the scriptengine".

On Wed, Jun 22, 2016 at 4:56 PM, Marko Rodriguez 
wrote:

> Hello,
>
> I created gremlin-python/ package and killed gremlin-variant/ package.
> Thus, the links I provided in the email earlier this morning are busted.
> You can move around from here to re-find the references.
>
> https://github.com/apache/tinkerpop/tree/TINKERPOP-1278/gremlin-python/src/main
> <
> https://github.com/apache/tinkerpop/tree/TINKERPOP-1278/gremlin-python/src/main
> >
>
> Thanks,
> Marko.
>
> http://markorodriguez.com
>
>
>
> > On Jun 22, 2016, at 7:36 AM, Marko Rodriguez 
> wrote:
> >
> > Hello,
> >
> > I have been working on TINKERPOP-1278 for a couple of weeks now and here
> is where my thoughts are going.
> >
> > First, a review of the concepts.
> >
> >   1. Apache TinkerPop is a JVM-based graph computing framework.
> >   2. Gremlin can be embedded/represented in any programming language
> that supports function composition and function nesting.
> >   - Every programming language supports these two constructs.
> >   3. There are two ways in which XXX language can work with Apache
> TinkerPop.
> >   a.) XXXScriptEngine can directly use TinkerPop classes.
> >   b.) XXX “mocks” of TinkerPop’s Traversal and
> RemoteConnection in the respective language.
> >   4. The language that is representing/hosting Gremlin is called the
> “source language.”
> >   5. The language that the Gremlin traversal will ultimately be
> executed on in the JVM is called the “target language.”
> >   6. It is the responsibility of a Translator to translate the
> source language into the target language.
> >
> https://github.com/apache/tinkerpop/blob/TINKERPOP-1278/gremlin-core/src/main/java/org/apache/tinkerpop/gremlin/process/traversal/util/Translator.java
> <
> https://github.com/apache/tinkerpop/blob/TINKERPOP-1278/gremlin-core/src/main/java/org/apache/tinkerpop/gremlin/process/traversal/util/Translator.java
> >
> >   - getAlias() is function naming.
> >   - addStep(), addSpawnStep(), addSource() is
> function composition.
> >   - getAnonymousTraversalTranslator() is function
> nesting.
> >   - getSourceLanguage() and getTargetLanguage() is
> translator metadata.
> >   7. It is possible/reasonable for both source and target languages
> to be on the JVM.
> >   - For example, Gremlin-Java translating to Gremlin-Groovy
> so it can avoid the complications of serialization and support remote
> lambda execution.
> >
> https://github.com/apache/tinkerpop/blob/TINKERPOP-1278/gremlin-groovy/src/main/java/org/apache/tinkerpop/gremlin/groovy/GroovyTranslator.java#L58-L66
> <
> https://github.com/apache/tinkerpop/blob/TINKERPOP-1278/gremlin-groovy/src/main/java/org/apache/tinkerpop/gremlin/groovy/GroovyTranslator.java#L58-L66
> >
> >
> > From this foundation, we should work towards the following:
> >
> >   1. bin/gremlin.sh —language gremlin-python
> >   - this will load up a GremlinConsole where a
> GremlinJythonScriptEngine is used to read and return results.
> >   - same gremlin> and ==> look-and-feel, but now its Python,
> not Groovy that is the scripting language.
> >   - In this way, Python people can work with TinkerPop and
> NEVER leave Python.
> >   2. Moving forward, we then have gremlin-jruby and respective
> GremlinJRubyScriptEngine.
> >   - In this way, Ruby people can work with TinkerPop and
> NEVER leave Ruby.
> >   3. Unlike Groovy, Python and Ruby have representations outside of
> the JVM and thus, need VM agnostic code (i.e. they can’t just “new
> GraphTraversal”).
> >   - PythonGraphTraversal (which is NOT just GraphTraversal
> used by Gremlin-Jython on the JVM).
> >
> https://github.com/apache/tinkerpop/blob/TINKERPOP-1278/gremlin-variant/src/main/jython/gremlin_python/gremlin_python.py
> <
> https://github.com/apache/tinkerpop/blob/TINKERPOP-1278/gremlin-variant/src/main/jython/gremlin_python/gremlin_python.py
> >
> >   - It is simple to auto generate XXX
> language “mocks” using reflection.
> >
> https://github.com/apache/tinkerpop/blob/TINKERPOP-1278/gremlin-variant/src/main/groovy/org/apache/tinkerpop/gremlin/python/GremlinPythonGenerator.groovy
> <
> https://github.com/apache/tinkerpop/blob/TINKERPOP-1278/gremlin-variant/src/main/groovy/org/apache/tinkerpop/gremlin/python/GremlinPythonGenerator.groovy
> >
> >   - Translators allow for the translation of XXX languag

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

[Marko Rodriguez]

Hello,

I created gremlin-python/ package and killed gremlin-variant/ package. Thus, 
the links I provided in the email earlier this morning are busted. You can move 
around from here to re-find the references.

https://github.com/apache/tinkerpop/tree/TINKERPOP-1278/gremlin-python/src/main 


Thanks,
Marko.

http://markorodriguez.com



> On Jun 22, 2016, at 7:36 AM, Marko Rodriguez  wrote:
> 
> Hello,
> 
> I have been working on TINKERPOP-1278 for a couple of weeks now and here is 
> where my thoughts are going.
> 
> First, a review of the concepts.
> 
>   1. Apache TinkerPop is a JVM-based graph computing framework.
>   2. Gremlin can be embedded/represented in any programming language that 
> supports function composition and function nesting.
>   - Every programming language supports these two constructs.
>   3. There are two ways in which XXX language can work with Apache 
> TinkerPop.
>   a.) XXXScriptEngine can directly use TinkerPop classes.
>   b.) XXX “mocks” of TinkerPop’s Traversal and RemoteConnection 
> in the respective language.
>   4. The language that is representing/hosting Gremlin is called the 
> “source language.”
>   5. The language that the Gremlin traversal will ultimately be executed 
> on in the JVM is called the “target language.”
>   6. It is the responsibility of a Translator to translate the source 
> language into the target language.
>   
> https://github.com/apache/tinkerpop/blob/TINKERPOP-1278/gremlin-core/src/main/java/org/apache/tinkerpop/gremlin/process/traversal/util/Translator.java
>  
> 
>  
>   - getAlias() is function naming.
>   - addStep(), addSpawnStep(), addSource() is function 
> composition.
>   - getAnonymousTraversalTranslator() is function nesting.
>   - getSourceLanguage() and getTargetLanguage() is 
> translator metadata.
>   7. It is possible/reasonable for both source and target languages to be 
> on the JVM.
>   - For example, Gremlin-Java translating to Gremlin-Groovy so it 
> can avoid the complications of serialization and support remote lambda 
> execution.
>   
> https://github.com/apache/tinkerpop/blob/TINKERPOP-1278/gremlin-groovy/src/main/java/org/apache/tinkerpop/gremlin/groovy/GroovyTranslator.java#L58-L66
>  
> 
> 
> From this foundation, we should work towards the following:
> 
>   1. bin/gremlin.sh —language gremlin-python
>   - this will load up a GremlinConsole where a 
> GremlinJythonScriptEngine is used to read and return results.
>   - same gremlin> and ==> look-and-feel, but now its Python, not 
> Groovy that is the scripting language.
>   - In this way, Python people can work with TinkerPop and NEVER 
> leave Python.
>   2. Moving forward, we then have gremlin-jruby and respective 
> GremlinJRubyScriptEngine.
>   - In this way, Ruby people can work with TinkerPop and NEVER 
> leave Ruby.
>   3. Unlike Groovy, Python and Ruby have representations outside of the 
> JVM and thus, need VM agnostic code (i.e. they can’t just “new 
> GraphTraversal”).
>   - PythonGraphTraversal (which is NOT just GraphTraversal used 
> by Gremlin-Jython on the JVM).
>   
> https://github.com/apache/tinkerpop/blob/TINKERPOP-1278/gremlin-variant/src/main/jython/gremlin_python/gremlin_python.py
>  
> 
>   - It is simple to auto generate XXX language 
> “mocks” using reflection.
>   
> https://github.com/apache/tinkerpop/blob/TINKERPOP-1278/gremlin-variant/src/main/groovy/org/apache/tinkerpop/gremlin/python/GremlinPythonGenerator.groovy
>  
> 
>   - Translators allow for the translation of XXX language 
> traversals to YYY language traversals on the JVM for execution by TinkerPop.
>   
> https://github.com/apache/tinkerpop/blob/TINKERPOP-1278/gremlin-variant/src/main/jython/gremlin_python/groovy_translator.py
>  
> 
>   When GremlinJythonScriptEngine exists, we should have

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

[Marko Rodriguez]

Hi,

Kuppitz just brought up something in chat and I remembered something we did for 
Rexster back in the TinkerPop2 days.

~/software/tinkerpop bin/gremlin.sh

 \,,,/
 (o o)
-oOOo-(3)-oOOo-
plugin activated: tinkerpop.server
plugin activated: tinkerpop.utilities
plugin activated: tinkerpop.tinkergraph
plugin activated: tinkerpop.gremlin-groovy
plugin activated: tinkerpop.gremlin-jython
gremlin> :script-engine
==>gremlin-groovy
gremlin> a = 2
==>2
gremlin> a.getClass()
==>class java.lang.Integer
gremlin> :script-engine gremlin-jython
==>now using gremlin-jython
gremlin> a
==>2
gremlin> type(a)

gremlin>

In short, one Bindings that is moved between ScriptEngine backings. The 
GremlinConsole allows us to jump between languages and keep the same bindings. 
g, graph, etc. In this way, the GremlinConsole is not tied to Groovy, but 
instead, while using the power of Groovysh, can I/O to any ScriptEngine.

Marko.

http://markorodriguez.com



> On Jun 22, 2016, at 7:36 AM, Marko Rodriguez  wrote:
> 
> Hello,
> 
> I have been working on TINKERPOP-1278 for a couple of weeks now and here is 
> where my thoughts are going.
> 
> First, a review of the concepts.
> 
>   1. Apache TinkerPop is a JVM-based graph computing framework.
>   2. Gremlin can be embedded/represented in any programming language that 
> supports function composition and function nesting.
>   - Every programming language supports these two constructs.
>   3. There are two ways in which XXX language can work with Apache 
> TinkerPop.
>   a.) XXXScriptEngine can directly use TinkerPop classes.
>   b.) XXX “mocks” of TinkerPop’s Traversal and RemoteConnection 
> in the respective language.
>   4. The language that is representing/hosting Gremlin is called the 
> “source language.”
>   5. The language that the Gremlin traversal will ultimately be executed 
> on in the JVM is called the “target language.”
>   6. It is the responsibility of a Translator to translate the source 
> language into the target language.
>   
> https://github.com/apache/tinkerpop/blob/TINKERPOP-1278/gremlin-core/src/main/java/org/apache/tinkerpop/gremlin/process/traversal/util/Translator.java
>  
> 
>  
>   - getAlias() is function naming.
>   - addStep(), addSpawnStep(), addSource() is function 
> composition.
>   - getAnonymousTraversalTranslator() is function nesting.
>   - getSourceLanguage() and getTargetLanguage() is 
> translator metadata.
>   7. It is possible/reasonable for both source and target languages to be 
> on the JVM.
>   - For example, Gremlin-Java translating to Gremlin-Groovy so it 
> can avoid the complications of serialization and support remote lambda 
> execution.
>   
> https://github.com/apache/tinkerpop/blob/TINKERPOP-1278/gremlin-groovy/src/main/java/org/apache/tinkerpop/gremlin/groovy/GroovyTranslator.java#L58-L66
>  
> 
> 
> From this foundation, we should work towards the following:
> 
>   1. bin/gremlin.sh —language gremlin-python
>   - this will load up a GremlinConsole where a 
> GremlinJythonScriptEngine is used to read and return results.
>   - same gremlin> and ==> look-and-feel, but now its Python, not 
> Groovy that is the scripting language.
>   - In this way, Python people can work with TinkerPop and NEVER 
> leave Python.
>   2. Moving forward, we then have gremlin-jruby and respective 
> GremlinJRubyScriptEngine.
>   - In this way, Ruby people can work with TinkerPop and NEVER 
> leave Ruby.
>   3. Unlike Groovy, Python and Ruby have representations outside of the 
> JVM and thus, need VM agnostic code (i.e. they can’t just “new 
> GraphTraversal”).
>   - PythonGraphTraversal (which is NOT just GraphTraversal used 
> by Gremlin-Jython on the JVM).
>   
> https://github.com/apache/tinkerpop/blob/TINKERPOP-1278/gremlin-variant/src/main/jython/gremlin_python/gremlin_python.py
>  
> 
>   - It is simple to auto generate XXX language 
> “mocks” using reflection.
>   
> https://github.com/apache/tinkerpop/blob/TINKERPOP-1278/gremlin-variant/src/main/groovy/org/apache/tinkerpop/gremlin/python/GremlinPythonGenerator.groovy
>  
> 

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

[Marko Rodriguez]

Hello,

I have been working on TINKERPOP-1278 for a couple of weeks now and here is 
where my thoughts are going.

First, a review of the concepts.

1. Apache TinkerPop is a JVM-based graph computing framework.
2. Gremlin can be embedded/represented in any programming language that 
supports function composition and function nesting.
- Every programming language supports these two constructs.
3. There are two ways in which XXX language can work with Apache 
TinkerPop.
a.) XXXScriptEngine can directly use TinkerPop classes.
b.) XXX “mocks” of TinkerPop’s Traversal and RemoteConnection 
in the respective language.
4. The language that is representing/hosting Gremlin is called the 
“source language.”
5. The language that the Gremlin traversal will ultimately be executed 
on in the JVM is called the “target language.”
6. It is the responsibility of a Translator to translate the source 
language into the target language.

https://github.com/apache/tinkerpop/blob/TINKERPOP-1278/gremlin-core/src/main/java/org/apache/tinkerpop/gremlin/process/traversal/util/Translator.java
 

 
- getAlias() is function naming.
- addStep(), addSpawnStep(), addSource() is function 
composition.
- getAnonymousTraversalTranslator() is function nesting.
- getSourceLanguage() and getTargetLanguage() is 
translator metadata.
7. It is possible/reasonable for both source and target languages to be 
on the JVM.
- For example, Gremlin-Java translating to Gremlin-Groovy so it 
can avoid the complications of serialization and support remote lambda 
execution.

https://github.com/apache/tinkerpop/blob/TINKERPOP-1278/gremlin-groovy/src/main/java/org/apache/tinkerpop/gremlin/groovy/GroovyTranslator.java#L58-L66
 


From this foundation, we should work towards the following:

1. bin/gremlin.sh —language gremlin-python
- this will load up a GremlinConsole where a 
GremlinJythonScriptEngine is used to read and return results.
- same gremlin> and ==> look-and-feel, but now its Python, not 
Groovy that is the scripting language.
- In this way, Python people can work with TinkerPop and NEVER 
leave Python.
2. Moving forward, we then have gremlin-jruby and respective 
GremlinJRubyScriptEngine.
- In this way, Ruby people can work with TinkerPop and NEVER 
leave Ruby.
3. Unlike Groovy, Python and Ruby have representations outside of the 
JVM and thus, need VM agnostic code (i.e. they can’t just “new GraphTraversal”).
- PythonGraphTraversal (which is NOT just GraphTraversal used 
by Gremlin-Jython on the JVM).

https://github.com/apache/tinkerpop/blob/TINKERPOP-1278/gremlin-variant/src/main/jython/gremlin_python/gremlin_python.py
 

- It is simple to auto generate XXX language 
“mocks” using reflection.

https://github.com/apache/tinkerpop/blob/TINKERPOP-1278/gremlin-variant/src/main/groovy/org/apache/tinkerpop/gremlin/python/GremlinPythonGenerator.groovy
 

- Translators allow for the translation of XXX language 
traversals to YYY language traversals on the JVM for execution by TinkerPop.

https://github.com/apache/tinkerpop/blob/TINKERPOP-1278/gremlin-variant/src/main/jython/gremlin_python/groovy_translator.py
 

When GremlinJythonScriptEngine exists, we should have a 
JythonTranslator as it will natively support lambdas.
- gremlin_driver, gremlin_rest_driver, etc. which are the 
Python specific replications of the same classes used in JVM TinkerPop.

https://github.com/apache/tinkerpop/blob/TINKERPOP-1278/gremlin-variant/src/main/jython/gremlin_driver/gremlin_driver.py
 


https://github.com/apache/tinkerpop/blob/TINKERPOP-1278/gremlin-variant/src/main/

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

[Marko Rodriguez]

Yea — submodules is a good idea.

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

Marko.

http://markorodriguez.com



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

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

[Stephen Mallette]

I would think that we want individual plugins for each variant.

This does lead me back to an earlier discussion about gremlin-variant
packaging. We didn't want to do

gremlin-variant
+-- gremlin-variant-python
+-- gremlin-variant-js,
+-- 
+-- gremlin-variant-X

so with gremlin-variant users are going to just get everything when they
depend on it. To my knowledge, we are only kinda viewing this from a python
perspective atm and haven't really researched all the languages we support,
but I sense that ultimately as we add more GLVs we're going to end up with
a really messy pom.xml for gremlin-variant with the potential for conflict
as we try to make maven deal with packaging issues for all those disparate
languages. Again, hard to say how much trouble this will eventually be, but
might be worth noodling on again in case anyone has any new thoughts on the
matter.



On Thu, Jun 16, 2016 at 12:10 PM, Daniel Kuppitz  wrote:

> The last few days I've been working on a Gremlin Python code executor for
> the TinkerPop docs. What I noticed was that we can't simply execute Gremlin
> Python code in our Gremlin Groovy console, simply because the console has
> no dependency to the gremlin-variants projects.
>
> That was unfortunate for the docs pre-processor, but what about the normal
> user? Do we need to have those language variants always available or would
> it be sufficient to have a Gremlin-Xyz plugin (where Xyz could be Python,
> Ruby, etc.)?
>
> I've added the "missing" dependency for now to get the docs pre-processor
> extension done, but I think we should remove that dependency again and
> create a plugin instead, before the branch gets merged into master.
>
> Cheers,
> Daniel
>

[DISCUSS] Gremlin Language variants in the Gremlin console

[Daniel Kuppitz]

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

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

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

Cheers,
Daniel