The Fugue Counterpoint by Hans Fugal


An outsider’s view of Minecraft development (Fall 2015)

I'm a programmer and a father. I want to teach my kids programming. My kids love Minecraft. Programmers can write Minecraft mods and plugins. It seems natural to teach my kids to program with Minecraft.

I am not a Minecraft aficionado. I know the game, sure, and I can even make it through the first night in survival mode. But to me it's just a game in the periphery of my consciousness. So I was dismayed when I started looking into writing Minecraft code, and discovered that keeping up with the various ways you can code in the Minecraft ecosystem requires a level of fanaticism and devotion that I just don't have. And unfortunately there is no page out there that covers the pros and cons of the various options, not really even one that is out of date. And the landscape has changed considerably in the past 1.5 years.

This is me writing such a post, for this moment in time, for those people who are programmers and familiar with Minecraft but are not Minecraft fans who already know the various plugin and mod frameworks by reputation as users.

Client and server are the two easiest concepts. They're exactly what you'd think. Hooray!

A mod is something that changes the behavior of the server (usually) or the client (less often) or both. Usually very hacky, i.e. developed against decompiled Java classes, and you trick Java into loading your classes instead or in addition to the usual Minecraft code. This is low-level hackery, made a little easier by Minecraft being written in Java. Mods are plagued with being out of date as Minecraft progresses, but the real popular ones with lots of support will stay up-to-date pretty well.

A plugin is code written to interact with a Minecraft server (or client, less often) via a well-defined API. The plugin is generally hosted by a mod that provides the API and proxies events, commands, etc.

Minecraft proper supports neither mods nor plugins directly. There is no official API or way to interface. But the scene is vibrant all the same. Various frameworks to support mods and plugins have sprung up. Some have died off but tutorials, books, forum posts, and so on still pollute Google and bookstores. As far as I can tell, the most important frameworks are as follows:

Forge provides a basic mod wrapper around decompiled Minecraft. If you use the Forge server (and launcher), you can choose the Forge mods to have enabled, and as a developer you have a bit more stable of an API.

Bukkit was the king of plugin frameworks, until it imploded in 2014 (due to a DMCA takedown by a bitter developer). CraftBukkit was the server mod that would host Bukkit plugins. It's probably possible to find the CraftBukkit jar still, but legality is grey at best.

After Bukkit imploded, the ground was fertile for dozens of replacement attempts. Now a little over a year later, it seems like there are two leaders. First, Spigot is a Bukkit-compatible API and has a server mod. It claims to also be a bit more performant than CraftBukkit, and I think it might have existed as a more-performant Bukkit since before Bukkit imploded. Since Spigot supports Bukkit plugins, and Bukkit was the most popular plugin API by a long shot, Spigot is now the most popular framework (the second is CraftBukkit, still.) You can see all this and more at the beautiful

Sponge is taking a fresh (and purportedly improved) approach on the plugin API. It's not compatible with Bukkit. It's also not done, but it looks like it's probably functional. Legally, it's probably on much more stable ground than Spigot, however Spigot doesn't seem to be under any serious contestation so pragmatically speaking Spigot is probably the better choice unless you especially like the Sponge api or philosophy. Especially given the wealth of documentation, books, tutorials, etc. aimed at Bukkit which are mostly still relevant with Spigot.

Glowstone/Glowstone++ is a from-scratch server that supports the Bukkit API. It's meant to be faster, simpler, completely open source, but not 100% identical in behavior to vanilla Minecraft. It looks like a viable alternative to Spigot's server mod, but you don't have to decide up-front. You can write a Spigot plugin and use it on Spigot, Glowstone(++), or even old CraftBukkit.

So, the executive summary is it looks like you probably want to use Spigot, and you can use learning materials written for Bukkit. If down the road Spigot implodes and takes Glowstone with it (because of API copyright or something), then Sponge might be poised to be the successor. Or maybe once you've got some experience under your belt you'll find Sponge more attractive (and perhaps more complete, by then).

