sergio
550c98f275
Reorganización física de crates/: - core/ (mezclaba 6 propósitos) se divide en protocol/, init/, runtime/, compat/ - shared/ (3 crates) se redistribuye en protocol/ e init/ - lapaloma (sub-módulo de ui_engine) se promueve a modules/pineal/ Renames de proyectos: - shipote → shuma (runtime de sandboxes) - nouser → akasha (explorador de Mónadas) - yahweh → nahual (motor GPUI, antes ui_engine/) - lapaloma → pineal (data-viz agnóstica) Fraccionamiento UI → core agnóstico: - vista-core (DeckState + snap, 175 LOC, 5 tests verdes) - barra-core (Task + render_html + sanitize, 90 LOC, 5 tests verdes) - vista-web y barra-web ahora son thin DOM bindings Documentación nueva: - 16 SDDs por subdirectorio (≤80 LOC c/u): protocol/init/runtime/compat + 10 módulos + apps/ - docs/STATUS.md con cifras reales por proyecto - docs/ROADMAP.md con plan a finalización (6 hitos, ~6-8 semanas) - CHANGELOG.md particionado en docs/changelog/<proyecto>.md (7 buckets) Automatización: - scripts/reorg.py — script idempotente que: git mv directorios, renombra package names, recomputa path = refs, reescribe imports rust, actualiza workspace Cargo.toml. Soporta --dry-run. - scripts/split-changelog.py — particiona CHANGELOG por componente. Validación: - cargo check --workspace pasa (124 crates + 2 nuevos cores). - 10 tests adicionales (5 en vista-core + 5 en barra-core) verdes. Co-Authored-By: Claude Opus 4.7 <noreply@anthropic.com>
56 lines
2.1 KiB
Rust
56 lines
2.1 KiB
Rust
//! `pineal-core` — primitivas agnósticas de Lapaloma.
|
|
//!
|
|
//! Cero `gpui`, cero `wgpu`, cero I/O. Todo lo que vive acá puede
|
|
//! correr en un test unitario, en un worker thread o en un export
|
|
//! a SVG. Las tres reglas del documento de arquitectura aplican:
|
|
//!
|
|
//! - **P1 Zero boxing.** Los datos viven en `Vec<f32>` planos
|
|
//! indexados, nunca como `Vec<Point2D>`. Cache L1 caliente y el
|
|
//! compilador puede SIMD-loopearlo.
|
|
//! - **P2 Zero alloc en hot path.** Buffers se reservan al construir,
|
|
//! se mutan in-place para siempre. Helpers escriben a `&mut Vec`
|
|
//! provistos por el caller, no devuelven `Vec` nuevos.
|
|
//! - **P3 Una draw call por capa.** Acá no se dibuja; pero los
|
|
//! tipos exponen slices contiguos listos para mandar al GPU
|
|
//! sin copia.
|
|
//!
|
|
//! Convención de coordenadas: el buffer canónico es interleaved
|
|
//! `[x0, y0, x1, y1, ...]`. Esto es el formato que `drawRawPoints`,
|
|
//! `Vertices.raw`, `wgpu` vertex buffers y `<polyline points>` SVG
|
|
//! consumen sin transformación.
|
|
|
|
#![forbid(unsafe_code)]
|
|
|
|
pub mod buffer;
|
|
pub mod ring;
|
|
pub mod spatial;
|
|
pub mod lttb;
|
|
pub mod scale;
|
|
|
|
// Algoritmos de layout — quedan como placeholders hasta que cada
|
|
// módulo de visualización (mesh, treemap, flow) los demande.
|
|
|
|
/// Barnes-Hut quadtree para layouts force-directed.
|
|
///
|
|
/// Cuando se implemente: el quadtree es un `Vec<f32>` plano de
|
|
/// stride 7 (cm_x, cm_y, mass, half_size, center_x, center_y,
|
|
/// child_base), no un árbol de objetos. Rebuild O(n) por frame
|
|
/// sin allocations.
|
|
pub mod barnes_hut {}
|
|
|
|
/// Sugiyama-lite jerárquico: cycle-removal por DFS + Kahn layering
|
|
/// + barycenter ordering con inversion-count crossings.
|
|
pub mod sugiyama {}
|
|
|
|
/// Squarified treemap (Bruls / d3-hierarchy). Worst-aspect formula
|
|
/// usa el lado *corto* del rectángulo restante.
|
|
pub mod squarify {}
|
|
|
|
/// Subtree-width tree layout: BFS spanning + bottom-up width
|
|
/// measurement + top-down placement. Simpler que Reingold-Tilford.
|
|
pub mod tree_layout {}
|
|
|
|
/// Force-Directed Edge Bundling (FDEB-lite, single quadratic-bezier
|
|
/// control point por edge).
|
|
pub mod fdeb {}
|