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 PR and make forward progress.
Occasionally bisecting a large set of PR's should still be less bot time
than attempting to build each of them individually.
Blocking the PR's due to target specific and or slow bot failures would be
a different question.
You could probably do this with a linear history, so long as the final tree
is the same as the merge commit, it should still build.
I'm just fond of the idea of trying to prevent bad commits from ever being
merged. Since they sometimes waste everyone's time.

On Fri, 1 Feb 2019 at 04:02, David Greene  wrote:

>  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 system like this is that when changes are going in
> rapidly, the queue grows very large and it takes forever to get your
> change merged.  PR builds are serialized and if a "build" means "make
> sure it builds on all the Buildbots" then it takes a very long time
> indeed.
>
> There are ways to parallelize builds by speculating that PRs will build
> cleanly but it gets pretty complicated quickly.
>
> > But this would be a radical redesign of the LLVM bot system, and would
> > have to wait until we're done with the GitHub migration and can spend
> > a couple of years debating the use of PRs. :-)
>
> Heh.  Fully guaranteeing buildability of a branch is not a trivial task
> and will take a LOT of thought and discussion.
>
>   -David
>
___
lldb-dev mailing list
lldb-dev@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev


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:
> >
> > 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
> > > hoping to get support from GitHub on this?
> > >
> > > We may write this rule in the developer guide, but I fear it'll be
> > > hard to enforce in practice.
> >
> > Again, changes aren't going through git yet, right?  Not until SVN is
> > decommissioned late this year (or early next).  SVN requires a strict
> > linear history so it handles the enforcement for now.
>
> > My personal opinion is that when SVN is decomissioned we should use pull
> > requests, simply because that's what's familiar to the very large
> > development community outside LLVM.  It will lower the bar to entry for
> > new contributors.  This has all sorts of implications we need to discuss
> > of course, but we have some time to do that.
> My personal opinion is an opposite of that one.
>
> *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.
>
> Low bar for entry is good, but not at the cost of raising the bar
> for the existing development community.
> In particular, i'm saying that github's ui/workflow/feature set
> is inferior to that one of phabricator.
>
> Is the low entry bar the only benefit?
> While it is good, it should not be the only factor.
> The contributors will already need to know how to build LLVM,
> write tests, make meaningful changes to the code.
> Additionally having to know how to work with phabricator
> isn't that much to ask for, considering the other prerequisites..
>
> > If we don't use PRs, then we're pretty much on the honor system to
> > disallow merges AFAIK.
> >
> >  -David
> Roman.
>
> > ___
> > cfe-dev mailing list
> > cfe-...@lists.llvm.org
> > https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev
> ___
> LLVM Developers mailing list
> llvm-...@lists.llvm.org
> https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
>
___
lldb-dev mailing list
lldb-dev@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev


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 that's one datapoint from people new to it.

-David
___
lldb-dev mailing list
lldb-dev@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev


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 pexpect on windows will 
be much easier than getting a working interactive command line.

___
lldb-dev mailing list
lldb-dev@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev


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 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
>
___
lldb-dev mailing list
lldb-dev@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev


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 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
___
lldb-dev mailing list
lldb-dev@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/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 could have a command which searches the command history.
> 
> The patch is r351313, if you want to look at it in detail. But, I don't think 
> this one example matters too much, since we will always have some code which 
> deals with the interactivity of the terminal. That will need to be tested 
> somehow.
> 
> Another example: we have a fairly complex piece of code that makes sure our 
> (lldb) prompt comes out in color. How do we write a test for that?

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.

Jim


> ___
> 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


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 the rest can be mocked.



On Thu, Jan 31, 2019 at 10:42 AM Pavel Labath  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 could have a command which searches the command
> > history.
> >
>
> The patch is r351313, if you want to look at it in detail. But, I don't
> think this one example matters too much, since we will always have some
> code which deals with the interactivity of the terminal. That will need
> to be tested somehow.
>
> Another example: we have a fairly complex piece of code that makes sure
> our (lldb) prompt comes out in color. How do we write a test for that?
>
___
lldb-dev mailing list
lldb-dev@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev


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 you want to look at it in detail. But, I don't 
think this one example matters too much, since we will always have some 
code which deals with the interactivity of the terminal. That will need 
to be tested somehow.


Another example: we have a fairly complex piece of code that makes sure 
our (lldb) prompt comes out in color. How do we write a test for that?

