[jira] [Created] (TINKERPOP-2290) Javascript GLV connection refused error handling

[Ted Wilmes (Jira)]

Ted Wilmes created TINKERPOP-2290:
-

 Summary: Javascript GLV connection refused error handling
 Key: TINKERPOP-2290
 URL: https://issues.apache.org/jira/browse/TINKERPOP-2290
 Project: TinkerPop
  Issue Type: Bug
  Components: javascript
Affects Versions: 3.4.1
Reporter: Ted Wilmes


I believe the Javascript driver is emitting connection refused errors in a 
manner that makes it difficult for users to add in retry and other error 
handling logic. My Javascript knowledge is minimal so apologies if the below 
examples are non-idiomatic Javascript.

Here's an example of the error:
{code:java}
UNCAUGHT:  { Error: connect ECONNREFUSED 127.0.0.1:8182
    at Object._errnoException (util.js:1022:11)
    at _exceptionWithHostPort (util.js:1044:20)
    at TCPConnectWrap.afterConnect [as oncomplete] (net.js:1198:14)
  code: 'ECONNREFUSED',
  errno: 'ECONNREFUSED',
  syscall: 'connect',
  address: '127.0.0.1',
  port: 8182 }
UNCAUGHT:  TypeError: Cannot read property 'aborted' of null
    at ClientRequest._req.on 
(/home/twilmes/repos/nodetest/node_modules/ws/lib/WebSocket.js:644:19)
    at emitOne (events.js:116:13)
    at ClientRequest.emit (events.js:211:7)
    at Socket.socketCloseListener (_http_client.js:363:9)
    at emitOne (events.js:121:20)
    at Socket.emit (events.js:211:7)
    at TCP._handle.close [as _onclose] (net.js:567:12) {code}
I did some looking at that UNCAUGHT TypeError is a separate issue and appears 
to be fixed in a newer version of the WS package that is being used.

To reproduce this problem, you can either start an application up and point it 
at a non-existant TP enabled DB (JanusGraph in my case) or turn the graph off 
while the application is running. After this is done, an error is logged but 
the only way I'm able to catch it is to do something like this:
{code:java}
 process.on('uncaughtException', function (err) {
   console.log("UNCAUGHT: ", err);
});{code}
Wrapping my queries and connection code in try/catch blocks does not catch 
anything.



--
This message was sent by Atlassian Jira
(v8.3.2#803003)

Re: [TP4 Benchmarking] Pipes vs. Single-Threaded RxJava vs. Multi-Threaded RxJava

[Ted Wilmes]

I hadn't put together that each compilation could have its own processor.
Very cool. Thanks for the benchmarking numbers. I had a tp3 inspired
JMH-based module in progress when I saw your results so I added the two
test traversals in. It doesn't do any parameterization of input sizes at
this point but if you're interested in checking it out I pushed it to the
tp4-jmh branch:
https://github.com/apache/tinkerpop/blob/tp4-jmh/java/machine/machine-perf-test/src/main/java/org/apache/tinkerpop/benchmark/util/AbstractTraversalBenchmarkBase.java
.

The benchmarks can be run from the command line or from the IDE using the
individual process tests:
https://github.com/apache/tinkerpop/tree/tp4-jmh/java/machine/machine-perf-test/src/main/java/org/apache/tinkerpop/benchmark/machine
.

Here's the median times for input size = 1000 that I pulled from running.
The full output includes the P90, P95, etc and it can also be set to dump
an average or raw throughput:

mvn clean test -DskipBenchmarks=false -Dforks=1 -DmeasureIterations=5
-DwarmupIterations=5

RxSerialTraversalBenchmark.g_inject_unfold_incr_incr_incr_incr:g_inject_unfold_incr_incr_incr_incr·p0.50
  sample  6.988  ms/op
RxParallelTraversalBenchmark.g_inject_unfold_incr_incr_incr_incr:g_inject_unfold_incr_incr_incr_incr·p0.50
  sample 11.633  ms/op
PipesTraversalBenchmark.g_inject_unfold_incr_incr_incr_incr:g_inject_unfold_incr_incr_incr_incr·p0.50
  sample  6.627  ms/op

RxSerialTraversalBenchmark.g_inject_unfold_repeat_times:g_inject_unfold_repeat_times·p0.50
sample 3.592  ms/op
RxParallelTraversalBenchmark.g_inject_unfold_repeat_times:g_inject_unfold_repeat_times·p0.50
sample  7.897  ms/op
PipesTraversalBenchmark.g_inject_unfold_repeat_times:g_inject_unfold_repeat_times·p0.50
sample  3.887  ms/op

JMH is great, but the defaults will have it do a ton of timing runs which
is slow so for quicker (but less accurate) runs the measureIterations and
warmupIterations can be decreased.

--Ted

On Mon, Apr 8, 2019 at 12:16 PM Marko Rodriguez 
wrote:

> Hi,
>
> I implemented Multi-threaded RxJava this morning — its called
> ParallelRxJava. Single-threaded is called SerialRxJava.
>
> The RxJavaProcessor factory will generate either depending on the Map.of()
> configuration:
>
>
> https://github.com/apache/tinkerpop/blob/tp4/java/machine/processor/rxjava/src/main/java/org/apache/tinkerpop/machine/processor/rxjava/RxJavaProcessor.java#L49-L53
> <
> https://github.com/apache/tinkerpop/blob/tp4/java/machine/processor/rxjava/src/main/java/org/apache/tinkerpop/machine/processor/rxjava/RxJavaProcessor.java#L49-L53
> >
>
>  You can see the source code for each RxJava implementation here:
>
>
> https://github.com/apache/tinkerpop/blob/tp4/java/machine/processor/rxjava/src/main/java/org/apache/tinkerpop/machine/processor/rxjava/SerialRxJava.java
> <
> https://github.com/apache/tinkerpop/blob/tp4/java/machine/processor/rxjava/src/main/java/org/apache/tinkerpop/machine/processor/rxjava/SerialRxJava.java
> >
>
> https://github.com/apache/tinkerpop/blob/tp4/java/machine/processor/rxjava/src/main/java/org/apache/tinkerpop/machine/processor/rxjava/ParallelRxJava.java
> <
> https://github.com/apache/tinkerpop/blob/tp4/java/machine/processor/rxjava/src/main/java/org/apache/tinkerpop/machine/processor/rxjava/ParallelRxJava.java
> >
>
> Given Ted’s comments last week, I decided to create a micro-benchmark
> @Test to compare SerialRxJava, ParallelRxJava, and Pipes.
>
>
> https://github.com/apache/tinkerpop/blob/tp4/java/machine/processor/rxjava/src/test/java/org/apache/tinkerpop/machine/processor/rxjava/RxJavaBenchmark.java
> <
> https://github.com/apache/tinkerpop/blob/tp4/java/machine/processor/rxjava/src/test/java/org/apache/tinkerpop/machine/processor/rxjava/RxJavaBenchmark.java
> >
>
> The results are below. My notes on the results are as follows:
>
> * ParallelRxJava used 7 threads.
> * Times averaged over 30 runs (minus the first 2 runs — JVM
> warmup).
> * SerialRxJava and Pipes are very close on non-branching
> traversals with a small input set.
> * ParallelRxJava never beats Pipes, but does beat SerialRxJava on
> large input sets.
> * My implementation of repeat() in RxJava is not good. I need to
> think of a better way to implement recursion (and branching in general).
> * ParallelRxJava will probably shine when the query has a lot of
> database operations (e.g. out(), inE(), addV(), etc.).
> * There is a lot of intelligence to to add to ParallelRxJava —
> e.g.,
> ** If the nested traversal is simple (only a few steps),
> don’t thread. For example, there is no need to thread the is() of
> choose(is(gt(3)),….).
> ** One of the beautiful things about TP4 is that each
> Compilation (nest) can have a different processor.
> *** Thus, parallel f

Re: A Question Regarding TP4 Processor Classifications

[Ted Wilmes]

> >> I would
> >> imagine Pipes would beat the Flowable performance on a single traversal
> >> side-by-side basis (thought perhaps not by much), but the Flowable
> version
> >> would likely scale up to higher throughput and better CPU utilization
> when
> >> under concurrent load.
> >
> >
> > Pipes is definitely faster than RxJava (single-threaded). While I only
> learned RxJava 36 hours ago, I don’t believe it will ever beat Pipes
> because Pipes4 is brain dead simple — much simpler than in TP3 where a
> bunch of extra data structures were needed to account for GraphComputer
> semantics (e.g. ExpandableIterator).
> >
> > I believe, given the CPU utilization/etc. points you make, that RxJava
> will come into its own in multi-threaded mode (called ParallelFlowable)
> when trying to get real-time performance from a query that
> touches/generates lots of data (traversers). This is the reason for
> Category 2 — real-time, multi-threaded, single machine. I only gave a quick
> pass last night at making ParallelFlowable work, but gave up when various
> test cases were failing (— I now believe I know the reason why). I hope to
> have ParallelFlowable working by mid-week next week and then we can
> benchmark its performance.
> >
> > I hope I answered your questions or at least explained my confusion.
> >
> > Thanks,
> > Marko.
> >
> > http://rredux.com <http://rredux.com/>
> >
> >
> >
> >
> >> On Apr 4, 2019, at 10:33 AM, Ted Wilmes  twil...@gmail.com>> wrote:
> >>
> >> Hello,
> >>
> >>
> >> --Ted
> >>
> >> On Tue, Apr 2, 2019 at 7:31 AM Marko Rodriguez  <mailto:okramma...@gmail.com>> wrote:
> >>
> >>> Hello,
> >>>
> >>> TP4 will not make a distinction between STANDARD (OLTP) and COMPUTER
> >>> (OLAP) execution models. In TP4, if a processing engine can convert a
> >>> bytecode Compilation into a working execution plan then that is all
> that
> >>> matters. TinkerPop does not need to concern itself with whether that
> >>> execution plan is “OLTP" or “OLAP" or with the semantics of its
> execution
> >>> (function oriented, iterator oriented, RDD-based, etc.). With that,
> here
> >>> are 4 categories of processors that I believe define the full spectrum
> of
> >>> what we will be dealing with:
> >>>
> >>>1. Real-time single-threaded single-machine.
> >>>* This is STANDARD (OLTP) in TP3.
> >>>* This is the Pipes processor in TP4.
> >>>
> >>>2. Real-time multi-threaded single-machine.
> >>>* This does not exist in TP3.
> >>>* We should provide an RxJava processor in TP4.
> >>>
> >>>3. Near-time distributed multi-machine.
> >>>* This does not exist in TP3.
> >>>* We should provide an Akka processor in TP4.
> >>>
> >>>4. Batch-time distributed multi-machine.
> >>>* This is COMPUTER (OLAP) in TP3 (Spark or Giraph).
> >>>* We should provide a Spark processor in TP4.
> >>>
> >>> I’m not familiar with the specifics of the Flink, Apex, DataFlow,
> Samza,
> >>> etc. stream-based processors. However, I believe they can be made to
> work
> >>> in near-time or batch-time depending on the amount of data pulled from
> the
> >>> database. However, once we understand these technologies better, I
> believe
> >>> we should be able to fit them into the categories above.
> >>>
> >>> In conclusion: Do these categories make sense to people?
> Terminology-wise
> >>> -- Near-time? Batch-time? Are these distinctions valid?
> >>>
> >>> Thank you,
> >>> Marko.
> >>>
> >>> http://rredux.com <http://rredux.com/> <http://rredux.com/ <
> http://rredux.com/>>
> >
>
>

Re: A Question Regarding TP4 Processor Classifications

[Ted Wilmes]

Hello,
Excellent progress on the the RxJava processor. I was wondering if
categories 1 and 2 can be combined where Pipes becomes the Flowable version
of the RxJava processor? In this case, though single threaded, we'd still
get the benefit of asynchronous execution of traversal steps versus
blocking execution on thread pools like the current TP3 model. I would
imagine Pipes would beat the Flowable performance on a single traversal
side-by-side basis (thought perhaps not by much), but the Flowable version
would likely scale up to higher throughput and better CPU utilization when
under concurrent load.

--Ted

On Tue, Apr 2, 2019 at 7:31 AM Marko Rodriguez  wrote:

> Hello,
>
> TP4 will not make a distinction between STANDARD (OLTP) and COMPUTER
> (OLAP) execution models. In TP4, if a processing engine can convert a
> bytecode Compilation into a working execution plan then that is all that
> matters. TinkerPop does not need to concern itself with whether that
> execution plan is “OLTP" or “OLAP" or with the semantics of its execution
> (function oriented, iterator oriented, RDD-based, etc.). With that, here
> are 4 categories of processors that I believe define the full spectrum of
> what we will be dealing with:
>
> 1. Real-time single-threaded single-machine.
> * This is STANDARD (OLTP) in TP3.
> * This is the Pipes processor in TP4.
>
> 2. Real-time multi-threaded single-machine.
> * This does not exist in TP3.
> * We should provide an RxJava processor in TP4.
>
> 3. Near-time distributed multi-machine.
> * This does not exist in TP3.
> * We should provide an Akka processor in TP4.
>
> 4. Batch-time distributed multi-machine.
> * This is COMPUTER (OLAP) in TP3 (Spark or Giraph).
> * We should provide a Spark processor in TP4.
>
> I’m not familiar with the specifics of the Flink, Apex, DataFlow, Samza,
> etc. stream-based processors. However, I believe they can be made to work
> in near-time or batch-time depending on the amount of data pulled from the
> database. However, once we understand these technologies better, I believe
> we should be able to fit them into the categories above.
>
> In conclusion: Do these categories make sense to people? Terminology-wise
> -- Near-time? Batch-time? Are these distinctions valid?
>
> Thank you,
> Marko.
>
> http://rredux.com 
>
>
>
>
>

Re: [DISCUSS] Deprecation around Java driver

[Ted Wilmes]

That sounds like a good approach. At this point, would you envision those
being TP specific options or perhaps include include hooks to support
arbitrary provider options?

--Ted

On Wed, Aug 8, 2018 at 1:00 PM Stephen Mallette 
wrote:

> Allow the setting of the scriptEvaluationTimeout per request has been an
> issue for a long time:
>
> https://issues.apache.org/jira/browse/TINKERPOP-1342
>
> I've hesitated a number of times in implementing this as it seemed to mean
> just more overloads around submit() and I didn't really want that. I think
> i'm going to create a new class to hold all the possible parameters called
> RequestOptions so that we basically just end up with:
>
> submit(gremlin)
> submit(gremlin, RequestOptions)
> submit(RequestMessage)
>
> That's really rough and obviously all the async variants would be there as
> well in that pattern, but anyone who follows the driver development should
> follow where I'm going with that. With those signatures we would then
> deprecate the other ones. I see all this change as part of 3.4.0.
>
> Please let me know if there are any concerns with this approach. Thanks!
>

Re: [DISCUSS] Review Process

[Ted Wilmes]

 java-driver
> >>> .net-driver
> >>> reference implementation
> >>> ...
> >>>
> >>> Thanks
> >>> Pieter
> >>>
> >>>
> >>>
> >>>
> >>> Perhaps for version 4 the project should be broken up
> >>>
> >>> On 10/07/2018 22:01, Jason Plurad wrote:
> >>> > Thanks for starting this conversation, Stephen. Lots of interesting
> >>> tidbits
> >>> > here, and perhaps some we can apply to other OSS projects.
> >>> >
> >>> >> I'm not sure if committers/PMC members have just not had time to do
> >>> > reviews or have not felt comfortable doing them
> >>> >
> >>> > Probably a combination of both, especially with the GLVs.
> >>> >
> >>> >> I personally chase votes in the background to get PRs to
> >>> merge.and, I
> >>> > don't want to do that anymore.
> >>> >
> >>> > Amazing that you did that, but I agree that nagging is not a great
> path
> >>> > forward.
> >>> >
> >>> >> it is perfectly fine to review/VOTE in the following manner (as
> >>> examples)
> >>> > It'd be great to have these examples added to the maintainer
> >>> guidelines.
> >>> > When I do code reviews, sometimes I feel like one-liner votes are a
> >>> bit of
> >>> > a cop out, but having examples like this would lower the mental
> hurdle
> >>> to
> >>> > getting started on reviewing.
> >>> >
> >>> >> It would also be nice for non-committers to do reviews - i don't
> know
> >>> how
> >>> > to encourage that behavior though.
> >>> >
> >>> > I agree on this, and it would be particularly important on areas of
> the
> >>> > code where we only have one primary committer, like each GLV. If we
> >>> come to
> >>> > agreement on a new policy, I'd suggest that if we get the docs
> written
> >>> up
> >>> > and published, then we can mention it on gremlin-users sort of as a
> >>> heads
> >>> > up to those interested in getting more involved. Their participation
> >>> helps
> >>> > drive out releases, and new releases attract more users.
> >>> >
> >>> > Regarding the proposal, a single binding +1 from a committer with a 1
> >>> week
> >>> > lazy consensus sounds fine to me. If the contribution is a major
> >>> feature or
> >>> > significant change, the expectation is that the committer realizes
> >>> this and
> >>> > holds it open for 3 votes before committing.
> >>> >
> >>> >
> >>> >
> >>> > On Tue, Jul 10, 2018 at 1:46 PM, Stephen Mallette <
> >>> spmalle...@gmail.com>
> >>> > wrote:
> >>> >
> >>> >> Good point, Ted - that wasn't clear and in truth I didn't think that
> >>> >> through well. I think we could say that that the +1 would come from
> a
> >>> >> committer. If the committer and submitter are one in the same then
> it
> >>> has
> >>> >> its single VOTE and technically, the PR just goes through the week
> >>> long
> >>> >> cooling period and could be merged after that. In the event the PR
> >>> >> submitter is not a committer then they would require at least one
> >>> committer
> >>> >> to be on board with a +1 and a week long wait.
> >>> >>
> >>> >> Ideally, I think we can trust committers enough to do smart things
> >>> with
> >>> >> this change in process. I would hope that a committer who submits a
> >>> PR that
> >>> >> is especially complex and touches scary code parts or breaks
> >>> user/provider
> >>> >> APIs requests an actual review from another committer who might be
> >>> able to
> >>> >> spot some problems even if the 1 week cool down passes by. I don't
> >>> want to
> >>> >> subvert the good things that reviews do, but I don't want them
> >>> holding up
> >>> >> simple code changes either. I'd really like it if we introduced this
> >>> change
> >&

Re: [DISCUSS] Review Process

[Ted Wilmes]

I fell way off the PR review train, I'll get back on. For clarification, is
that a +1 on top of the submitter +1? I'm thinking you
all just meant the submitter's +1 would be adequate after the lazy
consensus period but wanted to be sure. I'd be fine to moving with that. My
impression is that with the folks involved, if a submitter feels that
another set of eyes is really required and lazy consensus is not adequate,
regardless of the policy, that review will be sought and performed prior to
merge.

--Ted

On Tue, Jul 10, 2018 at 11:44 AM Stephen Mallette 
wrote:

> >   It looks like its disabled for this project.
>
> I don't think we can use the GitHub integration without getting off our
> Apache Mirror (which we've discussed, but not really pulled the trigger on
> for no particular reason other than the hassle of changing everything).
>
> >   Does it have to be in that order?
>
> I was thinking that the as long as there is a single +1 at any time in that
> week (or after that week) then it would be good to merge
>
> On Tue, Jul 10, 2018 at 12:36 PM Robert Dale  wrote:
>
> > There might be a better alternative to privately nagging ;-)  Github has
> a
> > feature on the sidebar that can be used to request reviews from
> individuals
> > or groups. The heading has 'Reviewers' and, when it's active, has a gear
> > icon to select people.  Github will then email the reviewers with the
> > request.  It looks like its disabled for this project.
> >
> > I like the idea of adding the option of having a single vote and a week
> to
> > soak.  Does it have to be in that order?  Or can the vote take place any
> > time during that week?  Otherwise, you could end up with no one voting in
> > the first week, get a vote, then waiting another week.
> >
> > Robert Dale
> >
> >
> > On Tue, Jul 10, 2018 at 7:22 AM Jorge Bay Gondra <
> jorgebaygon...@gmail.com
> > >
> > wrote:
> >
> > > I'm +1 on the idea of switching to lazy consensus after a single
> binding
> > > plus one and a week for objection. TinkerPop has so many different
> > modules
> > > / areas and committers have different expertise that is hard to get 3
> > votes
> > > on something.
> > >
> > > Other projects have the concept of main "reviewer" and this would be
> very
> > > similar, a committer that was responsible for reviewing the code and to
> > > check that everything is in order.
> > >
> > > El mar., 10 jul. 2018 a las 13:01, Stephen Mallette (<
> > spmalle...@gmail.com
> > > >)
> > > escribió:
> > >
> > > > I believe that the review process is not working so well anymore. I'm
> > not
> > > > sure if committers/PMC members have just not had time to do reviews
> or
> > > have
> > > > not felt comfortable doing them, but for the most part they aren't
> > > getting
> > > > done and PRs are languishing. Personally, I like our process, but if
> it
> > > > takes 3+ weeks to deal with a PR like this:
> > > >
> > > > https://github.com/apache/tinkerpop/pull/879/files
> > > >
> > > > where all we did was remove deprecated methods, I don't think we're
> > ever
> > > > going to get anything else through. As it stands, I personally chase
> > > votes
> > > > in the background to get PRs to merge.and, I don't want to do
> that
> > > > anymore.
> > > >
> > > > I'll remind committers (and those interested in becoming committers)
> > > that a
> > > > "review" in our context doesn't have to be a full on review of code
> > where
> > > > you hold this deep understanding of everything that is going on. That
> > is
> > > > awesome when that happens, but it is perfectly fine to review/VOTE in
> > the
> > > > following manner (as examples):
> > > >
> > > > + VOTE +1 - ran docker integration tests and everything passes
> > > > + VOTE +1 - reviewed the code in detail - solid pull request
> > > > + VOTE +1 - agree with the principle of this pull request but don't
> > fully
> > > > understand the code
> > > > + VOTE +1 - read through the updated documentation and understand why
> > > this
> > > > is important, nice
> > > >
> > > > So basically, you can VOTE and just explain your position for why you
> > > voted
> > > > (or not explain). I would like to keep this process, however, if we
> > can't
> > > > raise the VOTEs for whatever reason, then I'd like to suggest a
> change.
> > > >
> > > > I'd suggest that we go to a slightly looser version of
> > > review-then-commit,
> > > > where we require the 3  binding +1 VOTEs as we have been doing OR we
> > > > require a single binding +1 and 1 week for objection at which point
> we
> > > have
> > > > a form of lazy consensus.
> > > >
> > > > Honestly, I'd like to see some discussion on this from committers/PMC
> > > > members and not go with the standard form of lazy consensus that we
> > > > typically end up with. However, if no one truly has anything to say,
> > > > consider the 72 hours started now.
> > > >
> > >
> >
>

Re: [DISCUSS] Getting "Practical Gremlin" more visibilty

[Ted Wilmes]

I'll register an official yes, yes, and yes. The docs will continue to
serve as the source of truth and de facto TinkerPop reference. Practical
Gremlin is a particularly good and comprehensive riff on that material that
I think will resonate with many more folks if it is more easily found.
Perhaps when we come up with a logo or placement of that link, we can
notate it in such a manner that it is obviously a third party link.

--Ted

On Fri, Jun 8, 2018 at 2:50 PM, Stephen Mallette 
wrote:

> I'm not sure what we should do about this, but Kelvin's book, Practical
> Gremlin, is really the best thing out there for learning Gremlin. I mean,
> we have lots of good documentation in TinkerPop for sure, but it is written
> as more of a reference than a cohesive resource that you can go to for your
> paced learning. So while we have more than enough documentation for users
> to be able to figure out how to use our stuff, it's not quite the same
> learning experience that Practical Gremlin is.
>
> There's lots of good reason that it is the way it is. I think it's hard to
> keep a cohesive style when lots of different authors contribute to the same
> set of documents. We have also built our documentation in a very piecemeal
> style as the software has evolved and it sorta reads that way. We did do
> some smart things with "tutorials", but we don't have enough of them tying
> together disparate parts of the documentation.Anywaylucky for us,
> Practical Gremlin is doing a great job of filling this gap.
>
> What bothers me however, is that there are still developers who haven't
> heard of the book! The message still isn't getting out there. The obvious
> suggestion, which may have been made before, is that we place a link to the
> book right on the TinkerPop home page. I think that would be a start, but I
> think that perhaps even more visibility might be necessary. Maybe Practical
> Gremlin needs a good logo? Thoughts on what a logo should look like? Maybe
> we put the logo up there on the home page in place of where the "getting
> started" tutorial is? Other ideas?
>
> So the answer to all that might be "yes", "yes" and more "yes", but it is
> important that we also consider that Practical Gremlin is a third-party
> resource and that we would be linking away from the project documentation
> in a reasonably public way. As an Apache project, it is my understanding
> that our site should be the primary source for users to get their
> information on how to use the software. I mostly just want to acknowledge
> that point because as I mentioned earlier, I think TinkerPop has more than
> sufficient reference documentation. It's not as though we link our
> documentation to Practical Gremlin to give readers the source of
> information. It in fact works the other way around - Practical Gremlin
> treats our documentation as the reference (perhaps we could get a few more
> links back to us in there too - hehe). I think that as long as that is
> true, we satisfy our community requirements on documentation. Not sure if
> anyone would argue against that
>
> So, with all that said, any thoughts on what I propose above?
>

[jira] [Closed] (TINKERPOP-1973) Emit predicate ignored after final loop of a RepeatStep with times or until

[Ted Wilmes (JIRA)]

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

Ted Wilmes closed TINKERPOP-1973.
-
Resolution: Won't Fix

Closing as it is the expected behavior. Thanks for the examples [~dkuppitz]

> Emit predicate ignored after final loop of a RepeatStep with times or until
> ---
>
> Key: TINKERPOP-1973
> URL: https://issues.apache.org/jira/browse/TINKERPOP-1973
> Project: TinkerPop
>  Issue Type: Bug
>  Components: process
>Affects Versions: 3.3.3, 3.2.9
>Reporter: Ted Wilmes
>Assignee: Ted Wilmes
>Priority: Major
>
> When combined with a {{times}} or {{until}}, the {{emit}} predicate is not 
> applied to the output of the last loop of the {{RepeatStep}}.
> {code}
>  gremlin> g = TinkerFactory.createModern().traversal()
>  ==>graphtraversalsource[tinkergraph[vertices:6 edges:6], standard]
>  gremlin> g.V().repeat(out()).emit(has('name', 'lop')).values('name')
>  ==>lop
>  ==>lop
>  ==>lop
>  ==>lop
>  gremlin> g.V().repeat(out()).times(2).emit(has('name', 'lop')).values('name')
>  ==>lop
>  ==>ripple
>  ==>lop
>  ==>lop
>  ==>lop
>  gremlin>
> {code}



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

[jira] [Commented] (TINKERPOP-1973) Emit predicate ignored after final loop of a RepeatStep with times or until

[Ted Wilmes (JIRA)]

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

Ted Wilmes commented on TINKERPOP-1973:
---

