Re: Introduction + incoming RISC-V port(s)

[Robert Lipe <ro...@gmail.com>]

This iteration of BeagleV hardware is canceled <https://beaglev.org/>.
Given the friction of landing PR#3965, I'm just going to abandon it and
mark that CL closed and will be unsubscribing from the lists.  There's
probably nothing worth heroic efforts to preserve; only a few of those 108
commits were real work with the rest just feeding the machine. That basic
PR will be needed by the likes of  SiFive Unmatched and other RISC-V
hardware.

The NuttX tech is interesting, but I spent an unreasonable amount of time
chasing ghosts in the build system and the culture. A style guide that's so
complex that you can't teach it to a machine and blocking submits because
unrelated files have C99 comments inside an embedded string is just not a
fit for me.

Thanx to those of you that genuinely tried to help onboard a new dev. Good
luck to the project on your journey to be accepted by Apache.

RJL

On Wed, Jun 23, 2021 at 10:03 AM Abdelatif Guettouche <
abdelatif.guettouche@gmail.com> wrote:

> *So I've kicked that back in, but it appears I have to wait for a
> (gasp)human**to push a button*.
>
> This is actually a Github thing and is outside of our control.  It's pretty
> new too, so we too have to get used to it.  As Nathan said, this only
> applies to first time contributors.  Subsequent contributions should go a
> bit smoother.
>
> On Wed, Jun 23, 2021, 3:37 PM Nathan Hartman <ha...@gmail.com>
> wrote:
>
> > On Tue, Jun 22, 2021 at 11:12 PM Robert Lipe <ro...@gmail.com>
> wrote:
> >
> > > >
> > > >
> > > > > The presubmit flips out about C99 comments. Even that's too
> radical.
> > So
> > > > > much for being king. :-)
> > > >
> > > > You can use C99, but you cannot forgot to follow the Coding Style, //
> > > > comments shouldn't be used :-)
> > > >
> > >
> > > It's actually worse than that. You can use C99 comments at the end of a
> > > line
> > > but not at the beginning
> > >
> > > frobnicate();  // this is accepted
> > > // this is an error
> >
> >
> > That is a bug in nxstyle.c and should be fixed. Please file an issue or,
> if
> > you're inclined, open a PR...
> >
> > This is perfectly legal C99. That's 20+ years ago and was widely accepted
> > > before then.
> >
> >
> > That's true; however this standard and code style are well established in
> > this project; of course anyone can feel free to open a [DISCUSS] thread
> to
> > propose changes but the onus is obviously on them to persuade the
> community
> > why it should make those changes.
> >
> > I see // comments in 48 *.[ch] files. That ship has sailed.
> >
> >
> > That, too, is a bug and should be fixed.
> >
> > So I've kicked that back in, but it appears I have to wait for a (gasp)
> > > human
> > > to push a button. I assume this is to stop script kiddies from
> submitting
> > > bitcoin
> > > harvesters in the presubmit, but it really hoses a workflow as it's
> like
> > > submitting
> > > a box of punched cards across the table into the Holy Room where
> > computing
> > > is done and then awaiting a stack of greenbar with the results later in
> > the
> > > day.
> >
> >
> > Yes, it's to stop script kiddies with their mining businesses; however
> IIRC
> > that only applies to your first PR with a project. I think once your PR
> > gets merged the next one will go more swiftly.
> >
> > Hopefully, you're convinced I'm an actual human at this point (even if I
> > > complain
> > > too much :-)
> >
> >
> > Nope. I'm not convinced. :-p
> >
> > Jokes aside your participation is greatly appreciated.
> >
> > Cheers,
> > Nathan
> >
>

Re: Introduction + incoming RISC-V port(s)

[Robert Lipe <ro...@gmail.com>]

>
>
> >
> > In sum, it's not that NuttX is hard. It's that *NuttX IS MADE HARD,
> > PROBABLY ON PURPOSE*
>

I told myself to let NuttX go silently (I did unsub), but this overall
story matches several I've seen.

The core architecture is just weird in ways that don't encourage fresh
blood. Whitespace and comment standards seems minor but it not being
automatically generated by any existing editor doesn't add value; it adds
cognitive overhead for anyone that isn't exclusive with this code.

