My older twitter mercurial hook relied on twitter’s basic authentication which, as of August 31, 2010, is no longer supported. This script is an updated version that now works with twitter’s new OAuth system.

For this hook, you will need to create consumer keys for the script and access keys for the twitter account from which you wish to tweet. If you don’t know how to create and obtain these keys, don’t worry, Jeff Miller has written a nice article that covers how to generate them. After following his tutorial, you should have a python script that successfully posts to your twitter account from the command line and contains a CONSUMER_KEY, CONSUMER_SECRET, ACCESS_KEY, and ACCESS_SECRET. Simply use those keys for the corresponding configuration variables in the twitter section of your hgrc file. If you paste the block of code containing the consumer and access key strings into your config, the key values should not be surrounded by single or double quotes like they are in python code. Remember to remove the quotes or they will be sent as part of the keys and you will receive an “Invalid Token” exception.

This updated version of the hook requires tweepy.
More information on installing and configuring hooks can be found in mercurial’s documentation.

File: hgtwitter.py

'''
[extensions]
hgext.hgtwitter=

[hooks]
incoming.notify = python:hgext.hgtwitter.hook

[twitter]
CONSUMER_KEY = your Consumer Key
CONSUMER_SECRET = your Consumer Secret
ACCESS_KEY = your Access Key
ACCESS_SECRET = your Access Secret
'''
from mercurial import cmdutil, templater
import tweepy

tweet_template = '''
|{root|basename}:{rev}|
{desc|strip}
'''.strip()

def hook(ui, repo, hooktype, node=None, source=None, **kwargs):
    ctx = repo[node]
    CONSUMER_KEY = ui.config('twitter', 'CONSUMER_KEY')
    CONSUMER_SECRET = ui.config('twitter', 'CONSUMER_SECRET')
    ACCESS_KEY = ui.config('twitter', 'ACCESS_KEY')
    ACCESS_SECRET = ui.config('twitter', 'ACCESS_SECRET')

    t = cmdutil.changeset_templater(ui=ui, repo=repo,
                                   patch=False, diffopts=None,
                                   mapfile=None, buffered=False)
    t.use_template(templater.parsestring(tweet_template,
                                        quoted=False))

    ui.pushbuffer()
    t.show(ctx, changes=ctx.changeset(), root=repo.root)
    tweet = ui.popbuffer()

    if len(tweet) > 140:
        tweet = tweet[:139] + u"\u2026"

    auth = tweepy.OAuthHandler(CONSUMER_KEY, CONSUMER_SECRET)
    auth.set_access_token(ACCESS_KEY, ACCESS_SECRET)
    api = tweepy.API(auth)
    api.update_status(tweet)

t = cmdutil.changeset_templater(ui=ui, repo=repo,
                                   patch=False, mapfile=None,
                                   buffered=False)

UPDATE: This script uses basic auth and no longer works as of Aug 31, 2010. Please use the updated version with OAuth support

This is a really simple mercurial 1.2 hook for posting incoming changesets to twitter. It requires python-twitter.
File: hgtwitter.py

'''
[extensions]
hgext.hgtwitter=

[hooks]
incoming.notify = python:hgext.hgtwitter.hook

[twitter]
username = twitter_username
password = twitter_password
'''
from mercurial import cmdutil, templater
import twitter

tweet_template = '''
|{root|basename}:{rev}|
{desc|strip}
'''.strip()

def hook(ui, repo, hooktype, node=None, source=None, **kwargs):
    ctx = repo[node]
    tuser = ui.config('twitter', 'username')
    tpass = ui.config('twitter', 'password')

    t = cmdutil.changeset_templater(ui=ui, repo=repo,
                                   patch=False, diffopts=None,
                                   mapfile=None, buffered=False)
    t.use_template(templater.parsestring(tweet_template,
                                        quoted=False))

    ui.pushbuffer()
    t.show(ctx, changes=ctx.changeset(), root=repo.root)
    tweet = ui.popbuffer()

    if len(tweet) > 140:
        tweet = tweet[:139] + u"\u2026"

    api = twitter.Api(username=tuser, password=tpass)
    status = api.PostUpdate(tweet)

