date:20161102


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

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

Github user dkuppitz commented on the issue:

https://github.com/apache/tinkerpop/pull/479
  
Unfortunately I still get the same errors. Looks like they always happen in 
`RemoteGraphGroovyTranslatorProcessStandardTest`.


> Block calls to traversal side-effects until read is complete
> 
>
> Key: TINKERPOP-1434
> URL: https://issues.apache.org/jira/browse/TINKERPOP-1434
> Project: TinkerPop
>  Issue Type: Improvement
>  Components: driver
>Affects Versions: 3.2.2
>Reporter: stephen mallette
>Assignee: stephen mallette
>Priority: Minor
>
> Might make usability a little better if calls to {{getSideEffects()}} could 
> block until the remote {{Traversal}} complete iteration (i.e. on "read 
> complete") - or perhaps they return a {{Future}} or something.



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

[GitHub] tinkerpop issue #471: TINKERPOP-1506: Optional/Coalesce should not allow sid...

Github user spmallette commented on the issue:

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

VOTE +1


---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

[jira] [Commented] (TINKERPOP-1506) Optional/Coalesce should not allow sideEffect traversals.


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

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

Github user spmallette commented on the issue:

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

VOTE +1


> Optional/Coalesce should not allow sideEffect traversals.
> -
>
> Key: TINKERPOP-1506
> URL: https://issues.apache.org/jira/browse/TINKERPOP-1506
> Project: TinkerPop
>  Issue Type: Improvement
>  Components: process
>Affects Versions: 3.1.4, 3.2.2
>Reporter: Marko A. Rodriguez
>Assignee: Marko A. Rodriguez
> Fix For: 3.3.0
>
>
> It took me a long time to realize what was wrong with a traversal I wrote 
> that used {{optional(blah.sideEffect.blah)}}. {{optional()}} maps to 
> {{ChooseStep}} under the hood and the provide traversal is first tested for a 
> {{hasNext()}}. If so, the it plays itself out. The problem is that if there 
> is a side-effect in the traversal child, then it gets executed twice. 
> {code}
> gremlin> g = TinkerGraph.open().traversal()
> ==>graphtraversalsource[tinkergraph[vertices:0 edges:0], standard]
> gremlin> g.inject(1).optional(addV('twin'))
> ==>v[1]
> gremlin> g.V().valueMap(true)
> ==>[id:0,label:twin]
> ==>[id:1,label:twin]
> {code}
> We should NOT allow {{optional()}} to have {{SideEffectStep}} steps in it so 
> as not to cause unexpected behavior. {{StandardVerificationStrategy}} can 
> analyze and throw an exception if necessary.
> Also, {{coalesce()}} has a similar problem, though perhaps it can be a useful 
> 'technique.'
> {code}
> gremlin> g = TinkerGraph.open().traversal()
> ==>graphtraversalsource[tinkergraph[vertices:0 edges:0], standard]
> gremlin> g.inject(1).coalesce(addV('twin1').limit(0), addV('twin2'))
> ==>v[1]
> gremlin> g.V().valueMap(true)
> ==>[id:0,label:twin1]
> ==>[id:1,label:twin2]
> gremlin>
> {code}



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

[jira] [Created] (TINKERPOP-1543) Create a distinct language archetype.

Marko A. Rodriguez created TINKERPOP-1543:
-

 Summary: Create a distinct language archetype.
 Key: TINKERPOP-1543
 URL: https://issues.apache.org/jira/browse/TINKERPOP-1543
 Project: TinkerPop
  Issue Type: Improvement
  Components: documentation, language-variant
Affects Versions: 3.2.3
Reporter: Marko A. Rodriguez
Assignee: Marko A. Rodriguez


I want to do a "demo language" to show people how to create a language that 
compiles to Gremlin bytecode.

I believe this should be done via the {{gremlin-archetype}} framework?? (cc/ 
[~spmallette].

The language would be the 2D "pipe" language discussed on gremlin-users@. List 
of potential names for the language:

* GremlinDimensions
* gThang
* 2g
* StraightG

This archetype would include:

1. A language parser.
2. Connectivity to the process test suite.
3. Documentation.

If [~spmallette] or [~dkuppitz] could set me up a branch with the "archetype" 
stubbed, that would be super helpful and I can then nerd out from there.




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

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


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

Marko A. Rodriguez closed TINKERPOP-1372.
-
   Resolution: Fixed
Fix Version/s: 3.2.4

> 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
> Fix For: 3.2.4
>
>
> {{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] [Closed] (TINKERPOP-1506) Optional/Coalesce should not allow sideEffect traversals.


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

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

> Optional/Coalesce should not allow sideEffect traversals.
> -
>
> Key: TINKERPOP-1506
> URL: https://issues.apache.org/jira/browse/TINKERPOP-1506
> Project: TinkerPop
>  Issue Type: Improvement
>  Components: process
>Affects Versions: 3.1.4, 3.2.2
>Reporter: Marko A. Rodriguez
>Assignee: Marko A. Rodriguez
> Fix For: 3.3.0
>
>
> It took me a long time to realize what was wrong with a traversal I wrote 
> that used {{optional(blah.sideEffect.blah)}}. {{optional()}} maps to 
> {{ChooseStep}} under the hood and the provide traversal is first tested for a 
> {{hasNext()}}. If so, the it plays itself out. The problem is that if there 
> is a side-effect in the traversal child, then it gets executed twice. 
> {code}
> gremlin> g = TinkerGraph.open().traversal()
> ==>graphtraversalsource[tinkergraph[vertices:0 edges:0], standard]
> gremlin> g.inject(1).optional(addV('twin'))
> ==>v[1]
> gremlin> g.V().valueMap(true)
> ==>[id:0,label:twin]
> ==>[id:1,label:twin]
> {code}
> We should NOT allow {{optional()}} to have {{SideEffectStep}} steps in it so 
> as not to cause unexpected behavior. {{StandardVerificationStrategy}} can 
> analyze and throw an exception if necessary.
> Also, {{coalesce()}} has a similar problem, though perhaps it can be a useful 
> 'technique.'
> {code}
> gremlin> g = TinkerGraph.open().traversal()
> ==>graphtraversalsource[tinkergraph[vertices:0 edges:0], standard]
> gremlin> g.inject(1).coalesce(addV('twin1').limit(0), addV('twin2'))
> ==>v[1]
> gremlin> g.V().valueMap(true)
> ==>[id:0,label:twin1]
> ==>[id:1,label:twin2]
> gremlin>
> {code}



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

[jira] [Assigned] (TINKERPOP-1506) Optional/Coalesce should not allow sideEffect traversals.


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

Marko A. Rodriguez reassigned TINKERPOP-1506:
-

Assignee: Marko A. Rodriguez

> Optional/Coalesce should not allow sideEffect traversals.
> -
>
> Key: TINKERPOP-1506
> URL: https://issues.apache.org/jira/browse/TINKERPOP-1506
> Project: TinkerPop
>  Issue Type: Improvement
>  Components: process
>Affects Versions: 3.1.4, 3.2.2
>Reporter: Marko A. Rodriguez
>Assignee: Marko A. Rodriguez
> Fix For: 3.3.0
>
>
> It took me a long time to realize what was wrong with a traversal I wrote 
> that used {{optional(blah.sideEffect.blah)}}. {{optional()}} maps to 
> {{ChooseStep}} under the hood and the provide traversal is first tested for a 
> {{hasNext()}}. If so, the it plays itself out. The problem is that if there 
> is a side-effect in the traversal child, then it gets executed twice. 
> {code}
> gremlin> g = TinkerGraph.open().traversal()
> ==>graphtraversalsource[tinkergraph[vertices:0 edges:0], standard]
> gremlin> g.inject(1).optional(addV('twin'))
> ==>v[1]
> gremlin> g.V().valueMap(true)
> ==>[id:0,label:twin]
> ==>[id:1,label:twin]
> {code}
> We should NOT allow {{optional()}} to have {{SideEffectStep}} steps in it so 
> as not to cause unexpected behavior. {{StandardVerificationStrategy}} can 
> analyze and throw an exception if necessary.
> Also, {{coalesce()}} has a similar problem, though perhaps it can be a useful 
> 'technique.'
> {code}
> gremlin> g = TinkerGraph.open().traversal()
> ==>graphtraversalsource[tinkergraph[vertices:0 edges:0], standard]
> gremlin> g.inject(1).coalesce(addV('twin1').limit(0), addV('twin2'))
> ==>v[1]
> gremlin> g.V().valueMap(true)
> ==>[id:0,label:twin1]
> ==>[id:1,label:twin2]
> gremlin>
> {code}



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

[jira] [Commented] (TINKERPOP-1506) Optional/Coalesce should not allow sideEffect traversals.


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

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

Github user asfgit closed the pull request at:

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


> Optional/Coalesce should not allow sideEffect traversals.
> -
>
> Key: TINKERPOP-1506
> URL: https://issues.apache.org/jira/browse/TINKERPOP-1506
> Project: TinkerPop
>  Issue Type: Improvement
>  Components: process
>Affects Versions: 3.1.4, 3.2.2
>Reporter: Marko A. Rodriguez
>Assignee: Marko A. Rodriguez
> Fix For: 3.3.0
>
>
> It took me a long time to realize what was wrong with a traversal I wrote 
> that used {{optional(blah.sideEffect.blah)}}. {{optional()}} maps to 
> {{ChooseStep}} under the hood and the provide traversal is first tested for a 
> {{hasNext()}}. If so, the it plays itself out. The problem is that if there 
> is a side-effect in the traversal child, then it gets executed twice. 
> {code}
> gremlin> g = TinkerGraph.open().traversal()
> ==>graphtraversalsource[tinkergraph[vertices:0 edges:0], standard]
> gremlin> g.inject(1).optional(addV('twin'))
> ==>v[1]
> gremlin> g.V().valueMap(true)
> ==>[id:0,label:twin]
> ==>[id:1,label:twin]
> {code}
> We should NOT allow {{optional()}} to have {{SideEffectStep}} steps in it so 
> as not to cause unexpected behavior. {{StandardVerificationStrategy}} can 
> analyze and throw an exception if necessary.
> Also, {{coalesce()}} has a similar problem, though perhaps it can be a useful 
> 'technique.'
> {code}
> gremlin> g = TinkerGraph.open().traversal()
> ==>graphtraversalsource[tinkergraph[vertices:0 edges:0], standard]
> gremlin> g.inject(1).coalesce(addV('twin1').limit(0), addV('twin2'))
> ==>v[1]
> gremlin> g.V().valueMap(true)
> ==>[id:0,label:twin1]
> ==>[id:1,label:twin2]
> gremlin>
> {code}



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

[jira] [Commented] (TINKERPOP-1506) Optional/Coalesce should not allow sideEffect traversals.


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

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

Github user twilmes commented on the issue:

https://github.com/apache/tinkerpop/pull/471
  
Nice find.  Looks good. 

VOTE: +1


> Optional/Coalesce should not allow sideEffect traversals.
> -
>
> Key: TINKERPOP-1506
> URL: https://issues.apache.org/jira/browse/TINKERPOP-1506
> Project: TinkerPop
>  Issue Type: Improvement
>  Components: process
>Affects Versions: 3.1.4, 3.2.2
>Reporter: Marko A. Rodriguez
>
> It took me a long time to realize what was wrong with a traversal I wrote 
> that used {{optional(blah.sideEffect.blah)}}. {{optional()}} maps to 
> {{ChooseStep}} under the hood and the provide traversal is first tested for a 
> {{hasNext()}}. If so, the it plays itself out. The problem is that if there 
> is a side-effect in the traversal child, then it gets executed twice. 
> {code}
> gremlin> g = TinkerGraph.open().traversal()
> ==>graphtraversalsource[tinkergraph[vertices:0 edges:0], standard]
> gremlin> g.inject(1).optional(addV('twin'))
> ==>v[1]
> gremlin> g.V().valueMap(true)
> ==>[id:0,label:twin]
> ==>[id:1,label:twin]
> {code}
> We should NOT allow {{optional()}} to have {{SideEffectStep}} steps in it so 
> as not to cause unexpected behavior. {{StandardVerificationStrategy}} can 
> analyze and throw an exception if necessary.
> Also, {{coalesce()}} has a similar problem, though perhaps it can be a useful 
> 'technique.'
> {code}
> gremlin> g = TinkerGraph.open().traversal()
> ==>graphtraversalsource[tinkergraph[vertices:0 edges:0], standard]
> gremlin> g.inject(1).coalesce(addV('twin1').limit(0), addV('twin2'))
> ==>v[1]
> gremlin> g.V().valueMap(true)
> ==>[id:0,label:twin1]
> ==>[id:1,label:twin2]
> gremlin>
> {code}



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

[GitHub] tinkerpop issue #471: TINKERPOP-1506: Optional/Coalesce should not allow sid...

2016-11-02 Thread twilmes

Github user twilmes commented on the issue:

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

[jira] [Commented] (TINKERPOP-1542) Add Path.isEmpty() with a default implementation.


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

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

GitHub user okram opened a pull request:

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

TINKERPOP-1542: Add Path.isEmpty() with a default implementation.

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

Added `Path.isEmpty()` and `Path.head()` with default implementations. Have 
optimized implementations in `ImmutablePath` and `MutablePath`. These methods 
are used heavily by the `LP`-class of traversers. A few other random tweaks.

VOTE +1.

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

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

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

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


commit c2e5437275061a95105af885504abcb586b2ee2f
Author: Marko A. Rodriguez 
Date:   2016-11-02T22:34:43Z

Added Path.head() and Path.isEmpty() with default method implementations. 
Have optimized implementations in ImmutablePath and MutablePath. Using methods 
in the LP-class of traverser (the most heavily used traversers).




> Add Path.isEmpty() with a default implementation.
> -
>
> Key: TINKERPOP-1542
> URL: https://issues.apache.org/jira/browse/TINKERPOP-1542
> Project: TinkerPop
>  Issue Type: Improvement
>  Components: process
>Affects Versions: 3.2.3
>Reporter: Marko A. Rodriguez
>Assignee: Marko A. Rodriguez
>
> We have lots of {{path.size() == 0}} which for {{ImmutablePath}} is a 
> recursion. A {{path.isEmpty()}} is a O(1) call. Given how heavily used 
> {{ImmutablePath}} is, we should provide {{Path.isEmpty()}} with the following 
> default implementation.
> {code}
> public default boolean isEmpty() {
> return this.size() == 0;
> }
> {code}



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

[GitHub] tinkerpop pull request #480: TINKERPOP-1542: Add Path.isEmpty() with a defau...

GitHub user okram opened a pull request:

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

TINKERPOP-1542: Add Path.isEmpty() with a default implementation.

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

Added `Path.isEmpty()` and `Path.head()` with default implementations. Have 
optimized implementations in `ImmutablePath` and `MutablePath`. These methods 
are used heavily by the `LP`-class of traversers. A few other random tweaks.

VOTE +1.

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

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

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

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


commit c2e5437275061a95105af885504abcb586b2ee2f
Author: Marko A. Rodriguez 
Date:   2016-11-02T22:34:43Z

Added Path.head() and Path.isEmpty() with default method implementations. 
Have optimized implementations in ImmutablePath and MutablePath. Using methods 
in the LP-class of traverser (the most heavily used traversers).




---
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 #479: TINKERPOP-1434 Block calls on "remote" traversa...

GitHub user spmallette opened a pull request:

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

TINKERPOP-1434 Block calls on "remote" traversal to get side-effects

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

This prevents calls for side-effects that are not yet ready on the server. 
This was generally a problem in tests, but users could have also run afoul of 
the issue if they decided to get low-level with the API. It is more likely that 
they would grab side-effects with a call to `cap()` so this would be a 
non-issue in that case.

Did multiple runs of `mvn clean install && mvn verify -pl gremlin-server 
-DincludeNeo4j -DskipIntegrationTests=false` and it passes nicely. I never saw 
the test failures that triggered the effort to produce a fix for this problem, 
so @dkuppitz who saw it regularly should give this a review. Also, if travis 
passes, that would be a good sign - the error was seen there sometimes as well. 
 Please be sure to use `-DincludeNeo4j` if re-running the tests.

VOTE +1

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

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

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

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


commit 46a61bb124d27aebcf96a639b2614e16389b02f9
Author: Stephen Mallette 
Date:   2016-11-02T21:12:36Z

TINKERPOP-1434 Block calls on "remote" traversal to get side-effects

This prevents calls for side-effects that are not yet ready on the server. 
This was generally a problem in tests, but usrs could have also run afoul of 
the issue if they decided to get low-level with the API. It is more likely that 
they would grab side-effects with a call to cap() so this would be a non-issue 
in that case.




---
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-1434) Block calls to traversal side-effects until read is complete


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

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

GitHub user spmallette opened a pull request:

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

TINKERPOP-1434 Block calls on "remote" traversal to get side-effects

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

This prevents calls for side-effects that are not yet ready on the server. 
This was generally a problem in tests, but users could have also run afoul of 
the issue if they decided to get low-level with the API. It is more likely that 
they would grab side-effects with a call to `cap()` so this would be a 
non-issue in that case.

Did multiple runs of `mvn clean install && mvn verify -pl gremlin-server 
-DincludeNeo4j -DskipIntegrationTests=false` and it passes nicely. I never saw 
the test failures that triggered the effort to produce a fix for this problem, 
so @dkuppitz who saw it regularly should give this a review. Also, if travis 
passes, that would be a good sign - the error was seen there sometimes as well. 
 Please be sure to use `-DincludeNeo4j` if re-running the tests.

VOTE +1

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

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

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

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


commit 46a61bb124d27aebcf96a639b2614e16389b02f9
Author: Stephen Mallette 
Date:   2016-11-02T21:12:36Z

TINKERPOP-1434 Block calls on "remote" traversal to get side-effects

This prevents calls for side-effects that are not yet ready on the server. 
This was generally a problem in tests, but usrs could have also run afoul of 
the issue if they decided to get low-level with the API. It is more likely that 
they would grab side-effects with a call to cap() so this would be a non-issue 
in that case.




> Block calls to traversal side-effects until read is complete
> 
>
> Key: TINKERPOP-1434
> URL: https://issues.apache.org/jira/browse/TINKERPOP-1434
> Project: TinkerPop
>  Issue Type: Improvement
>  Components: driver
>Affects Versions: 3.2.2
>Reporter: stephen mallette
>Assignee: stephen mallette
>Priority: Minor
>
> Might make usability a little better if calls to {{getSideEffects()}} could 
> block until the remote {{Traversal}} complete iteration (i.e. on "read 
> complete") - or perhaps they return a {{Future}} or something.



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

[GitHub] tinkerpop issue #473: TINKERPOP-1372: ImmutablePath should not use Java recu...

Github user spmallette commented on the issue:

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

VOTE +1


---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

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


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

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

Github user asfgit closed the pull request at:

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


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

Github user asfgit closed the pull request at:

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


---
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-1372) ImmutablePath should not use Java recursion (call stacks are wack)


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

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

Github user spmallette commented on the issue:

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

VOTE +1


> 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-1541) Should repeated objects be returned for the same label?

Marko A. Rodriguez created TINKERPOP-1541:
-

 Summary: Should repeated objects be returned for the same label?
 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


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-1540) Create a set of marker interfaces that define step behavior

