[jira] [Commented] (TINKERPOP-1474) API Alignment Between Java Gremlin Graph Structure and GLVs

[Dylan Millikin (JIRA)]

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

Dylan Millikin commented on TINKERPOP-1474:
---

I'm less torn about this now that GLVs are around the corner. It makes 
everything a little simpler for everyone and the extra consistency would be 
welcome. 

I'm just going to point out that I believe {{valueMap(true)}} on edges does not 
currently return {{inV/outV}}. If we go the {{Reference*}} route it would be 
nice to have those added in.

> API Alignment Between Java Gremlin Graph Structure and GLVs
> ---
>
> Key: TINKERPOP-1474
> URL: https://issues.apache.org/jira/browse/TINKERPOP-1474
> Project: TinkerPop
>  Issue Type: Bug
>  Components: io
>Affects Versions: 3.2.2
>Reporter: Adam Holmberg
>
> The current Java GraphSON implementation and that in the Python GLV leave 
> some question about what *should* be returned from a simple traversal like 
> `g.V()`.
> The java implementation presently assumes that properties could be present 
> and returns a DetachedVertex: 
> https://github.com/apache/tinkerpop/blob/master/gremlin-core/src/main/java/org/apache/tinkerpop/gremlin/structure/io/graphson/GraphSONSerializersV2d0.java#L420-L433
> The python implementation assumes no such thing and returns something more 
> reminiscent of a ReferenceVertex: 
> https://github.com/apache/tinkerpop/blob/master/gremlin-python/src/main/jython/gremlin_python/structure/io/graphson.py#L238-L242
> Is the java version overreaching, and should not expect properties unless a 
> step calls for them (e.g. ` g.V().valueMap()` or `g.V().values('name')`, or 
> should the Python version be expanded?
> Is there something we can do to establish guidelines for this, and align 
> these APIs?



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

Re: A self-writing traversal.

[Marko Rodriguez]

So whats up Kuppitz? You just going to let me throw down a wicked nasty and not 
come back with something even better?!

Marko.

http://markorodriguez.com



> On Sep 28, 2016, at 11:02 AM, Marko Rodriguez  wrote:
> 
> Hello,
> 
> Assume the following graph.
> 
> g = TinkerGraph.open().traversal()
> g.addV().property(id,1).property('op','g.').as('g.').
>   addV().property('op','V(1).').as('V(1).').
>   addV().property('op','repeat(').as('repeat(').
>   addV().property('op','out()).').as('out()).').
>   addV().property('op','times(4).').
>  property('name',"x",'op',"properties('name')").as('times(4).').
>   addE('link').from('g.').to('V(1).').
>   addE('link').from('V(1).').to('repeat(').
>   addE('link').from('repeat(').to('out()).').
>   addE('link').from('out()).').to('times(4).')
> 
> 
> 
> Next, assume the following traversal:
> 
> g.V(1).repeat(out()).times(4).properties('name')
> 
> Look at the path that is traversed when the above traversal is executed 
> against the above graph.
> 
> gremlin> g.V(1).repeat(out()).times(4).properties('name').path().by('op')
> ==>[g.,V(1).,repeat(,out()).,times(4).,properties('name')]
> 
> This is a traversal that writes itself out.
> 
> Marko.
> 
> http://markorodriguez.com 
> 
> 
> 

[GitHub] tinkerpop issue #441: TINKERPOP-1467 Corrected a number of problems in close...

[dkuppitz]

Github user dkuppitz commented on the issue:

https://github.com/apache/tinkerpop/pull/441
  
FYI:  3x BUILD SUCCESS in a row.

My vote still holds true.


---
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-1340) docs do not state at what version an API was introduced (or deprecated)

[stephen mallette (JIRA)]

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

stephen mallette updated TINKERPOP-1340:

Labels:   (was: easyfix newbie)

