Re: SPI controllers with 32bit transfer mode

[Xiang Xiao]

Yes, it's better to open PR in github, then all people come from
community can give the feedback interactively. it is especially
important for the change like this one which may impact many user.

On Sun, Mar 8, 2020 at 11:02 AM Gregory Nutt  wrote:
>
> Hi, Petro,
>
> > I'm currently working on adding SPI driver for AM335X. The MCSPI
> > controller of AM335X supports the transfer of up to 32-bits long SPI
> > words. Currently, SPI driver in Nuttx supports up to 16-bits long
> > words transfer. The attached patch extends it to 32-bit long words.
>
> I am not comfortable about reviewing and incorporating such an extensive
> change without benefit of help with the review.  Can you possibly submit
> this as a PR to the Github apached/incubator_nuttx repository.  I think
> that would work out better.
>
> Greg
>
>

Re: Should we relax precheck a little bit?

[Justin Mclean]

Hi,

> Yes, this is the key point why I am asking this question: we need
> stable the mainline and make the first apache release. 

Apache doesn’t actually care if your release works or not [*], it not an ASF  
requirement that a build must pass all tests. What matters is that the next 
build is better than the last one. We would prefer that project make frequent 
releases, gradually improving things, and not put off a release trying to make 
it perfect. One path leads to community growth, the other to community decline, 
I’ll let you guess which is which.

Thanks,
Justin

[*] The project and it’s user might care more about this :-)

Re: NuttX github action pull request check build CI enabled

[Xiang Xiao]

On Sun, Mar 8, 2020 at 5:51 AM Gregory Nutt  wrote:
>
> I maintain only the Bitbucket tool repository.
>

Greg, can we migrate the bitucket tool to https://github.com/nuttx?
The benefit is that:
1.The end user can get all stuff from a single website
2.All contributor can use the same workflow for both code and tool change
3.All committer has the permission to merge the tool change after the
review finish

> On 3/7/2020 4:44 PM, Abdelatif Guettouche wrote:
> > Haitao, thank you for your hard work , and thanks to everyone who
> > helped push this forward.
> >
> > I noticed one small thing. The cibuild.sh script uses the tools
> > repository from Github, I believe the one in Bitbucket is more recent.
> > I don't know which one we should continue to support and update, but I
> > wanted to raise the issue.
> >
> >> But we haven't enabled the following archs build since lack of toolchains
> >> or because of build breaks.
> > For the xtensa/esp32 the toolchain is available as described in the README 
> > file.
> > https://github.com/apache/incubator-nuttx/blob/master/boards/xtensa/esp32/esp32-core/README.txt#L82
> > There are only 3 configurations for this arch and all build with no issues.
> >
> >
> > On Sat, Mar 7, 2020 at 2:57 PM Haitao Liu  wrote:
> >> With efforts and reviews from community, the nuttx and apps github action
> >> pull request check build CI now take effect.
> >>
> >> To summarize, Github action CI workflow steps as below:
> >>
> >> a. Pull docker container with build essential tools preinstalled
> >>
> >> b. Clone nuttx, apps and testing repos
> >>
> >> c. Do check job: nxstyle check pull request with checkpatch.sh
> >>
> >> d. Do matrix jobs builds: use testing cibuild.sh to do builds
> >>
> >> As to github action detailed review and dicussions, refer to:
> >>
> >> https://github.com/apache/incubator-nuttx/pull/261
> >>
> >> https://github.com/apache/incubator-nuttx-apps/pull/113
> >>
> >> But there is still some improvement need from community:
> >>
> >> 1. Build the remaining configs (total 78) and suppport for Windows(native,
> >> cygwin, msys) and macOS build enviroment
> >>
> >> As @davids5 asked, what % of board configs are being built (n of N)?
> >>
> >> As for now, the check build covers the following archs board configs:
> >> arm/sim/mips/risc-v/x86
> >>
> >> arm 455/478
> >>
> >> sim 30/34
> >>
> >> mips 11/11
> >>
> >> risc-v 7/9
> >>
> >> x86 2/2
> >>
> >> But we haven't enabled the following archs build since lack of toolchains
> >> or because of build breaks.
> >>
> >> If available, we could update the docker container to preinstall their
> >> toolchains and update testlist
> >>
> >> (https://github.com/apache/incubator-nuttx-testing/tree/master/testlist) in
> >> testing repo to build them.
> >>
> >> avr 0/11
> >>
> >> hc 0/2
> >>
> >> misoc 0/2
> >>
> >> or1k 0/1
> >>
> >> renesas 0/10
> >>
> >> x86_64 0/1 // link issue need resolved
> >>
> >> xtensa 0/3
> >>
> >> z16 0/2
> >>
> >> z80 0/17
> >>
> >> For github action free version, there are 20 jobs upper limit. And now we
> >> used 17 jobs (each job runs about 30 configs in an 2-cores cpu
> >> VM/container) here under Ubuntu build enviroment.
> >>
> >> So we reserve 3 jobs interntionally for Windows and MacOS builds in future
> >> to add support.
> >>
> >> 2. Refine the github action workflow:
> >>
> >> As @btashton and @xiaoxiang suggests, reduce size of docker images to save
> >> time and adding build artifacts to run the testsuite
> >>
> >> or some validation automatically.
> >>
> >>
> >> So If you are interested in them, feel free to make PR to improve any of
> >> them. Let's make the nuttx CI more productive.
>
>

Re: Should we relax precheck a little bit?

[Xiang Xiao]

On Sun, Mar 8, 2020 at 4:52 PM Justin Mclean
 wrote:
>
> Hi,
>
> > Yes, this is the key point why I am asking this question: we need
> > stable the mainline and make the first apache release.
>
> Apache doesn’t actually care if your release works or not [*], it not an ASF  
> requirement that a build must pass all tests. What matters is that the next 
> build is better than the last one. We would prefer that project make frequent 
> releases, gradually improving things, and not put off a release trying to 
> make it perfect. One path leads to community growth, the other to community 
> decline, I’ll let you guess which is which.

But how we measure the release become better and better?
1.All config/host build without error
2.The testsuit has the growing pass rate
Both are the reasonable indicator that the project is on the right
direction, is it right?


>
> Thanks,
> Justin
>
> [*] The project and it’s user might care more about this :-)

