projects/Xazz.md

What it is무엇인가

An AI pipeline DSL. One .xzz script covers preprocessing, model training, and security policy — compiled to a typed IR, then lowered to Polars (data) and Burn (deep learning).

AI 파이프라인 DSL입니다. 하나의 .xzz 스크립트로 전처리, 모델 학습, 보안 정책까지 다루고,타입드 IR로 컴파일한 뒤 Polars(데이터)와 Burn(딥러닝)으로 하강시킵니다.

Why it exists만든 이유

Python owns AI prototyping, but at pipeline scale three costs appear:

Python이 AI 프로토타이핑을 지배하지만, 파이프라인 규모에서 세 가지 비용이 발생합니다.

• Type and NaN errors crash at runtime, often mid-training → Xazz checks them at compile time, with line:col diagnostics and did-you-mean hints.
• 타입·NaN 에러가 런타임(종종 학습 도중)에 터짐 → Xazz는 컴파일 타임에 line:col 진단과 did-you-mean 힌트로 잡습니다.
• Data crosses language walls (pandas → NumPy → PyTorch) → Apache Arrow buffers are handed directly to Burn; the remaining copies are explicit in the memory model.
• 데이터가 언어 경계(pandas → NumPy → PyTorch)를 건너며 복사됨 → Apache Arrow 버퍼를 Burn에 직접 전달하고, 남는 복사 지점을 명시화했습니다.
• No security layer in the pipeline → policy-as-code guardrails, differential privacy, and a SHA-256 audit log are part of the runtime.
• 파이프라인에 보안 계층이 없음 → 폴리시 애즈 코드 가드레일, 차등 프라이버시, SHA-256 감사 로그를 런타임에 포함했습니다.

How it's built구조

All of this is written from scratch in Rust — nothing wraps an existing library:

모두 Rust로 처음부터 작성했고, 기존 라이브러리를 감싼 래퍼가 아닙니다.

• lexer → parser → static checker → typed IR → optimizer → emitter
• 렉서 → 파서 → 정적 체커 → 타입드 IR → 옵티마이저 → 이미터
• IR consumed once by the runtime (no double parse)
• 런타임이 IR을 한 번만 소비(이중 파싱 없음)
• CLI stays 2–5 MB; Polars and Burn live behind a subprocess boundary
• CLI는 2–5 MB 유지, Polars와 Burn은 서브프로세스 경계 뒤에 격리

type AirData = {
  station:  string,
  temp:     float,
  pm10:     Option<float>,
}

v dataset = load("air_data.csv") :: AirData
    |> fillNull("pm10", strategy: "mean")
    |> select(["station", "temp", "pm10"])

model AirPredictor {
  Dense(64) -> ReLU() -> Dense(1)
}

v trained = dataset
    |> train(AirPredictor, target: "pm10", epochs: 10)

It runs실행 결과

Static analysis catches a typo before execution — with a did-you-mean hint and a line:col span:

실행 전에 정적 분석이 오타를 잡습니다 — did-you-mean 힌트와 line:col 스팬과 함께:

xazz check

A model declaration compiled to real Burn layers, with epoch losses and a checkpoint:

모델 선언이 실제 Burn 레이어로 컴파일되어 에폭 손실과 체크포인트를 기록합니다:

xazz run demo/deep_learning.xzz

Zero-copy tensor handoff — Arrow buffers read directly by Burn, no pandas → NumPy → PyTorch copies:

제로카피 텐서 핸드오프 — Arrow 버퍼를 Burn이 직접 읽습니다. pandas → NumPy → PyTorch 복사가 없습니다:

memory model

projects/x1zzLang.md

Lineage계보

The original data-pipeline DSL that evolved into Xazz. It compiles .xzz scripts into optimized Polars LazyFrame execution plans. The project was primarily an exercise in language design, compiler engineering, and type system research.

Xazz로 성장한 최초의 데이터 파이프라인 DSL입니다. .xzz 스크립트를 최적화된 Polars LazyFrame 실행 계획으로 컴파일합니다. 언어 설계, 컴파일러 엔지니어링, 타입 시스템 연구가 목적이었습니다.

What it demonstrates보여주는 것

• A declarative pipeline DSL with a null-safe Option<T> type system
• 널 안전 Option<T> 타입 시스템을 가진 선언형 파이프라인 DSL
• Auto schema inference (x1zz import), EUC-KR/CP949 CSV decoding
• 자동 스키마 추론(x1zz import), EUC-KR/CP949 CSV 디코딩
• Dependency isolation — the CLI never links Polars (2–5 MB)
• 의존성 격리 — CLI는 Polars를 링크하지 않음 (2–5 MB)

projects/py2xzz.md

What it is무엇인가

