[jira] [Commented] (TINKERPOP-1792) Random TraversalSource Selection in GremlinScriptEngine
[ https://issues.apache.org/jira/browse/TINKERPOP-1792?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=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...
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
[ https://issues.apache.org/jira/browse/TINKERPOP-1789?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=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)
[GitHub] tinkerpop issue #720: TINKERPOP-1789: Reference elements should be represent...
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 ---
[jira] [Created] (TINKERPOP-1793) addE() should allow dynamic edge labels
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
[ https://issues.apache.org/jira/browse/TINKERPOP-1786?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=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...
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
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
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
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
[ https://issues.apache.org/jira/browse/TINKERPOP-1789?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=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...
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
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
[ https://issues.apache.org/jira/browse/TINKERPOP-1782?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=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...
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
[ 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
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
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
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
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
^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
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
[ https://issues.apache.org/jira/browse/TINKERPOP-1752?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=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...
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
[ https://issues.apache.org/jira/browse/TINKERPOP-1752?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=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...
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
[ https://issues.apache.org/jira/browse/TINKERPOP-1752?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=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...
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
[ https://issues.apache.org/jira/browse/TINKERPOP-1782?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=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...
Github user okram commented on the issue: https://github.com/apache/tinkerpop/pull/714 VOTE +1 ---