Re: [lldb-dev] test results look typical?

! -Todd On Mon, Aug 24, 2015 at 3:42 PM, Todd Fiala via lldb-dev lldb-dev@lists.llvm.org wrote: On Mon, Aug 24, 2015 at 3:39 PM, Zachary Turner ztur...@google.com wrote: Can't comment on the failures for Linux, but I don't think we have a good handle on the unexpected successes. I only added

Re: [lldb-dev] test results look typical?

normal, that'd be good to know. Thanks! It's likely that someone could just go in there and remove the XFAIL from those tests. On Mon, Aug 24, 2015 at 3:37 PM Todd Fiala via lldb-dev lldb-dev@lists.llvm.org wrote: Hi all, I'm just trying to get a handle on current lldb test failures

Re: [lldb-dev] test results look typical?

few hundreds runs. Ah yes that :-) Love it. Thanks, Tamas! Tamas On Tue, Aug 25, 2015 at 2:50 AM via lldb-dev lldb-dev@lists.llvm.org wrote: On Mon, Aug 24, 2015 at 05:37:43PM -0700, via lldb-dev wrote: On Mon, Aug 24, 2015 at 03:37:52PM -0700, Todd Fiala via lldb-dev wrote

Re: [lldb-dev] [Lldb-commits] [lldb] r248028 - Make libc++ tests skip themselves if libc++ is not actually loaded in the target

I'm in favor of (b). The less user-required setup to do the right thing on a test suite, the better IMHO. Those actively trying to make sure one or another c++ library is getting tested will be looking for the output to validate which std c++ lib(s) ran. -Todd On Wed, Oct 21, 2015 at 3:47 AM,

Re: [lldb-dev] lldb tests and tear down hooks

(And side note: if you're pushing a "lambda: self.foo()" with no arguments, the lambda is unneeded and you can just push "self.foo" --- that cleanup hook pushed on most tests at the end of the file is a perfect example of an unneeded level of lambda indirection). On Wed, Oct 21, 2015 at 12:04 PM,

Re: [lldb-dev] RFC: Making unit tests run by default on ninja check-lldb

Oh haha okay. :-) Thanks for explaining, Ying! -Todd On Wed, Oct 21, 2015 at 10:01 AM, Ying Chen wrote: > Yes, the output of dotest.py goes through LitTestCommand parse. > The parser is matching for "XPASS", but dotest output is using "UNEXPECTED > SUCCESS". :) > > Thanks,

Re: [lldb-dev] Moving pexpect and unittest2 to lldb/third_party

We could also then remove unittest2 from inclusion in the lldb repo. On Thu, Oct 22, 2015 at 11:28 AM, Todd Fiala wrote: > I'd be okay with that. > > The unittest2 stuff looks like it was a vestige of being incorporated > before unittest2 was stock (unitest) on Python

Re: [lldb-dev] Moving pexpect and unittest2 to lldb/third_party

Yeah I think the biggest thing I wanted to check there was that there wasn't any unittest2 behavior present in that cut of unittest2 that didn't make it into the revamped version brought into the python distributions when they upgraded unittest. Then it's just a big rename exercise on replacing

[lldb-dev] lldb-gtest scheme and target added to Xcode project

Hi all, I've taken a stab at getting the gtests in lldb/unittests to compile and run on Xcode. I just checked this in. There's a new scheme called lldb-gtest. If you run that in Xcode, it should build the DebugClang variant of lldb and link against the gtest libraries that come with clang. The

Re: [lldb-dev] Refactoring dotest as a Python package

On Tue, Oct 27, 2015 at 8:12 PM, Zachary Turner wrote: > Todd, I have one question. If I understand correctly, we currently run > dotest.py as a script, which imports dosep and calls some method in dosep, > and dosep then again exec's dotest. > > Can you think of a pythonic

Re: [lldb-dev] lldb-gtest scheme and target added to Xcode project

Yes, they do. On Mon, Oct 26, 2015 at 9:34 AM, Zachary Turner <ztur...@google.com> wrote: > Nice! Out of curiosity, do all the unittests pass? (I expect they do, as > they do everywhere else, just wondering) > > On Sun, Oct 25, 2015 at 2:57 PM Todd Fiala via lld

Re: [lldb-dev] command line for running the format checker?