Marko A. Rodriguez created TINKERPOP-1540:
-

 Summary: Create a set of marker interfaces that define step 
behavior
 Key: TINKERPOP-1540
 URL: https://issues.apache.org/jira/browse/TINKERPOP-1540
 Project: TinkerPop
  Issue Type: Improvement
  Components: process
Affects Versions: 3.2.3
Reporter: Marko A. Rodriguez


We have steps like {{SideEffectStep}}, {{MapStep}}, {{FlatMapStep}}, etc., but 
unfortunately, these are classes and not all side-effect, map, flatmap, etc. 
behaving steps extend them. As such, if you have strategies that need to reason 
on step behavior, you have to really know the Gremlin step library well.

To make it easier to write strategies, we should come up with a set of "marker" 
interfaces.

* {{Mapping}} (one-to-one)
* {{FlatMapping}} (one-to-many)
* {{Reducing}} (many-to-one)
* {{Filtering}} (one-to-oneOrNone)
* {{SideEffecting}} (one-to-one w/ side-effect)
* {{Barriering}} (many-to-many)

>From here, we tag all the steps with their respective behavior marker and then 
>go through and clean up strategies.



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

[jira] [Assigned] (TINKERPOP-1434) Block calls to traversal side-effects until read is complete


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

stephen mallette reassigned TINKERPOP-1434:
---

Assignee: stephen mallette

> Block calls to traversal side-effects until read is complete
> 
>
> Key: TINKERPOP-1434
> URL: https://issues.apache.org/jira/browse/TINKERPOP-1434
> Project: TinkerPop
>  Issue Type: Improvement
>  Components: driver
>Affects Versions: 3.2.2
>Reporter: stephen mallette
>Assignee: stephen mallette
>Priority: Minor
>
> Might make usability a little better if calls to {{getSideEffects()}} could 
> block until the remote {{Traversal}} complete iteration (i.e. on "read 
> complete") - or perhaps they return a {{Future}} or something.



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

[jira] [Commented] (TINKERPOP-1474) API Alignment Between Java Gremlin Graph Structure and GLVs

2016-11-02 Thread Kevin Gallardo (JIRA)


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

Kevin Gallardo commented on TINKERPOP-1474:
---

It sounds important to make the distinction between what is exposed through the 
API and what is the data that is actually being sent to clients. On one side 
there needs to be a distinction between when the server returns an Element with 
its properties and when it does not, based on the type of Traversal (OLAP or 
not) and the configuration of the Gremlin server. 

However, at least for the Gremlin-Java what is exposed is always the same, the 
high level element interface ({{Vertex}}/{{Edge}}), which has properties 
methods, and whether what the server sent was a ReferenceElement, or a 
DetachedElement, the API will not change for the client. The methods to get 
properties will either return the properties if they were sent, or something 
empty if they weren't and that will not break users code. 

It also sounds important that the GLVs follow the same path in order to achieve 
the general rule of thumb [stated in the reference 
doc|http://tinkerpop.apache.org/docs/current/reference/#gremlin-variants]: 
bq. A strong correspondence between variants ensures that the general Gremlin 
reference documentation is applicable to all variants and that users moving 
between development languages can easily adopt the Gremlin variant for that 
language.

The Graph structure types are already exposed through the python Gremlin 
variant, so it sounds like they should be for the other GLVs and in my opinion 
we should try to make it as consistent as possible.

> API Alignment Between Java Gremlin Graph Structure and GLVs
> ---
>
> Key: TINKERPOP-1474
> URL: https://issues.apache.org/jira/browse/TINKERPOP-1474
> Project: TinkerPop
>  Issue Type: Improvement
>  Components: io, language-variant
>Affects Versions: 3.2.2
>Reporter: Adam Holmberg
>
> The current Java GraphSON implementation and that in the Python GLV leave 
> some question about what *should* be returned from a simple traversal like 
> `g.V()`.
> The java implementation presently assumes that properties could be present 
> and returns a DetachedVertex: 
> https://github.com/apache/tinkerpop/blob/master/gremlin-core/src/main/java/org/apache/tinkerpop/gremlin/structure/io/graphson/GraphSONSerializersV2d0.java#L420-L433
> The python implementation assumes no such thing and returns something more 
> reminiscent of a ReferenceVertex: 
> https://github.com/apache/tinkerpop/blob/master/gremlin-python/src/main/jython/gremlin_python/structure/io/graphson.py#L238-L242
> Is the java version overreaching, and should not expect properties unless a 
> step calls for them (e.g. ` g.V().valueMap()` or `g.V().values('name')`, or 
> should the Python version be expanded?
> Is there something we can do to establish guidelines for this, and align 
> these APIs?



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

[jira] [Updated] (TINKERPOP-887) FastNoSuchElementException hides stack trace in client code


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

stephen mallette updated TINKERPOP-887:
---
Fix Version/s: (was: 3.3.0)

> FastNoSuchElementException hides stack trace in client code
> ---
>
> Key: TINKERPOP-887
> URL: https://issues.apache.org/jira/browse/TINKERPOP-887
> Project: TinkerPop
>  Issue Type: Improvement
>  Components: process
>Affects Versions: 3.0.2-incubating
>Reporter: Bryn Cooke
>Assignee: Marko A. Rodriguez
>Priority: Minor
> Fix For: 3.2.4
>
>
> I wrote some code that incorrectly assumed that a Gremlin query would return 
> an element, but it didn't. The surprise was that I got no stack trace and 
> therefore had no idea where in *my* code I had introduced the error.
> I haven't looked in detail at the TP code, so what comes next is speculation:
> If FastNoSuchElementException is being used in truly exceptional 
> circumstances then why is a singleton is used over a normal exception with 
> stack trace? It could just as easily be converted to a normal exception.
> If FastNoSuchElementException is being used for control flow then probably it 
> shouldn't. Code should check hasNext rather than trying for next and dealing 
> with an exceptional result. I'm not sure what the current state of things are 
> in the JVM but at least in the past try catch blocks would inhibit 
> optimization even without stack traces so this type of code was considered an 
> antipattern.



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

[jira] [Reopened] (TINKERPOP-887) FastNoSuchElementException hides stack trace in client code


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

stephen mallette reopened TINKERPOP-887:


> FastNoSuchElementException hides stack trace in client code
> ---
>
> Key: TINKERPOP-887
> URL: https://issues.apache.org/jira/browse/TINKERPOP-887
> Project: TinkerPop
>  Issue Type: Improvement
>  Components: process
>Affects Versions: 3.0.2-incubating
>Reporter: Bryn Cooke
>Assignee: Marko A. Rodriguez
>Priority: Minor
> Fix For: 3.2.4
>
>
> I wrote some code that incorrectly assumed that a Gremlin query would return 
> an element, but it didn't. The surprise was that I got no stack trace and 
> therefore had no idea where in *my* code I had introduced the error.
> I haven't looked in detail at the TP code, so what comes next is speculation:
> If FastNoSuchElementException is being used in truly exceptional 
> circumstances then why is a singleton is used over a normal exception with 
> stack trace? It could just as easily be converted to a normal exception.
> If FastNoSuchElementException is being used for control flow then probably it 
> shouldn't. Code should check hasNext rather than trying for next and dealing 
> with an exceptional result. I'm not sure what the current state of things are 
> in the JVM but at least in the past try catch blocks would inhibit 
> optimization even without stack traces so this type of code was considered an 
> antipattern.



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

[jira] [Closed] (TINKERPOP-887) FastNoSuchElementException hides stack trace in client code


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

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

Removed 3.3.0 - fix is implied by 3.2.4

> FastNoSuchElementException hides stack trace in client code
> ---
>
> Key: TINKERPOP-887
> URL: https://issues.apache.org/jira/browse/TINKERPOP-887
> Project: TinkerPop
>  Issue Type: Improvement
>  Components: process
>Affects Versions: 3.0.2-incubating
>Reporter: Bryn Cooke
>Assignee: Marko A. Rodriguez
>Priority: Minor
> Fix For: 3.2.4
>
>
> I wrote some code that incorrectly assumed that a Gremlin query would return 
> an element, but it didn't. The surprise was that I got no stack trace and 
> therefore had no idea where in *my* code I had introduced the error.
> I haven't looked in detail at the TP code, so what comes next is speculation:
> If FastNoSuchElementException is being used in truly exceptional 
> circumstances then why is a singleton is used over a normal exception with 
> stack trace? It could just as easily be converted to a normal exception.
> If FastNoSuchElementException is being used for control flow then probably it 
> shouldn't. Code should check hasNext rather than trying for next and dealing 
> with an exceptional result. I'm not sure what the current state of things are 
> in the JVM but at least in the past try catch blocks would inhibit 
> optimization even without stack traces so this type of code was considered an 
> antipattern.



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

[jira] [Commented] (TINKERPOP-887) FastNoSuchElementException hides stack trace in client code


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

ASF GitHub Bot commented on TINKERPOP-887:
--

Github user okram commented on the issue:

https://github.com/apache/tinkerpop/pull/470
  
I think I already merged before your rebase. Can you simply close this as 
we have pushed tp32.



> FastNoSuchElementException hides stack trace in client code
> ---
>
> Key: TINKERPOP-887
> URL: https://issues.apache.org/jira/browse/TINKERPOP-887
> Project: TinkerPop
>  Issue Type: Improvement
>  Components: process
>Affects Versions: 3.0.2-incubating
>Reporter: Bryn Cooke
>Assignee: Marko A. Rodriguez
>Priority: Minor
> Fix For: 3.3.0, 3.2.4
>
>
> I wrote some code that incorrectly assumed that a Gremlin query would return 
> an element, but it didn't. The surprise was that I got no stack trace and 
> therefore had no idea where in *my* code I had introduced the error.
> I haven't looked in detail at the TP code, so what comes next is speculation:
> If FastNoSuchElementException is being used in truly exceptional 
> circumstances then why is a singleton is used over a normal exception with 
> stack trace? It could just as easily be converted to a normal exception.
> If FastNoSuchElementException is being used for control flow then probably it 
> shouldn't. Code should check hasNext rather than trying for next and dealing 
> with an exceptional result. I'm not sure what the current state of things are 
> in the JVM but at least in the past try catch blocks would inhibit 
> optimization even without stack traces so this type of code was considered an 
> antipattern.



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

[GitHub] tinkerpop pull request #470: TINKERPOP-887 Conversion of FastNoSuchElementEx...

2016-11-02 Thread BrynCooke

Github user BrynCooke closed the pull request at:

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


---
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-887) FastNoSuchElementException hides stack trace in client code


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

ASF GitHub Bot commented on TINKERPOP-887:
--

Github user BrynCooke commented on the issue:

https://github.com/apache/tinkerpop/pull/470
  
Great thanks



> FastNoSuchElementException hides stack trace in client code
> ---
>
> Key: TINKERPOP-887
> URL: https://issues.apache.org/jira/browse/TINKERPOP-887
> Project: TinkerPop
>  Issue Type: Improvement
>  Components: process
>Affects Versions: 3.0.2-incubating
>Reporter: Bryn Cooke
>Assignee: Marko A. Rodriguez
>Priority: Minor
> Fix For: 3.3.0, 3.2.4
>
>
> I wrote some code that incorrectly assumed that a Gremlin query would return 
> an element, but it didn't. The surprise was that I got no stack trace and 
> therefore had no idea where in *my* code I had introduced the error.
> I haven't looked in detail at the TP code, so what comes next is speculation:
> If FastNoSuchElementException is being used in truly exceptional 
> circumstances then why is a singleton is used over a normal exception with 
> stack trace? It could just as easily be converted to a normal exception.
> If FastNoSuchElementException is being used for control flow then probably it 
> shouldn't. Code should check hasNext rather than trying for next and dealing 
> with an exceptional result. I'm not sure what the current state of things are 
> in the JVM but at least in the past try catch blocks would inhibit 
> optimization even without stack traces so this type of code was considered an 
> antipattern.



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

[GitHub] tinkerpop issue #470: TINKERPOP-887 Conversion of FastNoSuchElementException...

2016-11-02 Thread BrynCooke

Github user BrynCooke commented on the issue:

https://github.com/apache/tinkerpop/pull/470
  
Great thanks



---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

[GitHub] tinkerpop issue #470: TINKERPOP-887 Conversion of FastNoSuchElementException...

Github user okram commented on the issue:

https://github.com/apache/tinkerpop/pull/470
  
I think I already merged before your rebase. Can you simply close this as 
we have pushed tp32.



---
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-887) FastNoSuchElementException hides stack trace in client code


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

ASF GitHub Bot commented on TINKERPOP-887:
--

Github user BrynCooke commented on the issue:

https://github.com/apache/tinkerpop/pull/470
  
Retargeting at tp32. 


> FastNoSuchElementException hides stack trace in client code
> ---
>
> Key: TINKERPOP-887
> URL: https://issues.apache.org/jira/browse/TINKERPOP-887
> Project: TinkerPop
>  Issue Type: Improvement
>  Components: process
>Affects Versions: 3.0.2-incubating
>Reporter: Bryn Cooke
>Assignee: Marko A. Rodriguez
>Priority: Minor
>
> I wrote some code that incorrectly assumed that a Gremlin query would return 
> an element, but it didn't. The surprise was that I got no stack trace and 
> therefore had no idea where in *my* code I had introduced the error.
> I haven't looked in detail at the TP code, so what comes next is speculation:
> If FastNoSuchElementException is being used in truly exceptional 
> circumstances then why is a singleton is used over a normal exception with 
> stack trace? It could just as easily be converted to a normal exception.
> If FastNoSuchElementException is being used for control flow then probably it 
> shouldn't. Code should check hasNext rather than trying for next and dealing 
> with an exceptional result. I'm not sure what the current state of things are 
> in the JVM but at least in the past try catch blocks would inhibit 
> optimization even without stack traces so this type of code was considered an 
> antipattern.



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

[GitHub] tinkerpop issue #470: TINKERPOP-887 Conversion of FastNoSuchElementException...

2016-11-02 Thread BrynCooke

Github user BrynCooke commented on the issue:

https://github.com/apache/tinkerpop/pull/470
  
Retargeting at tp32. 


---
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 #468: TINKERPOP-1420 Removal of previously deprecated gremli...

Github user spmallette commented on the issue:

https://github.com/apache/tinkerpop/pull/468
  
3.3.0 has been discussed as one for breaking changes so I think we should 
come away with a release that is free of deprecation if we can. I think we 
should just be methodical about it and not throw in too many breaks at once 
(i.e. per milestone release). That's why i started with easy stuff that 
probably won't break anyone at all. I have a few more like that. 


---
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 #468: TINKERPOP-1420 Removal of previously deprecated gremli...

Github user okram commented on the issue:

https://github.com/apache/tinkerpop/pull/468
  
Huh. Cool. Are we removing deprecations for 3.3.0? If so, should I be doing 
similar things in the "process" areas of the codebase?

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 #470: TINKERPOP-887 Conversion of FastNoSuchElementException...

Github user spmallette commented on the issue:

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

VOTE +1


---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

[jira] [Commented] (TINKERPOP-887) FastNoSuchElementException hides stack trace in client code


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

ASF GitHub Bot commented on TINKERPOP-887:
--

Github user spmallette commented on the issue:

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

VOTE +1


> FastNoSuchElementException hides stack trace in client code
> ---
>
> Key: TINKERPOP-887
> URL: https://issues.apache.org/jira/browse/TINKERPOP-887
> Project: TinkerPop
>  Issue Type: Improvement
>  Components: process
>Affects Versions: 3.0.2-incubating
>Reporter: Bryn Cooke
>Assignee: Marko A. Rodriguez
>Priority: Minor
>
> I wrote some code that incorrectly assumed that a Gremlin query would return 
> an element, but it didn't. The surprise was that I got no stack trace and 
> therefore had no idea where in *my* code I had introduced the error.
> I haven't looked in detail at the TP code, so what comes next is speculation:
> If FastNoSuchElementException is being used in truly exceptional 
> circumstances then why is a singleton is used over a normal exception with 
> stack trace? It could just as easily be converted to a normal exception.
> If FastNoSuchElementException is being used for control flow then probably it 
> shouldn't. Code should check hasNext rather than trying for next and dealing 
> with an exceptional result. I'm not sure what the current state of things are 
> in the JVM but at least in the past try catch blocks would inhibit 
> optimization even without stack traces so this type of code was considered an 
> antipattern.



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

[jira] [Commented] (TINKERPOP-1256) Remove Traverser.split(R r, Step<T,R> step)


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

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

I tried going down this ticket and it was a rabbit hole. There are reasons why 
things are so awkward. ... :|

> Remove Traverser.split(R r, Step step)
> ---
>
> Key: TINKERPOP-1256
> URL: https://issues.apache.org/jira/browse/TINKERPOP-1256
> Project: TinkerPop
>  Issue Type: Improvement
>  Components: process
>Affects Versions: 3.2.0-incubating
>Reporter: Marko A. Rodriguez
>
> I just noticed that {{Traverser.split(R r, Step step)}} has no 
> implementation that actually uses the {{step}} argument. This is an appendage 
> from back in the day when it was always guaranteed that the step would set 
> labels and stepId. This is not the case with many OLAP variations of a step.
> I think we should do the following.
> 1. Figure out how to get rid of {{privat e 
> AbstractStep.prepareTraversalForNextStep()}} as this is an blemish.
> 2. Create {{Traverser.split(R r)}}.
> 3. Then labels are added via 
> {{traverser.setPath(traverser.getPath().extend(labels))}}.
> Not a big ticket item, just some nice backwards compatible house-cleaning to 
> remove technical debt.



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

[jira] [Commented] (TINKERPOP-1490) Provider a Future based Traversal.async(Function<Traversal,V>) terminal step


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

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

Github user spmallette commented on the issue:

https://github.com/apache/tinkerpop/pull/478
  
> CoreTraversalTest is that it uses mutating steps and thus, not subject to 
OLAP testing

Ah - didn't think to check if that was fully ignored. I'll fix that up.


> Provider a Future based Traversal.async(Function) terminal step
> 
>
> Key: TINKERPOP-1490
> URL: https://issues.apache.org/jira/browse/TINKERPOP-1490
> Project: TinkerPop
>  Issue Type: Improvement
>  Components: language-variant, process
>Affects Versions: 3.2.2
>Reporter: Marko A. Rodriguez
>
> [~mbroecheler] had the idea of adding a {{Traversal.async()}} method. This is 
> important for not only avoiding thread locking on a query in Gremlin, but 
> also, it will allow single threaded language variants like Gremlin-JavaScript 
> to use callbacks for processing query results.
> {code}
> Future result = 
> g.V().out().values("name").async(Traversal::toList)
> {code}
> {code}
> Future result = g.V().out().name.async{it.toList()}
> {code}
> {code}
> g.V().out().values('name').async((err,names) => {
>   // I don't know JavaScript, but ...
>   return list(names);
> }) 
> {code}
> ...



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

[GitHub] tinkerpop issue #478: TINKERPOP-1490 Implemented promise API for Traversal

Github user spmallette commented on the issue:

https://github.com/apache/tinkerpop/pull/478
  
> CoreTraversalTest is that it uses mutating steps and thus, not subject to 
OLAP testing

Ah - didn't think to check if that was fully ignored. I'll fix that up.


---
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-1490) Provider a Future based Traversal.async(Function<Traversal,V>) terminal step


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

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

