I’ve spent a bit of time fooling with javascript this past weekend. It really is okay, but I came across a few scoping gotcha. Scoping defaults to global, so

function fnc1() { a = 5; } fnc1(); alert("a: "+a);

Will show you that a is 5. I’m more used to languages that default to a local scope. To get variables into a local scope in javascript, this example should be written as:

b = null; function fnc2() { var b = 5; } fnc2(); alert("b: "+b);

Will show you that b is null – as expected.

I’ve been using open source software for well over 10 years. Here are some stories of times when I’ve had brief interactions with communities regarding “bugs”.

Back in 2001, I tried to submit a “bug report” to the php project – I had discovered that in certain cases a function worked slightly different than advertised. My report was dismissed with an RTFM and flagged as “Bogus”. I was a bit put-off by their response, as I had RTFM (and demonstrated that clearly in my report.) The problem with my report is that I was complaining about an edge case that wasn’t really a bug. It just wasn’t worth their time to really understand what I was getting at.

In 2003, I submitted a bug report to the dosbox project – I discovered several games that I wanted to work with the software that didn’t. I offered my help in fixing the bug. My report was greeted with open arms, my offer to help fix the bug lead the maintainers to give me tips on how to troubleshoot the issue. Not being an accomplished ASM debugger I wasn’t able to get very far in my work. They saw that I had given it “the ol’ college try” and were happy to fix it for me. (I decided to sweeten the deal for them with a small donation to the project.)

Earlier this year, I had some trouble with rsync. I was losing connections part way through the backups. I realized that it probably wasn’t an issue with rsync but with my connections. I read over all the help information and found nothing addressing my issue on the rsync website. After talking with a few of my sysadmin contacts, they were able to help me track the issue down to a problem with my ssh setup (which was using default settings.) I was then able to write up an informative message to the rsync mailing list suggesting an addition to their FAQ which I felt would save people in similar situations hours of research. They updated the FAQ with the information I provided.

A bit later in this year, I submitted a small patch to rsync fixing a trivial problem with building in a certain hosting environment. This message went ignored. Since it was a one line fix for a problem which likely only happens to me, it seems that may have been the right response on their part. (Especially since, thinking over it, my patch may very well be the wrong thing to do for most environments.)

All that to say, from my experience it really seems that the more I put into reports and patches the more likely I am to see results and a positive response.*

*read this if you haven’t: How to Report Bugs Effectively

A day in advance I’ve completed my pyweek entry! And, to be honest, my pyweek entry was more the completion of the pug.gui than the “game” I made. Some final stats on pug:

• gui.py is 31360 bytes
• theme.py is 7428 bytes
• 16 widgets included in the core

The theme is easily extensible – while maintaining separation from the Widget core. Themes can respond to events (play Sound effects), have per-frame loops (shrink/grow/change colors), and be styled using the CSS Box model. Here’s a couple fun screenshots:

The default theme:

The “game” with even more custom theme and Widgets:

I decided not to actually enter my entry into the pyweek judging mainly because it wasn’t a game, but also my “non-game” was utilizing pug, which wasn’t released a month ago (per pyweek rules for personal library usage.)

On a more “game design” topic, I’m a lot more comfortable creating arcade games, as that’s more my style. Games that involve your typical “gui widgets” just don’t excite me very much. The rational behind creating pug is that games do need good menus and options screens for the times when you aren’t playing the actual game. Many of my “core” widget choices are based on the primary use case I have for pug.

Since pug still isn’t up to the 32k limit, I’m likely to add in joystick support as well as add more information into the docstrings. There are a number of widgets I could include, but I don’t feel that the primary use case allows for those. (Users will be free to create “contrib” widgets to be placed into the “contrib” folder and will not be supported by me. I might even add in some “contrib” widgets – a secondary use case is quick game dev / level making tools. You need file pickers and dialogs for those – both of which I’ve developed for pug already.)

If you want to give pug a whirl: svn://www.imitationpickles.org/pug/trunk

-Phil

I’ve been working on a re-write of my pygame based gui PGU. I found, that as PGU grew larger I was less inclined to maintain it. It became harder to add new features and harder to maintain existing ones. At present, PGU is pretty stable, but it’s also pretty large and likely not going to change.

While working on Galcon, I added the ability for users to add their own python mods to the game. I wanted to give the users the ability to add their own option screens using a simple gui system, which, just for giggles, I decided to make sure it was less than 32k of code. After I had written this system “gui.py” it occurred to me that not only was the API simpler than PGU it also had most of the features PGU had! (As well as quite a few PGU didn’t have.) My simple 32k gui.py was rivaling my 250k pgu.gui!

I came up with a theory of sorts: “Any useful library can be written in 64k or less.” Of course, I wouldn’t swear by that, but I figured I’d give it a try. I’m working on getting more functionality than PGU had into my new PUG library. So far so well, I’m keeping the gui.py <= 32k and the theme.py <= 8k. So far I have a cleaner API with more features than the original PGU. However, keeping it smaller than 32k requires me to make quite a few trade-offs. I can't have all the features I included in PGU. The real challenge now is deciding “is this feature important for almost all games, or is it a bit frivolous” … I’m sort of cheating by putting those frivolous widgets into a contrib/ folder. At the same time, it’s helping me keep the core small and maintainable. Anything found in the contrib/ folder may very well be quite useful, but I can also claim it is unsupported and not have to worry about it.

My arbitrary rules for PUG development:

• the code in pug/ must be <= 64k
• gui.py <= 32k
• theme.py <= 8k
• code must be readable
• names must be readable
• use 4 spaces for tabs
• must include complete docstrings

A number of those rules are in place to keep me from “cheating” to get the file smaller. I hope to wrap up a useable version today .. and then begin working on my pyweek entry!

If anyone is brave and wants to try the alpha: svn://www.imitationpickles.org/pug/trunk

-Phil