[DISCUSS] deprecation label

[Stephen Mallette]

I don't like how I proposed to use the "deprecation" label a while back.
It's not helpful. You can read what I wrote here if you feel like it:

http://tinkerpop.apache.org/docs/current/dev/developer/#_deprecation

Anyway, I think it would be better if "deprecation" referred to the tickets
that were actually representing the deprecation of something and not the
act of removing deprecation. The idea would be that for every "deprecation"
ticket, there would likely be a "deprecation removal" ticket that had the
"breaking" label. That would be way more useful.

I'll assume lazy consensus after 72 hours and go through and do some JIRA
cleanup in this fashion and update the dev docs unless there are objections.

[DISCUSS] Deprecate useMapperFromGraph

[Stephen Mallette]

This might be in the weeds for most folks, but the useMapperFromGraph
setting in the Gremlin Server configuration file is something allowed by
the serializers which let's you specify a configured graph to use to build
a Mapper from that a specific serializer will use. The idea was that
serializers could just get their configurations directly from a Graph
instance which would bring any custom serializer stuff into Gremlin Server.
The problem is that if there are multiple types of graphs then the
serializers can only be configured to work with one of them.

This problem was long ago remedied with the introduction of a configuration
option for serializers which would take an IoRegistry implementation
directly thus allowing the user to specify multiple registries for the same
serializer.  I think that's ultimately the way going forward so
userMapperFromGraph is a bit of an anti-pattern we are still supporting.

I'd like to deprecate this feature for 3.2.6 on this ticket:

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

and then remove it completely in 3.3.0. I'll assume lazy consensus after 72
hours and proceed.

Thanks,

Stephen

[jira] [Created] (TINKERPOP-1694) Deprecate useMapperFromGraph

[stephen mallette (JIRA)]

stephen mallette created TINKERPOP-1694:
---

 Summary: Deprecate useMapperFromGraph
 Key: TINKERPOP-1694
 URL: https://issues.apache.org/jira/browse/TINKERPOP-1694
 Project: TinkerPop
  Issue Type: Improvement
  Components: server
Affects Versions: 3.2.5
Reporter: stephen mallette
Assignee: stephen mallette
Priority: Minor


Deprecate useMapperFromGraph



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Commented] (TINKERPOP-1688) Include TraversalMetrics annotation in pretty print

[ASF GitHub Bot (JIRA)]

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

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

Github user spmallette commented on the issue:

https://github.com/apache/tinkerpop/pull/635
  
+1 for non-binding votes @nastra  - thanks :smile: 


> Include TraversalMetrics annotation in pretty print
> ---
>
> Key: TINKERPOP-1688
> URL: https://issues.apache.org/jira/browse/TINKERPOP-1688
> Project: TinkerPop
>  Issue Type: Improvement
>  Components: process
>Affects Versions: 3.2.4
>Reporter: stephen mallette
>Assignee: stephen mallette
>
> Currently annotations on metrics are not displayed when you view the results 
> of a {{profile()}} via {{toString()}}. Including annotations might provide 
> important information to users that would otherwise be hidden or force the 
> user to manually pick apart the {{TraversalMetrics}} object itself which 
> isn't convenient.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[GitHub] tinkerpop issue #635: TINKERPOP-1688 Add annotations to TraversalMetrics pre...

[spmallette]

Github user spmallette commented on the issue:

https://github.com/apache/tinkerpop/pull/635
  
+1 for non-binding votes @nastra  - thanks :smile: 


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

Re: [TinkerPop] Re: Docker images: gremlin-server and gremlin-console

[Stephen Mallette]

I really don't know Docker too well so I can't really drive this one. I'm
not sure I understand if what Apache is offering us is suitable for the
needs TinkerPop has wrt Docker. Any volunteers willing to pick this up and
drive this discussion forward?



On Tue, Jun 13, 2017 at 4:26 PM, Stephen Mallette 
wrote:

> With help from Humbedooh aka Daniel Gruno, I've got in contact with folks
> at Apache Infrastructure regarding projects putting stuff on Docker Hub.
> Here was the basic reply:
>
> > We do support the use of Docker Hub under the ASF banner:
> > https://hub.docker.com/u/apache/
> > The policy for releases on there is still being worked out, but at
> > this moment if you have a dockerfile/ repo we can add that to our org
> > for automated building.
> > Just file a ticket on the INFRA JIRA
> > https://issues.apache.org/jira/secure/RapidBoard.jspa?rapi
> dView=25=INFRA
> > and we can add that repo to the org.
>
> Is that helpful for what we're talking about here? Are there other
> questions to ask?
>
>
>
> On Thu, Jun 8, 2017 at 2:36 AM, Florian Hockmann 
> wrote:
>
>> I think official images would be a very good idea as there exist
>> currently a lot of images, especially for Gremlin Server. Users typically
>> search for the official image or just take the image with the most pulls.
>> Images published directly by TinkerPop would get the most attention so
>> users don't end up with some image that isn't actively maintained.
>>
>> Another advantage of integrating the images in TinkerPop would probably
>> be that the deployment could be integrated into TinkerPop's usual release
>> cycle. So new images can be published directly for each new version.
>>
>> Am Dienstag, 6. Juni 2017 18:39:09 UTC+2 schrieb Stephen Mallette:
>>>
>>> Would it be interesting to anyone for TinkerPop to have an official
>>> docker image?
>>>
>>> On Tue, Jun 6, 2017 at 12:22 PM, Benjamin Ricaud 
>>> wrote:
>>>
 Thanks Jean-Baptiste,

 I have also done a container for the gremlin-server 3.2.4, configured
 to be used with gremlin-python:
 https://hub.docker.com/r/bricaud/gremlin-server/

 I noticed that you do not need the IP trick for the server to be
 accessed. If you set
 host: 0
 in your gremlin-conf.yaml, (and open the port with -p 8182:8182) you
 can access the server.
 (see my conf files on the github repo).

 Best,
 Benjamin

 Le jeudi 1 juin 2017 00:37:07 UTC+2, Jean-Baptiste Musso a écrit :
>
> Dear TinkerPop,
>
> I published a couple automatically built Docker images for
> gremlin-server and gremlin-console (current image tags: latest, 3.2.4, 3.2
> and 3):
>
> https://hub.docker.com/r/jbmusso/gremlin-server/
> https://hub.docker.com/r/jbmusso/gremlin-console/
>
> I built these because I needed to quickly start different
> configurations of gremlin-server when developing the gremlin-javascript
> client.
> Source repository: https://github.com/jbmusso/docker-tinkerpop
>
>
> Start gremlin-server with:
>
> docker run -p 8182:8182 jbmusso/gremlin-server:3.2.4
>
>
> Defaults to conf/gremlin-server.yaml within that container, or pass
> another .yaml file:
>
> docker run -p 8182:8182 jbmusso/gremlin-server:3.2.4
> conf/gremlin-server-modern.yaml
>
>
> Mounting your own config .yaml file with docker run -v argument should
> also work (untested).
>
>
> You can play with the console this way (make sure you run with the -it
> flags so Docker don't quit and actually lets you type commands from your
> shell):
>
> docker run -it jbmusso/gremlin-console:3.2.4
>
>
> If you want to execute a file located on your host from within a
> gremin-console container (the following assumes that foobar.groovy file
> exists in your $HOME dir):
>
> docker run -it -v ~/foobar.groovy:/script/foobar.groovy
> jbmusso/gremlin-console:3.2.4 -e /script/foobar.groovy
>
>
>
>
> Jean-Baptiste
>
> --
 You received this message because you are subscribed to the Google
 Groups "Gremlin-users" group.
 To unsubscribe from this group and stop receiving emails from it, send
 an email to gremlin-user...@googlegroups.com.
 To view this discussion on the web visit https://groups.google.com/d/ms
 gid/gremlin-users/c8141999-2e9d-4fd3-a763-5630866e5c6b%40goo
 glegroups.com
 
 .

 For more options, visit https://groups.google.com/d/optout.

>>>
>>> --
>> You received this message because you are subscribed to the Google Groups
>> "Gremlin-users" group.
>> To unsubscribe from this group and stop receiving emails from it, send an
>> email to 

[GitHub] tinkerpop issue #635: TINKERPOP-1688 Add annotations to TraversalMetrics pre...

[nastra]

Github user nastra commented on the issue:

https://github.com/apache/tinkerpop/pull/635
  
VOTE +1 (non-binding)


---
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-1688) Include TraversalMetrics annotation in pretty print

[ASF GitHub Bot (JIRA)]

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

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

Github user nastra commented on the issue:

https://github.com/apache/tinkerpop/pull/635
  
VOTE +1 (non-binding)


> Include TraversalMetrics annotation in pretty print
> ---
>
> Key: TINKERPOP-1688
> URL: https://issues.apache.org/jira/browse/TINKERPOP-1688
> Project: TinkerPop
>  Issue Type: Improvement
>  Components: process
>Affects Versions: 3.2.4
>Reporter: stephen mallette
>Assignee: stephen mallette
>
> Currently annotations on metrics are not displayed when you view the results 
> of a {{profile()}} via {{toString()}}. Including annotations might provide 
> important information to users that would otherwise be hidden or force the 
> user to manually pick apart the {{TraversalMetrics}} object itself which 
> isn't convenient.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Commented] (TINKERPOP-915) Gremlin Server supports REST and Websockets simultanteously

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on TINKERPOP-915:
--

