date:20170926

[jira] [Commented] (TINKERPOP-1792) Random TraversalSource Selection in GremlinScriptEngine

2017-09-26 Thread ASF GitHub Bot (JIRA)


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

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

GitHub user spmallette opened a pull request:

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

TINKERPOP-1792 Fixed GremlinScriptEngine bug in lambda processing

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

GremlinScriptEngine instances should now properly select the appropriate 
TraversalSource from bindings rather than select a random one. The 
TraversalSource is locally aliased to a "hidden" variable at the time of 
evaluation to avoid naming clashes with local variables defined in the bytecode 
itself. Added a number of validations to be sure that users get appropriate 
errors if they try to use the eval() method the wrong way. Included new tests 
to ensure that GremlinScriptEngine have the appropriate behavior.

All tests pass with `docker/build.sh -t -n -i`

VOTE +1

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

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

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

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


commit 30185646379b051b81484dd75ad34490fa7461b8
Author: Stephen Mallette 
Date:   2017-09-26T15:31:31Z

TINKERPOP-1792 Fixed GremlinScriptEngine bug in lambda processing

GremlinScriptEngine instances should now properly select the appropriate 
TraversalSource from bindings rather than select a random one. The 
TraversalSource is locally aliased to a "hidden" variable at the time of 
evaluation to avoid naming clashes with local variables defined in the bytecode 
itself. Added a number of validations to be sure that users get appropriate 
errors if they try to use the eval() method the wrong way. Included new tests 
to ensure that GremlinScriptEngine have the appropriate behavior.




> Random TraversalSource Selection in GremlinScriptEngine
> ---
>
> Key: TINKERPOP-1792
> URL: https://issues.apache.org/jira/browse/TINKERPOP-1792
> Project: TinkerPop
>  Issue Type: Bug
>Affects Versions: 3.2.6
>Reporter: stephen mallette
>Priority: Critical
>  Labels: deprecation
>
> {{GremlinScriptEngine}} implementations make a random {{TraversalSource}} 
> selection when processing lambdas. Obviously it should be bound more clearly 
> to the specific {{TraversalSource}} the caller requests. Another issue that 
> isn't completely clear is that bindings passed from the client share the same 
> namespace as {{TraversalSource}} bindings which means that if the 
> {{TraversalSource}} is "g" then you couldn't write a traversal like: 
> {{withSideEffect(“g”, “hello”)}}. That could be smarter as well.



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

[GitHub] tinkerpop pull request #723: TINKERPOP-1792 Fixed GremlinScriptEngine bug in...

2017-09-26 Thread spmallette

GitHub user spmallette opened a pull request:

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

TINKERPOP-1792 Fixed GremlinScriptEngine bug in lambda processing

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

GremlinScriptEngine instances should now properly select the appropriate 
TraversalSource from bindings rather than select a random one. The 
TraversalSource is locally aliased to a "hidden" variable at the time of 
evaluation to avoid naming clashes with local variables defined in the bytecode 
itself. Added a number of validations to be sure that users get appropriate 
errors if they try to use the eval() method the wrong way. Included new tests 
to ensure that GremlinScriptEngine have the appropriate behavior.

All tests pass with `docker/build.sh -t -n -i`

VOTE +1

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

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

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

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


commit 30185646379b051b81484dd75ad34490fa7461b8
Author: Stephen Mallette 
Date:   2017-09-26T15:31:31Z

TINKERPOP-1792 Fixed GremlinScriptEngine bug in lambda processing

GremlinScriptEngine instances should now properly select the appropriate 
TraversalSource from bindings rather than select a random one. The 
TraversalSource is locally aliased to a "hidden" variable at the time of 
evaluation to avoid naming clashes with local variables defined in the bytecode 
itself. Added a number of validations to be sure that users get appropriate 
errors if they try to use the eval() method the wrong way. Included new tests 
to ensure that GremlinScriptEngine have the appropriate behavior.




---

[jira] [Commented] (TINKERPOP-1789) Reference elements should be represented by id and label

2017-09-26 Thread ASF GitHub Bot (JIRA)


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

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

Github user dkuppitz commented on the issue:

https://github.com/apache/tinkerpop/pull/720
  
`docker/build.sh -t -i -n` succeeded.

VOTE: another +0.5


> Reference elements should be represented by id and label
> 
>
> Key: TINKERPOP-1789
> URL: https://issues.apache.org/jira/browse/TINKERPOP-1789
> Project: TinkerPop
>  Issue Type: Bug
>  Components: io
>Affects Versions: 3.2.6
>Reporter: stephen mallette
>Assignee: Marko A. Rodriguez
>Priority: Critical
>  Labels: breaking
> Fix For: 3.2.7, 3.3.1
>
>
> Reference elements don't have {{label()}} - wow. This is a breaking change 
> because adding label to reference objects will mean that the gryo 
> serialization format will change for reference objects.



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

[jira] [Created] (TINKERPOP-1793) addE() should allow dynamic edge labels

2017-09-26 Thread Daniel Kuppitz (JIRA)

Daniel Kuppitz created TINKERPOP-1793:
-

 Summary: addE() should allow dynamic edge labels
 Key: TINKERPOP-1793
 URL: https://issues.apache.org/jira/browse/TINKERPOP-1793
 Project: TinkerPop
  Issue Type: Improvement
  Components: process
Reporter: Daniel Kuppitz
Assignee: Marko A. Rodriguez


We can create vertices with dynamic labels, e.g:

{noformat}
...addV().property(label, select("x"))...
{noformat}

This approach doesn't work for edges as we don't have a parameterless {{addE}} 
overload. However, I think we can allow {{addE()}} and use 
{{Edge.DEFAULT_LABEL}}, just like we do for vertices; then the aforementioned 
approach would work.

As an aside: I would prefer {{addV(traversal)}} and {{addE(traversal)}} over 
{{addX().property(label, ...)}}.



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

[jira] [Commented] (TINKERPOP-1786) Recipe and missing manifest items for Spark on Yarn

2017-09-26 Thread ASF GitHub Bot (JIRA)


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

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

Github user vtslab commented on the issue:

https://github.com/apache/tinkerpop/pull/721
  
Could I assume a pseudo-hadoop cluster present during the integration test 
phase? I thought only the asciidoc processing had that. Anyway, breaking the 
spark-yarn option will be noticed through the docs processing, but hopefully 
not until hadoop-3 or spark-3.
I´ll correct the TinkerPop naming, off course, and will also add a pointer 
to the gremlin-plugin-dependencies section of the spark-gremlin manifest file.


> Recipe and missing manifest items for Spark on Yarn
> ---
>
> Key: TINKERPOP-1786
> URL: https://issues.apache.org/jira/browse/TINKERPOP-1786
> Project: TinkerPop
>  Issue Type: Improvement
>  Components: hadoop
>Affects Versions: 3.3.0, 3.1.8, 3.2.6
> Environment: gremlin-console
>Reporter: Marc de Lignie
>Priority: Minor
> Fix For: 3.2.7, 3.3.1
>
>
> Thorough documentation for running OLAP queries on Spark on Yarn has been 
> missing, keeping some users from getting the benefits of this nice feature of 
> the Tinkerpop stack and resulting in a significant number of questions on the 
> gremlin users list.



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

[GitHub] tinkerpop issue #721: TINKERPOP-1786 Recipe and missing manifest items for S...

2017-09-26 Thread vtslab

Github user vtslab commented on the issue:

https://github.com/apache/tinkerpop/pull/721
  
