I added boolean argument and if statement inside sort_unstable_by closure:

``` //from

|&a, &b| compare(a, b)

//to

|&a, &b| if is_reverse { compare(b, a) } else { compare(a, b) } ```

I expected binary to grow slightly, but actually it became ca 1KB smaller.

I dug into with bloaty and found that the reason is: quicksort fn became 980 bytes smaller.

Still not sure why. Inlining looks same, quicksort just has fewer instructions.

target: arm-unknown-linux-gnueabihf

details: https:// pastebin.com/qJdTw49n

commit: https://github.com/tracyspacy/fli/commit/a87a98be77cc1972a53e6399716a227d1135e76b

Comments URL: https://news.ycombinator.com/item?id=48761304

Points: 5

# Comments: 2

I have access to my raspberry pi zero via ssh only. As for me it is hard to differentiate types of files etc based on colors, I needed something more readable and clear like picture/icon or emoji as I ended up with etc. And I decided to build fli and since ls is obviosly preinstalled on almost any machine, the second requirement for fli as a complimentary tool, is to be tiny.

Readability: Nice readability thanks to use of emojis ( and ) instead of text coloring.

Size: Since rust std contributes heavily to binary size, this project is no_std + libc

Current binary size: M-series Mac 51KB , rpi zero 18KB.

Display options:

`fli` : short (name and type) not sorted output - direct stream, no heap allocation

`fli -s`: short (name and type) sorted by name output - uses heap allocation

`fli -l`: long (name, type, metadata ) not sorted output and fixed-sized alignment (20 chars for size and n_link) - direct stream, no heap allocation

`fli -l -s`: long (name, type, metadata ) sorted by name output and dynamic alignment - uses heap allocation.

`fli -l -S`: long (name, type, metadata ) sorted by size output and dynamic alignment - uses heap allocation.

GitHub repo: https://github.com/tracyspacy/fli

Comments URL: https://news.ycombinator.com/item?id=48607567

Points: 4

# Comments: 0

Initial Why: need some easy readable ls like tool for rpi to use via ssh. Current Why: check if with Rust one can build core utils like tools faster and smaller.

- Size: 18K - RPI ZERO W 51KB - Mac

- Default mode streams readdir() => stdout with zero heap allocation.

- Nice readabilty thx to ( and ) instead of text coloring

- Written in no_std rust + libc.

repo: https://github.com/tracyspacy/fli

Comments URL: https://news.ycombinator.com/item?id=48480956

Points: 2

# Comments: 0

Comments URL: https://news.ycombinator.com/item?id=48178440

Points: 1

# Comments: 0

Shows some additional info such as upvotes, downvotes, and comment count in the tray menu.

Built it to stay up to date with Lemmy without opening a browser. Planning to extend it as a mod tool to catch new posts in communities I moderate.

https://github.com/tracyspacy/lemmy-tray

Comments URL: https://news.ycombinator.com/item?id=48149604

Points: 2

# Comments: 0

Recently I added new example: Implementation of Binary Coded Decimal decoder from Petzold's "Code" book — every logic gate (bits switch, inverters, AND gates) is a task carrying its own instructions.

It works simple : cargo run 1001 -> 9 and as output it will show AND gate with inputs and output

bcd-decoder: https://github.com/tracyspacy/spacydo/tree/main/examples/bcd-decoder

vm: https://github.com/tracyspacy/spacydo

Comments URL: https://news.ycombinator.com/item?id=47572462

Points: 2

# Comments: 0

Recently I added new example: Implementation of Binary Coded Decimal decoder from Petzold's "Code" book — every logic gate (bits switch, inverters, AND gates) is a task carrying its own instructions.

It works simple : cargo run 1001 -> 9 and as output it will show AND gate with inputs and output

bcd-decoder: https://github.com/tracyspacy/spacydo/tree/main/examples/bcd-decoder

Comments URL: https://news.ycombinator.com/item?id=47230700

Points: 1

# Comments: 0

