Author architectures directly
Indentation-based .aur programs describe experiments, datasets, models, forward chains, explicit graph branches, and training jobs. Source spans survive parsing into later diagnostics.
01 / THE IDEA
A closer look.
Aurane compiles compact .aur model definitions into readable PyTorch programs. Its compiler resolves constants, optionally checks semantics and types, lowers tensor graphs into a shared representation, and powers profiling and architecture diagrams from that same representation.
A model description should stay compact without hiding the generated program. Aurane treats the architecture as a graph of named tensor values, so code generation, shape checking, and visual inspection can agree about what each layer consumes and produces.
Follow every tensor value
The shared IR gives each value a distinct name, inferred shape, and dtype. Undefined inputs and invalid operations can be reported at their source location before generated code is run.
Generate ordinary PyTorch
A registered torch backend emits modules, dataset setup, training workflows, metrics, and checkpoints. The output is Python source that can be inspected and edited.
Use the graph beyond compilation
The CLI exposes checking, IR export, profiling, Mermaid/DOT visualization, watching, linting, and formatting. Parameter and FLOP estimates are derived from architecture information.
02 / UNDER THE SURFACE
Inside the compiler
The main compilation path feeds a second branch for analysis and inspection.
DRAG TO PAN · SELECT A NODE · + / − TO ZOOM
Read the architecture as text
- Aurane source — A source program combines model definitions with optional datasets and training configuration. compile_source accepts source text and explicit backend, analysis, validation, and optimization options.
- Indentation parser — Parser reads indentation-based blocks and layer operations, including explicit graph forward blocks. Parsing produces an AuraneProgram rather than executing the source as Python.
- Constant resolution — The compiler resolves program constants immediately after parsing. Later passes receive the resolved AST, keeping symbolic configuration values consistent across generated code and analysis.
- Semantic analysis — When analysis is enabled, analyze_semantics checks the resolved program. Reported errors halt compilation before code generation and are formatted as semantic issues.
- Type / shape checks — The optional TypeChecker checks datasets, model shapes, references, and training configuration. The compile path refuses a result with type errors rather than emitting an invalid program.
- AST optimization — Optimization is explicitly selected with a level. optimize_ast returns a new program used by code generation; this is distinct from optimizing the runtime numerical kernels themselves.
- Backend registry — The registry maps a normalized backend name to a generator. The default registration is torch. A dynamic backend without a declared cache version disables caching to avoid stale output.
- Named tensor IR — Lowering creates explicit input and output values for each operation. Reused source variable names receive unique generated names; inputs must already exist in the environment.
- Shape + dtype inference — Every lowered operation infers its output shape from input shapes and its output dtype from input and parameter dtypes. Invalid dimensions or types become LocatedError diagnostics.
- Source diagnostics — IR nodes preserve source positions and lowering wraps inference failures with a SourceSpan. This relates a tensor contract violation to the architecture expression that caused it.
- PyTorch generator — TorchCodeGenerator writes imports, configuration, datasets, model definitions, and training code. It consumes the architecture representation to construct layer modules and forward operations.
- Readable Python — The chosen generator returns Python source to the compiler. Running that output is a separate action with PyTorch installed; compilation itself does not train a model.
- Architecture profiler — The profiler estimates architecture cost from model operations and inferred shapes. These are analytical estimates, not measured latency or benchmark results on a particular accelerator.
- Architecture diagrams — Visualization renders the model graph with operation labels, shapes, and parameter information. The graph path shares the model representation used by other compiler consumers.
- Verified compile cache — Cache keys include compiler/backend versions, source, and compile options. Cache reads verify the stored key and output SHA-256; missing or corrupt entries become ordinary cache misses.
03 / INTERACTIVE STUDY
Compile the dimensions
Adjust a miniature image model: three input channels, one valid convolution, flatten, and a ten-output dense layer. Watch the tensor shapes and parameter counts change together.
CHANGE THE INPUTS
An illustrative shape-inference example with stride one, no padding, and biases. It explains compiler contracts; it does not invoke Aurane or train PyTorch.
ILLUSTRATIVE MODELLIVE
04 / ENGINEERING CHOICES
Why it works this way.
One graph for several tools
Named values, shapes, dtypes, and source spans live in a shared IR. This reduces the chance that profiling, diagrams, and emitted forward code describe different networks.
Readable output is part of the interface
Compilation emits Python rather than an opaque executable. The user can inspect the generated modules and training program and run them with the PyTorch runtime.
Cache identity includes behavior
The source text alone is insufficient as a cache key. Compiler version, backend version, compile options, schema, and a hash of the output all participate in cache validation.
05 / OPEN THE SOURCE
Trace it back.
Implementation details, examples, and project documentation.
Compiler orchestration
Parsing, constant resolution, optional checks, backend selection, generation, and cache verification.
Tensor graph representation
Named graph values, source spans, shape/dtype inference, and explicit graph lowering.
PyTorch code generation
Generated modules, forward bodies, datasets, training workflows, metrics, and checkpoints.
Documented language surface
CLI commands, supported layers, examples, and stated local QA boundaries.
Scope & limitations
- The registry supports extensibility, but the built-in backend inspected here is PyTorch; this page does not claim additional implemented backends.
- Compiler estimates are not hardware measurements. The repository documents offline example checks separately from network downloads, long training, and CUDA execution.
Architecture and descriptions reflect the linked repository snapshot. The playground explains a mechanism; it does not execute the repository or report measured performance.