tinkerpop-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "ASF GitHub Bot (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (TINKERPOP-1278) Implement Gremlin-Python and general purpose language variant test infrastructure
Date Fri, 08 Jul 2016 14:11:11 GMT

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

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

GitHub user leifurhauks opened a pull request:

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

    TINKERPOP-1278 : Removed long literal 'L' suffix

    The 'L' suffix on numeric literals is a syntax error in python3. As far
    as I can tell, the suffix on the literal in this expression in
    JythonTranslator isn't necessary on python2, so removing it restores 2/3
    compatibility.

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

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

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

    https://github.com/apache/tinkerpop/pull/359.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 #359
    
----
commit 62af276e77e95ca21ac572a2f8a6fa8804489773
Author: Leifur Halldor Asgeirsson <lasgeirsson@zerofail.com>
Date:   2016-07-08T14:03:54Z

    TINKERPOP-1278 : Removed long literal 'L' suffix
    
    The 'L' suffix on numeric literals is a syntax error in python3. As far
    as I can tell, the suffix on the literal in this expression in
    JythonTranslator isn't necessary on python2, so removing it restores 2/3
    compatibility.

----


> Implement Gremlin-Python and general purpose language variant test infrastructure
> ---------------------------------------------------------------------------------
>
>                 Key: TINKERPOP-1278
>                 URL: https://issues.apache.org/jira/browse/TINKERPOP-1278
>             Project: TinkerPop
>          Issue Type: Improvement
>          Components: language-variant
>    Affects Versions: 3.2.0-incubating
>            Reporter: Marko A. Rodriguez
>            Assignee: Marko A. Rodriguez
>
> As discussed on dev@...
> Apache TinkerPop should provide, out-of-the-box, at least 3 Gremlin language variants.
It would be cool if these were:
> * Python (Mark Henderson)
> * PHP ([~PommeVerte])
> * Ruby (?[~okram])
> I think each of these should be generated using the reflection-model presented in http://tinkerpop.apache.org/docs/3.2.1-SNAPSHOT/tutorials/gremlin-language-variants/.
Moreover, on every {{mvn clean install}}, the code for these variants is generated.
> Given the desire to separate language variants from language drivers, I think that a
language driver for each variant above should be "plugable." Moreover, we should provide one
driver implementation for each -- simple GremlinServer REST.
> {code}
> gremlin-variants/
>   gremlin-ruby/
>     gremlin_ruby.rb
>     gremlin_ruby_rest_driver.rb
>   gremlin-php/
>     Gremlin_PHP.php
>     Gremlin_PHP_REST_Driver.php
>   gremlin-python/
>     gremlin-python.py
>     gremlin-python-rest-driver.py
> {code}
> Next, each variant implementation should be testable. This is PAINFUL if we have to implement
each {{g_V_out_repeatXasXaXX}} test case in {{ProcessXXXSuite}}. Perhaps some RegEx transducer
magic could be used to convert all those tests from Gremlin-Java to the respective host language?
However, even if we do that, we still have the problem of how to test the returned results.

> I think what we should test the returned results using the JVM. For instance, JRuby,
Jython, JPHP (does it exist?). If we do this, we will save ourselves a massive headache. All
we have to do is create a {{GraphProvider}} that uses {{TinkerGraph}} and whose {{TraversalSource}}
is some sort of wrapper around reflection-generated Ruby (e.g.).
> {code}
> g.V.out_e("knows") // returns a Ruby iterator
> {code}
> That Ruby iterator should be converted to a Java iterator and then the {{ProcessXXXSuite}}
can verify the results.
> With this, most everything is reflectively constructed.
> {code}
> gremlin_ruby.rb             // generated via Java reflection
> gremlin_ruby_rest_driver.rb // manually coded
> match_test.rb               // generated via RegEx transducer
> has_test.rb                 // generated via RegEx transducer
> ...
> RubyGraphProvider.java        // manually coded
> RubyProcessStandardSuite.java // manually coded
> RubyProcessComputerSuite.java // manually coded
> {code}
> Thus, the testing data flow would be:
> {code}
> MatchTest.Traversals.java --transducer-> match_test.rb
> match-test.rb --REST--> GremlinServer
> GremlinServer --GraphSON-->match-test.rb
> GraphSON --JRuby/GraphSONReader-->Java objects
> Java objects --JRuby-->MatchTest.java 
> {code}



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

Mime
View raw message