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

2025-03-19 Thread Luchian Mihai
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 thi

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

2025-03-19 Thread Luchian Mihai
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

Re: Re: [PROPOSAL] New nxstyle tool roadmap

2025-03-19 Thread Luchian Mihai
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:1

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

2025-03-19 Thread Luchian Mihai
Then it's settled, Thanks, Mihai On Wed, 19 Mar 2025 at 15:33, Sebastien Lorquet 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

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

2025-03-19 Thread Luchian Mihai
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

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

2025-03-18 Thread Luchian Mihai
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ł Łysz

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

2025-03-17 Thread Luchian Mihai
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

Re: [PROPOSAL] New nxstyle tool roadmap

2025-03-17 Thread Luchian Mihai
> > > used a docker script to run the checks on every PR. > > > > > > Just wondering if it would save some effort. > > > > > > Regards, > > > Mark > > > --- > > > Mark Stevens > >

[PROPOSAL] New nxstyle tool roadmap

2025-03-17 Thread 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

Re: [DRUNX] Distributed Runtime and bUild for NuttX

2025-02-04 Thread Luchian Mihai
Hi! First thing, I'm fairly new to nuttx so I might be off subject but here is my hot take on this subject. NuttX is offering support for a lot of boards, more than what DRUNX should require. Eg. stm32f3 family, offering support for all the boards would benefit the boards more than the NuttX code