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

[dkuppitz]

Github user dkuppitz 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-1508) Add choose(predicate,trueTraversal)

[ASF GitHub Bot (JIRA)]

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

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

Github user dkuppitz 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)

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

[ASF GitHub Bot (JIRA)]

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

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

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

https://github.com/apache/tinkerpop/pull/472#discussion_r85862272
  
--- Diff: 
gremlin-core/src/test/java/org/apache/tinkerpop/gremlin/process/traversal/step/branch/ChooseStepTest.java
 ---
@@ -38,7 +42,10 @@
 return Arrays.asList(
 __.choose(values("name")).option("marko", 
out()).option(none, in()),
 __.choose(values("name")).option("marko", 
in()).option(none, out()),
-__.choose(values("name")).option("josh", 
out()).option(none, in())
+__.choose(values("name")).option("josh", 
out()).option(none, in()),
+__.choose(out("knows").is(P.gt(0)), out("knows"), 
out("knows")),
+__.choose(out("knows").is(P.gt(0)), out("knows"), 
out("created")),
+__.choose(out("knows").is(P.gt(0)), out("knows"))
--- End diff --

Yea, I meant `count()`. I can add it before merge.


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

[okram]

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

https://github.com/apache/tinkerpop/pull/472#discussion_r85862272
  
--- Diff: 
gremlin-core/src/test/java/org/apache/tinkerpop/gremlin/process/traversal/step/branch/ChooseStepTest.java
 ---
@@ -38,7 +42,10 @@
 return Arrays.asList(
 __.choose(values("name")).option("marko", 
out()).option(none, in()),
 __.choose(values("name")).option("marko", 
in()).option(none, out()),
-__.choose(values("name")).option("josh", 
out()).option(none, in())
+__.choose(values("name")).option("josh", 
out()).option(none, in()),
+__.choose(out("knows").is(P.gt(0)), out("knows"), 
out("knows")),
+__.choose(out("knows").is(P.gt(0)), out("knows"), 
out("created")),
+__.choose(out("knows").is(P.gt(0)), out("knows"))
--- End diff --

Yea, I meant `count()`. I can add it 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] [Closed] (TINKERPOP-1424) PathRetractionStrategy can easily break VertexPrograms

[Daniel Kuppitz (JIRA)]

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

Daniel Kuppitz closed TINKERPOP-1424.
-
Resolution: Duplicate

> PathRetractionStrategy can easily break VertexPrograms
> --
>
> Key: TINKERPOP-1424
> URL: https://issues.apache.org/jira/browse/TINKERPOP-1424
> Project: TinkerPop
>  Issue Type: Bug
>  Components: process
>Affects Versions: 3.2.1
>Reporter: Daniel Kuppitz
>
> I just ran into an issue where I had to remove {{PathRetractionStrategy}} 
> from the traversal strategies. The traversal was something like this:
> {code}
> g.V().out().as("a").out().program(myVertexProgram)
> {code}
> ..and {{myVertexProgram}} tried to access the path label "a". This doesn't 
> work if {{PathRetractionStrategy}} is used.
> I think we need to extend VertexPrograms, like in TINKERPOP-1280. If a 
> VertexProgram has a {{LABELED_PATH}} requirement, it should also provide 
> information about which labels it needs access to.



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

[jira] [Commented] (TINKERPOP-1424) PathRetractionStrategy can easily break VertexPrograms

[Daniel Kuppitz (JIRA)]

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

Daniel Kuppitz commented on TINKERPOP-1424:
---

No, this is not longer an issue. The problem from the description was actually 
implemented as a test case in TINKERPOP-1280's PR: 
https://github.com/apache/tinkerpop/pull/404/files#diff-1ae539eeb6f0cc23749ee7b6c4bee881R2351

> PathRetractionStrategy can easily break VertexPrograms
> --
>
> Key: TINKERPOP-1424
> URL: https://issues.apache.org/jira/browse/TINKERPOP-1424
> Project: TinkerPop
>  Issue Type: Bug
>  Components: process
>Affects Versions: 3.2.1
>Reporter: Daniel Kuppitz
>
> I just ran into an issue where I had to remove {{PathRetractionStrategy}} 
> from the traversal strategies. The traversal was something like this:
> {code}
> g.V().out().as("a").out().program(myVertexProgram)
> {code}
> ..and {{myVertexProgram}} tried to access the path label "a". This doesn't 
> work if {{PathRetractionStrategy}} is used.
> I think we need to extend VertexPrograms, like in TINKERPOP-1280. If a 
> VertexProgram has a {{LABELED_PATH}} requirement, it should also provide 
> information about which labels it needs access to.



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

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

[ASF GitHub Bot (JIRA)]

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

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

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

https://github.com/apache/tinkerpop/pull/472#discussion_r85858468
  
--- Diff: 
gremlin-core/src/test/java/org/apache/tinkerpop/gremlin/process/traversal/step/branch/ChooseStepTest.java
 ---
@@ -38,7 +42,10 @@
 return Arrays.asList(
 __.choose(values("name")).option("marko", 
out()).option(none, in()),
 __.choose(values("name")).option("marko", 
in()).option(none, out()),
-__.choose(values("name")).option("josh", 
out()).option(none, in())
+__.choose(values("name")).option("josh", 
out()).option(none, in()),
+__.choose(out("knows").is(P.gt(0)), out("knows"), 
out("knows")),
+__.choose(out("knows").is(P.gt(0)), out("knows"), 
out("created")),
+__.choose(out("knows").is(P.gt(0)), out("knows"))
--- End diff --

It's pretty irrelevant for these tests, but `out("knows").is(gt(0))` makes 
no sense at all. Was it meant to be `out("knows").count().is(gt(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
>
> {{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...

[dkuppitz]

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

https://github.com/apache/tinkerpop/pull/472#discussion_r85858468
  
--- Diff: 
gremlin-core/src/test/java/org/apache/tinkerpop/gremlin/process/traversal/step/branch/ChooseStepTest.java
 ---
@@ -38,7 +42,10 @@
 return Arrays.asList(
 __.choose(values("name")).option("marko", 
out()).option(none, in()),
 __.choose(values("name")).option("marko", 
in()).option(none, out()),
-__.choose(values("name")).option("josh", 
out()).option(none, in())
+__.choose(values("name")).option("josh", 
out()).option(none, in()),
+__.choose(out("knows").is(P.gt(0)), out("knows"), 
out("knows")),
+__.choose(out("knows").is(P.gt(0)), out("knows"), 
out("created")),
+__.choose(out("knows").is(P.gt(0)), out("knows"))
--- End diff --

It's pretty irrelevant for these tests, but `out("knows").is(gt(0))` makes 
no sense at all. Was it meant to be `out("knows").count().is(gt(0))`?


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

[ASF GitHub Bot (JIRA)]

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

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

Github user dkuppitz commented on the issue:

https://github.com/apache/tinkerpop/pull/471
  
I've done some manual tests.

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

[dkuppitz]

Github user dkuppitz commented on the issue:

https://github.com/apache/tinkerpop/pull/471
  
I've done some manual tests.

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

[ASF GitHub Bot (JIRA)]

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

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

Github user okram commented on the issue:

https://github.com/apache/tinkerpop/pull/469
  
I ran the test suite and I no longer see GremlinServer INFO stuff during 
SparkGremlin test suite evaluation. Thus, VOTE +1.


> 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 issue #469: TINKERPOP-1534 Improve GraphProvider ability to releas...

[okram]

Github user okram commented on the issue:

https://github.com/apache/tinkerpop/pull/469
  
I ran the test suite and I no longer see GremlinServer INFO stuff during 
SparkGremlin test suite evaluation. Thus, 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-1534) Gremlin Server instances leaking in tests

[ASF GitHub Bot (JIRA)]

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

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

Github user twilmes commented on the issue:

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


> 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 issue #469: TINKERPOP-1534 Improve GraphProvider ability to releas...

[twilmes]

Github user twilmes commented on the issue:

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

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on TINKERPOP-887:
--

Github user okram commented on the issue:

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

[okram]

Github user okram commented on the issue:

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

[BrynCooke]

Github user BrynCooke commented on the issue:

https://github.com/apache/tinkerpop/pull/470
  
Yes, that's it.


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

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on TINKERPOP-887:
--

Github user BrynCooke commented on the issue:

https://github.com/apache/tinkerpop/pull/470
  
Yes, that's it.


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

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on TINKERPOP-887:
--

Github user okram commented on the issue:

https://github.com/apache/tinkerpop/pull/470
  
And for my own education -- this is to show only WHICH traversal "failed," 
not where in the traversal it failed? Thus, its more about many traversals in 
an application and knowing which traversal is "bad" ? Correct?


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

[okram]

Github user okram commented on the issue:

https://github.com/apache/tinkerpop/pull/470
  
And for my own education -- this is to show only WHICH traversal "failed," 
not where in the traversal it failed? Thus, its more about many traversals in 
an application and knowing which traversal is "bad" ? Correct?


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

[ASF GitHub Bot (JIRA)]

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

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

GitHub user okram opened a pull request:

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

TINKERPOP-1508: Add choose(predicate,trueTraversal)

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

Added `GraphTraversal.choose(predicate,traversal)` and 
`GraphTraversal.choose(traversal,traversal)`. These are implemented as 
`choose(traversal,identity())`. Up to this point, `choose()` has been 
if/then/else-semantics and now with addition, we have if/then-semantics.

VOTE +1

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

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

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

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


commit 659865bdb1a5e2db9e01847eb641101cab3d090a
Author: Marko A. Rodriguez 
Date:   2016-10-31T19:23:42Z

added choose(predicate,traversal) which is a map to 
choose(predicate,traversal,identity()) and gives us if/then-semantics instead 
of always requiring if/then/else-semantics.




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

[okram]

GitHub user okram opened a pull request:

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

TINKERPOP-1508: Add choose(predicate,trueTraversal)

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

Added `GraphTraversal.choose(predicate,traversal)` and 
`GraphTraversal.choose(traversal,traversal)`. These are implemented as 
`choose(traversal,identity())`. Up to this point, `choose()` has been 
if/then/else-semantics and now with addition, we have if/then-semantics.

VOTE +1

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

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

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

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


commit 659865bdb1a5e2db9e01847eb641101cab3d090a
Author: Marko A. Rodriguez 
Date:   2016-10-31T19:23:42Z

added choose(predicate,traversal) which is a map to 
choose(predicate,traversal,identity()) and gives us if/then-semantics instead 
of always requiring if/then/else-semantics.




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

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on TINKERPOP-887:
--

Github user BrynCooke commented on the issue:

https://github.com/apache/tinkerpop/pull/470
  
Exactly. It's currently a huge pain to figure out where things have gone 
wrong. Without this patch I have to divide and conquer my code every time I hit 
a FastNoSuchElementException.

There is no cost to a try/catch block. The construction of the regular 
NoSuchElementException is expensive, but should only be thrown on the top level 
traversal.

I actually found no significant difference between branches in terms of 
performance.

Mine
```
gremlin> graph = TinkerGraph.open()
==>tinkergraph[vertices:0 edges:0]
gremlin> graph.io(gryo()).readGraph('data/grateful-dead.kryo')
==>null
gremlin> h = graph.traversal()
==>graphtraversalsource[tinkergraph[vertices:808 edges:8049], standard]
gremlin> g = graph.traversal().withoutStrategies(LazyBarrierStrategy.class)
==>graphtraversalsource[tinkergraph[vertices:808 edges:8049], standard]
gremlin> clock(100){ h.V().out().out().out().toSet() }
==>3.33155785
gremlin> clock(20){ g.V().out().out().out().toSet() }
==>520.272772449
gremlin> clock(20){ g.V().out().flatMap(out()).flatMap(out()).toSet() }
==>903.525418999
gremlin> clock(100){ g.V().repeat(out()).times(3).toSet() }
==>1.83920066
gremlin> clock(100){ h.V().count() }
==>0.0069826
gremlin> 
```

Master
```
gremlin> graph = TinkerGraph.open()
==>tinkergraph[vertices:0 edges:0]
gremlin> graph.io(gryo()).readGraph('data/grateful-dead.kryo')
==>null
gremlin> h = graph.traversal()
==>graphtraversalsource[tinkergraph[vertices:808 edges:8049], standard]
gremlin> g = graph.traversal().withoutStrategies(LazyBarrierStrategy.class)
==>graphtraversalsource[tinkergraph[vertices:808 edges:8049], standard]
gremlin> clock(100){ h.V().out().out().out().toSet() }
==>3.59260972
gremlin> clock(20){ g.V().out().out().out().toSet() }
==>519.7500263
gremlin> clock(20){ g.V().out().flatMap(out()).flatMap(out()).toSet() }
==>907.32923195
gremlin> clock(100){ g.V().repeat(out()).times(3).toSet() }
==>1.76869779
gremlin> clock(100){ h.V().count() }
==>0.0069853699
gremlin> 
```



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

[BrynCooke]

Github user BrynCooke commented on the issue:

https://github.com/apache/tinkerpop/pull/470
  
Exactly. It's currently a huge pain to figure out where things have gone 
wrong. Without this patch I have to divide and conquer my code every time I hit 
a FastNoSuchElementException.

There is no cost to a try/catch block. The construction of the regular 
NoSuchElementException is expensive, but should only be thrown on the top level 
traversal.

I actually found no significant difference between branches in terms of 
performance.

Mine
```
gremlin> graph = TinkerGraph.open()
==>tinkergraph[vertices:0 edges:0]
gremlin> graph.io(gryo()).readGraph('data/grateful-dead.kryo')
==>null
gremlin> h = graph.traversal()
==>graphtraversalsource[tinkergraph[vertices:808 edges:8049], standard]
gremlin> g = graph.traversal().withoutStrategies(LazyBarrierStrategy.class)
==>graphtraversalsource[tinkergraph[vertices:808 edges:8049], standard]
gremlin> clock(100){ h.V().out().out().out().toSet() }
==>3.33155785
gremlin> clock(20){ g.V().out().out().out().toSet() }
==>520.272772449
gremlin> clock(20){ g.V().out().flatMap(out()).flatMap(out()).toSet() }
==>903.525418999
gremlin> clock(100){ g.V().repeat(out()).times(3).toSet() }
==>1.83920066
gremlin> clock(100){ h.V().count() }
==>0.0069826
gremlin> 
```

Master
```
gremlin> graph = TinkerGraph.open()
==>tinkergraph[vertices:0 edges:0]
gremlin> graph.io(gryo()).readGraph('data/grateful-dead.kryo')
==>null
gremlin> h = graph.traversal()
==>graphtraversalsource[tinkergraph[vertices:808 edges:8049], standard]
gremlin> g = graph.traversal().withoutStrategies(LazyBarrierStrategy.class)
==>graphtraversalsource[tinkergraph[vertices:808 edges:8049], standard]
gremlin> clock(100){ h.V().out().out().out().toSet() }
==>3.59260972
gremlin> clock(20){ g.V().out().out().out().toSet() }
==>519.7500263
gremlin> clock(20){ g.V().out().flatMap(out()).flatMap(out()).toSet() }
==>907.32923195
gremlin> clock(100){ g.V().repeat(out()).times(3).toSet() }
==>1.76869779
gremlin> clock(100){ h.V().count() }
==>0.0069853699
gremlin> 
```



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

[ASF GitHub Bot (JIRA)]

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

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

GitHub user okram opened a pull request:

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

TINKERPOP-1506: Optional/Coalesce should not allow sideEffect traversals.

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

`g.V(1).optional(addV())` created 2 vertices, not one. This is because 
`optional()` was implemented with the branch-step `ChooseStep`. This has been 
fixed with a custom `OptionalStep`. Test cases added to verify correct behavior.

Added to `master/` as this is a breaking change. Though, the previous 
behavior can easily be deemed a bug.

VOTE +1.

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

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

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

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


commit 40971c95903077d38cb754843eb914b5548f5c1f
Author: Marko A. Rodriguez 
Date:   2016-10-31T18:03:33Z

added OptionalStep to be used instead of optional() being backed by 
ChooseStep. This fixes a side-effect issue.




> 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 pull request #471: TINKERPOP-1506: Optional/Coalesce should not al...

[okram]

GitHub user okram opened a pull request:

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

TINKERPOP-1506: Optional/Coalesce should not allow sideEffect traversals.

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

`g.V(1).optional(addV())` created 2 vertices, not one. This is because 
`optional()` was implemented with the branch-step `ChooseStep`. This has been 
fixed with a custom `OptionalStep`. Test cases added to verify correct behavior.

Added to `master/` as this is a breaking change. Though, the previous 
behavior can easily be deemed a bug.

VOTE +1.

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

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

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

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


commit 40971c95903077d38cb754843eb914b5548f5c1f
Author: Marko A. Rodriguez 
Date:   2016-10-31T18:03:33Z

added OptionalStep to be used instead of optional() being backed by 
ChooseStep. This fixes a side-effect issue.




---
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-1525) Plug VertexProgram iteration leak on empty Spark RDD partitions

[stephen mallette (JIRA)]

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

stephen mallette closed TINKERPOP-1525.
---
   Resolution: Fixed
Fix Version/s: (was: 3.3.0)

> Plug VertexProgram iteration leak on empty Spark RDD partitions
> ---
>
> Key: TINKERPOP-1525
> URL: https://issues.apache.org/jira/browse/TINKERPOP-1525
> Project: TinkerPop
>  Issue Type: Bug
>  Components: hadoop
>Affects Versions: 3.2.3
>Reporter: Dan LaRocque
> Fix For: 3.2.4
>
>
> If SparkExecutor gets an RDD with empty partitions, it can invoke 
> {{VertexProgram.workerIterationStart}} without ever invoking 
> {{VertexProgram.workerIterationEnd}}.
> For vertex programs that allocate and release meaningful resources in the 
> start/end methods, this can lead to resource leaks.
> I already tested a fix that I made against the 3.2 series.  I will submit PRs 
> momentarily.



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

[jira] [Commented] (TINKERPOP-1424) PathRetractionStrategy can easily break VertexPrograms

[Marko A. Rodriguez (JIRA)]

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

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

Is this still an issue now that we have {{TINKERPOP-1280}} implemented? 

> PathRetractionStrategy can easily break VertexPrograms
> --
>
> Key: TINKERPOP-1424
> URL: https://issues.apache.org/jira/browse/TINKERPOP-1424
> Project: TinkerPop
>  Issue Type: Bug
>  Components: process
>Affects Versions: 3.2.1
>Reporter: Daniel Kuppitz
>
> I just ran into an issue where I had to remove {{PathRetractionStrategy}} 
> from the traversal strategies. The traversal was something like this:
> {code}
> g.V().out().as("a").out().program(myVertexProgram)
> {code}
> ..and {{myVertexProgram}} tried to access the path label "a". This doesn't 
> work if {{PathRetractionStrategy}} is used.
> I think we need to extend VertexPrograms, like in TINKERPOP-1280. If a 
> VertexProgram has a {{LABELED_PATH}} requirement, it should also provide 
> information about which labels it needs access to.



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

[jira] [Closed] (TINKERPOP-1480) PathRestractionStrategy shouldn't NoOpBarrierStep if it will be the end step.

[Marko A. Rodriguez (JIRA)]

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

Marko A. Rodriguez closed TINKERPOP-1480.
-
Resolution: Won't Fix
  Assignee: Marko A. Rodriguez

> PathRestractionStrategy shouldn't NoOpBarrierStep if it will be the end step.
> -
>
> Key: TINKERPOP-1480
> URL: https://issues.apache.org/jira/browse/TINKERPOP-1480
> Project: TinkerPop
>  Issue Type: Improvement
>  Components: process
>Affects Versions: 3.2.2
>Reporter: Marko A. Rodriguez
>Assignee: Marko A. Rodriguez
>
> {code}
> gremlin> 
> g.V().filter(has('name','marko')).match(__.as('a').has('age',32),__.as('a').out('knows').as('b')).where('a',neq('b')).select('a').by('name').explain()
> ==>Traversal Explanation
> ==
> Original Traversal [GraphStep(vertex,[]), 
> TraversalFilterStep([HasStep([name.eq(marko)])]), 
> MatchStep(AND,[[MatchStartStep(a), HasStep([age.eq(32)]), MatchEndStep], 
> [MatchStartStep(a), VertexStep(OUT,[knows],vertex), MatchEndStep(b)]]), 
> WherePredicateStep(a,neq(b)), SelectOneStep(a,value(name))]
> ConnectiveStrategy   [D]   [GraphStep(vertex,[]), 
> TraversalFilterStep([HasStep([name.eq(marko)])]), 
> MatchStep(AND,[[MatchStartStep(a), HasStep([age.eq(32)]), MatchEndStep], 
> [MatchStartStep(a), VertexStep(OUT,[knows],vertex), MatchEndStep(b)]]), 
> WherePredicateStep(a,neq(b)), SelectOneStep(a,value(name))]
> IncidentToAdjacentStrategy   [O]   [GraphStep(vertex,[]), 
> TraversalFilterStep([HasStep([name.eq(marko)])]), 
> MatchStep(AND,[[MatchStartStep(a), HasStep([age.eq(32)]), MatchEndStep], 
> [MatchStartStep(a), VertexStep(OUT,[knows],vertex), MatchEndStep(b)]]), 
> WherePredicateStep(a,neq(b)), SelectOneStep(a,value(name))]
> AdjacentToIncidentStrategy   [O]   [GraphStep(vertex,[]), 
> TraversalFilterStep([HasStep([name.eq(marko)])]), 
> MatchStep(AND,[[MatchStartStep(a), HasStep([age.eq(32)]), MatchEndStep], 
> [MatchStartStep(a), VertexStep(OUT,[knows],vertex), MatchEndStep(b)]]), 
> WherePredicateStep(a,neq(b)), SelectOneStep(a,value(name))]
> InlineFilterStrategy [O]   [GraphStep(vertex,[]), 
> HasStep([name.eq(marko)])@[a], HasStep([age.eq(32)]), 
> MatchStep(AND,[[MatchStartStep(a), VertexStep(OUT,[knows],vertex), 
> MatchEndStep(b)]]), WherePredicateStep(a,neq(b)), 
> SelectOneStep(a,value(name))]
> MatchPredicateStrategy   [O]   [GraphStep(vertex,[]), 
> HasStep([name.eq(marko)])@[a], HasStep([age.eq(32)]), 
> MatchStep(AND,[[MatchStartStep(a), VertexStep(OUT,[knows],vertex), 
> MatchEndStep(b)], [MatchStartStep(a), WherePredicateStep(neq(b)), 
> MatchEndStep]]), SelectOneStep(a,value(name))]
> FilterRankingStrategy[O]   [GraphStep(vertex,[]), 
> HasStep([name.eq(marko)])@[a], HasStep([age.eq(32)]), 
> MatchStep(AND,[[MatchStartStep(a), VertexStep(OUT,[knows],vertex), 
> MatchEndStep(b)], [MatchStartStep(a), WherePredicateStep(neq(b)), 
> MatchEndStep]]), SelectOneStep(a,value(name))]
> RepeatUnrollStrategy [O]   [GraphStep(vertex,[]), 
> HasStep([name.eq(marko)])@[a], HasStep([age.eq(32)]), 
> MatchStep(AND,[[MatchStartStep(a), VertexStep(OUT,[knows],vertex), 
> MatchEndStep(b)], [MatchStartStep(a), WherePredicateStep(neq(b)), 
> MatchEndStep]]), SelectOneStep(a,value(name))]
> RangeByIsCountStrategy   [O]   [GraphStep(vertex,[]), 
> HasStep([name.eq(marko)])@[a], HasStep([age.eq(32)]), 
> MatchStep(AND,[[MatchStartStep(a), VertexStep(OUT,[knows],vertex), 
> MatchEndStep(b)], [MatchStartStep(a), WherePredicateStep(neq(b)), 
> MatchEndStep]]), SelectOneStep(a,value(name))]
> PathRetractionStrategy   [O]   [GraphStep(vertex,[]), 
> HasStep([name.eq(marko)])@[a], HasStep([age.eq(32)]), 
> MatchStep(AND,[[MatchStartStep(a), VertexStep(OUT,[knows],vertex), 
> MatchEndStep(b)], [MatchStartStep(a), WherePredicateStep(neq(b)), 
> MatchEndStep]]), SelectOneStep(a,value(name)), NoOpBarrierStep(2500)]
> TinkerGraphStepStrategy  [P]   [TinkerGraphStep(vertex,[name.eq(marko), 
> age.eq(32)])@[a], MatchStep(AND,[[MatchStartStep(a), 
> VertexStep(OUT,[knows],vertex), MatchEndStep(b)], [MatchStartStep(a), 
> WherePredicateStep(neq(b)), MatchEndStep]]), SelectOneStep(a,value(name)), 
> NoOpBarrierStep(2500)]
> ProfileStrategy  [F]   [TinkerGraphStep(vertex,[name.eq(marko), 
> age.eq(32)])@[a], MatchStep(AND,[[MatchStartStep(a), 
> VertexStep(OUT,[knows],vertex), MatchEndStep(b)], [MatchStartStep(a), 
> WherePredicateStep(neq(b)), MatchEndStep]]), 

[jira] [Reopened] (TINKERPOP-1527) Do not override registered strategies in TraversalStrategies.GlobalCache

[stephen mallette (JIRA)]

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

stephen mallette reopened TINKERPOP-1527:
-

> Do not override registered strategies in TraversalStrategies.GlobalCache
> 
>
> Key: TINKERPOP-1527
> URL: https://issues.apache.org/jira/browse/TINKERPOP-1527
> Project: TinkerPop
>  Issue Type: Improvement
>  Components: process
>Affects Versions: 3.2.3
>Reporter: Marko A. Rodriguez
>Assignee: Marko A. Rodriguez
> Fix For: 3.2.4
>
>
> This may be a non-issue (need to check), but we currently do this in every 
> {{Graph}} (and {{GraphComputer}}) class.
> {code}
> static {
> TraversalStrategies.GlobalCache.registerStrategies(TinkerGraph.class, 
> TraversalStrategies.GlobalCache.getStrategies(Graph.class).clone().addStrategies(TinkerGraphStepStrategy.instance()));
> }
> {code}
> If this static code is loaded every time a {{Graph}} instance is created, 
> then manually tweaked strategy registrations get overwritten. If this is the 
> case, then we should do:
> {code}
> static {
> 
> TraversalStrategies.GlobalCache.registerStrategiesIfNotPresent(TinkerGraph.class,TraversalStrategies.GlobalCache.getStrategies(Graph.class).clone().addStrategies(TinkerGraphStepStrategy.instance()));
> }
> {code}
> That is, add a {{registerIfNotPresent()}} method.



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

[jira] [Reopened] (TINKERPOP-1525) Plug VertexProgram iteration leak on empty Spark RDD partitions

[stephen mallette (JIRA)]

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

stephen mallette reopened TINKERPOP-1525:
-

> Plug VertexProgram iteration leak on empty Spark RDD partitions
> ---
>
> Key: TINKERPOP-1525
> URL: https://issues.apache.org/jira/browse/TINKERPOP-1525
> Project: TinkerPop
>  Issue Type: Bug
>  Components: hadoop
>Affects Versions: 3.2.3
>Reporter: Dan LaRocque
> Fix For: 3.2.4
>
>
> If SparkExecutor gets an RDD with empty partitions, it can invoke 
> {{VertexProgram.workerIterationStart}} without ever invoking 
> {{VertexProgram.workerIterationEnd}}.
> For vertex programs that allocate and release meaningful resources in the 
> start/end methods, this can lead to resource leaks.
> I already tested a fix that I made against the 3.2 series.  I will submit PRs 
> momentarily.



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

[jira] [Commented] (TINKERPOP-1480) PathRestractionStrategy shouldn't NoOpBarrierStep if it will be the end step.

[Marko A. Rodriguez (JIRA)]

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

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

Given the discussion, we should keep {{PathRetractionStrategy}} barriers as 
they are. Thus, closing this issue with a "won't fix."

> PathRestractionStrategy shouldn't NoOpBarrierStep if it will be the end step.
> -
>
> Key: TINKERPOP-1480
> URL: https://issues.apache.org/jira/browse/TINKERPOP-1480
> Project: TinkerPop
>  Issue Type: Improvement
>  Components: process
>Affects Versions: 3.2.2
>Reporter: Marko A. Rodriguez
>
> {code}
> gremlin> 
> g.V().filter(has('name','marko')).match(__.as('a').has('age',32),__.as('a').out('knows').as('b')).where('a',neq('b')).select('a').by('name').explain()
> ==>Traversal Explanation
> ==
> Original Traversal [GraphStep(vertex,[]), 
> TraversalFilterStep([HasStep([name.eq(marko)])]), 
> MatchStep(AND,[[MatchStartStep(a), HasStep([age.eq(32)]), MatchEndStep], 
> [MatchStartStep(a), VertexStep(OUT,[knows],vertex), MatchEndStep(b)]]), 
> WherePredicateStep(a,neq(b)), SelectOneStep(a,value(name))]
> ConnectiveStrategy   [D]   [GraphStep(vertex,[]), 
> TraversalFilterStep([HasStep([name.eq(marko)])]), 
> MatchStep(AND,[[MatchStartStep(a), HasStep([age.eq(32)]), MatchEndStep], 
> [MatchStartStep(a), VertexStep(OUT,[knows],vertex), MatchEndStep(b)]]), 
> WherePredicateStep(a,neq(b)), SelectOneStep(a,value(name))]
> IncidentToAdjacentStrategy   [O]   [GraphStep(vertex,[]), 
> TraversalFilterStep([HasStep([name.eq(marko)])]), 
> MatchStep(AND,[[MatchStartStep(a), HasStep([age.eq(32)]), MatchEndStep], 
> [MatchStartStep(a), VertexStep(OUT,[knows],vertex), MatchEndStep(b)]]), 
> WherePredicateStep(a,neq(b)), SelectOneStep(a,value(name))]
> AdjacentToIncidentStrategy   [O]   [GraphStep(vertex,[]), 
> TraversalFilterStep([HasStep([name.eq(marko)])]), 
> MatchStep(AND,[[MatchStartStep(a), HasStep([age.eq(32)]), MatchEndStep], 
> [MatchStartStep(a), VertexStep(OUT,[knows],vertex), MatchEndStep(b)]]), 
> WherePredicateStep(a,neq(b)), SelectOneStep(a,value(name))]
> InlineFilterStrategy [O]   [GraphStep(vertex,[]), 
> HasStep([name.eq(marko)])@[a], HasStep([age.eq(32)]), 
> MatchStep(AND,[[MatchStartStep(a), VertexStep(OUT,[knows],vertex), 
> MatchEndStep(b)]]), WherePredicateStep(a,neq(b)), 
> SelectOneStep(a,value(name))]
> MatchPredicateStrategy   [O]   [GraphStep(vertex,[]), 
> HasStep([name.eq(marko)])@[a], HasStep([age.eq(32)]), 
> MatchStep(AND,[[MatchStartStep(a), VertexStep(OUT,[knows],vertex), 
> MatchEndStep(b)], [MatchStartStep(a), WherePredicateStep(neq(b)), 
> MatchEndStep]]), SelectOneStep(a,value(name))]
> FilterRankingStrategy[O]   [GraphStep(vertex,[]), 
> HasStep([name.eq(marko)])@[a], HasStep([age.eq(32)]), 
> MatchStep(AND,[[MatchStartStep(a), VertexStep(OUT,[knows],vertex), 
> MatchEndStep(b)], [MatchStartStep(a), WherePredicateStep(neq(b)), 
> MatchEndStep]]), SelectOneStep(a,value(name))]
> RepeatUnrollStrategy [O]   [GraphStep(vertex,[]), 
> HasStep([name.eq(marko)])@[a], HasStep([age.eq(32)]), 
> MatchStep(AND,[[MatchStartStep(a), VertexStep(OUT,[knows],vertex), 
> MatchEndStep(b)], [MatchStartStep(a), WherePredicateStep(neq(b)), 
> MatchEndStep]]), SelectOneStep(a,value(name))]
> RangeByIsCountStrategy   [O]   [GraphStep(vertex,[]), 
> HasStep([name.eq(marko)])@[a], HasStep([age.eq(32)]), 
> MatchStep(AND,[[MatchStartStep(a), VertexStep(OUT,[knows],vertex), 
> MatchEndStep(b)], [MatchStartStep(a), WherePredicateStep(neq(b)), 
> MatchEndStep]]), SelectOneStep(a,value(name))]
> PathRetractionStrategy   [O]   [GraphStep(vertex,[]), 
> HasStep([name.eq(marko)])@[a], HasStep([age.eq(32)]), 
> MatchStep(AND,[[MatchStartStep(a), VertexStep(OUT,[knows],vertex), 
> MatchEndStep(b)], [MatchStartStep(a), WherePredicateStep(neq(b)), 
> MatchEndStep]]), SelectOneStep(a,value(name)), NoOpBarrierStep(2500)]
> TinkerGraphStepStrategy  [P]   [TinkerGraphStep(vertex,[name.eq(marko), 
> age.eq(32)])@[a], MatchStep(AND,[[MatchStartStep(a), 
> VertexStep(OUT,[knows],vertex), MatchEndStep(b)], [MatchStartStep(a), 
> WherePredicateStep(neq(b)), MatchEndStep]]), SelectOneStep(a,value(name)), 
> NoOpBarrierStep(2500)]
> ProfileStrategy  [F]   [TinkerGraphStep(vertex,[name.eq(marko), 
> age.eq(32)])@[a], MatchStep(AND,[[MatchStartStep(a), 
> VertexStep(OUT,[knows],vertex), MatchEndStep(b)], 

[jira] [Created] (TINKERPOP-1535) Bump to support Giraph 1.2.0.

[Marko A. Rodriguez (JIRA)]

Marko A. Rodriguez created TINKERPOP-1535:
-

 Summary: Bump to support Giraph 1.2.0.
 Key: TINKERPOP-1535
 URL: https://issues.apache.org/jira/browse/TINKERPOP-1535
 Project: TinkerPop
  Issue Type: Improvement
  Components: hadoop
Affects Versions: 3.2.3
Reporter: Marko A. Rodriguez
 Fix For: 3.3.0






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

[jira] [Closed] (TINKERPOP-1527) Do not override registered strategies in TraversalStrategies.GlobalCache

[stephen mallette (JIRA)]

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

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

removed 3.3.0 as the "fix" version or else it will cause trouble when 
generating release notes. not sure if this is something that will be a concern 
at some point in the future. like we fix something in 3.2.x that doesnt' go 
forward to 3.3.x for some reason. oh well. guess we'll worry about that when it 
happens.

> Do not override registered strategies in TraversalStrategies.GlobalCache
> 
>
> Key: TINKERPOP-1527
> URL: https://issues.apache.org/jira/browse/TINKERPOP-1527
> Project: TinkerPop
>  Issue Type: Improvement
>  Components: process
>Affects Versions: 3.2.3
>Reporter: Marko A. Rodriguez
>Assignee: Marko A. Rodriguez
> Fix For: 3.2.4
>
>
> This may be a non-issue (need to check), but we currently do this in every 
> {{Graph}} (and {{GraphComputer}}) class.
> {code}
> static {
> TraversalStrategies.GlobalCache.registerStrategies(TinkerGraph.class, 
> TraversalStrategies.GlobalCache.getStrategies(Graph.class).clone().addStrategies(TinkerGraphStepStrategy.instance()));
> }
> {code}
> If this static code is loaded every time a {{Graph}} instance is created, 
> then manually tweaked strategy registrations get overwritten. If this is the 
> case, then we should do:
> {code}
> static {
> 
> TraversalStrategies.GlobalCache.registerStrategiesIfNotPresent(TinkerGraph.class,TraversalStrategies.GlobalCache.getStrategies(Graph.class).clone().addStrategies(TinkerGraphStepStrategy.instance()));
> }
> {code}
> That is, add a {{registerIfNotPresent()}} method.



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

[jira] [Updated] (TINKERPOP-1527) Do not override registered strategies in TraversalStrategies.GlobalCache

[stephen mallette (JIRA)]

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

stephen mallette updated TINKERPOP-1527:

Fix Version/s: (was: 3.3.0)

> Do not override registered strategies in TraversalStrategies.GlobalCache
> 
>
> Key: TINKERPOP-1527
> URL: https://issues.apache.org/jira/browse/TINKERPOP-1527
> Project: TinkerPop
>  Issue Type: Improvement
>  Components: process
>Affects Versions: 3.2.3
>Reporter: Marko A. Rodriguez
>Assignee: Marko A. Rodriguez
> Fix For: 3.2.4
>
>
> This may be a non-issue (need to check), but we currently do this in every 
> {{Graph}} (and {{GraphComputer}}) class.
> {code}
> static {
> TraversalStrategies.GlobalCache.registerStrategies(TinkerGraph.class, 
> TraversalStrategies.GlobalCache.getStrategies(Graph.class).clone().addStrategies(TinkerGraphStepStrategy.instance()));
> }
> {code}
> If this static code is loaded every time a {{Graph}} instance is created, 
> then manually tweaked strategy registrations get overwritten. If this is the 
> case, then we should do:
> {code}
> static {
> 
> TraversalStrategies.GlobalCache.registerStrategiesIfNotPresent(TinkerGraph.class,TraversalStrategies.GlobalCache.getStrategies(Graph.class).clone().addStrategies(TinkerGraphStepStrategy.instance()));
> }
> {code}
> That is, add a {{registerIfNotPresent()}} method.



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

[jira] [Closed] (TINKERPOP-1525) Plug VertexProgram iteration leak on empty Spark RDD partitions

[Marko A. Rodriguez (JIRA)]

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

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

> Plug VertexProgram iteration leak on empty Spark RDD partitions
> ---
>
> Key: TINKERPOP-1525
> URL: https://issues.apache.org/jira/browse/TINKERPOP-1525
> Project: TinkerPop
>  Issue Type: Bug
>  Components: hadoop
>Affects Versions: 3.2.3
>Reporter: Dan LaRocque
> Fix For: 3.3.0, 3.2.4
>
>
> If SparkExecutor gets an RDD with empty partitions, it can invoke 
> {{VertexProgram.workerIterationStart}} without ever invoking 
> {{VertexProgram.workerIterationEnd}}.
> For vertex programs that allocate and release meaningful resources in the 
> start/end methods, this can lead to resource leaks.
> I already tested a fix that I made against the 3.2 series.  I will submit PRs 
> momentarily.



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

[jira] [Closed] (TINKERPOP-1527) Do not override registered strategies in TraversalStrategies.GlobalCache

[Marko A. Rodriguez (JIRA)]

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

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

> Do not override registered strategies in TraversalStrategies.GlobalCache
> 
>
> Key: TINKERPOP-1527
> URL: https://issues.apache.org/jira/browse/TINKERPOP-1527
> Project: TinkerPop
>  Issue Type: Improvement
>  Components: process
>Affects Versions: 3.2.3
>Reporter: Marko A. Rodriguez
>Assignee: Marko A. Rodriguez
> Fix For: 3.3.0, 3.2.4
>
>
> This may be a non-issue (need to check), but we currently do this in every 
> {{Graph}} (and {{GraphComputer}}) class.
> {code}
> static {
> TraversalStrategies.GlobalCache.registerStrategies(TinkerGraph.class, 
> TraversalStrategies.GlobalCache.getStrategies(Graph.class).clone().addStrategies(TinkerGraphStepStrategy.instance()));
> }
> {code}
> If this static code is loaded every time a {{Graph}} instance is created, 
> then manually tweaked strategy registrations get overwritten. If this is the 
> case, then we should do:
> {code}
> static {
> 
> TraversalStrategies.GlobalCache.registerStrategiesIfNotPresent(TinkerGraph.class,TraversalStrategies.GlobalCache.getStrategies(Graph.class).clone().addStrategies(TinkerGraphStepStrategy.instance()));
> }
> {code}
> That is, add a {{registerIfNotPresent()}} method.



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

[jira] [Commented] (TINKERPOP-1531) DedupTest.g_V_asXaX_repeatXbothX_timesX3X_emit_asXbX_group_byXselectXaXX_byXselectXbX_dedup_order_byXidX_foldX_selectXvaluesX_unfold_dedup assumes id implements Com

[Marko A. Rodriguez (JIRA)]

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

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

Yea, that is a bad test. Can you change the test and provide a PR? (or... was 
this already done? -- if so, please close this JIRA ticket).

> DedupTest.g_V_asXaX_repeatXbothX_timesX3X_emit_asXbX_group_byXselectXaXX_byXselectXbX_dedup_order_byXidX_foldX_selectXvaluesX_unfold_dedup
>  assumes id implements Comparable
> ---
>
> Key: TINKERPOP-1531
> URL: https://issues.apache.org/jira/browse/TINKERPOP-1531
> Project: TinkerPop
>  Issue Type: Bug
>  Components: test-suite
>Affects Versions: 3.2.3
>Reporter: pieter martin
>Priority: Minor
>
> {noformat}DedupTest.g_V_asXaX_repeatXbothX_timesX3X_emit_asXbX_group_byXselectXaXX_byXselectXbX_dedup_order_byXidX_foldX_selectXvaluesX_unfold_dedup{noformat}
>  includes {noformat}order().by(T.id){noformat} which assumes that the id 
> implements Comparable.
> As ids are specified as Object this is not always true.



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

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

[okram]

Github user okram commented on the issue:

https://github.com/apache/tinkerpop/pull/470
  
Ah, so they want to know WHICH traversal in their application through the 
exception, not necessarily WHERE in a particular traversal the exception was 
thrown?


---
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-1118) SparkGraphComputer should use StarGraph, not VertexWritable.

[Marko A. Rodriguez (JIRA)]

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

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

I think we can get rid of the {{VertexWritable}}/{{ObjectWritable}} 
serialization issues if we solve this ticket. cc/ [~dalaro]

Right now, {{VertexWritable}} and {{ObjectWritable}} have their own 
serialization logic. This is important as these classes are used outside of 
just running jobs, but also for reading and writing {{SequenceFiles}}. In 
Spark, we don't need to have the RDD use these writables and in fact, can just 
directly reference the objects they wrap. In this way, we could have a better 
split between {{GryoInput/OutputFormat}} and the internal job serialization 
(message passing and the like).

> SparkGraphComputer should use StarGraph, not VertexWritable.
> 
>
> Key: TINKERPOP-1118
> URL: https://issues.apache.org/jira/browse/TINKERPOP-1118
> Project: TinkerPop
>  Issue Type: Improvement
>  Components: hadoop
>Affects Versions: 3.1.1-incubating
>Reporter: Marko A. Rodriguez
>  Labels: breaking
> Fix For: 3.3.0
>
>
> {{SparkGraphComputer}} input RDDs are typed as:
> {code}
> JavaPairRDD
> {code}
> The {{VertexWritable}} usage is a vestige from Hadoop and Giraph. In Spark, 
> we don't need to have this wrapper and thus, we can reduce the overhead (one 
> less object header) by making the input RDDs typed as:
> {code}
> JavaPairRDD
> {code}
> This would be a breaking change for graph providers that implement their own 
> {{InputRDD}} and {{OutputRDD}}, however, the fix is trivial. Instead of {{new 
> VertexWritable(vertex)}}, they would simply do {{StarGraph.of(vertex)}}. 



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

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

[ASF GitHub Bot (JIRA)]

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

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

Github user pauljackson closed the pull request at:

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


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



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

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

[pauljackson]

Github user pauljackson commented on the issue:

https://github.com/apache/tinkerpop/pull/456
  
OK, sorry about that. I closed it now.

-Paul


From: Jason Plurad [mailto:notificati...@github.com]
Sent: Monday, October 31, 2016 12:13 PM
To: apache/tinkerpop
Cc: Paul A. Jackson; Mention
Subject: Re: [apache/tinkerpop] TINKERPOP-1493 Groovy project doesn't build 
on Windows (#456)


I meant that this pull request 
#456 can be closed 
@pauljackson. We'll work with the other one 
#457.

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






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

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

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on TINKERPOP-887:
--

Github user dkuppitz commented on the issue:

https://github.com/apache/tinkerpop/pull/470
  
Interesting. I've had different results in myy benchmark and it looked more 
like just a lot of noise in the measurements, since Bryn's branch was sometimes 
a bit faster. There's a crazy difference between the 2 results of 
`h.V().out().out().out().toSet()`, but the others look okay to me.

> When is it NOT obvious?
It is not obvious for the actual users of TinkerPop. Applications throw 
exceptions and users have no idea where they need to fix their application.


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

[ASF GitHub Bot (JIRA)]

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

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

Github user pauljackson commented on the issue:

https://github.com/apache/tinkerpop/pull/456
  
OK, sorry about that. I closed it now.

-Paul


From: Jason Plurad [mailto:notificati...@github.com]
Sent: Monday, October 31, 2016 12:13 PM
To: apache/tinkerpop
Cc: Paul A. Jackson; Mention
Subject: Re: [apache/tinkerpop] TINKERPOP-1493 Groovy project doesn't build 
on Windows (#456)


I meant that this pull request 
#456 can be closed 
@pauljackson. We'll work with the other one 
#457.

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






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



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

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

[dkuppitz]

Github user dkuppitz commented on the issue:

https://github.com/apache/tinkerpop/pull/470
  
Interesting. I've had different results in myy benchmark and it looked more 
like just a lot of noise in the measurements, since Bryn's branch was sometimes 
a bit faster. There's a crazy difference between the 2 results of 
`h.V().out().out().out().toSet()`, but the others look okay to me.

> When is it NOT obvious?
It is not obvious for the actual users of TinkerPop. Applications throw 
exceptions and users have no idea where they need to fix their application.


---
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 #456: TINKERPOP-1493 Groovy project doesn't build on ...

[pauljackson]

Github user pauljackson closed the pull request at:

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


---
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-1489) Provide a Javascript Gremlin Language Variant

[ASF GitHub Bot (JIRA)]

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

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

Github user spmallette commented on the issue:

https://github.com/apache/tinkerpop/pull/450
  
I can take a shot at TINKERPOP-1490. I think we have community consensus on 
the approach if I remember correctly. I will work on it this week.


> 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

[spmallette]

Github user spmallette commented on the issue:

https://github.com/apache/tinkerpop/pull/450
  
I can take a shot at TINKERPOP-1490. I think we have community consensus on 
the approach if I remember correctly. I will work on it this week.


---
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 #450: TINKERPOP-1489 Javascript GLV

[okram]

Github user okram commented on the issue:

https://github.com/apache/tinkerpop/pull/450
  
@jorgebay  -- thanks for being patient. We have pushed off thinking about 
this since it wasn't going into the 3.2.3 and we were dealing with that release 
the last 2+ weeks.

I would like to get this into 3.2.4, so, lets focus on it again! 

We need to get the promise-based API settled for Gremlin-Java and then we 
can ripple that to Gremlin-JavaScript.  Thus, I think we should solve and merge 
this ticket first:  https://issues.apache.org/jira/browse/TINKERPOP-1490

I'm not too smart in this type of work ("promise" "future" etc. APIs)... so 
help on that ticket would be appreciated. Also, would having this worked out, 
then help to solidify your open questions on Gremlin-JavaScript?






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

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on TINKERPOP-887:
--

Github user okram commented on the issue:

https://github.com/apache/tinkerpop/pull/470
  
I ran a benchmark:

**BRYN'S BRANCH**

```
gremlin> graph = TinkerGraph.open()
==>tinkergraph[vertices:0 edges:0]
gremlin> graph.io(gryo()).readGraph('data/grateful-dead.kryo')
==>null
gremlin> h = graph.traversal()
==>graphtraversalsource[tinkergraph[vertices:808 edges:8049], standard]
gremlin> g = graph.traversal().withoutStrategies(LazyBarrierStrategy.class)
==>graphtraversalsource[tinkergraph[vertices:808 edges:8049], standard]
gremlin>
gremlin> clock(100){ h.V().out().out().out().toSet() }
==>5.1423786
gremlin> clock(20){ g.V().out().out().out().toSet() }
==>778.8892011
gremlin> clock(20){ g.V().out().flatMap(out()).flatMap(out()).toSet() }
==>1234.6360252
gremlin> clock(100){ g.V().repeat(out()).times(3).toSet() }
==>2.286429939997
gremlin> clock(100){ h.V().count() }
==>0.01190773
```

**MASTER BRANCH**

```
gremlin> graph = TinkerGraph.open()
==>tinkergraph[vertices:0 edges:0]
gremlin> graph.io(gryo()).readGraph('data/grateful-dead.kryo')
==>null
gremlin> h = graph.traversal()
==>graphtraversalsource[tinkergraph[vertices:808 edges:8049], standard]
gremlin> g = graph.traversal().withoutStrategies(LazyBarrierStrategy.class)
==>graphtraversalsource[tinkergraph[vertices:808 edges:8049], standard]
gremlin>
gremlin> clock(100){ h.V().out().out().out().toSet() }
==>3.2528534
gremlin> clock(20){ g.V().out().out().out().toSet() }
==>701.793796549
gremlin> clock(20){ g.V().out().flatMap(out()).flatMap(out()).toSet() }
==>1374.86072635
gremlin> clock(100){ g.V().repeat(out()).times(3).toSet() }
==>2.481017049997
gremlin> clock(100){ h.V().count() }
==>0.01866702
```

The reason for the `withoutStrategies(LazyBarrierStrategy)` is that I 
wanted to test lots and lots of results and thus, test the cost of the added 
`try/catch`-block. I guess the costs are neglible (?? what do others think ??).

Also, @bryncooke, can you provide an example of master/ vs. your branch of 
when its good to get a `NoSuchElementException`? When I do:

```
gremlin> g.V().out().values('age').next()
java.util.NoSuchElementException
Type ':help' or ':h' for help.
Display stack trace? [yN]y
java.util.NoSuchElementException
at 
org.apache.tinkerpop.gremlin.process.traversal.util.DefaultTraversal.next(DefaultTraversal.java:194)
...
```

...all  I learn is that the traversal `next()` method couldn't find 
anything. But that is obvious. When is it NOT obvious?


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

[ASF GitHub Bot (JIRA)]

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

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

Github user spmallette commented on the issue:

https://github.com/apache/tinkerpop/pull/457
  
i didn't try with just `-t` - pretty sure it is just integration tests 
though. i found what i think is a fix to my problem though - i removed all my 
docker images and had them rebuild and i just got my first good build on docker 
with `-t -i` in a long time.  i should be back to running it on this PR pretty 
soon. i have two separate systems doing builds right now on two different 
branches. hopefully they will both pass given the rebuilding of docker images.


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



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

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

[ASF GitHub Bot (JIRA)]

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

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

Github user pluradj commented on the issue:

https://github.com/apache/tinkerpop/pull/457
  
@spmallette are you hitting that with `docker/build.sh -t` also or only 
with integration tests?


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



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

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

[pluradj]

Github user pluradj commented on the issue:

https://github.com/apache/tinkerpop/pull/457
  
@spmallette are you hitting that with `docker/build.sh -t` also or only 
with integration tests?


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

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

[ASF GitHub Bot (JIRA)]

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

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

Github user pluradj commented on the issue:

https://github.com/apache/tinkerpop/pull/456
  
I meant that this pull request #456 can be closed @pauljackson. We'll work 
with the other one #457.


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



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

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

[pluradj]

Github user pluradj commented on the issue:

https://github.com/apache/tinkerpop/pull/456
  
I meant that this pull request #456 can be closed @pauljackson. We'll work 
with the other one #457.


---
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-1489) Provide a Javascript Gremlin Language Variant

[ASF GitHub Bot (JIRA)]

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

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

Github user jorgebay commented on the issue:

https://github.com/apache/tinkerpop/pull/450
  
I've added some fixes during the past weeks.

I'll try to summarize the open issues with this patch to try to unblock it:

A) Currently, the javascript GLV exposes `list()` instead of `toList()`. As 
it takes a callback as a parameter, having the method start with a `toX()` 
didn't feel natural to me.
Maybe it makes more sense to follow the existing naming (`toList()`). 
Exposing something uniform across all GLVs, whenever possible, can be more 
important (in the same way as Python GLV used mixedCase to be more close to 
gremlin).
The same applies to `next()`. To avoid confusions, we could document that 
`traversal.next()` is not an iterator and returns the first result.

B) Promise-based API.
We can include a promise-based method overloads when supported by the js 
engine, like [proposed above][1]. We can do it now, before merging it or as a 
next step after merging.

Can we try to reach a conclusion on these issues?
After that I can send a draft documentation for `gremlin-variants.asciidoc`.

I've been using the Javascript GLV for a while now and it feels good to 
have code completion for Traversal methods on the IDE!

[1]: https://github.com/apache/tinkerpop/pull/450#issuecomment-252911095


> 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

[jorgebay]

Github user jorgebay commented on the issue:

https://github.com/apache/tinkerpop/pull/450
  
I've added some fixes during the past weeks.

I'll try to summarize the open issues with this patch to try to unblock it:

A) Currently, the javascript GLV exposes `list()` instead of `toList()`. As 
it takes a callback as a parameter, having the method start with a `toX()` 
didn't feel natural to me.
Maybe it makes more sense to follow the existing naming (`toList()`). 
Exposing something uniform across all GLVs, whenever possible, can be more 
important (in the same way as Python GLV used mixedCase to be more close to 
gremlin).
The same applies to `next()`. To avoid confusions, we could document that 
`traversal.next()` is not an iterator and returns the first result.

B) Promise-based API.
We can include a promise-based method overloads when supported by the js 
engine, like [proposed above][1]. We can do it now, before merging it or as a 
next step after merging.

Can we try to reach a conclusion on these issues?
After that I can send a draft documentation for `gremlin-variants.asciidoc`.

I've been using the Javascript GLV for a while now and it feels good to 
have code completion for Traversal methods on the IDE!

[1]: https://github.com/apache/tinkerpop/pull/450#issuecomment-252911095


---
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] [Reopened] (TINKERPOP-1493) Groovy project doesn't build on Windows

[stephen mallette (JIRA)]

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

stephen mallette reopened TINKERPOP-1493:
-
  Assignee: Jason Plurad

The issue shouldn't be closed until the PR is merged and all issues associated 
with it are dealt with.

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



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

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

[Paul Jackson (JIRA)]

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

Paul Jackson closed TINKERPOP-1493.
---

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



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

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

[Paul Jackson (JIRA)]

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

Paul Jackson resolved TINKERPOP-1493.
-
Resolution: Fixed

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



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

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

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on TINKERPOP-887:
--

Github user dkuppitz commented on the issue:

https://github.com/apache/tinkerpop/pull/470
  
LGTM, thus 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...

[dkuppitz]

Github user dkuppitz commented on the issue:

https://github.com/apache/tinkerpop/pull/470
  
LGTM, thus VOTE: +1.


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

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

[ASF GitHub Bot (JIRA)]

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

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

Github user spmallette commented on the issue:

https://github.com/apache/tinkerpop/pull/457
  
i'm having a tough time getting this to build with docker. not sure 
whykeep getting failures that seem unrelated to this PR (dies in spark). 

```text
java.lang.IllegalStateException: org.apache.spark.SparkException: Job 
aborted due to stage failure: Task 1 in stage 4226.0 failed 1 times, most 
recent failure: Lost task 1.0 in stage 4226.0 (TID 4939, localhost): 
java.io.IOException: Mkdirs failed to create 
/usr/src/tinkerpop/spark-gremlin/target/test-case-data/SparkHadoopGraphProvider/graph-provider-data/~reducing/_temporary/0/_temporary/attempt_201610302243_9163_r_01_0
 (exists=false, cwd=file:/usr/src/tinkerpop/spark-gremlin)
at 
org.apache.hadoop.fs.ChecksumFileSystem.create(ChecksumFileSystem.java:450)
at 
org.apache.hadoop.fs.ChecksumFileSystem.create(ChecksumFileSystem.java:435)
at org.apache.hadoop.fs.FileSystem.create(FileSystem.java:909)
at 
org.apache.hadoop.io.SequenceFile$Writer.(SequenceFile.java:1135)
at org.apache.hadoop.io.SequenceFile.createWriter(SequenceFile.java:273)
at org.apache.hadoop.io.SequenceFile.createWriter(SequenceFile.java:530)
at 
org.apache.hadoop.mapreduce.lib.output.SequenceFileOutputFormat.getSequenceWriter(SequenceFileOutputFormat.java:64)
at 
org.apache.hadoop.mapreduce.lib.output.SequenceFileOutputFormat.getRecordWriter(SequenceFileOutputFormat.java:75)
at 
org.apache.spark.rdd.PairRDDFunctions$$anonfun$saveAsNewAPIHadoopDataset$1$$anonfun$12.apply(PairRDDFunctions.scala:1030)
at 
org.apache.spark.rdd.PairRDDFunctions$$anonfun$saveAsNewAPIHadoopDataset$1$$anonfun$12.apply(PairRDDFunctions.scala:1014)
at org.apache.spark.scheduler.ResultTask.runTask(ResultTask.scala:66)
at org.apache.spark.scheduler.Task.run(Task.scala:88)
at org.apache.spark.executor.Executor$TaskRunner.run(Executor.scala:214)
at 
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
at 
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
at java.lang.Thread.run(Thread.java:745)
Driver stacktrace:
at 
java.util.concurrent.CompletableFuture.reportGet(CompletableFuture.java:357)
at 
java.util.concurrent.CompletableFuture.get(CompletableFuture.java:1895)
at 
org.apache.tinkerpop.gremlin.process.computer.traversal.step.map.ComputerResultStep.processNextStart(ComputerResultStep.java:81)
at 
org.apache.tinkerpop.gremlin.process.traversal.step.util.AbstractStep.next(AbstractStep.java:126)
at 
org.apache.tinkerpop.gremlin.process.traversal.step.util.AbstractStep.next(AbstractStep.java:37)
at 
org.apache.tinkerpop.gremlin.process.traversal.util.DefaultTraversal.next(DefaultTraversal.java:157)
at 
org.apache.tinkerpop.gremlin.process.traversal.strategy.decoration.SubgraphStrategyProcessTest.shouldFilterEdgeCriterion(SubgraphStrategyProcessTest.java:166)
Caused by: org.apache.spark.SparkException: Job aborted due to stage 
failure: Task 1 in stage 4226.0 failed 1 times, most recent failure: Lost task 
1.0 in stage 4226.0 (TID 4939, localhost): java.io.IOException: Mkdirs failed 
to create 
/usr/src/tinkerpop/spark-gremlin/target/test-case-data/SparkHadoopGraphProvider/graph-provider-data/~reducing/_temporary/0/_temporary/attempt_201610302243_9163_r_01_0
 (exists=false, cwd=file:/usr/src/tinkerpop/spark-gremlin)
at 
org.apache.hadoop.fs.ChecksumFileSystem.create(ChecksumFileSystem.java:450)
at 
org.apache.hadoop.fs.ChecksumFileSystem.create(ChecksumFileSystem.java:435)
at org.apache.hadoop.fs.FileSystem.create(FileSystem.java:909)
at 
org.apache.hadoop.io.SequenceFile$Writer.(SequenceFile.java:1135)
at org.apache.hadoop.io.SequenceFile.createWriter(SequenceFile.java:273)
at org.apache.hadoop.io.SequenceFile.createWriter(SequenceFile.java:530)
at 
org.apache.hadoop.mapreduce.lib.output.SequenceFileOutputFormat.getSequenceWriter(SequenceFileOutputFormat.java:64)
at 
org.apache.hadoop.mapreduce.lib.output.SequenceFileOutputFormat.getRecordWriter(SequenceFileOutputFormat.java:75)
at 
org.apache.spark.rdd.PairRDDFunctions$$anonfun$saveAsNewAPIHadoopDataset$1$$anonfun$12.apply(PairRDDFunctions.scala:1030)
at 
org.apache.spark.rdd.PairRDDFunctions$$anonfun$saveAsNewAPIHadoopDataset$1$$anonfun$12.apply(PairRDDFunctions.scala:1014)
at org.apache.spark.scheduler.ResultTask.runTask(ResultTask.scala:66)
at org.apache.spark.scheduler.Task.run(Task.scala:88)
at 

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

[spmallette]

Github user spmallette commented on the issue:

https://github.com/apache/tinkerpop/pull/457
  
i'm having a tough time getting this to build with docker. not sure 
whykeep getting failures that seem unrelated to this PR (dies in spark). 

```text
java.lang.IllegalStateException: org.apache.spark.SparkException: Job 
aborted due to stage failure: Task 1 in stage 4226.0 failed 1 times, most 
recent failure: Lost task 1.0 in stage 4226.0 (TID 4939, localhost): 
java.io.IOException: Mkdirs failed to create 
/usr/src/tinkerpop/spark-gremlin/target/test-case-data/SparkHadoopGraphProvider/graph-provider-data/~reducing/_temporary/0/_temporary/attempt_201610302243_9163_r_01_0
 (exists=false, cwd=file:/usr/src/tinkerpop/spark-gremlin)
at 
org.apache.hadoop.fs.ChecksumFileSystem.create(ChecksumFileSystem.java:450)
at 
org.apache.hadoop.fs.ChecksumFileSystem.create(ChecksumFileSystem.java:435)
at org.apache.hadoop.fs.FileSystem.create(FileSystem.java:909)
at 
org.apache.hadoop.io.SequenceFile$Writer.(SequenceFile.java:1135)
at org.apache.hadoop.io.SequenceFile.createWriter(SequenceFile.java:273)
at org.apache.hadoop.io.SequenceFile.createWriter(SequenceFile.java:530)
at 
org.apache.hadoop.mapreduce.lib.output.SequenceFileOutputFormat.getSequenceWriter(SequenceFileOutputFormat.java:64)
at 
org.apache.hadoop.mapreduce.lib.output.SequenceFileOutputFormat.getRecordWriter(SequenceFileOutputFormat.java:75)
at 
org.apache.spark.rdd.PairRDDFunctions$$anonfun$saveAsNewAPIHadoopDataset$1$$anonfun$12.apply(PairRDDFunctions.scala:1030)
at 
org.apache.spark.rdd.PairRDDFunctions$$anonfun$saveAsNewAPIHadoopDataset$1$$anonfun$12.apply(PairRDDFunctions.scala:1014)
at org.apache.spark.scheduler.ResultTask.runTask(ResultTask.scala:66)
at org.apache.spark.scheduler.Task.run(Task.scala:88)
at org.apache.spark.executor.Executor$TaskRunner.run(Executor.scala:214)
at 
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
at 
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
at java.lang.Thread.run(Thread.java:745)
Driver stacktrace:
at 
java.util.concurrent.CompletableFuture.reportGet(CompletableFuture.java:357)
at 
java.util.concurrent.CompletableFuture.get(CompletableFuture.java:1895)
at 
org.apache.tinkerpop.gremlin.process.computer.traversal.step.map.ComputerResultStep.processNextStart(ComputerResultStep.java:81)
at 
org.apache.tinkerpop.gremlin.process.traversal.step.util.AbstractStep.next(AbstractStep.java:126)
at 
org.apache.tinkerpop.gremlin.process.traversal.step.util.AbstractStep.next(AbstractStep.java:37)
at 
org.apache.tinkerpop.gremlin.process.traversal.util.DefaultTraversal.next(DefaultTraversal.java:157)
at 
org.apache.tinkerpop.gremlin.process.traversal.strategy.decoration.SubgraphStrategyProcessTest.shouldFilterEdgeCriterion(SubgraphStrategyProcessTest.java:166)
Caused by: org.apache.spark.SparkException: Job aborted due to stage 
failure: Task 1 in stage 4226.0 failed 1 times, most recent failure: Lost task 
1.0 in stage 4226.0 (TID 4939, localhost): java.io.IOException: Mkdirs failed 
to create 
/usr/src/tinkerpop/spark-gremlin/target/test-case-data/SparkHadoopGraphProvider/graph-provider-data/~reducing/_temporary/0/_temporary/attempt_201610302243_9163_r_01_0
 (exists=false, cwd=file:/usr/src/tinkerpop/spark-gremlin)
at 
org.apache.hadoop.fs.ChecksumFileSystem.create(ChecksumFileSystem.java:450)
at 
org.apache.hadoop.fs.ChecksumFileSystem.create(ChecksumFileSystem.java:435)
at org.apache.hadoop.fs.FileSystem.create(FileSystem.java:909)
at 
org.apache.hadoop.io.SequenceFile$Writer.(SequenceFile.java:1135)
at org.apache.hadoop.io.SequenceFile.createWriter(SequenceFile.java:273)
at org.apache.hadoop.io.SequenceFile.createWriter(SequenceFile.java:530)
at 
org.apache.hadoop.mapreduce.lib.output.SequenceFileOutputFormat.getSequenceWriter(SequenceFileOutputFormat.java:64)
at 
org.apache.hadoop.mapreduce.lib.output.SequenceFileOutputFormat.getRecordWriter(SequenceFileOutputFormat.java:75)
at 
org.apache.spark.rdd.PairRDDFunctions$$anonfun$saveAsNewAPIHadoopDataset$1$$anonfun$12.apply(PairRDDFunctions.scala:1030)
at 
org.apache.spark.rdd.PairRDDFunctions$$anonfun$saveAsNewAPIHadoopDataset$1$$anonfun$12.apply(PairRDDFunctions.scala:1014)
at org.apache.spark.scheduler.ResultTask.runTask(ResultTask.scala:66)
at org.apache.spark.scheduler.Task.run(Task.scala:88)
at org.apache.spark.executor.Executor$TaskRunner.run(Executor.scala:214)
at 
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
at 
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
at 

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

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on TINKERPOP-887:
--

Github user BrynCooke commented on the issue:

https://github.com/apache/tinkerpop/pull/470
  
@dkuppitz I've updated the changelog and upgrade docs. Please could you 
take a look?


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

[BrynCooke]

Github user BrynCooke commented on the issue:

https://github.com/apache/tinkerpop/pull/470
  
@dkuppitz I've updated the changelog and upgrade docs. Please could you 
take a look?


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

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on TINKERPOP-887:
--

Github user BrynCooke commented on the issue:

https://github.com/apache/tinkerpop/pull/470
  
The lambda traversal will throw a regular NoSuchElementException is it is 
unparented.
However, won't this will only happen once? The exception will bubble up and 
out of the top level traversal?

If they did this
```
g.V().blah().map{ x -> 
  try {
__.inject(x).will().not().have().anything().next()
return "foo";
  }
  catch(NoSuchElementException e) {
return "bar";
  }
}
```
instead of

```
g.V().blah().map{ x -> 
  if(__.inject(x).will().not().have().anything().hasNext()) {
return "foo";
  }
  else {
return "bar";
  }
}
```
Then they would have a problem.




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

[BrynCooke]

Github user BrynCooke commented on the issue:

https://github.com/apache/tinkerpop/pull/470
  
The lambda traversal will throw a regular NoSuchElementException is it is 
unparented.
However, won't this will only happen once? The exception will bubble up and 
out of the top level traversal?

If they did this
```
g.V().blah().map{ x -> 
  try {
__.inject(x).will().not().have().anything().next()
return "foo";
  }
  catch(NoSuchElementException e) {
return "bar";
  }
}
```
instead of

```
g.V().blah().map{ x -> 
  if(__.inject(x).will().not().have().anything().hasNext()) {
return "foo";
  }
  else {
return "bar";
  }
}
```
Then they would have 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.
---