Re: [DISCUSS] Name of 3.4.x

May I suggest: Avant-gremlin (image attached). Keepin' the OmniGraffle tradition alive. Didn't really think about a number, but "forty two" comes to mind. Josh On Tue, Apr 17, 2018 at 5:35 AM, Stephen Mallette wrote: > We still need a name and logo for 3.4.x - we have plenty of decent names

Re: [DISCUSS] Depth First Repeat step

TinkerPop makes no guarantees about the order of elements unless you specify an explicit order. This also goes back to the fact that certain strategies (LazyBarrier-, RepeatUnroll- and PathRetractionStrategy) add NoOpBarrierSteps to your traversal, which ultimately turns it into a DFS/BFS mix. Chec

[jira] [Created] (TINKERPOP-1939) running spark-gremlin in gremlin console

Prashanth Madi created TINKERPOP-1939: - Summary: running spark-gremlin in gremlin console Key: TINKERPOP-1939 URL: https://issues.apache.org/jira/browse/TINKERPOP-1939 Project: TinkerPop

Re: [DISCUSS] Depth First Repeat step

> Also it seems to me that DFS only really applies to repeat() with an > emit(). > g.V().hasLabel("A").repeat().times(2) gets rewritten as > g.V().hasLabel("A").out().out(). Are their subtleties that I am not > aware of or does DFV vs BFS not matter in this case? When I read this I thought: clearl

Re: [DISCUSS] Depth First Repeat step

Hi, I agree with the question about whether this will affect more than just repeat()? I prefer that the semantics of the traversal be specified in the traversal as a first class citizen. i.e. with order(SearchAlgo). Strategies are to my mind internal to an implementation. In Robert's example

[jira] [Commented] (TINKERPOP-1936) Performance enhancement to Bytecode deserialization

[ https://issues.apache.org/jira/browse/TINKERPOP-1936?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16440833#comment-16440833 ] ASF GitHub Bot commented on TINKERPOP-1936: --- Github user robertdale commente

[GitHub] tinkerpop issue #839: TINKERPOP-1936 Improved performance of Bytecode deseri...

Github user robertdale commented on the issue: https://github.com/apache/tinkerpop/pull/839 VOTE +1 ---

Re: [DISCUSS] Depth First Repeat step

+1 on DFS -1 on order(SearchAlgo) It seems like a strategy may be more appropriate. It could affect more than just repeat(). And how would this interact with LazyBarrierStrategy? Maybe the default should be DFS with LazyBarrierStrategy. Then LazyBarrierStrategy can be removed with 'withoutStrat

[jira] [Commented] (TINKERPOP-1822) Repeat should depth first search

[ https://issues.apache.org/jira/browse/TINKERPOP-1822?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16440812#comment-16440812 ] ASF GitHub Bot commented on TINKERPOP-1822: --- Github user krlohnes commented

[GitHub] tinkerpop issue #838: TINKERPOP-1822: Add Depth First Search repeat step opt...

Github user krlohnes commented on the issue: https://github.com/apache/tinkerpop/pull/838 Thanks @spmallette I'll hold off on any more changes until things are worked out with that DISCUSS thread ---

Re: [DISCUSS] Depth First Repeat step

I assume you are referring to these booleans: I should have written “conditionals checking the SearchAlgo“. Like these which for now I have defaulting to BFS

Re: [DISCUSS] Name of 3.4.x

We still need a name and logo for 3.4.x - we have plenty of decent names, but no one threw up logo ideas. Can't really go with a name without a logo - we need both. Is anyone planning on following up their suggestion with a logo? If not, I'll just do mine and we can get this settled up. Thanks. On

Re: [DISCUSS] Depth First Repeat step

Thanks for the summary. Just a quick note - I'd not worry about the GLV tests for now. That part should be easy to sort out. Let's first make sure that we get clear on the other items first before digging too deeply there. On an administrative front, I think that this change should just go to 3.4.

Re: [DISCUSS] Depth First Repeat step

Stephen, That’s a fair summary. I had an immediate need for it, so I developed something based on Michel Pollmeier’s work and a modification to the syntax Pieter Martin suggested in the Jira

Re: GRAPHSON 3.0 serializing, IO Ref, and parent map exception

Well, the history goes more like this: The massive break came between GraphSON 1.0 and 2.0+types, somewhere along the 3.2.x line. For 3.3.0 we introduced GraphSON 3.0 which was mostly compatible with 2.0+types but still not perfectly as new types were added and inconsistencies fixed. We also opted