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
I don't think we should automatically print a backtrace after the target
create; just the stop reason and source (or disassembly) listing, ideally only
for the crashed thread.
Conceptually, we're loading the core file and attaching, and get a stopped
state. The state should be completely read-o
Sounds good, looks good then.
> On Dec 8, 2015, at 11:09 AM, Zachary Turner wrote:
>
> One advantage of this approach is that it makes the options available to the
> entire test suite. Even if we have no transferring going on, and we get
> argparse to return us a perfectly organized structure
One advantage of this approach is that it makes the options available to
the entire test suite. Even if we have no transferring going on, and we
get argparse to return us a perfectly organized structure with everything
in the right format, in order to make all the options accessible to the
rest of
There's no way to avoid doing a transfer out of the options dictionary at
some level, because it's not a straight transfer. There's a ton of
post-processing that gets done on the options dictionary in order to
convert the raw options into a useful format.
That might be solvable with more advanced
Do we not want to have an "options" global variable in this module that
contains everything instead of having separate global variables in this file?
The idea would be that you could assign directly when parsing arguments:
(configuration.options, args) = parser.parse_args(sys.argv[1:])
Its OK i
Hi Greg,
Take a look at dotest.py next time you get some free time and let me know
what you think. There should be no more globals. Everything that used to
be a global is now stored in its own module `configuration.py`, and
everything in `configuration.py` can be referenced from everywhere in th
On 7 December 2015 at 19:28, Kamil Rytarowski via lldb-dev
wrote:
>
> I ran the LLDB test suite of the LLDB-current version on NetBSD/amd64
> (v. 7.99.21).
>
> The results are as follows:
>
> 415 out of 415 test suites processed - TestRecursiveTypes.py
>
> Ran 415 test suites (266 failed) (64.0963
