Gloo is a modular Rust toolkit that provides ergonomic, safe wrappers around browser APIs (console, events, file, history, net, storage, timers, workers, etc.) for WebAssembly applications. The codebase is organized into independent crates (e.g., gloo-console, gloo-net, gloo-worker) that can be used individually or via the umbrella `gloo` crate. The architecture follows a layered design: each crate wraps low-level web-sys bindings into idiomatic Rust APIs, often with both callback-based and futures-based interfaces. Notable patterns include RAII-based resource management (ObjectUrl, Timer, EventListener), generic codec abstraction for worker message serialization, and stream/sink implementations for WebSocket and EventSource. The code is well-tested with headless browser tests and demonstrates strong asynchronous Rust practices. Examples show integration with Yew and Trunk build system.
mkosi is a command-line tool for building customized, bootable OS images. It wraps distribution package managers (dnf, apt, pacman, zypper, apk) and deeply integrates with systemd components (systemd-nspawn, systemd-repart, systemd-boot, systemd-vmspawn, ukify) to produce disk images, containers, unified kernel images, initrds, and extension images. The tool supports multiple output formats (disk, tar, cpio, uki, esp, sysext, confext, portable, oci, directory, addon) and can generate images for a wide range of Linux distributions including Fedora, Debian, Ubuntu, Arch, CentOS, openSUSE, and more. The architecture is a modular Python application with a central build pipeline orchestrated in mkosi/__init__.py. Configuration is handled via layered INI-style files with conditional [Match]/[Assert] sections, allowing complex multi-image builds. A sandbox abstraction (sandbox.py) isolates tool execution using Linux namespaces, mounts, and seccomp filters. Distribution-specific installers are registered via a class registry pattern in mkosi/distribution/__init__.py. The tool also provides standalone subcommands: mkosi-initrd, mkosi-addon, mkosi-sandbox, each with its own entry point. Key features include incremental caching, SecureBoot signing, verity and TPM support, kernel-install integration, tools tree for reproducible builds, and a comprehensive manifest generation. The codebase is well-structured with clear separation between configuration, sandboxing, package management, and image creation. It has extensive tests (pytest with integration markers) and active CI.
CS Demo Manager is a mature Electron + React desktop application for managing Counter-Strike 2 and CS:GO demo files. It provides a complete pipeline: downloading demos from Valve, Faceit, 5EPlay, and Renown; parsing them to extract all game events (kills, rounds, economy, grenades, positions, etc.) into a PostgreSQL database; viewing 2D match replays with heatmaps and timeline; generating highlight videos via HLAE/FFmpeg; and exporting statistics to XLSX/JSON. The architecture consists of three processes: an Electron main process for window lifecycle, a React renderer for the UI, and a background Node.js server daemon for demo analysis, video encoding, and scheduled tasks. The codebase is well-structured with strong separation of concerns, extensive type usage, custom error hierarchies, and a comprehensive test suite for core logic. It demonstrates high craftsmanship in generic UI components (virtualized table, heatmap, dialogs) and IPC patterns (typed WebSocket client with reply queue).
Fork TS Checker Webpack Plugin is a mature, production-grade webpack plugin that offloads TypeScript type checking to a separate process to avoid blocking the webpack build. The architecture is centered around a plugin class that integrates with webpack's compilation lifecycle via tapable hooks. On each compilation, it collects file changes and spawns two types of workers (via child_process RPC): one for computing TypeScript issues (syntactic, semantic, declaration, global diagnostics) and another for computing file dependencies. Workers use a controlled TypeScript system with an in-memory file system (memfs) for artifacts and a passive file system that delegates writes to memory for read-only modes. The plugin supports incremental watching, project references (solution builder), tracing, and various output modes (write-dts, write-tsbuildinfo, write-references). Configuration is flexible via cosmiconfig and validated with JSON schema. The codebase is well-structured with clear separation of concerns: hooks, formatters, issue filtering, RPC infrastructure, and file system abstractions. It includes extensive unit and end-to-end tests covering various TypeScript versions and webpack configurations. The plugin is actively maintained with a robust CI/CD pipeline and semantic release.
This repository is an unofficial PyTorch implementation of the Titans architecture from the research paper 'Titans: Learning to Memorize at Test Time'. It provides a library of neural network modules including Neural Memory, Memory-as-Context Transformer, and various attention mechanisms. The codebase consists of modular components that can be used as building blocks for sequence modeling, with training scripts demonstrating language modeling on the enwik8 dataset. The implementation focuses on test-time training mechanisms where the model learns to memorize at inference time through a neural memory module that updates its weights based on incoming sequences.
This is a production-grade single-page web application for picking and converting colors in the OKLCH and LCH color spaces. It provides interactive 2D charts (WebGL2-accelerated), sliders, numeric inputs, and a 3D gamut model (three.js) to explore and select colors. The app supports sRGB, Display P3, and Rec.2020 gamuts, and can parse and output a wide variety of color formats (hex, rgb, hsl, oklch, lch, lab, linear RGB, Figma P3 hex, etc.). State management is handled by nanostores with persistent settings in localStorage, and the URL hash is used for shareable color states. The codebase is well-structured with clear separation between core color logic (lib/), reactive stores (stores/), and UI components (view/). It includes a comprehensive test suite and CI/CD pipelines for deployment to Firebase Hosting. The architecture is a monolith frontend with no backend, built with Vite, TypeScript, PostCSS, and Pug templates.
Vue Macros is a monorepo of compile-time macros and syntactic sugar for Vue's `<script setup>`. It provides a collection of AST transforms (e.g., `defineOptions`, `defineModels`, `shortVmodel`, `reactivityTransform`, `setupComponent`) that are applied at build time, requiring no runtime overhead. The codebase is organized around a consistent `unplugin` pattern, where each macro is implemented as a separate package under `packages/`, and the main `vue-macros` package combines them all. Transforms are performed using Babel parsing and `MagicStringAST` for source-code manipulation, with TypeScript type resolution handled by a dedicated `@vue-macros/api` package. Architecturally, the repo is a well-structured, multibundler tool. Each feature package exports per-bundler adapters (Vite, Rollup, esbuild, Webpack, Rspack, Rolldown) while sharing a core transform implemented in `src/core/`. The configuration system (`packages/config`) dynamically enables or disables features based on the detected Vue version, and a Volar plugin (`packages/volar`) provides IDE support. Playgrounds under `playground/` demonstrate all macros in real projects, and the documentation site (Vitepress) includes interactive demos and i18n. Key data flows are compile-time only: Vue SFC source is parsed into AST, the macro transform walks and modifies the AST (using `walkAST` and `MagicStringAST`), and then outputs transformed code with injected helper imports. External dependencies include `vue` (for SFC parsing), `@babel/parser`, `magic-string-ast`, `unplugin`, `neverthrow`, and Volar core packages. The repo is actively maintained, with a large test suite (snapshots, fixture tests, type tests) and CI across multiple Node versions and OS platforms.
Ciao is a monolithic Rails 8 application for monitoring HTTP(S) endpoints. It periodically checks URLs for status codes and TLS certificate expiration, records status changes, and sends notifications via email or webhooks. The application uses SQLite for storage (no external database dependency), Rufus-scheduler for in-memory background job scheduling, and Puma as the web server. It provides a web UI and a RESTful JSON API for managing checks. The codebase is well-structured with clear separation of concerns, custom validators, a template-based notification renderer, and comprehensive test coverage. It follows modern Rails conventions and 12-factor app configuration via environment variables.
Aedes is a stream-based MQTT broker implementing MQTT 3.1 and 3.1.1 protocols. It provides a modular architecture where core broker logic handles protocol parsing, client sessions, message routing (QoS 0-2), retained messages, and Last Will and Testament. The system is designed to be embedded in various server types (TCP, TLS, WebSocket) through its handle() method. Key features include pluggable persistence and messaging layers, authentication/authorization hooks, clustering support, and comprehensive topic validation with wildcard handling. The codebase demonstrates strong attention to protocol correctness, backpressure handling, and security (e.g., prototype pollution protection).
Splitjoin.vim is a Vim plugin that toggles code between single-line and multi-line representations for a wide range of programming languages (Ruby, Python, Rust, JavaScript, Go, etc.). It provides two commands (`SplitjoinSplit` and `SplitjoinJoin`) and default mappings (`gS` and `gJ`) that intelligently split or join constructs like if-clauses, hashes, function calls, arrays, and more. The plugin uses a callback-based architecture where each filetype registers its own split/join functions, and the core engine iterates through them until one succeeds. It includes extensive test coverage using RSpec and Vimrunner, and supports many configurable options for coding style (trailing commas, alignment, brace placement, etc.). The codebase is well-organized with a clear separation between core utilities (`autoload/sj.vim`), language-specific logic (`autoload/sj/*.vim`), argument parsers (`autoload/sj/argparser/`), and filetype configuration (`ftplugin/*/splitjoin.vim`).
STC (Smart Template Containers) is a mature, type-safe generic container and algorithm library for C99/C11. It is not an application or service; it is a library component that developers link into systems programs, embedded code, games, and simulations. The library provides macro-instantiated generic containers (vec, list, deque, stack, queue, priority queue, hash map, hash set, sorted map, sorted set, bitset), string types with small-string optimization (cstr, csview), multi-dimensional array views (cspan), smart pointers (box, arc, rc), a regular expression engine (cregex), a stackful coroutine framework, random number generators, and algorithms such as sorting, filtering, and binary search. The code implements the actual functionality; the README and docs describe usage, but the headers and src tree are the ground truth. The architecture is a hybrid header-only and compiled library. Templated containers are generated at compile time by a sophisticated macro trait system (via i_key, i_type, c_pro_key, etc.), while non-templated facilities like cstr, cregex, cspan, and random are partially implemented in src/ and linked as libstc. Public entry points are the headers under include/stc/; the build supports both Makefile and Meson, with examples and tests under examples/ and tests/. External dependencies are minimal, essentially the C11 standard library only, with compiler-specific pragmas and intrinsics for GCC, Clang, MSVC, and TCC. Data flows are primarily in-memory: containers own and manage elements, string operations transform UTF-8 text, regex compiles and executes NFA graph matching, and coroutines yield and resume across tasks. The codebase demonstrates strong engineering practice: a custom test harness (ctest.h), CI with sanitizers across three OSes, extensive API documentation, and a large examples corpus. The macro-based generic system is clever and powerful but carries the usual debugging and tooling complexity; deprecated aliases still exist from API churn. Overall this is a high-quality, reusable C library with several notably self-contained subsystems that could be lifted into other projects.
AngelLive is a cross-platform (iOS, macOS, tvOS) live streaming viewer that aggregates content from multiple Chinese streaming platforms (Bilibili, etc.) via a dynamic plugin system. The application is built entirely in Swift, using SwiftUI for the UI layer with UIKit bridging where needed. Its core architecture revolves around a shared library, AngelLiveCore, which provides a plugin runtime for loading JavaScript-based platform adapters, a custom danmaku (bullet-chat) rendering engine, unified playback recovery with a state machine, and iCloud-based favorite and credential synchronization. The macOS and tvOS targets share the same core but have platform-specific UI components and input handling (e.g., tvOS focus-driven navigation, macOS menu bar and window management). The system is characterized by a high degree of modularity and concurrency: plugins are isolated sandboxed JavaScript runtimes, the danmaku engine uses asynchronous layer rendering and a dedicated shoot scheduler to handle burst traffic, and the playback recovery coordinator implements a tunable ladder of fallback actions (reload, switch CDN, refresh play args) to handle stream stalls. The favorite syncing engine uses `CKSyncEngine` with actor-based concurrency and circuit breakers to avoid retry storms. The codebase also includes a comprehensive test suite covering plugin operation, playback recovery, danmaku connection reconnection, and favorite refresh policies. Key entry points for the iOS app are `AngelLiveApp.swift` and `ContentView.swift`, which manage navigation and deep link handling. The macOS app uses `TabView` with sidebar navigation, and the tvOS app uses a SwiftUI-based sidebar and focusable grid. The developer console (`PluginConsoleView`) provides real-time logging and filtering of plugin calls, which is useful for debugging and extending the platform support. The app supports DLNA casting via SSDP discovery and a local HTTP proxy, and it integrates with AirPlay and Picture-in-Picture. Overall, AngelLive is a well-engineered, production-quality application with a clear separation of concerns, strong test coverage, and a plugin architecture that allows it to adapt to new platforms without modifying the core app. Its design patterns—such as the actor-based credential manager, the state machine for playback recovery, and the modular danmaku engine—are candidates for extraction into other projects.
This is the rx-angular monorepo, a production-grade toolkit for building fully reactive Angular applications with a focus on runtime performance, zone-less change detection, and developer experience. It provides a set of libraries including @rx-angular/state (reactive state management with RxState and rxEffects), @rx-angular/template (structural directives like *rxLet, *rxIf, *rxFor, and pipes like RxPush), @rx-angular/cdk (coercing, transformations, zone-less APIs, render strategies, and coalescing), @rx-angular/isr (incremental static regeneration for Angular SSR), @rx-angular/eslint-plugin (custom rules to enforce reactive, zone-less coding patterns), and @rx-angular/rebundle (an experimental esbuild/rolldown plugin for advanced chunk merging). The repo also includes comprehensive demo apps, documentation (Docusaurus), and end-to-end tests. The architecture is a typical Nx monorepo with each library as a separate secondary entry point, allowing tree-shaking. The code demonstrates strong engineering practices: extensive unit tests, property-based testing, well-typed APIs, and thoughtful abstractions for performance-critical rendering. The primary data flows are RxJS observable streams bound to Angular templates via the structural directives, with sophisticated scheduling and coalescing strategies to minimize change detection cycles.
This repository is a Java/Kotlin client library for the Telegram Bot API, providing type-safe wrappers for all bot API methods and models. The architecture is a classic library with a fluent builder pattern: users create request objects (e.g., `SendMessage`, `GetUpdates`), execute them via the `TelegramBot` class, and receive typed responses. The library handles both synchronous and asynchronous execution, supports long-polling and webhook modes, and includes Telegram Passport encryption/decryption utilities. The codebase is well-structured, with clear separation into model, request, response, and utility packages. It features custom Gson adapters for polymorphic API types (e.g., reaction types, chat boost sources) that demonstrate a clean discriminated union deserialization pattern. The library is actively maintained, tracking Telegram Bot API updates closely, and includes Kotlin extension functions for idiomatic usage. It is not a data research project; it is purely an integration library.
lua-resty-redis is a Lua Redis client driver for OpenResty/ngx_lua, leveraging the cosocket API for fully non-blocking I/O. It implements the Redis wire protocol (RESP) to support all standard Redis commands, including pipelining, transactions, pub/sub, and SSL connections. The library provides automatic method generation via Lua metatables, allowing any Redis command to be called as a method without explicit registration. It also offers connection pooling, Unix socket support, and configurable timeouts. The single source file (lib/resty/redis.lua) is self-contained and can be dropped into any OpenResty project. The codebase demonstrates strong engineering practices with efficient table reuse, proper error handling, and comprehensive test coverage.
This repository implements 'moss', a monolithic, Unix-like operating system kernel written in Rust, targeting AArch64 (with stubs for x86_64). It boots on QEMU and aims to run unmodified Linux userspace binaries (e.g., bash, coreutils, strace) by providing a Linux-compatible syscall interface. The kernel features an asynchronous core: all non-trivial syscalls are async functions, and the scheduler (EEVDF) and synchronization primitives are designed for async operation. The architecture includes a Hardware Abstraction Layer (HAL) via the `Arch` trait, but the majority of the code is ARM64-specific, covering boot, exception handling, MMU, interrupt controllers (GICv2/v3), UART drivers, timers, RTC, virtio, and a virtio-GPU display driver. The kernel provides a full process model with clone, execve, signals, futex, epoll, inotify, ptrace, and POSIX credentials. Memory management includes demand paging, copy-on-write, mmap, brk, a slab allocator with per-CPU caches, and a buddy allocator for physical frames. The VFS supports multiple filesystems: tmpfs, ext4 (via the ext4plus crate), FAT32, procfs, devfs, sysfs, and a cgroupfs stub. Networking uses the smoltcp stack for TCP/UDP and provides Unix domain sockets. The codebase is experimental and contains many stubs and unimplemented syscalls, but it is actively developed with a working init process, shell, and basic tools. Key strengths include the clean separation of architecture-independent kernel building blocks in the `libkernel` crate, the async-friendly synchronization primitives (`WakerSet`, `CondVar`, `Mutex`), the generic page table framework, and the driver registration macro. The code is well-structured for a kernel of this complexity, with extensive use of Rust's type system for safety (e.g., typed addresses, user-copy abstractions). However, the project is not production-hardened, relies on nightly Rust, and has significant architecture-specific code that limits portability.
AngryOxide is a production-grade 802.11 WiFi security auditing tool written in Rust. It captures and analyzes wireless frames in real time via raw AF_PACKET sockets, performs deauthentication, disassociation, PMKID, rogue M2, and other attacks, and outputs handshake data in hashcat-compatible hc22000 format, PCAPNG files with GPS metadata, and KismetDB SQLite databases. The application features a full terminal user interface built on ratatui with custom widgets (AdvTable, TabbedBlock) for monitoring access points, stations, and handshakes, as well as a headless mode for scripting. It integrates GPSD for geotagging and geofencing, and includes a standalone pcap/pcapng parsing library with fuzz testing and benchmarks. The architecture is a single binary monolith with clear module separation, background worker threads for I/O, and a state-machine attack engine. It is actively maintained, well-documented, and demonstrates strong Rust engineering practices.
ifvisible.js is a modern, dependency-free browser library that provides a clean, event-driven API for detecting page visibility and user activity. It wraps the standard Page Visibility API to surface focus/blur events, and adds an idle-detection system that fires `idle`/`wakeup` events after a configurable period of user inactivity (mouse, keyboard, touch, scroll). Version 3 is a complete rewrite in TypeScript with per-instance event isolation, SSR-safe construction (no DOM access at import time), and support for the Page Lifecycle API (`freeze`/`resume` for bfcache). The library ships as an ESM module, CommonJS, and an IIFE global, with bundled type definitions. It is designed for use in any client-side JavaScript project—SPA frameworks, traditional websites, or even server-side rendering environments (where it becomes a safe no-op). The architecture is simple: a single `IfVisible` class holds an internal `EventEmitter` and a `Timer` class for smart intervals that auto-pause when the user is idle. The codebase is well-structured, thoroughly tested (including an SSR test), and follows modern best practices. It is not a data research project; it is a reusable application library.
FLIP Fluids is a production-grade Blender addon for liquid simulation, integrating a custom C++ FLIP (Fluid Implicit Particle) engine with a comprehensive Python UI. The engine implements advanced numerical methods including level sets, variational pressure solvers, PCG with MIC(0) preconditioning, force fields, whitewater particles, and viscosity solvers, all backed by a vendored Eigen linear algebra library. The Blender addon provides property groups, UI panels, preset management, material libraries, and command-line scripts for baking, rendering, and Alembic/USD export. The architecture is a hybrid: the C++ engine is compiled as a shared library and accessed via C bindings and Python ctypes wrappers, while the addon code follows standard Blender patterns (operators, panels, property groups). Key entry points include the baking operators, simulation domain properties, and the engine's Python bindings in `ffengine/`. External dependencies include Blender (4.5+), Eigen, and optionally Mixbox for color blending. The codebase is well-structured with extensive version compatibility layers, but the vendored Eigen and reliance on Blender's evolving API introduce moderate technical drift.
NUR (Nix User Repository) is a community package registry and distribution layer for Nix. In production it maintains a registry of several hundred user-contributed Nix repositories in repos.json, pins every entry to a specific revision in repos.json.lock, and exposes the aggregate as a Nix flake/overlay/package set. The Nix entry points (default.nix, flake.nix, lib/evalRepo.nix, lib/repoSource.nix) lazily translate locked registry entries into `nur.repos.<name>.<pkg>` attributes, including typed support for NixOS, Home Manager, Darwin, and flake-parts modules and overlays via flake-parts. The operational core is a small, typed Python CLI (`bin/nur` and `ci/nur/`) with subcommands for updating the lockfile, evaluating repos, formatting the manifest, generating a combined monorepo, and producing a search index. Updates run hourly via GitHub Actions: each repo is concurrently prefetched using either the Git smart HTTP protocol or GitHub/GitLab archive endpoints, evaluated in a sandboxed `nix-env` run to catch breakage, and then either locked to a new revision or pruned from the registry if deleted. A separate set of CI scripts publishes `nur-combined` and updates package search data. The architecture is cleanly split between Nix expression logic and Python automation, with careful handling of async concurrency, evaluation failures, and safety guards against accidental mass repository loss.