The image attachment apparently didn't make it to the mailing list. Here's a direct link: https://s4.postimg.org/6nmfia5q5/extime.png
Cheers, Daniel On Wed, Aug 17, 2016 at 10:16 PM, Daniel Kuppitz <[email protected]> wrote: > do you have any recommendation for what that would look like in the output? > > > Something like this (I hope the screenshot will make it to the mailing > list): > > [image: Inline image 1] > > Cheers, > Daniel > > > On Wed, Aug 17, 2016 at 10:02 PM, Stephen Mallette <[email protected]> > wrote: > >> > But I still think that it would be beneficial to see the execution time >> for every single statement. Could be an option that can be turned on and >> off though. >> >> do you have any recommendation for what that would look like in the >> output? >> >> >> > This means *"will not fix; close"* for both tickets. That's >> unfortunate, but >> if it's really such a pain to add those features, well, then that's that. >> >> I just sorta feel +0 on these but I'd like to tidy up a bit at the same >> time. If others feel good about them, then by all means let's keep them >> open. I'm just bringing them to everyone's attention since there are a lot >> of them. >> >> On Wed, Aug 17, 2016 at 3:58 PM, Daniel Kuppitz <[email protected]> wrote: >> >> > Personally I like the execution time and syntax coloring feature >> requests. >> > >> > *Execution Time:* >> > >> > clock() is still good, because it allows you to measure the execution >> time >> > of larger code blocks and it does things like warmup rounds under the >> hood >> > to provide more realistic execution times. But I still think that it >> would >> > be beneficial to see the execution time for every single statement. >> Could >> > be an option that can be turned on and off though. >> > >> > *Syntax Highlighting:* >> > >> > Especially larger results can be hard to read. Anything that makes the >> > output more readable would be great. This can be either syntax >> highlighting >> > or proper indenting (or both). >> > >> > If no one has any thoughts on these ..., I'll act on these as I've >> > > described in this post. >> > >> > >> > This means *"will not fix; close"* for both tickets. That's unfortunate, >> > but if it's really such a pain to add those features, well, then that's >> > that. >> > >> > Cheers, >> > Daniel >> > >> > >> > >> > >> > >> > On Wed, Aug 17, 2016 at 8:23 PM, Stephen Mallette <[email protected] >> > >> > wrote: >> > >> > > There's a handful of semi-related JIRA issues for Gremlin Console out >> > there >> > > - I say "semi-related" because they all largely revolve around >> usability. >> > > Most recently is the discussion again about return of "null" for void >> > > returns: >> > > >> > > https://issues.apache.org/jira/browse/TINKERPOP-1409 >> > > >> > > We've had that discussion many times over the years and I'm not sure >> that >> > > we're going to come up with anything much better than the way it works >> > now. >> > > The JIRA discussion is already looking like past discussions on this >> > topic. >> > > >> > > Then there is this issue to :clear automatically after an error: >> > > >> > > https://issues.apache.org/jira/browse/TINKERPOP-1226 >> > > >> > > I think I'd like to close this without implementing with the >> reasoning I >> > > presented in the comment, but I thought others might feel different >> so I >> > > thought I'd bring it to everyone's attention for discussion. >> > > >> > > This next one is about showing the "execution time" in the console: >> > > >> > > https://issues.apache.org/jira/browse/TINKERPOP-1123 >> > > >> > > I see the reasoning for presenting that information but I don't think >> it >> > > fits the REPL environment that we have very well - I'd rather just >> close >> > > it. I would say that users should simply use clock() or the other >> > > performance tools we have if they want to track execution time. >> > > >> > > The following issue ultimately suggest we use line numbers in the >> console >> > > as groovysh does: >> > > >> > > https://issues.apache.org/jira/browse/TINKERPOP-1285 >> > > >> > > I could see that as useful, but personally I'd rather not change that >> and >> > > close the issue. I suppose it could be a configuration that users >> turn on >> > > as an option, but is it that useful to people that we should take the >> > time >> > > to code that? >> > > >> > > In this next issue, there is a request for shell coloring: >> > > >> > > https://issues.apache.org/jira/browse/TINKERPOP-1037 >> > > >> > > I've never been able to get that to work.............I think it would >> be >> > > neat, groovysh does most of the work and it really doesn't introduce >> much >> > > code, etc. - maybe someone smarter than me can figure that one out >> and we >> > > can leave it open (at this point though after multiple attempts, i'd >> > > personally just rather close it). >> > > >> > > Finally, there is this one, which talks about "additional help": >> > > >> > > https://issues.apache.org/jira/browse/TINKERPOP-1246 >> > > >> > > Recall that we had that incomplete PR for displaying javadoc in the >> > > console. That was a nice generalized solution, but didn't really >> belong >> > as >> > > a PR to TinkerPop. To me that was the best way to re-use existing >> > > documentation. It wouldn't be great for us to maintain special docs >> just >> > > for the Console. Anyone have any ideas here? Is this worth trying to >> do >> > at >> > > some point? or will we always end up pushing any such ideas down to >> > > groovysh and not really make them a part of TinkerPop in which case, >> we >> > > should just close this? >> > > >> > > If no one has any thoughts on these (aside from TINKERPOP-1409 which >> is >> > > having active discussion), I'll act on these as I've described in this >> > > post. >> > > >> > >> > >
