Re: [DISCUSS] Name of 3.4.x

2018-04-17 Thread Joshua Shinavier 
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,
> 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 Mon, Mar 5, 2018 at 4:25 PM, Stephen Mallette 
> wrote:
>
> > it just needs to be "music related" and "have something numeric" about
> it.
> >
> > On Mon, Mar 5, 2018 at 4:20 PM, David Brown  wrote:
> >
> >> Does it need to have a 3 or 4 in it?
> >>
> >> - 3 Little Gremlins (Marley)
> >> - 4 Gremlins of the Apocalypse (Kind of like Clash)
> >>
> >> Idk I do like the Gambler...
> >>
> >>
> >> On Mon, Mar 5, 2018 at 12:53 PM Stephen Mallette 
> >> wrote:
> >>
> >> > So...we have a few good suggestions in hand (and I added one):
> >> >
> >> > 1. 4 Seasons of Gremlin - unclear if we're talking Boyz II Men or
> >> Vivaldi
> >> > here...
> >> > 2. Four Rusted Gremlins - Marilyn Manson
> >> > 3. Three Times a Gremlin - from the Commodores, though I think Gremlin
> >> > would prefer the Kenny Rogers styling of it - I mean, look at this
> >> > https://www.youtube.com/watch?v=Ok7becfXoJE :D
> >> >
> >> > Sorry Jason, gotta disqualify your suggestion as it doesn't have a
> >> "number
> >> > reference" in it.
> >> >
> >> > Anyone have any other ideas?
> >> >
> >> >
> >> >
> >> > On Thu, Mar 1, 2018 at 8:33 AM, Jason Plurad 
> wrote:
> >> >
> >> > > Boyz II Men - ha, I hadn't considered that angle. I assumed the 4
> >> Seasons
> >> > > was a Vivaldi reference.
> >> > >
> >> > > How about David Bowie? The Gremlin Who Sold the World
> >> > > On Thu, Mar 1, 2018 at 8:06 AM Stephen Mallette <
> spmalle...@gmail.com
> >> >
> >> > > wrote:
> >> > >
> >> > > > I'm guessing at the reference for "4 Seasons of Gremlin" - are we
> >> > talking
> >> > > > Boyz || Men and "4 Seasons of Loneliness"?
> >> > > >
> >> > > > >  Yeah, I'd like to see what Gremlyn Manson would look like!
> >> > > >
> >> > > > would he look that much different than our "Nine Inch Nails
> >> Gremlin"?
> >> > > >
> >> > > >
> >> > > >
> >> > > > On Tue, Feb 27, 2018 at 10:58 AM, Robert Dale 
> >> > wrote:
> >> > > >
> >> > > > > Yeah, I'd like to see what Gremlyn Manson would look like!
> >> > > > >
> >> > > > > Robert Dale
> >> > > > >
> >> > > > > On Tue, Feb 27, 2018 at 10:40 AM, Daniel Kuppitz
>  >> >
> >> > > > wrote:
> >> > > > >
> >> > > > > > Four Rusted Gremlins (reference
> >> > > > > > ) :)
> >> > > > > >
> >> > > > > > On Tue, Feb 27, 2018 at 7:47 AM, Stephen Mallette <
> >> > > > spmalle...@gmail.com>
> >> > > > > > wrote:
> >> > > > > >
> >> > > > > > > We need a release name and associated Gremlin logo for the
> >> 3.4.x
> >> > > > series
> >> > > > > > of
> >> > > > > > > TinkerPop. Recall that names should be related to music and
> >> > > include a
> >> > > > > > > number. Thus far we've had:
> >> > > > > > >
> >> > > > > > > * Gremlin Symphony #40 in G Minor (3.3.x)
> >> > > > > > > * Nine Inch Gremlins (3.2.x)
> >> > > > > > > * A 187 On The Undercover Gremlinz (3.1.x)
> >> > > > > > > * A Gremlin Rāga in 7/16 Time (3.0.x)
> >> > > > > > >
> >> > > > > > > Please submit a name with a logo idea - a name where we
> can't
> >> > get a
> >> > > > > logo
> >> > > > > > > made doesn't really work too well. Thanks.
> >> > > > > > >
> >> > > > > >
> >> > > > >
> >> > > >
> >> > >
> >> >
> >>
> >>
> >> --
> >> David M. Brown
> >> R.A. CulturePlex Lab, Western University
> >>
> >
> >
>

Re: [DISCUSS] Depth First Repeat step

2018-04-17 Thread Daniel Kuppitz 
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. Check the .explain() output of your traversal to see which
strategy adds which steps.

Cheers,
Daniel


On Tue, Apr 17, 2018 at 4:45 PM, Michael Pollmeier <
mich...@michaelpollmeier.com> wrote:

