Re: [DISCUSS] Add HGraphDB to graph system listing

[Ted Wilmes]

The 72 hours blew past and I didn't even notice.  Looks like there aren't
any objections so I'll get HGraphDB
added to the listing tomorrow morning.

Thanks,
Ted

On Fri, Nov 11, 2016 at 11:58 AM, Ted Wilmes  wrote:

> I think at this point it's not too big of a problem and yeah, your point
> about it giving dormant projects a possible boost is a good one.  Perhaps
> in
> a few months we can reevaluate and if things look a little out of control
> we could introduce an every 3-4 months "pruning" of projects that no longer
> meet the criteria.
>
> --Ted
>
> On Fri, Nov 11, 2016 at 11:49 AM, Stephen Mallette 
> wrote:
>
>> Yeah - I think I'd come up with the "current or previous 'y' version"
>> stipulation. I still like that as a measure of "active" but at the same
>> time I've not really wanted to apply it a heavy-handed way. Projects that
>> become dormant may be helped by the promotion provided by TinkerPop (e.g.
>> someone finds ts-tinkerpop through the listing and starts to try to
>> contribute to it).  Maybe it's not too big a problem yet?
>>
>> On Fri, Nov 11, 2016 at 11:49 AM, Jason Plurad  wrote:
>>
>> > +1 on the HGraphDB index listing.
>> >
>> > I think another minor concern is how to handle projects that have gone
>> > dormant, like ts-tinkerpop or scalajs-gremlin-client for example.
>> > Understanding how versions line up between TinkerPop and whatever
>> database
>> > or library they want to use has been a pain point for many users.
>> >
>> > My emphasis below:
>> >
>> > The project must be *actively* developed/maintained to a current or
>> > previous "y" version of Apache TinkerPop (3.y.z).
>> >
>> > -- Jason
>> >
>> > On Thu, Nov 10, 2016 at 3:21 PM, Stephen Mallette > >
>> > wrote:
>> >
>> > > I sorta share that sentiment however, I think we had that discussion
>> back
>> > > when we determined our listing requirements and we figured we couldn't
>> > > figure out how to easily quantify "mature".
>> > >
>> > > On Thu, Nov 10, 2016 at 3:17 PM, Jean-Baptiste Musso <
>> jbmu...@gmail.com>
>> > > wrote:
>> > >
>> > > > Interesting thing. +1 to adding HGraphDB to the list.
>> > > >
>> > > > Minor concern: I'm not sure if we want to manage a curated list of
>> > > > implementations and maybe restrict to more mature projects. I'm just
>> > > > thinking out loud here: I'm not targeting HGraphDB specifically
>> (and I
>> > > wish
>> > > > them good luck - *cheers*). My main concern is that the project is
>> very
>> > > > young, but graph databases need as much publicity as they can.
>> > > >
>> > > > Jean-Baptiste
>> > > >
>> > > > On Thu, Nov 10, 2016 at 8:58 PM, Ted Wilmes 
>> wrote:
>> > > >
>> > > > > Hello everyone,
>> > > > > Robert Yokota notified us today that he has developed an
>> > > > > Apache TinkerPop enabled graph db: https://github.com/rayokota/
>> > > hgraphdb.
>> > > > > Correct me if I'm wrong Robert, but it looks like it's at the
>> > TinkerPop
>> > > > > 3.2.3 version.
>> > > > >
>> > > > > I think HGraphDB meets our index listing requirements but I
>> wanted to
>> > > > bring
>> > > > > it up
>> > > > > just in case anyone felt differently.  Unless there are any
>> > objections,
>> > > > > I'll assume lazy
>> > > > > consensus in three days (Sunday, November 13, 2016 2:00 CST) and
>> add
>> > > > > HGraphDB
>> > > > > to the graph systems listing.
>> > > > >
>> > > > > Thanks,
>> > > > > Ted
>> > > > >
>> > > >
>> > >
>> >
>>
>
>

[jira] [Created] (TINKERPOP-1554) has(propertyKey) should have a corresponding step in Gremlin-Java.

[Marko A. Rodriguez (JIRA)]

Marko A. Rodriguez created TINKERPOP-1554:
-

 Summary: has(propertyKey) should have a corresponding step in 
Gremlin-Java.
 Key: TINKERPOP-1554
 URL: https://issues.apache.org/jira/browse/TINKERPOP-1554
 Project: TinkerPop
  Issue Type: Improvement
  Components: process
Affects Versions: 3.2.3
Reporter: Marko A. Rodriguez


Currently {{has('name')}} compiles to {{filter(values('name'))}}. This is bad 
for a few reasons:

1. Its slower than a direct step.
2. Its nested traversals which increases reasoning time of strategies.
3. Its not clear from bytecode what it going on.

I propose:

{code}
public class HasPropertyStep implements FilterStep {

  private String propertyKey;

  public boolean filter(final Traverser.Admin traverser) {
return traverser.get().properties(propertyKey).hasNext();
  }

}
{code}



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

[jira] [Commented] (TINKERPOP-1502) Chained has()-steps should simply left-append HasContainers in Gremlin-Java.

[ASF GitHub Bot (JIRA)]

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

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

Github user dkuppitz commented on the issue:

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


> Chained has()-steps should simply left-append HasContainers in Gremlin-Java.
> 
>
> Key: TINKERPOP-1502
> URL: https://issues.apache.org/jira/browse/TINKERPOP-1502
> Project: TinkerPop
>  Issue Type: Improvement
>  Components: process
>Affects Versions: 3.2.2
>Reporter: Marko A. Rodriguez
>
> In Gremlin-Java, {{g.V().has(a).has(b).has(c).out()}} is originally 
> represented as {{[GraphStep,HasStep(a),HasStep(b),HasStep(c),VertexStep]}}. 
> Ultimately, {{InlineFilterStrategy}} or most provider strategies will turn 
> such {{HasStep}}-chains into {{[GraphStep,HasStep(a,b,c),VertexStep]}}. That 
> is, strategies fold {{has()}}-steps "left" and delete "right" {{has()}}-steps 
> and left propagates their labels (i.e. clock cycles). I think that 
> {{GraphTraversal}} should simply do this:
> {code}
> public GraphTraversal has(whateves) {
>   if(this.getEndStep() instanceof HasStep)
> this.getEndSte().addHasContainer(new HasContainer(whateves))
>   else
> this.addStep(new HasStep(new HasContainer(whateves)));
>   this.bytecode.addStep("has",whateves);
>   return this;
> }
> {code}
> In essence, a "write time" optimization can be done. Given that chains of 
> {{has()}}'s is super common, this can save significant clock-cycles in the 
> long run of a production application.



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

[GitHub] tinkerpop issue #495: TINKERPOP-1502 & TINKERPOP-1482: Chained has-container...

[dkuppitz]

Github user dkuppitz commented on the issue:

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

Re: Store and Aggregate

[Marko Rodriguez]

Hi,

I made a ticket for this:

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


Marko.

http://markorodriguez.com



