date:20161101

[jira] [Commented] (TINKERPOP-1211) UnfoldStep should unfold arrays.

2016-11-01 Thread ASF GitHub Bot (JIRA)


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

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

Github user twilmes commented on the issue:

https://github.com/apache/tinkerpop/pull/475
  
I grabbed the latest commit and things checked out.  Looks good.

VOTE: +1


> UnfoldStep should unfold arrays.
> 
>
> Key: TINKERPOP-1211
> URL: https://issues.apache.org/jira/browse/TINKERPOP-1211
> Project: TinkerPop
>  Issue Type: Bug
>  Components: process
>Affects Versions: 3.1.1-incubating
>Reporter: Marko A. Rodriguez
>  Labels: breaking
>
> Currently {{UnfoldStep}} does not unfold arrays as an array does not 
> implement {{Iterable}} or {{Iterator}}. We simply need to check if the 
> current object is an array, and if so, set the flatMap-iterator to 
> {{ArrayIterator}}.
> This would be breaking, but I doubt anyone ever uses arrays or would find 
> this a problem. I'm sure anyone who wanted to {{unfold}} an array was like: 
> "wha?"



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

[GitHub] tinkerpop issue #475: TINKERPOP-1211: UnfoldStep should unfold arrays.

2016-11-01 Thread twilmes

Github user twilmes commented on the issue:

https://github.com/apache/tinkerpop/pull/475
  
I grabbed the latest commit and things checked out.  Looks good.

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

[INFO] Jira notification email update

2016-11-01 Thread Hadrian Zbarcea


Hi,

I had a quick chat with infra@ today and they updated the notification 
email address to be this one. Before it was sending to the old incubator 
dev email.


Just so you know in case you need to update your mail filters.

Cheers,
Hadrian

[jira] [Commented] (TINKERPOP-1471) IncidentToAdjacentStrategy use hidden marker to avoid repeated recursion.

2016-11-01 Thread ASF GitHub Bot (JIRA)


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

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

Github user dkuppitz commented on a diff in the pull request:

https://github.com/apache/tinkerpop/pull/474#discussion_r86029705
  
--- Diff: 
gremlin-core/src/main/java/org/apache/tinkerpop/gremlin/process/traversal/strategy/decoration/SubgraphStrategy.java
 ---
@@ -105,21 +105,11 @@ private SubgraphStrategy(final Traversal 
vertexCriterion, final Trave
 this.vertexPropertyCriterion = null == vertexPropertyCriterion ? 
null : vertexPropertyCriterion.asAdmin().clone();
 
 if (null != this.vertexCriterion)
-this.addLabelMarker(this.vertexCriterion);
+TraversalHelper.applyTraversalRecursively(t -> 
t.getStartStep().addLabel(MARKER), this.vertexCriterion);
--- End diff --

Ha, it's getting late here.


> IncidentToAdjacentStrategy use hidden marker to avoid repeated recursion.
> -
>
> Key: TINKERPOP-1471
> URL: https://issues.apache.org/jira/browse/TINKERPOP-1471
> Project: TinkerPop
>  Issue Type: Improvement
>  Components: process
>Affects Versions: 3.2.2
>Reporter: Marko A. Rodriguez
>Assignee: Daniel Kuppitz
>
> TINKERPOP-1456 introduces the notion that "hidden labels" on steps will be 
> removed from the traversal prior to evaluation. This use of "hidden labels" 
> was necessary for {{SubgraphStrategy}} and it is not always possible to 
> remove the add "hidden labels" in {{SubgraphStrategy}} completely. Thus, 
> prior to evaluation, in hidden labels are removed.
> This concept of "hidden labels" is useful for marking steps in a traversal so 
> that  a strategy applied at a child gets information from the strategy 
> applied at a parent.
> This can be used to make {{IncidentToAdjacentStrategy}} faster. In 
> particular, the following recursion is called repeatedly for each child.
> {code}
>   if 
> (TraversalHelper.hasStepOfAssignableClassRecursively(INVALIDATING_STEP_CLASSES,
>  TraversalHelper.getRootTraversal(traversal)))
> return;
> {code}
> Instead, it would be smart to do this and then, you don't need to recurse 
> from the root traversal over and over again.
> {code}
> private final void addMarkerToChildren(final Traversal.Admin 
> traversal) {
> traversal.getStartStep().addLabel(MARKER);
> for (final Step step : traversal.getSteps()) {
> if (step instanceof TraversalParent) {
> ((TraversalParent) 
> step).getLocalChildren().forEach(this::addMarkerToChildren);
> ((TraversalParent) 
> step).getGlobalChildren().forEach(this::addMarkerToChildren);
> }
> }
> }
> public void apply(Traversal traversal) {
>   if(traversal.getParent() instanceof EmptyStep) {
> boolean mark = 
> TraversalHelper.hasStepOfAssignableClassRecursively(INVALIDATING_STEP_CLASSES,
>  traversal)
> if(mark)  this.addMarkerToChildren(traversal)
>   }
>   // if the marker exists, don't optimize
>   if(traversal.getStartStep().getLabels().contains(MARKER)) {
> traversal.getStartStep().removeLabel(MARKER);
> return;
>   }
> // else do the rest of the code.
> }
> {code}



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

[GitHub] tinkerpop pull request #474: TINKERPOP-1471: IncidentToAdjacentStrategy use ...

2016-11-01 Thread dkuppitz

Github user dkuppitz commented on a diff in the pull request:

https://github.com/apache/tinkerpop/pull/474#discussion_r86029705
  
--- Diff: 
gremlin-core/src/main/java/org/apache/tinkerpop/gremlin/process/traversal/strategy/decoration/SubgraphStrategy.java
 ---
@@ -105,21 +105,11 @@ private SubgraphStrategy(final Traversal 
vertexCriterion, final Trave
 this.vertexPropertyCriterion = null == vertexPropertyCriterion ? 
null : vertexPropertyCriterion.asAdmin().clone();
 
 if (null != this.vertexCriterion)
-this.addLabelMarker(this.vertexCriterion);
+TraversalHelper.applyTraversalRecursively(t -> 
t.getStartStep().addLabel(MARKER), this.vertexCriterion);
--- End diff --

Ha, it's getting late here.


---
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-1292) TinkerGraphComputer VertexProgramInterceptors

2016-11-01 Thread ASF GitHub Bot (JIRA)


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

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

GitHub user okram opened a pull request:

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

TINKERPOP-1292: TinkerGraphComputer VertexProgramInterceptors

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

Added `TinkerGraphCountStrategy` which will translate `g.V().count()` and 
`g.E().count()` into direct calls to the underlying 
`TinkerGraph.vertices/edges` hash maps (`.size()`). Thus, no need to iterate 
out the vertices/edges and then count the iteration. O(1) time for count.

--- we can extend on this line of reasoning in this branch if people have 
other ideas for shortcuts.

* Also did some cleanup of some test suites in Neo4jGraph and TinkerGraph 
that should have been removed long ago when their respective strategy suites 
were removed.

VOTE +1.

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

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

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

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


commit 0ea3b5e26e76919d080fe224b1b727a132c4b829
Author: Marko A. Rodriguez 
Date:   2016-11-01T21:24:18Z

added TinkerCountGlobalStep and TinkerGraphCountStrategy which will turn 
g.V().count() and g.E().count() into direct calls to the .size() of the 
underlying TinkerGraph.vertices/edges Maps. Removed the OptIn strategy suites 
in both TinkerGraph and Neo4jGraph -- this should have been done when these 
suites were removed long ago.




> TinkerGraphComputer VertexProgramInterceptors
> -
>
> Key: TINKERPOP-1292
> URL: https://issues.apache.org/jira/browse/TINKERPOP-1292
> Project: TinkerPop
>  Issue Type: Improvement
>  Components: process, tinkergraph
>Affects Versions: 3.2.0-incubating
>Reporter: Marko A. Rodriguez
> Fix For: 3.2.4
>
>
> Create {{TinkerGraphInterceptorStrategy}} for {{TinkerGraphComputer}} and 
> grow it starting with the two simple patterns below:
> {code}
> g.V().count() -> tinkerGraph.vertices.size()
> g.E().count() -> tinkerGraph.edges.size()
> {code}
> In fact, perhaps even create {{TinkerGraphCountStep}} for OLTP as well that 
> does the above.



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

[GitHub] tinkerpop pull request #476: TINKERPOP-1292: TinkerGraphComputer VertexProgr...

2016-11-01 Thread okram

GitHub user okram opened a pull request:

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

TINKERPOP-1292: TinkerGraphComputer VertexProgramInterceptors

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

Added `TinkerGraphCountStrategy` which will translate `g.V().count()` and 
`g.E().count()` into direct calls to the underlying 
`TinkerGraph.vertices/edges` hash maps (`.size()`). Thus, no need to iterate 
out the vertices/edges and then count the iteration. O(1) time for count.

--- we can extend on this line of reasoning in this branch if people have 
other ideas for shortcuts.

* Also did some cleanup of some test suites in Neo4jGraph and TinkerGraph 
that should have been removed long ago when their respective strategy suites 
were removed.

VOTE +1.

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

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

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

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


commit 0ea3b5e26e76919d080fe224b1b727a132c4b829
Author: Marko A. Rodriguez 
Date:   2016-11-01T21:24:18Z

added TinkerCountGlobalStep and TinkerGraphCountStrategy which will turn 
g.V().count() and g.E().count() into direct calls to the .size() of the 
underlying TinkerGraph.vertices/edges Maps. Removed the OptIn strategy suites 
in both TinkerGraph and Neo4jGraph -- this should have been done when these 
suites were removed long ago.




---
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-1211) UnfoldStep should unfold arrays.

