Reddit Programming
211 subscribers
1.22K photos
125K links
I will send you newest post from subreddit /r/programming
Download Telegram
Panoptic Segmentation using Detectron2
https://www.reddit.com/r/programming/comments/1qopi7p/panoptic_segmentation_using_detectron2/

<!-- SC_OFF -->For anyone studying Panoptic Segmentation using Detectron2, this tutorial walks through how panoptic segmentation combines instance segmentation (separating individual objects) and semantic segmentation (labeling background regions), so you get a complete pixel-level understanding of a scene. It uses Detectron2’s pretrained COCO panoptic model from the Model Zoo, then shows the full inference workflow in Python: reading an image with OpenCV, resizing it for faster processing, loading the panoptic configuration and weights, running prediction, and visualizing the merged “things and stuff” output. Video explanation: https://youtu.be/MuzNooUNZSY Medium version for readers who prefer Medium : https://medium.com/image-segmentation-tutorials/detectron2-panoptic-segmentation-made-easy-for-beginners-9f56319bb6cc Written explanation with code: https://eranfeit.net/detectron2-panoptic-segmentation-made-easy-for-beginners/ This content is shared for educational purposes only, and constructive feedback or discussion is welcome. Eran Feit <!-- SC_ON --> submitted by /u/Feitgemel (https://www.reddit.com/user/Feitgemel)
[link] (https://eranfeit.net/detectron2-panoptic-segmentation-made-easy-for-beginners/) [comments] (https://www.reddit.com/r/programming/comments/1qopi7p/panoptic_segmentation_using_detectron2/)
JSON vs XML in Embedded Linux - system design trade-offs
https://www.reddit.com/r/programming/comments/1qp07z1/json_vs_xml_in_embedded_linux_system_design/

<!-- SC_OFF -->Data formats define whether systems are lean or bloated. I explored how JSON and XML flow through embedded Linux: - Hardware → Driver → Kernel → Middleware → Application - Real code examples (I²C, sysfs, cJSON, libxml2) - Debugging strategies at every layer - Performance insights: JSON vs XML. Curious how others here approach data structuring in embedded or system-level projects — JSON, XML, or custom formats? <!-- SC_ON --> submitted by /u/ImaginaryPin1768 (https://www.reddit.com/user/ImaginaryPin1768)
[link] (https://codewafer.com/blogs/json-xml-in-embedded-linux-full-stack-guide-with-drivers-middleware/) [comments] (https://www.reddit.com/r/programming/comments/1qp07z1/json_vs_xml_in_embedded_linux_system_design/)
I tried learning compilers by building a language. It got out of hand.
https://www.reddit.com/r/programming/comments/1qp1j5m/i_tried_learning_compilers_by_building_a_language/

<!-- SC_OFF -->Hi all, I wanted to share a personal learning project I’ve been working on called sr-lang. It’s a small programming language and compiler written in Zig, with MLIR as the backend. I started it as a way to learn compiler construction by doing. Zig felt like a great fit, and its style/constraints ended up influencing the language design more than I expected. For context, I’m an ML researcher and I work with GPU-related stuff a lot, which is why you’ll see GPU-oriented experiments show up (e.g. Triton). Over time the project grew as I explored parsing, semantic analysis, type systems, and backend design. Some parts are relatively solid, and others are experimental or rough, which is very much part of the learning process. A bit of honesty up front I’m not a compiler expert. I used LLMs occasionally to explore ideas or unblock iterations. The design decisions and bugs are mine. If something looks awkward or overcomplicated, it probably reflects what I was learning at the time. It did take more than 10 months to get to this point (I'm slow). Some implemented highlights (selected) Parser, AST, and semantic analysis in Zig MLIR-based backend Error unions and defer / errdefer style cleanup Pattern matching and sum types comptime and AST-as-data via code {} blocks Async/await and closures (still evolving) Inline MLIR and asm {} support Triton / GPU integration experiments What’s incomplete Standard library is minimal Diagnostics/tooling and tests need work Some features are experimental and not well integrated yet I’m sharing this because I’d love feedback on design tradeoffs and rough edges help spotting obvious issues (or suggesting better structure) contributors who want low-pressure work (stdlib, tests, docs, diagnostics, refactors) Repo: https://github.com/theunnecessarythings/sr-lang Thanks for reading. Happy to answer questions or take criticism. <!-- SC_ON --> submitted by /u/theunnecessarythings (https://www.reddit.com/user/theunnecessarythings)
[link] (https://github.com/theunnecessarythings/sr-lang) [comments] (https://www.reddit.com/r/programming/comments/1qp1j5m/i_tried_learning_compilers_by_building_a_language/)
Walkthrough of X's algorithm that decides what you see
https://www.reddit.com/r/programming/comments/1qpharr/walkthrough_of_xs_algorithm_that_decides_what_you/

<!-- SC_OFF -->X open-sourced the algorithm behind the For You feed on January 20th (https://github.com/xai-org/x-algorithm). Candidate Retrieval Two sources feed the pipeline: Thunder: an in-memory service holding the last 48 hours of tweets in a DashMap (concurrent HashMap), indexed by author. It serves in-network posts from accounts you follow via gRPC. Phoenix: a two-tower neural network for discovery. User tower is a Grok transformer with mean pooling. Candidate tower is a 2-layer MLP with SiLU. Both L2-normalize, so retrieval is just a dot product over precomputed corpus embeddings. Scoring Phoenix scores all candidates in a single transformer forward pass, predicting 18 engagement probabilities per post - like, reply, retweet, share, block, mute, report, dwell, video completion, etc. To batch efficiently without candidates influencing each other's scores, they use a custom attention mask. Each candidate attends to the user context and itself, but cross-candidate attention is zeroed out. A WeightedScorer combines the 18 predictions into one number. Positive signals (likes, replies, shares) add to the score. Negative signals (blocks, mutes, reports) subtract. Then two adjustments: Author diversity - exponential decay so one author can't dominate your feed. A floor parameter (e.g. 0.3) ensures later posts still have some weight. Out-of-network penalty 0 posts from unfollowed accounts are multiplied by a weight (e.g. 0.7). Filtering 10 pre-filters run before scoring (dedup, age limit, muted keywords, block lists, previously seen posts via Bloom filter). After scoring, a visibility filter queries an external safety service and a conversation dedup filter keeps only the highest-scored post per thread. <!-- SC_ON --> submitted by /u/noninertialframe96 (https://www.reddit.com/user/noninertialframe96)
[link] (https://codepointer.substack.com/p/x-algorithm-how-x-decides-what-550) [comments] (https://www.reddit.com/r/programming/comments/1qpharr/walkthrough_of_xs_algorithm_that_decides_what_you/)
Locale-sensitive text handling (minimal reproducible example)
https://www.reddit.com/r/programming/comments/1qpjaj5/localesensitive_text_handling_minimal/

<!-- SC_OFF -->Text handling must not depend on the system locale unless explicitly intended. Some APIs silently change behavior based on system language. This causes unintended results. Minimal reproducible example under Turkish locale: "FILE".ToLower() == "fıle" Reverse casing example: "file".ToUpper() == "FİLE" This artifact exists to help developers detect locale-sensitive failures early. Use as reference or for testing. (You may download the .txt version of this post from the given link) <!-- SC_ON --> submitted by /u/BoloFan05 (https://www.reddit.com/user/BoloFan05)
[link] (https://drive.google.com/file/d/1Rgyxfzmw-rfchVi2oShJHHQ8YpMUqlgT/view?usp=sharing) [comments] (https://www.reddit.com/r/programming/comments/1qpjaj5/localesensitive_text_handling_minimal/)
We analyzed 6 real-world frameworks across 6 languages — here’s what coupling, cycles, and dependency structure look like at scale
https://www.reddit.com/r/programming/comments/1qpkt35/we_analyzed_6_realworld_frameworks_across_6/

<!-- SC_OFF -->We recently ran a structural dependency analysis on six production open-source frameworks, each written in a different language: Tokio (Rust) Fastify (JavaScript) Flask (Python) Prometheus (Go) Gson (Java) Supermemory (TypeScript) The goal was to look at structural characteristics using actual dependency data, rather than intuition or anecdote. Specifically, we measured: Dependency coupling Circular dependency patterns File count and SLOC Class and function density All results are from directly from the current GitHub main repository commits as of this week. The data at a glance Framework Language Files SLOC Classes Functions Coupling Cycles Tokio Rust 763 92k 759 2,490 1.3 0 Fastify JavaScript 277 70k 5 254 1.2 3 Flask Python 83 10k 69 520 2.1 1 Prometheus Go 400 73k 1,365 6,522 3.3 0 Gson Java 261 36k 743 2,820 3.8 10 Supermemory TypeScript 453 77k 49 917 4.3 0 Notes “Classes” in Go reflect structs/types; in Rust they reflect impl/type-level constructs. Coupling is measured as average dependency fan-out per parsed file. Full raw outputs are published for independent inspection (link below). Key takeaways from this set: 1. Size does not equal structural complexity Tokio (Rust) was the largest codebase analyzed (~92k SLOC across 763 files), yet it maintained: Very low coupling (1.3) Clear and consistent dependency direction This challenges the assumption that large systems inevitably degrade into tightly coupled “balls of mud.” 2. Cycles tend to cluster, rather than spread Where circular dependencies appeared, they were highly localized, typically involving a small group of closely related files rather than spanning large portions of the graph. Examples: Flask (Python) showed a single detected cycle confined to a narrow integration boundary. Gson (Java) exhibited multiple cycles, but these clustered around generic adapters and shared utility layers. No project showed evidence of cycles propagating broadly across architectural layers. This suggests that in well-structured systems, cycles — when they exist — tend to be contained, limiting their blast radius and cognitive overhead, even if edge-case cycles exist outside static analysis coverage. 3. Language-specific structural patterns emerge Some consistent trends showed up: Java (Gson)
Higher coupling and more cycles, driven largely by generic type adapters and deeper inheritance hierarchies
(743 classes and 2,820 functions across 261 files). Go (Prometheus)
Clean dependency directionality overall, with complexity concentrated in core orchestration and service layers.
High function density without widespread structural entanglement. TypeScript (Supermemory)
Higher coupling reflects coordination overhead in a large SDK-style architecture — notably without broad cycle propagation. 4. Class and function density explain where complexity lives Scale metrics describe how much code exists, but class and function density reveal how responsibility and coordination are structured. For example: Gson’s higher coupling aligns with its class density and reliance on generic coordination layers. Tokio’s low coupling holds despite its size, aligning with Rust’s crate-centric approach to enforcing explicit module boundaries. Smaller repositories can still accumulate disproportionate structural complexity when dependency direction isn’t actively constrained. Why we did this When onboarding to a large, unfamiliar repository or planning a refactor, lines of code alone are a noisy signal, and mental models, tribal knowledge, and architectural documentation often lag behind reality. Structural indicators like: Dependency fan-in / fan-out Coupling density Cycle concentration tend to correlate more directly with the effort
required to reason about, change, and safely extend a system. We’ve published the complete raw analysis outputs in the provided link: The outputs are static JSON artifacts (dependency graphs, metrics, and summaries) served directly by the public frontend. If this kind of structural information would be useful for a specific open-source repository, feel free to share a GitHub link. I’m happy to run the same analysis and provide the resulting static JSON (both readable and compressed) as a commit to the repo, if that is acceptable. Would love to hear how others approach this type of assessment in practice or what you might think of the analysis outputs. <!-- SC_ON --> submitted by /u/BaseDue9532 (https://www.reddit.com/user/BaseDue9532)
[link] (https://pvizgenerator.com/test-cases) [comments] (https://www.reddit.com/r/programming/comments/1qpkt35/we_analyzed_6_realworld_frameworks_across_6/)
AT&T Had iTunes in 1998. Here's Why They Killed It. (Companion to "The Other Father of MP3"
https://www.reddit.com/r/programming/comments/1qpsw4m/att_had_itunes_in_1998_heres_why_they_killed_it/

<!-- SC_OFF -->Recently I posted "The Other Father of MP3" about James Johnston, the Bell Labs engineer whose contributions to perceptual audio coding were written out of history. Several commenters asked what happened on the business side; how AT&T managed to have the technology that became iTunes and still lose. This is that story. Howie Singer and Larry Miller built a2b Music inside AT&T using Johnston's AAC codec. They had label deals, a working download service, and a portable player three years before the iPod. They tried to spin it out. AT&T killed the spin-out in May 1999. Two weeks later, Napster launched. Based on interviews with Singer (now teaching at NYU, formerly Chief of Strategic Technology at Warner Music for 10 years) and Miller (inaugural director of the Sony Audio Institute at NYU). The tech was ready. The market wasn't. And the permission culture of a century-old telephone monopoly couldn't move at internet speed. <!-- SC_ON --> submitted by /u/Traditional_Rise_609 (https://www.reddit.com/user/Traditional_Rise_609)
[link] (https://roguesgalleryprog.substack.com/p/the-a2b-spin-out-that-never-happened) [comments] (https://www.reddit.com/r/programming/comments/1qpsw4m/att_had_itunes_in_1998_heres_why_they_killed_it/)
40ns causal consistency by replacing consensus with algebra
https://www.reddit.com/r/programming/comments/1qpysme/40ns_causal_consistency_by_replacing_consensus/

<!-- SC_OFF -->Distributed systems usually pay milliseconds for correctness because they define correctness as execution order. This project takes a different stance: correctness is a property of algebra, not time. If operations commute, you don’t need coordination. If they don’t, the system tells you at admission time, in nanoseconds. Cuttlefish is a coordination-free state kernel that enforces strict invariants with causal consistency at ~40ns end-to-end (L1-cache scale), zero consensus, zero locks, zero heap in the hot path. Here, state transitions are immutable facts forming a DAG. Every invariant is pure algebra. The way casualty is tracked, is by using 512 bit bloom vector clocks which happen to hit a sub nano second 700ps dominance check. Non-commutativity is detected immediately, but if an invariant is commutative (abelian group/semilattice /monoid), admission requires no coordination. Here are some numbers for context(single core, Ryzen 7, Linux 6.x): Full causal + invariant admission: ~40ns
kernel admit with no deps: ~13ns
Durable admission (io_uring WAL): ~5ns For reference: etcd / Cockroach pay 1–50ms for linearizable writes. What this is: A low-level kernel for building databases, ledgers, replicated state machines Strict invariants without consensus when algebra allows it Bit-deterministic, allocation-free, SIMD-friendly Rust This is grounded in CALM, CRDT theory, and Bloom clocks, but engineered aggressively for modern CPUs (cache lines, branchless code, io_uring). Repo: https://github.com/abokhalill/cuttlefish I'm looking for feedback from people who’ve built consensus systems, CRDTs, or storage engines and think this is either right, or just bs. <!-- SC_ON --> submitted by /u/AdministrativeAsk305 (https://www.reddit.com/user/AdministrativeAsk305)
[link] (https://github.com/abokhalill/cuttlefish) [comments] (https://www.reddit.com/r/programming/comments/1qpysme/40ns_causal_consistency_by_replacing_consensus/)