Github user spmallette commented on the issue:

https://github.com/apache/tinkerpop/pull/618
  
ok - let me think about it a bit before you write too much code in any 
particular direction. we'll also give others some time to chime in in case they 
have an opinion.


> Gremlin Server supports REST and Websockets simultanteously
> ---
>
> Key: TINKERPOP-915
> URL: https://issues.apache.org/jira/browse/TINKERPOP-915
> Project: TinkerPop
>  Issue Type: Improvement
>  Components: server
>Affects Versions: 3.0.2-incubating
>Reporter: stephen mallette
>
> Develop a {{Channelizer}} that allows REST and Websockets to be configured at 
> the same time.  I've personally tried to do this on a couple of attempts 
> while following a Netty sample, but I've never been able to get it to work.  
> Perhaps folks like [~pluradj] or [~dmill] would like to give it a go some 
> day? :)



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[GitHub] tinkerpop issue #618: TINKERPOP-915 Add combined handler for Http and Websoc...

[spmallette]

Github user spmallette commented on the issue:

https://github.com/apache/tinkerpop/pull/618
  
ok - let me think about it a bit before you write too much code in any 
particular direction. we'll also give others some time to chime in in case they 
have an opinion.


---
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-915) Gremlin Server supports REST and Websockets simultanteously

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on TINKERPOP-915:
--

Github user krlohnes commented on the issue:

https://github.com/apache/tinkerpop/pull/618
  
My change can be summed up by 

"Setup the WebSocket stuff and insert the `GremlinEndpointHandler` into the 
`ChannelPipeline` to serve Http requests when necessary"

Changes to the `WebSocketChannelizer` and `SaslAuthenticationHandler` would 
likely be picked up easily enough by simply using the combined channelizer. If 
there was an issue with the `HttpChannelizer`, it may not be picked up by those 
tests.

Running all of the tests from both was mostly for my own sanity. I wanted 
to make sure I wasn't missing something.

If you're thinking about minimizing impact from extra tests running in the 
TP suite, I'd probably suggest running the combined channelizer on WS tests and 
both on `GremlinServerHttpIntegrateTest`. 


> Gremlin Server supports REST and Websockets simultanteously
> ---
>
> Key: TINKERPOP-915
> URL: https://issues.apache.org/jira/browse/TINKERPOP-915
> Project: TinkerPop
>  Issue Type: Improvement
>  Components: server
>Affects Versions: 3.0.2-incubating
>Reporter: stephen mallette
>
> Develop a {{Channelizer}} that allows REST and Websockets to be configured at 
> the same time.  I've personally tried to do this on a couple of attempts 
> while following a Netty sample, but I've never been able to get it to work.  
> Perhaps folks like [~pluradj] or [~dmill] would like to give it a go some 
> day? :)



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[GitHub] tinkerpop issue #618: TINKERPOP-915 Add combined handler for Http and Websoc...

[krlohnes]

Github user krlohnes commented on the issue:

https://github.com/apache/tinkerpop/pull/618
  
My change can be summed up by 

"Setup the WebSocket stuff and insert the `GremlinEndpointHandler` into the 
`ChannelPipeline` to serve Http requests when necessary"

Changes to the `WebSocketChannelizer` and `SaslAuthenticationHandler` would 
likely be picked up easily enough by simply using the combined channelizer. If 
there was an issue with the `HttpChannelizer`, it may not be picked up by those 
tests.

Running all of the tests from both was mostly for my own sanity. I wanted 
to make sure I wasn't missing something.

If you're thinking about minimizing impact from extra tests running in the 
TP suite, I'd probably suggest running the combined channelizer on WS tests and 
both on `GremlinServerHttpIntegrateTest`. 


---
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-915) Gremlin Server supports REST and Websockets simultanteously

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on TINKERPOP-915:
--

Github user spmallette commented on the issue:

https://github.com/apache/tinkerpop/pull/618
  
Not sure how I feel about it but just throwing stuff out there to think 
aboutAnother option might be to just have a smoke test for the combined 
channelizer? or maybe all tests should run over your combined channelizer and 
we just need smoke tests for the specific ones? do you feel like smoke tests 
are too risky given your changes? Do we need to re-test all functionality over 
all the channelizers?


> Gremlin Server supports REST and Websockets simultanteously
> ---
>
> Key: TINKERPOP-915
> URL: https://issues.apache.org/jira/browse/TINKERPOP-915
> Project: TinkerPop
>  Issue Type: Improvement
>  Components: server
>Affects Versions: 3.0.2-incubating
>Reporter: stephen mallette
>
> Develop a {{Channelizer}} that allows REST and Websockets to be configured at 
> the same time.  I've personally tried to do this on a couple of attempts 
> while following a Netty sample, but I've never been able to get it to work.  
> Perhaps folks like [~pluradj] or [~dmill] would like to give it a go some 
> day? :)



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[GitHub] tinkerpop issue #618: TINKERPOP-915 Add combined handler for Http and Websoc...

[spmallette]

Github user spmallette commented on the issue:

https://github.com/apache/tinkerpop/pull/618
  
Not sure how I feel about it but just throwing stuff out there to think 
aboutAnother option might be to just have a smoke test for the combined 
channelizer? or maybe all tests should run over your combined channelizer and 
we just need smoke tests for the specific ones? do you feel like smoke tests 
are too risky given your changes? Do we need to re-test all functionality over 
all the channelizers?


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

TinkerPop 3.1.7 Released: A 187 On The Undercover Gremlinz

[Ted Wilmes]

Hello,

TinkerPop 3.1.7 has just been released. This maintenance release contains a
number of bug fixes on the "Undercover Gremlinz" release line and should be
non-breaking for your upgrade needs.

The release artifacts can be found at this location:

https://www.apache.org/dyn/closer.lua/tinkerpop/3.1.7/apache-tinkerpop-gremlin-console-3.1.7-bin.zip
https://www.apache.org/dyn/closer.lua/tinkerpop/3.1.7/apache-tinkerpop-gremlin-server-3.1.7-bin.zip

The online docs can be found here:

http://tinkerpop.apache.org/docs/3.1.7/reference/ (user docs)
http://tinkerpop.apache.org/docs/3.1.7/upgrade/#_tinkerpop_3_1_7 (upgrade
docs)
http://tinkerpop.apache.org/javadocs/3.1.7/core/ (core javadoc)
http://tinkerpop.apache.org/javadocs/3.1.7/full/ (full javadoc)

The release notes are available here:

https://github.com/apache/tinkerpop/blob/3.1.7/CHANGELOG.asciidoc

The Central Maven repo has sync'd as well:

https://repo1.maven.org/maven2/org/apache/tinkerpop/tinkerpop/3.1.7/

Enjoy!

[jira] [Commented] (TINKERPOP-915) Gremlin Server supports REST and Websockets simultanteously

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on TINKERPOP-915:
--

Github user krlohnes commented on the issue:

https://github.com/apache/tinkerpop/pull/618
  
I can probably figure something out with JUnit `Parameters` for the 
`GremlinServerIntegrateTest` and `GremlinServerHttpIntegrateTest`. I'll have a 
go at it.  


> Gremlin Server supports REST and Websockets simultanteously
> ---
>
> Key: TINKERPOP-915
> URL: https://issues.apache.org/jira/browse/TINKERPOP-915
> Project: TinkerPop
>  Issue Type: Improvement
>  Components: server
>Affects Versions: 3.0.2-incubating
>Reporter: stephen mallette
>
> Develop a {{Channelizer}} that allows REST and Websockets to be configured at 
> the same time.  I've personally tried to do this on a couple of attempts 
> while following a Netty sample, but I've never been able to get it to work.  
> Perhaps folks like [~pluradj] or [~dmill] would like to give it a go some 
> day? :)



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[GitHub] tinkerpop issue #618: TINKERPOP-915 Add combined handler for Http and Websoc...

[krlohnes]

Github user krlohnes commented on the issue:

https://github.com/apache/tinkerpop/pull/618
  
I can probably figure something out with JUnit `Parameters` for the 
`GremlinServerIntegrateTest` and `GremlinServerHttpIntegrateTest`. I'll have a 
go at 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.
---

TinkerPop 3.2.5 Released: Nine Inch Gremlins

[Stephen Mallette]

Hello,

TinkerPop 3.2.5 has just been released. This release contains a number of
bug fixes and enhancements which are described in the Upgrade Documentation
below. Of special note, in this release, is the official recommendation for
how to develop Gremlin-based DSLs:

http://tinkerpop.apache.org/docs/3.2.5/reference/#dsl

The release artifacts can be found at this location:

https://www.apache.org/dyn/closer.lua/tinkerpop/3.2.5/
apache-tinkerpop-gremlin-console-3.2.5-bin.zip
https://www.apache.org/dyn/closer.lua/tinkerpop/3.2.5/
apache-tinkerpop-gremlin-server-3.2.5-bin.zip

The online docs can be found here:

http://tinkerpop.apache.org/docs/3.2.5/reference/ (user docs)
http://tinkerpop.apache.org/docs/3.2.5/upgrade/#_tinkerpop_3_2_5 (upgrade
docs)
http://tinkerpop.apache.org/javadocs/3.2.5/core/ (core javadoc)
http://tinkerpop.apache.org/javadocs/3.2.5/full/ (full javadoc)

The release notes are available here:

https://github.com/apache/tinkerpop/blob/3.2.5/CHANGELOG.asciidoc#tinkerpop-
325-release-date-june-12-2017