2016-11-01 Thread ASF GitHub Bot (JIRA)


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

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

Github user twilmes commented on a diff in the pull request:

https://github.com/apache/tinkerpop/pull/475#discussion_r86026558
  
--- Diff: 
gremlin-core/src/main/java/org/apache/tinkerpop/gremlin/process/traversal/step/map/UnfoldStep.java
 ---
@@ -46,6 +47,8 @@ else if (s instanceof Iterable)
 return ((Iterable) s).iterator();
 else if (s instanceof Map)
 return ((Map) s).entrySet().iterator();
+else if (s.getClass().isArray())
+return new ArrayIterator((Object[])s);
--- End diff --

This cast will fail if the incoming array is an array of primitives.  I 
think you could do something like this which is short and to the point but 
creates an intermediate, albeit short-lived list.
`return (Iterator)Arrays.asList(s).iterator();`

I was able to reproduce the issue when I nested a primitive array inside of 
a list.  Calling `unfold` twice looks a little silly but maybe someone would do 
this if they were dealing with nested collections.

```
gremlin> __.inject([0, 1, 2, [3, 4] as int[]]).unfold().unfold()
==>0
==>1
==>2
[I cannot be cast to [Ljava.lang.Object;
Type ':help' or ':h' for help.
Display stack trace? [yN]n
gremlin> __.inject([0, 1, 2, [3, 4]]).unfold().unfold()
==>0
==>1
==>2
==>3
==>4
```


> UnfoldStep should unfold arrays.
> 
>
> Key: TINKERPOP-1211
> URL: https://issues.apache.org/jira/browse/TINKERPOP-1211
> Project: TinkerPop
>  Issue Type: Bug
>  Components: process
>Affects Versions: 3.1.1-incubating
>Reporter: Marko A. Rodriguez
>  Labels: breaking
>
> Currently {{UnfoldStep}} does not unfold arrays as an array does not 
> implement {{Iterable}} or {{Iterator}}. We simply need to check if the 
> current object is an array, and if so, set the flatMap-iterator to 
> {{ArrayIterator}}.
> This would be breaking, but I doubt anyone ever uses arrays or would find 
> this a problem. I'm sure anyone who wanted to {{unfold}} an array was like: 
> "wha?"



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

[jira] [Commented] (TINKERPOP-1471) IncidentToAdjacentStrategy use hidden marker to avoid repeated recursion.

2016-11-01 Thread ASF GitHub Bot (JIRA)


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

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

Github user dkuppitz commented on a diff in the pull request:

https://github.com/apache/tinkerpop/pull/474#discussion_r86025437
  
--- Diff: 
gremlin-core/src/main/java/org/apache/tinkerpop/gremlin/process/traversal/strategy/decoration/SubgraphStrategy.java
 ---
@@ -105,21 +105,11 @@ private SubgraphStrategy(final Traversal 
vertexCriterion, final Trave
 this.vertexPropertyCriterion = null == vertexPropertyCriterion ? 
null : vertexPropertyCriterion.asAdmin().clone();
 
 if (null != this.vertexCriterion)
-this.addLabelMarker(this.vertexCriterion);
+TraversalHelper.applyTraversalRecursively(t -> 
t.getStartStep().addLabel(MARKER), this.vertexCriterion);
--- End diff --

`vertexCriterion` can be `null`. In that case 
`TraversalHelper.applyTraversalRecursively` and/or the consumer would throw a 
NPE.


> IncidentToAdjacentStrategy use hidden marker to avoid repeated recursion.
> -
>
> Key: TINKERPOP-1471
> URL: https://issues.apache.org/jira/browse/TINKERPOP-1471
> Project: TinkerPop
>  Issue Type: Improvement
>  Components: process
>Affects Versions: 3.2.2
>Reporter: Marko A. Rodriguez
>Assignee: Daniel Kuppitz
>
> TINKERPOP-1456 introduces the notion that "hidden labels" on steps will be 
> removed from the traversal prior to evaluation. This use of "hidden labels" 
> was necessary for {{SubgraphStrategy}} and it is not always possible to 
> remove the add "hidden labels" in {{SubgraphStrategy}} completely. Thus, 
> prior to evaluation, in hidden labels are removed.
> This concept of "hidden labels" is useful for marking steps in a traversal so 
> that  a strategy applied at a child gets information from the strategy 
> applied at a parent.
> This can be used to make {{IncidentToAdjacentStrategy}} faster. In 
> particular, the following recursion is called repeatedly for each child.
> {code}
>   if 
> (TraversalHelper.hasStepOfAssignableClassRecursively(INVALIDATING_STEP_CLASSES,
>  TraversalHelper.getRootTraversal(traversal)))
> return;
> {code}
> Instead, it would be smart to do this and then, you don't need to recurse 
> from the root traversal over and over again.
> {code}
> private final void addMarkerToChildren(final Traversal.Admin 
> traversal) {
> traversal.getStartStep().addLabel(MARKER);
> for (final Step step : traversal.getSteps()) {
> if (step instanceof TraversalParent) {
> ((TraversalParent) 
> step).getLocalChildren().forEach(this::addMarkerToChildren);
> ((TraversalParent) 
> step).getGlobalChildren().forEach(this::addMarkerToChildren);
> }
> }
> }
> public void apply(Traversal traversal) {
>   if(traversal.getParent() instanceof EmptyStep) {
> boolean mark = 
> TraversalHelper.hasStepOfAssignableClassRecursively(INVALIDATING_STEP_CLASSES,
>  traversal)
> if(mark)  this.addMarkerToChildren(traversal)
>   }
>   // if the marker exists, don't optimize
>   if(traversal.getStartStep().getLabels().contains(MARKER)) {
> traversal.getStartStep().removeLabel(MARKER);
> return;
>   }
> // else do the rest of the code.
> }
> {code}



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

[jira] [Commented] (TINKERPOP-1404) Path/label optimization

2016-11-01 Thread Marko A. Rodriguez (JIRA)


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

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

Can you VOTE on https://github.com/apache/tinkerpop/pull/473?

> Path/label optimization
> ---
>
> Key: TINKERPOP-1404
> URL: https://issues.apache.org/jira/browse/TINKERPOP-1404
> Project: TinkerPop
>  Issue Type: Improvement
>  Components: process
>Affects Versions: 3.2.1
>Reporter: pieter martin
>Assignee: pieter martin
>  Labels: performance
> Fix For: 3.3.0
>
>
> Currently path queries do a lot of label collection copying. This has a 
> significant impact on performance.
> As the labels are known and set on the traverser when {{Traverser.split(r, 
> step)}} is called there is no need to call {{Traverser.addLabels}} again in 
> {{AbstractStep}}
> Also seeing as {{AbstractStep.getLabels()}} returns an {{UnmodifyableSet}} 
> the step's labels can be used directly in the traverser. There is no need to 
> make a copy of it.



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

[jira] [Commented] (TINKERPOP-1471) IncidentToAdjacentStrategy use hidden marker to avoid repeated recursion.

2016-11-01 Thread ASF GitHub Bot (JIRA)


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

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

Github user dkuppitz commented on the issue:

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

A little refactoring would be nice though:

```
for (final Step step : traversal.getSteps()) {
if (step instanceof TraversalParent) {
((TraversalParent) 
step).getLocalChildren().forEach(this::addLabelMarker);
((TraversalParent) 
step).getGlobalChildren().forEach(this::addLabelMarker);
}
}
```
... should be as easy as:

```
TraversalHelper.forEachNestedTraversal(traversal, this::addLabelMarker);
```


> IncidentToAdjacentStrategy use hidden marker to avoid repeated recursion.
> -
>
> Key: TINKERPOP-1471
> URL: https://issues.apache.org/jira/browse/TINKERPOP-1471
> Project: TinkerPop
>  Issue Type: Improvement
>  Components: process
>Affects Versions: 3.2.2
>Reporter: Marko A. Rodriguez
>Assignee: Daniel Kuppitz
>
> TINKERPOP-1456 introduces the notion that "hidden labels" on steps will be 
> removed from the traversal prior to evaluation. This use of "hidden labels" 
> was necessary for {{SubgraphStrategy}} and it is not always possible to 
> remove the add "hidden labels" in {{SubgraphStrategy}} completely. Thus, 
> prior to evaluation, in hidden labels are removed.
> This concept of "hidden labels" is useful for marking steps in a traversal so 
> that  a strategy applied at a child gets information from the strategy 
> applied at a parent.
> This can be used to make {{IncidentToAdjacentStrategy}} faster. In 
> particular, the following recursion is called repeatedly for each child.
> {code}
>   if 
> (TraversalHelper.hasStepOfAssignableClassRecursively(INVALIDATING_STEP_CLASSES,
>  TraversalHelper.getRootTraversal(traversal)))
> return;
> {code}
> Instead, it would be smart to do this and then, you don't need to recurse 
> from the root traversal over and over again.
> {code}
> private final void addMarkerToChildren(final Traversal.Admin 
> traversal) {
> traversal.getStartStep().addLabel(MARKER);
> for (final Step step : traversal.getSteps()) {
> if (step instanceof TraversalParent) {
> ((TraversalParent) 
> step).getLocalChildren().forEach(this::addMarkerToChildren);
> ((TraversalParent) 
> step).getGlobalChildren().forEach(this::addMarkerToChildren);
> }
> }
> }
> public void apply(Traversal traversal) {
>   if(traversal.getParent() instanceof EmptyStep) {
> boolean mark = 
> TraversalHelper.hasStepOfAssignableClassRecursively(INVALIDATING_STEP_CLASSES,
>  traversal)
> if(mark)  this.addMarkerToChildren(traversal)
>   }
>   // if the marker exists, don't optimize
>   if(traversal.getStartStep().getLabels().contains(MARKER)) {
> traversal.getStartStep().removeLabel(MARKER);
> return;
>   }
> // else do the rest of the code.
> }
> {code}



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

[GitHub] tinkerpop issue #474: TINKERPOP-1471: IncidentToAdjacentStrategy use hidden ...

2016-11-01 Thread dkuppitz

Github user dkuppitz commented on the issue:

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

A little refactoring would be nice though:

```
for (final Step step : traversal.getSteps()) {
if (step instanceof TraversalParent) {
((TraversalParent) 
step).getLocalChildren().forEach(this::addLabelMarker);
((TraversalParent) 
step).getGlobalChildren().forEach(this::addLabelMarker);
}
}
```
... should be as easy as:

```
TraversalHelper.forEachNestedTraversal(traversal, this::addLabelMarker);
```


---
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-1404) Path/label optimization

