DEV Community: Divyanshu Sinha

🚀 Announcing Pythonaibrain-Warden (v0.1.1): Industrial-Grade, npm-Inspired Package & Environment Manager for Python

Divyanshu Sinha — Mon, 24 Aug 2026 07:59:58 +0000

I am excited to announce the official release of warden (pythonaibrain-warden v0.1.1)!

Python package management often forces developers to choose between low-level speed and high-level reproducibility. I built warden to bridge this gap by introducing an npm-inspired workflow centered on a deterministic lockfile architecture, native virtual environment isolation, and hard offline build guarantees.

🌟 Why I Built `warden`

🔐 Deterministic Lockfile Enforcement (warden.lock): warden locks exact artifact URLs and SHA-256 hashes. Every installation executes via pip install <exact-artifact> --no-deps, preventing pip's resolver from silently substituting different package versions.
🔌 Thin CLI over Core API Architecture: I designed every CLI subcommand as a light wrapper around warden.core. Whether called from terminal scripts, unit tests, or programmatically via import warden.core as core, execution behavior remains identical.
🛠️ Warden-Native Environments & Absolute Paths: warden wenv constructs standard CPython virtual environments natively. Subprocess calls resolve executables to absolute paths inside the active environment (resolve_executable), eliminating cross-platform PATH resolution bugs on Windows.
🎯 Per-File Dependency Targets: Need to run two files with mutually exclusive package requirements in the same repository? warden target set provisions isolated sub-environments (.warden/venvs/target-<slug>/) and dedicated lockfiles, allowing scripts like numpy==1.24.0 and numpy==1.26.4 to live side-by-side.
🏷️ Platform Wheel Selection: Artifact resolution ranks PyPI binaries against packaging.tags.sys_tags(), preventing platform mismatch errors on C-extension wheels.
🛑 fix vs. install Separation: warden fix repairs installed-vs-locked environment drift without ever modifying project requirements in warden.toml or warden.lock.
📦 Self-Contained Offline Bundling (.warden.wheel): warden build packages project source code, manifests, locked dependencies, and build-system tools (setuptools/wheel) into zero-network archives.
🚦 CI Reproducibility Gate (warden verify): Runs deep validation across manifests, lockfile consistency, SHA-256 digests, and active environment states with stable non-zero exit codes on failure.

⚡ Quick Start

# Install warden from PyPI
pip install pythonaibrain-warden==0.1.1

# Initialize a new project layout
warden init myapp
cd myapp

# Add dependencies & sync active environment
warden install requests
warden install "flask@3.0.0"

# Execute project entry point or verify reproducibility
warden run
warden verify

📋 Command Summary

Category	Commands
Dependencies	`install` • `update` • `uninstall` • `lock`
Environments	`wenv` • `use` • `fix`
Execution	`run` • `run-file` • `exec` • `target`
Quality & Audit	`verify` • `show` • `clean` • `cache`
Bundles & Deploy	`build` • `install-wheel` • `backup` • `restore` • `publish`

🌐 Links & Resources

PyPI Release: pythonaibrain-warden 0.1.1
GitHub Repository: DivyanshuSinha136/Pythonaibrain-Warden

I Built My Own Python Package Manager. Three Bugs Taught Us More Than the Design Did.

Divyanshu Sinha — Mon, 24 Aug 2026 07:36:04 +0000

A field report from building Pythonaibrain-Warden — an npm-inspired dependency and environment manager for Python with its own lock file, its own virtual environments, and a few opinions pip doesn't share.

The itch

Python's dependency story is not broken, exactly. It's plural. pip installs things. venv isolates things. pip-tools locks things. poetry and pdm try to do all three with opinions about how. If your project needs two different versions of the same library for two different scripts — a legacy report generator still pinned to numpy==1.24 sitting next to a new one that needs numpy>=1.26 — none of them have a clean answer. You get a second virtualenv, a README note nobody reads, and a slow drift toward "just don't touch that script."

I wanted something narrower and more opinionated: own the whole vertical slice — manifest, lock file, environments, and the install step — well enough that I could make specific, sharp decisions instead of general, safe ones. That became Warden.

This isn't a pitch. It's a walkthrough of what I actually built, and — more usefully — three bugs I caught by actually running the thing, not by reading the code and nodding.

The one rule that kept the codebase sane

Before any of the interesting stuff, one boring decision paid for itself repeatedly: the CLI layer is not allowed to think.

cli.py (argparse only)
   │
   ▼
core.py  ──────────────────────►  everything else

Every warden subcommand is an argparse definition plus a two-line function that parses arguments and calls a core.* function. That's it. core.install() doesn't know it was invoked from a terminal — it takes a Manifest, a list of package names, a boolean, and returns an exit code. You can import warden.core as core and call it directly, no subprocess, no argv.

I didn't design this because it's a best practice I'd read about. I designed it because by the time Warden had grown past a dozen commands, I needed a reason to trust that "what does install actually do" had exactly one answer, not one answer per code path that happened to call it. It also meant every new feature — and there were a lot — slotted into the same shape: write the logic once in core.py, wire up a thin CLI wrapper, move on.

I didn't use `venv.EnvBuilder`. On purpose.

Every Python environment tool eventually calls venv.EnvBuilder or shells out to python -m venv. Warden doesn't. It builds the environment by hand:

Find the real base interpreter (sys._base_executable).
Create the directory layout itself.
Symlink (or copy, on Windows) the interpreter in.
Hand-write pyvenv.cfg.
Bootstrap pip via ensurepip directly.

This wasn't rebellion for its own sake — it's the same algorithm venv uses internally, just owned end to end instead of delegated to a stdlib module whose error messages and edge-case behavior I didn't control. It paid off almost immediately, because it's what led us straight into the first real bug.

Bug #1: "python" doesn't mean what you think it means on Windows

Early on, a Windows tester ran the most boring possible sequence:

warden init myapp
cd myapp
warden wenv default
warden install
warden run

And got:

D:\Program Files\python.exe: Error while finding module specification for 'myapp.main'
(ModuleNotFoundError: No module named 'myapp')

The venv existed. The package was installed into it. warden run even printed Running in env 'default' right before failing. So why was it launching D:\Program Files\python.exe — the system interpreter — instead of the one sitting three directories below it?

The answer is one of those platform facts that only bites you once you actually test on the platform: on Windows, subprocess.Popen(['python', ...], env=custom_env) does not use custom_env['PATH'] to resolve the bare name python. CreateProcess resolves the executable using the calling process's own PATH, before the child's environment ever comes into play. Prepending the venv's Scripts\ directory to a dict you're about to hand to subprocess does exactly nothing on Windows. (On POSIX it works fine, which is precisely why this kind of bug survives testing on a Mac and ships broken to everyone else.)

The fix wasn't a workaround bolted onto the Windows case — it was to stop relying on PATH search at all:

def resolve_executable(env_path: Path, name: str) -> str:
    if name in ("python", "python3", "py"):
        p = python_path(env_path)
        if p.is_file():
            return str(p)
    ...
    return name  # fall back to PATH search only for things the env doesn't provide

Every command Warden spawns now resolves to an absolute path inside the target environment before it's ever launched. Correct on Windows because there's no PATH ambiguity left to exploit; correct on POSIX because it always was, and now it's explicit instead of accidental.

