[jira] [Commented] (TINKERPOP-1661) Docker-built documentation does not always point locally

2017-09-29 Thread ASF GitHub Bot (JIRA) 

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

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

Github user robertdale commented on the issue:

https://github.com/apache/tinkerpop/pull/725
  
Do we need dotnet stuff now to build docs?  I am confused by 
http://tinkerpop.apache.org/docs/3.2.6/dev/developer/#dotnet-environment
How do I set this up in docker?  Do I need to rebuild my docker images for 
this?

`docker/build.sh -d`:
```
[ERROR] Failed to execute goal 
org.eobjects.build:dotnet-maven-plugin:0.14:restore (default-restore) on 
project gremlin-dotnet-source:
Command (in /usr/src/tinkermem/gremlin-dotnet/src/Gremlin.Net) [dotnet, 
restore] failed:
Cannot run program "dotnet" (in directory 
"/usr/src/tinkermem/gremlin-dotnet/src/Gremlin.Net"):
error=2, No such file or directory -> [Help 1]
```



> Docker-built documentation does not always point locally
> 
>
> Key: TINKERPOP-1661
> URL: https://issues.apache.org/jira/browse/TINKERPOP-1661
> Project: TinkerPop
>  Issue Type: Improvement
>  Components: build-release
>Affects Versions: 3.2.4
>Reporter: Robert Dale
>Assignee: Daniel Kuppitz
>Priority: Minor
>
> After performing {{docker/build.sh -d}}
> When I pull up the initial URL to look at the docs, it's local -
> http://172.17.0.2/ .
> Anchor links to the same page are also local - http://172.17.0.2/#tutorials .
> However, all links to other pages are remote! Also, you can't just replace 
> the server name with the local IP, the URL is slightly different. e.g.
> http://tinkerpop.apache.org/docs/3.3.0-SNAPSHOT/reference
> must be changed to http://172.17.0.2/reference/ in order to view it locally.
> If the reviewer isn't paying attention to the url, s/he might be reviewing 
> the wrong content. It would be better if it were all local and/or relative 
> paths.



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

[jira] [Commented] (TINKERPOP-1661) Docker-built documentation does not always point locally

2017-09-29 Thread ASF GitHub Bot (JIRA) 

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

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

GitHub user dkuppitz opened a pull request:

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

TINKERPOP-1661 Docker-built documentation does not always point locally

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

That was much easier than I thought. I started by pushing directories 
around and updating links in most of the asciidoc files. Then I realized, that 
this can be a simple 2 line change in Docker's build script (it's basically 
just a global `sed` replacement and a symlink).

VOTE: +1

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

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

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

https://github.com/apache/tinkerpop/pull/725.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 #725


commit 82fb125891276ed610e1e7f195758120de20ae84
Author: Daniel Kuppitz 
Date:   2017-09-29T17:14:46Z

Update links to all docs pages in Docker build and emulate the published 
directory structure. This way the docs are easier to navigate in local builds.




> Docker-built documentation does not always point locally
> 
>
> Key: TINKERPOP-1661
> URL: https://issues.apache.org/jira/browse/TINKERPOP-1661
> Project: TinkerPop
>  Issue Type: Improvement
>  Components: build-release
>Affects Versions: 3.2.4
>Reporter: Robert Dale
>Assignee: Daniel Kuppitz
>Priority: Minor
>
> After performing {{docker/build.sh -d}}
> When I pull up the initial URL to look at the docs, it's local -
> http://172.17.0.2/ .
> Anchor links to the same page are also local - http://172.17.0.2/#tutorials .
> However, all links to other pages are remote! Also, you can't just replace 
> the server name with the local IP, the URL is slightly different. e.g.
> http://tinkerpop.apache.org/docs/3.3.0-SNAPSHOT/reference
> must be changed to http://172.17.0.2/reference/ in order to view it locally.
> If the reviewer isn't paying attention to the url, s/he might be reviewing 
> the wrong content. It would be better if it were all local and/or relative 
> paths.



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

[GitHub] tinkerpop pull request #725: TINKERPOP-1661 Docker-built documentation does ...