> > 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: clearly `.out().out()` is DFS for OLTP,
> that's also what the documentation says, e.g. in this nice infographic
> http://tinkerpop.apache.org/docs/current/images/oltp-vs-olap.png
>
> However, looks like that's not the case. Has my life been a lie? Setting
> up a simple flat graph to make things more obvious:
> v3 <- v1 <- v0 -> v2 -> v4
>
> ```
> graph = TinkerGraph.open()
> v0 = graph.addVertex("l0")
> v1 = graph.addVertex("l1")
> v2 = graph.addVertex("l1")
> v3 = graph.addVertex("l2")
> v4 = graph.addVertex("l2")
> v0.addEdge("e", v2)
> v2.addEdge("e", v4)
> v0.addEdge("e", v1)
> v1.addEdge("e", v3)
> g = graph.traversal()
> g.V(v0).out().sideEffect{println(it)}.out().sideEffect{println(it)}
> ```
>
> Prints:
> v[2]
> v[1]
> v[4]
> ==>v[4]
> v[3]
> ==>v[3]
>
> If this was OLTP the output would be:
> v[2]
> v[4]
> ==>v[4]
> v[1]
> v[3]
> ==>v[3]
>
> Cheers
> Michael
>
> On 18/04/18 02:58, pieter gmail wrote:
> > 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 LazyBarrierStrategy may be replaced/removed by an implementation
> > for whatever internal reason they have.
> >
> > Regarding the default, I am fine with any default but am wondering
> > whether it would be worthwhile for the default to be overridden at a
> > global level at not just per traversal? That way the impact can also be
> > alleviated when folks upgrade.
> >
> > 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?
> >
> > Cheers
> > Pieter
> >
> > On 17/04/2018 14:58, Robert Dale wrote:
> >> +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 'withoutStrategies()' and then it works just like
> >> everything else.  I'd prefer consistency with the way everything else
> >> works.
> >>
> >>
> >>
> >> Robert Dale
> >>
> >> On Tue, Apr 17, 2018 at 8:11 AM, Stephen Mallette  >
> >> wrote:
> >>
> >>> 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.0/master (so it's currently targeted to the right branch
> >>> actually) as
> >>> it sounds like we want DFS to be the default and that could be a
> >>> breaking
> >>> change as the semantics of the traversal shift a bit. So that's one
> >>> issue
> >>> to make sure we're all happy with.
> >>>
> >>> A next issue would be the API from the user perspective - thanks for
> the
> >>> link to that JIRA btw - I see I was involved in that conversation a
> >>> little
> >>> bit but then dropped off. You'd commented that you preferred a per loop
> >>> configuration for search approach which is what you stuck with for the
> >>> implementation. I guess I can see that there could be some value in
> >>> having
> >>> that ability. That said, I'm not sure that I like the overload of
> >>> order()
> >>> as the method for doing that:
> >>>
> >>> g.V().has("name", "marko").
> >>> repeat(__.outE().order().by("weight", decr).inV()).
> >>>   emit().
> >>>   order(SearchAlgo.DFS)
> >>>
> >>> Still thinking about what else we might do there, but perhaps that
> >>> can wait
> >>> a bit as I still need to study your changes in detail. Regarding:
> >>>
>    The barrier step that Daniel described doesn’t currently work since
> >>> there’s basically booleans in the

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

2018-04-17 Thread Prashanth Madi (JIRA) 
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
  Issue Type: Task
  Components: plugin
Affects Versions: 3.3.2
Reporter: Prashanth Madi


After installing spark-gremlin, if we try to start gremlin console. it would 
give below error..