Different files, different dependency versions, same project

Here's the feature I're most pleased with, and it's the direct answer to the "legacy script vs. new script" problem from the opening:

[targets]
"scripts/legacy_report.py" = { numpy = "==1.24.0" }
"scripts/new_report.py"    = { numpy = "==1.26.4" }

myproject/
 ├── scripts/legacy_report.py   → numpy==1.24.0
 └── scripts/new_report.py      → numpy==1.26.4

The important design choice here was resisting the urge to invent something clever. A "target" isn't a special sandboxed sub-concept — it's a completely ordinary Warden environment with an auto-generated name (target-scripts-legacy-report-py), its own real lock file, and it shows up in warden wenv list next to everything else. warden run-file scripts/legacy_report.py just looks up whether that file has an override, and if it does, routes to that environment — auto-provisioning it on first use if it isn't set up yet.

I tested this with two files pinned to two different click versions in the same project, with the project's own default environment sitting on a third version, just to make sure nothing was quietly sharing state:

$ warden run-file scripts/file1.py
! WARN Target env 'target-scripts-file1-py' isn't set up yet -- provisioning it now.
==> Resolving target 'scripts/file1.py' -> env 'target-scripts-file1-py'
✓ Locked 1 package(s)
✓ click==8.0.0 installed
file1.py running with click 8.0.0

$ warden run-file scripts/file2.py
! WARN Target env 'target-scripts-file2-py' isn't set up yet -- provisioning it now.
✓ click==8.4.2 installed
file2.py running with click 8.4.2

$ .warden/venvs/default/bin/python -c "import click; print(click.__version__)"
8.1.7

Three environments, three versions, one project, and nothing silently sharing site-packages with anything else.

The bug that only showed up completely offline

This one's our favorite, because it's a genuine two-layer bug and neither layer looks like a bug from the surface.

Warden can package a project into a .warden.wheel — source, lock file, and (by default) every dependency's actual .whl file bundled in, so the whole thing installs without touching the network. A tester built one, disconnected from the internet, and ran:

python -m warden install-wheel myapp-0.1.0.warden.wheel

Everything vendored installed fine. Then, right at the end:

==> Installing the project itself in editable mode
! WARN Could not editable-install the project itself: ...
error: subprocess-exited-with-error
pip subprocess to install build dependencies did not run successfully.

Followed, inevitably, by warden run failing with ModuleNotFoundError: No module named 'myapp' — because the package genuinely never got installed.

Here's the thing: I'd vendored every runtime dependency. So why did anything need the network at all?

pip install -e . doesn't just install your package. By default it uses PEP 517 build isolation — it spins up an ephemeral, throwaway environment and fetches setuptools and wheel into it from PyPI, every single time, to actually perform the build. Those two packages aren't runtime dependencies. They're not in warden.lock. I had never even thought to vendor them.

And the reason a freshly created environment couldn't just use its own copy: I checked.

$ python3 -m venv fresh
$ fresh/bin/python -c "import setuptools"
ModuleNotFoundError: No module named 'setuptools'

Modern CPython's ensurepip stopped bundling setuptools and wheel. It used to. It doesn't anymore. A brand-new venv today has exactly one thing in it: pip.

The fix needed both ends:

At build time, vendor the project's build-system requirements too — read [build-system].requires out of pyproject.toml, resolve and cache setuptools/wheel the same way I do runtime dependencies, and drop them in vendor/ alongside everything else.

At install time, before attempting the editable install, install those from the local vendor directory via pip --no-index --find-links, then run the editable install with --no-build-isolation — which tells pip "don't try to fetch anything, use what's already here."

def ensure_build_tools(python_exe, vendor_dir=None):
    if run_cmd([python_exe, "-c", "import setuptools, wheel"]).ok:
        return True
    args = [python_exe, "-m", "pip", "install", "--disable-pip-version-check"]
    if vendor_dir is not None:
        args += ["--no-index", "--find-links", str(vendor_dir)]
    return run_cmd(args + ["setuptools", "wheel"]).ok

I didn't trust this until I'd actually broken the network to test it — not "ran it with --no-vendor unset and assumed," but literally monkeypatched socket.getaddrinfo to raise for pypi.org and files.pythonhosted.org mid-run:

def blocked_getaddrinfo(host, *a, **kw):
    if host in ('pypi.org', 'files.pythonhosted.org'):
        raise socket.gaierror('simulated offline')
    return _orig(host, *a, **kw)
socket.getaddrinfo = blocked_getaddrinfo

Then ran install-wheel and run against it. Both succeeded. That's the difference between "should work offline" and "works offline" — one of them I'd have shipped confidently and been wrong.

A quieter bug: brackets are not decoration

Adding progress bars and tables (via rich) was mostly straightforward, except for one thing I almost missed entirely. rich parses plain strings passed to Table cells and console.status() as markup by default — [green]text[/] becomes styled green text. Convenient, until you print something that legitimately contains square brackets for an unrelated reason:

>>> table.add_row('pkg[extra1,extra2]>=1.0')

renders as:

pkg>=1.0

The extras syntax — completely standard PEP 508 dependency specification — got silently eaten. In a package manager, silently corrupting a dependency specifier in displayed output is merely embarrassing. It's the kind of bug that's obvious the second you see it and invisible until you specifically go looking, because the common case (requests==2.31.0) never has a bracket in it.

The fix was mechanical once I knew to look for it: never hand rich a raw dynamic string. Always wrap it in Text(), which bypasses markup parsing entirely.

# wrong: table.add_row(spec_string)
# right:
from rich.text import Text
table.add_row(Text(spec_string))

I went back through every table, every status spinner, every place a package name or version spec touched rich output, and fixed each one — then wrote a one-line regression test I now run whenever this code path changes: feed it pkg[extra1,extra2]>=1.0 and confirm the brackets survive.

What I'd tell you if you're building something similar

Test the platform you're least likely to be sitting in front of. The Windows PATH bug and the "ensurepip doesn't bundle setuptools anymore" bug both share a shape: they're invisible if you only ever develop and test on the same machine, in the same network conditions, on the same OS. Neither was hard to fix once found. Both were completely invisible in code review.

A library's convenience default is not automatically your correctness default. rich's markup-everywhere behavior is genuinely nice for 95% of use cases. It's actively wrong for a tool whose entire job is displaying user-supplied strings verbatim. pip's build isolation is genuinely the right default for "run pip install on a random package." It's the wrong default when you've already made an explicit, hash-verified promise about what's installed and where it came from.

Reuse the abstraction you already trust instead of inventing a parallel one. Per-file dependency targets could have been a bespoke sandboxing feature. Instead it's "an environment, but the name is computed instead of typed" — which meant it inherited every bit of correctness work already put into environment creation, activation, and locking, instead of needing its own.

None of this is finished, and that's fine to say out loud. Warden's resolver is deliberately greedy, not backtracking — a real diamond-dependency conflict gets reported clearly instead of resolved cleverly, which is a trade I're happy with but which I say plainly in the docs rather than let people discover. Per-target locks re-resolve independently rather than sharing work across targets. Being specific about what a tool doesn't do is, I'd argue, more useful to the next person than a features list that implies it does everything.