> On Sep 26, 2016, at 9:35 AM, Marko Rodriguez  wrote:
> 
> Hello,
> 
>> I imagine that .store('x').barrier() and .barrier().store('x') would have
>> the same end result while taking slightly different paths at least with how
>> I read the definitions as they are today in OLTP.
> 
> Yes, they would.
> 
>> .store('x').barrier() would lazily fill 'x' up to the barrier.
>> .barrier().store('x') would aggregate at the barrier then store all at once
>> in 'x'
>> After strategies are applied there may not be any real difference.
> 
> Correct.
> 
>> Although I'm a little confused by the local/global statement and how it
>> relates to lazy/eager collections.  I definitely see .as()  being 'local'
>> or per each entity whereas store() is a collection (not sure about scope).
>> So maybe the thought was that store(local) acts like as()?  but then it
>> would have to take another parameter for the label or still use as() in
>> addition.  .store(local, 'a'), or .store(local).as('a'),
>> .store(global).as('a'), .barrier().store(global).as('a’)?
> 
> Scope.global and Scope.local are simply tokens that mean, in general:
>   “for all traversers up to this step” — global
>   “for the current traverser at this step” — local
> 
> Thus,
> 
>   store(local) would “store the current traverser at this step.”
>   store(global) would “store all traversers up to this step."
> 
> Ah. I see your confusion now — yes, we would would still need a side-effect 
> variable name:
> 
>   store(local, “x”)
>   store(global, “x”)
> 
> …and no, this is not as(“x”) as as(“x”) labels a step. Store requires the 
> side-effect variable name.
> 
> HTH,
> Marko.
> 
> 
> 
> 
>> 
>> 
>> On Wed, Sep 21, 2016 at 9:15 AM, Ted Wilmes  wrote:
>> 
>>> I like the idea of deprecating aggregate and combining barrier with store
>>> to get the same behavior, but the flipped version makes more sense to me
>>> "store().barrier()" when running in OLTP mode.
>>> 
>>> gremlin> g.V().out().aggregate('x').limit(1).cap('x')
>>> ==>[v[3],v[3],v[3],v[2],v[4],v[5]]
>>> gremlin> g.V().out().store('x').barrier().limit(1).cap('x')
>>> ==>[v[3],v[3],v[3],v[2],v[4],v[5]]
>>> 
>>> With the barrier before the store in DFS, I would assume the store side
>>> effect would still be lazily populated.  Having said that I know we could
>>> make it work that way just fine, it just reads a little unintuitively to
>>> me.  Curious to see what you guys think of that though because I may have
>>> things turned around in my head.
>>> 
>>> --Ted
>>> 
>>> On Wed, Sep 21, 2016 at 4:59 AM, Jean-Baptiste Musso 
>>> wrote:
>>> 
 I also recall Daniel mentioning in a post that .store() in OLAP works
>>> like
 .aggregate() in OLTP so this change could help users distinguish between
 both worlds and BFS/DFS.
 
 On Wednesday, 21 September 2016, Dylan Millikin <
>>> dylan.milli...@gmail.com>
 wrote:
 
> yeah I like the barrier().store() best as well.
> 
> On Wed, Sep 21, 2016 at 11:46 AM, Jean-Baptiste Musso <
>>> jbmu...@gmail.com
> >
> wrote:
> 
>> I think barrier().store() for .aggregate() is very appropriate and
 fully
>> tells what is going on.
>> 
>> I like both, +1 for one or the other.
>> 
>> People also tend to confuse .as() and .store()/.aggregate().
>> 
>> On Tuesday, 20 September 2016, Marko Rodriguez  >
>> wrote:
>> 
>>> Hi,
>>> 
>>> I was thinking that store() and aggregate() should simply be
 “store().”
>>> 
>>>   store() -> store(local)
>>>   aggregate() -> store(global)
>>> 
>>> Or:
>>> 
>>>   aggregate() ->  barrier().store()
>>> 
>>> Random thoughts…
>>> 
>>> Marko.
>>> 
>>> http://markorodriguez.com
>>> 
>>> 
>>> 
>>> 
>> 
>> --
>> Jean-Baptiste
>> 
> 
 
 
 --
 Jean-Baptiste
 
>>> 
>> 
>> 
>> 
>> -- 
>> Robert Dale
> 

[jira] [Created] (TINKERPOP-1553) AggregateStep should go away in favor of StoreStep.NoOpBarrierStep

[Marko A. Rodriguez (JIRA)]

Marko A. Rodriguez created TINKERPOP-1553:
-

 Summary: AggregateStep should go away in favor of 
StoreStep.NoOpBarrierStep
 Key: TINKERPOP-1553
 URL: https://issues.apache.org/jira/browse/TINKERPOP-1553
 Project: TinkerPop
  Issue Type: Improvement
  Components: process
Affects Versions: 3.2.3
Reporter: Marko A. Rodriguez


`AggregateStep` can be expressed as `StoreStep.NoOpBarrierStep`. There is no 
reason to have the extra logic if we don't need it.

That is:

{code}
aggregate('a') => store('a').barrier()
{code}

Next, we should get rid of {{aggregate()}} and have two methods:

{code}
store(global,'a') => store('a').barrier()
store(local,'a') => store('a')
{code}

If you are storing global that means you are storing every traverser up to the 
current step. Likewise, store local would only store the current traverser.

Here is the crappy thing. All of our {{xxx(Scope)}} steps default to 
{{Scope.global}}: {{range()}}, {{tail()}}, {{count()}}...

We should probably keep the same pattern of {{Scope.global}} default, but then 
that means that we would have a breaking change in the API.

{code}
store("a") -would-change-to-> store(local,"a")
{code}

We should have a {{storeV3d0()}} backward compatibility which would simply use 
{{store(local,"a")}}. 



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

[jira] [Commented] (TINKERPOP-1443) Use an API checker during build

[ASF GitHub Bot (JIRA)]

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

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

Github user dkuppitz commented on the issue:

https://github.com/apache/tinkerpop/pull/494
  
> the `ImmutablePath` method changes are internal changes

I think that's the point. It would have been an internal change if the 
methods were internal, but they're public. We can assume that people never used 
it directly, but we won't know. Maybe someone out there added a TinkerPop 
dependency in his project, because he liked the `ImmutablePath` implementation, 
but nothing else (you know, like "let's add Apache Commons, they have a nice 
method in `StringUtils`").

Hence, if we need to touch public method in a public class: deprecate them 
and remove/change them in the next major release.


> Use an API checker during build
> ---
>
> Key: TINKERPOP-1443
> URL: https://issues.apache.org/jira/browse/TINKERPOP-1443
> Project: TinkerPop
>  Issue Type: Improvement
>  Components: build-release
>Affects Versions: 3.2.2
>Reporter: Lukas Krejci
>
> Tinkerpop 3.2.2 changed the signature of the method 
> {{GraphTraversal.hasLabel}} from {{(String...)}} to {{(String, String...)}}. 
> While this is certainly an improvement, it is both source and binary 
> incompatible change.
> I.e. even if every usage of {{hasLabel}} had at least one parameter in the 
> user code, none of those calls will work until all the user code is 
> recompiled using Tinkerpop 3.2.2.
> I don't know the versioning policy of Tinkerpop but changes like the above in 
> a micro/patch release are generally unexpected.
> Please consider API checkers like http://revapi.org to warn about such 
> incompatible API changes...



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

[GitHub] tinkerpop issue #494: TINKERPOP-1443 - Introduce API check into the build

[dkuppitz]

Github user dkuppitz commented on the issue:

https://github.com/apache/tinkerpop/pull/494
  
> the `ImmutablePath` method changes are internal changes

I think that's the point. It would have been an internal change if the 
methods were internal, but they're public. We can assume that people never used 
it directly, but we won't know. Maybe someone out there added a TinkerPop 
dependency in his project, because he liked the `ImmutablePath` implementation, 
but nothing else (you know, like "let's add Apache Commons, they have a nice 
method in `StringUtils`").

Hence, if we need to touch public method in a public class: deprecate them 
and remove/change them in the next major release.


---
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] tinkerpop issue #494: TINKERPOP-1443 - Introduce API check into the build

[metlos]

Github user metlos commented on the issue:

https://github.com/apache/tinkerpop/pull/494
  
Yes, Java makes it somewhat difficult to properly declare "module 
boundaries" - let's hope Java 9 will do that right.

But for now, it is often useful to declare certain packages as internal and 
not consider any changes in them as "user-facing". As shown with 
`org.apache.tinkerpop.shaded`, it is quite easy to exclude packages from the 
API check with Revapi.

If the internal and API classes are mixed within a single package, we could 
also annotate the internal classes with some dedicated annotation - let's say 
`org.apache.tinkerpop.Internal` and configure Revapi to ignore anything 
annotated with that annotation. Revapi can also be configured to just ignore 
certain classes but that's slightly more involved, because you'd need to modify 
the POM each time you add an internal class (as opposed to just annotating the 
class).


---
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-1443) Use an API checker during build

[ASF GitHub Bot (JIRA)]

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

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

Github user metlos commented on the issue:

https://github.com/apache/tinkerpop/pull/494
  
Yes, Java makes it somewhat difficult to properly declare "module 
boundaries" - let's hope Java 9 will do that right.

But for now, it is often useful to declare certain packages as internal and 
not consider any changes in them as "user-facing". As shown with 
`org.apache.tinkerpop.shaded`, it is quite easy to exclude packages from the 
API check with Revapi.

If the internal and API classes are mixed within a single package, we could 
also annotate the internal classes with some dedicated annotation - let's say 
`org.apache.tinkerpop.Internal` and configure Revapi to ignore anything 
annotated with that annotation. Revapi can also be configured to just ignore 
certain classes but that's slightly more involved, because you'd need to modify 
the POM each time you add an internal class (as opposed to just annotating the 
class).


> Use an API checker during build
> ---
>
> Key: TINKERPOP-1443
> URL: https://issues.apache.org/jira/browse/TINKERPOP-1443
> Project: TinkerPop
>  Issue Type: Improvement
>  Components: build-release
>Affects Versions: 3.2.2
>Reporter: Lukas Krejci
>
> Tinkerpop 3.2.2 changed the signature of the method 
> {{GraphTraversal.hasLabel}} from {{(String...)}} to {{(String, String...)}}. 
> While this is certainly an improvement, it is both source and binary 
> incompatible change.
> I.e. even if every usage of {{hasLabel}} had at least one parameter in the 
> user code, none of those calls will work until all the user code is 
> recompiled using Tinkerpop 3.2.2.
> I don't know the versioning policy of Tinkerpop but changes like the above in 
> a micro/patch release are generally unexpected.
> Please consider API checkers like http://revapi.org to warn about such 
> incompatible API changes...



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

[jira] [Commented] (TINKERPOP-1529) LazyBarrierStrategy is too agressive

[ASF GitHub Bot (JIRA)]

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

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

Github user okram commented on the issue:

https://github.com/apache/tinkerpop/pull/485
  
I do like `Traversal.metadata()`. However, I think that metadata should be 
stored at the root traversal only. Thus, its a global blackboard. Next, given 
that its an `Admin` method, it should just use standard Java method naming -- 
`Traversal.getMetadata()`, `Traversal.setMetadata()`.  If the traversal is NOT 
the root, then it walks the tree to get the metadata from the root.

If we do the metadata-thang in this ticket, we should update all the MARKER 
strategies -- AdjacentToIncident and SubgraphStrategy. (prolly some other?).

I think your `NoBarrier` work should really just be inlined into 
`LazyBarrierStragegy` and `PathRetractionStrategy`. Checkout how 
`LazyBarrierStrategy` has this notion of labeled paths and path processor ... 
its a "switch" to say whether or not to barrier.


> LazyBarrierStrategy is too agressive
> 
>
> Key: TINKERPOP-1529
> URL: https://issues.apache.org/jira/browse/TINKERPOP-1529
> Project: TinkerPop
>  Issue Type: Bug
>  Components: process
>Affects Versions: 3.2.3
>Reporter: Daniel Kuppitz
>Assignee: Daniel Kuppitz
>
> There are scenarios where {{LazyBarrierStrategy}} changes the semantics of a 
> traversal:
> {noformat}
> gremlin> g = TinkerFactory.createModern().traversal()
> ==>graphtraversalsource[tinkergraph[vertices:6 edges:6], standard]
> gremlin> g.V().store("a").out().select("a")
> ==>[v[1],v[2],v[3],v[4],v[5],v[6]]
> ==>[v[1],v[2],v[3],v[4],v[5],v[6]]
> ==>[v[1],v[2],v[3],v[4],v[5],v[6]]
> ==>[v[1],v[2],v[3],v[4],v[5],v[6]]
> ==>[v[1],v[2],v[3],v[4],v[5],v[6]]
> ==>[v[1],v[2],v[3],v[4],v[5],v[6]]
> {noformat}
> This is actually not the result of {{store()}}, this is {{aggregate()}}. The 
> expected result for {{store()}} would be:
> {noformat}
> ==>[v[1]]
> ==>[v[1]]
> ==>[v[1]]
> ==>[v[1],v[2],v[3],v[4]]
> ==>[v[1],v[2],v[3],v[4]]
> ==>[v[1],v[2],v[3],v[4],v[5],v[6]]
> {noformat}
> Another issue, which should probably go into another ticket, is this:
> {noformat}
> gremlin> 
> g.withoutStrategies(LazyBarrierStrategy).V().store("a").out().select("a")
> ==>[v[1],v[2],v[3],v[4],v[5],v[6]]
> ==>[v[1],v[2],v[3],v[4],v[5],v[6]]
> ==>[v[1],v[2],v[3],v[4],v[5],v[6]]
> {noformat}
> That's it, the console is hanging at this point. Looks like 
> {{PathRetractionStrategy}} is the remaining troublemaker. With both 
> strategies excluded, we get the expected result:
> {noformat}
> gremlin> g.withoutStrategies(LazyBarrierStrategy, 
> PathRetractionStrategy).V().store("a").out().select("a")
> ==>[v[1]]
> ==>[v[1]]
> ==>[v[1]]
> ==>[v[1],v[2],v[3],v[4]]
> ==>[v[1],v[2],v[3],v[4]]
> ==>[v[1],v[2],v[3],v[4],v[5],v[6]]
> {noformat}



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

[GitHub] tinkerpop issue #485: TINKERPOP-1529 LazyBarrierStrategy is too aggressive (...

[okram]

Github user okram commented on the issue:

https://github.com/apache/tinkerpop/pull/485
  
I do like `Traversal.metadata()`. However, I think that metadata should be 
stored at the root traversal only. Thus, its a global blackboard. Next, given 
that its an `Admin` method, it should just use standard Java method naming -- 
`Traversal.getMetadata()`, `Traversal.setMetadata()`.  If the traversal is NOT 
the root, then it walks the tree to get the metadata from the root.

If we do the metadata-thang in this ticket, we should update all the MARKER 
strategies -- AdjacentToIncident and SubgraphStrategy. (prolly some other?).

I think your `NoBarrier` work should really just be inlined into 
`LazyBarrierStragegy` and `PathRetractionStrategy`. Checkout how 
`LazyBarrierStrategy` has this notion of labeled paths and path processor ... 
its a "switch" to say whether or not to barrier.


---
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-1529) LazyBarrierStrategy is too agressive

[ASF GitHub Bot (JIRA)]

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

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

Github user okram commented on the issue:

https://github.com/apache/tinkerpop/pull/485
  
```
gremlin> g.V().barrier().store('a').sideEffect(select('a')).explain()
==>Traversal Explanation

==
Original Traversal [GraphStep(vertex,[]), NoOpBarrierStep, 
StoreStep(a), TraversalSideEffectStep([SelectOneStep(a)])]

ConnectiveStrategy   [D]   [GraphStep(vertex,[]), NoOpBarrierStep, 
StoreStep(a), TraversalSideEffectStep([SelectOneStep(a)])]
NoBarrierStrategy[O]   [GraphStep(vertex,[]), NoOpBarrierStep, 
StoreStep(a), TraversalSideEffectStep([SelectOneStep(a)])]
RepeatUnrollStrategy [O]   [GraphStep(vertex,[]), NoOpBarrierStep, 
StoreStep(a), TraversalSideEffectStep([SelectOneStep(a)])]
MatchPredicateStrategy   [O]   [GraphStep(vertex,[]), NoOpBarrierStep, 
StoreStep(a), TraversalSideEffectStep([SelectOneStep(a)])]
PathRetractionStrategy   [O]   [GraphStep(vertex,[]), NoOpBarrierStep, 
StoreStep(a), TraversalSideEffectStep([SelectOneStep(a), 
NoOpBarrierStep(2500)])]
InlineFilterStrategy [O]   [GraphStep(vertex,[]), NoOpBarrierStep, 
StoreStep(a), TraversalSideEffectStep([SelectOneStep(a), 
NoOpBarrierStep(2500)])]
IncidentToAdjacentStrategy   [O]   [GraphStep(vertex,[]), NoOpBarrierStep, 
StoreStep(a), TraversalSideEffectStep([SelectOneStep(a), 
NoOpBarrierStep(2500)])]
AdjacentToIncidentStrategy   [O]   [GraphStep(vertex,[]), NoOpBarrierStep, 
StoreStep(a), TraversalSideEffectStep([SelectOneStep(a), 
NoOpBarrierStep(2500)])]
FilterRankingStrategy[O]   [GraphStep(vertex,[]), NoOpBarrierStep, 
StoreStep(a), TraversalSideEffectStep([SelectOneStep(a), 
NoOpBarrierStep(2500)])]
RangeByIsCountStrategy   [O]   [GraphStep(vertex,[]), NoOpBarrierStep, 
StoreStep(a), TraversalSideEffectStep([SelectOneStep(a), 
NoOpBarrierStep(2500)])]
LazyBarrierStrategy  [O]   [GraphStep(vertex,[]), NoOpBarrierStep, 
StoreStep(a), TraversalSideEffectStep([SelectOneStep(a), 
NoOpBarrierStep(2500)])]
TinkerGraphCountStrategy [P]   [GraphStep(vertex,[]), NoOpBarrierStep, 
StoreStep(a), TraversalSideEffectStep([SelectOneStep(a), 
NoOpBarrierStep(2500)])]
TinkerGraphStepStrategy  [P]   [TinkerGraphStep(vertex,[]), 
NoOpBarrierStep, StoreStep(a), TraversalSideEffectStep([SelectOneStep(a), 
NoOpBarrierStep(2500)])]
ProfileStrategy  [F]   [TinkerGraphStep(vertex,[]), 
NoOpBarrierStep, StoreStep(a), TraversalSideEffectStep([SelectOneStep(a), 
NoOpBarrierStep(2500)])]
StandardVerificationStrategy [V]   [TinkerGraphStep(vertex,[]), 
NoOpBarrierStep, StoreStep(a), TraversalSideEffectStep([SelectOneStep(a), 
NoOpBarrierStep(2500)])]

Final Traversal[TinkerGraphStep(vertex,[]), 
NoOpBarrierStep, StoreStep(a), TraversalSideEffectStep([SelectOneStep(a), 
NoOpBarrierStep(2500)])]
gremlin>
```
`NoBarrierStep` doesn't seem to do anything ?