2016-11-01 Thread pieter martin (JIRA)


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

pieter martin closed TINKERPOP-1404.

   Resolution: Fixed
Fix Version/s: 3.3.0

Implemented via TINKERPOP-1372

> Path/label optimization
> ---
>
> Key: TINKERPOP-1404
> URL: https://issues.apache.org/jira/browse/TINKERPOP-1404
> Project: TinkerPop
>  Issue Type: Improvement
>  Components: process
>Affects Versions: 3.2.1
>Reporter: pieter martin
>Assignee: pieter martin
>  Labels: performance
> Fix For: 3.3.0
>
>
> Currently path queries do a lot of label collection copying. This has a 
> significant impact on performance.
> As the labels are known and set on the traverser when {{Traverser.split(r, 
> step)}} is called there is no need to call {{Traverser.addLabels}} again in 
> {{AbstractStep}}
> Also seeing as {{AbstractStep.getLabels()}} returns an {{UnmodifyableSet}} 
> the step's labels can be used directly in the traverser. There is no need to 
> make a copy of it.



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

[jira] [Commented] (TINKERPOP-1404) Path/label optimization

2016-11-01 Thread pieter martin (JIRA)


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

pieter martin commented on TINKERPOP-1404:
--

[~okram] has done the primary optimization of this branch with 
[https://issues.apache.org/jira/browse/TINKERPOP-1372]
Closing this for now. I'll do some profiling again to see if the changes 
regarding AbstractStep.prepareTraversalForNextStep still have a significant 
performance impact.

> Path/label optimization
> ---
>
> Key: TINKERPOP-1404
> URL: https://issues.apache.org/jira/browse/TINKERPOP-1404
> Project: TinkerPop
>  Issue Type: Improvement
>  Components: process
>Affects Versions: 3.2.1
>Reporter: pieter martin
>Assignee: pieter martin
>  Labels: performance
>
> Currently path queries do a lot of label collection copying. This has a 
> significant impact on performance.
> As the labels are known and set on the traverser when {{Traverser.split(r, 
> step)}} is called there is no need to call {{Traverser.addLabels}} again in 
> {{AbstractStep}}
> Also seeing as {{AbstractStep.getLabels()}} returns an {{UnmodifyableSet}} 
> the step's labels can be used directly in the traverser. There is no need to 
> make a copy of it.



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

[jira] [Commented] (TINKERPOP-1211) UnfoldStep should unfold arrays.

2016-11-01 Thread ASF GitHub Bot (JIRA)


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

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

GitHub user okram opened a pull request:

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

TINKERPOP-1211: UnfoldStep should unfold arrays.

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

Unfold step now handles unfolding of arrays.

VOTE +1.

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

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

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

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






> UnfoldStep should unfold arrays.
> 
>
> Key: TINKERPOP-1211
> URL: https://issues.apache.org/jira/browse/TINKERPOP-1211
> Project: TinkerPop
>  Issue Type: Bug
>  Components: process
>Affects Versions: 3.1.1-incubating
>Reporter: Marko A. Rodriguez
>  Labels: breaking
>
> Currently {{UnfoldStep}} does not unfold arrays as an array does not 
> implement {{Iterable}} or {{Iterator}}. We simply need to check if the 
> current object is an array, and if so, set the flatMap-iterator to 
> {{ArrayIterator}}.
> This would be breaking, but I doubt anyone ever uses arrays or would find 
> this a problem. I'm sure anyone who wanted to {{unfold}} an array was like: 
> "wha?"



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

[GitHub] tinkerpop pull request #475: TINKERPOP-1211: UnfoldStep should unfold arrays...

2016-11-01 Thread okram

GitHub user okram opened a pull request:

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

TINKERPOP-1211: UnfoldStep should unfold arrays.

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

Unfold step now handles unfolding of arrays.

VOTE +1.

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

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

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

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






---
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-620) Commutative Step Marker interface

2016-11-01 Thread Marko A. Rodriguez (JIRA)


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

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

[~mbroecheler] Is this still a desired feature? Can you provide a "gist" of 
where in your code you have to explicitly reason about commutativity? This will 
help me to better understand the usage.

> Commutative Step Marker interface
> -
>
> Key: TINKERPOP-620
> URL: https://issues.apache.org/jira/browse/TINKERPOP-620
> Project: TinkerPop
>  Issue Type: Improvement
>  Components: process
>Affects Versions: 3.0.2-incubating
>Reporter: Matthias Broecheler
> Fix For: 3.2.4
>
>
> Some steps can be reordered, i.e. they are commutative. For instance, 
> has-steps can be reordered without affecting the pipeline. When writing a 
> query optimizer I am often in a situation where I can only optimize a subset 
> of the supported steps and I might want to reorder them so that I can group 
> all the optimizable steps together. Currently, I have to manually identify 
> the commutative steps for that. It would be much nicer if TinkerPop could 
> have a "Commutative" marker interface for that and use it consistently.



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

[jira] [Commented] (TINKERPOP-1471) IncidentToAdjacentStrategy use hidden marker to avoid repeated recursion.

2016-11-01 Thread ASF GitHub Bot (JIRA)


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

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

GitHub user okram opened a pull request:

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

TINKERPOP-1471: IncidentToAdjacentStrategy use hidden marker to avoid 
repeated recursion.

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

Hidden labels can be used by strategies as a way to communicate between 
"layers" of the compilation tree. This model is now applied to 
`IncidentToAdjacentStrategy` where if the traversal (as a whole) should NOT be 
processed by `IncidentToAdjacentStrategy`, then each traversal in the tree is 
"marked." If the traversal can be processed by `IncidentToAdjacentStrategy`, 
then there is no need to mark the traversals. This removes the need to, for 
every traversal, do a recursion from the parent traversal looking for 
invalidating step classes.

VOTE +1.

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

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

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

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


commit 6a1a0741ea8ee64427a126e8980ecf7db1a3299a
Author: Marko A. Rodriguez 
Date:   2016-11-01T17:54:50Z

IncidentToAdjacentStrategy now uses a hidden marker label to remove the 
need for constant rootTraversal recrussion in search of invalidating steps.