mat` > > On Sun, Oct 25, 2015 at 8:57 AM Todd Fiala via lldb-dev < > lldb-dev@lists.llvm.org> wrote: > >> Hi all, >> >> What's the proper command line invocation to run our sources through to >> get proper LLVM formatting and other desired fix-ups? >>

[lldb-dev] swig generation

Hi all, I'd like to do a few things with our swig generation and handling: * Create a maintainer-mode style setup where the swig Python bindings are generated and checked into the repo (I'll call it the static python binding). This will be used by default, removing the need for most people and

Re: [lldb-dev] Two CLs requiring changes to the Xcode project

Looks like everything was covered. Thanks, all! On Thu, Nov 12, 2015 at 7:07 PM, Zachary Turner wrote: > Thanks! I actually forgot, there's one more file for the lldb-gtest > target. It's PythonExceptionStateTests.cpp. > > Thanks for the help > > On Thu, Nov 12, 2015 at

Re: [lldb-dev] swig generation

I will probably tackle this as two phases: Phase 1: * Python script modernization (the python swig wrapper generation) * Move Xcode onto it. Phase 2: * The maintainer-mode, static Python binding generation changes for cmake and Xcode. I want to make sure we have proven, still-functional Python

Re: [lldb-dev] Attaching to a stopped (cored) process hangs lldb-server

Hey Pavel, I think Mark is also on RHEL 5-era, so this going *way* back in the kernel space. It is entirely possible he is seeing different behavior based on that. We only recently started working on RHEL 7 and (I've heard reports of) 6. So this could just be legitimate behavioral difference

Re: [lldb-dev] Attaching to a stopped (cored) process hangs lldb-server

Although doing any kind of waitpid() in the case of a core file doesn't make sense. On Wed, Nov 4, 2015 at 9:44 AM, Todd Fiala wrote: > Hey Pavel, > > I think Mark is also on RHEL 5-era, so this going *way* back in the kernel > space. It is entirely possible he is seeing

Re: [lldb-dev] Compiling LLDB on Centos 5 (dont judge me)

Great, glad to hear, Mark! On Thu, Oct 29, 2015 at 4:57 PM, Mark Chandler wrote: > > For My Centos 5 build: > > * Using python 2.7 (From devtoolset 2) > > * Using gcc 4.8 (From devtoolset 2) > > * disabled libedit and python bindings > > * Built cmake from source > > *

Re: [lldb-dev] Apple LLDB OS X build bot

the test suit is run then where can we see the result of the tests? > > Thanks, > Tamas > > On Wed, Oct 28, 2015 at 2:03 PM Todd Fiala via lldb-dev < > lldb-dev@lists.llvm.org> wrote: > >> Hi all, >> >> I've made a few changes to the Apple OS X buildbot tod

Re: [lldb-dev] TestRaise.py test_restart_bug flakey stats

Thanks, Tamas. On Mon, Oct 19, 2015 at 4:30 AM, Tamas Berghammer wrote: > The expected flakey works a bit differently then you are described: > * Run the tests > * If it passes, it goes as a successful test and we are done > * Run the test again > * If it is passes the

Re: [lldb-dev] Python 3 and dotest

On Mon, Oct 12, 2015 at 7:31 PM, Zachary Turner wrote: > Moving this to the public list because it seems useful to see what other > members of the community have to say as well. > > On Mon, Oct 12, 2015 at 4:22 PM Zachary Turner wrote: > >> It's worth

[lldb-dev] proposal for reworked flaky test category

Hi all, I'd like unexpected successes (i.e. tests marked as unexpected failure that in fact pass) to retain the actionable meaning that something is wrong. The wrong part is that either (1) the test now passes consistently and the author of the fix just missed updating the test definition (or

Re: [lldb-dev] proposal for reworked flaky test category

On Mon, Oct 19, 2015 at 1:03 PM, Zachary Turner <ztur...@google.com> wrote: > > > On Mon, Oct 19, 2015 at 12:50 PM Todd Fiala via lldb-dev < > lldb-dev@lists.llvm.org> wrote: > >> Hi all, >> >> I'd like unexpected successes (i.e. tests marked as unexp

Re: [lldb-dev] proposal for reworked flaky test category

ide the categorization for the TestCase getCategories() mechanism. >> >> -Todd >> >> On Mon, Oct 19, 2015 at 1:03 PM, Zachary Turner <ztur...@google.com> >> wrote: >> >>> >>> >>> On Mon, Oct 19, 2015 at 12:50 PM Todd Fiala via lldb-dev

Re: [lldb-dev] TestRaise.py test_restart_bug flakey stats

Hmm, the flakey behavior may be specific to dwo. Testing it locally as unconditionally flaky on Linux is failing on dwarf. All the ones I see succeed are dwo. I wouldn't expect a diff there but that seems to be the case. So, the request still stands but I won't be surprised if we find that dwo

Re: [lldb-dev] Too many open files

Interesting, okay.. This does appear to be an accumulation issue. You made it most of the way through before the issue hit. I suspect we're leaking file handles. It probably doesn't hit the per-process limit on multiprocessing because the leaked files get spread across more processes. (All

Re: [lldb-dev] [Lldb-commits] [lldb] r253317 - Add Pythonic language binding wrapper generation script.

Checking in the static bindings is no different than projects checking in autoconf config baked scripts so that the vast majority of people don't need to run autoconf just to get a setup that rarely changes. There is precedent for this going back a long way on open source projects. I'm backing

Re: [lldb-dev] keep an eye out for broken lldb bindings

FYI - This switchover change looks like it made it through the Ubuntu and Windows builders. On Wed, Nov 18, 2015 at 10:21 AM, Todd Fiala wrote: > Hi all, > > I've cleaned up our swig generation scripts as used by cmake and Xcode > builds. They're working fine on Xcode,

Re: [lldb-dev] keep an eye out for broken lldb bindings

BTW this change only affected the swig wrapper generation. There's a separate "finish" script that I have not yet touched nor have I adopted on Xcode. I'll look at that as some near-term clean-up, I'd like to get Xcode using what everyone else is using there. -Todd On Wed, Nov 18, 2015 at

Re: [lldb-dev] [Lldb-commits] [lldb] r253317 - Add Pythonic language binding wrapper generation script.

On Wed, Nov 18, 2015 at 10:34 AM, Zachary Turner wrote: > > > On Wed, Nov 18, 2015 at 10:00 AM Todd Fiala wrote: > >> Checking in the static bindings is no different than projects checking in >> autoconf config baked scripts so that the vast majority of

Re: [lldb-dev] [Lldb-commits] [lldb] r253317 - Add Pythonic language binding wrapper generation script.

On Wed, Nov 18, 2015 at 12:53 PM, Todd Fiala wrote: > > > On Wed, Nov 18, 2015 at 12:45 PM, Zachary Turner > wrote: > >> >> >> On Wed, Nov 18, 2015 at 11:15 AM Todd Fiala wrote: >> >>> On Wed, Nov 18, 2015 at 10:34 AM, Zachary

Re: [lldb-dev] [Lldb-commits] [lldb] r253317 - Add Pythonic language binding wrapper generation script.

On Wed, Nov 18, 2015 at 12:45 PM, Zachary Turner wrote: > > > On Wed, Nov 18, 2015 at 11:15 AM Todd Fiala wrote: > >> On Wed, Nov 18, 2015 at 10:34 AM, Zachary Turner >> wrote: >> >>> Because even if it isn't perfect for everyone,

Re: [lldb-dev] swig generation

On Fri, Nov 13, 2015 at 9:02 AM, Todd Fiala wrote: > Hi all, > > I'd like to do a few things with our swig generation and handling: > > * Create a maintainer-mode style setup where the swig Python bindings are > generated and checked into the repo (I'll call it the static

Re: [lldb-dev] swig generation

On Mon, Nov 16, 2015 at 11:28 PM, Todd Fiala wrote: > > > On Fri, Nov 13, 2015 at 9:02 AM, Todd Fiala wrote: > >> Hi all, >> >> I'd like to do a few things with our swig generation and handling: >> >> * Create a maintainer-mode style setup where the

Re: [lldb-dev] Test suite rebuilding test executables many times

Not sure if this is relevant, but I seem to recall the remote test execution would spin off each test method run (test case level, not test suite level) into a new directory. I don't think that would be inherently broken by a no-clean scenario but we'd want to make sure it doesn't break. -Todd

Re: [lldb-dev] top-of-tree build failure when using configure on Linux?

nge it to CMake instead of configure? I know that's not what >> you want to hear, but the configure build is on its way out, so you're >> going to have to do this at some point anyway. >> >> >> >> On Thu, Sep 3, 2015 at 10:25 AM Todd Fiala via lldb-dev < >&g

[lldb-dev] Note to buildbot/testbot runners

Hi all, TL;DR: if you call dosep.py directly, you'll need to modify your flow to call dotest.py. *Details:* *dotest.py now runs in parallel test runner mode by default* Starting with lldb svn revision 246794, if you run buildbots or testbots and you directly called dosep.py as a build step,

Re: [lldb-dev] Note to buildbot/testbot runners

A few notes to dotest.py users: * If you want to limit a test run to a test subdirectory *tree*, you can use the new --test-subdir flag. It covers what used to be the supported unnamed argument in dosep.py. It is specified relative to the lldb/test dir. * If you want to use the unnamed

Re: [lldb-dev] Portable tests that create threads

I think the thread naming is a reasonable way to go. > 1) Linux and MacOSX inferiors can use pthread_setname_np > 2) FreeBSD inferiors can use pthread_set_name_np IIRC Linux and FreeBSD both are limited to a very short thread name, much shorter than OS X and, if I'm not mistaken, Windows as

Re: [lldb-dev] test results look typical?

2015 at 16:20, Todd Fiala via lldb-dev lldb-dev@lists.llvm.org wrote: On Mon, Aug 24, 2015 at 4:11 PM, Todd Fiala todd.fi...@gmail.com wrote: On Mon, Aug 24, 2015 at 4:01 PM, Chaoren Lin chaor...@google.com wrote: The TestDataFormatterLibcc* tests require libc

Re: [lldb-dev] Windows build questions

ly get > around to it, but it's a lot of work. Still follow the build instructions > anyway because there's other things as well, but the above 3 are probably > the most likely to trip you up. > > On Mon, Sep 7, 2015 at 10:33 AM Todd Fiala via lldb-dev < > lldb-dev@lists.l

Re: [lldb-dev] Looking for info on two rdars: 18684124, 15367233

We have a chunk of tests that are marked xfail that pass right now on OS X. I'll go through those in the near future. I'm also seeing several tests consistently unexpectedly pass on Linux x86_64 (Ubuntu 14.04) built with clang-3.6. I think at least some of them fail with gcc-4.9, so they might

Re: [lldb-dev] Looking for info on two rdars: 18684124, 15367233

Checking the disposition of these now. On Wed, Sep 9, 2015 at 8:10 AM, Todd Fiala wrote: > We have a chunk of tests that are marked xfail that pass right now on OS > X. I'll go through those in the near future. > > I'm also seeing several tests consistently unexpectedly

[lldb-dev] cleaning up unexpected successes on OS X

Hey all, As of this change: r247567 | tfiala | 2015-09-14 07:48:53 -0700 (Mon, 14 Sep 2015) | 7 lines I'm seeing the following unexpected successes on OS X: Unexpected Successes (16) UNEXPECTED SUCCESS: LLDB (suite) :: TestCallStdStringFunction.py (Darwin tfiala-mbp-01.local 15.0.0 Darwin

[lldb-dev] Digging into Linux unexpected successes

On an Ubuntu 14.04 x86_64 system, I'm seeing the following results: *cmake/ninja/clang-3.6:* Testing: 395 test suites, 24 threads 395 out of 395 test suites processed - TestGdbRemoteKill.py Ran 395 test suites (0 failed) (0.00%) Ran 478 test cases (0 failed) (0.00%) Unexpected Successes

Re: [lldb-dev] 7th build slot?

Okay, thanks. It would be awesome if the summary listed the specific versions of clang being used. TOT is obvious, but "clang" being 3.5 is less so. Seeing as clang behavior can change between releases, perhaps we can use the other slots for other clang versions? TOT clearly makes sense if

Re: [lldb-dev] 7th build slot?

Thanks for the info, Ying! On Tue, Sep 15, 2015 at 11:04 AM, Ying Chen wrote: > Thanks for the suggestions. > I've changed the descriptions of "clang" to "clang-3.5" since this > > build. > > We

Re: [lldb-dev] Digging into Linux unexpected successes

Change http://reviews.llvm.org/D12831 in review (waiting on Windows results for that) adds a test event stream that supports pluggable test event formatters. The first formatter I've added is JUnit/XUnit output. That's to support typical JUnit/XUnit output handling built into most commercial and

Re: [lldb-dev] Digging into Linux unexpected successes

me time. If you want I can include the list of >>> build numbers for all outcome, but it will be a very log list (currently >>> only included for Timeout and Failure) >>> >>> >> I'll know better when I have a look at what you provided. The hole I see >>

Re: [lldb-dev] Digging into Linux unexpected successes

a look at what you provided. The hole I see right now is we're not adequately dealing with unexpected successes for different configurations. Any reporting around that is helpful. Thanks! > Tamas > > On Mon, Sep 14, 2015 at 11:24 PM Todd Fiala via lldb-dev < > lldb-dev@lis

Re: [lldb-dev] TestAttachDenied - timing out

That said, I'm going to disable the test and look into why it is timing out so our poor Google test runner doesn't take forever to go through the tests. I'll file a ticket and look into it. On Tue, Sep 29, 2015 at 3:54 PM, Todd Fiala wrote: > Hi all, > > I've been running

[lldb-dev] TestAttachDenied - timing out

Hi all, I've been running the test suite for quite some time on the Linux side. I pretty consistently see this test case file: TestAttachDenied.py time out on my Linux setup (prior to any of my test runner changes). I'm noticing it is now showing up on the Google Linux buildbot (here - build

[lldb-dev] possible test runner speedup

Hi all, I've started looking into test runner speeds based on the number of threads. Since we first introduced the parallel test runner, we've defaulted to using a number of work queues equal to the number of logical processors reported by the machine. Thus on a 24 core Linux box (12

Re: [lldb-dev] Layout of FXSAVE struct for x86 Architectures in LLDB

I'm using this doc: http://www.intel.com/content/dam/www/public/us/en/documents/manuals/64-ia-32-architectures-software-developer-manual-325462.pdf In table 10-2, and again in 13-1, it does appear to call out the most significant byte as reserved (byte 5). As do the instruction details.

[lldb-dev] Ubuntu 15.10 B1 test results

Hi all, FYI - I just gave a build of lldb @248306 on a Ubuntu 15.10 Beta 1 VM running under a VMWare hypervisor. Here's what I saw: LLDB build with clang-3.7 / tests run with inferiors built with gcc 5.2.1 (defaults gcc): Ran 398 test suites (10 failed) (2.512563%) Ran 411 test cases (10

[lldb-dev] I see at least one test hanging...

Hey all, On the Linux build bot, I'm seeing at least one test hung here after my change: http://lab.llvm.org:8011/builders/lldb-x86_64-ubuntu-14.04-cmake/builds/6572 It is conceivable that my change to put the test inferior into a separate process group is interfering with timeout handling.

Re: [lldb-dev] I see at least one test hanging...

Rolled back here: ➜ lldb svn commit Sendingtest/dosep.py Transmitting file data . Committed revision 248284. I'll re-add this and limit to OS X after I get a chance to review. -Todd On Tue, Sep 22, 2015 at 9:01 AM, Todd Fiala wrote: > Hey all, > > On the Linux

Re: [lldb-dev] I see at least one test hanging...

I suspect my issue may have been over-isolation. While I only needed a new process group, I did it by creating a new session. The SIGQUIT used by timeout/gtimeout may not be able to work across sessions. I'm going to give this another try with just setting the process group without creating a

Re: [lldb-dev] I see at least one test hanging...

I stopped the two builds in progress (that were badly hanging, 20 minutes per test run configuration) until the builder caught up to r248284. -Todd On Tue, Sep 22, 2015 at 9:06 AM, Todd Fiala wrote: > Rolled back here: > ➜ lldb svn commit > Sendingtest/dosep.py

Re: [lldb-dev] [Diffusion] rL248282: test runner: Unix systems now put inferior dotest in its own process group.

Hey Zachary, There is a Windows-specific subprocess.CREATE_NEW_PROCESS_GROUP flag that you could potentially add to the Windows branch of the suprocess creation call in dosep.py. I'm not sure how useful that is on the Windows end as this is mostly about console signal isolation, but I thought

Re: [lldb-dev] changing default test runner from multiprocessing-based to threading-based

problem grows to other areas. What other >> things fail horribly when a single instance of LLDB is debugging 100 >> processes at the same time? >> >> It's worth adding this as an alternate run mode, but I don't think we >> should make it default until it's more battle-tested.

Re: [lldb-dev] changing default test runner from multiprocessing-based to threading-based

f course the problem grows to other areas. What other >>> things fail horribly when a single instance of LLDB is debugging 100 >>> processes at the same time? >>> >>> It's worth adding this as an alternate run mode, but I don't think we >>> should make it defau

Re: [lldb-dev] test results look typical?

Great, thanks for filing, Dawn! On Thu, Sep 17, 2015 at 2:08 PM, <d...@burble.org> wrote: > On Mon, Aug 24, 2015 at 05:37:43PM -0700, via lldb-dev wrote: > > On Mon, Aug 24, 2015 at 03:37:52PM -0700, Todd Fiala via lldb-dev wrote: > > > On Linux on non-virtualized h

[lldb-dev] changing default test runner from multiprocessing-based to threading-based

Hi all, I'm considering changing the default lldb test runner from multiprocessing-based to threading-based. Long ago I switched it from threading to multiprocessing. The only reason I did this was because OS X was failing to allow more than one exec at a time in the worker threads - way down

[lldb-dev] Moving test runner timeout logic into Python

Hi all, Over the last two days, I've hit some inconsistencies across platforms surrounding signal handling and the operation of the timeout/gtimeout executable mechanism that we use to handle timeouts of tests. The net result is I still see tests sometimes hang up the test running process, even

Re: [lldb-dev] Moving test runner timeout logic into Python

less blockable >>>>> kill. But make the >>>>># process die one way or another. >>>>> >>>>> # do the other post-process activity here... >>>>> >>>>> >>>>> >>>>> ^= that's roug

Re: [lldb-dev] Moving test runner timeout logic into Python

verywhere, I assume this means Windows > too, which currently does not support running with a timeout at all > (because timeout / gtimeout aren't present) > > On Wed, Sep 23, 2015 at 2:22 PM Todd Fiala via lldb-dev < > lldb-dev@lists.llvm.org> wrote: > >> Hi all, &

[lldb-dev] serialized, low-load test pass in parallel test runner

Hi all, On OS X (and frankly on Linux sometimes as well, but predominently OS X), we have tests that will sometimes fail when under significant load (e.g. running the concurrent test suite, exacerbated if we crank up the number of threads, but bad enough if we run at "number of concurrent workers

Re: [lldb-dev] serialized, low-load test pass in parallel test runner

Note this is similar to the flakey test mechanism, with the primary difference being that the re-run is done in a minimal CPU load environment rather than wherever the failure first occurred. The existing flakey test rerun logic is not helpful for the high-load-induced failures that I'm looking

Re: [lldb-dev] Linux core dump doesn't show listing when loaded

Does our init file mechanism have the ability to do something conditionally if it's a core file? (i.e. do we already have a way to get Ted's desired behavior via an inserted call to "thread backtrace all" that somehow gets triggered by the init, but only when we're talking about a core file?)

Re: [lldb-dev] Exclusively build and install LLDB?

Yes, that concept came out in the thread. I just wanted to make sure there wasn't also a desire to park on a version of llvm/clang, and if so, that the path there is not pleasant and definitely not intended to be supported on top of tree svn/trunk. Thanks for clarifying! -Todd On Wed, Dec 2,

Re: [lldb-dev] Exclusively build and install LLDB?

Sorry for being late the the party here. Sean Callanan and some of the other members can comment more on this, but LLDB's expression parser for C/C++ is going to need access to the clang include headers, so somehow lldb has to be able to find them. Out of tree llvm/clang usage is certainly

Re: [lldb-dev] static swig bindings and xcode workspace

Hi Zachary, On Mon, Nov 30, 2015 at 9:23 AM, Zachary Turner wrote: > Has the xcode build been changed to use static bindings yet? > It is only in our downstream branches. I stripped out support in llvm.org lldb per our other threads. > I got to thinking that maybe it

Re: [lldb-dev] New test summary results formatter

Also, all the text in the summary is fixed-width lined up nicely, which may not show in the commit message description if you're using a variable-width font. On a terminal it looks nice. On Wed, Dec 2, 2015 at 11:01 AM, Todd Fiala wrote: > > > On Wed, Dec 2, 2015 at 10:57

Re: [lldb-dev] New test summary results formatter

at 11:04 AM, Zachary Turner <ztur...@google.com> wrote: > Can --results-file=stdout be the default so that we don't have to specify > that? > > On Wed, Dec 2, 2015 at 11:02 AM Todd Fiala via lldb-dev < > lldb-dev@lists.llvm.org> wrote: > >> Also, all the text in

Re: [lldb-dev] static swig bindings and xcode workspace

On Wed, Dec 2, 2015 at 8:28 AM, Todd Fiala wrote: > Hi Zachary, > > On Mon, Nov 30, 2015 at 9:23 AM, Zachary Turner > wrote: > >> Has the xcode build been changed to use static bindings yet? >> > > It is only in our downstream branches. I stripped out

Re: [lldb-dev] New test summary results formatter

file organization. > > On Wed, Dec 2, 2015 at 11:04 AM Zachary Turner <ztur...@google.com> wrote: > >> Can --results-file=stdout be the default so that we don't have to specify >> that? >> >> On Wed, Dec 2, 2015 at 11:02 AM Todd Fiala via lldb-dev < >>

Re: [lldb-dev] New test summary results formatter

gt; logical source file organization. >> >> On Wed, Dec 2, 2015 at 11:04 AM Zachary Turner <ztur...@google.com> >> wrote: >> >>> Can --results-file=stdout be the default so that we don't have to >>> specify that? >>> >>> On Wed, Dec 2

Re: [lldb-dev] New test summary results formatter

On Wed, Dec 2, 2015 at 10:57 AM, Todd Fiala wrote: > Hi all, > > I just put up an optional test results formatter that is a prototype of > what we may move towards for our default test summary results. It went in > here: > > r254530 > > and you can try it out with

Re: [lldb-dev] New test summary results formatter

dule.) > >> On Wed, Dec 2, 2015 at 11:04 AM Zachary Turner <ztur...@google.com> >> wrote: >> >>> Can --results-file=stdout be the default so that we don't have to >>> specify that? >>> >>> On Wed, Dec 2, 2015 at 11:02 AM Todd Fiala vi

[lldb-dev] New test summary results formatter

Hi all, I just put up an optional test results formatter that is a prototype of what we may move towards for our default test summary results. It went in here: r254530 and you can try it out with something like: time test/dotest.py --executable `pwd`/build/Debug/lldb --results-formatter

Re: [lldb-dev] New test summary results formatter

atter is specified and no results-file is specified. Good idea, thanks! > On Wed, Dec 2, 2015 at 11:02 AM Todd Fiala via lldb-dev < > lldb-dev@lists.llvm.org> wrote: > >> Also, all the text in the summary is fixed-width lined up nicely, which >> may not show in the commit mess

Re: [lldb-dev] New test summary results formatter

ed, Dec 2, 2015 at 11:10 AM, Zachary Turner < >>>>>>>>>> ztur...@google.com> wrote: >>>>>>>>>> >>>>>>>>>>> Also another stylistic suggestion. I've been thinking about how >>>>>>>

Re: [lldb-dev] New test summary results formatter

t;>>>>> This has the advantage of making the command line shorter *and* a >>>>>> more logical source file organization. >>>>>> >>>>> >>>> The other thing that could allow me to do is possibly short-circuit

Re: [lldb-dev] New test summary results formatter

ackage called formatters. So right now >>>>>>>>> you've got lldbsuite.test.basic_results_formatter. >>>>>>>>> BasicResultsFormatter but it might make sense for this to be >>>>>>>>> lldbsuite.test.formatters.basic.Basic

Re: [lldb-dev] New test summary results formatter

On Wed, Dec 2, 2015 at 9:48 PM, Zachary Turner wrote: > > > On Wed, Dec 2, 2015 at 9:44 PM Todd Fiala wrote: > >> >> >>> and the classname could be dropped (there's only one class per file >>> anyway, so the classname is just wasted space) >>> >> >>

Re: [lldb-dev] New test summary results formatter

>>>>>>>>>>>> >>>>>>>>>>>>> When I run this under Python 3 I get "A bytes object is used >>>>>>>>>>>>> like a string" on Line 1033 of test_results.py. I'm going to dig >>>>>>&g

Re: [lldb-dev] New test summary results formatter

Hi all, r254890 moves the test summary counts to the end. It also greatly cleans up the issue detail line to be: ISSUE_TYPE: test_method_name (test relative path) I put a sample output in the revision comment. I think it looks much cleaner with the tweaks we discussed, and I really like the

Re: [lldb-dev] Auditing dotest's command line options

I think it's a nice improvement. Passing the options around via the argparse results (as I do in many programs) makes it easier to unit test, but having configuration variables all in a module makes it really simple to find and use everywhere without having them as globals. Thanks for cleaning

Re: [lldb-dev] BasicResultsFormatter - new test results summary

> > On Wed, Dec 9, 2015 at 4:00 PM Todd Fiala via lldb-dev < > lldb-dev@lists.llvm.org> wrote: > >> Hi all, >> >> Per a previous thread on this, I've made all the changes I intended to >> make last night to get the intended replacement of test run results mee

Re: [lldb-dev] BasicResultsFormatter - new test results summary

side to support a change in >> the default test result summary formatter? >> >> On Wed, Dec 9, 2015 at 4:00 PM Todd Fiala via lldb-dev < >> lldb-dev@lists.llvm.org> wrote: >> >>> Hi all, >>> >>> Per a previous thread on this, I'v

Re: [lldb-dev] BasicResultsFormatter - new test results summary

gt;> >>> >> >>> I use (so I claim) the same all upper-case markers for the test result >> >>> details. Including, not using XPASS but rather UNEXPECTED SUCCESS for >> >>> unexpected successes. (The former would trigger the lit script IIRC >> to >

Re: [lldb-dev] BasicResultsFormatter - new test results summary

lidate if its working). >>>>>>> > >>>>>>> > -Todd >>>>>>> > >>>>>>> > On Wed, Dec 9, 2015 at 8:06 AM, Todd Fiala <todd.fi...@gmail.com> >>>>>>> wrote: >>>>>>> >>

Re: [lldb-dev] BasicResultsFormatter - new test results summary

XPECTED SUCCESS >>>>> >> TIMEOUT >>>>> >> >>>>> >> (These are the fourth field in the array entries (lines 275 - 290) >>>>> of >>>>> >> packages/Python/lldbsuite/test/basic_results_

Re: [lldb-dev] BasicResultsFormatter - new test results summary

Fiala <todd.fi...@gmail.com> >>>>>> wrote: >>>>>> >> >>>>>> >> Specifically, the markers for issue details are: >>>>>> >> >>>>>> >> FAIL >>>>>> >> ERRO

Re: [lldb-dev] New test summary results formatter

One thing I excluded from the newer test results detail info is the architecture. I personally haven't ever needed that. I'd be happy to leave that out until we find someone who really needs it, just to keep it shorter. On Thu, Dec 3, 2015 at 5:14 PM, Todd Fiala wrote: >

[lldb-dev] LLDB and Swift

Hi all, Earlier today, you may have heard that Swift went open source over at swift.org. I just wanted to take a moment to mention the Swift debugger and REPL and how they relate to LLDB. Swift’s Debugger and REPL are built on LLDB’s source-level plug-in architecture. As such, the Swift

Re: [lldb-dev] New test summary results formatter

ause I didn't know all >>>>>>>>>>>> the formatters were derived from a common base. But your idea is >>>>>>>>>>>> better if >>>>>>>>>>>> everything is derived from a common base. To

Re: [lldb-dev] LLDB and Swift

Thanks, Kamil! -Todd > On Dec 3, 2015, at 5:02 PM, Kamil Rytarowski <n...@gmx.com> wrote: > > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA256 > > Very nice. Congrats on your release! > >> On 04.12.2015 00:03, Todd Fiala via lldb-dev wrote: >> Hi all, &

Re: [lldb-dev] New test summary results formatter

;>>>> >>>>>>>>>> Also another stylistic suggestion. I've been thinking about how >>>>>>>>>> to more logically organize all the source files now that we have a >>>>>>>>>> package. So it makes

  1   2   >