Warden is npm-inspired, not npm-derived: its own manifest (warden.toml), its own hash-pinned lock file (warden.lock), and environments it builds and owns itself rather than delegating to venv. Full command reference in CLI-REFERENCE.md, internal design writeup in ARCHITECTURE.md.

Resources

PyPI: https://pypi.org/project/pythonaibrain-warden
GitHub: https://github.com/DivyanshuSinha136/pythonaibrain-warden
Architecture: https://github.com/DivyanshuSinha136/Pythonaibrain-Warden/blob/main/ARCHITECTURE.md
CLI Reference: https://github.com/DivyanshuSinha136/Pythonaibrain-Warden/blob/main/CLI-REFERENCE.md
Issues: https://github.com/DivyanshuSinha136/Pythonaibrain-Warden/issues

Pythonaibrain-NLP 0.2.0 Is Now on PyPI — A Structured NLU/NLG Architecture for Python

Divyanshu Sinha — Fri, 21 Aug 2026 15:28:55 +0000

Today I'm releasing Pythonaibrain-NLP 0.2.0, the latest public release of my Python NLP framework.

The package is now available on PyPI, and the complete source code, documentation, architecture notes, examples, and tests are available on GitHub.

PyPI: https://pypi.org/project/Pythonaibrain-NLP/
GitHub: https://github.com/DivyanshuSinha136/Pythonaibrain-NLP

Install it with:

pip install pythonaibrain-nlp

Why another NLP framework?

Pythonaibrain-NLP was built around a different idea.

Instead of making a transformer the center of everything, I wanted to build a more structured NLP system where understanding, dialogue state, retrieval, and generation are explicit components of the architecture.

The current system combines:

Neural intent classification
Slot filling
Dialogue context
Retrieval-augmented responses
Neural language generation
A controllable NLG architecture
Standalone NLU and NLG APIs

The goal isn't to replace every modern NLP architecture.

The goal is to provide a structured, understandable, trainable NLP pipeline that can be integrated into Python applications.

The architecture

The core pipeline is:

                 User Input
                     │
                     ▼
              ┌─────────────┐
              │     NLU     │
              │             │
              │ Intent      │
              │ + Slots     │
              └──────┬──────┘
                     │
                     ▼
            ┌─────────────────┐
            │ Dialogue State  │
            │   + Context     │
            └────────┬────────┘
                     │
             ┌───────┴────────┐
             ▼                ▼
        Function/API         RAG
        Dispatch             Retrieval
             │                │
             └───────┬────────┘
                     ▼
              ┌─────────────┐
              │     NLG     │
              │   SC-LSTM   │
              └──────┬──────┘
                     │
                     ▼
                 Response

This separation makes each stage independently accessible and easier to experiment with.

NLU

The NLU subsystem uses a joint neural architecture for:

Intent classification + slot tagging

The model is designed to understand both what the user wants and which pieces of information are present in the input.

For example, a request such as:

"Book a flight to Delhi tomorrow"

can be represented through an intent together with structured slot information rather than treating the entire sentence as an opaque classification problem.

This structured representation can then be passed to the dialogue and application layers.

NLG with SC-LSTM

One of the central parts of Pythonaibrain-NLP is its Semantically-Controlled LSTM (SC-LSTM) based NLG system.

The idea is to condition generation on semantic information rather than simply generating text from an unconstrained language representation.

That gives the application a much more explicit relationship between:

Semantic representation
        ↓
   NLG controller
        ↓
   Generated text

This is particularly useful for task-oriented dialogue systems where the generated response should correspond to a known semantic intent.

Dialogue context

Pythonaibrain-NLP also maintains conversational information through:

Slot memory
Turn history
Dialogue context

This allows the system to work with multi-turn interactions rather than processing every sentence completely independently.

A conversation can therefore evolve as structured state instead of being treated as a sequence of unrelated strings.

Retrieval

The framework includes a lightweight retrieval component based on TF-IDF and cosine similarity.

This provides a simple way to retrieve relevant information when the system needs knowledge from a local corpus.

The important part here is that retrieval doesn't have to replace the rest of the NLP pipeline.

It can participate in the overall decision process:

NLU
 ↓
Intent + Slots
 ↓
Application logic / Retrieval
 ↓
NLG
 ↓
Response

No transformer dependency

Pythonaibrain-NLP does not require a transformer architecture for its core NLP pipeline.

Instead, it uses recurrent neural architectures and structured components.

That makes the project interesting for situations where developers want:

Explicit NLP components
Smaller specialized models
Trainable task-oriented systems
Understandable architecture
Local execution
Greater control over the processing pipeline

This isn't an argument that transformers are bad.

It's simply a different engineering trade-off.

A complete NLP pipeline

The interesting part of the project isn't one model by itself.

It's the combination.

Pythonaibrain-NLP brings together:

                 ┌──────────────┐
                 │     NLU      │
                 └──────┬───────┘
                        │
                 Intent + Slots
                        │
                        ▼
              ┌──────────────────┐
              │ Dialogue Context │
              └────────┬─────────┘
                       │
                 ┌─────┴─────┐
                 │           │
                 ▼           ▼
             Retrieval    Application
                 │           │
                 └─────┬─────┘
                       │
                       ▼
                 ┌───────────┐
                 │    NLG    │
                 └─────┬─────┘
                       │
                       ▼
                    Response

Each layer has a defined responsibility.

That structure is one of the main things I wanted from the project.

What is included in 0.2.0?

The repository includes:

NLU implementation
NLG implementation
SC-LSTM generation
Intent classification
Slot tagging
Dialogue context
TF-IDF/cosine retrieval
Training utilities
Evaluation functionality
Examples
Tests
API reference
Architecture documentation

The project also includes measured experiments and evaluation information in the repository rather than presenting the architecture only as a theoretical design.

Installation

pip install pythonaibrain-nlp

Then import the package from Python and use the APIs documented in the project.

The repository contains examples for getting started.

Open source

The complete project is available on GitHub:

https://github.com/DivyanshuSinha136/Pythonaibrain-NLP

And the package is available on PyPI:

https://pypi.org/project/Pythonaibrain-NLP/

What's next?

Version 0.2.0 is now the public baseline.

Future development can build on top of this foundation rather than changing the fundamental direction of the project.

I'm particularly interested in seeing what developers can build with the architecture and where the limitations become apparent when it is used outside my own experiments.

That's one of the most useful parts of releasing a project publicly: the architecture stops being something that exists only on my machine.

It becomes something other people can install, inspect, test, extend, and challenge.

Pythonaibrain-NLP 0.2.0 is now public. 🚀

If you're interested in structured NLU/NLG systems, dialogue architectures, recurrent neural NLP, or building NLP systems directly in Python, I'd love to see what you do with it.

Beyond Tooling Hell: A New Way to Teach Operating System Development

Divyanshu Sinha — Wed, 29 Jul 2026 10:37:19 +0000

Most people who try to learn Operating System development give up before they even change a single pixel on the screen. They get stuck in "tooling hell"—wrestling with arcane linker scripts, complex assembler syntax, and brittle build systems.

I wrote Operating System Development with Aetherix (2nd Edition) to offer a different path. This book isn't just about a toolkit, it's a ground-up guide to the physical and logical reality of how a computer actually boots and runs code.

