Introducing compile-time apps modularity #73
Conversation
|
|
boricj
force-pushed
the
compile_time_apps_modularity
branch
2 times, most recently
from
9fcf96a
to
0eab8e5
Compare
|
Great job, it makes the whole system more "dynamically manageable" - I hope this gets merged eventually :) |
boricj
force-pushed
the
compile_time_apps_modularity
branch
3 times, most recently
from
8fe8227
to
6d5f77f
Compare
|
OK, so this should be in good enough shape now for a proper review. I should probably code a third-party app to illustrate how all of this works in practice, but that can wait later. We could go as far as modularizing the support libraries too (python, poincare) so that we could for example replace Python with Lua without wasting Flash space in the process, but that's probably way overkill for now. |
|
That part is to both enforce a globally unique name for all apps (like Android) and have a directory structure that naturally prevents conflicts between apps. For example, if I create a third-party app for a periodic table hosted at https://github.com/boricj/periodic-table, I would give it the URI If adriweb then creates another completely different periodic table app hosted on GitHub too, there's no way either of them will be in conflict at this layer (obviously, they could still butthead on symbol redefinition or something else). Without that URI scheme, if two people come up with the I agree this may be a bit of over-engineering on my part, but it makes things as plug'n play as it gets. |
I'd argue that apps will have to have their own namespace as to avoid this - and I don't think there's a need for any extern "C" functions? |
|
Yes, C++ namespaces will be needed to prevent apps from stepping on each other's toes, but it remains to be seen how this will unfold. After all, homebrew apps integrated to the firmware at compile-time is not the usual way things are done in the calculator world. But even if the firmware architecture changes towards run-time apps down the road where such issues won't happen, it'll be some time before that happens. The last technical barrier is translation. Apps can't just pretend that they don't exist since the app Descriptor class returns identifiers to be translated and those are currently centralized. Obviously we can't embed translations for every third-party app ever in-tree, so I need to come up with a cunning plan that won't end up in rebasing disaster territory. |
boricj
force-pushed
the
compile_time_apps_modularity
branch
2 times, most recently
from
2b87b55
to
45bbd88
Compare
|
Alright, so translation reworking is done and it should be able to handle out-of-tree apps now. After this is merged, app-specific translations should be moved to their respective app directories in order not to bundle them if the relevant app is not selected, but I'd rather keep rebasing of this branch as painless as possible. |
|
Nice! |
boricj
force-pushed
the
compile_time_apps_modularity
branch
from
45bbd88
to
43236b0
Compare
|
I dropped the |
Note that this will not compile. The rest of the source code is adapted to the new translation scheme in another commit to ease rebasing.
To regenerate this commit, use the following Shell snippet:
for i in $(seq 1 20); do
for i in '*.cpp' '*.h'; do
find . -name $i | xargs sed -i 's|I18n::Message::|\&I18n::Common::|'
find . -name $i | xargs sed -i 's|(I18n::Message)0|\&I18n::NullMessage|'
find . -name $i | xargs sed -i 's|I18n::Message |const I18n::Message*|'
done
done
for i in $(seq 1 20); do
for i in '*.cpp' '*.h'; do
find . -name $i | xargs sed -i 's|const I18n::Message\*|const I18n::Message \*|'
done
done
boricj
force-pushed
the
compile_time_apps_modularity
branch
from
43236b0
to
ae1a4dd
Compare
|
All right, here's the first ever third-party app for NumWorks: https://github.com/boricj/numworks-hello-world. Not much to look at, but it proves this pull request actually works as intended. One issue to note is that the home view goes crazy if all nine apps are built. It's probably a good idea to modify it so that it scrolls up/down instead of left/right. |
boricj
changed the title
boricj
force-pushed
the
compile_time_apps_modularity
branch
2 times, most recently
from
551f3a6
to
f700a6b
Compare
boricj
force-pushed
the
compile_time_apps_modularity
branch
from
f700a6b
to
0a9a787
Compare
|
The With all outstanding issues out of the way, this pull request is now ready to be a candidate for merging. There are a couple of glitches with the home screen when there is a certain number of apps, but that's a separate problem. |
|
After chatting a bit on IRC, it became apparent that this pull request is a bit on the heavy side. @Ecco would you prefer for me to break it down into smaller pull requests, one at a time? Also, if somebody could confirm this works on the hardware that would be great. |
|
Hi @boricj ! First of all, a big thank you, both for your work and your positive mindset. The current PR is indeed a bit big, but in my opinion that's not the biggest issue. Having smaller PRs would indeed make the review/merge cycle faster though. If you don't mind, here are the issues I have with this PR:
I think the first thing we should focus on is being able to select which Epsilon apps are included in a build. We'll then add on this to make i18n more flexible and allow for third-party apps. To achieve this, I think the best approach would be as follow:
|
|
OK then. Considering that:
it's probably best to close this pull request, keep the branch around as a proof-of-concept, and open new, clean pull requests one at a time for each topic. I'm mostly worried about translation at this point, because reworking it is a quite involved task and I don't really have a good technical solution at hand (my hack is really more of a superficial workaround than a real solution at this point). #71 is probably a good place to discuss that topic further. |
|
Having to compile a new firmware to add apps makes this an approach for hobbyists and not a serious calculator for end users. |
|
Well then, what do you suggest? Keep in mind that there's not a lot of Flash to spare, epsilon is both fairly tightly integrated and a quickly moving target and the NumWorks team doesn't want to get burdened maintaining extra fluff without a good reason, even more so if it means providing backwards compatibility. I do believe apps written in (Micro)Python loaded at runtime without compilation/linking to be an achievable goal, unlike the same for native third-party apps, but I have a finite amount of free time to spend. |
The title says it all. The trick lies in a linked list of
App::Snapshotthat is built at run-time through constructors, each app containing a statically-declared node along with itsSnapshotinstance (instead of hard-coding everything insideAppsContainer). With some further trickery and code moving it could lay the foundations of a third-party apps ecosystem for NumWorks.As a proof-of-concept, this branch enablesApps to include are specified with theComputation,PythonandSettingsapps, disabling all other apps just by commenting them out insideapps/Makefile.APPS_LISTmake variable.Known issues:
Apps order on the home menu is pseudo-random ;The list of apps to use should be stored in an environment variable, not directly inside a Makefile ;Pythoncan't be left out without causing a linkage error ;Will have to move per-app translation strings inside apps ;