Re: [VOTE] TinkerPop 3.2.5 Release

[Robert Dale]

VOTE +1

Robert Dale

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

> Hello (again),
>
> We are happy to announce (again) that TinkerPop 3.2.5 is ready for release.
>
> The release artifacts can be found at this location:
> https://dist.apache.org/repos/dist/dev/tinkerpop/3.2.5/
>
> The source distribution is provided by:
> apache-tinkerpop-3.2.5-src.zip
>
> Two binary distributions are provided for user convenience:
> apache-tinkerpop-gremlin-console3.2.5-bin.zip
> apache-tinkerpop-gremlin-server-3.2.5-bin.zip
>
> The GPG key used to sign the release artifacts is available at:
> https://dist.apache.org/repos/dist/dev/tinkerpop/KEYS
>
> The online docs can be found here:
> http://tinkerpop.apache.org/docs/3.2.5/ (user docs)
> http://tinkerpop.apache.org/docs/3.2.5/upgrade/ (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 tag in Apache Git can be found here:
>
> https://git-wip-us.apache.org/repos/asf?p=tinkerpop.git;a=tag;h=
> 0ecbb067a212711a6b996af828cc932956282dcc
>
> The release notes are available here:
>
> https://github.com/apache/tinkerpop/blob/master/
> CHANGELOG.asciidoc#tinkerpop-320-nine-inch-gremlins
>
> The [VOTE] will be open for the next 72 hours --- closing Sunday (June 18,
> 2017) at  4:30pm EST
>
> My vote is +1 (again).
>
> Thank you very much,
> Stephen
>

[jira] [Updated] (TINKERPOP-1241) Create JMH benchmark viewer

[stephen mallette (JIRA)]

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

stephen mallette updated TINKERPOP-1241:

Priority: Trivial  (was: Minor)

