[GitHub] tinkerpop issue #366: TINKERPOP-1379 remove excess bulk in tail buffer
Github user okram commented on the issue: https://github.com/apache/tinkerpop/pull/366 VOTE +1. Note that I added a comment for how to make the test case simpler. --- 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. ---
[jira] [Commented] (TINKERPOP-1379) unaccounted excess in TailGlobalStep
[
https://issues.apache.org/jira/browse/TINKERPOP-1379?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15408294#comment-15408294
]
ASF GitHub Bot commented on TINKERPOP-1379:
---
Github user okram commented on a diff in the pull request:
https://github.com/apache/tinkerpop/pull/366#discussion_r73580040
--- Diff:
gremlin-test/src/main/java/org/apache/tinkerpop/gremlin/process/traversal/step/filter/TailTest.java
---
@@ -120,6 +123,19 @@ public void g_V_repeatXbothX_timesX3X_tailX7X() {
assertEquals(7, counter);
}
+/** Scenario: Global scope, using repeat (excess BULK) */
+@Test
+@LoadGraphWith(MODERN)
+public void g_V_repeatXin_outX_timesX3X_tailX7X_count() {
+final Traversal traversal =
get_g_V_repeatXin_outX_timesX3X_tailX7X_count();
+printTraversalForm(traversal);
+long count = 0L;
--- End diff --
This is as easy as:
```
checkResults(Collections.singleList(7L), traversal)
```
It will also verify `hasNext() == false` at the end.
> 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.0.2-incubating, 3.1.3, 3.2.1
>Reporter: Jason Plurad
> Fix For: 3.1.4, 3.2.2, 3.3.0
>
>
> 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)
[jira] [Commented] (TINKERPOP-1379) unaccounted excess in TailGlobalStep
[
https://issues.apache.org/jira/browse/TINKERPOP-1379?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15408295#comment-15408295
]
ASF GitHub Bot commented on TINKERPOP-1379:
---
Github user okram commented on the issue:
https://github.com/apache/tinkerpop/pull/366
VOTE +1.
Note that I added a comment for how to make the test case simpler.
> 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.0.2-incubating, 3.1.3, 3.2.1
>Reporter: Jason Plurad
> Fix For: 3.1.4, 3.2.2, 3.3.0
>
>
> 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 #366: TINKERPOP-1379 remove excess bulk in tail buffe...
Github user okram commented on a diff in the pull request:
https://github.com/apache/tinkerpop/pull/366#discussion_r73580040
--- Diff:
gremlin-test/src/main/java/org/apache/tinkerpop/gremlin/process/traversal/step/filter/TailTest.java
---
@@ -120,6 +123,19 @@ public void g_V_repeatXbothX_timesX3X_tailX7X() {
assertEquals(7, counter);
}
+/** Scenario: Global scope, using repeat (excess BULK) */
+@Test
+@LoadGraphWith(MODERN)
+public void g_V_repeatXin_outX_timesX3X_tailX7X_count() {
+final Traversal traversal =
get_g_V_repeatXin_outX_timesX3X_tailX7X_count();
+printTraversalForm(traversal);
+long count = 0L;
--- End diff --
This is as easy as:
```
checkResults(Collections.singleList(7L), traversal)
```
It will also verify `hasNext() == false` at the end.
---
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.
---
[jira] [Commented] (TINKERPOP-1379) unaccounted excess in TailGlobalStep
[
https://issues.apache.org/jira/browse/TINKERPOP-1379?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15408290#comment-15408290
]
ASF GitHub Bot commented on TINKERPOP-1379:
---
Github user pluradj commented on the issue:
https://github.com/apache/tinkerpop/pull/366
Test case `g.V().repeat(__.in().out()).times(3).tail(7).count()` against
the modern graph returns `-62`. Fails all the way back to 3.0.x.
> 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.0.2-incubating, 3.1.3, 3.2.1
>Reporter: Jason Plurad
> Fix For: 3.1.4, 3.2.2, 3.3.0
>
>
> 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 issue #366: TINKERPOP-1379 remove excess bulk in tail buffer
Github user pluradj commented on the issue: https://github.com/apache/tinkerpop/pull/366 Test case `g.V().repeat(__.in().out()).times(3).tail(7).count()` against the modern graph returns `-62`. Fails all the way back to 3.0.x. --- 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. ---
[DISCUSS] driver for gremlin-python
TinkerPop has long held to the idea that "drivers" would be a bit like graph implementations. TinkerPop builds reference implementation of a graph and third-parties maintain "other" implementations separately. The same idea has been held for "drivers" in that we have our reference implementation of the Java driver and third-parties produce implementations for other languages. GLVs sorta changed things though. Now we have a model where we maintain GLVs of other languages in TinkerPop itself. While somewhat risky to include the added code/complexity, maintaining the GLV in TinkerPop has a lot of good advantages for users and for growing our community. We also have come up with ways to manage the risk, by establishing a really nice initial reference implementation of gremlin-python which sets a high bar for new GLVs to come in (i.e. hooked into tinkerpop test suite, automated build mixed with maven, non-native JVM language focused, etc.). Of course, by introducing GLVs to TinkerPop though, we now have the issue of conflict with TinkerPop only having a single "reference implementation" for drivers because without a driver the GLV is pretty useless. We've mitigated that in gremlin-python so far with a simple REST implementation of a driver, but as we advance the capabilities of GLVs that approach won't be good for the long term. So - it seems like we (TinkerPop) should have a driver to go with each GLV? To me, the upsides are big for users: 1. Users don't have to hunt for drivers elsewhere - they just grab their GLV and go. I suppose there is still opportunity for third-party drivers to be built, but at least users have an immediate easy option within the Apache TinkerPop. 2. Our docs for GLV usage are completely in Apache TinkerPop and are "production ready" (i.e. not REST based then go switch to something third-party) There are some downsides which basically boil down to "Mo' code Mo' problems" but basically: 1. I believe that it will be expected that we maintain some parity in terms of features and performance with the drivers. We can't have the java driver be 10x over the python driver 2. The GLV code base becomes more complex. A high performing driver will not be trivial. 3. A whole class of downsides related to GLVs in general where we don't have the necessary language expertise to maintain it - though - again, mitigated by the high bar we set with our reference implementation for gremlin-python. Also, rather than a negative, one could also see this as an opportunity to grow the TinkerPop community. Ultimately, I think all of this is outweighed by the simple fact that we need a driver in Apache TinkerPop to fully test GLVs. Without that we're kinda of stuck ourselves.
[GitHub] tinkerpop issue #372: DSP-1397 Fix StarGraph addEdge for self-edges
Github user okram commented on the issue:
https://github.com/apache/tinkerpop/pull/372
I believe there is an easier solution. However, you don't provide a test
case so I don't know if it works.
CHANGE:
```
@Override
public Edge addEdge(final String label, final Vertex inVertex,
final Object... keyValues) {
final Edge edge = this.addOutEdge(label, inVertex, keyValues);
if (inVertex.equals(this)) {
if(null == this.inEdges)
this.inEdges = new HashMap<>();
List inE = this.inEdges.get(label);
if (null == inE) {
inE = new ArrayList<>();
this.inEdges.put(label, inE);
}
inE.add(edge);
}
return edge;
}
```
TO
```
@Override
public Edge addEdge(final String label, final Vertex inVertex,
final Object... keyValues) {
final Edge edge = this.addOutEdge(label, inVertex, keyValues);
if (inVertex.equals(this)) {
if (ElementHelper.getIdValue(keyValues).isPresent())
this.addInEdge(label, this, keyValues);
else {
final Object[] keyValuesWithId =
Arrays.copyOf(keyValues,keyValues.length+2);
keyValuesWithId[keyValuesWithId.length - 2] = T.id;
keyValuesWithId[keyValuesWithId.length - 1] = edge.id();
this.addInEdge(label, this, keyValuesWithId);
}
}
return edge;
}
```
Note that when I do this, all the current tests in TinkerPop pass
(`StarGraphTest`). Moreover, I added a test case to `StarGraphTest` that uses a
`GraphFilter`. I hope it tests what you want it to (when I didn't change the
method, the test still passes :| -- thus, you may need to add a test to ensure
we get failure without the new method addEdge method).
https://github.com/apache/tinkerpop/tree/TINKERPOP-1397
Finally, I think that you might think that bothE() would only return the
edge once, it shouldn't. It should return it twice. If that is the
misunderstanding, then this is NOT an issue.
```
gremlin> g.V(0l).bothE()
==>e[1][0-self->0]
==>e[1][0-self->0]
```
---
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.
---
[jira] [Updated] (TINKERPOP-1151) slf4j-log4j12 / log4j is only required for testing
[ https://issues.apache.org/jira/browse/TINKERPOP-1151?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] stephen mallette updated TINKERPOP-1151: Assignee: stephen mallette External issue URL: (was: https://github.com/apache/incubator-tinkerpop/pull/229) Labels: breaking (was: ) Labelled this issue as "breaking" - not sure that anyone will notice a break but we do muck with dependencies a little bit so if someone was depending on TinkerPop to get their log4j dependency they'll have to make an adjustment to their pom. My PR mentions all this in the upgrade docs. > slf4j-log4j12 / log4j is only required for testing > -- > > Key: TINKERPOP-1151 > URL: https://issues.apache.org/jira/browse/TINKERPOP-1151 > Project: TinkerPop > Issue Type: Bug > Components: build-release >Affects Versions: 3.1.0-incubating >Reporter: Hendy Irawan >Assignee: stephen mallette >Priority: Trivial > Labels: breaking > > Pull request: https://github.com/apache/incubator-tinkerpop/pull/229 -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (TINKERPOP-1151) slf4j-log4j12 / log4j is only required for testing
[ https://issues.apache.org/jira/browse/TINKERPOP-1151?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15408085#comment-15408085 ] ASF GitHub Bot commented on TINKERPOP-1151: --- GitHub user spmallette opened a pull request: https://github.com/apache/tinkerpop/pull/373 TINKERPOP-1151 Made a number of changes to logging dependencies. https://issues.apache.org/jira/browse/TINKERPOP-1151 Log4j is now generally a test dependency except for gremlin-server and gremlin-console where they need to be shipped as part of the binary distribution. In that case, they are optional scope for those who for some reason depend on those libs. I tested this a bunch of different ways: * `mvn clean install` shows the expected log messages * `mvn clean install -DskipIntegrationTests` shows the expected log messages * Gremlin Console displays log messages that aren't hidden by the default config and changes to that config allow logs to show in full * Gremlin Server displays expected log messages * Looked at the zip distributions and they obviously had the appropriate log4j jars * Tested builds of both archetype outputs and logging is good within those Anything else i missed where logging would be an issue? if not then VOTE +1 for me You can merge this pull request into a Git repository by running: $ git pull https://github.com/apache/tinkerpop TINKERPOP-1151 Alternatively you can review and apply these changes as the patch at: https://github.com/apache/tinkerpop/pull/373.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 #373 commit 8bf021d28465b3cd88d66baaeacd380161f86086 Author: Stephen Mallette Date: 2016-08-04T16:26:43Z Made a number of changes to logging dependencies. Log4j is now generally a test dependency except for gremlin-server and gremlin-console where they need to be shipped as part of the binary distribution. In that case, they are optional scope for those who for some reason depend on those libs. > slf4j-log4j12 / log4j is only required for testing > -- > > Key: TINKERPOP-1151 > URL: https://issues.apache.org/jira/browse/TINKERPOP-1151 > Project: TinkerPop > Issue Type: Bug > Components: build-release >Affects Versions: 3.1.0-incubating >Reporter: Hendy Irawan >Priority: Trivial > > Pull request: https://github.com/apache/incubator-tinkerpop/pull/229 -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[GitHub] tinkerpop pull request #373: TINKERPOP-1151 Made a number of changes to logg...
GitHub user spmallette opened a pull request: https://github.com/apache/tinkerpop/pull/373 TINKERPOP-1151 Made a number of changes to logging dependencies. https://issues.apache.org/jira/browse/TINKERPOP-1151 Log4j is now generally a test dependency except for gremlin-server and gremlin-console where they need to be shipped as part of the binary distribution. In that case, they are optional scope for those who for some reason depend on those libs. I tested this a bunch of different ways: * `mvn clean install` shows the expected log messages * `mvn clean install -DskipIntegrationTests` shows the expected log messages * Gremlin Console displays log messages that aren't hidden by the default config and changes to that config allow logs to show in full * Gremlin Server displays expected log messages * Looked at the zip distributions and they obviously had the appropriate log4j jars * Tested builds of both archetype outputs and logging is good within those Anything else i missed where logging would be an issue? if not then VOTE +1 for me You can merge this pull request into a Git repository by running: $ git pull https://github.com/apache/tinkerpop TINKERPOP-1151 Alternatively you can review and apply these changes as the patch at: https://github.com/apache/tinkerpop/pull/373.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 #373 commit 8bf021d28465b3cd88d66baaeacd380161f86086 Author: Stephen Mallette Date: 2016-08-04T16:26:43Z Made a number of changes to logging dependencies. Log4j is now generally a test dependency except for gremlin-server and gremlin-console where they need to be shipped as part of the binary distribution. In that case, they are optional scope for those who for some reason depend on those libs. --- 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: [DISCUSS] Download Page
Yeah I think we can be incremental about this. - add the site to /site as is. This way even if it's a pain people can contribute - make a publish-site.sh - add some form of template system (probably to publish-site.sh) - finalize with documentation? < or add it as we go On Thu, Aug 4, 2016 at 10:12 AM, Stephen Mallette wrote: > There's not a lot of pages - true - though when i wear the release manager > hat i have grumble every time i have to go through all the links trying to > get it right. invariably i make a change, then copy/paste to the others > only to find i misspelled something or missed a link. it just sucks. That > said, i'm open to the idea of moving the site as-is to the git repo under a > /site directory. that would be the first step to doing the static site > generation anyway. > > if it doesn't hinge on static site generation, then perhaps it should hinge > on a little script or something that will bin/publish-site.sh - that would > be nice. > > On Thu, Aug 4, 2016 at 9:14 AM, Robert Dale wrote: > > > Stephen, please correct me where I'm wrong, but after mirroring the > > site and removing docs and javadocs since these are generated, it > > would appear that there are only 7 html files to the website. It's not > > clear to me that at this point the effort of creating or moving to a > > template engine is worth the effort. I would rather see the static > > site as-is move to version control sooner rather than later and not > > hinge upon generation. > > > > On Wed, Aug 3, 2016 at 1:38 PM, Dylan Millikin > > > wrote: > > > The groovy template engine could work just fine. > > > FYI : > > > > > http://stackoverflow.com/questions/3793880/lightweight- > template-engine-in-java > > > There might be a few interested template engines there as well. > > > > > > On Wed, Aug 3, 2016 at 9:40 AM, Stephen Mallette > > > > wrote: > > > > > >> Yeah - i'm not so good with the sed to the awk to the grep or whatever > > so > > >> if it can be that simple that would be awesome. The groovy template > > engine > > >> might be another option. Something like that would work easy enough > too > > I > > >> would guess. I really don't think we need much more than that right > now. > > >> > > >> Organizationally, I think we should have a /site directory at the root > > of > > >> the repo to house the images/html template content and then have it > > >> generate into root /target/site from bin/generate-site.sh. > > >> > > >> On Wed, Aug 3, 2016 at 9:29 AM, Dylan Millikin < > > dylan.milli...@gmail.com> > > >> wrote: > > >> > > >> > Hmm sounds like what we would want would be a template engine that > > would > > >> > help us build the static site. > > >> > If all we need are includes that put together html partials > > >> > (headers/footers) we could make our own. It could be as simple as > > using > > >> sed > > >> > in bin/generate-web-site.sh > > >> > > > >> > On Wed, Aug 3, 2016 at 9:03 AM, Stephen Mallette < > > spmalle...@gmail.com> > > >> > wrote: > > >> > > > >> > > yes - static html/css and it sucks a bit because we don't have any > > >> re-use > > >> > > going on there. so if we have to change a menu or something it > means > > >> > > changing it on every page in the site. would be nice to have some > > >> > re-usable > > >> > > headers/footers and such. i looked into some static site > generators > > a > > >> > while > > >> > > back, but they all seemed like they did too much. maybe i didn't > > know > > >> > what > > >> > > to look for. > > >> > > > > >> > > On Wed, Aug 3, 2016 at 9:00 AM, Dylan Millikin < > > >> dylan.milli...@gmail.com > > >> > > > > >> > > wrote: > > >> > > > > >> > > > How is the current site structured? Is it just HTML and CSS > files? > > >> > > > > > >> > > > On Tue, Aug 2, 2016 at 6:20 PM, Stephen Mallette < > > >> spmalle...@gmail.com > > >> > > > > >> > > > wrote: > > >> > > > > > >> > > > > no - we don't have one for the main web site. i've wanted to > > >> suggest > > >> > > that > > >> > > > > we change that though and generate the main web site from the > > >> github > > >> > > > repo. > > >> > > > > in that way we could easily accept pull requests and such. i > > don't > > >> > > think > > >> > > > we > > >> > > > > want to take a full asciidoc approach and the web site > > generation > > >> > would > > >> > > > > probably stay separate from the doc generation, but it would > be > > >> nice > > >> > if > > >> > > > we > > >> > > > > could bin/generate-web-site.sh for a local build of that that > > thing > > >> > > which > > >> > > > > could then be published to the apache svn repo. anyone else > like > > >> that > > >> > > > idea? > > >> > > > > if so, how would it best be done? > > >> > > > > > > >> > > > > > > >> > > > > > > >> > > > > On Tue, Aug 2, 2016 at 5:05 PM, Robert Dale < > robd...@gmail.com> > > >> > wrote: > > >> > > > > > > >> > > > > > Is there a git repo for this and the main website? I would > > like > > >> to > > >> > > > > > make pull requests to fix
[GitHub] tinkerpop pull request #371: Added new recipe for Traversal Induced Values.
Github user spmallette commented on a diff in the pull request:
https://github.com/apache/tinkerpop/pull/371#discussion_r73552034
--- Diff: docs/src/recipes/traversal-induced-values.asciidoc ---
@@ -0,0 +1,83 @@
+
+Licensed to the Apache Software Foundation (ASF) under one or more
+contributor license agreements. See the NOTICE file distributed with
+this work for additional information regarding copyright ownership.
+The ASF licenses this file to You under the Apache License, Version 2.0
+(the "License"); you may not use this file except in compliance with
+the License. You may obtain a copy of the License at
+
+ http://www.apache.org/licenses/LICENSE-2.0
+
+Unless required by applicable law or agreed to in writing, software
+distributed under the License is distributed on an "AS IS" BASIS,
+WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
+See the License for the specific language governing permissions and
+limitations under the License.
+
+[[traversal-induced-values]]
+Traversal Induced Values
+
+
+The parameters of a `Traversal` can be known ahead of time as constants or
might otherwise be passed in as dynamic
+arguments.
+
+[gremlin-groovy,modern]
+
+g.V().has('name','marko').out('knows').has('age', gt(29)).values('name')
+
+
+In plain language, the above Gremlin asks, "What are the names of the
people who Marko knows who are over the age of
+29?". In this case, "29" is known as a constant to the traversal. Of
course, if the question is changed slightly to
+instead ask, "What are the names of the people who Marko knows who are
older than he is?", the hardcoding of "29" will
+no longer suffice. There are multiple ways Gremlin would allow this second
question to be answered. The first is
+obvious to any programmer - use a variable:
+
+[gremlin-groovy,modern]
+
+marko = g.V().has('name','marko').next()
+g.V(marko).out('knows').has('age', gt(marko.value('age'))).values('name')
+
+
+The downside to this approach is that it takes two separate traversals to
answer the question. Ideally, there should
+be a single traversal, that can query "marko" once, determine his `age`
and then use that for the value supplied to
+filter the people he knows. In this way the _value_ for the `age` filter
is _induced_ from the `Traversal` itself.
+
+[gremlin-groovy,modern]
+
+g.V().has('name','marko').as('marko'). <1>
+ out('knows').as('friend'). <2>
+ filter(select('marko','friend').by('age'). <3>
+ where('friend', gt('marko'))).<4>
+ values('name')
+
+
+<1> Find the "marko" `Vertex` and label it as "marko".
+<2> Traverse out on the "knows" edges to the adjacent `Vertex` and label
it as "person".
+<3> Filter the incoming "person" vertices. It is within this filter, that
the traversal induced values are utilized.
+The inner `select` grabs the "marko" vertex and the current "friend". The
`by` modulator extracts the "age" from both
+of those vertices which yields a `Map` with two keys, "marko" and
"friend", where the value of each is the "age".
+<4> The `Map` produced in the previous step can then be filtered with
`where` to only return a result if the "friend"
+age is greater than the "marko" age. If this is successful, then the
`filter` step from the previous line will succeed
+and allow the "friend" vertex to pass through.
+
+This traversal could also be written declaratively with `match` step as
follows:
--- End diff --
I thought about going into more detail there, but opted not to. I kinda
thought that if we wanted that sort of content that it didn't belong in a
recipe but in reference docs. It seemed a little out of scope of the recipe.
---
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.
---
[jira] [Created] (TINKERPOP-1399) NumberHelper needs to go into util and have a private constructor
Marko A. Rodriguez created TINKERPOP-1399:
-
Summary: NumberHelper needs to go into util and have a private
constructor
Key: TINKERPOP-1399
URL: https://issues.apache.org/jira/browse/TINKERPOP-1399
Project: TinkerPop
Issue Type: Improvement
Components: process
Affects Versions: 3.2.1
Reporter: Marko A. Rodriguez
Assignee: Daniel Kuppitz
{{NumberHelper}} is in the {{traversal/}} package. That is not good as its just
a utility class. It should be moved to {{traversal/util}}. Moreover, it needs a
private constructor so it can't be built as all methods are public static.
This would be a breaking change though I doubt anyone uses this class outside
of internal TinkerPop.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (TINKERPOP-1398) 3.2.0-incubating javadocs link broken
[ https://issues.apache.org/jira/browse/TINKERPOP-1398?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] stephen mallette updated TINKERPOP-1398: Affects Version/s: (was: 3.2.0-incubating) > 3.2.0-incubating javadocs link broken > - > > Key: TINKERPOP-1398 > URL: https://issues.apache.org/jira/browse/TINKERPOP-1398 > Project: TinkerPop > Issue Type: Bug > Components: documentation >Reporter: Robert Dale >Assignee: stephen mallette >Priority: Trivial > Labels: documentation > Original Estimate: 5m > Remaining Estimate: 5m > > tinkerpop.apache.og -> Download -> 3.2.0-incubating -> javadoc > Should point to http://tinkerpop.apache.org/javadocs/3.2.0-incubating/full/ -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Closed] (TINKERPOP-1398) 3.2.0-incubating javadocs link broken
[ https://issues.apache.org/jira/browse/TINKERPOP-1398?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] stephen mallette closed TINKERPOP-1398. --- Resolution: Done > 3.2.0-incubating javadocs link broken > - > > Key: TINKERPOP-1398 > URL: https://issues.apache.org/jira/browse/TINKERPOP-1398 > Project: TinkerPop > Issue Type: Bug > Components: documentation >Reporter: Robert Dale >Assignee: stephen mallette >Priority: Trivial > Labels: documentation > Original Estimate: 5m > Remaining Estimate: 5m > > tinkerpop.apache.og -> Download -> 3.2.0-incubating -> javadoc > Should point to http://tinkerpop.apache.org/javadocs/3.2.0-incubating/full/ -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Reopened] (TINKERPOP-1398) 3.2.0-incubating javadocs link broken
[ https://issues.apache.org/jira/browse/TINKERPOP-1398?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] stephen mallette reopened TINKERPOP-1398: - > 3.2.0-incubating javadocs link broken > - > > Key: TINKERPOP-1398 > URL: https://issues.apache.org/jira/browse/TINKERPOP-1398 > Project: TinkerPop > Issue Type: Bug > Components: documentation >Reporter: Robert Dale >Assignee: stephen mallette >Priority: Trivial > Labels: documentation > Original Estimate: 5m > Remaining Estimate: 5m > > tinkerpop.apache.og -> Download -> 3.2.0-incubating -> javadoc > Should point to http://tinkerpop.apache.org/javadocs/3.2.0-incubating/full/ -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Closed] (TINKERPOP-1398) 3.2.0-incubating javadocs link broken
[ https://issues.apache.org/jira/browse/TINKERPOP-1398?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] stephen mallette closed TINKERPOP-1398. --- Resolution: Done Assignee: stephen mallette Fix Version/s: (was: 3.2.2) Both the javadoc and reference docs links were bad - fixed both. thanks. not assigning a fix version as this change to the main web site isn't really pinned to the release cycle at this point. > 3.2.0-incubating javadocs link broken > - > > Key: TINKERPOP-1398 > URL: https://issues.apache.org/jira/browse/TINKERPOP-1398 > Project: TinkerPop > Issue Type: Bug > Components: documentation >Reporter: Robert Dale >Assignee: stephen mallette >Priority: Trivial > Labels: documentation > Original Estimate: 5m > Remaining Estimate: 5m > > tinkerpop.apache.og -> Download -> 3.2.0-incubating -> javadoc > Should point to http://tinkerpop.apache.org/javadocs/3.2.0-incubating/full/ -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (TINKERPOP-1398) 3.2.0-incubating javadocs link broken
Robert Dale created TINKERPOP-1398: -- Summary: 3.2.0-incubating javadocs link broken Key: TINKERPOP-1398 URL: https://issues.apache.org/jira/browse/TINKERPOP-1398 Project: TinkerPop Issue Type: Bug Components: documentation Affects Versions: 3.2.0-incubating Reporter: Robert Dale Priority: Trivial Fix For: 3.2.2 tinkerpop.apache.og -> Download -> 3.2.0-incubating -> javadoc Should point to http://tinkerpop.apache.org/javadocs/3.2.0-incubating/full/ -- This message was sent by Atlassian JIRA (v6.3.4#6332)
Re: [DISCUSS] Download Page
There's not a lot of pages - true - though when i wear the release manager hat i have grumble every time i have to go through all the links trying to get it right. invariably i make a change, then copy/paste to the others only to find i misspelled something or missed a link. it just sucks. That said, i'm open to the idea of moving the site as-is to the git repo under a /site directory. that would be the first step to doing the static site generation anyway. if it doesn't hinge on static site generation, then perhaps it should hinge on a little script or something that will bin/publish-site.sh - that would be nice. On Thu, Aug 4, 2016 at 9:14 AM, Robert Dale wrote: > Stephen, please correct me where I'm wrong, but after mirroring the > site and removing docs and javadocs since these are generated, it > would appear that there are only 7 html files to the website. It's not > clear to me that at this point the effort of creating or moving to a > template engine is worth the effort. I would rather see the static > site as-is move to version control sooner rather than later and not > hinge upon generation. > > On Wed, Aug 3, 2016 at 1:38 PM, Dylan Millikin > wrote: > > The groovy template engine could work just fine. > > FYI : > > > http://stackoverflow.com/questions/3793880/lightweight-template-engine-in-java > > There might be a few interested template engines there as well. > > > > On Wed, Aug 3, 2016 at 9:40 AM, Stephen Mallette > > wrote: > > > >> Yeah - i'm not so good with the sed to the awk to the grep or whatever > so > >> if it can be that simple that would be awesome. The groovy template > engine > >> might be another option. Something like that would work easy enough too > I > >> would guess. I really don't think we need much more than that right now. > >> > >> Organizationally, I think we should have a /site directory at the root > of > >> the repo to house the images/html template content and then have it > >> generate into root /target/site from bin/generate-site.sh. > >> > >> On Wed, Aug 3, 2016 at 9:29 AM, Dylan Millikin < > dylan.milli...@gmail.com> > >> wrote: > >> > >> > Hmm sounds like what we would want would be a template engine that > would > >> > help us build the static site. > >> > If all we need are includes that put together html partials > >> > (headers/footers) we could make our own. It could be as simple as > using > >> sed > >> > in bin/generate-web-site.sh > >> > > >> > On Wed, Aug 3, 2016 at 9:03 AM, Stephen Mallette < > spmalle...@gmail.com> > >> > wrote: > >> > > >> > > yes - static html/css and it sucks a bit because we don't have any > >> re-use > >> > > going on there. so if we have to change a menu or something it means > >> > > changing it on every page in the site. would be nice to have some > >> > re-usable > >> > > headers/footers and such. i looked into some static site generators > a > >> > while > >> > > back, but they all seemed like they did too much. maybe i didn't > know > >> > what > >> > > to look for. > >> > > > >> > > On Wed, Aug 3, 2016 at 9:00 AM, Dylan Millikin < > >> dylan.milli...@gmail.com > >> > > > >> > > wrote: > >> > > > >> > > > How is the current site structured? Is it just HTML and CSS files? > >> > > > > >> > > > On Tue, Aug 2, 2016 at 6:20 PM, Stephen Mallette < > >> spmalle...@gmail.com > >> > > > >> > > > wrote: > >> > > > > >> > > > > no - we don't have one for the main web site. i've wanted to > >> suggest > >> > > that > >> > > > > we change that though and generate the main web site from the > >> github > >> > > > repo. > >> > > > > in that way we could easily accept pull requests and such. i > don't > >> > > think > >> > > > we > >> > > > > want to take a full asciidoc approach and the web site > generation > >> > would > >> > > > > probably stay separate from the doc generation, but it would be > >> nice > >> > if > >> > > > we > >> > > > > could bin/generate-web-site.sh for a local build of that that > thing > >> > > which > >> > > > > could then be published to the apache svn repo. anyone else like > >> that > >> > > > idea? > >> > > > > if so, how would it best be done? > >> > > > > > >> > > > > > >> > > > > > >> > > > > On Tue, Aug 2, 2016 at 5:05 PM, Robert Dale > >> > wrote: > >> > > > > > >> > > > > > Is there a git repo for this and the main website? I would > like > >> to > >> > > > > > make pull requests to fix some things. > >> > > > > > > >> > > > > > On Fri, Jul 29, 2016 at 1:49 PM, Stephen Mallette < > >> > > > spmalle...@gmail.com> > >> > > > > > wrote: > >> > > > > > > The download page is now "live" > >> > > > > > > > >> > > > > > > On Thu, Jul 28, 2016 at 7:14 PM, Stephen Mallette < > >> > > > > spmalle...@gmail.com> > >> > > > > > > wrote: > >> > > > > > > > >> > > > > > >> I assume everyone is cool with making the Download Page > live > >> at > >> > > this > >> > > > > > point > >> > > > > > >> as there's been no other feedback in the last few days. > I'll > >> > > > probably > >> > > > > > make > >> > >
[jira] [Commented] (TINKERPOP-1350) Server locks when submitting parallel requests on session
[
https://issues.apache.org/jira/browse/TINKERPOP-1350?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15407791#comment-15407791
]
ASF GitHub Bot commented on TINKERPOP-1350:
---
Github user twilmes commented on the issue:
https://github.com/apache/tinkerpop/pull/367
Code and doc updates look good.
VOTE: +1
> Server locks when submitting parallel requests on session
> -
>
> Key: TINKERPOP-1350
> URL: https://issues.apache.org/jira/browse/TINKERPOP-1350
> Project: TinkerPop
> Issue Type: Bug
> Components: server
>Affects Versions: 3.1.2-incubating
>Reporter: stephen mallette
>Assignee: stephen mallette
>Priority: Critical
> Fix For: 3.1.4, 3.2.2
>
>
> This really is only a problem when there is some form of long blocking script
> submitted and only on a session when done in parallel, like:
> {code}
> final ResultSet first = client.submit(
> "Object mon1 = 'mon1';\n" +
> "synchronized (mon1) {\n" +
> "mon1.wait();\n" +
> "} ");
> final ResultSet second = client.submit(
> "Object mon2 = 'mon2';\n" +
> "synchronized (mon2) {\n" +
> "mon2.wait();\n" +
> "}");
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[GitHub] tinkerpop issue #367: TINKERPOP-1350 was never quite fixed in 3.1.3.
Github user twilmes commented on the issue: https://github.com/apache/tinkerpop/pull/367 Code and doc updates look good. VOTE: +1 --- 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. ---
[jira] [Commented] (TINKERPOP-1388) Make ExpandableStepIterator non-final
[
https://issues.apache.org/jira/browse/TINKERPOP-1388?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15407769#comment-15407769
]
Marko A. Rodriguez commented on TINKERPOP-1388:
---
Can you explain exactly what you are trying to do? Perhaps there is an
interface that can be created? Perhaps there is a method we could add to
{{ExpandableStepIterator}}?... As you can see, I'm reluctant to open up such
low-level classes to developers.
> Make ExpandableStepIterator non-final
> -
>
> Key: TINKERPOP-1388
> URL: https://issues.apache.org/jira/browse/TINKERPOP-1388
> Project: TinkerPop
> Issue Type: Improvement
> Components: process
>Affects Versions: 3.1.3
>Reporter: Matthias Broecheler
>Assignee: stephen mallette
>Priority: Minor
> Fix For: 3.1.4, 3.2.2
>
>
> to allow TinkerPop implementations to extend it.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[GitHub] tinkerpop pull request #371: Added new recipe for Traversal Induced Values.
Github user pluradj commented on a diff in the pull request:
https://github.com/apache/tinkerpop/pull/371#discussion_r73521595
--- Diff: docs/src/recipes/traversal-induced-values.asciidoc ---
@@ -0,0 +1,83 @@
+
+Licensed to the Apache Software Foundation (ASF) under one or more
+contributor license agreements. See the NOTICE file distributed with
+this work for additional information regarding copyright ownership.
+The ASF licenses this file to You under the Apache License, Version 2.0
+(the "License"); you may not use this file except in compliance with
+the License. You may obtain a copy of the License at
+
+ http://www.apache.org/licenses/LICENSE-2.0
+
+Unless required by applicable law or agreed to in writing, software
+distributed under the License is distributed on an "AS IS" BASIS,
+WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
+See the License for the specific language governing permissions and
+limitations under the License.
+
+[[traversal-induced-values]]
+Traversal Induced Values
+
+
+The parameters of a `Traversal` can be known ahead of time as constants or
might otherwise be passed in as dynamic
+arguments.
+
+[gremlin-groovy,modern]
+
+g.V().has('name','marko').out('knows').has('age', gt(29)).values('name')
+
+
+In plain language, the above Gremlin asks, "What are the names of the
people who Marko knows who are over the age of
+29?". In this case, "29" is known as a constant to the traversal. Of
course, if the question is changed slightly to
+instead ask, "What are the names of the people who Marko knows who are
older than he is?", the hardcoding of "29" will
+no longer suffice. There are multiple ways Gremlin would allow this second
question to be answered. The first is
+obvious to any programmer - use a variable:
+
+[gremlin-groovy,modern]
+
+marko = g.V().has('name','marko').next()
+g.V(marko).out('knows').has('age', gt(marko.value('age'))).values('name')
+
+
+The downside to this approach is that it takes two separate traversals to
answer the question. Ideally, there should
+be a single traversal, that can query "marko" once, determine his `age`
and then use that for the value supplied to
+filter the people he knows. In this way the _value_ for the `age` filter
is _induced_ from the `Traversal` itself.
+
+[gremlin-groovy,modern]
+
+g.V().has('name','marko').as('marko'). <1>
+ out('knows').as('friend'). <2>
+ filter(select('marko','friend').by('age'). <3>
+ where('friend', gt('marko'))).<4>
+ values('name')
+
+
+<1> Find the "marko" `Vertex` and label it as "marko".
+<2> Traverse out on the "knows" edges to the adjacent `Vertex` and label
it as "person".
+<3> Filter the incoming "person" vertices. It is within this filter, that
the traversal induced values are utilized.
+The inner `select` grabs the "marko" vertex and the current "friend". The
`by` modulator extracts the "age" from both
+of those vertices which yields a `Map` with two keys, "marko" and
"friend", where the value of each is the "age".
+<4> The `Map` produced in the previous step can then be filtered with
`where` to only return a result if the "friend"
+age is greater than the "marko" age. If this is successful, then the
`filter` step from the previous line will succeed
+and allow the "friend" vertex to pass through.
+
+This traversal could also be written declaratively with `match` step as
follows:
--- End diff --
Should there be any discussion of the possible performance differences
between the 2 approaches? Or is that mostly a system-specific discussion?
---
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.
---
[GitHub] tinkerpop issue #371: Added new recipe for Traversal Induced Values.
Github user okram commented on the issue: https://github.com/apache/tinkerpop/pull/371 VOTE +1. This got me to thinking that we really need to start to extend other steps (beyond the `Mutating`) to support traversal parameterization. --- 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: [DISCUSS] Download Page
Stephen, please correct me where I'm wrong, but after mirroring the site and removing docs and javadocs since these are generated, it would appear that there are only 7 html files to the website. It's not clear to me that at this point the effort of creating or moving to a template engine is worth the effort. I would rather see the static site as-is move to version control sooner rather than later and not hinge upon generation. On Wed, Aug 3, 2016 at 1:38 PM, Dylan Millikin wrote: > The groovy template engine could work just fine. > FYI : > http://stackoverflow.com/questions/3793880/lightweight-template-engine-in-java > There might be a few interested template engines there as well. > > On Wed, Aug 3, 2016 at 9:40 AM, Stephen Mallette > wrote: > >> Yeah - i'm not so good with the sed to the awk to the grep or whatever so >> if it can be that simple that would be awesome. The groovy template engine >> might be another option. Something like that would work easy enough too I >> would guess. I really don't think we need much more than that right now. >> >> Organizationally, I think we should have a /site directory at the root of >> the repo to house the images/html template content and then have it >> generate into root /target/site from bin/generate-site.sh. >> >> On Wed, Aug 3, 2016 at 9:29 AM, Dylan Millikin >> wrote: >> >> > Hmm sounds like what we would want would be a template engine that would >> > help us build the static site. >> > If all we need are includes that put together html partials >> > (headers/footers) we could make our own. It could be as simple as using >> sed >> > in bin/generate-web-site.sh >> > >> > On Wed, Aug 3, 2016 at 9:03 AM, Stephen Mallette >> > wrote: >> > >> > > yes - static html/css and it sucks a bit because we don't have any >> re-use >> > > going on there. so if we have to change a menu or something it means >> > > changing it on every page in the site. would be nice to have some >> > re-usable >> > > headers/footers and such. i looked into some static site generators a >> > while >> > > back, but they all seemed like they did too much. maybe i didn't know >> > what >> > > to look for. >> > > >> > > On Wed, Aug 3, 2016 at 9:00 AM, Dylan Millikin < >> dylan.milli...@gmail.com >> > > >> > > wrote: >> > > >> > > > How is the current site structured? Is it just HTML and CSS files? >> > > > >> > > > On Tue, Aug 2, 2016 at 6:20 PM, Stephen Mallette < >> spmalle...@gmail.com >> > > >> > > > wrote: >> > > > >> > > > > no - we don't have one for the main web site. i've wanted to >> suggest >> > > that >> > > > > we change that though and generate the main web site from the >> github >> > > > repo. >> > > > > in that way we could easily accept pull requests and such. i don't >> > > think >> > > > we >> > > > > want to take a full asciidoc approach and the web site generation >> > would >> > > > > probably stay separate from the doc generation, but it would be >> nice >> > if >> > > > we >> > > > > could bin/generate-web-site.sh for a local build of that that thing >> > > which >> > > > > could then be published to the apache svn repo. anyone else like >> that >> > > > idea? >> > > > > if so, how would it best be done? >> > > > > >> > > > > >> > > > > >> > > > > On Tue, Aug 2, 2016 at 5:05 PM, Robert Dale >> > wrote: >> > > > > >> > > > > > Is there a git repo for this and the main website? I would like >> to >> > > > > > make pull requests to fix some things. >> > > > > > >> > > > > > On Fri, Jul 29, 2016 at 1:49 PM, Stephen Mallette < >> > > > spmalle...@gmail.com> >> > > > > > wrote: >> > > > > > > The download page is now "live" >> > > > > > > >> > > > > > > On Thu, Jul 28, 2016 at 7:14 PM, Stephen Mallette < >> > > > > spmalle...@gmail.com> >> > > > > > > wrote: >> > > > > > > >> > > > > > >> I assume everyone is cool with making the Download Page live >> at >> > > this >> > > > > > point >> > > > > > >> as there's been no other feedback in the last few days. I'll >> > > > probably >> > > > > > make >> > > > > > >> some adjustments to the web site tomorrow to bring it online >> > > > publicly. >> > > > > > >> >> > > > > > >> On Mon, Jul 25, 2016 at 7:33 AM, Stephen Mallette < >> > > > > spmalle...@gmail.com >> > > > > > > >> > > > > > >> wrote: >> > > > > > >> >> > > > > > >>> I updated the downloads page some more: >> > > > > > >>> >> > > > > > >>> + tweaked the date format a bit to "really" match the rest of >> > the >> > > > > site >> > > > > > >>> (which is still inconsistent in other places like changelog - >> > > dah) >> > > > > > >>> + added a "verifying downloads" section which talks about >> > > > > GPG/PGP/etc. >> > > > > > >>> >> > > > > > >>> http://tinkerpop.apache.org/downloads.html >> > > > > > >>> >> > > > > > >>> >> > > > > > >>> >> > > > > > >>> >> > > > > > >>> On Fri, Jul 22, 2016 at 3:53 PM, Stephen Mallette < >> > > > > > spmalle...@gmail.com> >> > > > > > >>> wrote: >> > > > > > >>> >> > > > > > Good feedback Robert/Jason. >> > > > > > >>
[GitHub] tinkerpop issue #371: Added new recipe for Traversal Induced Values.
Github user twilmes commented on the issue: https://github.com/apache/tinkerpop/pull/371 Looks good, nice choice for a recipe. VOTE: +1 --- 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. ---
[GitHub] tinkerpop issue #372: DSP-1397 Fix StarGraph addEdge for self-edges
Github user spmallette commented on the issue: https://github.com/apache/tinkerpop/pull/372 @dalaro i assume that this is not a new problem and also has trouble in 3.1.x line of code - if so, could you please retarget your PR at tp31 branch? --- 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. ---
[jira] [Updated] (TINKERPOP-1397) StarVertex self edge has buggy interaction with graph filters
[
https://issues.apache.org/jira/browse/TINKERPOP-1397?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
stephen mallette updated TINKERPOP-1397:
Affects Version/s: 3.1.3
Fix Version/s: 3.1.4
Component/s: process
> StarVertex self edge has buggy interaction with graph filters
> -
>
> Key: TINKERPOP-1397
> URL: https://issues.apache.org/jira/browse/TINKERPOP-1397
> Project: TinkerPop
> Issue Type: Bug
> Components: process
>Affects Versions: 3.1.3
>Reporter: Dan LaRocque
> Fix For: 3.1.4
>
>
> When StarVertex adds a self-loop, it adds an instance of concrete type
> {{StarOutEdge}} to both its {{outEdges}} map and its {{inEdges}} map.
> https://github.com/apache/tinkerpop/blob/8f7218d53a31cf41f4a0269d64ac1c27dfc0907a/gremlin-core/src/main/java/org/apache/tinkerpop/gremlin/structure/util/star/StarGraph.java#L321-L330
> (line 329 adds a {{StarOutEdge}} to the {{inEdges}} map)
> Having a {{StarOutEdge}} in the {{inEdges}} map mostly doesn't matter.
> However, this does matter in the {{applyGraphFilter}} method. This method
> uses {{instanceof StarOutEdge}} to guess whether an edge's original direction
> was in or out:
> https://github.com/apache/tinkerpop/blob/8f7218d53a31cf41f4a0269d64ac1c27dfc0907a/gremlin-core/src/main/java/org/apache/tinkerpop/gremlin/structure/util/star/StarGraph.java#L470
> If you trace {{applyGraphFilter}} through, you see that a {{StarVertex}} with
> a self-loop can pop out of {{applyGraphFilter}} with two out edges
> corresponding to the self loop and no in edges. This leads to weird
> traversal results. One way to trigger this is to write a
> {{GraphFilterAware}} {{InputRDD}} that produces {{StarVertex}} instances and
> then run a {{g.V()inE("somelabel")}}, so that TP pushes down the
> "somelabel" constraint, which is how I got here.
> I think {{addEdge}} should continue putting a {{StarOutEdge}} into
> {{outEdges}}, like it already does. -However, it should put a {{StarInEdge}}
> into {{inEdges}}. This would increase the object overhead associated with
> StarVertices that have self loops (two edge objs instead of one). If we
> wanted to be obsessive about optimizing this case we could probably pervert
> the {{inEdge}}/{{outEdge}} datastructure contents to do it, but IMHO that's
> not worth it.- Actually, I'm no longer convinced that's safe, since I think
> it would alter some of StarVertex's other semantics. For one, I think
> retrieving an edge and setting a property on it would probably break.
> I'll make a PR soon.
> I don't know all of the versions this affects, but I do know it affects 3.2.1.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (TINKERPOP-1389) Support Spark 2.0.0
[ https://issues.apache.org/jira/browse/TINKERPOP-1389?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] stephen mallette updated TINKERPOP-1389: Component/s: hadoop > Support Spark 2.0.0 > --- > > Key: TINKERPOP-1389 > URL: https://issues.apache.org/jira/browse/TINKERPOP-1389 > Project: TinkerPop > Issue Type: Improvement > Components: hadoop >Affects Versions: 3.2.1 >Reporter: Chen Xin Yu > > Spark 2.0.0 was released: > http://spark.apache.org/news/spark-2-0-0-released.html > There are lots of improvement and changes compared to 1.6.1, we should better > bump to it for TinkerPop. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[GitHub] tinkerpop issue #371: Added new recipe for Traversal Induced Values.
Github user spmallette commented on the issue: https://github.com/apache/tinkerpop/pull/371 Sorry - forgot to add the file @twilmes - fixed up the commit and force pushed. --- 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. ---
