[jira] [Closed] (TINKERPOP-1390) IdentityRemoveStrategyTest fails randomly

2016-08-12 Thread stephen mallette (JIRA) 

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

stephen mallette closed TINKERPOP-1390.
---
Resolution: Fixed
  Assignee: stephen mallette

Fixed on 
https://github.com/apache/tinkerpop/commit/9542419ff262d102f8f8ec21dc28d795fbe876bc
 via CTR

> IdentityRemoveStrategyTest fails randomly
> -
>
> Key: TINKERPOP-1390
> URL: https://issues.apache.org/jira/browse/TINKERPOP-1390
> Project: TinkerPop
>  Issue Type: Bug
>  Components: process
>Affects Versions: 3.2.1
>Reporter: stephen mallette
>Assignee: stephen mallette
>Priority: Minor
> Fix For: 3.2.2
>
>
> This test fails for me on different occasions - enough for me to have noticed 
> it happening:
> {code}
> shouldBeFaster(org.apache.tinkerpop.gremlin.process.traversal.strategy.optimization.IdentityRemovalStrategyTest$PerformanceTest)
>   Time elapsed: 1.857 sec  <<< FAILURE!
> java.lang.AssertionError: null
>   at org.junit.Assert.fail(Assert.java:86)
>   at org.junit.Assert.assertTrue(Assert.java:41)
>   at org.junit.Assert.assertTrue(Assert.java:52)
>   at 
> org.apache.tinkerpop.gremlin.process.traversal.strategy.TraversalStrategyPerformanceTest.shouldBeFaster(TraversalStrategyPerformanceTest.java:107)
>   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:498)
>   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.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.apache.maven.surefire.junit4.JUnit4Provider.execute(JUnit4Provider.java:264)
>   at 
> org.apache.maven.surefire.junit4.JUnit4Provider.executeTestSet(JUnit4Provider.java:153)
>   at 
> org.apache.maven.surefire.junit4.JUnit4Provider.invoke(JUnit4Provider.java:124)
>   at 
> org.apache.maven.surefire.booter.ForkedBooter.invokeProviderInSameClassLoader(ForkedBooter.java:200)
>   at 
> org.apache.maven.surefire.booter.ForkedBooter.runSuitesInProcess(ForkedBooter.java:153)
>   at 
> org.apache.maven.surefire.booter.ForkedBooter.main(ForkedBooter.java:103)
> {code}



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

[jira] [Closed] (TINKERPOP-1145) TraversalSource.script() as a general-solution to :>

2016-08-12 Thread stephen mallette (JIRA) 

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

stephen mallette closed TINKERPOP-1145.
---
Resolution: Won't Fix
  Assignee: stephen mallette

The work we have in TINKERPOP-1278 is a better approach to this problem. 

> TraversalSource.script() as a general-solution to :>
> 
>
> Key: TINKERPOP-1145
> URL: https://issues.apache.org/jira/browse/TINKERPOP-1145
> Project: TinkerPop
>  Issue Type: Improvement
>  Components: process
>Affects Versions: 3.1.0-incubating, 3.1.1-incubating
>Reporter: Marko A. Rodriguez
>Assignee: stephen mallette
>
> In {{GraphComputer}}, if the traversal uses a lambda, the user has to use a 
> "remote connection" and submit their traversal as a script-engine {{String}} 
> via:
> {code}
> gremlin> :> g.V().group().by{it.name[0]} 
> {code}
> For Gremlin Server, {{:>}} is currently the only way to submit traversals in 
> the Gremlin Console.
> This is all bad. Why? Its Gremlin Console specific and we can solve it more 
> elegantly with the work in TINKERPOP-971 and TINKERPOP-575.
> {code}
> g = graph.traversal().withComputer()
> g.V().group().by("name") // CURRENT AND GOOD
> {code}
> {code}
> g = graph.traversal().withComputer()
> g.script("g.V().group().by{it.name[0]}") // PROPOSED
> {code}
> {code}
> g = graph.traversal().withServer('127.0.0.1:8080')
> g.script("g.V().group().by{it.name[0]}") // PROPOSED
> {code}
> See {{TraversalScriptFunction}} for some pieces of the implementation.
> We could then make {{:>}} simply be shorthand for {{g.script()}}. However, 
> outside the console, {{g.script()}} just works.
> Next, we can assume {{gremlin-groovy}}, but we could also allow:
> {code}
> g = 
> graph.traversal().withServer('127.0.0.1:8080').withStrategies(ScriptEngineStrategy.for("gremlin-scala"))
> g.script("g.V().group().by(??)") // PROPOSED
> {code}



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

[jira] [Closed] (TINKERPOP-1334) Provide a way to pull gremlin.driver.Cluster connection settings.

2016-08-12 Thread stephen mallette (JIRA) 

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

stephen mallette closed TINKERPOP-1334.
---
   Resolution: Implemented
 Assignee: stephen mallette
Fix Version/s: 3.2.2

Implemented via CTR at 
https://github.com/apache/tinkerpop/commit/5d87d279f2e142d25a4f92991b1caa5700c9b821

> Provide a way to pull gremlin.driver.Cluster connection settings.
> -
>
> Key: TINKERPOP-1334
> URL: https://issues.apache.org/jira/browse/TINKERPOP-1334
> Project: TinkerPop
>  Issue Type: Improvement
>  Components: driver
>Affects Versions: 3.2.0-incubating
>Reporter: Rocco Varela
>Assignee: stephen mallette
> Fix For: 3.2.2
>
>
> I would like a way to extract all the default settings for a 
> gremlin.driver.Cluster connection. I would like to examine the number of 
> connections being used in a ConnectionPool, number of in-flight requests per 
> connection, etc. 
> I see ways for setting these fields here, but no way to extract them: 
> http://tinkerpop.incubator.apache.org/javadocs/3.0.1-SNAPSHOT/full/org/apache/tinkerpop/gremlin/driver/Cluster.Builder.html#maxConnectionPoolSize-int-



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

