Older blog entries for sab39 (starting at number 46)

logic: The reason for existence of CSS2.1 is precisely to trim down the CSS2 spec to parts that are (a) reasonable and (b) widely implemented. The W3C now have procedures to ensure that the specifications they write are implementable and well-defined, but these procedures did not exist (or perhaps weren't followed) for CSS2 - if CSS2 were being pondered now, it could never leave Last Call Working Draft status.

CSS2.1 is essentially the subset of CSS2 that could leave Last Call status right now, with a few extra features pulled in from CSS3 because they're already ready to leave Last Call. CSS2.1 will therefore, unlike CSS2, be supported by all major browsers as soon as it's released, because being supported by multiple interoperating implementations is one of the requirements to exit Last Call.

lindsey: You sound like you might want nrdo. If this sounds like the sort of thing you're after, be aware that the publically-available tarball is fairly old - email the mailing list if you're interested and I'll throw up a newer one.

It doesn't (out of the box) generate the web pages themselves, but only the classes for representing rows in the database for persistence. On the other hand, it does generate the tables themselves in the DB, so you're saved the trouble of even creating them.

I experimented for a while with having nrdo actually generate web pages - in fact I have one project which actually does that. It turned out to be highly counterproductive - in order to cover all the variations of form field type I wanted, I had to allow so many different customization hooks on each field and each page that I ended up with an unmaintainable mess (and I still have to maintain it!). With that in mind, though, you're still welcome to try it: nrdo provides a language in which new code-generation templates can be written, and so you can write one for form pages if you want to.

lkcl: The license you propose would certainly exclude Debian from distributing it (at least in their 'main' section) since it doesn't come anywhere near complying with the DFSG. Your best bet if you really want to make life a pain in the neck for commercial enterprises (which seems somewhat counterproductive to me, but it's your code) would be to pick a license that has requirements that would be unpalatable to the companies in question, without mentioning them specifically. For many companies, that would be the GPL (because the requirement to release their own changes is anathema to proprietary software companies) but presumably that wouldn't apply to the companies you want to piss off.

Better yet, release it under a regular open source / free license, hold on to your own copyright (and require copyright assignment to yourself for significant contributions), and just plain don't take it personally when people do things you don't approve of with your code.

And if you don't want to have your programming skills exploited, take a job that doesn't involve programming at all, because the things you considered exploitative had nothing to do with open source and everything to do with paid employment in general and the specific employers in question.

You're clearly a spectacularly talented programmer - anyone who read KC Samba at the time period in question could tell that. Let your code speak for itself.

etrepum: I hadn't seen the two tools that you pointed out to me, but they still seem to be the same kind of tool as the ones I had already found: graphical diff or merge tools, rather than graphical patch tools. That is, they all seem to be equivalent to one or other of the following *nix commands:

diff file1 file2 | patch file1

or

diff3 file1 file2 file3

What I'm looking for is something equivalent to this slightly more general command:

diff file1 file2 | patch file3

