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 P
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:
> >
> >
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'
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 pexpe
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 ac
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 el
> 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 cou
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 t
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
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
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 bet
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@li
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 pyexpe
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 p
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
>> | \
>> \ `---.
>> `
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 syst
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
>
17 matches
Mail list logo