Ok, that make sense in the context of the injector distinction. So for my 
contrived example, the key would be to include the same predicate after the 
emit. That'll work for most cases I think as long as you aren't relying on the 
loop counter as part of your emit logic since (I think) the loop count is no 
longer available after the traverser has exited the repeat. The reason this 
came up was I was writing a traversal that traversed up a tree from the leaves 
a set number of levels, storing the intermediate results in a subgraph. For a 
smaller subset of those levels, It needed to execute another repeat traversal 
so I was using an {{emit(loops().is(lt(3))).repeat()}}. The issue was that 
repeat was executed for levels less than 3 and then the last level exiting the 
repeat.

 

> Emit predicate ignored after final loop of a RepeatStep with times or until
> ---
>
> Key: TINKERPOP-1973
> URL: https://issues.apache.org/jira/browse/TINKERPOP-1973
> Project: TinkerPop
>  Issue Type: Bug
>  Components: process
>Affects Versions: 3.3.3, 3.2.9
>Reporter: Ted Wilmes
>Assignee: Ted Wilmes
>Priority: Major
>
> When combined with a {{times}} or {{until}}, the {{emit}} predicate is not 
> applied to the output of the last loop of the {{RepeatStep}}.
> {code}
>  gremlin> g = TinkerFactory.createModern().traversal()
>  ==>graphtraversalsource[tinkergraph[vertices:6 edges:6], standard]
>  gremlin> g.V().repeat(out()).emit(has('name', 'lop')).values('name')
>  ==>lop
>  ==>lop
>  ==>lop
>  ==>lop
>  gremlin> g.V().repeat(out()).times(2).emit(has('name', 'lop')).values('name')
>  ==>lop
>  ==>ripple
>  ==>lop
>  ==>lop
>  ==>lop
>  gremlin>
> {code}



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

[jira] [Commented] (TINKERPOP-1973) Emit predicate ignored after final loop of a RepeatStep with times or until

[Ted Wilmes (JIRA)]

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

Ted Wilmes commented on TINKERPOP-1973:
---

[~dkuppitz] this behavior seemed like a bug to me but I wanted to double check 
with you to see if you thought there was a purpose for it.

> Emit predicate ignored after final loop of a RepeatStep with times or until
> ---
>
> Key: TINKERPOP-1973
> URL: https://issues.apache.org/jira/browse/TINKERPOP-1973
> Project: TinkerPop
>  Issue Type: Bug
>  Components: process
>Affects Versions: 3.3.3, 3.2.9
>Reporter: Ted Wilmes
>Assignee: Ted Wilmes
>Priority: Major
>
> When combined with a {{times}} or {{until}}, the {{emit}} predicate is not 
> applied to the output of the last loop of the {{RepeatStep}}.
> {code}
>  gremlin> g = TinkerFactory.createModern().traversal()
>  ==>graphtraversalsource[tinkergraph[vertices:6 edges:6], standard]
>  gremlin> g.V().repeat(out()).emit(has('name', 'lop')).values('name')
>  ==>lop
>  ==>lop
>  ==>lop
>  ==>lop
>  gremlin> g.V().repeat(out()).times(2).emit(has('name', 'lop')).values('name')
>  ==>lop
>  ==>ripple
>  ==>lop
>  ==>lop
>  ==>lop
>  gremlin>
> {code}



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

[jira] [Updated] (TINKERPOP-1973) Emit predicate ignored after final loop of a RepeatStep with times or until

[Ted Wilmes (JIRA)]

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

Ted Wilmes updated TINKERPOP-1973:
--
Description: 
When combined with a {{times}} or {{until}}, the {{emit}} predicate is not 
applied to the output of the last loop of the {{RepeatStep}}.
{code}
 gremlin> g = TinkerFactory.createModern().traversal()
 ==>graphtraversalsource[tinkergraph[vertices:6 edges:6], standard]
 gremlin> g.V().repeat(out()).emit(has('name', 'lop')).values('name')
 ==>lop
 ==>lop
 ==>lop
 ==>lop
 gremlin> g.V().repeat(out()).times(2).emit(has('name', 'lop')).values('name')
 ==>lop
 ==>ripple
 ==>lop
 ==>lop
 ==>lop
 gremlin>
{code}

  was:
When combined with a `times` or `until`, the `emit` predicate is not applied to 
the output of the last loop of the `RepeatStep`.

{code:groovy}
 gremlin> g = TinkerFactory.createModern().traversal()
 ==>graphtraversalsource[tinkergraph[vertices:6 edges:6], standard]
 gremlin> g.V().repeat(out()).emit(has('name', 'lop')).values('name')
 ==>lop
 ==>lop
 ==>lop
 ==>lop
 gremlin> g.V().repeat(out()).times(2).emit(has('name', 'lop')).values('name')
 ==>lop
 ==>ripple
 ==>lop
 ==>lop
 ==>lop
 gremlin>
{code}


> Emit predicate ignored after final loop of a RepeatStep with times or until
> ---
>
> Key: TINKERPOP-1973
>         URL: https://issues.apache.org/jira/browse/TINKERPOP-1973
> Project: TinkerPop
>  Issue Type: Bug
>  Components: process
>Affects Versions: 3.3.3, 3.2.9
>Reporter: Ted Wilmes
>Assignee: Ted Wilmes
>Priority: Major
>
> When combined with a {{times}} or {{until}}, the {{emit}} predicate is not 
> applied to the output of the last loop of the {{RepeatStep}}.
> {code}
>  gremlin> g = TinkerFactory.createModern().traversal()
>  ==>graphtraversalsource[tinkergraph[vertices:6 edges:6], standard]
>  gremlin> g.V().repeat(out()).emit(has('name', 'lop')).values('name')
>  ==>lop
>  ==>lop
>  ==>lop
>  ==>lop
>  gremlin> g.V().repeat(out()).times(2).emit(has('name', 'lop')).values('name')
>  ==>lop
>  ==>ripple
>  ==>lop
>  ==>lop
>  ==>lop
>  gremlin>
> {code}



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

[jira] [Updated] (TINKERPOP-1973) Emit predicate ignored after final loop of a RepeatStep with times or until

[Ted Wilmes (JIRA)]

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

Ted Wilmes updated TINKERPOP-1973:
--
Description: 
When combined with a `times` or `until`, the `emit` predicate is not applied to 
the output of the last loop of the `RepeatStep`.

{code:groovy}
 gremlin> g = TinkerFactory.createModern().traversal()
 ==>graphtraversalsource[tinkergraph[vertices:6 edges:6], standard]
 gremlin> g.V().repeat(out()).emit(has('name', 'lop')).values('name')
 ==>lop
 ==>lop
 ==>lop
 ==>lop
 gremlin> g.V().repeat(out()).times(2).emit(has('name', 'lop')).values('name')
 ==>lop
 ==>ripple
 ==>lop
 ==>lop
 ==>lop
 gremlin>
{code}

  was:
When combined with a `times` or `until`, the `emit` predicate is not applied to 
the output of the last loop of the `RepeatStep`.

```
gremlin> g = TinkerFactory.createModern().traversal()
==>graphtraversalsource[tinkergraph[vertices:6 edges:6], standard]
gremlin> g.V().repeat(out()).emit(has('name', 'lop')).values('name')
==>lop
==>lop
==>lop
==>lop
gremlin> g.V().repeat(out()).times(2).emit(has('name', 'lop')).values('name')
==>lop
==>ripple
==>lop
==>lop
==>lop
gremlin>

```


> Emit predicate ignored after final loop of a RepeatStep with times or until
> ---
>
> Key: TINKERPOP-1973
>         URL: https://issues.apache.org/jira/browse/TINKERPOP-1973
> Project: TinkerPop
>  Issue Type: Bug
>  Components: process
>Affects Versions: 3.3.3, 3.2.9
>Reporter: Ted Wilmes
>Assignee: Ted Wilmes
>Priority: Major
>
> When combined with a `times` or `until`, the `emit` predicate is not applied 
> to the output of the last loop of the `RepeatStep`.
> {code:groovy}
>  gremlin> g = TinkerFactory.createModern().traversal()
>  ==>graphtraversalsource[tinkergraph[vertices:6 edges:6], standard]
>  gremlin> g.V().repeat(out()).emit(has('name', 'lop')).values('name')
>  ==>lop
>  ==>lop
>  ==>lop
>  ==>lop
>  gremlin> g.V().repeat(out()).times(2).emit(has('name', 'lop')).values('name')
>  ==>lop
>  ==>ripple
>  ==>lop
>  ==>lop
>  ==>lop
>  gremlin>
> {code}



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

[jira] [Created] (TINKERPOP-1973) Emit predicate ignored after final loop of a RepeatStep with times or until

[Ted Wilmes (JIRA)]

Ted Wilmes created TINKERPOP-1973:
-

 Summary: Emit predicate ignored after final loop of a RepeatStep 
with times or until
 Key: TINKERPOP-1973
 URL: https://issues.apache.org/jira/browse/TINKERPOP-1973
 Project: TinkerPop
  Issue Type: Bug
  Components: process
Affects Versions: 3.2.9, 3.3.3
Reporter: Ted Wilmes
Assignee: Ted Wilmes


When combined with a `times` or `until`, the `emit` predicate is not applied to 
the output of the last loop of the `RepeatStep`.

```
gremlin> g = TinkerFactory.createModern().traversal()
==>graphtraversalsource[tinkergraph[vertices:6 edges:6], standard]
gremlin> g.V().repeat(out()).emit(has('name', 'lop')).values('name')
==>lop
==>lop
==>lop
==>lop
gremlin> g.V().repeat(out()).times(2).emit(has('name', 'lop')).values('name')
==>lop
==>ripple
==>lop
==>lop
==>lop
gremlin>

```



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

Re: [VOTE] TinkerPop 3.3.3 Release

[Ted Wilmes]

Docs and validate looked good

VOTE +1

Thanks,
Ted

On Wed, May 9, 2018 at 5:38 AM, Robert Dale  wrote:

> VOTE +1
>
> $ bin/validate-distribution.sh 3.3.3
>
> Validating binary distributions
>
> * downloading Apache TinkerPop Gremlin
> (apache-tinkerpop-gremlin-console-3.3.3-bin.zip)... OK
> * validating signatures and checksums ...
>   * PGP signature ... OK
>   * SHA1 checksum ... OK
> * unzipping Apache TinkerPop Gremlin ... OK
> * validating Apache TinkerPop Gremlin's docs ... OK
> * validating Apache TinkerPop Gremlin's binaries ... OK
> * validating Apache TinkerPop Gremlin's legal files ...
>   * LICENSE ... OK
>   * NOTICE ... OK
> * validating Apache TinkerPop Gremlin's plugin directory ... OK
> * validating Apache TinkerPop Gremlin's lib directory ... OK
> * testing script evaluation ... OK
>
> * downloading Apache TinkerPop Gremlin
> (apache-tinkerpop-gremlin-server-3.3.3-bin.zip)... OK
> * validating signatures and checksums ...
>   * PGP signature ... OK
>   * SHA1 checksum ... OK
> * unzipping Apache TinkerPop Gremlin ... OK
> * validating Apache TinkerPop Gremlin's docs ... OK
> * validating Apache TinkerPop Gremlin's binaries ... OK
> * validating Apache TinkerPop Gremlin's legal files ...
>   * LICENSE ... OK
>   * NOTICE ... OK
> * validating Apache TinkerPop Gremlin's plugin directory ... OK
> * validating Apache TinkerPop Gremlin's lib directory ... OK
>
> Validating source distribution
>
> * downloading Apache TinkerPop 3.3.3 (apache-tinkerpop-3.3.3-src.zip)...
> OK
> * validating signatures and checksums ...
>   * PGP signature ... OK
>   * SHA1 checksum ... OK
> * unzipping Apache TinkerPop 3.3.3 ... OK
> * building project ... OK
>
>
> Robert Dale
>
> On Tue, May 8, 2018 at 4:44 PM, Stephen Mallette 
> wrote:
>
> >  Hello,
> >
> > We are happy to announce that TinkerPop 3.3.3 is ready for release.
> >
> > The release artifacts can be found at this location:
> > https://dist.apache.org/repos/dist/dev/tinkerpop/3.3.3/
> > 
> >
> > The source distribution is provided by:
> > apache-tinkerpop-3.3.3-src.zip
> >
> > Two binary distributions are provided for user convenience:
> > apache-tinkerpop-gremlin-console-3.3.3-bin.zip
> > apache-tinkerpop-gremlin-server-3.3.3-bin.zip
> >
> > The GPG key used to sign the release artifacts is available at:
> > https://dist.apache.org/repos/dist/dev/tinkerpop/KEYS
> >
> > The online docs can be found here:
> > http://tinkerpop.apache.org/docs/3.3.3/
> >  (user docs)
> > http://tinkerpop.apache.org/docs/3.3.3/upgrade/
> >  (upgrade docs)
> > http://tinkerpop.apache.org/javadocs/3.3.3/core/
> >  (core javadoc)
> > http://tinkerpop.apache.org/javadocs/3.3.3/full/
> >  (full javadoc)
> >
> > The tag in Apache Git can be found here:
> > *https://git-wip-us.apache.org/repos/asf?p=tinkerpop.git;
> a=tag;h=
> > 696f5e40e5c56c58a4ab703608a790d8130ea640
> >  > 696f5e40e5c56c58a4ab703608a790d8130ea640>*
> >
> > The release notes are available here (i linked to the branch - github
> > hasn't sync'd the tag yet for some reason - not sure what the delay is
> with
> > Apache infra):
> > https://github.com/apache/tinkerpop/blob/tp33/CHANGELOG.
> > asciidoc#release-3-3-
> >  > asciidoc#release-3-3-2>
> > 3
> >
> > The [VOTE] will be open for the next 72 hours --- closing Friday, May 11,
> > 2018 at 5:00pm EST.
> >
> > My vote is +1.
> >
> > Thank you very much,
> > Stephen
> >
>

Re: [VOTE] TinkerPop 3.2.9 Release

[Ted Wilmes]

Docs and validate looked good +1

Thanks,
Ted

On Wed, May 9, 2018 at 6:26 AM, Stephen Mallette 
wrote:

> VOTE +1 - reviewed published docs a bit and validate-distribution.sh is
> good
>
> On Tue, May 8, 2018 at 4:43 PM, Robert Dale  wrote:
>
> > Hello,
> >
> > We are happy to announce that TinkerPop 3.2.9 is ready for release.
> >
> > The release artifacts can be found at this location:
> > https://dist.apache.org/repos/dist/dev/tinkerpop/3.2.9/
> >
> > The source distribution is provided by:
> > apache-tinkerpop-3.2.9-src.zip
> >
> > Two binary distributions are provided for user convenience:
> > apache-tinkerpop-gremlin-console-3.2.9-bin.zip
> > apache-tinkerpop-gremlin-server-3.2.9-bin.zip
> >
> > The GPG key used to sign the release artifacts is available at:
> > https://dist.apache.org/repos/dist/dev/tinkerpop/KEYS
> >
> > The online docs can be found here:
> > http://tinkerpop.apache.org/docs/3.2.9/ (user docs)
> > http://tinkerpop.apache.org/docs/3.2.9/upgrade/ (upgrade docs)
> > http://tinkerpop.apache.org/javadocs/3.2.9/core/ (core javadoc)
> > http://tinkerpop.apache.org/javadocs/3.2.9/full/ (full javadoc)
> >
> > The tag in Apache Git can be found here:
> >
> > https://git-wip-us.apache.org/repos/asf?p=tinkerpop.git;a=tag;h=
> > 721fd3c32d0a02337f156ef8d99e7ffb9f1cdc98
> >
> > The release notes are available here:
> >
> > https://github.com/apache/tinkerpop/blob/3.2.9/
> > CHANGELOG.asciidoc#release-3-2-9
> >
> > The [VOTE] will be open for the next 72 hours --- closing Friday (May 11
> > 2018) at 17:00 EDT.
> >
> > My vote is +1.
> >
> > Thank you very much,
> > Robert Dale
> >
>

Re: [TinkerPop] TinkerPop 3.2.8 Released: Nine Inch Gremlins

[Ted Wilmes]

Good catch, thanks Stephen.

--Ted

On Tue, Apr 10, 2018, 7:56 AM Stephen Mallette  wrote:

> Thanks Ted, just a quick edit though - while gremlin-javascript is
> technically at the url you provided the preferred package is:
>
> https://www.npmjs.com/package/gremlin
>
> On Tue, Apr 10, 2018 at 7:46 AM, Ted Wilmes  wrote:
>
>> Hello,
>>
>> TinkerPop 3.2.8 has just been released. This release marks the first
>> official release of the Gremlin Javascript GLV. The 3.2.8 release also
>> includes a number of other bug fixes and updates. Please refer to the
>> changelog for more details.
>>
>> The release artifacts can be found at this location:
>>
>> https://www.apache.org/dyn/closer.lua/tinkerpop/3.2.8
>> /apache-tinkerpop-gremlin-console-3.2.8-bin.zip
>> https://www.apache.org/dyn/closer.lua/tinkerpop/3.2.8
>> /apache-tinkerpop-gremlin-server-3.2.8-bin.zip
>> https://www.apache.org/dyn/closer.lua/tinkerpop/3.2.8/apache-tinkerpop-
>> 3.2.8-src.zip
>>
>> The online docs can be found here:
>>
>> http://tinkerpop.apache.org/docs/3.2.8/reference/ (user docs)
>> http://tinkerpop.apache.org/docs/3.2.8/upgrade/#_tinkerpop_3_2_8
>> (upgrade docs)
>> http://tinkerpop.apache.org/javadocs/3.2.8/core/ (core javadoc)
>> http://tinkerpop.apache.org/javadocs/3.2.8/full/ (full javadoc)
>>
>> The release notes are available here:
>>
>>
>> https://github.com/apache/tinkerpop/blob/tp32/CHANGELOG.asciidoc#tinkerpop-328-release-date-april-2-2018
>>
>> The Central Maven repo has sync'd as well:
>>
>> https://repo1.maven.org/maven2/org/apache/tinkerpop/tinkerpop/3.2.8/
>>
>> Python artifacts are available in pypi:
>>
>> https://pypi.python.org/pypi/gremlinpython/3.2.8
>>
>> .NET artifacts are available in NuGet:
>>
>> https://www.nuget.org/packages/Gremlin.Net/3.2.8
>>
>> Javascript artifacts are available in NPM:
>>
>> https://www.npmjs.com/package/gremlin-javascript
>>
>>
>>
>> --
>> You received this message because you are subscribed to the Google Groups
>> "Gremlin-users" group.
>> To unsubscribe from this group and stop receiving emails from it, send an
>> email to gremlin-users+unsubscr...@googlegroups.com.
>> To view this discussion on the web visit
>> https://groups.google.com/d/msgid/gremlin-users/CAGrm2%3DCvPY9KKLDCVU_ce15Yw2OhYds%3DDr%3DZ93DGGJR%2BH8f37w%40mail.gmail.com
>> <https://groups.google.com/d/msgid/gremlin-users/CAGrm2%3DCvPY9KKLDCVU_ce15Yw2OhYds%3DDr%3DZ93DGGJR%2BH8f37w%40mail.gmail.com?utm_medium=email&utm_source=footer>
>> .
>> For more options, visit https://groups.google.com/d/optout.
>>
>

TinkerPop 3.2.8 Released: Nine Inch Gremlins

[Ted Wilmes]

Hello,

TinkerPop 3.2.8 has just been released. This release marks the first
official release of the Gremlin Javascript GLV. The 3.2.8 release also
includes a number of other bug fixes and updates. Please refer to the
changelog for more details.

The release artifacts can be found at this location:

https://www.apache.org/dyn/closer.lua/tinkerpop/3.2.8
/apache-tinkerpop-gremlin-console-3.2.8-bin.zip
https://www.apache.org/dyn/closer.lua/tinkerpop/3.2.8
/apache-tinkerpop-gremlin-server-3.2.8-bin.zip
https://www.apache.org/dyn/closer.lua/tinkerpop/3.2.8/apache-tinkerpop-3.2.8
-src.zip

The online docs can be found here:

http://tinkerpop.apache.org/docs/3.2.8/reference/ (user docs)
http://tinkerpop.apache.org/docs/3.2.8/upgrade/#_tinkerpop_3_2_8 (upgrade
docs)
http://tinkerpop.apache.org/javadocs/3.2.8/core/ (core javadoc)
http://tinkerpop.apache.org/javadocs/3.2.8/full/ (full javadoc)

The release notes are available here:

https://github.com/apache/tinkerpop/blob/tp32/CHANGELOG.asciidoc#tinkerpop-328-release-date-april-2-2018

The Central Maven repo has sync'd as well:

https://repo1.maven.org/maven2/org/apache/tinkerpop/tinkerpop/3.2.8/

Python artifacts are available in pypi:

https://pypi.python.org/pypi/gremlinpython/3.2.8

.NET artifacts are available in NuGet:

https://www.nuget.org/packages/Gremlin.Net/3.2.8

Javascript artifacts are available in NPM:

https://www.npmjs.com/package/gremlin-javascript

[RESULT][VOTE] TinkerPop 3.2.8 Release

[Ted Wilmes]

 This vote is now closed with a total of 4 +1s, no +0s and no -1s. The
results are:

BINDING VOTES:

+1  (4 -- Ted Wilmes, Daniel Kuppitz, Stephen Mallette, Jason Plurad)
0   (0)
-1  (0)

NON-BINDING VOTES:

+1 (0)
0  (0)
-1 (0)

Thank you very much,
Ted Wilmes

Re: [VOTE] TinkerPop 3.2.8 Release

[Ted Wilmes]

Thanks for catching that Jorge. I'm okay with the hack. I'll setup an
npms.js and nuget account.

--Ted

On Wed, Apr 4, 2018 at 7:29 AM, Stephen Mallette 
wrote:

> If everyone else is ok with the little hack job to get this first
> deployment out, I think I am.
>
>
> On Wed, Apr 4, 2018 at 7:55 AM, Jorge Bay Gondra  >
> wrote:
>
> > Whatever you feel more comfortable, as the only risk is publishing it
> under
> > the name gremlin-javascript which is going to be deprecated anyways.
> >
> > If you are going to manually execute "npm publish" in your terminal, you
> > have to only change the package name in package.json.
> > If you are planning to use maven with the nodejs plugin to deploy, you
> have
> > to change the groovy template file"glv/PackageJson.template" in order to
> > change the generated "package.json" file.
> >
> > 2018-04-04 12:31 GMT+02:00 Stephen Mallette :
> >
> > > ugh - not to be sloppy but do we need to kill the artifacts we've
> already
> > > built over that? how bad would it be if we simply remembered to make
> that
> > > change at time of deployment? would that cause problems?
> > >
> > > On Wed, Apr 4, 2018 at 5:44 AM, Jorge Bay Gondra <
> > jorgebaygon...@gmail.com
> > > >
> > > wrote:
> > >
> > > > It looks like the JavaScript package still points to
> > > "gremlin-javascript",
> > > > instead of "gremlin"
> > > >
> > > > https://github.com/apache/tinkerpop/blob/3.2.8/gremlin-
> > > > javascript/src/main/javascript/gremlin-javascript/package.json#L2
> > > >
> > > > We should change that on both 3.2 and 3.3 branches.
> > > >
> > > > Also, if you are planning to do the JavaScript and C# GLV releases,
> you
> > > > should create an account on npmjs.com (and be part of the tinkerpop
> > > team)
> > > > and nuget.org (and be given access rights).
> > > >
> > > > Cheers,
> > > > Jorge
> > > >
> > > > 2018-04-03 18:58 GMT+02:00 Stephen Mallette :
> > > >
> > > > > validate-distributions.sh was clean for me. also gave some review
> to
> > > the
> > > > > docs and what i looked at seemed good to go:
> > > > >
> > > > > VOTE +1
> > > > >
> > > > > On Tue, Apr 3, 2018 at 12:05 PM, Daniel Kuppitz 
> > > wrote:
> > > > >
> > > > > > Looks good.
> > > > > >
> > > > > > *Validating binary distributions*
> > > > > >
> > > > > > * downloading Apache TinkerPop Gremlin
> > > > > > (apache-tinkerpop-gremlin-console-3.2.8-bin.zip)... OK
> > > > > > * validating signatures and checksums ...
> > > > > >   * PGP signature ... OK
> > > > > >   * MD5 checksum ... OK
> > > > > >   * SHA1 checksum ... OK
> > > > > > * unzipping Apache TinkerPop Gremlin ... OK
> > > > > > * validating Apache TinkerPop Gremlin's docs ... OK
> > > > > > * validating Apache TinkerPop Gremlin's binaries ... OK
> > > > > > * validating Apache TinkerPop Gremlin's legal files ...
> > > > > >   * LICENSE ... OK
> > > > > >   * NOTICE ... OK
> > > > > > * validating Apache TinkerPop Gremlin's plugin directory ... OK
> > > > > > * validating Apache TinkerPop Gremlin's lib directory ... OK
> > > > > > * testing script evaluation ... OK
> > > > > >
> > > > > > * downloading Apache TinkerPop Gremlin
> > > > > > (apache-tinkerpop-gremlin-server-3.2.8-bin.zip)... OK
> > > > > > * validating signatures and checksums ...
> > > > > >   * PGP signature ... OK
> > > > > >   * MD5 checksum ... OK
> > > > > >   * SHA1 checksum ... OK
> > > > > > * unzipping Apache TinkerPop Gremlin ... OK
> > > > > > * validating Apache TinkerPop Gremlin's docs ... OK
> > > > > > * validating Apache TinkerPop Gremlin's binaries ... OK
> > > > > > * validating Apache TinkerPop Gremlin's legal files ...
> > > > > >   * LICENSE ... OK
> > > > > >   * NOTICE ... OK
> > > > > > * validating Apache TinkerPop Gremlin's plugin directory ... OK
> > &

[VOTE] TinkerPop 3.2.8 Release

[Ted Wilmes]

Hello,

We are happy to announce that TinkerPop 3.2.8 is ready for release.

The release artifacts can be found at this location:
https://dist.apache.org/repos/dist/dev/tinkerpop/3.2.8/

The source distribution is provided by:
apache-tinkerpop-3.2.8-src.zip

Two binary distributions are provided for user convenience:
apache-tinkerpop-gremlin-console-3.2.8-bin.zip
apache-tinkerpop-gremlin-server-3.2.8-bin.zip

The GPG key used to sign the release artifacts is available at:
https://dist.apache.org/repos/dist/dev/tinkerpop/KEYS

The online docs can be found here:
http://tinkerpop.apache.org/docs/3.2.8/ (user docs)
http://tinkerpop.apache.org/docs/3.2.8/upgrade/ (upgrade docs)
http://tinkerpop.apache.org/javadocs/3.2.8/core/ (core javadoc)
http://tinkerpop.apache.org/javadocs/3.2.8/full/ (full javadoc)

The tag in Apache Git can be found here:

https://git-wip-us.apache.org/repos/asf?p=tinkerpop.git;a=tag;h=f76fd68f83b2479e74c00949549a41173d46b71b

The release notes are available here:

