butterfly
leaping
butterfly | leaping | |
---|---|---|
2 | 4 | |
4,225 | 248 | |
2.7% | 17.3% | |
3.0 | 2.9 | |
3 days ago | about 2 months ago | |
JavaScript | Python | |
MIT License | MIT License |
Stars - the number of stars that a project has on GitHub. Growth - month over month growth in stars.
Activity is a relative number indicating how actively a project is being developed. Recent commits have higher weight than older ones.
For example, an activity of 9.0 indicates that a project is amongst the top 10% of the most actively developed projects that we are tracking.
butterfly
- FLaNK AI Weekly 25 March 2025
-
Show HN: React Flow ā library for creating node based editors and apps
Butterfly [1] by alibaba has a vue wrapper (along with a React one) over a framework independent core.
It is not as well documented though.
[1] https://github.com/alibaba/butterfly
leaping
- FLaNK AI Weekly 25 March 2025
-
Show HN: Leaping ā Debug Python tests instantly with an LLM debugger
Oof, I'm sorry to hear that - I don't think we had any Django projects in the set of projects we were testing this out on. I just filed an issue here and hopefully fix it asap - https://github.com/leapingio/leaping/issues/2
-
Show HN: Leaping ā Open-source debugging with LLMs
Show HN: Leaping - Open-source debugging with LLMs
Hi HN! Weāre Adrien and Kanav. We met at our previous job, where we spent about a third of our life combating a constant firehose of bugs. In the hope of reducing this pain for others in the future, weāre working on automating debugging.
We started by capturing information from running applications to then āreplayā relevant sessions later. Our approach for Python involved extensive monkey patching: weād use OpenTelemetry-style instrumentation to hook into the request/response lifecycle, and capture anything non-deterministic (random, time, database/third-party API calls, etc.). We would then run your code again, mocking out the non-determinism with the captured values from production, which would let you fix production bugs with the local debugger experience. You might recognize this as a variant of omniscient debugging. We think it was a nifty idea, but we couldnāt get past the performance overhead/security concerns.
Approaching the problem differently, we thought - could we not just grab a stack trace and sort of āfigure it outā from there? Whether thatās possible in the general case is up for debate ā but we think that eventually, yes. The argument goes as follows: developers can solve bugs not because they are particularly clever or experienced (though it helps), but rather because they are willing to spend enough time coming up with increasingly informed hypotheses (āwas the variable set incorrectly inside of this function?ā) that they can test out in tight feedback loops (ālet me print out the variable before and after the function callā). We wondered: with the proper context and guidance, why couldnāt an LLM do the same?
Over the last few weeks, weāve been working on an approach that emulates the failing test approach to debugging, where you first reproduce the error in a failing test, then fix the source code, and finally run the test again to make sure it passes. Concretely, we take a stack trace, and start by simply re-running the function that failed. We then report the result back to the LLM, add relevant source code to the context window (with Tree-sitter and LSP), and prompt the AI for a code change that will get us closer to reproducing the bug. We apply those changes, re-run the script, and keep looping until we get the same bug as the original stack trace. Then the LLM formulates a root cause, generates a fix, we run the code again - and if the bug goes away, we call it a day. Weāre also looking into letting the LLM interact with a pdb shell, as well as implementing RAG for better context fetching. One thing that excites us about generating a functioning test case with a step-by-step explanation for the fix is that results are somewhat grounded in reality, making hallucinations/confabulations less likely.
Hereās a 50 second demo of how this approach fares on a (perhaps contrived) error: https://www.loom.com/share/a54c981536a54d3c9c269d8356ea0d51?sid=aeafd2d1-9b86-43ad-83a6-b1062aa1bb50
Weāre working on releasing a self-hosted Python version in the next few weeks on our GitHub repo: https://github.com/leapingio/leaping (right now itās just the demo source code). This is just the first step towards a larger goal, so weād love to hear any and all feedback/questions, or feel free to shoot me an email at [email protected]!
What are some alternatives?
react-flow - React Flow |Ā Svelte Flow - Powerful open source libraries for building node-based UIs with React (https://reactflow.dev) or Svelte (https://svelteflow.dev). Ready out-of-the-box and infinitely customizable. [Moved to: https://github.com/xyflow/xyflow]
spring-ai - An Application Framework for AI Engineering
Drawflow - Simple flow library š„ļøš±ļø
jsplumb - Visual connectivity for webapps
vite-svg-loader - Vite plugin to load SVG files as Vue components
X6 - š JavaScript diagramming library that uses SVG and HTML for rendering.
wavedrom - :ocean: Digital timing diagram rendering engine
DrawThe.Net - drawthe.net draws network diagrams dynamically from a text file describing the placement, layout and icons. Given a yaml file describing the hierarchy of the network and it's connections, a resulting diagram will be created.
hook-flow - A flowchart that explains the new lifecycle of a Hooks component. https://dwe.st/hf
panzoom - Universal pan and zoom library (DOM, SVG, Custom)
react-treebeard - React Tree View Component. Data-Driven, Fast, Efficient and Customisable.
React - The library for web and native user interfaces.