t = cmdutil.changeset_templater(ui=ui, repo=repo,
                                   patch=False, mapfile=None,
                                   buffered=False)

If you are running XBMC for Linux, you can use your Xbox1 (wired), Xbox360 (wired) and Xbox 360 (wireless) controller as a remote just like your original xbox controller with your original Xbox. If you want to use a wireless Xbox 360 controller with Linux, you will need to purchase an Xbox 360™ Wireless Gaming Receiver for Windows®. Despite the Wireless Gaming Receiver being branded as “For Windows”, it is fairly easy to get working quite well under Linux.

The Linux kernel has built in support for Xbox gamepads via a kernel module. The latest SVN XBMC has a default Keymap.xml with some support for this module, but a nice alternative is the Userspace Xbox/Xbox360 USB Gamepad Driver for Linux. I found it to be more stable and easier to get up and running. The only downside is that you will have to write your own Keymap.xml, but you can use my Keymap.xml which mimics the original Xbox controller binding as closely as possible.

UPDATE:
Here are some more up to date sources for getting xboxdrv working with XBMC.
xboxdrv & XMBC live forum thread
Ubuntu 9.04 xboxdrv XMBC How-to

See the README in the source of the Gamepad Driver for instructions on how to get it running, or if you run Ubuntu Linux there is a How-to on the Ubuntu forums at http://ubuntuforums.org/showthread.php?t=825464

I start the Userspace Xbox/Xbox360 USB Gamepad Driver with following options:

xboxdrv --wid 0 -s -l 2 --dpad-as-button --deadzone 12000

‘-s’ puts the driver in silent mode so it won’t spam the screen with messages.
‘-l 2’ tells led light 1 on the controller to blink twice and then stay lit.
‘–dpad-as-button’ turns the dpad into button events instead of an axis. This is important so you can scroll in the XBMC menus.
‘–deadzone 12000’ sets a deadzone for the thumbsticks. 12000 works well with XBMC for things like analog seeking but you might want to play around with that value.

In order for XBMC for linux to use this driver you have to create your own Keymap.xml file with the correct joystick name, which is “Xbox Gamepad (userspace driver)”. If you want to save some time, you can use my Keymap.xml. Place it in your ~/.xbmc/userdata/ folder, and make sure it’s named Keymap.xml(With a capital K) and not keymap.xml.

Download Keymap.xml

Update: jstultz pointed out that it is very important that the filename be Keymap.xml, not keymap.xml.
Checkout this discussion on the xbmc forums:
http://xbmc.org/forum/showthread.php?p=219809#post219809

After placing the Keymap.xml file in your userdata folder and running the xboxdrv command, you can start xbmc. You should then be able to use your controller with XBMC.

If the controller doesn’t work, the problem is most likely with permissions. Make sure the user you run xboxdrv and xbmc as has all the correct permissions to access usb devices and joysticks. This usually means both read and write permission for the file ‘/dev/input/uinput’.

The wireless Xbox 360 controller turns off automatically after a certain amount of inactivity. As a result, the battery lasts longer then other controllers I’ve tried. If you use the rechargeable battery, the controller becomes a pretty nice solution for an XBMC media center remote. Pressing the Xbox button on the controller will power the controller back on and it will start functioning again, so don’t be worried about the controller not working after it powers off.

During a Buildbot build step you might need to have a list of files which have changed as a result of a commit to your repository. A quick way to get this information during a build step is to subclass the build step class of your choice and overload its start() function.

A build step’s start() function is responsible for telling the slave to start executing the command. Each step class has a member variable called “build” of type “buildbot.process.base.Build” which it inherits from its main parent class “buildbot.process.buildstep.BuildStep”. Here is a quick example of getting file change information during a ShellCommand step in your master.cfg file:

from twisted.python import log
from buildbot.steps import shell
from buildbot.process.buildstep import RemoteShellCommand

