Re: #3860 - GSoC enquiries

[Ida Delphine]

Hello everyone,
Before submitting my final GSoC proposal will love it if my draft can be
reviewed one more time so that in case I still got errors I could fix them.
Just want to be sure everything is okay.
https://docs.google.com/document/d/1VADJh3_kIhs578IEmBJ98rjR6p5E1XcksUkq1Ms4jRA/edit?usp=sharing

Thanks,
Ida.

On Mon, Apr 12, 2021 at 6:40 AM Ida Delphine  wrote:

> Hello all,
> I made some changes to my initial proposal draft based on some feedback I
> got. Here's is the modified version. Please help me review and suggest
> improvements.
>
> https://docs.google.com/document/d/1VADJh3_kIhs578IEmBJ98rjR6p5E1XcksUkq1Ms4jRA/edit?usp=sharing
>
> Cheers,
> Ida.
>
> On Fri, Apr 9, 2021 at 1:51 AM Ida Delphine  wrote:
>
>> Hello All,
>>
>> Just a gentle reminder to please help me review this my proposal draft
>> and help me with ways to make it better :)
>>
>> https://docs.google.com/document/d/1VADJh3_kIhs578IEmBJ98rjR6p5E1XcksUkq1Ms4jRA/edit?usp=sharing
>>
>> Cheers,
>> Ida
>>
>> On Thu, 8 Apr 2021, 6:51 am Ida Delphine,  wrote:
>>
>>> Hello everyone,
>>> Here is the link to my GSoC proposal. Will love if you leave comments on
>>> ways I could make it better or any corrections (Especially the *Proposesd
>>> Schedule* section so that I will be sure about my project deliverables
>>> when inputting them).
>>>
>>> https://docs.google.com/document/d/1VADJh3_kIhs578IEmBJ98rjR6p5E1XcksUkq1Ms4jRA/edit?usp=sharing
>>> I will also love to know about any future improvements to this project.
>>>
>>> Cheers,
>>> Ida.
>>>
>>> On Wed, Apr 7, 2021 at 5:27 PM Gedare Bloom  wrote:
>>>
 On Wed, Apr 7, 2021 at 10:11 AM Ida Delphine  wrote:
 >
 > Hello,
 >
 > In case I succeed with this project will I be required to do some
 documentation on how it works?
 >
 Yes, in general we expect students to produce documentation while they
 work on also creating code.

 I think the direction we're heading right now is toward using
 clang-format, perhaps with an update to a common coding style. In this
 case, we solve our problem by policy rather than technical solution,
 and your work should focus on tool integration and automation without
 concern about the coding style itself.

 >
 > On Wed, Apr 7, 2021 at 9:51 AM Sebastian Huber <
 sebastian.hu...@embedded-brains.de> wrote:
 >>
 >> On 07/04/2021 09:03, Chris Johns wrote:
 >>
 >> > Would it be pragmatic to review these cases and change the
 standard?
 >>
 >> I sent a patch to review the format changes done by clang-format
 recently:
 >>
 >> https://lists.rtems.org/pipermail/devel/2021-April/066311.html
 >>
 >> It doesn't look that bad from my point of view. Fixing the alignment
 >> issue would make it even better:
 >>
 >> https://reviews.llvm.org/D27651
 >>
 >> >
 >> > I understand the long history but as you point out we either
 invest in the tools
 >> > to support the format, we change what we have or we manage it
 manually.
 >> I would prefer to change the style and use a widely used formatting
 >> tool. I think we spend to much time on the coding style in reviews.
 This
 >> is quite bad since we are all busy with all sorts of things and our
 time
 >> is better spent on more important tasks. A consistently formatted
 source
 >> code is very important, but enforcing this style manually is a waste
 of
 >> time.
 >>
 >> --
 >> 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

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

Re: #3860 - GSoC enquiries

[Ida Delphine]

Hello all,
I made some changes to my initial proposal draft based on some feedback I
got. Here's is the modified version. Please help me review and suggest
improvements.
https://docs.google.com/document/d/1VADJh3_kIhs578IEmBJ98rjR6p5E1XcksUkq1Ms4jRA/edit?usp=sharing

Cheers,
Ida.

On Fri, Apr 9, 2021 at 1:51 AM Ida Delphine  wrote:

> Hello All,
>
> Just a gentle reminder to please help me review this my proposal draft and
> help me with ways to make it better :)
>
> https://docs.google.com/document/d/1VADJh3_kIhs578IEmBJ98rjR6p5E1XcksUkq1Ms4jRA/edit?usp=sharing
>
> Cheers,
> Ida
>
> On Thu, 8 Apr 2021, 6:51 am Ida Delphine,  wrote:
>
>> Hello everyone,
>> Here is the link to my GSoC proposal. Will love if you leave comments on
>> ways I could make it better or any corrections (Especially the *Proposesd
>> Schedule* section so that I will be sure about my project deliverables
>> when inputting them).
>>
>> https://docs.google.com/document/d/1VADJh3_kIhs578IEmBJ98rjR6p5E1XcksUkq1Ms4jRA/edit?usp=sharing
>> I will also love to know about any future improvements to this project.
>>
>> Cheers,
>> Ida.
>>
>> On Wed, Apr 7, 2021 at 5:27 PM Gedare Bloom  wrote:
>>
>>> On Wed, Apr 7, 2021 at 10:11 AM Ida Delphine  wrote:
>>> >
>>> > Hello,
>>> >
>>> > In case I succeed with this project will I be required to do some
>>> documentation on how it works?
>>> >
>>> Yes, in general we expect students to produce documentation while they
>>> work on also creating code.
>>>
>>> I think the direction we're heading right now is toward using
>>> clang-format, perhaps with an update to a common coding style. In this
>>> case, we solve our problem by policy rather than technical solution,
>>> and your work should focus on tool integration and automation without
>>> concern about the coding style itself.
>>>
>>> >
>>> > On Wed, Apr 7, 2021 at 9:51 AM Sebastian Huber <
>>> sebastian.hu...@embedded-brains.de> wrote:
>>> >>
>>> >> On 07/04/2021 09:03, Chris Johns wrote:
>>> >>
>>> >> > Would it be pragmatic to review these cases and change the standard?
>>> >>
>>> >> I sent a patch to review the format changes done by clang-format
>>> recently:
>>> >>
>>> >> https://lists.rtems.org/pipermail/devel/2021-April/066311.html
>>> >>
>>> >> It doesn't look that bad from my point of view. Fixing the alignment
>>> >> issue would make it even better:
>>> >>
>>> >> https://reviews.llvm.org/D27651
>>> >>
>>> >> >
>>> >> > I understand the long history but as you point out we either invest
>>> in the tools
>>> >> > to support the format, we change what we have or we manage it
>>> manually.
>>> >> I would prefer to change the style and use a widely used formatting
>>> >> tool. I think we spend to much time on the coding style in reviews.
>>> This
>>> >> is quite bad since we are all busy with all sorts of things and our
>>> time
>>> >> is better spent on more important tasks. A consistently formatted
>>> source
>>> >> code is very important, but enforcing this style manually is a waste
>>> of
>>> >> time.
>>> >>
>>> >> --
>>> >> 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
>>>
>>
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: #3860 - GSoC enquiries

[Ida Delphine]

Hello All,

Just a gentle reminder to please help me review this my proposal draft and
help me with ways to make it better :)
https://docs.google.com/document/d/1VADJh3_kIhs578IEmBJ98rjR6p5E1XcksUkq1Ms4jRA/edit?usp=sharing

Cheers,
Ida

On Thu, 8 Apr 2021, 6:51 am Ida Delphine,  wrote:

> Hello everyone,
> Here is the link to my GSoC proposal. Will love if you leave comments on
> ways I could make it better or any corrections (Especially the *Proposesd
> Schedule* section so that I will be sure about my project deliverables
> when inputting them).
>
> https://docs.google.com/document/d/1VADJh3_kIhs578IEmBJ98rjR6p5E1XcksUkq1Ms4jRA/edit?usp=sharing
> I will also love to know about any future improvements to this project.
>
> Cheers,
> Ida.
>
> On Wed, Apr 7, 2021 at 5:27 PM Gedare Bloom  wrote:
>
>> On Wed, Apr 7, 2021 at 10:11 AM Ida Delphine  wrote:
>> >
>> > Hello,
>> >
>> > In case I succeed with this project will I be required to do some
>> documentation on how it works?
>> >
>> Yes, in general we expect students to produce documentation while they
>> work on also creating code.
>>
>> I think the direction we're heading right now is toward using
>> clang-format, perhaps with an update to a common coding style. In this
>> case, we solve our problem by policy rather than technical solution,
>> and your work should focus on tool integration and automation without
>> concern about the coding style itself.
>>
>> >
>> > On Wed, Apr 7, 2021 at 9:51 AM Sebastian Huber <
>> sebastian.hu...@embedded-brains.de> wrote:
>> >>
>> >> On 07/04/2021 09:03, Chris Johns wrote:
>> >>
>> >> > Would it be pragmatic to review these cases and change the standard?
>> >>
>> >> I sent a patch to review the format changes done by clang-format
>> recently:
>> >>
>> >> https://lists.rtems.org/pipermail/devel/2021-April/066311.html
>> >>
>> >> It doesn't look that bad from my point of view. Fixing the alignment
>> >> issue would make it even better:
>> >>
>> >> https://reviews.llvm.org/D27651
>> >>
>> >> >
>> >> > I understand the long history but as you point out we either invest
>> in the tools
>> >> > to support the format, we change what we have or we manage it
>> manually.
>> >> I would prefer to change the style and use a widely used formatting
>> >> tool. I think we spend to much time on the coding style in reviews.
>> This
>> >> is quite bad since we are all busy with all sorts of things and our
>> time
>> >> is better spent on more important tasks. A consistently formatted
>> source
>> >> code is very important, but enforcing this style manually is a waste of
>> >> time.
>> >>
>> >> --
>> >> 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
>>
>
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: #3860 - GSoC enquiries

[Ida Delphine]

I just did.

On Thu, 8 Apr 2021, 7:11 am Gedare Bloom,  wrote:

> Please enable commenting
>
> On Wed, Apr 7, 2021 at 11:51 PM Ida Delphine  wrote:
> >
> > Hello everyone,
> > Here is the link to my GSoC proposal. Will love if you leave comments on
> ways I could make it better or any corrections (Especially the Proposesd
> Schedule section so that I will be sure about my project deliverables when
> inputting them).
> >
> https://docs.google.com/document/d/1VADJh3_kIhs578IEmBJ98rjR6p5E1XcksUkq1Ms4jRA/edit?usp=sharing
> > I will also love to know about any future improvements to this project.
> >
> > Cheers,
> > Ida.
> >
> > On Wed, Apr 7, 2021 at 5:27 PM Gedare Bloom  wrote:
> >>
> >> On Wed, Apr 7, 2021 at 10:11 AM Ida Delphine  wrote:
> >> >
> >> > Hello,
> >> >
> >> > In case I succeed with this project will I be required to do some
> documentation on how it works?
> >> >
> >> Yes, in general we expect students to produce documentation while they
> >> work on also creating code.
> >>
> >> I think the direction we're heading right now is toward using
> >> clang-format, perhaps with an update to a common coding style. In this
> >> case, we solve our problem by policy rather than technical solution,
> >> and your work should focus on tool integration and automation without
> >> concern about the coding style itself.
> >>
> >> >
> >> > On Wed, Apr 7, 2021 at 9:51 AM Sebastian Huber <
> sebastian.hu...@embedded-brains.de> wrote:
> >> >>
> >> >> On 07/04/2021 09:03, Chris Johns wrote:
> >> >>
> >> >> > Would it be pragmatic to review these cases and change the
> standard?
> >> >>
> >> >> I sent a patch to review the format changes done by clang-format
> recently:
> >> >>
> >> >> https://lists.rtems.org/pipermail/devel/2021-April/066311.html
> >> >>
> >> >> It doesn't look that bad from my point of view. Fixing the alignment
> >> >> issue would make it even better:
> >> >>
> >> >> https://reviews.llvm.org/D27651
> >> >>
> >> >> >
> >> >> > I understand the long history but as you point out we either
> invest in the tools
> >> >> > to support the format, we change what we have or we manage it
> manually.
> >> >> I would prefer to change the style and use a widely used formatting
> >> >> tool. I think we spend to much time on the coding style in reviews.
> This
> >> >> is quite bad since we are all busy with all sorts of things and our
> time
> >> >> is better spent on more important tasks. A consistently formatted
> source
> >> >> code is very important, but enforcing this style manually is a waste
> of
> >> >> time.
> >> >>
> >> >> --
> >> >> 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
>
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: #3860 - GSoC enquiries

[Gedare Bloom]

Please enable commenting

On Wed, Apr 7, 2021 at 11:51 PM Ida Delphine  wrote:
>
> Hello everyone,
> Here is the link to my GSoC proposal. Will love if you leave comments on ways 
> I could make it better or any corrections (Especially the Proposesd Schedule 
> section so that I will be sure about my project deliverables when inputting 
> them).
> https://docs.google.com/document/d/1VADJh3_kIhs578IEmBJ98rjR6p5E1XcksUkq1Ms4jRA/edit?usp=sharing
> I will also love to know about any future improvements to this project.
>
> Cheers,
> Ida.
>
> On Wed, Apr 7, 2021 at 5:27 PM Gedare Bloom  wrote:
>>
>> On Wed, Apr 7, 2021 at 10:11 AM Ida Delphine  wrote:
>> >
>> > Hello,
>> >
>> > In case I succeed with this project will I be required to do some 
>> > documentation on how it works?
>> >
>> Yes, in general we expect students to produce documentation while they
>> work on also creating code.
>>
>> I think the direction we're heading right now is toward using
>> clang-format, perhaps with an update to a common coding style. In this
>> case, we solve our problem by policy rather than technical solution,
>> and your work should focus on tool integration and automation without
>> concern about the coding style itself.
>>
>> >
>> > On Wed, Apr 7, 2021 at 9:51 AM Sebastian Huber 
>> >  wrote:
>> >>
>> >> On 07/04/2021 09:03, Chris Johns wrote:
>> >>
>> >> > Would it be pragmatic to review these cases and change the standard?
>> >>
>> >> I sent a patch to review the format changes done by clang-format recently:
>> >>
>> >> https://lists.rtems.org/pipermail/devel/2021-April/066311.html
>> >>
>> >> It doesn't look that bad from my point of view. Fixing the alignment
>> >> issue would make it even better:
>> >>
>> >> https://reviews.llvm.org/D27651
>> >>
>> >> >
>> >> > I understand the long history but as you point out we either invest in 
>> >> > the tools
>> >> > to support the format, we change what we have or we manage it manually.
>> >> I would prefer to change the style and use a widely used formatting
>> >> tool. I think we spend to much time on the coding style in reviews. This
>> >> is quite bad since we are all busy with all sorts of things and our time
>> >> is better spent on more important tasks. A consistently formatted source
>> >> code is very important, but enforcing this style manually is a waste of
>> >> time.
>> >>
>> >> --
>> >> 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
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: #3860 - GSoC enquiries

[Ida Delphine]

Hello everyone,
Here is the link to my GSoC proposal. Will love if you leave comments on
ways I could make it better or any corrections (Especially the *Proposesd
Schedule* section so that I will be sure about my project deliverables when
inputting them).
https://docs.google.com/document/d/1VADJh3_kIhs578IEmBJ98rjR6p5E1XcksUkq1Ms4jRA/edit?usp=sharing
I will also love to know about any future improvements to this project.

Cheers,
Ida.

On Wed, Apr 7, 2021 at 5:27 PM Gedare Bloom  wrote:

> On Wed, Apr 7, 2021 at 10:11 AM Ida Delphine  wrote:
> >
> > Hello,
> >
> > In case I succeed with this project will I be required to do some
> documentation on how it works?
> >
> Yes, in general we expect students to produce documentation while they
> work on also creating code.
>
> I think the direction we're heading right now is toward using
> clang-format, perhaps with an update to a common coding style. In this
> case, we solve our problem by policy rather than technical solution,
> and your work should focus on tool integration and automation without
> concern about the coding style itself.
>
> >
> > On Wed, Apr 7, 2021 at 9:51 AM Sebastian Huber <
> sebastian.hu...@embedded-brains.de> wrote:
> >>
> >> On 07/04/2021 09:03, Chris Johns wrote:
> >>
> >> > Would it be pragmatic to review these cases and change the standard?
> >>
> >> I sent a patch to review the format changes done by clang-format
> recently:
> >>
> >> https://lists.rtems.org/pipermail/devel/2021-April/066311.html
> >>
> >> It doesn't look that bad from my point of view. Fixing the alignment
> >> issue would make it even better:
> >>
> >> https://reviews.llvm.org/D27651
> >>
> >> >
> >> > I understand the long history but as you point out we either invest
> in the tools
> >> > to support the format, we change what we have or we manage it
> manually.
> >> I would prefer to change the style and use a widely used formatting
> >> tool. I think we spend to much time on the coding style in reviews. This
> >> is quite bad since we are all busy with all sorts of things and our time
> >> is better spent on more important tasks. A consistently formatted source
> >> code is very important, but enforcing this style manually is a waste of
> >> time.
> >>
> >> --
> >> 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
>
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: #3860 - GSoC enquiries

[Gedare Bloom]

On Wed, Apr 7, 2021 at 10:11 AM Ida Delphine  wrote:
>
> Hello,
>
> In case I succeed with this project will I be required to do some 
> documentation on how it works?
>
Yes, in general we expect students to produce documentation while they
work on also creating code.

I think the direction we're heading right now is toward using
clang-format, perhaps with an update to a common coding style. In this
case, we solve our problem by policy rather than technical solution,
and your work should focus on tool integration and automation without
concern about the coding style itself.

>
> On Wed, Apr 7, 2021 at 9:51 AM Sebastian Huber 
>  wrote:
>>
>> On 07/04/2021 09:03, Chris Johns wrote:
>>
>> > Would it be pragmatic to review these cases and change the standard?
>>
>> I sent a patch to review the format changes done by clang-format recently:
>>
>> https://lists.rtems.org/pipermail/devel/2021-April/066311.html
>>
>> It doesn't look that bad from my point of view. Fixing the alignment
>> issue would make it even better:
>>
>> https://reviews.llvm.org/D27651
>>
>> >
>> > I understand the long history but as you point out we either invest in the 
>> > tools
>> > to support the format, we change what we have or we manage it manually.
>> I would prefer to change the style and use a widely used formatting
>> tool. I think we spend to much time on the coding style in reviews. This
>> is quite bad since we are all busy with all sorts of things and our time
>> is better spent on more important tasks. A consistently formatted source
>> code is very important, but enforcing this style manually is a waste of
>> time.
>>
>> --
>> 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
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: #3860 - GSoC enquiries

[Ida Delphine]

Hello,

In case I succeed with this project will I be required to do some
documentation on how it works?


On Wed, Apr 7, 2021 at 9:51 AM Sebastian Huber <
sebastian.hu...@embedded-brains.de> wrote:

> On 07/04/2021 09:03, Chris Johns wrote:
>
> > Would it be pragmatic to review these cases and change the standard?
>
> I sent a patch to review the format changes done by clang-format recently:
>
> https://lists.rtems.org/pipermail/devel/2021-April/066311.html
>
> It doesn't look that bad from my point of view. Fixing the alignment
> issue would make it even better:
>
> https://reviews.llvm.org/D27651
>
> >
> > I understand the long history but as you point out we either invest in
> the tools
> > to support the format, we change what we have or we manage it manually.
> I would prefer to change the style and use a widely used formatting
> tool. I think we spend to much time on the coding style in reviews. This
> is quite bad since we are all busy with all sorts of things and our time
> is better spent on more important tasks. A consistently formatted source
> code is very important, but enforcing this style manually is a waste of
> time.
>
> --
> 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
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: #3860 - GSoC enquiries

[Sebastian Huber]

On 07/04/2021 09:03, Chris Johns wrote:


Would it be pragmatic to review these cases and change the standard?


I sent a patch to review the format changes done by clang-format recently:

https://lists.rtems.org/pipermail/devel/2021-April/066311.html

It doesn't look that bad from my point of view. Fixing the alignment 
issue would make it even better:


https://reviews.llvm.org/D27651



I understand the long history but as you point out we either invest in the tools
to support the format, we change what we have or we manage it manually.
I would prefer to change the style and use a widely used formatting 
tool. I think we spend to much time on the coding style in reviews. This 
is quite bad since we are all busy with all sorts of things and our time 
is better spent on more important tasks. A consistently formatted source 
code is very important, but enforcing this style manually is a waste of 
time.


--
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: #3860 - GSoC enquiries

[Chris Johns]

On 7/4/21 3:01 pm, Sebastian Huber wrote:
> On 06/04/2021 18:12, Gedare Bloom wrote:
> 
>> On Mon, Apr 5, 2021 at 10:37 PM Sebastian Huber
>>   wrote:
>>> On 04/04/2021 22:18, Joel Sherrill wrote:
>>>
 On Sun, Apr 4, 2021 at 2:25 PM Ida Delphine >>> > wrote:

  Hello,

  Please who are the possible mentors for this project?


 IMO this is a project which has a larger potential potential set of
 mentors than
 one focused on say a single board.


  On Sun, 4 Apr 2021, 3:32 am Ida Delphine, >>>  > wrote:

  Regarding adding a script similar to linux/checkpatch.pl
    the criteria whether patches should
  need changes before being applied will be based on the output
  from running uncrustify right?


 Yes. Assuming we find a combination of uncrustify settings combined
 with changes to the RTEMS style and changes to uncrustify that put us
 in a place where we trust that the output wth the right settings
 matches our style.

 That is your goal. Find changes to the settlngs, uncrustify, and RTEMS
 code style where automated checking is possible. When you find a place
 where the coding style requires something uncrustify cannot currently
 do, the question is uncrustify changed or our coding style?

 Sebastian may have a list of some of those from his effort to create
 that configuration. But addressing the list of where the tooling and
 style guide do not align is a key part of your project.