The important difference is that the file being patched, file3, is (potentially) unrelated to the files being diffed. I need this because the scenario I'm dealing with is a repeated branch merge, which means that I'm not just dealing with a common ancestor, but with different ancestor files (that are derived from the same common ancestor at some point in the past, but have diverged and been merged already since then, so I don't want to merge all the way back to that common ancestor).

So what I need to do is equivalent to "take the changes that have happened on the trunk, and patch them into the branch". I just find it unbelievable that nobody's produced a graphical tool capable of doing that. Graphical diff programs seem to be one of those things, like AIM/ICQ clients, that everyone feels a need to write - but nobody thought to provide the basic features of patch when they did so...

Graphical patch tool

In the past half hour or so I've found at least a dozen different graphical "merge" tools for windows, which all seem to amount to a graphical diff with the opportunity to pick either the left or right version on a per-difference basis. The more sophisticated ones also support three-way "common ancestor" merging.

But it seems to be impossible to find a graphical tool offering the same basic functionality as patch itself. That is, take the differences between file1 and file2, and apply them to file3 with graphical conflict resolution. I'm trying to write a merge script for handling repeated merges of the same branch under a source control system that doesn't support this function, but I don't want to force users to manually deal with ".rej" and ".orig" files. A tool that I could launch from the command line that would be equivalent to "patch" if there were no conflicts, or produce a view something like one of these graphical "merge" tools for any conflicts if there were any, would make my life extremely easy.

Does anyone know of any such tool? I need one that works on Windows, but of course supporting Unix too is a plus because then I can write my tool portably. I find it hard to believe that no such thing exists - it seems such an obvious extension to "patch"...

Bram: I think that your "Straights and Queers" game can be formulated differently and in a way that makes it clearer that both players actually are equivalent to each other. Consider it as "North&South" versus "East&West", and pieces capture clockwise (or anticlockwise, if you prefer). This is equivalent to the game as you described, but avoids the political / social baggage of the terminology, and also the apparent (but illusory) asymmetry between the two players.

Your diary got me thinking about whether my proposed game could be played in a simultaneous-move mode, and I think it could. You'd just need some dispute-resolution rules. I think these rules would be sufficient:

  • A move must be legal in the state of the board at the beginning of the turn - you can't attempt a move in "hope" that the space needed becomes free.
  • If two pieces "advance" into the same space, neither piece is placed in that space. This is not considered a capture and neither player gains points for it. An "advance" move, per the rules, involves placing a piece in two separate spaces: these two placings are treated independently. Either way, the piece that attempted the advance is still removed. Thus if both the spaces are contested, the pieces making the advance disappear entirely.
  • If the target of an "attack" moves out of the way at the same time, the attack move is "successful" but the piece is not considered captured, and the move out of the way is successful also. One particular example of this rule is if an OOXX line exists and both players attack simultaneously - the line becomes OXOX and neither player is credited with a capture.

I'm hoping to put together some kind of html-based implementation of this game - once I get the alternating-play mode working, I might try to get the simultaneous one working too...

17 Jan 2003 (updated 17 Jan 2003 at 14:27 UTC) »

Rule change

Still no implementation in the forseeable future, but I thought a little bit more about the rules of the game I described in my last diary, and identified a problem: the results of the "attack" move can be immediately reversed by the opponent by another "attack" (for example, with OOXXX in a line, O attacks giving OOOXX, X can attack back and revert it to OOXXX). This kind of endless cycle of play is what the "ko" rule in Go is designed to prevent, but I felt that a ko rule would be over-complex for this game, so I tried to think of an alternative to the attack rule as stated.

One idea I kept coming back to was that in place of the existing rule where an attack makes OOX into OOO, it could instead make OOX into O-O (the hyphen being a blank space). The scenario above would then be impossible, because the sequence would become OOXXX => O-OXX => O-X-X, so no further attack is possible. I kept rejecting this because it causes a scoring problem - with this rule, every move except for "sacrifice" causes a net gain of one token on the board compared to the opponent, so the only way to gain a score advantage was to force the opponent to sacrifice. That seemed like it would force every game to get rather drawn out, as one player would have to completely dominate the board and force lots of sacrifices to win.

Eventually I realized a different natural solution to this problem. Instead of trying to formulate an attack rule that causes the number of tokens on the board to increase by the right amount, I could change the scoring system to get the same effect by counting each "captured" token as a point as well.

So here are the revised rules...

The board is a hexagonal grid of tesselated hexagons, something like this (the one shown is 6*6*6 giving 91 cells, slightly bigger than a chessboard, which seems about right - but alternative sizes are certainly possible). The game starts with each player having a single token, in the places marked by an X and an O in the linked text file. The starting player is chosen at random.

Players take it in turns to move. There are three moves available in the game:

  • Advance: Remove one of your tokens from position A and place two new tokens in positions B and C instead. B and C must be adjacent to each other, and both must be adjacent to A (that is, A, B and C must all be adjacent to each other).
  • Attack: This is permissible only when three tokens form a straight line, the first two (in order) being yours, and the last being your opponent's. The opponent's token is removed from the board and the middle token is moved into its space. The attacking player keeps the opponent's token, which is said to have been captured. Captured tokens cannot be used in the game, but count towards the player's score.
  • Sacrifice: Remove any single one of your tokens from the board. This move is permitted at any time except when you have only one token on the board, in which case it is permitted only if there is no other move you can make.

Scoring is as follows: Each player gets a score equal to the number of tokens they have on the board plus the number of captured tokens they hold. The player who went second has an extra half-point added as a handicap. The game is won when the difference between the two scores becomes greater than ten points (again, nothing special about ten, it could be any number that makes the game work well), or when one player is forced to sacrifice his last token.

16 Jan 2003 (updated 16 Jan 2003 at 18:21 UTC) »

So many ideas to follow up on, so little time...

... one of which I'm going to document here so that at least it doesn't get completely lost. I came up with an idea for a board game that I think would be at least somewhat interesting. So far I haven't done anything about it except for thinking up the rules, but there's not an obvious immediate winning strategy that I can see so far, so I think the game has a chance of being playable.

The board is a hexagonal grid of tesselated hexagons, something like this (the one shown is 6*6*6 giving 91 cells, slightly bigger than a chessboard, which seems about right - but alternative sizes are certainly possible). The game starts with each player having a single token, in the places marked by an X and an O in the linked text file. The starting player is chosen at random.

Players take it in turns to move. There are three moves available in the game:

  • Advance: Remove one of your tokens from position A and place two new tokens in positions B and C instead. B and C must be adjacent to each other, and both must be adjacent to A (that is, A, B and C must all be adjacent to each other).
  • Attack: This is permissible only when three tokens form a straight line, the first two (in order) being yours, and the last being your opponent's. The opponent's token is removed and replaced by a new token of yours.
  • Sacrifice: Remove any single one of your tokens from the board. This move is permitted at any time except when you have only one token on the board, in which case it is permitted only if there is no other move you can make.

Scoring is as follows: Each player gets a score equal to the number of tokens they have on the board, except that the player who went second gets an extra half-point as a handicap. The game is won when the difference between the two scores becomes greater than ten points (again, nothing special about ten, it could be any number that makes the game work well), or when one player is forced to sacrifice his last token.

If I ever get a chance, I'd like to write a web-based version of this game to see whether it actually works. But if anyone else is interested in the idea and thinks it might be worth pursuing, go right ahead...

So Savannah accepted nrdo but I can't upload the files into CVS until I've removed the non-free dependencies, which is fair enough. I've set up the homepage and added a task to the task manager for adding Postgres or MySQL support. I also created a mailing list, in theory. I say "in theory" because although the list appears to be there and functional, if I try to subscribe to it, nothing at all appears to happen. Perhaps there's a delay beyond the list-creation delay until the list actually starts working...

Wow - I just got permission (that I'd been hoping for for several years) to release nrdo as open source. The homepage is somewhat lacking at this point: most of the documentation is inside the source tarball. There's some discussion about what nrdo is in my comments to lkcl's recent article "Python Database Access". I'm sure I'll be talking about nrdo more in future diaries...

I've emailed the Savannah people to see if they'll bend their "no non-free dependencies" rule for dependencies that I'm actively working to remove. Still waiting to hear back, although I can't check my mail from here so I might have a response but not know it yet...

37 older entries...

New Advogato Features

New HTML Parser: The long-awaited libxml2 based HTML parser code is live. It needs further work but already handles most markup better than the original parser.

Keep up with the latest Advogato features by reading the Advogato status blog.

If you're a C programmer with some spare time, take a look at the mod_virgule project page and help us with one of the tasks on the ToDo list!