date:20160607

Re: [DISCUSS] Amend provider listing policies

2016-06-07 Thread Stephen Mallette

I just updated the policy page to include the "version compatibility" note:

http://tinkerpop.apache.org/policy.html

If you are a provider it would be most helpful if you could update your
project accordingly. I do think that for projects using maven that are open
source, the pom.xml is a sufficient expression of "version compatibility".

On Tue, May 31, 2016 at 9:27 AM, Stephen Mallette 
wrote:

> If i maintained such a project i would certainly have that kind of
> information. From the TinkerPop perspective however,i think it would be
> good to keep the bar "low" and not force more on providers than a basic
> minimum with respect to this issue.
>
> On Tue, May 31, 2016 at 9:12 AM, Dylan Millikin 
> wrote:
>
>> Sounds good. For drivers maybe a "tested against" line would be nice.
>>
>> On Tue, May 31, 2016 at 7:07 AM, Stephen Mallette 
>> wrote:
>>
>> > This thread made me start looking at the libraries we have on our home
>> > page:
>> >
>> > https://groups.google.com/d/msg/gremlin-users/R9-lFCX_2G0/79GAFOH9DgAJ
>> >
>> > While it was easy to figure out the version of TinkerPop that a provider
>> > used if there was a pom.xml involved it was less easy to figure out the
>> > version for other libraries. I think that it would be good if all
>> libraries
>> > listed something that expressed their version compatibility with
>> TinkerPop
>> > as this would reduce confusion with users. I think this is especially
>> true
>> > of the drivers that once complete don't need to see a lot of change from
>> > one release to the next as Gremlin Server's protocol doesn't change from
>> > release to release. That can lead to a library not seeing commits for
>> > months and even though it is compliant and useful with the latest
>> TinkerPop
>> > release might be considered unmaintained to someone looking in for the
>> > first time.
>> >
>> > What does everyone think of amending our listing policy:
>> >
>> > http://tinkerpop.apache.org/policy.html
>> >
>> > to include some requirement like that. Perhaps we don't need another
>> bullet
>> > for this - maybe we could just change the wording of:
>> >
>> > + The project must have some/significant documentation and that
>> > documentation must make explicit its usage of Apache TinkerPop.
>> >
>> > to be something like:
>> >
>> > + The project must have some/significant documentation and that
>> > documentation must make explicit its usage of Apache TinkerPop and its
>> > version compatibility requirements.
>> >
>> > good idea?
>> >
>>
>
>

[jira] [Commented] (TINKERPOP-1317) IoGraphTest throws error: URI is not hierarchical

2016-06-07 Thread ASF GitHub Bot (JIRA)


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

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

Github user spmallette commented on the issue:

https://github.com/apache/incubator-tinkerpop/pull/328
  
@pluradj assuming @twilmes is voting +1 here pending the spelling fix, you 
will have your positive VOTE if you include a +1 yourself.


> IoGraphTest throws error: URI is not hierarchical
> -
>
> Key: TINKERPOP-1317
> URL: https://issues.apache.org/jira/browse/TINKERPOP-1317
> Project: TinkerPop
>  Issue Type: Bug
>  Components: test-suite
>Affects Versions: 3.2.0-incubating, 3.1.2-incubating
>Reporter: Jason Plurad
>Assignee: Jason Plurad
>Priority: Minor
>
> Via https://groups.google.com/d/msg/gremlin-users/aap3pxZtGyU/t-eOC6ZyAAAJ
> These methods will fail for graph providers that are trying to implement the 
> test suite:
> * {{IoGraphTest.shouldReadWriteModernToFileWithHelpers()}}
> * {{IoGraphTest.shouldReadWriteClassicToFileWithHelpers()}}
> Example stack trace:
> {noformat}
> shouldReadWriteModernToFileWithHelpers[gryo](org.apache.tinkerpop.gremlin.structure.io.IoGraphTest)
>   Time elapsed: 0.004 sec  <<< ERROR!
> java.lang.RuntimeException: Unable to computePath for class 
> org.apache.tinkerpop.gremlin.structure.io.IoGraphTest
>   at 
> org.apache.tinkerpop.gremlin.TestHelper.computePath(TestHelper.java:117)
>   at 
> org.apache.tinkerpop.gremlin.TestHelper.getRootOfBuildDirectory(TestHelper.java:105)
>   at 
> org.apache.tinkerpop.gremlin.TestHelper.makeTestDataPath(TestHelper.java:70)
>   at 
> org.apache.tinkerpop.gremlin.TestHelper.generateTempFile(TestHelper.java:127)
>   at 
> org.apache.tinkerpop.gremlin.structure.io.IoGraphTest.shouldReadWriteModernToFileWithHelpers(IoGraphTest.java:164)
>   at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
>   at 
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
>   at 
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
>   at java.lang.reflect.Method.invoke(Method.java:497)
>   at 
> org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:50)
>   at 
> org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:12)
>   at 
> org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:47)
>   at 
> org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:17)
>   at 
> org.junit.internal.runners.statements.RunBefores.evaluate(RunBefores.java:26)
>   at 
> org.junit.internal.runners.statements.RunAfters.evaluate(RunAfters.java:27)
>   at org.junit.rules.TestWatcher$1.evaluate(TestWatcher.java:55)
>   at org.junit.rules.RunRules.evaluate(RunRules.java:20)
>   at org.junit.runners.ParentRunner.runLeaf(ParentRunner.java:325)
>   at 
> org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:78)
>   at 
> org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:57)
>   at org.junit.runners.ParentRunner$3.run(ParentRunner.java:290)
>   at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:71)
>   at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:288)
>   at org.junit.runners.ParentRunner.access$000(ParentRunner.java:58)
>   at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:268)
>   at org.junit.runners.ParentRunner.run(ParentRunner.java:363)
>   at org.junit.runners.Suite.runChild(Suite.java:128)
>   at org.junit.runners.Suite.runChild(Suite.java:27)
>   at org.junit.runners.ParentRunner$3.run(ParentRunner.java:290)
>   at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:71)
>   at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:288)
>   at org.junit.runners.ParentRunner.access$000(ParentRunner.java:58)
>   at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:268)
>   at org.junit.runners.ParentRunner.run(ParentRunner.java:363)
>   at org.junit.runners.Suite.runChild(Suite.java:128)
>   at 
> org.apache.tinkerpop.gremlin.AbstractGremlinSuite.runChild(AbstractGremlinSuite.java:212)
>   at 
> org.apache.tinkerpop.gremlin.AbstractGremlinSuite.runChild(AbstractGremlinSuite.java:50)
>   at org.junit.runners.ParentRunner$3.run(ParentRunner.java:290)
>   at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:71)
>   at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:288)
>   at org.junit.runners.ParentRunner.access$000(ParentRunner.java:58)
>   at

[GitHub] incubator-tinkerpop issue #328: TINKERPOP-1317: use graph class as root clas...

2016-06-07 Thread spmallette

Github user spmallette commented on the issue:

https://github.com/apache/incubator-tinkerpop/pull/328
  
@pluradj assuming @twilmes is voting +1 here pending the spelling fix, you 
will have your positive VOTE if you include a +1 yourself.


---
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] incubator-tinkerpop issue #333: if there is no edge label in the GraphML fil...

2016-06-07 Thread spmallette

Github user spmallette commented on the issue:

https://github.com/apache/incubator-tinkerpop/pull/333
  
Note that your PR is failing for Travis:

https://travis-ci.org/apache/incubator-tinkerpop/builds/135940598#L6936

Any idea what's wrong?


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

Documentation deprecation warning on Github Wikis

2016-06-07 Thread Jean-Baptiste Musso

Dear devs,

I was thinking recently that we could add a deprecation warning
message on top of all former Github Wiki pages and warn visitors that
a new version of TinkerPop is available. I think this was also brought
up recently on the mailing list so I'm opening a discussion here.

I feel that some newcomers are still hitting old school TinkerPop 2
material when google'ing for graphs, Gremlin and TinkerPop. Adding a
warning message on top of old Wiki pages pointing them to the freshest
development on the Apache TinkerPop website could certainly help.

If everyone agrees, I'm volunteering to git clone the Wiki on all
repositories and edit all pages. As Stephen noted on HipChat, it's as
simple as following these steps:
https://help.github.com/articles/adding-and-editing-wiki-pages-locally/

