| Commit message (Collapse) | Author | Age |
|---|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The tarball shipped bun's default x64 build, which requires AVX2 -- so sl0ppi
installed cleanly on a plain KVM guest and then died with "Illegal instruction"
the first time anything ran pi. Known since 0.1.7 and carried as an open item;
not something to ship a third time.
packaging/fetch-vendor.sh now fetches bun-linux-x64-baseline.zip. Verified
without needing such a machine, on an emulated CPU that has none:
qemu-x86_64 -cpu Nehalem <baseline>/bun --version -> 1.3.14
qemu-x86_64 -cpu Nehalem <default>/bun --version -> Illegal instruction
Also drops the installer's closing note about the status bar asking for
permissions on first launch: shipped plugins are granted implicitly now, so the
prompt it told people to expect no longer appears. (That text is baked into the
0.1.9 tarball; it is wrong but harmless, and corrected for the next one.)
And gitignores *.core -- qemu writes one where you stand when it kills a target
on an illegal instruction, and a 100MB core dump nearly went into this commit.
0.1.9 contains everything since 0.1.8: the split button actually visible and
clickable where it is drawn, including on stacked panes; shipped plugins not
asking for permission; the status bar as a framed box in the pane style with a
new-tab button and margins matching the pane gap, collapsing to a single line
in the mobile layout; and runtime tabs keeping a status bar without losing the
purpose the CLI uses for identity.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The artifact was stale twice over: it predated the protobuf fix and did not
contain the CLI at all. Both fixed, and the whole chain re-verified from the
tarball rather than assumed.
The CLI ships as a single 31K file (`bun build --target=bun`) run by the bundled
bun, rather than a source tree or a second `--compile`d binary that would embed
another 90M copy of bun. `install.sh` generates the wrapper and pins
SL0PPI_BIN to the sl0ppij it just installed, so the orchestrator can never end
up driving some other zellij that happens to come first on PATH.
Verified in a throwaway HOME with node, npm, bun, cargo, rustc and python3 all
replaced by poison stubs that fail loudly if invoked:
sl0ppij --version -> 0.45.0+sl0p1 (static musl, no libc dependency)
pi --version -> 0.84.1 (bundled bun)
sl0ppi doctor -> all good
sl0ppi init x2 -> two projects scaffolded
sl0ppi up -> session "dev", 2 tabs, agents suspended
sl0ppi ls -> agent:suspended, 1 pane each
sl0ppi up (again) -> "up to date"
And the promise the whole thing exists for, end to end: attach a client, press
Enter in the suspended agent pane, and pi starts on the bundled runtime -- while
the other project's agent stays suspended, because only the focused pane got the
key.
`make test` now runs the CLI suite alongside the Rust ones, so the two halves
cannot drift apart unnoticed.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Phase 3: `make package` now produces a tarball that provably works on a machine
with no node, npm, bun or rust.
Two bugs the clean-room test found, neither visible until a session actually
started:
- the default layout builds its status bar out of zjstatus, which we were not
shipping at all (vendored as sl0pstatus/ in the preceding commits)
- install.sh installed a hardcoded plugin list, so zjstatus.wasm would not
have reached the config dir even once staged
Also: layouts/*.kdl still pointed at ~/.config/zellij, missed by the rename pass
because that pass only rewrote config.kdl.
Verified end to end, from the tarball, in a throwaway HOME with node/npm/bun/
cargo shadowed by stubs that fail loudly if invoked:
sl0ppij --version -> sl0ppij 0.45.0+sl0p1
pi --version -> 0.84.1 (on the bundled bun)
pir --help -> ok
sl0ppij -s realtest -> session starts under a pty, config "Well defined",
fork pane titles render, both wasm plugins load,
no errors beyond the first-run permission cache
Artifact: sl0ppi-0.1.0-x86_64-linux.tar.gz, 83M, + .sha256.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
config/config.kdl plugin path -> ~/.config/sl0ppij/plugins, builtin plugins
-> the sl0ppij: URL scheme. Verified to load under the
renamed binary ("[CONFIG FILE]: Well defined.").
install-config.sh syncs to ~/.config/sl0ppij
install.sh a stock zellij on the target is no longer a warning, it is
just a fact: the two coexist
stage.sh drops the "renaming at package time is a fig leaf" note
Makefile builds `-p zellij` (package) and ships `sl0ppij` (binary);
`make check` now also gates the root package, using the
prebuilt asset plugins so it does not need debug wasm
docs/ rename.md records what was done, what was deliberately
left (plugin-internal strings live in prebuilt wasm), and
the verification actually performed
|
|
|
Adds the layer that makes this a distributable product rather than three
directories:
VERSION one sl0ppi version for the whole monorepo
FORKS.md what each component is based on, and how to rebase the fork
Makefile build / vendor / stage / package, plus dev-box helpers
packaging/ fetch pinned payloads, assemble an install tree, install it
docs/ architecture, the rename plan, the roadmap
The self-contained runtime question is settled and verified: pi upstream builds
its own release binary with `bun build --compile`, and a vendored bun runs the
vendored pi dist unmodified, so the tarball carries bun + pi and needs no system
node, npm or rust on the target machine.
packaging/install.sh does a per-user install under ~/.local, never clobbers an
existing config (writes .new alongside, or backs up under --force-config), and
warns loudly when a stock zellij is present -- because until docs/rename.md is
implemented the binary is still zellij underneath and would collide with it.
|
