Re: [lldb-dev] download page for LLDB at llvm.org

Okay, thanks for weighing in, Mehdi. I'll reach out to the LLVM side and see how they handle the builds, then report back on options there. -Todd On Thu, Nov 10, 2016 at 9:18 AM, Mehdi Amini <mehdi.am...@apple.com> wrote: > > On Nov 10, 2016, at 9:14 AM, Todd Fiala via lldb-dev

[lldb-dev] macOS Xcode test bot back in shape

Hello, all! I just wanted to update everyone on the state of the Green Dragon Xcode build of LLDB. That builder has had a rocky few months. The hardware, OS and Xcode version all were updated simultaneously, and in the process, several aspects of the test bot's logic were broken. We all

Re: [lldb-dev] LLVM_PRETTY_FUNCTION in RNBRemote.cpp?

We don't link in LLVM in debugserver, so this part probably just needs to go back to what it was before. On Tue, Aug 9, 2016 at 5:57 PM, Todd Fiala wrote: > (Did you do a global search and replace, and maybe we just need a new > include here?) > > On Tue, Aug 9, 2016 at

Re: [lldb-dev] LLVM_PRETTY_FUNCTION in RNBRemote.cpp?

(Did you do a global search and replace, and maybe we just need a new include here?) On Tue, Aug 9, 2016 at 5:55 PM, Todd Fiala wrote: > Hi Zachary, > > I've got the latest LLVM and clang updated, and I'm trying to build > debugserver in svn trunk. It's failing on these

[lldb-dev] Ubuntu buildbot timing after -gmodules

Hi Pavel, FYI - I took a look at the ubuntu 14.04 x86_64 cmake buildbot before and after the -gmodules change landed, and it looks like the total runtime is up about 12%. (Now ~28 minutes, before ~25 minutes). Doesn't seem too bad for the scope of increased coverage. -- -Todd

Re: [lldb-dev] Green Dragon LLDB Xcode build update: TSAN support

One more update: The Green Dragon OS X LLDB builder now actually runs the gtests instead of just building them. The gtests run as a phase right before the Python test suite. A non-zero value returning from the gtests will cause the OS X LLDB build to fail. Right now, tracking down the cause of

[lldb-dev] Green Dragon LLDB Xcode build update: TSAN support

Hi all, I've made a minor change to the Green Dragon LLDB OS X Xcode build located here: http://lab.llvm.org:8080/green/job/LLDB/ 1. Previously, the python test run used the default C/C++ compiler to build test inferiors. Now it uses the just-built clang/clang++ to build test inferiors. At

Re: [lldb-dev] more Green Dragon OS X buildbot/testbot tweaks

I have the OS X testbot fail nag emails going out properly now. Thanks! -Todd On Tue, Feb 2, 2016 at 7:58 AM, Todd Fiala wrote: > Hi all, > > I don't have this perfectly configured yet. It is happily running builds > and running test suites. However, while it reports

[lldb-dev] more Green Dragon OS X buildbot/testbot tweaks

Hi all, I don't have this perfectly configured yet. It is happily running builds and running test suites. However, while it reports test failures just fine, it doesn't fail the build on a test failure. I'm tracking down why now. I have just adjusted something so that we get an email on test

Re: [lldb-dev] Fixing OS X Xcode build

This is all fixed up by r259028. Change comments for r259027 contain some changes to the build requirements for Xcode OS X builds. These boil down to essentially: * OS X 10.9 is the minimum deployment version now, up from 10.8. This is driven by the LLVM/clang cmake-based build. * Cmake is now

Re: [lldb-dev] Patch to fix REPL for ARMv7 & ARMv6 on linux

