Hello all,
It been a while since the last time that I have contributed and I see that a lot of things were added (nice and thank you all), but now it is much more difficult to navigate the project.
First of all, I suggest to move all the source code directories and files into a separate directory named source or code
Secondly, I think that some of the source can be moved into libs and the other part can be split into more directories for comfort.
I am willing to make these changes myself and commit them to the main branch, but first I want general approval before going into this hassle.
Can you help me understand what you mean by “difficult to navigate” and “for comfort”?
Please be more specific … and break this massive change into smaller parts. e.g., rather than “other parts can be split into more directories for comfort”, propose a solution such as:
"I propose moving files for the dummy modes into an “Example” subdirectory, with a separate readme.md that explains what changes need to be made to that file to add a brand new mode from scratch.
The more specific your proposal, the greater likelihood you will get productive answers.
considerations for you ...
There are lots of different opinions on code styles, code layouts, tabs vs. spaces, CMake vs. … you get the picture. “Comfort” is also a subjective term, so hard to argue for/against as it differs between folks.
Thus, my questions are to help you lock down what problem you are trying to address in the code, to show that the problem affects everyone, and that the change is worth the costs.
Without doubt, I also prefer code not to live in root. However, this doesn’t inherently affect my own ability to navigate the code. I use tools such as VSCode to be able to jump to definitions, find uses of variables, etc. Those “just work” in this project.
Would changing locations externalize a cost? e.g., would everyone else need to re-learn the new location? Sometimes this is worthwhile, but always there is a cost.
Even if you do this, take it in small, bite-size changes. Spread it out over weeks, so that branches have time to integrate changes. Make each of your commits small (specifically, merge-friendly). etc.
Why is it beneficial to have multiple libs? Why is it beneficial to move to a different directory structure? What specific new structure would you be proposing?
Part of the sorting could be realized only while conducting the actual sorting.
Maybe I was too generalized.
So it is hard to distinguish in the root directory between files related to source, build system documentation and so on.
So at first all code must go into a separate sub-dir that will be the root dir of the source code.
In the code dir I suggest the following general distinctions:
Boot - all initial bootstrap and main function
Hal (Hardware Abstraction Layer) - all the code that directly communicate with hardware interface, including FS drivers.
Pirate - general code that is part of the BP interface available to users
Lib - independent code that implements unique functionality
This is my main point. Maybe it is better to do gradual change and after committing this sorting then we will figure out how to further divide the code.
This is a bad habit, if one wants better general understanding of the code base, then the code base must be better sorted so it will be easier to know what which part does and how they are related
I am all for sorting, and totally understand what you mean by “you don’t know until you get in there”.
The code reflects several efforts I made to tame the old PIC code into a test firmware for 5. I started off with an idea how to structure everything, but then I didn’t really know what would happen until I got in there and started writing. For example, the idea of having commands/apps with optional argument flags, or even the live updated toolbar, none of that occurred to me when I started coding. It only came during the process of learning what was possible.
My usual habit is to get to what feels like a point release, and then afterwards spend a week or so refactoring things and handling user bugs. That’s how the pirate folder came into being, with base functions for interacting with the hardware. That’s not so relevant here though because we have continuous releases.
The only think I’d like to do before a big reorg is make sure we have @henrygab 's most important quality of life updates merged. There was a ton of stuff in there I planed to get to myself, but he had already picked up on it. I believe the reorg of the system_config, moving the functions for pin reservation/release elsewhere (could be remembering wrong).
Lersi, are you aware how the above statement comes across?
Notice my response to your initial post … I started with questions to better understand your position.
Do you really want to muddy your positive contributions with what could reasonably be interpreted as personal attacks on the very folks who are trying to help you reach your goal?
How could you have written that?
Old:
Alternative:
I find it helpful for my own general understanding of a code base to not rely on such tools. For me, this means I benefit from a code base that has files logically grouped into a directory structure based on what they do.
Notice how the alternative avoids attacking, and avoids blanket statements that “X is right for everyone”.
I’m looking forward to your help, btw … I hope to see many PRs from you that improve the state of this project.
P.S. - I am intentionally NOT addressing whether use of tooling is actually a “good” or “bad” habit, helpful or harmful, etc. … even assuming arguendo that a single answer could apply universally.
I only have one QoL PR outstanding, and it’s for the RP2350 branch. However, I always expect that some of the concepts may be asked to be excluded … so let me know if any of the changes rub you the wrong way, and I will modify the PR to match your preferences.
As an obvious example: single file per line in CMakefiles.txt … will make diffs easier to merge / rebase against, but maybe not worth your effort to review).
That said, I tried to ensure each commit was conceptually focused and small, so review on a per-commit basis may be easiest for you?
Sorry, did not meant to harm anyone, I am still seeing it as non-offensive comment.
I do not see this as a personal offense rather as a criticism. I do not mean to harm anyone even personally, sorry that you understand it that way.
I provided some explanation after the comment but as usual I probably did not explain that well. My point was that to use the benefits modern tools give you as an excuse to a messy code and a messy repository is a bad habit.
Personally I do not care which tools you are using use vscode or use notepad, I really do not care.
At the end no body is after you, better avoid bullies and put their comments a side. There is no reason to make huge story out of a misplaced comment.