January 31, 2004

news flash: sloppy focus sucks

I am sorry but I just don't understand people's love of sloppy focus and corresponding hatred for click-to-focus. With sloppy focus you're even more dependent on your mouse...you have to keep it positioned over a window to keep it active. If you alt-tab to a new window you've gotta move your mouse over to it too. And if your mouse drifts off to the root window, all of a sudden you're losing keystrokes. What programmer wants to lose keystrokes? What programmer wants to constantly think about where his mouse is? This is idiocy. You supposed linux programmers foaming at the mouth about the greatness of sloppy focus are idiots.

Cygwin's integrated XWin window manager is sloppy focus & I can't figure out how to change the policy to click-to-focus. This is frustrating.

Posted by Alan at 04:41 AM | Comments (3)

January 24, 2004

thoughts on data-centric apps

If I had my way this is how the typical data-centric (heavy on database & presentation layers, light on the logic layer) app would be written: in Perl; no classes or XML schema definitions, just straight sql tables (so no representations of the same thing to keep in sync); serialization between the db and Perl done automatically into nested hash structures, with foreign keys determining nesting structure; nested hashes serialized to and from xml via XML::Simple; presentation logic controlled by xslt & whatever glue is necessary.

I see far too many projects (my own KB, for instance, or our CSTS project last year in DS) mired in just the problem of converting data between various formats. Seems like with these projects 90% of the code is devoted to that and only 10% to *actually doing something*. So we need to make this conversion as inexpensive and automatic as possible.

Posted by Alan at 03:52 PM | Comments (0)

January 15, 2004

vc# irritations

After one day with VC# 2003 Enterprise Architect Edition, I already have following list of irritations:

  • Cannot specify where intermediate object files go--they are always put in an obj/ subdirectory relative to the project file.
  • By default, adding an existing item to a project will make a new copy of the file in the project file directory. This would render true reuse of source files across multiple projects impossible. However, you can add an existing item to a project as a link--you just have to notice that the "Open" button is actually a dropdown button. Which I never would have noticed on my own. One wonders why this is not the default behavior.
  • Using devenv from the command line, it is possible to build a solution with devenv /build, but devenv /clean is broken and does nothing. All object files and target files remain untouched. This is a very basic build action which doesn't work.
  • Project files are stored in an xml format, but this format is undocumented and the xml schema for it is unavailable.
Posted by Alan at 11:25 AM | Comments (14)

January 11, 2004

connect-4 and rule-based play

Yeah I think Connect-4 is gonna be more than I bargained for, ie rather than using a brute-force lookahead it would need a lot of rule-based play and positional analysis. Check out the following link on expert play in Connect-4.

Posted by Alan at 09:44 PM | Comments (0)

January 06, 2004

link order

Here's a crummy problem I ran across the other day. I had this line in a Makefile:

g++ -L../../lib -lgamework -o Connect4 $(objects)

The compiler wouldn't pickup any of the symbols from the libgamework.a library, as if it wasn't even being linked in. I assumed this was some weird problem related to namespaces and static linking. However, it turned out the order of link args is important, because this worked:

g++ -L../../lib -o Connect4 $(objects) -lgamework

The symbols referenced by $(objects) are resolved when they're found in libgamework.a. If libgamework.a is the first arg, none of it ends up in the executable because no symbols need to be resolved at that point.

Posted by Alan at 03:51 PM | Comments (0)

January 03, 2004

connect-4 not so great

Well I got around to implementing Connect-4 under GameWork. Took me all of 2 hrs, but the AI stinks. The problem is not a big branching factor. As noted before the branching factor is at most 8, and this even tends to decrease as columns fill up. The problem (I think) is that the game isn't won slowly, by degrees, but all of a sudden. Unless I can find a way of objectively valuing the intermediate game states the lookahead will continue to stink.

Posted by Alan at 04:14 PM | Comments (0)