Curtis Yarvin
2016-07-01 17:09:51 UTC
Wise question, glasshoppa!
The answer: blocking .^ is a very non-fundamental behavior. It is
obviously not part of Nock proper (it turns into Nock instruction 11, which
is only implemented by the virtual extended Nock ++mock). It is not even
available to %gall apps, which can only do non-blocking .^. For the
programmer, the first layer blocking .^ works in is anything run by :dojo
(generators, command line, etc).
Internally, what you're doing with .^ from the dojo, and what you're doing
from a %gall app, are different. From a %gall app, .^ will just use the
Arvo kernel namespace function ++scry on your behalf. ++scry obviously has
no way to block. So in Unix terms, it's essentially producing EWOULDBLOCK.
From the dojo, .^ is actually invoking the build vane, %ford. The
superpowers of %ford are tremendous (and not well documented). You're
essentially saying: start this build and call me back when it's done. If
%ford does not actually have to block, it will give a result in the same
top-level Arvo step. But it's quite prepared to block.
(Moreover, the way we implement "blocking" is to... abort the computation
and rerun it when we have the result we need. With proper caching this is
surprisingly not-bad.)
If you want to do the same thing in :talk or another app, you need to
invoke %ford asynchronously the way :dojo does. Sorry, there is no such
thing as "real" app blocking. I can defend this: one of the things about
Urbit's super-event-centric I/O model is that your app state is always just
a noun, never some kind of saved execution context. The illusion of
blocking is pushed up to the highest possible level. The result of this is
that it makes sense to, for example, hotpatch a blocked :dojo. There is no
"please exit the program to continue upgrading" or whatever.
/e/~wolsyp-filtuc-havrut-londys--pinbel-ballut-fodmyl-litmer/host/real
â
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
<https://github.com/urbit/arvo/issues/191#issuecomment-229984009>, or mute
the thread
<https://github.com/notifications/unsubscribe/AALyAcJuuBVUgYMiGvAfoh1GdcrdLOrAks5qRTl2gaJpZM4JDQQ8>
.
The answer: blocking .^ is a very non-fundamental behavior. It is
obviously not part of Nock proper (it turns into Nock instruction 11, which
is only implemented by the virtual extended Nock ++mock). It is not even
available to %gall apps, which can only do non-blocking .^. For the
programmer, the first layer blocking .^ works in is anything run by :dojo
(generators, command line, etc).
Internally, what you're doing with .^ from the dojo, and what you're doing
from a %gall app, are different. From a %gall app, .^ will just use the
Arvo kernel namespace function ++scry on your behalf. ++scry obviously has
no way to block. So in Unix terms, it's essentially producing EWOULDBLOCK.
From the dojo, .^ is actually invoking the build vane, %ford. The
superpowers of %ford are tremendous (and not well documented). You're
essentially saying: start this build and call me back when it's done. If
%ford does not actually have to block, it will give a result in the same
top-level Arvo step. But it's quite prepared to block.
(Moreover, the way we implement "blocking" is to... abort the computation
and rerun it when we have the result we need. With proper caching this is
surprisingly not-bad.)
If you want to do the same thing in :talk or another app, you need to
invoke %ford asynchronously the way :dojo does. Sorry, there is no such
thing as "real" app blocking. I can defend this: one of the things about
Urbit's super-event-centric I/O model is that your app state is always just
a noun, never some kind of saved execution context. The illusion of
blocking is pushed up to the highest possible level. The result of this is
that it makes sense to, for example, hotpatch a blocked :dojo. There is no
"please exit the program to continue upgrading" or whatever.
.^(hart %e /(scot %p our)/host/real)
[p=%.y q=~ r=[%.y p=<|org urbit wolsyp-filtuc-havrut-londys--pinbel-ballut-fodmyl-litmer|>]]/e/~wolsyp-filtuc-havrut-londys--pinbel-ballut-fodmyl-litmer/host/real
â
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
<https://github.com/urbit/arvo/issues/191#issuecomment-229984009>, or mute
the thread
<https://github.com/notifications/unsubscribe/AALyAcJuuBVUgYMiGvAfoh1GdcrdLOrAks5qRTl2gaJpZM4JDQQ8>
.
--
You received this message because you are subscribed to the Google Groups "urbit" group.
To unsubscribe from this group and stop receiving emails from it, send an email to urbit-dev+***@googlegroups.com.
To post to this group, send email to urbit-***@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
You received this message because you are subscribed to the Google Groups "urbit" group.
To unsubscribe from this group and stop receiving emails from it, send an email to urbit-dev+***@googlegroups.com.
To post to this group, send email to urbit-***@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.