floitsch

In Denmark most providers charge you hourly rates.

Here is, for example, the page of my current provider: https://www.ok.dk/privat/produkter/el/priser

This page doesn't yet include the additional costs (last mile...), but there is definitely a big difference whether I consume the energy at cheap or expensive hours.

Note that Toit has nothing to do with JavaScript or the Web. It was from the beginning designed to run on embedded devices.

The current (and past) electricity prices in most of Europe can be found on nordpool.

Three days ago, in Denmark, prices went as low as -41.37Eur/MWh (where 100Eur/MWh is a common price otherwise).

https://www.nordpoolgroup.com/en/Market-data1/Dayahead/Area-...

At the moment electricity is cheapest (and therefore greenest) in the afternoon. Probably because of solar (partially from Germany).

https://app.electricitymaps.com/zone/DE

It's also great to see how much green energy Spain got recently.

I have connected my esp32s to chat (telegram) and openai. With the correct prompt and an interpreter they can now execute requests in human language: https://medium.com/p/3242af6f2988

For games I'm usually on lichess, but for puzzles I tend to use chesstempo.com. I find their quality just better.

Uses OpenAI API calls to translate human requests to a small language that is then interpreted by an interpreter on the ESP32. Runs entirely on the microcontroller.

Yeah... That would be hard to do in the limited memory of the ESP32. Main issue is the cost of TLS connections.

Did something similar (without voice) that runs on an esp32. This way I don't need any server or keep my desktop machine running.

Supports Telegram and Discord.

https://github.com/floitsch/ai-projects/tree/main/chat

Maybe give Toit (toitlang.org) a try.

We have been working on it for a few years now, and it gets more and more complete. Recently Espressif started contributing as well (and added Toit to their esp-idf installer).

Some selling points of Toit:

* modern language

* very fast execution for a dynamic language. (more than 10x faster than micropython)

* consistent libraries.

Google's business model is absolutely not built around privacy invasion, and their model is built around data collection of public data. If, for some reason, they couldn't use personalized ads anymore, they would simply earn less, but their business model would be the exact same as before.

Mozilla business model is entirely built around their market share. As such, they are in a much more difficult situation than Google's Chrome team. If Mozilla has a difficult time (financially), they are more likely to do shady things than the Chrome team which has no such pressure. For example, the Chrome team would never accept any cryptocurrency deal; something that I have no difficulties imaging Mozilla to do.

Obviously, Chrome will not actively hurt Google's other businesses (specifically ads), but Chrome's primary goal is to make the web a better place. The worst case scenario for Google is that the web (and thus their revenue stream) disappears.

Machine shop work - Blondihacks: https://www.youtube.com/@Blondihacks

I'm not the author, but I know him personally. I will make sure he reads this message.

That's probably on me...

If I had to do it again, I would make it stable now.

I have worked at Google (although in a different department). From what I could see there was never intentional hurting of other browsers. However, given a list of (always too long) TODOs, improving a non-critical feature for 10% of users often just doesn't make it to the top.

