Re: [DISCUSS] Accepting gremlint donation
I think that sounds like a good approach. I'll see if I can get started on that this week. man. 1. mar. 2021 kl. 13:12 skrev Stephen Mallette : > Øyvind, We've discussed a few different ways to bring the code in at this > point. Here's some first steps on your end that I think would be in order: > > 1. Submit a pull request with the gremlint code. We'd earlier discussed a > gremlint directory at the root of the repository. I think that still makes > sense. > 2. Make the appropriate modifications to your gremlint repository to point > users to the Apache repository and to "retire" that old repo > 3. We use JIRA for issue tracking[1]. I've created a Component type for > gremlint. Consider migrating any of your GitHub Issues you think relevant > to JIRA so that they may be tracked in this project. > > How's that for a start? > > [1] https://issues.apache.org/jira/projects/TINKERPOP/summary/statistics > > On Fri, Feb 26, 2021 at 10:37 AM Stephen Mallette > wrote: > > > The IP Clearance lazy consensus was achieved. I've closed the thread: > > > > > > > https://lists.apache.org/thread.html/r207e7f7b4de1b1fa4699012b9d9f53fcf5b43cc3efb80559aea0741f%40%3Cgeneral.incubator.apache.org%3E > > > > i think we can now focus on bringing in the code! > > > > On Mon, Feb 22, 2021 at 10:51 AM Stephen Mallette > > wrote: > > > >> I just closed the VOTE thread and it passed as expected: > >> > >> > >> > https://lists.apache.org/thread.html/r1006ed56b5d92628f3378f9baef854da6fef3f83d8492b746b467ab6%40%3Cdev.tinkerpop.apache.org%3E > >> > >> I've updated the IP Clearance document: > >> > >> > >> > https://svn.apache.org/repos/asf/incubator/public/trunk/content/ip-clearance/tinkerpop-gremlint.xml > >> > >> I think my last step is to write a post to Incubator to point to the > >> document and to request lazy consensus. I will get that out soon enough. > >> > >> > >> > >> On Wed, Feb 17, 2021 at 8:26 AM Øyvind Sæbø > >> wrote: > >> > >>> Very nice! The process seems a bit backwards to me too, but oh well. > >>> > >>> ons. 17. feb. 2021 kl. 13:37 skrev Stephen Mallette < > >>> spmalle...@gmail.com>: > >>> > >>> > I believe that the IP Clearance document is all complete now: > >>> > > >>> > > >>> > > >>> > https://svn.apache.org/repos/asf/incubator/public/trunk/content/ip-clearance/tinkerpop-gremlint.xml > >>> > > >>> > The process seems a bit backward to me, but I'd read elsewhere that > the > >>> > preferred method is to get this document complete and then issue a > VOTE > >>> > thread to confirm completeness and then add that thread link to the > >>> doc. At > >>> > that point, I then go get lazy consensus from Apache Incubator on the > >>> > submission. At that point we can work on the actual bits of bringing > >>> this > >>> > in. Almost there! > >>> > > >>> > On Fri, Feb 12, 2021 at 3:55 PM Øyvind Sæbø > >>> wrote: > >>> > > >>> > > Sounds good! > >>> > > > >>> > > I've always considered the gremlint repo and the gremlint.com repo > >>> to be > >>> > > the same project, distributed between two repos just for the sake > of > >>> > > separation of concerns. So both repos have the ASF license headers > in > >>> > their > >>> > > source files, saying that they are licensed to the ASF under one or > >>> more > >>> > > contributor license agreements. I imagined we could just include > the > >>> > latest > >>> > > commit id both from the gremlint master branch and from the > >>> gremlint.com > >>> > > master branch in the IP Clearance Document. However, if it turns > out > >>> to > >>> > be > >>> > > necessary to handle the IP clearance of the gremlint.com website > in > >>> a > >>> > more > >>> > > specific manner, we'll do what we can to accommodate that. > >>> > > > >>> > > fre. 12. feb. 2021 kl. 20:57 skrev Stephen Mallette < > >>> > spmalle...@gmail.com > >>> > > >: > >>> > > > >>> > > > I've updated the IP Clearance form with the latest information > >>> such as > >>> > I > >>> > > > have it. I cant remember how to regenerate the site so here's the > >>> raw > >>> > xml > >>> > > > for the file: > >>> > > > > >>> > > > > >>> > > > > >>> > > > >>> > > >>> > https://svn.apache.org/repos/asf/incubator/public/trunk/content/ip-clearance/tinkerpop-gremlint.xml > >>> > > > > >>> > > > Note that the only remaining piece is the CLA that you just > >>> submitted. > >>> > I > >>> > > > don't think we'll get confirmation on that from the secretary on > >>> our > >>> > end > >>> > > so > >>> > > > I will keep checking Apache records. Also note that I've used the > >>> > current > >>> > > > commit id from the gremlint master branch to denote the code that > >>> would > >>> > > be > >>> > > > donated. If I should use something else, please let me know. > >>> > > > > >>> > > > Finally, I wonder if we need to be concerned with the > gremlint.com > >>> > repo > >>> > > > since you mention that there isn't much there tying it to GitHub > >>> Pages. > >>> > > It > >>> > > > almost seems like the "deployed site" isn't really the artifact > >>>
[jira] [Closed] (TINKERPOP-2495) Extend GLV tests to cover lambdas
[
https://issues.apache.org/jira/browse/TINKERPOP-2495?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Stephen Mallette closed TINKERPOP-2495.
---
Resolution: Invalid
I think this is now generally supported in all languages. We already had lots
of tests that had lambdas in them and all the GLVs now consume them.
> Extend GLV tests to cover lambdas
> -
>
> Key: TINKERPOP-2495
> URL: https://issues.apache.org/jira/browse/TINKERPOP-2495
> Project: TinkerPop
> Issue Type: Improvement
> Components: test-suite
>Affects Versions: 3.5.0
>Reporter: Stephen Mallette
>Priority: Major
>
> Now that lambdas are universally supported and {{Translators}} handle them
> properly and we are trying to unify the test suite behind cucumber a good
> next step would be to migrate any tests that uses closures in the JVM test
> suite over to the GLV suite.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Closed] (TINKERPOP-2366) Gremlin Translators for Python
[ https://issues.apache.org/jira/browse/TINKERPOP-2366?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Stephen Mallette closed TINKERPOP-2366. --- Resolution: Duplicate > Gremlin Translators for Python > -- > > Key: TINKERPOP-2366 > URL: https://issues.apache.org/jira/browse/TINKERPOP-2366 > Project: TinkerPop > Issue Type: Improvement > Components: python, translator >Affects Versions: 3.4.6 >Reporter: Stephen Mallette >Priority: Trivial > > There is often a need to convert bytecode to its script like representation > and it is helpful to be able to do this natively in all programming > languages. While there is support for this feature in Java and Javascript > this functionality does not yet exist in Python. > https://github.com/apache/tinkerpop/blob/3.4.6/gremlin-javascript/src/main/javascript/gremlin-javascript/lib/process/translator.js > https://github.com/apache/tinkerpop/blob/3.4.6/gremlin-groovy/src/main/java/org/apache/tinkerpop/gremlin/groovy/jsr223/GroovyTranslator.java -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (TINKERPOP-2527) Add a GroovyTranslator equivalent method to the Python client
[ https://issues.apache.org/jira/browse/TINKERPOP-2527?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17292937#comment-17292937 ] ASF GitHub Bot commented on TINKERPOP-2527: --- spmallette commented on pull request #1399: URL: https://github.com/apache/tinkerpop/pull/1399#issuecomment-788018463 @krlawrence now that documentation is generating on `master` again I realized some sample code for Python->Groovy is needed on this PR: https://github.com/apache/tinkerpop/pull/1399/files#diff-aa69bbbf8224e408ea19bf3df1466e16e6309bcfb241f68b578032d9fbbbd48dR4301-R4335 Do you have a minute to add that? If you do, be sure to pull in my changes from this branch before you add your example. This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org > Add a GroovyTranslator equivalent method to the Python client > - > > Key: TINKERPOP-2527 > URL: https://issues.apache.org/jira/browse/TINKERPOP-2527 > Project: TinkerPop > Issue Type: Improvement > Components: python >Affects Versions: 3.5.0 >Reporter: Kelvin R. Lawrence >Assignee: Kelvin R. Lawrence >Priority: Major > > Currently there is no equivalent to GroovyTranslator for the Gremlin Python > client. There is one in the JavaScript client however. Adding one for the > Python client will further help in moving all the clients to a consistent > level of functionality. I have this mostly coded up and will try to submit > some code within the next few days. -- This message was sent by Atlassian Jira (v8.3.4#803005)
Apache TinkerPop Bio Update
To Committers/PMC Members, We got a bit out of the habit of sending this email during code freeze weeks. That seemed like asking for updates too often perhaps. Anyway, I figured it was time to check for updates. As an Apache TinkerPop committer and/or PMC member, your name is listed on the TinkerPop home page in the Contributor List[1] with your "bio". If you are active on the project, your "bio" reflects what you have been working on and what you expect to be working on with respect to TinkerPop for recent times (i.e. for the previous six months and the following six months). If you are currently inactive on the project, your "bio" reflects the full scope of all your contributions throughout your active periods. You can refer to the contributor listing policy[2] for full details. Please take a moment to update your bio directly in Git[3] or, if you would prefer, please reply to this email with your bio update and it will be added for you. If no changes are required, please reply to this email to confirm that this is the case. [1] https://tinkerpop.apache.org/#contributors [2] https://tinkerpop.apache.org/docs/current/dev/developer/#contributor-listing [3] https://github.com/apache/tinkerpop/blob/master/docs/site/home/index.html
[jira] [Closed] (TINKERPOP-2513) Generics insufficiently strict on property()
[
https://issues.apache.org/jira/browse/TINKERPOP-2513?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Stephen Mallette closed TINKERPOP-2513.
---
Fix Version/s: 3.5.0
Assignee: Stephen Mallette
Resolution: Fixed
> Generics insufficiently strict on property()
>
>
> Key: TINKERPOP-2513
> URL: https://issues.apache.org/jira/browse/TINKERPOP-2513
> Project: TinkerPop
> Issue Type: Bug
> Components: process
>Affects Versions: 3.4.9
>Reporter: Christopher Smith
>Assignee: Stephen Mallette
>Priority: Major
> Fix For: 3.5.0
>
>
> The method
> {code:java}
> GraphTraversal property(final VertexProperty.Cardinality cardinality,
> final Object key, final Object value, final Object... keyValues)
> {code}
> can be applied to any "current traversal location", whether that's a vertex
> or an edge. However, if this _particular_ signature is applied to an edge
> with _either_ (inclusive) {{cardinality}} or {{keyValues}} specified, it
> produces a {{ClassCastException}} when evaluated at
> {{AddPropertyStep.java:151}}. I understand entirely that multi-properties may
> not be supported on edges, but inadvertently adding {{single}} should, if an
> error, produce a compile-time error instead of a runtime
> {{ClassCastException}}. (At a minimum, a useful runtime exception should be
> thrown to indicate the semantic problem.)
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (TINKERPOP-2513) Generics insufficiently strict on property()
[
https://issues.apache.org/jira/browse/TINKERPOP-2513?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17292868#comment-17292868
]
ASF GitHub Bot commented on TINKERPOP-2513:
---
spmallette merged pull request #1393:
URL: https://github.com/apache/tinkerpop/pull/1393
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
> Generics insufficiently strict on property()
>
>
> Key: TINKERPOP-2513
> URL: https://issues.apache.org/jira/browse/TINKERPOP-2513
> Project: TinkerPop
> Issue Type: Bug
> Components: process
>Affects Versions: 3.4.9
>Reporter: Christopher Smith
>Assignee: Stephen Mallette
>Priority: Major
> Fix For: 3.5.0
>
>
> The method
> {code:java}
> GraphTraversal property(final VertexProperty.Cardinality cardinality,
> final Object key, final Object value, final Object... keyValues)
> {code}
> can be applied to any "current traversal location", whether that's a vertex
> or an edge. However, if this _particular_ signature is applied to an edge
> with _either_ (inclusive) {{cardinality}} or {{keyValues}} specified, it
> produces a {{ClassCastException}} when evaluated at
> {{AddPropertyStep.java:151}}. I understand entirely that multi-properties may
> not be supported on edges, but inadvertently adding {{single}} should, if an
> error, produce a compile-time error instead of a runtime
> {{ClassCastException}}. (At a minimum, a useful runtime exception should be
> thrown to indicate the semantic problem.)
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
Re: [DISCUSS] Revert to Groovy 2.x for 3.5.0
Docs are publishing now for 3.5.0 after the revert: https://tinkerpop.apache.org/docs/3.5.0-SNAPSHOT/reference/ On Fri, Feb 26, 2021 at 8:17 PM Stephen Mallette wrote: > I've reverted to Groovy 2.5.x and the 3.0 issue is reopened: > > https://issues.apache.org/jira/browse/TINKERPOP-2373 > > We're back to being fast on master. Going to generate docs for the first > time in months. Hopefully it won't be too big a mess. I will post back here > when I've got a new 3.5.0-SNAPSHOT published. > > On Fri, Feb 19, 2021 at 7:06 PM Josh Perryman > wrote: > >> As an interested observer, I think your concerns regarding Groovy are >> valid. All of your considerations look entirely reasonable. Perhaps move >> it >> to "risk" as suggested, and note it in the next board report. Maybe the >> Apache board has some pull in this situation? >> >> Reducing dependency on Groovy doesn't add a whole lot of value, but not >> being able to build the documentation is a definite problem. >> >> It's a shame. I rather like Groovy, though my actual professional use of >> it >> has been limited. >> >> -Josh >> >> On Fri, Feb 19, 2021 at 6:17 AM Stephen Mallette >> wrote: >> >> > Given the performance problems with Groovy 3.0 that I've detailed in >> this >> > thread: >> > >> > >> > >> https://lists.apache.org/thread.html/rbd7b09e53f7a0e421057192ed564907755252b8bd43085ecb16f98e4%40%3Cdev.tinkerpop.apache.org%3E >> > >> > and further documented in this issue: >> > >> > https://issues.apache.org/jira/browse/TINKERPOP-2526 >> > >> > and compounded by what I can only describe as unprecedented disinterest >> in >> > the problem by the Groovy Community, I think it wise that we revert 3.0 >> and >> > go back to 2.x. Thankfully, I think it was just this commit: >> > >> > >> > >> https://github.com/apache/tinkerpop/commit/cc3c5cb83e253b9949076628a7cfaade7f86f40e >> > >> > I will then reopen the Groovy 3.0 issue: >> > >> > https://issues.apache.org/jira/browse/TINKERPOP-2373 >> > >> > and link it to the performance blocker with TINKERPOP-2526. >> > >> > If there are no objections in the next 72 hours, I'll assume lazy >> consensus >> > and push on in this direction. >> > >> > I'm a bit shocked by the lack of feedback I've gotten on this issue from >> > Groovy to be honest. Just silence. It's understandable in that it is >> > perhaps a difficult/complex problem to get into but it's been months now >> > and without at least some direction and communication with Groovy >> project >> > members I could spend weeks developing a fix that may not even be >> > acceptable to be integrated into their code base. >> > >> > I don't want to read too much into this situation but it highlights our >> > continued dependence on Groovy despite our attempts to get better >> > separation as we went to TinkerPop 3. I'm starting to feel concerned >> that >> > this dependence is shifting further to "risk". I don't think we need to >> > make any immediate decisions, but with the expected move to processing >> > Gremlin with antlr (i.e. gremlin-script)[1] it might be time to try to >> cut >> > the cord further. Perhaps we switch to JShell for the Gremlin Console or >> > develop our own repl around gremlin-script?? Maybe we also deprecate >> Groovy >> > as a ScriptEngine in Gremlin Server and only host gremlin-script?? I >> > suppose that all of this is ideas for a different thread and for a >> > different day. >> > >> > [1] >> > >> > >> https://lists.apache.org/thread.html/rc9288877898d583b3307eebf09949d5887081da38186dd82e59077ae%40%3Cdev.tinkerpop.apache.org%3E >> > >> >
Re: [DISCUSS] Accepting gremlint donation
Øyvind, We've discussed a few different ways to bring the code in at this point. Here's some first steps on your end that I think would be in order: 1. Submit a pull request with the gremlint code. We'd earlier discussed a gremlint directory at the root of the repository. I think that still makes sense. 2. Make the appropriate modifications to your gremlint repository to point users to the Apache repository and to "retire" that old repo 3. We use JIRA for issue tracking[1]. I've created a Component type for gremlint. Consider migrating any of your GitHub Issues you think relevant to JIRA so that they may be tracked in this project. How's that for a start? [1] https://issues.apache.org/jira/projects/TINKERPOP/summary/statistics On Fri, Feb 26, 2021 at 10:37 AM Stephen Mallette wrote: > The IP Clearance lazy consensus was achieved. I've closed the thread: > > > https://lists.apache.org/thread.html/r207e7f7b4de1b1fa4699012b9d9f53fcf5b43cc3efb80559aea0741f%40%3Cgeneral.incubator.apache.org%3E > > i think we can now focus on bringing in the code! > > On Mon, Feb 22, 2021 at 10:51 AM Stephen Mallette > wrote: > >> I just closed the VOTE thread and it passed as expected: >> >> >> https://lists.apache.org/thread.html/r1006ed56b5d92628f3378f9baef854da6fef3f83d8492b746b467ab6%40%3Cdev.tinkerpop.apache.org%3E >> >> I've updated the IP Clearance document: >> >> >> https://svn.apache.org/repos/asf/incubator/public/trunk/content/ip-clearance/tinkerpop-gremlint.xml >> >> I think my last step is to write a post to Incubator to point to the >> document and to request lazy consensus. I will get that out soon enough. >> >> >> >> On Wed, Feb 17, 2021 at 8:26 AM Øyvind Sæbø >> wrote: >> >>> Very nice! The process seems a bit backwards to me too, but oh well. >>> >>> ons. 17. feb. 2021 kl. 13:37 skrev Stephen Mallette < >>> spmalle...@gmail.com>: >>> >>> > I believe that the IP Clearance document is all complete now: >>> > >>> > >>> > >>> https://svn.apache.org/repos/asf/incubator/public/trunk/content/ip-clearance/tinkerpop-gremlint.xml >>> > >>> > The process seems a bit backward to me, but I'd read elsewhere that the >>> > preferred method is to get this document complete and then issue a VOTE >>> > thread to confirm completeness and then add that thread link to the >>> doc. At >>> > that point, I then go get lazy consensus from Apache Incubator on the >>> > submission. At that point we can work on the actual bits of bringing >>> this >>> > in. Almost there! >>> > >>> > On Fri, Feb 12, 2021 at 3:55 PM Øyvind Sæbø >>> wrote: >>> > >>> > > Sounds good! >>> > > >>> > > I've always considered the gremlint repo and the gremlint.com repo >>> to be >>> > > the same project, distributed between two repos just for the sake of >>> > > separation of concerns. So both repos have the ASF license headers in >>> > their >>> > > source files, saying that they are licensed to the ASF under one or >>> more >>> > > contributor license agreements. I imagined we could just include the >>> > latest >>> > > commit id both from the gremlint master branch and from the >>> gremlint.com >>> > > master branch in the IP Clearance Document. However, if it turns out >>> to >>> > be >>> > > necessary to handle the IP clearance of the gremlint.com website in >>> a >>> > more >>> > > specific manner, we'll do what we can to accommodate that. >>> > > >>> > > fre. 12. feb. 2021 kl. 20:57 skrev Stephen Mallette < >>> > spmalle...@gmail.com >>> > > >: >>> > > >>> > > > I've updated the IP Clearance form with the latest information >>> such as >>> > I >>> > > > have it. I cant remember how to regenerate the site so here's the >>> raw >>> > xml >>> > > > for the file: >>> > > > >>> > > > >>> > > > >>> > > >>> > >>> https://svn.apache.org/repos/asf/incubator/public/trunk/content/ip-clearance/tinkerpop-gremlint.xml >>> > > > >>> > > > Note that the only remaining piece is the CLA that you just >>> submitted. >>> > I >>> > > > don't think we'll get confirmation on that from the secretary on >>> our >>> > end >>> > > so >>> > > > I will keep checking Apache records. Also note that I've used the >>> > current >>> > > > commit id from the gremlint master branch to denote the code that >>> would >>> > > be >>> > > > donated. If I should use something else, please let me know. >>> > > > >>> > > > Finally, I wonder if we need to be concerned with the gremlint.com >>> > repo >>> > > > since you mention that there isn't much there tying it to GitHub >>> Pages. >>> > > It >>> > > > almost seems like the "deployed site" isn't really the artifact >>> that >>> > this >>> > > > IP Clearance doc is about. That is more of an implementation >>> detail we >>> > > can >>> > > > handle separately, likely with the transfer of the domain name. >>> > > > >>> > > > Well, hopefully this process is getting close to being complete. >>> > Excited >>> > > to >>> > > > finally see it settling up. >>> > > > >>> > > > >>> > > > >>> > > > >>> > > > >>> > > > >>> > > > On Thu, Feb 11, 2021 a
Re: [DISCUSS] Request Retries
The pull request for this item is here in case it wasn't noticed: https://github.com/apache/tinkerpop/pull/1398 On Thu, Feb 18, 2021 at 8:23 PM David Bechberger wrote: > I think this would be a great way to allow customers to easily know if an > error was transient and able to be retried or not. > > Dave > > On Wed, Feb 17, 2021 at 4:06 AM Stephen Mallette > wrote: > > > I created this issue recently: > > > > https://issues.apache.org/jira/browse/TINKERPOP-2517 > > > > which discusses adding a new response status code that would let users > know > > when it is a good idea to consider a retry of a request. Graph providers > > could use this code to provide a hint when an error is likely resolvable > > with time. Usually, such errors are related to locking on transactions or > > some similar sort of issue. Currently users need to parse error messages > to > > determine when best to retry their requests which isn't so nice. > > > > To make this new code easy to use for providers we could provide a > specific > > TemporaryException that could be thrown/extended or i suppose a heavier > > approach would be to offer some kind of exception mapping that providers > > could supply to take their custom exceptions and convert them to this > form. > > Not sure which we would do, but the main point would be to provide the > code > > itself in the protocol itself so that drivers can begin to pick it up. > > > > I think we could add "SERVER_ERROR_TEMPORARY 596" for this purpose. I'd > > imagine it would be safe to even add it to 3.4.11. Thoughts? > > >