> IncidentToAdjacentStrategy use hidden marker to avoid repeated recursion.
> -
>
> Key: TINKERPOP-1471
> URL: https://issues.apache.org/jira/browse/TINKERPOP-1471
> Project: TinkerPop
>  Issue Type: Improvement
>  Components: process
>Affects Versions: 3.2.2
>Reporter: Marko A. Rodriguez
>Assignee: Daniel Kuppitz
>
> TINKERPOP-1456 introduces the notion that "hidden labels" on steps will be 
> removed from the traversal prior to evaluation. This use of "hidden labels" 
> was necessary for {{SubgraphStrategy}} and it is not always possible to 
> remove the add "hidden labels" in {{SubgraphStrategy}} completely. Thus, 
> prior to evaluation, in hidden labels are removed.
> This concept of "hidden labels" is useful for marking steps in a traversal so 
> that  a strategy applied at a child gets information from the strategy 
> applied at a parent.
> This can be used to make {{IncidentToAdjacentStrategy}} faster. In 
> particular, the following recursion is called repeatedly for each child.
> {code}
>   if 
> (TraversalHelper.hasStepOfAssignableClassRecursively(INVALIDATING_STEP_CLASSES,
>  TraversalHelper.getRootTraversal(traversal)))
> return;
> {code}
> Instead, it would be smart to do this and then, you don't need to recurse 
> from the root traversal over and over again.
> {code}
> private final void addMarkerToChildren(final Traversal.Admin 
> traversal) {
> traversal.getStartStep().addLabel(MARKER);
> for (final Step step : traversal.getSteps()) {
> if (step instanceof TraversalParent) {
> ((TraversalParent) 
> step).getLocalChildren().forEach(this::addMarkerToChildren);
> ((TraversalParent) 
> step).getGlobalChildren().forEach(this::addMarkerToChildren);
> }
> }
> }
> public void apply(Traversal traversal) {
>   if(traversal.getParent() instanceof EmptyStep) {
> boolean mark = 
> TraversalHelper.hasStepOfAssignableClassRecursively(INVALIDATING_STEP_CLASSES,
>  traversal)
> if(mark)  this.addMarkerToChildren(traversal)
>   }
>   // if the marker exists, don't optimize
>   if(traversal.getStartStep().getLabels().contains(MARKER)) {
> traversal.getStartStep().removeLabel(MARKER);
> return;
>   }
> // else do the rest of the code.
> }
> {code}



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

[GitHub] tinkerpop pull request #474: TINKERPOP-1471: IncidentToAdjacentStrategy use ...

2016-11-01 Thread okram

GitHub user okram opened a pull request:

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

TINKERPOP-1471: IncidentToAdjacentStrategy use hidden marker to avoid 
repeated recursion.

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

Hidden labels can be used by strategies as a way to communicate between 
"layers" of the compilation tree. This model is now applied to 
`IncidentToAdjacentStrategy` where if the traversal (as a whole) should NOT be 
processed by `IncidentToAdjacentStrategy`, then each traversal in the tree is 
"marked." If the traversal can be processed by `IncidentToAdjacentStrategy`, 
then there is no need to mark the traversals. This removes the need to, for 
every traversal, do a recursion from the parent traversal looking for 
invalidating step classes.

VOTE +1.

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

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

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

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


commit 6a1a0741ea8ee64427a126e8980ecf7db1a3299a
Author: Marko A. Rodriguez 
Date:   2016-11-01T17:54:50Z

IncidentToAdjacentStrategy now uses a hidden marker label to remove the 
need for constant rootTraversal recrussion in search of invalidating 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] [Closed] (TINKERPOP-1537) Python tests should not use hard-coded number of workers

2016-11-01 Thread Daniel Kuppitz (JIRA)


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

Daniel Kuppitz closed TINKERPOP-1537.
-
   Resolution: Fixed
Fix Version/s: 3.2.4

CTR'ed via 
https://github.com/apache/tinkerpop/commit/333f2ab677bfb3e2ec35f1fb0123ec30eec248e3.

> Python tests should not use hard-coded number of workers
> 
>
> Key: TINKERPOP-1537
> URL: https://issues.apache.org/jira/browse/TINKERPOP-1537
> Project: TinkerPop
>  Issue Type: Bug
>Affects Versions: 3.2.3
>Reporter: Daniel Kuppitz
>Assignee: Daniel Kuppitz
> Fix For: 3.2.4
>
>
> https://github.com/apache/tinkerpop/blob/tp32/gremlin-python/src/main/jython/tests/driver/test_driver_remote_connection.py#L88
> This test will fail on systems with less than 4 CPUs. Instead we should use 
> something like {{min(4, multiprocessing.cpu_count())}}.
> Also see: 
> http://stackoverflow.com/questions/1006289/how-to-find-out-the-number-of-cpus-using-python



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

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

2016-11-01 Thread Daniel Kuppitz (JIRA)

Daniel Kuppitz created TINKERPOP-1538:
-

 Summary: 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] [Commented] (TINKERPOP-1372) ImmutablePath should not use Java recursion (call stacks are wack)

2016-11-01 Thread ASF GitHub Bot (JIRA)


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

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

GitHub user okram opened a pull request:

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

TINKERPOP-1372: ImmutablePath should not use Java recursion (call stacks 
are wack)

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

`ImmutablePath` used heavy method-recursion which is expensive in Java to 
create a new call stack for each recurse. All method-recursion has been 
replaced with `while(true)`-recursion. Furthermore, was able to get rid of 
`ImmutablePath.TailPath` with a `public static ImmutablePath TAIL_PATH = new 
ImmutablePath(null,null,null)`.  This makes things much cleaner and we don't 
need the package protected `ImmutablePathImpl` interface. Finally, I stole 
@pietermartin's trick to use direct reference to `Set` labels as the 
labels are immutable.

Here is a benchmark of a bunch of `match()`-traversals on the Grateful Dead 
graph where the first two columns are time in milliseconds and the last column 
is the number of returned results.

```
PREVIOUS   NEW # RESULTS

[12.676,  12.019,  93]  
[222.123, 177.596, 2952]
[27.187,  35.787,  6]
[80.917,  77.891,  5421]
[189.354, 176.308, 5096]
[14.644,  14.969,  18]
[2.214,   0.908,   3]
[924.093, 777.707, 314932]
```

VOTE +1.

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

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

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

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


commit 04fe38a28d3dce2a910c40c49658c083785b6473
Author: Marko A. Rodriguez 
Date:   2016-11-01T12:39:45Z

removed call stack recursion in ImmutablePath. All is while(true) based 
with a break on 'tail path.' ImmutablePath.TailPath is no longer required as 
the 'tail' is a the path segmanet with currentObject == null. Some preliminary 
tests show a significant speed up. Benchmark to follow suit. Added more test 
cases to PathTest. Removed TailPath Class.forName() in GryoRegistrator as it is 
no longer an existing class.

commit 3caa5c8aa38b108f9548ce345ddd97bd7378f99e
Author: Marko A. Rodriguez 
Date:   2016-11-01T12:41:17Z

removed ImmutablePathImpl. Was initially Deprecated as TailPath is no 
longer needed, but since its a package local interface, it is not possible to 
implement outside of the package. Thus, if its no longer used in the package, 
delete.

commit cd000995d1670170b9b5f3d726f20fb8cf45ffc9
Author: Marko A. Rodriguez 
Date:   2016-11-01T13:09:45Z

removed more method-based recursions in ImmutablePath and inlined the 
singleHead() and singleTail() methods as they are no longer interface methods 
and are only called in one other method.

commit 3896a981fdfced7b19a830738b2f3ef51f82672a
Author: Marko A. Rodriguez 
Date:   2016-11-01T13:19:54Z

Overrode Path.isSimple() default impl for ImmutablePath that doesn't create 
so many objects.

commit deaf38a7ed35f3236614d833eeb0eac2a25334fc
Author: Marko A. Rodriguez 
Date:   2016-11-01T14:27:08Z

added @pietermartin's direct reference to Step.getLabels() optimization to 
ImmutablePath. Added JavaDoc to Traverser for the dropLabels()/keepLabels() 
method. Fixed a spelling mistake in AbstractTraverser.




> ImmutablePath should not use Java recursion (call stacks are wack)
> --
>
> Key: TINKERPOP-1372
> URL: https://issues.apache.org/jira/browse/TINKERPOP-1372
> Project: TinkerPop
>  Issue Type: Improvement
>  Components: process
>Affects Versions: 3.2.0-incubating
>Reporter: Marko A. Rodriguez
>Assignee: Marko A. Rodriguez
>
> {{ImmutablePath}} sucks for a few reasons:
> 1. It has {{ImmutablePathImpl}} interface to combine {{Tail}} and 
> {{ImmutablePath}}. Lame.
> 2. It uses recurssion to find data. Lame.
> For 3.2.1, I have done a lot to use {{while()}}-based recursion and I suspect 
> I can gut {{ImmutablePathImpl}} and few other kooky things.



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