https://github.com/apache/tinkerpop/blob/tp32/CHANGELOG.asciidoc#tinkerpop-328-release-date-april-2-2018

The [VOTE] will be open for the next 72 hours --- closing Friday April
6, 2018 at 11:00 AM CDT.

My vote is +1.

Thank you very much,
Ted Wilmes

Re: [DISCUSS] 3.2.8/3.3.2 Release Issues

[Ted Wilmes]

Hi Stephen,
I can take a crack at the 3.2.8 release.

--Ted

On Thu, Mar 22, 2018, 3:43 PM Stephen Mallette  wrote:

> So, TINKERPOP-1865 merged and TINKERPOP-1866 is in PR form awaiting review:
>
> https://github.com/apache/tinkerpop/pull/823
>
> Insanely great work from Florian Hockmann killing all these .NET tickets on
> the way up to release prior to his holiday time - appreciated!
>
> I think we also want to get in Jorge's PR so that we can release properly
> signed .NET assemblies:
>
> https://github.com/apache/tinkerpop/pull/822
>
> Other than, that I think we are setup for code freeze tomorrow and we can
> start focusing on more testing/docs.
>
> Does anyone care to volunteer to take 3.2.8 off my hands? Otherwise, I will
> manage both releases myself.
>
>
>
> On Wed, Mar 21, 2018 at 12:00 PM, Stephen Mallette 
> wrote:
>
> > Just a quick note to mention that we're down to just these two issues in
> > JIRA:
> >
> > https://issues.apache.org/jira/browse/TINKERPOP-1866
> > https://issues.apache.org/jira/browse/TINKERPOP-1865 (has a PR at
> > https://github.com/apache/tinkerpop/pull/820)
> >
> > any others?
> >
> > Looks like we might get this all closed up by code freeze on Friday
> >
> >
> > On Mon, Mar 12, 2018 at 12:11 PM, Stephen Mallette  >
> > wrote:
> >
> >> I just made an update on two issues that I thought needed to be done
> with
> >> gremlin-python for release, specifically:
> >>
> >> https://issues.apache.org/jira/browse/TINKERPOP-1898
> >> https://issues.apache.org/jira/browse/TINKERPOP-1895
> >>
> >> if you're following along, i basically closed 1895 as a duplicate of
> 1898
> >> as the two issues are related - ultimately, the issues is with
> specifying
> >> strategies when a lambda is present. basically, i can't get the test i
> had
> >> validating a fix to pass consistently and I believe that the reason is
> >> related to something that is out of our hands - an issue in jython
> >> processing varargs. Anyway, i don't imagine 1898 will get closed in time
> >> for release, but personally, I don't think this is a massive issue to
> block
> >> us from moving forward. I also think we have a reasonable workaround as
> >> gremlin-python users should be able to submit their lambdas as groovy
> and
> >> get a successful traversal execution.
> >>
> >>
> >>
> >> On Thu, Mar 8, 2018 at 9:42 AM, Florian Hockmann <
> f...@florian-hockmann.de>
> >> wrote:
> >>
> >>> I already started working on TINKERPOP-1901, but some tests failed and
> I
> >>> wanted to use a Docker image of the Gremlin Server for easier debugging
> >>> which is why I created a PR for that first.
> >>> Finishing TINKERPOP-1854 should be really easy once TINKERPOP-1901 is
> >>> done.
> >>>
> >>> Supporting g:T (TINKERPOP-1866) shouldn't require much work. It should
> >>> just need a small deserializer.
> >>>
> >>> But I'm not sure about the test related tickets (TINKERPOP-1865 and
> >>> TINKERPOP-1892). I looked into the failing tests when the new scenarios
> >>> were introduced and they seemed to be caused by bugs / missing
> >>> functionality in the way we create traversals from the Gherkin features
> >>> rather than real bugs in Gremlin.Net.
> >>>
> >>> I also still see the problem of releasing Gremlin.Net from a Unix
> system
> >>> as strong name signing is still not supported. The newest Visual Studio
> >>> version that was released on Monday (15.6) includes the fix, but we
> still
> >>> have to wait for the next release of the dotnet CLI tool. I asked in
> their
> >>> Gitter channel about an estimate but didn't get an answer so far. We
> might
> >>> have to set up a small build job on AppVeyor to build and pack
> Gremlin.Net
> >>> so that the release manager can download the NuGet packages from there
> and
> >>> then only has to push them. I can't handle the NuGet packaging this
> time as
> >>> I'm on vacation in the second half of March and first week of April.
> >>>
> >>> Do we have to set the release date in stone now or could we just see
> >>> where we are at the end of next week and then decide whether we stay
> with
> >>> the release date in the first week of April or whether we need more
> time?
> >>>
> >>> -Ursprüngliche Nachricht-
> >>> Von: Jorge Bay Gondra 
> >>> Gesendet: Donnerstag, 8. März 2018 09:26
> >>> An: dev@tinkerpop.apache.org
> >>> Betreff: Re: [DISCUSS] 3.2.8/3.3.2 Release Issues
> >>>
> >>> Lambdas in .NET is blocked by TINKERPOP-1901, I've updated JIRA to
> >>> reflect that.
> >>>
> >>> I don't know if we can make it with the current scope in that timeline.
> >>> I have very little / no time available for the .NET GLV issues until
> the
> >>> end of next week...
> >>>
> >>> On Wed, Mar 7, 2018 at 9:35 PM, Stephen Mallette  >
> >>> wrote:
> >>>
> >>> > In a previous thread we had the idea that we would look to release
> >>> > 3.2.8/3.3.2 around the first week of April which means that we will
> >>> > likely code freeze in about 10 days to focus on review/test/docs. I
> >>> > think that we want

[jira] [Assigned] (TINKERPOP-1925) Don't apply PathRetractionStrategy recursively

[Ted Wilmes (JIRA)]

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

Ted Wilmes reassigned TINKERPOP-1925:
-

Assignee: Ted Wilmes

> Don't apply PathRetractionStrategy recursively
> --
>
> Key: TINKERPOP-1925
> URL: https://issues.apache.org/jira/browse/TINKERPOP-1925
> Project: TinkerPop
>  Issue Type: Improvement
>  Components: process
>Affects Versions: 3.2.7
>Reporter: Daniel Kuppitz
>Assignee: Ted Wilmes
>Priority: Major
>
> {{PathRetractionStrategy}} should not be applied recursively, if possible. 
> This is considered an anti-pattern and just recently it caused a lot of 
> trouble. This commit fixed the recent issue:
> https://github.com/apache/tinkerpop/commit/b8eb8a02f1675a1b22b86ccc54d22453c65f406f
> {{PathRetractionStrategy}} collects requirements of child traversals, before 
> other strategies have a chance to mutate them. When other strategies get to 
> the child traversals, mutate them and thus add or remove requirements, a few 
> things can go crazy, especially because traverser requirements get cached 
> when they're first requested.
> Since I do not fully understand the {{PathRetractionStrategy}} code, my fix 
> was actually a workaround. As you can see in the commit linked above, I 
> implemented the same anti-pattern in {{SubgraphStrategy}} and 
> {{IncidentToAdjacentStrategy}}; these are the 2 strategies that can 
> potentially change the traverser requirements.
> It would be nice to revert these changes and instead make 
> {{PathRetractionStrategy}} work like all others. However, I'm not sure if 
> that's even possible.



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

Re: [DISCUSS] Drop support for Giraph in 3.4.0

[Ted Wilmes]

I agree, I think it's a good idea to remove it. I haven't ever run into
anyone using the GiraphGraphComputer.

--Ted

On Wed, Mar 14, 2018 at 3:03 AM, Jorge Bay Gondra 
wrote:

> I'm +1 on removing support for Giraph.
>
> We should try to simplify the build as much as possible and this
> integration doesn't seem to be very useful or in demand, specially with
> gremlin OLAP.
>
> On Tue, Mar 13, 2018 at 7:34 PM, Stephen Mallette 
> wrote:
>
> > A week or so ago I decided to try to figure out what was going on with
> the
> > Giraph upgrade - some of you may recall that we backed off doing that
> > upgrade for 3.3.0 at the last minute because it was hanging up Hadoop.
> > After messing with it for a bit, I started to wonder why this work was
> > necessary at all. Why not just suggest to the community that we drop
> > support for Giraph in 3.4.0?
> >
> > Some reasoning:
> >
> > 1. This weird Hadoop hanging problem is preventing upgrade. I suppose I
> > could try to figure it out, but Marko already tried and didn't succeed,
> so
> > I'm not sure what new insight I would bring since he was the expert.
> > 2. It massively slows our integration tests. we could be many times more
> > productive without giraph in the build.
> > 3. The Giraph community seems dormant (not one post on user mailing list
> > since November 2017 and very little happening on dev though i just
> learned
> > they have an LGPL dependency in their stuff while looking at recent
> posts -
> > no one has jumped on it to address it - the PR from community is still
> open
> > https://github.com/apache/giraph/pull/61 and over 2 weeks old). It just
> > doesn't seem like anyone is really maintaining or advancing the project.
> > 4. I could be wrong, but I sense that most organizations are using
> > gremlin-spark to do their work and giraph is largely unused.
> >
> > Anyway, it would be good to hear any feedback on this fairly major
> > decision. If there are no objections here on the dev list, I will take
> this
> > discussion to the user list and twitter to see if what the user community
> > thinks.
> >
> > Thanks,
> >
> > stephen
> >
>

Re: [TinkerPop] Re: New Committer: Kelvin Lawrence

[Ted Wilmes]

Great news! Welcome Kelvin and thanks so much for all the work you've done.

--Ted

On Wed, Jan 3, 2018 at 9:08 AM, Jorge Bay Gondra 
wrote:

> Welcome Kevin!!!
>
> On Wed, Jan 3, 2018 at 3:55 PM, Jason Plurad  wrote:
>
> > Congrats, Kelvin!
> >
> > On Wednesday, January 3, 2018 at 9:49:57 AM UTC-5, Stephen Mallette
> wrote:
> >>
> >> The Project Management Committee (PMC) for Apache TinkerPop has asked
> >> Kelvin Lawrence to become a committer and we are pleased to announce his
> >> acceptance.
> >>
> >> Kelvin has led the authoring of a crucial piece of  Gremlin literature
> in
> >> "Graph Databases, Gremlin and TinkerPop":
> >>
> >> http://kelvinlawrence.net/book/Gremlin-Graph-Guide.html
> >>
> >> It is a wonderful guide for Gremlin users of virtually all levels of
> >> experience. Kelvin is also helpful on the user mailing list where he
> steps
> >> in to provide answers on Gremlin questions.
> >>
> >> Welcome to TinkerPop committership, Kelvin and thank you for your
> efforts!
> >>
> >> --
> > You received this message because you are subscribed to the Google Groups
> > "Gremlin-users" group.
> > To unsubscribe from this group and stop receiving emails from it, send an
> > email to gremlin-users+unsubscr...@googlegroups.com.
> > To view this discussion on the web visit https://groups.google.com/d/
> > msgid/gremlin-users/c5e67c1f-fbed-4f9a-86db-85ab24403b4b%
> > 40googlegroups.com
> >  fbed-4f9a-86db-85ab24403b4b%40googlegroups.com?utm_medium=
> email&utm_source=footer>
> > .
> >
> > For more options, visit https://groups.google.com/d/optout.
> >
>

Re: [VOTE] TinkerPop 3.2.7 Release

[Ted Wilmes]

VOTE: +1

Thanks,
Ted

On Mon, Dec 18, 2017 at 2:15 PM, Daniel Kuppitz  wrote:

> /projects/apache/tinkerpop (tp32) $ bin/validate-distribution.sh 3.2.7
>
> Validating binary distributions
>
> * downloading Apache TinkerPop Gremlin
> (apache-tinkerpop-gremlin-console-3.2.7-bin.zip)... OK
> * validating signatures and checksums ...
>   * PGP signature ... OK
>   * MD5 checksum ... OK
>   * SHA1 checksum ... OK
> * unzipping Apache TinkerPop Gremlin ... OK
> * validating Apache TinkerPop Gremlin's docs ... OK
> * validating Apache TinkerPop Gremlin's binaries ... OK
> * validating Apache TinkerPop Gremlin's legal files ...
>   * LICENSE ... OK
>   * NOTICE ... OK
> * validating Apache TinkerPop Gremlin's plugin directory ... OK
> * validating Apache TinkerPop Gremlin's lib directory ... OK
> * testing script evaluation ... OK
>
> * downloading Apache TinkerPop Gremlin
> (apache-tinkerpop-gremlin-server-3.2.7-bin.zip)... OK
> * validating signatures and checksums ...
>   * PGP signature ... OK
>   * MD5 checksum ... OK
>   * SHA1 checksum ... OK
> * unzipping Apache TinkerPop Gremlin ... OK
> * validating Apache TinkerPop Gremlin's docs ... OK
> * validating Apache TinkerPop Gremlin's binaries ... OK
> * validating Apache TinkerPop Gremlin's legal files ...
>   * LICENSE ... OK
>   * NOTICE ... OK
> * validating Apache TinkerPop Gremlin's plugin directory ... OK
> * validating Apache TinkerPop Gremlin's lib directory ... OK
>
> Validating source distribution
>
> * downloading Apache TinkerPop 3.2.7 (apache-tinkerpop-3.2.7-src.zip)...
> OK
> * validating signatures and checksums ...
>   * PGP signature ... OK
>   * MD5 checksum ... OK
>   * SHA1 checksum ... OK
> * unzipping Apache TinkerPop 3.2.7 ... OK
> * building project ... OK
>
>
> VOTE: +1
>
>
> On Sun, Dec 17, 2017 at 6:22 AM, Stephen Mallette 
> wrote:
>
> > Hello,
> >
> > We are happy to announce that TinkerPop 3.2.7  is ready for release.
> >
> > The release artifacts can be found at this location:
> > https://dist.apache.org/repos/dist/dev/tinkerpop/3.2.7/
> >
> > The source distribution is provided by:
> > apache-tinkerpop-3.2.7-src.zip
> >
> > Two binary distributions are provided for user convenience:
> > apache-tinkerpop-gremlin-console-3.2.7-bin.zip
> > apache-tinkerpop-gremlin-server-3.2.7-bin.zip
> >
> > The GPG key used to sign the release artifacts is available at:
> > https://dist.apache.org/repos/dist/dev/tinkerpop/KEYS
> >
> > The online docs can be found here:
> > http://tinkerpop.apache.org/docs/3.2.7/ (user docs)
> > http://tinkerpop.apache.org/docs/3.2.7/upgrade/ (upgrade docs)
> > http://tinkerpop.apache.org/javadocs/3.2.7/core/ (core javadoc)
> > http://tinkerpop.apache.org/javadocs/3.2.7/full/ (full javadoc)
> >
> > The tag in Apache Git can be found here:
> >
> > https://git-wip-us.apache.org/repos/asf?p=tinkerpop.git;a=tag;h=
> > 540bf5c9a52f33a9448899091e11b9ce5be2792b
> >
> > The release notes are available here:
> >
> > https://github.com/apache/tinkerpop/blob/tp32/CHANGELOG.
> > asciidoc#tinkerpop-327-release-date-december-17-2017
> >
> > The [VOTE] will be open for the next 72 hours --- closing Wednesday,
> > December 20, 2017, at 8:30am EST.
> >
> > My vote is +1.
> >
> > Thank you very much,
> > Stephen
> >
>

Re: [VOTE] TinkerPop 3.3.1 Release

[Ted Wilmes]

Docs and binaries look good, thanks for heading this up Stephen.

VOTE: +1

Thanks,
Ted

On Tue, Dec 19, 2017 at 2:30 AM, pieter gmail 
wrote:

> Hi,
>
> Tested Sqlg on 3.3.1.
>
> Custom, structured and process tests all pass.
>
> VOTE +1
>
> Cheers
> Pieter
>
>
> On 17/12/2017 18:54, Stephen Mallette wrote:
>
>> Hello,
>>
>> We are happy to announce that TinkerPop 3.3.1 is ready for release.
>>
>> The release artifacts can be found at this location:
>>  https://dist.apache.org/repos/dist/dev/tinkerpop/3.3.1/
>>
>> The source distribution is provided by:
>>  apache-tinkerpop-3.3.1-src.zip
>>
>> Two binary distributions are provided for user convenience:
>>  apache-tinkerpop-gremlin-console-3.3.1-bin.zip
>>  apache-tinkerpop-gremlin-server-3.3.1-bin.zip
>>
>> The GPG key used to sign the release artifacts is available at:
>>  https://dist.apache.org/repos/dist/dev/tinkerpop/KEYS
>>
>> The online docs can be found here:
>>  http://tinkerpop.apache.org/docs/3.3.1/ (user docs)
>>  http://tinkerpop.apache.org/docs/3.3.1/upgrade/ (upgrade docs)
>>  http://tinkerpop.apache.org/javadocs/3.3.1/core/ (core javadoc)
>>  http://tinkerpop.apache.org/javadocs/3.3.1/full/ (full javadoc)
>>
>> The tag in Apache Git can be found here:
>>
>> https://git-wip-us.apache.org/repos/asf?p=tinkerpop.git;a=ta
>> g;h=48c762d3e6fd6dda95b806a0eb1126989f7569ee
>>
>> The release notes are available here:
>>
>> https://github.com/apache/tinkerpop/blob/3.3.1/CHANGELOG.
>> asciidoc#tinkerpop-331-release-date-december-17-2017
>>
>> The [VOTE] will be open for the next 72 hours --- closing Wednesday,
>> December 20, 2017, at 12:00pm EST.
>>
>> My vote is +1.
>>
>> Thank you very much,
>> Stephen
>>
>>
>

[jira] [Created] (TINKERPOP-1810) Add Lambda.binaryOperator and Lambda.unaryOperator

[Ted Wilmes (JIRA)]

Ted Wilmes created TINKERPOP-1810:
-

 Summary: Add Lambda.binaryOperator and Lambda.unaryOperator
 Key: TINKERPOP-1810
 URL: https://issues.apache.org/jira/browse/TINKERPOP-1810
 Project: TinkerPop
  Issue Type: Improvement
  Components: process
Affects Versions: 3.2.6
Reporter: Ted Wilmes


While working with sack and lambdas, I found that I could not specify a split 
({{UnaryOperator}}) or merge ({{BinaryOperator}}) operator remotely using the 
{{Lambda}} class helper methods. The sack supplier worked without issue because 
we already have {{Lambda.supplier}}. I propose we add {{Lambda.unaryOperator}} 
and {{Lambda.binaryOperator}}.



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

[jira] [Resolved] (TINKERPOP-1650) PathRetractionStrategy makes Match steps unsolvable

[Ted Wilmes (JIRA)]

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

Ted Wilmes resolved TINKERPOP-1650.
---
   Resolution: Fixed
Fix Version/s: 3.3.1

> PathRetractionStrategy makes Match steps unsolvable
> ---
>
> Key: TINKERPOP-1650
> URL: https://issues.apache.org/jira/browse/TINKERPOP-1650
> Project: TinkerPop
>  Issue Type: Bug
>  Components: process
>Affects Versions: 3.2.3, 3.2.4
>Reporter: Branden Moore
>Assignee: Ted Wilmes
> Fix For: 3.2.7, 3.3.1
>
>
> The `PathRetractionStrategy` can make certain Match() steps "Unsolvable".
> This (nonsensical) example demonstrates the issue:
> {code}
> gremlin> g = graph.traversal()
> ==>graphtraversalsource[tinkergraph[vertices:6 edges:6], standard]
> gremlin> 
> g.V().hasLabel("person").as("perp").match(__.as("a").out("created").as("sw"), 
> __.as("sw").has("lang", "java").as("java")).where("sw", 
> neq("a")).select("perp")
> The provided match pattern is unsolvable: [[MatchStartStep(a), 
> VertexStep(OUT,[created],vertex), MatchEndStep(sw)], [MatchStartStep(sw), 
> HasStep([lang.eq(java)]), MatchEndStep(java)], [MatchStartStep(sw), 
> WherePredicateStep(neq(a)), MatchEndStep]]
> Type ':help' or ':h' for help.
> Display stack trace? [yN]n
> gremlin> 
> {code}
> If we remove the `PathRetractionStrategy`, or use `g.withPath()` the match 
> step is solvable, and works fine.
> {code}
> g.withoutStrategies(PathRetractionStrategy).V().hasLabel("person").as("perp").match(__.as("a").out("created").as("sw"),
>  __.as("sw").has("lang", "java").as("java")).where("sw", 
> neq("a")).select("perp")
> ==>v[1]
> ==>v[4]
> ==>v[4]
> ==>v[6]
> gremlin> 
> g.withPath().V().hasLabel("person").as("perp").match(__.as("a").out("created").as("sw"),
>  __.as("sw").has("lang", "java").as("java")).where("sw", 
> neq("a")).select("perp")
> ==>v[1]
> ==>v[4]
> ==>v[4]
> ==>v[6]
> gremlin> 
> {code}



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

[jira] [Closed] (TINKERPOP-1650) PathRetractionStrategy makes Match steps unsolvable

[Ted Wilmes (JIRA)]

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

Ted Wilmes closed TINKERPOP-1650.
-

> PathRetractionStrategy makes Match steps unsolvable
> ---
>
> Key: TINKERPOP-1650
> URL: https://issues.apache.org/jira/browse/TINKERPOP-1650
> Project: TinkerPop
>  Issue Type: Bug
>  Components: process
>Affects Versions: 3.2.3, 3.2.4
>Reporter: Branden Moore
>Assignee: Ted Wilmes
> Fix For: 3.2.7, 3.3.1
>
>
> The `PathRetractionStrategy` can make certain Match() steps "Unsolvable".
> This (nonsensical) example demonstrates the issue:
> {code}
> gremlin> g = graph.traversal()
> ==>graphtraversalsource[tinkergraph[vertices:6 edges:6], standard]
> gremlin> 
> g.V().hasLabel("person").as("perp").match(__.as("a").out("created").as("sw"), 
> __.as("sw").has("lang", "java").as("java")).where("sw", 
> neq("a")).select("perp")
> The provided match pattern is unsolvable: [[MatchStartStep(a), 
> VertexStep(OUT,[created],vertex), MatchEndStep(sw)], [MatchStartStep(sw), 
> HasStep([lang.eq(java)]), MatchEndStep(java)], [MatchStartStep(sw), 
> WherePredicateStep(neq(a)), MatchEndStep]]
> Type ':help' or ':h' for help.
> Display stack trace? [yN]n
> gremlin> 
> {code}
> If we remove the `PathRetractionStrategy`, or use `g.withPath()` the match 
> step is solvable, and works fine.
> {code}
> g.withoutStrategies(PathRetractionStrategy).V().hasLabel("person").as("perp").match(__.as("a").out("created").as("sw"),
>  __.as("sw").has("lang", "java").as("java")).where("sw", 
> neq("a")).select("perp")
> ==>v[1]
> ==>v[4]
> ==>v[4]
> ==>v[6]
> gremlin> 
> g.withPath().V().hasLabel("person").as("perp").match(__.as("a").out("created").as("sw"),
>  __.as("sw").has("lang", "java").as("java")).where("sw", 
> neq("a")).select("perp")
> ==>v[1]
> ==>v[4]
> ==>v[4]
> ==>v[6]
> gremlin> 
> {code}



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

[jira] [Reopened] (TINKERPOP-1650) PathRetractionStrategy makes Match steps unsolvable

[Ted Wilmes (JIRA)]

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

Ted Wilmes reopened TINKERPOP-1650:
---

> PathRetractionStrategy makes Match steps unsolvable
> ---
>
> Key: TINKERPOP-1650
> URL: https://issues.apache.org/jira/browse/TINKERPOP-1650
> Project: TinkerPop
>  Issue Type: Bug
>  Components: process
>Affects Versions: 3.2.3, 3.2.4
>Reporter: Branden Moore
>Assignee: Ted Wilmes
> Fix For: 3.2.7, 3.3.1
>
>
> The `PathRetractionStrategy` can make certain Match() steps "Unsolvable".
> This (nonsensical) example demonstrates the issue:
> {code}
> gremlin> g = graph.traversal()
> ==>graphtraversalsource[tinkergraph[vertices:6 edges:6], standard]
> gremlin> 
> g.V().hasLabel("person").as("perp").match(__.as("a").out("created").as("sw"), 
> __.as("sw").has("lang", "java").as("java")).where("sw", 
> neq("a")).select("perp")
> The provided match pattern is unsolvable: [[MatchStartStep(a), 
> VertexStep(OUT,[created],vertex), MatchEndStep(sw)], [MatchStartStep(sw), 
> HasStep([lang.eq(java)]), MatchEndStep(java)], [MatchStartStep(sw), 
> WherePredicateStep(neq(a)), MatchEndStep]]
> Type ':help' or ':h' for help.
> Display stack trace? [yN]n
> gremlin> 
> {code}
> If we remove the `PathRetractionStrategy`, or use `g.withPath()` the match 
> step is solvable, and works fine.
> {code}
> g.withoutStrategies(PathRetractionStrategy).V().hasLabel("person").as("perp").match(__.as("a").out("created").as("sw"),
>  __.as("sw").has("lang", "java").as("java")).where("sw", 
> neq("a")).select("perp")
> ==>v[1]
> ==>v[4]
> ==>v[4]
> ==>v[6]
> gremlin> 
> g.withPath().V().hasLabel("person").as("perp").match(__.as("a").out("created").as("sw"),
>  __.as("sw").has("lang", "java").as("java")).where("sw", 
> neq("a")).select("perp")
> ==>v[1]
> ==>v[4]
> ==>v[4]
> ==>v[6]
> gremlin> 
> {code}



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

[jira] [Closed] (TINKERPOP-1650) PathRetractionStrategy makes Match steps unsolvable

[Ted Wilmes (JIRA)]

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

Ted Wilmes closed TINKERPOP-1650.
-

> PathRetractionStrategy makes Match steps unsolvable
> ---
>
> Key: TINKERPOP-1650
> URL: https://issues.apache.org/jira/browse/TINKERPOP-1650
> Project: TinkerPop
>  Issue Type: Bug
>  Components: process
>Affects Versions: 3.2.3, 3.2.4
>Reporter: Branden Moore
>Assignee: Ted Wilmes
> Fix For: 3.2.7
>
>
> The `PathRetractionStrategy` can make certain Match() steps "Unsolvable".
> This (nonsensical) example demonstrates the issue:
> {code}
> gremlin> g = graph.traversal()
> ==>graphtraversalsource[tinkergraph[vertices:6 edges:6], standard]
> gremlin> 
> g.V().hasLabel("person").as("perp").match(__.as("a").out("created").as("sw"), 
> __.as("sw").has("lang", "java").as("java")).where("sw", 
> neq("a")).select("perp")
> The provided match pattern is unsolvable: [[MatchStartStep(a), 
> VertexStep(OUT,[created],vertex), MatchEndStep(sw)], [MatchStartStep(sw), 
> HasStep([lang.eq(java)]), MatchEndStep(java)], [MatchStartStep(sw), 
> WherePredicateStep(neq(a)), MatchEndStep]]
> Type ':help' or ':h' for help.
> Display stack trace? [yN]n
> gremlin> 
> {code}
> If we remove the `PathRetractionStrategy`, or use `g.withPath()` the match 
> step is solvable, and works fine.
> {code}
> g.withoutStrategies(PathRetractionStrategy).V().hasLabel("person").as("perp").match(__.as("a").out("created").as("sw"),
>  __.as("sw").has("lang", "java").as("java")).where("sw", 
> neq("a")).select("perp")
> ==>v[1]
> ==>v[4]
> ==>v[4]
> ==>v[6]
> gremlin> 
> g.withPath().V().hasLabel("person").as("perp").match(__.as("a").out("created").as("sw"),
>  __.as("sw").has("lang", "java").as("java")).where("sw", 
> neq("a")).select("perp")
> ==>v[1]
> ==>v[4]
> ==>v[4]
> ==>v[6]
> gremlin> 
> {code}



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

[jira] [Resolved] (TINKERPOP-1650) PathRetractionStrategy makes Match steps unsolvable

[Ted Wilmes (JIRA)]

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

Ted Wilmes resolved TINKERPOP-1650.
---
   Resolution: Fixed
Fix Version/s: 3.2.7

> PathRetractionStrategy makes Match steps unsolvable
> ---
>
> Key: TINKERPOP-1650
> URL: https://issues.apache.org/jira/browse/TINKERPOP-1650
> Project: TinkerPop
>  Issue Type: Bug
>  Components: process
>Affects Versions: 3.2.3, 3.2.4
>Reporter: Branden Moore
>Assignee: Ted Wilmes
> Fix For: 3.2.7
>
>
> The `PathRetractionStrategy` can make certain Match() steps "Unsolvable".
> This (nonsensical) example demonstrates the issue:
> {code}
> gremlin> g = graph.traversal()
> ==>graphtraversalsource[tinkergraph[vertices:6 edges:6], standard]
> gremlin> 
> g.V().hasLabel("person").as("perp").match(__.as("a").out("created").as("sw"), 
> __.as("sw").has("lang", "java").as("java")).where("sw", 
> neq("a")).select("perp")
> The provided match pattern is unsolvable: [[MatchStartStep(a), 
> VertexStep(OUT,[created],vertex), MatchEndStep(sw)], [MatchStartStep(sw), 
> HasStep([lang.eq(java)]), MatchEndStep(java)], [MatchStartStep(sw), 
> WherePredicateStep(neq(a)), MatchEndStep]]
> Type ':help' or ':h' for help.
> Display stack trace? [yN]n
> gremlin> 
> {code}
> If we remove the `PathRetractionStrategy`, or use `g.withPath()` the match 
> step is solvable, and works fine.
> {code}
> g.withoutStrategies(PathRetractionStrategy).V().hasLabel("person").as("perp").match(__.as("a").out("created").as("sw"),
>  __.as("sw").has("lang", "java").as("java")).where("sw", 
> neq("a")).select("perp")
> ==>v[1]
> ==>v[4]
> ==>v[4]
> ==>v[6]
> gremlin> 
> g.withPath().V().hasLabel("person").as("perp").match(__.as("a").out("created").as("sw"),
>  __.as("sw").has("lang", "java").as("java")).where("sw", 
> neq("a")).select("perp")
> ==>v[1]
> ==>v[4]
> ==>v[4]
> ==>v[6]
> gremlin> 
> {code}



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

Re: TinkerPop Tutorial

[Ted Wilmes]

Wow, very impressive. Definitely should be on the list. Adding this to me
reading list.

--Ted

On Fri, Oct 6, 2017 at 9:59 AM, Marko Rodriguez 
wrote:

> Hello,
>
> Kevin Lawrence posted this Gremlin tutorial on GitHub.
>
> https://github.com/krlawrence/graph  krlawrence/graph>
>
> I think we should add it to our webpage listing.
>
> Wow, just look at this!
>
> http://kelvinlawrence.net/book/Gremlin-Graph-Guide.html <
> http://kelvinlawrence.net/book/Gremlin-Graph-Guide.html>
>
> Marko.
>
> http://markorodriguez.com
>
>
>
>

[jira] [Created] (TINKERPOP-1781) Traversal admin addStep does not update bytecode

[Ted Wilmes (JIRA)]

Ted Wilmes created TINKERPOP-1781:
-

 Summary: Traversal admin addStep does not update bytecode
 Key: TINKERPOP-1781
 URL: https://issues.apache.org/jira/browse/TINKERPOP-1781
 Project: TinkerPop
  Issue Type: Improvement
  Components: process
Affects Versions: 3.2.6, 3.3.0
Reporter: Ted Wilmes


Right now bytecode is constructed at traversal construction time and is not 
updated post-construction when traversal rewriting happens via strategies. This 
works fine in most cases because the traversal is locked post-strategy 
application and will be executed, not serialized out for execution somewhere 
else. 

There are issues when trying to apply client side, pre-serialization traversal 
rewriting (a kind of client-side traversal strategy outside of the usual 
strategy flow). Since a direct call to {{addStep}} circumvents the bytecode 
construction, the bytecode diverges from the rewritten traversal.

{code}
gremlin> traversal = g.V().out();null
==>null
gremlin> traversal.getSteps()
==>GraphStep(vertex,[])
==>VertexStep(OUT,vertex)
gremlin> traversal.getBytecode()
==>[[], [V(), out()]]
gremlin> TraversalHelper.insertAfterStep(new CountGlobalStep(traversal), 
traversal.getSteps()[1], traversal.asAdmin())
==>null
gremlin> traversal.getSteps()
==>GraphStep(vertex,[])
==>VertexStep(OUT,vertex)
==>CountGlobalStep
gremlin> traversal.getBytecode()
==>[[], [V(), out()]]
{code}



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

[jira] [Closed] (TINKERPOP-1287) StarGraph has an overdose of Stream usage.

[Ted Wilmes (JIRA)]

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

Ted Wilmes closed TINKERPOP-1287.
-
Resolution: Not A Problem

Profiling did not show stream usage making a significant impact on performance 
in this case. The use of `intern` mentioned in the comments was taken care of 
by TINKERPOP-1680.

> StarGraph has an overdose of Stream usage.
> --
>
> Key: TINKERPOP-1287
> URL: https://issues.apache.org/jira/browse/TINKERPOP-1287
> Project: TinkerPop
>  Issue Type: Improvement
>  Components: hadoop, structure
>Affects Versions: 3.2.0-incubating, 3.1.2-incubating
>Reporter: Marko A. Rodriguez
>Assignee: Ted Wilmes
> Fix For: 3.2.7
>
> Attachments: g.V.out.out.count.svg, stage0.svg, stage1.svg, stage2.svg
>
>
> {{StarGraph}} is loaded with {{Stream}}-usage. Gutting streams from 
> TinkerGraph made it much faster. It would be good if we did the same thing 
> for {{StarGraph}}.
> This can go into tp31/ and upmerge to master/.



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

[jira] [Commented] (TINKERPOP-1287) StarGraph has an overdose of Stream usage.

[Ted Wilmes (JIRA)]

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

Ted Wilmes commented on TINKERPOP-1287:
---

Not at this point [~spmallette], especially since the {{intern}} was taken care 
of. I'll go ahead and close it.

> StarGraph has an overdose of Stream usage.
> --
>
> Key: TINKERPOP-1287
> URL: https://issues.apache.org/jira/browse/TINKERPOP-1287
> Project: TinkerPop
>  Issue Type: Improvement
>  Components: hadoop, structure
>Affects Versions: 3.2.0-incubating, 3.1.2-incubating
>Reporter: Marko A. Rodriguez
>Assignee: Ted Wilmes
> Fix For: 3.2.7
>
> Attachments: g.V.out.out.count.svg, stage0.svg, stage1.svg, stage2.svg
>
>
> {{StarGraph}} is loaded with {{Stream}}-usage. Gutting streams from 
> TinkerGraph made it much faster. It would be good if we did the same thing 
> for {{StarGraph}}.
> This can go into tp31/ and upmerge to master/.



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

TinkerPop 3.1.8 Released: A 187 On The Undercover Gremlinz

[Ted Wilmes]

Hello,

TinkerPop 3.1.8 has just been released. This maintenance release contains a
number of bug fixes on the "Undercover Gremlinz" release line and should be
non-breaking for your upgrade needs.

The release artifacts can be found at this location:

https://www.apache.org/dyn/closer.lua/tinkerpop/3.1.8/
apache-tinkerpop-gremlin-console-3.1.8-bin.zip
https://www.apache.org/dyn/closer.lua/tinkerpop/3.1.8/
apache-tinkerpop-gremlin-server-3.1.8-bin.zip

The online docs can be found here:

http://tinkerpop.apache.org/docs/3.1.8/reference/ (user docs)
http://tinkerpop.apache.org/docs/3.1.8/upgrade/#_tinkerpop_3_1_8 (upgrade
docs)
http://tinkerpop.apache.org/javadocs/3.1.8/core/ (core javadoc)
http://tinkerpop.apache.org/javadocs/3.1.8/full/ (full javadoc)

