osekit

The layer between libose and a host: name lookup, extended types, and runtime module loading.

libose deliberately knows nothing about how names are resolved or how a host extends it. osekit supplies the parts a real program needs and libose leaves open.

What it adds

• osekit_lookup — resolving a name to something callable, backed by a radix tree (thirdparty/rax) so lookup does not walk the environment linearly. Includes the near-miss handler that answers an unbound name with “did you mean …?”
• osekit_types — the extended OSC types beyond the four required ones: doubles, timetags, symbols, 8/16/64-bit ints, and the unit types.
• osekit_load — dlopen-based module loading, so a host can pick up .so modules at runtime. Hosts without dlopen — the browser, a microcontroller — link their modules statically instead and leave this out.

Building

make                    # -> build/default/libosekit.a
make BUILD_ID=myhost    # -> build/myhost/libosekit.a, linking the matching libose
make check-build        # answered by libose, where the dependency machinery lives

BUILD_ID is passed down to libose so that the archive this links is the one built with these flags. See source/libose/README.md for why that matters.

Testing

make -C test check

Where this sits

libose      the VM and OSC              (allocates nothing, knows no host)
osekit      lookup, types, dlopen       <- you are here
o.se.stdlib the C stdlib, bound in
o.se.osen   osen, the language

Hosts sit above all four: the command line (o.se), Max (max.o.se), the browser (web.o.se), the microcontroller (MicrOSCript, becoming mcu.o.se), and Python (osepy).