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:
(lldb) print-dev threads[3].id 0x1234 (lldb) print-dev threads[4].id 0x2345 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. 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. On Wed, Sep 14, 2016 at 4:51 PM Jim Ingham <jing...@apple.com> wrote: > 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. > > 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. > > 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. > > Jim > > > > > On Sep 14, 2016, at 4:43 PM, Zachary Turner <ztur...@google.com> wrote: > > > > > > > > On Wed, Sep 14, 2016 at 4:39 PM Jim Ingham <jing...@apple.com> wrote: > > > > > 4. You can test a LOT more things when you are able to use an api that > doesn't have to be stable. > > > > 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." > > > > 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. > >
_______________________________________________ lldb-commits mailing list lldb-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