> LazyBarrierStrategy is too agressive
> 
>
> Key: TINKERPOP-1529
> URL: https://issues.apache.org/jira/browse/TINKERPOP-1529
> Project: TinkerPop
>  Issue Type: Bug
>  Components: process
>Affects Versions: 3.2.3
>Reporter: Daniel Kuppitz
>Assignee: Daniel Kuppitz
>
> There are scenarios where {{LazyBarrierStrategy}} changes the semantics of a 
> traversal:
> {noformat}
> gremlin> g = TinkerFactory.createModern().traversal()
> ==>graphtraversalsource[tinkergraph[vertices:6 edges:6], standard]
> gremlin> g.V().store("a").out().select("a")
> ==>[v[1],v[2],v[3],v[4],v[5],v[6]]
> ==>[v[1],v[2],v[3],v[4],v[5],v[6]]
> ==>[v[1],v[2],v[3],v[4],v[5],v[6]]
> ==>[v[1],v[2],v[3],v[4],v[5],v[6]]
> ==>[v[1],v[2],v[3],v[4],v[5],v[6]]
> ==>[v[1],v[2],v[3],v[4],v[5],v[6]]
> {noformat}
> This is actually not the result of {{store()}}, this is {{aggregate()}}. The 
> expected result for {{store()}} would be:
> {noformat}
> ==>[v[1]]
> ==>[v[1]]
> ==>[v[1]]
> ==>[v[1],v[2],v[3],v[4]]
> ==>[v[1],v[2],v[3],v[4]]
> ==>[v[1],v[2],v[3],v[4],v[5],v[6]]
> {noformat}
> Another issue, which should probably go into another ticket, is this:
> {noformat}
> gremlin> 
> g.withoutStrategies(LazyBarrierStrategy).V().store("a").out().select("a")
> ==>[v[1],v[2],v[3],v[4],v[5],v[6]]
> ==>[v[1],v[2],v[3],v[4],v[5],v[6]]
> ==>[v[1],v[2],v[3],v[4],v[5],v[6]]
> {noformat}
> That's it, the console is hanging at this point. Looks like 
> {{PathRetractionStrategy}} is the remaining troublemaker. With both 

[GitHub] tinkerpop issue #485: TINKERPOP-1529 LazyBarrierStrategy is too aggressive (...

[okram]

Github user okram commented on the issue:

https://github.com/apache/tinkerpop/pull/485
  
```
gremlin> g.V().barrier().store('a').sideEffect(select('a')).explain()
==>Traversal Explanation

==
Original Traversal [GraphStep(vertex,[]), NoOpBarrierStep, 
StoreStep(a), TraversalSideEffectStep([SelectOneStep(a)])]

ConnectiveStrategy   [D]   [GraphStep(vertex,[]), NoOpBarrierStep, 
StoreStep(a), TraversalSideEffectStep([SelectOneStep(a)])]
NoBarrierStrategy[O]   [GraphStep(vertex,[]), NoOpBarrierStep, 
StoreStep(a), TraversalSideEffectStep([SelectOneStep(a)])]
RepeatUnrollStrategy [O]   [GraphStep(vertex,[]), NoOpBarrierStep, 
StoreStep(a), TraversalSideEffectStep([SelectOneStep(a)])]
MatchPredicateStrategy   [O]   [GraphStep(vertex,[]), NoOpBarrierStep, 
StoreStep(a), TraversalSideEffectStep([SelectOneStep(a)])]
PathRetractionStrategy   [O]   [GraphStep(vertex,[]), NoOpBarrierStep, 
StoreStep(a), TraversalSideEffectStep([SelectOneStep(a), 
NoOpBarrierStep(2500)])]
InlineFilterStrategy [O]   [GraphStep(vertex,[]), NoOpBarrierStep, 
StoreStep(a), TraversalSideEffectStep([SelectOneStep(a), 
NoOpBarrierStep(2500)])]
IncidentToAdjacentStrategy   [O]   [GraphStep(vertex,[]), NoOpBarrierStep, 
StoreStep(a), TraversalSideEffectStep([SelectOneStep(a), 
NoOpBarrierStep(2500)])]
AdjacentToIncidentStrategy   [O]   [GraphStep(vertex,[]), NoOpBarrierStep, 
StoreStep(a), TraversalSideEffectStep([SelectOneStep(a), 
NoOpBarrierStep(2500)])]
FilterRankingStrategy[O]   [GraphStep(vertex,[]), NoOpBarrierStep, 
StoreStep(a), TraversalSideEffectStep([SelectOneStep(a), 
NoOpBarrierStep(2500)])]
RangeByIsCountStrategy   [O]   [GraphStep(vertex,[]), NoOpBarrierStep, 
StoreStep(a), TraversalSideEffectStep([SelectOneStep(a), 
NoOpBarrierStep(2500)])]
LazyBarrierStrategy  [O]   [GraphStep(vertex,[]), NoOpBarrierStep, 
StoreStep(a), TraversalSideEffectStep([SelectOneStep(a), 
NoOpBarrierStep(2500)])]
TinkerGraphCountStrategy [P]   [GraphStep(vertex,[]), NoOpBarrierStep, 
StoreStep(a), TraversalSideEffectStep([SelectOneStep(a), 
NoOpBarrierStep(2500)])]
TinkerGraphStepStrategy  [P]   [TinkerGraphStep(vertex,[]), 
NoOpBarrierStep, StoreStep(a), TraversalSideEffectStep([SelectOneStep(a), 
NoOpBarrierStep(2500)])]
ProfileStrategy  [F]   [TinkerGraphStep(vertex,[]), 
NoOpBarrierStep, StoreStep(a), TraversalSideEffectStep([SelectOneStep(a), 
NoOpBarrierStep(2500)])]
StandardVerificationStrategy [V]   [TinkerGraphStep(vertex,[]), 
NoOpBarrierStep, StoreStep(a), TraversalSideEffectStep([SelectOneStep(a), 
NoOpBarrierStep(2500)])]

Final Traversal[TinkerGraphStep(vertex,[]), 
NoOpBarrierStep, StoreStep(a), TraversalSideEffectStep([SelectOneStep(a), 
NoOpBarrierStep(2500)])]
gremlin>
```
`NoBarrierStep` doesn't seem to do anything ?


---
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-1443) Use an API checker during build

[ASF GitHub Bot (JIRA)]

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

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

Github user okram commented on the issue:

https://github.com/apache/tinkerpop/pull/494
  
I think we will need to decide what is considered NOT subject to change and 
what is subject to change. For example, the `ImmutablePath` method changes are 
internal changes that are "okay." Perhaps we can come up with a list of what 
packages we CAN'T change on minor releases?


> Use an API checker during build
> ---
>
> Key: TINKERPOP-1443
> URL: https://issues.apache.org/jira/browse/TINKERPOP-1443
> Project: TinkerPop
>  Issue Type: Improvement
>  Components: build-release
>Affects Versions: 3.2.2
>Reporter: Lukas Krejci
>
> Tinkerpop 3.2.2 changed the signature of the method 
> {{GraphTraversal.hasLabel}} from {{(String...)}} to {{(String, String...)}}. 
> While this is certainly an improvement, it is both source and binary 
> incompatible change.
> I.e. even if every usage of {{hasLabel}} had at least one parameter in the 
> user code, none of those calls will work until all the user code is 
> recompiled using Tinkerpop 3.2.2.
> I don't know the versioning policy of Tinkerpop but changes like the above in 
> a micro/patch release are generally unexpected.
> Please consider API checkers like http://revapi.org to warn about such 
> incompatible API changes...



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

[GitHub] tinkerpop issue #494: TINKERPOP-1443 - Introduce API check into the build

[okram]

Github user okram commented on the issue:

https://github.com/apache/tinkerpop/pull/494
  
I think we will need to decide what is considered NOT subject to change and 
what is subject to change. For example, the `ImmutablePath` method changes are 
internal changes that are "okay." Perhaps we can come up with a list of what 
packages we CAN'T change on minor releases?


---
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] tinkerpop issue #495: TINKERPOP-1502 & TINKERPOP-1482: Chained has-container...

[dkuppitz]

Github user dkuppitz commented on the issue:

https://github.com/apache/tinkerpop/pull/495
  
Since this PR touches `FilterRankingStrategyTest`s, it would be nice to 
have this issue fixed as well (and have some tests added to cover this 
scenario):

```
gremlin> g = TinkerFactory.createModern().traversal()
==>graphtraversalsource[tinkergraph[vertices:6 edges:6], standard]
gremlin> g.V(1).as("a").both().both().has("age").where(neq("a")).by("age")
The property does not exist as the key has no associated value for the 
provided element: v[5]:age
Type ':help' or ':h' for help.
Display stack trace? [yN]N
gremlin> 
g.V(1).as("a").both().both().has("age").where(neq("a")).by("age").explain()
==>Traversal Explanation

===
Original Traversal [GraphStep(vertex,[1])@[a], 
VertexStep(BOTH,vertex), VertexStep(BOTH,vertex), 
TraversalFilterStep([PropertiesStep([age],value)]), 
WherePredicateStep(neq(a),[value(age)])]
...
FilterRankingStrategy[O]   [GraphStep(vertex,[1])@[a], 
VertexStep(BOTH,vertex), VertexStep(BOTH,vertex), 
WherePredicateStep(neq(a),[value(age)]), 
TraversalFilterStep([PropertiesStep([age],value)])]
...
Final Traversal[TinkerGraphStep(vertex,[1])@[a], 
VertexStep(BOTH,vertex), VertexStep(BOTH,vertex), 
WherePredicateStep(neq(a),[value(age)]), NoOpBarrierStep(2500), 
TraversalFilterStep([PropertiesStep([age],property)])]
```


---
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-1502) Chained has()-steps should simply left-append HasContainers in Gremlin-Java.

[ASF GitHub Bot (JIRA)]

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

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

Github user okram commented on the issue:

https://github.com/apache/tinkerpop/pull/495
  
We could. However, its such a rare situation  too much 
optimization?


> Chained has()-steps should simply left-append HasContainers in Gremlin-Java.
> 
>
> Key: TINKERPOP-1502
> URL: https://issues.apache.org/jira/browse/TINKERPOP-1502
> Project: TinkerPop
>  Issue Type: Improvement
>  Components: process
>Affects Versions: 3.2.2
>Reporter: Marko A. Rodriguez
>
> In Gremlin-Java, {{g.V().has(a).has(b).has(c).out()}} is originally 
> represented as {{[GraphStep,HasStep(a),HasStep(b),HasStep(c),VertexStep]}}. 
> Ultimately, {{InlineFilterStrategy}} or most provider strategies will turn 
> such {{HasStep}}-chains into {{[GraphStep,HasStep(a,b,c),VertexStep]}}. That 
> is, strategies fold {{has()}}-steps "left" and delete "right" {{has()}}-steps 
> and left propagates their labels (i.e. clock cycles). I think that 
> {{GraphTraversal}} should simply do this:
> {code}
> public GraphTraversal has(whateves) {
>   if(this.getEndStep() instanceof HasStep)
> this.getEndSte().addHasContainer(new HasContainer(whateves))
>   else
> this.addStep(new HasStep(new HasContainer(whateves)));
>   this.bytecode.addStep("has",whateves);
>   return this;
> }
> {code}
> In essence, a "write time" optimization can be done. Given that chains of 
> {{has()}}'s is super common, this can save significant clock-cycles in the 
> long run of a production application.



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

[GitHub] tinkerpop issue #495: TINKERPOP-1502 & TINKERPOP-1482: Chained has-container...

[okram]

Github user okram commented on the issue:

https://github.com/apache/tinkerpop/pull/495
  
We could. However, its such a rare situation  too much 
optimization?


---
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-1502) Chained has()-steps should simply left-append HasContainers in Gremlin-Java.

[ASF GitHub Bot (JIRA)]

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

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

Github user dkuppitz commented on the issue:

https://github.com/apache/tinkerpop/pull/495
  
Yea, looks better now. Not sure if we should really keep all the steps in 
`g.V(1).outE('knows').hasLabel('created').more().bla()`. It's like the Java 
compiler would keep stuff within a `if (false) { ... }` block. The static 
analysis already tells us, that nothing will make it through the filter.

You already treat this particular case in a dedicated code block, why not 
remove everything that comes after it and append a `.not(identity())`?


> Chained has()-steps should simply left-append HasContainers in Gremlin-Java.
> 
>
> Key: TINKERPOP-1502
> URL: https://issues.apache.org/jira/browse/TINKERPOP-1502
> Project: TinkerPop
>  Issue Type: Improvement
>  Components: process
>Affects Versions: 3.2.2
>Reporter: Marko A. Rodriguez
>
> In Gremlin-Java, {{g.V().has(a).has(b).has(c).out()}} is originally 
> represented as {{[GraphStep,HasStep(a),HasStep(b),HasStep(c),VertexStep]}}. 
> Ultimately, {{InlineFilterStrategy}} or most provider strategies will turn 
> such {{HasStep}}-chains into {{[GraphStep,HasStep(a,b,c),VertexStep]}}. That 
> is, strategies fold {{has()}}-steps "left" and delete "right" {{has()}}-steps 
> and left propagates their labels (i.e. clock cycles). I think that 
> {{GraphTraversal}} should simply do this:
> {code}
> public GraphTraversal has(whateves) {
>   if(this.getEndStep() instanceof HasStep)
> this.getEndSte().addHasContainer(new HasContainer(whateves))
>   else
> this.addStep(new HasStep(new HasContainer(whateves)));
>   this.bytecode.addStep("has",whateves);
>   return this;
> }
> {code}
> In essence, a "write time" optimization can be done. Given that chains of 
> {{has()}}'s is super common, this can save significant clock-cycles in the 
> long run of a production application.



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