>>> I am not sure if tinkering code formatting tools to somehow produce the
>>> RTEMS style is a suitable GSoC project. What has this to do with coding?
>>> Also this task lingers around for years. Would it be a feasible task for
>>> a student?
>>>
>> Setting the configuration is not a good task, but since we apparently
>> can't find an out-of-the-box configuration, then there must be some
>> coding that is required to make those style formatters able to support
>> our style. (If not, then we should change our style later.)
>>
> Fixing in the pointer alignment in clang-format would help a bit to get
> something closer to the current RTEMS style. We already identified this issue 
> in
> 2018:
> 
> https://lists.rtems.org/pipermail/devel/2018-December/024145.html
> 
> The corresponding patch set is pending since 2016:
> 
> https://reviews.llvm.org/D27651
> 
> Adding support for new options to clang-format has high barriers:
> 
> https://lists.rtems.org/pipermail/devel/2018-December/024145.html
> 
> It is probably easier to add new options to uncrustify. They already have more
> than 700.
> 
> The difficult parts in the RTEMS style are the alignment of variables and
> parameters, the long functions
> 
> return_type loog(
> 
>   lng  long,
> 
>   a b
> 
> );
> 
> and the long control statements
> 
> if (
> 
>   ...
> 
> ) {
> 
>   ... block ..
> 
> }
> 
> Solving this with options is difficult. In some situations you need something
> like this: if condition, then use rule of option A, else use rule of option B.
> This rule selection may be done implicitly by the tool in a way you like it 
> or not.
> 

Would it be pragmatic to review these cases and change the standard?

I understand the long history but as you point out we either invest in the tools
to support the format, we change what we have or we manage it manually.

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

Re: #3860 - GSoC enquiries

[Sebastian Huber]

On 06/04/2021 18:12, Gedare Bloom wrote:


On Mon, Apr 5, 2021 at 10:37 PM Sebastian Huber
  wrote:

On 04/04/2021 22:18, Joel Sherrill wrote:


On Sun, Apr 4, 2021 at 2:25 PM Ida Delphine mailto:idad...@gmail.com>> wrote:

 Hello,

 Please who are the possible mentors for this project?


IMO this is a project which has a larger potential potential set of
mentors than
one focused on say a single board.


 On Sun, 4 Apr 2021, 3:32 am Ida Delphine, mailto:idad...@gmail.com>> wrote:

 Regarding adding a script similar to linux/checkpatch.pl
   the criteria whether patches should
 need changes before being applied will be based on the output
 from running uncrustify right?


Yes. Assuming we find a combination of uncrustify settings combined
with changes to the RTEMS style and changes to uncrustify that put us
in a place where we trust that the output wth the right settings
matches our style.

That is your goal. Find changes to the settlngs, uncrustify, and RTEMS
code style where automated checking is possible. When you find a place
where the coding style requires something uncrustify cannot currently
do, the question is uncrustify changed or our coding style?

Sebastian may have a list of some of those from his effort to create
that configuration. But addressing the list of where the tooling and
style guide do not align is a key part of your project.

I am not sure if tinkering code formatting tools to somehow produce the
RTEMS style is a suitable GSoC project. What has this to do with coding?
Also this task lingers around for years. Would it be a feasible task for
a student?


Setting the configuration is not a good task, but since we apparently
can't find an out-of-the-box configuration, then there must be some
coding that is required to make those style formatters able to support
our style. (If not, then we should change our style later.)

Fixing in the pointer alignment in clang-format would help a bit to get 
something closer to the current RTEMS style. We already identified this 
issue in 2018:


https://lists.rtems.org/pipermail/devel/2018-December/024145.html

The corresponding patch set is pending since 2016:

https://reviews.llvm.org/D27651

Adding support for new options to clang-format has high barriers:

https://lists.rtems.org/pipermail/devel/2018-December/024145.html

It is probably easier to add new options to uncrustify. They already 
have more than 700.


The difficult parts in the RTEMS style are the alignment of variables 
and parameters, the long functions


return_type loog(

  lng  long,

  a b

);

and the long control statements

if (

  ...

) {

  ... block ..

}

Solving this with options is difficult. In some situations you need 
something like this: if condition, then use rule of option A, else use 
rule of option B. This rule selection may be done implicitly by the tool 
in a way you like it or not.


--
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: #3860 - GSoC enquiries

[Gedare Bloom]

On Tue, Apr 6, 2021 at 2:20 PM Ida Delphine  wrote:
>
> Does this mean I won't have to work with uncrustify anymore?
>
It seems like there is encouragement to consider working with clang. I
think it is a good idea to work with clang anyway. There are other
possible projects that you might be able to consider building from
that skill set.

I think that there is a tricky problem in clang how to handle the
alignment of * when there are multiple * in the same declaration. You
might dig into that problem in your proposal, and identify a solution?
 The stack overflow link was posted before, if you an find it.

> On Tue, 6 Apr 2021, 5:12 pm Gedare Bloom,  wrote:
>>
>> On Mon, Apr 5, 2021 at 10:37 PM Sebastian Huber
>>  wrote:
>> >
>> > On 04/04/2021 22:18, Joel Sherrill wrote:
>> >
>> > >
>> > >
>> > > On Sun, Apr 4, 2021 at 2:25 PM Ida Delphine > > > > wrote:
>> > >
>> > > Hello,
>> > >
>> > > Please who are the possible mentors for this project?
>> > >
>> > >
>> > > IMO this is a project which has a larger potential potential set of
>> > > mentors than
>> > > one focused on say a single board.
>> > >
>> > >
>> > > On Sun, 4 Apr 2021, 3:32 am Ida Delphine, > > > > wrote:
>> > >
>> > > Regarding adding a script similar to linux/checkpatch.pl
>> > >  the criteria whether patches should
>> > > need changes before being applied will be based on the output
>> > > from running uncrustify right?
>> > >
>> > >
>> > > Yes. Assuming we find a combination of uncrustify settings combined
>> > > with changes to the RTEMS style and changes to uncrustify that put us
>> > > in a place where we trust that the output wth the right settings
>> > > matches our style.
>> > >
>> > > That is your goal. Find changes to the settlngs, uncrustify, and RTEMS
>> > > code style where automated checking is possible. When you find a place
>> > > where the coding style requires something uncrustify cannot currently
>> > > do, the question is uncrustify changed or our coding style?
>> > >
>> > > Sebastian may have a list of some of those from his effort to create
>> > > that configuration. But addressing the list of where the tooling and
>> > > style guide do not align is a key part of your project.
>> > I am not sure if tinkering code formatting tools to somehow produce the
>> > RTEMS style is a suitable GSoC project. What has this to do with coding?
>> > Also this task lingers around for years. Would it be a feasible task for
>> > a student?
>> >
>> Setting the configuration is not a good task, but since we apparently
>> can't find an out-of-the-box configuration, then there must be some
>> coding that is required to make those style formatters able to support
>> our style. (If not, then we should change our style later.)
>>
>> > --
>> > 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
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: #3860 - GSoC enquiries

[Ida Delphine]

Does this mean I won't have to work with uncrustify anymore?

On Tue, 6 Apr 2021, 5:12 pm Gedare Bloom,  wrote:

> On Mon, Apr 5, 2021 at 10:37 PM Sebastian Huber
>  wrote:
> >
> > On 04/04/2021 22:18, Joel Sherrill wrote:
> >
> > >
> > >
> > > On Sun, Apr 4, 2021 at 2:25 PM Ida Delphine  > > > wrote:
> > >
> > > Hello,
> > >
> > > Please who are the possible mentors for this project?
> > >
> > >
> > > IMO this is a project which has a larger potential potential set of
> > > mentors than
> > > one focused on say a single board.
> > >
> > >
> > > On Sun, 4 Apr 2021, 3:32 am Ida Delphine,  > > > wrote:
> > >
> > > Regarding adding a script similar to linux/checkpatch.pl
> > >  the criteria whether patches should
> > > need changes before being applied will be based on the output
> > > from running uncrustify right?
> > >
> > >
> > > Yes. Assuming we find a combination of uncrustify settings combined
> > > with changes to the RTEMS style and changes to uncrustify that put us
> > > in a place where we trust that the output wth the right settings
> > > matches our style.
> > >
> > > That is your goal. Find changes to the settlngs, uncrustify, and RTEMS
> > > code style where automated checking is possible. When you find a place
> > > where the coding style requires something uncrustify cannot currently
> > > do, the question is uncrustify changed or our coding style?
> > >
> > > Sebastian may have a list of some of those from his effort to create
> > > that configuration. But addressing the list of where the tooling and
> > > style guide do not align is a key part of your project.
> > I am not sure if tinkering code formatting tools to somehow produce the
> > RTEMS style is a suitable GSoC project. What has this to do with coding?
> > Also this task lingers around for years. Would it be a feasible task for
> > a student?
> >
> Setting the configuration is not a good task, but since we apparently
> can't find an out-of-the-box configuration, then there must be some
> coding that is required to make those style formatters able to support
> our style. (If not, then we should change our style later.)
>
> > --
> > 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
>
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: #3860 - GSoC enquiries

[Gedare Bloom]

On Mon, Apr 5, 2021 at 10:37 PM Sebastian Huber
 wrote:
>
> On 04/04/2021 22:18, Joel Sherrill wrote:
>
> >
> >
> > On Sun, Apr 4, 2021 at 2:25 PM Ida Delphine  > > wrote:
> >
> > Hello,
> >
> > Please who are the possible mentors for this project?
> >
> >
> > IMO this is a project which has a larger potential potential set of
> > mentors than
> > one focused on say a single board.
> >
> >
> > On Sun, 4 Apr 2021, 3:32 am Ida Delphine,  > > wrote:
> >
> > Regarding adding a script similar to linux/checkpatch.pl
> >  the criteria whether patches should
> > need changes before being applied will be based on the output
> > from running uncrustify right?
> >
> >
> > Yes. Assuming we find a combination of uncrustify settings combined
> > with changes to the RTEMS style and changes to uncrustify that put us
> > in a place where we trust that the output wth the right settings
> > matches our style.
> >
> > That is your goal. Find changes to the settlngs, uncrustify, and RTEMS
> > code style where automated checking is possible. When you find a place
> > where the coding style requires something uncrustify cannot currently
> > do, the question is uncrustify changed or our coding style?
> >
> > Sebastian may have a list of some of those from his effort to create
> > that configuration. But addressing the list of where the tooling and
> > style guide do not align is a key part of your project.
> I am not sure if tinkering code formatting tools to somehow produce the
> RTEMS style is a suitable GSoC project. What has this to do with coding?
> Also this task lingers around for years. Would it be a feasible task for
> a student?
>
Setting the configuration is not a good task, but since we apparently
can't find an out-of-the-box configuration, then there must be some
coding that is required to make those style formatters able to support
our style. (If not, then we should change our style later.)

> --
> 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
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: #3860 - GSoC enquiries

[Sebastian Huber]

On 04/04/2021 22:18, Joel Sherrill wrote:




On Sun, Apr 4, 2021 at 2:25 PM Ida Delphine > wrote:


Hello,

Please who are the possible mentors for this project?


IMO this is a project which has a larger potential potential set of 
mentors than

one focused on say a single board.


On Sun, 4 Apr 2021, 3:32 am Ida Delphine, mailto:idad...@gmail.com>> wrote:

Regarding adding a script similar to linux/checkpatch.pl
 the criteria whether patches should
need changes before being applied will be based on the output
from running uncrustify right?


Yes. Assuming we find a combination of uncrustify settings combined 
with changes to the RTEMS style and changes to uncrustify that put us 
in a place where we trust that the output wth the right settings 
matches our style.


That is your goal. Find changes to the settlngs, uncrustify, and RTEMS 
code style where automated checking is possible. When you find a place 
where the coding style requires something uncrustify cannot currently 
do, the question is uncrustify changed or our coding style?


Sebastian may have a list of some of those from his effort to create 
that configuration. But addressing the list of where the tooling and 
style guide do not align is a key part of your project.
I am not sure if tinkering code formatting tools to somehow produce the 
RTEMS style is a suitable GSoC project. What has this to do with coding? 
Also this task lingers around for years. Would it be a feasible task for 
a student?


--
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: #3860 - GSoC enquiries

[Joel Sherrill]

On Sun, Apr 4, 2021 at 2:25 PM Ida Delphine  wrote:

> Hello,
>
> Please who are the possible mentors for this project?
>

IMO this is a project which has a larger potential potential set of mentors
than
one focused on say a single board.

>
> On Sun, 4 Apr 2021, 3:32 am Ida Delphine,  wrote:
>
>> Regarding adding a script similar to linux/checkpatch.pl the criteria
>> whether patches should need changes before being applied will be based on
>> the output from running uncrustify right?
>>
>
Yes. Assuming we find a combination of uncrustify settings combined with
changes to the RTEMS style and changes to uncrustify that put us in a place
where we trust that the output wth the right settings matches our style.

That is your goal. Find changes to the settlngs, uncrustify, and RTEMS code
style where automated checking is possible. When you find a place where the
coding style requires something uncrustify cannot currently do, the
question is uncrustify changed or our coding style?

Sebastian may have a list of some of those from his effort to create that
configuration. But addressing the list of where the tooling and style guide
do not align is a key part of your project.

--joel


>> On Sat, Apr 3, 2021 at 2:32 AM Gedare Bloom  wrote:
>>
>>> On Fri, Apr 2, 2021 at 6:09 PM Joel Sherrill  wrote:
>>> >
>>> >
>>> >
>>> > On Fri, Apr 2, 2021, 6:59 PM Gedare Bloom  wrote:
>>> >>
>>> >> On Fri, Apr 2, 2021 at 4:48 PM Ida Delphine 
>>> wrote:
>>> >> >
>>> >> > Hello,
>>> >> > Please can you help explain what you mean by Adding a "check-style"
>>> target to the RTEMS build system?
>>> >> > And how I could possibly go about this?
>>> >> >
>>> >> I don't know if this makes sense exactly to me.  When compiling RTEMS
>>> >> it could be nice to have an option to check the style rules for
>>> >> compliance. This would be something to integrate in the
>>> >> rtems.git/wscript file most likely, as part of the waf build system.
>>> >> However, since checking style does not generate a target file, I don't
>>> >> know that this really is suitable as a way to verify style rules. It
>>> >> may be suitable to add a standalone script in rtems-tools.git that can
>>> >> be run over the rtems.git that creates a report about style problems.
>>> >> Maybe, a way to configure it to ignore some files or to add exceptions
>>> >> to the style rules for certain cases then could be possible.
>>> >
>>> >
>>> > If you have a configuration that produces the code formatted as
>>> expected in certain directories, then if a change is made as part of normal
>>> development, running uncrustify will result in changes to the file needed.
>>> In a way the goal is to have a directory full of files that an RTEMS
>>> uncrustify configuration does not change.
>>> >
>>> > If you have a script that can do that manually then we can easily add
>>> an automated check somewhere in the process to ensure that directories that
>>> adhere to the style rules continue to adhere to them.
>>> >
>>> > One thing to keep in mind is that there there are places where
>>> uncrustify does not have the ability to format code the way RTEMS has
>>> historically done it. we want the rules to be as close as possible to the
>>> existing practice but we are willing to adjust practice if it allows the
>>> tool to produce formatted output we can trust.
>>> >
>>> Also on the table could be modifications to uncrustify.
>>>
>>> > On each point where this type of issue occurs, we'll have to have a
>>> discussion about our Style versus what tool supports. It's likely indicates
>>> we're doing something that's not common in the open source world.
>>> >
>>> > Once the delta between the output of uncrustify and the committed
>>> source is zero, running uncrustify should produce no changes. Anything
>>> uncrustify wants to change at that point would be a style violation and
>>> flagged. In a perfect world it would prevent you from committing.
>>> >
>>> >>
>>> >>
>>> >> I think focus on 1 and 3 is better as a way to start, and perhaps
>>> >> something like the above can be the phase 2 effort.
>>> >>
>>> >> Gedare
>>> >>
>>> >> > Cheers,
>>> >> > Ida
>>> >> >
>>> >> > On Mon, Mar 29, 2021 at 9:45 PM Gedare Bloom 
>>> wrote:
>>> >> >>
>>> >> >> On Mon, Mar 29, 2021 at 1:28 PM Ida Delphine 
>>> wrote:
>>> >> >> >
>>> >> >> > Yes I have. But wondering how to run it with the given
>>> configuration I saw in this thread(
>>> https://lists.rtems.org/pipermail/devel/2020-October/062770.html).
>>> >> >> >
>>> >> >>
>>> >> >> If you download/copy the configuration into a cfg file, then you
>>> can
>>> >> >> use the examples from
>>> >> >> https://github.com/uncrustify/uncrustify#running-the-program and
>>> >> >> attempt to run it on some files within rtems.git/cpukit/score/src
>>> >> >> would be my suggestion.
>>> >> >>
>>> >> >> > On Mon, Mar 29, 2021 at 3:37 PM Gedare Bloom 
>>> wrote:
>>> >> >> >>
>>> >> >> >> Hi Ida,
>>> >> >> >>
>>> >> >> >> On Mon, Mar 29, 2021 at 7:36 AM Ida Delphine 
>>> wrote:
>>> 

Re: #3860 - GSoC enquiries

[Ida Delphine]

Hello,

Please who are the possible mentors for this project?

On Sun, 4 Apr 2021, 3:32 am Ida Delphine,  wrote:

> Regarding adding a script similar to linux/checkpatch.pl the criteria
> whether patches should need changes before being applied will be based on
> the output from running uncrustify right?
>
> On Sat, Apr 3, 2021 at 2:32 AM Gedare Bloom  wrote:
>
>> On Fri, Apr 2, 2021 at 6:09 PM Joel Sherrill  wrote:
>> >
>> >
>> >
>> > On Fri, Apr 2, 2021, 6:59 PM Gedare Bloom  wrote:
>> >>
>> >> On Fri, Apr 2, 2021 at 4:48 PM Ida Delphine  wrote:
>> >> >
>> >> > Hello,
>> >> > Please can you help explain what you mean by Adding a "check-style"
>> target to the RTEMS build system?
>> >> > And how I could possibly go about this?
>> >> >
>> >> I don't know if this makes sense exactly to me.  When compiling RTEMS
>> >> it could be nice to have an option to check the style rules for
>> >> compliance. This would be something to integrate in the
>> >> rtems.git/wscript file most likely, as part of the waf build system.
>> >> However, since checking style does not generate a target file, I don't
>> >> know that this really is suitable as a way to verify style rules. It
>> >> may be suitable to add a standalone script in rtems-tools.git that can
>> >> be run over the rtems.git that creates a report about style problems.
>> >> Maybe, a way to configure it to ignore some files or to add exceptions
>> >> to the style rules for certain cases then could be possible.
>> >
>> >
>> > If you have a configuration that produces the code formatted as
>> expected in certain directories, then if a change is made as part of normal
>> development, running uncrustify will result in changes to the file needed.
>> In a way the goal is to have a directory full of files that an RTEMS
>> uncrustify configuration does not change.
>> >
>> > If you have a script that can do that manually then we can easily add
>> an automated check somewhere in the process to ensure that directories that
>> adhere to the style rules continue to adhere to them.
>> >
>> > One thing to keep in mind is that there there are places where
>> uncrustify does not have the ability to format code the way RTEMS has
>> historically done it. we want the rules to be as close as possible to the
>> existing practice but we are willing to adjust practice if it allows the
>> tool to produce formatted output we can trust.
>> >
>> Also on the table could be modifications to uncrustify.
>>
>> > On each point where this type of issue occurs, we'll have to have a
>> discussion about our Style versus what tool supports. It's likely indicates
>> we're doing something that's not common in the open source world.
>> >
>> > Once the delta between the output of uncrustify and the committed
>> source is zero, running uncrustify should produce no changes. Anything
>> uncrustify wants to change at that point would be a style violation and
>> flagged. In a perfect world it would prevent you from committing.
>> >
>> >>
>> >>
>> >> I think focus on 1 and 3 is better as a way to start, and perhaps
>> >> something like the above can be the phase 2 effort.
>> >>
>> >> Gedare
>> >>
>> >> > Cheers,
>> >> > Ida
>> >> >
>> >> > On Mon, Mar 29, 2021 at 9:45 PM Gedare Bloom 
>> wrote:
>> >> >>
>> >> >> On Mon, Mar 29, 2021 at 1:28 PM Ida Delphine 
>> wrote:
>> >> >> >
>> >> >> > Yes I have. But wondering how to run it with the given
>> configuration I saw in this thread(
>> https://lists.rtems.org/pipermail/devel/2020-October/062770.html).
>> >> >> >
>> >> >>
>> >> >> If you download/copy the configuration into a cfg file, then you can
>> >> >> use the examples from
>> >> >> https://github.com/uncrustify/uncrustify#running-the-program and
>> >> >> attempt to run it on some files within rtems.git/cpukit/score/src
>> >> >> would be my suggestion.
>> >> >>
>> >> >> > On Mon, Mar 29, 2021 at 3:37 PM Gedare Bloom 
>> wrote:
>> >> >> >>
>> >> >> >> Hi Ida,
>> >> >> >>
>> >> >> >> On Mon, Mar 29, 2021 at 7:36 AM Ida Delphine 
>> wrote:
>> >> >> >> >
>> >> >> >> > Hello,
>> >> >> >> > Please do you mind telling me how to run uncrustify with the
>> given configuration with any sample file?
>> >> >> >>
>> >> >> >> What have you tried? Any directions followed/attempted or notes
>> that
>> >> >> >> you have taken would be helpful.
>> >> >> >>
>> >> >> >> I guess all the info that you should need is in Uncrustify's
>> readme
>> >> >> >> file. https://github.com/uncrustify/uncrustify
>> >> >> >>
>> >> >> >> Did you successfully compile uncrustify tool?
>> >> >> >>
>> >> >> >> > I'm a bit stuck.
>> >> >> >> >
>> >> >> >> > Thanks,
>> >> >> >> > Ida.
>> >> >> >> >
>> >> >> >> > On Wed, Mar 17, 2021 at 10:34 PM Gedare Bloom <
>> ged...@rtems.org> wrote:
>> >> >> >> >>
>> >> >> >> >> On Wed, Mar 17, 2021 at 2:28 PM Ida Delphine <
>> idad...@gmail.com> wrote:
>> >> >> >> >> >
>> >> >> >> >> > Hello,
>> >> >> >> >> > So I have gone through this configuration file and I think
>> I'm getting it. However I'm a bit lost in 

Re: #3860 - GSoC enquiries

[Ida Delphine]

Regarding adding a script similar to linux/checkpatch.pl the criteria
whether patches should need changes before being applied will be based on
the output from running uncrustify right?

On Sat, Apr 3, 2021 at 2:32 AM Gedare Bloom  wrote:

> On Fri, Apr 2, 2021 at 6:09 PM Joel Sherrill  wrote:
> >
> >
> >
> > On Fri, Apr 2, 2021, 6:59 PM Gedare Bloom  wrote:
> >>
> >> On Fri, Apr 2, 2021 at 4:48 PM Ida Delphine  wrote:
> >> >
> >> > Hello,
> >> > Please can you help explain what you mean by Adding a "check-style"
> target to the RTEMS build system?
> >> > And how I could possibly go about this?
> >> >
> >> I don't know if this makes sense exactly to me.  When compiling RTEMS
> >> it could be nice to have an option to check the style rules for
> >> compliance. This would be something to integrate in the
> >> rtems.git/wscript file most likely, as part of the waf build system.
> >> However, since checking style does not generate a target file, I don't
> >> know that this really is suitable as a way to verify style rules. It
> >> may be suitable to add a standalone script in rtems-tools.git that can
> >> be run over the rtems.git that creates a report about style problems.
> >> Maybe, a way to configure it to ignore some files or to add exceptions
> >> to the style rules for certain cases then could be possible.
> >
> >
> > If you have a configuration that produces the code formatted as expected
> in certain directories, then if a change is made as part of normal
> development, running uncrustify will result in changes to the file needed.
> In a way the goal is to have a directory full of files that an RTEMS
> uncrustify configuration does not change.
> >
> > If you have a script that can do that manually then we can easily add an
> automated check somewhere in the process to ensure that directories that
> adhere to the style rules continue to adhere to them.
> >
> > One thing to keep in mind is that there there are places where
> uncrustify does not have the ability to format code the way RTEMS has
> historically done it. we want the rules to be as close as possible to the
> existing practice but we are willing to adjust practice if it allows the
> tool to produce formatted output we can trust.
> >
> Also on the table could be modifications to uncrustify.
>
> > On each point where this type of issue occurs, we'll have to have a
> discussion about our Style versus what tool supports. It's likely indicates
> we're doing something that's not common in the open source world.
> >
> > Once the delta between the output of uncrustify and the committed source
> is zero, running uncrustify should produce no changes. Anything uncrustify
> wants to change at that point would be a style violation and flagged. In a
> perfect world it would prevent you from committing.
> >
> >>
> >>
> >> I think focus on 1 and 3 is better as a way to start, and perhaps
> >> something like the above can be the phase 2 effort.
> >>
> >> Gedare
> >>
> >> > Cheers,
> >> > Ida
> >> >
> >> > On Mon, Mar 29, 2021 at 9:45 PM Gedare Bloom 
> wrote:
> >> >>
> >> >> On Mon, Mar 29, 2021 at 1:28 PM Ida Delphine 
> wrote:
> >> >> >
> >> >> > Yes I have. But wondering how to run it with the given
> configuration I saw in this thread(
> https://lists.rtems.org/pipermail/devel/2020-October/062770.html).
> >> >> >
> >> >>
> >> >> If you download/copy the configuration into a cfg file, then you can
> >> >> use the examples from
> >> >> https://github.com/uncrustify/uncrustify#running-the-program and
> >> >> attempt to run it on some files within rtems.git/cpukit/score/src
> >> >> would be my suggestion.
> >> >>
> >> >> > On Mon, Mar 29, 2021 at 3:37 PM Gedare Bloom 
> wrote:
> >> >> >>
> >> >> >> Hi Ida,
> >> >> >>
> >> >> >> On Mon, Mar 29, 2021 at 7:36 AM Ida Delphine 
> wrote:
> >> >> >> >
> >> >> >> > Hello,
> >> >> >> > Please do you mind telling me how to run uncrustify with the
> given configuration with any sample file?
> >> >> >>
> >> >> >> What have you tried? Any directions followed/attempted or notes
> that
> >> >> >> you have taken would be helpful.
> >> >> >>
> >> >> >> I guess all the info that you should need is in Uncrustify's
> readme
> >> >> >> file. https://github.com/uncrustify/uncrustify
> >> >> >>
> >> >> >> Did you successfully compile uncrustify tool?
> >> >> >>
> >> >> >> > I'm a bit stuck.
> >> >> >> >
> >> >> >> > Thanks,
> >> >> >> > Ida.
> >> >> >> >
> >> >> >> > On Wed, Mar 17, 2021 at 10:34 PM Gedare Bloom 
> wrote:
> >> >> >> >>
> >> >> >> >> On Wed, Mar 17, 2021 at 2:28 PM Ida Delphine <
> idad...@gmail.com> wrote:
> >> >> >> >> >
> >> >> >> >> > Hello,
> >> >> >> >> > So I have gone through this configuration file and I think
> I'm getting it. However I'm a bit lost in the reading the messages in the
> thread. Do you mind explaining? Or we can start talking about a way forward.
> >> >> >> >> > Also can you help me with some steps on how to test this by
> myself if possible?
> >> >> >> >> >
> >> >> >> >>
> >> >> >> >> It 

Re: #3860 - GSoC enquiries

[Gedare Bloom]

On Fri, Apr 2, 2021 at 6:09 PM Joel Sherrill  wrote:
>
>
>
> On Fri, Apr 2, 2021, 6:59 PM Gedare Bloom  wrote:
>>
>> On Fri, Apr 2, 2021 at 4:48 PM Ida Delphine  wrote:
>> >
>> > Hello,
>> > Please can you help explain what you mean by Adding a "check-style" target 
>> > to the RTEMS build system?
>> > And how I could possibly go about this?
>> >
>> I don't know if this makes sense exactly to me.  When compiling RTEMS
>> it could be nice to have an option to check the style rules for
>> compliance. This would be something to integrate in the
>> rtems.git/wscript file most likely, as part of the waf build system.
>> However, since checking style does not generate a target file, I don't
>> know that this really is suitable as a way to verify style rules. It
>> may be suitable to add a standalone script in rtems-tools.git that can
>> be run over the rtems.git that creates a report about style problems.
>> Maybe, a way to configure it to ignore some files or to add exceptions
>> to the style rules for certain cases then could be possible.
>
>
> If you have a configuration that produces the code formatted as expected in 
> certain directories, then if a change is made as part of normal development, 
> running uncrustify will result in changes to the file needed. In a way the 
> goal is to have a directory full of files that an RTEMS uncrustify 
> configuration does not change.
>
> If you have a script that can do that manually then we can easily add an 
> automated check somewhere in the process to ensure that directories that 
> adhere to the style rules continue to adhere to them.
>
> One thing to keep in mind is that there there are places where uncrustify 
> does not have the ability to format code the way RTEMS has historically done 
> it. we want the rules to be as close as possible to the existing practice but 
> we are willing to adjust practice if it allows the tool to produce formatted 
> output we can trust.
>
Also on the table could be modifications to uncrustify.

> On each point where this type of issue occurs, we'll have to have a 
> discussion about our Style versus what tool supports. It's likely indicates 
> we're doing something that's not common in the open source world.
>
> Once the delta between the output of uncrustify and the committed source is 
> zero, running uncrustify should produce no changes. Anything uncrustify wants 
> to change at that point would be a style violation and flagged. In a perfect 
> world it would prevent you from committing.
>
>>
>>
>> I think focus on 1 and 3 is better as a way to start, and perhaps
>> something like the above can be the phase 2 effort.
>>
>> Gedare
>>
>> > Cheers,
>> > Ida
>> >
>> > On Mon, Mar 29, 2021 at 9:45 PM Gedare Bloom  wrote:
>> >>
>> >> On Mon, Mar 29, 2021 at 1:28 PM Ida Delphine  wrote:
>> >> >
>> >> > Yes I have. But wondering how to run it with the given configuration I 
>> >> > saw in this 
>> >> > thread(https://lists.rtems.org/pipermail/devel/2020-October/062770.html).
>> >> >
>> >>
>> >> If you download/copy the configuration into a cfg file, then you can
>> >> use the examples from
>> >> https://github.com/uncrustify/uncrustify#running-the-program and
>> >> attempt to run it on some files within rtems.git/cpukit/score/src
>> >> would be my suggestion.
>> >>
>> >> > On Mon, Mar 29, 2021 at 3:37 PM Gedare Bloom  wrote:
>> >> >>
>> >> >> Hi Ida,
>> >> >>
>> >> >> On Mon, Mar 29, 2021 at 7:36 AM Ida Delphine  wrote:
>> >> >> >
>> >> >> > Hello,
>> >> >> > Please do you mind telling me how to run uncrustify with the given 
>> >> >> > configuration with any sample file?
>> >> >>
>> >> >> What have you tried? Any directions followed/attempted or notes that
>> >> >> you have taken would be helpful.
>> >> >>
>> >> >> I guess all the info that you should need is in Uncrustify's readme
>> >> >> file. https://github.com/uncrustify/uncrustify
>> >> >>
>> >> >> Did you successfully compile uncrustify tool?
>> >> >>
>> >> >> > I'm a bit stuck.
>> >> >> >
>> >> >> > Thanks,
>> >> >> > Ida.
>> >> >> >
>> >> >> > On Wed, Mar 17, 2021 at 10:34 PM Gedare Bloom  
>> >> >> > wrote:
>> >> >> >>
>> >> >> >> On Wed, Mar 17, 2021 at 2:28 PM Ida Delphine  
>> >> >> >> wrote:
>> >> >> >> >
>> >> >> >> > Hello,
>> >> >> >> > So I have gone through this configuration file and I think I'm 
>> >> >> >> > getting it. However I'm a bit lost in the reading the messages in 
>> >> >> >> > the thread. Do you mind explaining? Or we can start talking about 
>> >> >> >> > a way forward.
>> >> >> >> > Also can you help me with some steps on how to test this by 
>> >> >> >> > myself if possible?
>> >> >> >> >
>> >> >> >>
>> >> >> >> It may be easier if you go "up" a level to see the full thread
>> >> >> >> context: 
>> >> >> >> https://lists.rtems.org/pipermail/devel/2020-October/thread.html#62769
>> >> >> >> Then you can go through the messages non-linearly. Right now, the
>> >> >> >> basic idea is to follow the steps outlined in the open project 
>> >> >> >> 

Re: #3860 - GSoC enquiries

[Joel Sherrill]

On Fri, Apr 2, 2021, 6:59 PM Gedare Bloom  wrote:

> On Fri, Apr 2, 2021 at 4:48 PM Ida Delphine  wrote:
> >
> > Hello,
> > Please can you help explain what you mean by Adding a "check-style"
> target to the RTEMS build system?
> > And how I could possibly go about this?
> >
> I don't know if this makes sense exactly to me.  When compiling RTEMS
> it could be nice to have an option to check the style rules for
> compliance. This would be something to integrate in the
> rtems.git/wscript file most likely, as part of the waf build system.
> However, since checking style does not generate a target file, I don't
> know that this really is suitable as a way to verify style rules. It
> may be suitable to add a standalone script in rtems-tools.git that can
> be run over the rtems.git that creates a report about style problems.
> Maybe, a way to configure it to ignore some files or to add exceptions
> to the style rules for certain cases then could be possible.
>

If you have a configuration that produces the code formatted as expected in
certain directories, then if a change is made as part of normal
development, running uncrustify will result in changes to the file needed.
In a way the goal is to have a directory full of files that an RTEMS
uncrustify configuration does not change.

If you have a script that can do that manually then we can easily add an
automated check somewhere in the process to ensure that directories that
adhere to the style rules continue to adhere to them.

One thing to keep in mind is that there there are places where uncrustify
does not have the ability to format code the way RTEMS has historically
done it. we want the rules to be as close as possible to the existing
practice but we are willing to adjust practice if it allows the tool to
produce formatted output we can trust.

On each point where this type of issue occurs, we'll have to have a
discussion about our Style versus what tool supports. It's likely indicates
we're doing something that's not common in the open source world.

Once the delta between the output of uncrustify and the committed source is
zero, running uncrustify should produce no changes. Anything uncrustify
wants to change at that point would be a style violation and flagged. In a
perfect world it would prevent you from committing.


>
> I think focus on 1 and 3 is better as a way to start, and perhaps
> something like the above can be the phase 2 effort.
>
> Gedare
>
> > Cheers,
> > Ida
> >
> > On Mon, Mar 29, 2021 at 9:45 PM Gedare Bloom  wrote:
> >>
> >> On Mon, Mar 29, 2021 at 1:28 PM Ida Delphine  wrote:
> >> >
> >> > Yes I have. But wondering how to run it with the given configuration
> I saw in this thread(
> https://lists.rtems.org/pipermail/devel/2020-October/062770.html).
> >> >
> >>
> >> If you download/copy the configuration into a cfg file, then you can
> >> use the examples from
> >> https://github.com/uncrustify/uncrustify#running-the-program and
> >> attempt to run it on some files within rtems.git/cpukit/score/src
> >> would be my suggestion.
> >>
> >> > On Mon, Mar 29, 2021 at 3:37 PM Gedare Bloom 
> wrote:
> >> >>
> >> >> Hi Ida,
> >> >>
> >> >> On Mon, Mar 29, 2021 at 7:36 AM Ida Delphine 
> wrote:
> >> >> >
> >> >> > Hello,
> >> >> > Please do you mind telling me how to run uncrustify with the given
> configuration with any sample file?
> >> >>
> >> >> What have you tried? Any directions followed/attempted or notes that
> >> >> you have taken would be helpful.
> >> >>
> >> >> I guess all the info that you should need is in Uncrustify's readme
> >> >> file. https://github.com/uncrustify/uncrustify
> >> >>
> >> >> Did you successfully compile uncrustify tool?
> >> >>
> >> >> > I'm a bit stuck.
> >> >> >
> >> >> > Thanks,
> >> >> > Ida.
> >> >> >
> >> >> > On Wed, Mar 17, 2021 at 10:34 PM Gedare Bloom 
> wrote:
> >> >> >>
> >> >> >> On Wed, Mar 17, 2021 at 2:28 PM Ida Delphine 
> wrote:
> >> >> >> >
> >> >> >> > Hello,
> >> >> >> > So I have gone through this configuration file and I think I'm
> getting it. However I'm a bit lost in the reading the messages in the
> thread. Do you mind explaining? Or we can start talking about a way forward.
> >> >> >> > Also can you help me with some steps on how to test this by
> myself if possible?
> >> >> >> >
> >> >> >>
> >> >> >> It may be easier if you go "up" a level to see the full thread
> >> >> >> context:
> https://lists.rtems.org/pipermail/devel/2020-October/thread.html#62769
> >> >> >> Then you can go through the messages non-linearly. Right now, the
> >> >> >> basic idea is to follow the steps outlined in the open project
> ticket.
> >> >> >> I think Christian has summarized it nicely in his recent email
> [1]: "I
> >> >> >> think the contributions from this project that would add value
> would
> >> >> >> be:
> >> >> >> 1. Finding a tool and a configuration that can do an RTEMS style
> or an
> >> >> >> acceptable close one.
> >> >> >> 2. Adding a "check-style" target to our build system.
> >> >> >> 

Re: #3860 - GSoC enquiries

[Gedare Bloom]

On Fri, Apr 2, 2021 at 4:48 PM Ida Delphine  wrote:
>
> Hello,
> Please can you help explain what you mean by Adding a "check-style" target to 
> the RTEMS build system?
> And how I could possibly go about this?
>
I don't know if this makes sense exactly to me.  When compiling RTEMS
it could be nice to have an option to check the style rules for
compliance. This would be something to integrate in the
rtems.git/wscript file most likely, as part of the waf build system.
However, since checking style does not generate a target file, I don't
know that this really is suitable as a way to verify style rules. It
may be suitable to add a standalone script in rtems-tools.git that can
be run over the rtems.git that creates a report about style problems.
Maybe, a way to configure it to ignore some files or to add exceptions
to the style rules for certain cases then could be possible.

I think focus on 1 and 3 is better as a way to start, and perhaps
something like the above can be the phase 2 effort.

Gedare

> Cheers,
> Ida
>
> On Mon, Mar 29, 2021 at 9:45 PM Gedare Bloom  wrote:
>>
>> On Mon, Mar 29, 2021 at 1:28 PM Ida Delphine  wrote:
>> >
>> > Yes I have. But wondering how to run it with the given configuration I saw 
>> > in this 
>> > thread(https://lists.rtems.org/pipermail/devel/2020-October/062770.html).
>> >
>>
>> If you download/copy the configuration into a cfg file, then you can
>> use the examples from
>> https://github.com/uncrustify/uncrustify#running-the-program and
>> attempt to run it on some files within rtems.git/cpukit/score/src
>> would be my suggestion.
>>
>> > On Mon, Mar 29, 2021 at 3:37 PM Gedare Bloom  wrote:
>> >>
>> >> Hi Ida,
>> >>
>> >> On Mon, Mar 29, 2021 at 7:36 AM Ida Delphine  wrote:
>> >> >
>> >> > Hello,
>> >> > Please do you mind telling me how to run uncrustify with the given 
>> >> > configuration with any sample file?
>> >>
>> >> What have you tried? Any directions followed/attempted or notes that
>> >> you have taken would be helpful.
>> >>
>> >> I guess all the info that you should need is in Uncrustify's readme
>> >> file. https://github.com/uncrustify/uncrustify
>> >>
>> >> Did you successfully compile uncrustify tool?
>> >>
>> >> > I'm a bit stuck.
>> >> >
>> >> > Thanks,
>> >> > Ida.
>> >> >
>> >> > On Wed, Mar 17, 2021 at 10:34 PM Gedare Bloom  wrote:
>> >> >>
>> >> >> On Wed, Mar 17, 2021 at 2:28 PM Ida Delphine  wrote:
>> >> >> >
>> >> >> > Hello,
>> >> >> > So I have gone through this configuration file and I think I'm 
>> >> >> > getting it. However I'm a bit lost in the reading the messages in 
>> >> >> > the thread. Do you mind explaining? Or we can start talking about a 
>> >> >> > way forward.
>> >> >> > Also can you help me with some steps on how to test this by myself 
>> >> >> > if possible?
>> >> >> >
>> >> >>
>> >> >> It may be easier if you go "up" a level to see the full thread
>> >> >> context: 
>> >> >> https://lists.rtems.org/pipermail/devel/2020-October/thread.html#62769
>> >> >> Then you can go through the messages non-linearly. Right now, the
>> >> >> basic idea is to follow the steps outlined in the open project ticket.
>> >> >> I think Christian has summarized it nicely in his recent email [1]: "I
>> >> >> think the contributions from this project that would add value would
>> >> >> be:
>> >> >> 1. Finding a tool and a configuration that can do an RTEMS style or an
>> >> >> acceptable close one.
>> >> >> 2. Adding a "check-style" target to our build system.
>> >> >> 3. Maybe add some kind of script similar to Linux "checkpatch.pl" that
>> >> >> could check whether patches would need changes _before_ they are
>> >> >> applied.
>> >> >> "
>> >> >>
>> >> >> The proposal preparation phase should work through identifying the
>> >> >> options and pros/cons for different tools while preparing a plan for
>> >> >> how to integrate style checks in 2, 3 and thinking through the coding
>> >> >> tasks for the summer.
>> >> >>
>> >> >> Getting the style checking tool's configuration to match with the
>> >> >> RTEMS style will be some effort, and testing it out and submitting
>> >> >> some patches based on it could be a good proposal activity also to
>> >> >> build some confidence about the tools that will be used.
>> >> >>
>> >> >> We also have some Python style guidelines that might be worth
>> >> >> addressing. Those are harder maybe, since the style refactoring might
>> >> >> be challenging to review for correctness.
>> >> >>
>> >> >> For getting started, I would recommend that you try running uncrustify
>> >> >> with the given configuration on some files in RTEMS, see what it
>> >> >> results in. Play around.
>> >> >>
>> >> >> [1] https://lists.rtems.org/pipermail/devel/2021-March/065547.html
>> >> >>
>> >> >> -Gedare
>> >> >>
>> >> >> > Thanks,
>> >> >> > Ida
>> >> >> >
>> >> >> > On Mon, Mar 15, 2021 at 9:39 PM Gedare Bloom  
>> >> >> > wrote:
>> >> >> >>
>> >> >> >> See the related thread, and we'll have to discuss how to move 
>> >> >> >> forward.

Re: #3860 - GSoC enquiries

[Ida Delphine]

Hello,
Please can you help explain what you mean by *Adding a "check-style" target
to the RTEMS build system*?
And how I could possibly go about this?

Cheers,
Ida

On Mon, Mar 29, 2021 at 9:45 PM Gedare Bloom  wrote:

> On Mon, Mar 29, 2021 at 1:28 PM Ida Delphine  wrote:
> >
> > Yes I have. But wondering how to run it with the given configuration I
> saw in this thread(
> https://lists.rtems.org/pipermail/devel/2020-October/062770.html).
> >
>
> If you download/copy the configuration into a cfg file, then you can
> use the examples from
> https://github.com/uncrustify/uncrustify#running-the-program and
> attempt to run it on some files within rtems.git/cpukit/score/src
> would be my suggestion.
>
> > On Mon, Mar 29, 2021 at 3:37 PM Gedare Bloom  wrote:
> >>
> >> Hi Ida,
> >>
> >> On Mon, Mar 29, 2021 at 7:36 AM Ida Delphine  wrote:
> >> >
> >> > Hello,
> >> > Please do you mind telling me how to run uncrustify with the given
> configuration with any sample file?
> >>
> >> What have you tried? Any directions followed/attempted or notes that
> >> you have taken would be helpful.
> >>
> >> I guess all the info that you should need is in Uncrustify's readme
> >> file. https://github.com/uncrustify/uncrustify
> >>
> >> Did you successfully compile uncrustify tool?
> >>
> >> > I'm a bit stuck.
> >> >
> >> > Thanks,
> >> > Ida.
> >> >
> >> > On Wed, Mar 17, 2021 at 10:34 PM Gedare Bloom 
> wrote:
> >> >>
> >> >> On Wed, Mar 17, 2021 at 2:28 PM Ida Delphine 
> wrote:
> >> >> >
> >> >> > Hello,
> >> >> > So I have gone through this configuration file and I think I'm
> getting it. However I'm a bit lost in the reading the messages in the
> thread. Do you mind explaining? Or we can start talking about a way forward.
> >> >> > Also can you help me with some steps on how to test this by myself
> if possible?
> >> >> >
> >> >>
> >> >> It may be easier if you go "up" a level to see the full thread
> >> >> context:
> https://lists.rtems.org/pipermail/devel/2020-October/thread.html#62769
> >> >> Then you can go through the messages non-linearly. Right now, the
> >> >> basic idea is to follow the steps outlined in the open project
> ticket.
> >> >> I think Christian has summarized it nicely in his recent email [1]:
> "I
> >> >> think the contributions from this project that would add value would
> >> >> be:
> >> >> 1. Finding a tool and a configuration that can do an RTEMS style or
> an
> >> >> acceptable close one.
> >> >> 2. Adding a "check-style" target to our build system.
> >> >> 3. Maybe add some kind of script similar to Linux "checkpatch.pl"
> that
> >> >> could check whether patches would need changes _before_ they are
> >> >> applied.
> >> >> "
> >> >>
> >> >> The proposal preparation phase should work through identifying the
> >> >> options and pros/cons for different tools while preparing a plan for
> >> >> how to integrate style checks in 2, 3 and thinking through the coding
> >> >> tasks for the summer.
> >> >>
> >> >> Getting the style checking tool's configuration to match with the
> >> >> RTEMS style will be some effort, and testing it out and submitting
> >> >> some patches based on it could be a good proposal activity also to
> >> >> build some confidence about the tools that will be used.
> >> >>
> >> >> We also have some Python style guidelines that might be worth
> >> >> addressing. Those are harder maybe, since the style refactoring might
> >> >> be challenging to review for correctness.
> >> >>
> >> >> For getting started, I would recommend that you try running
> uncrustify
> >> >> with the given configuration on some files in RTEMS, see what it
> >> >> results in. Play around.
> >> >>
> >> >> [1] https://lists.rtems.org/pipermail/devel/2021-March/065547.html
> >> >>
> >> >> -Gedare
> >> >>
> >> >> > Thanks,
> >> >> > Ida
> >> >> >
> >> >> > On Mon, Mar 15, 2021 at 9:39 PM Gedare Bloom 
> wrote:
> >> >> >>
> >> >> >> See the related thread, and we'll have to discuss how to move
> forward.
> >> >> >> The existing approach provides an uncrustify script:
> >> >> >> https://lists.rtems.org/pipermail/devel/2020-October/062769.html
> >> >> >>
> >> >> >>
> >> >> >> On Sun, Mar 14, 2021 at 9:47 PM Ida Delphine 
> wrote:
> >> >> >> >
> >> >> >> > Hello everyone,
> >> >> >> > This ticket(https://devel.rtems.org/ticket/3860) was proposed
> to me and I'm interested in it for GSoC.
> >> >> >> > The first task there is to find a code checker or formater that
> can produce results that match the RTEMS coding conventions. It also made
> mention some tools have been discussed in the past. Please I will love
> suggestions on possible tools I could use to achieve this.
> >> >> >> >
> >> >> >> >
> >> >> >> > Cheers,
> >> >> >> > Ida.
> >> >> >> > ___
> >> >> >> > devel mailing list
> >> >> >> > devel@rtems.org
> >> >> >> > http://lists.rtems.org/mailman/listinfo/devel
>
___
devel mailing list
devel@rtems.org

Re: #3860 - GSoC enquiries

[Gedare Bloom]

On Mon, Mar 29, 2021 at 1:28 PM Ida Delphine  wrote:
>
> Yes I have. But wondering how to run it with the given configuration I saw in 
> this thread(https://lists.rtems.org/pipermail/devel/2020-October/062770.html).
>

If you download/copy the configuration into a cfg file, then you can
use the examples from
https://github.com/uncrustify/uncrustify#running-the-program and
attempt to run it on some files within rtems.git/cpukit/score/src
would be my suggestion.

> On Mon, Mar 29, 2021 at 3:37 PM Gedare Bloom  wrote:
>>
>> Hi Ida,
>>
>> On Mon, Mar 29, 2021 at 7:36 AM Ida Delphine  wrote:
>> >
>> > Hello,
>> > Please do you mind telling me how to run uncrustify with the given 
>> > configuration with any sample file?
>>
>> What have you tried? Any directions followed/attempted or notes that
>> you have taken would be helpful.
>>
>> I guess all the info that you should need is in Uncrustify's readme
>> file. https://github.com/uncrustify/uncrustify
>>
>> Did you successfully compile uncrustify tool?
>>
>> > I'm a bit stuck.
>> >
>> > Thanks,
>> > Ida.
>> >
>> > On Wed, Mar 17, 2021 at 10:34 PM Gedare Bloom  wrote:
>> >>
>> >> On Wed, Mar 17, 2021 at 2:28 PM Ida Delphine  wrote:
>> >> >
>> >> > Hello,
>> >> > So I have gone through this configuration file and I think I'm getting 
>> >> > it. However I'm a bit lost in the reading the messages in the thread. 
>> >> > Do you mind explaining? Or we can start talking about a way forward.
>> >> > Also can you help me with some steps on how to test this by myself if 
>> >> > possible?
>> >> >
>> >>
>> >> It may be easier if you go "up" a level to see the full thread
>> >> context: 
>> >> https://lists.rtems.org/pipermail/devel/2020-October/thread.html#62769
>> >> Then you can go through the messages non-linearly. Right now, the
>> >> basic idea is to follow the steps outlined in the open project ticket.
>> >> I think Christian has summarized it nicely in his recent email [1]: "I
>> >> think the contributions from this project that would add value would
>> >> be:
>> >> 1. Finding a tool and a configuration that can do an RTEMS style or an
>> >> acceptable close one.
>> >> 2. Adding a "check-style" target to our build system.
>> >> 3. Maybe add some kind of script similar to Linux "checkpatch.pl" that
>> >> could check whether patches would need changes _before_ they are
>> >> applied.
>> >> "
>> >>
>> >> The proposal preparation phase should work through identifying the
>> >> options and pros/cons for different tools while preparing a plan for
>> >> how to integrate style checks in 2, 3 and thinking through the coding
>> >> tasks for the summer.
>> >>
>> >> Getting the style checking tool's configuration to match with the
>> >> RTEMS style will be some effort, and testing it out and submitting
>> >> some patches based on it could be a good proposal activity also to
>> >> build some confidence about the tools that will be used.
>> >>
>> >> We also have some Python style guidelines that might be worth
>> >> addressing. Those are harder maybe, since the style refactoring might
>> >> be challenging to review for correctness.
>> >>
>> >> For getting started, I would recommend that you try running uncrustify
>> >> with the given configuration on some files in RTEMS, see what it
>> >> results in. Play around.
>> >>
>> >> [1] https://lists.rtems.org/pipermail/devel/2021-March/065547.html
>> >>
>> >> -Gedare
>> >>
>> >> > Thanks,
>> >> > Ida
>> >> >
>> >> > On Mon, Mar 15, 2021 at 9:39 PM Gedare Bloom  wrote:
>> >> >>
>> >> >> See the related thread, and we'll have to discuss how to move forward.
>> >> >> The existing approach provides an uncrustify script:
>> >> >> https://lists.rtems.org/pipermail/devel/2020-October/062769.html
>> >> >>
>> >> >>
>> >> >> On Sun, Mar 14, 2021 at 9:47 PM Ida Delphine  wrote:
>> >> >> >
>> >> >> > Hello everyone,
>> >> >> > This ticket(https://devel.rtems.org/ticket/3860) was proposed to me 
>> >> >> > and I'm interested in it for GSoC.
>> >> >> > The first task there is to find a code checker or formater that can 
>> >> >> > produce results that match the RTEMS coding conventions. It also 
>> >> >> > made mention some tools have been discussed in the past. Please I 
>> >> >> > will love suggestions on possible tools I could use to achieve this.
>> >> >> >
>> >> >> >
>> >> >> > 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: #3860 - GSoC enquiries

[Ida Delphine]

Yes I have. But wondering how to run it with the given configuration I saw
in this thread(
https://lists.rtems.org/pipermail/devel/2020-October/062770.html).

On Mon, Mar 29, 2021 at 3:37 PM Gedare Bloom  wrote:

> Hi Ida,
>
> On Mon, Mar 29, 2021 at 7:36 AM Ida Delphine  wrote:
> >
> > Hello,
> > Please do you mind telling me how to run uncrustify with the given
> configuration with any sample file?
>
> What have you tried? Any directions followed/attempted or notes that
> you have taken would be helpful.
>
> I guess all the info that you should need is in Uncrustify's readme
> file. https://github.com/uncrustify/uncrustify
>
> Did you successfully compile uncrustify tool?
>
> > I'm a bit stuck.
> >
> > Thanks,
> > Ida.
> >
> > On Wed, Mar 17, 2021 at 10:34 PM Gedare Bloom  wrote:
> >>
> >> On Wed, Mar 17, 2021 at 2:28 PM Ida Delphine  wrote:
> >> >
> >> > Hello,
> >> > So I have gone through this configuration file and I think I'm
> getting it. However I'm a bit lost in the reading the messages in the
> thread. Do you mind explaining? Or we can start talking about a way forward.
> >> > Also can you help me with some steps on how to test this by myself if
> possible?
> >> >
> >>
> >> It may be easier if you go "up" a level to see the full thread
> >> context:
> https://lists.rtems.org/pipermail/devel/2020-October/thread.html#62769
> >> Then you can go through the messages non-linearly. Right now, the
> >> basic idea is to follow the steps outlined in the open project ticket.
> >> I think Christian has summarized it nicely in his recent email [1]: "I
> >> think the contributions from this project that would add value would
> >> be:
> >> 1. Finding a tool and a configuration that can do an RTEMS style or an
> >> acceptable close one.
> >> 2. Adding a "check-style" target to our build system.
> >> 3. Maybe add some kind of script similar to Linux "checkpatch.pl" that
> >> could check whether patches would need changes _before_ they are
> >> applied.
> >> "
> >>
> >> The proposal preparation phase should work through identifying the
> >> options and pros/cons for different tools while preparing a plan for
> >> how to integrate style checks in 2, 3 and thinking through the coding
> >> tasks for the summer.
> >>
> >> Getting the style checking tool's configuration to match with the
> >> RTEMS style will be some effort, and testing it out and submitting
> >> some patches based on it could be a good proposal activity also to
> >> build some confidence about the tools that will be used.
> >>
> >> We also have some Python style guidelines that might be worth
> >> addressing. Those are harder maybe, since the style refactoring might
> >> be challenging to review for correctness.
> >>
> >> For getting started, I would recommend that you try running uncrustify
> >> with the given configuration on some files in RTEMS, see what it
> >> results in. Play around.
> >>
> >> [1] https://lists.rtems.org/pipermail/devel/2021-March/065547.html
> >>
> >> -Gedare
> >>
> >> > Thanks,
> >> > Ida
> >> >
> >> > On Mon, Mar 15, 2021 at 9:39 PM Gedare Bloom 
> wrote:
> >> >>
> >> >> See the related thread, and we'll have to discuss how to move
> forward.
> >> >> The existing approach provides an uncrustify script:
> >> >> https://lists.rtems.org/pipermail/devel/2020-October/062769.html
> >> >>
> >> >>
> >> >> On Sun, Mar 14, 2021 at 9:47 PM Ida Delphine 
> wrote:
> >> >> >
> >> >> > Hello everyone,
> >> >> > This ticket(https://devel.rtems.org/ticket/3860) was proposed to
> me and I'm interested in it for GSoC.
> >> >> > The first task there is to find a code checker or formater that
> can produce results that match the RTEMS coding conventions. It also made
> mention some tools have been discussed in the past. Please I will love
> suggestions on possible tools I could use to achieve this.
> >> >> >
> >> >> >
> >> >> > 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: #3860 - GSoC enquiries

[Gedare Bloom]

Hi Ida,

On Mon, Mar 29, 2021 at 7:36 AM Ida Delphine  wrote:
>
> Hello,
> Please do you mind telling me how to run uncrustify with the given 
> configuration with any sample file?

What have you tried? Any directions followed/attempted or notes that
you have taken would be helpful.

I guess all the info that you should need is in Uncrustify's readme
file. https://github.com/uncrustify/uncrustify

Did you successfully compile uncrustify tool?

> I'm a bit stuck.
>
> Thanks,
> Ida.
>
> On Wed, Mar 17, 2021 at 10:34 PM Gedare Bloom  wrote:
>>
>> On Wed, Mar 17, 2021 at 2:28 PM Ida Delphine  wrote:
>> >
>> > Hello,
>> > So I have gone through this configuration file and I think I'm getting it. 
>> > However I'm a bit lost in the reading the messages in the thread. Do you 
>> > mind explaining? Or we can start talking about a way forward.
>> > Also can you help me with some steps on how to test this by myself if 
>> > possible?
>> >
>>
>> It may be easier if you go "up" a level to see the full thread
>> context: 
>> https://lists.rtems.org/pipermail/devel/2020-October/thread.html#62769
>> Then you can go through the messages non-linearly. Right now, the
>> basic idea is to follow the steps outlined in the open project ticket.
>> I think Christian has summarized it nicely in his recent email [1]: "I
>> think the contributions from this project that would add value would
>> be:
>> 1. Finding a tool and a configuration that can do an RTEMS style or an
>> acceptable close one.
>> 2. Adding a "check-style" target to our build system.
>> 3. Maybe add some kind of script similar to Linux "checkpatch.pl" that
>> could check whether patches would need changes _before_ they are
>> applied.
>> "
>>
>> The proposal preparation phase should work through identifying the
>> options and pros/cons for different tools while preparing a plan for
>> how to integrate style checks in 2, 3 and thinking through the coding
>> tasks for the summer.
>>
>> Getting the style checking tool's configuration to match with the
>> RTEMS style will be some effort, and testing it out and submitting
>> some patches based on it could be a good proposal activity also to
>> build some confidence about the tools that will be used.
>>
>> We also have some Python style guidelines that might be worth
>> addressing. Those are harder maybe, since the style refactoring might
>> be challenging to review for correctness.
>>
>> For getting started, I would recommend that you try running uncrustify
>> with the given configuration on some files in RTEMS, see what it
>> results in. Play around.
>>
>> [1] https://lists.rtems.org/pipermail/devel/2021-March/065547.html
>>
>> -Gedare
>>
>> > Thanks,
>> > Ida
>> >
>> > On Mon, Mar 15, 2021 at 9:39 PM Gedare Bloom  wrote:
>> >>
>> >> See the related thread, and we'll have to discuss how to move forward.
>> >> The existing approach provides an uncrustify script:
>> >> https://lists.rtems.org/pipermail/devel/2020-October/062769.html
>> >>
>> >>
>> >> On Sun, Mar 14, 2021 at 9:47 PM Ida Delphine  wrote:
>> >> >
>> >> > Hello everyone,
>> >> > This ticket(https://devel.rtems.org/ticket/3860) was proposed to me and 
>> >> > I'm interested in it for GSoC.
>> >> > The first task there is to find a code checker or formater that can 
>> >> > produce results that match the RTEMS coding conventions. It also made 
>> >> > mention some tools have been discussed in the past. Please I will love 
>> >> > suggestions on possible tools I could use to achieve this.
>> >> >
>> >> >
>> >> > 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: #3860 - GSoC enquiries

[Ida Delphine]

Hello,
Please do you mind telling me how to run uncrustify with the given
configuration with any sample file?
I'm a bit stuck.

Thanks,
Ida.

On Wed, Mar 17, 2021 at 10:34 PM Gedare Bloom  wrote:

> On Wed, Mar 17, 2021 at 2:28 PM Ida Delphine  wrote:
> >
> > Hello,
> > So I have gone through this configuration file and I think I'm getting
> it. However I'm a bit lost in the reading the messages in the thread. Do
> you mind explaining? Or we can start talking about a way forward.
> > Also can you help me with some steps on how to test this by myself if
> possible?
> >
>
> It may be easier if you go "up" a level to see the full thread
> context:
> https://lists.rtems.org/pipermail/devel/2020-October/thread.html#62769
> Then you can go through the messages non-linearly. Right now, the
> basic idea is to follow the steps outlined in the open project ticket.
> I think Christian has summarized it nicely in his recent email [1]: "I
> think the contributions from this project that would add value would
> be:
> 1. Finding a tool and a configuration that can do an RTEMS style or an
> acceptable close one.
> 2. Adding a "check-style" target to our build system.
> 3. Maybe add some kind of script similar to Linux "checkpatch.pl" that
> could check whether patches would need changes _before_ they are
> applied.
> "
>
> The proposal preparation phase should work through identifying the
> options and pros/cons for different tools while preparing a plan for
> how to integrate style checks in 2, 3 and thinking through the coding
> tasks for the summer.
>
> Getting the style checking tool's configuration to match with the
> RTEMS style will be some effort, and testing it out and submitting
> some patches based on it could be a good proposal activity also to
> build some confidence about the tools that will be used.
>
> We also have some Python style guidelines that might be worth
> addressing. Those are harder maybe, since the style refactoring might
> be challenging to review for correctness.
>
> For getting started, I would recommend that you try running uncrustify
> with the given configuration on some files in RTEMS, see what it
> results in. Play around.
>
> [1] https://lists.rtems.org/pipermail/devel/2021-March/065547.html
>
> -Gedare
>
> > Thanks,
> > Ida
> >
> > On Mon, Mar 15, 2021 at 9:39 PM Gedare Bloom  wrote:
> >>
> >> See the related thread, and we'll have to discuss how to move forward.
> >> The existing approach provides an uncrustify script:
> >> https://lists.rtems.org/pipermail/devel/2020-October/062769.html
> >>
> >>
> >> On Sun, Mar 14, 2021 at 9:47 PM Ida Delphine  wrote:
> >> >
> >> > Hello everyone,
> >> > This ticket(https://devel.rtems.org/ticket/3860) was proposed to me
> and I'm interested in it for GSoC.
> >> > The first task there is to find a code checker or formater that can
> produce results that match the RTEMS coding conventions. It also made
> mention some tools have been discussed in the past. Please I will love
> suggestions on possible tools I could use to achieve this.
> >> >
> >> >
> >> > 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: #3860 - GSoC enquiries

[Gedare Bloom]

On Wed, Mar 17, 2021 at 2:28 PM Ida Delphine  wrote:
>
> Hello,
> So I have gone through this configuration file and I think I'm getting it. 
> However I'm a bit lost in the reading the messages in the thread. Do you mind 
> explaining? Or we can start talking about a way forward.
> Also can you help me with some steps on how to test this by myself if 
> possible?
>

It may be easier if you go "up" a level to see the full thread
context: https://lists.rtems.org/pipermail/devel/2020-October/thread.html#62769
Then you can go through the messages non-linearly. Right now, the
basic idea is to follow the steps outlined in the open project ticket.
I think Christian has summarized it nicely in his recent email [1]: "I
think the contributions from this project that would add value would
be:
1. Finding a tool and a configuration that can do an RTEMS style or an
acceptable close one.
2. Adding a "check-style" target to our build system.
3. Maybe add some kind of script similar to Linux "checkpatch.pl" that
could check whether patches would need changes _before_ they are
applied.
"

The proposal preparation phase should work through identifying the
options and pros/cons for different tools while preparing a plan for
how to integrate style checks in 2, 3 and thinking through the coding
tasks for the summer.

Getting the style checking tool's configuration to match with the
RTEMS style will be some effort, and testing it out and submitting
some patches based on it could be a good proposal activity also to
build some confidence about the tools that will be used.

We also have some Python style guidelines that might be worth
addressing. Those are harder maybe, since the style refactoring might
be challenging to review for correctness.

For getting started, I would recommend that you try running uncrustify
with the given configuration on some files in RTEMS, see what it
results in. Play around.

[1] https://lists.rtems.org/pipermail/devel/2021-March/065547.html

-Gedare

> Thanks,
> Ida
>
> On Mon, Mar 15, 2021 at 9:39 PM Gedare Bloom  wrote:
>>
>> See the related thread, and we'll have to discuss how to move forward.
>> The existing approach provides an uncrustify script:
>> https://lists.rtems.org/pipermail/devel/2020-October/062769.html
>>
>>
>> On Sun, Mar 14, 2021 at 9:47 PM Ida Delphine  wrote:
>> >
>> > Hello everyone,
>> > This ticket(https://devel.rtems.org/ticket/3860) was proposed to me and 
>> > I'm interested in it for GSoC.
>> > The first task there is to find a code checker or formater that can 
>> > produce results that match the RTEMS coding conventions. It also made 
>> > mention some tools have been discussed in the past. Please I will love 
>> > suggestions on possible tools I could use to achieve this.
>> >
>> >
>> > 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: #3860 - GSoC enquiries

[Ida Delphine]

Hello,
So I have gone through this configuration file and I think I'm getting it.
However I'm a bit lost in the reading the messages in the thread. Do you
mind explaining? Or we can start talking about a way forward.
Also can you help me with some steps on how to test this by myself if
possible?

Thanks,
Ida

On Mon, Mar 15, 2021 at 9:39 PM Gedare Bloom  wrote:

> See the related thread, and we'll have to discuss how to move forward.
> The existing approach provides an uncrustify script:
> https://lists.rtems.org/pipermail/devel/2020-October/062769.html
>
>
> On Sun, Mar 14, 2021 at 9:47 PM Ida Delphine  wrote:
> >
> > Hello everyone,
> > This ticket(https://devel.rtems.org/ticket/3860) was proposed to me and
> I'm interested in it for GSoC.
> > The first task there is to find a code checker or formater that can
> produce results that match the RTEMS coding conventions. It also made
> mention some tools have been discussed in the past. Please I will love
> suggestions on possible tools I could use to achieve this.
> >
> >
> > 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: #3860 - GSoC enquiries

[Gedare Bloom]

See the related thread, and we'll have to discuss how to move forward.
The existing approach provides an uncrustify script:
https://lists.rtems.org/pipermail/devel/2020-October/062769.html


On Sun, Mar 14, 2021 at 9:47 PM Ida Delphine  wrote:
>
> Hello everyone,
> This ticket(https://devel.rtems.org/ticket/3860) was proposed to me and I'm 
> interested in it for GSoC.
> The first task there is to find a code checker or formater that can produce 
> results that match the RTEMS coding conventions. It also made mention some 
> tools have been discussed in the past. Please I will love suggestions on 
> possible tools I could use to achieve this.
>
>
> 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