In researching code, I found several majorish contributions in GitHub that
silently coasted to a halt after several rounds of hoop jumping.  The large
PRs have just idled  because the devs have gotten frustrated and left. (My
various feedback may have been perceived as rude, but at least I told you
why I left in the hope you can make it better for the next dev. In zero
cases did I feel that feedback was welcome.) In all the cases I noticed,
those were the last PRs in this project opened by those devs, so it's a
lost talent opportunity.

So I'm not sure it's on purpose, but there's a visible brain drain in the
thousands (!) of open PRs on the project.

Maybe NuttX has reached stasis and the existing team can keep it
maintained. It's a cool project and a welcome entry in the space between,
say, Free RTOS and a full million line Linux kernel + glibc, so I genuinely
do wish the project success whether that's a static core or a growing team.

Good luck!

Re: Introduction + incoming RISC-V port(s)

[Alan Carvalho de Assis <ac...@gmail.com>]

Hi Grr,

I agree with many points you raised: the amount of options inside
NuttX menuconfig is really a bad thing, it is like a maze. You need to
track many configs until you get everything in place and get things
done. But in the other hand it is what let you to fine tune the system
for your need.

It was implemented this way because of the modularity, flexibility and
customization level offered by NuttX. When you select that you want
Network support the configuration don't try to "read or mind" and
enable TCP or other protocol. You need to connect all the points.

I think raising these issues is really valid and helps to realize the issue.

About SPI, the solution you suggested was interesting, but as I recall
it was not easy to implement. I requires creating many pins options
inside the menuconfig, also it requires some external tool that you
develop, if I recall correct. I think the best approve for NuttX is
gaining support to Device Tree, like the existent for Zephyr.

Many of the issues related to board configuration for devices that
uses I2C and SPI can be fixed using the "common board" approach, but
it needs to be fixed for all boards and as you know we don't have many
people helping.

BR,

Alan

