<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On Wed, Dec 2, 2015 at 11:20 AM, Todd Fiala <span dir="ltr"><<a href="mailto:todd.fiala@gmail.com" target="_blank">todd.fiala@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">Yeah I'd be good with that. I can change that as well.<div><br></div><div>-Todd</div></div><div class="gmail_extra"><div><div class="h5"><br><div class="gmail_quote">On Wed, Dec 2, 2015 at 11:10 AM, Zachary Turner <span dir="ltr"><<a href="mailto:zturner@google.com" target="_blank">zturner@google.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">Also another stylistic suggestion. I've been thinking about how to more logically organize all the source files now that we have a package. So it makes sense conceptually to group all of the different result formatters under a subpackage called formatters. So right now you've got <span style="font-family:monospace,monospace">lldbsuite.test.basic_results_</span><span style="font-family:monospace,monospace">formatter.</span><span style="font-family:monospace,monospace">BasicResultsFormatter </span>but it might make sense for this to be lldbsuite.test.formatters.basic.BasicResultsFormatter. If you do things this way, it can actually result in a substantially shorter command line, because the --results-formatter option can use lldbsuite.test.formatters as a starting point. So you could instead write:<div><br></div><div><span style="font-family:monospace,monospace">test/dotest.py --results-formatter basic</span><br></div><div><span style="font-family:monospace,monospace"><br></span></div><div>dotest then looks for a `basic.py` module in the `lldbsuite.test.formatters` package, looks for a class inside with a @result_formatter decorator, and instantiates that.<span style="font-family:monospace,monospace"><br></span></div><div><br></div><div>This has the advantage of making the command line shorter *and* a more logical source file organization.</div></div></blockquote></div></div></div></div></blockquote><div><br></div><div>The other thing that could allow me to do is possibly short-circuit the results formatter specifier so that, if just the module is specified, and if the module only has one ResultsFormatter-derived class, I can probably rig up code that figures out the right results formatter, shortening the required discriminator to something even shorter (i.e. module.classname becomes just module.) </div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="gmail_extra"><div><div class="h5"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div><div><br><div class="gmail_quote"><div dir="ltr">On Wed, Dec 2, 2015 at 11:04 AM Zachary Turner <<a href="mailto:zturner@google.com" target="_blank">zturner@google.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">Can --results-file=stdout be the default so that we don't have to specify that?</div><br><div class="gmail_quote"><div dir="ltr">On Wed, Dec 2, 2015 at 11:02 AM Todd Fiala via lldb-dev <<a href="mailto:lldb-dev@lists.llvm.org" target="_blank">lldb-dev@lists.llvm.org</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">Also, all the text in the summary is fixed-width lined up nicely, which may not show in the commit message description if you're using a variable-width font. On a terminal it looks nice.</div><div class="gmail_extra"><br><div class="gmail_quote">On Wed, Dec 2, 2015 at 11:01 AM, Todd Fiala <span dir="ltr"><<a href="mailto:todd.fiala@gmail.com" target="_blank">todd.fiala@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote"><span>On Wed, Dec 2, 2015 at 10:57 AM, Todd Fiala <span dir="ltr"><<a href="mailto:todd.fiala@gmail.com" target="_blank">todd.fiala@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div dir="ltr">Hi all,<div><br></div><div>I just put up an optional test results formatter that is a prototype of what we may move towards for our default test summary results. It went in here:</div><div><br></div><div>r254530<br clear="all"><div><br></div><div>and you can try it out with something like:</div><div><br></div><div><div>time test/dotest.py --executable `pwd`/build/Debug/lldb --results-formatter lldbsuite.test.basic_results_formatter.BasicResultsFormatter --results-file st</div><div>out</div></div><div><br></div></div></div></blockquote><div><br></div>
</span><p><span>I cut and paste my line, but more than likely for most people you'd just want this:</span></p>
<p><font face="monospace, monospace">test/dotest.py --results-formatter lldbsuite.test.basic_results_formatter.BasicResultsFormatter --results-file stdout <br><span></span></font></p><p><font face="monospace, monospace">The other stuff was specific to my setup. That line assumes you run from the lldb source dir root.</font></p><span><p><font face="monospace, monospace"><br></font></p><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div dir="ltr"><div><div></div><div>Let me know if this satisfies the basic needs of counts and whatnot. It counts test method runs rather than all the oddball "file, class, etc." counts we had before.</div><div><br></div><div>It prints out the Details section when there are details, and keeps it nice and clean when there are none.</div><div><br></div><div>It also mentions a bit about test reruns up top, but that won't come into play until I get the multi-test-pass, single-worker/low-load mechanism in place, which will depend on newer rerun count awareness support.</div><div><br></div><div>The change also cleans up places where the test event framework was using string codes and replaces them with symbolic constants.</div><div><br></div><div>Let me know what you think. I can tweak it as needed to address testbot and other needs. Once it looks reasonable, I'd like to move over to using it by default in the parallel test runner rather than the legacy support.</div><div><br></div><div>Thanks!</div><span><font color="#888888">-- <br><div><div dir="ltr">-Todd</div></div>
</font></span></div></div>
</blockquote></span></div><span><font color="#888888"><br><br clear="all"><div><br></div>-- <br><div><div dir="ltr">-Todd</div></div>
</font></span></div></div>
</blockquote></div><br><br clear="all"><div><br></div>-- <br><div><div dir="ltr">-Todd</div></div>
</div>
_______________________________________________<br>
lldb-dev mailing list<br>
<a href="mailto:lldb-dev@lists.llvm.org" target="_blank">lldb-dev@lists.llvm.org</a><br>
<a href="http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev" rel="noreferrer" target="_blank">http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev</a><br>
</blockquote></div></blockquote></div>
</div></div></blockquote></div><br><br clear="all"><div><br></div></div></div><span class="HOEnZb"><font color="#888888">-- <br><div><div dir="ltr">-Todd</div></div>
</font></span></div>
</blockquote></div><br><br clear="all"><div><br></div>-- <br><div class="gmail_signature"><div dir="ltr">-Todd</div></div>
</div></div>