[jira] [Updated] (TINKERPOP-1379) unaccounted excess in TailGlobalStep

2016-07-20 Thread Jason Plurad (JIRA) 

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

Jason Plurad updated TINKERPOP-1379:

Affects Version/s: 3.1.3

> unaccounted excess in TailGlobalStep
> 
>
> Key: TINKERPOP-1379
> URL: https://issues.apache.org/jira/browse/TINKERPOP-1379
> Project: TinkerPop
>  Issue Type: Bug
>  Components: process
>Affects Versions: 3.1.3, 3.2.1
>Reporter: Jason Plurad
>
> https://github.com/apache/tinkerpop/blob/master/gremlin-core/src/main/java/org/apache/tinkerpop/gremlin/process/traversal/step/filter/TailGlobalStep.java#L71-L74
> This code doesn't account for the excess removed from {{tailBulk}}. This can 
> cause the code to set incorrect bulk values when there are multiple 
> traversers in the tail buffer.
> I observed this behavior intermittently in TitanGraph 
> (https://github.com/thinkaurelius/titan/pull/1312), which doesn't allow user 
> defined ids, so the ordering of the traversers in the TraverserSet is a lot 
> more random than the unit tests using TinkerGraph.
> This issue is reproducible with TinkerGraph (master/3.2.1). Instead of 
> loading from one of the data files, manually create the graph with the ids in 
> inverted order.
> {noformat}
> graph = TinkerGraph.open();
> // graph.io(IoCore.gryo()).readGraph("tinkerpop-modern.kryo");
> final Vertex v1 = graph.addVertex(T.id, 6L, T.label, "person", "name", 
> "marko", "age", 29);
> final Vertex v2 = graph.addVertex(T.id, 5L, T.label, "person", "name", 
> "vadas", "age", 27);
> final Vertex v3 = graph.addVertex(T.id, 4L, T.label, "software", "name", 
> "lop", "lang", "java");
> final Vertex v4 = graph.addVertex(T.id, 3L, T.label, "person", "name", 
> "josh", "age", 32);
> final Vertex v5 = graph.addVertex(T.id, 2L, T.label, "software", "name", 
> "ripple", "lang", "java");
> final Vertex v6 = graph.addVertex(T.id, 1L, T.label, "person", "name", 
> "peter", "age", 35);
> v1.addEdge("knows", v2, "weight", 0.5d);
> v1.addEdge("knows", v4, "weight", 1.0d);
> v1.addEdge("created", v2, "weight", 0.4d);
> v4.addEdge("knows", v5, "weight", 1.0d);
> v4.addEdge("knows", v3, "weight", 0.4d);
> v6.addEdge("knows", v3, "weight", 0.2d);
> if (graph.features().graph().supportsTransactions()) graph.tx().commit();
> final GraphTraversalSource g = graph.traversal();
> String result = 
> g.V().repeat(both()).times(3).tail(7).count().next().toString();
> boolean success = "7".equals(result);
> {noformat}
> The fix is this:
> {noformat}
> if (excess > 0) {
> oldest.setBulk(oldestBulk-excess);
> // Account for the loss of excess in the tail buffer
> this.tailBulk -= excess;
> }
> {noformat}



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

[DISCUSS] interrupt

2016-07-20 Thread pieter-gmail 
The current interrupt implementation is failing on Sqlg's HSQLDB
implementation.
The reason for this is that HSQLDB itself relies on Thread.interrupt()
for its own internal logic. When TinkerPop interrupts the thread it
thinks it has to do with its own logic and as a result the interrupt
flag is reset and no exception is thrown.

Reading the Thread.interrupt javadocs it says that wait(), join() and
sleep() will all reset the interrupt flag throw an InterruptedException.
This makes TinkerPop's reliance on the flag being set somewhat fragile.
All of those methods I suspect are common with database io code and
TinkerPop being a high level database layer makes it susceptible to 3rd
party interpretations of interrupt semantics.

In some ways the TraversalInterruptionTest itself had to carefully reset
the flag with its usage of Thread.sleep().

My proposal is to mark the traversal itself as interrupted rather than
the thread and keep the logic contained to TinkerPop's space.

Another benefit is that the traversal.interrupt() can raise an event
that implementations can listen to. On receipt of the event they would
then be able to send a separate request to the database to cancel a
particular query. In my case would be a nice way for Sqlg to tell
Postgresql or HSQLDB to cancel a particular query (the latest one the
traversal executed).

In many ways the semantics are the same. Currently for client code
wanting to interrupt a particular traversal it needs to have a reference
to the thread the traversal is executing in. Now instead it needs to
keep a reference to executing traversals and interrupt them directly.

Add Traversal.interrupt() and Traversal.isInterrupted(boolean
ClearInterrupted)

Caveat, I am not familiar with GremlinServer nor the complications
around interrupt there so perhaps I am missing something.

Thanks
Pieter

[jira] [Commented] (TINKERPOP-1380) dedup() doesn't dedup in rare cases

2016-07-20 Thread stephen mallette (JIRA) 

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

stephen mallette commented on TINKERPOP-1380:
-

I just noticed this which [~dkuppitz] thinks might be related to this issue:

{code}
gremlin> t = g.V().aggregate('a')
==>v[1]
==>v[2]
==>v[3]
==>v[4]
==>v[5]
==>v[6]
gremlin> t.clone()
==>v[1]
==>v[2]
==>v[3]
==>v[4]
==>v[5]
==>v[6]
gremlin> t.getSideEffects().get('a')
==>v[1]
==>v[1]
==>v[2]
==>v[2]
==>v[3]
==>v[3]
==>v[4]
==>v[4]
==>v[5]
==>v[5]
==>v[6]
==>v[6]
{code}

calls to {{clone()}} are keeping side-effects. perhaps that is the root of the 
problem here?

> dedup() doesn't dedup in rare cases
> ---
>
> Key: TINKERPOP-1380
> URL: https://issues.apache.org/jira/browse/TINKERPOP-1380
> Project: TinkerPop
>  Issue Type: Bug
>  Components: process
>Affects Versions: 3.2.1
>Reporter: Daniel Kuppitz
>
> I stumbled across this issue when I tried to solve a problem on the mailing 
> list. It seems like a lot of steps need to be involved in order to make it 
> reproducible.
> {code}
> gremlin> :set max-iteration 10
> gremlin> 
> gremlin> g = TinkerFactory.createModern().traversal().withComputer()
> ==>graphtraversalsource[tinkergraph[vertices:6 edges:6], graphcomputer]
> gremlin> 
> g.V().repeat(both()).until(cyclicPath()).path().aggregate("x").cap("x").unfold().dedup()
> ==>[v[1], v[2], v[1]]
> ==>[v[1], v[2], v[1]]
> ==>[v[1], v[3], v[1]]
> ==>[v[1], v[3], v[1]]
> ==>[v[1], v[4], v[1]]
> ==>[v[1], v[4], v[1]]
> ==>[v[2], v[1], v[2]]
> ==>[v[2], v[1], v[2]]
> ==>[v[3], v[1], v[3]]
> ==>[v[3], v[1], v[3]]
> ...
> {code}
> I can't reproduce it w/o using {{repeat()}}, {{aggregate()}} or {{cap()}}. It 
> is reproducible without {{path()}} though. And then it even gets a little 
> worse; check this out:
> {code}
> gremlin> 
> g.V().repeat(both()).until(cyclicPath()).aggregate("x").cap("x").unfold().dedup()
> ==>v[1]
> ==>v[1]
> ==>v[2]
> ==>v[2]
> ==>v[3]
> ==>v[3]
> ==>v[4]
> ==>v[4]
> ==>v[5]
> ==>v[5]
> ...
> gremlin> 
> g.V().repeat(both()).until(cyclicPath()).aggregate("x").cap("x").unfold().dedup().dedup()
> java.lang.RuntimeException: java.lang.IllegalStateException: 
> java.lang.IllegalArgumentException: The memory can only be set() during 
> vertex program setup and terminate: x
> Display stack trace? [yN]
> {code}
> The exception occurs only in OLAP mode, but also for more meaningful patterns 
> ({{.dedup().dedup()}} really doesn't make much sense).
> For a better / larger example see: 
> https://groups.google.com/d/msg/gremlin-users/NMXExuvDjt0/ps7bJDYwAQAJ



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

[jira] [Commented] (TINKERPOP-1382) As a developer we should be able to create user-defined gremlin step using latest Tinkerpop 3.x

2016-07-20 Thread Kaniska Mandal (JIRA) 

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

Kaniska Mandal commented on TINKERPOP-1382:
---

Thanks much Stephen for the quick clarification,

1) which version of Tinkerpop supports addStep ?

** we are accessing Titan and Tinkerpop Gremlin query through a multi-tenant 
java Rest API server 

2) so if we need to use Tinkerpop 3.1.0 , then we need to compile Titan 1.0.0  
with Tinkerpop 3.1.0 to be able to call 'addStep()' from inside our Java Rest 
API code (that can embed groovy script) Right ? 

