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(0.0), lt(0.6))]),
> EdgeVertexStep(IN)]
>
> We likely need more direct serialization tests of P, but I think those
> already exist in master. Made a note to review further after release.
>
>
> On Wed, Jun 14, 2017 at 3:57 PM, Robert Dale <robd...@gmail.com> wrote:
>
>> Fix pushed to tp32 and master.
>>
>> Robert Dale
>>
>> On Wed, Jun 14, 2017 at 3:50 PM, Stephen Mallette <spmalle...@gmail.com>
>> wrote:
>>
>> > Well - now that the VOTE on 3.2.5 is cancelled we can now fix up these
>> > couple of issues, specifically:
>> >
>> > 1. anyStepRecursively() bug (kuppitz is going to handle that)
>> > 2. Gryo serialization of inside() (robert dale, you had the fix for
>> that -
>> > do you want to just CTR that in? though i'm also interested in why tests
>> > didn't catch that problem)
>> >
>> > I'm going to leave out the other issue noted:
>> >
>> > https://issues.apache.org/jira/browse/TINKERPOP-1691
>> >
>> > as it is not user facing - just something related to the test suite
>> > (providers at least have a workaround for that if they hit problems as
>> they
>> > can @OptOut).
>> >
>> > I also don't intend to deploy another SNAPSHOT so i'm just going to
>> keep us
>> > on "3.2.5" and not revert to "3.2.5-SNAPSHOT". Let's just patch this up
>> > then I'll start on a fresh release packaging tomorrow.
>> >
>> > Any other concerns?
>> >
>> >
>> >
>> > On Tue, Jun 6, 2017 at 6:27 AM, Robert Dale <robd...@gmail.com> wrote:
>> >
>> > > That will probably work too. I use https://wummel.github.io/linkc
>> hecker/
>> > >
>> > >
>> > > Robert Dale
>> > >
>> > > On Tue, Jun 6, 2017 at 6:20 AM, Daniel Kuppitz <m...@gremlin.guru>
>> wrote:
>> > >
>> > > > https://validator.w3.org/checklink
>> > > >
>> > > > On Tue, Jun 6, 2017 at 12:18 PM, Stephen Mallette <
>> > spmalle...@gmail.com>
>> > > > wrote:
>> > > >
>> > > > > huh - that's a neat idea. is there a specific tool you use?
>> > > > >
>> > > > > On Tue, Jun 6, 2017 at 5:48 AM, Robert Dale <robd...@gmail.com>
>> > wrote:
>> > > > >
>> > > > > > Linkchecker passes.
>> > > > > >
>> > > > > > Robert Dale
>> > > > > >
>> > > > > > On Mon, Jun 5, 2017 at 6:38 AM, Stephen Mallette <
>> > > spmalle...@gmail.com
>> > > > >
>> > > > > > wrote:
>> > > > > >
>> > > > > > > I published latest docs for 3.2.5-SNAPSHOT:
>> > > > > > >
>> > > > > > > http://tinkerpop.apache.org/docs/3.2.5-SNAPSHOT/
>> > > > > > >
>> > > > > > > and made another deployment to the Apache Snapshot Repo after
>> > those
>> > > > > > > TinkerFactory adjustments.
>> > > > > > >
>> > > > > > > On Fri, Jun 2, 2017 at 8:39 PM, Stephen Mallette <
>> > > > spmalle...@gmail.com
>> > > > > >
>> > > > > > > wrote:
>> > > > > > >
>> > > > > > > > Just a reminder that code is frozen on the tp32 branch
>> starting
>> > > > > > tomorrow
>> > > > > > > > (Saturday) and for the following week. We'll use this
>> thread to
>> > > > > discuss
>> > > > > > > any
>> > > > > > > > issues or problems on 3.2.5 that are found during testing.
>> > There
>> > > > are
>> > > > > no
>> > > > > > > > open pull requests and no outstanding issues that I'm aware
>> of.
>> > > > I've
>> > > > > > > > published a TinkerPop 3.2.5-SNAPSHOT for providers to test
>> > > against
>> > > > > (or
>> > > > > > > they
>> > > > > > > > may build themselves - whatever is more convenient).
>> > > > > > > >
>> > > > > > > > Thanks,
>> > > > > > > >
>> > > > > > > > Stephen
>> > > > > > > >
>> > > > > > >
>> > > > > >
>> > > > >
>> > > >
>> > >
>> >
>>
>
>