What’s different about this book:

Minimal Prerequisites: The only prerequisite is ordinary arithmetic. We start by manually converting binary and hexadecimal to understand how code physically becomes a voltage on a wire.
The Language of Bytes: Instead of teaching an assembler’s syntax, this book teaches x86 machine code as its own language. You’ll learn to read and write raw bytes, understanding the ModR/M and SIB fields that define CPU instructions.
A "From-Scratch" Reference: Many chapters function as standalone references for computer science fundamentals. We dive deep into logic gates, flip-flops, memory hierarchies (DRAM/SRAM), and even the physics of how NAND flash traps an electrical charge.
Modern vs. Legacy Firmware: The book provides an honest, separate look at both the 16-bit BIOS real-mode world and the modern 64-bit UEFI long-mode environment, acknowledging that they share almost nothing at the byte level.
Verification Culture: We don't assume code works because it "looks right". Every concept is verified against independent tools like objdump and the Unicorn Engine CPU emulator to ensure absolute correctness.

This book is about transparency and honesty. It documents real bugs caught during development to teach you the discipline required for low-level programming. Whether you're a student or a hobbyist, my goal is to show you exactly what is happening at the byte level, from power-on sequencing to network framing.

The project is fully open-source under the GNU AGPL-3.0-or-later license.

Source:

Book Link:
https://github.com/DivyanshuSinha136/Aetherix/blob/main/book/Operating_System_with_Aetherix_ED2.pdf

GitHub Page:

DivyanshuSinha136 / Aetherix

A Python-native operating system development framework for building bootable x86 and x86_64 systems. Aetherix supports both legacy BIOS and modern UEFI firmware, generates machine code directly through its own native encoder, and provides high-level APIs alongside low-level instruction control.

Aetherix

A Python-native operating system development framework for building bootable x86 and x86_64 systems. Aetherix supports both legacy BIOS and modern UEFI firmware, generates machine code directly through its own native encoder, and provides high-level APIs alongside low-level instruction control.

from aetherix import Project

with Project("MyOS") as os:

    @os.kernel_entry
    def main(prog, drivers):
        drivers.vga.clear(prog)
        drivers.vga.print_string(prog, "Hello, world!")
        prog.hlt()

    os.build("myos.img")

qemu-system-i386 -drive file=myos.img,format=raw

Or write it to a USB stick: sudo dd if=myos.img of=/dev/sdX bs=4M status=progress (VirtualBox/VMware also accept the raw .img/.bin directly as a virtual disk.)

Install

pip install -e .

Requires a C compiler (gcc/clang/MSVC) on the machine building the package — the native encoder core is compiled once, either at install time or…

View on GitHub

PyPI Page:

pypi.org

Preview

Operating System with Aetherix book

Divyanshu Sinha — Mon, 20 Jul 2026 14:11:36 +0000

To celebrate the framework's release, I have also published a complete textbook: Operating System with Aetherix 📖.

It is a from-scratch guide to x86 operating system and UEFI application development. It breaks down how Aetherix works under the hood and teaches low-level computer architecture without using intermediate assembly language.

Inside the book:

No external tools: How Aetherix completely bypasses nasm, gcc, and ld.
Deep x86 internals: Manipulating ModR/M byte layouts, reading raw machine code hexabytes, and addressing memory segments.
Pure Python compilation: How a native C core handles binary machine-code encoding through standard-library ctypes bridges.
Extensible Ecosystem: How to use the native Hardware Abstraction Layer (HAL) to write custom peripheral drivers.

The entire framework is packed into a tiny, zero-dependency 204 KB footprint. The book is open-source.

Read the full textbook directly on my GitHub repository:
👉 https://github.com/DivyanshuSinha136/Aetherix/blob/main/Operating_System_with_Aetherix.pdf

Building an Interactive Shell in Python with Aetherix

Divyanshu Sinha — Sun, 19 Jul 2026 17:36:46 +0000

One of the first milestones after printing text to the screen is creating an operating system that responds to user input.

This example boots into a simple interactive shell built with Aetherix. Instead of displaying predefined text, it continuously reads keyboard input and updates the screen in real time.

Aether Shell Video Click to view

What it demonstrates

Despite being under 200 lines of Python, this example implements several core OS features:

⌨️ Real-time keyboard input
🔠 Shift-aware typing (uppercase and symbols)
🖥️ Runtime VGA text terminal with a moving cursor
⏎ Enter and Backspace support
🔊 PC speaker beep (F1)
🔄 Hardware reboot (F2)
⏻ Power-off (F3, emulator dependent)
🛑 Graceful halt on Escape

Unlike a scripted demo, what appears on screen depends entirely on what the user types.

Source code

"""
aether_shell -- a genuinely interactive example OS.

Unlike hello_os.py (which prints a few fixed, compile-time-known messages
and waits for one keypress), this boots into a live loop: it reads your
keyboard input in real time -- Shift and all -- and echoes it to the
screen using a runtime VGA cursor (aetherix.drivers.terminal) that
actually moves, wraps at the end of a row, and responds to
Enter/Backspace. There is no fixed script of what appears where; what
shows up on screen depends on what you type.

Controls:
    (letters, digits, punctuation, space)   echoed as typed
    Shift                                    uppercase letters, shifted symbols
    Enter                                    move to the next line
    Backspace                                erase the previous character
    F1                                        beep the PC speaker
    F2                                        reboot (hardware reset)
    F3                                        shutdown (QEMU/Bochs only --
                                               see aetherix.drivers.power)
    Esc                                       goodbye message, then halt

Run:
    python examples/aether_shell.py

Then boot the produced image in an emulator, e.g.:
    qemu-system-i386 -drive file=aether_shell.img,format=raw

Or verify it under CPU emulation without needing QEMU installed:
    pip install unicorn
    python tests/emulate.py build/aether_shell.img
"""
from os import system as s
from aetherix import Project, regs

