Older blog entries for jameson (starting at number 23)

Eventful 1.5 weeks lie behind us now. The most interesting part for me was the new bug tracking system- this was my first real-code encounter with Python.
One of the other interesting problems was how to deal with badly behaving single-user code. SCI games sometimes loop over the GetEvent() system call without explicitly waiting (they didn't have select() or anything like this). It's not unlike the "repeat until kepressed;" thing I used to do back in my Turbo Pascal days, and it sucks about as much. FreeSCI tries to trap it now by using the most obvious route- it keeps track of calls to functions which wait explicitly or retreive time values, and, if none of these was called after two subsequent GetEvent() calls, it executes a "penaly sleep" period. CPU usage in some sequences dropped from 1.25 to 0.22, so this appears to be a useful optimization.
Traffic in the IRC channel has increased significantly. It's fun, of course, but IRC can easily distract from doing real work (although this doesn't appear to be a problem for most developers yet).

This appears to be pretty much the most convenient language I've used so far. From what I've heard, its integration into C appears to be pretty good, too, making it a good choice for scripting languages. Of course, it still has a few things I personally consider problems:

  • Indentation rules. Changing control structures sometimes becomes a battle between me and EMACS' tabbing rules. Also, they doesn't help with automatically generated code (this may not be what Python was designed in mind with for, though).
  • list comprehensions and static lambda expression evaluation are missing. I know, they're in Python 2.1, but that doesn't help much until the licensing issues have been resolved (alternatively, those could be counted as the problem).
I still have to check out some of the other functional languages around to be able to judge it more appropriately. However, I agree with most of the other opinions regarding it that this should make an excellent teaching language, and, thanks to its extensive libraries and C integration, a good language for general purpose programming and prototyping, too.

Rumors about Samsung ditching API are about- don't know what to make of that yet... OTOH, Samsung has information about the upcoming UP1500 board on their page, whereas I can't find anything about it on API's page...
Anyway, if we disregard politics for a second and examine the specs, this looks like just the board everybody and their 400W power supply have been waiting for: Compared with the UP1000, memory bandwith was doubled everywhere (more than doubled in some places, IIRC), including AGP, and it comes with SRM rather than AlphaBIOS by default. Seems to require an EV68, though, so I'm left to drool...
But back to programming: For some reason, Compaq's ccc appears to have problems if people pass more than 6 parameters into inline assembly blocks. This breaks the current alpha blending code, of course... Any ideas?

Well, it's been a while...

