[jira] [Commented] (TINKERPOP-1541) Select should default to Pop.last semantics
[
https://issues.apache.org/jira/browse/TINKERPOP-1541?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15656176#comment-15656176
]
ASF GitHub Bot commented on TINKERPOP-1541:
---
Github user dkuppitz commented on the issue:
https://github.com/apache/tinkerpop/pull/482
`docker/build.sh -t -i -n` succeeded.
VOTE: +1
> Select should default to Pop.last semantics
> ---
>
> Key: TINKERPOP-1541
> URL: https://issues.apache.org/jira/browse/TINKERPOP-1541
> Project: TinkerPop
> Issue Type: Improvement
> Components: process
>Affects Versions: 3.2.3
>Reporter: Marko A. Rodriguez
>Assignee: Marko A. Rodriguez
> Labels: breaking
>
> Check this out:
> {code}
> gremlin> g.V().as('a').select('a').as('a').select('a')
> ==>[v[1],v[1]]
> ==>[v[2],v[2]]
> ==>[v[3],v[3]]
> ==>[v[4],v[4]]
> ==>[v[5],v[5]]
> ==>[v[6],v[6]]
> {code}
> Shouldn't we just return the uniques? This is a big decision as this can
> cause massive rippling breakage for users :).
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[GitHub] tinkerpop issue #482: TINKERPOP-1541: Select should default to Pop.last sema...
Github user dkuppitz commented on the issue: https://github.com/apache/tinkerpop/pull/482 `docker/build.sh -t -i -n` succeeded. 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 #486: TINKERPOP-1545 IncidentToAdjacentStrategy is buggy
Github user dkuppitz commented on the issue: https://github.com/apache/tinkerpop/pull/486 Force-pushed. Filtering steps based on 2 conditions (type and traversal requirements) was easier than I thought (thanks to `TraversalHelper.anyStepRecursively()`). --- 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-1545) IncidentToAdjacentStrategy is buggy
[
https://issues.apache.org/jira/browse/TINKERPOP-1545?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15655870#comment-15655870
]
ASF GitHub Bot commented on TINKERPOP-1545:
---
Github user dkuppitz commented on the issue:
https://github.com/apache/tinkerpop/pull/486
Force-pushed. Filtering steps based on 2 conditions (type and traversal
requirements) was easier than I thought (thanks to
`TraversalHelper.anyStepRecursively()`).
> IncidentToAdjacentStrategy is buggy
> ---
>
> Key: TINKERPOP-1545
> URL: https://issues.apache.org/jira/browse/TINKERPOP-1545
> Project: TinkerPop
> Issue Type: Bug
>Affects Versions: 3.1.4, 3.2.3
>Reporter: Daniel Kuppitz
>Assignee: Daniel Kuppitz
>
> {{IncidentToAdjacentStrategy}} turns {{outE().inV().simplePath()}} into
> {{out().simplePath()}}, which will return a wrong result as soon as there is
> more than 1 edge between a pair of vertices.
> The set {{INVALIDATING_STEP_CLASSES}} should only contain
> {{PathProcessor.class}} and {{LambdaHolder.class}} Furthermore
> {{SimplePathStep}} should implement {{PathProcessor}}.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (TINKERPOP-1545) IncidentToAdjacentStrategy is buggy
[
https://issues.apache.org/jira/browse/TINKERPOP-1545?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15655826#comment-15655826
]
ASF GitHub Bot commented on TINKERPOP-1545:
---
Github user dkuppitz commented on the issue:
https://github.com/apache/tinkerpop/pull/486
You know what, I will revert the change and not implement `PathProcessor`
in `SimplePathStep`. Here's why: `IncidentToAdjacentStrategy` should only rely
on the `getRequirements()` result, because otherwise this problem would come up
again with `VertexProgramSteps`.
> IncidentToAdjacentStrategy is buggy
> ---
>
> Key: TINKERPOP-1545
> URL: https://issues.apache.org/jira/browse/TINKERPOP-1545
> Project: TinkerPop
> Issue Type: Bug
>Affects Versions: 3.1.4, 3.2.3
>Reporter: Daniel Kuppitz
>Assignee: Daniel Kuppitz
>
> {{IncidentToAdjacentStrategy}} turns {{outE().inV().simplePath()}} into
> {{out().simplePath()}}, which will return a wrong result as soon as there is
> more than 1 edge between a pair of vertices.
> The set {{INVALIDATING_STEP_CLASSES}} should only contain
> {{PathProcessor.class}} and {{LambdaHolder.class}} Furthermore
> {{SimplePathStep}} should implement {{PathProcessor}}.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[GitHub] tinkerpop issue #486: TINKERPOP-1545 IncidentToAdjacentStrategy is buggy
Github user dkuppitz commented on the issue: https://github.com/apache/tinkerpop/pull/486 You know what, I will revert the change and not implement `PathProcessor` in `SimplePathStep`. Here's why: `IncidentToAdjacentStrategy` should only rely on the `getRequirements()` result, because otherwise this problem would come up again with `VertexProgramSteps`. --- 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-1545) IncidentToAdjacentStrategy is buggy
[
https://issues.apache.org/jira/browse/TINKERPOP-1545?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15655821#comment-15655821
]
ASF GitHub Bot commented on TINKERPOP-1545:
---
Github user dkuppitz commented on the issue:
https://github.com/apache/tinkerpop/pull/486
The `PathProcessor` interface has no function for SimpleStep and doesn't
add any overhead. AFAIK `PathProcessor` is only used by strategies to easily
identify traversals with "special requirements". Both, `SimpleStep` and
`CyclicStep`, access the current `traverser.path()` and thus they **process**
the **path**, which makes them `PathProcessor`s :).
I can also rely on the result of `getRequirements()`, but this would make
the strategy a bit slower and I really don't see why `SimplePath` and
`CyclicPath` should not be `PathProcessor`s.
> IncidentToAdjacentStrategy is buggy
> ---
>
> Key: TINKERPOP-1545
> URL: https://issues.apache.org/jira/browse/TINKERPOP-1545
> Project: TinkerPop
> Issue Type: Bug
>Affects Versions: 3.1.4, 3.2.3
>Reporter: Daniel Kuppitz
>Assignee: Daniel Kuppitz
>
> {{IncidentToAdjacentStrategy}} turns {{outE().inV().simplePath()}} into
> {{out().simplePath()}}, which will return a wrong result as soon as there is
> more than 1 edge between a pair of vertices.
> The set {{INVALIDATING_STEP_CLASSES}} should only contain
> {{PathProcessor.class}} and {{LambdaHolder.class}} Furthermore
> {{SimplePathStep}} should implement {{PathProcessor}}.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[GitHub] tinkerpop issue #486: TINKERPOP-1545 IncidentToAdjacentStrategy is buggy
Github user dkuppitz commented on the issue: https://github.com/apache/tinkerpop/pull/486 The `PathProcessor` interface has no function for SimpleStep and doesn't add any overhead. AFAIK `PathProcessor` is only used by strategies to easily identify traversals with "special requirements". Both, `SimpleStep` and `CyclicStep`, access the current `traverser.path()` and thus they **process** the **path**, which makes them `PathProcessor`s :). I can also rely on the result of `getRequirements()`, but this would make the strategy a bit slower and I really don't see why `SimplePath` and `CyclicPath` should not be `PathProcessor`s. --- 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 #478: TINKERPOP-1490 Implemented promise API for Trav...
Github user al3xandru commented on a diff in the pull request: https://github.com/apache/tinkerpop/pull/478#discussion_r87521066 --- Diff: gremlin-core/pom.xml --- @@ -61,6 +61,11 @@ limitations under the License. + +org.apache.commons --- End diff -- I cannot find any references to this new lib besides thread naming. is that its single purpose? --- 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) terminal step
[
https://issues.apache.org/jira/browse/TINKERPOP-1490?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15655730#comment-15655730
]
ASF GitHub Bot commented on TINKERPOP-1490:
---
Github user al3xandru commented on a diff in the pull request:
https://github.com/apache/tinkerpop/pull/478#discussion_r87521066
--- Diff: gremlin-core/pom.xml ---
@@ -61,6 +61,11 @@ limitations under the License.
+
+org.apache.commons
--- End diff --
I cannot find any references to this new lib besides thread naming. is that
its single purpose?
> 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] [Commented] (TINKERPOP-1545) IncidentToAdjacentStrategy is buggy
[
https://issues.apache.org/jira/browse/TINKERPOP-1545?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15655657#comment-15655657
]
ASF GitHub Bot commented on TINKERPOP-1545:
---
Github user okram commented on the issue:
https://github.com/apache/tinkerpop/pull/486
`PathProcessors` are intended for path analysis steps that use
`by()`-modulation. Also, what about `CyclicPathStep`? Perhaps just itemize
those steps explictly for now and now have them implement `PathProcessor`.
However...I guess they are `PathProcessors` that don't project out...
hmmm... perhaps do a study of `PathProcessor` use and see if making
`SimplePathStep` and `CyclicPathStep` one of those would be a problem.
> IncidentToAdjacentStrategy is buggy
> ---
>
> Key: TINKERPOP-1545
> URL: https://issues.apache.org/jira/browse/TINKERPOP-1545
> Project: TinkerPop
> Issue Type: Bug
>Affects Versions: 3.1.4, 3.2.3
>Reporter: Daniel Kuppitz
>Assignee: Daniel Kuppitz
>
> {{IncidentToAdjacentStrategy}} turns {{outE().inV().simplePath()}} into
> {{out().simplePath()}}, which will return a wrong result as soon as there is
> more than 1 edge between a pair of vertices.
> The set {{INVALIDATING_STEP_CLASSES}} should only contain
> {{PathProcessor.class}} and {{LambdaHolder.class}} Furthermore
> {{SimplePathStep}} should implement {{PathProcessor}}.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[GitHub] tinkerpop issue #486: TINKERPOP-1545 IncidentToAdjacentStrategy is buggy
Github user okram commented on the issue: https://github.com/apache/tinkerpop/pull/486 `PathProcessors` are intended for path analysis steps that use `by()`-modulation. Also, what about `CyclicPathStep`? Perhaps just itemize those steps explictly for now and now have them implement `PathProcessor`. However...I guess they are `PathProcessors` that don't project out... hmmm... perhaps do a study of `PathProcessor` use and see if making `SimplePathStep` and `CyclicPathStep` one of those would be a problem. --- 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-1547) Two bugs found associated with MatchStep: Path retraction and range count.
[
https://issues.apache.org/jira/browse/TINKERPOP-1547?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15655653#comment-15655653
]
ASF GitHub Bot commented on TINKERPOP-1547:
---
Github user asfgit closed the pull request at:
https://github.com/apache/tinkerpop/pull/483
> Two bugs found associated with MatchStep: Path retraction and range count.
> --
>
> Key: TINKERPOP-1547
> URL: https://issues.apache.org/jira/browse/TINKERPOP-1547
> Project: TinkerPop
> Issue Type: Bug
> Components: process
>Affects Versions: 3.2.3
>Reporter: Marko A. Rodriguez
>Assignee: Marko A. Rodriguez
> Fix For: 3.2.4
>
>
> {{PathRetractionStrategy}} can retract end labels from traversals and thus,
> ruin a pattern match. We had 3 traversals in our test suite that were buggy
> because of this. Finally, if the user does a pattern of
> {{as("a").count().is(gt(10)).as("b")}}, this will fail because of
> {{RangeIsCountByStrategy}}.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[GitHub] tinkerpop pull request #483: TINKERPOP-1547: Two bugs found associated with ...
Github user asfgit closed the pull request at: https://github.com/apache/tinkerpop/pull/483 --- If your project is set up for it, you can reply to this email and have your reply appear on GitHub as well. If your project does not have this feature enabled and wishes so, or if the feature is enabled but not working, please contact infrastructure at infrastruct...@apache.org or file a JIRA ticket with INFRA. ---
[jira] [Closed] (TINKERPOP-1547) Two bugs found associated with MatchStep: Path retraction and range count.
[
https://issues.apache.org/jira/browse/TINKERPOP-1547?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Marko A. Rodriguez closed TINKERPOP-1547.
-
Resolution: Fixed
> Two bugs found associated with MatchStep: Path retraction and range count.
> --
>
> Key: TINKERPOP-1547
> URL: https://issues.apache.org/jira/browse/TINKERPOP-1547
> Project: TinkerPop
> Issue Type: Bug
> Components: process
>Affects Versions: 3.2.3
>Reporter: Marko A. Rodriguez
>Assignee: Marko A. Rodriguez
> Fix For: 3.2.4
>
>
> {{PathRetractionStrategy}} can retract end labels from traversals and thus,
> ruin a pattern match. We had 3 traversals in our test suite that were buggy
> because of this. Finally, if the user does a pattern of
> {{as("a").count().is(gt(10)).as("b")}}, this will fail because of
> {{RangeIsCountByStrategy}}.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[GitHub] tinkerpop pull request #486: TINKERPOP-1545 IncidentToAdjacentStrategy is bu...
GitHub user dkuppitz opened a pull request: https://github.com/apache/tinkerpop/pull/486 TINKERPOP-1545 IncidentToAdjacentStrategy is buggy https://issues.apache.org/jira/browse/TINKERPOP-1545 Made `SimplePathStep` implement `PathProcessor` and `IncidentToAdjacentStrategy` skip all traversals that contain path processing steps. The first few test suites of `docker/builder -t -i -n` succeeded and I will let it run over night, but I'm confident, that nothing bad is gonna happen in the other test suites (otherwise I'm going to revert the next line tomorrow). VOTE: +1 You can merge this pull request into a Git repository by running: $ git pull https://github.com/apache/tinkerpop TINKERPOP-1545 Alternatively you can review and apply these changes as the patch at: https://github.com/apache/tinkerpop/pull/486.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 #486 commit 54dbeaacaf6ccfaab8db9de8ce736243fe32b78e Author: Daniel Kuppitz Date: 2016-11-10T23:00:03Z Made SimplePathStep implement PathProcessor and IncidentToAdjacentStrategy skip all traversals that contain path processing steps --- If your project is set up for it, you can reply to this email and have your reply appear on GitHub as well. If your project does not have this feature enabled and wishes so, or if the feature is enabled but not working, please contact infrastructure at infrastruct...@apache.org or file a JIRA ticket with INFRA. ---
[jira] [Commented] (TINKERPOP-1545) IncidentToAdjacentStrategy is buggy
[
https://issues.apache.org/jira/browse/TINKERPOP-1545?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15655489#comment-15655489
]
ASF GitHub Bot commented on TINKERPOP-1545:
---
GitHub user dkuppitz opened a pull request:
https://github.com/apache/tinkerpop/pull/486
TINKERPOP-1545 IncidentToAdjacentStrategy is buggy
https://issues.apache.org/jira/browse/TINKERPOP-1545
Made `SimplePathStep` implement `PathProcessor` and
`IncidentToAdjacentStrategy` skip all traversals that contain path processing
steps.
The first few test suites of `docker/builder -t -i -n` succeeded and I will
let it run over night, but I'm confident, that nothing bad is gonna happen in
the other test suites (otherwise I'm going to revert the next line tomorrow).
VOTE: +1
You can merge this pull request into a Git repository by running:
$ git pull https://github.com/apache/tinkerpop TINKERPOP-1545
Alternatively you can review and apply these changes as the patch at:
https://github.com/apache/tinkerpop/pull/486.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 #486
commit 54dbeaacaf6ccfaab8db9de8ce736243fe32b78e
Author: Daniel Kuppitz
Date: 2016-11-10T23:00:03Z
Made SimplePathStep implement PathProcessor and IncidentToAdjacentStrategy
skip all traversals that contain path processing steps
> IncidentToAdjacentStrategy is buggy
> ---
>
> Key: TINKERPOP-1545
> URL: https://issues.apache.org/jira/browse/TINKERPOP-1545
> Project: TinkerPop
> Issue Type: Bug
>Affects Versions: 3.1.4, 3.2.3
>Reporter: Daniel Kuppitz
>Assignee: Daniel Kuppitz
>
> {{IncidentToAdjacentStrategy}} turns {{outE().inV().simplePath()}} into
> {{out().simplePath()}}, which will return a wrong result as soon as there is
> more than 1 edge between a pair of vertices.
> The set {{INVALIDATING_STEP_CLASSES}} should only contain
> {{PathProcessor.class}} and {{LambdaHolder.class}} Furthermore
> {{SimplePathStep}} should implement {{PathProcessor}}.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Assigned] (TINKERPOP-1545) IncidentToAdjacentStrategy is buggy
[
https://issues.apache.org/jira/browse/TINKERPOP-1545?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Daniel Kuppitz reassigned TINKERPOP-1545:
-
Assignee: Daniel Kuppitz
> IncidentToAdjacentStrategy is buggy
> ---
>
> Key: TINKERPOP-1545
> URL: https://issues.apache.org/jira/browse/TINKERPOP-1545
> Project: TinkerPop
> Issue Type: Bug
>Affects Versions: 3.1.4, 3.2.3
>Reporter: Daniel Kuppitz
>Assignee: Daniel Kuppitz
>
> {{IncidentToAdjacentStrategy}} turns {{outE().inV().simplePath()}} into
> {{out().simplePath()}}, which will return a wrong result as soon as there is
> more than 1 edge between a pair of vertices.
> The set {{INVALIDATING_STEP_CLASSES}} should only contain
> {{PathProcessor.class}} and {{LambdaHolder.class}} Furthermore
> {{SimplePathStep}} should implement {{PathProcessor}}.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (TINKERPOP-1489) Provide a Javascript Gremlin Language Variant
[ https://issues.apache.org/jira/browse/TINKERPOP-1489?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15655320#comment-15655320 ] ASF GitHub Bot commented on TINKERPOP-1489: --- Github user jbmusso commented on the issue: https://github.com/apache/tinkerpop/pull/450 Ah, it looks like [nashorn supports let and const keywords on 8u40](http://fr.slideshare.net/akihironishikawa/nashorn-in-the-future-en) so we could swap `var` for `let` and `const` unless we want to target earlier versions of Java8. I don't think adding a transpiler such as Babeljs to the mix is worth the trouble here since it's going to be a nightmare to maintain the build pipeline. However, it *could* make sense for more recent versions of Node. Node 7 would be happier with ES2015 code rather than ES5 ;) - see http://node.green/. I don't think it's realistic so I'm just putting it here for further reference, basically when Java9 is out (where [nashorn could fully support ES2015/6](http://fr.slideshare.net/akihironishikawa/nashorn-in-the-future-en)). Note that there is [a proposal for adding async iterator to JavaScript](https://github.com/tc39/proposal-async-iteration). It's currently in stage 3 so this could make it to the EcmaScript specification. Using `.next()` for async iteration might become a reality. > Provide a Javascript Gremlin Language Variant > - > > Key: TINKERPOP-1489 > URL: https://issues.apache.org/jira/browse/TINKERPOP-1489 > Project: TinkerPop > Issue Type: Improvement > Components: language-variant >Reporter: Jorge Bay > > It would be nice to have a Javascript Gremlin Language Variant that could > work with any ES5 runtime, specially the ones that support > [CommonJs|http://requirejs.org/docs/commonjs.html], like Node.js. > Nashorn, the engine shipped with JDK 8+, does not implement CommonJs but > provides [additional > extensions|https://wiki.openjdk.java.net/display/Nashorn/Nashorn+extensions] > making modular JavaScript possible. Nashorn should be supported in order to > run glv tests under the same infrastructure (JDK8). -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[GitHub] tinkerpop issue #450: TINKERPOP-1489 Javascript GLV
Github user jbmusso commented on the issue: https://github.com/apache/tinkerpop/pull/450 Ah, it looks like [nashorn supports let and const keywords on 8u40](http://fr.slideshare.net/akihironishikawa/nashorn-in-the-future-en) so we could swap `var` for `let` and `const` unless we want to target earlier versions of Java8. I don't think adding a transpiler such as Babeljs to the mix is worth the trouble here since it's going to be a nightmare to maintain the build pipeline. However, it *could* make sense for more recent versions of Node. Node 7 would be happier with ES2015 code rather than ES5 ;) - see http://node.green/. I don't think it's realistic so I'm just putting it here for further reference, basically when Java9 is out (where [nashorn could fully support ES2015/6](http://fr.slideshare.net/akihironishikawa/nashorn-in-the-future-en)). Note that there is [a proposal for adding async iterator to JavaScript](https://github.com/tc39/proposal-async-iteration). It's currently in stage 3 so this could make it to the EcmaScript specification. Using `.next()` for async iteration might become a reality. --- 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) terminal step
[
https://issues.apache.org/jira/browse/TINKERPOP-1490?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15655286#comment-15655286
]
ASF GitHub Bot commented on TINKERPOP-1490:
---
Github user aholmberg commented on the issue:
https://github.com/apache/tinkerpop/pull/478
> the type of future returned will depend on the underlying
RemoteConnection implementation.
That depends on whether you are okay leaking remote connection
implementation through this API. I have been trying to think about this
traversal API as something distinct from transport (in which case you would
probably want an abstraction).
> 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 aholmberg commented on the issue: https://github.com/apache/tinkerpop/pull/478 > the type of future returned will depend on the underlying RemoteConnection implementation. That depends on whether you are okay leaking remote connection implementation through this API. I have been trying to think about this traversal API as something distinct from transport (in which case you would probably want an abstraction). --- If your project is set up for it, you can reply to this email and have your reply appear on GitHub as well. If your project does not have this feature enabled and wishes so, or if the feature is enabled but not working, please contact infrastructure at infrastruct...@apache.org or file a JIRA ticket with INFRA. ---
Re: [DISCUSS] Add HGraphDB to graph system listing
I sorta share that sentiment however, I think we had that discussion back when we determined our listing requirements and we figured we couldn't figure out how to easily quantify "mature". On Thu, Nov 10, 2016 at 3:17 PM, Jean-Baptiste Musso wrote: > Interesting thing. +1 to adding HGraphDB to the list. > > Minor concern: I'm not sure if we want to manage a curated list of > implementations and maybe restrict to more mature projects. I'm just > thinking out loud here: I'm not targeting HGraphDB specifically (and I wish > them good luck - *cheers*). My main concern is that the project is very > young, but graph databases need as much publicity as they can. > > Jean-Baptiste > > On Thu, Nov 10, 2016 at 8:58 PM, Ted Wilmes wrote: > > > Hello everyone, > > Robert Yokota notified us today that he has developed an > > Apache TinkerPop enabled graph db: https://github.com/rayokota/hgraphdb. > > Correct me if I'm wrong Robert, but it looks like it's at the TinkerPop > > 3.2.3 version. > > > > I think HGraphDB meets our index listing requirements but I wanted to > bring > > it up > > just in case anyone felt differently. Unless there are any objections, > > I'll assume lazy > > consensus in three days (Sunday, November 13, 2016 2:00 CST) and add > > HGraphDB > > to the graph systems listing. > > > > Thanks, > > Ted > > >
Re: [DISCUSS] Add HGraphDB to graph system listing
Interesting thing. +1 to adding HGraphDB to the list. Minor concern: I'm not sure if we want to manage a curated list of implementations and maybe restrict to more mature projects. I'm just thinking out loud here: I'm not targeting HGraphDB specifically (and I wish them good luck - *cheers*). My main concern is that the project is very young, but graph databases need as much publicity as they can. Jean-Baptiste On Thu, Nov 10, 2016 at 8:58 PM, Ted Wilmes wrote: > Hello everyone, > Robert Yokota notified us today that he has developed an > Apache TinkerPop enabled graph db: https://github.com/rayokota/hgraphdb. > Correct me if I'm wrong Robert, but it looks like it's at the TinkerPop > 3.2.3 version. > > I think HGraphDB meets our index listing requirements but I wanted to bring > it up > just in case anyone felt differently. Unless there are any objections, > I'll assume lazy > consensus in three days (Sunday, November 13, 2016 2:00 CST) and add > HGraphDB > to the graph systems listing. > > Thanks, > Ted >
[jira] [Commented] (TINKERPOP-1547) Two bugs found associated with MatchStep: Path retraction and range count.
[
https://issues.apache.org/jira/browse/TINKERPOP-1547?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15655019#comment-15655019
]
ASF GitHub Bot commented on TINKERPOP-1547:
---
Github user dkuppitz commented on the issue:
https://github.com/apache/tinkerpop/pull/483
Changes pushed. `docker/build.sh -t -i -n` succeeded.
VOTE: +1
> Two bugs found associated with MatchStep: Path retraction and range count.
> --
>
> Key: TINKERPOP-1547
> URL: https://issues.apache.org/jira/browse/TINKERPOP-1547
> Project: TinkerPop
> Issue Type: Bug
> Components: process
>Affects Versions: 3.2.3
>Reporter: Marko A. Rodriguez
>Assignee: Marko A. Rodriguez
> Fix For: 3.2.4
>
>
> {{PathRetractionStrategy}} can retract end labels from traversals and thus,
> ruin a pattern match. We had 3 traversals in our test suite that were buggy
> because of this. Finally, if the user does a pattern of
> {{as("a").count().is(gt(10)).as("b")}}, this will fail because of
> {{RangeIsCountByStrategy}}.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[GitHub] tinkerpop issue #483: TINKERPOP-1547: Two bugs found associated with MatchSt...
Github user dkuppitz commented on the issue: https://github.com/apache/tinkerpop/pull/483 Changes pushed. `docker/build.sh -t -i -n` succeeded. 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. ---
[DISCUSS] Add HGraphDB to graph system listing
Hello everyone, Robert Yokota notified us today that he has developed an Apache TinkerPop enabled graph db: https://github.com/rayokota/hgraphdb. Correct me if I'm wrong Robert, but it looks like it's at the TinkerPop 3.2.3 version. I think HGraphDB meets our index listing requirements but I wanted to bring it up just in case anyone felt differently. Unless there are any objections, I'll assume lazy consensus in three days (Sunday, November 13, 2016 2:00 CST) and add HGraphDB to the graph systems listing. Thanks, Ted
Re: Add HGraphDB to the homepage index?
Hi Robert, I stumbled upon your announcement earlier today. Exciting news! It looks like your project meets the index listing requirements. I'm going to send another message to dev to make sure there is consensus. Thanks, Ted On Thu, Nov 10, 2016 at 1:15 PM, Robert Yokota wrote: > Hi, > > I wrote a TinkerPop 3 provider for HBase so it could be used as an OLTP > graph database. Would it be possible to get it added to the homepage index > listing? > > https://github.com/rayokota/hgraphdb > > https://rayokota.wordpress.com/2016/11/10/hgraphdb-hbase- > as-a-tinkerpop-graph-database/ > > Thanks, > Robert >
[jira] [Commented] (TINKERPOP-1490) Provider a Future based Traversal.async(Function) terminal step
[
https://issues.apache.org/jira/browse/TINKERPOP-1490?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15654950#comment-15654950
]
ASF GitHub Bot commented on TINKERPOP-1490:
---
Github user davebshow commented on the issue:
https://github.com/apache/tinkerpop/pull/478
After actually thinking about this, the type of future returned will depend
on the underlying `RemoteConnection` implementation. A call to the
method`promise` will cause a `(async)traversal_strategy` to call `apply`, the
result of this depends on the underlying remote connection, and all the GLV has
to do is pass the returned futures along to the end user. Therefore a Tornado
based driver would return a `tornado.concurrent.Future` etc. etc. Make sense?
Or am I missing something...?
> 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 davebshow commented on the issue: https://github.com/apache/tinkerpop/pull/478 After actually thinking about this, the type of future returned will depend on the underlying `RemoteConnection` implementation. A call to the method`promise` will cause a `(async)traversal_strategy` to call `apply`, the result of this depends on the underlying remote connection, and all the GLV has to do is pass the returned futures along to the end user. Therefore a Tornado based driver would return a `tornado.concurrent.Future` etc. etc. Make sense? Or am I missing something...? --- 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. ---
Add HGraphDB to the homepage index?
Hi, I wrote a TinkerPop 3 provider for HBase so it could be used as an OLTP graph database. Would it be possible to get it added to the homepage index listing? https://github.com/rayokota/hgraphdb https://rayokota.wordpress.com/2016/11/10/hgraphdb-hbase- as-a-tinkerpop-graph-database/ Thanks, Robert
[jira] [Commented] (TINKERPOP-1490) Provider a Future based Traversal.async(Function) terminal step
[
https://issues.apache.org/jira/browse/TINKERPOP-1490?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15654803#comment-15654803
]
ASF GitHub Bot commented on TINKERPOP-1490:
---
Github user aholmberg commented on the issue:
https://github.com/apache/tinkerpop/pull/478
Coupling the traversal API to a web framework does not seem appealing to
me. Could we consider using the [futures
backport](https://pypi.python.org/pypi/futures), which backports the Python 3
standard library features to Python 2?
> 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 aholmberg commented on the issue: https://github.com/apache/tinkerpop/pull/478 Coupling the traversal API to a web framework does not seem appealing to me. Could we consider using the [futures backport](https://pypi.python.org/pypi/futures), which backports the Python 3 standard library features to Python 2? --- 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-1541) Select should default to Pop.last semantics
[
https://issues.apache.org/jira/browse/TINKERPOP-1541?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15654712#comment-15654712
]
ASF GitHub Bot commented on TINKERPOP-1541:
---
Github user dkuppitz commented on the issue:
https://github.com/apache/tinkerpop/pull/482
I'm cool with that change. I still have to run a `docker/build.sh -t -i -n`
though - will do so as soon as I have the resources available (unless someone
else volunteers).
> Select should default to Pop.last semantics
> ---
>
> Key: TINKERPOP-1541
> URL: https://issues.apache.org/jira/browse/TINKERPOP-1541
> Project: TinkerPop
> Issue Type: Improvement
> Components: process
>Affects Versions: 3.2.3
>Reporter: Marko A. Rodriguez
>Assignee: Marko A. Rodriguez
> Labels: breaking
>
> Check this out:
> {code}
> gremlin> g.V().as('a').select('a').as('a').select('a')
> ==>[v[1],v[1]]
> ==>[v[2],v[2]]
> ==>[v[3],v[3]]
> ==>[v[4],v[4]]
> ==>[v[5],v[5]]
> ==>[v[6],v[6]]
> {code}
> Shouldn't we just return the uniques? This is a big decision as this can
> cause massive rippling breakage for users :).
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[GitHub] tinkerpop issue #482: TINKERPOP-1541: Select should default to Pop.last sema...
Github user dkuppitz commented on the issue: https://github.com/apache/tinkerpop/pull/482 I'm cool with that change. I still have to run a `docker/build.sh -t -i -n` though - will do so as soon as I have the resources available (unless someone else volunteers). --- 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-1541) Select should default to Pop.last semantics
[
https://issues.apache.org/jira/browse/TINKERPOP-1541?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15654484#comment-15654484
]
ASF GitHub Bot commented on TINKERPOP-1541:
---
Github user okram commented on the issue:
https://github.com/apache/tinkerpop/pull/482
When I go to merge, I will change the method name to `selectV3d2()` so if
you want to vote :) ... Also, I think we need @dkuppitz and @robertdale
and @mhfrantz to have a look and vote too.
> Select should default to Pop.last semantics
> ---
>
> Key: TINKERPOP-1541
> URL: https://issues.apache.org/jira/browse/TINKERPOP-1541
> Project: TinkerPop
> Issue Type: Improvement
> Components: process
>Affects Versions: 3.2.3
>Reporter: Marko A. Rodriguez
>Assignee: Marko A. Rodriguez
> Labels: breaking
>
> Check this out:
> {code}
> gremlin> g.V().as('a').select('a').as('a').select('a')
> ==>[v[1],v[1]]
> ==>[v[2],v[2]]
> ==>[v[3],v[3]]
> ==>[v[4],v[4]]
> ==>[v[5],v[5]]
> ==>[v[6],v[6]]
> {code}
> Shouldn't we just return the uniques? This is a big decision as this can
> cause massive rippling breakage for users :).
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[GitHub] tinkerpop issue #482: TINKERPOP-1541: Select should default to Pop.last sema...
Github user okram commented on the issue: https://github.com/apache/tinkerpop/pull/482 When I go to merge, I will change the method name to `selectV3d2()` so if you want to vote :) ... Also, I think we need @dkuppitz and @robertdale and @mhfrantz to have a look and vote too. --- 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] [Created] (TINKERPOP-1549) Add more RangeStep test cases
Daniel Kuppitz created TINKERPOP-1549:
-
Summary: Add more RangeStep test cases
Key: TINKERPOP-1549
URL: https://issues.apache.org/jira/browse/TINKERPOP-1549
Project: TinkerPop
Issue Type: Improvement
Components: process
Reporter: Daniel Kuppitz
We do support negative values in {{RangeStep}}, e.g. to have an open end
({{skip()}} semantics). This is broken in DSEG, probably because we don't cover
this case in our test suite (not verified).
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Created] (TINKERPOP-1548) Traversals can complete before interrupted in TraversalInterruptionComputerTest
Ted Wilmes created TINKERPOP-1548:
-
Summary: Traversals can complete before interrupted in
TraversalInterruptionComputerTest
Key: TINKERPOP-1548
URL: https://issues.apache.org/jira/browse/TINKERPOP-1548
Project: TinkerPop
Issue Type: Bug
Components: test-suite
Affects Versions: 3.2.3
Reporter: Ted Wilmes
Assignee: Ted Wilmes
TinkerGraphComputer {{TraversalInterruptionComputerTest}} fails for me fairly
consistently. It appears that the test traversal is completing before
{{t.interrupt}} on occasion which causes the test to fail because the
{{TraversalInterruptedException}} is never thrown. I can reproduce this
failure more consistently when running TinkerGraphComputer with 1 worker.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (TINKERPOP-1547) Two bugs found associated with MatchStep: Path retraction and range count.
[
https://issues.apache.org/jira/browse/TINKERPOP-1547?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15654141#comment-15654141
]
ASF GitHub Bot commented on TINKERPOP-1547:
---
Github user okram commented on the issue:
https://github.com/apache/tinkerpop/pull/483
@dkuppitz -- note that @spmallette never VOTE'd so when you are done with
your testing and updates, just VOTE and I will merge.
> Two bugs found associated with MatchStep: Path retraction and range count.
> --
>
> Key: TINKERPOP-1547
> URL: https://issues.apache.org/jira/browse/TINKERPOP-1547
> Project: TinkerPop
> Issue Type: Bug
> Components: process
>Affects Versions: 3.2.3
>Reporter: Marko A. Rodriguez
>Assignee: Marko A. Rodriguez
> Fix For: 3.2.4
>
>
> {{PathRetractionStrategy}} can retract end labels from traversals and thus,
> ruin a pattern match. We had 3 traversals in our test suite that were buggy
> because of this. Finally, if the user does a pattern of
> {{as("a").count().is(gt(10)).as("b")}}, this will fail because of
> {{RangeIsCountByStrategy}}.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[GitHub] tinkerpop issue #483: TINKERPOP-1547: Two bugs found associated with MatchSt...
Github user okram commented on the issue: https://github.com/apache/tinkerpop/pull/483 @dkuppitz -- note that @spmallette never VOTE'd so when you are done with your testing and updates, just VOTE and I will 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] [Assigned] (TINKERPOP-1428) profile() throws NPE for union(group, group)
[
https://issues.apache.org/jira/browse/TINKERPOP-1428?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Marko A. Rodriguez reassigned TINKERPOP-1428:
-
Assignee: Marko A. Rodriguez
> profile() throws NPE for union(group, group)
>
>
> Key: TINKERPOP-1428
> URL: https://issues.apache.org/jira/browse/TINKERPOP-1428
> Project: TinkerPop
> Issue Type: Bug
> Components: process
>Affects Versions: 3.2.1
>Reporter: Daniel Kuppitz
>Assignee: Marko A. Rodriguez
> Fix For: 3.2.4
>
>
> {noformat}
> gremlin> g.V().union(group("m").by("name"), group("m").by("name")).profile()
> java.lang.NullPointerException
> Type ':help' or ':h' for help.
> Display stack trace? [yN]y
> java.lang.NullPointerException
> at
> org.apache.tinkerpop.gremlin.process.traversal.util.DefaultTraversalMetrics.handleNestedTraversals(DefaultTraversalMetrics.java:239)
> at
> org.apache.tinkerpop.gremlin.process.traversal.util.DefaultTraversalMetrics.handleNestedTraversals(DefaultTraversalMetrics.java:251)
> at
> org.apache.tinkerpop.gremlin.process.traversal.util.DefaultTraversalMetrics.handleNestedTraversals(DefaultTraversalMetrics.java:254)
> at
> org.apache.tinkerpop.gremlin.process.traversal.util.DefaultTraversalMetrics.setMetrics(DefaultTraversalMetrics.java:204)
> at
> org.apache.tinkerpop.gremlin.process.traversal.step.sideEffect.ProfileSideEffectStep.hasNext(ProfileSideEffectStep.java:73)
> at
> org.apache.tinkerpop.gremlin.process.traversal.step.util.ExpandableStepIterator.hasNext(ExpandableStepIterator.java:42)
> at
> org.apache.tinkerpop.gremlin.process.traversal.step.util.SupplyingBarrierStep.processAllStarts(SupplyingBarrierStep.java:83)
> at
> org.apache.tinkerpop.gremlin.process.traversal.step.util.SupplyingBarrierStep.processNextStart(SupplyingBarrierStep.java:70)
> at
> org.apache.tinkerpop.gremlin.process.traversal.step.util.AbstractStep.hasNext(AbstractStep.java:143)
> at
> org.apache.tinkerpop.gremlin.process.traversal.util.DefaultTraversal.hasNext(DefaultTraversal.java:179)
> at
> org.apache.tinkerpop.gremlin.console.Console$_closure3.doCall(Console.groovy:226)
> at sun.reflect.GeneratedMethodAccessor42.invoke(Unknown Source)
> at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:498)
> at
> org.codehaus.groovy.reflection.CachedMethod.invoke(CachedMethod.java:93)
> at groovy.lang.MetaMethod.doMethodInvoke(MetaMethod.java:325)
> at
> org.codehaus.groovy.runtime.metaclass.ClosureMetaClass.invokeMethod(ClosureMetaClass.java:294)
> at groovy.lang.MetaClassImpl.invokeMethod(MetaClassImpl.java:1024)
> at
> org.codehaus.groovy.tools.shell.Groovysh.setLastResult(Groovysh.groovy:446)
> at org.codehaus.groovy.tools.shell.Groovysh.execute(Groovysh.groovy:190)
> at
> org.apache.tinkerpop.gremlin.console.GremlinGroovysh.super$3$execute(GremlinGroovysh.groovy)
> at sun.reflect.GeneratedMethodAccessor14.invoke(Unknown Source)
> at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:498)
> at
> org.codehaus.groovy.reflection.CachedMethod.invoke(CachedMethod.java:93)
> at groovy.lang.MetaMethod.doMethodInvoke(MetaMethod.java:325)
> at groovy.lang.MetaClassImpl.invokeMethod(MetaClassImpl.java:1215)
> at
> org.codehaus.groovy.runtime.ScriptBytecodeAdapter.invokeMethodOnSuperN(ScriptBytecodeAdapter.java:132)
> at
> org.apache.tinkerpop.gremlin.console.GremlinGroovysh.execute(GremlinGroovysh.groovy:72)
> at org.codehaus.groovy.tools.shell.Shell.leftShift(Shell.groovy:122)
> at org.codehaus.groovy.tools.shell.ShellRunner.work(ShellRunner.groovy:95)
> at
> org.codehaus.groovy.tools.shell.InteractiveShellRunner.super$2$work(InteractiveShellRunner.groovy)
> at sun.reflect.GeneratedMethodAccessor38.invoke(Unknown Source)
> at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:498)
> at
> org.codehaus.groovy.reflection.CachedMethod.invoke(CachedMethod.java:93)
> at groovy.lang.MetaMethod.doMethodInvoke(MetaMethod.java:325)
> at groovy.lang.MetaClassImpl.invokeMethod(MetaClassImpl.java:1215)
> at
> org.codehaus.groovy.runtime.ScriptBytecodeAdapter.invokeMethodOnSuperN(ScriptBytecodeAdapter.java:132)
> at
> org.codehaus.groovy.runtime.ScriptBytecodeAdapter.invokeMethodOnSuper0(ScriptBytecodeAdapter.java:152)
> at
> org.codehaus.groovy.tools.shell.InteractiveShellRunner.work(InteractiveShellRunner.groovy:124)
> at org.codehaus.groovy.tools.shell.ShellRunner.run(ShellRunner.groovy:59)
> at
[jira] [Closed] (TINKERPOP-1428) profile() throws NPE for union(group, group)
[
https://issues.apache.org/jira/browse/TINKERPOP-1428?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Marko A. Rodriguez closed TINKERPOP-1428.
-
Resolution: Fixed
Fix Version/s: 3.2.4
> profile() throws NPE for union(group, group)
>
>
> Key: TINKERPOP-1428
> URL: https://issues.apache.org/jira/browse/TINKERPOP-1428
> Project: TinkerPop
> Issue Type: Bug
> Components: process
>Affects Versions: 3.2.1
>Reporter: Daniel Kuppitz
>Assignee: Marko A. Rodriguez
> Fix For: 3.2.4
>
>
> {noformat}
> gremlin> g.V().union(group("m").by("name"), group("m").by("name")).profile()
> java.lang.NullPointerException
> Type ':help' or ':h' for help.
> Display stack trace? [yN]y
> java.lang.NullPointerException
> at
> org.apache.tinkerpop.gremlin.process.traversal.util.DefaultTraversalMetrics.handleNestedTraversals(DefaultTraversalMetrics.java:239)
> at
> org.apache.tinkerpop.gremlin.process.traversal.util.DefaultTraversalMetrics.handleNestedTraversals(DefaultTraversalMetrics.java:251)
> at
> org.apache.tinkerpop.gremlin.process.traversal.util.DefaultTraversalMetrics.handleNestedTraversals(DefaultTraversalMetrics.java:254)
> at
> org.apache.tinkerpop.gremlin.process.traversal.util.DefaultTraversalMetrics.setMetrics(DefaultTraversalMetrics.java:204)
> at
> org.apache.tinkerpop.gremlin.process.traversal.step.sideEffect.ProfileSideEffectStep.hasNext(ProfileSideEffectStep.java:73)
> at
> org.apache.tinkerpop.gremlin.process.traversal.step.util.ExpandableStepIterator.hasNext(ExpandableStepIterator.java:42)
> at
> org.apache.tinkerpop.gremlin.process.traversal.step.util.SupplyingBarrierStep.processAllStarts(SupplyingBarrierStep.java:83)
> at
> org.apache.tinkerpop.gremlin.process.traversal.step.util.SupplyingBarrierStep.processNextStart(SupplyingBarrierStep.java:70)
> at
> org.apache.tinkerpop.gremlin.process.traversal.step.util.AbstractStep.hasNext(AbstractStep.java:143)
> at
> org.apache.tinkerpop.gremlin.process.traversal.util.DefaultTraversal.hasNext(DefaultTraversal.java:179)
> at
> org.apache.tinkerpop.gremlin.console.Console$_closure3.doCall(Console.groovy:226)
> at sun.reflect.GeneratedMethodAccessor42.invoke(Unknown Source)
> at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:498)
> at
> org.codehaus.groovy.reflection.CachedMethod.invoke(CachedMethod.java:93)
> at groovy.lang.MetaMethod.doMethodInvoke(MetaMethod.java:325)
> at
> org.codehaus.groovy.runtime.metaclass.ClosureMetaClass.invokeMethod(ClosureMetaClass.java:294)
> at groovy.lang.MetaClassImpl.invokeMethod(MetaClassImpl.java:1024)
> at
> org.codehaus.groovy.tools.shell.Groovysh.setLastResult(Groovysh.groovy:446)
> at org.codehaus.groovy.tools.shell.Groovysh.execute(Groovysh.groovy:190)
> at
> org.apache.tinkerpop.gremlin.console.GremlinGroovysh.super$3$execute(GremlinGroovysh.groovy)
> at sun.reflect.GeneratedMethodAccessor14.invoke(Unknown Source)
> at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:498)
> at
> org.codehaus.groovy.reflection.CachedMethod.invoke(CachedMethod.java:93)
> at groovy.lang.MetaMethod.doMethodInvoke(MetaMethod.java:325)
> at groovy.lang.MetaClassImpl.invokeMethod(MetaClassImpl.java:1215)
> at
> org.codehaus.groovy.runtime.ScriptBytecodeAdapter.invokeMethodOnSuperN(ScriptBytecodeAdapter.java:132)
> at
> org.apache.tinkerpop.gremlin.console.GremlinGroovysh.execute(GremlinGroovysh.groovy:72)
> at org.codehaus.groovy.tools.shell.Shell.leftShift(Shell.groovy:122)
> at org.codehaus.groovy.tools.shell.ShellRunner.work(ShellRunner.groovy:95)
> at
> org.codehaus.groovy.tools.shell.InteractiveShellRunner.super$2$work(InteractiveShellRunner.groovy)
> at sun.reflect.GeneratedMethodAccessor38.invoke(Unknown Source)
> at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:498)
> at
> org.codehaus.groovy.reflection.CachedMethod.invoke(CachedMethod.java:93)
> at groovy.lang.MetaMethod.doMethodInvoke(MetaMethod.java:325)
> at groovy.lang.MetaClassImpl.invokeMethod(MetaClassImpl.java:1215)
> at
> org.codehaus.groovy.runtime.ScriptBytecodeAdapter.invokeMethodOnSuperN(ScriptBytecodeAdapter.java:132)
> at
> org.codehaus.groovy.runtime.ScriptBytecodeAdapter.invokeMethodOnSuper0(ScriptBytecodeAdapter.java:152)
> at
> org.codehaus.groovy.tools.shell.InteractiveShellRunner.work(InteractiveShellRunner.groovy:124)
> at org.codehaus.groovy.tools.shell.ShellRunner.run(ShellRunner.groovy:59)
>
[jira] [Commented] (TINKERPOP-1428) profile() throws NPE for union(group, group)
[
https://issues.apache.org/jira/browse/TINKERPOP-1428?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15654138#comment-15654138
]
ASF GitHub Bot commented on TINKERPOP-1428:
---
Github user asfgit closed the pull request at:
https://github.com/apache/tinkerpop/pull/481
> profile() throws NPE for union(group, group)
>
>
> Key: TINKERPOP-1428
> URL: https://issues.apache.org/jira/browse/TINKERPOP-1428
> Project: TinkerPop
> Issue Type: Bug
> Components: process
>Affects Versions: 3.2.1
>Reporter: Daniel Kuppitz
> Fix For: 3.2.4
>
>
> {noformat}
> gremlin> g.V().union(group("m").by("name"), group("m").by("name")).profile()
> java.lang.NullPointerException
> Type ':help' or ':h' for help.
> Display stack trace? [yN]y
> java.lang.NullPointerException
> at
> org.apache.tinkerpop.gremlin.process.traversal.util.DefaultTraversalMetrics.handleNestedTraversals(DefaultTraversalMetrics.java:239)
> at
> org.apache.tinkerpop.gremlin.process.traversal.util.DefaultTraversalMetrics.handleNestedTraversals(DefaultTraversalMetrics.java:251)
> at
> org.apache.tinkerpop.gremlin.process.traversal.util.DefaultTraversalMetrics.handleNestedTraversals(DefaultTraversalMetrics.java:254)
> at
> org.apache.tinkerpop.gremlin.process.traversal.util.DefaultTraversalMetrics.setMetrics(DefaultTraversalMetrics.java:204)
> at
> org.apache.tinkerpop.gremlin.process.traversal.step.sideEffect.ProfileSideEffectStep.hasNext(ProfileSideEffectStep.java:73)
> at
> org.apache.tinkerpop.gremlin.process.traversal.step.util.ExpandableStepIterator.hasNext(ExpandableStepIterator.java:42)
> at
> org.apache.tinkerpop.gremlin.process.traversal.step.util.SupplyingBarrierStep.processAllStarts(SupplyingBarrierStep.java:83)
> at
> org.apache.tinkerpop.gremlin.process.traversal.step.util.SupplyingBarrierStep.processNextStart(SupplyingBarrierStep.java:70)
> at
> org.apache.tinkerpop.gremlin.process.traversal.step.util.AbstractStep.hasNext(AbstractStep.java:143)
> at
> org.apache.tinkerpop.gremlin.process.traversal.util.DefaultTraversal.hasNext(DefaultTraversal.java:179)
> at
> org.apache.tinkerpop.gremlin.console.Console$_closure3.doCall(Console.groovy:226)
> at sun.reflect.GeneratedMethodAccessor42.invoke(Unknown Source)
> at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:498)
> at
> org.codehaus.groovy.reflection.CachedMethod.invoke(CachedMethod.java:93)
> at groovy.lang.MetaMethod.doMethodInvoke(MetaMethod.java:325)
> at
> org.codehaus.groovy.runtime.metaclass.ClosureMetaClass.invokeMethod(ClosureMetaClass.java:294)
> at groovy.lang.MetaClassImpl.invokeMethod(MetaClassImpl.java:1024)
> at
> org.codehaus.groovy.tools.shell.Groovysh.setLastResult(Groovysh.groovy:446)
> at org.codehaus.groovy.tools.shell.Groovysh.execute(Groovysh.groovy:190)
> at
> org.apache.tinkerpop.gremlin.console.GremlinGroovysh.super$3$execute(GremlinGroovysh.groovy)
> at sun.reflect.GeneratedMethodAccessor14.invoke(Unknown Source)
> at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:498)
> at
> org.codehaus.groovy.reflection.CachedMethod.invoke(CachedMethod.java:93)
> at groovy.lang.MetaMethod.doMethodInvoke(MetaMethod.java:325)
> at groovy.lang.MetaClassImpl.invokeMethod(MetaClassImpl.java:1215)
> at
> org.codehaus.groovy.runtime.ScriptBytecodeAdapter.invokeMethodOnSuperN(ScriptBytecodeAdapter.java:132)
> at
> org.apache.tinkerpop.gremlin.console.GremlinGroovysh.execute(GremlinGroovysh.groovy:72)
> at org.codehaus.groovy.tools.shell.Shell.leftShift(Shell.groovy:122)
> at org.codehaus.groovy.tools.shell.ShellRunner.work(ShellRunner.groovy:95)
> at
> org.codehaus.groovy.tools.shell.InteractiveShellRunner.super$2$work(InteractiveShellRunner.groovy)
> at sun.reflect.GeneratedMethodAccessor38.invoke(Unknown Source)
> at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:498)
> at
> org.codehaus.groovy.reflection.CachedMethod.invoke(CachedMethod.java:93)
> at groovy.lang.MetaMethod.doMethodInvoke(MetaMethod.java:325)
> at groovy.lang.MetaClassImpl.invokeMethod(MetaClassImpl.java:1215)
> at
> org.codehaus.groovy.runtime.ScriptBytecodeAdapter.invokeMethodOnSuperN(ScriptBytecodeAdapter.java:132)
> at
> org.codehaus.groovy.runtime.ScriptBytecodeAdapter.invokeMethodOnSuper0(ScriptBytecodeAdapter.java:152)
> at
> org.codehaus.groovy.tools.shell.InteractiveShellRunner.work(InteractiveShellRunner.groovy:124)
> at org.codehaus.gr
[jira] [Commented] (TINKERPOP-1490) Provider a Future based Traversal.async(Function) terminal step
[
https://issues.apache.org/jira/browse/TINKERPOP-1490?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15654139#comment-15654139
]
ASF GitHub Bot commented on TINKERPOP-1490:
---
Github user spmallette commented on the issue:
https://github.com/apache/tinkerpop/pull/478
thanks @davebshow - i might ask for your assistance on implementing that.
still trying to get it right for java. that blocking call in `RemoteStep`
stinks. having a bit of a hard time trying to get the future delegated all the
way to the driver without tearing stuff 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 thanks @davebshow - i might ask for your assistance on implementing that. still trying to get it right for java. that blocking call in `RemoteStep` stinks. having a bit of a hard time trying to get the future delegated all the way to the driver without tearing stuff 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. ---
[GitHub] tinkerpop pull request #481: TINKERPOP-1428: profile() throws NPE for union(...
Github user asfgit closed the pull request at: https://github.com/apache/tinkerpop/pull/481 --- 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-1547) Two bugs found associated with MatchStep: Path retraction and range count.
[
https://issues.apache.org/jira/browse/TINKERPOP-1547?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15654133#comment-15654133
]
ASF GitHub Bot commented on TINKERPOP-1547:
---
Github user dkuppitz commented on the issue:
https://github.com/apache/tinkerpop/pull/483
Please don't merge this PR yet. While testing the changes in
`RangeByIsCountStrategy` I realized that we can add a minor tweak to get
another great optimization. I'll push my local changes as soon as
`docker/build.sh -t -i` reports success.
> Two bugs found associated with MatchStep: Path retraction and range count.
> --
>
> Key: TINKERPOP-1547
> URL: https://issues.apache.org/jira/browse/TINKERPOP-1547
> Project: TinkerPop
> Issue Type: Bug
> Components: process
>Affects Versions: 3.2.3
>Reporter: Marko A. Rodriguez
>Assignee: Marko A. Rodriguez
> Fix For: 3.2.4
>
>
> {{PathRetractionStrategy}} can retract end labels from traversals and thus,
> ruin a pattern match. We had 3 traversals in our test suite that were buggy
> because of this. Finally, if the user does a pattern of
> {{as("a").count().is(gt(10)).as("b")}}, this will fail because of
> {{RangeIsCountByStrategy}}.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[GitHub] tinkerpop issue #483: TINKERPOP-1547: Two bugs found associated with MatchSt...
Github user dkuppitz commented on the issue: https://github.com/apache/tinkerpop/pull/483 Please don't merge this PR yet. While testing the changes in `RangeByIsCountStrategy` I realized that we can add a minor tweak to get another great optimization. I'll push my local changes as soon as `docker/build.sh -t -i` reports success. --- 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) terminal step
[
https://issues.apache.org/jira/browse/TINKERPOP-1490?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15654127#comment-15654127
]
ASF GitHub Bot commented on TINKERPOP-1490:
---
Github user davebshow commented on the issue:
https://github.com/apache/tinkerpop/pull/478
@spmallette you can easily implement something similar in Python using
Futures. Using `tornado.concurrent.Future` would probably make the most sense,
as is is already 2/3 compatible and should work with any Python async syntax
(`yield`/`yield from`/`await`). The only problem with is that this ties the GLV
code more tightly to Tornado, which was previously only used for IO; however, a
similar implementation of Future isn't included with the Python 2 standard
library, so Tornado is probably the best option. I actually did something
pretty similar to this in the `gremlinclient` library.
> 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 davebshow commented on the issue: https://github.com/apache/tinkerpop/pull/478 @spmallette you can easily implement something similar in Python using Futures. Using `tornado.concurrent.Future` would probably make the most sense, as is is already 2/3 compatible and should work with any Python async syntax (`yield`/`yield from`/`await`). The only problem with is that this ties the GLV code more tightly to Tornado, which was previously only used for IO; however, a similar implementation of Future isn't included with the Python 2 standard library, so Tornado is probably the best option. I actually did something pretty similar to this in the `gremlinclient` library. --- 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-1541) Select should default to Pop.last semantics
[
https://issues.apache.org/jira/browse/TINKERPOP-1541?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15654068#comment-15654068
]
ASF GitHub Bot commented on TINKERPOP-1541:
---
Github user spmallette commented on the issue:
https://github.com/apache/tinkerpop/pull/482
ok - if it's trivial, then perhaps not worrying about.
> Select should default to Pop.last semantics
> ---
>
> Key: TINKERPOP-1541
> URL: https://issues.apache.org/jira/browse/TINKERPOP-1541
> Project: TinkerPop
> Issue Type: Improvement
> Components: process
>Affects Versions: 3.2.3
>Reporter: Marko A. Rodriguez
>Assignee: Marko A. Rodriguez
> Labels: breaking
>
> Check this out:
> {code}
> gremlin> g.V().as('a').select('a').as('a').select('a')
> ==>[v[1],v[1]]
> ==>[v[2],v[2]]
> ==>[v[3],v[3]]
> ==>[v[4],v[4]]
> ==>[v[5],v[5]]
> ==>[v[6],v[6]]
> {code}
> Shouldn't we just return the uniques? This is a big decision as this can
> cause massive rippling breakage for users :).
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[GitHub] tinkerpop issue #482: TINKERPOP-1541: Select should default to Pop.last sema...
Github user spmallette commented on the issue: https://github.com/apache/tinkerpop/pull/482 ok - if it's trivial, then perhaps not worrying about. --- 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-1541) Select should default to Pop.last semantics
[
https://issues.apache.org/jira/browse/TINKERPOP-1541?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15654066#comment-15654066
]
ASF GitHub Bot commented on TINKERPOP-1541:
---
Github user okram commented on the issue:
https://github.com/apache/tinkerpop/pull/482
The only difference is `select(Pop.mix,...)` (that is `selectV3d2()`) and
there are 6 or so tests that test it in `RangeTest` and `TailTest`. I can
explicitly make them use the method `selectV3d2()`, but as you can see, its
simply just a call to `select(Pop.mix,...)`. I could make a `SelectV3d2Test`
and just copy those range tests over and call those methods explicitly, but
seems pointless as unlike `groupV320()`, its not a new step with different
semantics, its the same step with just a different argument.
> Select should default to Pop.last semantics
> ---
>
> Key: TINKERPOP-1541
> URL: https://issues.apache.org/jira/browse/TINKERPOP-1541
> Project: TinkerPop
> Issue Type: Improvement
> Components: process
>Affects Versions: 3.2.3
>Reporter: Marko A. Rodriguez
>Assignee: Marko A. Rodriguez
> Labels: breaking
>
> Check this out:
> {code}
> gremlin> g.V().as('a').select('a').as('a').select('a')
> ==>[v[1],v[1]]
> ==>[v[2],v[2]]
> ==>[v[3],v[3]]
> ==>[v[4],v[4]]
> ==>[v[5],v[5]]
> ==>[v[6],v[6]]
> {code}
> Shouldn't we just return the uniques? This is a big decision as this can
> cause massive rippling breakage for users :).
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[GitHub] tinkerpop issue #482: TINKERPOP-1541: Select should default to Pop.last sema...
Github user okram commented on the issue: https://github.com/apache/tinkerpop/pull/482 The only difference is `select(Pop.mix,...)` (that is `selectV3d2()`) and there are 6 or so tests that test it in `RangeTest` and `TailTest`. I can explicitly make them use the method `selectV3d2()`, but as you can see, its simply just a call to `select(Pop.mix,...)`. I could make a `SelectV3d2Test` and just copy those range tests over and call those methods explicitly, but seems pointless as unlike `groupV320()`, its not a new step with different semantics, its the same step with just a different argument. --- 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-1547) Two bugs found associated with MatchStep: Path retraction and range count.
[
https://issues.apache.org/jira/browse/TINKERPOP-1547?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15653859#comment-15653859
]
ASF GitHub Bot commented on TINKERPOP-1547:
---
Github user spmallette commented on the issue:
https://github.com/apache/tinkerpop/pull/483
@twilmes can you please send some specifics on what interruption tests were
tanking on you and under what circumstances? Maybe just ping me on hipchat when
you have a moment rather than go through it here since it seem unrelated to
this PR.
> Two bugs found associated with MatchStep: Path retraction and range count.
> --
>
> Key: TINKERPOP-1547
> URL: https://issues.apache.org/jira/browse/TINKERPOP-1547
> Project: TinkerPop
> Issue Type: Bug
> Components: process
>Affects Versions: 3.2.3
>Reporter: Marko A. Rodriguez
>Assignee: Marko A. Rodriguez
> Fix For: 3.2.4
>
>
> {{PathRetractionStrategy}} can retract end labels from traversals and thus,
> ruin a pattern match. We had 3 traversals in our test suite that were buggy
> because of this. Finally, if the user does a pattern of
> {{as("a").count().is(gt(10)).as("b")}}, this will fail because of
> {{RangeIsCountByStrategy}}.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[GitHub] tinkerpop issue #483: TINKERPOP-1547: Two bugs found associated with MatchSt...
Github user spmallette commented on the issue: https://github.com/apache/tinkerpop/pull/483 @twilmes can you please send some specifics on what interruption tests were tanking on you and under what circumstances? Maybe just ping me on hipchat when you have a moment rather than go through it here since it seem unrelated to this PR. --- 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-1541) Select should default to Pop.last semantics
[
https://issues.apache.org/jira/browse/TINKERPOP-1541?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15653855#comment-15653855
]
ASF GitHub Bot commented on TINKERPOP-1541:
---
Github user spmallette commented on the issue:
https://github.com/apache/tinkerpop/pull/482
It should be `selectV3d2()` given that it will yield backward compatibility
to 3.2.x.
Maybe I missed it, but are there any tests for `selectV3d2()` - at least
something to exercise the old way of doing things?
> Select should default to Pop.last semantics
> ---
>
> Key: TINKERPOP-1541
> URL: https://issues.apache.org/jira/browse/TINKERPOP-1541
> Project: TinkerPop
> Issue Type: Improvement
> Components: process
>Affects Versions: 3.2.3
>Reporter: Marko A. Rodriguez
>Assignee: Marko A. Rodriguez
> Labels: breaking
>
> Check this out:
> {code}
> gremlin> g.V().as('a').select('a').as('a').select('a')
> ==>[v[1],v[1]]
> ==>[v[2],v[2]]
> ==>[v[3],v[3]]
> ==>[v[4],v[4]]
> ==>[v[5],v[5]]
> ==>[v[6],v[6]]
> {code}
> Shouldn't we just return the uniques? This is a big decision as this can
> cause massive rippling breakage for users :).
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[GitHub] tinkerpop issue #482: TINKERPOP-1541: Select should default to Pop.last sema...
Github user spmallette commented on the issue: https://github.com/apache/tinkerpop/pull/482 It should be `selectV3d2()` given that it will yield backward compatibility to 3.2.x. Maybe I missed it, but are there any tests for `selectV3d2()` - at least something to exercise the old way of doing things? --- 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-1428) profile() throws NPE for union(group, group)
[
https://issues.apache.org/jira/browse/TINKERPOP-1428?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15653847#comment-15653847
]
ASF GitHub Bot commented on TINKERPOP-1428:
---
Github user spmallette commented on the issue:
https://github.com/apache/tinkerpop/pull/481
VOTE +1
> profile() throws NPE for union(group, group)
>
>
> Key: TINKERPOP-1428
> URL: https://issues.apache.org/jira/browse/TINKERPOP-1428
> Project: TinkerPop
> Issue Type: Bug
> Components: process
>Affects Versions: 3.2.1
>Reporter: Daniel Kuppitz
>
> {noformat}
> gremlin> g.V().union(group("m").by("name"), group("m").by("name")).profile()
> java.lang.NullPointerException
> Type ':help' or ':h' for help.
> Display stack trace? [yN]y
> java.lang.NullPointerException
> at
> org.apache.tinkerpop.gremlin.process.traversal.util.DefaultTraversalMetrics.handleNestedTraversals(DefaultTraversalMetrics.java:239)
> at
> org.apache.tinkerpop.gremlin.process.traversal.util.DefaultTraversalMetrics.handleNestedTraversals(DefaultTraversalMetrics.java:251)
> at
> org.apache.tinkerpop.gremlin.process.traversal.util.DefaultTraversalMetrics.handleNestedTraversals(DefaultTraversalMetrics.java:254)
> at
> org.apache.tinkerpop.gremlin.process.traversal.util.DefaultTraversalMetrics.setMetrics(DefaultTraversalMetrics.java:204)
> at
> org.apache.tinkerpop.gremlin.process.traversal.step.sideEffect.ProfileSideEffectStep.hasNext(ProfileSideEffectStep.java:73)
> at
> org.apache.tinkerpop.gremlin.process.traversal.step.util.ExpandableStepIterator.hasNext(ExpandableStepIterator.java:42)
> at
> org.apache.tinkerpop.gremlin.process.traversal.step.util.SupplyingBarrierStep.processAllStarts(SupplyingBarrierStep.java:83)
> at
> org.apache.tinkerpop.gremlin.process.traversal.step.util.SupplyingBarrierStep.processNextStart(SupplyingBarrierStep.java:70)
> at
> org.apache.tinkerpop.gremlin.process.traversal.step.util.AbstractStep.hasNext(AbstractStep.java:143)
> at
> org.apache.tinkerpop.gremlin.process.traversal.util.DefaultTraversal.hasNext(DefaultTraversal.java:179)
> at
> org.apache.tinkerpop.gremlin.console.Console$_closure3.doCall(Console.groovy:226)
> at sun.reflect.GeneratedMethodAccessor42.invoke(Unknown Source)
> at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:498)
> at
> org.codehaus.groovy.reflection.CachedMethod.invoke(CachedMethod.java:93)
> at groovy.lang.MetaMethod.doMethodInvoke(MetaMethod.java:325)
> at
> org.codehaus.groovy.runtime.metaclass.ClosureMetaClass.invokeMethod(ClosureMetaClass.java:294)
> at groovy.lang.MetaClassImpl.invokeMethod(MetaClassImpl.java:1024)
> at
> org.codehaus.groovy.tools.shell.Groovysh.setLastResult(Groovysh.groovy:446)
> at org.codehaus.groovy.tools.shell.Groovysh.execute(Groovysh.groovy:190)
> at
> org.apache.tinkerpop.gremlin.console.GremlinGroovysh.super$3$execute(GremlinGroovysh.groovy)
> at sun.reflect.GeneratedMethodAccessor14.invoke(Unknown Source)
> at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:498)
> at
> org.codehaus.groovy.reflection.CachedMethod.invoke(CachedMethod.java:93)
> at groovy.lang.MetaMethod.doMethodInvoke(MetaMethod.java:325)
> at groovy.lang.MetaClassImpl.invokeMethod(MetaClassImpl.java:1215)
> at
> org.codehaus.groovy.runtime.ScriptBytecodeAdapter.invokeMethodOnSuperN(ScriptBytecodeAdapter.java:132)
> at
> org.apache.tinkerpop.gremlin.console.GremlinGroovysh.execute(GremlinGroovysh.groovy:72)
> at org.codehaus.groovy.tools.shell.Shell.leftShift(Shell.groovy:122)
> at org.codehaus.groovy.tools.shell.ShellRunner.work(ShellRunner.groovy:95)
> at
> org.codehaus.groovy.tools.shell.InteractiveShellRunner.super$2$work(InteractiveShellRunner.groovy)
> at sun.reflect.GeneratedMethodAccessor38.invoke(Unknown Source)
> at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:498)
> at
> org.codehaus.groovy.reflection.CachedMethod.invoke(CachedMethod.java:93)
> at groovy.lang.MetaMethod.doMethodInvoke(MetaMethod.java:325)
> at groovy.lang.MetaClassImpl.invokeMethod(MetaClassImpl.java:1215)
> at
> org.codehaus.groovy.runtime.ScriptBytecodeAdapter.invokeMethodOnSuperN(ScriptBytecodeAdapter.java:132)
> at
> org.codehaus.groovy.runtime.ScriptBytecodeAdapter.invokeMethodOnSuper0(ScriptBytecodeAdapter.java:152)
> at
> org.codehaus.groovy.tools.shell.InteractiveShellRunner.work(InteractiveShellRunner.groovy:124)
> at org.codehaus.groovy.tools.shell
[GitHub] tinkerpop issue #481: TINKERPOP-1428: profile() throws NPE for union(group, ...
Github user spmallette commented on the issue: https://github.com/apache/tinkerpop/pull/481 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. ---