Re: Should we relax precheck a little bit?

[David Sidrane]

Xiang,

Ok. see your point. It is valid and true the new changes do not add to the 
problem.

I just do not agree with the way of contributing. I look at it as if I touch a 
file, I take ownership and pride in making it better. We would not be being 
having this discussion if we had a tool that works and can format the codebase. 
 But we are where we are. So why don't you call a vote?



On 2020/03/08 04:13:11, Xiang Xiao  wrote: 
> On Sun, Mar 8, 2020 at 2:46 AM David Sidrane  wrote:
> >
> > -1 It is Not inline with long term goal and a violation of the Inviolable
> >
> 
> David,
> No new violation here, the code modified in patch still must pass the
> coding style check, the tool just ignored the unmodified part.
> 
> > o Expediency is not a justification for violating the coding standard.
> >
> > -Original Message-
> > From: Xiang Xiao [mailto:xiaoxiang781...@gmail.com]
> > Sent: Saturday, March 07, 2020 10:11 AM
> > To: dev@nuttx.apache.org
> > Subject: Should we relax precheck a little bit?
> >
> > Hi all,
> > The precheck ensure the whole file content comform to the coding
> > style, this strategy has several problems:
> > 1.Many source file in mainline already violate the coding style
> > 2.nxstyle frequently generate the false alarm in the current stage
> > How about we let precheck just ensure the modified line don't violate
> > the coding standards?
> > I am asking this question because:
> > 1.The change in PR 471 has a very good shape:
> >  https://github.com/apache/incubator-nuttx/pull/471/files
> >but the whole file precheck complain there are many errors:
> >  
> > https://github.com/apache/incubator-nuttx/pull/471/checks?check_run_id=492244725
> >It is unfair to require the contributor to fix the issue not made by
> > them.
> > 2.Most PR will fail at precheck stage due to item 1 and then block the
> > more important build test.
> >
> > Thanks
> > Xiang
> 

RE: Should we relax precheck a little bit?

[David Sidrane]

Hi Adam,

Have a look at https://github.com/mikr/whatstyle

I got furthest with clang-format and it. It may be we get a 95% of the way
there with it and we can add a backend secondary scripts.

I was unable to convince Greg to create a master template so my approach was
to combine all the files and run it on the set so it would get all the
constructs at once.

David

-Original Message-
From: Adam Feuer [mailto:a...@starcat.io]
Sent: Saturday, March 07, 2020 4:01 PM
To: dev@nuttx.apache.org
Subject: Re: Should we relax precheck a little bit?

Since there's no current maintainer for nxstyle... What would people think
about trying Clang-Format ?

It's a well-used tool (LLVM, Google, Chromium, Mozilla, Webkit, and
Microsoft ), and
can be configured for many different style guides... it should be possible
to configure it for NuttX's style guide. Or at least get close.

If there's interest, I can take a shot at trying to configure it using the
NuttX style guide. If we went that direction, we'd have another tool to
install. But then we'd only have to maintain a configuration, and we'd be
joining a big community who are all using this same tool.

What do you think?

-adam

On Sat, Mar 7, 2020 at 3:24 PM Gregory Nutt  wrote:

>
> > +1 for fixing nxstyle (or configuring another tool like Clang Format
> > )
> >
> > That would make it a lot easier to submit PRs that are in the right
> format,
> > at least :)
>
> There is no one dedicated to maintaining nxstyle right now.  I wrote the
> original*, but there was once a plan for Haitao Liu to take that over.
> Others (YAMT) and been making good contributions.  So I would not expect
> any snappy response to nxstyle problems right now.
>
> Greg
>
> * Just a little CYA and history.  nsstyle starting out as a tiny hack
> tool that I used to check a few things in files.  It got re-used a few
> times and grew and now it is a key program in the workflow.  It is
> unfortunate fact that the tool is woefully under designed.  Provided
> that we set up some good validation tests, I really think it should be
> redesigned to at least carefully reviewed to make sure that it can
> actually support the things that we expect from it.
>
> It is a dumb tool, it knows nothing about C syntax.  I don't think it
> really needs fully understand C syntax, but it does need to understand
> the context of things better.  Currently it is just a collection of
> heuristics that spots a few landmarks and makes interfaces from
> comparison of some patterns.  So it is not very capable.
>
>
>
>

-- 
Adam Feuer 

Re: Should we relax precheck a little bit?

[Justin Mclean]

Hi,

> But how we measure the release become better and better?

Very simply you succeeded if you attract more users and committers. Being 
welcoming to new committers and having a simple process which that are able to 
take part helps that. I think you are looking though this from a technical lens 
which is perhaps not always the right way to do so.

> Both are the reasonable indicator that the project is on the right direction, 
> is it right?

Sadly I’ve seen projects that take this approach and wither and die, but that 
not to say there is only one path. Try to think community over code.

Thanks,
Justin

Re: NuttX github action pull request check build CI enabled

[Gregory Nutt]

I maintain only the Bitbucket tool repository.


Greg, can we migrate the bitucket tool to https://github.com/nuttx?


No, I am going to keep my repositories on Bitbucket.

Re: Should we relax precheck a little bit?

[Gregory Nutt]

Hi, Xiang,

I basically agree with most of the things you say here, but in an Apache 
project, you cannot set rules unilaterally.  No one person has that 
authority over the project.  We all all equals.  Decisions can only be 
made with concurrence from other team members and we can only get 
concurrence through a full vote.


I think you should:

