The ∞ arrows of version control

At the 0th level is a point:

The point is the current state of your source code.

At the 1th level are the arrows:

These are your commits, connected by history.

At the 2th level are the arrows between arrows:

Every time you make a change to your history, such as by creating a new commit, or deleting a commit, you create a new history, linked to the old history with a 2-level arrow.

Most VCSs don't keep track of 2-level arrows, but they could.

At the 3th level are the arrows between 2-level arrows:

You may not see the need for 3-level arrows, but that's because you never work with 2-level arrows. You like 1-level arrows because you work with points, and 1-level arrows help you keep track of your points. You don't use 2-level arrows, but you can probably see why they are useful. Everyone knows that you should never git amend after a git push. But if git kept track of 2-level arrows, you could do a 2-level push, and sync your local amend with a remote amend. You could do a 2-level revert to undo your amend. And once you start working with 2-level arrows, you need 3-level arrows to keep track of those.

There are ∞ levels of arrows.

How can the computer store ∞ levels of arrows? Won't they take up ∞ space? Just one commit creates a 1-arrow, a 2-arrow, a 3-arrow, ... and so on.

But most 2-arrows are uniquely determined by a single 1-arrow, and uniquely determine their 3-arrow. Most n-arrows are degenerate, representing only the addition of a single (n-1)-arrow. At any time, only finitely many arrows require their own representation in memory.

Can a human mind keep track of 20 levels of arrows, let alone ∞ levels? That is hard to say, because no one has tried.

Building OpenCV with Java on Linux

This command worked for me:

cmake .. -DJAVA_INCLUDE_PATH=/usr/lib/jvm/java-8-oracle/include/ -DJAVA_INCLUDE_PATH2=/usr/lib/jvm/java-8-oracle/include/linux

It was not necessary to set BUILD_SHARED_LIBS to false as described on opencv.org. That would be rather undesirable to lose the ability to use shared libs just because you also want to use Java!

**HOWEVER**, because BUILD_SHARED_LIBS is set, libopencv_java310.so will have dependencies. It will be necessary to load libopencv_core.so.3.1 among others into the JVM at runtime, AND THEN to have libopencv_java310.so see those symbols. This is tricky in Java! If you don't want to go through this pain, you can go and unset BUILD_SHARED_LIBS; I won't judge you.

Essentially, what you need is a way to set RTLD_GLOBAL when loading the library. This can be accomplished using JNA:

NativeLibrary.getInstance(path);
System.load(path);

 Then you should be able to use OpenCV.

Example of using WebWorkers in ScalaJS

https://github.com/ellbur/scalajs-webworker-test

In case you were curious.

The biggest disadvantage of webworkers is that, at least, Chrome browser does not consider functions to be translatable from one webworker to another. This in theory should be possible, as a function can be represented as code+environment, and both of these are by themselves translatable.