Github user spmallette commented on the issue:

https://github.com/apache/tinkerpop/pull/478
  
> Why do you ignore promise tests for GroovyTranslator and JavaTranslator. 
Seems we would want that to work as well.

I thought I was getting errors because of the lambda i use to simulate a 
slow script. Should that work?

> Why not have a PromiseTest in the process computer and process standard 
suites? It would be good to know that computer tests (which wrap a 
CompletableFuture too!) work as expected.

There is a test in the process standard suite:


https://github.com/apache/tinkerpop/pull/478/files#diff-37e31635f13d54b33745544db66cc590R282

`CoreTraversalTest` executes as part of the `ProcessStandardSuite`. Is that 
sufficient? Should I add something extra for computer tests too?

> We should probably get Gremlin-Python set up on this branch before 
merging into tp32/. I can write the code, I just don't know much about promises 
nor how to do them in Python.

I wouldn't mind writing the code.  As I mentioned in the comment, I just 
knew there would be discussion required to get it done. My limited reading on 
the subject made it seem like there are difference between how it would be 
implemented in python 3.x and 2.x as well. note sure if @davebshow has a minute 
to shed any light on this.


> Provider a Future based Traversal.async(Function) terminal step
> 
>
> Key: TINKERPOP-1490
> URL: https://issues.apache.org/jira/browse/TINKERPOP-1490
> Project: TinkerPop
>  Issue Type: Improvement
>  Components: language-variant, process
>Affects Versions: 3.2.2
>Reporter: Marko A. Rodriguez
>
> [~mbroecheler] had the idea of adding a {{Traversal.async()}} method. This is 
> important for not only avoiding thread locking on a query in Gremlin, but 
> also, it will allow single threaded language variants like Gremlin-JavaScript 
> to use callbacks for processing query results.
> {code}
> Future result = 
> g.V().out().values("name").async(Traversal::toList)
> {code}
> {code}
> Future result = g.V().out().name.async{it.toList()}
> {code}
> {code}
> g.V().out().values('name').async((err,names) => {
>   // I don't know JavaScript, but ...
>   return list(names);
> }) 
> {code}
> ...



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

[GitHub] tinkerpop issue #478: TINKERPOP-1490 Implemented promise API for Traversal

Github user spmallette commented on the issue:

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

> Why do you ignore promise tests for GroovyTranslator and JavaTranslator.
Seems we would want that to work as well.

I thought I was getting errors because of the lambda i use to simulate a
slow script. Should that work?

> Why not have a PromiseTest in the process computer and process standard
suites? It would be good to know that computer tests (which wrap a
CompletableFuture too!) work as expected.

There is a test in the process standard suite:

https://github.com/apache/tinkerpop/pull/478/files#diff-37e31635f13d54b33745544db66cc590R282

`CoreTraversalTest` executes as part of the `ProcessStandardSuite`. Is that
sufficient? Should I add something extra for computer tests too?

> We should probably get Gremlin-Python set up on this branch before
merging into tp32/. I can write the code, I just don't know much about promises
nor how to do them in Python.

I wouldn't mind writing the code. As I mentioned in the comment, I just
knew there would be discussion required to get it done. My limited reading on
the subject made it seem like there are difference between how it would be
implemented in python 3.x and 2.x as well. note sure if @davebshow has a minute
to shed any light on this.

---
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-1534) Gremlin Server instances leaking in tests


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

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

Github user asfgit closed the pull request at:

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


> Gremlin Server instances leaking in tests
> -
>
> Key: TINKERPOP-1534
> URL: https://issues.apache.org/jira/browse/TINKERPOP-1534
> Project: TinkerPop
>  Issue Type: Bug
>  Components: server, test-suite
>Affects Versions: 3.2.3
>Reporter: stephen mallette
>Assignee: stephen mallette
> Fix For: 3.2.4
>
>
> Even though Gremlin Server appears to be shut down, it still produces output 
> in tests from spark/hadoop/etc.



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

[jira] [Commented] (TINKERPOP-1490) Provider a Future based Traversal.async(Function<Traversal,V>) terminal step


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

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

Github user jorgebay commented on the issue:

https://github.com/apache/tinkerpop/pull/478
  
I think that, instead of doing blocking calls like `fn.apply()` on a thread 
pool, we could expose a fully async API. Something like `toListAsync()` that 
returns a `CompletableFuture`.

For that, we should expose an async `TraversalStrategy` interface 
containing a `applyAsync()` method that returns a completable future.

A fully async API could be translate to any language, even for the ones 
that don't feature thread pools (like JavaScript).


> Provider a Future based Traversal.async(Function) terminal step
> 
>
> Key: TINKERPOP-1490
> URL: https://issues.apache.org/jira/browse/TINKERPOP-1490
> Project: TinkerPop
>  Issue Type: Improvement
>  Components: language-variant, process
>Affects Versions: 3.2.2
>Reporter: Marko A. Rodriguez
>
> [~mbroecheler] had the idea of adding a {{Traversal.async()}} method. This is 
> important for not only avoiding thread locking on a query in Gremlin, but 
> also, it will allow single threaded language variants like Gremlin-JavaScript 
> to use callbacks for processing query results.
> {code}
> Future result = 
> g.V().out().values("name").async(Traversal::toList)
> {code}
> {code}
> Future result = g.V().out().name.async{it.toList()}
> {code}
> {code}
> g.V().out().values('name').async((err,names) => {
>   // I don't know JavaScript, but ...
>   return list(names);
> }) 
> {code}
> ...



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

[GitHub] tinkerpop issue #478: TINKERPOP-1490 Implemented promise API for Traversal

Github user okram commented on the issue:

https://github.com/apache/tinkerpop/pull/478
  
Wow. This is cool. Questions/comments:

1. Why do you ignore promise tests for `GroovyTranslator` and 
`JavaTranslator`. Seems we would want that to work as well.
2. Why not have a `PromiseTest` in the process computer and process 
standard suites? It would be good to know that computer tests (which wrap a 
`CompletableFuture` too!) work as expected.
3. We should probably get Gremlin-Python set up on this branch before 
merging into `tp32/`. I can write the code, I just don't know much about 
promises nor how to do them in Python.
4. We should get @jorgebay to review to make sure Gremlin-JavaScript will 
be able to use this model/naming convention so we don't diverge Gremlin-JS too 
much from Gremlin-Java.


---
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-1490) Provider a Future based Traversal.async(Function<Traversal,V>) terminal step


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

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

Github user okram commented on the issue:

https://github.com/apache/tinkerpop/pull/478
  
Wow. This is cool. Questions/comments:

1. Why do you ignore promise tests for `GroovyTranslator` and 
`JavaTranslator`. Seems we would want that to work as well.
2. Why not have a `PromiseTest` in the process computer and process 
standard suites? It would be good to know that computer tests (which wrap a 
`CompletableFuture` too!) work as expected.
3. We should probably get Gremlin-Python set up on this branch before 
merging into `tp32/`. I can write the code, I just don't know much about 
promises nor how to do them in Python.
4. We should get @jorgebay to review to make sure Gremlin-JavaScript will 
be able to use this model/naming convention so we don't diverge Gremlin-JS too 
much from Gremlin-Java.