[GitHub] tinkerpop pull request #473: TINKERPOP-1372: ImmutablePath should not use Ja...

2016-11-01 Thread okram

GitHub user okram opened a pull request:

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

TINKERPOP-1372: ImmutablePath should not use Java recursion (call stacks 
are wack)

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

`ImmutablePath` used heavy method-recursion which is expensive in Java to 
create a new call stack for each recurse. All method-recursion has been 
replaced with `while(true)`-recursion. Furthermore, was able to get rid of 
`ImmutablePath.TailPath` with a `public static ImmutablePath TAIL_PATH = new 
ImmutablePath(null,null,null)`.  This makes things much cleaner and we don't 
need the package protected `ImmutablePathImpl` interface. Finally, I stole 
@pietermartin's trick to use direct reference to `Set` labels as the 
labels are immutable.

Here is a benchmark of a bunch of `match()`-traversals on the Grateful Dead 
graph where the first two columns are time in milliseconds and the last column 
is the number of returned results.

```
PREVIOUS   NEW # RESULTS

[12.676,  12.019,  93]  
[222.123, 177.596, 2952]
[27.187,  35.787,  6]
[80.917,  77.891,  5421]
[189.354, 176.308, 5096]
[14.644,  14.969,  18]
[2.214,   0.908,   3]
[924.093, 777.707, 314932]
```

VOTE +1.

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

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

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

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


commit 04fe38a28d3dce2a910c40c49658c083785b6473
Author: Marko A. Rodriguez 
Date:   2016-11-01T12:39:45Z

removed call stack recursion in ImmutablePath. All is while(true) based 
with a break on 'tail path.' ImmutablePath.TailPath is no longer required as 
the 'tail' is a the path segmanet with currentObject == null. Some preliminary 
tests show a significant speed up. Benchmark to follow suit. Added more test 
cases to PathTest. Removed TailPath Class.forName() in GryoRegistrator as it is 
no longer an existing class.

commit 3caa5c8aa38b108f9548ce345ddd97bd7378f99e
Author: Marko A. Rodriguez 
Date:   2016-11-01T12:41:17Z

removed ImmutablePathImpl. Was initially Deprecated as TailPath is no 
longer needed, but since its a package local interface, it is not possible to 
implement outside of the package. Thus, if its no longer used in the package, 
delete.

commit cd000995d1670170b9b5f3d726f20fb8cf45ffc9
Author: Marko A. Rodriguez 
Date:   2016-11-01T13:09:45Z

removed more method-based recursions in ImmutablePath and inlined the 
singleHead() and singleTail() methods as they are no longer interface methods 
and are only called in one other method.

commit 3896a981fdfced7b19a830738b2f3ef51f82672a
Author: Marko A. Rodriguez 
Date:   2016-11-01T13:19:54Z

Overrode Path.isSimple() default impl for ImmutablePath that doesn't create 
so many objects.

commit deaf38a7ed35f3236614d833eeb0eac2a25334fc
Author: Marko A. Rodriguez 
Date:   2016-11-01T14:27:08Z

added @pietermartin's direct reference to Step.getLabels() optimization to 
ImmutablePath. Added JavaDoc to Traverser for the dropLabels()/keepLabels() 
method. Fixed a spelling mistake in AbstractTraverser.




---
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: path query optimization

2016-11-01 Thread Marko Rodriguez

Hi,

So the one thing I just copied into TINKERPOP-1372 was your 
ImmutablePath.currentLabels = currentLabels (vs. copying the set). You are 
right, step labels are immutable and thus, there is no need to copy the set 
over — a direct reference is sufficient. Regarding the 
AbstractStep.traverserStepIdAndLabelsSetByChild changes — this isn’t so 
important as this is only used in OLAP  and thus, should be negligible relative 
to what else is going on in OLAP. However, to be good, I added the following:
@Override
public Path extend(final Set labels) {
if (labels.isEmpty())
return this;
else {
final Set newLabels = new LinkedHashSet<>();
newLabels.addAll(this.currentLabels);
newLabels.addAll(labels);
return new ImmutablePath(this.previousPath, this.currentObject, 
newLabels);
}
}
Thus, if the labels are empty, don’t clone.

This work along with the other recursion work in TINKERPOP-1372 provided a 
solid speed up. I’ll present benchmark results in the subsequent PR.

Thanks Pieter,
Marko.

http://markorodriguez.com



> On Nov 1, 2016, at 7:43 AM, pieter-gmail  wrote:
> 
> The branch is TINKERPOP-1404
> https://github.com/apache/tinkerpop/commit/c1556fe82c58527dc4425d23d1d69ce324e62cfa
> 
> Cheers
> Pieter
> 
> On 01/11/2016 15:23, Marko Rodriguez wrote:
>> What branch are you in? Perhaps give me URLs (to GitHub) to the files 
>> touched? (if its not too many)
>> 
>> Marko.
>> 
>> http://markorodriguez.com
>> 
>> 
>> 
>>> On Nov 1, 2016, at 7:19 AM, pieter-gmail  wrote:
>>> 
>>> Hi,
>>> 
>>> Yes I am but afraid I do not have time at present to concentrate on it.
>>> I just noticed your ImmutablePath ticket which will overlap with some of
>>> what I have done.
>>> 
>>> I'd suggest to pull my branch and look at what I did there. It was very
>>> little, but dangerous code, which is why I was reluctant to submit a PR
>>> at first. If you don't continue with it, I should in 2 or 3 weeks be
>>> able to look at it again.
>>> 
>>> Thanks
>>> Pieter
>>> 
>>> 
>>> On 01/11/2016 15:11, Marko Rodriguez wrote:
 Hi Pieter,
 
 I’m still really interested in your work in this area. Are you still doing 
 this?
 
 Marko.
 
 http://markorodriguez.com
 
 
 
> On Aug 7, 2016, at 9:12 AM, Pieter Martin  wrote:
> 
> To avoid the collection logic alltogether. For most steps there is no 
> need to
> check the labels as it is known that they are added, immutable and 
> correct.
> 
> Also with the current strategy the `ImmutablePath.currentLabels` is 
> exactly the
> same collection as that of the step. It is not a copy.
> 
> `Traverser.addLabels()` is only called for the steps previously 
> mentioned. They
> too can be optimized as there is no need to create a new `ImmutablePath` 
> just to
> set the labels. There could be a `Traverer.split()` method that creates 
> the
> initial `ImmutablePath` with the correct labels to start with. As things 
> stand
> now the `ImmutablePath` is created just to be replaced 1 or 2 millis 
> later. I
> have however not benchmarked any of those queries so am not touching that 
> at
> the moment.
> 
> In some ways its a matter of style. The label logic in `AbstractStep` is 
> not
> relevant to all of its subclasses and should be higher in the inheritance
> hierarchy.
> 
> Cheers
> Pieter
> 
> 
> Excerpts from Marko Rodriguez's message of August 7, 2016 3:54 :
>> Why not just check to see if the labels to be added already exist, if 
>> they do, don’t addLabels() and thus, don’t create a new collection.
>> Marko.
>> http://markorodriguez.com
>>> On Aug 7, 2016, at 6:07 AM, Pieter Martin  
>>> wrote:
>>> Here is what I have come up with so far.
>>> The idea is that `Traverser.split(r, step)` already copies the labels 
>>> to the
>>> traverser so there is no need to call `Traverser.addLabels(labels)` 
>>> again.
>>> I removed the `Traverser.addLabels(labels)` call from `AbstractStep`.
>>> For the traversers that do not call `Traverer.split(r, step)` I 
>>> manually added
>>> the `traverser.addLabels(labels)` call in `processNextStart()`. This 
>>> was done
>>> by fixing test failures rather than searching and investigating all 
>>> calls to
>>> `Traverser.split()`.
>>> The following steps needed the labels to be added manually.
>>> `AggregateStep`
>>> `CollectingBarrierStep`
>>> `FilterStep`
>>> `SideEffectStep`
>>> `StartStep`
>>> `NoOpBarrierStep`
>>> Further seeing as `Step.getLabels()` already returns a unmodifiable 
>>> collection and
>>> `ImmutablePath` is well immutable there is no need for it to have its 
>>> own copy
>>> of the labels. I set the

[jira] [Assigned] (TINKERPOP-1537) Python tests should not use hard-coded number of workers

2016-11-01 Thread Daniel Kuppitz (JIRA)


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

Daniel Kuppitz reassigned TINKERPOP-1537:
-

Assignee: Daniel Kuppitz