[GitHub] tinkerpop issue #495: TINKERPOP-1502 & TINKERPOP-1482: Chained has-container...

[dkuppitz]

Github user dkuppitz commented on the issue:

https://github.com/apache/tinkerpop/pull/495
  
Yea, looks better now. Not sure if we should really keep all the steps in 
`g.V(1).outE('knows').hasLabel('created').more().bla()`. It's like the Java 
compiler would keep stuff within a `if (false) { ... }` block. The static 
analysis already tells us, that nothing will make it through the filter.

You already treat this particular case in a dedicated code block, why not 
remove everything that comes after it and append a `.not(identity())`?


---
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: [DISCUSS] Speeding up the build - spark-gremlin

[Stephen Mallette]

Just wanted to point out that this change has been implemented and simple
"mvn clean install" runs are much faster for it. I'll keep looking for
additional changes we can make, but the build time is semi-reasonably now
on my system. It would be nice to be solidly in that 10-15 minute spot
without appreciable loss of coverage, so I'll see what else might be done
to get us there.

On Fri, Oct 28, 2016 at 2:43 PM, Stephen Mallette 
wrote:

> I've done a few runs of our coverage reports this morning with different
> configurations trying to analyze the effect spark-gremlin has on our test
> coverage. Why spark-gremlin? Because it takes about 50% of our build time
> right now and, as such, seemed like a good place to start thinking about
> how to make improvements to test performance. I didn't not run "integration
> tests" in any of my analysis, as I'm mostly interested in figuring out how
> to make "unit tests" faster without losing basic coverage there.
>
> Some things I noted:
>
> + spark-gremlin unit tests offer good coverage of spark-gremlin itself at
> about 72% line coverage and 76% branch coverage
> + the tests on spark-gremlin only add about 3% more branch coverage and 2%
> more line coverage to gremlin-core. I'm not sure what I expected to find,
> but that seems pretty small to me.
> + Removing the groovy or java "process suite" makes almost no difference
> in coverage - less than 1%
> + The longest run tests are the spark "io" tests,
> SparkGraphComputerProcessTest and SparkGraphComputerGroovyProcessTest.
>
> Marko, I think you would be best to speak to the implications of this
> suggestion, but if we make these longer run tests in gremlin-spark into
> integration tests we cut the speed of the build by roughly 40%. If we do
> that we sacrifice the minimal coverage we get in gremlin-core and our
> overall coverage of spark-gremlin drops by only 3% on lines of code and
> about 7% on branch coverage, so there is not a lot of loss there.
>
> If a change goes into gremlin-core, then it would be smart to run: "mvn
> clean install && mvn verify -pl gremlin-spark
> -DskipIntegrationTests=false". we would look to catch that in pull requests
> during code review.
>
> If we go with this approach, I could do some further analysis on
> spark-gremlin and determine if some new tests could be added to gain back
> the lost coverage via unit tests (that I presume will require mocking) so
> that we can get those few percentage points back (and maybe more).
>
> Anyway, I'll assume lazy consensus on this in 72 hours (Monday, October
> 31, 2016, 2:30pm) and move forward if there are no objections.
>
>
>
>
>
>

[jira] [Commented] (TINKERPOP-1502) Chained has()-steps should simply left-append HasContainers in Gremlin-Java.

[ASF GitHub Bot (JIRA)]

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

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

Github user dkuppitz commented on the issue:

https://github.com/apache/tinkerpop/pull/495
  
Alright, looks like I pulled too early, just got some more changes coming 
through. I will retest the latest.


> Chained has()-steps should simply left-append HasContainers in Gremlin-Java.
> 
>
> Key: TINKERPOP-1502
> URL: https://issues.apache.org/jira/browse/TINKERPOP-1502
> Project: TinkerPop
>  Issue Type: Improvement
>  Components: process
>Affects Versions: 3.2.2
>Reporter: Marko A. Rodriguez
>
> In Gremlin-Java, {{g.V().has(a).has(b).has(c).out()}} is originally 
> represented as {{[GraphStep,HasStep(a),HasStep(b),HasStep(c),VertexStep]}}. 
> Ultimately, {{InlineFilterStrategy}} or most provider strategies will turn 
> such {{HasStep}}-chains into {{[GraphStep,HasStep(a,b,c),VertexStep]}}. That 
> is, strategies fold {{has()}}-steps "left" and delete "right" {{has()}}-steps 
> and left propagates their labels (i.e. clock cycles). I think that 
> {{GraphTraversal}} should simply do this:
> {code}
> public GraphTraversal has(whateves) {
>   if(this.getEndStep() instanceof HasStep)
> this.getEndSte().addHasContainer(new HasContainer(whateves))
>   else
> this.addStep(new HasStep(new HasContainer(whateves)));
>   this.bytecode.addStep("has",whateves);
>   return this;
> }
> {code}
> In essence, a "write time" optimization can be done. Given that chains of 
> {{has()}}'s is super common, this can save significant clock-cycles in the 
> long run of a production application.



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

[GitHub] tinkerpop issue #495: TINKERPOP-1502 & TINKERPOP-1482: Chained has-container...

[dkuppitz]

Github user dkuppitz commented on the issue:

https://github.com/apache/tinkerpop/pull/495
  
Alright, looks like I pulled too early, just got some more changes coming 
through. I will retest the latest.


---
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-1502) Chained has()-steps should simply left-append HasContainers in Gremlin-Java.

[ASF GitHub Bot (JIRA)]

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

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

Github user okram commented on the issue:

https://github.com/apache/tinkerpop/pull/495
  
What you have in your examples is the "bug" that is fixed in this PR:

```
gremlin> g.V(1).outE('knows').hasLabel('created')
gremlin>
```

Likewise:

```
gremlin> g.V(1).outE().hasLabel("knows").hasLabel("created")
gremlin>
```

```
gremlin> g.V(1).outE().hasLabel("knows")
==>e[7][1-knows->2]
==>e[8][1-knows->4]
gremlin> g.V(1).outE().hasLabel("knows").explain()
==>Traversal Explanation

=
Original Traversal [GraphStep(vertex,[1]), 
VertexStep(OUT,edge), HasStep([~label.eq(knows)])]
...
InlineFilterStrategy [O]   [GraphStep(vertex,[1]), 
VertexStep(OUT,[knows],edge)]
...
Final Traversal[TinkerGraphStep(vertex,[1]), 
VertexStep(OUT,[knows],edge)]
gremlin>
```


> Chained has()-steps should simply left-append HasContainers in Gremlin-Java.
> 
>
> Key: TINKERPOP-1502
> URL: https://issues.apache.org/jira/browse/TINKERPOP-1502
> Project: TinkerPop
>  Issue Type: Improvement
>  Components: process
>Affects Versions: 3.2.2
>Reporter: Marko A. Rodriguez
>
> In Gremlin-Java, {{g.V().has(a).has(b).has(c).out()}} is originally 
> represented as {{[GraphStep,HasStep(a),HasStep(b),HasStep(c),VertexStep]}}. 
> Ultimately, {{InlineFilterStrategy}} or most provider strategies will turn 
> such {{HasStep}}-chains into {{[GraphStep,HasStep(a,b,c),VertexStep]}}. That 
> is, strategies fold {{has()}}-steps "left" and delete "right" {{has()}}-steps 
> and left propagates their labels (i.e. clock cycles). I think that 
> {{GraphTraversal}} should simply do this:
> {code}
> public GraphTraversal has(whateves) {
>   if(this.getEndStep() instanceof HasStep)
> this.getEndSte().addHasContainer(new HasContainer(whateves))
>   else
> this.addStep(new HasStep(new HasContainer(whateves)));
>   this.bytecode.addStep("has",whateves);
>   return this;
> }
> {code}
> In essence, a "write time" optimization can be done. Given that chains of 
> {{has()}}'s is super common, this can save significant clock-cycles in the 
> long run of a production application.



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

[jira] [Commented] (TINKERPOP-1502) Chained has()-steps should simply left-append HasContainers in Gremlin-Java.

[ASF GitHub Bot (JIRA)]

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

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

Github user dkuppitz commented on the issue:

https://github.com/apache/tinkerpop/pull/495
  
```
gremlin> g.V(1).outE("knows")
==>e[7][1-knows->2]
==>e[8][1-knows->4]
gremlin> g.V(1).outE("knows").hasLabel("created")
==>e[9][1-created->3]
```

This is still wrong. No `knows` edge will have a `created` label. The 
result should be empty. Furthermore I think that this is wrong:

```
gremlin> g.V(1).outE().hasLabel("knows").hasLabel("created")
==>e[7][1-knows->2]
==>e[8][1-knows->4]
==>e[9][1-created->3]
```

It should all boil down to `hasLabel(eq("knows").and(eq("created")))` / 
`has(label, eq("knows").and(eq("created")))`. Chained `has()` calls are / 
should be `and()`'ed, not `or()`'ed.


> Chained has()-steps should simply left-append HasContainers in Gremlin-Java.
> 
>
> Key: TINKERPOP-1502
> URL: https://issues.apache.org/jira/browse/TINKERPOP-1502
> Project: TinkerPop
>  Issue Type: Improvement
>  Components: process
>Affects Versions: 3.2.2
>Reporter: Marko A. Rodriguez
>
> In Gremlin-Java, {{g.V().has(a).has(b).has(c).out()}} is originally 
> represented as {{[GraphStep,HasStep(a),HasStep(b),HasStep(c),VertexStep]}}. 
> Ultimately, {{InlineFilterStrategy}} or most provider strategies will turn 
> such {{HasStep}}-chains into {{[GraphStep,HasStep(a,b,c),VertexStep]}}. That 
> is, strategies fold {{has()}}-steps "left" and delete "right" {{has()}}-steps 
> and left propagates their labels (i.e. clock cycles). I think that 
> {{GraphTraversal}} should simply do this:
> {code}
> public GraphTraversal has(whateves) {
>   if(this.getEndStep() instanceof HasStep)
> this.getEndSte().addHasContainer(new HasContainer(whateves))
>   else
> this.addStep(new HasStep(new HasContainer(whateves)));
>   this.bytecode.addStep("has",whateves);
>   return this;
> }
> {code}
> In essence, a "write time" optimization can be done. Given that chains of 
> {{has()}}'s is super common, this can save significant clock-cycles in the 
> long run of a production application.



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

[GitHub] tinkerpop issue #495: TINKERPOP-1502 & TINKERPOP-1482: Chained has-container...

[dkuppitz]

Github user dkuppitz commented on the issue:

https://github.com/apache/tinkerpop/pull/495
  
```
gremlin> g.V(1).outE("knows")
==>e[7][1-knows->2]
==>e[8][1-knows->4]
gremlin> g.V(1).outE("knows").hasLabel("created")
==>e[9][1-created->3]
```

This is still wrong. No `knows` edge will have a `created` label. The 
result should be empty. Furthermore I think that this is wrong:

```
gremlin> g.V(1).outE().hasLabel("knows").hasLabel("created")
==>e[7][1-knows->2]
==>e[8][1-knows->4]
==>e[9][1-created->3]
```

It should all boil down to `hasLabel(eq("knows").and(eq("created")))` / 
`has(label, eq("knows").and(eq("created")))`. Chained `has()` calls are / 
should be `and()`'ed, not `or()`'ed.


---
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] tinkerpop issue #457: TINKERPOP-1493 Groovy project doesn't build on Windows

[spmallette]

Github user spmallette commented on the issue:

https://github.com/apache/tinkerpop/pull/457
  
```text
$ sestatus -v
SELinux status: disabled
```


---
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-1493) Groovy project doesn't build on Windows

[ASF GitHub Bot (JIRA)]

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

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

Github user spmallette commented on the issue:

https://github.com/apache/tinkerpop/pull/457
  
```text
$ sestatus -v
SELinux status: disabled
```


> Groovy project doesn't build on Windows
> ---
>
> Key: TINKERPOP-1493
> URL: https://issues.apache.org/jira/browse/TINKERPOP-1493
> Project: TinkerPop
>  Issue Type: Bug
>  Components: groovy
>Affects Versions: 3.2.2
>Reporter: Paul Jackson
>Assignee: Jason Plurad
>Priority: Minor
>
> Builds on Windows fail for two reasons. First the line to create extTestDir 
> is creating a path consisting of two full paths concatenated together. The 
> second drive letter is seen as an illegal character:
> {code}private static final File extTestDir = new 
> File(System.getProperty("user.dir"), 
> TestHelper.makeTestDataDirectory(DependencyGrabberTest.class));{code}
> Second, when it comes time to delete the directory it is locked. This is 
> because some instances of JarFile are created on it but not closed.



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

Re: [GitHub] tinkerpop issue #457: TINKERPOP-1493 Groovy project doesn't build on Windows

