On Thu, Jan 31, 2019 at 11:40 AM Pavel Labath <pa...@labath.sk> wrote:
>
> On 31/01/2019 19:51, Zachary Turner wrote:
> > FileCheck the ansi escape codes seems like one possibility.
> >
> > In general I think you don't actually need to test true interactivity,
> > because the odds of there being a problem in the 2-3 lines of code that
> > convert the keyboard press to something else in LLDB are very unlikely
> > to be problematic, and the rest can be mocked.
>
>
> On 31/01/2019 20:02, Jim Ingham wrote:
> > All the traffic back and forth with the terminal happens in the
> > IOHandlerEditLine. We should be able to get our hands on the Debuggers
> > IOHandler and feed characters directly to it, and read the results. So we
> > should be able to write this kind of test by driving the debugger to
> > whatever state you need with SB API and then just run one command and get
> > the output string directly from the IOHandler. We should be able to then
> > scan that output for color codes. I don't think we need an external
> > process inspection tool to do this sort of thing.
> >
>
>
> Libedit expect to work with a real terminal, so to test the code that
> interacts with libedit (and there's more than 3 lines of that), you'll
> need something that can create a pty, and read and write characters to
> it, regardless of whether you drive the test through FileCheck or SB API.
>
> "creating a pty, and reading and writing to it" is pretty much the
> definition of pexpect.
>
> I am not saying either of this approaches can't be made to work, but I
> am not sure who is going to do it. I fear that we are shooting ourselves
> in the foot banning pexpect and then pushing patches without tests
> because "it's hard".
>
> Just for fun, I tried to write a test to check the coloring of the
> prompt via pexpect. It was _literally_ three lines long:
>
> def test_colored_prompt_comes_out_right(self):
> child = pexpect.spawn(lldbtest_config.lldbExec)
> child.expect_exact("(lldb) \x1b[1G\x1b[2m(lldb) \x1b[22m\x1b[8G")
>
>
> BTW: I am not proposing we spend heroic efforts trying to port pexpect
> 2.4 to python3. But I would consider using a newer version of pexpect to
> write tests ***where it makes sense to do so***. At least until someone
> comes up with a better (and not vapourware) alternative...
>
> pl
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?
Thanks,
--
Davide
_______________________________________________
lldb-dev mailing list
lldb-dev@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
