Loom Update v2

Loom has been greatly updated I finally added a web dashboard, which took forever.

There are a plethora of new features, including:

• Sessions — exit out of sessions with the exit button, or connect sessions to each other
• Models — spawn in models with one click, then apply your own skills to them
• Workflows — save a workflow, load it later, or create one purely in JSON — incredibly helpful for projects
• Skills — create, edit, and delete skills, all organized by folder; apply a skill to an AI while it’s running, plus a couple more features. Incredibly helpful!
• Tiling — arrange sessions side by side in the dashboard instead of being stuck with one view at a time
• Custom glyphs — each coding agent gets its own icon/symbol so you can tell them apart at a glance (Codex’s promptAgent, Claude’s code, and GPT-4o-mini’s reviewer each show up distinctly)

Under the hood

This release also folds in a batch of CLI improvements from the last dev log:

• Persistent memory — skills now auto-enable session persistence when applied, with /persist, /save, /load, and autosave on session lifecycle events
• Permanent one-way routing via /route//unroute, alongside the existing bidirectional /connect
• Live token tracking per session, with fixed Codex accounting so cached/reasoning tokens aren’t double-counted
• New backend: GitHub Copilot CLI support with resume and headless mode
• Cleaned up console output — grouped speakers, tool icons, purple prompt echo, and a top bar that now matches each session’s log color

Obsidian Release! 🎉

I have finally finished coding the first release of Obsidian!

To install it, head over to the Releases tab I tried to make the setup process as simple as possible. If you run into any trouble, please leave a comment or open an issue and I’ll help you out!

Getting Started

1. Go to the Releases page
2. Download the latest release for your platform
3. Follow the setup instructions included with the release
4. Make sure you have the dependencies installed (NASM, G++/MinGW-w64, CMake) see the README for install steps

Found a bug?

This is the first release, so there will absolutely be rough edges please open an issue with:

• What you were trying to do
• What happened instead
• Your OS / setup

Thanks for checking out Obsidian Lang, and happy coding!

Loom CLI Dev Log

2026-07-02

Dashboard

• Fixed chat bar positioning and added a top status bar for active sessions.
• Fixed multi-hop routing completing before real output arrived.
• Cleaned up console output with grouped speakers, collapsed blank lines, tool icons, and purple prompt echo.
• Top bar now matches each session’s log color and can display model labels.

Skills

• Added /skills new|edit|list|show|delete|apply with external editor support.
• Skills can auto-apply on spawn (/spawn codex as prompter).
• Applying a skill automatically enables persistent memory for that session.

Persistence

• Added /persist, /save, /load, and autosave on session lifecycle events.
• Persistence must be explicitly re-enabled after restart.
• Added configurable resume warning (persistence.warn_after_messages, default: 20).

Input

• Added bracketed paste support with collapsed paste previews.
• / now shows searchable command suggestions.
• Added /clear.

Backends

• Added GitHub Copilot CLI backend (copilot npm package) with resume support and headless --allow-all.

Token Tracking

• Added live per-session token counts.
• Fixed Codex accounting so cached/reasoning tokens aren’t double-counted.

Session Lifecycle

• /kill now fully removes sessions instead of leaving stopped entries.
• Fixed potential deadlock during session cleanup.

Cursor Fixes

• Redraw timer now only runs while sessions are active.
• Fixed Windows cursor placement when the input box is empty.

Scrolling

• Reworked scrolling to use a fixed anchor instead of following live output.
• Added mouse wheel scrolling for better PowerShell compatibility.

Routing

• Added permanent one-way routing with /route and /unroute.
• Left /connect unchanged since bidirectional links naturally loop; /route covers the persistent pipeline use case without feedback loops.

Showcase

• https://www.youtube.com/watch?v=DHUXMypePYI

Yet Another Obsidian Devlog

going to keep this one short and sweet because I honestly didn’t add much, butt his is what I added:

print "lambda functions and function calls now work!"

func test() -> int {2 + 2};

return test(); 

Lambda Functions & Function Calls

• Lambda Functions fully working for addition and subtraction, still can’t put in multiple inputs, but you know what that’s fine.
• You can now officially use function calls they work and it’s great, took a lot of coding / logic but it works!

