rs545837

5 ms·

1. 31.▲
   by rs545837 7mo ago

   Fair point on AST vs semantic. sem sits somewhere in between. It doesn't go as far as checking compiled output equivalence, but it does normalize the AST before hashing (we call it structural_hash), so purely cosmetic changes like refo
2. 32.▲
   by rs545837 7mo ago

   Could you comment here on the PR( https://github.com/jj-vcs/jj/pull/8833 ) if you want this integrated with jj
3. 33.▲
   by rs545837 7mo ago

   Didn't get what you are saying with mergigraf? I actually did mention about the granularity on which weave works on, in the X thread
4. 34.▲
   by rs545837 7mo ago

   For comments: weave bundles doc comments (JSDoc, ///, /* */, etc.) with the entity they belong to. So if one branch edits a doc comment and another edits the function body, they merge as part of the same entity. Sta
5. 35.▲
   by rs545837 7mo ago

   You will love this because we are supporting bash tree sitter grammar now with weave.
6. 36.▲
   by rs545837 7mo ago

   Thanks for the feedback, pumped up to hear that.
7. 37.▲
   Sem – Semantic Diff behind the new viral merge algo Weave(github.com)

   10 points by rs545837 7mo ago|1 comments
8. 38.▲
   by rs545837 7mo ago

   It's crazy of how we never changed the standard how we have viewed diffs in last 30 years. It's cumbersome and becomes a really cool area when you start looking it in the entity sense both in terms of semantic info and intention o
9. 39.▲
   by rs545837 7mo ago

   Thanks for notifying, I will update it. So we use a language specific parser called sem here: https://ataraxy-labs.github.io/sem/ , you can use all the languages listed here in weave, its a seperate library. So if you wa
10. 40.▲
    by rs545837 7mo ago

    Prevention better than cure, haha, that's exactly why weave ships an MCP server alongside the merge driver.
11. 41.▲
    by rs545837 7mo ago

    Source code is already a serialization of an AST, we just forgot that and started treating it as text. The practical problem is adoption: every tool in the ecosystem reads bytes.
12. 42.▲
    by rs545837 7mo ago

    interesting read, will comment more once I go through everything in detail. Thanks.
13. 43.▲
    by rs545837 7mo ago

    Good framing. Source code is already a serialization of an AST, we just forgot that and started treating it as text. The practical problem is adoption: every tool in the ecosystem reads bytes.
14. 44.▲
    by rs545837 7mo ago

    Yeah we are focusing on all these directions, could you also open up issues, if you want some specific things, helps us a lot in tracking issues.
15. 45.▲
    by rs545837 7mo ago

    CSTs are the right call for round-tripping, but isn't that essentially what tree-sitter gives you, a concrete syntax tree that preserves whitespace, comments, and formatting.
16. 46.▲
    by rs545837 7mo ago

    I had conversations with Martin, He just wants people asking for weave in their community, once people start doing it, we both can work on the integration then.
17. 47.▲
    by rs545837 7mo ago

    Yeah I am actually super excited for these new kind of innovations. These things are genuinely not letting me sleep these days.
18. 48.▲
    by rs545837 7mo ago

    Email conversations with Elijah and Taylor are private. Martin commented on our X post that went viral, and suggested a new benchmark design.
19. 49.▲
    by rs545837 7mo ago

    Thanks for the great explaination again.
20. 50.▲
    by rs545837 7mo ago

    This is exactly the use case, thanks for explaining.
21. 51.▲
    by rs545837 7mo ago

    Thanks for sharing the website as well here. Appreciate it!
22. 52.▲
    by rs545837 7mo ago

    Interesting idea. Tree-sitter's trade-off (speed + incrementality over completeness) makes sense for editors but you're right that for merge/diff a more thorough parser could be worth the cost since it's a cold path, not
23. 53.▲
    by rs545837 7mo ago

    This is actually cool, gonna check it out.
24. 54.▲
    by rs545837 7mo ago

    you made me emotional!
25. 55.▲
    by rs545837 7mo ago

    You're right, that's a real risk, weave runs post-merge validation for exactly this, it checks entity dependencies after merge, so if one side obsoletes what the other side depends on, it warns you even when the textual merge is c
26. 56.▲
    by rs545837 7mo ago

    That's exactly what inspect does ( https://github.com/ataraxy-labs/inspect ). It uses sem's entity graph to triage PRs: classifies every change, scores risk based on blast radius and dependents, and groups rela
27. 57.▲
    by rs545837 7mo ago

    When you start seeing the diffs with entities instead of lines, is what interests me, you get much better semantic info. If you have a language specific parser, you can make a merge algorithm like weave. But the bigger win isn't resol
28. 58.▲
    by rs545837 7mo ago

    C# is supported! It goes through sem-core's(the underlying library for parsing we use in Weave) tree-sitter-c-sharp plugin. Classes, methods, interfaces, enums, structs are all extracted with it. Let me know if you hit anything.
29. 59.▲
    by rs545837 7mo ago

    Thanks a lot! Appreciate it.
30. 60.▲
    by rs545837 7mo ago

    No it was meant to be here, I don't like reddit as much as I love HN.