The Central Maven repo has sync'd as well:

https://repo1.maven.org/maven2/org/apache/tinkerpop/tinkerpop/3.2.5/

Python artifacts have also been deployed to pypi:

https://pypi.python.org/pypi/gremlinpython/3.2.5

[image: Inline image 1]

[jira] [Commented] (TINKERPOP-1688) Include TraversalMetrics annotation in pretty print

[ASF GitHub Bot (JIRA)]

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

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

GitHub user spmallette opened a pull request:

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

TINKERPOP-1688 Add annotations to TraversalMetrics pretty print

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

See the example of what the revised pretty print looks like if annotations 
are present in the metrics in the link to the issue above (it's in the 
comments).

Builds with `mvn clean install`

VOTE +1

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

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

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

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


commit a9f48dfe811039c357d12fac7bd7a93113750d05
Author: Stephen Mallette 
Date:   2017-06-08T16:37:34Z

TINKERPOP-1688 Add annotations to TraversalMetrics pretty print




> Include TraversalMetrics annotation in pretty print
> ---
>
> Key: TINKERPOP-1688
> URL: https://issues.apache.org/jira/browse/TINKERPOP-1688
> Project: TinkerPop
>  Issue Type: Improvement
>  Components: process
>Affects Versions: 3.2.4
>Reporter: stephen mallette
>Assignee: stephen mallette
>
> Currently annotations on metrics are not displayed when you view the results 
> of a {{profile()}} via {{toString()}}. Including annotations might provide 
> important information to users that would otherwise be hidden or force the 
> user to manually pick apart the {{TraversalMetrics}} object itself which 
> isn't convenient.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[GitHub] tinkerpop pull request #635: TINKERPOP-1688 Add annotations to TraversalMetr...

[spmallette]

GitHub user spmallette opened a pull request:

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

TINKERPOP-1688 Add annotations to TraversalMetrics pretty print

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

See the example of what the revised pretty print looks like if annotations 
are present in the metrics in the link to the issue above (it's in the 
comments).

Builds with `mvn clean install`

VOTE +1

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

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

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

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


commit a9f48dfe811039c357d12fac7bd7a93113750d05
Author: Stephen Mallette 
Date:   2017-06-08T16:37:34Z

TINKERPOP-1688 Add annotations to TraversalMetrics pretty print




---
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-915) Gremlin Server supports REST and Websockets simultanteously

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on TINKERPOP-915:
--

Github user spmallette commented on the issue:

https://github.com/apache/tinkerpop/pull/618
  
`GremlinServerWsAndHttpIntegrateTest.java` is a nice validation that all 
the REST tests work and a reasonable portion websockets tests work, but is 
there a nicer way to do that? Under this model, every time we add a new test we 
have to also implement that test method in 
`GremlinServerWsAndHttpIntegrateTest.java`. We're also not really testing all 
functionality of websockets as it only does `GremlinServerIntegrateTest`. 

anyway - any thoughts on a better testing model?


> Gremlin Server supports REST and Websockets simultanteously
> ---
>
> Key: TINKERPOP-915
> URL: https://issues.apache.org/jira/browse/TINKERPOP-915
> Project: TinkerPop
>  Issue Type: Improvement
>  Components: server
>Affects Versions: 3.0.2-incubating
>Reporter: stephen mallette
>
> Develop a {{Channelizer}} that allows REST and Websockets to be configured at 
> the same time.  I've personally tried to do this on a couple of attempts 
> while following a Netty sample, but I've never been able to get it to work.  
> Perhaps folks like [~pluradj] or [~dmill] would like to give it a go some 
> day? :)



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[GitHub] tinkerpop issue #618: TINKERPOP-915 Add combined handler for Http and Websoc...

[spmallette]

Github user spmallette commented on the issue:

https://github.com/apache/tinkerpop/pull/618
  
`GremlinServerWsAndHttpIntegrateTest.java` is a nice validation that all 
the REST tests work and a reasonable portion websockets tests work, but is 
there a nicer way to do that? Under this model, every time we add a new test we 
have to also implement that test method in 
`GremlinServerWsAndHttpIntegrateTest.java`. We're also not really testing all 
functionality of websockets as it only does `GremlinServerIntegrateTest`. 

anyway - any thoughts on a better testing model?


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

Re: Development branch cleanup

[Daniel Kuppitz]

Yea, DEDUPCOUNT can be deleted. Not sure about TINKERPOP3-781
. Where's Matt *"now
that I'm a committer, I will leave you"* Frantz? :) The problem from the
ticket's description still exists; I don't know if there was any progress
made in that branch, but by now the branch is likely pretty useless.


On Mon, Jun 19, 2017 at 6:51 PM, Stephen Mallette 
wrote:

> Can we also get rid of DEDUPCOUNT ? Marko, I think that is one of yours?
> still useful?
>
> And the TINKERPOP3-781-local-aggregation-should-not-destroy-path which is
> super old and likely dead at this point? No activity has occurred on that
> ticket or that branch in forever. Still relevant?
>
> On Mon, Jun 19, 2017 at 12:38 PM, Daniel Kuppitz  wrote:
>
> > The following branches are scheduled for deletion:
> >
> > TINKERPOP-1010 -- [TINKERPOP-1010] Remove deprecated
> credentialsDbLocation
> > for SimpleAuthenticator
> > TINKERPOP-1044 -- [TINKERPOP-1044] ResponseMessage should contain
> > server-side exception name.
> > TINKERPOP-1044-master -- [TINKERPOP-1044] ResponseMessage should contain
> > server-side exception name.
> > TINKERPOP-1095 -- [TINKERPOP-1095] Create a custom ScriptContext
> > TINKERPOP-1303 -- [TINKERPOP-1303] add help for :remote config for Gephi
> > Plugin
> > TINKERPOP-1313 -- [TINKERPOP-1313] Rename RangeByIsCountStrategy
> > TINKERPOP-1387 -- [TINKERPOP-1387] from and to modulators for path steps
> > TINKERPOP-1443 -- [TINKERPOP-1443] Use an API checker during build
> > TINKERPOP-1504 -- [TINKERPOP-1504] MutationListener doesn't provide
> > property key on property additions
> > TINKERPOP-1554 -- [TINKERPOP-1554] has(propertyKey) should have a
> > corresponding step in Gremlin-Java.
> > TINKERPOP-1556 -- [TINKERPOP-1556] Allow Hadoop to run on IPv6 systems
> > TINKERPOP-1577 -- [TINKERPOP-1577] Provide support for Python3 or Python2
> > in the Docker builds.
> > TINKERPOP-1599 -- [TINKERPOP-1599] implement real gremlin-python driver
> > TINKERPOP-1602 -- [TINKERPOP-1602] Support SSL client certificate
> > authentication
> > TINKERPOP-1608 -- [TINKERPOP-1608] TP2-to-TP3 GraphML XSLT
> > TINKERPOP-1612 -- [TINKERPOP-1612] Remove gremlin-groovy-test module
> > TINKERPOP-1612-wip -- [TINKERPOP-1612] Remove gremlin-groovy-test module
> > TINKERPOP-1618 -- [TINKERPOP-1618] Remove groovy dependency from
> > gremlin-python
> > TINKERPOP-1625 -- [TINKERPOP-1625] Improvements to has() related steps
> > TINKERPOP-1626 -- [TINKERPOP-1626] choose() is buggy in OLAP
> > TINKERPOP-1627 -- [TINKERPOP-1627] LazyBarrierStrategy should not append
> an
> > end barrier.
> > TINKERPOP-1631 -- [TINKERPOP-1631] Fix visibility issues with the
> > BindingsGremlinPlugin
> > TINKERPOP-1638 -- [TINKERPOP-1638] count() is optimized away in where()
> > TINKERPOP-1639 -- [TINKERPOP-1639] Support simple String operations
> > TINKERPOP-1640 -- [TINKERPOP-1640] ComputerVerificationStrategy gives
> false
> > errors
> > TINKERPOP-1642 -- [TINKERPOP-1642] Improve performance of mutating
> > traversals
> > TINKERPOP-1644 -- [TINKERPOP-1644] Improve script compilation process and
> > include metrics
> > TINKERPOP-1645 -- [TINKERPOP-1645] Bump to Groovy 2.4.9
> > TINKERPOP-1648 -- [TINKERPOP-1648] XyzPropertyChangedEvent contains
> > incomplete data
> > TINKERPOP-1652 -- [TINKERPOP-1652] Disable PathRetractionStrategy
> strategy
> > if VertexProgramStep has LABELLED_PATH requirement
> > TINKERPOP-1653 -- [TINKERPOP-1653] Allow multiple scripts with arguments
> to
> > be passed to the Console
> > TINKERPOP-1654 -- [TINKERPOP-1654] Upgrade to jackson-databind 2.8.6+ in
> > gremlin-shaded
> > TINKERPOP-1654-tp32 -- [TINKERPOP-1654] Upgrade to jackson-databind
> 2.8.6+
> > in gremlin-shaded
> > TINKERPOP-1659 -- [TINKERPOP-1659] Docker build should use maven
> > settings.xml
> > TINKERPOP-1663 -- [TINKERPOP-1663] Validate a maximum for the number of
> > parameters passed to Gremlin Server
> > TINKERPOP-1665 -- [TINKERPOP-1665] Remove unittest from Gremlin-Python
> > tests
> > TINKERPOP-1668 -- [TINKERPOP-1668] RepeatUnrollStrategy should not
> execute
> > if there is a LoopStep used.
> > TINKERPOP-1673 -- [TINKERPOP-1673] GroovyTranslator produces Gremlin that
> > can't execute on :remote
> > TINKERPOP-1676 -- [TINKERPOP-1676] Improve GraphSON 2.0 Performance
> > TINKERPOP-1676-master -- [TINKERPOP-1676] Improve GraphSON 2.0
> Performance
> > TINKERPOP-1678 -- [TINKERPOP-1678] until(Predicate) is actually calling
> > emit(Predicate)
> > TINKERPOP-1681 -- [TINKERPOP-1681] Multiple hasId's are or'd into
> GraphStep
> > TINKERPOP-786 -- [TINKERPOP-786] Patterns for DSL Development
> >
> > If there are no objections, I will delete those branches at the end of
> this
> > week.
> >
> > Cheers,
> > Daniel
> >
>