# Executes a remote command with changed files appended onto the end
class ShellCommandChangeList(shell.ShellCommand):
  def start(self):
    # Substitute build properties into command
    command = self._interpolateProperties(self.command)
    # fail assert if command is not of correct type
    assert isinstance(command, (list, tuple, str))

    # Get changed file list from the build which invoked this step
    files = self.build.allFiles()
    # Log the changed files to twistd.log
    log.msg("Build Files: %s" % files)
    # Now we can do whatever we want with the list of changed files.
    # I will just append them to the end of the command.

    # Convert file list so it can be appended to the command's type
    if isinstance(command, str):
        files = " ".join(files)
    elif isinstance(command, tuple):
        files = tuple(files)

    # append files to end of command
    command += files

    # We have created the final command string
    # so we can fill out the arguments for a RemoteShellCommand
    # using our new command string
    kwargs = self.remote_kwargs
    kwargs['command'] = command
    kwargs['logfiles'] = self.logfiles

    # Create the RemoteShellCommand and start it
    cmd = RemoteShellCommand(**kwargs)
    self.setupEnvironment(cmd)
    self.checkForOldSlaveAndLogfiles()
    self.startCommand(cmd)

Here is a short contrived example of using the new ShellCommandChangeList build step with a BuildFactory to call a remote command for a fictional program named `checksum`. Let’s say that `checksum` is a program which takes filenames as input, computes the checksum of those files and prints those checksums to standard out.

from buildbot.steps import source, shell
from buildbot.process import factory

f = factory.BuildFactory()
f.addStep(source.SVN, svnurl="http://svn.example.org/Trunk/")
f.addStep(ShellCommandChangeList, command=["checksum"])

You should note that the way your VC system works and how your repository is set up in terms of file location and branches may affect how the file change paths are presented to you. You can easily see the list of file changes by using log.msg in your start() function to print them to the twistd.log file.

This is a quick update to my last article on Running Buildbot as a Windows XP Service. There was an interesting comment posted by jdpipe regarding the previous article . He offered a nice solution for some issues I was having with environment variables and stopping the Buildbot service. You can check out the article he wrote about it at https://pse.cheme.cmu.edu/wiki/view/Ascend/BuildBot.

He recommends using a python script instead of a batch file to ensure the build environment is setup correctly. By using a python script the service now launches pythonw.exe directly. This solves the Buildbot service issue where it’s not able to stop or restart properly as a result of being launched from a batch file. The article by jdpipe has excellent information on setting this up along with some pictures to help illustrate the process.

I once tried to create a game called Hunt Fish Camp. The main goal of the game was to hunt various types of wildlife. The cool thing about this game was that it revolved around an A.I. ecosystem. The idea was that you would drop a bunch of different animals into a level and they would interact with each other. I had a basic ecosystem going in the Half-Life 2 engine with birds, bears, headcrabs, and some other creatures. The animals had basic needs like hunger, sleep, and procreation. The game was really cool because the world just took care of itself. You would spawn into a level and walk around seeing all these cool interactions between species. It was really cool but it had one major flaw. There was no game. It was a cool software project and really neat to look at but not really all that fun to play. I couldn’t figure out why and chalked it up to the game’s young development state and unpolished gameplay.

Recently, I have begun to crave this sort of ecosystem type game again. A long time ago I heard about a game called S.T.A.L.K.E.R: Shadow of Chernobyl by developer GSC Game World. It has been in development for a long time. The interesting thing about this game is that it’s ecosystem based. From what I understood or possibly imagined is that it contains an A.I. ecosystem of mutants and humans which live in a zone. The basic idea behind the game was to give the player a huge environment and have them achieve goals with the main goal being to find and trade artifacts. The player tries to accomplish these goals and most of the gameplay comes from them interacting with the various creatures in the ecosystem. This sounded like the game I always wanted to play. I read an interesting interview with Anton Bolshakov, one of the developers on S.T.A.L.K.E.R. In the interview it sounded like the developers of S.T.A.L.K.E.R ran into the same problem I did when creating Hunt Fish Camp. It was an awesome simulation but it just didn’t appeal to players in terms of gameplay. As a result they delayed the game and began working on a more structured story. In another interview Bolshakov gave an explanation of why they chose to do this:

