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

2015-10-22 Thread Zachary Turner via lldb-dev 
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 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 unittest2 with unittest (again, after making sure that my
> expectations here are correct on this being valid).
>
> On Thu, Oct 22, 2015 at 11:33 AM, Zachary Turner 
> wrote:
>
>> 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 individual test and remove the if __name__ == "main" blocks.  After
>> that though it should be a fairly straightforward follow-up to remove it
>> entirely if anyone wants to.
>>
>> On Thu, Oct 22, 2015 at 11:30 AM Todd Fiala  wrote:
>>
>>> (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 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
> 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 lldb-dev <
> lldb-dev@lists.llvm.org> wrote:
>
>> 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 any use.
>>
>> If you prefer I leave it in that's less work for me since I have that
>> patch ready to go, but TBH I'd rather remove it if that's ok.
>>
>> On Thu, Oct 22, 2015 at 9:50 AM Zachary Turner 
>> wrote:
>>
>>> 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.py or something, but given the extra complexity and 
>>> the
>>> fact that it's running a totally different codepath, I wonder if the
>>> maintenance burden is worth it (I'm guessing no, since apparently it
>>> doesn't work well enough right now for anyone to use it)
>>>
>>> On Thu, Oct 22, 2015 at 9:47 AM Greg Clayton 
>>> wrote:
>>>
 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 <
 lldb-dev@lists.llvm.org> 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 Thu, Oct 22, 2015 at 2:55 AM Tamas Berghammer <
 tbergham...@google.com> wrote:
 > 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 have an objection against it.
 >
 > Tamas
 >
 > On Wed, Oct 21, 2015 at 8:57 PM Zachary Turner via lldb-dev <
 lldb-dev@lists.llvm.org> wrote:
 > TL;DR - Nobody has to do anything, this is just a heads up that a
 400+ file CL is coming.
 >
 > IANAL, but I've been told by one that I need to move all third
 party code used by LLDB to lldb/third_party.  Currently there is

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

2015-10-22 Thread Todd Fiala via lldb-dev 
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
> 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 lldb-dev <
> lldb-dev@lists.llvm.org> wrote:
>
>> 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 any use.
>>
>> If you prefer I leave it in that's less work for me since I have that
>> patch ready to go, but TBH I'd rather remove it if that's ok.
>>
>> On Thu, Oct 22, 2015 at 9:50 AM Zachary Turner 
>> wrote:
>>
>>> 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.py or something, but given the extra complexity and the
>>> fact that it's running a totally different codepath, I wonder if the
>>> maintenance burden is worth it (I'm guessing no, since apparently it
>>> doesn't work well enough right now for anyone to use it)
>>>
>>> On Thu, Oct 22, 2015 at 9:47 AM Greg Clayton  wrote:
>>>
 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 <
 lldb-dev@lists.llvm.org> 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 Thu, Oct 22, 2015 at 2:55 AM Tamas Berghammer <
 tbergham...@google.com> wrote:
 > 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 have an objection against it.
 >
 > Tamas
 >
 > On Wed, Oct 21, 2015 at 8:57 PM Zachary Turner via lldb-dev <
 lldb-dev@lists.llvm.org> wrote:
 > TL;DR - Nobody has to do anything, this is just a heads up that a
 400+ file CL is coming.
 >
 > IANAL, but I've been told by one that I need to move all third party
 code used by LLDB to lldb/third_party.  Currently there is only one thing
 there: the Python `six` module used for creating code that is portable
 across Python 2 and Python 3.
 >
 > The only other 2 instances that I'm aware of are pexpect and
 unittest2, which are under lldb/test.  I've got some patches locally which
 move pexpect and unittest2 to lldb/third_party.  I'll hold off on checking
 them in for a bit to give people a chance to see this message first,
 because otherwise you might be surprised when you see a CL with 400 files
 being checked in.
 >
 > Nobody will have to do anything after this CL goes in, and everything
 should continue to work exactly as it currently does.
 >
 > The main reason for the churn is that pretty much every single test
 in LLDB does something like this:
 >
 > import unittest2
 >
 > ...
 >
 > if __name__ == '__main__':
 > import atexit
 > lldb.SBDebugger.Initialize()
 > atexit.register(lambda: lldb.SBDebugger.Terminate())
 > unittest2.main()
 >
 > This worked when unittest2 was a subfolder of test, but not when it's
 somewhere else.  Since LLDB's python code is not organized into a standard
 python package and we treat the scripts like dotest etc as standalone
 scripts, the way I've made this work is by introducing a module called
 lldb_shared under test which, when you import it, fixes up sys.path to
 correctly add all the right locations under lldb/third_party.
 >
 > So, every single test now needs a line at the top to import
 lldb_shared.
 >
 > TBH I don't even know if we need this unittest2 stuff anymore (does
 anyone even use it?)  but even if the answer is no, then that still means
 changing every file to delete the import statement and the if __name__ ==
 '__main__': block.
 >
 > If there are no major concerns I plan to check this in by

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

2015-10-22 Thread Todd Fiala via lldb-dev 
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 unittest2 with unittest (again, after making sure that my
expectations here are correct on this being valid).

On Thu, Oct 22, 2015 at 11:33 AM, Zachary Turner  wrote:

> 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 individual test and remove the if __name__ == "main" blocks.  After
> that though it should be a fairly straightforward follow-up to remove it
> entirely if anyone wants to.
>
> On Thu, Oct 22, 2015 at 11:30 AM Todd Fiala  wrote:
>
>> (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 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
 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 lldb-dev <
 lldb-dev@lists.llvm.org> wrote:

> 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 any use.
>
> If you prefer I leave it in that's less work for me since I have that
> patch ready to go, but TBH I'd rather remove it if that's ok.
>
> On Thu, Oct 22, 2015 at 9:50 AM Zachary Turner 
> wrote:
>
>> 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.py or something, but given the extra complexity and the
>> fact that it's running a totally different codepath, I wonder if the
>> maintenance burden is worth it (I'm guessing no, since apparently it
>> doesn't work well enough right now for anyone to use it)
>>
>> On Thu, Oct 22, 2015 at 9:47 AM Greg Clayton 
>> wrote:
>>
>>> 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 <
>>> lldb-dev@lists.llvm.org> 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 Thu, Oct 22, 2015 at 2:55 AM Tamas Berghammer <
>>> tbergham...@google.com> wrote:
>>> > 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 have an objection against it.
>>> >
>>> > Tamas
>>> >
>>> > On Wed, Oct 21, 2015 at 8:57 PM Zachary Turner via lldb-dev <
>>> lldb-dev@lists.llvm.org> wrote:
>>> > TL;DR - Nobody has to do anything, this is just a heads up that a
>>> 400+ file CL is coming.
>>> >
>>> > IANAL, but I've been told by one that I need to move all third
>>> party code used by LLDB to lldb/third_party.  Currently there is only 
>>> one
>>> thing there: the Python `six` module used for creating code that is
>>> portable across Python 2 and Python 3.
>>> >
>>> > The only other 2 instances that I'm aware of are pexpect and
>>> unittest2, which are under lldb/test.  I've got some patches locally 
>>> which
>>> move pexpect and unittest2 to lldb/third_party.  I'll hold off on 
>>> checking
>>> them in

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

2015-10-22 Thread Zachary Turner via lldb-dev 
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 individual test and remove the if __name__ == "main" blocks.  After
that though it should be a fairly straightforward follow-up to remove it
entirely if anyone wants to.

On Thu, Oct 22, 2015 at 11:30 AM Todd Fiala  wrote:

> (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 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
>>> 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 lldb-dev <
>>> lldb-dev@lists.llvm.org> wrote:
>>>
 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 any use.

 If you prefer I leave it in that's less work for me since I have that
 patch ready to go, but TBH I'd rather remove it if that's ok.

 On Thu, Oct 22, 2015 at 9:50 AM Zachary Turner 
 wrote:

> 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.py or something, but given the extra complexity and the
> fact that it's running a totally different codepath, I wonder if the
> maintenance burden is worth it (I'm guessing no, since apparently it
> doesn't work well enough right now for anyone to use it)
>
> On Thu, Oct 22, 2015 at 9:47 AM Greg Clayton 
> wrote:
>
>> 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 <
>> lldb-dev@lists.llvm.org> 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 Thu, Oct 22, 2015 at 2:55 AM Tamas Berghammer <
>> tbergham...@google.com> wrote:
>> > 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 have an objection against it.
>> >
>> > Tamas
>> >
>> > On Wed, Oct 21, 2015 at 8:57 PM Zachary Turner via lldb-dev <
>> lldb-dev@lists.llvm.org> wrote:
>> > TL;DR - Nobody has to do anything, this is just a heads up that a
>> 400+ file CL is coming.
>> >
>> > IANAL, but I've been told by one that I need to move all third
>> party code used by LLDB to lldb/third_party.  Currently there is only one
>> thing there: the Python `six` module used for creating code that is
>> portable across Python 2 and Python 3.
>> >
>> > The only other 2 instances that I'm aware of are pexpect and
>> unittest2, which are under lldb/test.  I've got some patches locally 
>> which
>> move pexpect and unittest2 to lldb/third_party.  I'll hold off on 
>> checking
>> them in for a bit to give people a chance to see this message first,
>> because otherwise you might be surprised when you see a CL with 400 files
>> being checked in.
>> >
>> > Nobody will have to do anything after this CL goes in, and
>> everything should continue to work exactly as it currently does.
>> >
>> > The main reason for the churn is that pretty much every single test
>> in LLDB does something like this:
>> >
>> > import unittest2
>> >
>> > ...
>> >
>> > if __name__ == '__main__':
>> > import atexit
>> >

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

2015-10-22 Thread Greg Clayton via lldb-dev 
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 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 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 have an objection 
> against it.
> 
> Tamas
> 
> On Wed, Oct 21, 2015 at 8:57 PM Zachary Turner via lldb-dev 
>  wrote:
> TL;DR - Nobody has to do anything, this is just a heads up that a 400+ file 
> CL is coming.
> 
> IANAL, but I've been told by one that I need to move all third party code 
> used by LLDB to lldb/third_party.  Currently there is only one thing there: 
> the Python `six` module used for creating code that is portable across Python 
> 2 and Python 3.
> 
> The only other 2 instances that I'm aware of are pexpect and unittest2, which 
> are under lldb/test.  I've got some patches locally which move pexpect and 
> unittest2 to lldb/third_party.  I'll hold off on checking them in for a bit 
> to give people a chance to see this message first, because otherwise you 
> might be surprised when you see a CL with 400 files being checked in.
> 
> Nobody will have to do anything after this CL goes in, and everything should 
> continue to work exactly as it currently does.
> 
> The main reason for the churn is that pretty much every single test in LLDB 
> does something like this:
> 
> import unittest2
> 
> ...
> 
> if __name__ == '__main__':
> import atexit
> lldb.SBDebugger.Initialize()
> atexit.register(lambda: lldb.SBDebugger.Terminate())
> unittest2.main()
> 
> This worked when unittest2 was a subfolder of test, but not when it's 
> somewhere else.  Since LLDB's python code is not organized into a standard 
> python package and we treat the scripts like dotest etc as standalone 
> scripts, the way I've made this work is by introducing a module called 
> lldb_shared under test which, when you import it, fixes up sys.path to 
> correctly add all the right locations under lldb/third_party.
> 
> So, every single test now needs a line at the top to import lldb_shared.  
> 
> TBH I don't even know if we need this unittest2 stuff anymore (does anyone 
> even use it?)  but even if the answer is no, then that still means changing 
> every file to delete the import statement and the if __name__ == '__main__': 
> block.
> 
> If there are no major concerns I plan to check this in by the end of the day, 
> or tomorrow.
> ___
> lldb-dev mailing list
> lldb-dev@lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
> ___
> lldb-dev mailing list
> lldb-dev@lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev

___
lldb-dev mailing list
lldb-dev@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev

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

2015-10-22 Thread Zachary Turner via lldb-dev 
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 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 have an objection against it.
>
> Tamas
>
> On Wed, Oct 21, 2015 at 8:57 PM Zachary Turner via lldb-dev <
> lldb-dev@lists.llvm.org> wrote:
>
>> *TL;DR - Nobody has to do anything, this is just a heads up that a 400+
>> file CL is coming.*
>>
>> IANAL, but I've been told by one that I need to move all third party code
>> used by LLDB to lldb/third_party.  Currently there is only one thing there:
>> the Python `six` module used for creating code that is portable across
>> Python 2 and Python 3.
>>
>> The only other 2 instances that I'm aware of are pexpect and unittest2,
>> which are under lldb/test.  I've got some patches locally which move
>> pexpect and unittest2 to lldb/third_party.  I'll hold off on checking them
>> in for a bit to give people a chance to see this message first, because
>> otherwise you might be surprised when you see a CL with 400 files being
>> checked in.
>>
>> Nobody will have to do anything after this CL goes in, and everything
>> should continue to work exactly as it currently does.
>>
>> The main reason for the churn is that pretty much every single test in
>> LLDB does something like this:
>>
>> *import unittest2*
>>
>> ...
>>
>> if __name__ == '__main__':
>> import atexit
>> lldb.SBDebugger.Initialize()
>> atexit.register(lambda: lldb.SBDebugger.Terminate())
>> *unittest2.main()*
>>
>> This worked when unittest2 was a subfolder of test, but not when it's
>> somewhere else.  Since LLDB's python code is not organized into a standard
>> python package and we treat the scripts like dotest etc as standalone
>> scripts, the way I've made this work is by introducing a module called 
>> *lldb_shared
>> *under test which, when you import it, fixes up sys.path to correctly
>> add all the right locations under lldb/third_party.
>>
>> So, every single test now needs a line at the top to import lldb_shared.
>>
>> TBH I don't even know if we need this unittest2 stuff anymore (does
>> anyone even use it?)  but even if the answer is no, then that still means
>> changing every file to delete the import statement and the if __name__ ==
>> '__main__': block.
>>
>> If there are no major concerns I plan to check this in by the end of the
>> day, or tomorrow.
>>
> ___
>> lldb-dev mailing list
>> lldb-dev@lists.llvm.org
>> http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
>>
>
___
lldb-dev mailing list
lldb-dev@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev

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

2015-10-22 Thread Zachary Turner via lldb-dev 
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 any use.

If you prefer I leave it in that's less work for me since I have that patch
ready to go, but TBH I'd rather remove it if that's ok.

On Thu, Oct 22, 2015 at 9:50 AM Zachary Turner  wrote:

> 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.py or something, but given the extra complexity and the
> fact that it's running a totally different codepath, I wonder if the
> maintenance burden is worth it (I'm guessing no, since apparently it
> doesn't work well enough right now for anyone to use it)
>
> On Thu, Oct 22, 2015 at 9:47 AM Greg Clayton  wrote:
>
>> 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 <
>> lldb-dev@lists.llvm.org> 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 Thu, Oct 22, 2015 at 2:55 AM Tamas Berghammer <
>> tbergham...@google.com> wrote:
>> > 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 have an objection against it.
>> >
>> > Tamas
>> >
>> > On Wed, Oct 21, 2015 at 8:57 PM Zachary Turner via lldb-dev <
>> lldb-dev@lists.llvm.org> wrote:
>> > TL;DR - Nobody has to do anything, this is just a heads up that a 400+
>> file CL is coming.
>> >
>> > IANAL, but I've been told by one that I need to move all third party
>> code used by LLDB to lldb/third_party.  Currently there is only one thing
>> there: the Python `six` module used for creating code that is portable
>> across Python 2 and Python 3.
>> >
>> > The only other 2 instances that I'm aware of are pexpect and unittest2,
>> which are under lldb/test.  I've got some patches locally which move
>> pexpect and unittest2 to lldb/third_party.  I'll hold off on checking them
>> in for a bit to give people a chance to see this message first, because
>> otherwise you might be surprised when you see a CL with 400 files being
>> checked in.
>> >
>> > Nobody will have to do anything after this CL goes in, and everything
>> should continue to work exactly as it currently does.
>> >
>> > The main reason for the churn is that pretty much every single test in
>> LLDB does something like this:
>> >
>> > import unittest2
>> >
>> > ...
>> >
>> > if __name__ == '__main__':
>> > import atexit
>> > lldb.SBDebugger.Initialize()
>> > atexit.register(lambda: lldb.SBDebugger.Terminate())
>> > unittest2.main()
>> >
>> > This worked when unittest2 was a subfolder of test, but not when it's
>> somewhere else.  Since LLDB's python code is not organized into a standard
>> python package and we treat the scripts like dotest etc as standalone
>> scripts, the way I've made this work is by introducing a module called
>> lldb_shared under test which, when you import it, fixes up sys.path to
>> correctly add all the right locations under lldb/third_party.
>> >
>> > So, every single test now needs a line at the top to import lldb_shared.
>> >
>> > TBH I don't even know if we need this unittest2 stuff anymore (does
>> anyone even use it?)  but even if the answer is no, then that still means
>> changing every file to delete the import statement and the if __name__ ==
>> '__main__': block.
>> >
>> > If there are no major concerns I plan to check this in by the end of
>> the day, or tomorrow.
>> > ___
>> > lldb-dev mailing list
>> > lldb-dev@lists.llvm.org
>> > http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
>> > ___
>> > lldb-dev mailing list
>> > lldb-dev@lists.llvm.org
>> > http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
>>
>>
___
lldb-dev mailing list
lldb-dev@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev