gonative is going away
it's a system to connect gno and go code together, used for packages like fmt, but it has some problems and is not inspectable using static analysis
morgan
making tests run faster
#3119 improves the state of GnoVM tests, by greatly improving their performance with some smart caching
writing an amino code-generator, #2: it talks!
it talks, it walks, and it shreds the benchmarks, being up to 25 times faster than its amino (reflect) counterpart.
test smart: coverage is a measure, not a target
code coverage stats are pointless if the underlying tests make no attempt at being intelligent. the point is preventing bugs and creating maintainability, not adding inconvenience.
gno will have to make floating points deterministic
floating point arithmetic sometimes yields slightly different results on different hardware. this will be a problem we'll have to solve in gno.land to avoid chain forks.
writing an amino code-generator, #1: introduction
tomino is a new small side-project of mine. it has two objectives: creating encoders/decoders in other languages; and making faster, code-generated un/marshalers for go.
amino's "unrecognized concrete types"
one of the most common amino gotchas, which can often leave us puzzled as we try to figure why it can't parse even the simplest piece of encoded data.
what is test1?
it's not a testnet; not anymore, at least. instead, it's the name of a well-known address and associated mnemonic, often used when testing.
why should you use an avl tree instead of a map?
on the first day of gno development, you're taught "use avl trees, not maps". but how is a more complex implementation better than a native map type?
the beginning
so begins the diary of a gnome. there's not much to write here yet; but i thought it would be nice to kick-off this blog with a small introduction, to say why i decided to set up this blog, and what my intentions are with it.