Also, failures that are easy to reproduce are easy to debug. When a test
fails this way, you get a command line that can reproduce the problem that
can be debugged directly without having to debug across the python
boundary. I find that very helpful personally
On Wed, Feb 7, 2018 at 5:48 PM Zachary Turner <ztur...@google.com> wrote:
> Same reason that people use perl for heavy text processing, R for
> scientific programming, python for rapid iteration. It’s what they’re built
> for. When something is built for a very focused specific problem domain,
> the problems in that domain can be expressed very concisely and naturally.
>
> In the current python test there’s 4-6 lines of Python boilerplate for
> every 2-3 lines of test “meat”. And it’s all code, making matters even
> worse.
>
> A FileCheck test will have approximately 0 lines of text that aren’t part
> of the “meat” of the test, and on top of that it can poke at every low
> level detail of a system, not just those that are blessed with an api
>
> On Wed, Feb 7, 2018 at 5:29 PM Jim Ingham via Phabricator <
> revi...@reviews.llvm.org> wrote:
>
>> jingham requested changes to this revision.
>> jingham added a comment.
>> This revision now requires changes to proceed.
>>
>> You do care about the common match string. When the lldb driver handles
>> completion, if the common match string is not null, we append that to the
>> line at the cursor position, then present the matches if there is more than
>> one. So the common match string also has to be tested.
>>
>> The ability to page the completion requests in the API would be useful
>> for instance in symbol completion where you can get lots of matches, but if
>> you only plan to display the first page you'd rather not pay the cost to go
>> find them all. I put that in the SB API's because I didn't want to have to
>> add another one when I got around to implementing this. When I get around
>> to this I'll fix the docs... But you could remove that from the lldb
>> private version if you're so motivated. I'll still remember I intended to
>> extend it this way, even if nobody else will see that.
>>
>> We can't return a std::pair across the SB API's, but we could make the
>> common match be another parameter. There was some reason this seemed
>> logical to me at the time, but I must admit I can't remember why now. It
>> is in practice easy to use, however. You append element 0 to the cursor
>> position, then print the rest of the completions if num_matches is > 1.
>> Again, feel free to switch the lldb_private API if it bugs you.
>>
>> An additional test in the Python testsuite is:
>>
>> def test_target_create_dash_co(self):
>> """Test that 'target create --co' completes to 'target variable
>> --core '."""
>> self.complete_from_to('target create --co', 'target create --core ')
>>
>> So I still don't see why the file check method is preferable. But to
>> each his own, I guess.
>>
>>
>> https://reviews.llvm.org/D43048
>>
>>
>>
>>
_______________________________________________
lldb-commits mailing list
lldb-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