> Create JMH benchmark viewer
> ---
>
> Key: TINKERPOP-1241
> URL: https://issues.apache.org/jira/browse/TINKERPOP-1241
> Project: TinkerPop
>  Issue Type: Improvement
>  Components: benchmark
>Affects Versions: 3.1.1-incubating
>Reporter: Ted Wilmes
>Priority: Trivial
>
> JMH benchmarks results are saved to the {{gremlin-benchmark/benchmark}} 
> directory in JSON format.  It would be nice to have a simple way to view 
> benchmark results side by side.  Perhaps a simple index.html file with some 
> javascript to view the results of runs side by side.  JMH uses the method 
> names to identify tests so that along with the test class name could be used 
> to tie results from different runs together.  This Jenkins 
> [plugin|https://github.com/brianfromoregon/jmh-plugin] might have some 
> interesting examples of visualization in it.



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

[jira] [Updated] (TINKERPOP-1195) Client and ResultSet API changes

[stephen mallette (JIRA)]

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

stephen mallette updated TINKERPOP-1195:

Description: 
Given discussion on a couple different threads:

https://lists.apache.org/thread.html/Z424dvlo67k5np4
https://lists.apache.org/thread.html/Z70ku3nckrkkgiy

the idea to introduce a breaking change to the {{Client}} and {{Result}} API 
seems to be established.  The basic changes involve:

1. Remove the return of {{CompletableFuture}} from a {{ResultSet}} thus 
allowing it to block for the {{some()}} and {{all()}} methods.
2. Change {{Client.submit()}} to return {{List}} rather than return a 
{{ResultSet}} - that method will basically block until all results are returned 
and then unwrap the {{List}} and return that.

Unfortunately, there doesn't appear to be a way to make it so that these 
changes are non-breaking.

  was:
Given discussion on a couple different threads:

https://pony-poc.apache.org/thread.html/Z424dvlo67k5np4
https://pony-poc.apache.org/thread.html/Z70ku3nckrkkgiy

the idea to introduce a breaking change to the {{Client}} and {{Result}} API 
seems to be established.  The basic changes involve:

1. Remove the return of {{CompletableFuture}} from a {{ResultSet}} thus 
allowing it to block for the {{some()}} and {{all()}} methods.
2. Change {{Client.submit()}} to return {{List}} rather than return a 
{{ResultSet}} - that method will basically block until all results are returned 
and then unwrap the {{List}} and return that.

Unfortunately, there doesn't appear to be a way to make it so that these 
changes are non-breaking.


> Client and ResultSet API changes
> 
>
> Key: TINKERPOP-1195
> URL: https://issues.apache.org/jira/browse/TINKERPOP-1195
> Project: TinkerPop
>  Issue Type: Improvement
>  Components: driver
>Affects Versions: 3.1.1-incubating
>Reporter: stephen mallette
>Assignee: stephen mallette
>  Labels: breaking
>
> Given discussion on a couple different threads:
> https://lists.apache.org/thread.html/Z424dvlo67k5np4
> https://lists.apache.org/thread.html/Z70ku3nckrkkgiy
> the idea to introduce a breaking change to the {{Client}} and {{Result}} API 
> seems to be established.  The basic changes involve:
> 1. Remove the return of {{CompletableFuture}} from a {{ResultSet}} thus 
> allowing it to block for the {{some()}} and {{all()}} methods.
> 2. Change {{Client.submit()}} to return {{List}} rather than return a 
> {{ResultSet}} - that method will basically block until all results are 
> returned and then unwrap the {{List}} and return that.
> Unfortunately, there doesn't appear to be a way to make it so that these 
> changes are non-breaking.



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

[jira] [Closed] (TINKERPOP-1124) Make tinkerpop interfaces expandable

[stephen mallette (JIRA)]

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

stephen mallette closed TINKERPOP-1124.
---
Resolution: Won't Do

As there hasn't been any discussion on the dev list around this item since this 
was created and now recent activity I'm going to close it. If anyone feels this 
issue is still important, please start a DISCUSS thread as I recommended on the 
previous comment. 

> Make tinkerpop interfaces expandable
> 
>
> Key: TINKERPOP-1124
> URL: https://issues.apache.org/jira/browse/TINKERPOP-1124
> Project: TinkerPop
>  Issue Type: Improvement
>  Components: structure
>Affects Versions: 3.1.1-incubating
>Reporter: Marvin Froeder
>
> Make the return methods generic so we can specialize them.
> For instance, instead of
> {code:java}
> public interface Graph {
>  public Iterator vertices(final Object... vertexIds);
> }
> {code}
> move to
> {code:java}
> public interface Graph {
>  public Iterator vertices(final Object... vertexIds);
> }
> {code}
> That way, orientdb-gremlin (or any other drivers) can expose custom 
> operations on graphs, vertex or edges and even enforce types for things like 
> Element.id() and many other creative stuff.
> That is the way querydsl (http://www.querydsl.com/) found to have a 
> consistent api that can be extended and used in so many different modules.
> This would allow orient-gremlin expose orient specific operations w/o having 
> to expose the implementation.



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

[jira] [Commented] (TINKERPOP-1081) Add serializers for Graph.Features

[stephen mallette (JIRA)]

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

stephen mallette commented on TINKERPOP-1081:
-

Thinking in terms of where we are headed with GLV/Traversal interactions and 
not Graph API interactions i wonder if this serialization is needed. If there 
are new thoughts on this we can just keep it open, otherwise, I think I will 
just close it out.

> Add serializers for Graph.Features
> --
>
> Key: TINKERPOP-1081
> URL: https://issues.apache.org/jira/browse/TINKERPOP-1081
> Project: TinkerPop
>  Issue Type: Improvement
>  Components: io
>Affects Versions: 3.1.0-incubating
>Reporter: Bob Briody
>Priority: Trivial
>
> Gremlin Server should provide support for the serialization of Graph.Features 
> via 'graph.features()'.
> Ideally, all Graph.Features implementations would be coerced and serialized 
> uniformly and without any work on the part of the underlying graph 
> implementation.



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

[jira] [Closed] (TINKERPOP-1030) Map common exceptions to HTTP status codes where possible

[stephen mallette (JIRA)]

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

stephen mallette closed TINKERPOP-1030.
---
Resolution: Won't Do

I created this one, but no longer like the idea. Just more complexity in the 
gremlin server config that we don't need.  No one is really asking for this so 
- it's just stuff for the sake of stuff - closing.

> Map common exceptions to HTTP status codes where possible
> -
>
> Key: TINKERPOP-1030
> URL: https://issues.apache.org/jira/browse/TINKERPOP-1030
> Project: TinkerPop
>  Issue Type: Improvement
>  Components: server
>Affects Versions: 3.1.0-incubating
>Reporter: stephen mallette
>Priority: Trivial
>
> If a script throws an exception in the REST API, it would be nice if there 
> was a way to map that exception to an HTTP status code.  The gremlin server 
> configuration could have a specific set of exception to error code mappings.



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

[jira] [Commented] (TINKERPOP-974) Saving headless traversals for reuse (clone Iterator Fun)

[stephen mallette (JIRA)]

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

stephen mallette commented on TINKERPOP-974:


As of 3.2.5 we've published methods for doing this kind of thing:

{code}
g.V('u2590').possibleFriends()
{code}

with DSLs. Gremlin code can be more modularized this way.

> Saving headless traversals for reuse (clone Iterator Fun)
> -
>
> Key: TINKERPOP-974
> URL: https://issues.apache.org/jira/browse/TINKERPOP-974
> Project: TinkerPop
>  Issue Type: Improvement
>  Components: process
>Affects Versions: 3.0.2-incubating
>Reporter: Sebastian Estevez
> Fix For: 3.2.6
>
>
> It would be very useful to be able to do something like this:
> {code}
> gremlin> possibleFriends = 
> out('rated').inE('rated').has('stars',5).outV().groupCount().order(local).by(valueDecr).limit(local,1).mapKeys()
> gremlin> g.V('u2590').possibleFriends
> {code}
> Marko suggested the following workaround method using `; null` and `.clone()` 
> {code}
> gremlin> possibleFriends = 
> out('rated').inE('rated').has('stars',5).outV().groupCount().order(local).by(valueDecr).limit(local,1).mapKeys();
>  null
> ==>null
> gremlin> g.V('u2590').map(possibleFriends.clone())
> ==>v[u4277]
> gremlin> g.V('u2590').map(possibleFriends.clone())
> ==>v[u4277]
> gremlin> g.V('u2590').map(possibleFriends.clone())
> ==>v[u4277]
> gremlin> possibleFriends.clone()
> gremlin> possibleFriends.clone()
> gremlin> possibleFriends.clone()
> gremlin> possibleFriends.clone()
> gremlin> possibleFriends.clone()
> gremlin> possibleFriends.clone()
> gremlin> possibleFriends
> gremlin> g.V('u2590').map(possibleFriends.clone())
> The traversal strategies are complete and the traversal can no longer be 
> modulated
> Display stack trace? [yN]
> {code}
> https://gist.github.com/okram/9feb6940c749ed9a3058
> Having a nice way of breaking down complex gremlin into functions and using 
> them later would help modularize gremlin queries and improve readability and 
> maintenance.



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

Re: code freeze 3.2.5

[Stephen Mallette]

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

[VOTE] TinkerPop 3.2.5 Release

[Stephen Mallette]

Hello (again),

We are happy to announce (again) that TinkerPop 3.2.5 is ready for release.

The release artifacts can be found at this location:
https://dist.apache.org/repos/dist/dev/tinkerpop/3.2.5/

The source distribution is provided by:
apache-tinkerpop-3.2.5-src.zip

Two binary distributions are provided for user convenience:
apache-tinkerpop-gremlin-console3.2.5-bin.zip
apache-tinkerpop-gremlin-server-3.2.5-bin.zip

The GPG key used to sign the release artifacts is available at:
https://dist.apache.org/repos/dist/dev/tinkerpop/KEYS

The online docs can be found here:
http://tinkerpop.apache.org/docs/3.2.5/ (user docs)
http://tinkerpop.apache.org/docs/3.2.5/upgrade/ (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 tag in Apache Git can be found here:

https://git-wip-us.apache.org/repos/asf?p=tinkerpop.git;a=tag;h=0ecbb067a212711a6b996af828cc932956282dcc

The release notes are available here:

https://github.com/apache/tinkerpop/blob/master/
CHANGELOG.asciidoc#tinkerpop-320-nine-inch-gremlins

The [VOTE] will be open for the next 72 hours --- closing Sunday (June 18,
2017) at  4:30pm EST

My vote is +1 (again).

Thank you very much,
Stephen

[jira] [Closed] (TINKERPOP-969) respawn

[stephen mallette (JIRA)]

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

stephen mallette closed TINKERPOP-969.
--
   Resolution: Won't Do
Fix Version/s: (was: 3.2.6)

This one has been around for a long while moving from one targeted version to 
the next and I've never really understood what it's about. Since there has been 
any new discussion in a long time, I'm going to close it. Please feel free to 
re-open if necessary.

> respawn
> ---
>
> Key: TINKERPOP-969
> URL: https://issues.apache.org/jira/browse/TINKERPOP-969
> Project: TinkerPop
>  Issue Type: Improvement
>  Components: process
>Affects Versions: 3.0.2-incubating
>Reporter: Matt Frantz
>Assignee: Marko A. Rodriguez
>
> Control which aspects of the traverser propagate into an inner traversal by 
> using the {{respawn}} factory method.
> {noformat}
> // Clone only the location by default.
> g.V.map(respawn().out('mother').name)
> // Clone sack and path
> g.V.as('a').map(
>   respawn(sack,path).
>   sack().as('s').select('a','s'))
> {noformat}
> We would also like to allow the inner traversal to have its own sack and 
> side-effect scope.  This would require something that returns a 
> {{GraphTraversalSource}}, e.g. {{respawnSource}}.  That also means that 
> {{GraphTraversalSource}} needs a new step, e.g. {{identity}}, that would 
> allow it to be used as an inner traversal.
> {noformat}
> // can have its own sack definition
> g.V.map(respawnSource().withSack(0.0).identity().out()...)
> {noformat}



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

[jira] [Updated] (TINKERPOP-920) Test case needed for ensuring same cardinality for key.

[stephen mallette (JIRA)]

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

stephen mallette updated TINKERPOP-920:
---
 Labels:   (was: breaking)
Component/s: (was: test-suite)
 structure

Re-reading comments from where this was last left. I don't think we should 
enforce cardinality to a key. Instead {{getCardinality}} should be documented 
as a method that provides a cardinality hint that can be used by internal 
TinkerPop methods. I'd also rather not make significant changes here because 
{{getCardinality}} just takes a String right now. That may be insufficient for 
more advanced graph schemas like those that allow a vertex label namespace for 
properties such that the key isn't just the property key but is the vertex 
label plus the property key. Better to wait for more developments in that space 
before committing to a breaking change here.

> Test case needed for ensuring same cardinality for key.
> ---
>
> Key: TINKERPOP-920
> URL: https://issues.apache.org/jira/browse/TINKERPOP-920
> Project: TinkerPop
>  Issue Type: Improvement
>  Components: structure
>Affects Versions: 3.0.2-incubating
>Reporter: Marko A. Rodriguez
>Assignee: stephen mallette
>
> I'm note sure we have a test case for this so I will just make a ticket -- 
> please close with "won't fix" if this is already handled.
> Two properties with the same key should NOT have different cardinalities 
> because of {{Feature.getCardinality(key)}}.



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

[jira] [Closed] (TINKERPOP-844) PropertyMapStep should reuse PropertiesStep

[stephen mallette (JIRA)]

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

stephen mallette closed TINKERPOP-844.
--
   Resolution: Done
Fix Version/s: (was: 3.2.6)
   3.2.3

Looks like this was completed a while back - there was not additional feedback 
so I will assume it is done to satisfaction.

> PropertyMapStep should reuse PropertiesStep
> ---
>
> Key: TINKERPOP-844
> URL: https://issues.apache.org/jira/browse/TINKERPOP-844
> Project: TinkerPop
>  Issue Type: Improvement
>  Components: process
>Affects Versions: 3.0.2-incubating
>Reporter: Matthias Broecheler
>Assignee: Marko A. Rodriguez
> Fix For: 3.2.3
>
>
> Currently, there are two steps which retrieve properties: PropertiesStep and 
> PropertyMapStep. For any vendor implementation wishing to optimize property 
> retrieval this means twice the (redundant) work because each of the steps 
> needs to be extended individually.
> However, the functionality is very similar. PropertyMapStep should be 
> replaced by two steps: PropertiesStep which returns an iterator over 
> properties and a MapAggregatorStep (not tied to the name) which consumes 
> properties from the previous step and builds the map (either with property or 
> values as the the map value) until the element of a property differs.
> This reuse of PropertiesStep would have increase code reuse inside TinkerPop 
> and should not have a significant performance impact. Most importantly, it 
> makes life a lot easier for implementors.



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

[jira] [Updated] (TINKERPOP-800) [Proposal] Domain/Range checking during traversal construction.

[stephen mallette (JIRA)]

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

stephen mallette updated TINKERPOP-800:
---
Fix Version/s: (was: 3.2.6)

This seems like an idea that could be helpful to new users who aren't familiar 
with Gremlin's exceptions. Perhaps worth doing, but since it is "breaking" 
removed from 3.2.6.

> [Proposal] Domain/Range checking during traversal construction.
> ---
>
> Key: TINKERPOP-800
> URL: https://issues.apache.org/jira/browse/TINKERPOP-800
> Project: TinkerPop
>  Issue Type: Improvement
>  Components: process
>Affects Versions: 3.0.2-incubating
>Reporter: Marko A. Rodriguez
>Assignee: Marko A. Rodriguez
>  Labels: breaking
>
> I think we should add two new methods to {{Step}}.
> {code}
> Step.getDomain() -> Class
> Step.getRange() -> Class
> {code}
> Now, when someone does:
> {code}
> g.V().out()
> {code}
> {{GraphStep}} will report that its range is {{Vertex.class}}. {{VertexStep}} 
> will report its domain to be {{Vertex.class}}. Good. No typing issues. 
> However, when you do this:
> {code}
> g.E().out()
> {code}
> {{GraphStep}} will report that its range is {{Edge.class}}. {{VertexStep}} 
> will report its domain to be {{Vertex.class}} --- {{IllegalArgumentException: 
> "The provided traversal has an illegal function composition."}}.
> Why is this good -- much better than getting random {{ClassCastExceptions}} 
> at execution time.



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

[jira] [Closed] (TINKERPOP-787) User-defined containers

[stephen mallette (JIRA)]

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

stephen mallette closed TINKERPOP-787.
--
Resolution: Won't Do

Now that we have published methods for building DSLs I think this is something 
best left to users to implement as they see fit. I don't think we want to try 
to implement this kind of feature across all GLVs either given that we have a 
method for allowing this type of extension through DSLs. This issue hasn't been 
touched in a while so I'm going to close it. If anyone disagrees, please 
re-open for further discussion.

> User-defined containers
> ---
>
> Key: TINKERPOP-787
> URL: https://issues.apache.org/jira/browse/TINKERPOP-787
> Project: TinkerPop
>  Issue Type: Improvement
>  Components: process
>Affects Versions: 3.0.2-incubating
>Reporter: Matt Frantz
>
> For any steps that create containers, we could add a modifier step (like 
> {{by}}) that allows specifying a {{Supplier}} of that container.
> {noformat}
>  GraphTraversal withList(Supplier s);
>  GraphTraversal withMap(Supplier s);
> {noformat}
> In addition to providing optimized container implementations, it could 
> provide for application-specific derived container types, e.g. a Map subclass 
> with accessor methods for particular keys.
> {noformat}
> class Student extends HashMap {
>   public String name() { return (String)get("name"); }
>   public int schoolAge() { return (Integer)get("schoolAge"); }
> }
> {noformat}
> This in turn allows stronger type safety for traversals, since you could 
> declare the output of a Map-producing step to be your UDT.
> {noformat}
> g.V().as("name", "schoolAge")
>   .select("name", "schoolAge")
>   .withMap{->new Student()}
>   .by(values("name")
>   .by(out("school").values("age"))
> {noformat}



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

[jira] [Comment Edited] (TINKERPOP-1004) Make Transaction.commit() failures consistent across implementations.

[stephen mallette (JIRA)]

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

stephen mallette edited comment on TINKERPOP-1004 at 6/15/17 6:25 PM:
--

a couple of points that would make this worth it: 
https://issues.apache.org/jira/browse/TINKERPOP3-1005

and the following thread might shed some light: 
https://lists.apache.org/thread.html/Zhvzunq4kw26ysm


was (Author: dmill):
a couple of points that would make this worth it: 
https://issues.apache.org/jira/browse/TINKERPOP3-1005

and the following thread might shed some light : 
https://pony-https://lists.apache.org/thread.html/Zhvzunq4kw26ysm

> Make Transaction.commit() failures consistent across implementations.
> -
>
> Key: TINKERPOP-1004
> URL: https://issues.apache.org/jira/browse/TINKERPOP-1004
> Project: TinkerPop
>  Issue Type: Improvement
>  Components: structure
>Affects Versions: 3.0.2-incubating
>Reporter: Dylan Millikin
>  Labels: breaking
>
> Currently {{commit()}} can fail when implementations throw exceptions. These 
> exceptions aren't consistent and are very implementation specific. It would 
> be good to abstract this and provide TP specific exceptions for this (while 
> bubbling the original exceptions).



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

[jira] [Comment Edited] (TINKERPOP-1004) Make Transaction.commit() failures consistent across implementations.

[stephen mallette (JIRA)]

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

stephen mallette edited comment on TINKERPOP-1004 at 6/15/17 6:25 PM:
--

a couple of points that would make this worth it: 
https://issues.apache.org/jira/browse/TINKERPOP3-1005

and the following thread might shed some light : 
https://pony-https://lists.apache.org/thread.html/Zhvzunq4kw26ysm


was (Author: dmill):
a couple of points that would make this worth it: 
https://issues.apache.org/jira/browse/TINKERPOP3-1005

and the following thread might shed some light : 
https://pony-poc.apache.org/thread.html/Zhvzunq4kw26ysm

> Make Transaction.commit() failures consistent across implementations.
> -
>
> Key: TINKERPOP-1004
> URL: https://issues.apache.org/jira/browse/TINKERPOP-1004
> Project: TinkerPop
>  Issue Type: Improvement
>  Components: structure
>Affects Versions: 3.0.2-incubating
>Reporter: Dylan Millikin
>  Labels: breaking
>
> Currently {{commit()}} can fail when implementations throw exceptions. These 
> exceptions aren't consistent and are very implementation specific. It would 
> be good to abstract this and provide TP specific exceptions for this (while 
> bubbling the original exceptions).



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

[jira] [Closed] (TINKERPOP-1005) gremlin-server should throw a 500 error on commit() failure

[stephen mallette (JIRA)]

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

stephen mallette closed TINKERPOP-1005.
---
Resolution: Won't Do

Recent changes on other tickets related to 3.2.5 (and perhaps even earlier 
versions along the 3.2.x line)  have improved error messaging considerably. You 
now get the server error message, the server stacktrace and the exception 
hierarchy (you would see the specific Titan/JanusGraph exception names). If you 
used auto-transactions then a commit error would nowadays return as a 500 not a 
597. If you called commit within a script, well then that's a 597, but it 
should be a 597 in a sense because it failed as a script. Anyway, I think that 
tends to satisfy this one. I'm going to close this as a result - please re-open 
if I've not addressed something or this needs more discussion.

> gremlin-server should throw a 500 error on commit() failure
> ---
>
> Key: TINKERPOP-1005
> URL: https://issues.apache.org/jira/browse/TINKERPOP-1005
> Project: TinkerPop
>  Issue Type: Improvement
>  Components: server
>Affects Versions: 3.0.2-incubating
>Reporter: Dylan Millikin
>
> Currently gremlin-server throws a {{597 - SCRIPT EVALUATION ERROR}} on commit 
> failures (for concurrency reasons for example). This isn't really the correct 
> error to return in those cases. Drivers would expect a {{500 - SERVER ERROR}} 
> instead for their retry-failure strategies.
> Of course this could take on another form and somehow allow drivers to 
> differentiate commit failures from other exceptions. So in any event this is 
> probably going to depend on 
> https://issues.apache.org/jira/browse/TINKERPOP3-1004 yet also require a 
> change to the server code.



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

Re: code freeze 3.2.5

[Stephen Mallette]

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

Re: code freeze 3.2.5

[Ted Wilmes]

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 
> 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))]),
> >> >> > EdgeVertexStep(IN)]
> >> >> >
> >> >> > Final Traversal

