[jira] [Commented] (TINKERPOP-1867) union() can produce extra traversers
[ https://issues.apache.org/jira/browse/TINKERPOP-1867?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16317607#comment-16317607 ] Daniel Kuppitz commented on TINKERPOP-1867: --- It looks similar to what we saw in [TINKERPOP-1629|https://issues.apache.org/jira/browse/TINKERPOP-1629]. {noformat} gremlin> __.inject(1,2).map(union(fold()).fold()) ==>[[1]] ==>[[],[2]] gremlin> __.inject(1,2).map(union(mean()).fold()) ==>[1.0] ==>[NaN,2.0] {noformat} Marko tried hard to solve TINKERPOP-1629, but ultimately we decided to allow reducing barriers despite the few issues that can occur. It's probably the same thing for {{union()}}. We could write a simple strategy though, that would wrap all reducing child traversals in a {{map()}}. {noformat} gremlin> __.inject(1,2).map(union(map(fold())).fold()) ==>[[1]] ==>[[2]] gremlin> __.inject(1,2).map(union(map(mean())).fold()) ==>[1.0] ==>[2.0] {noformat} > union() can produce extra traversers > - > > Key: TINKERPOP-1867 > URL: https://issues.apache.org/jira/browse/TINKERPOP-1867 > Project: TinkerPop > Issue Type: Bug > Components: process >Affects Versions: 3.2.7 >Reporter: stephen mallette >Assignee: stephen mallette > > Hard to say where this bug is coming from but basically the most simple > representation is: > {code} > gremlin> g.V(1,2).local(__.union(__.constant(1).count())) > ==>1 > ==>0 > ==>1 > {code} > Similar problems occur with {{sum()}} and other reducing barriers when used > in this context. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (TINKERPOP-1861) VertexProgram create with varargs for Graphs
[ https://issues.apache.org/jira/browse/TINKERPOP-1861?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16317118#comment-16317118 ] ASF GitHub Bot commented on TINKERPOP-1861: --- GitHub user PBGraff opened a pull request: https://github.com/apache/tinkerpop/pull/772 TINKERPOP-1861 Modify VertexProgram Builder to take varargs Graphs VertexProgram.Builder.create() now takes varargs Graphs instead of just a single Graph. This change has been propagated through all methods affected. Old API is kept but deprecated for interfaces. Implementations of these interfaces have been updated to use the new API. Possible test problems that I don't understand and build flags due to API change. You can merge this pull request into a Git repository by running: $ git pull https://github.com/PBGraff/tinkerpop TINKERPOP-1861 Alternatively you can review and apply these changes as the patch at: https://github.com/apache/tinkerpop/pull/772.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 #772 commit 2a121f5a18385432c55000626114561a371ba138 Author: Graff, Philip B Date: 2018-01-08T21:26:05Z First set of changes moving to new API commit 48cb3dd3214050f7b54f16fa3576ec36f1196c49 Author: Graff, Philip B Date: 2018-01-08T20:22:48Z Updates to keep old API but deprecated commit ba2236dbfe85447265a8e56cabac46e419f665d1 Author: Graff, Philip B Date: 2018-01-08T21:16:34Z Modifying the test > VertexProgram create with varargs for Graphs > > > Key: TINKERPOP-1861 > URL: https://issues.apache.org/jira/browse/TINKERPOP-1861 > Project: TinkerPop > Issue Type: Improvement > Components: process >Affects Versions: 3.2.7 >Reporter: Philip Graff >Priority: Minor > > VertexProgram.Builder.create(Graph) can be modified to > VertexProgram.Builder.create(Graph...) so that passing in zero or many graphs > is naturally handled. The current state of passing in null when no graph is > needed is bad practice. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[GitHub] tinkerpop pull request #772: TINKERPOP-1861 Modify VertexProgram Builder to ...
GitHub user PBGraff opened a pull request: https://github.com/apache/tinkerpop/pull/772 TINKERPOP-1861 Modify VertexProgram Builder to take varargs Graphs VertexProgram.Builder.create() now takes varargs Graphs instead of just a single Graph. This change has been propagated through all methods affected. Old API is kept but deprecated for interfaces. Implementations of these interfaces have been updated to use the new API. Possible test problems that I don't understand and build flags due to API change. You can merge this pull request into a Git repository by running: $ git pull https://github.com/PBGraff/tinkerpop TINKERPOP-1861 Alternatively you can review and apply these changes as the patch at: https://github.com/apache/tinkerpop/pull/772.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 #772 commit 2a121f5a18385432c55000626114561a371ba138 Author: Graff, Philip B Date: 2018-01-08T21:26:05Z First set of changes moving to new API commit 48cb3dd3214050f7b54f16fa3576ec36f1196c49 Author: Graff, Philip B Date: 2018-01-08T20:22:48Z Updates to keep old API but deprecated commit ba2236dbfe85447265a8e56cabac46e419f665d1 Author: Graff, Philip B Date: 2018-01-08T21:16:34Z Modifying the test ---
[jira] [Created] (TINKERPOP-1867) union() can produce extra traversers
stephen mallette created TINKERPOP-1867: --- Summary: union() can produce extra traversers Key: TINKERPOP-1867 URL: https://issues.apache.org/jira/browse/TINKERPOP-1867 Project: TinkerPop Issue Type: Bug Components: process Affects Versions: 3.2.7 Reporter: stephen mallette Assignee: stephen mallette Hard to say where this bug is coming from but basically the most simple representation is: {code} gremlin> g.V(1,2).local(__.union(__.constant(1).count())) ==>1 ==>0 ==>1 {code} Similar problems occur with {{sum()}} and other reducing barriers when used in this context. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (TINKERPOP-1861) VertexProgram create with varargs for Graphs
[ https://issues.apache.org/jira/browse/TINKERPOP-1861?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16316981#comment-16316981 ] ASF GitHub Bot commented on TINKERPOP-1861: --- Github user PBGraff closed the pull request at: https://github.com/apache/tinkerpop/pull/768 > VertexProgram create with varargs for Graphs > > > Key: TINKERPOP-1861 > URL: https://issues.apache.org/jira/browse/TINKERPOP-1861 > Project: TinkerPop > Issue Type: Improvement > Components: process >Affects Versions: 3.2.7 >Reporter: Philip Graff >Priority: Minor > > VertexProgram.Builder.create(Graph) can be modified to > VertexProgram.Builder.create(Graph...) so that passing in zero or many graphs > is naturally handled. The current state of passing in null when no graph is > needed is bad practice. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[GitHub] tinkerpop pull request #768: TINKERPOP-1861 Modify VertexProgram.Builder.cre...
Github user PBGraff closed the pull request at: https://github.com/apache/tinkerpop/pull/768 ---
[jira] [Commented] (TINKERPOP-1447) Add some JavaScript intelligence to the documentation so that comments and output are not copied in a copy paste
[ https://issues.apache.org/jira/browse/TINKERPOP-1447?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16316719#comment-16316719 ] ASF GitHub Bot commented on TINKERPOP-1447: --- Github user spmallette commented on the issue: https://github.com/apache/tinkerpop/pull/766 don't have any of that stuff from my last attempt. what are you looking for exactly? i could fire it up again > Add some JavaScript intelligence to the documentation so that comments and > output are not copied in a copy paste > > > Key: TINKERPOP-1447 > URL: https://issues.apache.org/jira/browse/TINKERPOP-1447 > Project: TinkerPop > Issue Type: Improvement > Components: documentation >Affects Versions: 3.1.4, 3.2.2 >Reporter: Marko A. Rodriguez > > [~rjbriody] was saying that it is possible to have it such that when you > copy/paste the following: > {code} > gremlin> g.V().out("created") // and example <1> > ==>blah > {code} > only {{g.V().out("created")}} is put into the clipboard. I believe he said it > was via some JavaScript magic --- beyond me, but it would be cool if we did > this. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[GitHub] tinkerpop issue #766: TINKERPOP-1447 Add some JavaScript intelligence to the...
Github user spmallette commented on the issue: https://github.com/apache/tinkerpop/pull/766 don't have any of that stuff from my last attempt. what are you looking for exactly? i could fire it up again ---
[jira] [Commented] (TINKERPOP-1861) VertexProgram create with varargs for Graphs
[ https://issues.apache.org/jira/browse/TINKERPOP-1861?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16316717#comment-16316717 ] ASF GitHub Bot commented on TINKERPOP-1861: --- Github user spmallette commented on the issue: https://github.com/apache/tinkerpop/pull/768 Yes - @PBGraff please re-target the PR to tp32. > VertexProgram create with varargs for Graphs > > > Key: TINKERPOP-1861 > URL: https://issues.apache.org/jira/browse/TINKERPOP-1861 > Project: TinkerPop > Issue Type: Improvement > Components: process >Affects Versions: 3.2.7 >Reporter: Philip Graff >Priority: Minor > > VertexProgram.Builder.create(Graph) can be modified to > VertexProgram.Builder.create(Graph...) so that passing in zero or many graphs > is naturally handled. The current state of passing in null when no graph is > needed is bad practice. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[GitHub] tinkerpop issue #768: TINKERPOP-1861 Modify VertexProgram.Builder.create() t...
Github user spmallette commented on the issue: https://github.com/apache/tinkerpop/pull/768 Yes - @PBGraff please re-target the PR to tp32. ---
[jira] [Commented] (TINKERPOP-1866) Support g:T for .NET
[ https://issues.apache.org/jira/browse/TINKERPOP-1866?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16316714#comment-16316714 ] stephen mallette commented on TINKERPOP-1866: - I don't know if it provides much value in 2.0not sure of any other circumstance where it would be returned as part of a traversal. afaik, {{valueMap(true)} is the only use case. not sure if anyone else can think of a reason to have it supported for GraphSON 2.0. Note that "support" in this case does mean "when {{T}} is returned from the server, not when sent to the server". We already support {{T}} being serialized generally as an enum to the server in GraphSON 2.0. > Support g:T for .NET > > > Key: TINKERPOP-1866 > URL: https://issues.apache.org/jira/browse/TINKERPOP-1866 > Project: TinkerPop > Issue Type: Improvement > Components: dotnet >Affects Versions: 3.3.1 >Reporter: stephen mallette >Assignee: Jorge Bay >Priority: Critical > > We didn't have tests for return of {{T}} which can occur with > {{valueMap(true)}} - adding them on TINKERPOP-1860 exposed the failure in > .NET. This may or may not be an issue for GraphSON 3.0 only. In GraphSON 2.0, > {{g:T}} is a defined type, but it is typically not returned from the server > outside of {{valueMap(true)}}. When that did happen in GraphSON 2.0, {{T}} > values were simply converted to string. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (TINKERPOP-1866) Support g:T for .NET
[ https://issues.apache.org/jira/browse/TINKERPOP-1866?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16316685#comment-16316685 ] Jorge Bay commented on TINKERPOP-1866: -- Do you think we should we add it for both GraphSON2 and GraphSON3? > Support g:T for .NET > > > Key: TINKERPOP-1866 > URL: https://issues.apache.org/jira/browse/TINKERPOP-1866 > Project: TinkerPop > Issue Type: Improvement > Components: dotnet >Affects Versions: 3.3.1 >Reporter: stephen mallette >Assignee: Jorge Bay >Priority: Critical > > We didn't have tests for return of {{T}} which can occur with > {{valueMap(true)}} - adding them on TINKERPOP-1860 exposed the failure in > .NET. This may or may not be an issue for GraphSON 3.0 only. In GraphSON 2.0, > {{g:T}} is a defined type, but it is typically not returned from the server > outside of {{valueMap(true)}}. When that did happen in GraphSON 2.0, {{T}} > values were simply converted to string. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Created] (TINKERPOP-1866) Support g:T for .NET
stephen mallette created TINKERPOP-1866: --- Summary: Support g:T for .NET Key: TINKERPOP-1866 URL: https://issues.apache.org/jira/browse/TINKERPOP-1866 Project: TinkerPop Issue Type: Improvement Components: dotnet Affects Versions: 3.3.1 Reporter: stephen mallette Assignee: Jorge Bay Priority: Critical We didn't have tests for return of {{T}} which can occur with {{valueMap(true)}} - adding them on TINKERPOP-1860 exposed the failure in .NET. This may or may not be an issue for GraphSON 3.0 only. In GraphSON 2.0, {{g:T}} is a defined type, but it is typically not returned from the server outside of {{valueMap(true)}}. When that did happen in GraphSON 2.0, {{T}} values were simply converted to string. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Created] (TINKERPOP-1865) Run Gremlin .NET GLV tests wit GraphSON 3.0
stephen mallette created TINKERPOP-1865: --- Summary: Run Gremlin .NET GLV tests wit GraphSON 3.0 Key: TINKERPOP-1865 URL: https://issues.apache.org/jira/browse/TINKERPOP-1865 Project: TinkerPop Issue Type: Improvement Components: dotnet Affects Versions: 3.3.1 Reporter: stephen mallette Assignee: Jorge Bay GLV tests currently run for GraphSON 2.0 with .NET - they should be running for 3.0 especially on the 3.3.x line of code. Ideally we should probably run tests for both versions, but perhaps that is a separate issue at this point as it is for Python on TINKERPOP-1864 -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (TINKERPOP-1863) Delaying the setting of requestId till the RequestMessage instantiation time
[ https://issues.apache.org/jira/browse/TINKERPOP-1863?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=1631#comment-1631 ] ASF GitHub Bot commented on TINKERPOP-1863: --- Github user spmallette commented on the issue: https://github.com/apache/tinkerpop/pull/771 Thanks @EugeneChung - as this was minor change that was discussed on the dev mailing list already I decided to just CTR and merge it without further votes. I updated the CHANGELOG and made a minor tweak to the equality check for null: https://github.com/apache/tinkerpop/commit/c4b0f9de04fda08db5b6b03a91ba58f3def0217a > Delaying the setting of requestId till the RequestMessage instantiation time > > > Key: TINKERPOP-1863 > URL: https://issues.apache.org/jira/browse/TINKERPOP-1863 > Project: TinkerPop > Issue Type: Improvement > Components: driver >Reporter: Eugene Chung >Priority: Minor > > The Builder class of > org.apache.tinkerpop.gremlin.driver.message.RequestMessage class sets its > requestId field as UUID.randomUUID() by default. > But I think it should be fixed not to be set by default. The reasons are > below; > - UUID.randomUUID() uses SecureRandom which grabs the lock at JVM level, > which means whole threads calling this API compete against each other. > - Getting random value from SecureRandom is somewhat CPU-intensive job. > - If a gremlin client sends requestId by itself, the costs above are useless. > https://lists.apache.org/thread.html/a7e6cfeadad10852a2deed8616e47df6738c13c47119c12f98dcd3e1@%3Cdev.tinkerpop.apache.org%3E -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[GitHub] tinkerpop issue #771: TINKERPOP-1863 Delaying the setting of requestId till ...
Github user spmallette commented on the issue: https://github.com/apache/tinkerpop/pull/771 Thanks @EugeneChung - as this was minor change that was discussed on the dev mailing list already I decided to just CTR and merge it without further votes. I updated the CHANGELOG and made a minor tweak to the equality check for null: https://github.com/apache/tinkerpop/commit/c4b0f9de04fda08db5b6b03a91ba58f3def0217a ---
[jira] [Commented] (TINKERPOP-1863) Delaying the setting of requestId till the RequestMessage instantiation time
[ https://issues.apache.org/jira/browse/TINKERPOP-1863?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16316657#comment-16316657 ] ASF GitHub Bot commented on TINKERPOP-1863: --- Github user asfgit closed the pull request at: https://github.com/apache/tinkerpop/pull/771 > Delaying the setting of requestId till the RequestMessage instantiation time > > > Key: TINKERPOP-1863 > URL: https://issues.apache.org/jira/browse/TINKERPOP-1863 > Project: TinkerPop > Issue Type: Improvement > Components: driver >Reporter: Eugene Chung >Priority: Minor > > The Builder class of > org.apache.tinkerpop.gremlin.driver.message.RequestMessage class sets its > requestId field as UUID.randomUUID() by default. > But I think it should be fixed not to be set by default. The reasons are > below; > - UUID.randomUUID() uses SecureRandom which grabs the lock at JVM level, > which means whole threads calling this API compete against each other. > - Getting random value from SecureRandom is somewhat CPU-intensive job. > - If a gremlin client sends requestId by itself, the costs above are useless. > https://lists.apache.org/thread.html/a7e6cfeadad10852a2deed8616e47df6738c13c47119c12f98dcd3e1@%3Cdev.tinkerpop.apache.org%3E -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[GitHub] tinkerpop pull request #771: TINKERPOP-1863 Delaying the setting of requestI...
Github user asfgit closed the pull request at: https://github.com/apache/tinkerpop/pull/771 ---
[GitHub] tinkerpop issue #767: TINKERPOP-1858: HttpChannelizer Regression: Does not c...
Github user spmallette commented on the issue: https://github.com/apache/tinkerpop/pull/767 I'm getting test failures when running Gremlin Server integration tests. @krlohnes is that a problem for you? ---
[jira] [Commented] (TINKERPOP-1858) HttpChannelizer regression: Does not create specified AuthenticationHandler
[ https://issues.apache.org/jira/browse/TINKERPOP-1858?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16316552#comment-16316552 ] ASF GitHub Bot commented on TINKERPOP-1858: --- Github user spmallette commented on the issue: https://github.com/apache/tinkerpop/pull/767 I'm getting test failures when running Gremlin Server integration tests. @krlohnes is that a problem for you? > HttpChannelizer regression: Does not create specified AuthenticationHandler > --- > > Key: TINKERPOP-1858 > URL: https://issues.apache.org/jira/browse/TINKERPOP-1858 > Project: TinkerPop > Issue Type: Bug > Components: server >Affects Versions: 3.3.0 > Environment: All >Reporter: Keith Lohnes > Labels: easyfix, regression > Original Estimate: 1h > Remaining Estimate: 1h > > HttpChannelizer creates a HttpBasicAuthenticationHandler instead of > instantiating the specified AuthenticationHandler from the configuration -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (TINKERPOP-1447) Add some JavaScript intelligence to the documentation so that comments and output are not copied in a copy paste
[ https://issues.apache.org/jira/browse/TINKERPOP-1447?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16316460#comment-16316460 ] ASF GitHub Bot commented on TINKERPOP-1447: --- Github user robertdale commented on the issue: https://github.com/apache/tinkerpop/pull/766 @spmallette did you save your console log? > Add some JavaScript intelligence to the documentation so that comments and > output are not copied in a copy paste > > > Key: TINKERPOP-1447 > URL: https://issues.apache.org/jira/browse/TINKERPOP-1447 > Project: TinkerPop > Issue Type: Improvement > Components: documentation >Affects Versions: 3.1.4, 3.2.2 >Reporter: Marko A. Rodriguez > > [~rjbriody] was saying that it is possible to have it such that when you > copy/paste the following: > {code} > gremlin> g.V().out("created") // and example <1> > ==>blah > {code} > only {{g.V().out("created")}} is put into the clipboard. I believe he said it > was via some JavaScript magic --- beyond me, but it would be cool if we did > this. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[GitHub] tinkerpop issue #766: TINKERPOP-1447 Add some JavaScript intelligence to the...
Github user robertdale commented on the issue: https://github.com/apache/tinkerpop/pull/766 @spmallette did you save your console log? ---
[jira] [Commented] (TINKERPOP-1863) Delaying the setting of requestId till the RequestMessage instantiation time
[ https://issues.apache.org/jira/browse/TINKERPOP-1863?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16316385#comment-16316385 ] ASF GitHub Bot commented on TINKERPOP-1863: --- Github user robertdale commented on the issue: https://github.com/apache/tinkerpop/pull/771 VOTE +1 > Delaying the setting of requestId till the RequestMessage instantiation time > > > Key: TINKERPOP-1863 > URL: https://issues.apache.org/jira/browse/TINKERPOP-1863 > Project: TinkerPop > Issue Type: Improvement > Components: driver >Reporter: Eugene Chung >Priority: Minor > > The Builder class of > org.apache.tinkerpop.gremlin.driver.message.RequestMessage class sets its > requestId field as UUID.randomUUID() by default. > But I think it should be fixed not to be set by default. The reasons are > below; > - UUID.randomUUID() uses SecureRandom which grabs the lock at JVM level, > which means whole threads calling this API compete against each other. > - Getting random value from SecureRandom is somewhat CPU-intensive job. > - If a gremlin client sends requestId by itself, the costs above are useless. > https://lists.apache.org/thread.html/a7e6cfeadad10852a2deed8616e47df6738c13c47119c12f98dcd3e1@%3Cdev.tinkerpop.apache.org%3E -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[GitHub] tinkerpop issue #771: TINKERPOP-1863 Delaying the setting of requestId till ...
Github user robertdale commented on the issue: https://github.com/apache/tinkerpop/pull/771 VOTE +1 ---
[jira] [Created] (TINKERPOP-1864) Gremlin Python tests for GraphSON 2.0 and 3.0
stephen mallette created TINKERPOP-1864: --- Summary: Gremlin Python tests for GraphSON 2.0 and 3.0 Key: TINKERPOP-1864 URL: https://issues.apache.org/jira/browse/TINKERPOP-1864 Project: TinkerPop Issue Type: Improvement Components: python Affects Versions: 3.3.1 Reporter: stephen mallette Priority: Minor With TINKERPOP-1844 gremlin-python tests no longer run against GraphSON 2.0. They only run against 3.0. It would be good to include runs against 2.0 as well - that will come with some challenges because there are tests that simply can't run against 2.0 given its limitations. To some degree, we do get some confidence that 2.0 still works as the 3.2.x tests still run 2.0 and will continue to do so. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (TINKERPOP-1844) Python GLV test should run for GraphSON 3.0
[ https://issues.apache.org/jira/browse/TINKERPOP-1844?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16316232#comment-16316232 ] ASF GitHub Bot commented on TINKERPOP-1844: --- Github user asfgit closed the pull request at: https://github.com/apache/tinkerpop/pull/769 > Python GLV test should run for GraphSON 3.0 > --- > > Key: TINKERPOP-1844 > URL: https://issues.apache.org/jira/browse/TINKERPOP-1844 > Project: TinkerPop > Issue Type: Improvement > Components: python >Affects Versions: 3.3.0 >Reporter: stephen mallette >Priority: Critical > Labels: breaking > Fix For: 3.3.2 > > > The GLV tests are running for python on GraphSON 2.0. When I ran them for > GraphSON 3.0 I received some strange errors that looked like they might have > been related to bulking, but I can't say for sure. Anyway, we should > definitely be running these tests against 3.0 and potentially 2.0 as well > (2.0 can be a separate ticket and is less of a priority). -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Closed] (TINKERPOP-1844) Python GLV test should run for GraphSON 3.0
[ https://issues.apache.org/jira/browse/TINKERPOP-1844?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] stephen mallette closed TINKERPOP-1844. --- Resolution: Done Assignee: stephen mallette Fix Version/s: 3.3.2 > Python GLV test should run for GraphSON 3.0 > --- > > Key: TINKERPOP-1844 > URL: https://issues.apache.org/jira/browse/TINKERPOP-1844 > Project: TinkerPop > Issue Type: Improvement > Components: python >Affects Versions: 3.3.0 >Reporter: stephen mallette >Assignee: stephen mallette >Priority: Critical > Labels: breaking > Fix For: 3.3.2 > > > The GLV tests are running for python on GraphSON 2.0. When I ran them for > GraphSON 3.0 I received some strange errors that looked like they might have > been related to bulking, but I can't say for sure. Anyway, we should > definitely be running these tests against 3.0 and potentially 2.0 as well > (2.0 can be a separate ticket and is less of a priority). -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[GitHub] tinkerpop pull request #769: TINKERPOP-1844 Default GraphSON 3.0 for GLV tes...
Github user asfgit closed the pull request at: https://github.com/apache/tinkerpop/pull/769 ---
[GitHub] tinkerpop issue #695: TINKERPOP-1489 JavaScript GLV
Github user jorgebay commented on the issue: https://github.com/apache/tinkerpop/pull/695 I've addressed the comments made by @spmallette: - I've included sections on the `development-environment.asciidoc` file for js environment and info for the release managers. - Moved generation to a groovy file. ---
[jira] [Commented] (TINKERPOP-1489) Provide a Javascript Gremlin Language Variant
[ https://issues.apache.org/jira/browse/TINKERPOP-1489?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16316126#comment-16316126 ] ASF GitHub Bot commented on TINKERPOP-1489: --- Github user jorgebay commented on a diff in the pull request: https://github.com/apache/tinkerpop/pull/695#discussion_r160120074 --- Diff: gremlin-javascript/src/main/javascript/gremlin-javascript/package.json --- @@ -0,0 +1,39 @@ +{ + "name": "gremlin-javascript", + "version": "3.2.7-alpha1", --- End diff -- I've used `alpha` to avoid messing up in case it was accidentally pushed while testing the pull request. The version suffix is added in the `determineVersion()` method of the `generation.groovy` file. > Provide a Javascript Gremlin Language Variant > - > > Key: TINKERPOP-1489 > URL: https://issues.apache.org/jira/browse/TINKERPOP-1489 > Project: TinkerPop > Issue Type: Improvement > Components: javascript >Affects Versions: 3.2.5 >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.4.14#64029)
[jira] [Commented] (TINKERPOP-1489) Provide a Javascript Gremlin Language Variant
[ https://issues.apache.org/jira/browse/TINKERPOP-1489?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16316127#comment-16316127 ] ASF GitHub Bot commented on TINKERPOP-1489: --- Github user jorgebay commented on the issue: https://github.com/apache/tinkerpop/pull/695 I've addressed the comments made by @spmallette: - I've included sections on the `development-environment.asciidoc` file for js environment and info for the release managers. - Moved generation to a groovy file. > Provide a Javascript Gremlin Language Variant > - > > Key: TINKERPOP-1489 > URL: https://issues.apache.org/jira/browse/TINKERPOP-1489 > Project: TinkerPop > Issue Type: Improvement > Components: javascript >Affects Versions: 3.2.5 >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.4.14#64029)
[GitHub] tinkerpop pull request #695: TINKERPOP-1489 JavaScript GLV
Github user jorgebay commented on a diff in the pull request: https://github.com/apache/tinkerpop/pull/695#discussion_r160120074 --- Diff: gremlin-javascript/src/main/javascript/gremlin-javascript/package.json --- @@ -0,0 +1,39 @@ +{ + "name": "gremlin-javascript", + "version": "3.2.7-alpha1", --- End diff -- I've used `alpha` to avoid messing up in case it was accidentally pushed while testing the pull request. The version suffix is added in the `determineVersion()` method of the `generation.groovy` file. ---