Here we describe what each of the primary folders present in the
are used for. This organization is merely a convention, and the exact location
of any file does not affect its operation. That being said, some Ford
runes are designed with this structure in mind, and
applications such as dojo look in specific folders for code to run. Furthermore,
this organization is not perfectly adhered to - sometimes you may find structure
/lib, for example.
/appcontains userspace applications, i.e. Gall agents.
/gencontains generators. Many applications make use of generators, but also each generator in this folder may be run from dojo using
+. For example,
/gen/foo/hoonis run with
/libcontains libraries that may be shared by multiple agents, threads, generators, etc. However, this is not the location of the standard libraries (see
/sys). Libraries are imported from
/marcontains mark definitions.
/surcontains shared structure definitions. Whenever you expect structures to be used by code across multiple files, it is recommended to place their shared structures in
/sur. Structures are imported from
/syscontains the code that defines the kernel and standard libraries.
/sys/vanecontains the code for the vanes, aka kernel modules.
/sysis the exception to the rule - structures and functions that are central to Hoon, Arvo, and its vanes, are all located within this folder rather than in
/sur. See below for more information on
/tedcontains threads. These may be run from dojo using
-. For example,
/ted/foo/hoonis run with
/testscontains unit tests intended to be run using the
testthread. To run a particular test
/tests/foo.hoonin dojo, enter
-test %/tests/foo/test-bar ~. If a file is specified, every test in that file will run. If a folder is specified, every test in that folder will run.
/sys contains four files:
zuse.hoon. These are the files used to construct kernelspace. The chain of
give a brief description of each of them.
hoon.hooncontains the Hoon compiler and the Hoon standard library. The Hoon compiler is self-hosted. This is the first file loaded by the Nock virtual machine, Vere, in order for it to learn how to interpret Hoon. The kelvin version number is the subject of
hoon.hoon, currently at 140. One may see this from dojo by inspecting the subject with
.and noting that
%140is the final entry of the subject.
arvo.hooncontains the Arvo kernel and additional structures and functions directly relevant to the kernel. This is Urbit's "traffic cop", and as such contains the structure definitions for call stacks such as
bones. Once Vere understands Hoon, it loads and interprets
arvo.hoonto create the kernel.
hoon.hoonis the subject of
lull.hoonprimarily contains structures shared among the kernel and its vanes, as well as a few functions. In particular, this includes the definitions of the
cards utilized by each vane, each of which are documented in their respective documentation.
lull.hoonis loaded by the kernel during the larval stage in order to prepare to create the vanes.
arvo.hoonis the subject of
zuse.hoonis the Arvo standard library. It consists primarily of functions shared by the kernel and vanes, such as the ones related to cryptography.
zuse.hoonis loaded by the larval kernel following
lull.hoonis the subject of
zuseis the subject of the vanes.