[jira] [Commented] (TINKERPOP-1230) Serialising lambdas for RemoteGraph

2016-08-12 Thread stephen mallette (JIRA) 

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

stephen mallette commented on TINKERPOP-1230:
-

A method for lambda serialization was implemented on TINKERPOP-1278 as part of 
the work on gremlin-python. This issue will close with that one.

> Serialising lambdas for RemoteGraph
> ---
>
> Key: TINKERPOP-1230
> URL: https://issues.apache.org/jira/browse/TINKERPOP-1230
> Project: TinkerPop
>  Issue Type: Improvement
>  Components: driver, server
>Affects Versions: 3.1.1-incubating
>Reporter: Michael Pollmeier
>Priority: Minor
>
> I just made an attempt to serialise lambdas and send them via the 
> RemoteGraph. I didn't quite get there, but wanted to share my findings: 
> * it's possible to serialise lambdas on the jvm by just extending 
> `Serializable`:
> http://stackoverflow.com/questions/22807912/how-to-serialize-a-lambda/22808112#22808112
> * sending a normal predicate doesn't work (this is a Scala REPL but it should 
> be pretty easy to convert this to java/groovy)
>   val g = RemoteGraph.open("conf/remote-graph.properties").traversal()
>   val pred1 = new java.util.function.Predicate[Traverser[Vertex]] { def 
> test(v: Traverser[Vertex]) = true }
>   g.V().filter(pred1).toList 
> // java.lang.RuntimeException: java.io.NotSerializableException: $anon$1
>  // on server: nothing
>  
> * simply adding Serializable let's us send it over the wire, but the server 
> doesn't deserialise it
>   val pred2 = new java.util.function.Predicate[Traverser[Vertex]] with 
> Serializable { def test(v: Traverser[Vertex]) = true }
>   g.V().filter(pred2).toList 
>   // on server: [WARN] OpExecutorHandler - Could not deserialize the 
> Traversal instance
> org.apache.tinkerpop.gremlin.server.op.OpProcessorException: Could 
> not deserialize the Traversal instance
> at 
> org.apache.tinkerpop.gremlin.server.op.traversal.TraversalOpProcessor.iterateOp(TraversalOpProcessor.java:135)
> at 
> org.apache.tinkerpop.gremlin.server.handler.OpExecutorHandler.channelRead0(OpExecutorHandler.java:68)
>   // on client: 
> org.apache.tinkerpop.gremlin.driver.exception.ResponseException: $anon$1 



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

2016-08-12 Thread stephen mallette (JIRA) 

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

stephen mallette commented on TINKERPOP-1278:
-

Implemented TINKERPOP-1347 on this branch.

> Implement Gremlin-Python and general purpose language variant test 
> infrastructure
> -
>
> Key: TINKERPOP-1278
> URL: https://issues.apache.org/jira/browse/TINKERPOP-1278
> Project: TinkerPop
>  Issue Type: Improvement
>  Components: language-variant
>Affects Versions: 3.2.0-incubating
>Reporter: Marko A. Rodriguez
>Assignee: Marko A. Rodriguez
>
> As discussed on dev@...
> Apache TinkerPop should provide, out-of-the-box, at least 3 Gremlin language 
> variants. It would be cool if these were:
> * Python (Mark Henderson)
> * PHP ([~PommeVerte])
> * Ruby (?[~okram])
> I think each of these should be generated using the reflection-model 
> presented in 
> http://tinkerpop.apache.org/docs/3.2.1-SNAPSHOT/tutorials/gremlin-language-variants/.
>  Moreover, on every {{mvn clean install}}, the code for these variants is 
> generated.
> Given the desire to separate language variants from language drivers, I think 
> that a language driver for each variant above should be "plugable." Moreover, 
> we should provide one driver implementation for each -- simple GremlinServer 
> REST.
> {code}
> gremlin-variants/
>   gremlin-ruby/
> gremlin_ruby.rb
> gremlin_ruby_rest_driver.rb
>   gremlin-php/
> Gremlin_PHP.php
> Gremlin_PHP_REST_Driver.php
>   gremlin-python/
> gremlin-python.py
> gremlin-python-rest-driver.py
> {code}
> Next, each variant implementation should be testable. This is PAINFUL if we 
> have to implement each {{g_V_out_repeatXasXaXX}} test case in 
> {{ProcessXXXSuite}}. Perhaps some RegEx transducer magic could be used to 
> convert all those tests from Gremlin-Java to the respective host language? 
> However, even if we do that, we still have the problem of how to test the 
> returned results. 
> I think what we should test the returned results using the JVM. For instance, 
> JRuby, Jython, JPHP (does it exist?). If we do this, we will save ourselves a 
> massive headache. All we have to do is create a {{GraphProvider}} that uses 
> {{TinkerGraph}} and whose {{TraversalSource}} is some sort of wrapper around 
> reflection-generated Ruby (e.g.).
> {code}
> g.V.out_e("knows") // returns a Ruby iterator
> {code}
> That Ruby iterator should be converted to a Java iterator and then the 
> {{ProcessXXXSuite}} can verify the results.
> With this, most everything is reflectively constructed.
> {code}
> gremlin_ruby.rb // generated via Java reflection
> gremlin_ruby_rest_driver.rb // manually coded
> match_test.rb   // generated via RegEx transducer
> has_test.rb // generated via RegEx transducer
> ...
> RubyGraphProvider.java// manually coded
> RubyProcessStandardSuite.java // manually coded
> RubyProcessComputerSuite.java // manually coded
> {code}
> Thus, the testing data flow would be:
> {code}
> MatchTest.Traversals.java --transducer-> match_test.rb
> match-test.rb --REST--> GremlinServer
> GremlinServer --GraphSON-->match-test.rb
> GraphSON --JRuby/GraphSONReader-->Java objects
> Java objects --JRuby-->MatchTest.java 
> {code}



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

