b1eb68a475
3 Commits
| Author | SHA1 | Message | Date | |
|---|---|---|---|---|
| b1eb68a475 |
Vendor a patched Perspective build with column-axis expand/collapse
Perspective's column axis cannot be collapsed. The row axis has had it forever — GROUP BY ROLLUP holds every level and view.set_depth() hides the deeper ones — but nothing equivalent is exposed for split_by, so a Year over Month pivot can only ever be shown fully expanded. The engine already implements it. t_ctx2 is symmetric: set_depth(t_header, depth), open(t_header, idx) and close(t_header, idx) each have a real HEADER_COLUMN branch on m_ctraversal mirroring m_rtraversal, and t_view_config carries m_column_pivot_depth which server.cpp already applies. None of it is reachable: set_column_pivot_depth() is never called, so the depth stays -1, and View<t_ctx2>::expand/collapse hardcode HEADER_ROW. The patch is 193 lines of wiring across the protobuf, the Rust client and the datagrid — no new engine logic. Two capabilities result, mirroring the row axis: - split_by_depth in ViewConfig, the split_by counterpart to group_by_depth - expand_column()/collapse_column(), addressed by column traversal index exactly as the row methods are addressed by row index which together give the Excel behaviour — one year folded to its subtotal while its siblings stay expanded — that no combination of existing config could produce. Verified in this app against fc_cash_9: clicking a Year header goes from 27 columns to 15, totals reconciling at every level. Vendored rather than aliased - The previous approach pointed vite at a local checkout, which built only on one laptop and left package.json claiming npm 5.2.0 while the build used something else. The four packages are now committed as npm tarballs and package.json names them, so the declaration is true and `pf.sh deploy` works unchanged — npm install expands them like any registry package. - Packed with `pnpm pack`, not `npm pack`: Perspective is a pnpm workspace and cross-package deps are `workspace:^`, which npm rejects outright. pnpm rewrites those to real version ranges at pack time. - All four move together. Perspective couples loader, package versions, data format and apache-arrow; a partial vendor reintroduces exactly that drift. Cost, stated plainly: 12MB of opaque binaries in git that do not delta, a fork to maintain, and a second engine build for anyone changing it. rebuild-perspective.sh makes that repeatable and PROVENANCE.txt records the commit each tarball came from, because a committed .tgz otherwise has no recoverable source. README.md says how to delete all of it once upstream ships the feature. This also moves the app from 5.2.0 to 5.4.0. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01LoxNi8cFsQLPUSw3obb5NH |
|||
| 99375bb534 |
Load Perspective from bundle, not CDN; pin all packages at 5.2.0
The pivot stopped rendering with: LinkError: WebAssembly.instantiate(): Import #8 "env" "psp_opfs_load": function import requires a callable Nobody changed anything. The 4.x CDN bundle resolves its server WASM with new URL("../../../server/dist/wasm/perspective-server.wasm", import.meta.url) which from .../client@4.4.0/dist/cdn/ resolves to .../npm/@perspective-dev/server/dist/wasm/perspective-server.wasm -- with no version. jsdelivr serves @latest, so when @perspective-dev/server@5.2.0 was published on 2026-08-10 every page load began linking a 5.2.0 WASM against a 4.4.0 client. 4.4.1 and 4.5.2 carry the identical unversioned pattern, so no 4.x pin is safe over CDN. Beyond the outage, an unversioned URL means users execute whatever that package publishes next, unreviewed. Switch to the /inline entrypoints, which embed the WASM in the Vite build: no runtime fetch, and the version is fixed by package-lock.json (verified: zero `new URL(...perspective-server...)` in perspective.inline.js). - pin client/viewer/viewer-datagrid/server exact at 5.2.0. The explicit `server` pin matters: client declares it as "" (an empty range), which npm also resolves to latest -- the same break, at install time instead. - drop the viewer-d3fc import. pf_app never selects a chart plugin, and d3fc has no 5.x; loading 4.4.1 against a 5.x viewer only emits `get_static_config is not a function` per plugin. - themes move from a CDN <link> to @perspective-dev/viewer/themes. Verified end-to-end with every non-localhost request aborted: no external requests are attempted, both custom elements register, the Arrow stream ingests, and the pivot renders (TOTAL 17,235.97 = -7,573.97 + 30,907.47 - 6,097.53). apache-arrow 21.1.0 ingests cleanly against the 5.2.0 WASM. Bundle grows 263 KB -> 11.6 MB (5.4 MB gzipped); that is the embedded WASM. PERSPECTIVE.md also records findings from the same investigation: - §3a: expression columns are row-level, evaluated before aggregation, so a ratio like "revenue"/"qty" summed per row is wrong under any pivot (not just split_by). Fix is a weighted-mean aggregate, whose weight column must be a NESTED array: ['weighted mean', ['qty']]. Works in 4.4.0 and survives incremental table.update(). - §2: withdraws the recommendation of the 4.5.1-core + 4.4.1-d3fc pair. It does not deliver charts, so the trilemma is really a dilemma: inline bundling XOR charts. dataflow is on that pair and needs the same migration. - §5: cleanLayout() does not sanitize `aggregates`; guard it before adopting the weighted-mean pattern or a dropped column aborts the whole restore. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01SBt3EtKaP9D2mmWJ6Q4bov |
|||
| dc090fe394 |
Scaffold React/Vite/Tailwind UI with 3-step Setup → Baseline → Forecast flow
- ui/: React + Vite + Tailwind app (Setup, Baseline, Forecast views, collapsible sidebar, status bar, canvas timeline) - server.js: serve built UI from public/app/ - package.json: add build script (cd ui && npm run build) - routes/sources.js: default new col_meta role to 'dimension' instead of 'ignore' - .gitignore: exclude public/app/ build output - pf_spec.md: update tech stack, nav, frontend section, and project status to reflect current implementation Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com> |
