El mar, 3 ago 2021 a las 6:49, Alan Carvalho de Assis (<acas...@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 <robertl...@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.guettou...@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 <hartman.nat...@gmail.com> > >> wrote: > >> > >> > On Tue, Jun 22, 2021 at 11:12 PM Robert Lipe <robertl...@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 > >> > > >> > > >