On 8/6/21, Grr <ge...@gmail.com> wrote:
> El mar, 3 ago 2021 a las 6:49, Alan Carvalho de Assis (<ac...@gmail.com>)
> escribió:
>
>> Unfortunately NuttX is not for faint of heart people (same to the
>> Linux kernel)
>
> I don't know about Linux but what makes NuttX not for the faint of heart is
> you, the core programmers. I explain why:
>
> *Config Nightmare*
> NuttX menuconfig is a minefield. The first time I tried to test NuttX,
> selecting desired options caused a compilation crash because there are a
> lot of broken combinations (I fixed 4 or 5 to flex my muscles), especially
> regarding networking. When I *repeatedly* talked about making it easier for
> newbies, nobody even blinked and when I came with a GPIO subsystem that
> allows easy configuration via menuconfig, you showed complete lack of
> interest
>
> *Balkanization*
> Device support in NuttX is ludicrous. If I want to connect an SPI device
> like MCP2515 to a *supported random board*, I have to port the driver
> because the existing driver is tied to Blue Pill and one or two other
> boards. As anyone understands, a supported SPI peripheral *should* work
> with *any* supported board because a driver should work at bus level, *not*
> board level. If I'm a newbie that doesn't want or can go that deep, I'm SOL
>
> *Double Standards*
> I tried to correct the situation and developed a new SPI subsystem that
> doesn't tie drivers to a specific board, just to clash into header file
> mess: with the excuse of modularity, header files are mixed with source
> files, making it very difficult (I suspect on purpose) to build a
> board-agnostic driver system
>
> Of course, modularity is something for *others* to observe. The leader can
> enforce modularity and at the same time recommend to use internal
> interfaces when needed (
> https://www.mail-archive.com/dev@nuttx.apache.org/msg05752.html)
>
> *Networking Phobia*
> Back in 2015, I asked about SocketCAN on NuttX (
> https://nuttx.yahoogroups.narkive.com/RMKDgEcn/canopen-stack) but Nutt
> didn't want to even hear about it and *ERASED MY QUESTIONS FROM NEWSGROUP*.
> Five years later, Nutt was deploring that SocketCAN port to NuttX was
> rusting in a branch. And this schizophrenic attitude towards networking
> shows in NuttX
>
> In sum, it's not that NuttX is hard. It's that *NuttX IS MADE HARD,
> PROBABLY ON PURPOSE*
>
> In that scenario, Robert's position is perfectly understandable and even
> advisable. I myself will follow suit and go to a better RTOS, where I don't
> have to fight against everything to get the work done. I've wasted enough
> time
>
> Good bye
>
>
>> I know you are not an stupid guy and you have great
>> projects under your belt, but think also about your attitudes here.
>> Read again all the complains you did in your emails and imagine the
>> other side of your computer are few guys that spend years of their
>> life making that code.
>>
>> BR,
>>
>> Alan
>>
>> On 8/3/21, Robert Lipe <ro...@gmail.com> wrote:
>> > This iteration of BeagleV hardware is canceled <https://beaglev.org/>.
>> > Given the friction of landing PR#3965, I'm just going to abandon it and
>> > mark that CL closed and will be unsubscribing from the lists.  There's
>> > probably nothing worth heroic efforts to preserve; only a few of those
>> 108
>> > commits were real work with the rest just feeding the machine. That
>> > basic
>> > PR will be needed by the likes of  SiFive Unmatched and other RISC-V
>> > hardware.
>> >
>> > The NuttX tech is interesting, but I spent an unreasonable amount of
>> > time
>> > chasing ghosts in the build system and the culture. A style guide
>> > that's
>> so
>> > complex that you can't teach it to a machine and blocking submits
>> > because
>> > unrelated files have C99 comments inside an embedded string is just not
>> > a
>> > fit for me.
>> >
>> > Thanx to those of you that genuinely tried to help onboard a new dev.
>> Good
>> > luck to the project on your journey to be accepted by Apache.
>> >
>> > RJL
>> >
>> > On Wed, Jun 23, 2021 at 10:03 AM Abdelatif Guettouche <
>> > abdelatif.guettouche@gmail.com> wrote:
>> >
>> >> *So I've kicked that back in, but it appears I have to wait for a
>> >> (gasp)human**to push a button*.
>> >>
>> >> This is actually a Github thing and is outside of our control.  It's
>> >> pretty
>> >> new too, so we too have to get used to it.  As Nathan said, this only
>> >> applies to first time contributors.  Subsequent contributions should
>> >> go
>> a
>> >> bit smoother.
>> >>
>> >> On Wed, Jun 23, 2021, 3:37 PM Nathan Hartman
>> >> <ha...@gmail.com>
>> >> wrote:
>> >>
>> >> > On Tue, Jun 22, 2021 at 11:12 PM Robert Lipe <ro...@gmail.com>
>> >> wrote:
>> >> >
>> >> > > >
>> >> > > >
>> >> > > > > The presubmit flips out about C99 comments. Even that's too
>> >> radical.
>> >> > So
>> >> > > > > much for being king. :-)
>> >> > > >
>> >> > > > You can use C99, but you cannot forgot to follow the Coding
>> >> > > > Style,
>> >> > > > //
>> >> > > > comments shouldn't be used :-)
>> >> > > >
>> >> > >
>> >> > > It's actually worse than that. You can use C99 comments at the end
>> of
>> >> > > a
>> >> > > line
>> >> > > but not at the beginning
>> >> > >
>> >> > > frobnicate();  // this is accepted
>> >> > > // this is an error
>> >> >
>> >> >
>> >> > That is a bug in nxstyle.c and should be fixed. Please file an issue
>> >> > or,
>> >> if
>> >> > you're inclined, open a PR...
>> >> >
>> >> > This is perfectly legal C99. That's 20+ years ago and was widely
>> >> > accepted
>> >> > > before then.
>> >> >
>> >> >
>> >> > That's true; however this standard and code style are well
>> >> > established
>> >> > in
>> >> > this project; of course anyone can feel free to open a [DISCUSS]
>> thread
>> >> to
>> >> > propose changes but the onus is obviously on them to persuade the
>> >> community
>> >> > why it should make those changes.
>> >> >
>> >> > I see // comments in 48 *.[ch] files. That ship has sailed.
>> >> >
>> >> >
>> >> > That, too, is a bug and should be fixed.
>> >> >
>> >> > So I've kicked that back in, but it appears I have to wait for a
>> (gasp)
>> >> > > human
>> >> > > to push a button. I assume this is to stop script kiddies from
>> >> submitting
>> >> > > bitcoin
>> >> > > harvesters in the presubmit, but it really hoses a workflow as
>> >> > > it's
>> >> like
>> >> > > submitting
>> >> > > a box of punched cards across the table into the Holy Room where
>> >> > computing
>> >> > > is done and then awaiting a stack of greenbar with the results
>> >> > > later
>> >> > > in
>> >> > the
>> >> > > day.
>> >> >
>> >> >
>> >> > Yes, it's to stop script kiddies with their mining businesses;
>> >> > however
>> >> IIRC
>> >> > that only applies to your first PR with a project. I think once your
>> PR
>> >> > gets merged the next one will go more swiftly.
>> >> >
>> >> > Hopefully, you're convinced I'm an actual human at this point (even
>> >> > if
>> >> > I
>> >> > > complain
>> >> > > too much :-)
>> >> >
>> >> >
>> >> > Nope. I'm not convinced. :-p
>> >> >
>> >> > Jokes aside your participation is greatly appreciated.
>> >> >
>> >> > Cheers,
>> >> > Nathan
>> >> >
>> >>
>> >
>>
>

Re: Introduction + incoming RISC-V port(s)

[Grr <ge...@gmail.com>]

El mar, 3 ago 2021 a las 6:49, Alan Carvalho de Assis (<ac...@gmail.com>)
escribió:

> Unfortunately NuttX is not for faint of heart people (same to the
> Linux kernel)

I don't know about Linux but what makes NuttX not for the faint of heart is
you, the core programmers. I explain why:

*Config Nightmare*
NuttX menuconfig is a minefield. The first time I tried to test NuttX,
selecting desired options caused a compilation crash because there are a
lot of broken combinations (I fixed 4 or 5 to flex my muscles), especially
regarding networking. When I *repeatedly* talked about making it easier for
newbies, nobody even blinked and when I came with a GPIO subsystem that
allows easy configuration via menuconfig, you showed complete lack of
interest

*Balkanization*
Device support in NuttX is ludicrous. If I want to connect an SPI device
like MCP2515 to a *supported random board*, I have to port the driver
because the existing driver is tied to Blue Pill and one or two other
boards. As anyone understands, a supported SPI peripheral *should* work
with *any* supported board because a driver should work at bus level, *not*
board level. If I'm a newbie that doesn't want or can go that deep, I'm SOL

*Double Standards*
I tried to correct the situation and developed a new SPI subsystem that
doesn't tie drivers to a specific board, just to clash into header file
mess: with the excuse of modularity, header files are mixed with source
files, making it very difficult (I suspect on purpose) to build a
board-agnostic driver system

Of course, modularity is something for *others* to observe. The leader can
enforce modularity and at the same time recommend to use internal
interfaces when needed (
https://www.mail-archive.com/dev@nuttx.apache.org/msg05752.html)

*Networking Phobia*
Back in 2015, I asked about SocketCAN on NuttX (
https://nuttx.yahoogroups.narkive.com/RMKDgEcn/canopen-stack) but Nutt
didn't want to even hear about it and *ERASED MY QUESTIONS FROM NEWSGROUP*.
Five years later, Nutt was deploring that SocketCAN port to NuttX was
rusting in a branch. And this schizophrenic attitude towards networking
shows in NuttX

In sum, it's not that NuttX is hard. It's that *NuttX IS MADE HARD,
PROBABLY ON PURPOSE*

In that scenario, Robert's position is perfectly understandable and even
advisable. I myself will follow suit and go to a better RTOS, where I don't
have to fight against everything to get the work done. I've wasted enough
time

Good bye


> I know you are not an stupid guy and you have great
> projects under your belt, but think also about your attitudes here.
> Read again all the complains you did in your emails and imagine the
> other side of your computer are few guys that spend years of their
> life making that code.
>
> BR,
>
> Alan
>
> On 8/3/21, Robert Lipe <ro...@gmail.com> wrote:
> > This iteration of BeagleV hardware is canceled <https://beaglev.org/>.
> > Given the friction of landing PR#3965, I'm just going to abandon it and
> > mark that CL closed and will be unsubscribing from the lists.  There's
> > probably nothing worth heroic efforts to preserve; only a few of those
> 108
> > commits were real work with the rest just feeding the machine. That basic
> > PR will be needed by the likes of  SiFive Unmatched and other RISC-V
> > hardware.
> >
> > The NuttX tech is interesting, but I spent an unreasonable amount of time
> > chasing ghosts in the build system and the culture. A style guide that's
> so
> > complex that you can't teach it to a machine and blocking submits because
> > unrelated files have C99 comments inside an embedded string is just not a
> > fit for me.
> >
> > Thanx to those of you that genuinely tried to help onboard a new dev.
> Good
> > luck to the project on your journey to be accepted by Apache.
> >
> > RJL
> >
> > On Wed, Jun 23, 2021 at 10:03 AM Abdelatif Guettouche <
> > abdelatif.guettouche@gmail.com> wrote:
> >
> >> *So I've kicked that back in, but it appears I have to wait for a
> >> (gasp)human**to push a button*.
> >>
> >> This is actually a Github thing and is outside of our control.  It's
> >> pretty
> >> new too, so we too have to get used to it.  As Nathan said, this only
> >> applies to first time contributors.  Subsequent contributions should go
> a
> >> bit smoother.
> >>
> >> On Wed, Jun 23, 2021, 3:37 PM Nathan Hartman <ha...@gmail.com>
> >> wrote:
> >>
> >> > On Tue, Jun 22, 2021 at 11:12 PM Robert Lipe <ro...@gmail.com>
> >> wrote:
> >> >
> >> > > >
> >> > > >
> >> > > > > The presubmit flips out about C99 comments. Even that's too
> >> radical.
> >> > So
> >> > > > > much for being king. :-)
> >> > > >
> >> > > > You can use C99, but you cannot forgot to follow the Coding Style,
> >> > > > //
> >> > > > comments shouldn't be used :-)
> >> > > >
> >> > >
> >> > > It's actually worse than that. You can use C99 comments at the end
> of
> >> > > a
> >> > > line
> >> > > but not at the beginning
> >> > >
> >> > > frobnicate();  // this is accepted
> >> > > // this is an error
> >> >
> >> >
> >> > That is a bug in nxstyle.c and should be fixed. Please file an issue
> >> > or,
> >> if
> >> > you're inclined, open a PR...
> >> >
> >> > This is perfectly legal C99. That's 20+ years ago and was widely
> >> > accepted
> >> > > before then.
> >> >
> >> >
> >> > That's true; however this standard and code style are well established
> >> > in
> >> > this project; of course anyone can feel free to open a [DISCUSS]
> thread
> >> to
> >> > propose changes but the onus is obviously on them to persuade the
> >> community
> >> > why it should make those changes.
> >> >
> >> > I see // comments in 48 *.[ch] files. That ship has sailed.
> >> >
> >> >
> >> > That, too, is a bug and should be fixed.
> >> >
> >> > So I've kicked that back in, but it appears I have to wait for a
> (gasp)
> >> > > human
> >> > > to push a button. I assume this is to stop script kiddies from
> >> submitting
> >> > > bitcoin
> >> > > harvesters in the presubmit, but it really hoses a workflow as it's
> >> like
> >> > > submitting
> >> > > a box of punched cards across the table into the Holy Room where
> >> > computing
> >> > > is done and then awaiting a stack of greenbar with the results later
> >> > > in
> >> > the
> >> > > day.
> >> >
> >> >
> >> > Yes, it's to stop script kiddies with their mining businesses; however
> >> IIRC
> >> > that only applies to your first PR with a project. I think once your
> PR
> >> > gets merged the next one will go more swiftly.
> >> >
> >> > Hopefully, you're convinced I'm an actual human at this point (even if
> >> > I
> >> > > complain
> >> > > too much :-)
> >> >
> >> >
> >> > Nope. I'm not convinced. :-p
> >> >
> >> > Jokes aside your participation is greatly appreciated.
> >> >
> >> > Cheers,
> >> > Nathan
> >> >
> >>
> >
>

Re: Introduction + incoming RISC-V port(s)

[Alan Carvalho de Assis <ac...@gmail.com>]

Hi Robert,

We all here appreciate your effort to make it happen, but I think you
also started things very badly.

No matter what was your previous culture, we never arrive at someone
home and start talking bad things about their furniture and/or their
children. We all here was very patience to you and ignored it until at
the last minute.

Many people doesn't like the Coding Style that mister Greg created,
but it was his decision and more important than the coding style
defined is that it makes things consistent. I don't like the MISRA C,
but if I'm going to create source code for automotive industry I need
to follow it.

Unfortunately NuttX is not for faint of heart people (same to the
Linux kernel), I know you are not an stupid guy and you have great
projects under your belt, but think also about your attitudes here.
Read again all the complains you did in your emails and imagine the
other side of your computer are few guys that spend years of their
life making that code.

BR,

Alan

On 8/3/21, Robert Lipe <ro...@gmail.com> wrote:
> This iteration of BeagleV hardware is canceled <https://beaglev.org/>.
> Given the friction of landing PR#3965, I'm just going to abandon it and
> mark that CL closed and will be unsubscribing from the lists.  There's
> probably nothing worth heroic efforts to preserve; only a few of those 108
> commits were real work with the rest just feeding the machine. That basic
> PR will be needed by the likes of  SiFive Unmatched and other RISC-V
> hardware.
>
> The NuttX tech is interesting, but I spent an unreasonable amount of time
> chasing ghosts in the build system and the culture. A style guide that's so
> complex that you can't teach it to a machine and blocking submits because
> unrelated files have C99 comments inside an embedded string is just not a
> fit for me.
>
> Thanx to those of you that genuinely tried to help onboard a new dev. Good
> luck to the project on your journey to be accepted by Apache.
>
> RJL
>
> On Wed, Jun 23, 2021 at 10:03 AM Abdelatif Guettouche <
> abdelatif.guettouche@gmail.com> wrote:
>
>> *So I've kicked that back in, but it appears I have to wait for a
>> (gasp)human**to push a button*.
>>
>> This is actually a Github thing and is outside of our control.  It's
>> pretty
>> new too, so we too have to get used to it.  As Nathan said, this only
>> applies to first time contributors.  Subsequent contributions should go a
>> bit smoother.
>>
>> On Wed, Jun 23, 2021, 3:37 PM Nathan Hartman <ha...@gmail.com>
>> wrote:
>>
>> > On Tue, Jun 22, 2021 at 11:12 PM Robert Lipe <ro...@gmail.com>
>> wrote:
>> >
>> > > >
>> > > >
>> > > > > The presubmit flips out about C99 comments. Even that's too
>> radical.
>> > So
>> > > > > much for being king. :-)
>> > > >
>> > > > You can use C99, but you cannot forgot to follow the Coding Style,
>> > > > //
>> > > > comments shouldn't be used :-)
>> > > >
>> > >
>> > > It's actually worse than that. You can use C99 comments at the end of
>> > > a
>> > > line
>> > > but not at the beginning
>> > >
>> > > frobnicate();  // this is accepted
>> > > // this is an error
>> >
>> >
>> > That is a bug in nxstyle.c and should be fixed. Please file an issue
>> > or,
>> if
>> > you're inclined, open a PR...
>> >
>> > This is perfectly legal C99. That's 20+ years ago and was widely
>> > accepted
>> > > before then.
>> >
>> >
>> > That's true; however this standard and code style are well established
>> > in
>> > this project; of course anyone can feel free to open a [DISCUSS] thread
>> to
>> > propose changes but the onus is obviously on them to persuade the
>> community
>> > why it should make those changes.
>> >
>> > I see // comments in 48 *.[ch] files. That ship has sailed.
>> >
>> >
>> > That, too, is a bug and should be fixed.
>> >
>> > So I've kicked that back in, but it appears I have to wait for a (gasp)
>> > > human
>> > > to push a button. I assume this is to stop script kiddies from
>> submitting
>> > > bitcoin
>> > > harvesters in the presubmit, but it really hoses a workflow as it's
>> like
>> > > submitting
>> > > a box of punched cards across the table into the Holy Room where
>> > computing
>> > > is done and then awaiting a stack of greenbar with the results later
>> > > in
>> > the
>> > > day.
>> >
>> >
>> > Yes, it's to stop script kiddies with their mining businesses; however
>> IIRC
>> > that only applies to your first PR with a project. I think once your PR
>> > gets merged the next one will go more swiftly.
>> >
>> > Hopefully, you're convinced I'm an actual human at this point (even if
>> > I
>> > > complain
>> > > too much :-)
>> >
>> >
>> > Nope. I'm not convinced. :-p
>> >
>> > Jokes aside your participation is greatly appreciated.
>> >
>> > Cheers,
>> > Nathan
>> >
>>
>