It appears that S.T.A.L.K.E.R has now become an ecosystem based game with a storyline. It will be interesting to see since a lot of development went into the ecosystem’s simulation. Most games create the A.I. to facilitate the type of game and storyline they are creating as apposed to S.T.A.L.K.E.R where they kind of created a story over their A.I. system. I think it is going to be a really cool game but at the very least it should be very interesting to see how the gameplay works.

]]> /anthony/2006/11/11/ecosystem-games/feed/ 4 /anthony/2006/09/05/sntask-utility/ /anthony/2006/09/05/sntask-utility/#comments Tue, 05 Sep 2006 07:09:12 +0000 /anthony/2006/09/05/sntask-utility/

I have been working on setting up the new automated build system. We were having some hardware problems with the new server which was very unfortunate. Denrei tracked it down to the new gigabit NIC I installed. For now, we are going to revert back to the 100 Mbit onboard NIC.

Despite the problems, the build system seems to be working. The server seems stable, so I am finishing the automatic game source asset creation. Our build system notifies developers, via email, about updates to the distributed files. This is a good method for keeping developers up to date on the status of distributed files, but it is far too slow. If a developer is using files that are changing, they need to know immediately when those files change. As a result, we created a small utility called SNTask, that sits in the task bar. It shows developers the status of the build system in real-time, so they know immediately when files have changed.

One part of our next milestone consists of extending our automated build system. We already use Buildbot to automate most of our builds and testing. Every time source code is checked into the repository it is compiled and all unit tests are run. If the compile or unit tests fail the entire team is notified via email.

Our next milestone requires us to take our automated build system one step further. Source code and game source assets will be automatically built and distributed for all to use when checked into the repository. Any changes to the source code or game assets will result in all developers automatically using the updated version. If bad source code is checked in (it doesn’t compile or fails a unit test) then the build will fail, the team is notified and the broken version is not automatically deployed. There are many other cool extras we get for free when using this system. For example the ability to automatically deploy any version of the repository. If something went horribly wrong with the latest checked in version we can instantly build and deploy any prior version of the repository and all developers will automatically be using that version. Developers can deploy and work on different versions of the repository at the same time. This can also extend to branches and tags. We can have one part of our team working on an unstable branch of the engine while the other part is working on the main trunk of the repository which is stable. Each team works on their own branch and any changes they make are automatically deployed to the others using that same branch. When the unstable branch becomes stable and is merged into the main trunk then the new changes are instantly deployed to the group working with the main trunk.

This will also be very useful for game assets. The artist never has to compile or generate game assets from their source assets and then check the generated game assets into the repository. They just check in their source assets which are then automatically built into game assets and deployed to all developers. To test the new automated build system we decided to make another small game. Gavin and I are going to do most of the modeling so we can become acquainted with Maya. The game is a simple target range where you can shoot at various objects. As a result I felt compelled to name our current milestone “Hogan’s Alley”.

We finally got internet at our new place today. The release of our Pub Crawl milestone should happen shortly. We also replaced our old 100 Mbit networking hardware with new 1 Gbit switches. I was worried about the cost being too much for the extra speed. I was also worried that we wouldn’t see a big difference in our transfer rates. After hooking up the new switches my worries were quickly put to rest. The new transfer speeds over the network are wonderful and it was worth every penny. If you are deciding whether or not to switch to Gigabit Ethernet I highly recommend you do. If your computers don’t have Gigabit Ethernet cards you can pick them up pretty cheap and the money saved by using 100 Mbit hardware will not justify the slower transfer rates.

We have been hard at work on our fourth milestone titled ‘Pub Crawl’. All of our major goals were finished by our deadline on Sunday. This included creating ScriptNodes, updating snTools, and creating a small game to test them. I went into the milestone with the idea of creating a hacky throw away game system which sole purpose was to test the ScriptNodes. The system turned out better then I thought and we began to gain some insight into how our actual game system might operate. Denrei has been working endlessly on modeling the pub and its characters. His apartment filled with water during the flood and I think he has been living off of Zebra Cakes and Chipotle as it’s all I have seen him eat. Our milestone most likely won’t be publicly available for a little bit because of our big move to the new apartment. A lot of our time this week will be spent packing and unpacking. Not to leave you hanging here is a development screenshot of Pub Crawl.