if you don't mind, can you point us to some concrete example of 'defining 
custom steps' both (A) using addSteps (not just filter but a step that can 
combine many steps ) through groovy script as well as (B) how to register a 
GraphTraversalSource with gremlin server and then invoke chain of methods (as 
mentioned in the other comment)

Again appreciate much for helping us achive this critical functionality of 
'user-defined steps'



> As a developer we should be able to create user-defined gremlin step using 
> latest Tinkerpop 3.x 
> 
>
> Key: TINKERPOP-1382
> URL: https://issues.apache.org/jira/browse/TINKERPOP-1382
> Project: TinkerPop
>  Issue Type: Improvement
>  Components: process
>Affects Versions: 3.2.0-incubating
>Reporter: Kaniska Mandal
>
> As a developer we need to be able to define a custom step like we could do as 
> Gremlin.defineStep(...)  in Tinkerpop 2.x 
> It would be great if a separate Java API is provided to combine a set of 
> commands and define a custom step.



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

[jira] [Updated] (TINKERPOP-1381) improve test coverage of graphs with random ids

2016-07-20 Thread stephen mallette (JIRA) 

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

stephen mallette updated TINKERPOP-1381:

Issue Type: Improvement  (was: Test)

> improve test coverage of graphs with random ids
> ---
>
> Key: TINKERPOP-1381
> URL: https://issues.apache.org/jira/browse/TINKERPOP-1381
> Project: TinkerPop
>  Issue Type: Improvement
>  Components: test-suite
>Affects Versions: 3.2.1
>Reporter: Jason Plurad
>
> https://issues.apache.org/jira/browse/TINKERPOP-1379 exposed some issues with 
> the test suite where some tests were passing because the input graph has 
> user-assigned ids in a specific, repeatable order. Many graph systems do not 
> allow user-assigned ids and end up with random ids assigned to elements. This 
> difference in behavior can cause the TinkerPop suite to pass cleanly against 
> TinkerGraph, but fail intermittently against other graphs (Titan, Sqlg).
> https://issues.apache.org/jira/browse/TINKERPOP-1365 is perhaps related to 
> this, with respect to finding ways to increase coverage on the graph 
> configuration permutations.



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

[jira] [Created] (TINKERPOP-1381) improve test coverage of graphs with random ids

2016-07-20 Thread Jason Plurad (JIRA) 
Jason Plurad created TINKERPOP-1381:
---

 Summary: improve test coverage of graphs with random ids
 Key: TINKERPOP-1381
 URL: https://issues.apache.org/jira/browse/TINKERPOP-1381
 Project: TinkerPop
  Issue Type: Test
  Components: test-suite