Re: Adding IBM Graph to the providers list

2016-08-12 Thread Stephen Mallette 
+1

On Aug 12, 2016 10:03 AM, "Marko Rodriguez"  wrote:

> Hello,
>
> Assuming no one has any objections, I will update the homepage on Monday
> 8am (lazy consensus) with IBMGraph’s logo and “bio."
>
> Thanks,
> Marko.
>
> http://markorodriguez.com
>
>
>
> > On Aug 11, 2016, at 12:58 PM, Alaa Mahmoud  wrote:
> >
> > Here a link to the logo that I looked up pretty quickly. it'll do the job
> > :-)
> > http://cdn.geekwire.com/wp-content/uploads/2016/07/
> GraphDB-FA-big-hero-300x295.png
> >
> > Alaa
> >
> > On Thu, Aug 11, 2016 at 2:04 PM, Stephen Mallette 
> > wrote:
> >
> >> might need to ship it some other way - dev list doesn't like
> attachments i
> >> don't think.
> >>
> >> On Thu, Aug 11, 2016 at 1:52 PM, Marko Rodriguez 
> >> wrote:
> >>
> >>> Hi Alaa,
> >>>
> >>> I don’t think the logo came through, can you please reattach?
> >>>
> >>> Thank you,
> >>> Marko.
> >>>
> >>> http://markorodriguez.com
> >>>
> >>>
> >>>
>  On Aug 11, 2016, at 10:57 AM, Alaa Mahmoud 
> >> wrote:
> 
>  Can someone help add IBM Graph to the list of providers
> >>> http://tinkerpop.apache.org/providers.html <
> http://tinkerpop.apache.org/
> >>> providers.html>.
> 
>  Product info
>  IBM Graph  >
> >>> – is an easy-to-use, fully-managed graph database-as-a-service.
> >>> Administered through the cloud platform Bluemix, it is easy to start
> >> small
> >>> and scale seamlessly as user data grows.  IBM Graph is available 24/7
> and
> >>> managed by a team of experts so developers can focus on building their
> >>> application. Based on the Apache TinkerPop stack for building
> >>> high-performance graph applications, IBM Graph provides users with a
> set
> >> of
> >>> simplified HTTP API calls, a TinkerPop v3 compatible API, and the
> Gremlin
> >>> graph traversal language.
> 
>  Here's the link
>  https://console.ng.bluemix.net/catalog/services/ibm-graph/ <
> >>> https://console.ng.bluemix.net/catalog/services/ibm-graph/>
> 
>  Logo
>  Is attached
> 
>  Regrads
>  Alaa
> >>>
> >>>
> >>
>
>

[jira] [Commented] (TINKERPOP-1397) StarVertex self edge has buggy interaction with graph filters

2016-08-12 Thread ASF GitHub Bot (JIRA) 

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

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

Github user asfgit closed the pull request at:

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


> StarVertex self edge has buggy interaction with graph filters
> -
>
> Key: TINKERPOP-1397
> URL: https://issues.apache.org/jira/browse/TINKERPOP-1397
> Project: TinkerPop
>  Issue Type: Bug
>  Components: process
>Affects Versions: 3.1.3
>Reporter: Dan LaRocque
>Assignee: Marko A. Rodriguez
> Fix For: 3.1.4, 3.2.2
>
>
> When StarVertex adds a self-loop, it adds an instance of concrete type 
> {{StarOutEdge}} to both its {{outEdges}} map and its {{inEdges}} map.
> https://github.com/apache/tinkerpop/blob/8f7218d53a31cf41f4a0269d64ac1c27dfc0907a/gremlin-core/src/main/java/org/apache/tinkerpop/gremlin/structure/util/star/StarGraph.java#L321-L330
> (line 329 adds a {{StarOutEdge}} to the {{inEdges}} map)
> Having a {{StarOutEdge}} in the {{inEdges}} map mostly doesn't matter.  
> However, this does matter in the {{applyGraphFilter}} method.  This method 
> uses {{instanceof StarOutEdge}} to guess whether an edge's original direction 
> was in or out:
> https://github.com/apache/tinkerpop/blob/8f7218d53a31cf41f4a0269d64ac1c27dfc0907a/gremlin-core/src/main/java/org/apache/tinkerpop/gremlin/structure/util/star/StarGraph.java#L470
> If you trace {{applyGraphFilter}} through, you see that a {{StarVertex}} with 
> a self-loop can pop out of {{applyGraphFilter}} with two out edges 
> corresponding to the self loop and no in edges.  This leads to weird 
> traversal results.  One way to trigger this is to write a 
> {{GraphFilterAware}} {{InputRDD}} that produces {{StarVertex}} instances and 
> then run a {{g.V()inE("somelabel")}}, so that TP pushes down the 
> "somelabel" constraint, which is how I got here.
> I think {{addEdge}} should continue putting a {{StarOutEdge}} into 
> {{outEdges}}, like it already does.  -However, it should put a {{StarInEdge}} 
> into {{inEdges}}.  This would increase the object overhead associated with 
> StarVertices that have self loops (two edge objs instead of one).  If we 
> wanted to be obsessive about optimizing this case we could probably pervert 
> the {{inEdge}}/{{outEdge}} datastructure contents to do it, but IMHO that's 
> not worth it.-  Actually, I'm no longer convinced that's safe, since I think 
> it would alter some of StarVertex's other semantics.  For one, I think 
> retrieving an edge and setting a property on it would probably break.
> I'll make a PR soon.
> I don't know all of the versions this affects, but I do know it affects 3.2.1.



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

[GitHub] tinkerpop pull request #377: TINKERPOP-1397 StarGraph filtering with self ed...

