Okay, will do.
On Thu, Oct 22, 2015 at 12:56 PM, Zachary Turner wrote:
> This is going in right now. As it is a fairly large change, it wouldn't
> surprise me if someone encounters an issue. I tested this everywhere I can
> and it seems fine, so please let me know if anyone encounters anything
This is going in right now. As it is a fairly large change, it wouldn't
surprise me if someone encounters an issue. I tested this everywhere I can
and it seems fine, so please let me know if anyone encounters anything.
On Thu, Oct 22, 2015 at 11:39 AM Todd Fiala wrote:
> Yeah I think the bigge
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 un
Cool! I probably won't delete it from the repo entirely, because that
entails mucking with the command line options of dotest to remove any
related options, and any initialization code in dotest.py or TestBase
subclasses related to unittest2. For now I'll just delete the imports from
each individ
(I was eventually going to do this at some point after I verified it was
indeed true). It should just be called unittest in a stock distribution.
On Thu, Oct 22, 2015 at 11:29 AM, Todd Fiala wrote:
> We could also then remove unittest2 from inclusion in the lldb repo.
>
>
> On Thu, Oct 22, 2015
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 2.[6,7]?. Everyone should
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 2.[6,7]?. Everyone should
have a unitest included that is effectively what we use as unittest2.
-Todd
On Thu, Oct 22, 2015 at 10:05 AM, Zachary Turner via
I plan to put this in today. Greg, should I just go ahead and delete all
the unittest2 stuff entirely? TBH I'm all for anything that reduces the
complexity of the test suite. It's got a couple hundred options that
nobody uses, seems like we should start whittling away at stuff that
doesn't get a
You can get pretty much the same effect though by just running dotest and
passing it the folder that the .py file is in. Then it only runs tests in
that folder. You can specify the filename too if you want to limit it to
one name. Sure, it's a few keystrokes less to just type
TestMultithreaded.
I believe it would import lldb correctly. I don't tend to run the tests
individually, but if it did work, I would use it more.
> On Oct 22, 2015, at 9:26 AM, Zachary Turner via lldb-dev
> wrote:
>
> Todd, Greg, can you guys confirm this is true? The import lldb would
> succeed if someone ha
+todd and greg
On Thu, Oct 22, 2015 at 9:26 AM Zachary Turner wrote:
> Todd, Greg, can you guys confirm this is true? The import lldb would
> succeed if someone had their PYTHONPATH set up just right, but if really
> none of us care about it, I'm with Tamas in that I'd rather remove it.
>
> On
Todd, Greg, can you guys confirm this is true? The import lldb would
succeed if someone had their PYTHONPATH set up just right, but if really
none of us care about it, I'm with Tamas in that I'd rather remove it.
On Thu, Oct 22, 2015 at 2:55 AM Tamas Berghammer
wrote:
> Hi Zach,
>
> I think no
Hi Zach,
I think nobody is using the "if __name__ == '__main__'" block as executing
a test file directly isn't working at the moment (the "import lldb" command
fails). If you plan to change all test file then I would prefer to remove
the reference to unittest2 from them for simplicity if nobody ha
13 matches
Mail list logo
