thank you. As for python, seems it is preinstalled on pi, I assume option you suggested might be also viable initially, I'm not very experienced in python though.
Right now I feel interesting challenge on how small I can go with rust+libc while keeping it cross compiling.
I don't think the loop unrolling plays a big role here, I guess it was more an example.
While post body contains control flow, it can be simple arithmetic operation instead and it will lead to the similar result, so not the control flow itself causing this.
But yeah, I also feel, that more complex closure blocks some optimizations here, thus quicksort having less instructions.
I suspect that complex closure was outlined to a separate fn, and not copied to quicksort anymore.
It's an experimental approach to ordinary todos. There are plenty of good tools like taskwarrior, but their features are hardcoded task body is huge — you either dig through hundreds of features to find what you need, or something you need is too niche, so it will make no sense to hard code it for devs.
So, I decided to try a different approach as an experiment: keep the task model super simple (id,title, status,calldata), but let tasks have executable instructions.
That way almost any custom behavior becomes possible — tasks depending on other tasks, tasks modifying other tasks or creating new ones, recurring, self-deleting tasks, task that monitoring new tasks creation and creates alert task, or increase priority of older tasks etc.
The tradeoff is complexity for flexibility, like vim/helix vs zed or atom.
To make that work a tiny virtual machine is needed and a set of opcodes. So this vm can be a basis for some todo app.
I've been building a bytecode VM in Rust and recently implemented NaN boxing for value representation. Sharing here for anyone interested.
I needed all VM values (booleans, integers, string pool indices, bytecode references) to fit in 64 bits (stack is Vec<u64>).
My implementation encodes 5 distinct types using a 3-bit tag and 32-bit payload, all within a single u64. It also has 15 unused bits, they may be used later for types expansion.
I'm using a 64-bit layout:
- Bits 63-51: Quiet NaN signature (0x7FFC...)
- Bits 50-18: 32-bit payload (integers, string pool indices, etc.)
- Bits 17-3: Unused/ (15 bits)
- Bits 2-0: 3-bit type tag
- Bits 63-51: Quiet NaN signature (0x7FFC...)
- Bits 50-18: 32-bit payload (integers, string pool indices, etc.)
- Bits 17-3: Unused/ (15 bits)
- Bits 2-0: 3-bit type tag
So it allows me to have 5 tagged types: `TRUE_VAL`, `FALSE_VAL`, `STRING_VAL`, `CALLDATA_VAL`, `U32_VAL`
This is for a domain-specific VM I'm building for programmable task management (think "Vim for todo apps" - small core with scriptable behaviors). The VM is stack-based with:
- String pooling (indices stored as NaN-boxed values)
- Instruction pooling (bytecode reuse)
- Call stack for task instructions execution.
The faucet offers an unprecedented Web3 experience — no wallet connection, no address copy-paste, just one click.
0xNAME acts as a spam/Sybil prevention layer.
So, you can claim Testnet Sepolia ETH without:
• Wasting electricity on PoW
• Holding ETH or ERC-20 tokens
Know someone building on Ethereum Sepolia?
Or constantly hunting for Testnet ETH?
Send this their way. This faucet might save them a ton of time.
Hey, first of all, thanks for having a look. Honestly, I never thought it would grab any attention, but your feedback is definitely valid. This small driver was something I quickly put together as a simple prototype, borrowing parts from Pimoroni’s C++ driver https://github.com/pimoroni/pimoroni-pico/tree/main/drivers/... (you probably find some answers here). I initially needed it as part of a Pimoroni GFX PACK driver concept I was working on.
Now that it’s got some attention, it seems worth spending more time improving it.