2016-08-12 Thread asfgit 
Github user asfgit closed the pull request at:

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


---
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: [2/2] tinkerpop git commit: Merge remote-tracking branch 'origin/tp31'

2016-08-12 Thread Marko Rodriguez 
Simple fix — upmerge from tp31/ wasn’t done prior to edits to master/ on 
GroovyTailTest. Fixed.

Marko.

> On Aug 12, 2016, at 8:18 AM, Marko Rodriguez  wrote:
> 
> master/ is not building:
> 
> Tests in error:
>  
> GroovyTailTest$Traversals>TailTest.g_V_repeatXin_outX_timesX3X_tailX7X_count:131->get_g_V_repeatXin_outX_timesX3X_tailX7X_count:59->propertyMissing:-1
>  » MissingProperty
>  
> GroovyTailTest$Traversals>TailTest.g_V_repeatXin_outX_timesX3X_tailX7X_count:131->get_g_V_repeatXin_outX_timesX3X_tailX7X_count:59->propertyMissing:-1
>  » MissingProperty
> 
> Marko.,
> 
> http://markorodriguez.com
> 
> 
> 
>> On Aug 12, 2016, at 7:50 AM, plur...@apache.org wrote:
>> 
>> Merge remote-tracking branch 'origin/tp31'
>> 
>> 
>> Project: http://git-wip-us.apache.org/repos/asf/tinkerpop/repo
>> Commit: http://git-wip-us.apache.org/repos/asf/tinkerpop/commit/cc0c06f4
>> Tree: http://git-wip-us.apache.org/repos/asf/tinkerpop/tree/cc0c06f4
>> Diff: http://git-wip-us.apache.org/repos/asf/tinkerpop/diff/cc0c06f4
>> 
>> Branch: refs/heads/master
>> Commit: cc0c06f41a9679b5fd29722100a2afc0195ab334
>> Parents: c250331 6d29394
>> Author: Jason Plurad 
>> Authored: Fri Aug 12 09:49:51 2016 -0400
>> Committer: Jason Plurad 
>> Committed: Fri Aug 12 09:49:51 2016 -0400
>> 
>> --
>> CHANGELOG.asciidoc|  1 +
>> .../traversal/step/filter/TailGlobalStep.java |  5 -
>> .../traversal/step/filter/GroovyTailTest.groovy   |  5 +
>> .../process/traversal/step/filter/TailTest.java   | 18 ++
>> 4 files changed, 28 insertions(+), 1 deletion(-)
>> --
>> 
>> 
>> http://git-wip-us.apache.org/repos/asf/tinkerpop/blob/cc0c06f4/CHANGELOG.asciidoc
>> --
>> 
>> http://git-wip-us.apache.org/repos/asf/tinkerpop/blob/cc0c06f4/gremlin-core/src/main/java/org/apache/tinkerpop/gremlin/process/traversal/step/filter/TailGlobalStep.java
>> --
>> 
>> http://git-wip-us.apache.org/repos/asf/tinkerpop/blob/cc0c06f4/gremlin-groovy-test/src/main/groovy/org/apache/tinkerpop/gremlin/process/traversal/step/filter/GroovyTailTest.groovy
>> --
>> diff --cc 
>> gremlin-groovy-test/src/main/groovy/org/apache/tinkerpop/gremlin/process/traversal/step/filter/GroovyTailTest.groovy
>> index 41a7f39,7fac07e..c562233
>> --- 
>> a/gremlin-groovy-test/src/main/groovy/org/apache/tinkerpop/gremlin/process/traversal/step/filter/GroovyTailTest.groovy
>> +++ 
>> b/gremlin-groovy-test/src/main/groovy/org/apache/tinkerpop/gremlin/process/traversal/step/filter/GroovyTailTest.groovy
>> @@@ -55,8 -65,13 +55,13 @@@ public abstract class GroovyTailTest 
>> }
>> 
>> @Override
>> + public Traversal 
>> get_g_V_repeatXin_outX_timesX3X_tailX7X_count() {
>> + 
>> TraversalScriptHelper.compute("g.V.repeat(__.in().out()).times(3).tail(7).count()",g)
>> + }
>> + 
>> + @Override
>> public Traversal 
>> get_g_V_asXaX_out_asXaX_out_asXaX_selectXaX_byXunfold_valuesXnameX_foldX_tailXlocal_2X()
>>  {
>> -
>> TraversalScriptHelper.compute("g.V.as('a').out.as('a').out.as('a').select('a').by(unfold().values('name').fold).tail(local,
>>  2)",g)
>> +new ScriptTraversal<>(g, "gremlin-groovy", 
>> "g.V.as('a').out.as('a').out.as('a').select('a').by(unfold().values('name').fold).tail(local,
>>  2)")
>> }
>> 
>> @Override
>> 
>

Re: [2/2] tinkerpop git commit: Merge remote-tracking branch 'origin/tp31'

2016-08-12 Thread Marko Rodriguez 
master/ is not building:

Tests in error:
  
GroovyTailTest$Traversals>TailTest.g_V_repeatXin_outX_timesX3X_tailX7X_count:131->get_g_V_repeatXin_outX_timesX3X_tailX7X_count:59->propertyMissing:-1
 » MissingProperty
  
GroovyTailTest$Traversals>TailTest.g_V_repeatXin_outX_timesX3X_tailX7X_count:131->get_g_V_repeatXin_outX_timesX3X_tailX7X_count:59->propertyMissing:-1
 » MissingProperty

Marko.,

http://markorodriguez.com



