In the authors use case, it might also be easier to drop the executable and one big database file on a random shared file store in the company network instead of many small files and a database file for metadata.
And it might be faster to read files from db than from fs https://sqlite.org/fasterthanfs.html
Which was also forked for ESP32 and has its own community https://github.com/biologist79/ESPuino
The boards are built into boxes, toys (from fire engines to plush) and whatever sparks imagination. https://discourse.voss.earth/t/tonuino-gehaeuse-galerie/786/...
Most of the community speaks German, but there is also an English section https://discourse.voss.earth/c/international/11
The source code is in English and the schematics language independent. https://github.com/tonuino/TonUINO-TNG
For me, it is mostly about "sharing the code" as in: I put it somewhere and anyone who wants can use it. But if they adapt or remix it, they should also use a free license (ideally contribute back to my project).
> in the sense that it does not prevent tivoization?
I'm not sure, but I guess it does not protect against tivoization because if I were to distribute an executable or library, that could be used on a blackbox with proprietary code without them requiring to open their own code.
Thanks for the good luck wishes, but I don't intend to throw money towards enforcing the license at all. I mostly don't want to be liable for code that I open source.
And restricting it to EU would solve the problem that e.g. WTFPL or UNLICENSE have with countries that don't acknowledge public domain.
This is more a question out of curiosity for me, and many people react allergic to viral licenses, GNU or RMS so I was looking for alternatives because I also heard there were issues with CC-share-alike.
How do people here think about the EUPL, especially when compared to licenses like GPL, LGPL, AGPL, MPL,...?https://joinup.ec.europa.eu/collection/eupl/eupl-text-eupl-12I saw e.g. https://news.ycombinator.com/item?id=37160740 and https://news.ycombinator.com/item?id=14053129 but they don't contain discussions.I like that:1. I can read it in my native legalese and not just the English one.2....
The only fear I have is that I won't be able to install packages that no longer exist when I switching machines.
But by running
ELM_HOME="$PWD/deps" elm make ...
If you want to rely on them for every possible future requirement or rather want to pick another tool is another question :D
Anyways, just building the compiler without that check was also not that hard.
There are a bunch of other options/workarounds/hacks depending on the need. E.g. using getters or creating proxy objects https://github.com/anmolitor/intl-proxy, or event listeners, or postprocessing of the generated JS code, but those shouldn't be the first idea to reach for.
The last commit to the regex package was in May 2018, and Elm 0.19 was released later in August. https://github.com/elm/regex/commits/1.0.0/
So it seems like by the time of the official release you could have replaced your five lines with `Regex.fromString`.
But the missing Intl API is definitely a huge pain, and I understand that you were switching away if you needed it extensively. Or expected to want other sync APIs wrapped.
A common way to solve something like this is with proxy objects like in https://github.com/anmolitor/intl-proxy but it does not give access to every feature in a nice way.
I went the route of least resistance and built the Elm compiler without the Kernel code check. But in the past few years I hardly needed that anymore.
To me it looks more like the elm-haters are out in force and the Elm users don't participate anymore on this site.
Many hateful comments here below a historic post prompted me to create a new account after a detox phase of >10 years.
So far I try to correct a false statement in the (as of writing this) top comment [1] or add a more neutral view [2]. And maybe I will add more of my personal opinion in the future - or participate in other interesting topics depending on my mood.
[1]: https://news.ycombinator.com/item?id=39555542 [2]: https://news.ycombinator.com/item?id=39556395
And if you are thinking of starting now, you should not focus on what undocumented feature (or hack) was taken away in 2018 that allowed injecting arbitrary JavaScript code that easily broke all guarantees of the language https://discourse.elm-lang.org/t/native-code-in-0-19/826 but rather if Elm fits your current (and maybe future) needs. If it does not, keep looking for alternatives.
> The year in this link is very important. In the following year, the Elm team decided to [...]
The blog post was released a year after the official release of Elm 0.19 where the access to native code was further restricted in the official compiler.
It was not something that happened without ample prior notice, see for instance a post [1] by the Elm language creator in March 2018 in which he explains his reasoning for the upcoming change. Or another in March 2017 where he announced that intended change [2]. Even in 2015 he actively discouraged people to rely on these undocumented features and other hacks [3].
I also was not happy with that choice and felt the pain of something being taken away that was possible before, but that didn't stop me from using Elm at work nor from using it for fun.
So far I haven't found an alternative that I liked better, so I will stick to it.
[1]: https://discourse.elm-lang.org/t/native-code-in-0-19/826 [2]: https://groups.google.com/g/elm-dev/c/bAHD_8PbgKE/m/X-z67wTd... [3]: https://groups.google.com/g/elm-dev/c/1JW6wknkDIo/m/H9ZnS71B...