The release notes are available here:

https://github.com/apache/tinkerpop/blob/3.1.8/CHANGELOG.asciidoc

The Central Maven repo has sync'd as well:

https://repo1.maven.org/maven2/org/apache/tinkerpop/tinkerpop/3.1.8/

Enjoy!

Re: [VOTE] TinkerPop 3.3.0 Release

[Ted Wilmes]

Validated distribution and docs look good. Epic release, great job.

VOTE: +1

On Thu, Aug 24, 2017 at 10:00 AM, pieter gmail 
wrote:

> Afraid I won't get time to refactor Sqlg's ChooseStep/OptionalStep
> optimizations to deal with the new OptionalStep  before the vote expires.
> So all tests are not passing but its a Sqlg problem.
>
> Apart from that all seems well.
>
> VOTE +1
>
> Cheers
> Pieter
>
>
> On 24/08/2017 16:44, Stephen Mallette wrote:
>
>> doh - i can't believe that's still there. i'll just quick delete that line
>> in svn. stupid.
>>
>> On Thu, Aug 24, 2017 at 10:41 AM, Robert Dale  wrote:
>>
>> Seemed like there was something to do here before the release
>>>
>>> http://tinkerpop.apache.org/docs/3.3.0/upgrade/#_changes_to_io
>>> WILL NEED TO WRITE SOMETHING MORE COHESIVE HERE - JUST LISTING STUFF FOR
>>> RIGHT NOW
>>>
>>> Maybe 'here' doesn't mean there.
>>>
>>> VOTE +1
>>>
>>>
>>> Robert Dale
>>>
>>> On Tue, Aug 22, 2017 at 12:57 PM, Daniel Kuppitz 
>>> wrote:
>>>
>>> *Validating binary distributions*

 * downloading Apache TinkerPop Gremlin
 (apache-tinkerpop-gremlin-console-3.3.0-bin.zip)... OK
 * validating signatures and checksums ...
* PGP signature ... OK
* MD5 checksum ... OK
* SHA1 checksum ... OK
 * unzipping Apache TinkerPop Gremlin ... OK
 * validating Apache TinkerPop Gremlin's docs ... OK
 * validating Apache TinkerPop Gremlin's binaries ... OK
 * validating Apache TinkerPop Gremlin's legal files ...
* LICENSE ... OK
* NOTICE ... OK
 * validating Apache TinkerPop Gremlin's plugin directory ... OK
 * validating Apache TinkerPop Gremlin's lib directory ... OK
 * testing script evaluation ... OK

 * downloading Apache TinkerPop Gremlin
 (apache-tinkerpop-gremlin-server-3.3.0-bin.zip)... OK
 * validating signatures and checksums ...
* PGP signature ... OK
* MD5 checksum ... OK
* SHA1 checksum ... OK
 * unzipping Apache TinkerPop Gremlin ... OK
 * validating Apache TinkerPop Gremlin's docs ... OK
 * validating Apache TinkerPop Gremlin's binaries ... OK
 * validating Apache TinkerPop Gremlin's legal files ...
* LICENSE ... OK
* NOTICE ... OK
 * validating Apache TinkerPop Gremlin's plugin directory ... OK
 * validating Apache TinkerPop Gremlin's lib directory ... OK

 Validating source distribution

 * downloading Apache TinkerPop 3.3.0 (apache-tinkerpop-3.3.0-src.zi
 p)...
 OK
 * validating signatures and checksums ...
* PGP signature ... OK
* MD5 checksum ... OK
* SHA1 checksum ... OK
 * unzipping Apache TinkerPop 3.3.0 ... OK
 * building project ... OK


 VOTE: +1

 Cheers,
 Daniel


 On Tue, Aug 22, 2017 at 8:57 AM, Stephen Mallette >>> >
 wrote:

 Hello,
>
> We are happy to announce that TinkerPop 3.3.0 is ready for release.
>
> The release artifacts can be found at this location:
>  https://dist.apache.org/repos/dist/dev/tinkerpop/3.3.0/
>
> The source distribution is provided by:
>  apache-tinkerpop-3.3.0-src.zip
>
> Two binary distributions are provided for user convenience:
>  apache-tinkerpop-gremlin-console-3.3.0-bin.zip
>  apache-tinkerpop-gremlin-server-3.3.0-bin.zip
>
> The GPG key used to sign the release artifacts is available at:
>  https://dist.apache.org/repos/dist/dev/tinkerpop/KEYS
>
> The online docs can be found here:
>  http://tinkerpop.apache.org/docs/3.3.0/ (user docs)
>  http://tinkerpop.apache.org/docs/3.3.0/upgrade/ (upgrade
> docs)
>  http://tinkerpop.apache.org/javadocs/3.3.0/core/ (core
>
 javadoc)
>>>
  http://tinkerpop.apache.org/javadocs/3.3.0/full/ (full
>
 javadoc)
>>>
 The tag in Apache Git can be found here:
>
> https://git-wip-us.apache.org/repos/asf?p=tinkerpop.git;a=tag;h=
> e8aa977ab33e0ceec6ac9d06a3262d52b4e16511
>
> The release notes are available here:
>
> https://github.com/apache/tinkerpop/blob/3.3.0/
> CHANGELOG.asciidoc#tinkerpop-330-release-date-august-21-2017
>
> The [VOTE] will be open for the next 72 hours --- closing Friday
>
 (August
>>>
 21, 2017) at 12pm EST.
>
> My vote is +1.
>
> Thank you very much,
> Stephen
>
>
>

Re: [VOTE] TinkerPop 3.2.6 Release

[Ted Wilmes]

Validate distribution passed, docs look good.

VOTE: +1

--Ted

On Wed, Aug 23, 2017 at 7:51 AM, Stephen Mallette 
wrote:

> weird - thanks for noticing. i'd be against stopping release over those
> things - as you said, they are minor.  let's fix those after release.
>
> On Wed, Aug 23, 2017 at 7:29 AM, Florian Hockmann 
> wrote:
>
> > I found a few minor issues with the reference documentation, mainly
> > related to the new Gremlin.Net GLV:
> > * Custom Serialization includes the following: 'by creating serializers
> > and deserializers in C (or any other .NET language)'. The 'C'  should be
> > 'C#' here. I don't know what went wrong here as it's correct in the
> > asciidoc file and it works just fine for other occurrences of 'C#'. [1]
> > * The formatting and style of the Conclusion looks wrong. It's different
> > than that of the remaining document. [2]
> > * We should probably replace Gremlin-DotNet everywhere with Gremlin.Net
> to
> > stay consistent.
> >
> > I don't know if these minor issues should halt the release. Especially
> the
> > Gremlin.Net specific issues can also be fixed for the next release in my
> > opinion.
> >
> > Apart from that I built and tested Gremlin.Net without any problems. So,
> > my VOTE is +0
> >
> > [1] http://tinkerpop.apache.org/docs/3.2.6/reference/#_custom_
> > serialization_2
> > [2] http://tinkerpop.apache.org/docs/3.2.6/reference/#conclusion
> >
> > -Ursprüngliche Nachricht-
> > Von: pieter gmail [mailto:pieter.mar...@gmail.com]
> > Gesendet: Dienstag, 22. August 2017 21:19
> > An: dev@tinkerpop.apache.org
> > Betreff: Re: [VOTE] TinkerPop 3.2.6 Release
> >
> > Ran Sqlg's own test suite and TinkerPop's structured and process test
> > suites on Sqlg.
> > All passes.
> >
> > VOTE +1
> >
> > Cheers
> > Pieter
> >
> >
> > On 22/08/2017 20:29, Robert Dale wrote:
> > > VOTE +1
> > >
> > > Robert Dale
> > >
> > > On Tue, Aug 22, 2017 at 10:33 AM, Daniel Kuppitz 
> > wrote:
> > >
> > >> *Validating binary distributions*
> > >>
> > >> * downloading Apache TinkerPop Gremlin
> > >> (apache-tinkerpop-gremlin-console-3.2.6-bin.zip)... OK
> > >> * validating signatures and checksums ...
> > >>* PGP signature ... OK
> > >>* MD5 checksum ... OK
> > >>* SHA1 checksum ... OK
> > >> * unzipping Apache TinkerPop Gremlin ... OK
> > >> * validating Apache TinkerPop Gremlin's docs ... OK
> > >> * validating Apache TinkerPop Gremlin's binaries ... OK
> > >> * validating Apache TinkerPop Gremlin's legal files ...
> > >>* LICENSE ... OK
> > >>* NOTICE ... OK
> > >> * validating Apache TinkerPop Gremlin's plugin directory ... OK
> > >> * validating Apache TinkerPop Gremlin's lib directory ... OK
> > >> * testing script evaluation ... OK
> > >>
> > >> * downloading Apache TinkerPop Gremlin
> > >> (apache-tinkerpop-gremlin-server-3.2.6-bin.zip)... OK
> > >> * validating signatures and checksums ...
> > >>* PGP signature ... OK
> > >>* MD5 checksum ... OK
> > >>* SHA1 checksum ... OK
> > >> * unzipping Apache TinkerPop Gremlin ... OK
> > >> * validating Apache TinkerPop Gremlin's docs ... OK
> > >> * validating Apache TinkerPop Gremlin's binaries ... OK
> > >> * validating Apache TinkerPop Gremlin's legal files ...
> > >>* LICENSE ... OK
> > >>* NOTICE ... OK
> > >> * validating Apache TinkerPop Gremlin's plugin directory ... OK
> > >> * validating Apache TinkerPop Gremlin's lib directory ... OK
> > >>
> > >> Validating source distribution
> > >>
> > >> * downloading Apache TinkerPop 3.2.6 (apache-tinkerpop-3.2.6-src.
> > zip)...
> > >> OK
> > >> * validating signatures and checksums ...
> > >>* PGP signature ... OK
> > >>* MD5 checksum ... OK
> > >>* SHA1 checksum ... OK
> > >> * unzipping Apache TinkerPop 3.2.6 ... OK
> > >> * building project ... OK
> > >>
> > >>
> > >>
> > >> VOTE: +1
> > >>
> > >> Cheers,
> > >> Daniel
> > >>
> > >>
> > >> On Tue, Aug 22, 2017 at 4:54 AM, Stephen Mallette
> > >> 
> > >> wrote:
> > >>
> > >>> Hello,
> > >>>
> > >>> We are happy to announce that TinkerPop 3.2.6 is ready for release.
> > >>>
> > >>> The release artifacts can be found at this location:
> > >>>  https://dist.apache.org/repos/dist/dev/tinkerpop/3.2.6/
> > >>>
> > >>> The source distribution is provided by:
> > >>>  apache-tinkerpop-3.2.6-src.zip
> > >>>
> > >>> Two binary distributions are provided for user convenience:
> > >>>  apache-tinkerpop-gremlin-console-3.2.6-bin.zip
> > >>>  apache-tinkerpop-gremlin-server-3.2.6-bin.zip
> > >>>
> > >>> The GPG key used to sign the release artifacts is available at:
> > >>>  https://dist.apache.org/repos/dist/dev/tinkerpop/KEYS
> > >>>
> > >>> The online docs can be found here:
> > >>>  http://tinkerpop.apache.org/docs/3.2.6/ (user docs)
> > >>>  http://tinkerpop.apache.org/docs/3.2.6/upgrade/ (upgrade
> > docs)
> > >>>  http://tinkerpop.apache.org/javadocs/3.2.6/core/ (core
> > javadoc)
> > >>>  http://tinkerpop.apache.org/java

[RESULT][VOTE] TinkerPop 3.1.8 Release

[Ted Wilmes]

This vote is now closed with a total of 3 +1s, no +0s and no -1s. The
results are:

BINDING VOTES:

+1  (3 -- Ted Wilmes, Daniel Kuppitz, Stephen Mallette)
0   (0)
-1  (0)

NON-BINDING VOTES:

+1 (0)
0  (0)
-1 (0)

Thank you very much,
Ted Wilmes

[VOTE] TinkerPop 3.1.8 Release

[Ted Wilmes]

Hello,

We are happy to announce that TinkerPop 3.1.8 is ready for release.

The release artifacts can be found at this location:
https://dist.apache.org/repos/dist/dev/tinkerpop/3.1.8/

The source distribution is provided by:
apache-tinkerpop-3.1.8-src.zip

Two binary distributions are provided for user convenience:
apache-tinkerpop-gremlin-console-3.1.8-bin.zip
apache-tinkerpop-gremlin-server-3.1.8-bin.zip

The GPG key used to sign the release artifacts is available at:
https://dist.apache.org/repos/dist/dev/tinkerpop/KEYS

The online docs can be found here:
http://tinkerpop.apache.org/docs/3.1.8/ (user docs)
http://tinkerpop.apache.org/docs/3.1.8/upgrade/ (upgrade docs)
http://tinkerpop.apache.org/javadocs/3.1.8/core/ (core javadoc)
http://tinkerpop.apache.org/javadocs/3.1.8/full/ (full javadoc)

The tag in Apache Git can be found here:

https://git-wip-us.apache.org/repos/asf?p=tinkerpop.git;a=commit;h=77592c70ece5bff0de3cfe769459e1e467318798

The release notes are available here:

https://github.com/apache/tinkerpop/blob/3.1.8/CHANGELOG.asciidoc#tinkerpop-318-release-date-august-21-2017

The [VOTE] will be open for the next 72 hours --- closing Thursday (August
24, 2017) at 4pm CST.

My vote is +1.

Thank you very much,
Ted Wilmes

Re: Code Freeze 3.1.8/3.2.6/3.3.0

[Ted Wilmes]

Good morning,
The 3.1.8 SNAPSHOT docs and jars have been deployed.

Thanks,
Ted

On Sat, Aug 12, 2017 at 5:37 AM, Stephen Mallette 
wrote:

> For the next week we're in code freeze on tp31, tp32 and master. Let's
> spend the next week testing and reviewing documentation. I've deployed the
> latest SNAPSHOTs for 3.2.6 and 3.3.0. As Ted is handling 3.1.8, I assume
> he'll post a reply here when he does the same for that version.
>
> I know there are a couple of PRs still open that Robert Dale was trying to
> see through:
>
> https://github.com/apache/tinkerpop/pull/692 (netty version bump)
> https://github.com/apache/tinkerpop/pull/680 (neo4j version bump)
>
> Personally, I feel reasonably comfortable with getting the netty one in.
> Not so sure how the neo4j one will work.
>
> Anyway, as usual, let's use this thread to keep track of issues that pop up
> during code freeze week.
>

Re: [DISCUSS] 3.1.x EOL

[Ted Wilmes]

That makes good sense to me. I'd be honored to lead it off into the sunset.

--Ted

On Wed, Aug 9, 2017 at 6:14 AM, Jorge Bay Gondra 
wrote:

> 3.1 line is about 2 years old, I think its a lot of time for a relatively
> new project like TinkerPop.
> I'm in favor of making 3.1.8 the last release of the 3.1 branch.
>
> On Wed, Aug 9, 2017 at 12:51 PM, Stephen Mallette 
> wrote:
>
> > We have taken backward compatibility and long term support to a new level
> > in TinkerPop 3.x as compared with previous major versions. We're about to
> > go on eight releases of the 3.1.x line of code. Now that 3.3.0 is about
> to
> > release I'm wondering if we need to continue with support of any kind on
> > the 3.1.x line (similar to how we stopped completely stopped dev on
> 3.0.x).
> >
> > I can expand this discussion to the user mailing list, but I thought I'd
> > start here to see what people thought. Can we make 3.1.8 our last release
> > on that line of code?
> >
>

[jira] [Closed] (TINKERPOP-1727) Bytecode object shallow copied when traversals are cloned

[Ted Wilmes (JIRA)]

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

Ted Wilmes closed TINKERPOP-1727.
-
   Resolution: Fixed
Fix Version/s: 3.2.6
   3.3.0

> Bytecode object shallow copied when traversals are cloned
> -
>
> Key: TINKERPOP-1727
> URL: https://issues.apache.org/jira/browse/TINKERPOP-1727
> Project: TinkerPop
>  Issue Type: Bug
>  Components: process
>Affects Versions: 3.3.0, 3.2.5
>    Reporter: Ted Wilmes
>Assignee: Ted Wilmes
> Fix For: 3.3.0, 3.2.6
>
>
> The {{bytecode}} member of traversal objects are only shallow copied when a 
> traversal is cloned. This causes issues because any updates to the clone will 
> be propagated to cloned traversal.
> {code}
> gremlin> g = TinkerGraph.open().traversal()
> ==>graphtraversalsource[tinkergraph[vertices:0 edges:0], standard]
> gremlin> traversal = g.V().out();null
> ==>null
> gremlin> clonedTraversal = traversal.asAdmin().clone();null
> ==>null
> gremlin> clonedTraversal.out().out();null
> ==>null
> gremlin> traversal.getBytecode()
> ==>[[], [V(), out(), out(), out()]]
> gremlin> clonedTraversal.getBytecode()
> ==>[[], [V(), out(), out(), out()]]
> {code}



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

[jira] [Created] (TINKERPOP-1727) Bytecode object shallow copied when traversals are cloned

[Ted Wilmes (JIRA)]

Ted Wilmes created TINKERPOP-1727:
-

 Summary: Bytecode object shallow copied when traversals are cloned
 Key: TINKERPOP-1727
 URL: https://issues.apache.org/jira/browse/TINKERPOP-1727
 Project: TinkerPop
  Issue Type: Bug
  Components: process
Affects Versions: 3.2.5, 3.3.0
Reporter: Ted Wilmes
Assignee: Ted Wilmes


The {{bytecode}} member of traversal objects are only shallow copied when a 
traversal is cloned. This causes issues because any updates to the clone will 
be propagated to cloned traversal.

{code}
gremlin> g = TinkerGraph.open().traversal()
==>graphtraversalsource[tinkergraph[vertices:0 edges:0], standard]
gremlin> traversal = g.V().out();null
==>null
gremlin> clonedTraversal = traversal.asAdmin().clone();null
==>null
gremlin> clonedTraversal.out().out();null
==>null
gremlin> traversal.getBytecode()
==>[[], [V(), out(), out(), out()]]
gremlin> clonedTraversal.getBytecode()
==>[[], [V(), out(), out(), out()]]
{code}



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

Re: ASF Board Draft Report - July 2017

[Ted Wilmes]

Looks good, thanks for putting this together.

