> -----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.
>
> 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.
Also, until Python2 is declared dead and not supported at all by lldb, we
should be able
to run this under 2 or 3.
> 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
> _______________________________________________
> lldb-dev mailing list
> lldb-dev@lists.llvm.org
> https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
_______________________________________________
lldb-dev mailing list
lldb-dev@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
