Ferrilab Design, LLC
ContentsDoing Business
The Wisconsin entity Ferrilab Design, LLC serves as my professional agent for work on this software. It:
- owns the publicly-available software that I produce
- provides my professional service while producing this software
- receives any financial awards granted for this software
Or, more concisely, Ferrilab Design, LLC exists to separate my hobby work from my regular employment, and to keep both of them separate from my personal life. The Ferrilab project doesn’t make me any money (though if it helps you do so, please consider that I create and distribute it freely, and can only allocate effort for doing so as either I, or you, indicate a desire for me to do so), and this LLC is solely for organizational purposes.
I have full-time employment with which I am quite satisfied. I am able to perform compensated, independent, work outside that, but not to the detraction of my day job. If you are interested in working with me on that limited basis, you may write to ferrilab@myrrlyn.net
.
Public Works
The Ferrilab project is a collection of my work that has spun out of developing my primary project, bitvec
. At the moment it is composed of these crates:
funty
and radium
were extracted from bitvec
and are usable on their own.
Each of these crates are described in more detail on their own pages.
funty
Short for fundamental types, this crate provides traits that unify the language primitives (integers, floating-point numbers, bool
, char
, and pointers) so that code can be generic over them.
With the initial stabilization of Generic Associated Types in Rust 1.65, I was able to pull the trait-level pointer permission system I sketched in bitvec
out into funty
and create a Pointer<T: ?Sized, P: Permisison>
type that generically unifies *const T
and *mut T
and correctly adheres to Rust’s and Miri’s rules about permission tracking, and Pointer
even switches between storing a *const T
and *mut T
internally as appropriate, so that code analysis tools can understand what is going on without needing to understand the Permission
trait.
The standard library APIs for the primitives, especially pointers, continues to evolve. funty
tracks it as best I am able to do, and tries to in general remain about four releases behind current. This will not always be true, as I may decide to use major advances in the language.
radium
Originally sketched out by Nika Layzell, radium
provides trait unification over Atomic
and Cell<>
types. The Radium
trait can be taken as a generic bound to accept a type which may or may not be atomic, and the Item
associated type describes the primitive being managed.
Additionally, radium
provides the Atom<T>
, Isotope<T>
, and Radon<T>
type families. These take a primitive integer as their type parameter, and forward to the corresponding atomic, maybe-atomic, or Cell<>
, respectively.
The Isotope
type family uses platform support information to determine whether it forwards to an Atomic
or to a Cell
. You can use this to have a single unchanging name that changes behavior according to the target without needing to personally remember where your code can and can’t run.
bitvec
This is my most prominent work. It implements bit-precision addressing, allowing the creation of arbitrary bitfields, compact usize => bool
collections, and I/O protocol buffer manipulation.
It works by encoding an intra-byte bit index into part of a slice pointer, so that memory can be described by &/mut BitSlice
references rather than Bits<'a>
struct handles. The creation of custom reference types allows the crate to implement the vast majority of Rust’s APIs, as everywhere that requires an actual reference rather than just a borrowing view can still receive bitvec
types.