> Python tests should not use hard-coded number of workers
> 
>
> Key: TINKERPOP-1537
> URL: https://issues.apache.org/jira/browse/TINKERPOP-1537
> Project: TinkerPop
>  Issue Type: Bug
>Affects Versions: 3.2.3
>Reporter: Daniel Kuppitz
>Assignee: Daniel Kuppitz
>
> https://github.com/apache/tinkerpop/blob/tp32/gremlin-python/src/main/jython/tests/driver/test_driver_remote_connection.py#L88
> This test will fail on systems with less than 4 CPUs. Instead we should use 
> something like {{min(4, multiprocessing.cpu_count())}}.
> Also see: 
> http://stackoverflow.com/questions/1006289/how-to-find-out-the-number-of-cpus-using-python



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

Re: path query optimization

2016-11-01 Thread pieter-gmail

The branch is TINKERPOP-1404
https://github.com/apache/tinkerpop/commit/c1556fe82c58527dc4425d23d1d69ce324e62cfa

Cheers
Pieter

On 01/11/2016 15:23, Marko Rodriguez wrote:
> What branch are you in? Perhaps give me URLs (to GitHub) to the files 
> touched? (if its not too many)
>
> Marko.
>
> http://markorodriguez.com
>
>
>
>> On Nov 1, 2016, at 7:19 AM, pieter-gmail  wrote:
>>
>> Hi,
>>
>> Yes I am but afraid I do not have time at present to concentrate on it.
>> I just noticed your ImmutablePath ticket which will overlap with some of
>> what I have done.
>>
>> I'd suggest to pull my branch and look at what I did there. It was very
>> little, but dangerous code, which is why I was reluctant to submit a PR
>> at first. If you don't continue with it, I should in 2 or 3 weeks be
>> able to look at it again.
>>
>> Thanks
>> Pieter
>>
>>
>> On 01/11/2016 15:11, Marko Rodriguez wrote:
>>> Hi Pieter,
>>>
>>> I’m still really interested in your work in this area. Are you still doing 
>>> this?
>>>
>>> Marko.
>>>
>>> http://markorodriguez.com
>>>
>>>
>>>
 On Aug 7, 2016, at 9:12 AM, Pieter Martin  wrote:

 To avoid the collection logic alltogether. For most steps there is no need 
 to
 check the labels as it is known that they are added, immutable and correct.

 Also with the current strategy the `ImmutablePath.currentLabels` is 
 exactly the
 same collection as that of the step. It is not a copy.

 `Traverser.addLabels()` is only called for the steps previously mentioned. 
 They
 too can be optimized as there is no need to create a new `ImmutablePath` 
 just to
 set the labels. There could be a `Traverer.split()` method that creates the
 initial `ImmutablePath` with the correct labels to start with. As things 
 stand
 now the `ImmutablePath` is created just to be replaced 1 or 2 millis 
 later. I
 have however not benchmarked any of those queries so am not touching that 
 at
 the moment.

 In some ways its a matter of style. The label logic in `AbstractStep` is 
 not
 relevant to all of its subclasses and should be higher in the inheritance
 hierarchy.

 Cheers
 Pieter


 Excerpts from Marko Rodriguez's message of August 7, 2016 3:54 :
> Why not just check to see if the labels to be added already exist, if 
> they do, don’t addLabels() and thus, don’t create a new collection.
> Marko.
> http://markorodriguez.com
>> On Aug 7, 2016, at 6:07 AM, Pieter Martin  
>> wrote:
>> Here is what I have come up with so far.
>> The idea is that `Traverser.split(r, step)` already copies the labels to 
>> the
>> traverser so there is no need to call `Traverser.addLabels(labels)` 
>> again.
>> I removed the `Traverser.addLabels(labels)` call from `AbstractStep`.
>> For the traversers that do not call `Traverer.split(r, step)` I manually 
>> added
>> the `traverser.addLabels(labels)` call in `processNextStart()`. This was 
>> done
>> by fixing test failures rather than searching and investigating all 
>> calls to
>> `Traverser.split()`.
>> The following steps needed the labels to be added manually.
>> `AggregateStep`
>> `CollectingBarrierStep`
>> `FilterStep`
>> `SideEffectStep`
>> `StartStep`
>> `NoOpBarrierStep`
>> Further seeing as `Step.getLabels()` already returns a unmodifiable 
>> collection and
>> `ImmutablePath` is well immutable there is no need for it to have its 
>> own copy
>> of the labels. I set the labels directly on the path as oppose to making 
>> a copy.
>> `TinkerGraphProcessComputerTest` passes.
>> `TinkerGraphProcessStandardTest` passes.
>> `TinkerGraphStructureStandardTest` has one failure.
>> `SerializationTest$GryoTest.shouldSerializePathAsDetached` fails with
>> `java.lang.IllegalArgumentException: Class is not registered:
>> java.util.Collections$UnmodifiableSet`
>> Let me know what you think.
>> Thanks
>> Pieter
>> Excerpts from Ted Wilmes's message of August 7, 2016 12:16 :
>>> Neat find Pieter.  With regards to the update to ImmutablePath, I think
>>> that defensive copying of inbound collections is generally a good idea 
>>> but
>>> if we can target specific areas where we can reap big gains from not
>>> creating new collections it may be worth it to relax that constraint,
>>> especially if we're only talking about internal APIs.  If we do relax 
>>> that
>>> constraint though, we'll need to careful during code review and unit
>>> testing because those bugs can be difficult to track down.  The other 
>>> nice
>>> thing that the defensive copy gets us, particularly in the case of the
>>> ImmutablePath, is that it isolates ImmutablePath from whatever the 
>>> subclass
>>> of set

Re: path query optimization

2016-11-01 Thread Marko Rodriguez

What branch are you in? Perhaps give me URLs (to GitHub) to the files touched? 
(if its not too many)

Marko.

http://markorodriguez.com



> On Nov 1, 2016, at 7:19 AM, pieter-gmail  wrote:
> 
> Hi,
> 
> Yes I am but afraid I do not have time at present to concentrate on it.
> I just noticed your ImmutablePath ticket which will overlap with some of
> what I have done.
> 
> I'd suggest to pull my branch and look at what I did there. It was very
> little, but dangerous code, which is why I was reluctant to submit a PR
> at first. If you don't continue with it, I should in 2 or 3 weeks be
> able to look at it again.
> 
> Thanks
> Pieter
> 
> 
> On 01/11/2016 15:11, Marko Rodriguez wrote:
>> Hi Pieter,
>> 
>> I’m still really interested in your work in this area. Are you still doing 
>> this?
>> 
>> Marko.
>> 
>> http://markorodriguez.com
>> 
>> 
>> 
>>> On Aug 7, 2016, at 9:12 AM, Pieter Martin  wrote:
>>> 
>>> To avoid the collection logic alltogether. For most steps there is no need 
>>> to
>>> check the labels as it is known that they are added, immutable and correct.
>>> 
>>> Also with the current strategy the `ImmutablePath.currentLabels` is exactly 
>>> the
>>> same collection as that of the step. It is not a copy.
>>> 
>>> `Traverser.addLabels()` is only called for the steps previously mentioned. 
>>> They
>>> too can be optimized as there is no need to create a new `ImmutablePath` 
>>> just to
>>> set the labels. There could be a `Traverer.split()` method that creates the
>>> initial `ImmutablePath` with the correct labels to start with. As things 
>>> stand
>>> now the `ImmutablePath` is created just to be replaced 1 or 2 millis later. 
>>> I
>>> have however not benchmarked any of those queries so am not touching that at
>>> the moment.
>>> 
>>> In some ways its a matter of style. The label logic in `AbstractStep` is not
>>> relevant to all of its subclasses and should be higher in the inheritance
>>> hierarchy.
>>> 
>>> Cheers
>>> Pieter
>>> 
>>> 
>>> Excerpts from Marko Rodriguez's message of August 7, 2016 3:54 :
 Why not just check to see if the labels to be added already exist, if they 
 do, don’t addLabels() and thus, don’t create a new collection.
 Marko.
 http://markorodriguez.com