Hope that's helpful!


Reduce compilation time with template magic.

It is a common belief that templates must be implemented in header files, a lamentable situation that greatly increases build times because those full-blown headers must be compiled every time they are included. It also makes the headers less useful as brief documentation, which one of the things about headers that is actually good.

But that is not strictly true. You can separate template declarations and implementations. With a simple pattern and just a little thought, you can compile your template code once and link it just like you do regular objects or functions.

Let us begin with a function foo which just prints the T it was given to cout. Here is the header:

// foo.h
#pragma once

template <class T> void foo(T);

Now let's try to use it:

#include "foo.h"

int main(void) {
    return 0;

And compile:

$ c++ -std=c++11 -c
$ c++ a.o
Undefined symbols for architecture x86_64:
  "void foo<int>(int)", referenced from:
      _main in a.o
ld: symbol(s) not found for architecture x86_64
collect2: error: ld returned 1 exit status

The object file compiles fine, but linking fails because void foo<int>(int) is undefined. So, let's define it:

// foo-tmpl.h
#pragma once

#include "foo.h"
#include <iostream>

template <class T> void foo(T t)
    std::cout << t << std::endl;

Now if we change to include foo-tmpl.h instead of foo.h, the implicit instantiation will work fine. But instead, let's explicitly instantiate the int specialization in, because we believe everyone and their dog will want the int specialization, and we want to save compile time:

#include "foo-tmpl.h"

template <int> foo(int);

And compile:

$ c++ -std=c++11 -c
$ c++ -std=c++11 -c
$ c++ a.o foo.o
$ ./a.out


Ok, but what about implicitly instantiating templates? We don't want to give up this unique power of templates. We can do it. This is why I put the implementation of foo in foo-tmpl.h instead of When we need to instantiate, we include the -tmpl.h instead of the .h. We should try to avoid doing this in other headers, and prefer to do it (once) in an implementation file. To demonstrate let's introduce a new function bar:

// bar.h
#pragma once

void bar();

And its implementation:

#include "bar.h"
#include "foo-tmpl.h"

void bar()

Now we are implicitly instantiating void foo<const char*>(const char*), but that's ok because we included foo-tmpl.h. Now we can use bar:

#include "bar.h"

int main(void) {
    return 0;

Compile and run:

$ c++ -std=c++11 -c
$ c++ -std=c++11 -c
$ c++ b.o bar.o
$ ./a.out

And finally, let's use them together

#include "foo.h"
#include "bar.h"

int main(void) {
    return 0;

Compile and run:

$ c++ -std=c++11 -c
$ c++ c.o foo.o bar.o
$ ./a.out 

Just to make sure we understand what's going on under the covers, let's look at the symbols with nm, and make sure things are defined where we expect them to be:

$ nm *.o | c++filt  # manually-filtered output follows
                 U void foo<int>(int)

                 U bar()

                 U bar()
                 U void foo<int>(int)

0000000000000000 T void foo<int>(int)

0000000000000000 T bar()
0000000000000075 S void foo<char const*>(char const*)

I performed these explorations with gcc 4.8.

$ c++ --version
c++ (MacPorts gcc48 4.8-20130210_0) 4.8.0 20130210 (experimental)
Copyright (C) 2013 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.  There is NO

With C++11 you also have extern template at your disposal, which lets you avoid implicit instantiation. So if you have many files which instantiate the MyClass specialization, and don't want to even be aware of MyClass, you can add this to MyClass.h:

// MyClass.h
#include "foo.h"
class MyClass {

extern template void foo<MyClass>(MyClass);

And then looks something like this:

#include "MyClass.h"
#include "foo-tmpl.h"

// explicitly instantiate templates
template void foo<MyClass>(MyClass);

MyClass::MyClass() {
    // ...

// ...

Now the MyClass instantiation of foo will only be compiled once in, but can be used in umpteen other files.


tmux C-Left in

I use on OS X, and I want to bind ctrl-left/right to cycle through tmux windows (like I did with screen).

The tmux incantation is easy to find online:

bind-key -n C-Left prev
bind-key -n C-Right next

This doesn't work though, because is sending ^[[5D for left instead of what tmux expects. In my case, with TERM=xterm-256color, tmux is expecting ^[[1;5D for C-Left and ^[[1;5C for C-Right. You can change this in the settings. Ideally would magically send the right values based on the TERM setting, if there is such a thing as the right values in the world of terminfo and modified arrow keys.

I would prefer to tell tmux to accept ^[[5D instead of ^[[1;5D, which is what I did in my screen config, but I can't see any way to tell tmux to take a raw escape sequence instead of logical keys. I prefer that so that I don't have to remember (or research) magical incantations to configure the next time I start from scratch on OS X. So if you know how, let me know.


tmux 1.8 reflows text on terminal resize

Hello world!

Filed under: Uncategorized No Comments

Sourdough in Bread Pans

A lot of people will tell you you shouldn't put sourdough in metal. Some even go so far as to say you shouldn't use a metal spoon to stir it. That's all nonsense. It's not hydrochloric acid, it's food.

However, when you leave sourdough in a vessel for an extended period of time, and that vessel is not non-reactive, it will react. (The same as tomato sauce will.) It turns out, aluminized steel is one of those substances, and my precious Chicago Metallic pan is ruined from a few very long and sour proofs (10+ hours). Also a lot of scratches from metal knives trying to release stubborn loaves, have taken their toll. As it turns out aluminized steel is steel coated with an aluminum-silicone coating, so you should probably treat it as you would non-stick, even if it claims to be "uncoated" (meaning it doesn't have a non-stick coating). Use plastic utensils to wage war with your stubborn bread.

I'm not sure whether regular non-stick coatings are non-reactive or not, but I'm not a fan of tiptoeing around my cookware so I avoid non-stick.

So I'm buying a Stainless Steel Loaf Pan. I considered silicon too, but I hear horror stories of bad smells at high heat and not keeping their shape with a heavy loaf. And I'm not sure if they'll brown well (stainless is supposed to be less-good for browning that aluminum or aluminized steel, but oh well).

If you already have aluminized steel pans I'm sure you can bake sourdough in them, just watch out for long sour proofs, and use plastic.


Code Reading on a Kindle

First, add this to your ~/.enscriptrc file:

Media: kindle 498 612 0 0 498 612

Now, here's a script (I call it kindlecode) to generate a pdf on stdout:

enscript -Mkindle -E -p- "$@" | ps2pdf - -

Usage is something like this:

$ kindlecode *.{c,h} > /Volumes/Kindle/documents/foo.pdf

kindlecode in real life


Calipers and Science

Just for kicks I dug up the original Jackson/Pollock paper for skinfold measurements for determining body fat percentage. Turns out there's also a 7-point equation that also takes circumference of waist and forearm into account.

Here's a snapshot of the equations for men from the paper ("Generalized equations for predicting body density of men" by A.S. Jackson and M.L. Pollock, 1978. I couldn't find the PDF for the women paper online).
Generalized body density equations

Important notes: skinfolds are in millimeters, circumferences are in meters, and log is the natural log (ln in most computer languages). I plugged my values from two weeks back into a spreadsheet and got the following results:

JP Equation Density %BF
Sum of seven skinfolds
S, S^2, age 1.0518 20.62%
S, S^2, age,C 1.0476 22.51%
log S, age 1.0506 21.15%
log S, age, C 1.0482 22.25%
Sum of three skinfolds
S, S^2, age (5) 1.0607 16.69%
S, S^2, age,C (6) 1.0549 19.24%
log S, age (7) 1.0578 17.95%
log S, age, C (8) 1.0574 18.14%

The most interesting thing here is that there's a large difference between 7 and 3 site measurements, and the 3 site range is significantly larger. Also very interesting to note is that the one-site (suprailiac) AccuMeasure chart is, for me, in line with the 7-site measurement (22.1%). Given other measurements I've taken and just general guesswork based on what I see in the mirror, I think that is a decent estimate.

It's also curious that there are two sets of equations given, one using logs and one using squares.

Moral of the story: more data is better, sometimes not-enough more data is worse than a simpler estimate, and interesting things can be learned when you go to the original source. (This is just a quick note, but the paper is very interesting and reading it will be an interesting exercise that sets proper expectations for, and understanding of, the JP7 skinfold method).


Motorcycle Wheel Alignment

An important part of maintaining a motorcycle is keeping the correct slack on the chain. Usually this involves loosening the rear wheel nut and using two adjustment bolts (one on each side of the wheel) to set the correct tension. Care must be taken to ensure that the front and rear wheels are aligned, or you get bad wear and handling. When you know they are aligned already, you can just count the "flats" and turn the bolts the same amount. But from time to time, or whenever you're uncertain, you have to align them.

The simplest method is just using the marks on the swingarm. This is what I did the first time, but it felt like the rear tire was out of alignment. A little searching of the web confirmed that these marks are both too imprecise and often just plain wrong. What really matters is not the marks the manufacturer put on, but whether the two wheels are actually aligned.

The most common DIY method is to take a string, hold it taught so that it just touches both edges of the rear tire and extends to the ground at the front tire. Carefully measure on both sides, and adjust until the front tire is perfectly centered. I tried this method after I decided I wasn't sure my wheels were aligned. It was a big hassle, especially with just one person, but eventually I got the hang of it. It felt more accurate than the marks but it still felt wildly inaccurate. Something more rigid than string but still nice and straight may have given me more confidence, but I didn't have anything long and straight enough. It could have been placebo, but it rode a lot better after aligning this way.

By this point it had turned quixotic and I would not rest until I found an easy and accurate way to align my wheels. One search led to another and I eventually stumbled across the ProAligner. I was intrigued—how could a ruler be more accurate? Even one with "scientifically designed" red marks. Being the cheapskate engineer that I am I wasn't gong to shell out even $30 unless I knew it would work, and not if I could make my own.

If you search for more details on the ProAligner, you get not a lot of results that fall in two categories: gushing reviews that may or may not be shills, and skeptical curmudgeons that scream SPAM or dismiss even the idea of aligning your wheels. Nobody bridges the two with important details like what the theory is and why it may or may not work, or how it is even used.

Luckily for you anxious wheel aligners (Yes, I realize it is January. I live in California—deal with it! ;-), I have put the jigsaw together and will now help you decide whether to buy the ProAligner.

First, let's discuss the theory on which it works. It's simple geometry. Center front wheel relative to rear tireAlign rear wheel
You are making right triangles and adjusting the wheels until the opposite sides are the same. First you center the front wheel on the rear tire by sighting down each edge of the front tire, then you align the rear wheel by sighting down each edge of the rear tire. Adjust and repeat as necessary until the rear wheel is aligned when the front wheel is centered. Refer to the figure, and reread this paragraph until you get it because it is the key to the whole method, and the thing that ProAligner hopes to hide from all but those who have purchased their ruler. Once you know this tidbit and how it works, it's a slippery slope to realizing you don't need their product to replicate it.

I approximated their design in CAD (the exact spacing is irrelevant, I think I used centimeters and didn't fret whether my printer scaled it slightly), printed it out, and taped it onto some cardboard. Since I don't have a center stand, and my high-quality bike lift is opaque, I needed to do it on the sidestand, so I cut the cardboard to the appropriate angle.

The first time I tried to use it, I put the ruler at the rear wheel and didn't have the whole process figured out. I thought you just sighted along the front tires and soon realized that this alone was super inaccurate unless you could be sure the front wheel was centered perfectly. With the ruler at the rear wheel, it was impossible to read, even with the "scientifically designed" markings.

The second time, I put the ruler just behind the front wheel and had figured out the key idea of centering the front tire relative to the rear wheel, then sighting the rear wheel to read the adjustment. The ruler was easy to read at this distance. I think even a regular school ruler would be—it was 2–3 feet from my eye. The shadow side of my rear tire was hard to sight because it was all just dark. It would have been easier with better lighting, but it was easily remedied with a piece of masking tape on the rear edge to provide contrast. I was pleasantly surprised that it was not only easy to sight and read (aside from having to literally lie on my stomach), but the readings were consistent and reproduceable. It was fairly close to aligned (from the string method) but needed slight adjustment—it turned out I could distinguish one "flat" of the adjusting bolt. This is quite accurate, and easier than futzing about with strings.

As I see it, ProAligner is clever on several fronts. First, coming up with the idea of sighting down the edges of the tires and realizing that this is quite accurate (like sighting a rifle), that was pretty clever. Then, the folding ruler while hardly novel does make positioning it stable and flexible. Finally, I'll concede that the "scientifically designed" markings are easier to read than a regular ruler. So if you're into supporting clever independent companies or would rather spend some money than spend time making your own, then go buy yourself a ProAligner and rest assured that it is accurate and easy.

I have some other ideas for accurate measuring of alignment if lying on the ground isn't your thing. First, a string-based method that I hope would take away most of the frustration: Get a dowel or 2x4 and accurately notch the width of your rear wheel and the center point between the notches. Run the string from the rear tire (hint, wrap around the tire and anchor on a spoke—tape on the tire doesn't stick well) to the notches and wedge it under the centered front wheel. Now you just turn the bolts until the sides of the string just barely touch on both sides.

Second, a laser-pointer method. This isn't unlike this post which was my original tip on the ProAligner, but I think it's easier than his contraption. Attach two laser pointers to straight 2x4s such that they span the rear wheel and point true and level. Bungee them to the rear wheel such that the lasers hit down by the front wheel. Adjust until the front wheel is centered between the laser points. The success of this depends on how accurately you can true the pointers and whether you can keep them on (or have a friend), etc. You could also forego the boards if you have a friend and just sight the laser down the side of the rear tire (a little red on both edges, and also down on the ground by the front tire), have your friend mark with chalk, then measure.

Well, now you have all my thoughts on wheel alignment. My favorite is the ProAligner method—it's faster, simpler, feels most consistent and reliable, and you can even DIY with a ruler, some cardboard, a utility knife, and some tape.


clock_getres() and clock_gettime()

In Linux kernel 2.6.33 at least, when you call clock_getres() you may not be getting the whole story if the kernel was compiled without high-res timers. (CONFIG_HIGH_RES_TIMERS)

clock_getres() returns {0, 999848}, which you might think means clock_gettime() has a resolution of about 1ms. But no, if you call clock_gettime() twice in rapid succession you find that it is far higher resolution than that—I usually get either 698 or 699 nanoseconds as the difference. So is clock_getres() wrong? No, not exactly. It is reporting the jiffy that limits clock_settime() and the timers. If you time clock_nanosleep() you find that even if you ask to sleep for 1ns you will sleep until the next jiffy boundary, i.e. as much as 1ms and about 0.5ms on average.

If you look at /proc/timer_list on this machine, it reports a tick resolution of 999848, but hrtimer functions are being used underneath the covers:

active timers:
#0: , hrtimer_wakeup, S:01, hrtimer_start_range_ns, smc_proxy/14652
# expires at 1322421490000000000-1322421490000050000 nsecs [in 1303778479239642688 to 1303778479239692688 nsecs]
clock 1:
.base: ffff88002820e680
.index: 1
.resolution: 999848 nsecs
.get_time: ktime_get

My guess is that clock_gettime() is using HRT and giving high-resolution answers even though you didn't enable using HRT for POSIX timer functions by leaving CONFIG_HIGH_RES_TIMERS unset.

A side effect of this silly situation is that gettimeofday() is also accurate (to µs), though usleep() and nanosleep(), like clock_nanosleep(), are limited to 1ms ticks.


Watch Movie Online Underworld: Blood Wars (2016) subtitle english

Poster Movie Underworld: Blood Wars 2016

Underworld: Blood Wars (2016) HD

Director : Anna Foerster.
Producer : David Kern, Gary Lucchesi, Tom Rosenberg, Len Wiseman, Richard S. Wright.
Release : November 28, 2016
Country : United States of America.
Production Company : Lakeshore Entertainment, Screen Gems, Sketch Films.
Language : English, Português, Український.
Runtime : 91 min.
Genre : Action, Horror.

Buy Now on Amazon Underworld: Blood Wars (2016) Full Movie

'Underworld: Blood Wars' is a movie genre Action, was released in November 28, 2016. Anna Foerster was directed this movie and starring by Kate Beckinsale. This movie tell story about Vampire death dealer Selene fends off brutal attacks from both the Lycan clan and the Vampire faction that betrayed her. With her only allies, David and his father Thomas, she must stop the eternal war between Lycans and Vampires, even if it means she has to make the ultimate sacrifice.

Do not miss to Watch movie Underworld: Blood Wars (2016) Online for free with your family. only 2 step you can Watch or download this movie with high quality video. Come and join us! because very much movie can you watch free streaming.

Watch movie online Underworld: Blood Wars (2016)

Incoming search term :

Watch Underworld: Blood Wars 2016 Online Free megashare
Underworld: Blood Wars 2016 English Full Episodes Watch Online
Watch Underworld: Blood Wars 2016 Online Megashare
live streaming film Underworld: Blood Wars
Underworld: Blood Wars 2016 HD Full Episodes Online
watch full movie Underworld: Blood Wars
Underworld: Blood Wars 2016 English Episodes
Watch Underworld: Blood Wars 2016 Online Putlocker
Underworld: Blood Wars 2016 Full Episodes Watch Online
streaming Underworld: Blood Wars 2016
Underworld: Blood Wars 2016 Episodes Watch Online
movie Underworld: Blood Wars 2016 streaming
Underworld: Blood Wars 2016 HD English Full Episodes Download
Underworld: Blood Wars 2016 live streaming film online
Underworld: Blood Wars 2016 English Full Episodes Download
download full movie Underworld: Blood Wars
movie Underworld: Blood Wars 2016 trailer
download film Underworld: Blood Wars
download movie Underworld: Blood Wars 2016 now
watch full film Underworld: Blood Wars 2016 online
Watch Underworld: Blood Wars 2016 Online Free putlocker
live streaming movie Underworld: Blood Wars 2016 online
Underworld: Blood Wars 2016 English Full Episodes Online Free Download
Underworld: Blood Wars 2016 For Free Online
Underworld: Blood Wars 2016 Watch Online
Underworld: Blood Wars 2016 Full Episode
Watch Underworld: Blood Wars 2016 Online Viooz
Underworld: Blood Wars 2016 English Episodes Free Watch Online
Watch Underworld: Blood Wars 2016 Online Free Putlocker
Underworld: Blood Wars 2016 English Full Episodes Free Download
watch full Underworld: Blood Wars 2016 movie
Underworld: Blood Wars 2016 live streaming movie
Underworld: Blood Wars film
download Underworld: Blood Wars 2016 movie
Underworld: Blood Wars 2016 English Episode
Underworld: Blood Wars 2016 Full Episodes Online
streaming Underworld: Blood Wars movie
Underworld: Blood Wars 2016 For Free online
watch full film Underworld: Blood Wars
film Underworld: Blood Wars online
watch full Underworld: Blood Wars movie online
Watch Underworld: Blood Wars 2016 Online Free Viooz
Underworld: Blood Wars 2016 Online Free Megashare
Underworld: Blood Wars 2016 Episodes Online
Watch Underworld: Blood Wars 2016 Online Free