[Robert Dale]

It's common these days to be enabled by default.  Try: sestatus

Robert Dale

On Tue, Nov 15, 2016 at 10:53 AM, spmallette  wrote:

> Github user spmallette commented on the issue:
>
> https://github.com/apache/tinkerpop/pull/457
>
> i didn't think so. I purposely didn't turn anything on that I know of.
>
>
> ---
> 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-1493) Groovy project doesn't build on Windows

[ASF GitHub Bot (JIRA)]

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

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

Github user dkuppitz commented on the issue:

https://github.com/apache/tinkerpop/pull/457
  
Btw. I don't think that this error is related to any of our components. The 
`mkdirs` problem has been reported in Docker's issue tracker several times and 
whenever they thought they solved it, someone else came up and ran into this 
issue again. I bet there's something on your system that interferes with 
Docker. SELinux has often been mentioned when this error popped up. Do you have 
any security related stuff to protect your file system?


> Groovy project doesn't build on Windows
> ---
>
> Key: TINKERPOP-1493
> URL: https://issues.apache.org/jira/browse/TINKERPOP-1493
> Project: TinkerPop
>  Issue Type: Bug
>  Components: groovy
>Affects Versions: 3.2.2
>Reporter: Paul Jackson
>Assignee: Jason Plurad
>Priority: Minor
>
> Builds on Windows fail for two reasons. First the line to create extTestDir 
> is creating a path consisting of two full paths concatenated together. The 
> second drive letter is seen as an illegal character:
> {code}private static final File extTestDir = new 
> File(System.getProperty("user.dir"), 
> TestHelper.makeTestDataDirectory(DependencyGrabberTest.class));{code}
> Second, when it comes time to delete the directory it is locked. This is 
> because some instances of JarFile are created on it but not closed.



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

[GitHub] tinkerpop issue #457: TINKERPOP-1493 Groovy project doesn't build on Windows

[dkuppitz]

Github user dkuppitz commented on the issue:

https://github.com/apache/tinkerpop/pull/457
  
Btw. I don't think that this error is related to any of our components. The 
`mkdirs` problem has been reported in Docker's issue tracker several times and 
whenever they thought they solved it, someone else came up and ran into this 
issue again. I bet there's something on your system that interferes with 
Docker. SELinux has often been mentioned when this error popped up. Do you have 
any security related stuff to protect your file system?


---
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-1493) Groovy project doesn't build on Windows

[ASF GitHub Bot (JIRA)]

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

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

Github user spmallette commented on the issue:

https://github.com/apache/tinkerpop/pull/457
  
i didn't think so. I purposely didn't turn anything on that I know of.


> Groovy project doesn't build on Windows
> ---
>
> Key: TINKERPOP-1493
> URL: https://issues.apache.org/jira/browse/TINKERPOP-1493
> Project: TinkerPop
>  Issue Type: Bug
>  Components: groovy
>Affects Versions: 3.2.2
>Reporter: Paul Jackson
>Assignee: Jason Plurad
>Priority: Minor
>
> Builds on Windows fail for two reasons. First the line to create extTestDir 
> is creating a path consisting of two full paths concatenated together. The 
> second drive letter is seen as an illegal character:
> {code}private static final File extTestDir = new 
> File(System.getProperty("user.dir"), 
> TestHelper.makeTestDataDirectory(DependencyGrabberTest.class));{code}
> Second, when it comes time to delete the directory it is locked. This is 
> because some instances of JarFile are created on it but not closed.



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

[GitHub] tinkerpop issue #457: TINKERPOP-1493 Groovy project doesn't build on Windows

[spmallette]

Github user spmallette commented on the issue:

https://github.com/apache/tinkerpop/pull/457
  
i didn't think so. I purposely didn't turn anything on that I know of.


---
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] tinkerpop issue #457: TINKERPOP-1493 Groovy project doesn't build on Windows

[dkuppitz]

Github user dkuppitz commented on the issue:

https://github.com/apache/tinkerpop/pull/457
  
Hmm, that's very unlikely. Check the output of `docker images`. The `TAG` 
column shows the Hadoop version.


---
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] tinkerpop pull request #495: TINKERPOP-1502 & TINKERPOP-1482: Chained has-co...

[okram]

GitHub user okram opened a pull request:

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

TINKERPOP-1502 & TINKERPOP-1482: Chained has-containers and AndP stringency

https://issues.apache.org/jira/browse/TINKERPOP-1502
https://issues.apache.org/jira/browse/TINKERPOP-1482

This ticket accomplishes various things around `GraphTraversal.has()`. 

1.) A write-time optimization is provided where if a `HasStep` is the 
traversal's end step, simply `HasStep.addHasContainer()`. This reduces the time 
required by `InlineFilterStrategy` and provider strategies to fold in 
`HasContainers` and remove `HasSteps`. 

2.) `GraphTraversal.hasXXX()` was tweaked by @dkuppitz a release ago. He 
used `Object` to determine numerous things like `String`, `P`, etc.  This is 
bad. We want the `GraphTraversal` API to be explicit so I added stricter 
typing: e.g. `hasLabel(String,String...)` and `hasLabel(P)`. 

3.) `HasContainer.makeHasContainers()` was a TinkerPop hack trying to help 
providers and it shouldn't be done. This method turned `AndP(x,y)` into 
individual `x` and `y` predicates so providers didn't have to analyze `AndP` 
trees.  We shouldn't do this as the provider will be getting `AndP` 
compositions elsewhere and will need to be able to handle it. I updated 
`Neo4jGraphStep` and `TinkerGraphStep` to process `AndP` predicates accordingly 
for index lookups. Added a note to upgrade docs for other providers --- simple 
update if they want to use the old "break apart `AndP`"-model.

4.) Found a bug in `InlineFilterStrategy` around `outE().hasLabel()` where 
`outE('knows').hasLabel('created')` was turned into `outE('knows','created')` 
and thus, semantically incorrect.

Going to add a few more tests before VOTING.

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

$ git pull https://github.com/apache/tinkerpop TINKERPOP-1502

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

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


commit 83f2ddb6629eab9c4dca8c4103dce60a3b8fc7a6
Author: Marko A. Rodriguez 
Date:   2016-11-14T19:54:07Z

first push on 'left-append' of has() containers.

commit d471f2d22fe0e040504ab98a1735ad9a6edaa692
Author: Marko A. Rodriguez 
Date:   2016-11-14T20:46:00Z

fixed up the hasXXX() methods to account of P and Object differently. Will 
go through and create a TraversalHelper.addHasContainer() method which will 
left append or right append depending on Traversal state. this will simplify 
methods signficiantly.

commit 07f264241fa7a1124faac27a06df83a7449b75c9
Author: Marko A. Rodriguez 
Date:   2016-11-14T22:44:40Z

added TraversalHelper.addHasContainer() which will either append a HasStep 
with container or if the traverasl ends with a HasContainerHolder, fold the 
container into the holder. This just makes the code in GraphTravesrsal cleaner 
with less copy/paste.

commit e29e1c33fddf2ea245027fe91dec882b8ffdf4d7
Author: Marko A. Rodriguez 
Date:   2016-11-15T15:27:24Z

found a bug in HasContainer.makeHasContainers() around AndP recurssion. No 
biggie, just didn't yield ultimate optimization. Found a bug in 
InlineFilterStrategy where hasLabel() should only back propagate into 
VertexStep[edges] if the step doesn't already have edge labels. Removed 
HasContainer.makeHasContainers() -- another ticket I'm putting into this 
branch. GraphTraversal.has() is fixed up accordingly with left-fold 
HasContainers and valid Object[] usage. Going to add a few more tests around 
hasXXX() steps.




---
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-1502) Chained has()-steps should simply left-append HasContainers in Gremlin-Java.

[ASF GitHub Bot (JIRA)]

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

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

GitHub user okram opened a pull request:

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

TINKERPOP-1502 & TINKERPOP-1482: Chained has-containers and AndP stringency

https://issues.apache.org/jira/browse/TINKERPOP-1502
https://issues.apache.org/jira/browse/TINKERPOP-1482

This ticket accomplishes various things around `GraphTraversal.has()`. 

1.) A write-time optimization is provided where if a `HasStep` is the 
traversal's end step, simply `HasStep.addHasContainer()`. This reduces the time 
required by `InlineFilterStrategy` and provider strategies to fold in 
`HasContainers` and remove `HasSteps`. 

2.) `GraphTraversal.hasXXX()` was tweaked by @dkuppitz a release ago. He 
used `Object` to determine numerous things like `String`, `P`, etc.  This is 
bad. We want the `GraphTraversal` API to be explicit so I added stricter 
typing: e.g. `hasLabel(String,String...)` and `hasLabel(P)`. 

3.) `HasContainer.makeHasContainers()` was a TinkerPop hack trying to help 
providers and it shouldn't be done. This method turned `AndP(x,y)` into 
individual `x` and `y` predicates so providers didn't have to analyze `AndP` 
trees.  We shouldn't do this as the provider will be getting `AndP` 
compositions elsewhere and will need to be able to handle it. I updated 
`Neo4jGraphStep` and `TinkerGraphStep` to process `AndP` predicates accordingly 
for index lookups. Added a note to upgrade docs for other providers --- simple 
update if they want to use the old "break apart `AndP`"-model.

4.) Found a bug in `InlineFilterStrategy` around `outE().hasLabel()` where 
`outE('knows').hasLabel('created')` was turned into `outE('knows','created')` 
and thus, semantically incorrect.

Going to add a few more tests before VOTING.

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

$ git pull https://github.com/apache/tinkerpop TINKERPOP-1502

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

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


commit 83f2ddb6629eab9c4dca8c4103dce60a3b8fc7a6
Author: Marko A. Rodriguez 
Date:   2016-11-14T19:54:07Z

first push on 'left-append' of has() containers.

commit d471f2d22fe0e040504ab98a1735ad9a6edaa692
Author: Marko A. Rodriguez 
Date:   2016-11-14T20:46:00Z

fixed up the hasXXX() methods to account of P and Object differently. Will 
go through and create a TraversalHelper.addHasContainer() method which will 
left append or right append depending on Traversal state. this will simplify 
methods signficiantly.

commit 07f264241fa7a1124faac27a06df83a7449b75c9
Author: Marko A. Rodriguez 
Date:   2016-11-14T22:44:40Z

added TraversalHelper.addHasContainer() which will either append a HasStep 
with container or if the traverasl ends with a HasContainerHolder, fold the 
container into the holder. This just makes the code in GraphTravesrsal cleaner 
with less copy/paste.

commit e29e1c33fddf2ea245027fe91dec882b8ffdf4d7
Author: Marko A. Rodriguez 
Date:   2016-11-15T15:27:24Z

found a bug in HasContainer.makeHasContainers() around AndP recurssion. No 
biggie, just didn't yield ultimate optimization. Found a bug in 
InlineFilterStrategy where hasLabel() should only back propagate into 
VertexStep[edges] if the step doesn't already have edge labels. Removed 
HasContainer.makeHasContainers() -- another ticket I'm putting into this 
branch. GraphTraversal.has() is fixed up accordingly with left-fold 
HasContainers and valid Object[] usage. Going to add a few more tests around 
hasXXX() steps.




> Chained has()-steps should simply left-append HasContainers in Gremlin-Java.
> 
>
> Key: TINKERPOP-1502
> URL: https://issues.apache.org/jira/browse/TINKERPOP-1502
> Project: TinkerPop
>  Issue Type: Improvement
>  Components: process
>Affects Versions: 3.2.2
>Reporter: Marko A. Rodriguez
>
> In Gremlin-Java, {{g.V().has(a).has(b).has(c).out()}} is originally 
> represented as {{[GraphStep,HasStep(a),HasStep(b),HasStep(c),VertexStep]}}. 
> Ultimately, {{InlineFilterStrategy}} or most provider strategies will turn 
> such {{HasStep}}-chains into {{[GraphStep,HasStep(a,b,c),VertexStep]}}. That 
> is, strategies fold {{has()}}-steps "left" and delete "right" {{has()}}-steps 
> and left propagates their labels (i.e. clock cycles). I think that 
> 

Cleaning up incubator references

[Robert Dale]

Created infrastructure ticket INFRA-12919

https://github.com/apache/tinkerpop
- mirrored from git://git.apache.org/incubator-tinkerpop.git

https://git.apache.org/
- Apache TinkerPop (Incubating)

https://git-wip-us.apache.org/repos/asf?p=tinkerpop.git
- description Apache TinkerPop (Incubating)

Let me know if you see anything else and I will add it to the ticket.


Robert Dale

[jira] [Closed] (TINKERPOP-1538) Gremlin Server spawned by test suites should use a different port

[stephen mallette (JIRA)]

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

stephen mallette closed TINKERPOP-1538.
---
   Resolution: Done
 Assignee: stephen mallette
Fix Version/s: 3.1.6

