Joe Bryan

@pkova this was inadvertently closed by the deletion of `next/hoon/138` in #6615. I've restored the branch for now.

Per `+sane`, valid cords cannot contain null bytes. The same limitation applies to tapes -- arbitrary binary data should be represented as `octs` or something similar. At the same time,...

@Firfi you're behind on updates to `%base`, and the version of the `+vats` command you have doesn't accept additional arguments. Can you just run `+vats` and post the full update...

Your star (`~rolryx`) is behind on updates (as is your galaxy `~ryx`). I just checked with ``` > -read %z ~rolryx %kids da+now / 0v13.gb7b2.v1h24.upgv3.o743l.jjc2k.8ellh.8keur.4osot.1si86.rll9k > -read %z ~ryx %kids...

This is a worthy experiment -- I'm surprised at how small this diff is! @ohAitch is right, you'll want to keep a cursor into the input cord and `+cut` bytes...

In lieu of a better place to put and discuss "draft RFC with working code", I want to keep this kind of thing open.

@trinkerin we have a feature called "docking", on by default, where the binary is copied into the pier (the directory where your ship is being created). That copy is failing...

#6669 is just a workaround, basically ignoring the problem. We still need a long-term fix.

What does your unit test do? Does it just import the app core and call it directly?

in vere, the underlying HAMT is also capped, with CLOCK eviction.