You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@nuttx.apache.org by Peter van der Perk <pe...@nxp.com> on 2025/03/17 14:00:21 UTC
RE: [EXT] Re: [PROPOSAL] New nxstyle tool roadmap
The main issue I was facing with clang-format was the indentation with NuttX BreakBeforeBraces style see
https://github.com/llvm/llvm-project/issues/44188
Regards,
Peter
-----Original Message-----
From: Nathan Hartman <ha...@gmail.com>
Sent: Monday, March 17, 2025 2:39 PM
To: dev@nuttx.apache.org
Subject: Re: [PROPOSAL] New nxstyle tool roadmap
Regarding the missing features in clang format, have you considered opening feature requests for these with the clang devs?
Regarding a nxtool with multiple subcommands for things, such as style checking, this is an interesting idea that should be explored.
My only concern is with the addition of developer-side dependencies.
Whenever we add more required tools or languages on the developer's system, we potentially add friction that makes it harder for newcomer to adopt NuttX.
It may not be avoidable, and in the long run, we're probably better off using existing well-maintained and well-adopted tools, which both Python and tree-sitter are, than to maintain custom tooling that tries to duplicate such functionality.
Python is very likely to already be installed on developer machines, so is a good choice of scripting language. But we should still consider this
carefully:
Python is a language that morphs all the time and is always growing new features and syntax (like C++; the language has become huge). You have to know the whole language, because different developers who contribute to the scripts will know and use different parts of the language. Also Python has been known to change in non-backward-compatible ways, so we'll forever need to chase these.
NuttX is implemented in C, so all of the NuttX devs know C, and aren't necessarily Python experts. Should we consider adopting tree-sitter but implementing nxtool in C?
Cheers,
Nathan
On Mon, Mar 17, 2025 at 9:00 AM Matteo Golin <ma...@gmail.com> wrote:
> Hello,
>
> I have tried to make a clang format configuration to use, but I have
> the same problem where there are a couple style items that clang
> format has no options for. Things like enforcing lowercase hex or
> putting curly braces indented on a separate line after static initializers.
>
> On Mon, Mar 17, 2025, 8:52 AM Mark Stevens <ma...@thepcsite.co.uk> wrote:
>
> > Has anyone looked at using a custom .clang-format file to see if we
> > can get close to the NuttX style?
> >
> > I’ve used this route in a couple of projects. I did have to
> > compromise
> on
> > one or two rules as I could not get the exact format I wanted. I
> > thought this was worth it as it saved me writing my own tool to do
> > the job. I
> then
> > used a docker script to run the checks on every PR.
> >
> > Just wondering if it would save some effort.
> >
> > Regards,
> > Mark
> > -------------------------------------------
> > Mark Stevens
> > Blog: blog.mark-stevens.co.uk
> >
> >
> > > On 17 Mar 2025, at 11:31, Luchian Mihai <lu...@gmail.com>
> > wrote:
> > >
> > > Hello Nuttx,
> > >
> > > *--- Summary ---*
> > > I've been in the habit of fixing small issues regarding nxstyle.
> > >
> > > One of the last conclusions drawn was that it does not tokenize
> > > the
> file,
> > > which leads to limitations in checking syntax.
> > > Please check
> > > https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2F
> > > github.com%2Fapache%2Fnuttx%2Fpull%2F15847&data=05%7C02%7Cpeter.va
> > > nderperk%40nxp.com%7C523719ea66ff4c72fe8d08dd65591eda%7C686ea1d3bc
> > > 2b4c6fa92cd99c5c301635%7C0%7C0%7C638778155632496788%7CUnknown%7CTW
> > > FpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4z
> > > MiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=hULCYTu4Wc
> > > TAeojjtlaWZlKrEi0hdM7WBEWYVBGlWu0%3D&reserved=0 for further
> > details.
> > >
> > > I am working on a new implementation of nxstyle using python and
> > > tree-sitter for parsing and checking the source code.
> > > Treesitter is getting more traction in the past years. Some
> > > editors are making use of treesitter, such as zed, neovim, helix, and others.
> > > GitHub uses if for code navigation
> > >
> >
> https://docs/
> .github.com%2Fen%2Frepositories%2Fworking-with-files%2Fusing-files%2Fn
> avigating-code-on-github&data=05%7C02%7Cpeter.vanderperk%40nxp.com%7C5
> 23719ea66ff4c72fe8d08dd65591eda%7C686ea1d3bc2b4c6fa92cd99c5c301635%7C0
> %7C0%7C638778155632522235%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRy
> dWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%
> 3D%7C0%7C%7C%7C&sdata=pqiaN5mq4Vkfftwe8G2F1PsmxFXDw08XkVsAx%2BjkjqI%3D
> &reserved=0
> > > So, I think it may be a suitable solution for nuttx as well.
> > >
> > > This will take a lot of work, but you can track my progress at
> > > https://github.com/LuchianMihai/nuttx/tree/nxtool.
> > > Please feel free to add any suggestions you may see fit.
> > >
> > > *--- Questions ---*
> > >
> > > 1.
> > > I've also set up the work for an new tool, calling it nxtool (at
> > > the
> > time I
> > > did not know that is not a new name/concept), Mostly, it's a
> > > "boilerplate" to add more subcommands under a common
> > command
> > > called nxtool.
> > > Currently only a single subcommand is present, checkpatch,
> > > equivalent
> to
> > > the present checkpatch.sh so basically call *nxtool checkpatch
> > > file* Now I've dug the mailing archive and found that nxtool, or
> > > similar
> > projects
> > > were proposed in the past, such as
> > > https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2F
> > > gitlab.com%2Fnuttx-upm%2Fupm&data=05%7C02%7Cpeter.vanderperk%40nxp
> > > .com%7C523719ea66ff4c72fe8d08dd65591eda%7C686ea1d3bc2b4c6fa92cd99c
> > > 5c301635%7C0%7C0%7C638778155632554445%7CUnknown%7CTWFpbGZsb3d8eyJF
> > > bXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTW
> > > FpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=CPkRSYKGw1uEmABoXKTyelEO
> > > axSV%2BAhdAIRe%2Fq7rhFE%3D&reserved=0 or
> > > https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2F
> > > gitlab.com%2Fnuttx_projects%2Fnuttx_workspace_manager&data=05%7C02
> > > %7Cpeter.vanderperk%40nxp.com%7C523719ea66ff4c72fe8d08dd65591eda%7
> > > C686ea1d3bc2b4c6fa92cd99c5c301635%7C0%7C0%7C638778155632569907%7CU
> > > nknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsI
> > > lAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata
> > > =HTL0lm3o1zZrGCjDRAWUGimzePcoD4ivySqmpOoK22c%3D&reserved=0
> > > But both of them seem abandoned or not actively worked on.
> > > I feel like I'm missing some info regarding the work I'm doing.
> > > Why did the work stop, what was the issue with them?
> > > I saw mentions of zephyr meta-tool west, and they weren't bad, or
> against
> > > tools alike.
> > >
> > > So my question basically is, what is the take of the nuttx
> > > community
> > python
> > > based meta-tool?
> > >
> > > 2.
> > > Although I've already started investing time in this, I'm not sure
> > > how
> > much
> > > effort the nuttx community is willing to invest for enforcing this
> > > custom coding style in favor of using clang-format and gnu style.
> > > If I'm to add a new tool for enforcing nuttx coding style, I'd
> > > like to
> > know
> > > that there is no talk about deprecating this work.
> > >
> > > *--- Cosing words ---*
> > >
> > > As mentioned previously, please reply with any proposals, ideas,
> thoughts
> > > you have for such a tool, if any,
> > > or any counter arguments you may have.
> >
> >
>
Re: [EXT] Re: [PROPOSAL] New nxstyle tool roadmap
Posted by Tomek CEDRO <to...@cedro.info>.
To be honest this GNU style is a bit awkward as I tend to use K&R..
but I must admit it is really easy to read and understand when reading
new code.. but NuttX seems to use GNU derivative anyways so no
"generic tools" can be used here and this is the main problem? :-)
https://nuttx.apache.org/docs/latest/contributing/coding_style.html
I would be careful with Python, I use it myself, but it becomes more
and more self-incompatible in the long term, so I would suggest
focusing on generic minimal C-like tools that does not change often
with time :-P
The coding style is not that important if there are good tools to
verify and convert to whatever style is required i.e. vim / emacs /
vscode plugin or some script that can convert/validate specific
file(s). We can adapt GNU, K&R, Allman, or whatever seems best to the
community. Assuming this change will make our life easier :-)
Thanks :-)
Tomek
On Tue, Mar 18, 2025 at 5:18 PM Luchian Mihai <lu...@gmail.com> wrote:
>
> Well, this is what I fear, working for something that may change anyway.
> I cannot force this change, If we come to an agreement I'll continue the
> work I've started, else it is just a waste of time.
> Can we make a choice regarding code style?
>
> Cheers,
> Mihai
>
>
> On Tue, 18 Mar 2025 at 00:32, Michał Łyszczek <mi...@bofc.pl>
> wrote:
>
> > Peter van der Perk:
> > > The main issue I was facing with clang-format was the indentation with
> > NuttX
> > > BreakBeforeBraces style see
> > > https://github.com/llvm/llvm-project/issues/44188
> >
> > Maybe it's time to say it out loud. GNU indent style for curly brackets
> > should die ;). Changing these to Allman style should be trivial without
> > the risk of breaking anything.
> >
> > This would enable use of well established project insead of maintaining
> > internal one.
--
CeDeROM, SQ7MHZ, http://www.tomek.cedro.info
Re: [EXT] Re: [PROPOSAL] New nxstyle tool roadmap
Posted by Luchian Mihai <lu...@gmail.com>.
Well, this is what I fear, working for something that may change anyway.
I cannot force this change, If we come to an agreement I'll continue the
work I've started, else it is just a waste of time.
Can we make a choice regarding code style?
Cheers,
Mihai
On Tue, 18 Mar 2025 at 00:32, Michał Łyszczek <mi...@bofc.pl>
wrote:
> Peter van der Perk:
> > The main issue I was facing with clang-format was the indentation with
> NuttX
> > BreakBeforeBraces style see
> > https://github.com/llvm/llvm-project/issues/44188
>
> Maybe it's time to say it out loud. GNU indent style for curly brackets
> should die ;). Changing these to Allman style should be trivial without
> the risk of breaking anything.
>
> This would enable use of well established project insead of maintaining
> internal one.
Re: [EXT] Re: [PROPOSAL] New nxstyle tool roadmap
Posted by Tomek CEDRO <to...@cedro.info>.
On Wed, Mar 19, 2025 at 9:58 AM Luchian Mihai <lu...@gmail.com> wrote:
> Hello all,
> First, a few conclusions I've drawn:
> * Keep indent checking fully decoupled, indent style may or may not change
> in future.
> * For the moment we'll keep gnu style. Code style change will have a big
> impact over the code base.
> * If it comes to change, Allman is the best candidate, this will not have
> an significant impact on my work, changing an constant for braces indent
> depth (this only applies for indent)
Maybe adhering to GNU will enable standard tools and bring minimal
change. But there is a big resistance, so probably updating
tools/nxstyle is the way to go.. using C as it is right now. NuttX is
quite conservative as you can see. Most of us can work with different
code styles while we care most about functionality and long-term
maintenance :-)
Luchian maybe you could focus on different area where currently
manpower is more desired.. like adding drivers to missing peripherals
in existing MCUs, updating documentation, or adding missing CMake
stuff if you prefer to support more modern tools?
> Second, some would avoid python, let's discuss programming language:
> I'll add a few key points for this discussion:
> * Zephyr is using python for its meta-tool, west.
> * Mynewt is using go for its meta-tool, newt
> * Do nuttx need/want a similar meta-tool
> * There are already python scripts in our tooling, maybe worth
> standardizing them.
> * If it comes to not using python i'll insist on using rust, personal take,
> I do not want to handle strings using c.
There were discussions like this before. We do not want this kind of
meta-tool. No additional programming languages frameworks and
dependencies to setup things. We want to keep things absolutely
minimal and Unix aligned with independent but cooperating building
blocks as it is right now. Including CMake and Python was exception
here rather than a rule :-)
How would you like to standardize python scripts? Right now these are
independent tools, so if anything that uses them updates then a tool
update goes along together. If you standardize them into a meta-tool
then this meta-tool will require additional work for maintenance and
updating one thing may break other things and we want to avoid that. I
guess small building blocks are here by design :-)
Rust is supported by nuttx-apps but only as option for users
interested in it. It is their burden to have all dependencies built
and installed. No one else is impacted. But having rust as basic
dependency just to setup things is a strong no-go here. Imagine
building whole rust ecosystem on a small embedded system with limited
resources where packages are not provided (i.e. rPI0). I had this
problem with pyOCD+CMSIS-Pack-Manager, other folks too, so the
dependency was removed as default after feedback of the community. We
recently did tests of automated distributed testing on rPI0 and it was
working fine. Introducing Rust as basic setup dependency would make
things a lot more complicated and time consuming, maybe even a blocker
on some platforms, we want to avoid that.
I was recently on a hands-on STM workshop. I did quick port NuttX to a
new MCU under 10 minutes. While the workshop was aimed at Zephyr and
(~30) people could not even git clone the repository to start working.
It was too big to fetch at once by that many people. Minimalistic
approach of NuttX has its benefits :-)
> Let's hear the community take on this subject.
Always good to discuss :-)
Have a good day folks :-)
Tomek
ps/2: Is this a some sort of global race where winner changes as many
lines of code without actual change of the functionality / without
adding new functionality / breaking existing functionality? Are people
paid per changed line of code right now? Maybe "progress" is measured
by changed lines of code or PR amount? :-P
--
CeDeROM, SQ7MHZ, http://www.tomek.cedro.info
Re: [EXT] Re: [PROPOSAL] New nxstyle tool roadmap
Posted by Luchian Mihai <lu...@gmail.com>.
Hello all,
First, a few conclusions I've drawn:
* Keep indent checking fully decoupled, indent style may or may not change
in future.
* For the moment we'll keep gnu style. Code style change will have a big
impact over the code base.
* If it comes to change, Allman is the best candidate, this will not have
an significant impact on my work, changing an constant for braces indent
depth (this only applies for indent)
Second, some would avoid python, let's discuss programming language:
I'll add a few key points for this discussion:
* Zephyr is using python for its meta-tool, west.
* Mynewt is using go for its meta-tool, newt
* Do nuttx need/want a similar meta-tool
* There are already python scripts in our tooling, maybe worth
standardizing them.
* If it comes to not using python i'll insist on using rust, personal take,
I do not want to handle strings using c.
Let's hear the community take on this subject.
Cheers,
Mihai
On Wed, 19 Mar 2025 at 09:44, raiden00pl <ra...@gmail.com> wrote:
> K&R is ugly and unreadable. It will also mess up git history a lot, so I'll
> definitely vote against it.
> Allman is much more acceptable, but style change is a significant change
> for the project,
> and there's been a lot of complaining here lately about "big changes".
>
> śr., 19 mar 2025 o 02:03 Michał Łyszczek <mi...@bofc.pl>
> napisał(a):
>
> > Nathan Hartman:
> > > But, if there's going to be a discussion about brace styles, I would
> vote
> > > for K&R's One True Brace Style. :-)
> >
> > I agree that K&R is the way to go. But. Switching to Allman is just
> > removing
> > 2 spaces on lines where bracket is. Change is trivial and will not mess
> > with
> > the history.
> >
> > In theory going to K&R is simple too. Basically same check as with
> Allman,
> > but instead of removing 2 spaces you remove all spaces + previous new
> line
> > character. But this will impact history, as all if/for/while will have an
> > altered line where check is happening.
> >
> > tl;dr: K&R is more compact, but will mess with history. Allman will be
> just
> > as vertically wide as GNU, but will leave history intact where it
> matters.
> >
> > I am down to any change that removes that awful GNU indent :)
>
Re: [EXT] Re: [PROPOSAL] New nxstyle tool roadmap
Posted by Luchian Mihai <lu...@gmail.com>.
Then it's settled,
Thanks,
Mihai
On Wed, 19 Mar 2025 at 15:33, Sebastien Lorquet <se...@lorquet.fr>
wrote:
> Hello
>
> I admit it was a bad idea.
>
> What I support is no change at all.
>
> Also, yeah, it's in the inviolables, thanks for the reminder Greg.
>
> Sebastien
>
>
> On 19/03/2025 14:23, raiden00pl wrote:
> > Changing the code style for new files only is the worst possible idea.
> > Maintaining two
> > styles is so bad that I'm surprised that someone even suggested it.
> > The best decision would be to not change anything in the code style, but
> if
> > we
> > decide to change the style, the entire codebase should be updated. This
> of
> > course
> > raises the problems mentioned above, which is why I think it's best not
> to
> > change
> > the style at all. The current style was chosen by Greg and we should
> > respect that :)
> >
> > śr., 19 mar 2025 o 14:05 Nathan Hartman <ha...@gmail.com>
> > napisał(a):
> >
> >> On Wed, Mar 19, 2025 at 5:45 AM Sebastien Lorquet <sebastien@lorquet.fr
> >
> >> wrote:
> >> (snip)
> >>
> >>> Messing *all* developer working copies with huge diffs just for code
> >>> formatting is a no-go. This will prevent bissections and backports.
> >>
> >> This is by far my biggest concern with code style changes. Bissections,
> >> backports, comparisons across revisions and across releases, and much
> >> more--these things are far, far more important for maintenance and
> >> stabilization.
> >>
> >> Again, I recommend *not* to change code style, and if change must be
> made
> >> to support widely adopted tooling, let's keep it to an absolute
> minimum, or
> >> investigate asking the widely adopted tooling to add support for some of
> >> our nuances.
> >>
> >> Specifically, I am *not* in favor of changing brace style. GNU brace
> style
> >> *is* supported by widely adopted tooling.
> >>
> >> (I only mentioned K&R to illustrate that if we start debating brace
> styles,
> >> people will come out of the woodwork to promote their favorite style and
> >> we'll get nowhere. So far we've heard GNU, Allman, K&R, Whitesmiths...
> >> brace styles are one of the holy wars of computing. Let's keep the brace
> >> style we've always used in this project and focus on more important
> >> things.)
> >>
> >> Define some relevant rules for new code if you want, but please dont
> >>> rewrite the full nuttx codebase just for the pleasure of the eyes (or
> >>> the pleasure to use a new toy^H^H^Htool).
> >>
> >> The problem with defining a new style for new code and keeping the old
> >> style for old code is that a 1 line change in a 10,000 line file will
> mean
> >> reformatting the whole file, if we follow the same rules we have now
> with
> >> nxstyle. And we'll have 2 code styles and be inconsistent, so things
> like
> >> editorconfig won't work.
> >>
> >> Cheers,
> >> Nathan
> >>
>
Re: [EXT] Re: [PROPOSAL] New nxstyle tool roadmap
Posted by Sebastien Lorquet <se...@lorquet.fr>.
Hello
I admit it was a bad idea.
What I support is no change at all.
Also, yeah, it's in the inviolables, thanks for the reminder Greg.
Sebastien
On 19/03/2025 14:23, raiden00pl wrote:
> Changing the code style for new files only is the worst possible idea.
> Maintaining two
> styles is so bad that I'm surprised that someone even suggested it.
> The best decision would be to not change anything in the code style, but if
> we
> decide to change the style, the entire codebase should be updated. This of
> course
> raises the problems mentioned above, which is why I think it's best not to
> change
> the style at all. The current style was chosen by Greg and we should
> respect that :)
>
> śr., 19 mar 2025 o 14:05 Nathan Hartman <ha...@gmail.com>
> napisał(a):
>
>> On Wed, Mar 19, 2025 at 5:45 AM Sebastien Lorquet <se...@lorquet.fr>
>> wrote:
>> (snip)
>>
>>> Messing *all* developer working copies with huge diffs just for code
>>> formatting is a no-go. This will prevent bissections and backports.
>>
>> This is by far my biggest concern with code style changes. Bissections,
>> backports, comparisons across revisions and across releases, and much
>> more--these things are far, far more important for maintenance and
>> stabilization.
>>
>> Again, I recommend *not* to change code style, and if change must be made
>> to support widely adopted tooling, let's keep it to an absolute minimum, or
>> investigate asking the widely adopted tooling to add support for some of
>> our nuances.
>>
>> Specifically, I am *not* in favor of changing brace style. GNU brace style
>> *is* supported by widely adopted tooling.
>>
>> (I only mentioned K&R to illustrate that if we start debating brace styles,
>> people will come out of the woodwork to promote their favorite style and
>> we'll get nowhere. So far we've heard GNU, Allman, K&R, Whitesmiths...
>> brace styles are one of the holy wars of computing. Let's keep the brace
>> style we've always used in this project and focus on more important
>> things.)
>>
>> Define some relevant rules for new code if you want, but please dont
>>> rewrite the full nuttx codebase just for the pleasure of the eyes (or
>>> the pleasure to use a new toy^H^H^Htool).
>>
>> The problem with defining a new style for new code and keeping the old
>> style for old code is that a 1 line change in a 10,000 line file will mean
>> reformatting the whole file, if we follow the same rules we have now with
>> nxstyle. And we'll have 2 code styles and be inconsistent, so things like
>> editorconfig won't work.
>>
>> Cheers,
>> Nathan
>>
Re: [EXT] Re: [PROPOSAL] New nxstyle tool roadmap
Posted by raiden00pl <ra...@gmail.com>.
Changing the code style for new files only is the worst possible idea.
Maintaining two
styles is so bad that I'm surprised that someone even suggested it.
The best decision would be to not change anything in the code style, but if
we
decide to change the style, the entire codebase should be updated. This of
course
raises the problems mentioned above, which is why I think it's best not to
change
the style at all. The current style was chosen by Greg and we should
respect that :)
śr., 19 mar 2025 o 14:05 Nathan Hartman <ha...@gmail.com>
napisał(a):
> On Wed, Mar 19, 2025 at 5:45 AM Sebastien Lorquet <se...@lorquet.fr>
> wrote:
> (snip)
>
> > Messing *all* developer working copies with huge diffs just for code
> > formatting is a no-go. This will prevent bissections and backports.
>
>
> This is by far my biggest concern with code style changes. Bissections,
> backports, comparisons across revisions and across releases, and much
> more--these things are far, far more important for maintenance and
> stabilization.
>
> Again, I recommend *not* to change code style, and if change must be made
> to support widely adopted tooling, let's keep it to an absolute minimum, or
> investigate asking the widely adopted tooling to add support for some of
> our nuances.
>
> Specifically, I am *not* in favor of changing brace style. GNU brace style
> *is* supported by widely adopted tooling.
>
> (I only mentioned K&R to illustrate that if we start debating brace styles,
> people will come out of the woodwork to promote their favorite style and
> we'll get nowhere. So far we've heard GNU, Allman, K&R, Whitesmiths...
> brace styles are one of the holy wars of computing. Let's keep the brace
> style we've always used in this project and focus on more important
> things.)
>
> Define some relevant rules for new code if you want, but please dont
> > rewrite the full nuttx codebase just for the pleasure of the eyes (or
> > the pleasure to use a new toy^H^H^Htool).
>
>
> The problem with defining a new style for new code and keeping the old
> style for old code is that a 1 line change in a 10,000 line file will mean
> reformatting the whole file, if we follow the same rules we have now with
> nxstyle. And we'll have 2 code styles and be inconsistent, so things like
> editorconfig won't work.
>
> Cheers,
> Nathan
>
Re: [EXT] Re: [PROPOSAL] New nxstyle tool roadmap
Posted by Luchian Mihai <lu...@gmail.com>.
Hi Alan,
This discussion did in fact not start from a bug.
It just happens to have some spare time on my hands and I want to work on
something other than embedded.
I fixed some nxstyle bugs previously and saw this opportunity to work with
trees (as in data structure, tree-sitter)
I've started this discussion to make my work visible, and to preempt some
changes that I may have not been aware of.
Regarding my questions, I like Greg's answer, short, on point answer.
"We keep nuttx style, it's in the inviolables."
Same applies for my second question (would be useful for nuttx a meta-tool).
"Yes" or "Let's try and see" or "No, let's keep scripts independent".
Same applies for any other topics we could discuss over my proposal, like
choice of programming language.
It was never my intention to change anything, any change would have been
done at the request/agreement of the community.
To be honest, it doesn't matter too much to me the style choice, I like
nuttx coding style (it's a trademark / signature)
and I also think that it is a better idea to work on our own linter,
tree-sitter can make easy work on parsing and checking.
Your proposal is also fine, I can alway support it.
I fear the problem will be enforcing/agreeing to either choice, the new
nxstyle that keeps the old style, or alter the current style.
I think the same holds true about any other features you mentioned, maybe
this situation can be avoided if some roadmaps can be sketched.
A way to express "we are going this direction".
Anyway, my conclusion is as follows:
I'll continue the work using python and tree-sitter under my initial nxtool
proposal.
I'll follow the guidelines at contributing / c coding style.
We'll see the outcome during code review when a pull request gets opened.
Cheers,
Mihai
On Wed, 19 Mar 2025 at 17:54, Alan C. Assis <ac...@gmail.com> wrote:
> I agree that this change will have an impact, but the discussion here is to
> decide whether we can switch to a format supported by other linters and
> code formatters like clang-format or not.
>
> If there is no BUG to be fixed, why are so many people discussing this
> here? (30+
> emails so far).
>
> So before making any decision, I suggest we confirm that changing the
> parentheses indentation from GNU to Altman will make it possible to use
> clang-format to lint the NuttX code style.
>
> If I remember correctly, there are many other coding styles that are
> exclusive to NuttX, maybe no linter is prepared for NuttX! :-D
>
> Luchian, thank you for raising this topic, but I need to warn you to not
> spend too much time investigating this problem. We had previous examples of
> people spending a lot for time creating new features to NuttX (i.e.
> CMakefile, Device Tree) and then some people came here to say it was not
> necessary. Unfortunately these developers that try to do things like that
> are skilled developers and we lost them forever.
>
> BR,
>
> Alan
>
> On Wed, Mar 19, 2025 at 12:22 PM Sebastien Lorquet <se...@lorquet.fr>
> wrote:
>
> > Hello,
> >
> > My feeling is that moving all braces by 2 spaces to the right is not
> > worth the gigantic mess and maintenance nightmare it will create in the
> > entire repositories.
> >
> > And as noticed by raidenp00l, changing only new files makes no sense
> > since it means maintaining two different indentation systems.
> >
> > The reasonable option is to do nothing at all.
> >
> > As of now, indentation works, there is no bug to fix, and changing it
> > will not improve nuttx.
> >
> > Sebastien
> >
> >
> > On 19/03/2025 16:14, Alan C. Assis wrote:
> > > But changing from GNU to Altman (removing 2 "half" indentation spaces)
> > > could fall on this category:
> > >
> > > ``No "revolutionary" changes to the coding standard (but perhaps some
> > > "evolutionary" changes).''
> > >
> > > BR,
> > >
> > > Alan
> > >
> > >
> > > On Wed, Mar 19, 2025 at 10:24 AM Gregory Nutt <sp...@gmail.com>
> > wrote:
> > >
> > >> Coding style change are discussed in INVIOLABLES.md:
> > >>
> >
> https://github.com/apache/nuttx/blob/master/INVIOLABLES.md#clear-consistent-standardized-coding-style
> > >> ________________________________
> > >> From: Nathan Hartman <ha...@gmail.com>
> > >> Sent: Wednesday, March 19, 2025 6:03 AM
> > >> To: dev@nuttx.apache.org <de...@nuttx.apache.org>
> > >> Subject: Re: [EXT] Re: [PROPOSAL] New nxstyle tool roadmap
> > >>
> > >> On Wed, Mar 19, 2025 at 5:45 AM Sebastien Lorquet <
> sebastien@lorquet.fr
> > >
> > >> wrote:
> > >> (snip)
> > >>
> > >>> Messing *all* developer working copies with huge diffs just for code
> > >>> formatting is a no-go. This will prevent bissections and backports.
> > >>
> > >> This is by far my biggest concern with code style changes.
> Bissections,
> > >> backports, comparisons across revisions and across releases, and much
> > >> more--these things are far, far more important for maintenance and
> > >> stabilization.
> > >>
> > >> Again, I recommend *not* to change code style, and if change must be
> > made
> > >> to support widely adopted tooling, let's keep it to an absolute
> > minimum, or
> > >> investigate asking the widely adopted tooling to add support for some
> of
> > >> our nuances.
> > >>
> > >> Specifically, I am *not* in favor of changing brace style. GNU brace
> > style
> > >> *is* supported by widely adopted tooling.
> > >>
> > >> (I only mentioned K&R to illustrate that if we start debating brace
> > styles,
> > >> people will come out of the woodwork to promote their favorite style
> and
> > >> we'll get nowhere. So far we've heard GNU, Allman, K&R, Whitesmiths...
> > >> brace styles are one of the holy wars of computing. Let's keep the
> brace
> > >> style we've always used in this project and focus on more important
> > >> things.)
> > >>
> > >> Define some relevant rules for new code if you want, but please dont
> > >>> rewrite the full nuttx codebase just for the pleasure of the eyes (or
> > >>> the pleasure to use a new toy^H^H^Htool).
> > >>
> > >> The problem with defining a new style for new code and keeping the old
> > >> style for old code is that a 1 line change in a 10,000 line file will
> > mean
> > >> reformatting the whole file, if we follow the same rules we have now
> > with
> > >> nxstyle. And we'll have 2 code styles and be inconsistent, so things
> > like
> > >> editorconfig won't work.
> > >>
> > >> Cheers,
> > >> Nathan
> > >>
> >
>
Re: [EXT] Re: [PROPOSAL] New nxstyle tool roadmap
Posted by "Alan C. Assis" <ac...@gmail.com>.
I agree that this change will have an impact, but the discussion here is to
decide whether we can switch to a format supported by other linters and
code formatters like clang-format or not.
If there is no BUG to be fixed, why are so many people discussing this
here? (30+
emails so far).
So before making any decision, I suggest we confirm that changing the
parentheses indentation from GNU to Altman will make it possible to use
clang-format to lint the NuttX code style.
If I remember correctly, there are many other coding styles that are
exclusive to NuttX, maybe no linter is prepared for NuttX! :-D
Luchian, thank you for raising this topic, but I need to warn you to not
spend too much time investigating this problem. We had previous examples of
people spending a lot for time creating new features to NuttX (i.e.
CMakefile, Device Tree) and then some people came here to say it was not
necessary. Unfortunately these developers that try to do things like that
are skilled developers and we lost them forever.
BR,
Alan
On Wed, Mar 19, 2025 at 12:22 PM Sebastien Lorquet <se...@lorquet.fr>
wrote:
> Hello,
>
> My feeling is that moving all braces by 2 spaces to the right is not
> worth the gigantic mess and maintenance nightmare it will create in the
> entire repositories.
>
> And as noticed by raidenp00l, changing only new files makes no sense
> since it means maintaining two different indentation systems.
>
> The reasonable option is to do nothing at all.
>
> As of now, indentation works, there is no bug to fix, and changing it
> will not improve nuttx.
>
> Sebastien
>
>
> On 19/03/2025 16:14, Alan C. Assis wrote:
> > But changing from GNU to Altman (removing 2 "half" indentation spaces)
> > could fall on this category:
> >
> > ``No "revolutionary" changes to the coding standard (but perhaps some
> > "evolutionary" changes).''
> >
> > BR,
> >
> > Alan
> >
> >
> > On Wed, Mar 19, 2025 at 10:24 AM Gregory Nutt <sp...@gmail.com>
> wrote:
> >
> >> Coding style change are discussed in INVIOLABLES.md:
> >>
> https://github.com/apache/nuttx/blob/master/INVIOLABLES.md#clear-consistent-standardized-coding-style
> >> ________________________________
> >> From: Nathan Hartman <ha...@gmail.com>
> >> Sent: Wednesday, March 19, 2025 6:03 AM
> >> To: dev@nuttx.apache.org <de...@nuttx.apache.org>
> >> Subject: Re: [EXT] Re: [PROPOSAL] New nxstyle tool roadmap
> >>
> >> On Wed, Mar 19, 2025 at 5:45 AM Sebastien Lorquet <sebastien@lorquet.fr
> >
> >> wrote:
> >> (snip)
> >>
> >>> Messing *all* developer working copies with huge diffs just for code
> >>> formatting is a no-go. This will prevent bissections and backports.
> >>
> >> This is by far my biggest concern with code style changes. Bissections,
> >> backports, comparisons across revisions and across releases, and much
> >> more--these things are far, far more important for maintenance and
> >> stabilization.
> >>
> >> Again, I recommend *not* to change code style, and if change must be
> made
> >> to support widely adopted tooling, let's keep it to an absolute
> minimum, or
> >> investigate asking the widely adopted tooling to add support for some of
> >> our nuances.
> >>
> >> Specifically, I am *not* in favor of changing brace style. GNU brace
> style
> >> *is* supported by widely adopted tooling.
> >>
> >> (I only mentioned K&R to illustrate that if we start debating brace
> styles,
> >> people will come out of the woodwork to promote their favorite style and
> >> we'll get nowhere. So far we've heard GNU, Allman, K&R, Whitesmiths...
> >> brace styles are one of the holy wars of computing. Let's keep the brace
> >> style we've always used in this project and focus on more important
> >> things.)
> >>
> >> Define some relevant rules for new code if you want, but please dont
> >>> rewrite the full nuttx codebase just for the pleasure of the eyes (or
> >>> the pleasure to use a new toy^H^H^Htool).
> >>
> >> The problem with defining a new style for new code and keeping the old
> >> style for old code is that a 1 line change in a 10,000 line file will
> mean
> >> reformatting the whole file, if we follow the same rules we have now
> with
> >> nxstyle. And we'll have 2 code styles and be inconsistent, so things
> like
> >> editorconfig won't work.
> >>
> >> Cheers,
> >> Nathan
> >>
>
Re: [EXT] Re: [PROPOSAL] New nxstyle tool roadmap
Posted by Sebastien Lorquet <se...@lorquet.fr>.
Hello,
My feeling is that moving all braces by 2 spaces to the right is not
worth the gigantic mess and maintenance nightmare it will create in the
entire repositories.
And as noticed by raidenp00l, changing only new files makes no sense
since it means maintaining two different indentation systems.
The reasonable option is to do nothing at all.
As of now, indentation works, there is no bug to fix, and changing it
will not improve nuttx.
Sebastien
On 19/03/2025 16:14, Alan C. Assis wrote:
> But changing from GNU to Altman (removing 2 "half" indentation spaces)
> could fall on this category:
>
> ``No "revolutionary" changes to the coding standard (but perhaps some
> "evolutionary" changes).''
>
> BR,
>
> Alan
>
>
> On Wed, Mar 19, 2025 at 10:24 AM Gregory Nutt <sp...@gmail.com> wrote:
>
>> Coding style change are discussed in INVIOLABLES.md:
>> https://github.com/apache/nuttx/blob/master/INVIOLABLES.md#clear-consistent-standardized-coding-style
>> ________________________________
>> From: Nathan Hartman <ha...@gmail.com>
>> Sent: Wednesday, March 19, 2025 6:03 AM
>> To: dev@nuttx.apache.org <de...@nuttx.apache.org>
>> Subject: Re: [EXT] Re: [PROPOSAL] New nxstyle tool roadmap
>>
>> On Wed, Mar 19, 2025 at 5:45 AM Sebastien Lorquet <se...@lorquet.fr>
>> wrote:
>> (snip)
>>
>>> Messing *all* developer working copies with huge diffs just for code
>>> formatting is a no-go. This will prevent bissections and backports.
>>
>> This is by far my biggest concern with code style changes. Bissections,
>> backports, comparisons across revisions and across releases, and much
>> more--these things are far, far more important for maintenance and
>> stabilization.
>>
>> Again, I recommend *not* to change code style, and if change must be made
>> to support widely adopted tooling, let's keep it to an absolute minimum, or
>> investigate asking the widely adopted tooling to add support for some of
>> our nuances.
>>
>> Specifically, I am *not* in favor of changing brace style. GNU brace style
>> *is* supported by widely adopted tooling.
>>
>> (I only mentioned K&R to illustrate that if we start debating brace styles,
>> people will come out of the woodwork to promote their favorite style and
>> we'll get nowhere. So far we've heard GNU, Allman, K&R, Whitesmiths...
>> brace styles are one of the holy wars of computing. Let's keep the brace
>> style we've always used in this project and focus on more important
>> things.)
>>
>> Define some relevant rules for new code if you want, but please dont
>>> rewrite the full nuttx codebase just for the pleasure of the eyes (or
>>> the pleasure to use a new toy^H^H^Htool).
>>
>> The problem with defining a new style for new code and keeping the old
>> style for old code is that a 1 line change in a 10,000 line file will mean
>> reformatting the whole file, if we follow the same rules we have now with
>> nxstyle. And we'll have 2 code styles and be inconsistent, so things like
>> editorconfig won't work.
>>
>> Cheers,
>> Nathan
>>
Re: [EXT] Re: [PROPOSAL] New nxstyle tool roadmap
Posted by Gregory Nutt <sp...@gmail.com>.
My issues in the past with "pretty printers" were most mostly with C
comments. Most pretty-printers just scramble comments, especially if
they don't understand the comment indentation. NuttX multi-line comments
are not supported by anything AFAIK. And comment information that has a
columnar organization can also cause code scrambling.
THIS:
https://nuttx.apache.org/docs/latest/contributing/coding_style.html#comments
There are (or were) a couple of tools scripts that tried to make GNU
into Nuttx (under tools/). They were miserable failures, due primarily
to commenting.
Re: [EXT] Re: [PROPOSAL] New nxstyle tool roadmap
Posted by "Alan C. Assis" <ac...@gmail.com>.
But changing from GNU to Altman (removing 2 "half" indentation spaces)
could fall on this category:
``No "revolutionary" changes to the coding standard (but perhaps some
"evolutionary" changes).''
BR,
Alan
On Wed, Mar 19, 2025 at 10:24 AM Gregory Nutt <sp...@gmail.com> wrote:
> Coding style change are discussed in INVIOLABLES.md:
> https://github.com/apache/nuttx/blob/master/INVIOLABLES.md#clear-consistent-standardized-coding-style
> ________________________________
> From: Nathan Hartman <ha...@gmail.com>
> Sent: Wednesday, March 19, 2025 6:03 AM
> To: dev@nuttx.apache.org <de...@nuttx.apache.org>
> Subject: Re: [EXT] Re: [PROPOSAL] New nxstyle tool roadmap
>
> On Wed, Mar 19, 2025 at 5:45 AM Sebastien Lorquet <se...@lorquet.fr>
> wrote:
> (snip)
>
> > Messing *all* developer working copies with huge diffs just for code
> > formatting is a no-go. This will prevent bissections and backports.
>
>
> This is by far my biggest concern with code style changes. Bissections,
> backports, comparisons across revisions and across releases, and much
> more--these things are far, far more important for maintenance and
> stabilization.
>
> Again, I recommend *not* to change code style, and if change must be made
> to support widely adopted tooling, let's keep it to an absolute minimum, or
> investigate asking the widely adopted tooling to add support for some of
> our nuances.
>
> Specifically, I am *not* in favor of changing brace style. GNU brace style
> *is* supported by widely adopted tooling.
>
> (I only mentioned K&R to illustrate that if we start debating brace styles,
> people will come out of the woodwork to promote their favorite style and
> we'll get nowhere. So far we've heard GNU, Allman, K&R, Whitesmiths...
> brace styles are one of the holy wars of computing. Let's keep the brace
> style we've always used in this project and focus on more important
> things.)
>
> Define some relevant rules for new code if you want, but please dont
> > rewrite the full nuttx codebase just for the pleasure of the eyes (or
> > the pleasure to use a new toy^H^H^Htool).
>
>
> The problem with defining a new style for new code and keeping the old
> style for old code is that a 1 line change in a 10,000 line file will mean
> reformatting the whole file, if we follow the same rules we have now with
> nxstyle. And we'll have 2 code styles and be inconsistent, so things like
> editorconfig won't work.
>
> Cheers,
> Nathan
>
Re: [EXT] Re: [PROPOSAL] New nxstyle tool roadmap
Posted by Gregory Nutt <sp...@gmail.com>.
Coding style change are discussed in INVIOLABLES.md: https://github.com/apache/nuttx/blob/master/INVIOLABLES.md#clear-consistent-standardized-coding-style
________________________________
From: Nathan Hartman <ha...@gmail.com>
Sent: Wednesday, March 19, 2025 6:03 AM
To: dev@nuttx.apache.org <de...@nuttx.apache.org>
Subject: Re: [EXT] Re: [PROPOSAL] New nxstyle tool roadmap
On Wed, Mar 19, 2025 at 5:45 AM Sebastien Lorquet <se...@lorquet.fr>
wrote:
(snip)
> Messing *all* developer working copies with huge diffs just for code
> formatting is a no-go. This will prevent bissections and backports.
This is by far my biggest concern with code style changes. Bissections,
backports, comparisons across revisions and across releases, and much
more--these things are far, far more important for maintenance and
stabilization.
Again, I recommend *not* to change code style, and if change must be made
to support widely adopted tooling, let's keep it to an absolute minimum, or
investigate asking the widely adopted tooling to add support for some of
our nuances.
Specifically, I am *not* in favor of changing brace style. GNU brace style
*is* supported by widely adopted tooling.
(I only mentioned K&R to illustrate that if we start debating brace styles,
people will come out of the woodwork to promote their favorite style and
we'll get nowhere. So far we've heard GNU, Allman, K&R, Whitesmiths...
brace styles are one of the holy wars of computing. Let's keep the brace
style we've always used in this project and focus on more important things.)
Define some relevant rules for new code if you want, but please dont
> rewrite the full nuttx codebase just for the pleasure of the eyes (or
> the pleasure to use a new toy^H^H^Htool).
The problem with defining a new style for new code and keeping the old
style for old code is that a 1 line change in a 10,000 line file will mean
reformatting the whole file, if we follow the same rules we have now with
nxstyle. And we'll have 2 code styles and be inconsistent, so things like
editorconfig won't work.
Cheers,
Nathan
Re: [EXT] Re: [PROPOSAL] New nxstyle tool roadmap
Posted by Nathan Hartman <ha...@gmail.com>.
On Wed, Mar 19, 2025 at 5:45 AM Sebastien Lorquet <se...@lorquet.fr>
wrote:
(snip)
> Messing *all* developer working copies with huge diffs just for code
> formatting is a no-go. This will prevent bissections and backports.
This is by far my biggest concern with code style changes. Bissections,
backports, comparisons across revisions and across releases, and much
more--these things are far, far more important for maintenance and
stabilization.
Again, I recommend *not* to change code style, and if change must be made
to support widely adopted tooling, let's keep it to an absolute minimum, or
investigate asking the widely adopted tooling to add support for some of
our nuances.
Specifically, I am *not* in favor of changing brace style. GNU brace style
*is* supported by widely adopted tooling.
(I only mentioned K&R to illustrate that if we start debating brace styles,
people will come out of the woodwork to promote their favorite style and
we'll get nowhere. So far we've heard GNU, Allman, K&R, Whitesmiths...
brace styles are one of the holy wars of computing. Let's keep the brace
style we've always used in this project and focus on more important things.)
Define some relevant rules for new code if you want, but please dont
> rewrite the full nuttx codebase just for the pleasure of the eyes (or
> the pleasure to use a new toy^H^H^Htool).
The problem with defining a new style for new code and keeping the old
style for old code is that a 1 line change in a 10,000 line file will mean
reformatting the whole file, if we follow the same rules we have now with
nxstyle. And we'll have 2 code styles and be inconsistent, so things like
editorconfig won't work.
Cheers,
Nathan
Re: [EXT] Re: [PROPOSAL] New nxstyle tool roadmap
Posted by Nathan Hartman <ha...@gmail.com>.
On Wed, Mar 19, 2025 at 5:45 AM Sebastien Lorquet <se...@lorquet.fr>
wrote:
(snip)
> Messing *all* developer working copies with huge diffs just for code
> formatting is a no-go. This will prevent bissections and backports.
This is by far my biggest concern with code style changes. Bissections,
backports, comparisons across revisions and across releases, and much
more--these things are far, far more important for maintenance and
stabilization.
Again, I recommend *not* to change code style, and if change must be made
to support widely adopted tooling, let's keep it to an absolute minimum, or
investigate asking the widely adopted tooling to add support for some of
our nuances.
Specifically, I am *not* in favor of changing brace style. GNU brace style
*is* supported by widely adopted tooling.
(I only mentioned K&R to illustrate that if we start debating brace styles,
people will come out of the woodwork to promote their favorite style and
we'll get nowhere. So far we've heard GNU, Allman, K&R, Whitesmiths...
brace styles are one of the holy wars of computing. Let's keep the brace
style we've always used in this project and focus on more important things.)
Define some relevant rules for new code if you want, but please dont
> rewrite the full nuttx codebase just for the pleasure of the eyes (or
> the pleasure to use a new toy^H^H^Htool).
The problem with defining a new style for new code and keeping the old
style for old code is that a 1 line change in a 10,000 line file will mean
reformatting the whole file, if we follow the same rules we have now with
nxstyle. And we'll have 2 code styles and be inconsistent, so things like
editorconfig won't work.
Cheers,
Nathan
Re: Re: [PROPOSAL] New nxstyle tool roadmap
Posted by Luchian Mihai <lu...@gmail.com>.
Hello,
A change of style, in my opinion, should be started by a maintainer and
agreed by (at least) majority.
The python bindings to tree-sitter allows editing files. I do not intend to
support this feature, but it can be an option for autoformatter.
Cheers, Mihai
On Wed, 19 Mar 2025 at 14:06, Peter van der Perk <pe...@nxp.com>
wrote:
> After working in many codebases, I don't really have any preference for a
> style.
> Except that the project should have an autoformatter such as clang-format
> or astyle.
>
> Unfortunely the current code style for NuttX is so exotic that no
> formatter supports it well.
> So, either an autoformatter should be adapted supporting the NuttX style
> features or maybe consider switching code style allowing the use of an
> autoformatter, which is still less preferred regarding git history.
>
> Peter
>
> -----Original Message-----
> From: Sebastien Lorquet <se...@lorquet.fr>
> Sent: Wednesday, March 19, 2025 11:45 AM
> To: dev@nuttx.apache.org
> Subject: Re: Re: [PROPOSAL] New nxstyle tool roadmap
>
>
> Hello,
>
> Great, thank you.
>
>
> At dayjob for 15 years I have used Whitesmiths, which I actually like now
> (I resisted at first!), and is the most logical one for me, as the full
> sub-block is indented, so it's very readable, almost like python.
> My company uses this style for historical and code readability reasons.
>
> So I have to adapt anyways. A preference would be to avoid a style with
> 'half indentations' such as gnu. K&R is fine for me.
>
> But code compacity is an illusion. Well spaced code is easier to
> understand and maintain.
>
> So Allman would work for me too.
>
> Sebastien
>
>
> On 19/03/2025 11:14, Luchian Mihai wrote:
> > I do not want to change anything, I'm working on a linter.
> > It will only *report* noncompliance to a style, not *change* the
> > source code.
> > The enforcing part should only be imposed by code review, not a tool.
> > I'm not a supporter of automatic pipelines either, this compliance
> > should be manual work.
> > My previous questions were to clarify the community agreed style.
> > I aim to improve the existing tooling, with minimal change on the
> > actual kernel/apps/c codebase as possible.
> >
> > On Wed, 19 Mar 2025 at 11:44, Sebastien Lorquet <se...@lorquet.fr>
> > wrote:
> >
> >> I will just tell one generic thing:
> >>
> >> Please just dont push commits just to change the code style globally.
> >> What is written is written.
> >>
> >> Messing *all* developer working copies with huge diffs just for code
> >> formatting is a no-go. This will prevent bissections and backports.
> >>
> >> Define some relevant rules for new code if you want, but please dont
> >> rewrite the full nuttx codebase just for the pleasure of the eyes (or
> >> the pleasure to use a new toy^H^H^Htool).
> >>
> >> Sebastien
> >>
> >>
> >> On 19/03/2025 08:43, raiden00pl wrote:
> >>> K&R is ugly and unreadable. It will also mess up git history a lot,
> >>> so
> >> I'll
> >>> definitely vote against it.
> >>> Allman is much more acceptable, but style change is a significant
> >>> change for the project, and there's been a lot of complaining here
> >>> lately about "big changes".
> >>>
> >>> śr., 19 mar 2025 o 02:03 Michał Łyszczek <mi...@bofc.pl>
> >>> napisał(a):
> >>>
> >>>> Nathan Hartman:
> >>>>> But, if there's going to be a discussion about brace styles, I
> >>>>> would
> >> vote
> >>>>> for K&R's One True Brace Style. :-)
> >>>> I agree that K&R is the way to go. But. Switching to Allman is just
> >>>> removing
> >>>> 2 spaces on lines where bracket is. Change is trivial and will not
> >>>> mess with the history.
> >>>>
> >>>> In theory going to K&R is simple too. Basically same check as with
> >> Allman,
> >>>> but instead of removing 2 spaces you remove all spaces + previous
> >>>> new
> >> line
> >>>> character. But this will impact history, as all if/for/while will
> >>>> have
> >> an
> >>>> altered line where check is happening.
> >>>>
> >>>> tl;dr: K&R is more compact, but will mess with history. Allman will
> >>>> be
> >> just
> >>>> as vertically wide as GNU, but will leave history intact where it
> >> matters.
> >>>> I am down to any change that removes that awful GNU indent :)
>
RE: Re: [PROPOSAL] New nxstyle tool roadmap
Posted by Peter van der Perk <pe...@nxp.com>.
After working in many codebases, I don't really have any preference for a style.
Except that the project should have an autoformatter such as clang-format or astyle.
Unfortunely the current code style for NuttX is so exotic that no formatter supports it well.
So, either an autoformatter should be adapted supporting the NuttX style features or maybe consider switching code style allowing the use of an autoformatter, which is still less preferred regarding git history.
Peter
-----Original Message-----
From: Sebastien Lorquet <se...@lorquet.fr>
Sent: Wednesday, March 19, 2025 11:45 AM
To: dev@nuttx.apache.org
Subject: Re: Re: [PROPOSAL] New nxstyle tool roadmap
Hello,
Great, thank you.
At dayjob for 15 years I have used Whitesmiths, which I actually like now (I resisted at first!), and is the most logical one for me, as the full sub-block is indented, so it's very readable, almost like python.
My company uses this style for historical and code readability reasons.
So I have to adapt anyways. A preference would be to avoid a style with 'half indentations' such as gnu. K&R is fine for me.
But code compacity is an illusion. Well spaced code is easier to understand and maintain.
So Allman would work for me too.
Sebastien
On 19/03/2025 11:14, Luchian Mihai wrote:
> I do not want to change anything, I'm working on a linter.
> It will only *report* noncompliance to a style, not *change* the
> source code.
> The enforcing part should only be imposed by code review, not a tool.
> I'm not a supporter of automatic pipelines either, this compliance
> should be manual work.
> My previous questions were to clarify the community agreed style.
> I aim to improve the existing tooling, with minimal change on the
> actual kernel/apps/c codebase as possible.
>
> On Wed, 19 Mar 2025 at 11:44, Sebastien Lorquet <se...@lorquet.fr>
> wrote:
>
>> I will just tell one generic thing:
>>
>> Please just dont push commits just to change the code style globally.
>> What is written is written.
>>
>> Messing *all* developer working copies with huge diffs just for code
>> formatting is a no-go. This will prevent bissections and backports.
>>
>> Define some relevant rules for new code if you want, but please dont
>> rewrite the full nuttx codebase just for the pleasure of the eyes (or
>> the pleasure to use a new toy^H^H^Htool).
>>
>> Sebastien
>>
>>
>> On 19/03/2025 08:43, raiden00pl wrote:
>>> K&R is ugly and unreadable. It will also mess up git history a lot,
>>> so
>> I'll
>>> definitely vote against it.
>>> Allman is much more acceptable, but style change is a significant
>>> change for the project, and there's been a lot of complaining here
>>> lately about "big changes".
>>>
>>> śr., 19 mar 2025 o 02:03 Michał Łyszczek <mi...@bofc.pl>
>>> napisał(a):
>>>
>>>> Nathan Hartman:
>>>>> But, if there's going to be a discussion about brace styles, I
>>>>> would
>> vote
>>>>> for K&R's One True Brace Style. :-)
>>>> I agree that K&R is the way to go. But. Switching to Allman is just
>>>> removing
>>>> 2 spaces on lines where bracket is. Change is trivial and will not
>>>> mess with the history.
>>>>
>>>> In theory going to K&R is simple too. Basically same check as with
>> Allman,
>>>> but instead of removing 2 spaces you remove all spaces + previous
>>>> new
>> line
>>>> character. But this will impact history, as all if/for/while will
>>>> have
>> an
>>>> altered line where check is happening.
>>>>
>>>> tl;dr: K&R is more compact, but will mess with history. Allman will
>>>> be
>> just
>>>> as vertically wide as GNU, but will leave history intact where it
>> matters.
>>>> I am down to any change that removes that awful GNU indent :)
Re: [EXT] Re: [PROPOSAL] New nxstyle tool roadmap
Posted by Sebastien Lorquet <se...@lorquet.fr>.
Hello,
Great, thank you.
At dayjob for 15 years I have used Whitesmiths, which I actually like
now (I resisted at first!), and is the most logical one for me, as the
full sub-block is indented, so it's very readable, almost like python.
My company uses this style for historical and code readability reasons.
So I have to adapt anyways. A preference would be to avoid a style with
'half indentations' such as gnu. K&R is fine for me.
But code compacity is an illusion. Well spaced code is easier to
understand and maintain.
So Allman would work for me too.
Sebastien
On 19/03/2025 11:14, Luchian Mihai wrote:
> I do not want to change anything, I'm working on a linter.
> It will only *report* noncompliance to a style, not *change* the source
> code.
> The enforcing part should only be imposed by code review, not a tool.
> I'm not a supporter of automatic pipelines either, this compliance should
> be manual work.
> My previous questions were to clarify the community agreed style.
> I aim to improve the existing tooling, with minimal change on the actual
> kernel/apps/c codebase as possible.
>
> On Wed, 19 Mar 2025 at 11:44, Sebastien Lorquet <se...@lorquet.fr>
> wrote:
>
>> I will just tell one generic thing:
>>
>> Please just dont push commits just to change the code style globally.
>> What is written is written.
>>
>> Messing *all* developer working copies with huge diffs just for code
>> formatting is a no-go. This will prevent bissections and backports.
>>
>> Define some relevant rules for new code if you want, but please dont
>> rewrite the full nuttx codebase just for the pleasure of the eyes (or
>> the pleasure to use a new toy^H^H^Htool).
>>
>> Sebastien
>>
>>
>> On 19/03/2025 08:43, raiden00pl wrote:
>>> K&R is ugly and unreadable. It will also mess up git history a lot, so
>> I'll
>>> definitely vote against it.
>>> Allman is much more acceptable, but style change is a significant change
>>> for the project,
>>> and there's been a lot of complaining here lately about "big changes".
>>>
>>> śr., 19 mar 2025 o 02:03 Michał Łyszczek <mi...@bofc.pl>
>>> napisał(a):
>>>
>>>> Nathan Hartman:
>>>>> But, if there's going to be a discussion about brace styles, I would
>> vote
>>>>> for K&R's One True Brace Style. :-)
>>>> I agree that K&R is the way to go. But. Switching to Allman is just
>>>> removing
>>>> 2 spaces on lines where bracket is. Change is trivial and will not mess
>>>> with
>>>> the history.
>>>>
>>>> In theory going to K&R is simple too. Basically same check as with
>> Allman,
>>>> but instead of removing 2 spaces you remove all spaces + previous new
>> line
>>>> character. But this will impact history, as all if/for/while will have
>> an
>>>> altered line where check is happening.
>>>>
>>>> tl;dr: K&R is more compact, but will mess with history. Allman will be
>> just
>>>> as vertically wide as GNU, but will leave history intact where it
>> matters.
>>>> I am down to any change that removes that awful GNU indent :)
Re: [EXT] Re: [PROPOSAL] New nxstyle tool roadmap
Posted by Luchian Mihai <lu...@gmail.com>.
I do not want to change anything, I'm working on a linter.
It will only *report* noncompliance to a style, not *change* the source
code.
The enforcing part should only be imposed by code review, not a tool.
I'm not a supporter of automatic pipelines either, this compliance should
be manual work.
My previous questions were to clarify the community agreed style.
I aim to improve the existing tooling, with minimal change on the actual
kernel/apps/c codebase as possible.
On Wed, 19 Mar 2025 at 11:44, Sebastien Lorquet <se...@lorquet.fr>
wrote:
> I will just tell one generic thing:
>
> Please just dont push commits just to change the code style globally.
> What is written is written.
>
> Messing *all* developer working copies with huge diffs just for code
> formatting is a no-go. This will prevent bissections and backports.
>
> Define some relevant rules for new code if you want, but please dont
> rewrite the full nuttx codebase just for the pleasure of the eyes (or
> the pleasure to use a new toy^H^H^Htool).
>
> Sebastien
>
>
> On 19/03/2025 08:43, raiden00pl wrote:
> > K&R is ugly and unreadable. It will also mess up git history a lot, so
> I'll
> > definitely vote against it.
> > Allman is much more acceptable, but style change is a significant change
> > for the project,
> > and there's been a lot of complaining here lately about "big changes".
> >
> > śr., 19 mar 2025 o 02:03 Michał Łyszczek <mi...@bofc.pl>
> > napisał(a):
> >
> >> Nathan Hartman:
> >>> But, if there's going to be a discussion about brace styles, I would
> vote
> >>> for K&R's One True Brace Style. :-)
> >> I agree that K&R is the way to go. But. Switching to Allman is just
> >> removing
> >> 2 spaces on lines where bracket is. Change is trivial and will not mess
> >> with
> >> the history.
> >>
> >> In theory going to K&R is simple too. Basically same check as with
> Allman,
> >> but instead of removing 2 spaces you remove all spaces + previous new
> line
> >> character. But this will impact history, as all if/for/while will have
> an
> >> altered line where check is happening.
> >>
> >> tl;dr: K&R is more compact, but will mess with history. Allman will be
> just
> >> as vertically wide as GNU, but will leave history intact where it
> matters.
> >>
> >> I am down to any change that removes that awful GNU indent :)
>
Re: [EXT] Re: [PROPOSAL] New nxstyle tool roadmap
Posted by Sebastien Lorquet <se...@lorquet.fr>.
I will just tell one generic thing:
Please just dont push commits just to change the code style globally.
What is written is written.
Messing *all* developer working copies with huge diffs just for code
formatting is a no-go. This will prevent bissections and backports.
Define some relevant rules for new code if you want, but please dont
rewrite the full nuttx codebase just for the pleasure of the eyes (or
the pleasure to use a new toy^H^H^Htool).
Sebastien
On 19/03/2025 08:43, raiden00pl wrote:
> K&R is ugly and unreadable. It will also mess up git history a lot, so I'll
> definitely vote against it.
> Allman is much more acceptable, but style change is a significant change
> for the project,
> and there's been a lot of complaining here lately about "big changes".
>
> śr., 19 mar 2025 o 02:03 Michał Łyszczek <mi...@bofc.pl>
> napisał(a):
>
>> Nathan Hartman:
>>> But, if there's going to be a discussion about brace styles, I would vote
>>> for K&R's One True Brace Style. :-)
>> I agree that K&R is the way to go. But. Switching to Allman is just
>> removing
>> 2 spaces on lines where bracket is. Change is trivial and will not mess
>> with
>> the history.
>>
>> In theory going to K&R is simple too. Basically same check as with Allman,
>> but instead of removing 2 spaces you remove all spaces + previous new line
>> character. But this will impact history, as all if/for/while will have an
>> altered line where check is happening.
>>
>> tl;dr: K&R is more compact, but will mess with history. Allman will be just
>> as vertically wide as GNU, but will leave history intact where it matters.
>>
>> I am down to any change that removes that awful GNU indent :)
Re: [EXT] Re: [PROPOSAL] New nxstyle tool roadmap
Posted by raiden00pl <ra...@gmail.com>.
K&R is ugly and unreadable. It will also mess up git history a lot, so I'll
definitely vote against it.
Allman is much more acceptable, but style change is a significant change
for the project,
and there's been a lot of complaining here lately about "big changes".
śr., 19 mar 2025 o 02:03 Michał Łyszczek <mi...@bofc.pl>
napisał(a):
> Nathan Hartman:
> > But, if there's going to be a discussion about brace styles, I would vote
> > for K&R's One True Brace Style. :-)
>
> I agree that K&R is the way to go. But. Switching to Allman is just
> removing
> 2 spaces on lines where bracket is. Change is trivial and will not mess
> with
> the history.
>
> In theory going to K&R is simple too. Basically same check as with Allman,
> but instead of removing 2 spaces you remove all spaces + previous new line
> character. But this will impact history, as all if/for/while will have an
> altered line where check is happening.
>
> tl;dr: K&R is more compact, but will mess with history. Allman will be just
> as vertically wide as GNU, but will leave history intact where it matters.
>
> I am down to any change that removes that awful GNU indent :)
Re: [EXT] Re: [PROPOSAL] New nxstyle tool roadmap
Posted by Michał Łyszczek <mi...@bofc.pl>.
Nathan Hartman:
> But, if there's going to be a discussion about brace styles, I would vote
> for K&R's One True Brace Style. :-)
I agree that K&R is the way to go. But. Switching to Allman is just removing
2 spaces on lines where bracket is. Change is trivial and will not mess with
the history.
In theory going to K&R is simple too. Basically same check as with Allman,
but instead of removing 2 spaces you remove all spaces + previous new line
character. But this will impact history, as all if/for/while will have an
altered line where check is happening.
tl;dr: K&R is more compact, but will mess with history. Allman will be just
as vertically wide as GNU, but will leave history intact where it matters.
I am down to any change that removes that awful GNU indent :)
Re: [EXT] Re: [PROPOSAL] New nxstyle tool roadmap
Posted by Nathan Hartman <ha...@gmail.com>.
Hi all,
I think we shouldn't make drastic changes to the source style because that
will just create a lot of busywork and a lot of source changes that will
introduce needless headaches when comparing different revisions etc.
Instead, I think we should make only the minimal adjustments to the source
style that will allow use of widespread tools.
But, if there's going to be a discussion about brace styles, I would vote
for K&R's One True Brace Style. :-)
Cheers,
Nathan
On Tue, Mar 18, 2025 at 3:21 PM Alan C. Assis <ac...@gmail.com> wrote:
> Hi Michal,
>
> That makes sense, actually I think Altman is similar (but more elegant)
> GNU style:
>
> https://en.wikipedia.org/wiki/Indentation_style
>
> BR,
>
> Alan
>
> On Mon, Mar 17, 2025 at 7:32 PM Michał Łyszczek <mi...@bofc.pl>
> wrote:
>
> > Peter van der Perk:
> > > The main issue I was facing with clang-format was the indentation with
> > NuttX
> > > BreakBeforeBraces style see
> > > https://github.com/llvm/llvm-project/issues/44188
> >
> > Maybe it's time to say it out loud. GNU indent style for curly brackets
> > should die ;). Changing these to Allman style should be trivial without
> > the risk of breaking anything.
> >
> > This would enable use of well established project insead of maintaining
> > internal one.
>
Re: [EXT] Re: [PROPOSAL] New nxstyle tool roadmap
Posted by "Alan C. Assis" <ac...@gmail.com>.
Hi Michal,
That makes sense, actually I think Altman is similar (but more elegant) to
GNU style:
https://en.wikipedia.org/wiki/Indentation_style
BR,
Alan
On Mon, Mar 17, 2025 at 7:32 PM Michał Łyszczek <mi...@bofc.pl>
wrote:
> Peter van der Perk:
> > The main issue I was facing with clang-format was the indentation with
> NuttX
> > BreakBeforeBraces style see
> > https://github.com/llvm/llvm-project/issues/44188
>
> Maybe it's time to say it out loud. GNU indent style for curly brackets
> should die ;). Changing these to Allman style should be trivial without
> the risk of breaking anything.
>
> This would enable use of well established project insead of maintaining
> internal one.
Re: [EXT] Re: [PROPOSAL] New nxstyle tool roadmap
Posted by Michał Łyszczek <mi...@bofc.pl>.
Peter van der Perk:
> The main issue I was facing with clang-format was the indentation with NuttX
> BreakBeforeBraces style see
> https://github.com/llvm/llvm-project/issues/44188
Maybe it's time to say it out loud. GNU indent style for curly brackets
should die ;). Changing these to Allman style should be trivial without
the risk of breaking anything.
This would enable use of well established project insead of maintaining
internal one.
Re: [EXT] [PROPOSAL] New nxstyle tool roadmap
Posted by Luchian Mihai <lu...@gmail.com>.
Hello all,
I fully agree with you Mark, hence my question.
Though your point would only be true if we deprecate nxstyle. Maintenance
or adding new features is still work/time spent.
It's just that, at current time I'm willing to spend my time on a new
implementation. I would argue it's the better choice.
It is indeed a tool for styling, I won't argue, but it a part of what nuttx
"package". I do not see it as less important than OS or apps, maybe not as
high of priority, true.
For me it's just a matter of what nuttx wants to provide.
Regarding your statement Filipe, I think I may need to clarify the scope of
"my" nxstyle. Although I won't use the same codebase, I do not aim to
change what nxstyle is.
I just aim to rewrite it in python using a language parser, making it a
more capable linting tool. I aim to reuse the reported messages as much as
possible.
My last PR that touched nxstyle fixed an issue while introducing others due
to nxstyle not tokenizing the file provided.
As why python, arguably a better suited language for parsing text and
easier to integrate in (ephemeral) workflows, docker and such, among other
arguments I may have.
Cheers,
Mihai
On Mon, 17 Mar 2025 at 20:51, Filipe Cavalcanti
<fi...@espressif.com.invalid> wrote:
> Hi all,
>
> I'm a strong supporter of linting tools that can save us work during
> development. In fact, I added the pre-commit-config to NuttX so I can apply
> nxstyle at each commit in a "nicer" way (even though I'm sure most people
> are not aware of it).
>
> Honestly, if this was a new project, I would suggest we just choose a
> widely used software that would enforce the rules and that would be it.
>
> Now, in the current project status this can tricky. A different tool would
> have to accept most of our rules and those that are not available, would
> have to be implemented.
>
> On the other hand, nxstyle works fine but it does need some maintenance. I
> have seem some rules enforced on PR comments that nxstyle is not catching.
> Also, I believe it has issues running multiple files in a multi-threaded
> environment.
>
> With that said, I personally think keeping and improving nxstyle would be
> less of an effort than changing to a different tool.
>
> I would like to hear what others think about this.
>
> Filipe
>
> ________________________________
> From: Mark Stevens <ma...@wildernesslabs.co.INVALID>
> Sent: Monday, March 17, 2025 1:27 PM
> To: dev@nuttx.apache.org <de...@nuttx.apache.org>
> Subject: Re: [EXT] [PROPOSAL] New nxstyle tool roadmap
>
> [You don't often get email from mark.stevens@wildernesslabs.co.invalid.
> Learn why this is important at
> https://aka.ms/LearnAboutSenderIdentification ]
>
> [External: This email originated outside Espressif]
>
> A couple of things to bear in mind:
>
> - Perfection is the enemy of good
> - Would you rather maintain a tool for styling or work on Apps/OS code?
>
> I agree that as it stands, clang-format does not always allow enforcement
> of the exact style we would like but if it is nearly there is it worth
> looking at the style and possibly changing?
>
> Somethings could be enforced at PR time, the one that was mentioned is hex
> constants. So clang-format does not do that but it does not cause a
> failure either. So if 95% of the stuff is there, then is it good enough
> with manual intervention at PR/merge time?
>
> If we have a new tool then someone has to maintain it which is great if
> you have a group of people who are passionate about tools.
>
> Regards,
> Mark
> —
> Mark Stevens
> mark.stevens@wildernesslabs.co
>
>
>
>
>
>
> > On 17 Mar 2025, at 14:00, Peter van der Perk <pe...@nxp.com>
> wrote:
> >
> > The main issue I was facing with clang-format was the indentation with
> NuttX BreakBeforeBraces style see
> > https://github.com/llvm/llvm-project/issues/44188
> >
> > Regards,
> >
> > Peter
> >
> > -----Original Message-----
> > From: Nathan Hartman <hartman.nathan@gmail.com <mailto:
> hartman.nathan@gmail.com>>
> > Sent: Monday, March 17, 2025 2:39 PM
> > To: dev@nuttx.apache.org <ma...@nuttx.apache.org>
> > Subject: Re: [PROPOSAL] New nxstyle tool roadmap
> >
> > Regarding the missing features in clang format, have you considered
> opening feature requests for these with the clang devs?
> >
> > Regarding a nxtool with multiple subcommands for things, such as style
> checking, this is an interesting idea that should be explored.
> >
> > My only concern is with the addition of developer-side dependencies.
> > Whenever we add more required tools or languages on the developer's
> system, we potentially add friction that makes it harder for newcomer to
> adopt NuttX.
> >
> > It may not be avoidable, and in the long run, we're probably better off
> using existing well-maintained and well-adopted tools, which both Python
> and tree-sitter are, than to maintain custom tooling that tries to
> duplicate such functionality.
> >
> > Python is very likely to already be installed on developer machines, so
> is a good choice of scripting language. But we should still consider this
> > carefully:
> >
> > Python is a language that morphs all the time and is always growing new
> features and syntax (like C++; the language has become huge). You have to
> know the whole language, because different developers who contribute to the
> scripts will know and use different parts of the language. Also Python has
> been known to change in non-backward-compatible ways, so we'll forever need
> to chase these.
> >
> > NuttX is implemented in C, so all of the NuttX devs know C, and aren't
> necessarily Python experts. Should we consider adopting tree-sitter but
> implementing nxtool in C?
> >
> > Cheers,
> > Nathan
> >
> > On Mon, Mar 17, 2025 at 9:00 AM Matteo Golin <ma...@gmail.com>
> wrote:
> >
> >> Hello,
> >>
> >> I have tried to make a clang format configuration to use, but I have
> >> the same problem where there are a couple style items that clang
> >> format has no options for. Things like enforcing lowercase hex or
> >> putting curly braces indented on a separate line after static
> initializers.
> >>
> >> On Mon, Mar 17, 2025, 8:52 AM Mark Stevens <ma...@thepcsite.co.uk>
> wrote:
> >>
> >>> Has anyone looked at using a custom .clang-format file to see if we
> >>> can get close to the NuttX style?
> >>>
> >>> I’ve used this route in a couple of projects. I did have to
> >>> compromise
> >> on
> >>> one or two rules as I could not get the exact format I wanted. I
> >>> thought this was worth it as it saved me writing my own tool to do
> >>> the job. I
> >> then
> >>> used a docker script to run the checks on every PR.
> >>>
> >>> Just wondering if it would save some effort.
> >>>
> >>> Regards,
> >>> Mark
> >>> -------------------------------------------
> >>> Mark Stevens
> >>> Blog: blog.mark-stevens.co.uk
> >>>
> >>>
> >>>> On 17 Mar 2025, at 11:31, Luchian Mihai <lu...@gmail.com>
> >>> wrote:
> >>>>
> >>>> Hello Nuttx,
> >>>>
> >>>> *--- Summary ---*
> >>>> I've been in the habit of fixing small issues regarding nxstyle.
> >>>>
> >>>> One of the last conclusions drawn was that it does not tokenize
> >>>> the
> >> file,
> >>>> which leads to limitations in checking syntax.
> >>>> Please check
> >>>> https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2F
> >>>> github.com <http://github.com/>%2Fapache%2Fnuttx%2Fpull%2F15847&data=05%7C02%7Cpeter.va
> <http://7cpeter.va/>
> >>>> nderperk%40nxp.com <http://40nxp.com/
> >%7C523719ea66ff4c72fe8d08dd65591eda%7C686ea1d3bc
> >>>> 2b4c6fa92cd99c5c301635%7C0%7C0%7C638778155632496788%7CUnknown%7CTW
> >>>> FpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4z
> >>>> MiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=hULCYTu4Wc
> >>>> TAeojjtlaWZlKrEi0hdM7WBEWYVBGlWu0%3D&reserved=0 for further
> >>> details.
> >>>>
> >>>> I am working on a new implementation of nxstyle using python and
> >>>> tree-sitter for parsing and checking the source code.
> >>>> Treesitter is getting more traction in the past years. Some
> >>>> editors are making use of treesitter, such as zed, neovim, helix, and
> others.
> >>>> GitHub uses if for code navigation
> >>>>
> >>>
> >> https://docs/
> >> .github.com <http://github.com/
> >%2Fen%2Frepositories%2Fworking-with-files%2Fusing-files%2Fn
> >> avigating-code-on-github&data=05%7C02%7Cpeter.vanderperk%40nxp.com <
> http://40nxp.com/>%7C5
> >> 23719ea66ff4c72fe8d08dd65591eda%7C686ea1d3bc2b4c6fa92cd99c5c301635%7C0
> >> %7C0%7C638778155632522235%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRy
> >> dWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%
> >> 3D%7C0%7C%7C%7C&sdata=pqiaN5mq4Vkfftwe8G2F1PsmxFXDw08XkVsAx%2BjkjqI%3D
> >> &reserved=0
> >>>> So, I think it may be a suitable solution for nuttx as well.
> >>>>
> >>>> This will take a lot of work, but you can track my progress at
> >>>> https://github.com/LuchianMihai/nuttx/tree/nxtool.
> >>>> Please feel free to add any suggestions you may see fit.
> >>>>
> >>>> *--- Questions ---*
> >>>>
> >>>> 1.
> >>>> I've also set up the work for an new tool, calling it nxtool (at
> >>>> the
> >>> time I
> >>>> did not know that is not a new name/concept), Mostly, it's a
> >>>> "boilerplate" to add more subcommands under a common
> >>> command
> >>>> called nxtool.
> >>>> Currently only a single subcommand is present, checkpatch,
> >>>> equivalent
> >> to
> >>>> the present checkpatch.sh so basically call *nxtool checkpatch
> >>>> file* Now I've dug the mailing archive and found that nxtool, or
> >>>> similar
> >>> projects
> >>>> were proposed in the past, such as
> >>>> https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2F
> >>>> gitlab.com <http://gitlab.com/
> >%2Fnuttx-upm%2Fupm&data=05%7C02%7Cpeter.vanderperk%40nxp
> >>>> .com%7C523719ea66ff4c72fe8d08dd65591eda%7C686ea1d3bc2b4c6fa92cd99c
> >>>> 5c301635%7C0%7C0%7C638778155632554445%7CUnknown%7CTWFpbGZsb3d8eyJF
> >>>> bXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTW
> >>>> FpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=CPkRSYKGw1uEmABoXKTyelEO
> >>>> axSV%2BAhdAIRe%2Fq7rhFE%3D&reserved=0 or
> >>>> https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2F
> >>>> gitlab.com <http://gitlab.com/
> >%2Fnuttx_projects%2Fnuttx_workspace_manager&data=05%7C02
> >>>> %7Cpeter.vanderperk%40nxp.com <http://40nxp.com/
> >%7C523719ea66ff4c72fe8d08dd65591eda%7
> >>>> C686ea1d3bc2b4c6fa92cd99c5c301635%7C0%7C0%7C638778155632569907%7CU
> >>>> nknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsI
> >>>> lAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata
> >>>> =HTL0lm3o1zZrGCjDRAWUGimzePcoD4ivySqmpOoK22c%3D&reserved=0
> >>>> But both of them seem abandoned or not actively worked on.
> >>>> I feel like I'm missing some info regarding the work I'm doing.
> >>>> Why did the work stop, what was the issue with them?
> >>>> I saw mentions of zephyr meta-tool west, and they weren't bad, or
> >> against
> >>>> tools alike.
> >>>>
> >>>> So my question basically is, what is the take of the nuttx
> >>>> community
> >>> python
> >>>> based meta-tool?
> >>>>
> >>>> 2.
> >>>> Although I've already started investing time in this, I'm not sure
> >>>> how
> >>> much
> >>>> effort the nuttx community is willing to invest for enforcing this
> >>>> custom coding style in favor of using clang-format and gnu style.
> >>>> If I'm to add a new tool for enforcing nuttx coding style, I'd
> >>>> like to
> >>> know
> >>>> that there is no talk about deprecating this work.
> >>>>
> >>>> *--- Cosing words ---*
> >>>>
> >>>> As mentioned previously, please reply with any proposals, ideas,
> >> thoughts
> >>>> you have for such a tool, if any,
> >>>> or any counter arguments you may have.
>
>
Re: [EXT] [PROPOSAL] New nxstyle tool roadmap
Posted by Filipe Cavalcanti <fi...@espressif.com.INVALID>.
Hi all,
I'm a strong supporter of linting tools that can save us work during development. In fact, I added the pre-commit-config to NuttX so I can apply nxstyle at each commit in a "nicer" way (even though I'm sure most people are not aware of it).
Honestly, if this was a new project, I would suggest we just choose a widely used software that would enforce the rules and that would be it.
Now, in the current project status this can tricky. A different tool would have to accept most of our rules and those that are not available, would have to be implemented.
On the other hand, nxstyle works fine but it does need some maintenance. I have seem some rules enforced on PR comments that nxstyle is not catching. Also, I believe it has issues running multiple files in a multi-threaded environment.
With that said, I personally think keeping and improving nxstyle would be less of an effort than changing to a different tool.
I would like to hear what others think about this.
Filipe
________________________________
From: Mark Stevens <ma...@wildernesslabs.co.INVALID>
Sent: Monday, March 17, 2025 1:27 PM
To: dev@nuttx.apache.org <de...@nuttx.apache.org>
Subject: Re: [EXT] [PROPOSAL] New nxstyle tool roadmap
[You don't often get email from mark.stevens@wildernesslabs.co.invalid. Learn why this is important at https://aka.ms/LearnAboutSenderIdentification ]
[External: This email originated outside Espressif]
A couple of things to bear in mind:
- Perfection is the enemy of good
- Would you rather maintain a tool for styling or work on Apps/OS code?
I agree that as it stands, clang-format does not always allow enforcement of the exact style we would like but if it is nearly there is it worth looking at the style and possibly changing?
Somethings could be enforced at PR time, the one that was mentioned is hex constants. So clang-format does not do that but it does not cause a failure either. So if 95% of the stuff is there, then is it good enough with manual intervention at PR/merge time?
If we have a new tool then someone has to maintain it which is great if you have a group of people who are passionate about tools.
Regards,
Mark
—
Mark Stevens
mark.stevens@wildernesslabs.co
> On 17 Mar 2025, at 14:00, Peter van der Perk <pe...@nxp.com> wrote:
>
> The main issue I was facing with clang-format was the indentation with NuttX BreakBeforeBraces style see
> https://github.com/llvm/llvm-project/issues/44188
>
> Regards,
>
> Peter
>
> -----Original Message-----
> From: Nathan Hartman <hartman.nathan@gmail.com <ma...@gmail.com>>
> Sent: Monday, March 17, 2025 2:39 PM
> To: dev@nuttx.apache.org <ma...@nuttx.apache.org>
> Subject: Re: [PROPOSAL] New nxstyle tool roadmap
>
> Regarding the missing features in clang format, have you considered opening feature requests for these with the clang devs?
>
> Regarding a nxtool with multiple subcommands for things, such as style checking, this is an interesting idea that should be explored.
>
> My only concern is with the addition of developer-side dependencies.
> Whenever we add more required tools or languages on the developer's system, we potentially add friction that makes it harder for newcomer to adopt NuttX.
>
> It may not be avoidable, and in the long run, we're probably better off using existing well-maintained and well-adopted tools, which both Python and tree-sitter are, than to maintain custom tooling that tries to duplicate such functionality.
>
> Python is very likely to already be installed on developer machines, so is a good choice of scripting language. But we should still consider this
> carefully:
>
> Python is a language that morphs all the time and is always growing new features and syntax (like C++; the language has become huge). You have to know the whole language, because different developers who contribute to the scripts will know and use different parts of the language. Also Python has been known to change in non-backward-compatible ways, so we'll forever need to chase these.
>
> NuttX is implemented in C, so all of the NuttX devs know C, and aren't necessarily Python experts. Should we consider adopting tree-sitter but implementing nxtool in C?
>
> Cheers,
> Nathan
>
> On Mon, Mar 17, 2025 at 9:00 AM Matteo Golin <ma...@gmail.com> wrote:
>
>> Hello,
>>
>> I have tried to make a clang format configuration to use, but I have
>> the same problem where there are a couple style items that clang
>> format has no options for. Things like enforcing lowercase hex or
>> putting curly braces indented on a separate line after static initializers.
>>
>> On Mon, Mar 17, 2025, 8:52 AM Mark Stevens <ma...@thepcsite.co.uk> wrote:
>>
>>> Has anyone looked at using a custom .clang-format file to see if we
>>> can get close to the NuttX style?
>>>
>>> I’ve used this route in a couple of projects. I did have to
>>> compromise
>> on
>>> one or two rules as I could not get the exact format I wanted. I
>>> thought this was worth it as it saved me writing my own tool to do
>>> the job. I
>> then
>>> used a docker script to run the checks on every PR.
>>>
>>> Just wondering if it would save some effort.
>>>
>>> Regards,
>>> Mark
>>> -------------------------------------------
>>> Mark Stevens
>>> Blog: blog.mark-stevens.co.uk
>>>
>>>
>>>> On 17 Mar 2025, at 11:31, Luchian Mihai <lu...@gmail.com>
>>> wrote:
>>>>
>>>> Hello Nuttx,
>>>>
>>>> *--- Summary ---*
>>>> I've been in the habit of fixing small issues regarding nxstyle.
>>>>
>>>> One of the last conclusions drawn was that it does not tokenize
>>>> the
>> file,
>>>> which leads to limitations in checking syntax.
>>>> Please check
>>>> https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2F
>>>> github.com <http://github.com/>%2Fapache%2Fnuttx%2Fpull%2F15847&data=05%7C02%7Cpeter.va <http://7cpeter.va/>
>>>> nderperk%40nxp.com <http://40nxp.com/>%7C523719ea66ff4c72fe8d08dd65591eda%7C686ea1d3bc
>>>> 2b4c6fa92cd99c5c301635%7C0%7C0%7C638778155632496788%7CUnknown%7CTW
>>>> FpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4z
>>>> MiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=hULCYTu4Wc
>>>> TAeojjtlaWZlKrEi0hdM7WBEWYVBGlWu0%3D&reserved=0 for further
>>> details.
>>>>
>>>> I am working on a new implementation of nxstyle using python and
>>>> tree-sitter for parsing and checking the source code.
>>>> Treesitter is getting more traction in the past years. Some
>>>> editors are making use of treesitter, such as zed, neovim, helix, and others.
>>>> GitHub uses if for code navigation
>>>>
>>>
>> https://docs/
>> .github.com <http://github.com/>%2Fen%2Frepositories%2Fworking-with-files%2Fusing-files%2Fn
>> avigating-code-on-github&data=05%7C02%7Cpeter.vanderperk%40nxp.com <http://40nxp.com/>%7C5
>> 23719ea66ff4c72fe8d08dd65591eda%7C686ea1d3bc2b4c6fa92cd99c5c301635%7C0
>> %7C0%7C638778155632522235%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRy
>> dWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%
>> 3D%7C0%7C%7C%7C&sdata=pqiaN5mq4Vkfftwe8G2F1PsmxFXDw08XkVsAx%2BjkjqI%3D
>> &reserved=0
>>>> So, I think it may be a suitable solution for nuttx as well.
>>>>
>>>> This will take a lot of work, but you can track my progress at
>>>> https://github.com/LuchianMihai/nuttx/tree/nxtool.
>>>> Please feel free to add any suggestions you may see fit.
>>>>
>>>> *--- Questions ---*
>>>>
>>>> 1.
>>>> I've also set up the work for an new tool, calling it nxtool (at
>>>> the
>>> time I
>>>> did not know that is not a new name/concept), Mostly, it's a
>>>> "boilerplate" to add more subcommands under a common
>>> command
>>>> called nxtool.
>>>> Currently only a single subcommand is present, checkpatch,
>>>> equivalent
>> to
>>>> the present checkpatch.sh so basically call *nxtool checkpatch
>>>> file* Now I've dug the mailing archive and found that nxtool, or
>>>> similar
>>> projects
>>>> were proposed in the past, such as
>>>> https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2F
>>>> gitlab.com <http://gitlab.com/>%2Fnuttx-upm%2Fupm&data=05%7C02%7Cpeter.vanderperk%40nxp
>>>> .com%7C523719ea66ff4c72fe8d08dd65591eda%7C686ea1d3bc2b4c6fa92cd99c
>>>> 5c301635%7C0%7C0%7C638778155632554445%7CUnknown%7CTWFpbGZsb3d8eyJF
>>>> bXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTW
>>>> FpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=CPkRSYKGw1uEmABoXKTyelEO
>>>> axSV%2BAhdAIRe%2Fq7rhFE%3D&reserved=0 or
>>>> https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2F
>>>> gitlab.com <http://gitlab.com/>%2Fnuttx_projects%2Fnuttx_workspace_manager&data=05%7C02
>>>> %7Cpeter.vanderperk%40nxp.com <http://40nxp.com/>%7C523719ea66ff4c72fe8d08dd65591eda%7
>>>> C686ea1d3bc2b4c6fa92cd99c5c301635%7C0%7C0%7C638778155632569907%7CU
>>>> nknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsI
>>>> lAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata
>>>> =HTL0lm3o1zZrGCjDRAWUGimzePcoD4ivySqmpOoK22c%3D&reserved=0
>>>> But both of them seem abandoned or not actively worked on.
>>>> I feel like I'm missing some info regarding the work I'm doing.
>>>> Why did the work stop, what was the issue with them?
>>>> I saw mentions of zephyr meta-tool west, and they weren't bad, or
>> against
>>>> tools alike.
>>>>
>>>> So my question basically is, what is the take of the nuttx
>>>> community
>>> python
>>>> based meta-tool?
>>>>
>>>> 2.
>>>> Although I've already started investing time in this, I'm not sure
>>>> how
>>> much
>>>> effort the nuttx community is willing to invest for enforcing this
>>>> custom coding style in favor of using clang-format and gnu style.
>>>> If I'm to add a new tool for enforcing nuttx coding style, I'd
>>>> like to
>>> know
>>>> that there is no talk about deprecating this work.
>>>>
>>>> *--- Cosing words ---*
>>>>
>>>> As mentioned previously, please reply with any proposals, ideas,
>> thoughts
>>>> you have for such a tool, if any,
>>>> or any counter arguments you may have.
Re: [EXT] [PROPOSAL] New nxstyle tool roadmap
Posted by Mark Stevens <ma...@wildernesslabs.co.INVALID>.
A couple of things to bear in mind:
- Perfection is the enemy of good
- Would you rather maintain a tool for styling or work on Apps/OS code?
I agree that as it stands, clang-format does not always allow enforcement of the exact style we would like but if it is nearly there is it worth looking at the style and possibly changing?
Somethings could be enforced at PR time, the one that was mentioned is hex constants. So clang-format does not do that but it does not cause a failure either. So if 95% of the stuff is there, then is it good enough with manual intervention at PR/merge time?
If we have a new tool then someone has to maintain it which is great if you have a group of people who are passionate about tools.
Regards,
Mark
—
Mark Stevens
mark.stevens@wildernesslabs.co
> On 17 Mar 2025, at 14:00, Peter van der Perk <pe...@nxp.com> wrote:
>
> The main issue I was facing with clang-format was the indentation with NuttX BreakBeforeBraces style see
> https://github.com/llvm/llvm-project/issues/44188
>
> Regards,
>
> Peter
>
> -----Original Message-----
> From: Nathan Hartman <hartman.nathan@gmail.com <ma...@gmail.com>>
> Sent: Monday, March 17, 2025 2:39 PM
> To: dev@nuttx.apache.org <ma...@nuttx.apache.org>
> Subject: Re: [PROPOSAL] New nxstyle tool roadmap
>
> Regarding the missing features in clang format, have you considered opening feature requests for these with the clang devs?
>
> Regarding a nxtool with multiple subcommands for things, such as style checking, this is an interesting idea that should be explored.
>
> My only concern is with the addition of developer-side dependencies.
> Whenever we add more required tools or languages on the developer's system, we potentially add friction that makes it harder for newcomer to adopt NuttX.
>
> It may not be avoidable, and in the long run, we're probably better off using existing well-maintained and well-adopted tools, which both Python and tree-sitter are, than to maintain custom tooling that tries to duplicate such functionality.
>
> Python is very likely to already be installed on developer machines, so is a good choice of scripting language. But we should still consider this
> carefully:
>
> Python is a language that morphs all the time and is always growing new features and syntax (like C++; the language has become huge). You have to know the whole language, because different developers who contribute to the scripts will know and use different parts of the language. Also Python has been known to change in non-backward-compatible ways, so we'll forever need to chase these.
>
> NuttX is implemented in C, so all of the NuttX devs know C, and aren't necessarily Python experts. Should we consider adopting tree-sitter but implementing nxtool in C?
>
> Cheers,
> Nathan
>
> On Mon, Mar 17, 2025 at 9:00 AM Matteo Golin <ma...@gmail.com> wrote:
>
>> Hello,
>>
>> I have tried to make a clang format configuration to use, but I have
>> the same problem where there are a couple style items that clang
>> format has no options for. Things like enforcing lowercase hex or
>> putting curly braces indented on a separate line after static initializers.
>>
>> On Mon, Mar 17, 2025, 8:52 AM Mark Stevens <ma...@thepcsite.co.uk> wrote:
>>
>>> Has anyone looked at using a custom .clang-format file to see if we
>>> can get close to the NuttX style?
>>>
>>> I’ve used this route in a couple of projects. I did have to
>>> compromise
>> on
>>> one or two rules as I could not get the exact format I wanted. I
>>> thought this was worth it as it saved me writing my own tool to do
>>> the job. I
>> then
>>> used a docker script to run the checks on every PR.
>>>
>>> Just wondering if it would save some effort.
>>>
>>> Regards,
>>> Mark
>>> -------------------------------------------
>>> Mark Stevens
>>> Blog: blog.mark-stevens.co.uk
>>>
>>>
>>>> On 17 Mar 2025, at 11:31, Luchian Mihai <lu...@gmail.com>
>>> wrote:
>>>>
>>>> Hello Nuttx,
>>>>
>>>> *--- Summary ---*
>>>> I've been in the habit of fixing small issues regarding nxstyle.
>>>>
>>>> One of the last conclusions drawn was that it does not tokenize
>>>> the
>> file,
>>>> which leads to limitations in checking syntax.
>>>> Please check
>>>> https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2F
>>>> github.com <http://github.com/>%2Fapache%2Fnuttx%2Fpull%2F15847&data=05%7C02%7Cpeter.va <http://7cpeter.va/>
>>>> nderperk%40nxp.com <http://40nxp.com/>%7C523719ea66ff4c72fe8d08dd65591eda%7C686ea1d3bc
>>>> 2b4c6fa92cd99c5c301635%7C0%7C0%7C638778155632496788%7CUnknown%7CTW
>>>> FpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4z
>>>> MiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=hULCYTu4Wc
>>>> TAeojjtlaWZlKrEi0hdM7WBEWYVBGlWu0%3D&reserved=0 for further
>>> details.
>>>>
>>>> I am working on a new implementation of nxstyle using python and
>>>> tree-sitter for parsing and checking the source code.
>>>> Treesitter is getting more traction in the past years. Some
>>>> editors are making use of treesitter, such as zed, neovim, helix, and others.
>>>> GitHub uses if for code navigation
>>>>
>>>
>> https://docs/
>> .github.com <http://github.com/>%2Fen%2Frepositories%2Fworking-with-files%2Fusing-files%2Fn
>> avigating-code-on-github&data=05%7C02%7Cpeter.vanderperk%40nxp.com <http://40nxp.com/>%7C5
>> 23719ea66ff4c72fe8d08dd65591eda%7C686ea1d3bc2b4c6fa92cd99c5c301635%7C0
>> %7C0%7C638778155632522235%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRy
>> dWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%
>> 3D%7C0%7C%7C%7C&sdata=pqiaN5mq4Vkfftwe8G2F1PsmxFXDw08XkVsAx%2BjkjqI%3D
>> &reserved=0
>>>> So, I think it may be a suitable solution for nuttx as well.
>>>>
>>>> This will take a lot of work, but you can track my progress at
>>>> https://github.com/LuchianMihai/nuttx/tree/nxtool.
>>>> Please feel free to add any suggestions you may see fit.
>>>>
>>>> *--- Questions ---*
>>>>
>>>> 1.
>>>> I've also set up the work for an new tool, calling it nxtool (at
>>>> the
>>> time I
>>>> did not know that is not a new name/concept), Mostly, it's a
>>>> "boilerplate" to add more subcommands under a common
>>> command
>>>> called nxtool.
>>>> Currently only a single subcommand is present, checkpatch,
>>>> equivalent
>> to
>>>> the present checkpatch.sh so basically call *nxtool checkpatch
>>>> file* Now I've dug the mailing archive and found that nxtool, or
>>>> similar
>>> projects
>>>> were proposed in the past, such as
>>>> https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2F
>>>> gitlab.com <http://gitlab.com/>%2Fnuttx-upm%2Fupm&data=05%7C02%7Cpeter.vanderperk%40nxp
>>>> .com%7C523719ea66ff4c72fe8d08dd65591eda%7C686ea1d3bc2b4c6fa92cd99c
>>>> 5c301635%7C0%7C0%7C638778155632554445%7CUnknown%7CTWFpbGZsb3d8eyJF
>>>> bXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTW
>>>> FpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=CPkRSYKGw1uEmABoXKTyelEO
>>>> axSV%2BAhdAIRe%2Fq7rhFE%3D&reserved=0 or
>>>> https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2F
>>>> gitlab.com <http://gitlab.com/>%2Fnuttx_projects%2Fnuttx_workspace_manager&data=05%7C02
>>>> %7Cpeter.vanderperk%40nxp.com <http://40nxp.com/>%7C523719ea66ff4c72fe8d08dd65591eda%7
>>>> C686ea1d3bc2b4c6fa92cd99c5c301635%7C0%7C0%7C638778155632569907%7CU
>>>> nknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsI
>>>> lAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata
>>>> =HTL0lm3o1zZrGCjDRAWUGimzePcoD4ivySqmpOoK22c%3D&reserved=0
>>>> But both of them seem abandoned or not actively worked on.
>>>> I feel like I'm missing some info regarding the work I'm doing.
>>>> Why did the work stop, what was the issue with them?
>>>> I saw mentions of zephyr meta-tool west, and they weren't bad, or
>> against
>>>> tools alike.
>>>>
>>>> So my question basically is, what is the take of the nuttx
>>>> community
>>> python
>>>> based meta-tool?
>>>>
>>>> 2.
>>>> Although I've already started investing time in this, I'm not sure
>>>> how
>>> much
>>>> effort the nuttx community is willing to invest for enforcing this
>>>> custom coding style in favor of using clang-format and gnu style.
>>>> If I'm to add a new tool for enforcing nuttx coding style, I'd
>>>> like to
>>> know
>>>> that there is no talk about deprecating this work.
>>>>
>>>> *--- Cosing words ---*
>>>>
>>>> As mentioned previously, please reply with any proposals, ideas,
>> thoughts
>>>> you have for such a tool, if any,
>>>> or any counter arguments you may have.