ilyakooo0/urbit
1
0
Fork 0
mirror of https://github.com/ilyakooo0/urbit.git synced 2024-11-11 04:48:00 +03:00
Code Issues Packages Projects Releases Wiki Activity
face904377
urbit/pkg/arvo/app/clock.hoon

41 lines
720 B
Plaintext
Raw Normal View History

various: add [landscape] marker to apps in arvo
2020-09-01 04:54:39 +03:00
:: clock [landscape]:
::
:: deprecated, should be removed
apps: stop serving webpages from all apps except publish
2020-04-29 22:01:31 +03:00
::
clock: add dbug
2020-04-01 23:26:07 +03:00
/+ *server, default-agent, verb, dbug
eyre: subscribe to apps for responses 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.
2019-11-09 10:31:11 +03:00
=, format
::
get geolocation from weather app, revise clock appearance to match new launch page
2020-02-06 05:08:22 +03:00
|%
::
+$ card card:agent:gall
+$ versioned-state
$% state-zero
==
+$ state-zero [%0 data=json]
--
ames: backpressure fixes
2019-11-27 01:56:20 +03:00
%+ verb |
clock: add dbug
2020-04-01 23:26:07 +03:00
%- agent:dbug
get geolocation from weather app, revise clock appearance to match new launch page
2020-02-06 05:08:22 +03:00
=| state-zero
=* state -
gall: mall -> gall
2019-11-19 07:36:21 +03:00
^- agent:gall
|_ =bowl:gall
eyre: better userspace libraries
2019-11-09 23:22:59 +03:00
+* this .
def ~(. (default-agent this %|) bowl)
::
apps: stop serving webpages from all apps except publish
2020-04-29 22:01:31 +03:00
++ on-init on-init:def
clock: ensure launch is listening correctly In the wild, ships that were live pre-OS1 still had launch subscriptions open to the clock on the /tile path, instead of the currently-used /clocktile path. Additionally, launch state for the clock tile seemed incomplete. Here, we simply re-%add the clock to launch. Note that launch currently does not clean up old subscriptions on path change. For the pre-OS1 case, the old path is no longer in use, rendering the subscription harmless. For cases where the correct subscription was already in place, it'll print a %watch-wire-not-unique, but doesn't do any harm besides that.
2020-04-02 00:13:57 +03:00
++ on-save !>(%3)
goad: recompile apps after changes to /sys OTAs commonly end up in an inconsistent state if apps depend on changes to /sys. For example, the %sift changes break on OTA because %spider needs to be reloaded so that it's aware of the new thread type. This adds a %goad app, which reloads all apps after every change to /sys. Getting this to start OTA is nontrivial, but this pattern should work for apps in the future. The changes to clock shouldn't generally be necessary; they are only necessary here because we can't rely on hood to start goad, since hood fails to compile if it's run before zuse is reloaded. Once goad is active, this will cease to be a problem.
2019-12-14 03:32:13 +03:00
++ on-load
|= old-state=vase
clock: ensure launch is listening correctly In the wild, ships that were live pre-OS1 still had launch subscriptions open to the clock on the /tile path, instead of the currently-used /clocktile path. Additionally, launch state for the clock tile seemed incomplete. Here, we simply re-%add the clock to launch. Note that launch currently does not clean up old subscriptions on path change. For the pre-OS1 case, the old path is no longer in use, rendering the subscription harmless. For cases where the correct subscription was already in place, it'll print a %watch-wire-not-unique, but doesn't do any harm besides that.
2020-04-02 00:13:57 +03:00
^- (quip card _this)
eyre: better userspace libraries
2019-11-09 23:22:59 +03:00
:_ this
apps: stop serving webpages from all apps except publish
2020-04-29 22:01:31 +03:00
[%pass / %arvo %e %disconnect [~ /'~clock']]~
eyre: subscribe to apps for responses 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.
2019-11-09 10:31:11 +03:00
::
apps: stop serving webpages from all apps except publish
2020-04-29 22:01:31 +03:00
++ on-poke on-poke:def
++ on-watch on-watch:def
eyre: subscribe to apps for responses 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.
2019-11-09 10:31:11 +03:00
++ on-leave on-leave:def
++ on-peek on-peek:def
++ on-agent on-agent:def
apps: stop serving webpages from all apps except publish
2020-04-29 22:01:31 +03:00
++ on-arvo on-arvo:def
eyre: subscribe to apps for responses 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.
2019-11-09 10:31:11 +03:00
++ on-fail on-fail:def
--
Reference in New Issue Copy Permalink