Re: [lldb-dev] [RFC]The future of pexpect
This would be great. All of these tests have always been disabled on Windows so converting them to lit tests would increase test coverage there as well On Wed, Jan 30, 2019 at 6:00 PM Alex Langford via lldb-dev < lldb-dev@lists.llvm.org> wrote: > +1 > > Thanks for bringing this up. I'd like to see this happen! > > - Alex > > On 1/30/19, 5:33 PM, "lldb-dev on behalf of 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, > > -- > Davide > ___ > lldb-dev mailing list > lldb-dev@lists.llvm.org > > https://urldefense.proofpoint.com/v2/url?u=https-3A__lists.llvm.org_cgi-2Dbin_mailman_listinfo_lldb-2Ddev=DwIGaQ=5VD0RTtNlTh3ycd41b3MUw=plcBe-Lvb3GcVnji0z26DNJmyn6uNsBq7AW-IQ7KAQQ=oo0_7ONGQhEkwtwF6DG8I6sVC2lUR-vlmka8pm4v1k0=zp1B92i8MPZxGtbFYUADj5J4GqHwpC1-g_x3fIN1hq0= > > > ___ > 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
+1 Thanks for bringing this up. I'd like to see this happen! - Alex On 1/30/19, 5:33 PM, "lldb-dev on behalf of 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, -- Davide ___ lldb-dev mailing list lldb-dev@lists.llvm.org https://urldefense.proofpoint.com/v2/url?u=https-3A__lists.llvm.org_cgi-2Dbin_mailman_listinfo_lldb-2Ddev=DwIGaQ=5VD0RTtNlTh3ycd41b3MUw=plcBe-Lvb3GcVnji0z26DNJmyn6uNsBq7AW-IQ7KAQQ=oo0_7ONGQhEkwtwF6DG8I6sVC2lUR-vlmka8pm4v1k0=zp1B92i8MPZxGtbFYUADj5J4GqHwpC1-g_x3fIN1hq0= ___ lldb-dev mailing list lldb-dev@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
[lldb-dev] [RFC]The future of pexpect
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, -- Davide ___ 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
> -Original Message- > From: cfe-dev [mailto:cfe-dev-boun...@lists.llvm.org] On Behalf Of David > Greene via cfe-dev > Sent: Wednesday, January 30, 2019 3:52 PM > To: Jeremy Lakeman > Cc: llvm-dev; LLDB Dev; cfe-dev; openmp-dev (openmp-...@lists.llvm.org) > Subject: Re: [cfe-dev] [llvm-dev] [Github] RFC: linear history vs merge > commits > > Jeremy Lakeman via llvm-dev writes: > > > 4. Each reviewed bug / feature must be rebased onto the current "known > > good" commit, merged into a "probably good" commit, tested by build > > bots, and only then pushed to trunk. Keeping trunk's history more > > usable, with most bad patches reworked and resubmitted instead of > > reverted. > > If you mean having a submitted PR trigger builds and only allow merging > if all builds pass, that may be doable. Of course by the time it's > merged it will be against some later commit (so it should be rebased) > and there's no guarantee it will build against *that* commit. But it > will tend to filter out most problems. 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. By the time a PR reaches the front of the build queue, it might not apply cleanly, in which case it gets bounced just like a failed build would. 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. :-) --paulr ___ 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
Björn Pettersson A writes: > In llvm (split) we have: > > UL4->UL3->UL2->UL1->UL0 >\ > ...->DL2->DL1 > > In clang (split) we have: > > UC4->UC3->UC2->UC1->UC0 >\ > ...->DC2->DC1 > > > DL1 is a commit that updates the clang submodule to DC1 (and in this > scenario at the same time merges UL1 and DL2 in llvm). 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--' As a submodule update, DC1 is "inlined" into DL1 and its commit message is appended to that of DL1. I'm presuming here that llvm never updated the clang submodule to DC2, so it remains an independent commit. The inlining is done assuming that submodule updates represent a single logical change. Submodule updates are assumed to be related to whatever changes happen in the umbrella so they all get smushed together into one commit. The edge UC1->DL1 represents the use of UC1 tree for every project *except* llvm, because clang was a submodule of llvm (and updated to DC1 which merged UC1) and no other project was a submodule in llvm. DL1 still has the llvm tree from UL1 plus any local changes you may have made. Admittedly, this is tricky to understand. Believe me, there were a lot of headaches involved trying to figure out what the right thing to do is. This is my best stab at that. I don't think I have a test that creates this kind of graph. It would be interesting to see if it works. :) At the moment I'm busy with other things. Give it a try and see if it does what you expect. > How does git know that it should follow the parent relation from > DL1 to UL1 for the llvm subdir, and not the UL0->UC1->DC1->DL1 > path? I mean, if I check out commit DC1 I will see the contribution > from UL0 in the llvm subdir, and DL1 includes the changes from DC1. With the history above this is no longer an issue since you can't check out DC1 as such. It's related to the llvm tree in DL1. Let's say we have a commit DC3 and commit DL3 updated llvm's clang submodule to DC3. Commit DC4 was never referenced in a submodule update. The graph should then look like this: UL4->UC2->UL3->UL2->UL1->UL0->UC1 <- monorepo/master | \ \ `---. `. \ \| ... ->DL3/DC3->DL2->DL1/DC1 <- zip/master /\ / ... ->DC4--' `--->DC2' DC3 is related to DL3 so it got inlined. DC2 has an llvm tree based on DL3. Hopefully, this is now clear as mud. :) -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
On Wed, Jan 30, 2019 at 12:42 PM David Greene via cfe-dev wrote: > > Bruce Hoult via llvm-dev writes: > > > How about: > > > > Require a rebase, followed by git merge --no-ff > > > > This creates a linear history, but with extra null merge commits > > delimiting each related series of patches. > > > > I believe it is compatible with bisect. > > > > https://linuxhint.com/git_merge_noff_option/ > > We've done both and I personally prefer the strict linear history by a > lot. It's just much easier to understand a linear history. > Agreed. Let's go with option #1. -eric ___ lldb-dev mailing list lldb-dev@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
Re: [lldb-dev] [llvm-dev] [Github] RFC: linear history vs merge commits
Jeremy Lakeman via llvm-dev writes: > 4. Each reviewed bug / feature must be rebased onto the current "known > good" commit, merged into a "probably good" commit, tested by build > bots, and only then pushed to trunk. Keeping trunk's history more > usable, with most bad patches reworked and resubmitted instead of > reverted. If you mean having a submitted PR trigger builds and only allow merging if all builds pass, that may be doable. Of course by the time it's merged it will be against some later commit (so it should be rebased) and there's no guarantee it will build against *that* commit. But it will tend to filter out most problems. Trying to keep a branch buildable at all times is a hard problem, but the above is probably a 90% solution. -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] [Github] RFC: linear history vs merge commits
Bruce Hoult via llvm-dev writes: > How about: > > Require a rebase, followed by git merge --no-ff > > This creates a linear history, but with extra null merge commits > delimiting each related series of patches. > > I believe it is compatible with bisect. > > https://linuxhint.com/git_merge_noff_option/ We've done both and I personally prefer the strict linear history by a lot. It's just much easier to understand a linear history. -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] [Github] RFC: linear history vs merge commits
Strongly in favor of #1. If we decide to move away from #1, I strongly believe it should be done well after the github migration. (i.e. lets not change everything at once!) Philip On 1/29/19 2:33 PM, Tom Stellard via cfe-dev wrote: Hi, As part of the migration of LLVM's source code to github, we need to update our developer policy with instructions about how to interact with the new git repository. There are a lot of different topics we will need to discuss, but I would like to start by initiating a discussion about our merge commit policy. Should we: 1. Disallow merge commits and enforce a linear history by requiring a rebase before push. 2. Allow merge commits. 3. Require merge commits and disallow rebase before push. I'm going to propose that if we cannot reach a consensus that we adopt policy #1, because this is essentially what we have now with SVN. What does everyone think? Thanks, Tom ___ cfe-dev mailing list cfe-...@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev ___ lldb-dev mailing list lldb-dev@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
Re: [lldb-dev] [llvm-dev] [Github] RFC: linear history vs merge commits
> On Jan 29, 2019, at 4:55 PM, Jeremy Lakeman via llvm-dev > wrote: > > 5. When a new feature is broken up into a patch series, the series should be > rebased then immediately merged to help identify the individual patches in > the history graph. Typically the LLVM development model discourages merging big features in one go and instead gravitates towards breaking patches up into small, easy to reason about patches that gradually morph the code towards the goal. This makes it easier for reviewers and to track down regressions after each patch landed. For this reason we rarely have series of connected patches coming in at once. -- adrian ___ lldb-dev mailing list lldb-dev@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
Re: [lldb-dev] [Github] RFC: linear history vs merge commits
On Tue, Jan 29, 2019 at 5:33 PM Tom Stellard via lldb-dev wrote: > > Hi, > > As part of the migration of LLVM's source code to github, we need to update > our developer policy with instructions about how to interact with the new git > repository. There are a lot of different topics we will need to discuss, but > I would like to start by initiating a discussion about our merge commit > policy. Should we: > > 1. Disallow merge commits and enforce a linear history by requiring a >rebase before push. > > 2. Allow merge commits. > > 3. Require merge commits and disallow rebase before push. > > I'm going to propose that if we cannot reach a consensus that we > adopt policy #1, because this is essentially what we have now > with SVN. > > What does everyone think? I'm strongly in favour of #1: no merges allowed, enforced by the upstream repository, and that for release branches we use cherry-picks like we do currently. Thanks, Hans ___ lldb-dev mailing list lldb-dev@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
[lldb-dev] [8.0.0 Release] Release Candidate 1 source, docs, and binaries available
Hello everyone, Source, docs, and binaries for LLVM-8.0.0-rc1 are now available at https://prereleases.llvm.org/8.0.0/#rc1 Please try it out and report any problems as bugs marked as blockers of https://llvm.org/pr40331 Thanks, Hans ___ lldb-dev mailing list lldb-dev@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
Re: [lldb-dev] [Release-testers] [8.0.0 Release] rc1 has been tagged
ARM looks good. Uploaded. 358fc71b8021eddbb1b93142bc09f1ad698677a6 clang+llvm-8.0.0-rc1-armv7a-linux-gnueabihf.tar.xz Cheers, Diana On Wed, 30 Jan 2019 at 05:45, Brian Cain via Release-testers wrote: > > > SLES and Ubuntu 14.04 tarballs uploaded. Sorry for the delay. I will try > and find time to make a build for bionic / 18.04 too. > > 99ec00702e39b096ace4fbce3d787b9e485b879e > clang+llvm-8.0.0-rc1-x86_64-linux-gnu-ubuntu-14.04.tar.xz > > dbf204f70cb09ec459e5eb4fc14e8fa71292daa7 > clang+llvm-8.0.0-rc1-x86_64-linux-sles11.3.tar.xz > > > On Wed, Jan 23, 2019 at 6:50 PM Hans Wennborg via Release-testers > wrote: >> >> Dear testers, >> >> 8.0.0-rc1 was just tagged (from the branch at r351980). >> >> It took a little longer than planned, but it's looking good. >> >> Please run the test script, share your results, and upload binaries. >> >> I'll get the source tarballs and docs published as soon as possible, >> and binaries as they become available. >> >> Thanks, >> Hans >> ___ >> Release-testers mailing list >> release-test...@lists.llvm.org >> https://lists.llvm.org/cgi-bin/mailman/listinfo/release-testers > > > > -- > -Brian > ___ > Release-testers mailing list > release-test...@lists.llvm.org > https://lists.llvm.org/cgi-bin/mailman/listinfo/release-testers ___ lldb-dev mailing list lldb-dev@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
