Why I don't use hg-flow

I recently had a chance to read A successful Git branching model (the branching model underlying the popular git-flow and hg-flow extensions), and I found it rather interesting.  For NBTParse, I've been following a modified form of Mercurial's standard branching.  I thought about trying to adapt my work to use hg-flow, but I realized the differences are largely cosmetic:

• My main development descends from the @ bookmark, just like the "develop" branch of Driessen's model.  Conveniently, Mercurial automatically updates to this bookmark when cloning, if there's no obvious target revision.
• Although I rarely bother with them, feature branches are easily supported as bookmarked alternate heads of the default named branch.  I may use them more often once NBTParse approaches stability and it becomes necessary to keep the trunk stable(ish) leading up to a beta release.
• I use release branches, much like Driessen.  Mine are named branches instead of bookmarks, but this is mostly a matter of the former not existing under Git.  The release branches also have bookmarks, which are reused from one branch to the next; this makes it easy to (automatically) find the current unstable release branch (it's just release-unstable), for example.
• Much like feature branches, hotfix branches are just bookmarked alternate heads of release branches.  Again, I rarely bother with them, since my release branches remain open for as long as the released product is supported.  However, they can be useful if a fix is likely to require multiple commits or the attention of multiple developers.
• Now we come to the "master" branch.  I must admit, I don't quite have a master branch, but I have the next best thing.  All my releases are tagged, and the latest unstable (and stable, once we hit stable) is bookmarked.  I can just do hg log -r 'tag("re:version-.*")' to find everything that would have been on the master branch if I had one.  If I only want stable releases, I can use a more precise regex (e.g. ^version-\d+\.\d+\.\d+$).  Oh, and those revsets work in Bitbucket's search interface, too.

I'm sure Driessen's model is extremely helpful for him and lots of other developers, and it's nice to see people looking at nontraditional branching strategies.  But I guess I just don't see much value in rearranging my commits like this; my revision DAG is complicated enough already.

NBTParse

For quite some time, now, I've been working on a Python library called NBTParse.  It's designed to manipulate Minecraft worlds.  It's been languishing in a not-ready-for-prime-time state for the longest time, but I've finally decided to start working towards a 1.0 release.  As a motivator for that, I've begun rapid releases of 0.x.0 versions.

Each new 0.x.0 release will happen on the first Thursday of the month.  0.2.0 dropped on the 5th, but I didn't think to blog about it until now.  It can be had from PyPI under the name nbtparse (that is, you can run pip install nbtparse as usual).  If you don't have a C compiler, you may have difficulty with this.

Let's talk about the current status of the library.  It's currently very rough, with a number of serious shortcomings.  The biggest is the lack of a lighting engine.  In short, it doesn't adjust lighting information after altering the terrain.  Because of this, terrain manipulation is highly risky at the moment, with great potential to corrupt saves.  In other words, back up your saves before playing with this.  But you knew that already; it's listed as pre-alpha in PyPI, after all.  Work on the lighting engine has not seriously begun yet, so this will likely remain the case for a long time.  On the other hand, I hope to at least have heightmap updating in time for 0.3.0 (this will hopefully prevent any corruption from actually crashing Minecraft, though you'll still experience lighting errors).

Another issue is Minecraft 1.8 compatibility.  In short, there is none.  While 1.8-isms are nominally accessible, they're not particularly fun to work with right now.  Fortunately, this is mostly a matter of sitting down and writing declarative code to describe the new features.  It should be fairly straightforward once I get around to actually doing it.  I hope to have this in 0.3.0.

Finally, the API is not yet stable.  Some aspects of the library may change as we move closer to 1.0, without backwards compatibility.

Meta-Compatibilism

Salviati

A few days ago, I bought a $5 desk toy on Amazon. Now that it's here, I'm regretting the purchase. It's not nearly as good as I expected. Oh well, it's not that much money.

Simplicio

Do you ever wonder if you could have done things differently?

Salviati

What do you mean?

Simplicio

Well, take that toy, for example. Could you have decided not to buy it?

Salviati

Well, if I had known I wouldn't like it, of course I wouldn't have bought it.

Simplicio

That's not what I meant. Could you have chosen differently if you hadn't known?

Salviati

What are you talking about? I didn't know and I did buy it. What more is there to discuss?

Simplicio

Were you making a real choice, or just following the laws of physics?

Salviati

What is a "real" choice?

Simplicio

A choice which could have come out differently.

Salviati

If I had decided by flipping a coin, then it could have come out differently. But that doesn't really strike me as much of a choice.

Simplicio

No, the coin's motion is determined by chaotic air currents and subtle physical factors. There isn't any real randomness there.

Salviati

OK, what if I use a Geiger counter hooked up to a radioactive mineral? Unless you subscribe to a hidden variable theory (which I do not), the counter's clicking is truly random. No matter how much you know about the situation, you can never predict exactly when it will go off.

Simplicio

We're missing the point. I don't want to know whether a Geiger counter could have made a different choice. I want to know whether you could have made a different choice.

Salviati

Either some part of my brain acts like a miniature Geiger counter, or no such part exists. If it does exist, then yes, I could have "chosen" differently, but I don't think you'll want to count that either. If it doesn't, then obviously not.

Simplicio

So you admit it! You did not make a real choice, because real choices don't exist. We're all slaves to physics.

Salviati

Nonsense. I wanted it, and purchased it because I felt like it. My action directly resulted from my desire. No one forced me to buy it. Physics isn't a person, actively controlling my life. You still haven't given me a definition of "real choice."

Simplicio

A real choice is a choice you could have made differently, under the same circumstances, under your own conscious direction.

Salviati

But why would I want to? At the time, I thought it was a grand idea. In that state of mind, why wouldn't I buy it?

Simplicio

That's irrelevant. The question is whether you could have chosen differently, not whether you actually would have.

Salviati

What's the difference between "I could have chosen differently, but never would have," and "I could not have chosen differently?" Those sound like the same thing to me.

Simplicio

They're not. "Could" is physics. "Would" is choice.

Salviati

But you just said choice doesn't exist. Besides, how can choice be independent of physics? Unless you want to start talking about an immortal soul or something...

Simplicio

It doesn't matter. A choice-making soul would have the same logical problems as a choice-making brain. And this quibbling is pointless. Choice, as I've defined it, doesn't exist. We both agree on that much, I think.

Salviati

It doesn't exist because it is ill-defined.

Simplicio

No, it doesn't exist because it fails to refer.

Salviati

The desk toy was just an example. Setting it aside for now, all of your arguments have been a priori, that is, logical reasoning divorced from empirical evidence. If you demonstrate by logic that something can't exist, it must be logically inconsistent. You've argued that your own definition of choice is logically inconsistent. Your position is the same as mine.

The above writing format is a blatant ripoff of Galileo. I find it rather convenient, but it is admittedly unoriginal.

Watch Your Back, Git

Changeset evolution is a big deal.  But nobody seems to be talking about it.  Well, except for this guy:

But even he says it's a small set of incremental improvements.  This is not small.  But it is all a little abstract right now.  Let's write a use case.

The Pendulum and the Winch

I often find that explaining computer science to non-computer-scientists is difficult.  It's been said that computer science is like no other field of study.  Well, I think that's a rather strong claim to make.  What follows is a translation of a standard problem in computer science into physics.  It is an analogy, unrealistic but nevertheless interesting.

I have a pendulum, supported by some apparatus ultimately connected to a pillar or pole.  It is possible to move the apparatus up or down, but only by manually detaching and reattaching it by hand.  I have a winch affixed to this apparatus which may raise or lower the pendulum.  It is connected to a coil of rope or string (which, for the purposes of this problem, is infinitely long yet magically takes up a finite volume), and can be remotely controlled at the press of a button.  The winch is also geared discretely; it only turns in units, and then only one at a time.

I wish to carry out a series of experiments involving varying the length of my pendulum.  In particular, I often want to lengthen the pendulum.  Most of the time, this setup suits me quite well.  But sometimes, I find I need a pendulum longer than the apparatus is high off the ground.  In these situations, I need to climb the pillar and move the winch up.  In so doing, I may need to start an entire experiment over again because the pendulum lost energy while I was climbing.  How can I avoid or minimize those climbs in proportion to the maximum length of the pendulum?  We must assume I do not know the maximum length in advance, perhaps because my experiments are highly complex and difficult to predict, or perhaps because they are directed by someone else's instructions, and they did not think to tell me in advance how long a pendulum I would need.

The Great Picard Theorem

The great Picard theorem states that, if an analytic function contains an essential singularity, then within any punctured neighborhood of the singularity, the function takes on every value with at most a single exception.

Singularities happen all the time

We will soon create intelligences greater than our own. When this happens, human history will have reached a kind of singularity, an intellectual transition as impenetrable as the knotted space-time at the center of a black hole, and the world will pass far beyond our understanding. -- Vernor Vinge, 1983

 The technological singularity is supposed to occur when we develop "true" or "strong" AI.  Beyond that point, we are told, everything will be different, in the most conveniently vague ways.  Perhaps society will run on communism, or anarcho-capitalism, or something we don't have a name for (in other words, whatever the author happens to think would be ideal).  We are told that the resulting society will be totally incomprehensible to those of us still living in the present day.

My reaction to all this can be summed up in two words: "So what?"