Here's an example of such header we could add:

https://gist.github.com/jbmusso/802cf97ceb20547ba6abf0b4112ac3ee

Thoughts? Feel free to iterate. The wording could be improved.

Cheers,

Jean-Baptiste

Re: Documentation deprecation warning on Github Wikis

2016-06-07 Thread Marko Rodriguez

I think that is a good idea and I like the header.

Thanks,
Marko.

http://markorodriguez.com



> On Jun 7, 2016, at 2:05 PM, Jean-Baptiste Musso  wrote:
> 
> Dear devs,
> 
> I was thinking recently that we could add a deprecation warning
> message on top of all former Github Wiki pages and warn visitors that
> a new version of TinkerPop is available. I think this was also brought
> up recently on the mailing list so I'm opening a discussion here.
> 
> I feel that some newcomers are still hitting old school TinkerPop 2
> material when google'ing for graphs, Gremlin and TinkerPop. Adding a
> warning message on top of old Wiki pages pointing them to the freshest
> development on the Apache TinkerPop website could certainly help.
> 
> If everyone agrees, I'm volunteering to git clone the Wiki on all
> repositories and edit all pages. As Stephen noted on HipChat, it's as
> simple as following these steps:
> https://help.github.com/articles/adding-and-editing-wiki-pages-locally/
> 
> Here's an example of such header we could add:
> 
> https://gist.github.com/jbmusso/802cf97ceb20547ba6abf0b4112ac3ee
> 
> Thoughts? Feel free to iterate. The wording could be improved.
> 
> Cheers,
> 
> Jean-Baptiste

[GitHub] incubator-tinkerpop issue #333: if there is no edge label in the GraphML fil...

2016-06-07 Thread spmallette

Github user spmallette commented on the issue:

https://github.com/apache/incubator-tinkerpop/pull/333
  
Travis still seems to be having a problem. You can see the "red X" on the 
Travis job in github - just click the "Details" link next to it to see the 
problem being reported.


---
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-1318) java.lang.NoSuchMethodError: org/hamcrest/Matcher.describeMismatch

2016-06-07 Thread ASF GitHub Bot (JIRA)


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

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

Github user asfgit closed the pull request at:

https://github.com/apache/incubator-tinkerpop/pull/329


> java.lang.NoSuchMethodError: org/hamcrest/Matcher.describeMismatch
> --
>
> Key: TINKERPOP-1318
> URL: https://issues.apache.org/jira/browse/TINKERPOP-1318
> Project: TinkerPop
>  Issue Type: Bug
>  Components: test-suite
>Affects Versions: 3.2.0-incubating, 3.1.2-incubating
>Reporter: Jason Plurad
>Assignee: Jason Plurad
>Priority: Minor
>
> I don't recall specifically how to make this fail with {{gremlin-test}}, but 
> I did run into it at one point when writing a graph implementation. This blog 
> describes the issue and workaround. 
> https://tedvinke.wordpress.com/2013/12/17/mixing-junit-hamcrest-and-mockito-explaining-nosuchmethoderror/
> The error trace looks like this:
> {noformat}
> java.lang.NoSuchMethodError: 
> org.hamcrest.Matcher.describeMismatch(Ljava/lang/Object;Lorg/hamcrest/Description;)V
> {noformat}
> There is a dependency conflict created by an older version of {{hamcrest}} 
> coming out of {{mockito-all}}. The fix is to use {{mockito-core}} instead.
> I'll submit a patch for this.



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

[GitHub] incubator-tinkerpop pull request #329: TINKERPOP-1318: use mockito-core inst...

2016-06-07 Thread asfgit

Github user asfgit closed the pull request at:

https://github.com/apache/incubator-tinkerpop/pull/329


---
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] incubator-tinkerpop pull request #328: TINKERPOP-1317: use graph class as ro...

2016-06-07 Thread asfgit

Github user asfgit closed the pull request at:

https://github.com/apache/incubator-tinkerpop/pull/328


---
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] incubator-tinkerpop issue #325: TINKERPOP-1321 Introduce Kryo shim to suppor...

2016-06-07 Thread dkuppitz

Github user dkuppitz commented on the issue:

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

[jira] [Closed] (TINKERPOP-1321) Loosen coupling between TinkerPop serialization logic and shaded Kryo

2016-06-07 Thread Marko A. Rodriguez (JIRA)


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

Marko A. Rodriguez closed TINKERPOP-1321.
-
Resolution: Implemented
  Assignee: Marko A. Rodriguez

> Loosen coupling between TinkerPop serialization logic and shaded Kryo
> -
>
> Key: TINKERPOP-1321
> URL: https://issues.apache.org/jira/browse/TINKERPOP-1321
> Project: TinkerPop
>  Issue Type: Improvement
>  Components: io
>Affects Versions: 3.2.0-incubating
>Reporter: Dan LaRocque
>Assignee: Marko A. Rodriguez
> Fix For: 3.2.1
>
>
> When running jobs on Spark, TinkerPop currently recommends setting 
> spark.serializer=GryoSerializer.  This makes GryoSerializer responsible for 
> serializing not just TinkerPop types but also scala runtime types and Spark 
> internals.  GryoSerializer doesn't extend either of the two serializers 
> provided by Spark.  It effectively assumes responsibility for reimplementing 
> them.
> This is problematic.  It is not totally trivial to replicate the 
> functionality of Spark's standard serializers.  It is also not easy to 
> empirically test all meaningful cases.  For instance, there is a conditional 
> within Spark that selects between two concrete Map implementations depending 
> on whether the current RDD partition count exceeds 2k 
> (https://github.com/apache/spark/blob/branch-1.6/core/src/main/scala/org/apache/spark/scheduler/MapStatus.scala#L47-L53).
>   The implementation used below this threshold serializes fine on 
> GryoSerializer.  The implementation used above the threshold does not.  Above 
> the partition threshold, I've started getting 
> {{org.apache.spark.SparkException: Job aborted due to stage failure: 
> Exception while getting task result: 
> org.apache.tinkerpop.shaded.kryo.KryoException: java.io.IOException: I failed 
> to find one of the right cookies.}}  Google leads to 
> https://github.com/RoaringBitmap/RoaringBitmap/issues/64.  However, just 
> switching to Spark's {{KryoSerializer}} without changing anything somehow 
> fixes the problem in my environment, implying that Spark has done something 
> to address this problem that may not be fully replicated in TinkerPop.
> However, "just switching to Spark's KryoSerializer" is not a great approach.  
> For one thing, we lose the benefit of TinkerPop's space-efficient StarGraph 
> serializer, and Spark traversals can produce a lot of little ego-StarGraphs.  
> These still serialize, but KryoSerializer uses its default behavior 
> (FieldSerializer), which is not as clever about StarGraphs as TinkerPop's 
> StarGraphSerializer.  TinkerPop's reliance on its own internal shaded Kryo 
> means that its serializers cannot be registered with Spark's unshaded Kryo.
> More concerning, it's impossible to completely switch to KryoSerializer just 
> by tweaking the configuration.  Besides spark.serializer, there is also a 
> setting spark.closure.serializer for which the only supported value is 
> JavaSerializer.  Key TP classes that make it into the object reference graphs 
> of Spark closures implement Serializable by resorting to TinkerPop's shaded 
> Kryo via HadoopPools (looking at Object/VertexWritable).  This leads to 
> surprises with custom property data types.  It doesn't matter if those types 
> implement Serializable, and it doesn't matter if Spark's KryoSerializer is 
> configured to accept those types.  If  those types are reachable from 
> Object/VertexWritable, then they must be registered with TinkerPop's internal 
> shaded Kryo, or else it will choke on them (unless it was explicitly 
> configured to allow unregistered classes).
> I suggest the following change to give users more flexibility in their choice 
> of spark.serializer, and to allow them to reuse TinkerPop's serializers if 
> they choose not to use GryoSerializer: introduce lightweight interfaces that 
> decouple TinkerPop's serialization logic from the exact Kryo shaded/unshaded 
> package doing the work.  TinkerPop's serialization logic would be written 
> against interfaces that replicate a minimal subset of Kryo, and then TP's 
> shaded Kryo or Spark's unshaded Kryo could be plugged in underneath without 
> having to touch the source, recompile any TinkerPop code, or munge bytecode 
> at runtime.
> This would not resolve all of the potential problems/complexity around 
> TinkerPop serialization, but it would make it possible for users to apply the 
> spark.serializer of their choice, switching off GryoSerializer if they so 
> choose.  Users could also continue to use GyroSerializer as they have until 
> now.
> I've already run this through a few iterations locally and have an 
> abstraction that allows me to run with spark.serializer=KryoSerializer, 
> register GryoMapper/GryoSerializer's

[jira] [Commented] (TINKERPOP-1321) Loosen coupling between TinkerPop serialization logic and shaded Kryo

2016-06-07 Thread ASF GitHub Bot (JIRA)


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

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

Github user okram commented on the issue:

https://github.com/apache/incubator-tinkerpop/pull/325
  
```
[INFO] Reactor Summary:
[INFO]
[INFO] Apache TinkerPop ... SUCCESS [  
9.619 s]
[INFO] Apache TinkerPop :: Gremlin Shaded . SUCCESS [  
1.894 s]
[INFO] Apache TinkerPop :: Gremlin Core ... SUCCESS [ 
28.393 s]
[INFO] Apache TinkerPop :: Gremlin Test ... SUCCESS [  
9.757 s]
[INFO] Apache TinkerPop :: Gremlin Groovy . SUCCESS [ 
34.087 s]
[INFO] Apache TinkerPop :: Gremlin Groovy Test  SUCCESS [  
4.713 s]
[INFO] Apache TinkerPop :: TinkerGraph Gremlin  SUCCESS [02:35 
min]
[INFO] Apache TinkerPop :: Gremlin Benchmark .. SUCCESS [  
3.353 s]
[INFO] Apache TinkerPop :: Hadoop Gremlin . SUCCESS [04:08 
min]
[INFO] Apache TinkerPop :: Spark Gremlin .. SUCCESS [12:36 
min]
[INFO] Apache TinkerPop :: Giraph Gremlin . SUCCESS [  
02:58 h]
```

Neo4j failed cause it couldn't download jars (my internet connection must 
have died over night).


