Hi Tamas,
Adding Lars, Artem and Iurii. Iurii has been working on a version for
clang-format recently.
On 7/18/19 3:43 PM, Tamas K Lengyel wrote:
Using astyle (http://astyle.sourceforge.net) can greatly reduce the overhead of
manually checking and applying style-fixes to source-code. The incl
On 18.07.2019 16:43, Tamas K Lengyel wrote:
> --- a/CODING_STYLE
> +++ b/CODING_STYLE
> @@ -60,8 +60,8 @@ Bracing
> ---
>
> Braces ('{' and '}') are usually placed on a line of their own, except
> -for the do/while loop. This is unlike the Linux coding style and
> -unlike K&R. do/while
On Thu, Jul 18, 2019 at 9:02 AM Julien Grall wrote:
>
> Hi Tamas,
>
> Adding Lars, Artem and Iurii. Iurii has been working on a version for
> clang-format recently.
>
> On 7/18/19 3:43 PM, Tamas K Lengyel wrote:
> > Using astyle (http://astyle.sourceforge.net) can greatly reduce the
> > overhead
On Thu, Jul 18, 2019 at 9:14 AM Jan Beulich wrote:
>
> On 18.07.2019 16:43, Tamas K Lengyel wrote:
> > --- a/CODING_STYLE
> > +++ b/CODING_STYLE
> > @@ -60,8 +60,8 @@ Bracing
> > ---
> >
> > Braces ('{' and '}') are usually placed on a line of their own, except
> > -for the do/while loop.
Hi Tamas,
On 7/18/19 4:14 PM, Tamas K Lengyel wrote:
On Thu, Jul 18, 2019 at 9:02 AM Julien Grall wrote:
Hi Tamas,
Adding Lars, Artem and Iurii. Iurii has been working on a version for
clang-format recently.
On 7/18/19 3:43 PM, Tamas K Lengyel wrote:
Using astyle (http://astyle.sourceforge
>- Line 289: Files imported from Linux should not be touch here.
This is just a raw dump of what happens if I run astyle on all source
and header files. Obviously I won't attempt to upstream all these
changes you see in the gist. Respective maintainers are welcome to use
the tool if they find
>- Line 139: The { are commonly on the same line as struct or definition.
According to CODING_STYLE that's not how it should be.
Tamas
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
>- Line 276: The switch case indentation was correct from Xen PoV before
Removing "indent-switches" from the .astylerc actually leaves these
switches untouched, so that's an easy fix.
Tamas
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
>- Line 58: This is fairly common to indent the parameters as it is
> today. But then on line 158/272 it indents as we do today. So I am not
> sure what the expected coding style from the tools.
This was due to the tool not allowing indentation to be further to the
right then 40 characters. Ca
>- Line 8735: It looks like to me the tools policy is quite
> inconsistent. In previous place it keeps it properly aligned see line 5777.
This was also due to not allowing indentation to be more then 40
characters to the right. Overriding max-continuation-indent leaves
these be.
Tamas
__
>- Line 1025: The tools needs to be able to deal for_each_vcpu(...) & co.
These can be made OK by adding braces. Other than that the only way I
found to make it not change the indentation is to add the comment "/*
*INDENT-OFF* */" before the block and "/* *INDENT-ON* */" afterwards.
Tamas
__
On 18/07/2019 15:43, Tamas K Lengyel wrote:
> diff --git a/CODING_STYLE b/CODING_STYLE
> index 6cc5b774cf..0b37f7ae4d 100644
> --- a/CODING_STYLE
> +++ b/CODING_STYLE
> @@ -60,8 +60,8 @@ Bracing
> ---
>
> Braces ('{' and '}') are usually placed on a line of their own, except
> -for the do/w
On Thu, Jul 18, 2019 at 11:59 AM Andrew Cooper
wrote:
>
> On 18/07/2019 15:43, Tamas K Lengyel wrote:
> > diff --git a/CODING_STYLE b/CODING_STYLE
> > index 6cc5b774cf..0b37f7ae4d 100644
> > --- a/CODING_STYLE
> > +++ b/CODING_STYLE
> > @@ -60,8 +60,8 @@ Bracing
> > ---
> >
> > Braces ('{' a
Hi,
On 18/07/2019 18:18, Tamas K Lengyel wrote:
- Line 289: Files imported from Linux should not be touch here.
This is just a raw dump of what happens if I run astyle on all source
and header files. Obviously I won't attempt to upstream all these
changes you see in the gist. Respective ma
Hi Tamas,
On 18/07/2019 18:22, Tamas K Lengyel wrote:
- Line 139: The { are commonly on the same line as struct or definition.
According to CODING_STYLE that's not how it should be.
I guess you refer to the section "Bracing". If so, I think we don't follow the
CODING_STYLE for struct or
Hi Tamas,
On 18/07/2019 18:48, Tamas K Lengyel wrote:
- Line 1025: The tools needs to be able to deal for_each_vcpu(...) & co.
These can be made OK by adding braces. Other than that the only way I
found to make it not change the indentation is to add the comment "/*
*INDENT-OFF* */" before
On 18.07.2019 19:22, Tamas K Lengyel wrote:
>> - Line 139: The { are commonly on the same line as struct or definition.
>
> According to CODING_STYLE that's not how it should be.
Having the brace on the same line there is rather helpful to easily
tell the definition point of a struct/union/en
Hi,
On 18/07/2019 19:34, Tamas K Lengyel wrote:
On Thu, Jul 18, 2019 at 11:59 AM Andrew Cooper
wrote:
On 18/07/2019 15:43, Tamas K Lengyel wrote:
diff --git a/CODING_STYLE b/CODING_STYLE
index 6cc5b774cf..0b37f7ae4d 100644
--- a/CODING_STYLE
+++ b/CODING_STYLE
@@ -60,8 +60,8 @@ Bracing
---
On Fri, Jul 19, 2019 at 2:43 AM Julien Grall wrote:
>
> Hi Tamas,
>
> On 18/07/2019 18:48, Tamas K Lengyel wrote:
> >> - Line 1025: The tools needs to be able to deal for_each_vcpu(...) &
> >> co.
> >
> > These can be made OK by adding braces. Other than that the only way I
> > found to make
On Fri, Jul 19, 2019 at 3:03 AM Julien Grall wrote:
>
> Hi,
>
> On 18/07/2019 19:34, Tamas K Lengyel wrote:
> > On Thu, Jul 18, 2019 at 11:59 AM Andrew Cooper
> > wrote:
> >>
> >> On 18/07/2019 15:43, Tamas K Lengyel wrote:
> >>> diff --git a/CODING_STYLE b/CODING_STYLE
> >>> index 6cc5b774cf..0b
On Fri, Jul 19, 2019 at 3:01 AM Jan Beulich wrote:
>
> On 18.07.2019 19:22, Tamas K Lengyel wrote:
> >> - Line 139: The { are commonly on the same line as struct or
> >> definition.
> >
> > According to CODING_STYLE that's not how it should be.
>
> Having the brace on the same line there is r
Hi Tamas,
On 19/07/2019 14:00, Tamas K Lengyel wrote:
On Fri, Jul 19, 2019 at 2:43 AM Julien Grall wrote:
Hi Tamas,
On 18/07/2019 18:48, Tamas K Lengyel wrote:
- Line 1025: The tools needs to be able to deal for_each_vcpu(...) & co.
These can be made OK by adding braces. Other than t
On Fri, Jul 19, 2019 at 7:11 AM Julien Grall wrote:
>
> Hi Tamas,
>
> On 19/07/2019 14:00, Tamas K Lengyel wrote:
> > On Fri, Jul 19, 2019 at 2:43 AM Julien Grall wrote:
> >>
> >> Hi Tamas,
> >>
> >> On 18/07/2019 18:48, Tamas K Lengyel wrote:
> - Line 1025: The tools needs to be able t
Hi Tamas,
On 19/07/2019 14:14, Tamas K Lengyel wrote:
On Fri, Jul 19, 2019 at 7:11 AM Julien Grall wrote:
Hi Tamas,
On 19/07/2019 14:00, Tamas K Lengyel wrote:
On Fri, Jul 19, 2019 at 2:43 AM Julien Grall wrote:
Hi Tamas,
On 18/07/2019 18:48, Tamas K Lengyel wrote:
- Line 1025: T
> On Jul 18, 2019, at 10:43, Tamas K Lengyel wrote:
>
> Using astyle (http://astyle.sourceforge.net) can greatly reduce the overhead
> of
> manually checking and applying style-fixes to source-code. The included
> .astylerc is the closest approximation of the established Xen style (including
> s
On 19/07/2019 14:24, Julien Grall wrote:
Hi Tamas,
On 19/07/2019 14:14, Tamas K Lengyel wrote:
On Fri, Jul 19, 2019 at 7:11 AM Julien Grall wrote:
Hi Tamas,
On 19/07/2019 14:00, Tamas K Lengyel wrote:
On Fri, Jul 19, 2019 at 2:43 AM Julien Grall wrote:
Hi Tamas,
On 18/07/2019 18:48,
Hi Tamas,
On 19/07/2019 14:05, Tamas K Lengyel wrote:
On Fri, Jul 19, 2019 at 3:03 AM Julien Grall wrote:
Hi,
On 18/07/2019 19:34, Tamas K Lengyel wrote:
On Thu, Jul 18, 2019 at 11:59 AM Andrew Cooper
wrote:
On 18/07/2019 15:43, Tamas K Lengyel wrote:
diff --git a/CODING_STYLE b/CODING_
On Fri, Jul 19, 2019 at 7:34 AM Julien Grall wrote:
>
> Hi Tamas,
>
> On 19/07/2019 14:05, Tamas K Lengyel wrote:
> > On Fri, Jul 19, 2019 at 3:03 AM Julien Grall wrote:
> >>
> >> Hi,
> >>
> >> On 18/07/2019 19:34, Tamas K Lengyel wrote:
> >>> On Thu, Jul 18, 2019 at 11:59 AM Andrew Cooper
> >>>
On Jul 19, 2019, at 09:31, Julien Grall wrote:
>> On 19/07/2019 14:24, Julien Grall wrote:
>> Hi Tamas,
>>> On 19/07/2019 14:14, Tamas K Lengyel wrote:
On Fri, Jul 19, 2019 at 7:11 AM Julien Grall wrote:
Hi Tamas,
> On 19/07/2019 14:00, Tamas K Lengyel wrote:
>> On F
On Fri, Jul 19, 2019 at 7:31 AM Julien Grall wrote:
>
>
>
> On 19/07/2019 14:24, Julien Grall wrote:
> > Hi Tamas,
> >
> > On 19/07/2019 14:14, Tamas K Lengyel wrote:
> >> On Fri, Jul 19, 2019 at 7:11 AM Julien Grall wrote:
> >>>
> >>> Hi Tamas,
> >>>
> >>> On 19/07/2019 14:00, Tamas K Lengyel wr
Hi Rich,
On 19/07/2019 14:50, Rich Persaud wrote:
On Jul 19, 2019, at 09:31, Julien Grall wrote:
On 19/07/2019 14:24, Julien Grall wrote:
Hi Tamas,
On 19/07/2019 14:14, Tamas K Lengyel wrote:
On Fri, Jul 19, 2019 at 7:11 AM Julien Grall wrote:
Hi Tamas,
On 19/07/2019 14:00, Tamas K Lengy
On 19/07/2019, 14:50, "Rich Persaud" wrote:
On Jul 19, 2019, at 09:31, Julien Grall wrote:
>> On 19/07/2019 14:24, Julien Grall wrote:
>> Hi Tamas,
>>> On 19/07/2019 14:14, Tamas K Lengyel wrote:
On Fri, Jul 19, 2019 at 7:11 AM Julien Grall
wrote:
Hi All,
On Thu, Jul 18, 2019 at 6:16 PM Jan Beulich wrote:
>
> On 18.07.2019 16:43, Tamas K Lengyel wrote:
> > --- a/CODING_STYLE
> > +++ b/CODING_STYLE
> > @@ -60,8 +60,8 @@ Bracing
> > ---
> >
> > Braces ('{' and '}') are usually placed on a line of their own, except
> > -for the do/whi
Hi Julien, All,
On Thu, Jul 18, 2019 at 6:44 PM Julien Grall wrote:
>
> Hi Tamas,
>
> On 7/18/19 4:14 PM, Tamas K Lengyel wrote:
> > On Thu, Jul 18, 2019 at 9:02 AM Julien Grall wrote:
> >>
> >> Hi Tamas,
> >>
> >> Adding Lars, Artem and Iurii. Iurii has been working on a version for
> >> clang-
On Fri, Jul 26, 2019 at 8:42 AM Viktor Mitin wrote:
>
> Hi All,
>
> On Thu, Jul 18, 2019 at 6:16 PM Jan Beulich wrote:
> >
> > On 18.07.2019 16:43, Tamas K Lengyel wrote:
> > > --- a/CODING_STYLE
> > > +++ b/CODING_STYLE
> > > @@ -60,8 +60,8 @@ Bracing
> > > ---
> > >
> > > Braces ('{' an
Hi All,
On Thu, Jul 18, 2019 at 8:24 PM Tamas K Lengyel wrote:
>
> >- Line 139: The { are commonly on the same line as struct or definition.
>
> According to CODING_STYLE that's not how it should be.
All such cases should be explicitly stated in the CODING_STYLE document.
Thanks
> Tamas
>
Please be aware that such for_each_* cases are covered by clang-format.
Thanks
On Thu, Jul 18, 2019 at 8:50 PM Tamas K Lengyel wrote:
>
> >- Line 1025: The tools needs to be able to deal for_each_vcpu(...) & co.
>
> These can be made OK by adding braces. Other than that the only way I
> foun
lOn 26/07/2019 15:49, Viktor Mitin wrote:
Hi Julien, All,
Hi,
On Thu, Jul 18, 2019 at 6:44 PM Julien Grall wrote:
Hi Tamas,
On 7/18/19 4:14 PM, Tamas K Lengyel wrote:
On Thu, Jul 18, 2019 at 9:02 AM Julien Grall wrote:
Hi Tamas,
Adding Lars, Artem and Iurii. Iurii has been working on
On Fri, Jul 19, 2019 at 11:37 AM Julien Grall wrote:
>
> Hi Tamas,
>
> On 18/07/2019 18:22, Tamas K Lengyel wrote:
> >> - Line 139: The { are commonly on the same line as struct or
> >> definition.
> >
> > According to CODING_STYLE that's not how it should be.
>
> I guess you refer to the sec
Hi Viktor,
On 26/07/2019 15:58, Viktor Mitin wrote:
On Fri, Jul 19, 2019 at 11:37 AM Julien Grall wrote:
Hi Tamas,
On 18/07/2019 18:22, Tamas K Lengyel wrote:
- Line 139: The { are commonly on the same line as struct or definition.
According to CODING_STYLE that's not how it should b
On Fri, Jul 26, 2019 at 9:12 AM Julien Grall wrote:
>
> Hi Viktor,
>
> On 26/07/2019 15:58, Viktor Mitin wrote:
> > On Fri, Jul 19, 2019 at 11:37 AM Julien Grall wrote:
> >>
> >> Hi Tamas,
> >>
> >> On 18/07/2019 18:22, Tamas K Lengyel wrote:
> - Line 139: The { are commonly on the same
Hi All,
On Thu, Jul 18, 2019 at 5:45 PM Tamas K Lengyel wrote:
> Checking the comment styles are not included in the automation.
The same about clang-format. Checking the comment styles is not supported.
It seems this is not code format checker task to parse and modify the
code comments...
Tha
On 26/07/2019 16:48, Viktor Mitin wrote:
Hi All,
On Thu, Jul 18, 2019 at 5:45 PM Tamas K Lengyel wrote:
Checking the comment styles are not included in the automation.
The same about clang-format. Checking the comment styles is not supported.
It seems this is not code format checker task
On Fri, Jul 26, 2019 at 6:54 PM Julien Grall wrote:
>
>
>
> On 26/07/2019 16:48, Viktor Mitin wrote:
> > Hi All,
> >
> > On Thu, Jul 18, 2019 at 5:45 PM Tamas K Lengyel wrote:
> >
> >> Checking the comment styles are not included in the automation.
> >
> > The same about clang-format. Checking th
On 26/07/2019, 16:12, "Julien Grall" wrote:
Hi Viktor,
On 26/07/2019 15:58, Viktor Mitin wrote:
> On Fri, Jul 19, 2019 at 11:37 AM Julien Grall
wrote:
>>
>> Hi Tamas,
>>
>> On 18/07/2019 18:22, Tamas K Lengyel wrote:
- Line 139: The { are common
On 26.07.2019 16:49, Viktor Mitin wrote:
> Hi Julien, All,
>
> On Thu, Jul 18, 2019 at 6:44 PM Julien Grall wrote:
>>
>> Hi Tamas,
>>
>> On 7/18/19 4:14 PM, Tamas K Lengyel wrote:
>>> On Thu, Jul 18, 2019 at 9:02 AM Julien Grall wrote:
Hi Tamas,
Adding Lars, Artem and Iurii.
Hi Jan,
On 7/29/19 1:19 PM, Jan Beulich wrote:
On 26.07.2019 16:49, Viktor Mitin wrote:
Hi Julien, All,
On Thu, Jul 18, 2019 at 6:44 PM Julien Grall wrote:
Hi Tamas,
On 7/18/19 4:14 PM, Tamas K Lengyel wrote:
On Thu, Jul 18, 2019 at 9:02 AM Julien Grall wrote:
Hi Tamas,
Adding Lars, A
On 29.07.2019 14:49, Julien Grall wrote:
> Hi Jan,
>
> On 7/29/19 1:19 PM, Jan Beulich wrote:
>> On 26.07.2019 16:49, Viktor Mitin wrote:
>>> Hi Julien, All,
>>>
>>> On Thu, Jul 18, 2019 at 6:44 PM Julien Grall wrote:
Hi Tamas,
On 7/18/19 4:14 PM, Tamas K Lengyel wrote:
>
Hi Jan,
On Mon, Jul 29, 2019 at 4:21 PM Jan Beulich wrote:
> - Line 67: I believe Jan request the space before label
> >>> Seems agreed not to add the spaces before label. Right?
> >>
> >> Certainly not, afaia. I will object to any written down rule disallowing
> >> leading blank(s) al
On 31.07.2019 18:20, Viktor Mitin wrote:
> How all those projects live without this issue?
Perhaps they don't care? I do.
> What is the reason not to fix 'diff -p'? Is it not possible at all?
I have no idea, but I guess there's a reason for its current
behavior.
> Could you please share more de
On Thu, Aug 1, 2019 at 10:40 AM Jan Beulich wrote:
>
> On 31.07.2019 18:20, Viktor Mitin wrote:
> > How all those projects live without this issue?
>
> Perhaps they don't care? I do.
>
> > What is the reason not to fix 'diff -p'? Is it not possible at all?
>
> I have no idea, but I guess there's a
On 01.08.2019 14:16, Viktor Mitin wrote:
> I expected you to have some arguments why it cannot be fixed in the
> diff or other tools.
I don't follow: How does it matter here whether I have arguments towards
(not) fixing diff etc? That's their maintainers' arguments, if any, not
mine. All I know (f
On 01.08.19 14:16, Viktor Mitin wrote:
On Thu, Aug 1, 2019 at 10:40 AM Jan Beulich wrote:
On 31.07.2019 18:20, Viktor Mitin wrote:
How all those projects live without this issue?
Perhaps they don't care? I do.
What is the reason not to fix 'diff -p'? Is it not possible at all?
I have no
On Thu, Aug 1, 2019 at 3:50 PM Juergen Gross wrote:
>
> On 01.08.19 14:16, Viktor Mitin wrote:
> > On Thu, Aug 1, 2019 at 10:40 AM Jan Beulich wrote:
> >>
> >> On 31.07.2019 18:20, Viktor Mitin wrote:
> >>> How all those projects live without this issue?
> >>
> >> Perhaps they don't care? I do.
>
On 02.08.19 10:38, Viktor Mitin wrote:
On Thu, Aug 1, 2019 at 3:50 PM Juergen Gross wrote:
On 01.08.19 14:16, Viktor Mitin wrote:
On Thu, Aug 1, 2019 at 10:40 AM Jan Beulich wrote:
On 31.07.2019 18:20, Viktor Mitin wrote:
How all those projects live without this issue?
Perhaps they don'
On Fri, Aug 2, 2019 at 12:23 PM Juergen Gross wrote:
> >> A snipplet from commit 57f8b13c724023c78fa15a80452d1de3e51a1418:
> >>
> >> @@ -4096,14 +4097,12 @@ retry_transaction:
> >>goto out;
> >>
> >>if (target == NULL) {
> >> -libxl__xs_printf(gc, t, target_path, "%"PR
On 02.08.2019 13:44, Viktor Mitin wrote:
> On Fri, Aug 2, 2019 at 12:23 PM Juergen Gross wrote:
>
A snipplet from commit 57f8b13c724023c78fa15a80452d1de3e51a1418:
@@ -4096,14 +4097,12 @@ retry_transaction:
goto out;
if (target == NULL) {
-
57 matches
Mail list logo