Re: code freeze 3.2.5

[Stephen Mallette]

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 
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 > >
>> > 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))]),
>> >> > EdgeVertexStep(IN)]
>> >> >
>> >> > Final Traversal[TinkerGraphStep(vertex,[1]),
>> >> > VertexStep(OUT,edge), HasStep([weight.and(gt(0.0), lt(0.6))]),
>> >> > EdgeVertexStep(IN)]
>> >> >
>> >> > We likely need more direct serialization tests of P, but I think
>> those
>> >> > already exist in master. Made a note to review further after release.
>> >> >
>> >> >
>> >> > On Wed, Jun 14, 2017 at 3:57 PM, Robert Dale 
>> wrote:
>> >> >
>> >> >> Fix pushed to tp32 and master.

[jira] [Closed] (TINKERPOP-789) Choose then Enforce Semantics for Graph.close()

[stephen mallette (JIRA)]

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

stephen mallette closed TINKERPOP-789.
--
Resolution: Won't Do

I don't think there's a reason to burden providers with yet another batch of 
tests. Closing a graph can have wide meaning and it is probably best to leave 
it up to the graph to decide the best way to handle that. TinkerGraph's current 
close operation generally makes sense, though multiple calls to {{close()}} 
will repeatedly save a graph if a "save file location" is specified - a little 
odd. In any case, {{AutoCloseable}} seems to be implemented in a variety of 
ways in the java world so perhaps this behavior (or the fact that after 
{{close()}} you can still call methods on the graph like {{addVertex}}) is not 
so out of line. Consider {{ByteArrayInputStream.close()}} who's javadoc states: 
"Closing a ByteArrayInputStream has no effect. The methods in this class can be 
called after the stream has been closed without generating an IOException." 
Anyway, I think I will just update the javadoc on {{TinkerGraph.close()}} and 
close this out.