> Loosen coupling between TinkerPop serialization logic and shaded Kryo
> -
>
> Key: TINKERPOP-1321
> URL: https://issues.apache.org/jira/browse/TINKERPOP-1321
> Project: TinkerPop
>  Issue Type: Improvement
>  Components: io
>Affects Versions: 3.2.0-incubating
>Reporter: Dan LaRocque
> Fix For: 3.2.1
>
>
> When running jobs on Spark, TinkerPop currently recommends setting 
> spark.serializer=GryoSerializer.  This makes GryoSerializer responsible for 
> serializing not just TinkerPop types but also scala runtime types and Spark 
> internals.  GryoSerializer doesn't extend either of the two serializers 
> provided by Spark.  It effectively assumes responsibility for reimplementing 
> them.
> This is problematic.  It is not totally trivial to replicate the 
> functionality of Spark's standard serializers.  It is also not easy to 
> empirically test all meaningful cases.  For instance, there is a conditional 
> within Spark that selects between two concrete Map implementations depending 
> on whether the current RDD partition count exceeds 2k 
> (https://github.com/apache/spark/blob/branch-1.6/core/src/main/scala/org/apache/spark/scheduler/MapStatus.scala#L47-L53).
>   The implementation used below this threshold serializes fine on 
> GryoSerializer.  The implementation used above the threshold does not.  Above 
> the partition threshold, I've started getting 
> {{org.apache.spark.SparkException: Job aborted due to stage failure: 
> Exception while getting task result: 
> org.apache.tinkerpop.shaded.kryo.KryoException: java.io.IOException: I failed 
> to find one of the right cookies.}}  Google leads to 
> https://github.com/RoaringBitmap/RoaringBitmap/issues/64.  However, just 
> switching to Spark's {{KryoSerializer}} without changing anything somehow 
> fixes the problem in my environment, implying that Spark has done something 
> to address this problem that may not be fully replicated in TinkerPop.
> However, "just switching to Spark's KryoSerializer" is not a great approach.  
> For one thing, we lose the benefit of TinkerPop's space-efficient StarGraph 
> serializer, and Spark traversals can produce a lot of little ego-StarGraphs.  
> These still serialize, but KryoSerializer uses its default behavior 
> (FieldSerializer), which is not as clever about StarGraphs as TinkerPop's 
> StarGraphSerializer.  TinkerPop's reliance on its own internal shaded Kryo 
> means that its serializers cannot be registered with Spark's unshaded Kryo.
> More concerning, it's impossible to completely switch to KryoSerializer just 
> by tweaking the configuration.  Besides spark.serializer, there is also a 
> setting spark.closure.serializer for which the only supported value is 
> JavaSerializer.  Key TP classes that make it into the object reference graphs 
> of Spark closures implement Serializable by resorting to TinkerPop's shaded 
> Kryo via HadoopPools (looking at Object/VertexWritable).  This leads to 
> surprises with custom property data types.  It doesn't matter if those types 
> implement Serializable, and it doesn't matter if Spark's KryoSerializer is 
> configured to accept those types.  If  those types are reachable from 
> Object/VertexWritable, then they must be registered with TinkerPop's internal 
> shaded Kryo, or else it will choke on them (unless it was explicitly 
> configured to allow unregistered classes).
> I suggest

[GitHub] incubator-tinkerpop issue #325: TINKERPOP-1321 Introduce Kryo shim to suppor...

2016-06-07 Thread okram

Github user okram commented on the issue:

https://github.com/apache/incubator-tinkerpop/pull/325
  
```
[INFO] Reactor Summary:
[INFO]
[INFO] Apache TinkerPop ... SUCCESS [  
9.619 s]
[INFO] Apache TinkerPop :: Gremlin Shaded . SUCCESS [  
1.894 s]
[INFO] Apache TinkerPop :: Gremlin Core ... SUCCESS [ 
28.393 s]
[INFO] Apache TinkerPop :: Gremlin Test ... SUCCESS [  
9.757 s]
[INFO] Apache TinkerPop :: Gremlin Groovy . SUCCESS [ 
34.087 s]
[INFO] Apache TinkerPop :: Gremlin Groovy Test  SUCCESS [  
4.713 s]
[INFO] Apache TinkerPop :: TinkerGraph Gremlin  SUCCESS [02:35 
min]
[INFO] Apache TinkerPop :: Gremlin Benchmark .. SUCCESS [  
3.353 s]
[INFO] Apache TinkerPop :: Hadoop Gremlin . SUCCESS [04:08 
min]
[INFO] Apache TinkerPop :: Spark Gremlin .. SUCCESS [12:36 
min]
[INFO] Apache TinkerPop :: Giraph Gremlin . SUCCESS [  
02:58 h]
```

Neo4j failed cause it couldn't download jars (my internet connection must 
have died over night).


---
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-1254) Support dropping traverser path information when it is no longer needed.

2016-06-07 Thread Marko A. Rodriguez (JIRA)


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

Marko A. Rodriguez commented on TINKERPOP-1254:
---

How are things going on this work? [~twilmes] Doing okay? Need any 
advice/reviews?

> Support dropping traverser path information when it is no longer needed.
> 
>
> Key: TINKERPOP-1254
> URL: https://issues.apache.org/jira/browse/TINKERPOP-1254
> Project: TinkerPop
>  Issue Type: Improvement
>  Components: process
>Affects Versions: 3.1.1-incubating
>Reporter: Marko A. Rodriguez
>Assignee: Ted Wilmes
>
> The most expensive traversals (especially in OLAP) are those that can not be 
> "bulked." There are various reasons why two traversers at the same object can 
> not be bulked, but the primary reason is {{PATH}} or {{LABELED_PATH}}. That 
> is, when the history of the traverser is required, the probability of two 
> traversers having the same history is low.
> A key to making traversals more efficient is to do as a much as possible to 
> remove historic information from a traverser so it can get bulked. How does 
> one do this? 
> {code}
> g.V.as('a').out().as('b').out().where(neq('a').and().neq('b')).both().name
> {code}
> The {{LABELED_PATH}} of "a" and "b" are required up to the {{where()}} and at 
> which point, at {{both()}}, they are no longer required. It would be smart to 
> support:
> {code}
> traverser.dropLabels(Set)
> traverser.dropPath()
> {code}
> We would then, via a {{TraversalOptimizationStrategy}} insert a step between 
> {{where()}} and {{both()}} called {{PathPruneStep}} which would be a 
> {{SideEffectStep}}. The strategy would know which labels were no longer 
> needed (via forward lookahead) and then do:
> {code}
> public class PathPruneStep {
>   final Set dropLabels = ...
>   final boolean dropPath = ...
>   public void sideEffect(final Traverser traverser) {
> final Traverser start = this.starts.next();
> if(this.dropPath) start.dropPath();
> else start.dropLabels(labels); 
>   }
> }
> {code}
> Again, the more we can prune historic path data no longer needed, the higher 
> the probability of bulking. Think about this in terms of {{match()}}.
> {code}
> g.V().match(
>   a.out.b,
>   b.out.c,
>   c.neq.a,
>   c.out.b,
> ).select("a")
> {code}
> All we need is "a" at the end. Thus, once a pattern has been passed and no 
> future patterns require that label, drop it! 
> This idea is related to TINKERPOP-331, but I don't think we should deal with 
> manipulating the species. Thus, I think 331 is too "low level."



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

