[jira] [Commented] (TINKERPOP-1389) Support Spark 2.0.0

[Chen Xin Yu (JIRA)]

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

Chen Xin Yu commented on TINKERPOP-1389:


The patch I submitted before is only fixed the issues for compiling. There are 
hundreds test cases failed as TINKERPOP-1426

> Support Spark 2.0.0
> ---
>
> Key: TINKERPOP-1389
> URL: https://issues.apache.org/jira/browse/TINKERPOP-1389
> Project: TinkerPop
>  Issue Type: Improvement
>  Components: hadoop
>Affects Versions: 3.2.1
>Reporter: Chen Xin Yu
> Fix For: 3.3.0
>
> Attachments: TINKERPOP-1389.patch
>
>
> Spark 2.0.0 was released:
> http://spark.apache.org/news/spark-2-0-0-released.html
> There are lots of improvement and changes compared to 1.6.1, we should better 
> bump to it for TinkerPop.



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

[jira] [Updated] (TINKERPOP-1426) GryoSerializer should implement Java serialization interface

[Chen Xin Yu (JIRA)]

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

Chen Xin Yu updated TINKERPOP-1426:
---
Description: 
There is description for Serializer in spark:

 * Implementations of this trait should implement:
 *
 * 1. a zero-arg constructor or a constructor that accepts a 
[[org.apache.spark.SparkConf]]
 * as parameter. If both constructors are defined, the latter takes precedence.
 *
 * 2. Java serialization interface.

Class GryoSerializer in Tinkerepop extends Serializer, but does not implement 
java.io.Serializable. 
It works well before Spark 2.0. But with Spark 2.0, it changed by SPARK-13926 
for Dependency,scala. 
Gyro and all its fields must implement Java serialisation interface, otherwise 
hundreds of test cases are failed as:

Caused by: org.apache.spark.SparkException: Job aborted due to stage failure: 
Task not serializable: java.io.NotSerializableException: 
org.apache.tinkerpop.gremlin.spark.structure.io.gryo.GryoSerializer
Serialization stack:
- object not serializable (class: 
org.apache.tinkerpop.gremlin.spark.structure.io.gryo.GryoSerializer, value: 
org.apache.tinkerpop.gremlin.spark.structure.io.gryo.GryoSerializer@1b12ec8e)
- field (class: org.apache.spark.ShuffleDependency, name: serializer, 
type: class org.apache.spark.serializer.Serializer)
- object (class org.apache.spark.ShuffleDependency, 
org.apache.spark.ShuffleDependency@7a4f876a)
- field (class: scala.Tuple2, name: _2, type: class java.lang.Object)
- object (class scala.Tuple2, (MapPartitionsRDD[1] at mapToPair at 
InputFormatRDD.java:46,org.apache.spark.ShuffleDependency@7a4f876a))

  was:
In spark description for Serializer, there is:
 * Implementations of this trait should implement:
 *
 * 1. a zero-arg constructor or a constructor that accepts a 
[[org.apache.spark.SparkConf]]
 * as parameter. If both constructors are defined, the latter takes precedence.
 *
 * 2. Java serialization interface.

Tinkerepop Class GryoSerializer extends Serializer, but does not implement 
serialisation. It works well before Spark 2.0. But with Spark 2.0, with the 
change for SPARK-13926 for Dependency,scala. Gyro must implement Java 
serialisation interface, otherwise hundreds of test cases are failed as:
Caused by: org.apache.spark.SparkException: Job aborted due to stage failure: 
Task not serializable: java.io.NotSerializableException: 
org.apache.tinkerpop.gremlin.spark.structure.io.gryo.GryoSerializer
Serialization stack:
- object not serializable (class: 
org.apache.tinkerpop.gremlin.spark.structure.io.gryo.GryoSerializer, value: 
org.apache.tinkerpop.gremlin.spark.structure.io.gryo.GryoSerializer@1b12ec8e)
- field (class: org.apache.spark.ShuffleDependency, name: serializer, 
type: class org.apache.spark.serializer.Serializer)
- object (class org.apache.spark.ShuffleDependency, 
org.apache.spark.ShuffleDependency@7a4f876a)
- field (class: scala.Tuple2, name: _2, type: class java.lang.Object)
- object (class scala.Tuple2, (MapPartitionsRDD[1] at mapToPair at 
InputFormatRDD.java:46,org.apache.spark.ShuffleDependency@7a4f876a))