[GitHub] tinkerpop issue #630: Restore 5 second cutoff time in TraversalInterruptionC...

[spmallette]

Github user spmallette commented on the issue:

https://github.com/apache/tinkerpop/pull/630
  
Thanks - hopefully 5 seconds will suffice. I suppose this time limit is 
more of a failsafe to prevent the test from hanging indefinitely so it could be 
bigger if a graph needed longer iteration time for some reason.


---
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 #630: Restore 5 second cutoff time in TraversalInterr...

[asfgit]

Github user asfgit closed the pull request at:

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


---
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 #633: TINKERPOP-741 (master) Removed deprecated transaction ...

[spmallette]

Github user spmallette commented on the issue:

https://github.com/apache/tinkerpop/pull/633
  
The travis failure is on a timed test unrelated to this change.


---
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-741) Remove Options For Transaction Retry

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on TINKERPOP-741:
--

GitHub user spmallette opened a pull request:

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

TINKERPOP-741 Deprecated Transaction.submit(Function)

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

Deprecated  methods related to transaction retry in preparation for removal 
in 3.3.0.  Builds with `mvn clean install`.

VOTE +1

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

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

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

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


commit eba0a2c0a3dbb8ea1bb4d5358b8c7445cad15c85
Author: Stephen Mallette 
Date:   2017-06-19T15:45:32Z

TINKERPOP-741 Deprecated Transaction.submit(Function)




> Remove Options For Transaction Retry
> 
>
> Key: TINKERPOP-741
> URL: https://issues.apache.org/jira/browse/TINKERPOP-741
> Project: TinkerPop
>  Issue Type: Improvement
>  Components: structure
>Affects Versions: 3.0.2-incubating
>Reporter: stephen mallette
>
> Submitting a transactional workload for automatic retry currently looks like 
> this:
> {code}
> public  Workload submit(final Function work);
> {code}
> but that doesn't take into account relatively recent changes that allow 
> mutation operations to execute over a {{Traversal}}.  It also doesn't account 
> for workload constructed over multiple requests in a session to Gremlin 
> Server too well.
> Maybe we do something like:
> {code}
> public  Workload submit(final Function... work);
> public  Workload submit(final Function... work);
> public  Workload submit(final Traversal... work);
> {code}
> I suppose it might need to return a {{List}} or something like that so 
> that each piece of the transaction could maintain its own result.
> With respect to Gremlin Server and in-session requests, a driver could 
> automate transaction retry by inserting scripts to a list variable on the 
> server side until client-side {{commit()}} at which point that list could be 
> {{submit}} for retry.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[GitHub] tinkerpop pull request #634: TINKERPOP-741 Deprecated Transaction.submit(Fun...

[spmallette]

GitHub user spmallette opened a pull request:

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

TINKERPOP-741 Deprecated Transaction.submit(Function)

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

Deprecated  methods related to transaction retry in preparation for removal 
in 3.3.0.  Builds with `mvn clean install`.

VOTE +1

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

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

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

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


commit eba0a2c0a3dbb8ea1bb4d5358b8c7445cad15c85
Author: Stephen Mallette 
Date:   2017-06-19T15:45:32Z

TINKERPOP-741 Deprecated Transaction.submit(Function)




---
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-741) Remove Options For Transaction Retry

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on TINKERPOP-741:
--

GitHub user spmallette opened a pull request:

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

TINKERPOP-741 (master)

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

Removed deprecated  methods related to transaction retry.  Builds with `mvn 
clean install`.

VOTE +1

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

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

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

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


commit eba0a2c0a3dbb8ea1bb4d5358b8c7445cad15c85
Author: Stephen Mallette 
Date:   2017-06-19T15:45:32Z

TINKERPOP-741 Deprecated Transaction.submit(Function)

commit 21102e4fa86c1094a36e44bba8147d27f3da7628
Author: Stephen Mallette 
Date:   2017-06-19T15:52:04Z

Merge branch 'TINKERPOP-741' into TINKERPOP-741-master

commit 80822ee52c7eb500e38a444d44f98b5469c496e6
Author: Stephen Mallette 
Date:   2017-06-19T16:15:33Z

TINKERPOP-741 Removed deprecated transaction retry methods

commit 21bc4d85945cdd9beeeaedd92eb2769d75de53ba
Author: Stephen Mallette 
Date:   2017-06-19T16:24:47Z

TINKERPOP-741 Added upgrade docs around deprecation




> Remove Options For Transaction Retry
> 
>
> Key: TINKERPOP-741
> URL: https://issues.apache.org/jira/browse/TINKERPOP-741
> Project: TinkerPop
>  Issue Type: Improvement
>  Components: structure
>Affects Versions: 3.0.2-incubating
>Reporter: stephen mallette
>
> Submitting a transactional workload for automatic retry currently looks like 
> this:
> {code}
> public  Workload submit(final Function work);
> {code}
> but that doesn't take into account relatively recent changes that allow 
> mutation operations to execute over a {{Traversal}}.  It also doesn't account 
> for workload constructed over multiple requests in a session to Gremlin 
> Server too well.
> Maybe we do something like:
> {code}
> public  Workload submit(final Function... work);
> public  Workload submit(final Function... work);
> public  Workload submit(final Traversal... work);
> {code}
> I suppose it might need to return a {{List}} or something like that so 
> that each piece of the transaction could maintain its own result.
> With respect to Gremlin Server and in-session requests, a driver could 
> automate transaction retry by inserting scripts to a list variable on the 
> server side until client-side {{commit()}} at which point that list could be 
> {{submit}} for retry.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[GitHub] tinkerpop pull request #633: TINKERPOP-741 (master)

[spmallette]

GitHub user spmallette opened a pull request:

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

TINKERPOP-741 (master)

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

Removed deprecated  methods related to transaction retry.  Builds with `mvn 
clean install`.

VOTE +1

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

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

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

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


commit eba0a2c0a3dbb8ea1bb4d5358b8c7445cad15c85
Author: Stephen Mallette 
Date:   2017-06-19T15:45:32Z

TINKERPOP-741 Deprecated Transaction.submit(Function)

commit 21102e4fa86c1094a36e44bba8147d27f3da7628
Author: Stephen Mallette 
Date:   2017-06-19T15:52:04Z

Merge branch 'TINKERPOP-741' into TINKERPOP-741-master

commit 80822ee52c7eb500e38a444d44f98b5469c496e6
Author: Stephen Mallette 
Date:   2017-06-19T16:15:33Z

TINKERPOP-741 Removed deprecated transaction retry methods

commit 21bc4d85945cdd9beeeaedd92eb2769d75de53ba
Author: Stephen Mallette 
Date:   2017-06-19T16:24:47Z

TINKERPOP-741 Added upgrade docs around deprecation




---
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-1682) by-modulator optimization strategy

[ASF GitHub Bot (JIRA)]

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

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

Github user dkuppitz commented on the issue:

https://github.com/apache/tinkerpop/pull/621
  
Added a few comments and worked on those points that I haven't commented. I 
will push in few minutes after getting a clean build.


> by-modulator optimization strategy
> --
>
> Key: TINKERPOP-1682
> URL: https://issues.apache.org/jira/browse/TINKERPOP-1682
> Project: TinkerPop
>  Issue Type: Improvement
>  Components: process
>Affects Versions: 3.2.4
>Reporter: Daniel Kuppitz
>Assignee: Daniel Kuppitz
>
> The can be a significant difference in performance depending on whether you 
> use {{by(id)}} or {{by(id())}}:
> {noformat}
> gremlin> g.V().out().in().path().by(id()).profile()
> ==>Traversal Metrics
> Step   Count  
> Traversers   Time (ms)% Dur
> =
> TinkerGraphStep(vertex,[]) 6  
>  6  12.13758.03
> VertexStep(OUT,vertex) 6  
>  6   1.345 6.43
> VertexStep(IN,vertex) 12  
> 12   0.861 4.12
> PathStep([[IdStep, ProfileStep]]) 12  
> 12   6.57031.42
>   IdStep  36  
> 36   0.452
> >TOTAL -  
>  -  20.916-
> gremlin> g.V().out().in().path().by(id).profile()
> ==>Traversal Metrics
> Step   Count  
> Traversers   Time (ms)% Dur
> =
> TinkerGraphStep(vertex,[]) 6  
>  6   0.87611.54
> VertexStep(OUT,vertex) 6  
>  6   0.714 9.40
> VertexStep(IN,vertex) 12  
> 12   3.29943.43
> PathStep([id])12  
> 12   2.70635.63
> >TOTAL -  
>  -   7.596-
> {noformat}
> We should have a strategy that rewrites these simple patterns. This affects 
> {{id()}}, {{label()}}, {{key()}}, {{value()}}, but also 
> {{by(values("name"))}}, which can be rewritten as {{by("name")}}



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[GitHub] tinkerpop issue #621: TINKERPOP-1682 by-modulator optimization strategy

