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

[Zachary Turner]

Can you link me to the Phabricator issue?  I vaguely recall commenting on
it once, but it must not have been CC'ed to the list or something, because
I've never seen it come across in a public email to the list?

On Mon Nov 17 2014 at 2:22:41 PM Kate Stone <katherine_stone at apple.com>
wrote:

> 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
>  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>
> 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> wrote:
>>
>>> On 17 November 2014 14:07, Kate Stone <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
>>> > 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_variabl
>>> es/TestGlobalVariables.py",
>>> line 24, in test_with_dwarf
>>>     self.global_variables()
>>>   File "/tank/emaste/src/llvm/tools/lldb/test/lang/c/global_variabl
>>> es/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/comma
>>> nd_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
>>> 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/ee1638fd/attachment.html>