[GitHub] incubator-tinkerpop issue #328: TINKERPOP-1317: use graph class as root clas...

2016-06-07 Thread twilmes

Github user twilmes commented on the issue:

https://github.com/apache/incubator-tinkerpop/pull/328
  
Yes, looks good to me 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.
---

[jira] [Commented] (TINKERPOP-1317) IoGraphTest throws error: URI is not hierarchical

2016-06-07 Thread ASF GitHub Bot (JIRA)


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

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

Github user twilmes commented on the issue:

https://github.com/apache/incubator-tinkerpop/pull/328
  
Yes, looks good to me VOTE: +1


> IoGraphTest throws error: URI is not hierarchical
> -
>
> Key: TINKERPOP-1317
> URL: https://issues.apache.org/jira/browse/TINKERPOP-1317
> Project: TinkerPop
>  Issue Type: Bug
>  Components: test-suite
>Affects Versions: 3.2.0-incubating, 3.1.2-incubating
>Reporter: Jason Plurad
>Assignee: Jason Plurad
>Priority: Minor
>
> Via https://groups.google.com/d/msg/gremlin-users/aap3pxZtGyU/t-eOC6ZyAAAJ
> These methods will fail for graph providers that are trying to implement the 
> test suite:
> * {{IoGraphTest.shouldReadWriteModernToFileWithHelpers()}}
> * {{IoGraphTest.shouldReadWriteClassicToFileWithHelpers()}}
> Example stack trace:
> {noformat}
> shouldReadWriteModernToFileWithHelpers[gryo](org.apache.tinkerpop.gremlin.structure.io.IoGraphTest)
>   Time elapsed: 0.004 sec  <<< ERROR!
> java.lang.RuntimeException: Unable to computePath for class 
> org.apache.tinkerpop.gremlin.structure.io.IoGraphTest
>   at 
> org.apache.tinkerpop.gremlin.TestHelper.computePath(TestHelper.java:117)
>   at 
> org.apache.tinkerpop.gremlin.TestHelper.getRootOfBuildDirectory(TestHelper.java:105)
>   at 
> org.apache.tinkerpop.gremlin.TestHelper.makeTestDataPath(TestHelper.java:70)
>   at 
> org.apache.tinkerpop.gremlin.TestHelper.generateTempFile(TestHelper.java:127)
>   at 
> org.apache.tinkerpop.gremlin.structure.io.IoGraphTest.shouldReadWriteModernToFileWithHelpers(IoGraphTest.java:164)
>   at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
>   at 
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
>   at 
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
>   at java.lang.reflect.Method.invoke(Method.java:497)
>   at 
> org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:50)
>   at 
> org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:12)
>   at 
> org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:47)
>   at 
> org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:17)
>   at 
> org.junit.internal.runners.statements.RunBefores.evaluate(RunBefores.java:26)
>   at 
> org.junit.internal.runners.statements.RunAfters.evaluate(RunAfters.java:27)
>   at org.junit.rules.TestWatcher$1.evaluate(TestWatcher.java:55)
>   at org.junit.rules.RunRules.evaluate(RunRules.java:20)
>   at org.junit.runners.ParentRunner.runLeaf(ParentRunner.java:325)
>   at 
> org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:78)
>   at 
> org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:57)
>   at org.junit.runners.ParentRunner$3.run(ParentRunner.java:290)
>   at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:71)
>   at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:288)
>   at org.junit.runners.ParentRunner.access$000(ParentRunner.java:58)
>   at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:268)
>   at org.junit.runners.ParentRunner.run(ParentRunner.java:363)
>   at org.junit.runners.Suite.runChild(Suite.java:128)
>   at org.junit.runners.Suite.runChild(Suite.java:27)
>   at org.junit.runners.ParentRunner$3.run(ParentRunner.java:290)
>   at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:71)
>   at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:288)
>   at org.junit.runners.ParentRunner.access$000(ParentRunner.java:58)
>   at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:268)
>   at org.junit.runners.ParentRunner.run(ParentRunner.java:363)
>   at org.junit.runners.Suite.runChild(Suite.java:128)
>   at 
> org.apache.tinkerpop.gremlin.AbstractGremlinSuite.runChild(AbstractGremlinSuite.java:212)
>   at 
> org.apache.tinkerpop.gremlin.AbstractGremlinSuite.runChild(AbstractGremlinSuite.java:50)
>   at org.junit.runners.ParentRunner$3.run(ParentRunner.java:290)
>   at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:71)
>   at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:288)
>   at org.junit.runners.ParentRunner.access$000(ParentRunner.java:58)
>   at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:268)
>   at org.junit.runners.ParentRunner.run(ParentRunner.java:363)
>   at 
>

[jira] [Commented] (TINKERPOP-1321) Loosen coupling between TinkerPop serialization logic and shaded Kryo

2016-06-07 Thread ASF GitHub Bot (JIRA)


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

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

Github user dkuppitz commented on the issue:

https://github.com/apache/incubator-tinkerpop/pull/325
  
VOTE: +1


