| Commit message (Collapse) | Author | Age |
|---|
| |
|
|
|
|
| |
again to overwrite), the rest of an X/'/w written and the refused named; Edit filters get a pane command's environment ($PARDES_MOUNT, $PARDES_9P, $PARDES_PID, $winid); an Edit with no commands runs beside one whose commands run unless it touches a file that one changes, refused busy (EBUSY) as is a second Edit with commands
Co-Authored-By: Claude Opus 5.5 <[email protected]>
|
| |
|
|
|
|
| |
(answered like a held read, so a status read or a filter reading the session's own mount runs beside it), a Tflush or hang-up of the write kills the commands' process groups and changes nothing; e loads by Get's way (asked once, clean after, undo puts the name back); ~ in e r w f B; B checks every name first; an Edit that runs commands is a write of its own, refused up front with other lines; Edit's +Errors output keeps the keyboard where it was; X goes in pane order; a refused write open says its errno; the reference's Coming from acme rows say what Get file's undo, failure and directory refusal, Putall's answer, Zerox across Dump and Incl's directories now do
Co-Authored-By: Claude Opus 5.5 <[email protected]>
|
| |
|
|
|
|
| |
width is invalid (EINVAL), from a pane's exec too; Incl refuses a relative or missing directory and takes - only alone
Co-Authored-By: Claude Opus 5.5 <[email protected]>
|
| |
|
|
|
|
| |
off the loop (one undo step, a failure changes nothing, its stderr in +Errors, a 9P write answered when done), X and Y over the open text panes, b B D e r f w and the "file" address; checked against sam -d, and the reference's Edit section and Coming from acme row say so
Co-Authored-By: Claude Opus 5.5 <[email protected]>
|
| |
|
|
|
|
| |
step is out, so its err is in the log by then; with a step out it still waits for that step (follows rzxqzosq; monkey9p's one_failure_rule)
Co-Authored-By: Claude Opus 5.5 <[email protected]>
|
| |
|
|
|
|
|
|
|
|
|
|
| |
under 9ns --mntgen ($NINE_MOUNT/pardes/<name>), unset when it is not known
9ns says --mntgen with NINE_MNTGEN=1 (cloud9). Under `9ns --unix` the
mount is the server it dialled, never this session (its socket does not
exist until it starts), so it stays unset there; scripts fall back to
`9p -a "unix!$PARDES_9P"`. Nothing is statted: the name comes from the
session's socket and the environment. selfmount checks both modes.
Co-Authored-By: Claude Opus 5.5 <[email protected]>
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
last line is answered at once: the line runs at the editor's next step
A shell's truncating open of exec (or look, ctl, log, pager) sends a
setattr that changes nothing; it waited for the editor to be quiet, and
through a 9ns mount that quiet could never come: 9ns answers nothing else
on the mount while the setattr is out, and the editor's step may be out
reading a pane's file through it. This was the "truncating open of exec
hangs, only in selfmount" mystery. Only a truncate of a pane's file or a
tag waits now.
A close holding a last line with no newline hands it to the editor's step
(tree.runClosedLines, beside fillClosedPagers), as a /pager close does, and
is answered at once; a refusal is the log's err.
Co-Authored-By: Claude Opus 5.5 <[email protected]>
|
| |
|
|
| |
written after its directory with ghostty-vt, SGR becomes spans drawn over the plain text, every other escape is dropped, and PagerColor off pages it plain
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
klingon` is invalid (EINVAL), its message citing no doc path
A refused answer quoted the word `answer`, not the choice refused. A
`name` with nothing after it was an unknown control message. A Repl of
no such language failed EIO with a pointer into the reference; it now
says `invalid language` (EINVAL, here and through a mount) and how many
more there are. A builtin's failure that says invalid anywhere is
EINVAL, as 9ns reads it.
Co-Authored-By: Claude Opus 5.5 <[email protected]>
|
| |
|
|
|
|
|
|
|
|
| |
there says no such socket (ENOENT), and the hint says tcp! takes a numeric address
`Mount peer rel/x.sock` dialled relative to wherever the editor ran;
`Mount peer unix!/nonexistent` said `dial failed: no answer` (EIO); and
the hint offered `tcp!host!port` where only a numeric address is taken.
Co-Authored-By: Claude Opus 5.5 <[email protected]>
|
| |
|
|
|
|
|
|
|
|
|
| |
address, EINVAL, not a session name that does not answer
A dial with a `!` and no `/` that was neither tcp!, quic! nor unix! was
taken for a session's name, failing as `dial failed: no answer`, EIO.
It is now refused as the malformed address it is, before any dial. A
path with a `!` in it still dials.
Co-Authored-By: Claude Opus 5.5 <[email protected]>
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
that asked it, and says on the message row that it previewed and applied nothing
A multi-file Rename filled a +Search preview but the waiting exec write
answered the pane it was asked from, and nothing was said. lspResponse
now notes the pane it filled (fs.lsp_result); the write that waited for
the answer reads that pane back, as a look or an exec answers the pane
it went to, and the message row says `Rename: N edit(s) across files,
previewed, not applied`.
Co-Authored-By: Claude Opus 5.5 <[email protected]>
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
permission denied, and a Save there says so, not no such directory
`pardes noperm/a/b/c` and `pardes /proc/1/root/x` took the missing
directory for one Save would make, opened a pane and exited 0; its Save
then said "no such directory". fs.deniedAbove finds the nearest
directory there and asks whether it may be searched and written:
forwarding refuses such a name, exit 1, "permission denied", and a
failed Save says "permission denied", which the writer's 9P error
carries as EPERM (9ns: EACCES).
Co-Authored-By: Claude Opus 5.5 <[email protected]>
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
another client's exec meanwhile can never take the text into its pane
pardes - wrote `pager <dir>` to /ctl, then read /exec on a fresh open,
which answers the session's last answer: a client that exec'd in
between had its pane overwritten by the paged text. /pager takes the
directory and answers the +Pager's serial on the open that wrote it,
as /pane/new answers its own open; the ctl verb is gone. Client.ask
writes and reads on one open. The README's look recipe reads its
answer on its own open too.
Co-Authored-By: Claude Opus 5.5 <[email protected]>
|
| |
|
|
|
|
|
|
|
|
|
|
| |
takes all that fit, before the hangup cuts it
A follower reads one record per read, and a Restore hangs every client
up, so records queued just before it -- the ones a script most wants,
what led up to the Restore -- were lost: the read after the first was
cut. Before the cut, each held read of /log is answered with every
whole record queued that fits it.
Co-Authored-By: Claude Opus 5.5 <[email protected]>
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
8 MiB arrives whole, not as its last chunk
Each 8 MiB chunk went in by its own Client.write, which opens a body
with OTRUNC, so every chunk replaced the one before and a long page
kept only its tail, with exit 0. The text now goes in through one open,
truncated once and written at rising offsets; a long write is timed by
its progress, each 9P write answered within 30 s rather than the whole
transfer within 2. fs.py pages 11 MiB of numbered lines and compares
the body byte for byte, and pages past the 256 MiB cap and checks the
first 256 MiB and the cut note.
Co-Authored-By: Claude Opus 5.5 <[email protected]>
|
| |
|
|
|
|
| |
core, threads, detached sessions and 9P fit, from the old design notes checked against the code
Co-Authored-By: Claude Opus 5.5 <[email protected]>
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
signal, and a start sweeps the ones a dead editor left
/tmp had gathered thousands of private prompt files: Exit removed its
own, but an editor killed by a signal, or a crashed one, left them for
ever. They now carry their editor's pid in the name, a SIGTERM or
SIGHUP removes them before the signal's death, and each start removes
those whose pid kill(pid, 0) answers ESRCH for. Files of the older
shape carry no pid and are left alone, as a running older editor may
still read them; the shared ones in the runtime directory are kept,
being every session's.
Co-Authored-By: Claude Opus 5.5 <[email protected]>
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
sweeps the pardes-9p-<pid>.sock files whose pid is gone
The runtime directory had gathered a hundred sockets of dead editors:
only a clean exit removed its own, and a signal or a crash left it. The
terminal's kill handler and, where nothing else handles the signals, a
handler of the listener's own now unlink the socket before the signal's
death. At listen, each pardes-9p-<pid>.sock whose pid kill(pid, 0)
answers ESRCH for, that is a socket of this user's and that nothing
answers on, is removed; a live pid's, a named session's and anything
else are never touched.
Co-Authored-By: Claude Opus 5.5 <[email protected]>
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
its own and renamed into place
A client that waits for the socket file and then connects, as fs.py's
session helper and scripts do, was sometimes refused under load. The
listener bound the socket at its final name, so the file existed a moment
before listen(2), and a connect in that window got ECONNREFUSED. Now it
listens under `<name>.<pid>`, is chmodded, then renamed over the final
name, so that name only ever names a listening socket. A final name held
by a live listener is still refused, and a name with no room for the
suffix is bound in place as before. The registry test checks the socket
is listening where it appears and that the temporary name is gone.
Co-Authored-By: Claude Opus 5.5 <[email protected]>
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
waiting: 128", and a mount beside 40 held event reads still answers
Two limits met. pardes parked 32 reads per connection and refused the
next with EAGAIN's C string, "Resource temporarily unavailable". 9ns kept
32 tags and 31 workers, each pinned by a held read. So 31 followers
through one mount took every worker, and `cat layout` then queued for
ever: the whole mount deadlocked.
cloud9 (705be665, pushed to sr.ht and pinned here) now refuses in words
past the cap. Its 9ns window is 256, so a mount always has workers past
what pardes holds. pardes raises its cap to 128. fs.md documents the limit
beside held reads. selfmount.py holds 40 event reads through the mount and
reads layout beside them. It times out with the 9ns installed before this
change and passes with the new one.
Co-Authored-By: Claude Opus 5.5 <[email protected]>
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
editor: the refusal is printed, exit 1, and no stray pane is left
When the environment named a live session that answered, several
failures broke out of forwarding and started a whole editor inside the
pane that asked: a refused name, a pane the session has not, a failed look
write. Its screen was drawn over the shell. Now, once the session answers
(Client.probe), every refusal is printed as `pardes: <file>: <why>`, in
the session's own words (the Rerror, now kept by the client), and the
launch exits 1, as acme's B does. A new name the session refuses deletes
the pane made for it, so no empty +New is left. A missing environment or a
session that does not answer still starts a separate editor. fs.py checks
a refused name and a stale PARDES_PANE.
Co-Authored-By: Claude Opus 5.5 <[email protected]>
|
| |
|
|
|
|
|
|
| |
untouched: the GUI no longer calls into a freed one at startup
listen started the editor's turn and pointed its answer_held and wake_parked hooks at the new Listener, then, when socketPath found the path too long for sun_path (108 bytes), freed the Listener with gpa.destroy while the hooks stayed set; the GUI's next rest (waitInput) called answerHeld on freed memory and died with SIGSEGV. The lapis bench's runs crashed for 12-character names in an 82-byte runtime directory (a 110-byte path) and not for shorter ones. The path is checked before anything is made; a unit test asks listen for a name too long and finds the turn's hooks clear and the turn not started.
Co-Authored-By: Claude Opus 5.5 <[email protected]>
|
| |
|
|
|
|
|
|
| |
is deleted, so it can be $EDITOR
A launch inside a pane forwards its file to the session's look and returned at once, so fish's Ctrl-O (edit_command_buffer), git commit and crontab -e read their still-unedited file back and went on. With --wait, as acme's E against B and read the way plan9port's E reads acme's log, it finds the pane /index names the file by (the one already showing it, if open), follows /log on one connection with 'follow new', reads /index once more to catch a Del that came first, and then blocks with no deadline until that pane's del record: exit 0, or 1 when the connection ends with the session. The 9P client's one-shot requests keep their 2 s deadline; its new follow takes it for the setup only. Outside pardes nothing changes. --help, docs/fs.md, the README and the 9P skill say to set EDITOR='pardes --wait', which GIT_EDITOR follows. Tested in fs.py (it returns within 50 ms of the Del, a second -w waits on the same pane, one whose session is killed exits 1) and end to end: fish 4.8 in a detached session, echo hi, Ctrl-O, the waiting launch idle in poll, the line edited over 9P, Save, Del, and fish ran echo edited.
Co-Authored-By: Claude Opus 5.5 <[email protected]>
|
| |
|
|
|
|
| |
A failure the editor said as it performed a write's work (a Save's disk write, a shell, a language server) was posted as a msg and taken back out when the write's err was logged, which it cannot be once a log follower has read it: a follower saw both. Such a failure is now posted without a msg in the first place (fs.write_waits), and nothing is taken back.
Co-Authored-By: Claude Opus 5.5 <[email protected]>
|
| |
|
|
|
|
|
|
| |
it needs more
A last line with no newline was held to the close, so printf bogus > ctl answered 0 and failed only in the log, Edit ,s/zzz/y/ too. A write shorter than its Twrite is the whole of what was written (acme takes each write whole): its tail runs then and a failure is the write's. It is held only when the parser says it needs more -- an open { block, an a/c/i text -- or when the write filled its Twrite and may go on (the listener tells the core the room, msize less its header).
Co-Authored-By: Claude Opus 5.5 <[email protected]>
|
| |
|
|
|
|
|
|
| |
is a real refusal or says why it cannot fire
A sweep for round 23's crash: a run's answer (pty/run) was bufPrint'd into 48 bytes with catch unreachable, so a foreground program's long name (macOS gives up to 32 bytes) panicked; it now cuts at the room, keeping its newline, in 96 bytes. The rest were numbers into buffers sized for them, a braille codepoint, pthread calls on the queue's own mutex, and pdf_view's resolved outline entries: each now carries a one-line comment saying why it cannot fire.
Co-Authored-By: Claude Opus 5.5 <[email protected]>
|
| |
|
|
|
|
| |
std's statFile takes the kernel's ENAMETOOLONG for a bug (errnoBug), so a name, look, DumpDir or Save path with a part over 255 bytes panicked the editor (exec.kindOf via writeName, recentKeeps, dumpFailed). Every non-test statFile now goes through fs.statPath, which refuses such a name as NameTooLong first; fs.py drives long, looping, not-a-directory and not-ours paths through name, look, DumpDir, Dump and Save.
Co-Authored-By: Claude Opus 5.5 <[email protected]>
|
| |
|
|
|
|
|
|
| |
room fails, and so does a write to an image's or PDF's body
Callers or Callees with nothing found, Hover or Lspwhy with no room for its pane, and a question asked of no file's pane said nothing, the 9P write succeeding; a body write to an image or PDF pane went nowhere. A write that asks a language server now waits for its answer (turn.lsp_answers), and what fails there -- nothing found, no answer, a backend's @none why, a placement with no room (ENOSPC) -- fails the write and logs its err. No diagnostics is said, not failed.
Co-Authored-By: Claude Opus 5.5 <[email protected]>
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
answers
A shell whose exec failed (a script's missing interpreter) was reported
started: Tty and pty/ctl exec succeeded, then the pane died. The child now
reports a failed chdir or exec through a close-on-exec pipe the parent
reads before acknowledging the shell; the host's spawn fails with the
reason (`shell not found`, ENOENT), which fails the waiting write. A Tty
whose first shell never ran leaves no pane; a terminal restarted by
pty/ctl exec keeps its pane.
Co-Authored-By: Claude Opus 5.5 <[email protected]>
|
| |
|
|
|
|
|
|
| |
It failed EIO with `file not found`, which named no file that was
missing. It says `Save <path>: no such directory`, and a late failure
saying `no such` answers ENOENT, as a builtin's does.
Co-Authored-By: Claude Opus 5.5 <[email protected]>
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
is said as `dial failed: <reason>`
Mount took any well-formed dial and nothing was found out until the
first look through it, which then said `look: look: dial`. Mount now
probes the peer (version, attach, its root) with the turn out, and fails
its write, mounting nothing, when none answers; the dial errors read as
words, `no answer`, `timed out`, `hung up`, and a look through a peer
gone since names its path: `look: /n/peer/f: dial failed: no answer`.
Co-Authored-By: Claude Opus 5.5 <[email protected]>
|
| |
|
|
|
|
|
|
|
| |
The save record was logged as soon as the host was asked to write, so a
Save into a read-only directory logged save and then failed. It is now
logged only once the write is done; a failure's err record (the write's,
naming the path) stands alone, the msg it was also said as dropped.
Co-Authored-By: Claude Opus 5.5 <[email protected]>
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
A mount cuts a write at its message size, and each piece ran on its own: a
line cut at the boundary ran as shell commands and a 50 KB Edit block
broke. An open of look, exec, tagexec, any ctl or a column's exec now keeps
an unfinished last line, or an Edit block still open, until its next write
or its release, and never runs a fragment. The same open record holds what
its last write touched, which a read on it answers (as /net/tcp/clone
does); an open that never wrote reads the session's last as of its open.
A release that runs a held line waits for quiet and counts as a change;
a clicked line with a control character is still refused at its write.
Tested in unit tests, fs.py (python client, 8 KiB) and selfmount.py (the
kernel mount, a 1000-line seq burst and a 50 KB Edit block).
Co-Authored-By: Claude Opus 5.5 <[email protected]>
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
"Unix TCP and QUIC share one listener" failed 17 of 360 runs under load
(12 parallel copies), always at p.fs.opens: the client had hung up but its
connection's task had not yet seen it, reset() then cut the connection, and
the releases the hangup owes were refused as the old editor's. The test's
replacement editor is the same editor, so those opens stayed. It now waits
(resting, with its own deadline) for the runner to empty before reset:
0 of 360 after.
fs-test -Dquic=true failed too, at two points. A session Looking at its own
tree through a QUIC mount is features.txt's documented "left as they are"
case (QUIC is answered on the editor's thread); that check is dropped with a
note. The /screen check asserted body text that the view may have scrolled
past (2 of 7 runs); it now asserts the pane's tag. 10 of 10 after.
Co-Authored-By: Claude Opus 5.5 <[email protected]>
|
| |
|
|
|
|
|
|
| |
pardes leaves none behind; tests remove their /tmp dirs
Every pardes host wrote its own pardes-osc133-bash-* and -fish-* files to /tmp and removed them only at a clean teardown, so each killed session, test and crash left two: 72K of them had piled up. They are now written once per content, named by its hash, in the user's private runtime directory, renamed into place whole and shared by every pardes; without that directory the old private /tmp files remain. fish's -C source is quoted. The 9p_io tests remove their runtime dirs with what the listener left in them, and the snapshot runner removes its retry captures when every retry passed.
Co-Authored-By: Claude Opus 5.5 <[email protected]>
|
| |
|
|
|
|
|
|
| |
being reset
Four slots ran out under scripts plus a mount, and the fifth client was closed without a word, which through a mount looks exactly like a dead session. pardes now serves sixteen, and builds against cloud9 09b77cf, whose runner answers the Tversion of a client it cannot seat with an Rerror "too many connections" and tells pardes, which logs `err - 9p: too many connections`. QUIC keeps its own sixteen and still just closes.
Co-Authored-By: Claude Opus 5.5 <[email protected]>
|
| |
|
|
|
|
|
|
| |
names the path and why
The write answered ok and the pane stayed dirty, with `save: AccessDenied` on its message row: a script saw success. The failure now says `Save <path>: <why>`, and a 9P write that waited on the save fails with EIO and that text, logged as an err record.
Co-Authored-By: Claude Opus 5.5 <[email protected]>
|
| |
|
|
|
|
|
|
|
|
|
| |
The Restore marked the connections to cut in cloud9's Conn.user, which cloud9
also writes, clearing it for a connection accepted into that slot on another
task: a client dialling in as the marks were made could be marked old and
cut. Each connection is now stamped from a counter as it opens (cloud9's
opened hook), and a Restore cuts those stamped before its own count; nothing
is written from two tasks.
Co-Authored-By: Claude Opus 5.5 <[email protected]>
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
and restores
A client that wrote Restore saw its connection cut with no answer, and could
not tell a Restore from a crash. The listener now lets the writer's answer out
before the cut, and cuts only the old editor's connections, refusing their
requests meanwhile; a client that dials during it is the new editor's and
stays. Dump logs 'dump <path>' and the restored editor's log 'restore <path>'.
Keeping connections across a Restore was weighed and left: the fids name the
old editor's panes and opens, so it would mean carrying serials and open
records into the new one, where acme's Load only adds windows. tty's Restore
also closed its shells' ptys without reaping them; it retires them now.
Co-Authored-By: Claude Opus 5.5 <[email protected]>
|
| |
|
|
|
|
|
|
|
| |
The write got EPIPE: Kill set quit, the request waited for the editor to
settle its effects, and the editor quit and cut the connections first.
A write that quits the editor is now answered at once, and the listener
lets pending answers out (up to 200 ms) before it stops the runner.
Co-Authored-By: Claude Opus 5.5 <[email protected]>
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
and reads the settings, a pane's ctl its own
Every builtin could only be clicked, or written to exec, and the settings
could be read only as the Config window's prose. acme keeps window verbs on
a window's ctl, and webfs and upas/fs keep session settings on a root ctl.
Each builtin now declares its scope (scope = .session; settings are all
session, the rest pane), read by the registry. The root /ctl takes session
builtins and reads every setting in the words a write takes, so its read
written back changes nothing (panel and scene effects now take on/off like
the toggles, to make that true); a pane's ctl takes the pane's builtins
beside get, lock and unlock. Writes are checked whole and refused in Plan
9's ctl words (unknown control message "X", wrong #args ...), which 9ns
now maps to EINVAL (cloud9 re-pinned at a8c7a715). A builtin that would
prompt for its argument fails the write instead, and a refusal is answered
at once, not after the frame.
Co-Authored-By: Claude Opus 5.5 <[email protected]>
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
shut down
The held read is now kept by the Ticket cloud9's Conn.hold() gives its
park and answered through Conn.answerWith(), which makes the answer only
while that very park still waits, instead of walking the engine's slots
by tag; pardes no longer reaches into the engine for it. A second read on
an open whose read is held fails with file in use rather than sitting
parked where nothing answers it, and a read that waits with no open
record to hold it is logged and asserted on. A read on an event or
pty/data open whose pane closed answers acme's "window shut down"
(editors/acme/xfid.c:1005). The pane keeps its run's and its lock's open
handles, checked through openOf on use, not record indices. Docs: lock
from a shell needs a held fd, and a command that clears the screen may
read as cut.
Needs cloud9 zvuqvnzy (cca47d63), which adds Conn.hold, waiting and
answerWith; build.zig.zon still pins 82d8152c until that is pushed and
re-pinned.
Co-Authored-By: Claude Opus 5.5 <[email protected]>
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
Snapshots (and /log's cursor), runs, and the reader_handle constants for
event and pty/data each reused the open handle and each validated
handle and node on its own. Now p.fs.opens is one table of 64 records,
each the node it was opened on and a tagged union of what it holds, like
lib9p's per-fid aux and acme's Fid (editors/acme/dat.h:373-385): one
lookup (openOf), one release, ENFILE when full. A held read lives in
its open's record, so it goes with the release. Opens that hold nothing
answer handle 0 and take no record.
Co-Authored-By: Claude Opus 5.5 <[email protected]>
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
A following log, event, pty/data or a pty/run before its answer used to
answer .again and wait for a wakeAll, which only the parked-write path
asked for, so the band-aid had every queue push set turn.parked. Now the
core keeps such a read (ctlfs.hold) and, as the turn is given up after
anything that queued a record, ran a command out or closed a pane,
answers it on its own connection, the way factotum answers the log reads
it keeps and acme an event read. Only a read the engine still holds
parked is answered, because cloud9 tells the backend nothing of a
Tflush, so a flushed read spends no record.
Co-Authored-By: Claude Opus 5.5 <[email protected]>
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The editor's loop was the only thing that could answer a 9P request, which
made the editor's own syscalls through a mount of its own tree -- a Look at
/mnt/9p/pardes/<me>/anything under a `9ns --mntgen` view, a Save into it --
requests only the blocked loop could serve. The name-based refusal that
followed (ownMountSuffix) and the in-process routing of a mount of oneself
(Client.sameSession) were patches over that, and both are gone, with the
mailbox that shipped every request to the editor's thread.
One rule replaces them, `pardes.turn`: the core is single-threaded, the
editor's thread has the turn by default and gives it up in two kinds of gap
-- while it waits for input and while a step of it is out in a host syscall
-- and a cloud9 connection task takes it in those gaps to answer. `out`
counts the steps that are out, from any thread: while one is, the core reads
consistently but that step still holds pointers into it, so a request that
would change a pane (a write, a truncation, an rmdir) is parked in the
engine and retried when the turn is next given up with nothing out, and the
editor's own wake waits for the count to reach zero. It is never a write of
its own that a step waits on out there -- writes come from a shell
performing a save between steps -- so a parked request is never the
syscall's own, and making a pane or rendering a screen need not park:
every yield sits before its step's mutation, so the layout and the surface
are whole under it. A changing request that queued effects is answered
once the editor has performed them (`echo Save > exec` returns with the
file written, as acme's `put` does), and it settles the way a step does,
because without that a /log reader waited for the user's next keystroke.
Every host syscall on a user path has to give the turn up, not fs.zig's
alone: the first end-to-end run hung in `inotify_add_watch` performing the
new pane's watch effect. PDFs and images are read whole at open, so no
draw goes out into the host. The core's allocator takes its fixed buffer
through the lock-free interface, since a connection task allocates while
the editor's thread is out in a syscall that allocates too. A Restore puts
the replacement in first and releases every task waiting on the old core.
cloud9 (pinned at eb1a104) parks an open, a truncating wstat, a clunk and a
remove on `again`, not only reads and writes, and answers a parked job
whose fid was clunked without asking the backend.
Verified: test/selfmount.py runs the editor under `9ns --mntgen` and
Looks at, reads and Saves its own tree through the mount; a unit test pins
that a change parks while the editor is out mid-step and lands when it
rests, while a read is answered in the window. 9P over the Unix socket
against a tty session, same machine, Debug builds: a read of /index 278us
-> 61us, a truncating body write 1184us -> 609us, exec Save 718us -> 583us;
the gesture benchmark is unchanged (geometric mean 0.997 over 53 cells).
Also from the reviews: a notice chip over an image or PDF pane was painted
out by the picture drawn after the cells, so pictures give up the rows; in
the GUI a tree-sitter context band painted over the chip, so body layers
are emitted first; a message is one row of printable text, its 256-byte
cut never leaves half a glyph, and one wider than its pane keeps its tail
(the file name, the reason) rather than its head.
Co-Authored-By: Claude Fable 5.1 <[email protected]>
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Opening a path inside this editor's own 9P tree hung the session outright, and
it is easy to do by accident: a file manager whose $EDITOR is pardes, or a Look
at anything under /mnt/9p/pardes/<me>/. The realpath, the stat and the read all
leave through the mount and come back as 9P requests only this editor's loop
can answer, while that loop is blocked making them. The filesystem then stops
answering anybody, which is what made it look frozen rather than slow.
The answer has to come from the NAME, before any syscall, because the syscall
is the thing that never returns: the listener notes the name it is posted under
and `resolveOs` refuses a path containing `/pardes/<that name>/`, with
`readLimit` refusing it too for anything that gets past resolution. Another
session's mount stays perfectly usable, and `/n/self/...` is the way to reach
your own tree -- the editor serves it from memory without leaving the process.
Reproduced before and after: the 9P write that never returned now returns, the
editor stays responsive, and it spends four CPU ticks doing it.
The transient lines also now look like what they were modelled on. They carried
the context band's bookkeeping -- one list, rows reserved the way sticky
headers reserve them -- but still painted as ordinary body text, so a message
read as a stray line at the bottom of the pane rather than as part of its
chrome. They take the tagline font and the tagline's own colours now, verified
on a running editor: the announcement lands with font_role=tagline.
Two tests the features never had: a builtin announcing itself, reaching the
notice list, being overridden by Msg's own text and silenced by Verbose; and
the own-mount guard, including that a session with no listener refuses nothing.
Co-Authored-By: Claude Opus 5 (1M context) <[email protected]>
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The registry sweep could delete a live socket, anywhere on the filesystem. A
reviewer reproduced it: a socket that is bound but has not reached listen(2)
answers ECONNREFUSED exactly like a dead one -- that window is every server's
startup -- and the sweep then followed the entry's symlink and unlinked
whatever absolute path it named. It now follows a target only into the
directory our own sockets live in and only to a `pardes-9p-*.sock` name, it
re-probes immediately before deleting rather than trusting a probe that is by
then several syscalls old, and a readlink that exactly filled its buffer is
treated as the truncation it is. The test grew a case for an entry whose
target is not ours: the entry goes, the file does not.
Ctrl-V in raw tty mode was a black hole when the yank register was empty --
neither typed nor forwarded -- so vim's visual block, readline's quoted-insert
and every other program's Ctrl-V simply vanished. With nothing to paste the
chord belongs to the program again.
The lone-ESC flush added earlier was dead code. vaxis already returns Escape
for a one-byte 0x1b (`Parser.parseGround` asserts `input.len == 1`), so the
carried byte it waited for can never exist; a reviewer showed a 3 ms gap and a
60 ms gap behaving identically. Removed rather than left to imply a guarantee
it never provided.
A shell whose editor is gone can start one again. Naming a live but
unreachable session made `pardes <file>` exit 1, which let a stale environment
variable lock someone out of their own editor; it falls through to an ordinary
session, as it did before the variable existed.
Also: the macOS ABI check for `pardes_topbar_pane_border_px` had been replaced
by a duplicate of the line above it; `--startup` now fails on a leak the way
every other measurement in that file does, and stops calling its maximum a p95
below twenty samples; the served README and the skill no longer tell you to
write to `data` with `>`, which truncates the whole body before the write
lands; `docs/v9fs.md` described the allocate-on-walk design that was rejected;
and `test/fs.py` keys nesting off `PARDES_PID`, so its forwarding case stops
passing only when the runner happens to be inside a live pardes.
fs-test now reaches its one documented pre-existing failure instead of dying
early. Suite 778/783 with the two known crashes.
Co-Authored-By: Claude Opus 5 (1M context) <[email protected]>
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The 9P tree stops being a command language wearing a filesystem. /new
created a pane as a side effect of a *read*; it is now Tcreate in /pane,
with Tremove to close, which cloud9's engine has always supported and the
editor never declared: tree.zig now says
`features = .{ .create = true, .remove = true }`. Eleven pane ctl verbs
become files that can be read as well as written -- dot, limit, dirty,
mark, scroll, look, exec -- leaving ctl with `get`, the one verb no file
would say better. Root /ctl splits into a read-only /status and the
/look and /exec files whose write IS the click. stat carries real sizes
where it used to answer 0, and qid versions track a pane's revision, so a
client can poll for change without re-reading the body.
Commit a624a56 moved raw-tty keys to an early-return branch that knew only
Ctrl-B and bare Escape, and in the same edit deleted the paste branch below
it. That cost Shift-Escape (the unconditional way out of tty mode) and both
paste chords: Ctrl-V and Ctrl-Shift-V reached the child as keystrokes, so an
agent CLI running in a pane took Ctrl-V for its image-paste binding and
answered "No image found in clipboard". Both are restored, with tests.
Nested detection was not subtly broken but deleted: 60367d8 removed
nested.zig's process-ancestry walk and left "am I inside pardes" derived from
PARDES_FORWARD_LOOK, which read "0" both for --nested and for "the listener
did not come up". PARDES_PID now answers that question on its own, checked
with kill(pid, 0); PARDES_9P and PARDES_PANE answer how to reach it; the flag
is gone. The posted-9P registry also self-heals now -- a session that aborts
cannot unlink its own socket, so posting sweeps entries whose target refuses
a connection, symlinks only and on a definite ECONNREFUSED only.
Elsewhere: tty scrolling is sticky-bottom, following new output only from
the last row, with typing and entering raw mode snapping back to live; the
boot layouts are a Boot enum instead of a chain of ifs, and the bare tty
startup (Boot.tty, which main.zig names) opens an empty text pane under the
shell while tests keep Boot.tty_shell; builtins announce themselves on the
message row under a Verbose setting that is on by default; Config prints
each setting the way you would type it back, so WindowOpacity 70 rather than
"WindowOpacity: 70%"; LocationsConfig opens its window only when called bare;
every tagline puts the word that closes the thing last, and a column now
outlives its panes -- closing the last one leaves an empty pane, and only
Delcol, newly on the column tagline, takes the column away.
Co-Authored-By: Claude Opus 5 (1M context) <[email protected]>
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
pardes spoke 9P and could be mounted, but only by naming its socket:
$XDG_RUNTIME_DIR/pardes-9p-<name>.sock sits one directory above the
registry and nothing could find it. Now a listening editor advertises
itself at $XDG_RUNTIME_DIR/9p/pardes/<name>, a symlink to the socket it
already binds. One directory for the program, one entry per editor —
the layout zmx posts its sessions under — so several editors group
rather than crowd the registry root.
The socket does not move: adopting the registry only advertises. Only
the runtime-directory socket posts, so an instance on the
~/.local/state fallback stays out of the user's registry, the way a
private ZMX_DIR does for zmx. Stopping unposts, and only while the
entry is still ours, so a name another editor has since claimed is
never unlinked. The cloud9 pin moves to 9c4d668c for cloud9.post's
path helpers.
Serving is the whole of it. Consuming the registry is 9ns's job: it
mounts the lot at /mnt/9p and an interactive fish already self-wraps in
one, so a pardes started from a terminal reads /mnt/9p/harness/... with
the same code that reads any other path. Two drafts that taught
`resolve` to dial the registry itself were reverted — one duplicated
9ns for no gain, the other reinterpreted relative dials, which are a
feature. `resolve` is byte-identical to what it was, and no dial that
worked changes meaning.
What pardes still does not do, and why, is in docs/cloud9.md: it binds
its own socket rather than posting through cloud9.post, because post
claims flat names only — legalName rejects '/', and claimName derives
its lock directory by stripping "/9p" — so a name inside a subdirectory
cannot go through it. zmx hand-rolls the same symlink for the same
reason. Unifying them means teaching post a group, which is a change to
adversarially-hardened code rather than a rename.
docs/divergences.md records what this bookmark move leaves beside it:
the editor line rruwvuzm (~1300 lines, forked at 01104e7c, still on the
old cloud9 pin), the other bookmarks, and two failures that are not
this change — fs-test's syntax-highlighting assertion, which fails
identically on a clean main, and pardes not starting headless, which is
why this is covered by 9p-io-test rather than by running the editor.
Tests: 11/11 9p-io-test, including a listener that posts on start and
unposts on stop; 31/31 unit-test.
|
