[jira] [Commented] (TINKERPOP-1409) Make the "null" return in the gremlin console into something more understandable

[stephen mallette (JIRA)]

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

stephen mallette commented on TINKERPOP-1409:
-

Could there have been a setting to allow for "no line" of some sort that didn't 
print a "==>"? like:

{code}
gremlin> inputstream.close()
gremlin>
{code}

> Make the "null" return in the gremlin console into something more 
> understandable
> 
>
> Key: TINKERPOP-1409
> URL: https://issues.apache.org/jira/browse/TINKERPOP-1409
> Project: TinkerPop
>  Issue Type: Improvement
>  Components: console
>Affects Versions: 3.2.1
>Reporter: Jeremy Hanna
>
> A common question among new users is what is with the "null" return String in 
> the console when there is a successful execution.  An explanation is in the 
> docs now (see note at bottom of 
> http://tinkerpop.apache.org/docs/current/reference/#_mutating_the_graph 
> section) but it would be nice to avoid it or make it more immediately 
> understandable for new users.
> It's not a huge deal, but often comes up as a question from new users.



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

[GitHub] tinkerpop pull request #391: Fixed empty result

[robertdale]

GitHub user robertdale opened a pull request:

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

Fixed empty result

Forgot to test this one. Fixed now.

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

$ git pull https://github.com/robertdale/tinkerpop emptyResult-bugfix

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

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


commit 629ad68865c16b3924e26dcfa940d38ccc6f04cb
Author: Robert Dale 
Date:   2016-08-27T11:43:10Z

fixed empty result




---
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-1409) Make the "null" return in the gremlin console into something more understandable

[Robert Dale (JIRA)]

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

Robert Dale commented on TINKERPOP-1409:


This was included in https://github.com/apache/tinkerpop/pull/384

{noformat}
g> :set empty.result.indicator Nil
g> null
==>Nil
g> :set empty.result.indicator ""
g> null
==>
g> 
{noformat}


> Make the "null" return in the gremlin console into something more 
> understandable
> 
>
> Key: TINKERPOP-1409
> URL: https://issues.apache.org/jira/browse/TINKERPOP-1409
> Project: TinkerPop
>  Issue Type: Improvement
>  Components: console
>Affects Versions: 3.2.1
>Reporter: Jeremy Hanna
>
> A common question among new users is what is with the "null" return String in 
> the console when there is a successful execution.  An explanation is in the 
> docs now (see note at bottom of 
> http://tinkerpop.apache.org/docs/current/reference/#_mutating_the_graph 
> section) but it would be nice to avoid it or make it more immediately 
> understandable for new users.
> It's not a huge deal, but often comes up as a question from new users.



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

[jira] [Closed] (TINKERPOP-1230) Serialising lambdas for RemoteGraph

[stephen mallette (JIRA)]

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

stephen mallette closed TINKERPOP-1230.
---
   Resolution: Done
 Assignee: Marko A. Rodriguez
Fix Version/s: 3.2.2

> Serialising lambdas for RemoteGraph
> ---
>
> Key: TINKERPOP-1230
> URL: https://issues.apache.org/jira/browse/TINKERPOP-1230
> Project: TinkerPop
>  Issue Type: Improvement
>  Components: driver, server
>Affects Versions: 3.1.1-incubating
>Reporter: Michael Pollmeier
>Assignee: Marko A. Rodriguez
>Priority: Minor
> Fix For: 3.2.2
>
>
> I just made an attempt to serialise lambdas and send them via the 
> RemoteGraph. I didn't quite get there, but wanted to share my findings: 
> * it's possible to serialise lambdas on the jvm by just extending 
> `Serializable`:
> http://stackoverflow.com/questions/22807912/how-to-serialize-a-lambda/22808112#22808112
> * sending a normal predicate doesn't work (this is a Scala REPL but it should 
> be pretty easy to convert this to java/groovy)
>   val g = RemoteGraph.open("conf/remote-graph.properties").traversal()
>   val pred1 = new java.util.function.Predicate[Traverser[Vertex]] { def 
> test(v: Traverser[Vertex]) = true }
>   g.V().filter(pred1).toList 
> // java.lang.RuntimeException: java.io.NotSerializableException: $anon$1
>  // on server: nothing
>  
> * simply adding Serializable let's us send it over the wire, but the server 
> doesn't deserialise it
>   val pred2 = new java.util.function.Predicate[Traverser[Vertex]] with 
> Serializable { def test(v: Traverser[Vertex]) = true }
>   g.V().filter(pred2).toList 
>   // on server: [WARN] OpExecutorHandler - Could not deserialize the 
> Traversal instance
> org.apache.tinkerpop.gremlin.server.op.OpProcessorException: Could 
> not deserialize the Traversal instance
> at 
> org.apache.tinkerpop.gremlin.server.op.traversal.TraversalOpProcessor.iterateOp(TraversalOpProcessor.java:135)
> at 
> org.apache.tinkerpop.gremlin.server.handler.OpExecutorHandler.channelRead0(OpExecutorHandler.java:68)
>   // on client: 
> org.apache.tinkerpop.gremlin.driver.exception.ResponseException: $anon$1 



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