> On Aug 7, 2016, at 6:07 AM, Pieter Martin  wrote:
> Here is what I have come up with so far.
> The idea is that `Traverser.split(r, step)` already copies the labels to 
> the
> traverser so there is no need to call `Traverser.addLabels(labels)` again.
> I removed the `Traverser.addLabels(labels)` call from `AbstractStep`.
> For the traversers that do not call `Traverer.split(r, step)` I manually 
> added
> the `traverser.addLabels(labels)` call in `processNextStart()`. This was 
> done
> by fixing test failures rather than searching and investigating all calls 
> to
> `Traverser.split()`.
> The following steps needed the labels to be added manually.
> `AggregateStep`
> `CollectingBarrierStep`
> `FilterStep`
> `SideEffectStep`
> `StartStep`
> `NoOpBarrierStep`
> Further seeing as `Step.getLabels()` already returns a unmodifiable 
> collection and
> `ImmutablePath` is well immutable there is no need for it to have its own 
> copy
> of the labels. I set the labels directly on the path as oppose to making 
> a copy.
> `TinkerGraphProcessComputerTest` passes.
> `TinkerGraphProcessStandardTest` passes.
> `TinkerGraphStructureStandardTest` has one failure.
> `SerializationTest$GryoTest.shouldSerializePathAsDetached` fails with
> `java.lang.IllegalArgumentException: Class is not registered:
> java.util.Collections$UnmodifiableSet`
> Let me know what you think.
> Thanks
> Pieter
> Excerpts from Ted Wilmes's message of August 7, 2016 12:16 :
>> Neat find Pieter.  With regards to the update to ImmutablePath, I think
>> that defensive copying of inbound collections is generally a good idea 
>> but
>> if we can target specific areas where we can reap big gains from not
>> creating new collections it may be worth it to relax that constraint,
>> especially if we're only talking about internal APIs.  If we do relax 
>> that
>> constraint though, we'll need to careful during code review and unit
>> testing because those bugs can be difficult to track down.  The other 
>> nice
>> thing that the defensive copy gets us, particularly in the case of the
>> ImmutablePath, is that it isolates ImmutablePath from whatever the 
>> subclass
>> of set was that the caller passed in.  I think that's what is causing the
>> serialization test failure in this case since the caller passed in an
>> unmodifiable set.
>> --Ted
>> On Fri, Aug 5, 2016, 2:31 PM Marko Rodriguez  
>> wrote:
>>> Hello,
>>> This is cool.

Re: path query optimization

2016-11-01 Thread pieter-gmail

Hi,

Yes I am but afraid I do not have time at present to concentrate on it.
I just noticed your ImmutablePath ticket which will overlap with some of
what I have done.

I'd suggest to pull my branch and look at what I did there. It was very
little, but dangerous code, which is why I was reluctant to submit a PR
at first. If you don't continue with it, I should in 2 or 3 weeks be
able to look at it again.

Thanks
Pieter


On 01/11/2016 15:11, Marko Rodriguez wrote:
> Hi Pieter,
>
> I’m still really interested in your work in this area. Are you still doing 
> this?
>
> Marko.
>
> http://markorodriguez.com
>
>
>
>> On Aug 7, 2016, at 9:12 AM, Pieter Martin  wrote:
>>
>> To avoid the collection logic alltogether. For most steps there is no need to
>> check the labels as it is known that they are added, immutable and correct.
>>
>> Also with the current strategy the `ImmutablePath.currentLabels` is exactly 
>> the
>> same collection as that of the step. It is not a copy.
>>
>> `Traverser.addLabels()` is only called for the steps previously mentioned. 
>> They
>> too can be optimized as there is no need to create a new `ImmutablePath` 
>> just to
>> set the labels. There could be a `Traverer.split()` method that creates the
>> initial `ImmutablePath` with the correct labels to start with. As things 
>> stand
>> now the `ImmutablePath` is created just to be replaced 1 or 2 millis later. I
>> have however not benchmarked any of those queries so am not touching that at
>> the moment.
>>
>> In some ways its a matter of style. The label logic in `AbstractStep` is not
>> relevant to all of its subclasses and should be higher in the inheritance
>> hierarchy.
>>
>> Cheers
>> Pieter
>>
>>
>> Excerpts from Marko Rodriguez's message of August 7, 2016 3:54 :
>>> Why not just check to see if the labels to be added already exist, if they 
>>> do, don’t addLabels() and thus, don’t create a new collection.
>>> Marko.
>>> http://markorodriguez.com
 On Aug 7, 2016, at 6:07 AM, Pieter Martin  wrote:
 Here is what I have come up with so far.
 The idea is that `Traverser.split(r, step)` already copies the labels to 
 the
 traverser so there is no need to call `Traverser.addLabels(labels)` again.
 I removed the `Traverser.addLabels(labels)` call from `AbstractStep`.
 For the traversers that do not call `Traverer.split(r, step)` I manually 
 added
 the `traverser.addLabels(labels)` call in `processNextStart()`. This was 
 done
 by fixing test failures rather than searching and investigating all calls 
 to
 `Traverser.split()`.
 The following steps needed the labels to be added manually.
 `AggregateStep`
 `CollectingBarrierStep`
 `FilterStep`
 `SideEffectStep`
 `StartStep`
 `NoOpBarrierStep`
 Further seeing as `Step.getLabels()` already returns a unmodifiable 
 collection and
 `ImmutablePath` is well immutable there is no need for it to have its own 
 copy
 of the labels. I set the labels directly on the path as oppose to making a 
 copy.
 `TinkerGraphProcessComputerTest` passes.
 `TinkerGraphProcessStandardTest` passes.
 `TinkerGraphStructureStandardTest` has one failure.
 `SerializationTest$GryoTest.shouldSerializePathAsDetached` fails with
 `java.lang.IllegalArgumentException: Class is not registered:
 java.util.Collections$UnmodifiableSet`
 Let me know what you think.
 Thanks
 Pieter
 Excerpts from Ted Wilmes's message of August 7, 2016 12:16 :
> Neat find Pieter.  With regards to the update to ImmutablePath, I think
> that defensive copying of inbound collections is generally a good idea but
> if we can target specific areas where we can reap big gains from not
> creating new collections it may be worth it to relax that constraint,
> especially if we're only talking about internal APIs.  If we do relax that
> constraint though, we'll need to careful during code review and unit
> testing because those bugs can be difficult to track down.  The other nice
> thing that the defensive copy gets us, particularly in the case of the
> ImmutablePath, is that it isolates ImmutablePath from whatever the 
> subclass
> of set was that the caller passed in.  I think that's what is causing the
> serialization test failure in this case since the caller passed in an
> unmodifiable set.
> --Ted
> On Fri, Aug 5, 2016, 2:31 PM Marko Rodriguez  wrote:
>> Hello,
>> This is cool. Check out also ImmutablePath.extend(labels) as that is
>> ultimately what Traverser.addLabels() calls. We have a lot of set copying
>> and I don’t know if its needed (as you seem to be demonstrating). What I
>> don’t like about your solution is the explicit reference to the
>> B_L_P…Traverser in AbstractStep. See if you can work your solution 
>> without
>> it.
>> Good

[jira] [Commented] (TINKERPOP-1537) Python tests should not use hard-coded number of workers

2016-11-01 Thread Marko A. Rodriguez (JIRA)


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

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

Ah. Yea, that is my bad. Can you handle this and push it to {{tp32/}}? I don't 
think you need a PR as its pretty basic. I would just test it locally and CTR 
it. If {{cpu_count()}} doesn't work (for whatever reason), just remove the 
{{workers=4}} parameter. Its not necessary.

> Python tests should not use hard-coded number of workers
> 
>
> Key: TINKERPOP-1537
> URL: https://issues.apache.org/jira/browse/TINKERPOP-1537
> Project: TinkerPop
>  Issue Type: Bug
>Affects Versions: 3.2.3
>Reporter: Daniel Kuppitz
>
> https://github.com/apache/tinkerpop/blob/tp32/gremlin-python/src/main/jython/tests/driver/test_driver_remote_connection.py#L88
> This test will fail on systems with less than 4 CPUs. Instead we should use 
> something like {{min(4, multiprocessing.cpu_count())}}.
> Also see: 
> http://stackoverflow.com/questions/1006289/how-to-find-out-the-number-of-cpus-using-python



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

Re: path query optimization

2016-11-01 Thread Marko Rodriguez

Hi Pieter,

I’m still really interested in your work in this area. Are you still doing this?

Marko.

http://markorodriguez.com



