Time
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.
C++
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.
Movies
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').
FreeSCI
/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.
Exult
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).
Anime
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...
Python
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:
Alpha
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...
FreeSCI
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...
Exult
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.
Assembly
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...
Work
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...
D'Oh.
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...)
Exult
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.
ISP
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.
Entertainment
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...).
University
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).
Work
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.
Games
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").
Entertainment
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 :-)
Handheld
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.
FreeSCI
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...
FreeSCI
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++
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.
Workstations
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!
University
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).
Christmas
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.
Exult
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...
FreeSCI
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!