Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Difftastic: A diff that understands syntax

github.com

Post reply on HN
Print view View original

211–220 of 224 posts

Re: Difftastic: A diff that understands syntax

#211

Post by tomatowurst »

emacsen wrote: post #5

This looks absolutely amazing. One thing I do find interesting (and a wish were different) is that only programming languages are supported, rather than data formats as well. For example, two JSON documents may be valid but formatted slightly differently, or a common task for me is comparing two YAML files. Comparing config files that have a well defined syntax and or can be abstracted into a tree (JSON, YAML, TOML,…

same, I don't know how many times I do a diff and wish there was a smarter solution that could take account formatting and whitespaces. This is it. Wish git diff would incorporate this, would be a real treat.

Re: Difftastic: A diff that understands syntax

#212

Post by goombacloud »

SuperSandro2000 wrote: post #202

Delta is a pager that does Syntax highliting, better diff highliting and improved outputs of existing git commands. Highly recommended. https://github.com/dandavison/delta

I find ydiff more useful, specially for the side-by-side output: https://github.com/ymattw/ydiff

I'm using it like "git-ydiff-s" script in my PATH to use "git ydiff-s":

    #!/bin/sh
    git diff "$@" | ydiff -s --wrap --width=0
Installation is "sudo dnf install ydiff" or curl -fsSL https://raw.github.com/ymattw/ydiff/master/ydiff.py > ~/bin/ydiff chmod +x ~/bin/ydiff # (and change to python3)

Re: Difftastic: A diff that understands syntax

#213

Post by ninkendo »

chockchocschoir wrote: post #81
simonw wrote: post #60

Earlier quoted context omitted.

I would naively expect that this problem is easiest to solve for languages like JSON that have an unambiguous way to be pretty printed.

Indeed. One could just do `diff $(jq . $fileOne) $(jq . $fileTwo)` and you'll end up with a "nice enough" diff even if $fileOne and $fileTwo were very differently formatted.

Nitpick: diff takes filenames as arguments, so comparing the output of two commands would need the `<()` expansion. So the command would be `diff <(jq . $fileOne) <(jq . $fileTwo)`

Re: Difftastic: A diff that understands syntax

#214

Post by danbruc »

jhgb wrote: post #138
danbruc wrote: post #134

Earlier quoted context omitted.

So I can only use the diff tool to compare two non-compiling versions of a source file if I provide a test suite for that file to the diff tool? And how would you want to make use of the test suite? Before you can run the test suite, the source file must already parse and compile which is already more than a diff tool based on a syntax tree requires - it must be able to parse the source code but it doesn't have to co…

> So I can only use the diff tool to compare two non-compiling versions of a source file if I provide a test suite for that file to the diff tool? Not sure what this whole straw man is about. I definitely didn't suggest anything like that. Of course you can only compare two compiling versions of a source file using a test-suite-based heuristics. I thought this whole thing was about "heuristics that identify reasonabl…

We have obviously been taking past each other. My point was that a parser for a syntax tree based diff tool should probably be able to deal well with files with syntax errors, i.e. it must be able to fix syntax errors. And with fixing syntax errors I did not mean actually fixing the file but being able to construct a reasonable syntax tree even if some subtrees do not adhere to the grammar. Given an input like

  class foo
  {
    function bar() {
    function baz() { }
  }
it should be able to parse the file as if bar() was not missing the closing curly brace. If the parser just gave up or inserted the closing curly brace at the end

  class foo
  {
    function bar() {
    function baz() { }
  }
  }
making baz() a nested function inside of bar() the result would be worse than using a character-based diff algorithm. But I never intended to say anything about making code functionally correct, that is none of the business of a parser or diff algorithm.

Re: Difftastic: A diff that understands syntax

#215

Post by estebank »

loxias wrote: post #22

This looks really cool and I can't wait to try it, tho... a bit of a PITA to get running. ;) Took a while to figure out how to build, and had to install 400MB of dependencies first.... Edit: And after installing cargo, watching it fail to build, then determining I must need a newer version of cargo, so I built that from source... it fails. Apparently I need to install `rustc-mozilla` and not `rustc`. "obviously". Thi…

Honest question: how did you arrive to the conclusion you needed rustc-mozilla? I would love to make sure whatever flow led you to that is made clearer for other newcomers, because that is definitely not something anyone that isn't working on Firefox should even try.

Re: Difftastic: A diff that understands syntax

#216

Post by jbrr25 »

ducktective wrote: post #150
adwn wrote: post #139

Earlier quoted context omitted.

In another comment you're asking about vim support. So let me get this straight: You're using vim, yet you're unable to resolve the error message = note: /usr/bin/ld: cannot find Scrt1.o: No such file or directory /usr/bin/ld: cannot find crti.o: No such file or directory Have you tried googling for "ubuntu crti.o: No such file or directory" ?

>Have you tried googling for "ubuntu crti.o: No such file or directory" ? Depending on the project, there is a certain threshold of trying-to-make-something-work which I'm willing to undertake in order to test an app. But you are right. I'm sorry if my OG comment may come arrogant to the devs who do stuff for free. (♥ to the devs) [edit]: ok, I tried again, `sudo apt update && sudo apt install build-essential` before…

The GCC version in Ubuntu 18.04 is too old. I had the same problem, I just installed clang, updated the default c++ and it worked. There is an issue in the repo about that.

Re: Difftastic: A diff that understands syntax

#217

Post by vcmiraldo »

narush wrote: post #25
vcmiraldo wrote: post #10

I really like the idea of focusing on producing patches for human consumption. I studied the problem of merging AST-level patches during my PhD ( https://github.com/VictorCMiraldo/hdiff ) and can confirm: not simple! :)

Can you give a little color on where the difficulties lie? Is it an efficiency question, or is determining "which changes" hard in the first place?

Efficiency is not the issue at this point. My prototype diffing algorithm was linear and there have been improvements on it already (I think something called "truediff" is linear but an order of magnitude better! I could be misremembering the name, don't quote me :) ).

The real difficult part is in how you represent AST-level changes, which will limit what your merging algorithm can do. In particular, working around moving "the same subtree" into different places is difficult. Imagine the following conflict:

([1,3], [4,2,5]) ([1,3], [2,4,5])

Both p and q move the same thing to different places so they need a human to make a decision about what's the correct merge. Depending on your choice of "what is a change", even detecting this type of conflict will be difficult. And that's because we didn't add insertions nor deletions. Because now, say p was:

([1,2,3], [4,5]) -- p --> ([1,3], [2,5])

One could argue that we can now merge, because '4' was also deleted hence the position in which we insert '2' in the second list is irrelevant.

If we extrapolate from lists of integers to arbitrary ASTs the difficulties become even worse :)

Re: Difftastic: A diff that understands syntax

#218

Post by vcmiraldo »

arianvanp wrote: post #172
einpoklum wrote: post #159

Earlier quoted context omitted.

So I looked at the paper and it seems interesting. Basic idea: Instead of the operations to consider being "insert", "delete" and "copy", one adds "reorder" "contract subtree" and "duplicate" (although I didn't quite get the subtlety of copy vs duplicate on a short skim); and even though extra ops increase the search space, they actually let you search more effectively. I can buy that argument. The practical problem,…

Some of the GHC performance bugs that we ran into during the research have been fixed as far as I know! Though I'd have to double-check

Indeed, we also designed a brand new generics library to work around that. Performance was really not an issue! :)

Re: Difftastic: A diff that understands syntax

#219

Post by vcmiraldo »

stavros wrote: post #185
vcmiraldo wrote: post #10

I really like the idea of focusing on producing patches for human consumption. I studied the problem of merging AST-level patches during my PhD ( https://github.com/VictorCMiraldo/hdiff ) and can confirm: not simple! :)

Please tell me the final output of your PhD was a differtation.

omg!! I really should have left that typo somewhere in there! What a missed opportunity! xD

Re: Difftastic: A diff that understands syntax

#220

Post by vcmiraldo »

einpoklum wrote: post #159
vcmiraldo wrote: post #10

I really like the idea of focusing on producing patches for human consumption. I studied the problem of merging AST-level patches during my PhD ( https://github.com/VictorCMiraldo/hdiff ) and can confirm: not simple! :)

So I looked at the paper and it seems interesting. Basic idea: Instead of the operations to consider being "insert", "delete" and "copy", one adds "reorder" "contract subtree" and "duplicate" (although I didn't quite get the subtlety of copy vs duplicate on a short skim); and even though extra ops increase the search space, they actually let you search more effectively. I can buy that argument. The practical problem,…

Copy just copies once. The need for duplicate is clear if you're trying to diff something like `t = [a]` and `u = [a, a]`. You could copy `a`, but you'd have to decide whether to copy it on the first or second position; the second one would be classified an "insertion" by any ins/del/cpy-algorithm. If you instead opt to NOT make that choice, you can say: pick the source `a` and duplicate it instead
Post reply on HN