A Rust CLI tool that converts Python data and deep-learning pipelines (pandas / PyTorch) into.xzz scripts. Hand-porting is repetitive; this does it automatically.

Python 데이터·딥러닝 파이프라인(pandas / PyTorch)을 .xzz 스크립트로 변환하는 Rust CLI 도구입니다. 수동 이식은 반복적이라 자동화했습니다.

How it works동작 방식

Python source ─▶ parser ─▶ xazz-core AST ─▶ emitter ─▶ .xzz

• A self-contained Python 3 lexer/parser, mirroring the ast module spec
• Python 3 ast 모듈 스펙을 미러링한 자체 렉서/파서
• pandas chains → pipeline ops; nn.Module → model declarations
• pandas 체인 → 파이프라인 연산, nn.Module → 모델 선언
• A span map keeps original Python line/column positions for diagnostics
• 스팬 맵이 원본 Python 위치를 보존해 진단에 사용

projects/llm-pcag-research.md

The question질문

Quantizing weights (FP16 → INT8 → INT4) is the standard answer to LLM inference cost. How much energy does it actually save — and does the saving hold up as precision drops?

가중치 양자화(FP16 → INT8 → INT4)는 LLM 추론 비용에 대한 표준 해법입니다. 실제로 에너지를 얼마나 아끼고, 정밀도가 낮아질수록 절감 효과는 유지될까요?

What the metric shows지표가 보여주는 것

• PCAG collapses monotonically: INT8 20.8 → INT4 10.4 → INT3 4.8
• PCAG는 단조 감소: INT8 20.8 → INT4 10.4 → INT3 4.8
• A power wall at INT4→INT3 (slope 5.68/bit, −54.4% cliff), verified by three independent paths
• INT4→INT3에 파워 월(기울기 5.68/bit, −54.4% 급락), 세 경로로 검증
• The inflection root is structurally independent of amplitude
• 변곡점은 진폭과 구조적으로 독립

Current status현재 상태

The analysis is literature-anchored reference data (Source=Reference-Literature), since this was done without GPU access. The GPU measurement harness is written and in progress.

GPU가 없는 환경이라 분석은 문헌 기반 참조값(Source=Reference-Literature)입니다. GPU 측정 하네스는 작성되어 진행 중입니다.

engineering-logs/security-guardrail.md

Problem문제

A data pipeline DSL had no security story: PII and secrets could flow from CSV to output, and nothing stopped a pipeline from reading /etc/passwd. The type checker answers "does this code run?" — but nobody asked "is it safe to run this code?"

데이터 파이프라인 DSL에는 보안이 없었습니다. PII와 시크릿이 CSV에서 출력까지 그대로 흐를 수 있었고,/etc/passwd를 읽는 것도 막을 수 없었어요. 타입 체커는 "이 코드가 돌아가나?"를 답하지만, "이 코드를 돌려도 안전한가?"를 묻는 사람은 없었습니다.

Approach접근

A policy-as-code layer in xazz-compiler scans before execution and is fail-closed: if the policy can't be loaded, execution is refused. Scanners are hand-rolled — normalized exact match, not substring matching.

xazz-compiler에 폴리시 애즈 코드 계층을 두고 실행 전에 스캔하며, fail-closed입니다. 정책을 못 불러오면 실행을 거부합니다. 스캐너는 직접 구현했고, 부분 문자열이 아닌 정규화 후 정확 일치를 씁니다.

• RRN: form + checksum validated — a checksum mismatch is not flagged
• 주민번호: 형식 + 체크섬 검증 — 체크섬이 틀리면 탐지하지 않음
• Cards: 13–19 digits + Luhn + issuer prefix; timestamps and order numbers excluded
• 카드: 13–19자리 + Luhn + 발급사 접두사; 타임스탬프·주문번호는 제외
• Three gate points — the final one sits inside xazz-exec, the only place Polars runs
• 3중 게이트 — 마지막 게이트는 Polars가 실행되는 유일한 곳인 xazz-exec 내부

engineering-logs/typed-ir.md

Problem문제

The first version interpreted the raw AST twice — the CLI re-parsed source, then the runtime re-parsed the AST against Polars/Burn. Two passes, two chances to diverge.

초기 버전은 원시 AST를 두 번 해석했습니다. CLI가 소스를 다시 파싱하고, 런타임이 AST를 Polars/Burn에 다시 매핑했어요. 두 번 해석하니 두 번 어긋날 수 있었습니다.

Fix해결

A single typed IR: .xzz compiles to it once, the runtime consumes it once. An optimizer on the IR is meaning-preserving and backend-independent.

단일 타입드 IR로 정리했습니다. .xzz는 IR로 한 번 컴파일되고, 런타임은 IR을 한 번만 소비합니다. IR 위의 옵티마이저는 의미를 보존하며 백엔드와 무관합니다.