with Project("AetherShell", boot_message="AetherShell starting...") as os_:

    @os_.kernel_entry
    def main(prog, drivers):
        vga = drivers.vga
        kb = drivers.keyboard
        term = drivers.terminal
        power = drivers.power

        kb.init(prog)  # zero the Shift-state flag
        vga.clear(prog)
        vga.print_string(prog, "AetherShell v0.2 -- a live Aetherix demo OS",
                          row=0, col=0, attr=vga.GREEN_ON_BLACK)
        vga.print_string(prog, "Type (Shift works!). Enter=newline  Backspace=erase",
                          row=1, col=0)
        vga.print_string(prog, "F1=beep  F2=reboot  F3=shutdown  Esc=halt",
                          row=2, col=0)
        term.init(prog, start_row=4)

        prog.label("shell_loop")
        kb.wait_key_scancode(prog)  # blocks; raw scancode (make OR break) ends up in AL

        prog.cmp8(regs.AL, kb.SCANCODE_ESCAPE)
        prog.jcc(regs.JZ, "shell_halt")
        prog.cmp8(regs.AL, kb.SCANCODE_ENTER)
        prog.jcc(regs.JZ, "shell_enter")
        prog.cmp8(regs.AL, kb.SCANCODE_BACKSPACE)
        prog.jcc(regs.JZ, "shell_backspace")
        prog.cmp8(regs.AL, kb.SCANCODE_F1)
        prog.jcc(regs.JZ, "shell_beep")
        prog.cmp8(regs.AL, kb.SCANCODE_F2)
        prog.jcc(regs.JZ, "shell_reboot")
        prog.cmp8(regs.AL, kb.SCANCODE_F3)
        prog.jcc(regs.JZ, "shell_shutdown")

        # Shift press/release: update the flag keyboard.read_char also
        # uses, then go straight back to waiting -- Shift never prints.
        prog.cmp8(regs.AL, kb.SCANCODE_LSHIFT)
        prog.jcc(regs.JZ, "shell_shift_on")
        prog.cmp8(regs.AL, kb.SCANCODE_RSHIFT)
        prog.jcc(regs.JZ, "shell_shift_on")
        prog.cmp8(regs.AL, kb.SCANCODE_LSHIFT | kb.BREAK_BIT)
        prog.jcc(regs.JZ, "shell_shift_off")
        prog.cmp8(regs.AL, kb.SCANCODE_RSHIFT | kb.BREAK_BIT)
        prog.jcc(regs.JZ, "shell_shift_off")

        # Any other break code (bit 7 set) -- ignore, don't echo on release.
        prog.test_al(kb.BREAK_BIT)
        prog.jcc(regs.JNZ, "shell_loop")

        # Dispatch any other recognized key, Shift-aware: compare the
        # scancode against each known entry and, on a match, print
        # whichever of its two (compile-time-known) characters matches
        # the current runtime Shift state. Same technique
        # keyboard.read_char uses internally, inlined here because this
        # loop also needs to catch Enter/Backspace/F-keys in the same
        # pass, which read_char deliberately doesn't return for.
        all_codes = sorted(set(kb.SCANCODE_SET1_ASCII) | set(kb.SCANCODE_SET1_SHIFTED))
        for code in all_codes:
            skip_label = prog.unique_label("key_skip")
            use_shifted_label = prog.unique_label("key_use_shifted")
            unshifted_ch = kb.SCANCODE_SET1_ASCII.get(code, kb.SCANCODE_SET1_SHIFTED.get(code))
            shifted_ch = kb.SCANCODE_SET1_SHIFTED.get(code, unshifted_ch)

            prog.cmp8(regs.AL, code)
            prog.jcc(regs.JNZ, skip_label)
            prog.load8(regs.BL, kb.SHIFT_STATE_VAR)
            prog.cmp8(regs.BL, 0)
            prog.jcc(regs.JNZ, use_shifted_label)
            term.putchar_imm(prog, unshifted_ch)
            prog.jmp("shell_loop")
            prog.label(use_shifted_label)
            term.putchar_imm(prog, shifted_ch)
            prog.jmp("shell_loop")
            prog.label(skip_label)

        prog.jmp("shell_loop")  # unrecognized key -- ignore and keep waiting

        prog.label("shell_shift_on")
        prog.store8(kb.SHIFT_STATE_VAR, 1)
        prog.jmp("shell_loop")

        prog.label("shell_shift_off")
        prog.store8(kb.SHIFT_STATE_VAR, 0)
        prog.jmp("shell_loop")

        prog.label("shell_enter")
        term.newline(prog)
        prog.jmp("shell_loop")

        prog.label("shell_backspace")
        term.backspace(prog)
        prog.jmp("shell_loop")

        prog.label("shell_beep")
        drivers.speaker.beep(prog, frequency_hz=880, duration_iterations=1_500_000)
        prog.jmp("shell_loop")

        prog.label("shell_reboot")
        vga.print_string(prog, "Rebooting...", row=24, col=0, attr=vga.YELLOW_ON_BLACK)
        power.reboot(prog)

        prog.label("shell_shutdown")
        vga.print_string(prog, "Shutting down...", row=24, col=0, attr=vga.YELLOW_ON_BLACK)
        power.shutdown(prog)

        prog.label("shell_halt")
        vga.print_string(prog, "Goodbye! System halted.", row=24, col=0, attr=vga.YELLOW_ON_BLACK)
        prog.hlt()

    out = os_.build(str("aether_shell.img"))
    print(f"Built: {out} ({out.stat().st_size} bytes)")
    print(f"Kernel sectors: {(len(os_.kernel.assemble()) + 511) // 512}")
    print("Boot it with: qemu-system-i386 -drive file=aether_shell.img,format=raw")
    s("qemu-system-i386 -drive file=aether_shell.img,format=raw")

Why this example is interesting

Traditional hobby OS tutorials often require writing hundreds of lines of C and Assembly before reaching this level of interactivity.

With Aetherix, the example focuses on the shell's behavior:

Wait for a key
Decide what action to perform
Update the terminal
Repeat

The framework provides the boot process, VGA output, keyboard driver, terminal driver, power management, and machine code generation, allowing the example to stay focused on the operating system logic.

From Python Code to a Bootable Graphics OS

Divyanshu Sinha — Sun, 19 Jul 2026 15:03:41 +0000

One of the classic milestones in hobby operating system development is switching from text mode to graphics mode. In this example, Aetherix boots into VGA Mode 13h, plays a loading animation, renders a full-screen background, and composites a logo all from Python code that builds a bootable disk image.

Highlights

🎞️ Loading animation
🎨 VGA Mode 13h graphics
🖼️ Full-screen background rendering
🪟 Logo compositing
💾 Bootable disk image generation
🐍 Written in Python with Aetherix

The example preprocesses images at build time, generating a shared VGA palette for the background and logo. When the system boots, the kernel simply renders the prepared pixel data, resulting in a fast graphical startup.

Source code

from os import system as s
from pathlib import Path

from aetherix import Project, imaging
from aetherix.drivers import graphics

ASSETS_DIR = Path(__file__).resolve().parent / "assets"

# -- Prepare assets at build time (resizing/quantizing happens here, not
#    at boot -- the kernel only ever handles already-prepared bytes) --
loading_frames = [
    imaging.load_image(ASSETS_DIR / f"loading_{i}.png") for i in range(6)
]

# background and logo will be on screen AT THE SAME TIME, so they must
# share one 256-color palette -- VGA Mode 13h has a single palette for the
# whole screen, not one per image (see imaging.load_images_shared_palette).
background, logo = imaging.load_images_shared_palette([
    (ASSETS_DIR / "background.png", graphics.GFX_WIDTH, graphics.GFX_HEIGHT, True),
    (ASSETS_DIR / "logo.png", 64, 64, False),
])

LOGO_X = (graphics.GFX_WIDTH - logo.width) // 2
LOGO_Y = (graphics.GFX_HEIGHT - logo.height) // 2

with Project("GraphicsOS", graphics_mode=graphics.MODE_13H) as os_:

    @os_.kernel_entry
    def main(prog, drivers):
        # 1. Loading animation -- plays once, then falls through.
        drivers.graphics.play_frames(prog, loading_frames, delay_iterations=3_000_000, loop=False)

        # 2. Home screen -- background, then a logo composited on top.
        drivers.graphics.show_image(prog, background, x=0, y=0)
        drivers.graphics.show_image(prog, logo, x=LOGO_X, y=LOGO_Y)

        prog.hlt()

    out = os_.build(str("graphics_os.img"))
    print(f"Built: {out} ({out.stat().st_size} bytes)")
    print(f"Kernel sectors: {(len(os_.kernel.assemble()) + 511) // 512}")
    print("Boot it with: qemu-system-i386 -drive file=graphics_os.img,format=raw")
    s("qemu-system-i386 -drive file=graphics_os.img,format=raw")