Could I assume a pseudo-hadoop cluster present during the integration test 
phase? I thought only the asciidoc processing had that. Anyway, breaking the 
spark-yarn option will be noticed through the docs processing, but hopefully 
not until hadoop-3 or spark-3.
IÂ´ll correct the TinkerPop naming, off course, and will also add a pointer 
to the gremlin-plugin-dependencies section of the spark-gremlin manifest file.


---

Re: [DISCUSS] Asciidoc Header Reformat

2017-09-26 Thread Robert Dale

Looks good!

Robert Dale

On Tue, Sep 26, 2017 at 1:38 PM, Daniel Kuppitz  wrote:

> Yea, that was the right regex to look for these errors: grep '^== $'
> $(find . -name "*.asciidoc")
> Got them all now, will push the fix in a few.
>
> Cheers,
> Daniel
>
>
> On Tue, Sep 26, 2017 at 10:30 AM, Robert Dale  wrote:
>
> > docs/src/reference/gremlin-applications.asciidoc:
> > @@ -294,8 +288,7 @@ v[2]
> >  v[3]
> >  v[4]
> >  v[5]
> > -v[6]
> > -
> > +== v[6]
> >
> >  It is also possible to pass arguments to scripts.  Any parameters
> > following the file name specification are treated
> >  as arguments to the script. They are collected into a list and passed in
> > as a variable called "args".  The following
> > @@ -316,8 +309,7 @@ When executed from the command line a parameter can
> be
> > supplied:
> >  $ bin/gremlin.sh -e gremlin.groovy marko
> >  v[1]
> >  $ bin/gremlin.sh -e gremlin.groovy vadas
> > -v[2]
> > -
> > +== v[2]
> >
> >
> >
> > Robert Dale
> >
> > On Tue, Sep 26, 2017 at 1:22 PM, Robert Dale  wrote:
> >
> > > Looks like master CHANGELOG picked up a conflict...
> > >
> > > <<< HEAD
> > > == TinkerPop 3.3.0 (Gremlin Symphony #40 in G Minor)
> > > .
> > > .
> > > .
> > >
> > > == TinkerPop 3.2.0 (Nine Inch Gremlins)
> > > ===
> > > == TinkerPop 3.2.0 (Nine Inch Gremlins)
> > > >>> asciidoc-header
> > >
> > >
> > > Robert Dale
> > >
> > > On Tue, Sep 26, 2017 at 1:19 PM, Daniel Kuppitz 
> wrote:
> > >
> > >> Ah, good find! That's the same issue I've had in the reference docs
> and
> > >> recipes. Fixed.
> > >>
> > >> Cheers,
> > >> Daniel
> > >>
> > >>
> > >> On Tue, Sep 26, 2017 at 10:08 AM, Robert Dale 
> > wrote:
> > >>
> > >> > git grep "== =="
> > >> >
> > >> > Robert Dale
> > >> >
> > >> > On Tue, Sep 26, 2017 at 1:07 PM, Robert Dale 
> > wrote:
> > >> >
> > >> > > I see things like '== ==>6' in docs/src/upgrade/release-3.2.
> > >> > > x-incubating.html
> > >> > >
> > >> > > Robert Dale
> > >> > >
> > >> > > On Tue, Sep 26, 2017 at 12:57 PM, Robert Dale 
> > >> wrote:
> > >> > >
> > >> > >> ^d
> > >> > >>
> > >> > >> Robert Dale
> > >> > >>
> > >> > >> On Tue, Sep 26, 2017 at 12:56 PM, Daniel Kuppitz  >
> > >> > wrote:
> > >> > >>
> > >> > >>> This is one. I pushed the changes to tp32/ and master/. I only
> > found
> > >> > (and
> > >> > >>> fixed) 2 minor issues, where my script produced a little
> > formatting
> > >> > mess.
> > >> > >>>
> > >> > >>> Cheers,
> > >> > >>> Daniel
> > >> > >>>
> > >> > >>>
> > >> > >>> On Tue, Sep 19, 2017 at 9:23 AM, Stephen Mallette <
> > >> > spmalle...@gmail.com>
> > >> > >>> wrote:
> > >> > >>>
> > >> > >>> > For whatever reason we started writing our headers in our docs
> > >> with:
> > >> > >>> >
> > >> > >>> > Header
> > >> > >>> > ==
> > >> > >>> >
> > >> > >>> > Subheader
> > >> > >>> > -
> > >> > >>> >
> > >> > >>> > SubSubHeader
> > >> > >>> > 
> > >> > >>> >
> > >> > >>> > as opposed to the alternative:
> > >> > >>> >
> > >> > >>> > = This Is A Header
> > >> > >>> >
> > >> > >>> > == Subheader
> > >> > >>> >
> > >> > >>> > === SubSubHeader
> > >> > >>> >
> > >> > >>> > The downside with the first approach is that it forces us to
> do
> > >> two
> > >> > >>> things:
> > >> > >>> >
> > >> > >>> > 1. Remember the syntax for each header layer (which we all
> > >> probably
> > >> > >>> know
> > >> > >>> > pretty well at this point, but still...)
> > >> > >>> > 2. Ensure that the width of the header formatting line is
> equal
> > to
> > >> > the
> > >> > >>> > length of the text above it.
> > >> > >>> >
> > >> > >>> > That second point is a killer sometimes. While I've trained
> > >> myself to
> > >> > >>> be
> > >> > >>> > good at noticing that problem I know it's bitten us in
> releases
> > >> over
> > >> > >>> and
> > >> > >>> > over and over again.
> > >> > >>> >
> > >> > >>> > Anyway, I think going to the alternative formatting would be
> > >> better
> > >> > and
> > >> > >>> > propose to do a full reformatting. Please let me know if there
> > are
> > >> > any
> > >> > >>> > concerns about doing that - if I don't hear back in the next
> few
> > >> days
> > >> > >>> I'll
> > >> > >>> > proceed with the changes.
> > >> > >>> >
> > >> > >>> > Thanks,
> > >> > >>> >
> > >> > >>> > Stephen
> > >> > >>> >
> > >> > >>>
> > >> > >>
> > >> > >>
> > >> > >
> > >> >
> > >>
> > >
> > >
> >
>

Re: [DISCUSS] Asciidoc Header Reformat

2017-09-26 Thread Daniel Kuppitz

Yea, that was the right regex to look for these errors: grep '^== $'
$(find . -name "*.asciidoc")
Got them all now, will push the fix in a few.

Cheers,
Daniel


On Tue, Sep 26, 2017 at 10:30 AM, Robert Dale  wrote:

> docs/src/reference/gremlin-applications.asciidoc:
> @@ -294,8 +288,7 @@ v[2]
>  v[3]
>  v[4]
>  v[5]
> -v[6]
> -
> +== v[6]
>
>  It is also possible to pass arguments to scripts.  Any parameters
> following the file name specification are treated
>  as arguments to the script. They are collected into a list and passed in
> as a variable called "args".  The following
> @@ -316,8 +309,7 @@ When executed from the command line a parameter can be
> supplied:
>  $ bin/gremlin.sh -e gremlin.groovy marko
>  v[1]
>  $ bin/gremlin.sh -e gremlin.groovy vadas
> -v[2]
> -
> +== v[2]
>
>
>
> Robert Dale
>
> On Tue, Sep 26, 2017 at 1:22 PM, Robert Dale  wrote:
>
> > Looks like master CHANGELOG picked up a conflict...
> >
> > <<< HEAD
> > == TinkerPop 3.3.0 (Gremlin Symphony #40 in G Minor)
> > .
> > .
> > .
> >
> > == TinkerPop 3.2.0 (Nine Inch Gremlins)
> > ===
> > == TinkerPop 3.2.0 (Nine Inch Gremlins)
> > >>> asciidoc-header
> >
> >
> > Robert Dale
> >
> > On Tue, Sep 26, 2017 at 1:19 PM, Daniel Kuppitz  wrote:
> >
> >> Ah, good find! That's the same issue I've had in the reference docs and
> >> recipes. Fixed.
> >>
> >> Cheers,
> >> Daniel
> >>
> >>
> >> On Tue, Sep 26, 2017 at 10:08 AM, Robert Dale 
> wrote:
> >>
> >> > git grep "== =="
> >> >
> >> > Robert Dale
> >> >
> >> > On Tue, Sep 26, 2017 at 1:07 PM, Robert Dale 
> wrote:
> >> >
> >> > > I see things like '== ==>6' in docs/src/upgrade/release-3.2.
> >> > > x-incubating.html
> >> > >
> >> > > Robert Dale
> >> > >
> >> > > On Tue, Sep 26, 2017 at 12:57 PM, Robert Dale 
> >> wrote:
> >> > >
> >> > >> ^d
> >> > >>
> >> > >> Robert Dale
> >> > >>
> >> > >> On Tue, Sep 26, 2017 at 12:56 PM, Daniel Kuppitz 
> >> > wrote:
> >> > >>
> >> > >>> This is one. I pushed the changes to tp32/ and master/. I only
> found
> >> > (and
> >> > >>> fixed) 2 minor issues, where my script produced a little
> formatting
> >> > mess.
> >> > >>>
> >> > >>> Cheers,
> >> > >>> Daniel
> >> > >>>
> >> > >>>
> >> > >>> On Tue, Sep 19, 2017 at 9:23 AM, Stephen Mallette <
> >> > spmalle...@gmail.com>
> >> > >>> wrote:
> >> > >>>
> >> > >>> > For whatever reason we started writing our headers in our docs
> >> with:
> >> > >>> >
> >> > >>> > Header
> >> > >>> > ==
> >> > >>> >
> >> > >>> > Subheader
> >> > >>> > -
> >> > >>> >
> >> > >>> > SubSubHeader
> >> > >>> > 
> >> > >>> >
> >> > >>> > as opposed to the alternative:
> >> > >>> >
> >> > >>> > = This Is A Header
> >> > >>> >
> >> > >>> > == Subheader
> >> > >>> >
> >> > >>> > === SubSubHeader
> >> > >>> >
> >> > >>> > The downside with the first approach is that it forces us to do
> >> two
> >> > >>> things:
> >> > >>> >
> >> > >>> > 1. Remember the syntax for each header layer (which we all
> >> probably
> >> > >>> know
> >> > >>> > pretty well at this point, but still...)
> >> > >>> > 2. Ensure that the width of the header formatting line is equal
> to
> >> > the
> >> > >>> > length of the text above it.
> >> > >>> >
> >> > >>> > That second point is a killer sometimes. While I've trained
> >> myself to
> >> > >>> be
> >> > >>> > good at noticing that problem I know it's bitten us in releases
> >> over
> >> > >>> and
> >> > >>> > over and over again.
> >> > >>> >
> >> > >>> > Anyway, I think going to the alternative formatting would be
> >> better
> >> > and
> >> > >>> > propose to do a full reformatting. Please let me know if there
> are
> >> > any
> >> > >>> > concerns about doing that - if I don't hear back in the next few
> >> days
> >> > >>> I'll
> >> > >>> > proceed with the changes.
> >> > >>> >
> >> > >>> > Thanks,
> >> > >>> >
> >> > >>> > Stephen
> >> > >>> >
> >> > >>>
> >> > >>
> >> > >>
> >> > >
> >> >
> >>
> >
> >
>

Re: [DISCUSS] Asciidoc Header Reformat

2017-09-26 Thread Robert Dale

That was master.  tp32 is:
@@ -278,8 +272,7 @@ v[2]
 v[3]
 v[4]
 v[5]
-v[6]
-
+== v[6]

 It is also possible to pass arguments to scripts.  Any parameters
following the file name specification are treated
 as arguments to the script. They are collected into a list and passed in
as a variable called "args".  The following
@@ -300,8 +293,7 @@ When executed from the command line a parameter can be
supplied:
 $ bin/gremlin.sh -e gremlin.groovy marko
 v[1]
 $ bin/gremlin.sh -e gremlin.groovy vadas
-v[2]
-
+== v[2]


Robert Dale

On Tue, Sep 26, 2017 at 1:30 PM, Robert Dale  wrote:

> docs/src/reference/gremlin-applications.asciidoc:
> @@ -294,8 +288,7 @@ v[2]
>  v[3]
>  v[4]
>  v[5]
> -v[6]
> -
> +== v[6]
>
>  It is also possible to pass arguments to scripts.  Any parameters
> following the file name specification are treated
>  as arguments to the script. They are collected into a list and passed in
> as a variable called "args".  The following
> @@ -316,8 +309,7 @@ When executed from the command line a parameter can be
> supplied:
>  $ bin/gremlin.sh -e gremlin.groovy marko
>  v[1]
>  $ bin/gremlin.sh -e gremlin.groovy vadas
> -v[2]
> -
> +== v[2]
>
>
>
> Robert Dale
>
> On Tue, Sep 26, 2017 at 1:22 PM, Robert Dale  wrote:
>
>> Looks like master CHANGELOG picked up a conflict...
>>
>> <<< HEAD
>> == TinkerPop 3.3.0 (Gremlin Symphony #40 in G Minor)
>> .
>> .
>> .
>>
>> == TinkerPop 3.2.0 (Nine Inch Gremlins)
>> ===
>> == TinkerPop 3.2.0 (Nine Inch Gremlins)
>> >>> asciidoc-header
>>
>>
>> Robert Dale
>>
>> On Tue, Sep 26, 2017 at 1:19 PM, Daniel Kuppitz  wrote:
>>
>>> Ah, good find! That's the same issue I've had in the reference docs and
>>> recipes. Fixed.
>>>
>>> Cheers,
>>> Daniel
>>>
>>>
>>> On Tue, Sep 26, 2017 at 10:08 AM, Robert Dale  wrote:
>>>
>>> > git grep "== =="
>>> >
>>> > Robert Dale
>>> >
>>> > On Tue, Sep 26, 2017 at 1:07 PM, Robert Dale 
>>> wrote:
>>> >
>>> > > I see things like '== ==>6' in docs/src/upgrade/release-3.2.
>>> > > x-incubating.html
>>> > >
>>> > > Robert Dale
>>> > >
>>> > > On Tue, Sep 26, 2017 at 12:57 PM, Robert Dale 
>>> wrote:
>>> > >
>>> > >> ^d
>>> > >>
>>> > >> Robert Dale
>>> > >>
>>> > >> On Tue, Sep 26, 2017 at 12:56 PM, Daniel Kuppitz 
>>> > wrote:
>>> > >>
>>> > >>> This is one. I pushed the changes to tp32/ and master/. I only
>>> found
>>> > (and
>>> > >>> fixed) 2 minor issues, where my script produced a little formatting
>>> > mess.
>>> > >>>
>>> > >>> Cheers,
>>> > >>> Daniel
>>> > >>>
>>> > >>>
>>> > >>> On Tue, Sep 19, 2017 at 9:23 AM, Stephen Mallette <
>>> > spmalle...@gmail.com>
>>> > >>> wrote:
>>> > >>>
>>> > >>> > For whatever reason we started writing our headers in our docs
>>> with:
>>> > >>> >
>>> > >>> > Header
>>> > >>> > ==
>>> > >>> >
>>> > >>> > Subheader
>>> > >>> > -
>>> > >>> >
>>> > >>> > SubSubHeader
>>> > >>> > 
>>> > >>> >
>>> > >>> > as opposed to the alternative:
>>> > >>> >
>>> > >>> > = This Is A Header
>>> > >>> >
>>> > >>> > == Subheader
>>> > >>> >
>>> > >>> > === SubSubHeader
>>> > >>> >
>>> > >>> > The downside with the first approach is that it forces us to do
>>> two
>>> > >>> things:
>>> > >>> >
>>> > >>> > 1. Remember the syntax for each header layer (which we all
>>> probably
>>> > >>> know
>>> > >>> > pretty well at this point, but still...)
>>> > >>> > 2. Ensure that the width of the header formatting line is equal
>>> to
>>> > the
>>> > >>> > length of the text above it.
>>> > >>> >
>>> > >>> > That second point is a killer sometimes. While I've trained
>>> myself to
>>> > >>> be
>>> > >>> > good at noticing that problem I know it's bitten us in releases
>>> over
>>> > >>> and
>>> > >>> > over and over again.
>>> > >>> >
>>> > >>> > Anyway, I think going to the alternative formatting would be
>>> better
>>> > and
>>> > >>> > propose to do a full reformatting. Please let me know if there
>>> are
>>> > any
>>> > >>> > concerns about doing that - if I don't hear back in the next few
>>> days
>>> > >>> I'll
>>> > >>> > proceed with the changes.
>>> > >>> >
>>> > >>> > Thanks,
>>> > >>> >
>>> > >>> > Stephen
>>> > >>> >
>>> > >>>
>>> > >>
>>> > >>
>>> > >
>>> >
>>>
>>
>>
>

[jira] [Commented] (TINKERPOP-1789) Reference elements should be represented by id and label

2017-09-26 Thread ASF GitHub Bot (JIRA)


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

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

Github user dkuppitz commented on the issue:

https://github.com/apache/tinkerpop/pull/720
  
VOTE: +0.5

Will add the other 0.5 once `docker/build.sh -t -i -n` reports success 
(currently running on my machine; just in case somebody else was planning to do 
it).


> Reference elements should be represented by id and label
> 
>
> Key: TINKERPOP-1789
> URL: https://issues.apache.org/jira/browse/TINKERPOP-1789
> Project: TinkerPop
>  Issue Type: Bug
>  Components: io
>Affects Versions: 3.2.6
>Reporter: stephen mallette
>Assignee: Marko A. Rodriguez
>Priority: Critical
>  Labels: breaking
> Fix For: 3.2.7, 3.3.1
>
>
> Reference elements don't have {{label()}} - wow. This is a breaking change 
> because adding label to reference objects will mean that the gryo 
> serialization format will change for reference objects.



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

[GitHub] tinkerpop issue #720: TINKERPOP-1789: Reference elements should be represent...

2017-09-26 Thread dkuppitz

Github user dkuppitz commented on the issue:

https://github.com/apache/tinkerpop/pull/720
  
VOTE: +0.5

Will add the other 0.5 once `docker/build.sh -t -i -n` reports success 
(currently running on my machine; just in case somebody else was planning to do 
it).


---

Re: [DISCUSS] Asciidoc Header Reformat

2017-09-26 Thread Robert Dale

docs/src/reference/gremlin-applications.asciidoc:
@@ -294,8 +288,7 @@ v[2]
 v[3]
 v[4]
 v[5]
-v[6]
-
+== v[6]

 It is also possible to pass arguments to scripts.  Any parameters
following the file name specification are treated
 as arguments to the script. They are collected into a list and passed in
as a variable called "args".  The following
@@ -316,8 +309,7 @@ When executed from the command line a parameter can be
supplied:
 $ bin/gremlin.sh -e gremlin.groovy marko
 v[1]
 $ bin/gremlin.sh -e gremlin.groovy vadas
-v[2]
-
+== v[2]



Robert Dale

On Tue, Sep 26, 2017 at 1:22 PM, Robert Dale  wrote:

> Looks like master CHANGELOG picked up a conflict...
>
> <<< HEAD
> == TinkerPop 3.3.0 (Gremlin Symphony #40 in G Minor)
> .
> .
> .
>
> == TinkerPop 3.2.0 (Nine Inch Gremlins)
> ===
> == TinkerPop 3.2.0 (Nine Inch Gremlins)
> >>> asciidoc-header
>
>
> Robert Dale
>
> On Tue, Sep 26, 2017 at 1:19 PM, Daniel Kuppitz  wrote:
>
>> Ah, good find! That's the same issue I've had in the reference docs and
>> recipes. Fixed.
>>
>> Cheers,
>> Daniel
>>
>>
>> On Tue, Sep 26, 2017 at 10:08 AM, Robert Dale  wrote:
>>
>> > git grep "== =="
>> >
>> > Robert Dale
>> >
>> > On Tue, Sep 26, 2017 at 1:07 PM, Robert Dale  wrote:
>> >
>> > > I see things like '== ==>6' in docs/src/upgrade/release-3.2.
>> > > x-incubating.html
>> > >
>> > > Robert Dale
>> > >
>> > > On Tue, Sep 26, 2017 at 12:57 PM, Robert Dale 
>> wrote:
>> > >
>> > >> ^d
>> > >>
>> > >> Robert Dale
>> > >>
>> > >> On Tue, Sep 26, 2017 at 12:56 PM, Daniel Kuppitz 
>> > wrote:
>> > >>
>> > >>> This is one. I pushed the changes to tp32/ and master/. I only found
>> > (and
>> > >>> fixed) 2 minor issues, where my script produced a little formatting
>> > mess.
>> > >>>
>> > >>> Cheers,
>> > >>> Daniel
>> > >>>
>> > >>>
>> > >>> On Tue, Sep 19, 2017 at 9:23 AM, Stephen Mallette <
>> > spmalle...@gmail.com>
>> > >>> wrote:
>> > >>>
>> > >>> > For whatever reason we started writing our headers in our docs
>> with:
>> > >>> >
>> > >>> > Header
>> > >>> > ==
>> > >>> >
>> > >>> > Subheader
>> > >>> > -
>> > >>> >
>> > >>> > SubSubHeader
>> > >>> > 
>> > >>> >
>> > >>> > as opposed to the alternative:
>> > >>> >
>> > >>> > = This Is A Header
>> > >>> >
>> > >>> > == Subheader
>> > >>> >
>> > >>> > === SubSubHeader
>> > >>> >
>> > >>> > The downside with the first approach is that it forces us to do
>> two
>> > >>> things:
>> > >>> >
>> > >>> > 1. Remember the syntax for each header layer (which we all
>> probably
>> > >>> know
>> > >>> > pretty well at this point, but still...)
>> > >>> > 2. Ensure that the width of the header formatting line is equal to
>> > the
>> > >>> > length of the text above it.
>> > >>> >
>> > >>> > That second point is a killer sometimes. While I've trained
>> myself to
>> > >>> be
>> > >>> > good at noticing that problem I know it's bitten us in releases
>> over
>> > >>> and
>> > >>> > over and over again.
>> > >>> >
>> > >>> > Anyway, I think going to the alternative formatting would be
>> better
>> > and
>> > >>> > propose to do a full reformatting. Please let me know if there are
>> > any
>> > >>> > concerns about doing that - if I don't hear back in the next few
>> days
>> > >>> I'll
>> > >>> > proceed with the changes.
>> > >>> >
>> > >>> > Thanks,
>> > >>> >
>> > >>> > Stephen
>> > >>> >
>> > >>>
>> > >>
>> > >>
>> > >
>> >
>>
>
>

[jira] [Commented] (TINKERPOP-1782) RangeByIsCountStrategy doesn't handle floating point numbers properly

2017-09-26 Thread ASF GitHub Bot (JIRA)


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

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

Github user asfgit closed the pull request at:

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


> RangeByIsCountStrategy doesn't handle floating point numbers properly
> -
>
> Key: TINKERPOP-1782
> URL: https://issues.apache.org/jira/browse/TINKERPOP-1782
> Project: TinkerPop
>  Issue Type: Bug
>  Components: process
>Affects Versions: 3.2.6
>Reporter: Daniel Kuppitz
>Assignee: Daniel Kuppitz
> Fix For: 3.2.7, 3.3.1
>
>
> See: https://groups.google.com/d/msg/gremlin-users/90IY6QMp4YQ/w60l_pfvCgAJ



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

[GitHub] tinkerpop pull request #714: TINKERPOP-1782 RangeByIsCountStrategy doesn't h...

2017-09-26 Thread asfgit

Github user asfgit closed the pull request at:

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


---

[jira] [Closed] (TINKERPOP-1782) RangeByIsCountStrategy doesn't handle floating point numbers properly

2017-09-26 Thread Daniel Kuppitz (JIRA)


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

Daniel Kuppitz closed TINKERPOP-1782.
-
   Resolution: Fixed
Fix Version/s: 3.3.1
   3.2.7

> RangeByIsCountStrategy doesn't handle floating point numbers properly
> -
>
> Key: TINKERPOP-1782
> URL: https://issues.apache.org/jira/browse/TINKERPOP-1782
> Project: TinkerPop
>  Issue Type: Bug
>  Components: process
>Affects Versions: 3.2.6
>Reporter: Daniel Kuppitz
>Assignee: Daniel Kuppitz
> Fix For: 3.2.7, 3.3.1
>
>
> See: https://groups.google.com/d/msg/gremlin-users/90IY6QMp4YQ/w60l_pfvCgAJ



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

Re: [DISCUSS] Asciidoc Header Reformat

2017-09-26 Thread Robert Dale

Looks like master CHANGELOG picked up a conflict...

<<< HEAD
== TinkerPop 3.3.0 (Gremlin Symphony #40 in G Minor)
.
.
.

== TinkerPop 3.2.0 (Nine Inch Gremlins)
===
== TinkerPop 3.2.0 (Nine Inch Gremlins)
>>> asciidoc-header


Robert Dale

On Tue, Sep 26, 2017 at 1:19 PM, Daniel Kuppitz  wrote:

> Ah, good find! That's the same issue I've had in the reference docs and
> recipes. Fixed.
>
> Cheers,
> Daniel
>
>
> On Tue, Sep 26, 2017 at 10:08 AM, Robert Dale  wrote:
>
> > git grep "== =="
> >
> > Robert Dale
> >
> > On Tue, Sep 26, 2017 at 1:07 PM, Robert Dale  wrote:
> >
> > > I see things like '== ==>6' in docs/src/upgrade/release-3.2.
> > > x-incubating.html
> > >
> > > Robert Dale
> > >
> > > On Tue, Sep 26, 2017 at 12:57 PM, Robert Dale 
> wrote:
> > >
> > >> ^d
> > >>
> > >> Robert Dale
> > >>
> > >> On Tue, Sep 26, 2017 at 12:56 PM, Daniel Kuppitz 
> > wrote:
> > >>
> > >>> This is one. I pushed the changes to tp32/ and master/. I only found
> > (and
> > >>> fixed) 2 minor issues, where my script produced a little formatting
> > mess.
> > >>>
> > >>> Cheers,
> > >>> Daniel
> > >>>
> > >>>
> > >>> On Tue, Sep 19, 2017 at 9:23 AM, Stephen Mallette <
> > spmalle...@gmail.com>
> > >>> wrote:
> > >>>
> > >>> > For whatever reason we started writing our headers in our docs
> with:
> > >>> >
> > >>> > Header
> > >>> > ==
> > >>> >
> > >>> > Subheader
> > >>> > -
> > >>> >
> > >>> > SubSubHeader
> > >>> > 
> > >>> >
> > >>> > as opposed to the alternative:
> > >>> >
> > >>> > = This Is A Header
> > >>> >
> > >>> > == Subheader
> > >>> >
> > >>> > === SubSubHeader
> > >>> >
> > >>> > The downside with the first approach is that it forces us to do two
> > >>> things:
> > >>> >
> > >>> > 1. Remember the syntax for each header layer (which we all probably
> > >>> know
> > >>> > pretty well at this point, but still...)
> > >>> > 2. Ensure that the width of the header formatting line is equal to
> > the
> > >>> > length of the text above it.
> > >>> >
> > >>> > That second point is a killer sometimes. While I've trained myself
> to
> > >>> be
> > >>> > good at noticing that problem I know it's bitten us in releases
> over
> > >>> and
> > >>> > over and over again.
> > >>> >
> > >>> > Anyway, I think going to the alternative formatting would be better
> > and
> > >>> > propose to do a full reformatting. Please let me know if there are
> > any
> > >>> > concerns about doing that - if I don't hear back in the next few
> days
> > >>> I'll
> > >>> > proceed with the changes.
> > >>> >
> > >>> > Thanks,
> > >>> >
> > >>> > Stephen
> > >>> >
> > >>>
> > >>
> > >>
> > >
> >
>

Re: [DISCUSS] Asciidoc Header Reformat

2017-09-26 Thread Daniel Kuppitz

Ah, good find! That's the same issue I've had in the reference docs and
recipes. Fixed.

Cheers,
Daniel


On Tue, Sep 26, 2017 at 10:08 AM, Robert Dale  wrote:

> git grep "== =="
>
> Robert Dale
>
> On Tue, Sep 26, 2017 at 1:07 PM, Robert Dale  wrote:
>
> > I see things like '== ==>6' in docs/src/upgrade/release-3.2.
> > x-incubating.html
> >
> > Robert Dale
> >
> > On Tue, Sep 26, 2017 at 12:57 PM, Robert Dale  wrote:
> >
> >> ^d
> >>
> >> Robert Dale
> >>
> >> On Tue, Sep 26, 2017 at 12:56 PM, Daniel Kuppitz 
> wrote:
> >>
> >>> This is one. I pushed the changes to tp32/ and master/. I only found
> (and
> >>> fixed) 2 minor issues, where my script produced a little formatting
> mess.
> >>>
> >>> Cheers,
> >>> Daniel
> >>>
> >>>
> >>> On Tue, Sep 19, 2017 at 9:23 AM, Stephen Mallette <
> spmalle...@gmail.com>
> >>> wrote:
> >>>
> >>> > For whatever reason we started writing our headers in our docs with:
> >>> >
> >>> > Header
> >>> > ==
> >>> >
> >>> > Subheader
> >>> > -
> >>> >
> >>> > SubSubHeader
> >>> > 
> >>> >
> >>> > as opposed to the alternative:
> >>> >
> >>> > = This Is A Header
> >>> >
> >>> > == Subheader
> >>> >
> >>> > === SubSubHeader
> >>> >
> >>> > The downside with the first approach is that it forces us to do two
> >>> things:
> >>> >
> >>> > 1. Remember the syntax for each header layer (which we all probably
> >>> know
> >>> > pretty well at this point, but still...)
> >>> > 2. Ensure that the width of the header formatting line is equal to
> the
> >>> > length of the text above it.
> >>> >
> >>> > That second point is a killer sometimes. While I've trained myself to
> >>> be
> >>> > good at noticing that problem I know it's bitten us in releases over
> >>> and
> >>> > over and over again.
> >>> >
> >>> > Anyway, I think going to the alternative formatting would be better
> and
> >>> > propose to do a full reformatting. Please let me know if there are
> any
> >>> > concerns about doing that - if I don't hear back in the next few days
> >>> I'll
> >>> > proceed with the changes.
> >>> >
> >>> > Thanks,
> >>> >
> >>> > Stephen
> >>> >
> >>>
> >>
> >>
> >
>

Re: [DISCUSS] Asciidoc Header Reformat

2017-09-26 Thread Robert Dale

git grep "== =="

Robert Dale

On Tue, Sep 26, 2017 at 1:07 PM, Robert Dale  wrote:

> I see things like '== ==>6' in docs/src/upgrade/release-3.2.
> x-incubating.html
>
> Robert Dale
>
> On Tue, Sep 26, 2017 at 12:57 PM, Robert Dale  wrote:
>
>> ^d
>>
>> Robert Dale
>>
>> On Tue, Sep 26, 2017 at 12:56 PM, Daniel Kuppitz  wrote:
>>
>>> This is one. I pushed the changes to tp32/ and master/. I only found (and
>>> fixed) 2 minor issues, where my script produced a little formatting mess.
>>>
>>> Cheers,
>>> Daniel
>>>
>>>
>>> On Tue, Sep 19, 2017 at 9:23 AM, Stephen Mallette 
>>> wrote:
>>>
>>> > For whatever reason we started writing our headers in our docs with:
>>> >
>>> > Header
>>> > ==
>>> >
>>> > Subheader
>>> > -
>>> >
>>> > SubSubHeader
>>> > 
>>> >
>>> > as opposed to the alternative:
>>> >
>>> > = This Is A Header
>>> >
>>> > == Subheader
>>> >
>>> > === SubSubHeader
>>> >
>>> > The downside with the first approach is that it forces us to do two
>>> things:
>>> >
>>> > 1. Remember the syntax for each header layer (which we all probably
>>> know
>>> > pretty well at this point, but still...)
>>> > 2. Ensure that the width of the header formatting line is equal to the
>>> > length of the text above it.
>>> >
>>> > That second point is a killer sometimes. While I've trained myself to
>>> be
>>> > good at noticing that problem I know it's bitten us in releases over
>>> and
>>> > over and over again.
>>> >
>>> > Anyway, I think going to the alternative formatting would be better and
>>> > propose to do a full reformatting. Please let me know if there are any
>>> > concerns about doing that - if I don't hear back in the next few days
>>> I'll
>>> > proceed with the changes.
>>> >
>>> > Thanks,
>>> >
>>> > Stephen
>>> >
>>>
>>
>>
>

Re: [DISCUSS] Asciidoc Header Reformat

2017-09-26 Thread Robert Dale

I see things like '== ==>6' in
docs/src/upgrade/release-3.2.x-incubating.html

Robert Dale

On Tue, Sep 26, 2017 at 12:57 PM, Robert Dale  wrote:

> ^d
>
> Robert Dale
>
> On Tue, Sep 26, 2017 at 12:56 PM, Daniel Kuppitz  wrote:
>
>> This is one. I pushed the changes to tp32/ and master/. I only found (and
>> fixed) 2 minor issues, where my script produced a little formatting mess.
>>
>> Cheers,
>> Daniel
>>
>>
>> On Tue, Sep 19, 2017 at 9:23 AM, Stephen Mallette 
>> wrote:
>>
>> > For whatever reason we started writing our headers in our docs with:
>> >
>> > Header
>> > ==
>> >
>> > Subheader
>> > -
>> >
>> > SubSubHeader
>> > 
>> >
>> > as opposed to the alternative:
>> >
>> > = This Is A Header
>> >
>> > == Subheader
>> >
>> > === SubSubHeader
>> >
>> > The downside with the first approach is that it forces us to do two
>> things:
>> >
>> > 1. Remember the syntax for each header layer (which we all probably know
>> > pretty well at this point, but still...)
>> > 2. Ensure that the width of the header formatting line is equal to the
>> > length of the text above it.
>> >
>> > That second point is a killer sometimes. While I've trained myself to be
>> > good at noticing that problem I know it's bitten us in releases over and
>> > over and over again.
>> >
>> > Anyway, I think going to the alternative formatting would be better and
>> > propose to do a full reformatting. Please let me know if there are any
>> > concerns about doing that - if I don't hear back in the next few days
>> I'll
>> > proceed with the changes.
>> >
>> > Thanks,
>> >
>> > Stephen
>> >
>>
>
>

Re: [DISCUSS] Asciidoc Header Reformat

2017-09-26 Thread Robert Dale

^d

Robert Dale

On Tue, Sep 26, 2017 at 12:56 PM, Daniel Kuppitz  wrote:

> This is one. I pushed the changes to tp32/ and master/. I only found (and
> fixed) 2 minor issues, where my script produced a little formatting mess.
>
> Cheers,
> Daniel
>
>
> On Tue, Sep 19, 2017 at 9:23 AM, Stephen Mallette 
> wrote:
>
> > For whatever reason we started writing our headers in our docs with:
> >
> > Header
> > ==
> >
> > Subheader
> > -
> >
> > SubSubHeader
> > 
> >
> > as opposed to the alternative:
> >
> > = This Is A Header
> >
> > == Subheader
> >
> > === SubSubHeader
> >
> > The downside with the first approach is that it forces us to do two
> things:
> >
> > 1. Remember the syntax for each header layer (which we all probably know
> > pretty well at this point, but still...)
> > 2. Ensure that the width of the header formatting line is equal to the
> > length of the text above it.
> >
> > That second point is a killer sometimes. While I've trained myself to be
> > good at noticing that problem I know it's bitten us in releases over and
> > over and over again.
> >
> > Anyway, I think going to the alternative formatting would be better and
> > propose to do a full reformatting. Please let me know if there are any
> > concerns about doing that - if I don't hear back in the next few days
> I'll
> > proceed with the changes.
> >
> > Thanks,
> >
> > Stephen
> >
>

Re: [DISCUSS] Asciidoc Header Reformat

2017-09-26 Thread Daniel Kuppitz

This is one. I pushed the changes to tp32/ and master/. I only found (and
fixed) 2 minor issues, where my script produced a little formatting mess.

Cheers,
Daniel


On Tue, Sep 19, 2017 at 9:23 AM, Stephen Mallette 
wrote:

> For whatever reason we started writing our headers in our docs with:
>
> Header
> ==
>
> Subheader
> -
>
> SubSubHeader
> 
>
> as opposed to the alternative:
>
> = This Is A Header
>
> == Subheader
>
> === SubSubHeader
>
> The downside with the first approach is that it forces us to do two things:
>
> 1. Remember the syntax for each header layer (which we all probably know
> pretty well at this point, but still...)
> 2. Ensure that the width of the header formatting line is equal to the
> length of the text above it.
>
> That second point is a killer sometimes. While I've trained myself to be
> good at noticing that problem I know it's bitten us in releases over and
> over and over again.
>
> Anyway, I think going to the alternative formatting would be better and
> propose to do a full reformatting. Please let me know if there are any
> concerns about doing that - if I don't hear back in the next few days I'll
> proceed with the changes.
>
> Thanks,
>
> Stephen
>

[jira] [Commented] (TINKERPOP-1752) Gremlin.Net: Generate completely type-safe methods

2017-09-26 Thread ASF GitHub Bot (JIRA)


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

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

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

https://github.com/apache/tinkerpop/pull/712#discussion_r141112905
  
--- Diff: gremlin-dotnet/src/Gremlin.Net/Process/Traversal/Bytecode.cs ---
@@ -79,7 +85,77 @@ public void AddSource(string sourceName, params object[] 
args)
 /// The traversal method arguments.
 public void AddStep(string stepName, params object[] args)
 {
-StepInstructions.Add(new Instruction(stepName, args));
+StepInstructions.Add(new Instruction(stepName, 
FlattenArguments(args)));
+Bindings.Clear();
--- End diff --

Any reason we don't support lambdas? Even if .NET can't support them 
natively for some reason wouldn't we minimally support the ability to pass a 
python/groovy/etc lambda? it's kinda weird that way, but i think back to the 
point that kuppitz made on the dev list the other day where he stated that he 
doesn't always find a way out of using lambdas in production systems he works 
on - so ultimately users will need that kind of capability i think.


> Gremlin.Net: Generate completely type-safe methods
> --
>
> Key: TINKERPOP-1752
> URL: https://issues.apache.org/jira/browse/TINKERPOP-1752
> Project: TinkerPop
>  Issue Type: Improvement
>  Components: dotnet
>Affects Versions: 3.2.5
>Reporter: Florian Hockmann
>Priority: Minor
>
> Currently the generated traversal methods in Gremlin.Net take {{params 
> object[] args}} as an argument which allows the user to provide an arbitrary 
> number of arguments with any type. While this makes the generation rather 
> simple, it doesn't tell the user which arguments are actually valid so users 
> can submit completely invalid traversals like:
> {code}
> g.V(1).AddE(1234, "invalidArgument2").Next()
> {code}
> Type-safe methods could also use the original argument names to tell users 
> something about what kind of values the methods expect. Consider for example 
> the following method signatures for the C# step {{AddE}} that are basically a 
> 1:1 representation of the original Java {{addE}} step:
> {code}
> public GraphTraversal< S , Edge > AddE (Direction direction, string 
> firstVertexKeyOrEdgeLabel, string edgeLabelOrSecondVertexKey, params object[] 
> propertyKeyValues);
> public GraphTraversal< S , Edge > AddE (string edgeLabel);
> {code}
> Implementing this should make TINKERPOP-1725 obsolete and also resolve 
> TINKERPOP-1751.



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

[GitHub] tinkerpop pull request #712: TINKERPOP-1752: Gremlin.Net: Generate completel...

2017-09-26 Thread spmallette

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

https://github.com/apache/tinkerpop/pull/712#discussion_r141112905
  
--- Diff: gremlin-dotnet/src/Gremlin.Net/Process/Traversal/Bytecode.cs ---
@@ -79,7 +85,77 @@ public void AddSource(string sourceName, params object[] 
args)
 /// The traversal method arguments.
 public void AddStep(string stepName, params object[] args)
 {
-StepInstructions.Add(new Instruction(stepName, args));
+StepInstructions.Add(new Instruction(stepName, 
FlattenArguments(args)));
+Bindings.Clear();
--- End diff --

Any reason we don't support lambdas? Even if .NET can't support them 
natively for some reason wouldn't we minimally support the ability to pass a 
python/groovy/etc lambda? it's kinda weird that way, but i think back to the 
point that kuppitz made on the dev list the other day where he stated that he 
doesn't always find a way out of using lambdas in production systems he works 
on - so ultimately users will need that kind of capability i think.


---

[jira] [Commented] (TINKERPOP-1752) Gremlin.Net: Generate completely type-safe methods

2017-09-26 Thread ASF GitHub Bot (JIRA)


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

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

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

https://github.com/apache/tinkerpop/pull/712#discussion_r141109744
  
--- Diff: gremlin-dotnet/src/Gremlin.Net/Process/Traversal/Bytecode.cs ---
@@ -79,7 +85,77 @@ public void AddSource(string sourceName, params object[] 
args)
 /// The traversal method arguments.
 public void AddStep(string stepName, params object[] args)
 {
-StepInstructions.Add(new Instruction(stepName, args));
+StepInstructions.Add(new Instruction(stepName, 
FlattenArguments(args)));
+Bindings.Clear();
--- End diff --

I agree that a solution could be an overkill on the API...

I'm +1 from not supporting bindings in the .NET GLV (and document it), I 
don't see much purpose.

What do you think about not supporting Bindings on the .NET GLV @okram 
@spmallette @robertdale ?


> Gremlin.Net: Generate completely type-safe methods
> --
>
> Key: TINKERPOP-1752
> URL: https://issues.apache.org/jira/browse/TINKERPOP-1752
> Project: TinkerPop
>  Issue Type: Improvement
>  Components: dotnet
>Affects Versions: 3.2.5
>Reporter: Florian Hockmann
>Priority: Minor
>
> Currently the generated traversal methods in Gremlin.Net take {{params 
> object[] args}} as an argument which allows the user to provide an arbitrary 
> number of arguments with any type. While this makes the generation rather 
> simple, it doesn't tell the user which arguments are actually valid so users 
> can submit completely invalid traversals like:
> {code}
> g.V(1).AddE(1234, "invalidArgument2").Next()
> {code}
> Type-safe methods could also use the original argument names to tell users 
> something about what kind of values the methods expect. Consider for example 
> the following method signatures for the C# step {{AddE}} that are basically a 
> 1:1 representation of the original Java {{addE}} step:
> {code}
> public GraphTraversal< S , Edge > AddE (Direction direction, string 
> firstVertexKeyOrEdgeLabel, string edgeLabelOrSecondVertexKey, params object[] 
> propertyKeyValues);
> public GraphTraversal< S , Edge > AddE (string edgeLabel);
> {code}
> Implementing this should make TINKERPOP-1725 obsolete and also resolve 
> TINKERPOP-1751.



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

[GitHub] tinkerpop pull request #712: TINKERPOP-1752: Gremlin.Net: Generate completel...

2017-09-26 Thread jorgebay

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

https://github.com/apache/tinkerpop/pull/712#discussion_r141109744
  
--- Diff: gremlin-dotnet/src/Gremlin.Net/Process/Traversal/Bytecode.cs ---
@@ -79,7 +85,77 @@ public void AddSource(string sourceName, params object[] 
args)
 /// The traversal method arguments.
 public void AddStep(string stepName, params object[] args)
 {
-StepInstructions.Add(new Instruction(stepName, args));
+StepInstructions.Add(new Instruction(stepName, 
FlattenArguments(args)));
+Bindings.Clear();
--- End diff --

I agree that a solution could be an overkill on the API...

I'm +1 from not supporting bindings in the .NET GLV (and document it), I 
don't see much purpose.

What do you think about not supporting Bindings on the .NET GLV @okram 
@spmallette @robertdale ?


---

[jira] [Commented] (TINKERPOP-1752) Gremlin.Net: Generate completely type-safe methods

2017-09-26 Thread ASF GitHub Bot (JIRA)


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

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

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

https://github.com/apache/tinkerpop/pull/712#discussion_r141104538
  
--- Diff: gremlin-dotnet/src/Gremlin.Net/Process/Traversal/Bytecode.cs ---
@@ -79,7 +85,77 @@ public void AddSource(string sourceName, params object[] 
args)
 /// The traversal method arguments.
 public void AddStep(string stepName, params object[] args)
 {
-StepInstructions.Add(new Instruction(stepName, args));
+StepInstructions.Add(new Instruction(stepName, 
FlattenArguments(args)));
+Bindings.Clear();
--- End diff --

This is definitely a problem, but do you see a way to fix it? 
Unfortunately, I think we have to use `static` here unless we want to create 
overloads for each parameter in the Traversal API that takes a `Binding` 
instead of the unbound variable which would result in a lot of overloads.

Since [`Bindings` don't seem to improve the performance with 
Bytecode](https://lists.apache.org/thread.html/c10baff72e67a8b7728c42b5c4e983a83e82b8f6964b3aa465f0e341@)
 when no lambdas are used which we don't support anyway, we may also remove the 
support for `Bindings` altogether from Gremlin.Net. Then we also don't need the 
`FlattenArguments` and `ConvertArgument` functions in `Bytecode` which are not 
exactly intuitive.

Or if we want to continue supporting them, we could also add a note to the 
documentation to make users aware of these concurrency problems with `Bindings`.


> Gremlin.Net: Generate completely type-safe methods
> --
>
> Key: TINKERPOP-1752
> URL: https://issues.apache.org/jira/browse/TINKERPOP-1752
> Project: TinkerPop
>  Issue Type: Improvement
>  Components: dotnet
>Affects Versions: 3.2.5
>Reporter: Florian Hockmann
>Priority: Minor
>
> Currently the generated traversal methods in Gremlin.Net take {{params 
> object[] args}} as an argument which allows the user to provide an arbitrary 
> number of arguments with any type. While this makes the generation rather 
> simple, it doesn't tell the user which arguments are actually valid so users 
> can submit completely invalid traversals like:
> {code}
> g.V(1).AddE(1234, "invalidArgument2").Next()
> {code}
> Type-safe methods could also use the original argument names to tell users 
> something about what kind of values the methods expect. Consider for example 
> the following method signatures for the C# step {{AddE}} that are basically a 
> 1:1 representation of the original Java {{addE}} step:
> {code}
> public GraphTraversal< S , Edge > AddE (Direction direction, string 
> firstVertexKeyOrEdgeLabel, string edgeLabelOrSecondVertexKey, params object[] 
> propertyKeyValues);
> public GraphTraversal< S , Edge > AddE (string edgeLabel);
> {code}
> Implementing this should make TINKERPOP-1725 obsolete and also resolve 
> TINKERPOP-1751.



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

[GitHub] tinkerpop pull request #712: TINKERPOP-1752: Gremlin.Net: Generate completel...

2017-09-26 Thread FlorianHockmann

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

https://github.com/apache/tinkerpop/pull/712#discussion_r141104538
  
--- Diff: gremlin-dotnet/src/Gremlin.Net/Process/Traversal/Bytecode.cs ---
@@ -79,7 +85,77 @@ public void AddSource(string sourceName, params object[] 
args)
 /// The traversal method arguments.
 public void AddStep(string stepName, params object[] args)
 {
-StepInstructions.Add(new Instruction(stepName, args));
+StepInstructions.Add(new Instruction(stepName, 
FlattenArguments(args)));
+Bindings.Clear();
--- End diff --

This is definitely a problem, but do you see a way to fix it? 
Unfortunately, I think we have to use `static` here unless we want to create 
overloads for each parameter in the Traversal API that takes a `Binding` 
instead of the unbound variable which would result in a lot of overloads.

Since [`Bindings` don't seem to improve the performance with 
Bytecode](https://lists.apache.org/thread.html/c10baff72e67a8b7728c42b5c4e983a83e82b8f6964b3aa465f0e341@)
 when no lambdas are used which we don't support anyway, we may also remove the 
support for `Bindings` altogether from Gremlin.Net. Then we also don't need the 
`FlattenArguments` and `ConvertArgument` functions in `Bytecode` which are not 
exactly intuitive.

Or if we want to continue supporting them, we could also add a note to the 
documentation to make users aware of these concurrency problems with `Bindings`.


---

[jira] [Commented] (TINKERPOP-1782) RangeByIsCountStrategy doesn't handle floating point numbers properly

2017-09-26 Thread ASF GitHub Bot (JIRA)


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

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

Github user okram commented on the issue:

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



> RangeByIsCountStrategy doesn't handle floating point numbers properly
> -
>
> Key: TINKERPOP-1782
> URL: https://issues.apache.org/jira/browse/TINKERPOP-1782
> Project: TinkerPop
>  Issue Type: Bug
>  Components: process
>Affects Versions: 3.2.6
>Reporter: Daniel Kuppitz
>Assignee: Daniel Kuppitz
>
> See: https://groups.google.com/d/msg/gremlin-users/90IY6QMp4YQ/w60l_pfvCgAJ



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

[GitHub] tinkerpop issue #714: TINKERPOP-1782 RangeByIsCountStrategy doesn't handle f...

2017-09-26 Thread okram

Github user okram commented on the issue:

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



---

[jira] [Commented] (TINKERPOP-1792) Random TraversalSource Selection in GremlinScriptEngine

[GitHub] tinkerpop pull request #723: TINKERPOP-1792 Fixed GremlinScriptEngine bug in...

[jira] [Commented] (TINKERPOP-1789) Reference elements should be represented by id and label

[jira] [Created] (TINKERPOP-1793) addE() should allow dynamic edge labels

[jira] [Commented] (TINKERPOP-1786) Recipe and missing manifest items for Spark on Yarn

[GitHub] tinkerpop issue #721: TINKERPOP-1786 Recipe and missing manifest items for S...

Re: [DISCUSS] Asciidoc Header Reformat

Re: [DISCUSS] Asciidoc Header Reformat

Re: [DISCUSS] Asciidoc Header Reformat

[jira] [Commented] (TINKERPOP-1789) Reference elements should be represented by id and label

[GitHub] tinkerpop issue #720: TINKERPOP-1789: Reference elements should be represent...

Re: [DISCUSS] Asciidoc Header Reformat

[jira] [Commented] (TINKERPOP-1782) RangeByIsCountStrategy doesn't handle floating point numbers properly

[GitHub] tinkerpop pull request #714: TINKERPOP-1782 RangeByIsCountStrategy doesn't h...

[jira] [Closed] (TINKERPOP-1782) RangeByIsCountStrategy doesn't handle floating point numbers properly

Re: [DISCUSS] Asciidoc Header Reformat

Re: [DISCUSS] Asciidoc Header Reformat

Re: [DISCUSS] Asciidoc Header Reformat

Re: [DISCUSS] Asciidoc Header Reformat

Re: [DISCUSS] Asciidoc Header Reformat

Re: [DISCUSS] Asciidoc Header Reformat

[jira] [Commented] (TINKERPOP-1752) Gremlin.Net: Generate completely type-safe methods

[GitHub] tinkerpop pull request #712: TINKERPOP-1752: Gremlin.Net: Generate completel...

[jira] [Commented] (TINKERPOP-1752) Gremlin.Net: Generate completely type-safe methods

[GitHub] tinkerpop pull request #712: TINKERPOP-1752: Gremlin.Net: Generate completel...

[jira] [Commented] (TINKERPOP-1752) Gremlin.Net: Generate completely type-safe methods

[GitHub] tinkerpop pull request #712: TINKERPOP-1752: Gremlin.Net: Generate completel...

[jira] [Commented] (TINKERPOP-1782) RangeByIsCountStrategy doesn't handle floating point numbers properly

[GitHub] tinkerpop issue #714: TINKERPOP-1782 RangeByIsCountStrategy doesn't handle f...

29 matches

Site Navigation

Mail list logo

Footer information