[jira] [Closed] (TINKERPOP-1347) RemoteConnection needs to provide TraversalSideEffects.

[stephen mallette (JIRA)]

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

stephen mallette closed TINKERPOP-1347.
---
   Resolution: Done
 Assignee: stephen mallette
Fix Version/s: 3.2.2

> RemoteConnection needs to provide TraversalSideEffects.
> ---
>
> Key: TINKERPOP-1347
> URL: https://issues.apache.org/jira/browse/TINKERPOP-1347
> Project: TinkerPop
>  Issue Type: Improvement
>  Components: driver, process, server
>Affects Versions: 3.2.0-incubating
>Reporter: Marko A. Rodriguez
>Assignee: stephen mallette
>  Labels: breaking
> Fix For: 3.2.2
>
>
> Right now the {{RemoteConnection}} API is this:
> {code}
> public  Iterator submit(final Traversal 
> traversal) throws RemoteConnectionException;
> {code}
> This is bad because a result set is not just an iterator of traversers, it is 
> also the sideEffects. I just hit a big snag in {{gremlin-variants}} when not 
> using TinkerGraph and thus, not everything in the same JVM.
> I think we should do one of two things:
> {code}
> public  Traversal submit(final Traversal traversal) throws 
> RemoteConnectionException;
> {code}
> In essence, a traversal goes out an then a traversal comes back and that 
> traversal has an end step iterator of traversers as well as traversal 
> side-effects. Moreover, that returned {{Traversal}} could be like 
> {{RemoteTraversal}}  and when {{getSideEffects()}} is called, the sideEffects 
> are lazily fetched 
> We will have the same problem when we extend {{RemoteConnection}} with:
> {code}
> public  Iterator submit(final String alias, final 
> String scriptEngine, final String traversalScript, Object... bindings) throws 
> RemoteConnectionException;
> {code}
> I sort of like the concept of {{RemoteTraversal}} as it allows us to not only 
> {{getSideEffects()}}, but also {{toString()}}, etc. A remote traversal can 
> offer more control than just {{Iterator}}.
> cc/ [~spmallette]



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

[jira] [Closed] (TINKERPOP-1392) Remove support for java serialized Traversal

[stephen mallette (JIRA)]

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

stephen mallette closed TINKERPOP-1392.
---
Resolution: Done

> Remove support for java serialized Traversal
> 
>
> Key: TINKERPOP-1392
> URL: https://issues.apache.org/jira/browse/TINKERPOP-1392
> Project: TinkerPop
>  Issue Type: Improvement
>  Components: server
>Affects Versions: 3.2.1
>Reporter: stephen mallette
>Assignee: stephen mallette
>  Labels: breaking
> Fix For: 3.2.2
>
>
> Given TINKERPOP-1278 and {{Bytecode}} serialization of a {{Traversal}} the 
> old method of serializing {{Traversal}} with java serialization isn't that 
> useful. There seems to be little point in deprecating that functionality 
> because the only library that supports that protocol is gremlin-driver which 
> will now use the new approach. Dropping it completely wouldn't break anyone's 
> code though we still should consider it a "breaking" change.



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