Affects Versions: 3.2.1
Reporter: Jason Plurad


https://issues.apache.org/jira/browse/TINKERPOP-1379 exposed some issues with 
the test suite where some tests were passing because the input graph has 
user-assigned ids in a specific, repeatable order. Many graph systems do not 
allow user-assigned ids and end up with random ids assigned to elements. This 
difference in behavior can cause the TinkerPop suite to pass cleanly against 
TinkerGraph, but fail intermittently against other graphs (Titan, Sqlg).

https://issues.apache.org/jira/browse/TINKERPOP-1365 is perhaps related to 
this, with respect to finding ways to increase coverage on the graph 
configuration permutations.



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

Re: [VOTE] TinkerPop 3.2.1 Release

2016-07-20 Thread Daniel Kuppitz 
>
> imo, a -1 should be reserved for when there is a massive bug that brings down
> the house


I concur. I've also found some nasty bugs in OLAP during my tests and even
if without a workaround I would probably have voted +1, as this has nothing
to do with the release.

you have a single backend for Sqlg


That's another good point. If all tests pass for our reference
implementations (TinkerGraph and Neo4j), why should a failing test in
another 3rd party implementation block our release? AFAIK there are also
still issues in Titan, but that's a Titan thing, not a TinkerPop issue.

Cheers,
Daniel




On Wed, Jul 20, 2016 at 6:01 PM, Stephen Mallette 
wrote:

> Pieter, Thanks as usual for testing. I would offer than this is not a case
> for a -1. Note that a -1 says we abort the release completely.
>
> imo, a -1 should be reserved for when there is a massive bug that brings
> down the house - meaning the system is abend in some way and there are no
> workarounds. a -1 might also be presented if the packaging is bad somehow -
> like we didn't include the documentation in the zips. i could also see a -1
> if somehow a GPL'd dependency snuck into our packaging somehow or we
> otherwise violated Apache licensing. If other's don't agree, I hope they'll
> say so.
>
> in this case, you have a single backend for Sqlg that is failing a single
> test that you can temporarily OptOut of for your tests to pass. Users don't
> specifically have a workaround for this problem if they use Sqlg and
> HSQLDB, but it's less of a "bug" and more of a feature that they can't use
> (i.e. they can't interrupt a running traversal). To me, I don't think we
> need to stop release of TinkerPop over that narrow case.
>
> Would you reconsider your -1 based on that logic?
>
>
>
> On Wed, Jul 20, 2016 at 11:45 AM, pieter-gmail 
> wrote:
>
> > Hi,
> >
> > Ran all Sqlg's tests and the process and structured  test suites.
> > But alas there are failures.
> >
> > TraversalInterruptionTest are failing on HSQLDB as the
> > Thread.interrupt() is intercepted by them and the interrupt flag is
> reset.
> > The TraversalInterruptionTest tests themselves suffers from this as its
> > own Thread.sleep() logic resets the interrupt flag and requires special
> > resetting. I'd say the current interrupt strategy needs rethinking.
> >
> > TailTest.g_V_repeatXbothX_timesX3X_tailX7X fails. I added a few more,
> > repeat followed by a tail step, tests in sqlg, all of which also fails.
> > Jason has already proposed a fix for this here
> > .
> >
> > vote -1
> >
> > Thanks
> > Pieter
> >
> >
> >
> > On 19/07/2016 15:20, Stephen Mallette wrote:
> > > Hello,
> > >
> > > We are happy to announce that TinkerPop 3.2.1 is ready for release -
> note
> > > the lack of "-incubating" everywhere.  :)
> > >
> > > The release artifacts can be found at this location:
> > > https://dist.apache.org/repos/dist/dev/tinkerpop/3.2.1/
> > >
> > > The source distribution is provided by:
> > > apache-tinkerpop-3.2.1-src.zip
> > >
> > > Two binary distributions are provided for user convenience:
> > > apache-gremlin-console-3.2.1-bin.zip
> > > apache-gremlin-server-3.2.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.2.1/reference/ (user docs)
> > > http://tinkerpop.apache.org/docs/3.2.1/upgrade/ (upgrade docs)
> > > http://tinkerpop.apache.org/javadocs/3.2.1/core/ (core javadoc)
> > > http://tinkerpop.apache.org/javadocs/3.2.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=tag;h=c5a9e2815e76f044e6b33b773b6bb0bb048270cc
> > >
> > > The release notes are available here:
> > >
> >
> https://github.com/apache/tinkerpop/blob/3.2.1/CHANGELOG.asciidoc#release-3-2-1
> > >
> > > The [VOTE] will be open for the next 72 hours --- closing Friday (July
> > 22,
> > > 2016) at 9:30 am EST.
> > >
> > > My vote is +1.
> > >
> > > Thank you very much,
> > > Stephen
> > >
> >
> >
>

[jira] [Commented] (TINKERPOP-1379) unaccounted excess in TailGlobalStep

2016-07-20 Thread ASF GitHub Bot (JIRA) 

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

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

GitHub user pluradj opened a pull request:

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

TINKERPOP-1379 remove excess bulk in tail buffer

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

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

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

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

https://github.com/apache/tinkerpop/pull/363.patch

To close this pull request, make a commit to your master/trunk branch
with (at least) the following in the commit message:

This closes #363


commit d43db2bb2f3f4988503f0cdedbd1877cd542c502
Author: Jason Plurad 
Date:   2016-07-20T16:31:53Z

remove excess bulk in tail buffer




