modrobert @modrobert@qoto.org

U-BOOT now supports booting from an http server 🎉 no more tftp pain! https://www.cnx-software.com/2023/01/25/u-boot-now-supports-booting-linux-from-an-http-server/

Really good article describing how to parse code from a custom language, create an ast, generate assembly and execute it in memory for a just in time calculator in V https://l-m.dev/cs/jitcalc/ #vlang #jit #ast

sorry for the interruption, we've had some serious server problems, but the bitcoin git hidden service http://nxshomzlgqmwfwhcnyvbznyrybh3gotlfgis7wkv7iur2yj2rarlhiad.onion/ is finally up and running again

Some more KAP musings

After having migrated to the new fork syntax, I now have another idea.

Currently, integer maths is always 64-bit, with wraparound overflow (because that's what the JVM does by default). For a language that is kinda oriented towards maths, that's pretty ugly.

I'm considering implementing support for bignums, in order to eliminate integer overflows. Doing so will make the behaviours of integers similar to Lisp, which is good (Lisp has, after all, the best numeric tower of any programming language, and this would make KAP almost on par with it).

However...

It would have a negative impact on performance. I don't know how much, but definitely measurable.

On the other hand, no one would care...

There are no actual users of KAP anyway, and I'm not sure that'll ever change.
If you are looking for performance, kap is already slower than any performance-oriented language.
No matter how slow I make kap, it'll still be faster than Python, which people seems to happily by using.

If I were to do this, I would also need to integrate just with bignums on the JVM, but also find a bignum library for JS (I have't researched this) as well as learning how to use GMP, since KAP can compile to JS and native as well.

I love moss and I love frogs and I just discovered the cutest thing in existence: the Vietnamese moss frog 🤗

#mosstodon