> docs do not state at what version an API was introduced (or deprecated)
> ---
>
> Key: TINKERPOP-1340
> URL: https://issues.apache.org/jira/browse/TINKERPOP-1340
> Project: TinkerPop
>  Issue Type: Improvement
>  Components: documentation
>Affects Versions: 3.2.0-incubating, 3.1.2-incubating
>Reporter: Jason Plurad
>Priority: Trivial
> Fix For: 3.2.3
>
>
> An all-to-common problem for new developers coming to the TinkerPop is 
> figuring out which APIs work against the graph they are using. Since 
> TinkerPop is ahead of many graph implementation out there (Titan/TP 3.0.1, 
> Stardog/TP 3.0.2, Blazegraph/TP 3.1.0 -- kudos to Sqlg and Unipop for TP 
> 3.2.0!), it's really important that developers know which APIs in the current 
> docs are valid. Ideally the developers would go directly to that version of 
> the TP docs, but that doesn't always happen thanks to Google.
> I propose doc updates on each Graph Traversal Step in the [reference 
> docs|http://tinkerpop.apache.org/docs/current/reference/#graph-traversal-steps]
>  and in the javadocs (on 
> [__.java|http://tinkerpop.apache.org/javadocs/current/full/org/apache/tinkerpop/gremlin/process/traversal/dsl/graph/__.html]
>  and on specific step implementations, i.e. 
> [AddEdgeStep.java|http://tinkerpop.apache.org/javadocs/current/full/org/apache/tinkerpop/gremlin/process/traversal/step/map/AddEdgeStep.html]).
> It should state the specific version (3.y.z) the API was introduced or 
> deprecated.



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

[jira] [Closed] (TINKERPOP-1189) SimpleAuthenticator over HttpChannelizer makes Gremlin Server pretty slow and consumes more CPU

[stephen mallette (JIRA)]

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

stephen mallette closed TINKERPOP-1189.
---
Resolution: Cannot Reproduce
  Assignee: stephen mallette

If there's new information for this issue, please feel free to pass it along.

> SimpleAuthenticator over HttpChannelizer makes Gremlin Server pretty slow and 
> consumes more CPU
> ---
>
> Key: TINKERPOP-1189
> URL: https://issues.apache.org/jira/browse/TINKERPOP-1189
> Project: TinkerPop
>  Issue Type: Improvement
>  Components: server
>Affects Versions: 3.0.2-incubating
> Environment: Gremlin Server 3.0.2 backended by Titan 1.0.0 and 
> Cassandra (separate instance), running in a server with 2 CPUs / 7.5 GB RAM 
> (Linux Debian 3.16.7)
>Reporter: Gabriel Moreira
>Assignee: stephen mallette
>Priority: Minor
>
> I have setup Authorization in my Gremlin Server instances (v3.0.2), backended 
> by Titan v1.0.0 and Cassandra.
> I am testing SimpleAuthenticator, with the following snippet from my 
> gremlin-server.yaml:
> authentication: {
>   className: org.apache.tinkerpop.gremlin.server.auth.SimpleAuthenticator,
>   config: {
> credentialsDb: conf/tinkergraph-empty.properties,
> credentialsDbLocation: data/credentials.kryo}}
> ssl: {
>   enabled: false}
> I am using the default serialization file of TinkerGraph credentials.kryo, 
> with only the default user stephen/password.
>  I am using Basic Auth in my requests to Gremlin Server, by passing the 
> header "Authorization" with the value "Basic c3RlcGhlbjpwYXNzd29yZA==".
> Authorization works as expected. Therefore, the Gremlin Server becomes pretty 
> slow! It takes 10x more time and consumes 5x more CPU (from 10% to 50%) to 
> handle the same simple traversal Http POST request (below) in batch, compared 
> to Gremlin Server with NO authorization!
> {
> "gremlin": "g.V().has('CONTENT','id', 'LinkPost:7330001').count()"
> }
> Is there a workaround to this?
> Ps. If there is a fix, could it be patched for version 3.0.2? I am limited to 
> this version because I use Titan 1.0.0.
> Thanks.
> Gabriel Moreira



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

[jira] [Commented] (TINKERPOP-1467) Improve close() operations on the Java driver

[ASF GitHub Bot (JIRA)]

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

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

Github user spmallette commented on the issue:

https://github.com/apache/tinkerpop/pull/441
  
I ran the docker build multiple times today following the report of stuck 
integration tests. I never ran into the problem, but the adjustments I forced 
pushed prior to those tests hopefully fixed it.  


> Improve close() operations on the Java driver 
> --
>
> Key: TINKERPOP-1467
> URL: https://issues.apache.org/jira/browse/TINKERPOP-1467
> Project: TinkerPop
>  Issue Type: Bug
>  Components: driver
>Affects Versions: 3.1.3
>Reporter: stephen mallette
>Assignee: stephen mallette
> Fix For: 3.1.5, 3.2.3
>
>
> A few big problems:
> 1. Client will hang if submitting a request after {{close()}}
> 2. Multiple calls to {{close()}} hangs periodically
> 3. Closing the {{Cluster}} doesn't attempt to clean up open {{Client}} 
> instances.



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

[GitHub] tinkerpop issue #441: TINKERPOP-1467 Corrected a number of problems in close...

[spmallette]

Github user spmallette commented on the issue:

https://github.com/apache/tinkerpop/pull/441
  
I ran the docker build multiple times today following the report of stuck 
integration tests. I never ran into the problem, but the adjustments I forced 
pushed prior to those tests hopefully fixed it.  


---
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-1485) Move source for TinkerPop site to source code repo

[stephen mallette (JIRA)]

stephen mallette created TINKERPOP-1485:
---

 Summary: Move source for TinkerPop site to source code repo
 Key: TINKERPOP-1485
 URL: https://issues.apache.org/jira/browse/TINKERPOP-1485
 Project: TinkerPop
  Issue Type: Improvement
  Components: documentation
Affects Versions: 3.2.2
Reporter: stephen mallette
 Fix For: 3.3.0


Some time ago there was discussion on the Mailing List to move the web site to 
the source code repo so that it could be contributed to via pull request. It 
would be nice because then we could better rely on some basic static site 
generation to help deal with repetitive and sometimes error prone process of 
updating the header for the pages.

Anyway, a few thoughts:

1. need a shell script to publish the site to svn - something like 
{{bin/publish-site.sh}}
2. place files in the root of the project in a directory called {{site/}}
3. if possible, do some basic site generation with maybe some groovy script or 
just the shell script mentioned above to inject a "header file" for each page.



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

Re: [DISCUSS] breaking gremlin-server.sh just a little

[Stephen Mallette]

This is a very neat change I think - our gremlin-server.sh looks pretty
legit now. I'd just add one clarification that the proposal here is to push
this breaking change into the next release of 3.2.3. the question is
whether we wait for 3.3.0 which we would presumably start on pretty soon
(couple of weeks) to avoid pushing a breaking change into the 3.2.x line.
any thoughts on the matter?

On Fri, Sep 30, 2016 at 12:22 PM, Robert Dale  wrote:

> In relation to PR https://github.com/apache/tinkerpop/pull/439 , I'm
> proposing that gremlin-server.sh will be an init script.  As an init
> script, the expectation of not providing any parameters is to display
> usage/help:
>
> Usage: gremlin-server.sh {start|stop|restart|status|console|install
>   |}
>
> This breaks the current usage of starting the server in the foreground
> with the default yaml file.  Instead, a user would provide the command
> `console`.
>
> I have tried to keep other backwards compatibility by accepting `-i`
> (aka `install`) and a yaml file.  If the yaml file is the only
> parameter, the server will continue to start in the foreground.
>
> If there are no objections, then @spmallette will assume lazy
> consensus after 72 hours and do his thing.  I'm guessing.  ;-)
>
> --
> Robert Dale
>

[DISCUSS] breaking gremlin-server.sh just a little

[Robert Dale]

In relation to PR https://github.com/apache/tinkerpop/pull/439 , I'm
proposing that gremlin-server.sh will be an init script.  As an init
script, the expectation of not providing any parameters is to display
usage/help:

Usage: gremlin-server.sh {start|stop|restart|status|console|install
  |}

This breaks the current usage of starting the server in the foreground
with the default yaml file.  Instead, a user would provide the command
`console`.

I have tried to keep other backwards compatibility by accepting `-i`
(aka `install`) and a yaml file.  If the yaml file is the only
parameter, the server will continue to start in the foreground.

If there are no objections, then @spmallette will assume lazy
consensus after 72 hours and do his thing.  I'm guessing.  ;-)

-- 
Robert Dale

[GitHub] tinkerpop issue #444: TINKERPOP-1158 gremlin.sh -v emits log4j initializatio...

[dkuppitz]

Github user dkuppitz commented on the issue:

https://github.com/apache/tinkerpop/pull/444
  
This branch was rebased and force pushed. If you've had it checked out 
before, you'll likely have a merge conflict in your local version. Try to 
checkout a fresh copy:

```
git checkout master
git branch -D TINKERPOP-1158
git pull
git checkout TINKERPOP-1158
```


---
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-1158) gremlin.sh -v emits log4j initialization errors

[ASF GitHub Bot (JIRA)]

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

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

Github user dkuppitz commented on the issue:

https://github.com/apache/tinkerpop/pull/444
  
This branch was rebased and force pushed. If you've had it checked out 
before, you'll likely have a merge conflict in your local version. Try to 
checkout a fresh copy:

```
git checkout master
git branch -D TINKERPOP-1158
git pull
git checkout TINKERPOP-1158
```


> gremlin.sh -v emits log4j initialization errors
> ---
>
> Key: TINKERPOP-1158
> URL: https://issues.apache.org/jira/browse/TINKERPOP-1158
> Project: TinkerPop
>  Issue Type: Bug
>  Components: console
>Affects Versions: 3.1.1-incubating
>Reporter: Ariel Weisberg
>Assignee: Daniel Kuppitz
>Priority: Trivial
>
> I get a bunch of unrelated noise from log4j when I run hash 
> [c0b79c5|https://github.com/apache/incubator-tinkerpop/tree/c0b79c5c65db6424407ca00144be5167052c6c6b].
> I am running from the bin directory of the repository after {{mvn clean 
> install}}.
> {noformat}
> $ ./gremlin.sh -v
>  log4j:WARN No appenders could be found for logger 
> (com.jcabi.manifests.Manifests).
> log4j:WARN Please initialize the log4j system properly.
> log4j:WARN See http://logging.apache.org/log4j/1.2/faq.html#noconfig for more 
> info.
> gremlin 3.2.0-SNAPSHOT
> {noformat}



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

[GitHub] tinkerpop issue #439: TINKERPOP-980: added sysv and systemd init scripts

[robertdale]

Github user robertdale commented on the issue:

https://github.com/apache/tinkerpop/pull/439
  
Cool. I was wondering how to link. Didn't think it was absolute.  I hope it 
works. Tried testing with `./docker/build.sh -d` but it hangs at installing 
plugins `* hadoop-gremlin ...`.



---
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-980) Add a service script or daemon mode in the distribution

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on TINKERPOP-980:
--

Github user robertdale commented on the issue:

https://github.com/apache/tinkerpop/pull/439
  
Cool. I was wondering how to link. Didn't think it was absolute.  I hope it 
works. Tried testing with `./docker/build.sh -d` but it hangs at installing 
plugins `* hadoop-gremlin ...`.



> Add a service script or daemon mode in the distribution
> ---
>
> Key: TINKERPOP-980
> URL: https://issues.apache.org/jira/browse/TINKERPOP-980
> Project: TinkerPop
>  Issue Type: Improvement
>  Components: server
>Affects Versions: 3.0.2-incubating
>Reporter: Jeremy Hanna
>Assignee: Dylan Millikin
>Priority: Minor
>  Labels: breaking
>
> Based on this discussion, it looks like there was an example from [~dkuppitz] 
> on how to create a gremlin server service on linux:
> https://groups.google.com/forum/#!msg/gremlin-users/uA48IQ3YJcw/4KnUKIS8HI4J
> Here is a link to the gist for the service:
> https://gist.github.com/dkuppitz/20bda51e3465a612cd9b
> I think it would be great to include this or a way to daemonize the server 
> into the tinkerpop distribution.



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

[jira] [Commented] (TINKERPOP-1484) Bad interaction of long-typed vertex properties with TinkerGraph indexes

[Florin Mihaila (JIRA)]

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

Florin Mihaila commented on TINKERPOP-1484:
---

> I don't know how we would make all this work better offhand. Smarter indices? 
> We have similar annoyances with ids and .equals. I won't close this yet in 
> case anyone has ideas for what could be done to make this less confusing.

Thank you for your explanation. I don't know whether it's possible/desirable 
for the TinkerGraph indexes to do what the in-memory filtering does, but until 
a fix is proposed by someone familiar with the implementation, given that a 
simple workaround exists, I would like to suggest the inclusion of a line in 
the TinkerPop documentation on indexes to help users avoid this trap.

> Bad interaction of long-typed vertex properties with TinkerGraph indexes
> 
>
> Key: TINKERPOP-1484
> URL: https://issues.apache.org/jira/browse/TINKERPOP-1484
> Project: TinkerPop
>  Issue Type: Bug
>  Components: tinkergraph
>Affects Versions: 3.2.2, 3.2.3
> Environment: macOS Sierra (v10.12), jdk 1.8.0_102-b14 
>Reporter: Florin Mihaila
>Priority: Minor
>
> In graphs with indexed properties, queries fail on certain vertices (but 
> not all) with properties of type long.
> 
> The following code reproduces the bug:
> 
> {code:title=bug.groovy}
> graph = TinkerGraph.open() 
> graph.createIndex('other', Vertex.class) // (A)
> graph.createIndex('prop', Vertex.class)  // (B)
>   
> v = graph.addVertex()
> v.property('prop', (long)1)
> v.property('other', 0)
>   
> v = graph.addVertex()
> v.property('prop', 12345678910)
> v.property('other', 1)
>   
> g = graph.traversal()
> {code}
> 
> The verbatim console session:
>   
> {noformat}
> $ bin/gremlin.sh bug.groovy
>   
>  \,,,/
>  (o o)
> -oOOo-(3)-oOOo-
> plugin activated: tinkerpop.server
> plugin activated: tinkerpop.utilities
> plugin activated: tinkerpop.tinkergraph
> gremlin> g.V().valueMap()
> ==>[other:[0],prop:[1]]
> ==>[other:[1],prop:[12345678910]]
> gremlin> g.V().has('prop', 1)   // (1)
> gremlin> g.V().has('prop', (long)1)   // (2) 
> ==>v[0]
> gremlin> g.V().has('other', 0).has('prop', 1) // (3)
> ==>v[0]
> gremlin> g.V().has('prop', 12345678910) // (4)
> ==>v[3]
> gremlin> 
>   
> {noformat}  
>   
> h4. Observations:
> 1. The node is _not_ found, although it's there.
> 2. The node _is_ found if the property value is explicitly cast to long.
> 3. The node _is_ found if the graph is queried on another indexed 
> property first.
> 4. The node _is_ found if the property value is wider than an int.
> 
> h4. Variations:
> v1. If the 'other' property is not indexed (line A), query (2) fails.
> v2. If the 'prop' property is not indexed (line B), all queries succeed!
>   
> Tested on freshly built tinkerpop distributions, versions 3.2.2 and 3.2.3.



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

[jira] [Commented] (TINKERPOP-1483) PropertyMapStep returns Map<String,E> but puts non String keys in it!

[ASF GitHub Bot (JIRA)]

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

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

Github user JPMoresmau commented on the issue:

https://github.com/apache/tinkerpop/pull/446
  
Well, I wasn't going to change the API on my very first PR :-). The first 
thing I did with a valueMap result was to iterate on the keys, which crashes... 
Of course if you want to change the API to Map it's fine.


> PropertyMapStep returns Map but puts non String keys in it!
> -
>
> Key: TINKERPOP-1483
> URL: https://issues.apache.org/jira/browse/TINKERPOP-1483
> Project: TinkerPop
>  Issue Type: Bug
>  Components: process
>Affects Versions: 3.2.2
>Reporter: JP Moresmau
>
> PropertyMapStep.map has return type Map, but if includeTokens is 
> true:
> {code}
> if (element instanceof VertexProperty) {
> map.put(T.id, element.id());
> map.put(T.key, ((VertexProperty) element).key());
> map.put(T.value, ((VertexProperty) element).value());
> } else {
> map.put(T.id, element.id());
> map.put(T.label, element.label());
> }
> {code}
> T.id, T.key and T.value are NOT strings, so code looping through the keys in 
> Java fails. toString() are missing... But do we rely on having these keys in 
> other operations?



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

[jira] [Commented] (TINKERPOP-1483) PropertyMapStep returns Map<String,E> but puts non String keys in it!

[ASF GitHub Bot (JIRA)]

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

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

Github user okram commented on the issue:

https://github.com/apache/tinkerpop/pull/446
  
Hm. This is a hard pill to swallow as its not backwards compatible. I was 
thinking you were going to go the route of making it `Map` and 
thus, allow the enums as they are. If people have code that is `map.get(id)`, 
your changes will break their code.


> PropertyMapStep returns Map but puts non String keys in it!
> -
>
> Key: TINKERPOP-1483
> URL: https://issues.apache.org/jira/browse/TINKERPOP-1483
> Project: TinkerPop
>  Issue Type: Bug
>  Components: process
>Affects Versions: 3.2.2
>Reporter: JP Moresmau
>
> PropertyMapStep.map has return type Map, but if includeTokens is 
> true:
> {code}
> if (element instanceof VertexProperty) {
> map.put(T.id, element.id());
> map.put(T.key, ((VertexProperty) element).key());
> map.put(T.value, ((VertexProperty) element).value());
> } else {
> map.put(T.id, element.id());
> map.put(T.label, element.label());
> }
> {code}
> T.id, T.key and T.value are NOT strings, so code looping through the keys in 
> Java fails. toString() are missing... But do we rely on having these keys in 
> other operations?



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

[GitHub] tinkerpop issue #446: TINKERPOP-1483: valueMap should always return string k...

[okram]

Github user okram commented on the issue:

https://github.com/apache/tinkerpop/pull/446
  
Hm. This is a hard pill to swallow as its not backwards compatible. I was 
thinking you were going to go the route of making it `Map` and 
thus, allow the enums as they are. If people have code that is `map.get(id)`, 
your changes will break their code.


---
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 pull request #446: TINKERPOP-1483: valueMap should always return s...

[JPMoresmau]

GitHub user JPMoresmau opened a pull request:

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

TINKERPOP-1483: valueMap should always return string keys

Code changed, test added

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

$ git pull https://github.com/JPMoresmau/tinkerpop TINKERPOP-1483

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

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


commit 02a179ca3aba5089faca25f20647ff7dc1de1e6a
Author: jpmoresmau 
Date:   2016-09-30T14:49:49Z

valueMap should always return string keys




---
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-1483) PropertyMapStep returns Map<String,E> but puts non String keys in it!

[ASF GitHub Bot (JIRA)]

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

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

GitHub user JPMoresmau opened a pull request:

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

TINKERPOP-1483: valueMap should always return string keys

Code changed, test added

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

$ git pull https://github.com/JPMoresmau/tinkerpop TINKERPOP-1483

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

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


commit 02a179ca3aba5089faca25f20647ff7dc1de1e6a
Author: jpmoresmau 
Date:   2016-09-30T14:49:49Z

valueMap should always return string keys




> PropertyMapStep returns Map but puts non String keys in it!
> -
>
> Key: TINKERPOP-1483
> URL: https://issues.apache.org/jira/browse/TINKERPOP-1483
> Project: TinkerPop
>  Issue Type: Bug
>  Components: process
>Affects Versions: 3.2.2
>Reporter: JP Moresmau
>
> PropertyMapStep.map has return type Map, but if includeTokens is 
> true:
> {code}
> if (element instanceof VertexProperty) {
> map.put(T.id, element.id());
> map.put(T.key, ((VertexProperty) element).key());
> map.put(T.value, ((VertexProperty) element).value());
> } else {
> map.put(T.id, element.id());
> map.put(T.label, element.label());
> }
> {code}
> T.id, T.key and T.value are NOT strings, so code looping through the keys in 
> Java fails. toString() are missing... But do we rely on having these keys in 
> other operations?



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

[jira] [Commented] (TINKERPOP-1158) gremlin.sh -v emits log4j initialization errors

[ASF GitHub Bot (JIRA)]

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

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

Github user okram commented on the issue:

https://github.com/apache/tinkerpop/pull/444
  
I get this:

```
~/software/tinkerpop bin/gremlin.sh
bin/gremlin.sh: line 25: syntax error near unexpected token `<<<'
```


> gremlin.sh -v emits log4j initialization errors
> ---
>
> Key: TINKERPOP-1158
> URL: https://issues.apache.org/jira/browse/TINKERPOP-1158
> Project: TinkerPop
>  Issue Type: Bug
>  Components: console
>Affects Versions: 3.1.1-incubating
>Reporter: Ariel Weisberg
>Assignee: Daniel Kuppitz
>Priority: Trivial
>
> I get a bunch of unrelated noise from log4j when I run hash 
> [c0b79c5|https://github.com/apache/incubator-tinkerpop/tree/c0b79c5c65db6424407ca00144be5167052c6c6b].
> I am running from the bin directory of the repository after {{mvn clean 
> install}}.
> {noformat}
> $ ./gremlin.sh -v
>  log4j:WARN No appenders could be found for logger 
> (com.jcabi.manifests.Manifests).
> log4j:WARN Please initialize the log4j system properly.
> log4j:WARN See http://logging.apache.org/log4j/1.2/faq.html#noconfig for more 
> info.
> gremlin 3.2.0-SNAPSHOT
> {noformat}



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

[GitHub] tinkerpop issue #444: TINKERPOP-1158 gremlin.sh -v emits log4j initializatio...

[okram]

Github user okram commented on the issue:

https://github.com/apache/tinkerpop/pull/444
  
I get this:

```
~/software/tinkerpop bin/gremlin.sh
bin/gremlin.sh: line 25: syntax error near unexpected token `<<<'
```


---
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 #445: TINKERPOP-1470: InlineFilterStrategy should try and P....

[twilmes]

Github user twilmes commented on the issue:

https://github.com/apache/tinkerpop/pull/445
  
I like how you pulled the chunks of processing out into separate methods in 
`InlineFilterStrategy`.  Cleans things up nicely.

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-1470) InlineFilterStrategy should try and P.or() has() children in OrSteps.

