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