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.
• 파이프라인에는 보안 계층이 없었습니다. 정책 기반(policy-as-code) 가드레일과 차등 프라이버시, 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/Xz.md

What it is무엇인가

An experimental general-purpose programming language built around one thesis: AI-written, Human-reviewed. Code will increasingly be written by machines, so Xz is designed for humans to read, verify, and trust it — explicit types at contract boundaries, value semantics with explicit mut, Result types on a single error channel, and structured JSON diagnostics a model can act on.

AI가 쓰고 사람이 검증한다. 이 명제 하나를 중심으로 설계한 실험적 범용 언어입니다. 앞으로 코드는 점점 기계가 작성할 텐데, 사람은 그 코드를 읽고 검증하고 신뢰할 수 있어야 한다고 생각했습니다. 그래서 계약 경계에는 타입이 명시되고, 값 시맨틱에는 mut이 명시되고, 에러 채널은 Result 하나로 단일화했습니다. 모델이 읽을 수 있는 구조적 JSON 진단도 갖춰져 있습니다.

The differentiator — intent verification핵심 차별점 · 인텐트 검증

Static typing catches type mismatches, but nothing catches a comment that lies about behavior. Xz makes the contract between comment and code verifiable: every documented claim is proven by the compiler, trusted by a human via @trusted, or rejected in --strict builds.

정적 타이핑은 타입 불일치는 잡아주지만, 동작에 대해 거짓말하는 주석은 아무도 잡지 못합니다. Xz는 주석과 코드 사이의 계약을 검증할 수 있는 형태로 만들었습니다. 문서화된 주장은 컴파일러가 증명하거나, 사람이 @trusted로 신뢰하거나, --strict 빌드에서 거부됩니다.

• @intent / @requires / @ensures NL claims are structurally paired (in order) with formal pre / post contracts; the NL text is never parsed.
• @intent / @requires / @ensures 자연어 주장은 형식 pre / post 계약과 순서대로 구조적 짝을 이룹니다. 자연어는 파싱되지 않습니다.
• @effects is derived from the body, transitively over calls, and compared against the declaration.
• @effects는 본문에서 호출을 따라 전이적으로 도출되어 선언과 대조됩니다.
• Stable intent diagnostics (I0020–I0024) travel as JSON with spans and confidence-scored fixes.
• 안정적인 인텐트 진단(I0020–I0024)이 스팬과 신뢰도 점수 기반 수정안과 함께 JSON으로 전달됩니다.

record Point {
    x: Float
    y: Float
}

/// Computes the Euclidean distance between two points.
/// @intent  Returns the straight-line distance from a to b.
/// @ensures result is ok implies result.value >= 0.0
/// @effects none
func distance(a: Point, b: Point) -> Result[Float, DomainError]
    post result is ok implies result.value >= 0.0
{
    let dx = b.x - a.x
    let dy = b.y - a.y
    ok(sqrt(dx * dx + dy * dy)?)
}

How it's built구조

• Full front end from scratch: lexer → indentation parser → name resolution → type inference → contract checking → intent verification
• 처음부터 구현한 전체 프런트엔드: lexer → 들여쓰기 파서 → 이름 해석 → 타입 추론 → 계약 검사 → 인텐트 검증
• LLVM backend via inkwell (portable LLVM 17): JIT (xz run), native binary (xz build-native), shared library (xz build --shared)
• inkwell 기반 LLVM 백엔드(이식형 LLVM 17): JIT(xz run), 네이티브 바이너리(xz build-native), 공유 라이브러리(xz build --shared)
• FFI-first interop: C ABI bridge, @cstruct records, Ptr handles, and generated Python ctypes wrappers (xz bind --lang python)
• FFI 우선 상호운용: C ABI 브리지, @cstruct 레코드, Ptr 핸들, 생성된 Python ctypes 래퍼(xz bind --lang python)

Status현재 상태

Phases 1–4 implemented, Phase 5 (FFI & interop) underway. hello.xz and contracts.xzpass the full front end and execute via the LLVM JIT; Phases 6–8 (concurrency runtime, stdlib, tooling) are on the roadmap. Xz is an experimental technical project, separate from the commercial Xazz line.

Phase 1–4는 구현을 마쳤고, Phase 5(FFI와 상호운용)를 진행 중입니다. hello.xz와contracts.xz가 전체 프런트엔드를 통과해 LLVM JIT로 실행됩니다. Phase 6–8(동시성 런타임, 표준 라이브러리, 툴링)은 로드맵에 있습니다. Xz는 상업용 Xazz 라인과 별개인 실험적 기술 프로젝트입니다.

projects/next.xz.md

What it is무엇인가

A hybrid web framework and orchestration toolkit that bridges Next.js (TypeScript) with theXz language. Next.js owns the UI and routing shell; Xz owns the backend business logic that must be explicit, verifiable, and safely AI-generatable.

Next.js(TypeScript)와 Xz 언어를 잇는 하이브리드 웹 프레임워크이자 오케스트레이션 툴킷입니다. Next.js가 UI와 라우팅 셸을 맡고, 명시적이고 검증 가능해야 하며 AI가 안전하게 생성할 수 있는 백엔드 비즈니스 로직은 Xz가 맡습니다.

How it works동작 방식

Next.js App Router (TS/JS)
        │  Server Actions / generated bindings
        ▼
next.xz  ── bridge · agent · audit
        │  C ABI / Bun FFI
        ▼
Xz Core (.xz)  ── LLVM 17 native / shared library

• @xz-lang/bridge — generates typed TypeScript bindings from @export signatures and loads the compiled shared library over Bun FFI / koffi.
• @xz-lang/bridge: @export 시그니처로 타입이 붙은 TypeScript 바인딩을 생성하고, Bun FFI / koffi로 컴파일된 공유 라이브러리를 로드합니다.
• @xz-lang/agent — drives the LLM → xz check-json → repair loop with a bounded retry budget; never silently accepts a failing module.
• @xz-lang/agent: LLM → xz check-json → 수정 루프를 제한된 재시도 예산으로 돌립니다. 실패한 모듈을 조용히 받아들이지 않습니다.
• @xz-lang/audit — a /___audit overlay that renders contract and effect badges for human approval.
• @xz-lang/audit: 사람의 승인을 위한 계약·이펙트 배지를 렌더링하는 /___audit 오버레이.

Status현재 상태

v0.1.0-draft — the PRD, architecture, and subsystem specs are in place; the bridge, agent loop, and audit UI are the work in progress.

v0.1.0-draft. PRD와 아키텍처, 서브시스템 스펙은 준비됐고, 브리지와 에이전트 루프, 감사 UI를 작업하고 있습니다.

projects/rails.xz.md

What it is무엇인가

A hybrid Rails toolkit that bridges Ruby on Rails with the Xz language. It is a set of gems plus a mountable Engine — a toolkit on top of Rails, not a fork of it.

Ruby on Rails와 Xz 언어를 잇는 하이브리드 Rails 툴킷입니다. gem 모음과 마운트 가능한 Engine으로 이루어져 있고, Rails를 포크하는 게 아니라 위에 얹는 방식입니다.

How it works동작 방식

Rails web layer (Controllers · ActiveRecord · Hotwire)
        │  Ruby Native FFI (Fiddle / ffi)
        ▼
rails.xz  ── bridge · agent · audit engine
        │  C ABI shared library (.so)
        ▼
Xz core (.xz)  ── LLVM native / shared library

• rails-xz-bridge — generates Ruby bindings from @export signatures and loads Xz shared libraries through Fiddle/ffi.
• rails-xz-bridge: @export 시그니처로 Ruby 바인딩을 생성하고 Fiddle/ffi로 Xz 공유 라이브러리를 로드합니다.
• rails-xz-agent — runs the LLM → xz check-json → repair loop inside an ActiveJob with a bounded retry budget.
• rails-xz-agent: LLM → xz check-json → 수정 루프를 ActiveJob 안에서 제한된 재시도 예산으로 실행합니다.
• rails-xz — a Rails Engine providing the Xz::Module service DSL and the /xz_audit approval dashboard.
• rails-xz: Xz::Module 서비스 DSL과 /xz_audit 승인 대시보드를 제공하는 Rails Engine.
• Split: I own the bridge, binding generation, and compiler integration; imrubydev owns the Engine and developer experience.
• 역할 분담: 브리지, 바인딩 생성, 컴파일러 통합은 제가, Engine과 개발자 경험은 imrubydev가 맡습니다.

Status현재 상태

v0.1.0-draft — the PRD, architecture, subsystem specs, and gem skeletons are in place; the Ruby bridge, agent loop, and Engine are in progress.

v0.1.0-draft. PRD와 아키텍처, 서브시스템 스펙, gem 스켈레톤은 준비됐고, Ruby 브리지와 에이전트 루프, Engine을 작업하고 있습니다.

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에 정책 기반(policy-as-code) 계층을 두고 실행 전에 스캔합니다.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
• 게이트는 세 곳입니다. 마지막 게이트는 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

