This adds syntax for running imps. For example:
-time ~s1
Runs the "time" imp with the argument ~s1. This blocks the terminal
until the imp has completed (backspace kills it, of course). You could
avoid blocking the terminal if you sacrifice the ability to use imps as
sources in more complex commands.
In keeping with this one-and-done view of imps, this also changes spider
to not use a live build of imps. This significantly reduces the amount
of uncertainty around imps -- spider will try exactly once to run your
imp, and if it fails it'll tell you. If you want to retry, that's up to
you.
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.
This extends `gol` "backward-inference" typechecking to thread through
cores. Recall that `gol` is used exclusively for receiving more
specific error messages; these changes should have no effect on programs
which already compile successfully.
Before, this would type-fail on the second `|%`.
```
!:
^+ ^?
|%
++ foo *@ud
--
|%
++ foo
?: =(1 1)
2
%foo
--
```
With these changes, it gives a mint-nice at `%foo`. It will also give
you explicit errors if you have the wrong number/names of arms,
including which arms it expects.
This is becoming much more important with static gall, since it's the
first time we've used core subtyping so extensively and in userspace.
This extends `gol` "backward-inference" typechecking to thread through cores. Recall that `gol` is used exclusively for receiving more specific error messages; these changes should have no effect on programs which already compile successfully.
Before, this would type-fail on the second `|%`.
```
!:
^+ ^?
|%
++ foo *@ud
--
|%
++ foo
?: =(1 1)
2
%foo
--
```
With these changes, it gives a mint-nice at `%foo`. It will also give you explicit errors if you have the wrong number/names of arms, including which arms it expects.
This is becoming much more important with static gall, since it's the first time we've used core subtyping so extensively and in userspace.
We were updating our state and then using that when checking if the rift
had incremented. This would never be true, since we'd already set the
new state.
Fixes#1852 again