Caused by: groovy.lang.GroovyRuntimeException: Conflicting module versions. 
Module [groovy-swing is loaded in version 2.4.14 and you are trying to load 
version 2.4.11

 

I can workaround it by deleting files manually but there should an option to 
ignore such error or use latest version in future releases. Also, if possible 
update spark-gremlin dependencies



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

Re: [DISCUSS] Depth First Repeat step

2018-04-17 Thread Michael Pollmeier 
> 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: clearly `.out().out()` is DFS for OLTP,
that's also what the documentation says, e.g. in this nice infographic
http://tinkerpop.apache.org/docs/current/images/oltp-vs-olap.png

However, looks like that's not the case. Has my life been a lie? Setting
up a simple flat graph to make things more obvious:
v3 <- v1 <- v0 -> v2 -> v4

```
graph = TinkerGraph.open()
v0 = graph.addVertex("l0")
v1 = graph.addVertex("l1")
v2 = graph.addVertex("l1")
v3 = graph.addVertex("l2")
v4 = graph.addVertex("l2")
v0.addEdge("e", v2)
v2.addEdge("e", v4)
v0.addEdge("e", v1)
v1.addEdge("e", v3)
g = graph.traversal()
g.V(v0).out().sideEffect{println(it)}.out().sideEffect{println(it)}
```

Prints:
v[2]
v[1]
v[4]
==>v[4]
v[3]
==>v[3]

If this was OLTP the output would be:
v[2]
v[4]
==>v[4]
v[1]
v[3]
==>v[3]

Cheers
Michael

On 18/04/18 02:58, pieter gmail wrote:
> 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 LazyBarrierStrategy may be replaced/removed by an implementation
> for whatever internal reason they have.
> 
> Regarding the default, I am fine with any default but am wondering
> whether it would be worthwhile for the default to be overridden at a
> global level at not just per traversal? That way the impact can also be
> alleviated when folks upgrade.
> 
> 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?
> 
> Cheers
> Pieter
> 
> On 17/04/2018 14:58, Robert Dale wrote:
>> +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 'withoutStrategies()' and then it works just like
>> everything else.  I'd prefer consistency with the way everything else
>> works.
>>
>>
>>
>> Robert Dale
>>
>> On Tue, Apr 17, 2018 at 8:11 AM, Stephen Mallette 
>> wrote:
>>
>>> 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.0/master (so it's currently targeted to the right branch
>>> actually) as
>>> it sounds like we want DFS to be the default and that could be a
>>> breaking
>>> change as the semantics of the traversal shift a bit. So that's one
>>> issue
>>> to make sure we're all happy with.
>>>
>>> A next issue would be the API from the user perspective - thanks for the
>>> link to that JIRA btw - I see I was involved in that conversation a
>>> little
>>> bit but then dropped off. You'd commented that you preferred a per loop
>>> configuration for search approach which is what you stuck with for the
>>> implementation. I guess I can see that there could be some value in
>>> having
>>> that ability. That said, I'm not sure that I like the overload of
>>> order()
>>> as the method for doing that:
>>>
>>> g.V().has("name", "marko").
>>>     repeat(__.outE().order().by("weight", decr).inV()).
>>>   emit().
>>>   order(SearchAlgo.DFS)
>>>
>>> Still thinking about what else we might do there, but perhaps that
>>> can wait
>>> a bit as I still need to study your changes in detail. Regarding:
>>>
   The barrier step that Daniel described doesn’t currently work since
>>> there’s basically booleans in the RepeatStep on whether or not to
>>> stash the
>>> starts to make the RepeatStep depth first.
>>>
>>> I assume you are referring to these booleans:
>>>
>>> https://github.com/apache/tinkerpop/blob/fe8ee98f6967c7b0f0ee7f2cf2d105
>>> 31b68fab8b/gremlin-core/src/main/java/org/apache/
>>> tinkerpop/gremlin/process/traversal/step/branch/RepeatStep.java#L46-L47
>>>
>>> ?
>>>
>>>
>>>
>>> On Tue, Apr 17, 2018 at 7:37 AM, Keith Lohnes  wrote:
>>>
 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: [DISCUSS] Depth First Repeat step

2018-04-17 Thread pieter gmail 

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 LazyBarrierStrategy may be replaced/removed by an implementation 
for whatever internal reason they have.


Regarding the default, I am fine with any default but am wondering 
whether it would be worthwhile for the default to be overridden at a 
global level at not just per traversal? That way the impact can also be 
alleviated when folks upgrade.


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?


Cheers
Pieter

On 17/04/2018 14:58, Robert Dale wrote:

+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 'withoutStrategies()' and then it works just like
everything else.  I'd prefer consistency with the way everything else works.



Robert Dale

On Tue, Apr 17, 2018 at 8:11 AM, Stephen Mallette 
wrote:


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.0/master (so it's currently targeted to the right branch actually) as
it sounds like we want DFS to be the default and that could be a breaking
change as the semantics of the traversal shift a bit. So that's one issue
to make sure we're all happy with.

A next issue would be the API from the user perspective - thanks for the
link to that JIRA btw - I see I was involved in that conversation a little
bit but then dropped off. You'd commented that you preferred a per loop
configuration for search approach which is what you stuck with for the
implementation. I guess I can see that there could be some value in having
that ability. That said, I'm not sure that I like the overload of order()
as the method for doing that:

g.V().has("name", "marko").
repeat(__.outE().order().by("weight", decr).inV()).
  emit().
  order(SearchAlgo.DFS)

Still thinking about what else we might do there, but perhaps that can wait
a bit as I still need to study your changes in detail. Regarding:


  The barrier step that Daniel described doesn’t currently work since

there’s basically booleans in the RepeatStep on whether or not to stash the
starts to make the RepeatStep depth first.

I assume you are referring to these booleans:

https://github.com/apache/tinkerpop/blob/fe8ee98f6967c7b0f0ee7f2cf2d105
31b68fab8b/gremlin-core/src/main/java/org/apache/
tinkerpop/gremlin/process/traversal/step/branch/RepeatStep.java#L46-L47

?



On Tue, Apr 17, 2018 at 7:37 AM, Keith Lohnes  wrote:


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

with DFS being explicit.

The semantics I used were g.V().repeat(out()).order(DFS), putting the
order
clause outside of the repeat. It made it simpler for me to develop and
seemed nice to make that DFS vs BFS explicit. The barrier step that

Daniel

described doesn’t currently work since there’s basically booleans in the
RepeatStep on whether or not to stash the starts to make the RepeatStep
depth first.

I added a test for the DFS, though I’ve had some issues getting things to
run re: .net tests and some other tests timing out. I have some more

tests

I'd like to write based off issues that I ran into testing this in the
console (k-ary trees, until/emit before the repeat vs after), but I

really

wanted to get this out there for people to take a look at and see if it
could work out.
​

On Mon, Apr 16, 2018 at 7:29 PM Stephen Mallette 
wrote:


  Keith, I have to admit that I didn't really follow this general body

of

work closely, which include this pull request, the earlier one from

Michael

Pollmeier, the JIRA and I think some discussion somewhere on one of the
mailing lists. As best I have gathered from what I did follow, I feel

like

the focus of this work so far was mostly related to "can someone get it

to

actually work", but not a lot about other aspects like testing, api,
release branch to apply

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

2018-04-17 Thread ASF GitHub Bot (JIRA) 

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

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

Github user robertdale commented on the issue:

https://github.com/apache/tinkerpop/pull/839
  
VOTE +1


> Performance enhancement to Bytecode deserialization
> ---
>
> Key: TINKERPOP-1936
> URL: https://issues.apache.org/jira/browse/TINKERPOP-1936
> Project: TinkerPop
>  Issue Type: Improvement
>  Components: io
>Affects Versions: 3.2.8
>Reporter: stephen mallette
>Assignee: stephen mallette
>Priority: Major
> Fix For: 3.4.0, 3.2.9, 3.3.3
>
>
> There is a bad bottleneck in Jackson deserialization of {{Bytecode}}. It 
> doesn't become extremely apparent until higher levels of load are reached and 
> I think is even more evident after the latest bump in Jackson version where a 
> bug fix in Jackson itself changed the way in which deserialization caching 
> for collections was handled. {{Bytecode}} deserialization was relying on the 
> standard Jackson collection deserializers and it costs quite considerably in 
> terms of synchronized access to the deserializer cache and to the reflection 
> calls required to sort out types.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

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

2018-04-17 Thread robertdale 
Github user robertdale commented on the issue:

https://github.com/apache/tinkerpop/pull/839
  
VOTE +1


---

Re: [DISCUSS] Depth First Repeat step

2018-04-17 Thread Robert Dale 
+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 'withoutStrategies()' and then it works just like
everything else.  I'd prefer consistency with the way everything else works.



Robert Dale

On Tue, Apr 17, 2018 at 8:11 AM, Stephen Mallette 
wrote:

> 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.0/master (so it's currently targeted to the right branch actually) as
> it sounds like we want DFS to be the default and that could be a breaking
> change as the semantics of the traversal shift a bit. So that's one issue
> to make sure we're all happy with.
>
> A next issue would be the API from the user perspective - thanks for the
> link to that JIRA btw - I see I was involved in that conversation a little
> bit but then dropped off. You'd commented that you preferred a per loop
> configuration for search approach which is what you stuck with for the
> implementation. I guess I can see that there could be some value in having
> that ability. That said, I'm not sure that I like the overload of order()
> as the method for doing that:
>
> g.V().has("name", "marko").
>repeat(__.outE().order().by("weight", decr).inV()).
>  emit().
>  order(SearchAlgo.DFS)
>
> Still thinking about what else we might do there, but perhaps that can wait
> a bit as I still need to study your changes in detail. Regarding:
>
> >  The barrier step that Daniel described doesn’t currently work since
> there’s basically booleans in the RepeatStep on whether or not to stash the
> starts to make the RepeatStep depth first.
>
> I assume you are referring to these booleans:
>
> https://github.com/apache/tinkerpop/blob/fe8ee98f6967c7b0f0ee7f2cf2d105
> 31b68fab8b/gremlin-core/src/main/java/org/apache/
> tinkerpop/gremlin/process/traversal/step/branch/RepeatStep.java#L46-L47
>
> ?
>
>
>
> On Tue, Apr 17, 2018 at 7:37 AM, Keith Lohnes  wrote:
>
> > 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
> >  > focusedCommentId=16233681=com.atlassian.jira.
> > plugin.system.issuetabpanels%3Acomment-tabpanel#comment-16233681>
> > with DFS being explicit.
> >
> > The semantics I used were g.V().repeat(out()).order(DFS), putting the
> > order
> > clause outside of the repeat. It made it simpler for me to develop and
> > seemed nice to make that DFS vs BFS explicit. The barrier step that
> Daniel
> > described doesn’t currently work since there’s basically booleans in the
> > RepeatStep on whether or not to stash the starts to make the RepeatStep
> > depth first.
> >
> > I added a test for the DFS, though I’ve had some issues getting things to
> > run re: .net tests and some other tests timing out. I have some more
> tests
> > I'd like to write based off issues that I ran into testing this in the
> > console (k-ary trees, until/emit before the repeat vs after), but I
> really
> > wanted to get this out there for people to take a look at and see if it
> > could work out.
> > ​
> >
> > On Mon, Apr 16, 2018 at 7:29 PM Stephen Mallette 
> > wrote:
> >
> > >  Keith, I have to admit that I didn't really follow this general body
> of
> > > work closely, which include this pull request, the earlier one from
> > Michael
> > > Pollmeier, the JIRA and I think some discussion somewhere on one of the
> > > mailing lists. As best I have gathered from what I did follow, I feel
> > like
> > > the focus of this work so far was mostly related to "can someone get it
> > to
> > > actually work", but not a lot about other aspects like testing, api,
> > > release branch to apply it to, etc. Is that a fair depiction of how
> this
> > > work has developed so far? if so, let's use this thread to make sure
> > we're
> > > all on the same page as to how this change will get in on all those
> sorts
> > > of issues.
> > >
> > > btw, thanks to you and michael for sticking at this to come to
> something
> > > that seems to work. looking forward to the continued discussion on this
> > > thread.
> > >
> > >
> > > On Mon, Apr 16, 2018 at 6:54 PM, Michael Pollmeier <
> > > mich...@michaelpollmeier.com> wrote:
> > >
> > > > Unsurprisingly I'm also +1 for defaulting to DFS in OLTP. My feeling
> is
> > > > that most users currently expect it to be DFS since that's what the
> > docs
> > > > say.
> > > >
> > > > And yes, it's easy

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

2018-04-17 Thread ASF GitHub Bot (JIRA) 

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

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

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


> Repeat should depth first search
> 
>
> Key: TINKERPOP-1822
> URL: https://issues.apache.org/jira/browse/TINKERPOP-1822
> Project: TinkerPop
>  Issue Type: Improvement
>  Components: process
>Affects Versions: 3.3.0, 3.2.6
>Reporter: Robert Dale
>Priority: Major
>
> Perhaps optionally.
> See also:
> * https://groups.google.com/forum/#!topic/gremlin-users/gLSLxH_K-wE
> * https://github.com/apache/tinkerpop/pull/715



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

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

2018-04-17 Thread krlohnes 
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] Name of 3.4.x

2018-04-17 Thread Stephen Mallette 
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 Mon, Mar 5, 2018 at 4:25 PM, Stephen Mallette 
wrote:

> it just needs to be "music related" and "have something numeric" about it.
>
> On Mon, Mar 5, 2018 at 4:20 PM, David Brown  wrote:
>
>> Does it need to have a 3 or 4 in it?
>>
>> - 3 Little Gremlins (Marley)
>> - 4 Gremlins of the Apocalypse (Kind of like Clash)
>>
>> Idk I do like the Gambler...
>>
>>
>> On Mon, Mar 5, 2018 at 12:53 PM Stephen Mallette 
>> wrote:
>>
>> > So...we have a few good suggestions in hand (and I added one):
>> >
>> > 1. 4 Seasons of Gremlin - unclear if we're talking Boyz II Men or
>> Vivaldi
>> > here...
>> > 2. Four Rusted Gremlins - Marilyn Manson
>> > 3. Three Times a Gremlin - from the Commodores, though I think Gremlin
>> > would prefer the Kenny Rogers styling of it - I mean, look at this
>> > https://www.youtube.com/watch?v=Ok7becfXoJE :D
>> >
>> > Sorry Jason, gotta disqualify your suggestion as it doesn't have a
>> "number
>> > reference" in it.
>> >
>> > Anyone have any other ideas?
>> >
>> >
>> >
>> > On Thu, Mar 1, 2018 at 8:33 AM, Jason Plurad  wrote:
>> >
>> > > Boyz II Men - ha, I hadn't considered that angle. I assumed the 4
>> Seasons
>> > > was a Vivaldi reference.
>> > >
>> > > How about David Bowie? The Gremlin Who Sold the World
>> > > On Thu, Mar 1, 2018 at 8:06 AM Stephen Mallette > >
>> > > wrote:
>> > >
>> > > > I'm guessing at the reference for "4 Seasons of Gremlin" - are we
>> > talking
>> > > > Boyz || Men and "4 Seasons of Loneliness"?
>> > > >
>> > > > >  Yeah, I'd like to see what Gremlyn Manson would look like!
>> > > >
>> > > > would he look that much different than our "Nine Inch Nails
>> Gremlin"?
>> > > >
>> > > >
>> > > >
>> > > > On Tue, Feb 27, 2018 at 10:58 AM, Robert Dale 
>> > wrote:
>> > > >
>> > > > > Yeah, I'd like to see what Gremlyn Manson would look like!
>> > > > >
>> > > > > Robert Dale
>> > > > >
>> > > > > On Tue, Feb 27, 2018 at 10:40 AM, Daniel Kuppitz > >
>> > > > wrote:
>> > > > >
>> > > > > > Four Rusted Gremlins (reference
>> > > > > > ) :)
>> > > > > >
>> > > > > > On Tue, Feb 27, 2018 at 7:47 AM, Stephen Mallette <
>> > > > spmalle...@gmail.com>
>> > > > > > wrote:
>> > > > > >
>> > > > > > > We need a release name and associated Gremlin logo for the
>> 3.4.x
>> > > > series
>> > > > > > of
>> > > > > > > TinkerPop. Recall that names should be related to music and
>> > > include a
>> > > > > > > number. Thus far we've had:
>> > > > > > >
>> > > > > > > * Gremlin Symphony #40 in G Minor (3.3.x)
>> > > > > > > * Nine Inch Gremlins (3.2.x)
>> > > > > > > * A 187 On The Undercover Gremlinz (3.1.x)
>> > > > > > > * A Gremlin Rāga in 7/16 Time (3.0.x)
>> > > > > > >
>> > > > > > > Please submit a name with a logo idea - a name where we can't
>> > get a
>> > > > > logo
>> > > > > > > made doesn't really work too well. Thanks.
>> > > > > > >
>> > > > > >
>> > > > >
>> > > >
>> > >
>> >
>>
>>
>> --
>> David M. Brown
>> R.A. CulturePlex Lab, Western University
>>
>
>

Re: [DISCUSS] Depth First Repeat step

2018-04-17 Thread Stephen Mallette 
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.0/master (so it's currently targeted to the right branch actually) as
it sounds like we want DFS to be the default and that could be a breaking
change as the semantics of the traversal shift a bit. So that's one issue
to make sure we're all happy with.

A next issue would be the API from the user perspective - thanks for the
link to that JIRA btw - I see I was involved in that conversation a little
bit but then dropped off. You'd commented that you preferred a per loop
configuration for search approach which is what you stuck with for the
implementation. I guess I can see that there could be some value in having
that ability. That said, I'm not sure that I like the overload of order()
as the method for doing that:

g.V().has("name", "marko").
   repeat(__.outE().order().by("weight", decr).inV()).
 emit().
 order(SearchAlgo.DFS)

Still thinking about what else we might do there, but perhaps that can wait
a bit as I still need to study your changes in detail. Regarding:

>  The barrier step that Daniel described doesn’t currently work since
there’s basically booleans in the RepeatStep on whether or not to stash the
starts to make the RepeatStep depth first.

I assume you are referring to these booleans:

https://github.com/apache/tinkerpop/blob/fe8ee98f6967c7b0f0ee7f2cf2d10531b68fab8b/gremlin-core/src/main/java/org/apache/tinkerpop/gremlin/process/traversal/step/branch/RepeatStep.java#L46-L47

?



On Tue, Apr 17, 2018 at 7:37 AM, Keith Lohnes  wrote:

> 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
>  focusedCommentId=16233681=com.atlassian.jira.
> plugin.system.issuetabpanels%3Acomment-tabpanel#comment-16233681>
> with DFS being explicit.
>
> The semantics I used were g.V().repeat(out()).order(DFS), putting the
> order
> clause outside of the repeat. It made it simpler for me to develop and
> seemed nice to make that DFS vs BFS explicit. The barrier step that Daniel
> described doesn’t currently work since there’s basically booleans in the
> RepeatStep on whether or not to stash the starts to make the RepeatStep
> depth first.
>
> I added a test for the DFS, though I’ve had some issues getting things to
> run re: .net tests and some other tests timing out. I have some more tests
> I'd like to write based off issues that I ran into testing this in the
> console (k-ary trees, until/emit before the repeat vs after), but I really
> wanted to get this out there for people to take a look at and see if it
> could work out.
> ​
>
> On Mon, Apr 16, 2018 at 7:29 PM Stephen Mallette 
> wrote:
>
> >  Keith, I have to admit that I didn't really follow this general body of
> > work closely, which include this pull request, the earlier one from
> Michael
> > Pollmeier, the JIRA and I think some discussion somewhere on one of the
> > mailing lists. As best I have gathered from what I did follow, I feel
> like
> > the focus of this work so far was mostly related to "can someone get it
> to
> > actually work", but not a lot about other aspects like testing, api,
> > release branch to apply it to, etc. Is that a fair depiction of how this
> > work has developed so far? if so, let's use this thread to make sure
> we're
> > all on the same page as to how this change will get in on all those sorts
> > of issues.
> >
> > btw, thanks to you and michael for sticking at this to come to something
> > that seems to work. looking forward to the continued discussion on this
> > thread.
> >
> >
> > On Mon, Apr 16, 2018 at 6:54 PM, Michael Pollmeier <
> > mich...@michaelpollmeier.com> wrote:
> >
> > > Unsurprisingly I'm also +1 for defaulting to DFS in OLTP. My feeling is
> > > that most users currently expect it to be DFS since that's what the
> docs
> > > say.
> > >
> > > And yes, it's easy to verify the default in the test suite, once we
> > > agreed on what the default should be.
> > >
> > > Cheers
> > > Michael
> > >
> > > On 17/04/18 04:40, pieter gmail wrote:
> > > > Hi,
> > > >
> > > > I have not properly followed the previous thread. However I thought
> is
> > > > going to be a way to set the default behavior as apposed to needing
> to
> > > > use barrier()
> > > > Is this the case or not?
> > > >
> > > > For Sqlg at least it is possible to optimize BFS much more
> effectively
> > > > than DFS so it will be nice to have a way to set the strategy rather
> > > > than having to manually inject barriers.
> > > >
> > > > Is the test suite going to enforce the BFS vs DFS?
> > > >
> > > >

Re: [DISCUSS] Depth First Repeat step

2018-04-17 Thread Keith Lohnes 
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

with DFS being explicit.

The semantics I used were g.V().repeat(out()).order(DFS), putting the order
clause outside of the repeat. It made it simpler for me to develop and
seemed nice to make that DFS vs BFS explicit. The barrier step that Daniel
described doesn’t currently work since there’s basically booleans in the
RepeatStep on whether or not to stash the starts to make the RepeatStep
depth first.

I added a test for the DFS, though I’ve had some issues getting things to
run re: .net tests and some other tests timing out. I have some more tests
I'd like to write based off issues that I ran into testing this in the
console (k-ary trees, until/emit before the repeat vs after), but I really
wanted to get this out there for people to take a look at and see if it
could work out.
​

On Mon, Apr 16, 2018 at 7:29 PM Stephen Mallette 
wrote:

>  Keith, I have to admit that I didn't really follow this general body of
> work closely, which include this pull request, the earlier one from Michael
> Pollmeier, the JIRA and I think some discussion somewhere on one of the
> mailing lists. As best I have gathered from what I did follow, I feel like
> the focus of this work so far was mostly related to "can someone get it to
> actually work", but not a lot about other aspects like testing, api,
> release branch to apply it to, etc. Is that a fair depiction of how this
> work has developed so far? if so, let's use this thread to make sure we're
> all on the same page as to how this change will get in on all those sorts
> of issues.
>
> btw, thanks to you and michael for sticking at this to come to something
> that seems to work. looking forward to the continued discussion on this
> thread.
>
>
> On Mon, Apr 16, 2018 at 6:54 PM, Michael Pollmeier <
> mich...@michaelpollmeier.com> wrote:
>
> > Unsurprisingly I'm also +1 for defaulting to DFS in OLTP. My feeling is
> > that most users currently expect it to be DFS since that's what the docs
> > say.
> >
> > And yes, it's easy to verify the default in the test suite, once we
> > agreed on what the default should be.
> >
> > Cheers
> > Michael
> >
> > On 17/04/18 04:40, pieter gmail wrote:
> > > Hi,
> > >
> > > I have not properly followed the previous thread. However I thought is
> > > going to be a way to set the default behavior as apposed to needing to
> > > use barrier()
> > > Is this the case or not?
> > >
> > > For Sqlg at least it is possible to optimize BFS much more effectively
> > > than DFS so it will be nice to have a way to set the strategy rather
> > > than having to manually inject barriers.
> > >
> > > Is the test suite going to enforce the BFS vs DFS?
> > >
> > > Thanks
> > > Pieter
> > >
> > > On 16/04/2018 16:56, Daniel Kuppitz wrote:
> > >> +1 for DFS. If the query relies on BFS, you can always do
> > >> .repeat(barrier())...
> > >>
> > >> ^ This holds true as long as there's no significant difference in the
> > >> cpu+memory consumption and overall performance of the two approaches.
> > BFS
> > >> has its advantages when it comes to bulking; an arbitrary number of
> > >> traversers on the same element is processed at the same pace as a
> single
> > >> traverser. I don't think we can benefit from bulking in DFS.
> > >>
> > >> Cheers,
> > >> Daniel
> > >>
> > >>
> > >> On Mon, Apr 16, 2018 at 5:44 AM, Keith Lohnes 
> > wrote:
> > >>
> > >>> As part of #838 
> there’s
> > >>> some
> > >>> discussion around whether or not to make DFS the default for the
> repeat
> > >>> step. On the one hand, everything else in OLTP is depth first. On the
> > >>> other
> > >>> hand, there’s likely existing traversals that depend on the breadth
> > >>> first
> > >>> nature of repeat. My general preference is to make DFS optional at
> > >>> first,
> > >>> and at some later date, change the default and have that be a
> separate
> > >>> change from implementing DFS for repeat
> > >>> ​
> > >>>
> > >
> > >
> >
> >
>

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

2018-04-17 Thread Stephen Mallette 
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 to default to GraphSON 3.0 in Gremlin Server, and since 3.0
didn't have a typeless version as GraphSON 2.0 did, that application/json
became a typed JSON which is truly different from 1.0. So, there was a
progression there, and you can certainly revert back to GraphSON 1.0 for
3.3.0 but the rise of GLVs usually doesn't make it sensible to do that.

All of this was more or less documented in the upgrade docs here:

http://tinkerpop.apache.org/docs/3.3.2/upgrade/#_changes_to_io

Hope that history helps you get oriented a bit.

On Tue, Apr 17, 2018 at 12:08 AM, Dylan Millikin 
wrote:

> It makes sense that we shouldn't carry it forward. That wasn't what I was
> getting to though. My initial plea was that since moving from GraphSON 1.0
> to 3.0 can introduce some breaking changes I was asking if this should be
> documented somewhere (update notes for example).
> I've since decided against it, because this really only affects non-java
> users (who typically would not be aware of the underlying IO but would be
> affected by the changes) and depending on the driver's implementation it
> may or may not be breaking. So it should be up to the "client" to report
> the breaking change, not TP.
>
> Right now since the php driver still needs to support the 3.2.x line, I've
> opted to deserialize into the old ugly format. I'll introduce a breaking
> change later.
>
>
>
>
>
>
> On Mon, Apr 16, 2018 at 7:36 PM, Stephen Mallette 
> wrote:
>
> > the "1" is no longer a thing (i.e. the toString() of a complex object)
> > because GraphSON 3.0 allows complex keys. That "1" was a hack in prior
> > versions of GraphSON to get around that problem. We shouldn't be trying
> to
> > carry that forward. Does that make sense?
> >
> > On Mon, Apr 16, 2018 at 4:17 PM, Dylan Millikin <
> dylan.milli...@gmail.com>
> > wrote:
> >
> > > Actually, let me change that up a bit. I would expect the Map to be
> part
> > of
> > > Tree, not encapsulate it. So something like :
> > >
> > > "data":{
> > >"@type":"g:List",
> > >"@value":[{
> > >   "@type":"g:Tree",
> > >   "@value":[{
> > > "@type":"g:Map",
> > > "@value":{
> > >"1",
> > >{
> > >   "key":{
> > >  "@type":"g:Vertex",
> > >  "@value":{
> > > "id":{"@type":"g:Int64","@value":1},
> > > "label":"vertex",
> > > "properties":{"name": ...
> > >
> > > It could be debated that this is something the client side serializer
> > > could/would need to add in when treating Tree. But still a little
> > lopsided.
> > >
> > > BTW if you're wondering, the "1" key from GRAPHSON 1.0 is a string
> > > representation of the *element id*. So I really wouldn't be surprised
> if
> > > people were using that information currently.
> > >
> > >
> > > On Mon, Apr 16, 2018 at 4:04 PM, Dylan Millikin <
> > dylan.milli...@gmail.com>
> > > wrote:
> > >
> > > > I'm going to leverage this email a bit more for the following point.
> > > >
> > > > I noticed that the actual format of Tree has changed with GRAPHSON
> 3.0.
> > > > We're now handling Lists whereas it used to be Maps. This seems to
> be a
> > > > breaking change when using GRAPHSON 3.0.
> > > >
> > > > Given: g.V(1).out().properties("name").tree()
> > > >
> > > > In 1.0 we get :
> > > >
> > > > "data":[{
> > > >"1":{
> > > >   "key":{
> > > >  "id":1,
> > > >  "label":"vertex",
> > > >  "type":"vertex",
> > > >  "properties":{"name": ...
> > > >
> > > > In 3.0 we get :
> > > >
> > > > "data":{
> > > >"@type":"g:List",
> > > >"@value":[{
> > > >   "@type":"g:Tree",
> > > >   "@value":[{
> > > >  "key":{
> > > >  "@type":"g:Vertex",
> > > >  "@value":{
> > > >  "id":{"@type":"g:Int64","@value":1},
> > > >  "label":"vertex",
> > > >  "properties":{"name": ...
> > > >
> > > > When instead we should be getting :
> > > >
> > > > "data":{
> > > >"@type":"g:Map",
> > > >"@value":[{
> > > >   "1",
> > > >   {
> > > >  "@type":"g:Tree",
> > > >  "@value":[{
> > > > "key":{
> > > >"@type":"g:Vertex",
> > > >"@value":{
> > > >"id":{"@type":"g:Int64","@value":1},
> > > >"label":"vertex",
> > > >"properties":{"name": ...
> > > >
> > > > I like the new way better to be honest. And it's probably more
> > consistent
> > > > with gryo, but this is a breaking change and inconsistent across
> > > >