> Choose then Enforce Semantics for Graph.close()
> ---
>
> Key: TINKERPOP-789
> URL: https://issues.apache.org/jira/browse/TINKERPOP-789
> Project: TinkerPop
>  Issue Type: Improvement
>  Components: structure, test-suite
>Affects Versions: 3.0.2-incubating
>Reporter: stephen mallette
>Assignee: stephen mallette
>
> The semantics for {{Graph.close()}} are fairly open  right now.  See 
> TinkerGraph:
> {code}
> gremlin> graph = TinkerFactory.createModern()
> ==>tinkergraph[vertices:6 edges:6]
> gremlin> graph.close()
> ==>null
> gremlin> graph.vertices()
> ==>v[1]
> ==>v[2]
> ==>v[3]
> ==>v[4]
> ==>v[5]
> ==>v[6]
> {code}
> Seems like a call to {{close()}} should mean something especially since we 
> implement {{AutoCloseable}}.  I believe that most graphs throw exceptions 
> (Titan does {{IllegalStateException}} i think) if you try to access the graph 
> once {{close()}} is called.  



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

[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=16050787#comment-16050787
 ] 

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

GitHub user FlorianHockmann opened a pull request:

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

TINKERPOP-1552: Clean-up Gremlin-DotNet project files

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

This removes some obsolete configuration options and improves the package 
meta information. Especially the description was extended to reflect the 
current state of Gremlin-DotNet. This explanation can be removed as soon as the 
old Gremlin.Net driver is obsolete (probably when a first release version of 
Gremlin-DotNet is released).
The version is now 3.2.5-beta1.

