I made an open-source archiver that beats 7-Zip and WinRAR in some of my tests
▲ 2 r/windowsapps+1 crossposts

I made an open-source archiver that beats 7-Zip and WinRAR in some of my tests

I made a small open-source archiver called DedupArc.

In my tests on game folders it compressed better than 7-Zip and WinRAR while also being noticeably faster.

It also lets you launch applications from an archive without manually extracting the whole thing first.

GitHub: https://github.com/Garyu-tt/DedupArc

Would be interesting to see how it performs on other people's data. If someone finds a case where it completely falls apart, even better.

u/Holiday_Reference_41 — 11 days ago
▲ 34 r/devtools+1 crossposts

I’m building an IDE where a codebase becomes a navigable 3D semantic graph — here’s Godot mapped inside it

This is an early screenshot of Tagma Studio, an experimental IDE I’m building on top of Code-OSS.

Instead of treating a project as a hierarchy of files and folders, Tagma represents it as a semantic graph: source files, symbols, dependencies, capabilities, modules, generated artifacts and runtime relations become connected entities in one space.

The screenshot shows part of the imported Godot codebase. Around 15,000 graph entities are currently visible in this projection.

The long-term goal is not merely to create a prettier dependency viewer. I want the graph to become an actual working representation of the system:

select a subsystem and isolate its complete dependency neighborhood;

navigate from high-level concepts down to specific code;

see shared infrastructure and hidden coupling between projects;

track how the graph changes over time;

compile or assemble executable components from capabilities rather than manually chosen files;

let automated tools operate on an explicit, inspectable model instead of guessing from raw text.

The current visualization is still too dense and resembles a galaxy of code. I’m now replacing the global force-directed layout with a more neural-like topology: sparse local clusters, shared backbone tracts, late branching and a small number of meaningful long-range connections.

It is very much a work in progress, but this is the first version where the entire idea has started to become visible on screen.

What would you personally need from a graph-based IDE for it to become useful rather than just visually impressive?

u/Holiday_Reference_41 — 17 days ago
▲ 2 r/devtools+1 crossposts

I’m building a graph-native IDE where source code, project structure and runtime execution exist in one connected space

This is a small raw demo of Tagma Studio, an IDE I’m building around a graph-native programming model.

The idea is that a project should not be represented only as a tree of files. Files, functions, dependencies, data flows, runtime signals and execution paths should form one connected graph that can be explored at different levels.

In the video, I move from the full project graph to smaller local structures, open the related source files, and inspect the code behind them.

The long-term goal is to make the graph not just a visualization, but the actual working representation of the program:

files remain real editable source files;

every file can expose its own subgraph;

subgraphs remain connected to the complete project;

code execution is visible in real time;

active signals and execution paths are displayed directly on the graph;

the same structure can be used for navigation, debugging and program composition.

It is still an early prototype, so this is intentionally an unedited recording of the current working state rather than a polished concept video.

I’m interested in whether this way of navigating and understanding a codebase feels useful, or whether it currently looks too dense to read.

u/Holiday_Reference_41 — 23 days ago

When you try to solve one tiny problem and accidentally create a digital mind to solve it

I originally just wanted to stop my software from duplicating the same resources and logic across different tasks.

The idea sounded small: represent reusable entities, dependencies and capabilities as a shared semantic graph, then let the runtime assemble only the structure required for the current goal.

Several architectural rabbit holes later, this is what the live topology looks like:

149,453 indexed entities

19,393 physical neurons

21,456 physical synapses

353,080 raw relationships

shared fragments reused across multiple tasks

alternative execution routes instead of one rigid call chain

This is not an image generated by an AI model. It is a visualization of the actual internal structure of my experimental runtime, Project Tagma / MirbiOS.

It is not literally conscious—at least the debugger has filed no demands for legal personhood yet—but the system increasingly behaves less like a conventional program and more like a dynamically assembled nervous system.

I tried to remove duplicate code.

Apparently the reasonable solution was to grow a brain.

u/Holiday_Reference_41 — 25 days ago