Live data from Hacker News

Difftastic: A diff that understands syntax

github.com

131–140 of 224 posts

Re: Difftastic: A diff that understands syntax

#131
post #53

I would love it if version control stored an AST that also includes comments and dividers (where right now we would leave an empty line) and dev machines rendered it out however they wanted. They could even change the language of keywords in addition to normal formatting.

FWIW VCS for Smalltalk basically does this.

The challenge for a tool like difftastic is that I can't guarantee that syntax is well-formed. You might be using new syntax that my parser doesn't support, you might have merge conflicts, or you might have a plain syntax error in your code.

Tree-sitter handles parse errors gracefully, so difftastic handles syntax errors pretty well in my experience.

Re: Difftastic: A diff that understands syntax

#132
post #106

Earlier quoted context omitted.

The method I posted above doesn't write anything to /usr/local. Root isn't required. Everything is written under ~.

Whoa really? I'm sorry, and retract my ignorant assumption! Going to try it out now.

There are a few packages available, e.g. https://aur.archlinux.org/packages/difftastic and https://pkgsrc.se/wip/difftastic.

I've also had requests from Alpine Linux packagers to allow dynamic linking to parsers. This is something I want to support in future, once I'm happy with the basic diffing logic.

Re: Difftastic: A diff that understands syntax

#133

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! :)

Should've named that repo "phdiff".

I'll vote for "diphph"

Re: Difftastic: A diff that understands syntax

#134
post #125

Earlier quoted context omitted.

I am still lost. Test suite for what? We have a parser - binary, source code and maybe a test suite if the parser developers decided to write tests - and a random text file that we throw at the parser and for which the parser hopefully generates a useful syntax tree if the content is a well-formed or not too badly malformed program in a language the parser understands.

What "test suite for the parser"? Of course a test suite for the faulty program you're trying to correct into a working one.

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 compile. Passing the test suite requires even more, not only being able to parse and compile but also yield the correct behavior which the diff tool doesn't care about.

And you actually jumped over the hard part that requires the heuristics, how to modify the input in order to make it parse. Take a 10 kB source file and delete 10 random characters - how will you figure out which characters to put back where? With 100 possible characters, 10,000 positions to insert a character, and having to insert 10 characters, you are looking at something like 10^60 possible modifications. You are certainly not going to try them one after another, each time checking if the modified source file parses, compiles, and passes the test suite.

Re: Difftastic: A diff that understands syntax

#135
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,…

I would love a great XML diff tool, and after seeing the demo of this I was sad to see XML not in there. Would pay for.

Re: Difftastic: A diff that understands syntax

#136
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…

Same here. Looked into repo -> no binary in release or Github actions

spinned up a Ubuntu 18.04 instance -> git clone, git checkout 0.24.0

installed rust using curl | sh method

build fails:

https://termbin.com/29xy

removed the instance and gonna check it again 6 months later

Re: Difftastic: A diff that understands syntax

#138
post #125

Earlier quoted context omitted.

What "test suite for the parser"? Of course a test suite for the faulty program you're trying to correct into a working one.

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 reasonable changes which fix the file" mentioned above? "Reasonable changes that DON'T fix the file" are clearly recognizable by NOT passing the test suite, just as if it was a human trying to make those changes and finding out that the change that he just did didn't in fact yield the desired results after running the test suite.

> With 100 possible characters, 10,000 positions to insert a character, and having to insert 10 characters, you are looking at something like 10^60 possible modifications.

If you're working with an AST, you're almost certainly not working with characters. That would be immensely wasteful. In fact working with an AST is pretty much the only way in which the set of changes is sufficiently reduced for almost any change to NOT be rejected outright. With character-level modifications, you're facing the problem that almost every edit will be outright rejected as early as at the stage of parsing.

Re: Difftastic: A diff that understands syntax

#139
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…

Same here. Looked into repo -> no binary in release or Github actions spinned up a Ubuntu 18.04 instance -> git clone, git checkout 0.24.0 installed rust using curl | sh method build fails: https://termbin.com/29xy removed the instance and gonna check it again 6 months later

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" ?
Post reply on HN