1. Update the workflow document at 
https://cwiki.apache.org/confluence/display/NUTTX/Code+Contribution+Workflow+--+Brennan+Ashton 
so that it provides  complete descriptions of the step from where some 
decides to modify code until that change is incorporated into the 
repository.


2. Call for a 72-hour [DISCUSS] phase to review the workflow, then then

3. A [VOTE] to approve the workflow.

No direction from one person to another is appropriate without that 
concurrence.  Even then, nothing is really binding.  No one can be 
punished for not following the rules other than through peer pressure.


I appreciate that you might probably be uncomfortable about updating the 
workflow document in a language that is not your native language.  But 
we can help you through that through the review process.


Greg

Re: Should we relax precheck a little bit?

[Adam Feuer]

Thanks David. I'll try your approach. If there are some things that don't
quite work with Clang-Format (I already found a few) I'll see about adding
a fixup script pass at the end, or contributing some rules back to Clang.

I'll try your idea about combining all the files under sched into a set.

When you said you got 95% of the way there, do you have a .clang-format
file that I could use as a starting point? If so that would help me start
where you left off.

cheers
adam

On Sun, Mar 8, 2020 at 3:40 AM David Sidrane 
wrote:

> Hi Adam,
>
> Have a look at https://github.com/mikr/whatstyle
>
> I got furthest with clang-format and it. It may be we get a 95% of the way
> there with it and we can add a backend secondary scripts.
>
> I was unable to convince Greg to create a master template so my approach
> was
> to combine all the files and run it on the set so it would get all the
> constructs at once.
>
> David
>
> -Original Message-
> From: Adam Feuer [mailto:a...@starcat.io]
> Sent: Saturday, March 07, 2020 4:01 PM
> To: dev@nuttx.apache.org
> Subject: Re: Should we relax precheck a little bit?
>
> Since there's no current maintainer for nxstyle... What would people think
> about trying Clang-Format ?
>
> It's a well-used tool (LLVM, Google, Chromium, Mozilla, Webkit, and
> Microsoft ), and
> can be configured for many different style guides... it should be possible
> to configure it for NuttX's style guide. Or at least get close.
>
> If there's interest, I can take a shot at trying to configure it using the
> NuttX style guide. If we went that direction, we'd have another tool to
> install. But then we'd only have to maintain a configuration, and we'd be
> joining a big community who are all using this same tool.
>
> What do you think?
>
> -adam
>
> On Sat, Mar 7, 2020 at 3:24 PM Gregory Nutt  wrote:
>
> >
> > > +1 for fixing nxstyle (or configuring another tool like Clang Format
> > > )
> > >
> > > That would make it a lot easier to submit PRs that are in the right
> > format,
> > > at least :)
> >
> > There is no one dedicated to maintaining nxstyle right now.  I wrote the
> > original*, but there was once a plan for Haitao Liu to take that over.
> > Others (YAMT) and been making good contributions.  So I would not expect
> > any snappy response to nxstyle problems right now.
> >
> > Greg
> >
> > * Just a little CYA and history.  nsstyle starting out as a tiny hack
> > tool that I used to check a few things in files.  It got re-used a few
> > times and grew and now it is a key program in the workflow.  It is
> > unfortunate fact that the tool is woefully under designed.  Provided
> > that we set up some good validation tests, I really think it should be
> > redesigned to at least carefully reviewed to make sure that it can
> > actually support the things that we expect from it.
> >
> > It is a dumb tool, it knows nothing about C syntax.  I don't think it
> > really needs fully understand C syntax, but it does need to understand
> > the context of things better.  Currently it is just a collection of
> > heuristics that spots a few landmarks and makes interfaces from
> > comparison of some patterns.  So it is not very capable.
> >
> >
> >
> >
>
> --
> Adam Feuer 
>


-- 
Adam Feuer 

FW: Should we relax precheck a little bit?

[David Sidrane]

> When you said you got 95% of the way there, do you have a .clang-format
file that I could use as a starting point?

No. I did not get there. I was just referring to to the last % as a script.

-Original Message-
From: Adam Feuer [mailto:a...@starcat.io]
Sent: Sunday, March 08, 2020 9:11 AM
To: dev@nuttx.apache.org
Subject: Re: Should we relax precheck a little bit?

Thanks David. I'll try your approach. If there are some things that don't
quite work with Clang-Format (I already found a few) I'll see about adding
a fixup script pass at the end, or contributing some rules back to Clang.

I'll try your idea about combining all the files under sched into a set.

When you said you got 95% of the way there, do you have a .clang-format
file that I could use as a starting point? If so that would help me start
where you left off.

cheers
adam

On Sun, Mar 8, 2020 at 3:40 AM David Sidrane 
wrote:

> Hi Adam,
>
> Have a look at https://github.com/mikr/whatstyle
>
> I got furthest with clang-format and it. It may be we get a 95% of the way
> there with it and we can add a backend secondary scripts.
>
> I was unable to convince Greg to create a master template so my approach
> was
> to combine all the files and run it on the set so it would get all the
> constructs at once.
>
> David
>
> -Original Message-
> From: Adam Feuer [mailto:a...@starcat.io]
> Sent: Saturday, March 07, 2020 4:01 PM
> To: dev@nuttx.apache.org
> Subject: Re: Should we relax precheck a little bit?
>
> Since there's no current maintainer for nxstyle... What would people think
> about trying Clang-Format ?
>
> It's a well-used tool (LLVM, Google, Chromium, Mozilla, Webkit, and
> Microsoft ), and
> can be configured for many different style guides... it should be possible
> to configure it for NuttX's style guide. Or at least get close.
>
> If there's interest, I can take a shot at trying to configure it using the
> NuttX style guide. If we went that direction, we'd have another tool to
> install. But then we'd only have to maintain a configuration, and we'd be
> joining a big community who are all using this same tool.
>
> What do you think?
>
> -adam
>
> On Sat, Mar 7, 2020 at 3:24 PM Gregory Nutt  wrote:
>
> >
> > > +1 for fixing nxstyle (or configuring another tool like Clang Format
> > > )
> > >
> > > That would make it a lot easier to submit PRs that are in the right
> > format,
> > > at least :)
> >
> > There is no one dedicated to maintaining nxstyle right now.  I wrote the
> > original*, but there was once a plan for Haitao Liu to take that over.
> > Others (YAMT) and been making good contributions.  So I would not expect
> > any snappy response to nxstyle problems right now.
> >
> > Greg
> >
> > * Just a little CYA and history.  nsstyle starting out as a tiny hack
> > tool that I used to check a few things in files.  It got re-used a few
> > times and grew and now it is a key program in the workflow.  It is
> > unfortunate fact that the tool is woefully under designed.  Provided
> > that we set up some good validation tests, I really think it should be
> > redesigned to at least carefully reviewed to make sure that it can
> > actually support the things that we expect from it.
> >
> > It is a dumb tool, it knows nothing about C syntax.  I don't think it
> > really needs fully understand C syntax, but it does need to understand
> > the context of things better.  Currently it is just a collection of
> > heuristics that spots a few landmarks and makes interfaces from
> > comparison of some patterns.  So it is not very capable.
> >
> >
> >
> >
>
> --
> Adam Feuer 
>