> GryoSerializer should implement Java serialization interface
> 
>
> Key: TINKERPOP-1426
> URL: https://issues.apache.org/jira/browse/TINKERPOP-1426
> Project: TinkerPop
>  Issue Type: Bug
>  Components: io
>Affects Versions: 3.2.1
>Reporter: Chen Xin Yu
>
> There is description for Serializer in spark:
>  * Implementations of this trait should implement:
>  *
>  * 1. a zero-arg constructor or a constructor that accepts a 
> [[org.apache.spark.SparkConf]]
>  * as parameter. If both constructors are defined, the latter takes 
> precedence.
>  *
>  * 2. Java serialization interface.
> Class GryoSerializer in Tinkerepop extends Serializer, but does not implement 
> java.io.Serializable. 
> It works well before Spark 2.0. But with Spark 2.0, it changed by SPARK-13926 
> for Dependency,scala. 
> Gyro and all its fields must implement Java serialisation interface, 
> otherwise hundreds of test cases are failed as:
> Caused by: org.apache.spark.SparkException: Job aborted due to stage failure: 
> Task not serializable: java.io.NotSerializableException: 
> org.apache.tinkerpop.gremlin.spark.structure.io.gryo.GryoSerializer
> Serialization stack:
>   - object not serializable (class: 
> org.apache.tinkerpop.gremlin.spark.structure.io.gryo.GryoSerializer, value: 
> org.apache.tinkerpop.gremlin.spark.structure.io.gryo.GryoSerializer@1b12ec8e)
>   - field (class: org.apache.spark.ShuffleDependency, name: serializer, 
> type: class org.apache.spark.serializer.Serializer)
>   - object (class org.apache.spark.ShuffleDependency, 
> org.apache.spark.ShuffleDependency@7a4f876a)
>   - 

[jira] [Created] (TINKERPOP-1426) GryoSerializer should implement Java serialization interface

[Chen Xin Yu (JIRA)]

Chen Xin Yu created TINKERPOP-1426:
--

 Summary: GryoSerializer should implement Java serialization 
interface
 Key: TINKERPOP-1426
 URL: https://issues.apache.org/jira/browse/TINKERPOP-1426
 Project: TinkerPop
  Issue Type: Bug
  Components: io
Affects Versions: 3.2.1
Reporter: Chen Xin Yu


In spark description for Serializer, there is:
 * Implementations of this trait should implement:
 *
 * 1. a zero-arg constructor or a constructor that accepts a 
[[org.apache.spark.SparkConf]]
 * as parameter. If both constructors are defined, the latter takes precedence.
 *
 * 2. Java serialization interface.

Tinkerepop Class GryoSerializer extends Serializer, but does not implement 
serialisation. It works well before Spark 2.0. But with Spark 2.0, with the 
change for SPARK-13926 for Dependency,scala. Gyro must implement Java 
serialisation interface, otherwise hundreds of test cases are failed as:
Caused by: org.apache.spark.SparkException: Job aborted due to stage failure: 
Task not serializable: java.io.NotSerializableException: 
org.apache.tinkerpop.gremlin.spark.structure.io.gryo.GryoSerializer
Serialization stack:
- object not serializable (class: 
org.apache.tinkerpop.gremlin.spark.structure.io.gryo.GryoSerializer, value: 
org.apache.tinkerpop.gremlin.spark.structure.io.gryo.GryoSerializer@1b12ec8e)
- field (class: org.apache.spark.ShuffleDependency, name: serializer, 
type: class org.apache.spark.serializer.Serializer)
- object (class org.apache.spark.ShuffleDependency, 
org.apache.spark.ShuffleDependency@7a4f876a)
- field (class: scala.Tuple2, name: _2, type: class java.lang.Object)
- object (class scala.Tuple2, (MapPartitionsRDD[1] at mapToPair at 
InputFormatRDD.java:46,org.apache.spark.ShuffleDependency@7a4f876a))



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

Re: New Committer: David Brown

[David Brown]

Thanks everyone! I am really looking forward to contributing.