[ASF GitHub Bot (JIRA)]

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

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

Github user twilmes commented on the issue:

https://github.com/apache/tinkerpop/pull/445
  
I like how you pulled the chunks of processing out into separate methods in 
`InlineFilterStrategy`.  Cleans things up nicely.

VOTE: +1


> InlineFilterStrategy should try and P.or() has() children in OrSteps.
> -
>
> Key: TINKERPOP-1470
> URL: https://issues.apache.org/jira/browse/TINKERPOP-1470
> Project: TinkerPop
>  Issue Type: Improvement
>  Components: process
>Affects Versions: 3.2.2
>Reporter: Marko A. Rodriguez
>Assignee: Marko A. Rodriguez
>
> The following patterns:
> {code}
> g.V().or(has("age",gt(20)), has("age",lt(32)))
> g.V().and(or(has("age",gt(20)), has("age",lt(32))),has("age",neq(23))
> {code}
> should be re-written by {{InlineFilterStrategy}} as:
> {code}
> g.V().has("age",gt(20).or(lt(32)))
> g.V().has("age",gt(20).or(lt(32)).and(neq(23)))
> {code}
> This would then make it easier for provider strategies to fold the predicate 
> into graph/vertex-centric push down predicates accordingly.
> Note that {{InlineFilterStep}} already has the code to flatten {{AndSteps}}. 
> Thus, during its recursion, it would do the following rewrites to get to the 
> final form.
> {code}
> g.V().and(or(has("age",gt(20)), has("age",lt(32))),has("age",neq(23))
> g.V().or(has("age",gt(20)), has("age",lt(32))).has("age",neq(23))
> g.V().has("age",gt(20).or(lt(32))).has("age",neq(23))
> g.V().has("age",gt(20).or(lt(32)).and(neq(23)))
> {code}



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

[GitHub] tinkerpop issue #439: TINKERPOP-980: added sysv and systemd init scripts

[spmallette]

Github user spmallette commented on the issue:

https://github.com/apache/tinkerpop/pull/439
  
wow - @robertdale - this is a really nice PR. I added the "breaking" label 
to the JIRA ticket as this would prevent gremlin-server.sh from working as it 
did before. I think I'm ok with that, but we should probably have a DISCUSS on 
the dev list about that just to bring it to everyone's attention to make sure 
there are no objections. Do you mind starting that thread for us - otherwise I 
will kick one off?

As for the PR itself, I can test this manually, but will have to rely on 
others for code review. gremlin-server.sh is looking pretty legit!


---
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-980) Add a service script or daemon mode in the distribution

[stephen mallette (JIRA)]

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

stephen mallette updated TINKERPOP-980:
---
Labels: breaking  (was: )

> Add a service script or daemon mode in the distribution
> ---
>
> Key: TINKERPOP-980
> URL: https://issues.apache.org/jira/browse/TINKERPOP-980
> Project: TinkerPop
>  Issue Type: Improvement
>  Components: server
>Affects Versions: 3.0.2-incubating
>Reporter: Jeremy Hanna
>Assignee: Dylan Millikin
>Priority: Minor
>  Labels: breaking
>
> Based on this discussion, it looks like there was an example from [~dkuppitz] 
> on how to create a gremlin server service on linux:
> https://groups.google.com/forum/#!msg/gremlin-users/uA48IQ3YJcw/4KnUKIS8HI4J
> Here is a link to the gist for the service:
> https://gist.github.com/dkuppitz/20bda51e3465a612cd9b
> I think it would be great to include this or a way to daemonize the server 
> into the tinkerpop distribution.



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

[jira] [Updated] (TINKERPOP-1484) Bad interaction of long-typed vertex properties with TinkerGraph indexes

[stephen mallette (JIRA)]

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

stephen mallette updated TINKERPOP-1484:

Priority: Minor  (was: Major)

I think this all makes sense if you understand how the TinkerGraph indices 
work. 

> 1. The node is not found, although it's there.
> 2. The node is found if the property value is explicitly cast to long.

You made the value a Long so you must query it as a Long. 

{code}
gremlin> g.V().has('prop', 1l) 
==>v[0]
{code}

Values in indices are compared using {{.equals()}} so the type is taken into 
account.

> 3. The node is found if the graph is queried on another indexed property 
> first.

The TinkerGraph indices aren't super smart. I'm pretty sure that they grab the 
first index in a set of {{has()}} steps and then uses that for the initial 
index lookup then it in-memory filters the rest. So with TinkerGraph it is 
always best to put highly selective properties first in a traversal. Note that 
you get a result here because in-memory {{has}} is better at number comparison 
and doesn't do {{.equals}} for those cases.

> 4. The node is found if the property value is wider than an int.

Based on my previous explanations, that's expected.

> v1. If the 'other' property is not indexed (line A), query (2) fails.

Again, my previous explanation explains this, but if you don't index "other" 
then " TinkerGraph uses "prop" as the index and then you get nothing returned.

> v2. If the 'prop' property is not indexed (line B), all queries succeed!

Same thing - now you're all in-memory so {{has()}} in-memory filtering without 
{{.equals()}} is in play.

I don't know how we would make all this work better offhand. Smarter indices? 
We have similar annoyances with ids and {{.equals}}. I won't close this yet in 
case anyone has ideas for what could be done to make this less confusing.



> Bad interaction of long-typed vertex properties with TinkerGraph indexes
> 
>
> Key: TINKERPOP-1484
> URL: https://issues.apache.org/jira/browse/TINKERPOP-1484
> Project: TinkerPop
>  Issue Type: Bug
>  Components: tinkergraph
>Affects Versions: 3.2.2, 3.2.3
> Environment: macOS Sierra (v10.12), jdk 1.8.0_102-b14 
>Reporter: Florin Mihaila
>Priority: Minor
>
> In graphs with indexed properties, queries fail on certain vertices (but 
> not all) with properties of type long.
> 
> The following code reproduces the bug:
> 
> {code:title=bug.groovy}
> graph = TinkerGraph.open() 
> graph.createIndex('other', Vertex.class) // (A)
> graph.createIndex('prop', Vertex.class)  // (B)
>   
> v = graph.addVertex()
> v.property('prop', (long)1)
> v.property('other', 0)
>   
> v = graph.addVertex()
> v.property('prop', 12345678910)
> v.property('other', 1)
>   
> g = graph.traversal()
> {code}
> 
> The verbatim console session:
>   
> {noformat}
> $ bin/gremlin.sh bug.groovy
>   
>  \,,,/
>  (o o)
> -oOOo-(3)-oOOo-
> plugin activated: tinkerpop.server
> plugin activated: tinkerpop.utilities
> plugin activated: tinkerpop.tinkergraph
> gremlin> g.V().valueMap()
> ==>[other:[0],prop:[1]]
> ==>[other:[1],prop:[12345678910]]
> gremlin> g.V().has('prop', 1)   // (1)
> gremlin> g.V().has('prop', (long)1)   // (2) 
> ==>v[0]
> gremlin> g.V().has('other', 0).has('prop', 1) // (3)
> ==>v[0]
> gremlin> g.V().has('prop', 12345678910) // (4)
> ==>v[3]
> gremlin> 
>   
> {noformat}  
>   
> h4. Observations:
> 1. The node is _not_ found, although it's there.
> 2. The node _is_ found if the property value is explicitly cast to long.
> 3. The node _is_ found if the graph is queried on another indexed 
> property first.
> 4. The node _is_ found if the property value is wider than an int.
> 
> h4. Variations:
> v1. If the 'other' property is not indexed (line A), query (2) fails.
> v2. If the 'prop' property is not indexed (line B), all queries succeed!
>   
> Tested on freshly built tinkerpop distributions, versions 3.2.2 and 3.2.3.



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

[jira] [Commented] (TINKERPOP-1470) InlineFilterStrategy should try and P.or() has() children in OrSteps.

[ASF GitHub Bot (JIRA)]

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

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

Github user okram commented on the issue:

https://github.com/apache/tinkerpop/pull/445
  
Ran integration tests overnight.

```
[INFO] 

[INFO] BUILD SUCCESS
[INFO] 

[INFO] Total time: 05:12 h
[INFO] Finished at: 2016-09-29T21:09:28-06:00
[INFO] Final Memory: 121M/1519M
[INFO] 

```


> InlineFilterStrategy should try and P.or() has() children in OrSteps.
> -
>
> Key: TINKERPOP-1470
> URL: https://issues.apache.org/jira/browse/TINKERPOP-1470
> Project: TinkerPop
>  Issue Type: Improvement
>  Components: process
>Affects Versions: 3.2.2
>Reporter: Marko A. Rodriguez
>Assignee: Marko A. Rodriguez
>
> The following patterns:
> {code}
> g.V().or(has("age",gt(20)), has("age",lt(32)))
> g.V().and(or(has("age",gt(20)), has("age",lt(32))),has("age",neq(23))
> {code}
> should be re-written by {{InlineFilterStrategy}} as:
> {code}
> g.V().has("age",gt(20).or(lt(32)))
> g.V().has("age",gt(20).or(lt(32)).and(neq(23)))
> {code}
> This would then make it easier for provider strategies to fold the predicate 
> into graph/vertex-centric push down predicates accordingly.
> Note that {{InlineFilterStep}} already has the code to flatten {{AndSteps}}. 
> Thus, during its recursion, it would do the following rewrites to get to the 
> final form.
> {code}
> g.V().and(or(has("age",gt(20)), has("age",lt(32))),has("age",neq(23))
> g.V().or(has("age",gt(20)), has("age",lt(32))).has("age",neq(23))
> g.V().has("age",gt(20).or(lt(32))).has("age",neq(23))
> g.V().has("age",gt(20).or(lt(32)).and(neq(23)))
> {code}



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

[GitHub] tinkerpop issue #445: TINKERPOP-1470: InlineFilterStrategy should try and P....

[okram]

Github user okram commented on the issue:

https://github.com/apache/tinkerpop/pull/445
  
Ran integration tests overnight.

```
[INFO] 

[INFO] BUILD SUCCESS
[INFO] 

[INFO] Total time: 05:12 h
[INFO] Finished at: 2016-09-29T21:09:28-06:00
[INFO] Final Memory: 121M/1519M
[INFO] 

```


---
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 #439: TINKERPOP-980: added sysv and systemd init scripts

[robertdale]

Github user robertdale commented on the issue:

https://github.com/apache/tinkerpop/pull/439
  
- `gremlin-server.sh` _is_ the init script.  This makes it more inline with 
other Apache servers like Tomcat, ActiveMQ, solr, etc.
- Moved how to install "As A Service" from Upgrade to Gremlin Server 
Configuration per @PommeVerte 
- Also added parameters and environment config to Server Configuration 
section
- Deprecated `-i` in favor of `install`
- Starting `gremlin-server.sh` without parameters is a breaking change. 
Amazingly, it's not ever actually used anywhere without parameters.
 


---
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: When do we release TinkerPop 3.2.3?

[Ted Wilmes]

That sounds good to me and unless someone else wants to take the
reigns on 3.1.5, I can take a crack at it again.  The formatting snafu in
the 3.1.4 change log has been haunting my dreams since last release
so I'd like to get it nailed this time.

--Ted

On Fri, Sep 30, 2016 at 6:04 AM, Stephen Mallette 
wrote:

> Wow - end of September already...I think we could code freeze at the
> end of next week, 10/7 with release VOTE for Monday, 10/17.  In addition to
> 3.2.3, we also will drop 3.1.5.  There wasn't a lot of change on 3.1.5 but
> there were bug fixes nonetheless. Does that sound good to everyone?
> Obviously, your silence indicates that you are blissfully enamored with the
> proposal.
>
> For PMC members - Ted was good enough to pick up 3.1.4 release manager
> duties last time and I thought that was cool because the more folks setup
> to be able to to this the better. I think he'd agree that it wasn't that
> painful. :) Anyway, any volunteers to help with this release?
>
>
>
> On Thu, Sep 29, 2016 at 2:06 PM, Marko Rodriguez 
> wrote:
>
> > Hi,
> >
> > TinkerPop 3.2.2 was sort of a poop-show. Lots of bugs and compatibility
> > issues were introduced. As such, we said a while back that 3.2.3 would
> be a
> > cleanup of 3.2.2 and then a fast release.
> >
> > What are the plans for a 3.2.3 release? In terms of the work I have
> slated
> > for 3.2.3, I’m ready whenever.
> >
> > Thanks,
> > Marko.
> >
> > http://markorodriguez.com
> >
> >
> >
> >
>

Re: When do we release TinkerPop 3.2.3?

[Stephen Mallette]

Wow - end of September already...I think we could code freeze at the
end of next week, 10/7 with release VOTE for Monday, 10/17.  In addition to
3.2.3, we also will drop 3.1.5.  There wasn't a lot of change on 3.1.5 but
there were bug fixes nonetheless. Does that sound good to everyone?
Obviously, your silence indicates that you are blissfully enamored with the
proposal.

For PMC members - Ted was good enough to pick up 3.1.4 release manager
duties last time and I thought that was cool because the more folks setup
to be able to to this the better. I think he'd agree that it wasn't that
painful. :) Anyway, any volunteers to help with this release?



On Thu, Sep 29, 2016 at 2:06 PM, Marko Rodriguez 
wrote:

> Hi,
>
> TinkerPop 3.2.2 was sort of a poop-show. Lots of bugs and compatibility
> issues were introduced. As such, we said a while back that 3.2.3 would be a
> cleanup of 3.2.2 and then a fast release.
>
> What are the plans for a 3.2.3 release? In terms of the work I have slated
> for 3.2.3, I’m ready whenever.
>
> Thanks,
> Marko.
>
> http://markorodriguez.com
>
>
>
>

[jira] [Commented] (TINKERPOP-1467) Improve close() operations on the Java driver

[ASF GitHub Bot (JIRA)]

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

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

Github user dkuppitz commented on the issue:

https://github.com/apache/tinkerpop/pull/441
  
As said in a private chat, integration tests were stuck when I ran them 
first. However, the second attempt succeeded. More investigation is apparently 
needed, but for this PR:

VOTE: +1


> Improve close() operations on the Java driver 
> --
>
> Key: TINKERPOP-1467
> URL: https://issues.apache.org/jira/browse/TINKERPOP-1467
> Project: TinkerPop
>  Issue Type: Bug
>  Components: driver
>Affects Versions: 3.1.3
>Reporter: stephen mallette
>Assignee: stephen mallette
> Fix For: 3.1.5, 3.2.3
>
>
> A few big problems:
> 1. Client will hang if submitting a request after {{close()}}
> 2. Multiple calls to {{close()}} hangs periodically
> 3. Closing the {{Cluster}} doesn't attempt to clean up open {{Client}} 
> instances.



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

[GitHub] tinkerpop issue #441: TINKERPOP-1467 Corrected a number of problems in close...

[dkuppitz]

Github user dkuppitz commented on the issue:

https://github.com/apache/tinkerpop/pull/441
  
As said in a private chat, integration tests were stuck when I ran them 
first. However, the second attempt succeeded. More investigation is apparently 
needed, but for this PR:

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