-- 
Adam Feuer 

Re: FW: Should we relax precheck a little bit?

[Adam Feuer]

Got it. Thanks.

On Sun, Mar 8, 2020 at 11:10 AM David Sidrane 
wrote:

> > When you said you got 95% of the way there, do you have a .clang-format
> file that I could use as a starting point?
>
> No. I did not get there. I was just referring to to the last % as a script.
>
> -Original Message-
> From: Adam Feuer [mailto:a...@starcat.io]
> Sent: Sunday, March 08, 2020 9:11 AM
> To: dev@nuttx.apache.org
> Subject: Re: Should we relax precheck a little bit?
>
> Thanks David. I'll try your approach. If there are some things that don't
> quite work with Clang-Format (I already found a few) I'll see about adding
> a fixup script pass at the end, or contributing some rules back to Clang.
>
> I'll try your idea about combining all the files under sched into a set.
>
> When you said you got 95% of the way there, do you have a .clang-format
> file that I could use as a starting point? If so that would help me start
> where you left off.
>
> cheers
> adam
>
> On Sun, Mar 8, 2020 at 3:40 AM David Sidrane 
> wrote:
>
> > Hi Adam,
> >
> > Have a look at https://github.com/mikr/whatstyle
> >
> > I got furthest with clang-format and it. It may be we get a 95% of the
> way
> > there with it and we can add a backend secondary scripts.
> >
> > I was unable to convince Greg to create a master template so my approach
> > was
> > to combine all the files and run it on the set so it would get all the
> > constructs at once.
> >
> > David
> >
> > -Original Message-
> > From: Adam Feuer [mailto:a...@starcat.io]
> > Sent: Saturday, March 07, 2020 4:01 PM
> > To: dev@nuttx.apache.org
> > Subject: Re: Should we relax precheck a little bit?
> >
> > Since there's no current maintainer for nxstyle... What would people
> think
> > about trying Clang-Format ?
> >
> > It's a well-used tool (LLVM, Google, Chromium, Mozilla, Webkit, and
> > Microsoft ),
> and
> > can be configured for many different style guides... it should be
> possible
> > to configure it for NuttX's style guide. Or at least get close.
> >
> > If there's interest, I can take a shot at trying to configure it using
> the
> > NuttX style guide. If we went that direction, we'd have another tool to
> > install. But then we'd only have to maintain a configuration, and we'd be
> > joining a big community who are all using this same tool.
> >
> > What do you think?
> >
> > -adam
> >
> > On Sat, Mar 7, 2020 at 3:24 PM Gregory Nutt  wrote:
> >
> > >
> > > > +1 for fixing nxstyle (or configuring another tool like Clang Format
> > > > )
> > > >
> > > > That would make it a lot easier to submit PRs that are in the right
> > > format,
> > > > at least :)
> > >
> > > There is no one dedicated to maintaining nxstyle right now.  I wrote
> the
> > > original*, but there was once a plan for Haitao Liu to take that over.
> > > Others (YAMT) and been making good contributions.  So I would not
> expect
> > > any snappy response to nxstyle problems right now.
> > >
> > > Greg
> > >
> > > * Just a little CYA and history.  nsstyle starting out as a tiny hack
> > > tool that I used to check a few things in files.  It got re-used a few
> > > times and grew and now it is a key program in the workflow.  It is
> > > unfortunate fact that the tool is woefully under designed.  Provided
> > > that we set up some good validation tests, I really think it should be
> > > redesigned to at least carefully reviewed to make sure that it can
> > > actually support the things that we expect from it.
> > >
> > > It is a dumb tool, it knows nothing about C syntax.  I don't think it
> > > really needs fully understand C syntax, but it does need to understand
> > > the context of things better.  Currently it is just a collection of
> > > heuristics that spots a few landmarks and makes interfaces from
> > > comparison of some patterns.  So it is not very capable.
> > >
> > >
> > >
> > >
> >
> > --
> > Adam Feuer 
> >
>
>
> --
> Adam Feuer 
>


-- 
Adam Feuer 

NuttX Companion introductory docs

[Adam Feuer]

Hi,

Over the past 6 weeks I decided to keep all my notes about learning NuttX
in a set of Sphinx ReStructured Text docs. I thought they might be useful
to others.

It's not complete by any means, and they could use improvement especially
in showing the use of other boards and thread-aware debugging. And probably
many other places too. But it's a start. It's open source using the Apache
2.0 License.

If you're interested you can see them here:

NuttX Companion 

If you have improvements or comments I would love to know them!

cheers
adam
-- 
Adam Feuer 

RE: Re: Should we relax precheck a little bit?

[Peter Van Der Perk]

Hi Adam,