Assembly Code For Example:

global obsidian_program

extern GetStdHandle
extern WriteConsoleA
extern ExitProcess

section .text

test:
    mov eax, 2
    mov ebx, 2
    add eax, ebx
    ret

obsidian_program:
    sub rsp, 40
    mov ecx, -11
    call GetStdHandle
    mov rcx, rax
    lea rdx, [rel str0]
    mov r8d, 47
    lea r9, [rel written]
    mov qword [rsp+32], 0
    call WriteConsoleA
    add rsp, 40

    call test
    mov ecx, eax


    sub rsp, 40
    call ExitProcess

section .bss
    written resd 1

section .data
    str0 db "lambda functions and function calls now work!", 13, 10

Obsidian v1 updates Devlog

What’s new?

Finally got basic lambda style return functions working.
Right now these both compile all the way through the tokenizer, IR, NASM generation, and actually run correctly:
func test() -> int {2 + 2};
func anothertest() -> int {2 - 2};

test currently spits out:

    mov eax, 2
    mov ebx, 2
    add eax, ebx
    ret

So the entire pipeline is finally working end to end.

Syntax change

I ended up changing the function syntax halfway through development.
Originally it looked like this:
func test() -> { 2 + 2 }

The problem is -> was basically trying to do two different jobs at once. It was acting like “here comes the function body” instead of what it should actually mean: “here comes the return type.”
That would’ve forced the parser to guess whether the next token was a type or the start of a block, which is just unnecessary pain when the fix is simple.
Now it’s:
func name() -> type { body }

Way cleaner, no ambiguity, and honestly it reads a lot better too.
Under the hood

Parentheses are now their own tokens (_OPEN_PAREN / _CLOSE_PAREN) instead of getting lumped together with braces.

Expressions are currently evaluated by folding left-to-right through (operator, operand) pairs.

+, -, *, and / all work with integer literals.

One limitation right now is there’s no operator precedence yet.
So:
2 + 3 * 4

currently evaluates as:
((2 + 3) * 4) = 20

instead of:
2 + (3 * 4) = 14

Not really a bug, just something I haven’t implemented yet. The real fix is building an expression tree instead of another parser hack.
Right now everything also assumes the operands are integer literals. Variables aren’t hooked into expression evaluation yet, so identifiers basically don’t work inside expressions.
Function bodies are also limited to a single expression for now no multiple statements or nested expressions yet.

Next up

• Proper operator precedence (expression trees)
• Variables inside expressions
• Multi-statement function bodies
• Saving/restoring non-volatile registers once functions start calling other functions. Right now I’m using ebx as a scratch register, which is perfectly fine for leaf functions but won’t fly forever once function calls exist.

Obsidian Lang v1 Dev Log (this is a progress update, not a release announcement)

What is Obsidian Lang?

Obsidian Lang is a programming language I’m building from scratch. The primary goal isn’t the language itself, it’s mastering parsing, interpretation, and assembly generation. So far the project has forced me to get much more comfortable with C++ and x86-64 assembly, which has been the real payoff.

The problem

Most languages marketed as “beginner friendly” fall into one of two traps. Some oversimplify to the point of being a dead end (Scratch). Others let you write things that work today but teach habits that fall apart later (Python). Obsidian Lang is my attempt at something different: a language designed so that it effectively cannot crash. Whatever the input, even malformed input, the program keeps running.

How that’s implemented

The interpreter is built to absorb mistakes rather than halt on them. Errors get logged, execution continues, and the user still gets a running program out the other end.

Architecture

The pipeline is two passes:

1. Tokenize. Raw source text is scanned character by character into a flat token stream (Tokens.h / Tokenize.cpp). Keywords (return, print, let, const, func, int), operators (+ - * / = ->), literals, and identifiers are all recognized here.

2. Interpret. The token stream is walked once to build an intermediate representation, a flat list of Line structs, each tagged with a category (Create, Header, Info, Program, Section, Function), a label, and the emitted text. That IR is then walked a second time in a fixed order defined in docs/archecture.md to produce the final NASM x64 output: global directive, extern headers, .text section, function bodies, the obsidian_program entry point, program body, .bss, .data, and .rdata, in that order.

