ilyakooo0/urbit
1
0
Fork 0
mirror of https://github.com/ilyakooo0/urbit.git synced 2024-12-15 10:02:47 +03:00
Code Issues Packages Projects Releases Wiki Activity
277debf710
urbit/pkg/arvo/app/clock.hoon

121 lines
2.7 KiB
Plaintext
Raw Normal View History

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
/= tile-js
/^ octs
/; as-octs:mimes:html
/: /===/app/clock/js/tile
/| /js/
/~ ~
==
=, 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)
::
++ on-init
gall: mall -> gall
2019-11-19 07:36:21 +03:00
^- (quip card:agent:gall _this)
eyre: better userspace libraries
2019-11-09 23:22:59 +03:00
=/ launcha
launch: add %remove launch-action
2020-03-26 00:53:12 +03:00
[%launch-action !>([%add %clock /clocktile '/~clock/js/tile.js'])]
eyre: better userspace libraries
2019-11-09 23:22:59 +03:00
:_ this
:~ [%pass / %arvo %e %connect [~ /'~clock'] %clock]
[%pass /clock %agent [our.bowl %launch] %poke launcha]
==
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
:: bootstrapping to get %goad started OTA
::
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)
=/ old !<(?(~ %1 %2 %3) old-state)
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
=^ cards this
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
?: ?=(%3 old)
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
`this
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
?: ?=(%2 old)
:: ensure launch is set up to listen to us correctly
::
=/ launcha
[%launch-action !>([%add %clock /clocktile '/~clock/js/tile.js'])]
:_ this
[%pass /clock %agent [our.bowl %launch] %poke launcha]~
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
:_ this :_ ~
[%pass /behn %arvo %b %wait +(now.bowl)]
::
[cards this]
::
eyre: better userspace libraries
2019-11-09 23:22:59 +03:00
++ on-poke
|= [=mark =vase]
gall: mall -> gall
2019-11-19 07:36:21 +03:00
^- (quip card:agent:gall _this)
get geolocation from weather app, revise clock appearance to match new launch page
2020-02-06 05:08:22 +03:00
|^
?: ?=(%json mark)
(poke-json !<(json vase))
mall, eyre: refactor server apps to be stateless
2019-11-13 11:38:35 +03:00
?. ?=(%handle-http-request mark)
eyre: better userspace libraries
2019-11-09 23:22:59 +03:00
(on-poke:def mark vase)
mall, eyre: refactor server apps to be stateless
2019-11-13 11:38:35 +03:00
=+ !<([eyre-id=@ta =inbound-request:eyre] vase)
eyre: better userspace libraries
2019-11-09 23:22:59 +03:00
:_ this
mall, eyre: refactor server apps to be stateless
2019-11-13 11:38:35 +03:00
%+ give-simple-payload:app eyre-id
eyre: better userspace libraries
2019-11-09 23:22:59 +03:00
%+ require-authorization:app inbound-request
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
|= =inbound-request:eyre
=/ request-line (parse-request-line url.request.inbound-request)
=/ back-path (flop site.request-line)
=/ name=@t
=/ back-path (flop site.request-line)
?~ back-path
''
i.back-path
::
?~ back-path
not-found:gen
?: =(name 'tile')
(js-response:gen tile-js)
not-found:gen
get geolocation from weather app, revise clock appearance to match new launch page
2020-02-06 05:08:22 +03:00
::
++ poke-json
|= jon=json
^- (quip card:agent:gall _this)
=. data.state jon
:_ this
[%give %fact ~[/clocktile] %json !>(jon)]~
--
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-watch
|= =path
gall: mall -> gall
2019-11-19 07:36:21 +03:00
^- (quip card:agent:gall _this)
mall, eyre: refactor server apps to be stateless
2019-11-13 11:38:35 +03:00
?: ?=([%http-response *] path)
`this
get geolocation from weather app, revise clock appearance to match new launch page
2020-02-06 05:08:22 +03:00
?. =(/clocktile path)
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-watch:def path)
get geolocation from weather app, revise clock appearance to match new launch page
2020-02-06 05:08:22 +03:00
[[%give %fact ~ %json !>(data.state)]~ this]
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
++ on-arvo
|= [=wire =sign-arvo]
gall: mall -> gall
2019-11-19 07:36:21 +03:00
^- (quip card:agent:gall _this)
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
?: ?=(%wake +<.sign-arvo)
?^ error.sign-arvo
:_ this :_ ~
[%pass /dill %arvo %d %flog %crud %clock-fail u.error.sign-arvo]
:_ this :_ ~
[%pass /gall %arvo %g %goad | `%hood]
::
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
?. ?=(%bound +<.sign-arvo)
(on-arvo:def wire sign-arvo)
[~ this]
::
++ on-fail on-fail:def
--
Reference in New Issue Copy Permalink