GSoC - Code Formatting and Style Checking for RTEMS score

[Ida Delphine]

Hello everyone,

Regarding this project (https://devel.rtems.org/ticket/3860) I went with
clang-format as we all agreed. I have tested it on some "score" files and
it made some changes which I don't think are very much in line with the
RTEMS coding style. However, it wasn't really clear if we will chage the
RTEMS coding style or try to make changes to clang-format to fit the style.
Please will love to know the best option.

Cheers,
Ida.
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: GSoC - Code Formatting and Style Checking for RTEMS score

[Gedare Bloom]

hi Ida,

On Wed, May 5, 2021 at 3:21 PM Ida Delphine  wrote:
>
> Hello everyone,
>
> Regarding this project (https://devel.rtems.org/ticket/3860) I went with 
> clang-format as we all agreed. I have tested it on some "score" files and it 
> made some changes which I don't think are very much in line with the RTEMS 
> coding style. However, it wasn't really clear if we will chage the RTEMS 
> coding style or try to make changes to clang-format to fit the style.
> Please will love to know the best option.
>
We will likely need to consider our choices carefully. If we can find
a suitably close style that is already well-supported by clang, and
get consensus from the maintainers on a change, then that might be the
best route forward. I think the first thing to do is take the examples
that have been shown by Sebastian that are "close" but not quite
perfect, and identify the cases where they differ with RTEMS style in
order to present for discussion here. If consensus can't be reached to
change the style, then we would need to have a plan for how to improve
the existing tools for what we have.

However, I think there is interest in doing less work on the tool
side, and more work on how to integrate it into our workflows better.

> Cheers,
> Ida.
> ___
> devel mailing list
> devel@rtems.org
> http://lists.rtems.org/mailman/listinfo/devel
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: GSoC - Code Formatting and Style Checking for RTEMS score

[Christian Mauderer]

Hello Ida and Gedare,

On 06/05/2021 06:26, Gedare Bloom wrote:

hi Ida,

On Wed, May 5, 2021 at 3:21 PM Ida Delphine  wrote:


Hello everyone,

Regarding this project (https://devel.rtems.org/ticket/3860) I went with clang-format as 
we all agreed. I have tested it on some "score" files and it made some changes 
which I don't think are very much in line with the RTEMS coding style. However, it wasn't 
really clear if we will chage the RTEMS coding style or try to make changes to 
clang-format to fit the style.
Please will love to know the best option.


We will likely need to consider our choices carefully. If we can find
a suitably close style that is already well-supported by clang, and
get consensus from the maintainers on a change, then that might be the
best route forward.


+1


I think the first thing to do is take the examples
that have been shown by Sebastian that are "close" but not quite
perfect, and identify the cases where they differ with RTEMS style in
order to present for discussion here. If consensus can't be reached to
change the style, then we would need to have a plan for how to improve
the existing tools for what we have.


I also found the following tool quite useful to play with the clang 
style config:


https://zed0.co.uk/clang-format-configurator/

Maybe it can help a bit to find out what certain options mean.



However, I think there is interest in doing less work on the tool
side, and more work on how to integrate it into our workflows better.


+1




Cheers,
Ida.
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel


___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: GSoC - Code Formatting and Style Checking for RTEMS score

[Joel Sherrill]

On Thu, May 6, 2021 at 12:47 PM Christian Mauderer 
wrote:

> Hello Ida and Gedare,
>
> On 06/05/2021 06:26, Gedare Bloom wrote:
> > hi Ida,
> >
> > On Wed, May 5, 2021 at 3:21 PM Ida Delphine  wrote:
> >>
> >> Hello everyone,
> >>
> >> Regarding this project (https://devel.rtems.org/ticket/3860) I went
> with clang-format as we all agreed. I have tested it on some "score" files
> and it made some changes which I don't think are very much in line with the
> RTEMS coding style. However, it wasn't really clear if we will chage the
> RTEMS coding style or try to make changes to clang-format to fit the style.
> >> Please will love to know the best option.
> >>
> > We will likely need to consider our choices carefully. If we can find
> > a suitably close style that is already well-supported by clang, and
> > get consensus from the maintainers on a change, then that might be the
> > best route forward.
>
> +1
>
> > I think the first thing to do is take the examples
> > that have been shown by Sebastian that are "close" but not quite
> > perfect, and identify the cases where they differ with RTEMS style in
> > order to present for discussion here. If consensus can't be reached to
> > change the style, then we would need to have a plan for how to improve
> > the existing tools for what we have.
>
> I also found the following tool quite useful to play with the clang
> style config:
>
> https://zed0.co.uk/clang-format-configurator/
>
> Maybe it can help a bit to find out what certain options mean.
>
> >
> > However, I think there is interest in doing less work on the tool
> > side, and more work on how to integrate it into our workflows better.
>
> +1
>

I agree with all of this from the student perspective. But we will have
to come to some agreement on a machine producible format to
be able to use the integration. A report on what doesn't match would
give us something to chew on while Ida works the integration.

--joel

>
> >
> >> Cheers,
> >> Ida.
> >> ___
> >> devel mailing list
> >> devel@rtems.org
> >> http://lists.rtems.org/mailman/listinfo/devel
> > ___
> > devel mailing list
> > devel@rtems.org
> > http://lists.rtems.org/mailman/listinfo/devel
> >
> ___
> devel mailing list
> devel@rtems.org
> http://lists.rtems.org/mailman/listinfo/devel
>
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: GSoC - Code Formatting and Style Checking for RTEMS score

[Ida Delphine]

Hello everyone,
Went through some previous emails and it turns out Sebastian already came
up with a configuration for clang format which works well for RTEMS except
for the fact that some configurations haven't been implemented into
clang-format yet. Using

AlignConsecutiveDeclarations: false
PointerAlignment: Right

Doesn't seem to work.
For example in the cpukit/score/src/threadq.c file, something like

RTEMS_STATIC_ASSERT(
offsetof( Thread_queue_Syslock_queue, Queue.name )
== offsetof( struct _Thread_queue_Queue, _name ),
THREAD_QUEUE_SYSLOCK_QUEUE_NAME
);

RTEMS_STATIC_ASSERT(
sizeof( Thread_queue_Syslock_queue )
== sizeof( struct _Thread_queue_Queue ),
THREAD_QUEUE_SYSLOCK_QUEUE_SIZE
);

#if defined(RTEMS_SMP)
void _Thread_queue_Do_acquire_critical(
Thread_queue_Control *the_thread_queue,
ISR_lock_Context *lock_context
)
{
_Thread_queue_Queue_acquire_critical(
&the_thread_queue->Queue,
&the_thread_queue->Lock_stats,
lock_context
);

becomes this after using the given configuration

RTEMS_STATIC_ASSERT(sizeof(Thread_queue_Syslock_queue) ==
sizeof(struct _Thread_queue_Queue),
THREAD_QUEUE_SYSLOCK_QUEUE_SIZE);

#if defined(RTEMS_SMP)
void _Thread_queue_Do_acquire_critical(Thread_queue_Control *
the_thread_queue,
ISR_lock_Context *lock_context) {
_Thread_queue_Queue_acquire_critical(
&the_thread_queue->Queue, &the_thread_queue->Lock_stats, lock_context);

Everything seems manageable except for this alignment issue...
This also throws more light on the changes using clang-format (
https://lists.rtems.org/pipermail/devel/2018-December/024145.html)

On Thu, May 6, 2021 at 8:05 PM Joel Sherrill  wrote:

>
>
> On Thu, May 6, 2021 at 12:47 PM Christian Mauderer 
> wrote:
>
>> Hello Ida and Gedare,
>>
>> On 06/05/2021 06:26, Gedare Bloom wrote:
>> > hi Ida,
>> >
>> > On Wed, May 5, 2021 at 3:21 PM Ida Delphine  wrote:
>> >>
>> >> Hello everyone,
>> >>
>> >> Regarding this project (https://devel.rtems.org/ticket/3860) I went
>> with clang-format as we all agreed. I have tested it on some "score" files
>> and it made some changes which I don't think are very much in line with the
>> RTEMS coding style. However, it wasn't really clear if we will chage the
>> RTEMS coding style or try to make changes to clang-format to fit the style.
>> >> Please will love to know the best option.
>> >>
>> > We will likely need to consider our choices carefully. If we can find
>> > a suitably close style that is already well-supported by clang, and
>> > get consensus from the maintainers on a change, then that might be the
>> > best route forward.
>>
>> +1
>>
>> > I think the first thing to do is take the examples
>> > that have been shown by Sebastian that are "close" but not quite
>> > perfect, and identify the cases where they differ with RTEMS style in
>> > order to present for discussion here. If consensus can't be reached to
>> > change the style, then we would need to have a plan for how to improve
>> > the existing tools for what we have.
>>
>> I also found the following tool quite useful to play with the clang
>> style config:
>>
>> https://zed0.co.uk/clang-format-configurator/
>>
>> Maybe it can help a bit to find out what certain options mean.
>>
>> >
>> > However, I think there is interest in doing less work on the tool
>> > side, and more work on how to integrate it into our workflows better.
>>
>> +1
>>
>
> I agree with all of this from the student perspective. But we will have
> to come to some agreement on a machine producible format to
> be able to use the integration. A report on what doesn't match would
> give us something to chew on while Ida works the integration.
>
> --joel
>
>>
>> >
>> >> Cheers,
>> >> Ida.
>> >> ___
>> >> devel mailing list
>> >> devel@rtems.org
>> >> http://lists.rtems.org/mailman/listinfo/devel
>> > ___
>> > devel mailing list
>> > devel@rtems.org
>> > http://lists.rtems.org/mailman/listinfo/devel
>> >
>> ___
>> devel mailing list
>> devel@rtems.org
>> http://lists.rtems.org/mailman/listinfo/devel
>>
>
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: GSoC - Code Formatting and Style Checking for RTEMS score

[Ida Delphine]

Hello everyone,
Still waiting for some feedback :)

Cheers,
Ida.

On Mon, 10 May 2021, 5:59 am Ida Delphine,  wrote:

> Hello everyone,
> Went through some previous emails and it turns out Sebastian already came
> up with a configuration for clang format which works well for RTEMS except
> for the fact that some configurations haven't been implemented into
> clang-format yet. Using
>
> AlignConsecutiveDeclarations: false
> PointerAlignment: Right
>
> Doesn't seem to work.
> For example in the cpukit/score/src/threadq.c file, something like
>
> RTEMS_STATIC_ASSERT(
> offsetof( Thread_queue_Syslock_queue, Queue.name )
> == offsetof( struct _Thread_queue_Queue, _name ),
> THREAD_QUEUE_SYSLOCK_QUEUE_NAME
> );
>
> RTEMS_STATIC_ASSERT(
> sizeof( Thread_queue_Syslock_queue )
> == sizeof( struct _Thread_queue_Queue ),
> THREAD_QUEUE_SYSLOCK_QUEUE_SIZE
> );
>
> #if defined(RTEMS_SMP)
> void _Thread_queue_Do_acquire_critical(
> Thread_queue_Control *the_thread_queue,
> ISR_lock_Context *lock_context
> )
> {
> _Thread_queue_Queue_acquire_critical(
> &the_thread_queue->Queue,
> &the_thread_queue->Lock_stats,
> lock_context
> );
>
> becomes this after using the given configuration
>
> RTEMS_STATIC_ASSERT(sizeof(Thread_queue_Syslock_queue) ==
> sizeof(struct _Thread_queue_Queue),
> THREAD_QUEUE_SYSLOCK_QUEUE_SIZE);
>
> #if defined(RTEMS_SMP)
> void _Thread_queue_Do_acquire_critical(Thread_queue_Control *
> the_thread_queue,
> ISR_lock_Context *lock_context) {
> _Thread_queue_Queue_acquire_critical(
> &the_thread_queue->Queue, &the_thread_queue->Lock_stats, lock_context);
>
> Everything seems manageable except for this alignment issue...
> This also throws more light on the changes using clang-format (
> https://lists.rtems.org/pipermail/devel/2018-December/024145.html)
>
> On Thu, May 6, 2021 at 8:05 PM Joel Sherrill  wrote:
>
>>
>>
>> On Thu, May 6, 2021 at 12:47 PM Christian Mauderer 
>> wrote:
>>
>>> Hello Ida and Gedare,
>>>
>>> On 06/05/2021 06:26, Gedare Bloom wrote:
>>> > hi Ida,
>>> >
>>> > On Wed, May 5, 2021 at 3:21 PM Ida Delphine  wrote:
>>> >>
>>> >> Hello everyone,
>>> >>
>>> >> Regarding this project (https://devel.rtems.org/ticket/3860) I went
>>> with clang-format as we all agreed. I have tested it on some "score" files
>>> and it made some changes which I don't think are very much in line with the
>>> RTEMS coding style. However, it wasn't really clear if we will chage the
>>> RTEMS coding style or try to make changes to clang-format to fit the style.
>>> >> Please will love to know the best option.
>>> >>
>>> > We will likely need to consider our choices carefully. If we can find
>>> > a suitably close style that is already well-supported by clang, and
>>> > get consensus from the maintainers on a change, then that might be the
>>> > best route forward.
>>>
>>> +1
>>>
>>> > I think the first thing to do is take the examples
>>> > that have been shown by Sebastian that are "close" but not quite
>>> > perfect, and identify the cases where they differ with RTEMS style in
>>> > order to present for discussion here. If consensus can't be reached to
>>> > change the style, then we would need to have a plan for how to improve
>>> > the existing tools for what we have.
>>>
>>> I also found the following tool quite useful to play with the clang
>>> style config:
>>>
>>> https://zed0.co.uk/clang-format-configurator/
>>>
>>> Maybe it can help a bit to find out what certain options mean.
>>>
>>> >
>>> > However, I think there is interest in doing less work on the tool
>>> > side, and more work on how to integrate it into our workflows better.
>>>
>>> +1
>>>
>>
>> I agree with all of this from the student perspective. But we will have
>> to come to some agreement on a machine producible format to
>> be able to use the integration. A report on what doesn't match would
>> give us something to chew on while Ida works the integration.
>>
>> --joel
>>
>>>
>>> >
>>> >> Cheers,
>>> >> Ida.
>>> >> ___
>>> >> devel mailing list
>>> >> devel@rtems.org
>>> >> http://lists.rtems.org/mailman/listinfo/devel
>>> > ___
>>> > devel mailing list
>>> > devel@rtems.org
>>> > http://lists.rtems.org/mailman/listinfo/devel
>>> >
>>> ___
>>> devel mailing list
>>> devel@rtems.org
>>> http://lists.rtems.org/mailman/listinfo/devel
>>>
>>
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: GSoC - Code Formatting and Style Checking for RTEMS score

[Gedare Bloom]

On Wed, May 12, 2021 at 2:18 PM Ida Delphine  wrote:
>
> Hello everyone,
> Still waiting for some feedback :)
>
> Cheers,
> Ida.
>
> On Mon, 10 May 2021, 5:59 am Ida Delphine,  wrote:
>>
>> Hello everyone,
>> Went through some previous emails and it turns out Sebastian already came up 
>> with a configuration for clang format which works well for RTEMS except for 
>> the fact that some configurations haven't been implemented into clang-format 
>> yet. Using
>>
>> AlignConsecutiveDeclarations: false
>> PointerAlignment: Right
>>
>> Doesn't seem to work.
>> For example in the cpukit/score/src/threadq.c file, something like
>>
>> RTEMS_STATIC_ASSERT(
>> offsetof( Thread_queue_Syslock_queue, Queue.name )
>> == offsetof( struct _Thread_queue_Queue, _name ),
>> THREAD_QUEUE_SYSLOCK_QUEUE_NAME
>> );
>>
>> RTEMS_STATIC_ASSERT(
>> sizeof( Thread_queue_Syslock_queue )
>> == sizeof( struct _Thread_queue_Queue ),
>> THREAD_QUEUE_SYSLOCK_QUEUE_SIZE
>> );
>>
>> #if defined(RTEMS_SMP)
>> void _Thread_queue_Do_acquire_critical(
>> Thread_queue_Control *the_thread_queue,
>> ISR_lock_Context *lock_context
>> )
>> {
>> _Thread_queue_Queue_acquire_critical(
>> &the_thread_queue->Queue,
>> &the_thread_queue->Lock_stats,
>> lock_context
>> );
>>
>> becomes this after using the given configuration
>>
>> RTEMS_STATIC_ASSERT(sizeof(Thread_queue_Syslock_queue) ==
>> sizeof(struct _Thread_queue_Queue),
>> THREAD_QUEUE_SYSLOCK_QUEUE_SIZE);
>>
>> #if defined(RTEMS_SMP)
>> void _Thread_queue_Do_acquire_critical(Thread_queue_Control 
>> *the_thread_queue,
>> ISR_lock_Context *lock_context) {
>> _Thread_queue_Queue_acquire_critical(
>> &the_thread_queue->Queue, &the_thread_queue->Lock_stats, lock_context);
>>
>> Everything seems manageable except for this alignment issue...
>> This also throws more light on the changes using clang-format 
>> (https://lists.rtems.org/pipermail/devel/2018-December/024145.html)
>>
I think we're willing to concede the pointer alignment. However, it
would be worth spending some time to see if
https://reviews.llvm.org/D27651 can be made to work. The current state
of the code would need to be compared to the patch on that review
board.

Beyond that, documenting the clang-format options to use is next, and
then identifying a plan how to invoke clang-format during a git
workflow is needed.

>> On Thu, May 6, 2021 at 8:05 PM Joel Sherrill  wrote:
>>>
>>>
>>>
>>> On Thu, May 6, 2021 at 12:47 PM Christian Mauderer  
>>> wrote:

 Hello Ida and Gedare,

 On 06/05/2021 06:26, Gedare Bloom wrote:
 > hi Ida,
 >
 > On Wed, May 5, 2021 at 3:21 PM Ida Delphine  wrote:
 >>
 >> Hello everyone,
 >>
 >> Regarding this project (https://devel.rtems.org/ticket/3860) I went 
 >> with clang-format as we all agreed. I have tested it on some "score" 
 >> files and it made some changes which I don't think are very much in 
 >> line with the RTEMS coding style. However, it wasn't really clear if we 
 >> will chage the RTEMS coding style or try to make changes to 
 >> clang-format to fit the style.
 >> Please will love to know the best option.
 >>
 > We will likely need to consider our choices carefully. If we can find
 > a suitably close style that is already well-supported by clang, and
 > get consensus from the maintainers on a change, then that might be the
 > best route forward.

 +1

 > I think the first thing to do is take the examples
 > that have been shown by Sebastian that are "close" but not quite
 > perfect, and identify the cases where they differ with RTEMS style in
 > order to present for discussion here. If consensus can't be reached to
 > change the style, then we would need to have a plan for how to improve
 > the existing tools for what we have.

 I also found the following tool quite useful to play with the clang
 style config:

 https://zed0.co.uk/clang-format-configurator/

 Maybe it can help a bit to find out what certain options mean.

 >
 > However, I think there is interest in doing less work on the tool
 > side, and more work on how to integrate it into our workflows better.

 +1
>>>
>>>
>>> I agree with all of this from the student perspective. But we will have
>>> to come to some agreement on a machine producible format to
>>> be able to use the integration. A report on what doesn't match would
>>> give us something to chew on while Ida works the integration.
>>>
>>> --joel


 >
 >> Cheers,
 >> Ida.
 >> ___
 >> devel mailing list
 >> devel@rtems.org
 >> http://lists.rtems.org/mailman/listinfo/devel
 > ___
 > devel mailing list
 > devel@rtems.org
 > http://lists.rtems.org/mailman/listinfo/devel
 >
 ___
 devel mailing list
 devel@rtems.org
>

Re: GSoC - Code Formatting and Style Checking for RTEMS score

[Ida Delphine]

Hi Gedare,

With regards to your comment on discord on me looking for a tool that works
on both patches and source files, it turns out clang-format has that
functionality already. Here's what I found -
https://clang.llvm.org/docs/ClangFormat.html#script-for-patch-reformatting

Does it match what you have in mind?

On Thu, May 13, 2021 at 3:49 PM Gedare Bloom  wrote:

> On Wed, May 12, 2021 at 2:18 PM Ida Delphine  wrote:
> >
> > Hello everyone,
> > Still waiting for some feedback :)
> >
> > Cheers,
> > Ida.
> >
> > On Mon, 10 May 2021, 5:59 am Ida Delphine,  wrote:
> >>
> >> Hello everyone,
> >> Went through some previous emails and it turns out Sebastian already
> came up with a configuration for clang format which works well for RTEMS
> except for the fact that some configurations haven't been implemented into
> clang-format yet. Using
> >>
> >> AlignConsecutiveDeclarations: false
> >> PointerAlignment: Right
> >>
> >> Doesn't seem to work.
> >> For example in the cpukit/score/src/threadq.c file, something like
> >>
> >> RTEMS_STATIC_ASSERT(
> >> offsetof( Thread_queue_Syslock_queue, Queue.name )
> >> == offsetof( struct _Thread_queue_Queue, _name ),
> >> THREAD_QUEUE_SYSLOCK_QUEUE_NAME
> >> );
> >>
> >> RTEMS_STATIC_ASSERT(
> >> sizeof( Thread_queue_Syslock_queue )
> >> == sizeof( struct _Thread_queue_Queue ),
> >> THREAD_QUEUE_SYSLOCK_QUEUE_SIZE
> >> );
> >>
> >> #if defined(RTEMS_SMP)
> >> void _Thread_queue_Do_acquire_critical(
> >> Thread_queue_Control *the_thread_queue,
> >> ISR_lock_Context *lock_context
> >> )
> >> {
> >> _Thread_queue_Queue_acquire_critical(
> >> &the_thread_queue->Queue,
> >> &the_thread_queue->Lock_stats,
> >> lock_context
> >> );
> >>
> >> becomes this after using the given configuration
> >>
> >> RTEMS_STATIC_ASSERT(sizeof(Thread_queue_Syslock_queue) ==
> >> sizeof(struct _Thread_queue_Queue),
> >> THREAD_QUEUE_SYSLOCK_QUEUE_SIZE);
> >>
> >> #if defined(RTEMS_SMP)
> >> void _Thread_queue_Do_acquire_critical(Thread_queue_Control
> *the_thread_queue,
> >> ISR_lock_Context *lock_context) {
> >> _Thread_queue_Queue_acquire_critical(
> >> &the_thread_queue->Queue, &the_thread_queue->Lock_stats, lock_context);
> >>
> >> Everything seems manageable except for this alignment issue...
> >> This also throws more light on the changes using clang-format (
> https://lists.rtems.org/pipermail/devel/2018-December/024145.html)
> >>
> I think we're willing to concede the pointer alignment. However, it
> would be worth spending some time to see if
> https://reviews.llvm.org/D27651 can be made to work. The current state
> of the code would need to be compared to the patch on that review
> board.
>
> Beyond that, documenting the clang-format options to use is next, and
> then identifying a plan how to invoke clang-format during a git
> workflow is needed.
>
> >> On Thu, May 6, 2021 at 8:05 PM Joel Sherrill  wrote:
> >>>
> >>>
> >>>
> >>> On Thu, May 6, 2021 at 12:47 PM Christian Mauderer 
> wrote:
> 
>  Hello Ida and Gedare,
> 
>  On 06/05/2021 06:26, Gedare Bloom wrote:
>  > hi Ida,
>  >
>  > On Wed, May 5, 2021 at 3:21 PM Ida Delphine 
> wrote:
>  >>
>  >> Hello everyone,
>  >>
>  >> Regarding this project (https://devel.rtems.org/ticket/3860) I
> went with clang-format as we all agreed. I have tested it on some "score"
> files and it made some changes which I don't think are very much in line
> with the RTEMS coding style. However, it wasn't really clear if we will
> chage the RTEMS coding style or try to make changes to clang-format to fit
> the style.
>  >> Please will love to know the best option.
>  >>
>  > We will likely need to consider our choices carefully. If we can
> find
>  > a suitably close style that is already well-supported by clang, and
>  > get consensus from the maintainers on a change, then that might be
> the
>  > best route forward.
> 
>  +1
> 
>  > I think the first thing to do is take the examples
>  > that have been shown by Sebastian that are "close" but not quite
>  > perfect, and identify the cases where they differ with RTEMS style
> in
>  > order to present for discussion here. If consensus can't be reached
> to
>  > change the style, then we would need to have a plan for how to
> improve
>  > the existing tools for what we have.
> 
>  I also found the following tool quite useful to play with the clang
>  style config:
> 
>  https://zed0.co.uk/clang-format-configurator/
> 
>  Maybe it can help a bit to find out what certain options mean.
> 
>  >
>  > However, I think there is interest in doing less work on the tool
>  > side, and more work on how to integrate it into our workflows
> better.
> 
>  +1
> >>>
> >>>
> >>> I agree with all of this from the student perspective. But we will have
> >>> to come to some agreement on a machine producible format to
> >>> be able to use the integration. A report on what do

Re: GSoC - Code Formatting and Style Checking for RTEMS score

[Gedare Bloom]

On Mon, May 31, 2021 at 2:59 PM Ida Delphine  wrote:
>
> Hi Gedare,
>
> With regards to your comment on discord on me looking for a tool that works 
> on both patches and source files, it turns out clang-format has that 
> functionality already. Here's what I found - 
> https://clang.llvm.org/docs/ClangFormat.html#script-for-patch-reformatting
>
> Does it match what you have in mind?
>
Yes. I think we would want to not use the `-i` option but instead pass
through and check the changes. I don't think we should rewrite the
patches themselves, but instead we want to use a tool that can be used
to check and approve the style of submitted patches. You might need to
write a modified version of the clang-format-diff.py to use as a
"checker" with ability to provide exceptions to the rules.

Gedare

> On Thu, May 13, 2021 at 3:49 PM Gedare Bloom  wrote:
>>
>> On Wed, May 12, 2021 at 2:18 PM Ida Delphine  wrote:
>> >
>> > Hello everyone,
>> > Still waiting for some feedback :)
>> >
>> > Cheers,
>> > Ida.
>> >
>> > On Mon, 10 May 2021, 5:59 am Ida Delphine,  wrote:
>> >>
>> >> Hello everyone,
>> >> Went through some previous emails and it turns out Sebastian already came 
>> >> up with a configuration for clang format which works well for RTEMS 
>> >> except for the fact that some configurations haven't been implemented 
>> >> into clang-format yet. Using
>> >>
>> >> AlignConsecutiveDeclarations: false
>> >> PointerAlignment: Right
>> >>
>> >> Doesn't seem to work.
>> >> For example in the cpukit/score/src/threadq.c file, something like
>> >>
>> >> RTEMS_STATIC_ASSERT(
>> >> offsetof( Thread_queue_Syslock_queue, Queue.name )
>> >> == offsetof( struct _Thread_queue_Queue, _name ),
>> >> THREAD_QUEUE_SYSLOCK_QUEUE_NAME
>> >> );
>> >>
>> >> RTEMS_STATIC_ASSERT(
>> >> sizeof( Thread_queue_Syslock_queue )
>> >> == sizeof( struct _Thread_queue_Queue ),
>> >> THREAD_QUEUE_SYSLOCK_QUEUE_SIZE
>> >> );
>> >>
>> >> #if defined(RTEMS_SMP)
>> >> void _Thread_queue_Do_acquire_critical(
>> >> Thread_queue_Control *the_thread_queue,
>> >> ISR_lock_Context *lock_context
>> >> )
>> >> {
>> >> _Thread_queue_Queue_acquire_critical(
>> >> &the_thread_queue->Queue,
>> >> &the_thread_queue->Lock_stats,
>> >> lock_context
>> >> );
>> >>
>> >> becomes this after using the given configuration
>> >>
>> >> RTEMS_STATIC_ASSERT(sizeof(Thread_queue_Syslock_queue) ==
>> >> sizeof(struct _Thread_queue_Queue),
>> >> THREAD_QUEUE_SYSLOCK_QUEUE_SIZE);
>> >>
>> >> #if defined(RTEMS_SMP)
>> >> void _Thread_queue_Do_acquire_critical(Thread_queue_Control 
>> >> *the_thread_queue,
>> >> ISR_lock_Context *lock_context) {
>> >> _Thread_queue_Queue_acquire_critical(
>> >> &the_thread_queue->Queue, &the_thread_queue->Lock_stats, lock_context);
>> >>
>> >> Everything seems manageable except for this alignment issue...
>> >> This also throws more light on the changes using clang-format 
>> >> (https://lists.rtems.org/pipermail/devel/2018-December/024145.html)
>> >>
>> I think we're willing to concede the pointer alignment. However, it
>> would be worth spending some time to see if
>> https://reviews.llvm.org/D27651 can be made to work. The current state
>> of the code would need to be compared to the patch on that review
>> board.
>>
>> Beyond that, documenting the clang-format options to use is next, and
>> then identifying a plan how to invoke clang-format during a git
>> workflow is needed.
>>
>> >> On Thu, May 6, 2021 at 8:05 PM Joel Sherrill  wrote:
>> >>>
>> >>>
>> >>>
>> >>> On Thu, May 6, 2021 at 12:47 PM Christian Mauderer  
>> >>> wrote:
>> 
>>  Hello Ida and Gedare,
>> 
>>  On 06/05/2021 06:26, Gedare Bloom wrote:
>>  > hi Ida,
>>  >
>>  > On Wed, May 5, 2021 at 3:21 PM Ida Delphine  wrote:
>>  >>
>>  >> Hello everyone,
>>  >>
>>  >> Regarding this project (https://devel.rtems.org/ticket/3860) I went 
>>  >> with clang-format as we all agreed. I have tested it on some "score" 
>>  >> files and it made some changes which I don't think are very much in 
>>  >> line with the RTEMS coding style. However, it wasn't really clear if 
>>  >> we will chage the RTEMS coding style or try to make changes to 
>>  >> clang-format to fit the style.
>>  >> Please will love to know the best option.
>>  >>
>>  > We will likely need to consider our choices carefully. If we can find
>>  > a suitably close style that is already well-supported by clang, and
>>  > get consensus from the maintainers on a change, then that might be the
>>  > best route forward.
>> 
>>  +1
>> 
>>  > I think the first thing to do is take the examples
>>  > that have been shown by Sebastian that are "close" but not quite
>>  > perfect, and identify the cases where they differ with RTEMS style in
>>  > order to present for discussion here. If consensus can't be reached to
>>  > change the style, then we would need to have a plan for how to improve
>>  > the existing tools for

Re: GSoC - Code Formatting and Style Checking for RTEMS score

[Ida Delphine]

Hello everyone,

I applied the configuration Sebastian used and ran clang-format on
cpukit/score/src/threadqenque.c and so far these are the differences I
could notice...
Below are some example areas in the code you can spot the differences:

   - In line 68, the ")" at the end of the parameter list needs to be in a
   new row, but this doesn't seem to be supported in clang-format.
   - In line 142, if the function call is split into multiple rows, the
   ");" should always be in a new row.
   - In line 201-202, we can see that the "*" of the pointers are not
   aligned to the right.

You can check out the formatted file here - https://pastebin.com/nDBrSSCP



On Tue, Jun 1, 2021 at 5:36 PM Gedare Bloom  wrote:

> On Mon, May 31, 2021 at 2:59 PM Ida Delphine  wrote:
> >
> > Hi Gedare,
> >
> > With regards to your comment on discord on me looking for a tool that
> works on both patches and source files, it turns out clang-format has that
> functionality already. Here's what I found -
> https://clang.llvm.org/docs/ClangFormat.html#script-for-patch-reformatting
> >
> > Does it match what you have in mind?
> >
> Yes. I think we would want to not use the `-i` option but instead pass
> through and check the changes. I don't think we should rewrite the
> patches themselves, but instead we want to use a tool that can be used
> to check and approve the style of submitted patches. You might need to
> write a modified version of the clang-format-diff.py to use as a
> "checker" with ability to provide exceptions to the rules.
>
> Gedare
>
> > On Thu, May 13, 2021 at 3:49 PM Gedare Bloom  wrote:
> >>
> >> On Wed, May 12, 2021 at 2:18 PM Ida Delphine  wrote:
> >> >
> >> > Hello everyone,
> >> > Still waiting for some feedback :)
> >> >
> >> > Cheers,
> >> > Ida.
> >> >
> >> > On Mon, 10 May 2021, 5:59 am Ida Delphine,  wrote:
> >> >>
> >> >> Hello everyone,
> >> >> Went through some previous emails and it turns out Sebastian already
> came up with a configuration for clang format which works well for RTEMS
> except for the fact that some configurations haven't been implemented into
> clang-format yet. Using
> >> >>
> >> >> AlignConsecutiveDeclarations: false
> >> >> PointerAlignment: Right
> >> >>
> >> >> Doesn't seem to work.
> >> >> For example in the cpukit/score/src/threadq.c file, something like
> >> >>
> >> >> RTEMS_STATIC_ASSERT(
> >> >> offsetof( Thread_queue_Syslock_queue, Queue.name )
> >> >> == offsetof( struct _Thread_queue_Queue, _name ),
> >> >> THREAD_QUEUE_SYSLOCK_QUEUE_NAME
> >> >> );
> >> >>
> >> >> RTEMS_STATIC_ASSERT(
> >> >> sizeof( Thread_queue_Syslock_queue )
> >> >> == sizeof( struct _Thread_queue_Queue ),
> >> >> THREAD_QUEUE_SYSLOCK_QUEUE_SIZE
> >> >> );
> >> >>
> >> >> #if defined(RTEMS_SMP)
> >> >> void _Thread_queue_Do_acquire_critical(
> >> >> Thread_queue_Control *the_thread_queue,
> >> >> ISR_lock_Context *lock_context
> >> >> )
> >> >> {
> >> >> _Thread_queue_Queue_acquire_critical(
> >> >> &the_thread_queue->Queue,
> >> >> &the_thread_queue->Lock_stats,
> >> >> lock_context
> >> >> );
> >> >>
> >> >> becomes this after using the given configuration
> >> >>
> >> >> RTEMS_STATIC_ASSERT(sizeof(Thread_queue_Syslock_queue) ==
> >> >> sizeof(struct _Thread_queue_Queue),
> >> >> THREAD_QUEUE_SYSLOCK_QUEUE_SIZE);
> >> >>
> >> >> #if defined(RTEMS_SMP)
> >> >> void _Thread_queue_Do_acquire_critical(Thread_queue_Control
> *the_thread_queue,
> >> >> ISR_lock_Context *lock_context) {
> >> >> _Thread_queue_Queue_acquire_critical(
> >> >> &the_thread_queue->Queue, &the_thread_queue->Lock_stats,
> lock_context);
> >> >>
> >> >> Everything seems manageable except for this alignment issue...
> >> >> This also throws more light on the changes using clang-format (
> https://lists.rtems.org/pipermail/devel/2018-December/024145.html)
> >> >>
> >> I think we're willing to concede the pointer alignment. However, it
> >> would be worth spending some time to see if
> >> https://reviews.llvm.org/D27651 can be made to work. The current state
> >> of the code would need to be compared to the patch on that review
> >> board.
> >>
> >> Beyond that, documenting the clang-format options to use is next, and
> >> then identifying a plan how to invoke clang-format during a git
> >> workflow is needed.
> >>
> >> >> On Thu, May 6, 2021 at 8:05 PM Joel Sherrill  wrote:
> >> >>>
> >> >>>
> >> >>>
> >> >>> On Thu, May 6, 2021 at 12:47 PM Christian Mauderer <
> o...@c-mauderer.de> wrote:
> >> 
> >>  Hello Ida and Gedare,
> >> 
> >>  On 06/05/2021 06:26, Gedare Bloom wrote:
> >>  > hi Ida,
> >>  >
> >>  > On Wed, May 5, 2021 at 3:21 PM Ida Delphine 
> wrote:
> >>  >>
> >>  >> Hello everyone,
> >>  >>
> >>  >> Regarding this project (https://devel.rtems.org/ticket/3860) I
> went with clang-format as we all agreed. I have tested it on some "score"
> files and it made some changes which I don't think are very much in line
> with the RTEMS coding style. However, it wasn't really clear if 

Re: GSoC - Code Formatting and Style Checking for RTEMS score

[Joel Sherrill]

On Fri, Jun 4, 2021 at 12:24 AM Ida Delphine  wrote:

> Hello everyone,
>
> I applied the configuration Sebastian used and ran clang-format on
> cpukit/score/src/threadqenque.c and so far these are the differences I
> could notice...
> Below are some example areas in the code you can spot the differences:
>
>- In line 68, the ")" at the end of the parameter list needs to be in
>a new row, but this doesn't seem to be supported in clang-format.
>
> If I understand correctly, clang-format does not like:

https://git.rtems.org/rtems/tree/cpukit/score/src/threadqenqueue.c

which has the first parameter on its one line but wants the first parameter
after the open parenthesis?

The RTEMS style would seem to correspond to AlignAfterOpenBracket being
set to AlwaysBreak


>
>- In line 142, if the function call is split into multiple rows, the
>");" should always be in a new row.
>
> Having the closing parenthesis on its own line may end up being something
we have to change the RTEMS style on. I do not see an option in their
documentation to do this. Unfortunate, since I like the symmetry between
braces and parentheses.

 Could you file an issue with them and/or ask a question the appropriate
mailing list? Please cc Gedara and me. Give them an example. Maybe
we are missing something.

>
>- In line 201-202, we can see that the "*" of the pointers are not
>aligned to the right.
>
>
This seems to be the issue Gedare mentioned which might have a patch.
Follow up on that.

But I think we had previously discussed this as a point we may have to
concede and change RTEMS style on.

> You can check out the formatted file here - https://pastebin.com/nDBrSSCP
>

Is it just the website or are blank line differences? It may just be an
illusion. I think the spacing between the numbered lines is greater
than in the git view. Just odd.

--joel

>
>
> On Tue, Jun 1, 2021 at 5:36 PM Gedare Bloom  wrote:
>
>> On Mon, May 31, 2021 at 2:59 PM Ida Delphine  wrote:
>> >
>> > Hi Gedare,
>> >
>> > With regards to your comment on discord on me looking for a tool that
>> works on both patches and source files, it turns out clang-format has that
>> functionality already. Here's what I found -
>> https://clang.llvm.org/docs/ClangFormat.html#script-for-patch-reformatting
>> >
>> > Does it match what you have in mind?
>> >
>> Yes. I think we would want to not use the `-i` option but instead pass
>> through and check the changes. I don't think we should rewrite the
>> patches themselves, but instead we want to use a tool that can be used
>> to check and approve the style of submitted patches. You might need to
>> write a modified version of the clang-format-diff.py to use as a
>> "checker" with ability to provide exceptions to the rules.
>>
>> Gedare
>>
>> > On Thu, May 13, 2021 at 3:49 PM Gedare Bloom  wrote:
>> >>
>> >> On Wed, May 12, 2021 at 2:18 PM Ida Delphine 
>> wrote:
>> >> >
>> >> > Hello everyone,
>> >> > Still waiting for some feedback :)
>> >> >
>> >> > Cheers,
>> >> > Ida.
>> >> >
>> >> > On Mon, 10 May 2021, 5:59 am Ida Delphine, 
>> wrote:
>> >> >>
>> >> >> Hello everyone,
>> >> >> Went through some previous emails and it turns out Sebastian
>> already came up with a configuration for clang format which works well for
>> RTEMS except for the fact that some configurations haven't been implemented
>> into clang-format yet. Using
>> >> >>
>> >> >> AlignConsecutiveDeclarations: false
>> >> >> PointerAlignment: Right
>> >> >>
>> >> >> Doesn't seem to work.
>> >> >> For example in the cpukit/score/src/threadq.c file, something like
>> >> >>
>> >> >> RTEMS_STATIC_ASSERT(
>> >> >> offsetof( Thread_queue_Syslock_queue, Queue.name )
>> >> >> == offsetof( struct _Thread_queue_Queue, _name ),
>> >> >> THREAD_QUEUE_SYSLOCK_QUEUE_NAME
>> >> >> );
>> >> >>
>> >> >> RTEMS_STATIC_ASSERT(
>> >> >> sizeof( Thread_queue_Syslock_queue )
>> >> >> == sizeof( struct _Thread_queue_Queue ),
>> >> >> THREAD_QUEUE_SYSLOCK_QUEUE_SIZE
>> >> >> );
>> >> >>
>> >> >> #if defined(RTEMS_SMP)
>> >> >> void _Thread_queue_Do_acquire_critical(
>> >> >> Thread_queue_Control *the_thread_queue,
>> >> >> ISR_lock_Context *lock_context
>> >> >> )
>> >> >> {
>> >> >> _Thread_queue_Queue_acquire_critical(
>> >> >> &the_thread_queue->Queue,
>> >> >> &the_thread_queue->Lock_stats,
>> >> >> lock_context
>> >> >> );
>> >> >>
>> >> >> becomes this after using the given configuration
>> >> >>
>> >> >> RTEMS_STATIC_ASSERT(sizeof(Thread_queue_Syslock_queue) ==
>> >> >> sizeof(struct _Thread_queue_Queue),
>> >> >> THREAD_QUEUE_SYSLOCK_QUEUE_SIZE);
>> >> >>
>> >> >> #if defined(RTEMS_SMP)
>> >> >> void _Thread_queue_Do_acquire_critical(Thread_queue_Control
>> *the_thread_queue,
>> >> >> ISR_lock_Context *lock_context) {
>> >> >> _Thread_queue_Queue_acquire_critical(
>> >> >> &the_thread_queue->Queue, &the_thread_queue->Lock_stats,
>> lock_context);
>> >> >>
>> >> >> Everything seems manageable except for this alignment issue...
>> >> >> This also throws more light 

Re: GSoC - Code Formatting and Style Checking for RTEMS score

[Gedare Bloom]

On Fri, Jun 4, 2021 at 8:47 AM Joel Sherrill  wrote:
>
>
>
> On Fri, Jun 4, 2021 at 12:24 AM Ida Delphine  wrote:
>>
>> Hello everyone,
>>
>> I applied the configuration Sebastian used and ran clang-format on 
>> cpukit/score/src/threadqenque.c and so far these are the differences I could 
>> notice...
>> Below are some example areas in the code you can spot the differences:
>>
>> In line 68, the ")" at the end of the parameter list needs to be in a new 
>> row, but this doesn't seem to be supported in clang-format.
>
> If I understand correctly, clang-format does not like:
>
> https://git.rtems.org/rtems/tree/cpukit/score/src/threadqenqueue.c
>
> which has the first parameter on its one line but wants the first parameter
> after the open parenthesis?
>
> The RTEMS style would seem to correspond to AlignAfterOpenBracket being
> set to AlwaysBreak
>
>>
>> In line 142, if the function call is split into multiple rows, the ");" 
>> should always be in a new row.
>
> Having the closing parenthesis on its own line may end up being something
> we have to change the RTEMS style on. I do not see an option in their
> documentation to do this. Unfortunate, since I like the symmetry between
> braces and parentheses.
>
>  Could you file an issue with them and/or ask a question the appropriate
> mailing list? Please cc Gedara and me. Give them an example. Maybe
> we are missing something.
>>
>> In line 201-202, we can see that the "*" of the pointers are not aligned to 
>> the right.
>
>
> This seems to be the issue Gedare mentioned which might have a patch.
> Follow up on that.
>
> But I think we had previously discussed this as a point we may have to
> concede and change RTEMS style on.
>>
>> You can check out the formatted file here - https://pastebin.com/nDBrSSCP
>
>
> Is it just the website or are blank line differences? It may just be an
> illusion. I think the spacing between the numbered lines is greater
> than in the git view. Just odd.
>
That's just the pastebin having more vertical padding between consecutive lines.

> --joel
>>
>>
>>
>> On Tue, Jun 1, 2021 at 5:36 PM Gedare Bloom  wrote:
>>>
>>> On Mon, May 31, 2021 at 2:59 PM Ida Delphine  wrote:
>>> >
>>> > Hi Gedare,
>>> >
>>> > With regards to your comment on discord on me looking for a tool that 
>>> > works on both patches and source files, it turns out clang-format has 
>>> > that functionality already. Here's what I found - 
>>> > https://clang.llvm.org/docs/ClangFormat.html#script-for-patch-reformatting
>>> >
>>> > Does it match what you have in mind?
>>> >
>>> Yes. I think we would want to not use the `-i` option but instead pass
>>> through and check the changes. I don't think we should rewrite the
>>> patches themselves, but instead we want to use a tool that can be used
>>> to check and approve the style of submitted patches. You might need to
>>> write a modified version of the clang-format-diff.py to use as a
>>> "checker" with ability to provide exceptions to the rules.
>>>
>>> Gedare
>>>
>>> > On Thu, May 13, 2021 at 3:49 PM Gedare Bloom  wrote:
>>> >>
>>> >> On Wed, May 12, 2021 at 2:18 PM Ida Delphine  wrote:
>>> >> >
>>> >> > Hello everyone,
>>> >> > Still waiting for some feedback :)
>>> >> >
>>> >> > Cheers,
>>> >> > Ida.
>>> >> >
>>> >> > On Mon, 10 May 2021, 5:59 am Ida Delphine,  wrote:
>>> >> >>
>>> >> >> Hello everyone,
>>> >> >> Went through some previous emails and it turns out Sebastian already 
>>> >> >> came up with a configuration for clang format which works well for 
>>> >> >> RTEMS except for the fact that some configurations haven't been 
>>> >> >> implemented into clang-format yet. Using
>>> >> >>
>>> >> >> AlignConsecutiveDeclarations: false
>>> >> >> PointerAlignment: Right
>>> >> >>
>>> >> >> Doesn't seem to work.
>>> >> >> For example in the cpukit/score/src/threadq.c file, something like
>>> >> >>
>>> >> >> RTEMS_STATIC_ASSERT(
>>> >> >> offsetof( Thread_queue_Syslock_queue, Queue.name )
>>> >> >> == offsetof( struct _Thread_queue_Queue, _name ),
>>> >> >> THREAD_QUEUE_SYSLOCK_QUEUE_NAME
>>> >> >> );
>>> >> >>
>>> >> >> RTEMS_STATIC_ASSERT(
>>> >> >> sizeof( Thread_queue_Syslock_queue )
>>> >> >> == sizeof( struct _Thread_queue_Queue ),
>>> >> >> THREAD_QUEUE_SYSLOCK_QUEUE_SIZE
>>> >> >> );
>>> >> >>
>>> >> >> #if defined(RTEMS_SMP)
>>> >> >> void _Thread_queue_Do_acquire_critical(
>>> >> >> Thread_queue_Control *the_thread_queue,
>>> >> >> ISR_lock_Context *lock_context
>>> >> >> )
>>> >> >> {
>>> >> >> _Thread_queue_Queue_acquire_critical(
>>> >> >> &the_thread_queue->Queue,
>>> >> >> &the_thread_queue->Lock_stats,
>>> >> >> lock_context
>>> >> >> );
>>> >> >>
>>> >> >> becomes this after using the given configuration
>>> >> >>
>>> >> >> RTEMS_STATIC_ASSERT(sizeof(Thread_queue_Syslock_queue) ==
>>> >> >> sizeof(struct _Thread_queue_Queue),
>>> >> >> THREAD_QUEUE_SYSLOCK_QUEUE_SIZE);
>>> >> >>
>>> >> >> #if defined(RTEMS_SMP)
>>> >> >> void _Thread_queue_Do_acquire_critical(Thread_queue_Control 
>>> >> >> *the_thr

Re: GSoC - Code Formatting and Style Checking for RTEMS score

[Joel Sherrill]

On Fri, Jun 4, 2021 at 12:39 PM Gedare Bloom  wrote:

> On Fri, Jun 4, 2021 at 8:47 AM Joel Sherrill  wrote:
> >
> >
> >
> > On Fri, Jun 4, 2021 at 12:24 AM Ida Delphine  wrote:
> >>
> >> Hello everyone,
> >>
> >> I applied the configuration Sebastian used and ran clang-format on
> cpukit/score/src/threadqenque.c and so far these are the differences I
> could notice...
> >> Below are some example areas in the code you can spot the differences:
> >>
> >> In line 68, the ")" at the end of the parameter list needs to be in a
> new row, but this doesn't seem to be supported in clang-format.
> >
> > If I understand correctly, clang-format does not like:
> >
> > https://git.rtems.org/rtems/tree/cpukit/score/src/threadqenqueue.c
> >
> > which has the first parameter on its one line but wants the first
> parameter
> > after the open parenthesis?
> >
> > The RTEMS style would seem to correspond to AlignAfterOpenBracket being
> > set to AlwaysBreak
> >
> >>
> >> In line 142, if the function call is split into multiple rows, the ");"
> should always be in a new row.
> >
> > Having the closing parenthesis on its own line may end up being something
> > we have to change the RTEMS style on. I do not see an option in their
> > documentation to do this. Unfortunate, since I like the symmetry between
> > braces and parentheses.
> >
> >  Could you file an issue with them and/or ask a question the appropriate
> > mailing list? Please cc Gedara and me. Give them an example. Maybe
> > we are missing something.
> >>
> >> In line 201-202, we can see that the "*" of the pointers are not
> aligned to the right.
> >
> >
> > This seems to be the issue Gedare mentioned which might have a patch.
> > Follow up on that.
> >
> > But I think we had previously discussed this as a point we may have to
> > concede and change RTEMS style on.
> >>
> >> You can check out the formatted file here -
> https://pastebin.com/nDBrSSCP
> >
> >
> > Is it just the website or are blank line differences? It may just be an
> > illusion. I think the spacing between the numbered lines is greater
> > than in the git view. Just odd.
> >
> That's just the pastebin having more vertical padding between consecutive
> lines.
>

That's what I thought but it did make the code look funny.

Ida/Gedare.. does this mean there are only 3 style mismatch issues? Or only
three in this file?

Probably should try a few more files and see if there are other
discrepancies.

And obviously work on the integration/automation of using the tools. :)

--joel


>
> > --joel
> >>
> >>
> >>
> >> On Tue, Jun 1, 2021 at 5:36 PM Gedare Bloom  wrote:
> >>>
> >>> On Mon, May 31, 2021 at 2:59 PM Ida Delphine 
> wrote:
> >>> >
> >>> > Hi Gedare,
> >>> >
> >>> > With regards to your comment on discord on me looking for a tool
> that works on both patches and source files, it turns out clang-format has
> that functionality already. Here's what I found -
> https://clang.llvm.org/docs/ClangFormat.html#script-for-patch-reformatting
> >>> >
> >>> > Does it match what you have in mind?
> >>> >
> >>> Yes. I think we would want to not use the `-i` option but instead pass
> >>> through and check the changes. I don't think we should rewrite the
> >>> patches themselves, but instead we want to use a tool that can be used
> >>> to check and approve the style of submitted patches. You might need to
> >>> write a modified version of the clang-format-diff.py to use as a
> >>> "checker" with ability to provide exceptions to the rules.
> >>>
> >>> Gedare
> >>>
> >>> > On Thu, May 13, 2021 at 3:49 PM Gedare Bloom 
> wrote:
> >>> >>
> >>> >> On Wed, May 12, 2021 at 2:18 PM Ida Delphine 
> wrote:
> >>> >> >
> >>> >> > Hello everyone,
> >>> >> > Still waiting for some feedback :)
> >>> >> >
> >>> >> > Cheers,
> >>> >> > Ida.
> >>> >> >
> >>> >> > On Mon, 10 May 2021, 5:59 am Ida Delphine, 
> wrote:
> >>> >> >>
> >>> >> >> Hello everyone,
> >>> >> >> Went through some previous emails and it turns out Sebastian
> already came up with a configuration for clang format which works well for
> RTEMS except for the fact that some configurations haven't been implemented
> into clang-format yet. Using
> >>> >> >>
> >>> >> >> AlignConsecutiveDeclarations: false
> >>> >> >> PointerAlignment: Right
> >>> >> >>
> >>> >> >> Doesn't seem to work.
> >>> >> >> For example in the cpukit/score/src/threadq.c file, something
> like
> >>> >> >>
> >>> >> >> RTEMS_STATIC_ASSERT(
> >>> >> >> offsetof( Thread_queue_Syslock_queue, Queue.name )
> >>> >> >> == offsetof( struct _Thread_queue_Queue, _name ),
> >>> >> >> THREAD_QUEUE_SYSLOCK_QUEUE_NAME
> >>> >> >> );
> >>> >> >>
> >>> >> >> RTEMS_STATIC_ASSERT(
> >>> >> >> sizeof( Thread_queue_Syslock_queue )
> >>> >> >> == sizeof( struct _Thread_queue_Queue ),
> >>> >> >> THREAD_QUEUE_SYSLOCK_QUEUE_SIZE
> >>> >> >> );
> >>> >> >>
> >>> >> >> #if defined(RTEMS_SMP)
> >>> >> >> void _Thread_queue_Do_acquire_critical(
> >>> >> >> Thread_queue_Control *the_thread_queue,
> >>> >> >> ISR_lock_Context *lo

Re: GSoC - Code Formatting and Style Checking for RTEMS score

[Ida Delphine]

Okay, I will take a look.

Regarding me asking a question in the appropriate clang-format mailing list
should it be just regarding the parentheses and braces being aligned?

On Fri, Jun 4, 2021 at 8:41 PM Joel Sherrill  wrote:

>
>
> On Fri, Jun 4, 2021 at 12:39 PM Gedare Bloom  wrote:
>
>> On Fri, Jun 4, 2021 at 8:47 AM Joel Sherrill  wrote:
>> >
>> >
>> >
>> > On Fri, Jun 4, 2021 at 12:24 AM Ida Delphine  wrote:
>> >>
>> >> Hello everyone,
>> >>
>> >> I applied the configuration Sebastian used and ran clang-format on
>> cpukit/score/src/threadqenque.c and so far these are the differences I
>> could notice...
>> >> Below are some example areas in the code you can spot the differences:
>> >>
>> >> In line 68, the ")" at the end of the parameter list needs to be in a
>> new row, but this doesn't seem to be supported in clang-format.
>> >
>> > If I understand correctly, clang-format does not like:
>> >
>> > https://git.rtems.org/rtems/tree/cpukit/score/src/threadqenqueue.c
>> >
>> > which has the first parameter on its one line but wants the first
>> parameter
>> > after the open parenthesis?
>> >
>> > The RTEMS style would seem to correspond to AlignAfterOpenBracket being
>> > set to AlwaysBreak
>> >
>> >>
>> >> In line 142, if the function call is split into multiple rows, the
>> ");" should always be in a new row.
>> >
>> > Having the closing parenthesis on its own line may end up being
>> something
>> > we have to change the RTEMS style on. I do not see an option in their
>> > documentation to do this. Unfortunate, since I like the symmetry between
>> > braces and parentheses.
>> >
>> >  Could you file an issue with them and/or ask a question the appropriate
>> > mailing list? Please cc Gedara and me. Give them an example. Maybe
>> > we are missing something.
>> >>
>> >> In line 201-202, we can see that the "*" of the pointers are not
>> aligned to the right.
>> >
>> >
>> > This seems to be the issue Gedare mentioned which might have a patch.
>> > Follow up on that.
>> >
>> > But I think we had previously discussed this as a point we may have to
>> > concede and change RTEMS style on.
>> >>
>> >> You can check out the formatted file here -
>> https://pastebin.com/nDBrSSCP
>> >
>> >
>> > Is it just the website or are blank line differences? It may just be an
>> > illusion. I think the spacing between the numbered lines is greater
>> > than in the git view. Just odd.
>> >
>> That's just the pastebin having more vertical padding between consecutive
>> lines.
>>
>
> That's what I thought but it did make the code look funny.
>
> Ida/Gedare.. does this mean there are only 3 style mismatch issues? Or
> only
> three in this file?
>
> Probably should try a few more files and see if there are other
> discrepancies.
>
> And obviously work on the integration/automation of using the tools. :)
>
> --joel
>
>
>>
>> > --joel
>> >>
>> >>
>> >>
>> >> On Tue, Jun 1, 2021 at 5:36 PM Gedare Bloom  wrote:
>> >>>
>> >>> On Mon, May 31, 2021 at 2:59 PM Ida Delphine 
>> wrote:
>> >>> >
>> >>> > Hi Gedare,
>> >>> >
>> >>> > With regards to your comment on discord on me looking for a tool
>> that works on both patches and source files, it turns out clang-format has
>> that functionality already. Here's what I found -
>> https://clang.llvm.org/docs/ClangFormat.html#script-for-patch-reformatting
>> >>> >
>> >>> > Does it match what you have in mind?
>> >>> >
>> >>> Yes. I think we would want to not use the `-i` option but instead pass
>> >>> through and check the changes. I don't think we should rewrite the
>> >>> patches themselves, but instead we want to use a tool that can be used
>> >>> to check and approve the style of submitted patches. You might need to
>> >>> write a modified version of the clang-format-diff.py to use as a
>> >>> "checker" with ability to provide exceptions to the rules.
>> >>>
>> >>> Gedare
>> >>>
>> >>> > On Thu, May 13, 2021 at 3:49 PM Gedare Bloom 
>> wrote:
>> >>> >>
>> >>> >> On Wed, May 12, 2021 at 2:18 PM Ida Delphine 
>> wrote:
>> >>> >> >
>> >>> >> > Hello everyone,
>> >>> >> > Still waiting for some feedback :)
>> >>> >> >
>> >>> >> > Cheers,
>> >>> >> > Ida.
>> >>> >> >
>> >>> >> > On Mon, 10 May 2021, 5:59 am Ida Delphine, 
>> wrote:
>> >>> >> >>
>> >>> >> >> Hello everyone,
>> >>> >> >> Went through some previous emails and it turns out Sebastian
>> already came up with a configuration for clang format which works well for
>> RTEMS except for the fact that some configurations haven't been implemented
>> into clang-format yet. Using
>> >>> >> >>
>> >>> >> >> AlignConsecutiveDeclarations: false
>> >>> >> >> PointerAlignment: Right
>> >>> >> >>
>> >>> >> >> Doesn't seem to work.
>> >>> >> >> For example in the cpukit/score/src/threadq.c file, something
>> like
>> >>> >> >>
>> >>> >> >> RTEMS_STATIC_ASSERT(
>> >>> >> >> offsetof( Thread_queue_Syslock_queue, Queue.name )
>> >>> >> >> == offsetof( struct _Thread_queue_Queue, _name ),
>> >>> >> >> THREAD_QUEUE_SYSLOCK_QUEUE_NAME
>> >>> >> >> );
>> >>>

Re: GSoC - Code Formatting and Style Checking for RTEMS score

[Gedare Bloom]

On Fri, Jun 4, 2021 at 2:57 PM Ida Delphine  wrote:
>
> Okay, I will take a look.
>
> Regarding me asking a question in the appropriate clang-format mailing list 
> should it be just regarding the parentheses and braces being aligned?
>
That would be the right question to ask, if you can't find a way to
align the closing parenthesis.

You might also follow-up that old thread related to alignment of the pointers.

> On Fri, Jun 4, 2021 at 8:41 PM Joel Sherrill  wrote:
>>
>>
>>
>> On Fri, Jun 4, 2021 at 12:39 PM Gedare Bloom  wrote:
>>>
>>> On Fri, Jun 4, 2021 at 8:47 AM Joel Sherrill  wrote:
>>> >
>>> >
>>> >
>>> > On Fri, Jun 4, 2021 at 12:24 AM Ida Delphine  wrote:
>>> >>
>>> >> Hello everyone,
>>> >>
>>> >> I applied the configuration Sebastian used and ran clang-format on 
>>> >> cpukit/score/src/threadqenque.c and so far these are the differences I 
>>> >> could notice...
>>> >> Below are some example areas in the code you can spot the differences:
>>> >>
>>> >> In line 68, the ")" at the end of the parameter list needs to be in a 
>>> >> new row, but this doesn't seem to be supported in clang-format.
>>> >
>>> > If I understand correctly, clang-format does not like:
>>> >
>>> > https://git.rtems.org/rtems/tree/cpukit/score/src/threadqenqueue.c
>>> >
>>> > which has the first parameter on its one line but wants the first 
>>> > parameter
>>> > after the open parenthesis?
>>> >
>>> > The RTEMS style would seem to correspond to AlignAfterOpenBracket being
>>> > set to AlwaysBreak
>>> >
>>> >>
>>> >> In line 142, if the function call is split into multiple rows, the ");" 
>>> >> should always be in a new row.
>>> >
>>> > Having the closing parenthesis on its own line may end up being something
>>> > we have to change the RTEMS style on. I do not see an option in their
>>> > documentation to do this. Unfortunate, since I like the symmetry between
>>> > braces and parentheses.
>>> >
>>> >  Could you file an issue with them and/or ask a question the appropriate
>>> > mailing list? Please cc Gedara and me. Give them an example. Maybe
>>> > we are missing something.
>>> >>
>>> >> In line 201-202, we can see that the "*" of the pointers are not aligned 
>>> >> to the right.
>>> >
>>> >
>>> > This seems to be the issue Gedare mentioned which might have a patch.
>>> > Follow up on that.
>>> >
>>> > But I think we had previously discussed this as a point we may have to
>>> > concede and change RTEMS style on.
>>> >>
>>> >> You can check out the formatted file here - https://pastebin.com/nDBrSSCP
>>> >
>>> >
>>> > Is it just the website or are blank line differences? It may just be an
>>> > illusion. I think the spacing between the numbered lines is greater
>>> > than in the git view. Just odd.
>>> >
>>> That's just the pastebin having more vertical padding between consecutive 
>>> lines.
>>
>>
>> That's what I thought but it did make the code look funny.
>>
>> Ida/Gedare.. does this mean there are only 3 style mismatch issues? Or only
>> three in this file?
>>
>> Probably should try a few more files and see if there are other 
>> discrepancies.
>>
>> And obviously work on the integration/automation of using the tools. :)
>>
>> --joel
>>
>>>
>>>
>>> > --joel
>>> >>
>>> >>
>>> >>
>>> >> On Tue, Jun 1, 2021 at 5:36 PM Gedare Bloom  wrote:
>>> >>>
>>> >>> On Mon, May 31, 2021 at 2:59 PM Ida Delphine  wrote:
>>> >>> >
>>> >>> > Hi Gedare,
>>> >>> >
>>> >>> > With regards to your comment on discord on me looking for a tool that 
>>> >>> > works on both patches and source files, it turns out clang-format has 
>>> >>> > that functionality already. Here's what I found - 
>>> >>> > https://clang.llvm.org/docs/ClangFormat.html#script-for-patch-reformatting
>>> >>> >
>>> >>> > Does it match what you have in mind?
>>> >>> >
>>> >>> Yes. I think we would want to not use the `-i` option but instead pass
>>> >>> through and check the changes. I don't think we should rewrite the
>>> >>> patches themselves, but instead we want to use a tool that can be used
>>> >>> to check and approve the style of submitted patches. You might need to
>>> >>> write a modified version of the clang-format-diff.py to use as a
>>> >>> "checker" with ability to provide exceptions to the rules.
>>> >>>
>>> >>> Gedare
>>> >>>
>>> >>> > On Thu, May 13, 2021 at 3:49 PM Gedare Bloom  wrote:
>>> >>> >>
>>> >>> >> On Wed, May 12, 2021 at 2:18 PM Ida Delphine  
>>> >>> >> wrote:
>>> >>> >> >
>>> >>> >> > Hello everyone,
>>> >>> >> > Still waiting for some feedback :)
>>> >>> >> >
>>> >>> >> > Cheers,
>>> >>> >> > Ida.
>>> >>> >> >
>>> >>> >> > On Mon, 10 May 2021, 5:59 am Ida Delphine,  
>>> >>> >> > wrote:
>>> >>> >> >>
>>> >>> >> >> Hello everyone,
>>> >>> >> >> Went through some previous emails and it turns out Sebastian 
>>> >>> >> >> already came up with a configuration for clang format which works 
>>> >>> >> >> well for RTEMS except for the fact that some configurations 
>>> >>> >> >> haven't been implemented into clang-format yet. Using
>>> >>> >> >>
>>

Re: GSoC - Code Formatting and Style Checking for RTEMS score

[Ida Delphine]

Okay. I will do that.

On Fri, 4 Jun 2021, 10:48 pm Gedare Bloom,  wrote:

> On Fri, Jun 4, 2021 at 2:57 PM Ida Delphine  wrote:
> >
> > Okay, I will take a look.
> >
> > Regarding me asking a question in the appropriate clang-format mailing
> list should it be just regarding the parentheses and braces being aligned?
> >
> That would be the right question to ask, if you can't find a way to
> align the closing parenthesis.
>
> You might also follow-up that old thread related to alignment of the
> pointers.
>
> > On Fri, Jun 4, 2021 at 8:41 PM Joel Sherrill  wrote:
> >>
> >>
> >>
> >> On Fri, Jun 4, 2021 at 12:39 PM Gedare Bloom  wrote:
> >>>
> >>> On Fri, Jun 4, 2021 at 8:47 AM Joel Sherrill  wrote:
> >>> >
> >>> >
> >>> >
> >>> > On Fri, Jun 4, 2021 at 12:24 AM Ida Delphine 
> wrote:
> >>> >>
> >>> >> Hello everyone,
> >>> >>
> >>> >> I applied the configuration Sebastian used and ran clang-format on
> cpukit/score/src/threadqenque.c and so far these are the differences I
> could notice...
> >>> >> Below are some example areas in the code you can spot the
> differences:
> >>> >>
> >>> >> In line 68, the ")" at the end of the parameter list needs to be in
> a new row, but this doesn't seem to be supported in clang-format.
> >>> >
> >>> > If I understand correctly, clang-format does not like:
> >>> >
> >>> > https://git.rtems.org/rtems/tree/cpukit/score/src/threadqenqueue.c
> >>> >
> >>> > which has the first parameter on its one line but wants the first
> parameter
> >>> > after the open parenthesis?
> >>> >
> >>> > The RTEMS style would seem to correspond to AlignAfterOpenBracket
> being
> >>> > set to AlwaysBreak
> >>> >
> >>> >>
> >>> >> In line 142, if the function call is split into multiple rows, the
> ");" should always be in a new row.
> >>> >
> >>> > Having the closing parenthesis on its own line may end up being
> something
> >>> > we have to change the RTEMS style on. I do not see an option in their
> >>> > documentation to do this. Unfortunate, since I like the symmetry
> between
> >>> > braces and parentheses.
> >>> >
> >>> >  Could you file an issue with them and/or ask a question the
> appropriate
> >>> > mailing list? Please cc Gedara and me. Give them an example. Maybe
> >>> > we are missing something.
> >>> >>
> >>> >> In line 201-202, we can see that the "*" of the pointers are not
> aligned to the right.
> >>> >
> >>> >
> >>> > This seems to be the issue Gedare mentioned which might have a patch.
> >>> > Follow up on that.
> >>> >
> >>> > But I think we had previously discussed this as a point we may have
> to
> >>> > concede and change RTEMS style on.
> >>> >>
> >>> >> You can check out the formatted file here -
> https://pastebin.com/nDBrSSCP
> >>> >
> >>> >
> >>> > Is it just the website or are blank line differences? It may just be
> an
> >>> > illusion. I think the spacing between the numbered lines is greater
> >>> > than in the git view. Just odd.
> >>> >
> >>> That's just the pastebin having more vertical padding between
> consecutive lines.
> >>
> >>
> >> That's what I thought but it did make the code look funny.
> >>
> >> Ida/Gedare.. does this mean there are only 3 style mismatch issues? Or
> only
> >> three in this file?
> >>
> >> Probably should try a few more files and see if there are other
> discrepancies.
> >>
> >> And obviously work on the integration/automation of using the tools. :)
> >>
> >> --joel
> >>
> >>>
> >>>
> >>> > --joel
> >>> >>
> >>> >>
> >>> >>
> >>> >> On Tue, Jun 1, 2021 at 5:36 PM Gedare Bloom 
> wrote:
> >>> >>>
> >>> >>> On Mon, May 31, 2021 at 2:59 PM Ida Delphine 
> wrote:
> >>> >>> >
> >>> >>> > Hi Gedare,
> >>> >>> >
> >>> >>> > With regards to your comment on discord on me looking for a tool
> that works on both patches and source files, it turns out clang-format has
> that functionality already. Here's what I found -
> https://clang.llvm.org/docs/ClangFormat.html#script-for-patch-reformatting
> >>> >>> >
> >>> >>> > Does it match what you have in mind?
> >>> >>> >
> >>> >>> Yes. I think we would want to not use the `-i` option but instead
> pass
> >>> >>> through and check the changes. I don't think we should rewrite the
> >>> >>> patches themselves, but instead we want to use a tool that can be
> used
> >>> >>> to check and approve the style of submitted patches. You might
> need to
> >>> >>> write a modified version of the clang-format-diff.py to use as a
> >>> >>> "checker" with ability to provide exceptions to the rules.
> >>> >>>
> >>> >>> Gedare
> >>> >>>
> >>> >>> > On Thu, May 13, 2021 at 3:49 PM Gedare Bloom 
> wrote:
> >>> >>> >>
> >>> >>> >> On Wed, May 12, 2021 at 2:18 PM Ida Delphine 
> wrote:
> >>> >>> >> >
> >>> >>> >> > Hello everyone,
> >>> >>> >> > Still waiting for some feedback :)
> >>> >>> >> >
> >>> >>> >> > Cheers,
> >>> >>> >> > Ida.
> >>> >>> >> >
> >>> >>> >> > On Mon, 10 May 2021, 5:59 am Ida Delphine, 
> wrote:
> >>> >>> >> >>
> >>> >>> >> >> Hello everyone,
> >>> >>> >> >> Went through some previous emails and it tu

Re: GSoC - Code Formatting and Style Checking for RTEMS score

[Gedare Bloom]

On Sun, Jun 20, 2021 at 1:13 AM Ida Delphine  wrote:

> Hello everyone,
> I updated the hooks script. About the modes, we have the default, "strict"
> and "nonstrict" (couldn't think of better names). With the default mode, it
> prints a warning specifying the number of style issues if any and aborts
> the commit. With the strict mode, it goes into more detail showing both the
> formatted and unformatted patch, the number of style issues, and aborts the
> commit. In the non-strict mode, it simply displays the warning with the
> style issues and the commit happens.
>
> The default mode basically happens when you run
>
>> git commit -m "Commit message"
>>
> The best method I could find to pass arguments to a script was via
> environment variables. So the nonstrict mode applies when you run
>
>> STYLEMODE=nonstrict git commit -m "Commit message"
>>
> The strict mode applies when you run
>
>> STYLEMODE=strict git commit -m "Commit message"
>>
>
> What are the possible options to pass arguments? (Maybe, a blog post :))
Reading from a git-config file would be better than environment variables.

It might be better to share screenshots by a link (e.g., a blog post :)) to
avoid hitting the mailing list attachment limits.

Gedare

>
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: GSoC - Code Formatting and Style Checking for RTEMS score

[Ida Delphine]

Hello mentors,

Here is the code for my pre-commit hook script. How it works is by default,
upon commiting it outputs a warning stating the number of style issues in
case there are mismatches.
The user can trigger the strict mode which gives a more detailed output of
the style issues by running adding the mode to the config file ( git config
mode "strict") - will document this.

https://github.com/Idadelveloper/rtems/blob/master/hooks/pre-commit

I had already sent some screenshots here on how the outcome looks like.
Will love to improve my code based on your feedback and get more
suggestions.


On Mon, Jun 21, 2021 at 7:05 PM Gedare Bloom  wrote:

>
>
> On Sun, Jun 20, 2021 at 1:13 AM Ida Delphine  wrote:
>
>> Hello everyone,
>> I updated the hooks script. About the modes, we have the default,
>> "strict" and "nonstrict" (couldn't think of better names). With the default
>> mode, it prints a warning specifying the number of style issues if any and
>> aborts the commit. With the strict mode, it goes into more detail showing
>> both the formatted and unformatted patch, the number of style issues, and
>> aborts the commit. In the non-strict mode, it simply displays the warning
>> with the style issues and the commit happens.
>>
>> The default mode basically happens when you run
>>
>>> git commit -m "Commit message"
>>>
>> The best method I could find to pass arguments to a script was via
>> environment variables. So the nonstrict mode applies when you run
>>
>>> STYLEMODE=nonstrict git commit -m "Commit message"
>>>
>> The strict mode applies when you run
>>
>>> STYLEMODE=strict git commit -m "Commit message"
>>>
>>
>> What are the possible options to pass arguments? (Maybe, a blog post :))
> Reading from a git-config file would be better than environment variables.
>
> It might be better to share screenshots by a link (e.g., a blog post :))
> to avoid hitting the mailing list attachment limits.
>
> Gedare
>
>>
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: GSoC - Code Formatting and Style Checking for RTEMS score

[Gedare Bloom]

Hi Ida,

On Tue, Jun 29, 2021 at 1:11 PM Ida Delphine  wrote:
>
> Hello mentors,
>
> Here is the code for my pre-commit hook script. How it works is by default, 
> upon commiting it outputs a warning stating the number of style issues in 
> case there are mismatches.
> The user can trigger the strict mode which gives a more detailed output of 
> the style issues by running adding the mode to the config file ( git config 
> mode "strict") - will document this.
>
> https://github.com/Idadelveloper/rtems/blob/master/hooks/pre-commit
>
I made comments on your commit that added this:
https://github.com/Idadelveloper/rtems/commit/6bfc4802d17b3aab260190d53467b750848f0002

> I had already sent some screenshots here on how the outcome looks like. Will 
> love to improve my code based on your feedback and get more suggestions.
>
>
> On Mon, Jun 21, 2021 at 7:05 PM Gedare Bloom  wrote:
>>
>>
>>
>> On Sun, Jun 20, 2021 at 1:13 AM Ida Delphine  wrote:
>>>
>>> Hello everyone,
>>> I updated the hooks script. About the modes, we have the default, "strict" 
>>> and "nonstrict" (couldn't think of better names). With the default mode, it 
>>> prints a warning specifying the number of style issues if any and aborts 
>>> the commit. With the strict mode, it goes into more detail showing both the 
>>> formatted and unformatted patch, the number of style issues, and aborts the 
>>> commit. In the non-strict mode, it simply displays the warning with the 
>>> style issues and the commit happens.
>>>
>>> The default mode basically happens when you run

 git commit -m "Commit message"
>>>
>>> The best method I could find to pass arguments to a script was via 
>>> environment variables. So the nonstrict mode applies when you run

 STYLEMODE=nonstrict git commit -m "Commit message"
>>>
>>> The strict mode applies when you run

 STYLEMODE=strict git commit -m "Commit message"
>>>
>>>
>> What are the possible options to pass arguments? (Maybe, a blog post :)) 
>> Reading from a git-config file would be better than environment variables.
>>
>> It might be better to share screenshots by a link (e.g., a blog post :)) to 
>> avoid hitting the mailing list attachment limits.
>>
>> Gedare
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: GSoC - Code Formatting and Style Checking for RTEMS score

[Ida Delphine]

Thank you. I will make changes accordingly.

On Thu, 1 Jul 2021, 5:31 pm Gedare Bloom,  wrote:

> Hi Ida,
>
> On Tue, Jun 29, 2021 at 1:11 PM Ida Delphine  wrote:
> >
> > Hello mentors,
> >
> > Here is the code for my pre-commit hook script. How it works is by
> default, upon commiting it outputs a warning stating the number of style
> issues in case there are mismatches.
> > The user can trigger the strict mode which gives a more detailed output
> of the style issues by running adding the mode to the config file ( git
> config mode "strict") - will document this.
> >
> > https://github.com/Idadelveloper/rtems/blob/master/hooks/pre-commit
> >
> I made comments on your commit that added this:
>
> https://github.com/Idadelveloper/rtems/commit/6bfc4802d17b3aab260190d53467b750848f0002
>
> > I had already sent some screenshots here on how the outcome looks like.
> Will love to improve my code based on your feedback and get more
> suggestions.
> >
> >
> > On Mon, Jun 21, 2021 at 7:05 PM Gedare Bloom  wrote:
> >>
> >>
> >>
> >> On Sun, Jun 20, 2021 at 1:13 AM Ida Delphine  wrote:
> >>>
> >>> Hello everyone,
> >>> I updated the hooks script. About the modes, we have the default,
> "strict" and "nonstrict" (couldn't think of better names). With the default
> mode, it prints a warning specifying the number of style issues if any and
> aborts the commit. With the strict mode, it goes into more detail showing
> both the formatted and unformatted patch, the number of style issues, and
> aborts the commit. In the non-strict mode, it simply displays the warning
> with the style issues and the commit happens.
> >>>
> >>> The default mode basically happens when you run
> 
>  git commit -m "Commit message"
> >>>
> >>> The best method I could find to pass arguments to a script was via
> environment variables. So the nonstrict mode applies when you run
> 
>  STYLEMODE=nonstrict git commit -m "Commit message"
> >>>
> >>> The strict mode applies when you run
> 
>  STYLEMODE=strict git commit -m "Commit message"
> >>>
> >>>
> >> What are the possible options to pass arguments? (Maybe, a blog post
> :)) Reading from a git-config file would be better than environment
> variables.
> >>
> >> It might be better to share screenshots by a link (e.g., a blog post
> :)) to avoid hitting the mailing list attachment limits.
> >>
> >> Gedare
>
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: GSoC - Code Formatting and Style Checking for RTEMS score

[Ida Delphine]

Hello mentors,

I got some feedback and I have improved my code based on it -
https://github.com/Idadelveloper/rtems/blob/master/hooks/pre-commit
Will love to get some more feedback and ways to make it look better.
And is it okay I start working on its documentation though it hasn't been
approved yet?

Cheers,
Ida

On Thu, Jul 1, 2021 at 6:42 PM Ida Delphine  wrote:

> Thank you. I will make changes accordingly.
>
> On Thu, 1 Jul 2021, 5:31 pm Gedare Bloom,  wrote:
>
>> Hi Ida,
>>
>> On Tue, Jun 29, 2021 at 1:11 PM Ida Delphine  wrote:
>> >
>> > Hello mentors,
>> >
>> > Here is the code for my pre-commit hook script. How it works is by
>> default, upon commiting it outputs a warning stating the number of style
>> issues in case there are mismatches.
>> > The user can trigger the strict mode which gives a more detailed output
>> of the style issues by running adding the mode to the config file ( git
>> config mode "strict") - will document this.
>> >
>> > https://github.com/Idadelveloper/rtems/blob/master/hooks/pre-commit
>> >
>> I made comments on your commit that added this:
>>
>> https://github.com/Idadelveloper/rtems/commit/6bfc4802d17b3aab260190d53467b750848f0002
>>
>> > I had already sent some screenshots here on how the outcome looks like.
>> Will love to improve my code based on your feedback and get more
>> suggestions.
>> >
>> >
>> > On Mon, Jun 21, 2021 at 7:05 PM Gedare Bloom  wrote:
>> >>
>> >>
>> >>
>> >> On Sun, Jun 20, 2021 at 1:13 AM Ida Delphine 
>> wrote:
>> >>>
>> >>> Hello everyone,
>> >>> I updated the hooks script. About the modes, we have the default,
>> "strict" and "nonstrict" (couldn't think of better names). With the default
>> mode, it prints a warning specifying the number of style issues if any and
>> aborts the commit. With the strict mode, it goes into more detail showing
>> both the formatted and unformatted patch, the number of style issues, and
>> aborts the commit. In the non-strict mode, it simply displays the warning
>> with the style issues and the commit happens.
>> >>>
>> >>> The default mode basically happens when you run
>> 
>>  git commit -m "Commit message"
>> >>>
>> >>> The best method I could find to pass arguments to a script was via
>> environment variables. So the nonstrict mode applies when you run
>> 
>>  STYLEMODE=nonstrict git commit -m "Commit message"
>> >>>
>> >>> The strict mode applies when you run
>> 
>>  STYLEMODE=strict git commit -m "Commit message"
>> >>>
>> >>>
>> >> What are the possible options to pass arguments? (Maybe, a blog post
>> :)) Reading from a git-config file would be better than environment
>> variables.
>> >>
>> >> It might be better to share screenshots by a link (e.g., a blog post
>> :)) to avoid hitting the mailing list attachment limits.
>> >>
>> >> Gedare
>>
>
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: GSoC - Code Formatting and Style Checking for RTEMS score

[Ida Delphine]

Hello everyone,
I added the functionality for my script to ignore certain directories like
/bsps/, /testsuites/, '/cpukit/zlib', '/cpukit/mghttpd'.
https://github.com/Idadelveloper/rtems/blob/master/hooks/pre-commit
Are there any extra directories I should exclude?

Also open to more suggestions and feedback to make my code better :)

Cheers,
Ida.

On Sun, Jul 4, 2021 at 12:40 AM Ida Delphine  wrote:

> Hello mentors,
>
> I got some feedback and I have improved my code based on it -
> https://github.com/Idadelveloper/rtems/blob/master/hooks/pre-commit
> Will love to get some more feedback and ways to make it look better.
> And is it okay I start working on its documentation though it hasn't been
> approved yet?
>
> Cheers,
> Ida
>
> On Thu, Jul 1, 2021 at 6:42 PM Ida Delphine  wrote:
>
>> Thank you. I will make changes accordingly.
>>
>> On Thu, 1 Jul 2021, 5:31 pm Gedare Bloom,  wrote:
>>
>>> Hi Ida,
>>>
>>> On Tue, Jun 29, 2021 at 1:11 PM Ida Delphine  wrote:
>>> >
>>> > Hello mentors,
>>> >
>>> > Here is the code for my pre-commit hook script. How it works is by
>>> default, upon commiting it outputs a warning stating the number of style
>>> issues in case there are mismatches.
>>> > The user can trigger the strict mode which gives a more detailed
>>> output of the style issues by running adding the mode to the config file (
>>> git config mode "strict") - will document this.
>>> >
>>> > https://github.com/Idadelveloper/rtems/blob/master/hooks/pre-commit
>>> >
>>> I made comments on your commit that added this:
>>>
>>> https://github.com/Idadelveloper/rtems/commit/6bfc4802d17b3aab260190d53467b750848f0002
>>>
>>> > I had already sent some screenshots here on how the outcome looks
>>> like. Will love to improve my code based on your feedback and get more
>>> suggestions.
>>> >
>>> >
>>> > On Mon, Jun 21, 2021 at 7:05 PM Gedare Bloom  wrote:
>>> >>
>>> >>
>>> >>
>>> >> On Sun, Jun 20, 2021 at 1:13 AM Ida Delphine 
>>> wrote:
>>> >>>
>>> >>> Hello everyone,
>>> >>> I updated the hooks script. About the modes, we have the default,
>>> "strict" and "nonstrict" (couldn't think of better names). With the default
>>> mode, it prints a warning specifying the number of style issues if any and
>>> aborts the commit. With the strict mode, it goes into more detail showing
>>> both the formatted and unformatted patch, the number of style issues, and
>>> aborts the commit. In the non-strict mode, it simply displays the warning
>>> with the style issues and the commit happens.
>>> >>>
>>> >>> The default mode basically happens when you run
>>> 
>>>  git commit -m "Commit message"
>>> >>>
>>> >>> The best method I could find to pass arguments to a script was via
>>> environment variables. So the nonstrict mode applies when you run
>>> 
>>>  STYLEMODE=nonstrict git commit -m "Commit message"
>>> >>>
>>> >>> The strict mode applies when you run
>>> 
>>>  STYLEMODE=strict git commit -m "Commit message"
>>> >>>
>>> >>>
>>> >> What are the possible options to pass arguments? (Maybe, a blog post
>>> :)) Reading from a git-config file would be better than environment
>>> variables.
>>> >>
>>> >> It might be better to share screenshots by a link (e.g., a blog post
>>> :)) to avoid hitting the mailing list attachment limits.
>>> >>
>>> >> Gedare
>>>
>>
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: GSoC - Code Formatting and Style Checking for RTEMS score

[Sebastian Huber]

Hello Ida,

On 10/07/2021 01:08, Ida Delphine wrote:
I added the functionality for my script to ignore certain directories 
like /bsps/, /testsuites/, '/cpukit/zlib', '/cpukit/mghttpd'.
https://github.com/Idadelveloper/rtems/blob/master/hooks/pre-commit 


Are there any extra directories I should exclude?

Also open to more suggestions and feedback to make my code better :)


what do I have to do to test this pre-commit hook?

--
embedded brains GmbH
Herr Sebastian HUBER
Dornierstr. 4
82178 Puchheim
Germany
email: sebastian.hu...@embedded-brains.de
phone: +49-89-18 94 741 - 16
fax:   +49-89-18 94 741 - 08

Registergericht: Amtsgericht München
Registernummer: HRB 157899
Vertretungsberechtigte Geschäftsführer: Peter Rasmussen, Thomas Dörfler
Unsere Datenschutzerklärung finden Sie hier:
https://embedded-brains.de/datenschutzerklaerung/
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: GSoC - Code Formatting and Style Checking for RTEMS score

[Kuan-Hsun Chen]

Hello Ida,

It would be great if you make a README.md at
https://github.com/Idadelveloper/rtems/tree/master/hooks to guide potential
users how to use your pre-commit hook and provide some examples.

I tried to find the information from your blog, but the update stopped at
the second week (https://idadelveloper.github.io/blog/2021/05/21/gsoc-week2).
I don't know if the post has been updated by taking the suggestion from
Gedare, e.g., I read that some possible options to pass arguments are
listed, but I see that you have considered Joel's comments for the ignoring
paths. Please make a new post in your blog to summarize the latest status.

Best regards,
Kuan-Hsun


On Mon, Jul 12, 2021 at 9:22 AM Sebastian Huber <
sebastian.hu...@embedded-brains.de> wrote:

> Hello Ida,
>
> On 10/07/2021 01:08, Ida Delphine wrote:
> > I added the functionality for my script to ignore certain directories
> > like /bsps/, /testsuites/, '/cpukit/zlib', '/cpukit/mghttpd'.
> > https://github.com/Idadelveloper/rtems/blob/master/hooks/pre-commit
> > 
> > Are there any extra directories I should exclude?
> >
> > Also open to more suggestions and feedback to make my code better :)
>
> what do I have to do to test this pre-commit hook?
>
> --
> embedded brains GmbH
> Herr Sebastian HUBER
> Dornierstr. 4
> 82178 Puchheim
> Germany
> email: sebastian.hu...@embedded-brains.de
> phone: +49-89-18 94 741 - 16
> fax:   +49-89-18 94 741 - 08
>
> Registergericht: Amtsgericht München
> Registernummer: HRB 157899
> Vertretungsberechtigte Geschäftsführer: Peter Rasmussen, Thomas Dörfler
> Unsere Datenschutzerklärung finden Sie hier:
> https://embedded-brains.de/datenschutzerklaerung/
> ___
> devel mailing list
> devel@rtems.org
> http://lists.rtems.org/mailman/listinfo/devel



-- 
Diese Mail wurde mobil geschrieben. Etwaige Rechtschreibfehler sind volle
Absicht und als großzügiges Geschenk zu verstehen.
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: GSoC - Code Formatting and Style Checking for RTEMS score

[Ida Delphine]

Hello,
What I did was copy and paste the script into my local
rtems/.git/hooks/pre-commit file, intentionally made some wrong style
changes in some files and tried making a commit. I have documented how it
works here
https://github.com/Idadelveloper/rtems-docs/commit/a30407e159726ce745df7ab4813c5b3a58b34f93
Will love feedback to also make it better.

On Mon, Jul 12, 2021 at 8:22 AM Sebastian Huber <
sebastian.hu...@embedded-brains.de> wrote:

> Hello Ida,
>
> On 10/07/2021 01:08, Ida Delphine wrote:
> > I added the functionality for my script to ignore certain directories
> > like /bsps/, /testsuites/, '/cpukit/zlib', '/cpukit/mghttpd'.
> > https://github.com/Idadelveloper/rtems/blob/master/hooks/pre-commit
> > 
> > Are there any extra directories I should exclude?
> >
> > Also open to more suggestions and feedback to make my code better :)
>
> what do I have to do to test this pre-commit hook?
>
> --
> embedded brains GmbH
> Herr Sebastian HUBER
> Dornierstr. 4
> 82178 Puchheim
> Germany
> email: sebastian.hu...@embedded-brains.de
> phone: +49-89-18 94 741 - 16
> fax:   +49-89-18 94 741 - 08
>
> Registergericht: Amtsgericht München
> Registernummer: HRB 157899
> Vertretungsberechtigte Geschäftsführer: Peter Rasmussen, Thomas Dörfler
> Unsere Datenschutzerklärung finden Sie hier:
> https://embedded-brains.de/datenschutzerklaerung/
>
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: GSoC - Code Formatting and Style Checking for RTEMS score

[Ida Delphine]

Hello everyone,
>From the discussion on discord it looks like clang-format cannot be
installed on MacOS and FreeBSD. Is there any alternative or way to have it
on these operating systems?

On Wed, 5 May 2021, 10:21 pm Ida Delphine,  wrote:

> Hello everyone,
>
> Regarding this project (https://devel.rtems.org/ticket/3860) I went with
> clang-format as we all agreed. I have tested it on some "score" files and
> it made some changes which I don't think are very much in line with the
> RTEMS coding style. However, it wasn't really clear if we will chage the
> RTEMS coding style or try to make changes to clang-format to fit the style.
> Please will love to know the best option.
>
> Cheers,
> Ida.
>
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: GSoC - Code Formatting and Style Checking for RTEMS score

[Gedare Bloom]

On Thu, Jul 15, 2021 at 5:19 AM Ida Delphine  wrote:
>
> Hello everyone,
> From the discussion on discord it looks like clang-format cannot be installed 
> on MacOS and FreeBSD. Is there any alternative or way to have it on these 
> operating systems?
>
What are the challenges with them? Can clang-format be built from
source on those hosts?

> On Wed, 5 May 2021, 10:21 pm Ida Delphine,  wrote:
>>
>> Hello everyone,
>>
>> Regarding this project (https://devel.rtems.org/ticket/3860) I went with 
>> clang-format as we all agreed. I have tested it on some "score" files and it 
>> made some changes which I don't think are very much in line with the RTEMS 
>> coding style. However, it wasn't really clear if we will chage the RTEMS 
>> coding style or try to make changes to clang-format to fit the style.
>> Please will love to know the best option.
>>
>> Cheers,
>> Ida.
>
> ___
> devel mailing list
> devel@rtems.org
> http://lists.rtems.org/mailman/listinfo/devel
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: GSoC - Code Formatting and Style Checking for RTEMS score

[Ida Delphine]

I will check on this

On Thu, Jul 15, 2021 at 3:39 PM Gedare Bloom  wrote:

> On Thu, Jul 15, 2021 at 5:19 AM Ida Delphine  wrote:
> >
> > Hello everyone,
> > From the discussion on discord it looks like clang-format cannot be
> installed on MacOS and FreeBSD. Is there any alternative or way to have it
> on these operating systems?
> >
> What are the challenges with them? Can clang-format be built from
> source on those hosts?
>
> > On Wed, 5 May 2021, 10:21 pm Ida Delphine,  wrote:
> >>
> >> Hello everyone,
> >>
> >> Regarding this project (https://devel.rtems.org/ticket/3860) I went
> with clang-format as we all agreed. I have tested it on some "score" files
> and it made some changes which I don't think are very much in line with the
> RTEMS coding style. However, it wasn't really clear if we will chage the
> RTEMS coding style or try to make changes to clang-format to fit the style.
> >> Please will love to know the best option.
> >>
> >> Cheers,
> >> Ida.
> >
> > ___
> > devel mailing list
> > devel@rtems.org
> > http://lists.rtems.org/mailman/listinfo/devel
>
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: GSoC - Code Formatting and Style Checking for RTEMS score

[Chris Johns]

Hi,

I will bring the discussion to the devel list and I hope the comments are in
line with the purpose of the project. Please correct what I say if it is not.

The pre-commit script that is in github review is a good base and I believe it
solves that problem for those on Linux. It is a great start and it is nice to 
see.

The work needs to mature and progress and that means a few things. I was
approached by Joel about where this would live in rtems-tools. As the script
stands it is not suitable for rtems-tool because the format is specific to the
score code in rtems.git.

I think a pre-commit script needs to live in the repo it is for in a spot a user
can copy to the hooks directory of their repo. For example `git-hooks`.

A git hooks script for rtems.git needs to run on all the supported hosts or we
may result in patches being left on the floor. If a contributor's host OS is not
supported and the patch is rejected for formatting reasons picked up by the
check the contributor may just walk away.

The script should use `/usr/bin/env python3` and it needs to check for a range
of `clang-format` instances. FreeBSD has a package that installs the format
command as `clang-format10` for LLVM 10 and `clang-format11` for version 11.

A contributor being able to run the script may depend on the host having a
package or packages installed. Given this is for RTEMS development that is fine.
The script needs to handle any set up errors nicely if something is missing. I
prefer we avoid the "experts" approach to error management.

There is possible future work adding a command to rtems-tools. Ida and I
discussed this on discord and we decided a command called `rtems-style` would be
nice. It would be nice if that command checked, ie `--mode=check`, a style as
well as `--mode=reformat` to automatically reformat a source file.

A command for rtems-tools has to support python2 and python3 and it has to
handle errors in suitable manner. Printing uncaught exception is not OK. It
should also be self contained and not depend on any pip python packages.

If an `rtems-style` command is created and installed when rtems-tool is
installed the pre-commit git script could be made to use it and so the style is
held in a single location.

Finally an rtems-style command could be extended to support python
(--lang=python) or other styles for other code formats. This is inline with our
other eco-system interfaces we provide.

I hope this helps.

Chris

On 16/7/21 5:13 am, Ida Delphine wrote:
> I will check on this
> 
> On Thu, Jul 15, 2021 at 3:39 PM Gedare Bloom  > wrote:
> 
> On Thu, Jul 15, 2021 at 5:19 AM Ida Delphine  > wrote:
> >
> > Hello everyone,
> > From the discussion on discord it looks like clang-format cannot be
> installed on MacOS and FreeBSD. Is there any alternative or way to have it
> on these operating systems?
> >
> What are the challenges with them? Can clang-format be built from
> source on those hosts?
> 
> > On Wed, 5 May 2021, 10:21 pm Ida Delphine,  > wrote:
> >>
> >> Hello everyone,
> >>
> >> Regarding this project (https://devel.rtems.org/ticket/3860
> ) I went with clang-format as we all
> agreed. I have tested it on some "score" files and it made some changes
> which I don't think are very much in line with the RTEMS coding style.
> However, it wasn't really clear if we will chage the RTEMS coding style or
> try to make changes to clang-format to fit the style.
> >> Please will love to know the best option.
> >>
> >> Cheers,
> >> Ida.
> >
> > ___
> > devel mailing list
> > devel@rtems.org 
> > http://lists.rtems.org/mailman/listinfo/devel
> 
> 
> 
> ___
> devel mailing list
> devel@rtems.org
> http://lists.rtems.org/mailman/listinfo/devel
> 
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: GSoC - Code Formatting and Style Checking for RTEMS score

[Ida Delphine]

Hi everyone,
I was able to successfully build LLVM from source using "ninja" instead of
"make" after a couple of failed attempts because I kept running out of
resources.

Is there anything else I am supposed to do as far building LLVM is
concerned? Or will every user first have to clone the llvm repo and build
it from source like I did?

On Fri, 16 Jul 2021, 5:28 am Chris Johns,  wrote:

> Hi,
>
> I will bring the discussion to the devel list and I hope the comments are
> in
> line with the purpose of the project. Please correct what I say if it is
> not.
>
> The pre-commit script that is in github review is a good base and I
> believe it
> solves that problem for those on Linux. It is a great start and it is nice
> to see.
>
> The work needs to mature and progress and that means a few things. I was
> approached by Joel about where this would live in rtems-tools. As the
> script
> stands it is not suitable for rtems-tool because the format is specific to
> the
> score code in rtems.git.
>
> I think a pre-commit script needs to live in the repo it is for in a spot
> a user
> can copy to the hooks directory of their repo. For example `git-hooks`.
>
> A git hooks script for rtems.git needs to run on all the supported hosts
> or we
> may result in patches being left on the floor. If a contributor's host OS
> is not
> supported and the patch is rejected for formatting reasons picked up by the
> check the contributor may just walk away.
>
> The script should use `/usr/bin/env python3` and it needs to check for a
> range
> of `clang-format` instances. FreeBSD has a package that installs the format
> command as `clang-format10` for LLVM 10 and `clang-format11` for version
> 11.
>
> A contributor being able to run the script may depend on the host having a
> package or packages installed. Given this is for RTEMS development that is
> fine.
> The script needs to handle any set up errors nicely if something is
> missing. I
> prefer we avoid the "experts" approach to error management.
>
> There is possible future work adding a command to rtems-tools. Ida and I
> discussed this on discord and we decided a command called `rtems-style`
> would be
> nice. It would be nice if that command checked, ie `--mode=check`, a style
> as
> well as `--mode=reformat` to automatically reformat a source file.
>
> A command for rtems-tools has to support python2 and python3 and it has to
> handle errors in suitable manner. Printing uncaught exception is not OK. It
> should also be self contained and not depend on any pip python packages.
>
> If an `rtems-style` command is created and installed when rtems-tool is
> installed the pre-commit git script could be made to use it and so the
> style is
> held in a single location.
>
> Finally an rtems-style command could be extended to support python
> (--lang=python) or other styles for other code formats. This is inline
> with our
> other eco-system interfaces we provide.
>
> I hope this helps.
>
> Chris
>
> On 16/7/21 5:13 am, Ida Delphine wrote:
> > I will check on this
> >
> > On Thu, Jul 15, 2021 at 3:39 PM Gedare Bloom  > > wrote:
> >
> > On Thu, Jul 15, 2021 at 5:19 AM Ida Delphine  > > wrote:
> > >
> > > Hello everyone,
> > > From the discussion on discord it looks like clang-format cannot be
> > installed on MacOS and FreeBSD. Is there any alternative or way to
> have it
> > on these operating systems?
> > >
> > What are the challenges with them? Can clang-format be built from
> > source on those hosts?
> >
> > > On Wed, 5 May 2021, 10:21 pm Ida Delphine,  > > wrote:
> > >>
> > >> Hello everyone,
> > >>
> > >> Regarding this project (https://devel.rtems.org/ticket/3860
> > ) I went with clang-format as
> we all
> > agreed. I have tested it on some "score" files and it made some
> changes
> > which I don't think are very much in line with the RTEMS coding
> style.
> > However, it wasn't really clear if we will chage the RTEMS coding
> style or
> > try to make changes to clang-format to fit the style.
> > >> Please will love to know the best option.
> > >>
> > >> Cheers,
> > >> Ida.
> > >
> > > ___
> > > devel mailing list
> > > devel@rtems.org 
> > > http://lists.rtems.org/mailman/listinfo/devel
> > 
> >
> >
> > ___
> > devel mailing list
> > devel@rtems.org
> > http://lists.rtems.org/mailman/listinfo/devel
> >
>
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: GSoC - Code Formatting and Style Checking for RTEMS score

[Gedare Bloom]

On Tue, Aug 10, 2021 at 3:21 PM Ida Delphine  wrote:
>
> Hi everyone,
> I was able to successfully build LLVM from source using "ninja" instead of 
> "make" after a couple of failed attempts because I kept running out of 
> resources.
>
> Is there anything else I am supposed to do as far building LLVM is concerned? 
> Or will every user first have to clone the llvm repo and build it from source 
> like I did?
>
I think it would be good to update/provide RSB recipe for newer
version(s) of LLVM. If you can do that after the GSoC coding period
ends, that would be great.

> On Fri, 16 Jul 2021, 5:28 am Chris Johns,  wrote:
>>
>> Hi,
>>
>> I will bring the discussion to the devel list and I hope the comments are in
>> line with the purpose of the project. Please correct what I say if it is not.
>>
>> The pre-commit script that is in github review is a good base and I believe 
>> it
>> solves that problem for those on Linux. It is a great start and it is nice 
>> to see.
>>
>> The work needs to mature and progress and that means a few things. I was
>> approached by Joel about where this would live in rtems-tools. As the script
>> stands it is not suitable for rtems-tool because the format is specific to 
>> the
>> score code in rtems.git.
>>
>> I think a pre-commit script needs to live in the repo it is for in a spot a 
>> user
>> can copy to the hooks directory of their repo. For example `git-hooks`.
>>
>> A git hooks script for rtems.git needs to run on all the supported hosts or 
>> we
>> may result in patches being left on the floor. If a contributor's host OS is 
>> not
>> supported and the patch is rejected for formatting reasons picked up by the
>> check the contributor may just walk away.
>>
>> The script should use `/usr/bin/env python3` and it needs to check for a 
>> range
>> of `clang-format` instances. FreeBSD has a package that installs the format
>> command as `clang-format10` for LLVM 10 and `clang-format11` for version 11.
>>
>> A contributor being able to run the script may depend on the host having a
>> package or packages installed. Given this is for RTEMS development that is 
>> fine.
>> The script needs to handle any set up errors nicely if something is missing. 
>> I
>> prefer we avoid the "experts" approach to error management.
>>
>> There is possible future work adding a command to rtems-tools. Ida and I
>> discussed this on discord and we decided a command called `rtems-style` 
>> would be
>> nice. It would be nice if that command checked, ie `--mode=check`, a style as
>> well as `--mode=reformat` to automatically reformat a source file.
>>
>> A command for rtems-tools has to support python2 and python3 and it has to
>> handle errors in suitable manner. Printing uncaught exception is not OK. It
>> should also be self contained and not depend on any pip python packages.
>>
>> If an `rtems-style` command is created and installed when rtems-tool is
>> installed the pre-commit git script could be made to use it and so the style 
>> is
>> held in a single location.
>>
>> Finally an rtems-style command could be extended to support python
>> (--lang=python) or other styles for other code formats. This is inline with 
>> our
>> other eco-system interfaces we provide.
>>
>> I hope this helps.
>>
>> Chris
>>
>> On 16/7/21 5:13 am, Ida Delphine wrote:
>> > I will check on this
>> >
>> > On Thu, Jul 15, 2021 at 3:39 PM Gedare Bloom > > > wrote:
>> >
>> > On Thu, Jul 15, 2021 at 5:19 AM Ida Delphine > > > wrote:
>> > >
>> > > Hello everyone,
>> > > From the discussion on discord it looks like clang-format cannot be
>> > installed on MacOS and FreeBSD. Is there any alternative or way to 
>> > have it
>> > on these operating systems?
>> > >
>> > What are the challenges with them? Can clang-format be built from
>> > source on those hosts?
>> >
>> > > On Wed, 5 May 2021, 10:21 pm Ida Delphine, > > > wrote:
>> > >>
>> > >> Hello everyone,
>> > >>
>> > >> Regarding this project (https://devel.rtems.org/ticket/3860
>> > ) I went with clang-format as we 
>> > all
>> > agreed. I have tested it on some "score" files and it made some changes
>> > which I don't think are very much in line with the RTEMS coding style.
>> > However, it wasn't really clear if we will chage the RTEMS coding 
>> > style or
>> > try to make changes to clang-format to fit the style.
>> > >> Please will love to know the best option.
>> > >>
>> > >> Cheers,
>> > >> Ida.
>> > >
>> > > ___
>> > > devel mailing list
>> > > devel@rtems.org 
>> > > http://lists.rtems.org/mailman/listinfo/devel
>> > 
>> >
>> >
>> > ___
>> > devel mailing list
>> > devel

Re: GSoC - Code Formatting and Style Checking for RTEMS score

[Ida Delphine]

Hello everyone,
I wrote the style checking tool and looking forward to some feedback to
improve it...
https://github.com/Idadelveloper/rtems-tools/blob/master/misc/tools/style.py

On Wed, 11 Aug 2021, 5:07 pm Gedare Bloom,  wrote:

> On Tue, Aug 10, 2021 at 3:21 PM Ida Delphine  wrote:
> >
> > Hi everyone,
> > I was able to successfully build LLVM from source using "ninja" instead
> of "make" after a couple of failed attempts because I kept running out of
> resources.
> >
> > Is there anything else I am supposed to do as far building LLVM is
> concerned? Or will every user first have to clone the llvm repo and build
> it from source like I did?
> >
> I think it would be good to update/provide RSB recipe for newer
> version(s) of LLVM. If you can do that after the GSoC coding period
> ends, that would be great.
>
> > On Fri, 16 Jul 2021, 5:28 am Chris Johns,  wrote:
> >>
> >> Hi,
> >>
> >> I will bring the discussion to the devel list and I hope the comments
> are in
> >> line with the purpose of the project. Please correct what I say if it
> is not.
> >>
> >> The pre-commit script that is in github review is a good base and I
> believe it
> >> solves that problem for those on Linux. It is a great start and it is
> nice to see.
> >>
> >> The work needs to mature and progress and that means a few things. I was
> >> approached by Joel about where this would live in rtems-tools. As the
> script
> >> stands it is not suitable for rtems-tool because the format is specific
> to the
> >> score code in rtems.git.
> >>
> >> I think a pre-commit script needs to live in the repo it is for in a
> spot a user
> >> can copy to the hooks directory of their repo. For example `git-hooks`.
> >>
> >> A git hooks script for rtems.git needs to run on all the supported
> hosts or we
> >> may result in patches being left on the floor. If a contributor's host
> OS is not
> >> supported and the patch is rejected for formatting reasons picked up by
> the
> >> check the contributor may just walk away.
> >>
> >> The script should use `/usr/bin/env python3` and it needs to check for
> a range
> >> of `clang-format` instances. FreeBSD has a package that installs the
> format
> >> command as `clang-format10` for LLVM 10 and `clang-format11` for
> version 11.
> >>
> >> A contributor being able to run the script may depend on the host
> having a
> >> package or packages installed. Given this is for RTEMS development that
> is fine.
> >> The script needs to handle any set up errors nicely if something is
> missing. I
> >> prefer we avoid the "experts" approach to error management.
> >>
> >> There is possible future work adding a command to rtems-tools. Ida and I
> >> discussed this on discord and we decided a command called `rtems-style`
> would be
> >> nice. It would be nice if that command checked, ie `--mode=check`, a
> style as
> >> well as `--mode=reformat` to automatically reformat a source file.
> >>
> >> A command for rtems-tools has to support python2 and python3 and it has
> to
> >> handle errors in suitable manner. Printing uncaught exception is not
> OK. It
> >> should also be self contained and not depend on any pip python packages.
> >>
> >> If an `rtems-style` command is created and installed when rtems-tool is
> >> installed the pre-commit git script could be made to use it and so the
> style is
> >> held in a single location.
> >>
> >> Finally an rtems-style command could be extended to support python
> >> (--lang=python) or other styles for other code formats. This is inline
> with our
> >> other eco-system interfaces we provide.
> >>
> >> I hope this helps.
> >>
> >> Chris
> >>
> >> On 16/7/21 5:13 am, Ida Delphine wrote:
> >> > I will check on this
> >> >
> >> > On Thu, Jul 15, 2021 at 3:39 PM Gedare Bloom  >> > > wrote:
> >> >
> >> > On Thu, Jul 15, 2021 at 5:19 AM Ida Delphine  >> > > wrote:
> >> > >
> >> > > Hello everyone,
> >> > > From the discussion on discord it looks like clang-format
> cannot be
> >> > installed on MacOS and FreeBSD. Is there any alternative or way
> to have it
> >> > on these operating systems?
> >> > >
> >> > What are the challenges with them? Can clang-format be built from
> >> > source on those hosts?
> >> >
> >> > > On Wed, 5 May 2021, 10:21 pm Ida Delphine,  >> > > wrote:
> >> > >>
> >> > >> Hello everyone,
> >> > >>
> >> > >> Regarding this project (https://devel.rtems.org/ticket/3860
> >> > ) I went with clang-format
> as we all
> >> > agreed. I have tested it on some "score" files and it made some
> changes
> >> > which I don't think are very much in line with the RTEMS coding
> style.
> >> > However, it wasn't really clear if we will chage the RTEMS coding
> style or
> >> > try to make changes to clang-format to fit the style.
> >> > >> Please will love to know the best option.
> >> >