Ah, just the autorebuild part: DOCUMENTATION — NUTTX LATEST DOCUMENTATION https://nuttx.apache.org/docs/latest/contributing/documentation.html#live-rebuild
For me, I was doing the work in VSCode also and just having my browser on the side where the preview would be. __ Ludovic Vanasse [email protected] On 2025-11-26T15:09:16.000-05:00, Tim Hardisty <[email protected]> wrote: > I simply follow: > https://nuttx.apache.org/docs/latest/contributing/documentation.html > > This is a PITA as you can't just make a change and expect it to be OK. I > started working on a simple documentation mod just the other day - in VS > Code - but the RST previewers online or within VS Code failed to render > the ^ subsubsection as expected. Can do without that hassle. > > Maybe there's a better editor for documentation than what I'm using - > and not sure, really, what you are referring to here? > > On 26/11/2025 20:01, Ludovic Vanasse wrote: >> Having done a bit of documentation rework in the past. There's a >> hot reload function in the documentation generation. It'll start a >> rebuild and refresh the page with the new edit. I thought it was >> pretty convenient on my machine and we have the Nix devshell for >> it also, so no need to install anything else than Nix.. Hope this >> helps :). __ Ludovic Vanasse [email protected] On >> 2025-11-26T14:06:54.000-05:00, Tim Hardisty >> <[email protected]> wrote: >> >>> This would need only a trivial change to documentation, which >>> then doesn't need a full RST build/check I would think. On >>> 26/11/2025 19:04, Tim Hardisty wrote: >>> >>>> Think my message passed yours in the ether...yes; that's what >>>> I'm suggesting :-) On 26/11/2025 19:02, Alan C. Assis wrote: >>>> >>>>> I think what we are calling "Strict Priority" is defined by >>>>> POSIX as SCHED_FIFO. SCHED_FIFO: The thread runs until it >>>>> blocks itself or it is preempted by a higher priority >>>>> thread. (This is what you want). SCHED_RR: The thread runs >>>>> until the above happens *OR* its time slice (200ms) expires. >>>>> So, we could create a choice in the menuconfig with these >>>>> three options: SCHED_FIFO SCHED_RR SCHED_SPORADIC If >>>>> SCHED_FIFO is selected, the RR_INTERVAL is set to 0. If >>>>> SCHED_RR is selected the option to set RR_INTERVAL value >>>>> will show up. What do you think? BR, Alan On Wed, Nov 26, >>>>> 2025 at 3:40 PM Alan C. Assis <[email protected]> wrote: >>>>> >>>>>> Do you suggest moving from RST to Markdown? I think >>>>>> SCHED_PRIORITY is not a standard definition, at least I >>>>>> didn't find it in POSIX. You can propose using RR slice >>>>>> equal 0 by default, but I don't know the side effects (it >>>>>> could be considered a breaking change, because some user >>>>>> applications could stop working or behave strangely). BR, >>>>>> Alan On Wed, Nov 26, 2025 at 3:27 PM Tim Hardisty >>>>>> <[email protected]> wrote: >>>>>> >>>>>>> I don't mind doing documentation - but it does take a >>>>>>> lot more effort since RST doesn't have very good >>>>>>> previewers that I have found: it is difficult to know if >>>>>>> will it render correctly on the website unless you do >>>>>>> the whole RST build stuff. Quicker - if agreeable as a >>>>>>> short term fix - would be to add a Kconfig option to >>>>>>> specifically choose the scheduling option, with an >>>>>>> appropriate CONFIG_RR_INTERVAL setting of 0 for >>>>>>> SCHED_PRIORITY or 200ms for SCHED_RR? That would mean no >>>>>>> code changes as such? Something like that anyway. If it >>>>>>> fixes my issue, I can play with this and do a PR On >>>>>>> 26/11/2025 18:16, Alan C. Assis wrote: >>>>>>> >>>>>>>> Guess what? We are still missing a proper >>>>>>>> Documentation! :-) BR, Alan On Wed, Nov 26, 2025 at >>>>>>>> 3:11 PM Tim Hardisty <[email protected]> wrote: >>>>>>>> >>>>>>>>> So do we agree the documentation is at best >>>>>>>>> misleading? And, to me, simply wrong? On 26/11/2025 >>>>>>>>> 18:07, Alan C. Assis wrote: >>>>>>>>> >>>>>>>>>> Exactly! You can refer to >>>>>>>>>> sched/sched/sched_timerexpiration.c line 207 On >>>>>>>>>> Wed, Nov 26, 2025 at 3:00 PM Tim Hardisty >>>>>>>>>> <[email protected] wrote: >>>>>>>>>> >>>>>>>>>>> That's what I inferred (yet to try it) - so is >>>>>>>>>>> the documentation misleading since the default >>>>>>>>>>> CONFIG_RR_INTERVAL=200 forces RR >>>>>>> scheduling >>>>>>> >>>>>>>>>>> rather than the stated "strict priority >>>>>>>>>>> scheduling"? On 26/11/2025 17:54, Alan C. Assis >>>>>>>>>>> wrote: >>>>>>>>>>> >>>>>>>>>>>> CONFIG_RR_INTERVAL=0 On Wed, Nov 26, 2025 at >>>>>>>>>>>> 2:22 PM Tim Hardisty < >>>>>>> [email protected]> >>>>>>> >>>>>>>>>>>> wrote: >>>>>>>>>>>> >>>>>>>>>>>>> Apologies if this isn't really a NuttX >>>>>>>>>>>>> question... Documentation says "By default, >>>>>>>>>>>>> NuttX performs strict priority >>>>>>>>>>> scheduling". >>>>>>>>>>> >>>>>>>>>>>>> Default CONFIG_RR_INTERVAL is 200ms. I have >>>>>>>>>>>>> multiple threads, but have not set any >>>>>>>>>>>>> scheduling >>>>>>> parameters, >>>>>>> >>>>>>>>> but >>>>>>>>> >>>>>>>>>>>>> it seems threads are being scheduled every >>>>>>>>>>>>> 200ms rather on a >>>>>>> priority >>>>>>> >>>>>>>>>>>>> basis. What *should* I be doing, please, to >>>>>>>>>>>>> get all my threads scheduled >>>>>>> by >>>>>>> >>>>>>>>>>>>> priority? Thanks, TimH PS - yes I have >>>>>>>>>>>>> thrown myself in the deep end without a life >>>>>>>>>>>>> jacket >>>>>>>>> with >>>>>>>>> >>>>>>>>>>>>> my project. And I'm no doubt up ****-creek >>>>>>>>>>>>> without a paddle. But I >>>>>>> am >>>>>>> >>>>>>>>>>>>> always learning!