I also enabled the generation of an XML document containing the 
documentation comments which will be displayed to the user with IntelliSense. 
The warning about missing comments had to be disabled for some files as we 
currently just don't have comments for those. I think that's ok for now, but we 
should try to find a way to create meaningful comments where they are missing 
right now for the first official (non-beta) release.

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

$ git pull https://github.com/FlorianHockmann/tinkerpop 
gremlin-dotnet-packagemetadata

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

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


commit 02955d4df4c1e16ec3fcd6977979badc44a8b91e
Author: Florian Hockmann 
Date:   2017-06-15T16:25:56Z

Clean-up Gremlin-DotNet project files

This removes some obsolete configuration options and improves the package 
meta information. Especially the description was extended to reflect the 
current state of Gremlin-DotNet. This explanation can be removed as soon as the 
old Gremlin.Net driver is obsolete (probably when a first release version of 
Gremlin-DotNet is released).
The version is now 3.2.5-beta1.

commit ab55e95de63efc6d670a7af50901f9c48a33501d
Author: Florian Hockmann 
Date:   2017-06-15T17:00:38Z

Let Gremlin-DotNet include the documentation comments

Every build now generates an XML document containing the documentation 
comments which will be displayed to the user with IntelliSense. The warning 
about missing comments had to be disabled for some files as we currently just 
don't have comments for those.




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

[FlorianHockmann]

GitHub user FlorianHockmann opened a pull request:

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

TINKERPOP-1552: Clean-up Gremlin-DotNet project files

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

This removes some obsolete configuration options and improves the package 
meta information. Especially the description was extended to reflect the 
current state of Gremlin-DotNet. This explanation can be removed as soon as the 
old Gremlin.Net driver is obsolete (probably when a first release version of 
Gremlin-DotNet is released).
The version is now 3.2.5-beta1.

I also enabled the generation of an XML document containing the 
documentation comments which will be displayed to the user with IntelliSense. 
The warning about missing comments had to be disabled for some files as we 
currently just don't have comments for those. I think that's ok for now, but we 
should try to find a way to create meaningful comments where they are missing 
right now for the first official (non-beta) release.

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

$ git pull https://github.com/FlorianHockmann/tinkerpop 
gremlin-dotnet-packagemetadata

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

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


commit 02955d4df4c1e16ec3fcd6977979badc44a8b91e
Author: Florian Hockmann 
Date:   2017-06-15T16:25:56Z

Clean-up Gremlin-DotNet project files

This removes some obsolete configuration options and improves the package 
meta information. Especially the description was extended to reflect the 
current state of Gremlin-DotNet. This explanation can be removed as soon as the 
old Gremlin.Net driver is obsolete (probably when a first release version of 
Gremlin-DotNet is released).
The version is now 3.2.5-beta1.

commit ab55e95de63efc6d670a7af50901f9c48a33501d
Author: Florian Hockmann 
Date:   2017-06-15T17:00:38Z

Let Gremlin-DotNet include the documentation comments

Every build now generates an XML document containing the documentation 
comments which will be displayed to the user with IntelliSense. The warning 
about missing comments had to be disabled for some files as we currently just 
don't have comments for those.




---
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=16050749#comment-16050749
 ] 

ASF GitHub Bot commented on TINKERPOP-915:
--

Github user spmallette commented on the issue:

https://github.com/apache/tinkerpop/pull/618
  
Sorry @krlohnes - if you're not following along we had a snag in 3.2.5 
release so the release branches still aren't open. Probably won't see this PR 
handled until next week some time at this rate.


> 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
  
Sorry @krlohnes - if you're not following along we had a snag in 3.2.5 
release so the release branches still aren't open. Probably won't see this PR 
handled until next week some time at this rate.


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

[jira] [Commented] (TINKERPOP-1489) Provide a Javascript Gremlin Language Variant

[ASF GitHub Bot (JIRA)]

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

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

Github user asfgit closed the pull request at:

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


> 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] [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=16050744#comment-16050744
 ] 

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

Github user spmallette commented on the issue:

https://github.com/apache/tinkerpop/pull/626
  
Merged - very cool. Tests work wonderfully. 


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

[GitHub] tinkerpop pull request #626: TINKERPOP-1489: Update Javascript GLV

[asfgit]

Github user asfgit closed the pull request at:

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


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

[spmallette]

Github user spmallette commented on the issue:

https://github.com/apache/tinkerpop/pull/626
  
Merged - very cool. Tests work wonderfully. 


---
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-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=16050710#comment-16050710
 ] 

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

Github user asfgit closed the pull request at:

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


> 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 #627: TINKERPOP-1552: Improve comments in Gremlin-Dot...

[asfgit]

Github user asfgit closed the pull request at:

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


---
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-1550) Make Graphite and Ganglia optional dependencies

[ASF GitHub Bot (JIRA)]

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

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

GitHub user spmallette opened a pull request:

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

TINKERPOP-1550 Made ganglia/graphite optional dependencies

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

These dependencies must now be installed manually by users. Updated docs 
and the LICENSE for Gremlin Server. Gets rid of the weird one-off exclusion of 
an LGPL license (couldn't support Ganglia out of the box anyway) and lessens 
transitive dependency burdens.

Builds with `mvn clean install && mvn verify -pl gremlin-server 
-DskipIntegrationTests=false && mvn verify -pl gremlin-console 
-DskipIntegrationTests=false`

VOTE +1

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

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

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

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


commit 945c23571fcccafb95f7c129d368955cd068c430
Author: Stephen Mallette 
Date:   2017-06-15T16:11:51Z

TINKERPOP-1550 Made ganglia/graphite optional dependencies

These dependencies must now be installed manually by users. Updated docs 
and the LICENSE for Gremlin Server.




> Make Graphite and Ganglia optional dependencies
> ---
>
> Key: TINKERPOP-1550
> URL: https://issues.apache.org/jira/browse/TINKERPOP-1550
> Project: TinkerPop
>  Issue Type: Improvement
>  Components: server
>Affects Versions: 3.2.3
>Reporter: stephen mallette
>Assignee: stephen mallette
>Priority: Minor
> Fix For: 3.3.0
>
>
> This ticket started out as "Provide a way to not specifically depend on and 
> package the various reporters tied to the Gremlin Server `MetricsManager`", 
> but while that is a nice idea, it ends up being more complicated than what is 
> required and at this point I haven't really heard of any users asking for the 
> ability to drop in other reporters. 
> Anyway, Ganglia/Graphite should be made optional dependencies as they aren't 
> really required for operation of Gremlin Server and it should be up to the 
> user to decide which they want to use and include. Plus, this gets rid of the 
> ugly problem of an LGPL dependency which we used to just exclude and thus 
> force the user to copy in manually. As a result, we kinda added stuff to the 
> distribution which didn't work out of the box anyway. Better to just avoid 
> the whole issue and not include them.



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

[GitHub] tinkerpop pull request #628: TINKERPOP-1550 Made ganglia/graphite optional d...

[spmallette]

GitHub user spmallette opened a pull request:

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

TINKERPOP-1550 Made ganglia/graphite optional dependencies

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

These dependencies must now be installed manually by users. Updated docs 
and the LICENSE for Gremlin Server. Gets rid of the weird one-off exclusion of 
an LGPL license (couldn't support Ganglia out of the box anyway) and lessens 
transitive dependency burdens.

Builds with `mvn clean install && mvn verify -pl gremlin-server 
-DskipIntegrationTests=false && mvn verify -pl gremlin-console 
-DskipIntegrationTests=false`

VOTE +1

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

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

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

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


commit 945c23571fcccafb95f7c129d368955cd068c430
Author: Stephen Mallette 
Date:   2017-06-15T16:11:51Z

TINKERPOP-1550 Made ganglia/graphite optional dependencies

These dependencies must now be installed manually by users. Updated docs 
and the LICENSE for Gremlin Server.




---
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-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=16050665#comment-16050665
 ] 

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

Github user FlorianHockmann commented on the issue:

https://github.com/apache/tinkerpop/pull/627
  
It shouldn't be too hard to create the link, but I don't really know where 
to include it. The `summary` element should just include a short description 
and the `remarks` element is only visible in the generated API docs I think. I 
also never saw a link included in the document comments. So I don't know how 
that would work.


> 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 #627: TINKERPOP-1552: Improve comments in Gremlin-DotNet

[FlorianHockmann]

Github user FlorianHockmann commented on the issue:

https://github.com/apache/tinkerpop/pull/627
  
It shouldn't be too hard to create the link, but I don't really know where 
to include it. The `summary` element should just include a short description 
and the `remarks` element is only visible in the generated API docs I think. I 
also never saw a link included in the document comments. So I don't know how 
that would work.


---
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 #627: TINKERPOP-1552: Improve comments in Gremlin-DotNet

[spmallette]

Github user spmallette commented on the issue:

https://github.com/apache/tinkerpop/pull/627
  
Nice additions. I wonder how hard it would be to figure out how to add a 
link to the official javadoc:


http://tinkerpop.apache.org/javadocs/x.y.z/full/org/apache/tinkerpop/gremlin/process/traversal/dsl/graph/GraphTraversal.html#addV--

I think the x.y.z could be dynamically driven based on the pom.xml without 
too much trouble. wdyt?


---
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-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=16050636#comment-16050636
 ] 

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

Github user spmallette commented on the issue:

https://github.com/apache/tinkerpop/pull/627
  
Nice additions. I wonder how hard it would be to figure out how to add a 
link to the official javadoc:


http://tinkerpop.apache.org/javadocs/x.y.z/full/org/apache/tinkerpop/gremlin/process/traversal/dsl/graph/GraphTraversal.html#addV--

I think the x.y.z could be dynamically driven based on the pom.xml without 
too much trouble. wdyt?


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

[jira] [Assigned] (TINKERPOP-1550) Make Graphite and Ganglia optional dependencies

[stephen mallette (JIRA)]

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

stephen mallette reassigned TINKERPOP-1550:
---

 Assignee: stephen mallette
Fix Version/s: 3.3.0
  Description: 
This ticket started out as "Provide a way to not specifically depend on and 
package the various reporters tied to the Gremlin Server `MetricsManager`", but 
while that is a nice idea, it ends up being more complicated than what is 
required and at this point I haven't really heard of any users asking for the 
ability to drop in other reporters. 

Anyway, Ganglia/Graphite should be made optional dependencies as they aren't 
really required for operation of Gremlin Server and it should be up to the user 
to decide which they want to use and include. Plus, this gets rid of the ugly 
problem of an LGPL dependency which we used to just exclude and thus force the 
user to copy in manually. As a result, we kinda added stuff to the distribution 
which didn't work out of the box anyway. Better to just avoid the whole issue 
and not include them.

  was:Provide a way to not specifically depend on and package the various 
reporters tied to the Gremlin Server `MetricsManager`.

  Summary: Make Graphite and Ganglia optional dependencies  (was: 
Dynamically load metrics for Gremlin Server)

> Make Graphite and Ganglia optional dependencies
> ---
>
> Key: TINKERPOP-1550
> URL: https://issues.apache.org/jira/browse/TINKERPOP-1550
> Project: TinkerPop
>  Issue Type: Improvement
>  Components: server
>Affects Versions: 3.2.3
>Reporter: stephen mallette
>Assignee: stephen mallette
>Priority: Minor
> Fix For: 3.3.0
>
>
> This ticket started out as "Provide a way to not specifically depend on and 
> package the various reporters tied to the Gremlin Server `MetricsManager`", 
> but while that is a nice idea, it ends up being more complicated than what is 
> required and at this point I haven't really heard of any users asking for the 
> ability to drop in other reporters. 
> Anyway, Ganglia/Graphite should be made optional dependencies as they aren't 
> really required for operation of Gremlin Server and it should be up to the 
> user to decide which they want to use and include. Plus, this gets rid of the 
> ugly problem of an LGPL dependency which we used to just exclude and thus 
> force the user to copy in manually. As a result, we kinda added stuff to the 
> distribution which didn't work out of the box anyway. Better to just avoid 
> the whole issue and not include them.



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