Featured — Min / Max scatter / select_assign대표 기여 · Min / Max scatter / select_assign

The largest-scope contribution. Element-wise scatter / select_assignsupported only Assign, Add, and Mul; Min /Max hit unimplemented! on every backend — even though scatter_ndalready implemented all five variants. Implemented the missing variants end-to-end across all four backends, plus autodiff backward passes. Merged asPR #5582.

범위가 가장 컸던 기여입니다. 요소별 scatter / select_assign은Assign, Add, Mul만 지원했고 Min / Max는 모든 백엔드에서 unimplemented!에 걸렸습니다. scatter_nd는 다섯 변형을 전부 구현해 두고서요. 빠진 변형을 네 백엔드 전부와 autodiff backward까지 end-to-end로 구현했습니다.PR #5582로 머지됐습니다.

How과정

• All four backends: ndarray primitives; flex helpers sharing the existing update walkers; cubecl entries reusing the BinaryMinOp / BinaryMaxOp kernels; tch via scatter_reduce / index_reduce_ ("amin" / "amax").
• 네 백엔드 전부: ndarray 프리미티브; 기존 업데이트 워커를 공유하는 flex 헬퍼; BinaryMinOp / BinaryMaxOp 커널을 재사용하는 cubecl; scatter_reduce / index_reduce_("amin" / "amax")를 쓰는 tch.
• Autodiff: backward passes for Min / Max scatter and select_assign, mirroring the scatter_nd Min/Max gradient — winner masks from comparisons, ties credited to both operands, unique indices required.
• Autodiff: Min / Max scatter와 select_assign의 backward 패스를 scatter_nd Min/Max 그래디언트와 같은 방식으로 구현했습니다. 비교로 winner 마스크를 만들고, 동률은 양쪽 입력에 귀속시키고, unique index를 요구합니다.
• Dispatch matches now enumerate every IndexingUpdateOp variant, so an unsupported combination fails at compile time instead of panicking at runtime.
• dispatch match가 모든 IndexingUpdateOp 변형을 열거하므로, 지원되지 않는 조합은 런타임 panic 대신 컴파일 타임에 실패합니다.
• Verified with 1839 tensor + 572 autodiff tests (--features ndarray) and clippy-clean on burn-ndarray, burn-flex, burn-autodiff, burn-cubecl; confirmed the new autodiff tests fail with the old unimplemented! when the backward is removed.
• --features ndarray로 텐서 1839개 + autodiff 572개 테스트를 통과했고, burn-ndarray·burn-flex·burn-autodiff·burn-cubecl은 clippy 클린입니다. backward를 제거하면 새 autodiff 테스트가 기존 unimplemented!로 실패하는 것도 확인했습니다.

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.
• 메인테이너가 직접 머지했습니다.

Also — element-wise binary ops추가 · 요소별 이항 연산

Applied the binary_ops_ew TensorCheck (device + broadcast) to five element-wise ops —remainder, powi, powf, hypot, atan2 — which previously bypassed validation and panicked per-backend. Merged as PR #5564.

요소별 이항 연산 5개(remainder, powi, powf, hypot,atan2)에 binary_ops_ew 텐서 검증(device와 브로드캐스트)을 적용했습니다. 기존에는 검증을 건너뛰고 백엔드마다 다른 panic이 났습니다.PR #5564로 머지됐습니다.

• Each op has a regression test asserting the Tensor Operation Error, verified to fail if the check is removed; valid broadcasts still pass.
• 연산마다 Tensor Operation Error를 검증하는 회귀 테스트를 추가했고, 검증 제거 시 실패함을 확인했습니다. 유효한 브로드캐스트는 여전히 통과합니다.
• Merged directly by the maintainer.
• 메인테이너가 직접 머지했습니다.

Also — matmul rank validation추가 · matmul rank 검증

Rank-1 matmul calls previously bypassed TensorCheck (a D < 2short-circuit) and failed inconsistently per backend: ndarray panicked withattempt to subtract with overflow (shape_lhs[ndims - 2] underflows atndims == 1), tch treated 1D×1D as a dot product and returned a 0-dim scalar inconsistent with the Tensor<1> output rank, and cubecl had no valid kernel input. Merged as PR #5580.

