[Lldb-commits] [PATCH] D24591: [LIT] First pass of LLDB LIT support

[Zachary Turner via lldb-commits]

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 <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.
>
> Jim
>
>
>
> > 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...
URL: <http://lists.llvm.org/pipermail/lldb-commits/attachments/20160914/2d64d5d7/attachment.html>