[jira] [Commented] (TINKERPOP-1867) union() can produce extra traversers

[Daniel Kuppitz (JIRA)]

[ 
https://issues.apache.org/jira/browse/TINKERPOP-1867?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=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

[ASF GitHub Bot (JIRA)]

[ 
https://issues.apache.org/jira/browse/TINKERPOP-1861?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=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 ...

[PBGraff]

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 (JIRA)]

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)

[GitHub] tinkerpop pull request #768: TINKERPOP-1861 Modify VertexProgram.Builder.cre...

[PBGraff]

Github user PBGraff closed the pull request at:

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


---

[jira] [Commented] (TINKERPOP-1861) VertexProgram create with varargs for Graphs

[ASF GitHub Bot (JIRA)]

[ 
https://issues.apache.org/jira/browse/TINKERPOP-1861?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=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)

[jira] [Commented] (TINKERPOP-1447) Add some JavaScript intelligence to the documentation so that comments and output are not copied in a copy paste

[ASF GitHub Bot (JIRA)]

[ 
https://issues.apache.org/jira/browse/TINKERPOP-1447?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=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...

[spmallette]

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

[ASF GitHub Bot (JIRA)]

[ 
https://issues.apache.org/jira/browse/TINKERPOP-1861?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=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...

[spmallette]

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

[stephen mallette (JIRA)]

[ 
https://issues.apache.org/jira/browse/TINKERPOP-1866?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=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

[Jorge Bay (JIRA)]

[ 
https://issues.apache.org/jira/browse/TINKERPOP-1866?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=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 (JIRA)]

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 (JIRA)]

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

[ASF GitHub Bot (JIRA)]

[ 
https://issues.apache.org/jira/browse/TINKERPOP-1863?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=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 ...

[spmallette]

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

[ASF GitHub Bot (JIRA)]

[ 
https://issues.apache.org/jira/browse/TINKERPOP-1863?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=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...

[asfgit]

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

[spmallette]

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

[ASF GitHub Bot (JIRA)]

[ 
https://issues.apache.org/jira/browse/TINKERPOP-1858?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=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)

[GitHub] tinkerpop issue #766: TINKERPOP-1447 Add some JavaScript intelligence to the...

[robertdale]

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

[ASF GitHub Bot (JIRA)]

[ 
https://issues.apache.org/jira/browse/TINKERPOP-1863?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=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 ...

[robertdale]

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 (JIRA)]

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

[ASF GitHub Bot (JIRA)]

[ 
https://issues.apache.org/jira/browse/TINKERPOP-1844?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=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

[stephen mallette (JIRA)]

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

[asfgit]

Github user asfgit closed the pull request at:

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


---

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

[GitHub] tinkerpop issue #695: TINKERPOP-1489 JavaScript GLV

[jorgebay]

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

[ASF GitHub Bot (JIRA)]

[ 
https://issues.apache.org/jira/browse/TINKERPOP-1489?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=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

[jorgebay]

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.


---