[lldb-dev] [RFC]The future of pexpect

[Pavel Labath via lldb-dev]

On 21/02/2019 19:48, Ted Woodward wrote:
> 
> 
>> -----Original Message-----
>> From: lldb-dev <lldb-dev-bounces at lists.llvm.org> On Behalf Of Pavel Labath
>> via lldb-dev
>> Sent: Thursday, February 21, 2019 8:35 AM
>> To: Davide Italiano <dccitaliano at gmail.com>
>> Cc: LLDB <lldb-dev at lists.llvm.org>
>> Subject: [EXT] Re: [lldb-dev] [RFC]The future of pexpect
>>
>> On 21/02/2019 00:03, Davide Italiano wrote:
>>> I found out that there are tests that effectively require
>>> interactivity. Some of the lldb-mi ones are an example.
>>> A common use-case is that of sending SIGTERM in a loop to make sure
>>> `lldb-mi` doesn't crash and handle the signal correctly.
>>>
>>> This functionality is really hard to replicate in lit_as is_.
>>> Any ideas on how we could handle this case?
>>
>> How hard is it to import a new version of pexpect which supports python3 and
>> stuff?
>>
>> I'm not sure how the situation is on darwin, but I'd expect (:P) that most linux
>> systems either already have it installed, or have an easy way to do so. So we
>> may not even be able to get away with just using the system one and skipping
>> tests when it's not present.
>>
>> BTW, for lldb-mi I would actually argue that it should *not* use pexpect :D.
>> Interactivity is one thing, and I'm very much in favour of keeping that ability,
>> but pexpect is not a prerequisite for that. For me, the main advantage of
>> pexpect is that it emulates a real terminal. However, lldb-mi does not need
>> that stuff. It doesn't have any command line editing capabilities or similar. It's
>> expecting to communicate with an IDE over a pipe, and that's it.
>>
>> Given that, it should be fairly easy to rewrite the lldb-mi tests to work on top
>> of the standard python "subprocess" library. While we're doing that, we might
>> actually fix some of the issues that have been bugging everyone in the lldb-mi
>> tests. At least for me, the most annoying thing was that when lldb-mi fails to
>> produce the expected output, the test does not fail immediately, but instead
>> the implementation of self.expect("^whatever") waits until the timeout
>> expires, optimistically hoping that it will find some output that match the
>> pattern.
>>
>> If we change this to something like self.expect_reply("^whatever"), and make
>> the "expect_reply" function smart enough to know that lldb-mi's response
>> should come as a single line, and if the first line doesn't match, it should abort,
>> this problem would be fixed. While we're at it, we could also tune the failure
>> message so that it's more helpful than the current implementation. Plus, that
>> would solve the issue of not being able to run lldb-mi tests on windows.
> 
> This would be OK, I think, as long as "expect_reply" has the option to do a partial match,
> or a regex match. Some of the lldb-mi tests only look for certain parts of the reply.

Yes, except from the difference in treating "messages" independently, 
the function could/should have the same matching capabilities as the 
current one.

I do see an opportunity to improve this to do some kind of 
structure-aware matching (expect_reply("library-loaded", 
target_name="foo.so", loaded_addr=0x47000)). IMO, that would make these 
tests superior even to the current lit tests, but I'm not an lldb-mi 
developer, so I'll probably stop short of doing that. :)


> 
> Also, until Python2 is declared dead and not supported at all by lldb, we should be able
> to run this under 2 or 3.

Yes, of course.