It's amazingly awkward to print a syntactic diff correctly. Even the lines before and after the changes may not line up, if whitespace has changed!
Difftastic now inserts blank lines to help things line up. I'm reasonably happy with the result here.
Haskell Wingman is a fun project that provides hole-based refinement to any editor that speaks LSP!
It's a great example of how to describe complex features in terms of user benefit too.
https://haskellwingman.dev/
I've been playing with 'sliders' in difftastic, the classic diff problem where you highlight an adjacent value that is correct but weird.
I've taught difftastic to penalise sequences across newlines. This largely works, but it hurts perf (another degree of freedom to solve).
Interactive Sokoban, the 2D logic puzzle, on a non-Euclidean surface:
https://sokyokuban.com/
Snorkel is a project that encourages you to build heuristic functions to train a ML model on. It's a clever alternative to manually labelling data.
https://www.snorkel.org/use-cases/01-spam-tutorial
Sadly `git difftool` invokes your tool once per file. This makes it hard to print whitespace between files.
I'm experimenting with adding an extra newline at the end of output, but it feels a bit untidy for the single file case.
Difftastic update: I've rewritten the tree diffing logic to use Dijkstra's algorithm similar to Autochrome.
It works amazingly well! Note how it recognises both parent and children unchanged nodes in the lisp example. You can even see me refactoring Rust to use if-let.
Neat GitHub feature I haven't seen before: if the contributing guide has changed since your last pull request, it tells you!
Plain data in Rust can be surprisingly verbose.
I thought I wanted:
enum Action { Changed, Unchanged }
but it turned out I wanted this instead:
#[derive(Debug, Copy, Clone, PartialEq, Eq, Hash)]
enum Action { Changed, Unchanged }
I wrote a non-trivial graph algorithm and it worked first time!
I was suspicious until I tried it on a three node graph and was kinda comforted to learn it still had bugs.
I'm not convinced that offering the staging area is a good default for git.
It's an abstraction that newcomers have to learn before their first commit. Subversion style "commit every tracked file" isn't as pretty (`git add` is general) but it's the common case.
I'm reading papers about tree diff techniques, to try to improve my structural diff tool.
Most papers focus on diffing XML. Their techniques are clever and relevant, but crikey some of the intro quotes really haven't aged well.
On building intuitions on monads and functors:
https://www.jerf.org/iri/post/2958
(Also, TIL that the function type is a functor in Haskell!)
Nix and patching the Linux kernel whilst still tracking upstream packages:
https://zeroindexed.com/nix-ejection-problem
Readable tree diffing is a really interesting problem. When do you highlight lists? Do you highlight all the lists enclosing a modified subtree? What about comments?
I'm relatively happy with this case, but I think the outermost lists shouldn't be highlighted at all.
My new diff tool is now sufficiently feature complete that it can diff its own source code!
I've found a bunch of new bugs, but that's dogfooding :)
Butter, an experimental programming language exploring ideas for low level efficiency, has one of the best looking roadmaps I've seen in a long time!
Smart appliances with internet connections often have all sorts of security issues, privacy issues, etc.
They'd be a huge help when daylight savings time occurs though. That almost makes up for it.
Still tinkering with tree diff heuristics. Sometimes it works really well, but other times it's too keen to match up lists.
I'm still trying to find a colour scheme I like for my diff tool. I need two different styles: added code should be more prominent than moved code.
ANSI colours are extremely limited, so I tried using green / green background. Using bold and bright green seems to work better.
Showing 1,041-1,060 of 7,508 posts