> Loosen coupling between TinkerPop serialization logic and shaded Kryo
> -
>
> Key: TINKERPOP-1321
> URL: https://issues.apache.org/jira/browse/TINKERPOP-1321
> Project: TinkerPop
>  Issue Type: Improvement
>  Components: io
>Affects Versions: 3.2.0-incubating
>Reporter: Dan LaRocque
> Fix For: 3.2.1
>
>
> When running jobs on Spark, TinkerPop currently recommends setting 
> spark.serializer=GryoSerializer.  This makes GryoSerializer responsible for 
> serializing not just TinkerPop types but also scala runtime types and Spark 
> internals.  GryoSerializer doesn't extend either of the two serializers 
> provided by Spark.  It effectively assumes responsibility for reimplementing 
> them.
> This is problematic.  It is not totally trivial to replicate the 
> functionality of Spark's standard serializers.  It is also not easy to 
> empirically test all meaningful cases.  For instance, there is a conditional 
> within Spark that selects between two concrete Map implementations depending 
> on whether the current RDD partition count exceeds 2k 
> (https://github.com/apache/spark/blob/branch-1.6/core/src/main/scala/org/apache/spark/scheduler/MapStatus.scala#L47-L53).
>   The implementation used below this threshold serializes fine on 
> GryoSerializer.  The implementation used above the threshold does not.  Above 
> the partition threshold, I've started getting 
> {{org.apache.spark.SparkException: Job aborted due to stage failure: 
> Exception while getting task result: 
> org.apache.tinkerpop.shaded.kryo.KryoException: java.io.IOException: I failed 
> to find one of the right cookies.}}  Google leads to 
> https://github.com/RoaringBitmap/RoaringBitmap/issues/64.  However, just 
> switching to Spark's {{KryoSerializer}} without changing anything somehow 
> fixes the problem in my environment, implying that Spark has done something 
> to address this problem that may not be fully replicated in TinkerPop.
> However, "just switching to Spark's KryoSerializer" is not a great approach.  
> For one thing, we lose the benefit of TinkerPop's space-efficient StarGraph 
> serializer, and Spark traversals can produce a lot of little ego-StarGraphs.  
> These still serialize, but KryoSerializer uses its default behavior 
> (FieldSerializer), which is not as clever about StarGraphs as TinkerPop's 
> StarGraphSerializer.  TinkerPop's reliance on its own internal shaded Kryo 
> means that its serializers cannot be registered with Spark's unshaded Kryo.
> More concerning, it's impossible to completely switch to KryoSerializer just 
> by tweaking the configuration.  Besides spark.serializer, there is also a 
> setting spark.closure.serializer for which the only supported value is 
> JavaSerializer.  Key TP classes that make it into the object reference graphs 
> of Spark closures implement Serializable by resorting to TinkerPop's shaded 
> Kryo via HadoopPools (looking at Object/VertexWritable).  This leads to 
> surprises with custom property data types.  It doesn't matter if those types 
> implement Serializable, and it doesn't matter if Spark's KryoSerializer is 
> configured to accept those types.  If  those types are reachable from 
> Object/VertexWritable, then they must be registered with TinkerPop's internal 
> shaded Kryo, or else it will choke on them (unless it was explicitly 
> configured to allow unregistered classes).
> I suggest the following change to give users more flexibility in their choice 
> of spark.serializer, and to allow them to reuse TinkerPop's serializers if 
> they choose not to use GryoSerializer: introduce lightweight interfaces that 
> decouple TinkerPop's serialization logic from the exact Kryo shaded/unshaded 
> package doing the work.  TinkerPop's serialization logic would be written 
> against interfaces that replicate a minimal subset of Kryo, and then TP's 
> shaded Kryo or Spark's unshaded Kryo could be plugged in underneath without 
> having to touch the source, recompile any TinkerPop code, or munge bytecode 
> at runtime.
> This would not resolve all of the potential problems/complexity around 
> TinkerPop serialization, but it would make it possible for users to apply the 
> spark.serializer of their choice, switching off GryoSerializer if they so 
> choose.  Users could also continue to use GyroSerializer as they have until 
> now.
> I've already run this through a few iterations locally and have an 
> abstraction that allows me to run with

[jira] [Created] (TINKERPOP-1326) Use KryoShim for serialization in VertexProgramHelper

2016-06-07 Thread Marko A. Rodriguez (JIRA)

Marko A. Rodriguez created TINKERPOP-1326:
-

 Summary: Use KryoShim for serialization in VertexProgramHelper
 Key: TINKERPOP-1326
 URL: https://issues.apache.org/jira/browse/TINKERPOP-1326
 Project: TinkerPop
  Issue Type: Improvement
  Components: io, process, structure
Affects Versions: 3.2.1
Reporter: Marko A. Rodriguez
 Fix For: 3.3.0


At the next major release, we should swap out the Java serialization work in 
{{VertexProgramHelper}} and instead, use the {{KryoShim}} work developed by 
[~dalaro]. This means we need a {{KryoShimService}} in {{gremlin-core}}. I say 
we remove the {{HadoopPoolsKryoShimService}} and go with a 
{{GryoPoolKryoShimService}} that then Hadoop-based OLAP engines can use (as 
well as engines like TinkerGraph).

This would a a "minor breaking" change as I suspect no provider is that deep 
into the serialization API of TinkerPop and the change would be a simple 
"change X to Y" sort of change for them.



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

[jira] [Commented] (TINKERPOP-1317) IoGraphTest throws error: URI is not hierarchical

2016-06-07 Thread ASF GitHub Bot (JIRA)


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

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

Github user pluradj commented on the issue:

https://github.com/apache/incubator-tinkerpop/pull/328
  
I always forget to vote for my own stuff. Thanks all.

VOTE: +1


> IoGraphTest throws error: URI is not hierarchical
> -
>
> Key: TINKERPOP-1317
> URL: https://issues.apache.org/jira/browse/TINKERPOP-1317
> Project: TinkerPop
>  Issue Type: Bug
>  Components: test-suite
>Affects Versions: 3.2.0-incubating, 3.1.2-incubating
>Reporter: Jason Plurad
>Assignee: Jason Plurad
>Priority: Minor
>
> Via https://groups.google.com/d/msg/gremlin-users/aap3pxZtGyU/t-eOC6ZyAAAJ
> These methods will fail for graph providers that are trying to implement the 
> test suite:
> * {{IoGraphTest.shouldReadWriteModernToFileWithHelpers()}}
> * {{IoGraphTest.shouldReadWriteClassicToFileWithHelpers()}}
> Example stack trace:
> {noformat}
> shouldReadWriteModernToFileWithHelpers[gryo](org.apache.tinkerpop.gremlin.structure.io.IoGraphTest)
>   Time elapsed: 0.004 sec  <<< ERROR!
> java.lang.RuntimeException: Unable to computePath for class 
> org.apache.tinkerpop.gremlin.structure.io.IoGraphTest
>   at 
> org.apache.tinkerpop.gremlin.TestHelper.computePath(TestHelper.java:117)
>   at 
> org.apache.tinkerpop.gremlin.TestHelper.getRootOfBuildDirectory(TestHelper.java:105)
>   at 
> org.apache.tinkerpop.gremlin.TestHelper.makeTestDataPath(TestHelper.java:70)
>   at 
> org.apache.tinkerpop.gremlin.TestHelper.generateTempFile(TestHelper.java:127)
>   at 
> org.apache.tinkerpop.gremlin.structure.io.IoGraphTest.shouldReadWriteModernToFileWithHelpers(IoGraphTest.java:164)
>   at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
>   at 
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
>   at 
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
>   at java.lang.reflect.Method.invoke(Method.java:497)
>   at 
> org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:50)
>   at 
> org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:12)
>   at 
> org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:47)
>   at 
> org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:17)
>   at 
> org.junit.internal.runners.statements.RunBefores.evaluate(RunBefores.java:26)
>   at 
> org.junit.internal.runners.statements.RunAfters.evaluate(RunAfters.java:27)
>   at org.junit.rules.TestWatcher$1.evaluate(TestWatcher.java:55)
>   at org.junit.rules.RunRules.evaluate(RunRules.java:20)
>   at org.junit.runners.ParentRunner.runLeaf(ParentRunner.java:325)
>   at 
> org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:78)
>   at 
> org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:57)
>   at org.junit.runners.ParentRunner$3.run(ParentRunner.java:290)
>   at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:71)
>   at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:288)
>   at org.junit.runners.ParentRunner.access$000(ParentRunner.java:58)
>   at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:268)
>   at org.junit.runners.ParentRunner.run(ParentRunner.java:363)
>   at org.junit.runners.Suite.runChild(Suite.java:128)
>   at org.junit.runners.Suite.runChild(Suite.java:27)
>   at org.junit.runners.ParentRunner$3.run(ParentRunner.java:290)
>   at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:71)
>   at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:288)
>   at org.junit.runners.ParentRunner.access$000(ParentRunner.java:58)
>   at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:268)
>   at org.junit.runners.ParentRunner.run(ParentRunner.java:363)
>   at org.junit.runners.Suite.runChild(Suite.java:128)
>   at 
> org.apache.tinkerpop.gremlin.AbstractGremlinSuite.runChild(AbstractGremlinSuite.java:212)
>   at 
> org.apache.tinkerpop.gremlin.AbstractGremlinSuite.runChild(AbstractGremlinSuite.java:50)
>   at org.junit.runners.ParentRunner$3.run(ParentRunner.java:290)
>   at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:71)
>   at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:288)
>   at org.junit.runners.ParentRunner.access$000(ParentRunner.java:58)
>   at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:268)
>   at

[GitHub] incubator-tinkerpop issue #329: TINKERPOP-1318: use mockito-core instead of ...

2016-06-07 Thread pluradj

Github user pluradj commented on the issue:

https://github.com/apache/incubator-tinkerpop/pull/329
  
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] incubator-tinkerpop issue #330: TINKERPOP-1319: several FeatureRequirement a...

2016-06-07 Thread pluradj

Github user pluradj commented on the issue:

https://github.com/apache/incubator-tinkerpop/pull/330
  
`mvn clean install && mvn verify -pl gremlin-server 
-DskipIntegrationTests=false` runs cleanly.

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

[jira] [Commented] (TINKERPOP-1321) Loosen coupling between TinkerPop serialization logic and shaded Kryo

2016-06-07 Thread ASF GitHub Bot (JIRA)


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

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