On Wed, Aug 31, 2016 at 1:09 PM, Kelvin Lawrence
 wrote:
> Congratulations David - I see a lot of folks very excited about the prospect
> of combining Python and Gremlin!
>
> Kelvin
>
>
> On Wednesday, August 31, 2016 at 10:10:53 AM UTC-5, Stephen Mallette wrote:
>>
>> The Project Management Committee (PMC) for Apache TinkerPop has asked
>> David Brown to become a committer and we are pleased to announce that he has
>> accepted.
>>
>> If you're using TinkerPop with Python today, it's likely because of David
>> Brown's work. He was the first person to implement the Gremlin Server
>> protocol for TinkerPop 3.x outside of my initial implementation. He built
>> many other Python related libraries for TinkerPop since then, provided
>> testing during releases and added a good bit of input on Gremlin Server
>> along the way.
>>
>> Being a committer enables easier contribution to the project since there
>> is no need to work via the patch submission process. This should enable
>> better productivity.
>>
>>
>



-- 
David M. Brown
R.A. CulturePlex Lab, Western University

[DISCUSS] README for PyPi

[Stephen Mallette]

I've taken a swipe at the README file that gets parsed into PyPi for the
text description of the artifacts uploaded there. You can see what it looks
like deployed to the PyPi test site at this point:

https://testpypi.python.org/pypi/gremlinpython

The source file for this is here:

https://github.com/apache/tinkerpop/blob/01398b0444d5eb15bf50160cccf0001c73c803b6/gremlin-python/src/main/jython/README

It's in RST format - blah - as that's the only formatted text PyPi will
parse. Python ecosystem is so weird. I hope i run into another sourceforge
project hosting python stuff today - that will be sweet.

If there are any suggested updates (an image of Gremlin might be nice - but
i'm done fussing with RST for the day), please yell.

Re: New PMC: Jason Plurad

[Ted Wilmes]

Welcome aboard Jason!

--Ted

On Wed, Aug 31, 2016 at 12:20 PM, Alaa Mahmoud  wrote:

> Congratulations Jason!
>
> Alaa
>
> On Wed, Aug 31, 2016 at 12:30 PM, Marko Rodriguez 
> wrote:
>
> > Hello,
> >
> > Jason Plurad of mailing list support, Gremlin Server/Console development,
> > and IBM Graph fame has accepted a position aboard the illustriously
> > enlightened Apache TinkerPop PMC. Jason has been with TinkerPop for over
> a
> > year and has consistently produced beyond the whims of the moment and as
> > such, is able to help guide the future of The TinkerPop.
> >
> > With that, welcome Jason to the board — please don’t put your feet up on
> > the table and for god's sake, don’t forget your white wig when attending
> > the exclusive PMC meetings.
> >
> > http://www.ontrack-media.net/ss8/ss8m4l4image3.jpg <
> > http://www.ontrack-media.net/ss8/ss8m4l4image3.jpg>
> >
> > Marko.
> >
> > http://markorodriguez.com
> >
> >
> >
> >
>

Re: Code Freeze 3.1.4/3.2.2

[Ted Wilmes]

The 3.1.4-SNAPSHOT docs have been published to: http://tinkerpop.apache.
org/docs/3.1.4-SNAPSHOT/

Changelog bugs and improvements have also been updated with where we stand
at this point with 3.1.4:
https://github.com/apache/tinkerpop/blob/tp31/CHANGELOG.asciidoc

Thanks,
Ted




On Sun, Aug 28, 2016 at 7:52 AM, Ted Wilmes  wrote:

> Hello,
> The 3.1.4-SNAPSHOT has been published.  As Stephen mentioned, we do not
> expect any
> non-doc changes/additions to tp31 but let me know if something comes up.
> I'll be reviewing
> the docs and publishing a doc snapshot later this week.
>
> Thanks,
> Ted
>
> On Sat, Aug 27, 2016 at 5:15 AM, Stephen Mallette 
> wrote:
>
>> Code freeze begins today. Some minor changes to expect on master:
>>
>> + We have one lingering PR that needs to be merged once it is rebased:
>> https://github.com/apache/tinkerpop/pull/385
>> + I suspect we will see more tests on gremlin-python as well as tweaks to
>> the build process
>> + We may see one more serializers added to GraphSON 2.0 -
>> TraversalExplanation
>> + More docs as usual
>>
>> Recall, that gremlin-python and GraphSON 2.0 will be "experimental" so I
>> don't think we should be too concerned about late changes on that stuff at
>> this point. So - nothing major coming down the pike and as far as I know
>> there shouldn't be any change on tp31 branch aside from some added
>> documentation.
>>
>> Providers should be free to test things out in their implementations. I've
>> published the 3.2.2-SNAPSHOT to Apache Snapshots repo. Note that Ted is
>> going to be handling the 3.1.4 release - he will publish the
>> 3.1.4-SNAPSHOT
>> sometime soon (thanks for helping out with that Ted - it will be
>> interesting to have two voices taking us through code freeze week into
>> release)..
>>
>> As usual, please stay tuned to this thread for updates as we head to
>> release. Thanks!
>>
>
>

[GitHub] tinkerpop pull request #393: Add pytest-runner in order to properly build gr...

[asfgit]

Github user asfgit closed the pull request at:

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


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

Re: New Committer: David Brown

[Kelvin Lawrence]

Congratulations David - I see a lot of folks very excited about the 
prospect of combining Python and Gremlin!

Kelvin

On Wednesday, August 31, 2016 at 10:10:53 AM UTC-5, Stephen Mallette wrote:
>
> The Project Management Committee (PMC) for Apache TinkerPop has asked 
> David Brown to become a committer and we are pleased to announce that he 
> has accepted.
>
> If you're using TinkerPop with Python today, it's likely because of David 
> Brown's work. He was the first person to implement the Gremlin Server 
> protocol for TinkerPop 3.x outside of my initial implementation. He built 
> many other Python related libraries for TinkerPop since then, provided 
> testing during releases and added a good bit of input on Gremlin Server 
> along the way.
>
> Being a committer enables easier contribution to the project since there 
> is no need to work via the patch submission process. This should enable 
> better productivity.
>
>
>

Re: New PMC: Jason Plurad

[Kelvin Lawrence]

Awesome news - congrats Jason and the whole team for the continued success 
of Tinkerpop! (I now have the visual of Jason in a wig stuck in my head) :-)