Hi Pavel, Will is trying to get this working downstream of here IIRC. Greg, can you have a look and see what you think of the patch? (Also see Pavel's comments). Thanks! -Todd On Wed, Jan 27, 2016 at 1:28 AM, Omair Javaid via lldb-dev < lldb-dev@lists.llvm.org> wrote: > Hi Will, > > I dont

[lldb-dev] Fixing OS X Xcode build

Hi all, At the current moment the OS X Xcode build is broken. I'll be working on fixing it today. As has been discussed in the past, post llvm/clang-3.8 the configure/automake system was getting stripped out of LLVM and clang. The OS X Xcode build has a legacy step in it that still uses the

Re: [lldb-dev] something just toasted the test suite on OS X

>>>> couple helper routes to go in either the "to unicode" or the "to bytes" >>>>>>>> direction. It basically looks at the type of the string/bytes you >>>>>>>> give it, >>>>>>>> and makes sure it b

Re: [lldb-dev] something just toasted the test suite on OS X

te: >>>>>> >>>>>>> I'm also not sure why Linux isn't failing. Looking at the >>>>>>> documentation for io.write object, i see this: >>>>>>> >>>>>>> write(*s*) >>>>>>> <https://do

Re: [lldb-dev] something just toasted the test suite on OS X

ngle call to print. >> >> On Mon, Jan 25, 2016 at 8:54 PM Zachary Turner <ztur...@google.com> >> wrote: >> >>> sorry, yea I stuck around for a while after that patch waiting for >>> emails, but nothing came through. Please revert in the meantime, I'll

Re: [lldb-dev] something just toasted the test suite on OS X

Well our whole test suite just stopped running, so yes. On Mon, Jan 25, 2016 at 6:58 PM, Enrico Granata <egran...@apple.com> wrote: > > On Jan 25, 2016, at 6:48 PM, Todd Fiala via lldb-dev < > lldb-dev@lists.llvm.org> wrote: > > Not sure exactly what it is, but al

Re: [lldb-dev] something just toasted the test suite on OS X

tuck around for a while after that patch waiting for >> emails, but nothing came through. Please revert in the meantime, I'll work >> on a fix tomorrow. >> >> On Mon, Jan 25, 2016 at 8:52 PM Todd Fiala via lldb-dev < >> lldb-dev@lists.llvm.org> wrote: >> &

Re: [lldb-dev] something just toasted the test suite on OS X

, Todd Fiala <todd.fi...@gmail.com> wrote: > Well our whole test suite just stopped running, so yes. > > On Mon, Jan 25, 2016 at 6:58 PM, Enrico Granata <egran...@apple.com> > wrote: > >> >> On Jan 25, 2016, at 6:48 PM, Todd Fiala via lldb-dev < >>

Re: [lldb-dev] something just toasted the test suite on OS X

nothing came through. Please revert in the meantime, I'll work on a > fix tomorrow. > > On Mon, Jan 25, 2016 at 8:52 PM Todd Fiala via lldb-dev < > lldb-dev@lists.llvm.org> wrote: > >> I think I see what happened w/r/t why no emails when out when the build >> went heavy

[lldb-dev] Ubuntu version-based fail/skip

Hey all, What do you think about having some kind of way of marking the (in this case, specifically) Ubuntu distribution for fail/skip test decorators? I've had a few cases where I've needed to mark tests failing on for Ubuntu where it really was only a particular release of an Ubuntu

[lldb-dev] LLDB OS X buildbot/testbot details

Hi all, The llvm.org Green Dragon (i.e. Jenkins-based) LLDB OS X buildbot/testbot has received some improvements today. The Jenkins build now uses the xUnit plugin to process xUnit-based test suite results, which are displayed more usefully on the "build and test" page here

Re: [lldb-dev] clang-format now supports return type on separate line

t; >> Kate Stone k8st...@apple.com >>  Xcode Runtime Analysis Tools >> >> On Jan 21, 2016, at 9:46 PM, Todd Fiala via lldb-dev < >> lldb-dev@lists.llvm.org> wrote: >> >> Okay, sounds like a reasonable thing to try. We can always review it if >> i

Re: [lldb-dev] LLDB test questions

Hi Ted! I hope you don't mind - I'm going to CC lldb-dev since there is some useful general info in here for others who are getting started with the test system. (And others can fact-check anything I may gloss over here). On Thu, Jan 21, 2016 at 2:00 PM, Ted Woodward

Re: [lldb-dev] clang-format now supports return type on separate line

Glad to see clang-format getting some improvements. On Thu, Jan 7, 2016 at 10:30 AM, Zachary Turner wrote: > As far as I'm aware, this is the last major incompatibility between LLDB's > style and clang-format's feature set. > > I would appreciate it if more people could

[lldb-dev] Holiday time

Hi all, I just wanted to send out a note on behalf of the Apple LLDB team noting that we'll be off for the holidays, coming back the week of Jan 04. Please keep that in mind when looking for responses from us. Happy Holidays! -- -Todd ___ lldb-dev

Re: [lldb-dev] [Bug 25896] New: Hide stack frames from specific source files

Sounds like you almost want the ability to do a backtrace projection. At one point I wanted this for cross C++/Java frames, but I haven't worked on that problem in some time. Android folks - did we ever add anything to support hiding some of the trampolines or other call sites involved in the

Re: [lldb-dev] building on mac

> Are the Xcode scripts using the llvm configure build? If so they will > need to be changed to the CMake build sooner or later, because the > configure build is going away in the near future. > > On Thu, Dec 17, 2015 at 3:18 PM Todd Fiala via lldb-dev < > lldb-dev@lists

Re: [lldb-dev] turning on tests for OS X llvm.org Green Dragon builder

Hi all, This is complete. We now have OS X running the tests (both gtest and Python tests) at the end of the build phase on the LLVM Green Dragon OS X build. This build: http://lab.llvm.org:8080/green/view/LLDB/job/LLDB/15459/ is the first build where I got everything working. It already

Re: [lldb-dev] turning on tests for OS X llvm.org Green Dragon builder

Still in progress. I've got the tests running, but I've still got some configuration issues to work out to get them running cleanly. On Fri, Dec 18, 2015 at 12:48 PM, Todd Fiala wrote: > Hi all, > > I'm working on turning this on soon here (sometime this afternoon). It

Re: [lldb-dev] building on mac

gt; >> wrote: >> >>> Are the Xcode scripts using the llvm configure build? If so they will >>> need to be changed to the CMake build sooner or later, because the >>> configure build is going away in the near future. >>> >>> On Thu, Dec 17, 2015 at

Re: [lldb-dev] mind if I try allowing reruns on arm/aarch64?

(And, as an aside, I may just nuke the serial test runner anyway, since we can do it with a multi-worker runner with a single worker just fine, and reduce the code size --- I really don't see a good reason to keep the serial test runner strategy anymore except for a purely theoretical sense). On

Re: [lldb-dev] mind if I try allowing reruns on arm/aarch64?

Excellent. I'll try this in the afternoon. I need to run out now but I'll check in what we discussed later on when I get back. Thanks! On Thu, Dec 17, 2015 at 10:51 AM, Ying Chen wrote: > Yes, you could use android builder to run that experiment. > Please watch test 7 of

Re: [lldb-dev] building on mac

Ah. Okay, this might be the llvm/clang build script that Xcode uses as an llvm/clang build step. That's going to need to be updated if it is using configure (for the reasons I mentioned above). So it sounds like some part of llvm or clang may be sniffing and finding some part of ocaml, and

Re: [lldb-dev] mind if I try allowing reruns on arm/aarch64?

Hi Ying, I just put this change in that reverted the aarch64 and arm removal from test-rerun eligibility: r255935. I'll watch this builder now and see what happens. If it hangs on reruns, I'll revert r255935. Thanks! -Todd

Re: [lldb-dev] building on mac

We definitely should not be requiring ocaml :-) Are you using a configure-based build? If so, can you switch over to using cmake and see if you see that same issue? We pretty much don't maintain the configure build, and it is getting stripped from llvm and clang in the next version of them

[lldb-dev] expected timeouts and reruns

Hi all, If you happen to use --rerun-all-issues to turn on test rerunning (via single worker thread) for any failed issue, one thing to be aware of is that expected timeouts that do time out will not be rerun. They are not eligible for rerun (at least as of r255641) since they wouldn't cause the

Re: [lldb-dev] test rerun phase is in

android/builds/4305/steps/test7/logs/stdio > > Thanks, > Ying > > On Mon, Dec 14, 2015 at 4:52 PM, Todd Fiala via lldb-dev < > lldb-dev@lists.llvm.org> wrote: > >> And, btw, this shows the rerun logic working (via the --rerun-all-issues >> flag): >> >&g

Re: [lldb-dev] Problem with dotest_channels.py

emote host >> [D:\Python_for_lldb\x86\lib\asyncore.py|read|83] >> [D:\Python_for_lldb\x86\lib\asyncore.py|handle_read_event|449] >> [D:\src\llvm\llvm\tools\lldb\packages\Python\lldbsuite\test\dotest_channels.py|handle_read|137] >> [D:\Python_for_lldb\x86\lib\asyncore.py|

Re: [lldb-dev] test rerun phase is in

output display due to the recursive >>>>>>>>>> taking of a >>>>>>>>>> lock on a lock that was not recursive-enabled. While I would have >>>>>>>>>> expected >>>>>>>>>> to see th

Re: [lldb-dev] test rerun phase is in

builder here is >>>>>>>>> using >>>>>>>>> when I was testing earlier, it's possible somehow that we're hitting >>>>>>>>> a path >>>>>>>>> here that is attempting to recursively take a loc

Re: [lldb-dev] test rerun phase is in

The full set that are blowing up are: = Issue Details = FAIL: test_expr_stripped_dwarf (lang/objc/hidden-ivars/TestHiddenIvars.py) FAIL: test_frame_variable_stripped_dwarf (lang/objc/hidden-ivars/TestHiddenIvars.py) FAIL: test_typedef_dsym (lang/c/typedef/Testtypedef.py)

Re: [lldb-dev] test rerun phase is in

isn't quite right there). >>> >>> On Mon, Dec 14, 2015 at 4:39 PM, Siva Chandra <sivachan...@google.com> >>> wrote: >>> >>>> Can you try again after taking my change at r255584? >>>> >>>> On Mon, Dec 14, 2015 at 4:31 PM, Todd Fia

Re: [lldb-dev] test rerun phase is in

t; >> wrote: >> >>> Can you try again after taking my change at r255584? >>> >>> On Mon, Dec 14, 2015 at 4:31 PM, Todd Fiala via lldb-dev >>> <lldb-dev@lists.llvm.org> wrote: >>> > I'm having some of these blow up. >>> > >>

Re: [lldb-dev] Problem with dotest_channels.py

Hey Zachary, I just put in: r255581 which should hopefully: (1) catch the exception you see there, (2) handle it gracefully in the common and to-be-expected case of the test inferior going down hard, and (3) print out an error if anything else unexpected is happening here. Let me know if you

Re: [lldb-dev] test rerun phase is in

ething isn't quite right there). > > On Mon, Dec 14, 2015 at 4:39 PM, Siva Chandra <sivachan...@google.com> > wrote: > >> Can you try again after taking my change at r255584? >> >> On Mon, Dec 14, 2015 at 4:31 PM, Todd Fiala via lldb-dev >> <lldb-dev@lis

Re: [lldb-dev] test rerun phase is in

I'm having some of these blow up. In the case of test/lang/c/typedef/Testtypedef.py, it looks like some of the @expected decorators were changed a bit, and perhaps they are not pound for pound the same. For example, this test used to really be marked XFAIL (via an expectedFailureClang

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

Oh yeah, that's fine. I won't take that code out. Hmm at least some of the builds went through this weekend, I made a number of changes Saturday morning (US Pacific time) that I saw go through the Ubuntu 14.04 cmake bot. On Mon, Dec 14, 2015 at 6:29 AM, Pavel Labath wrote:

[lldb-dev] test rerun phase is in

Hi all, I just put in the single-worker, low-load, follow-up test run pass in r255543. Most of the work for it went in late last week, this just mostly flips it on. The feature works like this: * First test phase works as before: run all tests using whatever level of concurrency is normally

[lldb-dev] debug info test failures

Hi all, I'm seeing locally on OS X the same build failures that I'm seeing on the ubuntu 14.04 cmake builedbot: ERROR: TestWithLimitDebugInfo.TestWithLimitDebugInfo.test_limit_debug_info_dwarf (lang/cpp/limit-debug-info/TestWithLimitDebugInfo.py) ERROR:

Re: [lldb-dev] debug info test failures

I temporarily skipped these tests on Darwin and Linux here: r255549 I'll file a bug in a moment... On Mon, Dec 14, 2015 at 1:42 PM, Todd Fiala wrote: > Hi all, > > I'm seeing locally on OS X the same build failures that I'm seeing on the > ubuntu 14.04 cmake builedbot: >

Re: [lldb-dev] test rerun phase is in

Ah yes I see. Thanks, Ying (and Siva! Saw your comments too). On Mon, Dec 14, 2015 at 2:34 PM, Ying Chen wrote: > Seems this is the first build that fails, and it only has one CL 255542 > . > >

Re: [lldb-dev] debug info test failures

2015 at 1:53 PM Todd Fiala via lldb-dev < > lldb-dev@lists.llvm.org> wrote: > >> I temporarily skipped these tests on Darwin and Linux here: >> r255549 >> >> I'll file a bug in a moment... >> >> On Mon, Dec 14, 2015 at 1:42 PM, Todd Fiala <todd.fi...

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

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

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

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

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

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

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

I think we can do this, and I'd like us to do this unless it's proven to break something we're not aware of. I think you did some research on this after we discussed last, but something (maybe in the decorators) didn't just work. Was that right? On Fri, Dec 11, 2015 at 11:18 AM, Zachary Turner

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

Okay. Sounds like something we can work around one way or another, either by introducing the correct exception name for unittest, or introducing our own if we need to do so. On Fri, Dec 11, 2015 at 11:22 AM, Zachary Turner wrote: > If I remember correctly it was in the way

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

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

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

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

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

us 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, Tod

[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

[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

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

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

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

  1   2   >