> unaccounted excess in TailGlobalStep
> 
>
> Key: TINKERPOP-1379
> URL: https://issues.apache.org/jira/browse/TINKERPOP-1379
> Project: TinkerPop
>  Issue Type: Bug
>  Components: process
>Affects Versions: 3.2.1
>Reporter: Jason Plurad
>
> https://github.com/apache/tinkerpop/blob/master/gremlin-core/src/main/java/org/apache/tinkerpop/gremlin/process/traversal/step/filter/TailGlobalStep.java#L71-L74
> This code doesn't account for the excess removed from {{tailBulk}}. This can 
> cause the code to set incorrect bulk values when there are multiple 
> traversers in the tail buffer.
> I observed this behavior intermittently in TitanGraph 
> (https://github.com/thinkaurelius/titan/pull/1312), which doesn't allow user 
> defined ids, so the ordering of the traversers in the TraverserSet is a lot 
> more random than the unit tests using TinkerGraph.
> This issue is reproducible with TinkerGraph (master/3.2.1). Instead of 
> loading from one of the data files, manually create the graph with the ids in 
> inverted order.
> {noformat}
> graph = TinkerGraph.open();
> // graph.io(IoCore.gryo()).readGraph("tinkerpop-modern.kryo");
> final Vertex v1 = graph.addVertex(T.id, 6L, T.label, "person", "name", 
> "marko", "age", 29);
> final Vertex v2 = graph.addVertex(T.id, 5L, T.label, "person", "name", 
> "vadas", "age", 27);
> final Vertex v3 = graph.addVertex(T.id, 4L, T.label, "software", "name", 
> "lop", "lang", "java");
> final Vertex v4 = graph.addVertex(T.id, 3L, T.label, "person", "name", 
> "josh", "age", 32);
> final Vertex v5 = graph.addVertex(T.id, 2L, T.label, "software", "name", 
> "ripple", "lang", "java");
> final Vertex v6 = graph.addVertex(T.id, 1L, T.label, "person", "name", 
> "peter", "age", 35);
> v1.addEdge("knows", v2, "weight", 0.5d);
> v1.addEdge("knows", v4, "weight", 1.0d);
> v1.addEdge("created", v2, "weight", 0.4d);
> v4.addEdge("knows", v5, "weight", 1.0d);
> v4.addEdge("knows", v3, "weight", 0.4d);
> v6.addEdge("knows", v3, "weight", 0.2d);
> if (graph.features().graph().supportsTransactions()) graph.tx().commit();
> final GraphTraversalSource g = graph.traversal();
> String result = 
> g.V().repeat(both()).times(3).tail(7).count().next().toString();
> boolean success = "7".equals(result);
> {noformat}
> The fix is this:
> {noformat}
> if (excess > 0) {
> oldest.setBulk(oldestBulk-excess);
> // Account for the loss of excess in the tail buffer
> this.tailBulk -= excess;
> }
> {noformat}



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

[GitHub] tinkerpop pull request #363: TINKERPOP-1379 remove excess bulk in tail buffe...

2016-07-20 Thread pluradj 
GitHub user pluradj opened a pull request:

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

TINKERPOP-1379 remove excess bulk in tail buffer

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

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

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

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

https://github.com/apache/tinkerpop/pull/363.patch

To close this pull request, make a commit to your master/trunk branch
with (at least) the following in the commit message:

This closes #363


commit d43db2bb2f3f4988503f0cdedbd1877cd542c502
Author: Jason Plurad 
Date:   2016-07-20T16:31:53Z

remove excess bulk in tail buffer




---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

Re: [VOTE] TinkerPop 3.2.1 Release

2016-07-20 Thread Stephen Mallette 
Pieter, Thanks as usual for testing. I would offer than this is not a case
for a -1. Note that a -1 says we abort the release completely.

imo, a -1 should be reserved for when there is a massive bug that brings
down the house - meaning the system is abend in some way and there are no
workarounds. a -1 might also be presented if the packaging is bad somehow -
like we didn't include the documentation in the zips. i could also see a -1
if somehow a GPL'd dependency snuck into our packaging somehow or we
otherwise violated Apache licensing. If other's don't agree, I hope they'll
say so.

in this case, you have a single backend for Sqlg that is failing a single
test that you can temporarily OptOut of for your tests to pass. Users don't
specifically have a workaround for this problem if they use Sqlg and
HSQLDB, but it's less of a "bug" and more of a feature that they can't use
(i.e. they can't interrupt a running traversal). To me, I don't think we
need to stop release of TinkerPop over that narrow case.

Would you reconsider your -1 based on that logic?



On Wed, Jul 20, 2016 at 11:45 AM, pieter-gmail 
wrote:

> Hi,
>
> Ran all Sqlg's tests and the process and structured  test suites.
> But alas there are failures.
>
> TraversalInterruptionTest are failing on HSQLDB as the
> Thread.interrupt() is intercepted by them and the interrupt flag is reset.
> The TraversalInterruptionTest tests themselves suffers from this as its
> own Thread.sleep() logic resets the interrupt flag and requires special
> resetting. I'd say the current interrupt strategy needs rethinking.
>
> TailTest.g_V_repeatXbothX_timesX3X_tailX7X fails. I added a few more,
> repeat followed by a tail step, tests in sqlg, all of which also fails.
> Jason has already proposed a fix for this here
> .
>
> vote -1
>
> Thanks
> Pieter
>
>
>
> On 19/07/2016 15:20, Stephen Mallette wrote:
> > Hello,
> >
> > We are happy to announce that TinkerPop 3.2.1 is ready for release - note
> > the lack of "-incubating" everywhere.  :)
> >
> > The release artifacts can be found at this location:
> > https://dist.apache.org/repos/dist/dev/tinkerpop/3.2.1/
> >
> > The source distribution is provided by:
> > apache-tinkerpop-3.2.1-src.zip
> >
> > Two binary distributions are provided for user convenience:
> > apache-gremlin-console-3.2.1-bin.zip
> > apache-gremlin-server-3.2.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.2.1/reference/ (user docs)
> > http://tinkerpop.apache.org/docs/3.2.1/upgrade/ (upgrade docs)
> > http://tinkerpop.apache.org/javadocs/3.2.1/core/ (core javadoc)
> > http://tinkerpop.apache.org/javadocs/3.2.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=tag;h=c5a9e2815e76f044e6b33b773b6bb0bb048270cc
> >
> > The release notes are available here:
> >
> https://github.com/apache/tinkerpop/blob/3.2.1/CHANGELOG.asciidoc#release-3-2-1
> >
> > The [VOTE] will be open for the next 72 hours --- closing Friday (July
> 22,
> > 2016) at 9:30 am EST.
> >
> > My vote is +1.
> >
> > Thank you very much,
> > Stephen
> >
>
>

Re: [VOTE] TinkerPop 3.2.1 Release

2016-07-20 Thread pieter-gmail 
Hi,

Ran all Sqlg's tests and the process and structured  test suites.
But alas there are failures.

TraversalInterruptionTest are failing on HSQLDB as the
Thread.interrupt() is intercepted by them and the interrupt flag is reset.
The TraversalInterruptionTest tests themselves suffers from this as its
own Thread.sleep() logic resets the interrupt flag and requires special
resetting. I'd say the current interrupt strategy needs rethinking.

TailTest.g_V_repeatXbothX_timesX3X_tailX7X fails. I added a few more,
repeat followed by a tail step, tests in sqlg, all of which also fails.
Jason has already proposed a fix for this here
.

vote -1

Thanks
Pieter



On 19/07/2016 15:20, Stephen Mallette wrote:
> Hello,
>
> We are happy to announce that TinkerPop 3.2.1 is ready for release - note
> the lack of "-incubating" everywhere.  :)
>
> The release artifacts can be found at this location:
> https://dist.apache.org/repos/dist/dev/tinkerpop/3.2.1/
>
> The source distribution is provided by:
> apache-tinkerpop-3.2.1-src.zip
>
> Two binary distributions are provided for user convenience:
> apache-gremlin-console-3.2.1-bin.zip
> apache-gremlin-server-3.2.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.2.1/reference/ (user docs)
> http://tinkerpop.apache.org/docs/3.2.1/upgrade/ (upgrade docs)
> http://tinkerpop.apache.org/javadocs/3.2.1/core/ (core javadoc)
> http://tinkerpop.apache.org/javadocs/3.2.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=tag;h=c5a9e2815e76f044e6b33b773b6bb0bb048270cc
>
> The release notes are available here:
> https://github.com/apache/tinkerpop/blob/3.2.1/CHANGELOG.asciidoc#release-3-2-1
>
> The [VOTE] will be open for the next 72 hours --- closing Friday (July 22,
> 2016) at 9:30 am EST.
>
> My vote is +1.
>
> Thank you very much,
> Stephen
>