Kelvin

On Wednesday, August 31, 2016 at 11:30:10 AM UTC-5, Marko A. Rodriguez 
wrote:
>
> Hello,
>
> Jason Plurad of mailing list support, Gremlin Server/Console development, 
> and IBM Graph fame has accepted a position aboard the illustriously 
> enlightened Apache TinkerPop PMC. Jason has been with TinkerPop for over a 
> year and has consistently produced beyond the whims of the moment and as 
> such, is able to help guide the future of The TinkerPop.
>
> With that, welcome Jason to the board — please don’t put your feet up on 
> the table and for god's sake, don’t forget your white wig when attending 
> the exclusive PMC meetings.
>
> http://www.ontrack-media.net/ss8/ss8m4l4image3.jpg
>
> Marko.
>
> http://markorodriguez.com
>
>
>
>

[jira] [Assigned] (TINKERPOP-1425) Use trailing underscores in gremlin-python

[Marko A. Rodriguez (JIRA)]

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

Marko A. Rodriguez reassigned TINKERPOP-1425:
-

Assignee: Marko A. Rodriguez  (was: David M. Brown)

> Use trailing underscores in gremlin-python
> --
>
> Key: TINKERPOP-1425
> URL: https://issues.apache.org/jira/browse/TINKERPOP-1425
> Project: TinkerPop
>  Issue Type: Improvement
>  Components: language-variant
>Affects Versions: 3.2.2
>Reporter: stephen mallette
>Assignee: Marko A. Rodriguez
> Fix For: 3.2.2
>
>
> As per discussion on TINKERPOP-1278 it seems more pythonesque to use trailing 
> underscores rather than leading.



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

New PMC: Jason Plurad

[Marko Rodriguez]

Hello,

Jason Plurad of mailing list support, Gremlin Server/Console development, and 
IBM Graph fame has accepted a position aboard the illustriously enlightened 
Apache TinkerPop PMC. Jason has been with TinkerPop for over a year and has 
consistently produced beyond the whims of the moment and as such, is able to 
help guide the future of The TinkerPop.