[GitHub] tinkerpop pull request #627: TINKERPOP-1552: Improve comments in Gremlin-Dot...

[FlorianHockmann]

GitHub user FlorianHockmann opened a pull request:

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

TINKERPOP-1552: Improve comments in Gremlin-DotNet

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

This change adds many comments to Gremlin-DotNet, especially for the GLV 
part. Some comments where taken from the respective Java classes. It also adds 
comments to most of the auto-generated methods to tell the user what the method 
does.

Example for the anonymous class `__`:
```cs
/// 
/// Spawns a  and adds the 
out step to that traversal.
/// 
public static GraphTraversal Out(params object[] args)
{
return new GraphTraversal().Out(args);
}
```
And for a `GraphTraversal` step:
```cs
/// 
/// Adds the aggregate step to this .
/// 
public GraphTraversal< S , E > Aggregate (params object[] args)
{
Bytecode.AddStep("aggregate", args);
return Wrap< S , E >(this);
}
```
Apart from the comment improvements, this also marks 
`GraphTraversalSource.WithBindings` as obsolete as it is also marked as 
deprecated in Gremlin-Java.

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

$ git pull https://github.com/FlorianHockmann/tinkerpop dotnet-glv-comments

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

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


commit a0e6c22324ec078053afa14f5123a729002f60db
Author: Florian Hockmann 
Date:   2017-06-15T13:09:58Z

Improve comments in Gremlin-DotNet, especially for the GLV part




---
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-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=16050503#comment-16050503
 ] 

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

GitHub user FlorianHockmann opened a pull request:

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

TINKERPOP-1552: Improve comments in Gremlin-DotNet

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

This change adds many comments to Gremlin-DotNet, especially for the GLV 
part. Some comments where taken from the respective Java classes. It also adds 
comments to most of the auto-generated methods to tell the user what the method 
does.

Example for the anonymous class `__`:
```cs
/// 
/// Spawns a  and adds the 
out step to that traversal.
/// 
public static GraphTraversal Out(params object[] args)
{
return new GraphTraversal().Out(args);
}
```
And for a `GraphTraversal` step:
```cs
/// 
/// Adds the aggregate step to this .
/// 
public GraphTraversal< S , E > Aggregate (params object[] args)
{
Bytecode.AddStep("aggregate", args);
return Wrap< S , E >(this);
}
```
Apart from the comment improvements, this also marks 
`GraphTraversalSource.WithBindings` as obsolete as it is also marked as 
deprecated in Gremlin-Java.

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

$ git pull https://github.com/FlorianHockmann/tinkerpop dotnet-glv-comments

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

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


commit a0e6c22324ec078053afa14f5123a729002f60db
Author: Florian Hockmann 
Date:   2017-06-15T13:09:58Z

Improve comments in Gremlin-DotNet, especially for the GLV part




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

Re: code freeze 3.2.5

[Stephen Mallette]

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 
> > 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  >
> >> 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))]),
> >> > EdgeVertexStep(IN)]
> >> >
> >> > Final Traversal[TinkerGraphStep(vertex,[1]),
> >> > VertexStep(OUT,edge), HasStep([weight.and(gt(0.0), lt(0.6))]),
> >> > EdgeVertexStep(IN)]
> >> >
> >> > We likely need more direct serialization tests of P, but I think those
> >> > already exist in master. Made a note to review further after release.
> >> >
> >> >
> >> > On Wed, Jun 14, 2017 at 3:57 PM, Robert Dale 
> wrote:
> >> >
> >> >> Fix pushed to tp32 and master.
> >> >>
> >> >> Robert Dale
> >> >>
> >> >> On Wed, Jun 14, 2017 at 3:50 PM, Stephen Mallette <
> >> spmalle...@gmail.com>
> >> >> wrote:
> >> >>
> >> >> > Well - now that the VOTE on 3.2.5 is cancelled we can now fix up
> >> these
> >> >> > couple of issues, specifically:
> >> >> >
> >> >> > 1. anyStepRecursively() bug (kuppitz is going to handle that)
> >> >> > 2. Gryo serialization of 

Re: code freeze 3.2.5