Getting Started

Install Aetherix:

pip install aetherix

Resources

PiPY: https://pypi.org/project/aetherix/
GitHub: https://github.com/DivyanshuSinha136/Aetherix

⭐ If you find Aetherix interesting, consider giving the repository a star on GitHub. Feedback, ideas, and contributions are always welcome!

Building My First UEFI Application in Python with Aetherix

Divyanshu Sinha — Sun, 19 Jul 2026 14:23:54 +0000

Building a bootable UEFI application entirely in Python — no NASM, no linker, and no C compiler for the EFI binary.

What makes this interesting is that the .efi executable itself wasn't produced from C or assembly source. The program was written in Python using Aetherix, which emits the required machine code and packages it into a valid UEFI executable.

from aetherix.uefi.app import UefiApp
from aetherix.uefi import console, keyboard, diskimage
from aetherix import regs

app = UefiApp()

@app.entry
def main(prog, sys_table):
    console.clear_screen(prog, sys_table)
    console.set_cursor_position(prog, sys_table, 0, 0)
    console.println(prog, "Hello from Aetherix UEFI!", sys_table)
    console.println(prog, "", sys_table)
    console.println(prog, "This machine code was generated entirely by aetherix.uefi --", sys_table)
    console.println(prog, "no nasm, no ld, no C compiler toolchain for the .efi itself.", sys_table)
    console.println(prog, "", sys_table)
    console.println(prog, "Press any key to continue...", sys_table)
    keyboard.read_key(prog, sys_table, regs.R12, regs.R13)

    console.set_cursor_position(prog, sys_table, 0, 8)
    console.println(prog, "Key received. Returning control to firmware.", sys_table)

efi_path = app.build(str("uefi_hello.efi"))
print(f"Built: {efi_path} ({efi_path.stat().st_size} bytes)")

img_path = diskimage.write_disk_image(efi_path.read_bytes(), str("uefi_hello.img"))
print(f"Built: {img_path} ({img_path.stat().st_size} bytes)")
print(r'Boot it with: qemu-system-x86_64 -drive if=pflash,format=raw,readonly=on,file="D:\Program Files\qemu\share\edk2-x86_64-code.fd" -drive if=pflash,format=raw,file=.\vars.fd -drive file=uefi_hello.img,format=raw')

Resources

📦 Install

pip install aetherix

🔗 GitHub

https://github.com/DivyanshuSinha136/Aetherix

⭐ If you enjoyed this article, consider starring the repository.
Feedback and contributions are always welcome!

Introducing Aetherix 0.1.0 – Build Operating Systems with Python

Divyanshu Sinha — Sun, 19 Jul 2026 10:18:02 +0000

Today I'm excited to release Aetherix 0.1.0 on PyPI.

Aetherix is an open-source Python framework for experimenting with operating system development. The goal is to make low-level OS concepts more approachable while still allowing developers to build real bootable projects.

Current features include:

BIOS boot support
UEFI support
x86 target
VGA graphics support
Bootloader generation
Driver framework
Python-first API for building OS components

Install it with:

pip install aetherix

Quick Start:

from aetherix import Project

with Project("MyOS") as os:

    @os.kernel_entry
    def main(prog, drivers):
        drivers.vga.clear(prog)
        drivers.vga.print_string(prog, "Hello, world!")
        prog.hlt()

    os.build("myos.img")

qemu-system-i386 -drive file=myos.img,format=raw

Or write it to a USB stick: sudo dd if=myos.img of=/dev/sdX bs=4M status=progress conv=fsync
(VirtualBox and VMware also accept the raw .img/.bin directly as a virtual disk.)

GitHub: https://github.com/DivyanshuSinha136/Aetherix/
PyPI : https://pypi.org/project/aetherix/

This is just the first public release, and there is still a lot to improve. I'd really appreciate feedback, bug reports, feature requests, and contributions from the community.

If you've ever wanted to explore OS development without starting entirely from C or Assembly, I'd love to hear what you think.

I Built VoxMark — A Declarative Language for Interactive Documents and Web Applications

Divyanshu Sinha — Fri, 03 Jul 2026 18:51:39 +0000

Over the past several months, I've been working on VoxMark, a project that started as an idea to make writing interactive documents simpler.

Today, I'm excited to share that VoxMark 1.0.0 is officially available on PyPI.

What is VoxMark?

VoxMark is a declarative markup language built around VML (VoxMark Language). It extends familiar Markdown-style authoring with interactive widgets, layouts, and application-oriented components while compiling to static web assets.

Instead of writing large amounts of HTML, CSS, and JavaScript, you describe your document using VML syntax.

For example:

::alert[success]{
Your project has been built successfully.
}

::card[Welcome]{
This content is inside an interactive card.
}

