Live data from Hacker News

Graphtage: A semantic diff utility for JSON, HTML, YAML, CSV, etc

github.com

1–10 of 52 posts

Re: Graphtage: A semantic diff utility for JSON, HTML, YAML, CSV, etc

#3

Interesting use of U+031F COMBINING PLUS SIGN BELOW to indicate additions, I don't think I've seen that before.

I think it's really cool as well. Although, it does start to look a little wonky with quotes and probably some other characters and makes skimming a bit harder. Maybe monospaced fonts will start to handle this better if it gets popular?

Re: Graphtage: A semantic diff utility for JSON, HTML, YAML, CSV, etc

#4
post #3

Interesting use of U+031F COMBINING PLUS SIGN BELOW to indicate additions, I don't think I've seen that before.

I think it's really cool as well. Although, it does start to look a little wonky with quotes and probably some other characters and makes skimming a bit harder. Maybe monospaced fonts will start to handle this better if it gets popular?

Ruby typography support in terminals maybe?

Re: Graphtage: A semantic diff utility for JSON, HTML, YAML, CSV, etc

#5

Interesting use of U+031F COMBINING PLUS SIGN BELOW to indicate additions, I don't think I've seen that before.

It's the kind of UI experimentation I like to see people try, but I'm not sure they nailed this one.

Probably onto something though. Try different diacritical symbols and see what sticks. Given how '"' looks, maybe combining above or below needs to vary by character. Above probably looks awful for '.' and ','.

Really I think the strikethrough might suffice. The only way to know for sure is to take away the color highlighting, so my brain doesn't use it as a crutch, and see if people can still read the diff.

Re: Graphtage: A semantic diff utility for JSON, HTML, YAML, CSV, etc

#8

It's cool, but does seem quite slow. I'm diffing two 45kB CSVs on a fast computer and after 10 minutes I'm still at: Diffing: 0% ... 0/93195 [00:00

30 minutes in and I still don't have a diff of the two CSVs... Has this program worked for anyone here?

    Diffing:   0%|                                | 153/93195 [30:02

Re: Graphtage: A semantic diff utility for JSON, HTML, YAML, CSV, etc

#9
> Graphtage matches ordered sequences like lists using an “online”[note], “constructive”[note] implementation of the Levenshtein distance metric[note], similar to the Wagner–Fischer algorithm[note[. The algorithm starts with an unbounded mapping and iteratively improves it until the bounds converge, at which point the optimal edit sequence is discovered. This is implemented in the graphtage.levenshtein module.

https://trailofbits.github.io/graphtage/latest/howitworks.ht...

So not a tree algo, but an adaptation of a list-diff algo? Or is this just a note on how the tree-diff compares sequences?

Re: Graphtage: A semantic diff utility for JSON, HTML, YAML, CSV, etc

#10

It's cool, but does seem quite slow. I'm diffing two 45kB CSVs on a fast computer and after 10 minutes I'm still at: Diffing: 0% ... 0/93195 [00:00

I think it’s ended up with a quadratic algorithm for diffing sequences and a quadratic log algorithm for diffing dictionaries.

To understand why the sequences problem is quadratic, consider a sequence A of length m being doffed with a sequence B of length n. We want to express our diff in the minimum number of operations where an operation is removing, adding, or editing an element in the sequence. Construct a graph as follows: the nodes will be the points on an mxn lattice corresponding to points in the two sequences. An edge going right means “delete this item from sequence A,” and costs (eg 1). An edge going down means “add this item from sequence B” and has a similar cost. An edge going diagonally down and right means to edit the item in A into the item in B and it’s cost depends on how different they are. The problem is to find the shortest path from the top left to the bottom right.

If you could compute the entire graph for free and then applied something like Dijkstra’s algorithm you would be worst-case quadratic (if all the diagonal costs were 2 or more, you would need to touch every node).

There are a few ways you could try to improve this:

1. Look for easy opportunities to optimise. Eg you could have a patience style strategy of cutting off any common prefix or suffix. This won’t help in the worst case.

2. Limit to a fixed width diagonal. This might mean worse diffs but means the graph search problem becomes more linear. I suspect something is going on with the diagonal based on the description

3. Somehow develop some good heuristics and use a better search algorithm like A*. This might not help in the worst case

4. Something else.

Post reply on HN