Spending most of my time on university stuff lately, so there's not much going on development-wise. With some luck, a university project might turn out to become another addition to the Free Software world, though. OK, to be honest, it's the other way 'round- I'm trying to get a piece of code I'm working on to be accepted as a replacement for a much more boring project I'm supposed to be working on.
GCC 3.0's out, and I'm supposed to be happy. Unfortunately, Compaq's (soon Intel's?) cxx is faster by an order of magnitude. I haven't compared the code quality yet- neither compiler manages to build Mozilla or the kdelibs on my box, and I'm not really in the mood to do benchmarking.
Since the last update, I went to the theaters exactly four times: Twice to see Mononoke Hime, which I highly recommend- the German synchronized version is surprisingly good-, once for Perfect Blue, which wasn't bad either, and once again for The Mummy 2 (Or whatever the official title is), which I didn't enjoy quite as much as most of the others I talked to. It had a few nice ideas, but it was just too cheesy ("Hollywood-ish") in places.
Anyway, I think I'm going to skip Perl Harbour- according to two reviews and one oral report, it's apparently not worth watching. Not quite on par with Saving Private Ryan, Das Boot or Hotaru no Haka('Grave of the Fireflies').
/dev/sequencer doesn't like me. Somehow, we run out of partials (voices) much too soon, even though a sufficient number of note-offs (MIDI 8x... or was that 9x?) are sent. Also, far too many gfx optimizations appear to be hitting worst-case situations (especially noticeable in the HQ character setup screen). Don't like that at all.
A few interesting suggestions regarding extending SCI have been suggested on the IRC channel, mostly regarding BSD socket support. Personally, I think a more interesting challenge would be to extend the interpreter to have 32 bit support without breaking the existing 16 bit code. Anyway, general interest in using SCI for new stuff bodes well regarding Brian Provinciano's SCI development thingy. Don't think I'd want to use a 16 bit interpreter for a new project, though...
Interpreters and virtual machines
I got an interesting mail from someone who slightly mis-judged the order of magnitude of FreeSCI and wanted to pit it against Java and .NET. He was rather persistant with this, especially since, as he pointed out, a proprietary VM called ICVM was much faster than Java on his system. From what I can tell, ICVM looks like a more register-based approach (like Dis) with a highly CISC instruction set. Due to the CISCness, the interpreter overhead was supposed to be rather small, making a JIT unneccessary.
However, the design of ICVM looks rather PC-centric- most of its registers are 32 bit, and it only has 6 general purpose integer and 3 general purpose floating point registers (On most architectures, you could play Space War in the remaning registers without this noticeably affecting performance...).
Anyway, the main point he was making was that there ought to be a free VM design around. Creating a good real-life VM would certainly be an interesting challenge, but I'm not sure whether it'd help Free Software in general- after all, it would just encourage people to keep their stuff closed again. Then again, it might help making non-mainstream platforms more popular, which might turn out to affect the BSDs and GNU/Linux positively... Of course, the amount of work needed to create something in the order of manitude of Java would be immense. A more sane starting point would probably be to start off an existing project (such as Python) and use its libraries, tweak its VM for performance, and write a gcc backend for it...
Well, I guess I'm spending too much time thinking about this- a project of this kind couldn't happen without massive interest from a group of powerful hackers, and I don't think we'll see that.
Looks like Exult will be going into Debian's contrib. IMHO that's pretty good news, but I'm not certain whether the auto-built Alpha port will work well (since they're probably building it with gcc rather than cxx).
Watched the first ten episodes of Cowboy Bebop for the third time (with a constantly increasing audience). I do have the third DVD lying around here, but, not having a DVD player myself, I'll have to wait for other people to have some spare time in order to finally learn what happens after Ganymede Elegy...
Mononoke Hime is going to be shown in our local theaters RSN. Only two more weeks or so...
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:
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.
(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...)
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").
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)...
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).
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 ;-)
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.
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 ( ), 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.
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!