urbit/pkg/arvo
Philip Monk 4e466214e3
arvo: compile hoon/arvo in separate roads
Adds +mure to run a trap in a separate road.  This should eventually be
just a hint.

Vega was running inside a mule, but since +load was called within vega,
the new kernel was all run within the same mule, so it didn't actually
get to reclaim the space after hoon compiled.

We verified this with printfs in u3m_fall.  On the test ship (from
mainnet) which had 800MB used, vega was taking interior free space from
950MB to 450 over the course of compiling hoon, then each vane would go
from about 450 to 350 and then back to 450 once it finished (which
proves they were correctly isolated).  With this change, after hoon
compiles the free space goes back up to 950MB.  This gives us a lot more
space to compile OTAs.

We had to slightly refactor the logic for doubly-recompiling hoon, since
+mure as written produces a ?(!! _trap), and you can't find faces in the
result of the trap.  We could bake mure, but that's rather awkward.  I
wonder if there's a way to fix this as a wet gate.
2020-06-12 20:51:23 -07:00
..
app hood: update on-save 2020-05-27 19:35:22 -07:00
gen gen: add |ames-wake 2020-05-28 10:50:32 -07:00
lib ames: add |ames-wake 2020-05-28 10:28:31 -07:00
mar Merge branch 'release/next-sys' into m/debug-dashboard 2020-05-26 20:36:27 +02:00
ren various: remove trailing whitespace 2020-01-03 22:06:42 +01:00
sur Merge branch 'release/next-sys' into m/debug-dashboard 2020-05-26 20:36:27 +02:00
sys arvo: compile hoon/arvo in separate roads 2020-06-12 20:51:23 -07:00
ted migrate-channels: addressed review 2020-05-20 14:24:24 -06:00
tests Merge branch 'yosoyubik/apt-dup' (#2417) 2020-04-13 17:43:41 +04:00
.gitattributes gitattributes: export-ignore additions [ci skip] 2020-02-01 17:40:27 +04:00
.ignore Write top-level pier code; hook up Ames and Behn. 2019-07-31 19:34:14 -07:00
LICENSE.txt Pull in latest v0.8.0.rc changes 2019-07-16 15:59:39 -07:00
README.md master without pills, hopefully 2019-10-14 16:02:27 -04:00
TESTING.udon Pull in latest v0.8.0.rc changes 2019-07-16 15:59:39 -07:00

Arvo

A clean-slate operating system.

Usage

To run Arvo, you'll need Urbit. To install Urbit and run Arvo please follow the instructions in the getting started docs. You'll be on the live network in a few minutes.

If you're doing development on Arvo, keep reading.

Documentation

Find Arvo's documentation on urbit.org.

Development

To boot a fake ship from your development files, run urbit with the following arguments:

urbit -F zod -A /path/to/arvo -c fakezod

Mount Arvo's filesystem allows you to update its contents through Unix. To do so, run |mount in dojo. It is most common to |mount /=home=.

To create a custom pill (bootstrapping object) from the files loaded into the home desk, run .my/pill +solid. Your pill will appear in /path/to/fakezod/.urb/put/my.pill.

To boot a fake ship with a custom pill, use the -B flag:

urbit -F zod -A /path/to/arvo -B /path/to.pill -c fakezod

To run all tests in /tests, run +test in dojo. +test /some/path would only run all tests in /tests/some/path.

Maintainers

Most parts of Arvo have dedicated maintainers.

  • /sys/hoon: @pilfer-pandex (~pilfer-pandex)
  • /sys/zuse: @pilfer-pandex (~pilfer-pandex)
  • /sys/arvo: @jtobin (~nidsut-tomdun)
  • /sys/vane/ames: @belisarius222 (~rovnys-ricfer) & @joemfb (~master-morzod)
  • /sys/vane/behn: @belisarius222 (~rovnys-ricfer)
  • /sys/vane/clay: @philipcmonk (~wicdev-wisryt)
  • /sys/vane/dill: @bernardodelaplaz (~rigdyn-sondur)
  • /sys/vane/eyre: @eglaysher (~littel-ponnys)
  • /sys/vane/ford: @belisarius222 (~rovnys-ricfer) & @eglaysher (~littel-ponnys)
  • /sys/vane/gall: @jtobin (~nidsut-tomdun)
  • /sys/vane/jael: @fang- (~palfun-foslup) & @joemfb (~master-morzod)
  • /app/acme: @joemfb (~master-morzod)
  • /app/dns: @joemfb (~master-morzod)
  • /app/hall: @fang- (~palfun-foslup)
  • /app/talk: @fang- (~palfun-foslup)
  • /app/aqua: @philipcmonk (~wicdev-wisryt)
  • /lib/test: @eglaysher (~littel-ponnys)

Contributing

Contributions of any form are more than welcome! Please take a look at our contributing guidelines for details on our git practices, coding styles, how we manage issues, and so on.

You might also be interested in: