marc136

In general, e.g. to place the files and their metadata like checksum, access rights, image previews, foreign keys right next to each other.

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

Or one for arduino https://news.ycombinator.com/item?id=41500071

Which was also forked for ESP32 and has its own community https://github.com/biologist79/ESPuino

If you are looking for a FOSS alternative to tonies, yoto and such I would also recommend the DIY TonUINO project.

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

I'm not sure if I understand correctly.

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.

If I understand you correctly, your advice is that EUPL is an unknown/obscure license and you would not choose it for that reason?

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.

That's high on my list, too.

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 ...

I can get those downloaded into the directories and add them to the VCS.

Zero workarounds seems overly dramatic, here are a few: https://news.ycombinator.com/item?id=39567011

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.

Yes, ports or custom elements are the recommended options, https://github.com/elm-community/js-integration-examples

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.

> So I made a package that wraps native RegExp. When 0.19 was released, I couldn't upgrade because of those 5 lines. The regex package eventually got regex.fromstring(). So I could've upgraded.

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.

Funny that you have this impression.

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

For anyone new to Elm, please know that you have a stable language with no major changes since 2018 and no official release since end of 2019, see https://iselmdead.info and decide if that is a bad or a good thing for you.

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.

If time is important to you, please correct your statement.

> 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...