The XML-like style in StylePtr gets a bit insane when styles are pulled from places like Fett263.
I immediately Patreon supported Fett263 and started learning how to get cool StylePtr in place. Loving my new saber.
As a full-time software developer (just not C++), I naturally threw the code into my IDE to make final tweaks and learn more. The lack of code formatting is a shame. It would be huge to have a code formatted and linter on the StylePtr arguments.
I did find the style editor out there. Unfortunately, as soon as I paste styles from Fett263, it immediately fails with errors such as: Unknown identifier:ALT_COLOR3_ARG
Are there any recommended plugins, linters, code formatters for styles and ProffieOS in general?
The Style Editor would be it at the moment. Since ProffieOS is all just C++, a C++ editor would work, however for linting you’d need to make sure the rest of ProffieOS was setup and injected somehow.
Even with that though, template errors tend to be difficult to follow, and are of course not ProffieOS specific. That’d be where the Style Editor would be far more useful.
Try using this version of the Style Editor… you may have found one that’s out of date: ProffieOS Style Editor
Yeah, it has been decades since I touched C++. It does seem that it will be making a comeback in my future though. Part of me wishes I had the time to rewrite ProffieOS to Rust. Not that I have anything against C++, it is just that where I work there is more interest in Rust for service projects.
Anyway. I appreciate the direction. I think the editor link I had was very outdated.
Do you have a link to the github projector the Style Editor? It looks like it is using web assembly? My guess would be to emulate the proffieOS logic and then render the blade with webGL or something based on the LED pin outputs?
And last question on the line of development tooling.
I picked up a Diagnostic Station since I’m planning on custom building a few projects based on the Proffie chip. Proffie 3.9 Diagnostic Station
Is there a way to compile/build/upload/etc to the flash in a developer method that might be faster than just hitting upload on the Arduino App? I’m figuring not, but I thought I might check just to see if there are some shortcuts for incremental build updates or something along that line.
arduino-cli is no faster than Arduino though.
Although it can be easier to integrate into other environments, like if you want to compile from VI, EMACS, or some other smart editor.
Right, not that it’s faster to complete that process, but it can be scripted. I read the question as making things faster/more efficient via automation, I see that may not have been the focus though…
As a semi-aside, given the monolithic nature of ProffieOS, all being condensed into one .ino file (and so ultimately a single translation unit once all the arduino stuff is done), are there any possibilities at all of build caching?
As I understand it that sort of caching relies on certain build objects not changing, but if you only have one build object…
I’m also curious as to why ProffieOS is built such that there aren’t any additional .cpp files to split things up? I suppose if there’s not a way to setup LTO with Arduino tooling it could result in larger binaries? The exclusive use of headers and significant header injection has always felt weird to me.
Again though, I’m certainly a novice, so chances are there’s something I’m overlooking and/or overly simplifying.
As usual, the answer is yes AND no.
There is essentially nothing that can be cached in ProffieOS itself, however, the arduino core that is also built is generally cached.
The answer is purely historical. I had trouble getting things to work with multiple files early on, not sure if this was an Arduino problem, a documentation problem or a me problem, but I just decided to inline everything. My particular style of C++ tends to require that a large chunk of the code is inlined anyways. It works relatively well for ProffieOS because it’s small enough that inlining everything doesn’t really bother a modern computer very much, but it doesn’t scale well to large projects.
As for incremental uploads or anything like that; That’s simply not supported at this time, and wouldn’t be particularly helpful anyways since the generated code is relatively small.
