My Basic

[FantasyFactory]

Hello everyone!
I'm implementing in my fork of this beautiful software, a basic interpreter (based on https://github.com/paladin-t/my_basic) is a light but very powerful interpreter.
It currently works, but they are only at the beginning.

I think it could be a very interesting feature to integrate into sharandac software.
At this moment I am working on binding the functions of the watch (alarm clock, notifications, accelerometer, touchscreen, audio, etc.) so that directly from the basic program you can interact with the watch.
Next I would like to implement as basic functions the lvgl primitives, so that I can create forms, buttons and graphics (through canvas lvgl) and also the management of the spiffs file system and the http client.

I believe that having the ability to run simple BASIC programs could open up the possibility of playing with the watch even to people who don't know C and don't want to delve into complex software like sharandac's. (I think about educational purpose)

In addition, it would be very nice to think of implementing a kind of "app store", in which anyone could upload their "basic app" to a common repository and anyone could download it directly to the watch and run it.

If anyone wants to help me on my fork I would be happy, but I would like this thing to become the common heritage of the sharandac project.

[jakub-vesely]

Dear FantasyFactory,
Your example looks good and I can imagine how you enjoyed the work on the interpreter. I would like to wish you good luck and endurance because I guess you are at the begging of a long journey.

I just would like to highlight possibility to use an interpreter that is already done. e.g. Lua which is powerful stable and very well documented. I tested usage of LUA on another project based on ESP32 and it seems that it is feasible.
https://github.com/jakub-vesely/HuGo

Of course, some effort will be necessary to integrate LUA into My-TTGO-Watch as well but you can focus on interface only. interpreter is already done.

To use an interpreter for apps is great idea. They could be downloaded dynamically to SPIFFS and everyone could upload
only the ones he/she wants. Unrequited apps would not take the space in the program memory. The question is whether binary size of the c/interpreter interfaces would not take more space actually. Depends on number of available apps.

I'm sorry, for not really positive feedback, I try to be constructive. Let me know, if you are interested in more details regarding to usage of LUA.

Have a good fun, Jakub

p.s. I'm sorry for so hasty, conclusions. After additional searching information regarding to my_basic, I have to say that it is also well documented and probably stable. It seems, it is under development many years.

[BecVision]

Very good idea, I programmed in 1982 ~ years in basic (Sinclair ZX81 & Spectrum), today's level is already high for me .. :)

[FantasyFactory]

I've also made my first steps in programming with ZX81

[zenflow]

@jakub-vesely What do you think about JavaScript as the scripting language? I think it would be a great choice because it's high-level and most programmers are at least familiar with it, if not experienced with it. Probably Google's V8 engine is a bit bulky for the device, but I think quickjs could work beautifully.

[FantasyFactory]

I have evaluated several possibilities, surely javascript or micropython are better languages ​​from all points of view, but micropython is very heavy, and for QuickJs a complete porting should be done which I don't have the time to do, also QuickJs should be reduced to essential functionalities and this would nullify the possibility of using standard libraries etc ... both micropython and a possible porting of QuickJs would not allow to use common codes on the clock, I think about the complexity of implementing Ajax just to give an example.
This basic interpreter (https://github.com/paladin-t/my_basic) is very powerful, supports prototype based programming, lambda astractions, classes, collections, is easily extendable and is very light and fast and easy to learn and to be used for simple scrips or games also for educational purpose. These are the reasons for the choice

[zenflow]

For JavaScript we also have this option: https://github.com/neonious/lowjs

[zenflow]

Another option for JavaScript: https://github.com/Moddable-OpenSource/moddable

[zenflow]

This basic interpreter (https://github.com/paladin-t/my_basic) is very powerful, supports prototype based programming, lambda astractions, classes, collections, is easily extendable and is very light and fast and easy to learn and to be used for simple scrips or games also for educational purpose. These are the reasons for the choice

@FantasyFactory It would work with this language, and be awesome, but I just think it would be even more awesome if it was a more common language since:

1. Developer familiarity - A high proportion of developers are already experienced with JS and Python, so they would be more efficient & comfortable using one of those
2. Mature ecosystems - There are tons of libraries and tools available for JS and python, to get things done quickly & without reinventing the wheel. With a language like my-basic I can see myself porting a lot of libraries to that language.

[zenflow]

I have evaluated several possibilities, surely javascript or micropython are better languages ​​from all points of view, but micropython is very heavy, and for QuickJs a complete porting should be done which I don't have the time to do, also QuickJs should be reduced to essential functionalities and this would nullify the possibility of using standard libraries etc ... both micropython and a possible porting of QuickJs would not allow to use common codes on the clock, I think about the complexity of implementing Ajax just to give an example.

---

@FantasyFactory Sorry, I have a tenuous understanding here, but.. What do you mean exactly by "complete porting"? I think it's already compatible with the ESP32 platform.. https://www.freelists.org/post/quickjs-devel/quickjs-on-esp32,2

---

What do you mean by "QuickJs should be reduced to essential functionalities and this would nullify the possibility of using standard libraries".. do you mean that because of the limited space on the ESP32 we would want an even more lightweight build of QuickJS, without the standard libraries? I'm not sure if QuickJS supports that, but the standard libraries for JS would not be very heavy, since JS has a notoriously bare-bones (or arguably non-existent) standard library. This is actually the reason for the huge number of packages/dependencies for every node.js project: we have to use lots of little packages to make up for the lack of a standard library. That would give us an advantage here though, since we won't waste space on "standard library" functions that won't necessarily be used.

Note that the QuickJS README says "210 KiB of x86 code for a simple hello world program".

It would still be pretty small (close to that) when compiled for the ESP32, right?

---

Sorry, what do you mean by "would not allow to use common codes on the clock"?

[FantasyFactory]

@FantasyFactory Sorry, I have a tenuous understanding here, but.. What do you mean exactly by "complete porting"? I think it's already compatible with the ESP32 platform.. https://www.freelists.org/post/quickjs-devel/quickjs-on-esp32,2

I still don't see any ports, in the link you sent it simply talks about the fact that esp32 would be powerful enough to support it.

Sorry, what do you mean by "would not allow to use common codes on the clock"?

Even assuming that there is a port on esp32, it is useless without the integration to the TTWatch features, the graphical interface, etc. of course, they must be developed anyway, but doing it within a much more complex interpreter (like quickjs) is a much more difficult undertaking than the one I am already facing.

What do you mean by "QuickJs should be reduced to essential functionalities and this would nullify the possibility of using standard libraries" (etc.)

let me explain, i like javascript, i like python, they are modern, beautiful, powerful, flexible languages! Basic is an old-fashioned thing, good for sinclair spectrum nostalgics. OK!

Python or Javascript can use tons of libraries and frameworks, with which writing an application for TTwatch would become very simple! .... boom! No
Tons of these frameworks would have to be rewritten to make them usable on TTwatch, if you can, if you have the time to do it, if esp32 doesn't explode, if the result is something not that different from the original frameworks to making unusable any piece of open source without rewriting it in turn.
At this point, we might as well use a simple basic interpreter, in any case any small software someone wants to develop it should learn a specific "TTwatch" language, not a standard basic but not even a standard python or a standard javascript.

Then, if someone takes over the enterprise and succeeds, I immediately throw away the basic interpreter sources, I give a big applause and I will be happy to use python or js on the TTwatch

[FantasyFactory]

There is https://banglejs.com/ More beautiful, more powerful, js programmable https://github.com/espruino/Espruino

at best I don't think I would be able to make even a bad copy, requiring hundreds of hours of work, for something that costs as much as a dinner in a pizzeria

better fly at ground level and doing someting easier but usable, imho

[FantasyFactory]

another possible and interesting alternative would be squirrel, http://www.squirrel-lang.org/ there is already a port to esp32 https://github.com/EternityForest/Acorns

[FantasyFactory]

and here's another one https://github.com/EternityForest/arduinoscript this guy (https://github.com/EternityForest) loves to write interpreters for arduino 👍

[JoshuaPK]

Interestingly enough I was also toying with the idea of porting Lua as an app on this watch. After reading through this issue I took a look at all of the Javascript engines described here. There's one that is not mentioned: Ducktape. And there is a version of Ducktape that has a mature implementation for ESP32 that has built-in support for all of the ESP32 stuff.

https://github.com/nkolban/duktape-esp32

The challenge here is that the last update to this esp32 port is 3 years old, where Ducktape itself has been updated as recently as two months ago. So in addition to modifying this port of Ducktape to work with this watch, we would need to update the version of Ductape used to the latest. Also, I'm not sure how resource intensive (in terms of storage used, PSRAM used, etc) this implementation is.

I wonder how much work that would be, compared to building Lua as an app on this watch and then building the bindings to the ESP32 and other hardware on the watch. Most of the Lua ESP32 stuff I've seen is the work done on WhiteCat Lua RTOS and I haven't had a chance to see how portable that stuff is.

[urobot2011]

For JavaScript we also have this option: https://jerryscript.net/