On Mon, Feb 25, 2019 at 1:35 PM Adrian Prantl <apra...@apple.com> wrote:
>
>
>
> > On Feb 25, 2019, at 1:15 PM, Davide Italiano <dccitali...@gmail.com> wrote:
> >
> > On Fri, Feb 22, 2019 at 6:32 AM Pavel Labath <pa...@labath.sk> wrote:
> >>
> >> On 21/02/2019 19:48, Ted Woodward wrote:
> >>>
> >>>
> >>>> -----Original Message-----
> >>>> From: lldb-dev <lldb-dev-boun...@lists.llvm.org> On Behalf Of Pavel
> >>>> Labath
> >>>> via lldb-dev
> >>>> Sent: Thursday, February 21, 2019 8:35 AM
> >>>> To: Davide Italiano <dccitali...@gmail.com>
> >>>> Cc: LLDB <lldb-dev@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?
>
> What you are saying is that we would write the tests as Python tests in a way
> similar to how lldbtest.expect() look in the dotest.py tests, banking on
> synchronous mode taking care of all the synchronization? Are you thinking of
> doing this for all the remaining tests or only the ones where a command input
> depends on the result of a previous command?
>
I'm thinking to do this for all the remaining tests. Do you have any
concerns about this? (I'm aware your GSoC student introduced the `lit
lldb-mi` tests for a reason, I just don't know exactly what the reason
was).
_______________________________________________
lldb-dev mailing list
lldb-dev@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