Currently supported:

• print "string" compiles down to a direct Win32 WriteConsoleA call, with the string byte count computed at compile time (including the CRLF).
• return <int> maps to ExitProcess. Since there’s no branching yet, whichever return is lexically last in the source is the one that determines the actual exit code, the exit sequence itself is always emitted once, at the very end, so later print calls can’t clobber ecx before the process actually exits.
• const <type> <name> = <value> allocates a .rdata entry.
• func <name> -> <int> emits a minimal function body with a mov/ret sequence.

Operators (+ - * /), let bindings, and full function bodies are tokenized already but not yet wired into codegen, that’s the next chunk of work.

Why this approach

Keeping the IR as one flat, tagged struct instead of a proper AST was a deliberate simplification for v1. It made the two-pass emit order easy to reason about and easy to debug (the interpreter dumps every function name and variable name it collected at the end of a run). It won’t scale forever, but for getting a first working pipeline from source text to a runnable Windows executable, it did the job.

Quantum IDE Used ai to make an installer because honestly I don’t know how to do it. For the most part this project is done, I may add more stuff later, but I quite like this project please be generous with the voting (●’◡’●)

Obsidian Lang – Added functions defined with func <name>(params) I also added a return opperater that kinda mimics a lambda function the token is called _RET_OP same function called but instead you do func<name>(params) -> <return_code>

Obsidian Lang - Fully dynamic coding language written in c++ & assembly. I have added a couple more tokens, but the thing I want to focus on in this dev post is the variable scopes. I know have a let and a const variable scope that allow me to do different things. According to my design const will be mutable. More progress soon

Obsidian Lang Devlog v2

You can now print hello world! Yes you heard that right with our proprietary enterprise insane level 9000 code by typing print "hello world"; it prints hello world!.

This is a huge step because to even get here and be able to use print multiple times etc. there’s a whole sorting algorithm I had to make for my interrupter to sort and build the correct assembly code dynamically. More information here: https://github.com/veefs/obsidian-lang/blob/main/docs/archecture.md

Obsidian Lang v1 - Got the basic assembly code conversation working for my programming language, dealing with a lot of annoying logic stuff related to the assembly code generation, but other than that this is an incredibly fun project already to work on I can’t want to sink in many hours. Obsidian Lang will hopefully be a capable little toy language

Finale funding pitch This E-Bulletin model will greatly help people because it provides an always-on system that can recieve commands and remind you of things you need to do. Although this is somewhat expensive to fund, please note that I will be building a custom linux OS and making this as professional as It can be, the case is already made and theres not much progress I can make, please refer to my github for more information

Finale funding pitch This E-Bulletin model will greatly help people because it provides an always-on system that can recieve commands and remind you of things you need to do. Although this is somewhat expensive to fund, please note that I will be building a custom linux OS and making this as professional as It can be, the case is already made and theres not much progress I can make, please refer to my github for more information

Made Oasis-Scan for a hackathon projected so all my time is bunched up into one bit, what Oasis-Scan does is scan your computer for all existing CVE’s and shows you how you can be hacked and what issues exist within your computer

Devlog Update! - really trying to hammer out the logistics to my project which is why in my github repo I made a concept.md, for my bulletin board I want it to run on a custom barebones linux OS that way all the drivers and such are preinstalled and it’s all super easy. Also thinking of how to add more integration to the bulletin board, and figuring out the budget https://github.com/veefs/BulletinOS/blob/main/concepts/concept.md

made a case for the entire thing, you can basically just mount it pretty easily and throw everything inside should be a tight fit as I perfectly matched the dimensions

BulletinOS Project finally started, my idea for this is to have a eletronic bulletin opperating on at least a raspberry pi 3b if not higher with a mic. You would be able to speak commands into it, use an AI to populate to-do tasks etc. So far aiming toward quite a substantial budget: $60 -> Microphone $100 -> Display $50 -> Raspberry pi 3b + (or better)$210 Total Cost