[Lldb-commits] [PATCH] D24591: [LIT] First pass of LLDB LIT support
Zachary Turner via lldb-commits
lldb-commits at lists.llvm.org
Wed Sep 14 16:58:53 PDT 2016
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.id
(lldb) print-dev threads.id
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
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 <jingham at 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.
> > On Sep 14, 2016, at 4:43 PM, Zachary Turner <zturner at google.com> wrote:
> > On Wed, Sep 14, 2016 at 4:39 PM Jim Ingham <jingham at 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.
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the lldb-commits