> On Aug 12, 2016, at 7:50 AM, plur...@apache.org wrote:
> 
> Merge remote-tracking branch 'origin/tp31'
> 
> 
> Project: http://git-wip-us.apache.org/repos/asf/tinkerpop/repo
> Commit: http://git-wip-us.apache.org/repos/asf/tinkerpop/commit/cc0c06f4
> Tree: http://git-wip-us.apache.org/repos/asf/tinkerpop/tree/cc0c06f4
> Diff: http://git-wip-us.apache.org/repos/asf/tinkerpop/diff/cc0c06f4
> 
> Branch: refs/heads/master
> Commit: cc0c06f41a9679b5fd29722100a2afc0195ab334
> Parents: c250331 6d29394
> Author: Jason Plurad 
> Authored: Fri Aug 12 09:49:51 2016 -0400
> Committer: Jason Plurad 
> Committed: Fri Aug 12 09:49:51 2016 -0400
> 
> --
> CHANGELOG.asciidoc|  1 +
> .../traversal/step/filter/TailGlobalStep.java |  5 -
> .../traversal/step/filter/GroovyTailTest.groovy   |  5 +
> .../process/traversal/step/filter/TailTest.java   | 18 ++
> 4 files changed, 28 insertions(+), 1 deletion(-)
> --
> 
> 
> http://git-wip-us.apache.org/repos/asf/tinkerpop/blob/cc0c06f4/CHANGELOG.asciidoc
> --
> 
> http://git-wip-us.apache.org/repos/asf/tinkerpop/blob/cc0c06f4/gremlin-core/src/main/java/org/apache/tinkerpop/gremlin/process/traversal/step/filter/TailGlobalStep.java
> --
> 
> http://git-wip-us.apache.org/repos/asf/tinkerpop/blob/cc0c06f4/gremlin-groovy-test/src/main/groovy/org/apache/tinkerpop/gremlin/process/traversal/step/filter/GroovyTailTest.groovy
> --
> diff --cc 
> gremlin-groovy-test/src/main/groovy/org/apache/tinkerpop/gremlin/process/traversal/step/filter/GroovyTailTest.groovy
> index 41a7f39,7fac07e..c562233
> --- 
> a/gremlin-groovy-test/src/main/groovy/org/apache/tinkerpop/gremlin/process/traversal/step/filter/GroovyTailTest.groovy
> +++ 
> b/gremlin-groovy-test/src/main/groovy/org/apache/tinkerpop/gremlin/process/traversal/step/filter/GroovyTailTest.groovy
> @@@ -55,8 -65,13 +55,13 @@@ public abstract class GroovyTailTest 
>  }
> 
>  @Override
> + public Traversal 
> get_g_V_repeatXin_outX_timesX3X_tailX7X_count() {
> + 
> TraversalScriptHelper.compute("g.V.repeat(__.in().out()).times(3).tail(7).count()",g)
> + }
> + 
> + @Override
>  public Traversal 
> get_g_V_asXaX_out_asXaX_out_asXaX_selectXaX_byXunfold_valuesXnameX_foldX_tailXlocal_2X()
>  {
> -
> TraversalScriptHelper.compute("g.V.as('a').out.as('a').out.as('a').select('a').by(unfold().values('name').fold).tail(local,
>  2)",g)
> +new ScriptTraversal<>(g, "gremlin-groovy", 
> "g.V.as('a').out.as('a').out.as('a').select('a').by(unfold().values('name').fold).tail(local,
>  2)")
>  }
> 
>  @Override
>

[jira] [Updated] (TINKERPOP-1397) StarVertex self edge has buggy interaction with graph filters

2016-08-12 Thread Marko A. Rodriguez (JIRA) 

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

Marko A. Rodriguez updated TINKERPOP-1397:
--
Fix Version/s: 3.2.2

> StarVertex self edge has buggy interaction with graph filters
> -
>
> Key: TINKERPOP-1397
> URL: https://issues.apache.org/jira/browse/TINKERPOP-1397
> Project: TinkerPop
>  Issue Type: Bug
>  Components: process
>Affects Versions: 3.1.3
>Reporter: Dan LaRocque
> Fix For: 3.1.4, 3.2.2
>
>
> When StarVertex adds a self-loop, it adds an instance of concrete type 
> {{StarOutEdge}} to both its {{outEdges}} map and its {{inEdges}} map.
> https://github.com/apache/tinkerpop/blob/8f7218d53a31cf41f4a0269d64ac1c27dfc0907a/gremlin-core/src/main/java/org/apache/tinkerpop/gremlin/structure/util/star/StarGraph.java#L321-L330
> (line 329 adds a {{StarOutEdge}} to the {{inEdges}} map)
> Having a {{StarOutEdge}} in the {{inEdges}} map mostly doesn't matter.  
> However, this does matter in the {{applyGraphFilter}} method.  This method 
> uses {{instanceof StarOutEdge}} to guess whether an edge's original direction 
> was in or out:
> https://github.com/apache/tinkerpop/blob/8f7218d53a31cf41f4a0269d64ac1c27dfc0907a/gremlin-core/src/main/java/org/apache/tinkerpop/gremlin/structure/util/star/StarGraph.java#L470
> If you trace {{applyGraphFilter}} through, you see that a {{StarVertex}} with 
> a self-loop can pop out of {{applyGraphFilter}} with two out edges 
> corresponding to the self loop and no in edges.  This leads to weird 
> traversal results.  One way to trigger this is to write a 
> {{GraphFilterAware}} {{InputRDD}} that produces {{StarVertex}} instances and 
> then run a {{g.V()inE("somelabel")}}, so that TP pushes down the 
> "somelabel" constraint, which is how I got here.
> I think {{addEdge}} should continue putting a {{StarOutEdge}} into 
> {{outEdges}}, like it already does.  -However, it should put a {{StarInEdge}} 
> into {{inEdges}}.  This would increase the object overhead associated with 
> StarVertices that have self loops (two edge objs instead of one).  If we 
> wanted to be obsessive about optimizing this case we could probably pervert 
> the {{inEdge}}/{{outEdge}} datastructure contents to do it, but IMHO that's 
> not worth it.-  Actually, I'm no longer convinced that's safe, since I think 
> it would alter some of StarVertex's other semantics.  For one, I think 
> retrieving an edge and setting a property on it would probably break.
> I'll make a PR soon.
> I don't know all of the versions this affects, but I do know it affects 3.2.1.



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

