| Commit message (Collapse) | Author | Age |
|---|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
zellij-server is one enormous crate and `fastdev` was building it in 16
codegen units, which is the granularity the incremental cache can skip work
at: a one-line change re-optimised a sixteenth of the crate. Splitting the
crates we actually edit into 256 units makes that a sliver instead.
Measured on the same one-line change to pane_boundaries_frame.rs, `git
checkout` of the file to a linked binary:
codegen-units = 16 52s
codegen-units = 256 6s, 4s on a second run
+ opt-level = 1 5s (rejected: not worth a slower binary)
Ruled out on the way: linking the 69MB binary is ~2s, and rust-lld did not
beat the default linker on it, so the linker was never the problem. Root
crate codegen plus link is ~2s of the total.
Costs one 80s rebuild when switching profiles, and the fastdev binary keeps
opt-level 3. Verified with the full server/utils suites and make check-live.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Makes the fork installable and runnable beside a stock zellij: separate binary
name, config dir, cache dir, socket dir, log file and plugin URL scheme.
Everything user-visible is defined once in zellij-utils/src/branding.rs and
referenced from the ~15 places that used to hold a literal, rather than sed-ing
the tree -- upstream has 3300 commits of future rebases, and each touched
upstream line is a conflict forever. A conflict in branding.rs itself always
resolves the same way: keep our constant, take their code.
binary zellij -> sl0ppij
config dir ~/.config/zellij -> ~/.config/sl0ppij
system cfg /etc/zellij -> /etc/sl0ppij
cache/data ProjectDirs(Zellij) -> ProjectDirs(foo.sl0p.sl0ppij)
socket/tmp /tmp/zellij-$UID -> /tmp/sl0ppij-$UID
log zellij-log/zellij.log -> sl0ppij-log/sl0ppij.log
plugin urls zellij:tab-bar -> sl0ppij:tab-bar (zellij: still parses)
Two things deliberately NOT renamed:
- The cargo package stays `zellij`; only [[bin]] is renamed. Renaming the
package would ripple through every intra-workspace dep, the plugin API and
the 0.45.0+sl0p1 version trick for a name nobody sees.
- The $ZELLIJ* environment variables stay, because the ecosystem (shell
prompts, "am I in a multiplexer" checks, our own pi-ext) looks for them. We
now export $SL0PPIJ* alongside them, and those take precedence on read.
branding::import_compat_env() folds an inherited ZELLIJ_CONFIG_DIR into its
SL0PPIJ_ spelling at startup, before clap reads the environment -- clap can
only be told one variable name per argument.
Snapshots: 14 updated, all of them the plugin URL scheme or a session message.
The insta churn (assertion_line metadata, trailing newlines) that a bulk
--force-update introduces across 340+ other snapshots was reverted, so the diff
here is only what actually changed.
Tests: zellij-utils 471 passed, zellij-server 1499 passed. branding.rs carries
its own tests, including one asserting no shipped default path contains the
string "zellij".
Verified live: sl0ppij creates /tmp/sl0ppij-1000 next to an existing
/tmp/zellij-1000, and `sl0ppij list-sessions` reports none while a stock zellij
reports three running sessions.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
`zellij --version` was identical to upstream, so there was no way to tell a
fork binary from a stock one.
Uses BUILD METADATA (+sl0p1) rather than a prerelease (-sl0p1): cargo ignores
build metadata when matching version requirements, so the intra-workspace
`zellij-utils = "0.45.0"` dependencies still resolve. The prerelease form was
tried first and fails to resolve - it would require updating every member
manifest to depend on the exact prerelease.
Checked against the places VERSION is actually consumed:
- shared::version_number() yields 4500 for both 0.45.0 and 0.45.0+sl0p1, so
terminal version reporting is byte-identical, and still orders below 0.46.0.
- client/server compatibility keys off CLIENT_SERVER_CONTRACT_VERSION, not
this, so existing sessions are unaffected.
- ZELLIJ_PLUGIN_ARTIFACT_DIR is keyed by VERSION, so the bundled wasm plugins
are recompiled once on first run after a bump. One-time, harmless.
Baselines held: zellij-server 1421/30, zellij-utils 435/5.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Building this fork for local use took ~3 minutes per one-line change:
[profile.release] sets lto = true and codegen-units = 1, so every rebuild
redid whole-program optimization on a single core. That is right for a
shipped artifact and pure waste for a binary we just want to look at in a
terminal - zellij is bound on a human, not on codegen.
[profile.fastdev] inherits release, keeps opt-level 3, drops LTO, uses 16
codegen units and keeps the incremental cache:
cargo build --profile fastdev -p zellij ~2.8s incremental (was ~3min)
[profile.release] is deliberately untouched, so shipping/benchmarking builds
are unchanged.
.fastfeedback/SPEED.md records the narrow commands, measured timings, the
deploy loop, and - importantly - the PRE-EXISTING test failure baselines
(30 in zellij-server, 5 in zellij-utils) so a future session does not waste
time chasing failures it did not cause.
Rejected: the gold linker (rustc warns it is deprecated with known Rust
bugs) and clang+lld (no lld binary installed). Dropping LTO removed the
dominant cost anyway.
|
|
|
Squashed import of upstream zellij at 0e6e4404 ("Support the Kitty Image
Protocol (#5428)"), the merge-base our fork was developed against. Upstream's
3311 commits are deliberately NOT replayed here; only our own fork commits are,
so the monorepo stays small and `git log sl0ppij/` shows sl0p work, not zellij's
entire history.
Upstream provenance is tracked in FORKS.md and can always be re-fetched from
https://github.com/zellij-org/zellij.
|