> Provider a Future based Traversal.async(Function) terminal step
> 
>
> Key: TINKERPOP-1490
> URL: https://issues.apache.org/jira/browse/TINKERPOP-1490
> Project: TinkerPop
>  Issue Type: Improvement
>  Components: language-variant, process
>Affects Versions: 3.2.2
>Reporter: Marko A. Rodriguez
>
> [~mbroecheler] had the idea of adding a {{Traversal.async()}} method. This is 
> important for not only avoiding thread locking on a query in Gremlin, but 
> also, it will allow single threaded language variants like Gremlin-JavaScript 
> to use callbacks for processing query results.
> {code}
> Future result = 
> g.V().out().values("name").async(Traversal::toList)
> {code}
> {code}
> Future result = g.V().out().name.async{it.toList()}
> {code}
> {code}
> g.V().out().values('name').async((err,names) => {
>   // I don't know JavaScript, but ...
>   return list(names);
> }) 
> {code}
> ...



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

[jira] [Closed] (TINKERPOP-1534) Gremlin Server instances leaking in tests


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

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

> Gremlin Server instances leaking in tests
> -
>
> Key: TINKERPOP-1534
> URL: https://issues.apache.org/jira/browse/TINKERPOP-1534
> Project: TinkerPop
>  Issue Type: Bug
>  Components: server, test-suite
>Affects Versions: 3.2.3
>Reporter: stephen mallette
>Assignee: stephen mallette
> Fix For: 3.2.4
>
>
> Even though Gremlin Server appears to be shut down, it still produces output 
> in tests from spark/hadoop/etc.



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

[GitHub] tinkerpop pull request #469: TINKERPOP-1534 Improve GraphProvider ability to...

Github user asfgit closed the pull request at:

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


---
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-932) Add ability to cancel script execution associated with a Gremlin Server Session


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

ASF GitHub Bot commented on TINKERPOP-932:
--

Github user asfgit closed the pull request at:

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


> Add ability to cancel script execution associated with a Gremlin Server 
> Session 
> 
>
> Key: TINKERPOP-932
> URL: https://issues.apache.org/jira/browse/TINKERPOP-932
> Project: TinkerPop
>  Issue Type: Improvement
>  Components: server
>Affects Versions: 3.0.2-incubating
>Reporter: Zachary Kurey
>Assignee: stephen mallette
> Fix For: 3.2.4
>
>
> Currently with a {{SessionedClient}} there is no way to cancel a long running 
> script and the client has to depend on Gremlin Server side configured 
> timeouts before they can execute another script associated with the same 
> session id.
> There is a way we can forcefully close a session from the client side, or 
> just close the entire Gremlin client.  But it would be useful for client side 
> applications to be able to cancel script execution, have its intermediate 
> effects rolled back, and be able to continue interacting with the session 
> without losing session variable state maintained on the Gremlin server side.
> Unsure where this should live at an API level, since canceling by session id 
> isn't relevant for all {{Client}} implementations.  If somehow when the 
> {{CompletableFuture}} returned by {{Client.submitAsync}} could do 
> this when the {{Future}} is canceled, that would be a nice way to bridge 
> implementations.



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

[jira] [Closed] (TINKERPOP-932) Add ability to cancel script execution associated with a Gremlin Server Session


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

stephen mallette closed TINKERPOP-932.
--
Resolution: Done

> Add ability to cancel script execution associated with a Gremlin Server 
> Session 
> 
>
> Key: TINKERPOP-932
> URL: https://issues.apache.org/jira/browse/TINKERPOP-932
> Project: TinkerPop
>  Issue Type: Improvement
>  Components: server
>Affects Versions: 3.0.2-incubating
>Reporter: Zachary Kurey
>Assignee: stephen mallette
> Fix For: 3.2.4
>
>
> Currently with a {{SessionedClient}} there is no way to cancel a long running 
> script and the client has to depend on Gremlin Server side configured 
> timeouts before they can execute another script associated with the same 
> session id.
> There is a way we can forcefully close a session from the client side, or 
> just close the entire Gremlin client.  But it would be useful for client side 
> applications to be able to cancel script execution, have its intermediate 
> effects rolled back, and be able to continue interacting with the session 
> without losing session variable state maintained on the Gremlin server side.
> Unsure where this should live at an API level, since canceling by session id 
> isn't relevant for all {{Client}} implementations.  If somehow when the 
> {{CompletableFuture}} returned by {{Client.submitAsync}} could do 
> this when the {{Future}} is canceled, that would be a nice way to bridge 
> implementations.



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

[GitHub] tinkerpop pull request #461: TINKERPOP-932 Added "force" option on session c...

Github user asfgit closed the pull request at:

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


---
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-1372) ImmutablePath should not use Java recursion (call stacks are wack)


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

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

Github user okram commented on the issue:

https://github.com/apache/tinkerpop/pull/473
  
@pietermartin -- I think my last commit is another optimization you 
discussed.


> 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 issue #473: TINKERPOP-1372: ImmutablePath should not use Java recu...

Github user okram commented on the issue:

https://github.com/apache/tinkerpop/pull/473
  
@pietermartin -- I think my last commit is another optimization you 
discussed.


---
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-1490) Provider a Future based Traversal.async(Function<Traversal,V>) terminal step


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

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

GitHub user spmallette opened a pull request:

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

TINKERPOP-1490 Implemented promise API for Traversal

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

Added two promise() methods that return `CompletableFuture` on `Traversal`. 
Provided an override on `DefaultTraversal` for those methods because the 
function that transforms the Traversal is executed in a different thread and 
therefore requires Graph transaction management (or else we would orphan 
transactions). Did not update gremlin-python with the promise API because it 
seemed to beg discussion on the "right" way to do that (i.e. what library to 
use to support promises?, just use futures from the core lib?, etc).

Had to move `commons-lang` to `gremlin-core` as a dependency (it was in 
`gremlin-groovy`) so I that I could make use of the thread naming factory. 
Doesn't really change anything as `gremlin-groovy` packaged with the console 
and server anyway. LICENSE/NOTICE can remain unchanged as a result.

Works with `mvn clean install -DincludeNeo4j`.

VOTE +1

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

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

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

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


commit 9ad3042ff876a88af719a95b8e144f56b10c81c4
Author: Stephen Mallette 
Date:   2016-11-01T13:30:28Z

TINKERPOP-1490 Implemented promise API for Traversal

Added two promise() methods that return CompletableFuture on Traversal. 
Provided an override on DefaultTraversal for those methods because the function 
that transforms the Traversal is executed in a different thread and therefore 
requires Graph transaction management (or else we would orphan transactions). 
Did not update gremlin-python with the promise API because it seemed to beg 
discussion on the "right" way to do that (i.e. what library to use to support 
promises?, just use futures from the core lib?, etc).




> Provider a Future based Traversal.async(Function) terminal step
> 
>
> Key: TINKERPOP-1490
> URL: https://issues.apache.org/jira/browse/TINKERPOP-1490
> Project: TinkerPop
>  Issue Type: Improvement
>  Components: language-variant, process
>Affects Versions: 3.2.2
>Reporter: Marko A. Rodriguez
>
> [~mbroecheler] had the idea of adding a {{Traversal.async()}} method. This is 
> important for not only avoiding thread locking on a query in Gremlin, but 
> also, it will allow single threaded language variants like Gremlin-JavaScript 
> to use callbacks for processing query results.
> {code}
> Future result = 
> g.V().out().values("name").async(Traversal::toList)
> {code}
> {code}
> Future result = g.V().out().name.async{it.toList()}
> {code}
> {code}
> g.V().out().values('name').async((err,names) => {
>   // I don't know JavaScript, but ...
>   return list(names);
> }) 
> {code}
> ...



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

[GitHub] tinkerpop pull request #478: TINKERPOP-1490 Implemented promise API for Trav...

GitHub user spmallette opened a pull request:

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

TINKERPOP-1490 Implemented promise API for Traversal

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

Added two promise() methods that return `CompletableFuture` on `Traversal`. 
Provided an override on `DefaultTraversal` for those methods because the 
function that transforms the Traversal is executed in a different thread and 
therefore requires Graph transaction management (or else we would orphan 
transactions). Did not update gremlin-python with the promise API because it 
seemed to beg discussion on the "right" way to do that (i.e. what library to 
use to support promises?, just use futures from the core lib?, etc).

Had to move `commons-lang` to `gremlin-core` as a dependency (it was in 
`gremlin-groovy`) so I that I could make use of the thread naming factory. 
Doesn't really change anything as `gremlin-groovy` packaged with the console 
and server anyway. LICENSE/NOTICE can remain unchanged as a result.

Works with `mvn clean install -DincludeNeo4j`.

VOTE +1

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

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

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

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


commit 9ad3042ff876a88af719a95b8e144f56b10c81c4
Author: Stephen Mallette 
Date:   2016-11-01T13:30:28Z

TINKERPOP-1490 Implemented promise API for Traversal