[jira] [Closed] (TINKERPOP-1226) Gremlin Console should :clear automagically after "Display stack trace."

[stephen mallette (JIRA)]

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

stephen mallette closed TINKERPOP-1226.
---
   Resolution: Done
 Assignee: stephen mallette
Fix Version/s: 3.2.2

Line numbers implemented.

> Gremlin Console should :clear automagically after "Display stack trace."
> 
>
> Key: TINKERPOP-1226
> URL: https://issues.apache.org/jira/browse/TINKERPOP-1226
> Project: TinkerPop
>  Issue Type: Improvement
>  Components: console
>Affects Versions: 3.1.1-incubating
>Reporter: Marko A. Rodriguez
>Assignee: stephen mallette
> Fix For: 3.2.2
>
>
> I don't know if this is possible, but Martin brought this up the other day. 
> Why not just automatically call {{:clear}} after an Exception has been 
> through to get the Console back into an orderly state.



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

[jira] [Closed] (TINKERPOP-1285) Gremline console does not differentiate between multi-line and single-line input

[stephen mallette (JIRA)]

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

stephen mallette closed TINKERPOP-1285.
---
   Resolution: Done
 Assignee: stephen mallette
Fix Version/s: 3.2.2

Line numbers now clearly show when the console goes multi-line.

> Gremline console does not differentiate between multi-line and single-line 
> input
> 
>
> Key: TINKERPOP-1285
> URL: https://issues.apache.org/jira/browse/TINKERPOP-1285
> Project: TinkerPop
>  Issue Type: Improvement
>  Components: console
>Affects Versions: 3.2.0-incubating
>Reporter: Rocco Varela
>Assignee: stephen mallette
>Priority: Minor
> Fix For: 3.2.2
>
>
> When entering input, say into a script variable, that extends over multiple 
> lines the gremlin console does not provide the user with any indication that 
> they are in a multi-line input mode. Here is an example.
> Notice the 'gremline>' prompts are presented within the triple-quotes.
> {code}
> gremlin> script = '''
> gremlin> line1_command
> gremlin> line2_command
> gremlin> '''
> {code}
> Ideally we would like something like this, showing the user that they are 
> still in multi-line input mode.
> {code}
> gremlin> script = '''
> ... line1_command
> ... line2_command
> ... '''
> gremlin>
> {code}



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

[GitHub] tinkerpop pull request #385: TINKERPOP-1285 added multi-line line number sup...

[asfgit]

Github user asfgit closed the pull request at:

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


---
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-1285) Gremline console does not differentiate between multi-line and single-line input

[ASF GitHub Bot (JIRA)]

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

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

Github user asfgit closed the pull request at:

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


> Gremline console does not differentiate between multi-line and single-line 
> input
> 
>
> Key: TINKERPOP-1285
> URL: https://issues.apache.org/jira/browse/TINKERPOP-1285
> Project: TinkerPop
>  Issue Type: Improvement
>  Components: console
>Affects Versions: 3.2.0-incubating
>Reporter: Rocco Varela
>Priority: Minor
>
> When entering input, say into a script variable, that extends over multiple 
> lines the gremlin console does not provide the user with any indication that 
> they are in a multi-line input mode. Here is an example.
> Notice the 'gremline>' prompts are presented within the triple-quotes.
> {code}
> gremlin> script = '''
> gremlin> line1_command
> gremlin> line2_command
> gremlin> '''
> {code}
> Ideally we would like something like this, showing the user that they are 
> still in multi-line input mode.
> {code}
> gremlin> script = '''
> ... line1_command
> ... line2_command
> ... '''
> gremlin>
> {code}



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

[jira] [Commented] (TINKERPOP-1246) 'help' in the gremlin console should give the user something

[Robert Dale (JIRA)]

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

Robert Dale commented on TINKERPOP-1246:


This was included in https://github.com/apache/tinkerpop/pull/384

{noformat}
g> help
No such property: help for class: groovysh_evaluate
Type ':help' or ':h' for help.
Display stack trace? [yN]
g> 
{noformat}

