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

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?