Re: [VOTE] TinkerPop 3.1.3 Release

2016-07-20 Thread Ted Wilmes 
valitedate-distribution.sh looked good from my end along with manual tests
and a review of the generated java and other docs.

VOTE: +1

--Ted

On Tue, Jul 19, 2016 at 1:50 PM, Dylan Millikin 
wrote:

> Added tests for all the new features in the PHP driver.
> Installed gremlin-neo4j and ran the tests against a combination of
> TinkerGraph, Neo4j, sasl, etc.
>
> All tests pass.
> VOTE: +1
>
> On Mon, Jul 18, 2016 at 5:16 PM, Daniel Kuppitz  wrote:
>
> > $ bin/validate-distribution.sh 3.1.3
> >
> > Validating binary distributions
> >
> > * downloading Apache Gremlin Console
> > (apache-gremlin-console-3.1.3-bin.zip)... OK
> > * validating signatures and checksums ...
> >   * PGP signature ... OK
> >   * MD5 checksum ... OK
> >   * SHA1 chacksum ... OK
> > * unzipping Apache Gremlin Console ... OK
> > * validating Apache Gremlin Console's docs ... OK
> > * validating Apache Gremlin Console's binaries ... OK
> > * validating Apache Gremlin Console's legal files ...
> >   * LICENSE ... OK
> >   * NOTICE ... OK
> > * validating Apache Gremlin Console's plugin directory ... OK
> > * validating Apache Gremlin Console's lib directory ... OK
> > * testing script evaluation ... OK
> >
> > * downloading Apache Gremlin Server
> > (apache-gremlin-server-3.1.3-bin.zip)... OK
> > * validating signatures and checksums ...
> >   * PGP signature ... OK
> >   * MD5 checksum ... OK
> >   * SHA1 chacksum ... OK
> > * unzipping Apache Gremlin Server ... OK
> > * validating Apache Gremlin Server's docs ... OK
> > * validating Apache Gremlin Server's binaries ... OK
> > * validating Apache Gremlin Server's legal files ...
> >   * LICENSE ... OK
> >   * NOTICE ... OK
> > * validating Apache Gremlin Server's plugin directory ... OK
> > * validating Apache Gremlin Server's lib directory ... OK
> >
> > Validating source distribution
> >
> > * downloading Apache Tinkerpop 3.1.3 (apache-tinkerpop-3.1.3-src.zip)...
> OK
> > * validating signatures and checksums ...
> >   * PGP signature ... OK
> >   * MD5 checksum ... OK
> >   * SHA1 chacksum ... OK
> > * unzipping Apache Tinkerpop 3.1.3 ... OK
> > OK
> >
> > Looks good. I will do a few more manual tests tomorrow, but for now...
> >
> > VOTE: +1
> >
> > Oh, and I remember that I already mentioned it last time: We should fix
> > those typos in the script (chacksum .> checksum, Tinkerpop -> TinkerPop)
> >
> > Cheers,
> > Daniel
> >
> >
> > On Mon, Jul 18, 2016 at 10:32 PM, Stephen Mallette  >
> > wrote:
> >
> > > Hello,
> > >
> > > We are happy to announce that TinkerPop 3.1.3 is ready for release -
> note
> > > the lack of "-incubating" everywhere.  :)
> > >
> > > The release artifacts can be found at this location:
> > > https://dist.apache.org/repos/dist/dev/tinkerpop/3.1.3/
> > >
> > > The source distribution is provided by:
> > > apache-tinkerpop-3.1.3-src.zip
> > >
> > > Two binary distributions are provided for user convenience:
> > > apache-gremlin-console-3.1.3-bin.zip
> > > apache-gremlin-server-3.1.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.1.3/reference/ (user docs)
> > > http://tinkerpop.apache.org/docs/3.1.3/upgrade/ (upgrade docs)
> > > http://tinkerpop.apache.org/javadocs/3.1.3/core/ (core javadoc)
> > > http://tinkerpop.apache.org/javadocs/3.1.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=0f960ff0823246176343468b746b6e3ac2ade23c
> > >
> > > The release notes are available here:
> > >
> > >
> >
> https://github.com/apache/tinkerpop/blob/3.1.3/CHANGELOG.asciidoc#tinkerpop-313-release-date-july-18-2016
> > >
> > > The [VOTE] will be open for the next 72 hours --- closing Thursday
> (July
> > > 21, 2016) at 4:30 pm EST.
> > >
> > > My vote is +1.
> > >
> > > Thank you very much,
> > > Stephen
> > >
> >
>

