[lldb-dev] LLDB Evolution

Fri Aug 19 01:35:45 PDT 2016

I am fine with reformatting the python code as well.

BTW, does anyone know if autopep8 (or something similar) has some
editor or git integration, in a similar way that clang-format does? It
would be great if we could make sure any new code added after that
still follows the conventions.

cheers,
pl

On 18 August 2016 at 19:15, Kate Stone <k8stone at apple.com> wrote:
> If there’s consensus on a reasonable automated formatting solution for
> Python then I’m fine with going ahead and doing so at the same time.  The
> PEP-8 standard would leave Python code with 4-space indentation, and impart
> a consistent look to our code.  Earlier this week I verified that our
> current repository builds and passes tests cleanly under the following
> conditions:
>
> LLVM-style default .clang-format specified at the root of the tree:
>
>
> BasedOnStyle: LLVM
>
> Formatting disabled using .clang-format in packages/Python/lldbsuite.  It’s
> not just a matter of comment style and location driving tests.  The tests
> themselves are exercising debugging functionality driven by debug
> information line tables.  Debugging behavior can and will change when using
> line-oriented requests (breakpoint on a particular line, step over a
> particular line, etc.):
>
>
> DisableFormat: true
>
> # Disabling formatting doesn't implicitly disable include sorting
> SortIncludes: false
>
> Formatting automatically applied for all .c, .h, and .cpp sources in the
> tree
>
>
> I’ll run the full suite again following reformatting using autopep8 for all
> .py files.
>
> Thanks to everyone who has chimed in with suggestions, and with
> contributions to ensure that include ordering doesn’t become an issue on
> other platforms.
>
> Kate Stone k8stone at apple.com
>  Xcode Low Level Tools
>
> On Aug 15, 2016, at 8:50 AM, David Jones via lldb-dev
> <lldb-dev at lists.llvm.org> wrote:
>
> On Mon, Aug 15, 2016 at 2:36 AM, Pavel Labath via lldb-dev
> <lldb-dev at lists.llvm.org> wrote:
>>
>> I've sampled the python code from the llvm repository, and it seems to
>> be using a mixture of 4-, 2-, and even 8- character indent, with 4
>> being the most prevalent. So, I think we can safely stay with status
>> quo.
>>
>
> (Comment from the peanut gallery...)
>
> Python does have a language-level style guide (PEP-8):
>
> https://www.python.org/dev/peps/pep-0008/
>
> If code is going to be reformatted, then it may be best to try to converge
> on exactly the PEP-8 style. Speaking as a project "outsider" (i.e., not an
> active contributor), but someone with Python background, anything that
> diverges from standard Python style seems jarring (at least to me).
>
>
>>
>> It will take some editor tweaking to make it use the correct indent
>> for different files, but it should be manageable.
>>
>> pl
>>
>> On 12 August 2016 at 18:13, Jim Ingham <jingham at apple.com> wrote:
>> >
>> >> On Aug 12, 2016, at 5:23 AM, Pavel Labath via lldb-dev
>> >> <lldb-dev at lists.llvm.org> wrote:
>> >>
>> >> On 12 August 2016 at 00:54, Chris Lattner via lldb-dev
>> >> <lldb-dev at lists.llvm.org> wrote:
>> >>> I recommend approaching this in three steps:
>> >>>
>> >>> 1) get the less-controversial changes done that Greg was outlining.
>> >>> 2) start a discussion in the llvm community about the concept of a
>> >>> member/global prefix.
>> >>> 2a) the community could agree that llvm-as-a-whole should move to
>> >>> prefixes
>> >>> or otherwise change the camel case policy.
>> >>> 2b) the community could agree that the existing policies are preferred
>> >>> 3) LLDB moves to whatever is the end result of the discussion.
>> >>>
>> >>> I guess what I’m saying is that since the opinions about this are very
>> >>> strong, and because we haven’t really had that debate in the LLVM
>> >>> community,
>> >>> that it would be bad to proactively move to the LLVM style, simply to
>> >>> have
>> >>> to move back later.  Iff the (sure to be extensive) community
>> >>> discussion
>> >>> settles on the idea that prefixes are the wrong thing, then LLDB
>> >>> should
>> >>> remove them to be consistent.
>> >>>
>> >>> -Chris
>> >>
>> >> +1
>> >>
>> >>
>> >>
>> >> In terms of the formatting of tests, I did some more research on this.
>> >> I think the changes needed to be made to the test suite are generally
>> >> trivial to fix (e.g. r278490), but I don't think we can avoid a manual
>> >> intervention. CommentPragmas does not seem to be a silver bullet -- it
>> >> does prevent clang-format from breaking the comment, but it does not
>> >> prevent it from moving the whole comment to a new line. That said,
>> >> when I reformatted the test sources with CommentPragmas set, the
>> >> number of failures went down to 80 (from about 150)...
>> >>
>> >> I believe we should still perform the reformatting of the tests, at
>> >> least to standardize on the 2 space indent (in fact we should consider
>> >> doing the same for the python code as well, I don't know what's the
>> >> situation there in llvm land), but it can be done later. It will make
>> >> the period while the code is in flux longer, but hopefully not too
>> >> long. Also the modifications will be independent of the main reformat,
>> >> so it will still be true that a single source file only got
>> >> reformatted once.
>> >>
>> >
>> > My eyes put in a vote for not reformatting the Python to 2 space tabs.
>> > In C++, most IDE's do smart things with double-clicking on { to find the
>> > closing ones easing the task that two space indents makes somewhat harder.
>> > But since the spacing is the only nesting indicator in Python, it would be
>> > nice to keep that more visually apparent.
>> >
>> >> pl
>> >> _______________________________________________
>> >> lldb-dev mailing list
>> >> lldb-dev at lists.llvm.org
>> >> http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
>> >
>> _______________________________________________
>> lldb-dev mailing list
>> lldb-dev at lists.llvm.org
>> http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
>
>
> _______________________________________________
> lldb-dev mailing list
> lldb-dev at lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
>
>