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 <filipe.cavalca...@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 <mark.stev...@wildernesslabs.co.INVALID> > Sent: Monday, March 17, 2025 1:27 PM > To: dev@nuttx.apache.org <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 <peter.vanderp...@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.nat...@gmail.com <mailto: > hartman.nat...@gmail.com>> > > Sent: Monday, March 17, 2025 2:39 PM > > To: dev@nuttx.apache.org <mailto: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 <matteo.go...@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 <m...@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 <luchiann.mi...@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. > >
