Here's `pdf-redact-tools` from Homebrew: https://github.com/kach/tower-of-power/blob/master/gallery/p...
Here's the CS core at Stanford (dependency = prereq): https://github.com/kach/tower-of-power/blob/master/gallery/c...
Here's `pdf-redact-tools` from Homebrew: https://github.com/kach/tower-of-power/blob/master/gallery/p...
Here's the CS core at Stanford (dependency = prereq): https://github.com/kach/tower-of-power/blob/master/gallery/c...
Edit: partly because I also know the original author was denied a job at Google. Imagine the productivity gain this team has given to a company the size of google.
https://www.propublica.org/article/the-worlds-email-encrypti...
But I also remember the takedown about no one actually relying on email encryption for security:
https://news.ycombinator.com/item?id=3080437
Voluntarily maintained by a single person for decades until hit by a big lawsuit and ICANN stepped up to help.
Yes, it's an important piece of software. But it's not "required" for any services itself.
Probably, however, the graph would horrify me as well.
https://npm.anvaka.com/#!/view/2d/webpack
And yes, the dependency chains become absolutely insane for some projects.
That's a nice instance of literate programming. I don't come across those very often.
Click "Raw" to see the image
digraph G {
a -> {x y z}
b -> {x y z}
c -> {x y z}
}
cannot be drawn on the plane without any crossings.Suppose we have two components-- X and Y-- which depend on two other lower-level components-- A and B. How would you draw this as a block dependency diagram without repetition?
If both X and Y depend on B, then X and Y must be above B, and both touch B. If X and Y are orthogonal rectangles, then the entire X-Y edge is obscured from below. This means that another lower-level component A must can only interact with either X or Y. You'd need to allow X or Y to no longer be orthogonal rectangles to overcome this, or need to give up on the vertical organization of dependencies.
1->2; 1->4; 2->3; 3->4
Unless 4 is slanted.