Lovely example of using fuel to debug compiler optimisation passes in GHC:
https://blog.ezyang.com/2011/06/debugging-compilers-with-optimization-fuel/
miniblog.
I've released difftastic 0.18! Lots of good stuff in this release:
* Better display: a ton of bugfixes and added support for light terminals
* Improved CLI: better --help and discoverable options
* Small performance and parsing (OCaml, Lisp) fixes
Here's another fun example where syntactic diffing really helps.
Even though the syntax has changed (`attr` was a named argument, now it's a record), the nesting has changed, and the line has changed, difftastic has successfully matched the `attr` in the code afterwards!
TIL that Ada was the result of a language competition, seeking to replace the 450(!) programming languages in use at the department of defence: https://ocw.mit.edu/courses/aeronautics-and-astronautics/16-01-unified-engineering-i-ii-iii-iv-fall-2005-spring-2006/comps-programming/15_robertdewar.pdf
Today I learnt that racing IPv4 and IPv6 connections to use the fastest is called "happy eyeballs" https://en.wikipedia.org/wiki/Happy_Eyeballs
I'm feeling reasonably happy with the light and dark styles of difftastic now: there's a reasonable amount of contrast on both sides.
I'm now using ANSI bright colours for the dark theme and it works pretty well. I had to give up on cyan as it's too pale on light backgrounds.
It is really hard to find good terminal colours for both light and dark themes.
I've replaced uses of 'bright' colours with bold as it seems to work better. git-diff does the same thing.
Explicit black and white colours are available, but you can't assume the default colour!
Cute benchmarking technique for choosing sample programs in a benchmarking suite: perform principal component analysis to avoid redundancy!
https://github.com/bytecodealliance/rfcs/blob/main/accepted/benchmark-suite.md#candidate-benchmark-programs
I've released difftastic 0.17! https://github.com/wilfred/difftastic
This is a small release following a few nasty diffing bugs that slipped into the last version. It also includes syntax highlighting :)
Note how added keywords are in bold, and unchanged comments now have their own colour.
Here's a fun example where a minimal syntactic diff is confusing.
Difftastic has found `args` and `fty.ft_params` occurrences on the right, but it's not terribly useful! It's not even the same `args` as the right hand side is introducing a new binding.
I'm still not sure what I should choose as a minimum supported Rust version for my projects.
The oldest stable version on Debian seems to be 1.41: https://packages.debian.org/stretch/rustc
Excellent collection of advice for building CLI apps in Rust. It's really helpful to see opinions on e.g. should env vars take precedence over CLI arguments.
https://rust-cli-recommendations.sunshowers.io/
@Azure Great website, thanks for sharing :)
Difftastic does syntax highlighting based on tree-sitter's parse of the *whole file*. It's more accurate than most diffs are able to do.
In this hunk, the opening " of the string literal isn't included, but difftastic still knows that the first lines are from a string.
Adding too much coloured highlighting to difftastic kinda makes it hard to spot the changed bits.
I've tried making type names bold (same as keywords) and it looks pretty good though.
Experimenting with syntax highlighting for difftastic.
I'm trying hard to stay within the limited terminal colours. It works everywhere and requires no detection of terminal capabilities or theme.
It's a very limited palette though. Using bold for keywords saves a colour.
Difftastic 0.16 is out! In this release:
* Substantially improved performance (a little over 2x)
* Improvements for Bash, OCaml and JSX
* Added Scala support
* Better handling of diff sliders
I keep getting surprised by .lines() semantics in Rust.
"" -> empty
"foo" -> one line
"foo\n" -> one line
"foo\nbar" -> two lines
I end up using .split('\n') everywhere instead, but .lines() is so convenient it feels like a footgun.
I do wish Rust had a `expect(life()).toEqual(42)` syntax for tests.
`assert_eq!(life(), 42)` just gives "assertion failed: 41 == 42" and it's hard to see which was the expected value. This is particularly hard with larger values.
Diff sliders are a really interesting problem for AST diffs. Here's a surprising example.
At first, it looks like the first `|` should be highlighted. However the first `|` is the outer `match` case, and the inner | is syntactically an or-pattern!
Showing 341-360 of 384 posts