Show HN: BambooGrid – Open-source web UI for power grid modeling and power flow
9 by soaringmonchi | 2 comments on Hacker News.
Hi HN, I am co-founder of Kickstage, a software company specializing in solutions for the electrical industry and lately grid operators. We are hiring engineers from different backgrounds, a lot of them software developers with limited experience in the sectors. Deep domain knowledge is key in our industry however, so we are constantly teaching the basics of power flow analysis, active vs reactive power, transmission line properties etc. With Jupyter notebooks and the Python console only, that's a tedious task and hardly ever led to a deep understanding of the topics. So we built BambooGrid: a web-based editor on top of pandapower, a popular simulation library in our industry. You drag elements like buses, lines, loads generators and transformers onto a canvas, wire them up, set parameters and run power flow. It will print results directly on the canvas, color buses according to their voltages, even allows you to see an interactive admittance matrix. You can try it out without installing anything on https://ift.tt/5vqF9Om (thanks to our friends at Hostzero who sponsored hosting). Start with one of the included samples or draw your own. Just don't forget to add a slack element. Built on a Python backend (driven by the choice of pandapower mainly) and a React frontend. Fully MIT licensed, so feel free to use and modify to your liking.
Even better: Give us feedback - we're extremely open to suggestions how to improve the tool and are glad about every user who learns a bit more about power systems through it. Šime, who built most of this, is also in the thread. We are both happy to answer anything about the implementation or power systems in general.
Hack Nux
Watch the number of websites being hacked today, one by one on a page, increasing in real time.
New ask Hacker News story: Why people chasing after useless token saving plugins and ignoring real solution
Why people chasing after useless token saving plugins and ignoring real solution
2 by yohji1984 | 0 comments on Hacker News.
I wrote a blog yesterday on how useless RTK and Ponytail are on real coding tasks. And published my agent harness long-horizon task benchmarks on 80% real token saving. I just want to know why people just ignore the fact those pulgins are useless and don't care about the real savings? full reports are on my repo: https://ift.tt/2KxZ731 Arm n Harness score Total tokens Modeled cost Rounds Duration No plugin 2 78.85% 6.660M $5.281946 62.5 895s Ponytail 2 80.77% -7.56% -8.87% -9.60% +13.51% RTK 2 76.92% +13.20% +7.18% +44.00% +40.69% Configuration Passes Pass rate Observed tokens Rounds Estimated cost Tura Balanced High 48/60 80.0% 229,695,477 2,017 $221.138 Tura Direct High 39/60 65.0% 75,108,167 969 $99.620 Codex CLI Medium 38/60 63.3% 333,538,349 3,140 $257.173 Codex CLI High 36/60 60.0% 455,742,296 6,074 $327.483
2 by yohji1984 | 0 comments on Hacker News.
I wrote a blog yesterday on how useless RTK and Ponytail are on real coding tasks. And published my agent harness long-horizon task benchmarks on 80% real token saving. I just want to know why people just ignore the fact those pulgins are useless and don't care about the real savings? full reports are on my repo: https://ift.tt/2KxZ731 Arm n Harness score Total tokens Modeled cost Rounds Duration No plugin 2 78.85% 6.660M $5.281946 62.5 895s Ponytail 2 80.77% -7.56% -8.87% -9.60% +13.51% RTK 2 76.92% +13.20% +7.18% +44.00% +40.69% Configuration Passes Pass rate Observed tokens Rounds Estimated cost Tura Balanced High 48/60 80.0% 229,695,477 2,017 $221.138 Tura Direct High 39/60 65.0% 75,108,167 969 $99.620 Codex CLI Medium 38/60 63.3% 333,538,349 3,140 $257.173 Codex CLI High 36/60 60.0% 455,742,296 6,074 $327.483
New Show Hacker News story: Show HN: SirixDB 1.0 Beta – Git-Like Versioning, Diffs, Time-Travel Queries
Show HN: SirixDB 1.0 Beta – Git-Like Versioning, Diffs, Time-Travel Queries
9 by lichtenberger | 0 comments on Hacker News.
Hi HN! I've posted SirixDB here before, back in 2019 ( https://ift.tt/vWX1UQo ) and again in 2023 ( https://ift.tt/4CufLzr ). The core idea behind SirixDB is, that history is a first-class citizen. Every commit stores a lightweight, queryable revision. You can query any point in time, even individual nodes (for instance JSON values), diff arbitrary revisions, and efficiently track how data evolved without replaying events. Unlike traditional event stores, historical states do not need to be reconstructed by replaying events nor do we have to think about projections. Revisions are directly queryable. A simple example: Jan 1: Record "Price = $100, valid from Jan 1". Stored on Jan 1 (transaction time). Jan 20: Discover price was actually $95 on Jan 1. Commit correction. After correction, you can ask across both axes: - "What did we THINK the price was on Jan 16?" -> $100 (Transaction time) - "What WAS the price on Jan 1?" -> $95 (Valid time) I've worked on this in my spare time since 2013, following its academic precursor (Idefix/Treetank) at the University of Konstanz. The architecture relies on an append-only physical log and a persistent copy-on-write page trie. A high level view of the architecture: Physical Log (append-only, sequential writes) ┌────────────────────────────────────────────────────────────────────────┐ │ [R1:Root] [R1:P1] [R1:P2] [R2:Root] [R2:P1'] [R3:Root] [R3:P2'] ... │ └────────────────────────────────────────────────────────────────────────┘ t=0 t=1 t=2 t=3 t=4 t=5 t=6 → time Each revision is indexed, and unchanged pages are shared: [Rev 1] [Rev 2] [Rev 3] │ │ │ ▼ ▼ ▼ [Root₁] [Root₂] [Root₃] │ │ │ │ │ │ │ └─────────┐ │ └────────┐ │ └─────────┐ ▼ ▼ ▼ ▼ ▼ ▼ ┌──────┐ ┌──────┐ ┌──────┐ ┌──────┐ │ P1 │ │ P2 │ │ P1' │ │ P2' │ └──────┘ └──────┘ └──────┘ └──────┘ Rev 1 Rev 1+2 Rev 2+3 Rev 3 (shared) (shared) Beneath the root pages sit node and secondary indexes, using a novel sliding-snapshot algorithm to balance read/write performance. Everything is queryable using JSONiq via the Brackit compiler. Back in 2019, and even in 2023, SirixDB was very slow due to GC pressure. Unlike most other document stores, SirixDB stores fine-grained nodes, and I came to realize that an on-heap (JVM) representation made up of lots of small objects simply didn't make sense. I measured it with async-profiler — with some help from Andrei Pangin himself — and the result was that the poor throughput was due to the sheer amount of allocations which scaled almost linearly with the number of open transactions. Working a full-time software engineering job, I lacked the energy for a massive spare-time rewrite. About a year ago, I started experimenting with AI. It turned out to be ideal for automating the tedious, repetitive parts of migrating the storage layer to Java's Foreign Function & Memory API, storing pages completely off-heap. Looking further ahead, the append-only, immutable-page design maps naturally onto object storage like S3 and distributed logs like Kafka for a cloud version, and initial prototypes already exist. Maybe that becomes a commercial service one day, but for now, I'm just thrilled to see these core design principles finally proven out.There's an interactive demo, documentation, and the code is on GitHub. I'd love feedback and am happy to answer questions! kind regards Johannes [1] https://sirix.io | https://ift.tt/YLQuBWH [2] https://ift.tt/914Ovsq [3] https://demo.sirix.io [4] https://sirix.io/docs/ [5] http://brackit.io
9 by lichtenberger | 0 comments on Hacker News.
Hi HN! I've posted SirixDB here before, back in 2019 ( https://ift.tt/vWX1UQo ) and again in 2023 ( https://ift.tt/4CufLzr ). The core idea behind SirixDB is, that history is a first-class citizen. Every commit stores a lightweight, queryable revision. You can query any point in time, even individual nodes (for instance JSON values), diff arbitrary revisions, and efficiently track how data evolved without replaying events. Unlike traditional event stores, historical states do not need to be reconstructed by replaying events nor do we have to think about projections. Revisions are directly queryable. A simple example: Jan 1: Record "Price = $100, valid from Jan 1". Stored on Jan 1 (transaction time). Jan 20: Discover price was actually $95 on Jan 1. Commit correction. After correction, you can ask across both axes: - "What did we THINK the price was on Jan 16?" -> $100 (Transaction time) - "What WAS the price on Jan 1?" -> $95 (Valid time) I've worked on this in my spare time since 2013, following its academic precursor (Idefix/Treetank) at the University of Konstanz. The architecture relies on an append-only physical log and a persistent copy-on-write page trie. A high level view of the architecture: Physical Log (append-only, sequential writes) ┌────────────────────────────────────────────────────────────────────────┐ │ [R1:Root] [R1:P1] [R1:P2] [R2:Root] [R2:P1'] [R3:Root] [R3:P2'] ... │ └────────────────────────────────────────────────────────────────────────┘ t=0 t=1 t=2 t=3 t=4 t=5 t=6 → time Each revision is indexed, and unchanged pages are shared: [Rev 1] [Rev 2] [Rev 3] │ │ │ ▼ ▼ ▼ [Root₁] [Root₂] [Root₃] │ │ │ │ │ │ │ └─────────┐ │ └────────┐ │ └─────────┐ ▼ ▼ ▼ ▼ ▼ ▼ ┌──────┐ ┌──────┐ ┌──────┐ ┌──────┐ │ P1 │ │ P2 │ │ P1' │ │ P2' │ └──────┘ └──────┘ └──────┘ └──────┘ Rev 1 Rev 1+2 Rev 2+3 Rev 3 (shared) (shared) Beneath the root pages sit node and secondary indexes, using a novel sliding-snapshot algorithm to balance read/write performance. Everything is queryable using JSONiq via the Brackit compiler. Back in 2019, and even in 2023, SirixDB was very slow due to GC pressure. Unlike most other document stores, SirixDB stores fine-grained nodes, and I came to realize that an on-heap (JVM) representation made up of lots of small objects simply didn't make sense. I measured it with async-profiler — with some help from Andrei Pangin himself — and the result was that the poor throughput was due to the sheer amount of allocations which scaled almost linearly with the number of open transactions. Working a full-time software engineering job, I lacked the energy for a massive spare-time rewrite. About a year ago, I started experimenting with AI. It turned out to be ideal for automating the tedious, repetitive parts of migrating the storage layer to Java's Foreign Function & Memory API, storing pages completely off-heap. Looking further ahead, the append-only, immutable-page design maps naturally onto object storage like S3 and distributed logs like Kafka for a cloud version, and initial prototypes already exist. Maybe that becomes a commercial service one day, but for now, I'm just thrilled to see these core design principles finally proven out.There's an interactive demo, documentation, and the code is on GitHub. I'd love feedback and am happy to answer questions! kind regards Johannes [1] https://sirix.io | https://ift.tt/YLQuBWH [2] https://ift.tt/914Ovsq [3] https://demo.sirix.io [4] https://sirix.io/docs/ [5] http://brackit.io
New ask Hacker News story: Ask HN: How's the idea of creating LinkedIn styled character profiles
Ask HN: How's the idea of creating LinkedIn styled character profiles
3 by anitroves | 3 comments on Hacker News.
I am working on it so tell me how this idea sounds to you.
3 by anitroves | 3 comments on Hacker News.
I am working on it so tell me how this idea sounds to you.
New ask Hacker News story: Ask HN: US Equivalent of Anabin?
Ask HN: US Equivalent of Anabin?
2 by xqb64 | 0 comments on Hacker News.
I'm wondering if there exists a US equivalent of Anabin[0] -- a German portal and database for evaluating foreign educational certificates. [0]: https://ift.tt/MaowHlQ
2 by xqb64 | 0 comments on Hacker News.
I'm wondering if there exists a US equivalent of Anabin[0] -- a German portal and database for evaluating foreign educational certificates. [0]: https://ift.tt/MaowHlQ
New Show Hacker News story: Show HN: A dashboard for tracking SK Hynix price gaps across exchanges
Show HN: A dashboard for tracking SK Hynix price gaps across exchanges
2 by jaxzxu | 0 comments on Hacker News.
I built this after SKHY began trading to make it easier to compare the US ADR with SK Hynix’s Korean shares. The dashboard adjusts for FX and the ADR conversion ratio. It highlights the current pricing gap, how it changed over time, and comparable trading volume. Data comes from Yahoo Finance. Feedback is welcome!
2 by jaxzxu | 0 comments on Hacker News.
I built this after SKHY began trading to make it easier to compare the US ADR with SK Hynix’s Korean shares. The dashboard adjusts for FX and the ADR conversion ratio. It highlights the current pricing gap, how it changed over time, and comparable trading volume. Data comes from Yahoo Finance. Feedback is welcome!