Since I reached an acceptable milestone with PieCrust performance recently,
I had some free time again to catch up with some of my other projects. The first
one to get some love is Gutentags, my tag-management Vim plugin, which was
sitting there with a bunch of pull requests and bug reports.
The newest version of Gutentags includes better support for project-specific
settings via the
.gutctags file, some progress on supporting Cscope (not quite
finished yet), and various bug fixes, all from a few generous (and patient)
Grab it from Bitbucket or Github, depending on your preferred
PieCrust news -- and this blog -- have been pretty quiet for the past couple
months, and that's because I've been busy working on PieCrust 2 performance.
TL;DR: PieCrust 2 now runs in multiple cores, which speeds up the
baking process quite a bit. Update your repositories, or grab the latest version
More details after the break.
While I was working on the documentation for PieCrust 2, I decided I
might as well do something proper, like support for translations and versioning.
The documentation is now in the same repository as the code, and it's easy to
bake the documentation pages for each release.
To do this, I needed a simple tool that could do the basic work of cloning a
repository, syncing back to given points in times, and do something. In
theory, this would be a simple
bash script or something, but I also wanted it
to do nothing if it already did something for that same specific point in
Thus September was born (if you don't get the reference, even with the
picture above, I can't help you).
It's a simple Python script that still packs some goodness to it. It basically
lets you roll your own readthedocs kinda website (in a very basic way of
course), with appropriate hooks to your repositories.
You run it from inside your repository (Mercurial or Git at the moment) and it
will sync back to each tagged changeset and run a command of your choice. You
can specify a bunch of stuff in a configuration file, like the command itself
(which supports interpolation with a few useful values), the oldest tag to start
from (in case you don't want to go all the way back to the first release), and a
couple of other things. It will work out of a temporary directory in which it
clones your repository, and stores a cache file that describes what it's doing.
If you keep that temporary directory around, it won't re-do the work it
previously did (so it will only rebake my documentation pages if I moved a tag
or added some new ones, and it will re-use and update the repository clone).
It's still all new and a bit squeaky, so make sure to file some bug reports if
you see anything wrong. Oh, and it's on Github too for you Git kids.
It had to happen eventually, but PieCrust 1.x is now officially
deprecated. It was deprecated more or less unofficially before, as you can see
from the lack of activity on the repository, but, well, here it is.
The PieCrust 2 help pages are now showing up by default at the official
URL, and that's where I'll be focusing from now on.
If you want to upgrade your existing 1.x website to 2.0, you can follow the
installation and upgrade instructions. And of course, please contact
me if you have issues or feedback!
After the nice one-shot "The Murderer of Thomas Fell", my new gaming group decided to continue with the 1930s
horror genre and we played through roughly a third of the Realm of Shadows
campaign for Call of Cthulhu.
It ended with a near-total-party-kill.
You can read the actual-play for "Kith and Kin" (the first chapter) and
"Provender of the God" (the second chapter) over in the RPG section.
One thing that I realize now that I'm writing those things up is how often I
feel the need to explain why, as a GM, I'm doing this or that -- making the
bad guys attack here, adding some clues there, etc. Most of the "actual plays"
out there only focus on what happened around the players' side of the table. But
I'm finding it more interesting to also include what's happening behind the GM's
This is especially interesting because investigative adventures rely a
lot on the GM improvising events and moving around clues to keep the story
going, as opposed to, say, a dungeon crawl, where most of the design decisions
can be done upfront during the preparation phase, and the improvisation is
mostly about adjusting enemies to keep combat balanced.
Adding the GM side of the game makes it easier for me to see what I did right
and what I did wrong, and may even get me some constructive feedback on some of
those decisions. I'll try to keep adding things like that in the future reports.