2017-09-29 Thread dkuppitz 
GitHub user dkuppitz opened a pull request:

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

TINKERPOP-1661 Docker-built documentation does not always point locally

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

That was much easier than I thought. I started by pushing directories 
around and updating links in most of the asciidoc files. Then I realized, that 
this can be a simple 2 line change in Docker's build script (it's basically 
just a global `sed` replacement and a symlink).

VOTE: +1

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

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

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

https://github.com/apache/tinkerpop/pull/725.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 #725


commit 82fb125891276ed610e1e7f195758120de20ae84
Author: Daniel Kuppitz 
Date:   2017-09-29T17:14:46Z

Update links to all docs pages in Docker build and emulate the published 
directory structure. This way the docs are easier to navigate in local builds.




---

Re: [DISCUSS] GLV Test Suite

2017-09-29 Thread Stephen Mallette 
I did some pretty heavy refactoring to the python test logic (altered a bit
by some revision of the gherkin feature file language) and the result is a
much more simplified test logic file:

https://github.com/apache/tinkerpop/blob/TINKERPOP-1784/gremlin-python/src/main/jython/radish/feature_steps.py

About 120 lines of code (down from about 170). If you include the test
logic "setup" file:

https://github.com/apache/tinkerpop/blob/TINKERPOP-1784/gremlin-python/src/main/jython/radish/terrain.py

