[Lldb-commits] [lldb] r222163 - Complete rewrite of interactive editing support for single- and multi-line input.

[Kate Stone]

That seems like a perfectly reasonable solution for now.  There was indeed a review sent out for this change, and there was quite a bit of community involvement in making sure everything was in fine shape for Linux as well as some speculative support for Windows editline implementations that don’t support the wide character variants.  I’m glad the fix on your end was relatively straightforward.

Kate Stone k8stone at apple.com <mailto:k8stone at apple.com>
 Xcode Runtime Analysis Tools

> On Nov 17, 2014, at 1:54 PM, Zachary Turner <zturner at google.com> wrote:
> 
> Fixed this by disabling compiltion of Editline on Windows in r222177.  Editline was already being disabled on Windows anyway due to existing issues, it was just being disabled at runtime instead of compile time.  I looked into fixing the actual issue, and it was non-trivial.  I would have pushed for a revert if this was an actual regression (i.e. Editline used to work on Windows, and now didn't), but since it was already disabled to begin with, I just turned it off.
> 
> On Mon Nov 17 2014 at 11:58:24 AM Zachary Turner <zturner at google.com <mailto:zturner at google.com>> wrote:
> This also doesn't compile on Windows due to the use of select() on a file descriptor.  Was a review ever sent out to lldb-commits for this?  I follow lldb-commits somewhat closely and I don't recall ever seeing a public review go out for this.  I do recall some discussion about this patch some time ago, and it was state that a review would go out so we would have time to work through any issues before submitting the patch, but then a review never happened.
> 
> I will spend some time looking into how this affects Windows later and how it can be fixed, but if it looks like this is not going to be trivial to fix, then maybe we need to revert until the issues can be worked out?
> 
> On Mon Nov 17 2014 at 11:48:58 AM Ed Maste <emaste at freebsd.org <mailto:emaste at freebsd.org>> wrote:
> On 17 November 2014 14:07, Kate Stone <katherine.stone at apple.com <mailto:katherine.stone at apple.com>> wrote:
> > Author: kate
> > Date: Mon Nov 17 13:06:59 2014
> > New Revision: 222163
> >
> > URL: http://llvm.org/viewvc/llvm-project?rev=222163&view=rev <http://llvm.org/viewvc/llvm-project?rev=222163&view=rev>
> > Log:
> > Complete rewrite of interactive editing support for single- and multi-line input.
> 
> FYI, two new test failures appeared on FreeBSD after this change. I'm
> curious if the Linux guys see similar behaviour.
> 
> 
> FAIL: LLDB (/usr/bin/clang-x86_64) :: test_with_dwarf
> (TestGlobalVariables.GlobalVariablesTestCase)
> ======================================================================
> FAIL: test_with_dwarf (TestGlobalVariables.GlobalVariablesTestCase)
>    Test 'frame variable --scope --no-args' which omits args and shows scopes.
> ----------------------------------------------------------------------
> Traceback (most recent call last):
>   File "/tank/emaste/src/llvm/tools/lldb/test/lldbtest.py", line 382, in wrapper
>     return func(self, *args, **kwargs)
>   File "/tank/emaste/src/llvm/tools/lldb/test/lang/c/global_variables/TestGlobalVariables.py",
> line 24, in test_with_dwarf
>     self.global_variables()
>   File "/tank/emaste/src/llvm/tools/lldb/test/lang/c/global_variables/TestGlobalVariables.py",
> line 60, in global_variables
>     'stop reason = breakpoint'])
>   File "/tank/emaste/src/llvm/tools/lldb/test/lldbtest.py", line 1886, in expect
>     self.runCmd(str, msg=msg, trace = (True if trace else False),
> check = not error, inHistory=inHistory)
>   File "/tank/emaste/src/llvm/tools/lldb/test/lldbtest.py", line 1812, in runCmd
>     msg if msg else CMD_MSG(cmd))
> AssertionError: False is not True : Process should be stopped due to breakpoint
> Config=x86_64-/usr/bin/clang
> ----------------------------------------------------------------------
> Ran 2 tests in 0.200s
> 
> FAILED (failures=1, skipped=1)
> 
> 
> FAIL: LLDB (/usr/bin/clang-x86_64) :: test_command_regex
> (TestCommandRegex.CommandRegexTestCase)
> ======================================================================
> ERROR: test_command_regex (TestCommandRegex.CommandRegexTestCase)
>    Test a simple scenario of 'command regex' invocation and subsequent use.
> ----------------------------------------------------------------------
> Traceback (most recent call last):
>   File "/tank/emaste/src/llvm/tools/lldb/test/functionalities/command_regex/TestCommandRegex.py",
> line 38, in test_command_regex
>     child.expect('The following is a list of built-in, permanent
> debugger commands:')
>   File "/tank/emaste/src/llvm/tools/lldb/test/pexpect-2.4/pexpect.py",
> line 1316, in expect
>     return self.expect_list(compiled_pattern_list, timeout, searchwindowsize)
>   File "/tank/emaste/src/llvm/tools/lldb/test/pexpect-2.4/pexpect.py",
> line 1330, in expect_list
>     return self.expect_loop(searcher_re(pattern_list), timeout,
> searchwindowsize)
>   File "/tank/emaste/src/llvm/tools/lldb/test/pexpect-2.4/pexpect.py",
> line 1414, in expect_loop
>     raise TIMEOUT (str(e) + '\n' + str(self))
> TIMEOUT: Timeout exceeded in read_nonblocking().
> _______________________________________________
> lldb-commits mailing list
> lldb-commits at cs.uiuc.edu <mailto:lldb-commits at cs.uiuc.edu>
> http://lists.cs.uiuc.edu/mailman/listinfo/lldb-commits <http://lists.cs.uiuc.edu/mailman/listinfo/lldb-commits>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/lldb-commits/attachments/20141117/25e45bb8/attachment.html>