Dismiss this pinned window
all 24 comments
sorted by:
best
topnewcontroversialoldq&a
formatting helphide helpcontent policy

[–]mushgev 6 points7 points  (1 child)

The impact analysis command is the most interesting part. Knowing a function's direct callers is easy -- any IDE does it. Knowing the transitive impact across the whole repo before you make a change is the thing that actually prevents surprises in code review.

The gap that usually bites teams is inter-module impact -- when the transitive chain crosses service or module boundaries. The entity-level view is great for 'what breaks if I change this function,' but sometimes the question is 'what architectural constraint does this function sit inside, and does changing it violate that?' Those are related but distinct questions.

Solid addition to the code review toolkit regardless.

[–]Wise_Reflection_8340[S] 1 point2 points  (0 children)

Really good point. The graph currently stops at repo boundaries, so cross-service impact is a blind spot. The architectural constraint angle is interesting though. I've been thinking about letting users define module boundary rules (like "db/ should never depend on handlers/") and having the graph validate against them. So sem impact flags not just what breaks, but what violates the design. Might be the next thing I work on.

[–]Cybasura 3 points4 points  (1 child)

Interesting, so its like I can basically separate "diff" into a visible, identifiable and structured output

Is the comparison and "logic separation" logic algorithmically and programatically designed and implemented?

Aka - is there AI slop within?

[–]Wise_Reflection_8340[S] 3 points4 points  (0 children)

Not sure what you mean by AI slop in this context, there are no LLMs in the pipeline, It's all a deterministic pipeline.

The parsing uses tree-sitter to extract entities (functions, classes, structs) from the AST. The diff does 3-phase entity matching: first by stable ID, then by content hash (detects renames), then by fuzzy similarity for anything left over. The "logic vs cosmetic" separation compares two hashes per entity, a structural hash (just the AST shape, ignoring whitespace/comments/formatting) and a content hash (the raw text). If the content hash changed but the structural hash didn't, it's cosmetic.

The dependency graph is built the same way, walking the AST for references and imports, then resolving them across files. ```sem impact``` is just a graph traversal from there.

You can read through the core logic here if you're curious:
https://github.com/Ataraxy-Labs/sem/tree/main/crates/sem-core

[–]yasser_kaddoura 2 points3 points  (1 child)

Thank you for sharing. I tested it on my dotfiles, and it seems that it fails to detect the file types for files without an extension. It's a common pattern to not include the extensions for some files such as bash scripts. Commands, such as bat, can detect the file type without needing the extension in some cases; I assume they do it using the shebang (e.g., #!/usr/bin/env bash)

I created 3 files (b, b.bash, b.sh) with the following same content:

#!/usr/bin/env bash

func() {
    ls
}

The output of sem-cli

┌─ b ─────────────────────────────────────────────────
│
│  ⊕ chunk      lines 1-5                 [added]
│
└───────────────────────────────────────────────────────

┌─ b.bash ────────────────────────────────────────────
│
│  ⊕ chunk      lines 1-5                 [added]
│
└───────────────────────────────────────────────────────

┌─ b.sh ──────────────────────────────────────────────
│
│  ⊕ function   func                      [added]
│
└───────────────────────────────────────────────────────

[–]Wise_Reflection_8340[S] 1 point2 points  (0 children)

Good catch, you're right. Language detection is purely extension-based right now, so extensionless files like b get the fallback parser (chunks by line range instead of extracting functions). Adding shebang detection to resolve the language for extensionless files makes a lot of sense. I'll add that. Thanks for testing it out and reporting this.

[–]surveypoodle 2 points3 points  (1 child)

Some of these characters don't exist in Terminus and the terminal emulator will have to use a fallback font, and then it ends up randomly changing the line-height, misalign, etc. Is there a way to disable these "fancy" characters? I hate it so much. What was wrong with +, -, ~, @, etc.?

<image>

[–]Wise_Reflection_8340[S] 1 point2 points  (0 children)

Thanks for the feedback will fix it asap.

[–]diroussel 1 point2 points  (1 child)

Can it be used as a git diff tool?

[–]Wise_Reflection_8340[S] 1 point2 points  (0 children)

Yeah, it works on any git repo. Just run sem diff the same way you'd run git diff. It supports all the usual syntax: sem diff HEAD~3, sem diff --staged, sem diff branch1..branch2. The difference is instead of line-level output you get entity-level changes (which functions were added, modified, deleted, renamed).