we end up with about 250 lines of test logic total (take out the
comment/license and we're probably well under 200 total - not too bad). I
think I'm closing in on the end to infrastructure building here so the
basic framework is getting close to final at this point I believe. I'll
keep scanning the tests looking for other types of assertions that I've not
yet covered, but it's getting pretty solid I think. Hopefully, there won't
need to be too many more lines of code needed to express the test logic as
I like how things are looking right now.




On Thu, Sep 28, 2017 at 8:02 AM, Jorge Bay Gondra 
wrote:

> Great progress! I like how you avoided using ids, even if it adds some
> complexity to the transformation required.
>
> The Python step definitions are still quite simple, I think it would be
> mostly the same on the rest of the languages.
>
> On Thu, Sep 28, 2017 at 1:45 PM, Stephen Mallette 
> wrote:
>
> > Just another update on progress with the test suite. The language of the
> > .feature files is getting slightly more complex as I try to translate
> more
> > and more of our Java process suite tests into the language of the gherkin
> > files. You can see here where I've added the ability to include
> parameters:
> >
> > https://github.com/apache/tinkerpop/blob/TINKERPOP-1784/
> > gremlin-test/features/filter/Has.feature#L33
> >
> > I also came up with a method of asserting edges (didn't want to rely on
> ids
> > as it makes the gherkin harder to read, plus i didn't want to assume
> > TinkerGraph identifiers in case these tests were every used with some
> other
> > graph database that didn't use longs):
> >
> > https://github.com/apache/tinkerpop/blob/TINKERPOP-1784/
> > gremlin-test/features/map/Vertex.feature#L105-L111
> >
> > for all those additions (and others) the logic required by the GLV to
> > process these tests has stayed surprisingly simple:
> >
> > https://github.com/apache/tinkerpop/blob/TINKERPOP-1784/
> > gremlin-python/src/main/jython/radish/feature_steps.py
> >
> > There's a fair bit of regex/string manipulation involved there, but it's
> > processing strings from the feature file so that's the nature of it I
> > suppose. I think I'm of the mind that I want to port all of the tests to
> > feature files, so I wrote this unit test to help validate that none were
> > missed:
> >
> > https://github.com/apache/tinkerpop/blob/TINKERPOP-1784/
> > gremlin-test/src/test/java/org/apache/tinkerpop/gremlin/
> > structure/FeatureCoverageTest.java
> >
> > I don't know that we have to get to 100% porting right away, but I think
> > that once we have these gherkin files written they not only become the
> > basis for our current GLV testing work, but we might be able to simply
> use
> > them for testing the Java stuff as well - that would rid us of having the
> > test code duplication. It also sets us up with a portable body of tests
> > that can be re-used in TinkerPop 4.x.
> >
> > I'm open to suggestions if anyone has any.
> >
> > On Mon, Sep 25, 2017 at 11:23 AM, Jorge Bay Gondra <
> > jorgebaygon...@gmail.com
> > > wrote:
> >
> > > I was able to build a proof of concept for a Gherkin-based test runner
> in
> > > C#, that takes the proposed count and select features
> > >  > > gremlin-test/features/map>
> > > and runs them using C# step definitions.
> > >
> > > It uses the Gherkin parser  >
> > > from
> > > cucumber, there isn't a release of the parser with .NET Core support so
> > > I've
> > > asked them to release one
> > >  (there is no
> > > limitation from their source files). If they are not able to release it
> > in
> > > the next few days, we can implement our own as it should be pretty
> > straight
> > > forward.
> > >
> > > On Fri, Sep 22, 2017 at 2:23 PM, Stephen Mallette <
> spmalle...@gmail.com>
> > > wrote:
> > >
> > > > Thanks for the update. I'm trying to keep the test language as simple
> > as
> > > > possible so that we don't need an overly complicated test
> > implementation.
> > > > Hopefully that will help make the .NET approach as easy as possible.
> > > >
> > > > On Fri, Sep 22, 2017 at 8:20 AM, Jorge Bay Gondra <
> > > > jorgebaygon...@gmail.com>
> > > > wrote:
> > > >
> > > > > I've been looking into Gherkin support for .NET: SpecFlow, the
> > cucumber
> > > > > implementation for

[jira] [Closed] (TINKERPOP-1792) Random TraversalSource Selection in GremlinScriptEngine

2017-09-29 Thread stephen mallette (JIRA) 

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

stephen mallette closed TINKERPOP-1792.
---
   Resolution: Fixed
 Assignee: stephen mallette
Fix Version/s: 3.3.1
   3.2.7

> Random TraversalSource Selection in GremlinScriptEngine
> ---
>
> Key: TINKERPOP-1792
> URL: https://issues.apache.org/jira/browse/TINKERPOP-1792
> Project: TinkerPop
>  Issue Type: Bug
>  Components: groovy, python
>Affects Versions: 3.2.6
>Reporter: stephen mallette
>Assignee: stephen mallette
>Priority: Critical
>  Labels: deprecation
> Fix For: 3.2.7, 3.3.1
>
>
> {{GremlinScriptEngine}} implementations make a random {{TraversalSource}} 
> selection when processing lambdas. Obviously it should be bound more clearly 
> to the specific {{TraversalSource}} the caller requests. Another issue that 
> isn't completely clear is that bindings passed from the client share the same 
> namespace as {{TraversalSource}} bindings which means that if the 
> {{TraversalSource}} is "g" then you couldn't write a traversal like: 
> {{withSideEffect(“g”, “hello”)}}. That could be smarter as well.



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

[jira] [Commented] (TINKERPOP-1792) Random TraversalSource Selection in GremlinScriptEngine

2017-09-29 Thread ASF GitHub Bot (JIRA) 

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

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

Github user asfgit closed the pull request at:

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


> Random TraversalSource Selection in GremlinScriptEngine
> ---
>
> Key: TINKERPOP-1792
> URL: https://issues.apache.org/jira/browse/TINKERPOP-1792
> Project: TinkerPop
>  Issue Type: Bug
>  Components: groovy, python
>Affects Versions: 3.2.6
>Reporter: stephen mallette
>Priority: Critical
>  Labels: deprecation
>
> {{GremlinScriptEngine}} implementations make a random {{TraversalSource}} 
> selection when processing lambdas. Obviously it should be bound more clearly 
> to the specific {{TraversalSource}} the caller requests. Another issue that 
> isn't completely clear is that bindings passed from the client share the same 
> namespace as {{TraversalSource}} bindings which means that if the 
> {{TraversalSource}} is "g" then you couldn't write a traversal like: 
> {{withSideEffect(“g”, “hello”)}}. That could be smarter as well.



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

[GitHub] tinkerpop pull request #723: TINKERPOP-1792 Fixed GremlinScriptEngine bug in...

2017-09-29 Thread asfgit 
Github user asfgit closed the pull request at:

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


---