--Ted

On Tue, Jul 11, 2017 at 6:54 AM, Stephen Mallette 
wrote:

> Updated with the "new committer" news - I plan to get this posted to the
> board tomorrow
>
> 
>
> ## Description:
> Apache TinkerPop is a graph computing framework for both graph databases
> (OLTP) and graph analytic systems (OLAP).
>
> ## Activity:
> In the last report, we alluded to a committer to whom we extended an
> invitation to for membership within the PMC, and that invitation was
> accepted
> by Robert Dale. In addition, two new committers have been added in Florian
> Hockmann and Jorge Bay Gondra. Both have been contributing in recent months
> to expanding the TinkerPop ecosystem into the Microsoft .NET and Javascript
> worlds.
>
> TinkerPop released versions 3.1.7 and 3.2.5 ( in the last reportm it was
> mistakenly written that 3.2.5 was released - that should have read 3.2.4).
> New development has started on the follow-on releases to those versions and
> work for the new major line of 3.3.0 continues with an expected release
> by end of summer.
>
> Microsoft announced the release of Azure CosmosDB[1], which is a globally
> distributed, multi-model database service. They chose to expose Apache
> TinkerPop as their Graph API. There were some initial branding issues where
> Apache was not properly acknowledged, but the issues were quickly rectified
> once the PMC contacted the project developers at Microsoft.
>
> There were also a number of talks given related to TinkerPop and the
> Gremlin language. Here are a few samples from PMC members:
>
> - "Open problems in the Universal Graph Theory" Keynote at Graph Day
> by Dr. Marko Rodriguez[2][3]
> - "Start Flying with Python and Apahce TinkerPop" at Graph Day
> by Jason Plurad[4]
> - "JanusGraph: Today and Looking to the Future" at Graph Day
> by Ted Wilmes[5]
>
> ## Issues:
> There are no issues requiring board attention at this time.
>
> ## Releases:
> - 3.1.7 (June 12, 2017)
> - 3.2.5 (June 12, 2017)
>
> ## PMC/Committer:
>
> - Last PMC addition was Robert Dale - April 2017
> - Last committer addition was Florian Hockmann/Jorge Bay Gondra - July 2017
>
> ## Links
>
> [1] https://azure.microsoft.com/en-us/services/cosmos-db/
> [2] https://zenodo.org/record/583293
> [3]
> https://www.slideshare.net/slidarko/open-problems-in-the-
> universal-graph-theory
> [4]
> https://www.slideshare.net/JasonPlurad/start-flying-with-
> python-apache-tinkerpop
> [5] http://graphday.com/sf2017/sessions#wilmes
>
> On Mon, Jul 10, 2017 at 10:45 AM, Stephen Mallette 
> wrote:
>
> > Here is the draft of the July 2017 board report - please let me know if
> > there is anything else to add.
> >
> > Ted, not sure if you have a better link to your presentation (I sorta
> > assumed it related to TinkerPop to some degree - if that was wrong and
> you
> > don't think it should be in here, please let me know).
> >
> > Also, I will likely include the outcome of some private PMC discussions
> in
> > here as well as soon as they settle, but I thought I'd just get this out
> > there for initial feedback.
> >
> > 
> >
> > ## Description:
> > Apache TinkerPop is a graph computing framework for both graph databases
> > (OLTP) and graph analytic systems (OLAP).
> >
> > ## Activity:
> > In the last report, we alluded to a committer to whom we extended an
> > invitation to for membership within the PMC, and that invitation was
> > accepted
> > by Robert Dale.
> >
> > TinkerPop released versions 3.1.7 and 3.2.5 ( in the last reportm it was
> > mistakenly written that 3.2.5 was released - that should have read
> 3.2.4).
> > New development has started on the follow-on releases to those versions
> > and
> > work for the new major line of 3.3.0 continues with an expected release
> > by end of summer.
> >
> > Microsoft announced the release of Azure CosmosDB[1], which is a globally
> > distributed, multi-model database service. They chose to expose Apache
> > TinkerPop as their Graph API. There were some initial branding issues
> where
> > Apache was not properly acknowledged, but the issues were quickly
> > rectified
> > once the PMC contacted the project developers at Microsoft.
> >
> > There were also a number of talks given related to TinkerPop and the
> > Gremlin language. Here are a few samples from PMC members:
> >
> > - "Open problems in the Universal Graph Theory" Keynote at 

TinkerPop 3.1.7 Released: A 187 On The Undercover Gremlinz

[Ted Wilmes]

Hello,

TinkerPop 3.1.7 has just been released. This maintenance release contains a
number of bug fixes on the "Undercover Gremlinz" release line and should be
non-breaking for your upgrade needs.

The release artifacts can be found at this location:

https://www.apache.org/dyn/closer.lua/tinkerpop/3.1.7/apache-tinkerpop-gremlin-console-3.1.7-bin.zip
https://www.apache.org/dyn/closer.lua/tinkerpop/3.1.7/apache-tinkerpop-gremlin-server-3.1.7-bin.zip

The online docs can be found here:

http://tinkerpop.apache.org/docs/3.1.7/reference/ (user docs)
http://tinkerpop.apache.org/docs/3.1.7/upgrade/#_tinkerpop_3_1_7 (upgrade
docs)
http://tinkerpop.apache.org/javadocs/3.1.7/core/ (core javadoc)
http://tinkerpop.apache.org/javadocs/3.1.7/full/ (full javadoc)

The release notes are available here:

https://github.com/apache/tinkerpop/blob/3.1.7/CHANGELOG.asciidoc

The Central Maven repo has sync'd as well:

https://repo1.maven.org/maven2/org/apache/tinkerpop/tinkerpop/3.1.7/

Enjoy!

Re: Code Freeze 3.1.7

[Ted Wilmes]

tp31 is now reopened for 3.1.8 development.

Thanks,
Ted

On Tue, Jun 6, 2017 at 8:52 AM, Ted Wilmes  wrote:

> Hello,
> 3.1.7 is now frozen and a snapshot build and updated docs have been
> published. There isn't anything outstanding that I know of, but please let
> me know if anythings needs to be added this week.
>
> Thanks,
> Ted
>

[jira] [Commented] (TINKERPOP-1650) PathRetractionStrategy makes Match steps unsolvable

[Ted Wilmes (JIRA)]

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

Ted Wilmes commented on TINKERPOP-1650:
---

Yes, I still plan on fixing this one.

> PathRetractionStrategy makes Match steps unsolvable
> ---
>
> Key: TINKERPOP-1650
> URL: https://issues.apache.org/jira/browse/TINKERPOP-1650
> Project: TinkerPop
>  Issue Type: Bug
>  Components: process
>Affects Versions: 3.2.3, 3.2.4
>Reporter: Branden Moore
>Assignee: Ted Wilmes
>
> The `PathRetractionStrategy` can make certain Match() steps "Unsolvable".
> This (nonsensical) example demonstrates the issue:
> {code}
> gremlin> g = graph.traversal()
> ==>graphtraversalsource[tinkergraph[vertices:6 edges:6], standard]
> gremlin> 
> g.V().hasLabel("person").as("perp").match(__.as("a").out("created").as("sw"), 
> __.as("sw").has("lang", "java").as("java")).where("sw", 
> neq("a")).select("perp")
> The provided match pattern is unsolvable: [[MatchStartStep(a), 
> VertexStep(OUT,[created],vertex), MatchEndStep(sw)], [MatchStartStep(sw), 
> HasStep([lang.eq(java)]), MatchEndStep(java)], [MatchStartStep(sw), 
> WherePredicateStep(neq(a)), MatchEndStep]]
> Type ':help' or ':h' for help.
> Display stack trace? [yN]n
> gremlin> 
> {code}
> If we remove the `PathRetractionStrategy`, or use `g.withPath()` the match 
> step is solvable, and works fine.
> {code}
> g.withoutStrategies(PathRetractionStrategy).V().hasLabel("person").as("perp").match(__.as("a").out("created").as("sw"),
>  __.as("sw").has("lang", "java").as("java")).where("sw", 
> neq("a")).select("perp")
> ==>v[1]
> ==>v[4]
> ==>v[4]
> ==>v[6]
> gremlin> 
> g.withPath().V().hasLabel("person").as("perp").match(__.as("a").out("created").as("sw"),
>  __.as("sw").has("lang", "java").as("java")).where("sw", 
> neq("a")).select("perp")
> ==>v[1]
> ==>v[4]
> ==>v[4]
> ==>v[6]
> gremlin> 
> {code}



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

Re: [VOTE] TinkerPop 3.2.5 Release

[Ted Wilmes]

VOTE: +1

--Ted

On Fri, Jun 16, 2017 at 3:18 AM, Daniel Kuppitz  wrote:

> bin/validate-distribution.sh still looking good.
>
> VOTE: +1
>
>
> On Thu, Jun 15, 2017 at 10:33 PM, Stephen Mallette 
> wrote:
>
> > Hello (again),
> >
> > We are happy to announce (again) that TinkerPop 3.2.5 is ready for
> release.
> >
> > The release artifacts can be found at this location:
> > https://dist.apache.org/repos/dist/dev/tinkerpop/3.2.5/
> >
> > The source distribution is provided by:
> > apache-tinkerpop-3.2.5-src.zip
> >
> > Two binary distributions are provided for user convenience:
> > apache-tinkerpop-gremlin-console3.2.5-bin.zip
> > apache-tinkerpop-gremlin-server-3.2.5-bin.zip
> >
> > The GPG key used to sign the release artifacts is available at:
> > https://dist.apache.org/repos/dist/dev/tinkerpop/KEYS
> >
> > The online docs can be found here:
> > http://tinkerpop.apache.org/docs/3.2.5/ (user docs)
> > http://tinkerpop.apache.org/docs/3.2.5/upgrade/ (upgrade docs)
> > http://tinkerpop.apache.org/javadocs/3.2.5/core/ (core javadoc)
> > http://tinkerpop.apache.org/javadocs/3.2.5/full/ (full javadoc)
> >
> > The tag in Apache Git can be found here:
> >
> > https://git-wip-us.apache.org/repos/asf?p=tinkerpop.git;a=tag;h=
> > 0ecbb067a212711a6b996af828cc932956282dcc
> >
> > The release notes are available here:
> >
> > https://github.com/apache/tinkerpop/blob/master/
> > CHANGELOG.asciidoc#tinkerpop-320-nine-inch-gremlins
> >
> > The [VOTE] will be open for the next 72 hours --- closing Sunday (June
> 18,
> > 2017) at  4:30pm EST
> >
> > My vote is +1 (again).
> >
> > Thank you very much,
> > Stephen
> >
>

[RESULT][VOTE] TinkerPop 3.1.7 Release

[Ted Wilmes]

This vote is now closed with a total of 3 +1s, no +0s and no -1s. The
results are:

BINDING VOTES:

+1  (3 -- Ted Wilmes, Stephen Mallette, Daniel Kuppitz)
  0  (0)
 -1  (0)

NON-BINDING VOTES:

+1 (0)
  0 (0)
 -1 (0)

Thank you very much,
Ted Wilmes

Re: code freeze 3.2.5

[Ted Wilmes]

Good deal, should I close out the vote for 3.1.7 tonight, barring any -1's
and then we can hold off on the announcement to coincide with 3.2.5?

--Ted

On Thu, Jun 15, 2017 at 12:28 PM, Stephen Mallette 
wrote:

> Kuppitz (who has the day off today) just informed me that the fix he was
> responsible for is in. I'm going to restart the release process - Hopefully
> i'll have a new VOTE thread opened up by end of day.
>
> On Thu, Jun 15, 2017 at 9:34 AM, Stephen Mallette 
> wrote:
>
> > It seems that way. It could only be a problem if someone submitted gryo
> > bytecode generated from something other than our GraphTraversal
> > implementation. That seems unlikely so I guess this was a lesser problem
> > than I thought - oh well.
> >
> > On Thu, Jun 15, 2017 at 9:15 AM, Robert Dale  wrote:
> >
> >> So I guess inside, outside, and between are never actually serialized
> >> directly because they become a composition of other predicates?
> >>
> >> Robert Dale
> >>
> >> On Thu, Jun 15, 2017 at 8:48 AM, Robert Dale  wrote:
> >>
> >> > Was working on serializing JanusGraph predicates - geo, text - for
> >> > withRemote. Since those predicates become P, I had to borrow and
> modify
> >> the
> >> > TinkerPop P serializer and noticed that something's not like the
> other.
> >> >
> >> > Robert Dale
> >> >
> >> > On Thu, Jun 15, 2017 at 8:37 AM, Stephen Mallette <
> spmalle...@gmail.com
> >> >
> >> > wrote:
> >> >
> >> >> Robert, how did you go about hitting that problem with P.inside()? It
> >> >> occurs to me now that this was so deadly a bug because I'm not sure
> we
> >> >> ever
> >> >> end up actually serializing an "inside".
> >> >>
> >> >> On Thu, Jun 15, 2017 at 6:23 AM, Stephen Mallette <
> >> spmalle...@gmail.com>
> >> >> wrote:
> >> >>
> >> >> > We do have a test for P.inside in the process tests but I didn't
> >> realize
> >> >> > that it doesn't compile to a P.inside at bytecode serialization
> time:
> >> >> >
> >> >> > gremlin> g.V(1).outE().has("weight", P.inside(0.0d,
> >> >> 0.6d)).inV().explain()
> >> >> > ==>Traversal Explanation
> >> >> > 
> >> >> > 
> >> >> > ===
> >> >> > Original Traversal [GraphStep(vertex,[1]),
> >> >> > VertexStep(OUT,edge), HasStep([weight.and(gt(0.0), lt(0.6))]),
> >> >> > EdgeVertexStep(IN)]
> >> >> >
> >> >> > ConnectiveStrategy   [D]   [GraphStep(vertex,[1]),
> >> >> > VertexStep(OUT,edge), HasStep([weight.and(gt(0.0), lt(0.6))]),
> >> >> > EdgeVertexStep(IN)]
> >> >> > MatchPredicateStrategy   [O]   [GraphStep(vertex,[1]),
> >> >> > VertexStep(OUT,edge), HasStep([weight.and(gt(0.0), lt(0.6))]),
> >> >> > EdgeVertexStep(IN)]
> >> >> > FilterRankingStrategy[O]   [GraphStep(vertex,[1]),
> >> >> > VertexStep(OUT,edge), HasStep([weight.and(gt(0.0), lt(0.6))]),
> >> >> > EdgeVertexStep(IN)]
> >> >> > InlineFilterStrategy [O]   [GraphStep(vertex,[1]),
> >> >> > VertexStep(OUT,edge), HasStep([weight.and(gt(0.0), lt(0.6))]),
> >> >> > EdgeVertexStep(IN)]
> >> >> > IncidentToAdjacentStrategy   [O]   [GraphStep(vertex,[1]),
> >> >> > VertexStep(OUT,edge), HasStep([weight.and(gt(0.0), lt(0.6))]),
> >> >> > EdgeVertexStep(IN)]
> >> >> > AdjacentToIncidentStrategy   [O]   [GraphStep(vertex,[1]),
> >> >> > VertexStep(OUT,edge), HasStep([weight.and(gt(0.0), lt(0.6))]),
> >> >> > EdgeVertexStep(IN)]
> >> >> > RepeatUnrollStrategy [O]   [GraphStep(vertex,[1]),
> >> >> > VertexStep(OUT,edge), HasStep([weight.and(gt(0.0), lt(0.6))]),
> >> >> > EdgeVertexStep(IN)]
> >> >> > RangeByIsCountStrategy   [O]   [GraphStep(vertex,[1]),
> >> >> > VertexStep(OUT,edge), HasStep([weight.and(gt(0.0), lt(0.6))]),
> >> >> > EdgeVertexStep(IN)]
> >> >> > PathRetractionStrategy   [O]   [GraphStep(vertex,[1]),
> >> >> > VertexStep(OUT,edge), HasStep([weight.and(gt(0.0), lt(0.6))]),
> >> >> > EdgeVertexStep(IN)]
> >> >> > LazyBarrierStrategy  [O]   [GraphStep(vertex,[1]),
> >> >> > VertexStep(OUT,edge), HasStep([weight.and(gt(0.0), lt(0.6))]),
> >> >> > EdgeVertexStep(IN)]
> >> >> > TinkerGraphCountStrategy [P]   [GraphStep(vertex,[1]),
> >> >> > VertexStep(OUT,edge), HasStep([weight.and(gt(0.0), lt(0.6))]),
> >> >> > EdgeVertexStep(IN)]
> >> >> > TinkerGraphStepStrategy  [P]   [TinkerGraphStep(vertex,[1]),
> >> >> > VertexStep(OUT,edge), HasStep([weight.and(gt(0.0), lt(0.6))]),
> >> >> > EdgeVertexStep(IN)]
> >> >> > ProfileStrategy  [F]   [TinkerGraphStep(vertex,[1]),
> >> >> > VertexStep(OUT,edge), HasStep([weight.and(gt(0.0), lt(0.6))]),
> >> >> > EdgeVertexStep(IN)]
> >> >> > StandardVerificationStrategy [V]   [TinkerGraphStep(vertex,[1]),
> >> >> > VertexStep(OUT,edge), HasStep([weight.and(gt(0.0), lt(0.6))]),
> >> >> > EdgeVertexStep(IN)]
> >> >> >
> >> >> > Final Traversal[TinkerGraphStep(vertex,[1]),
> >> >> > VertexStep(OUT,edge), HasStep([weight.and(gt(

[VOTE] TinkerPop 3.1.7 Release

[Ted Wilmes]

Hello,

We are happy to announce that TinkerPop 3.1.7 is ready for release.

The release artifacts can be found at this location:
https://dist.apache.org/repos/dist/dev/tinkerpop/3.1.7/

The source distribution is provided by:
apache-tinkerpop-3.1.7-src.zip

Two binary distributions are provided for user convenience:
apache-tinkerpop-gremlin-console-3.1.7-bin.zip
apache-tinkerpop-gremlin-server-3.1.7-bin.zip

The GPG key used to sign the release artifacts is available at:
https://dist.apache.org/repos/dist/dev/tinkerpop/KEYS

The online docs can be found here:
http://tinkerpop.apache.org/docs/3.1.7/ (user docs)
http://tinkerpop.apache.org/docs/3.1.7/upgrade/ (upgrade docs)
http://tinkerpop.apache.org/javadocs/3.1.7/core/ (core javadoc)
http://tinkerpop.apache.org/javadocs/3.1.7/full/ (full javadoc)

The tag in Apache Git can be found here:

https://git-wip-us.apache.org/repos/asf?p=tinkerpop.git;a=tag;h=1240a2346d4016634cd95dd62d5a56498bd852fb

The release notes are available here:

https://github.com/apache/tinkerpop/blob/3.1.7/CHANGELOG.asciidoc#tinkerpop-317-release-date-june-12-2017

The [VOTE] will be open for the next 72 hours --- closing Thursday (June
15, 2017) at 8pm CST.

My vote is +1.

Thank you very much,
Ted Wilmes

Code Freeze 3.1.7

[Ted Wilmes]

Hello,
3.1.7 is now frozen and a snapshot build and updated docs have been
published. There isn't anything outstanding that I know of, but please let
me know if anythings needs to be added this week.

Thanks,
Ted

Re: [DISCUSS] Upcoming Release 3.2.5/3.1.7

[Ted Wilmes]

I can do the 3.1.7 line.

--Ted

On Fri, May 26, 2017 at 9:06 AM, Stephen Mallette 
wrote:

> I think we should start to firm things up for release of 3.2.5 and 3.1.7.
> I'd like to propose that our code freeze period start Saturday June 3 with
> a VOTE for release Monday, June 12. Hopefully that sounds good to everyone.
> Is anyone aware of any critical issues that need to be resolved for these
> versions?
>
> Also, Any volunteers to help with release duties?
>

[jira] [Resolved] (TINKERPOP-1652) Disable PathRetractionStrategy strategy if VertexProgramStep has LABELLED_PATH requirement

[Ted Wilmes (JIRA)]

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

Ted Wilmes resolved TINKERPOP-1652.
---
   Resolution: Fixed
Fix Version/s: 3.2.5

> Disable PathRetractionStrategy strategy if VertexProgramStep has 
> LABELLED_PATH requirement
> --
>
> Key: TINKERPOP-1652
> URL: https://issues.apache.org/jira/browse/TINKERPOP-1652
> Project: TinkerPop
>  Issue Type: Bug
>  Components: process
>Affects Versions: 3.2.4
>Reporter: Ted Wilmes
>Assignee: Ted Wilmes
> Fix For: 3.2.5
>
>
> [~dkuppitz] notified me that there is an issue where 
> {{PathRetractionStrategy}} is incorrectly dropping path elements when a 
> {{VertexProgramStep}} is present that has a {{LABELLED_PATH}} requirement.  
> We already handle the case where path is required but this issue will also 
> disable the strategy if a vertex program is present that requires 
> {{LABELLED_PATH}}.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Closed] (TINKERPOP-1652) Disable PathRetractionStrategy strategy if VertexProgramStep has LABELLED_PATH requirement

[Ted Wilmes (JIRA)]

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

Ted Wilmes closed TINKERPOP-1652.
-

> Disable PathRetractionStrategy strategy if VertexProgramStep has 
> LABELLED_PATH requirement
> --
>
> Key: TINKERPOP-1652
> URL: https://issues.apache.org/jira/browse/TINKERPOP-1652
> Project: TinkerPop
>  Issue Type: Bug
>  Components: process
>Affects Versions: 3.2.4
>Reporter: Ted Wilmes
>Assignee: Ted Wilmes
> Fix For: 3.2.5
>
>
> [~dkuppitz] notified me that there is an issue where 
> {{PathRetractionStrategy}} is incorrectly dropping path elements when a 
> {{VertexProgramStep}} is present that has a {{LABELLED_PATH}} requirement.  
> We already handle the case where path is required but this issue will also 
> disable the strategy if a vertex program is present that requires 
> {{LABELLED_PATH}}.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Commented] (TINKERPOP-1652) Disable PathRetractionStrategy strategy if VertexProgramStep has LABELLED_PATH requirement

[Ted Wilmes (JIRA)]

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

Ted Wilmes commented on TINKERPOP-1652:
---

Thanks for the test, I was thinking this wouldn't fix that.  That'll be next on 
the list.

> Disable PathRetractionStrategy strategy if VertexProgramStep has 
> LABELLED_PATH requirement
> --
>
> Key: TINKERPOP-1652
> URL: https://issues.apache.org/jira/browse/TINKERPOP-1652
> Project: TinkerPop
>  Issue Type: Bug
>  Components: process
>Affects Versions: 3.2.4
>    Reporter: Ted Wilmes
>Assignee: Ted Wilmes
>
> [~dkuppitz] notified me that there is an issue where 
> {{PathRetractionStrategy}} is incorrectly dropping path elements when a 
> {{VertexProgramStep}} is present that has a {{LABELLED_PATH}} requirement.  
> We already handle the case where path is required but this issue will also 
> disable the strategy if a vertex program is present that requires 
> {{LABELLED_PATH}}.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Created] (TINKERPOP-1652) Disable PathRetractionStrategy strategy if VertexProgramStep has LABELLED_PATH requirement

[Ted Wilmes (JIRA)]

Ted Wilmes created TINKERPOP-1652:
-

 Summary: Disable PathRetractionStrategy strategy if 
VertexProgramStep has LABELLED_PATH requirement
 Key: TINKERPOP-1652
 URL: https://issues.apache.org/jira/browse/TINKERPOP-1652
 Project: TinkerPop
  Issue Type: Bug
Reporter: Ted Wilmes
Assignee: Ted Wilmes


[~dkuppitz] notified me that there is an issue where {{PathRetractionStrategy}} 
is incorrectly dropping path elements when a {{VertexProgramStep}} is present 
that has a {{LABELLED_PATH}} requirement.  We already handle the case where 
path is required but this issue will also disable the strategy if a vertex 
program is present that requires {{LABELLED_PATH}}.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Assigned] (TINKERPOP-1650) PathRetractionStrategy makes Match steps unsolvable

[Ted Wilmes (JIRA)]

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

Ted Wilmes reassigned TINKERPOP-1650:
-

Assignee: Ted Wilmes

> PathRetractionStrategy makes Match steps unsolvable
> ---
>
> Key: TINKERPOP-1650
> URL: https://issues.apache.org/jira/browse/TINKERPOP-1650
> Project: TinkerPop
>  Issue Type: Bug
>Affects Versions: 3.2.3, 3.2.4
>Reporter: Branden Moore
>    Assignee: Ted Wilmes
>
> The `PathRetractionStrategy` can make certain Match() steps "Unsolvable".
> This (nonsensical) example demonstrates the issue:
> {code}
> gremlin> g = graph.traversal()
> ==>graphtraversalsource[tinkergraph[vertices:6 edges:6], standard]
> gremlin> 
> g.V().hasLabel("person").as("perp").match(__.as("a").out("created").as("sw"), 
> __.as("sw").has("lang", "java").as("java")).where("sw", 
> neq("a")).select("perp")
> The provided match pattern is unsolvable: [[MatchStartStep(a), 
> VertexStep(OUT,[created],vertex), MatchEndStep(sw)], [MatchStartStep(sw), 
> HasStep([lang.eq(java)]), MatchEndStep(java)], [MatchStartStep(sw), 
> WherePredicateStep(neq(a)), MatchEndStep]]
> Type ':help' or ':h' for help.
> Display stack trace? [yN]n
> gremlin> 
> {code}
> If we remove the `PathRetractionStrategy`, or use `g.withPath()` the match 
> step is solvable, and works fine.
> {code}
> g.withoutStrategies(PathRetractionStrategy).V().hasLabel("person").as("perp").match(__.as("a").out("created").as("sw"),
>  __.as("sw").has("lang", "java").as("java")).where("sw", 
> neq("a")).select("perp")
> ==>v[1]
> ==>v[4]
> ==>v[4]
> ==>v[6]
> gremlin> 
> g.withPath().V().hasLabel("person").as("perp").match(__.as("a").out("created").as("sw"),
>  __.as("sw").has("lang", "java").as("java")).where("sw", 
> neq("a")).select("perp")
> ==>v[1]
> ==>v[4]
> ==>v[4]
> ==>v[6]
> gremlin> 
> {code}



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Commented] (TINKERPOP-1650) PathRetractionStrategy makes Match steps unsolvable

[Ted Wilmes (JIRA)]

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

Ted Wilmes commented on TINKERPOP-1650:
---

Thanks for the steps to reproduce [~bjmoor].  I'll take a look.