[dkuppitz]

Github user dkuppitz commented on the issue:

https://github.com/apache/tinkerpop/pull/621
  
Added a few comments and worked on those points that I haven't commented. I 
will push in few minutes after getting a clean build.


---
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-1682) by-modulator optimization strategy

[ASF GitHub Bot (JIRA)]

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

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

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

https://github.com/apache/tinkerpop/pull/621#discussion_r122694055
  
--- Diff: 
gremlin-core/src/main/java/org/apache/tinkerpop/gremlin/process/traversal/step/map/GroupStepV3d0.java
 ---
@@ -111,6 +111,16 @@ public void modulateBy(final Traversal.Admin 
kvrTraversal) {
 }
 
 @Override
+public void replaceLocalChild(final Traversal.Admin 
oldTraversal, final Traversal.Admin newTraversal) {
--- End diff --

This one is even easier - there's no pre-processing and the strategy should 
not change the internal `state` field.


> by-modulator optimization strategy
> --
>
> Key: TINKERPOP-1682
> URL: https://issues.apache.org/jira/browse/TINKERPOP-1682
> Project: TinkerPop
>  Issue Type: Improvement
>  Components: process
>Affects Versions: 3.2.4
>Reporter: Daniel Kuppitz
>Assignee: Daniel Kuppitz
>
> The can be a significant difference in performance depending on whether you 
> use {{by(id)}} or {{by(id())}}:
> {noformat}
> gremlin> g.V().out().in().path().by(id()).profile()
> ==>Traversal Metrics
> Step   Count  
> Traversers   Time (ms)% Dur
> =
> TinkerGraphStep(vertex,[]) 6  
>  6  12.13758.03
> VertexStep(OUT,vertex) 6  
>  6   1.345 6.43
> VertexStep(IN,vertex) 12  
> 12   0.861 4.12
> PathStep([[IdStep, ProfileStep]]) 12  
> 12   6.57031.42
>   IdStep  36  
> 36   0.452
> >TOTAL -  
>  -  20.916-
> gremlin> g.V().out().in().path().by(id).profile()
> ==>Traversal Metrics
> Step   Count  
> Traversers   Time (ms)% Dur
> =
> TinkerGraphStep(vertex,[]) 6  
>  6   0.87611.54
> VertexStep(OUT,vertex) 6  
>  6   0.714 9.40
> VertexStep(IN,vertex) 12  
> 12   3.29943.43
> PathStep([id])12  
> 12   2.70635.63
> >TOTAL -  
>  -   7.596-
> {noformat}
> We should have a strategy that rewrites these simple patterns. This affects 
> {{id()}}, {{label()}}, {{key()}}, {{value()}}, but also 
> {{by(values("name"))}}, which can be rewritten as {{by("name")}}



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[GitHub] tinkerpop pull request #621: TINKERPOP-1682 by-modulator optimization strate...

[dkuppitz]

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

https://github.com/apache/tinkerpop/pull/621#discussion_r122736897
  
--- Diff: 
gremlin-core/src/main/java/org/apache/tinkerpop/gremlin/process/traversal/util/TraversalRing.java
 ---
@@ -62,6 +62,10 @@ public void addTraversal(final Traversal.Admin 
traversal) {
 this.traversals.add(traversal);
 }
 
+public void setTraversal(final int index, final Traversal.Admin 
traversal) {
--- End diff --

Yea, it would be cleaner, but with indexing it's much faster as you don't 
have to search the whole `TraversalRing` for a specific traversal. I know, the 
ring will usually contain only a few traversals, but well It's `O(1)` vs. 
`O(n)`.


---
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 #621: TINKERPOP-1682 by-modulator optimization strate...

[dkuppitz]

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

https://github.com/apache/tinkerpop/pull/621#discussion_r122693554
  
--- Diff: 
gremlin-core/src/main/java/org/apache/tinkerpop/gremlin/process/traversal/step/map/GroupStep.java
 ---
@@ -79,6 +79,14 @@ public void modulateBy(final Traversal.Admin 
kvTraversal) {
 }
 
 @Override
+public void replaceLocalChild(final Traversal.Admin 
oldTraversal, final Traversal.Admin newTraversal) {
+if (null != this.keyTraversal && 
this.keyTraversal.equals(oldTraversal))
+this.keyTraversal = this.integrateChild(newTraversal);
+else if (null != this.valueTraversal && 
this.valueTraversal.equals(oldTraversal))
--- End diff --

I saw that, but if the strategy modifies the value traversal, then 
`this.barrierStep` is (and will further be) `null`, Likewise the reducing 
operator can only be `assign`.


---
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-915) Gremlin Server supports REST and Websockets simultanteously

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on TINKERPOP-915:
--

Github user krlohnes commented on the issue:

https://github.com/apache/tinkerpop/pull/618
  
@spmallette Yeah, I'm on the mailing list, I've been following along. No 
worries.


> Gremlin Server supports REST and Websockets simultanteously
> ---
>
> Key: TINKERPOP-915
> URL: https://issues.apache.org/jira/browse/TINKERPOP-915
> Project: TinkerPop
>  Issue Type: Improvement
>  Components: server
>Affects Versions: 3.0.2-incubating
>Reporter: stephen mallette
>
> Develop a {{Channelizer}} that allows REST and Websockets to be configured at 
> the same time.  I've personally tried to do this on a couple of attempts 
> while following a Netty sample, but I've never been able to get it to work.  
> Perhaps folks like [~pluradj] or [~dmill] would like to give it a go some 
> day? :)



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[GitHub] tinkerpop issue #618: TINKERPOP-915 Add combined handler for Http and Websoc...

[krlohnes]

Github user krlohnes commented on the issue:

https://github.com/apache/tinkerpop/pull/618
  
@spmallette Yeah, I'm on the mailing list, I've been following along. No 
worries.


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

Re: Code Freeze 3.1.7

[Ted Wilmes]

tp31 is now reopened for 3.1.8 development.

Thanks,
Ted

On Tue, Jun 6, 2017 at 8:52 AM, Ted Wilmes  wrote:

> Hello,
> 3.1.7 is now frozen and a snapshot build and updated docs have been
> published. There isn't anything outstanding that I know of, but please let
> me know if anythings needs to be added this week.
>
> Thanks,
> Ted
>

Re: code freeze 3.2.5

[Michael Pollmeier]

Looks like the mirrors are synchronised.
I just released Gremlin-Scala 3.2.5.0 as well :)

On 19/06/17 12:54, Stephen Mallette wrote:

The tp32 branch is re-opened for development. Packages have been released -
just waiting for the mirrors now and then we can announce.

On Thu, Jun 15, 2017 at 4:35 PM, Stephen Mallette 
wrote:


Since I got the new VOTE thread out today, I think we can likely count on
announcing the two  releases on Monday afternoon.

On Thu, Jun 15, 2017 at 1:57 PM, Stephen Mallette 
wrote:


Yes - please close the vote on 3.1.7. We will just hold off publishing
artifacts to central and announcing until the 3.2.5 release is done. Thanks!

On Thu, Jun 15, 2017 at 1:52 PM, Ted Wilmes  wrote:


Good deal, should I close out the vote for 3.1.7 tonight, barring any
-1's
and then we can hold off on the announcement to coincide with 3.2.5?

--Ted

On Thu, Jun 15, 2017 at 12:28 PM, Stephen Mallette 

wrote:


It seems that way. It could only be a problem if someone submitted

gryo

bytecode generated from something other than our GraphTraversal
implementation. That seems unlikely so I guess this was a lesser

problem

than I thought - oh well.

On Thu, Jun 15, 2017 at 9:15 AM, Robert Dale 

wrote:



So I guess inside, outside, and between are never actually

serialized

directly because they become a composition of other predicates?

Robert Dale

On Thu, Jun 15, 2017 at 8:48 AM, Robert Dale 

wrote:



Was working on serializing JanusGraph predicates - geo, text - for
withRemote. Since those predicates become P, I had to borrow and

modify

the

TinkerPop P serializer and noticed that something's not like the

other.


Robert Dale

On Thu, Jun 15, 2017 at 8:37 AM, Stephen Mallette <

spmalle...@gmail.com


wrote:


Robert, how did you go about hitting that problem with

P.inside()? It

occurs to me now that this was so deadly a bug because I'm not

sure

we

ever
end up actually serializing an "inside".

On Thu, Jun 15, 2017 at 6:23 AM, Stephen Mallette <

spmalle...@gmail.com>

wrote:


We do have a test for P.inside in the process tests but I

didn't

realize

that it doesn't compile to a P.inside at bytecode serialization

time:


gremlin> g.V(1).outE().has("weight", P.inside(0.0d,

0.6d)).inV().explain()

==>Traversal Explanation


===
Original Traversal [GraphStep(vertex,[1]),
VertexStep(OUT,edge), HasStep([weight.and(gt(0.0), lt(0.6))]),
EdgeVertexStep(IN)]

