dgoodwin's blog

I rewrote most of the GTK table code earlier in the week (have I mentioned how much I love Glade 3?) to now look *almost* like something that could actually resemble a poker table. Should now seat 10 players instead of the previous 4. Dozens of general gameplay commits to keep things running smooth, it's actually quite playable at the moment, we ran through several hands in a network game a couple nights ago and it seemed to be working fine, although it's a little disorienting when you're used to the sounds in actual online poker clients.

Between bowes and Kenny we've got a curses UI moving along, as well as a replacement hand evaluator that's not quite finished but when it is, will relieve the dependency we have on the non-Python pokereval code. Another friend is reportedly hacking on support for various graphical cards which will be an awesome addition.

"sudo python setup.py install" should now get you an installed and playable version of rounder-server, rounder, and rounder-txt (not yet completed).

Account creation is stalled due to some missing functionality in Twisted for anonymous logins when using perspective broker. Fix is coming out in Twisted 8, not yet in Fedora so I'm waiting for that to appear before I apply the patch to start us down the path. Once it's in logins will be anonymous, your avatar received then will only allow you to do certain things, among them create yourself an account, and of course login. This and chat (which will be super easy) are the only two things on my mind grapes that need to be done for a 0.0.1.

More info available on the project page for those interested.

After two days of obsessive coding Rounder is now in a playable state.

If you'd like to try it out:

1. Manually install the dependencies listed on the rounder project page.
2. git-clone http://anongit.dangerouslyinc.com/rounder
3. Spawn a server by running the rounder-server script in the top level of the source. Will be listening on port 35100 and can accept outside connections provided your firewall allows them through. Four $1/2 limit hold'em tables will be automatically created.
4. Run the client with the rounder script. (again top level)
5. Login as player0 (or player1 - player9) / password. Each login can only login once, although if someone closes their client that login should be freed up again.
6. Double click a table and claim a seat
7. Repeat with another client and username, or have a friend connect remotely.
8. A player at the table must hit the Deal button to kick off a new hand.
9. Act as prompted throughout the hand and repeat when the hand ends.

Should be able to play for a good long while. Things may start going wonky as you near 0 funds, most likely if you have to post a blind that puts you all-in.

Meanwhile Kenny & jbowes have kicked off a curses text client that's shaping up nicely (see rounder.ui.curses package), my wife's going to take a shot at Gimping up a table graphic for use in the background, and I've started writing up an architecture document to walk through the high level layout, layers, and some of the decisions made for anyone looking to get involved.

Getting really close to a point where we could do a 0.0.1 release. Some important things that still need taking care of:

• Distutils installation. (setup.py)
• Account creation. (accept requests from clients but only create the accounts in memory)

Moving into our house in about a week and a half so probably won't release until after that, but wheels are in motion. Until then feel free to checkout and tinker!

Big milestone in rounder development tonight. Brace yourselves for what's likely the most unattractive poker interface ever created:

This is two clients connected to a server, viewing the same table, with the first network events being dispatched and rendered. (player joined table and player left table) It's not a hard scenario to replicate if you have the source checked out and the dependencies installed, just fire up rounder-server, then run the rounder executable right in the top level directory as many times as you like. The server is configured to accept about 10 logins of player0/password, player1/password, etc.

Things have been moving along drastically faster lately, I've been finding about an hour a night to hack on it as opposed to the previous average of few hours a month. Meanwhile Kenny has jumped into the fray with a patch I consider quite impressive. Following my previous development update post bitching about the logic involved with handling all-ins, he started reading code and composed a much simpler and more logical way to handle this core engine logic and implemented the whole thing.

Tonight's milestone, while quite unimpressive visually, indicates that there's a LOT of plumbing in place. Seeing those little events fly back and forth was extremely fulfilling. Getting a hand to play through is now a matter of hooking up a minimal amount of code to fire off a poker hand, and continuing to add client support for incoming events from the server. (most of these are implemented and being sent out server side, although I'm sure there'll be a few to come down the line)

Still a pile of work to be done before a 1.0 but we're getting there. All the project info you desire is available here.

Rounder (my attempt to build an open source poker client/server/community started last March) development continues at a slow and not so steady pace. I've basically been averaging two (short) coding sessions a month since October thanks to work and my stupid (i.e. awesome) PS3. Going to try to bump that up to a couple times a week and so far so good since overcoming a bit of an unpleasant hurdle I've been screwing around with for literally months. (handling all-in calls/raises)

Basic architecture overview, a core poker engine (objects like players, tables, games, and limits), and a networking layer consisting of a server objects (creates and organizes engine objects) and a client object (bad name as this exists on the server and dispatches events and action prompts to connected clients). The client side program isn't really written yet, everything is currently driven through unit tests.

Status right now, engine is quite functional but even after months of hammering on edge cases and writing any test I could think of to make the thing break (then fixing it), I'm absolutely certain there's still problems in there. Coding poker logic has turned out to be a bit of a challenge, just so many deviations and one off situations, and I've had a lot of trouble coming up with ways to keep the code clean and logical. It's well compartmentalized and objects should have pretty well defined responsibilities, but there's still a lot of if/else cruft in them.

Now that I'm relatively happy with how things behave when you get down to all-in calls and raises, I returned to defining the missing events sent out to all a tables observers whenever something happens. This is pretty far along and most events are now defined, soon it'll be time to write the client to actually listen for them.

