It would be good to document the Hz, MHz, ... exception in the section 2.8 of
the coding style document, along with VOLTAGE_3p3V and CONFIG_NET_IPv6.
How about also allowing VOLTAGE_2mV and CURRENT_4mA and also uV and uA? I find
it odd that the battery charger drivers now charge with megavolts a
On Mon, May 18, 2020 at 9:20 PM Gregory Nutt wrote:
>
> > ... Either way, the left edge of the comment will not line up
> > with the "define" or "undef."
>
> This is the perfect illustration of the problem of mixing the
> incompatible C and pre-processor indentation. Visually, you eye is
> drawn
... Either way, the left edge of the comment will not line up
with the "define" or "undef."
This is the perfect illustration of the problem of mixing the
incompatible C and pre-processor indentation. Visually, you eye is
drawn to want to align the C code with the pre-processor indentation
So, would the correct indentation for the comment be at 2 columns or at 4
columns here? Either way, the left edge of the comment will not line up
with the "define" or "undef."
Column 1. Why should there be any indentation on the comments. There is
no C nesting at all.
It is nearly impossi
On Mon, May 18, 2020 at 8:08 PM Gregory Nutt wrote:
>
> > Actually, I just ran into another nxstyle-related conundrum and I
> > don't see anything about this in the coding standard.
> >
> > Regarding indentations, the coding standard says that everything is
> > indented by units of 2, so that all
Actually, I just ran into another nxstyle-related conundrum and I
don't see anything about this in the coding standard.
Regarding indentations, the coding standard says that everything is
indented by units of 2, so that all C code begins at column 4n + 2.
But preprocessor statements begin with
Actually, I just ran into another nxstyle-related conundrum and I
don't see anything about this in the coding standard.
Regarding indentations, the coding standard says that everything is
indented by units of 2, so that all C code begins at column 4n + 2.
But preprocessor statements begin with a '
On Mon, May 18, 2020 at 7:48 PM Gregory Nutt wrote:
> >> I started out life a a tiny, ad hoc program to help me review code and
> >> then became indispensable. It was never designed; it just evolved.
> > Some programs just "happen" that way, and work fine, and there's no
> > need to replace them.
I started out life a a tiny, ad hoc program to help me review code and
then became indispensable. It was never designed; it just evolved.
Some programs just "happen" that way, and work fine, and there's no
need to replace them.
True. However, there is some software for which you are less pro
On Mon, May 18, 2020 at 7:39 PM Gregory Nutt wrote:
> You should feel free to just modify nxstyle at any time you like.
:-)
> I started out life a a tiny, ad hoc program to help me review code and
> then became indispensable. It was never designed; it just evolved.
Some programs just "happen"
LGTM. I can't come up with any credible case where that would fail
badly. I suppose if someone wanted SHMOOZHz that would be okay albeit
weird. One would normally expect a limited number of things before the
H, but I don't think we need be concerned about that.
I first considered making the
Submitted PR1067.
Cheers,
Nathan
On Mon, May 18, 2020 at 7:20 PM Gregory Nutt wrote:
> LGTM. I can't come up with any credible case where that would fail
> badly. I suppose if someone wanted SHMOOZHz that would be okay albeit
> weird. One would normally expect a limited number of things before the
> H, but I don't think we nee
case 'z':
if (!have_upper || n < 1 ||
line[n - 1] != 'H')
{
have_lower = true;
}
break;
On Mon, May 18, 2020 at 6:29 PM Gregory Nutt wrote:
> > Are abbreviations like MHz, KHz, Hz, intended to be exceptions to the
> > mixed case rules?
>
> Yes, the coding standard is here:
snip
> If that is not working, then please consider a PR. I see logic that
> picks off and ignores MHz but no
nxstyle produces errors about mixed case identifiers like the
following, which are found throughout the system:
GPIO_SPEED_100MHz
GPIO_SPEED_10MHz
GPIO_SPEED_120MHz
GPIO_SPEED_25MHz
GPIO_SPEED_2MHz
GPIO_SPEED_400KHz
GPIO_SPEED_40MHz
GPIO_SPEED_50MHz
GPIO_SPEED_5MHz
Are abbreviations like MHz,
nxstyle produces errors about mixed case identifiers like the
following, which are found throughout the system:
GPIO_SPEED_100MHz
GPIO_SPEED_10MHz
GPIO_SPEED_120MHz
GPIO_SPEED_25MHz
GPIO_SPEED_2MHz
GPIO_SPEED_400KHz
GPIO_SPEED_40MHz
GPIO_SPEED_50MHz
GPIO_SPEED_5MHz
Are abbreviations like MHz, KHz
On 5/18/2020 12:02 PM, Nathan Hartman wrote:
Moving this discussion from a 2020/05/17 thread titled:
"Backporting Fixes [was: heap malloc when executing binary/elf file]"
The discussion about automated testing begins at [1] where Greg
asks whether we want to invest in an exhaustive functional te
On Mon, May 18, 2020 at 12:12 PM Gregory Nutt wrote:
> I think we need to assure that these two "tiers" are compatible and use
> the same test infrastructure. The should have these things in common:
I'd like to move this discussion to a new thread, titled "Automated
Testing" without several leve
Moving this discussion from a 2020/05/17 thread titled:
"Backporting Fixes [was: heap malloc when executing binary/elf file]"
The discussion about automated testing begins at [1] where Greg
asks whether we want to invest in an exhaustive functional test suite
to qualify releases.
I suggested that
* The next tier could be an automated test suite that runs in a
simulator.
This would be accessible to the greatest numbers of developers and
contributors, because there's nothing to buy.
* The highest tier could be testing on a reference hardware board.
I think we need to assure th
So, in current git HEAD [1], what is the search order now?
Is it back to:
- Elf
- Built-in
- NSH
Or is it:
- Built-in
- Elf
- NSH
It is not so clean and well partitioned. It is more like:
o IF Built-in available
- Elf
- IF NOT Elf
Built-in
o Elf
o NSH
The logic is spread across
On Mon, May 18, 2020 at 12:03 AM Gregory Nutt wrote:
> Build testing is important but does not address functionality. Things
> can be completely broken and still build perfectly.
Correct.
> Currently our functional testing strategy is simply to ask people to
> check releases. But no problems ha
>
>
> That is true. The assumption is that the stack size of the built-in
> application will be big enough for the replacement ELF application.
> That might not be true. But in the case of replacing a built-in
> application with an ELF application, the rule is that we cannot
> modify
> the
So, in current git HEAD [1], what is the search order now?
Is it back to:
- Elf
- Built-in
- NSH
Or is it:
- Built-in
- Elf
- NSH
It is not so clean and well partitioned. It is more like:
o IF Built-in available
- Elf
- IF NOT Elf
Built-in
o Elf
o NSH
The logic is spread across a
On Mon, May 18, 2020 at 10:38 AM Gregory Nutt wrote:
> >> Yes, the best solution is to extend ELF with stack and priority info.
> >> But before that happen, gathering this info from the built-in app
> >> table is workable alternative:
> >> 1.Keep the trying order(file system, built-in and nsh comm
Yes, the best solution is to extend ELF with stack and priority info.
But before that happen, gathering this info from the built-in app
table is workable alternative:
1.Keep the trying order(file system, built-in and nsh command)
2.And get the stack/priority from built-in app table for file s
Yes, the best solution is to extend ELF with stack and priority info.
But before that happen, gathering this info from the built-in app
table is workable alternative:
1.Keep the trying order(file system, built-in and nsh command)
2.And get the stack/priority from built-in app table for file sys
On Mon, May 18, 2020 at 9:07 PM Gregory Nutt wrote:
>
>
> > OK, by now I'll keep using the alternative to use another name for the
> > elf app/FILE_APPS, as seemingly intended by
> > chao.an in his commit.
> No, that was an error. The requirements have always supported
> replacement of built-in a
OK, by now I'll keep using the alternative to use another name for the
elf app/FILE_APPS, as seemingly intended by
chao.an in his commit.
No, that was an error. The requirements have always supported
replacement of built-in applications with ELF applications. That is a
recommended way for u
Hi all,
OK, by now I'll keep using the alternative to use another name for the
elf app/FILE_APPS, as seemingly intended by
chao.an in his commit.
I don't really understand Chaos solution because if the ELF app needs a
bigger stack, which is quite probable because it is a
derivation/evolution of
31 matches
Mail list logo