> PathRetractionStrategy makes Match steps unsolvable
> ---
>
> Key: TINKERPOP-1650
> URL: https://issues.apache.org/jira/browse/TINKERPOP-1650
> Project: TinkerPop
>  Issue Type: Bug
>Affects Versions: 3.2.3, 3.2.4
>Reporter: Branden Moore
>
> The `PathRetractionStrategy` can make certain Match() steps "Unsolvable".
> This (nonsensical) example demonstrates the issue:
> {code}
> gremlin> g = graph.traversal()
> ==>graphtraversalsource[tinkergraph[vertices:6 edges:6], standard]
> gremlin> 
> g.V().hasLabel("person").as("perp").match(__.as("a").out("created").as("sw"), 
> __.as("sw").has("lang", "java").as("java")).where("sw", 
> neq("a")).select("perp")
> The provided match pattern is unsolvable: [[MatchStartStep(a), 
> VertexStep(OUT,[created],vertex), MatchEndStep(sw)], [MatchStartStep(sw), 
> HasStep([lang.eq(java)]), MatchEndStep(java)], [MatchStartStep(sw), 
> WherePredicateStep(neq(a)), MatchEndStep]]
> Type ':help' or ':h' for help.
> Display stack trace? [yN]n
> gremlin> 
> {code}
> If we remove the `PathRetractionStrategy`, or use `g.withPath()` the match 
> step is solvable, and works fine.
> {code}
> g.withoutStrategies(PathRetractionStrategy).V().hasLabel("person").as("perp").match(__.as("a").out("created").as("sw"),
>  __.as("sw").has("lang", "java").as("java")).where("sw", 
> neq("a")).select("perp")
> ==>v[1]
> ==>v[4]
> ==>v[4]
> ==>v[6]
> gremlin> 
> g.withPath().V().hasLabel("person").as("perp").match(__.as("a").out("created").as("sw"),
>  __.as("sw").has("lang", "java").as("java")).where("sw", 
> neq("a")).select("perp")
> ==>v[1]
> ==>v[4]
> ==>v[4]
> ==>v[6]
> gremlin> 
> {code}



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

Re: ChooseStep & count type coercion

[Ted Wilmes]

Good catch and yep, that's the one.

On Fri, Feb 17, 2017 at 9:14 AM, Robert Dale  wrote:

> I think this is the correct link
> https://issues.apache.org/jira/browse/TINKERPOP-1620
>
> Robert Dale
>
> On Wed, Feb 1, 2017 at 12:56 PM, Ted Wilmes  wrote:
>
> > Thanks guys.  Ticket created:
> > https://issues.apache.org/jira/browse/TINKERPOP-1596
> >
> > --Ted
> >
> > On Wed, Feb 1, 2017 at 10:37 AM, Marko Rodriguez 
> > wrote:
> >
> > > I concur with Robert.
> > >
> > > Kuppitz has done a lot to help in this area with NumberHelper. We
> should
> > > make sure it is propagated throughout.
> > > https://github.com/apache/tinkerpop/blob/master/gremlin-
> > > core/src/main/java/org/apache/tinkerpop/gremlin/util/NumberHelper.java
> <
> > > https://github.com/apache/tinkerpop/blob/master/gremlin-
> > > core/src/main/java/org/apache/tinkerpop/gremlin/util/
> NumberHelper.java>
> > >
> > > Can you please make a ticket about your particular ChooseStep
> situation?
> > >
> > > https://issues.apache.org/jira/browse/TINKERPOP/ <
> > > https://issues.apache.org/jira/browse/TINKERPOP/?
> > > selectedTab=com.atlassian.jira.jira-projects-plugin:summary-panel>
> > >
> > > Thank you,
> > > Marko.
> > >
> > > http://markorodriguez.com
> > >
> > >
> > >
> > > > On Feb 1, 2017, at 8:03 AM, Robert Dale  wrote:
> > > >
> > > > It absolutely would make sense to treat numbers as numbers and not as
> > > data
> > > > structures.  This is one of those things that keeps gremlin tied to a
> > > Java
> > > > implementation and from being language-agnostic.
> > > >
> > > > Robert Dale
> > > >
> > > > On Wed, Feb 1, 2017 at 9:51 AM, Ted Wilmes 
> wrote:
> > > >
> > > >> Hello,
> > > >> I wrote a traversal using a choose that included a count in the
> > > branching
> > > >> traversal.  Here is a simplified version:
> > > >>
> > > >> g.V().choose(bothE().count()).option(1, constant(1)).option(3,
> > > >> constant(3))
> > > >>
> > > >> I wasn't getting any results and then realized none of the options
> > would
> > > >> match because count produces a long.
> > > >> This is the correct behavior now and makes sense in the context of
> > > Java's
> > > >> type system but I was wondering if it
> > > >> wouldn't make sense to handle the type coercion from int to long so
> > the
> > > >> user could use an integer?  I think this
> > > >> would be consistent with how other steps like 'is' works:
> > > >>
> > > >> gremlin> g.V().local(bothE().count()).is(3)
> > > >> ==>3
> > > >> ==>3
> > > >> ==>3
> > > >>
> > > >>
> > > >> Full example:
> > > >> gremlin> g = TinkerFactory.createModern().traversal()
> > > >> ==>graphtraversalsource[tinkergraph[vertices:6 edges:6], standard]
> > > >> gremlin> g.V().choose(bothE().count()).option(1,
> > constant(1)).option(3,
> > > >> constant(3))
> > > >> gremlin> g.V().choose(bothE().count()).option(1l,
> > > constant(1)).option(3l,
> > > >> constant(3))
> > > >> ==>3
> > > >> ==>1
> > > >> ==>3
> > > >> ==>3
> > > >> ==>1
> > > >> ==>1
> > > >>
> > > >>
> > > >> Thanks,
> > > >> Ted
> > > >>
> > >
> > >
> >
>

TinkerPop 3.1.6 Released: A 187 On The Undercover Gremlinz

[Ted Wilmes]

Hello,

TinkerPop 3.1.6 has just been released. This maintenance release contains a
number of bug fixes on the "Undercover Gremlinz" release line and should be
non-breaking for your upgrade needs.

The release artifacts can be found at this location:

https://www.apache.org/dyn/closer.lua/tinkerpop/3.1.6/apache-tinkerpop-gremlin-console-3.1.6-bin.zip
https://www.apache.org/dyn/closer.lua/tinkerpop/3.1.6/apache-tinkerpop-gremlin-server-3.1.6-bin.zip

The online docs can be found here:

http://tinkerpop.apache.org/docs/3.1.6/reference/ (user docs)
http://tinkerpop.apache.org/docs/3.1.6/upgrade/#_tinkerpop_3_1_6 (upgrade
docs)
http://tinkerpop.apache.org/javadocs/3.1.6/core/ (core javadoc)
http://tinkerpop.apache.org/javadocs/3.1.6/full/ (full javadoc)

The release notes are available here:

https://github.com/apache/tinkerpop/blob/3.1.6/CHANGELOG.asciidoc

The Central Maven repo has sync'd as well:

https://repo1.maven.org/maven2/org/apache/tinkerpop/tinkerpop/3.1.6/

Enjoy!


​

3.1.x code freeze lifted

[Ted Wilmes]

The code freeze is lifted on the 3.1.x line and the 3.1.7-SNAPSHOT has been
published.

Thanks,
Ted

[RESULT][VOTE] TinkerPop 3.1.6 Release

[Ted Wilmes]

This vote is now closed with a total of 5 +1s, no +0s and no -1s. The
results are:

BINDING VOTES:

+1  (5 -- Ted Wilmes, Stephen Mallette, Daniel Kuppitz, Dylan Millikin,
Jason Plurad)
0   (0)
-1  (0)

NON-BINDING VOTES:

+1 (1 -- David Brown)
0  (0)
-1 (0)

Thank you very much,
Ted Wilmes

Re: [VOTE] TinkerPop 3.2.4 Release

[Ted Wilmes]

Release and docs looks good to me.

Validating source distribution

* downloading Apache TinkerPop 3.2.4 (apache-tinkerpop-3.2.4-src.zip)... OK
* validating signatures and checksums ...
  * PGP signature ... OK
  * MD5 checksum ... OK
  * SHA1 checksum ... OK
* unzipping Apache TinkerPop 3.2.4 ... OK
* building project ... OK


VOTE: +1

Thanks,
Ted

On Thu, Feb 9, 2017 at 12:32 PM, pieter-gmail 
wrote:

> Ok, however I did test on the 3.2.4-SNAPSHOT immediately after Jason's
> email on the 2/2/2017 and those changes were not there.
> They are there now but there was a SNAPSHOT release on the 08/02/2017 so
> things changed.
> Anyhow that might just be some SNAPSHOT confusion thing.
>
> Next time I'll pull the code and build it manually to make sure.
>
> Thanks
> Pieter
>
>
>
> On 09/02/2017 22:27, Marko Rodriguez wrote:
> > Hi,
> >
> >> The significant change is
> >> ffe1b4c Marko A. Rodriguez  on 2016/11/15 at
> 12:44 AM
> > Ah yea. Thats different from what I thought you had issue with —
> has-containers and arrays/collections handling.
> >
> >> I don't have a problem with the changes just that is quite a refactor on
> >> my side as it changes the structure of the HasSteps and its
> >> HasContainers. I had made some assumptions around how HasSteps and
> >> HasContainers look when optimizing.
> > Yea, it “folds left” now so you don’t have to walk over has()-chains.
> >
> >> The change is quite old but somehow it was not present in the
> >> 3.2.4-SNAPSHOT I tested on it when the code freeze announcement was
> >> made. Not sure what happened there but alas its not giving me enough
> >> time to get things working again.
> > I would say don’t wait till releases to test Sqlg. In principle, you
> should VOTE on every PR by building and testing the changes against Sqlg.
> That is where you can make a huge contribution.
> >
> >> So I am not voting negative just requesting a weekend, if possible, to
> >> get through the refactor.
> > Again, PR awareness, not release awareness.
> >
> > Marko.
> >
> > http://markorodriguez.com
> >
> >
> >> Cheers
> >> Pieter
> >>
> >>
> >>
> >>
> >>
> >> "added TraversalHelper.addHasContainer() on 2016/11/15
> >>
> >> On 09/02/2017 22:11, Stephen Mallette wrote:
> >>> Unless I'm missing something, HasStep hasn't changed in 4 months and
> >>> HasContainer hasn't changed in 3 months. The only update that went in
> after
> >>> 2/2 that I can think of that would have any bearing for graph
> providers who
> >>> tested before/after that date would be the AutoCloseable stuff:
> >>>
> >>> https://github.com/apache/tinkerpop/pull/548
> >>>
> >>> Your problems aren't related to that are they?  Can you provide some
> >>> synopsis of where the problems lie?
> >>>
> >>>
> >>>
> >>> On Thu, Feb 9, 2017 at 2:47 PM, pieter-gmail 
> >>> wrote:
> >>>
>  Hi,
> 
>  Some issues regarding the release process.
> 
>  On the 2/2/2017 the 3.2.4-SNAPSHOT was released.
>  I then started testing and found almost no issues.
> 
>  However yesterday when the VOTE mail came I found many issues on
> 3.2.4.
>  To understand the confusion I tested again on 3.2.4-SNAPSHOT and found
>  the same new issues.
>  I then checked the 3.2.4-SNAPSHOT timestamp and it changed to
> 08/02/2017
> 
>  Not sure what happened there as I can not, nor is it worth it, check
> an
>  old SNAPSHOT version's binary.
>  The relevant code changes are quite old (December 2016) but it may
> have
>  been done on a separate branch and rebasing may loose the merging
>  information. Not sure about this though.
> 
>  This only leaves the 72 hours to catch up.
> 
>  Even though it is a minor release there has been significant changes
> to
>  HasStep and HasContainer which breaks the heart (mine at least) of
>  implementors optimization code.
> 
>  Basically to get any value from a vote I for one will need more time.
> 
>  So far I have not found any TinkerPop issues but will need at least
> the
>  weekend to know better.
> 
>  Thanks
>  Pieter
> 
>  On 08/02/2017 16:51, Jason Plurad wrote:
> > Hello,
> >
> > We are happy to announce that TinkerPop 3.2.4 is ready for release.
> >
> > The release artifacts can be found at this location:
> >https://dist.apache.org/repos/dist/dev/tinkerpop/3.2.4/
> >
> > The source distribution is provided by:
> >apache-tinkerpop-3.2.4-src.zip
> >
> > Two binary distributions are provided for user convenience:
> >apache-tinkerpop-gremlin-console-3.2.4-bin.zip
> >apache-tinkerpop-gremlin-server-3.2.4-bin.zip
> >
> > The GPG key used to sign the release artifacts is available at:
> >https://dist.apache.org/repos/dist/dev/tinkerpop/KEYS
> >
> > The online docs can be found here:
> >http://tinkerpop.apache.org/docs/3.2.4/ (user docs)
> >http://tinkerpop.apache.org/do

Re: [VOTE] TinkerPop 3.1.6 Release

[Ted Wilmes]

Thanks for taking the time to vote.  If there aren't any objections by EOD
tomorrow, I'll call it and complete the release.

Thanks,
Ted

On Mon, Feb 6, 2017 at 1:52 PM, Dylan Millikin 
wrote:

> I ran the php driver tests against this locally and everything is good.
>
> VOTE +1 from me!!
>
> Cheers.
>
> On Mon, Feb 6, 2017 at 7:48 AM, Stephen Mallette 
> wrote:
>
> > I can't remember the error I got, but I think it makes sense to test
> > validate-distribution.sh from the branch that the release was generated
> > from. I probably shouldn't have tried to test from master - that sorta
> > doesn't make sense.
> >
> > On Sun, Feb 5, 2017 at 7:58 AM, Daniel Kuppitz  wrote:
> >
> > > >
> > > > Note that I couldn't use the validate-distribution.sh on master for
> > some
> > > reason
> > > > - it failed
> > >
> > >
> > > Did it fail when it tested gremlin.sh -e..? This test was added
> recently
> > > and I think that's expected to fail in 3.1.x. All others should succeed
> > > though, but in general we should always use the validation script from
> > the
> > > respective development branches (tp31/, tp32/  and master/).
> > >
> > > Validation worked for me too, hence ...
> > >
> > > VOTE: +1
> > >
> > > Cheers,
> > > Daniel
> > >
> > >
> > > On Sat, Feb 4, 2017 at 2:20 AM, Stephen Mallette  >
> > > wrote:
> > >
> > > > Hey Ted - You're a little early as we agreed a while back to let two
> > > > weekends pass from code freeze to VOTE day (maybe release docs need
> to
> > be
> > > > updated to reflect that). Not a big deal imo as I doubt there are
> many
> > > > folks still testing on 3.1.6 at this point, so I'm fine to VOTE from
> > here
> > > > if everyone else is. If anyone feels like we need to extend the
> VOTEing
> > > > time, just yell.  3.2.4 voting definitely shouldn't start until
> Monday.
> > > >
> > > > In the mean time, as it is right now:
> > > >
> > > > $ bin/validate-distribution.sh 3.1.6
> > > >
> > > > Validating binary distributions
> > > >
> > > > * downloading Apache TinkerPop Gremlin
> > > > (apache-tinkerpop-gremlin-console-3.1.6-bin.zip)... OK
> > > > * validating signatures and checksums ...
> > > >   * PGP signature ... OK
> > > >   * MD5 checksum ... OK
> > > >   * SHA1 checksum ... OK
> > > > * unzipping Apache TinkerPop Gremlin ... OK
> > > > * validating Apache TinkerPop Gremlin's docs ... OK
> > > > * validating Apache TinkerPop Gremlin's binaries ... OK
> > > > * validating Apache TinkerPop Gremlin's legal files ...
> > > >   * LICENSE ... OK
> > > >   * NOTICE ... OK
> > > > * validating Apache TinkerPop Gremlin's plugin directory ... OK
> > > > * validating Apache TinkerPop Gremlin's lib directory ... OK
> > > > * testing script evaluation ... OK
> > > >
> > > > * downloading Apache TinkerPop Gremlin
> > > > (apache-tinkerpop-gremlin-server-3.1.6-bin.zip)... OK
> > > > * validating signatures and checksums ...
> > > >   * PGP signature ... OK
> > > >   * MD5 checksum ... OK
> > > >   * SHA1 checksum ... OK
> > > > * unzipping Apache TinkerPop Gremlin ... OK
> > > > * validating Apache TinkerPop Gremlin's docs ... OK
> > > > * validating Apache TinkerPop Gremlin's binaries ... OK
> > > > * validating Apache TinkerPop Gremlin's legal files ...
> > > >   * LICENSE ... OK
> > > >   * NOTICE ... OK
> > > > * validating Apache TinkerPop Gremlin's plugin directory ... OK
> > > > * validating Apache TinkerPop Gremlin's lib directory ... OK
> > > >
> > > > Validating source distribution
> > > >
> > > > * downloading Apache TinkerPop 3.1.6 (apache-tinkerpop-3.1.6-src.
> > zip)...
> > > > OK
> > > > * validating signatures and checksums ...
> > > >   * PGP signature ... OK
> > > >   * MD5 checksum ... OK
> > > >   * SHA1 checksum ... OK
> > > > * unzipping Apache TinkerPop 3.1.6 ... OK
> > > > * building project ... OK
> > > >
> > > > Note that I couldn't use the validate-distribution.sh on master for
> >

Re: [VOTE] TinkerPop 3.1.6 Release

[Ted Wilmes]

Thanks Stephen, got ahead of myself there.  Yes, if folks need extra time,
let me know and we'll extend.

--Ted

On Fri, Feb 3, 2017 at 7:20 PM, Stephen Mallette 
wrote:

> Hey Ted - You're a little early as we agreed a while back to let two
> weekends pass from code freeze to VOTE day (maybe release docs need to be
> updated to reflect that). Not a big deal imo as I doubt there are many
> folks still testing on 3.1.6 at this point, so I'm fine to VOTE from here
> if everyone else is. If anyone feels like we need to extend the VOTEing
> time, just yell.  3.2.4 voting definitely shouldn't start until Monday.
>
> In the mean time, as it is right now:
>
> $ bin/validate-distribution.sh 3.1.6
>
> Validating binary distributions
>
> * downloading Apache TinkerPop Gremlin
> (apache-tinkerpop-gremlin-console-3.1.6-bin.zip)... OK
> * validating signatures and checksums ...
>   * PGP signature ... OK
>   * MD5 checksum ... OK
>   * SHA1 checksum ... OK
> * unzipping Apache TinkerPop Gremlin ... OK
> * validating Apache TinkerPop Gremlin's docs ... OK
> * validating Apache TinkerPop Gremlin's binaries ... OK
> * validating Apache TinkerPop Gremlin's legal files ...
>   * LICENSE ... OK
>   * NOTICE ... OK
> * validating Apache TinkerPop Gremlin's plugin directory ... OK
> * validating Apache TinkerPop Gremlin's lib directory ... OK
> * testing script evaluation ... OK
>
> * downloading Apache TinkerPop Gremlin
> (apache-tinkerpop-gremlin-server-3.1.6-bin.zip)... OK
> * validating signatures and checksums ...
>   * PGP signature ... OK
>   * MD5 checksum ... OK
>   * SHA1 checksum ... OK
> * unzipping Apache TinkerPop Gremlin ... OK
> * validating Apache TinkerPop Gremlin's docs ... OK
> * validating Apache TinkerPop Gremlin's binaries ... OK
> * validating Apache TinkerPop Gremlin's legal files ...
>   * LICENSE ... OK
>   * NOTICE ... OK
> * validating Apache TinkerPop Gremlin's plugin directory ... OK
> * validating Apache TinkerPop Gremlin's lib directory ... OK
>
> Validating source distribution
>
> * downloading Apache TinkerPop 3.1.6 (apache-tinkerpop-3.1.6-src.zip)...
> OK
> * validating signatures and checksums ...
>   * PGP signature ... OK
>   * MD5 checksum ... OK
>   * SHA1 checksum ... OK
> * unzipping Apache TinkerPop 3.1.6 ... OK
> * building project ... OK
>
> Note that I couldn't use the validate-distribution.sh on master for some
> reason - it failed - had to use the one in tp31 and the above was my output
> so I think all is good: Thanks for handling the release Ted - that's a big
> help to me and the community.
>
> VOTE +1
>
>
>
>
>
> On Feb 3, 2017 6:09 PM, "Ted Wilmes"  wrote:
>
> > Hello,
> >
> > We are happy to announce that TinkerPop 3.1.6 is ready for release.
> >
> > The release artifacts can be found at this location:
> > https://dist.apache.org/repos/dist/dev/tinkerpop/3.1.6/
> >
> > The source distribution is provided by:
> > apache-tinkerpop-3.1.6-src.zip
> >
> > Two binary distributions are provided for user convenience:
> > apache-tinkerpop-gremlin-console-3.1.6-bin.zip
> > apache-tinkerpop-gremlin-server-3.1.6-bin.zip
> >
> > The GPG key used to sign the release artifacts is available at:
> > https://dist.apache.org/repos/dist/dev/tinkerpop/KEYS
> >
> > The online docs can be found here:
> > http://tinkerpop.apache.org/docs/3.1.6/ (user docs)
> > http://tinkerpop.apache.org/docs/3.1.6/upgrade/ (upgrade docs)
> > http://tinkerpop.apache.org/javadocs/3.1.6/core/ (core javadoc)
> > http://tinkerpop.apache.org/javadocs/3.1.6/full/ (full javadoc)
> >
> > The tag in Apache Git can be found here:
> >
> > https://git-wip-us.apache.org/repos/asf?p=tinkerpop.git;a=ta
> > g;h=refs/tags/3.1.6
> >
> > The release notes are available here:
> >
> > https://github.com/apache/tinkerpop/blob/3.1.6/CHANGELOG.asc
> > iidoc#tinkerpop-316-release-date-february-3-2017
> >
> > The [VOTE] will be open for the next 72 hours --- closing Monday
> (2/6/2017)
> > at 5:00 PM CST.
> >
> > My vote is +1.
> >
> > Thank you very much,
> > Ted Wilmes
> >
>

[VOTE] TinkerPop 3.1.6 Release

[Ted Wilmes]

Hello,

We are happy to announce that TinkerPop 3.1.6 is ready for release.

The release artifacts can be found at this location:
https://dist.apache.org/repos/dist/dev/tinkerpop/3.1.6/

The source distribution is provided by:
apache-tinkerpop-3.1.6-src.zip

Two binary distributions are provided for user convenience:
apache-tinkerpop-gremlin-console-3.1.6-bin.zip
apache-tinkerpop-gremlin-server-3.1.6-bin.zip

The GPG key used to sign the release artifacts is available at:
https://dist.apache.org/repos/dist/dev/tinkerpop/KEYS

The online docs can be found here:
http://tinkerpop.apache.org/docs/3.1.6/ (user docs)
http://tinkerpop.apache.org/docs/3.1.6/upgrade/ (upgrade docs)
http://tinkerpop.apache.org/javadocs/3.1.6/core/ (core javadoc)
http://tinkerpop.apache.org/javadocs/3.1.6/full/ (full javadoc)

The tag in Apache Git can be found here:

https://git-wip-us.apache.org/repos/asf?p=tinkerpop.git;a=tag;h=refs/tags/3.1.6

The release notes are available here:

https://github.com/apache/tinkerpop/blob/3.1.6/CHANGELOG.asciidoc#tinkerpop-316-release-date-february-3-2017

The [VOTE] will be open for the next 72 hours --- closing Monday (2/6/2017)
at 5:00 PM CST.

My vote is +1.

Thank you very much,
Ted Wilmes

Re: ChooseStep & count type coercion

[Ted Wilmes]

Thanks guys.  Ticket created:
https://issues.apache.org/jira/browse/TINKERPOP-1596

--Ted

On Wed, Feb 1, 2017 at 10:37 AM, Marko Rodriguez 
wrote:

> I concur with Robert.
>
> Kuppitz has done a lot to help in this area with NumberHelper. We should
> make sure it is propagated throughout.
> https://github.com/apache/tinkerpop/blob/master/gremlin-
> core/src/main/java/org/apache/tinkerpop/gremlin/util/NumberHelper.java <
> https://github.com/apache/tinkerpop/blob/master/gremlin-
> core/src/main/java/org/apache/tinkerpop/gremlin/util/NumberHelper.java>
>
> Can you please make a ticket about your particular ChooseStep situation?
>
> https://issues.apache.org/jira/browse/TINKERPOP/ <
> https://issues.apache.org/jira/browse/TINKERPOP/?
> selectedTab=com.atlassian.jira.jira-projects-plugin:summary-panel>
>
> Thank you,
> Marko.
>
> http://markorodriguez.com
>
>
>
> > On Feb 1, 2017, at 8:03 AM, Robert Dale  wrote:
> >
> > It absolutely would make sense to treat numbers as numbers and not as
> data
> > structures.  This is one of those things that keeps gremlin tied to a
> Java
> > implementation and from being language-agnostic.
> >
> > Robert Dale
> >
> > On Wed, Feb 1, 2017 at 9:51 AM, Ted Wilmes  wrote:
> >
> >> Hello,
> >> I wrote a traversal using a choose that included a count in the
> branching
> >> traversal.  Here is a simplified version:
> >>
> >> g.V().choose(bothE().count()).option(1, constant(1)).option(3,
> >> constant(3))
> >>
> >> I wasn't getting any results and then realized none of the options would
> >> match because count produces a long.
> >> This is the correct behavior now and makes sense in the context of
> Java's
> >> type system but I was wondering if it
> >> wouldn't make sense to handle the type coercion from int to long so the
> >> user could use an integer?  I think this
> >> would be consistent with how other steps like 'is' works:
> >>
> >> gremlin> g.V().local(bothE().count()).is(3)
> >> ==>3
> >> ==>3
> >> ==>3
> >>
> >>
> >> Full example:
> >> gremlin> g = TinkerFactory.createModern().traversal()
> >> ==>graphtraversalsource[tinkergraph[vertices:6 edges:6], standard]
> >> gremlin> g.V().choose(bothE().count()).option(1, constant(1)).option(3,
> >> constant(3))
> >> gremlin> g.V().choose(bothE().count()).option(1l,
> constant(1)).option(3l,
> >> constant(3))
> >> ==>3
> >> ==>1
> >> ==>3
> >> ==>3
> >> ==>1
> >> ==>1
> >>
> >>
> >> Thanks,
> >> Ted
> >>
>
>

[jira] [Created] (TINKERPOP-1620) Choose with count branch traversal type coercion

[Ted Wilmes (JIRA)]

Ted Wilmes created TINKERPOP-1620:
-

 Summary: Choose with count branch traversal type coercion
 Key: TINKERPOP-1620
 URL: https://issues.apache.org/jira/browse/TINKERPOP-1620
 Project: TinkerPop
  Issue Type: Bug
  Components: process
Affects Versions: 3.2.3
Reporter: Ted Wilmes
Assignee: Ted Wilmes


A {{ChooseStep}} with a {{count}} branching traversal is currently sensitive to 
whether or not the {{option}} keys are {{long}} or {{int}}.  This results in 
the following behavior:

{code}
gremlin> g = TinkerFactory.createModern().traversal()
==>graphtraversalsource[tinkergraph[vertices:6 edges:6], standard]
gremlin> g.V().choose(bothE().count()).option(1, constant(1)).option(3, 
constant(3))
gremlin> g.V().choose(bothE().count()).option(1l, constant(1)).option(3l, 
constant(3))
==>3
==>1
==>3
==>3
==>1
==>1
{code}

The branch traversal results if, numeric, should be evaluated against the 
options using {{NumberHelper}} so as to be consistent with other steps.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