With that, welcome Jason to the board — please don’t put your feet up on the 
table and for god's sake, don’t forget your white wig when attending the 
exclusive PMC meetings.

http://www.ontrack-media.net/ss8/ss8m4l4image3.jpg 


Marko.

http://markorodriguez.com

[jira] [Commented] (TINKERPOP-1278) Implement Gremlin-Python and general purpose language variant test infrastructure

[David M. Brown (JIRA)]

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

David M. Brown commented on TINKERPOP-1278:
---

+1 Leif I agree.

> 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
> Fix For: 3.2.2
>
>
> 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)

[jira] [Commented] (TINKERPOP-1278) Implement Gremlin-Python and general purpose language variant test infrastructure

[David M. Brown (JIRA)]

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

David M. Brown commented on TINKERPOP-1278:
---

Adam Holmberg - Regarding naming, while methods typically have lowercase names 
separated with underscores, PEP 8 does suggest that "mixedCase is allowed only 
in contexts where that's already the prevailing style". While this typically 
refers to backwards compatibility, you see mixed case in libraries that provide 
bridges to other languages...the example that comes to mind is PyObjC. I wonder 
if this is an example where using mixed case is acceptable in order to give 
gremlin-python the same "feel" as gremlin...thoughts?

> 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
> Fix For: 3.2.2
>
>
> 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)

[DISCUSS] Build on Windows

[Stephen Mallette]

We have this issue open:

https://issues.apache.org/jira/browse/TINKERPOP-1179

which is about AppVeyor and running a windows build. It hasn't moved much
recently and Apache Infra (i assume) has disabled the AppVeyor integration
(which in my book is fine b/c most of the time it ended with a red "X" on
pull requests). So, the question is, do we care about AppVeyor and
supporting a Windows build?

For me, i'd say "no" on both (in which case i'd just close this ticket).
Some reasons:

1. I think that there aren't enough core developers working on Windows to
warrant the added effort of trying to maintain a Windows build.
2. The complexity of the build will increase with each GLV and it will be
hard enough trying to keep that sane without Windows.
3. Doc generation system is bound to shell environments

Couldn't Windows users fall back to docker for their builds? Seems like it
would be easier to maintain a docker/build.bat than it would to try to make
everything else we have work on windows? thoughts?

Re: [jira] [Commented] (TINKERPOP-1278) Implement Gremlin-Python and general purpose language variant test infrastructure

[Stephen Mallette]

dave, i don't think adam is on this list. you probably need to reply in
JIRA. i do think however, that the issue is open to discussion on this list
if others would like to comment. We do intend to release gremlin-python as
"experimental" with the intent of gathering feedback for a final release on
3.3.0.

On Tue, Aug 30, 2016 at 2:54 PM, David Brown  wrote:

> @aholmber - Regarding naming, while methods typically have lowercase
> names separated with underscores, PEP 8 does suggest that "mixedCase
> is allowed only in contexts where that's already the prevailing
> style". While this typically refers to backwards compatibility, you
> see mixed case in libraries that provide bridges to other
> languages...the example that comes to mind is PyObjC. I wonder if this
> is an example where using mixed case is acceptable in order to give
> gremlin-python the same "feel" as gremlin...thoughts?
>
> On Tue, Aug 30, 2016 at 2:39 PM, stephen mallette (JIRA)
>  wrote:
> >
> > [ https://issues.apache.org/jira/browse/TINKERPOP-1278?
> page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&
> focusedCommentId=15449778#comment-15449778 ]
> >
> > stephen mallette commented on TINKERPOP-1278:
> > -
> >
> > [~stamhankar999] thanks for your thoughts on the testing aspects of
> things. i think we have some work to do before we can call the testing
> model completely settled for all GLVs. I suspect some changes will occur. I
> think we need a good mix of native tests as well as those that can be
> executed via the process suites. We will try to come to a full
> understanding of that model for 3.3.x.
> >
> > [~aholmber] i remember your commit comment. i think that happened when
> [~okram] was away on vacation. since he wrote the code generation stuff for
> that, perhaps he'd be best to have a look and address your concerns.
> >
> >> 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
> >> Fix For: 3.2.2
> >>
> >>
> >> 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
> >>