Skip to content

Instantly share code, notes, and snippets.

@conectado
conectado / README.md
Last active July 13, 2025 12:46
Method call resolution in Rust for type parameters

The way method resolution works in Rust is specified in this section of the reference.

For a given type T where a method is being called, it follows these steps:

  1. Start with a candidate list containing only T (candidates := [T])
  2. Try to dereference (*) the last element of the list(last)
  3. If *last is valid, add it to the list (candidates := candidates : [last]) and go to the previous step. Else continue.
  4. AAttempt unsized coercion, meaning vaguely, converting a sized type to its unsized variant (e.g. [T; N] to [T])
  5. For each element t on candidates add &t and &mut t
  6. For each t in candidates:

📱Valet

A Decentralized Automated Testing Network

🙈 tl;dr:

Valet is a decentralized test automation network where developers run tests on real devices (iOS or Android), and device owners get paid for executing them. Using Nostr for discovery, Lightning for payments, and Raspberry Pi nodes for execution, it’s less expensive, more open, and more scalable than traditional test clouds. Built by Jason Huggins (Selenium, Appium, Sauce Labs), Valet is an experiment in P2P testing at scale. 🚀

introduction

inspired by a friend’s fledgling language design and motivated by the JeanHeyd Meneide RustConf Fiasco™ and improving the story for compile-time introspection, i decided i needed a place to spew the last year’s musings on variadic generics in Rust in one mighty, less-than-understandable catharsis.

i think somewhere in here is a considered and reasonable design, so that’s neat!

perhaps i’ll make this an RFC one day. probably not. you have my express permission to do that yourself.

variadic generics?

this nugget of language jargon encapsulates the idea that we might want to bind to an arbitrarily large list of generic parameters, all at once. there are many reasons to want to do this:

@Tomcc
Tomcc / blockstate_protocol.md
Last active April 17, 2026 10:19
Block Changes in Beta 1.2.13

Block Storage & Network Protocol Changes

Paletted chunks & removing BlockIDs brings a few big changes to how blocks are represented. In Bedrock, Blocks used to be represented by their 8 bit ID and 4 bit data; this means that we can only represent 256 blocks and 16 variants for each block. As it happens we ran out of IDs in Update Aquatic, so we had to do something about it :)

After this change, we can represent infinite types of Blocks and infinite BlockStates, just like in Java. BlockStates are what is sent over the network as they are roughly equivalent to the old ID+data information, eg. they're all the information attached to a block.

BlockStates are serialized in two ways:

PersistentID: a PersistentID is a NBT tag containing the BlockState name and its variant number; for example