I've been trying to make a clang-format for NuttX however I did run in some 
nasty bugs with clang-format.
Mostly the inconsistent spacing caused by preprocessor directives (#ifdef) etc.
I've filed a bug on the LLVM bugtracker 
(https://bugs.llvm.org/show_bug.cgi?id=44843) unfortunely I didn't get any 
response.
Please find below the clang-format I've used, I would say it's 80% done.
But it's mostly that NXStyle requires special things that clang-format doesn’t 
provide.

---
AccessModifierOffset: -6
AlignAfterOpenBracket: Align
AlignConsecutiveAssignments: 'true'
AlignConsecutiveDeclarations: 'false'
AlignEscapedNewlines: DontAlign
AlignTrailingComments: 'true'
AllowShortFunctionsOnASingleLine: None
AllowShortIfStatementsOnASingleLine: 'false'
AllowShortLoopsOnASingleLine: 'false'
AlwaysBreakAfterDefinitionReturnType: None
AlwaysBreakAfterReturnType: AllDefinitions
BreakBeforeBinaryOperators: None
BraceWrapping:
  AfterCaseLabel:  true
  AfterClass:  true
  AfterControlStatement: true
  AfterEnum:   true
  AfterFunction:   true
  AfterNamespace:  true
  AfterObjCDeclaration: true
  AfterStruct: true
  AfterUnion:  true
  BeforeCatch: true
  BeforeElse:  true
  IndentBraces:true
  SplitEmptyFunction: true
  SplitEmptyRecord: true
  SplitEmptyNamespace: true
BreakBeforeBraces: Custom
ColumnLimit: 77
CommentPragmas: '^ IWYU pragma:'
ConstructorInitializerIndentWidth: '0'
ContinuationIndentWidth: 2
IncludeIsMainRegex: (Test)?$
IndentPPDirectives: AfterHash
IndentWidth: '2'
JavaScriptQuotes: Leave
MaxEmptyLinesToKeep: 2
NamespaceIndentation: None
ObjCBlockIndentWidth: '3'
PenaltyBreakBeforeFirstCallParameter: '32'
PenaltyBreakComment: 0
PenaltyBreakFirstLessLess: '44'
PenaltyBreakString: 838
PenaltyExcessCharacter: '399916'
PenaltyReturnTypeOnItsOwnLine: 30
PointerAlignment: Right
ReflowComments: 'true'
SortIncludes: 'false'
SpaceAfterCStyleCast: 'false'
SpaceBeforeAssignmentOperators: 'true'
SpaceBeforeParens: ControlStatements
SpaceInEmptyParentheses: 'false'
SpacesBeforeTrailingComments: 1
SpacesInCStyleCastParentheses: 'false'
SpacesInParentheses: 'false'
SpacesInSquareBrackets: 'false'
Standard: Cpp11
TabWidth: '4'
UseTab: Never
...

> Thanks David. I'll try your approach. If there are some things that don't 
> quite work with Clang-Format (I already found a few) I'll see about adding a 
> fixup script pass at the end, or contributing some rules back to Clang.
> 
> I'll try your idea about combining all the files under sched into a set.
> 
> When you said you got 95% of the way there, do you have a .clang-format file 
> that I could use as a starting point? If so that would help me start where 
> you left off.
> 
>cheers
>adam

Re: Should we relax precheck a little bit?

[Gregory Nutt]

The best pretty printer for NuttX that I am aware of is still 
tools/indent.sh.  It consistently screws up a few things (as listed in 
tools/README.txt).  But the screw-ups are relatively easy and probably 
could be postprocesses.  The astyle and uncrustify stuff in tools/ is 
pretty must useles.


But none of the tools handle subtle things, like aligned of assignments 
on = operators like:


  dog  = bat;   /* Assign dog */
  pony = lizard;    /* Assign pony */
  aardvark = pangolin;  /* Assign aardvark */

and none handle this awful case:

   #ifdef HAVE_SOMETHINGELSE
  if (something == somethingelse)
    {
   do(somethingelse);
    }
  else
   #endif
  if (something == nothing)
    {
  do(nothing);
    }

It is not clear what the indentation should be for the if outside of the 
#ifdef.. #endif.  Most code aligns that if as though the previous 
conditional logic did not exist.


Another issue is the unconditional compound statement which breaks all 
of indentation rules (but this is an nxstyle problem).


  {
    int i
   for (i = 0; i < n; i++)
  {
    handle(i);
  }
  }

The outer {} is indented only by two which makes the indentation of all 
of the inner stuff appear wrong to nxstyle.

Re: Re: Should we relax precheck a little bit?

[Adam Feuer]

Thanks Peter! I will try out your config. If it can get close, I will see
if I can create a post-processor like David said.

cheers
adam

On Sun, Mar 8, 2020 at 2:09 PM Peter Van Der Perk 
wrote:

> Hi Adam,
>
> I've been trying to make a clang-format for NuttX however I did run in
> some nasty bugs with clang-format.
> Mostly the inconsistent spacing caused by preprocessor directives (#ifdef)
> etc.
> I've filed a bug on the LLVM bugtracker (
> https://bugs.llvm.org/show_bug.cgi?id=44843) unfortunely I didn't get any
> response.
> Please find below the clang-format I've used, I would say it's 80% done.
> But it's mostly that NXStyle requires special things that clang-format
> doesn’t provide.
>
> ---
> AccessModifierOffset: -6
> AlignAfterOpenBracket: Align
> AlignConsecutiveAssignments: 'true'
> AlignConsecutiveDeclarations: 'false'
> AlignEscapedNewlines: DontAlign
> AlignTrailingComments: 'true'
> AllowShortFunctionsOnASingleLine: None
> AllowShortIfStatementsOnASingleLine: 'false'
> AllowShortLoopsOnASingleLine: 'false'
> AlwaysBreakAfterDefinitionReturnType: None
> AlwaysBreakAfterReturnType: AllDefinitions
> BreakBeforeBinaryOperators: None
> BraceWrapping:
>   AfterCaseLabel:  true
>   AfterClass:  true
>   AfterControlStatement: true
>   AfterEnum:   true
>   AfterFunction:   true
>   AfterNamespace:  true
>   AfterObjCDeclaration: true
>   AfterStruct: true
>   AfterUnion:  true
>   BeforeCatch: true
>   BeforeElse:  true
>   IndentBraces:true
>   SplitEmptyFunction: true
>   SplitEmptyRecord: true
>   SplitEmptyNamespace: true
> BreakBeforeBraces: Custom
> ColumnLimit: 77
> CommentPragmas: '^ IWYU pragma:'
> ConstructorInitializerIndentWidth: '0'
> ContinuationIndentWidth: 2
> IncludeIsMainRegex: (Test)?$
> IndentPPDirectives: AfterHash
> IndentWidth: '2'
> JavaScriptQuotes: Leave
> MaxEmptyLinesToKeep: 2
> NamespaceIndentation: None
> ObjCBlockIndentWidth: '3'
> PenaltyBreakBeforeFirstCallParameter: '32'
> PenaltyBreakComment: 0
> PenaltyBreakFirstLessLess: '44'
> PenaltyBreakString: 838
> PenaltyExcessCharacter: '399916'
> PenaltyReturnTypeOnItsOwnLine: 30
> PointerAlignment: Right
> ReflowComments: 'true'
> SortIncludes: 'false'
> SpaceAfterCStyleCast: 'false'
> SpaceBeforeAssignmentOperators: 'true'
> SpaceBeforeParens: ControlStatements
> SpaceInEmptyParentheses: 'false'
> SpacesBeforeTrailingComments: 1
> SpacesInCStyleCastParentheses: 'false'
> SpacesInParentheses: 'false'
> SpacesInSquareBrackets: 'false'
> Standard: Cpp11
> TabWidth: '4'
> UseTab: Never
> ...
>
> > Thanks David. I'll try your approach. If there are some things that
> don't quite work with Clang-Format (I already found a few) I'll see about
> adding a fixup script pass at the end, or contributing some rules back to
> Clang.
> >
> > I'll try your idea about combining all the files under sched into a set.
> >
> > When you said you got 95% of the way there, do you have a .clang-format
> file that I could use as a starting point? If so that would help me start
> where you left off.
> >
> >cheers
> >adam
>


-- 
Adam Feuer 

Re: Should we relax precheck a little bit?

[Adam Feuer]

Thanks Greg. I haven't tried indent, I will try it with the config you
suggest, if it can get close I'll try a pre-processor script with it too.

-adam

On Sun, Mar 8, 2020 at 2:21 PM Gregory Nutt  wrote:

> The best pretty printer for NuttX that I am aware of is still
> tools/indent.sh.  It consistently screws up a few things (as listed in
> tools/README.txt).  But the screw-ups are relatively easy and probably
> could be postprocesses.  The astyle and uncrustify stuff in tools/ is
> pretty must useles.
>
> But none of the tools handle subtle things, like aligned of assignments
> on = operators like:
>
>dog  = bat;   /* Assign dog */
>pony = lizard;/* Assign pony */
>aardvark = pangolin;  /* Assign aardvark */
>
> and none handle this awful case:
>
> #ifdef HAVE_SOMETHINGELSE
>if (something == somethingelse)
>  {
> do(somethingelse);
>  }
>else
> #endif
>if (something == nothing)
>  {
>do(nothing);
>  }
>
> It is not clear what the indentation should be for the if outside of the
> #ifdef.. #endif.  Most code aligns that if as though the previous
> conditional logic did not exist.
>
> Another issue is the unconditional compound statement which breaks all
> of indentation rules (but this is an nxstyle problem).
>
>{
>  int i
> for (i = 0; i < n; i++)
>{
>  handle(i);
>}
>}
>
> The outer {} is indented only by two which makes the indentation of all
> of the inner stuff appear wrong to nxstyle.
>
>
>

-- 
Adam Feuer 

Re: Should we relax precheck a little bit?

[Adam Feuer]

Pre- or post- processor I meant, depending on what would work best.

-adam

On Sun, Mar 8, 2020 at 2:29 PM Adam Feuer  wrote:

> Thanks Greg. I haven't tried indent, I will try it with the config you
> suggest, if it can get close I'll try a pre-processor script with it too.
>
> -adam
>
> On Sun, Mar 8, 2020 at 2:21 PM Gregory Nutt  wrote:
>
>> The best pretty printer for NuttX that I am aware of is still
>> tools/indent.sh.  It consistently screws up a few things (as listed in
>> tools/README.txt).  But the screw-ups are relatively easy and probably
>> could be postprocesses.  The astyle and uncrustify stuff in tools/ is
>> pretty must useles.
>>
>> But none of the tools handle subtle things, like aligned of assignments
>> on = operators like:
>>
>>dog  = bat;   /* Assign dog */
>>pony = lizard;/* Assign pony */
>>aardvark = pangolin;  /* Assign aardvark */
>>
>> and none handle this awful case:
>>
>> #ifdef HAVE_SOMETHINGELSE
>>if (something == somethingelse)
>>  {
>> do(somethingelse);
>>  }
>>else
>> #endif
>>if (something == nothing)
>>  {
>>do(nothing);
>>  }
>>
>> It is not clear what the indentation should be for the if outside of the
>> #ifdef.. #endif.  Most code aligns that if as though the previous
>> conditional logic did not exist.
>>
>> Another issue is the unconditional compound statement which breaks all
>> of indentation rules (but this is an nxstyle problem).
>>
>>{
>>  int i
>> for (i = 0; i < n; i++)
>>{
>>  handle(i);
>>}
>>}
>>
>> The outer {} is indented only by two which makes the indentation of all
>> of the inner stuff appear wrong to nxstyle.
>>
>>
>>
>
> --
> Adam Feuer 
>


-- 
Adam Feuer 

Re: NuttX Companion introductory docs

[Nathan Hartman]

On Sun, Mar 8, 2020 at 4:08 PM Adam Feuer  wrote:

> Hi,
>
> Over the past 6 weeks I decided to keep all my notes about learning NuttX
> in a set of Sphinx ReStructured Text docs. I thought they might be useful
> to others.
>
> It's not complete by any means, and they could use improvement especially
> in showing the use of other boards and thread-aware debugging. And probably
> many other places too. But it's a start. It's open source using the Apache
> 2.0 License.
>
> If you're interested you can see them here:
>
> NuttX Companion 
>
> If you have improvements or comments I would love to know them!
>
> cheers
> adam
> --
> Adam Feuer 
>
Cool! Would it be possible to convert these to Confluence and make them
available directly on the official Apache NuttX site? (Making it available
for reading and editing, will allow the community to further improve and
gradually complete your notes.)

Nathan

Re: squashing commits or not

[Nathan Hartman]

On Fri, Mar 6, 2020 at 10:20 AM Abdelatif Guettouche <
abdelatif.guettou...@gmail.com> wrote:

> I think you made it clear that you prefer a TL;DR; document.  Maybe we
> can have both.


If we go back to my original email on this subject a couple of months ago,
I suggested to begin with a tl;dr; section and then follow it with the
detailed text. Now that we have the detailed text, it's a simple matter to
summarize it and put the summary at the top.

We will need a second document explaining the release process that we
haven't designed yet.

Re: squashing commits or not

[Gregory Nutt]

If we go back to my original email on this subject a couple of months ago,
I suggested to begin with a tl;dr; section and then follow it with the
detailed text. Now that we have the detailed text, it's a simple matter to
summarize it and put the summary at the top.


Only slightly related... This morning, I removed some of the writing 
instructions from the trop draft work flow proposal.  I think they have 
served their purpose and destroy readability of the document.  I also 
delete all of the comments that I could (I can't delete other people's 
comments and I can't delete my comments if people responded to them).


Perhaps this will may the document less intimidating.  It would be good 
to get all of the other kruft out of the document to so that we can 
refine what's there.  If other people will delete there own, obsolete 
comments, I will delete more of mine as well.


Greg

Re: NuttX Companion introductory docs

[Adam Feuer]

On Sun, Mar 8, 2020 at 2:35 PM Nathan Hartman 
wrote:

> Cool! Would it be possible to convert these to Confluence and make them
> available directly on the official Apache NuttX site?


No. You're welcome to do that if you want. But I think there's value in
having this set of docs in source control.

Having the docs in a wiki would make it very hard to synchronize a version
of documentation with a particular software revision if we wanted to do
that, making it hard to get accurate docs for a particular release. Note
that many projects and programming languages keep their docs in source
control for this reason. (Python
, Rust
, Clang
, etc.) So does the
Zephyr RTOS project BTW (docs , docs
source ).

There's a more practical reason for me too... I find it extremely hard to
create good-looking, usable documentation in Confluence. I prefer to use a
technical documentation markup language like RST.


> (Making it available
> for reading and editing, will allow the community to further improve and
> gradually complete your notes.)
>

The book is open source and on Github, I'm taking pull requests. So people
are welcome to collaborate that way! And the project can be forked there
too.

My suggestion would be to simply put a link from the wiki docs to this
book. I can't do that because I tried to create a Apache Confluence account
that had edit rights a few weeks ago, and failed. I tried to get tech
support from Apache but no one could help me work it out.

cheers
adam
-- 
Adam Feuer 

Re: NuttX Companion introductory docs

[Brennan Ashton]

On Sun, Mar 8, 2020, 3:03 PM Adam Feuer  wrote:

> My suggestion would be to simply put a link from the wiki docs to this
> book. I can't do that because I tried to create a Apache Confluence account
> that had edit rights a few weeks ago, and failed. I tried to get tech
> support from Apache but no one could help me work it out.
>
> cheers
> adam
>

What is your Apache user name I'll happily give you the permissions. That
goes for anyone else that is part of the project. Just let us know and we
can click the buttons :) just need to have the barrier to keep the spam
down.

--Brennan

Re: NuttX Companion introductory docs

[Adam Feuer]

Nathan,

I'm sorry for being abrupt with that "no." :)

I just think for now the best approach would be to link to the docs, and if
people want to collaborate or fill in missing pieces, they can open PRs or
Issues. If that doesn't work, we can look at other ways to go.

cheers
adam

On Sun, Mar 8, 2020 at 2:35 PM Nathan Hartman 
wrote:

> On Sun, Mar 8, 2020 at 4:08 PM Adam Feuer  wrote:
>
> > Hi,
> >
> > Over the past 6 weeks I decided to keep all my notes about learning NuttX
> > in a set of Sphinx ReStructured Text docs. I thought they might be useful
> > to others.
> >
> > It's not complete by any means, and they could use improvement especially
> > in showing the use of other boards and thread-aware debugging. And
> probably
> > many other places too. But it's a start. It's open source using the
> Apache
> > 2.0 License.
> >
> > If you're interested you can see them here:
> >
> > NuttX Companion 
> >
> > If you have improvements or comments I would love to know them!
> >
> > cheers
> > adam
> > --
> > Adam Feuer 
> >
> Cool! Would it be possible to convert these to Confluence and make them
> available directly on the official Apache NuttX site? (Making it available
> for reading and editing, will allow the community to further improve and
> gradually complete your notes.)
>
> Nathan
>


-- 
Adam Feuer 

Re: NuttX Companion introductory docs

[Adam Feuer]

Thanks Brennan. That worked.

I put a link to the NuttX Companion on the Getting Started page
 and
also on the main Documentation page
 at the
bottom.

cheers
adam

On Sun, Mar 8, 2020 at 3:28 PM Brennan Ashton 
wrote:

> On Sun, Mar 8, 2020, 3:03 PM Adam Feuer  wrote:
>
> > My suggestion would be to simply put a link from the wiki docs to this
> > book. I can't do that because I tried to create a Apache Confluence
> account
> > that had edit rights a few weeks ago, and failed. I tried to get tech
> > support from Apache but no one could help me work it out.
> >
> > cheers
> > adam
> >
>
> What is your Apache user name I'll happily give you the permissions. That
> goes for anyone else that is part of the project. Just let us know and we
> can click the buttons :) just need to have the barrier to keep the spam
> down.
>
> --Brennan
>


-- 
Adam Feuer 

Re: Should we relax precheck a little bit?

[Justin Mclean]

Hi,

> I basically agree with most of the things you say here, but in an Apache 
> project, you cannot set rules unilaterally.  No one person has that authority 
> over the project.  We all all equals.  Decisions can only be made with 
> concurrence from other team members and we can only get concurrence through a 
> full vote.

Refining that a bit. It true no one has authority but it's best to try and to 
reach consensus by discussion. Voting too often or too early makes winners and 
losers and splits the community. Vote when done is usually made to confirm that 
consensus and when called teh outcome is already known.

I would not suggest having a vote on this in such a short time frame.

Thanks,
Justin

Build failed in Jenkins: NuttX-Nightly-Build #58

[Apache Jenkins Server]

See 

Changes:


--
[...truncated 504.43 KB...]
  Copy files
  Select CONFIG_HOST_LINUX=y
  Refreshing...
  Building NuttX...

mtd/at24xx.c:139:4: warning: #warning "Assuming MTD driver block size is the 
same as the FLASH page size" [-Wcpp]
 #  warning "Assuming MTD driver block size is the same as the FLASH page size"
^~~

Skipping: sim/cxxtest

Configuration/Tool: sim/nettest

  Cleaning...
  Configuring...
  Copy files
  Select CONFIG_HOST_LINUX=y
  Refreshing...
  Building NuttX...


Skipping: sim/nxwm

Configuration/Tool: sim/ipforward

  Cleaning...
  Configuring...
  Copy files
  Select CONFIG_HOST_LINUX=y
  Refreshing...
  Building NuttX...


Configuration/Tool: sim/nx

  Cleaning...
  Configuring...
  Copy files
  Select CONFIG_HOST_LINUX=y
  Refreshing...
  Building NuttX...


Configuration/Tool: sim/ostest

  Cleaning...
  Configuring...
  Copy files
  Select CONFIG_HOST_LINUX=y
  Refreshing...
  Building NuttX...


Configuration/Tool: sim/mount

  Cleaning...
  Configuring...
  Copy files
  Select CONFIG_HOST_LINUX=y
  Refreshing...
  Building NuttX...


Configuration/Tool: sim/minibasic

  Cleaning...
  Configuring...
  Copy files
  Select CONFIG_HOST_LINUX=y
  Refreshing...
  Building NuttX...


Configuration/Tool: sim/tcpblaster

  Cleaning...
  Configuring...
  Copy files
  Select CONFIG_HOST_LINUX=y
  Refreshing...
  Building NuttX...

tcpblaster_server.c: In function 'tcpblaster_server':
tcpblaster_server.c:256:71: warning: passing argument 1 of 'localtime' from 
incompatible pointer type [-Wincompatible-pointer-types]
   strftime(timebuff, 100, "%Y-%m-%d %H:%M:%S.000", localtime (&curr));
   ^
In file included from tcpblaster_server.c:50:0:
/usr/include/time.h:123:19: note: expected 'const time_t * {aka const long int 
*}' but argument is of type 'struct timespec *'
 extern struct tm *localtime (const time_t *__timer) __THROW;
   ^
tcpblaster_client.c: In function 'tcpblaster_client':
tcpblaster_client.c:230:71: warning: passing argument 1 of 'localtime' from 
incompatible pointer type [-Wincompatible-pointer-types]
   strftime(timebuff, 100, "%Y-%m-%d %H:%M:%S.000", localtime (&curr));
   ^
In file included from 
:47:0,
 from 
:48,
 from 
:50,
 from 
:48,
 from tcpblaster_client.c:45:

Re: Should we relax precheck a little bit?

[Xiang Xiao]

On Mon, Mar 9, 2020 at 12:52 PM Justin Mclean  wrote:
>
> Hi,
>
> > I basically agree with most of the things you say here, but in an Apache 
> > project, you cannot set rules unilaterally.  No one person has that 
> > authority over the project.  We all all equals.  Decisions can only be made 
> > with concurrence from other team members and we can only get concurrence 
> > through a full vote.
>
> Refining that a bit. It true no one has authority but it's best to try and to 
> reach consensus by discussion. Voting too often or too early makes winners 
> and losers and splits the community. Vote when done is usually made to 
> confirm that consensus and when called teh outcome is already known.
>

Yes, that is why I send this email to get the community feedback.
To avoid the topic extend to the unrelated field, let's just focus on
one thing I suggest:
The github action just check the coding style for the modified lines
in the patch, not the whole source lines.
Here is the several reasons:
1.It's hard to review the real change if we mix the style change in
PR, here is two examples:
   https://github.com/apache/incubator-nuttx/pull/492
   https://github.com/apache/incubator-nuttx/pull/495
   The change in these two PR is simple:
   1.Fix the warning: implicit declaration of function 'uart_earlyserialinit'
   2.Change the argument and return of spi_send from uint16_t to uint32_t
   But it is very hard to review now because more than 90% change is
to fix the style issue.
2.The github action still ensure the modified lines confirm the coding
standard, so the relaxtion don't make the situation worse.
3.The contributor or committer still can create the dedicated patch to
fix the style issue.
Please reply with your reason here if you have different opinion, so
the community can get more thought.

> I would not suggest having a vote on this in such a short time frame.
>

How much time should we wait before starting a vote?

> Thanks,
> Justin