ArrayFire is a mature, production-grade tensor and array computing library implemented in C++, exposing both a C API (af_* functions) and a C++ API (af::array). It provides hundreds of accelerated numerical operations — dense and sparse linear algebra (LU, QR, SVD, Cholesky, solve), FFT and signal processing, image transforms and filtering, computer vision feature detection (FAST, SIFT, ORB, SUSAN, homography), statistics, and random number generation — across four hardware backends: CPU, CUDA, OpenCL, and oneAPI/SYCL. The architecture is layered: thin C API wrappers and C++ classes in src/api/c and src/api/cpp dispatch through a unified runtime layer (src/api/unified) that lazily loads backend shared libraries via a symbol manager; each backend implements the same templated operation set over device-resident arrays with backend-specific kernels under src/backend/*/kernel. The genuinely interesting engineering lives in src/backend/common: a JIT expression-tree system that fuses array operations into compiled kernels, deterministic hash-based kernel caching, a memory manager with JIT-pressure eviction heuristics, FFT plan caching, and cross-platform dynamic library loading. The test suite is unusually rigorous for a numerical library — well over 100 gtest programs covering correctness across all dtypes, large dimensions, random-number quality via PractRand, and death tests — while examples span image processing, machine learning, financial Monte Carlo, and PDE simulation. Maintenance is active (commits through 2026, CI workflows, source releases), but technical drift is medium: the oneAPI backend is explicitly incomplete with many operations stubbed as ONEAPI_NOT_SUPPORTED, deprecated compatibility APIs remain (include/af/compatible.h), the four backends duplicate a large amount of near-identical code, and some packaging artifacts (Tegra toolchain pinned to gcc-5, vendored vcpkg LAPACK patches, Debian postinst hardcoding MKL/CUDA paths) are stale. This is a software library rather than a data pipeline — there are no notebooks, datasets, or analytical artifacts — though its algorithms are directly applicable to computer vision and scientific computing workloads.
Astroterm is a terminal-based star map application written in C. It renders the real-time positions of stars, planets, the Moon, and constellation figures using ASCII or Unicode characters. The system computes celestial positions from the Yale Bright Star Catalog, Keplerian orbital elements, and user-specified date/time and location (latitude/longitude or city name). It projects the visible sky onto the terminal via a stereographic projection and uses ncurses for display and input. The build system is Meson with Ninja, supporting Linux, macOS, and Windows. The codebase is well-structured into separate modules for astronomy calculations (astro.c), coordinate transforms (coord.c), terminal rendering (drawing.c, term.c), and data parsing (parse_BSC5.c, city.c). It includes comprehensive unit tests using Unity and CI via GitHub Actions. The application is highly configurable through command-line arguments and demonstrates strong craftsmanship in astronomical computations and terminal graphics.
cgltf is a single-file, stb-style C library for parsing and writing glTF 2.0 files. It provides a comprehensive set of data structures mirroring the glTF spec, along with functions to parse JSON/GLB, load buffers, validate data, and write back glTF/GLB. The library is self-contained, requires no external dependencies, and includes an embedded copy of the JSMN JSON parser. It supports core glTF 2.0 and many extensions (KHR_materials_*, KHR_lights_punctual, EXT_mesh_gpu_instancing, etc.). The code is well-structured, uses C99, and is designed for easy integration into any C or C++ project. It is used by major projects like bgfx, Filament, and raylib. The writer component (cgltf_write.h) is separate but similarly crafted. The repository includes a comprehensive test suite and fuzz testing setup.
This repository contains raygui, an immediate-mode GUI library for the raylib game programming library. It is written entirely in C as a single header file (src/raygui.h). The library provides over 25 controls (buttons, sliders, text boxes, list views, color pickers, etc.) designed specifically for building development tools, debug overlays, and editors. The architecture follows an immediate-mode pattern where controls are drawn and return their state every frame, with no retained state managed by the library, making it highly predictable and easy to integrate into existing game loops. A powerful styling system allows complete customization of colors, fonts, and metrics, with over 20 pre-built themes provided in the styles/ directory. The library also includes a built-in icon system with 256+ 16x16 icons. While tightly coupled to raylib by default, a standalone mode (RAYGUI_STANDALONE) allows it to be adapted to any graphics library by implementing a small set of backend functions. The examples directory contains several high-quality, reusable custom widgets (curve editor, property list, file dialog) that demonstrate how to extend the library. The codebase is mature, well-documented, and actively maintained, representing a high standard of C library craftsmanship within its domain.
DeePMD-kit is a comprehensive, production-grade deep learning package for many-body interatomic potential energy representation and molecular dynamics simulation. It provides a unified framework for training and deploying machine learning interatomic potentials (MLIPs) across multiple backends: TensorFlow, PyTorch, JAX, and PaddlePaddle, with a backend-agnostic core (dpmodel) that ensures numerical consistency. The package supports a wide range of descriptor architectures (SeA, SeR, SeT, DPA1/2/3/4, attention-based, hybrid) and fitting targets (energy, force, virial, dipole, polarizability, density of states, spin, property). It integrates tightly with LAMMPS via custom pair styles and plugins, and also supports ASE, i-PI, GROMACS, and other MD engines. The codebase is highly modular, with a plugin registration system for models, descriptors, and losses, and offers extensive serialization capabilities for model export and compression. Pretrained models (DPA-3, DPA-4) are available for direct download and fine-tuning. The project is actively maintained with a large community, comprehensive test suites, and continuous integration across CPU and GPU platforms.
librdkafka is a high-performance, production-grade C (and C++) client library for Apache Kafka, developed and maintained by Confluent. It provides full protocol-level support for producing and consuming messages, including advanced features such as exactly-once semantics (idempotent producer, transactions), consumer groups with multiple rebalance protocols (classic and KIP-848), share consumers (KIP-932), and a comprehensive Admin API for cluster management (topics, configs, ACLs, SCRAM credentials). The library is designed for embedding into applications across many languages via bindings (Python, Go, .NET, Rust, etc.) and supports a wide range of authentication mechanisms (SSL, SASL/PLAIN, SCRAM, OAUTHBEARER, GSSAPI) and compression codecs (zstd, LZ4, snappy, gzip). It includes a robust mock cluster for integration testing, a highly configurable configuration system, and extensive unit and integration tests covering hundreds of scenarios. The architecture separates protocol handling, broker transport, partition assignment, and admin operations into modular internal components, while exposing a clean, callback-driven C API and an object-oriented C++ wrapper. The codebase is actively maintained with frequent releases addressing security fixes (CVE tracking), Kafka protocol evolution (e.g., KIP-848, KIP-932), and platform compatibility (Linux, macOS, Windows, s390x). Vendored dependencies like lz4, snappy, cJSON, and nanopb are periodically updated, but some platform-specific #ifdefs and legacy protocol support contribute to moderate technical drift.
pret/pokeruby is a reverse-engineering project that reconstructs the complete source code of Pokémon Ruby and Sapphire (Game Boy Advance) in C and ARM assembly. The build system compiles the entire game into byte-identical .gba ROMs, verified by pinned SHA1 checksums across a matrix of variants: Ruby/Sapphire, revisions 0/1/2, German localization, debug builds, and a modern-toolchain mode. The repository is the actual working source of the game engine, not documentation: it contains the battle system (turn logic, AI, animations via sprite templates and affine transforms), overworld/field state machines (weather, poison, cut, evolving, day care), Pokémon storage and save/load serialization, contest/link multiplayer subsystems, and the m4a sound driver, all written directly against GBA hardware registers and ARM7TDMI constraints. The architecture is a monolithic single-binary ROM rather than a service or library. Entry points are AgbMain() and the CB2_* main-loop callback system; game systems are orchestrated by a 16-slot task scheduler and a sprite/OAM manager. The build is driven by a sophisticated Makefile that feeds custom C++ asset pipelines — gbagfx (PNG↔GBA tile conversion, Huffman compression), preproc (charmap string embedding, INCBIN expansion), scaninc (include/incbin dependency resolution), mid2agb and wav2agb (MIDI/WAV to m4a data), mapjson/jsonproc (map JSON to assembly) — which generate C arrays and assembly that the hand-written sources consume. Data flows are: raw asset → tool → generated C/asm table → compile/link → .gba ROM → SHA1 comparison against the retail cartridge dump. Because this is a decompilation, the code carries inherent artifacts: sub_* function names, NONMATCHING stubs with NAKED asm fallbacks, unused/unreferenced data, and known UB comments. However, the project is professionally maintained with CI, organized headers, careful localization branching, and a clean separation between game code and build tooling. The tools/ directory is the most reusable asset — each utility is standalone and portable to any GBA homebrew or decomp effort — followed by small hardware-abstraction layers like include/gba/macro.h and src/trig.c.
Generic Mapping Tools (GMT) is a mature, open-source collection of approximately 100 command-line tools for processing geographic and Cartesian data and producing high-quality PostScript illustrations, maps, and animations. The system is architected as a modular C library with a central dispatcher executable (`gmt`) that loads and runs individual modules. It supports both a classic mode (direct module calls) and a modern mode (`gmt begin/end`, `gmt subplot`) that manages sessions, figures, and panels. Key entry points include the `gmt` command, the C API (`GMT_Create_Session`, `GMT_Call_Module`), and shell completion scripts. Data flows involve reading grid, table, image, and color palette table (CPT) data from local files or remote servers (via `@` prefix), processing through modules (e.g., `grdimage`, `psxy`, `grdmath`, `grdfilter`), and outputting PostScript, grids, or other formats. External dependencies include netCDF, GDAL, FFTW, PCRE/POSIX regex, PROJ, GSHHG coastlines, and DCW country polygons. The codebase exhibits high craftsmanship with systematic option parsing, a well-defined API, extensive test coverage, and reusable infrastructure components.
This is the official NATS C client library (nats.c), a production-grade C library providing full support for the NATS messaging system. It implements core publish/subscribe, request-reply, queue groups, and advanced features including JetStream (streams, consumers, key-value store, object store), a microservices framework, and legacy NATS Streaming support. The library is designed for high performance and reliability, with built-in reconnection, TLS/SSL, authentication (NKeys, JWT), and event loop integration (libevent, libuv). It exposes a comprehensive C API with hundreds of functions, and includes extensive examples and documentation. The codebase is well-structured with platform abstractions for Unix and Windows, and internal modules for protocol parsing, connection management, threading, and memory management. While the library is actively maintained and widely used, it carries some technical debt from legacy Streaming support and a large, tightly-coupled internal architecture.
Corrfunc is a high-performance scientific computing library for cosmology, specifically for computing two-point correlation functions and the void probability function from galaxy catalogs. It provides both a C library/command-line interface and Python bindings through C extensions. The code implements pair counting for real-space (DD, xi, wp), redshift-space (DDrppi, DDsmu), angular (DDtheta), and mock/survey geometries, with support for periodic simulation boxes and line-of-sight survey data. The architecture is a hybrid C core with Python wrappers: OpenMP parallelized C kernels, runtime dispatch across SSE4.2/AVX/AVX2/AVX512 intrinsics, grid-based cell decomposition, and a custom fast-food binary format for fast I/O. The project also includes a substantial test suite with reference outputs, CI workflows, and benchmark scripts used in a peer-reviewed performance paper. Despite being packaged as an application/library, the repository contains research artifacts: benchmark .npz files, paper scripts, and astrophysical mock-catalog test data. These are support materials for validating and advertising performance, not the primary deliverable. The dominant character is clearly a reusable scientific library, not a data-analysis pipeline. The codebase is mature and well-engineered for its niche, but shows some drift: Python 2 compatibility remnants, a complex dual Makefile/setup.py build, heavy code duplication between theory and mock modules, and platform-specific SIMD code that requires careful maintenance. It remains actively maintained and is the de facto standard CPU tool for fast correlation functions in cosmology.
Radare2 is a modular reverse engineering framework written in C. It provides a comprehensive set of libraries and command-line tools for binary analysis, disassembly, debugging, emulation, and file format parsing. The architecture is plugin-based: every major subsystem (architectures, binary formats, I/O backends, debuggers, filesystems, crypto, scripting languages) is implemented as a plugin registered via a common RLibStruct pattern. The core library (libr/) contains reusable data structures (RBTrees, RBuffer, RStrBuf, RList, etc.), utilities (base64, ASN.1, regex, event system, thread wrappers), and analysis engines (ESIL emulator, search algorithms, type propagation). The framework supports dozens of CPU architectures (x86, ARM, MIPS, RISC-V, etc.) and binary formats (ELF, PE, Mach-O, DEX, etc.), and can be extended via language bindings (JavaScript, Python, Rust, etc.) and a package manager (r2pm). Despite its large codebase and some legacy components, the project is actively maintained with continuous integration, fuzz testing, and a responsive issue tracker.
Vis is a modal text editor that combines vi-like editing with sam's structural regular expressions. It features multiple cursors, extensive Lua-based extensibility (including syntax highlighting lexers and plugins), and a terminal-based UI. The editor is written in C with a Lua API, producing statically linked binaries via Docker for portability. Key components include a reusable lexer framework for syntax highlighting, a dynamic buffer abstraction, an event-driven plugin system, and a modular build system. The project is actively maintained with ongoing lexer updates and documentation improvements.
JavaCPP is a mature, annotation-driven library that provides efficient Java-to-C++ interoperability via JNI. It is not an application but a core infrastructure library used by hundreds of downstream projects (e.g., OpenCV, FFmpeg, TensorFlow bindings) to bridge Java and native C++ code. The system consists of a code generation pipeline (Parser, Generator, Builder) that reads Java annotations and C++ headers to produce JNI wrapper classes, a runtime layer (Loader, Pointer hierarchy) that manages native memory and library loading, and a multidimensional data access layer (Indexer package) optimized for scientific computing. The architecture is modular: build-time code generation (Maven plugin and CLI), runtime library loading with caching and platform detection, and a uniform pointer API with automatic deallocation via PhantomReferences. Key entry points are the Builder class (for build-time code generation) and the Loader class (for runtime library loading). The codebase is largely well-crafted, with reusable patterns like the Indexer factory pattern, PointerScope for deterministic resource management, and annotation-driven configuration. Some core components (Generator, Parser) are acknowledged as complex and messy, reflecting organic growth to handle real-world C++ headers. The repository maintains an extensive test suite and supports a wide range of platforms (Linux, macOS, Windows, Android, iOS, FreeBSD, embedded architectures).
Trice is an embedded logging and tracing toolchain consisting of a lightweight C instrumentation library for microcontrollers and a Go-based host CLI tool. The C library provides variadic macros that emit compact binary records (ID + values) instead of format strings, drastically reducing flash and bandwidth usage. The Go tool manages Trice IDs (insert, clean, bind), decodes incoming binary streams from targets over UART, RTT, TCP/UDP, or file, and displays formatted logs with timestamps, colors, and filtering. It supports multiple buffer strategies (stack, static, double, ring), framing protocols (COBS, TCOBS), optional XTEA encryption, and local logging on the target itself. The architecture is a classic host-target split: the target runs the C library, the host runs the Go CLI. The codebase is well-tested with a large matrix of CGO test configurations and CI pipelines for multiple STM32 example projects. It is actively maintained with frequent releases and a responsive issue tracker.
ESBMC (Efficient SMT-based Bounded Model Checker) is a mature, open-source formal verification tool that automatically detects or proves the absence of runtime errors in C, C++, Python, Java/Kotlin (via Jimple), CHERI, and Solidity programs. It parses source code using language-specific frontends (Clang for C/C++, CPython parser for Python, Soot for Java), converts programs into a common GOTO intermediate representation, and performs bounded symbolic execution with SMT solving (Z3, Bitwuzla, CVC5, Yices, etc.). The tool checks for assertions, memory safety (buffer overflows, null pointers, use-after-free), arithmetic overflows, concurrency races, and user-defined contracts (requires/ensures/assigns). It supports advanced verification techniques including k-induction, loop invariant synthesis, incremental BMC, and quantifier reasoning. The architecture is modular: frontends produce GOTO programs, which are then processed by a series of analysis passes (pointer analysis, value-set analysis, loop unrolling, contract enforcement) before being encoded into SMT formulas. The solver backend is pluggable, with support for interactive solvers and experimental one-shot solvers (Mallob, NeuroSym). The repository includes an extensive regression test suite with thousands of small, self-contained test cases organized by language and feature, many with paired passing/failing variants to ensure soundness. Operational models for C standard library functions, C++ STL, Python standard library (including numpy), and SystemC are bundled as source code for SMT translation. Key entry points include the main ESBMC binary (built from `src/esbmc/`), the Clang C/C++ frontend (`src/clang-c-frontend/`), the Python frontend (`src/python-frontend/`), and the solver interfaces (`src/solvers/`). The tool is actively used in research and industry, has won 43 awards at SV-COMP and Test-Comp, and is supported by multiple funding agencies. External dependencies include Boost (program_options, filesystem), Clang/LLVM, and several SMT solvers.
This repository is Xilinx's fork of QEMU, a full-system and user-mode emulator/virtualizer. It provides machine emulation via dynamic binary translation (TCG) and hardware acceleration through KVM, Xen, HVF, and other accelerators. The codebase includes a vast array of device models (CPUs, interrupt controllers, storage, network, graphics, timers, etc.), a block layer for storage backends, live migration for VM state transfer, and QMP/HMP monitoring interfaces. The architecture is highly modular with the QEMU Object Model (QOM), coroutine-based async I/O, and a plugin API. It also supports user-mode emulation for Linux and BSD syscalls. This is purely an application repo; there is no data science or research code. The Xilinx fork adds extensive device models for Xilinx FPGAs and SoCs (Versal, ZynqMP, etc.), making it especially relevant for embedded developers. The code is actively maintained with recent commits and issue triage, and while the sheer size introduces some technical debt, the overall engineering quality is high.
bspwm is a tiling window manager for X11 that represents windows as leaves of a full binary tree. It uses a client-server architecture: the `bspwm` daemon manages windows and desktops, while the `bspc` command-line client communicates with it over a Unix domain socket. The daemon does not handle input directly; instead, an external helper like `sxhkd` invokes `bspc` to perform actions. Configuration is done via shell scripts (`bspwmrc`) that call `bspc` commands, and the state can be dumped to JSON for restoration. The project is written in C99 with XCB (X11 C Bindings) and supports EWMH/ICCCM standards, multi-monitor setups (RandR/Xinerama), a rule system for window matching, and event subscriptions for external tools like panels.
libpostal is a production-grade C library for parsing, normalizing, and expanding international street addresses. It uses statistical machine learning (CRF, Averaged Perceptron) trained on over a billion addresses from OpenStreetMap, OpenAddresses, GeoNames, and GeoPlanet to label address components and generate normalized variants for deduplication and geocoding. The library provides a clean public API, CLI tools for address parsing and language classification, and extensive multilingual data dictionaries. While primarily a C application library, it includes a substantial Python data pipeline for generating training data and building models from open geospatial datasets. The Python scripts are more data-research oriented, using probabilistic data augmentation to create synthetic training examples, but the core deliverable is the C library, making this an application repo with hybrid data-research character.
jgmenu is a lightweight, standalone X11 menu application written in C, designed for scripting, modding, and tweaking. It renders menus using Cairo and Pango, reading menu data from CSV files or piped commands. The architecture is modular: a core menu engine (src/jgmenu.c) handles event loops, drawing, and item management, while separate generators (jgmenu-apps, jgmenu-ob, jgmenu-lx, jgmenu-pmenu) produce CSV data from .desktop files, Openbox XML, or XDG menus. Configuration is via a jgmenurc file with 80+ options, and IPC via Unix sockets enables integration with tint2 and XFCE panels. The codebase demonstrates strong C engineering practices: banned unsafe functions, custom safe string buffers (sbuf), a generic linked list (list.h), a hashmap, and a CSV parser with triple-quote support. It includes a comprehensive test suite using a sharness-like framework and CI via GitHub Actions. While tightly coupled to X11, the utility modules are cleanly isolated and reusable in other C projects.
Netis Cloud Probe is a production-grade network packet capture and forwarding system designed to monitor traffic without requiring dedicated TAP or SPAN hardware. It consists of a high-performance C capture engine (cpworker), a Go daemon (cpdaemon) that manages worker processes and communicates with a central policy manager (CPM), and a Go CLI (cpctl) for manual control. The system supports multiple capture sources (libpcap, DPDK, pcap files) and output sinks (GRE, VXLAN, ZMQ, rotating files) with a configurable execution model (real-time or pipelined using a lock-free SPSC ring buffer). Configuration reload is handled via a state-machine protocol, enabling hot-swapping of tasks without packet loss. The codebase is multi-language (C, Go) with CMake and Mage build systems, comprehensive unit and integration tests, and bilingual documentation (English, Chinese). It is actively maintained with a recent commit and continuous integration.