Unit tests remain a thing of beauty, no disk/network access compromises (Ran 87 tests in 2.435s) and great effort has been made to keep the code *extremely* testable.

I'm concerned about the decision to use Twisted for the networking layer. It seems awesome for Python but I have this nagging feeling that sooner or later, I'll want to write clients in something other than Python.

Roadmap:

1. Finish off event notifications.
2. Return to edge case testing for a few more things.
3. Write account creation glue.
4. Complete server code to spawn a single table. (i.e. someone creates a server, friends can connect by IP and play)
5. Write a really ugly and simple GTK client to actually be playable.
6. Implement database layer. (sqlalchemy, may have to be bumped up in priority)
7. Complete server code to manage creation of tables/games.

So still a long way to go. For anyone interested in jumping into the pool the project is written in Python and stored in Git. You can browse source at this location and clone with git-clone http://anongit.dangerouslyinc.com/rounder.

I've fallen in love with Eclim this week. I spend most of my work day in the Java world and that generally means a lot of time spent in Eclipse. I run Vim on the side for all my XML and JSP work but Eclipse just offers too much power for Java development to ignore, despite the fact that I don't like actually using it to write text. And it's not that I think it's particularly bad at text editing, it's just plain, whereas Vim is flat out amazing at it.

I've seen a few attempted solutions for combining the best of both worlds and even tried Eclim a few months back, but it just wasn't working after installation and I didn't feel like spending the time to debug. I tried again this week however and it worked with little hassle, since then I've spent maybe 5 minutes a day in Eclipse itself.

The installer can be a little flaky, I had to run a second time but it then worked no problem, possibly because I had eclipse running during the first attempt. This installs an Eclipse plugin and then a Vim plugin. (probably a very good idea to backup your existing Vim config although I haven't noticed any problems)

Once installed you fire up a standalone server on the command line which exposes various Eclipse functionality to other editors and programs. The Vim plugin then talks to this and adapts the functionality for Vim using it's built-in intelligent auto-completion and compile error code.

To be honest I use (and wanted) about two features from Eclipse, compile on the fly, and auto-completion. Fortunately these are two of the features exposed by Eclim and they work very nicely. Every time you save a buffer that's part of a Eclipse Java project you'll get colored arrows on the left hand side of your buffer indicating lines with compile errors or warnings. The delay is very small.

C-X C-U brings up the intelligent auto-completion dialog, also works very well, although I use the normal unintelligent text auto-completion (C-N and C-P) a little bit more as they're faster.

This is pretty much all I needed to get myself free from Eclipse and I'm drastically more productive writing code in Vim. Vim's tabs and buffers and commands kick Eclipse's ass all over town. Best of all when you need to do something complex (refactoring especially comes to mind) you can fire up Eclipse for the specific task and then shut it back down. Your system's memory will thank you.

IMO these Eclim guys really did come up with a great idea for this, expose the Eclipse functionality and let other editors make use of it. For some strange reason using Vim makes my days a little more enjoyable so I'm particularly grateful for their work. I'd actually love to contribute some to the project if I can run across some feature ideas down the road.

Bravo Eclim devs.

Update to my evolving list of notes on using git in day to day development. In some cases these are just the best methods I've found thus far, comments and suggestions are welcome. Sorry for the raw format. :) Phasing use of cogito out for raw git usage, most of it is now gone.

Getting Set Up

Edit ~/.ssh/config:

Host git.dangerouslyinc.com
User herk
Port 2223

Checking out:
git clone git+ssh://git.dangerouslyinc.com/git/wuja

Identify yourself:
git repo-config user.name "Awesome Haxor"
git repo-config user.email "ahaxor@dangerouslyinc.com"

Update:
git pull

Commit locally:
git-commit -a

Workflow

• Work in branches.
• Git pull in master to keep up to date.
• Rebase branch against master.
• Merge branch into master if pushing. (i.e. with commit access)
• Format patch in branch if not pushing, wait for changes to appear in master via a pull.

Branching

List:
git branch

Create 'new' branch:
git branch new

Switch to branch:
git-checkout new

Publish local branch:
git push git+ssh://git.dangerouslyinc.com/git/revelation splashid:splashid

Checkout branch elsewhere:
git pull git+ssh://git.dangerouslyinc.com/git/revelation splashid:splashid

Merge master into branch:
git-merge master

Generating Patches

git-format-patch origin

Reverting Uncommitted Changes

git-checkout file-to-revert
git reset HEAD <file>

Diff

Generate diff between two commit IDs:
cg diff -r 0fa7b047ad8968f5996029071e04cb9b4f2831b9..234cde4eb65cc903e40a98f4d87eea9ae28f7ef4

Diff most recent commit:
git diff HEAD^ HEAD

Tags

Create and push a tag:
cg tag 0.0.5
git push --tags

Repositories

Tracking svn:
git-svn init svn://url
git-svn fetch
git-clone rhn.git newrepodir
git-svn dcommit

Creating a new remote repository:
# Upload .git dir
git --bare update-server-info
chmod +x hooks/post-update

Misc

Create a tarball for release:
git archive --format=tar --prefix=wuja-0.0.8/ HEAD | gzip >~/rpmbuild/SOURCES/wuja-0.0.8.tar.gz

Clone to send to someone:
git clone --bare my-project