Re: [DISCUSS] New IO format for GLVs/Gremlin Server

2016-07-20 Thread gallardo.kev...@gmail.com 


On 2016-07-19 22:28 (+0100), Marko Rodriguez  wrote: 
> Hi,
> 
> However, in general we just need an “object mapper pattern.” For instance:
> 
> For any JSON object { } that has a @type field, the @type value maps to a 
> deserializer. Thus, while we need to be able to serialize/deserialize the 
> standard Vertex/Edge/VertexProperty/etc. the representation should be 
> generalized to support any registered @type.

Agree with that, we wouldn't have had the choice than adding deserializers for 
these types anyway with how Jackson works. I had also planned indeed to make 
the GraphSONTypeIdResolver - which is the component that handles the conversion 
"typeID" -> "Java Class" for deserialization and "Java Class" -> "typeID" for 
serialization - configurable for users.

> 
>   Java GraphSON serializer/deserializer registration:
>   
> https://github.com/apache/tinkerpop/blob/TINKERPOP-1278/gremlin-core/src/main/java/org/apache/tinkerpop/gremlin/structure/io/graphson/GraphSONModule.java#L129-L147
>  
> 
> 
>   Python GraphSON serializer registration:
>   
> https://github.com/apache/tinkerpop/blob/TINKERPOP-1278/gremlin-python/src/main/jython/gremlin_python/process/graphson.py#L122-L127
>  
> 
> 
> People can register more @types as needed for their graph processor’s type 
> system.
> 
> Marko.
> 
> http://markorodriguez.com
> 
> 
> 
> > On Jul 19, 2016, at 12:55 PM, Marko Rodriguez  wrote:
> > 
> > We need:
> > 
> > Graph
> > Element
> > Vertex
> > Edge
> > VertexProperty
> > Property
> > Path
> > TraversalExplanation
> > TraversalMetrics
> > Traversal (i.e. Bytecode)
> > Traverser (object + bulk at minimum)
> > 
> > Marko.
> > 
> > http://markorodriguez.com
> > 
> > 
> > 
> >> On Jul 19, 2016, at 12:45 PM, Robert Dale  wrote:
> >> 
> >> There's also Path that can be returned from a query. It looks like
> >> GraphSON 1.0 handles this today in the REST API but it's not typed as
> >> a path.
> >> 
> >> On Tue, Jul 19, 2016 at 2:14 PM, gallardo.kev...@gmail.com
> >>  wrote:
> >>> 
> >>> 
> >>> On 2016-07-19 18:02 (+0100), Robert Dale  wrote:
>  - It seems redundant to nest a vertex or edge inside a type-value
>  object and is inconsistent with a VertexProperty.
>  - VertexProperty and (edge) Property are implicit types. I don't know
>  if this is ok. Could they ever be used outside of their parents where
>  they would need to be typed?
> >>> 
> >>> I agree with the VertexProperty remark. That's one last question I wanted 
> >>> to solve, if we go for typing Vertex and edges, do we include others? The 
> >>> full list I see then is : vertex/edge/vertexproperty/property/graph.
> >>> 
> >>> However I am not sure how useful it is to have more than Vertex and Edge. 
> >>> As, when deserializing a Vertex for example, there's no question as to 
> >>> what is in the "properties" field of the Vertex, there are necessarily 
> >>> only VertexProperties. However looking at the API, it seems like it is 
> >>> supported to write only a VertexProperty if one wants to (see 
> >>> GraphWriter.writeVertexProperty()), so in that case, to me it makes sense 
> >>> to add the types for the elements of the list I described above. @stephen 
> >>> any thoughts about that ?
> >>> 
>  - Edges:
>  - is in/outVLabel new? Couldn't find it in the API or any examples of 
>  this.
>  - why not make inV/outV have proper vertices with labels (to satisfy
>  the case previous case) instead of just IDs? This would also be more
>  consistent with the API.
> >>> 
> >>> I haven't touched that part, it was in the format before. I believe this 
> >>> is a question for Stephen.
> >>> 
>  
>  Otherwise looks good!
> >>> 
> >>> Thanks for the feedback.
>  
>  On Tue, Jul 19, 2016 at 12:05 PM, gallardo.kev...@gmail.com
>   wrote:
> > 
> > 
> > On 2016-07-15 16:25 (+0100), 
> > "gallardo.kev...@gmail.com" wrote:
> >> 
> >> 
> >> On 2016-07-09 16:48 (+0100), Stephen Mallette  
> >> wrote:
> >>> With all the work on GLVs and the recent work on GraphSON 2.0, I 
> >>> think it's
> >>> important that we have a solid, efficient, programming language 
> >>> neutral,
> >>> lossless serialization format. Right now that format is GraphSON and 
> >>> it
> >>> works for that purpose (ever more  so with 2.0). Given some 
> >>> discussion on
> >>> the GraphSON 2.0