Added two promise() methods that return CompletableFuture on Traversal. 
Provided an override on DefaultTraversal for those methods because the function 
that transforms the Traversal is executed in a different thread and therefore 
requires Graph transaction management (or else we would orphan transactions). 
Did not update gremlin-python with the promise API because it seemed to beg 
discussion on the "right" way to do that (i.e. what library to use to support 
promises?, just use futures from the core lib?, etc).




---
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-1539) Create a ComplexTraversalTest with crazy nested gnarly traversals.

2016-11-02 Thread Daniel Kuppitz (JIRA)


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

Daniel Kuppitz commented on TINKERPOP-1539:
---

Yup, but I don't think we should go too crazy with those tests. Complex queries 
in tests should still have a purpose and not just be there, because it's easy 
for us to write a 20+ step query. We should prepare the infrastructure for 
those tests and then add them on demand. A few good first candidates would be 
the queries I'm going to write for 
https://issues.apache.org/jira/browse/TINKERPOP-1529.

> Create a ComplexTraversalTest with crazy nested gnarly traversals.
> --
>
> Key: TINKERPOP-1539
> URL: https://issues.apache.org/jira/browse/TINKERPOP-1539
> Project: TinkerPop
>  Issue Type: Improvement
>  Components: process, test-suite
>Affects Versions: 3.2.3
>Reporter: Marko A. Rodriguez
>
> Our {{ProcessSuite}} has numerous tests verifying the semantics of the 
> various steps. Unfortunately, these tests are on simple traversals focused on 
> exposing the step in question in isolation.
> It would be good to add {{ComplexTraversalTest}} to the {{ProcessSuite}} 
> which has traversals over the Grateful Dead graph (for complexity reasons) 
> doing:
> 1. Numerous nests.
> 2. Match/Select/Where complexities.
> 3. Global side-effect access and unrolling and injecting.
> 4. ... just a bunch of nasty stuff.
> This will give us much more confidence as we add more strategies and 
> potentially, mess up our algebra which isn't exposed by the simple 
> "flat'-traversals we current test with.
> [~dkuppitz] --- would you be interested in doing this?



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

[jira] [Created] (TINKERPOP-1539) Create a ComplexTraversalTest with crazy nested gnarly traversals.

Marko A. Rodriguez created TINKERPOP-1539:
-

 Summary: Create a ComplexTraversalTest with crazy nested gnarly 
traversals.
 Key: TINKERPOP-1539
 URL: https://issues.apache.org/jira/browse/TINKERPOP-1539
 Project: TinkerPop
  Issue Type: Improvement
  Components: process, test-suite
Affects Versions: 3.2.3
Reporter: Marko A. Rodriguez


Our {{ProcessSuite}} has numerous tests verifying the semantics of the various 
steps. Unfortunately, these tests are on simple traversals focused on exposing 
the step in question in isolation.

It would be good to add {{ComplexTraversalTest}} to the {{ProcessSuite}} which 
has traversals over the Grateful Dead graph (for complexity reasons) doing:

1. Numerous nests.
2. Match/Select/Where complexities.
3. Global side-effect access and unrolling and injecting.
4. ... just a bunch of nasty stuff.

This will give us much more confidence as we add more strategies and 
potentially, mess up our algebra which isn't exposed by the simple 
"flat'-traversals we current test with.

[~dkuppitz] --- would you be interested in doing this?



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

[jira] [Closed] (TINKERPOP-1384) Description of filter function in traversal documentation


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

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

Yes, you are correct. Thank you.

> Description of filter function in traversal documentation
> -
>
> Key: TINKERPOP-1384
> URL: https://issues.apache.org/jira/browse/TINKERPOP-1384
> Project: TinkerPop
>  Issue Type: Bug
>  Components: documentation
>Reporter: Keith Lohnes
>Assignee: Marko A. Rodriguez
>Priority: Minor
> Fix For: 3.3.0, 3.2.4
>
>
> In http://tinkerpop.apache.org/docs/current/reference/#traversal
> I noticed the images there describe the filter step as S →  S ∪ Ø which 
> doesn't make sense to me since S = S ∪ Ø 
> It should be
> S →  E ⊆ S 
> since a filter yields a subset (though not necessarily a proper subset) of S



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

[jira] [Assigned] (TINKERPOP-1384) Description of filter function in traversal documentation


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

Marko A. Rodriguez reassigned TINKERPOP-1384:
-

Assignee: Marko A. Rodriguez

> Description of filter function in traversal documentation
> -
>
> Key: TINKERPOP-1384
> URL: https://issues.apache.org/jira/browse/TINKERPOP-1384
> Project: TinkerPop
>  Issue Type: Bug
>  Components: documentation
>Reporter: Keith Lohnes
>Assignee: Marko A. Rodriguez
>Priority: Minor
>
> In http://tinkerpop.apache.org/docs/current/reference/#traversal
> I noticed the images there describe the filter step as S →  S ∪ Ø which 
> doesn't make sense to me since S = S ∪ Ø 
> It should be
> S →  E ⊆ S 
> since a filter yields a subset (though not necessarily a proper subset) of S



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

[jira] [Commented] (TINKERPOP-1243) MatchStep should be a FilterStep, not a MapStep


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

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

Dah. This is not as easy as I thought. I was hoping that 
{{match().select("a","b")}} would just work with {{MatchStep}} as a 
{{FilterStep}}. Unfortunately, you have you to do 
{{match().select(last,"a","b")}} as you can have repeats. This actually begs 
the question. Should a {{as("a").identity().as("a").select("a")}} return a 
2-element list or just the single. That is, set or list. :| ... That is a rats 
nest I dare not get into.

> MatchStep should be a FilterStep, not a MapStep
> ---
>
> Key: TINKERPOP-1243
> URL: https://issues.apache.org/jira/browse/TINKERPOP-1243
> Project: TinkerPop
>  Issue Type: Improvement
>  Components: process
>Affects Versions: 3.1.1-incubating, 3.2.0-incubating
>Reporter: Marko A. Rodriguez
>  Labels: breaking
>
> {{MatchStep}} should really be a {{FilterStep}}. It simply filters out all 
> traversers that don't match the patterns. However, given that you typically 
> {{select()}} after {{match()}}, a {{Map}} is generated. The 
> benefit of making it a {{FilterStep}} is that people can use {{match()}} to 
> filter without having to deal with unrolling the {{Map}}. Moreover, it feels 
> more consistent with the language constructs.



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

[jira] [Commented] (TINKERPOP-1292) TinkerGraphComputer VertexProgramInterceptors


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

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

Github user twilmes commented on the issue:

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


> 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 issue #476: TINKERPOP-1292: TinkerGraphComputer VertexProgramInter...

2016-11-02 Thread twilmes

Github user twilmes commented on the issue:

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

The cost of ==, equals, and instaceof for static classes.

2016-11-02 Thread Marko Rodriguez

Hi,

The root traversal of a traversal is the one whose traversal.getParent() 
instanceof EmptyStep.

In our strategies we use:

traversal.getParent().equals(EmptyStep.instance())
traversal.getParent() == EmptyStep.instance()
traversal.getParent() instanceof EmptyStep

Which way is fastest?

import org.apache.tinkerpop.gremlin.process.traversal.step.util.EmptyStep
random = new Random()
x = []
for(int i=0;i<1;i++) {
 select = random.nextInt(3)
 if(0 == select)
  x.add(EmptyStep.instance())
 if(1 == select)
  x.add(i)
 else
  x.add(UUID.randomUUID())
}


gremlin> clock(1000){ x.each{ it instanceof EmptyStep }}
==>0.751338511999
gremlin> clock(1000){ x.each{ it == EmptyStep }}
==>1.526259428
gremlin> clock(1000){ x.each{ it.equals(EmptyStep) }}
==>2.829880314

Seems “instanceof” is the winner.

Marko.

http://markorodriguez.com

[jira] [Assigned] (TINKERPOP-1508) Add choose(predicate,trueTraversal)


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

Marko A. Rodriguez reassigned TINKERPOP-1508:
-

Assignee: Marko A. Rodriguez

> Add choose(predicate,trueTraversal)
> ---
>
> Key: TINKERPOP-1508
> URL: https://issues.apache.org/jira/browse/TINKERPOP-1508
> Project: TinkerPop
>  Issue Type: Improvement
>  Components: process
>Affects Versions: 3.2.2
>Reporter: Marko A. Rodriguez
>Assignee: Marko A. Rodriguez
> Fix For: 3.3.0, 3.2.4
>
>
> {{choose()}} supports 
> {{choose(predicateTraversal,trueTraversal,falseTraversal)}}.
> I have lots of code that does this:
> {code}
> choose(blah(), bloop(), identity())
> {code}
> That is, if the predicate traversal doesn't hold, I simply want the incoming 
> traverser to be emitted -- {{identity()}}. This is sort of like 
> {{optional()}}, but the predicate is something different from the branch. It 
> would be nice to be able to simply say:
> {code}
> choose(blah(),bloop())
> {code}
> ...where its understood that a "false" means {{identity()}}.



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

[jira] [Closed] (TINKERPOP-1508) Add choose(predicate,trueTraversal)


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

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