And yes, Google is a huge company with a ton of developers, but teams are not. In my experience, these kind of fixes are sometimes even done by individuals in their "spare" time, to contribute a bit back (even if it's for a competing browser).

It's on our (my) Todo list.

The next best thing is currently probably this tutorial: https://docs.google.com/document/d/1K-TYea7jbYfj2ecMUmr0T0zd...

If I remember correctly we were supposed to have our personal projects there.

Since Google owns the copyright it almost makes sense.

Also, being in the Google organization doesn't mean that Google is involved in it. I'm maintaining a project there (`google/double-conversion`), despite not having worked for Google for years. Nobody at Google has any influence or reviews on that project.

That's not true for many people.

When working at Google, developers generally open-source their private projects (which are legally owned by Google) under a Google umbrella, with a Google copyright. This rarely stops developers. When I worked there, my incentive was to make my work more useful and give something back. I'm pretty sure many other Googlers feel the same way.

If Github found another way of making my work more useful to others, all the better. I would prefer if Copilot wasn't the only option, and if there was a good open-source alternative, but that's completely independent of the fact that my code was used to teach a neural network how to complete code snippets.

Shell scripting also inspired some choices (especially syntax) of the Toit language (toitlang.org).

Clearly, it's for a different purpose, and there are some things that wouldn't work in a general-purpose language that isn't as focused on line-based string processing, but we are really happy with the things we took from bash.

The European Union looked into unifying Europe's plugs. They decided that the cost was not worth it.

I would have been happy to switch to a unified European plug. Iirc, the proposal was actually quite decent.

https://www.europarl.europa.eu/doceo/document/E-6-2005-1731-...

I use it for Toit (toitlang.org).

It's not perfect, but still incredible useful (and sometimes scary; in a good way).

I particularly like it for writing tests, but it's useful in normal code too.

Interesting fact: the Anglo-Scottish border is significantly shorter than the one separating Northern Ireland from Ireland: 154km vs 499km.

We use it for some of our tools, so it's possible (and works nicely). Our LSP server was initially written in Toit: https://github.com/toitlang/toit/tree/master/tools/lsp/serve... (To be fair, it uses the compiler underneath for analyzing the sources).

Main restriction is, that we haven't finished the Windows implementation yet. Specifically networking and spawning processes only works on Linux/macOS so far. (The main reason we ported the LSP server to Go).

The `host` package (https://pkg.toit.io/package/github.com%2Ftoitlang%2Fpkg-host...) provides some functionality for running things on the desktop.

We rely heavily on the ESP32 peripherals for strict timings.

For example the 1-wire protocol is implemented using the RMT (remote control) peripheral. The pixel strips driver uses the UART or i2s.

If really necessary, we could drop down to C, but the hardware is usually better (more precise and leaves us to do other things in the meantime).

We couldn't use `:` as that one is already used for too many things.

We then experimented with different tokens, and `/` felt best.

The `:` are actually doing the same thing, introducing a block (think of it like a limited function).

The `/` are also the same (division), but it's true that we also use `/` to introduce types. For example `x/int`.

I think Toit is relatively easy to learn, but there are definitely a few things that need explaining in the beginning.

For those interested in a comparison to MicroPython: I recently wrote a Toit version of the MakePython ESP32 Dev Kit lessons.

Here is the Toit version of it: https://docs.google.com/document/d/1K-TYea7jbYfj2ecMUmr0T0zd...

And here the MicroPython: https://www.makerfabs.com/desfile/files/Get-Started-MicroPyt...

In big parts that's true, but there are some good arguments in favor of a GC for these small devices:

- the GC is a sliding compacting GC. As such there is no fragmentation for heap-allocated memory.

- the memory on these devices is tiny. The GC thus doesn't take long time.

- the ESP32 has really good peripherals, making timing sensitive operations very rare. In most cases there is a hardware module that does the job for you. The timing requirements then usually become significant less important.

Jaguar is the tooling to enable rapid development. It consists of two parts: one that runs on the ESP32 and another one that runs on your computer.

Whenever a new program is ready, it gets pushed (over WiFi) to the device. The whole process only updates the actual program (not the whole OS), thus making the development cycle really fast.

Compared to MicroPython, Toit is significantly faster. In my (obviously biased) opinion, it's also more robust.

You can't link C drivers directly without modifying the Toit code base, but there is a bridge to talk between C and Toit code. Generally, we prefer to reimplement the drivers in Toit. However, for some bigger ones it clearly makes sense to keep the C version.

Another alternative is Toit: https://toitlang.org

I recently wrote a Toit version of the lessons for the MakePython ESP32 starter kit. That makes it easier to start with Toit, but it also gives a nice comparison between the two.

MicroPython: https://www.makerfabs.com/desfile/files/Get-Started-MicroPyt...

Toit: https://docs.google.com/document/d/1K-TYea7jbYfj2ecMUmr0T0zd...

I'm a fan of the MakePython ESP32 dev kit. It's reasonably priced and the ESP32 makes it possible to do nice things. https://www.makerfabs.com/makepython-esp32-starter-kit.html

I used it for our Toit tutorial: https://docs.google.com/document/d/1K-TYea7jbYfj2ecMUmr0T0zd...