0af86743c6
This commit combines 12 separate commits: serialize signatures This took a surprising number of goose chases to work out... I had to find out - what is the gmser prefix for a signature (sg_) - what is the gmb wrapper for a signature (none) - what errors gmser can report when a signature is invalid - what an example of a valid signature is - what that example signature serializes to coerce stringy booleans coerce bytes coerce bits The thing to remember about bits is that they are actually integers... It is tempting to present bits as binaries, but that hides the nuance of the infinite leading zeroes, the potential for infinite leading ones, etc. coerce character It's really just an integer... Should we flatten it to an integer instead? I don't know. Also coerce unicode strings to FATE This is mainly so that gajudesk can pass text box content to hz as-is, but also allows users to pass utf8 binaries in, if they want to, for some reason. Coerce binaries as-is Sophia accepts both sg_... and #... as signatures, so we should probably accept binaries as signatures directly. People might expect to be able to put the listy string "#..." in too, but that is more complex to do. coerce hashes It turns out there are a lot of types that, like option, should only be valid as an opaque/normalized type, but should be substituted for something different in the flat representation. If we restructure things a little then we can implement all of these in one go. Refactor type normalization Some of these checks were redundant, and we probably don't actually need substitution to wrap success/failure, since it isn't expected to fail anyway... Now the logic is much simpler, and adding more built-in type definitions should be easy. Add a map for builtin types This makes it much easier to implement all these standard library things. In doing so I changed the convention for option, hash, unit, to be stringy rather than atoms. Also I changed some error messages based on what was more helpful during debugging of the unit tests. Add more builtin types We probably should extract these from the standard library instead of cherry picking the ones that are needed by the chain? e.g. Chain.tx still doesn't work. remaining types `tx` isn't defined in all the same places that pointee, name, base_tx, fr, fp are defined, but actually it is the only one not in the list I was looking at, so we are all good. As demonstration, there is also a test case for Set.set, despite Set.set not being defined as a builtin type.