Re: [PROPOSAL] New nxstyle tool roadmap

[Nathan Hartman]

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  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  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 
> > 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://github.com/apache/nuttx/pull/15847 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/en/repositories/working-with-files/using-files/navigating-code-on-github
> > > 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://gitlab.com/nuttx-upm/upm or
> > > https://gitlab.com/nuttx_projects/nuttx_workspace_manager
> > > 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
> > 

RP2040 multiple GPIO interrupts

[Matteo Golin]

Hello everyone,

I have an application wherein I am using a W5500-EVB Pico as the MCU for a 
network controlled system. I need to connect
several switch inputs into this MCU. The switches are normally held high via 
the RP2040's internal pullups, and pulled
low when flipped.

The problem I'm encountering is that it appears that the current RP2040 support 
only allows for one type of interrupt
per pin: either rising edge or falling edge. I need to trigger on both rising 
and falling edge to accurately track the
state of the switch. I'm wondering if anyone else has had a similar issue or 
has suggestions about how I can resolve
this.

Thanks,

-- 
Matteo Golin


signature.asc
Description: PGP signature

Re: RP2040 multiple GPIO interrupts

[William Martin]

Do you have enough gpio's available to dedicate two pins per switch? If 
so, just tie them in pairs, program one of the pair to interrupt high, 
the other low.


On 3/17/25 14:18, Matteo Golin wrote:

Hello everyone,

I have an application wherein I am using a W5500-EVB Pico as the MCU for a 
network controlled system. I need to connect
several switch inputs into this MCU. The switches are normally held high via 
the RP2040's internal pullups, and pulled
low when flipped.

The problem I'm encountering is that it appears that the current RP2040 support 
only allows for one type of interrupt
per pin: either rising edge or falling edge. I need to trigger on both rising 
and falling edge to accurately track the
state of the switch. I'm wondering if anyone else has had a similar issue or 
has suggestions about how I can resolve
this.

Thanks,

Re: [PROPOSAL] New nxstyle tool roadmap

[Mark Stevens]

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  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://github.com/apache/nuttx/pull/15847 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/en/repositories/working-with-files/using-files/navigating-code-on-github
> 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://gitlab.com/nuttx-upm/upm or
> https://gitlab.com/nuttx_projects/nuttx_workspace_manager
> 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.

[PROPOSAL] New nxstyle tool roadmap

[Luchian Mihai]

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://github.com/apache/nuttx/pull/15847 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/en/repositories/working-with-files/using-files/navigating-code-on-github
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://gitlab.com/nuttx-upm/upm or
https://gitlab.com/nuttx_projects/nuttx_workspace_manager
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: [PROPOSAL] New nxstyle tool roadmap

[Matteo Golin]

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  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 
> 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://github.com/apache/nuttx/pull/15847 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/en/repositories/working-with-files/using-files/navigating-code-on-github
> > 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://gitlab.com/nuttx-upm/upm or
> > https://gitlab.com/nuttx_projects/nuttx_workspace_manager
> > 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: [PROPOSAL] New nxstyle tool roadmap

[Luchian Mihai]

Hi,

I do agree with clang format part, if we are to alter existing style it
will mean to maintain it ourselves, on some codebase that is not nuttx, I
would avoid that.

About the other part, I do not fully agree.
If we take 2019 - 2025 period, Nuttx has changed more than Python. I'm a
new contributor and anything prior to 2020 is arcane history.
Infrastructure and tooling will always evolve, at a fast pace
unfortunately, 5 years down the line I would not bet that github will be
the default hosting platform, taking into account the concurrence such as
gitlab, codeberg, gitea, forgero.
I would keep tooling flexible, easy to change, so maybe python is not the
main focus when we talk about change.

About the python part, I'm not a bit fan of (although I'm mostly writing
python lately), it's obnoxious, most python codebases are hard to maintain,
or poorly written, and venv are not a solution for everything, but I think
it's one of the best languages for tooling, beginner friendly, lots of code
already written (we can take examples).
If it comes to not choosing python, I'll choose golang or rust, I fear c
with strings of pointers :).

But I'm not the one to argue,
I'll go with the majority.

Cheers,
Mihai

On Mon, 17 Mar 2025 at 15:39, Nathan Hartman 
wrote:

> 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 
> 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  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 
> > > 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://github.com/apache/nuttx/pull/15847 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/en/repositories/working-with-files/using-files/navigating-code-on-github
> > > > 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

Re: [EXT] [PROPOSAL] New nxstyle tool roadmap

[Mark Stevens]

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.stev...@wildernesslabs.co






> On 17 Mar 2025, at 14:00, Peter van der Perk  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  >
> 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  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  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 
>>> 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
 e

RE: [EXT] Re: [PROPOSAL] New nxstyle tool roadmap

[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

Regards,

Peter

-Original Message-
From: Nathan Hartman 
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  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  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 
> > 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

Re: [EXT] [PROPOSAL] New nxstyle tool roadmap

[Filipe Cavalcanti]

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 
Sent: Monday, March 17, 2025 1:27 PM
To: dev@nuttx.apache.org 
Subject: Re: [EXT] [PROPOSAL] New nxstyle tool roadmap

[You don't often get email from mark.stev...@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.stev...@wildernesslabs.co






> On 17 Mar 2025, at 14:00, Peter van der Perk  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  >
> 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  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  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

Re: [EXT] [PROPOSAL] New nxstyle tool roadmap

[Luchian Mihai]

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
 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 
> Sent: Monday, March 17, 2025 1:27 PM
> To: dev@nuttx.apache.org 
> Subject: Re: [EXT] [PROPOSAL] New nxstyle tool roadmap
>
> [You don't often get email from mark.stev...@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.stev...@wildernesslabs.co
>
>
>
>
>
>
> > On 17 Mar 2025, at 14:00, Peter van der Perk 
> 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.nat...@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