Slashdotted! Somehow, I had expected to rise to a higher level of awareness, or something like that. Well, can't have everything.
Anyway, we now have sound, tri-linear filtering (plus something I used to call bi-linear filtering which definitely isn't), alpha-blending on Alphas (see "Assembly" below- it's just a feature, so I didn't feel too bad coding this non-portably), and lots of bug fixes. I guess it's time to prepare for a feature freeze again...

Haven't touched that project in a while, but will get back to it soon- they're gearing up to the next release, so I'd better make sure cxx works.

It's been the first time since roughly two years that I touched assembly again, and it feels quite weird. The Alpha instruction set is so much different from the ia32 one I grew up with. With all of its extensions, it's not quite as clean as the original MIPS one, but the core concepts are pretty clean and RISC. I definitely don't mourn my ia32 assembly days.
It's really a pity that we (well, most of us, anyway) are stuck on the ia32 architecture because of "binary compatibility" issues. Shouldn't it be possible to do a complete flow analysis of a program, transform it into a device-independant representation (java bytecode comes to mind, although I'd prefer something more functional and tree-like... maybe RTL?), and then re-assemble it on an arbitrary target device? Sort of a ia32 compiler frontend.
Normal compilers generally have to make some concessions towards code generation; specifically, they need to be reasonably fast in order not to slow down the development cycle (used to be a major problem before harddisks and compilers with few passes became common- those advances pretty much killed off research in incremental compilers, but that's a different story). However, a cross-assembler would typically be run on a program that is known to be working already; therefore, if the cross-assembler itself was fully operational, it would not be required to be run more than once for each program; consequently, it could be slow as hell (hey, it should be possible to get Prolog to do that stuff by back-tracking...). External functions (e.g. DOS: Int 0x10, 0xa000 memory access) would still have to be modelled in some way, of course, but I don't see why this shouldn't be possible if we accept a moderate performance loss. Has anybody heard of a project like this?
Anyway, this is too much work for a project for the evenings; maybe I should look into this (or the theoretical aspect of it, at least) for my Master's Thesis...

Yeah, I'm back at work again. XPath, XSLT, Java, some business buzzwords, and roughly everything in between. This in itself would be pretty boring, but I just love the work atmosphere- being a research institute, we have enough time to think about things before we build them, and our bosses actually have some clue about the stuff they're doing (or, at least, are able to admit it and ask for help if they don't, which appears to be a surprisingly uncommon feature). Anyway, I got to install Debian/Sparc on a Sparc notebook (which didn't have working fd support). A rather fun and enlightening experience, until I got to the point where it turned out that 'sed' would segfault on complicated stuff, such as the stuff done in configure scripts. OK, NP, just grabbed the most recent release from the GNU ftp server, ran ./configure...
OK, well, maybe it wouldn't be quite that easy. Still, a manual compile didn't really improve the situation- it built, but it segfaulted all the same. So I took the BSD sed and tried to compile that. This was the moment where I realized that the BSD people care for OS independance in their system tools about as much as the GNU guys do...
Anyway, it works now. Anyone who wants a copy of the ported BSD sed, just give me a call.

"Retro gaming"
(Warning: Rant ahead)
That phrase sounds pretty weird to me. It's implication is that the games it covers are "obsolete" in some way, that they're more of a historic curiosity than an actual game.
I beg to differ.
Don't get me wrong- I whole-heartedly agree that there are great games with much better graphics and sound than, say, Space Quest 3 or Ultima 7, and that some of those games are actually fun and challenging.
(Of course I've grown somewhat out of touch with the "gaming community", so I'll just assume that there are any new games which fit that description...)
Still, how does that obsolete those old games? I mean, chess or Go are ages old, however someone playing them is not considered to be "retro". Some games which are only a few decades in age, though, are looked down upon, people generally assuming that a WAFF might be the only reason to re-play them.
I guess this is yet another sign of how much power advertisement companies, marketing divisions, and mass media hold over us nowadays. They don't need to convince everyone, but if they convince enough people, those will convince others. In this case, they'll convince them that they need those great new graphics and surround sound, or they're stupid.
Dealing with this kind of mental enslavement is likely to be one of the greater challenges of our future (and no, I'm not just talking about "retro gaming" here...)

4 Feb 2001 (updated 4 Feb 2001 at 18:04 UTC) »
0.3.1 was released on thursday. It's been over half a year since the last release, and I guess that delays of this size are not good for free software projects. Anyway, what's more important, we now have a TODO for 0.3.2. One of the more interesting points in there is the suggested re-implementation of the parser. We're using a "proto-Earley" algorithm for parsing right now- it works, and it's not really performance critical because it's only used once right after something has been entered, but I don't really like it anyway. I'll read up on LL and LR parsers for this one; however, it looks as if the most sensible change would be to change the emulation of non-determininsm from set management to back-tracking in the algorithm. The Sierra grammar typically matches two to 8 derivation trees(is that the right phrase?), of which only the first one is considered, so we're wasting a lot of memory and resources in this place.

Looks like the others want to release a second alpha RSN- this means I need to catch up with the Alpha port again (probably tomorrow). Turns out that it's a bad thing that Compaq's cxx doesn't understand the -include flag- while it's possible to emulate that with 'make' rules, this emulation step appears to be a PITA in automake. This means that it won't be possible to de-uglify my Alpha/Linux/cxx modifications. Well, it wouldn't help with the main ugliness (#ifndef'd includes of standard system headers), so I won't investigate any further into that direction.

Now they did it. Looks like my ISP, which just happens to be the dominant ISP here in Germany and a remnant of the former telco monopolist, managed to blow up all of their routers and backup systems in Frankfurt/Main. Or something equivalent (that'd be the only "sane" explanation for the current situation). Anyway, my 'net connection is slow as hell and totally unreliable (using CVS is almost impossible). A friend of mine was told that this will probably be fixed "in a month or so". Oh, and on top of that, my DSL line will be delayed by, well, roughly half a year (Note that those guys never had any friends in the first place, so they're not risking anything there).
I had to take my system to work (where they have a T3 connection) just in order to release FreeSCI. This sucks badly.

Got a Cowboy Bebop DVD. They didn't have the first one, so I took #2 (after all, it's supposed to be rather episodic). Watched it yesterday, and I really like it. Somehow, it reminds me of Elite and Frontier, and anything that does can't be bad.
I also started learning Japanese. I guess it'll take a few years, but it's an interesting challenge. Thanks to Anime, I'm even semi-guaranteed to keep motivated for quite a while (Note that Sierra's adventure games were my base motivation for learning English...).

The semester is coming to an end. This means that I have to finish some work, including the seminar paper mentioned earlier, and prepare for a few tests (OK, so I'm not going to do that until one day before the test, but WTF).

My regular job resumes on February 22nd. Then it's back again to Java, XML, and e-commerce (shudder). I'm looking forward to doing more XSLT work, though- while the language does have its design-by-commitee weirdnesses and is a PITA to type (-> active code generator?), it's certainly a refreshing break from most of the other stuff I'm supposed to work with.

I wish I had time to play any. OTOH, the only commercial game that runs on my box would be Civ CTP, so I'd probably just play Nethack or Moria or Angband or something like that. Anyway, it looks as if Loki is having problems. This is an inherently bad sign, as they were the gaming company closest to "doing it right", in my book. This is going to send a very bad sign- I just hope they'll recover (and port Deus Ex to the Alpha).

Graphical User Interfaces
Regarding recent discussions of GUIs here: Personally, I never got the hang of GUIs. I do agree that customizeable keys (or even just functions available via hotkeys) are a good thing, though; in fact, my personal opinion is that the pointing device should be as optional as possible. We need graphics, for a vast amount of reasons, and we need pointing devices, because they are more efficient whenever some sort of aiming is required. However, without speech recognition or stylus + handwriting recognition, we can't go without a keyboard (and even /with/ those, I'd recommend against going without one), so there's no point in trying not to use it. OTOH, without a touch screen, we need the mouse for certain kinds of graphical interaction (at least for the rough aiming). Still, my impression is that the keyboard is superior for the vast majority of tasks, and GUI designers shouldn't forget about that. While I'm ranting, I might as well mention the other thing I perceive as a common misfeature in graphical programs: Popup windows, or, more precisely, stealing the keyboard focus. I don't care about the fact that Mozilla couldn't get a host name resolved while I'm typing my password for a remote account, so I don't see the point of it stealing my keyboard focus. Neither do I see the point of it opening a window to tell me so when it has ample space in the browser window to do just that. Of course it might be argued that some things are important, and should be brought to the user's attention as soon as possible. I guess some sort of "notification bar" would be most appropriate for that- a bar (occupying a few pixels on top of the screen) which flashes or shows some sort of icon whenever some program wants something urgently or believes that I absolutely have to be told about something else. Given a sufficiently versatile type system, users would even be able to weed out events they don't care about, or sort those by their own asessment of the events' priority. I guess what I'm proposing could be called a "non-intrusive user interface". I don't know whether this is the kind of thing Joe Random User would like to use, but it's the kind of GUI I'd be comfortable with (provided that it'd fulfill the usual requirements like customizeability and easy control from the keyboard). Come to think of it, we should also assign numbers and letters to windows (same as we do to virtual desktops), so that they can be addressed in very few keystrokes. (This might also help with voice input- changing the voice input focus should be easier if you don't have to say things like "the second x-term from the left").

Code freeze since yesterday evening. I guess I should update the homepage with the news. Anyway, 0.3.1 is close, though it'll be UNIX only this time (mostly because the DDRAW gfx driver is still incomplete).
I think I'll abuse the Compaq TestDrive systems for testing this time... wonder if FreeSCI builds on OpenVMS...

I don't quite recall who it was, but someone here at Advogato recently gave a pointer to megatokyo.com- whoever you were, thanks- I can't believe I overlooked this online comic/manga for so long :-)

Looks like a YOPY Development kit is finally available. The YOPY, for those who don't recall, is one of the Linux handhelds announced last year (StrongARM, 32 MB Flash, 16 MB SDRam, IRDA, RS-232C, CompactFlash type 2, 240x320x65k color display, batteries). I played with one of those on last year's CeBit, and it seemed pretty cool back then (the display wasn't too clear, though, and some of the programs didn't work yet). My main complaints about it are the size- it's not too bad, but more kludgy than a PalmPilot- and the use of batteries. For a further analysis, I'd need one...
But back to the YOPYDK: It's priced at roughly 0.7kEUR (read on before panicking), and it includes an actual YOPY. Unless I missed something, all software and patches are free (gcc, gdb etc.), so the actual value you get is the YOPY itself. They're targetting ia32/Linux workstations as development platforms, which means that their gcc/binutils/gdb patches might require some 64 bit cleanups before I can use them, but still...

Considering how much I write about this thing, it seems likely I'll get one after this year's CeBit or so. I don't see why it shouldn't be possible to get FreeSCI to run on it (once memory usage has been reduced somewhat further)...

Improbability factor 262144:1 and falling...

On monday, which just happens to be the the last monday prior to the intended FreeSCI CVS freeze, my router's root HD finally decided to go the way of all hardware and leave me without net access. The same day, my car started leaking massive amounts of oil, rendering it effectively unusable.

Improbability factor 2048:1 and falling...

So starbase42 (the router) was destroyed. Deciding that net access was more important than mobility, I set out to buy a new HD and install Debian rather than SuSE (nothing personal, I just happen to like apt). Everything went well, until I started loading the ISDN modules: it took me 7 hours to find out that hisax.o was not autodetecting the IRQ correctly- 7 hours I intended to spend refining my slides for a presentation, which, not surprisingly, happens to be tomorrow.

Improbability factor 1:1... Normality... Repeat, we have normality...

Most things are still very broken ATM. rei (my workstation) still doesn't have a 'net connection due to missing ipchains on starbase42 (which I should probably rename to starbase42-A now), my father has to use an old KDE snapshot and no StarOffice until apt finishes updating, and so on.

Well, I'm still mostly alive, which is not really surprising since I wouldn't be able to suffer otherwise.

One of the new sound guys, Stuffed Crust, is starting to dig into the code and change things in preparation for a sound implementation. This means that we might have a 0.3.2 release pretty soon after the 0.3.1 one (and yes, we should start freezing features in CVS for it RSN.) One problem we kept on having was memory leaks. A lot of memory was being lost during the game (e.g. all game resources were present twice, and stuff like that...); using dmalloc, we managed to track down most of them. FreeSCI now uses 25 MB RAM on my box, in 640x400 16bpp, which is less than two thirds of the initial value it used there (and you no longer loose 1.5MB each time the background pic changes).

One thing that is concerning me are the numerous calls for SCI1 support (SCI1 is, very roughly, a name for the the first VGA versions of the SCI interpreter). We still aren't fully stable in SCI0 yet- Colonel's Bequest, Conquest of Camelot and Hoyle's Book of Games have known problems- and I'd rather fix existing problems before starting the vm re-organization we will need for SCI1. However, a lot of effort appears to have gone into SCI1 research already (still waiting for documentation...), so I don't really want other people from working on it with the things we have in FreeSCI either...

I guess the best approach to this would be to fork off the 0.6 development branch right after the 0.3.1 release. Thus, SCI1 people would have something to work on now. (Most of the remaining pre-0.4 work is related to refining the graphics subsystem, adding sound support, and fixing bugs. This is relatively orthogonal to the VM reimplementation, so forward-porting should be rather simple in most cases).

Linux 2.4.0
Somehow, I feel much less thrilled than I felt with the 2.2.0 (aka "Brown Paper Bag") release. I haven't installed it on any of the boxes I administrate- I don't need any of its features on the ia32 one, I'm not going to trust my Alpha to it just yet, and the SGI Indy isn't anything I'd want to run Linux on.

Happy new year! (Yeah, I'm late ;-)

Local hardware
Lots of network changes around here, but everything went smoothly. This is a bad sign, obviously- things aren't supposed to go smoothly when networks are involved.
I finally replaced my trusty old NEC CP6 with an HP Laserjet 1100. Technology sure has come some way since the last millenium- that thing prints a postscript page in less than 10 seconds! (5 to 7, I'd guess). The same took several minutes on the CP6...

Widget system is in, menus work again, savegames appear to be operational- somehow, things are getting together much faster than I had expected them to. We'll probably start preparing for a new release RSN- end of this month seems like a good date for 0.3.1.
I guess it's appropriate to update the homepage with a few new screenshots now...

g++ 2.95.3 doesn't fix the SIGILL when running Exult on Alpha/Linux, so I'll continue trying to make it work on cxx for a while.

Here is a review of the Sun Blade 1000 (in german). Looks like another piece of hardware I'd appreciate having around ;-)
It has the usual disadvantages of Sun systems, though- GNU tools aren't installed (I don't have the slightest Idea why they keep on forgetting to ship them pre-installed), and the price is relatively high at roughly 15kEUR (for the cheap 512 MB system). You can probably get a DP2000+ workstation with 2 833 MHz EV67s (or are those EV68s?) and a gig of ECC RAM for two thirds of the price, at roughly 1.2 times the FP and Int performance- for one processor (but IO and Mem throughput might be a bit worse, and you won't get a funky 3D accellerator with it). Well, you could, if enough of those systems were shipping.

28 Dec 2000 (updated 1 Jan 2001 at 14:07 UTC) »

Merry post-christmas, everyone!

Spent the last four days preparing a for a seminar in mid-january. Usually, I'd never voluntarily pick a seminar on "information commerce", but the person responsible for this one happens to be my boss, and he actually gave me an interesting topic to work on: Combining three modal locics to model deadlines and similar stuff in business transactions. (well, "combining three modal logics" is the interesting part here, the rest of the title is decoration). It's based on two papers ([1] [2]), but it turns out that, while providing a nice algebra for writing things down, it's too messed up for sensible reasoning or planning in any but the most trivial of cases.
Researching for this one taught me to like the NEC CS citeseeker
However, there still is one thing I hate about seminars, and that's preparing the slides. I enjoy presenting my stuff, and I like writing the seminar paper (if the subject is interesting, which it is in this case- combining deontic logic, dynamic logic, and temporal logic (PTL, to be precise)), but watering down the contents to improve the grokability factor hurts. A lot. But that's the price I'll have to pay for taking a seminar which mostly CS economists ("Wirtschaftsinformatiker") (US people: think CIS) are involved in.
Slides have another problem: While the TeX seminar mode works great for me, my boss wants PowerPoint slides. However, I don't have access to any win32 system and couldn't install it on my Alpha if I wanted to (which, surprisingly, I don't), so I'll have to try something like converting them to eps, which SO5.1 is supposed to be able to import (I can't run that one locally, either, but it's installed on some Solaris boxes I have access to).

For Christmas, I turned an SGI Indy into an X terminal, so that my father can finally enjoy KDE2 to do whatever it is he wanted to do in the Internet. Turned out that konqueror renders the FreeSCI homepage correctly, which makes it look pretty broken. Oops.

Good News, Alpha users: Exult/CVS works now! Except for the segfault when clicking "Setup" in the main menu, everything looks pretty good- as long as you use playmidi for MIDI output. I guess I should have a look at libkmidi or timidity...

Considerable improvements- the display lists work great now! I just wish the guy working on sound support had more time for FreeSCI. Anyway, I guess I'll take a break from writing seminar slides now and try to fix the two remaining dynamic/static display list bugs. And, if that works, re-enable some more of the disabled graphics functionality.
Also fixed the FreeSCI homepage. Sorry for needing so long to find out about that, Konqueror (Konquerer?) users!
BTW, I think I'll try this IRC thing tonight.

Despite the pretty screenshots, not much interest popped up. I really need to test/debug/fix the widget subsystem ASAP, so that 0.3.1 can be released before the semester is over (before Woody starts to freeze, actually).
Some more bugfixing and re-enabling of disabled stuff proved to take care of some problems, though. However, there are enough bugs now to warrant an extensive bug hunt- no more features until the priority map, the SQ3 intro, and collisions work again.

Alpha users: Don't try it just yet; SF didn't let me access CVS yesterday (they moved a few servers, apparently), but I learned that some important patches of the Alpha/DECCXX patch are still missing.

I also noticed that a lot more people are working on Exult actively than there are on FreeSCI, even though the latter covers more games. This may be because of the recent release, but I also suspect that their IRC sessions, which happen to be rather productive, help a lot with keeping people in touch and together. Or maybe DrCode is just better at managing projects or motivating people than I am... Well, I can try to improve, but I'm wondering about that IRC thing. It's much easier to build a community with an IRC channel, of course... do any of the people who actually read this have any experience with the affect of "official" IRC channels on the development process in a free software project?

Other games
Tried Chromium BSU. Lots of typecasts of pointers to ints, so I didn't bother letting it finish compiling. I guess I won't have time to fix this one too soon, though.
Sarien: claudio wanted it to have a new graphics system one day. I hope that the FreeSCI one will be fit for the task once the widget stuff has stabilized.

Don't have enough time to have a lot of it, but I squeezed some "Family Guy" and "The Slayers" into some spare time slots. Turned out that both are quite entertaining in their own little ways, but neither is a "must-see". IMHO, both are worth watching, though.
BTW, some people may have missed this, but Shin Seiki Evangelion (Neon Genesis Evangelion for US people) is being broadcast in Germany these days (subtitled). I'd be pretty happy about this if I hadn't bought all the tapes (well, at least now I can watch them with german subtitles...). Anyway, Anime appears to be making its way inroads here, and I guess that's a good thing.

Finally managed to get it working on Alpha/Linux- you can get a binary from this place, if you're interested. The page also includes rough build instructions and a link to my outdated patch. DrCode registered me as a developer just after fingolfin added most of that patch; I'll try to fix the remaining issues as soon as I have some spare time again (ca. April 2032).

Fixed the dynview display list (mostly), and released two screenshots that didn't look too broken. The new graphics subsystem definitely takes more time to render the background pictures (it uses flood fill, after all), but, personally, I like the results. Also, the actual screen update time (time spent in the Animate system call) has improved significantly (3x3 currently plays at roughly the speed of the old 1x1; if nothing changes on the screen, network traffic should be minimized when playing over X as well), and, of course, it's more scalable, but I mentioned those two things here before, so I'm not going to go into any detail here.
I still hope I'll have some spare post-christmas time to devote to the gfx subsystem, but a seminar presentation I have to prepare may take a lot of that time.

Compaq have released JDK1.2.2 for Alpha/Linux to the general public. This is an important event, since it almost obliterates one of the three platform disadvantages of the Alpha I mentioned here (or was it the Heise newsticker?) a few months ago- they were:

  • Broken g++
  • No recent JDK
  • No hw-accellerated GLX
Point #2 is only almost obliterated, since the license agreement you have to click-sign in order to download the JDK (and the form you have to fill out in order to download libcpml, which the JDK depends on), does not allow free redistribution of those things (and not re-packaging either, although the point in this is rather limited if redistribution is disallowed anyway). (Most of these things were pointed out by Christopher C. Chimelis, probably the Debian/Alpha guy, which I thought I'd better mention here.)

Anyway, regarding the other two points: cxx is quite good, if you ignore the implicit g++ namespace mangling. cxx is evil, proprietary, and binary-only, of course, but there's not much of a point in preferring a free broken compiler over a working non-free compiler.
WRT to GLX, I've heard a few success reports regarding PCI graphics cards (Voodoo 3), but AGP cards still aren't fully supported on my UP1000 because of firmware troubles (an upcoming internal API contact promised to give me an estimated date for the release of the upgrade next year, though).

AI test tomorrow. This should be fun- I like the subject. One of the few things that are more fun than building compilers or engines for 10-year-old games.

I'm out of it consistently now. People trying to contact me should probe back after christmas, in case I'm still alive (and don't rely on my answer then).

No, this is not another rant about how much gcc 2.95.2's c++ frontend sucks on the Alpha, breaks with internal compiler errors, creates incorrect function tables, cancer, famine, and a whole load of other evil things. No, it isn't- I just wanted to point out to those who missed it that the gcc steering commitee appears to be planning to put out a 2.95.3 interim release. This is great news- even though the hairs I pulled out won't grow back this way, a lot of programs might *finally* work on the Alpha. Like Mozilla. Or Qt. Or KDE. Or, of course, Exult.

Implemented and verified the new decompression method, but haven't checked it in yet. Since the new widget system is doing quite well, I'll lay off implementing the hooks from the SCI kernel calls to the widget system until after christmas.

Christmas presents
My favored present for everyone this year would be that they don't have to buy me a present. Too bad not everybody is happy with that, so we can't limit ourselves to singing and celebrating and generally stuffing our stomachs with various kinds of comestibles, much like we did with the traditional goose (or whatever kind of animal or plant you happen to traditionally prepare for christmas).

14 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!