[jira] [Commented] (TINKERPOP-1179) AppVeyor Windows build is not stable

2016-07-20 Thread stephen mallette (JIRA) 

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

stephen mallette commented on TINKERPOP-1179:
-

[~velobr] i noticed that appveyor seems to have been turned off by apache (i'm 
just guessing as they had control of the account). i like the idea of a 
"windows build" for TinkerPop as it might encourage windows folks to contribute 
and eliminate some mailing list questions when the build fails on that OS, 
however this issue really doesn't affect me so i'm not actively working on it. 

i'm not sure if this issue still interests you as it's been open a while 
without too much new additional activity, but if it does could you please let 
me know your thoughts on it when you get a moment? 

> AppVeyor Windows build is not stable 
> -
>
> Key: TINKERPOP-1179
> URL: https://issues.apache.org/jira/browse/TINKERPOP-1179
> Project: TinkerPop
>  Issue Type: Bug
>  Components: build-release
>Affects Versions: 3.1.1-incubating
>Reporter: stephen mallette
>
> Since we merged in the working branch of appveyor there have been very few 
> stable builds.  That lack of stability makes it look like all of our PRs are 
> "red" when they really aren't as Travis is successful.
> I've temporarily modified appveyor.yml to just do a {{mvn clean validate}} 
> until it can be proven that the appveyor build is stable.  There are 
> currently several fail points that seem to recur, but I can't say for sure 
> that these are all the errors:
> 1. ProfileTest
> {code}
> ProfileTest$Traversals>ProfileTest.g_V_sideEffectXThread_sleepX10XX_sideEffectXThread_sleepX5XX_profile:173
>  Duration should be at least the length of the sleep (59ms): 51
> {code}
> This timed test has always given some problems here and there, but i don't 
> think we've seen it as a problem in months given the last set of tweaks 
> performed to it.  We could mark this test as "non-deterministic" and it would 
> be ignored for the standard build..not sure if that's the right way to go.
> 2. Archetypes modules won't compile
> {code}
> [ERROR] Failed to execute goal 
> org.apache.maven.plugins:maven-archetype-plugin:2.4:integration-test 
> (default) on project gremlin-archetype-tinkergraph: 
> [ERROR] Archetype IT 'standard' failed: Cannot run additions goals. 
> [ERROR] -> [Help 1] 
> [ERROR] Failed to execute goal org.apache.maven.plugins:maven-archety
> {code}
> 3. Weirdness with GroupSideEffectStepV3D0Test:
> {code}
> [ERROR] 
> /C:/projects/incubator-tinkerpop/gremlin-core/src/test/java/org/apache/tinkerpop/gremlin/process/traversal/step/sideEffect/GroupSideEffectStepV3D0Test.java:[37,8]
>  class GroupSideEffectStepV3d0Test is public, should be declared in a file 
> named GroupSideEffectStepV3d0Test.java
> {code}



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

[jira] [Updated] (TINKERPOP-1380) dedup() doesn't dedup in rare cases

2016-07-20 Thread Daniel Kuppitz (JIRA) 

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

Daniel Kuppitz updated TINKERPOP-1380:
--
Description: 
I stumbled across this issue when I tried to solve a problem on the mailing 
list. It seems like a lot of steps need to be involved in order to make it 
reproducible.

{code}
gremlin> :set max-iteration 10
gremlin> 
gremlin> g = TinkerFactory.createModern().traversal().withComputer()
==>graphtraversalsource[tinkergraph[vertices:6 edges:6], graphcomputer]
gremlin> 
g.V().repeat(both()).until(cyclicPath()).path().aggregate("x").cap("x").unfold().dedup()
==>[v[1], v[2], v[1]]
==>[v[1], v[2], v[1]]
==>[v[1], v[3], v[1]]
==>[v[1], v[3], v[1]]
==>[v[1], v[4], v[1]]
==>[v[1], v[4], v[1]]
==>[v[2], v[1], v[2]]
==>[v[2], v[1], v[2]]
==>[v[3], v[1], v[3]]
==>[v[3], v[1], v[3]]
...
{code}

I can't reproduce it w/o using {{repeat()}}, {{aggregate()}} or {{cap()}}. It 
is reproducible without {{path()}} though. And then it even gets a little 
worse; check this out:

{code}
gremlin> 
g.V().repeat(both()).until(cyclicPath()).aggregate("x").cap("x").unfold().dedup()
==>v[1]
==>v[1]
==>v[2]
==>v[2]
==>v[3]
==>v[3]
==>v[4]
==>v[4]
==>v[5]
==>v[5]
...
gremlin> 
g.V().repeat(both()).until(cyclicPath()).aggregate("x").cap("x").unfold().dedup().dedup()
java.lang.RuntimeException: java.lang.IllegalStateException: 
java.lang.IllegalArgumentException: The memory can only be set() during vertex 
program setup and terminate: x
Display stack trace? [yN]
{code}

