-
Once again i appreciate the amount of time people take to actual respond to this. So I'll try not to waste to much more of your time, since i think it will probably be more meaningful discussion once i have at least a working display.
But hopeful these responses will make you slightly less worried. Granted your still rightful to be skeptical of it working. I'll probably find some big bugs once i get into this more.
But I'm very worried about copying stuff out in such a way that you then end up duplicating loads of code, because then it makes maintenance a nightmare. What if I want to change how buzz works but now there are 10 identical jswrap_banglejs_buzz implementations spread across the Espruino and alt_watch repos?
My "goal" is that it wouldn't really matter all that much how bangleJS worked. I'm trying to encapsulate hardware. So if you imagined jswrap_bangle.c without most of the defines. That's what i would like. Granted defines will still probably be used just in a slightly different way. I just want to separate the larger state machine of bangleJS from the unique features of each device.
So for you example about buzzer, i haven't tried to make it but from the states it might look like this.
- buzzer_beep()
- buzzer_buzz()
- buzzer_vibrate()
These functions would be overridable if they needed to be. Granted a thing like a IMU will probably need a more advance abstraction because it's more complicated.
So yes i also wouldn't accept the idea of if you changed the Buzzer, backlight or other hardware that it would cause a huge backlog of devices to not be useable. I understand that nobody would ever want that level of burden. Especially a open source project.
while yes it'll probably get compiled out, it just makes everything harder for developers who then have to try and follow a series of stubs to get to the actual code. This has been done in the ESP32 port and it just makes trying to work on it a nightmare
Your probably right on this. How would you feel about moving the true pure javascript stuff out.
Ex.
here to here - buzzer_beep()
You are reading a single comment by @Gordon and its replies.
Click here to read the full conversation.
user156811
@Gordon
Yes, it's a hard one - when developing something like Bangle.js I start out making it work in JS too, and then end up having to port to C. It's really just trying to get to a point where you have some device that is almost impossible to brick regardless of what you do in JS - but also even if JS could be made much much faster it's still going to struggle with things the the LCD that want to be fast (and perhaps even transfer data in the background like we do for Bangle.js)
In an ideal world I'd really like the
BOARD.pyfile to be able to describe the entire device, and to then have the relevant driver files pulled in and made to work without ifdefs everywhere - but I think in many cases these watches to strange stuff (like sharing I2C and SPI wires!) that might just make that impossible.Obviously you're welcome to do whatever you want, but I wouldn't be happy about pulling something that stubbed every function back into the main repo - while yes it'll probably get compiled out, it just makes everything harder for developers who then have to try and follow a series of stubs to get to the actual code. This has been done in the ESP32 port and it just makes trying to work on it a nightmare: https://github.com/espruino/Espruino/blob/master/targets/esp32/bluetooth.c#L258
For the actual JS functions, we have the ability to add a JSON header that overrides previous ones, and we do this on DICKENS (the Starfield Collectors Edition watch) so that could be an option for some stuff:
https://github.com/espruino/Espruino/blob/master/libs/dickens/jswrap_dickens.c#L30-L34
Personally, I think that stuff to do with the actual JS interface (like
Bangle.setOptions/etc) that's going to be mostly common should always stay injswrap_bangle.cbut if it were possible to pull out the actual hardware-related code into separate files, that would be good.But I'm very worried about copying stuff out in such a way that you then end up duplicating loads of code, because then it makes maintenance a nightmare. What if I want to change how
buzzworks but now there are 10 identicaljswrap_banglejs_buzzimplementations spread across the Espruino and alt_watch repos?In many ways just forking the repo and changing
jswrap_bangle.cfor the new watches is preferable over duplicating code over multiple different files - at least then if there's a fix for something in the main repository you stand a fighting chance of being able to merge that in - but if the code end up duplicated all over the place it's going to make keeping everything (especially if it's in a separate repo) up to date almost impossible.