As follow-up to 3fdef1468, we now no longer store the prompt or cursor
in state. These were still used for view initialization, but it's more
appropriate to %hey the underlying console application in those cases.
The scry endpoints we remove, expecting clients that depended on them
to send a %hail instead.
No longer inserts newlines or redraws the prompt post-print, pushing
this responsibility down to drum where it belongs.
Additionally, separates the flow for dill's own output, from that of the
console application. This lets us keep the desired behavior for now, and
will ease reworking in the future.
Last-printed-line and cursor position are still kept around in dill
state, in order to respond to the relevant scry endpoints. These should
either be refactored to scry into the underlying console app, or be
removed entirely in favor of %hey.
Instead of confining you to just the bottom row. 0,0 is bottom left.
Doesn't behave exactly as expected for non-zero column coordinates yet,
but all in due time.
Likewise for belt. This necessitates renaming the %mor blit for newlines
to %nel, making this require a new runtime version. That's fine, more
breaking changes are to follow.
* jb/motion:
pill: solid
zuse: remove %crud from vane-task
arvo: full vane names in $sign
aqua: build again (still broken)
arvo: reform of the scry reform
This was a little bit too crummy. Instead, we put in a placeholder of ~,
which should be forwards-compatible with atomic session identifiers,
where ~ identifies the default session.
Additionally touches up the herm wires/paths to stick to the above more
closely.
This lets us support the "random userspace app sending dill belts".
Ultimately, we'll want to be able to specify a session identifier
alongside the belt, instead of strictly relying on the duct.
Adds a %view task, which opens a subscription on the output sent to the
specified session. %flee closes the same.
Whenever dill sends a blit to the session, any subscribers get the
output also.
The structures here will become more reasonable once we replace ducts
with proper dill session identifiers.
People using older runtimes might not support the %klr blit. It's not
uncommon for prompts without style to get passed in as %pom though, so
here we catch that case and turn it into a %pro, which gets rendered as
a traditional %lin.
Depending on the additions to term.c made in 467d8d239 allows dill to
forget about ansi escape codes, and pass styled text nouns straight on
to vere.
Also removes a bit of logic from drum, which assumed things about the
rendering of escape codes to adjust cursor positioning. Now it simply
states the semantic cursor position, letting the runtime deal with the
potential influence of styling.
We need to get updates directly into %home in case the marks depend on
changes to hoon.hoon. %base has no reason to exist.
Our ota strategy is now to merge from parent/kids to home, then
parent/kids to kids.
Uses Zuse's previously unused +harden helper function to streamline
+task unwrapping in vanes.
(Arguably, in landlocked vanes like Ford, we should crash if we get a
%soft task, since no events should be coming in directly from the
outside.)
This removes the %http-response special case from gall. In its place,
we implement a subscription regime with the following steps:
- Agent sends %connect to Eyre
- Eyre pokes agent with %handle-http-response, including unique eyre-id
- Agent passes %start-watching to Eyre with eyre-id and unique app-id
- Eyre subscribes to agent on /http-response/app-id
- Agent produces a %http-response-header fact followed by 0 or more
%http-response-data facts and possibly a %http-response-cancel fact
- Agent produces a %kick to close the subscription, which Eyre
interprets as completion of the message.
This works when there is data. There is currently a bug where if the
response has no data in total (as in the case of a naked 404), no
response will be sent.
This also includes lib/http-handler, which implements a convenient
interface for agents that want to respond immediately with all the data.
This lets them avoid carrying extra state to keep track of pending
requests.
This should really have access to your state and the ability to change
it. Perhaps a more minimalist design would be better: just keep track
of the requests, then hand it off to +on-watch when eyre is ready to
receive responses. It's not clear how to pass in the request data in
+on-watch.
