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

[Pavel Labath via lldb-dev]

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.

Anyway, that's what I'd do. I was actually planning to look into that 
soon, but then I roped myself into writing a yaml (de)serialization tool 
for minidumps, so I have no idea when I will get back to that. I hope 
some of this is helpful nonetheless.

cheers,
pavel