| Commit message (Collapse) | Author | Age |
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
Published 0.1.1 with the dead-session and flaky-read fixes.
Also removes the `sl0ppi-cli` line from MANIFEST and the version field from
cli/package.json: the CLI ships as part of the product, so a version of its own
only drifts -- a 0.1.1 release shipped a MANIFEST claiming sl0ppi-cli 0.1.0.
Records the terminal-level flakiness as a known issue with the measurements, so
it is a tracked defect rather than folklore: list-tabs/list-panes fail ~60% of
the time against a detached live session on a 2-vCPU box, ~25% with a client
attached, and the action client blames "no active session" for what is really a
transient enumeration failure.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The gnu release build required GLIBC_2.39 (Jan 2024), so the "install it on
another machine" artifact would have failed on Debian 12, Ubuntu 22.04 and
RHEL 9. That is the whole premise of this repo, so it is a defect, not a nit.
make build -> cargo zigbuild --target x86_64-unknown-linux-musl
result -> ELF, statically linked, 0 GLIBC_ symbols, 51M
make build-gnu kept for fast local use
A musl build needs a musl C toolchain: isahc/curl pulls libz-sys and
libnghttp2-sys unconditionally (confirmed: --no-default-features does not drop
them). cargo-zigbuild + the ziglang python module were already installed here,
so this needs no sudo, no docker daemon and no system packages.
stage.sh now refuses to be quiet about it: it reports "statically linked" or
warns loudly that the artifact inherits the build box's libc.
Re-verified from the tarball in a throwaway HOME with node/npm/bun/cargo
replaced by poison stubs: static binary, pi 0.84.1 on the bundled bun, both wasm
plugins installed, session starts under a pty with no errors.
Remaining libc floor is bun's own glibc 2.17 (2012); bun publishes a musl build
if Alpine ever matters.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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.
|