ChooseStep & count type coercion

[Ted Wilmes]

Hello,
I wrote a traversal using a choose that included a count in the branching
traversal.  Here is a simplified version:

 g.V().choose(bothE().count()).option(1, constant(1)).option(3, constant(3))

I wasn't getting any results and then realized none of the options would
match because count produces a long.
This is the correct behavior now and makes sense in the context of Java's
type system but I was wondering if it
wouldn't make sense to handle the type coercion from int to long so the
user could use an integer?  I think this
would be consistent with how other steps like 'is' works:

gremlin> g.V().local(bothE().count()).is(3)
==>3
==>3
==>3


Full example:
gremlin> g = TinkerFactory.createModern().traversal()
==>graphtraversalsource[tinkergraph[vertices:6 edges:6], standard]
gremlin> g.V().choose(bothE().count()).option(1, constant(1)).option(3,
constant(3))
gremlin> g.V().choose(bothE().count()).option(1l, constant(1)).option(3l,
constant(3))
==>3
==>1
==>3
==>3
==>1
==>1


Thanks,
Ted

[jira] (TINKERPOP-1597) PathRetractionStrategy messing up certain traversals

[Ted Wilmes (JIRA)]

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

Ted Wilmes closed TINKERPOP-1597.
-
Resolution: Fixed

A `PathRetractionStrategy` test has been added to verify the nested `dedup` 
does not drop labels.  The new `OptionalTest` test method provided by 
[~dkuppitz] is affected by TINKERPOP-1619 so it was not merged as part of this 
ticket.

> PathRetractionStrategy messing up certain traversals
> 
>
> Key: TINKERPOP-1597
> URL: https://issues.apache.org/jira/browse/TINKERPOP-1597
> Project: TinkerPop
>  Issue Type: Bug
>  Components: process
>Affects Versions: 3.3.0
>Reporter: Daniel Kuppitz
>Assignee: Ted Wilmes
> Fix For: 3.3.0
>
>
> There are certain types of traversals that do not work when 
> {{PathRetractionStrategy}} is included. This ticket discusses one specific 
> case that is only reproducible in {{3.3.0-SNAPSHOT}} / current {{master/}}.
> Here's the traversal and the expected result:
> {noformat}
> gremlin> 
> g.withoutStrategies(PathRetractionStrategy).V(1,2).as("a").optional(bothE().dedup().as("b")).choose(select("b").select("a","b").,
>  project("a").by(select("a")))
> ==>[a:v[2]]
> ==>[a:v[1],b:e[9][1-created->3]]
> ==>[a:v[1],b:e[7][1-knows->2]]
> ==>[a:v[1],b:e[8][1-knows->4]]
> {noformat}
> With {{PathRetractionStrategy}} included we get:
> {noformat}
> gremlin> 
> g.V(1,2).as("a").optional(bothE().dedup().as("b")).choose(select("b"), 
> select("a","b"), project("a").by(select("a")))
> ==>[a:v[2]]
> {noformat}
> What's interesting is, that the following 2 traversals compile to the same 
> final traversal (according to {{.explain()}}):
> {noformat}
> g.withoutStrategies(PathRetractionStrategy).V(1,2).as("a").optional(bothE().dedup().as("b")).choose(select("b").barrier(2500),
>  select("a","b").barrier(2500), project("a").by(select("a").barrier(2500)))
> g.V(1,2).as("a").optional(bothE().dedup().as("b")).choose(select("b"), 
> select("a","b"), project("a").by(select("a")))
> {noformat}
> ...but the one w/ {{PathRetractionStrategy}} still returns the wrong result, 
> while the other traversal returns the expected result.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] (TINKERPOP-1619) TinkerGraphComputer worker count affects OptionalStep query results

[Ted Wilmes (JIRA)]

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

Ted Wilmes commented on TINKERPOP-1619:
---

Ok, that makes sense.  I was wondering if when I bumped the worker count to 4 
the duplicate edges were no longer being processed by the same worker and the 
dedup wasn't global.  Kuppitz had a variation of this query as a test case for 
TINKERPOP-1597 so I'll go ahead and close that one out now.

> TinkerGraphComputer worker count affects OptionalStep query results
> ---
>
> Key: TINKERPOP-1619
> URL: https://issues.apache.org/jira/browse/TINKERPOP-1619
> Project: TinkerPop
>  Issue Type: Bug
>  Components: process
>Affects Versions: 3.3.0
>Reporter: Ted Wilmes
>
> I found that when I bump the worker count up to 4 on my local box, the dedup 
> nested in the optional appears to not be handled correctly.
> {code}
> gremlin> g = TinkerFactory.createModern().traversal()
> ==>graphtraversalsource[tinkergraph[vertices:6 edges:6], standard]
> gremlin> g.withComputer(Computer.compute().workers(3)).V(1, 
> 2).optional(bothE().dedup())
> ==>e[9][1-created->3]
> ==>e[7][1-knows->2]
> ==>e[8][1-knows->4]
> ==>v[2]
> gremlin> g.withComputer(Computer.compute().workers(4)).V(1, 
> 2).optional(bothE().dedup())
> ==>e[9][1-created->3]
> ==>e[7][1-knows->2]
> ==>e[7][1-knows->2]
> ==>e[8][1-knows->4]
> {code}



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] (TINKERPOP-1619) TinkerGraphComputer worker count affects OptionalStep query results

[Ted Wilmes (JIRA)]

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

Ted Wilmes commented on TINKERPOP-1619:
---

That's a good question, {{tp32}} throws this exception with that query:

{code}
gremlin> g = TinkerFactory.createModern().traversal()
gremlin> g.withComputer(Computer.compute().workers(3)).V(1, 
2).optional(bothE().dedup())
   [33/1896]
java.lang.RuntimeException: java.lang.IllegalStateException: 
java.lang.IllegalArgumentException: The provided key is not a memory compute 
key: 1.2.1(1.1.0(2.0.0()))
Type ':help' or ':h' for help.
Display stack trace? [yN]y
java.lang.IllegalStateException: java.lang.RuntimeException: 
java.lang.IllegalStateException: java.lang.IllegalArgumentException: The 
provided key is not a memory compute key: 1.2.1(1.1.0(2.0.0()))
at 
org.apache.tinkerpop.gremlin.process.computer.traversal.step.map.VertexProgramStep.processNextStart(VertexProgramStep.java:88)
at 
org.apache.tinkerpop.gremlin.process.traversal.step.util.AbstractStep.hasNext(AbstractStep.java:143)
at 
org.apache.tinkerpop.gremlin.process.traversal.step.util.ExpandableStepIterator.next(ExpandableStepIterator.java:50)
at 
org.apache.tinkerpop.gremlin.process.computer.traversal.step.map.ComputerResultStep.processNextStart(ComputerResultStep.java:68)
at 
org.apache.tinkerpop.gremlin.process.traversal.step.util.AbstractStep.hasNext(AbstractStep.java:143)
at 
org.apache.tinkerpop.gremlin.process.traversal.util.DefaultTraversal.hasNext(DefaultTraversal.java:184)
at 
org.apache.tinkerpop.gremlin.console.Console$_closure3.doCall(Console.groovy:237)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at 
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at 
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:498)
at 
org.codehaus.groovy.reflection.CachedMethod.invoke(CachedMethod.java:93)
at groovy.lang.MetaMethod.doMethodInvoke(MetaMethod.java:325)
at 
org.codehaus.groovy.runtime.metaclass.ClosureMetaClass.invokeMethod(ClosureMetaClass.java:294)
at groovy.lang.MetaClassImpl.invokeMethod(MetaClassImpl.java:1027)
at 
org.codehaus.groovy.tools.shell.Groovysh.setLastResult(Groovysh.groovy:447)
at org.codehaus.groovy.tools.shell.Groovysh.execute(Groovysh.groovy:191)
at 
org.apache.tinkerpop.gremlin.console.GremlinGroovysh.super$3$execute(GremlinGroovysh.groovy)
at sun.reflect.GeneratedMethodAccessor14.invoke(Unknown Source)
at 
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:498)
at 
org.codehaus.groovy.reflection.CachedMethod.invoke(CachedMethod.java:93)
at groovy.lang.MetaMethod.doMethodInvoke(MetaMethod.java:325)
at groovy.lang.MetaClassImpl.invokeMethod(MetaClassImpl.java:1218)
at 
org.codehaus.groovy.runtime.ScriptBytecodeAdapter.invokeMethodOnSuperN(ScriptBytecodeAdapter.java:132)
at 
org.apache.tinkerpop.gremlin.console.GremlinGroovysh.execute(GremlinGroovysh.groovy:72)
at org.codehaus.groovy.tools.shell.Shell.leftShift(Shell.groovy:122)
at 
org.codehaus.groovy.tools.shell.ShellRunner.work(ShellRunner.groovy:95)
at 
org.codehaus.groovy.tools.shell.InteractiveShellRunner.super$2$work(InteractiveShellRunner.groovy)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at 
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at 
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:498)
at 
org.codehaus.groovy.reflection.CachedMethod.invoke(CachedMethod.java:93)
at groovy.lang.MetaMethod.doMethodInvoke(MetaMethod.java:325)
at groovy.lang.MetaClassImpl.invokeMethod(MetaClassImpl.java:1218)
at 
org.codehaus.groovy.runtime.ScriptBytecodeAdapter.invokeMethodOnSuperN(ScriptBytecodeAdapter.java:132)
at 
org.codehaus.groovy.runtime.ScriptBytecodeAdapter.invokeMethodOnSuper0(ScriptBytecodeAdapter.java:152)
at 
org.codehaus.groovy.tools.shell.InteractiveShellRunner.work(InteractiveShellRunner.groovy:124)
at 
org.codehaus.groovy.tools.shell.ShellRunner.run(ShellRunner.groovy:59)
at 
org.codehaus.groovy.tools.shell.InteractiveShellRunner.super$2$run(InteractiveShellRunner.groovy)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at 
sun.reflect.NativeMethodAccessorImpl.invo

[jira] (TINKERPOP-1619) TinkerGraphComputer worker count affects OptionalStep query results

[Ted Wilmes (JIRA)]

Ted Wilmes created TINKERPOP-1619:
-

 Summary: TinkerGraphComputer worker count affects OptionalStep 
query results
 Key: TINKERPOP-1619
 URL: https://issues.apache.org/jira/browse/TINKERPOP-1619
 Project: TinkerPop
  Issue Type: Bug
  Components: process
Affects Versions: 3.3.0
Reporter: Ted Wilmes


I found that when I bump the worker count up to 4 on my local box, the dedup 
nested in the optional appears to not be handled correctly.

{code}
gremlin> g = TinkerFactory.createModern().traversal()
==>graphtraversalsource[tinkergraph[vertices:6 edges:6], standard]
gremlin> g.withComputer(Computer.compute().workers(3)).V(1, 
2).optional(bothE().dedup())
==>e[9][1-created->3]
==>e[7][1-knows->2]
==>e[8][1-knows->4]
==>v[2]
gremlin> g.withComputer(Computer.compute().workers(4)).V(1, 
2).optional(bothE().dedup())
==>e[9][1-created->3]
==>e[7][1-knows->2]
==>e[7][1-knows->2]
==>e[8][1-knows->4]
{code}



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

Code Freeze 3.1.6

[Ted Wilmes]

Hello,
We are now under code freeze for 3.1.6.  Updated snapshots have been
published and I'll be doing one more publish later in the week with the
finalized changelog.  Let me know if anything comes up in the meantime and
we'll get it incorporated.

Thanks,
Ted

[jira] [Closed] (TINKERPOP-1583) PathRetractionStrategy retracts keys that are actually needed

[Ted Wilmes (JIRA)]

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

Ted Wilmes closed TINKERPOP-1583.
-
   Resolution: Fixed
Fix Version/s: 3.2.4

> PathRetractionStrategy retracts keys that are actually needed
> -
>
> Key: TINKERPOP-1583
> URL: https://issues.apache.org/jira/browse/TINKERPOP-1583
> Project: TinkerPop
>  Issue Type: Bug
>  Components: process
>Affects Versions: 3.2.3
>Reporter: Geoff Reedy
>Assignee: Ted Wilmes
> Fix For: 3.2.4
>
>
> We've seen this specifically for labels used in the until modulator of repeat 
> but I suspect it happens for other modulators as well. Here's a test case:
> {code}
> graph = TinkerGraph.open()
> g = graph.traversal()
> g.addV().as("first").repeat(addE("next").to(addV()).inV()).times(5).addE("next").to(select("first")).iterate()
> g.V().limit(1).as('z').out().repeat(store('seen').out().where(without('seen'))).until(where(eq('z')))
> {code}
> complains there is no z-key
> I tired to fix it myself and submit a pull request but I found the 
> implementation of PathRetractionStrategy confusing.
> One thing I noticed is that it seems the set of labels a step needs present 
> in order to work properly is determined external to the steps and that code 
> includes a lot of type-tests. If that logic were pushed down into the step 
> implementations I think fixing the repeat case would be easier and it would 
> be possible for extension steps to work properly with this strategy 
> (currently it seems they can't because of the closed-world assumption 
> inherent in the type-casing).



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Closed] (TINKERPOP-1433) Add steps to dev docs to help committers get their keys in order

[Ted Wilmes (JIRA)]

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

Ted Wilmes closed TINKERPOP-1433.
-
   Resolution: Fixed
Fix Version/s: 3.2.4
   3.3.0

> Add steps to dev docs to help committers get their keys in order
> 
>
> Key: TINKERPOP-1433
> URL: https://issues.apache.org/jira/browse/TINKERPOP-1433
> Project: TinkerPop
>  Issue Type: Improvement
>  Components: documentation
>Affects Versions: 3.1.4
>    Reporter: Ted Wilmes
>Assignee: Ted Wilmes
> Fix For: 3.3.0, 3.2.4
>
>
> I'll add some steps to help committers navigate the Apache PGP docs and will 
> include any TinkerPop specific steps (update validate-distribution.sh).



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

Re: [DISCUSS] Release 3.2.4 and 3.1.6

[Ted Wilmes]

I've only attempted running it from the docker build thus far.  I'm
thinking it has
to be some odd local environment issue.  I'll try again here in a bit and
see if I
can nail down the root cause.

On Thu, Jan 26, 2017 at 8:29 AM, Stephen Mallette 
wrote:

> Thanks Ted. Does the GLV issue have something to do with your python setup?
> or is it a problem with the docs themselves?
>
> On Thu, Jan 26, 2017 at 9:26 AM, Ted Wilmes  wrote:
>
> > Jason,
> > I ctr'ed an update to docs adding instructions for getting keys setup.
> For
> > some reason
> > I'm getting consistent failures in the GLV portion of the docs when I'm
> > generation them so I haven't
> > published updated snapshots yet.  For the time being though, if you
> haven't
> > started the key process
> > yet, you can see the info here under Release Manager Requirements:
> > https://github.com/apache/tinkerpop/blob/master/docs/
> > src/dev/developer/release.asciidoc
> >
> > --Ted
> >
> > On Wed, Jan 25, 2017 at 5:13 PM, Stephen Mallette 
> > wrote:
> >
> > > sure - please put that in the prefix of the PR title so it links back
> to
> > > that original jira ticket
> > >
> > > On Wed, Jan 25, 2017 at 5:17 PM, Paul A. Jackson 
> > > wrote:
> > >
> > > > OK, low-risk PR coming for OLTP part. Should I reuse TINKERPOP-1589?
> > > >
> > > > Thanks,
> > > > -Paul
> > > >
> > > > -Original Message-
> > > > From: Stephen Mallette [mailto:spmalle...@gmail.com]
> > > > Sent: Wednesday, January 25, 2017 5:07 PM
> > > > To: dev@tinkerpop.apache.org
> > > > Subject: Re: [DISCUSS] Release 3.2.4 and 3.1.6
> > > >
> > > > Being as close as we are to our code freeze/test week, I'd say that
> > big,
> > > > complex or otherwise risky changes probably won't collect too many +1
> > > > reviews at this point. If the OLTP improvement is small/concise (low
> > > risk),
> > > > it could be considered for inclusion in 3.2.4.
> > > >
> > > > On Wed, Jan 25, 2017 at 5:00 PM, Paul A. Jackson <
> paul.jack...@pb.com>
> > > > wrote:
> > > >
> > > > > I have something that fixes OLTP. I haven't worked with OLAP and it
> > > > > looks like the changes for this will be extensive, touching
> > > > > IteratorUtils and so on.
> > > > >
> > > > > Would you be interested in a PR for just the OLTP part?
> > > > >
> > > > >
> > > > > -Original Message-
> > > > > From: Stephen Mallette [mailto:spmalle...@gmail.com]
> > > > > Sent: Wednesday, January 25, 2017 3:58 PM
> > > > > To: dev@tinkerpop.apache.org
> > > > > Subject: Re: [DISCUSS] Release 3.2.4 and 3.1.6
> > > > >
> > > > > in his case, it should go to tp32.
> > > > >
> > > > > On Wed, Jan 25, 2017 at 3:56 PM, Paul A. Jackson <
> > paul.jack...@pb.com>
> > > > > wrote:
> > > > >
> > > > > > For what branch should a pull request be submitted?
> > > > > >
> > > > > >
> > > > > > -Original Message-
> > > > > > From: Stephen Mallette [mailto:spmalle...@gmail.com]
> > > > > > Sent: Wednesday, January 25, 2017 3:41 PM
> > > > > > To: dev@tinkerpop.apache.org
> > > > > > Subject: Re: [DISCUSS] Release 3.2.4 and 3.1.6
> > > > > >
> > > > > > I went with the most obvious implementation place for
> > > > CloseableIterator.
> > > > > > If you see other spots where you could make an argument that it
> > > > > > would make sense to add it then feel free to offer a pull request
> > > > > > and we can get it reviewed. I didn't look into your VertexStep
> > > > > > suggestion too deeply, but a quick review seems to have me
> thinking
> > > > > > that it would make
> > > > > sense to do that.
> > > > > > Basically anywhere that a step interacts with the structure API
> > > > > > seems like it would be a candidate for CloseableIterator to be
> > > > > > implemented as it is in GraphStep.
> > > > > >
> > > > > > On Wed, Jan 25, 2017 at 3:30 PM, Paul A. Jackson
> > > > > &g

Re: [DISCUSS] Release 3.2.4 and 3.1.6

[Ted Wilmes]

Jason,
I ctr'ed an update to docs adding instructions for getting keys setup.  For
some reason
I'm getting consistent failures in the GLV portion of the docs when I'm
generation them so I haven't
published updated snapshots yet.  For the time being though, if you haven't
started the key process
yet, you can see the info here under Release Manager Requirements:
https://github.com/apache/tinkerpop/blob/master/docs/src/dev/developer/release.asciidoc

--Ted

On Wed, Jan 25, 2017 at 5:13 PM, Stephen Mallette 
wrote:

> sure - please put that in the prefix of the PR title so it links back to
> that original jira ticket
>
> On Wed, Jan 25, 2017 at 5:17 PM, Paul A. Jackson 
> wrote:
>
> > OK, low-risk PR coming for OLTP part. Should I reuse TINKERPOP-1589?
> >
> > Thanks,
> > -Paul
> >
> > -Original Message-
> > From: Stephen Mallette [mailto:spmalle...@gmail.com]
> > Sent: Wednesday, January 25, 2017 5:07 PM
> > To: dev@tinkerpop.apache.org
> > Subject: Re: [DISCUSS] Release 3.2.4 and 3.1.6
> >
> > Being as close as we are to our code freeze/test week, I'd say that big,
> > complex or otherwise risky changes probably won't collect too many +1
> > reviews at this point. If the OLTP improvement is small/concise (low
> risk),
> > it could be considered for inclusion in 3.2.4.
> >
> > On Wed, Jan 25, 2017 at 5:00 PM, Paul A. Jackson 
> > wrote:
> >
> > > I have something that fixes OLTP. I haven't worked with OLAP and it
> > > looks like the changes for this will be extensive, touching
> > > IteratorUtils and so on.
> > >
> > > Would you be interested in a PR for just the OLTP part?
> > >
> > >
> > > -Original Message-
> > > From: Stephen Mallette [mailto:spmalle...@gmail.com]
> > > Sent: Wednesday, January 25, 2017 3:58 PM
> > > To: dev@tinkerpop.apache.org
> > > Subject: Re: [DISCUSS] Release 3.2.4 and 3.1.6
> > >
> > > in his case, it should go to tp32.
> > >
> > > On Wed, Jan 25, 2017 at 3:56 PM, Paul A. Jackson 
> > > wrote:
> > >
> > > > For what branch should a pull request be submitted?
> > > >
> > > >
> > > > -Original Message-
> > > > From: Stephen Mallette [mailto:spmalle...@gmail.com]
> > > > Sent: Wednesday, January 25, 2017 3:41 PM
> > > > To: dev@tinkerpop.apache.org
> > > > Subject: Re: [DISCUSS] Release 3.2.4 and 3.1.6
> > > >
> > > > I went with the most obvious implementation place for
> > CloseableIterator.
> > > > If you see other spots where you could make an argument that it
> > > > would make sense to add it then feel free to offer a pull request
> > > > and we can get it reviewed. I didn't look into your VertexStep
> > > > suggestion too deeply, but a quick review seems to have me thinking
> > > > that it would make
> > > sense to do that.
> > > > Basically anywhere that a step interacts with the structure API
> > > > seems like it would be a candidate for CloseableIterator to be
> > > > implemented as it is in GraphStep.
> > > >
> > > > On Wed, Jan 25, 2017 at 3:30 PM, Paul A. Jackson
> > > > 
> > > > wrote:
> > > >
> > > > > So, I modified my code to work with CloseableIterator. I was
> > > > > hoping this would be honored in more places than it is.
> > > > >
> > > > > Where it does work is if the user of a traversal calls
> > > > > traversal.close() all the steps will get closed, including the
> > > > > typically
> > > > first GraphStep.
> > > > > GraphStep in turn checks whether the iterator that was provided by
> > > > > iteratorSupplier implements CloseableIterator and if so, closes
> > > > > it, and this is good.
> > > > >
> > > > > What I was hoping, in addition, though, was when
> > > > > VertexStep.flatMap() (or anything else) calls Vertex.vertices() or
> > > > > Vertex.edges() that before it finishes with the iterator it also
> > > > > make the same check for CloseableIterator and call close().
> > > > >
> > > > > Thoughts?
> > > > >
> > > > > -Paul
> > > > >
> > > > > -Original Message-
> > > > > From: Paul A. Jackson [mailto:paul.jack...@pb.com]
> > > > > Sent: Tuesday, January 24, 2017 3:01 PM
> > > > > To: dev@tinkerpop.apache.org
> > > > > Subject: RE: [DISCUSS] Release 3.2.4 and 3.1.6
> > > > >
> > > > > Great. I'll try it out.
> > > > >
> > > > > -Paul
> > > > >
> > > > >
> > > > > -Original Message-
> > > > > From: Stephen Mallette [mailto:spmalle...@gmail.com]
> > > > > Sent: Tuesday, January 24, 2017 2:54 PM
> > > > > To: dev@tinkerpop.apache.org
> > > > > Subject: Re: [DISCUSS] Release 3.2.4 and 3.1.6
> > > > >
> > > > > no - it's in 3.2.4 and merged forward to 3.3.0:
> > > > >
> > > > > https://github.com/apache/tinkerpop/blob/e3889bf2401b42c3afbc85eab
> > > > > c2 fb c ebf2588974/gremlin-core/src/main/java/org/apache/
> > > > > tinkerpop/gremlin/structure/util/CloseableIterator.java
> > > > >
> > > > > On Tue, Jan 24, 2017 at 2:52 PM, Paul A. Jackson
> > > > > 
> > > > > wrote:
> > > > >
> > > > > > Is CloseableIterator only in the 3.3 branch?
> > > > > >
> > > > > > -Paul
> > > > > >
> > > > > >
> > > > > > -Original Message

Re: [DISCUSS] Release 3.2.4 and 3.1.6

[Ted Wilmes]

Code freeze Friday sounds good to me.  Yes, I'll be submitting a PR for the
PathRetractionStrategy bugs (1583 & 1597).

I can take the 3.1.6 release.

--Ted

On Mon, Jan 23, 2017 at 9:03 AM, Marko Rodriguez 
wrote:

> @Ted — Do you think you can fix the PathRetractionStrategy bugs for this
> release, please?
>
> Marko.
>
> http://markorodriguez.com
>
>
>
> > On Jan 23, 2017, at 7:57 AM, Stephen Mallette 
> wrote:
> >
> > It's been a while since we've had a release (October 2016) and given the
> > importance of the recent critical security fix from Groovy 2.4.8 I think
> > it's worth getting some new versions out there. I'm not sure what
> everyone
> > is working on or has concerns about, but after the PRs that are out there
> > for tp32 get merged (especially https://github.com/apache/
> tinkerpop/pull/541)
> > I don't really have anything else critical for those versions. Please
> call
> > out any issues that might be important for this release on this thread.
> >
> > I don't think we should worry about doing a milestone release of 3.3.0
> yet.
> > I'd like to see some more change go into that branch before we do that,
> but
> > if others feel differently and would like to offer an argument I'd be
> open
> > to the idea.
> >
> > I propose we focus on a release of 3.1.6 and 3.2.4 in two weeks time with
> > the code freeze going into place at end of day friday of this week
> (January
> > 27, 2017). If there are no objections in the next three days (Thursday,
> > January 26, 2017, 10:00am), let's assume lazy consensus and move forward
> > with that plan.
> >
> > Assuming we do move forward with a release, are there any volunteers for
> > release manager?
>
>

[jira] [Comment Edited] (TINKERPOP-1597) PathRetractionStrategy messing up certain traversals

[Ted Wilmes (JIRA)]

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

Ted Wilmes edited comment on TINKERPOP-1597 at 1/13/17 4:02 PM:


The {{dedup}} step is incorrectly dropping labels because there is a bug 
related to child traversals.  I'll clean up my quick and dirty test fix and 
submit a PR.


was (Author: twilmes):
The {{dedup}} step is incorrectly dropping labels because their is a bug 
related to child traversals.  I'll clean up my quick and dirty test fix and 
submit a PR.