[jira] [Assigned] (TINKERPOP-1397) StarVertex self edge has buggy interaction with graph filters

2016-08-12 Thread Marko A. Rodriguez (JIRA) 

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

Marko A. Rodriguez reassigned TINKERPOP-1397:
-

Assignee: Marko A. Rodriguez

> StarVertex self edge has buggy interaction with graph filters
> -
>
> Key: TINKERPOP-1397
> URL: https://issues.apache.org/jira/browse/TINKERPOP-1397
> Project: TinkerPop
>  Issue Type: Bug
>  Components: process
>Affects Versions: 3.1.3
>Reporter: Dan LaRocque
>Assignee: Marko A. Rodriguez
> Fix For: 3.1.4, 3.2.2
>
>
> When StarVertex adds a self-loop, it adds an instance of concrete type 
> {{StarOutEdge}} to both its {{outEdges}} map and its {{inEdges}} map.
> https://github.com/apache/tinkerpop/blob/8f7218d53a31cf41f4a0269d64ac1c27dfc0907a/gremlin-core/src/main/java/org/apache/tinkerpop/gremlin/structure/util/star/StarGraph.java#L321-L330
> (line 329 adds a {{StarOutEdge}} to the {{inEdges}} map)
> Having a {{StarOutEdge}} in the {{inEdges}} map mostly doesn't matter.  
> However, this does matter in the {{applyGraphFilter}} method.  This method 
> uses {{instanceof StarOutEdge}} to guess whether an edge's original direction 
> was in or out:
> https://github.com/apache/tinkerpop/blob/8f7218d53a31cf41f4a0269d64ac1c27dfc0907a/gremlin-core/src/main/java/org/apache/tinkerpop/gremlin/structure/util/star/StarGraph.java#L470
> If you trace {{applyGraphFilter}} through, you see that a {{StarVertex}} with 
> a self-loop can pop out of {{applyGraphFilter}} with two out edges 
> corresponding to the self loop and no in edges.  This leads to weird 
> traversal results.  One way to trigger this is to write a 
> {{GraphFilterAware}} {{InputRDD}} that produces {{StarVertex}} instances and 
> then run a {{g.V()inE("somelabel")}}, so that TP pushes down the 
> "somelabel" constraint, which is how I got here.
> I think {{addEdge}} should continue putting a {{StarOutEdge}} into 
> {{outEdges}}, like it already does.  -However, it should put a {{StarInEdge}} 
> into {{inEdges}}.  This would increase the object overhead associated with 
> StarVertices that have self loops (two edge objs instead of one).  If we 
> wanted to be obsessive about optimizing this case we could probably pervert 
> the {{inEdge}}/{{outEdge}} datastructure contents to do it, but IMHO that's 
> not worth it.-  Actually, I'm no longer convinced that's safe, since I think 
> it would alter some of StarVertex's other semantics.  For one, I think 
> retrieving an edge and setting a property on it would probably break.
> I'll make a PR soon.
> I don't know all of the versions this affects, but I do know it affects 3.2.1.



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

[jira] [Closed] (TINKERPOP-1397) StarVertex self edge has buggy interaction with graph filters

2016-08-12 Thread Marko A. Rodriguez (JIRA) 

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

Marko A. Rodriguez closed TINKERPOP-1397.
-
Resolution: Fixed

> StarVertex self edge has buggy interaction with graph filters
> -
>
> Key: TINKERPOP-1397
> URL: https://issues.apache.org/jira/browse/TINKERPOP-1397
> Project: TinkerPop
>  Issue Type: Bug
>  Components: process
>Affects Versions: 3.1.3
>Reporter: Dan LaRocque
>Assignee: Marko A. Rodriguez
> Fix For: 3.1.4, 3.2.2
>
>
> When StarVertex adds a self-loop, it adds an instance of concrete type 
> {{StarOutEdge}} to both its {{outEdges}} map and its {{inEdges}} map.
> https://github.com/apache/tinkerpop/blob/8f7218d53a31cf41f4a0269d64ac1c27dfc0907a/gremlin-core/src/main/java/org/apache/tinkerpop/gremlin/structure/util/star/StarGraph.java#L321-L330
> (line 329 adds a {{StarOutEdge}} to the {{inEdges}} map)
> Having a {{StarOutEdge}} in the {{inEdges}} map mostly doesn't matter.  
> However, this does matter in the {{applyGraphFilter}} method.  This method 
> uses {{instanceof StarOutEdge}} to guess whether an edge's original direction 
> was in or out:
> https://github.com/apache/tinkerpop/blob/8f7218d53a31cf41f4a0269d64ac1c27dfc0907a/gremlin-core/src/main/java/org/apache/tinkerpop/gremlin/structure/util/star/StarGraph.java#L470
> If you trace {{applyGraphFilter}} through, you see that a {{StarVertex}} with 
> a self-loop can pop out of {{applyGraphFilter}} with two out edges 
> corresponding to the self loop and no in edges.  This leads to weird 
> traversal results.  One way to trigger this is to write a 
> {{GraphFilterAware}} {{InputRDD}} that produces {{StarVertex}} instances and 
> then run a {{g.V()inE("somelabel")}}, so that TP pushes down the 
> "somelabel" constraint, which is how I got here.
> I think {{addEdge}} should continue putting a {{StarOutEdge}} into 
> {{outEdges}}, like it already does.  -However, it should put a {{StarInEdge}} 
> into {{inEdges}}.  This would increase the object overhead associated with 
> StarVertices that have self loops (two edge objs instead of one).  If we 
> wanted to be obsessive about optimizing this case we could probably pervert 
> the {{inEdge}}/{{outEdge}} datastructure contents to do it, but IMHO that's 
> not worth it.-  Actually, I'm no longer convinced that's safe, since I think 
> it would alter some of StarVertex's other semantics.  For one, I think 
> retrieving an edge and setting a property on it would probably break.
> I'll make a PR soon.
> I don't know all of the versions this affects, but I do know it affects 3.2.1.



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