Github user spmallette commented on the issue:

https://github.com/apache/incubator-tinkerpop/pull/325
  
All tests pass with `docker/build.sh -t -n -i`

VOTE +1


> Loosen coupling between TinkerPop serialization logic and shaded Kryo
> -
>
> Key: TINKERPOP-1321
> URL: https://issues.apache.org/jira/browse/TINKERPOP-1321
> Project: TinkerPop
>  Issue Type: Improvement
>  Components: io
>Affects Versions: 3.2.0-incubating
>Reporter: Dan LaRocque
>Assignee: Marko A. Rodriguez
> Fix For: 3.2.1
>
>
> When running jobs on Spark, TinkerPop currently recommends setting 
> spark.serializer=GryoSerializer.  This makes GryoSerializer responsible for 
> serializing not just TinkerPop types but also scala runtime types and Spark 
> internals.  GryoSerializer doesn't extend either of the two serializers 
> provided by Spark.  It effectively assumes responsibility for reimplementing 
> them.
> This is problematic.  It is not totally trivial to replicate the 
> functionality of Spark's standard serializers.  It is also not easy to 
> empirically test all meaningful cases.  For instance, there is a conditional 
> within Spark that selects between two concrete Map implementations depending 
> on whether the current RDD partition count exceeds 2k 
> (https://github.com/apache/spark/blob/branch-1.6/core/src/main/scala/org/apache/spark/scheduler/MapStatus.scala#L47-L53).
>   The implementation used below this threshold serializes fine on 
> GryoSerializer.  The implementation used above the threshold does not.  Above 
> the partition threshold, I've started getting 
> {{org.apache.spark.SparkException: Job aborted due to stage failure: 
> Exception while getting task result: 
> org.apache.tinkerpop.shaded.kryo.KryoException: java.io.IOException: I failed 
> to find one of the right cookies.}}  Google leads to 
> https://github.com/RoaringBitmap/RoaringBitmap/issues/64.  However, just 
> switching to Spark's {{KryoSerializer}} without changing anything somehow 
> fixes the problem in my environment, implying that Spark has done something 
> to address this problem that may not be fully replicated in TinkerPop.
> However, "just switching to Spark's KryoSerializer" is not a great approach.  
> For one thing, we lose the benefit of TinkerPop's space-efficient StarGraph 
> serializer, and Spark traversals can produce a lot of little ego-StarGraphs.  
> These still serialize, but KryoSerializer uses its default behavior 
> (FieldSerializer), which is not as clever about StarGraphs as TinkerPop's 
> StarGraphSerializer.  TinkerPop's reliance on its own internal shaded Kryo 
> means that its serializers cannot be registered with Spark's unshaded Kryo.
> More concerning, it's impossible to completely switch to KryoSerializer just 
> by tweaking the configuration.  Besides spark.serializer, there is also a 
> setting spark.closure.serializer for which the only supported value is 
> JavaSerializer.  Key TP classes that make it into the object reference graphs 
> of Spark closures implement Serializable by resorting to TinkerPop's shaded 
> Kryo via HadoopPools (looking at Object/VertexWritable).  This leads to 
> surprises with custom property data types.  It doesn't matter if those types 
> implement Serializable, and it doesn't matter if Spark's KryoSerializer is 
> configured to accept those types.  If  those types are reachable from 
> Object/VertexWritable, then they must be registered with TinkerPop's internal 
> shaded Kryo, or else it will choke on them (unless it was explicitly 
> configured to allow unregistered classes).
> I suggest the following change to give users more flexibility in their choice 
> of spark.serializer, and to allow them to reuse TinkerPop's serializers if 
> they choose not to use GryoSerializer: introduce lightweight interfaces that 
> decouple TinkerPop's serialization logic from the exact Kryo shaded/unshaded 
> package doing the work.  TinkerPop's serialization logic would be written 
> against interfaces that replicate a minimal subset of Kryo, and then TP's 
> shaded Kryo or Spark's unshaded Kryo could be plugged in underneath without 
> having to touch the source, recompile any TinkerPop code, or munge bytecode 
> at runtime.
> This would not resolve all of the potential problems/complexity around 
> TinkerPop serialization, but it would make it possible for users to apply the 
> spark.serializer of their choice, switching off GryoSerializer if they so 
> choose.  Users could also continue to use GyroSerializer as they have until 
> now.
> I've already run this through

[jira] [Commented] (TINKERPOP-1196) Calls to Result.one() might block indefinitely

2016-06-07 Thread ASF GitHub Bot (JIRA)


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

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

Github user asfgit closed the pull request at:

https://github.com/apache/incubator-tinkerpop/pull/322


> Calls to Result.one() might block indefinitely
> --
>
> Key: TINKERPOP-1196
> URL: https://issues.apache.org/jira/browse/TINKERPOP-1196
> Project: TinkerPop
>  Issue Type: Bug
>  Components: driver
>Affects Versions: 3.1.1-incubating
>Reporter: stephen mallette
>Assignee: stephen mallette
> Fix For: 3.1.3
>
>
> There are no reproduction steps for this but it does seem to happen from on 
> very rare occasion for some unknown reason.  Need to investigate more.



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

[GitHub] incubator-tinkerpop pull request #322: TINKERPOP-1196 Fix for Result.one() w...

2016-06-07 Thread asfgit

Github user asfgit closed the pull request at:

https://github.com/apache/incubator-tinkerpop/pull/322


---
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] incubator-tinkerpop pull request #325: TINKERPOP-1321 Introduce Kryo shim to...

2016-06-07 Thread asfgit

Github user asfgit closed the pull request at:

https://github.com/apache/incubator-tinkerpop/pull/325


---
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-1321) Loosen coupling between TinkerPop serialization logic and shaded Kryo

2016-06-07 Thread ASF GitHub Bot (JIRA)


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

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

Github user asfgit closed the pull request at:

https://github.com/apache/incubator-tinkerpop/pull/325