> Gremlin Server spawned by test suites should use a different port
> -
>
> Key: TINKERPOP-1538
> URL: https://issues.apache.org/jira/browse/TINKERPOP-1538
> Project: TinkerPop
>  Issue Type: Improvement
>  Components: server, test-suite
>Affects Versions: 3.2.3
>Reporter: Daniel Kuppitz
>Assignee: stephen mallette
> Fix For: 3.1.6
>
>
> The Gremlin Server instance spawned by test suites should use a different 
> port (if the default port is already in use). You get all kind of test 
> errors, if something else (even another Gremlin Server instance) is already 
> using the default port.



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

[GitHub] tinkerpop pull request #492: TINKERPOP-1538 [tp32]

[asfgit]

Github user asfgit closed the pull request at:

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


---
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-1538) Gremlin Server spawned by test suites should use a different port

[ASF GitHub Bot (JIRA)]

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

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

Github user asfgit closed the pull request at:

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


> Gremlin Server spawned by test suites should use a different port
> -
>
> Key: TINKERPOP-1538
> URL: https://issues.apache.org/jira/browse/TINKERPOP-1538
> Project: TinkerPop
>  Issue Type: Improvement
>  Components: server, test-suite
>Affects Versions: 3.2.3
>Reporter: Daniel Kuppitz
>
> The Gremlin Server instance spawned by test suites should use a different 
> port (if the default port is already in use). You get all kind of test 
> errors, if something else (even another Gremlin Server instance) is already 
> using the default port.



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

[GitHub] tinkerpop pull request #491: TINKERPOP-1538 Use non-default port for gremlin...

[asfgit]

Github user asfgit closed the pull request at:

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


---
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-1538) Gremlin Server spawned by test suites should use a different port

[ASF GitHub Bot (JIRA)]

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

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

Github user asfgit closed the pull request at:

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


> Gremlin Server spawned by test suites should use a different port
> -
>
> Key: TINKERPOP-1538
> URL: https://issues.apache.org/jira/browse/TINKERPOP-1538
> Project: TinkerPop
>  Issue Type: Improvement
>  Components: server, test-suite
>Affects Versions: 3.2.3
>Reporter: Daniel Kuppitz
>
> The Gremlin Server instance spawned by test suites should use a different 
> port (if the default port is already in use). You get all kind of test 
> errors, if something else (even another Gremlin Server instance) is already 
> using the default port.



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

[GitHub] tinkerpop pull request #493: TINKERPOP-1538 [master]

[asfgit]

Github user asfgit closed the pull request at:

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


---
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: GLV - Languages with no JVM support

[Jorge Bay Gondra]

Hi Florian,
I've started this thread to understand if the TinkerPop repo is the best
place for a C# GLV, now that I understand that the answer is yes, I've
created a JIRA ticket to discuss the C# GLV specifically:
https://issues.apache.org/jira/browse/TINKERPOP-1552

I'm mainly focused on having a well defined C# GLV API and serialization,
but we should also include a Gremlin Server driver. I'm interested in any
kind of collaboration: via code / reviews / improvements / ...

Thanks,
Jorge

On Mon, Nov 14, 2016 at 5:44 PM, Florian Hockmann 
wrote:

> Yes exactly, I meant that the GLV just uses a third-party driver that
> conforms to TinkerPop standards and then the driver can become part of
> TinkerPop once the GLV gets accepted. This approach would avoid the need to
> implement a new driver just for the GLV. And I just wanted to know what the
> requirements or TinkerPop standards / guidelines are, so we can evaluate
> whether an existing driver conforms to them or at least doesn't require too
> much work.
>
> Yeah, I noticed that there is still much discussion going on around the
> topic of testing GLVs. That is also why I put my efforts on hold regarding
> a C# GLV.
>
> > Those tests should produce xunit style output unless there is some good
> reason not to.
>
> Xunit is basically the default testing tool for .NET Core (it is even used
> by Microsoft instead of their own MsTest). So, that shouldn't be a problem.
>
> >4. The build/deploy process needs to be bound to maven which might be one
> of the trickier bits to deal with.
>
> I am really not a maven expert, but at least for C# this should be
> possible to do with .NET Core which is more or less supported by Travis-CI
> (in "stealth mode" only at the moment): https://github.com/travis-ci/
> travis-ci/issues/5189
> Maven would just have to execute some powershell / bash script that
> performs the .NET Core build and deployment.
>
> -Ursprüngliche Nachricht-
> Von: Stephen Mallette [mailto:spmalle...@gmail.com]
> Gesendet: Montag, 14. November 2016 17:10
> An: dev@tinkerpop.apache.org
> Betreff: Re: GLV - Languages with no JVM support
>
> > the choice is basically either to implement a new one for the GLV or
> > add
> an existing one to TinkerPop once the GLV will be added
>
> By "existing one" I assume that you mean that the GLV would include a
> third-party driver? I suppose that could happen, but the driver code would
> still have to conform to TinkerPop naming standards and patterns so I would
> bet that some significant changes would be required to that third-party
> driver - perhaps enough so that it really just looked like "implementing a
> new one".
>
> Anyway, the GLV probably wouldn't be accepted without some form of driver
> as it would be inherently incomplete. There has to be some way to connect
> the GLV to Gremlin Server as a default implementation. I'm not sure that
> we've formalize the requirements yet, but I'm sure we would evaluate any
> GLV that was submitted with the following general guidelines that have been
> discussed on this list in the past:
>
> 1. The GLV should keep in line with class/method names of the java API
> where possible to ensure consistency of feel across languages.
> 2. There needs to be adequate tests (we're still discussing the approach
> to testing GLVs and i think that needs to be tackled sooner than later as
> more GLVs start to come in). Those tests should produce xunit style output
> unless there is some good reason not to.
> 3. There needs to be adequate documentation (e.g. Reference docs) 4. The
> build/deploy process needs to be bound to maven which might be one of the
> trickier bits to deal with.
>
> This list may or may not be "complete" and is obviously quite general in
> nature, but perhaps at least summarizes some of the concerns we've
> discussed on the list in relation to new GLVs. Note that we will likely
> move slowly on bringing in a GLV as it will mean a major change to the
> TinkerPop code base. Be prepared to be patient and to rebase your PR a lot
> if you decide to submit something. :)
>
> On Mon, Nov 14, 2016 at 10:22 AM, Florian Hockmann  >
> wrote:
>
> > Ok, I didn’t know that there is already such an interface for Java.
> > That is of course a good starting point for a C# GLV. It could define
> > a similar RemoteConnection interface in C# and therefore allow users
> > to choose any driver that implements this interface.
> >
> > Regarding your point on “TinkerPop native drivers”: Since there
> > currently is no .NET driver in TinkerPop, the choice is basically
> > either to implement a new one for the GLV or add an existing one to
> > TinkerPop once the GLV will be added.
> >
> > Are there any requirements for drivers to be included in TinkerPop so
> > they can be used as a default driver by GLVs?
> >
> > -Ursprüngliche Nachricht-
> > Von: Stephen Mallette [mailto:spmalle...@gmail.com]
> > Gesendet: Montag, 14. 

[jira] [Updated] (TINKERPOP-1552) C# Gremlin Language Variant

[stephen mallette (JIRA)]

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

stephen mallette updated TINKERPOP-1552:

Affects Version/s: 3.2.3

> C# Gremlin Language Variant
> ---
>
> Key: TINKERPOP-1552
> URL: https://issues.apache.org/jira/browse/TINKERPOP-1552
> Project: TinkerPop
>  Issue Type: Improvement
>  Components: language-variant
>Affects Versions: 3.2.3
>Reporter: Jorge Bay
>
> It would be nice to have a C# GLV that runs under .NET Framework 4.5+ and 
> .NET Core.
> The maven build could use the Exec Maven Plugin to exec .NET Core's [dotnet 
> test|https://www.microsoft.com/net/core#macos] command.
> Some requirements, from the mailing list (edited):
> {quote}
> 1. The GLV should keep in line with class/method names of the java API
> where possible to ensure consistency of feel across languages.
> 2. There needs to be adequate tests (we're still discussing the approach to
> testing GLVs and i think that needs to be tackled sooner than later as more
> GLVs start to come in). Those tests should produce xunit style output
> unless there is some good reason not to.
> 3. There needs to be adequate documentation (e.g. Reference docs)
> 4. The build/deploy process needs to be bound to maven which might be one of 
> the trickier bits to deal with.
> {quote}



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

[jira] [Updated] (TINKERPOP-1552) C# Gremlin Language Variant

[stephen mallette (JIRA)]

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

stephen mallette updated TINKERPOP-1552:

Component/s: language-variant

> C# Gremlin Language Variant
> ---
>
> Key: TINKERPOP-1552
> URL: https://issues.apache.org/jira/browse/TINKERPOP-1552
> Project: TinkerPop
>  Issue Type: Improvement
>  Components: language-variant
>Affects Versions: 3.2.3
>Reporter: Jorge Bay
>
> It would be nice to have a C# GLV that runs under .NET Framework 4.5+ and 
> .NET Core.
> The maven build could use the Exec Maven Plugin to exec .NET Core's [dotnet 
> test|https://www.microsoft.com/net/core#macos] command.
> Some requirements, from the mailing list (edited):
> {quote}
> 1. The GLV should keep in line with class/method names of the java API
> where possible to ensure consistency of feel across languages.
> 2. There needs to be adequate tests (we're still discussing the approach to
> testing GLVs and i think that needs to be tackled sooner than later as more
> GLVs start to come in). Those tests should produce xunit style output
> unless there is some good reason not to.
> 3. There needs to be adequate documentation (e.g. Reference docs)
> 4. The build/deploy process needs to be bound to maven which might be one of 
> the trickier bits to deal with.
> {quote}



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

[jira] [Commented] (TINKERPOP-1538) Gremlin Server spawned by test suites should use a different port

[ASF GitHub Bot (JIRA)]

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

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

Github user okram commented on the issue:

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


> Gremlin Server spawned by test suites should use a different port
> -
>
> Key: TINKERPOP-1538
> URL: https://issues.apache.org/jira/browse/TINKERPOP-1538
> Project: TinkerPop
>  Issue Type: Improvement
>  Components: server, test-suite
>Affects Versions: 3.2.3
>Reporter: Daniel Kuppitz
>
> The Gremlin Server instance spawned by test suites should use a different 
> port (if the default port is already in use). You get all kind of test 
> errors, if something else (even another Gremlin Server instance) is already 
> using the default port.



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

[jira] [Created] (TINKERPOP-1552) C# Gremlin Language Variant

[Jorge Bay (JIRA)]

Jorge Bay created TINKERPOP-1552:


 Summary: C# Gremlin Language Variant
 Key: TINKERPOP-1552
 URL: https://issues.apache.org/jira/browse/TINKERPOP-1552
 Project: TinkerPop
  Issue Type: Improvement
Reporter: Jorge Bay


It would be nice to have a C# GLV that runs under .NET Framework 4.5+ and .NET 
Core.

The maven build could use the Exec Maven Plugin to exec .NET Core's [dotnet 
test|https://www.microsoft.com/net/core#macos] command.

Some requirements, from the mailing list (edited):

{quote}
1. The GLV should keep in line with class/method names of the java API
where possible to ensure consistency of feel across languages.
2. There needs to be adequate tests (we're still discussing the approach to
testing GLVs and i think that needs to be tackled sooner than later as more
GLVs start to come in). Those tests should produce xunit style output
unless there is some good reason not to.
3. There needs to be adequate documentation (e.g. Reference docs)
4. The build/deploy process needs to be bound to maven which might be one of 
the trickier bits to deal with.
{quote}



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

[jira] [Commented] (TINKERPOP-1541) Select should default to Pop.last semantics

[ASF GitHub Bot (JIRA)]

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

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

Github user okram closed the pull request at:

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


> Select should default to Pop.last semantics
> ---
>
> Key: TINKERPOP-1541
> URL: https://issues.apache.org/jira/browse/TINKERPOP-1541
> Project: TinkerPop
>  Issue Type: Improvement
>  Components: process
>Affects Versions: 3.2.3
>Reporter: Marko A. Rodriguez
>Assignee: Marko A. Rodriguez
>  Labels: breaking
> Fix For: 3.3.0
>
>
> Check this out:
> {code}
> gremlin> g.V().as('a').select('a').as('a').select('a')
> ==>[v[1],v[1]]
> ==>[v[2],v[2]]
> ==>[v[3],v[3]]
> ==>[v[4],v[4]]
> ==>[v[5],v[5]]
> ==>[v[6],v[6]]
> {code}
> Shouldn't we just return the uniques? This is a big decision as this can 
> cause massive rippling breakage for users :).



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

[jira] [Commented] (TINKERPOP-1538) Gremlin Server spawned by test suites should use a different port

[ASF GitHub Bot (JIRA)]

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

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

Github user okram commented on the issue:

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


> Gremlin Server spawned by test suites should use a different port
> -
>
> Key: TINKERPOP-1538
> URL: https://issues.apache.org/jira/browse/TINKERPOP-1538
> Project: TinkerPop
>  Issue Type: Improvement
>  Components: server, test-suite
>Affects Versions: 3.2.3
>Reporter: Daniel Kuppitz
>
> The Gremlin Server instance spawned by test suites should use a different 
> port (if the default port is already in use). You get all kind of test 
> errors, if something else (even another Gremlin Server instance) is already 
> using the default port.



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

[GitHub] tinkerpop issue #493: TINKERPOP-1538 [master]

