Show HN: Externalized Properties, a modern Java configuration library
Show HN (score: 6)Description
More from Show
Show HN: Ec – a terminal Git conflict resolver inspired by IntelliJ
Show HN: Ec – a terminal Git conflict resolver inspired by IntelliJ Hi HN, I built ec because my friends who are new to development kept getting stuck on Git conflicts.<p>Most TUI merge tools felt hard to use or non-intuitive for them. The only flow they found easy was the IntelliJ (JetBrains) conflict resolver, so I recreated that experience in the terminal.<p>ec is a terminal-native, 3-pane conflict resolver with a focused, step-by-step flow. If you try it and leave feedback, I would be really grateful. Thanks!<p>Repo: <a href="https://github.com/chojs23/ec" rel="nofollow">https://github.com/chojs23/ec</a>
Show HN: Emmtrix ONNX-to-C Code Generator for Edge AI Deployment
Show HN: Emmtrix ONNX-to-C Code Generator for Edge AI Deployment Hi HN, we wanted to share our open source ONNX-to-C code generator. It translates ONNX models into C code for deployment on embedded systems. We developed it for use with emmtrix Code Vectorizer (<a href="https://www.emmtrix.com/tools/emmtrix-code-vectorizer" rel="nofollow">https://www.emmtrix.com/tools/emmtrix-code-vectorizer</a>) which optimizes the generated code for various embedded architectures. The ONNX-to-C code generator can however also be used standalone to generate plain C code. In contrast to many other tools, it makes deployment trivial since the generated code is fully standalone and no additional runtime is required.
Show HN: SHDL – A minimal hardware description language built from logic gates
Show HN: SHDL – A minimal hardware description language built from logic gates Hi, everyone!<p>I built SHDL (Simple Hardware Description Language) as an experiment in stripping hardware description down to its absolute fundamentals.<p>In SHDL, there are no arithmetic operators, no implicit bit widths, and no high-level constructs. You build everything explicitly from logic gates and wires, and then compose larger components hierarchically. The goal is not synthesis or performance, but understanding: what digital systems actually look like when abstractions are removed.<p>SHDL is accompanied by PySHDL, a Python interface that lets you load circuits, poke inputs, step the simulation, and observe outputs. Under the hood, SHDL compiles circuits to C for fast execution, but the language itself remains intentionally small and transparent.<p>This is not meant to replace Verilog or VHDL. It’s aimed at: - learning digital logic from first principles - experimenting with HDL and language design - teaching or visualizing how complex hardware emerges from simple gates.<p>I would especially appreciate feedback on: - the language design choices - what feels unnecessarily restrictive vs. educationally valuable - whether this kind of “anti-abstraction” HDL is useful to you.<p>Repo: <a href="https://github.com/rafa-rrayes/SHDL" rel="nofollow">https://github.com/rafa-rrayes/SHDL</a><p>Python package: PySHDL on PyPI<p>To make this concrete, here are a few small working examples written in SHDL:<p>1. Full Adder<p>component FullAdder(A, B, Cin) -> (Sum, Cout) {<p><pre><code> x1: XOR; a1: AND; x2: XOR; a2: AND; o1: OR; connect { A -> x1.A; B -> x1.B; A -> a1.A; B -> a1.B; x1.O -> x2.A; Cin -> x2.B; x1.O -> a2.A; Cin -> a2.B; a1.O -> o1.A; a2.O -> o1.B; x2.O -> Sum; o1.O -> Cout; }</code></pre> }<p>2. 16 bit register<p># clk must be high for two cycles to store a value<p>component Register16(In[16], clk) -> (Out[16]) {<p><pre><code> >i[16]{ a1{i}: AND; a2{i}: AND; not1{i}: NOT; nor1{i}: NOR; nor2{i}: NOR; } connect { >i[16]{ # Capture on clk In[{i}] -> a1{i}.A; In[{i}] -> not1{i}.A; not1{i}.O -> a2{i}.A; clk -> a1{i}.B; clk -> a2{i}.B; a1{i}.O -> nor1{i}.A; a2{i}.O -> nor2{i}.A; nor1{i}.O -> nor2{i}.B; nor2{i}.O -> nor1{i}.B; nor2{i}.O -> Out[{i}]; } }</code></pre> }<p>3. 16-bit Ripple-Carry Adder<p>use fullAdder::{FullAdder};<p>component Adder16(A[16], B[16], Cin) -> (Sum[16], Cout) {<p><pre><code> >i[16]{ fa{i}: FullAdder; } connect { A[1] -> fa1.A; B[1] -> fa1.B; Cin -> fa1.Cin; fa1.Sum -> Sum[1]; >i[2,16]{ A[{i}] -> fa{i}.A; B[{i}] -> fa{i}.B; fa{i-1}.Cout -> fa{i}.Cin; fa{i}.Sum -> Sum[{i}]; } fa16.Cout -> Cout; } }</code></pre>
Show HN: 83 browser-use trajectories, visualized
Show HN: 83 browser-use trajectories, visualized Hey all, Justin here. I previously built Phind, the AI search engine for developers.<p>One of the biggest problems we had there was figuring out what went wrong with bad searches. We had tons of searches per day, but less than 1% of users gave any explicit feedback. So we were either manually digging through searches or making general system improvements and hoping they helped.<p>This problem gets harder with agents. Traces are longer and more complex. It takes more effort to review them, so I'm building a tool that lets you analyze LLM outputs directly to help developers of LLM apps and agents understand where things are breaking and why.<p>I've put together a demo using browser-use agent traces (gpt-5): <a href="https://trails-red.vercel.app/viewer" rel="nofollow">https://trails-red.vercel.app/viewer</a><p>It's early, but I have lots of ideas - live querying of past failures for currently-running agents, preference models to expand sparse signal data.<p>Would love feedback on the demo. Also if you're building agents and have 10k+ traces per day that you're not looking at but would like to, I'd love to talk.
No other tools from this source yet.