eerimoq

Thanks!

I use a slightly modified version of your beautiful map on my website (https://mys-lang.org/statistics.html). No animations and the green circles are not quite aligned to the hexagons. Works well enough for my use case anyway.

The CPU usage sky rockets when showing the world SVG in my Chromium browser. Is there any trick to make the animated SVG be less CPU intensive?

It compiles statically typed Python modules to CPython C extension modules. I do not know the details, but it sounds like that's a major difference to Mys.

Please do, but I won't promise I will contribute a lot, so don't be disappointed. =)

This looks promising indeed. Thanks for sharing.

I'll keep this in mind.

For me it's pretty simple. I love Python. I like speed. I like embedded. This is an attempt to take advantage of Python's type hints to create fast and hopefully small binaries that can be executed on embedded devices limited amount of resources (both CPU and RAM).

There are probably other languages that would serve the same purpose, but oh well, I can't resist creating another. =)

I like the idea. If our languages are similar it could even make sense to stop developing one of them and focus on the other, but that's probably far fetched. I'll have a look at yours to get a better understanding of what it looks like and where it shines. Maybe we meet again =)

Well, probably not. Nim is similar, but I prefer Mys' Python-like syntax. Mys' toolchain will probably be similar to Nim. That is, generating C/C++ code.

Sorry about the confusion. Mys is statically typed. I changed the HN post from strongly to statically to make it clear.

Nice job.

I don't understand the question. Can you rephrase it? =)

No, I am not aware of ChocoPy. Thanks for letting me know.

Shedskin uses the Python interpreter if I remember correctly. I aim not to.

Updated the GitHub repo and the HN post. Thanks.

It's a wide question, and I don't have a good answer. One obvious difference is the syntax. I prefer Python's syntax over Nim's, but at the same time I find Python slow sometimes and hard to use in embedded systems. I'm aiming to create something similar to Nim's toolchain to address that.

That's pretty much what I wrote in the first post.

In my experience most bugs are due to misunderstanding requirements and simply writing faulty logic. Just a few bugs are related to the language itself.

Of course the language can help the programmer to write better code. High level constructs and easily available libraries that are well tested and widely used helps a lot. However, the biggest problem is not the language, it's that the programmer simply writes faulty code.

Thank you very much. Very helpful answer. I'll continue to use 52 MHz until I encounter problems (if any).

Will fix it at some point =)

I'm just referring to the fec driver kernel module, not the user space software. But I might of course be wrong. I've done lots of iterations trying to optimize the boot time on this tiny embedded system, and it's not always easy to remember all details. It could be that the fec driver is asynchronously probed. I guess I have to try it again at some point. =)

The goal is to not configure the MMC at all in Linux, but just rely on the bootloader has already configured it.

Btw, where can I find the spec? And where in the spec can I read about this? Is this true even if we know the MMC supports 52 MHz?

You are right, it probably could. I should try compiling the fec-driver into the kernel and make it asynchronous. Should save a couple of milliseconds, and hopefully not delay entering user space.

I'm curious as well, and yes, by reboot I mean calling "reboot(RB_AUTOBOOT)". I was under the impression that the ROM code has to start over from the beginning, which I think it does. Maybe it can skip some initialization since the SoC is already up and running. Maybe there is some initial hardware setup that is only done at power on. It's hard to tell as this part of the boot sequence runs closed source NXP code.

Amazing!

There are plenty of song on his YouTube channel:

https://www.youtube.com/channel/UCoGRABtFGU7ng79NqF0KuIQ/vid...

The C code that applies a patch can do so using just a couple 100 bytes of RAM, depending on the chosen compression algorithm. Heatshrink is probably a good choice for an MCU.

There are two kind of patches; normal and in-place. The normal patch requires the old firmware to be readable until the patching procedure is completed. The in-place patch is designed to write the new firmware to the same memory area as the old is read from.

You can read more about in-place patches here: https://detools.readthedocs.io/en/latest/#id2

I'm glad you find it useful.

In Monolinux there is a single statically linked user space application (the init-process). Alpine has the traditional approach of many user space applications and shared libraries, if I'm not mistaken.

The size depends on your Linux kernel configuration and user space application. My guess is that most distros will be a 5+ MB.

ARM is the only architecture I've used so far. =)

See https://github.com/eerimoq/dbg-macro.

I got inspired by this HN post and implemented it today. There's certainly room for improvment.