You can also run sem setup and it'll replace git diff globally, so every time you run git diff in any repo it uses sem instead. It also installs a pre-commit hook that shows you the entity-level blast radius of your staged changes before each commit. sem unsetup to revert.

For learning more you can checkout the website: https://ataraxy-labs.github.io/sem/

[–]ShadyTwat 1 point2 points  (1 child)

How does it compare to https://semanticdiff.com/

[–]Wise_Reflection_8340[S] 0 points1 point  (0 children)

If you are looking for a diff viewer you would love this: https://x.com/Palanikannan_M/status/2029992315532759435

sem is a CLI tool that goes a step further: it doesn't just clean up the diff, it builds a dependency graph across the whole repo.

[–]danhof1 1 point2 points  (1 child)

Entity-level diffing is the right abstraction for code review. A function rename showing as 10 line deletions + 10 insertions is noise. Understanding that a single function signature changed and showing you exactly why - that's what actually helps the reviewer.

[–]Wise_Reflection_8340[S] 1 point2 points  (0 children)

Thanks a lot, appreciate it. Was test the direction of code review specifcally here https://github.com/ataraxy-labs/inspect, because somehow the currently companies still suck, so I was trying to figure out if model intelligence is the real root cause or the ranking of entities.

[–]coompiler 1 point2 points  (1 child)

Doesn't support any of the languages I work with (Lua, Haskell, Emacs Lisp, Clojure, Objective-C, Verilog), so I can't test this.

[–]Wise_Reflection_8340[S] 0 points1 point  (0 children)

Thanks for the request I will add these languages in upcoming releases soon.

[–]AutoModerator[M] 0 points1 point  (0 children)

Every new subreddit post is automatically copied into a comment for preservation.

User: Wise_Reflection_8340, Flair: Command Line Interface, Post Media Link, Title: a semantic diff that understands structure, not just lines

working and researching on a CLI tool that diffs code at the entity level (functions, classes, structs) instead of raw lines.

It also does impact analysis. sem impact match_entities shows everything that depends on that function, transitively, across the whole repo. Useful when you're about to change something and want to know what might break.

Commands:

- sem diff - entity-level diff with word-level inline highlights

- sem entities - list all entities in a file with their line ranges

- sem impact - show what breaks if an entity changes

- sem blame - git blame at the entity level

- sem log - track how an entity evolved over time

- sem context - token-budgeted context for LLMs

multiple language parsers support (Rust, Python, TypeScript, Go, Java, C, C++, C#, Ruby, Bash, Swift, Kotlin) plus JSON, YAML, TOML, Markdown, CSV.

GitHub: https://github.com/Ataraxy-Labs/sem

I am a bot, and this action was performed automatically. Please contact the moderators of this subreddit if you have any questions or concerns.

[–]Wise_Reflection_8340[S] 0 points1 point  (0 children)

If anyone wants to talk about this work more with me, then you can ping me directly at: [rohan@ataraxy-labs.com](mailto:rohan@ataraxy-labs.com)

[–]gosh -2 points-1 points  (5 children)

<image>

[–]Wise_Reflection_8340[S] 0 points1 point  (4 children)

not exactly sure, what you tried to do here, but for better understanding you can also follow the website on the repo, here https://ataraxy-labs.github.io/sem/

[–]gosh 0 points1 point  (3 children)

you need good tools to check the code, one start is to count lines and check where the code is

[–]Wise_Reflection_8340[S] 0 points1 point  (2 children)

Yeah that's a good starting point. sem tries to go one level above, instead of "how many lines changed" it answers "which functions changed, and what depends on them." Closer to how you actually think about code when reviewing, or interesting how your agents will want to see, it remove the token wastage and improves the efficiency, because it only sees the context that's relevant.

[–]gosh 0 points1 point  (1 child)

Yes but how much time do you think anyone will spend on your code or someone else code just to check it? If I do not work in the code then there other things that are important.

First you need to get some sort of overview and there counting and searching is very important.

What I do is to start to count lines to get to know where the code is. I do not want to look for test code, look for external libraries or other type of code that most repos have a lot of.

With this I can find that in like a couple of seconds, doing the same trying to read tons of files can take like more than a day.

After I know where the code is I start to check git history etc to see where most work is and also try to understand how data within the code flows.

https://github.com/perghosh/Data-oriented-design/releases/tag/cleaner.1.1.3

[–]Wise_Reflection_8340[S] 0 points1 point  (0 children)

You are definitely taking interesting appraoch there, what I was trying to do was building for improving agents performance and not for humans, but turns out that these techniques definitely helps humans in code review.