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

[Pavel Labath via lldb-dev]

On 25/02/2019 22:15, Davide Italiano wrote:
> On Fri, Feb 22, 2019 at 6:32 AM Pavel Labath <pavel at labath.sk> wrote:
>>
>> 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.
>>>>
> 
> Pavel, I think yours is a really nice idea.
> I'm no python expert, but I found out making the conversion is
> relatively simple.
> I propose a proof-of-concept API and implementation here:
> 
> https://gist.github.com/dcci/94a4936a227d9c7627b91ae9575b7b68
> 
> Comments appreciated! Once we agree on how this should look like, I do
> recommend to have a new lldbMITest base class and incrementally start
> moving the tests to it.
> Once we're done, we can delete the old class.
> 
> Does this sound reasonable?
> 
> --
> Davide
> 

Sounds great. Let's ship it. :)

pl