> PathRetractionStrategy messing up certain traversals
> 
>
> Key: TINKERPOP-1597
> URL: https://issues.apache.org/jira/browse/TINKERPOP-1597
> Project: TinkerPop
>  Issue Type: Bug
>  Components: process
>Affects Versions: 3.3.0
>Reporter: Daniel Kuppitz
>Assignee: Ted Wilmes
>
> There are certain types of traversals that do not work when 
> {{PathRetractionStrategy}} is included. This ticket discusses one specific 
> case that is only reproducible in {{3.3.0-SNAPSHOT}} / current {{master/}}.
> Here's the traversal and the expected result:
> {noformat}
> gremlin> 
> g.withoutStrategies(PathRetractionStrategy).V(1,2).as("a").optional(bothE().dedup().as("b")).choose(select("b").select("a","b").,
>  project("a").by(select("a")))
> ==>[a:v[2]]
> ==>[a:v[1],b:e[9][1-created->3]]
> ==>[a:v[1],b:e[7][1-knows->2]]
> ==>[a:v[1],b:e[8][1-knows->4]]
> {noformat}
> With {{PathRetractionStrategy}} included we get:
> {noformat}
> gremlin> 
> g.V(1,2).as("a").optional(bothE().dedup().as("b")).choose(select("b"), 
> select("a","b"), project("a").by(select("a")))
> ==>[a:v[2]]
> {noformat}
> What's interesting is, that the following 2 traversals compile to the same 
> final traversal (according to {{.explain()}}):
> {noformat}
> g.withoutStrategies(PathRetractionStrategy).V(1,2).as("a").optional(bothE().dedup().as("b")).choose(select("b").barrier(2500),
>  select("a","b").barrier(2500), project("a").by(select("a").barrier(2500)))
> g.V(1,2).as("a").optional(bothE().dedup().as("b")).choose(select("b"), 
> select("a","b"), project("a").by(select("a")))
> {noformat}
> ...but the one w/ {{PathRetractionStrategy}} still returns the wrong result, 
> while the other traversal returns the expected result.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (TINKERPOP-1597) PathRetractionStrategy messing up certain traversals

[Ted Wilmes (JIRA)]

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

Ted Wilmes commented on TINKERPOP-1597:
---

The {{dedup}} step is incorrectly dropping labels because their is a bug 
related to child traversals.  I'll clean up my quick and dirty test fix and 
submit a PR.

> PathRetractionStrategy messing up certain traversals
> 
>
> Key: TINKERPOP-1597
> URL: https://issues.apache.org/jira/browse/TINKERPOP-1597
> Project: TinkerPop
>  Issue Type: Bug
>  Components: process
>Affects Versions: 3.3.0
>Reporter: Daniel Kuppitz
>Assignee: Ted Wilmes
>
> There are certain types of traversals that do not work when 
> {{PathRetractionStrategy}} is included. This ticket discusses one specific 
> case that is only reproducible in {{3.3.0-SNAPSHOT}} / current {{master/}}.
> Here's the traversal and the expected result:
> {noformat}
> gremlin> 
> g.withoutStrategies(PathRetractionStrategy).V(1,2).as("a").optional(bothE().dedup().as("b")).choose(select("b").select("a","b").,
>  project("a").by(select("a")))
> ==>[a:v[2]]
> ==>[a:v[1],b:e[9][1-created->3]]
> ==>[a:v[1],b:e[7][1-knows->2]]
> ==>[a:v[1],b:e[8][1-knows->4]]
> {noformat}
> With {{PathRetractionStrategy}} included we get:
> {noformat}
> gremlin> 
> g.V(1,2).as("a").optional(bothE().dedup().as("b")).choose(select("b"), 
> select("a","b"), project("a").by(select("a")))
> ==>[a:v[2]]
> {noformat}
> What's interesting is, that the following 2 traversals compile to the same 
> final traversal (according to {{.explain()}}):
> {noformat}
> g.withoutStrategies(PathRetractionStrategy).V(1,2).as("a").optional(bothE().dedup().as("b")).choose(select("b").barrier(2500),
>  select("a","b").barrier(2500), project("a").by(select("a").barrier(2500)))
> g.V(1,2).as("a").optional(bothE().dedup().as("b")).choose(select("b"), 
> select("a","b"), project("a").by(select("a")))
> {noformat}
> ...but the one w/ {{PathRetractionStrategy}} still returns the wrong result, 
> while the other traversal returns the expected result.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Assigned] (TINKERPOP-1597) PathRetractionStrategy messing up certain traversals

[Ted Wilmes (JIRA)]

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

Ted Wilmes reassigned TINKERPOP-1597:
-

Assignee: Ted Wilmes

> PathRetractionStrategy messing up certain traversals
> 
>
> Key: TINKERPOP-1597
> URL: https://issues.apache.org/jira/browse/TINKERPOP-1597
> Project: TinkerPop
>  Issue Type: Bug
>  Components: process
>Affects Versions: 3.3.0
>Reporter: Daniel Kuppitz
>Assignee: Ted Wilmes
>
> There are certain types of traversals that do not work when 
> {{PathRetractionStrategy}} is included. This ticket discusses one specific 
> case that is only reproducible in {{3.3.0-SNAPSHOT}} / current {{master/}}.
> Here's the traversal and the expected result:
> {noformat}
> gremlin> 
> g.withoutStrategies(PathRetractionStrategy).V(1,2).as("a").optional(bothE().dedup().as("b")).choose(select("b").select("a","b").,
>  project("a").by(select("a")))
> ==>[a:v[2]]
> ==>[a:v[1],b:e[9][1-created->3]]
> ==>[a:v[1],b:e[7][1-knows->2]]
> ==>[a:v[1],b:e[8][1-knows->4]]
> {noformat}
> With {{PathRetractionStrategy}} included we get:
> {noformat}
> gremlin> 
> g.V(1,2).as("a").optional(bothE().dedup().as("b")).choose(select("b"), 
> select("a","b"), project("a").by(select("a")))
> ==>[a:v[2]]
> {noformat}
> What's interesting is, that the following 2 traversals compile to the same 
> final traversal (according to {{.explain()}}):
> {noformat}
> g.withoutStrategies(PathRetractionStrategy).V(1,2).as("a").optional(bothE().dedup().as("b")).choose(select("b").barrier(2500),
>  select("a","b").barrier(2500), project("a").by(select("a").barrier(2500)))
> g.V(1,2).as("a").optional(bothE().dedup().as("b")).choose(select("b"), 
> select("a","b"), project("a").by(select("a")))
> {noformat}
> ...but the one w/ {{PathRetractionStrategy}} still returns the wrong result, 
> while the other traversal returns the expected result.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Created] (TINKERPOP-1596) TinkerGraphComputer does not shutdown ComputerService Executor

[Ted Wilmes (JIRA)]

Ted Wilmes created TINKERPOP-1596:
-

 Summary: TinkerGraphComputer does not shutdown ComputerService 
Executor
 Key: TINKERPOP-1596
 URL: https://issues.apache.org/jira/browse/TINKERPOP-1596
 Project: TinkerPop
  Issue Type: Bug
  Components: tinkergraph
Affects Versions: 3.2.3
Reporter: Ted Wilmes
Assignee: Ted Wilmes


I haven't seen any issues in normal usage, but while benchmarking 
`TinkerGraphComputer` with JMH, I noticed the forked JVM was hanging and had to 
be forcibly killed by JMH.

{code}
Thread[TinkerGraphComputer-boss,5,main]
  at sun.misc.Unsafe.park(Native Method)
  at java.util.concurrent.locks.LockSupport.park(LockSupport.java:175)
  at 
java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject.await(AbstractQueuedSynchronizer.java:2039)
  at java.util.concurrent.LinkedBlockingQueue.take(LinkedBlockingQueue.java:442)
  at 
java.util.concurrent.ThreadPoolExecutor.getTask(ThreadPoolExecutor.java:1067)
  at 
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1127)
  at 
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
  at java.lang.Thread.run(Thread.java:745)



{code}

The {{TinkerWorkerPool}} is being closed but not the {{ComputerService}} which 
causes the hang.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Work started] (TINKERPOP-1583) PathRetractionStrategy retracts keys that are actually needed

[Ted Wilmes (JIRA)]

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

Work on TINKERPOP-1583 started by Ted Wilmes.
-
> PathRetractionStrategy retracts keys that are actually needed
> -
>
> Key: TINKERPOP-1583
> URL: https://issues.apache.org/jira/browse/TINKERPOP-1583
> Project: TinkerPop
>  Issue Type: Bug
>  Components: process
>Affects Versions: 3.2.3
>Reporter: Geoff Reedy
>Assignee: Ted Wilmes
>
> We've seen this specifically for labels used in the until modulator of repeat 
> but I suspect it happens for other modulators as well. Here's a test case:
> {code}
> graph = TinkerGraph.open()
> g = graph.traversal()
> g.addV().as("first").repeat(addE("next").to(addV()).inV()).times(5).addE("next").to(select("first")).iterate()
> g.V().limit(1).as('z').out().repeat(store('seen').out().where(without('seen'))).until(where(eq('z')))
> {code}
> complains there is no z-key
> I tired to fix it myself and submit a pull request but I found the 
> implementation of PathRetractionStrategy confusing.
> One thing I noticed is that it seems the set of labels a step needs present 
> in order to work properly is determined external to the steps and that code 
> includes a lot of type-tests. If that logic were pushed down into the step 
> implementations I think fixing the repeat case would be easier and it would 
> be possible for extension steps to work properly with this strategy 
> (currently it seems they can't because of the closed-world assumption 
> inherent in the type-casing).



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (TINKERPOP-1583) PathRetractionStrategy retracts keys that are actually needed

[Ted Wilmes (JIRA)]

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

Ted Wilmes commented on TINKERPOP-1583:
---

Thanks for reporting this [~gereedy].  I'll take a look.

> PathRetractionStrategy retracts keys that are actually needed
> -
>
> Key: TINKERPOP-1583
> URL: https://issues.apache.org/jira/browse/TINKERPOP-1583
> Project: TinkerPop
>  Issue Type: Bug
>  Components: process
>Affects Versions: 3.2.3
>Reporter: Geoff Reedy
>
> We've seen this specifically for labels used in the until modulator of repeat 
> but I suspect it happens for other modulators as well. Here's a test case:
> {code}
> graph = TinkerGraph.open()
> g = graph.traversal()
> g.addV().as("first").repeat(addE("next").to(addV()).inV()).times(5).addE("next").to(select("first")).iterate()
> g.V().limit(1).as('z').out().repeat(store('seen').out().where(without('seen'))).until(where(eq('z')))
> {code}
> complains there is no z-key
> I tired to fix it myself and submit a pull request but I found the 
> implementation of PathRetractionStrategy confusing.
> One thing I noticed is that it seems the set of labels a step needs present 
> in order to work properly is determined external to the steps and that code 
> includes a lot of type-tests. If that logic were pushed down into the step 
> implementations I think fixing the repeat case would be easier and it would 
> be possible for extension steps to work properly with this strategy 
> (currently it seems they can't because of the closed-world assumption 
> inherent in the type-casing).



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Assigned] (TINKERPOP-1583) PathRetractionStrategy retracts keys that are actually needed

[Ted Wilmes (JIRA)]

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

Ted Wilmes reassigned TINKERPOP-1583:
-

Assignee: Ted Wilmes

> PathRetractionStrategy retracts keys that are actually needed
> -
>
> Key: TINKERPOP-1583
> URL: https://issues.apache.org/jira/browse/TINKERPOP-1583
> Project: TinkerPop
>  Issue Type: Bug
>  Components: process
>Affects Versions: 3.2.3
>Reporter: Geoff Reedy
>Assignee: Ted Wilmes
>
> We've seen this specifically for labels used in the until modulator of repeat 
> but I suspect it happens for other modulators as well. Here's a test case:
> {code}
> graph = TinkerGraph.open()
> g = graph.traversal()
> g.addV().as("first").repeat(addE("next").to(addV()).inV()).times(5).addE("next").to(select("first")).iterate()
> g.V().limit(1).as('z').out().repeat(store('seen').out().where(without('seen'))).until(where(eq('z')))
> {code}
> complains there is no z-key
> I tired to fix it myself and submit a pull request but I found the 
> implementation of PathRetractionStrategy confusing.
> One thing I noticed is that it seems the set of labels a step needs present 
> in order to work properly is determined external to the steps and that code 
> includes a lot of type-tests. If that logic were pushed down into the step 
> implementations I think fixing the repeat case would be easier and it would 
> be possible for extension steps to work properly with this strategy 
> (currently it seems they can't because of the closed-world assumption 
> inherent in the type-casing).



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Closed] (TINKERPOP-1548) Traversals can complete before interrupted in TraversalInterruptionComputerTest

[Ted Wilmes (JIRA)]

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

Ted Wilmes closed TINKERPOP-1548.
-
   Resolution: Fixed
Fix Version/s: 3.2.4

> Traversals can complete before interrupted in 
> TraversalInterruptionComputerTest
> ---
>
> Key: TINKERPOP-1548
> URL: https://issues.apache.org/jira/browse/TINKERPOP-1548
> Project: TinkerPop
>  Issue Type: Bug
>  Components: test-suite
>Affects Versions: 3.2.3
>Reporter: Ted Wilmes
>Assignee: Ted Wilmes
> Fix For: 3.2.4
>
>
> TinkerGraphComputer {{TraversalInterruptionComputerTest}} fails for me fairly 
> consistently.  It appears that the test traversal is completing before 
> {{t.interrupt}} on occasion which causes the test to fail because the 
> {{TraversalInterruptedException}} is never thrown.  I can reproduce this 
> failure more consistently when running TinkerGraphComputer with 1 worker.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Work started] (TINKERPOP-1548) Traversals can complete before interrupted in TraversalInterruptionComputerTest

[Ted Wilmes (JIRA)]

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

Work on TINKERPOP-1548 started by Ted Wilmes.
-
> Traversals can complete before interrupted in 
> TraversalInterruptionComputerTest
> ---
>
> Key: TINKERPOP-1548
> URL: https://issues.apache.org/jira/browse/TINKERPOP-1548
> Project: TinkerPop
>  Issue Type: Bug
>  Components: test-suite
>Affects Versions: 3.2.3
>Reporter: Ted Wilmes
>Assignee: Ted Wilmes
>
> TinkerGraphComputer {{TraversalInterruptionComputerTest}} fails for me fairly 
> consistently.  It appears that the test traversal is completing before 
> {{t.interrupt}} on occasion which causes the test to fail because the 
> {{TraversalInterruptedException}} is never thrown.  I can reproduce this 
> failure more consistently when running TinkerGraphComputer with 1 worker.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Closed] (TINKERPOP-965) Optimize TraversalStrategy application

[Ted Wilmes (JIRA)]

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

Ted Wilmes closed TINKERPOP-965.

Resolution: Won't Fix

Further profiling has shown that the new long pole in the tent is the 
PathRetractionStrategy. Strategy application is still running pretty quickly so 
we're in pretty good shape but I'd like to make it faster. Due to the 
complexity of the PathRetractionStrategy I will not risk introducing issues 
with a refactor for this release but will target performance improvements for 
3.3.

> Optimize TraversalStrategy application
> --
>
> Key: TINKERPOP-965
> URL: https://issues.apache.org/jira/browse/TINKERPOP-965
> Project: TinkerPop
>  Issue Type: Improvement
>  Components: process
>Affects Versions: 3.1.0-incubating
>Reporter: Marko A. Rodriguez
>Assignee: Ted Wilmes
>
> From the work of [~twilmes], it appears that we can gain a lot by making 
> {{Traversal.applyStrategies()}} as fast as possible. This is going to be 
> especially important as we transition people away from using 
> "Blueprints-methods" (e.g. {{Graph.addVertex()}} and {{Vertex.addEdge()}}) to 
> "Gremlin-methods" (e.g. {{g.addV()}} and 
> {{g.V().as('a').out().addE('knows').from('a')}}).
> Obviously the "Blueprints-methods" will always be faster given that they are 
> direct calls to the underlying provider. However, they should not be so 
> ridiculously faster that people won't use the "Gremlin-methods." Furthermore, 
> given [~dkuppitz]'s recent work with {{BulkLoaderVertexProgram}} and soon 
> TINKERPOP3-942, the "Gremlin-methods" will be the only way to get these 
> features.
> In general, the work should go beyond the {{Mutation}}-steps and make it so 
> that all traversals compile as fast as possible. The first step is to realize 
> where things are slow and knock those out firsthopefully we realize some 
> tricks!
> Related to: TINKERPOP3-957



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

Re: [DISCUSS] Add HGraphDB to graph system listing

[Ted Wilmes]

The 72 hours blew past and I didn't even notice.  Looks like there aren't
any objections so I'll get HGraphDB
added to the listing tomorrow morning.

Thanks,
Ted

On Fri, Nov 11, 2016 at 11:58 AM, Ted Wilmes  wrote:

> I think at this point it's not too big of a problem and yeah, your point
> about it giving dormant projects a possible boost is a good one.  Perhaps
> in
> a few months we can reevaluate and if things look a little out of control
> we could introduce an every 3-4 months "pruning" of projects that no longer
> meet the criteria.
>
> --Ted
>
> On Fri, Nov 11, 2016 at 11:49 AM, Stephen Mallette 
> wrote:
>
>> Yeah - I think I'd come up with the "current or previous 'y' version"
>> stipulation. I still like that as a measure of "active" but at the same
>> time I've not really wanted to apply it a heavy-handed way. Projects that
>> become dormant may be helped by the promotion provided by TinkerPop (e.g.
>> someone finds ts-tinkerpop through the listing and starts to try to
>> contribute to it).  Maybe it's not too big a problem yet?
>>
>> On Fri, Nov 11, 2016 at 11:49 AM, Jason Plurad  wrote:
>>
>> > +1 on the HGraphDB index listing.
>> >
>> > I think another minor concern is how to handle projects that have gone
>> > dormant, like ts-tinkerpop or scalajs-gremlin-client for example.
>> > Understanding how versions line up between TinkerPop and whatever
>> database
>> > or library they want to use has been a pain point for many users.
>> >
>> > My emphasis below:
>> >
>> > The project must be *actively* developed/maintained to a current or
>> > previous "y" version of Apache TinkerPop (3.y.z).
>> >
>> > -- Jason
>> >
>> > On Thu, Nov 10, 2016 at 3:21 PM, Stephen Mallette > >
>> > wrote:
>> >
>> > > I sorta share that sentiment however, I think we had that discussion
>> back
>> > > when we determined our listing requirements and we figured we couldn't
>> > > figure out how to easily quantify "mature".
>> > >
>> > > On Thu, Nov 10, 2016 at 3:17 PM, Jean-Baptiste Musso <
>> jbmu...@gmail.com>
>> > > wrote:
>> > >
>> > > > Interesting thing. +1 to adding HGraphDB to the list.
>> > > >
>> > > > Minor concern: I'm not sure if we want to manage a curated list of
>> > > > implementations and maybe restrict to more mature projects. I'm just
>> > > > thinking out loud here: I'm not targeting HGraphDB specifically
>> (and I
>> > > wish
>> > > > them good luck - *cheers*). My main concern is that the project is
>> very
>> > > > young, but graph databases need as much publicity as they can.
>> > > >
>> > > > Jean-Baptiste
>> > > >
>> > > > On Thu, Nov 10, 2016 at 8:58 PM, Ted Wilmes 
>> wrote:
>> > > >
>> > > > > Hello everyone,
>> > > > > Robert Yokota notified us today that he has developed an
>> > > > > Apache TinkerPop enabled graph db: https://github.com/rayokota/
>> > > hgraphdb.
>> > > > > Correct me if I'm wrong Robert, but it looks like it's at the
>> > TinkerPop
>> > > > > 3.2.3 version.
>> > > > >
>> > > > > I think HGraphDB meets our index listing requirements but I
>> wanted to
>> > > > bring
>> > > > > it up
>> > > > > just in case anyone felt differently.  Unless there are any
>> > objections,
>> > > > > I'll assume lazy
>> > > > > consensus in three days (Sunday, November 13, 2016 2:00 CST) and
>> add
>> > > > > HGraphDB
>> > > > > to the graph systems listing.
>> > > > >
>> > > > > Thanks,
>> > > > > Ted
>> > > > >
>> > > >
>> > >
>> >
>>
>
>

Re: [DISCUSS] Add HGraphDB to graph system listing

[Ted Wilmes]

I think at this point it's not too big of a problem and yeah, your point
about it giving dormant projects a possible boost is a good one.  Perhaps in
a few months we can reevaluate and if things look a little out of control
we could introduce an every 3-4 months "pruning" of projects that no longer
meet the criteria.

--Ted

On Fri, Nov 11, 2016 at 11:49 AM, Stephen Mallette 
wrote:

> Yeah - I think I'd come up with the "current or previous 'y' version"
> stipulation. I still like that as a measure of "active" but at the same
> time I've not really wanted to apply it a heavy-handed way. Projects that
> become dormant may be helped by the promotion provided by TinkerPop (e.g.
> someone finds ts-tinkerpop through the listing and starts to try to
> contribute to it).  Maybe it's not too big a problem yet?
>
> On Fri, Nov 11, 2016 at 11:49 AM, Jason Plurad  wrote:
>
> > +1 on the HGraphDB index listing.
> >
> > I think another minor concern is how to handle projects that have gone
> > dormant, like ts-tinkerpop or scalajs-gremlin-client for example.
> > Understanding how versions line up between TinkerPop and whatever
> database
> > or library they want to use has been a pain point for many users.
> >
> > My emphasis below:
> >
> > The project must be *actively* developed/maintained to a current or
> > previous "y" version of Apache TinkerPop (3.y.z).
> >
> > -- Jason
> >
> > On Thu, Nov 10, 2016 at 3:21 PM, Stephen Mallette 
> > wrote:
> >
> > > I sorta share that sentiment however, I think we had that discussion
> back
> > > when we determined our listing requirements and we figured we couldn't
> > > figure out how to easily quantify "mature".
> > >
> > > On Thu, Nov 10, 2016 at 3:17 PM, Jean-Baptiste Musso <
> jbmu...@gmail.com>
> > > wrote:
> > >
> > > > Interesting thing. +1 to adding HGraphDB to the list.
> > > >
> > > > Minor concern: I'm not sure if we want to manage a curated list of
> > > > implementations and maybe restrict to more mature projects. I'm just
> > > > thinking out loud here: I'm not targeting HGraphDB specifically (and
> I
> > > wish
> > > > them good luck - *cheers*). My main concern is that the project is
> very
> > > > young, but graph databases need as much publicity as they can.
> > > >
> > > > Jean-Baptiste
> > > >
> > > > On Thu, Nov 10, 2016 at 8:58 PM, Ted Wilmes 
> wrote:
> > > >
> > > > > Hello everyone,
> > > > > Robert Yokota notified us today that he has developed an
> > > > > Apache TinkerPop enabled graph db: https://github.com/rayokota/
> > > hgraphdb.
> > > > > Correct me if I'm wrong Robert, but it looks like it's at the
> > TinkerPop
> > > > > 3.2.3 version.
> > > > >
> > > > > I think HGraphDB meets our index listing requirements but I wanted
> to
> > > > bring
> > > > > it up
> > > > > just in case anyone felt differently.  Unless there are any
> > objections,
> > > > > I'll assume lazy
> > > > > consensus in three days (Sunday, November 13, 2016 2:00 CST) and
> add
> > > > > HGraphDB
> > > > > to the graph systems listing.
> > > > >
> > > > > Thanks,
> > > > > Ted
> > > > >
> > > >
> > >
> >
>

[DISCUSS] Add HGraphDB to graph system listing

[Ted Wilmes]

Hello everyone,
Robert Yokota notified us today that he has developed an
Apache TinkerPop enabled graph db: https://github.com/rayokota/hgraphdb.
Correct me if I'm wrong Robert, but it looks like it's at the TinkerPop
3.2.3 version.

I think HGraphDB meets our index listing requirements but I wanted to bring
it up
just in case anyone felt differently.  Unless there are any objections,
I'll assume lazy
consensus in three days (Sunday, November 13, 2016 2:00 CST) and add
HGraphDB
to the graph systems listing.

Thanks,
Ted

Re: Add HGraphDB to the homepage index?

[Ted Wilmes]

Hi Robert,
I stumbled upon your announcement earlier today.  Exciting news!  It looks
like
your project meets the index listing requirements.  I'm going to send
another message to dev to make sure there is consensus.

Thanks,
Ted

On Thu, Nov 10, 2016 at 1:15 PM, Robert Yokota  wrote:

> Hi,
>
> I wrote a TinkerPop 3 provider for HBase so it could be used as an OLTP
> graph database.  Would it be possible to get it added to the homepage index
> listing?
>
> https://github.com/rayokota/hgraphdb
>
> https://rayokota.wordpress.com/2016/11/10/hgraphdb-hbase-
> as-a-tinkerpop-graph-database/
>
> Thanks,
> Robert
>

[jira] [Created] (TINKERPOP-1548) Traversals can complete before interrupted in TraversalInterruptionComputerTest

[Ted Wilmes (JIRA)]

Ted Wilmes created TINKERPOP-1548:
-

 Summary: Traversals can complete before interrupted in 
TraversalInterruptionComputerTest
 Key: TINKERPOP-1548
 URL: https://issues.apache.org/jira/browse/TINKERPOP-1548
 Project: TinkerPop
  Issue Type: Bug
  Components: test-suite
Affects Versions: 3.2.3
Reporter: Ted Wilmes
Assignee: Ted Wilmes


TinkerGraphComputer {{TraversalInterruptionComputerTest}} fails for me fairly 
consistently.  It appears that the test traversal is completing before 
{{t.interrupt}} on occasion which causes the test to fail because the 
{{TraversalInterruptedException}} is never thrown.  I can reproduce this 
failure more consistently when running TinkerGraphComputer with 1 worker.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Closed] (TINKERPOP-1468) GraphTraversal.optional throws a NPE if no traversal is provided

[Ted Wilmes (JIRA)]

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

Ted Wilmes closed TINKERPOP-1468.
-
Resolution: Won't Fix
  Assignee: Ted Wilmes

Since this is related to Groovy and a 0 arg method call (see 
[here|https://objectpartners.com/2015/09/02/groovy-gotcha-passing-zero-arguments-to-a-method-that-expects-one/]
 for details) we are closing this as "won't fix".

> GraphTraversal.optional throws a NPE if no traversal is provided
> 
>
> Key: TINKERPOP-1468
> URL: https://issues.apache.org/jira/browse/TINKERPOP-1468
> Project: TinkerPop
>  Issue Type: Bug
>  Components: process
>Affects Versions: 3.2.2
>        Reporter: Ted Wilmes
>Assignee: Ted Wilmes
>  Labels: trivial
>
> {{GraphTraversal.optional}} throws a NPE if no traversal is provided.  We 
> should probably throw a friendlier exception with instructions to provide a 
> traversal as an argument.
> {code}
> gremlin> g.V().optional()
> java.lang.NullPointerException
> Type ':help' or ':h' for help.
> Display stack trace? [yN]y
> java.lang.NullPointerException
>   at 
> org.apache.tinkerpop.gremlin.process.traversal.dsl.graph.GraphTraversal.optional(GraphTraversal.java:1316)
> {code}



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

Re: New Committer: Robert Dale

[Ted Wilmes]

Welcome Robert!

--Ted

On Thu, Oct 27, 2016 at 8:30 AM, Stephen Mallette 
wrote:

> The Project Management Committee (PMC) for Apache TinkerPop has asked
> Robert Dale to become a committer and we are pleased to announce that he
> has accepted.
>
> Robert has submitted a number of quality pull requests to TinkerPop
> covering both new features and bug/documentation fixes and has been engaged
> in many different development discussions that have shaped the direction
> TinkerPop has taken. He's also been helpful on the user mailing list,
> providing some nice answers to those who have needed support. All of that
> activity made him a sound choice for committership.
>
> Let this proclamation traverse the entirety of The TinkerPop so that all
> may know to welcome Robert to the TinkerPop Guild!
>