that actually looks kinda good - of course it assume the coloring issue can be solved - haha. I think you should add that image to the JIRA "timing" issue. Nice!
On Wed, Aug 17, 2016 at 4:21 PM, Daniel Kuppitz <[email protected]> wrote: > 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. >>> > > >>> > >>> >> >> >