> Add choose(predicate,trueTraversal)
> ---
>
> Key: TINKERPOP-1508
> URL: https://issues.apache.org/jira/browse/TINKERPOP-1508
> Project: TinkerPop
>  Issue Type: Improvement
>  Components: process
>Affects Versions: 3.2.2
>Reporter: Marko A. Rodriguez
>Assignee: Marko A. Rodriguez
> Fix For: 3.3.0, 3.2.4
>
>
> {{choose()}} supports 
> {{choose(predicateTraversal,trueTraversal,falseTraversal)}}.
> I have lots of code that does this:
> {code}
> choose(blah(), bloop(), identity())
> {code}
> That is, if the predicate traversal doesn't hold, I simply want the incoming 
> traverser to be emitted -- {{identity()}}. This is sort of like 
> {{optional()}}, but the predicate is something different from the branch. It 
> would be nice to be able to simply say:
> {code}
> choose(blah(),bloop())
> {code}
> ...where its understood that a "false" means {{identity()}}.



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

[jira] [Commented] (TINKERPOP-1508) Add choose(predicate,trueTraversal)


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

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

Github user asfgit closed the pull request at:

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


> Add choose(predicate,trueTraversal)
> ---
>
> Key: TINKERPOP-1508
> URL: https://issues.apache.org/jira/browse/TINKERPOP-1508
> Project: TinkerPop
>  Issue Type: Improvement
>  Components: process
>Affects Versions: 3.2.2
>Reporter: Marko A. Rodriguez
>
> {{choose()}} supports 
> {{choose(predicateTraversal,trueTraversal,falseTraversal)}}.
> I have lots of code that does this:
> {code}
> choose(blah(), bloop(), identity())
> {code}
> That is, if the predicate traversal doesn't hold, I simply want the incoming 
> traverser to be emitted -- {{identity()}}. This is sort of like 
> {{optional()}}, but the predicate is something different from the branch. It 
> would be nice to be able to simply say:
> {code}
> choose(blah(),bloop())
> {code}
> ...where its understood that a "false" means {{identity()}}.



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

[GitHub] tinkerpop pull request #472: TINKERPOP-1508: Add choose(predicate,trueTraver...

Github user asfgit closed the pull request at:

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


---
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-887) FastNoSuchElementException hides stack trace in client code


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

ASF GitHub Bot commented on TINKERPOP-887:
--

Github user spmallette commented on the issue:

https://github.com/apache/tinkerpop/pull/470
  
did anyone run a full docker build on this - i didn't see that in the 
comments? i have one running nowi think we should wait for that before 
merge.


> FastNoSuchElementException hides stack trace in client code
> ---
>
> Key: TINKERPOP-887
> URL: https://issues.apache.org/jira/browse/TINKERPOP-887
> Project: TinkerPop
>  Issue Type: Improvement
>  Components: process
>Affects Versions: 3.0.2-incubating
>Reporter: Bryn Cooke
>Assignee: Marko A. Rodriguez
>Priority: Minor
>
> I wrote some code that incorrectly assumed that a Gremlin query would return 
> an element, but it didn't. The surprise was that I got no stack trace and 
> therefore had no idea where in *my* code I had introduced the error.
> I haven't looked in detail at the TP code, so what comes next is speculation:
> If FastNoSuchElementException is being used in truly exceptional 
> circumstances then why is a singleton is used over a normal exception with 
> stack trace? It could just as easily be converted to a normal exception.
> If FastNoSuchElementException is being used for control flow then probably it 
> shouldn't. Code should check hasNext rather than trying for next and dealing 
> with an exceptional result. I'm not sure what the current state of things are 
> in the JVM but at least in the past try catch blocks would inhibit 
> optimization even without stack traces so this type of code was considered an 
> antipattern.



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

[GitHub] tinkerpop issue #470: TINKERPOP-887 Conversion of FastNoSuchElementException...

Github user spmallette commented on the issue:

https://github.com/apache/tinkerpop/pull/470
  
did anyone run a full docker build on this - i didn't see that in the 
comments? i have one running nowi think we should wait for that before 
merge.


---
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-887) FastNoSuchElementException hides stack trace in client code


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

ASF GitHub Bot commented on TINKERPOP-887:
--

Github user PommeVerte commented on the issue:

https://github.com/apache/tinkerpop/pull/470
  
looks good and is a nice addition *I will definitely enjoy this* : VOTE +1


> FastNoSuchElementException hides stack trace in client code
> ---
>
> Key: TINKERPOP-887
> URL: https://issues.apache.org/jira/browse/TINKERPOP-887
> Project: TinkerPop
>  Issue Type: Improvement
>  Components: process
>Affects Versions: 3.0.2-incubating
>Reporter: Bryn Cooke
>Assignee: Marko A. Rodriguez
>Priority: Minor
>
> I wrote some code that incorrectly assumed that a Gremlin query would return 
> an element, but it didn't. The surprise was that I got no stack trace and 
> therefore had no idea where in *my* code I had introduced the error.
> I haven't looked in detail at the TP code, so what comes next is speculation:
> If FastNoSuchElementException is being used in truly exceptional 
> circumstances then why is a singleton is used over a normal exception with 
> stack trace? It could just as easily be converted to a normal exception.
> If FastNoSuchElementException is being used for control flow then probably it 
> shouldn't. Code should check hasNext rather than trying for next and dealing 
> with an exceptional result. I'm not sure what the current state of things are 
> in the JVM but at least in the past try catch blocks would inhibit 
> optimization even without stack traces so this type of code was considered an 
> antipattern.



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

[GitHub] tinkerpop issue #470: TINKERPOP-887 Conversion of FastNoSuchElementException...

2016-11-02 Thread PommeVerte

Github user PommeVerte commented on the issue:

https://github.com/apache/tinkerpop/pull/470
  
looks good and is a nice addition *I will definitely enjoy this* : 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-1508) Add choose(predicate,trueTraversal)


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

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

Github user PommeVerte commented on the issue:

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


> Add choose(predicate,trueTraversal)
> ---
>
> Key: TINKERPOP-1508
> URL: https://issues.apache.org/jira/browse/TINKERPOP-1508
> Project: TinkerPop
>  Issue Type: Improvement
>  Components: process
>Affects Versions: 3.2.2
>Reporter: Marko A. Rodriguez
>
> {{choose()}} supports 
> {{choose(predicateTraversal,trueTraversal,falseTraversal)}}.
> I have lots of code that does this:
> {code}
> choose(blah(), bloop(), identity())
> {code}
> That is, if the predicate traversal doesn't hold, I simply want the incoming 
> traverser to be emitted -- {{identity()}}. This is sort of like 
> {{optional()}}, but the predicate is something different from the branch. It 
> would be nice to be able to simply say:
> {code}
> choose(blah(),bloop())
> {code}
> ...where its understood that a "false" means {{identity()}}.



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

[GitHub] tinkerpop issue #472: TINKERPOP-1508: Add choose(predicate,trueTraversal)

2016-11-02 Thread PommeVerte

Github user PommeVerte commented on the issue:

https://github.com/apache/tinkerpop/pull/472
  
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-965) Optimize TraversalStrategy application


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

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

Any more developments in this area? If there is nothing else to do, can you 
please close the ticket.

> Optimize TraversalStrategy application
> --
>
> Key: TINKERPOP-965
> URL: https://issues.apache.org/jira/browse/TINKERPOP-965
> Project: TinkerPop
>  Issue Type: Improvement
>  Components: process
>Affects Versions: 3.1.0-incubating
>Reporter: Marko A. Rodriguez
>Assignee: Ted Wilmes
>
> From the work of [~twilmes], it appears that we can gain a lot by making 
> {{Traversal.applyStrategies()}} as fast as possible. This is going to be 
> especially important as we transition people away from using 
> "Blueprints-methods" (e.g. {{Graph.addVertex()}} and {{Vertex.addEdge()}}) to 
> "Gremlin-methods" (e.g. {{g.addV()}} and 
> {{g.V().as('a').out().addE('knows').from('a')}}).
> Obviously the "Blueprints-methods" will always be faster given that they are 
> direct calls to the underlying provider. However, they should not be so 
> ridiculously faster that people won't use the "Gremlin-methods." Furthermore, 
> given [~dkuppitz]'s recent work with {{BulkLoaderVertexProgram}} and soon 
> TINKERPOP3-942, the "Gremlin-methods" will be the only way to get these 
> features.
> In general, the work should go beyond the {{Mutation}}-steps and make it so 
> that all traversals compile as fast as possible. The first step is to realize 
> where things are slow and knock those out firsthopefully we realize some 
> tricks!
> Related to: TINKERPOP3-957



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


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

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

Github user okram commented on the issue:

https://github.com/apache/tinkerpop/pull/473
  
@pietermartin voted +1 on the dev@ mailing list for this ticket. In the 
future, @pietermartin, can you VOTE on the GitHub pull request comment thread?


> 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 issue #473: TINKERPOP-1372: ImmutablePath should not use Java recu...

Github user okram commented on the issue:

https://github.com/apache/tinkerpop/pull/473
  
@pietermartin voted +1 on the dev@ mailing list for this ticket. In the 
future, @pietermartin, can you VOTE on the GitHub pull request comment 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-1473) Given PathRetractionStrategy, PathProcessorStrategy can be extended to support partial where() inlining.