Closed ObiKeahloa closed 2 years ago
ObiKeahloa
commented
3 years ago By "testing" I mean with another simple program I made in C++ (Yes I know not C ) it seemed to be saving atleast a few KBs.
Battery management will also become a problem in the near future.
Avamander
commented
3 years ago We could try to make a system in a server that automatically takes new PR's (Pull Requests) and does code optimization , then give it as a review edit.
Yes, unit testing is a thing that could be done. Same goes with code linting and formatting. Things are ready for the last two as I created .clang-format and .clang-tidy configuration files.
Having a better memory allocating system (The system shouldn't take extra space , that will defeat the purpose.)
Optimizing the amount of RAM allocated to FreeRTOS tasks can be done, but requires work. I think there's an issue by JF002 about this.
ObiKeahloa
commented
3 years ago Yes there is an issue by JF002 about the RTOS memory management.
JF002
commented
3 years ago Hi @MysteriousLog6 and thank you for these suggestions!
Regarding project management: Any help on that subject is welcome! It's the first time I'm the creator/maintainer of an open-source project that receives so many feedbacks and contributions, and, even if I do my best, I don't know how to fulfill that job correctly! These last few weeks, and especially since the announcement of 1.0, the activity on this repo has exploded, and I clearly became the bottleneck to review and merge PR, fix bugs, answer to questions,...
Regarding memory management: Yes, our internal memories (RAM and FLASH) and quite full, and we've not implemented (yet) a way to easily use the external flash memory. For this, I created a Github Project so we can centralize brainstorms, fixes and work related to memory management. Feel free to create an issue/pr if you think you can help!
Note that it's not the code that take the most of the space. The flash space is mainly used by graphical assets (fonts, icons, graphics,...). Trying to reduce the code will probably help us, but not that much. FreeRTOS, LVGL and NimBLE probably use a significant part of the memory but... I don't think we want to rewrite them from scratch... They are complex pieces of code and they do their job very well. I doubt we'll be able to do better than these folks working on these projects!
ObiKeahloa
commented
3 years ago Project Management:
We could make a few people be grouped for specific things , lets say there is a pull request regarding a new feature:
The same system can be followed for other pull requests too , the grouping can be done as a separate discussion with people who would want to be members , we could also bias (As in favor them ) towards users who have already made pull requests that are functional and loved by the community.
We could also turn on the "Discussions" tab in the InfiniTime Repo thus preventing extra issue's from being created by people who are having trouble. (Perfect example being this very post)
A group that is responsible for management of the repo (Updating documentation , Fixing spelling errors etc.) could be added.
But this all boils down to the availability of people , if enough are available the new problem is that we have to do scheduling of the teams otherwise @JF002 will again become the bottleneck.
ObiKeahloa
commented
3 years ago Storage Management: We could move the assets to the External SPI flash memory , if possible we could also use a compression algorithm for the assets.
We could also think of moving away from LVGL to another alternative (If there are any that are better than LVGL) .
These are all that I could come up with right now but will try to find more.
JF002
commented
3 years ago him/her
him suits me well :)
@MysteriousLog6 regarding project management, this is more or less what we are doing now, but is a much less formal way. Anyone is welcome to review, test and comment PRs, and I welcome this kind of help.
But yeah, there's no group of people with specific subject of attention (PR, doc,...). I don't think Github provides a way to create groups of contributors with specific permissions on the repo (at least, not on private repos).
I don't know that "discussions" tab, but I'll have a look right now!
Regarding storage : yes, moving assets (bitmaps, fonts, icons) to the spi flash memory is probably one of the main solution to implement to free a lot of space on the internal memory. We are currently brainstorming about it here : https://github.com/JF002/InfiniTime/issues/321.
ObiKeahloa
commented
3 years ago But yeah, there's no group of people with specific subject of attention (PR, doc,...). I don't think Github provides a way to create groups of contributors with specific permissions on the repo (at least, not on private repos).
We could assign badges to people (Might be possible) who are interested in these groups , they will still have to inform you about the pull request so that you merge it thus them not needing write access.
pfeerick
commented
3 years ago Discussion needs to be explicitly turned on and is a relatively new feature that started coming online for public repos about this time last year. You can see it in action here... https://github.com/arendst/Tasmota/discussions
To have granular control of permissions... you would need to transfer the repo from an owner account, to a organisation account. I ended up creating two organisation accounts when doing pine64/rock64 PRs, due to the upstream repos being forks of forks, and not being able to have multiple forked repos under the one account. One of the sillier GitHub limitations. Otherwise, you can only have collaborators, who have a lot of the same access and control as the owner.
Taking Avamander's clang-format the logical next step, and having it run as part of a GitHub Action for PRs would be good also... there would then be not 'guessing' as to whether code was formatted correctly, or if it isn't, what changes are needed. You'd get a tick or a cross, and have the log to review.
Avamander
commented
3 years ago Discussion needs to be explicitly turned on and is a relatively new feature that started coming online for public repos about this time last year. You can see it in action here... https://github.com/arendst/Tasmota/discussions
I'm not sure it's a better format than the issue tracker. IMO quite a few initial discussions turn into real Issues and vice versa, it's part of triage to determine and label those as such. We don't really gain anything by splitting either attention or the two categories into two (or more places).
pfeerick
commented
3 years ago Agreed... if there wasn't already the bridged discord/matrix/telegram/IRC chat, and also the pinetime forum, then it would be perfectly suitable, as it can be used as a forum in it's own right, but to add that now would just divide attention even more.
ObiKeahloa
commented
3 years ago Agreed... if there wasn't already the bridged discord/matrix/telegram/IRC chat, and also the pinetime forum, then it would be perfectly suitable, as it can be used as a forum in it's own right, but to add that now would just divide attention even more.
Not everybody has these , Discord/Matrix/IRC Chat and Pine Time Forum.
ObiKeahloa
commented
3 years ago About code in Pull Request Management will this help?
https://github.com/marketplace/codefactor
@Avamander @pfeerick @JF002
Pull Request Management:: As the project becomes larger and larger more and more pullrequests will come with varying code , which can both be an upside (More efficient and creative code can be added) and a downside (Maybe bad code will be accidentally added).
We could try to make a system in a server that automatically takes new PR's (Pull Requests) and does code optimization , then give it as a review edit.
This needs more time and a few other brains as this will become a big issue (Huh , now that I think about it so will the bottom one.)
Memory Management::
The device seems to be only having 512KB (There is an extra 4MB of SPI storage , the 4MB for data storage) of inbuilt storage and 64KB of RAM.
This is pretty limiting (Atleast to me , used to being able to have GB's/MB's of ram....) but we have been able to do a lot with the limited amount of specs.
How we can improve(Maybe , not sure): Having a better memory allocating system (The system shouldn't take extra space , that will defeat the purpose.) Merging more of the Apps into smaller codebases and smaller files.(Not sure how much this will help but in my testing it helps a little teeny tiny bit.). Trying to use compiler optimizations (Not sure maybe used already?) Making our own replacements of specific parts of other software we use(Or maybe the entire thing). (LVGL , mynewt-nimble and FreeRTOS).
These are the only things I thought needs to improved a lot , specially the Memory Management.