Recent blog entries for thraxil

thomasvs wrote:

As a side note, this application also needs to do some string processing and perl is really terrible for that. I hadn't noticed that ever before, but looping over a string in various directions is just so much easier in C.

perl has its downsides, but not being good at string processing isn't usually included in that list. arguably, perl's greatest strength is string processing. could you elaborate on what kind of string processing tasks you find easier to do in C than in perl? are you maybe just not familiar with the wonderful world of regular expressions that perl puts at your fingertips?

ESR gave a lecture at the New School in NYC earlier tonight. i took copious notes if anyone is interested. some great stuff in there.

Bram, the Roshambo strategies you describe sound similar to some of the old Prisoner's Dilemma tournaments i've read about. from Game Theory and Strategy, by Philip D. Straffin:

Axelrod invited professional game theorists to write computer programs to play iterated Prisoner's Dilemma, and then conducted a tournament in which each program played all the other programs. Fourteen programs were entered, some of considerable complexity. The winner was a four line program submitted by Anatol Rapoport, called TIT FOR TAT. Its instructions were:

  1. Start by choosing C [cooperate].
  2. Thereafter, in each round, choose whatever your opponent chose in the previous round.

In other words, "Do unto your opponent what your opponent has just done unto you."

[...] A more general conclusion comes from Axelrod's analysis of programs which did well. They tended to share four properties with TIT FOR TAT. To do well, a strategy should be

  • Nice. It should start by cooperating, and never be the first to defect.
  • Retaliatory. It should reliably punish defection by its opponent.
  • Forgiving. Having punished defectionn, it should be willing to try cooperating again.
  • Clear. Its pattern of play should be consistent and easy to predict.

It is tempting to speculate about the extent to which these four properties might characterize successful social behavior in competitive situations.

not really directly applicable to the Roshambo stuff, but i think it's interesting and you reminded me of it. and game theory is generally just cool.

wow. it's been a long time since i've posted here...

(tool-bar-mode -1) appears to be the magic incantation to turn off the toolbar in emacs 21. thanks a. p. garcia and Sean Neakums.

so i've been secretly recoding the backend for my community weblog. i wrote the last version a year ago. having spent the last year writing a few hundred lines of perl a day, my skills have improved and it pains me to look at the old code.

one of the features that i've come to rely on heavily is the web-based categorized, hierarchical bookmarks. however, i'm thinking for the new version i'll abandon the inherent problems of categories and hierarchies and switch to keyword tagging. while thinking about it last night, i realized that it's inherently a more powerful system. with categories, i could place a bookmark in "programming/xml/tutorials". with keywords, i can duplicate this just by tagging it with 'programming','xml', and 'tutorials' but still be free to add other keywords like 'functional programming'.

there were ways to essentially do this within a hierarchical structure by either making copies of the bookmark in multiple categories or implementing something like symbolic links. either way, things are ugly and get uglier if your hierarchy isn't well thought-out from the beginning. keywords seem like an elegant way to sidestep these problems.

thinking about this has renewed my interest in filesystems like reiserfs that begin to implement the 'filesystem as a database' idea. must research further. must code more first.

discovered that both the docbook ide and xslide emacs modes don't work yet in emacs 21. damn. they're both super useful. hopefully they'll be updated soon; i've come to rely on them for a lot of my work and would hate to have to downgrade back to 20.x just because of that.

if anyone knows off the top of their head how to turn off the new toolbar, let me know.


you're right, i was going from CVS. tarballs were hard to come by yesterday.

it compiles fine on my redhat box at home. configure does complain that i don't have some of the libraries (Xaw3d, ungif, etc) but i know that these are installed on the machine.

i'll do some investigating and see if i can figure out why it's not finding them. thanks for the help though.

i attempted to compile the new version of emacs today. it only sortof worked.

grabbed the new emacs-21 and leim tarballs, unpacked them on my mandrake box at work, ran ./configure and make bootstrap and make install. the compilation succeeded but there were lots of warnings about X related things (font libs, etc). i can get the new version to run but only in console mode; no nice X windows mode. :(

i was particularly disappointed in the quality of the INSTALL doc that came in the tarball. for a project that's been around as long as emacs, i'd have figured that it would at least contain instructions for a basic compile with the standard options enabled. actually, if you follow the instructions in INSTALL, you can't even compile emacs on a basic linux box. it says to do ./configure, make (which will not work), and make install; no mention at all of make bootstrap.

actually, i've noticed this kind of problem with the documentation for a lot of open source projects. i feel like i have a much better chance of finding an answer to my problem if my problem is advanced and obscure than if it is something simple. i can't even count how many times i've compiled an app or installed it from a tarball only to find that the executable installed doesn't have a guessable name. so i've installed a program on my system and now i have no idea how to run it or get any info on it (man doesn't work too well if you don't know the name of the program). luckily, i'm savvy enough to do a quick find for the newest executable files on my system or to read through several levels of complex makefiles and install scripts to figure out what went where, but i can imagine the frustration of a user who didn't know how to do this.

so basically, i'm going to try on my projects to always make sure i include all the documentation that a user needs to get up and running with the standard options enabled on a basic system without too much fuss. it doesn't seem like it should be that hard.

New Advogato Features