[jira] [Commented] (TINKERPOP-1397) StarVertex self edge has buggy interaction with graph filters

2016-08-12 Thread ASF GitHub Bot (JIRA) 

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

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

Github user asfgit closed the pull request at:

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


> StarVertex self edge has buggy interaction with graph filters
> -
>
> Key: TINKERPOP-1397
> URL: https://issues.apache.org/jira/browse/TINKERPOP-1397
> Project: TinkerPop
>  Issue Type: Bug
>  Components: process
>Affects Versions: 3.1.3
>Reporter: Dan LaRocque
> Fix For: 3.1.4
>
>
> When StarVertex adds a self-loop, it adds an instance of concrete type 
> {{StarOutEdge}} to both its {{outEdges}} map and its {{inEdges}} map.
> https://github.com/apache/tinkerpop/blob/8f7218d53a31cf41f4a0269d64ac1c27dfc0907a/gremlin-core/src/main/java/org/apache/tinkerpop/gremlin/structure/util/star/StarGraph.java#L321-L330
> (line 329 adds a {{StarOutEdge}} to the {{inEdges}} map)
> Having a {{StarOutEdge}} in the {{inEdges}} map mostly doesn't matter.  
> However, this does matter in the {{applyGraphFilter}} method.  This method 
> uses {{instanceof StarOutEdge}} to guess whether an edge's original direction 
> was in or out:
> https://github.com/apache/tinkerpop/blob/8f7218d53a31cf41f4a0269d64ac1c27dfc0907a/gremlin-core/src/main/java/org/apache/tinkerpop/gremlin/structure/util/star/StarGraph.java#L470
> If you trace {{applyGraphFilter}} through, you see that a {{StarVertex}} with 
> a self-loop can pop out of {{applyGraphFilter}} with two out edges 
> corresponding to the self loop and no in edges.  This leads to weird 
> traversal results.  One way to trigger this is to write a 
> {{GraphFilterAware}} {{InputRDD}} that produces {{StarVertex}} instances and 
> then run a {{g.V()inE("somelabel")}}, so that TP pushes down the 
> "somelabel" constraint, which is how I got here.
> I think {{addEdge}} should continue putting a {{StarOutEdge}} into 
> {{outEdges}}, like it already does.  -However, it should put a {{StarInEdge}} 
> into {{inEdges}}.  This would increase the object overhead associated with 
> StarVertices that have self loops (two edge objs instead of one).  If we 
> wanted to be obsessive about optimizing this case we could probably pervert 
> the {{inEdge}}/{{outEdge}} datastructure contents to do it, but IMHO that's 
> not worth it.-  Actually, I'm no longer convinced that's safe, since I think 
> it would alter some of StarVertex's other semantics.  For one, I think 
> retrieving an edge and setting a property on it would probably break.
> I'll make a PR soon.
> I don't know all of the versions this affects, but I do know it affects 3.2.1.



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

Re: Adding IBM Graph to the providers list

2016-08-12 Thread Marko Rodriguez 
Hello,

Assuming no one has any objections, I will update the homepage on Monday 8am 
(lazy consensus) with IBMGraph’s logo and “bio."

Thanks,
Marko.

http://markorodriguez.com



> On Aug 11, 2016, at 12:58 PM, Alaa Mahmoud  wrote:
> 
> Here a link to the logo that I looked up pretty quickly. it'll do the job
> :-)
> http://cdn.geekwire.com/wp-content/uploads/2016/07/GraphDB-FA-big-hero-300x295.png
> 
> Alaa
> 
> On Thu, Aug 11, 2016 at 2:04 PM, Stephen Mallette 
> wrote:
> 
>> might need to ship it some other way - dev list doesn't like attachments i
>> don't think.
>> 
>> On Thu, Aug 11, 2016 at 1:52 PM, Marko Rodriguez 
>> wrote:
>> 
>>> Hi Alaa,
>>> 
>>> I don’t think the logo came through, can you please reattach?
>>> 
>>> Thank you,
>>> Marko.
>>> 
>>> http://markorodriguez.com
>>> 
>>> 
>>> 
 On Aug 11, 2016, at 10:57 AM, Alaa Mahmoud 
>> wrote:
 
 Can someone help add IBM Graph to the list of providers
>>> http://tinkerpop.apache.org/providers.html >> providers.html>.
 
 Product info
 IBM Graph 
>>> – is an easy-to-use, fully-managed graph database-as-a-service.
>>> Administered through the cloud platform Bluemix, it is easy to start
>> small
>>> and scale seamlessly as user data grows.  IBM Graph is available 24/7 and
>>> managed by a team of experts so developers can focus on building their
>>> application. Based on the Apache TinkerPop stack for building
>>> high-performance graph applications, IBM Graph provides users with a set
>> of
>>> simplified HTTP API calls, a TinkerPop v3 compatible API, and the Gremlin
>>> graph traversal language.
 
 Here's the link
 https://console.ng.bluemix.net/catalog/services/ibm-graph/ <
>>> https://console.ng.bluemix.net/catalog/services/ibm-graph/>
 
 Logo
 Is attached
 
 Regrads
 Alaa
>>> 
>>> 
>>

[jira] [Closed] (TINKERPOP-1228) Traversal Caching for TraversalOpProcessor

2016-08-12 Thread stephen mallette (JIRA) 

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

stephen mallette closed TINKERPOP-1228.
---
Resolution: Not A Problem
  Assignee: stephen mallette