// xazz-compiler/src/opt.rs
// 1. fold_constants   8 / 2 -> 4.0 (div-by-zero preserved)
// 2. merge_selects    select([a,b]) |> select([a]) -> select([a])
// 3. pushdown_filters filter before select/withColumn when safe

engineering-logs/dependency-isolation.md

Problem문제

The CLI linked Polars directly, so a --help command shipped ~35 MB of binary the CLI never used.

CLI가 Polars를 직접 링크해서, --help 한 번에 쓸 일 없는 ~35 MB 바이너리가 배포됐습니다.

Fix해결

A Cargo workspace with hard rules: the CLI never links Polars/Tokio; execution runs in a spawned subprocess. Communication is CLI arguments only — no IPC protocol.

카고 워크스페이스에 명확한 규칙을 세웠습니다. CLI는 Polars/Tokio를 절대 링크하지 않고, 실행은 스폰된 서브프로세스에서 합니다. 통신은 CLI 인자뿐이고 IPC 프로토콜이 없습니다.

xazz (CLI binary)                ~2-5 MB
  clap · csv · anyhow · encoding_rs
  NO Polars · NO Tokio

  xazz-core          AST · Token · Error · Typed IR (serde only)
  xazz-compiler      Lexer -> Parser -> Checker -> Typed IR
                     -> Opt -> Emitter + guardrail
  xazz-exec          Polars + Burn runtime (heavy deps isolated)
  xazz-runner        subprocess bridge (std only, timeout)

• CLI: ~2–5 MB (was ~35 MB)
• CLI: ~2–5 MB (이전 ~35 MB)
• The runner enforces an execution timeout and resolves the engine without PATH fallback (fail-closed)
• 러너가 실행 타임아웃을 적용하고, PATH 폴백 없이 엔진을 찾음(fail-closed)

benchmarks.md

Xazz vs pandasXazz vs pandas

Same 4-stage pipeline (drop nulls → dual filter → group-by aggregates → fill + count) on Seoul air-quality data, median of 3 runs after warmup, wall-clock timing.

동일한 4단계 파이프라인(널 제거 → 이중 필터 → 그룹별 집계 → 채우기·카운트)을 서울 대기질 데이터로, 워밍업 후 3회 중앙값, 벽시계 시간으로 측정했습니다.

The gap narrows as data grows, and the small-scale number includes a pandas interpreter-boot penalty — 1.93× at 4.09M rows is the robust figure. Polars' multithreading also trades higher peak RSS for latency.

데이터가 커질수록 격차는 줄어들고, 소규모 수치에는 pandas 인터프리터 부팅 비용이 포함되어 있어 409만 행의 1.93×가 더 견고한 수치입니다. Polars 멀티스레딩은 지연 시간 대신 최대 RSS를 높이는 트레이드오프도 있습니다.

Chart차트

benches/render_benchmark_chart.py

x1zzLang vs pandasx1zzLang vs pandas

Up to 3.84× on a 3.4M-row Seoul air-quality dataset, from Polars LazyFrame query optimization before execution.

340만 행 서울 대기질 데이터셋에서 최대 3.84배. Polars LazyFrame의 실행 전 쿼리 최적화 덕분입니다.

benches/x1zzLang_benchmark2.png

opensource-burn.md

What무엇

Added matmul batch-broadcast validation to TensorCheck — the public tensor-API check layer that runs before backend dispatch — so every backend reports a consistentTensor Operation Error instead of an inconsistent backend-specific panic. Merged as PR #5555.

백엔드 디스패치 이전에 실행되는 공개 텐서 API 검증 레이어인 TensorCheck에 matmul 배치 브로드캐스트 검증을 추가해, 모든 백엔드가 일관된 Tensor Operation Error를 받도록 했습니다 (기존에는 백엔드마다 제각각 다른 panic이 발생).PR #5555로 머지됐습니다.

How과정

• Regression test that fails if the check is removed; narrowed after review to exercise exactly this path (not a pre-existing inner-dimension check).
• 검증을 제거하면 실패하는 회귀 테스트를 작성하고, 리뷰 후 이 경로만 정확히 검증하도록 범위를 조정했습니다 (기존 inner-dimension 검증이 아닌).
• First PR was rejected as backend-local (ndarray is deprecated) with a hot-path allocation; reworked onto the shared layer per maintainer direction.
• 첫 PR은 백엔드 로컬(ndarray는 deprecated) + 핫패스 힙 할당으로 거절 → 메인테이너가 제시한 방향대로 공통 레이어로 재작업했습니다.
• Merged directly by the maintainer.
• 메인테이너가 직접 머지했습니다.