Re: [lldb-dev] [RFC]The future of pexpect

2019-01-31 Thread Jim Ingham via lldb-dev
Even if it was the keyboard handler, lldb feeds characters to edit line through the IO Handler, so it should be possible to emulate the up arrow as well. If there are reasons why that's not feasible, we should be able to make it work. This seems a tractable problem to me, and to me seems a

Re: [lldb-dev] [RFC]The future of pexpect

2019-01-31 Thread Zachary Turner via lldb-dev
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

Re: [lldb-dev] [RFC]The future of pexpect

2019-01-31 Thread Pavel Labath via lldb-dev
On 31/01/2019 02:32, Davide Italiano via lldb-dev wrote: As you probably know (I didn’t), lldb embeds its own version of `pexpect-2.4`, which doesn’t support python3. This is the (relatively short) list of tests relying on pyexpect: testcases/tools/lldb-mi/syntax/TestMiSyntax.py:import

Re: [lldb-dev] [RFC]The future of pexpect

2019-01-31 Thread Davide Italiano via lldb-dev
On Thu, Jan 31, 2019 at 10:09 AM Pavel Labath wrote: > > On 31/01/2019 02:32, Davide Italiano via lldb-dev wrote: > > As you probably know (I didn’t), lldb embeds its own version of > > `pexpect-2.4`, which doesn’t support python3. > > This is the (relatively short) list of tests relying on

Re: [lldb-dev] [RFC]The future of pexpect

2019-01-31 Thread Pavel Labath via lldb-dev
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

Re: [lldb-dev] [RFC]The future of pexpect

2019-01-31 Thread Zachary Turner via lldb-dev
Was the test failing specifically in the keyboard handler for up arrow, or was it failing in the command history searching code? Because if it's the latter, then we could have a command which searches the command history. On Thu, Jan 31, 2019 at 10:23 AM Davide Italiano via lldb-dev <

Re: [lldb-dev] [RFC]The future of pexpect

2019-01-31 Thread Jim Ingham via lldb-dev
> On Jan 31, 2019, at 10:42 AM, Pavel Labath via lldb-dev > wrote: > > On 31/01/2019 19:26, Zachary Turner wrote: >> Was the test failing specifically in the keyboard handler for up arrow, or >> was it failing in the command history searching code? Because if it's the >> latter, then we

Re: [lldb-dev] [RFC]The future of pexpect

2019-01-31 Thread Zachary Turner via lldb-dev
It's worth mentioning that pexpect is basically unusable on Windows, so there's still that. On Thu, Jan 31, 2019 at 11:40 AM Pavel Labath 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

Re: [lldb-dev] [RFC]The future of pexpect

2019-01-31 Thread Pavel Labath via lldb-dev
On 31/01/2019 20:52, Zachary Turner wrote: It's worth mentioning that pexpect is basically unusable on Windows, so there's still that. Our interactive command line is basically unusable on windows, so there isn't anything to test anyway. I expect (pun intended) that getting a working

Re: [lldb-dev] [RFC]The future of pexpect

2019-01-31 Thread Jim Ingham via lldb-dev
I don't think anybody uses these tests. They are all time based benchmarks, and in the end there was just too much variability for them to be really useful. We really need to do more work tracking performance, but I think a better approach is to focus on how much work we do (how many DIE's

Re: [lldb-dev] [RFC]The future of pexpect

2019-01-31 Thread Pavel Labath via lldb-dev
On 31/01/2019 19:26, Zachary Turner wrote: Was the test failing specifically in the keyboard handler for up arrow, or was it failing in the command history searching code?  Because if it's the latter, then we could have a command which searches the command history. The patch is r351313, if

Re: [lldb-dev] [cfe-dev] [llvm-dev] [Github] RFC: linear history vs merge commits

2019-01-31 Thread David Greene via lldb-dev
Roman Lebedev writes: > *Does* LLVM want to switch from phabricator to github pr's? > I personally don't recall previous discussions. > Personally, i hope not, i hope phabricator should/will stay. I find Phab pretty unintuitive. I just started using it in earnest about four months ago, so

Re: [lldb-dev] [llvm-dev] [cfe-dev] [Github] RFC: linear history vs merge commits

2019-01-31 Thread Jeremy Lakeman via lldb-dev
https://help.github.com/articles/checking-out-pull-requests-locally/ Script a bot to scrape the patches and post to phabricator? On Fri, 1 Feb 2019 at 04:22, Roman Lebedev via llvm-dev < llvm-...@lists.llvm.org> wrote: > On Thu, Jan 31, 2019 at 8:29 PM David Greene via cfe-dev > wrote: > > > >

Re: [lldb-dev] [cfe-dev] [llvm-dev] [Github] RFC: linear history vs merge commits

2019-01-31 Thread Jeremy Lakeman via lldb-dev
I realise that llvm trunk can move fairly quickly. So my original, but brief, suggestion was to merge the current set of approved patches together rather than attempting them one at a time. Build on a set of fast smoke test bots. If something breaks, it should be possible to bisect it to reject a

Re: [lldb-dev] [cfe-dev] [llvm-dev] [Github] RFC: linear history vs merge commits

2019-01-31 Thread David Greene via lldb-dev
Mehdi AMINI writes: > What is the practical plan to enforce the lack of merges? When we > looked into this GitHub would not support this unless also forcing > every change to go through a pull request (i.e. no pre-receive hooks > on direct push to master were possible). Did this change? Are we >

Re: [lldb-dev] [cfe-dev] [llvm-dev] [Github] RFC: linear history vs merge commits

2019-01-31 Thread David Greene via lldb-dev
writes: > Systems that I've seen will funnel all submitted PRs into a single queue > which *does* guarantee that the trial builds are against HEAD and there > are no "later commits" that can screw it up. If the trial build passes, > the PR goes in and becomes the new HEAD. The downside of a

Re: [lldb-dev] [monorepo] Much improved downstream zipping tool available

2019-01-31 Thread David Greene via lldb-dev
Björn Pettersson A writes: >> Ok, in that case I would expect the resulting history to look like >> this: >> >> UL4->UC2->UL3->UL2->UL1->UL0->UC1 <- monorepo/master >> | \ >> \ `---. >>