[okram]

Github user okram commented on the issue:

https://github.com/apache/tinkerpop/pull/493
  
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] tinkerpop issue #491: TINKERPOP-1538 Use non-default port for gremlin server...

[okram]

Github user okram commented on the issue:

https://github.com/apache/tinkerpop/pull/491
  
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] tinkerpop pull request #482: TINKERPOP-1541: Select should default to Pop.la...

[okram]

Github user okram closed the pull request at:

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


---
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] tinkerpop issue #492: TINKERPOP-1538 [tp32]

[okram]

Github user okram commented on the issue:

https://github.com/apache/tinkerpop/pull/492
  
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-1493) Groovy project doesn't build on Windows

[ASF GitHub Bot (JIRA)]

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

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

Github user spmallette commented on the issue:

https://github.com/apache/tinkerpop/pull/457
  
@dkuppitz does that make any sense to you? is docker not using 2.7.2 
somehow?


> Groovy project doesn't build on Windows
> ---
>
> Key: TINKERPOP-1493
> URL: https://issues.apache.org/jira/browse/TINKERPOP-1493
> Project: TinkerPop
>  Issue Type: Bug
>  Components: groovy
>Affects Versions: 3.2.2
>Reporter: Paul Jackson
>Assignee: Jason Plurad
>Priority: Minor
>
> Builds on Windows fail for two reasons. First the line to create extTestDir 
> is creating a path consisting of two full paths concatenated together. The 
> second drive letter is seen as an illegal character:
> {code}private static final File extTestDir = new 
> File(System.getProperty("user.dir"), 
> TestHelper.makeTestDataDirectory(DependencyGrabberTest.class));{code}
> Second, when it comes time to delete the directory it is locked. This is 
> because some instances of JarFile are created on it but not closed.



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

[GitHub] tinkerpop issue #457: TINKERPOP-1493 Groovy project doesn't build on Windows

[spmallette]

Github user spmallette commented on the issue:

https://github.com/apache/tinkerpop/pull/457
  
@dkuppitz does that make any sense to you? is docker not using 2.7.2 
somehow?


---
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-1493) Groovy project doesn't build on Windows

[ASF GitHub Bot (JIRA)]

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

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

Github user pauljackson commented on the issue:

https://github.com/apache/tinkerpop/pull/457
  
Looking at the Hadoop code gives no direct clue (to me), but it does seem 
to indicate that you are not using the 2.7.2 version, which might explain the 
inconsistent results. Maybe your local maven repo has the wrong version?

The stack trace ends with:
Caused by: java.io.IOException: Mkdirs failed to create 
/usr/src/tinkerpop/spark-gremlin/target/test-case-data/SparkHadoopGraphProvider/graph-provider-data/~reducing/_temporary/0/_temporary/attempt_201611051613_15726_r_00_0
 (exists=false, cwd=file:/usr/src/tinkerpop/spark-gremlin)
at 
org.apache.hadoop.fs.ChecksumFileSystem.create(ChecksumFileSystem.java:450)
at 
org.apache.hadoop.fs.ChecksumFileSystem.create(ChecksumFileSystem.java:435)

I grabbed the related source from for version 2.7.2 from here: 
https://archive.apache.org/dist/hadoop/core/hadoop-2.7.2/

https://archive.apache.org/dist/hadoop/core/hadoop-2.7.2/hadoop-2.7.2-src.tar.gz

hadoop-2.7.2-src/hadoop-common-project/hadoop-common/src/main/java/org/apache/hadoop/fs/ChecksumFileSystem.java