[Robert Dale]

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 
> 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 
>> 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))]),
>> > EdgeVertexStep(IN)]
>> >
>> > Final Traversal[TinkerGraphStep(vertex,[1]),
>> > VertexStep(OUT,edge), HasStep([weight.and(gt(0.0), lt(0.6))]),
>> > EdgeVertexStep(IN)]
>> >
>> > We likely need more direct serialization tests of P, but I think those
>> > already exist in master. Made a note to review further after release.
>> >
>> >
>> > On Wed, Jun 14, 2017 at 3:57 PM, Robert Dale  wrote:
>> >
>> >> Fix pushed to tp32 and master.
>> >>
>> >> Robert Dale
>> >>
>> >> On Wed, Jun 14, 2017 at 3:50 PM, Stephen Mallette <
>> spmalle...@gmail.com>
>> >> wrote:
>> >>
>> >> > Well - now that the VOTE on 3.2.5 is cancelled we can now fix up
>> these
>> >> > couple of issues, specifically:
>> >> >
>> >> > 1. anyStepRecursively() bug (kuppitz is going to handle that)
>> >> > 2. Gryo serialization of inside() (robert dale, you had the fix for
>> >> that -
>> >> > do you want to just CTR that in? though i'm also interested in why
>> tests
>> >> > didn't catch that problem)
>> >> >
>> >> > I'm going to leave out the other issue noted:
>> >> >
>> >> > https://issues.apache.org/jira/browse/TINKERPOP-1691
>> >> >
>> >> > as it is not user facing  - just something related to the test suite
>> >> > (providers at least have a workaround for that if they hit problems
>> as
>> >> they
>> >> > can @OptOut).
>> >> >
>> >> > I also 

Re: code freeze 3.2.5

[Robert Dale]

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 
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 
> 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))]),
> > EdgeVertexStep(IN)]
> >
> > Final Traversal[TinkerGraphStep(vertex,[1]),
> > VertexStep(OUT,edge), HasStep([weight.and(gt(0.0), lt(0.6))]),
> > EdgeVertexStep(IN)]
> >
> > We likely need more direct serialization tests of P, but I think those
> > already exist in master. Made a note to review further after release.
> >
> >
> > On Wed, Jun 14, 2017 at 3:57 PM, Robert Dale  wrote:
> >
> >> Fix pushed to tp32 and master.
> >>
> >> Robert Dale
> >>
> >> On Wed, Jun 14, 2017 at 3:50 PM, Stephen Mallette  >
> >> wrote:
> >>
> >> > Well - now that the VOTE on 3.2.5 is cancelled we can now fix up these
> >> > couple of issues, specifically:
> >> >
> >> > 1. anyStepRecursively() bug (kuppitz is going to handle that)
> >> > 2. Gryo serialization of inside() (robert dale, you had the fix for
> >> that -
> >> > do you want to just CTR that in? though i'm also interested in why
> tests
> >> > didn't catch that problem)
> >> >
> >> > I'm going to leave out the other issue noted:
> >> >
> >> > https://issues.apache.org/jira/browse/TINKERPOP-1691
> >> >
> >> > as it is not user facing  - just something related to the test suite
> >> > (providers at least have a workaround for that if they hit problems as
> >> they
> >> > can @OptOut).
> >> >
> >> > I also don't intend to deploy another SNAPSHOT so i'm just going to
> >> keep us
> >> > on "3.2.5" and not revert to "3.2.5-SNAPSHOT". Let's just patch this
> up
> >> > then I'll start on a fresh release packaging tomorrow.
> >> >
> >> > Any other concerns?
> >> >
> >> >
> >> >
> >> > On Tue, Jun 6, 2017 at 6:27 AM, Robert Dale 
> 

Re: code freeze 3.2.5

[Stephen Mallette]

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 
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))]),
> EdgeVertexStep(IN)]
>
> Final Traversal[TinkerGraphStep(vertex,[1]),
> VertexStep(OUT,edge), HasStep([weight.and(gt(0.0), lt(0.6))]),
> EdgeVertexStep(IN)]
>
> We likely need more direct serialization tests of P, but I think those
> already exist in master. Made a note to review further after release.
>
>
> On Wed, Jun 14, 2017 at 3:57 PM, Robert Dale  wrote:
>
>> Fix pushed to tp32 and master.
>>
>> Robert Dale
>>
>> On Wed, Jun 14, 2017 at 3:50 PM, Stephen Mallette 
>> wrote:
>>
>> > Well - now that the VOTE on 3.2.5 is cancelled we can now fix up these
>> > couple of issues, specifically:
>> >
>> > 1. anyStepRecursively() bug (kuppitz is going to handle that)
>> > 2. Gryo serialization of inside() (robert dale, you had the fix for
>> that -
>> > do you want to just CTR that in? though i'm also interested in why tests
>> > didn't catch that problem)
>> >
>> > I'm going to leave out the other issue noted:
>> >
>> > https://issues.apache.org/jira/browse/TINKERPOP-1691
>> >
>> > as it is not user facing  - just something related to the test suite
>> > (providers at least have a workaround for that if they hit problems as
>> they
>> > can @OptOut).
>> >
>> > I also don't intend to deploy another SNAPSHOT so i'm just going to
>> keep us
>> > on "3.2.5" and not revert to "3.2.5-SNAPSHOT". Let's just patch this up
>> > then I'll start on a fresh release packaging tomorrow.
>> >
>> > Any other concerns?
>> >
>> >
>> >
>> > On Tue, Jun 6, 2017 at 6:27 AM, Robert Dale  wrote:
>> >
>> > > That will probably work too. I use https://wummel.github.io/linkc
>> hecker/
>> > >
>> > >
>> > > Robert Dale
>> > >
>> > > On Tue, Jun 6, 2017 at 6:20 AM, Daniel Kuppitz 
>> wrote:
>> > >
>> > > > https://validator.w3.org/checklink
>> > > >
>> > > > On Tue, Jun 6, 2017 at 12:18 PM, Stephen Mallette <
>> > spmalle...@gmail.com>
>> > > > wrote:
>> > > >
>> > > > > huh - that's a neat idea. is there a specific tool you use?
>> > > > >
>> > > > > On Tue, Jun 6, 2017 at 5:48 AM, Robert Dale 

Re: code freeze 3.2.5

[Stephen Mallette]

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))]),
EdgeVertexStep(IN)]

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

We likely need more direct serialization tests of P, but I think those
already exist in master. Made a note to review further after release.


On Wed, Jun 14, 2017 at 3:57 PM, Robert Dale  wrote:

> Fix pushed to tp32 and master.
>
> Robert Dale
>
> On Wed, Jun 14, 2017 at 3:50 PM, Stephen Mallette 
> wrote:
>
> > Well - now that the VOTE on 3.2.5 is cancelled we can now fix up these
> > couple of issues, specifically:
> >
> > 1. anyStepRecursively() bug (kuppitz is going to handle that)
> > 2. Gryo serialization of inside() (robert dale, you had the fix for that
> -
> > do you want to just CTR that in? though i'm also interested in why tests
> > didn't catch that problem)
> >
> > I'm going to leave out the other issue noted:
> >
> > https://issues.apache.org/jira/browse/TINKERPOP-1691
> >
> > as it is not user facing  - just something related to the test suite
> > (providers at least have a workaround for that if they hit problems as
> they
> > can @OptOut).
> >
> > I also don't intend to deploy another SNAPSHOT so i'm just going to keep
> us
> > on "3.2.5" and not revert to "3.2.5-SNAPSHOT". Let's just patch this up
> > then I'll start on a fresh release packaging tomorrow.
> >
> > Any other concerns?
> >
> >
> >
> > On Tue, Jun 6, 2017 at 6:27 AM, Robert Dale  wrote:
> >
> > > That will probably work too. I use https://wummel.github.io/
> linkchecker/
> > >
> > >
> > > Robert Dale
> > >
> > > On Tue, Jun 6, 2017 at 6:20 AM, Daniel Kuppitz 
> wrote:
> > >
> > > > https://validator.w3.org/checklink
> > > >
> > > > On Tue, Jun 6, 2017 at 12:18 PM, Stephen Mallette <
> > spmalle...@gmail.com>
> > > > wrote:
> > > >
> > > > > huh - that's a neat idea. is there a specific tool you use?
> > > > >
> > > > > On Tue, Jun 6, 2017 at 5:48 AM, Robert Dale 
> > wrote:
> > > > >
> > > > > > Linkchecker passes.
> > > > > >
> > > > > > Robert Dale
> > > > > >
> > > > > > On Mon, Jun 5, 2017 at 6:38 AM, Stephen Mallette <
> > > spmalle...@gmail.com
> > > > >
> > > > > > wrote:
> > > > > >
> > > > > > > I published latest docs for 3.2.5-SNAPSHOT:
> > > > > > >
> > > > > > > http://tinkerpop.apache.org/docs/3.2.5-SNAPSHOT/
> > > > > > >
> > > > > > > and made another deployment to the