rank-1 matmul 호출이 기존에는 TensorCheck를 우회했고(D < 2short-circuit) 백엔드마다 제각각 실패했습니다. ndarray는 attempt to subtract with overflow(ndims == 1에서 shape_lhs[ndims - 2] 언더플로)로 panic을 냈고, tch는 1D×1D를 dot product로 처리해 Tensor<1> 출력 rank와 모순되는 0차원 스칼라를 돌려줬고, cubecl은 유효한 커널 입력이 없었습니다.PR #5580로 머지됐습니다.

• TensorCheck::matmul now registers a clear error for ranks < 2, mirroring the tri() check.
• TensorCheck::matmul이 tri() 검증처럼 rank < 2에 대해 명확한 에러를 등록합니다.
• Regression test float_should_panic_when_rank_is_less_than_2 in burn-backend-tests/tests/tensor/float/ops/matmul.rs — verified to fail with the backend overflow panic (not the expected message) when the check is removed.
• burn-backend-tests/tests/tensor/float/ops/matmul.rs에 회귀 테스트 float_should_panic_when_rank_is_less_than_2를 추가했습니다. 검증을 제거하면 기대 메시지가 아니라 백엔드 overflow panic으로 실패하는 것도 확인했습니다.
• Merged directly by the maintainer.
• 메인테이너가 직접 머지했습니다.

Also — no-std vec! macro fix추가 · no-std vec! 매크로 수정

The no-std test job failed to compile burn-std: layout.rs (added in #5625) imports use alloc::vec::Vec; but never the vec! macro, and its#[cfg(test)] module uses vec![...] — which only compiles with the std prelude available. Added use alloc::vec;. Merged asPR #5639.

no-std 테스트 잡이 burn-std 컴파일에 실패했습니다. layout.rs(#5625에서 추가)는use alloc::vec::Vec;만 임포트하고 vec! 매크로는 임포트하지 않았는데, 그#[cfg(test)] 모듈은 std 프렐류드가 있어야만 컴파일되는 vec![...]를 사용합니다.use alloc::vec;를 추가했습니다.PR #5639로 머지됐습니다.

• Reproduced locally: cargo test --no-default-features --release -p burn-std produced 4 cannot find macro vec errors; after the fix, 168 unit tests pass.
• 로컬에서 재현해 보면 cargo test --no-default-features --release -p burn-std가 cannot find macro vec 오류 4건을 냈고, 수정 후에는 168개 유닛 테스트가 통과합니다.
• Merged directly by the maintainer.
• 메인테이너가 직접 머지했습니다.

opensource-arrow.md

What무엇

Replaced the BufferBuilder used to re-encode sliced IPC run-ends withVec in into_zero_offset_run_array (arrow-ipc writer). This was the one callsite still using the builder on current main — the other candidates in#10245's list had already been converted, so I located the real remaining path rather than re-doing a converted one. Merged as PR #11005.

IPC run-ends 재인코딩(into_zero_offset_run_array, arrow-ipc writer)에 쓰던BufferBuilder를 Vec으로 교체했습니다. 유지보수자들이 "Rust의 최적화된 Vec이 빌더 추상화보다 낫다"고 관찰한#10245 전환 작업에서 main에 실제로 남아 있던 마지막 callsite였습니다. 목록의 다른 후보들은 이미 변환돼 있었기 때문에, 변환된 곳을 다시 고치는 대신 진짜 남은 경로를 찾아 작업했습니다.PR #11005로 머지됐습니다.

How과정

• No behavior change: the re-encoded run-ends buffer is byte-identical.
• 동작 변화는 없습니다. 재인코딩된 run-ends 버퍼는 바이트 단위로 동일합니다.
• Verified with the full arrow-ipc suite — the run-array roundtrip tests exercise the re-encoding path for every slice length and both slice offsets.
• arrow-ipc 전체 테스트로 검증했습니다. run-array 라운드트립 테스트가 모든 슬라이스 길이와 양쪽 slice offset에 대해 재인코딩 경로를 검사합니다.
• Approved by two maintainers and merged.
• 메인테이너 2명의 승인 후 머지됐습니다.

Also — interval parsing follow-up추가 · interval 파싱 후속

A follow-up (PR #11006, under review) relaxes interval parsing so bare units like "5 day hour" parse as"5 day 0 hour", matching PostgreSQL.

후속 PR(PR #11006, 리뷰 중)은 interval 파싱을 완화해 "5 day hour" 같은 bare unit을 PostgreSQL처럼"5 day 0 hour"로 해석합니다.