[GitHub] tinkerpop issue #748: TINKERPOP-1834: Consider iterate() as a first class st...

2017-11-21 Thread okram
Github user okram commented on the issue:

https://github.com/apache/tinkerpop/pull/748
  
Closing. Going to provide a simpler solution.


---


[GitHub] tinkerpop issue #748: TINKERPOP-1834: Consider iterate() as a first class st...

2017-11-20 Thread okram
Github user okram commented on the issue:

https://github.com/apache/tinkerpop/pull/748
  
A `cap()` step is a `SupplyBarrierStep` and thus, requires an emission -- a 
single emission, but an emission nonetheless. The ultimate solution step has to 
a `FilterStep` by nature so it can truly return "nothing." However, we are now 
getting into particulars that don't need arguing. The concept is what matters. 
Now that I get the problem, you simply don't want to have to "reattach" and 
send data back if you don't have to, then the solution is, filter everything as 
the last step. That is, have `iterate()` append to the bytecode a "filter all." 
Easy. How that is done, just needs some fiddlin' around.


---


[GitHub] tinkerpop issue #748: TINKERPOP-1834: Consider iterate() as a first class st...

2017-11-20 Thread spmallette
Github user spmallette commented on the issue:

https://github.com/apache/tinkerpop/pull/748
  
I think I like @BrynCooke  suggestion. an empty `cap()` currently generates 
an error so this might be a good use for it. being equivalent to `iterate()` 
seems logical to me.


---


[GitHub] tinkerpop issue #748: TINKERPOP-1834: Consider iterate() as a first class st...

2017-11-20 Thread BrynCooke
Github user BrynCooke commented on the issue:

https://github.com/apache/tinkerpop/pull/748
  
Would a cap step with no side effect keys be a better fit here rather than 
filter?
It would remove the need for a 'false' traversal.


---


[GitHub] tinkerpop issue #748: TINKERPOP-1834: Consider iterate() as a first class st...

2017-11-17 Thread dkuppitz
Github user dkuppitz commented on the issue:

https://github.com/apache/tinkerpop/pull/748
  
`filter(false)` == `not(identity())`


---


[GitHub] tinkerpop issue #748: TINKERPOP-1834: Consider iterate() as a first class st...

2017-11-17 Thread spmallette
Github user spmallette commented on the issue:

https://github.com/apache/tinkerpop/pull/748
  
oh`filter(false)` referred to adding a `FilterStep` to the end of the 
traversal basically that didn't allow any traversers through. Of course, a 
provider writing a `TraversalStrategy` wouldn't be able to detect "false" if 
you use the a lambda in `filter()`, so the provider couldn't optimize properly. 
Are you thinking something else here?


---


[GitHub] tinkerpop issue #748: TINKERPOP-1834: Consider iterate() as a first class st...

2017-11-17 Thread okram
Github user okram commented on the issue:

https://github.com/apache/tinkerpop/pull/748
  
There is nothing for "the server" to know. Thus, gutting the introspection. 
By appending `filter(false)` to the bytecode, you have a traversal that returns 
nothing. Which is exactly what you want. No need for the receiving/executing 
engine to reason about anything. A 3-line change to `iterate()` would do the 
trick.


---


[GitHub] tinkerpop issue #748: TINKERPOP-1834: Consider iterate() as a first class st...

2017-11-16 Thread okram
Github user okram commented on the issue:

https://github.com/apache/tinkerpop/pull/748
  
I think we over engineered this ticket. I believe @dkuppitz has the best 
idea.

```
public Traversal iterate() {
  this.filter(false);
  while(hasNext()) {
next();
  } 
  return this;
}
```




---


[GitHub] tinkerpop issue #748: TINKERPOP-1834: Consider iterate() as a first class st...

2017-11-16 Thread okram
Github user okram commented on the issue:

https://github.com/apache/tinkerpop/pull/748
  
Makes sense.


---


[GitHub] tinkerpop issue #748: TINKERPOP-1834: Consider iterate() as a first class st...

2017-11-16 Thread spmallette
Github user spmallette commented on the issue:

https://github.com/apache/tinkerpop/pull/748
  
In reviewing this, I think Gremlin Server needs a change. When we submit a 
remote traversal. Gremlin Server needs to check for `iterate()` in the bytecode 
and actually call `iterate()` rather than `next()` that way the graph instance 
gets the right method called on it for any additional optimization that could 
occur there. Plus, if the client did call `iterate()` it's better that Gremlin 
Server simply return no results - that's a big optimization. I can work on that 
change and just commit it to this branch as part of this PR.


---


[GitHub] tinkerpop issue #748: TINKERPOP-1834: Consider iterate() as a first class st...

2017-11-15 Thread okram
Github user okram commented on the issue:

https://github.com/apache/tinkerpop/pull/748
  
```
[INFO] 

[INFO] BUILD SUCCESS
[INFO] 

[INFO] Total time: 02:30 h
[INFO] Finished at: 2017-11-15T12:13:52-07:00
[INFO] Final Memory: 164M/1526M
[INFO] 

```


---