> 'help' in the gremlin console should give the user something
> 
>
> Key: TINKERPOP-1246
> URL: https://issues.apache.org/jira/browse/TINKERPOP-1246
> Project: TinkerPop
>  Issue Type: Improvement
>  Components: console
>Affects Versions: 3.1.1-incubating
>Reporter: Jeremy Hanna
>
> A new user to TinkerPop and/or Gremlin will probably flounder initially and 
> will likely try to type 'help' in the gremlin-console.  Currently it just 
> gives an error that help is not mapped to a class and gives the option to 
> show a stack trace.
> I know there is :help for the command mode, but that's going to confuse them 
> further I think because those are special commands and not what they're 
> looking for.
> Piggy backing on something [~rustyrazorblade] mentioned, perhaps we could 
> have it give a general message but help gremlin or help tinkerpop could open 
> the docs.
> In general though, I think it would be useful to have something defined for 
> help - perhaps a basic explanation with a couple of examples with the toy 
> graph while also referring to the tutorials section of the site.  Then it 
> would also be handy to override the help with specific commands like for each 
> of the commands in the docs like traversal steps (though that may be a lot of 
> work to maintain) such as 'help count' or 'help barrier'.  Specific keywords 
> could be used like was mentioned 'help gremlin' or 'help tinkerpop' or 'help 
> docs' could open the docs.
> Maybe some of this is overkill but I think overriding 'help' in some form 
> would be helpful for new users.  Also just trying to brainstorm what could be 
> done.



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

[GitHub] tinkerpop issue #385: TINKERPOP-1285 added multi-line line number support

[robertdale]

Github user robertdale commented on the issue:

https://github.com/apache/tinkerpop/pull/385
  
This was rebased on master.


---
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.
---

Code Freeze 3.1.4/3.2.2

[Stephen Mallette]

Code freeze begins today. Some minor changes to expect on master:

+ We have one lingering PR that needs to be merged once it is rebased:
https://github.com/apache/tinkerpop/pull/385
+ I suspect we will see more tests on gremlin-python as well as tweaks to
the build process
+ We may see one more serializers added to GraphSON 2.0 -
TraversalExplanation
+ More docs as usual

Recall, that gremlin-python and GraphSON 2.0 will be "experimental" so I
don't think we should be too concerned about late changes on that stuff at
this point. So - nothing major coming down the pike and as far as I know
there shouldn't be any change on tp31 branch aside from some added
documentation.

Providers should be free to test things out in their implementations. I've
published the 3.2.2-SNAPSHOT to Apache Snapshots repo. Note that Ted is
going to be handling the 3.1.4 release - he will publish the 3.1.4-SNAPSHOT
sometime soon (thanks for helping out with that Ted - it will be
interesting to have two voices taking us through code freeze week into
release)..

As usual, please stay tuned to this thread for updates as we head to
release. Thanks!

[GitHub] tinkerpop pull request #390: GraphSON 2.0 Deser tweaks and improvements

[asfgit]

Github user asfgit closed the pull request at:

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


---
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.
---

Building gremlin-python

[Stephen Mallette]

Now that gremlin-python has been merged to master, you might wonder about
what this has done to our build/release process. Well, not very much. If
you do your standard

mvn clean install

on master right now you should see that everything builds and is good to go
- even gremlin-python. So, everything is good, right? right? well, yes and
no.

The "yes" aspect here is that the entire project still builds with maven
which keeps our build toolchain simple. Users can just have java installed
as they always did and still get a clean build of TinkerPop. The "no"
aspect is that native python tests (and if you were deploy,
packaging/deployment tasks) did not execute.

What's good however is that even the native python build tasks are still
just part of the maven toolchain. You just need to have python 2.x
installed and, if you do, build with:

mvn clean install -DglvPython

You will now see in your output the results of native pytest execution. I
think this approach almost sets the basic pattern for future GLVs. I'd
prefer to not have -glvPython to some degree and simply detect python on
the system and then execute natively if it can, but then i think about what
happens as we add more GLVs and then i sorta like the idea of having the
specific option to turn things on and off.