The related code does have a call to create() on line 435 but the exception 
is thrown on line 449:
  @Override
  public FSDataOutputStream create(Path f, FsPermission permission,
  boolean overwrite, int bufferSize, short replication, long blockSize,
  Progressable progress) throws IOException {
return create(f, permission, overwrite, true, bufferSize, // 435
replication, blockSize, progress);
  }

  private FSDataOutputStream create(Path f, FsPermission permission,
  boolean overwrite, boolean createParent, int bufferSize,
  short replication, long blockSize,
  Progressable progress) throws IOException {
Path parent = f.getParent();
if (parent != null) {
  if (!createParent && !exists(parent)) {
throw new FileNotFoundException("Parent directory doesn't exist: "
+ parent);
  } else if (!mkdirs(parent)) {
throw new IOException("Mkdirs failed to create " + parent //449
+ " (exists=" + exists(parent) + ", cwd=" + 
getWorkingDirectory() // 450
+ ")");
  }
}



From: stephen mallette [mailto:notificati...@github.com]
Sent: Tuesday, November 15, 2016 8:24 AM
To: apache/tinkerpop
Cc: Paul A. Jackson; Author
Subject: Re: [apache/tinkerpop] TINKERPOP-1493 Groovy project doesn't build 
on Windows (#457)


The stack trace is pasted above.

—
You are receiving this because you authored the thread.
Reply to this email directly, view it on 
GitHub, or 
mute the 
thread.






> Groovy project doesn't build on Windows
> ---
>
> Key: TINKERPOP-1493
> URL: https://issues.apache.org/jira/browse/TINKERPOP-1493
> Project: TinkerPop
>  Issue Type: Bug
>  Components: groovy
>Affects Versions: 3.2.2
>Reporter: Paul Jackson
>Assignee: Jason Plurad
>Priority: Minor
>
> Builds on Windows fail for two reasons. First the line to create extTestDir 
> is creating a path consisting of two full paths concatenated together. The 
> second drive letter is seen as an illegal character:
> {code}private static final File extTestDir = new 
> File(System.getProperty("user.dir"), 
> TestHelper.makeTestDataDirectory(DependencyGrabberTest.class));{code}
> Second, when it comes time to delete the directory it is locked. This is 
> because some instances of JarFile are created on it but not closed.



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

[GitHub] tinkerpop issue #457: TINKERPOP-1493 Groovy project doesn't build on Windows

[pauljackson]

Github user pauljackson commented on the issue:

https://github.com/apache/tinkerpop/pull/457
  
Looking at the Hadoop code gives no direct clue (to me), but it does seem 
to indicate that you are not using the 2.7.2 version, which might explain the 
inconsistent results. Maybe your local maven repo has the wrong version?

The stack trace ends with:
Caused by: java.io.IOException: Mkdirs failed to create 
/usr/src/tinkerpop/spark-gremlin/target/test-case-data/SparkHadoopGraphProvider/graph-provider-data/~reducing/_temporary/0/_temporary/attempt_201611051613_15726_r_00_0
 (exists=false, cwd=file:/usr/src/tinkerpop/spark-gremlin)
at 
org.apache.hadoop.fs.ChecksumFileSystem.create(ChecksumFileSystem.java:450)
at 
org.apache.hadoop.fs.ChecksumFileSystem.create(ChecksumFileSystem.java:435)

I grabbed the related source from for version 2.7.2 from here: 
https://archive.apache.org/dist/hadoop/core/hadoop-2.7.2/

https://archive.apache.org/dist/hadoop/core/hadoop-2.7.2/hadoop-2.7.2-src.tar.gz

hadoop-2.7.2-src/hadoop-common-project/hadoop-common/src/main/java/org/apache/hadoop/fs/ChecksumFileSystem.java

The related code does have a call to create() on line 435 but the exception 
is thrown on line 449:
  @Override
  public FSDataOutputStream create(Path f, FsPermission permission,
  boolean overwrite, int bufferSize, short replication, long blockSize,
  Progressable progress) throws IOException {
return create(f, permission, overwrite, true, bufferSize, // 435
replication, blockSize, progress);
  }

  private FSDataOutputStream create(Path f, FsPermission permission,
  boolean overwrite, boolean createParent, int bufferSize,
  short replication, long blockSize,
  Progressable progress) throws IOException {
Path parent = f.getParent();
if (parent != null) {
  if (!createParent && !exists(parent)) {
throw new FileNotFoundException("Parent directory doesn't exist: "
+ parent);
  } else if (!mkdirs(parent)) {
throw new IOException("Mkdirs failed to create " + parent //449
+ " (exists=" + exists(parent) + ", cwd=" + 
getWorkingDirectory() // 450
+ ")");
  }
}



From: stephen mallette [mailto:notificati...@github.com]
Sent: Tuesday, November 15, 2016 8:24 AM
To: apache/tinkerpop
Cc: Paul A. Jackson; Author
Subject: Re: [apache/tinkerpop] TINKERPOP-1493 Groovy project doesn't build 
on Windows (#457)


The stack trace is pasted above.

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

[jira] [Closed] (TINKERPOP-1541) Select should default to Pop.last semantics

[Marko A. Rodriguez (JIRA)]

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

Marko A. Rodriguez closed TINKERPOP-1541.
-
   Resolution: Fixed
Fix Version/s: 3.3.0

> Select should default to Pop.last semantics
> ---
>
> Key: TINKERPOP-1541
> URL: https://issues.apache.org/jira/browse/TINKERPOP-1541
> Project: TinkerPop
>  Issue Type: Improvement
>  Components: process
>Affects Versions: 3.2.3
>Reporter: Marko A. Rodriguez
>Assignee: Marko A. Rodriguez
>  Labels: breaking
> Fix For: 3.3.0
>
>
> Check this out:
> {code}
> gremlin> g.V().as('a').select('a').as('a').select('a')
> ==>[v[1],v[1]]
> ==>[v[2],v[2]]
> ==>[v[3],v[3]]
> ==>[v[4],v[4]]
> ==>[v[5],v[5]]
> ==>[v[6],v[6]]
> {code}
> Shouldn't we just return the uniques? This is a big decision as this can 
> cause massive rippling breakage for users :).



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

[jira] [Created] (TINKERPOP-1551) Solidify and document Gremlin bytecode specification

[Marko A. Rodriguez (JIRA)]

Marko A. Rodriguez created TINKERPOP-1551:
-

 Summary: Solidify and document Gremlin bytecode specification
 Key: TINKERPOP-1551
 URL: https://issues.apache.org/jira/browse/TINKERPOP-1551
 Project: TinkerPop
  Issue Type: Improvement
  Components: process
Affects Versions: 3.2.3
Reporter: Marko A. Rodriguez


Gremlin Bytecode has a nested list structure of the form:

{code}
[operand, argument*]*
{code}

..where an argument can be another bytecode sequence.

Right now, bytecode has a one-to-one with the {{GraphTraversal}} API. This is 
fine except for in the case of various step-modulators. If we can fold 
step-modulation into the full instruction, then I think Bytecode can be 
specified nicely and easily worked with by language designers.

Here is the problem with modulation instructions:

{code}
['select','a','b']
['by','name']
['by',[[bothE],[count]]]
{code}

When working with this instruction sequence, you have to "back propagate" the 
{{by}}-modulators to the {{select}}-instruction. As {{by}}-modulation is a 
syntactic device, it should NOT be in the instruction set. The above sequence 
should be represented as:

{code}
['select','a','b',[['values','name']],[[bothE],[count]]]
{code}




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

[GitHub] tinkerpop issue #457: TINKERPOP-1493 Groovy project doesn't build on Windows

[spmallette]

Github user spmallette commented on the issue:

https://github.com/apache/tinkerpop/pull/457
  
The stack trace is pasted above.


---
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-1493) Groovy project doesn't build on Windows

[ASF GitHub Bot (JIRA)]

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

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

Github user pauljackson commented on the issue:

https://github.com/apache/tinkerpop/pull/457
  
Is there a stacktrace or other output that might help us figure this out? 
Specific test that fails?

Thanks,
-Paul


From: stephen mallette [mailto:notificati...@github.com]
Sent: Saturday, November 12, 2016 6:22 AM
To: apache/tinkerpop
Cc: Paul A. Jackson; Author
Subject: Re: [apache/tinkerpop] TINKERPOP-1493 Groovy project doesn't build 
on Windows (#457)


I'm still in a position where tp31 is fine on docker but this PR is not. I 
rely on docker pretty heavily, so until I figure out what's wrong with my 
environment, I'm hesitant to +1 this though I admit that this change really 
shouldn't affect spark at all (yet somehow it does).

—
You are receiving this because you authored the thread.
Reply to this email directly, view it on 
GitHub, or 
mute the 
thread.






> Groovy project doesn't build on Windows
> ---
>
> Key: TINKERPOP-1493
> URL: https://issues.apache.org/jira/browse/TINKERPOP-1493
> Project: TinkerPop
>  Issue Type: Bug
>  Components: groovy
>Affects Versions: 3.2.2
>Reporter: Paul Jackson
>Assignee: Jason Plurad
>Priority: Minor
>
> Builds on Windows fail for two reasons. First the line to create extTestDir 
> is creating a path consisting of two full paths concatenated together. The 
> second drive letter is seen as an illegal character:
> {code}private static final File extTestDir = new 
> File(System.getProperty("user.dir"), 
> TestHelper.makeTestDataDirectory(DependencyGrabberTest.class));{code}
> Second, when it comes time to delete the directory it is locked. This is 
> because some instances of JarFile are created on it but not closed.



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

[GitHub] tinkerpop issue #457: TINKERPOP-1493 Groovy project doesn't build on Windows

[pauljackson]

Github user pauljackson commented on the issue:

https://github.com/apache/tinkerpop/pull/457
  
Is there a stacktrace or other output that might help us figure this out? 
Specific test that fails?

Thanks,
-Paul


From: stephen mallette [mailto:notificati...@github.com]
Sent: Saturday, November 12, 2016 6:22 AM
To: apache/tinkerpop
Cc: Paul A. Jackson; Author
Subject: Re: [apache/tinkerpop] TINKERPOP-1493 Groovy project doesn't build 
on Windows (#457)


I'm still in a position where tp31 is fine on docker but this PR is not. I 
rely on docker pretty heavily, so until I figure out what's wrong with my 
environment, I'm hesitant to +1 this though I admit that this change really 
shouldn't affect spark at all (yet somehow it does).

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

[jira] [Commented] (TINKERPOP-1493) Groovy project doesn't build on Windows

[ASF GitHub Bot (JIRA)]

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

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

Github user pluradj commented on the issue:

https://github.com/apache/tinkerpop/pull/457
  
I configured a system with the same specs as listed, but I got 3 
consecutive successes. Not sure what the issue could be.


> Groovy project doesn't build on Windows
> ---
>
> Key: TINKERPOP-1493
> URL: https://issues.apache.org/jira/browse/TINKERPOP-1493
> Project: TinkerPop
>  Issue Type: Bug
>  Components: groovy
>Affects Versions: 3.2.2
>Reporter: Paul Jackson
>Assignee: Jason Plurad
>Priority: Minor
>
> Builds on Windows fail for two reasons. First the line to create extTestDir 
> is creating a path consisting of two full paths concatenated together. The 
> second drive letter is seen as an illegal character:
> {code}private static final File extTestDir = new 
> File(System.getProperty("user.dir"), 
> TestHelper.makeTestDataDirectory(DependencyGrabberTest.class));{code}
> Second, when it comes time to delete the directory it is locked. This is 
> because some instances of JarFile are created on it but not closed.



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

[GitHub] tinkerpop issue #457: TINKERPOP-1493 Groovy project doesn't build on Windows

[pluradj]

Github user pluradj commented on the issue:

https://github.com/apache/tinkerpop/pull/457
  
I configured a system with the same specs as listed, but I got 3 
consecutive successes. Not sure what the issue could be.


---
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: Commit problem

[Robert Dale]

I see. I didn't have the apache git repo. That worked. Thanks.

Robert Dale

On Tue, Nov 15, 2016 at 6:52 AM, Stephen Mallette 
wrote:

> I checked and you should have commit access. Not sure how your remotes are
> setup, but mine look like this:
>
> $ git remote -v
> mirror https://github.com/apache/tinkerpop.git (fetch)
> mirror https://github.com/apache/tinkerpop.git (push)
> origin  https://git-wip-us.apache.org/repos/asf/tinkerpop.git/ (fetch)
> origin  https://git-wip-us.apache.org/repos/asf/tinkerpop.git/ (push)
>
> You can't push to the "mirror" so if you're trying to do that, then that's
> why it is failing. You need to setup "origin" against the Apache Git and
> not GitHub. The "mirror" is useful for grabbing pull requests from
> third-parties though, so it's worth keeping that around:
>
> git fetch pull/123/head:pr-123
> git checkout pr-123
>
> Note that if you have changes for tp31, then your order of operations
> should be to not push to tp31 first. You should get tp31 -> tp32 -> master
> branches all settled locally (i.e. merge tp31 to tp32 then tp32 to master
> locally) then push in reverse order starting with master then tp32 and then
> tp31. I think that will reduce the chance of merge issues if someone
> fetches in the middle of your pushing to those three branches.
>
> Hopefully, checking your remotes helps solve your push problem. Please let
> me know if it's all good.
>
>
>
> On Mon, Nov 14, 2016 at 9:18 PM, Robert Dale  wrote:
>
> > I fixed a small typo and wanted to commit it.  Am I doing this right?
> >
> > [rdale@mocl99mqm12 tinkerpop]$ git status
> > On branch tp31
> > Your branch is ahead of 'upstream/tp31' by 1 commit.
> >   (use "git push" to publish your local commits)
> > nothing to commit, working tree clean
> > [rdale@mocl99mqm12 tinkerpop]$ git push
> > ERROR: Permission to apache/tinkerpop.git denied to robertdale.
> > fatal: Could not read from remote repository.
> >
> > Please make sure you have the correct access rights
> > and the repository exists.
> >
> >
> >
> > Robert Dale
> >
>

[GitHub] tinkerpop issue #494: TINKERPOP-1443 - Introduce API check into the build

[metlos]

Github user metlos commented on the issue:

https://github.com/apache/tinkerpop/pull/494
  
K, finally the CI fails for the right reasons :wink: 
https://travis-ci.org/apache/tinkerpop/builds/176007319#L3026


---
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-1443) Use an API checker during build

[ASF GitHub Bot (JIRA)]

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

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

Github user metlos commented on the issue:

https://github.com/apache/tinkerpop/pull/494
  
K, finally the CI fails for the right reasons :wink: 
https://travis-ci.org/apache/tinkerpop/builds/176007319#L3026


> Use an API checker during build
> ---
>
> Key: TINKERPOP-1443
> URL: https://issues.apache.org/jira/browse/TINKERPOP-1443
> Project: TinkerPop
>  Issue Type: Improvement
>  Components: build-release
>Affects Versions: 3.2.2
>Reporter: Lukas Krejci
>
> Tinkerpop 3.2.2 changed the signature of the method 
> {{GraphTraversal.hasLabel}} from {{(String...)}} to {{(String, String...)}}. 
> While this is certainly an improvement, it is both source and binary 
> incompatible change.
> I.e. even if every usage of {{hasLabel}} had at least one parameter in the 
> user code, none of those calls will work until all the user code is 
> recompiled using Tinkerpop 3.2.2.
> I don't know the versioning policy of Tinkerpop but changes like the above in 
> a micro/patch release are generally unexpected.
> Please consider API checkers like http://revapi.org to warn about such 
> incompatible API changes...



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

Re: Commit problem

[Stephen Mallette]

I checked and you should have commit access. Not sure how your remotes are
setup, but mine look like this:

$ git remote -v
mirror https://github.com/apache/tinkerpop.git (fetch)
mirror https://github.com/apache/tinkerpop.git (push)
origin  https://git-wip-us.apache.org/repos/asf/tinkerpop.git/ (fetch)
origin  https://git-wip-us.apache.org/repos/asf/tinkerpop.git/ (push)

You can't push to the "mirror" so if you're trying to do that, then that's
why it is failing. You need to setup "origin" against the Apache Git and
not GitHub. The "mirror" is useful for grabbing pull requests from
third-parties though, so it's worth keeping that around:

git fetch pull/123/head:pr-123
git checkout pr-123

Note that if you have changes for tp31, then your order of operations
should be to not push to tp31 first. You should get tp31 -> tp32 -> master
branches all settled locally (i.e. merge tp31 to tp32 then tp32 to master
locally) then push in reverse order starting with master then tp32 and then
tp31. I think that will reduce the chance of merge issues if someone
fetches in the middle of your pushing to those three branches.

Hopefully, checking your remotes helps solve your push problem. Please let
me know if it's all good.



On Mon, Nov 14, 2016 at 9:18 PM, Robert Dale  wrote:

> I fixed a small typo and wanted to commit it.  Am I doing this right?
>
> [rdale@mocl99mqm12 tinkerpop]$ git status
> On branch tp31
> Your branch is ahead of 'upstream/tp31' by 1 commit.
>   (use "git push" to publish your local commits)
> nothing to commit, working tree clean
> [rdale@mocl99mqm12 tinkerpop]$ git push
> ERROR: Permission to apache/tinkerpop.git denied to robertdale.
> fatal: Could not read from remote repository.
>
> Please make sure you have the correct access rights
> and the repository exists.
>
>
>
> Robert Dale
>

[jira] [Commented] (TINKERPOP-1541) Select should default to Pop.last semantics

[ASF GitHub Bot (JIRA)]

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

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

Github user robertdale commented on the issue:

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


> Select should default to Pop.last semantics
> ---
>
> Key: TINKERPOP-1541
> URL: https://issues.apache.org/jira/browse/TINKERPOP-1541
> Project: TinkerPop
>  Issue Type: Improvement
>  Components: process
>Affects Versions: 3.2.3
>Reporter: Marko A. Rodriguez
>Assignee: Marko A. Rodriguez
>  Labels: breaking
>
> Check this out:
> {code}
> gremlin> g.V().as('a').select('a').as('a').select('a')
> ==>[v[1],v[1]]
> ==>[v[2],v[2]]
> ==>[v[3],v[3]]
> ==>[v[4],v[4]]
> ==>[v[5],v[5]]
> ==>[v[6],v[6]]
> {code}
> Shouldn't we just return the uniques? This is a big decision as this can 
> cause massive rippling breakage for users :).



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

[GitHub] tinkerpop issue #482: TINKERPOP-1541: Select should default to Pop.last sema...

[robertdale]

Github user robertdale commented on the issue:

https://github.com/apache/tinkerpop/pull/482
  
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-1443) Use an API checker during build

[ASF GitHub Bot (JIRA)]

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

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

GitHub user metlos opened a pull request:

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

TINKERPOP-1443 - Introduce API check into the build

This introduces API checks into the build and fails the build whenever a 
"severe" change is introduced that would break either source or binary 
compatibility.

Several modules are excluded from the API check (by setting the 
`revapi.skip` property to true) but because I don't know exactly what Tinkerpop 
considers its public API this list might shrink or grow...

The API analysis itself is configured such that it only checks classes from 
`org.apache.tinkerpop` package and subpackages excluding 
`org.apache.tinkerpop.shaded`.

More importantly, the analysis is configured to allow breaking changes on a 
new minor version - from the context I gathered that is roughly your policy.

Also using a non-public class as part of the API always breaks the build 
even if other breaking changes are allowed.

As it stands right now, the CI build will fail with this PR because there 
are API changes that the checker disallows.

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

$ git pull https://github.com/metlos/tinkerpop api-check-tp32

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

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


commit f35041fe52173f4ce73ad4385d1ad011306e3df1
Author: Lukas Krejci 
Date:   2016-11-14T22:55:23Z

Introduce Revapi API checks into the build.

The API checker is set up to only check classes in org.apache.tinkerpop
package (and sub packages) and is set up to ignore breaking changes
on a minor version increase.

It always reports non-public classes that leak into the API though.

commit 992800be33d28f55372cb219e90447dd4f33accb
Author: Lukas Krejci 
Date:   2016-11-15T08:57:59Z

Merge remote-tracking branch 'upstream/tp32' into api-check




> Use an API checker during build
> ---
>
> Key: TINKERPOP-1443
> URL: https://issues.apache.org/jira/browse/TINKERPOP-1443
> Project: TinkerPop
>  Issue Type: Improvement
>  Components: build-release
>Affects Versions: 3.2.2
>Reporter: Lukas Krejci
>
> Tinkerpop 3.2.2 changed the signature of the method 
> {{GraphTraversal.hasLabel}} from {{(String...)}} to {{(String, String...)}}. 
> While this is certainly an improvement, it is both source and binary 
> incompatible change.
> I.e. even if every usage of {{hasLabel}} had at least one parameter in the 
> user code, none of those calls will work until all the user code is 
> recompiled using Tinkerpop 3.2.2.
> I don't know the versioning policy of Tinkerpop but changes like the above in 
> a micro/patch release are generally unexpected.
> Please consider API checkers like http://revapi.org to warn about such 
> incompatible API changes...



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

[GitHub] tinkerpop pull request #494: TINKERPOP-1443 - Introduce API check into the b...

[metlos]

GitHub user metlos opened a pull request:

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

TINKERPOP-1443 - Introduce API check into the build

This introduces API checks into the build and fails the build whenever a 
"severe" change is introduced that would break either source or binary 
compatibility.

Several modules are excluded from the API check (by setting the 
`revapi.skip` property to true) but because I don't know exactly what Tinkerpop 
considers its public API this list might shrink or grow...

The API analysis itself is configured such that it only checks classes from 
`org.apache.tinkerpop` package and subpackages excluding 
`org.apache.tinkerpop.shaded`.

More importantly, the analysis is configured to allow breaking changes on a 
new minor version - from the context I gathered that is roughly your policy.

Also using a non-public class as part of the API always breaks the build 
even if other breaking changes are allowed.

As it stands right now, the CI build will fail with this PR because there 
are API changes that the checker disallows.

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

$ git pull https://github.com/metlos/tinkerpop api-check-tp32

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

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


commit f35041fe52173f4ce73ad4385d1ad011306e3df1
Author: Lukas Krejci 
Date:   2016-11-14T22:55:23Z

Introduce Revapi API checks into the build.

The API checker is set up to only check classes in org.apache.tinkerpop
package (and sub packages) and is set up to ignore breaking changes
on a minor version increase.

It always reports non-public classes that leak into the API though.

commit 992800be33d28f55372cb219e90447dd4f33accb
Author: Lukas Krejci 
Date:   2016-11-15T08:57:59Z

Merge remote-tracking branch 'upstream/tp32' into api-check




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