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

I fixed several RHEL-derived distribution-related issues in top of tree LLDB a few weeks back. It was for RHEL 7-derived builds, so quite a bit newer. If you are building your lldb off of top-of-tree, hopefully this will mostly become an exercise of: * Do you have a new-enough python. (I believ

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 way to make this work

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 > > * Make is fine so didnt both

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

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 today. These ar

Re: [lldb-dev] Is this a test, or a build? Help with link you supplied / Tony

I'm not sure I fully understand the question, but the GreenDragon CI LLVM Build Cluster has an LLDB builder for OS X which looks like you're referencing with the links above. It gets built by a few stages: one to grab sources, another to do the building. I just poked over there and the build look

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 th

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 different behavior base

[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 a

Re: [lldb-dev] swig generation

On Fri, Nov 13, 2015 at 9:43 AM, Zachary Turner wrote: > On Fri, Nov 13, 2015 at 9:02 AM Todd Fiala via lldb-dev < > lldb-dev@lists.llvm.org> wrote: > >> Hi all, >> >> I'd like to do a few things with our swig generation and handling: >> >> * C

Re: [lldb-dev] swig generation

On Fri, Nov 13, 2015 at 10:24 AM, Todd Fiala wrote: > > > On Fri, Nov 13, 2015 at 9:43 AM, Zachary Turner > wrote: > >> On Fri, Nov 13, 2015 at 9:02 AM Todd Fiala via lldb-dev < >> lldb-dev@lists.llvm.org> wrote: >> >>> Hi all, >>> >

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 f

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 6:05 PM Jason Molenda

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 python > binding). > > T

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 swig Python bindings are >> generated and chec

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

Nothing concrete at the moment; however, it could be interesting to look at the clang community and see what could be done for llvm-based language implementations. The angle that I think would be interesting would be if we can generate bindings more effectively based on the in-depth understanding

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

> that comes out of python that comes out of swig, rather (i.e. the binding generation output). On Tue, Nov 17, 2015 at 8:03 PM, Todd Fiala wrote: > Nothing concrete at the moment; however, it could be interesting to look > at the clang community and see what could be done for llvm-based langua

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

Usage of static bindings for the prepare_bindings.py script went in here: r253448. Only Xcode provides the flag to use it. The commit description indicates how it works in this incarnation. Essentially it only uses the static Python binding if and only if a swig isn't specified or cannot be foun

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 of

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

> On OS X, it is a pain to get unless you install homebrew/macports/fink. On Linux, you'll need to do an apt-get or yum install. And I should add that installing home-brew (the most common way of picking up extra goodies, as I know I do it on home machines) is also one of the most common ways to p

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

Hi all, I've cleaned up our swig generation scripts as used by cmake and Xcode builds. They're working fine on Xcode, but I've only checked them on Ubuntu 14.04 as far as cmake builds go. The change to switch over to the cleaned-up script happened here: r253478 Probably the biggest place somet

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, but I've only checked the

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 10:32

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 people don't >> need to run autoconf just

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, it works for everyone. >>> >> >> Unless you can't get swig on

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 Turner >>> wrote: >>> Because even if it isn't perfect for e

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

On Wed, Nov 18, 2015 at 12:51 PM, Zachary Turner wrote: > (This is originally from a thread on lldb-commits, but it seems more > appropriate here, so I'm responding here. > > On Wed, Nov 18, 2015 at 12:47 PM Todd Fiala wrote: > >> BTW if you cook up something on the swig-as-a-service end that en

[lldb-dev] if you look at binding-generation-as-service element...

Hey Zachary, Please make sure to ping Greg Clayton, particularly if it does anything that would make the binding no longer be C-linkage-compatible. He can tell you all the bits we are counting on. I think the keys are: * we don't ever have there be vtables. * we never remove API surface area. *

Re: [lldb-dev] if you look at binding-generation-as-service element...

Sure. On Wed, Nov 18, 2015 at 1:09 PM, Zachary Turner wrote: > Can I send you a sample set of bindings generated by 3.x as a fail-fast > test? Try them out, see if anything breaks, etc? > > On Wed, Nov 18, 2015 at 1:07 PM Todd Fiala wrote: > >> Hey Zachary, >> >> Please make sure to ping Greg

[lldb-dev] bindings as service idea

Hey Zachary, I think the time pressure has gotten the better of me, so I want to apologize for getting snippy about the static bindings of late. I am confident we will get to a good solution for removing that dependency, but I can certainly wait for a solution (using an alternate approach in our

Re: [lldb-dev] if you look at binding-generation-as-service element...

Ah good got it. Thanks, somehow didn't see this earlier. Thanks! On Wed, Nov 18, 2015 at 1:27 PM, Zachary Turner wrote: > Google Drive is being bad right now. Hopefully this works better :-/ > > > > On Wed, Nov 18, 2015 at 1:20 PM Zachary Turner wrote: > >> Err, links aren't showing up for m

Re: [lldb-dev] bindings as service idea

On Wed, Nov 18, 2015 at 10:06 PM, Todd Fiala wrote: > Hey Zachary, > > I think the time pressure has gotten the better of me, so I want to > apologize for getting snippy about the static bindings of late. I am > confident we will get to a good solution for removing that dependency, but > I can c

Re: [lldb-dev] bindings as service idea

For the benefit of continuity in conversation, here is what you had to say about it before: > One possibility (which I mentioned to you offline, but I'll put it here for others to see) is that we make a swig bot which is hosted in the cloud much like our public build bots. We provide a Python scr

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

We're reviewing these. I've added the ones that I use or need for infrastructure. I've pinged everyone else internally and we'll be sure to update any others over today and tomorrow. -Todd On Wed, Nov 18, 2015 at 2:32 PM, Zachary Turner via lldb-dev < lldb-dev@lists.llvm.org> wrote: > I would

Re: [lldb-dev] bindings as service idea

On Thu, Nov 19, 2015 at 9:44 AM, Zachary Turner wrote: > Just to re-iterate, if we use the bindings as a service, then I envision > checking the bindings in. This addresses a lot of the potential pitfalls > you point out, such as the "oops, you can't hit the network, no build for > you" and the

Re: [lldb-dev] bindings as service idea

I'm out next week, but I can help if needed after that. Related to all this, you have mentioned a few times that there are newer swig features you want to use. Can you enumerate the features not present in 1.x but present in 3.x that you want to take advantage of, and what benefits they will brin

Re: [lldb-dev] bindings as service idea

Some other points we need to consider on the bindings-as-service idea: * The service should be exposed via secure connection (https/ssl/etc.) This might already be guaranteed on the Google end by virtue of the endpoint, but we'll want to make sure we can have a secure connection. (This will be a

Re: [lldb-dev] bindings as service idea

>> If so, does this mean everyone needs to generate a cert locally? Generally not - as long as the server is dishing out something over https, the server will be signed with a certificate that is going to be in the local OS's set of trusted root certificates (particularly if this is provided by Go

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

Yeah that would be awesome, and also would be a lot of work. Good luck! On Fri, Nov 20, 2015 at 10:37 AM, Zachary Turner via lldb-dev < lldb-dev@lists.llvm.org> wrote: > Seems reasonable. I will make a best effort to get as many of them as I > can. > > On Fri, Nov 20, 2015 at 10:34 AM Greg Cla

[lldb-dev] lldb-server/debugserver tests and debuginfo build type

Hi all, I think the vast majority of those likely aren't concerned with debug info format. Most of us are off next week, but when we get back I'll look into getting those to run without debuginfo variants except where needed. -- -Todd ___ lldb-dev mai

[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 to

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

s see which of the tests really are failing under load. So this is all likely for the best, with a small ramp-up time to while we "discover" which tests are hitting this. > cheers, > pl > Thanks! > > > > > > On 27 November 2015 at 18:58, Todd Fiala via ll

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

mode + threshold) to get it up and running, then add the test markers and the required opt-in mode that we'll default with per Pavel's comments. -Todd > > Sent from phone > On Nov 27, 2015 10:57 AM, "Todd Fiala via lldb-dev" < > lldb-dev@lists.llvm.org>

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 possib

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 would make sense to pu

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?) Alt

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, 20

[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 lldbsu

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 something like: > > time test/d

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 AM, Todd Fiala wrote:

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 support in llvm.org > lldb per our other th

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

11:04 AM, Zachary Turner 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 the summary is fixed-

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

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 the summary is fixed-width lined up nicely, which >>> may not sh

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

ion. > > On Wed, Dec 2, 2015 at 11:04 AM Zachary Turner 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> wr

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

. >> >> On Wed, Dec 2, 2015 at 11:04 AM Zachary Turner >> 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] static swig bindings and xcode workspace

I'll dig in more when I get to it, but yeah I like the concept for sure. On Wed, Dec 2, 2015 at 11:12 AM, Zachary Turner wrote: > Ahh, that's a bummer if true. Because `contrib` is a nice way to group > together all the things that all the things that have specific maintainers > and so everyone

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

15 at 11:04 AM Zachary Turner >> 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:

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

t;>>>>> `lldbsuite.test.formatters` package, looks for a class inside with a >>>>>> @result_formatter decorator, and instantiates that. >>>>>> >>>>>> This has the advantage of making the command line shorter *and* a >>>>

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

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 message descriptio

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

starting point. So you could instead write: >>>>>>> >>>>>>> test/dotest.py --results-formatter basic >>>>>>> >>>>>>> dotest then looks for a `basic.py` module in the >>>>>>> `lldbsuite.test.fo

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

es sense conceptually to group all of the different >>>>>>>>> result formatters under a subpackage called formatters. So right now >>>>>>>>> you've got lldbsuite.test.basic_results_formatter. >>>>>>>>>

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

rmatters under a subpackage called formatters. So right now >>>>>>>>> you've got lldbsuite.test.basic_results_formatter. >>>>>>>>> BasicResultsFormatter but it might make sense for this to be >>>>>>>>> lldbsuite.t

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

about how >>>>>>>>>> to more logically organize all the source files now that we have a >>>>>>>>>> package. So it makes sense conceptually to group all of the >>>>>>>>>> different >>>>>>>>>

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

>>>>>>>>>> -Todd >>>>>>>>>> >>>>>>>>>> On Wed, Dec 2, 2015 at 11:10 AM, Zachary Turner < >>>>>>>>>> ztur...@google.com> wrote: >>>>>>>>>> >&

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

r idea is >>>>>>>>>>>> better if >>>>>>>>>>>> everything is derived from a common base. To be honest you could >>>>>>>>>>>> even just >>>>>>>>>>>> gene

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

Wed, Dec 2, 2015 at 11:40 AM Zachary Turner < >>>>>>>>>>>> ztur...@google.com> wrote: >>>>>>>>>>>> >>>>>>>>>>>>> When I run this under Python 3 I get "A bytes object is used >>

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) >>> >> >> Part of the reason I included that is I've hit

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

just put one test case class in a file", and with a "test file base names must be unique" policy, I think we can even get away with "test_method_name (relative filename)" to identify the test method. That should be even shorter than what Zachary and I were discussing last

[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 Debugge

Re: [lldb-dev] LLDB and Swift

Thanks, Kamil! -Todd > On Dec 3, 2015, at 5:02 PM, Kamil Rytarowski 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

That seems reasonable. I'll work that in. -Todd > On Dec 3, 2015, at 4:55 PM, Zachary Turner wrote: > > It would also be nice if the summary statistics were printed after the list > of failing / errored tests. The reason is that it involves a fixed number of > lines to print the table, but t

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: > That seems reasonable.

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 lo

Re: [lldb-dev] LLDB/NetBSD test suite results as of 8 Dec 2015

Sounds like you're making some good progress, Kamil! -Todd On Mon, Dec 7, 2015 at 4:28 PM, Kamil Rytarowski via lldb-dev < lldb-dev@lists.llvm.org> wrote: > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA256 > > I ran the LLDB test suite of the LLDB-current version on NetBSD/amd64 > (v. 7.99.21).

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 th

[lldb-dev] BasicResultsFormatter - new test results summary

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 meet or exceed current requirements. I'd like to switch over to that by default. I'm depending on the test event system to be able to handle test met

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

nt is this is a no-op on the test runner. On Wed, Dec 9, 2015 at 8:02 AM, Tamas Berghammer wrote: > +Ying Chen > > Ying, what do we have to do on the build bot side to support a change in > the default test result summary formatter? > > On Wed, Dec 9, 2015 at 4:00 PM Todd Fial

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

t; > The intent is this is a no-op on the test runner. > > On Wed, Dec 9, 2015 at 8:02 AM, Tamas Berghammer > wrote: > >> +Ying Chen >> >> Ying, what do we have to do on the build bot side to support a change in >> the default test result summary format

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

that as a failing-style result). >> >> The intent is this is a no-op on the test runner. >> >> On Wed, Dec 9, 2015 at 8:02 AM, Tamas Berghammer >> wrote: >> >>> +Ying Chen >>> >>> Ying, what do we have to do on the build bot s

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

e lit script IIRC to > >>> parse that as a failing-style result). > >>> > >>> The intent is this is a no-op on the test runner. > >>> > >>> On Wed, Dec 9, 2015 at 8:02 AM, Tamas Berghammer < > tbergham...@google.com> > >>>

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

gt;>> details. Including, not using XPASS but rather UNEXPECTED SUCCESS for >> >>> unexpected successes. (The former would trigger the lit script IIRC >> to >> >>> parse that as a failing-style result). >> >>> >> >>> Th

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

gt; >>> That's a good point, Tamas. >>> >>> >>> >>> 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 >&g

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

bsuite/test/basic_results_formatter.py). >>>> >> >>>> >> -Todd >>>> >> >>>> >> On Wed, Dec 9, 2015 at 8:04 AM, Todd Fiala >>>> wrote: >>>> >>> >>>> >>> That's a good point,

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

entries (lines 275 - 290) >>>>> of >>>>> >> packages/Python/lldbsuite/test/basic_results_formatter.py). >>>>> >> >>>>> >> -Todd >>>>> >> >>>>> >> On Wed, Dec 9, 2015 at 8:04 A

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

are: >>>>>> >> >>>>>> >> FAIL >>>>>> >> ERROR >>>>>> >> UNEXPECTED SUCCESS >>>>>> >> TIMEOUT >>>>>> >> >>>>>> >> (These are the fourth

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

hink this is a noisy way to accomplish this, but it certainly >>>>>>> would >>>>>>> > validate if its working). >>>>>>> > >>>>>>> > -Todd >>>>>>> > >>>>>>> > O

Re: [lldb-dev] Benchmark tests

Hey Jason, Are you the benchmark user? -Todd On Wed, Dec 9, 2015 at 12:32 PM, Zachary Turner via lldb-dev < lldb-dev@lists.llvm.org> wrote: > Is anyone using the benchmark tests? None of the command line options >

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

On 9 December 2015 at 17:08, Todd Fiala >>>>>>>>>> wrote: >>>>>>>>>> > Here's what I can do. >>>>>>>>>> > >>>>>>>>>> > Put in the change (setting the default to use the new format). >&g

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

Sure, I can do that. Tamas, okay to give more detail on -v? I'll give it a shot to see what else comes out if we do that. -Todd On Thu, Dec 10, 2015 at 12:58 PM, Zachary Turner wrote: > > > On Thu, Dec 10, 2015 at 12:54 PM Todd Fiala wrote: > >> Hi Tamas, >> >> >> >> On Thu, Dec 10, 2015 at

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

Checked this in as r255310. Let me know if you find any issues with that, Tamas. You will need '-v' to enable it. Otherwise, it will just print the method name. -Todd On Thu, Dec 10, 2015 at 2:39 PM, Todd Fiala wrote: > Sure, I can do that. > > Tamas, okay to give more detail on -v? I'll gi

Re: [lldb-dev] Separating test runner and tests

I'm fine with the idea. FWIW the test events model will likely shift a bit, as it is currently a single sink, whereas I am likely to turn it into a test event filter chain shortly here. Formatters still make sense as they'll be the things at the end of the chain. Minor detail, result_formatter.p

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

On Fri, Dec 11, 2015 at 3:26 AM, Pavel Labath wrote: > Todd, I've had to disable the new result formatter as it was not > working with the expected timeout logic we have for the old one. The > old XTIMEOUT code is a massive hack and I will be extremely glad when > we get rid of it, but we can't k

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

Merging threads. > The concept is not there to protect against timeouts, which are caused by processes being too slow, for these we have been increasing timeouts where necessary. Okay, I see. If that's the intent, then expected timeout sounds reasonable. (My abhorrence was against the idea of u

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

> (btw, I haven't checked, is it possible to XFAIL crashes now? This currently doesn't work. We'd need a smarter rerun mechanism (something I do intend to do at some point), where we (1) know all the tests that should run from a given test file before any are run, and (2) when a timeout or exce

Re: [lldb-dev] Separating test runner and tests

I like it. On Fri, Dec 11, 2015 at 9:51 AM, Zachary Turner wrote: > Yea wasn't planning on doing this today, just throwing the idea out there. > > On Fri, Dec 11, 2015 at 9:35 AM Todd Fiala wrote: > >> I'm fine with the idea. >> >> FWIW the test events model will likely shift a bit, as it is cu

[lldb-dev] marking new summary output for expected timeouts

Hi Pavel, I'm going to adjust the new summary output for expected timeouts. I hope to do that in the next hour or less. I'll put that in and flip the default back on for using the new summary output. I'll do those two changes separately, so you can revert the flip back on to flip it back off if

Re: [lldb-dev] Separating test runner and tests

One thing I want to make sure we can do is have a sane way of storing and running tests that test the test execution engine. Those are tests that should not run as part of an "lldb test run". These are tests that maintainers of the test system run to make sure we're not breaking stuff when we to

Re: [lldb-dev] Separating test runner and tests

Unittest. Comes with Python. On Fri, Dec 11, 2015 at 11:07 AM, Zachary Turner wrote: > Presumably those tests use an entirely different, hand-rolled test running > infrastructure? > > On Fri, Dec 11, 2015 at 10:52 AM Todd Fiala wrote: > >> One thing I want to make sure we can do is have a sane

Re: [lldb-dev] Separating test runner and tests

It just requires running the test file as a python script. The runner is fired off like this: if __name__ == "__main__": unittest.main() which is typically added to the bottom of all test files so you can call it directly. -Todd On Fri, Dec 11, 2015 at 11:12 AM, Todd Fiala wrote: > Unitt

Re: [lldb-dev] Separating test runner and tests

The tests end up looking substantially similar to our lldb test suite tests, as they were based on unittest2, which is/was a relative of unittest that now lives in Python. The docs for unittest in python 2.x have generally been accurate for the unittest2 lib we use. At least, for the areas I use.

  1   2   3   4   >