Recently I added new example: Implementation of Binary Coded Decimal decoder from Petzold's "Code" book — every logic gate (bits switch, inverters, AND gates) is a task carrying its own instructions.

It works simple : cargo run 1001 -> 9 and as output it will show AND gate with inputs and output

bcd-decoder: https://github.com/tracyspacy/spacydo/tree/main/examples/bcd-decoder

Comments URL: https://news.ycombinator.com/item?id=47222959

Points: 2

# Comments: 0

Sometimes, there are moments when you feel loosing control over your life, when there is to much on a plate and all this overwhelms you, makes you anxious. For me, solution always was to use kind of "get things done" tools, to organize myself. I tried various todo apps, even bought a paper todo, but this wasn't enough this time. Every restriction in functionality, every missed feature made me feel I'm loosing control again. And one moment I gave up and decided it is time to make my own tool and make it right (in my understanding), i.e a todo that is highly customazible and instead of hardcoded features can have any you want. Despite todo is an anecdote and there are thousands of them, same as with an edit tool https://devblogs.microsoft.com/commandline/edit-is-now-open-source/ it is quite a challenging task to make a good one.

# Design/Concept

Luckily, I had 2 weeks of winter holidays and I decided to invest this time into a project. I thought a lot on how to make a todo that potentially have any possible feature that anyone can simply add just when they need it. My solution was a Virtual Machine with persistent storage + Tasks that have their own executable instructions. So in this design any todo app could be a simple wrapper around i/o and all functionality would be powered by the VM.

# Problems/Complexity

Creation of a working VM is a complex task for sure. I will not mention every problem I faced during last months, but will just list some features I implemented to solve them:

- NaN-boxing — All stack values are 64-bit (u64) encoding 6 distinct types (Null, Boolean(TRUE_VAL,FALSE_VAL), STRING_VAL, CALLDATA_VAL, U32_VAL, MEM_SLICE_VAL (offset: 25 bits, size: 25 bits)).

- InlineVec — Fixed-size array-backed vector implementation used for stack, control stack, call stack, and jump stack with specified limits.

- Dynamic Memory/Heap — growable Vec heap, memory slices use 25-bit offset and 25-bit size fields (limited by MEM_SLICE_VAL).

- Definite Loops — DO…LOOP 2 nested loops only possible for now.

- Conditional jump - IF..THEN 2 nested IF..THEN statements only possible for now.

- Custom binary encoding/decoding implementation.

# Current state

My Virtual Machine is still in it's early days and may miss some important instructions, but it can be already used for a todo app demo with programmable tasks. All operations — from simple CRUD to the tasks' own instructions — are executed by the VM. The concept is, that any kind of automation or workflow can be enabled by task instructions executed by the VM, rather than hardcoded functions in the app - exactly what I wanted to achieve initially! There are 4 demo task instructions that are not a part of the todo code, but instead are in toml file which could be updated any time with a new one:

- chain - Creates next task once when another is completed. Removes calldata after call - called once

- either - Sets complete if either one or another task is completed + deletes not completed task

- destructable - task self destructs when it’s status set to complete

- hide - Keeps task hidden while specified task’s status is not complete.

https://github.com/tracyspacy/spacydo/tree/main/examples/todo

When I added the todo example, I realized, that the originally hardcoded states in the VM were a limitation. If I would make them generic (which I did), the VM would serve more than just todo apps: new use cases such as tasks orchestration and even state machines became possible. I added a finite state machine primitive example as well - a traffic light - where task is a simple state machine which has own state transition rules in executable calldata.

https://github.com/tracyspacy/spacydo/tree/main/examples/traffic_light

I'm still working on this project alone and struggle to get other people involved to help me stabilize and finalize the VM.

Anyway, this journey is interesting and insightful, and I'm curious what comes next.

Comments URL: https://news.ycombinator.com/item?id=47179642

Points: 1

# Comments: 0

VM has persistent storage, so state is persistent across calls

Calldata logic: check task's state -> transit to next -> save. State transition rule: 0(Green)->1(Yellow)->2(Red)->0(Green).

examples code: https://github.com/tracyspacy/spacydo/blob/main/examples/traffic_light

Comments URL: https://news.ycombinator.com/item?id=47140675

Points: 1

# Comments: 0

What's new:

- NaN-boxing — All stack values are 64-bit (u64) encoding 6 distinct types (Null, Boolean(TRUE_VAL,FALSE_VAL), STRING_VAL, CALLDATA_VAL, U32_VAL, MEM_SLICE_VAL (offset: 25 bits, size: 25 bits)).

- InlineVec — Fixed-size array-backed vector implementation used for stack, control stack, call stack, and jump stack with specified limits.

- Dynamic Memory/Heap — growable Vec heap; memory slices use 25-bit offset and 25-bit size fields (limited by MEM_SLICE_VAL).

- Zero dependencies —Custom binary encoding/decoding implementation.

Furthermore I added an example to stresstest VM - a todo app with programmable tasks.

In this example, all todo operations — from simple CRUD to tasks own instructions — are executed by a virtual machine.

The concept is that any kind of automation or workflow can be enabled by task instructions executed by the VM, rather than hardcoded functions in the app. It’s close to the concept of rules engines.

There are 4 demo task instructions:

- chain - Creates next task once when another completes. Removes calldata after call - called once

- either - Sets complete if either one or another task is completed + deletes not completed task (see gif)

- destructable - task self destructs when it’s status set to complete

- hide - Keeps task hidden while specified task’s status is not complete.

It is possible to add your own instructions to calldata.toml and use them within todo example:

cargo run -- add -calldata

todo example : https://github.com/tracyspacy/spacydo/tree/main/examples/todo

vm repo: https://github.com/tracyspacy/spacydo

Comments URL: https://news.ycombinator.com/item?id=47013612

Points: 1

# Comments: 0

The concept is that any kind of automation or workflow can be enabled by task instructions executed by the VM, rather than hardcoded functions in the app. It’s close to the concept of rules engines.

There are 4 demo task instructions:

- *chain* - Creates next task once when another completes. Removes calldata after call - called once - *either* - Sets complete if either one or another task is completed + deletes not completed task (see gif) - *destructable* - task self destructs when it’s status set to complete - *hide* - Keeps task hidden while specified task’s status is not complete.

It is possible to add your own instructions to calldata.toml and use them within todo example:

cargo run -- add -calldata

demo gif: https://lemmy.ml/pictrs/image/674bea85-d6b0-40d7-ba7f-dd1c10649aee.gif

repo: https://github.com/tracyspacy/spacydo

todo example : https://github.com/tracyspacy/spacydo/tree/main/examples/todo

Comments URL: https://news.ycombinator.com/item?id=47004379

Points: 1

# Comments: 0

Recent updates:

- VM now uses NaN-boxing technique.

- All stack values are 64-bit (u64) but encode 5 distinct types: Boolean, String, CallData, U32, and MemSlice (25-bit offset + 25-bit size).

- Added InlineVec — a vector-like structure backed by a fixed-size array. The VM stack, control stack, call stack, and jump stack now use it with defined limits. - VM has memory now (heap). Memory is simple Vec, grows dynamically, but technically length is restricted by mem_slice_val format: 25 bits payload for offset and size

Project is still in absolutely early stage.

Repo is here: https://github.com/tracyspacy/spacydo

Comments URL: https://news.ycombinator.com/item?id=46847422

Points: 4

# Comments: 3

I needed all VM values (booleans, integers, string pool indices, bytecode references) to fit in 64 bits (stack is Vec). 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

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

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 & instructions pooling (indices stored as NaN-boxed values) - Call stack for task instructions execution.

code is here : https://github.com/tracyspacy/spacydo/blob/main/src/values.rs

Comments URL: https://news.ycombinator.com/item?id=46529383

Points: 5

# Comments: 0

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

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.