leaping
difftastic
leaping | difftastic | |
---|---|---|
4 | 68 | |
248 | 19,694 | |
17.3% | - | |
2.9 | 9.9 | |
about 2 months ago | 5 days ago | |
Python | Rust | |
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.
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]!
difftastic
-
Linus Torvalds adds arbitrary tabs to kernel code
i want a diff tool that shows me exactly which tokens have changed, and which haven't, regardless of how they are laid out.
These already exist: https://github.com/Wilfred/difftastic
when we get that, then we should get even less merge conflicts.
Counterintuitively, that is not the case. AST-merge is a much, much, much, much, much harder problem than AST-diff.
https://github.com/Wilfred/difftastic?tab=readme-ov-file#can...
The fact that diffs can be used to drive a 3-way merge is in fact an accidental property that arises due to the sheer crudeness of the diff format. As soon as you start using more-sophisticated diff formats, solutions to "the diff problem" no longer lead directly to solutions to "the merge problem".
- FLaNK AI Weekly 25 March 2025
-
Difftastic, a structural diff tool that understands syntax
Yes there is an `ā-override` option you can use to specify the language in which a file should be parsed.
https://github.com/Wilfred/difftastic/blob/master/CHANGELOG....
-
So You Think You Know Git ā Git Tips and Tricks by Scott Chacon
Use the fantastic difftastic instead of git's diff. https://difftastic.wilfred.me.uk/
[alias]
- Difftastic: A structural diff tool that understands syntax
-
SemanticDiff now supports Rust
difftastic provides similar capabilities in a free tool based on treesitter
-
My programming language aware diff for VS Code and GitHub now supports Rust
difftastic? https://github.com/Wilfred/difftastic
-
Prettier $20k Bounty was Claimed
If you're looking for a VS Code extension or a GitHub app, check out https://semanticdiff.com/. I'm a co-founder of this project.
If you prefer a CLI tool, check out https://github.com/Wilfred/difftastic. It supports more languages, but doesn't recognize when code has been replaced by an equivalent version ("invariances"). So it will show some changes (e.g. replacing a character in a string with an escape sequence) even though they are technically equivalent.
-
Pijul: Version-Control Post-Git ā¢ Goto 2023
Shameless plug: I've written difftastic[1], a tool that builds ASTs and then does a structural diff of them. You can use it with git too.
It's an incredibly hard problem though, both from a computational complexity point of view, and trying to build a comprehensible UI once you've done the structural AST diff.
[1]: https://github.com/wilfred/difftastic
-
Always leave a trailing comma in Python lists, dicts, tuples
There is a diff tool called difftastic: https://github.com/Wilfred/difftastic
The idea is that it does not show diff based on text change, but on syntastic meaning. For that, it uses tree-sitter.
I think it still shows the trailing comma in the situation as shown in the article, but it's quite different experience than the standard text based diff.
What are some alternatives?
spring-ai - An Application Framework for AI Engineering
delta - A syntax-highlighting pager for git, diff, grep, and blame output
diffsitter - A tree-sitter based AST difftool to get meaningful semantic diffs
neogit - An interactive and powerful Git interface for Neovim, inspired by Magit
Visual Studio Code - Visual Studio Code
gumtree - An awesome code differencing tool
tree-sitter-cpp - C++ grammar for tree-sitter
git-split-diffs - Syntax highlighted side-by-side diffs in your terminal
emacs-diff-ansi
locust - "git diff" over abstract syntax trees
tree-sitter - An incremental parsing system for programming tools
tryceratops - A linter to prevent exception handling antipatterns in Python (limited only for those who like dinosaurs).