> On Aug 7, 2016, at 9:12 AM, Pieter Martin  wrote:
> 
> To avoid the collection logic alltogether. For most steps there is no need to
> check the labels as it is known that they are added, immutable and correct.
> 
> Also with the current strategy the `ImmutablePath.currentLabels` is exactly 
> the
> same collection as that of the step. It is not a copy.
> 
> `Traverser.addLabels()` is only called for the steps previously mentioned. 
> They
> too can be optimized as there is no need to create a new `ImmutablePath` just 
> to
> set the labels. There could be a `Traverer.split()` method that creates the
> initial `ImmutablePath` with the correct labels to start with. As things stand
> now the `ImmutablePath` is created just to be replaced 1 or 2 millis later. I
> have however not benchmarked any of those queries so am not touching that at
> the moment.
> 
> In some ways its a matter of style. The label logic in `AbstractStep` is not
> relevant to all of its subclasses and should be higher in the inheritance
> hierarchy.
> 
> Cheers
> Pieter
> 
> 
> Excerpts from Marko Rodriguez's message of August 7, 2016 3:54 :
>> Why not just check to see if the labels to be added already exist, if they 
>> do, don’t addLabels() and thus, don’t create a new collection.
>> Marko.
>> http://markorodriguez.com
>>> On Aug 7, 2016, at 6:07 AM, Pieter Martin  wrote:
>>> Here is what I have come up with so far.
>>> The idea is that `Traverser.split(r, step)` already copies the labels to the
>>> traverser so there is no need to call `Traverser.addLabels(labels)` again.
>>> I removed the `Traverser.addLabels(labels)` call from `AbstractStep`.
>>> For the traversers that do not call `Traverer.split(r, step)` I manually 
>>> added
>>> the `traverser.addLabels(labels)` call in `processNextStart()`. This was 
>>> done
>>> by fixing test failures rather than searching and investigating all calls to
>>> `Traverser.split()`.
>>> The following steps needed the labels to be added manually.
>>> `AggregateStep`
>>> `CollectingBarrierStep`
>>> `FilterStep`
>>> `SideEffectStep`
>>> `StartStep`
>>> `NoOpBarrierStep`
>>> Further seeing as `Step.getLabels()` already returns a unmodifiable 
>>> collection and
>>> `ImmutablePath` is well immutable there is no need for it to have its own 
>>> copy
>>> of the labels. I set the labels directly on the path as oppose to making a 
>>> copy.
>>> `TinkerGraphProcessComputerTest` passes.
>>> `TinkerGraphProcessStandardTest` passes.
>>> `TinkerGraphStructureStandardTest` has one failure.
>>> `SerializationTest$GryoTest.shouldSerializePathAsDetached` fails with
>>> `java.lang.IllegalArgumentException: Class is not registered:
>>> java.util.Collections$UnmodifiableSet`
>>> Let me know what you think.
>>> Thanks
>>> Pieter
>>> Excerpts from Ted Wilmes's message of August 7, 2016 12:16 :
 Neat find Pieter.  With regards to the update to ImmutablePath, I think
 that defensive copying of inbound collections is generally a good idea but
 if we can target specific areas where we can reap big gains from not
 creating new collections it may be worth it to relax that constraint,
 especially if we're only talking about internal APIs.  If we do relax that
 constraint though, we'll need to careful during code review and unit
 testing because those bugs can be difficult to track down.  The other nice
 thing that the defensive copy gets us, particularly in the case of the
 ImmutablePath, is that it isolates ImmutablePath from whatever the subclass
 of set was that the caller passed in.  I think that's what is causing the
 serialization test failure in this case since the caller passed in an
 unmodifiable set.
 --Ted
 On Fri, Aug 5, 2016, 2:31 PM Marko Rodriguez  wrote:
> Hello,
> This is cool. Check out also ImmutablePath.extend(labels) as that is
> ultimately what Traverser.addLabels() calls. We have a lot of set copying
> and I don’t know if its needed (as you seem to be demonstrating). What I
> don’t like about your solution is the explicit reference to the
> B_L_P…Traverser in AbstractStep. See if you can work your solution without
> it.
> Good luck,
> Marko.
> http://markorodriguez.com
> > On Aug 5, 2016, at 12:44 PM, pieter-gmail 
> wrote:
> >
> > Sorry forgot to add a rather important part.
> >
> > I changed ImmutablePath's constructor to
> >
> >private ImmutablePath(final ImmutablePathImpl previousPath, final
> > Object currentObject, final Set currentLabels) {
> >this.previousPath = previousPath;
> >this.currentObject = currentObject;
> >this.currentLabels = currentLabels;
> > //

[jira] [Created] (TINKERPOP-1537) Python tests should not use hard-coded number of workers

2016-11-01 Thread Daniel Kuppitz (JIRA)

Daniel Kuppitz created TINKERPOP-1537:
-

 Summary: Python tests should not use hard-coded number of workers
 Key: TINKERPOP-1537
 URL: https://issues.apache.org/jira/browse/TINKERPOP-1537
 Project: TinkerPop
  Issue Type: Bug
Affects Versions: 3.2.3
Reporter: Daniel Kuppitz


https://github.com/apache/tinkerpop/blob/tp32/gremlin-python/src/main/jython/tests/driver/test_driver_remote_connection.py#L88

This test will fail on systems with less than 4 CPUs. Instead we should use 
something like {{min(4, multiprocessing.cpu_count())}}.

Also see: 
http://stackoverflow.com/questions/1006289/how-to-find-out-the-number-of-cpus-using-python



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

[jira] [Assigned] (TINKERPOP-1372) ImmutablePath should not use Java recursion (call stacks are wack)

2016-11-01 Thread Marko A. Rodriguez (JIRA)


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

Marko A. Rodriguez reassigned TINKERPOP-1372:
-

Assignee: Marko A. Rodriguez

> ImmutablePath should not use Java recursion (call stacks are wack)
> --
>
> Key: TINKERPOP-1372
> URL: https://issues.apache.org/jira/browse/TINKERPOP-1372
> Project: TinkerPop
>  Issue Type: Improvement
>  Components: process
>Affects Versions: 3.2.0-incubating
>Reporter: Marko A. Rodriguez
>Assignee: Marko A. Rodriguez
>
> {{ImmutablePath}} sucks for a few reasons:
> 1. It has {{ImmutablePathImpl}} interface to combine {{Tail}} and 
> {{ImmutablePath}}. Lame.
> 2. It uses recurssion to find data. Lame.
> For 3.2.1, I have done a lot to use {{while()}}-based recursion and I suspect 
> I can gut {{ImmutablePathImpl}} and few other kooky things.



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

[jira] [Created] (TINKERPOP-1536) Include GLVs in Docker build

2016-11-01 Thread Daniel Kuppitz (JIRA)

Daniel Kuppitz created TINKERPOP-1536:
-

 Summary: Include GLVs in Docker build
 Key: TINKERPOP-1536
 URL: https://issues.apache.org/jira/browse/TINKERPOP-1536
 Project: TinkerPop
  Issue Type: Improvement
  Components: language-variant
Affects Versions: 3.2.3
Reporter: Daniel Kuppitz
Assignee: Daniel Kuppitz
 Fix For: 3.3.0


This requires a change in the Docker container definitions, hence it should 
only go into 3.3.0.



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

[jira] [Commented] (TINKERPOP-1420) Remove deprecated ConcurrentBindings in gremlin-groovy

2016-11-01 Thread ASF GitHub Bot (JIRA)


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

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

Github user spmallette commented on the issue:

https://github.com/apache/tinkerpop/pull/468
  
I've had three goods builds in a row with docker now on this branch. I also 
cleared my containers/images and it's been good since.


> Remove deprecated ConcurrentBindings in gremlin-groovy
> --
>
> Key: TINKERPOP-1420
> URL: https://issues.apache.org/jira/browse/TINKERPOP-1420
> Project: TinkerPop
>  Issue Type: Improvement
>  Components: groovy
>Affects Versions: 3.2.1
>Reporter: stephen mallette
>Priority: Minor
>  Labels: breaking, deprecation
>
> {{ConcurrentBindings}} were moved to to {{gremlin-core}} - the old class in 
> {{gremlin-groovy}} was deprecated and can be removed.



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

[GitHub] tinkerpop issue #468: TINKERPOP-1420 Removal of previously deprecated gremli...

2016-11-01 Thread spmallette

Github user spmallette commented on the issue:

https://github.com/apache/tinkerpop/pull/468
  
I've had three goods builds in a row with docker now on this branch. I also 
cleared my containers/images and it's been good since.


---
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-1420) Remove deprecated ConcurrentBindings in gremlin-groovy

2016-11-01 Thread ASF GitHub Bot (JIRA)


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

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

Github user dkuppitz commented on the issue:

https://github.com/apache/tinkerpop/pull/468
  
So weird. Build succeeded with `docker/build.sh -t -i -n`  after I've 
rebuilt my containers and removed the `.glv` file from my `gremlin-python` 
directory.

VOTE: +1


> Remove deprecated ConcurrentBindings in gremlin-groovy
> --
>
> Key: TINKERPOP-1420
> URL: https://issues.apache.org/jira/browse/TINKERPOP-1420
> Project: TinkerPop
>  Issue Type: Improvement
>  Components: groovy
>Affects Versions: 3.2.1
>Reporter: stephen mallette
>Priority: Minor
>  Labels: breaking, deprecation
>
> {{ConcurrentBindings}} were moved to to {{gremlin-core}} - the old class in 
> {{gremlin-groovy}} was deprecated and can be removed.



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

[GitHub] tinkerpop issue #468: TINKERPOP-1420 Removal of previously deprecated gremli...

2016-11-01 Thread dkuppitz

Github user dkuppitz commented on the issue:

https://github.com/apache/tinkerpop/pull/468
  
So weird. Build succeeded with `docker/build.sh -t -i -n`  after I've 
rebuilt my containers and removed the `.glv` file from my `gremlin-python` 
directory.

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

37 matches

Mail list logo