> Loosen coupling between TinkerPop serialization logic and shaded Kryo
> -
>
> Key: TINKERPOP-1321
> URL: https://issues.apache.org/jira/browse/TINKERPOP-1321
> Project: TinkerPop
>  Issue Type: Improvement
>  Components: io
>Affects Versions: 3.2.0-incubating
>Reporter: Dan LaRocque
>Assignee: Marko A. Rodriguez
> Fix For: 3.2.1
>
>
> When running jobs on Spark, TinkerPop currently recommends setting 
> spark.serializer=GryoSerializer.  This makes GryoSerializer responsible for 
> serializing not just TinkerPop types but also scala runtime types and Spark 
> internals.  GryoSerializer doesn't extend either of the two serializers 
> provided by Spark.  It effectively assumes responsibility for reimplementing 
> them.
> This is problematic.  It is not totally trivial to replicate the 
> functionality of Spark's standard serializers.  It is also not easy to 
> empirically test all meaningful cases.  For instance, there is a conditional 
> within Spark that selects between two concrete Map implementations depending 
> on whether the current RDD partition count exceeds 2k 
> (https://github.com/apache/spark/blob/branch-1.6/core/src/main/scala/org/apache/spark/scheduler/MapStatus.scala#L47-L53).
>   The implementation used below this threshold serializes fine on 
> GryoSerializer.  The implementation used above the threshold does not.  Above 
> the partition threshold, I've started getting 
> {{org.apache.spark.SparkException: Job aborted due to stage failure: 
> Exception while getting task result: 
> org.apache.tinkerpop.shaded.kryo.KryoException: java.io.IOException: I failed 
> to find one of the right cookies.}}  Google leads to 
> https://github.com/RoaringBitmap/RoaringBitmap/issues/64.  However, just 
> switching to Spark's {{KryoSerializer}} without changing anything somehow 
> fixes the problem in my environment, implying that Spark has done something 
> to address this problem that may not be fully replicated in TinkerPop.
> However, "just switching to Spark's KryoSerializer" is not a great approach.  
> For one thing, we lose the benefit of TinkerPop's space-efficient StarGraph 
> serializer, and Spark traversals can produce a lot of little ego-StarGraphs.  
> These still serialize, but KryoSerializer uses its default behavior 
> (FieldSerializer), which is not as clever about StarGraphs as TinkerPop's 
> StarGraphSerializer.  TinkerPop's reliance on its own internal shaded Kryo 
> means that its serializers cannot be registered with Spark's unshaded Kryo.
> More concerning, it's impossible to completely switch to KryoSerializer just 
> by tweaking the configuration.  Besides spark.serializer, there is also a 
> setting spark.closure.serializer for which the only supported value is 
> JavaSerializer.  Key TP classes that make it into the object reference graphs 
> of Spark closures implement Serializable by resorting to TinkerPop's shaded 
> Kryo via HadoopPools (looking at Object/VertexWritable).  This leads to 
> surprises with custom property data types.  It doesn't matter if those types 
> implement Serializable, and it doesn't matter if Spark's KryoSerializer is 
> configured to accept those types.  If  those types are reachable from 
> Object/VertexWritable, then they must be registered with TinkerPop's internal 
> shaded Kryo, or else it will choke on them (unless it was explicitly 
> configured to allow unregistered classes).
> I suggest the following change to give users more flexibility in their choice 
> of spark.serializer, and to allow them to reuse TinkerPop's serializers if 
> they choose not to use GryoSerializer: introduce lightweight interfaces that 
> decouple TinkerPop's serialization logic from the exact Kryo shaded/unshaded 
> package doing the work.  TinkerPop's serialization logic would be written 
> against interfaces that replicate a minimal subset of Kryo, and then TP's 
> shaded Kryo or Spark's unshaded Kryo could be plugged in underneath without 
> having to touch the source, recompile any TinkerPop code, or munge bytecode 
> at runtime.
> This would not resolve all of the potential problems/complexity around 
> TinkerPop serialization, but it would make it possible for users to apply the 
> spark.serializer of their choice, switching off GryoSerializer if they so 
> choose.  Users could also continue to use GyroSerializer as they have until 
> now.
> I've already run this through a few iterations locally and have an 
> abstraction that allows me to

[jira] [Updated] (TINKERPOP-1235) Remove deprecated ProcessPerformanceSuite and TraversalPerformanceTest

2016-06-07 Thread stephen mallette (JIRA)


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

stephen mallette updated TINKERPOP-1235:

Description: The JUnit Benchmark based performance tests were deprecated 
for 3.2.0-incubating given: TINKERPOP-1016 and TINKERPOP-1273  (was: The JUnit 
Benchmark based performance tests were deprecated for 3.2.0-incubating given: 
TINKERPOP-1016)

> Remove deprecated ProcessPerformanceSuite and TraversalPerformanceTest
> --
>
> Key: TINKERPOP-1235
> URL: https://issues.apache.org/jira/browse/TINKERPOP-1235
> Project: TinkerPop
>  Issue Type: Improvement
>  Components: test-suite
>Affects Versions: 3.2.0-incubating
>Reporter: Ted Wilmes
>Priority: Minor
>  Labels: breaking, deprecation
>
> The JUnit Benchmark based performance tests were deprecated for 
> 3.2.0-incubating given: TINKERPOP-1016 and TINKERPOP-1273



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

[GitHub] incubator-tinkerpop issue #322: TINKERPOP-1196 Fix for Result.one() which co...

2016-06-07 Thread pluradj

Github user pluradj commented on the issue:

https://github.com/apache/incubator-tinkerpop/pull/322
  
I inspected the code, and got 5 successful runs on my Mac.

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

[jira] [Commented] (TINKERPOP-1196) Calls to Result.one() might block indefinitely

2016-06-07 Thread ASF GitHub Bot (JIRA)


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

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

Github user pluradj commented on the issue:

https://github.com/apache/incubator-tinkerpop/pull/322
  
I inspected the code, and got 5 successful runs on my Mac.

VOTE: +1


> Calls to Result.one() might block indefinitely
> --
>
> Key: TINKERPOP-1196
> URL: https://issues.apache.org/jira/browse/TINKERPOP-1196
> Project: TinkerPop
>  Issue Type: Bug
>  Components: driver
>Affects Versions: 3.1.1-incubating
>Reporter: stephen mallette
>Assignee: stephen mallette
> Fix For: 3.1.3
>
>
> There are no reproduction steps for this but it does seem to happen from on 
> very rare occasion for some unknown reason.  Need to investigate more.



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

[GitHub] incubator-tinkerpop issue #325: TINKERPOP-1321 Introduce Kryo shim to suppor...

2016-06-07 Thread spmallette

Github user spmallette commented on the issue:

https://github.com/apache/incubator-tinkerpop/pull/325
  
All tests pass with `docker/build.sh -t -n -i`

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

[jira] [Commented] (TINKERPOP-1254) Support dropping traverser path information when it is no longer needed.

2016-06-07 Thread Ted Wilmes (JIRA)


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

Ted Wilmes commented on TINKERPOP-1254:
---

I'm getting close to ready for a review.  I ended up switching over to keeping 
vs. dropping the labels.  Drop works out well if a traversal is totally flat 
but becomes problematic when you're dealing with steps that take nested 
traversals.  Currently I'm finishing up some fixes related to errors while 
running on graph computer, and then I'll push so we have something concrete to 
discuss.

> Support dropping traverser path information when it is no longer needed.
> 
>
> Key: TINKERPOP-1254
> URL: https://issues.apache.org/jira/browse/TINKERPOP-1254
> Project: TinkerPop
>  Issue Type: Improvement
>  Components: process
>Affects Versions: 3.1.1-incubating
>Reporter: Marko A. Rodriguez
>Assignee: Ted Wilmes
>
> The most expensive traversals (especially in OLAP) are those that can not be 
> "bulked." There are various reasons why two traversers at the same object can 
> not be bulked, but the primary reason is {{PATH}} or {{LABELED_PATH}}. That 
> is, when the history of the traverser is required, the probability of two 
> traversers having the same history is low.
> A key to making traversals more efficient is to do as a much as possible to 
> remove historic information from a traverser so it can get bulked. How does 
> one do this? 
> {code}
> g.V.as('a').out().as('b').out().where(neq('a').and().neq('b')).both().name
> {code}
> The {{LABELED_PATH}} of "a" and "b" are required up to the {{where()}} and at 
> which point, at {{both()}}, they are no longer required. It would be smart to 
> support:
> {code}
> traverser.dropLabels(Set)
> traverser.dropPath()
> {code}
> We would then, via a {{TraversalOptimizationStrategy}} insert a step between 
> {{where()}} and {{both()}} called {{PathPruneStep}} which would be a 
> {{SideEffectStep}}. The strategy would know which labels were no longer 
> needed (via forward lookahead) and then do:
> {code}
> public class PathPruneStep {
>   final Set dropLabels = ...
>   final boolean dropPath = ...
>   public void sideEffect(final Traverser traverser) {
> final Traverser start = this.starts.next();
> if(this.dropPath) start.dropPath();
> else start.dropLabels(labels); 
>   }
> }
> {code}
> Again, the more we can prune historic path data no longer needed, the higher 
> the probability of bulking. Think about this in terms of {{match()}}.
> {code}
> g.V().match(
>   a.out.b,
>   b.out.c,
>   c.neq.a,
>   c.out.b,
> ).select("a")
> {code}
> All we need is "a" at the end. Thus, once a pattern has been passed and no 
> future patterns require that label, drop it! 
> This idea is related to TINKERPOP-331, but I don't think we should deal with 
> manipulating the species. Thus, I think 331 is too "low level."



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

[GitHub] incubator-tinkerpop issue #331: if there is no edge label in the GraphML fil...

2016-06-07 Thread spmallette

Github user spmallette commented on the issue:

https://github.com/apache/incubator-tinkerpop/pull/331
  
I posted a note about this here:

https://groups.google.com/d/msg/gremlin-users/56CI2PTWueg/0Hj915GyEQAJ

with more explicit instructions. Your code change looks sensible as you 
show in your comment and it's good to know that works, but now you need to get 
us that code (with a unit test) in a good pull request that we can 
review/accept. 

I assume that the reason you can't push is because you cloned the apache 
repository. Again, you need to fork the Apache TinkerPop repo and make your 
changes there, then submit your pull request to us from that. When you submit 
your pull request it should only have your changes in it (note above how you 
have tons of commits from lots of different people - that's always an indicator 
that something isn't right). I gave pretty explicit instructions on how to 
proceed in that mailing list post. I hope you can get familiar with GitHub 
processes to submit this fix - it would be appreciated.

I'm going to close this PR from my end.  Thanks.


---
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] incubator-tinkerpop pull request #333: if there is no edge label in the Grap...

2016-06-07 Thread SergeVil

GitHub user SergeVil opened a pull request:

https://github.com/apache/incubator-tinkerpop/pull/333

if there is no edge label in the GraphML file, then use Edge.DEFAULT

As per suggestion in 
https://groups.google.com/forum/?utm_medium=email_source=footer#!topic/gremlin-users/56CI2PTWueg

I'm commiting the change

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

$ git pull https://github.com/SergeVil/incubator-tinkerpop tp31-graphml

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

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


commit 73427e2e4e99d5332cc82e6e1f67295a91df05b6
Author: Serge Vilvovsky 
Date:   2016-06-07T17:17:55Z

if there is no edge label in the GraphML file, then use Edge.DEFAULT




---
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] incubator-tinkerpop pull request #331: if there is no edge label in the Grap...