This really isn't terribly useful an idea anymore with {{Bytecode}} 
representation of a {{Traversal}} and side-effect data cached on the server.

> Traversal Caching for TraversalOpProcessor
> --
>
> Key: TINKERPOP-1228
> URL: https://issues.apache.org/jira/browse/TINKERPOP-1228
> Project: TinkerPop
>  Issue Type: Improvement
>  Components: driver, server
>Affects Versions: 3.2.0-incubating
>Reporter: stephen mallette
>Assignee: stephen mallette
>
> Serialized traversals are big which makes repeated requests for the same 
> traversal expensive. Would be better to cache these somehow for re-use to 
> avoid the serialization and network overhead.



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

[jira] [Closed] (TINKERPOP-1255) Please delete old releases from mirroring system

2016-08-12 Thread stephen mallette (JIRA) 

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

stephen mallette closed TINKERPOP-1255.
---
Resolution: Fixed

I assume the new download page addresses the issues raised at this point. No 
"old" versions should be on the mirror at this point.

> Please delete old releases from mirroring system
> 
>
> Key: TINKERPOP-1255
> URL: https://issues.apache.org/jira/browse/TINKERPOP-1255
> Project: TinkerPop
>  Issue Type: Improvement
>  Components: build-release
>Affects Versions: 3.1.1-incubating
> Environment: 
> https://dist.apache.org/repos/dist/release/incubator/tinkerpop/
>Reporter: Sebb
>Assignee: stephen mallette
>
> To reduce the load on the ASF mirrors, projects are required to delete old 
> releases [1]
> Please can you remove all non-current releases?
> Thanks!
> [1] http://www.apache.org/dev/release.html#when-to-archive



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

[jira] [Commented] (TINKERPOP-1397) StarVertex self edge has buggy interaction with graph filters

2016-08-12 Thread ASF GitHub Bot (JIRA) 

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

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

Github user spmallette commented on the issue:

https://github.com/apache/tinkerpop/pull/377
  
VOTE +1


> StarVertex self edge has buggy interaction with graph filters
> -
>
> Key: TINKERPOP-1397
> URL: https://issues.apache.org/jira/browse/TINKERPOP-1397
> Project: TinkerPop
>  Issue Type: Bug
>  Components: process
>Affects Versions: 3.1.3
>Reporter: Dan LaRocque
> Fix For: 3.1.4
>
>
> When StarVertex adds a self-loop, it adds an instance of concrete type 
> {{StarOutEdge}} to both its {{outEdges}} map and its {{inEdges}} map.
> https://github.com/apache/tinkerpop/blob/8f7218d53a31cf41f4a0269d64ac1c27dfc0907a/gremlin-core/src/main/java/org/apache/tinkerpop/gremlin/structure/util/star/StarGraph.java#L321-L330
> (line 329 adds a {{StarOutEdge}} to the {{inEdges}} map)
> Having a {{StarOutEdge}} in the {{inEdges}} map mostly doesn't matter.  
> However, this does matter in the {{applyGraphFilter}} method.  This method 
> uses {{instanceof StarOutEdge}} to guess whether an edge's original direction 
> was in or out:
> https://github.com/apache/tinkerpop/blob/8f7218d53a31cf41f4a0269d64ac1c27dfc0907a/gremlin-core/src/main/java/org/apache/tinkerpop/gremlin/structure/util/star/StarGraph.java#L470
> If you trace {{applyGraphFilter}} through, you see that a {{StarVertex}} with 
> a self-loop can pop out of {{applyGraphFilter}} with two out edges 
> corresponding to the self loop and no in edges.  This leads to weird 
> traversal results.  One way to trigger this is to write a 
> {{GraphFilterAware}} {{InputRDD}} that produces {{StarVertex}} instances and 
> then run a {{g.V()inE("somelabel")}}, so that TP pushes down the 
> "somelabel" constraint, which is how I got here.
> I think {{addEdge}} should continue putting a {{StarOutEdge}} into 
> {{outEdges}}, like it already does.  -However, it should put a {{StarInEdge}} 
> into {{inEdges}}.  This would increase the object overhead associated with 
> StarVertices that have self loops (two edge objs instead of one).  If we 
> wanted to be obsessive about optimizing this case we could probably pervert 
> the {{inEdge}}/{{outEdge}} datastructure contents to do it, but IMHO that's 
> not worth it.-  Actually, I'm no longer convinced that's safe, since I think 
> it would alter some of StarVertex's other semantics.  For one, I think 
> retrieving an edge and setting a property on it would probably break.
> I'll make a PR soon.
> I don't know all of the versions this affects, but I do know it affects 3.2.1.



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

[GitHub] tinkerpop issue #377: TINKERPOP-1397 StarGraph filtering with self edges

2016-08-12 Thread spmallette 
Github user spmallette commented on the issue:

https://github.com/apache/tinkerpop/pull/377
  
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-1151) slf4j-log4j12 / log4j is only required for testing

2016-08-12 Thread stephen mallette (JIRA) 

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

stephen mallette closed TINKERPOP-1151.
---
   Resolution: Fixed
Fix Version/s: 3.2.2

> slf4j-log4j12 / log4j is only required for testing
> --
>
> Key: TINKERPOP-1151
> URL: https://issues.apache.org/jira/browse/TINKERPOP-1151
> Project: TinkerPop
>  Issue Type: Bug
>  Components: build-release
>Affects Versions: 3.1.0-incubating
>Reporter: Hendy Irawan
>Assignee: stephen mallette
>Priority: Trivial
>  Labels: breaking
> Fix For: 3.2.2
>
>
> Pull request: https://github.com/apache/incubator-tinkerpop/pull/229



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

[GitHub] tinkerpop pull request #373: TINKERPOP-1151 Made a number of changes to logg...

2016-08-12 Thread asfgit 
Github user asfgit closed the pull request at:

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


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