___
lldb-dev mailing list
lldb-dev@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev


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 did you have 
to parse to do X, how many lookups did it take to compile an expression, or how 
many memory requests did a task take, things like that.  Those seem to me 
likely to be ore stable.

That said, I'm unclear why any of the benchmark tests would need pexpect to 
function.  The Driver used to have a lot more functionality in it that has 
since been moved into the SB API's.  Maybe there was good reason for doing 
performance testing through the driver but I can't think of any good reason for 
doing that nowadays. 

Jim

> On Jan 31, 2019, at 10:23 AM, Davide Italiano via lldb-dev 
>  wrote:
> 
> 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 pyexpect:
>>> 
>>> testcases/tools/lldb-mi/syntax/TestMiSyntax.py:import pexpect
>>> # 7 (EOF)
>>> testcases/tools/lldb-mi/lldbmi_testcase.py:import pexpect
>>> testcases/tools/lldb-mi/signal/TestMiSignal.py:import pexpect
>>> testcases/tools/lldb-mi/signal/TestMiSignal.py:import pexpect
>>> testcases/lldbtest.py:import pexpect
>>> testcases/driver/batch_mode/TestBatchMode.py:import pexpect
>>> testcases/driver/batch_mode/TestBatchMode.py:import pexpect
>>> testcases/driver/batch_mode/TestBatchMode.py:import pexpect
>>> testcases/driver/batch_mode/TestBatchMode.py:import pexpect
>>> testcases/lldbpexpect.py:import pexpect
>>> testcases/terminal/TestSTTYBeforeAndAfter.py:import pexpect
>>> testcases/darwin_log.py:import pexpect
>>> testcases/macosx/nslog/TestDarwinNSLogOutput.py:import pexpect
>>> testcases/benchmarks/stepping/TestSteppingSpeed.py:import pexpect
>>> testcases/benchmarks/frame_variable/TestFrameVariableResponse.py:
>>>   import pexpect
>>> testcases/benchmarks/turnaround/TestCompileRunToBreakpointTurnaround.py:
>>>import pexpect
>>> testcases/benchmarks/turnaround/TestCompileRunToBreakpointTurnaround.py:
>>>import pexpect
>>> testcases/benchmarks/expression/TestExpressionCmd.py:import pexpect
>>> testcases/benchmarks/expression/TestRepeatedExprs.py:import pexpect
>>> testcases/benchmarks/expression/TestRepeatedExprs.py:import pexpect
>>> testcases/benchmarks/startup/TestStartupDelays.py:import pexpect
>>> testcases/functionalities/command_regex/TestCommandRegex.py:
>>> import pexpect
>>> testcases/functionalities/single-quote-in-filename-to-lldb/TestSingleQuoteInFilename.py:
>>>import pexpect
>>> testcases/functionalities/format/TestFormats.py:import pexpect
>>> 
>>> (I count 14, but there might be something else).
>>> 
>>> I audited all of them and from what I see they’re almost all testing the 
>>> driver.
>>> I had a chat with my coworkers and we agreed it's reasonable to
>>> replace them with lit tests (as they're just running commands).
>>> This would allow us to get rid of an external dependency, which
>>> happened to be cause of trouble in the past.
>>> 
>>> Are there any objections?
>>> 
>>> Thanks,
>>> 
>> 
>> I'm not a fan of pexpect, and if these tests can be converted to lit,
>> then I'm all for it. But I do have a question.
>> 
>> There is a class of tests that cannot be written in the current lit
>> framework, but they can with pexpect. A couple of weeks ago we had a
>> patch fixing a bug where pressing up arrow while searching through the
>> command history caused a crash. In the end a test for this was not
>> included because it was hard for a reason unrelated to pexpect, but
>> without pexpect (or something equivalent) writing a test for this would
>> be impossible.
>> 
> 
> I don't know about this, to be honest. Maybe lit should grow an
> interactive mode somehow to accomodate for this functionality?
> I'm not an expert in how it's implemented so that could be hard to achieve.
> FWIW, I haven't seen anything that really requires interactivity, but
> I have to admit I haven't looked really deeply.
> 
>> What's our story for testing interactive command-line functionalities?
>> The way I see it, if we don't use pexpect, we'll either have to use some
>> other tool which simulates a realistic terminal, or write our own. (We
>> already have one attempt for this in
>> unittests/Editline/EditlineTest.cpp, but this would need more work to be
>> fully functional.)
>> 
>> pl
>> 
>> 
>> PS: Does anyone actually use the benchmark tests? Can we just delete them?
> 
> I don't know. Maybe Jim knows. I personally 

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 better place to put 
effort than something like pexpect.

Jim


> On Jan 31, 2019, at 10:26 AM, Zachary Turner via lldb-dev 
>  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.
> 
> On Thu, Jan 31, 2019 at 10:23 AM Davide Italiano via lldb-dev 
>  wrote:
> 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 pyexpect:
> > >
> > > testcases/tools/lldb-mi/syntax/TestMiSyntax.py:import pexpect
> > >  # 7 (EOF)
> > > testcases/tools/lldb-mi/lldbmi_testcase.py:import pexpect
> > > testcases/tools/lldb-mi/signal/TestMiSignal.py:import pexpect
> > > testcases/tools/lldb-mi/signal/TestMiSignal.py:import pexpect
> > > testcases/lldbtest.py:import pexpect
> > > testcases/driver/batch_mode/TestBatchMode.py:import pexpect
> > > testcases/driver/batch_mode/TestBatchMode.py:import pexpect
> > > testcases/driver/batch_mode/TestBatchMode.py:import pexpect
> > > testcases/driver/batch_mode/TestBatchMode.py:import pexpect
> > > testcases/lldbpexpect.py:import pexpect
> > > testcases/terminal/TestSTTYBeforeAndAfter.py:import pexpect
> > > testcases/darwin_log.py:import pexpect
> > > testcases/macosx/nslog/TestDarwinNSLogOutput.py:import pexpect
> > > testcases/benchmarks/stepping/TestSteppingSpeed.py:import pexpect
> > > testcases/benchmarks/frame_variable/TestFrameVariableResponse.py:
> > >import pexpect
> > > testcases/benchmarks/turnaround/TestCompileRunToBreakpointTurnaround.py:
> > > import pexpect
> > > testcases/benchmarks/turnaround/TestCompileRunToBreakpointTurnaround.py:
> > > import pexpect
> > > testcases/benchmarks/expression/TestExpressionCmd.py:import 
> > > pexpect
> > > testcases/benchmarks/expression/TestRepeatedExprs.py:import 
> > > pexpect
> > > testcases/benchmarks/expression/TestRepeatedExprs.py:import 
> > > pexpect
> > > testcases/benchmarks/startup/TestStartupDelays.py:import pexpect
> > > testcases/functionalities/command_regex/TestCommandRegex.py:
> > > import pexpect
> > > testcases/functionalities/single-quote-in-filename-to-lldb/TestSingleQuoteInFilename.py:
> > > import pexpect
> > > testcases/functionalities/format/TestFormats.py:import pexpect
> > >
> > > (I count 14, but there might be something else).
> > >
> > > I audited all of them and from what I see they’re almost all testing the 
> > > driver.
> > > I had a chat with my coworkers and we agreed it's reasonable to
> > > replace them with lit tests (as they're just running commands).
> > > This would allow us to get rid of an external dependency, which
> > > happened to be cause of trouble in the past.
> > >
> > > Are there any objections?
> > >
> > > Thanks,
> > >
> >
> > I'm not a fan of pexpect, and if these tests can be converted to lit,
> > then I'm all for it. But I do have a question.
> >
> > There is a class of tests that cannot be written in the current lit
> > framework, but they can with pexpect. A couple of weeks ago we had a
> > patch fixing a bug where pressing up arrow while searching through the
> > command history caused a crash. In the end a test for this was not
> > included because it was hard for a reason unrelated to pexpect, but
> > without pexpect (or something equivalent) writing a test for this would
> > be impossible.
> >
> 
> I don't know about this, to be honest. Maybe lit should grow an
> interactive mode somehow to accomodate for this functionality?
> I'm not an expert in how it's implemented so that could be hard to achieve.
> FWIW, I haven't seen anything that really requires interactivity, but
> I have to admit I haven't looked really deeply.
> 
> > What's our story for testing interactive command-line functionalities?
> > The way I see it, if we don't use pexpect, we'll either have to use some
> > other tool which simulates a realistic terminal, or write our own. (We
> > already have one attempt for this in
> > unittests/Editline/EditlineTest.cpp, but this would need more work to be
> > fully functional.)
> >
> > pl
> >
> >
> > PS: Does anyone actually use the benchmark tests? Can we just delete them?
> 
> I don't know. Maybe Jim knows. I personally don't use them.
> 

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 <
lldb-dev@lists.llvm.org> wrote:

> 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 pyexpect:
> > >
> > > testcases/tools/lldb-mi/syntax/TestMiSyntax.py:import pexpect
> > >  # 7 (EOF)
> > > testcases/tools/lldb-mi/lldbmi_testcase.py:import pexpect
> > > testcases/tools/lldb-mi/signal/TestMiSignal.py:import pexpect
> > > testcases/tools/lldb-mi/signal/TestMiSignal.py:import pexpect
> > > testcases/lldbtest.py:import pexpect
> > > testcases/driver/batch_mode/TestBatchMode.py:import pexpect
> > > testcases/driver/batch_mode/TestBatchMode.py:import pexpect
> > > testcases/driver/batch_mode/TestBatchMode.py:import pexpect
> > > testcases/driver/batch_mode/TestBatchMode.py:import pexpect
> > > testcases/lldbpexpect.py:import pexpect
> > > testcases/terminal/TestSTTYBeforeAndAfter.py:import pexpect
> > > testcases/darwin_log.py:import pexpect
> > > testcases/macosx/nslog/TestDarwinNSLogOutput.py:import pexpect
> > > testcases/benchmarks/stepping/TestSteppingSpeed.py:import
> pexpect
> > > testcases/benchmarks/frame_variable/TestFrameVariableResponse.py:
> > >import pexpect
> > >
> testcases/benchmarks/turnaround/TestCompileRunToBreakpointTurnaround.py:
> > > import pexpect
> > >
> testcases/benchmarks/turnaround/TestCompileRunToBreakpointTurnaround.py:
> > > import pexpect
> > > testcases/benchmarks/expression/TestExpressionCmd.py:import
> pexpect
> > > testcases/benchmarks/expression/TestRepeatedExprs.py:import
> pexpect
> > > testcases/benchmarks/expression/TestRepeatedExprs.py:import
> pexpect
> > > testcases/benchmarks/startup/TestStartupDelays.py:import
> pexpect
> > > testcases/functionalities/command_regex/TestCommandRegex.py:
> > > import pexpect
> > >
> testcases/functionalities/single-quote-in-filename-to-lldb/TestSingleQuoteInFilename.py:
> > > import pexpect
> > > testcases/functionalities/format/TestFormats.py:import pexpect
> > >
> > > (I count 14, but there might be something else).
> > >
> > > I audited all of them and from what I see they’re almost all testing
> the driver.
> > > I had a chat with my coworkers and we agreed it's reasonable to
> > > replace them with lit tests (as they're just running commands).
> > > This would allow us to get rid of an external dependency, which
> > > happened to be cause of trouble in the past.
> > >
> > > Are there any objections?
> > >
> > > Thanks,
> > >
> >
> > I'm not a fan of pexpect, and if these tests can be converted to lit,
> > then I'm all for it. But I do have a question.
> >
> > There is a class of tests that cannot be written in the current lit
> > framework, but they can with pexpect. A couple of weeks ago we had a
> > patch fixing a bug where pressing up arrow while searching through the
> > command history caused a crash. In the end a test for this was not
> > included because it was hard for a reason unrelated to pexpect, but
> > without pexpect (or something equivalent) writing a test for this would
> > be impossible.
> >
>
> I don't know about this, to be honest. Maybe lit should grow an
> interactive mode somehow to accomodate for this functionality?
> I'm not an expert in how it's implemented so that could be hard to achieve.
> FWIW, I haven't seen anything that really requires interactivity, but
> I have to admit I haven't looked really deeply.
>
> > What's our story for testing interactive command-line functionalities?
> > The way I see it, if we don't use pexpect, we'll either have to use some
> > other tool which simulates a realistic terminal, or write our own. (We
> > already have one attempt for this in
> > unittests/Editline/EditlineTest.cpp, but this would need more work to be
> > fully functional.)
> >
> > pl
> >
> >
> > PS: Does anyone actually use the benchmark tests? Can we just delete
> them?
>
> I don't know. Maybe Jim knows. I personally don't use them.
> ___
> 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


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 pyexpect:
> >
> > testcases/tools/lldb-mi/syntax/TestMiSyntax.py:import pexpect
> >  # 7 (EOF)
> > testcases/tools/lldb-mi/lldbmi_testcase.py:import pexpect
> > testcases/tools/lldb-mi/signal/TestMiSignal.py:import pexpect
> > testcases/tools/lldb-mi/signal/TestMiSignal.py:import pexpect
> > testcases/lldbtest.py:import pexpect
> > testcases/driver/batch_mode/TestBatchMode.py:import pexpect
> > testcases/driver/batch_mode/TestBatchMode.py:import pexpect
> > testcases/driver/batch_mode/TestBatchMode.py:import pexpect
> > testcases/driver/batch_mode/TestBatchMode.py:import pexpect
> > testcases/lldbpexpect.py:import pexpect
> > testcases/terminal/TestSTTYBeforeAndAfter.py:import pexpect
> > testcases/darwin_log.py:import pexpect
> > testcases/macosx/nslog/TestDarwinNSLogOutput.py:import pexpect
> > testcases/benchmarks/stepping/TestSteppingSpeed.py:import pexpect
> > testcases/benchmarks/frame_variable/TestFrameVariableResponse.py:
> >import pexpect
> > testcases/benchmarks/turnaround/TestCompileRunToBreakpointTurnaround.py:
> > import pexpect
> > testcases/benchmarks/turnaround/TestCompileRunToBreakpointTurnaround.py:
> > import pexpect
> > testcases/benchmarks/expression/TestExpressionCmd.py:import pexpect
> > testcases/benchmarks/expression/TestRepeatedExprs.py:import pexpect
> > testcases/benchmarks/expression/TestRepeatedExprs.py:import pexpect
> > testcases/benchmarks/startup/TestStartupDelays.py:import pexpect
> > testcases/functionalities/command_regex/TestCommandRegex.py:
> > import pexpect
> > testcases/functionalities/single-quote-in-filename-to-lldb/TestSingleQuoteInFilename.py:
> > import pexpect
> > testcases/functionalities/format/TestFormats.py:import pexpect
> >
> > (I count 14, but there might be something else).
> >
> > I audited all of them and from what I see they’re almost all testing the 
> > driver.
> > I had a chat with my coworkers and we agreed it's reasonable to
> > replace them with lit tests (as they're just running commands).
> > This would allow us to get rid of an external dependency, which
> > happened to be cause of trouble in the past.
> >
> > Are there any objections?
> >
> > Thanks,
> >
>
> I'm not a fan of pexpect, and if these tests can be converted to lit,
> then I'm all for it. But I do have a question.
>
> There is a class of tests that cannot be written in the current lit
> framework, but they can with pexpect. A couple of weeks ago we had a
> patch fixing a bug where pressing up arrow while searching through the
> command history caused a crash. In the end a test for this was not
> included because it was hard for a reason unrelated to pexpect, but
> without pexpect (or something equivalent) writing a test for this would
> be impossible.
>

I don't know about this, to be honest. Maybe lit should grow an
interactive mode somehow to accomodate for this functionality?
I'm not an expert in how it's implemented so that could be hard to achieve.
FWIW, I haven't seen anything that really requires interactivity, but
I have to admit I haven't looked really deeply.

> What's our story for testing interactive command-line functionalities?
> The way I see it, if we don't use pexpect, we'll either have to use some
> other tool which simulates a realistic terminal, or write our own. (We
> already have one attempt for this in
> unittests/Editline/EditlineTest.cpp, but this would need more work to be
> fully functional.)
>
> pl
>
>
> PS: Does anyone actually use the benchmark tests? Can we just delete them?

I don't know. Maybe Jim knows. I personally don't use them.
___
lldb-dev mailing list
lldb-dev@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev


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 pexpect
 # 7 (EOF)
testcases/tools/lldb-mi/lldbmi_testcase.py:import pexpect
testcases/tools/lldb-mi/signal/TestMiSignal.py:import pexpect
testcases/tools/lldb-mi/signal/TestMiSignal.py:import pexpect
testcases/lldbtest.py:import pexpect
testcases/driver/batch_mode/TestBatchMode.py:import pexpect
testcases/driver/batch_mode/TestBatchMode.py:import pexpect
testcases/driver/batch_mode/TestBatchMode.py:import pexpect
testcases/driver/batch_mode/TestBatchMode.py:import pexpect
testcases/lldbpexpect.py:import pexpect
testcases/terminal/TestSTTYBeforeAndAfter.py:import pexpect
testcases/darwin_log.py:import pexpect
testcases/macosx/nslog/TestDarwinNSLogOutput.py:import pexpect
testcases/benchmarks/stepping/TestSteppingSpeed.py:import pexpect
testcases/benchmarks/frame_variable/TestFrameVariableResponse.py:
   import pexpect
testcases/benchmarks/turnaround/TestCompileRunToBreakpointTurnaround.py:
import pexpect
testcases/benchmarks/turnaround/TestCompileRunToBreakpointTurnaround.py:
import pexpect
testcases/benchmarks/expression/TestExpressionCmd.py:import pexpect
testcases/benchmarks/expression/TestRepeatedExprs.py:import pexpect
testcases/benchmarks/expression/TestRepeatedExprs.py:import pexpect
testcases/benchmarks/startup/TestStartupDelays.py:import pexpect
testcases/functionalities/command_regex/TestCommandRegex.py:
import pexpect
testcases/functionalities/single-quote-in-filename-to-lldb/TestSingleQuoteInFilename.py:
import pexpect
testcases/functionalities/format/TestFormats.py:import pexpect

(I count 14, but there might be something else).

I audited all of them and from what I see they’re almost all testing the driver.
I had a chat with my coworkers and we agreed it's reasonable to
replace them with lit tests (as they're just running commands).
This would allow us to get rid of an external dependency, which
happened to be cause of trouble in the past.

Are there any objections?

Thanks,



I'm not a fan of pexpect, and if these tests can be converted to lit, 
then I'm all for it. But I do have a question.


There is a class of tests that cannot be written in the current lit 
framework, but they can with pexpect. A couple of weeks ago we had a 
patch fixing a bug where pressing up arrow while searching through the 
command history caused a crash. In the end a test for this was not 
included because it was hard for a reason unrelated to pexpect, but 
without pexpect (or something equivalent) writing a test for this would 
be impossible.


What's our story for testing interactive command-line functionalities? 
The way I see it, if we don't use pexpect, we'll either have to use some 
other tool which simulates a realistic terminal, or write our own. (We 
already have one attempt for this in 
unittests/Editline/EditlineTest.cpp, but this would need more work to be 
fully functional.)


pl


PS: Does anyone actually use the benchmark tests? Can we just delete them?
___
lldb-dev mailing list
lldb-dev@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev


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
>>  | \
>>  \  `---.
>>   `. \
>> \|
>> ... ->DL2->DL1/DC2 <- zip/master
>> /
>> ... ->DC2--'
>> 
>
> I still do not understand how that actually works technically, but maybe
> it does if you say so. But I also believe that "git log" etc on DL1/DC2
> will show that commit UL0 is part of my tree (which it isn't?). This will
> be really confusing when looking back at the history when debugging etc.

Yes, it will look like UL0 is part of your tree.  The edge from
UL1->DL1, which looks redundant, is actually there as a visual reminder
of the state of the llvm tree.

Unfortunately, git just doesn't have a good way to express the kind of
history we're creating here.  Since redundant edges are oddball in git
and git itself never creates them, I thought it would be strange enough
to stick out as a reminder.

If there's some other way to express this (Git notes?  Commit message?)
that would be more helpful, I'd be happy to consider it.

 -David
___
lldb-dev mailing list
lldb-dev@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev


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 system like this is that when changes are going in
rapidly, the queue grows very large and it takes forever to get your
change merged.  PR builds are serialized and if a "build" means "make
sure it builds on all the Buildbots" then it takes a very long time
indeed.

There are ways to parallelize builds by speculating that PRs will build
cleanly but it gets pretty complicated quickly.

> But this would be a radical redesign of the LLVM bot system, and would
> have to wait until we're done with the GitHub migration and can spend
> a couple of years debating the use of PRs. :-)

Heh.  Fully guaranteeing buildability of a branch is not a trivial task
and will take a LOT of thought and discussion.

  -David
___
lldb-dev mailing list
lldb-dev@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev


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
> hoping to get support from GitHub on this?
>
> We may write this rule in the developer guide, but I fear it'll be
> hard to enforce in practice.

Again, changes aren't going through git yet, right?  Not until SVN is
decommissioned late this year (or early next).  SVN requires a strict
linear history so it handles the enforcement for now.

My personal opinion is that when SVN is decomissioned we should use pull
requests, simply because that's what's familiar to the very large
development community outside LLVM.  It will lower the bar to entry for
new contributors.  This has all sorts of implications we need to discuss
of course, but we have some time to do that.

If we don't use PRs, then we're pretty much on the honor system to
disallow merges AFAIK.

 -David
___
lldb-dev mailing list
lldb-dev@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev