Skip to content

simple twitter mercurial hook

Monday, March 30, 2009

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)

If you have problems with mercurial 1.1 and lower, try removing the diffopts argument from changeset_templater() so it looks like:

t = cmdutil.changeset_templater(ui=ui, repo=repo,
                                   patch=False, mapfile=None,
                                   buffered=False)
Filed in mercurial | | Comments (7)

Using XBMC for Linux with an XBOX 360 Wireless Controller and the Userspace USB Driver xboxdrv

Saturday, September 13, 2008

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.

Filed in media center, xbmc | | Comments (23)

Switch to DVORAK

Tuesday, February 19, 2008

I recently switched from a qwerty keyboard to a dvorak keyboard. If you want to see why an idiot like me would switch to a keyboard layout that is used by less then 1% of the population, then checkout the wikipedia article. I highly recommend the dvorak layout if you enjoy causing yourself unnecessary mental anguish with the slight possibility of increasing your typing speed. It’s also fun when you have to use someone else’s computer, and you have to tell them to wait 4 minutes while you mentally prepare yourself to use a qwerty keyboard. After looking like you have never typed before, because your hitting the wrong keys, you ask them if you can switch their computer to dvorak. They promptly tell you to go to hell because you are elitist douche bag.

Filed in random | | Comments (0)

Atari 2600 reviewed in 1981 by a guy from 2007

Thursday, February 15, 2007

I recently received an Atari 2600. Naturally I decided it would make more sense to write about it from the perspective of a man who traveled back to 1981 from present day. It’s sort of like a person moving to Phoenix, Arizona to work remotely for a company in Chicago, Illinois but instead of Phoenix, Arizona I am working remotely from 1981. To be more specific and to make the example more confusing I will be reviewing the system from the 1981 Chicago suburbs. I will be experiencing technology in the 80’s as most people living in the Chicago suburbs did at that time which was mostly through technology from the late 70’s.

It’s my first day since I moved to the 1981 Chicago suburbs. I am pretty bored. I was able to get my hands on an Atari 2600. I think my uncle bought it in 1979 and somehow I got a hold of it. When I pulled it out of the box the first thing I noticed was the front of the Atari appears to be made out of wood. Nothing makes a piece of technology look more advanced then when its made out of wood. The worst part is its not even real wood. Its black plastic with some sort of wood pattern on it. Somebody at Atari stood up at a board meeting and was actually like “Black plastic seems a little cheap looking don’t you think? I’m pretty classy and my coffee table is made of oak so this piece of technology should also be made of oak. Lets class things up by putting some fake oak wood panels on there.” Everyone else agreed with him. By everyone else I mean everyone else in 1977. Don’t get me wrong oak is very classy for a dining room table, a book shelf, or any item where wood has proven itself valuable both functionally and aesthetically but that doesn’t mean my electronics need to be encased in it or emulate its look. After the initial shock that someone would surround technology in oak I was shocked to find that it goes rather nicely with everything else in my living room. This includes my TV which, for some reason, is surrounded by oak too. I decided to place the Atari 2600 in my oak entertainment system cabinet and to my surprise it blended in perfectly because my stereo speakers, receiver, and record player all have oak cases. Good work Atari on that oak patterned front panel for the 2600.

I found that the power cord and TV wires were very long. This is pretty nice compared to systems from 2007 but seemed unnecessary because the system was so close to the TV in my cabinet. I hooked up the 2600 to the TV and attached these two little VHF prong things. I put the system on channel 3 and turned on my TV. I then looked through the games and found Super Breakout. I plugged it in and sat down on my couch. I quickly realized why the cords on the Atari 2600 are so long. There are no menus to start the game. The game select and game reset switches(I use the term switch instead of button because that is whats on the system. A huge dead man switch that you pull down on) are on the actual console so in order to start or reset the game you have to stand up and walk over to the console which is in my oak cabinet on the other side of my oak coffee table.

After moving my Atari 2600 to the couch next to me I pulled down on the game reset switch and started playing Super Breakout. It’s amazing. Using the analog paddle controller is awesome and I had such great control over the in game paddle. It makes it more like an arcade game. When I got past the last blocks my on screen paddle halved in size and the ball was flying so fast. I finally got my score up to 309 and was extremely proud of myself only to find there is no storing of high scores. You have to write it down or just remember it. After playing for awhile my best score was 428 but no one will ever know unless I am around to tell them and even then there is really no way to prove it.

I was extremely surprised at how fun the Atari 2600 was. I also played asteroids but I don’t think that game was ever fun in any form so I didn’t count it. When I was done playing I switched the Atari cable back to television and Trapper John, M.D. was on CBS so I just stared at a wall for 3 hours and then fell down. Perfect ending to a perfect day.

Filed in random | | Comments (0)

Getting File Changes From Buildbot

Friday, January 19, 2007

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)

You can use the new ShellCommandChangeList class in the same way you use the ShellCommand class. The only difference being the ShellCommandChangeList class will append a list of changed files to the end of the step’s shell command. We use a similar class and method at Stolen Notebook to build large source asset files (models, levels, art, etc.) automatically with buildbot when they are checked into our repository.

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"])

Lets say two files named main.cpp and main.h are changed in the src directory of our svnurl and submitted to the repository which triggers this build. The normal ShellCommand step would just call “checksum” remotely. The ShellCommandChangeList step on the other hand would call “checksum src/main.cpp src/main.h”

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.

Filed in buildbot, sysadmin | | Comments (3)

Buildbot as a Windows XP Service Part 2

Monday, January 15, 2007

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.

Filed in sysadmin | | Comments (2)

Ecosystem Games

Saturday, November 11, 2006

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:

“Initially, the idea of S.T.A.L.K.E.R. was a complete simulation with no plot, when any of the stalker-characters could finish the game. Unfortunately, it was not possible to implement this idea, since players did not understand why after they have been playing the game for three weeks they suddenly saw the “Game Over” screen, when some other stalker passed the game. The main concept became plot-oriented. The game gained a storyline that the player can go along from the first mission and until the end. But this storyline got a simulated world. You can go along with the story or go sideways. You can explore the world, do sidequests.”

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.

Filed in random | | Comments (0)

SNTask Utility

Tuesday, September 5, 2006

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 will know immediately when there have been changes to files.

Filed in sysadmin | | Comments (1)

Conversations at 150 yards can be awkward.

Wednesday, August 30, 2006

I proved an important theory today. Having a conversation at 150 yards can indeed be just as awkward as a conversation from 3 feet away. I often look down from my apartment building and spot people I know. I find it amusing to call them on their cell phones and notify them that I am judging them from an elevated position. Then, I tell them exactly how and why I am judging them and hang up. Sometimes I keep it short and sweet. If you know me, and are walking past my building, it is not uncommon to receive a phone call and hear “Nice pants loser. Ya’ll just got judged!… CLICK”. If you quickly turn around and look up at my floor, you might catch me ducking behind a sofa. Anyway, today one of my friends managed to pull me into an awkward conversation about network cards before I was able to judge them. The conversation was fine but it was made awkward by the fact that the person I called stopped and looked at me while having the conversation from 150 yards away. It’s very odd to make extreme gestures like you are yelling to someone far away but then be talking in a normal voice. The entire experience was terrifying. I’d like to try it again someday. Finally, incase you were wondering, I actually yell the work “CLICK!” before I hang up a phone.

Filed in random | | Comments (0)

Automated Build System

Monday, August 28, 2006

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”.

Filed in game, sysadmin | | Comments (0)