<div dir="ltr">You can get thing 1, thing 2, and thing 3 in declarative ways with a command line api too.  Like the example I gave earlier:  <div><br></div><div>(lldb) print-dev threads[3].id</div><div>0x1234</div><div>(lldb) print-dev threads[4].id</div><div>0x2345</div><div><br></div><div>You're getting one value at a time, not a space separated list.  Although I think we could take it one step further and say that all developer commands like this must either return one value or a comma separated list with spaces.  In any case, we're not talking about the output of arbitrary commands here, we're talking about the output of a very controlled command which we can restrict any way we like.  And we can even have tests that validate that this special command's output always matches a particular simple regex to ensure that it's never something that will be confusing to parse.</div><div><br></div><div>Furthermore, we're talking about a command independent of the normal user command api.  There would be zero risk associated with changing the output format of a given command, because it would be completely independent of the command the tests would be using.</div></div><br><div class="gmail_quote"><div dir="ltr">On Wed, Sep 14, 2016 at 4:51 PM Jim Ingham <<a href="mailto:jingham@apple.com">jingham@apple.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">If the internal thing is three things in a list, you get back thing one, thing two and thing three in declarative ways rather than "I got three space separated things, maybe they had spaces in them, maybe there were quotes, etc, and don't ever change this now or you'll have to go fix all the tests...  I really don't see how going back to irregular text output grubbing is a step forward.<br class="gmail_msg">
<br class="gmail_msg">
Also, the SBInternal API's would be much simpler to write, (a) since you wouldn't have to concern yourself with how the other end was going to parse up what you were outputting and (b) because individual API calls are much easier to write than LLDB commands/sub-commands.<br class="gmail_msg">
<br class="gmail_msg">
You could have your special lldb command that produced JSON and then the test engine had some language to pick fields out, then you could only read this output with confidence, and you're back to the same fragility when testing the results of regular commands.  You could change all the regular commands to optionally produce some structured output, but that's a lot of work to reproduce something that already works pretty well.<br class="gmail_msg">
<br class="gmail_msg">
Jim<br class="gmail_msg">
<br class="gmail_msg">
<br class="gmail_msg">
<br class="gmail_msg">
> On Sep 14, 2016, at 4:43 PM, Zachary Turner <<a href="mailto:zturner@google.com" class="gmail_msg" target="_blank">zturner@google.com</a>> wrote:<br class="gmail_msg">
><br class="gmail_msg">
><br class="gmail_msg">
><br class="gmail_msg">
> On Wed, Sep 14, 2016 at 4:39 PM Jim Ingham <<a href="mailto:jingham@apple.com" class="gmail_msg" target="_blank">jingham@apple.com</a>> wrote:<br class="gmail_msg">
><br class="gmail_msg">
> > 4. You can test a LOT more things when you are able to use an api that doesn't have to be stable.<br class="gmail_msg">
><br class="gmail_msg">
> When I mentioned that API, I had in mind an internal Python module that you could use to grub into internals.  I'm all for that.  I'm not so much in favor of "I have an ad hoc command that prints out various bits of texts, and we'll use that for testing."<br class="gmail_msg">
><br class="gmail_msg">
> Is it any different though? Take the API you're imagining to grub for internals.  Now imagine the EXACT same API as an lldb command.  What's the difference?  What could you do with the Python API that you couldn't do with the command API?  Aside from write imperative control flow constructs, which I see as a positive rather than a negative.<br class="gmail_msg">
<br class="gmail_msg">
</blockquote></div>