The exception occurs only in OLAP mode, but also for more meaningful patterns 
({{.dedup().dedup()}} really doesn't make much sense).

For a better / larger example see: 
https://groups.google.com/d/msg/gremlin-users/NMXExuvDjt0/ps7bJDYwAQAJ

  was:
I stumbled across this issue when I tried to solve a problem on the mailing 
list. It seems like a lot of steps need to be involved in order to make it 
reproducible.

{code}
gremlin> :set max-iteration 10
gremlin> 
gremlin> g = TinkerFactory.createModern().traversal().withComputer()
==>graphtraversalsource[tinkergraph[vertices:6 edges:6], graphcomputer]
gremlin> 
g.V().repeat(both()).until(cyclicPath()).path().aggregate("x").cap("x").unfold().dedup()
==>[v[1], v[2], v[1]]
==>[v[1], v[2], v[1]]
==>[v[1], v[3], v[1]]
==>[v[1], v[3], v[1]]
==>[v[1], v[4], v[1]]
==>[v[1], v[4], v[1]]
==>[v[2], v[1], v[2]]
==>[v[2], v[1], v[2]]
==>[v[3], v[1], v[3]]
==>[v[3], v[1], v[3]]
...
{code}

I can't reproduce it w/o using {{repeat()}}, {{aggregate()}} or {{cap()}}. It 
is reproducible without {{path()}} though. And then it even gets a little 
worse; check this out:

{code}
gremlin> 
g.V().repeat(both()).until(cyclicPath()).aggregate("x").cap("x").unfold().dedup()
==>v[1]
==>v[1]
==>v[2]
==>v[2]
==>v[3]
==>v[3]
==>v[4]
==>v[4]
==>v[5]
==>v[5]
...
gremlin> 
g.V().repeat(both()).until(cyclicPath()).aggregate("x").cap("x").unfold().dedup().dedup()
java.lang.RuntimeException: java.lang.IllegalStateException: 
java.lang.IllegalArgumentException: The memory can only be set() during vertex 
program setup and terminate: x
Display stack trace? [yN]
{code}

The exception occurs only in OLAP mode, but also for more meaningful patterns 
({{.dedup().dedup()}} really doesn't make much sense)


> dedup() doesn't dedup in rare cases
> ---
>
> Key: TINKERPOP-1380
> URL: https://issues.apache.org/jira/browse/TINKERPOP-1380
> Project: TinkerPop
>  Issue Type: Bug
>  Components: process
>Affects Versions: 3.2.1
>Reporter: Daniel Kuppitz
>
> I stumbled across this issue when I tried to solve a problem on the mailing 
> list. It seems like a lot of steps need to be involved in order to make it 
> reproducible.
> {code}
> gremlin> :set max-iteration 10
> gremlin> 
> gremlin> g = TinkerFactory.createModern().traversal().withComputer()
> ==>graphtraversalsource[tinkergraph[vertices:6 edges:6], graphcomputer]
> gremlin> 
> g.V().repeat(both()).until(cyclicPath()).path().aggregate("x").cap("x").unfold().dedup()
> ==>[v[1], v[2], v[1]]
> ==>[v[1], v[2], v[1]]
> ==>[v[1], v[3], v[1]]
> ==>[v[1], v[3], v[1]]
> ==>[v[1], v[4], v[1]]
> ==>[v[1], v[4], v[1]]
> ==>[v[2], v[1], v[2]]
> ==>[v[2], v[1], v[2]]
> ==>[v[3], v[1], v[3]]
> ==>[v[3], v[1], v[3]]
> ...
> {code}
> I can't reproduce it w/o using {{repeat()}}, {{aggregate()}} or {{cap()}}. It 
> is reproducible without {{path()}} though. And then it even gets a little 
> worse; check this out:
> {code}
> gremlin> 
> g.V().repeat(both()).until(cyclicPath()).aggregate("x").cap("x").unfold().dedup()
> ==>v[1]
> ==>v[1]
> ==>v[2]
> ==>v[2]
> ==>v[3]
> ==>v[3]
> ==>v[4]
> ==>v[4]
> ==>v[5]
> ==>v[5]
> ...
> gremlin> 
> g.V().repeat(both()).until(cyclicPath()).aggregate("x").cap("x").unfold().dedup().dedup()
> java.lang.RuntimeException: java.lang.IllegalStateException: 
>

[jira] [Created] (TINKERPOP-1380) dedup() doesn't dedup in rare cases

2016-07-20 Thread Daniel Kuppitz (JIRA) 
Daniel Kuppitz created TINKERPOP-1380:
-

 Summary: dedup() doesn't dedup in rare cases
 Key: TINKERPOP-1380
 URL: https://issues.apache.org/jira/browse/TINKERPOP-1380
 Project: TinkerPop
  Issue Type: Bug
  Components: process
Affects Versions: 3.2.1
Reporter: Daniel Kuppitz


I stumbled across this issue when I tried to solve a problem on the mailing 
list. It seems like a lot of steps need to be involved in order to make it 
reproducible.

{code}
gremlin> :set max-iteration 10
gremlin> 
gremlin> g = TinkerFactory.createModern().traversal().withComputer()
==>graphtraversalsource[tinkergraph[vertices:6 edges:6], graphcomputer]
gremlin> 
g.V().repeat(both()).until(cyclicPath()).path().aggregate("x").cap("x").unfold().dedup()
==>[v[1], v[2], v[1]]
==>[v[1], v[2], v[1]]
==>[v[1], v[3], v[1]]
==>[v[1], v[3], v[1]]
==>[v[1], v[4], v[1]]
==>[v[1], v[4], v[1]]
==>[v[2], v[1], v[2]]
==>[v[2], v[1], v[2]]
==>[v[3], v[1], v[3]]
==>[v[3], v[1], v[3]]
...
{code}

I can't reproduce it w/o using {{repeat()}}, {{aggregate()}} or {{cap()}}. It 
is reproducible without {{path()}} though. And then it even gets a little 
worse; check this out:

{code}
gremlin> 
g.V().repeat(both()).until(cyclicPath()).aggregate("x").cap("x").unfold().dedup()
==>v[1]
==>v[1]
==>v[2]
==>v[2]
==>v[3]
==>v[3]
==>v[4]
==>v[4]
==>v[5]
==>v[5]
...
gremlin> 
g.V().repeat(both()).until(cyclicPath()).aggregate("x").cap("x").unfold().dedup().dedup()
java.lang.RuntimeException: java.lang.IllegalStateException: 
java.lang.IllegalArgumentException: The memory can only be set() during vertex 
program setup and terminate: x
Display stack trace? [yN]
{code}



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