101–110 of 224 posts
I was interested in SemanticMerge/XMerge but when I looked they didn't have a Mac clinet and now it looks like they don't have a personal edition. I just want to buy a private license and use it locally. https://semanticmerge.com
Earlier quoted context omitted.
With only basic knowledge in the domain I would assume it is hard and ugly. If the file is malformed, there is almost certainly an infinite number of possible edits to make the file adhere to the grammar, hence there can not be any algorithm that just provides the one and only correct syntax tree. This in turn means that you have to come up with heuristics that identify reasonable changes which fix the file and that…
"If the file is malformed, there is almost certainly an infinite number of possible edits to make the file adhere to the grammar, hence there can not be any algorithm that just provides the one and only correct syntax tree. This in turn means that you have to come up with heuristics that identify reasonable changes which fix the file and that is probably not easy." Don't we call such heuristics "test suites"?
var foo = bar baz
var foo = barbaz
var foo = "bar baz"
var foo = { bar, baz }
var foo = bar // baz
var foo = bar
//var foo = bar baz
var foo = bar * baz
var foo = bar + baz
var foo = bar.baz
var foo = bar(baz)
var abc = 123
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.
This exact project is called JetBrains MPS.
I was interested in SemanticMerge/XMerge but when I looked they didn't have a Mac clinet and now it looks like they don't have a personal edition. I just want to buy a private license and use it locally. https://semanticmerge.com
They are requesting feedback on the pricing model for the latest revision of the technology, maybe HN could change their minds: https://www.gmaster.io/pricing
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.
Earlier quoted context omitted.
Ah, well, if you're willing to accept having a frankensystem with a mix of packaged and unpackaged software, sure. ;) I used to do that, back in Slackware days. It's considered really sloppy and unmaintainable to admin a system like that. Things quickly get out of hand. That strategy _does_ work if you isolate it to a chroot or a container, but littering /usr/local with all sorts of locally compiled upstream is just…
The method I posted above doesn't write anything to /usr/local. Root isn't required. Everything is written under ~.
I'm sorry, and retract my ignorant assumption! Going to try it out now.
Earlier quoted context omitted.
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?
Not OP, but the docs call out some "Tricky Cases" [1]. [1] https://difftastic.wilfred.me.uk/tricky_cases.html
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,…
For everyone wondering, it looks like this will work with git diff: https://difftastic.wilfred.me.uk/git.html .
Earlier quoted context omitted.
"If the file is malformed, there is almost certainly an infinite number of possible edits to make the file adhere to the grammar, hence there can not be any algorithm that just provides the one and only correct syntax tree. This in turn means that you have to come up with heuristics that identify reasonable changes which fix the file and that is probably not easy." Don't we call such heuristics "test suites"?
I don't understand that question. Given the following source file that does not parse var foo = bar baz there are many ways to change it and make it parse including the following reasonable ones var foo = barbaz var foo = "bar baz" var foo = { bar, baz } var foo = bar // baz var foo = bar //var foo = bar baz var foo = bar * baz var foo = bar + baz var foo = bar.baz var foo = bar(baz) but also unreasonable ones like v…