2016-06-07 Thread asfgit

Github user asfgit closed the pull request at:

https://github.com/apache/incubator-tinkerpop/pull/331


---
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] incubator-tinkerpop pull request #332: if there is no edge label in the Grap...

2016-06-07 Thread SergeVil

GitHub user SergeVil opened a pull request:

https://github.com/apache/incubator-tinkerpop/pull/332

if there is no edge label in the GraphML file, then use Edge.DEFAULT

As per suggestion in 
https://groups.google.com/forum/?utm_medium=email_source=footer#!topic/gremlin-users/56CI2PTWueg

I'm commiting the change

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

$ git pull https://github.com/SergeVil/incubator-tinkerpop tp31-graphml

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

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


commit 73427e2e4e99d5332cc82e6e1f67295a91df05b6
Author: Serge Vilvovsky 
Date:   2016-06-07T17:17:55Z

if there is no edge label in the GraphML file, then use Edge.DEFAULT




---
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] incubator-tinkerpop issue #333: if there is no edge label in the GraphML fil...

2016-06-07 Thread SergeVil

Github user SergeVil commented on the issue:

https://github.com/apache/incubator-tinkerpop/pull/333
  
> Why waste the object creation using Optional? Instead, in one line, do:
> edgeOutVertex.addEdge(null == edgeLabel ? Edge.DEFAULT_LABEL : edgeLabel, 
edgeInVertex, propsReady);

Pushed


---
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-1328) Provide [gremlin-python] as an code executor in docs

2016-06-07 Thread Daniel Kuppitz (JIRA)


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

Daniel Kuppitz commented on TINKERPOP-1328:
---

And there's the problem. The pre-processor simply outputs what it gets from the 
console. Nothing like {{gremlin>}} is manually added.

> Provide [gremlin-python] as an code executor in docs
> 
>
> Key: TINKERPOP-1328
> URL: https://issues.apache.org/jira/browse/TINKERPOP-1328
> Project: TinkerPop
>  Issue Type: Improvement
>  Components: documentation
>Affects Versions: 3.2.0-incubating
>Reporter: Marko A. Rodriguez
> Fix For: 3.2.1
>
>
> We currently support {{[gremlin-groovy]}} and 
> {{[gremlin-groovy,modern]}}-style code block annotations. It would be good to 
> also support {{[gremlin-python]}} and {{[gremlin-python,modern]}}. Likewise, 
> ensure a generalization for the future when {{gremlin-ruby}} and 
> {{gremlin-php}} are added.
> Gremlin-Python source can be evaluated using Groovy and the Jython 
> ScriptEngine. Suppose the following code block:
> {code}
> [gremlin-python,modern]
> g.V().out().name
> {code}
> *GROOVY*
> First, assume the following startup code that should be evaluated once and 
> only once into the Gremlin-Groovy script engine.
> {code}
> import javax.script.ScriptEngineManager
> import javax.script.SimpleBindings
> loader = new URLClassLoader(new 
> File("/Applications/jython-2.7.0/jython.jar").toURI().toURL()) // JYTHON_PATH 
> is better
> jython = new ScriptEngineManager(loader).getEngineByName("jython")
> jython.eval("import sys");
> jython.eval("sys.path.append('/Users/marko/software/tinkerpop/gremlin-variant/src/main/jython/gremlin_python')");
>  // PYTHON_PATH is better
> jython.eval("from gremlin_python import *");
> jythonBindings = new SimpleBindings();
> jythonBindings.put("g", jython.eval("PythonGraphTraversalSource('g')"));
> jython.getContext().setBindings(jythonBindings, 
> javax.script.ScriptContext.GLOBAL_SCOPE);
> {code}
> *The above requires that a global variable exist to where Jython is installed 
> as well as to where Gremlin-Python is installed. Though, for the latter, you 
> will simply be able to use {{pip}} to install dynamically ({{PYTHON_PATH}}) 
> is set to the location of Gremlin-Python.*
> From there, the code block above would be evaluated as:
> {code}
> g = TinkerGraphFactory.createModern().traversal()
> Eval.me("g", g, jython.eval("g.V().out().name").toString())
> {code}
> This looks as follow:
> {code}
> gremlin> g = TinkerFactory.createModern().traversal()
> ==>graphtraversalsource[tinkergraph[vertices:6 edges:6], standard]
> gremlin> Eval.me("g", g, jython.eval("g.V().out().name").toString())
> ==>lop
> ==>vadas
> ==>josh
> ==>ripple
> ==>lop
> ==>lop
> {code}
> And thats that...



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

[GitHub] incubator-tinkerpop issue #333: if there is no edge label in the GraphML fil...

2016-06-07 Thread SergeVil

Github user SergeVil commented on the issue:

https://github.com/apache/incubator-tinkerpop/pull/333
  
Will take a look



On Tue, Jun 7, 2016 at 2:18 PM, stephen mallette 
wrote:

> Note that your PR is failing for Travis:
>
> https://travis-ci.org/apache/incubator-tinkerpop/builds/135940598#L6936
>
> Any idea what's wrong?
>
> â
> You are receiving this because you authored the thread.
> Reply to this email directly, view it on GitHub
> 
,
> or mute the thread
> 

> .
>



---
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: Documentation deprecation warning on Github Wikis

2016-06-07 Thread Dylan Bethune-Waddell

I believe I mentioned this on the Titan or Tinkerpop mailing list but it was 
off-topic at the time, so I will restate here:


What about a pinned post on the gremlin-users mailing lists linking to the most 
recent docs and website as another guidepost for users in line with this one? 
Does this edit to all the old wikis etc. make such a thing redundant? My 
thinking on this is that it would be similar to the pinned post titled "On 
proper issue submission" at the top of the Titan mailing list - short and 
sweet, saving Tinker-time solving problems on the list that are not easily 
reproducible or particularly relevant/straightforward. It could also prevent 
some posts based on outdated information that beget more relevant questions 
posted deep down in the thread, which now has a misleading title that does not 
match the core of its content.


From: Jean-Baptiste Musso 
Sent: Tuesday, June 7, 2016 4:05:16 PM
To: dev@tinkerpop.apache.org
Subject: Documentation deprecation warning on Github Wikis

Dear devs,

I was thinking recently that we could add a deprecation warning
message on top of all former Github Wiki pages and warn visitors that
a new version of TinkerPop is available. I think this was also brought
up recently on the mailing list so I'm opening a discussion here.

I feel that some newcomers are still hitting old school TinkerPop 2
material when google'ing for graphs, Gremlin and TinkerPop. Adding a
warning message on top of old Wiki pages pointing them to the freshest
development on the Apache TinkerPop website could certainly help.

If everyone agrees, I'm volunteering to git clone the Wiki on all
repositories and edit all pages. As Stephen noted on HipChat, it's as
simple as following these steps:
https://help.github.com/articles/adding-and-editing-wiki-pages-locally/
Adding and editing wiki pages locally - User 
Documentation
help.github.com
Cloning wikis locally to your computer. Every wiki provides an easy way to 
clone its contents down to your computer: If you're using GitHub Desktop, click 
Clone in ...




Here's an example of such header we could add:

https://gist.github.com/jbmusso/802cf97ceb20547ba6abf0b4112ac3ee

Thoughts? Feel free to iterate. The wording could be improved.

Cheers,

Jean-Baptiste

40 matches

Mail list logo