::icon[rocket|1.2em|#f59e0b]{} Launch

The compiler generates HTML, CSS, a lightweight JavaScript loader, and a WebAssembly module. The JavaScript's role is simply to bootstrap the page and load the compiled WebAssembly module, where the runtime logic resides.

Features

Current features include:

Interactive widgets
Cards, alerts, tabs, timelines, progress bars, badges, collapsible sections, and more
Built-in SVG icon library with 209 icons
Syntax highlighting
Variables and reusable components
Include system for modular documents
HTML generation
WebAssembly modules
Development server
Project scaffolding
Source formatter
Linter
AST viewer
File watcher for automatic rebuilds

Documentation Written in VoxMark

One milestone I'm particularly happy about is that the official documentation is written entirely in VML.

The documentation isn't written in Markdown and converted later—it is authored directly using the language itself and compiled with the VoxMark compiler.

In other words, VoxMark is now dogfooding its own technology.

Installation

Install directly from PyPI:

pip install voxmark

Show the available commands:

python -m voxmark --help

Create Project:

python -m voxmark init <project name>/

cd <project name>

Edit generated *.vml file inside project directory.

Compile a document:

python -m voxmark compiler --build <file name>.vml -o build/

Serve it locally:

python -m voxmark server build/

How VoxMark Looks After Compilation

One of the goals of VoxMark is to let authors write declarative VML while generating polished, interactive web pages. Here are a few examples of the compiled output.

📊 Graph Widgets

📦 Embedded Content

🎨 Custom Styling

📈 Charts

🚀 Hero Sections

Why I Built It

My goal wasn't to replace HTML.

Instead, I wanted a language that lets authors focus on content and structure while still being capable of building interactive documentation and lightweight web applications.

I also wanted the syntax to stay approachable for people already familiar with Markdown while providing richer capabilities through widgets.

What's Next?

This is only the beginning.

Future work includes expanding the widget ecosystem, improving the compiler, enhancing the developer experience, and continuing to refine the language based on feedback from the community.

Links

📦 PyPI: https://pypi.org/project/voxmark/

📖 Documentation: https://divyanshusinha136.github.io/VoxMark-Language/

💻 GitHub: https://github.com/DivyanshuSinha136/VoxMark-Language/

I'd love to hear your thoughts, suggestions, and ideas. Feedback from the developer community will help shape the next versions of VoxMark.

How I Generated a 100-Million-Pixel Julia Set on a 4 GB RAM PC Using Python

Divyanshu Sinha — Wed, 17 Jun 2026 19:52:22 +0000

Fractals have fascinated programmers for decades.

From the Mandelbrot Set to Julia Sets, these mathematical structures can generate breathtaking patterns from surprisingly simple equations.

The challenge isn't generating a fractal.

The challenge is generating one at extreme resolutions.

A 10,000 × 10,000 image contains:

100,000,000 pixels

That's 100 million pixels.

Many image-generation approaches attempt to store the entire image in memory before saving it to disk. At these resolutions, memory consumption can quickly become a problem.

This is where pyaitk.CLSE's StreamingWriter becomes useful.

Instead of building the entire image in RAM, rows are generated and written directly to disk.

In this article, we'll create a 10K Julia Set fractal while keeping memory usage under control.

The Code

from pyaitk.CLSE import StreamingWriter

WIDTH = 10000
HEIGHT = 10000

MAX_ITER = 300

C_REAL = -0.7
C_IMAG = 0.27015

with StreamingWriter(
    "julia_10k.png",
    width=WIDTH,
    height=HEIGHT,
    bpp=24
) as sw:

    for py in range(HEIGHT):

        row = []

        zy = ((py / HEIGHT) * 3.0) - 1.5

        for px in range(WIDTH):

            zx = ((px / WIDTH) * 3.0) - 1.5

            iteration = 0

            while (
                zx * zx + zy * zy < 4.0 and
                iteration < MAX_ITER
            ):

                temp = zx * zx - zy * zy + C_REAL
                zy = 2.0 * zx * zy + C_IMAG
                zx = temp

                iteration += 1

            color = int(
                255 * iteration / MAX_ITER
            )

            row.append(
                (
                    color,
                    color // 2,
                    255 - color
                )
            )

        sw.write_row(row)

The result is a massive Julia Set image containing intricate fractal structures across 100 million pixels.

Why Julia Sets?

Julia Sets are generated by repeatedly applying a complex mathematical function.

The equation used is:

z = z² + c

where:

c = -0.7 + 0.27015i

Each pixel becomes a point in the complex plane.

The algorithm repeatedly evaluates the equation until either:

The point escapes
The maximum iteration count is reached

The number of iterations determines the pixel colour.

This simple rule produces remarkably complex structures.

Mapping Pixels to Mathematics

A computer screen works in pixels.

A fractal works in mathematical coordinates.

The first step is converting pixel positions into coordinates in the complex plane.

zx = ((px / WIDTH) * 3.0) - 1.5
zy = ((py / HEIGHT) * 3.0) - 1.5

This maps the image into a viewing region:

(-1.5, -1.5)
        ↓
( 1.5,  1.5)

Every pixel becomes a unique mathematical starting point.

The Escape Test

The heart of the algorithm is:

while (
    zx * zx + zy * zy < 4.0 and
    iteration < MAX_ITER
):

As long as the point remains inside the escape radius, iteration continues.

If the value grows beyond:

|z| > 2

the point is considered escaped.

Points that remain stable create the characteristic Julia Set structure.

Colouring the Fractal

After the iteration process finishes, a colour is assigned.

color = int(
    255 * iteration / MAX_ITER
)

The pixel colour becomes:

(
    color,
    color // 2,
    255 - color
)

This creates a smooth gradient ranging from deep blues to bright highlights.

More advanced colour maps can produce even more dramatic results.

Why StreamingWriter Matters

A traditional image-generation workflow usually follows this pattern:

Allocate image
Store every pixel in memory
Save image

For small images, this isn't a problem.

But a 10,000 × 10,000 RGB image contains 100 million pixels. As resolutions increase, memory requirements grow rapidly, especially when additional processing buffers are involved.

StreamingWriter takes a different approach:

Generate row
Write row to disk
Discard row
Generate next row

Only a single row (and a small amount of bookkeeping data) needs to exist in memory at any given moment.

Memory usage remains relatively stable because the entire image never needs to be stored in RAM simultaneously.

This means even developers using older laptops, entry-level PCs, virtual machines, or systems with around 4 GB of RAM can generate extremely large procedural images without needing workstation-class hardware.

Instead of requiring enough memory to hold a complete 100-million-pixel image, StreamingWriter continuously streams data directly to disk.

The result is a workflow that scales far beyond what many traditional in-memory approaches can comfortably handle.

Understanding the Scale

Let's put the resolution into perspective.

10000 × 10000

equals:

100,000,000 pixels

For comparison:

Resolution	Pixels
1920×1080	2.07 Million
3840×2160 (4K)	8.29 Million
7680×4320 (8K)	33.18 Million
10000×10000	100 Million

This single fractal image contains more pixels than a typical 8K render.

Beyond Julia Sets

The same streaming approach can be applied to many procedural graphics systems:

Mandelbrot Sets
Perlin Noise
Voronoi Diagrams
Terrain Maps
Heatmaps
Scientific Visualizations
AI Dataset Generation
Procedural Artwork

The rendering logic changes.

The streaming architecture remains exactly the same.

Why This Matters

Modern displays continue to increase in resolution.

At the same time, procedural content generation is becoming increasingly important in:

Games
Simulations
AI
Scientific Computing
Generative Art

Generating these assets efficiently requires more than just fast algorithms.

It requires memory-efficient workflows.

StreamingWriter provides exactly that.

Final Thoughts

Creating a Julia Set is already an interesting mathematical exercise.

Creating one at 10,000 × 10,000 resolution introduces an entirely different challenge: managing memory efficiently.

By combining fractal mathematics with pyaitk.CLSE.StreamingWriter, it's possible to generate images containing 100 million pixels while avoiding the need to keep the entire image in memory.

One of the most interesting aspects is that this kind of rendering isn't limited to high-end workstations. Thanks to row-by-row streaming, even systems with around 4 GB of RAM can participate in generating massive procedural images that would otherwise be impractical using fully in-memory workflows.

What starts as a simple equation:

z = z² + c

ultimately becomes a massive, highly detailed fractal image generated one row at a time.

And that's the power of streaming image generation.

Other

Installation

pip install pythonaibrain[clse]

For more information

github.com/DivyanshuSinha136/Pythonaibrain-1.1.9

Creating Fractals, Noise, Voronoi Patterns, and Gradients in Python with pyaitk.CLSE

Divyanshu Sinha — Wed, 17 Jun 2026 19:39:02 +0000

Procedural graphics are everywhere.

They're used in:

Game development
Scientific visualization
AI dataset generation
Generative art
Simulations
Digital design tools

Traditionally, creating fractals, noise maps, Voronoi diagrams, and advanced gradients requires multiple libraries or a significant amount of custom code.

But with pyaitk.CLSE, many of these techniques are available through simple, high-level APIs.

In this article, we'll explore how to generate fractals, procedural textures, and gradients using just a few lines of Python.

Mandelbrot Set

The Mandelbrot Set is one of the most famous fractals in mathematics.

With CLSE, generating one is straightforward:

from pyaitk.CLSE import ProceduralArt

img = ProceduralArt.mandelbrot_set(
    width=800,
    height=600
)

img.save("mandelbrot.png")

The result is a detailed fractal image generated entirely through mathematical iteration.

Applications include:

Mathematical visualization
Educational software
Fractal exploration tools
Procedural artwork

Julia Sets

Julia Sets are closely related to the Mandelbrot Set but produce dramatically different structures depending on the selected complex constant.

img = ProceduralArt.julia_set(
    800,
    600,
    c_real=-0.7,
    c_imag=0.27015
)

img.save("julia.png")

Changing the values of c_real and c_imag creates entirely new fractal worlds.

This makes Julia Sets particularly popular for:

Generative art
Animation
Mathematical experimentation
Visual effects

Sierpinski Triangle

The Sierpinski Triangle is a classic recursive fractal.

img = ProceduralArt.sierpinski_triangle(
    512,
    512,
    depth=7
)

img.save("sierpinski.png")

Despite its simple construction rules, the resulting structure demonstrates self-similarity at multiple scales.

Common uses include:

Fractal education
Recursive graphics
Computational geometry demonstrations

Plasma Generation

Procedural plasma effects create smooth, colorful organic patterns.

img = ProceduralArt.plasma(
    512,
    512
)

img.save("plasma.png")

Plasma textures are often used for:

Fantasy effects
Energy fields
Abstract backgrounds
Procedural artwork

Because the image is mathematically generated, every output can be unique.

Voronoi Diagrams

Voronoi diagrams divide space into regions based on distance from seed points.

img = ProceduralArt.voronoi(
    512,
    512,
    n_cells=25,
    seed=42
)

img.save("voronoi.png")

The generated regions resemble:

Cellular structures
Cracked surfaces
Geographic partitioning
Natural growth patterns

Voronoi diagrams are widely used in:

Terrain generation
Game maps
Biology simulations
Procedural environments

Perlin Noise

Perlin Noise is one of the most important algorithms in procedural generation.

img = ProceduralArt.perlin_noise_image(
    512,
    512,
    octaves=4
)

img.save("perlin.png")

Perlin Noise serves as the foundation for many procedural systems.

Applications include:

Terrain generation
Cloud rendering
Water simulation
Texture synthesis
AI dataset creation

The octaves parameter controls detail complexity.

Higher values produce richer structures.

Linear Gradients

Gradients are fundamental building blocks for many graphics workflows.

Creating a smooth linear gradient is simple:

from pyaitk.CLSE import VisualEffects

img = VisualEffects.create_linear_gradient(
    512,
    512,
    (70, 130, 200),
    (200, 80, 120)
)

img.save("linear_gradient.png")

This smoothly blends one colour into another across the image.

Common uses include:

UI backgrounds
Data visualization
Procedural textures
Design assets

Radial Gradients

Radial gradients create colour transitions radiating outward from a central point.

img = VisualEffects.create_radial_gradient(
    512,
    512,
    (255, 220, 50),
    (30, 30, 120)
)

img.save("radial_gradient.png")

This technique is useful for:

Lighting effects
Glow effects
Planet rendering
Artistic compositions

Combining Techniques

One of the strengths of CLSE is that these generators can be combined.

For example:

noise = ProceduralArt.perlin_noise_image(
    1024,
    1024,
    octaves=6
)

gradient = VisualEffects.create_radial_gradient(
    1024,
    1024,
    (255, 200, 50),
    (20, 20, 80)
)

These outputs can be blended, transformed, filtered, or streamed into larger rendering pipelines.

This enables developers to create highly complex procedural graphics from simple building blocks.

Why This Matters

Many procedural graphics workflows require multiple libraries, custom implementations, or hundreds of lines of code.

CLSE provides ready-to-use generators for:

Mandelbrot Fractals
Julia Sets
Sierpinski Triangles
Plasma Effects
Voronoi Diagrams
Perlin Noise
Linear Gradients
Radial Gradients

all through a consistent API.

This makes experimentation faster and lowers the barrier to creating advanced procedural imagery.

Final Thoughts

Procedural generation is one of the most powerful techniques in computer graphics.

With just a few function calls, pyaitk.CLSE can generate fractals, noise maps, cellular structures, and professional-looking gradients entirely from mathematics.

Whether you're building games, creating AI datasets, generating textures, producing educational visualizations, or simply exploring generative art, CLSE provides a practical toolkit for creating images from code.

And perhaps the most interesting part?

Every image starts from pure algorithms—no external assets required.

DEV Community: Divyanshu Sinha

🚀 Announcing Pythonaibrain-Warden (v0.1.1): Industrial-Grade, npm-Inspired Package & Environment Manager for Python

🌟 Why I Built warden

⚡ Quick Start

📋 Command Summary

🌐 Links & Resources

I Built My Own Python Package Manager. Three Bugs Taught Us More Than the Design Did.

The itch

The one rule that kept the codebase sane

I didn't use venv.EnvBuilder. On purpose.

Bug #1: "python" doesn't mean what you think it means on Windows

Different files, different dependency versions, same project

The bug that only showed up completely offline

A quieter bug: brackets are not decoration

What I'd tell you if you're building something similar

Resources

Pythonaibrain-NLP 0.2.0 Is Now on PyPI — A Structured NLU/NLG Architecture for Python

Why another NLP framework?

The architecture

NLU

NLG with SC-LSTM

Dialogue context

Retrieval

No transformer dependency

A complete NLP pipeline

What is included in 0.2.0?

Installation

Open source

What's next?

Links

Beyond Tooling Hell: A New Way to Teach Operating System Development

What’s different about this book:

Source:

DivyanshuSinha136 / Aetherix

A Python-native operating system development framework for building bootable x86 and x86_64 systems. Aetherix supports both legacy BIOS and modern UEFI firmware, generates machine code directly through its own native encoder, and provides high-level APIs alongside low-level instruction control.

Aetherix

Install

Preview

Operating System with Aetherix book

Building an Interactive Shell in Python with Aetherix

What it demonstrates

Source code

Why this example is interesting

From Python Code to a Bootable Graphics OS

Highlights

Source code

Getting Started

Resources

Building My First UEFI Application in Python with Aetherix

Resources

📦 Install

🔗 GitHub

Introducing Aetherix 0.1.0 – Build Operating Systems with Python

Current features include:

Install it with:

Quick Start:

I Built VoxMark — A Declarative Language for Interactive Documents and Web Applications

What is VoxMark?

Features

Documentation Written in VoxMark

Installation

How VoxMark Looks After Compilation

📊 Graph Widgets

📦 Embedded Content

🎨 Custom Styling

📈 Charts

🚀 Hero Sections

Why I Built It

What's Next?

Links

How I Generated a 100-Million-Pixel Julia Set on a 4 GB RAM PC Using Python

The Code

Why Julia Sets?

Mapping Pixels to Mathematics

The Escape Test

Colouring the Fractal

Why StreamingWriter Matters

Understanding the Scale

Beyond Julia Sets

Why This Matters

🌟 Why I Built `warden`

I didn't use `venv.EnvBuilder`. On purpose.