ConnectiveStrategy   [D]   [GraphStep(vertex,[1]),
VertexStep(OUT,edge), HasStep([weight.and(gt(0.0), lt(0.6))]),
EdgeVertexStep(IN)]
MatchPredicateStrategy   [O]   [GraphStep(vertex,[1]),
VertexStep(OUT,edge), HasStep([weight.and(gt(0.0), lt(0.6))]),
EdgeVertexStep(IN)]
FilterRankingStrategy[O]   [GraphStep(vertex,[1]),
VertexStep(OUT,edge), HasStep([weight.and(gt(0.0), lt(0.6))]),
EdgeVertexStep(IN)]
InlineFilterStrategy [O]   [GraphStep(vertex,[1]),
VertexStep(OUT,edge), HasStep([weight.and(gt(0.0), lt(0.6))]),
EdgeVertexStep(IN)]
IncidentToAdjacentStrategy   [O]   [GraphStep(vertex,[1]),
VertexStep(OUT,edge), HasStep([weight.and(gt(0.0), lt(0.6))]),
EdgeVertexStep(IN)]
AdjacentToIncidentStrategy   [O]   [GraphStep(vertex,[1]),
VertexStep(OUT,edge), HasStep([weight.and(gt(0.0), lt(0.6))]),
EdgeVertexStep(IN)]
RepeatUnrollStrategy [O]   [GraphStep(vertex,[1]),
VertexStep(OUT,edge), HasStep([weight.and(gt(0.0), lt(0.6))]),
EdgeVertexStep(IN)]
RangeByIsCountStrategy   [O]   [GraphStep(vertex,[1]),
VertexStep(OUT,edge), HasStep([weight.and(gt(0.0), lt(0.6))]),
EdgeVertexStep(IN)]
PathRetractionStrategy   [O]   [GraphStep(vertex,[1]),
VertexStep(OUT,edge), HasStep([weight.and(gt(0.0), lt(0.6))]),
EdgeVertexStep(IN)]
LazyBarrierStrategy  [O]   [GraphStep(vertex,[1]),
VertexStep(OUT,edge), HasStep([weight.and(gt(0.0), lt(0.6))]),
EdgeVertexStep(IN)]
TinkerGraphCountStrategy [P]   [GraphStep(vertex,[1]),
VertexStep(OUT,edge), HasStep([weight.and(gt(0.0), lt(0.6))]),
EdgeVertexStep(IN)]
TinkerGraphStepStrategy  [P]

  [TinkerGraphStep(vertex,[1]),

VertexStep(OUT,edge), HasStep([weight.and(gt(0.0), lt(0.6))]),
EdgeVertexStep(IN)]
ProfileStrategy  [F]

  [TinkerGraphStep(vertex,[1]),

VertexStep(OUT,edge), HasStep([weight.and(gt(0.0), lt(0.6))]),
EdgeVertexStep(IN)]
StandardVerificationStrategy [V]

  [TinkerGraphStep(vertex,[1]),

VertexStep(OUT,edge), HasStep([weight.and(gt(0.0), lt(0.6))]),

Re: Updating dependencies from 3.1.1-incubating

[Stephen Mallette]

The merge path will merge tp31 to tp32 and then tp32 to master. I don't
think there will be a lot of merge conflicts with your PR so I think we can
probably handle it all on our end after review. If we have problems we will
let you know. Thanks.

On Mon, Jun 19, 2017 at 8:15 AM, Sheldon Hall  wrote:

> OK thanks for letting me know. I also checked the latest master on github
> and it looks like the issue is still there. Just let me know if you want me
> to submit a pr to any other branches.
>
> > On 19 Jun 2017, at 12:15, Stephen Mallette  wrote:
> >
> > Thank you for submitting that patch and you did submit it to the right
> > place if you want the 3.1.x line. You just missed the cut-off for 3.1.7
> > which will release in a the next day or so, therefore you would see the
> fix
> > on 3.1.8. There is no plan for a release date for that at this point, but
> > we usually release every two to three months so that should give you a
> > rough idea to work with.
> >
> > On Mon, Jun 19, 2017 at 6:49 AM, Sheldon Hall  wrote:
> >
> >> Hi,
> >>
> >> We have been depending on 3.1.1-incubating here at Grakn for a while
> now,
> >> but I am hoping to get a bug fix into the main repo to help with our
> >> testing. I have submitted a pr to the branch tp31 (
> >> https://issues.apache.org/jira/browse/TINKERPOP-1519) assuming that it
> is
> >> the continuation of 3.1.1-incubating. If the bug fix is accepted, I am
> not
> >> sure which version it will end up in and therefore what I might need to
> >> upgrade my dependencies to. Could anyone help me understand what will
> >> happen next? In the meantime I will probably deploy a fork to maven to
> get
> >> things up and running faster.
> >>
> >> Thanks,
> >>
> >> Sheldon
> >>
>
>

Re: Updating dependencies from 3.1.1-incubating

[Sheldon Hall]

OK thanks for letting me know. I also checked the latest master on github and 
it looks like the issue is still there. Just let me know if you want me to 
submit a pr to any other branches.

> On 19 Jun 2017, at 12:15, Stephen Mallette  wrote:
> 
> Thank you for submitting that patch and you did submit it to the right
> place if you want the 3.1.x line. You just missed the cut-off for 3.1.7
> which will release in a the next day or so, therefore you would see the fix
> on 3.1.8. There is no plan for a release date for that at this point, but
> we usually release every two to three months so that should give you a
> rough idea to work with.
> 
> On Mon, Jun 19, 2017 at 6:49 AM, Sheldon Hall  wrote:
> 
>> Hi,
>> 
>> We have been depending on 3.1.1-incubating here at Grakn for a while now,
>> but I am hoping to get a bug fix into the main repo to help with our
>> testing. I have submitted a pr to the branch tp31 (
>> https://issues.apache.org/jira/browse/TINKERPOP-1519) assuming that it is
>> the continuation of 3.1.1-incubating. If the bug fix is accepted, I am not
>> sure which version it will end up in and therefore what I might need to
>> upgrade my dependencies to. Could anyone help me understand what will
>> happen next? In the meantime I will probably deploy a fork to maven to get
>> things up and running faster.
>> 
>> Thanks,
>> 
>> Sheldon
>> 



signature.asc
Description: Message signed with OpenPGP using GPGMail

Re: Updating dependencies from 3.1.1-incubating

[Stephen Mallette]

Thank you for submitting that patch and you did submit it to the right
place if you want the 3.1.x line. You just missed the cut-off for 3.1.7
which will release in a the next day or so, therefore you would see the fix
on 3.1.8. There is no plan for a release date for that at this point, but
we usually release every two to three months so that should give you a
rough idea to work with.

On Mon, Jun 19, 2017 at 6:49 AM, Sheldon Hall  wrote:

> Hi,
>
> We have been depending on 3.1.1-incubating here at Grakn for a while now,
> but I am hoping to get a bug fix into the main repo to help with our
> testing. I have submitted a pr to the branch tp31 (
> https://issues.apache.org/jira/browse/TINKERPOP-1519) assuming that it is
> the continuation of 3.1.1-incubating. If the bug fix is accepted, I am not
> sure which version it will end up in and therefore what I might need to
> upgrade my dependencies to. Could anyone help me understand what will
> happen next? In the meantime I will probably deploy a fork to maven to get
> things up and running faster.
>
> Thanks,
>
> Sheldon
>

[jira] [Commented] (TINKERPOP-1552) C# Gremlin Language Variant

[ASF GitHub Bot (JIRA)]

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

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

Github user asfgit closed the pull request at:

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


> C# Gremlin Language Variant
> ---
>
> Key: TINKERPOP-1552
> URL: https://issues.apache.org/jira/browse/TINKERPOP-1552
> Project: TinkerPop
>  Issue Type: Improvement
>  Components: language-variant
>Affects Versions: 3.2.3
>Reporter: Jorge Bay
>Assignee: stephen mallette
>
> It would be nice to have a C# GLV that runs under .NET Framework 4.5+ and 
> .NET Core.
> The maven build could use the Exec Maven Plugin to exec .NET Core's [dotnet 
> test|https://www.microsoft.com/net/core#macos] command.
> Some requirements, from the mailing list (edited):
> {quote}
> 1. The GLV should keep in line with class/method names of the java API
> where possible to ensure consistency of feel across languages.
> 2. There needs to be adequate tests (we're still discussing the approach to
> testing GLVs and i think that needs to be tackled sooner than later as more
> GLVs start to come in). Those tests should produce xunit style output
> unless there is some good reason not to.
> 3. There needs to be adequate documentation (e.g. Reference docs)
> 4. The build/deploy process needs to be bound to maven which might be one of 
> the trickier bits to deal with.
> {quote}



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[GitHub] tinkerpop pull request #629: TINKERPOP-1552: Clean-up Gremlin-DotNet project...

[asfgit]

Github user asfgit closed the pull request at:

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


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

Re: code freeze 3.2.5

[Stephen Mallette]

The tp32 branch is re-opened for development. Packages have been released -
just waiting for the mirrors now and then we can announce.

On Thu, Jun 15, 2017 at 4:35 PM, Stephen Mallette 
wrote:

> Since I got the new VOTE thread out today, I think we can likely count on
> announcing the two  releases on Monday afternoon.
>
> On Thu, Jun 15, 2017 at 1:57 PM, Stephen Mallette 
> wrote:
>
>> Yes - please close the vote on 3.1.7. We will just hold off publishing
>> artifacts to central and announcing until the 3.2.5 release is done. Thanks!
>>
>> On Thu, Jun 15, 2017 at 1:52 PM, Ted Wilmes  wrote:
>>
>>> Good deal, should I close out the vote for 3.1.7 tonight, barring any
>>> -1's
>>> and then we can hold off on the announcement to coincide with 3.2.5?
>>>
>>> --Ted
>>>
>>> On Thu, Jun 15, 2017 at 12:28 PM, Stephen Mallette >> >
>>> wrote:
>>>
>>> > Kuppitz (who has the day off today) just informed me that the fix he
>>> was
>>> > responsible for is in. I'm going to restart the release process -
>>> Hopefully
>>> > i'll have a new VOTE thread opened up by end of day.
>>> >
>>> > On Thu, Jun 15, 2017 at 9:34 AM, Stephen Mallette <
>>> spmalle...@gmail.com>
>>> > wrote:
>>> >
>>> > > It seems that way. It could only be a problem if someone submitted
>>> gryo
>>> > > bytecode generated from something other than our GraphTraversal
>>> > > implementation. That seems unlikely so I guess this was a lesser
>>> problem
>>> > > than I thought - oh well.
>>> > >
>>> > > On Thu, Jun 15, 2017 at 9:15 AM, Robert Dale 
>>> wrote:
>>> > >
>>> > >> So I guess inside, outside, and between are never actually
>>> serialized
>>> > >> directly because they become a composition of other predicates?
>>> > >>
>>> > >> Robert Dale
>>> > >>
>>> > >> On Thu, Jun 15, 2017 at 8:48 AM, Robert Dale 
>>> wrote:
>>> > >>
>>> > >> > Was working on serializing JanusGraph predicates - geo, text - for
>>> > >> > withRemote. Since those predicates become P, I had to borrow and
>>> > modify
>>> > >> the
>>> > >> > TinkerPop P serializer and noticed that something's not like the
>>> > other.
>>> > >> >
>>> > >> > Robert Dale
>>> > >> >
>>> > >> > On Thu, Jun 15, 2017 at 8:37 AM, Stephen Mallette <
>>> > spmalle...@gmail.com
>>> > >> >
>>> > >> > wrote:
>>> > >> >
>>> > >> >> Robert, how did you go about hitting that problem with
>>> P.inside()? It
>>> > >> >> occurs to me now that this was so deadly a bug because I'm not
>>> sure
>>> > we
>>> > >> >> ever
>>> > >> >> end up actually serializing an "inside".
>>> > >> >>
>>> > >> >> On Thu, Jun 15, 2017 at 6:23 AM, Stephen Mallette <
>>> > >> spmalle...@gmail.com>
>>> > >> >> wrote:
>>> > >> >>
>>> > >> >> > We do have a test for P.inside in the process tests but I
>>> didn't
>>> > >> realize
>>> > >> >> > that it doesn't compile to a P.inside at bytecode serialization
>>> > time:
>>> > >> >> >
>>> > >> >> > gremlin> g.V(1).outE().has("weight", P.inside(0.0d,
>>> > >> >> 0.6d)).inV().explain()
>>> > >> >> > ==>Traversal Explanation
>>> > >> >> > 
>>> > >> >> > 
>>> > >> >> > ===
>>> > >> >> > Original Traversal [GraphStep(vertex,[1]),
>>> > >> >> > VertexStep(OUT,edge), HasStep([weight.and(gt(0.0), lt(0.6))]),
>>> > >> >> > EdgeVertexStep(IN)]
>>> > >> >> >
>>> > >> >> > ConnectiveStrategy   [D]   [GraphStep(vertex,[1]),
>>> > >> >> > VertexStep(OUT,edge), HasStep([weight.and(gt(0.0), lt(0.6))]),
>>> > >> >> > EdgeVertexStep(IN)]
>>> > >> >> > MatchPredicateStrategy   [O]   [GraphStep(vertex,[1]),
>>> > >> >> > VertexStep(OUT,edge), HasStep([weight.and(gt(0.0), lt(0.6))]),
>>> > >> >> > EdgeVertexStep(IN)]
>>> > >> >> > FilterRankingStrategy[O]   [GraphStep(vertex,[1]),
>>> > >> >> > VertexStep(OUT,edge), HasStep([weight.and(gt(0.0), lt(0.6))]),
>>> > >> >> > EdgeVertexStep(IN)]
>>> > >> >> > InlineFilterStrategy [O]   [GraphStep(vertex,[1]),
>>> > >> >> > VertexStep(OUT,edge), HasStep([weight.and(gt(0.0), lt(0.6))]),
>>> > >> >> > EdgeVertexStep(IN)]
>>> > >> >> > IncidentToAdjacentStrategy   [O]   [GraphStep(vertex,[1]),
>>> > >> >> > VertexStep(OUT,edge), HasStep([weight.and(gt(0.0), lt(0.6))]),
>>> > >> >> > EdgeVertexStep(IN)]
>>> > >> >> > AdjacentToIncidentStrategy   [O]   [GraphStep(vertex,[1]),
>>> > >> >> > VertexStep(OUT,edge), HasStep([weight.and(gt(0.0), lt(0.6))]),
>>> > >> >> > EdgeVertexStep(IN)]
>>> > >> >> > RepeatUnrollStrategy [O]   [GraphStep(vertex,[1]),
>>> > >> >> > VertexStep(OUT,edge), HasStep([weight.and(gt(0.0), lt(0.6))]),
>>> > >> >> > EdgeVertexStep(IN)]
>>> > >> >> > RangeByIsCountStrategy   [O]   [GraphStep(vertex,[1]),
>>> > >> >> > VertexStep(OUT,edge), HasStep([weight.and(gt(0.0), lt(0.6))]),
>>> > >> >> > EdgeVertexStep(IN)]
>>> > >> >> > 

[jira] [Commented] (TINKERPOP-1552) C# Gremlin Language Variant

[ASF GitHub Bot (JIRA)]

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

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

Github user spmallette commented on the issue:

https://github.com/apache/tinkerpop/pull/629
  
I'm going to merge this then tp32-glv and this branch on the latest from 
tp32 now that the release is done. Should be in shortly.


> C# Gremlin Language Variant
> ---
>
> Key: TINKERPOP-1552
> URL: https://issues.apache.org/jira/browse/TINKERPOP-1552
> Project: TinkerPop
>  Issue Type: Improvement
>  Components: language-variant
>Affects Versions: 3.2.3
>Reporter: Jorge Bay
>Assignee: stephen mallette
>
> It would be nice to have a C# GLV that runs under .NET Framework 4.5+ and 
> .NET Core.
> The maven build could use the Exec Maven Plugin to exec .NET Core's [dotnet 
> test|https://www.microsoft.com/net/core#macos] command.
> Some requirements, from the mailing list (edited):
> {quote}
> 1. The GLV should keep in line with class/method names of the java API
> where possible to ensure consistency of feel across languages.
> 2. There needs to be adequate tests (we're still discussing the approach to
> testing GLVs and i think that needs to be tackled sooner than later as more
> GLVs start to come in). Those tests should produce xunit style output
> unless there is some good reason not to.
> 3. There needs to be adequate documentation (e.g. Reference docs)
> 4. The build/deploy process needs to be bound to maven which might be one of 
> the trickier bits to deal with.
> {quote}



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[GitHub] tinkerpop issue #629: TINKERPOP-1552: Clean-up Gremlin-DotNet project files

[spmallette]

Github user spmallette commented on the issue:

https://github.com/apache/tinkerpop/pull/629
  
I'm going to merge this then tp32-glv and this branch on the latest from 
tp32 now that the release is done. Should be in shortly.


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

[stephen mallette (JIRA)]

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

stephen mallette commented on TINKERPOP-1489:
-

About to rebase tp32-glv and this branch on the latest from tp32 now that the 
release is done. Should be in shortly.

> 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.4.14#64029)

[jira] [Closed] (TINKERPOP-1683) AbstractHadoopGraphComputer on Windows

[stephen mallette (JIRA)]

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

stephen mallette closed TINKERPOP-1683.
---
   Resolution: Fixed
 Assignee: stephen mallette
Fix Version/s: 3.2.6

I added the regex adjustment:

https://github.com/apache/tinkerpop/commit/e6c969e332e3ea5615af3863ab642b17043b3eab

> AbstractHadoopGraphComputer on Windows
> --
>
> Key: TINKERPOP-1683
> URL: https://issues.apache.org/jira/browse/TINKERPOP-1683
> Project: TinkerPop
>  Issue Type: Bug
>  Components: hadoop
>Affects Versions: 3.2.5
> Environment: Windows
>Reporter: Felix Hill
>Assignee: stephen mallette
>Priority: Trivial
>  Labels: RegEx
> Fix For: 3.2.6
>
>   Original Estimate: 0.25h
>  Remaining Estimate: 0.25h
>
> AbstractHadoopGraphComputer splits *HADOOP_GREMLIN_LIBS* in a wrong way if ; 
> is the File.pathSeparator (on windows).
> Here, the produced PATH_PATTERN splits a path at each character not at each 
> seperator.
> {code:title=AbstractHadoopGraphComputer.java|borderStyle=solid}
> private final static Pattern PATH_PATTERN =
> Pattern.compile(File.pathSeparator.equals(":") ? "([^:]|://)+" : 
> ("[^" + File.pathSeparator + "]"));
> final Matcher matcher = PATH_PATTERN.matcher(hadoopGremlinLibs);
> while (matcher.find()) {
> final String path = matcher.group();
> }
> {code}



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Updated] (TINKERPOP-1683) AbstractHadoopGraphComputer on Windows

[stephen mallette (JIRA)]

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

stephen mallette updated TINKERPOP-1683:

Affects Version/s: (was: 3.3.0)
   3.2.5

> AbstractHadoopGraphComputer on Windows
> --
>
> Key: TINKERPOP-1683
> URL: https://issues.apache.org/jira/browse/TINKERPOP-1683
> Project: TinkerPop
>  Issue Type: Bug
>  Components: hadoop
>Affects Versions: 3.2.5
> Environment: Windows
>Reporter: Felix Hill
>Priority: Trivial
>  Labels: RegEx
>   Original Estimate: 0.25h
>  Remaining Estimate: 0.25h
>
> AbstractHadoopGraphComputer splits *HADOOP_GREMLIN_LIBS* in a wrong way if ; 
> is the File.pathSeparator (on windows).
> Here, the produced PATH_PATTERN splits a path at each character not at each 
> seperator.
> {code:title=AbstractHadoopGraphComputer.java|borderStyle=solid}
> private final static Pattern PATH_PATTERN =
> Pattern.compile(File.pathSeparator.equals(":") ? "([^:]|://)+" : 
> ("[^" + File.pathSeparator + "]"));
> final Matcher matcher = PATH_PATTERN.matcher(hadoopGremlinLibs);
> while (matcher.find()) {
> final String path = matcher.group();
> }
> {code}



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

Updating dependencies from 3.1.1-incubating

[Sheldon Hall]

Hi,

We have been depending on 3.1.1-incubating here at Grakn for a while now, but I 
am hoping to get a bug fix into the main repo to help with our testing. I have 
submitted a pr to the branch tp31 
(https://issues.apache.org/jira/browse/TINKERPOP-1519 
) assuming that it is the 
continuation of 3.1.1-incubating. If the bug fix is accepted, I am not sure 
which version it will end up in and therefore what I might need to upgrade my 
dependencies to. Could anyone help me understand what will happen next? In the 
meantime I will probably deploy a fork to maven to get things up and running 
faster.

Thanks,

Sheldon


signature.asc
Description: Message signed with OpenPGP using GPGMail

[jira] [Closed] (TINKERPOP-1676) Improve GraphSON 2.0 Performance

[stephen mallette (JIRA)]

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

stephen mallette closed TINKERPOP-1676.
---
   Resolution: Done
Fix Version/s: 3.2.6

This was largely completed on 3.2.5 but I found one additional improvement that 
could be made which I CTR'd in. If there is more work to do here, we can create 
new more specific tickets.

> Improve GraphSON 2.0 Performance
> 
>
> Key: TINKERPOP-1676
> URL: https://issues.apache.org/jira/browse/TINKERPOP-1676
> Project: TinkerPop
>  Issue Type: Improvement
>  Components: io
>Affects Versions: 3.2.4
>Reporter: stephen mallette
>Assignee: stephen mallette
>  Labels: breaking
> Fix For: 3.2.6
>
>
> Not sure what will happen here. Just wanted an issue where I could experiment 
> a bit with and gather feedback from others for collaboration in case others 
> had ideas. Right now, GraphSON reads are considerably slower than Gryo and 
> writes appear to be faster, so the focus will be on how to get reads more in 
> line with what Gryo can do. 



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Commented] (TINKERPOP-1519) TinkerGraphComputer doesn't handle multiple MessageScopes in single iteration

[ASF GitHub Bot (JIRA)]

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

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

GitHub user sheldonkhall opened a pull request:

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

TINKERPOP-1519: tinker graph computer does not handle multiple scopes

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

This change modifies the tinker graph computer so that each message sent in 
a vertex program remembers its scope. Previously when the receiveMessages 
method on TinkerMessenger was called it would loop through ALL message scopes 
and then ALL messages, which is incorrect. Now the method loops over each 
scope, and then each message within that scope.

I have added the regression test suggested in the JIRA ticket and run mvn 
clean install locally to confirm everything passes OK.

I had a quick look at the latest master, and this bugfix may need to be 
merged there too.


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

$ git pull https://github.com/sheldonkhall/tinkerpop tp31

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

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


commit 28c514da9065683ed90ea6aabc66ffdcbab99c11
Author: Sheldon 
Date:   2017-06-15T17:00:32Z

bugfix

commit 99679a037db3e86112471a40cd454114231852b6
Author: Sheldon 
Date:   2017-06-19T09:35:16Z

add the regression test




> TinkerGraphComputer doesn't handle multiple MessageScopes in single iteration
> -
>
> Key: TINKERPOP-1519
> URL: https://issues.apache.org/jira/browse/TINKERPOP-1519
> Project: TinkerPop
>  Issue Type: Bug
>  Components: tinkergraph
>Affects Versions: 3.1.1-incubating
> Environment: Mac OSX
>Reporter: Felix Chapman
>Priority: Minor
>
> When executing a VertexProgram that sends messages on multiple MessageScopes 
> in a single iteration, then the messages behave as if they were sent on all 
> scopes within that iteration.
> e.g. if you send message {{A}} on {{out}} edges, and message {{B}} on {{in}} 
> edges, then {{A}} and {{B}} will instead be sent over both {{in}} and {{out}} 
> edges.
> The problem can be resolved by using only a single MessageScope per 
> iteration, but this involves increasing the number of iterations.
> An example of this behaviour is below:
> {code:java}
> public class TinkerTest {
> public static void main(String[] args) throws ExecutionException, 
> InterruptedException {
> TinkerGraph graph = TinkerGraph.open();
> Vertex a = graph.addVertex("a");
> Vertex b = graph.addVertex("b");
> Vertex c = graph.addVertex("c");
> a.addEdge("edge", b);
> b.addEdge("edge", c);
> // Simple graph:
> // a -> b -> c
> // Execute a traversal program that sends an incoming message of "2" 
> and an outgoing message of "1" from "b"
> // then each vertex sums any received messages
> ComputerResult result = graph.compute().program(new 
> MyVertexProgram()).submit().get();
> // We expect the results to be {a=2, b=0, c=1}. Instead it is {a=3, 
> b=0, c=3}
> 
> System.out.println(result.graph().traversal().V().group().by(Element::label).by("count").next());
> }
> }
> class MyVertexProgram implements VertexProgram {
> private final MessageScope.Local countMessageScopeIn = 
> MessageScope.Local.of(__::inE);
> private final MessageScope.Local countMessageScopeOut = 
> MessageScope.Local.of(__::outE);
> private static final String MEMORY_KEY = "count";
> private static final Set COMPUTE_KEYS = 
> Collections.singleton(MEMORY_KEY);
> @Override
> public void setup(final Memory memory) {}
> @Override
> public GraphComputer.Persist getPreferredPersist() {
> return GraphComputer.Persist.VERTEX_PROPERTIES;
> }
> @Override
> public Set getElementComputeKeys() {
> return COMPUTE_KEYS;
> }
> @Override
> public Set getMessageScopes(final Memory memory) {
> return Sets.newHashSet(countMessageScopeIn, countMessageScopeOut);
> }
> @Override
> public void execute(Vertex vertex, Messenger messenger, Memory 
> memory) {
> switch (memory.getIteration()) {
> case 0:
> if (vertex.label().equals("b")) {
> messenger.sendMessage(this.countMessageScopeIn, 2L);
> messenger.sendMessage(this.countMessageScopeOut, 1L);
> }
> 

[GitHub] tinkerpop pull request #632: TINKERPOP-1519: tinker graph computer does not ...

[sheldonkhall]

GitHub user sheldonkhall opened a pull request:

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

TINKERPOP-1519: tinker graph computer does not handle multiple scopes

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

This change modifies the tinker graph computer so that each message sent in 
a vertex program remembers its scope. Previously when the receiveMessages 
method on TinkerMessenger was called it would loop through ALL message scopes 
and then ALL messages, which is incorrect. Now the method loops over each 
scope, and then each message within that scope.

I have added the regression test suggested in the JIRA ticket and run mvn 
clean install locally to confirm everything passes OK.

I had a quick look at the latest master, and this bugfix may need to be 
merged there too.


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

$ git pull https://github.com/sheldonkhall/tinkerpop tp31

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

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


commit 28c514da9065683ed90ea6aabc66ffdcbab99c11
Author: Sheldon 
Date:   2017-06-15T17:00:32Z

bugfix

commit 99679a037db3e86112471a40cd454114231852b6
Author: Sheldon 
Date:   2017-06-19T09:35:16Z

add the regression test




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

[Jorge Bay (JIRA)]

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

Jorge Bay commented on TINKERPOP-1489:
--

Nice! I see it on npm under the url: https://www.npmjs.com/org/tinkerpop

To grant access to the gremlin-javascript package, I need a team to be created 
under tinkerpop, like "developers" (with just the admin user as part of that 
team should be enough), maybe there is already a team created but I can not see 
it. That way, I could [grant access to the org's 
team|https://www.npmjs.com/docs/orgs/managing-package-access.html#managing-package-access]:

{code}
npm access grant read-write tinkerpop:developers
{code}

Afterwards, you can revoke access to my user.

> 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.4.14#64029)